Chapter 4.1 Software Project Planning

1
Chapter 4.1Software Project Planning
2
The Four Ps

• People the most important element of a
  successful project
• Product the software to be built
• Process the set of framework activities and
  software engineering tasks to get the job done
• Project all work required to make the product a
  reality

Project
Process
Product
People
3
The People The Stakeholders

• Five categories of stakeholders
• Senior managers who define the business issues
  that often have significant influence on the
  project.
• Project (technical) managers who must plan,
  motivate, organize, and control the practitioners
  who do software work.
• Practitioners who deliver the technical skills
  that are necessary to engineer a product or
  application.
• Customers who specify the requirements for the
  software to be engineered and other stakeholders
  who have a peripheral interest in the outcome.
• End-users who interact with the software once it
  is released for production use.

4
Software Teams
5
The People Team Leaders

• Qualities to look for in a team leader
• Motivation. The ability to encourage (by push
  or pull) technical people to produce to their
  best ability.
• Organization. The ability to mold existing
  processes (or invent new ones) that will enable
  the initial concept to be translated into a final
  product.
• Ideas or innovation. The ability to encourage
  people to create and feel creative even when they
  must work within bounds established for a
  particular software product or application.

6
The People The Software Team

• Seven project factors to consider when
  structuring a software development team
• the difficulty of the problem to be solved
• the size of the resultant program(s) in lines of
  code or function points
• the time that the team will stay together (team
  lifetime)
• the degree to which the problem can be
  modularized
• the required quality and reliability of the
  system to be built
• the rigidity of the delivery date
• the degree of sociability (communication)
  required for the project

7
The Product Scope

• Scope
• Context. How does the software to be built fit
  into a larger system, product, or business
  context and what constraints are imposed as a
  result of the context?
• Information objectives. What customer-visible
  data objects are produced as output from the
  software? What data objects are required for
  input?
• Function and performance. What function does the
  software perform to transform input data into
  output? Are any special performance
  characteristics to be addressed?
• Software project scope must be unambiguous and
  understandable at the management and technical
  levels.

8
Problem Decomposition

• Sometimes called partitioning or problem
  elaboration
• Once scope is defined
• It is decomposed into constituent functions
• It is decomposed into user-visible data objects
• or
• It is decomposed into a set of problem classes
• Decomposition process continues until all
  functions or problem classes have been defined

9
The Process

• Once a process framework has been established
• Consider project characteristics
• Determine the degree of rigor required
• Define a task set for each software engineering
  activity
• Task set
• Software engineering tasks
• Work products
• Quality assurance points
• Milestones

10
The Project

• Projects get into trouble when
• Software people dont understand their customers
  needs.
• The product scope is poorly defined.
• Changes are managed poorly.
• The chosen technology changes.
• Business needs change or are ill-defined.
• Deadlines are unrealistic.
• Users are resistant.
• Sponsorship is lost or was never properly
  obtained.
• The project team lacks people with appropriate
  skills.
• Managers and practitioners avoid best practices
  and lessons learned.

11
To Get to the Essence of a Project

• Why is the system being developed?
• What will be done?
• When will it be accomplished?
• Who is responsible?
• Where are they organizationally located?
• How will the job be done technically and
  managerially?
• How much of each resource (e.g., people,
  software, tools, database) will be needed?

12
Chapter 4.2 Process and Project Metrics
13
A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
size?
function?
14
Why Do We Measure?

• assess the status of an ongoing project
• track potential risks
• uncover problem areas before they go critical,
• adjust work flow or tasks,
• evaluate the project teams ability to control
  quality of software work products.

15
Process Metrics

• Quality-related
• focus on quality of work products and
  deliverables
• Productivity-related
• Production of work-products related to effort
  expended
• Statistical SQA data
• error categorization analysis
• Defect removal efficiency
• propagation of errors from process activity to
  activity
• Reuse data
• The number of components produced and their
  degree of reusability

16
Typical Project Metrics

• Effort/time per software engineering task
• Errors uncovered per review hour
• Scheduled vs. actual milestone dates
• Changes (number) and their characteristics
• Distribution of effort on software engineering
  tasks

17
Typical Size-Oriented Metrics

• errors per KLOC (thousand lines of code)
• defects per KLOC
• per LOC
• pages of documentation per KLOC
• errors per person-month
• errors per review hour
• LOC per person-month
• per page of documentation

