At the Fraunhofer Center-Maryland software-engineering research facility, we use application development, feedback, and learning techniques to improve software-development technologies for our clients, which include the Department of Defense, NASA, Boeing, DaimlerChrysler, Motorola, Nokia, and local software companies in Maryland. One of the facility's primary assets is the Visual Query Interface software system, used to visualize data.
A couple of years ago, it became clear that the VQI system couldn't take any more change. The effort of adding functionality to the then-3-year-old system consistently exceeded expectations. A quick analysis revealed that most of the VQI modules were highly coupled to each other. Also, no one dared touch several chunks of "half-dead" code because of the risk of introducing errors, and code was placed in modules where it didn't belong.
We deemed it too expensive and time-consuming to replace the system by rewriting the code from scratch. Instead we designed a new architecture and reused most of the code, saving roughly 12 worker-months and six calendar months compared with replacement time and effort. We removed code that wasn't used and introduced design patterns to make the architecture flexible. We formed components and moved the code into the right place. And we made it easy to add new components.
We also changed our process to better sustain the software. We needed to protect our software investment and explicitly ensure that changes were implemented correctly; otherwise we ran the risk of ending up where we started: with unsustainable code.
Our organization comprises about 15 full-time people, but we have high developer turnover because we frequently use temporary programmers. Developers are typically assigned a feature-oriented task for which they design and implement a solution. We have found that the implementation often deviates from our plans, causing the software to decay quickly. We needed a way to match the planned architecture and implementation so we could detect violations and correct them.
Our solution was to actively sustain the software. We did this by following these steps:
1. Define and document the architecture.
2. Make sure the developers understand the architecture.
3. Implement a process to evaluate the implementation without reviewing all the code.
Our evaluation approach is based on architectural guidelines, components, and their connectors. By applying the process as part of the regular development effort, we can ensure that the software is architecturally sound.
—Mikael Lindvall is a scientist at the Fraunhofer Center for Experimental Software Engineering Maryland and a member of the SEI sustainment project headed by Robert Seacord.
