Software Project Management: Understanding Risks and Risk Management, Essays (university) of Software Project Management

Download Software Project Management: Understanding Risks and Risk Management and more Essays (university) Software Project Management in PDF only on Docsity!

1

An Introduction

Chapter 1

Software Project

Management

Presented By Laxminath Tripathy

Robert Hughes and Mike Cotterell

L.N.Tripathy

In this introduction the main questions to be addressed will be:

 What is software project management? Is it really different from ‘ordinary’ project management?

 How do you know when a project has been successful? For example, do the expectations of the customer/client match those of the developers?

Some dictionary definitions:

“A specific plan or design”

“A planned undertaking”

“A large undertaking e.g. a public works scheme” Longmans dictionary

Key points above are planning and size of task

‘Jobs’ – repetition of very well-defined and well understood tasks with very little uncertainty

‘Exploration’ – e.g. finding a cure for cancer: the outcome is very uncertain

‘Projects’ – in the middle! 4

A task is more ‘project-like’ if it is:

 Non-routine

 Planned

 Aiming at a specific target

 Work carried out for a customer

 Involving several specialisms

 Made up of several different phases

 Constrained by time and resources

 Large and/or complex

Not really! …but…

 Invisibility

 Complexity

 Conformity

 Flexibility

make software more problematic to build than other engineered artefacts.

Feasibility study Is project technically feasible and worthwhile from a business point of view? Planning Only done if project is feasible Execution Implement plan, but plan may be changed as we go along 7

8

Requirements analysis

 Requirements elicitation: what does the client need?  Analysis: converting ‘customer-facing’ requirements into equivalents that developers can understand  Requirements will cover  Functions  Quality  Resource constraints i.e. costs

 Architecture design  Based on system requirements  Defines components of system: hardware, software, organizational  Software requirements will come out of this

 Code and test  Of individual components

 Integration  Putting the components together

 Qualification testing  Testing the system (not just the software )

 Installation  The process of making the system operational  Includes setting up standing data, setting system parameters, installing on operational hardware platforms, user training etc

 Acceptance support  Including maintenance and enhancement

Distinguishing different types of project is important as different types of task need different project approaches e.g.

 Information systems versus embedded systems

 Objective-based versus product-based

This involves the following activities:

 Planning – deciding what is to be done

 Organizing – making arrangements

 Staffing – selecting the right people for the job

 Directing – giving instructions

continued…

 Monitoring – checking on progress

 Controlling – taking action to remedy hold-ups

 Innovating – coming up with solutions when

problems emerge

 Representing – liaising with clients, users,

developers and other stakeholders

 Answering the question ‘ What do we have to do to have a success?’

 Need for a project authority  Sets the project scope  Allocates/approves costs

 Could be one person - or a group  Project Board  Project Management Board  Steering committee

Informally , the objective of a project can be

defined by completing the statement:

The project will be regarded as a success if………………………………..

Rather like post-conditions for the project

Focus on what will be put in place, rather than

how activities will be carried out

S – specific, that is, concrete and well-defined

M – measurable, that is, satisfaction of the objective can be objectively judged

A – achievable, that is, it is within the power of the individual or group concerned to meet the target

R – relevant, the objective must relevant to the true purpose of the project

T – time constrained: there is defined point in time by which the objective should be achieved

These are steps along the way to achieving the

objective. Informally, these can be defined by

completing the sentence…

Objective X will be achieved IF the following goals are all achieved A…………… B…………… C…………… etc

Often a goal can be allocated to an individual. Individual may have the capability of achieving goal, but not the objective on their own e.g.

Objective – user satisfaction with software product

Analyst goal – accurate requirements

Developer goal – software that is reliable

How do we know that the goal or objective has been achieved? By a practical test, that can be objectively assessed.

e.g. for user satisfaction with software product:

 Repeat business – they buy further products from us

 Number of complaints – if low etc etc

These are people who have a stake or interest in the project In general, they could be users/clients or developers/implementers

They could be:

 Within the project team

 Outside the project team, but within the same organization

 Outside both the project team and the organization

Benefits of delivered project must outweigh costs

Costs include:

• Development
• Operation

Benefits

• Quantifiable
• Non-quantifiable

22

£

£

Benefits

Costs

L.N.Tripathy

 Initiating

 Planning

 Executing

 Monitoring & Control

 Change Control

 Closing

 Cash Flow Forecasting (to secure funding)

 Net Profit

 Payback Period

 Return On Investment (ROI) - (Average annual profit/total investment*100)

 Net Present Value (NPV)  NPV = sum(PV)  PV(t) = value in year t/(1+r) exp(t)

 Internal Rate of Return (IRR) – The percentage discount that will zero the NPV

 ‘Cash-flow’ is value of income less outgoing

 Net profit value of all the cash-flows for the lifetime of the application

 Year 0’ represents all the costs before system is operation