Software Project

Management

1
Contents

 Introduction to Project Planning

 Software Cost Estimation
 Cost Estimation Models
 Software Size Metrics
 Empirical Estimation
 Heuristic Estimation
 COCOMO
 Staffing Level Estimation
 Effect of Schedule Compression on Cost
 Summary

2
Introduction
 Many software projects fail:
 due to faulty project
management practices:
 It is important to learn different
aspects of software project
management.

3
Cont..
 Goal of software project
management:
 enable a group of engineers to work
efficiently towards successful
completion of a software project.

4
Cont..
 The right mix of planning, monitoring, and
controlling can make the difference in
completing a project …
 on time, on budget, and with high quality
results.
 These guidelines will help you plan the
work and work the plan.

5
 Project Management –
The Problem

 A survey of companies indicated that only 14%

of failures could be attributed to a company’s
inability to cope with technology. The other
86% were due to management problems:

 improperly defined objectives (17 percent)

 unfamiliar scope (17 percent)
 lack of effective communication (20 percent)
 poor project management skills (32 percent)

6
Project Management -
Definitions
“Project management consists of managing the production
of a product within given time and funding limits. Since
this requires human resources, project management
involves not only technical and organizational skills, but
also the art of managing people.”

“Project management involves the planning, monitoring,

and control of the people, process and events that occur
as software evolves from preliminary concept to
operational implementation.”

7
Project Management –
Overview
 What is it?
 Planning, monitoring and control of
 People
 Process
 Events
 Who does it?
 Everyone, to some extent, e.g.:
 A software engineer manages his/her daily
activities: planning, monitoring and controlling
technical tasks
 A project manager plans, monitors and controls
the activities of a team of software engineers.
 A senior manager coordinates the interactions
between business and software professionals

8
 Cont…
 Why is it important?
 As we saw earlier, many projects fail
 Software development is a complex task
 particularly if it involves many people and survives a long time
“ there are no technical failures; only management failures”
 What are the steps?
 Understand the four P’s:
 People – must be organized to work effectively.
 Product – must have effective communication with the customer to specify
scope and requirements.
 Process – must be appropriate for people and product .
 Project – must estimate effort and time needed, define work products,
establish quality checkpoints, establish methods to monitor and control
work defined by plan.
 Main focus on people and project

9
 The People
 A 1988 IEEE study asked the engineering of major
technology companies what was most important
to the success of a project. Some quotes:
“I guess if you had to pick one thing out that is most
important in our environment, it’s not the tools we use,
it’s the people.”
“The only rule I have in management is to ensure that I
have good people – real good people – and that I
produce good people – and that I provide an
environment in which good people can produce.”
 Managers say that people are primary, but
unfortunately they often do not act with this
principle.

10
The People
 People working on software projects play various roles,
which can be organized into five basic types:
 Senior managers
 Define business issues that often have great impact on
project
 Project managers
 Plan, motivate, organize and control the people who do
technical aspects of work
 Practitioners
 Deliver necessary technical skills to engineer
 Customers & Stakeholders
 Specify requirements and scope for software
 End-Users
 Interact with software product once it is released
 To be effective, the Team Leader must organize the
project team so as to maximize each person’s skills and
abilities.

11
The Team Leader
 Project management is a people-oriented
activity
 model of leadership
 Motivation
 Ability to encourage technical people to work to the best
of their abilities
 Organization
 Ability to adapt existing processes, or develop new ones,
to enable the concept to be turned into a product
 Ideas/Innovation
 Ability to encourage people to create, and to feel
creative, within the bounds of the particular product

12
The Team Leader
 Another view of what makes a good team leader:
 Problem solving
 Decide which technical and organizational issues are most
important
 Create a systematic solution to the problem – or motivate
others to do so
 Apply lessons from past projects to new ones
 Remain flexible enough to change direction if initial proposed
solution doesn’t work
 Managerial Identity
 Confidence to take charge of project when necessary, but
also to let good technical people use their initiative
 Achievement
 Reward initiative and achievement
 Influence and Team building
 Be able to “read” people – understand both verbal and non-
verbal signals from team members, and react to their needs

