UNIT-2

SOFTWARE PROJECT
MANAGEMENT RENAISSANCE
Conventional software management
 Water Fall Model

 Conventional software Management Performance

Evolution of Software Economics

Software Economics

Pragmatic Software Cost Estimation

Improving Software Economics
The old way and The new way
Life-cycle Phases and Process artifacts
 C O N V E N T I O N A L S O F T WA R E
MANAGEMENT
Conventional software economics provides a benchmark of
performance for conventional software management
principles.

 The best thing about software is its fl exibility

• It can be programmed to do almost anything.

 The worst thing about software is also its

fl exibility

• The "almost anything" characteristic has made it diffi cult

to plan, monitors, and control software development.
Three important analyses of the state of the software
engineering industry are

1. Software development is still highly

unpredictable. Only about 10% of software
projects are delivered successfully within initial
budget and schedule estimates.

2. Management discipline is more of a discriminator

in success or failure than are technology
advances.

3. The level of software scrap and rework is

indicative of an immature process.
 THE WATERFALL MODEL
• Most software engineering texts present the waterfall
model as the source of the "conventional" software
process
• It provides an insightful and concise summary of
conventional software management
Three main primary points are

There are two essential steps common to the development of computer

programs: analysis and coding.

• Analysis and coding both involve creative work that directly contributes to
the usefulness of the end product.

• Waterfall Model part 1: The two basic steps to building a program

Analysis

Coding

• Analysis and coding both involve creative work that directly contributes to the
usefulness of the end product
• 2. In order to manage and control all of the intellectual
freedom associated with software development, one must
introduce several other "overhead" steps, including system
requirements definition, software requirements definition,
program design, and testing. These steps supplement the
analysis and coding steps
• The basic framework described in the waterfall
model is risky and invites failure.

• The testing phase that occurs at the end of the

development cycle is the first event for which
timing, storage, input/output transfers, etc., are
experienced as distinguished from analyzed.

• The resulting design changes are likely to be so

disruptive that the software requirements upon
which the design is based are likely violated.
Either the requirements must be modified or a
substantial design change is warranted.
FI VE NECESSARY I M PRO VEM ENTS FO R
W AT E R F A L L M O D E L A R E : -
1. Program design comes first .

Insert a preliminary program design phase between the software

requirements phase and the analysis phase.
2. Document the design.

The amount of documentation required on most software programs is

quite a lot, certainly much more than most programmers, analysts, or
program designers are willing to do if left to their own devices
3. Do it twice.

If a computer program is being developed for the first time, arrange

matters so that the version finally delivered to the customer for
operational deployment is actually the second version insofar as
critical design/operations are concerned
4) Plan, control, and monitor testing. Without question, the
biggest user of project resources-manpower, computer time,
and/or management judgment-is the test phase.

• This is the phase of greatest risk in terms of cost and schedule. It

occurs at the latest point in the schedule, when backup alternatives
are least available

5)Involve the customer. It is important to involve the customer in a

formal way so that he has committed himself at earlier points
before final delivery.
 IN PRACTICE
• Some software projects still practice the conventional software
management approach.

• It is useful to summarize the characteristics of the conventional

process as it has typically been applied, which is not
necessarily as it was intended.

• Projects destined for trouble frequently exhibit the following

symptoms:
1. Protracted integration and late design breakage.
2. Late risk resolution.
3. Requirements-driven functional decomposition.
4. Adversarial (conflict or opposition) stakeholder
relationships.
5. Focus on documents and review meetings.
Table 1-1 provides a typical profile of cost expenditures across the
spectrum of software activities.
 LATE RISK RESOLUTION
• A serious issue associated with the waterfall lifecycle was the lack of
early risk resolution.

• Figure 1.3 illustrates a typical risk profile for conventional waterfall

model projects.

• It includes four distinct periods of risk exposure, where risk is defined as

the probability of missing a cost, schedule, feature, or quality goal.
REQUIREMENTS-DRIVEN FUNCTIONAL
DECOMPOSITION:
• This approach depends on specifying requirements completely
and unambiguously before other development activities begin.

• It naively treats all requirements as equally important, and

