Modeling Software Maintenance in SEER-SEM

Transcription

1 Modeling Software Maintenance in SEER-SEM Each program-level work element can include a detailed, year-by-year maintenance model. SEER- SEM estimates the effort and cost of software maintenance using a sophisticated supplementary model. Together with development cost estimates, you can obtain a cradle-to-grave cost picture for a software project. Tradeoffs can be made by comparing life-cycle costs against differing development methods and practices. The software maintenance model described below has been part of SEER-SEM since the release of version 8.2. Current versions of SEER-SEM maintain backwards compatibility with the maintenance model that was in use prior to version 8.2. By default, however, older estimates will be automatically converted to the current maintenance model. To find out how to retain the earlier maintenance model when you open an older SEER-SEM estimate, please see the SEM 8.1 (or earlier) Compatibility section of this document. The Maintenance Tab Below, you will find detailed descriptions of the inputs on the Maintenance tab in the SEER-SEM inputs window. SOFTWARE MAINTENANCE Parameter Category. These parameters are available only at the Program WBS element level. To activate maintenance estimation, enter the total number of years for which the software will be maintained. The probability or confidence level of estimates used to compute effort or schedule can be independently assigned using Options menu tuning commands. It includes the following parameters: Years of Maintenance, Maintenance Start Date, Annual Growth, Annual Change Rate, Personnel Differences, Development Environment Differences, Maintenance Level (Rigor), Maintainability, Annual Productivity Gain, Percent To Be Maintained, Maintenance Size, Steady State Maintenance Only, Corrective, Preventive, Adaptive, Perfective, Enhancements, Minimum Maintenance Staff (Optional), Maximum Maintenance Staff (Optional), Coverage Hours/Day, Coverage Days/Week, Staff Shifts/Day, and Staff Resources. Years of Maintenance Parameter. Enter the number of years for which software maintenance costs will be estimated. Maintenance begins when operational test and evaluation is completed. You can enter partial years: 1.53, 0.75, etc. Maintenance Start Date Parameter. The date on which maintenance will begin. If no date is entered, maintenance will begin when operational evaluation and test is completed (the computed value). To override the computed value, click on the Use computed value checkbox so that it is not checked, then enter the new value. If you have already entered a start date and wish to revert to the computed start date, enter 0 into the date field. Page 1

2 Annual Growth Parameter Category. The anticipated size growth from the point immediately after the software is turned over to maintenance to the end of the maintenance cycle. Software growth may include additions of new functionality. Major enhancements should be modeled separate as new developments or incremental builds. 100% Very high, major updates adding many new functions 35% High, major updates adding some new functions 20% Nominal, minor updates with enhancements to existing functions 5% Low, minor enhancements 0% Very low, sustaining engineering only This is a category parameter, along with a series of inputs which will appear below it when you set the Years of Maintenance parameter to anything other than 0. Each input in the series is numbered; the number of inputs corresponds to the number entered in the Years of Maintenance parameter. Annual Change Rate Parameter Category. Average percent of the software impacted by software maintenance and sustaining engineering for the given year. This could include changes, revalidation, reverse engineering, redocumentation, minor changes for new hardware, or recertification. 35% Very High 15% High 11% Nominal 5% Low 0% Very Low This is a category parameter, along with a series of inputs which will appear below it when you set the Years of Maintenance parameter to anything other than 0. Each input in the series is numbered; the number of inputs corresponds to the number entered in the Years of Maintenance parameter. Defects by Year Parameter Category. The expected value of defects fixed per year. The default value is computed. Defect Resolution Time (hours) by Year Parameter Category. The average time in hours that a defects is resolved. The default value is computed. Personnel Differences Parameter. Rate the maintenance personnel's capabilities and experience in comparison to the development personnel's capabilities and experience. If maintenance only is being estimated as a separate Program WBS element, this parameter should be set to Nominal, and the Personnel Capabilities and Experience parameters should be rated individually. Page 2

