1 / 28

Extreme Programming Modified : Embrace Requirements Engineering Practices

IEEE Joint International Conference on Requirements Engineering 9-13 September 2002, Essen, Germany. Extreme Programming Modified : Embrace Requirements Engineering Practices. J . Nawrocki , M. Jasinski, B. Walter, A.Wojciechowski Poznan University of Technology, Poznan, Poland.

damian
Download Presentation

Extreme Programming Modified : Embrace Requirements Engineering Practices

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IEEE Joint International Conference on Requirements Engineering 9-13 September 2002, Essen, Germany Extreme Programming Modified:Embrace Requirements Engineering Practices J. Nawrocki, M. Jasinski, B. Walter, A.Wojciechowski Poznan University of Technology, Poznan, Poland

  2. Extreme Programming (XP) = a lightweight (agile) software development methodology Tom DeMarco Introduction "XP is the most important movement in our field today."

  3. Introduction • Interesting practices of XP: • strong customer orientation • increments & short releases • test-first coding • planning game etc.

  4. Introduction • Weaknesses of XP: • lack of documentation • one (on-site) customer • too short planning perspective How to solve those problems and preserve agility?

  5. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

  6. I’ve changed my mind. Let’s go that way. Documen -tation Documen -tation Developer Customer Reconciling XP with documentation Travel light.

  7. I’ve changed my mind. No problem. code + tests Customer Reconciling XP with documentation Travel light. What you need is just code and test cases. IEEE Standard 830 UML

  8. Error Reconciling XP with documentation Travel light. What you need is just code and test cases. Oral communication is preferred as „the written and e-mail communications (..) are error-prone”. But people sometimes forget! Why did I decide to ..

  9. I’ve changed my mind. No problem. Documen -tation Customer Reconciling XP with documentation To be agile does not mean that you have to throw away the (requirements) documentation.

  10. I’ve changed my mind. No problem. Documen -tation Developer Customer Reconciling XP with documentation To be agile does not mean that you have to throw away the (requirements) documentation.

  11. Reconciling XP with documentation To be agile does not mean that you have to throw away the requirements documentation. In XP tester „is responsible for helping the customer choose and write functional tests”. -- Kent Beck • XP roles: • Customer • Developer • Coach • Tracker • Tester Tester-analyst (product manager) is responsible for writing and managing usage scenarios, requirements, and acceptance tests. Tools: Rational RequisitePro, Rational Robot, xUnit

  12. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

  13. Weaknesses of XP One on-site customer If there are many it is assumed they speak one voice. Sometimes they don’t. We need a new car. No! We need a new furniture.

  14. Original Planning Game Development Customer Customer 6 h More colors 9 h More func. 9 hours More colors More colors Writes user stories Chooses scope Effort, risk, velocity Multiple customer representatives

  15. Modified Planning Game Development Customers Customers 6 h 9 h More colors More func. More colors 9 hours More colors More colors They write user stories Effort, risk, velocity How to choose the scope? Multiple customer representatives

  16. Modified Planning Game Big boss Customers Multiple customer representatives 20 hours for you .. Customers 6 h 9 h More func. More colors How to choose the scope?

  17. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

  18. Technical risk Utility A spike solution Modifying the XP Lifecycle Design for today, not for tomorrow. Short planning perspective (one release) One release is sometimes not enough.

  19. Modifying the XP Lifecycle Design for today, not for tomorrow. Short planning perspective (one release) One release is sometimes not enough. Technical risk Utility

  20. Modifying the XP Lifecycle 0. Initial Project Statement (subject, stakeholders etc.) 1. Usage scenarios (problems + visions) 2. Requirements specification 3. Project presentation & selection of developers 4. Project planning (and risk exploration) 5. Release 1 (2 iterations, each takes 3 weeks) 6. Release 2 (2 iterations)

  21. Contents 1. Introduction 2. Reconciling XP with documentation 3. Multiple customer representatives 4. Modifying the XP lifecycle 5. Early evaluation results 6. Conclusions

  22. Quality Manager and Facilitator 5th year Project Manager and Analyst 4th year Designing, coding, testing, writing documentation 3rd year Software Development Studio – A team structure

  23. Experiment at PUT Software Development Studio 2000/01 CMM Level 2 eXtremme Programming

  24. Experiment at PUT Software Development Studio 2001/02 Modified eXtremme Programming

  25. Score: 3 – obligatory 2 – frequently used 1 – sometimes 0 – never Initial < 55 Basic Sommerville-Sawyer Model RE Practices • Interm. • ... • ... • Advanced • ... • ... • Basic • ... • ... Defined > 85 Basic & > 40 Interm.+Adv. Repeatable > 55 Basic

  26. Score: 3 – obligatory 2 – frequently used 1 – sometimes 0 – never Initial < 55 Basic Sommerville-Sawyer Model Defined > 85 Basic & > 40 Interm.+Adv. Repeatable > 55 Basic

  27. Summary At last! • Tester-analyst is responsible for documenting and managing requirements. • Modified Planning Game tries to solve conflicts between multiple customers. • Modified life-cycle emphasises requirements engineering and risk management. • There is a need for user training. • Early results are promising.

  28. Questions? ?

More Related