depends on those requirements remaining constant over the
software development life cycle.

• These conditions rarely occur in the real world. Specification of

requirements is a difficult and important part of the software
development process.
Figure 1-4 illustrates the result of requirements-driven
approaches: a software structure that is organized around the
requirements specification structure.
A D V E R S A R I A L S TA K E H O L D E R
R E L AT I O N S H I P S :
• The following sequence of events was typical for most
contractual software efforts:

• The contractor prepared a draft contract-deliverable

document that captured an intermediate artifact and
delivered it to the customer for approval.

• The customer was expected to provide comments (typically

within 15 to 30 days).

• The contractor incorporated these comments and submitted

(typically within 15 to 30 days) a final version for approval.

• This one-shot review process encouraged high levels of

sensitivity on the part of customers and contractors.
 FOCUS ON DOCUMENTS AND
REVIEW MEETINGS:
• The conventional process focused on producing various
documents that attempted to describe the software product,
with insufficient focus on producing tangible increments of
the products themselves .

• Contractors were driven to produce literally tons of paper to

meet milestones and demonstrate progress to
stakeholders, rather than spend their energy on tasks that
would reduce risk and produce quality software
 CONVENTIONAL SOFTWARE MANAGEMENT
PERFORMANCE

Barry Boehm's Industrial Software Metrics Top 10 List

1. Finding and fixing a software problem after delivery costs

100 times more than finding and fixing the problem in
early design phases.

2. You can compress software development schedules 25%

of nominal, but no more.

3. For every $1 you spend on development, you will spend $2

on maintenance.(Iron law of s/w development)

4. Software development and maintenance costs are

primarily a function of the number of source lines of code.
5. Variations among people account for the biggest differences in

software productivity

6. The overall ratio of software to hardware costs is still growing. In

1955 it was 15:85; in 1985, 85:15.

7. Only about 15% of software development effort is devoted to

programming.

8. Software systems and products typically cost 3 times as much

per SLOC as individual software programs. Software-system

products (i.e., system of systems) cost 9 times as much.

9. Walkthroughs catch 60% of the errors

10. 80% of the contribution comes from 20% of the contributors.

 E V O L U T I O N O F S O F T WA R E
ECONOMICS
SOFTWARE ECONOMICS

• Most software cost models can be abstracted into a function of five

basic parameters:

• Size

• Process

• Personnel

• Environment and

• Required Quality
• The size of the end product (in human-generated components), which
is typically quantified in terms of the number of source instructions
or the number of function points required to develop the required
functionality

• The process used to produce the end product, in particular the ability
of the process to avoid non- value- adding activities (rework,
bureaucratic delays, communications overhead)

• The capabilities of software engineering personnel, and particularly

their experience with the computer science issues and the
applications domain issues of the project
• The environment, which is made up of the tools and
techniques available to support efficient software
development and to automate the process

• The required quality of the product, including its features,

performance, reliability, and adaptability

• The relationships among these parameters and the estimated

cost can be written as follows:
Effort = (Personnel) (Environment) (Quality)
(Size process )
• Figure 2-1 shows three generations of basic technology advancement in
tools, components, and processes.
• Figure 2-2 provides an overview of how a return on investment (ROI) profile
can be achieved in subsequent efforts across life cycles of various domains.
PRAGMATIC SOFTWARE COST ESTIMATION
There have been many debates among developers and vendors of
software cost estimation models and tools.

Three topics of these debates are of particular interest here:

• Which cost estimation model to use?

• Whether to measure software size in source lines of code or

function points.

• What constitutes a good estimate?

• There are several popular cost estimation models (such as COCOMO,
CHECKPOINT, ESTIMACS, Knowledge Plan, Price-S, ProQMS, SEER,
SLIM, SOFTCOST, and SPQR/20),

• COCOMO is also one of the most open and well-documented cost

estimation models.
A G O O D S O F T W A R E C O S T E S T I M AT E H A S
T H E F O L L O W I N G AT T R I B U T E S :
• It is conceived and supported by the project manager, architecture
team, development team, and test team accountable for
performing the work.

