Design Point An Empirical Approach for Estimating Design Effort

Transcription

1 Design Point An Empirical Approach for Estimating Design Effort Abstract: In this paper, we present an extension to Function Point estimation, Design Point, conceived to estimate size and productivity of design phase for software development projects executed by Infosys. This approach is based on capturing functional and non-functional requirements, identifying design sensitive parameters influencing design phase and deriving design size for any development project. An empirical validation and refinement of model (identification of design sensitive parameters and degree of influence for each for the parameters) has been performed to test the hypothesis over a large number of projects in different stages of execution Introduction Software development effort estimation is the process of predicting the most realistic effort required to develop software based on available information. In order to spend the right amount of time in each of the software life cycle stages we see a need to predict individual life cycle effort. This especially becomes critical when the project runs for several months and years as there is a need to monitor the project progress and team productivity across different stages. Traditionally, Organizational/industry level guidelines for distribution of effort across Software Development Lifecycle (SDLC) phases are applied to predict effort for individual life cycle stages that does not take into account the project characteristics design intensive, etc. as the approach of execution could be different for each kind. This necessitates forming proper guidelines to estimate effort and measure productivity for individual life cycles of the project depending on its characteristics. This paper explores various components of the design phase for application development projects and tries to come up with an empirical approach for accurately sizing design and calculating design productivity. This approach leverages existing industry norms for sizing functional requirements using Function Point (FP) concepts; define an approach for capturing non-functional implementation requirements and identifying parameters sensitive in the design phase. This approach has been deployed across 30+ development projects in Infosys across various business domains like Finance, Retail and Insurance and a statistical analysis and validation has been performed for the model. The paper is organized as follows: Section 2 reviews the literature on software effort models, parameters influencing design phase, and size. Section 3 discusses the research hypothesis, while Section 4 presents empirical testing methodology, the statistical approach and results of empirical testing, followed by conclusions. Related Work Sizing software has remained one of the most challenging aspects of software engineering. Several measures and approaches have been defined to come up with accurate sizing of software components and hence accurately predict software costs. Amongst various sizing methodology, Function Points (FPs) and Use Case Points (UCPs) have attained wide acceptance amongst software professionals. These approaches are based on functionality of the system as perceived by the Business Users and which allows for its application very early on in the project. However there are different points of view on Function Point assessment (FPA) methodology primarily on how to address technical complexity [7], identification of weights for various complexity parameters [7] and relevance of the 14 parameters to various SDLC phases of execution [6]. Costagliola et al [1] have defined a FP like approach, called Class Point, to estimate size of object oriented products based on design documentation. They have proposed a two phased approach, where first phase Class Point 1 (CP1) can be performed at the beginning of project and the second phase Class Point 2 (CP2) can be performed when more information is available. This

2 approach is primarily based on identification and classification of classes based on four different system components and evaluation of complexity of each class. This approach has leveraged the Value Adjustment Factor (VAF) prescribed by FPA and added additional design sensitive parameters such as user adaptivity, rapid prototyping, multi-user interactivity and multiple interfaces while deriving the final class points. 3D Function Points [6] is also based on the design artifact and tries to merge FP concepts on design sizing. This approach considers each class as Internal Logical File (ILF) and the messages across class boundaries as transactions. Predictive Object Points [2], uses weighted method per class (WMC), and combines this information with average depth of inheritance tree, average Number of Children (NOC) and uses weighting factor for each type of method. These approaches can be implemented only at the end of the design phase for object-oriented design artifacts. Baresi et al [6] investigated the impact of number of attributes of design components on the design effort for web applications. Some of the attributes contributing to the design effort for a web application were identified to be Entities, Components, Slots, Granularity, Association, Cohesion, Reuse, Navigation Measures & Presentation Measures. Shupp et al [5] have proposed an activity based counting technique based on FPA and is referred to as System Function Points. Unlike FPA, where the influential factors reflecting the environmental influences on a software development effort are applied against the sum of the Unadjusted Function Points, the System Function Point technique embeds the Systems Engineering environment into the difficulty factors directly. The System Function Point technique captures the difficulty (Difficulty on Functionality, Scenario, Interfaces, Operator Interfaces, Data Control Processing, Design Stability.) applied to each item counted based on the following four areas: Pervasiveness, Ambiguity, Technology, and Analysis /Evaluation. The literature survey and data available from projects reveals that FPA does not comprehensively address the individual life cycle stage sizing challenges and has to be fine tuned for accurately predicting design size and design effort at the end of requirements phase. A bottom-up design sizing approach like Class Point can be implemented only at the end of design phase and hence cannot be deployed for predicting effort while a top down FPA based approach does not accurately reflect the impact of technical functionality and other design sensitive parameters towards design size and design effort Research Hypothesis Here we describe the proposed process for sizing design phase for a software development project and establish various parameters which influence the design. One of the key factors which influence the design size for any software project is the nature of functionality delivered by the application. FPA methodology for sizing functional requirement is a universally accepted practice and can be leveraged for sizing design components. The Unadjusted Function Point (UFP) reflects the specific countable functions provided to a user by the project/application. The application s specific user functionality is evaluated in terms of what is delivered by the application and not how it is delivered and only user requested and defined components are counted as part of UFP [IFPUG manual] In various researches, different ways to capture the technical components that significantly influence the design effort have been described. This model separates design components for functional and technical requirements and identifies key design sensitive parameters which influence design size or effort. Design size for components catering to functional requirements is obtained by leveraging UFPs. This model has also identified guidelines for capturing the technical requirements for any software development project and complexity parameters which influence design effort. The total adjusted design size for any application thus can be measured using following formulae