3 Very High High Nominal Low Very Low Significantly better than development personnel. Slightly better than development personnel. Same as development personnel. Somewhat less than development personnel. Significantly lower than development personnel. Development Environment Differences Parameter. Rate the quality of the maintenance environment in comparison to the tools and practices used in the development environment. If maintenance is being estimated as a separate Program WBS element, this parameter should be set to Nominal, and the Development Support Environment parameters should be rated individually. Very High High Nominal Low Very Low Significantly better than development environment. Slightly better than development environment. Same as development environment. Somewhat worse than development environment. Significantly worse than development environment. Maintenance Level (Rigor) Parameter. The thoroughness with which maintenance activities will be performed. Very High High Nominal Low Very Low Thorough maintenance for all types of software activities, including regular documentation updates. Software maintenance is well planned in both the long and short term with frequent reviews of priorities. A dedicated staff is assigned for maintenance. Software will remain useful and not degenerate over time. Complete maintenance including maintenance planning and priority review. Software documentation is updated on a semiregular basis. Software will not degenerate over time. Average maintenance activity. Short-term planning and prioritization of maintenance. Documentation is updated less than once a year (change pages and addenda). Software will become less useful over time. Basic maintenance with most activity being reactive to emergencies and problems as they arise. No planning of maintenance activity. Documentation is updated only with page and addenda changes. Software will degenerate over time. Bare bones maintenance. Nondedicated team doing emergency fixes. Maintenance is performed on an ad hoc, sporadic basis. Little to no documentation update. Software will degenerate rapidly. This setting may represent sustaining engineering effort of a delivered incremental build by the developers during development of subsequent builds. Page 3

4 Maintainability Parameter. Measures how easy it is to analyze, change, and test the application or product. The more maintainable the application is, the less effort will be spent. The following rating scale provides examples of degrees of maintainability. In many cases the maintainability attributes of an application will be mixed (i.e. coding standards followed, but overall design is difficult to ascertain). Please refer to the scorecard for further guidance on rating this parameter. Very High High Nominal Low Very Low Application code reads intuitively and is easily understood. Interfaces and build procedures are well documented and easily followed. Design concepts such as high cohesion, loose coupling, encapsulation are highly evident. Design specifications are available and reflect the current implementation. Application test cases and procedures available and ready to run in a turn-key fashion. Test environments and platforms available. Code follows an understood set of standards that foster readability. Design documentation is available but may not reflect recent changes. Good design concepts such as high cohesion, low coupling and encapsulation are present. Code is reasonably well documented with comments and prologues with basic adherence to coding standards. Reasonable attempts at best design practices have been followed, but no added effort to make the application easy to maintain was followed in initial implementation. Test cases and procedures may require some updates. Code follows no standards and is poorly documented. Poor design structure that requires greater examination before changes can be made. Test cases and procedures exist but require extensive updates, test platforms may be non-standard. Poorly formed code, minimal comments and prologues. No documentation for design or interface specifications available. No relevant test cases or procedures to draw upon. Requires nonstandard or out of date platforms and tools that are difficult to access. Maintainability Scorecard Because maintainability covers several facets, rating it may pose a challenge. The following scorecard can assist in determining the maintainability rating. For each of the criteria listed below, mark the number in the column that best describes how well it applies to the work element, then total the marked numbers for each column. Add the column totals to determine the maintainability score. The numeric scores correspond to the maintainability ratings in the manner shown below: Very High = 12 Nominal = 6 Very Low = 0 Page 4

