Coursehero >> Indiana >> IUPUI >> CSCI 299

Course Hero has millions of student submitted documents similar to the one below including study guides, homework solutions, papers, exam answer keys and textbook solutions.

the Creating Project Plan This article describes how to create a complete project plan using your insight into project cost and schedule. This includes a work breakdown structure, a deliverable plan and estimating for maintenance. Author: William Roetzheim Co-Founder, Cost Xpert Group, Inc. Creating the Project Plan One of the most difficult tasks for a project manager is the creation of the project baseline plan that will be used to manage the development effort. Even with a correct estimate of effort and time, it is easy to forget tasks, incorrectly allocate effort among tasks, or fail to allow enough resources for maintenance. Even in this area, we find that software estimating can be a science, not just an art. It really is possible to accurately and consistently estimate development costs and schedules for a wide range of projects, then quickly create a project plan. This series of 4 articles provides you the tools you need to understand step-by-step approaches to estimating the cost and schedule for your projects. Although there is a wide range of software cost estimating tools on the market to help with this process, we focus in this series of articles on understanding the fundamental concepts. You will be able to implement the concepts in these articles using nothing more complicated than a spreadsheet. In our first article, estimating software costs, we covered the various methods of estimating the size of a program (called program volume). We discussed the traditional measures of Lines of Code and Function Points, plus introduced other approaches. At the end of this article, we ll show you how to prepare a preliminary, unadjusted estimate using this information. In our second article, Project Cost Adjustments, we covered the concept of project cost adjustments for variations in the project environment. At the end of this article, you were able to create an accurate estimate of the time and cost required to develop a new application. Our third article, Dealing with Reuse, explained how to quantify the impact of software reuse and commercial components/libraries on your estimate. Finally this last article in the series describes how to use your insight into project cost and schedule to create a complete project plan. Creating the Work Breakdown Structure The most fundamental building block of a project plan is the Work Breakdown Structure, or WBS. The WBS contains a list of tasks to be accomplished. You Page 1 of 7 can implement a template WBS in a spreadsheet as a list of task names, task percentages of effort, and task descriptions. For example, a simple WBS template applicable for some e-commerce jobs is as follows: Task Project Planning and Mgmt Define Business Strategy Define Marketing Strategy Define Requirements Design site Build site Test site Deploy site Percent Description 10 Project estimating, planning, and risk management. Define the business strategy and document it in a strategic 4 brief. Define the marketing strategy and document it in a creative 4 brief. Define system requirements in both documentation and 4 prototype form, plus define a production/style guide. Prepare the functional specifications, technical 30 specifications, site architecture, and test plan. Build the site, including the front end, middle-tier, agents, 19 and interfaces. 19 Test the site, both at the unit level and the integration level. Deploy the site, including acceptance testing and user 10 documentation when required. Once you ve determined the correct total effort for the job using the approach described in the earlier articles in our series, you can use the percent of effort to quickly and easily allocate that effort among all of the tasks in your WBS. Creating the Deliverable Plan On most projects, you will be required to create technical documentation. This is typically necessary to facilitate communication during development, to assist in maintenance, and to provide milestones for payment. The first step is obviously to create another template, this time of document titles and descriptions. Templates of documentation are often referred to as standards. However, we can go beyond this initial step. It is very valuable to include an estimate of the page count for each document in your project plan. This information is useful for: Setting customer/client expectations; Defining the correct document scope to the developers that will be writing the documents; and Estimating review time. Page 2 of 7 We have found that the correct number of pages of documentation can be predicted using the staff months of development effort as the input. This is accomplished using the following formula: Pages = A * B( PersonMonths C ) To apply this formula, you raise the person months of effort to a variable (C), multiply the results times another variable (B), then add a third variable (A). The following table contains a sample deliverable planning standard applicable for many e-commerce development projects. Deliverable Document A B C Description Software Development Plan (SDP) The Software Development Plan (SDP) describes a developer's plans for conducting a software development effort. This is expressed in the form of a project Gantt chart supplemented by one or more Project Work Orders covering the various phases of 5 0.08 0.91 work. Documents strategic business objectives, measures of business success, stakeholders, and 0.9 0.91 stakeholder objectives. Defines target audience(s), objectives, market and product positioning, branding, and relationship between web strategy 0.9 0.91 and overall market strategy. Strategic Brief 2 Creative Brief 2 Software Requirements Specification Prototype (SRS) The Software Requirements Specification (SRS) specifies the requirements for a computer program and the methods to be used to ensure that each 3 1.21 0.91 requirement has been met. 1 0 1 System prototype. Defines back-end and middle-tier functional requirements from a 4 0.91 business perspective. Defines the technical details of the system design, including object 4 0.91 design. Functional Specifications 0 Technical Brief 0 Site architecture Description of the site architecture with sufficient detail to allow the 0 2.14 0.91 site to be configured for Page 3 of 7 deployment. The Software Test Plan (STP) describes plans for acceptance testing of a computer program. It describes the software test environment to be used for the testing, identifies the tests to be performed, and provides 5 0.12 0.91 schedules for test activities. The Software Design Description (SDD) describes the design of a computer program. It describes the program wide design decisions, the software architectural design, and the detailed design needed to implement the software. It includes the middle-tier object and application server design; pseudocode for all key algorithms and business rules; field mappings for all screens; sort, select, and display requirements for reports; and detailed data format 8 0.91 specifications for all interfaces. Software Test Plan (STP) Software Design Description (SDD) 0 Software Test Description (STD) The Software Test Description (STD) describes the test preparations, test cases, and test procedures to be used to perform acceptance testing of a computer 5 2.27 0.91 program.. The Software User Manual (SUM) tells a hands-on software user how to install and use a computer program. It includes a tutorial section describing how to accomplish specific user work tasks identified as Operational Scenarios in the Software Requirement Specification, and also offers a comprehensive reference to all screens, reports, 2.1 0.91 and menu choices. Software User Manual (SUM) 15 Using this standard, let s calculate the estimated page count for Software Design Description (SDD) on a 50 person month of effort project. We begin by noticing that the values for A, B, and C are 0, 8, and 0.91 respectively. The calculation is then as follows: Page 4 of 7 Pages = A + B( Effort C ) = 0 + 8(50 0.91 ) = 8 * 35 = 280 pages Estimating Maintenance Effort It is often necessary to estimate maintenance effort as part of your planning process. You may need to plan adequate maintenance staff. You may need to bid a warranty on the software, requiring that you estimate the effort required to provide these warranty services. First and foremost, you must ensure that you have a common understanding of maintenance work with your customer. We define three categories of maintenance activities: Corrective maintenance Adaptive maintenance Perfective maintenance Corrective maintenance is your standard bug fixes. Adaptive fixes involves modifications to the software required by changes in the operating environment (database upgrades, operating system upgrades, compiler version changes, and so on). Perfective maintenance is the most tricky to understand. It involves changes to the code to allow the software to meet the same requirement but in a significantly more acceptable manner. The largest example of perfective maintenance is modifications of the code to improve performance in trouble spots. Note that any changes to the code to add new functionality are not considered maintenance. Nor are any changes that are based strictly on user preference. The following figure shows the approximate distribution of maintenance effort based on one study by Capers Jones. The following table shows the proper categorization of each maintenance activity based on our approach. Category on figure Emergency program fixes Routine debugging Accommodate changes to input data files Accommodate changes to hardware Maintenance category Corrective Corrective Adaptive Adaptive Page 5 of 7 operating system Enhancements for users Improve documentation Improve code efficiency Other Not included as maintenance Not included as maintenance Perfective Other Emergency program fixes Routine debugging Accommodate changes to input data, files Accommodate changes to hardware operating systems Enhancements for users Improve documentation Improve code efficiency Other 9.3 12.4 17.4 6.2 41.8 5.5 4.0 3.4 We have found that steady state maintenance annual effort is proportionate to development effort (this conclusion was initially proposed by Barry Boehm, then confirmed by numerous researchers). The range varies between 3% of development effort and 20% of development effort. The vast majority of projects fall in a much more narrow range of 12% of original effort to 17% of original effort. For example, suppose we have a project that requires 50 person months of development effort. We estimate that the maintenance effort will be 15%. The annual budget for maintenance then needs to be 50 * .15, or 7.5 person months of effort. I qualified this statement by saying the steady state maintenance . We have found that it takes 4 years of maintenance following delivery to reach steady state for a typical system. During this period of time, the maintenance effort will be greater than the steady state effort. The optimum maintenance effort actually shows an exponential drop off from a value roughly twice the steady state value immediately following delivery to the steady state value at the start of year 4. Page 6 of 7 During this time, the additional effort is spent on corrective and perfective maintenance. Page 7 of 7

Find millions of documents here - Study Guides, Homework Solutions, Papers, Exam Answer Keys and more. Course Hero has millions of course related materials that will enable you to learn better, faster and get an A in all your courses.
Below is a small sample set of documents: