Software Development Management
Lecture 12
1Chapter 22 Project management
Topics covered
 Processes and methodologies
 Project management
 Project planning
 Risk management
 People management
2Chapter 22 Project management
Processes and Methodologies
Lecture 12/Part 1
3Chapter 2 Software Processes
Software process models
 The waterfall model
 Plan-driven model. Separate and distinct phases of specification
and development.
 Incremental development
 Specification, development and validation are interleaved. May
be plan-driven or agile (respecting agile development principles).
 Reuse-oriented software engineering
 The system is assembled from existing components. May be
plan-driven or agile.
 In practice, most large systems are developed using a
process that incorporates elements from all of these
models.
Chapter 2 Software Processes 4
Software prototyping
 A prototype is an initial version of a system used to
demonstrate concepts and try out design options.
 A prototype can be used in:
 The requirements engineering process to help with requirements
elicitation and validation;
 In design processes to explore options and develop a UI design;
 In the testing process to run back-to-back tests.
5Chapter 2 Software Processes
Benefits of prototyping
 Improved system usability.
 A closer match to users’ real needs.
 Improved design quality.
 Improved maintainability.
 Reduced development effort.
6Chapter 2 Software Processes
Prototype development
 May be based on rapid prototyping languages or tools
 May involve leaving out functionality, low quality
 Prototype focus on areas of the product that are not well-
understood;
 Error checking and recovery may not be included in the
prototype;
 Focus on functional rather than non-functional requirements
such as reliability and security – hard to tune for these;
 Normally undocumented.
 Prototypes should be discarded after development as
they are not a good basis for a production system
Chapter 2 Software Processes 7
Incremental delivery
 Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality.
 User requirements are prioritised and the highest priority
requirements are included in early increments.
 Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
8Chapter 2 Software Processes
Incremental delivery
9Chapter 2 Software Processes
Incremental delivery advantages
 Customer value can be delivered with each increment so
system functionality is available earlier.
 Early increments act as a prototype to help elicit
requirements for later increments.
 Lower risk of overall project failure.
 The highest priority system services tend to receive the
most testing.
10Chapter 2 Software Processes
Incremental delivery problems
 Most systems require a set of basic facilities that are
used by different parts of the system.
 As requirements are not defined in detail until an increment is to
be implemented, it can be hard to identify common facilities that
are needed by all increments.
 The essence of iterative processes is that the
specification is developed in conjunction with the
software.
 However, this conflicts with the procurement model of many
organizations, where the complete system specification is part of
the system development contract.
11Chapter 2 Software Processes
Boehm’s spiral model
 Process is represented as a spiral rather than as a
sequence of activities with backtracking.
 Each loop in the spiral represents a phase in the
process.
 No fixed phases such as specification or design - loops
in the spiral are chosen depending on what is required.
 Risks are explicitly assessed and resolved throughout
the process.
12Chapter 2 Software Processes
Boehm’s spiral model of the software
process
13Chapter 2 Software Processes
Spiral model sectors
 Objective setting
 Specific objectives for the phase are identified.
 Risk assessment and reduction
 Risks are assessed and activities put in place to reduce the key
risks.
 Development and validation
 A development model for the system is chosen which can be
any of the generic models.
 Planning
 The project is reviewed and the next phase of the spiral is
planned.
14Chapter 2 Software Processes
Spiral model usage
 Spiral model has been very influential in helping people
think about iteration in software processes and
introducing the risk-driven approach to development.
 In practice, however, the model is rarely used as
published for practical software development.
Chapter 2 Software Processes 15
The Rational Unified Process
 A modern generic process derived from the work on the
UML and associated process.
 Brings together aspects of the 3 generic process models
discussed previously.
 Normally described from 3 perspectives
 A dynamic perspective that shows phases over time;
 A static perspective that shows process activities;
 A practive perspective that suggests good practice.
