Software Project Management (R20) Unit - III

7. Model Based Software Architectures  Achieving stable software architecture represents a significant
project milestone at which the critical make/buy decisions should
7.1 Architecture : A Management Perspective have been resolved.
 Architecture representations provide a basis for balancing the
The most critical technical product of a software project is its trade-offs between the problem space (requirements and
architecture: the infrastructure, control, and data interfaces that permit constraints) and the solution space (the operational product).
software components to cooperate as a system and software designers to  The architecture and process encapsulate many of the important
cooperate efficiently as a team. When the communications media include (high-payoff or high-risk) communications among individuals,
multiple languages and intergroup literacy varies, the communications teams, organizations, and stakeholders.
problem can become extremely complex and even unsolvable. If a  Poor architectures and immature processes are often given as
software development team is to be successful, the inter project reasons for project failures.
communications, as captured in the software architecture, must be both  A mature process, an understanding of the primary requirements,
accurate and precise. and a demonstrable architecture are important prerequisites for
predictable planning.
From a management perspective, there are three different aspects of  Architecture development and process definition are the
architecture. They are : intellectual steps that map the problem to a solution without
violating the constraints; they require human innovation and
1. An architecture (the intangible design concept) is the design of a cannot be automated.
software system this includes all engineering necessary to specify
a complete bill of materials. 7.2 Architecture : A Technical Perspective
2. An architecture baseline (the tangible artifacts) is a slice of
information across the engineering artifact sets sufficient to An architecture framework is defined in terms of views that are
satisfy all stakeholders that the vision (function and quality) can abstractions of the UML models in the design set. The design model
be achieved within the parameters of the business case (cost, includes the full breadth and depth of information. An architecture view
profit, time, technology, and people). is an abstraction of the design model; it contains only the architecturally
3. An architecture description (a human-readable representation of significant information. Most real-world systems require four views:
an architecture, which is one of the components of an architecture design, process, component, and deployment. The purposes of these
baseline) is an organized subset of information extracted from the views are as follows :
design set model(s). The architecture description communicates
how the intangible concept is realized in the tangible artifacts.  Design : describes architecturally significant structures and
functions of the design model
The number of views and the level of detail in each view can vary widely.
 Process : describes concurrency and control thread relationships
The importance of software architecture and its close linkage with
among the design, component, and deployment views
modern software development processes can be summarized as follows :
 Component : describes the structure of the implementation set
 Deployment : describes the structure of the deployment set

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 1 of 16
Software Project Management (R20) Unit - III

The following figure summarizes the artifacts of the design set, including The requirements model addresses the behavior of the system as seen by
the architecture views and architecture description : its end users, analysts, and testers. This view is modeled statically using
use case and class diagrams, and dynamically using sequence,
collaboration, state chart, and activity diagrams.
 The use case view describes how the system's critical
(architecturally significant) use cases are realized by elements of
the design model. It is modeled statically using use case diagrams,
and dynamically using any of the UML behavioral diagrams.
 The design view describes the architecturally significant
elements of the design model. This view, an abstraction of the
design model, addresses the basic structure and functionality of
the solution. It is modeled statically using class and object
diagrams, and dynamically using any of the UML behavioral
diagrams.
 The process view addresses the run-time collaboration issues
involved in executing the architecture on a distributed
deployment model, including the logical software network
topology (allocation to processes and threads of control),
interprocess communication, and state management. This view is
modeled statically using deployment diagrams, and dynamically
using any of the UML behavioral diagrams.
 The component view describes the architecturally significant
elements of the implementation set. This view, an abstraction of
the design model, addresses the software source code realization
of the system from the perspective of the project's integrators and
developers, especially with regard to releases and configuration
management. It is modeled statically using component diagrams,
and dynamically using any of the UML behavioral diagrams.
 The deployment view addresses the executable realization of the
system, including the allocation of logical processes in the
distribution view (the logical software topology) to physical
resources of the deployment network (the physical system
topology). It is modeled statically using deployment diagrams,
and dynamically using any of the UML behavioral diagrams.
Figure : Architecture, an organized and abstracted view into the design
models

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 2 of 16
Software Project Management (R20) Unit - III

Generally, an architecture baseline should include the following :

8. Workflows of the Process
 Requirements : critical use cases, system-level quality objectives,
and priority relationships among features and qualities 8.1 Software Process Workflows
 Design : names, attributes, structures, behaviors, groupings, and
The term ‘Workflows’ is used to mean a thread of cohesive and mostly
relationships of significant classes and components
sequential activities. Workflows are mapped to product artifacts. There
 Implementation : source component inventory and bill of
