|
 |
 |
Software Architecture & Design
Software architecture forms the backbone for building successful software-intensive systems. Architecture largely permits or precludes a system's quality attributes such as performance or reliability. Architecture represents a capitalized investment, an abstract reusable model that can be transferred from one system to the next. Architecture also represents a common vehicle for communication among a system's stakeholders, and is the arena in which conflicting goals and requirements are mediated. The right architecture is the key to software project success. Conversely, the wrong one is a sure road to failure.
The software design standards used by EEI are based on the Rational Unified Process or RUP. RUP is an object oriented, iterative methodology for designing software intensive systems. In an iterative methodology, processes are repeatable. The process is coupled with specific Technical Standards of platforms, languages and other key technical aspects of building software intensive systems.
There are two main design artifacts produced by EEI:
1. Software Requirements Specification (SRS). The Software Requirements Specification is a high-level technical paper consumable by non-technical people. It is typically created by a business analyst or analysts and reviewed by a team of piers. After a satisfactory review, the SRS is passed to a Program Manager and Development Team. 2. Software Architecture Document (SAD). This is a well-known template from the arsenal of the Rational Unified Process. The Software Architecture Document is created by the development team under the direction of the Program Manager while consulting the Software Requirements Specification. Design Standards and Guidelines – The design standards used by EEI are based on the RUP iterative methodology for designing software intensive systems. It is important to distinguish between Standards and Guidelines. Standards must be adhered to while guidelines give a certain direction. For example, it is a standard to produce a Software Architecture Document in the RUP methodology but it is a guideline to use a UML based tool.
Design Methodology – Our design methodology uses a model for describing the architecture of software-intensive systems, based on the use of multiple, concurrent views (the 4+1 approach). The use of multiple views allows us to separately address the concerns of the various stakeholders of the architecture including end-users, developers, systems engineers, project managers, etc., and to handle separately the functional and non functional requirements. Each of the five views is described, together with a notation to capture it. The views are designed using an architecture-centered, scenario driven, iterative development process.
In a 4+1 approach there are four main technical views into the system:
- Logical View
- Implementation View
- Process View
- Deployment View
The "4+1" is the business driver or the Business View also referred to as the Use Case View. An additional view is optional, the Data View which is required for systems having persistent data.
Design Artifacts - There are two main standard artifacts:
1. Approach Paper. The Approach Paper is a high-level technical paper consumable by non-technical people. The purpose is to provide a high-level description of the technology direction of a project around the time Business Requirements and Functional Specifications are stabilized. 2. Software Architecture Document (SAD) This is a well-known template from the arsenal of the Rational Unified Process. The SAD implements an objected oriented, 4+1 approach to the design of software intensive systems with a strong emphasis on completeness. Aspects of the system to be developed are addressed at the design phase.
|
