Managing Project Scope in Software Development, Slides of Software Engineering

Download Managing Project Scope in Software Development and more Slides Software Engineering in PDF only on Docsity!

SOFTWARE REQUIREMENTS

ENGINEERING

LECTURE

MANAGING THE

SCOPE

Project

Scope

3  (^) As with any professional activity, meeting commitments in application development involves making realistic assessments of project resources , time lines, and objectives before the activity begins.  (^) For software development, these factors combine to create the "scope" of the project.  (^) Project scope is a function of:  (^) The functionality that must be delivered to meet the user's needs  (^) The resources available to the project  (^) The time available in which to achieve the implementation  (^) Figure below provides a perspective of the "box" we can use to represent project scope.

The Problem of Project

Scope

5  (^) If we want to ensure our credibility and gain the confidence of our customers, it is important that we not slip the schedule. The total and the functionality we can deliver is obviously limited by the available time  (^) So, for purposes of scope analysis, we'll treat time as a fixed factor. (fixe d) available resources (also fixed), so the achievable scope is the area of the box.  (^) If the effort required to implement the system features is equal to the resources available during the scheduled time, the project has an achievable scope. However, experience has shown that there is often a poor match between these factors in the scope equation.

The Problem of Project

Scope

6

 What happens when a project proceeds with a 200 percent initial

scope?

 (^) If the intended features of the applications were completely independent, which is unlikely, only half of them will be working when the deadline passes. The product provides only half of the intended utility. The features don't work together, and don't produce any useful combined functionality.  (^) An application with reduced scope will be deployed in this case.  (^) Consequences include::  (^) Seriously unhappy customers  (^) Missed marketing commitments and  (^) Inaccurate manuals and promotional materials

The Requirements

Baseline

8  (^) A primary technique in scope management is to establish a high-level requirements baseline for the project (Figure 2).  (^) Baseline can be viewed as an itemizedset of features intended to be delivered in a specific version of the application. Figure 2 :: Requirements baseline

The Requirements

Baseline

9  (^) The first step in creating the baseline is simply to list the features  (^) It is suggested that any new system, no matter how complex, Max have 25– 50 features.  (^) How to get a list of proposed features. ???

Setting

Priorities

11  (^) Establishing the relative priorities for the feature set is important to scope management  (^) During prioritization, it is important that the customers and users, or other representatives—not the development team—set the initial priorities.  (^) In our project example, let's assume that we vote on the priority of each feature, using a critical- important and useful scale; the results of this exercise are shown in Table 1. Table 1:: Prioritized Features List Features Priorities Feature 1 : SQL database support Critical Feature4: Employee Complete Information bank Critical Feature6: Automatic Leave management support Critical Feature3: Provide Modification facility to Employee Important Feature 2 : Multiuser security Important Feature 5 : Generation of Employee Report Important Feature7: Online Notification facility for Employee Information Useful Feature8: Integration with other database Useful

Assessing

Effort

12

 The next step is to establish the rough level of effort

implied by each feature of the proposed baseline.

 The team may wish to use "team-weeks" or "team-months” as a gross

estimate of the total impact of a feature on the project. This rough

estimate serves as a substitute for a more detailed estimate.

 Then, using these totals, the team can determine where to

initially draw the baseline.

Adding the Risk

Element

14  (^) Another aspect of managing scope is estimating the " risk " associated with each feature.  (^) In this context, we'll consider risk to be the probability that the implementation of a feature will cause an adverse impact on the schedule and/or the budget.

Adding the Risk

Element

15  (^) Risk gives us a measure of the potential impact of including a particular feature within the project baseline. A high-risk feature has the potential to impact the project negatively.  (^) Table 3 shows the revised features list also including the Effort and Risk Estimates for the prioritized features on a scale of Low, Medium, High. Table 3:: Prioritized Features List with Effort and Risk Estimates Features Priorities Effort Risk Estima tes Feature1: SQL database support Critical^ Medium^ Low Feature 4: Employee Complete Information bank Critical^ High^ Medium Feature 6: Automatic Leave management support Critical^ Medium^ Low Feature 3: Provide Modification facility to Employee Important^ Low^ Medium Feature 2: Multiuser security Important^ Medium^ High Feature 5: Generation of Employee Report Important^ Low^ Low Feature 7: Online Notification facility for Employee Information Useful^ Low^ Low Feature 8: Integration with other database Useful^ High^ Medium

Scope

Reduction

17  (^) If expectations are properly set and managed, anything that can be accomplished beyond the baseline will be a bonus. Table 4 applies this simple heuristic to the baseline for our sample project.  (^) Features below the baseline are now future features and will be considered in later releases. Table 4 :: Final Prioritization List Features Priorities Effort Risk Estimates Feature 1: SQL database support Critical Medium Low Feature 4: Employee Complete Information bank Critical High Medium Feature 6: Automatic Leave management support Critical Medium Low Feature 3: Provide Modification facility to Employee Important Low Medium Baseline (features above this line are committed features) Feature2: Multiuser security Important Medium High Feature 5: Generation of Employee Report Important Low Low Feature 7: Online Notification facility for Employee Information Useful Low Low Feature 8: Integration with other database Useful High Medium

Managing Your

Customer

1 8

Communicating the

Result

20  (^) If the project scope must be reduced, make sure that the customer is a direct participant. A customer who is part of the process will own the result. A customer who is excluded from the process will be unhappy and tend to blame the developers for not trying hard enough.  (^) Engaging the customer in this dialogue helps to avoid the embarrassment of missed schedules and missing features. Any extra features accomplished beyond the baseline will be perceived positively.

RESULT

S

Negotiating with the

Customer

21  (^) Almost all business processes require negotiation.  (^) Consider negotiating with a customer for a delivery date, negotiating your annual increase with your manager, negotiating an achievable quota for your sales team, or negotiating additional resources for your project.