No abstract

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. 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.

Since the early 90's 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.

No abstract

Extreme Programming (XP) is a lightweight software development niethodolog\~. It attracts attention of many software development teritns and its populurih is growing vent fast. A part of success conies from ititeresting conipositioti of programming practices included into XP. But what particularlv appeals to programmers arid makes XP especially ititeresting to them is resignation of inspection meetings, thick docunientation etc. Many people do trot understrind XP arid they find XP a good excuse for riot usitig approved programming practices. Thus, a maturity model f o r XP is needed that would indicate the risk associated with a project arid in some crises made it clear tiiat a project is not followitig tieither C M M I '~ nor XP practices. Iti the paper we propose a simple 4-level tnuturity tnodel for XP.organization that he/she will be hardly available to the project.Thus, one needs to distinguish between different levels of advancement in XP practices. Those levels could be indication of risk associated with a project (the higher level, the lower risk) and those levels -like in case ofIn the paper a simple 4-level maturity model for XP is proposed. The model resembles CMM(1) and PSP. In Section 2 basic XP practices are presented. Section 3 contains a brief survey of different types of maturity models and we explain why we decided to use a CMMlike model with four levels. In Section 4 we present a concept of maturity model for extreme Programming. The maturity levels are describe in Sections 5 -7. The assessment problems are briefly discussed in Section 8. The rules and practices of XP 1. IntroductionLightweight software development methodologies like extreme Programming (XP) are getting more and more popular. A part of success comes from interesting composition of programming practices included into XP. The XP practices have been selected to ' form a complementary set in which one of them supports another [2, 31. But what particularly appeals to programmers and makes XP especially interesting to them is resignation of inspection meetings, thick documentation etc.However, our experience is that many people find XP a good excuse for not using approved programming practices. They do not follow neither classical practices nor XP ones. One of the reasons is that some of the XP practices are very hard to be followed in 100%. For cxample XP requires to have an on-site customer representative capable of making business decisions concerning the project. In many cases a person who has the power of making business decisions and is not afraid of political conflicts [ I ] is so important to the client Extreme Programming, XP is a lightweight methodology for software development [2]. XP is oriented towards delivering incrementally growing software products. Its flexible character comes from experience of software project managers, programmers and businessoriented people involved in software development. It gives strong preference to informal oral communication in development teams over methods of written documentation of des...