CS 504: SOFTWARE

ENGINEERING

Software Project
Management
01/24/25 CS 504 1
 Software project management
Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the
requirements of the organisations developing
and procuring the software.

Project management is needed because

software development is always subject to
budget and schedule constraints that are set by
the organisation developing the software.

01/24/25 CS 504 2
Software management distinctions
The product is intangible.
The product is uniquely flexible.
Software engineering is not recognized as an
engineering discipline with the sane status as

mechanical, electrical engineering, etc.

The software development process is not
standardised.
Many software projects are 'one-off' projects.

01/24/25 CS 504 3
 Management activities
Proposal writing.
Project planning and scheduling.
Project costing.
Project monitoring and reviews.
Personnel selection and evaluation.
Report writing and presentations.

01/24/25 CS 504 4
 Management commonalities
These activities are not peculiar to software
management.
Many techniques of engineering project
management are equally applicable to
software project management.
Technically complex engineering systems
tend
to suffer from the same problems as software
systems.

01/24/25 CS 504 5
Management Spectrum
• People:
– the most important element of a successful
project
– People management capability maturity model
(PM-CMM) can be applied
• Product:
– the software to be built
• Process — the set of framework activities and
software engineering tasks to get the job done
• Project — all work required to make the
product a reality

01/24/25 CS 504 6
The People

01/24/25 CS 504 7
People Management Capability
Model
• Curtis et al (2009) People Capability Maturity
Level, ver 2.0, 2nd Ed.

01/24/25 CS 504 8
Stakeholders
• Senior managers who define the business issues
that often have significant influence on the project.
• Project (technical) managers who must plan,
motivate, organize, and control the practitioners
who do software work.
• Practitioners who deliver the technical skills that
are necessary to engineer a product or application.
• Customers who specify the requirements for the
software to be engineered and other stakeholders
who have a peripheral interest in the outcome.
• End-users who interact with the software once it
is released for production use.

01/24/25 CS 504 9
Project Teams
How to lead?

How to organize?

How to collaborate?

How to motivate?
How to create good ideas?

01/24/25 CS 504 10
The Team Leaders
• The MOI Model:
– Motivation. The ability to encourage (by
“push or pull”) technical people to produce to
their best ability.
– Organization. The ability to mold existing
processes (or invent new ones) that will
enable the initial concept to be translated into
a final product.
– Ideas or innovation. The ability to encourage
people to create and feel creative even when
they must work within bounds established for
a particular software product or application.

01/24/25 CS 504 11
 Project staffing
May not be possible to appoint the ideal people to
work on a project
 Project budget may not allow for the use of highly-
paid staff;
 Staff with the appropriate experience may not be
available;
 An organisation may wish to develop employee skills
on a software project.
Managers have to work within these constraints
especially when there are shortages of trained staff.

01/24/25 CS 504 12
 Factors to Consider When Selecting Team
Members
• The difficulty of the problem to be solved
• The size of the resultant program(s) in lines of
code or function points
• The time that the team will stay together (team
lifetime)
• The degree to which the problem can be
modularized
• The required quality and reliability of the system
to be built
• The rigidity of the delivery date
• The degree of sociability (communication)
required for the project
01/24/25 CS 504 13
Organizational
• closed paradigm:
Paradigms
– structures a team along a traditional hierarchy
of authority.
– Such teams can work well when producing S/W
that is quite similar to past efforts, but they will
be less likely to be innovative when working
within the closed paradigm.
• random paradigm:
– structures a team loosely and depends on
individual initiative of the team members.
– When innovation or technological breakthrough
is required, team following the random
paradigm will excel.
– But such teams may struggle when “Orderly
01/24/25
Performance”
CS 504
is required. 14
Organizational Paradigms
• open paradigm:
– attempts to structure a team in a manner that
achieves some of the controls associated with
the closed paradigm but also much of the
innovation that occurs when using the random
paradigm.
– Work is performed collaboratively. Heavy
communication and consensus-based decision
making are the trademarks of open paradigm
teams.
– Open paradigm team structure are well suited
to the solution of complex problems but may
not perform as efficiently as other teams.

