Bartosz Walter

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.

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.

Leveraging code smell detection with inter-smell relations

The variety of code smells deserves a numerous set of detectors capable of sensing them. There exist several sources of data that may be examined: code metrics, existence of particular elements in an abstract syntax tree, specific code behavior or subsequent changes in the code. Another factor that can be used for this purpose is the knowledge of other, already detected or rejected smells. In the paper we define and analyze different relations that exist among smells and provide tips how they could be exploited to alleviate detection of other smells.

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.

Investigating the Impact of Code Smells on System's Quality: An Empirical Study on Systems of Different Application Domains

There are various activities that support software maintenance. Program comprehension and detection of design anomalies and their symptoms, like code smells and anti patterns, are particularly relevant for improving the quality and facilitating evolution of a system. In this paper we describe an empirical study on the detection of code smells, aiming at identifying the most frequent smells in systems of different domains and hence the domains characterized by more smells. Moreover, we study possible correlations existing among smells and the values of a set of software quality metrics using Spearmans rank correlation and Principal Component Analysis.

Multi-criteria detection of bad smells in code with UTA method

Bad smells are indicators of inappropriate code design and implementation. They suggest a need for refactoring, i.e. restructuring the program towards better readability, understandability and eligibility for changes. Smells are defined only in terms of general, subjective criteria, which makes them difficult for automatic identification. Existing approaches to smell detection base mainly on human intuition, usually supported by code metrics. Unfortunately, these models do not comprise the full spectrum of possible smell symptoms and still are uncertain. In the paper we propose a multi-criteria approach for detecting smells adopted from UTA method. It learns from programmers preferences, and then combines the signals coming from different sensors in the code and computes their utility functions. The final result reflects the intensity of an examined smell, which allows the programmer to make a ranking of most onerous odors.

Aspect-oriented Response Injection: an Alternative to Classical Mutation Testing

Due to increasing importance of test cases in software development, there is a need to verify and assure their quality. Mutation testing is an effective technique of checking if tests react properly to changes by introducing alterations to the original source code. A mutant which survives all test cases indicates insufficient or inappropriate testing assertions. The most onerous disadvantage of this technique is considerable time required to generate, compile mutants and then execute test cases against each of them. In the paper we propose an aspect-oriented approach to generation and execution of mutants, called response injection, which excludes the need for separate compilation of every mutant.

Inter-smell relations in industrial and open source systems: A replication and comparative analysis

The presence of anti-patterns and code smells can affect adversely software evolution and quality. Recent work has shown that code smells that appear together in the same file (i.e., collocated smells) can interact with each other, leading to various types of maintenance issues and/or to the intensification of negative effects. It has also been found that code smell interactions can occur across coupled files (i.e., coupled smells), with comparable negative effects as the interaction of same-file (collocated) smells. Different inter-smell relations have been described in previous work, yet only few studies have evaluated them empirically. This study attempts to replicate the findings from previous work on inter-smell relations by analyzing larger systems, and by including both industrial and open source ones. We also include the analysis of coupled smells in addition to collocated smells, to achieve a more complete picture of inter-smell relations. Our results suggest that if coupled smells are not considered, one may risk increasing the number of false negatives when analysing inter-smells. A major finding is that patterns of inter-smell relations vary between open source and industrial systems, suggesting that contextual variables should be considered in further studies on code smells.

The relationship between design patterns and code smells

Context-Design patterns represent recommended generic solutions to various design problems, whereas code smells are symptoms of design issues that could hinder further maintenance of a software system. We can intuitively expect that both concepts are mutually exclusive, and the presence of patterns is correlated with the absence of code smells. However, the existing experimental evidence supporting this claim is still insufficient, and studies separately analyzing the impact of smells and patterns on code quality deliver diverse results.Objective-The aim of the paper is threefold: (1) to determine if and how the presence of the design patterns is linked to the presence of code smells, (2) to investigate if and how these relationships change throughout evolution of code, and (3) to identify the relationships between individual patterns and code smells.Method-We analyze nine design patterns and seven code smells in two medium-size, long-evolving, open source Java systems. In particular, we explore how the presence of design patterns impacts the presence of code smells, analyze if this link evolves over time, and extract association rules that describe their individual relationships.Results-Classes participating in design patterns appear to display code smells less frequently than other classes. The observed effect is stronger for some patterns (e.g., Singleton, State-Strategy) and weaker for others (e.g., Composite). The ratio between the relative number of smells in the classes participating in patterns and the relative number of smells in other classes, is approximately stable or slightly decreasing in time.Conclusion-This observation could be used to anticipate the smell-proneness of individual classes, and improve code smell detectors. Overall, our findings indicate that the presence of design patterns is linked with a lower number of code smell instances. This could support programmers in a context-sensitive analysis of smells in code.