SOFTWARE SYSTEM DESIGN AND MAINTENANCE

Modules/Module4/Mod4Home.html

Module 4 - Home

Software System Design and Maintenance

Modular Learning Outcomes

Upon successful completion of this module, the student will be able to satisfy the following outcomes:

• Case
  • Explain why documenting a system design is useful to the system development process.
  • Identify the dynamics of testing a system.
• SLP
  • Define what is meant by system evolution and how its characteristics affect maintenance.
• Discussion
  • Discuss quality measure to maintain a system.
  • Integration and Reflection.

Module Overview

System Design and Testing

Module 4 focuses on the process by which the requirements are translated into a system design to deliver a software product. A good design is one that describes a system able to meet all of the requirements and user needs; however, other high-level concepts in design are important. For example, it is essential that a software application design be adequate for long-term intended use and also consider components of reusability and modifiability. Lower level concepts such as modularity and abstraction are also used to measure characteristics of design and to allow general guidelines to evaluate quality and maintainability. 

Planning the design includes devising and maintaining a workable scheme to ensure that all requirements are addressed during the design phase and not during coding or testing. Design includes several plans such as working with users to decide how system interfaces, reports, and screens best fit user needs for acceptance. This may require developing several prototypes to show users the possibilities, to determine how performance requirements can be met, or to evaluate the best look and feel. To account for quality conditions on the project and in the organization, project teams often make decisions to increase fault tolerance. Another goal is to anticipate potential faults that may occur and design the system in ways that minimize disruption to the user. Design also emphasizes collaboration with other developers through the software life cycle. Also, since designs are built from components, the interrelationships among components and data must be well-documented. Cross-referencing may be necessary to help explain which parts of the design affect what components and data. Other developers should also participate in design reviews, evaluating the design at several stages and making suggestions for improvement.

Testing an application includes coordinating with the project team and developers to carry out the various test plans as shown in Figure 4-1. Unit testing is very different from integration testing. The developer performs unit testing of each components and has complete control over the testing process. The developer creates the test data, designs the test cases, and runs the tests. When integrating components, the developer sometimes works individually, but often collaborates with a small part of the test and development team; however, when testing a system, the developer works with the entire development team and designated users coordinated and directed by the test team leader.

Figure 4-1. Test Planning

Delivering the System

This module also discusses the need for training and documentation, which are two issues key to successfully transfer the system from developers to users. Even with turnkey systems (where the developers hand over the system to the user and are not responsible for its maintenance), delivery involves more than putting the system in place. It is during training when the development team helps users to understand and feel comfortable with the product. If delivery is not successful, users will not use the system properly and may be unhappy with its performance.

As the system is being designed, training materials are developed to help users learn to use the system. Accompanying training guides is documentation to help user navigate through problem-solving. Training and documentations should be done from two perspectives: the user and the operator. Sometimes, the same person is both user and operator. Something to consider is that user and operator tasks have very different goals, so the training for each job should emphasize different aspects of the system. Training can be done in many ways. At some point, if users forget how to access a file or use a new function, training should include steps to locate components and troubleshoot. Formal documentation, icons and on-line help, demonstrations and classes, and expert users are examples of training aids that are very helpful when a new system is implemented.

System Maintenance

Implementing a system in production does not mark the end of the software developers' involvement. Rather, many systems require continuous change, extending even past delivery. Software maintenance deals with managing change in this part of the lifecycle. Performing maintenance requires its own skill set, in addition to those required for software development. Maintenance personnel are usually programmers and analyst who interact continually with colleagues and users to effectively define problems and find solutions. Maintainers need to be good detectives, testing software thoroughly and hunting down the sources of failure. They also need to understand the “big picture” of how systems with complex interactions interoperate with the environment.

Another important technique is software rejuvenation, which may involve reverse engineering to re-document restructure, and reengineer an existing system. The overall goal is to make hidden information explicit, so that it can be used to improve the design and structure of the code. Although complete rejuvenation is unlikely in the near future, it is being used successfully in mature domains like the Department of Defense, IRS, insurance companies, and aerospace where legacy systems are still efficient but are too complex to re-write from scratch.

Privacy Policy | Contact