01/24/25 CS 504 15
Organizational Paradigms
• synchronous paradigm:
– relies on the natural compartmentalization of
a problem and organizes team members to
work on pieces of the problem with little
active communication among themselves.

“Working with people is difficult but not

impossible.” Peter Drucker
01/24/25 CS 504 16
Organizational Paradigms
• One of the earliest software team structures
was a closed paradigm structure originally
called chief programmer team. The nucleus of
the teams is composed of:
– A Senior Engineer that plans, coordinates,
and reviews all technical activities of the
team.
– A Technical Staff (2 – 5 people), that conduct
analysis and development activities.
– A Backup Engineer that supports the senior
engineer in his activities and can replace the
Senior Engineer with minimum loss of project
continuity.

01/24/25 CS 504 17
Jelled Project Teams
• A jelled team is a group of people so strongly
know that the whole is greater than the sum of
parts.
• Members of jelled teams are significantly more
productive and more motivated than average.
• They share a common goal, a common culture,
and in many cases, a “sense of eliteness” that
makes them unique.
• But not all teams jell. In fact, many teams
suffer from “team toxicity.”

01/24/25 CS 504 18
Team Toxicity: A Peril of Success
• A frenzied work atmosphere in which team
members waste energy and lose focus on the
objectives of the work to be performed.
High frustration caused by personal, business, or
technological factors that cause friction among
team members.
“Fragmented or poorly coordinated procedures” or
a poorly defined or improperly chosen process
model that becomes a roadblock to
accomplishment.
Unclear definition of roles resulting in a lack of
accountability and resultant finger-pointing.

01/24/25 CS 504 19
Team Toxicity: A Peril of Success
• “Continuous and repeated exposure to failure”
that leads to a loss of confidence and a
lowering of morale.
• To avoid a frenzied work environment, the
manager should be certain that the team has
access to all information required to do the job
and that major goals and objectives, once
defined, should not be modified unless
absolutely necessary.
• Teams often struggle with the differing human
traits of their members.
• Some team members are extroverted; others
are introverted.
01/24/25 CS 504 20
Team Toxicity: A peril of Success
• Some people gather information intuitively,
distilling broad concepts from dissimilar facts.
• Others process information linearly, collecting
and organizing minute details from the data
provided.
• Some team members are comfortable making
decisions only when a logical, orderly
argument is presented.
• Others are intuitive, willing to make a decision
based on “feel”.

01/24/25 CS 504 21
Team Toxicity: A peril of success
• Some practitioners want a detailed schedule
populated by organized tasks that enable them
to achieve closure for some element of a
project.
• Others prefer a more spontaneous environment
in which open issues are OK.
• Some work hard to get things done long before
a milestone date, thereby avoiding stress as
date approaches, while others don't
• It is important to note that recognition of
human differences is the first step toward
creating teams that jell.

01/24/25 CS 504 22
Agile Team
• Team members must have trust in one
another.
• The distribution of skills must be appropriate to
the problem.
• Mavericks may have to be excluded from the
team, if team cohesiveness is to be maintained.
• Team is “self-organizing”
– An adaptive team structure
– Uses elements of random, open, and
synchronous paradigms
– Significant autonomy

01/24/25 CS 504 23
Agile Team
• The agile philosophy stresses individual
competency coupled with group collaboration
as critical success factors for the team.
• “Collective ownership is nothing more than an
instantiation of the idea that products should
be attributable to the team, not individuals who
make up the team.” Jim Highsmith

01/24/25 CS 504 24
Coordination and Communication
• Formal, impersonal approaches include
software engineering documents and work
products (including source code), technical
memos, project milestones, schedules, and
project control tools, change requests and
related documentation, error tracking reports,
and repository data.
• Formal, interpersonal procedures focus on
quality assurance activities applied to software
engineering work products. These include
status review meetings and design and code
inspections.

