Software Development Management
Lecture 12
1Chapter 22 Project management
Topics covered
 Project management
 Project planning
 Risk management
 People management
 Tool support
2Chapter 22 Project management
Project Management
Lecture 12/Part 2
3Chapter 22 Project management
 Concerned with activities involved in ensuring
that software is delivered on time and on
schedule and in accordance with the organisations
developing and procuring the software.
 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.
Software project management
4Chapter 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
5Chapter 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
6Chapter 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.
7Chapter 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 8
Project Planning
Lecture 12/Part 3
9Chapter 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
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, which are not too small (about week or two).
 Organize tasks concurrently to make optimal use of workforce.
 Minimize task dependencies to avoid delays caused by one task
waiting for another to complete.
 Use graphical notation to visualise and manage project schedule.
Chapter 23 Project planning
Schedule representation – Gantt chart
Chapter 23 Project planning
Schedule representation – 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 often 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 with incremental delivery.
 Unlike in plan-driven approaches, the functionality of
these increments is not planned in advance but is
decided during the development.
 The customer’s priorities and requirements change so it
makes sense to have a flexible plan that can accommodate
these changes.
 While plan-driven approaches work with fixed
functionality and decide on the time plan accordingly,
agile approaches have fixed time plan (e.g. weekly
sprints) and decide on the functionality accordingly.
Chapter 23 Project planning
Software pricing
 Estimates are made to discover the cost, to the
developer company, of producing a software system.
 You take into account hardware, software, travel, training, effort
and other costs.
 Both fixed and variable costs need to be considered.
 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
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 in future 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.
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 is likely to be.
 Algorithmic cost assessment 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
individuallyand 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 assessment
 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 II 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 II (published in 2000).
 COCOMO II takes into account different approaches to
software development, reuse, etc.
 COCOMO II incorporates a range of sub-models that
produce increasingly detailed software estimates.
Chapter 23 Project planning
COCOMO II estimation models
Chapter 23 Project planning
COCOMO II factors
Chapter 23 Project planning
Ratings
CostDrivers Very Low Low Nominal High Very High Extra High
Product attributes
Required softwarereliability 0.75 0.88 1.00 1.15 1.40
Sizeof application database 0.94 1.00 1.08 1.16
Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65
Hardware attributes
Run-timeperformanceconstraints 1.00 1.11 1.30 1.66
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual machine environment 0.87 1.00 1.15 1.30
Required turnabouttime 0.87 1.00 1.07 1.15
Personnel attributes
Analystcapability 1.46 1.19 1.00 0.86 0.71
Applications experience 1.29 1.13 1.00 0.91 0.82
Softwareengineer capability 1.42 1.17 1.00 0.86 0.70
Virtualmachine experience 1.21 1.10 1.00 0.90
Programming languageexperience 1.14 1.07 1.00 0.95
Project attributes
Application of softwareengineering methods 1.24 1.10 1.00 0.91 0.82
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development schedule 1.23 1.08 1.00 1.04 1.10
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
30Chapter 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.
31Chapter 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 willnot 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.
32Chapter 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)
33Chapter 22 Project management
The risk management process
34Chapter 22 Project management
 Risk analysis
 Assess the likelihood and consequences of these risks;
 Risk planning
 Draw up plans to avoid or minimise the effects of the risk;
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 35
People Management
Lecture 12/Part 5
36Chapter 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).
39Chapter 22 Project management
Maslow's hierarchy of needs
40Chapter 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
41Chapter 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.
42Chapter 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.
43Chapter 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, testing and 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 44
 Group size
 The larger the group, the harder it is for people to communicate
with other group members.
 Group structure
 Communication is better in informallystructured 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
gender.
 The physical work environment
 Good workplace organisation can help encourage
communications.
Group communications
45Chapter 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 46
Tool Support
Lecture 12/Part 6
47Chapter 22 Project management
SE tasks commonly supported by tools
 Plan and schedule software development project
 Specify, manage and trace requirements
 Model and analyze business processes
 Create design and deployment models
 Create, edit, compile and debug code in different languages
 Generate and import database schema
 Track changes
 Manage tests
 Document software development
 Communicateand develop team based projects
48Chapter 7 Design and implementation
Most popular tools
 Requirements analysis and design modeling tools
 Programming environments that automate parts of
program construction processes (e.g., automated builds)
 Software configuration management and version control
 Testing tools including static and dynamic analysis tools
 Continuous integration and release management
 Issue tracking
 Project management tools
 Tool integration concepts and mechanisms
Chapter 4 Requirements engineering 49
Integrated development environments
(IDEs)
 Software development tools are often grouped to
create an integrated development environment (IDE).
 An IDE is a set of software tools that supports different
aspects of software development, within some common
framework and user interface.
 IDEs are created to support development in a specific
programming language such as Java. The language
IDE may be developed specially, or may be an
instantiation of a general-purpose IDE, with specific
language-support tools.
50Chapter 7 Design and implementation
Key points
 Software engineering process can be supported by a
large variety of tools.
 The specific tools are often integrated into a single
environment or framework, which assists the developers
through integrated support on one place.
Chapter 7 Design and implementation 51