02 Software Project Planning

Software Project Management Software Project Planning

1

Integration Management – Main Role of a Project Manager Team Members Role – Concentrating on completing their work packages Project Sponsor – Protecting the project from changes and loss of resources Project Manager – To put all the pieces of the project together into one cohesive whole that gets the project done faster, cheaper and with fewer resources while meeting the project objectives.

2

3

4

Identifying Needs The project manager drives the scope of the project. The project manager should identify and talk to the main stakeholder The effective way to show stakeholders that their needs are understood and that those specific needs will be addressed is with a vision and scope document

5

Vision and Scope Document A typical vision and scope document follows an outline like this one: 1. Problem Statement a) b) c) d) e)

Project background Stakeholders Users Risks Assumptions

2. Vision of the Solution a) b) c) d)

Vision statement List of features Scope of phased release (optional) Features that will not be developed

6

Resource List The project plan should contain a list of all resources that will be used on the project. A resource is a person, hardware, room or anything else that is necessary for the project but limited in its availability The resource list should give each resource a name, a brief one-line description, and list the availability and cost (if applicable) of the resource

7

Estimates and Project Schedule The project plan should also include estimates and a project schedule:  A work breakdown structure (WBS) is defined. This is a list of tasks which, if performed, will generate all of the work products needed to build the software.  An estimate of the effort required for each task in the WBS is generated.  A project schedule is created by assigning resources and determining the calendar time required for each task.

Estimates and project schedules will be discussed in detail in later slides. 8

Risk Plan A risk plan is a list of all risks that threaten the project, along with a plan to mitigate some or all of those risks. The project manager selects team members to participate in a risk planning session: • The team members brainstorm potential risks • The probability and impact of each risk is estimated • A risk plan is constructed

9

Risk Plan Example

10

Configuration management planning Starts during the early phases of the project All products of the software process may have to be managed Specifications Designs Programs Test data User manuals Thousands of separate documents may be generated for a large software system 11

The CM plan Defines the types of documents to be managed and a document naming scheme Defines who takes responsibility for the CM procedures and creation of “baselines” Defines policies for change control and version management Defines the CM records which must be maintained Describes the tools which should be used to assist the CM process and any limitations on their use 12

Configuration management – Why New versions of software systems are created as they change  For different machines/OS  Offering different functionality  Tailored for particular user requirements Configuration management is concerned with managing evolving software systems  System change is a team activity  CM aims to control the costs and effort involved in making changes to a system Involves the development and application of procedures and standards to manage an evolving software product May be seen as part of a more general quality management process When released to CM, software systems are sometimes called baselines as they are a starting point for further development 13

Configuration management – Why Involves the development and application of procedures and standards to manage an evolving software product May be seen as part of a more general quality management process When released to CM, software systems are sometimes called baselines as they are a starting point for further development

14

Stepwise Project Planning Step 0 Select Project Step 1 Identify Project Scope and Objectives  Identify Objectives and measures of effectiveness in meeting them  Establish a project authority  Identify Stakeholders – All the participants in Escalation Procedure  Establish methods of communications with all parties Step 2 Identify Project Infrastructure  Establish Project Execution Methodology  Identify installation standards and procedures (H/w and S/w Requirements)  Identify project team organization

Step 3 Analyze project characteristics  Identify Project Risks  Project Phases  Review overall resource estimates

15

Stepwise Project Planning Step 4 Identify project products and activities  Identify and describe project products (Including Quality Criteria) - Deliverables  Acceptance/Warranty Criteria  Configuration Management

Step 5 Estimate effort for each activity Step 6 Identify activity risks  Identify and quantity risks  Plan risk reduction and contingency measures  Adjust plans and estimates to take account of risks

Step 7 Allocate Resources  Identify and allocate resources  Revise plans and estimates to take account of resource constraints

Step 8 Review/Publicize plan  Review Quality aspects of project plan  Document plans and obtain agreement

Step 9/10 Execute plan/lower levels of planning This may require the reiteration of the planning process at a lower level 16

Project Management Plan The project management plan defines the work that will be done on the project and who will do it. It consists of:  A statement of work (SOW) that describes all work products that will be produced and a list of people who will perform that work  A resource list that contains a list of all resources that will be needed for the product and their availability  A work breakdown structure and a set of estimates  A project schedule  A risk plan that identifies any risks that might be encountered and indicates how those risks would be handled should they occur Project Management Plan

