SPPM Artifacts and Phases
SPPM Artifacts and Phases
SPPM Artifacts and Phases
attention to robustness, performance, and finish. A modern software development process must be
defined to support the following:
• Evolution of the plans, requirements, and architecture, together with well defined
synchronization points
• Risk management and objective measures of progress and quality
• Evolution of system capabilities through demonstrations of increasing functionality
The transition between engineering and production is a crucial event for the various stakeholders.
The production plan has been agreed upon, and there is a good enough understanding of the
problem and the solution that all stakeholders can make a firm commitment to go ahead with
production. Engineering stage is decomposed into two distinct phases, inception and elaboration,
and the production stage into construction and transition. These four phases of the life-cycle
process are loosely mapped to the conceptual framework of the spiral model as shown in Figure
5-1
PRIMARY OBJECTIVES
• Baselining the architecture as rapidly as practical (establishing a configuration-managed
snapshot in which all changes are rationalized, tracked, and maintained)
• Baselining the vision
• Baselining a high-fidelity plan for the construction phase
• Demonstrating that the baseline architecture will support the vision at a reasonable cost in
a reasonable time
ESSENTIAL ACTIVITIES
• Elaborating the vision.
• Elaborating the process and infrastructure.
• Elaborating the architecture and selecting components.
ESSENTIAL ACTIVITIES
• Resource management, control, and process optimization
• Complete component development and testing against evaluation criteria
• Assessment of product releases against acceptance criteria of the vision
PRIMARY EVALUATION CRITERIA
• Is this product baseline mature enough to be deployed in the user community? (Existing
defects are not obstacles to achieving the purpose of the next release.)
• Is this product baseline stable enough to be deployed in the user community? (Pending
changes are not obstacles to achieving the purpose of the next release.)
• Are the stakeholders ready for transition to the user community?
• Are actual resource expenditures versus planned expenditures acceptable?
Design Set
UML notation is used to engineer the design models for the solution. The design set
contains varying levels of abstraction that represent the components of the solution space (their
identities, attributes, static relationships, dynamic interactions). The design set is evaluated,
assessed, and measured through a combination of the following:
• Analysis of the internal consistency and quality of the design model
• Analysis of consistency with the requirements models
• Translation into implementation and deployment sets and notations (for example,
traceability, source code generation, compilation, linking) to evaluate the consistency and
completeness and the semantic balance between information in the sets
• Analysis of changes between the current version of the design model and previous versions
(scrap, rework, and defect elimination trends)
• Subjective review of other dimensions of quality
Implementation set
The implementation set includes source code (programming language notations) that
represents the tangible implementations of components (their form, interface, and dependency
relationships) Implementation sets are human-readable formats that are evaluated, assessed, and
measured through a combination of the following:
• Analysis of consistency with the design models
• Translation into deployment set notations (for example, compilation and linking) to
evaluate the consistency and completeness among artifact sets
• Assessment of component source or executable files against relevant evaluation criteria
through inspection, analysis, demonstration, or testing
• Execution of stand-alone component test cases that automatically compare expected results
with actual results
• Analysis of changes between the current version of the implementation set and previous
versions (scrap, rework, and defect elimination trends)
• Subjective review of other dimensions of quality
Deployment Set
The deployment set includes user deliverables and machine language notations,
executable software, and the build scripts, installation scripts, and executable target specific data
necessary to use the product in its target environment. Deployment sets are evaluated, assessed,
and measured through a combination of the following:
• Testing against the usage scenarios and quality attributes defined in the requirements set
to evaluate the consistency and completeness and the~ semantic balance between
information in the two sets
• Testing the partitioning, replication, and allocation strategies in mapping components of
the implementation set to physical resources of the deployment system (platform type,
number, network topology)
• Testing against the defined usage scenarios in the user manual such as installation, user-
oriented dynamic reconfiguration, mainstream usage, and anomaly management
• Analysis of changes between the current version of the deployment set and previous
versions (defect elimination trends, performance changes)
• Subjective review of other dimensions of quality
Each artifact set is the predominant development focus of one phase of the life
cycle; the other sets take on check and balance roles.
As illustrated in Figure 6-2, each phase has a predominant focus: Requirements are the
focus of the inception phase; design, the elaboration phase; implementation, the construction
phase; and deployment, the transition phase. The management artifacts also evolve, but at a
fairly constant level across the life cycle. Most of today's software development tools map
closely to one of the five artifact sets.
1. Management: scheduling, workflow, defect tracking, change management,
2. documentation, spreadsheet, resource management, and presentation tools
2. Requirements: requirements management tools
3. Design: visual modeling tools
4. Implementation: compiler/debugger tools, code analysis tools, test coverage analysis
tools, and test management tools
5. Deployment: test coverage and test automation tools, network management tools,
commercial components (operating systems, GUIs, RDBMS, networks, middleware), and
installation tools.
Status Assessments
Status assessments provide periodic snapshots of project health and status, including the software
project manager's risk assessment, quality indicators, and management indicators. Typical status
assessments should include a review of resources, personnel staffing, financial data (cost and
revenue), top 10 risks, technical progress (metrics snapshots), major milestone plans and results,
total project or product scope & action items
Environment
An important emphasis of a modern approach is to define the development and maintenance
environment as a first-class artifact of the process. A robust, integrated development environment
must support automation of the development process. This environment should include
requirements management, visual modeling, document automation, host and target programming
tools, automated regression testing, and continuous and integrated change management, and
feature and defect tracking.
Deployment
A deployment document can take many forms. Depending on the project, it could include several
document subsets for transitioning the product into operational status. In big contractual efforts in
which the system is delivered to a separate maintenance organization, deployment artifacts may
include computer system operations manuals, software installation manuals, plans and procedures
for cutover (from a legacy system), site surveys, and so forth. For commercial software products,
deployment artifacts may include marketing plans, sales rollout kits, and training courses.
Architecture Description
The architecture description provides an organized view of the software architecture under
development. It is extracted largely from the design model and includes views of the design,
implementation, and deployment sets sufficient to understand how the operational concept of the
requirements set will be achieved. The breadth of the architecture description will vary from
project to project depending on many factors. Figure 6-10 provides a default outline for an
architecture description.