Sw Proj Mgmt

8/6/2019 Sw Proj Mgmt

http://slidepdf.com/reader/full/sw-proj-mgmt 1/26

Software Project Management



Project

• Non-routine tasks are involved• Planning is required• Specific objectives are to be met or a specified

product is to be created• The project has a predetermined time span• Work involves several specialisms• Work is carried out in several phases

• The resources that are available for use on theproject are constrained• The project is large or complex



Software Projects Vs Other types of

project

• Invisibility – Progress is not immediately visible.• Complexity – Software products contain more

complexity than other engineered artefacts.• Conformity – Traditional engineering projects

though complex are governed by physical lawsthat are consistent. Software developers have toconform to the requirements of human clients

• Flexibility – Software systems are likely to be

subject to a high degree of change. The easewith which software can be changed is usuallyseen as one of its strength



Feasibility study/plan/execution cycle

Feasibility Study

Plan

Project Execution

Is it worthdoing?

How dowe do it?

Do it!



Activities

• Feasibility study – investigates whether a

prospective project is worth starting – that it has

a valid business case

• Planning – Formulation of outline plan for thewhole project and a detailed one for the first

stage. Detailed planning for the later stages

would be done as they approach.

• Project execution – Often contains design and

implementation sub-phases



ISO 12207 Software development life cycle

Requirement analysis

Architecture design


Architecture design


Detailed design

Code and test

Integration

Qualification test

Integration

Qualification test

Installation S o

f t w ar e

I n s t al l a t i on /

a c c e

p t an c e

s u p p or t

S y s t em

S of t w

ar e

S y s t em

Acceptance support

C o d e an d

t e s t

R e q ui r em en t

s

D e s i gn



Project Execution• Requirement analysis – Process of investigating what the

potential users and their managers and employers require as

features and qualities of the new system. These ‘customer-facing’ requirements then have to be translated into technical

requirements from which the developers of the new system

can work

• Architecture design – This maps the requirements to thecomponents of the system that is to be built.

– Decision to be made about which processes in the new

system will be carried out by the user and which can be

computerized. This design of the system architecture thusforms an input to the development of the software

requirements.

– A second architecture design process then takes place

which maps the software requirements to software

components.



• Detailed design – Each software component is made up of a

number of software units that can be separately coded and tested.

The detailed design of these units is carried out separately.• Code and test – This could refer to writing code for each software

unit or could refer to the use of an application-builder. Initial testing to

debug individual

• Integration – The individual components are collected together and

tested to see if they meet the overall requirements. Integration couldbe at the level of

– Software where different components are combined,

– At the level of the system as a whole where the software and other

components of the system such as the hardware platforms and networks

and the user procedures are brought together

• Qualification testing – Testing the system, including the software

components to ensure that all the requirements have been fulfilled



• Installation – Process of making new system operational. Would

also include setting system parameters, installing the software onto

the hardware platforms and user training

• Acceptance support – Stage of resolving problems with the

newly installed system, error rectification, any extensions andimprovements

Case study



• Many software projects have two stages

– First is an objectives-driven project which

results in a recommended course of action

and may even specify a new software systemto meet identified requirements

– Next is a project actually to create the

software product



Objectives versus products

• Projects may be distinguished by whether

their aim is to produce a product or to

meet certain objectives

• A project might be to create a product, the

details of which have been specified by

the client

• A project might also be required to meet

certain objectives



Problems with Software projects

• Poor estimates and plans

• Lack of quality standards and measures

• Lack of guidance about making organizational

decisions

• Lack of techniques to make progress visible

• Poor role definition – who does what?

• Incorrect success criteria



Problems identified by Software

professionals

• Inadequate specification of work

• Management ignorance

• Lack of knowledge of application area

• Lack of standards• Lack of up-to-date documentation

• Lack of communication between users and technicians

• Deadline pressure

• Lack of quality control

• Remote management

• Lack of training



Business Case

• Most projects need to have a justification or a businesscase – effort and expense

• Cost – benefit analysis

For e.g.

• That development costs are not allowed to rise to a levelwhich threatens to exceed the value of benefits;

• That the features of the system are not reduced to a

level where the expected benefits cannot be realized;• That the delivery date is not delayed so that there is an