01/24/25 CS 504 25
Coordination and Communication
• Informal, interpersonal procedures include
group meetings for information dissemination
and problem solving and “collocation of
requirements and development staff.”
• Electronic communication encompasses
electronic mail, electronic bulletin boards, and
by extension, video-based conferencing
systems.
• Interpersonal networking includes informal
discussions with team members and those
outside the project who may have experience
or insight that can assist team members.

01/24/25 CS 504 26
The Product

01/24/25 CS 504 27
Software Scope
• Context. How does the software to be built
fit into a larger system, product, or business
context and what constraints are imposed as
a result of the context?
• Information objectives. What customer-
visible data objects are produced as output
from the software? What data objects are
required for input?
• Function and performance. What function
does the software perform to transform input
data into output? Are any special
performance characteristics to be addressed?
01/24/25 CS 504 28
Software Scope
• Software project scope must be unambiguous
and understandable at the management and
technical levels.
• A statement of software scope must be
bounded “bounds the features of the software.”

01/24/25 CS 504 29
Problem Decomposition
• Sometimes called partitioning or problem
elaboration:
– An activity that sits at the core of S/W
requirements analysis.
– During the scoping activity no attempt is
made to fully decompose the problem.
– Decomposition is applied in:
• The functionality that must be delivered.
• The process that will be used to deliver it.

01/24/25 CS 504 30
Problem Decomposition
• Once scope is defined …
– It is decomposed into constituent functions
– It is decomposed into user-visible data objects
or
It is decomposed into a set of problem classes
Decomposition process continues until all functions
or problem classes have been defined

01/24/25 CS 504 31
The Process

01/24/25 CS 504 32
The Process
• The manager must decide which process model
is most appropriate for:
– The customers who have requested the product
and the people who will do the work.
– The characteristics of the product itself
– The project environment in which the S/W team
works.
• Once a process framework has been established
– Consider project characteristics
– Determine the degree of rigor required
– Define a task set for each software engineering
activity

01/24/25 CS 504 33
The Process
• Task set include:
– Software engineering tasks
– Work products
– Quality assurance points
– Milestones

01/24/25 CS 504 34
Process Decomposition
• Process decomposition commences when
the manager asks. “how do we accomplish
this framework activity?”
• For example, a small, relatively simple project
might require the following work tasks for the
communication activity:
– Develop list of clarification issues.
– Meet with customer to address clarification
issues.
– Jointly develop a statement of scope.
– Review the statement of scope with all
concerned.
– Modify the statement of scope as required.
01/24/25 CS 504 35
The Project

01/24/25 CS 504 36
Project is in Jeopardy When
• Software people don’t understand their customer’s
needs.
• The product scope is poorly defined.
• Changes are managed poorly.
• The chosen technology changes.
• Business needs change [or are ill-defined].
• Deadlines are unrealistic.
• Users are resistant.
• Sponsorship is lost [or was never properly obtained].
• The project team lacks people with appropriate skills.
• Managers [and practitioners] avoid best practices and
lessons learned.

01/24/25 CS 504 37
How does the manager act to
avoid problems just noted?
• Start on the right foot.
– accomplished by working hard (very hard) to
understand the problem that is to be solved
and then setting realistic objectives and
expectations.
• Maintain momentum.
– the project manager must provide incentives
to keep turnover of personnel to an absolute
minimum, the team should emphasize quality
in every task it performs, and senior
management should do everything possible to
stay out of the team’s way.

01/24/25 CS 504 38
How does the manager act to
avoid problems just noted?
• Track progress.
– progress is tracked as work products (e.g.,
models, source code, sets of test cases) are
produced and approved (using formal technical
reviews) as part of a quality assurance activity.
• Make smart decisions.
– decisions of the project manager and the
software team should be to “keep it simple.”
Decide to allocate more time to identify and
then avoid obvious risks, and decide to allocate
more time than you think is needed to complex
or risky tasks (you’ll need every second.)