• It is accepted by all stakeholders as ambitious but realizable.

• It is based on a well-defined software cost model with a credible

basis.

• It is based on a database of relevant project experience that

includes similar processes, similar technologies, similar
environments, similar quality requirements, and similar people.

• It is defined in enough detail so that its key risk areas are

understood and the probability of success is objectively
assessed.
 I M P R O V I N G S O F T WA R E
ECONOMICS
• Five basic parameters of the software cost model are
Reducing the size or complexity of what needs to be
developed.

Improving the development process.

Using more-skilled personnel and better teams

Using better environments (tools to automate the process).

Trading off or backing off on quality thresholds.

 REDUCING SOFTWARE PRODUCT SIZE

• Languages
• Object Oriented method and visual modeling
• Reuse
• Commercial components
 LANGUAGES
• Universal function points (UFPs 1 ) are useful estimators for
language-independent, early life-cycle estimates.

• The basic units of function points are external user inputs,

external outputs, internal logical data groups, external
data interfaces, and external inquiries.

• SLOC metrics are useful estimators for software after a

candidate solution is formulated and an implementation
language is known.

• Substantial data have been documented relating SLOC to

function points.
LANGUAGES SLOC per UFP
Assembly 320
C 128
FORTAN77 105
COBOL85 91
Ada83 71
C++ 56
Ada95 55
Java 55
Visual Basic 35
 O B J E C T- O R I E N T E D M E T H O D S
AND VISUAL MODELING

• Object-oriented programming languages appear to benefit

both software productivity and software quality.

• The fundamental impact of object-oriented technology is in

reducing the overall size of what needs to be developed.

• People like drawing pictures to explain something to others or

to themselves.
Booch described three reasons that certain object oriented
succeed

1. An object-oriented model of the problem and its solution encourages a

common vocabulary between the end users of a system and its
developers, thus creating a shared understanding of the problem being
solved.

2. The use of continuous integration creates opportunities to recognize

risk early and make incremental corrections without destabilizing the
entire development effort.

3. An object-oriented architecture provides a clear separation of

concerns among disparate elements of a system, creating firewalls
that prevent a change in one part of the system from rending the
fabric of the entire architecture.
 BOOCH ALSO SUMMARIZED FIVE
C H A R A C T E R I S T I C S O F A S U C C E S S F U L O B J E C T-
ORIENTED PROJECT
1. A ruthless focus on the development of a system that provides a
well understood collection of essential minimal characteristics.

2. The existence of a culture that is centered on results, encourages

communication, and yet is not afraid to fail.

3. The effective use of object-oriented modeling.

4. The existence of a strong architectural vision.

5. The application of a well-managed iterative and incremental

development life cycle.
 REUSE
• Reusing existing components and creating reusable components
have been integral parts of software engineering since the early
advancements in programming languages

• With reuse in order to minimize development costs while

achieving all the other required attributes of performance,
feature set, and quality .

• Most truly reusable components of value are transitioned to

commercial products supported by organizations with the following
characteristics:
• They have an economic motivation for continued support.
• They take ownership of improving product quality, adding new
features, and transitioning to new technologies.
• They have a sufficiently broad customer base to be profitable.
 COMMERCIAL COMPONENTS
• the use of commercial components is certainly desirable as a means of
reducing custom development, it has not proven to be straightforward in
practice .
 IMPROVING SOFTWARE PROCESSES

Three distinct process perspectives are.

• Metaprocess: an organization's policies, procedures, and

practices for pursuing a software-intensive line of business.

• The focus of this process is on organizational economics,

long-term strategies, and software ROI.

• Macroprocess: a project's policies, procedures, and practices

for producing a complete software product within certain cost,
schedule, and quality constraints.

• The focus of the macro process is on creating an adequate

instance of the Meta process for a specific set of constraints.
• Microprocess: a project team's policies, procedures, and practices
for achieving an artifact of the software process.

• The focus of the micro process is on achieving an

intermediate product baseline with adequate quality and
adequate functionality as economically and rapidly as
practical.
 IMPROVING TEAM EFFECTIVENESS

• Teamwork outweighs individual contributions. A project manager

