Software Project Management

MOE 225 Software Engineering

Topic 8

Project Teams - Overview

Team organization Democratic team approach Classical chief programmer team approach Beyond chief programmer and democratic teams Synchronize-and-stabilize teams Extreme programming teams

Programming Team Organization

A product must be completed within 3 months, but 1 person-year of programming is still needed

Solution• If one programmer can code the product in 1 year, four programmers

can do it in 3 months

Nonsense• Four programmers will probably take nearly a year

• The quality of the product is usually lower

Task Sharing

If one farm hand can pick a strawberry field in 10 days, ten farm hands can pick same strawberry field in 1 day

One woman can produce a baby in 9 months, but nine women cannot possibly produce that baby in 1 month

Unlike baby production, it is possible to share coding tasks between members of team

Unlike strawberry picking, team members must interact in meaningful and effective way

Programming Team Organization

Example: • Freda and Joe code two modules, mA and mB, say.

What can go wrong?• Both Freda and Joe may code mA, and ignore mB

• Freda may code mA, Joe may code mB. When mA calls mB it passes 4 parameters; but mB requires 5 parameters

• Or, the order of parameters in mA and mB may be different• Or, the order may be same, but the data types may be slightly

different

This has nothing whatsoever to do with technical competency • Team organization is a managerial issue

Communications Problems Example

• There are three channels of communication between 3 programmers working on project. The deadline is rapidly approaching but the code is not nearly complete

“Obvious” solution: • Add a fourth programmer to the

team But other three have to explain in detail

• What has been accomplished• What is still incomplete

Brooks’s Law• Adding additional programming personnel to a team when

product is late has the effect of making the product even later

Democratic Team Approach

Basic underlying concept—egoless programming Programmers can be highly attached to their code

• They even name their modules after themselves• They see their modules as extension of themselves

If a programmer sees a module as an extension of his/her ego, he/she is not going to try to find all the errors in “his”/“her” code• If there is an error, it is termed a bug • The fault could have been prevented if code had been better guarded against the “bug”

• “Shoo-Bug” aerosol spray

Democratic Team Approach

Proposed Solution• Egoless programming

• Restructure the social environment

• Restructure programmers’ values

• Encourage team members to find faults in code

• A fault must be considered a normal and accepted event

• The team as whole will develop an ethos, group identity

• Modules will “belong” to the team as whole

• A group of up to 10 egoless programmers constitutes a democratic team

Democratic Team Approach

Strengths of Democratic Team Approach• Democratic teams are enormously productive

• They work best when the problem is difficult

• They function well in a research environment

• Problem: • Democratic teams have to spring up spontaneously

Difficulties with Democratic Team Approach• Management may have difficulty

• Difficult to introduce into an undemocratic environment

Chief Programmer Teams

Consider a 6-person team• Fifteen 2-person

communication channels

• The total number of 2-, 3-, 4-, 5-, and 6-person groups is 57

• This team cannot do 6 person-months of work in 1 month

Chief Programmer Teams (contd)

Six programmers, but now only 5 lines of communication

Classical Chief Programmer Teams

Basic idea behind the concept• Analogy: chief surgeon directing operation, assisted by

• Other surgeons

• Anesthesiologists

• Nurses

• Other experts, such as cardiologists, nephrologists

Two key aspects• Specialization

• Hierarchy

Classical Chief Programmer Teams Chief programmer

• Successful manager and highly skilled programmer• Does the architectural design• Allocates coding among the team members• Writes the critical (or complex) sections of code• Handles all the interfacing issues• Reviews the work of the other team members• Is personally responsible for every line of code

Back-up programmer• Necessary only because the chief programmer is human• The back-up programmer must be in every way as competent as the chief programmer• Must know as much about the project as the chief programmer• Does black-box test case planning and other tasks that are independent of the design process

Classical Chief Programmer Teams Programming secretary

• A highly skilled, well paid, central member of the chief programmer team• Responsible for maintaining the program production library (documentation of

project), including:• Source code listings• JCL• Test data

• Programmers hand their source code to the secretary who is responsible for • Conversion to machine-readable form, • Compilation, linking, loading, execution, and running test cases (1971, remember!)

Programmers • Do nothing but program• All other aspects are handled by the programming secretary

Classical Chief Programmer Teams Strengths of CPT Approach

• It works• Numerous successful projects have used variants of CPT

Weaknesses of the CPT Approach• Chief programmer must be a highly skilled programmer and a successful manager

• Shortage of highly skilled programmers• Shortage of successful managers• Programmers and managers “are not made that way”

