Maintainability

With respect to maintainability, your application should be designed and deployed in such a way that it can be maintained and repaired easily. Maintainability is defined as the ease with which a software system or a component can be modified to correct faults or errors, improve performance, or be adaptable to accept new added functionality. The system must also be adaptable to a changing environment. It might seem obvious, but a computer system is useful only as long as it continues to function properly. Maintainability is the measure of how easy it is to keep the system functioning. Maintainability requirements define how the system is to be maintained at an operational level after it is put into production.

A maintainability requirement is usually a quantitatively stated requirement that specifies the degree to which an application or component must be able to be maintained between major releases. These are typical examples of maintainability requirements:

  • An episode of unexpected downtime will not exceed five minutes.

  • The scheduled system downtime for maintenance will not exceed five days a year, and each specific instance of these scheduled maintenance windows will not exceed 8 hours.

  • The average time required to make a minor enhancement (including testing and documentation updates) will not exceed five work days.

As you can see from the preceding examples, these are the objectives of maintainability requirements:

  • Ensure that minor defects in an application or a component are easy to correct.

  • Ensure that minor enhancements to an application or component are relatively easy to implement.

  • Minimize maintenance costs and free up programmers for other projects.

When a car is several years old, it usually falls into two categories. First, the car continues to run well, requires little maintenance, and performs almost as well as the day you bought it. Second, the car constantly breaks down, so it's unavailable while it's in the shop, and it becomes more expensive to maintain. Owners of cars in the second category usually decide to dump the car and buy a new one.

In many ways, this car analogy parallels a computer system. A system with high maintainability needs little attention and has a long useful life. A system with low maintainability has high maintenance costs, is unreliable, and is frequently unavailable. A low level of maintainability results in the following:

  • A lot of effort is required to carry out a typical modification to a software product's functionality.

  • Code is difficult to understand, modify, and migrate.

  • The cost of maintenance over the system's lifetime is prohibitive.

For the most part, maintainability requirements are usually concerned with these areas:

  • Breadth of the application At how many sites will the application be installed? For example, is the application at a single-site location, or will it require a multi-site installation? Single-site installations are generally easier to maintain for the simple reason that the staff responsible for ensuring maintainability is most likely located at that site.

  • Method of distribution Concerns in this area deal with methods of distributing updates or changes needed to keep your applications properly maintained.

  • Maintenance expectations Discussions are needed to determine what everyone expects in terms of maintenance obligations and responsibilities.

  • Impact of third-party agreements If third-party vendors developed portions of the application, processes must be put into place to incorporate upgrades or corrections.

The major objectives of determining maintainability requirements are as follows:

  • Maintainability requirements should be concerned only with modifications made between major releases or with new versions of the application.

  • Maintainability requirements should focus on corrections of minor defects, implementation of minor enhancements, and updates to the corresponding documentation.

  • Maintenance requirements should be specified quantitatively. For example, requirements should revolve around areas such as the time and expense needed to repair defects, system downtime, and staff requirements.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net