Software Project Management - PowerPoint PPT Presentation

Loading...

PPT – Software Project Management PowerPoint presentation | free to download - id: 2159db-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Software Project Management

Description:

MSIT 630. 1-1. Lecture 2. Software Project Management. MSIT 630. 1-2 ... NASA Web Integrated Software Environment http://research.ivv.nasa.gov/projects/WISE ... – PowerPoint PPT presentation

Number of Views:44
Avg rating:3.0/5.0
Slides: 65
Provided by: garthma
Learn more at: http://polaris.umuc.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Project Management


1
Lecture 2
  • Software Project Management

2
Topics
  • Project Organization
  • Process and Project Metrics
  • Planning and Estimation
  • Risk Management

3
Additional References
  • Abdel-Hamid, Tarek Madnick, Stuart (1991)
    Software Project Dynamics. Prentice Hall.
  • Jones, Capers (1991). Applied Software
    Measurement. McGraw Hill.
  • DeMarco, Tom (1982). Controlling Software
    Projects. Yourdon Press.
  • Donaldson, S. Siegel, S. (1997). Cultivating
    Successful Software Development. Prentice Hall.
  • Humphrey, Watts (1995). A Discipline for Software
    Engineering. Addison Wesley.

4
Additional References
  • Fairley, Richard Rook, Paul, Risk Management
    for Software Development, in Software
    Engineering, Dorfman, M Thayer, R. (eds)
    (1997). IEEE Computer Society Presss.
  • Shumskas, Anthony, Software Risk Mitigation, in
    Total Quality Management for Software.
    Schulmeyer, G. McManus, J. (eds) (1996).
    International Thomson Computer Press.
  • Sommerville, Ian (2001). Software Engineering
    (6th ed.). Addison-Wesley.

5
Additional References
  • Sample text for a Software Development Plan
    http//www.airtime.co.uk/users/wysywig/sdp_1.htm
  • Boehm, B. (1995), Anchoring the Software Process.
    http//sunset.usc.edu/TechRpts/Papers/usccse95-507
    /ASP.html
  • University of Southern California - Center for
    Software Engineering
    http//sunset.usc.edu
  • Software Program Managers Network
    http//www.spmn.com
  • NASA Web Integrated Software Environment
    http//research.ivv.nasa.gov/projects/WISE/

6
Additional References
  • Practical Software Measurement (PSM), Version
    3.1, April 17, 1998. Office of the Undersecretary
    of Defense for Acquisition and Technology

7
Topics
  • Project Organization
  • Process and Project Metrics
  • Planning and Estimation
  • Risk Management

8
Net U.S. Productivity for New Projects
Jones (1991), p. 165
J
9
Process Factors
Jones (1991), p. 169
10
Workforce Level at IBMs DP Services Organization
Abdel-Hamid, p. 162
11
Resource Consumption
Schach, pp. 278, 279
12
Ideal vs. Actual Staff Loading Strategies
DeMarco (1982), p. 176
13
Alternate Staffing Strategies
DeMarco (1982), p. 181
14
Chief Programmer Team
Sommerville, p. 502
15
Modern Programming Team Structure
Schach, p. 98
16
Organizational Structure for Larger Projects
Schach, p. 99
17
Decentralized Decision Making
Schach, p. 100
18
People Differences (1)
  • Ability to perform the work
  • Interest in the work
  • Experience with similar applications
  • Experience with similar tools or languages
  • Experience with similar techniques
  • Experience with similar development environment

Pfleeger, p. 90
19
People Differences (2)
  • Training
  • Ability to communicate with others
  • Ability to share responsibility with others
  • Management skills

Pfleeger, p. 90
20
Work Styles
Pfleeger, p. 93
21
Topics
  • Project Organization
  • Process and Project Metrics
  • Planning and Estimation
  • Risk Management

22
What Are Metrics?
Metric - quantitative measurement (used for
tracking purposes)
Process Metrics - feedback to improve the
process, productivity
Project Metrics - used to track project progress
Product Metrics - track quality of product
23
Common Issues - Measurement Categories
  • Schedule and Progress
  • Milestone Performance
  • Work Unit Progress
  • Incremental Capability
  • Growth and Stability
  • Product Size and Stability
  • Functional Size and Stability
  • Technical Adequacy
  • Technology Impacts
  • Target Computer Resource Utilization
  • Technical Performance
  • Resources and Cost
  • Personnel
  • Financial Performance
  • Environment Availability
  • Development Performance
  • Process Maturity
  • Productivity
  • Product Quality
  • Defects
  • Complexity
  • Rework

