Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

SPM Unit 3

Download as pdf or txt
Download as pdf or txt
You are on page 1of 65

UNIT 3

LIFE CYCLE PHASES


 The most important Characteristic of a successful
software development process is the well-defined
separation between "research and development"
activities and "production" activities.
 Suppose any software project is failed the primary
reason is improper seperation of these two stages.The
unsuccessful projects exhibits the following
characteristics.
 1. An overemphasis on research and development
 2. An overemphasis on production.
 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
 The economic factor provides a simple framework for
deriving a lifecycle picture.
 To achieve the scale of economics and higher returns
on investment, the developers should develop the
software with process automation and in component-
based development model. Two stages of the life-cycle:
 1. The engineering stage – driven by less
predictable but smaller teams doing design and
synthesis activities.
 2. The production stage – driven by more
predictable but larger teams doing construction,
test, and deployment activities.
 The transition between engineering and production is
a crucial event for the various stakeholders.
 Generally the production plans are agreed after
enough understanding of the problem and all the
stakeholders are agreed to the particular solution and
committed to go for production.
 Engineering stage is decomposed into two distinct
phases, inception and elaboration, and the
 production stage into construction and transition.
The following diagram shows the
development of project stages
 Here the size of the spiral corresponds to the
sluggishness of the project with respect to the artifacts
that has been developed.
 This sluggishness visualizes the maintaining the
process or development consistency, regression
testing ,documentation, quality analysis and
configuration control.
INCEPTION PHASE
 The over all goal of the inception phase is to achieve
the concurrence between the stakeholders and life-
cycle phases of the project.
 The following are the primary objectives and the
essential activities of the inception phase.
Primary objectives
 1. Establish the project's software scope and boundary
conditions, including an operational concept,
acceptance criteria, and a clear understanding of what
is and is not intended to be in the project.
 2. selecting the critical use cases of the system and the
primary states of operation that will reduce the major
design trade-offs.
 3.Estimating the cost and schedule for the entire
project

 4. Estimating potential risks


Essential Activities
 1. Formulating the scope of the project. This activity
involves capturing the requirements and operational
concepts in an information repository that describes
user’s view the requirements The information
repository should be sufficient to define the problem
space and derive the acceptance criteria for the end
product.
 2. Synthesizing the architecture. Here design
drawbacks, problem space ambuigities, and available
solution space ass are evaluated.
 3. Planning and preparing a business case. Alternatives
for risk management, staffing, iteration
 plans, and cost/schedule/profitability trade-offs are
evaluated.
Primary Evaluation Criteria
 1. Do all stakeholders concur on the scope definition
and cost and schedule estimates?
 2. Are requirements understood?
 3. Are the cost and schedule estimates, priorities, risks,
and development processes believable?
 4. Are actual resource expenditures versus planned
expenditures acceptable?
Elaboration phase
 We know that elaboration phase is most difficult one
than remaining three phases.
 At the end of the elaboration phase, the total project
engineering is considered to be completed and project
goes to production.
 The elaboration phase must ensure that the
architecture, requirements and plans are stable
enough and risks are sufficiently mitigated, cost and
schedule for the completion of the development can
be predicted within acceptable range.
Primary objectives
 1. Base lining the architecture as rapidly as practical
 2. Base lining the vision
 3. Base lining a high-reliability plan for the
construction phase
 4. Demonstrating that the baseline architecture will
support the vision at a reasonable cost in a
reasonable time
Essential Activities
 1.Elaborate the vision
 2.Elaborating the process and infrastructure
 3.Elaborating the architecture and selecting
components
Primary Evaluation criteria

 1. Is the vision stable?


 2. Is the architecture stable?
 3. Does the executable demonstration show that the
major risk elements have been addressed and credibly
resolved?
Construction Phase
 The construction phase represents a production
process, in which emphasis is placed on managing
resources and controlling operations to optimize
costs, schedules, and quality.
 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.
Primary objectives
 1. Minimizing development costs by optimizing
resources and avoiding unnecessary scrap and rework
 2. Achieving adequate quality as rapidly as practical
 3. Achieving useful versions (alpha, beta, and other
test releases) as rapidly as practical
Essential Activities
 1. Resource management, control, and process
optimization
 2. Complete component development and testing
against evaluation criteria
 3. Assessment of product releases against acceptance
criteria of the vision
Primary Evaluation Criteria
 1. Is the project baseline mature enough to be deployed
in the user community?
 2. Is this product baseline stable enough to be
deployed in the user community?
 3. Are the stakeholders ready for transition to the user
community?
 4. Are actual resource expenditures versus planned
