1

Software Project Planning

2

Introduction

• The overall goal of project planning is to establish a realistic strategy for controlling, tracking, and monitoring a complex technical project.

• Why?• So the end result gets done on time, with

quality!

3

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?

4

Continue…

Project ScopeEstimatesRisksScheduleControl strategy

SoftwareProject

Plan

5

Understanding Scope

• Understand the customers needs• understand the business context• understand the project boundaries• understand the customer’s motivation• understand the likely paths for change

6

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

• The planning objective is achieved through a process of information discovery that leads to reasonable estimates.

7

Decomposition Techniques

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

8

Software Sizing

• 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

software team.– The stability of product requirements and the environment that

supports the software engineering efforts.

9

Continue…

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

10

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

normalization value.– Function points are derived using an experimential relationship based

on the countable direct measures of software’s information domain and assessment of software complexity

11

Continue…

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

12

Continue…

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

13

Problem Based Estimation

• The LOC and FP data are used in two ways during software project estimation:

• 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 effort projections

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

14

Continue…

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

• When LOC is used as the estimation variable, decomposition is absolutely essential and is often taken to considerable levels of details.

15

16

LOC-Based Estimation

17

LOC-Based Estimation

Functions

UICF

2DGA

3DGA

DSM

CGDF

PCF

DAM

Totals

estimated LOC $/LOC Cost Effort (months)LOC/pm

2340

5380

6800

3350

4950

2140

8400

33,360

14

20

20

18

22

28

18

315

220

220

240

200

140

300

32,000

107,000

136,000

60,000

109,000

60,000

151,000

655,000

7.4

24.4

30.9

13.9

24.7

15.2

28.0

145.0

18

FP-Based Estimation

19

20

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces algorithms

measurement parameter

4 5 4 7 7 3

count

x x x x x x

count-total

= = = = = =

weight

complexity multiplier

feature points

0.25 p-m / FP = 120 p-m

40 25 12 4 4 60

160 125 48 28 28 180

569

.84

478

FP Based Estimation

21

Process Based Estimation

• Here, the process is decomposed into a relatively small set of tasks and the efforts required to accomplish each task is identified.

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

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

22

DFD and ERD

Quick Review

23

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

24

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

25

Entity Relation Diagram (ERD)

• The ERD is the notation that is used to conduct the data modeling activity.

• The objects and its relationship is/are the main parts in data modeling.

• These pairs can be represented graphically using the entity/relationship diagram.

• A set of primary components such as : data objects, attributes, relationships are identified in ERD

26

Cardinality

• It defines as the maximum number of objects that can participate in a relationship.

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

27

(0, m) (1, 1)

object objectrelationship1 2

One common form:

(0, m)

(1, 1)

object 1 object 2relationship

Another common form:attribute

ERD Notation!

28

(1,1) (1,m)placesCustomer

requestfor service

generates (1,n)

(1,1)

workorder

worktasks

materials

consistsof

lists

(1,1)(1,w)

(1,1)

(1,i)

selectedfrom

standardtask table

(1,w)

(1,1)

ERD: An Example

29

Need of DFD

30

Need of DFD

31

What are DFDs?

32

33

Symbols used in DFD

34

Continue…

35

Rules of Data Flow

36

Data Flow Diagrams

37

Styles in Drawing DFD

38

Describing a System with DFD

39

Context Diagram of Mess Management System

40

Leveling DFD

41

Why do we level DFD?

42

Expanded DFD for Hostel Mess Management System

43

Expanded DFD for Hostel Mess Management System

44

Expanded DFD Billing system

45

Leveling Rules

46

Illegal Construction

47

Illegal Construction in DFD

48

Leveling Examples

Refer PP 321

49

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.

• COCOMO 2 takes into account different approaches to software development, reuse, etc.

50

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

reusable components.– Post-architecture model. Used once the system

architecture has been designed and more information about the system is available.

51

COCOMO estimation models

52

Risk Management

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

53

Examples of common project, product, and business risks

Risk Affects Description

Staff turnover Project Experienced staff will leave the project before it is finished.

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.

CASE tool underperformance

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.

54

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;

55

The risk management process

56

Risk identification

• May be a team activities or based on the individual project manager’s experience.

• A checklist of common risks may be used to identify risks in a project– Technology risks.– People risks.– Organisational risks.– Requirements risks.– Estimation risks.

57

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)

58

Risk planning

• 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 reduced;

• Contingency plans– If the risk arises, contingency plans are plans to deal with

that risk;

59

Strategies to help manage risk

Risk Strategy

Organizational financial problems

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

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.

60

Strategies to help manage risk

Risk Strategy

Organizational restructuring

Prepare a briefing document for senior management showing how the project is making a very important contribution to the goals of the business.

Database performance

Investigate the possibility of buying a higher-performance database.

Underestimated development time

Investigate buying-in components; investigate use of a program generator.

61

Data Dictionary

• It is a repository that contains description of all data objects consumed or produced by the software.

62

Building a Data Dictionary

Name: Aliases: Where used: How used: Description: Format:

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)

63

Data Dictionary Notation

Notation

=

+

[ ]

{ }

( ... )

* ... text ...*

n

Meaning

is composed of

and

either-or

n repetitions of

optional data

delimits a comment

64

Data Dictionary Example

telephone numberintegrated

office phone system

Name: Aliases: Where/How used: Description: Format:

telephone number phone number, number read-phone-number (input) display-phone-number (output) analyze-long-distance-calls (input) 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:

alphanumeric data

system output