24
Metrics Phase Coverage


25
Measurement Application Process
26
Core Program Metrics - As Recommended by the SEI
Issues Have we Planned for sufficient
resources? Are we progressing as planned? On
budget? On schedule? How good is the product?
Metrics Size Effort Cost
and Schedule Quality
Measure (Actual vs. Planned) Function points,
SLOC, CSCIs, SUs, etc. Labor Costs, Labor
Hours, etc. Actual vs. planned cost to
date, Gantt Charts, Milestones, Reviews,
Deliverables, etc. Defects, Changes, Fixes,
etc.
How large is the job? Does my process
provide valid estimates?
Source Carleton, et al., Software Management for
DoD Systems Recommendations for Initial
Implementation, SEI Technical Report, Sept 1992
27
Cost and Schedule Metrics (Earned Value Example)
Projected actual end cost
CONTRACT BUDGET BASE
NOW


Actual cost of work performed
Planned cost of work scheduled
COST VARIANCE

SCHEDULE VARIANCE
Planned cost of work performed
15
16
17
19
20
21
22
23
24
25
26
27
28
29
30 ..... end of project
18
TRR
CDR
CONTRACT MONTH
28

Guidance on Metrics (1)
  • Set clearly defined goals (Goal-Question-Metric
    (GQM) paradigm)
  • Focus on project issues (risk management)
  • Begin by only collecting a few key measurements
  • Develop a Project Measurement Plan
  • Must have management commitment and buy-in from
    project personnel
  • training, briefs
  • allocate adequate resources metrics analyst
  • set up a metrics working group

29

Guidance on Metrics (2)
  • Provide timely feedback to project personnel on
    metrics analysis
  • Automate measurement collection as much as
    possible
  • minimize impact on project personnel
  • Measurement results should remain anonymous
  • do not measure individuals
  • all projects are different, do not compare
  • focus on the process and the product

30
Guidance on Metrics (3)
  • Understand that metrics are not an end to
    themselves
  • metrics cannot identify, explain, or predict
    everything
  • most issues/problems require more than one
    measurement to characterize and understand
  • metrics should augment, not replace, good
    management and engineering judgment
  • Encourage feedback from measurement program
    participants
  • Plan for changes to measurement program and the
    types of measurements collected

31
Topics
  • Project Organization
  • Process and Project Metrics
  • Planning and Estimation
  • Risk Management

32
Planning in the Spiral Model
Schach, p. 81
33
Software Development Subsystems
Abdel-Hamid, p. 22
34
Project Planning - Lessons Learned (1)
  • Planning requires a software systems development
    life cycle to provide a framework for considering
    the specific tasks to be performed.
  • Planning needs to account for the interaction
    among management, development, and product
    assurance disciplines throughout the project life
    cycle.
  • Planning is an ongoing negotiation between the
    customer and seller.

Donaldson Sigel, pp. 32-34
35
Project Planning - Lessons Learned (2)
  • Planning maps out the envisioned technical
    approach, resources, schedule, and milestones for
    the transition from the current state to a
    desired state.
  • Planning should incorporate the need for change.
  • Planning needs to assess risk to determine the
    appropriate mix of management, development, and
    product assurance resources.

Donaldson Sigel, pp. 32-34
36
Project Planning - Lessons Learned (3)
  • Planning is required for any software systems
    development, and it is captured in a project plan
    ranging from a one-page memo to a sizable
    document.

Donaldson Sigel, pp. 32-34
37
Project Planning Framework
Customer Need
Define the requirements
Items
Tasks
Produce the conceptual design
Historical size database
Estimate the product size
Customer
Historical productivity database
Estimate the resources
Resources available
Produce the schedule
Management
Size, resource, schedule data
Delivered Product
Develop the product
Analyze the process
Tracking reports
Humphrey, p. 146
38
Other Planning Considerations
  • Training
  • Facilities
  • Tools and other support hardware and software
  • Documentation and other deliverables
  • Special testing requirements

