Planning a
Software Project
1
Defining the Problem
Defining the problem
1. Develop a definitive statement of the problem to be
solved. Include a description of the present
situation, problem constraints and a statement of
the goals to be achieved.
2. Justify a computerized solution strategy for the
problem
3. Identify the functions to be provided by, and the
constraints on, the hardware subsystem, the
software subsystem and the people subsystem.
4. Determine system-level goals and requirements for
the development process and the work products
5. Establish high-level acceptance criteria for the
system
2
Developing a solution strategy
6. Outline several solution strategies, without regard
for constraints.
7. Conduct a feasibility study for each strategy.
8. Recommend a solution strategy, indicating why
other strategies were rejected.
9. Develop a list of priorities for product characteristics
Planning the development process
10.Define a life-cycle model and an organizational
structure for the project
11.Plan, the configuration management, quality
assurance and validation activities
12.Determine phase-dependent tools, techniques and
notations to be used
3
13.Establish preliminary cost estimates for system
development
14.Establish a preliminary development schedule
15.Establish preliminary staffing estimates.
16.Develop preliminary estimates of the computing
resources required to operate and maintain the
system
17.Prepare a glossary of terms
18.Identify sources of information and refer to them
throughout the project plan
4
Developing a solution strategy
A solution strategy is not a detailed solution, but
rather a general statement concerning the nature
possible solutions. Strategy factors include
considerations such as batch or time-sharing;
database or file system; graphics or text; real time or
off-line processing, etc
Several strategies should be considered before
one is adopted.
Strategies should be generalized without regard
for feasibility because it is not possible for humans to
be both creative and critical at the same time.
5
The feasibility of each proposed solution strategy
can be established by examining solution constraints.
It is extremely important to document the
reasons for rejecting other strategies. A solution
strategy should include a priority list of product
features.
Planning the development process
The first consideration is to define a product lifecycle model. The software life cycle encompasses all
activities required to define, develop, test, deliver,
operate and maintain a software product
6
The phased life cycle model
The phased model segments the software life
cycle into a series of successive activities. Each phase
requires well-defined input information, utilized well-
defined processes, and results in well-defined
products. Resources are required to complete the
process in each phase, and each phase is
accomplished through the application of explicit
methods, tools and techniques.
7
The phased life cycle model
8
The feasibility of each proposed solution strategy
can be established by examining solution constraints.
It is extremely important to document the
reasons for rejecting other strategies. A solution
strategy should include a priority list of product
features.
Planning the development process
The first consideration is to define a product lifecycle model. The software life cycle encompasses all
activities required to define, develop, test, deliver,
operate and maintain a software product
9
Milestones, Documents and Reviews
Another view of the software life cycle that
emphasizes the milestones, documents and review
throughout the product development. As a software
product evolves through the development cycle, it is
often difficult, if not impossible for project managers
and project team members to asses the progress, to
determine resources expended, to protect schedule
delays or to anticipate problem areas. Establishing
milestones, review points, standardized documents
and management sign offs can improve product
visibility
10
11
The Cost Model
Another view of the software life cycle can be
obtained by considering the cost of performing the
various activities in a software project. The cost of
conducting a software project is the sum of costs
incurred in conducting each phase of the project.
Costs incurred within each phase include the cost of
performing the processes and preparing the products
for the phase, plus the cost of verifying that the
products of the present phase are complete and
consistent with respect to all previous phases
12
The Cost Model of the
Software Life Cycle
13
The Prototype Life Cycle Model
Another view of the software development and
maintenance, emphasizes the sources of product
requests, the major go/no-go decision points and
the issues of prototypes. A prototype is a mock-up
or model of components of the actual product. A
prototype exhibits limited functional capabilities, low
reliability and/or inefficient performance.
Reasons for developing prototype
1. Illustrate input data formats, messages, reports and
interactive dialogues for the customer.
2. To explore technical issues in the proposed product
3. Where a phased model is not appropriate.
14
Successive Versions
Product development by the method of
successive versions is an extension of prototype in
which an initial product skeleton is refined into
increasing levels of capability
15
Planning an organizational structure
The tasks include planning
Product Development
Services
Publications
Quality Assurance
Support and Maintenance
The planning task identifies external customers
and internal product needs, conducts feasibility
studies and monitors progress from beginning to
end of the product life cycle.
16
The development task specifies designs,
implements, debugs, tests and integrates the product.
The service task provides automated tools and
computer resources for all other tasks, and perform
configuration management, product distribution and
miscellaneous administrative support.
The publication task develops user’s manuals,
installation instructions, principles or operation and
other supporting documents
The support task promotes the product, trains
users, installs the product. The maintenance task
provides error correction and minor enhancements
throughout the productive life cycle of the software
product
17
Other planning activities
Planning for configuration management and
quality assurance
Planning for independent Verification and
validation
Planning Phase-Dependent Tools and
Techniques
Other Activities
18
Software Cost Estimation
Estimating the cost of a software product is one
of the most difficult and error-prone tasks in SE. It is
difficult to make an accurate cost estimate during the
planning phase of software development, since so
many unknown factors will be there.
Expert Judgment
Delphi Cost Estimation
Work Breakdown Structure
Algorithmic Cost Models
19
Expert Judgment
The most widely used cost estimation technique
is expert judgment, which is an inherently top-down
estimation technique. Expert judgment relies on the
experience, background and business sense of one
or more key people in the organization.
The judgment will be based on a previous
project, which is almost similar.
Advantages: Empirical
Disadvantages: Subjective
20
Delphi Cost Estimation
The Delphi technique can be adapted to software
cost estimation in the following manner.
A coordinator provides each estimator with the
System Definition document and form for recording a
cost estimate.
Estimators study the definition and complete their
estimates anonymously. They may ask questions to
the coordinator, but they do not discuss their
estimates with one another.
The coordinator prepares and distributes a summary
of the estimators’ responses, and includes any
unusual rationales noted by the estimators.
21
Delphi Cost Estimation
Estimators complete another estimate again
anonymously using the results from the previous
estimate. Estimators whose estimates differ sharply
from the group may be asked, to provide justification
for their estimates.
The process is iterated for as many rounds as
required. No group discussion is allowed during the
entire process.
22
Work Breakdown Structure
The work breakdown structure is a bottom-up
estimation tool. A work breakdown structure is a
hierarchical chart that accounts for the individual parts
of a system. A WBS chart can indicate the product
hierarchy or process hierarchy.
We can use either a process WBS or a product
WBS for cost estimation. The primary advantages of
the WBS technique are in identifying and accounting
for various process and product factors, and in
making explicit exactly which costs are included in the
estimates.
23
Algorithmic Cost Models
Algorithmic cost estimators compute the
estimated cost of a software system as the sum of the
costs of the modules and subsystems that comprise
the system. Algorithmic cost models are bottom-up
estimators. The algorithmic method is designed to
provide some mathematical equations to perform
software estimation
The most widely used algorithmic model is the
Constructive Cost Model (COCOMO)
24
The COCOMO Model