13
Coordination and
Communication
 Software projects fail for many reasons. For modern
software, issues of scale and uncertainty are usually
unavoidable
 Scale: many projects are large, leading to complexity,
confusion and major difficulties in coordinating people
 Uncertainty: scope and requirements change is common, often
resulting in continuous addition to the team load

 Interoperability: new software must communicate with existing

systems, and conform to predefined standards and constraints

14
Coordination and
Communication
 To deal with these issues, methods must be established
to promote both formal and informal communication
between team members, and to coordinate their work
 Project Coordination Techniques
 Formal, impersonal approaches
 Software engineering documents, technical memos,
project highlights, schedules and PM tools, change
requests & documentation, error tracking reports,
etc.
 Formal, interpersonal procedures
 Focus on quality assurance activities applied to the
work products: status review meetings, design and
code inspections.

15
 Coordination and
Communication

 Project Coordination Techniques cont.

 Informal, interpersonal procedures
 Group meetings for communication of information,
problem solving, and getting requirements and
development staff together
 Electronic communication
 Email, bulletin boards, video conferencing
 Interpersonal network
 Informal discussions with team members and outside
experts

16
The Project
 Ten signs that indicate that a project is in trouble:
 Technical people don’t understand customer’s needs
 Product scope is poorly defined
 Change management is poor
 Change in technology chosen for solution
 Business needs change or are not well defined
 Deadlines are not realistic
 Users are opposing to the proposed solution
 Sponsorship is lost, or was never actually obtained
 Project team lacks people with the right skills
 Managers and team members refuse to accept best-practice,
and lessons learned on previous projects

17
The Project
 How does a project manager avoid these
problems?
 Start on the right foot
 Work very hard to understand the problem
 Set realistic objectives and expectations for team
 Give team members autonomy, authority and
appropriate technology
 Maintain momentum
 Provide incentives
 Ensure that team highlights quality in every task

18
The Project
 How does a project management avoid these
problems? cont.
 Track progress
 Work products are produced and approved by formal technical
review
 Project and process metrics can be gathered and compared with
historical data
 Make smart decisions
• Avoid tradition interfaces if a standard is available
• Identify and avoid understandable risks
• Allocate more time to think about risky or complex tasks
 Conduct a post-mortem analysis
 Establish a mechanism for extracting lessons-learned from
completed projects: planned vs. actual schedule, metrics, feedback
from team members and customers
 Record findings in written form

19
Meetings
 Project Managers are required to run meetings.
 Some good practices:
1. Distribute start time, end time and estimated time
for agenda items (before meeting)
2. Prepare items (before meeting)
3. Start on time
4. Have someone record action items
5. Get agreement on agenda and timing
6. Watch timing throughout – end on time
7. Keep discussions on topic
8. Circulate minutes including action items and
discussion summary (after meeting)

20
Formal Technical Reviews
(FTR)
 An FTR is a quality assurance activity
performed by software engineers (and
others).
 Objectives
 Discover errors in function, logic or
implementation for any representation of software
 Verify that software being reviewed meets its
requirements
 Achieve uniform software development
 Make projects more manageable
 Train junior software engineers

21
FTRs: Preparation
 Preparation for an FTR
 Person who developed the work product – the producer
– informs the team leader that it is ready for review
 Team leader designates a review leader, who evaluates
the product’s and distributes copies of product material
to two or three other reviewers
 Each reviewer spends one or two hours reviewing the
product and making notes on it
 At the same time, the review leader also reviews the
product, establishes an agenda for the review meeting
and schedules a meeting time

22
FTRs: Reporting
Review Reporting and Recording
 After the review meeting, the recorder produces a review
summary report, answering the questions:
 What was reviewed?
 Who reviewed it?
 What were the findings and conclusions?
 Review summary report is typically a single page, possibly
with attachments
 A review issues list should also be created and attached to
the summary report. It notes:
 Problem areas within the product
 An action item checklist which guides the producer as corrections
are made
 The review leader should have follow-up the producer to
ensure that the issues have been addressed

23
FTRs: Guidelines
 Review the product, not the producer
 Set an agenda and maintain it
 Identify problem areas but don’t attempt to solve every
