Project Managementstaff.um.edu.mt/ecac1//files/cis3119-1.pdfconcepts of project planning and associated risk issues. In particular: •To make you aware that project planning is a

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


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


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


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


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


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


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


Slide 9 of 61

Tools

The Software Crisis

PROCESS

Q

+ Methods Q

Faculty of ICT


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


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


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


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


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


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


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


Slide 17 of 61

Phases and Life-Cycle

Testing

Requirements

Analysis

DesignImplementation

Feasibility

Maintenance

Faculty of ICT


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


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


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


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


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


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


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


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


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


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


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


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


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


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


Slide 32 of 61

Session Contents

• Management Responsibilities

• Typical project cycle

• Project Planning

• Risk management

Faculty of ICT


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


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


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


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


Slide 37 of 61


• 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


Slide 38 of 61


• 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


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


Slide 40 of 61

The Project Control Cycle

Collectingdata

Adapted from Hughes

Processingdata

Taking decisionsand making plans

Implementing

Definingobjectives

Modelling

Faculty of ICT


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


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


Slide 43 of 61

Other Project Plans

• Quality

• Configuration management

• Staff development

• Exception

• Maintenance

Faculty of ICT


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


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


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


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


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


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


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


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


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


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


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


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


Slide 56 of 61

Boehm’s Risk Management Breakdown

Also known as Boehm’s “Risk Engineering” model

Faculty of ICT


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


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


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


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


Documents

Project Managementstaff.um.edu.mt/ecac1//files/cis3119-1.pdfconcepts of project planning and associated risk issues. In particular: •To make you aware that project planning is a