The document discusses various techniques for planning software projects, including scoping the project, estimating effort and timelines, identifying risks, creating schedules, and developing control strategies. It covers estimating project size through techniques like function point analysis and lines of code counting. It also discusses decomposing projects into sub-problems and estimating effort for each through methods like problem-based estimation and process-based estimation using standard components. Data flow diagrams and entity relationship diagrams are presented as tools for modeling systems and defining requirements.

1. Software Project Planning
1

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!
2

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?
3

4. Continue…
Project Scope
Estimates
Risks
Schedule
Control strategy
Software
Project
Plan
4

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
5

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

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

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

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

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
10

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

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

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

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

15. 15

16. LOC-Based Estimation
16

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
17

18. FP-Based Estimation
18

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

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

22. DFD and ERD
Quick Review
22

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
23

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
24

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
25

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

27. (0, m) (1, 1)
object objectrelationship
1 2
One common form:
(0, m)
(1, 1)
object 1 object 2
relationship
Another common form:
attribute
ERD Notation!
27

28. (1,1) (1,m)
placesCustomer
request
for service
generates (1,n)
(1,1)
work
order
work
tasks
materials
consists
of
lists
(1,1)
(1,w)
(1,1)
(1,i)
selected
from
standard
task table
(1,w)
(1,1)
ERD: An Example
28

29. Need of DFD
29

30. Need of DFD
30

31. What are DFDs?
31

32. 32

33. Symbols used in DFD
33

34. Continue…
34

35. Rules of Data Flow
35

36. Data Flow Diagrams
36

37. Styles in Drawing DFD
37

38. Describing a System with DFD
38

39. Context Diagram of Mess Management
System
39

40. Leveling DFD
40

41. Why do we level DFD?
41

42. Expanded DFD for Hostel Mess
Management System
42

43. Expanded DFD for Hostel Mess
Management System
43

44. Expanded DFD Billing system
44

45. Leveling Rules
45

46. Illegal Construction
46

47. Illegal Construction in DFD
47

48. Leveling Examples
Refer PP 321
48

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

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

51. COCOMO estimation models
51

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

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

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;
54

55. The risk management process
55

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

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

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;
58

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

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

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

62. Building a Data Dictionary
62
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
63
Notation
=
+
[ ]
{ }
( ... )
* ... text ...*
n
Meaning
is composed of
and
either-or
n repetitions of
optional data
delimits a comment

64. Data Dictionary Example
64
telephone number
integrated
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