SPM Lecture Notes UNIT I

Software Project Management

Software Project Management

Lecture Notes

Lecture Notes

UNIT-I

UNIT-I

Introduction and Software Project Planning

Introduction and Software Project Planning

For For

Third Year Students MCA Third Year Students MCA

1.

1. PlanningPlanning –– deciding what to do deciding what to do 2.

2. OrganizingOrganizing –– making arrangements making arrangements 3.

3. StaffingStaffing –– selecting the right people for the job etc. selecting the right people for the job etc. 4.

4. DirectingDirecting –– giving instructions giving instructions 5.

5. MonitoringMonitoring –– checking on progress checking on progress 6.

6. ControllingControlling –– taking action to remedy hold-ups taking action to remedy hold-ups Innovating

Innovating –– coming up with new solutions coming up with new solutions Representing

Representing –– liaising with clients, users, developer, suppliers and other stakeholders. liaising with clients, users, developer, suppliers and other stakeholders.

Fundamentals of Software Project Management:

Fundamentals of Software Project Management:

Elements of Management

Elements of Management

7. 7. 8. 8.

What is Software

What is Software

: Software is a general term for the various kinds of : Software is a general term for the various kinds of  programs programs used to used to operate

operate computers computers and related devices. and related devices. OR

OR

Software means

Software means computer computer  instructions instructions or or  data  data .. Anything that can be Anything that can be stored stored electronically iselectronically is software, in contrast to

software, in contrast to storage storage devices devices and display devices which are calledand display devices which are called hardware. hardware.

A unique process, consisting of a set of coordinated and controlled activities with start and finish dates, A unique process, consisting of a set of coordinated and controlled activities with start and finish dates, undertaken to achieve an objective conforming to specific requirements including constraints of time, undertaken to achieve an objective conforming to specific requirements including constraints of time, cost and resources

cost and resources

What is a Project

‘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!

Are software  projects really different from other projects?

Not really! …but…

• Invisibility

• Complexity

• Conformity

• Flexibility

make software more problematic to build than other engineered artefacts.

Is project technically feasible and worthwhile from a business point of view?

Jobs versus projects

Software projects vs. other type of project

Activities covered by project management

Feasibility study Planning

 –  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

The software development life-cycle ISO 12207)

ISO 12207 life-cycle

 –  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

A traditional distinction has been between information system which enable staff to carry out office process and embedded system which control machines.

Stock control system -> information system

Air condition equipment in a building -> embedded system Some system may have both the systems.

For example: stock control system also controls an automated warehouse.

• Answering the question ‘Wh at 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: Rather like post-conditions  for the project

Focus on what  will be put in place, rather than how activities will be carried out

specific, that is, concrete and well-defined

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

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

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

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

Some ways of categorizing projects

Setting objectives

Objectives

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

Objectives should be SMART

– – – – –

These are steps along the way to achieving the objective. Informally, these can be defined by

completing the sentence…

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

Goals/sub-objectives

Objective X will be achieved

IF the following goals are all achieved

……… B……… C……… etc

Measures of effectiveness

Organization may have different titles such as a feasibility study or a project justification for what we call business case.

Its objective is to provide a rationale for the project by showing that the benefits of the project outcomes will exceed the costs of development.

A business case document might contain:

1. Introduction and background to the proposal. 2. The proposed project

3. The market

4. Organization and operation infrastructure 5. The benefits

6. Outline implementation plan 7. Costs

8. The financial case 9. Management plan

Data – the raw details

e.g. ‘6,000 documents processed at location X’ 

Information – the data is processed to produce something that is meaningful and useful

e.g. ‘productivity is 100 documents a day’ 

Comparison with objectives/goals

e.g. we will not meet target of processing all documents by 31 st  _March 

Modelling – working out the probable outcomes of various decisions

e.g. if we employ two more staff at location X how quickly can we get the documents processed?

Implementation – carrying out the remedial actions that have been decided upon

The business case

software project or how to make a project successful. It focuses on the four P’s; people, produ ct,

process and project. Here, the manager of the project has to control a ll these P’s to have a smooth