5 Item Not At All Partially Fully Code or modules are easily understood Build procedures and dependencies are well-documented and easily followed. Designs are available and reflect the current implementation. Test cases and procedures available and ready to run in a turn-key fashion. Test environments and platforms available Code standards are being used that make it readable and easily understood Score = Total + Total + Total Annual Productivity Gain Parameter. Percent productivity improvement per year for corrective effort. Productivity improvements will reduce the effort required to fix defects. Maintenance Size Assumptions Parameter Category. This is a category-level parameter. It includes the following maintenance size assumption inputs: Percent To Be Maintained Parameter. Estimate the percentage of the total that will be maintained. For example, if part of the software is in a read-only memory and cannot be changed, exclude it from software maintenance costs by reducing this percentage. Maintenance Size Parameter. Determines whether new, total, or effective size should be used to estimate maintenance. New Size Total Size Effective Size All new size from lines, functions or other size metrics used. All size from both new and existing lines, functions or other metrics. Only effective size based on new size plus rework of existing size. Maintenance Estimate Options Parameter Category. This is a category level parameter. Input values may not be entered at this level. Parameters included in this category are: Steady State Maintenance Parameter. Determine whether a steady state staffing level is estimated for maintenance requirements. The default is Yes: maintenance is estimated based on a fixed staff level over the period of maintenance. YES NO Estimate maintenance with a fixed annual staff level. Estimate maintenance with additional effort in the first years. This is appropriate for new or immature systems that may have a higher level of undetected defects. Page 5

6 Corrective Maintenance Parameter. Include correction of software problems in maintenance: fixes, addressing design flaws, etc. Preventive Maintenance Parameter. Include anticipating and preventing software errors, malfunctions, and breakdowns. Adaptive Maintenance Parameter. Include adapting software to current operating environments in maintenance: updating the software to the latest operating systems, compilers, hardware devices, COTS software, etc. Porting the software to a new environment if major re-engineering is required is beyond the scope of normal maintenance activities, and should be estimated separately as a new software development activity. Perfective Maintenance Parameter. Include fine tuning and perfecting the software in maintenance: adjusting control or data files, refining performance issues, and other minor finishing touches. Enhancement Maintenance Parameter. Include adding software enhancements in maintenance. This includes only minor enhancements, primarily to compensate for immediate user needs or unexpected deficiencies in the software. Any major re-engineering should be estimated separately as a new software development project. Minimum Maintenance Staff (Optional) Parameter. The minimum number of personnel who will be assigned to maintain the software. Use this parameter for fixed staffing or level of effort maintenance. A fractional number can be entered. Maximum Maintenance Staff (Optional) Parameter. The maximum number of personnel assigned to maintain the software. Can be used for fixed staffing or level of effort maintenance. A fractional number can be entered. Maintenance Coverage Requirements Parameter Category. This is a category-level parameter. It includes the following maintenance coverage inputs: Maintenance Coverage Hours/Day Parameter. Number of hours per day that the staff must be available to address defect driven corrective maintenance. Coverage Hours/Day ranges from 8 to 24. The coverage hours/day and days/week determine when staff needs to be open and available for fixing defects. Maintenance Coverage Days/Week Parameter. The number of works days per week that the staff must be available to address defect driven corrective maintenance. Coverage Days/Week ranges from 5 to 7. Page 6

7 The coverage hours/day and days/week determine when staff needs to be open and available for fixing defects. Maintenance Staff Shifts/Day Parameter. The number of staff shifts per day, ranging from 1 to 4. The default value is computed, and is based on the ratio of Coverage Hours/Day to Staff Work Hours/Day, rounded up. To overwrite the computed value, uncheck the Use computed value checkbox in the parameter input dialog box, then enter a new value for the input. Maintenance Staff Resources Parameter. Choice indicating whether the software maintenance staff works exclusively on the application being maintained, or if there is a pool of shared maintenance personnel who can support numerous applications. There are two options: Item Shared Dedicated Estimates the incremental staff level required for corrective maintenance for the application. Coverage requirements will not impact effort under the Shared option. Estimates to total staff required to support corrective maintenance activity for the given coverage requirements. The Dedicated option will estimate staff to the nearest full time equivalent for each shift that needs to be covered. SEM 8.1 (or earlier) Compatibility The Version 8.1 and Earlier Maintenance Model The Maintenance inputs described above are for the current SEER-SEM Maintenance model. If you are opening an older estimate and want to maintain backward compatibility with the less detailed Maintenance model used by SEER-SEM 8.1 and earlier versions, you can activate it by clicking on the SEM 8.1 (or earlier) Compatibility checkbox in the Project Parameters dialog box (Options / Set Project Parameters). When the older Maintenance model is activated, many of the standard Maintenance inputs will no longer be available, and older Maintenance inputs which are not used by the current model will become available. Note: If the current Maintenance model is turned on (the default setting) when you open an estimate created using the older Maintenance model, SEER-SEM will apply the new model automatically. You should only turn SEM 8.1 (or earlier) Compatibility on if you specifically want to retain the earlier Maintenance model in an older estimate. Otherwise, you should use the current Maintenance model. Earlier Maintenance Inputs The older Maintenance model uses the following inputs: SOFTWARE MAINTENANCE o Years of Maintenance o Separate Sites o Maintenance Growth Over Life Page 7