16Chapter 2 Software Processes
Phases in the Rational Unified Process
17Chapter 2 Software Processes
RUP phases
 Inception
 Establish the business case for the system.
 Elaboration
 Develop an understanding of the problem domain and the
system architecture.
 Construction
 System design, programmingand testing.
 Transition
 Deploy the system in its operating environment.
18Chapter 2 Software Processes
Static workflows in the Rational Unified
Process
Workflow Description
Business modelling The business processes are modelled using business
use cases.
Requirements Actors who interact with the system are identified and
use cases are developed to model the system
requirements.
Analysis and design A design model is created and documented using
architectural models, component models, object
models and sequence models.
Implementation The components in the system are implemented and
structured into implementation sub-systems.
Automatic code generation from design models helps
accelerate this process.
19Chapter 2 Software Processes
Static workflows in the Rational Unified
Process
Workflow Description
Testing Testing is an iterative process that is carried out in conjunction
with implementation. System testing follows the completion of
the implementation.
Deployment A product release is created, distributed to users and installed in
their workplace.
Configuration and
change management
This supporting workflow managed changes to the system (see
Chapter 25).
Project management This supporting workflow manages the system development (see
Chapters 22 and 23).
Environment This workflow is concerned with making appropriate software
tools available to the software development team.
20Chapter 2 Software Processes
Agile methods
 Dissatisfaction with the overheads involved in software
design methods of the 1980s and 1990s led to the
creation of agile methods. These methods:
 Focus on the code rather than the design
 Are based on an iterative approach to software development
 Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements.
 The aim of agile methods is to reduce overheads in the
software process (e.g. by limiting documentation) and to
be able to respond quickly to changing requirements
without excessive rework.
21Chapter 3 Agile software development
The principles of agile methods
Principle Description
Customer involvement Customers should be closely involved throughout the
development process. Their role is provide and prioritize new
system requirements and to evaluate the iterations of the
system.
Incremental delivery The software is developed in increments with the customer
specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and
exploited. Team members should be left to develop their own
ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and so design the
system to accommodate these changes.
Maintain simplicity Focus on simplicity in both the software being developed and
in the development process. Wherever possible, actively work
to eliminate complexity from the system.
22Chapter 3 Agile software development
Agile method applicability
 Product development where a software company is
developing a small or medium-sized product for sale.
 Custom system development within an organization,
where there is a clear commitment from the customer to
become involved in the development process and where
there are not a lot of external rules and regulations that
affect the software.
 Because of their focus on small, tightly-integrated teams,
there are problems in scaling agile methods to large
systems.
Chapter 3 Agile software development 23
Problems with agile methods
 It can be difficult to keep the interest of customers who
are involved in the process.
 Team members may be unsuited to the intense
involvement that characterises agile methods.
 Prioritising changes can be difficult where there are
multiple stakeholders.
 Maintaining simplicity requires extra work.
 Contracts may be a problem as with other approaches to
iterative development.
24Chapter 3 Agile software development
Plan-driven and agile development
 Plan-driven development
 A plan-driven approach to software engineering is based around
separate development stages with the outputs to be produced at
each of these stages planned in advance.
 Not necessarily waterfall model – plan-driven, incremental
development is possible
 Iteration occurs within activities.
 Agile development
 Specification, design, implementation and testing are interleaved
and the outputs from the development process are
decided through a process of negotiation during the software
development process.
25Chapter 3 Agile software development
Plan-driven and agile specification
26Chapter 3 Agile software development
Extreme programming
 Perhaps the best-known and most widely used agile
method.
 Extreme Programming (XP) takes an ‘extreme’ approach
to iterative development.
 New versions may be built several times per day;
 Increments are delivered to customers every 2 weeks;
 All tests must be run for every build and the build is only
accepted if tests run successfully.
27Chapter 3 Agile software development
XP and agile principles
 Incremental development is supported through small,
frequent system releases.
 Customer involvement means full-time customer
engagement with the team.
 People not process through pair programming, collective
ownership and a process that avoids long working hours.
 Change supported through regular system releases.
 Maintaining simplicity through constant refactoring of
