Software Architecture
 Architecture Documentation |
|
Software Architecture |
||||
|
||||
| Architects and Process | ||||
Architects are often passionate about software development methods. This makes sense because they are passionate about building well-structured systems and want the best possible odds for getting it done. Being control-freak alpha-geek types they like methods as a vehicle for spreading the word about how things should be done, and enforcing standards as projects proceed. It takes discipline to build strongly architected systems, and solid methodologies lay out the steps.
I am a fan of the Rational Unified Process. My first experience with RUP was in 1996 with a Beta version of the process before it was released to the world. Rational trainers and mentors helped us through a full cycle of object oriented analysis, design and development. In the years since then I have been on a number of teams using parts of the process with varying degrees of rigor, and was convinced that following the process more completely pays off.
In 2002, I helped our team experiment with story driven development, bringing the best of our RUP traditions into a more agile form. I wrote this process overview as a proposal, sold it to the team, and led the transition. I recently updated most of it to reflect what we really do. We found that story planning gave us much better estimates, work plans and tracking, and the iterative approach greatly reduced defects. The customers enjoyed the planning game sessions, and came away with better confidence that we understood what they wanted.
The beating heart of process is requirements. They are at the center of every phase of the project.
Starting from high level business needs we work down to system features, essential system requirements and use case descriptions of how people interact with the system. From those we derive concrete software requirements. We maintain traceability so we can prove that every requirement meets a business need and every feature is fully realized.
Using Rational's Requisite Pro we manage requirements in a traceabilitiy matrix stored in a database. Managers allocate features to releases and assign requirements to developers. Developers design and build to requirements and communicate which ones are ready for test. Testers write test plans to verify that every requirement is met. Release managers query the status of requirements to know when a release is ready to ship. Customers sign off requirements to indicate user acceptance.
Change control for all important artifacts of a system is critical, too. Managing requirements leads the battle against scope creep. This includes controlling the flow of change requests for defects, enhancements and so on. Managing and monitoring changes in design and implementation artifacts helps keep things focused and on track.
With our story-driven approach, any new requirement, change or defect correction becomes a story, and feeds into the iteration plan like any other.
| Architecture Documentation |