3 Design Size (Design Points) = ( UFP functionality + UFP technical requirements) * Design Complexity UFP technical requirements are derived out of various technical and non-functional requirements supported by the software project. Technical requirements are those which are not directly identifiable by the users. Some of the examples of technical requirements include Logging, Caching, Metering, Exception handling, Formatting utilities, Data Transformation, Connectors, batch framework, transaction management, utility libraries, socket communication and asynchronous processing. We have derived guidelines to map effort/size for technical requirements based on the implementation effort. These guidelines will enable software developers and designers calculate equivalent unadjusted function point size for various technical requirements. Technical requirements can be implemented either through creation of new components or through reuse of existing components for any development project. New Components: In this approach, number of logical sub-processes has been identified as a key parameter for defining complexity level (and hence size) of technical requirements. A sub-process can be defined as an identifiable atomic workflow which helps in implementing a technical requirement. The complexity has been categorized into Low, Intermediate, Medium, High and Very High based on the number of sub-processes. Design size for new components based on unadjusted function points (UFP technical requirements for new components) can be computed based on following table: Complexity Definition Number of Sub-Processes UFP technical requirements for new Components Low (0-3) Intermediate (4-8) Medium (9-15) High (16-25) Very High Guidelines for arriving at design size for technical components based on complexity on a consistent basis (number of sub-processes) has been arrived at based on empirical data collected across 30+ development projects spanning across multiple technologies. Design effort for creating the technical components has been compared with design effort for creating functional components and number of sub-processes requiring similar effort have been mapped to average unadjusted function point size of the functional components. Design size for technical components in terms of UFP has been validated by comparing predicted design effort with actual design effort. Re-use of existing components: A large number of software development projects leverage existing components during development and hence guidelines have to be laid down for use of these components. Key parameters which define complexity in re-using components are Usage, Configurability, Requirement of a Proof-of-Concept, System Setup, Documentation, Interaction/Dependencies and Application Program Interface (API) Count. Guidelines have been laid for deriving the Technical component complexity based on the above parameters. Technical component complexity for any technical requirement will be sum of all complexity factors and size for UFP technical requirements reused components and can be computed based on the Technical component complexity as per table defined below. Complexity Definition Technical component Complexity UFP technical requirements Reused Components Low (0-10) Intermediate (10-18) Medium (18+) Design complexity factor: FPA counting practices [8] have identified 14 General System Characteristics (GSCs) which influence the size of any application or project. Influence of these GSCs is spread across all the SDLC phase of

