DMIoT, School of Computing

Software Engineering Academic Program

Fundamentals of Software Engineering

By
Yayehudar T.
 Chapter Five
Software Project Management
 Software Project Management
❖A project is well-defined task, which is a collection of several
operations done in order to achieve a goal (e.g. software development
and delivery).
❖A Project can be characterized as:
✓Project comes with a start and end time.
✓Project is not a routine activity or day-to-day operation.
✓Project needs adequate resources in terms of time, manpower,
finance, material

3
 Cont’d...
▪ Software project management is an essential part of software
engineering.
▪ Projects need to be managed because professional software
engineering is always subject to organizational budget and schedule
constraints.
▪ The success criteria for project management obviously vary from
project to project but, for most projects, important goals are:
✓Deliver the software to the customer at the agreed time.
✓Keep overall costs within budget.
✓Deliver software that meets the customer’s expectations.
✓Maintain a happy and well-functioning development team.

4
 Cont’d...
Life Cycle and Project Management
▪ When a life cycle model is followed project management is
easier.
• For example: The project manager can at any time fairly
accurately tell,
✓ at which stage (e.g., design, code, test, etc.) of the
project is.
✓ How much time would it take to complete

5
 Cont’d...
Project Management Without a Life Cycle Model
▪ It becomes very difficult to track the progress of the
project:
• The project manager would have to depend on the
guesses of the team members.
▪ This usually leads to a problem:
• known as the 99% complete syndrome.

6
 Software Project
▪ It is the complete process of software development from requirement
gathering to testing and maintenance, carried out according to the
execution methodologies, in a specified period of time to achieve
intended software product.
▪ A set of activities undertaken within a defined time period in order to
meet a specific set of goals/objectives within a budget.
❑ Projects are different from standard business operational activities as
they:
✓Are unique in nature: they do not involve repetitive processes.
• Every project undertaken is different from the last, whereas
operational activities often involve undertaking repetitive (identical)
processes
✓ Have a defined timescale: projects have a clearly specified start and
end date within which the deliverables must be produced to meet a
specified customer requirement
7
 Cont’d...
✓Have an approved budget: projects are allocated a level of financial
expenditure within which the deliverables must be produced to meet a
specified customer requirement
✓Have limited resources: at the start of a project, an agreed amount of
labor, equipment and materials is allocated to the project
✓Involve an element of risk: projects entail a level of uncertainty and
therefore carry business risk.
✓Achieve beneficial change: the purpose of a project, typically, is to
improve an organization through the implementation of business
change.

8
 Cont’d...
❖A project generally exhibits most of the following conditions:
✓ It is finite
✓ Usually complex
✓ Non-repetitive
✓ Requires resources

9
 Cont’d...
❖The image below shows triple constraints for software projects.
❖It is an essential part of software organization to deliver quality
product, keeping the cost within client’s budget constrain and
deliver the project as per scheduled.

10
 Project Stakeholders
❑Project stakeholders are individuals and organizations that are
actively involved in the project.
▪ Key Stakeholders include:
✓ Project manager: the individual responsible for managing the
project.
✓ Customer: the individual or organization that will use the
project's product or service.
✓ Project team members: the group that is performing the work of
the project.
✓ Sponsor: the individual or group that provides the financial
resources for the project.

11
 Project Planning
▪ Carried out before development starts.
▪ The project plan guides execution
▪ Key outputs include:
✓ A work breakdown structure (WBS)
✓ A project schedule, in the form of a Gantt chart with all
dependencies and resources entered
✓ A list of prioritized risks

12
 Cont’d...
❑Important activities:
✓ Estimation: Effort, cost, resource, and project duration
✓ Scheduling
✓ Staffing
✓ Risk management: identification, analysis, and abatement
procedures
✓ Miscellaneous plans: quality assurance plan, configuration
management plan, etc.

13
 Types of plan
▪ Software development plan: the central plan, which describes how
the system will be developed.
✓ Specifies the order of work to be carried out, resources,
responsibilities, and so on.
▪ Quality assurance plan: specifies the quality procedures & standards
to be used.
▪ Validation plan: defines how a client will validate the system that has
been developed.
▪ Configuration management plan: defines how the system will be
configured and installed.
▪ Maintenance plan: defines how the system will be maintained.
▪ Staff development plan: describes how the skills of the participants
will be developed.
14
 Cont’d…
