Galbraith, David Fairley --- "Just enough religion to make us hate: a ...
Chart 4-1 Copyright © 2004 by R. Fairley CSE516 Summer, 2004 CSE 516 Introduction to Software...
-
Upload
christiana-murphy -
Category
Documents
-
view
215 -
download
3
Transcript of Chart 4-1 Copyright © 2004 by R. Fairley CSE516 Summer, 2004 CSE 516 Introduction to Software...
chart 4-1Copyright © 2004
by R. FairleyCSE516Summer, 2004
CSE 516Introduction to Software Engineering
SESSION 4: SOFTWARE PROJECT MANAGEMENTdeveloped by
Richard E. Fairley, Ph.D.Professor and Director of Software Engineering
Oregon Graduate [email protected]
chart 4-2Copyright © 2004
by R. FairleyCSE516Summer, 2004
SESSION TOPICS
• Planning and Estimating• Measuring and Controlling• Leading and Directing• Communicating and Coordinating• Managing Risk Factors
chart 4-3Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Is A Project?
• A project is a coordinated set of work activities that:
– has a starting date and an ending date
– has well-defined objectives
– has allocated schedule and resources
– has a qualified project team
– has assigned roles and responsibilities
– produces one or more tangible work products
chart 4-4Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Is Management?
• Management is concerned with identifying, planning, coordinating, and leading the work activities of groups of people – so that they can accomplish more than the groups
could accomplish if each person acted on their own without coordination of their work activities
chart 4-5Copyright © 2004
by R. FairleyCSE516Summer, 2004
WHAT IS PROJECT MANAGEMENT?
Managing a software project involves several types of work activities:
– Planning and Estimating• schedule, resources, processes, technology
– Measuring and Controlling• quality, productivity, progress
– Leading and Directing• the project team members
– Communicating and Coordinating• with managers, other departments, other projects, other
companies, customers, users, acquirers, . . . .
– Managing Risk• identifying, prioritizing, and handling potential problems
and real problems
chart 4-6Copyright © 2004
by R. FairleyCSE516Summer, 2004
Project Management Roles
• A software project requires two types of management roles:– the project manager (the producer role)
• the project manager is responsible for delivering a satisfactory product on schedule and within budget
– the software architect (the director role)• the software architect is responsible for the
technical content of the product
chart 4-7Copyright © 2004
by R. FairleyCSE516Summer, 2004
Manager and Architect Roles
• The project manager, working with the customer, higher level management, and the software architect is responsible for a successful outcome – and (we hope) has the authority to make the
necessary decisions• The software architect is responsible for developing
technical options, presents them to the decision makers (project manager, customer, and higher level management)– and (we hope) has the authority to successfully
implement the chosen alternatives
chart 4-8Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Is Project Management?
• Project management is concerned with identifying, planning, coordinating, and controlling the work activities of a software project to deliver, on time and within budget, a product that satisfies user needs and customer expectations
• The major activities of project management are:– planning and estimating– measuring and controlling– leading and directing– communicating and coordinating– managing risk
chart 4-9Copyright © 2004
by R. FairleyCSE516Summer, 2004
customer
management
Planning and Replanning
ActivityDefinition
WorkAssign-ments
ProductDevelopment
Quality Assurance
Independent Validation
Measuring
Controlling
DataRetention
Estimating
ReportingStatus ReportsProject Reports
Requirementsand Constraints
Directives andConstraints
Change Requests and Problem Reports
ConfigurationManagement
product
. . . . . . . . . . . . .. . . .
A Workflow Model for Managing Software Projects
chart 4-10Copyright © 2004
by R. FairleyCSE516Summer, 2004
Project Foundations
• A software project should have the following foundations:– Product foundations include:
• the system requirements*• the system design constraints• the software requirements*
– Process foundations:• an engineering process model**• a workflow model• a contractual agreement• a project plan
* see Session 3**see Session 2
chart 4-11Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Contractual Agreement
A contractual agreement should contain:• scope of work• deliverable work products • delivery date(s)• customer & user review schedule• change request procedures• development constraints• product acceptance criteria• delivery, installation, and training schedule (if
appropriate)• price and payment schedule (if appropriate)
the contractual agreement is sometimescalled a Statement of Work (SOW) or aMemo of Understanding (MOU)
chart 4-12Copyright © 2004
by R. FairleyCSE516Summer, 2004
Contents of A Project Plan- IEEE Standard 1058 -
A project plan should contain:• A list of work products to be developed• References to other foundation documents• Organizational roles and responsibilities• Development methods and tools• Mechanisms of measurement and control• Necessary resources with need dates and costs• Work activities with detailed schedules and budgets• Risk factors and contingency plans• On-going risk management procedures• Plans for updating the plan
chart 4-13Copyright © 2004
by R. FairleyCSE516Summer, 2004
Plans versus Requirements
• The requirements describe what product(s) to make• The project plan is the roadmap for making the product(s)
– a map helps us to determine the best route to follow– a map helps us to communicate our planned route– a map allows us to measure progress– a map can be used to determine alternate routes– a map can help us find the way back if we get lost
Q: which comes first, the requirements or the project plan??
chart 4-14Copyright © 2004
by R. FairleyCSE516Summer, 2004
Planning Tools
• Some tools for planning a software project:– the work breakdown structure (WBS)– work packages– the schedule network– the Gantt chart– resource profiles
chart 4-15Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Work Breakdown Structure
• A work breakdown structure is a hierarchical tree structure used to:
– specify work activities– depict the “is part of” relationships among work
activities– decompose work activities into tasks* for small
teams and individual workers* a task is the smallest unit of work for management
accountabilityactivities are composed of tasks
chart 4-16Copyright © 2004
by R. FairleyCSE516Summer, 2004
ATMSoftware Project
System Interfs.
Software Dvmt.
Integr.& Test
QualityAssur.
Config. Mgmt.
UserDocs.
Project Mgmt.
BuildATMHD
BuildFINAT
BuildMAINT
BuildValidator
BuildRecorder
BuildProcessor
BuildTerminator
CUT
DES
CIT
–––
–––
–––
CUT
DES
CIT
CUT
DES
CIT
IntegrateValidator,
Processor,Recorder,
Terminator–––
CUT
DES
CIT
A WBS Example:
Integrate & TestATMHD, FINAT, MAINT
ATMHD: ATM Hardware Drivers DES: Detailed DesignFINAT: Financial Transactions CUT: Code & Unit TestMAINT: Maintenance Diagnostics CIT: Component Integration & Test
tasks
chart 4-17Copyright © 2004
by R. FairleyCSE516Summer, 2004
WBS Numbering
ATMSoftware Project
2 3 4 5 6 71
3.1 3.2 3.3
3.2.1 3.2.33.2.2 3.2.4
3.2.1.2
3.2.1.1
3.2.1.3
–––
––
–
–––
3.2.2.2
3.2.2.1
3.2.2.3
3.2.3.2
3.2.3.1
3.2.3.3
3.2.5
–––
3.2.4.2
3.2.4.1
3.2.4.3
3.4
chart 4-18Copyright © 2004
by R. FairleyCSE516Summer, 2004
Partial WBS for anATM Project ATM
Project
System Analysis
Software Dvmt.
SystemTest
QualityAssur.
Config. Mgmt.
Tech.Pubs.
Project Mgmt.
3.1. BuildATMHD
3.2. BuildFINAT
3.3. BuildMAINT
3.2.1.2CUTV
3.2.1.1DESV
3.2.1.3ITVC
–––
–––
–––
3.2.2.2CUTP
3.2.2.1DESP
3.2.2.3ITPC
3.2.3.2CUTR
3.2.3.1DESR
3.2.3.3 ITRC
3.2.5. Integrate FINAT
–––
3.2.4.2 CUTT (Code & Unit Test Terminator)
3.2.4.1 DEST (Design Terminator)
3.2.4.3 ITTC (Integrate & Test Term. Components)
1. 2. 3. 4. 5. 6. 7.
3.5. IntegrateATMHD, FINAT,MAINT & COMM
BuildValidator
3.2.1. BuildProcessor3.2.2. Build
Recorder32.3. Build
Terminator3.2.4.
1.1. 1.2.3.4. Build
COMM
chart 4-19Copyright © 2004
by R. FairleyCSE516Summer, 2004
Outline Form of the WBS1. Project Management2. System Analysis3. Software Engineering
3.1. Build ATM Hardware Drivers3.2. Build Financial Transaction Handler
3.2.1. Build Validator3.2.2. Build Transaction Processor
3.2.2.1. Design Transaction Processor3.2.2.2. Code & Unit Test Transaction Processor3.2.2.3. Integrate & Test Processor Components
3.2.3. Build Recorder3.2.4. Build Terminator
3.3. Build Maintenance & Diagnostic Subsystem3.4. Build the Communications Package3.5. Integrate ATMHD, FINAT, MAINT, and COMM
4. System Test5. Quality Assurance6. Configuration Management7. Technical Publications
chart 4-20Copyright © 2004
by R. FairleyCSE516Summer, 2004
WBS Notes
• The product structure is embedded in the work breakdown structure
• The Decimal numbering system is used to identify the elements in the WBS–the number indicates the position of the element in the WBS
–the number of digits in the WBS number indicates the depth of the element
• The example WBS is 4 levels deep –Depending on the size and complexity of the product being developed, the WBS for most projects will be decomposed in a range of 4 to 6 levels
chart 4-21Copyright © 2004
by R. FairleyCSE516Summer, 2004
WBS Work Packages
• Each work element in a WBS is documented in a work package
• A work package specifies:– the activity identifier
(number, name and description)– types and numbers of resources required– planned duration– required predecessor work activities– successor work activities– work products to be produced– acceptance criteria for the work products– risk factors for the work package
chart 4-22Copyright © 2004
by R. FairleyCSE516Summer, 2004
A Work Package Example
Activity : 3.2.2.1 DESIGN_TRANSACTION_PROCESSORActivity description: Specify internal structure of the Transaction
Processor (TP) Estimated duration: 2 weeksResources needed:
Personnel: 2 senior designersSkills: Designer must know the TP domain and
StatemateTools: One Sun workstation running StatemateTravel: 3 day Design Review in San Diego for 2 people
Predecessor tasks: 2.3.1 - Develop TP requirementsSuccessor tasks: 3.2.2.2 - Implement Transaction Processor
Work Products: Architectural specification for TPTest plan for TP
Baselines Created: Architectural specification for TPTest plan for TP
Completion criteria: design and test plan inspections by peers andsign-off of TP design by the Software Architect
Risks: senior designers not identified
chart 4-23Copyright © 2004
by R. FairleyCSE516Summer, 2004
An Activity List for a Software ProjectActivity # Description Pred. Duration #Staff
3.1 Analyze requirements - 1 2
3.2 Redesign existing components 3.1 6 4
3.3 Design new components 3.1 3 1
3.4 Design interfaces 3.3 1 2
3.5 Implement new code 3.3 6 2
3.6 Develop integration plan 3.3 2 2
3.7 Modify existing code 3.2, 3.4 5 1
3.8 Finish unit testing 3.5, 3.7 1 2
3.9 Update documentation 3.5, 3.7 2 3
3.10 Develop integration tests 3.6 1 3
3.11 Perform integration tests 3.8, 9, 10 1 2
3.12 Perform acceptance tests 3.11 1 1
chart 4-24Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Activity Network - Critical Path Method (CPM)
1 2
3
4 6 7
8 9 10
5
3.13.3
3.4
3.5
3.6 3.10
3.9
3.8
3.11 3.12
(1)
(3)
(6)
3.7
(5) (1)
(0)
(2) (1)
(1) (1)(1)
(6)
(2)
x.y = Activity; x = Milestone; (x) = Activity duration
3.2
chart 4-25Copyright © 2004
by R. FairleyCSE516Summer, 2004
Activity Gantt Chart with Slack Times
WEEK
3.1 3.2 3.3
3.4 3.5 3.6 3.7
3.8 3.93.103.113.12
1 3 5 7 9 11 13 15
chart 4-26Copyright © 2004
by R. FairleyCSE516Summer, 2004
Earliest Start-Time Staffing Profile
# of People
Week
Personnel Loading (Early Start)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
10
8
6
4
2
EARLY STARTPROFILE
chart 4-27Copyright © 2004
by R. FairleyCSE516Summer, 2004
Latest Start-Time Staffing Histogram
# of People
Week
Personnel Loading (Late Start)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
10
8
6
4
2
LATEST-STARTPROFILE
chart 4-28Copyright © 2004
by R. FairleyCSE516Summer, 2004
A RESOURCE–LEVELLEDSTAFFING PROFILE
10
8
6
4
2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# STAFF
WEEK
chart 4-29Copyright © 2004
by R. FairleyCSE516Summer, 2004
A Constrained Staffing Profile
10
8
6
4
2
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# ofPeople
Week
chart 4-30Copyright © 2004
by R. FairleyCSE516Summer, 2004
WHAT TO DO?
• Add more people?• Take more time?• Descope the requirements?• Use more efficient (and effective) resources?• Play “chicken?”• Plan for overtime?• Sacrifice quality?
– reduce testing– reduce documentation– eliminate on-line help messages
chart 4-31Copyright © 2004
by R. FairleyCSE516Summer, 2004
Project Estimation
• The following project factors must be estimated:– effort and other resources (= cost)– schedule with milestones– product size and complexity– product quality (defects, safety, security, ...)– risk factors
chart 4-32Copyright © 2004
by R. FairleyCSE516Summer, 2004
Project Estimation - II
• An estimate is a projection from past to future, suitably adjusted to account for differences between past and future– past: history of past projects– future: requirements for the product– adjustment factors: to account for difference between
past and future
chart 4-33Copyright © 2004
by R. FairleyCSE516Summer, 2004
Elements of Estimation
HistoricalData
AdjustmentFactors
Future-ProductAttributes
Estimate
EstimationProcedure
Assumptions and Constraints*
* Assumption: something taken to be true Constraint: an imposed must-be or must-do
chart 4-34Copyright © 2004
by R. FairleyCSE516Summer, 2004
Some Adjustment Factors* for Software Projects
• ‘goodness’ of the requirements• Size of data and code• Complexity of data and code• Required reliability• Time and memory constraints• Quality of the development tools• Familiarity of the development tools• Engineering processes used• Engineering methods used• Experience in the application domain• Skills and motivation of the people• Schedule pressure
*factors that make seemingly similarprojects differ in effort, schedule, quality, . . .
chart 4-35Copyright © 2004
by R. FairleyCSE516Summer, 2004
Estimation Techniques
• Estimation techniques include:– Analogy– Rule of Thumb– Expert Judgment– Designing to Cost and Schedule– WBS/activity network/resource loading– Algorithmic Models
• theory-based models (e.g., SLIM)=> regression-based models (e.g., COCOMO)
chart 4-36Copyright © 2004
by R. FairleyCSE516Summer, 2004
Regression-Based Estimation Models
• Analysis of past projects might show a “best-fit” relationship between project size and work effort of the form:
Effort = A * (Size) ^ B; – for example:
Effort = 2.5 * (Size) ^ 1.25where Effort is in Person-Weeks and Size is in
Thousands of Delivered Lines of Code• Adjustment factors (AFs) are then applied to the Effort
estimate to adjust it up or downEffort = A * (Size) ^ B * AFs
Q: why is the Effort-Sizerelation non-linear?
chart 4-37Copyright © 2004
by R. FairleyCSE516Summer, 2004
Deriving A Regression Model
••*
*
*******
*
**
* *
*
*
**** **
log LOC3 (1k) 4 (10k) 5 (100k) 6 (1000k)
* ****
**
***
*
*
1 (10)
2 (100)
3 (1000)
4 (10000)
log Staff-Months
*
*
**
ProjectHistories:
why do projectsof the same sizerequire differentamounts of work?
log SM = log a + b * log LOCSM = a * (LOC)^be.g. SM = 2.8 * LOC ^ 1.25
log a
b
chart 4-38Copyright © 2004
by R. FairleyCSE516Summer, 2004
An Example
• Suppose we estimate the product size to be 50,000 lines of code
• Then the unadjusted effort estimate is:– Effort = 2.5 * (50) ^ 1.25– Effort = 2.5 * 133 = 332 person-weeks
• Suppose we assume skilled people and a familiar job; we will reduce the estimate by 20%
• Adjusted Effort = 0.8 x 332 = 266 staff-weeks• Effort can then be broken down into combinations of people
and time; for example: – 10 people for 26 weeks– but probably not 26 people for 10 weeks– and not 266 people for one week
chart 4-39Copyright © 2004
by R. FairleyCSE516Summer, 2004
Regression-Based Estimation
•**
*******
*
**
***
**** *
log Size, S (LOC)
* ****
**
***
*
*
log Effort, E (Staff-Months)
*
*
**
ProjectHistories:
E = 2.5 * (S) ^ 1.25
266 staff-weeks
X
3 (1k) 4 (10k) 5 (100k) 6 (1000k)
1 (10)
2 (100)
3 (1000)
4 (10000)
chart 4-40Copyright © 2004
by R. FairleyCSE516Summer, 2004
Effort, Schedule, and Cost
• Effort is the amount of work required to accomplish a work activity– for example, 266 person-weeks (PWs)
• Schedule is the amount of time required to accomplish a set of work activities– for example, 26 weeks
• To accomplish a 266 person-week project in 26 weeks, we need 266 / 26 = 10 people
• Labor cost is determined by loaded salaries– for example, if loaded salaries are $10,000 per
person-month, a 266 person-week (66 person-month project will cost $660,000 for salaries (or 660/50 = $13 per LOC)
chart 4-41Copyright © 2004
by R. FairleyCSE516Summer, 2004
Productivity and Unit Cost
• Productivity is the ratio of product produced to effort consumed
• Average productivity for the project is:– 50,000 LOC / 660 PW = 75 LOC/PW
• Unit cost is:– $660,000 / 50,000 LOC = $13 per LOC – for salaries for design, coding, and testing
• note: a typical cost for developing applications programs such as spreadsheets and word processors is $35 to $50 per LOC
chart 4-42Copyright © 2004
by R. FairleyCSE516Summer, 2004
Productivity and Production Rate
• Productivity is:Output_Produced / Resources_Used
for example:if we design, write, and test 3000 lines of code using 6 person-weeks of effort, our productivity is
3000 / 6 = 500 LOC / PW(500 Lines-Of-Code per Person-Week)
• Production rate is the amount of output produced by everyone working at an activityif 3 people each produce 500 LOC/PW the production rate for each week is 1500 LOC
• Productivity and production involve both quantity of output and quality of output produced
chart 4-43Copyright © 2004
by R. FairleyCSE516Summer, 2004
A Question
Who is more productive?
The person who writes 500 lines of poor quality code in 5 days (100 LOC/PD) or
the person who thinks about it, reads some books, and talks to people for 4 days then writes 50 lines of high quality code on the 5th day (10 LOC/PD) to do the same thing?
LOC/PD: lines-of-code per programmer-day
chart 4-44Copyright © 2004
by R. FairleyCSE516Summer, 2004
Rework and Productivity
• There are two types of rework:– evolutionary rework– avoidable rework
• Evolutionary rework occurs when we add enhancements to increase the value of the product for the users
– evolutionary rework must add value, otherwise it is avoidable rework
• Avoidable rework occurs:– when we correct mistakes that we could have avoided– when we have to redo a poorly done job
• Avoidable rework reduces our net productivity and our net production rate
chart 4-45Copyright © 2004
by R. FairleyCSE516Summer, 2004
Productivity - II
• We must distinguish net productivity from gross productivity:
Net = Gross - Avoidable Rework*In many organizations, avoidable rework amounts to 30% to 50% of all work activities in software development and modification
• Net productivity varies widely among individuals and organizations– factors of 10 or 20 are not uncommon– largely caused by variations in avoidable rework
chart 4-46Copyright © 2004
by R. FairleyCSE516Summer, 2004
Avoidable Rework
• Avoidable rework is caused by– lack of skill, training, or tools– lack of cost-effective work processes– inadequate communication– excessive schedule pressure– poor motivation, morale, or leadership– human fallibility– other reasons?
chart 4-47Copyright © 2004
by R. FairleyCSE516Summer, 2004
Estimation Techniques
• Estimation techniques include:– Analogy– Rule of Thumb– Expert Judgment=> Designing to Cost and Schedule– WBS/activity network/resource loading– Algorithmic Models
• theory-based models (e.g., SLIM)• regression-based models (e.g., COCOMO)
chart 4-48Copyright © 2004
by R. FairleyCSE516Summer, 2004
Designing to Cost and Schedule
• How to estimate a schedule-constrained project?• What to do if we don’t have enough historical data to
build a regression model?Design to cost and schedule:• Suppose we have 5 people to do a project in 6 months
(5x6=30 staff-months of effort)• Also suppose we know our past productivity on a similar
project was 500 LOC/SM• Then we can build a product of 15,000 LOC
– (30x500 = 15,000)
chart 4-49Copyright © 2004
by R. FairleyCSE516Summer, 2004
Designing to Cost and Schedule - II
• Q: What to do if we have no historical data and no productivity numbers?
• A: Prioritize the requirements and pursue an iterative approach until the scheduled delivery date arrives– use a prioritized, spiral approach so that the most
important parts are completed first
chart 4-50Copyright © 2004
by R. FairleyCSE516Summer, 2004
Measuring Software Size by Lines of Code
• Lines of code may not be a good size measure:– measuring productivity by LOC may encourage
developers to write lots of lines of bad code– use of modern methods and tools makes it difficult (or
irrelevant) to measure lines of code
chart 4-51Copyright © 2004
by R. FairleyCSE516Summer, 2004
An Alternative Way to Measure the System
• To estimate effort, schedule, defect levels, etc., use product factors in the environment of the software instead of estimating and measuring size in lines of code
system ofinterest
stimuli responses
Environment
chart 4-52Copyright © 2004
by R. FairleyCSE516Summer, 2004
Fairley’s Conjecture
• It is always possible to find factors in the environment of the software to be developed that can be used to estimate project factors of interest such as effort, schedule, defect level, and so forth
• For example, # of user screens, # of menus, # of items per menu, # of buttons in a user interface– examine past projects to determine the amount of
effort required– use that productivity factor to estimate future
projects
chart 4-53Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Procedure
1. Identify the major environmental factors that influence the factors of interest such as the amount of work, time, and quality on past projects
2. From past projects, develop conversion factors to convert from environmental factors to factors of interest – for example, user-screens per day or defects fixed per week
3. Count the environmental factors for the project to be estimated4. Use the conversion factors to estimate the factors of interest5. Add adjustment factors to “fine-tune” the estimates
see the function point materialin the Pressman text, page 89-91
chart 4-54Copyright © 2004
by R. FairleyCSE516Summer, 2004
Major Activities of Project Management
• Planning and Estimating=> Measuring and Controlling• Managing Risk Factors• Leading and Directing• Representing the Project
chart 4-55Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Do We Need To Measure and Control?
• Cost: expenditures• Schedule: milestones achieved• Progress: work products completed• Quality: defects, reliability• Rework: non-productive work• Risk: risk factors
chart 4-56Copyright © 2004
by R. FairleyCSE516Summer, 2004
Binary Tracking of Progress
• Work tasks (WBS elements)are documented in work packages
• Each work package produces one or more tangible work products that have specified acceptance criteria
• Work tasks are counted a 0% complete until the associated work product(s) satisfy their acceptance criteria
– the work task is then counted 100% complete• Effort, schedule, cost, etc are tracked at the task level and
“rolled up” in the WBS for status reporting
chart 4-57Copyright © 2004
by R. FairleyCSE516Summer, 2004
Binary Tracking of Work Packages
Coding
InputModule
ProcessModule
GetInput
EditData
ProcessData
3.
3.1 3.2
3.1.1 3.2.1 3.2.2 3.2.33.1.2
CheckInput
FormatData
100% 0%
50% 33%
0% 100% 0%
41.5%complete
Assuming all work packages are of equal size; if not, they must be weighted by relative effort
chart 4-58Copyright © 2004
by R. FairleyCSE516Summer, 2004
More Detailed Decomposition
Coding
InputModule
ProcessModule
GetInput
EditData
ProcessData
3.
3.1 3.2
3.1.1 3.2.1 3.2.2 3.2.33.1.2
CheckInput
FormatData
100%
75% 67%
100% 50%
71%complete
EditIncr1
EditIncr2
0%100%0%
ErrorHandling
100%
ScanInput
50% 50%
Proc.Incr1
Proc.Incr2
0%100%
chart 4-59Copyright © 2004
by R. FairleyCSE516Summer, 2004
An Observation
• The tracking examples report progress as:– 41.5% complete
and– 71% complete
• Finer levels of detail provide increased accuracy of measurement
– at the risk of micro-managementHence, the 40 staff-hour rule-of-thumb
which is a good compromise between accuracy of measurement and micro-management
chart 4-60Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Rolling Wave Approach to Incremental Planning and Tracking
• It is impossible (and undesirable) to plan at this level of detail for the entire project in the beginning
• Each month the WBS and schedule network are updated (rolled forward)– work packages for the next month (4 weeks) are
decomposed to the level of one work-week each and tracked at that level
– work packages for the next three months are decomposed as much as possible
– the entire WBS and schedule network are reviewed and updated as necessary
chart 4-61Copyright © 2004
by R. FairleyCSE516Summer, 2004
Corrective Action• Corrective action involves adjusting the project when actual results do
not conform to planned results• Corrective actions can include:
– changing the project • more time• more people (beware of Brooks’ Law)• better people (better resources)• incremental delivery
– changing the product• simplify the product features• remove some requested features• reduce quality requirements• reduce documentation
chart 4-62Copyright © 2004
by R. FairleyCSE516Summer, 2004
Incremental Demonstrations of Progress
• Periodic demonstrations of evolving product capabilities may be the only way to measure product factors such as memory use, execution time, reliability, safety, or security– allocate technical parameters to elements of the
product architecture– measure values in incremental demonstrations– compare demonstrated values to planned values– taking corrective action as necessary
chart 4-63Copyright © 2004
by R. FairleyCSE516Summer, 2004
Demonstrating Incremental Progress
BuildVersion N
• • •• • • • • •
BuildVersion 2
BuildVersion 1
Time
ValidateVersion 0.1
ValidateVersion 0.1+0.2
• • •• • • • • •
Goal:Rework < 20%
DeliverVersion 1.0
Demo
Demo
Demo
chart 4-64Copyright © 2004
by R. FairleyCSE516Summer, 2004
Incremental Measurement of Memory Usage
IncrementalVersions
MemoryUsed
V1 V2 V3 V4 V5
10% reserve
256K225K
Actual
Plan
chart 4-65Copyright © 2004
by R. FairleyCSE516Summer, 2004
Major Activities of Project Management
• Planning and Estimating• Measuring and Controlling=> Managing Risk Factors• Leading and Directing• Representing the Project
chart 4-66Copyright © 2004
by R. FairleyCSE516Summer, 2004
Managing Risk Factors
• A risk is a potential problem– a problem is a risk that has materialized
• A risk is characterized by probability and impact– probability: the chance the problem might happen– impact: the negative effects if the problem happen
• A risk becomes a problem when a risk indicator crosses some threshold value– pre-planned corrective actions must be invoked
chart 4-67Copyright © 2004
by R. FairleyCSE516Summer, 2004
Risk Management Procedures
• Systematic risk management involves:– identifying risk factors: distinguish symptoms from
causes– prioritizing them: analyzing probabilities and impacts– deciding on a strategy for dealing with each significant
risk factor– developing action plans and contingency plans– tracking contingent risks– working contingency plans, as necessary– engaging in crisis management when action plans and
contingency plans fail
chart 4-68Copyright © 2004
by R. FairleyCSE516Summer, 2004
Risk Management Strategies
• Risk Avoidance– change the requirements– change the technology– extend the schedule– get more or better skilled people– find a new job
• Risk Transfer– move some features into the hardware– require more highly-skilled users– use special-skills subcontractor(s)
• Risk Handling– develop action plans and contingency plans
chart 4-69Copyright © 2004
by R. FairleyCSE516Summer, 2004
Format of an Action Plan
• An Action Plan specifies:– the risk factor (problem to be avoided)– actions to be completed– responsible parties– available resources– progress milestones– required completion date– completion criteria
chart 4-70Copyright © 2004
by R. FairleyCSE516Summer, 2004
Format of a Contingency Plan
• A Contingency Plan should specify:– the risk factor (problem to be avoided)– tracking mechanism– threshold trigger– contingency actions, if needed
• documented in an action plan– maximum duration of the contingent-action plan
chart 4-71Copyright © 2004
by R. FairleyCSE516Summer, 2004
Crisis Management
• Failure to resolve a crisis in a timely manner requires making some major decisions about the project– should it be cancelled?– should it be rescoped?– should some people be replaced?– should different people be added?– should different technology be tried?
• Crisis management requires making hard decisions and generating new plans– a shut-down plan or a re-direction plan must be
developed
chart 4-72Copyright © 2004
by R. FairleyCSE516Summer, 2004
Major Activities of Project Management
• Planning and Estimating• Managing Risk Factors• Measuring and Controlling=> Leading and Directing• Representing the Project
chart 4-73Copyright © 2004
by R. FairleyCSE516Summer, 2004
Attributes of A Leader
A good leader is a good:• Communicator• Listener• Facilitator• Visionary• Coach• Enthusiast• Crisis Manager
Leading should not be confused with managing
chart 4-74Copyright © 2004
by R. FairleyCSE516Summer, 2004
Leading vs Managing
• A good manager is a good planner, estimator, progress tracker, and risk anticipator
• A good leader is a good “people person”• Software projects need good managers and good leaders
– one or more persons must play these roles• sometimes the software architect plays the role of
project leader• and the project manager goes along with it
chart 4-75Copyright © 2004
by R. FairleyCSE516Summer, 2004
Motivation
• Motivation is the drive to satisfy one’s psychological needs
• We cannot motivate others but we can create the conditions in which people can satisfy some of their psychological needs at work
• Sometimes, we can create our own conditions that will satisfy our psychological needs at work– for example, finding a quiet “hiding place” to get
some work done– or working at home sometimes
chart 4-76Copyright © 2004
by R. FairleyCSE516Summer, 2004
The Psychology of Job Satisfaction
• In order to satisfy their psychological needs at work, people need:
– to know their work is important– to use a variety of skills– to perform well defined tasks– to have a sense of achievement– to receive feedback and recognition– to have profession growth opportunities– to have some autonomy– to have pleasant social interactions
different people need these things to different degrees
chart 4-77Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Makes Software Engineers Happy At Work?
• A quiet place to work• Challenging technical problems• Autonomy to solve problems• Ability to control own schedule• A chance to learn new things & try new ideas• Adequate computing facilities• Competent technical leadership• Chance to communicate with peers:
electronic mail, bulletin boards, news groups, technical conferences
chart 4-78Copyright © 2004
by R. FairleyCSE516Summer, 2004
What Makes A Good Software Project Team?
• Correct skill mixture• Good tools• Respect for one another• Shared ownership of the results• Respect for leaders and managers• Good communication skills• Willingness to be team members• Fair treatment of each person• Good working environment• Having some fun together
chart 4-79Copyright © 2004
by R. FairleyCSE516Summer, 2004
Major Activities of Project Management
• Planning and Estimating• Managing Risk Factors• Measuring and Controlling• Leading and Directing=> Communicating and Coordinating
chart 4-80Copyright © 2004
by R. FairleyCSE516Summer, 2004
Representing the Project
• The project manager and software architect must be the communicators and coordinators with those who are interested in the project:– users– customer(s)– potential customers– higher-level management– other projects– subcontractors– other departments
• training, quality assurance, configuration management, maintenance, documentation
chart 4-81Copyright © 2004
by R. FairleyCSE516Summer, 2004
Major Activities of Project Management
• Planning and Estimating• Measuring and Controlling• Leading and Directing• Communicating and Coordinating• Managing Risk
chart 4-82Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS - CHAPTER 2
• “More software projects have gone awry for lack of calendar time than for all other causes combined”
• Why?– bad estimates– confusing effort with progress– failure to stick by our estimates– failure to monitor our schedules– adding people to try to make up time on the schedule
chart 4-83Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS - CHAPTER 2
Brooks’ Law• “Adding manpower to a late software project makes it later”• Reasons
– training of new people– repartitioning of the work– increased communication: n(n-1)/2
• going from 6 people to 7 people increases the number of communication paths from 15 to 21
• This need not happen if:– problem is recognized early– well-defined tasks can be partitioned off– qualified people are available to do those tasks
chart 4-84Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS - CHAPTER 2Some memorable quotes:• “All programmers are optimists”• “We tend to blame the physical media for most of our
implementation difficulties”• “The programmer builds from pure thought-stuff”• “Men and months are interchangeable commodities only when
a task can be partitioned among many workers with no communication among them”
• “The bearing of a child takes nine months, no matter how many women are assigned”
chart 4-85Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS - CHAPTER 2Memorable quotes:• “If each part of the task must be separately coordinated with
each other part, the effort increases as n(n-1)/2”• “For some years I have been successful using the following
rule of thumb when scheduling a software task: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test NOTE: This is one area that is now outdated
chart 4-86Copyright © 2004
by R. FairleyCSE516Summer, 2004
AN UPDATE TO BROOKS’ SCHEDULING RULE-OF-THUMB
• Modern techniques allow us to spend:60% of our effort in planning, requirements, and design20% of our effort in detailed design and coding20% of our effort in validation
chart 4-87Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS -- CHAPTER 3
• Chapter 3 addresses the issue of how to organize projects • Brooks’ chief surgeon is analogous to our team leader or
chief architect• The other roles in Chapter 3 are roles that can be played
by different developers, in addition to their developer roles
– language expert– assistant manager/architect– tester– toolsmith
chart 4-88Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS -- CHAPTER 8
• The most important point is the non-linear relationship between product size and effort– Effort = a * (Size) ^ b * (adjustment factors)– b > 1: diseconomy of scale– b < 1: economy of scalethe values of a, b, and the adjustment factors will be
different for different types of systems and in different organizations
• Another interesting relation is that between effort and schedule– Schedule = K * (Effort) ^ 0.33
chart 4-89Copyright © 2004
by R. FairleyCSE516Summer, 2004
BROOKS -- CHAPTER 14
• Chapter 14 is concerned with preparing and tracking the schedule– use frequent, verifiable milestones– monitor the critical path– have standard reports that are reviewed on a regular
basis (weekly)• Without planning and tracking of detailed, objective
milestones a project gets to be one year late“one day at a time”
chart 4-90Copyright © 2004
by R. FairleyCSE516Summer, 2004
SESSION TOPICS
– Planning and Estimating– Measuring and Controlling– Managing Risk Factors– Leading and Directing– Communicating and Coordinating