flow in the project progress and to reach the goal.

The four P’s of management spectrum has been described briefly in below.

But mainly people of a project highlight the developers. It is so important to have highly skilled and motivated developers that the Software Engineering Institute has developed a People

Management Capability Maturity Model (PM-CMM), “to enhance the readiness of software

organizations to undertake increasingly complex applications by helping to attract, grow, motivate, deploy, and retain the talent needed to improve their software development

capability”. Organizations that achieve high levels of maturity in the people management area

have a higher likelihood of implementing effective software engineering practices.

objectives and scope should be established, alternative solutions should be considered, and technical and management constraints should be identified. Without this information, it is impossible to define reasonable and accurate estimates of the cost, an effective assessment of risk, a realistic breakdown of project tasks or a manageable project schedule that provides a meaningful indication of progress.

software development can be established. A number of different tasks sets— tasks, milestones,

work products, and quality assurance points—enable the framework activities to be adapted to

the characteristics of the software project and the requirements of the project team. Finally, umbrella activities overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process.

Here, the manager has to do some job. The project includes all and everything of the total development process and to avoid project failure the manager has to take some steps, has to be concerned about some common warnings etc.

 Projects progress quickly until they are 90% complete. Then they remain at 90%

complete forever.

 When things are going well, something will go wrong. When things just can’t get worse,

they will. When things appear to be going better, you have overlooked something.

 If project content is allowed to change freely, the rate of change will exceed the rate of

progress.

 Project teams detest progress reporting because it manifests their lack of progress.

The Management Spectrum :

The management spectrum describes the management of a

The People:

People of a project includes from manager to developer, from customer to end user.

The Product:

Product is any software that has to be developed. To develop successfully, product

The Process:

A software process provides the framework from which a comprehensive plan for

The Project:

Requirements Analysis

Implementation Design

System Testing

Delivery and Installation

Requirements

Analysis

D

E

L

A

Y

Vaporware

ow it should go

ow it often goes

 Software Project:

 _{All technical  and managerial  activities required to deliver the deliverables to the}

client.

 _{A software project has a specific duration, consumes resources and produces work}

 products .

 _{Management categories to complete a software project:}

 _{Tasks, Activities, Functions}

 Software Project Management Plan:

 _{The controlling document for a software project.}

 _{Specifies the technical and managerial approaches to develop the software}

product.

 _{Companion document to requirements analysis document: Changes in either may}

imply changes in the other document.

 _{SPMP may be part of project agreement.}

 Document written for a client that defines:

 

 Can be a contract, a statement of work, a business plan, or a project charter.

 Client: Individual or organization that specifies the requirements and accepts the project

deliverables.

 Deliverables (= Work Products that will be delivered to the client):

   

Software Project Management Plan

Project Agreement

the scope, duration, cost and deliverables for the project. the exact items, quantities, delivery dates, delivery location.

Documents

Demonstrations of function

Demonstration of nonfunctional requirements Demonstrations of subsystems

Project Management Life Cycle comprises four phases... Initiation  involves starting up the project, by

documenting a business case, feasibility study, terms of reference, appointing the team and setting up a Project Office.

Planning  involves setting out the roadmap for the project by creating the following plans: project plan, resource plan, financial plan, quality plan, acceptance plan and

communications plan.

Execution involves building the deliverables and controlling the project delivery, scope, costs, quality, risks and issues.

Closure  involves winding-down the project by releasing staff, handing over deliverables to the customer and completing a post

implementation review.

A more detailed description of the Project Management Methodology and Life Cycle follows: 

Project Initiation is the first phase in the Project Life Cycle and essentially involves starting up the project. You initiate a project by defining its purpose and scope, the justification for initiating it and the solution to be implemented. You will also need to recruit a suitably skilled project team, set up a Project Office and perform an end of Phase Review. The Project Initiation phase involves the following six key steps:

After defining the project and appointing the project team, you're ready to enter the detailed

Project Management Life Cycle

Project Initiation

With a clear definition of the project and a suite of detailed project plans, you are now ready to enter the Execution phase of the project.