Development plan should contain:
1. Introduction: brief introduction to project
2. Project organization: intro to organizations, people, and their roles
3. Risk Analysis: what are the key risks to the project?
4. Hardware and software resources: what Hardware and Software
resources will be required for the project and when
5. Work breakdown: the project divided into activities, milestones,
deliverables, dependencies between tasks etc.
6. Project schedule: actual time required - allocation of dates
7. Reporting and progress measurement: mechanisms to monitor
progress.

15
 Organization of SPMP Document
▪ Introduction:
• (Objectives,Major Functions,Performance Issues,Management and
Technical Constraints)
▪ Project Estimates
• (Historical Data,Estimation Techniques,Effort, Cost, and Project
Duration Estimates)
▪ Project Resources Plan
• (People,Hardware and Software,Special Resources)
▪ Schedules
• (Work Breakdown Structure,Task Network, Gantt Chart
Representation,PERT Chart Representation)
16
 Cont’d...
▪ Risk Management Plan
• (Risk Analysis,Risk Identification,Risk Estimation,Abatement
Procedures)
▪ Project Tracking and Control Plan
▪ Miscellaneous Plans
• (Quality Assurance)

17
In What Ways Management of Software Projects Differ
from Management of Engineering Systems?

▪ Intangible:
✓ Software is invisible till it is ready and runs
▪ Large Change Impact:
✓ A small change request can have terrible impact
✓ Change is the rule rather than exception
▪ Intellectual work
18
Why Software Project Management is Hard?
▪ Management of intellectual and complex work
▪ It is hard to manage anything that you cannot see
▪ Changing customer requirements
▪ Manpower turnover

19
 Common Mistakes why Projects FAIL
▪ Project managers begin without knowing what the project is.
▪ Project managers do not have a plan.
▪ Project managers do not break the project down to manageable
pieces.

20
 What is management?
❑Management involves the following activities:
✓Planning: deciding what is to be done, Estimate and schedule
resources
✓Organizing: making arrangements, Who does what
✓Staffing: selecting the right people for the job, Recruiting and
motivating personnel
✓Directing: giving instructions, Ensure team acts as a whole
✓Monitoring: checking on progress, revising plans
✓Controlling: taking action to remedy hold-ups
✓Innovating: coming up with solutions when problems emerge
✓Representing: liaising with clients, users, developers and other
stakeholders
21
 Responsibility of project managers
❖Project proposal writing,

❖Project cost estimation,

❖ Scheduling,

❖Project staffing,

❖ Project monitoring and control,

❖Software configuration management,

❖Risk management,

❖Managerial
22 report writing and presentations, etc.
 Setting objectives
▪ Answering the question ‘What do we have to do to have a
success?
❑Objectives should be SMART
✓S -specific, that is, concrete and well-defined
✓M -measurable, that is, satisfaction of the objective can be
objectively judged
✓A -achievable, that is, it is within the power of the individual or
group concerned to meet the target
✓R -relevant, the objective must be relevant to the true purpose of the
project
✓T -time constrained: there is defined point in time by which the
objective should be achieved
23
 SOFTWARE SCOPE
▪ Software Scope is defined in collaboration with the User
Management by asking the following Questions on the
following areas:-
✓ Software Context,

✓ Information Objectives

✓ Function and Performance of Software

▪ Software Poject Scope must be Unambigious and

understandable at the Management and Technical level

24
 Project Estimation
▪ For an effective management, accurate estimation of
various measures is a must.
▪ With the correct estimation, managers can manage and
control the project more efficiently and effectively.
▪ Project estimation may involve the following:
• Software size estimation
• Effort estimation
• Time estimation
• Cost estimation

25
 Software size estimation
▪ Software size may be estimated either in terms of KLOC
(Kilo Line of Code) or by calculating number of function
points in the software.

Effort estimation
▪ The manager estimates efforts in terms of personnel
requirement and man-hour required to produce the
software.
▪ For effort estimation software size should be known.

