software project managemnt

Text book: Software Project Management by Bob Hughes and Mike Cotterell, 4th ed.

Unit – 1: Introduction to Software Project Management (SPM)

LECTURE 1

1.1 Definition of Software Project Management (SPM)

Software Project Management (SPM) is an activity of organizing, planning and

scheduling of Software Projects.

1.2 Software Projects versus other types of project

The following characteristics of software project which make them different from other

projects:

Invisibility

Complexity

Conformity

Flexibility

1.3 Activities covered by software project management (SPM)

The following activities are:

The feasibility study

Planning

Project execution

The feasibility/Plan/execution cycle as shown in the figure:

Fig: Feasibility/Plan/execution cycle

1. The feasibility study

We study that whether the project have worth or not, it mean that it has a

valid business case.

2. Planning

First, we formulate the outline plan for the whole project then later we will

go for the detail and accurate plan.

3. Project execution

The execution of a project contains the design and implementation sub-

phases.

LECTURE 2

1.4 Categorizing Software Projects

The software projects can be broadly divided into two categories:

Information systems versus embedded systems

The difference is that in the former case, the system interface with the organization eq.

stock control system, whereas in the later case, the systems interface with a machine eq.

the air conditioning equipment in a building.

Objective versus products

Feasibility study

Plan

Project execution

How we do it?

Do it?

Is it worth doing?

A project might be to create a project, the details of which have been specified by the

client. On the other hand, the project may be required to meet certain objectives.

1.5 Requirement specification

The following are:

Functional requirements

These define what the end-product of the project is to do.

Quality requirements

There will be other attributes of the attributes of the application to be implemented that

do not relate so much to what the system is to do but how to do it, eq. response time.

Resource requirements

A record of how much the organization is willing to spend on the system.

These are also called non-functional requirements.

LECTURE 3

1.6 What is Management?

The management involves the following activities:

Planning

Organizing

Staffing

Directing

Monitoring

Controlling

Innovating

Representing

1.7 Management control

It involves setting the objectives for a system and then monitoring the system.

The figures explain the whole system:

This will involves the local manages in data collection. Data processing will be needed

to transform this raw data into useful information. The making decisions/plans will be

useful to take decision whether it will be complete on time or not. It also considers other

aspects. The project manager can move staff from particular branches. This is modeling

the consequences of a potentials solution. Several different proposals could be modeled

in this way before one was chosen for implementation.

It can be seen that a project plan is dynamic and will need constant adjustment during the

execution of a project.

Fig: The project control cycle

The real

world

Data collection

Data processing

Making decisions /

plans

Implementation

Define objective

Modeling

Actions

Data

Information

Decisions

LECTURE 4

Requirement specification

The following are:

Functional requirements

These define what the end-product of the project is to do.

Quality requirements

There will be other attributes of the attributes of the application to be implemented that

do not relate so much to what the system is to do but how to do it, eq. response time.

Resource requirements

A record of how much the organization is willing to spend on the system.

These are also called non-functional requirements.

Categorizing Software Projects

The software projects can be broadly divided into two categories:

Information systems versus embedded systems

The difference is that in the former case, the system interface with the organization eq.

stock control system, whereas in the later case, the systems interface with a machine eq.

the air conditioning equipment in a building.

Objective versus products

A project might be to create a project, the details of which have been specified by the

client. On the other hand, the project may be required to meet certain objectives.


Unit -2 Stepwise Project planning

LECTURE 5

2.1 Introduction

A major principle of project planning is to plan in outline first and then in more

detail as the time to carry out an activity approaches.

An outline of stepwise planning activities is:

Select project

Identify project scope and objectives

Identify project infrastructure

Analyze project characteristics

Identifies project product and activities

Estimate effort for each activity

Identify activity risks

Allocate resources

Review/publicize plan

Execute plan/lower levels of planning

2.2 Selecting a project

The project must be worthwhile such that it should have priority over other projects. This

evaluate of the merits of projects could be part of strategic planning.

2.3 Identify project scope and objectives


Identify objectives and practical measures of the effectiveness in meeting those

objectives.

Establish a project authority

Stakeholder analysis – identify all stakeholders in the project and their interests

Modify objectives in the light of stakeholder’s analysis

Establish methods of communication with all parties

LECTURE 5

2.4 Identify project infrastructure


Identify relationship between the project and strategic planning

Identify installation standards and procedures

Identify project team organization

2.5 Analysis project characteristics


Distinguish the project as either objective- or product-driven

Analysis other project characteristics (including quality-based ones)

