MOE 225-Software Project Management.ppt
Transcript of MOE 225-Software Project Management.ppt
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
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 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
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
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
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)
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) 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
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
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.