Model to estimate the development cost and
schedule of a software project.
Introduced by Barry Boehm in 1981.
First two letters of the words Constructive Cost
Model
Primarily based on the software development
practices prior to 1980s, i.e. based on the
Waterfall model.
The most fundamental calculation in the
COCOMO model is the use of the Effort
Equation to estimate the number of PersonMonths required to develop a project.
25

COCOMO consists of a hierarchy of three
increasingly detailed and accurate forms.
Basic COCOMO - is a static, single-valued model
that computes software development effort (and cost)
as a function of program size expressed in estimated
lines of code.

Intermediate COCOMO - computes software
development effort as function of program size and a
set of "cost drivers" that include subjective
assessment of product, hardware, personnel and
project attributes.

Detailed COCOMO - incorporates all characteristics
of the intermediate version with an assessment of the
cost driver's impact on each step (analysis, design,
etc.) of the software engineering process.
26
Project Classes



Organic mode: small teams, familiar environment,
well-understood applications, no difficult nonfunctional requirements (EASY)
Semi-detached mode: Project team may have
experience mixture, system may have more
significant non-functional constraints, organization
may have less familiarity with application (HARDER)
Embedded: Hardware/software systems, tight
constraints, unusual for team to have deep
application experience (HARD)
27
Basic COCOMO Formula





Organic mode:
PM = 2.4 (KDSI)1.05
Semi-detached mode:
PM = 3 (KDSI)1.12
Embedded mode:
PM = 3.6 (KDSI)1.2
KDSI = Kilo Delivered Source Instructions
PM is the nominal effort in person months
28