18
Typical Function-Oriented Metrics

• errors per FP (thousand lines of code)
• defects per FP
• per FP
• pages of documentation per FP
• FP per person-month

19
Function-Oriented Metrics

• FP are computed by
• FP count-total 0.65 0.01 Sum(Fi)
• count-total is the sum of all FP entries
• The Fi (i 1 to 14) are "complexity adjustment
  values" based on responses to the following
  questions ART85
• 1. Does the system require reliable backup and
  recovery?
• 2. Are data communications required?
• 3. Are there distributed processing functions?
• 4. Is performance critical?
• ...
• Each of these questions is answered using a scale
  that ranges from 0 (not important or applicable)
  to 5 (absolutely essential).

20
Comparing LOC and FP
Representative values developed by QSM
21
Object-Oriented Metrics

• Number of scenario scripts (use-cases)
• Number of support classes (required to implement
  the system but are not immediately related to the
  problem domain)
• Average number of support classes per key class
  (analysis class)
• Number of subsystems (an aggregation of classes
  that support a function that is visible to the
  end-user of a system)

22
WebApp Project Metrics

• Number of static Web pages (the end-user has no
  control over the content displayed on the page)
• Number of dynamic Web pages (end-user actions
  result in customized content displayed on the
  page)
• Number of internal page links (internal page
  links are pointers that provide a hyperlink to
  some other Web page within the WebApp)
• Number of persistent data objects
• Number of external systems interfaced
• Number of static content objects
• Number of dynamic content objects
• Number of executable functions

23
Measuring Quality

• Correctness the degree to which a program
  operates according to specification
• Maintainabilitythe degree to which a program is
  amenable to change
• Integritythe degree to which a program is
  impervious to outside attack
• Usabilitythe degree to which a program is easy
  to use

24
Defect Removal Efficiency
DRE E /(E D)
where E is the number of errors found before
delivery of the software to the end-user D is
the number of defects found after delivery.
25
Chapter 4.3 Estimation for Software Projects
26
Software Project Planning
The overall goal of project planning is to
establish a pragmatic strategy for controlling,
tracking, and monitoring a complex technical
project. Why? So the end result gets done on
time, with quality!
27
Project Planning Task Set-I

• Establish project scope
• Determine feasibility
• Analyze risks
• Define required resources
• Determine required human resources
• Define reusable software resources
• Identify environmental resources

28
Project Planning Task Set-II

• Estimate cost and effort
• Decompose the problem
• Develop two or more estimates using size,
  function points, process tasks or use-cases
• Reconcile the estimates
• Develop a project schedule
• Establish a meaningful task set
• Define a task network
• Use scheduling tools to develop a timeline chart
• Define schedule tracking mechanisms

29
Estimation

• Estimation of resources, cost, and schedule for a
  software engineering effort requires
• experience
• access to good historical information (metrics)
• the courage to commit to quantitative predictions
  when qualitative information is all that exists
• Estimation carries inherent risk and this risk
  leads to uncertainty

30
Write it Down!
Project Scope Estimates Risks Schedule Control
strategy
Software Project Plan
31
What is Scope?

• Software scope describes
• the functions and features that are to be
  delivered to end-users
• the data that are input and output
• the content that is presented to users as a
  consequence of using the software
• the performance, constraints, interfaces, and
  reliability that bound the system.
• Scope is defined using one of two techniques
• A narrative description of software scope is
  developed after communication with all
  stakeholders.
• A set of use-cases is developed by end-users.

32
Resource Estimation

• Three major categories of software engineering
  resources
• People
• Development environment
• Reusable software components
• Often neglected during planning but become a
  paramount concern during the construction phase
  of the software process
• Each resource is specified with
• A description of the resource
• A statement of availability
• The time when the resource will be required
• The duration of time that the resource will be
  applied

Time window
33
Categories of Resources

• People
• Number required
• Skills required
• Geographical location

• Development Environment
• Software tools
• Computer hardware
• Network resources

The Project

• Reusable Software Components
• Off-the-shelf components
• Full-experience components
• Partial-experience components
• New components

34
Human Resources

• Planners need to select the number and the kind
  of people skills needed to complete the project
• They need to specify the organizational position
  and job specialty for each person
• Small projects of a few person-months may only
  need one individual
• Large projects spanning many person-months or
  years require the location of the person to be
  specified also
• The number of people required can be determined
  only after an estimate of the development effort

35
Development Environment Resources