39
Size Estimation - Lines of Code - Definitions
  • SLOC - Source (Single) Line of Code
  • KLOC - Thousand Lines of Code
  • PLOC - Physical Line of Code
  • LLOC - Logical Line of Code
  • CLOC - Commented Line of Code
  • NCLOC - Non-Commented Line of Code
  • DSI - Delivered Source Instruction

40
Software Size Attributes
  • Length
  • Functionality
  • Complexity
  • Reuse

41
Size Estimation - Wideband-Delphi
  • Group of experts is given programs specification
    and estimation form.
  • Group meets to discuss project goals,
    assumptions, and estimation issues.
  • Individuals each anonymously list project tasks
    and a size estimate.
  • A moderator tabulates results.
  • Experts meet to discuss results by reviewing
    tasks that have been defined but not the
    estimates.
  • Cycle continues until estimates converge.

42
FFP (File-Flow-Process) Metric (van der Poel
Schach)
S Size C Cost Fi Files Fl Flows Pr
Processes b Measure of efficiency
Schach, p. 267
43
Function Point Calculation
Unadjusted UFP a1(Inp) a2(Out) a3(Inq)
a4(Maf) a5(Inf) Adjusted TCF 0.65 0.01 x
DI FP UFP x TCF
FP Function Points TCF Technical Complexity
Factor UFP Unadjusted Function Points DI
Degree of Influence
44
Table of Function Point Values (ai)
45
Technical Factors for Function Point Computation
(DI)
Step 1 - Assign value between 0 and 5 to each of
the 14 factors where 0 implies not present or no
influence and 5 implies strong influence
throughout.
Step 2 DI is the sum of the 14 values.
Schach, p. 268
46
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

47
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

48
Cost Estimation Techniques
  • Expert Judgment by Analogy
  • Bottom-Up Approach
  • Algorithmic Cost Estimation

Schach, pp. 270 - 272
49
Structuring of Software Cost Estimation (SCE)
Models
Heemstra, in Dorfmann Thayer, p. 378
50
General Cost Estimation Structure
Heemstra, in Dorfmann Thayer, p. 379
51
Some Algorithmic Cost Models
  • Putnam SLIM Model
  • TRW Wolverton Model
  • RCA Price S Model
  • COCOMO Model

52
COCOMO 81 (Constructive Cost Model)
  • Macro Estimation Model
  • Intermediate Model
  • Micro Estimation Model

53
COCOMO II
  • Application Composition Model (Early Prototyping
    Level)
  • based on Object Points
  • Early Design Model (Level)
  • based on Function Points
  • Post-Architecture Model (Level)
  • based on Function Points or Lines of Code

54
Topics
  • Project Organization
  • Process and Project Metrics
  • Planning and Estimation
  • Risk Management

55
Risk Increases With System Complexity
CMU/SEI-96-TR-012
56
Software Risk Factors
  • Technical risk (performance related)
  • Supportability risk (performance related)
  • Programmatic risk (environment related)
  • Cost risk
  • Schedule risk

USAF, Guidelines for Successful Acquisition and
Management of Software-Intensive Systems, Vol. 1
- Ver. 2.0, June 1996
57
Risks Within a System Context
SYSTEM
CMU/SEI-96-TR-012
58
Risk Management Process
USAF, Guidelines for Successful Acquisition and
Management of Software-Intensive Systems, Vol. 1
- Ver. 2.0, June 1996. Fig 6-3
59
Taxonomy of Software Development Risks
CMU/SEI-93-TR-6
60
Risk Management Procedures
  • Risk Assessment
  • Risk identification
  • Risk analysis
  • Risk prioritization
  • Risk Control
  • Risk abatement strategies
  • Risk mitigation planning
  • Risk mitigation

Fairley Rook (Dorfman Thayer), pp. 392-396
61
Boehms Taxonomy for Risk Management
Fairley Rook (Dorfman Thayer), p. 389
62
Risk Magnitude Level Matrix
USAF, Guidelines for Successful Acquisition and
Management of Software-Intensive Systems, Vol. 1
- Ver. 2.0, June 1996. Fig 6-7
63
Precedented vs. Unprecedented Systems
Risk
  • This team has done something similar to this
    before.
  • Our organization has done this before, but not
    this team.
  • Its been done before, but not by our
    organization.
  • No one has done this before.

Low
Precedented
Unprecedented
High
Based on conversation with R. Sylvester, MITRE
Corp., 1988
64
Next Lecture
  • Structured Methods (Part 1)
About PowerShow.com