pragma::tims is a Java-based issue tracking system and bugtracking tool. The key concept of the software is to manage defects and requirements (both called “tickets”) in a single tool. The pragma::tims’ smart client is a Webstart application, which can be run on any OS. pragma::tims also offers a simplified web client called pragma::tims c³ (customer care center) designed as a support to off-site customers. The customer tickets created in pragma::tims c³ have a separately configurable status model. Additionally, every customer ticket is always linked to its automatically created clone, which is an unrestricted ("real") and otherwise completely independent pragma::tims ticket.
The first version of pragma::tims was created in 2003 by the German consulting company, mceti AG, which is now United Mentors GmbH. The project is currently being developed by QuestByte Ltd. & Co. KG. pragma::tims was originally a 2-tier fat client with MySQL as database backend. The c³-web client was added in 2004. The product was completely re-designed in 2005 and has now a 3-tier-architecture with a Java smart client, a server-side business layer running as an Apache Tomcat servlet container, and a RDBMS (e.g. PostgreSQL) as database backend. Recently, an internationalized release has been made available with a new look-and-feel and a separate administration client.
pramga::tims's server system requirements include:
Currently supported relational database systems are SQL Server 2000, PostgreSQL 8.0.x or above and Oracle 10g or above. pragma::tims application server can operate on any platform which supports Apache Tomcat. The database server may run on a separate machine. For MS Windows server an installation wizard is offered. For Unix-based OS detailed installation instructions are available.
The client runs on any platform supporting Java 5.
The object model of pragma::tims is based on the idea that most software development projects basically need three object layers: project, system and sub-system. This very basic concept is used for both requirements and defects. The type of the ticket is determined by a prefix, which can be changed any time. For example, a "defect"-prefix can be changed into a "feature"-prefix that uses a different status model. In addition to the predefined existing ticket attributes, any number of generic fields can be created by the administrator.