4 application development. In this model, we have identified and isolated eighteen system characteristics which have a greater influence on design phase. GSCs defined by FPA [8] like Data Communications, Complex Processing, Reusability, Multiple Sites, Distributed Data Processing, Heavily used user configuration (user and system) and Transaction Rate have a direct impact on design phase and have been included in the proposed model. Some of the other parameters like Prototyping [1], User adaptivity [1], Design patterns [5], Multi User interactivity, Data Complexity, Interoperability, Recoverability and Multiple Technology also influence the design phase. Parameters like Data Communication, Complex Processing, Prototyping, Multi User Interactivity, Data Complexity, Heavily Used configuration, Recoverability and Multiple Technology have a significantly higher influence on the design phase and hence have been given higher weight-age towards design size/effort. Design complexity Parameters Data communication [8] Complex processing [8] Reusability [8] Multiple sites [8] Prototyping [1] User adaptivity [1] Multi User interactivity [1] Interoperability Design patterns [5] Description Degree to which the application communicates directly with the processor Degree to which processing logic influenced the development of the application Degree to which the application and the code in the application have been specifically designed, developed, and supported to be usable in other applications Degree to which the application has been developed for multiple locations and user organizations Describes the amount of prototyping required while designing Degree to which the application has been developed for its responses to the user input Describes the amount of interaction between users Describes the amount of interaction required between the applications. Describes the required design architecture complexity. Data complexity (environment and data type) Distributed data processing Heavily used configuration (User and System) [8] Performance [8] Transaction rate [8] Recoverability Multiple technology Describes the requirement for high configurability, Complex data types and data structures within the database Degree to which the application transfers data among components of the application Degree to which computer resource restrictions influenced the development of the application Degree to which response time and throughput performance considerations influenced the application development Degree to which the rate of business transactions influenced the development of the application. Describes how data will be recovered. Addresses complexity due to multiple technologies Along the lines of FPA, each parameter is rated on a scale of 0-5 (unless otherwise) mentioned based on the degree of influence (refer Appendix II). The final design complexity based on degrees of influence and respective weightages can be defined as design complexity factor DCF = (TDI*0.01)+1 Statistical Analysis and Results Validation of model in isolation The proposed model for capturing design size was deployed in live projects in various business domains like Finance, Retail, Insurance, etc and the methodology was fine-tuned based on the results. Empirical design size derived from this model and actual design effort were used to calculate design productivity for different technologies. During the first phase, this model was deployed in a controlled environment of 10 application development projects in Infosys of average effort of 1100 person days. The results from the controlled deployment were subsequently analyzed to fine-tune the model. This model was subsequently deployed in 30+ application development projects in various technologies (Java,.NET and Mainframe) of average effort of 1200 person days.

5 This study has shown a very strong and positive correlation in design size and design effort in the sample of projects selected for deployment. Another positive indicator was the co-variance in the design productivity. The co-variance reduced by over 50 % in our model over the co-variance calculated in the traditional way ( Sized in Function Point/ Design Effort) This model was then deployed in a larger number of projects for deriving baseline design productivity for different technologies. For further confirmation, design size (calculated using this model) and design productivity ( baseline) was used to estimate design effort for new development projects. There was a significant improvement in estimation accuracy of design effort and 95% of the projects had less than 20% deviation while 75% of the projects showed less than 10% deviation in design effort (actual effort vs estimated effort). This confirmed the robustness, stability, accuracy and scalability of the model We have observed that the deviation occurs because of certain development aspects. Negative deviation is due to reuse of design components, frameworks and patterns, requirement clarity etc, whereas positive deviation is due to significant requirement changes, skill set issue etc. The framework is quite generic and independent of technology for application development environment. Interestingly, when we compared the design productivity between technologies we could not see much variation between Java and.net design productivity but significant variation with procedural methodology. We believe the same can be further extended to estimate design effort in the beginning of the design phase as well as decide the schedule and staffing requirement based on overall design complexity (we believe higher complex design would need more experienced staff) Figure 1: Analysis with overall project productivity We have also tried to fit our analysis in the bigger scheme of things and tried to see how it correlates with overall project productivity as it is generally expected that good design productivity would lead to higher project productivity. Figure 2 represents the correlation and it shows that our assumption was found true in the analysis. Figure 2: Analysis of design effort and Design complexity To understand how design efforts correlates with design size and project complexity, we used the data of 30 development projects collected earlier and compared the design effort % along with Overall design complexity (measured as Design size in design point / Functional size in Function point) as shown in figure 1. Again, we find strong positive correlation between the parameters which is as expected.

