SOFTWARE PROJECT PLANNING

1
SOFTWARE PROJECT PLANNING
2
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

3
Fundamental estimation questions

• How much effort is required to complete an
  activity?
• How much calendar time is needed to complete an
  activity?
• What is the total cost of an activity?
• Project estimation and scheduling and interleaved
  management activities

4
Planning and estimating

• Ideally, we would like to plan the entire
  software project at the very beginning of the
  process
• The earliest possible detailed planning is after
  the specification phase
• Accuracy of estimation increases as the process
  proceeds
• Accurate duration estimation is critical
• Accurate cost estimation is critical
• Internal cost
• External cost
• There are too many variables for accurate
  estimate of cost or duration

5
Software pricing factors
There is not a simple relationship between the
development cost and the price charged to the
customer
6
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

7
Programmer productivity

• A measure of the rate at which individual
  engineers involved in software development
  produce software and associated documentation
• Not quality-oriented although quality assurance
  is a factor in productivity assessment
• Essentially, we want to measure useful
  functionality produced per time unit

8
Productivity measures

• Size related measures based on some output from
  the software process. This may be lines of
  delivered source code, object code instructions,
  etc.
• Function-related measures based on an estimate of
  the functionality of the delivered software.
  Function-points are the best known of this type
  of measure

9
Lines of code

• Lines of code (LOC), or
• Thousand delivered source instructions (KDSI)
• Source code is only a small part of total
  software effort
• Different languages ? different lengths of code
• LOC not defined for nonprocedural languages (like
  LISP)
• It is not clear how to count lines of code
• Executable lines of code?
• Data definitions?
• Comments?
• Changed/deleted lines?
• Not everything written is delivered to the client

10
Function points (FP)

• Based on a combination of program characteristics
• external inputs and outputs
• user interactions
• external interfaces
• files used by the system
• A weight is associated with each of these
• The function point count is computed by
  multiplying each raw count by the weight and
  summing all values

11
Function points (contd.)

• For example
• FP 4 Inp 5 Out 4 Inq 10 Maf 7
  Inf
• Inp - number of inputs
• Out number of outputs
• Inq - inquiries
• Maf - master files
• Inf - interfaces
• FPsmay be subjective

12
Object points

• Object points are an alternative function-related
  measure to function points when 4Gls or similar
  languages are used for development
• Object points are NOT the same as object classes
• The number of object points in a program is a
  weighted estimate of
• The number of separate screens that are displayed
• The number of reports that are produced by the
  system
• The number of 3GL modules that must be developed
  to supplement the 4GL code

13
Object point estimation

• Object points are easier to estimate from a
  specification than function points as they are
  simply concerned with screens, reports and 3GL
  modules
• They can therefore be estimated at an early point
  in the development process. At this stage, it is
  very difficult to estimate the number of lines of
  code in a system
• Object points are used in the COCOMO II
  estimation model

14
Productivity estimates

• Real-time embedded systems, 40-160 LOC/month
• Systems programs, 150-400 LOC/month
• Commercial applications, 200-800 LOC/month
• In object points, productivity has been measured
  between 4 and 50 object points/month depending on
  tool support and developer capability

15
Quality and productivity

• All metrics based on volume/unit time are flawed
  because they do not take quality into account
• Productivity may generally be increased at the
  cost of quality
• It is not clear how productivity/quality metrics
  are related

16
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

17
Estimation techniques

• Expert judgment
• Estimation by analogy
• Pricing to win
• Algorithmic cost modeling

18
Expert judgment

• One or more experts in both software development
  and the application domain use their experience
  to predict software costs
• Process iterates until some consensus is reached
• Advantages
• Relatively cheap estimation method
• Can be accurate if experts have direct experience
  of similar systems
• Disadvantages
• Very inaccurate if there are no experts!

19
Estimation by analogy

• The cost of a project is computed by comparing
  the project to a similar project in the same
  application domain
• Advantages
• Accurate if project data available
• Disadvantages
• Impossible if no comparable project has been
  tackled
• Needs systematically maintained cost database

20
Pricing to win

• The project costs whatever the customer has to
  spend on it
• This approach may seem unethical and
  un-businesslike. However, when detailed
  information is lacking it may be the only
  appropriate strategy
• Advantages
• You get the contract
• Disadvantages
• The probability that the customer gets the system
  he or she wants is small
• Costs do not accurately reflect the work required

21
Top-down and bottom-up estimation

• Any of these approaches may be used top-down or
  bottom-up
