Research Article Volume 6 Issue No. 7

Transcription

1 DOI / ISSN IJESC Research Article Volume 6 Issue No. 7 A Tool to Evaluate the Performance of UCP Shaweta Mehta 1, Shailja Kumari 2 Assistant Professor 2 Department of Computer Science and Applications CDLU, Sirsa, India shwetamehta899@gmail.com 1 Abstract: Software effort estimation is an important part of software development work and provides essential input to project feasibility analyses, bidding, budgeting and planning. A no. of techniques is used for estimation of effort amongst which widely used are COCOMO 1 and COCOMO 2 that estimates the cost in terms of efforts. But effort is linearly or non-linearly dependent upon the size of the developing software. For size estimation, Lines of Code (LOC) counts technique showed its comforts as developer do not have to solve any mathematical equations, just count the no. of lines of the developed software. Then came Functions Point (FP) technique, this technique proved its goodness in almost every aspect where LOC lacks. Developers estimate Lines of code early before the software is finally built. FP had been used for a long time being for estimation of size, which is the main input for COCOMO1 and COCOMOII. But as the time changes, needs and their solutions also changes. Today, software are based on object oriented paradigm and OOP languages. Developers use Unified Modeling Language (UML) notations and diagrams for estimation of each aspect of software development. So the main factor is to use such a technique that supports the OOPs for estimation purposes. Hence, this paper presents a technique that supports OOPs for estimation purposes by implementing USE CASE POINT ESTIMATION TECHNIQUE (UCP) which overcomes the drawbacks of FP which is procedural oriented (POP).Further evaluation of the performance of UCP in comparative to COCOMO 1 and COCOMOII is taken. This all will be performed with the help of a self implemented tool having all the functionalities at one location. Keywords: Use Case Point (UCP), FP, COCOMO, LOC, SDLC INTRODUCTION Proper software effort estimation is foremost activity adopted in every software development life cycle. Several features offered by OO programming concept such as Encapsulation, Inheritance, Polymorphism, Abstraction, Cohesion and Coupling play an important role to manage the development process. Currently used software development effort estimation models such as, COCOMO and Function Point analysis, do not provide accurate project cost and effort estimation. These techniques have been proven unsatisfactory for estimating cost and effort because the LOC and FP are both used for procedural oriented paradigm. The LOC is dependent on the programming language and FP based on human decisions. The use case model is used to predict the size of the future software system at an early development stage. This dissertation work describes the various estimation methods combined into a single tool. Tools consists estimation models of main input parameter size. These are Source Lines of Code (SLOC) and Function Point (FP).This Size Input is incorporated into cost estimation models like COCOMO I and COCOMO II from where we estimate other factors like Effort, duration, Cost etc. But the main aim of this tool is to provide better estimates of size for this time trend languages which are based on Object Oriented Paradigm. To better describe the functional requirements of OOP paradigm that are based on use case modeling, Use case point estimation technique is used. We will now briefly explain the steps in the use case point s method as used by Karen (Karen 93.) First, categorize the actors in the use case model as simple, average or complex and calculate the total unadjusted actor weight (UAW) by counting the number of actors in each category, multiplying each total by its specified weighting factor, and then adding the points. Next, categorize the use cases as simple, average or complex, depending on the number of transactions, including the transactions in alternative flows. Then the unadjusted use case weights (UUCW) are calculated by counting the number of use cases in each category, multiplying each category of use case with its weight and adding the products. The UAW is added to the UUCW to get the unadjusted use case points (UUCP) [2]. Next, the use case points are adjusted based on the values assigned to a number of technical factors and environmental factors. Each factor is assigned a value between 0 and 5 depending on its assumed influence on the overall project. UML and UCP Object oriented development is the combination of object oriented analysis, object oriented design, and object oriented programming. In object oriented analysis we are preparing the model which helps us in requirements gathering. In object oriented design can be done by using the UML. In object oriented programming project construction can be done. The Unified Modeling Language (called UML) was developed to provide a common language for object oriented modeling. It was designed to be extensible in order to satisfy a wide variety of needs and was also intended to be independent of particular. UML notations and diagrams are as follow: 1) Use Case Diagram 2) Class Diagram. 3) Sequence Diagram International Journal of Engineering Science and Computing, July

