Project Management
Software Engineering Management, Risk, Software quality assurance, Stochastic analysis, Reliability and availability
measurement, Algorithmic estimation techniques, Real-time systems.
This document © 2005-2018 Dr. Ernest Cachia
Faculty of ICT
CIS3119 – Software Engineering: Project Management
Ernest CachiaDepartment of Computer Information Systems
Slide 2 of 61
CSA3170 - Unit Aims
The intention of this study unit is to introduce students to thefundamental issues and techniques involved in the control andestimation of quality and complexity of industry-scale softwaredevelopment effort. This unit will also introduce some advancedtopics used in the modelling of reliability and availability as well asin the development of real-time systems.
The study unit will deal with both the human and the technicaldimension of software development and will include such issues asthe scope of management, the concept of team structure andculture, process control and measurement as well as resource andeffort estimation and quality assurance.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 3 of 61
Session 1
General Refresher and Introduction (slides 4 to 19)
This should serve as a general reminder of what you SHOULD alreadybe well aware of as well as informing you of what lies ahead.
STEP 1 of any management activity – KNOW WHAT YOU MANAGE!
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 4 of 61
In this session
The aim of this session is to refresh some Software Engineering knowledge, at the same time introducing you to the basic scope and underlying fundamental principles of software project management. In particular:
•To get you to recognise the need for management of any human activity that involves the construction of sophisticated, cost-effective solutions through the collaboration of individuals.
•To extend this to incorporate software projects
•To relate the software product to the software process
•To appreciate the particularities of software project management in the context of “traditional” management
•To isolate the criteria determining a software product and the requirements of a development process
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 5 of 61
Session Contents
• Modern software development
• What is a system and its development process
• Development phases and Software Development Life-Cycles (SDLCs)
• Aspects of management
• Project properties
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 6 of 61
Modern Software Development
• A very appropriate definition
“The multi-person construction of multi-version software” (Parnas, D. L., Software Conference, 1987)
• The final goal of software engineering can be seen as:
To be to build software systems of demonstrable high quality.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 7 of 61
Attributes of Sound Systems
Software solutions are made up of software systems, and a sound modern system is:
• Sophisticated• Structured hierarchically• Usefully observed at various levels of abstraction• Made up of recurring components in different
configurations• Not internally complex• Evolved from simpler versions• Effectively verified
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 8 of 61
An Unsustainable Situation
• On one hand…– People build software systems using no particular method– People build fragile software systems– People build inaccurate software systems– Software system development is expensive– Software system development requires considerable planning
and effort
• On the other hand…– Modern software systems are ever-increasing in sophistication– Demands on software systems is always rising– Software systems are what make a computing entity– People consciously or unconsciously rely on software for most of
their social activities
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 9 of 61
Tools
The Software Crisis
PROCESS
Q
+ Methods Q
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 10 of 61
The “Wrongness” of Our Ways
Unmanaged development is not effective for modern system development.
- No process control
- No product or process guarantees
- No true management
- No client confidence
- No process visibility / traceability
- No metrication
- No communication
no quality!
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 11 of 61
Phased Development
Monolithic process (?)No management potential!
Phased process
Phase “i” Phase “i+1” … Phase “n”
Milestone “i” Milestone “i+1” Milestone “n”
…
Structured & focused management
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 12 of 61
Breaking the Monolithic Model
• Done by introducing “steps” into the software development process.
• Steps in the development process are called “phases” (or “stages”).
• Phases must be self contained and pre-defined.
• Phases should decrease abstraction as they progress.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 13 of 61
A Software Development Phase
A software development phase:
• Is a delimited period of time within the process of development of a software system.
• Has a definite starting set of data and a definite set of results.
• Is based on the results set of earlier phases.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 14 of 61
Advantages of Phased Development
• Phased development
– Offers benchmarking
– Offers insight
– Offers mile-stoning niches
– Offers a documentation-building framework
– Offers a definite progression sequence
– Offers possibilities for prototyping
– Allows end-user and client participation
– Offers possibilities for better testing strategies
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 15 of 61
A Development Milestone
• A software development milestone is a scheduled event…– for which some project team member (or leader) is
accountable.
– is used to measure progress.
• A milestone typically includes:– a formal review.
– the issuance of documents.
– the delivery of a (sometimes intermediate) product.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 16 of 61
Typical Software Development Phases
InstallationRequirements
Analysis
Feasibility
Design
Implementation
Testing
Maintenance
Retirement
Statement
Elicitation
Strategy planning
Feasibility study
Detailed
System
Integration
Component
Support
Operations
Detailed
System
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 17 of 61
Phases and Life-Cycle
Testing
Requirements
Analysis
DesignImplementation
Feasibility
Maintenance
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 18 of 61
The Life-Cycle
As defined by the ANSI / IEEE Standard 729-1983
• A life-cycle…
– is a finite and definite period of time.
– starts when a software product is conceived.
– ends when the product is no longer available or effective for use.
• Any life-cycle is organised in, and by implication, composed of, phases
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 19 of 61
Main SDLC Types
Remember these?...
Development model definition (personal): A particular interaction configuration of development phases leading to a final software product.– Waterfall (and Enhanced Waterfall)– V-model– Evolutionary Prototyping (aka Incremental)– Throw-away Prototyping (aka Rapid)– Rapid Application Development (RAD) – leading to many agile
forms– Spiral– Reuse-oriented– Formal (aka Transformational)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 20 of 61
Management in General
These life-cycles do not “simply happen” or get used in the “right” way. They must be managed.
A possible (personal and informal) definition of management
The strategic deployment, organisation, monitoring and control of specific resources involved in a particular activity.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 21 of 61
Why Bother Managing?
Assumption 1: Resources can be used in any number of ways
Assumption 2: The way resources are used can impact positively or negatively on their efficiency
Assumption 3: The way resources are used is entirely dependant on the way they are managed
Therefore…
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 22 of 61
Concluding from previous
A planned, objective and scientific approach to resource management is of paramount importance for the success of human effort involving multiple resources and/or more
than one person.It is therefore understood that management entails great responsibility.
Misjudgements at this level can have dire and far-reaching repercussions.
Remember that…
Eagles may soar, but weasels don't get sucked into jet engines.
(quoted from John Benfield)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 23 of 61
What is to be Managed?
• This depends on the nature of what is being developed. Some examples:• Retail outlet: stock management, accounting, etc.
• Vehicle repair: job flow, stock management, etc.
• University: lecture management, staff activity, admin., etc.
• Hospital: doctor allocation, stock management, admin, etc.
In software development, projects are managed – hence the term “project management”.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 24 of 61
Project Management
• First of all, what is a project?In general a planned activity – however, this is a very subjective definition and requires further qualification
• We need to extract the main project properties to be able to understand the nature of a “project”.
• One should keep in mind that:1. All project properties are not necessarily present in every
project2. Project properties can themselves be graded (i.e. not
simply considered as a “toggle” value)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 25 of 61
Project Properties (1/2)
So, what makes a particular activity a project?
• Is made up of, or contains some, non-routine tasks
• Can include novel approaches and/or techniques
• Necessitates a degree of planning
• The work involved is phased
• Milestones, deliverables and timescales are set
throughout
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 26 of 61
Project Properties (2/2)
Some more project properties:
• The work involved is of a commissioned nature
• Amalgamates and brings to focus various specialities
and/or cultural backgrounds
• Work resources are pre-defined
• The work involved is large-scale and/or high-sophistication
[Some of this list is loosely adapted from Hughes & Cotterell]
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 27 of 61
Software Project Structure
Generic software project structure
Project
System 1 System 2 System n. . .
Sub-system 1 Sub-system 2 . . .
Module 1 Module 2
. . .
. . .
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 28 of 61
A s/w Project vs. any Project
• In the case of a s/w project…
– Progress is not always visible
– Abstraction plays a central and permeating role
– In terms of cost, s/w products are more complex than traditional ones
– Deals in subjectivity
– Have to contend with conflicting or ill-formed requirements
– Is always expected to accommodate the physical components of a system (i.e. is subject to change as per design)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 29 of 61
Summary (Session 1)
• Modern software development needs to be collaborative, transparent and manageable.
• A system provides a solution to a real-world issue, and is produced as a result of a project which, in turn, has distinguishing properties (most important of which is its sub-division into phases).
• Software Development Life-Cycles (SDLCs) are standardised roadmaps indicating how a project is to reach its goal. An SDLC is made up of phases.
• Management is not simply directing. There are many tasks associated with this generic activity.
• A software project is fundamentally different from a “traditional” project.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 30 of 61
Session 2
Project Management and Risk Issues
This session should serve as an eye-opener to the issues involved inmanaging software projects of certain calibre and the importance oftaking risk management seriously enough to plan, categorise andmitigate it.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 31 of 61
Session Aims
The aim of this session is to introduce you to some fundamental concepts of project planning and associated risk issues. In particular:
•To make you aware that project planning is a very crucial aspect of project management.
•To drive home the fact that planning will always entail a risk dimension.
•To make you appreciate, analyse and categorise software development risks.
•To acquaint you with risk mitigation.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 32 of 61
Session Contents
• Management Responsibilities
• Typical project cycle
• Project Planning
• Risk management
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 33 of 61
Activity 1
Carry out the activity from handout “CSA3170-A”(Use the criteria explained in slides 25 & 24 from session 1)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 34 of 61
Activity: “CSA3170-A”
(Adapted from Hughes)
Prioritise the following ten activities in order of merit of the description“project”. That is, arrange the list such that the activities you considermost worthy of the description “project” are at the top of the list in orderof merit. You should write down any reasons that may support yourordering.
• Amending a financial computer system to deal with the Euro
• Producing an edition of a newspaper
• Building the Channel Tunnel
• Getting married
• A research project into what makes a good Human Computer Interface
• An investigation into the reason why a user has a problem with a computer
• A first or second year programming assignment in a computing course
• Servicing a customer at a supermarket check-out point
• Writing an OS for a new computer
• Installing a new version of word-processor in an organisation
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 35 of 61
Manageable components of a s/w project
How do we do it?
Feasibilitystudy
PlanProject
execution
Is it worth doing?
Do it!
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 36 of 61
Management Responsibilities (1/3)
Nine responsibilities are identified (over the next 3 slides)
• Planning
Deciding what to do by defining tasks, milestones, products and meta-products
• Scheduling
Deciding when things happen by setting deadlines and sequences
• Monitoring
Checking on progress by maintaining watch on quality, timeliness, and cost
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 37 of 61
Management Responsibilities (2/3)
• DirectingIssuing instructions to guide development along agreed-upon lines and standards
• ControllingTaking action whenever necessary to correct what’s being monitored if it strays from the set parameters
• OrganisingMaking arrangements to organise available resources to promote efficient development
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 38 of 61
Management Responsibilities (3/3)
• StaffingPopulating project development by selecting appropriately qualified and suited people and delegating them to the right jobs
• InnovatingBeing able to “break the mould” whenever necessary to come up with new approaches and solutions
• RepresentingOffer good project Public Relations (PR), or maybe more precisely Client Relations (CR)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 39 of 61
Activity: “CSA3170-B”
(Adapted from Hughes)
Consider the following hypothetical scenario:
Joe Borg is the manager of a software development section. On Tuesday at 1000 hrs he and hisfellow section managers have a meeting with their group manager about the staffingrequirements for the coming year. Joe has already drafted a staff request document. Thisdocument is based on the work planned for his section for the next year. The document isdiscussed at the meeting. At 1400 hrs Joe has a meeting with his senior staff about an importantproject his section is undertaking. One of the programming staff has just had a road accident andwill be hospitalised for some time. It is decided that the project can be kept on schedule by somenifty rescheduling and by transferring another team member from less urgent work to thisproject. A temporary replacement is to be brought in to do the less urgent work, but this maytake a week or so to arrange. Joe has to phone both the personnel manager about getting areplacement and the client, for whom the less urgent work is being done, explaining why it islikely to be delayed.
Identify which of the nine management responsibilities (as discussed in the lecture slides) Joewas responding to at different points during his day. Not all the nine responsibilities arenecessarily included in the above scenario.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 40 of 61
The Project Control Cycle
Collectingdata
Adapted from Hughes
Processingdata
Taking decisionsand making plans
Implementing
Definingobjectives
Modelling
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 41 of 61
Project Planning, Scheduling and Control
Client
Management
Developers
products
reports
controls
statistics
analysis
pro
du
cts
requ
iremen
ts
con
du
ct
“meta” data
Software development is a set of technical activities which should be managed if they are to be effective.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 42 of 61
Project Planning
• Scope of project• Project estimates
• Effort• Cost• Time• Human resources
• Resource management• Risk analysis• Scheduling issues• Staff organisation
All the above should be continuously monitored because project information is constantly being received as development progresses.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 43 of 61
Other Project Plans
• Quality
• Configuration management
• Staff development
• Exception
• Maintenance
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 44 of 61
Quality Planning
In general: The setting of the stage to ensure that a standardised and quality-oriented approach to development is used throughout the organisation. Amongst other things, this plan should include:
– Reference to industry-wide standards (e.g. the ISO 9000 series)
– Management tasks and responsibilities
– Transparency (i.e. audits and visibility)
– Staff-orientation (i.e. training)
– Communication framework
– Risk management
– Inbuilt checking structure
– Documentation issues
– Development tools and methods
– Testing issues
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 45 of 61
Project Planning Techniques
• Option Analysis (Goal aspect)• Weighing various (sometime conflicting) goals against each other.
• Risk Management (Problem probability aspect)• Determining, analysing, planning for, and controlling unwanted
(detrimental) events.
• Milestone Setting (Product aspect)• Determination and setting of (meta) deliverables.
• Scheduling (Activity/Timing aspect)• Setting conditions for task activation and termination.
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 46 of 61
Risk Management
One must first understand:• What risk is
• How can one identify risk
• What types of risk are possible
• The likely sources of risk
• The likely effects of risk
• The probability and severity of a given risk
• Possible precautions and mitigating actions
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 47 of 61
Risk Dissection
• Risk identification− Define the risk
• Probability (chance) of occurrence− Subjective but can be based on solid experience
• Severity (developmental impact)− Should be clearly discernable and prognostic
• Manageable and mitigate-able− To what extent is it controllable?
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 48 of 61
Software Project Risk Types
Although risk will effect all aspects of software development, onemust determine the “point of first impact” of any particular risk.Knowing this will help create preventive measures where it matters.One can narrow the “point of first impact” for any softwaremanagement effort as follows:
• The product
• The project
• The business
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 49 of 61
Risk Classification
Risk type examples
• Changes in management: Project• Fluctuation of requirements: Project & Product• Staff movement: Project• Technology shifts: Business• Wrong usage or inadequacy of
modelling tools: Product• Hardware resource unavailable: Project• Competition: Business• Problems in specification chain: Project & Product
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 50 of 61
Time and Cost Overrun Risks
When a software project overruns its planned delivery timeand budget, this can usually be traced back to one of thefollowing reasons:
– Estimation inaccuracies (could be inherent in the methods used)
– Planning assumptions
– Unforeseen events
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 51 of 61
Estimation Inaccuracies
Estimation methods are exactly that – an estimation. Therefore,some lack of accuracy is inherent, indeed expected. Estimationtechniques are a typical “love-hate” fact associated with projectmanagement, in that:
Love them because…• It is a forecasting tool, hence indispensible• Can work at various levels of abstraction, hence refine-able• Can be rendered more accurate by incorporating experience and
historical data
Hate them because…• Can rely on some subjective data at times• Can take on an idealistic (naïve) outlook• It can be frustrating in their data requirements
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 52 of 61
Typical Project Planning Misjudgements
• Over optimistic schedule
• Stakeholder unavailability
• Resource unavailability
• Weak monitoring
• Taking a “for obvious” stance to expertise
• Letting personal views effect objectivity
• Staff augmentation (especially on an already late project)
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 53 of 61
Sources of Software Project Risks (1/2)
• Generic
– Applicable and common to all types of software project, butmight provide different levels of accuracy across projects ofdifferent type
• Specific
– Applicable and more appropriate to specific types of project,but will require closer involvement by project team members
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 54 of 61
Sources of Software Project Risks (2/2)
Whatever the type of risks being considered, the following are a listof the main risk categories that are to be considered (adapted from a
generic list in Hughes):
• The nature of the application being built
• Staff morale, skills, experience, motivation and availability
• Project culture and procedure/methods
• Hardware and platform/OS requirements
• Implementation and changeover issues
• Third-party dependency
• Real-world requirement shift
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 55 of 61
Traditional Software Engineering Risks (Boehm, 1989)
• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing the wrong software functions
• Developing the wrong user interface
• Gold plating
• Continuing stream of requirements
• Shortfalls in externally furnished components and tasks
• Real-time performance shortfalls
• Straining computer science capabilities
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 56 of 61
Boehm’s Risk Management Breakdown
Also known as Boehm’s “Risk Engineering” model
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 57 of 61
Risk Exposure
The importance attached to a particular risk is known as riskexposure (RE). This is calculated as follows:
Risk exposure (RE) = risk probability x risk impact
Units: €/£/$/… <none> €/£/$/…
or 1 .. 10 <none> 1 .. 10
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 58 of 61
Risk Reduction Leverage
A measure of the balance between the perceived benefits ofreducing (or removing) a risk and the cost of doing so, calledthe risk reduction cost (RRC), is called the risk reductionleverage (RRL). This can be calculated as follows:
RRL = (REbefore – REafter) / RRC
All units are monetary
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 59 of 61
Risk Control and Mitigation
Finally, one should be aware of the five techniques that are commonly used to reduce/control risk should they occur.
• Hazard preventionThe removal or rendering to insignificance the possibility of particular hazards ever arising
• Likelihood reductionTaking every precaution to ensure that the chance of a negative event happening is the least possible
• Risk avoidanceTaking measures to ensure that the risk is not encountered in the first place
• Risk transferThe movement of a particular risk factor to other (non-project) entities
• Contingency planningWhat to do when the unavoidable (and some things are) happens!
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems
Slide 60 of 61
Summary (Session 2)
• The various responsibilities (nine in all)
• The steps a typical project goes through in a real-world context
• Risk management: Its understanding, analysis, classification and avoidance or mitigation
Faculty of ICT
Ernest CachiaDepartment of Computer Information Systems