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]



SESSION TOPICS

• Planning and Estimating• Measuring and Controlling• Leading and Directing• Communicating and Coordinating• Managing Risk Factors



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



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



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



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



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



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



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



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



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)



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



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??



Planning Tools

• Some tools for planning a software project:– the work breakdown structure (WBS)– work packages– the schedule network– the Gantt chart– resource profiles



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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, . . .



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)



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?



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



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



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)



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)



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



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



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



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



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



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?



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)



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)



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



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



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



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



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



Major Activities of Project Management

• Planning and Estimating=> Measuring and Controlling• Managing Risk Factors• Leading and Directing• Representing the Project



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



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



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



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%



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



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



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



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



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



Incremental Measurement of Memory Usage

IncrementalVersions

MemoryUsed

V1 V2 V3 V4 V5

10% reserve

256K225K

Actual

Plan




• Planning and Estimating• Measuring and Controlling=> Managing Risk Factors• Leading and Directing• Representing the Project



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



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



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



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



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



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




• Planning and Estimating• Managing Risk Factors• Measuring and Controlling=> Leading and Directing• Representing the Project



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



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



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



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



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



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




• Planning and Estimating• Managing Risk Factors• Measuring and Controlling• Leading and Directing=> Communicating and Coordinating



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




• Planning and Estimating• Measuring and Controlling• Leading and Directing• Communicating and Coordinating• Managing Risk



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



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



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”



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



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



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



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



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”



SESSION TOPICS

– Planning and Estimating– Measuring and Controlling– Managing Risk Factors– Leading and Directing– Communicating and Coordinating

chart 4-1 copyright © 2004 by r. fairley cse516 summer, 2004 cse 516 introduction to software...

Documents