• Top-down
• Usable without knowledge of the system
  architecture and the components that might be
  part of the system
• Takes into account costs such as integration,
  configuration management and documentation
• Can underestimate the cost of solving difficult
  low-level technical problems
• Bottom-up
• Usable when the architecture of the system is
  known and components identified
• Accurate method if the system has been designed
  in detail
• May underestimate costs of system level
  activities such as integration and documentation

22
Algorithmic cost modeling

• Cost is estimated as a mathematical function of
  product, project and process attributes whose
  values are estimated by project managers
• Effort A SizeB M
• A is an organization-dependent constant
• B reflects the disproportionate effort for large
  projects
• M is a multiplier reflecting product, process and
  people attributes
• Most commonly used product attribute for cost
  estimation is code size
• Most models are basically similar but with
  different values for A, B and M

23
Estimation accuracy

• The size of a software system can only be known
  accurately when it is finished
• Several factors influence the final size
• Use of COTS and reused components
• Programming language
• Distribution of system
• As the development process progresses the size
  estimate becomes more accurate

24
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

25
The COCOMO model

• Constructive COst MOdel-an empirical model based
  on project experience
• http//sunset.usc.edu/csse/research/COCOMOII/cocom
  o_main.html
• 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 II
• COCOMO II takes into account modern SE
  technologies, various life cycle models, rapid
  prototyping, reuse, and COTS software

26
COCOMO 81
27
COCOMO II

• COCOMO II has three levels that allow
  increasingly detailed estimates to be prepared as
  development progresses
• Early prototyping level
• Estimates based on object points and a simple
  formula is used for effort estimation
• Early design level
• Estimates based on function points that are then
  translated to LOC
• Post-architecture level
• Estimates based on lines of source code

28
Early prototyping level

• Supports prototyping projects and projects where
  there is extensive reuse
• Based on standard estimates of developer
  productivity in object points/month
• Takes CASE tool use into account
• Formula is PM ( NOP(1 -reuse/100 ) ) / PROD
• PM is the effort in person-months
• NOP is the number of object points
• PROD is the productivity

29
Early prototyping level -Object point productivity
30
Early design level

• Estimates can be made after the requirements have
  been agreed
• Based on standard formula for algorithmic models
• PM A SizeB M PMm
• where
• A 2.5 in initial calibration
• Size in KLOC
• B varies from 1.1 to 1.24 depending on novelty of
  the project, development flexibility, risk
  management approaches and the process maturity
• M is multiplier
• PMm reflects the amount of automatically
  generated code

31
Early design level -Multipliers

• Multipliers reflect the capability of the
  developers, the non-functional requirements, the
  familiarity with the development platform, etc.
• M PERS RCPX RUSE PDIF PREX FCIL SCED
• where
• PERS - personnel capability
• RCPX - product reliability and complexity
• RUSE - the reuse required
• PDIF - platform difficulty
• PREX - personnel experience
• FCIL - the team support facilities
• SCED - required schedule

32
Post-architecture level -Size

• Uses same formula as early design estimates
• Estimate of size is adjusted to take into account
• Requirements volatility -rework required to
  support change
• Extent of possible reuse -reuse is non-linear and
  has associated costs so this is not a simple
  reduction in LOC
• ESLOC ASLOC (AA SU 0.4DM 0.3CM 0.3IM) /
  100
• ESLOC is equivalent number of lines of new code
• ASLOC is the number of lines of reusable code
  which must be modified
• AA is a factor which reflects the initial
  assessment costs of deciding if software may be
  reused
• SU is a factor based on the cost of software
  understanding
• DM is the percentage of design modified
• CM is the percentage of the code that is modified
• IM is the percentage of the original integration
  effort required for integrating the reused
  software

33
Post-architecture level -Exponent term

• Sum of 5 scale factors /100 1.01

34
Post-architecture level -Exponent term

• Example
• Precedenteness new project Low 4
• Development flexibility no client involvement
  Very high 1
• Architecture/risk resolution no risk analysis
  Very low 5
• Team cohesion new team Nominal 3
• Process maturity some control nominal 3
• Scale factor is therefore 1.17

35
Project cost drivers
36
Effects of cost drivers
37
Project duration

• Calendar time can be estimated using a COCOMO II
  formula
