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 the project 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 laws that are consistent. Software developers have to conform to the requirements of human clients Flexibility Software systems are likely to be subject to a high degree of change. The ease with which software can be changed is usually seen as one of its strength

Feasibility study/plan/execution cycle

Feasibility Study

How do we do it?

Is it worth doing?

Plan Do it!

Project Execution

Activities
Feasibility study investigates whether a prospective project is worth starting that it has a valid business case Planning Formulation of outline plan for the whole 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 System Software System Software Architecture design Requirement analysis Requirement s

Architecture design Requirement analysis

Design

Detailed design Code and test Code and test Integration Qualification test Integration Qualification test

Installation/ acceptance support

Installation Acceptance support

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 customerfacing 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 the components 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 thus forms 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 could be 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 and improvements

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 system to 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 business case effort and expense Cost benefit analysis For e.g. That development costs are not allowed to rise to a level which 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 requirements
These define what the end-product of the project is to do.

Quality requirements
These define about the end-product should do. These are still things that the user will be able to experience.

Resource requirements
This 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 to be managed by a local government authority but has now become autonomous. Its payroll is still administered by the local authority and pay slips and other output are produced in the local authoritys computer centre. The authority now charges the college for this serve. The college management are of the opinion that it would be cheaper to obtain an off-the-shelf payroll package and do the payroll processing themselves. What would be the main stages of the project to convert to independent payroll processing by the college? Bearing in mind that an off-the-shelf package is to be used, how would this project differ from one where the software was to be written from scratch?

Project evaluation All the costs that would be incurred by the college if it were to carry out its own payroll processing would need to be carefully examined to ensure that it would be more cost effective than letting the local authority carry on providing the service. Planning The way that the transfer to local processing is to be carried out needs to be carefully planned with the participation of all those concerned. Some detailed planning would need to be deferred until more information was available, for example which payroll package was to be used. Requirements elicitation and analysis This is finding out what the users need from the system. To a large extent it will often consist of finding out what the current system does, as it may be assumed that in general the new system is to provide the same functions as the old. The users might have additional requirements, however, or there might even be facilities that are no longer needed. Specification This involves documenting what the new system is to be able to do.

 Design/Coding As an off-the-shelf package is envisaged, these stages will be replaced by a package evaluation and selection activity. Verification and validation Tests will need to be carried out to ensure 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 the software, setting system parameters such as the salary scales, and setting up details of employees. Maintenance/support This will include dealing with users queries, liaising with the package supplier and taking account of new payroll requirements.

Overview of Step Wise planning

0. Select project 1. Identify project scope and objectives 2. Identify project infrastructure

3. Analyze project characteristics

4. Identify the products and activities

5. Estimate effort for each activity Lower level detail 6. Identify activity risks

For each activity

10. Lower level planning

7. Allocate resources

9. Execute plan

8. Review/ publicize plan

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 stakeholders 1.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 productdriven 3.2 Analyze other project characteristics 3.3 Identify high-level project risks 3.4 Take into account user requirements concerning implementation 3.5 Select general life-cycle approach 3.6 Review overall resource estimates

4.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 Project checkpoints products
System products Module products Management products

4. Identify project products and activities

Module design documents

Module code

Progress report

Overall specification

Integration test cases

Tested integrated software

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