code.
28Chapter 3 Agile software development
Key points
 Processes should include activities to cope with change. This may
involve a prototyping phase that helps avoid poor decisions on
requirements and design.
 Processes may be structured for iterative development and delivery
so that changes may be made without disrupting the system as a
whole.
 The Rational Unified Process is a modern generic process model
that is organized into phases (inception, elaboration, construction
and transition) but separates activities (requirements, analysis and
design, etc.) from these phases.
 Agile methods are incremental development methods that focus on
rapid development, frequent releases of the software, reducing
process overheads and producing high-quality code. They involve
the customer directly in the development process.
29Chapter 2 Software Processes
Project Management
Lecture 12/Part 2
30Chapter 22 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.
Software project management
31Chapter 22 Project management
Success criteria
 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.
32Chapter 22 Project management
 The product is intangible.
 Software cannot be seen or touched. Software project managers
cannot see progress by simply looking at the artefact that is
being constructed.
 Many software projects are 'one-off' projects.
 Large software projects are usually different in some ways from
previous projects. Even managers who have lots of previous
experience may find it difficult to anticipate problems.
 Software processes are variable and organization
specific.
 We still cannot reliably predict when a particular software
process is likely to lead to development problems.
Software management distinctions
33Chapter 22 Project management
 Project planning
 Project managers are responsible for planning, estimating and
scheduling project development and assigning people to
tasks.
 Risk management
 Project managers assess the risks that may affect a project,
monitor these risks and take action when problems arise.
 People management
 Project managers have to choose people for their team and
establish ways of working that leads to effective team
performance.
Management activities
34Chapter 22 Project management
Management activities
 Reporting
 Project managers are usually responsible for reporting on the
progress of a project to customers and to the managers of the
company developing the software.
 Contract negotiation
 The first stage in a software project may involve writing a
proposal to win a contract to carry out an item of work. The
proposal describes the objectives of the project and how it will be
carried out.
 Then the contract is negotiated and later extended with
requirements changes and changing schedule constraints.
35Chapter 22 Project management
Key points
 Good project management is essential if software
engineering projects are to be developed on schedule
and within budget.
 Software management is distinct from other engineering
management. Software is intangible. Projects may be
novel or innovative with no body of experience to guide
their management. Software processes are not as
mature as traditional engineering processes.
Chapter 22 Project management 36
Project Planning
Lecture 12/Part 3
37Chapter 23 Project planning
Project planning
 Project planning involves breaking down the work into
parts and assign these to project team members,
anticipate problems that might arise and prepare
tentative solutions to those problems.
 The project plan, which is created at the start of a
project, is used to communicate how the work will be
done to the project team and customers, and to help
assess progress on the project.
Chapter 23 Project planning
Planning stages
 At the proposal stage, when you are bidding for a
contract to develop or provide a software system.
 During the project startup phase, when you have to
plan who will work on the project, how the project will be
broken down into increments, how resources will be
allocated across your company, etc.
 Periodically throughout the project, when you modify
your plan in the light of experience gained and
information from monitoring the progress of the work.
Chapter 23 Project planning
Plan-driven development
 Plan-driven or plan-based development is an approach
to software engineering where the development
process is planned in detail.
 Plan-driven development is based on engineering project
management techniques and is the ‘traditional’way of managing
large software development projects.
 A project plan is created that records the work to be
done, who will do it, the development schedule and the
work products.
 Managers use the plan to support project decision
making and as a way of measuring progress.
Chapter 23 Project planning
The project planning process
Chapter 23 Project planning
Project scheduling
 Project scheduling is the process of deciding how the
work in a project will be organized as separate tasks,
and when and how these tasks will be executed.
 You estimate the calendar time needed to complete each
task, the effort required and who will work on the tasks
that have been identified.
 You also have to estimate the resources needed to
complete each task, such as the disk space required on
a server, the time required on specialized hardware,
such as a simulator, and what the travel budget will be.
Chapter 23 Project planning
The project scheduling process
 Split project into tasks and estimate time and resources required to
