Jerzy R. Nawrocki

Simplifying effort estimation based on Use Case Points

Context: The Use Case Points (UCP) method can be used to estimate software development effort based on a use-case model and two sets of adjustment factors relating to the environmental and technical complexity of a project. The question arises whether all of these components are important from the effort estimation point of view. Objective: This paper investigates the construction of UCP in order to find possible ways of simplifying it. Method: The cross-validation procedure was used to compare the accuracy of the different variants of UCP (with and without the investigated simplifications). The analysis was based on data derived from a set of 14 projects for which effort ranged from 277 to 3593 man-hours. In addition, the factor analysis was performed to investigate the possibility of reducing the number of adjustment factors. Results: The two variants of UCP - with and without unadjusted actor weights (UAW) provided similar prediction accuracy. In addition, a minor influence of the adjustment factors on the accuracy of UCP was observed. The results of the factor analysis indicated that the number of adjustment factors could be reduced from 21 to 6 (2 environmental factors and 4 technical complexity factors). Another observation was made that the variants of UCP calculated based on steps were slightly more accurate than the variants calculated based on transactions. Finally, a recently proposed use-case-based size metric TTPoints provided better accuracy than any of the investigated variants of UCP. Conclusion: The observation in this study was that the UCP method could be simplified by rejecting UAW; calculating UCP based on steps instead of transactions; or just counting the total number of steps in use cases. Moreover, two recently proposed use-case-based size metrics Transactions and TTPoints could be used as an alternative to UCP to estimate effort at the early stages of software development.

Extreme programming modified: embrace requirements engineering practices

Extreme programming (XP) is an agile (lightweight) software development methodology and it becomes more and more popular. XP proposes many interesting practices, but it also has some weaknesses. From the software engineering point of view the most important issues are: maintenance problems resulting from very limited documentation (XP relies on code and test cases only), and lack of wider perspective of a system to be built. Moreover, XP assumes that there is only one customer representative. In many cases there are several representatives (each one with his own view of the system and different priorities) and then some XP practices should be modified. In the paper we assess XP from two points of view: the capability maturity model and the Sommerville-Sawyer model (1997). We also propose how to introduce documented requirements to XP, how to modify the planning game to allow many customer representatives and how to get a wider perspective of a system to be built at the beginning of the project lifecycle.

Toward maturity model for extreme programming

Extreme programming (XP) is a lightweight software development methodology. It attracts attention of many software development teams and its popularity is growing very fast. A part of success comes from interesting composition of programming practices included in XP. But what particularly appeals to programmers and makes XP especially interesting to them is resignation of inspection meetings, thick documentation etc. Many people do not understand XP and they find XP a good excuse for not using approved programming practices. Thus, a maturity model for XP is needed that would indicate the risk associated with a project and in some cases make it clear that a project is following neither CMMI(SM) nor XP practices. In the paper, we propose a simple 4-level maturity model for XP.

Pair programming vs. side-by-side programming

In agile methodologies communication between programmers is very important. Some of them (e.g. XP or Crystal Clear) recommend pair programming. There are two styles of pair programming: XP-like and side-by-side (the latter comes from Crystal Clear). In the paper an experiment is described that aimed at comparison of those two styles. The subjects were 25 students of Computer Science of 4th and 5th year of study. They worked for 6 days at the university (in a controlled environment) programming web-based applications with Java, Eclipse, MySQL, and Tomcat. The results obtained indicate that side-by-side programming is a very interesting alternative to XP-like pair programming mainly due to less effort overhead (in the experiment the effort overhead for side-by-side programming was as small as 20%, while for XP it was about 50%).

Balancing Agility and Formalism in Software Engineering

In this age of modern era, the use of internet must be maximized. Yeah, internet will help us very much not only for important thing but also for daily activities. Many people now, from any level can use internet. The sources of internet connection can also be enjoyed in many places. As one of the benefits is to get the on-line balancing agility and formalism in software engineering second ifip tc 2 central and east european conference on software engineering techniques cee set 2007 poznaan poland october 10 12 2007 revised selected papers author bertrand meyer book, as the world window, as many people suggest.