26
 Time estimation
▪ Once size and efforts are estimated, the time required to
produce the software can be estimated.
▪ Software tasks are divided into smaller tasks, activities or
events by Work Breakdown Structure (WBS).
▪ The tasks are scheduled on day-to-day basis or in calendar
months.

27
 Cost estimation
▪ This might be considered as the most difficult of all because it
depends on more elements than any of the previous ones.
▪ For estimating project cost, it is required to consider:
• Size of the software
• Software quality
• Hardware
• Additional software or tools, licenses etc.
• Skilled personnel with task-specific skills
• Travel involved
• Communication
• Training and support 28
 Estimation techniques
• Expert judgement
• Estimation by analogy
• Parkinson's Law
• Pricing to win
• Algorithmic cost modelling
• Top-down and bottom up

29
 1. Expert judgement
• One or more experts in both software development and the
application domain use their experience to predict software
costs.
• Process iterates until some consensus is reached.
▪ Advantages:
• Relatively cheap estimation method.
• Can be accurate if experts have direct experience of
similar systems
▪ Disadvantages:
• Very inaccurate if there are no experts!

30
 2. Estimation by analogy
▪ The cost of a project is computed by comparing the project
to a similar project in the same application domain.
• ➔ software size, effort, or cost of a comparable project
from the past
▪ Advantages:
• Accurate if project data available
▪ Disadvantages:
• Impossible if no comparable project has been tackled.
Needs systematically maintained cost database

31
 3. Pricing to win
▪ The project costs whatever the customer has to
spend on it
▪ Advantages:
• You get the contract
▪ Disadvantages:
• The probability that the customer gets the system he or
she wants is small. Costs do not accurately reflect the
work required.

32
 4. Parkinson's Law
▪ The project costs whatever resources are available
Advantages:
• it helps to distribute the project development time among
different activities in a balanced manner without any
additional overspend
Disadvantages:
• System is usually unfinished

33
 5. Bottom-up versus top-down
❑ Bottom-up : Start at the component level and estimate the effort
required for each component.
▪ Add these efforts to reach a final estimate
✓ use when no past project data
✓ identify all tasks that have to be done – so quite time-consuming
✓ use when you have no data about similar past projects
❑ Top-down : Start at the system level and assess the overall system
functionality and how this is delivered through sub-systems.
✓ produce overall estimate based on project cost drivers
✓ based on past project data
✓ divide overall estimate between jobs to be done
34
 COnstructive COst Model (COCOMO)
▪ Actually three different models :
1. THE BASIC MODEL: a gross estimator that does not take
individual complexity characteristics into account.
2. THE INTERMEDIATE MODEL: considers 15 factors that
are called “cost driver attributes”
3. THE DETAILED MODEL: introduces “phase sensitive
effort multipliers” that enable the estimate to be modified
and updated as the project continues.

35
COCOMO : Basic Model

36
 Cont’d...
▪ Organic mode (application programs) : relatively small,
simple SW projects (e.g. Thermal analysis program)
▪ Semi-detached mode ( utility programs): an
intermediate (in size and complexity) SW projects with
mixed experience, mixed requirements
▪ Embedded mode (system programs) – developed within
tight HW, SW and operational constraints (flight control
SW for aircraft)

37
 Cont’d…
Example:1
▪ Assume that the size of semi-detached software product has been
estimated to be 33,300 lines of source code.
▪ Determine the effort required to develop the software product and
the nominal development time.
Solution:
• The estimated number of lines of code is : 33.3 KLOC
Project type is : semi-detached
Therefore,
pm = 3.0* KLOC1.12 = 3.0 (33.3) 1.12 = 152 person-months
To compute development time :
tdev = 2.5 pm0.35 = 2.5 (152)0.35 = 14.5 months
38
 Cont’d…
Example:2
▪ Assume that the size of an organic type software product has been
estimated to be 32,000 lines of source code.
▪ Assume that the average salary of software engineers be ETB. 15,000
per month.
▪ Determine the effort required to develop the software product and the
nominal development time.
Solution
• From the basic COCOMO estimation formula for organic software:
Effort = 2.4 х (32)1.05 = 91 PM
Nominal development time = 2.5 х (91)0.38 = 14 months
Cost required to develop the product = 14 х 15,000 = 210,000 Birr
39
 COCOMO: Intermediate Model