8 o Maintenance Start Date o Personnel Differences o Development Environment Differences o Annual Change Rate o Maintenance Level (Rigor) o Maintenance Size Assumptions Percent To Be Maintained Maintenance Size o Maintenance Estimate Options Steady State Maintenance Only Corrective Adaptive Perfective Enhancements Min Maintenance Staff (Optional) Max Maintenance Staff (Optional) Differences Between the Old and Current Maintenance Models In the earlier Maintenance model, there were no growing lists of inputs describing individual Years of Maintenance. The Maintenance Growth Over Life and Annual Change Rate inputs applied to every Year of Maintenance without specifying growth or change rates for individual years. The earlier model also did not include the Defects, Defect Resolution Time, Annual Productivity Gain, Preventive, and Coverage Requirements inputs. The earlier Maintenance model did include the following inputs, which are not part of the current Maintenance model. Separate Sites Parameter. Enter the number of separate operational sites where the software will be installed, and where users will have significant input into system enhancements. Maintenance Growth Over Life Parameter. Estimate the percentage of the anticipated size growth from the point immediately after the software is turned over to maintenance to the end of the maintenance cycle. An input of 100% means that the software will double in size. Software growth may include additions of new functionality. (Major enhancements should be modeled separately, as new developments or incremental builds, and the effect of these should not be included.) 100% Very high, major updates adding, many new functions. 35% High, major updates adding, some new functions. 20% Nominal, minor updates with enhancements to existing functions. 5% Low, minor enhancements. 0% Very low, sustaining engineering only. Page 8

9 Activating SEM 8.1 (or earlier) Compatibility in the Project Parameters Dialog Box If you want to open a project file created with SEER-SEM 8.1 or an earlier version, and you do not want to apply the maintenance model changes which were introduced with SEER-SEM 8.2, you can click on the SEM 8.1 (or earlier) Compatibility checkbox in the Set Project Parameters dialog box (Options / Set Project Parameters) so that it is marked. If the box is not checked: Maintenance will be based on the model introduced with SEER-SEM 8.2. o Broken out into individual Years of Maintenance. o Includes detailed Coverage Requirements. The following inputs will be included the Maintenance tab: o Annual Growth. o Defects. o Defect Resolution Time. o Maintainability. o Annual Productivity Gain. o Preventive (in the Maintenance Estimate Options category). o The Coverage Requirements category. The following inputs will be growing lists: o Years of Maintenance. o Annual Growth. o Annual Change Rate. o Defects. o Defect Resolution Time. The following inputs from the earlier model will not be present: o Separate Sites. o Maintenance Growth Over Life. If the box is checked: Maintenance will be based on the model used before SEER-SEM 8.2. o Detailed inputs for individual Years of Maintenance will not be available. o Separate Sites will be included. o Detailed Coverage Requirements will not be included. Note that in addition to the differences listed, SEER-SEM outputs which depend on Maintenance data will also reflect the differences between the two models. Page 9