Department of Software Engineering

JIGJIGA University
Software Process Management
Hand-out of Chapter 2
LIFE CYCLE PHASES AND ARTIFACTS OF THE PROCESS

INTRODUCTION
 Characteristic of a successful software development process is the well-
defined separation between "research and development" activities and
"production" activities. Most unsuccessful project:; exhibit one of the following
characteristics:
 An overemphasis on research and development
 An overemphasis on production.
 Successful modern projects-and even successful projects developed under the
conventional process-tend to have a very well-defined project milestone when
there is a noticeable transition from a research attitude to a production
attitude.
Earlier phases focus on achieving functionality. Later phases revolve around
achieving a product that can be shipped to a customer, with explicit attention to
robustness, performance, and finish.
 A modern software development process must be defined to support the
following:
1. Evolution of the plans, requirements, and architecture, together with well
defined synchronization points
2. Risk management and objective measures of progress and quality

3. Evolution of system capabilities through demonstrations of increasing

functionality

ENGINEERING AND PRODUCTION STAGES

 To achieve economies of scale and higher returns on investment, we must move
toward a software manufacturing process driven by technological improvements in
process automation and component based development. Two stages of the life cycle
are:
 The Engineering stage, driven by less predictable but smaller teams doing
design and synthesis activities.
 The Production stage, driven by more predictable but larger team~ doing
construction, test, and deployment activities.
 The two stages of the Life Cycle: Engineering and Production.

LIFE-CYCLE ENGINEERING STAFF EMPHASIS PRODUCTION STAGE

ASPECT EMPHASIS

Risk reduction Schedule, technical feasibility Cost

Products Architecture baseline Product release baselines

Activities Analysis, design, planning Implementation, testing

Assessment Demonstration, inspection, analysis Testing

Economics Resolving diseconomies of scale Exploiting economies of scale

Management Planning Operations

• 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.
INCEPTION, ELEBORATION, CONSTRUCTION, TRANSITION PHASES

INCEPTION PHASE
• The overriding goal of the inception phase is to achieve concurrence among
stakeholders on the lifecycle objectives for the project.

 Primary Objectives
• Establishing the project's software scope and boundary condition, including all
operational concept, acceptance criteria, and a clear understanding of what is and is
not intended to be in the product.
• Discriminating the critical use cases of the system and the primary scenarios of
operation that will drive the major design trade-offs.
• Demonstrating at least one candidate architecture against some of the primary
scenarios.
• Estimating the cost and schedule for the entire project (including detailed estimates
for the elaboration phase).
• Estimating potential risks (sources of un predictability)

ELABORATION PHASE
• At the end of this phase, the “Engineering” is considered complete.
• The elaboration phase activities must ensure that the architecture, requirements,
and plans are stable enough, and the risks sufficiently mitigated, that the cost and
schedule for the completion of the development call be predicted within an
acceptable range.
• During the elaboration phase, an executable architecture prototype is built in one or
more iterations, depending on the scope, size and risk.
Primary Objectives
• Base lining the architecture as rapidly as practical (establishing a configuration-
managed snapshot in which all changes are rationalized, tracked, and maintained)
• Base lining the vision
• Base lining 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.

CONSTRUCTION PHASE
• During the construction phase, all remaining components and application features
are integrated into the application, and all features are thoroughly tested.
• Newly developed software is integrated where required.
• The construction phase represents a production process, in which emphasis is placed
on managing resources and controlling operations to optimize costs, schedules and
quality.
Primary Objectives
• Minimizing development costs by optimizing resources and avoiding unnecessary
scrap and rework
• Achieving adequate quality as rapidly as practical
• Achieving useful versions (alpha, beta and other test releases) as rapidly as practical
 • 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.

TRANSITION PHASE
• The transition phase is entered when a baseline is mature enough to be deployed in
the end-user domain.
• This typically requires that a usable subset of the system has been achieved with
acceptable quality levels and user documentation so that transition to the user will
provide positive results.
• This phase could include any of the following activities:
• Beta testing to validate the new system against user expectations
• Beta testing and parallel operation relative to a legacy system it is replacing
• conversion of operational databases
• Training of user and maintainers
– The transition phase concludes when the deployment baseline has achieved
the complete vision.
• Primary Objectives
– Achieving user self-supportability
– Achieving stakeholder concurrence that deployment baselines are complete
and consistent with the evaluation criteria of the vision
– Achieving final produce baselines as rapidly and cost-effectively as practical.

THE ARTIFACT SETS

 To make the development of a complete software system manageable, distinct
