1 chapter 3 project management. 2 the 4 p’s people — the most important element of a successful...
Post on 22-Dec-2015
216 views
TRANSCRIPT
1
Chapter 3Chapter 3Project Project
ManagementManagement
2
The 4 The 4 P’sP’s
PeoplePeople — the most important element — the most important element of a successful projectof a successful project
ProductProduct — the software to be built — the software to be built ProcessProcess — the set of framework — the set of framework
activities and software engineering activities and software engineering tasks to get the job donetasks to get the job done
ProjectProject — all work required to make — all work required to make the product a realitythe product a reality
3
Software Software ProjectsProjects
• size
• delivery deadline
• budgets and costs
• application domain
• technology to be implemented
• system constraints
• user requirements
• available resources
Factors that influence the end result ...
4
Project Management Project Management ConcernsConcerns
staffing?
cost estimation?
project scheduling?
project monitoring?
other resources?
customer communication?
risk assessment?
product quality?
measurement?
5
Why Projects Why Projects Fail?Fail?
• • an unrealistic deadline is established an unrealistic deadline is established
• • changing customer requirements changing customer requirements
• • an honest underestimate of effortan honest underestimate of effort
• • predictable and/or unpredictable riskspredictable and/or unpredictable risks
• • technical difficultiestechnical difficulties
• • miscommunication among project staffmiscommunication among project staff
• • failure in project managementfailure in project management
6
Software Software TeamsTeams
the difficulty of the problem to be solvedthe difficulty of the problem to be solved the size of the resultant program(s) in lines of code or the size of the resultant program(s) in lines of code or
function pointsfunction points the time that the team will stay together (team lifetime)the time that the team will stay together (team lifetime) the degree to which the problem can be modularizedthe degree to which the problem can be modularized the required quality and reliability of the system to be the required quality and reliability of the system to be
builtbuilt the rigidity of the delivery datethe rigidity of the delivery date the degree of sociability (communication) required for the degree of sociability (communication) required for
the projectthe project
The following factors must be considered when selecting asoftware project team structure ...
7
Democratic decentralized (DD)Democratic decentralized (DD) Better for difficult problemsBetter for difficult problems High moraleHigh morale Low modularity?Low modularity?
Controlled decentralized (CD).Controlled decentralized (CD). High modularityHigh modularity
Controlled centralized (CC).Controlled centralized (CC). High modularityHigh modularity Faster for routine workFaster for routine work
Organizational Organizational ParadigmsParadigms
8
Chief Programmer Chief Programmer TeamTeam
IBM – New York Times projectIBM – New York Times project Chief Programmer – backupChief Programmer – backup ““Librarian”Librarian” 2-5 programmers2-5 programmers
9
Defining the Defining the ProblemProblem
establish scope—a narrative that establish scope—a narrative that bounds the problembounds the problem
decomposition—establishes decomposition—establishes functional partitioningfunctional partitioning
10
Melding Problem and Melding Problem and ProcessProcess
.
Software Engineering Tasks
plan
ning
risk
anal
ysis
engi
neer
ing
Product Functions
Text input
Editing and formating
Automatic copy edit
Page layout capability
Automatic indexing and TOC
File management
Document production
cust
omer
com
mun
icat
ion
COMMON PROCESSFRAMEWORK ACTIVITIES
11
To Get to the Essence of a To Get to the Essence of a ProjectProject
Why is the system being developed?Why is the system being developed? What will be done? By when?What will be done? By when? Who is responsible for a function?Who is responsible for a function? Where are they organizationally Where are they organizationally
located?located? How will the job be done technically How will the job be done technically
and managerially?and managerially? How much of each resource (e.g., How much of each resource (e.g.,
people, software, tools, database) will people, software, tools, database) will be needed?be needed? Barry Boehm
12
PERPERTT
Tasks – activities with well defined Tasks – activities with well defined beginning and endbeginning and end
Use a graph to show dependenciesUse a graph to show dependenciesCircles milestonesCircles milestonesArrows activitiesArrows activities
Determine critical path and slack timeDetermine critical path and slack time ExpediterExpediter Statistical estimates and simulations Statistical estimates and simulations
can be used for more realismcan be used for more realism
13
BesBest t
prapracticcticeses
DODDOD Airlie software Council (Virginia)Airlie software Council (Virginia) 1994 initiative1994 initiative
14
NinNine e
BesBest t
prapracticcticeses
Formal risk managementFormal risk management User manual as specificationUser manual as specification Inspections and peer reviewsInspections and peer reviews Metric-based scheduling and trackingMetric-based scheduling and tracking Binary gates at the inch-pebble levelBinary gates at the inch-pebble level Program-wide visibility of project plan Program-wide visibility of project plan
and progress versus planand progress versus plan
15
NinNine e
besbest t
prapracticcticeses
Defect tracking against quality Defect tracking against quality targetstargets
Separate specification of hardware Separate specification of hardware and sotware functionalityand sotware functionality
People-aware management People-aware management accountabililtyaccountabililty
16
WoWorst rst prapracticcticeses
Don’t use schedule compression to Don’t use schedule compression to justify usage of new technology on justify usage of new technology on any time critical projectany time critical project
Don’t specify implementation Don’t specify implementation technology in the RFPtechnology in the RFP
Don’t advocate use of unproven silver Don’t advocate use of unproven silver bullet approachesbullet approaches
17
WoWorst rst PraPracticcticeses
Don’t expect to recover form any Don’t expect to recover form any substantial schedule slip (10% or substantial schedule slip (10% or more) without making more than more) without making more than corresponding reductions in corresponding reductions in functionality to be deliveredfunctionality to be delivered
Don’t put items out of project control Don’t put items out of project control on the critical pathon the critical path
Don’t expect to achieve large, positive Don’t expect to achieve large, positive improvements (10% or more over past improvements (10% or more over past observed performanceobserved performance
18
Worst practicesWorst practices
Don’t bury all project complexity in the Don’t bury all project complexity in the software (as opposed to the hardware)software (as opposed to the hardware)
Don’t conduct the critical system Don’t conduct the critical system engineering tasks without software engineering tasks without software expertiseexpertise
Don’t believe that formal reviews provide Don’t believe that formal reviews provide an accurate picture of the project. an accurate picture of the project. Usefulness inversely proportional to Usefulness inversely proportional to number beyond fivenumber beyond five
19
MicMicrosrosoft oft Level 5 can’t compete against Level 5 can’t compete against
Microsoft?Microsoft? 17 million copies of Word?17 million copies of Word? Legal problemsLegal problems Bozo explosion? Bozo explosion? 2000 unsolicited resumes/week2000 unsolicited resumes/week
20
MS MS pepeoplopleweware are polpolicieiciess
Hire smart peopleHire smart people On project team right away (IBM - 6 On project team right away (IBM - 6
months training)months training) Weekly education sessionsWeekly education sessions MentorMentor Kick backKick back
21
MS MS mamananagergerss
Induce uncertainty, don’t swallow itInduce uncertainty, don’t swallow it The manager is the greatest expert on The manager is the greatest expert on
when you will finish - rely on QA for when you will finish - rely on QA for opinionopinion
Prevent someone from going darkPrevent someone from going dark Don’t micromanageDon’t micromanage
rely on interdependence among team membersrely on interdependence among team members
Small milestonesSmall milestones Don’t trade one bad date for anotherDon’t trade one bad date for another
22
MS MS devdeveloelopmpment ent prapracticcticeses
Case tools, formal analysis and design Case tools, formal analysis and design - not- not
Formal specification - notFormal specification - not Daily buildDaily build TestingTesting
Development not allowed to being until testing Development not allowed to being until testing signs off on specificationssigns off on specifications
1-1 ratio of testers to developers1-1 ratio of testers to developers Quick and dirty tests before buildQuick and dirty tests before build