Combining Extreme Programming with ISO 9000
EurAsia-ICT '02 Proceedings of the First EurAsian Conference on Information and Communication Technology
Requirements interaction management in an eXtreme programming environment: a case study
Proceedings of the 27th international conference on Software engineering
A risk-driven method for eXtreme programming release planning
Proceedings of the 28th international conference on Software engineering
A Rewriting Framework for Rule-Based Programming Dynamic Applications
Fundamenta Informaticae - SPECIAL ISSUE ON CONCURRENCY SPECIFICATION AND PROGRAMMING (CS&P 2005) Ruciane-Nide, Poland, 28-30 September 2005
Requirement process establishment and improvement: from the viewpoint of cybernetics
COMPSAC-W'05 Proceedings of the 29th annual international conference on Computer software and applications conference
A study to support agile methods more effectively through traceability
Innovations in Systems and Software Engineering
Communication patterns of agile requirements engineering
Proceedings of the 1st Workshop on Agile Requirements Engineering
Balancing agility and discipline with XPrince
RISE'05 Proceedings of the Second international conference on Rapid Integration of Software Engineering Techniques
A Rewriting Framework for Rule-Based Programming Dynamic Applications
Fundamenta Informaticae - SPECIAL ISSUE ON CONCURRENCY SPECIFICATION AND PROGRAMMING (CS&P 2005) Ruciane-Nide, Poland, 28-30 September 2005
| Hi-index | 0.00 |
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.