Maintenance by Monrose
Our clients, especially manufacturers of test and measurement equipment, typically have many well-established products, some of which may have been in production for more than a decade. By employing Monrose Services to carry out their software maintenance work, they can extend the life of their existing products without disrupting new developments.
Within the past few years we have undertaken such diverse maintenance work as:
- Modifying a 20-year-old 8085-based system to overcome a component obsolescence issue.
- Facilitating the replacement of an obsolete microcontroller.
- Adding new measurement capabilities and improving the performance of several test and measurement systems.
- Creating a new variant for an existing product family.
- Tracking down an obscure bug in a DSP system.
In many cases there was little or no documentation available, and very limited capabilities for debugging on the target hardware.
Most of our work in recent years has been in C, but we have the capabilities to handle C++, PL/M, Pascal and Occam, and are prepared to tackle other languages (including assembly language) as required.
Working Method
|
Site Visit
|
Apart from gaining an understanding of the system, we make an assessment of the existing software build procedures and the availability of build and debug tools.
|
|
Proposal
|
Usually we offer a fixed-price contract, (including a maintenance period of 60 days from delivery during which any defects found in the new code will be corrected free of charge).
Sometimes the nature of the modification is too complex to assess without undertaking an Analysis and Report Project, for which a fee is charged. The report delivered on completion of this initial project forms the basis for a further Proposal.
|
|
Access
|
As much analysis work as practicable is carried out away from the client's site, although sometimes it is necessary to have access to the client's equipment. If this is the case, our requirements will be included in the Dependencies section of the Proposal.
|
|
Documentation
|
We always aim to leave the client's system in a better documented state following the maintenance project. To that end the Proposal will usually specify deliverables such as requirements specifications, design specifications and notes to assist with the update of manuals and other user documentation.
|

|
The All-Important Build Procedures
The initial build of a customer's legacy software can be one of the most challenging parts of a project. Writing build procedures has always been a tedious task, but they are vital if software is to be maintained over the long term.
Recommendations:
- Keep records of the specific hardware and software configurations of the computers on which the software was built.
- Keep that old 486 / MSDOS PC, Intel MDS800 or MicroVAX stored safely. It may be needed one day.
- Record the details and preserve copies of specific versions of all the tools used to build the software - not forgetting the software that controls the PROM programmer!
Being forced to "upgrade" a compiler because the version originally used was not recorded or is no longer available can be like taking the parts list of a printed circuit board, making a few random changes to component values, and expecting the completed board to perform exactly as before.
- Validate the build procedures by getting someone not connected with the software development to follow them from scratch. Better still, make it a policy that any software installed in products during manufacturing or service must be built independently of the originating software team.
 |