unacceptable loss benefits



Requirement Specification

• Functional requirementsThese define what the end-product of the project is to do.

• Quality requirementsThese define about the end-product should do. These are still

things that the user will be able to experience.

• Resource requirementsThis would keep a record of how much the organization is willing to

spend on the system.



Case Study

ABC College is a higher education institution which used tobe managed by a local government authority but hasnow become autonomous. Its payroll is still administeredby the local authority and pay slips and other output areproduced in the local authority’s computer centre. The

authority now charges the college for this serve. Thecollege management are of the opinion that it would becheaper to obtain an ‘off-the-shelf’ payroll package anddo the payroll processing themselves.

What would be the main stages of the project to convert to

independent payroll processing by the college? Bearingin mind that an off-the-shelf package is to be used, howwould this project differ from one where the software wasto be written from scratch?



• Project evaluation – All the costs that would be incurred by the college if itwere to carry out its own payroll processing would need to be carefully

examined to ensure that it would be more cost effective than letting thelocal authority carry on providing the service.

• Planning – The way that the transfer to local processing is to be carried outneeds to be carefully planned with the participation of all those concerned.Some detailed planning would need to be deferred until more informationwas available, for example which payroll package was to be used.

• Requirements elicitation and analysis – This is finding out what the usersneed from the system. To a large extent it will often consist of finding outwhat the current system does, as it may be assumed that in general thenew system is to provide the same functions as the old. The users mighthave additional requirements, however, or there might even be facilities

that are no longer needed.

• Specification – This involves documenting what the new system is to beable to do.



• Design/Coding – As an ‘off-the-shelf’ package is envisaged, these

stages will be replaced by a package evaluation and selectionactivity.

• Verification and validation – Tests will need to be carried out toensure that the selected package will actually do what is required.This task might well involve parallel running of the old and new

systems and a comparison of the output from them both to check for any inconsistencies.

• Implementation – This would involve the things like installing thesoftware, setting system parameters such as the salary scales, andsetting up details of employees.

• Maintenance/support – This will include dealing with users’ queries,liaising with the package supplier and taking account of new payrollrequirements.

O i f S Wi l i



Overview of Step Wise planning

4.

Identify the products and activities

0. Select project

1.

Identify project scope and objectives

2.

Identify project infrastructure

3.

Analyze project characteristics

5.

Estimate effort for each activity

6. Identify activity risks

7. Allocate resources

8. Review/ publicize plan9. Execute plan

10. Lower level planning

For each

activityLower

level detail



1. Identify project scope and objectives

1.1 Identify objectives and measures of effectiveness in

meeting them

1.2 Establish a project authority

1.3 Identify stakeholders1.4 Modify objectives in the light of stakeholder analysis

1.5 Establish methods of communications with all parties



2. Identify project infrastructure

2.1 Establish relationship between project and strategic

planning

2.2 Identify installation standards and procedures

2.3 Identify project team organization



3. Analyze project characteristics

3.1 Distinguish the project as either objective- or product-

driven

3.2 Analyze other project characteristics

3.3 Identify high-level project risks3.4 Take into account user requirements concerning

implementation

3.5 Select general life-cycle approach

3.6 Review overall resource estimates



4. Identify project products and

activities4.1 Identify and describe project products

4.2 Document generic product flows

4.3 Recognize product instances

4.4 Produce ideal activity network

4.5 Modify ideal to take into account need for stages and

checkpoints Project

products

System

products

Module

products

Tested

integrated

software

Integration test

cases

Overall

specification

Management

products

Module

design

documents

Module code Progress

report



5. Estimate effort for each activity

5.1 Carry out bottom-up estimates

5.2 Revise plan to create controllable activities



6. Identify activity risks

6.1 Identify and quantify activity-based risks

6.2 Plan risk reduction and contingency measures where

appropriate

6.3 Adjust plans and estimates to take account of risks



7. Allocate resources

7.1 Identify and allocate resources

7.2 Revise plans and estimates to take account of resource

constraints

8. Review/publicize plan

8.1 Review quality aspects of project plan

8.2 Document plans and obtain agreement

Sw Proj Mgmt

Documents

Transcript of Sw Proj Mgmt