02 Software Project Planning
-
Upload
prashant66000 -
Category
Documents
-
view
665 -
download
2
Transcript of 02 Software Project Planning
1
Software Project Management
Software Project Planning
2
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.
3
4
5
Identifying Needs
The project manager drives the scope of the project.The project manager should identify and
talk to the main stakeholderThe 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
6
Vision and Scope Document
A typical vision and scope document follows an outline like this one:
1. Problem Statementa) Project backgroundb) Stakeholdersc) Usersd) Riskse) Assumptions
2. Vision of the Solutiona) Vision statementb) List of featuresc) Scope of phased release (optional)d) Features that will not be developed
7
Statement of Work
The statement of work (SOW) is a detailed description of all of the work products which will be created over the course of the project. It includes:A list of features that will be developedA description of each intermediate deliverable or
work product that will be built.The estimated effort involved for each work
product to be delivered
8
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
9
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.
10
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
11
Risk Plan Example
12
Stepwise Project Planning
Step 0 Select ProjectStep 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
13
Stepwise Project PlanningStep 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 activityStep 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
14
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
15
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.
16
17
Scope Management
18
Work Breakdown Structure (WBS)
WBS is deliverable oriented. Not only the customer deliverables but all
the deliverables.
19
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.
20
Project Plan Creation (mpp)
Project Plan Tutorial Sample Project Plan
21
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
22
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.
23
Spiral Model
The spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down 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.
24
Spiral ModelThe 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.
25
26
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.
27
28
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.
29
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
30
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????