This is the phase in which the deliverables are physically built and presented to the customer for acceptance.

While each deliverable is being constructed, a suite of management  processes  are undertaken to monitor and control the deliverables being output by the project. These processes include managing time, cost, quality, change, risks, issues, suppliers, customers and communication.

Once all the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure.

Project Closure involves releasing the final deliverables to the customer, handing over project documentation to the business, terminating supplier contracts, releasing project resources and communicating project closure to all

stakeholders. The last remaining step is to undertake a Post Implementation Review to identify the level of project success and note any lessons learned for future projects.

Project Execution

• Project has a customer/sponsor

i.e. direct beneficiary from the project success

• It has stakes and stakeholders

• It has definable inputs, control parameter, purpose or end-product.

e.g. cost, schedule, performance

• It is unique (as against routine)

• It is temporary in nature

• It evolves as it progresses

• It involves an element of unfamiliarity

• It involves uncertainties and risks

• It is a process of working to achieve the goals

• It require varied resources

• It has defined start and finish dates.

• Project management involves application of knowledge, skills, tools and techniques to the

project activities with the objectives of meeting or exceeding the stakeholder expectations.

• Project management requires ability to administer a project by balancing the team and

technology.

Team Technology

• Process is a set of interrelated actions that are performed to achieve a predefined set of

products, services or results.

• Project processes are performed by the project team.

• Project processes broadly fall into two categories:

• : these are directed at initiating, planning,

Schedule Cost

Performance

Software Project Management Framework

Characteristics of projects:

What is project management?

Project and product-oriented processes

Project management processes

Resources

Profit

• : these processes are typically defined by the project life

cycle.

• Project management processes and product-oriented processes overlap and interact with

each other throughout the project life.

• Processes interact with each other in complex ways

• They also interact in relation to scope, cost, schedule etc.

It is 2-dimentional graph, given in the classroom

• A document that formally recognizes the existence of  a project.

• Provides the PM with the authority to apply organizational resources to the project: what the PM can and cannot do.

– e.g.; Right to reset Plan when requirements are changed

• Defines the project goal, scope and objectives. • Details the level of quality to be expected.

• Validates the business justification. • Highlights risk.

• It’s the contract: if anything needs resolution, this should specify it

• When in doubt, read the Charter! • Also specifies:

– what to do if there is conflict

– Management reconciliation

– Scope change management

– Knowledge transfer Process Product Engineering Process Product Development Process Process Management Process Project Management Process Product-oriented processes

Components of a process

Overlap Amongst process groups

Project Charter

• 1.1 Identify objectives and measures of effectiveness

 –  ‘how do we know if we have succeeded?’

• 1.2 Establish a project authority

 –  ‘who is the boss?’

• 1.3 Identify all stakeholders in the project and their interests

- ‘who will be affected/involved in the project?

• 1.4 Modify objectives in the light of stakeholder analysis

 –  ‘do we need to do things to win over stakeholders?’

• 1.5 Establish methods of communication with all parties

- ‘how do we keep in contact?

• 2.1 Establish link between project and any strategic plan

Software Project Planning

Step 1 establish project scope and objectives

• 2.3. Identify project team organization

‘where do I fit in?’

• 3.1 Distinguish the project as either objective or product-based.

 –  Is there more than one way of achieving success?

• 3.2 Analyse other project characteristics (including quality based ones)

 –  what is different about this project?

• Identify high level project risks

 –  ‘what could go wrong?’

 –  ‘what can we do to stop it?’

• Take into account user requirements concerning implementation

• Select general life cycle approach

 –  waterfall? Increments? Prototypes?

• Review overall resource estimates

‘does all this increase the cost?’

4.1 Identify and describe project products - ‘what do we have to produce?’

Step 3 Analysis of project characteristics

• The PBS and PFD will probably have identified generic products e.g. ‘software modules’

• It might be possible to identify specific instances e.g. ‘module A’, ‘module B’ …

• But in many cases this will have to be left to later, more detailed, planning

• Identify the activities needed to create each product in the PFD