6 Conclusions Several measures have been defined in order to estimate the size of software systems and then estimate development effort using the same. Function Points have achieved a worldwide acceptance to estimate the size of business software systems and to predict the effort, cost and duration of its development. However, estimating internal life cycle stage wise effort, especially design phase continues to remain a challenge. Similarly, Function Point is being used as measure of overall productivity but productivity at the end of design is not an accurate one when function point is used for the same as well. The literature shows that the FP method needs to improve further in case of using it for individual life cycles. The Design Point approach leverages the main features of the FP keeping the design phase in mind to provide a more accurate estimate and better understanding of design productivity. As it leverages original function point and also remaining additions are structurally designed similar to function point, it would be easy to use and would provide an effective measurement in traditional application development project. This approach for computing design size and hence base-lining design productivity will allow Project Managers to accurately predict design effort, design timelines, number of architects and designers required in the critical design phase, and allow the Project Managers additional parameters for monitoring and tracking project health during the initial phases of project execution. This methodology will allow software professionals to accurately estimate design effort for projects which do not involve all the SDLC phases. Overall we strongly believe it should help understand the design process much better and help us in better control and optimization of the process. The additional effort needed to calculate the same is minimal. However, it needs to be tested and explored further in embedded system design or complex algorithm design. Further data points are needed for fine tuning the method and the equation, however the results of such analysis till date, lead us to believe in the effectiveness of the approach for Application Development projects Acknowledgement The authors would like to gratefully acknowledge the reviewers in Infosys technologies for their helpful comments and constructive reviews while designing the concept and improving the manuscript. The work would not have been possible without the encouragement of Kris Gopalakrishnan, CEO Infosys, K. Dinesh, Head of Quality & Internal Systems and Member of Board, Infosys and Srinath Batni Head Delivery and Member of Board, Infosys and Satyendra Kumar, Global Head Quality. We acknowledge the contribution of our reviewers - Ramakrishnan M, Head SEPG, Infosys, J Srinivas & Srinivas Prabhala Head of Architecture team in Banking & Capital Market practice for their review comments.

7 References (1) Gennaro Costagliola, Fillomena Ferrucci, Genoveffa Tortara - Class point An approach to size and estimation for OO system, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 31, NO. 1, JANUARY 2005 (2) Simon Moser, Bedag Informatik - Measuring Object-Oriented Business Models - TOOLS '97 Proceedings of the Technology of Object- Oriented Languages and Systems - Tools-25, IEEE Computer Society Washington, DC, USA 1997 (3) Eugenio Capra, Chiara Francalanci, and Francesco Merlo - An empirical study on the relationship among software design quality, development effort and governance IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 34, NO. 6, NOVEMBER/DECEMBER 2008 (4) Fast Serious: a UML based metric for effort estimation - Massimo Carbone and Giuseppe Santucci, Universita' degli studi di Roma "La Sapienza" 6th ECOOP Workshop on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE 2002)June 11th, 2002 (5) Jeffrey K. Shupp Applying an Activity Based Counting Technique - (Lockheed Martin, Management and Data Systems), COSYSMO, University of Southern California (6) Luciano Baresi, Sandro Morasca, Paolo Paolini - Estimating the Design Effort of Web Applications - METRICS '03 Proceedings of the 9th International Symposium on Software Metrics, Sydney, Australia (7) CHARLES R. SYMONS- Function point analysis difficulties and improvements- IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 14, NO. I, JANUARY 1988 (8) International Function Point Users Group (IFPUG) Function Point Counting Practices Manual - Release 4.3.1, Counting Practices Committee, IFPUG - Srinivasan Venkataraman is a Group Project Manager with the technology focus group of Infosys' Banking and Capital Market practice. With over 16 years of experience, he drives technology solution for business challenges of fortune 100 companies. His areas of interest include legacy system integration and modernization of archaic legacy applications to improve on performance and cost of operations. Srinivasan Venkataraman Srinivasan_v01@infosys.com Pratip Sengupta is a Group Project Manager with the Infosys. With over 14 years of experience, he manages software services for multiple projects for Banking and Capital Markets clients. His areas of interest include object oriented, distributed technologies and Internet solutions. He has been associated with multiple development projects as manager and architect. Pratip Sengupta Pratip_Sengupta@infosys.com Amit Patni is a Senior Technology Architect with Infosys Banking and Capital Markets practice. He has over 12 years of experience spanning multiple technologies and enterprise applications in the retail banking space. His area of interests includes SOA Integration, Event Driven Architectures and CEP. Amit Patni Amit_Patni@infosys.com Bibhash Saha heads quality function of Infosys Banking and Capital Markets practice. With over 16years of experience, he drives process improvements in various critical client programs for Infosys. His area of interest includes estimation methodologies, Six Sigma, CMMI assessments & metrics and statistical process controls. Bibhash Saha Bibhash_Saha@infosys.com