ESTIMATING EFFORT REQUIRED TO DELIVER
OBJECT-ORIENTED SOFTWARE DEVELOPMENT PROJECTS:
A USE-CASE POINT’S ACCOUNT
SCOTT, E. and JOHNSTON, K.A.
University of Cape TownE-mail: [email protected]
ABSTRACT
The high failure rate of ICT application development projects can in some cases be attributed to inaccurate estimations of cost and schedule. The lack of sufficient information during the early stages of projects may hinder reliable estimates of effort. Developing an estimate is a complex task that requires a significant amount of effort as estimates can be performed at various stages of a project and experts are not always available to perform these tasks. The traditional Function Point Analysis is a well known and widely used technique of estimating projects, managing change of scope, measuring productivity, and communicating functional requirements. More and more Information Systems projects are being developed using an Object-Oriented approach, for which the Function Points approach was not initially designed.
The Object-Oriented paradigm applies the Unified Modelling Language (UML) in the analysis and design phases to model future systems. Use Cases and Use Case Diagrams in UML are used to depict functional requirements in the early stages of a project lifecycle. Several attempts have been made to use Use Case Points, based on ideas similar to that of Function Points, to calculate project size and estimate effort.
The third year systems development group project of the Information Systems major at the University of Cape Town is the students’ first encounter with a real world project. The main objective of the project is to give students a real world experience of the diverse and complex nature of developing an information system, where managing scope, time and quality are of utmost importance. In order for these projects to adhere to sound Object-Oriented principles, the authors felt obliged to require that students use Use Case Points, developed by Karner in 1993 to calculate project size and estimate effort. One of the initial stumbling blocks was that no comprehensive model explaining all factors could be found. Inputs from Koirala (2004) and Dennis, Haley Wixom & Tegarden (2005) were used, adapted and developed into a unique South African based model using Use Case Points to estimate Object-Oriented system development projects.
This paper describes the process used to develop the detailed model which was implemented and tested by 25 third year project groups in 2005. It further analyses the estimates in relation to some of the outcomes of the projects and comments on the effectiveness of the implementation. Current limitations are considered and further improvements are proposed.
KEY WORDS: Estimating; Measuring, Productivity, Object-Oriented, Use Case Points, Function Points
INTRODUCTION
Several factors including effective estimating of time and money contribute to the success or failure of software projects. It is thus not surprising that the overall success rate of Information Technology (IT) projects was just 34% in 2002 (Schwalbe, 2006). Estimating software projects is a complex task which requires a significant amount of effort at various stages of the project. Estimates are influenced by the size of task, the expected productivity (how fast work will be done), the resources available, constraints and environment. Contributing factors to inaccurate estimation could include:
• the development of an estimate without a full understanding of the requirements.
• the use of tools or estimation in general without the necessary experience.
• a bias toward underestimation.
• an attempt to provide a fixed number for a bid and not a real estimate (Coombs, 2003; Schwalbe, 2006).
A fair amount of literature exists that deals with systems development (SD) projects. Most of these sources discuss procedural or traditional SD projects and approaches such as Function Point Analysis (FPA) to estimate the productivity for these systems. This paper reports on a research project to estimate
Object-Oriented (OO) student group projects. It was envisaged that the outcomes of the research project would contribute to the growing body of knowledge on estimating OO projects, not only in South Africa, but also globally.
As a first step, Use Case Points (UCP) was identified as a suitable approach to estimation. Secondly an account of “How to use UCP” was taught to the student teams with the aid of lectures, examples and a workshop, was given. Once the training was completed it was a requirement that all the development teams implement UCP to estimate productivity of their own OO projects as a third step. Results that substantiate the estimation accuracy of the approach are shown in Table 2 and discussed in the analysis section of this paper. In previous years student teams had difficulty to relate to the structural approach of FPA. They however seemed more comfortable with the implementation of UCP as it appeared to better aligned with the OO paradigm implemented in the projects.
The paper proceeds by providing an overview of the current literature on estimation. Literature on FPA and UCP was then reviewed. This was followed by a description of the systems development group project, the method used in this research project, and lastly a presentation of the findings.
ESTIMATION
The Standish group occasionally publishes a “CHAOS” report which gives statistics and criteria related to IS project management successes and failures. Historically application development projects have a poor track record for meeting cost goals. Average cost overruns from the 1995 CHAOS study was 189%; this figure improved to 145% in the 2001 study (Schwalbe, 2006). In 2001, the British Computer Society (BCS) reviewed 1027 projects, 13% were successful in term of scope, time, cost and quality (Coombs, 2003). McLeod & Smith, (2003, p83) confirm that an estimate is “a prediction which is likely to be above or below the actual result”. The estimation of costs, delivery dates and resources are required in the initiation and planning phases of the project management process, these being the first phases in the process. These elements should however also be revised at the end of each of the subsequent phases in the process group (Bocij et al, 2006; Coombs, 2003). Estimates are however revised as the project progresses. Revisions to the initial estimates generally result in trade-offs between the triple constraints: Costs, Scope and Time (Scwalbe, 2006). Metrics on software projects are a necessity to improve estimation (Nelson, 2005). One real possibility of arriving at metrics is to measure productivity for the various tasks engaged in on a project. Productivity is defined by economists Turban et al. (2004), as outputs divided by inputs. In SD terms, outputs can be measured simply as useable lines of code, and inputs can be measured as the amount of labour. McLeod & Smith (2003) define productivity as value divided by cost. Value is derived from the quantity produced (size and functionality), plus the quality (reusability and defects). Costs include factors such as personnel (time and money), resources (hardware, software) and complexity (environmental constraints and the difficulty of the problem).
Schwalbe (2006) states that productivity varies by a factor of about one to ten across development teams, and varies by an average of 21% between pairs of software developers. Demarco and Lister (1999) demonstrate that the major issues of software development are human, not technical. Demarco & Lister (1999) found no correlation between productivity and programming language, years of experience or salary. It thus seems that years of experience might not be an issue and the students results obtained in this study could be a reliable indicator of their productivity in the project.
METHODS OF ESTIMATION
Examples of the many different approaches to estimate SD projects include the Work Breakdown Structure (WBS), Wideband Delphi Technique, FPA, COCOMO, Source Lines Of Code (SLOC) and UCP (Bocij et al, 2006; Damodaran & Washington, 2002, McLeod and Smith, 2003; Schwalbe, 2006). Traditional methods use Functions and Files, and Concept Diagrams whereas the OO paradigm uses Use Case Points (UCP) that implements Use Cases to assist in the calculation of an estimate.
Function Point Analysis (FPA) is a widely used method based on the physical layout of the system and uses amongst others data inputs and outputs (Probasco, 2002) which is not directly related to the OO paradigm which uses objects and methods. In the Object-Oriented (OO) paradigm Use Case modelling is used extensively in both the analysis and design phases and it therefore makes sense to utilise a method that implements UCP to estimate projects (Damodaran & Washington, 2002).
Function Point Analysis
FPA determines the functional weight of system from a user perspective. It is independent of computer language, development methodology, technology or capability of the project team used to develop the application. Schwalbe (2006) defines Function Points (FP) as a technology independent assessment of functions involved in developing a system. McLeod & Smith (2003) define productivity as Function Points divided by the person months of effort, and state that while FPA was initially used to measure productivity it is now also implemented for sizing and estimating. Bocij et al, (2006) define FPA as a method of estimating the time it will take to build a system, by counting the number of functions and data inputs and outputs and then comparing it to completed projects. Bocij et al, (2006) reflected that FPA was developed before Graphical User Interface (GUI) applications, interactive development environments, etc. which have subsequently improved productivity as a function of data inputs and outputs.
Calculating FPs is difficult as it tends to older technologies like mainframes and it is almost impossible to calculate the FPs until the full requirements definition is complete. It also excludes a clear definition for OO, does not work well for systems with little Input and Output (I-O) and does not provide a measure of business worth (Heller, 1997; Marchewka, 2003; McLeod & Smith, 2003).
Use Case Points
An OO approach is based on the concept that systems should be built from a collection of re-usable parts called objects (Ambler, 2004). Objects have properties that can be set, as well as functions (methods) that define the actions that they can take. OO programs are thus collections and compositions of objects with methods that act and operate on these objects (Elliott, 2004; O,Brien & Marakas, 2006; Post and Anderson, 2003).
O’ Brien and Marakas (2006) are of the opinion that OO languages are the most widely used programming languages today, but Bocij et al. (2006) contradicts this by saying that procedural systems vastly outnumber object systems and the OO ones are often slower and more costly. McLeod & Smith (2003) caution that to reap benefits of OO, a project needs a disciplined, managed development process and methodology as well as skills to manage and use the technology effectively.
UCP is a relatively new approach to project estimation. It utilises Use Cases which form a part of the Unified Modelling Language (UML) and is an effective tool for understanding the requirements of OO systems (Chaffey & Wood, 2005; Bocij et al, 2006). A Use Case represents a sequence of actions between an actor(s) and the system that supports activities of the actor(s) and provides a measurable value to an actor, where an actor can be a person, organisation or an external system that interacts with the system. It represents a generic description of system usage (Bocij et al, 2006; Schwalbe, 2006). A Use Case diagram can consist of more than one Use Case and is one of the standard Unified Modelling Language (UML) artefacts (Ambler, 2004). “Use Case modelling is an accepted and widespread technique to capture the business processes and requirements of a software application” (Clem, 2005, online).
UCP is an estimation measure based on Use Cases that enables the estimation of a software application’s size and effort (Clem, 2005). The equation (UCP = TCP * ECF * UUCP * PF) to calculate UCP comprises four variables, Technical Complexity Factor (TCF), Environment Complexity Factor (ECF), Unadjusted Use Case Point (UUCP) and a Productivity Factor (PF) (Clem, 2005; Damodaran & Washington, 2002; Dennis et al, 2005; Koirala, 2004; Nageswaran, 2001; Ribu, 2001)
Several references provide the necessary steps to calculate the estimate. The UUCP consists of the sum of two separate computations, namely the Unadjusted Use Case Weight (UUCW) and the Unadjusted Actor Weight (UAW). To perform these computations each case in all the Use Case Diagrams need to be expanded and categorised as simple, average or complex for both actors and use cases (Clem. 2005; Dennis et al, 2005; Koirala, 2004; Ribu, 2001).
For TCP thirteen sub-factors exist, each of which needs to be weighted between 0 and 5 and multiplied by a perceived complexity between 0 and 5. The total thus obtained is multiplied by 0.01 and added to 0.6 to give the TCF value (Clem, 2005; Ribu, 2001). Eight sub-factors exist for ECF, these are again weighted and multiplied by a perceived impact in a similar fashion to the TCF sub-factors. The total thus obtained is multiplied by -0.03 and added to 1.4 to give you the ECF value (Clem, 2005; Ribu, 2001). No clear and complete guidelines exist as to how the weighting, complexity, or perceived impact for each one of the sub-factors for ECF and TCF is obtained. The authors adopted the weightings as per Ribu (2001), and completed the criteria for the weighting complexity and perceived impact of the sub-factors for both ECF and TCF. The weightings for both TCF and ECF require explanation.
Clem (2005) describes the Productivity Factor (PF) as “a ratio of the number of people hours per use case point based on past projects”. In situations where no historical UCP data exists Clem (2005) suggested a value between 15 and 30, typically 20, whereas Ribu (2001) based it on an environmental sub-factor count to arrive at a PF factor of either 20 or 28.
IMPLEMENTATION
To both teach and validate the use and implementation of UCP, the Systems Development Group Project of Information Systems majors at UCT was used to both teach and validate the use and implementation of UCP. The population consisted of 25 project teams who implemented the method for the first time in each one of their respective projects.
Systems Development Group Project
The Systems Development Group Project (Project) forms an integral part of the capstone course for the Information Systems majors at the University of Cape Town (UCT) (Scott, 2004). It involves building a comprehensive web-based management system according to detailed specifications and an OO approach is followed throughout the lifecycle of the Project. Different themes for projects are chosen annually. The theme in 2005 was an inventory management system that could be implemented in an organisation to label, track, maintain, and control their inventory while increasing productivity and reducing errors. Students work in teams of 5 and are required to find their own sponsor in industry. A sponsor would normally be a business representative with a problem that matches the generic specifications of the project and is prepared to meet with the team on a regular basis to provide guidance and an understanding of the business rules. Every year the Project is introduced in mid February and terminates in September with a project and code presentation. An Expo is hosted in October to showcase the products to the wider public, schools and specific representatives from industry. The Project provides students with a unique real world opportunity that necessitates them to interact with users in organisations, acquire business skills, work in teams, and apply analytical and critical thinking skills to solve a business problem effectively (Scott, 2004).
Formal lectures, lab sessions and workshops are conducted throughout the first half of the course to empower students with hard and soft skills and to provide them with the fundamental project management theories. In the second half of the course teams dedicate their time to build their systems in Visual Basic.Net, ASP.Net and use Microsoft Access or SQL as a database server. Several well-defined interim and milestone deliverables exist and a rigorous assessment strategy is implemented to assist the teams to manage the scope, time and quality of the project. The milestones include extensive documentation, like a Business Case, User Requirement Specification, Systems Specification Document, Test Cases, a User Manual and the software application (Scott, 2004). Staff members in the department act as Project Managers for the individual teams and in addition to this Microsoft Project Server and Microsoft Project are used as tools to store and manage project and resource information. For each one of the respective teams the two sponsor evaluations, at the end of the design phase and at the end of the project, provide valuable feedback on their individual progress and conduct.
Not only are the students highly motivated and passionate about the products they deliver, but the exposure to a real world problem is an experience that assists to develop them into marketable IT/IS professionals (Scott, 2004).
Method of Implementation
In support of the OO approach, used throughout the course, a decision was made at the beginning of 2005 to introduce UCP instead of FPA as a more suitable method of estimation. As part of the learning experience two theory lectures and a supplementary example were used to introduce UCP to the students. To enhance this learning experience and assist students to understand the practical application of the theory taught in lectures a followed-up two hour supervised workshop was conducted. Students worked in teams of 5 to simulate the project environment and the workshop also served as a warm-up exercise for the deliverables of the group project.
For the purpose of the workshop a case study of a hospital system implemented for a particular teaching hospital was used. To encourage effective time management the workshop was divided into separate tasks, each with a time restriction. The first 20 minute task was to draw a Use Case Diagram to identify external actors and functions for the hospital system. Each Case in the Use Case Diagram was then extended for task 2, detailing typical courses of action and alternative courses of action. Task 3 required teams to calculate the Unadjusted Actor Weighting (UAW). For this the students had to determine the number and type of actors from the UC diagram, where the three Actor Types were defined as:
• Simple – Actors who interact with the system through a well-defined Application Program Interface, • Average – Actors who interact with the system using a protocol-based interface, eg. HTTP, TCP/IP,
or a database, and
• Complex – Human Actors interacting through a Graphical User Interface or a Web page.
Task 4 required teams to calculate the Unadjusted Use Case Weight Total (UUCW). For this task they used the extended Use Cases to count the number of events (steps) in each Use Case in order to determine the complexity of the Use Cases. The Unadjusted Use Case Points (UUCP) was then calculated in task 5 by adding the UAW to the UUCW obtained in the previous two tasks.
Task 6 required students to assign a complexity number (between 0-5) to each of the 13 Technical sub-factors and to support their decision with reasons. Weightings were adopted from Ribu (2001). Due to a discrepancy found in the weightings given by Ribu (2001), the weighting that occurred in the majority of the tables was chosen. For example, T2 had a weighting of 2 in one table, but a weighting of 1 in four tables and hence a weighting of 1 was chosen. The sub-factors were carefully selected to reflect the type and complexity of system the students were required to build in their projects. A range of complexity factors with descriptions was provided for each of the sub-factors. For example, for T1. Distributed System – does the system have distributed or centralized architecture, the following possible options were given:
• 0 no transfer of data
• 1 prepares data for another component • 2 data prepared & then transferred • 3 if single direction online data transfer • 4 if online data transfer in both directions • 5 if dynamic processing
The remainder of the sub-factors (T2-T13) with complexity factors used, are given in Appendix A. Table 1 Formulas used in the intermediate and final steps of the UCP estimate
Step Formula/Algorithm
Technical Complexity Factor (TCF) TCF = 0.6 + (0.01 x TFactor(Task 7)) Environmental Complexity Factor (ECF) ECF = 1.4 + (-0.03 X EFactor(Task 9)) Unadjusted Use Case Points (UUCP) UUCP = UAW (Task 3)+ UUCW (Task 4)
Productivity Factor (PF) If sum of (Number of Efactors E1 through E6 Assigned value < 3) and (Number of EFactors E7 and E8 Assigned Value > 3) <= 2 PF = 20
Else
If sum of (Number of Efactors E1 through E6 Assigned value < 3) and (Number of EFactors E7 and E8 Assigned Value > 3) = 3 or 4 PF = 28
Else Rethink Project; it has too high risk of failure Adjusted Use Case Points (UCP) UCP = UUCP x TCF x ECF
Person Hours Person Hours = UCP x PF
From the weightings obtained for the sub-factors, the Technical Factor Value (TFactor) could be calculated in task 7 by multiplying the weighting by the assigned value for each factor and then by finding the sum of the calculated values. This sum was used to obtain the Technical Complexity Factor (TCF), see Table 1. Task 8 required students to assign a perceived impact (between 0-5) to each of the 8 Environmental Sub-factors with reasons. Weightings were again taken from Ribu (2001), and again the same policy as above was applied to out rule the discrepancies. A range of perceived impacts with descriptions was provided for each of the sub-factors as given in Appendix B. Task 9 involved calculating the Environmental Factor Value (EFactor) by multiplying the weighting by the assigned value for each factor and then by finding the sum of the calculated values. The EFactor was used to calculate the Environmental Complexity Factor (ECF) and Ribu’s (2001) formula was used then used in task 10 to determine a value of either 20 or 28 for the Productivity Factor (PF), see Table 1.
The final task (11) was to determine the Adjusted Use Case Points (AUCP) and Person Hours, see Table 1. Once completed the workshops were collected, marked and returned to the students including rich feedback. The process explained above was used to act as a pilot, guiding the teams in applying the estimation process in their own systems. In those cases where the hours calculated were more than the nominal hours available, teams were advised to reduce the scope, enabling them to keep to the non-negotiable due date of 7 September 2005 for all projects. Once all projects had been completed and written up, data was collected and analysed to give some indication of how successful this approach was implemented as a first time for the course as can be seen in the next section.
ANALYSIS
In previous years all project teams used FPA as an early estimation measure. The implementation of a method, like FPA, that does not align well with the OO paradigm created reasons for concerns. In addition to this, students struggled to understand the relevancy of the steps used by the FPA in terms of the OO approach implemented in their projects.
The data for two teams in the sample of 25 project teams was discarded. The one team implemented FPA in stead of UCP, whilst the calculations of the second team were corrupted. Table 2 displays the project teams (numbers and names), the Person Hours calculated for the respective systems as described in the previous section and the final overall mark each team obtained for project. An assessment strategy with multiple assessment opportunities is implemented in the course to ensure the effective and objective assessment of the projects. The marks obtained for each project are the culmination of a range of measures and evaluations each addressing a particular area throughout the life cycle of the project (Scott & van der Merwe, 2004)
Table 2 Project teams with Person Hours and Final Project Mark Actual Person Hours (122 days; 8 hours/p/d; 5 members) 4880
Team # Team Name Person Hours Project Mark
1 Digital Oasis 7954 91% 4 Smart Solutions 11575 83% 8 Capstone Creations 5349 80% 24 Ladybug 2447 80% 13 Eminence 4183 78% 11 Lucid Dreams 10808 77%
2 Black Sheep Solutions 8691 76%
9 Converge IT Solutions 4386 76% 22 Taurus Consulting 5310 75% 16 The Incredibles 2249 70% 7 Fusion Development 4677 68% 25 TriCommunications 8064 66% 5 Discover IT 4799 65%
6 Byte Size Solutions 2741 58%
15 Out of Box Solutions 3057 58%
3 Matay Solutions 5250 57% 17 Birkies 4505 57% 21 Synergy 2037 57% 18 Epsilon 2419 56% 14 Endeavour Solutions 4093 55% 12 Kaizen Solutions 2827 51% 19 Sops Solutions 2382 50% 10 Logix Solutions 2700 47% Legend PH > 5400 4000<PH<5400
PH 4000
Although the specifications for the project were given to students at the first lecture of the year in mid February, teams had to be formed first and the students were confronted with the task of finding a sponsor in industry. Once these tasks were completed, the project started in all earnest by 13 March 2005, two weeks before the first interim deliverable was due, and terminated on 7 September 2005. This period of time translates to 122 days, excluding Saturdays, Sundays and public holidays. Except for one team, all teams had 5 members.
In real life, if 5 employees should work for a period of 122 days, 8 hours per day the total number of Person Hours would amount to 4880, as shown in the first row of Table 2. Typically the student teams did not allocate all their time to the group project, but they tend to work after hours and over week-ends. From the authors’ experience, students are highly motivated and put in many additional hours to complete the projects within the allocated time.
The Person Hours for 9 teams were close to this value of 4880, varying from 4093 to 5349. Of the 5 teams who exceeded this value, 4 teams obtained overall marks for their projects of 75% or more. This could probably indicate that these teams exerted themselves by putting in much more effort to achieve products of a very high quality and extensive scope, a common trend amongst competitive projects teams and high achievers. Tri-communications (team 25) only had 3 members and was the only team with less than 5 members. The team adapted the scope of their system as a result of the high estimate of 8064 Person Hours and was able to deliver a very good product with a reasonable scope and within the given time, despite their restricted resources. Digital Oasis (Team 1) obtained the highest mark overall for their project. The scope of their system was also reduced after the Analysis Phase and as a result of the estimated Person Hours of 7954 as shown in Table 2. This decision at an early stage of the project life cycle enabled the team to focus more on implementing advanced features, ease of use and enhancing the overall quality of the product. The Person Hour counts of 9 teams were less than 4000. Seven of these teams achieved marks of less than 60% for their projects. Several reasons can be given for the low project marks. Of these, the most important would be a limited scope and inferior quality of the final product. Some of these teams experienced difficulty to resolve conflict and struggled with a lack of resources due to limited programming skills and members who did not contribute equally. Two teams in this group achieved high marks. Both these projects addressed smaller problems and hence the systems were of smaller scope. The quality of deliverables and milestones, the efficient interpretation and capturing of the business problem in code, using sound business rules and processes and the implementation of advanced OO principles however, contributed to their high marks. As a first attempt by the student groups of estimation using UCP, it is noteworthy that the Person Hours for 9 out of the 23 teams fell within a credible range of the actual number of Person Hours available for the given time period.
CONCLUSION
The research project achieved two specific objectives. It assisted to determine an approach that could be implemented to effectively estimate group projects and could be used as an instrument to educate student teams in the utilisation of UCP.
The students were able to motivate and understand the implementation of the new approach as it was better aligned to the OO paradigm used in the group projects and the estimation results were more credible in terms of person hours obtained in the caculations.
The main issue in this study was the selection of an approach to estimate OO projects. The approach selected was UCP as it best suited OO projects. A core issue with the use of this approach was that insufficient detail was provided in the different steps of the method to allow users to make informed decisions. The authors enhanced these areas by adding more detail.
It is recommended that similar research be undertaken in 2006 in both the third and the fourth year courses to study the continuing use of UCP, and to refine the numbers and narration for complexity and perceived impact. Explanations and criteria for weightings of both TCF and ECF factors possibly need to be revisited and more clearly defined or explained. Further research could be done to establish whether the factors differ for projects operating in different industry segments.
REFERENCES
Ambler S.W (2004), The Object Primer, Third edition, Cambridge University Press, UK, ISBN 0-521-54018-6. Bocij P, Chaffey D, Greasley A & Hickie S (2006) Business Information Systems, 3rd Edition, FT Prentice
Hall, Harlow, England, ISBN 0-273-68814-6.
Chaffey D & Wood S (2005), Business Information Management, FT Prentice Hall, Harlow, England, ISBN 0-273-68655-0.
Clem R, (2005), Project Estimation with Use Case Points, Available Online at: http://www.codeproject.com/gen/design/usecasep.asp [2005, March 22].
Coombs P, (2003), IT Project Estimation, Cambridge University Press, Cambridge, ISBN 0-521-53285-X. Damodaran, M & Washington A N E (2002), Estimation Using Use-Case Points. The Proceedings of the
Information Systems Education Conference(ISECON 2002), San Antonio, USA. ISSN: 1542-7382. DeMarco T & Lister T (1999) Peopleware productive projects and teams, Dorset House, New York, ISBN
0-932633-43-9.
Dennis A, Haley Wixom B, Tegarden D (2005), Systems Analysis and design with UML Version 2.0, Wiley & Sons, USA, ISBN 0-471-34806-6.
Elliot E, (2004), Global Business Information Technology, Addison Wesley, Harlow, England, ISBN 0-321-27012-6.
Heller R, (1997), Introduction to Function Point Analysis. Available Online at: http://www.sei.cmu.edu/str/descriptions/fpa_body.html [Last modified 2005, December 14].
Koirala S (2004), How to prepare Quotation using Use Case Points, Available Online at: www.codeproject.com/gen/design/usecasepoints.asp, [2004, December 14].
Marchewka JT (2003), Information Technology Project Management, Wiley & Sons, USA, ISBN 0-471-39203-0.
McLeod G & Smith D, (2003), Managing Information Technology Projects, Inspired Press.
Nageswaran S, (2001), Test Effort Estimation Using Use Case points, Quality Week 2001, San Francisco, California, USA.
Nelson, R. (2005). Project retrospectives: Evaluating Project Success, Failure, and eveything in between. MIS Quarterly Executive, 4(3), 361-372.
O’Brien JA & Marakas GM (2006) Management Information Systems, McGraw-Hill, Boston, ISBN 0-07-111629-X.
Post GV & Anderson DL (2006), Management Information Systems, McGraw-Hill, Boston, ISBN 0-07-111638-9.
Probasco L, (2002), Dear Dr. Use Case: What About Function Points and Use Cases?, Available Online at: http://www-128.ibm.com/developerworks/rational/library/2870.html, [2002,Aug 15].
Ribu K, (2001), Estimating Object-Oriented Software Projects with Use Cases, Masters thesis, University of Oslo, Norway.
Schwalbe K, (2004), Information Technology Project Management, Third Edition, Thomson, Canada, ISBN 0-619-15984-7.
Scott, E.C. (2004), Systems development group project: A real world experience, Proceedings of the Information Systems Education Conference (ISECON 2004), Newport, Rhode Island, USA.
Scott, E. C., Van der Merwe, N., (2003). Using Multiple Approaches to Assess Student Group Projects, The Electronic Journal of Information Systems Evaluation (EJISE), December 2003, Volume 6, Issue 2, pp 177-186.
Turban E, McLean E, Wetherbe J, (2004), Information Technology for Management, 4th Edition, John Wiley & Sons, USA.
APPENDIX A
13 Technical Sub-factors
T1. Distributed System – does system have distributed or centralized architecture, the following possible numbers were given:
0 no transfer of data
1 prepares data for another component 3 data prepared & then transferred 3 if single direction online data transfer 4 if online data transfer in both directions 5 if dynamic processing
T2. Response time or throughput 0 no requirements
1 no special attention to response times or throughput 2 if response time & throughput critical at peak times
3 if response time & throughput critical during business hours
4 if user performance requirements stringent & require performance analysis in design phase 5 if performance analysis tools needed in design, development & implementation phases
T3. End-user online efficiency– functions provided by app. May include menus, nav aids, help, scrolling, F keys, reverse video, highlighting, pop ups, as few screens as possible, multilingual support etc
0 if none 1 if 1-3 2 if 4-5
3 if 6 or more with no specific user requirements
4 if 6 or more with stated specific user requirements demanding human factors to be included
5 if 6 or more with stated specific user requirements demanding specific tools & processes be used to demonstrate requirements achieved
T4. Complex internal processing – includes sensitive control &/or app specific security processing, extensive logical processing, extensive mathematical processing, exception processing, multiple I/O possibilities
0 if none 1 if any 1 2 if any 2
3, 4, 5 if any 3, 4, 5
T5. Reusability of code – degree to which app will be useable in other apps 0 if no reusable code
1 if reusable code is used within app
2 if less than 10% of app considers more than 1 apps needs 3 if 10% or more of app considered more than 1 apps needs
4 if app developed specially to ease reuse. Customizable at source level
5 if app designed specially to ease reuse. Customizable at source level by parameter T6. Easy to Install – ease of conversion & installation
0 if no special considerations stated by user. No special setup required. 1 if no special considerations stated by user. Special setup required.
2 conversion & installation requirements stated by user. Impact not considered important. 3 conversion & installation requirements stated by user. Impact considered important. 4 in addition to 2, automated conversion & installation tools provided & tested
5 in addition to 3, automated conversion & installation tools provided & tested T7. Ease of use – efficiency & effectiveness of start-up, backup, & recovery
0 no special considerations stated other than normal backups 1-4 select from list, each item counts as 1 unless noted otherwise
• Effective start-up, backup & recovery processes provided, but operator intervention required • Effective start-up, backup & recovery processes provided, but no operator intervention required (2) • Application minimizes need for media handling
• Application minimizes need for paper handling
5 App is designed for unattended operation. Automatic error recovery.
T8. Portability - degree to which app designed to be installed & operated at multiple sites 0 only 1 site
1 app designed to operate only under identical hw & sw environs 2 app designed to operate only under similar hw & sw environs 3 app designed to operate only under different hw & sw environs 4 documentation & support plan provided & tested for 1 or 2 5 documentation & support plan provided & tested for 3
T9. Ease of change – degree app was developed to facilitate change. Select items from list, each item counts as indicated:
• Flexible query/report facility to handle simple requests (1)
• Flexible query/report facility to handle complex requests (>1 file)(2) • Flexible query/report facility to handle v.complex requests (>1 file)(3)
• Control data kept in tables & maintained online. Changes take effect next day (1). • If changes take effect immediately (real-time) counts as 2.
T10. Concurrency – large numbers of users working with locking support? 0 only 1 user at a time
1 app designed to operate with less than 5 users concurrently 2 app designed to operate with less than 50 users concurrently 3 app designed to operate with less than 100 users concurrently 4 app designed to operate with less than 1000 users concurrently 5 app designed to operate with over a 1000 users concurrently T11. Special security objectives included
0 if no special considerations stated by user. No special security required. 1 if no special considerations stated by user. Special security required. 2 security requirements stated by user. Impact not considered important. 3 security requirements stated by user. Impact considered important. 4 in addition to 2, automated security tools provided & tested
5 in addition to 3, automated security tools provided & tested T12. Direct access for third parties
0 if pure batch or stand-alone PC
1 if batch with remote data entry or printing 2 if batch with remote data entry & remote printing 3 if TP front-end links to batch
4 if more than a front-end with one type of TP 5 if more than 1 type of TP protocol
T13. Special User training required 0 no user training required
1 one day course required for general users 2 two day course required for general users 3 one week course required for general users 4 two week course required for general users 5 extensive courses required for general users
APPENDIX B
8 Environmental Sub-factors
E1 Familiarity with system – are people working on project familiar with OO domain and technical details of project?
0 if first time using OO
1 if team has worked on 1 OO project before 2 if team has worked on 2 OO projects before 3 if team has worked on >3 OO projects before 4 if team has worked on >10 OO projects before 5 if team has worked on >20 OO projects before
E2. Application experience – what experience do people have with the application? 0 if first time using working on this type of application
1 if team has worked on one standalone app before 2 if team has worked on several standalone apps before 3 if team has worked on several client/server apps before 4 if team has worked on an enterprise app before
5 if team has worked on several enterprise apps before E3. Object-oriented experience – knowledge of OOP concepts
0 if team never used OO before
1 if team has 1 years OO working experience 2 if team has 2 years OO working experience
3 if team has >2 years OO working experience, including advanced OO concepts 4 if team has worked on full 3 tier web based apps with advanced OO concepts 5 if team has worked on advanced integrated apps with other OO packages E4. Lead analyst capability – knowledge of the domain
0 if lead analyst has never used OO before 1 if lead analyst has worked with OO programs
2 if lead analyst has OO experience and a knowledge of UML modelling
3 if lead analyst has OO experience and a sound knowledge of UML, Agile modelling etc 4 if lead analyst has experience with full 3 tier web based apps
5 if lead analyst has experience with large integrated enterprise applications E5. Motivation – team motivation
0 if high absenteeism (more than 1 day per person per month) 1 if moderate absenteeism (members miss meetings)
2 if members arrive late for meetings, have to be pushed to start work
3 if members mostly on time, usually start work on own, sometimes look for extra work 4 if members always on time, self start work, always looking for extra work, commitment
5 if team absenteeism is low, try to accomplish meaningful goals, always trying to improve,
always
trying to help each other, can work independently, show commitment
E6. Requirements stability – is scope clear and well defined 0 Scope not well defined
1 URS, WBS & PBM unclear and lacking detail 2 URS, WBS & PBM clear and well defined
3 URS, WBS & PBM clear and well defined, project justified
4 URS, WBS & PBM clear and well defined, project justified, and success criteria detailed
5 All the requirements (URS), all the work (WBS) and all the products (PBM) of the project clearly defined, project justified, and success criteria detailed, and project charter signed.
E7. Part time staff – are there part-time staff (consultants) on the project 0 zero part time staff or consultants
1 part time staff or consultants will do <5% of work 2 part time staff or consultants will do <10% of work 3 part time staff or consultants will do <20% of work 4 part time staff or consultants will do <50% of work 5 part time staff or consultants will do >50% of work E8. Difficulty of programming language
0 if using non structured programming languages eg HTML 1 if using structured programming language eg Pascal 2 if using OO programming language eg C
3 if using OO programming language with full OO capability and advanced features eg C++ 4 if using event driven OO programming language with full OO capability eg Java
