SOFTWARE DEVELOPMENT PROJECT SUMMARY DATA

Transcription

1 SOFTWARE DEVELOPMENT PROJECT SUMMARY DATA L- *l. Project Name: Date: *2. Development Contractor/Organization: 3. Project Description 3.1 Mission Description 3.2 Major Hardware Interfaces: 3.3 Major System Functions: 3.4 Major Software Functions: - *3.5 Number of CSCIs (CPCIs): CSCI (CPCI) Names: (list on CSCI Form[~]) *3.7 System User: Development Contractor -- Other Commerci a1 Company - Department of Defense -- Other Government Agency - *3.8 System Class: *a. Platform: Standard Ground Systems - Military Mobile Systems - Real Time Ground Systems Commercial Avionics Mil Spec Avionics - Unmanned Space System Manned Space System - *b. Mode: (Normally mode wi 1 l be embedded for DOD software. ) Organic Semi -detached Embedded *3.9 Contract Type: - (e.g., CPFF, CPIF, FFP, etc.) NOTE: For 3.10 through 4, identify data source in sufficient detail so that - you could subsequently trace back to that da~ta source, if needed. *3.10 Modern Programning Practices (COCOMO "MODP") Very Low - Low - Nominal - Hi gh - Very High - (no use) (beginning use) (some use) (general use) (routine use) Source of data: -

2 *3.11 Schedule Accel eration/stretchout Assessment : Acceleration Stretchout Very Low Low Nominal Hl gh Very High d ( ) (85-9w ( )- (105-11m (115% +) Source of data: *3.12a Requirements Volatility e.g., project rework due to requirements changes ( COCOMO " RVOL" ) Low (essentially none) Nomi nal (small, non-critical redi rections) Hi gh (occasional moderate redirections) Very High Extra High Source of data: (frequent moderate or occasional major redirections) (frequent major redi rections) *3.12b Data Base Size (COCOMO "DATA") Low (very small effort) Norni nal (nominal size effort) High (1 arge easy effort) Very High (large and complex effort) Source of data: 4. Project man-power expenditures - indicate source of data. Project Activity Project Total Man-hours Source of Data Requirements Analysis Product Desi gn Programmi ng Test Pl anni ng Verify & Val idate Project Off i ce Configuration Mgt Quality Assurance Documentation 'Designates data required to cal i brate model.

3 COMPUTER SOFTWARE CONFIGURATION ITEM SUMMARY DATA ( ) NOTE: Because of the great variation in the number and size of Computer Software L Configuration Items (CSCIs) and/or data availability, it may not be practical to collect data for each CSCI. If CSCI data is not available, provide summary data for a1 1 (i.e., total program) CSCIs being developed. 1 CSCI Name: *2. Functional Description (brief): *3. Personnel - Experience & Capabilities A. Analyst Capabilities (ACAP) Very Low Low Normal High Very High 15t h 35th- 55t h- 7 5 t h 90th Percentile Percentile Percentile Percentile Percentile B. Analyst Experience (AEXP) Very Low Low Normal Hi gh Very High < 4 nos. exp. 1 y r 3 y r r 6 y r r 12 yrs. C. Programmer Capability (PCAP) Very Low Low Norma 1 High :. Very High 15t h 3 5 r 5 5 r 7 5 t h 90th L Percentile Percent i 1 e Percentile Percentile Percentile D. Languages Experience (LEXP) Very Low Low 1 mo. exp. 4 nos. Norma 1 1 yr. High 3 yrs. E. Virtual Machine (VEXP) Very Low Low Nomi na 1 High 1 mo. exp. 4 nos- 1 yr. 3 yrs- F. Support Software/Tool s Very Low Low Nomi nal High Very High 1 mo. 1-4 nos nos. 1-3 yrs. 3-6 yrs. *4. Reliability Requirement (RELY) Very Low Low Nomi na 1 High Very High Effect: slight Low, easily Moderate, High f% Risk to h u G inconvenience recov 1 osses recoverabl e 1 oss ci a1 1 oss life *5. Complexity (CPLX) Very Low Low (offline simple print routines) (offline data processing) Nominal (data processing and math routines) L.. High (some H/V 1/0 and advanced data structures) Very High (real time communications and advanced math) Extra High (extremely complex scientific processing such as satellite ephemeris calculations)

4 6. Size *6.1 Del i verable Lines of Source Code Exc *6.2 Non-del i verabl e Li nes of Source Code udi ng Documentati on: Excluding Documentation: 6.3 Operation Response Requirements Distr 6.1 (Total = 100%) bution As a Percent of Item A. Real-Time % B. On-Line % C. Time-Constrai ned % C. Non-Time Constrained % 6.4 Languages Used as a Percent of Item 6.1 (Total = 100%) A. Language: Percentage: B. Language: Percentage: C. Language: Percentage: D. Language: Percentage: *6.5 Modified and Adapted Code From Similar Projects (needed if Modified and/or Adapted Code was used) %of Modification Required Project # of DSLOC Desi gn Code Integration 7. Documentation (Total for all CSCIs) Document Title # of Paaes ist 'd or Act'l CSCI Devel opment Speci f i cat ion CSCI Product Specification Test Pl an Test Procedures Test Report User's Manual Operator's Manual Other: Other: 8. Software Failure Hi story Requirements Development Phase d of Software Failures/irrors Prel imi nary Design (Contract Award to PDR) Detailed Design (PDR to CDR) Code & Debug (CDR to Test & Integ Start) Test R Integration (T&I Start to FQT) System TestIIOC (FQT to Contract End) *Designates data required to calibrate model.

5 DEVELOPMENT (HOST) AND TARGET COMPUTER DATA FORM (9/18/87) 1. Target Computer 1.1 Manufacturer: Model Number: 1.2 Main Memory Size in Words: Word Si ze: Bits 1.3 Maximum Main Memory Size: 1.4 CPU Processing Speed: Number of CPUs: ~ Reserve Memory. Requi rement : - % Reserve Ti mi ng Requi rement : % Concurrent Development with Software: Yes No Virtual Machine Volatility: Low (VIRT) (Major change every 12 months, Minor: 1 month) Nominal (Major: 6 months, Minor: 2 weeks) High (Major: 2 months, Minor: 1 week) Very High (Major:. 2 weeks, Minor: 2 days) Percent Ut i 1 i zat i on : ~51% 51-70% 71-85% 86-95% >95% A. CPU Memory (STOR) B. Execution Time (TIME) CPU Memory Constraint Eva1 uation: No Memory Economy Measures Required <25% of Source Code is Time Constrained - (50% of Source Code is Time Consstrained - <75% o f Source Code is Time Constrained CPU Time Constraint Evaluation: No software is CPU Time Constrained - (25% of Source Code is Time Constrained - <50% of Source Code is Time Constrained - ~75% of Source Code is Time Constrained - CSCIs Hosted on This Computer: L 2. Development (Host) Computer 2.1 Same as Target Computer: Yes -- No If no, Manufacturer: - Model Number: Difference Between Devel oprnent ar~d Target Computer:

6 * 2.2 Turnaround Time: (TURN) Low ( interact i ve) : High (4-12 hrs) Nominal (<4 hrs) Very High (>12 hrs) 2.3 For Interactive Development, Indicate the Average Number of Software Engineers/Programmers per Terminal: 2.4 Number of Development (Host) Sites 2.5 Development (Host) Site Locations: 2.6 Devel opment (Host) Computer Locati on(s) : * 2.7 Software Development Tool Usage: Very Low Low Nomi nal Hi gh Very High 2.8 Development (Host ) Computer Resource Avai 1 abi 1 i ty: *Designates minimum criteria to calibrate model.

7 SOFTWARE LABOR HOUR EXPENDITURE DATA (Form 2) 9/24/87 TE: Subm it/resubmit upon completion of each milestone review and upon project comp letion. Contract No: Total lines of new source Code Total lines of re-used/rnodified Code WBS Element or CPCI or Total Project Q n n n n n n n a MILESTONE n n 0 REVIEWS n DATE n n n n n * MANHOURS ** SOURCE OF DATA n SRR n n n n n Q n n n n n n SDR n n n n n a n n n n n SSR* n n n n n n CDR n n n n n a n n n n n w START CODE n n n n n n DEBUG n n 0 n n I n n n n n n START INFORM. n n (I n n n INT TEST n n n n n n n n n n n - - n n Q n n n n FQT* n a II n n n B n n FCA n n 1 n n a ll I PCA n n n n n n n n n n n QCOMPLETION* n n n n n n n n w *Designates data required to calibrate model. **Manhours should include System, Software, and Test Engineering hours.

8

9 REVIC - GENERAL THEORY OF THE MODEL The REVIC model predicts the life cycle costs for software development from requirements analysis through completion of the software aceptance testing. It implements the intermediate form of the CONSTRUCTIVE COST MODEL (COCOMO) described by Dr. Barry W. Boehm in his book Software Engineering Economics. The intermediate COCOMO model provides a set of basic equations which calculate the effort (manpower in manmonths) and schedule (linear time in calendar months) to perform a typical software development project based on an estimate of the line of code to be developed. The form of the basic equations are shown in Figure 1. (1) MM = A ( KDSI ) A b n ( Fi ) (2) TDEV = C ( MM ) A d FIGURE 1 Equation (1) predicts the manpower (MM) in manmonths based on the estimated line of code to be developed (KDSI is an acronym for Thousand Delivered Source Instructions) and the product of a group of environmental factors Fi. The coefficients (A and b) and the factors (Fi) are determined by statistical means from a database of completed projects. The factors attempt to account for the variations in the total development environment (such as programmers capabilities or availability of software tools) which tend to increase or decrease the total effort and schedule. The results from equation (1) are input to equation (2) to determine the resulting schedule (TDEV is an acronym for Development Time) in months needed to perform the complete development. The COCOMO model then provides a set of tables which provide a distribution of the effort and schedule to the phases of development (system engineering, preliminary design, etc.) and activities (system analysis, coding, test planning, managing, etc.) as a percentage of the total. The COCOMO model has three different modes corresponding to the degree of overall difficulty and project attributes. Each mode (Organic, Embedded, and Semidetached) has different coefficients for the two equations and slightly different sets of efforvschedule distribution tables. The distribution tables are further subdivided based on the total line of code to be developed. The majority of the REVIC program is concerned with prompting the user for the information needed by the program to determine the proper coefficients, factors, and distribution tables. Since the program provides a complete interface between the user and the model, no knowledge of the model is required by the user and much of the typical intimidation of analytic models is removed. REVIC further incorporates many current ideas which were not described by Boehm in his book. The model has been enhanced by using statistical methods for determining the lines of code to be developed. Low, high, and most probable estimates for each CSC (computer software component) are used to calculate the effective lines of code and the standard deviation. The effective lines of code and standard deviation are then used in the equations rather than the linear sum of the estimates. In this manner, the estimating uncertainties can be quantified and to some extent, reduced. A sensitivity analysis showing the plus and minus three sigmas for effort and schedule is easily calculated using the standard deviation. The program is written in 'non-modal' form. Once the initial input process is complete, the user is presented with custom menus which allow fully exercising the analytical features and displays of the program.

10

11 REVlC - Getting Started The REVlC program is provided on a standard IBM DOS compatible, floppy disk. Besides the necessary system files and the advanced version of Microsoft Basic, BASICA, the disk contains six additional files. The files are: The first two files named REVIC.BAS and REVIC1.BAS are the actual program which implements the model. During program execution, the two files chain back and forth to each other. To start the program, either file can be "RUN" from the basic interpreter. The third file, REVICDAT.DAT, is a data file which is read by REVlC during initialization. It contains the coefficients for all six COCOMO equations as well as the phase and activity distribution tables. If this file is missing or accidently deleted, it can be recreated by running the fourth file. REVICMKE.BAS will create the REVICDAT file and put the appropriate values into the data file. The REVlC program allows the user to save the results of the analysis session in a special data file which can be reloaded at a future session. SAMPLE.DAT is an example of such a data file. It can be loaded by following the program's prompts, and is provided to allow the user to play with the model before entering real data. The last file provided on the disk is COCOMO.COM. This is a command file which can be used to load BASICA and start the REVIC.BAS program from the DOS prompt. The programs can be run from a hard disk or from the floppys. To start the program, first make sure that the disk drive containing the REVlC program and files is declared to be the default drive, then run the COCOMO command file. For example, if the files were copied to a hard disk whose drive identifier is 'C', execute the following commands from the DOS prompt '9: > C: <RETURN> C> COCOMO <RETURN> At this point the command file will load the BASICA interpreter, load the REVIC.BAS file, and then run REVIC.BAS. As an alternative to using the command file, the program could be started as follows: C> BASICA <RETURN> After BASICA has loaded it will display a message giving its rev number and amount of free memory remaining. Then it will display an 'OK. After the 'OK' type the following: OK RUN "REVIC.BASw <RETURN> At this point, the REVlC program will be loaded and started. From this point on the program will provide prompts and instructions to the user. At various points in the program, whenever you have chosen to load or save a data file, you will be asked to input the file name. If a disk drive is not specified as part of the files name, the program will look for the file on the default disk. Inputting the '.DAT' extension is

12 optional, the program will append it if you don't specify it. If you specify a filename which is nonexistent, the program will crash. If that happens, restart it by typing RUN <RETURN> While the program is running, you will be asked to input choices from various options. Generally choosing a menu choice requires entering a single number followed by hitting the RETURN key. Occasionally you will need to input letters. When responding to a menu choice, only the first letter of the appropriate choice is required (The program will accept upper or lowercase). Whenever a menu is presented, the default choice is indicated by square brackets. For example, when the program asks if you ' want to do something it will typically provide the following prompt: In this case hitting the RETURN key without entering a Y or N will result in the Yes choice by defautt. Throughout the program, these default prompts allow you to rapidly enter the most used choices.

13 REVlC - The Three COCOMO Modes of Software Development The model will ask you to choose the mode of development in order to pick the right set of coefficients and distribution tables. While the program will give a brief description of each mode in the actual prompt, the following is a more complete description of the differences between the modes and is taken from Dr. Boehm's book. ORGANIC MODE In the organic mode, relatively small software teams develp software in a highly familiar, in-house environment. Most people connected with the project have extensive experience in working with related systems within the organization, and have a thorough understanding of how the system under development will contribute to the organization's objectives. This means that most of the project people can usefully contribute to the project in its early stages, without generating a great deal of project communications overhead. Also, an organic mode project is relatively relaxed about the way the software meets it requirements and interface specifications. If a situation arises where an exact correspondence of the software product to the original requirements or interface specifications would cause an extensive rework, the project team can generally negotiate a modification of the specifications that can be developed more easily, and that will not be too difficult for the user to accomodate. Other factors common to organic mode software projects are: ' A generally stable development environment, with very little concurrent development of associated new hardware and operational procedures. ' Minimal need for innovative data processing architectures or algorithms. ' A relatively low premium on early completion of the project. Relatively small size. Very few organic mode projects have developed products with more than 50 KDSl of new software. These factors also tend to correlate with higher project productivity and smaller project diseconomies of scale. SEMIDETACHED MODE The semidetached mode of software development represents an intermediate stage between the organic and embedded modes. Intermediate may mean either of two things: 1. An intermediate level of the project characteristic. 2. A mixture of the organic and embedded mode characteristics.

14 Thus, with respect to the feature 'experience in working with related software systems,' any of the following could be characteristic of a semidetached mode project. ' The team members all have an intermediate level of experience with related systems. ' The team has a wide mixture of experienced and inexperienced people. ' The team members have experience related to some aspects of the system under development, but not others. The size range of a semidetached mode project generally extends up to 300 KDSI. EMBEDDED MODE The major distinguishing factor of an embedded mode software project is a need to operate within tight constraints. The product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures, such as an electronic funds transfer system or an air traffic control system. In general, the costs of changing the other parts of this complex are so high that their characteristics are considered essentially unchangeable, and the software is expected both to conform to their specifications, and to take up the slack on any unforeseen difficulties encountered or changes required within the other parts of the complex. As a result, the embedded mode project does not generally have the option of negotiating easier software changes and fixes by modifying the requirements and interface specifications. The project must therefore expend more effort in accommodating changes and fixes, more effort in assuring that the software actually meets the specifications, and more effort in assuring that changes are made correctly. These factors contribute both to lower productivity and to greater diseconomies of scale on larger projects. The embedded mode project is generally charting its way through unknown territory to a greater extent than the organic mode project. This leads the project to use a much smaller team of analysts in the early stages, as a large number of people would get swamped in communications overhead. Once the embedded project has completed its product design, its best strategy is to bring on a very large team of programmers to perform detailed design, coding, and unit testing in parallel. Otherwise, the project would take much longer to complete, which would be bad for two main reasons: ' The product would have to absorb more changes. ' The product would be further out-of-date when delivered. (Generally, the premium for early completion of embedded mode projects is much higher, often because of a need to get an entire hardware-software complex in operation as soon as possible.) This strategy leads to the higher peaks in the personnel curves of embedded mode projects, and to the greater amount of effort consumed compared to an organic mode project working to the same total development schedule.

15 REVlC - Description of Phase Dlstrlbution In order to interpret the distribution of effort by phase shown in the REVlC displays, the user should be familiar with the development life cycle phases. The following section describes the phases and what should have been accomplished by the end of that particular phase. 1. Plans and Requirements Phase (After completion of a Design Concept Review or equivalent) At the completion of this phase there should be an approved, validated system architecture, including basic hardware-software allocations; an approved, validated concept of operation, including basic human-machine allocations; and a top level life cycle plan, including milestones, resources, responsibilities, schedules, and major activities. This phase is also known as the Systems Analysis Phase. 2. Preliminary Design Phase (after completion of a Software Requirements Review or equivalent) At the end of this phase there should be a detailed development plan with milestone criteria, resource budgets, organization, responsibilities,schedules, activities, techniques, and products specified; a detailed usage plan for training, conversion, installation, operations, and support identified for all elements of the development plan; a detailed product control plan for configuration management, quality assurance, and VerificationNalidation; an approved validated software requirements specification with functional, performance, and interface specifications validated for completeness, consistency, testibility, and feasibility. 3. Critical Design Phase (After completion of a Preliminary Design Review or equivalent) At the end of this phase there should be a verified software produd design specification with program component hierarchy, control and data interfaces through unit level; physical and logical data structure through field level; data processing resource budgets (timing, storage, accuracy); verified for compeleteness, consistancy, feasibility, and traceability to requirements. All high-risk development issues should have been identified and a resolution obtained; and a preliminary integration and test plan, acceptance test plan, and user's manuals prepared. 4. Code and Unit Test Phase (After completion of a Critical Design Review or equivalent) At the end of this phase each routine should be coded and verified with a detailed design specification showing name, purpose, assumptions, sizing, calling sequence, error exits, inputs, outputs, algorithms, and processing flow; a data base description through the parameterfcharacterfbit level; everything verified for completeness, consistancy, and traceability to requirements and system design speafications and budgets; an approved acceptance test plan; and a complete draft of the integration and test plan and user's manual. 5. Integration and Test Phase (After completion of all unit test criteria or a Test Readiness Review) At the end of this phase there should be verification of all unit input and output options, including error messages; exercise of all executable statements and all branch options; verification of programming standards compliance; and completion of unit level as-build documentation. 6. Implementation Phase (After completion of a Software Acceptance Review or equivalent Physical/Functional Configuration Audits) This phase is characterized by acceptance of all deliverable software products; reports, manuals, as-build specifications, data bases, listings, etc. Since software is usually part of a larger system which drives the implementation phase, the COCOMO model does not include this phase in its predicted costs. This phase must be estimated separately.

16 7. Operation and Maintenance Phase (After completion of the System Acceptance Review or equivalent) This phase marks the actual use of the delivered product by the customer and continuous upgrades to the software. While the COCOMO model provides methods to estimate this phase,, it has been left out of the REVlC model.

17 REVIC - Description of Activity Distribution During all of the life cycle phases, the manpower expended can be lumped into discrete activities. The REVIC program provides a distribution of all effort by activity as follows: Requirements Analysts - determination, specification, review, and update of software functional, performance, interface, and verification requirements. Product Designers - determination, specification, review, and update of hardware-software architecture, program design, and data base design. Programmers - detailed design, code, unit test, and integration of individual computer program components. lncludes programming personnel planning, tool acquisition, data base development, component level documentation, and intermediate level programming management. Test Planners - specification, review, and update of product test and acceptance test plans. Acquisition of associated test drivers, test tools, and test data. Verification and Validation - performance of independent requirements validation, design V & V, product test, and acceptance test. Acquision of requirements and design V & V tools. Project Office - project level management functions. lncludes project level planning and control, contract and subcontract management, and customer interface. CM & QA - configuration management includes product identification, change control, status accounting, operation of program support library, development and monitoring of end item acceptance plan. Quality assurance includes development and monitoring of project standards, and technical audits of software products and processes. Manuals - development and update of user's manuals, operators' manuals, and maintenance manuals.

18 REVlC - Costs Not Included The costs shown for the REVlC model do not include all life cycle costs. The following checklist should be used to ensure that all possible sources of labor and other costs are considered in determining the overall cost estimate for the program. Items from this list should be included to the extent that they are not covered by the company's allowable Overhead and General 81 Administrative rates. 1. Clerical Costs. 2. Related Personnel Costs. Security personnel, overtime, benefits, hiring, relocation, education; personnel costs for product acquisition: contracts, legal, receiving inspection, etc." 3. Related Computer Costs. Installation, maintenance, insurance, specialequipment, terminals, control units, data entry devices, etc." 4. Office Equipment Costs. Typewriters, telephones, copiers, file cabinets, desks, chairs, word processing, etc." 5. Software Product Costs. Purchase, rental, licensing, maintenance of software components, utilities, tools, etc." 6. Supplies Costs. Tapes, disks, forms, cards, paper, print ribbons, office supplies, etc." 7. Telecommunication Costs. Line charges, special equipment, modems, multiplexers, cables, connectors, video conferencing, etc." 8. Facility Costs. Office rental, electricity, air conditioning, heating, water, taxes, depreciation, cleaning, repairs, insurance, security, fire protection, etc." 9. Other Costs. Travel, postage, printing, consulting fees, books, periodicals, conventions, messenger services, equipment relocation, etc."

19 REVlC - Notes for the Macintosh User The Macintosh version of the REVlC program is provided on a standard 3 l n" disk. Besides the system folder, only three files are provided. They are: REVlC REVIC.Help SAMPLE.Data The REVlC file contains the entire program and uses the '.Helpf file to print out instructions if the user desires. The SAMPLE.Data file contains an example of a saved data file from the program. Program execution is typical Macintosh and uses the standard Macintosh interface of radio buttons, edit fields, and custom menu bars. A user familiar with any Macintosh application should have no trouble running the model. Since not all Macintosh fonts are proportional, the program's displays will only be properly lined up if the system file contains a Monaco 12 font. The system on the delivered disk contains this font. Be careful not to delete it if you change systems. Version 2.1 of Microsoft Basic, which the program is written for, does not completely support the HFS filing system. Consequently, when saving or loading data files, the user may have to look around to find the file on the desktop.

20