problem
 Take written notes
 Limit the number of participants
 Insist on advance preparation
 Develop a checklist for each work product
 Allocate resources and time
 Conduct meaningful training
 Review earlier reviews

24
Responsibility of project
managers
 Project proposal writing,
 Project cost estimation,
 Scheduling,
 Project staffing,
 Project monitoring and control,
 Software configuration management,
 Risk management,
 Managerial report writing and presentations, etc.

25
Cont…
 A project manager’s activities
are varied.
 can be broadly classified into:
 project planning,
 project monitoring and control
activities.
26
Project Planning

 Once a project is found to be feasible,

 project managers undertake project
planning.
 It involves estimating several
characteristics of the project and
planning the project activities based on
the estimate made

27
project monitoring and
control activities
 It is undertaken once the development
activities start
 The main aim is to ensure that the
development proceeds as per plan

28
Project Planning Activities
 Estimation:
 Effort, cost, resource, and project duration
 Project scheduling:
 The schedules for manpower and other resources have
to be developed
 Staff organization:
 staffing plans
 Risk handling:
 identification, analysis, and abatement procedures
 Miscellaneous plans:
 quality assurance plan, configuration management
plan, etc. have to be done

29
Project planning

 Requires highest care and attention --->

commitments to unrealistic time result in:
 irritating delays.
 customer dissatisfaction
 bad affect on team morale
 poor quality work
 project failure.

30
 Sliding Window Planning
 Involves project planning over several
stages:
 Especially for large projects, it becomes very difficult to make accurate
plans.
 A part of this difficulty is due to the fact that the project parameters, scope
of project, project staff, etc. may change during the span of the project.
 To make accurate plans project managers undertake project planning in
stages
 protects managers from making big commitments too early.
 More information becomes available as project progresses.
 Facilitates accurate planning

31
SPMP Document

 After planning is complete:

 Document the plans:
 in a Software Project
Management Plan(SPMP)
document.

32
Organization of SPMP Document

 Introduction (Objectives,Major Functions,Performance Issues,Management and Technical

Constraints)

 Project Estimates (Historical Data used,Estimation Techniques used,Effort, Cost, and Project Duration
Estimates)

 Project Resources Plan (People,Hardware and Software,Special Resources)

 Schedules (Task Network, Gantt Chart Representation,PERT Chart Representation)
 Risk Management Plan (Risk Analysis,Risk Identification,Risk Estimation, Abatement
Procedures)

 Project Tracking and Control Plan

 Miscellaneous Plans(Process Tailoring,Quality Assurance)

33
Software Cost Estimation

 Determine size of the product.

 From the size estimate,
 determine the effort needed.
 From the effort estimate,
 determine project duration, and cost.

34
Software Cost Estimation

Effort Cost
Estimation Estimation

Size Staffing
Estimation Estimation

Duration
Estimation Scheduling

35
Software Cost Estimation

 Three main approaches to

estimation:
 Empirical
 Heuristic
 Analytical

36
Software Cost Estimation
Techniques

 Empirical techniques:
 an educated guess based on past experience.
 Heuristic techniques:
 assume that the characteristics to be
estimated can be expressed in terms of
some mathematical expression.
 Analytical techniques:
 derive the required results starting from
certain simple assumptions.

37
Software Size Metrics

 LOC (Lines of Code):

 Simplest and most widely used
metric.
 Comments and blank lines should
not be counted.

38
Disadvantages of Using LOC
 Size can vary with coding style.
 Focuses on coding activity alone, but a good problem size
measures should consider the total effort needed to specify,
design, test etc.
 Correlates poorly with quality and efficiency of code, larger
code does not necessarily imply better quality or higher
efficiency
 Some programmers produce lengthy and complicated code
as they do not make effective use of the available
instruction set.
 Code reuse, etc.

39
Disadvantages of Using LOC
(cont...)

 Measures lexical complexity only.

 does not address the issues of structural or logical
complexity.
 Between two programs with equal LOC count, a
program having complex logic would require much
more effort to develop than a program with very
simple logic
 Difficult to estimate LOC in the final product from
problem description specification.
 The LOC count can only be accurately computed only