2 4) Interaction Diagram 5) Collaboration Diagram 6) State chart Diagram 7) Activity Diagram Every diagram and notations used in diagrams have its own significance and importance. The main concern is on Use case diagram as these are used by the developers for requirement gathering at early stages. Nowadays, use cases utilization has been extended due to its inclusion in UML, so that its usage in Object-Oriented Software development has turned into a must. USE CASE DIAGRAM: In order to develop a method to measure effort other than that which uses function points, are due to the fact that UML is widely used and that the object oriented paradigm is extensively accepted the selected option of using use cases. They have the advantage that many people are using them, and the use case textual description is written earlier within the life cycle of a system. As it was necessary to estimate the weight of each use case in the total size calculation, transactions and entity objects were used as size notions of the use cases. To point out the advantage of utilizing the use case model instead of another alternative model as a resource for size calculation, Fig. shows, in a temporal sequence, the different artifacts that are commonly developed. The first artifact in the figure is the Client Requirements Definition. Based on this, a List of Use Cases -which defines the scope of the application, may be written. Then a textual description of each use case may be made. With this information the Analyst may define the Graphic User Interface, the Inputs and Outputs of the system. Finally the Entity and Relational Model may be drawn Client Requiremen t Definition List of Use Cases Textual description of each Use Cases Graphic User Interface Inputs Outputs Entity- Relation- -ship Model Figure 1: Temporal sequence of the different artifacts that are commonly developed Use case diagrams depict: Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. For e.g., actor named employee For e.g., employee detailed named imp detail use case is shown in diagram. Figure 3: Use Cases representation in use case diagram. Figure 2: Actor representation in use case diagram. Use cases. A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse. Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case. The International Journal of Engineering Science and Computing, July

3 arrowheads are typically confused with data flow and as a result I avoid their use. Figure 3: Association representation in use case diagram USE CASE POINT ESTIMATION TECHNIQUE This technique was proposed by Gustav Karner in 1993 to estimate the projects based on OO. Some little changes were being made in the technique, but the main concept is used as it is in afterward extensions. Use case point estimation is calculated from use case model. The main aspects of use case point estimate technique are actors, use cases, associations between actors and use cases, relationships between actors, relationships between use cases. UCP is measured by counting the number of actors and transactions included in the flow of events with some weight. A transaction is an event that occurs between an actor and the target system, the event being performed entirely or not at all. The UCP counting process consists of the following steps: Step 1 - Unadjusted Actors Weights (UAW) Categorization of actors in the model is as it can be a simple, average or a complex actor depending on the way of its interaction with the system. Each actor possesses some weight and lastly their no. multiplied sum is termed as Unadjusted Actors Weight. A Simple actor can be represented by another system with some defined interfaces or it can be another system interacting through API (Application Programming Interface). It possesses weight 1. This can be calculated by using the following formula: SActor = Σ (SimpleActor) * SimpleWeight Where SActor stands for Simple Actor The Average actor can be represented by a system interacting through protocols such as TCP/IP or it is a person interacting through a text-based interface (such as an old ASCII terminal). It possesses weight 2, and can be obtained from the following formula AActor = Σ (AverageActor) * AverageWeight Where AActor stands for Average Actor 1. Unadjusted Actors Weights (UAW) 2. Unadjusted Use Case Weights (UUCW) 3. Unadjusted Use Case Points (UUCP) 4. Technical Complexity Factor (TCF) 5. Environmental Factor (EF) 6. Adjusted Use Case Points (AUCP) 7. Staff hours per Use Case Point. The Complex actor can be represented by a person that interacts through graphical interfaces or Internet. It possesses weight 3. The following formula gives that number. CActor = Σ (ComplexActor) * ComplexWeight After one get done all calculations previous presented, the UAW can be obtained by: UAW = SActor + AActor + CActor Type Description Weight Factor Simple Program Interface 1 Average Interactive, protocol driven 2 Interface Complex Graphical User Interface 3 Table 1: Classification of actors Step 2 - Unadjusted Use Case Weights (UUCW) The same process used for actors, should be repeated with the use cases. That process should rate use cases among Simple, Average and Complex. If the use case possesses up to 3 transactions, it should be considered as a simple use case (SUsecase), therefore weight is equal to 5. That can be calculated by: SUsecase = Σ (SimpleUC) * SimpleWeight International Journal of Engineering Science and Computing, July

4 On the other hand, if the use case possesses from 4 to 7 transactions, it should be considered as an average use case (AUsecase), therefore weight is equal to 10. That can be calculated by: (CUsecase), therefore weight equals 15. That can be calculated by: CUsecase = Σ (ComplexUC) * ComplexWeight AUsecase = Σ (AverageUC) * AverageWeight After get done all calculations previously presented, the UUCW can be obtained from: Concluding, if the use case possesses more than 7 transactions, it should be considered as a complex one UUCW = SUsecase + AUsecase + CUsecase Type Description Weight factor Simple Less than 3 transactions 5 Average 4 to 7 transactions 10 Complex More than 7 transactions 15 Table 4.2: Transaction-Based Weighting Factor Step 3 - Unadjusted Use Case Points - UUCP Unadjusted Use Case Points (UUCP) is simply the sum of UAW and UUCW. This can be expressed by: UUCP = UAW + UUCW Step 4- Technical Complexity Factor (TCF) Next, the use case points are adjusted based on the values assigned to a number of technical factors and environmental factors. Each factor is assigned a value between 0 and 5 depending on its assumed influence on the overall project. Factor no. Description Weight T1 Distributed system 2 T2 Response or Throughput 1 performance objective T3 End-user efficiency 1 T4 Complex Internal processing 1 T5 Code must be reusable 1 T6 Easy to Install 0.5 T7 Easy to use 0.5 T8 Portable 2 T9 Easy to change 1 T10 Concurrent 1 T11 Includes Special Security Features 1 T12 Provides Direct Access for Third 1 Parties T13 Special user Training facilities are 1 Required Table 4.3: Technical Complexity Factor weighting for UCP International Journal of Engineering Science and Computing, July