• TDEV 3 (PM)(0.330.2(B-1.01))
• PM is the effort computation
• B is the exponent computed as discussed above (B
  is 1 for the early prototyping model
• The time required is function of the total
  effort it is independent of the number of people
  working on the project
• Adding more people to a project that is behind
  schedule is unlikely to help

38
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

39
Why are projects late?

• An unrealistic deadline established by someone
  outside the software development group
• Changing customer requirements that are not
  reflected in schedule changes
• An honest underestimate of the amount of effort
  and/or the number of resources that will be
  required to do the job
• Predictable and/or unpredictable risks that were
  not considered when the project commenced
• Technical difficulties that could not have been
  foreseen in advance
• Human difficulties that could not have been
  foreseen in advance
• Miscommunication among project staff that results
  in delays
• A failure by project management to recognize that
  the project is falling behind schedule and a lack
  of action to correct the problem

40
Software project scheduling

• Compartmentalization
• define a number of manageable distinct tasks
• Interdependency
• Determine interdependency of each task
• Some tasks must occur in sequence, other can
  occur in parallel
• Time allocation
• Each task must be allocated a number of work
  units, a start date a completion date
• Define responsibilities
• Team members should be assigned to every
  scheduled task
• Defined outcomes
• Every task should have a defined outcome (work
  product)
• Defined milestones
• Every task or group of tasks should be associated
  with a project milestone work products are
  reviewed for quality and approved

41
Relationship between staff effort

• Man month as a unit for measuring the size of a
  job is dangerous and deceptive myth
• Man months are interchangeable only when a task
  can be partitioned among many workers with no
  communication among them some tasks can not be
  partitioned because of sequential constraints
• The number of people working on a project varies
  depending on the phase of the project
• Adding people late in a project often causes
  schedules to slip even further

42
Effort allocation 40-20-40 rule

• Front end activities
• customer communication
• analysis
• design
• review and modification

40- 50

• Construction activities
• coding or code generation

15- 20

• Testing and installation
• unit, integration
• black-box, white-box
• regression

30- 40
43
Defining a task network

• Task network (activity network) is a graphic
  representation of the task flow for a project

44
Scheduling

• Scheduling of software project does not differ
  greatly from scheduling of any multitask
  engineering effort
• Driven by
• Estimates of effort
• A decomposition of the product function
• The selection of the appropriate process model
  task set
• Decomposition of tasks

45
Scheduling

• Tools allow software planner to
• Determine the critical path (e.g. the chain of
  tasks) that determines the duration of the
  project
• Establish most likely time estimates for
  individual tasks by applying statistical models
• Calculate boundary times that define a time
  window for a particular task
• The earliest time that a task can begin when all
  preceding tasks are completed in the shortest
  possible time
• The latest time for task initiation before the
  minimum project time completion time is delayed
• The earliest finish time
• The latest finish time
• The total float the amount of surplus time
  allowed in scheduling tasks so that the critical
  path is maintained on schedule

46
Timeline charts
47
Tracking the schedule

• Conduct periodic project status meetings in which
  each team member reports progress and problems
• Determine whether formal project milestones have
  been accomplished
• Compare actual start date to planned start date
  for each project task
• Meet informally with practitioners to obtain
  their subjective assessment of progress to date
  and problems on the horizon
• Assess progress quantitatively (e.g., earned
  value analysis)

48
Overview

• Fundamentals of project planning and estimating
• Metrics for software productivity assessment
• Different techniques that can be used for
  estimation
• Algorithmic cost estimation method -COCOMO
• Project scheduling and tracking
• Framework for Software Project Management Plan
  (SPMP)

49
Framework for SPMP -IEEE Standard 1058.1

• 1. Introduction
• 1.1. Project overview
• 1.2. Project deliverables
• 1.3. Evolution of the SPMP
• 1.4. Reference materials
• 1.5. Definitions and acronyms
• 2. Project organization
• 2.1. Process model
• 2.2. Organizational structure
• 2.3. Organizational boundaries
• and Interfaces
• 2.4. Project responsibilities
• 3. Managerial process
• 3.1.Management objectives and priorities
• 3.2. Assumptions, dependencies,
• and constraints
• 3.3. Risk management

• 3.4. Monitoring and controlling mechanisms
• 3.5. Staffing plan
• 4. Technical process
• 4.1. Methods, tools, and techniques
• 4.2. Software documentation
• 4.3. Project support function
• 5. Work packages, schedule, and budget
• 5.1. Work packages
• 5.2. Dependencies
• 5.3. Resources requirements
• 5.4. Budget and resource allocation
• 5.5. Schedule
• Additional components

50
CASE tools for the planning

• Word processor, spreadsheet
• Automated intermediate COCOMO/COCOMO II
• Management tools assist with planning and
  monitoring
• Mac Project
• Microsoft Project