after the code has been fully developed
 So not useful for project planning

40
Function Point Metric

 Overcomes some of the shortcomings of

the LOC metric
 Size of software product can be estimated
from problem specification
 Proposed by Albrecht in early 80's:
 FP=4 #inputs + 5 #Outputs + 4
#inquiries + 10 #files + 10 #interfaces
 Input:
 A set of related inputs is counted as one input.

41
Function Point Metric
 Output:
 A set of related outputs is counted as one output.
 Inquiries:
 Each user query type is counted.
 Inquiries are the user commands which require
specific action by the system
 Files:
 Files are logically related data and thus can be data
structures or physical files.
 Interface:
 Data transfer to other systems.

42
Function Point Metric (CONT.)

 Suffers from a major drawback:

 the size of a function is considered to be
independent of its complexity.
 Extend function point metric:
 Feature Point metric:
 considers an extra parameter:
 Algorithm Complexity.

43
Function Point Metric (CONT.)

 Proponents claim:
 FP is language independent.
 Size can be easily derived from problem
description
 Opponents claim:
 it is subjective --- Different people can come
up with different estimates for the same
problem.
44
Empirical Size Estimation
Techniques
 Expert Judgement:
 an educated guess based on past
experience.
 Suffers from individual bias.
 Delphi Estimation:
 overcomes some of the problems of
expert judgement.

45
Expert judgement

 Experts divide a software product into

component units:
 e.g. GUI, database module, data
communication module, billing module,
etc.
 Add up the guesses for each of the
components.

46
Delphi Estimation:

 Team of Experts and a coordinator.

 Experts carry out estimation
independently:
 mention the underlying principle behind
their estimation.
 coordinator notes down any
extraordinary underlying principle:
 circulates among experts.

47
Delphi Estimation:

 Experts re-estimate.
 Experts never meet each other
 to discuss their viewpoints.

48
Heuristic Estimation Techniques
 Heuristic techniques assume that the relationships among the
different project parameters can be modelled using suitable
mathematical expression.
 Once the basic (independent parameters) are known , the
other (dependent) parameters can be easily determined
 Single Variable Model:
 Parameter to be Estimated=C1(Estimated Characteristic)d1
 Multivariable Model:
 Assumes that the parameter to be estimated depends on
more than one characteristic.
 Parameter to be Estimated=C1(Estimated
Characteristic)d1+ C2(Estimated Characteristic)d2+…
 Usually more accurate than single variable models.

49
COCOMO Model
 COCOMO (COnstructive COst MOdel) proposed
by Boehm.
 Divides software product developments into 3
categories:
 Organic
 Semidetached
 Embedded
 In order to classify a product into the identified
categories,
 Boehm considered not only the characteristics of the
product
 but also those of the development team and
development environment
50
COCOMO Product classes

 Roughly correspond to:

 application, utility and system programs
respectively.
 Data processing and scientific programs are
considered to be application programs.
 Compilers, linkers, editors, etc., are utility
programs.
 Operating systems and real-time system
programs, etc. are system programs.

51
Cont…
 Brooks, 1975 states that utility programs are
roughly three times as difficult to write a
application programs,
 And system programs are roughly three times as
difficult as utility programs,
 Thus according to Brooks, the relative levels of
product development complexity for three
categories (application, utility and system
programs) of product are 1:3:9.

52
Elaboration of Product
classes
 Organic:
 Relatively small groups
 working to develop well-understood applications.
 Semidetached:
 Project team consists of a mixture of
experienced and inexperienced staff.
 Embedded:
 The software is strongly coupled to complex
hardware, or real-time systems.

53
COCOMO Model (CONT.)

 For each of the three product categories:

 From size estimation (in KLOC), Boehm provides
equations to predict:
 project duration in months
 effort in programmer-months
 Boehm obtained these equations:
 examined historical data collected from a large
number of actual projects.

54
COCOMO Model (CONT.)

 According to Boehm, Software

cost estimation is done through
three stages:
 Basic COCOMO,
 Intermediate COCOMO,
 Complete COCOMO.

55
Basic COCOMO Model (CONT.)

 Gives only an approximate estimation of project