should balance solid talent with skilled individuals in key roles.

Some maxims of team management include the following:

• A well-managed project can succeed with a nominal engineering team.

• A mismanaged project will almost never succeed, even with an expert

team of engineers.

• A well-architected system can be built by a nominal team of software

builders.

• A poorly architected system will flounder even with an expert team of

builders.
 B O E H M F I V E S TA F F I N G
PRINCIPLES ARE
• The principle of top talent: Use better and fewer people

• The principle of job matching: Fit the tasks to the skills and
motivation of the people available.

• The principle of career progression: An organization does best in the

long run by helping its people to self-actualize.

• The principle of team balance: Select people who will complement

and harmonize with one another

• The principle of phase-out: Keeping a misfit on the team doesn't

benefit anyone
• The following are some crucial attributes of successful software
project managers that deserve much more attention:

• Hiring skills.

• Few decisions are as important as hiring decisions.

• Placing the right person in the right job seems obvious but is
surprisingly hard to achieve.

• Customer-interface skill.

• Avoiding adversarial relationships among stakeholders is a

prerequisite for success.

• Decision-making skill.

• We all know a good leader when we run into one, and decision-

making skill seems obvious despite its intangible definition .

• Team-building skill.

• Teamwork requires that a manager establish trust,

• motivate progress

• exploit eccentric prima donnas

• transition average people into top performers

• eliminate misfits and

• consolidate diverse opinions into a team direction.

• Selling skill.

• Successful project managers must sell all stakeholders (including

themselves) on decisions and priorities

• sell candidates on job positions

• sell changes to the status quo in the face of resistance and

• sell achievements against objectives

 IMPROVING AUTOMATION THROUGH SOFTWARE
ENVIRONMENTS

• The tools and environment used in the software process generally

have a linear effect on the productivity of the process.

• Planning tools, requirements management tools, visual modeling

tools, compilers, editors, debuggers, quality assurance analysis tools,
test tools, and user interfaces provide crucial automation support for
evolving the software engineering artifacts.
• Round-trip engineering

• It describes the key capability of environments that support iterative

development.

• maintaining different information repositories for the engineering

artifacts, we need automation support to ensure efficient and error-free
transition of data from one artifact to another.

• Forward engineering is the automation of one engineering artifact

from another, more abstract representation.

• For example, compilers and linkers have provided automated transition of

source code into executable code.

• Reverse engineering is the generation or modification of a more

abstract representation from an existing artifacts
For example, it is easy to find statements such as the following
from companies in a particular tool .
 Requirements analysis and evolution activities consume 40% of life-
cycle costs.

 Software design activities have an impact on more than 50% of the

resources.

 Coding and unit testing activities consume about 50% of software

development effort and schedule.

 Test activities can consume as much as 50% of a project's

resources..
• Configuration control and change management are critical activities that can
consume as much as 25% of resources on a large-scale project.

• Documentation activities can consume more than 30% of project

engineering resources.

• Project management, business administration, and progress assessment

can consume as much as 30% of project budgets
 ACHIEVING REQUIRED
QUALITY
Key practices that improve overall software quality include the
following:

• Focusing on driving requirements and critical use cases early in the

life cycle

• Focusing on requirements completeness and traceability late in the

life cycle

• focusing throughout the life cycle on a balance between

requirements evolution, design evolution, and plan evolution

• Using metrics and indicators to measure the progress and quality of

an architecture as it evolves from a high-level prototype into a fully
compliant product
• Providing integrated life-cycle environments that support early and
continuous configuration control, change management, rigorous design
methods, document automation, and regression test automation

• Using visual modeling and higher level languages that support

architectural control, abstraction, reliable programming, reuse, and
self-documentation

• Early and continuous insight into performance issues through

demonstration-based evaluations
• Project inception. The proposed design was asserted to be low risk
with adequate performance margin.

• Initial design review.

• Mid-life-cycle design review. The assessments started whittling away

at the margin, as early benchmarks and initial tests began exposing
the optimism inherent in earlier estimates.

• Integration and test. Serious performance problems were uncovered,

necessitating fundamental changes in the architecture
 PEER INSPECTIONS: A PRAGMATIC VIEW