▪ There are 15 different attributes, called cost driver attributes,
that determine the multiplying factors.
▪ These factors depend on product, computer, personnel, and
technology (project) attributes.
▪ Each cost driver has a rating scale (very low, low, nominal,
high, very high and extra high ).
Software Project a b

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20 40

Effort multipliers for different cost drivers.

41
 Steps
1) Determine the initial estimate (nominal estimate) of the
development effort from the estimate of thousands of
lines of source code (KLOC).
→ Ei = a * (KLOC) b
2) Determine a set of 15 multiplying factors from different
attributes of the project, and compute the effort
adjustment factor (EAF).
→ EAF = product of all the 15 multiplying factors.
3) Compute the total effort by multiplying the initial effort
with the effort adjustment factor.
→ Total effort = Ei * EAF
42
 Cont’d…
• Assume 4 modules are to be contained in a project.
• Assume the project is organic.
• The modules are
M1 = 0.5 KLOC, M2 = 0.5 KLOC, M3 = 0.3 KLOC, and M4 = 0.7
KLOC.
❑And the multiplying factors are:
✓RELY, required reliability is …. very high
✓CPLX, product complexity is…. high
✓STOR, main storage constraint is … high
✓Others are … nominal
❑Calculate: i) The initial effort
ii) The total effort 43
 Cont’d…
Solution:
• size = M1 + M2 + M3 + M4
= 2 KLOC
• For organic project a = 3.2, b = 1.05
Ei = a * (size) b
= 6.72
• Total Effort = Ei * EAF; Where
EAF =1.40 * 1.15 * 1.06 * 1 = 1.71
Total Effort =6.72 *1.71
= 11.5 PM 44
 Exercise
❑ Suppose a system for office automation has to be designed.
From the requirements, it is clear that there will be four major
modules in the system: data entry, data update, query, and report
generator. It is also clear from the requirements that this project
will fall in the organic category. The sizes for the different
modules and the overall system are estimated to be:
• Data Entry 0.6 KLOC
• Data Update 0.6 KLOC
• Query 0.8 KLOC
• Reports 1.0 KLOC
• TOTAL 3.0 KLOC
45
 Cont’d...
▪ From the requirements, the ratings of the different cost
driver attributes(multiplier) are assessed
• Complexity High 1.15
• Storage High 1.06
• Experience Low 1.13
• Programmer Capability Low 1.17.
▪ Based on this value what is the estimated effort by person
month
• Ei =? a * KLOCb
• EAF= ?
• E= Ei * EAF
46
 Project Scheduling and Staffing
