• The overall goal of project planning is to
establish a realistic strategy for controlling,
tracking, and monitoring a complex technical
• So the end result gets done on time, with
The Steps in Project Planning
• Scoping—understand the problem and the work
that must be done
• Estimation—how much effort? how much time?
• Risk—what can go wrong? how can we avoid it?
what can we do about it?
• Schedule—how do we allocate resources along
the timeline? what are the milestones?
• Control strategy—how do we control quality?
how do we control change?
• Understand the customers needs
• understand the business context
• understand the project boundaries
• understand the customer’s motivation
• understand the likely paths for change
Project Planning Objectives
• The main objective of software project planning is to provide
a framework that enables the manager to make reasonable
estimates of resources, cost, and schedule.
• These estimates are made within a limited time frame at the
beginning of a software project and should be updated
regularly as the project progresses.
• In addition, estimates should attempt to define best case and
worst case scenario so that project outcomes can be
• The planning objective is achieved through a process of
information discovery that leads to reasonable estimates.
• Software project estimation is a form of problem solving and
in most of the cases, the problem to be solved ( i.e.
developing a cost and efforts estimate for a software project)
is to complex to be considered as one piece.
• So, there is a need of decomposing the main problem into set
of sub problems( manageable Unit)
• We also call this approach as “ Divide and Conquer” .
• Decomposition can be for “Process” or “Problem”
• Estimation uses a single or both decomposition process.
• Before applying any one of the decomposition process,
software sizing, problem based estimation and process based
estimation are to be known.
• The accuracy of a software project estimate is predicated on a
number of things:
– The degree to which the planner has properly estimated the size of
the product to be built.
– The ability to translate the size estimate into human efforts, calendar
time and cost.
– The degree to which the project plan reflects the abilities of the
– The stability of product requirements and the environment that
supports the software engineering efforts.
• Let’s consider software sizing problem.
• A project estimate is only as good as the estimate of the size
of the work to be accomplished, sizing represent the project
planner’s first major challenge.
• In the context of project planning, the size refers to a
quantifiable outcome of the software project.
• In a direct approach, size can be measured in LOC and in
indirect approach, size is represented as FP.
Approaches to the Sizing Problem
• “Fuzzy Logic” sizing:
– This approach uses the appropriate reasoning techniques that are the
foundation of fuzzy logic.
– To apply this approach, the planner must identify the type of
application, establish its magnitude on a qualitative scale, and then
refine the magnitude within the original range.
• Function point sizing:
– It uses a measure of the functionality delivered by the application as a
– Function points are derived using an experimential relationship based
on the countable direct measures of software’s information domain
and assessment of software complexity
• Standard component sizing:
– Software is composed of a number of different standard components
that are generic to a particular application area.
– Example: Standard components for an information system are
subsystem, modules, screens, reports, interactive programs, batch
programs, files, LOC, and object level instructions.
– The project planner estimates the number of occurrence of each
standard component and then uses historical project data to
determine the delivered size as per standard component.
• Change sizing:
– This approach is used when a project encompasses the use of existing
software that must be modified in some way as part of project.
– The planner estimates the number and type( eg: reuse, adding code,
changing code, deleting code) of modifications that must be
Problem Based Estimation
• The LOC and FP data are used in two ways during software
• As an estimation variable to size each element of the software
• As baseline metrics collected from past projects and used in
conjunction with estimation variables to develop cost and
• LOC and FP are distinct estimation techniques: but they have
few common features.
• The project planner begins with bounded statements of
software scope and from this statement attempts are made to
decompose software into problem functions that can each be
• LOC and FP is then estimated for each functions.
• Baseline productivity metrics ( e.g. LOC/pm or FP/pm9) are
then applied to the appropriate estimation variable, and cost
or effort for the function derive.
• Function estimates are combined to produce an overall
estimate of the entire project.
• The LOC and FP estimation techniques differ in the level of
details required for decomposition and the target of the
• When LOC is used as the estimation variable, decomposition
is absolutely essential and is often taken to considerable
levels of details.
number of user inputs
number of user outputs
number of user inquiries
number of files
number of ext.interfaces
0.25 p-m / FP = 120 p-m
FP Based Estimation
Process Based Estimation
• Here, the process is decomposed into a relatively small set of
tasks and the efforts required to accomplish each task is
• Like the problem based estimation, process based estimation
begins with a description of software functions obtained from
the project scope.
• A series of software process activities must be performed for
• Once problem functions and process activities are melded ,
the planner estimates the efforts ( eg. Person-month) that will
be required to accomplish each software process activity for
each software functions.
Elements of Analysis Model
• The analysis model must achieve three primary objectives:
– To describe what the customer requires
– To establish a basis for the creation of a software design
– To define a set of requirements that can be validated once
the software is built
Why Data Modeling?
• examines data objects independently of processing
• focuses attention on the data domain
• creates a model at the customer’s level of abstraction
• indicates how data objects relate to one another
Entity Relation Diagram (ERD)
• The ERD is the notation that is used to conduct the data
• The objects and its relationship is/are the main parts in data
• These pairs can be represented graphically using the
• A set of primary components such as : data objects,
attributes, relationships are identified in ERD
• It defines as the maximum number of objects that can participate in
• It is the specification of the number of occurrences of one object
that can be related to the number of occurrence of another object.
• One to One ( 1:1) : An occurrence of object “A” can relate to one
and only one occurrence of object “B”; and vice versa
• One to Many ( 1:N) : One occurrence of object “A” can relate to one
or many occurrence of object “B”; but an occurrence of object “B”
can relate to only one occurrence of object ‘A”
• Many to Many (M:N) : An occurrence of object “A” can relate to one
or more occurrence of object “B” and vice versa.
• Students are asked to refer PP 319 for details.
(0, m) (1, 1)
One common form:
object 1 object 2
Another common form:
ERD: An Example
The COCOMO 2 model
• An empirical model based on project experience.
• Well-documented, ‘independent’ model which is not tied
to a specific software vendor.
• Long history from initial version published in 1981
(COCOMO-81) through various instantiations to
• COCOMO 2 takes into account different approaches to
software development, reuse, etc.
COCOMO 2 models
• COCOMO 2 incorporates a range of sub-models that produce
increasingly detailed software estimates.
• The sub-models in COCOMO 2 are:
– Application composition model. Used when software is
composed from existing parts.
– Early design model. Used when requirements are available
but design has not yet started.
– Reuse model. Used to compute the effort of integrating
– Post-architecture model. Used once the system
architecture has been designed and more information
about the system is available.
• Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
• A risk is a probability that some adverse circumstance will
– Project risks affect schedule or resources;
– Product risks affect the quality or performance of the
software being developed;
– Business risks affect the organisation developing or
procuring the software.
Examples of common project, product,
and business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
Management change Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Project and product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and product Specifications of essential interfaces are not
available on schedule.
Size underestimate Project and product The size of the system has been underestimated.
Product CASE tools, which support the project, do not
perform as anticipated.
Technology change Business The underlying technology on which the system
is built is superseded by new technology.
Product competition Business A competitive product is marketed before the
system is completed.
The risk management process
• Risk identification
– Identify project, product and business risks;
• Risk analysis
– Assess the likelihood and consequences of these risks;
• Risk planning
– Draw up plans to avoid or minimise the effects of the risk;
• Risk monitoring
– Monitor the risks throughout the project;
• May be a team activities or based on the individual project
• A checklist of common risks may be used to identify risks in a
– Technology risks.
– People risks.
– Organisational risks.
– Requirements risks.
– Estimation risks.
Examples of different risk types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per
second as expected. (1)
Reusable software components contain defects that mean they cannot be reused
as planned. (2)
People It is impossible to recruit staff with the skills required. (3)
Key staff are ill and unavailable at critical times. (4)
Required training for staff is not available. (5)
Organizational The organization is restructured so that different management are responsible for
the project. (6)
Organizational financial problems force reductions in the project budget. (7)
Tools The code generated by software code generation tools is inefficient. (8)
Software tools cannot work together in an integrated way. (9)
Requirements Changes to requirements that require major design rework are proposed. (10)
Customers fail to understand the impact of requirements changes. (11)
Estimation The time required to develop the software is underestimated. (12)
The rate of defect repair is underestimated. (13)
The size of the software is underestimated. (14)
• Consider each risk and develop a strategy to manage that risk.
• Avoidance strategies
– The probability that the risk will arise is reduced;
• Minimisation strategies
– The impact of the risk on the project or product will be
• Contingency plans
– If the risk arises, contingency plans are plans to deal with
Strategies to help manage risk
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business and presenting
reasons why cuts to the project budget would not be cost-
Recruitment problems Alert customer to potential difficulties and the possibility of
delays; investigate buying-in components.
Staff illness Reorganize team so that there is more overlap of work and
people therefore understand each other’s jobs.
Defective components Replace potentially defective components with bought-in
components of known reliability.
Requirements changes Derive traceability information to assess requirements
change impact; maximize information hiding in the design.
Strategies to help manage risk
Prepare a briefing document for senior management
showing how the project is making a very important
contribution to the goals of the business.
Investigate the possibility of buying a higher-performance
Investigate buying-in components; investigate use of a
• It is a repository that contains description of all data objects
consumed or produced by the software.
Building a Data Dictionary
the primary name of the composite data item
other names for the data item
data transforms (processes) that use the
composite data item
the role of the data item (input, output,
temporary storage, etc.
a notation for representing content (presented
on next slide)
specific information about data types, pre-set
values (if known)
Data Dictionary Notation
( ... )
* ... text ...*
is composed of
n repetitions of
delimits a comment
Data Dictionary Example
phone number, number
telephone no. = [ local extension | outside no. | 0]
outside no. = 9 + [ service code | domestic no. ]
service code = [ 211 |411 |611 |911 ]
domestic no. = ( ( 0 ) + area code ) + local number
area code = *three numeral designator*
Build the requirements dictionary: