Software Requirements and Specification

Transcription

1 Software Requirements and Specification Agile Methods SE Jay Urbain Credits: Beck, K. (1999). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. Beck, Kent; et al. (2001). Manifesto for Agile Software Development. Agile Alliance. Retrieved Larman, Craig; Basili, Victor R. (June 2003). Iterative and Incremental Development: A Brief History. Computer 36 (6):

2 Agile Methods 2

3 Agile Development Methods Iterative and incremental software development methodology. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. Promotes: adaptive planning evolutionary development and delivery, and a time-boxed iterative approach Encourages rapid and flexible response to change. Note: Agile management methods can (and are) be applied to development projects other than software development. 3

4 Background IBM's Service Bureau Corporation documented adaptive development techniques in Paper by E. A. Edmonds (1974) introduced an adaptive software development process. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Boston, MA: Addison-Wesley. Beck, Kent; et al. (2001). Manifesto for Agile Software Development. Agile Alliance. Retrieved Larman, Craig; Basili, Victor R. (June 2003). Iterative and Incremental Development: A Brief History. Computer 36 (6):

5 Why Agile Development? Lightweight software development methods evolved in the mid-1990s as a reaction against heavyweight methods characterized as: heavily regulated regimented micromanaged waterfall model of development 5

6 Agile Method Implementations Early implementations of lightweight (Agile) methods include: Scrum (1995) Crystal Clear (1996) Extreme Programming (1996) Adaptive Software Development (1995) Feature Driven Development (1995) Dynamic Systems Development Method (DSDM) (1995) Now typically referred to as agile methodologies, after the Agile Manifesto published in

7 Agile Manifesto Beck, Kent; et al. (2001). "Manifesto for Agile Software Development". Agile Alliance. Retrieved Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Note: While there is value in the items on the right, we value the items on the left more. 7

8 Agile Manifesto Principles 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently (weeks rather than months) 4. Working software is the principal measure of progress 5. Sustainable development, able to maintain a constant pace 6. Close, daily co-operation between business people and developers 7. Face-to-face conversation is the best form of communication (colocation) 8. Projects are built around motivated individuals, who should be trusted 9. Continuous attention to technical excellence and good design 10. Simplicity 11. Self-organizing teams 12. Regular adaptation to changing circumstances 8

9 Agile Methods Promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. Break tasks into small increments with minimal planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a team working through a full software development cycle: planning, requirements analysis, design, coding, unit testing, and acceptance testing working product demonstrated to stakeholders. 9

10 Agile Methods Minimizes overall risk and allows the project to adapt to changes quickly. Stakeholders produce documentation as required. Multiple iterations may be required to release a product or new features. Team composition in an agile project is usually crossfunctional and self-organizing. Agile team will always contain a customer representative. Most agile implementations use a routine and formal daily face-to-face communication among team members 10

11 Agile Process 11

12 Extreme Programming 12

13 Extreme Programming Goal: Improve software quality and responsiveness to changing customer requirements. Advocates frequent "releases" in short development cycles (timeboxing) intended to improve productivity and introduce checkpoints where new customer requirements can be adopted. Takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels, on the theory that if some is good, more is better. 13

14 Extreme Process 14

15 Extreme Programming Other elements of extreme programming include: programming in pairs extensive code review unit testing of all code avoiding programming of features until they are actually needed flat management structure simplicity and clarity in code expecting changes in the customer's requirements as time passes and the problem is better understood frequent communication with the customer and among programmers 15

16 Extreme Origins Created by Kent Beck while working on the Chrysler Comprehensive Compensation System (C3) payroll project (1996). Beck wrote Extreme Programming Explained (1999). Rise of the Internet and the dot-com boom emphasized speed-to-market as competitive business factors. Rapidly-changing requirements demanded short product life-cycles (incompatible with traditional methods). 16

17 Scrummage Scrum (abbreviated form of scrummage), a way of restarting a game, either after an accidental infringement or (in rugby) when the ball has gone out of play. 17

18 Scrum Background Iterative, incremental framework for project management (1986, Hirotaka Takeuchi and Ikujiro Nonaka). DeGrace and Stahl (1991) coined the scrum approach referring to the manner of restarting a rugby game after a minor infraction. Often seen in agile software development (introduced by 1995, Sutherland and Schwaber). 18

19 Scrum Characteristics Scrum Process skeleton that contains sets of practices and predefined roles. The main roles in Scrum are: Scrum Master Maintains the processes (project manager) Product Owner Represents the stakeholders and the business Team Cross-functional group who do the actual analysis, design, implementation, testing, etc. Sprint Basic unit of development (iteration). Fixed interval of 1 to 4 weeks (timeboxed). 19

20 Scrum Characteristics Daily Scrum During the sprint, a project status meeting occurs. Burn down During the sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Many additional processes, artifacts, and terms! 20

21 Bottom Line A development process is a means to an end, and has to work for your application and organization. Critical for team members to understand application needs (requirements) and not get off track agile helps us with this. The less certain the requirements the more agile we need to be. In all cased, understanding customer needs is critical and we often can not adequately elicit customer requirements without providing them something to evaluate. Successfully delivered projects are all about reducing risk, understanding the needs of the customer, and be able to adapt to change. Once you start using something, your needs evolve. And this is life ;-). 21