are seven top-level workflows :
materials (number, name, purpose, cost) of all primitive
components
1. Management workflow : controlling the process and ensuring
 Deployment : executable components sufficient to demonstrate
win conditions for all stakeholders
the critical use cases and the risk associated with achieving the
2. Environment workflow : automating the process and evolving
system qualities.
the maintenance environment
3. Requirements workflow : analyzing the problem space and
evolving the requirements artifacts
4. Design workflow : modeling the solution and evolving the
architecture and design artifacts
5. Implementation workflow : programming the components and
evolving the implementation and deployment artifacts
6. Assessment workflow : assessing the trends in process and
product quality
7. Deployment workflow : transitioning the end products to the
user
The following figure illustrates the relative levels of effort expected
across the phases in each of the top-level workflows :

Figure : Activity Levels across the life-cycle phases

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 3 of 16
Software Project Management (R20) Unit - III

The following table shows the allocation of artifacts and the emphasis of 8.2 Iteration Workflows
each workflow in each of the life-cycle phases of inception, elaboration,
construction, and transition : Iteration consists of a loosely sequential set of activities in various
proportions, depending on where the iteration is located in the
development cycle. Each iteration is defined in terms of a set of allocated
usage scenarios. An individual iteration's workflow, illustrated in the
figure below, generally includes the following sequence:

Figure : The workflow of an Iteration

 Management : iteration planning to determine the content of the

release and develop the detailed plan for the iteration;
assignment of work packages, or tasks, to the development team
 Environment : evolving the software change order database to
reflect all new baselines and changes to existing baselines for all
product, test, and environment components
 Requirements : analyzing the baseline plan, the baseline
architecture, and the baseline requirements set artifacts to fully
elaborate the use cases to be demonstrated at the end of this

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 4 of 16
Software Project Management (R20) Unit - III

iteration and their evaluation criteria; updating any requirements

set artifacts to reflect changes necessitated by results of this
iteration's engineering activities
 Design : evolving the baseline architecture and the baseline
design set artifacts to elaborate fully the design model and test
model components necessary to demonstrate against the
evaluation criteria allocated to this iteration; updating design set
artifacts to reflect changes necessitated by the results of this
iteration's engineering activities
 Implementation : developing or acquiring any new components,
and enhancing or modifying any existing components, to
demonstrate the evaluation criteria allocated to this iteration;
integrating and testing all new and modified components with
existing baselines (previous versions)
 Assessment : evaluating the results of the iteration, including
compliance with the allocated evaluation criteria and the quality
of the current baselines; identifying any rework required and
determining whether it should be performed before deployment
of this release or allocated to the next release; assessing results to
improve the basis of the subsequent iteration's plan
 Deployment : transitioning the release either to an external
organization (such as a user, independent verification and
validation contractor, or regulatory agency) or to internal closure
by conducting a post-mortem so that lessons learned can be Figure : Iteration emphasis across the life cycle
captured and reflected in the next iteration

Iterations in the inception and elaboration phases focus on management. An iteration represents the state of the overall architecture and the
Requirements, and design activities. Iterations in the construction phase complete deliverable system. An increment represents the current
focus on design, implementation, and assessment. Iterations in the progress that will be combined with the preceding iteration to from the
transition phase focus on assessment and deployment. The following next iteration. The following figure, an example of a simple development
figure shows the emphasis on different activities across the life cycle : life cycle, illustrates the differences between iterations and increments :

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 5 of 16
Software Project Management (R20) Unit - III

9. Checkpoints of the Process

Introduction

Three types of joint management reviews are conducted throughout the

process:

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.

The following figure illustrates a typical sequence of project checkpoints

for a relatively large project :

Figure : A typical build sequence associated with a layered architecture

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 6 of 16
Software Project Management (R20) Unit - III

 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
The following table summarizes the balance of information across the
major milestones :

Figure : A typical sequence of life cycle checkpoints

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. In an 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 Table : The general status of plans, requirements, and products across the
major milestones

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 7 of 16
Software Project Management (R20) Unit - III

Life-Cycle Objectives Milestone The following details refer to the default agendas for the life-cycle
architecture 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.

Life-Cycle Architecture Milestone

The life-cycle architecture milestone occurs at the end of the elaboration

phase. The primary goal is to demonstrate an executable architecture to
all stakeholders. The baseline architecture consists of both a human-
readable representation (the architecture document) and a configuration-
controlled set of software components captured in the engineering
artifacts. A successfully completed life-cycle architecture milestone will
result in authorization from the stakeholders to proceed with the
construction phase.

