Planning a Software Project

1
Planning aSoftware Project
2

• Defining the Problem
• Defining the problem
• 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.
• Justify a computerized solution strategy for the
  problem
• Identify the functions to be provided by, and the
  constraints on, the hardware subsystem, the
  software subsystem and the people subsystem.
• Determine system-level goals and requirements for
  the development process and the work products
• Establish high-level acceptance criteria for the
  system

3

• Developing a solution strategy
• Outline several solution strategies, without
  regard for constraints.
• Conduct a feasibility study for each strategy.
• Recommend a solution strategy, indicating why
  other strategies were rejected.
• Develop a list of priorities for product
  characteristics
• Planning the development process
• Define a life-cycle model and an organizational
  structure for the project
• Plan, the configuration management, quality
  assurance and validation activities
• Determine phase-dependent tools, techniques and
  notations to be used

4

1. Establish preliminary cost estimates for system
   development
2. Establish a preliminary development schedule
3. Establish preliminary staffing estimates.
4. Develop preliminary estimates of the computing
   resources required to operate and maintain the
   system
5. Prepare a glossary of terms
6. Identify sources of information and refer to them
   throughout the project plan

5
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.
6
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 life-cycle model. The
software life cycle encompasses all activities
required to define, develop, test, deliver,
operate and maintain a software product
7
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.
8
The phased life cycle model
9
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 life-cycle model. The
software life cycle encompasses all activities
required to define, develop, test, deliver,
operate and maintain a software product
10
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
11
(No Transcript)
12
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
13
The Cost Model of the Software Life Cycle
14

• 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
• Illustrate input data formats, messages, reports
  and interactive dialogues for the customer.
• To explore technical issues in the proposed
  product
• Where a phased model is not appropriate.

15
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
16
Planning an organizational structure The tasks
include planning Product Development Services Publ
ications 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.
17
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 users
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
18
Other planning activities Planning for
configuration management and quality
assurance Planning for independent Verification
and validation Planning Phase-Dependent Tools
and Techniques Other Activities
19

• 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

20
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 Disadvantag
es Subjective
21

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

22

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

23

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

24

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

25
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 Person-Months required to
  develop a project.

26

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

27
Project Classes

• Organic mode small teams, familiar environment,
  well-understood applications, no difficult
  non-functional 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)

28
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