1.6 Incremental Development and Deployment


The major case study in this book involves incrementally replacing a system through a series of white-box modernizations. Each of the counterforces introduced in this chapter was applied at various times to the overall effort.

Incremental development reduces overall program risks by allowing both users and developers to gradually understand the new system. Lessons learned from each increment can be applied to prevent mistakes in later increments. Smaller steps are typically easier to manage and to evaluate. Smaller increments can also result in a more focused effort.

Theoretically, building a system in a single increment minimizes development and deployment costs because it is necessary to test and deploy only a single system. The costs of system testing and deployment are fixed costs that are largely independent of the size of the increment, and are incurred for each increment. In practice, a single development/deployment cycle does not typically lower development costs, because of the complexity of completing the entire project at one time.

Incremental development is also likely to influence the target architecture toward resembling the legacy architecture. This occurs when the legacy system is separated into functional increments along lines dictated by the legacy architecture. As the number of increments increases and the corresponding size of each increment decreases, legacy and modernized architectures tend to converge.

A componentization strategy that defines new components and how they interact with legacy components to maintain existing functionality during the development period is also part of the overall strategy. Certain componentization strategies may require the database to be iteratively restructured. Restructuring the database has implied costs, including rework and the need to migrate the "new" legacy data after each increment.

To be successful, this strategy must consider the future of the programmers who have maintained these legacy systems for years . These programmers must be involved as stakeholders in defining the strategy. There should be a plan to enable them to come up to speed in the new technology while they are maintaining the legacy system. Legacy system programmers will more willingly collaborate if they have a clear role in the new system.



Modernizing Legacy Systems
Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices
ISBN: 0321118847
EAN: 2147483647
Year: 2003
Pages: 142

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