Software design review is an excellent way to keep your software architecture in check and inspect how your teams work. The primary goal of an architectural review is to increase the quality and security of your software by spotting faults before release. Therefore, reviewing the software architecture will help you make high-level decisions like:
- What structure is the team going with?
- What style is the developer going to use?
- What functions will the software perform?
- How will the structural components of the architecture perform?
- Will the software meet the needs of all the stakeholders?
Performing Architectural Reviews
You can review the architecture for your existing software with the following key factors.
You can measure the time your application takes to respond to events in a time interval by observing performance-related architectural principles like:
- Pooling connections
- Balancing load
- Processing distribution
A typical unit of measure could be using specific changes as benchmarks and cross-referencing them with the expense of making the changes.
Performing Design Reviews
Development teams can conduct a comprehensive, systematic, and well-documented inspection of the software design to determine if the software meets specific design requirements or not. A design review also helps in identifying problems in the design process. Typically, the design review process consists of three steps:
Preliminary design review
The team reviews high-level architectural design to determine if the design meets the state and non-functional requirements or not. In simple terms, a preliminary review is conducted to see how well the design:
- Ensures software requirements are reflected in the architecture
- Specifies whether effective modularity is achieved
- Defines interfaces for modules and external system elements
- Ensures data structure remains consistent with the information domain
- Ensures maintainability
- Assesses quality factors
Members of a review team
Organizations formally create a review team, in which every member acts as an independent individual authorized to make comments and decisions where necessary. The team also verifies if the proposed design includes the essential hardware and interface with other computer-based systems. An ideal review team will contain the following members:
Since organizations design software and solutions to meet the needs of their customers, they define the software’s requirements and utility.
A moderator presides over the review, encourages discussions, maintains the main objective throughout the review, and plays an active role in settling disputes without bias.
The secretary remains a silent observer who does not participate in the review process but records the meetings and can provide input if required.
- System designers
Individuals who are not only responsible for designing the software, they also manage the entire computer-based system for the organization.
The review team also contains developers who are not actively involved in the project and can provide an outsider’s view on the design and address consistency issues.
The review team notes the errors they discover in their process and then assesses the faults according to their severity. If the faults are minor, they can be resolved by the review team, but if the design has major faults, the team may agree to have the proposed conceptual design revised by the designers. The preliminary design review process is repeated until the review team approves the design concept.
Critical design review
After completing the preliminary design review and satisfying the customers with the proposed design, the team conducts a critical design review. The purpose of this review is to:
- Ensure that there are no defects in the technical and conceptual designs
- Verify that the design under review satisfies the requirements that were established in the architectural design specifications
- Critical evaluation of the functionality and maturity of the design
- Justify the design to the stakeholders and make the technical design more precise, effective, and easily understandable
During a critical design review, the team creates diagrams to evaluate alternative design Strategies and major design decisions. Similar to the preliminary design review, a team of independent individuals is also formed to conduct a critical design review. The following individuals are a part of this team:
- System tester
An individual that understands the technical issues related to design and compares with similar projects
The person who is responsible for documenting the software
- Program designer
A person who understands design and is capable of driving detailed program designs
If the critical design review team uncovers discrepancies in the review, they start assessing the faults as per their severity. The team resolves all minor faults, but the team may agree to revise the proposed technical design through the development team if there is a major fault. The review team may repeat this process to verify that the device design needs the customer’s expectations.
Program design review
Organizations conduct a program design review to obtain feedback before developers base the coding on the design. Therefore, a program design review helps the development teams in:
- Determining the feasibility e of the detailed design
- Ensuring interface consistency as per the architectural design
- Specifying if the design is compatible with the implementation language
- Ensuring that structured programming is used throughout the design
- Ensuring that the development team understands the required design
The program design review team comprises system designers, program designers, developers, a system tester, an analyst moderator, and a secretary. After completing the design for the program, the program designers present their plans to a different team for comments and suggestions on their design. After completing a product design review, the team forwards the project to the developers.
Design review process
Design review is integral to secure software development as the teams can logically view various software components before release. After the software design is ready for review, the Criterion includes the following steps:
- Selecting members for the design review team, assigning the rules, and preparing schedules for review.
- Distributing the software package to the participants for review.
- Checking for completeness and compliance with the desired requirements while disturbing the efficiency of the design. The team also checks for defects; if found, they can choose to resolve the issues themselves or ask the designers to make the desired changes.
- After the review team improves the design, the Software Development Manager gets the design approved by the project manager before further development takes place. Replicating data
- Processing isolation between OLTP and OLAP
A typical unit of measurement could be:
- Transactions per unit
- Competition time
You can measure the ability of the system to maintain its operations even with system errors or incorrect usage by observing reliability-related architectural principles like:
- Using preventive measure
- Recycling server processes
- Containing server processes
- Logging transactions to build a database
A typical unit of measure could be the mean time to failure.
You can measure the portion of time the system remains active by observing availability-related architectural principles like:
- Responding to server failover
- Managing transactions
- Operating in a stateless environment
A typical unit of measure could be:
- Time interval between failures.
- Time taken by the server to recover from a failure.
You can measure your software’s ability to resist unauthorized attempts of usage and Denial of Service attacks by observing security-related architectural principles like:
- Identifying and authenticating users
- Authorizing access to resources
- Auditing security policies
- Ensuring data integrity
- Ensuring data confidentiality
- Ensuring continuity of services during a Denial of Service attack
You can measure the software’s ability to make instant and cost-effective changes by observing modifiability-related architectural principles like:
- Separating concerns of client and server
- Implementing change independent of the interface
- Separating data and functions
- Encoding functions into meta-data
- Interpreting languages
- Discovering run-time hard-coded connections
Architectural reviews are essential for an efficient work process. You can increase the security and quality of your software by noticing faults as they occur. Here, we’ve summarized the processes of preliminary, critical, and program design reviews to help you secure your software development. Best of luck!