The purpose of this article is to explain project estimation and planning utilizing a case study development of a new employee tracking application. After a brief overview of the case study, the article moves on to an explanation of project estimation and planning. Two types of estimation are discussed in the process; top-down and bottom-up. The article introduces and uses tools to accomplish top-down and bottom-up project estimation for the employee tracking application. The article closes with an overview of the estimation outcomes, introducing next steps for the project planning process.
Case Study Overview
The human resources department has requested a new application which will allow staff to maintain, inquire upon, and report information about employees and jobs. Requirements include the ability to report a list of employees by geographic location, the names and geographic locations of employees with a particular job, and a history of job assignments for a particular employee. The application will draw on an existing database for the above information. The programming language is C for the application and the interface. Most programmers are familiar with C and with the existing interface. The estimated cost of software developer is $13,750 per month, including salary, benefits, and overhead costs. Case study requirements, entity relationship diagram, and data description has been attached to this report as Attachment A.
Project Estimation and Planning
There are two approaches to estimation; top-down and bottom-up (Temnenco, 2007). The bottom-up approach to project estimation examines each individual activity that must take place for project completion, estimates the time required to complete each activity, and adds up all of the activity times for a total project time required. Time is translated into cost using the enterprise estimates of developer cost including salary and benefits (Temnenco, 2007). Instead of focusing on individual activities, the top-down approach focuses on overall system properties such as size, complexity, and other characteristic factors of the overall project. With overall project characteristics, the top-down approach uses averages based on enterprise or industry experience to estimate cost and complexity associated with the project. The top-down approach can be illustrated with the Constructive Cost Model (COCOMO).
COCOMO
COCOMO is “one of the original effort estimation models developed by software engineers” (Ahmed, 2011, pp. 45-48). There are three variations of COCOMO. Basic COCOMO uses only three estimates; (1) the estimated number of lines of code, and (2) an effort estimate multiplier, and (3) an exponential factor based on scale factors. Intermediate COCOMO, which is often referred to as COCOMO II, takes a systematic approach to attributes which affect effort and complexity whether they be related to the product itself, hardware, personnel, or project. Finally, a detailed approach to COCOMO can dissect the project into separate parts, apply COCOMO to each part, and arrive at an effort estimated for each component. Whether basic, intermediate, or detailed COCOMO is used, each model provides an estimate in person-months for the project. The COCOMO effort estimates can be used to estimate project duration and cost.
The COCOMO II model utilized here was developed by University of Michigan-Dearborn (2020), and involves three steps; (1) compute the count total used to define project complexity, (2) find the complexity adjustment factor based on project characteristics, (3) determine an estimate for lines of code (LOC) required and (4) select a complexity level for the project. Inputs for the first step, information domain values, are provided in Attachment B and justified herein. First, depending on the scenario, the employee tracking application will need various inputs from the human resources user in order to produce reports; employee name, office location, and job assignment. In turn, the application will produce one of three reports; (1) a list of employees at a particular location, (2) a report of names and office locations of employees with a certain job assignment, and (3) a history of job assignments for a selected employee. To produce these reports, the user will need to enter one of three inquires.
The number of files is estimated using a model-view-controller, or MVC, design pattern (Gamma, Helm, Johnson, & Vlissides, 1995, pp. 4-5). The model includes the data structures to be used in the application. As detailed in the project requirements, there are six classes of data objects to be utilized by programmers. Additionally, the model will need an object which collects data based on the user inquiry and returns output to the user. Combining the data with the operations object, there will be seven files needed for the model portion of the MVC structure. There are five views to be produced; a main menu where the user selects the type of report desired, a data input where the user enters the desired input for the selected report, and one view for each of the three types of reports to be produced. Each of these five views will require a file. Finally, one controller file will be needed to initiate a user session and to provide services for that session. In total it can be estimated that there will be 13 files for the model (7), view (5), and controller (1) portions of this application. There is only one interface required for the application which will provide an access point for an existing employee location database.
The application is relatively straightforward, collecting discrete input from users and producing reports with data from a database. As such, an ‘Average’ assignment is applied to each of these domain factors. Based on these domain inputs, the COCOMO II step 1 count total equaled 176, which has been included in Attachment B.
The second step of the COCOMO II model calls on the planner to rate 14 attributes of the project. Each of these attributes range in influence on the project from essential to of no influence at all. The inputs for each of all factors are displayed in Attachment B to this report, where it can be seen that four factors contribute to the complexity of the employee tracking project. First, the project requires data communications with the employee application database which will require programmers to develop and integrate an interface into the application. This is rated essential to the project since the required reports to be produced by the application cannot be generated without data from the database. Performance of the application in terms of speed and availability is also noted as important on par with other enterprise application, i.e. average. Input / Output complexity is given also noted as a moderate influence on the project due to the required inputs by the user; employee name, locations, and job assignments. Each of these three items requires the user to obtain detailed and sometimes secure information, and to enter this information correctly to produce the desired reports. Internal processing, requiring the collection, collation, and reproduction of information into structured reports, is also noted as an influence contributing to the application complexity.
The primary output of the COCOMO II complexity adjustment determination is the estimated function points, which is an estimate of the number of functions required to be build in the present application (Ahmed, 2011, p. 41). Using the inputs for complexity influences described above, the function points for the employee tracking application is calculated to be 135.52. Given that the programmers will be using the C programming language, the COCOMO II model estimates 43,366.40 lines of code per function point. Details related to inputs for determining function points and lines of code, along with the calculated output, is included in Attachment B.
The final step for COCOMO II is determining the complexity of the project. For this, there are three options; organic, semi-detached, or embedded (Schach, 2011, p. 278). The employee tracking application is relatively straightforward, collecting input from the user, retrieving information from a database, collating the information and producing it in a report. The data collected from the database is not altered, modified, or analyzed by the application. As such, the complexity assigned to the employee tracking application is organic – a designation for small relatively straightforward applications.
The final result of the COCOMO II model is to determine an estimate of effort required and time duration of the project. Based on the model inputs discussed above, the project is estimated to require 15.61 person-months. Based on the enterprise cost of software developers, this would indicate a total cost for development of $214,637.50. To confirm these factors, a bottom-up approach of project planning and estimation should be completed.
OpenProj
For bottom-up project planning and estimation, OpenProj (2019) will be applied to the employee tracking application. The inputs for bottom-up planning such as project scope and requirements can be taken from the employee tracking application requirements document (Attachment A). Typical inputs would also include the software engineering life cycle model to be used in development. As was discussed in more detail above, the present application is straightforward and relatively simple in concept. As a result, the Waterfall Life Cycle Model (Schach, 2011, pp. 53-55) will be utilized as part of bottom-up planning process in a manner consistent with Ahmed (2011, p. 54).
In addition to the typical inputs to bottom-up planning, certain assumptions will be necessary in order to produce an initial project plan, duration, schedule, and cost estimation. For the present purposes, the employee tracking application has been deemed straightforward. To that end, the project will be completed with one project manager, two senior software developers, and two software developers. The enterprise cost per development staff ($13,750 per month) is assigned to each of these staff members. Assuming 2,080 hours are worked in 12 months, the hourly cost for each of these staff members is estimated to be $79.30.
Output from the OpenProj analysis has been included as Attachment C. Nine tasks have been identified for the current project; planning, management, requirements, prototyping, configuration management, design, code development, testing, and delivery. For the planning and management phases, five days have been assigned to each and both have been assigned to the project manager alone. Two senior developers and the project managers will work to refine system requirements for ten days. The two senior developers then work to complete prototyping, configuration and design over 30 days. Once design is complete, two senior developers work with two staff developers to develop the code for the application in 45 days. Testing and any necessary modifications are carried out by the same four-person team over 15 days. After completion of testing, the project manager coordinates delivery with the human resources team.
Based on these assumptions, OpenProj calculates the duration and cost of the project to be 111 days and $225,903.36, respectively. OpenProj estimates that the project will take 2,848 person-hours. Assuming a working year of 2,080 hours, this equates to 16.43 person-months, slightly more than the 15.61 estimated using the top-down COCOMO II approach.
Summary
This article has illustrated top-down and bottom-up planning and estimation for the development of a straightforward enterprise application. Both top-down and bottom-up planning were introduced, with tools selected for each approach to be used in the present case study. The top-down approach, COCOMO II, arrived at a duration of 15.61 person-months and a cost of $214,637.50. A bottom-up approach using OpenProj arrived at a slightly higher duration of 16.43 person-months and an overall cost of $225,903.36. While the COCOMO II estimates provided insights based on overall project characteristics, the bottom-up OpenProj estimates were able to break requirements down into individual tasks.
References
Attachment A: Statement of Requirements
A group in our human resources (HR) department has requested a new application. The current HR information systems provide much of the information it needs, but each geographic region has a different and incompatible application. This new application is to provide one unified view across all of the company’s many locations.
The new application must allow HR staff to maintain, inquire about, and report information about employees and jobs. The attached entity-relationship diagram illustrates the database tables and their relationships. The attached data description provides details of what fields must be tracked.
Some of the new, important features expected of the new application are the ability to report a list of employees at a particular location, to report the names and office locations of all employees with a particular job, and to report the history of job assignments (including the job description) for a particular employee.
The new application will leverage an existing office location database. This data is maintained by an existing application managed by the facilities department, so the Employee-Tracking Application must treat it as read-only.
We generally use the C language to develop this type of product because most of the programmers are familiar with its database interface. The business analysis team does not foresee any need to reuse the software for purposes other than this particular application.
Our average cost for each software developer is $13,750 per month, which includes salary, benefits, and overhead costs.
We need estimates of the effort and time required to complete this project so that we can prepare an accurate proposal for the customer.
Entity-Relationship Diagram for Employee-Tracking Application
Data Description for Employee-Tracking Application
EMPLOYEE entity type:
Employee_Name
Social_Security_Number
Number_of_Dependents
Type_Code (Salaried or Hourly)
Location_Name
SALARIED_EMPLOYEE entity subtype:
Supervisory_Level
HOURLY_EMPLOYEE entity subtype:
Standard_Hourly_Rate
Collective_Bargaining_Unit_Number
JOB_ASSIGNMENT entity type:
Effective_Date
Salary
Performance_Rating
Job_Number
Employee_Social_Security_Number
JOB entity type:
Job_Name
Job_Number
Pay_Grade
Job_Description
LOCATION entity type:
Location_Name
Address
Inter_Office_Code
Attachment B: Top-Down Planning with COCOMO II
(University of Michigan-Dearborn, 2020)
Step 1: Compute Count Total
Step 2: Determine Complexity Adjustment Values
Step 3: Determine Lines of Code (LOC)
Step 4: Select Complexity
Attachment C: Bottom-Up Planning with OpenProj
Project Overview
Resource Information
Tasks, Schedule, and Resource Assignments