• Transitioning engineering information from one artifact set to

another, thereby assessing the consistency, feasibility,
understandability, and technology constraints inherent in the
engineering artifacts

• Major milestone demonstrations that force the artifacts to be

assessed against tangible criteria in the context of relevant use
cases

• Environment tools (compilers, debuggers, analyzers, automated test

suites) that ensure representation rigor, consistency, completeness,
and change control
• Life-cycle testing for detailed insight into critical trade-offs, acceptance
criteria, and requirements compliance

• Change management metrics for objective insight into multiple-perspective

change trends and convergence or divergence from quality and progress
goals
T H E O L D WAY A N D T H E N E W WAY
THE PRINCIPLES OF CONVENTIONAL SOFTWARE ENGINEERING

1. Make quality

2. High-quality software is possible

3. Give products to customers early

4. Determine the problem before writing the requirements

5. Evaluate design alternatives

6. Use an appropriate process model.

7. Use different languages for different phases

8. Minimize intellectual distance.

9. Put techniques before tools

10. Get it right before you make it faster.

11 . Inspect code

12. Good management is more important than good technology

13. People are the key to success

14. Follow with care

15. Take Responsibility

16. Understand the customer priorities

17. The more they see, The more they need

18.Plan to throw one away

19.Design for change

20.Design without Documentation is not design

21. Use tools, but be realistic

22.Avoid Tricks

23 Encapsulate

24. Use Coupling and Cohesion

25. Use the McCabe complexity measure

26.Don’t Test your own software

27. Analyze Causes for Errors

28. Realize that Software's entropy increases

29. People and Time are not Interchangeable

30. Expect Excellence

 THE PRINCIPLES OF MODERN SOFTWARE MANAGEMENT

1. Base the process on an architecture-first approach

2. Establish an iterative life-cycle process that confronts risk early
3. Transition design methods to emphasize component-based
development
4. Establish a change management environment.
5. Enhance change freedom through tools that support round-trip
engineering.
6. Capture design artifacts in rigorous, model-based notation
7. Instrument the process for objective quality control and progress
assessment.
8. Use a demonstration-based approach to assess intermediate
artifacts.
9. Plan intermediate releases in groups of usage scenarios with
evolving levels of detail
10. Establish a configurable process that is economically scalable.
 TRANSITIONING TO AN ITERATIVE PROCESS

The following map the process exponent parameters of COCOMO II to

top 10 principles of a modern process.

 Application precedentedness
 Process flexibility.
 Architecture risk resolution.
 Team cohesion
 Software process maturity.
LIFE CYCLE PHASES
AND
PROCESS ARTIFACTS
 Life cycle phases

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
 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 teams

doing construction, test, and deployment activities
 INCEPTION PHASE

PRIMARY OBJECTIVES

• Establishing the project's software scope and boundary conditions

• Including an operational concept & acceptance criteria

• A clear understanding of what the product will and will not include.

• Identifying the system's critical use cases and primary operational

scenarios will guide key 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 unpredictability)

ESSENTIAL ACTIVITIES

• Formulating the scope of the project

• Synthesizing the architecture

• Planning and preparing a business case

PRIMARY EVALUATION CRITERIA

• Do all stakeholders concur on the scope definition and cost and
schedule estimates?
• Are requirements understood, as evidenced by the fidelity of the
critical use cases?
• Are the cost and schedule estimates, priorities, risks, and
development processes credible?
• Do the depth and breadth of an architecture prototype demonstrate
the preceding criteria?
• Are actual resource expenditures versus planned expenditures
acceptable.
 ELABORATION PHASE

OBJECTIVES

• Base lining the architecture as rapidly as practical

• 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 .

PRIMARY EVALUATION CRITERIA

• Is the vision stable?

• Is the architecture stable?

• Does the executable demonstration show that the major risk

elements have been addressed and credibly resolved?

• Is the construction phase plan of sufficient fidelity, and is it backed

up with a credible basis of estimate?

• Do all stakeholders agree that the current vision can be met if the
current plan is executed to develop the complete system in the
context of the current architecture?

