Develop a Worksheet Tool for Size Estimating and use it to develop a Size Estimate Report
Background
IPC frequently develops software and has built up a large data base of information on what it takes to build certain specific kinds of software. There is also a small data base of reusable software components that are frequently used within new products. You have been assigned to develop a size estimating tool using a spreadsheet.
The size estimating tool will accept data about a new project and historical data about related, prior projects and use this data to estimate the size of the new software, in source lines of code (SLOC) and in estimated bytes of memory (RAM). The spreadsheet(s) should produce tables that satisfy your company's policies for size estimation, per a separate handout. Note that although this assignment does not entail use of function points, the tool should be designed to work equally well with lines of code, function points, or any other unit of software size.
Typical software projects
The typical software project at IPC produces from 1 to 5 separate software items (SIs), each of which performs a specific function, often on a separate processor. These processors and their corresponding software items are typically integrated to form the final system product. The reason software is divided into separate items is because each software item typically performs a separate function, on a separate processor, and may also be programmed in a different language. By keeping them separate, it is easier to develop them in parallel and, when repair and maintenance are required, you may be able to fix any one of them without changing the others. You can also develop and deliver different software items on different schedules.
Each software item is typically subdivided into components that perform specific sub-functions. Some of these components are available in a library of reusable components, and in other cases such a component is derived from an older component by some sort of modification (for example, rewriting in a new language, adding functionality or changing it to be compatible with more recent standards). And sometimes a component may be shared between software items (this is known as "concurrent reuse").
Sample Project
To test out your estimating tool, you will use data from the "Mr. Television" project. Several documents are supplied to describe this project: a Statement of Work from the marketing organization and a System Design Summary from the system engineering organization are formal documents (but not necessarily complete or accurate). Other documents are provided as well, some of which may conflict with each other or with the formal documents. Part of your task is to evaluate all of this information and make judgment calls and assumptions (explaining your assumptions).
Company Standards
Also provided is a set of sample company standards for size and cost estimating and creating WBSs. These are inspired by actual company standards but are greatly reduced in scope. Your work is expected to conform to these standards to a reasonable degree. But if you have a good reason for differing, go ahead (and explain why).
Risks and Assumptions
The "Mr. Television" project has many risks. As you develop your estimate, note software related risks that might affect the size estimate and take them into consideration when doing your work. For example, if the information available on estimated size is unreliable, you might want to assume a greater range of possible sizes. Also note these risks for later use in the risk management plan of your SDP. You should also make a list of important questions you would like to get answers to if this were a real project. Those questions will be included in the risk management plan as well. If there is something you don't know but feel that you need to know, you may need to make assumptions about the unknown. For example, suppose you don't know if there is enough space to accommodate all of your software staff. You might make the assumption that there is enough space. Such unknowns and assumptions are documented at the beginning of the SDP.
1.0 Work to be Performed
1.1 Using a spreadsheet tool such as Microsoft ExcelTM, you are to design and implement a worksheet that will estimate the size of a single software item (type-I worksheet) and a second worksheet that will combine the information from several worksheets of the first kind (one per software item) into a size estimate for the entire system (type-S worksheet). A type-S worksheet will allow inputs from up to five separate type-I worksheets.
Hint 1: to develop the type-S worksheet, start with a type-I worksheet and change the "components" to be the totals from the type-I worksheets).
Hint 2: create a workbook for the whole assignment that contains each of the individual worksheets mentioned above as a separate worksheet.
You will demonstrate this estimating tool using the "Mr. Television" data and submit a "size estimating report" to show the results. [For the "Mr. Television" application you will need four type-I worksheets.]
Note 1: the size estimating worksheets should produce output consistent with the size estimating policies and procedures provided separately. What you turn in will be the size estimating report, not the worksheets themselves.
Note 2: Entry of data into the type-I worksheets is manual. You may also manually copy data over from the type-I totals to the type-S worksheet, but you may also do this in an automated way if you know how to do this with spreadsheets. If you combine all of this into one workbook with separate "pages" or "worksheets" for each individual worksheet, the process will be easier. Note that sophistication of your worksheet/workbook will not be a factor in your grade. However, feel free to include a brief description of how it works, especially if you found something to be particularly helpful. For example, in previous years students have recommended that all parameters and variables be placed in a separate worksheet.
2.0 Software Characteristics
2.1 As you design worksheets for this assignment, you should assume that all software is to be written in the C, Java, or Ada programming language or some combination of these. Each individual component is written in exactly one language, but a Software Item may contain more than one language. For each of these languages there are two parameters derived from the company's historical data base: memory requirements (the average number of bytes of memory taken up per line of source code); and productivity (the number of lines of code developed per day by the average software development team). The productivity number will be used in a later, cost estimation assignment.
Memory Rqmts. Productivity
Language (Bytes per Line) (LOC/Day)
Ada 7.5 12
C 5.5 8
Java 11.5 10
Warning: the values of these parameters may change over time. Your spreadsheet should set them up as easily modified variables rather than embedding their values in formulas.
Special Note: the ratio of memory bytes to lines of code is a highly inconsistent one and applies only to the code, not the data. For example, a small program with a large data file might generate a very large number of memory units per line of code if you count the space occupied by the data file. So do not rely on the above ratios when deciding the memory size of software components if you only know the size in lines of code. Look for other information that may be more reliable, such as estimates made by experts.
Each software component is classified as new, modified, or reused. For each of these there is a separate "equivalent effort" ratio that translates actual lines of code into a possibly different number that reflects the equivalent effort in new lines of code. This ratio is as follows:
New code: 1.0 (100%)
Modified code: 0.6 (60%) nominal, but may vary (#1)
Reused code: 0.3 (30%) nominal, but may vary (#2)
Concurrent reuse: 0.02 (2%) or less (#3)
#1 A component that is only slightly modified is considered modified, but the ratio is likely to be much lower in such a case. You need to examine the specific situation and decide. A component that is translated into a new language is considered modified in most cases, unless the translation is so difficult that you decide to treat it as new.
#2 Some reuse is easier than others. For example, if you have very good specifications, test cases, etc. the ratio would be lower than shown, whereas if you lack such information the ratio might be higher.
#3 Concurrent reuse is the classification you use for the second and subsequent copies when the same component is to be used more than once in your product. The ratio used depends on how much work you think it will take to support these other copies - for example, to update them if a change is made to the first copy or to integrate each copy with the other software. Typically, the ratio for concurrent reuse is less than 2%. If the first copy of the software is new, the concurrent reuse ratio might be in the 2% range. If the first copy is reused or lightly modified, the concurrent reuse ratio for the second and subsequent copies is typically very low, from 0.5% to 1.5%.
Thus, for example, suppose a product has four components, one of each type:
Component Size (LOC) Type Equivalent Size
Comp1 10000 New 10000
Comp2 10000 Modified 6000
Comp3 10000 Reused 3000
Comp4 10000 Reused (concurrent) 200 (using 2%)
Total 40000 Mixture 19200
Note that although the effort for this example is lower than for "all new" code, the memory requirements of the code are still as large as if it had all been newly developed. Note also that a single component may contain some new code, some modified code, and some reused code.
3.0 Typical description of a software product:
A typical software product is described in terms of its components. For each component, the following information must be provided:
Programming Size Comments Bytes of
Component Language <--(Source Lines of Code)--> on Basis Target
Name (Ada, C, Or Min Expected Max for Estimate Memory
Java)
The size information provided for each component may come from one of the following:
* size of an existing library component to be reused (in this case, Min=Max=Likely)
* size of an existing library component to be modified (in this case, Min, Likely and Max represent opinions on how much the new one will differ from the old one)
* size of a similar component from a prior project (in this case, Min, Likely and Max represent opinions on how much the new one will differ from the old one)
* expert opinions (in this case, Min, Likely and Max represent varying opinions on the size of the new software.)
For this assignment, the size unit is source lines of code, and it is your job to provide the estimates based on the "Mr. Television" documentation separately distributed.
The spreadsheet must be designed so that it can accept any reasonable combination of size data and compute estimated values for total size in equivalent source lines of code and bytes of memory. (You will use the type-S worksheet in a later assignment.)
4.0 Deliverables
REMEMBER TO PUT THE COVER SHEET ON THE FRONT (see last page).
The deliverable for this assignment consists of a Size Estimate Report, as described in the Policies and Procedures (P&P) handed out separately. This report contains the following:
4.1 An overall software size estimate, generated by the size estimate worksheet (type-S) for the "Mr. Television" project, showing the following outputs:
4.1.0 Assumptions and other notes, such as rationale for reuse factors
4.1.1 Actual Size Table, per P&P
4.1.2 Equivalent Size Table, per P&P
4.1.3 Bar Chart showing new, reused and modified (per P&P).
4.2 For each software product in the "Mr. Television" project, a size estimate, generated by the size estimation worksheet (type-I) showing the following outputs:
4.2.0 Assumptions and other notes, such as rationale for reuse factors
4.2.1 Actual Size Table, per P&P
4.2.2 Equivalent Size Table, per P&P
4.2.3 Bar Chart showing new, reused and modified (per P&P).
Note: The size estimate tables (actual and equivalent) (items 4.1.1 and 4.1.2, above) for the type-S worksheet will also be included as Appendix B of your SDP (Assignment 5).
[cover sheet - fill in all bold, underlined sections with your specific information]
ASSIGNMENT 3
DESIGN AND BUILD
A
SIZE ESTIMATING SPREADSHEET
SE
PLANNING AND MANAGING A SOFTWARE PROJECT
Spring, 2010
NAME __Your Name Goes Here______ LOCATION ___Location Goes Here__
THIS COVER SHEET SHOULD APPEAR AS THE FIRST PAGE.
Grading template Student do not write inside this box
___________/30 Type-S Spreadsheet
__________/ 5 Assumptions
__________/10 Actual Size Table
__________/10 Equivalent Size Table
__________/ 5 Reuse Graph
___________/60 Type-I Spreadsheets
__________/ 8 Assumptions (2 each)
__________/20 Actual Size Table (5 each)
__________/20 Equivalent Size Table (5 each)
__________/12 Reuse Graphs (3 each)
___________/10 Overall Report Format (10)
___________/100 Total Assignment Grade