01/24/25 CS 504 39
How does the manager act to
avoid problems just noted?
• Conduct a postmortem analysis.
– Establish a consistent mechanism for
extracting lessons learned for each project.

01/24/25 CS 504 40
Risk management
Risk management is concerned with
identifying risks and drawing up plans to
minimise their effect on a project.
A risk is a probability that some adverse
circumstance will occur
Project risks affect schedule or resources;
Product risks affect the quality or performance
of the software being developed;
Business risks affect the organisation
developing or procuring the software.

01/24/25 CS 504 41
Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be
delivered on schedule.
Requirements change Project and There will be a larger number of changes to the
product requirements than anticipated.
Specification delays Project and Specifications of essential interfaces are not available on
product schedule
Size underestimate Project and The size of the system has been underestimated.
product
CASE tool under- Product CASE tools which support the project do not perform as
performance anticipated
Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.

01/24/25 CS 504 42
The risk management process
Risk identification
Identify project, product and business risks;
Risk analysis
Assess the likelihood and consequences of
these risks;
Risk planning
Draw up plans to avoid or minimise the effects
of the risk;
Risk monitoring
Monitor the risks throughout the project;

01/24/25 CS 504 43
The risk management process

Risk Risk
Risk analysis Risk planning
identification monitoring

Risk avoidance
List of potential Prioritised risk Risk
and contingency
risks list assessment
plans

01/24/25 CS 504 44
Risk identification
Technology risks.
People risks.
Organisational risks.
Requirements risks.
Estimation risks.

01/24/25 CS 504 45
Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per second
as expected.
Software components that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
Required training for staff is not available.
Organisational The organisation is restructured so that different management are responsible for
the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.

01/24/25 CS 504 46
Risk analysis
Assess probability and seriousness of each
risk.
Probability may be very low, low, moderate,
high or very high.
Risk effects might be catastrophic, serious,
tolerable or insignificant.

01/24/25 CS 504 47
Risk analysis (i)
Risk Probability Effects
Organisational financial problems force reductions in Low Catastrophic
the project budget.
It is impossible to recruit staff with the skills required High Catastrophic
for the project.
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain Moderate Serious
defects which limit their functionality.
Changes to requirements that require major design Moderate Serious
rework are proposed.
The organisation is restructured so that different High Serious
management are responsible for the project.

01/24/25 CS 504 48
Risk analysis (ii)
Risk Probability Effects
The database used in the system cannot process as Moderate Serious
many transactions per second as expected.
The time required to develop the software is High Serious
underestimated.
CASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of Moderate Tolerable
requirements changes.
Required training for staff is not available. Moderate Tolerable
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificant

01/24/25 CS 504 49
Risk planning
Consider each risk and develop a strategy to
manage that risk.
Avoidance strategies
The probability that the risk will arise is
reduced;
Minimisation strategies
The impact of the risk on the project or
product will be reduced;
Contingency plans
If the risk arises, contingency plans are plans
to deal with that risk;
01/24/25 CS 504 50
Risk management strategies (i)
Risk Strategy
Organisational Prepare a briefing document for senior management
financial problems showing how the project is making a very important
contribution to the goals of the business.
Recruitment Alert customer of potential difficulties and the
problems possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-
components in components of known reliability.

01/24/25 CS 504 51
Risk management strategies (ii)
Risk Strategy
Requirements Derive traceability information to assess requirements
changes change impact, maximise information hiding in the
design.
Organisational Prepare a briefing document for senior management
restructuring showing how the project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higher-
performance performance database.
Underestimated Investigate buying in components, investigate use of a
development time program generator

01/24/25 CS 504 52
Risk monitoring
Assess each identified risks regularly to
decide whether or not it is becoming less or
more probable.
Also assess whether the effects of the risk
have changed.
Each key risk should be discussed at
management progress meetings.

01/24/25 CS 504 53
Risk indicators
Risk type Potential indicators
Technology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about
CASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
defects

01/24/25 CS 504 54
Check for
• Product Metrics for
Software

01/24/25 CS 504 55