Chapter 6
Software Design Concepts and Principles
On 11/1/202X, the DH development team, after establishing what the team felt was a solid set of requirements as specified by the DH software requirements specifications (SRS), held a team meeting to discuss the next step in the development process. In the meeting, Team Leader Disha Chandra made the point that the Homeowner organization had learned from previous project failures that they needed to have a greater emphasis on the design phase of the DH project. Disha asserted that a lack of effort in this phase typically results in major issues in meeting project deadlines and budgets, as well as a lack of overall quality in the system produced.
During the meeting, Disha asked Yao Wang, the System Architect, to give an overview of the design process and some of the challenges typically encountered in such a process.
Yao started with a description of the DH design phases, listed in Table 6.1 (extracted below from Table 2.2 in Chapter 2):
Architectural Design |
|
Construction Increment 1, 2,... |
|
■ First, they would develop a software architecture for the DigitalHome.
■ Then, they would use the architectural model to develop a plan for building and integrating the increments of the system.
■ Finally, they would construct each increment and integrate it into the system.
Yao announced that he would be delivering several short tutorials on software design. He stated he was a little wary about this since the team had extensive design experience; but he felt it would be good to review some basics and emphasize key concepts – heads were nodding as he spoke.
Software Architecture
After Yao Wang delivered his introductory tutorial on design concepts and principles, he explained that while defining a software architecture that ensures addressing the functional requirements (i.e., that the system does what it is supposed to do), it is just as important that the system architecture ensures the inclusion of the non-functional requirements (quality attributes) of the system such as performance, reliability, security, availability, testability, and modifiability. Yao also explained that architecture differs from lower-level design in the sense that architecture tackles the overall structure and behavior of a system as bounded by a set of software requirements, while lower-level design decisions are those made by developers to design system modules that maintain the overall architectural decisions made earlier in the architecture phase.
Next, Yao prepared and delivered a tutorial on development of a software architecture.
Architecture Views and Styles
After specifying the set of system requirements in the SRS document and arriving at a set of quality attribute scenarios, the next step for the DH development team is to establish the path for moving from the requirements phase to establishing a system architecture. System Architect Yao Wang called for a meeting where Wang expressed the importance of developing and documenting a system architecture that can be useful for the multiple stakeholders of the system. In his listing of those stakeholders he included:
■ Customers
■ Users
■ Marketing personnel
■ Managers
■ Development team members
■ Maintenance personnel
■ Independent V&V personnel
Yao asked for suggestions on how to proceed with representing an architecture that could be used by all these entities, who have different sets of expertise, technical knowledge and language, and varying concerns. Georgia Magee suggested that the team come up with a priority of the stakeholders and address the needs for the top three. This was not acceptable by the team lead. Disha Chandra made the point, that since this is a prototype system, the concerns of all stakeholders must be adequately addressed and represented. Michel Jackson suggested that the team come up with a very general architecture that could be understood and used by all stakeholders. This suggestion was also rejected. Yao Wang indicated that an architecture must be detailed enough to ensure correct modular and detailed design and implementation by downstream developers. Finally, Yao suggested that the team use what is known as “architecture views” and “architectural styles” to represent the system in different ways, each of which is suitable for a set of stakeholders. Since not all the team was familiar with architectural views and styles, he offered to prepare and present a mini-tutorial on the subject.
Object-Oriented Design
After the DH Team selected and described the architectural styles for the DH system, Yao Wang began a discussion of which design paradigm should be used to implement the styles selected. The team was in universal agreement that they should use an object-oriented design approach. Just to make sure the team had a common and accurate understanding of objected-oriented design features, Yao led a discussion of the features.
Design Verification
As the team was completing its initial draft of the SDS, Yao Wang, the System Architect, led the team in discussion of the procedure they would use in verifying the SDS. He reminded the team that the term “verification” referred to the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase (e.g., the design documents cover all the requirements in the SRS). He delivered a short tutorial on design verification. Note: Chapter 3 contains additional material validation and verification activities performed throughout the development life cycle.
Software Reuse and Design Patterns
In April 202X Jose Ortiz, the Director, DigitalHomeOwner Division of HomeOwner Inc, met with the DH development team to emphasize a desire within management to improve on the organization’s meeting of its deadlines and schedules. In the meeting, Jose asked the team to suggest ideas to ensure that delivery and deployment of systems for potential clients is done in a more rapid manner.
After a session of brainstorming, Disha Chandra suggested that the team employ more of software reuse. She highlighted the need for reuse of already developed artifacts at all phases of development. She also asked that the team suggest ways not to only reuse previously developed components, but as importantly, to develop artifacts with the vision of using them in future systems.
To achieve these goals, the team recognized that they must put more focus on designing systems for change, and at the same time making use of already established reuse methodologies such as architecture views, styles, and design and code patterns.
Documenting Software Design
In early November 202X, the DH development Team Leader Disha Chandra sends an e-mail to the rest of the DH Team emphasizing the importance of documentation for the DH software development artifacts. In the e-mail, Disha thanked the team for doing a great job in documenting the system requirements in the SRS document. She made the point that the same level of rigor must be used when producing the rest of the artifacts. Disha stressed the importance of such documentation, especially when it comes to the architecture. She noted that she planned to have a meeting to discuss how IEEE Std 1016™-2009, IEEE Standard for Information Technology—Systems Design—Software Design Descriptions, and the Software Engineering Body of Knowledge (SWEBOK) [Bourque 2014] should influence the documentation of the DH design.