• More than one activity might be needed to create a single product

• Hint: Identify activities by verb + noun but avoid ‘produce…’ (too vague)

• Draw up activity network

4.2 document Generic product flows

Step 4.3 Recognize product instances

n ‘ideal’ activity

 –  break up very long activities into a series of smaller ones

 –  bundle up very short activities (create check lists?)

• 6.1.Identify and quantify risks for activities

 –  damage if risk occurs (measure in time lost or money)

 –  likelihood if risk occurring

• 6.2. Plan risk reduction and contingency measures

 –  risk reduction: activity to stop risk occurring

 –  contingency: action if risk does occur

• 6.3 Adjust overall plans and estimates to take account of risks

 –  e.g. add new activities which reduce risks associated with other activities e.g.

training, pilot trials, information gathering

• 7.1 Identify and allocate resources to activities

• 7.2 Revise plans and estimates to take into account resource constraints

 –  e.g. staff not being available until a later date

 –  non-project activities

• 8.1 Review quality aspects of project plan

• 8.2 Document plan and obtain agreement

Step 6: Identify activity risks

Step 7: Allocate resources

A successful project is one delivered on time, within, budget and with required quality. This implies that targets are set which the project manager then tries to meet.

A project manager has to produce estimates of effort which affects costs, and of activity duration, which affect the delivery time.

Some of the difficulties of estimating time arise from the complexity and invisibility of the

software. Also the intensely human activities which make up system development can’t be

treated in a purely mechanistic way. Other difficulties include:

1. Subjective nature of estimating 2. Political implications

3. Changing technology

4. Lack of homogeneity of project experience

Estimates are carried out at varies stages of software project for a variety of reasons: 1. Strategic planning

2. Feasibility study 3. System specification

4. Evaluation of supplier’s proposal

5. Project palnning

• Parkinson’s Law: ‘Work expands to fill the time available’

• An over-estimate is likely to cause project to take longer than it would otherwise

• Weinberg’s Zeroth Law of reliability: ‘a software project that does not have to meet a

reliability requirement can meet any other requirement’

Barry Boehm, in his classic work on software efforts models, identified the main ways of deriving estimates of software development efforts as:

• Algorithmic models, which use ‘effort drivers’ representing characteristics of the target

system and the implementation environment to predict effort;

• Export judgement, based on the advice of knowledgeable staff;

• Analogy, where a similar, completed, project is identified and its actual effort is used as

the basis of the estimate;

• Parkinson, where the staff effort available to do a project becomes the ‘estimate’

Software Project Estimate

What are estimates done?

Over and under-estimating

• Bottom-up - activity based, analytical

• Parametric or algorithmic models e.g. function points

• Expert opinion - just guessing?

• Analogy - case-based, comparative

• Parkinson and ‘price to win’

• Bottom-up

 –  use when no past project data

 –  identify all tasks that have to be done – so quite time-consuming

 –  use when you have no data about similar past projects

• Top-down

 –  produce overall estimate based on project cost drivers

 –  based on past project data

 –  divide overall estimate between jobs to be done

1. Break project into smaller and smaller components

2. Stop when you get to what one person can do in one/two weeks] 3. Estimate costs for the lowest level activities

4. At each higher level calculate estimate by adding estimates for lower levels

• COCOMO (lines of code) and function points examples of these

• Problem with COCOMO etc:

A taxonomy of estimating methods

Bottom-up versus top-down

Bottom-up estimating

Top-down estimates

• Examples of system characteristics

 –  no of screens x 4 hours

 –  no of reports x 2 days

 –  no of entity types x 2 days

• the quantitative relationship between the input and output products of a process can be

used as the basis of a parametric model

• simplistic model for an estimate

estimated effort = (system size) / productivity e.g. system size = lines of code

productivity = lines of code per day

• productivity = (system size) / effort based on past projects

• Some models focus on task or system size e.g. Function Points

• FPs originally used to estimate Lines of Code, rather than effort

• Other models focus on productivity: e.g. COCOMO

• Lines of code (or FPs etc) an input

Parametric models - the need for historical data