By Adam, Senior Consultant and Remedy Developer

 

When I first joined Aim, I was impressed by their development standards and documentation. As a Remedy Developer, I was asked to develop a bespoke Remedy Application to help manage the development lifecycle. Whilst I’d worked with Remedy Applications in the past which were very good at promoting good coding practices and code control, they’d been very clunky and time-consuming to use. I therefore set about designing this version from the ground up to ensure it promoted these same benefits but would be more efficient and as user friendly as possible. 

 

I designed this application with the following goals in mind:

1.       To help manage the release cycle by providing a place to detail the requirements, design the solution, document the code, run the test scripts and allocate them to individual developers. 
 

2.       To provide a way to help with code control to ensure nothing is missed when migrating code from the Development environment onto the UAT and Production environments. 
 

3.       To provide an easy way to look back at code developed previously in order to find the original requirements and how it fits with other code developed.
 

4.       To make it as quick and hassle-free to use as possible by the Developer so that good documentation is not too much of a hindrance and to allow them to focus on good development.
 

Remedy is unusual in that its code is held in the database. This makes it possible for a Remedy application to see and interrogate that code. Whilst ordinarily this wouldn’t be of any use, this is extremely useful for an application designed to document and manage that code and is something previous tools I used didn’t do. I therefore used this to great effect, both to allow that code to be related back to specific customer requirements and testing issues, but also to provide handy ‘widgets’ that allow a developer to more easily track down and understand existing code; something that is invaluable both when changing existing functionality and when troubleshooting. This not only leads to faster development, but helps ensure things aren’t missed which leads to fewer testing issues. I believe it is this capability that sets it apart from any other similar tools already out there.

 

Aim Remedy DevSure consists of the following main areas of functionality:

·         Console
The Console provides a view of the current requirements and issues against a project along with entry points into the various bits of functionality and the various configuration forms used by Aim Remedy DevSure.

·         Requirements
The Requirements form captures the business requirement, the proposed technical solution and then the details of the low-level code.
What sets this apart from other similar programs written and used by other Remedy companies is that the individual code objects can then be related (including in bulk) and individually documented to the main requirement. This allows them to be tracked properly to ensure they are not missed as well as providing a way to search the requirements by looking for one of those code objects.
Test scripts can also be written against the requirements with the results recorded and these can then be exported as a report. 

·         Issues
The Issues form is a place in which to record any issues found during testing or by the customer. This provides the same functionality as the requirements form above but means it can be tracked separately from the requirement if needed, and likewise can be related back to one or more requirements.

·         Utilities
The Utilities form is basically a large collection of ‘widgets’ that help the developer understand existing code.  This is therefore of great use both for customising or changing existing code, and when troubleshooting issues.  The details of all the functions won’t mean a lot to non-developers but to give some examples, it:

 

          o   Searches for the code that displays a specific message to the user. 

          o   Shows when timed events (escalations and archiving) are set to run which can help identify the cause of performance issues.

          o   Displays version information of the platform and all installed ITSM applications. This can be useful for a support person to copy and paste when reporting an issue to BMC.

          o   Finds code that opens a specific form or sets a value in a specific field.

 

One of the great challenges when developing Aim Remedy DevSure is in understanding how the code is stored in the Remedy database. This is something that is not well documented (at least outside BMC and in the public domain) and so the only way was to reverse-engineer it by looking at the database and comparing with the code. There have been some issues where this has changed between versions, such as the introduction of overlays in v7.6.4, of the Association objects in V9 and changes to the way Flashboards are held and so I have had to code around these to ensure it supports the latest releases as well as continuing to support the older versions.

We have been using Aim Remedy DevSure to great success for some time with one of our major customers and we are now rolling it out for use by other customers. It is undoubtedly viewed as a thoroughly professional  tool.  It basically provides an ‘online’ version of the documentation for previous releases which can then easily be searched. This has allowed me to check the original requirements and agreed solution design when the purpose or behaviour of a specific code object is brought into question. It has also helped ensure all our deployments to production have been successful by reducing risk of missing code. Aim Remedy DevSure has an exciting roadmap which will allow it to be increasingly useful.

 

Click here to find out more about Remedy.