eXtreme Solution Design (XSD)
Documenting the architecture of a software solution’s design can be performed with agilityRoger HillSolution Architecture Design Methodologies
While in the company’s workout room at lunch one day, Jared Stivers, a Python programmer, was exercising on the machine next to me. He started a conversation by explaining that he was working on a project that seemed more challenging than he had previously experienced. He was accustomed to building small software applications with XP, but was wondering how it would work for a bigger project. The project would need to be partitioned into several manageable units with multiple developers working on the various pieces. How could the bigger project be controlled? How would he decompose the components and manage the higher risk of change with agility? Could he still apply the rules of eXtreme Programming? I framed my response to him by using terms with which he was familiar—the values and laws of agile software development. Abstract
Kent Beck invented eXtreme Programming (XP) as a lightweight methodology for software development. His intent was to reduce the development time and enhance the flexibility of developing quality software solutions in a team environment. His work has also spawned a new approach to software analysis and design, called “agile.” The term “agile” refers to the ability of the methodology to accommodate change during the development process. The capacity to change, to refactor the solution, is embedded in the use of story cards as the mechanism to capture the business requirements. Similar to Ivar Jacobson’s Use Case approach to OOSE (Jacobson, 1992), eXtreme Programming relies on the story. The metaphor of the business is captured as a set of story cards that define the required business functionality, and is backed up with data that is defined as domain objects. Traditionally, software development practices focused on complete and thorough up-front architecture because the development of the solution was costly, time consuming, and inflexible. With eXtreme Programming, the cost and schedule for delivery of a system is greatly reduced, and the flexibility of the delivered application is significantly enhanced. With the focus on rapidly prototyping a possible solution, there is a tendency to jump to a solution, and quickly hack out something to show the customer. By applying the principles and practices of eXtreme Solution Design, programming teams can take the “hack” out of rapid development and deliver an integrated collection of software services. eXtreme Values
Jared was familiar with Scott Ambler’s five values of Agile Modeling. I leveraged his knowledge by showing how the values he was accustomed to applied to small software application development projects; namely communication, simplicity, feedback, courage, and humility (Ambler, 2006); also apply to an extreme solution design approach for larger development projects. In XSD, models are the key element in communicating understanding. A semantically accurate model communicates business facts that are compileable into data and/or methods at the lower implementation levels of system definition. The models should be tested via customer walk-throughs and by playing the models together. For example, the stories need to be reconciled with the domain object model and the analysis model to verify that those models fully support the requirements of the metaphors. This is a form of early user testing that is paramount to maintaining an agile development environment. Continue reading
|