parameters & basic COCOMO model is given by
following expression:
 Effort = a1×(KLOC)a2 PM
 Tdev = b1 ×(Effort)b2 Months
 KLOC is the estimated kilo lines of source code,
 a1,a2,b1,b2 are constants for different
categories of software products,
 Tdev is the estimated time to develop the
software in months,
 Effort estimation is obtained in terms of person
months (PMs).

56
Development Effort
Estimation
 Organic :
 Effort = 2.4 (KLOC)1.05 PM
 Semi-detached:
 Effort = 3.0(KLOC)1.12 PM
 Embedded:
 Effort = 3.6 (KLOC)1.20PM
57
Development Time
Estimation
 Organic:
 Tdev = 2.5 (Effort)0.38 Months
 Semi-detached:
 Tdev = 2.5 (Effort)0.35 Months
 Embedded:
 Tdev = 2.5 (Effort)0.32 Months
58
Basic COCOMO Model (CONT.)

d
he
 Effort is Effort
m
id
et
a c

e
somewhat
S
ded
d
super-linear Em
be
ga
n ic

(slope of curve Or

≥ 1) in problem
size. Size

The effort required to develop a product increases rapidly

with project size 59
Basic COCOMO Model (CONT.)

 Development time
 sublinear function of
product size. Dev. Time
 When product size ed hed
d d ta c
increases two times, be ide
18 Months Em Sem
 development time does
not double but rises 14 Months
ic
gan
moderately. Or
 Time taken:
30K 60K
 almost same for all the Size
three product categories.

60
Basic COCOMO Model (CONT.)

 Development time does not

increase linearly with product size:
 For larger products more parallel
activities can be identified:
 can be carried out simultaneously by a
number of engineers.

61
Basic COCOMO Model (CONT.)

 Development time is roughly the same for

all the three categories of products:
 For example, a 60 KLOC program can be
developed in approximately 18 months
 regardless of whether it is of organic, semi-
detached, or embedded type.

62
Example
 The size of an organic software product has been estimated to
be 32,000 lines of source code. Assume that average salary of
software developers is Rs. 15,000 per month, determine the
effort required to develop the software product, the nominal
development time, and the cost to develop the product.

 Effort = 2.4*(32)1.05 = 91 PM
 Nominal development time = 2.5*(91)0.38 = 14 months
 Cost required to develop the product= 91 × 15,000= Rs.
1,465,000

63
Intermediate COCOMO

 Basic COCOMO model assumes

 effort and development time depend on
product size alone.
 However, several parameters affect effort
and development time:
 Reliability requirements
 Availability of CASE tools and modern facilities to
the developers
 Size of data to be handled

64
Intermediate COCOMO

 For accurate estimation,

 the effect of all relevant parameters must be
considered:
 Intermediate COCOMO model recognizes this
fact:
 refines the initial estimate obtained by the basic
COCOMO by using a set of 15 cost drivers
(multipliers) based on various attributes of software
development.
 A "cost driver" is the unit of an activity that causes the
change of an activity cost

65
Intermediate COCOMO
(CONT.)

 For example, If modern

programming practices are used,
 initial estimates are scaled
downwards.
 If there are stringent reliability
requirements on the product :
 initial estimate is scaled upwards.
66
Intermediate COCOMO
(CONT.)

 Rate different parameters on a

scale of one to three:
 Depending on these ratings,
 multiply cost driver values with
the estimate obtained using the
basic COCOMO.

67
Intermediate COCOMO
(CONT.)

 Cost driver classes:

 Product: Inherent complexity of the product,
reliability requirements of the product, etc.
 Computer: Execution time, storage
requirements, etc.
 Personnel: Experience of personnel, etc.
 Development Environment: Sophistication of
the tools used for software development.

68
Shortcoming of basic and
intermediate COCOMO models

 Both models:
 consider a software product as a single
homogeneous entity:
 However, most large systems are made up of
several smaller sub-systems.
 Some sub-systems may be considered as organic
type, some may be considered embedded, etc.
 for some the reliability requirements may be high,
and so on.

69
Complete COCOMO

 Cost of each sub-system is estimated