Identify high-level risks

Take into accounts user requirements concerning implementation

Select development methodology and life-cycle approach

Review overall resource estimates

LECTURE 6

2.6 Identify project products and activities


Identify and describe project products (or deliverables)

The products will form the hierarchy. The main product will have sets of

component products which in turn may have sub-component products and

so on. This relationship can be documented in a Product Breakdown

Structure (PBS). It is shown as in the figure.

Fig. A framework of a product breakdown structure for a system development task

Document generic product flows

Some products will need one or more other products to exist first before

they can be created. For example, a program design must be created before

the program can be written and the program specification must exist

before the design can be concerned. These relationships can be shown by

the Product Flow Diagram (PFD). It is shown as in figure.

Project products

System products

Module products

Management products

Module design

documents

Module code

Progress report

Overall specification

Integration case

Tested integration software

Fig. A framework of a PFD for a software development task

Recognize product instances

There may be delayed to later in the product when more information is

known.

Produce ideal activity network

It is explained by an example of activities network.

User requirements

Overall system specification

Integration system test cases

Module design

Module code

Integrated/tested software

Fig. An example of an activity network

Modify the ideal to take into account need for stages and checkpoints

There might be a need to modify this by dividing the project into stages

and introduces checkpoint activities. These are activities which draw

together the products activities to check that they are compatible.

There could be some key attributes, or milestones, which represent the

completion of important stages of the project of which they would want to

take particular note.

2.7 Estimate effort for each activity


Carry out bottom-up estimates

At this point, estimates of the staff effort required, the probable elapsed

time and the non-staff resources needed for each activity will need to be

produced.

Effort is the amount of work that needs to be done.

Elapsed time is the time between the start and end of a task.

Revise plan to create controllable activities

Design integration teat cases

Specify overall system

Code module A

Design module B

Code module B

Design module A

Test integrated software

Try to make activities about the length of the reporting period used for

monitoring and controlling the project.

LECTURE 7

2.8 Identify activity risks


Identify and quantify activity-based risks

A project plan will be based on a huge number of assumptions. So,

identifications of risks are very important factor. If it will not take very

seriously, the project may be delayed and costly.

Plan risk reduction and contingency measures where appropriate

We can avoid or at least reduce some of the identified risks. On the other

hand, contingency plans specify action that is to be taken if a risk

materializes.

Adjust overall plans and estimates to take account of risks

We may change our plans, by adding new activities which reduce risks

2.9 Allocate resources

Identify and allocate resources

The staff available for the project are identified and are allocated to tasks

Revise plans and estimates to take into account resource constraints

Some staff may be needed for more than one task at the same time and an

order of priority is established.

2.10 Review/publicize plan

Review quality aspects of the project plan

Each task should have quality criteria. These are quality checks that have

to be passed before the activity can be ‘signed off’ as completed.

Document plans and obtain agreement

The plans should be carefully documented and all the parties must agree to

the commitment required for the plan.


Unit-3 Project Evaluation and Estimation

LECTURE 8

Cost-benefit analysis

It mainly comprise two steps

Identify and estimating all of the costs and benefits of carrying out the

project and operating the delivered application.

Expressing these costs and benefits in common units

We need to evaluate the net benefit, that is, the difference between the

total benefit and the total benefit and the total cost of creating and

operating the system.

We can categorize cost according to where they originate in the life of the

project. These are:

Development costs

Setup costs

Operational costs

Cash flow forecasting

A cash flow forecast will indicate when expenditure and income will take place. It is as

shown in the figure:

Fig: Typical product life cycle cash flow

LECTURE 9

Cost-benefit evaluation techniques

The following cost-benefit evaluation techniques are:

Net profit

The net profit of a project is the difference between total costs and the total

income over the life of the project.

Payback period

The payback period is the time taken to break even or pay back the initial

investment.

Return on investment

The return on investment (ROI), also known as the accounting rate of return

(ARR), provides a way of comparing the net profitability to the investment

required.

Average annual profit

ROI = --------------------------- * 100

Total income

Net present value

The calculation of net present value is a project evaluation technique that takes

into account the profitability of a project and the timing of the cash flows that are

produced.

The present value of any future cash flow may be obtained by applying the

following formula

Value in year t

Present value = -----------------------

(1+r) t

Where r is the discount rate and t is the number of years into the future that the

cash flow occurs.

Internal rate of return

The internal rate of return (IRR) attempts to provide a profitability measures as a

percentage return that is directly comparable with interest rates.

Risk evaluation

