SPM Lecture Notes UNIT I

Software Project Management

Lecture Notes

UNIT-I Introduction and Software Project Planning

For Third Year Students MCA

Page 1 of 22

1. 2. 3. 4. 5. 6.

Planning – deciding what to do Organizing – making arrangements Staffing – selecting the right people for the job etc. Directing – giving instructions Monitoring – checking on progress Controlling – taking action to remedy hold-ups Innovating – coming up with new solutions Representing – liaising with clients, users, developer, suppliers and other stakeholders.

: Software is a general term for the various kinds of  programs of  programs used  used to operate computers operate computers and  and related devices. OR Software means computer  instructions  instructions or  data   data . Anything that can be stored be  stored electronically is software, in contrast to storage to  storage devices  devices and display devices which are called hardware. called  hardware. :  planned activity  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, cost and resources Some dictionary definitions:

“A specific plan or design”  “A planned undertaking”  “A large undertaking e.g. a public works scheme”  Page 2 of 22

‘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? Only done if project is feasible Implement plan, but plan may be changed as we go along Page 3 of 22

 – 

 – 

 – 

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  – 

 – 

 – 

•

 – 

•

 – 

•

 – 

•

Page 4 of 22

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

Page 5 of 22

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 •

•

•

Page 6 of 22

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

Page 7 of 22

The management spectrum describes the management of a 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. People of a project includes from manager to developer, from customer to end user. 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. Product is any software that has to be developed. To develop successfully, product 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. A software process provides the framework from which a comprehensive plan for 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.

Page 8 of 22

Requirements Analysis Design

Implementation

System Testing

Delivery and Installation

Requirements Analysis

D E L A Y

Vaporware

Page 9 of 22



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):    

Page 10 of 22

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 Planning phase. This involves creating a suite of planning documents to help guide the team throughout the project delivery. The Planning Phase involves completing the following 10 key steps: Page 11 of 22

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.

Page 12 of 22

•

•

•

•

•

•

•

•

•

•

•

•

•

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

Schedule

Technology

Cost

Resources

Performance

Profit

Productivity

•

•

•

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, executing, monitoring, controlling and closing a project. •

Page 13 of 22

: 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. •

•

Process

Product Engineering Process

Process Management Process

Product Development Process

Project Management Process

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 qua lity 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 – Training approach – Anything else …

Page 14 of 22

•

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 ‘why did they want the project?’ 2.2 Identify installation standards and procedures ‘what standards do we have to follow?’  – 

•

 – 

Page 15 of 22

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?’

Page 16 of 22

•

•

•

•

•

•

•

The PBS and PFD will probably have identified generic pro ducts 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

Page 17 of 22

•

5.1 Carry out bottom-up estimates distinguish carefully between effort  and elapsed  time 5.2. Revise plan to create controllable activities  – 

•

Page 18 of 22

 – 

 – 

•

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

This may require the reiteration of the planning process at a lower level Page 19 of 22

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’ Price to win, where the ‘estimate’ is a figure that seems sufficient low to win a contract; Top-down, where an overall estimate for the whole project is broken down into the effort required for component tasks; Bottom-up, where component tasks are identified and sized and these individual estimates are aggregated. •

•

•

•

•

•

•

Page 20 of 22

•

•

•

•

•

•

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:

Page 21 of 22

•

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

Page 22 of 22