expenditures acceptable?
Transition Phase
 The transition phase is entered when project to be
deployed in the end user domain.
 The transition phase requires a usable system has been
developed with acceptable quality levels and user
documentation.
 This phase includes the following activities

 1. Beta testing to validate the new system against user


expectations
 2. Beta testing and parallel operation relative to a
legacy system it is replacing
 3. Conversion of operational databases
 4. Training of users and maintainers
 Generally the transition phase focuses on the activities
to place the complete system in the hands of the user.
It includes, beta releases, bug fix and enhancement
releases. Here the developer puts his efforts for
developing user oriented documentation , training
users, supporting users for the product use.
Primary Objectives
 1. Achieving user self-supportability
 2. Achieving stakeholder concurrence that deployment
baselines are complete and consistent with the
evaluation criteria of the vision
 3. Achieving final product baselines as rapidly and
cost-effectively as practical
Essential Activities
 1. Synchronization and integration of concurrent
construction increments into consistent deployment
baselines
 2. Deployment-specific engineering
 3. Assessment of deployment baselines against the
complete vision and acceptance criteria in
the requirements set
Primary Evaluation criteria
 1. Is the user satisfied?
 2. Are actual resource expenditures versus planned
expenditures acceptable?
The Artifact Sets
 To manage the complete software development
process, we should collect various kinds of information
and organized it in to artifact sets.
 Each artifact set may have related artifacts that are
persistent and are in a uniform representation format.
 Here set represents a complete view of the system and
an artifact represents unified information that is
developed as a single entity.
 Generally the artifacts are divided in to five distinct
set in the project development life cycle.
 Those are management set artifacts, requirement
artifact set, design artifact set, implementation artifact
set and deployment artifact set.
The Management Artifacts
 The management artifact set consisting of the artifacts
related with process planning and execution. This set
use ad hoc notations such as text; graphics required to
represents the agreements among project personnel,
and among stake holders.
 Management set artifacts are evaluated, assessed and
measured through the combination of the following.
 1.Relevant stakeholder review
 2.Analysis of changes between the current artifacts
with the previous artifacts.
 3.Demonstrations need to balance all artifacts
The Engineering set Artifacts
 The Engineering set artifacts consists of requirement
set, design set, implementation set and deployment
set.
 The primary goal to evaluating quality of each artifact
set is transiting the information from one set to
another set.
 So we can maintain balance among the requirements,
design, implementation, and deployment.
Requirement Artifacts
 To specify the vision statement we use structured text
in requirement artifact, the vision document describe
the scope of the project.
 Here we use some ad hoc formats for supplementary
specifications . Here we use UML notation for
engineering representation of requirements model.
 The requirement set is primary to evaluate the
remaining three sets of artifacts
 Requirement artifacts are evaluated , assessed and
measured through combination of the following
 1)Analyze the consistency with the release
specifications of management set.
 2)Analyze the consistency between the vision and the
requirements models.
 3)Mapping the design , implementation and
deployment sets to evaluate the consistency and
completeness
 4) The changes between current versions of
requirement artifacts with previous version.
 5)Individual review of other dimensions of quality
Design Artifacts
 UML notation is used to engineer the design models
for the solution.
 The design set artifacts includes ,the design model,
test model, software architecture description.
 The design set artifacts are evaluated, assessed, and
measured through a combination of the following:
 Analyze the internal consistency and quality of the
design model
 Analysis of consistency with the requirements models
 Translate the design models into implementation and
deployment sets evaluate the consistency and
completeness between the sets
 Analyze the change between the current version
design model and previous version design model
 Individual review of other dimensions of quality
Implementation Artifacts
 The implementation artifact set includes source code
that is useful to develop the working system
components and any executable required to test these
components.
 Implementation set artifacts can be translated into
deployment set.
 Implementation sets are in human-readable formats
that are evaluated, assessed, and measured through a
combination of the following:
 Analyze the consistency with the design models
 Translation into deployment set notations
 Assessment of component source code or executable
files through inspection, analysis, demonstration, or
testing
 Execution of stand-alone component test cases that
automatically compare expected results with actual
results
 Analyze the difference between the current version of
artifacts with previous version.
Deployment Artifacts
 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 project in user
environment.
 Deployment sets are evaluated, assessed, and
measured through a combination of the following:
 1)test the deployment set against the system usage
and the quality to be evaluated with respect to
consistency and completeness.
 2)Test the usage scenarios –user manual, mainstream
usage, anomaly management.
 3)Analyze the changes between the current version
and previous version .
 4)Individual review of other dimensions of quality
 The goal of artifacts is to optimize the process
