Software architectural design produces finished structures as deliverables.
The software architecture process itself is nonlinear and requires multiple,
parallel development paths and iterations. During the development process,
dependencies on a vendor product, a technology, or the impact of new technology
or client business practices in response to changing economic conditions
may require changes to the architecture. Software architecture is a living
process that is closely coupled with the full life-cycle of a project.
Software architecture is the fundamental organization
of a system embodied in its components, their relationships to each
other and to the environment, and the principles guiding its design
Source: IEEE Standard 1471:2000 - Recommended Practice
for Architecture Descriptions of Software-Intensive Systems
IEEE Standard 1471:2000 provides a framework for describing an architecture.
The architectural description is based on the terminology of IEEE Standard
1471, a recommended practice, that presents consensus elements of good
practices in describing architectures. There are five core compliance
elements that must be met by an architectural description:
- Identifying the stakeholders of the system and their architectural
- Selecting and defining viewpoints to address those concerns
- Documenting views of the architecture satisfying those viewpoints
- Recording any known inconsistencies between views
- Providing rationale for architectural decisions made in the architectural
IEEE 1471 concentrates on describing architectures through views, which
are mapped to specific viewpoints:
- Viewpoints are the reusable parts of architectural descriptions
- Architectural descriptions require multiple views
- Views describe the system from the perspective of the systemís stakeholders
- The contents of views should be described by a Platform/System Independent
Architecture-Driven Software Construction
ASR Strategic Resources is active in promoting software architecture
through the Association of Information Technology Professionals (AITP)
and the Worldwide Institute of Software Architects (WWISA).
Our enterprise architecture doctrine recognizes eight core architectural
activities within two major software construction phases:
Pre-Design documents the needs of the
client and defines the scope of the project.
Key design points, requirements, and processes are examined within the
context of the project. Available resources
are assessed including financial and intellectual capital.
Domain Analysis documents the business
and technology environment in detail. Project scope and client expectations
are defined. Domain experts provide specialized knowledge for key issues
such as technology choices, infrastructure details, and implementation
approaches as well as client business workflows.
Schematic Design documents the structure
of the system by combining graphical notations such as UML with linear
(text) notation. Items such as the system's look and feel, workflows,
transformations, data stores, and deployment characteristics are described
in detail. Enough detail is provided for proof of
concept and prototype builds.
Design Development documents the
final design of the system in detail. Client requirements are
mapped out and defined with sufficient detail to provide a benchmark
against which client expectations can be validated
regarding the design and implementation.
Project Documents consist of the artifacts
required by the people that will actually build the system including
budgets, resources, roles, construction sequences, tools, methods, and
Staffing and Contracting identifies
who will play a role in building the solution internal staff, contractors,
or outsource services. Bids are issued, selected, and awarded. Contract
details, project costs, resources are assigned (both human and material),
and the sequence of development activities are worked out in detail.
Construction is supervised by the architectural
team, which in turn is managed by a chief architect who bears overall
responsibility for maintaining design integrity and the design vision.
Design reviews and change requests are evaluated, managed, approved,
and documented by the architecture team.
Post Construction is supervised by
the architecture team with regard to rollout. Migration, warranty, training,
and maintenance issues are coordinated and overseen by the architectural
team as well.
ASR Strategic Resources is experienced with a number of standard software
architecture models and frameworks including:
- Zachman Framework
- ISO/IEC 10746-3 RM-ODP (Reference
Model of Open Distributed Processing)
- Kruchten 4+1 View Model (Unified Process)
- C4ISR Architecture Framework (Command,
Control, Communication, Computers, Intelligence,
Surveillance, and Reconnaissance)
ASR Strategic Resources has adopted the Unified Modeling Language (UML)
for graphical notation. Because the Unified Process and UML have a number
of shortcomings, we supplement them with additional notations and architectural
frameworks. UML is supplemented by Object Constraint Language (OCL) and
linear (textual) notations to provide detailed design information. Our
architectural practices rely heavily on code generation technology to
automate the development process. The use of linear notations and Architecture
Definition Languages (ADL) provide a code generation mechanism. UML by
itself, or even in conjunction with OCL, is not capable of providing the
detail necessary to support automatic code generation.
ASR Strategic Resources uses a number of enterprise tools to support
our architectural development process. Our internal tools are built around
our Auldenfire Atelier framework and include Auldenfire Legion. External
tools include Rational Rose Enterprise Edition and Computer Associates