• Back-up programmer must be as good as the chief programmer• But he/she must take a back seat (and a lower salary) waiting for something to happen to the chief programmer• Top programmers, top managers will not do that

• Programming secretary does nothing but paperwork all day• Software professionals hate paperwork

• Classical CPT is impractical

Beyond CP and Democratic Teams We need ways to organize teams that

• Make use of the strengths of democratic teams and chief programmer teams, and• Can handle teams of 20 (or 120) programmers

Democratic teams• Positive attitude to finding faults

Use CPT in conjunction with code walkthroughs or inspections Potential Pitfall Chief programmer is personally responsible for every line of code.

• He/she must therefore be present at reviews Chief programmer is also the team manager

• He/she must therefore not be present at reviews!

Beyond CP and Democratic Teams

Solution• Reduce the managerial role of the chief programmer

Beyond CP and Democratic Teams It is easier to find a team leader than a chief programmer Each employee is responsible to exactly one manager—lines of responsibility are clearly

delineated Team leader is responsible for only technical management Budgetary and legal issues, and performance appraisal are not handled by the team leader Team leader participates in reviews—the team manager is not permitted to do so Team manager participates at regular team meetings to appraise the technical skills of the

team members

Larger Projects

Nontechnical side is similar For even larger products, add additional layers

Beyond CP and Democratic Teams

Decentralize the decision-making process where appropriate Useful where the democratic team is good

Synchronize-and-Stabilize Teams

Used by Microsoft Products consist of 3 or 4 sequential builds Small parallel teams

• 3 to 8 developers• 3 to 8 testers (work one-to-one with developers)• Team is given the overall task specification• They may design the task as they wish

Why this does not degenerate into hacker-induced chaos• Daily synchronization step• Individual components always work together

Synchronize-and-Stabilize Teams

Rules• Must adhere to the time to enter the code into the database for that day's

synchronization

Analogy• Letting children do what they like all day … but with a 9 P.M. bedtime

Will this work in all companies?• Perhaps if the software professionals are as good as at Microsoft

• Again, more research is needed

Extreme Programming Teams

Feature of XP• All code is written by two programmers sharing a computer

• “Pair programming”

Advantages of Pair Programming• Test cases drawn up by one member of team

• Knowledge not all lost if one programmer leaves

• Inexperienced programmers can learn

• Centralized computers promote egoless programming

Final Remarks on Team Organization

There is no one solution to the problem of team organization The “correct” way depends on

• The product • The outlook of the leaders of the organization• Previous experience with various team structures

Very little research has been done on software team organization• Instead, team organization has been based on research on group dynamics in general

Without relevant experimental results, it is hard to determine optimal team organization for a specific product

Planning and Estimating Overview

Planning and the software process Estimating duration and cost Software project management plan components Software project management plan framework IEEE software project management plan Planning of testing Planning of object-oriented projects Training requirements Documentation standards

Planning and Estimating

Before starting to build software, it is essential to plan the entire development effort in detail

Planning continues during development and then maintenance• Initial planning is not enough• The earliest possible detailed planning is after the specification

phase

Planning and the Software Process

Accuracy of estimation increases as the process proceeds

Planning and the Software Process

Example• Cost estimate of $1 million during the requirements phase

• Likely actual cost is in the range ($0.25M, $4M)

• Cost estimate of $1 million in the middle of the specification phase • Likely actual cost is in the range ($0.5M, $2M)

• Cost estimate of $1 million end of the specification phase (earliest appropriate time)

• Likely actual cost is in the range ($0.67M, $1.5M)

This model is old (1976)• Estimating techniques have improved• But the shape of the curve is likely to be similar

Estimating Duration and Cost

Accurate duration estimation is critical Accurate cost estimation is critical

• Internal, external costs

There are too many variables for accurate estimate of cost or duration

Human Factors

Sackman (1968) showed differences of up to 28 to 1 between pairs of programmers

He compared matched pairs of programmers• Product size

• Product execution time

• Development time

• Coding time

• Debugging time

Critical staff members may resign during project

Metrics for the Size of a Product

Lines of Code (LOC) Software Science FFP Function Points COCOMO

Lines of Code

Lines of code (LOC), or Thousand delivered source instructions (KDSI)

• Source code is only a small part of total software effort • Different languages different lengths of code • LOC not defined for nonprocedural languages (like LISP) • It is not clear how to count lines of code

• Executable lines of code?

• Data definitions ?

• Comments?

• JCL statements?

• Changed/deleted lines?

• Not everything written is delivered to the client

Lines of Code (contd)

LOC is known when the product finished Estimation based on LOC is doubly dangerous

