Effort Estimation Model

Effort Estimation Model Effort Estimation Model for each Phase of Software Development Life Cycle Information Technology Abstract Assessment of main risks of software development discloses that major threat of delays are caused by poor effort / cost estimation of the project. Low / poor cost estimation is the second highest priority risk [1]. This risk can affect four out of total five phases of software development life cycle i.e. Analysis, Design, Coding and Testing. Hence targeting this risk alone may reduce the over all risk impact of the project by fifty percent. Architectural designing of the system is great activity which consumes most of the time in SDLC. Obviously effort is put to produce the design of the system. It is evident that none of the existing estimation models try to calculate the effort put on designing of the system. Although use case estimation model uses the use case points to estimate the cost. But what is the cost of creating use cases? One reason of poor estimates produced by existing models can be negligence of design effort/cost. Therefore it shall be well estimated to prevent any cost overrun of the project. We propose a model to estimate the effort in each of these phases rather than just relying upon the cost estimation of the coding phase only. It will also ease the monitoring of project status and comparison against planned cost and actual cost incurred so far at any point of time. Key Words: Effort estimation, software development life cycle, Risk Mitigation, Project Planning. Section 1:Back Ground and Motivation Existing estimation techniques such as Functions point estimation and use case estimation rely upon the artifacts generated in earlier phase. These artifacts (i.e. Use case diagrams, class diagrams, sequence diagrams, activity diagrams, state chart diagrams etc) depict the architectural design of the entire system. These diagrams are not generated out of a blue or are not instantly available without putting any effort. Standard task set and the percentage of work duration associated with it decomposes the ratio of effort put in each phase. Activity Standard Work Effort% Definition Phase Business Requirements 6% Functional Specifications 10% Delivery Phase Detailed Design 14% Code and Unit Test 40% System Testing 20% User Acceptance Testing 10% Total Effort 100% Table 1 Standard Task Set Work Duration %age [4] It is evident in Table 1 that although major ratio (i.e. 40%) of work effort is put in code and unit test phase. The rest 60 percent effort is put in different areas of the project development life cycle. Hence this signifies the importance of estimating cost for these phases of software development life cycle. Usually the effort estimation is done after the analyses phase when the project reaches into coding stage. The cost / effort is measured in terms of line of codes for each functionality to be incorporated into the software. Therefore it is very clear to understand that only 40 % (i.e. as shown in table 1) of the total software development effort is estimated. Whereas this estimation is delayed until all the analyses and design has completed. We have adapted a different approach and suggest that effort estimation shall be carried out for each phase of the development process. We propose this model to avoid the risk of low cost estimation as earliest as possible in the development process. Current software cost estimation methods first try to know the size of the software to be built. Based upon this size the expected effort to be put is measured. Estimated effort further is utilized to calculate the duration (i.e. Time required) and cost (monetary/human resources) of the project. Calculating the size of project is the foremost logical step to be taken in order to estimate the effort. If we do not know the distance to be travelled we can not estimate the cost and duration per mileage. Therefore we also first measure the size of the entire project. We know that there are mainly three categories of software projects i.e. Organic mode: These are relatively small, simple SW projects (application programs e.g. Thermal analysis program) Embedded mode: System programs which are developed within tight HW, SW and operational constraints (flight control SW for aircraft). Semi-detached mode: An intermediate level (size and complexity, utility programs) SW projects with mixed experience, mixed requirements. It can be mixture of organic and embedded software as well. Therefore these categories of the software project would effect the estimation of each phase. We propose the modular approach to be adapted for the development efforts so that even large scale enterprise information systems can also be decomposed into a mix of several modules of organic, semi detached, and embedded system. Therefore the focus can be put in individual module accordingly. Following are the sections which individually discuss the methods to estimate the expected effort to be put in each phase of software development life cycle. Section 2: Measuring the Size of each project We do not try to measure the size of the project as a whole rather focus on measuring the size of each phase i.e. Analyses, design, coding and testing phases. This can provide us different milestones in the road map of project development. Our main objective is to suggest the estimation methods for analysis, design and testing phasing. We do not focus much on coding phase, as we would refer to the already done work for this phase. We estimate the size of each phase based on the artifacts and project products which are produced in that particular phase. E.g. the analyses phase produces the detailed user requirements document (use cases etc), design phase produces the class diagram, database Model i.e. E-R diagram, Sequence diagrams, activity diagrams etc. based upon these deliverables in each phase the time and effort to produce these are estimated. Figure 1 shows the step wise flow chart of entire project planning process. After the identification of project scope/objectives, characteristics and infrastructure, the identification of all the activities is done. This identification of activities at early stage may provide the strong basis to estimate the size of each individual phase of software development process. As this involves the work break down structure to be defined and can identify the product / deliverable of each phase. Figure also shows that based on this identification of each activity the cost and risk are estimated for each activity. As this is part of project planning. Therefore we can obtain this information in the most earliest phase of project planning and do not need to wait for longer duration as have to wait in existing cost estimation models to estimate the cost of construction of the software. Hence early stage activity identification can help us to estimate the cost/effort for each phase i.e. analysis, design, coding and testing. Figure 1. Step wise Project Planning [3] Moreover the responsibility of the analysis and design of the system goes to the systems analyst. Generally system is viewed in terms of a collection of sub systems therefore each sub system analysis and design is the responsibility of any individual analyst. Hence the human resource need is very clear for analysis and design phase. But when team work is done in coding and testing phases then more stressed has to be put to estimate the required human resources. Bruegge defines the following work products to be generated in each phase of software development life cycle. Figure 2 Software Life Cycle Activities. [6] Bruegge describes and decomposes the overall system model and design into three types of design models i.e. Analysis model Object Design model Behavioral model Section 3: Requirement Elicitation Analyses Phase Size and Effort Estimation In earlier phase of the development process the scope is defined. This may also provide an intuitive vision of project size to the experienced project managers. Unified Process for software development defines the work products in different phases. [2] During the analyses phase we propose Inception points to be identified and estimated. Inception points refer to the points which must be analyzed about in context of the interest of each stakeholder. As use cases represent the points of some business operation or systems functionality, which needs to be clearly understood and modeled therefore we call them inception points. We must know the accurate number of inception points and the effort needed to develop those points. Unified process for software development describes the following main work products in Inception phase. Definition of the problem Identification of all stakeholders Identification of Functional / non functional requirements Validation of requirements [2] Therefore all the main inception points can be clearly identified. Inception point will mainly focus around the identification of the users / stakeholders (possible actors functionality needed) and requirements. The size can be estimated for this phase by estimating the requirements. This can further be utilized to estimate the cost to build the use cases for each requirement. We suggest that the elicitation of requirements may consume effort / cost relevant to the number of requirements and user present. No of Requirements No of Users Project Size Less than 25 1-10 Small 25 50 11-50 Average 50 above 50 above Large Table 2 Project size based on no of requirements. Table 2 can signifies the need to enumerate each requirement, moreover each requirement will produce a use case and would also identify all its possible actors. Hence this can produce the effort needed to build those use cases which need to be documented in the software requirement specification document. Use cases can also be weighted to measure their complexity. So that the size can be determined and the time taken to create those use cases can be determined. No of Processing Points No of Actors No of > Use case Time taken to develop No of Person 1-3 1-2 1-2 3 Hours 1 4-5 3-5 3-5 5 Hours 1 5 + 5 + 5 + 7 Hours 1 Table 3 Use Case Types We have categorized the use cases based upon the number of processing points. actors, and the extension use cases which emerge from that particular use case. We conducted a survey to get the opinion from experienced software engineers and project managers in different software houses. We had distributed the questionnaire which primarily contained the questions to ask about the time needed to develop different types of use case as described in the table 3. We have processed the survey data and have obtained the average time for each category of the use case. Hence we can sum up the total number of inception points and can multiply them by the number of hours required for each type of use case. Summing up the time required in hours for each type of use case can then further give us the total number of hours required to build inception points. Section 4:Design Phase Size and Effort Estimation Object design model and behavioral model are produced during the design phase. We can estimate the size of each model alone and can sum the effort to obtain the total design phase effort. We can identify the Design Points, therefore we can add the weight associated to each design point and hence can measure the size and effort of that particular design point. This gives the lower level granularity to perceive the effort and size of each possible system feature to be designed. Hence further gives us tighter grip on the project progress. Following can be the possible design points: Entity classes Boundary classes Control classes System decomposition System integration Aggregation / composition of objects Generalization / specialization of objects Object interaction Interfaces Application logic 4.1Object Design Model Size and Effort The main artifact of the Object model is class diagram. Class diagram is comprised of several entity, control and boundary classes. If Entity Relationship diagram has already been produced then the effort can be lessened as persistent object are already been identified. Further more each type of classes need to be designed very carefully as control classes depict all the processing and interaction responsibilities among the classes. Where as boundary classes are responsible for the interfacing with either other system components, users, or external system for electronic data interchange. We declare each class to be a design point. A class in the system primarily depicts a systems object which interacts with other objects in systems environment. Hence a class does not dangle into a void but have solid connections and interactions with other classes that must be very accurately and rightly designed. Therefore we can categorize the class based on the complexity of their design. A class would be difficult to design if it has many associations , aggregations, generalizations, functionalities, overloading, overriding etc. Table 4 depicts the parameters to judge the complexity ratio of any class to be designed therefore the effort would be relevant to the complexity ratio. Complexity Ratio No of Associations No of Interactions No of Methods No of Interfaces Time Required (Hours) Low None None 1-5 1 2 2 Medium Single Single 5-10 2 5 5 High Multiple Multiple 10-20 5 10 8 Table 4: class categories for design complexity Our conducted survey tells us that based upon the complexity ratio any class can take 2, 5, or 8 hours for designing. Remember that this time is for design of the class but coding can take extra effort in the coding phase. Therefore if we can obtain the total number of design points and multiply them with the hours required to get the total hours required for the entire class diagram. 4.2Behavioral Model Size and Effort Behavioral model comprises of different diagrams which depicts the state, interaction of different classes with each other and the sequence of activities performed in the system to achieve any objective or perform business function. These diagrams are sequence diagram and state transition diagrams mainly. We declare each of these diagrams to be the design point as it is very essential to trace the possible states of the system so that a good design can be obtained. Whereas the sequence diagrams is the most sophisticated diagram that shows the complete step by step functionality and participating classes. But if the functionality of the existing system has been well understood then creation of sequence diagrams become easier. Our surveyed data reveals the facts that each of these diagrams can be different in complexity level i.e. low, medium, high. Parameters involved for determining the complexity level are summarized in table 5 below. Complexity Ratio State Chart No of States No of Transitions / Events No of Activity of State No of Actions associated with states Time Required (Hours) 1-5 1-5 1-5 1-5 3 5-10 5-7 5-7 5-7 5 10-15 7-10 7-10 7-10 8 Sequence Diagram NO of Classes No of Actors No of Events No of Control, boundary Entity Objects Time Required (Hours) 1-5 1-5 1-5 1-5 3 5-10 5-7 5-7 5-7 5 10-15 7-10 7-10 7-10 8 Table 5 Complexity parameters for behavioral model diagrams We perceive each of such diagrams as design point and can sum up the total number of hours required for each to obtain the total size and effort estimate to develop behavioral model. 4.3Data Model Size and Effort Mainly an objective is set to achieve an Entity Relationship diagram to depict the over all database design for the entire software system. E-R diagram itself involves several steps to be carried out. The size of database model itself may relate to the type of software project. Embedded software may not be using any large data base but may work using few files available in the read only memory. Whereas organic and semi detached software projects may require the data to be accessed from large databases. Complexity further increases when database has to be distributed. For the time being we do not discuss about distributed databases and leave it for our future work. Therefore we aim to estimate the size of conventional database to be built. The following table 4 summarizes the parameters that would affect the size of the database. Complexity Ratio No of Entities No of Relationships No of Aggregations Normalization Degree Query Joins Low 10-20 5-10 1-5 1-3 10-15 Medium 20-35 10-20 5-10 1-3 15-25 High 35-50 20-40 10-20 1-5 25-50 Table 6: Complexity parameters and Ratio to develop E-R Model The larger the number of entities to be designed, larger the database size increases. It is time consuming task to identify the persistent objects (i.e. entities) in the system. Then to design its attribute set. Different types of attributes i.e. composite, derived and multi-valued attributes are difficult to design and to decide that which entity would be the best suitable place for any particular attribute. Based upon the complexity ratio we had conducted a survey to know that how much time and personnel is required to build the E-R model. We have analyzed the data and got the average time and no of personnel required to develop E-R model. Complexity Ratio Days Required Personnel Required Low 7 10 1 2 Medium 10 25 1 3 High 25 40 1 5 Table 7: Required Effort for E-R model We have considered the flexibility range in the commencement of the activities as well, therefore have concluded the time and personnel requirement in to range of lower and upper limit. Section 5.Coding phase Size and Effort estimate Much work has been done to focus at the code phase effort and size estimation. Mainly Constructive Cost Model and Use case Point method strive hard to achieve this objective. But still there is room for the refinement. But as our main objective was to talk about the other phases e