Chapter4 Agile Development Rapid Development Rapid development and

Chapter-4 Agile Development

Rapid Development Ø Rapid development and delivery is now often the most important requirement for software systems — Businesses operate in a fast –changing requirement and it is practically impossible to produce a set of stable software requirements — Software has to evolve quickly to reflect changing business needs. Ø Rapid software development — Specification, design and implementation are inter-leaved — System is developed as a series of versions with stakeholders involved in version evaluation — User interfaces are often developed using an IDE and graphical toolset.

Agile Development Ø Dissatisfaction with the overheads involved in software design methods of the 1980 s and 1990 s led to the creation of agile methods. These methods: — Focus on the code rather than the design — Are based on an iterative approach to software development — Are intended to deliver working software quickly and evolve this quickly to meet changing requirements. Ø The aim of agile methods is to reduce overheads in the software process (e. g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

Agile Manifesto Ø We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan Ø That is, while there is value in the items on value the items on the left more. the right, we

What is “Agility”? Ø Effective (rapid and adaptive) response to change (team Ø Ø members, new technology, requirements) Effective communication in structure and attitudes among all team members, technological and business people, software engineers and managers。 Drawing the customer into the team. Eliminate “us and them” attitude. Planning in an uncertain world has its limits and plan must be flexible. Organizing a team so that it is in control of the work performed Emphasize an incremental delivery strategy as opposed to intermediate products that gets working software to the customer as rapidly as feasible.

Agility and the Cost of Change

Agility and the Cost of Change Ø Conventional wisdom is that the cost of change increases nonlinearly as a project progresses. It is relatively easy to accommodate a change when a team is gathering requirements early in a project. If there any changes, the costs of doing this work are minimal. But if the middle of validation testing, a stakeholder is requesting a major functional change. Then the change requires a modification to the architectural design, construction of new components, changes to other existing components, new testing and so on. Costs escalate quickly. Ø A well-designed agile process may “flatten” the cost of change curve by coupling incremental delivery with agile practices such as continuous unit testing and pair programming. Thus team can accommodate changes late in the software project without dramatic cost and time impact.

Agile Process Ø Is driven by customer descriptions of what is required (scenarios). Some assumptions: — Recognizes that plans are short-lived (some requirements will persist, some will change. Customer priorities will change) — Develops software iteratively with a heavy emphasis on construction activities (design and construction are interleaved, hard to say how much design is necessary before construction. Design models are proven as they are created. ) — Analysis, design, construction and testing are not predictable. Ø Thus has to Adapt as changes occur due to unpredictability Ø Delivers multiple ‘software increments’, deliver an operational prototype or portion of an OS to collect customer feedback for adaption.

The principles of agile methods

Advantages of Agile Methods Ø Customer satisfaction by rapid, continuous delivery of useful software. Ø People and interactions are emphasized rather than process and tools. Ø Customers, developers and testers constantly interact with each other. Ø Working software is delivered frequently (weeks rather than months). Ø Face-to-face conversation is the best form of communication. Ø Close, daily cooperation between business people and developers. Ø Regular adaptation to changing circumstances. Even late changes in requirements are welcomed

Plan-driven and agile development Ø Plan-driven development — A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. — Not necessarily waterfall model – plan-driven, incremental development is possible — Iteration occurs within activities. Ø Agile development — Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

Plan-driven and agile development

Agile Methodologies for Software Development

Extreme Programming XP Ø Developed by Kent Beck : — XP is “a light-weight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements. ” Ø Alternative to “heavy-weight” software development models (which tend to avoid change and customers) — "Extreme Programming turns the conventional software process sideways. Rather than planning, analyzing, and designing for the far-flung future, XP programmers do all of these activities a little at a time throughout development. ” — -- IEEE Computer , October 1999

XP Process

XP PLANNING Ø The planning activity (also called the planning game) begins with listening—a requirements gathering activity that enables the technical members of the XP team to understand the business context for the software — Begins with the creation of user stories(Required Features and Functionality) — Each story is assigned a value(priority) — Agile team assesses each story and assigns a cost — If the Story will required more than three development weeks, customer is asked to split the story into smaller stories

XP PLANNING — Stories are grouped to for a deliverable increment — A commitment is made on delivery date, the stories are developedin one of the three ways 1. All stories will be implemented immediately 2. The stories with highest value will be moved up in the schedule and implemented first 3. The riskiest stories will be moved up in the schedule and implemented first PROJECT VELOCITY — After the first increment project velocity “Number of stories implemented in first release” — define subsequent delivery dates for other increments — Whether over commitment has been made

XP DESIGN —Follows the KIS (Keep It Simple) principle “Simple design is always preferred” —Provides implementation guidance for a story “Nothing Less Nothing More” —Encourage the use of CRC (Class Responsibility Collaborator)cards “CRC cards identify and organize the object-oriented classes that are relevant to the current software increment. ” —If a difficult design problem is encountered, XP recommends the immediate creation of an operational prototype of that portion of the design. Called a spike solution, the design prototype is implemented and evaluated. —Encourages Refactoring an iterative refinement of the internal program design Doesn’t alter internal behavior of code Minimizes the chances of bugs Improve design of code

XP CODING —the use of CRC —Recommends the construction of a unit test for a store before coding commences —Programmer is better able to focus on what must be implemented to pass the unit test —Encourages pair programming (key concept) v. Real time problem solving v. Real time quality assurance —The pair programmers have integration responsibility. —This “continuous integration” strategy helps to avoid compatibility and interfacing problems and provides a “smoke testing” environment

XP TESTING —All unit tests are executed daily —The unit tests that are created should be implemented using a framework that enables them to be automated (hence, they can be executed easily and repeatedly). This encourages a regression testing strategy —Acceptance tests are defined by the customer and executed to assess customer visible functionality

UNIT TESTING Ø Unit testing focuses verification effort on the smallest unit of Ø 1. 2. 3. 4. software design—the software component or module Unit-test considerations. The module interface is tested to ensure that information properly flows into and out of the program unit under test. Local data structures are examined to ensure that data stored temporarily maintains its integrity during all steps in an algorithm’s execution. All independent paths through the control structure are exercised to ensure that all statements in a module have been executed at least once. Boundary conditions are tested to ensure that the module operates properly at boundaries established to limit or restrict processing. And finally, all error-handling paths are tested.

TEST CASE Ø Test cases should be designed to uncover errors due to 1. 2. 3. 4. 5. 6. 7. erroneous computations, incorrect comparisons, or improper control flow. Comparison of different data type Incorrect logical operator or precedence Expectation of equality Incorrect comparison of variables Improper loop termination Failure to exit Improper modified loop

Embrace Change Ø In traditional software life cycle models, the cost of changing a program rises exponentially over time — Why would it cost more to make large changes during testing than during requirements specification? Ø A key assumption of XP is that the cost of changing a program can be hold mostly constant over time Ø Hence XP is a lightweight (agile) process: — Instead of lots of documentation nailing down what customer wants up front, XP emphasizes plenty of feedback — Embrace change: iterate often, design and redesign, code and test frequently, keep the customer involved — Deliver software to the customer in short (2 week) iterations — Eliminate defects early, thus reducing costs

Four Core Values of XP Ø Communication Ø Simplicity Ø Feedback Ø Courage

Four Core Values of XP Communication XP emphasizes value of communication in many of its practices: — On-site customer, user stories, pair programming, collective ownership (popular with open source developers), daily standup meetings, etc. XP employs a coach whose job is noticing when people aren’t communicating and reintroduce them

Four Core Values of XP Simplicity ''Do the simplest thing that could possibly work'' (DTSTTCPW) principle XP restricts developers to design only for immediate needs, rather than consider future needs. The intent is to create a simple design that can be easily implemented in code. If the design must be improved, it can be refactored at a later time.

Four Core Values of XP Feedback Ø Feedback at different time scales Ø Unit tests tell programmers status of the system Ø When customers write new user stories, programmers estimate time required to deliver changes Ø Programmers produce new releases every 2 -3 weeks for customers to review

Four Core Values of XP Courage Ø The courage to communicate and accept feedback Ø The courage to throw code away (prototypes) Ø The courage to refactor the architecture of a system

Twelve XP Practices The Planning Game 2. Small Releases 3. Metaphor 4. Simple Design 5. Test-driven development 6. Refactoring 7. Pair Programming 8. Collective Ownership 9. Continuous Integration 10. 40 -Hours a Week 11. On-Site Customer 12. Coding Standards 1.

The Planning Game Ø Customer comes up with a list of desired features for the system — How is this different from the usual requirements gathering? Ø Each feature is written out as a user story — Describes in broad strokes what the feature requires — Typically written in 2 -3 sentences on 4 x 6 story cards Ø Developers estimate how much effort each story will take, and how much effort the team can produce in a given time interval (iteration) Ø Project velocity = how many days can be committed to a project per week Ø Given developer estimates and project velocity, the customer prioritizes which stories to implement

Small Releases Ø Small releases — Start with the smallest useful feature set — Release early and often, adding a few features each time — Releases can be date driven or user story driven Ø Simple design — Always use the simplest possible design that gets the job done — The requirements will change tomorrow, so only do what's needed to meet today's requirements

Test-driven development Ø Test first: before adding a feature, write a test for it! — If code has no automated test case, it is assumed it does not work Ø When the complete test suite passes 100%, the feature is accepted Ø Tests come in two basic flavors… Ø Unit Tests automate testing of functionality as developers write it — Each unit test typically tests only a single class, or a small cluster of classes — Unit tests typically use a unit testing framework, such as JUnit (x. Unit) — Experiments show that test-driven development reduces debugging time — Increases confidence that new features work, and work with everything — If a bug is discovered during development, add a test case to make sure it doesn’t come back!

Test-driven development Ø Acceptance Tests (or Functional Tests) are specified by the customer to test that the overall system is functioning as specified — When all the acceptance tests pass, that user story is considered complete — Could be a script of user interface actions and expected results — Ideally acceptance tests should be automated, either using a unit testing framework, or a separate acceptance testing framework

Pair Programming Two programmers work together at one machine Ø Driver enters code, while navigator critiques it Ø Periodically switch roles Ø Research results: Pair programming increases productivity Higher quality code (15% fewer defects) in about half the time (58%) Pairs produce higher quality code Ø Pairs complete their tasks faster Ø Pairs enjoy their work more Ø Pairs feel more confident in their work Ø

Refactoring Programming team look for possible software improvements and make these improvements even where there is no immediate need for them. Ø This improves the understandability of the software and so reduces the need for documentation. Ø Changes are easier to make because the code is well-structured and clear. Ø Examples Ø Re-organization of a class hierarchy to remove duplicate code. Ø Tidying up and renaming attributes and methods to make them easier to understand. Ø The replacement of inline code with calls to methods that have been included in a program library.

More XP Practices Ø Collective code ownership — No single person "owns" a module — Any developer can work on any part of the code base at any time Ø Continuous integration — All changes are integrated into the code base at least daily — Tests have to run 100% both before and after integration

More XP Practices Ø 40 -hour work week — — Programmers go home on time “fresh and eager every morning, and tired and satisfied every night” In crunch mode, up to one week of overtime is allowed More than that and there’s something wrong with the process Ø On-site customer — Development team has continuous access to a real live customer, that is, someone who will actually be using the system Ø Coding standards — Everyone codes to the same standards — Ideally, you shouldn't be able to tell by looking at it who on the team has touched a specific piece of code

Examples of task cards for prescribing medication

Self Study SCRUM