The technical data (engineering artifacts available at the life-cycle

architecture milestone) listed as under should have been reviewed by
the time of the lifecycle architecture milestone :

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 8 of 16
Software Project Management (R20) Unit - III

Initial Operational Capability Milestone The format and content of these minor milestones tend to be highly
dependent on the project and the organizational culture. The following
The initial operational capability milestone occurs late in the construction figure identifies the various minor milestones to be considered when a
phase. The goals are to assess the readiness of the software to begin the project is being planned :
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.

9.1 Minor Milestones

For most iterations, which have a one-month to six-month duration, only

two minor milestones are needed :
Figure : Typical minor milestones in the life cycle of an iteration
i. Iteration Readiness Review. This informal milestone is
conducted at the start of each iteration to review the detailed
iteration plan and the evaluation criteria that have been allocated 9.3 Periodic Status Assessments
to this iteration .
ii. Iteration Assessment Review. This informal milestone is Periodic status assessments are management reviews conducted at
conducted at the end of each iteration to assess the degree to regular intervals (monthly, quarterly) to address progress and quality
which the iteration achieved its objectives and satisfied its indicators, ensure continuous attention to project dynamics, and
evaluation criteria, to review iteration results, to review maintain open communications among all stakeholders.
qualification test results (if part of the iteration), to determine the
amount of rework to be done, and to review the impact of the Periodic status assessments serve as project snapshots. While the period
iteration results on the plan for subsequent iterations. may vary, the recurring event forces the project history to be captured
and documented. Status assessments provide the following :

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 9 of 16
Software Project Management (R20) Unit - III

 A mechanism for openly addressing, communicating, and 10. Iterative Process Planning
resolving management issues, technical issues, and project risks
 Objective data derived directly from on-going activities and Introduction
evolving product configurations
 A mechanism for disseminating process, progress, quality trends, Like software development, project planning requires an iterative
practices, and experience information to and from all process. Like software, a plan is an intangible piece of intellectual
stakeholders in an open forum property to which all the same concepts must be applied. Plans have an
engineering stage, during which the plan is developed, and a production
Periodic status assessments are crucial for focusing continuous attention stage, when the plan is executed. Plans must evolve as the understanding
on the evolving health of the project and its dynamic priorities. They force evolves of the problem space and the solution space. Planning errors are
the software project manager to collect and review the data periodically, just like product errors : The sooner in the life cycle they are resolved, the
force outside peer review, and encourage dissemination of best practices less impact they have on project success.
to and from other stakeholders.
10.1 Work Breakdown Structures
The default content of periodic status assessments should include the
topics identified in the following table : 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 :

1. A delineation of all significant work

2. A clear task decomposition for assignment of responsibilities
3. 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 first-level
decomposition by subsystem. Subsystems are then decomposed into
their components, one of which is typically the software.
Table : Default content of status assessment reviews

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 10 of 16
Software Project Management (R20) Unit - III

10.1.1 Conventional WBS Issues Subsystem M

Component M1
Conventional work breakdown structures frequently suffer from three Requirements
fundamental flaws : Design
Code
1. They are prematurely structured around the product design.
Test
2. They are prematurely decomposed, planned, and budgeted in
Documentation
either too much or too little detail.
…(similar structures for other components)
3. They are project-specific, and cross-project comparisons are
usually difficult or impossible. Component MN
Requirements
Conventional work breakdown structures are prematurely structured Design
around the product design. A WBS is the architecture for the financial Code
plan. The following section shows a typical conventional WBS that has Test
been structured primarily around the subsystems of its product Documentation
architecture, then further decomposed into the components of each Integration and test
subsystem : Test planning
Test procedure preparation
Management Testing
System requirement and design Test reports
Subsystem 1 Other support areas
Component 11 Configuration control
Requirements Quality assurance
Design System administration
Code
Test
Documentation Conventional work breakdown structures are prematurely
…(similar structures for other components) decomposed, planned, and budgeted in either too little or too much
Component 1N detail. Large software projects tend to be over planned and small projects
Requirements tend to be under planned. The basic problem with planning too much
Design detail at the outset is that the detail does not evolve with the level of
Code fidelity in the plan.
Test
Documentation
Conventional work breakdown structures are project-specific, and
cross-project comparisons are usually difficult or impossible. With no
…(similar structures for other subsystems)
standard WBS structure, it is extremely difficult to compare plans,

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 11 of 16
Software Project Management (R20) Unit - III