separately.
 Costs of the sub-systems are added to
obtain total cost.
 Reduces the margin of error in the
final estimate.

70
Complete COCOMO
Example
 A Management Information System (MIS) for an
organization having offices at several places
across the country:
 Database part (semi-detached)
 Graphical User Interface (GUI) part (organic)
 Communication part (embedded)
 Costs of the components are estimated
separately:
 summed up to give the overall cost of the system.

71
Halstead's Software
Science
 An analytical technique to
estimate:
 size,
 development effort,
 development time.

72
Halstead's Software
Science
 Halstead used a few primitive program
parameters
 number of operators and operands
 Derived expressions for:
 over all program length,
 potential minimum volume
 actual volume,
 language level,
 effort, and
 development time.
73
Staffing Level Estimation

 Number of employees required during

any development project:
 not constant.
 Norden in 1958 analyzed many R&D
projects, and observed:
 Rayleigh curve represents the number of
full-time employees required at any
time.
74
Rayleigh Curve

 Rayleigh curve is Rayleigh Curve

specified by two Effort
parameters: per
unit
 td the time at time
which the curve
reaches its
maximum td
 K the total area Time
under the curve.
 L=f(K, td)
75
Putnam’s Work:

 In 1976, Putnam studied the problem of

staffing of software projects:
 observed that the level of effort required in
software development efforts has a similar
envelope.
 found that the Rayleigh-Norden curve
 relates the number of delivered lines of code to
effort and development time.

76
Putnam’s Work (CONT.) :
 Putnam analyzed a large number of
army projects, and derived the
expression:
L=CkK1/3td4/3
 K is the effort expended (in PM) in the
product development and L is the size in
KLOC.
 td is the time to develop the software.
 Ck is the state of technology constant
 reflects factors that affect programmer
productivity.
77
Putnam’s Work (CONT.) :

 Ck=2 for poor development environment

 no methodology, poor documentation, and
review, etc.
 Ck=8 for good software development
environment
 software engineering principles used
 Ck=11 for an excellent environment

78
Rayleigh Curve

 Very small number of engineers are

needed at the beginning of a project
 carry out planning and specification.
 As the project progresses:
 more detailed work is required,
 number of engineers slowly increases
and reaches a peak.

79
Rayleigh Curve

 Putnam observed that:

 the time at which the Rayleigh curve
reaches its maximum value
 corresponds to system testing and product
release.
 After system testing,
 the number of project staff falls till product
installation and delivery.
80
Rayleigh Curve

 From the Rayleigh curve observe

that:
 approximately 40% of the area
under the Rayleigh curve is to the
left of td
 and 60% to the right.

81
Effect of Schedule Change
on Cost
 Using the Putnam's expression for L,
K=L3/Ck3td4
Or, K=C1/td4
 For the same product size, C1=L3/Ck3 is a
constant.
 Or, K1/K2 = td24/td14

Effort increases in proportion to the fourth power of the degree of

compression

82
Effect of Schedule Change on
Cost (CONT.)

 Observe:
 a relatively small compression in delivery schedule/ schedule of
project
 can result in substantial penalty on human effort.
 Example: if the estimated develop time is 1 year, then in order to
develop the product in 6 months, the total effort required to
develop the product increases 16 times.

 Also, observe:
 benefits can be gained by using fewer people over a somewhat
longer time span.

83
Example

 If the estimated development time is 1

year, then in order to develop the
product in 6 months,
 the total effort and hence the cost
increases 16 times.
 In other words,
 the relationship between effort and the
chronological delivery time is highly nonlinear.

84
Effect of Schedule Change on
Cost (CONT.)

 Putnam model indicates extreme penalty

for schedule compression
 and extreme reward for expanding the
schedule.
 Putnam estimation model works
reasonably well for very large systems,
 but seriously misjudges the effort for medium
and small systems.

85
Effect of Schedule Change on
Cost (CONT.)

 Boehm observed:
 “There is a limit beyond which the
schedule of a software project cannot
be reduced by buying any more
personnel or equipment.”

86
Effect of Schedule Change
on Cost (CONT.)

 If a project manager accepts a customer