activities and objectives.
 There is no scientific methodology for selecting
management, requirement ,design, and
implementation
 Generally each artifact set use different plans to gain
the relevant information of the system
 The management artifacts concentrate on plans,
process, business objectives and acceptance criteria.
 Reqirement artifacts concentrate on engineering
information and operational concepts.
 Design artifacts concentrates on engineering
blueprints.
 Implementation artifacts concentrate on building
block of the solution in the human readable form.
 Deployment artifacts concentrate on solution in
machine readable form.
 The modern software development process map to any
one of the artifact set.
 1)Management : workflow, defect tracking , change
management , documentation , spread sheet ,resource
management and presentation tools
 2)Requirements : requirements of management tools
 Design: visual modeling tools
 Implementation: compiler/debugger tools, code
analysis tools, test coverage analysis tools, and test
management tools
 Deployment: test coverage and test automation tools,
network management tools, commercial components
and installation tools.
Implementation set versus
Deployment set
 The implementation set and deployment set have their
own concept ,the differences between these two sets
are essential.
 The structure of information delivered to the user is
entirely different from the structure of source code
executed in environment
 We know that the engineering decisions has great
impact on quality and deployment of the system, at
the same time it is difficult to understand the
engineering decisions.
Artifact Evolution over the life cycle
 Each state of development represents a certain amount
of precision in the final system description.
 At the beginning of the life cycle, precision is low and
the representation is generally high.
 Finally the precision is high and every thing is
specified in full detail.
 Each phase of development focuses on a particular
artifact set. At the end of each phase, the system
development will process all the sets.
 The following diagram represents the life cycle
evolution of artifact set
 The inception phase focuses mainly on critical
requirements ,initial deployment view and little focus
on implementation primary focus on design
architecture.
 During the elaboration phase, there is much greater
depth in requirements, much more breadth in the
design set, and further work on implementation and
deployment issues.
 The main focus of the construction phase is design
and implementation.
 The main focus of the transition phase is on
achieving consistency and completeness of the
deployment set in the context of the other sets.
Test Artifacts

 In conventional software testing, document driven


techniques are used.
 Generally the development teams built requirement
documents, top level design documents, and detailed
design documents in software development process.
 In the same way before conducting the software
testing, the system test plan documents, system test
procedure documents, integration test plan
documents, unit test plan documents are constructed
by the testing team.
 The testing is done basically by identifying the test
infrastructure. Due to this the following engineering
constraints are used in testing process.
 The test artifacts must be developed concurrently with
the product from inception through deployment.
Thus, testing is a full-life-cycle activity.
 The test artifacts are communicated, engineered, and
developed within the same artifact sets as the
development product.
 The test artifacts are implemented in programmable
and repeatable formats .
 The test artifacts are documented in the same way that
the product is documented.
 Developers of the test artifacts use the same tools,
techniques, and training as the software engineers
developing the product.
 The testing is only one aspect of the assessment of
workflow. Other Aspects include inspection, analysis
and demonstration.
 The success of a test can be determined by comparing
the expected outcome to the actual outcome.
Management Artifacts
 The management artifact set is used to capture
intermediate results and additional information
required to document the product/process.
 This information have how to maintainable product,
how to improve the product and improvements of the
process.
 Business case: The business case information is used
to determine whether investing in the project in
beneficial or not.
 The business case artifact includes the expected cost,
revenue, backup data and technical management
plans.
 The main purpose of business case is to transform the
vision into economics terms, so an organization can
make accurate ROI.
 Software development Plan: The software
development plan(SDP) describes the process
framework in full detail.
 Its a defined document of projects process.
 Two important indicators of SDP are a) periodic
updating and b)understanding and acceptance by
managers
Work Breakdown Structure(WBS)
 The work breakdown structure (WBS) is key featuring
for budgeting and collecting costs.
 The project manager should have an idea about
projects costs.
 Suppose the WBS may plan improperly it may cause
for project failure, because it has large impact on
design and production stages of the project.
 The project manager concentrates on lower level of
WBS after particular level of stability achieved in the
project development
 Software change order Database:
 Managing change is one of the fundamental issues in
iterative development process. With good change
freedom, a project may develop more productively.
 This change freedom can increases the flexibility in
project contents, quality, and number of iterations that
a project can achieve within a given schedule.
Generally Change freedom is achieved through process
automation
 Release Specifications:
 The projects plan scope and objective is assessed
before release.
 This assessment criterion is depending on the projects
vision statement and many other parameters
 Release description:
 Release description documents describe the results of
each release, including performance against each of
the evaluation criteria in the corresponding release
specification.

You might also like