financial data, schedule data, organizational efficiencies, cost trends, AD Transition phase management
productivity trends, or quality trends across multiple projects. ADA Next generation planning
ADB Transition phase project control and status assessments
10.1.2 Evolutionary Work Breakdown Structures B Environment
BA Inception phase environment specification
An evolutionary WBS should organize the planning elements around the BB Elaboration phase environment baselining
process framework rather than the product framework. The basic BBA Development environment installation and administration
recommendation for the WBS is to organize the hierarchy as follows : BBB Development environment integration and custom
toolsmithing
 First-level WBS elements are the workflows (management, BBC SCO database formulation
BC Construction phase environment maintenance
environment, requirements, design, implementation, assessment,
BCA Development environment installation and administration
and deployment).
BCB SCO database maintenance
 Second-level elements are defined for each phase of the life
BD Transition phase environment maintenance
cycle (inception, elaboration, construction, and transition).
BDA Development environment maintenance and
 Third-level elements are defined for the focus of activities that administration
produce the artifacts of each phase. BDB SCO database maintenance
BDC Maintenance environment packaging and transition
A default WBS consistent with the process framework (phases, C Requirements
workflows, and artifacts) is shown as below : CA Inception phase requirements development
CCA Vision specification
A Management CAB Use case modeling
AA Inception phase management CB Elaboration phase requirements baselining
AAA Business case development CBA Vision baselining
AAB Elaboration phase release specifications CBB Use case model baselining
AAC Elaboration phase WBS specifications CC Construction phase requirements maintenance
AAD Software development plan CD Transition phase requirements maintenance
AAE Inception phase project control and status assessments D Design
AB Elaboration phase management DA Inception phase architecture prototyping
ABA Construction phase release specifications DB Elaboration phase architecture baselining
ABB Construction phase WBS baselining DBA Architecture design modeling
ABC Elaboration phase project control and status DBB Design demonstration planning and conduct
assessments DBC Software architecture description
AC Construction phase management DC Construction phase design modeling
ACA Deployment phase planning DCA Architecture design model maintenance
ACB Deployment phase WBS baselining DCB Component design modeling
ACC Construction phase project control and status DD Transition phase design maintenance
assessments

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 12 of 16
Software Project Management (R20) Unit - III

E Implementation The structure shown is intended to be merely a starting point. It needs to

EA Inception phase component prototyping be tailored to the specifics of a project in many ways, as follows :
EB Elaboration phase component implementation
EBA Critical component coding demonstration integration  Scale. Larger projects will have more levels and substructures.
EC Construction phase component implementation  Organizational structure. Projects that include subcontractors
ECA Initial release(s) component coding and stand-alone or span multiple organizational entities may introduce
testing constraints that necessitate different WBS allocations.
ECB Alpha release component coding and stand-alone testing
 Degree of custom development. Depending on the character of
ECC Beta release component coding and stand-alone testing
the project, there can be very different emphases in the
ECD Component maintenance
requirements, design, and implementation workflows.
F Assessment
 Business context. Projects developing commercial products for
FA Inception phase assessment
delivery to a broad customer base may require much more
FB Elaboration phase assessment
FBA Test modeling
elaborate substructures for the deployment element.
FBB Architecture test scenario implementation  Precedent experience. Very few projects start with a clean slate.
FBC Demonstration assessment and release descriptions Most of them are developed as new generations of a legacy
FC Construction phase assessment system (with a mature WBS) or in the context of existing
FCA Initial release assessment and release description organizational standards (with preordained WBS expectations).
FCB Alpha release assessment and release description
FCC Beta release assessment and release description
FD Transition phase assessment The WBS decomposes the character of the project and maps it to the life
FDA Product release assessment and release description cycle, the budget, and the personnel. Reviewing a WBS provides insight
G Deployment into the important attributes, priorities, and structure of the project plan.
GA Inception phase deployment planning
GB Elaboration phase deployment planning Another important attribute of a good WBS is that the planning fidelity
GC Construction phase deployment inherent in each element is commensurate with the current life-cycle
GCA User manual baselining phase and project state. The figure in the next page illustrates this idea.
GD Transition phase deployment
GDA Product transition to user One of the primary reasons for organizing the default WBS in this way 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
This recommended structure provides one example of how the elements networks (with a well-defined budget and continuous assessment of
of the process framework can be integrated into a plan. It provides a actual versus planned expenditures).
framework for estimating the costs and schedules of each element,
allocating them across a project organization, and tracking expenditures.

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 13 of 16
Software Project Management (R20) Unit - III