• A software engineering environment (SEE)
  incorporates hardware, software, and network
  resources that provide platforms and tools to
  develop and test software work products
• Most software organizations have many projects
  that require access to the SEE provided by the
  organization
• Planners must identify the time window required
  for hardware and software and verify that these
  resources will be available

36
Reusable Software Resources

• Off-the-shelf components
• Components are from a third party or were
  developed for a previous project
• Ready to use fully validated and documented
  virtually no risk
• Full-experience components
• Components are similar to the software that needs
  to be built
• Software team has full experience in the
  application area of these components
• Modification of components will incur relatively
  low risk

37
Reusable Software Resources

• Partial-experience components
• Components are related somehow to the software
  that needs to be built but will require
  substantial modification
• Software team has only limited experience in the
  application area of these components
• Modifications that are required have a fair
  degree of risk
• New components
• Components must be built from scratch by the
  software team specifically for the needs of the
  current project
• Software team has no practical experience in the
  application area
• Software development of components has a high
  degree of risk

38
Estimation Techniques

• Past (similar) project experience
• Conventional estimation techniques
• task breakdown and effort estimates
• size (e.g., FP) estimates
• Empirical models
• Automated tools

39
Functional Decomposition
Statement of Scope
functional decomposition
Perform a Grammatical parse
40
Problem-Based Estimation

• Start with a bounded statement of scope
• Decompose the software into problem functions
  that can each be estimated individually
• Compute an LOC or FP value for each function
• Derive cost or effort estimates by applying the
  LOC or FP values to your baseline productivity
  metrics (e.g., LOC/person-month or
  FP/person-month)
• Combine function estimates to produce an overall
  estimate for the entire project

41
Problem-Based Estimation

• In general, the LOC/pm and FP/pm metrics should
  be computed by project domain
• Important factors are team size, application
  area, and complexity
• LOC and FP estimation differ in the level of
  detail required for decomposition with each value
• For LOC, decomposition of functions is essential
  and should go into considerable detail (the more
  detail, the more accurate the estimate)
• For FP, decomposition occurs for the five
  information domain characteristics and the 14
  adjustment factors
• External inputs, external outputs, external
  inquiries, internal logical files, external
  interface files

42
Problem-Based Estimation

• For both approaches, the planner uses lessons
  learned to estimate an optimistic, most likely,
  and pessimistic size value for each function or
  count (for each information domain value)
• Then the expected size value S is computed as
  follows S (Sopt 4Sm Spess)/6
• Historical LOC or FP data is then compared to S
  in order to cross-check it

43
Example LOC Approach
Average productivity for systems of this type
620 LOC/pm. Burdened labor rate 8000 per
month, the cost per line of code is approximately
13. Based on the LOC estimate and the
historical productivity data, the total estimated
project cost is 431,000 and the estimated effort
is 54 person-months.
44
Example FP Approach
The estimated number of FP is derived FPestimat
ed count-total 0.65 0.01 Sum(Fi)
(see next) FPestimated 375 organizational
average productivity 6.5 FP/pm. burdened
labor rate 8000 per month, the cost per FP is
approximately 1230. Based on the FP estimate
and the historical productivity data, the total
estimated project cost is 461,000 and the
estimated effort is 58 person-months.
45
Complexity Adjustment Factor

• Factor Value
• Backup and recovery 4
• Data communications 2
• Distributed processing 0
• Performance critical 4
• Existing operating environment 3
• On-line data entry 4
• Input transaction over multiple screens 5
• Master files updated on-line 3
• Information domain values complex 5
• Internal processing complex 5
• Code designed for reuse 4
• Conversion/installation in design 3
• Multiple installations 5
• Application designed for change 5

• Answer the factors using a scale that ranges from
  0 (not important or applicable) to 5 (absolutely
  essential)
• Sum(Fi)52

46
Example FP Approach
The estimated number of FP is derived FPestimat
ed count-total 0.65 0.01
Sum(Fi) FPestimated 375 organizational
average productivity 6.5 FP/pm. burdened
labor rate 8000 per month, the cost per FP is
approximately 1230. Based on the FP estimate
and the historical productivity data, the total
estimated project cost is 461,000 and the
estimated effort is 58 person-months.
47
Process-Based Estimation

• Identify the set of functions that the software
  needs to perform as obtained from the project
  scope
• Identify the series of framework activities that
  need to be performed for each function