• To start estimation process, LOC in finished product must be estimated

• LOC estimate is then used to estimate the cost of the product — uncertain input to an uncertain cost estimator

Software Science

Metrics based on number of operands, operators Limited predictive power—metrics can be

computed only after the product has been implemented

There are major doubts about the validity of Software Science

Metrics for the Size of a Product

Metrics based on measurable quantities that can be determined early in software life cycle • FFP

• Function Points

FFP Metric

For cost estimation of medium-scale DP systems The three basic structural elements of DP systems

• files, flows, and processes

Given number of files (Fi), flows (Fl), processes (Pr)• Size (S), cost (C) given by

S = Fi + Fl + Pr

C = b S

Constant b varies from organization to organization Validity and reliability of FFP metric were demonstrated using a

purposive sample • BUT, the metric was never extended to include databases

Function Points

Based on number of inputs (Inp), outputs (Out), inquiries (Inq), master files (Maf), interfaces (Inf)

For any product, size in “function points” is given byFP = 4 Inp + 5 Out + 4 Inq + 10 Maf + 7 Inf

Oversimplification of a 3-step process.

Function Points (contd)

1. Classify each component of product (Inp, Out,

Inq, Maf, Inf) as simple, average, or complex. • Assign appropriate number of function points

• Sum gives UFP (unadjusted function points)

Function Points (contd)

2. Compute technical complexity factor (TCF) • Assign value from 0 (“not present”)

to 5 (“strong influence throughout”) to each of 14 factors such as transaction rates, portability

• Add 14 numbers total degree of influence (DI)

TCF = 0.65 + 0.01 DI

• Technical complexity factor (TCF) lies between 0.65 and 1.35

3. Number of function points (FP) given by

FP = UFP TCF

Analysis of Function Points

Function points are usually better than KDSI—but there are some problems

“Errors in excess of 800% counting KDSI, but only 200% in counting function points” (Jones, 1987)

Like FFP, maintenance can be inaccurately measured

Techniques of Cost Estimation

Expert judgment by analogy Experts compare target product to completed products

• Guesses can lead to hopelessly incorrect cost estimates • Experts may recollect completed products inaccurately• Human experts have biases • However, results of estimation by broad group of experts may be accurate

Bottom-up approach Break product into smaller components

• Smaller components may be no easier to estimate• Process-level costs

Techniques of Cost Estimation

Algorithmic models Metric used as input to model to compute cost, duration

• An algorithmic model is unbiased, and superior to expert opinion

• However, estimates are only as good as the underlying assumptions

Examples• SLIM Model

• Price S Model

• COnstructive COst MOdel (COCOMO)

COCOMO consists of three models• Macro-estimation model for product as a whole

• Intermediate COCOMO

• Micro-estimation model which treats product in detail

We examine intermediate COCOMO

Intermediate COCOMO

1. Estimate length of product in KDSI

2. Estimate product development mode (organic, semidetached, embedded) Example

• Straightforward product (“organic mode”)Nominal effort = 3.2 (KDSI)1.05 person-months

Intermediate COCOMO

3. Compute nominal effort Example

• Organic product, est. 12,000 delivered source statements (12 KDSI)Nominal effort = 3.2 (12)1.05 = 43 person-months

4. Multiply nominal value by 15 software development cost multipliers Example

• Product complexity multiplier

Intermodule control and decision tables

Intermediate COCOMO (contd)

Software development effort multipliers

Intermediate COCOMO (contd)

Example• Microprocessor-based communications processing software for

electronic funds transfer network with high reliability, performance, development schedule, and interface requirements

1. Complex (“embedded”) mode2. Estimate: 10,000 delivered source instructions3. Nominal effort = 2.8 (10)1.20 = 44 person-months4. Product of effort multipliers = 1.35, so estimated

effort for project is • 1.35 44 = 59 person-months

Intermediate COCOMO (contd)

Software development effort multipliers

Intermediate COCOMO (contd) Estimated effort for project (59 person-months) used as input for

additional formulas for• Dollar costs

• Development schedules

• Phase and activity distributions

• Computer costs

• Annual maintenance costs

• Related items

Intermediate COCOMO has been validated with respect to broad sample

Actual values within 20% of predicted values about 68% of time• Intermediate COCOMO was most accurate estimation method of its time

COCOMO II 1995 extension to 1981 COCOMO that incorporates

• Object orientation

• Modern life-cycle models

• Rapid prototyping

• Fourth-generation languages

• COTS software

COCOMO II is far more complex than the first version Three different models

• Application composition model for early phases• Based on feature points (like function points)

• Early design model• Based on function points