demand to compress the development
time by more than 25%
 very unlikely to succeed.
 The main reason being that every project has only
a limited amount activities which can be carried out
in parallel, and
 sequential activities cannot be speeded up by hiring
any number of additional engineers.
 many engineers have to sit idle.

87
Jensen Model
 Jensen model is very similar to
Putnam model.
 attempts to soften the effect of
schedule compression on effort
 makes it applicable to smaller and
medium sized projects.

88
Jensen Model
 Jensen proposed the equation:
 L=CtetdK1/2
 K1/K2 = td22/td12
 Where,
 Cte is the effective technology constant,
 td is the time to develop the software, and
 K is the effort needed to develop the software.

 When the project duration is compressed, Jensen models the

increases in effort (and cost) requirement to be proportional to
the squire of the degree of compression

89
Organization Structure

 Functional Organization:
 Engineers are organized into functional
groups, e.g.
 specification, design, coding, testing,
maintenance, etc.
 Engineers from functional groups get
assigned to different projects

90
Advantages of Functional
Organization

 Specialization
 Ease of staffing
 Good documentation is produced
 different phases are carried out by
different teams of engineers.
 Helps identify errors earlier.

91
Project Organization

 Engineers get assigned to a project

for the entire duration of the project
 Same set of engineers carry out all the
phases
 Advantages:
 Engineers save time on learning details
of every project.
 Leads to job rotation

92
Team Structure

 Problems of different complexities

and sizes require different team
structures:
 Chief-programmer team
 Democratic team (suitable for less understood
problem)

 Mixed organization
93
Chief Programmer Team

 A senior engineer provides

technical leadership:
 partitions the task among the team
members.
 verifies and integrates the products
developed by the members.

94
Chief Programmer Team

 Works well when

 the task is well understood
 also within the intellectual grasp of a single
individual,

 The chief programmer team leads to lower

team morale, personal development etc., since
the team member work under the constant
supervision of the chief programmer

95
Chief Programmer Team

 Chief programmer team is subject to

single point failure:
 too much responsibility and authority is
assigned to the chief programmer.

96
Democratic Teams
 Suitable for:
 small projects requiring less than five or six
engineers
 research-oriented projects
 A manager provides administrative
leadership:
 at different times different members of the
group provide technical leadership.

97
Democratic Teams

 Democratic organization provides

 higher morale and job satisfaction to the
engineers

 Suitable for less understood problems,

 a group of engineers can invent better
solutions than a single individual.

98
Democratic Teams

 Disadvantage:
 team members may waste a
lot time arguing about trivial
points:
 absence of any authority in the
team.

99
Mixed Control Team
Organization
 Draws upon ideas from both:
 democratic organization and
 chief-programmer team organization.
 Communication is limited
 to a small group that is most likely to benefit
from it.
 Suitable for large organizations.

100
Team Organization

Democratic Team
Chief Programmer team

101
Mixed team organization

102
Summary
 We discussed the broad
responsibilities of the project
manager:
 Project planning
 Project Monitoring and Control

103
Summary
 To estimate software cost:
 Determine size of the product.
 Using size estimate,
 determine effort needed.
 From the effort estimate,
 determine project duration, and cost.

104
Summary (CONT.)
 Cost estimation techniques:
 Empirical Techniques
 Heuristic Techniques
 Analytical Techniques
 Empirical techniques:
 based on systematic guesses by experts.
 Expert Judgement
 Delphi Estimation

105
Summary (CONT.)
 Heuristic techniques:
 assume that characteristics of a software
product can be modeled by a mathematical
expression.
 COCOMO
 Analytical techniques:
 derive the estimates starting with some basic
assumptions:
 Halstead's Software Science

106
Summary (CONT.)
 The staffing level during the life cycle of a
software product development:
 follows Rayleigh curve
 maximum number of engineers required
during testing.

107
Summary (CONT.)

 Relationship between schedule change and

effort:
 highly nonlinear.
 Software organizations are usually
organized in:
 functional format
 project format

108
Summary (CONT.)

 Project teams can be organized in

following ways:
 Chief programmer: suitable for routine work.
 Democratic: Small teams doing R&D type work
 Mixed: Large projects

109