• Estimate the effort (in person months) that will
  be required to accomplish each software process
  activity for each function

48
Process-Based Estimation

• Apply average labor rates (i.e., cost/unit
  effort) to the effort estimated for each process
  activity
• Compute the total cost and effort for each
  function and each framework activity (See table
  in Pressman, p. 655)
• Compare the resulting values to those obtained by
  way of the LOC and FP estimates
• If both sets of estimates agree, then your
  numbers are highly reliable
• Otherwise, conduct further investigation and
  analysis concerning the function and activity
  breakdown

This is the most commonly used of the two
estimation techniques (problem and process)
49
Process-Based Estimation
Obtained from process framework
framework activities
application functions
Effort required to accomplish each framework
activity for each application function
50
Process-Based Estimation Example
Based on an average burdened labor rate of 8,000
per month, the total estimated project cost is
368,000 and the estimated effort is 46
person-months.
51
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data
52
Estimation with Use-Cases
Using 620 LOC/pm as the average productivity for
systems of this type and a burdened labor rate of
8000 per month, the cost per line of code is
approximately 13. Based on the use-case estimate
and the historical productivity data, the total
estimated project cost is 552,000 and the
estimated effort is 68 person-months.
53
Empirical Estimation Models
General form
exponent
effort tuning coefficient size
usually derived
empirically
as person-months
derived
of effort required
usually LOC but
may also be
function point
either a constant or
a number derived based
on complexity of project
54
COCOMO-II

• COCOMO II is actually a hierarchy of estimation
  models that address the following areas
• Application composition model. Used during the
  early stages of software engineering, when
  prototyping of user interfaces, consideration of
  software and system interaction, assessment of
  performance, and evaluation of technology
  maturity are paramount.
• Early design stage model. Used once requirements
  have been stabilized and basic software
  architecture has been established.
• Post-architecture-stage model. Used during the
  construction of the software.

55
The Software Equation
A dynamic multivariable model E LOC x
B0.333/P3 x (1/t4) where E effort in
person-months or person-years t project
duration in months or years B special skills
factor P productivity parameter
56
Estimation for OO Projects-I

• Develop estimates using effort decomposition, FP
  analysis, and any other method that is applicable
  for conventional applications.
• Using object-oriented analysis modeling (Chapter
  8), develop use-cases and determine a count.
• From the analysis model, determine the number of
  key classes (called analysis classes in Chapter
  8).
• Categorize the type of interface for the
  application and develop a multiplier for support
  classes
• Interface type Multiplier
• No GUI 2.0
• Text-based user interface 2.25
• GUI 2.5
• Complex GUI 3.0

57
Estimation for OO Projects-II

• Multiply the number of key classes (step 3) by
  the multiplier to obtain an estimate for the
  number of support classes.
• Multiply the total number of classes (key
  support) by the average number of work-units per
  class. Lorenz and Kidd suggest 15 to 20
  person-days per class.
• Cross check the class-based estimate by
  multiplying the average number of work-units per
  use-case

58
The Make-Buy Decision
59
Computing Expected Cost
expected cost
(path probability) x (estimated path cost)
i
i
For example, the expected cost to build is

expected cost 0.30 (380K) 0.70
(450K)

build
429 K


similarly,


expected cost 382K
reuse

expected cost 267K
buy
expected cost 410K
contr
60
Chapter 4.4 Project Scheduling
61
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

62
Effort and Delivery Time
63
Scheduling Principles

• front end activities
• customer communication
• analysis
• design
• review and modification
• construction activities
• coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression

64
40-20-40 Distribution of Effort

• A recommended distribution of effort across the
  software process is 40 (analysis and design),
  20 (coding), and 40 (testing)?
• Work expended on project planning rarely accounts
  for more than 2 - 3 of the total effort
• Requirements analysis may comprise 10 - 25
• Effort spent on prototyping and project
  complexity may increase this
• Software design normally needs 20 25
• Coding should need only 15 - 20 based on the
  effort applied to software design
• Testing and subsequent debugging can account for
  30 - 40
• Safety or security-related software requires more
  time for testing

65
Basic Principles for Project Scheduling

• Compartmentalization
• The project must be compartmentalized into a
  number of manageable activities, actions, and
  tasks both the product and the process are
  decomposed
• Interdependency
• The interdependency of each compartmentalized
  activity, action, or task must be determined
• Some tasks must occur in sequence while others
  can occur in parallel