17

Scope Management Scope Management means –  Constantly checking to make sure you are completing all the work  Not letting people randomly add to the scope of the project without a structured change control system  Making sure all changes fit within the project charter  Defining and controlling what is and is not included in the project  Preventing extra work or gold plating

Scope planning is focused on thinking ahead to determine, “How will I do this”?, before doing the work, and turning the answer into a project scope management plan. (SMP) Project SMP may be unique for a particular project but may cover topics that for the company or the type of the project may be standardized. Once completed SMP becomes part of Project Management Plan and is used to guide and measure the project until the closing process group.

18

19

Scope Management

20

Work Breakdown Structure (WBS) WBS is deliverable oriented. Not only the customer deliverables but all

.

the deliverables

21

There are few rules for creating a WBS. WBSs created by different –people for same projects may be different. Following rules should be followed – It is created with the help of the team. The first level is completed before the project is over. Each level of the WBS is a smaller piece of the level above. The entire project is included in each of the highest levels of the WBS. Eventually some levels will be broken down further.  Includes only work needed to create deliverables  Work not in the WBS is not part of the project.  Continues breaking down the project until you reach what are called work packages (tasks) –    

• • • • •

Can be realistically an confidently estimated Cannot be logically subdivided further Can be completed quickly Have a meaningful conclusion and deliverable Can be completed without interruption. (Without the need for more information)

MOST COMMONLY  The top level of the WBS is the Project Title.  The first level is the same as Project SDLC. (Analysis, Design etc)  The second and later level breaks the project into smaller pieces.

22

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; this is its process. These activities can be organized in different ways and we can call these PROCESS MODELS. Process Models are –  Waterfall Model  Spiral Model  V- Model  Software Prototyping

23

Waterfall Model To follow the waterfall model, one proceeds from one phase to the next in a purely sequential manner. For example, one first completes requirements specification, which are set in stone. When the requirements are fully completed, one proceeds to design. The software in question is designed and a blueprint is drawn for implementers (coders) to follow — this design should be a plan for implementing the requirements given. When the design is fully completed, an implementation of that design is made by coders. Towards the later stages of this implementation phase, separate software components produced are combined to introduce new functionality and reduced risk through the removal of errors. Thus the waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. However, there are various modified waterfall models (including Royce's final model) that may include slight or major variations upon this process.

24

Spiral Model The spiral model is a software development process combining elements of both design and prototypingin-stages, in an effort to combine advantages of topdown and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.

25

Spiral Model The steps in the spiral model iteration can be generalized as follows: The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. A preliminary design is created for the new system. This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. A second prototype is evolved by a fourfold procedure:    

evaluating the first prototype in terms of its strengths, weaknesses, and risks; defining the requirements of the second prototype; planning and designing the second prototype; constructing and testing the second prototype.

26

27

V Model The V-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V.

28

29

Software Prototyping Software prototyping, an activity during certain software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed. A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation. The conventional purpose of a prototype is to allow users of the software to evaluate developers' proposals for the design of the eventual product by actually trying them out, rather than having to interpret and evaluate the design based on descriptions. Two Types  Throw-away Prototypes – • The prototype is used to test out some ideas and is then discarded when the true development of the operational system is commenced.  Evolutionary Prototypes – • The prototype is developed and modified until it is finally in a state where it can become the operational system.

30

Software Prototyping - Benefits Learning by doing Improved Communication Improved user involvement Clarification of partially known requirements Demonstration of the consistency and completeness of a specification Reduced need for documentation Reduced maintenance cost Feature constraint Production of expected results

31

Incremental Delivery Plan This approach breaks the application down into small components which are then implemented and delivered in a sequence. Each delivered sequence must give some benefit to the user. (Phased Delivery) Advantages – Feedback from early increments improves the later stages The possibility of changes in requirements is reduced because of the shorter time span Users gets benefits earlier than normal conventional approach. Early delivery of some useful components improves cash flow because you get some ROI early.  Smaller sub projects are easier to control.    

Disadvantages –  Later increments might require modifications in previous increments. This is known as software breakage.  Software developers might be more productive in large systems as compared to smaller ones.

Selecting the most appropriate model – think????

32