This chapter is from the book
This chapter is from the book
This chapter is from the book
Inputs to Sizing
The size of a software application can be measured in several measuring units. Popular sizing units include Source Lines of Code (SLOC), function points (FP), object points, and feature points. Each measuring unit is unique in the sense that the measuring unit defined by the SLOC method does not have a clear and measurable equivalent ratio with, for example, function points or object points. Each measuring unit also measures the application size from a different perspective. For example,
- SLOC measures the total lines of code that can be counted in the software application. The SLOC are specific to the technology platform on which the application was developed. For a given application, the SLOC count will vary for different technology platforms. The number of SLOC, if written in COBOL, would be far higher when compared to SLOC written in C, although the delivered functionality would be the same in both cases.
- Function points (FP) count measures the business functionality delivered by the application being counted. The size measured through FP method is independent of the technology on which the application is developed. Therein lies the comforting fact that when two different experienced estimators are given an application, the size they measure in function points will be within a comfortable variance range.
- Object points measures the size of an application by counting the number of screens, reports, and interfaces (known as objects) required to complete the coding. The objects themselves can be classified into different level of complexity such as simple, average, and complex.
- Feature points 6 is a variant of function points. Developed by Capers Jones, this method adds another measurable attribute, the complexity of algorithms. Here the size is measured in feature points count very similar to function point count.
Source of Inputs
For any type of estimation, it is important to have detailed information about the application/system. This is also the case with function point estimation. For estimating the size of an application using function point analysis, the following information about the application is required:
- Scope (specifications) of the application
- Data being maintained by the application
- Data being referenced (but not being maintained) by the application
- Logical grouping of the data being used by the application
- Input to the application, in terms of data within the defined application scope
- Output from the application like reports, queries, etc., within the scope of application requirements
- The general behavioral characteristics of the system
These inputs can be categorized into two distinct types of requirements, typically called functional and non-functional requirements. The requirements information can be obtained from the following artifacts:
- Functional requirements:
- Business process
- Business work flow
- Conceptual data model
- Functional specifications or use case specifications
- Input on external applications, if any, including details of interface with other applications
- Non-functional requirements:
- Documents stating the performance requirements and other infrastructure details, like multiple sites, reliability, scalability, availability, usability, etc.
Accuracy of Requirements
The quality and accuracy of the requirements specification is critical to correct sizing. The specifications need to be complete, correct, and up-to-date for the size calculation. The result of wrong size estimation will lead to incorrect effort projections, schedule calculations, and other project planning and project costs because these activities are based heavily on the size information.
Details of all the functionality required by the user at the time of project initiation may not be available, which can lead to scope change later (also known as scope creep). The specifications should include the business data and reference data. Following are some of the points that must be specified to ensure the accuracy of the requirements specifications documents:
- Objectives of the proposed system
- Business requirements
- Scope and boundary
- Business events/functions
- Screens and reports
- External interfaces
- Operating environment; hardware, operating system, technology platform, and network protocols
- Specific communication requirements
- Performance requirements
- Special user requirements
- Data migration
- Architectural requirements
- Constraints/issues
Role of Size in the Software Development Lifecycle
The purpose of evaluating and estimating the size of a software application is to move the estimation process forward to arrive at effort, schedule, and costs of executing the project. As such, it is essential for the estimator to understand the relation between the various categories of size units (SLOC, FP, object points, and feature points) to its applicability in the software development lifecycle stages. The typical lifecycle stages of software project execution considered here are (1) the requirement phase, (2) the design phase, (3) the build (construction) phase, and (4) the test phase. Consider the following points:
- The Source Lines-Of-Code (SLOC) is the most ambiguous of all the sizing units and is highly unreliable as far as the estimation process is considered. Obviously, estimations are done when the application is yet to be developed. Predicting the SLOC that the application will generate upon project completion would be quite an uphill task.
- The other concern is to relate the SLOC count to the lifecycle stages of software project execution. Although the total SLOC generated at the end of project completion is measurable, coming up with an estimation formula that would give you the break-up effort for various lifecycle stages of project execution individually would be complex. To better illustrate, consider an application in COBOL that generates 50,000 SLOC. How do you relate this SLOC count to the effort it would take to complete the lifecycles stages (requirements, design, build, and test)? Experts in COBOL may be able to provide an approximate effort that it takes to code and test a given count of SLOC. The estimator will then have to convert the code and test (build) effort to the total project execution effort through extrapolation methods. Every bit of error in calculation of code and test effort will be multiplied during the extrapolation.
-
Function points is perhaps the nearest method to providing a measuring unit that spans across all the standard lifecycle phases of software project execution. Function point count of an application under development depicts the total functionality that the user expects to be delivered. If you have the data on the delivery rate of the project team, the total project effort can thus be calculated by dividing the FP count by the delivery rate (productivity). Further, the total project execution effort can be now divided into lifecycle phase efforts based either on historic data from your own organization or industry standard data.
For example, consider a project that has a count of 1,000 FP. Assuming a delivery rate (productivity) of the project team on a selected platform to be 15 FP per person month, you get a total effort of approximately 67 person months (1,000 FP divided by 15 FP per person month). If you assume a lifecycle phase breakup of effort as
- Requirements: 15 percent
- Design: 20 percent
- Build: 40 percent
- Test: 25 percent
The total project effort can be divided according to the preceding percentages. The percentage breakup of effort can be fine-tuned by taking feedback from completed projects and applying corrections as applicable through continuous improvement cycles.
- Feature points are quite similar to function points.
- Object points looks at the number of objects (screens, reports, etc.) likely to be generated in the software. The effort estimated for objects is similar to that of SLOC and it is focused on the code and test phase of the project execution lifecycle. The full effort is calculated by extrapolation as is done in the case of SLOC estimation.