• Post-architecture model• Based on function points or KDSI

COCOMO II (contd)

COCOMO Effort model is effort = a (size)b

• Intermediate COCOMO• Three values for (a, b)

• COCOMO II• b varies depending on values of certain parameters

COCOMO II supports reuse COCOMO II has 17 multiplicative cost drivers (was 15)

• Seven are new

It is too soon for results regarding • Accuracy of COCOMO II

• Extent of improvement (if any) over Intermediate COCOMO

Tracking Duration and Cost Estimates

Whatever estimation method used, careful tracking is vital

Components of a software project management plan (SPMP)• Work to be done

• Resources with which to do it

• Money to pay for it

Resources needed for software development:• People

• Hardware

• Support software

Use of Resources Varies with Time

Rayleigh curves accurately depict resource consumption

Entire software development plan must be a function of time

Work Categories

Project function• Work carried on throughout project• Examples:

project management, quality control

Activity• Work that relates to a specific phase• Major unit of work • With precise beginning and ending dates• That consumes resources, and• Results in work products like budget, design, schedules, source code, or users’

manual

Task• An activity comprises a set of tasks (the smallest unit of work subject to

management accountability)

Completion of Work Products

Milestone: Date on which the work product is to be completed It must first pass reviews performed by

• Fellow team members

• Management

• Client

Once the work product has been reviewed and agreed upon, it becomes a baseline

Work Package

Work product, plus • Staffing requirements• Duration• Resources• Name of responsible individual• Acceptance criteria for work product

Money• Vital component of plan • Detailed budget must be worked out as a function of time • Money must be allocated, as function of time, to

• Project functions• Activities

How to Plan Software Development

State problem clearly (Specification Phase) Determine viable solution strategies (Specification

Phase) Should client be advised to computerize?

• Cost–benefit analysis

If so, which viable solution strategy? Decide by• Minimizing total cost to client, or• Maximizing total return on investments, or• Other methods

Develop SPMP for product as whole

Software Project Management Plan (SPMP)

Determine work units Estimate resources required Draw up budget Come up with detailed timetable Framework for SPMP

• IEEE Standard 1058.1• Standard widely agreed upon• Designed for use with all types of software product• Advantages of standardization

IEEE SPMP

Planning of Testing

SPMP must explicitly state what testing is to be done• Traceability

• All black box test cases must be drawn up as soon as possible after specifications are complete

Testing during the Planning Phase• Must check SPMP as a whole

• Pay particular attention to duration and cost estimates

Planning of Object-Oriented Projects

Object-oriented product consists of largely independent pieces Planning is somewhat easier Whole is more than the sum of its parts Use COCOMO II ( or modify intermediate COCOMO

estimators) However, reuse destroys everything

• Reuse of existing components during development• Production of components for future reuse

These work in opposite directions Newer data: savings outweigh costs

Training Requirements

“We don’t need to worry about training until the product is finished, and then we can train the user ” • Training is generally needed by the members of the development

group, starting with training in software planning • New software development method necessitates training for every

member of the group• Introduction of hardware or software tools of any sort necessitates

training• Programmers may need training in the operating system,

implementation language • Documentation preparation training may be needed• Computer operators require training

Documentation Standards

How much documentation is generated by a product?• IBM internal commercial product (50 KDSI)

• 28 pages of documentation per KDSI

• Commercial software product of same size• 66 pages per KDSI

• IMS/360 Version 2.3 (about 166 KDSI)• 157 pages of documentation per KDSI

• (TRW) For every 100 hours spent on coding activities, 150–200 hours were spent on documentation-related activities

Types of Documentation

Planning Control Financial Technical Source code Comments within source code

Documentation Standards

Reduce misunderstandings between team members Aid SQA Only new employees have to learn standards Standards assist maintenance programmers Standardization is important for user manuals

CASE Tools for the Planning Phase

Word processor, spreadsheet Automated intermediate COCOMO/COCOMO II Management tools assist with planning and

monitoring• MacProject, Microsoft Project

Software Project Management - the Big Picture

For a broader coverage of the other aspects of software project management refer to “Software Project Management” (Version 2 Handout); the contents of which are as follows:• Project Planning and Management (Slide 3-38)• Managing People (Slide 39-89)• Software Cost Estimation (Slide 90-147)• Quality Management (Slide 148-201)• Process Improvement (Slide 202-235)• Legacy Systems (Slide 236-273)• Software Change (Slide 274-312)• Software Re-engineering (Slide 313-348)• Configuration Management (Slide 349-400)

Exercise 5: An as exercise, go though the presentation and take note of the key points.