- 1: Start Development with Software Requirements
- 2: Honor Your Users and Communicate with Them Often
- 3: Don't Allow Unwarranted Requirements Changes
- 4: Invest Up Front in Software Architecture
- 5: Don't Confuse Products with Standards
- 6: Recognize and Retain Your Top Talent
- 7: Understand Object-Oriented Technology
- 8: Design Web-Centric Applications and Reusable Components
- 9: Plan for Change
- 10: Implement and Always Adhere to a Production Acceptance Process
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
9: Plan for Change
The best developers and architects plan for change during all phases of the software lifecycle. During the course of an average one-year development cycle, not only will the design be subject to change, but so will the user requirements, the development tools, the third-party software libraries, the DBMS system, the operating system, the hardware, the network, the programmers, and many other aspects of the application that can't possibly be foreseen or otherwise planned for. Some aspects of change, such as a new release of the operating system, can certainly be planned for by discussing schedules with the vendor and making a decision whether a new release should be installed or not. Sometime during the application's life, however, the underlying operating system will probably have to be upgraded, so it's really just a matter of when changes such as these are made. In either case, you still have to plan for the changes.
The longer the expected project lifetime, the more important it is to plan for change. The Cassini mission to Saturn, operated by JPL, was launched in October of 1997. With any luck, the spacecraft will enter orbit around Saturn in 2004. The JPL engineers running the Cassini ground station definitely must plan for changes in hardware and software prior to the spacecraft's encounter with Saturn in 2004. Any company that designs an extended-lifetime product with an embedded hardware and software component must pay careful attention to planning for change. Back down on earth, for instance, every high-end Xerox printer contains an embedded workstation controller. Typically these workstations are commercial off-the-shelf products with an average lifespan of 18 months. Xerox high-end printers are designed for 5–10 or more years of continuous operation. Xerox must plan for change in the embedded workstation components for each of its printer lines.
There are many ways to plan for change. For starters, allow extra budget and schedule in your project for unforeseen changes. At the start of the project, work to clearly identify all risk items that could lead to a possible change somewhere in the future. During the design, look for ways to mitigate the risk of a change further downstream. At the coding level, look for ways to quickly and easily set up code to be adapted to new situations and events within your business. For instance, use tabular definitions whenever possible versus hard-coding these parameters into your code.