collections of information are organized into artifact sets.
 Artifact represents consistent information that typically is developed and reviewed
as a single entity.
 Life-cycle software artifacts are organized into five distinct sets that are roughly
partitioned by the underlying language of the set: management (ad hoc textual
formats), requirements (organized text and models of the problem space, (design
models of the solution space), implementation (human-readable programming,
language and associated source files), and deployment (machine-process able
languages and associate files).
 The artifact sets are shown below

Requirement Design Set Implementation Deployment Set

Set Set

1. Vision 1. Design 1. Source code 1. Integrated product

documen Model(s) baselines executable
t 2. Test Model 2. Associated baselines
2. 3. Software compile- 2. Associated run-
Requirem architectur time files time files
ents e 3. Component 3. User Manual
Model(s) descriptio executable
n s.
 Management Set
Planning Artifacts Operational Artifacts

1. Work breakdown structure 5. Release descriptions

2. Business case 6. Status assessment
3. Release specifications 7. Software change order database
4. Software development plan 8. Deployment documents
9. Environment

PRAGMATIC ARTIFACTS

• People want to review information but don’t understand the language of the
artifact. Many interested reviewers of a particular artifact will resist having to learn
the engineering language in which the artifact is written.
• People want to review the information but don’t have access to the tools. It is not
very common for the development organization to be fully tooled; it is extremely
rare that the/other stakeholders have any capability to review the engineering
artifacts on-line.
• Human-readable engineering artifacts should use rigorous notations that are
complete, consistent, and used in a self-documenting manner. Properly spelled
English words should be used for all identifiers and descriptions. Acronyms and
abbreviations should be used only where they are well accepted. This practice
enables understandable representations, browse able formats (paperless review),
more-rigorous notations, and reduced error rates.
• Useful documentation is self-defining: It is documentation that gets used.
• Paper is physical; electronic artifacts are too easy to change. On-line and Web-
based artifacts can be changed easily and are viewed with more skepticism because
of their inherent volatility.

MODEL BASED SOFTWARE ARCHITECTURE

ARCHITECTURE: A MANAGEMENT PERSPECTIVE
 The most critical technical product of a software project is its architecture: the
infrastructure, control and date interfaces that permit software components to co-
operate as a system and software designers to co-operate efficiently as a tem. When
the communications media include multiple languages and inter group literacy
varies, the communications problem can become extremely complex and even
unsolvable. If a software development team is to be successful, the inter project
communications, as captured in the software architecture, must be both accurate
and precise.
 From a management perspective, there are three difference aspects of architecture.
 An architecture (the intangible design concept) is the design of a software
system this includes all engineering necessary to specify a complete bill of
materials.
 An architecture baseline (the tangible artifacts) is a slice of information across
the engineering artifact sets sufficient to satisfy all stakeholders that the
 vision (function and quality) can be achieved within the parameters of the
business case (cost, profit, time, technology and people).

 An architecture description (a human-readable representation of an

architecture, which is one of the components of an architecture baseline) is
an organized subset of information extracted form the design set model(s).
The architecture description communicates how the intangible concept is
realized in the tangible artifacts.
 The number of views and the level of detail in each view can vary widely.
 The importance of software architecture and its close linkage with modern software
development processes can be summarized as follows:
 Achieving stable software architecture represents a significant project
milestone at which the critical make/buy decisions should have been
resolved.
 Architecture representations provide a basis for balancing the trade-offs
between the problem space (requirements and constraints) and the solution
space (the operational product).
 The architecture and process encapsulate many of the important (high-payoff
or high-risk) communications among individuals, teams, organizations and
stakeholders.
 Poor architectures and immature processes are often given as reasons for
project failures.
 A mature process, an understanding of the primary requirements, and a
demonstrable architecture are important prerequisites fro predictable
planning.
 Architecture development and process definition are the intellectual steps
that map the problem to a solution without violating the constraints; they
require human innovation and cannot be automated.

ARCHITECTURE: A TECHNICAL PERSPECTIVE

• An architecture framework is defined in the terms of views that are abstractions of

the UML models in the design set. The design model includes the full breadth and
depth of information. An architecture view is an abstraction of the design model; it
contains only the architecturally significant information. Most real-world systems
require four views: design, process, component and deployment. The purposes of
these views are as follows:
– Design: Describes architecturally significant structures and functions of the
design model.
– Process: Describes concurrency and control thread relationship among the
design, component and deployment views.
– Component: Describes the structure of the implementation set.
– Deployment: Describes the structures of the deployment set.