complete each task.
 Organize tasks concurrently to make optimal
use of workforce.
 Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Chapter 23 Project planning
Schedule representation
 Graphical notations are normally used to illustrate the
project schedule.
 These show the project breakdown into tasks. Tasks
should not be too small. They should take about a week
or two.
 Bar charts are the most commonly used representation
for project schedules. They show the schedule as
activities or resources against time.
Chapter 23 Project planning
Activity bar chart
Chapter 23 Project planning
Staff allocation chart
Chapter 23 Project planning
Scheduling problems
 Estimating the difficulty of problems and hence the cost
of developing a solution is hard.
 Productivity is not proportional to the number of people
working on a task.
 Adding people to a late project makes it later because of
communication overheads.
 The unexpected always happens. Always allow
contingency in planning.
Chapter 23 Project planning
Agile planning
 Agile methods of software development are iterative
approaches where the software is developed and
delivered to customers in increments.
 Unlike plan-driven approaches, the functionality of these
increments is not planned in advance but is decided
during the development.
 The decision on what to include in an increment depends on
progress and on the customer’s priorities.
 The customer’s priorities and requirements change so it
makes sense to have a flexible plan that can
accommodate these changes.
Chapter 23 Project planning
Software pricing
 Estimates are made to discover the cost, to the
developer, of producing a software system.
 You take into account, hardware, software, travel, training and
effort costs.
 There is not a simple relationship between the
development cost and the price charged to the customer.
 Broader organisational, economic, political and business
considerations influence the price charged.
Chapter 23 Project planning
Factors affecting software pricing
Factor Description
Market opportunity A development organization may quote a low price because
it wishes to move into a new segment of the software
market. Accepting a low profit on one project may give the
organization the opportunity to make a greater profit later.
The experience gained may also help it develop new
products.
Cost estimate
uncertainty
If an organization is unsure of its cost estimate, it may
increase its price by a contingency over and above its
normal profit.
Contractual terms A customer may be willing to allow the developer to retain
ownership of the source code and reuse it in other projects.
The price charged may then be less than if the software
source code is handed over to the customer.
Chapter 23 Project planning
Factors affecting software pricing
Factor Description
Requirements volatility If the requirements are likely to change, an organization
may lower its price to win a contract. After the contract is
awarded, high prices can be charged for changes to the
requirements.
Financial health Developers in financial difficulty may lower their price to
gain a contract. It is better to make a smaller than normal
profit or break even than to go out of business. Cash flow
is more important than profit in difficult economic times.
Chapter 23 Project planning
Estimation techniques
 Organizations need to make software effort and cost
estimates. There are two types of technique that can be
used to do this:
 Experience-based techniques The estimate of future effort
requirements is based on the manager’s experience of past
projects and the application domain. Essentially, the manager
makes an informed judgment of what the effort requirements are
likely to be.
 Algorithmic cost modeling In this approach, a formulaic approach
is used to compute the project effort based on estimates of
product attributes, such as size, and process characteristics,
such as experience of staff involved.
Chapter 23 Project planning
Experience-based approaches
 Experience-based techniques rely on judgments based
on experience of past projects and the effort expended in
these projects on software development activities.
 Typically, you identify the deliverables to be produced in
a project and the different software components or
systems that are to be developed.
 You document these in a spreadsheet, estimate them
individually and compute the total effort required.
 It usually helps to get a group of people involved in the
effort estimation and to ask each member of the group to
explain their estimate.
Chapter 23 Project planning
Algorithmic cost modelling
 Cost is estimated as a mathematical function of
product, project and process attributes whose
values are estimated by project managers:
 Effort = A ´ SizeB ´ M
 A is an organisation-dependent constant, B reflects the
disproportionate effort for large projects and M is a multiplier
reflecting product, process and people attributes.
 The most commonly used product attribute for cost
estimation is code size.
 Most models are similar but they use different values for
