AIMS

Automated Issue Management (AIMS)

Have you ever experienced software defects (bugs), or even authored some yourself? Eh... hmm... !? I am sure you agree that when working on any type of a product, there is a great need for tracking and resolving defects. Even after a product is released to its audience, there is a need to track defects, suggestions and other types of requests from the end users. As you probably already know, there are quite a few bad things that can happen if you do not have adequate support for tracking change requests and other issues of that nature. If you don't agree, then have a look at the following points:

  1. Requests get forgotten. They will! This is a fact of life. Report a handful of bugs on a friday at 5 pm to an engineer that is responsible for resolving them, and he has surely forgotten some of them by the following Monday. 

  2. Requests get misplaced. Consider issues that require input from several people before they can be resolved. As different engineers may be responsible for different areas of a product, it may not be clear who should handle a particular issue in some cases. As such, it may very well happen that either several engineers will begin to work on a request -- or no one at all. In either case, you end up with a mess.

    3.  
  3. Requests get misinterpreted. The use of technical terms and the insight into the use of a product differ greatly between people and more importantly, between different people with different responsibilities. An engineer may have great knowledge about the technical side of a small part of a product (how and why it works), but little knowledge about how or why an end-user would use the product. Reports about defects or requests for new features may therefore be misinterpreted to some degree. It is also quite common for an engineer to correct defects which, although they exist, they are not the defects that someone reported. It's even more likely that the resolution for an issue is incomplete, or just plain wrong!

    4.  
  4. Unwanted side-effects. As products evolve and become more and more complex, there is an increasing chance that any change applied to the product will cause unwanted side-effects. It's actually quite common for engineers to fix one defect only to introduce another one, which in turn causes the original problem to re-surface. 

Tracking changes

Tracking changes is a necessity when striving for quality and good customer support for a product, even if you only use Post-It! notes to accomplish this task.

AIMS is product suited to do exactly this. It's an Automated Issues Management System, sometimes referred to as a Change Request Tracking tool. It's as equally useful when quality testing a product during that last phase of the product development, as it is in providing customer support for an already released product. In provides unparalleled support for tracking issues, by letting the users log issues (requests for some actions, such as to fix a defect or add a new feature).

A request to change some aspect of a product, such as fixing a bug, adding a new feature, or requesting some form of maintenance action, is known as an "Issue" in this system. Issues have some important properties that help users deal with the problem mentioned above. They are:

  1. Issues have a state. "Active" issues are issues that still require some actions. "Resolved" issues have been processed, but no one has verified that those actions were appropriate. An Issue becomes "Closed" only after someone has reviewed the actions and decided that the Issue has indeed been correctly processed.

    2.  

  2. Issues have an owner, which is the person responsible for processing the issue and thus move it towards the goal of being closed. As an issue can not be orphaned, there is no chance of issues being forgotten.

    3.  

  3. Issues have an audit trail. All actions associated to an Issue are logged, which allows you to review them. This is important when an unwanted side-effect is found, as it enables you to scrutinize all the actions taken up to the point where the side-effect was found.

    4.  

By using these properties when managing issues, an issue can not be forgotten (it's in the system until it is closed), it can not be misplaced (someone is always responsible for it), it can not be misinterpreted (the person who logged the issue always has a chance to review the actions taken and the result), and side-effects can be avoided (someone will always review changes before issues are closed, and there is a detailed audit-trail that can be used to resolve such problems).

 

Features and benefits

Although AIMS was designed to track bugs in software, it's ideal for any type of use where requests for actions are logged and processed. Such examples include help-desk support, product support and generic product development.

  • Actions taken on an issue are immediately observable by users of AIMS on all platforms.
  • Notification of actions through e-mail, AIMS and third-party plug-ins, either immediately or at recurring intervals.
  • Great platform support, ranging from Unix, Windows (NT,95,98), and Macintosh, to handheld devices.
  • Scalable solution. Supports anything from single user to >10000 user systems. Current support includes ODBC data sources, such as JET and SQL Server.
  • Secure client/server access, through SSL. Works well with firewalls.
  • Single, secure and remote administration tool.
  • High quality, extendable and platforms independent forms.
  • High quality, extendable and platforms independent reports.
    •   

    Requirements

    As AIMS consists of a number of client and server modules that run on several platforms, the system requirement varies. The requirements for some configurations are quoted at the end of this section.

    Server applications

    - Web server modules,
          Netscape Enterprise Server: Unix, Windows
          Microsoft Internet Information Server: Windows (95,98,NTWS, NTS),       Macintosh (8.5)
    - Mail server module,
          Windows NT: Windows (NTWS, NTS)
    - Action notification server module,
          Windows NT: Windows (NTWS, NTS)

    Client applications

    - Web client modules,
          Netscape Navigator: Any platform, version 3.0+ and above
          Microsoft Internet Explorer: Any platform, version 3.0+ and above
    - E-Mail client modules,
          Any Internet e-mail reader.
    - Native clients,
          Aims windows client: Windows (95, 98, NT)

    Typical configurations

    Typical 5-15 user configuration on Windows, including:
    - Web server module running IIS on an NT Workstation
    - Action notification server module, on an NT Workstation
    - Mail server module, on an NT Workstation
    - JET ODBC database engine.
    - Web clients on various platforms.
    - E-mail client on various platforms.
    - Aims native client, on Windows.

    Server:
    Required - PC with 166 Mhz 32MB PII and 1GB HD.
    Recommended - PC with 200 Mhz 64MB PII and 3GB HD.

    Client:
    Required - Any computer with Internet or e-mail support.

     

    Pricing

    Call for information.

     

    Support

    If you have purchased a copy of AIMS, then you may qualify to download a more recent version. Please follow the following link to download it.
    Download

    To view issues in the current version of AIMS, or to report known issues, follow this link to the AIMS Project or contact us directly. If you have recently purchased AIMS, then please register AIMS here.
    Register

     

    DEMO version

    You may find a recent demo version of AIMS here!