▪ As well as effort estimation, managers must estimate the
calendar time required to complete a project and when staff
will be required.
▪ Once the effort is estimated, various schedules (or project
duration can be developed.
▪ For example, for a project whose effort estimate is 56
person-months, schedule of 8 months is possible with 7
people.
▪ A schedule of 7 months with 8 people is also possible, as is
a schedule of approximately 9 months with 6 people.
▪ The time required is independent of the number of people
working on the project➔ not fully interchangeable 47
 PROJECT SCHEDULING
• Project-task scheduling is an important project planning activity.
• It involves deciding which tasks would be taken up when.
• In order to schedule the project activities, a software project manager
needs to do the following:
1. Identify all the tasks needed to complete the project.
2. Break down large tasks into small activities.
3. Determine the dependency among different activities.
4. Establish the most likely estimates for the time durations necessary to
complete the activities.
5. Allocate resources to activities.
6. Plan the starting and ending dates for various activities.
7. Determine the critical path.
• A critical path is the chain of activities that determines the duration of the
project. 48
 Gantt Chart
• Gantt chart was devised by Henry Gantt (1917).
• It represents project schedule with respect to time periods.
• It is a horizontal bar chart with bars representing activities and time
scheduled for the project activities.

49
 Why Are Projects Late?
✓an unrealistic deadline established by someone outside the
software development group
✓ changing customer requirements that are not reflected in
schedule changes;
✓predictable and/or unpredictable risks that were not considered
when the project commenced;
✓technical difficulties that could not have been foreseen in
advance
✓human difficulties that could not have been foreseen in advance;
✓miscommunication among project staff that results in delays;
✓a failure by project management to recognize that the project is
falling behind schedule and a lack of action to correct the
problem
50
 Staffing( team structure)
▪ Detailed scheduling is done only after actual assignment of people has
been done.
▪ project's team is led by a project manager, who does the planning and
task assignment.
▪ is responsible for all major technical decisions of the project.
▪ The teams are structured hierarchically, consists of analyzer,
programmers, testers, a configuration controller, quality controller, and
possibly a librarian for documentation.
▪ Generally the team structure is determined by
• The Management style of the organization;
• The number of people, who will populate the team, and their skill
levels
• The overall problem difficulties.
51
 Cont’d...
▪ Project Factors that should be considered when Planning the
structure of Teams.
1. The difficulty of the ‘Problem” to be solved
2. The ‘’Size’’ of the resultant programs in terms of Line Code
(LOC) or Function Points (FP)
3. The “Time” that the Team will stay together (Team Lifetime)
4. The degree to which the problem can be modularised.
5. The required Quality and Reliability of the System to be built
6. The rigidity of the Delivery Date
7. The degree of Sociability (Communication) required for the
Project.
52
 Cont’d...
▪ Group communication: which affects the progress of the
project
❑Several factors affect communications in a group
✓ Status of the group members
• Higher-status members tend to dominate communications
with lower status members
✓Personalities in the group
• If there are too many people in the group who are task-
oriented, this may inhibit effective communications (all are
concentrated on technical issues and nobody discusses
problems) 53
 Cont’d...
✓Sexual composition of the group
• Studies have shown that men and women prefer to work
in mixed-sex groups.
• Within these groups, communications are better than in
single-sex groups
✓ Communication channels
• Communications are more effective if anyone in a
group can easily contact anyone else

54
 Team Structure
• We consider only three team structures:
• Democratic,
• Chief programmer,
• Mixed team

55
 Chief programmer teams
• Fred Brooks was concerned about the need to maintain ‘design
consistency’ in large software systems
• Appointment of key programmers, Chief Programmers, with
responsibilities for defining requirements, designing, writing and test
software code
• Assisted by a support team: co-pilot – shared coding, editor who
made typed in new or changed code, program clerk who wrote and
maintained documentation and tester
• Problem – finding staff capable of the chief programmer role

56
 Democratic Team
• Does not enforce any formal team hierarchy.
• Decisions are taken based on discussions,
• any member is free to discuss with any other member
• Since a lot of debate and discussions among the team
members takes place,
• for large team sizes significant overhead is incurred

57
 Mixed Control Team Structure
• Incorporates both hierarchical reporting and democratic
set up.

58
 Risk management
• The planning for risk includes these steps:
• Risk identification – what risks might there be?
• Risk analysis and prioritization – which are the most
serious risks?
• Risk planning – what are we going to do about them?
• Risk monitoring – what is the current state of the risk?

59
 Boehm’s top 10 development risks
Risk Risk reduction techniques

Personnel Staffing with top talent; job matching; teambuilding;

shortfalls training and career development; early scheduling
of key personnel

Unrealistic time Multiple estimation techniques; design to cost;

and cost incremental development; recording and analysis
estimates of past projects; standardization of methods

Developing the Improved software evaluation; formal specification

wrong methods; user surveys; prototyping; early user
software manuals
functions
Developing the Prototyping; task analysis; user involvement
wrong user 60
interface
 Cont’d…
Gold plating Requirements scrubbing, prototyping,
design to cost
Late changes to Change control, incremental development
requirements
Shortfalls in externally Benchmarking, inspections, formal
supplied components specifications, contractual agreements,
quality controls
Shortfalls in externally Quality assurance procedures, competitive
performed tasks design etc
Real time performance Simulation, prototyping, tuning
problems
Development Technical analysis, cost-benefit analysis,
technically too difficult prototyping , training
61
Thank You!
?