A, B and M.
Chapter 23 Project planning
Estimation accuracy
 The size of a software system can only be known
accurately when it is finished.
 Several factors influence the final size
 Use of COTS and components;
 Programming language;
 Distributionof system.
 As the development process progresses then the size
estimate becomes more accurate.
 The estimates of the factors contributing to B and M are
subjective and vary according to the judgment of the
estimator.
Chapter 23 Project planning
Estimate uncertainty
Chapter 23 Project planning
The COCOMO 2 model
 An empirical model based on project experience.
 Well-documented, ‘independent’ model which is not tied
to a specific software vendor.
 Long history from initial version published in 1981
(COCOMO-81) through various instantiations to
COCOMO 2.
 COCOMO 2 takes into account different approaches to
software development, reuse, etc.
Chapter 23 Project planning
COCOMO 2 models
 COCOMO 2 incorporates a range of sub-models that
produce increasingly detailed software estimates.
 The sub-models in COCOMO 2 are:
 Application composition model. Used when software is
composed from existing parts.
 Earlydesign model. Used when requirements are available but
design has not yet started.
 Reuse model. Used to compute the effort of integrating reusable
components.
 Post-architecture model. Used once the system architecture
has been designed and more information about the system is
available.
Chapter 23 Project planning
COCOMO estimation models
Chapter 23 Project planning
Key points
 Plan-driven development is organized around a complete project
plan that defines the project activities, the planned effort, the activity
schedule and who is responsible for each activity.
 Project scheduling involves the creation of graphical representations
the project plan. Bar charts show the activity duration and staffing
timelines, are the most commonly used schedule representations.
 The price charged for a system does not just depend on its
estimateddevelopment costs; it may be adjusted depending on the
market and organizational priorities.
 The COCOMO II costing model is an algorithmic cost model that
uses project, product, hardware and personnel attributes as well as
product size and complexity attributes to derive a cost estimate.
Chapter 23 Project planning
Risk Management
Lecture 12/Part 4
61Chapter 22 Project management
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 of the software being developed;
 Business risks affect the organisation developing or procuring
the software.
62Chapter 22 Project management
Examples of common project, product, and
business risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is
finished.
Managementchange Project There will be a change of organizational
management with different priorities.
Hardware unavailability Project Hardware that is essential for the project will not
be delivered on schedule.
Requirements change Projectand product There will be a larger number of changes to the
requirements than anticipated.
Specification delays Projectand product Specifications of essential interfaces are not
available onschedule.
Size underestimate Projectand product The size of the system has been underestimated.
CASE tool
underperformance
Product CASE tools, which support the project, do not
perform as anticipated.
Technologychange Business The underlying technology on which the system
is built is superseded by new technology.
Productcompetition Business A competitive product is marketed before the
system is completed.
63Chapter 22 Project management
Fine-grained risk types and their examples
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per
secondas expected.(1)
Reusable software components contain defects that mean they cannot be reused
as planned.(2)
People It is impossible to recruit staff with the skills required.(3)
Key staff are ill and unavailableatcritical times. (4)
Required training forstaff is notavailable.(5)
Organizational The organization is restructured so that different management are responsible for
the project.(6)
Organizational financial problemsforce reductions in the project budget.(7)
Tools The code generatedby software codegenerationtools is inefficient.(8)
Software tools cannot worktogetherin an integrated way.(9)
Requirements Changes to requirements thatrequire majordesign reworkare proposed.(10)
Customers fail to understand the impact of requirementschanges.(11)
Estimation The time required to develop the software is underestimated.(12)
The rate of defect repairis underestimated.(13)
The size of the software is underestimated.(14)
64Chapter 22 Project management
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;
65Chapter 22 Project management
The risk management process
66Chapter 22 Project management
Key points
 Risk management is now recognized as one of the most
important project management tasks.
 Risk management involves identifying and assessing
