Abstract: . . .  al.: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading MA (1994) 15. Seddon, J.: The Case Against ISO 9000 . 2nd edn. Oak Tree Press, Dublin (2000) 16. Software Engineering Institute: Capability Maturity Model Integration. Version 1.1, Staged Representation. Carnegie Mellon University. (2002) 17. Sommerville, I., Sawyer, P.: Requirements Engineering: A Good Practice Guide. John Wiley & Sons, Chichester (1997). 18. Tricker, R., Sherring-Lucas, B.: ISO 9000 :2000 in Brief. Butterworth-Heinemann, Oxford (2001). . . .
. . .  Oligny, S., Kusters, R., van Veenendaal, E. (eds.): Project Control: Satisfying the Customer. Proceedings of ESCOM 2001. Shaker Publishing (2001) 269–276 12. Nawrocki, J., Walter, B., Wojciechowski, A.: Toward Maturity Model for eXtreme Programming. Proceedings of the 27th EUROMICRO Conference, Los Alamitos. IEEE Computer Society (2001) 233–239 13. Nawrocki, J., Walter, B., Wojciechowski, A.: Comparison of CMM Level 2 and eXtreme Programming. Proceedings of the 7th European Conference on Software Quality. Helsinki, Finland. (2002). LNCS (in printing). 14. Paulk, M. C. et al.: The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading MA (1994) 15. Seddon, J.: The Case Against ISO 9000 . 2nd edn. Oak Tree Press, Dublin (2000) 16. Software Engineering Institute: Capability Maturity Model Integration. Version 1.1, Staged Representation. Carnegie Mellon University. (2002) 17. Sommerville, I., Sawyer, P.: Requirements Engineering: A Good Practice Guide. . . .
. . .  developments it is necessary to make investments in new technologies and try new tools out. On the other hand, new tools and technologies are imma- ture and one cannot depend on them. The best approach is to make some (preferably small) investment now and after some time invest more or give up, depending on the developments (it is like buying an option on the stock exchange). XP is based on incremental software development and its suites the strategy very well. – Customer orientation . In XP all the business decisions are made by the customer and he has the full control over the development process. – Lack of excessive paperwork . In XP programmers concentrate on program- ming, not on writing documentation. The only artifacts they have to produce are test cases and code. – Quality assurance through intensive testing . In XP programmers first cre- ate test cases then they write code. Automated tests and integration are performed several times a day and they drive the development process. – Lack . . .
--3000,3,500,2806,26328