Comparison of CMM Level 2 and eXtreme Programming

Lightweight software development methodologies promise an easy way to deliver products of high quality without excessive cost. On the contrary, classical heavyweight processes are well-defined and proven, but require a lot of effort. Two approaches: eXtreme Programming (XP) and CMM Level 2 have been used in joined industry-academic software projects run at the Poznan University of Technology. Running concurrently those two software approaches allowed us to compare them on the basis of experimental data. After the projects were completed, major risk factors connected with both approaches have been collected and some improvements have been proposed.

Improving the reliability of transaction identification in use cases

Context: The concept of transactions is used in Use Case Points (UCP), and in many other functional size measurement methods, to capture the smallest unit of functionality that should be considered while measuring the size of a system. Unfortunately, in the case of the UCP method at least four methods for use-case transaction identification have been proposed so far. The different approaches to transaction identification and difficulties related to the analysis of requirements expressed in natural language can lead to problems in the reliability of functional size measurement. Objective: The goal of this study was to evaluate reliability of transaction identification in use cases (with the methods mentioned in the literature), analyze their weaknesses, and propose some means for their improvement. Method: A controlled experiment on a group of 120 students was performed to investigate if the methods for transaction identification, known from the literature, provide similar results. In addition, a qualitative analysis of the experiment data was performed to investigate the potential problems related to transaction identification in use cases. During the experiment a use-case benchmark specification was used. The automatic methods for transaction identification, proposed in the paper have been validated using the same benchmark by comparing the outcomes provided by these methods to on-average number of transactions identified by the participants of the experiment. Results: A significant difference in the median number of transactions was observed between groups using different methods of transaction identification. The Kruskal-Wallis test was performed with the significance level @a set to 0.05 and followed by the post-hoc analysis performed according to the procedure proposed by Conover. Also a large intra-method variability was observed. The ratios between the maximum and minimum number of transactions identified by the participants using the same method were equal to 1.96, 3.83, 2.03, and 2.21. The proposed automatic methods for transaction identification provided results consistent with those provided by the participants of the experiment and functional measurement experts. The relative error between the number of transaction identified by the tool and on-average number of transactions identified by the participants of the experiment ranged from 3% to 7%. Conclusions: Human-performed transaction identification is error prone and quite subjective. Its reliability can be improved by automating the process with the use of natural language processing techniques.

Automatic Transactions Identification in Use Cases

Since the early 90s of the previous century, use cases have became informal industry standard for presenting functional requirements. The rapid popularity growth stimulated many different approaches for their presentation and writing styles. Unfortunately, this variability makes automatic processing of use cases very difficult. This problem might be mitigated by the use of transaction concept, which is defined as an atomic part of the use case scenario. In this paper we present approach to the automatic transaction discovery in the textual use cases, through the NLP analysis. The proposed solution was implemented as a prototype tool UCTD and preliminarily verified in a case study.

Supporting use-case reviews

Use cases are a popular way of specifying functional requirements of computer-based systems. Each use case contains a sequence of steps which are described with a natural language. Use cases, as any other description of functional requirements, must go through a review process to check their quality. The problem is that such reviews are time consuming. Moreover, effectiveness of a review depends on quality of the submitted document - if a document contains many easy-to-detect defects, then reviewers tend to find those simple defects and they feel exempted from working hard to detect difficult defects. To solve the problem it is proposed to augment a requirements management tool with a detector that would find easy-to-detect defects automatically.

Using Non-functional Requirements Templates for Elicitation: A Case Study

It is still an open question how to achieve a proper balance between the cost and value of requirements elicitation. When deciding to assign time and other resources to elicitation, one needs to know what its effectives would be. In the paper we investigate the Structured Elicitation of Non-functional Require-ments(SENoR) method. The method is composed of a sequence of short brainstorming sessions driven by ISO25010 quality characteristics. It uses Non-functional Requirements Templates (NoRTs) to support the elicitation process. Our exploratory case study on cost and effectiveness of SENoR and NoRTs included 7 projects that developed tailor-made web applications. The findings show that two 1.5-hour elicitation workshops can result in non-functional requirements of stability at the level of 80%.