• Are actual resource expenditures versus planned expenditures

acceptable?
 CONSTRUCTION PHASE

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
PRIMARY EVALUATION CRITERIA

• Is this product baseline mature enough to be deployed in the user

community?

• Is this product baseline stable enough to be deployed in the user

community?

• Are the stakeholders ready for transition to the user community?

• Are actual resource expenditures versus planned expenditures acceptable

 TRANSITION PHASE

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 users and maintainers

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 product baselines as rapidly and cost-effectively as practical

ESSENTIAL ACTIVITIES

• Synchronization and integration of concurrent construction increments into

consistent deployment baselines

• Deployment-specific engineering (cutover, commercial packaging and

production, sales rollout kit development, field personnel training)

• Assessment of deployment baselines against the complete vision and

acceptance criteria in the requirements set

EVALUATION CRITERIA

• Is the user satisfied?

• Are actual resource expenditures versus planned expenditures acceptable?

 WHAT IS ARTIFACT
• An artifact is a byproduct of software development that helps to
describe the architecture, design and function of software.

• Artifacts are like roadmaps that software developers can use to trace
the entire software development process.

• Artifacts can also include things like case studies, data models, design
documents, scripts, Unified Modeling Languages and work products.
 ARTIFACT SET
Life-cycle software artifacts are organized into five distinct
sets

 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),

 Deployment (machine-process able languages and associated

files).
 THE MANAGEMENT SET

 The management set captures the artifacts associated with

process planning and execution

 These artifacts use ad hoc notations, including text, graphics

and contracts among project personnel ,stakeholders

Specific artifacts included in this set are the work breakdown

structure are
 The business case
 The release specifications
 The release descriptions
 The software change orders
 The deployment documents
 The environment
 Management set artifacts are evaluated, assessed,
and measured through a combination of the
following:-
 Relevant stakeholder review

 Analysis of changes between the current version of the artifact

and previous versions

 Major milestone demonstrations of the balance among all artifacts

and, in particular, the accuracy of the business case and vision
artifacts
 THE ENGINEERING SETS

The engineering sets consist of four and they are:

• The Requirements Set
• The Design Set
• The Implementation Set
• The Deployment Set.
 REQUIREMENTS SET
Requirements artifacts are evaluated, assessed, and measured
through a combination of the following:

 Analysis of consistency with the release specifications of the

management set

 Analysis of consistency between the vision and the requirements

models

 Mapping against the design, implementation, and deployment sets to

evaluate the consistency and completeness and the semantic balance
between information in the different sets

 Analysis of changes between the current version of requirements

artifacts and previous versions (scrap, rework, and defect elimination
trends)

 Subjective review of other dimensions of quality

 DESIGN SET
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

 I M P L E M E N TAT I O N S E T S
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 SETS
Deployment sets are evaluated, assessed, and measured through a
combination of the following:

• Testing usage scenarios and quality attributes to evaluate

consistency, completeness, and alignment with requirements.

• Testing partitioning, replication, and allocation strategies for mapping

implementation components to the deployment system's physical
resources.

• Testing against defined usage scenarios in the user manual, including

installation, user-driven reconfiguration, standard 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

Most of today's software development tools map closely to one of the
five artifact sets.

• Management: scheduling, workflow, defect tracking, change

management, documentation, spreadsheet, resource management, and
presentation tools

• Requirements: requirements 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 (operating systems, GUIs,
RDBMS, networks, middleware), and installation tools.
ARTIFACT EVOLUTION OVER THE LIFE CYCLE
 TEST ARTIFACTS

• Testing is a full-life-cycle activity, not a late life-cycle activity.

• The test artifacts are communicated, engineered, and developed

within the same artifact sets as the developed product.

• The test artifacts are implemented in programmable and repeatable

formats (as software programs).

• 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.
• Management set: The release specifications and release
descriptions capture the objectives, evaluation criteria, and results
of an intermediate milestone

• Requirements set: The entire requirement set is a test artifact

because it is the basis of all assessment activities across the life
cycle.

• Design set: A test model for non-deliverable components needed to

test the product baselines is captured in the design set.

