DOC PREVIEW
USC CSCI 510 - usccse2002-510

This preview shows page 1-2-3-4-5 out of 16 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 16 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Assumptions2. Using “Earned Value” for Feedback Control of Software DevelopmentValue-Based Software Engineering: Reinventing “Earned Value” Monitoring andControlBarry Boehm, Li Guo Huang, USCNovember 20021. IntroductionThe Value-Based Software Engineering (VBSE) agenda described in [Boehm, 2002b] has the objectives of integrating value considerations into current and emerging software engineering principles and practices, and of developing an overall framework in which they compatibly reinforce each other. One of these areas is value-based planning and control, including principles and practices for extending traditional cost, schedule, and product planning and control techniques to include planning and control of the value delivered to stakeholders.Current approaches for software planning and control, such as those in the Software Capability Maturity Model [Paulk et al., 1995] focus on the monitoring and control of the project’s planned commitments, efforts, costs, schedules, technical activities, risks, product sizes, and critical computer resources. They do not address the monitoring and control of the reasons for which the project was established, or of the actual value likely to be realized by the project’s results.Recent updates such as the Capability Maturity Model-Integrated (CMMI) [Ahern-Clouse-Turner, 2001; SEI, 2002] make some progress toward value-based projectdefinition and planning. But their project monitoring and control processes remain focused largely on monitoring project progress with respect to execution plans. Neglecting to monitor and control with respect to the value added by software was not too risky when business values changed slowly and software was a minor contributor to business values. However, such neglect is increasingly risky in today’s (and tomorrow’s) world of software-driven product lines and tornado-driven [Moore, 1995] changes in the information technology marketplace. Many projects have faithfully delivered products on or near their planned budgets and schedules, only to find out that the business need for the product has largely disappeared, or that competitors have already captured its planned market niche.A particular anomaly in the monitoring and control area is the “Earned Value Management System” [Air Force, 1978]. It is a most useful technique for monitoring andcontrolling the process of a complex project. But it has absolutely nothing to say about the stakeholder value of the system being developed. It serves a purpose, but needs to be incorporated into feedback control systems which focus on the real stakeholder value being earned. In section 2, we summarize how current earned value systems are used for feedback control of software development. In sections 3 and 4, we provide an alternativeapproach for project feedback control which focuses on the actual stakeholder value likely to be earned by completing the project. Section 3 provides a framework for monitoring and controlling for value in terms of the DMR Benefits Realization Approach and on business case analysis, using an order processing system as an example. Section 4elaborates on the value-based feedback control mechanisms and illustrates them via the example. Section 5 presents the conclusions and promising directions for future research and development.2. Using “Earned Value” for Feedback Control of Software DevelopmentPerforming feedback control of large software projects becomes very difficult, because there will be hundreds of tasks going on concurrently. Some tasks will be ahead on budget and schedule; others will be behind. Current “earned value” [Forsberg et al., 2000] systems enable large-project managers to achieve better visibility and control of such complex situations. Most software cost and schedule estimation models include breakdowns of a project’sbudget and schedule by software component, development phase, and task activity. This enables a project to set up an Earned Value system in which the estimated cost for each task can be considered as the value earned for the project when the task is completed. The Earned Value System works as follows:1. The project develops a set of tasks necessary for completion, and associated budgets and schedules for each.2. Each task is assigned an earned value (EV) for its completion, usually its task budget.3. As a project proceeds, three primary quantities are reviewed at selected times T:a. The Budgeted Cost of Work Scheduled (BCWS): the sum of the EV’s of all tasks scheduled to be completed by time T.b. The Budgeted Cost of Work Performed (BCWP), or project level earned value: the sum of the EV’s of all tasks actually completed by time T.c. The actual cost of the project through time T.4. If the BCWP (budgeted cost of work performed) is equal to or greater than the BCWS (budgeted cost of work scheduled), then the project is on or ahead of schedule.5. If the BCWP is equal to or greater than the project cost, then the project is on or ahead of budget. 6. If the BCWP is significantly less than the BCWS and/or the project cost at the time T, then the project is significantly overrunning its schedule and/or its budget, and corrective action needs to be performed.The six steps are summarized in the earned value feedback process shown in Figure 1.Figure 1. “Earned Value” Feedback Process2.1 An Earned Value System ExampleFigure 2. Earned Value System ExampleFigure 2 provides an example to explain how the Earned Value System can help us to assess the project progress and likely cost to complete a software project. For simplicity, we assume that the project starts with four sequential tasks: prototypes, analyses, plans and specs. BCWS: Budgeted Cost of Work ScheduledBCWP: Budgeted Cost of Work PerformedCost: Actual Cost of Work PerformedDetermine corrective actionsDetermine corrective actionsNoNoDevelop/updateplans, BCWSPerformto plansBCWP>BCWS?BCWP>Cost?YesYesBudgeted Cost of Work Scheduled Budgeted Cost of Work PerformedProject Expenditures Cost($)Time(Months)SpecsPlansAnalyses Prototypes 1 2 3 4 5 10,00020,00030,00040,00050,000The first step is to assign an earned value to each task. We estimate that the completion of prototypes will take 2 months and $15,000, the analyses one month and $10,000, the plans one month and another $10,000, and the specs one month and $15,000. Therefore, the cumulative earned value we can get


View Full Document

USC CSCI 510 - usccse2002-510

Download usccse2002-510
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view usccse2002-510 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view usccse2002-510 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?