The following things are:

Risk identification and ranking

In any project evaluation we should attempt to identify the risks and quantify their

potential effects. One common approach to risk analysis is to construct a project

risk matrix utilizing a checklist of possible risks and to classify each risk

according to its relative importance and likelihood.

Risk and net present value

Where a project is relatively risky it is common practice to use a higher discount

rate to calculate net present value.

Cost-benefit analysis

A more sophisticated approach to the evaluation of risk is to consider each

possible outcome and estimate the probability of its occurring and the

corresponding value of the outcome. The value of the project is then obtained by

summing the cost or benefit for each category.

Risk profile analysis

By study the results of a sensitivity analysis we can identify those factors that are

most important to the success of the project. There are a number of risk analysis

applications available and produce the risk profiles of the type.

Using decision trees

The analysis of a decision tree consists of evaluating the expected benefit of

taking each path from a decision point (It is denoted by D). The expected value of

each path is the sum of the value of each possible outcome multiplied by its

probability of occurrence. This is shown as in the figure:

Fig. A Decision Tree

LECTURE 10

Selection of a an appropriate project approach

The selection of a particular process model could add new products to the Project

Breakdown Structure (PBS) or new activities to the activity network. This will generate

inputs for identify the products and activities of the project.

Choosing technologies

An outcome of project analysis will be the selection of the most appropriate

methodologies and technologies. Methodologies include approaches like Unified

Software Development Process (USDP), Structure System Analysis and Design Method

(SSADM), and Human-Centered Design, while technologies include appropriate

application-building and automated testing environments.

The some of the steps of the project analysis are:

Identify project as either objectives-driven or product-driven

D

Extend

Replace

Expansion

No expansion

Expansion

No expansion

0.2

0.8

0.2

0.8

In objective-driven project, we define the general software solution that is to be

implemented, while in product-driven project, the product to be created is defined

before the start of the product.

Analysis other project characteristics

The following point will arise:

Is a data-oriented or process-oriented system to be implemented?

Will the software that is too produced be a general tool or application

specific?

Are there specific tools available for implementing the particular type of

application?

Is the system to be created safety critical?

What is the nature of the hardware/software environment in which the

system will operate?

Identify high-level project risks

The following uncertainty will occur:

Product uncertainty

Process uncertainty

Resource uncertainty

Take into account user requirement concerning implementation

Select general life-cycle approach

Some approaches are:

Control systems

Information systems

General tools

Specialized techniques

Hardware environment

Safety-critical systems

Choice of process models

The word ‘process’ is used to emphasize the idea of a system in action. In order to

achieve an outcome, the system will have to execute one or more activities. A major part

of the planning will be choosing development methods and slotting them into an overall

process model.

Structure methods

The principle behind structure method is ‘get it right first time’. The structure methods

are made up of sets of steps and rules which generate system products such as use case

diagrams. Some of them are rapid application development (RAD), waterfall model etc.

LECTURE 11

The RAD Model

Rapid application development (RAD) is an incremental software development process

model that emphasizes an extremely short development cycle. The RAD model is a”

high-speed” adaptation of the linear sequential model in which rapid development is

achieved by using component-based construction. The RAD approach encompasses the

following phases:

Business modeling

Data modeling

Fig: The Process

Process modeling

Application generation

Testing and turnover

Like all process models, the RAD approach has drawbacks:

For large but scalable projects, RAD requires sufficient human resources to create

the right number of RAD teams.

RAD requires developers and customers who are committed to the rapid-fire

activities necessary to get a system complete in a much abbreviated time frame. If

commitment is lacking from either constituency, RAD projects will fail.

Not all types of applications are appropriate for RAD. If a system cannot be

properly modularized, building the components necessary for RAD will be

problematic. If high performance is an issue and performance is to be achieved

through tuning the interfaces to system components, the RAD approach may not

work.

RAD is not appropriate when technical risks are high. This occurs when a new

application makes heavy use of new technology or when the new software

requires a high degree of interoperability with existing computer programs.

LECTURE 12

The Spiral Model

The spiral model, originally proposed by Boehm, is an evolutionary software process

model that couples the iterative nature of prototyping with the controlled and systematic

aspects of the linear sequential model.

A spiral model is divided into a number of framework activities, also called task regions.

Typically, there are between three and six task regions. Figure 2.8 depicts a spiral model

that contains six task regions:

Customer communication

Planning

Risk analysis

Engineering

Construction and release

Customer evaluation

software project managemnt

Documents

Transcript of software project managemnt