Software Project Management Lecture 9 Software Configuration Management.
Software Project Management
description
Transcript of Software Project Management
1
© 2001 Shawn A. Bohner
Software Project ManagementCS6704: Class 2
Software Project Software Project ManagementManagementCS6704: Class 2CS6704: Class 2
Instructor: Shawn A. BohnerVoice: (703) 538-8374
Email: [email protected]
Teaching Assistant: Yunxian ZhouEmail: [email protected]
Voice: (703) 538-8381
2
Agenda
u Review Last Week’s Materiall Turn in Homeworkl Reading Discussionl Project Plans Discussionl Review last weeks class
u Chapter 1: What Makes a Good Software Manager?
u Chapter 2: Four Basics that Workl Break
u Software Process Managementu Homework Assignment
2
3
AugAug SeptSept OctOct NovNov DECDEC
Class BeginsClass BeginsPM BasicsPM Basics
Software Software Project Project
PlanningPlanning
Managing with Managing with MetricsMetrics
ProgramProgramManagementManagement
Emerging PM Emerging PM ParadigmsParadigms
Final ExamFinal Exam
Software Software Process and Process and
Life CycleLife Cycle
Software Software EstimationEstimation
Risk Risk ManagementManagement
Human SideHuman Sideof PMof PM
Project Project Portfolio Portfolio
ManagementManagement
Fall Semester Timeline
16 weeks, 13 sessions… So much to do & so little time … manage your time effectively!
16 weeks, 13 sessions… So much to do & so little time … manage your time effectively!
MidMid--Term Term ExamExam
4
Discussions…
u Reading Discussionl What was the main idea of the paper?l Does software projects differ from other
projects? If so, how?l Do you do these things in your projects?l What parts of these can be automated?
u Software Project Plans Discussionl Where did you find software plan examples?l What did the software plans contain?l Was it what you expected? What was different or
missing? l What there enough information in the plans to
support the management decisions for projects you have seen?
3
5
So, why is e-Engineering a project management problem?
u Large, complex, distributed systemsl CPU speed, memory, bandwidthl Things we’re taught to ignore
u Heterogeneous platform architecturesl Mainframe, desktop, laptop, palmtop … l CORBA, VXML, EJB, … languages
u Mobility (Several 2000/1 IEEE Computer Issues)
l One application runs on many devices across varied communications
l Each device has varied resource profiles
u Modeling, analysis, simulation…l Collaborative design on partial information
u Development teams across the globel Around the clock developmentl Decentralized ownership and control
6
Why Are Projects Late?u Unrealistic deadline established by someone outside the software
development groupu Changing customer requirements that are not reflected in schedule
changesu Honest underestimate of the amount of
effort and/or the number of resources that will be required to do the job
u Predictable and/or unpredictable risks that were not considered when the project started
u Technical difficulties that could not have been foreseen in advance
u Human difficulties that could not have been foreseen in advance
u Miscommunication among project staff that results in delaysu Failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the problem
Which of these are unique to Software Projects?Which of these are unique to Software Projects?
4
7
So, what did Capers Jones tell us here?
Early On-Time Delayed Canceled Sum
1 FP 14.68% 83.16% 1.92% 0.25% 100.00%
10FP 11.08% 81.25% 5.67% 2.00% 100.00%
100FP 6.06% 74.77% 11.83% 7.33% 100.00%
1000FP 1.24% 60.76% 17.67% 20.33% 100.00%
10,000FP 0.14% 28.03% 23.83% 48.00% 100.00%
100,000FP 0.00% 13.67% 21.33% 65.00% 100.00%
Average 5.53% 56.94% 13.71% 23.82% 100.00%
From Capers Jones, Patterns of Software Systems Failure and Success(International Thomson Computer Press, 1996)
8
Semi-Formal Definition
u Management – The activities undertaken by ??? to plan and control activities of others to ???.
u Project Management – “… a ??? of procedures, practices, technologies, and know-how that provide the ?, ??, ???, ????, and ????? necessary to successfully manage an engineering project.” [Thayer 1987]
5
9
Classic Management Activities
SoftwareProject
SoftwareSoftwareProjectProject
Planning
Planning
PlanningDi
recti
ng
Dire
cting
Dire
cting
StaffingStaffingStaffing Organizing
OrganizingOrganizing
ControllingControllingControlling
?
?
?
?
?
10
Prog. Mngt. Capability Maturity Model
Result
Value
Risk
MaturityLevel
Key Process AreaConcentrations
StrategicInflection
Point
EffectiveSpan
5Incorporated
Value Management,Business Continuity Planning,Procurement Management,Outsourcing and Contract Manage-ment, PM Center of Excellence
Integrationwith Business
Enterprise/Industry
4Managed
Program Process Management,Project Integration Management,Project Performance Management,Vendor Management, PM Career Path,Staff Performance Management,Customer Relationship Management,Contingency Management,Communications Management
DynamicMicro-LevelChange
MultipleBusinessUnits
3Defined
PM Methodology, Skill Management,PM Training, Risk Management,Change Management,Staff Resource Management,Environment Resource Management,Conflict/Issue Management
Static Macro-Level Change
MultipleProject
2Stable
Planning, Estimation,Tracking, Risk Identification,Schedule Management,Budget/Cost Management,Scope Mgmt., Progress Reporting
StabilizePerformance
SingleProject
1 - Initial Acquiring New PMs
6
11
What do PMs Manage? Software!
u Software is part of a computer system that is ???
u Business changes and its computer systems must respond
u Software is ???, not manufactured
u Software is intangibleu Software is complex
Software is suppose to change… otherwise it would in the hardware!Software is suppose to change… Software is suppose to change… otherwise it would in the hardware!otherwise it would in the hardware!
12
Software Project Management must Manage to a Future (moving) Target
u ??? Changesl Market shifts and investment fluctuationsl Portfolio changesl Mergers and Acquisitions …
u ??? Changesl Hardware, software, networks, mobile …l Fast, better, cheaper …
u ??? Changesl Agility vs. qualityl Business and technology …
u ??? Changesl Shortages and gluts …
7
13
Project Management Truths
u You can get someone to commit to an unreasonable deadline, but you can’t l …bully him into meeting it
u Experienced PM’s Motto: Projects fail l …one day at a time
u Projects progress to 90% completion very rapidly…l They remain there while great sums of money and time are
spent to keep them there
u You can freeze specifications, l …but you can’t freeze expectations
u When quoting “off the shelf,” remember l …there is no shelf
u If project content is allowed to change freely, l the rate of change will soon exceed the rate of progress
14
Chapter 1: What makes a good Software Manager?
u The purpose of this chapter is to examine characteristics of a good software project managerl What are the key attributes associated with
successful project managers? l Which software projects management skills are
essential?u Objectives
l Outline key characteristics of a good software manager
l Examine people, business, and process perspectives
8
15
People Perspective
u Rob Thomasett – “most projects fail because of people and PM concern rather than technical issues.”
u ~80% of software project managers come from technical ranksl Some with natural abilities, others must learnl Often with predispositions about managers
and how projects should be runl Most are surprised by their first project
– Budgets, resources, customers, estimates, teams, meetings, decisions, and risks
u Beware of the little hairy boss syndrome…
16
Some Sage Advice…
u Be flexible. l Let your people perform according to their capabilities.
Stretch goals are good but they have to have enough room to stretch.
u Have compassion. l Deal compassionately with difficult people (often they do
not know they are difficult and may be difficult because the do not understand)
u Know when to lead and when to manage.l Lead people… manage process and product
(by example) (systematically)
u Accept the role of meetings.l Communication, not bureaucracyl Prepare and manage them
9
17
Coach Your Team to Success [Hawkins 1994]
u Yes, project management is a team sportu Success is spelled “T E A M”u Increase chances of success by
l Hiring the best and brightestl Keep the teams smalll Minimize distractionsl Train staff for best performancel Meet as a team often but not for long periodsl Know your team membersl Set the example
18
Software Teams
u Difficulty of the problem to be solvedu Size of the resultant program(s) in lines of code
or function pointsu Time that the team will stay togetheru Degree to which the problem can be modularizedu Required quality and reliability of the system to
be builtu Rigidity of the delivery dateu Degree of sociability (communication) required
for the project – Relationship management
Consider the following factors when selecting asoftware project team structure ...
10
19
Business Perspective
u Again, most software project managers did not come from the business…
u Chaos Studyu Creating software products to benefit the
business and its customersl Who wants the software and who doesn’t?l Who are the users? What will the software do
for them and the business?l When do users need (not want) the software?l Why does the business need the software?l Why is your team developing the software?
u Business investment portfolio view
20
Basis for IT Portfolio Investment
u Value maintenance —managing ongoing, non-discretionary investments in IT assets
u Value enhancement —discretionary investments in improving or growing IT asset base
u Value exploration —venture into high-risk/high-payoff IT investments •
• •
• • •
• •
•
• • •
• •
•
• •
•
IT PortfolioIT Portfolio
Projects/Initiatives
Projects/InitiativesERPERPEE--BizBiz
CRMCRMSecuritySecurityNetwork
Network UpgradeUpgradeConsolidation
Consolidation
ApplicationsApplications
DataData
ServicesServices
Infrastructure
Infrastructure
Human Capital
Human Capital
Existing
AssetsExisting
Assets
11
21
Maintain Existing IT Asset Value
u IT liability avoidance and value retention
u Fund baseline costs for critical business operations, maintenance, and support
u Skeleton funding based on minimum headcount and costs to keep system running
u Incentives to reduce baseline costs
Prevent Business Discontinuity
ValueValueMaintenanceMaintenance
IT Investment BudgetIT Investment Budget
22
Enhancing Existing IT Asset Value
u Strategic prioritiesl Investments criteria l Investment process
u Phased funding on projects with interim deliverablesl Jump-startl Initial capability l Advanced function
u Continued allocations through project value and delivery commitments being met and communicated
Invest in Existing Assets According to Business Strategy
ValueValueEnhancementEnhancement
ValueValueMaintenanceMaintenance
IT Investment BudgetIT Investment Budget
12
23
Exploring Future IT Asset Value
u Requires dynamic mindset for quick response to value and market changesl Digital Planning for agility
u Value Enhancement investment criteria plus:l Business/Market advantagel 2-3 year ROI/IRR projectionl Clear exit strategy
u Manage using a venture funding model – close and regular interactions
Engage in high risk, high yield opportunities
ValueValueEnhancementEnhancement
ValueValueMaintenanceMaintenance
ValueValueExplorationExploration
24
Investment Model IT Portfolio
Cost toConform
Cost toExcel
Lost ValueLeveraged Value
Followers Leaders
Minimum Investment
Excess Investment
ValueValueMaintenanceMaintenance
ValueValueExplorationExploration
ValueValueEnhancementEnhancement
13
25
Process Perspective
u Software process has matured into a vital part of software projectsl Software Engineering Institute’s Capability
Maturity Modelsl Best practicesl ISO 9000, Malcolm-Baldridge, TQM…
u At the heart of every project plan is an activity/task set derived largely from the process
26
Management Secrets
u Avoid having team members work in isolation
u Stay with your project team – they are the ones delivering the products of the project
u Concentrate on Tasks – not toolsu Do your homework (no this is not a
subliminal message for CS6704)l Stay current on latest advancements in
management and technical techniques for projects that you manage
u Sounds like common sense… but it is not so common!
14
27
Chapter 2: Four Basics that Work
u The purpose of this chapter is to examine four basic software project management principles that workl What are the basic areas for successful project
managers to manage?
u Objectivesl 1. Balance people, process, and productl 2. Promote visibilityl 3. Organize using configuration managementl 4. Apply standards judiciously
28
The 3 P’s
u Peoplel Critical to all projects but the most variable in
the management equationl Creative, complex, capable, costly
u Processl Most focused on in recent yearsl Manage the process through measures (next
section)l Universe, world, and atomic views
u Productl Software is to be change tolerantl Quality measuredl Ultimate delivery
15
29
Balancing the 3 P’s
u Difficult of the product dependent on people and process capabilitiesl Must triangulate on Pfactors…
u People Knowledgel Domainl Systeml Programming
u Process Maturityl Levels 1-5 on the SEI-CMM scale
u Product Maturityl From research prototype to packaged
component
30
Visibility
u Software is invisible to naked eye… l Intangible – must be measured with a computer
u Software projects are largely invisible (until they complete) – managed as a cost
u Project managers must bring visibility to software product and project
u Two “dreaded” visibility vehiclesl Documentationl Metrics
u Project team vision, commitment, and group memory
16
31
Visibility Through Modeling
u Models answer questionsu What questions need clarity (better
visibility) – model themu Modeling tools
l SADT/IDEF0, Warnier-Orr diagrams, STDs, Structure charts
l CRC cards, object interaction diagramsl Mind maps, story boards,
32
How are Metrics Used for Visibility?
02468
10Predevelop
Develop
Post-develop
Integral (CM, V&V)
Life Cycle
Project Mgmt
GoalQuestion
Metric
Decision?
tGetting attention —What situations need to be addressed?
Dashboard of indicators
tKeeping score —How well is it (or IT) doing?
Scorecard on goals
tSolving problems —Which choice or improvement should be made?
Benchmarking for performance improvement
17
33
Meaningful Management Visibility
Operational View• Process/activities• Products/specs• Policy/procedures• Constraints/guides . . . OLTG
TL A p p l i c a t i o n s ,
I n f o r m a t i o n Reques t s ,
Updates
Appl ica t ion Acceptance
I n f o r m a t i o n
Obtain Technical
Loan Applications
A13 3 . 0 D
Conduct Applicant
Credit CheckA25 3 . 0 D
Conduct Technical
ReviewA31 3 2 . 0 D
Accept/Reject Loan
GuaranteeA41 3 1 . 0 D
Appl ica t ion Correspondence
Comple ted Loan
Appl ica t ions
Cred i t
Approval
Technical Approval
S c i e n t i f i c / E n g i n e e r i n g Review Team,
DoD Review Team
Management ViewiCosts/budgetiSchedule/effort/delayiUtilization and loadingiResource availability . . .
del
Sdel
svcSsvc
0.136.7615500.412
Audit A
arcvTm
*
16.8751121
Workload
wkld
svtm
# d u C s t Dr
146 0.68 24.5Base Acty
a b mo
avgmax
m i nx0
SD
30.006726.135916.8753.11928
BaseThrupu
xx
3.51362
145.6003000
Delay>Svtm
a b mo
avg
max
m i nsSD
1680.46
980.271280.077392.198
SvcTmBase
Exp*
Base
delSdel
svcSsvc
334.0530980.271
Audit
Alt
a b mo
avg
max
m i ns
SD
974.839500.41225.9854
293.569SvcTmAlt
wkld
svtm
# d u C s t Dr
0.78 0.35 16.9Alt.Acty
x
0.350250.782503000
Delay>Svtm
Exp*A
a b mo
avg
max
m i n
x0
SD
49.5746
36.130116.87512.4660
AltThruput
1st Qtr 2nd Qtr 3rd Qtr 4th Qtr0
20
40
60
80
100
42
4344
45
46
47
48Production
DelayOverhead
Executive Decision ViewiROI, ROM, EVA, …iBusiness ImpactiPrice/performanceiRisk/opportunity . . . Value
34
Key Visibility Principles for Metricsu Clearly defined metrics,
consistently appliedu Metrics are only indicators, use
them accordinglyu Focus on leading indicators over
lagging onesu Recognize indicators of
problemsl Lack of changel Frequent changel Slow, steady deviation from plans
Navigation
Software metrics are navigational instruments giving position, direction, and rate of change
Software metrics are navigational instruments giving position, direction, and rate of change
18
35
Configuration Management
No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle.
Ed Bersoff, et al, 1980
u Product dependencies can be complexl Time, use, version, …
36
Flow of SCM: Definition, Use, Archive
Production Library
Acceptance Test Library
Integration Testing Library
System Testing Library
Unit Development Library
Emergency Fix Library
Production Library
Acceptance Test Library
Integration Testing Library
System Testing Library
Unit Development Library
Emergency Fix Library
Archives of SystemSoftware
SCM Staff
0 Defines SCM Structures, Standards and Procedures
Key Software BaselineVersions
Software Project Staff
0 Uses SCM Library Structures, Standards and Procedures
SCM Staff
0 Archives/ControlsBaselined Software
19
37
Standards
u The wonderful thing about standards is that there are so many to choose from…l But when leveraged correctly, they simplify the
process and management of a software project
u Standards save time and moneyu Examples:
l IEEE 1042 – SCM Standardl MIL-STD-498/IEEE 1498 – Software
Development Life Cycle
38
Software Process
u The purpose of this module is to introduce several software process models used to manage large-scale software projectsl While no software process works well for every
project, every project needs to conform to some systematic process
u Objectivesl Outline software as a processl Outline key aspects of software processl Examine how to assess software process
maturity
20
39
The Linear Model
analysis design code test
System/informationengineering
40
Iterative Models
listento
customerbuild/revisemock-up
customertest-drivesmock-up
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
team #1
team #2team #3
60 - 90 days
Prototyping
RAD
21
41
The Incremental Model
analysis design code test
System/informationengineering
analysis design code test
analysis design code test
analysis design code test
increment 2
increment 3
increment 4
increment 1
delivery of1st increment
delivery of2nd increment
delivery of3rd increment
delivery of4th increment
calendar time
42
An Evolutionary (Spiral) Model
CustomerCommunication
Planning
Construction & ReleaseCustomerEvaluation
Engineering
Risk Analysis
22
43
Still Other Process Modelsu Component assembly model—the process
to apply when reuse is a development objective
u Concurrent process model—recognizes that different part of the project will be at different places in the process
u Formal methods—the process to apply when a mathematical specification is to be developed
u Cleanroom software engineering—emphasizes error detection before testing
44
SEI Process Program Background
u CBA IPIs and SPAs conducted since 1987 through December 1999 and returned to the SEI by January 2000l 1512 assessments
– 1024 CBA IPIs– 488 SPAs
l 1166 organizationsl 309 participating companiesl 283 reassessed organizationsl 6168 projects
*Source: Software Engineering Institute
23
45
SEI’s Software Process Capability Maturity Model
Level Focus Key Process Areas Result
1Initial
Heroes
5Optimizing
ContinuousProcess
Improvement
Defect preventionTechnology innovationProcess change management
4Managed
Product andProcess Quality
Process measurement andanalysisQuality management
3Defined
EngineeringProcess
Organization process focusOrganization process definitionPeer reviewsTraining programIntergroup coordinationSoftware product engineeringIntegrated software management
Productivity& Quality
Risk
2Repeatable
ProjectManagement
Software project planningSoftware project trackingSoftware subcontract mgt.Software quality assuranceSoftware configuration mgt.Requirements management
*Source: Software Engineering Institute
46
Summary of the SEI/CMM Levels
1) Initial: The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort.
2) Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
3) Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standardsoftware process for developing and maintaining software.
4) Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
5) Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
24
47
Software Process Maturity Advances
0.87
79.8
12.40.58.7
75.3
15.49.7
0.50.7
16.9
72.2
1.40.5
12
64.4
21.7
0.62.3
15.1
58.1
23.9
1.53.815.6
30.6
48.6
0
10
20
30
40
50
60
70
80
90
Level 1 Level 2 Level 3 Level 4 Level 5
1987-91 1992 1994 1996 1998 1999
*Source: Software Engineering Institute
48
Summary Maturity Findings: Organizational Trends
u Software Quality Assurance is the least frequently satisfied level 2 KPAs among organizations assessed at level 1
u Integrated Software Management, Training Program and Organization Process Definition are the least frequently satisfied level 3 KPAs among organizations assessed at level 2
u Higher maturity has been reached among those organizations reporting reassessments
*Source: Software Engineering Institute
25
49
Process Improvement Maturity Levels
Process
Ad hocs High variability/Low
predictabilitys Heroes => Successs High Risk
Process
Repeatables Project metrics focuss Low variability/Medium
predictabilitys PM => Successs Medium-High Risk
Defineds Process metrics focuss High predictabilitys Process => Successs Medium Risk
50
More Traction at Upper levels...
Manageds Product and
Process metricss High predictabilitys Managed Process
=> Successs Low-Medium Risk
Optimized (Incorporated)
s Value metricss High predictabilitys Agility => Successs Low Risk
26
51
Homework Assignment for 9/10/01
u Read Paper entitled, “Anchoring the Software Process” by Barry Boehml Summarize key points of assigned reading into a short 1
page paper (~300-500 words)
u Read SPMH Text Chapters 1, 2, and 3l Homework Questions/Deliverables:1. What are the key characteristics of an effective project
manager? Please include references.2. Outline how to balance people, process, and product for
effective project management3. What visibility techniques work best for showing project
progress? Why?4. Search web for Configuration Management Plan
Template and send it to me via email.
u Have a great week!