project risks to establish the probability that they will
occur and the consequences for the project if that risk
does arise. You should make plans to avoid, manage or
deal with likely risks if or when they arise.
Chapter 22 Project management 67
People Management
Lecture 12/Part 5
68Chapter 22 Project management
Managing people
 People are an organisation’s most important assets.
 The tasks of a manager are essentially people-oriented.
Unless there is some understanding of people,
management will be unsuccessful.
 Poor people management is an important contributor to
project failure.
Chapter 22 Project management
People management factors
 Consistency
 Team members should all be treated in a comparable way
without favourites or discrimination.
 Respect
 Different team members have different skills and these
differences should be respected.
 Inclusion
 Involve all team members and make sure that people’s views are
considered.
 Honesty
 You should always be honest about what is going well and what
is going badly in a project.
Chapter 22 Project management
Motivating people
 An important role of a manager is to motivate the people
working on a project.
 Motivation means organizing the work and the working
environment to encourage people to work effectively.
 If people are not motivated, they will not be interested in the work
they are doing. They will work slowly, be more likely to make
mistakes and will not contribute to the broader goals of the team
or the organization.
 Motivation is a complex issue but it appears that their are
different types of motivation based on:
 Basic needs (e.g. food, sleep, etc.);
 Personal needs (e.g. respect, self-esteem);
 Social needs (e.g. to be accepted as part of a group).
71Chapter 22 Project management
Human needs hierarchy
72Chapter 22 Project management
Need satisfaction
 In software development groups, basic physiological and
safety needs are not an issue.
 Social
 Provide communal facilities;
 Allow informal communications e.g. via social networking
 Esteem
 Recognition of achievements;
 Appropriate rewards.
 Self-realization
 Training - people want to learn more;
 Responsibility.
73Chapter 22 Project management
Personality types
 Task-oriented.
 The motivation for doing the work is the work itself;
 Self-oriented.
 The work is a means to an end which is the achievement of
individual goals - e.g. to get rich, to play tennis, to travel etc.;
 Interaction-oriented
 The principal motivation is the presence and actions of
co-workers. People go to work because they like to go to
work.
 Individual motivations are made up of elements
of each class, where teamwork plays an essential role.
74Chapter 22 Project management
Teamwork
 Most software engineering is a group activity
 The development schedule for most non-trivial software projects
cannot be completed by one person working alone.
 A good group is cohesive and has a team spirit.
 In a cohesive group, members consider the group to be more
important than any individual in it.
 The advantages of a cohesive group are:
 Team members learn from each other and get to know each
other’s work; Inhibitions caused by ignorance are reduced.
 Knowledge is shared. Continuity can be maintained if a group
member leaves.
 Refactoring and continual improvement is encouraged. Group
members work collectively to deliver high quality results and fix
problems.
75Chapter 22 Project management
The effectiveness of a team
 The people in the group
 You need a mix of people in a project group as software
development involves diverse activities such as negotiating with
clients, programming, testingand documentation.
 The group organization
 A group should be organized so that individuals can contribute to
the best of their abilities and tasks can be completed as
expected.
 Technical and managerial communications
 Good communications between group members, and between
the software engineering team and other project stakeholders, is
essential.
Chapter 22 Project management 76
 Group size
 The larger the group, the harder it is for people to communicate
with other group members.
 Group structure
 Communication is better in informally structured groups than in
hierarchically structuredgroups.
 Group composition
 Communication is better when there are different personality
types in a group and when groups are mixed rather than single
sex.
 The physical work environment
 Good workplace organisation can help encourage
communications.
Group communications
77Chapter 22 Project management
Key points
 People are motivated by interaction with other people, the
recognition of management and their peers, and by being given
opportunities for personal development.
 Software development groups should be fairly small and cohesive.
The key factors that influence the effectiveness of a group are the
people in that group, the way that it is organized and the
communication between group members.
 Communications within a group are influenced by factors such as
the status of group members, the size of the group, the gender
composition of the group, personalities and available communication
channels.
Chapter 22 Project management 78