UNIT-IV

CHAPTER-1

ITERATIVE PROCESS PLANNING

Iterative Process Planning: Work breakdown structures, planning guidelines, cost and schedule
estimating, Iteration planning process, Pragmatic planning.

Project Organizations and Responsibilities: Line-of-Business Organizations, Project Organizations,

evolution of Organizations.

Process Automation: Automation Building blocks, The Project Environment

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.
CONVENTIONAL WBS ISSUES
Conventional work breakdown structures frequently suffer from three fundamental flaws.
1. They are prematurely structured around the product design.
2. They are prematurely decomposed, planned, and budgeted in either too much or too little
detail.
3. They are project-specific, and cross-project comparisons are usually difficult or impossible.
 Conventional work breakdown structures are prematurely structured around the product
design. Figure 10-1 shows a typical conventional WBS that has been structured primarily around
the subsystems of its product architecture, then further decomposed into the components of each
subsystem. A WBS is the architecture for the financial plan.
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)

Component MN

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
Conventional work breakdown structures are prematurely decomposed, planned, and
budgeted in either too little or too much detail.

 Large software projects tend to be over planned and small projects tend to be under
planned.
 The basic problem with planning too much detail at the outset is that the detail does not
evolve with the level of fidelity in the plan.
 Conventional work breakdown structures are project-specific, and cross-project
comparisons are usually difficult or impossible.
 With no standard WBS structure, it is extremely difficult to compare plans, financial data,
schedule data, organizational efficiencies, cost trends, productivity trends, or quality
trends across multiple projects
10.1.2 EVOLUTIONARY WORK BREAKDOWN STRUCTURES

An evolutionary WBS should organize the planning elements around the process framework rather
than the product framework.
The basic recommendation for the WBS is to organize the hierarchy as follows:
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-2 Default work

breakdown structure
A Management
AA Inception phase
management
AAA Business
case development
AAB
Elaboration phase release
specifications
AAC
BC Construction phase environment maintenance

BCA Development environment installation and administration

BCB SCO database maintenance

BD Transition phase environment maintenance

BDA Development environment maintenance and administration

BDB SCO database maintenance

BDC Maintenance environment packaging and transition

C Requirements

CA Inception phase requirements development

CCA Vision specification

CAB Use case modeling

CB Elaboration phase requirements baselining

CBA Vision baselining

CBB Use case model baselining

CC Construction phase requirements maintenance

CD Transition phase requirements maintenance

D Design

DA Inception phase architecture prototyping

DB Elaboration phase architecture baselining

DBA Architecture design modeling

DBB Design demonstration planning and conduct

DBC Software architecture description

DC Construction phase design modeling

DCA Architecture design model maintenance

DCB Component design modeling DD Transition phase design maintenance

Implementation

EA Inception phase component prototyping

EB Elaboration phase component implementation

EBA Critical component coding demonstration integration

EC Construction phase component implementation

ECA Initial release(s) component coding and stand-alone testing

ECB Alpha release component coding and stand-alone testing

ECC Beta release component coding and stand-alone testing

10.2 PLANNING GUIDELINES
Software projects span a broad range of application domains. It is valuable but risky to make
specific planning recommendations independent of project context.

It is valuable because most people in management positions are looking for a starting point a
skelton they can flesh out with project-specific details

Project-independent planning advice is also risky. There is the risk that the guidelines may pe
adopted blindly without being adapted to specific project circumstances.

Figure 10-3 Evolution of planning fidelity in the WBS over the life cycle

Two simple planning guidelines should be considered when a project plan is being initiated or
assessed. The first guideline, detailed in Table 10-1, prescribes a default allocation of costs
among the first-level WBS elements.
 The second guideline, detailed in Table 10-2, prescribes the allocation of effort and schedule
across the lifecycle phases .these values can also vary widely ,depending on the specific
constraints of an application ,they provide an average expectation across a spectrum of
application domain

DOMAIN INCEPTION ELABARATION CONSTRUCTION TRANSISTION

EFFORT 5% 20% 65% 10%
SCHEDULE 10% 30% 50% 10%

THE COST AND SCHEDULE ESTIMATING PROCESS

Project plans need to be derived from two perspectives.

The first is a forward-looking, top down approach. It starts with an understanding of the general
requirements and constraints, derives a macro-level budget and schedule, then decomposes these
elements into lower level budgets and intermediate milestones.

From this perspective, the following planning sequence would occur:

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

THE ITERATION PLANNING PROCESS

Planning is concerned with defining the actual sequence of intermediate results. An evolutionary
build plan is important because there are always adjustments in build content and schedule as
early conjecture evolves into well-understood project circumstances. Iteration is used to mean a
complete synchronization across the project, with a well orchestrated global assessment of the
entire project baseline.
 Inception iterations. The early prototyping activities integrate the foundation components of a
candidate architecture and provide an executable framework for elaborating the critical use cases
of the system. This framework includes existing components, commercial components, and
custom prototypes sufficient to demonstrate a candidate architecture and sufficient requirements
understanding to establish a credible business case, vision, and software development plan.

Elaboration iterations. These iterations result in architecture, including a complete framework

and infrastructure for execution. Upon completion of the architecture iteration, a few critical use
cases should be demonstrable: (1) initializing the architecture, (2) injecting a scenario to drive
the worst-case data processing flow through the system (for example, the peak transaction
throughput or peak load scenario), and (3) injecting a scenario to drive the worst-case control
flow through the system (for example, orchestrating the fault-tolerance use cases).

Construction iterations. Most projects require at least two major construction iterations:an
alpha release and a beta release.

Transition iterations. Most projects use a single iteration to transition a beta release into the
final product. 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

Two iterations in elaboration: architecture prototype and architecture baseline

Two iterations in construction: alpha and beta releases

One iteration in transition: product release

A very large or unprecedented project with many stakeholders may require additional inception
iteration and two additional iterations in construction, for a total of nine iterations.

PRAGMATIC PLANNING
 Even though good planning is more dynamic in an iterative process, doing it accurately is far
easier.
 While executing iteration N of any phase, the software project manager must be monitoring and
controlling against a plan that was initiated in iteration N - 1 and must be planning iteration N +
1. The art of good project·
 management is to make trade-offs in the current iteration plan and the next iteration plan based on
objective results in the current iteration and previous iterations.
 Aside from bad architectures and misunderstood requirements, inadequate planning (and
subsequent bad management) is one of the most common reasons for project failures.
 Conversely, the success of every successful project can be attributed in part to good planning.
 A project's plan is a definition of how the project requirements will be transformed into' a
product within the business constraints.
 It must be realistic, it must be current, it must be a team product, it must be understood by the
stakeholders, and it must be used. Plans are not just for managers.
 The more open and visible the planning process and results, the more ownership there is among
the team members who need to execute it. Bad, closely held plans cause attrition. Good, open
plans can shape cultures and encourage teamwork.
 UNIT-IV

CHAPTER-2

Project Organizations and Responsibilities: Line-of-Business Organizations, Project Organizations,

evolution of Organizations.

 Organizations engaged in software Line-of-Business need to support projects with the

infrastructure necessary to use a common process.
 Project organizations need to allocate artifacts & responsibilities across project team to ensure a
balance of global (architecture) & local (component) concerns.
 The organization must evolve with the WBS & Life cycle concerns.
 Software lines of business & product teams have different motivation.
 Software lines of business are motivated by return of investment (ROI), new business
discriminators, market diversification & profitability.
 Project teams are motivated by the cost, Schedule & quality of specific deliverables

 Project Organization is actually a structure that simply facilitates and motivates

coordination and implementation of activities of the project.
 Their main purpose is to simply create an environment that encourages development of
interactions between team members with very less amount of disruptions, overlaps, and
conflicts.
 The most important decision of a project management team is form of organization
structure that will be required and essential for the project. The organization should
evolve with Work Breakdown Structure (WBS) and life-cycle concerns.

1.Line-Of-Business Organizations:

Line business organizations need to support projects with infrastructure that are
necessary and essential to make use of a common process. Line of business simply a
general term that describes and explains products and services simply offered by a
business or manufacturer. Software lines of the business are generally motivated and
supported by Return of Investment (ROI), new business discriminators, market
diversification, and profitability .
The main features of default organization are as follows:
• Responsibility for process definition & maintenance is specific to a cohesive line of
business.
• Responsibility for process automation is an organizational role & is equal in importance
to the process definition role.
• Organizational role may be fulfilled by a single individual or several different teams .
Various authorities of Organization :

1. Software Engineering Process Authority (SEPA) –

It is team that is responsible for exchanging information and guidance of project both to
and from project practitioners. The project practitioners simply perform work and are
usually responsible for one or more process activities. SEPA is a very important and
essential role or responsibility in any of organizations.

2. Project Review Authority (PRA) –

Project review is simply a scheduled status meeting that is taken on a regular basis. It
includes project progress, issues, and risks. It is responsible for project review. The PRA
generally reviews both conformance to contractual obligations and organizational policy
obligations of project.

3. Software Engineering Environment Authority (SEEA) –

SEEA is a very important role and is very much needed to achieve an ROI for a common
process. It is simply responsible for supporting and managing a standard environment. Due
to this, different tools, techniques, and training can be effectively amortized across all types
of projects.

4. Infrastructure –
Organizational infrastructure generally consists of systems, protocols, and various
processes that provide structure to an organization, support human resources, supports
organization in carrying out its vision, mission, goals, and values. It can range from trivial
to largely entrenched bureaucracies. Various components of organizational infrastructure
are Project administration, Engineering skill centers, and professional development
Project organizations:
Project organizations generally need to allocate artifacts and responsibilities across project
team simply to ensure and confirm a balance of global (architecture) and local (component)
concerns.

The above figure shows a default project organization and maps project-level roles and
responsibilities.

• The main features of the default organization are as follows:

• The project management team is an active participant, responsible for producing as well as
managing.

• The architecture team is responsible for real artifacts and for the integration of components, not
just for staff functions.

• The development team owns the component construction and maintenance activities.• The
assessment team is separate from development.

• Quality is everyone’s into all activities and checkpoints. Each team takes responsibility for a
different quality perspective

Software management team

Most projects are over restricted. Schedule, costs, functionality, and quality expectations are high
interrelated and require continuous negotiation among multiple stakeholders who have different
goals
2) Software management team take the burden of delivering win conditions to all stakeholders
3) Software management team is responsible for planning the effort, conduction the plan, and
adapting the plan to changes in the understanding of the requirements or design.
4) The Software management team takes ownership of all aspects of quality.

Software Architecture Team

For many projects, the skills of software architecture team is crucial for achieving system-wide
qualities, and for implementing the applications
3) In most projects, the inception and elaboration phases will be handled by the software
management team and software architecture team.
4) This team is also responsible for system level quality such as reliability, performance, and
maintainability

Software Development Team

It is an application-specific group comprises several sub teams having common component skill
set. The following are from this set:
Commercial Component:
specialists with detailed knowledge of commercial components central to a system's architecture
b) Database: specialists with experience in the display organization, storage, and retrieval of
data
c) GUl's: specialists with experience in the display organization data presentation and user
interaction necessary to support human input output, and control needs.
d) Operating systems and networking: specialists with experience in the execution of multiple
software objects on a network
e) Domain applications: specialists with experience in the algorithms, application processing,
or business rules specific to the system.

Software Assessment Team

It should be a separate team why because of two reasons, one to assure the quality perspective
and two for using an independent test team.
Release specification: is an evaluation criteria will document what the customer may expect to
see a major milestone.
2) Release description: Which will validate the results.
Are the two artifacts in the modern process that will employ use-case-oriented or capability
based testing.
The assessment team is responsible for the quality of baseline releases with respect to the
requirements and customer expectations.
EVOLUTION OF ORGANIZATIONS:

Evaluation of organization or organizational evaluation is systematic process for

obtaining or getting valid information about performance of an organization and factors
that generally affect this performance.
It differs from other types of evaluation simply because it only concentrates and focuses
on organization as primary unit of analysis.
Through evaluation of the organization, effectiveness of an organization is counted and
measured in terms of its functioning, problems, and achievements from behavioural and
even social points of view.

Importance of Evaluation:
 It is needed to ensure whether objectives and goals being established are achieved or
not.
 It is needed to ensure that organization is adapting to new environments, changing
technology, and even changes in other external variables so as to efficiently utilize
available resources.
 It is needed for different modes to better fulfil and complete needs of clients of
institute.

Activities Emphasized in every Phase:

1. Inception Team –

It is an organization that moves from abstract, broad conversations into more detailed
discussions. They capture fine details of what’s going to happen next and work that is
 needed to be completed to achieve agreed-upon goal. This team simply focuses on
planning, with more support from various teams to just confirm and ensure that plans
represent general agreement of all perspectives.

2. Elaboration Team –:

This team gains handle on architecture of system. They simply begin setting up
environment for Construction by purchasing hardware, software, and tools. It is an
organization mainly focused on architecture in which driving forces of project simply
reside in software architecture team. They are supported by software development and
software assessment team. These teams have necessary and important to achieve stable
architecture baseline.

3. Construction Team

This team generally turn project or product vision into visual thing. They also work with
product manager to simply create user experience that fulfils requirements. It is fairly
balanced organization in which several activities reside in software development and even
in software assessment teams.

4. Transition Team

The transition team generally focuses on reviewing transition plans, monitoring progress,
providing resources that are needed, resolving issue, and escalation management. The
transition team also assesses and evaluates quality, status reporting, and even project
change control. It is actually an organization that focuses on customer in which feedback
from users simply drives deployment activities.