Agile Development

Transcription

1 Agile Development

2 Many flavors: Waterfall, Spiral Rapid Application Development (DSDM) Xtreme Programming (XP, an agile methodology) Usability Engineering Model, Star Iteration is done throughout Guides you through steps in development of technology Sometimes institutionalized

3 Mother of all models Outdated but iterative versions still used Five stages Requirements Design Code Test Maintain

4 Very difficult to get requirements right at the beginning of process No iteration expected, although some modified versions allow for iteration No testing of design before coding starts Cost to make fixes greatly increases after coding begins

5 Developed during the 1980 s, published in 1991 Use of computer-aided software engineering (CASE) tools Turn requirements into code quickly

6 Time Boxing: keep development cycles short Prototyping: create interactive prototypes quickly in order to get user feedback Iteration: Each cycle increases features of application Users involved in providing feedback after each cycle Teams: small, experienced, motivated team members Management: remove paperwork/bureaucratic barriers Joint Application Development (JAD) workshops Get stakeholders and programmers together to develop requirements

7 But still code before getting feedback from users on design

8 cf. IBM Software Group, Agile development

9 Myth 1. No Documentation 2. Undisciplined 3. No Planning 4. Not Predictable 5. Does Not Scale 6. Is a Fad 7. Silver Bullet Reality 1. Agile Documentation 2. Requires great discipline 3. Just-in-time (JIT) planning 4. Far more predictable 5. Eclipse is agile 6. Quickly becoming the norm 7. It requires skilled people

10 What is ASD? How it s different Mythbusters Why does ASD Work? Some Common Practices

11 An iterative and incremental (evolutionary) approach performed in a highly collaborative manner with just the right amount of ceremony to produce high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. Core principles Fits just right process Continuous testing and validation Consistent team collaboration Rapid response to change Ongoing customer involvement Frequent delivery of working software 11

12 Code and fix Classic Engineering methodologies predictive process-oriented Lightweight methodologies (agile) adaptive people-oriented

13 Code and fix Classic Engineering methodologies predictive process-oriented Lightweight methodologies (agile) adaptive people-oriented

14

15 Most prominent of the Agile methodologies Developed in late 1990 s Adaptability emphasized over predictability expect requirements to change, so must adapt to them different from methods which attempt to define all requirements early in the life cycle Communication: frequent verbal communication to ensure users and developers are on the same page Simplicity: Start with simplest solution & increase complexity as needed Feedback: Unit tests, acceptance tests (testing utility), quick estimates

16 Principles: Design for today, not for tomorrow Throw code away if necessary Rapid feedback from customers Incremental rather than major changes Expect changes in requirements Less documentation Less emphasis on design May get tempted to keep adding features May concentrate user acceptance tests on utility neglecting other usability goals

17 Planning User Stories Release Planning Small Releases Measure Project Velocity Divide project to iterations Iterations Planning Move People around Stand up meeting Designing Simplicity System Metaphor CRC cards Spike solutions YAGNI Refactor cf.

18 Planning User Stories Release Planning Small Releases Measure Project Velocity Divide project into iterations Iterations Planning Move People around Stand up meeting Designing Simplicity System Metaphor CRC cards Spike solutions YAGNI Refactor cf.

19 Planning User Stories Release Planning Small Releases Measure Project Velocity Divide project to iterations Iterations Planning Move People around Stand up meeting Fix XP when it breaks Designing Simplicity System Metaphor CRC cards Spike solutions YAGNI Refactor cf.

20 Planning User Stories Release Planning Small Releases Measure Project Velocity Divide project to iterations Iterations Planning Move People around Stand up meeting Designing Simplicity System Metaphor CRC cards Spike solutions YAGNI Refactor cf.

21 Coding Customer available Code standards Test-Driven Pair Programming Sequential change integration Integrate often Collective code ownership Don t optimize early No overtime Testing Unit test everything All tests pass before release Bug== new test Acceptance tests cf.

22 Coding Customer available Code standards Test-Driven Pair Programming Sequential change integration Integrate often Collective code ownership Don t optimize early No overtime Testing Unit test everything All tests pass before release Bug== new test Acceptance tests cf.

23 Coding Customer available Code standards Test-Driven Pair Programming Sequential change integration Integrate often Collective code ownership Don t optimize early No overtime Testing Unit test everything All tests pass before release Bug== new test Acceptance tests cf.

24 Coding Customer available Code standards Test-Driven Pair Programming Sequential change integration Integrate often Collective code ownership Don t optimize early No overtime Testing Unit test everything All tests pass before release Bug== new test Acceptance tests cf.

25 A Unit Test is a test of a small functional piece of code Easier to find bugs Easier to maintain Easier to understand Easier to Develop You have already done unit testing

26

27 AgileAlliance.com ExtremeProgramming.org y.html To Learn More: CS350 Software Design & Development EE368 Software Engineering CS459 Human-Computer Interaction

28 Monday, December 9 th,7:00 10:00 pm SC 162, closed book, open notes Sections 1 & 2 are optional (bring Exam1 & Exam2 with you & submit with final exam) Section 3 is required

29 Java I/O: binary data Serialized data Compressed files Networking client-server paradigm Socket (client-side) ServerSocket (server-side) Multithreading Thread safety Synchronization General JSP (Servlets, RMI) Agile Programming Methodoloty Inheritance & Composition Design

30 The object serialization API provides a method for encoding objects as byte streams, and reconstituting them; the encoding can be transferred from one VM to another, or saved in a binary file for later deserialization. Item 74: Implement Serializable judiciously decreases the flexibility to change a class s implementation once it has been released increases the likelihood of bugs and security holes (hidden constructor, Item 76) increases the testing burden associated with releasing a new version of a class

31 Note: classes designed for inheritance should rarely implement Serializable, and interfaces should rarely extend it; exception Throwable, Component and HttpServlet inner classes (Item 22) should not implement Serializable as a rule of thumb, value classes such as Date and BigInteger should implement Serializable, as should most collection classes

32 Synchronization required for all shared data structures like Shared databases (like account balances) Global variables Dynamically allocated structures (off the heap) like queues, lists, trees, etc. What are not shared data structures? Variables that are local to a procedure/method (on the stack) Note, though, that other bad things happen if try to share pointer to a variable that is local to a procedure

33 public synchronized void transfer(int from, int to, int amount) { try { while (accounts[from] < amount) wait(); accounts[from] -= amount; accounts[to] += amount; ntransacts++; notifyall(); if (ntransacts % NTEST == 0) test(); } catch(interruptedexception e) { // handle the exception } }

34 Item 66: Synchronize access to shared mutable data synchronized code ensures that an object is only observed when it is in a consistent state (mutual exclusion) synchronized code also ensures that when one thread starts running code in a synchronized method, it sees all the modifications to that same object made by other threads

35 a specific object is locked (not a class, not a method) when an object is locked, no other thread may modify it when a thread successfully calls a synchronized method, it owns the lock to the object until either it returns from the method, or it calls wait()