Professional Documents
Culture Documents
ERODE - 638 104: Mg6088 Software Project Management Lecture Notes
ERODE - 638 104: Mg6088 Software Project Management Lecture Notes
Year/Sem : IV/VIII
UNIT - I
Conventional Software Management: The waterfall model, conventional software Management performance.
Evolution of Software Economics: Software Economics, pragmatic software cost estimation
1. Conventional software management
Conventional software management practices are sound in theory, but practice is still tied to archaic (outdated)
technology and techniques.
Conventional software economics provides a benchmark of performance for conventional software manage-
ment principles.
The best thing about software is its flexibility: It can be programmed to do almost anything.
The worst thing about software is also its flexibility: The "almost anything" characteristic has made it difficult
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.
All three analyses reached the same general conclusion: The success rate for software projects is very low.
The three analyses provide a good introduction to the magnitude of the software problem and the current
norms for conventional software management performance.
Analysis
Design
Coding
Testing
Operation
3. 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.
1. Program design comes first. Insert a preliminary program design phase between the software
requirements generation phase and the analysis phase. By this technique, the program designer
assures that the software will not fail because of storage, timing, and data flux (continuous
change). As analysis proceeds in the succeeding phase, the program designer must impose on the
analyst the storage, timing, and operational constraints in such a way that he senses the consequences.
If the total resources to be applied are insufficient or if the embryonic(in an early stage of
development) operational design is wrong, it will be recognized at this early stage and the iteration
with requirements and preliminary design can be redone before final design, coding, and test
commences. How is this program design procedure implemented?
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. Why do we need so much documentation? (1) Each designer must communicate with interfacing
designers, managers, and possibly customers. (2) During early phases, the documentation is the design. (3) The
real monetary value of documentation is to support later modifications by a separate test team, a separate
maintenance team, and operations personnel who are not software literate.
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. Note that this is simply the entire process done in miniature, to a time scale
that is relatively small with respect to the overall effort. In the first version, the team must have a special
broad competence where they can quickly sense trouble spots in the design, model them, model alternatives,
forget the straightforward aspects of the design that aren't worth studying at this early point, and, finally,
arrive at an error-free program.
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, if
at all. The previous three recommendations were all aimed at uncovering and solving problems before
entering the test phase. However, even after doing these things, there is still a test phase and there are still
important things to be done, including: (1) employ a team of test specialists who were not responsible for the
original design; (2) employ visual inspections to spot the obvious errors like dropped minus signs, missing
factors of two, jumps to wrong addresses (do not use the computer to detect this kind of thing, it is too
expensive); (3) test every logic path; (4) employ the final checkout on the target computer.
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. There are three points following requirements definition where
the insight, judgment, and commitment of the customer can bolster the development effort. These include a
"preliminary software review" following the preliminary program design step, a sequence of "critical software
design reviews" during program design, and a "final software acceptance review".
1.1.2 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:
Early success via paper designs and thorough (often too thorough) briefings.
Commitment to code late in the life cycle.
Integration nightmares (unpleasant experience) due to unforeseen implementation issues and interface
ambiguities.
Heavy budget and schedule pressure to get the system working.
Late shoe-homing of no optimal fixes, with no time for redesign.
A very fragile, unmentionable product delivered late.
In the conventional model, the entire system was designed on paper, then implemented all at once, then
integrated. 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. Early in the life cycle, as the requirements were being specified, the actual risk exposure was highly
unpredictable.
The following sequence of events was typical for most contractual software efforts:
1. The contractor prepared a draft contract-deliverable document that captured an intermediate artifact
and delivered it to the customer for approval.
2. The customer was expected to provide comments (typically within 15 to 30 days).
3. 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.
Barry Boehm's "Industrial Software Metrics Top 10 List is a good, objective characterization of the state of
software development.
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.
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.
2.1 SOFTWARE ECONOMICS
Most software cost models can be abstracted into a function of five basic parameters: size, process, personnel,
environment, and required quality.
1. 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
2. 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)
3. The capabilities of software engineering personnel, and particularly their experience with the
computer science issues and the applications domain issues of the project
4. The environment, which is made up of the tools and techniques available to support efficient
software development and to automate the process
5. 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:
One important aspect of software economics (as represented within today's software cost models) is that
the relationship between effort and size exhibits a diseconomy of scale. The diseconomy of scale of software
development is a result of the process exponent being greater than 1.0. Contrary to most manufacturing
processes, the more software you build, the more expensive it is per unit item.
Figure 2-1 shows three generations of basic technology advancement in tools, components, and processes.
The required levels of quality and personnel are assumed to be constant. The ordinate of the graph refers to
software unit costs (pick your favorite: per SLOC, per function point, per component) realized by an
organization.
The three generations of software development are defined as follows:
1) Conventional: 1960s and 1970s, craftsmanship. Organizations used custom tools, custom processes,
and virtually all custom components built in primitive languages. Project performance was highly
predictable in that cost, schedule, and quality objectives were almost always underachieved.
2) Transition: 1980s and 1990s, software engineering. Organiz:1tions used more-repeatable processes and off-
the-shelf tools, and mostly (>70%) custom components built in higher level languages. Some of the
components (<30%) were available as commercial products, including the operating system, database
management system, networking, and graphical user interface.
3) Modern practices: 2000 and later, software production. This book's philosophy is rooted in the
use of managed and measured processes, integrated automation environments, and mostly
(70%) off-the-shelf components. Perhaps as few as 30% of the components need to be custom
built
Technologies for environment automation, size reduction, and process improvement are not independent of
one another. In each new era, the key is complementary growth in all technologies. For example, the process
advances could not be used successfully without new component technologies and increased tool automation.
Organizations are achieving better economies of scale in successive technology eras-with very large projects
(systems of systems), long-lived products, and lines of business comprising multiple similar projects. 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.
2.2 PRAGMATIC SOFTWARE COST ESTIMATION
One critical problem in software cost estimation is a lack of well-documented case studies of projects that used
an iterative development approach. Software industry has inconsistently defined metrics or atomic units of
measure, the data from actual projects are highly suspect in terms of consistency and comparability. It is hard
enough to collect a homogeneous set of project data within one organization; it is extremely difficult to homog-
enize data across different organizations with different processes, languages, domains, and so on.
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:
3.1.1 LANGUAGES
Universal function points (UFPs1) 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. Some of these results are shown in Table 3-2.
Languages expressiveness of some of todays popular languages
LANGUAGES SLOC per UFP
Assembly 320
C 128
FORTAN77 105
COBOL85 91
Ada83 71
C++ 56
Ada95 55
Java 55
Visual Basic 35
Table 3-2
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.
1
Function point metrics provide a standardized method for measuring the various functions of a software application.
The basic units of function points are external user inputs, external outputs, internal logical data groups, external data interfaces, and
external inquiries.
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.
3.1.3 REUSE
Reusing existing components and building reusable components have been natural software engineering
activities since the earliest improvements in programming languages. With reuse in order to minimize
development costs while achieving all the other required attributes of performance, feature set, and quality. Try
to treat reuse as a mundane part of achieving a return on investment.
Most truly reusable components of value are transitioned to commercial products supported by
organizations with the following characteristics:
In a perfect software engineering world with an immaculate problem description, an obvious solution space, a
development team of experienced geniuses, adequate resources, and stakeholders with common goals, we
could execute a software development process in one iteration with almost no scrap and rework. Because we
work in an imperfect world, however, we need to manage engineering activities so that scrap and rework
profiles do not have an impact on the win conditions of any stakeholder. This should be the underlying
premise for most process improvements.
Software project managers need many leadership qualities in order to enhance team effectiveness. The
following are some crucial attributes of successful software project managers that deserve much more attention:
1. 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.
2. Customer-interface skill. Avoiding adversarial relationships among stakeholders is a prerequisite for
success.
Decision-making skill. The jillion books written about management have failed to provide a clear
definition of this attribute. 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. In practice, selling requires continuous negotiation, compromise,
and empathy
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, and 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
Conventional development processes stressed early sizing and timing estimates of computer program
resource utilization. However, the typical chronology of events in performance assessment was as follows
Project inception. The proposed design was asserted to be low risk with adequate performance
margin.
Initial design review. Optimistic assessments of adequate design margin were based mostly on paper
analysis or rough simulation of the critical threads. In most cases, the actual application algorithms
and database sizes were fairly well understood.
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. The underlying infrastructure was usually the scapegoat, but the real
culprit was immature use of the infrastructure, immature architectural solutions, or poorly understood
early design trade-offs.
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
Inspections are also a good vehicle for holding authors accountable for quality products. All authors of
software and documentation should have their products scrutinized as a natural by-product of the process.
Therefore, the coverage of inspections should be across all authors rather than across all components.
Top 10 principles of modern software management are. (The first five, which are the main themes of my definition of an
iterative process, are summarized in Figure 4-1.)
Base the process on an architecture-first approach. This requires that a demonstrable balance be achieved
among the driving requirements, the architecturally significant design decisions, and the life-cycle plans
before the resources are committed for full-scale development.
Establish an iterative life-cycle process that confronts risk early. With today's sophisticated software
systems, it is not possible to define the entire problem, design the entire solution, build the software, and
then test the end product in sequence. Instead, an iterative process that refines the problem understanding,
an effective solution, and an effective plan over several iterations encourages a balanced treatment of all
stakeholder objectives. Major risks must be addressed early to increase predictability and avoid expensive
downstream scrap and rework.
Transition design methods to emphasize component-based development. Moving from a line-of-code
mentality to a component-based mentality is necessary to reduce the amount of human-generated source
code and custom development.
Table 4-1 maps top 10 risks of the conventional process to the key attributes and principles of a modern
process
4.3 TRANSITIONING TO AN ITERATIVE PROCESS
Modern software development processes have moved away from the conventional waterfall model, in which
each stage of the development process is dependent on completion of the previous stage.
The economic benefits inherent in transitioning from the conventional waterfall model to an iterative
development process are significant but difficult to quantify. As one benchmark of the expected economic
impact of process improvement, consider the process exponent parameters of the COCOMO II model.
(Appendix B provides more detail on the COCOMO model) This exponent can range from 1.01 (virtually no
diseconomy of scale) to 1.26 (significant diseconomy of scale). The parameters that govern the value of the
process exponent are application precedentedness, process flexibility, architecture risk resolution, team
cohesion, and software process maturity.
The following paragraphs map the process exponent parameters of CO COMO II to my top 10 principles of
a modern process.
Application precedentedness. Domain experience is a critical factor in understanding how to plan and
execute a software development project. For unprecedented systems, one of the key goals is to confront
risks and establish early precedents, even if they are incomplete or experimental. This is one of the primary
reasons that the software industry has moved to an iterative life-cycle process. Early iterations in the life
cycle establish precedents from which the product, the process, and the plans can be elaborated in evolving
levels of detail.
Process flexibility. Development of modern software is characterized by such a broad solution space and
so many interrelated concerns that there is a paramount need for continuous incorporation of changes.
These changes may be inherent in the problem understanding, the solution space, or the plans. Project
artifacts must be supported by efficient change management commensurate with project needs. A
configurable process that allows a common framework to be adapted across a range of projects is
necessary to achieve a software return on investment.
Architecture risk resolution. Architecture-first development is a crucial theme underlying a successful
iterative development process. A project team develops and stabilizes architecture before developing all the
components that make up the entire suite of applications components. An architecture-first and
component-based development approach forces the infrastructure, common mechanisms, and control
mechanisms to be elaborated early in the life cycle and drives all component make/buy decisions into the
architecture process.
Team cohesion. Successful teams are cohesive, and cohesive teams are successful. Successful teams and
cohesive teams share common objectives and priorities. Advances in technology (such as programming
languages, UML, and visual modeling) have enabled more rigorous and understandable notations for
communicating software engineering information, particularly in the requirements and design artifacts that
previously were ad hoc and based completely on paper exchange. These model-based formats have also
enabled the round-trip engineering support needed to establish change freedom sufficient for evolving
design representations.
Software process maturity. The Software Engineering Institute's Capability Maturity Model (CMM) is a
well-accepted benchmark for software process assessment. One of key themes is that truly mature
processes are enabled through an integrated environment that provides the appropriate level of automation
to instrument the process for objective quality control.
Important questions
Explain briefly Waterfall model. Also explain Conventional s/w management performance?
1.
4. Explain five staffing principal offered by Boehm. Also explain Peer Inspections?
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:
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. 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
5.2 INCEPTION PHASE
The overriding goal of the inception phase is to achieve concurrence among stakeholders on the life-cycle
objectives for the project.
PRIMARY OBJECTIVES
Establishing 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 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 scenanos
Estimating the cost and schedule for the entire project (including detailed estimates for the
elaboration phase)
Estimating potential risks (sources of unpredictability)
ESSENTIAL ACTMTIES
Formulating the scope of the project. The information repository should be sufficient to define the
problem space and derive the acceptance criteria for the end product.
Synthesizing the architecture. An information repository is created that is sufficient to demonstrate the
feasibility of at least one candidate architecture and an, initial baseline of make/buy decisions so that
the cost, schedule, and resource estimates can be derived.
Planning and preparing a business case. Alternatives for risk management, staffing, iteration plans,
and cost/schedule/profitability trade-offs are evaluated.
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? (The
primary value of prototyping candidate architecture is to provide a vehicle for understanding the
scope and assessing the credibility of the development group in solving the particular technical
problem.)
Are actual resource expenditures versus planned expenditures acceptable
ESSENTIAL ACTIVITIES
Elaborating the vision.
Elaborating the process and infrastructure.
Elaborating the architecture and selecting components.
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 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?
Requirements Set
Requirements artifacts are evaluated, assessed, and measured through a combination of the following:
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 deploy-
ment, 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,
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.
The inception phase focuses mainly on critical requirements usually with a secondary focus on an initial
deployment view. 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.
Release Specifications
The scope, plan, and objective evaluation criteria for each baseline release are derived from the vision statement
as well as many other sources (make/buy analyses, risk management concerns, architectural considerations,
shots in the dark, implementation constraints, quality thresholds). These artifacts are intended to evolve along
with the process, achieving greater fidelity as the life cycle progresses and requirements understanding matures.
Figure 6-6 provides a default outline for a release specification
Release Descriptions
Release description documents describe the results of each release, including performance against each of the
evaluation criteria in the corresponding release specification. Release baselines should be accompanied by a
release description document that describes the evaluation criteria for that configuration baseline and provides
substantiation (through demonstration, testing, inspection, or analysis) that each criterion has been addressed in
an acceptable manner. Figure 6-7 provides a default outline for a release description.
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.
Management Artifact Sequences
In each phase of the life cycle, new artifacts are produced and previously developed artifacts are updated to
incorporate lessons learned and to capture further depth and breadth of the solution. Figure 6-8 identifies a
typical sequence of artifacts across the life-cycle phases.
6.3 ENGINEERING ARTIFACTS
Most of the engineering artifacts are captured in rigorous engineering notations such as UML, programming
languages, or executable machine codes. Three engineering artifacts are explicitly intended for more general
review, and they deserve further elaboration.
Vision Document
The vision document provides a complete vision for the software system under development and. supports the
contract between the funding authority and the development organization. A project vision is meant to be
changeable as understanding evolves of the requirements, architecture, plans, and technology. A good vision
document should change slowly. Figure 6-9 provides a default outline for a vision document.
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.
Software User Manual
The software user manual provides the user with the reference documentation necessary to support the delivered
software. Although content is highly variable across application domains, 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.
1. Major milestones. These system wide events are held at the end of each development phase. They
provide visibility to system wide issues, synchronize the management and engineering perspectives,
and verify that the aims of the phase have been achieved.
2. Minor milestones. These iteration-focused events are conducted to review the content of an iteration
in detail and to authorize continued work.
3. Status assessments. These periodic events provide management with frequent and regular insight
into the progress being made.
Each of the four phases-inception, elaboration, construction, and transition consists of one or more iterations
and concludes with a major milestone when a planned technical capability is produced in demonstrable form.
An iteration represents a cycle of activities for which there is a well-defined intermediate result-a minor
milestone-captured with two artifacts: a release specification (the evaluation criteria and plan) and a release
description (the results). Major milestones at the end of each phase use formal, stakeholder-approved evaluation
criteria and release descriptions; minor milestones use informal, development-team-controlled versions of these
artifacts.
Figure 9-1 illustrates a typical sequence of project checkpoints for a relatively large project.
9.1 MAJOR MILESTONES
The four major milestones occur at the transition points between life-cycle phases. They can be used in many
different process models, including the conventional waterfall model. Inan iterative model, the major milestones
are used to achieve concurrence among all stakeholders on the current state of the project. Different
stakeholders have very different concerns:
Customers: schedule and budget estimates, feasibility, risk assessment, requirements understanding,
progress, product line compatibility
Users: consistency with requirements and usage scenarios, potential for accommodating growth,
quality attributes
Architects and systems engineers: product line compatibility, requirements changes, trade-off
analyses, completeness and consistency, balance among risk, quality, and usability
Developers: sufficiency of requirements detail and usage scenario descriptions, . frameworks for
component selection or development, resolution of development risk, product line compatibility,
sufficiency of the development environment
Maintainers: sufficiency of product and documentation artifacts, understandability, interoperability
with existing systems, sufficiency of maintenance environment
Others: possibly many other perspectives by stakeholders such as regulatory agencies, independent
verification and validation contractors, venture capital investors, subcontractors, associate contractors,
and sales and marketing teams
Table 9-1 summarizes the balance of information across the major milestones.
Life-Cycle Objectives Milestone
The life-cycle objectives milestone occurs at the end of the inception phase. The goal is to present to all
stakeholders a recommendation on how to proceed with development, including a plan, estimated cost and
schedule, and expected benefits and cost savings. A successfully completed life-cycle objectives milestone will
result in authorization from all stakeholders to proceed with the elaboration phase.
The technical data listed in Figure 9-2 should have been reviewed by the time of the lifecycle architecture
milestone. Figure 9-3 provides default agendas for this milestone.
Initial Operational Capability Milestone
The initial operational capability milestone occurs late in the construction phase. The goals are to assess the
readiness of the software to begin the transition into customer/user sites and to authorize the start of acceptance
testing. Acceptance testing can be done incrementally across multiple iterations or can be completed entirely
during the transition phase is not necessarily the completion of the construction phase.
Product Release Milestone
The product release milestone occurs at the end of the transition phase. The goal is to assess the completion of
the software and its transition to the support organization, if any. The results of acceptance testing are
reviewed, and all open issues are addressed. Software quality metrics are reviewed to determine whether
quality is sufficient for transition to the support organization.
The format and content of these minor milestones tend to be highly dependent on the project and the
organizational culture. Figure 9-4 identifies the various minor milestones to be considered when a project is
being planned.
The default content of periodic status assessments should include the topics identified in Table 9-2.
10. Iterative process planning
A good work breakdown structure and its synchronization with the process framework are critical factors in
software project success. Development of a work breakdown structure dependent on the project management
style, organizational culture, customer preference, financial constraints, and several other hard-to-define,
project-specific parameters.
A WBS is simply a hierarchy of elements that decomposes the project plan into the discrete work tasks. A
WBS provides the following information structure:
A delineation of all significant work
A clear task decomposition for assignment of responsibilities
A framework for scheduling, budgeting, and expenditure tracking
Many parameters can drive the decomposition of work into discrete tasks: product subsystems, components,
functions, organizational units, life-cycle phases, even geographies. Most systems have a first-level
decomposition by subsystem. Subsystems are then decomposed into their components, one of which is typically
the software.
Figure 10-1 Conventional work breakdown structure, following the product hierarchy
Management
System requirement and design
Subsystem 1
Component 11
Requirements
Design
Code
Test
Documentation
(similar structures for other components)
Component 1N
Requirements
Design
Code
Test
Documentation
(similar structures for other subsystems)
Subsystem M
Component M1
Requirements
Design
Code
Test
Documentation
(similar structures for other components)
ComponentMN
Requirements
Design
Code
Test
Documentation
Integration and test
Test planning
Test procedure preparation
Testing
Test reports
Other support areas
Configuration control
Quality assurance
System administration
First-level WBS elements are the workflows (management, environment, requirements, design,
implementation, assessment, and deployment).
Second-level elements are defined for each phase of the life cycle (inception, elaboration,
construction, and transition).
Third-level elements are defined for the focus of activities that produce the artifacts of each phase.
A default WBS consistent with the process framework (phases, workflows, and artifacts) is shown in
Figure 10-2. This recommended structure provides one example of how the elements of the process
framework can be integrated into a plan. It provides a framework for estimating the costs and schedules of
each element, allocating them across a project organization, and tracking expenditures.
The structure shown is intended to be merely a starting point. It needs to be tailored to the specifics of a
project in many ways.
Scale. Larger projects will have more levels and substructures.
Organizational structure. Projects that include subcontractors or span multiple organizational entities
may introduce constraints that necessitate different WBS allocations.
Degree of custom development. Depending on the character of the project, there can be very different
emphases in the requirements, design, and implementation workflows.
Business context. Projects developing commercial products for delivery to a broad customer base
may require much more elaborate substructures for the deployment element.
Precedent experience. Very few projects start with a clean slate. Most of them are developed as new
generations of a legacy system (with a mature WBS) or in the context of existing organizational
standards (with preordained WBS expectations).
The WBS decomposes the character of the project and maps it to the life cycle, the budget, and the
personnel. Reviewing a WBS provides insight into the important attributes, priorities, and structure of the
project plan.
Another important attribute of a good WBS is that the planning fidelity inherent in each element is
commensurate with the current life-cycle phase and project state. Figure 10-3 illustrates this idea. One of the
primary reasons for organizing the default WBS the way I have is to allow for planning elements that range
from planning packages (rough budgets that are maintained as an estimate for future elaboration rather than
being decomposed into detail) through fully planned activity networks (with a well-defined budget and
continuous assessment of actual versus planned expenditures).
Figure 10-3 Evolution of planning fidelity in the WBS over the life cycle
Inception Elaboration
Transition Construction
1. The software project manager (and others) develops a characterization of the overall size, process,
environment, people, and quality required for the project.
2. A macro-level estimate of the total effort and schedule is developed using a software cost estimation
model.
3. The software project manager partitions the estimate for the effort into a top-level WBS using
guidelines such as those in Table 10-1.
4. At this point, subproject managers are given the responsibility for decomposing each of the WBS
elements into lower levels using their top-level allocation, staffing profile, and major milestone dates
as constraints.
The second perspective is a backward-looking, bottom-up approach. We start with the end in mind, analyze the
micro-level budgets and schedules, then sum all these elements into the higher level budgets and intermediate
milestones. This approach tends to define and populate the WBS from the lowest levels upward. From this per-
spective, the following planning sequence would occur:
1. The lowest level WBS elements are elaborated into detailed tasks
2. Estimates are combined and integrated into higher level budgets and milestones.
3. Comparisons are made with the top-down budgets and schedule milestones.
Milestone scheduling or budget allocation through top-down estimating tends to exaggerate the project
management biases and usually results in an overly optimistic plan. Bottom-up estimates usually exaggerate the
performer biases and result in an overly pessimistic plan.
These two planning approaches should be used together, in balance, throughout the life cycle of the
project. During the engineering stage, the top-down perspective will dominate because there is usually not
enough depth of understanding nor stability in the detailed task sequences to perform credible bottom-up
planning. During the production stage, there should be enough precedent experience and planning fidelity that
the bottom-up planning perspective will dominate. Top-down approach should be well tuned to the project-
specific parameters, so it should be used more as a global assessment technique. Figure 10-4 illustrates this life-
cycle planning balance.
Macro level task estimation for Micro level task estimation for
production stage artifacts production stage artifacts
Micro level task estimation for Macro level task estimation for
engineering artifacts maintenance of engineering artifacts
Stakeholder concurrence Stakeholder concurrence
Coarse grained variance analysis of Fine grained variance analysis of actual
actual vs planned expenditures vs planned expenditures
Tuning the top down project
independent planning guidelines into
project specific planning guidelines
WBS definition and elaboration