Software Project Management

Why is SPM important?

◻ Unfortunately, projects are not always successful

◻ Standish Group in the U.S. analyzed 13,522 projects and

concluded that only a third of them were successful; 82
percent were late and 43 percent exceeded their budget

◻ The reason for these project shortcomings is often the

management of projects.
What is a project?
◻ In dictionary definition, it emphases on
-----Being planned activity
◻ Routine: one knows exactly what to do

◻ Exploratory: full of uncertainties and risks

What is a project?
◻ The characteristics distinguish projects:
◻ non-routine tasks are involved;

◻ planning is required;

◻ specific objectives are to be met or a specified product is

to be created;
◻ the project has a predetermined time span;

◻ work is carried out for someone other than yourself;

..contd
◻ work involves several specialism;
◻ people are formed into a temporary work group to carry
out the task ;
◻ work is carried out in several phases;
◻ the resources that are available for use on the project are
constrained;
◻ the project is large or complex
Project Constraints
◻ Scope:
◻ What work will be done as part of the project
◻ What unique product, service, or result does the customer or sponsor
expect from the project
◻ Time
◻ How long should it take to complete the project
◻ Who can approve changes to the schedule
◻ Cost
◻ What is the project’s budget
◻ Who can authorize changes to the budget
Software prj vs. other types of prj
◻ Invisibility: With software, progress is not immediately visible

◻ Complexity: Per dollar, software products contain more complexity than

other engineered artefacts

◻ Conformity: Software developers have to conform to the requirements of

human clients

◻ Flexibility: Software systems are particularly subject to change

Contract management and technical project management.
◻ Client organization will appoint a project manager
◻ Project manager will not worry about estimating the effort needed to write
individual software components as long as overall project is within budget
and on time.
Activities covered by SPM
◻ A software project is not only concerned with the actual writing of
software. In fact, where a software application is bought in “of the shelf”,
there may be no software writing as such, but this is still fundamentally a
software project because so many of the other activities associated with
software will still be present.

Three successive processes

Activities covered by SPM
◻ The feasibility study: assesses whether a project is worth
starting – that it has a valid business case

◻ Planning: If the feasibility study indicates that the

prospective project appears viable, then project planning can
start

◻ Project execution: The execution of a project often contains

design and implementation sub-phases.
..contd
◻ Design is making decisions about the form of the products to
be created

◻ Planning details the activities to be carried out to create

these products

■ E.g., Activities recommended in the international

standard ISO 12207
Plans, methods and methodologies
◻ Activity: test a component
◻ Methods: Real activates:

✔ Analyze the requirements

✔ Devise and write test cases ✔ Its start and end dates
✔ Create test scripts and a plan ✔ Who will carry it out
expected results ✔ What tools and materials
✔ Compare the actual results
and the expected ones

◻ A plan takes the method and convert it to real activities,

identifying for each activity
◻ Groups of methods or techniques are often grouped into
methodologies such as object-oriented design
Some ways of categorizing
software projects
◻ Compulsory vs. voluntary users
◻ Supermarket transaction system vs. computer game

◻ Information systems vs. embedded systems

◻ Office system vs. machine control system

◻ Objectives vs. products

◻ to meet certain objectives vs. to produce a product (course management
system vs. anti-virus system)
Stakeholders
The people who have a stake or interest in the project

◻ Internal to the project team

◻ External to the project team but within the same organization
◻ External to both the project team and the organization
◻ Identify them early for setting up better communication channels
Setting objectives
◻ Objectives focus on the desired outcomes of the project
rather than the task within it.
◻ SMART principles
◻ Specific: Effective objectives are concrete and well defined
◻ Measurable: measures of effectiveness which tell us how
successful the project has been
◻ Achievable: within the power of the individual or group
◻ Relevant: must be relevant to the true purpose of the project
◻ Time constrained: should be a defined point in time by which the
objective should have been achieved
Project success and failure
◻ The project plan should be designed to ensure project
success
◻ Project success can usually be summarized and delivering:
◻ the agreed functionality

◻ To the required level of quality

◻ on time

◻ within budget

◻ Project success vs. business success

What is management
◻ Management involves the following activities:

◻ planning – deciding what is to be done;

◻ organizing – making arrangement;

◻ staffing – selecting the right people for the job;

◻ directing – giving instructions;

..contd
◻ monitoring – checking on progress;

◻ controlling – taking action to remedy hold-ups;

◻ innovating – coming up with new solutions;

◻ representing- liaising with clients, users, developer,

suppliers and other stakeholders
Management control
◻ Management, in general,
involves setting objectives
for a system and then
monitoring the
performance of the system

◻ Figure: The project

control cycle
Advantages
◻ Using project management techniques provides
advantages, such as

■ Better control of financial, physical, and human

resources

■ Improved customer relations

■ Shorter development times

■ Lower costs and improved productivity

..contd
■ Higher quality and increased reliability

■ Higher profit margins

■ Better internal coordination

■ Positive impact on meeting strategic goal

■ Higher worker morale

Management control
◻ Management, in general, involves setting objectives for a
system and then monitoring the performance of the system

■ This will involve the local managers in data collection

■ Data processing will be needed to transform this raw
data into useful information
◻ Figure The project
control cycle
Selection of an appropriate project
approach
◻ The development of software in-house usually means that:

◻ the developers and the users belong to the same organization

◻ the application will slot into a portfolio of existing computer-
based systems;
Selection of an appropriate project
approach
◻ The methodologies and technologies are largely dictated by
organizational standards and policies, including the existing
enterprise architecture

◻ Technical planning (project analysis): the decision process of

reviewing the methodologies and technologies to be used for
each individual project
Build or buy?
◻ Software development can be seen from two differing
viewpoints:
◻ from the developers
◻ from the clients or user
◻ With in-house development, the developers and the users are
in the same organization
◻ Where the development is outsourced, they are in different
organizations. In these days of global system development,
the different organizations could be on different continents
Build or buy?
◻ Contracting the project out to an external IT development
company may be attractive in circumstances where there is a
lack of technical staff to lead the effort of developing a new
IT effort
◻ Fig Project Analysis is the subject of Step3
Build or buy?
◻ Advantages of off the shelf software:

◻ the supplier of the application can spread the cost of

development over a large number of customers and thus the
cost per customer should be reduced;

◻ The software already exists and so

◻ it can be examined and perhaps even trialled before
acquisition,
Build or buy?
◻ There is no delay while the software is being built;

◻ Where lots of people have already used the software,

most of the bugs are likely to have been reported and
removed, leading to more reliable software
Build or buy?
◻ Disadvantages of off the shelf software
◻ As you have the same application as everyone else, there is
no competitive advantage

◻ Modern off-the-shelf software tends to be very customizable:

the characteristics of the application can be changed by
means of various parameter tables

◻ However, this flexibility has limits and you may end up

having to. change your office procedures in order to fit in
with the computer system
Build or buy?
◻ You will not own the software code. This may rule out
making modifications to the application in response to
changes in the organization or its environment

◻ Once you have acquired your off-the-shelf system, your

organization may come to be very reliant upon it. This may
create a considerable barrier to moving to a different
application

◻ The supplier may be in a position to charge inflated licence

fees because you are effectively a captive customer
Choosing methodologies and
technologies
◻ Methodologies
◻ A collection of methods Techniques and methods are sometimes
distinguished

◻ Techniques tend to involve the application of scientific,

