Figure 1 - uploaded by Luigi Lavazza
Content may be subject to copyright.
Source publication
Functional Size Measures are often used for effort estimation. However, these measures do not take into account the amount and complexity of elaboration required, concentrating instead on the amount of data accessed or moved. Methods for measuring the functional complexity have been proposed, but, being based on the textual description of requireme...
Context in source publication
Context 1
... consider a simplified version of a library management system. Because of space limits, only two use cases are illustrated: the login process and the process of borrowing a book (see Figure 1). Figure 2 describes the system, highlighting the interfaces that make external interactions possible, and the logical data managed within and outside the system. ...
Similar publications
Today's manufacturing companies have strived to develop a large variety of customer-specified products in an effort to survive and stay competitive. Process platforms have been well recognized as a means for companies to obtain a stable production and thus the economy of scale. A process platform assists companies in configuring similar production...
A consistency check between design and implementation is usually done in order to check the correctness of the system' requirements. However, if the requirements are changed over time, then the document versioning occurred within the requirements. For XML Schema, document versioning exists when there is a change in the XML Schema from its previous...
Citations
... Problem diagrams are deployed to represent Problem Frames models in specialised notations, ang these COSMIC ideas are applied to problem frame elements, then the technique is demarcated to spread over COSMIC-compliant measurement rules to requirements models as per the problem frames. Furthermore, Lavazza & Robiolo, 2010 also try to estimate the amount of complexity using measurement-oriented UML modeling to support the functional size and functional complexity. A case study has been proposed to evaluate different functional sizes and complexity measures from UML. ...
In the contemporary age of cyber-physical systems (CPS), where software governs the control, coordination, and management of physical objects to tackle real-world problems, engineering requirements for such systems present considerable challenges. Consequently, it is not surprising that the requirements engineering (RE) community, encompassing both academia and industry, has turned to established RE methodologies and applied them within the context of CPS; notably, Jackson’s Problem Frames (PF) approach deploys problem diagrams for modeling CPS. However, problem diagrams of realistic CPS often present visual and conceptual complexities, which must be addressed before PF can be usefully applied in practice. In this paper, the above problem is addressed in two steps: firstly, preliminary findings are presented by deriving from the application of eye-tracking software in the assessment of a technique designed to mitigate the visual complexity inherent in the CARE (Computer-Aided Requirements Engineering) tool developed for PF. An auto-layout technique is developed for detecting and resolving overlaps, aimed at enhancing its usability from the perspectives of cognition, psychology, and user studies; secondly, the technique of a complexity matrix is applied for calculating and evaluating the conceptual complexity inherent in problem diagrams. Our eye-tracking results show the successful implementation of overlap detection and resolution. The case studies in the second step also demonstrate the applicability and effectiveness of the complexity matrix calculations.
... The latest work, done by De Vito et al. [12], consists of a generic automated estimation tool that is claimed to work accurately for any domain. More UML-related approaches are found in [13][14][15]. ...
The COSMIC functional size measurement (FSM) method can be applied in different phases of software projects: early in the design phase or after the implementation has been delivered. Different software artifacts can be used to produce the COSMIC functional size of a piece of software: specification requirements, implemented code, etc. COSMIC has been used in different domains (e.g. Management Information Systems (MIS), Real-time Embedded Systems-RTES, etc.), and has been applied to different conceptual frameworks and programming paradigms. Assembly language is the lowest-level programming language designed for a specific type of processor executing machine code. Assembly can be compiled or interpreted from different high-level languages. ARM processors account for 90% of those used in the mobile industry and controllers of IoT devices. In addition, 75% of the processors used in invehicle infotainment Advanced Driver-Assistance Systems (ADAS) are made by ARM. As a whole, they address 33% of the total addressable market. In this paper, we propose an FSM procedure based on COSMIC ISO 19761 to measure software artifacts expressed in ARM’s base 32-bit Assembly code. An FSM automation prototype tool is also introduced.
... Anda et al [1] estimated the software effort based on use case components and compute the total time in hours. Lavazza and Robiolo [2] showed the measurement-oriented UML modeling can support the computing effort based on functional size and complexity as independent variables. Sridhar [3] proposed knowledge based effort estimation for multimedia projects and concluded that the accuracy of effort estimation can be improved using knowledge rules. ...
The use case and class diagrams are important models of the system created during early phases of the software development. Effort and size estimation are also important points of the software development. Many effort estimation models proposed in the last years and many factors have an impact on software efforts like complexity, use case points and class points. Effort/size estimation is calculated using the proposed model online shopping system as a case study. The results indicate that the proposed model can help to estimate project size earlier in the design phase, to predict effort needed to complete development. The percentage of estimated effort between two diagrams is 85.49 is obtained .
... Lavazza and Robiolo used measures from UML sequence diagrams in conjunction with functional size measures for effort estimation [27]. Sellami et al. further developed this idea: they used measures from UML models to complement COS-MIC size measures, to derive more accurate effort estimation model [36]. ...
Background. Functional size measurement methods aim at measuring the size of functional user requirements of software applications. Functional user requirements can be represented via different notations, including UML diagrams. Objectives. In this paper, the relationship between functional size measures (namely IFPUG Function Points and COSMIC Function Points) and object-oriented measures of UML diagrams representing functional requirements are investigated. Method. A set of functional requirement specifications was modeled via UML diagrams. The functional size measures of user requirements were derived via the standard IFPUG and COSMIC processes; the corresponding UML models were measured using a set of object-oriented metrics that are applicable to UML models representing requirements. Functional size measures were then compared to object-oriented measures. Results. Statistically significant linear regression models were found. It was also found that object-oriented measures of UML requirements models can be used to estimate functional size measures with good accuracy. Conclusions. The obtained results suggest that object-oriented measures –which tools can automatically extract from UML models– provide indications concerning requirements size that are substantially equivalent to those provided by functional size measures.
... -Functional size of software is the main factor influencing understandability. It refers to the number and complexity of use cases that the software system satisfies, and not the implementation size (Albrecht 1979;Lavazza and Robiolo 2010;(OMG) 2014). Unless we are interested in the relation between functional size and the understandability of software, comparing the understandability of software applications of various sizes is problematic. ...
Executable software models formalize functional software requirements. This means that the understandability of software models is of paramount importance. In this paper, we investigate the influence of cyclomatic complexity on the understandability of executable translatable unified modeling language (xtUML) models. We adapt traditional cyclomatic complexity metrics to different xtUML sub-models and present two different ways of measuring complexity distribution: horizontal, among elements of the same type, and vertical, among elements of different types. In order to test our hypothesis that cyclomatic complexity distribution influences the understandability of xtUML models, we have performed an experiment with student participants in which we have evaluated the understandability of three semantically equivalent xtUML models with different complexity distributions. Results indicate that a better distribution of cyclomatic complexity has a positive influence on model understandability.
... Internal attribute can be measured in term of process, product or resources itself separate from its behavior and external attribute can be measured in term of how the process, product or resources relates to its environment through its behavior. Thus, UCP is an approach to measure the software size based on internal product attribute and UCP is an approach to measure software size based on its functionality of software size [10,11]. ...
Employee Application (EA) is a system information for realizing the latest personal data and integrated, provide accurate employee information for planning, development, welfare and control of employees. EA in STT-PLN began to be published since 2013. The software size of the EA STT-PLN will be measured with use case point method. Measurement of the software size of EA STT-PLN will be measured with Use Case Point upon use case diagram for EA STT-PLN as shown in the project has small software size where score Use Case Point (UCP) = 70.34. UCP is another alternative implementation method which can be applied to measure application software size whenever needed to deal with time, money and people.
... Nevertheless, UCP utilities use case diagram as its factors and can be used only on object-oriented system. The Use Case Points is different from Object Points (OP) [14], because OP includes non-UML factors into its effort calculation [15], [16]. There is also other object oriented metrics which utilizes PHP_depend [17]. ...
... vouchers) are listed by opening this menu. 16. Open Setting Interface: In this menu, users will be able to open interface for several settings to the game. ...
The rise of mobile application is inevitable. Every year, the number of mobile application is increased. It is important for mobile application project owners to calculate the required resources before building a mobile application. In software metric, Use Case Points method is able to count software size of mobile application based on their functionality. This method utilizes use case diagram as their computation factors in the estimation process. Moreover, two other complexity factors are also considered in this method, which are: Technical Complexity Factor and Environment Factor. In this paper, we present software size calculation of QuestDone Mobile Application using 7 steps use case points method. QuestDone has been implemented, but we do not know its software size (i.e. how big the software, how much it cost, how many people is needed). As the result from use case points method, the Use Case Points value of QuestDone is 126.88 with Effort Estimation equal to 889 hours. The software size estimation process of QuestDone Mobile Application detailed in this paper can give an insight to project owners to count software size of other similar projects.
... To this end, we observe that the number and variety of datasets that were analyzed provide a reasonably wide sample, that is expected to be representative of a wide range of software applications. Indeed, even if 4 out of 7 datasets in our study included applications developed by students (i.e., Abualkishik, Robiolo, Liu, and Cuadrado Gallego datasets) they were not manipulated so that they could be more easily measured [19,26,27,29] . As for the type and size of the applications included in the 7 datasets, from the description provided by the researchers who previously employed them [19 , 24-30] , they can be considered representative of industrial software applications. ...
Background Several functional size measurement methods have been proposed. A few ones -like IFPUG and COSMIC methods- are widely used, while others -like Simple Function Points method- are interesting new proposals, which promise to deliver functional size measures via a faster and cheaper measurement process. Objectives Since all functional size measurement methods address the measurement of the same property of software (namely, the size of functional specifications), it is expected that measures provided in a given measurement unit can be converted into a different measurement unit. In this paper, convertibility of IFPUG Function Points, COSMIC Function Points, and Simple Function Points is studied. Method
Convertibility is analyzed statistically via regression techniques. Seven datasets, each one containing measures of a set of software applications expressed in IFPUG Function Points, COSMIC Function Points and Simple Function Points, were analyzed. The components of functional size measures (usually known as Base Functional Components) were also involved in the analysis. ResultsAll the analyzed measures appear well correlated to each other. Statistically significant quantitative models were found for all the combinations of measures, for all the analyzed datasets. Several models involving Base Functional Components were found as well. Conclusions
From a practical point of view, the paper shows that converting measures from a given functional size unit into another one is viable. The magnitude of the conversion errors is reported, so that practitioners can evaluate if the expected conversion error is acceptable for their specific purposes. From a conceptual point of view, the paper shows that Base Functional Components of a given method can be used to estimate measures expressed in a different measurement unit: this seems to imply that different functional size measurement methods are 'structurally' strongly correlated.
... L Lavazza et al [10] improve UCP method using Path (P) and Transaction (T) which is described in the use case description to create a measurement model established by linear regression. G Robiolo et al [11] offer an alternative way by creating an effort model with linear regression using use case transactions and scenarios as main factors. ...
Software size is widely recognized as an important parameter for effort and cost estimation. Currently there are many methods for measuring software size including Source Line of Code (SLOC), Function Points (FP), Netherlands Software Metrics Users Association (NESMA), Common Software Measurement International Consortium (COSMIC), and Use Case Points (UCP). SLOC is physically counted after the software is developed. Other methods compute size from functional, technical, and/or environment aspects at early phase of software development. In this research, activity point approach is proposed to be another software size estimation method. Activity point is computed using activity diagram and adjusted with technical complexity factors (TCF), environment complexity factors (ECF), and people risk factors (PRF). An evaluation of the approach is present.
... International Function Point User Group (IFPUG), which managed the evolution of the technique through several releases of the Function Point (FP) [5], [8], [9]. There are several variations of Function Point and methods with all pros and cons for each method, such as: Mark II, NESMA, FiSMA, COSMIC, FSM, FPA UML-Base and Use-Case Points [5], [7], [8]. ...
... International Function Point User Group (IFPUG), which managed the evolution of the technique through several releases of the Function Point (FP) [5], [8], [9]. There are several variations of Function Point and methods with all pros and cons for each method, such as: Mark II, NESMA, FiSMA, COSMIC, FSM, FPA UML-Base and Use-Case Points [5], [7], [8]. The use case points method was proposed by Karner [7] and The method is extension of Function Points (FP) method [6], [9]. ...
Knowledge Management portal is a system to support Knowledge Management process, in order to create, capture, develop, share, reuse and optimize the knowledge and particularly in Bina Nusantara University which has implemented Knowledge Management System (KMS) since 2002. However, this KMS need to be measured in order to know how better this KMS in term of the software size. The BINUS KMS will be measured in term of their software size in functionality perspective with use case point method. This metric of KMS will be used by management to know how better the software size, complexity level and effort to development in numbering. Measurement of software size with software metric such as Use Case Point upon use case diagram for BINUS knowledge Management Portal shows that the project has medium software size with score Use Case Point (UCP) = 108.56 and has estimate effort will be developed in 2,064 hours (or in 258 days or 51.6 weeks or 12.9 months) and has development cost for 516,000,000.00 rupiah (Indonesian currency). Use Case Point, estimate effort and project value will powerful to help management in order to make decision regarding the implementation of IT software project development in term of time, money and people.