• Some actions or activities cannot commence until
  the work product produced by another is available

66
Basic Principles for Project Scheduling

• Time allocation
• Each task to be scheduled must be allocated some
  number of work units
• In addition, each task must be assigned a start
  date and a completion date that are a function of
  the interdependencies
• Start and stop dates are also established based
  on whether work will be conducted on a full-time
  or part-time basis
• Effort validation
• Every project has a defined number of people on
  the team
• As time allocation occurs, the project manager
  must ensure that no more than the allocated
  number of people have been scheduled at any given
  time

67
Basic Principles for Project Scheduling

• Defined responsibilities
• Every task that is scheduled should be assigned
  to a specific team member
• Defined outcomes
• Every task that is scheduled should have a
  defined outcome for software projects such as a
  work product or part of a work product
• Work products are often combined in deliverables
• Defined milestones
• Every task or group of tasks should be associated
  with a project milestone
• A milestone is accomplished when one or more work
  products has been reviewed for quality and has
  been approved

68
Relationship Between People and Effort

• Common management myth If we fall behind
  schedule, we can always add more programmers and
  catch up later in the project
• This practice actually has a disruptive effect
  and causes the schedule to slip even further
• The added people must learn the system
• The people who teach them are the same people who
  were earlier doing the work
• During teaching, no work is being accomplished
• Lines of communication (and the inherent delays)
  increase for each new person added

69
Factors that Influence a Projects Schedule

• Size of the project
• Number of potential users
• Mission criticality
• Application longevity
• Stability of requirements
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded and non-embedded characteristics
• Project staff
• Reengineering factors

70
Purpose of a Task Network

• Also called an activity network
• It is a graphic representation of the task flow
  for a project
• It depicts task length, sequence, concurrency,
  and dependency
• Points out inter-task dependencies to help the
  manager ensure continuous progress toward project
  completion
• The critical path
• A single path leading from start to finish in a
  task network
• It contains the sequence of tasks that must be
  completed on schedule if the project as a whole
  is to be completed on schedule
• It also determines the minimum duration of the
  project

71
Example Task Network
Task F 2
Task H 5
Task G 3
Task B 3
Task N 2
Task A 3
Task E 8
Task C 7
Task I 4
Task J 5
Task M 0
Task D 5
Task K 3
Task L 10
Where is the critical path and what tasks are on
it?
72
Example Task Network
Task F 2
Task H 5
Task G 3
Task B 3
Task N 2
Task A 3
Task E 8
Task C 7
Task I 4
Task J 5
Task M 0
Task D 5
Task K 3
Task L 10
Critical path A-B-C-E-K-L-M-N
73
Timeline Charts
74
Use Automated Tools toDerive a Timeline Chart
75
Example Timeline Charts
76
Proposed Tasks for a Long-Distance Move of 8,000
lbs of Household Goods
Pack household goods
Arrange for workers to unload truck
Make decision to move
Determine destination location
Determine date to move out or move in
Make lodging reservations
Drive truck from origin to destination
Reserve rental truck and supplies
Get money to pay for the move
Find lodging with space to park truck
Decide on type/size of rental truck
Unload truck
Lease or buy home at destination
Plan travel route and overnight stops
Return truck and supplies
Arrange for workers to load truck
Pick up rental truck
Load truck
Arrange for person to drive truck/car

• Where is the critical path and what tasks are on
  it?
• Given a firm start date, on what date will the
  project be completed?
• Given a firm stop date, when is the latest date
  that the project must start by?

77
Proposed Tasks for a Long-Distance Move of 8,000
lbs of Household Goods
2. Get money to pay for the move
3. Determine date to move out or move in
13. Find lodging with space to park truck
14. Make lodging reservations
12. Plan travel route and overnight stops
4. Determine destination location
5. Lease or buy home at destination
19. Unload truck
18. Drive truck from origin to destination
11. Milestone
6. Decide on type/size of rental truck
7. Arrange for workers to load truck
17. Load truck
15. Reserve rental truck and supplies
16. Pick up rental truck
20. Return truck and supplies
8. Arrange for person to drive truck/car
9. Arrange for workers to unload truck

• Where is the critical path and what tasks are on
  it?
• Given a firm start date, on what date will the
  project be completed?
• Given a firm stop date, when is the latest date
  that the project must start by?

10. Pack household goods
78
Timeline Chart for Long Distance Move