mathematical or logical principles to resolve a particular kind
of problem. They often require the practice of particular
personal skills – software design
Choosing methodologies and
technologies
◻ Methodologies include approaches like the Unified
Software Development Process (USDPl, Structured
Systems Analysis and Design Method (SSADM) and
Human Centred Design, while technologies might
include appropriate application-building and automated
testing environments
Choosing methodologies and
technologies
◻ The analysis identifies the methodology, but also selects the
methods within the methodology that are to be deployed

◻ As well as the products and activities, the chosen methods

and technologies will affect the training requirements for
development staff

◻ the types of staff to be recruited;

◻ the development environment- both hardware and
software;
◻ system maintenance arrangements.
Identify project as either
objective-driven or product-driven

◻ A product-driven project
creates products defined
before the start of the
project

◻ An objective-driven
product will often have
come first which will have
defined the general
software solution that is to
be implemented
Identify project as either
objective-driven or product-driven
◻ Analyse other project characteristics

◻ The following questions can be usefully asked:

◻ Is a data-oriented or process-oriented system to be
implemented?
◻ Data-oriented systems generally mean information
systems that will have a substantial database
◻ Process-oriented systems refer to embedded control
systems
Identify project as either
objective-driven or product-driven
◻ Will the software that is to be produced be a general tool or
application specific?

◻ An example of a general tool would be a spread sheet or a

word processing package
◻ An application-specific package could be, for example, an
airline seat reservation system
Identify project as either
objective-driven or product-driven
◻ Select general life-cycle approach

◻ Control systems; A real-time system will need to be

implemented _using an appropriate methodology. Real-time
systems that employ concurrent processing may have to use
techniques such as Petri nets
Identify project as either
objective-driven or product-driven
◻ Information systems; Similarly, an information system will
need a methodology, such as SSADM or Information
Engineering, that matches that type of environment

◻ SSADM would be especially appropriate where the project

employs a large number of development staff whose work
will need to be coordinated: the method lays down in detail
the activities and products needed at each step. Team
members would therefore know exactly what is expected
Identify project as either
objective-driven or product-driven
◻ Availability of users

■ Where the software is for the general market rather than

application and user specific, then a methodology witch
assumes that identifiable users exist who can be quizzed about
their needs would have to be thought about with caution

■ Some business systems development methods assume an

existing clerical system which can be analysed to yield the
logical features of a new, computer-based, system. In these
cases a marketing specialists may act as a surrogate user
Identify project as either
objective-driven or product-driven
◻ Specialized techniques

■ For example, expert system sells and logic-based programming

languages have been invented to expedite the development of
knowledge-based systems

■ Similarly, a number of specialized techniques and standard

components are available to assist in the development of
graphics-based systems
Identify project as either
objective-driven or product-driven
◻ Hardware environment

■ The environment in which the system is to operate could put

constraints on the way it is to be implemented

■ The need for a fast response lime or restricted computer

memory might mean that only low-level programming
languages can be used
Identify project as either
objective-driven or product-driven
◻ Safety-critical systems

■ Where safety and reliability are essential: this might justify the
additional expense of a formal specification using a notation
such as OCL

■ Extremely critical systems could justify the cost of having

independent teams develop parallel systems with the same
functionality. The operational systems can then run concurrently
with continuous cross-checking
Identify project as either
objective-driven or product-driven
◻ Imprecise requirements

◻ Uncertainties or a novel hardware/software platform mean

that a prototyping approach should be considered
◻ If the environment in which the system is to be implemented
IS a rapidly changing one, then serious consideration would
need to be given to incremental delivery
◻ If the users have uncertain objectives in connection with the
project, then a soft systems approach might be desirable
Choice of process models
◻ In order to achieve an outcome, the system will have to execute
one or more activities: this is its process

◻ In the development of computer-based applications a number of

interrelated activities have to be undertaken to create a final
product

◻ These activities can be organized in different ways and we can

call these process models
Structure versus speed of
delivery
◻ The OO approach is included as a structured method

◻ Structured methods consist of sets of steps and rules which,

when applied, generate system products such as use case
diagrams

◻ The pay-off, it is hoped, is a less error prone and more

maintainable final system
Structure versus speed of
delivery
◻ This balance of costs and benefits is more likely to be justified
on a large project involving many developers and users

◻ Because of the additional effort needed and their greater

applicability to large and complex projects, these are often
called heavyweight methods
The waterfall model
The waterfall model
◻ There is a sequence of activities working from top to bottom

◻ The arrows pointing upwards and backwards indicate that a

later stage may reveal the need for some extra work at an earlier
stage, but this should definitely be the exception rather than the
rule

◻ The flow of the waterfall model should be downwards with the

possibility of just a little splash back
The spiral model
◻ Another way at looking at the waterfall model

◻ A greater level of detail is considered at each stage of the

project and a greater degree of confidence about the probability
of success for the project should be justified

◻ This can be portrayed as a loop or a spiral where the system to

be implemented is considered in more detail in each sweep
Software prototyping
◻ A prototype is a working model of one or more aspects of the
projected system that is constructed and tested quickly and
inexpensively in order to test out assumptions

◻ Prototypes can be classified as throw-away or evolutionary

Software prototyping
◻ Throw-away prototypes The prototype tests out some ideas and
is then discarded when the true development of the operational
system is commenced

◻ Evolutionary prototypes The prototype is developed and

modified until is finally in a state where it can become the
operational system
Software prototyping
◻ Reasons for prototyping

◻ Learn by doing, being able to look back on a task and see

where mistakes have been made

◻ Improved Communication, users do not get a feel for how the

system is likely to work in practice from a specification
Software prototyping
◻ Improved user involvement, the users can be more actively
involved in design decisions

◻ Demonstration of the consistency and completeness of a

specification, Any mechanism that attempts to implement a
specification on a computer is likely to uncover ambiguities and
omissions
Software prototyping
◻ Reduced need for documentation, because a working prototype
can be examined there is less need for detailed documentation
of requirements

◻ Reduced maintenance costs, if the user is unable to suggest

modifications at the prototyping stage they are more likely to
ask for changes to the operational system
Software prototyping
◻ Drawbacks and Dangers of prototyping

◻ Users can misunderstand the role of the prototype For example,

they might expect the prototype to have as stringent input
validation or as fast a response as the operational system,
although this was not intended.
Other ways of categorizing
prototypes
◻ What is being learnt?

◻ The most important reason for having a prototype is that there

is a need to learn about an area of uncertainty

◻ For any prototype it is essential that the project managers define

at the outset what it is intended to learn from the prototype
Other ways of categorizing
prototypes
◻ Students often realize that the software that they are to write as
part of their project could not safely be used by real users. They
therefore call the software a 'prototype'. However, if it is a real
prototype then they must:

◻ specify what they hope to learn from the prototype;

◻ plan how the prototype is to be evaluated;
◻ report on what has actually been learnt.
Other ways of categorizing
prototypes
◻ To what extent is the prototyping to be done?

◻ Simulated interaction For example, the user can type in a

request to access a record and the system will respond by
showing the details of a record, but the details shown are
always the same and no access is made to a database

◻ Partial working model:

◻ vertical - some features are prototyped fully
◻ horizontal - all features are prototyped but not in detail (for example,
there might not be a full validation of input).
Other ways of categorizing
prototypes
◻ What is being prototyped?

◻ The human-computer interface With information systems, what

the system is to do has usually been established and agreed by
management at a fairly early stage in the development of the
system

◻ Prototyping tends to be confined to establishing the precise way

in which the operators are to interact with the system. In this
case, it is important that the physical vehicle for the prototype
be as similar as possible to the operational system
Other ways of categorizing
prototypes
◻ At what stage of a system development project would a
prototype be useful as a means of reducing the following
uncertainties?

◻ There is a proposal that the senior managers of an insurance

company have personal access to management information
through an executive information system installed on
personal computers located on their desks

◻ Such a system would be costly to set up and there is some

doubt about whether the managers would actually use the
system.
Other ways of categorizing
prototypes
◻ Controlling changes during prototyping

◻ One approach has been to categorize changes as belonging to

one of three types:

◻ Cosmetic
◻ Local
◻ Global
Incremental Delivery
◻ The approach Engineering Management involves breaking the
system down into small components which are
then implemented and delivered in sequence

◻ Each component that is delivered must give some benefit to the

user

◻ Figure below gives a general idea of the approach

◻ Figure below gives a general idea of the approach
Incremental Delivery
◻ Advantages of this approach
◻ These are some of the justifications given for the approach:

◻ the feedback from early increments can influence the later stages;

◻ the possibility of changes in requirements is not so great as with large

monolithic projects because of the shorter timespan between the
design of a component and its delivery;
Incremental Delivery
◻ users get benefits earlier than with a conventional approach;

◻ early delivery of some useful components improves cash flow,

because you get some return on investment early on; smaller
sub-projects are easier to control and manage;

◻ the project can be temporarily abandoned if more urgent work

crops up;

◻ job satisfaction is increased for developers who see their

labours bearing fruit at regular, short, intervals
Incremental Delivery
◻ Disadvantages

◻ On the other hand these disadvantages have been put forward:

◻ 'software breakage', that is, later increments might require the earlier
increments to be modified;
◻ developers might be more productive working on one large system
than on a series of smaller ones
Incremental Delivery
◻ The incremental delivery plan

◻ The content of each increment and the order in which the increments
are to be delivered to the users of the system have to be planned at the
outset

◻ Basically the same process has to be undertaken as in strategic

planning but at a more detailed level where the attention is given to
increments of a user application rather than whole applications

◻ The elements of the incremental plan are the system objectives,

incremental plan and the open technology plan.
Incremental Delivery
◻ Identify system objectives

◻ The purpose is to give an idea of the 'big picture', that is, the
overall objectives that the system is to achieve. These can
then expanded into more specific functional goals and
quality goals. Functional goals will include:

◻ objectives it is intended to achieve;

◻ computer/non-computer functions to achieve them
Incremental Delivery
◻ Having defined the overall objectives, the next stage is to plan the
increments using the following guidelines:

◻ steps typically should consist of 1 % to 5% of the total project;

◻ non-computer steps may be included - but these must deliver benefits

directly to the users;
Incremental Delivery
◻ Ideally, an increment should take one month or less and should never
take more than three months;

◻ each increment should deliver some benefit to the user;

◻ some increments will be physically dependent on others;
◻ value-to-cost ratios may be used to decide priorities (see below)
Incremental Delivery
◻ The value to cost ratio = V/C where V is a score 1-10 representing value
to customer and C is a score 0-10 representing cost
Incremental Delivery
◻ Create open technology plan

◻ If the system is to be able to cope with new components being

continually added then it has to be built so that it is extendible, portable
and maintainable

◻ As a minimum this will require the use of:

◻ a standard high level language;
◻ a standard operating system;
Incremental Delivery
◻ variable parameters, for example, items such as organization name,
department names and charge rates are held in a parameter file that can
be amended without programmer intervention;

◻ a standard database management system

◻ These are all things that might be expected as a matter of course in a

modern IS development environment
Agile Methods
◻ “We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:

◻ Individuals and interactions over processes and tools

◻ Working software over comprehensive documentation
◻ Customer collaboration over contract negotiation
◻ Responding to change over following a plan That is, while there is
value in the items on the right, we value the items on the left more.”
Agile Methods
◻ Underlying Assumptions for Agile SW Development

◻ “Different projects need different processes or methodologies”

◻ “Focussing on skills, communication and community allows the project

to be more effective and more agile than focussing on process”
Atern/Dynamic Systems
Development Method
◻ DSDM is a framework that is made up of eight principles, a lifecycle and
products, roles and responsibilities and several best practice techniques

◻ These underpin and support a philosophy of delivering strategically

aligned business benefits as early as possible to give an organisation the
best possible return on investment (ROI)

◻ DSDM’s heritage along with most of agile is founded in I.T. but over the
last decade the agile arena has moved on and agile is no longer seen as
the preserve of I.T. although, unlike DSDM, many agile concepts and
approaches are only focussed on I.T
Atern/Dynamic Systems
Development Method
◻ The Eight Principles of DSDM

◻ Focus on the business need

◻ Deliver on time
◻ Collaborate
◻ Never compromise quality
◻ Build incrementally from firm foundation
◻ Develop iteratively
◻ Communicate continuously and clearly
◻ Demonstrate control
Atern/Dynamic Systems
Development Method
◻ The Structure of an Atern Project

◻ Atern differs from more common agile approaches as it encompasses

the entire project lifecycle and not just software development (where
Scrum prevails)

◻ It incorporates project management disciplines and provides

mechanisms to ensure that the project benefits are clear, the proposed
solution is feasible and there are solid foundations in place before
detailed work is started

◻ There are seven phases to an Atern project

Extreme Programming
◻ Extreme Programming (XP) is an agile software development
framework that aims to produce higher quality software, and higher
quality of life for the development team

◻ XP is the most specific of the agile frameworks regarding appropriate

engineering practices for software development
Extreme Programming
◻ Values
◻ The five values of XP are communication, simplicity,
feedback, courage, and respect and are described in more
detail below
◻ Communication
◻ Software development is inherently a team sport that relies
on communication to transfer knowledge from one team
member to everyone else on the team
◻ XP stresses the importance of the appropriate kind of
communication – face to face discussion with the aid of a
white board or other drawing mechanism.
Extreme Programming
◻ Simplicity
◻ Simplicity means “what is the simplest thing that will work?”

◻ The purpose of this is to avoid waste and do only absolutely

necessary things such as keep the design of the system as
simple as possible so that it is easier to maintain, support,
and revise. Simplicity also means address only the
requirements that you know about; don’t try to predict the
future
Extreme Programming
◻ Feedback
◻ Through constant feedback about their previous efforts,
teams can identify areas for improvement and revise their
practices. Feedback also supports simple design

◻ Your team builds something, gathers feedback on your

design and implementation, and then adjust your product
going forward
Extreme Programming
◻ Courage
◻ Kent Beck defined courage as “effective action in the face of
fear” (Extreme Programming Explained P. 20). This
definition shows a preference for action based on other
principles so that the results aren’t harmful to the team
◻ You need courage to raise organizational issues that reduce
your team’s effectiveness
◻ You need courage to stop doing something that doesn’t
work and try something else. You need courage to accept
and act on feedback, even when it’s difficult to accept
Extreme Programming
◻ Respect
◻ The members of your team need to respect each other in
order to communicate with each other, provide and accept
feedback that honour's your relationship, and to work
together to identify simple designs and solutions
Extreme Programming
◻ Practices
◻ The core of XP is the interconnected set of software
development practices listed below

◻ While it is possible to do these practices in isolation, many

teams have found some practices reinforce the others and
should be done in conjunction to fully eliminate the risks you
often face in software development
Extreme Programming
◻ The Planning Game
◻ Small Releases
◻ Metaphor
◻ Simple Design
◻ Testing
◻ Refactoring
◻ Pair Programming
◻ Collective Ownership
◻ Continuous Integration
◻ 40-hour week
◻ On-site Customer
◻ Coding Standard
Managing Iterative Process
◻ Like software development, project planning requires an iterative
process. Like software, a plan is an intangible piece of intellectual
property to which all the same concepts must be applied

◻ Plans have an engineering stage, during which the plan is developed,

and a production stage, when the plan is executed. Plans must evolve
as the understanding evolves of the problem space and the solution
space
Managing Iterative Process
◻ Key Points

◻ Projects can underplan and they can overplan. Once again, balance is
paramount in the level of planning detail and the buy-in among
stakeholders

◻ The work breakdown structure is the "architecture" of the project

plan. It must encapsulate change and evolve with the appropriate
level of detail throughout the life cycle

◻ Cost and schedule budgets should be estimated using microanalysis

techniques (top-down project level) and microanalysis techniques
(bottom-up task level) to achieve predictable results
Selecting the most appropriate
process model
◻ Euro method distinguishes between the construction of an application
and its installation. It is possible to use different approaches for these
two stages. For example, an application could be constructed using a
one-shot strategy but then be released to its users in increments

◻ The only combinations of construction and installation strategies that

are not feasible are evolutionary installation with any other
construction approach than evolutionary
Selecting the most appropriate
process model
◻ In general, Euro method suggests that where uncertainty is high then
an evolutionary approach is to be favoured. An example of
uncertainty would be where the users' requirements are not clearly
defined

◻ Where the requirements are relatively certain but there are many
complexities, for example, where there is a large embedded system
that is going to need a large amount of code, then an incremental
approach might be favoured
Selecting the most appropriate
process model
◻ Where deadlines are tight, then either an evolutionary or an
incremental approach is favoured over a one-shot strategy, as both
tactics should allow at least something to be delivered at the deadline,
even if it is not all that was originally promised. Students about to
plan final year projects would do well to note this