First Level WBS Element Default Budget

Management 10%
Environment 10%
Requirement 10%
Design 15%
Implementation 25%
Assessment 25%
Deployment 5%
Total 100%

Table : Web budgeting defaults

The second guideline, detailed in the following table, prescribes the

allocation of effort and schedule across the lifecycle phases :

Domain Inception Elaboration Construction Transition

Effort 5% 20% 65% 10%
Schedule 10% 30% 50% 10%

Figure : Evolution of planning fidelity in the WBS over the life cycle Table : Default distributions of effort and schedule by phase

10.3 The Cost and Schedule Estimate Process

10.2 Planning Guidelines
Project plans need to be derived from two perspectives. The first is a
Software projects span a broad range of application domains. It is forward-looking, top-down approach. It starts with an understanding of
valuable but risky to make specific planning recommendations the general requirements and constraints, derives a macro-level budget
independent of project context. Project-independent planning advice is and schedule, then decomposes these elements into lower level budgets
also risky. There is the risk that the guidelines may be adopted blindly and intermediate milestones. From this perspective, the following
without being adapted to specific project circumstances. Two simple planning sequence would occur :
planning guidelines should be considered when a project plan is being
initiated or assessed. The first guideline, detailed in table below, 1. The software project manager (and others) develops a
prescribes a default allocation of costs among the first-level WBS characterization of the overall size, process, environment, people,
elements : 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.

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 14 of 16
Software Project Management (R20) Unit - III

3. The software project manager partitions the estimate for the

effort into a top-level WBS using guideline such as those in the
Web budgeting defaults table given above.
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 perspective, 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 mile- stones.
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 Figure : Planning balance throughout the life cycle
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. The following figure
illustrates this life-cycle planning balance :

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 15 of 16
Software Project Management (R20) Unit - III

10.4 The Iteration Planning Process  Two iterations in elaboration : architecture prototype and
architecture baseline
Planning is concerned with defining the actual sequence of intermediate  Two iterations in construction : alpha and beta releases
results. An evolutionary build plan is important because there are always  One iteration in transition : product release
adjustments in build content and schedule as early conjecture evolves
into well-understood project circumstances. Iteration is used to mean a A very large or unprecedented project with many stakeholders may
complete synchronization across the project, with a well-orchestrated require additional inception iteration and two additional iterations in
global assessment of the entire project baseline. construction, for a total of nine iterations.

 Inception iterations. The early prototyping activities integrate the 10.5 Pragmatic Planning
foundation components of a candidate architecture and provide
an executable framework for elaborating the critical use cases of Even though good planning is more dynamic in an iterative process, doing
the system. This frame-work includes existing components, it accurately is far easier. While executing iteration N of any phase, the
commercial components, and custom prototypes sufficient to software project manager must be monitoring and controlling against a
demonstrate a candidate architecture and sufficient requirements plan that was initiated in iteration N - 1 and must be planning iteration
understanding to establish a credible business case, vision, and N + 1. The art of good project management is to make trade-offs in the
software development plan. current iteration plan and the next iteration plan based on objective
 Elaboration iterations. These iterations result in architecture, results in the current iteration and previous iterations. Aside from bad
including a complete framework and infrastructure for execution. architectures and misunderstood requirements, inadequate planning
Upon completion of the architecture iteration, a few critical use (and subsequent bad management) is one of the most common reasons
cases should be demonstrable: (1) initializing the architecture, (2) for project failures. Conversely, the success of every successful project
injecting a scenario to drive the worst-case data processing flow can be attributed in part to good planning.
through the system (for example, the peak transaction throughput
or peak load scenario), and (3) injecting a scenario to drive the A project's plan is a definition of how the project requirements will be
worst-case control flow through the system (for example, transformed into' a product within the business constraints. It must be
orchestrating the fault-tolerance use cases). realistic, it must be current, it must be a team product, it must be
 Construction iterations. Most projects require at least two major understood by the stakeholders, and it must be used. Plans are not just
construction iterations: an alpha release and a beta release. for managers. The more open and visible the planning process and
 Transition iterations. Most projects use a single iteration to results, the more ownership there is among the team members who need
transition a beta release into the final product. to execute it. Bad, closely held plans cause attrition. Good, open plans can
shape cultures and encourage teamwork.
The general guideline is that most projects will use between four and nine
iterations. The typical project would have the following six-iteration
profile :

 One iteration in inception : an architecture prototype =========== END OF UNIT-III ===========

Compiled by : Dr. K.N.V.R.Kumar

STMW, Guntur Page 16 of 16