• Implementation set: Self-documenting source code representations

for test components and test drivers provide the equivalent of test
procedures and test scripts.
 MANAGEMENT ARTIFACTS

The management set includes several artifacts that capture

intermediate results and information necessary to document the
product/process legacy, maintain the product, improve the product, and
improve the process.
Business Case

 The business case artifact provides all the information necessary to

determine whether the project is worth investing in

 The main purpose is to transform the vision into economic terms so

that an organization can make an accurate ROI assessment.
S O F T WA R E D E V E L O P M E N T P L A N
• The software development plan (SDP) elaborates the process
framework into a fully detailed plan.

• Two indications of a useful SDP are periodic updating (it is not

stagnant shelf ware) and understanding and acceptance by
managers and practitioners alike .
 WORK BREAKDOWN
STRUCTURE
 Work breakdown structure (WBS) is the vehicle for budgeting and
collecting costs.

 To monitor and control a project's financial performance, the software

project manager must have insight into project costs and how they are
expended.

 The structure of cost accountability is a serious project planning

constraint
 S O F T WA R E C H A N G E O R D E R
D ATA B A S E
• Managing change is one of the fundamental primitives of an iterative
development process.

• flexibility increases the content, quality, and number of iterations that

a project can achieve within a given schedule.

• Change freedom has been achieved in practice through automation,

and today's iterative development environments carry the burden of
change management.

• Organizational processes that depend on manual change

management techniques have encountered major inefficiencies.
 R E L E A S E S P E C I F I C AT I O N S
The scope, plan, and objective evaluation criteria for each baseline
release are derived from the vision statement as well as many other
sources
 RELEASE DESCRIPTIONS
 Release description documents outline the outcomes of each release,
detailing performance against the evaluation criteria in the
corresponding release specification.

 Each release baseline should include a release description document

that:

 Defines the evaluation criteria for that configuration baseline.

 Provides evidence (through demonstration, testing, inspection, or

analysis) that each criterion has been satisfactorily met.
 ENVIRONMENT
• A key focus of a modern approach is defining the development
and maintenance environment as a primary process artifact.

• A robust, integrated development environment should automate

the development process.
• Environment should include:
• Requirements management
• Visual modeling
• Document automation
• Host and target programming tools
• Automated regression testing
• Continuous and integrated change management
• 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.
M A N A G E M E N T A R T I FA C T
SEQUENCES
 ENGINEERING ARTIFACTS
Most of the engineering artifacts are captured in rigorous engineering
notations such as UML, programming languages, or executable
machine codes.
• Vision Document

• The vision document provides a complete vision for the software

system under development & supports the contract between the
funding authority and the development organization .
 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
 S O F T WA R E U S E R M A N U A L
• The software user manual provides the user with the reference
documentation necessary to support the delivered software.

• The user manual should include installation procedures, usage

procedures and guidance, operational constraints, and a user
interface description, at a minimum.

• For software products with a user interface, this manual should be

developed early in the life cycle because it is a necessary mechanism
for communicating and stabilizing an important subset of
requirements.

• The user manual should be written by members of the test team, who
are more likely to understand the user's perspective than the
development team.
 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

• Standardized formats (such as UML, spreadsheets, Visual Basic, C++,

and Ada 95), visualization tools, and the Web are rapidly making it
economically feasible for all stakeholders to exchange information
electronically.
• 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 jargon in the context of the component's usage.

• Useful documentation is self-defining: It is documentation that

gets used.

• Paper is tangible; 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
ARCHI TECTURE
ARCHITECTURE: A MANAGEMENT PERSPECTIVE

• The most critical technical product of a software project is its

architecture:

• the infrastructure, control, and data interfaces that permit software

components to cooperate as a system and software designers to
cooperate efficiently as a team.
From a management perspective, there are three different 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 from the design
set model(s). The architecture description communicates how the
intangible concept is realized in the tangible artifacts.
• The importance of software architecture and its close linkage with
modern software development processes can be summarized as
follows:

• Achieving a 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 for predictable planning.

• Architecture development and process definition are creative

steps that map problems to solutions while respecting
constraints, requiring human innovation.