Software Estimation Plan
From TeamF::CGT
Revision: 2709
Contents |
Abstract
Software Estimation Plan is to avoid the dangers of unrealistic estimations before and during the development of Governance Toolkit Project. This Software Estimation Plan is produced to ensure the estimation of the project size. The document contains system description, estimation methodology and estimation calculation that will help the team through project planning.
Introduction
This document starts off by giving the context of the estimation plan by explaining the software system which the team will be estimating. From there, this document will describe the methodology used for estimating the size of the software, which the estimation team decided, using function points. The document will also describe how the methodology was carried out and used, hence provide reasons for choosing the estimation methodology.
Overview of System
Project Information
The Corporate Governance Toolkit (CGT) is a toolkit that can be used to create customised corporate governance applications. These customised applications may include:
- Risk Management Systems;
- Compliance Systems;
- Performance Management Systems; and
- other Corporate Governance Systems.
The Client
The Client will use the Corporate Governance Toolkit in multiple ways. The Client may:
- Distribute the Corporate Governance Toolkit as is, with the intention that the end-user will use the Corporate Governance Toolkit in order to create their own corporate governance software; or
- Consult with an end-user, create customised corporate governance software for the end-user, then distribute it to the end-user.
Current System
The existing system, Risk System is a tool that assists an organisation identify, analyse, measure and report the risks it faces. The Risk system essentially provides an organisation with a central database that holds information about risks from all the different division and produce a report that calculates the risk profiles and the impact on each division and on the whole organisation.
Risk System was developed by our client, Risk Wizard to manage the risks as recommended by Australian Risk Management Standards. It has been sold to their clients as packaged software.
Risk System software breaks the risk management into Identification, Analysis, Evaluation, Treatment, Review and Reporting phases. It allows the users to enter information about a risk after a user has completed the recommended risk management procedures in these phases. Risk System also produces necessary reports to support the analysis of risks.
Proposed System
The aim of the proposed system, the Corporate Governance Toolkit (CGT) is to provide organizations with a single system to manage all their corporate governance needs. CGT must not only overcome the lack of customization of the existing system, but also provide multiple integrated tools as part of a single system to record, analyze and report on different corporate governance issues.
CGT aims to provide an organisation with a single centralised system that consists of all the different tools needed to implement an organisation’s corporate governance policies. Given that each organization’s corporate policy is quite different, any tool built must be tailored to an organization’s needs.
CGT addresses these two identified needs for the corporate governance software by providing web-based software that gives the users the capacity to build their own corporate governance tool kit.
In order to achieve this goal, CGT must be able to dynamically build any tools needed to address an area of corporate governance and integrate these different tools into a single functioning system.
CGT endeavors to able to create applications to support Risk Management, Control and Compliance Management, Privacy Management, Dashboards, Activity Alert, Performance Management, Incident management and Issue Registers. However, given the limited the resources and time constraints of the 440 team, the CGT software will only be able to dynamically create applications or end-system that support:
- Risk Management
- Compliance Management
- Performance Management
CGT will be expanded in the future by Risk Wizard to support the creation of other types of tools.
Estimating
Discussion of Different Methodologies
There are many different methodologies in estimating a software system. We have researched and considered the following methodologies when making a decision:
- Function Point Analysis (FPA);
- Constructive Cost Model (CoCoMo);
- Expert Judgement.
Following this, we will discuss the above methodologies which we have considered and make a decision in the following section.
Function Point Analysis (FPA)
Function Point Analysis (FPA) starts of by identifying the functionality of the software system. It counts the different entities or functions from the SRS and weights it against the complexity of the each of those functions to come out with a function point count. From there, the function point count will be taken and used to estimate the software system.
Different function points can be described by:
- External Inputs (EI);
- External Outputs (EO);
- External Inquries (EQ);
- Internal Logical Files (ILF);
- External Interfaces Files (EIF).
Constructive Cost Model (CoCoMo)
Constructive Cost Model (CoCoMo) was designed to give an estimate of the number of programmer-months it will take to develop a software product. It is an algorithmic estimation model where you calculate the effort based on the following equation:
Effort = A X Size^B X M
where:
- A: A constant factor usually 2.94
- B: Increased effort required as the size of the project increases
- Size: Estimate in terms of function or object points
- M: Process characteristics
Expert Judgement
Expert Judgement basically just getting experienced people in software estimation to estimate the software system.
References
The following references were used:
- Sommerville, 2004, Software Engineering, 7th Edition, pg.623-637
- http://en.wikipedia.org/wiki/Cocomo
- http://en.wikipedia.org/wiki/Estimation_in_software_engineering
- 443 Lecture Notes at http://www.cs.mu.oz.au/443/Estimation2.ppt
Choice
After much discussion and thought, the Team has chosen Function Point Analysis. The reasons are the following:
- Stable Requirements
- The team does not have a stable architecture design of the system it was impossible to do other Estimation Methodologies;
- The team does have stable requirements.
- Experience with FPA
- The team has experience with FPA from lectures and tutorials.
The team did not choose Expert Judgement or Cocomo because of the following reasons:
- We did not have the resources to pay for Expert Judgement;
- We did not have experience in terms of Cocomo;
- We did not have a stable design to use Cocomo.
Method
After we have chosen Function Point Analysis (FPA). From the Software Requirements Specification (SRS), the team broke down the core system into the following functions:
- Create Database Tables
- Set Icons For Tables and Attributes
- Set Special Attribute Properties
- Support Data Types
- Edit Table Properties
- Delete Tables
- Input Records into Tables
- Modify Records in Tables
- Duplicate Records
- Define Values to Other Values
- Create Tree Structure
- View Database Trees
- Set ActiveReports Report as View
- Set Dundas Chart as View
- Set Default View
- Plain Text Browser-based CSS Editor
- Load CSS Templates
- View Records by Tree
- Filter Records
- Show Views
- Context-specific Buttons
- Select view for Record Type
- Select Default View
After breaking down the system, the team discussed what kind of data function types for the functions of the system. The team also discussed the complexity of each of the functional points.
From there, the team came up with the following table which represents the different datatypes and the complexity of the functions:
| SRS Section | Functional Requirement | Datatype | Complexity |
|---|---|---|---|
| 7.1 | Create Database Tables | EI | LOW |
| 7.2 | Set Icons For Tables and Attributes | EI | LOW |
| 7.3 | Set Special Attribute Properties | EI | AVERAGE |
| 7.4 | Support Data Types | ILF | LOW |
| 7.5 | Edit Table Properties | EI | HIGH |
| 7.6 | Delete Tables | EI | HIGH |
| 7.7 | Input Records into Tables | EI | AVERAGE |
| 7.8 | Modify Records in Tables | EI | AVERAGE |
| 7.9 | Duplicate Records | EI | AVERAGE |
| 7.10 | Define Values to other Values | EI | HIGH |
| 7.13 | Create Tree Structure | EI | HIGH |
| 8.1 | View Database Trees | EQ | AVERAGE |
| 8.2 | Set ActiveReports Report as View | EI | HIGH |
| 8.4 | Set Dundas Chart as View | EI | HIGH |
| 8.6 | Set Default View | EI | LOW |
| 8.7 | Plain Text Browser-based CSS Editor | EI | AVERAGE |
| 8.8 | Load CSS Templates | EI | AVERAGE |
| 9.1 | View Records by Tree | EQ | AVERAGE |
| 9.4 | Filter Records | EQ | HIGH |
| 9.5 | Show Views | EO | LOW |
| 9.6 | Context-specific Buttons | EO | LOW |
| 9.7 | Select view for Record Type | EQ | LOW |
| 9.8 | Change Default View | EI | LOW |
Legend:
- ILF: Internal Logical File
- EI: External Inputs
- EO: External Outputs
- EQ: External Inquiry
Calculation
After identifying the datatypes and the complexity of the functions, we calculate the total complexity by multiplication and summing up the result. We then will have the Total Number of Unadjusted Function Points. From there, we will then adjust it with the Multiplied Value Adjustment Factor (MVAF) to produce the Total Number of Adjusted Function Points.
The calculation is as follows:
| Type of Component/Complexity | Low | Average | High | Total Complexity |
|---|---|---|---|---|
| External Inputs | 4 x 3 = 12 | 6 x 4 = 24 | 6 x 5 = 30 | 66 |
| External Outputs | 2 x 3 = 6 | 0 x 4 = 0 | 0 x 5 = 0 | 6 |
| External Inquiries | 1 x 3 = 3 | 2 x 4 = 8 | 1 x 5 = 5 | 16 |
| Internal Logical Files | 1 x 3 = 3 | 0 x 4 = 0 | 0 x 5 = 0 | 3 |
| Total | 24 | 32 | 35 | 91 |
| Total Number of Unadjusted Function Points | 91 |
|---|---|
| Multiplied Value Adjustment Factor | 0.7 |
| Total Adjusted Function Points | 64 |
| Estimate of Function Points/Week | 4 |
| Estimate of Weeks for Completion of all Function Points | 16 |
Note: The MVAF was calculated MVAF = (TDI * 0.01) + 0.65 where TDI was 5.
Estimation in 440
Software estimation will primarily be used to assist internal project planning. Determining the number of adjusted function points helps to determine the size of the project, from which the estimate of function points/time can be used to determine how long the project will take to implement. This estimation will assist in planning the design, implementation as well as testing of the functional points. Furthermore, identifying the predicted difficulty of each function point will help resource allocation, in that more resources can be allocated to difficult function points. The project manager and the implementation manager will produce a form for team members to fill in after coding each task. The form will inlcude the team member coding, the number of points, the estimated time to complete the task, the actual time to complete the task. This will allow both the implementation manager and the projecct manager to calculate the time per function point and adjust the schedule accordingly. This form will also provide additional information, such as, the time per function point for each team member and allow better allocation of tasks according to the difficulties.
The estimation will also be used as a way of communicating to the client and other third parties how the project is progressing. This would be provided as a percentage complete based on the number of function points complete / total function points for the project. Functional point analysis is especially useful for this as it allows the project to be described in non-technical terms, and thus can be easily understood by non-technical users. If the client wishes to reprioritise or modify requirements, the functional point analysis can also be used to help identify a way to potentially remove some requirements and add ones with similar function points, to minimise slippage of the project. To initiate this the client liasion officer would conduct the following procedure:
- the client liasion officer arrangers a meeting with the client
- during the meeting the current progress of the team and the ammount of time required to complete the remain features of the project would be discussed
Confidence in Estimation
Whilst Function Point Analysis is a proven technique for successfully sizing projects, it is primarily a manual operation that result in a different outcome when performed by different people. This inherently means that its success is largely dependent on the experience of those applying it. The team has relatively high confidence in the accuracy of the breakdown of the system into into a set of function points, however, the problem comes from attempting to estimate how many function points can be completed per hour. Given the team's lack of experience, both in large-scale software development and working with each other, it is extremely difficult to predict the rate of our productivity. Moreover, productivity is very likely to increase over the course of the project, and thus the function point/time calculation will vary as well.
This estimation of function point/time is probably the weakest part of the analysis. However, given that the analysis is relatively easy to update, the estimation is likely to become more accurate as it is updated throughout the project, thus increasing confidence as time progresses.
Monitoring the Accuracy of Estimation
The software estimation will be monitored during the implementation and test phases of the project. As each functionality is implemented and tested the time taken will be monitored, this will determine the accuracy of the estimation of the difficulty of a function. The number of function point implemented per week will also be monitored to determine if the estimation is accurate for each week of the project. This will have to be monitored over the entire project as the productivity of the team may vary due to other commitments. However, as the progress is monitor the team will be able to update the estimate from the experience gained.