5 The Technical Complexity Factor (TCF): TCF = (.01 * Tfactor) Where Tfactor is the sum of multiplication of weight with the no. of factors Step 5: Environmental Factor: The level of the environmental complexity is directly related to professionals' experience involved in the project. The environmental factors vary in a scale from 0 to 5, indicating little and large experience. EF is calculated considering Table Factor Description Weight F1 Familiar with Process 1.5 F2 Application experience 0.5 F3 Object oriented experience 1.0 F4 Analyst capability 0.5 F5 Motivation 1.0 F6 Stable requirements 2.0 F7 Part time workers -1.0 F8 Difficult programming language -1.0 Table 4.4: Environmental Complexity Factors The Environmental Factor (EF): EF = (-0.03 * Efactor) Where Efactor is the sum of multiplication of weight with the no. of factors Step 6 - Adjusted Use Case Points (AUCP) The Adjusted Use Case Points (AUCP) is calculated considering UUCP, TCF, and EF from the following formula: AUCP = UUCP * TCF * EF Finally, the UCP is multiplied by a historically collected figure representing productivity, such as a factor of 20-staff hrs per use case point, to arrive at a project estimate. The result is an estimate of the total number of person hours required to complete the project. Step 7 - Staff Hours per Use Case Point The spent time for programming per person needed to accomplish each one of AUCP should be calculated. Karner proposed the use of 20person-hour for each AUCP unit. Duration = AUCP* PF person hours Where Productivity Factor (PF) = 20. Effort =Duration/152 person-months Cost = (labor rate)* effort. Advantages: 1) Current trend issues for software requirement gathering are through modeling the use case diagrams. International Journal of Engineering Science and Computing, July

6 2) Use case textual description is written earlier within the life cycle of a system. 3) Use case notations and diagrams are easy to understand and to interpret. 4) Several environmental factors along with technical factor are present on the behalf of which estimates are assumed to be more accurate. 5) Object-oriented paradigm and visual programming form the basis for use of UCP technique. 6) Weighting factors are not much complicated. OBJECTIVE Presently we are working in object oriented paradigm where a life seems to be automated, although manual workings are present but reduces to a very low level. Now various researches have been performed in this context. Our main objectives are: 1) Since the object-oriented approach has become a de facto standard for software development, it became necessary to revise the effort and cost estimation models to suit the object-oriented technology. 2) To reduce the efforts associated with software development. 3) To reduce the cost associated with estimation of software resources. 4) To use simple diagrams and notations of UML to make the estimation process simple such that even a novice developer can perform estimation accurate and reliable. 5) To make the estimation process easy while working with current trend and issues of Object oriented paradigm.. REFERENCES 4) Rajiv aggarwal book. K k aggarwal. 5) Bharat Bhushan Aggarwal 6) Hareton Leung Zhang Fan, Software cost estimation, Department of Computing, The Hong Kong Polytechnic University, pg no ) B.W. Boehm et al "The COCOMO 2.0 Software Cost Estimation Model", American Programmer, pp.2-17, July ) Barry Boehm, Bradford Clark, Ellis Horowitz, Chris Westland, Cost Models for Future Software Life Cycle Processes: COCOMO 2.0* Science Publishers, ) Costar tool table. 10) COCOMO MODEL 11) Parastoo Mohagheghi, Bente Anda, Reidar Conradi Effort Estimation of Use Cases for Incremental Large-Scale Software Development, ICSE, pg no , ) Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., Selby, R. Cost models for future software life cycle processes: COCOMO 2.0. USC center for software engineering, x.html 13) D.St-Pierre, M Maya, A. Abran, J. Desharnais and P. Bourque, Full Function Points: Counting Practice Manual, Technical Report , University of Quebec at Montreal, ) Takuya uemura, Shinji kusumoto, and Katsuro inoue, Function Point Measurement Tool for UML Design Specification 15) UML 2.0 Reference Manual, Object Management Group, ) Mr.K.Koteswara Rao Mr.Srinivasan Nagaraj Mr. Jitender Ahuja Measuring the function points from the Points of Relationships of UML, 2008 IEEE, pg no ) Mel Damodaran, Estimations using Use Case Points 2) Encyclopedia of Software engineering, volume 2, second edition 3) Nancy Merlo Schett, Seminar on Software Cost Estimation, Computer Science, 2002 International Journal of Engineering Science and Computing, July