Agile SDLC Methodology

Design and Architecture SDLC SDLC - Software Development Life Cycle Linear sequence of stages Phases in SDLC Requirement Design and Architecture Coding Testing Implementation Maintenance SDLC - all systems naturally undergo to develop a system from planning to analysis to design to implementation.

Traditional SDLC Methodologies Waterfall Model Spiral Model Iterative Model V Model Big Bang Model Rapid Application Development Model Advantages of Waterfall Model 1. Clear project objectives. 2. Stable project requirements. 3. Progress of system is measurable. 4. Strict sign-off requirements. Disadvantages of Waterfall Model 1. Time consuming 2. Never backward (Traditional) 3. Little room for iteration 4. Difficulty responding to changes Advantages of Spiral Model 1. Avoidance of Risk is enhanced. 2. Strong approval and documentation control. 3. Implementation has priority over functionality. 4. Additional Functionality can be added at a later date. Disadvantages of Spiral Model 1. Highly customized limiting re-usability 2. Applied differently for each application 3. Risk of not meeting budget or schedule 4. Possibility to end up implemented as the Waterfall framework Advantages of Prototype model 1. Strong Dialogue between users and developers 2. Missing functionality can be identified easily 3. Confusing or difficult functions can be identified 4. Requirements validation, Quick implementation of, incomplete, but functional, application 5. May generate specifications for a production application 6. Environment to resolve unclear objectives 7. Encourages innovation and flexible designs Disadvantages of Prototype model 1. Contract may be awarded without rigorous evaluation of Prototype 2. Identifying non-functional elements difficult to document 3. Incomplete application may cause application not to be used as the full system was designed 4. Incomplete or inadequate problem analysis 5. Client may be unknowledgeable 6. Approval process and requirement is not strict 7. Requirements may frequently change significantly

Project – What do we need to Know Every Project needs to be handled differently & Existing Methods need to be tailored best to suit Project Requirements

Agile – When and Where 1970 , Dr. Winston Royce Criticized the Traditional SDLCs Questioned the adaptability of these methods to Software Development Agile Evolved from techniques developed at DuPont in the mid-80s Further defined in works by James Martin and James Kerr et al. Agile – Characterized by quickness, lightness and ease of Movement (Graceful)

Agile in a Nutshell Break Products into small incremental builds Builds are provided in iterations Duration- Iterations will be one to three weeks Cross Functional Teams work Simultaneously on Planning, Requirements Analysis, Design, Coding , Unit testing & Acceptance Testing Iterative Approach – Working Software delivered after each iteration

Redefining Agile A project management process that encourages frequent inspection and adaptation; a leadership philosophy that encourages team work, self-organization and accountability; a set of engineering best practices that allow for rapid delivery of high-quality software; business approach that aligns development with customer needs and company goals. Agile can be applied in an effective and light-weight manner

Agile SDLC

Myths No Detailed Documentation Open Communication with customer Adapt to changing Product Requirements Dynamically Test the Product Frequently

Components of Agile Methodology No Component Description Classification 1 Values A Standard considered worthwhile or desirable Communication Simplicity Feedback Courage Humility 2 Principles Basic Generalization that can be accepted as true and that can be used as a basis for reasoning Core Principles Supplementary Principles 3 Practices Process of doing (can be a performance or action) Core Practices Supplementary Practices

Agile Principles Assume Simplicity Incremental Change Maximize Stakeholder Investment Model With a Purpose Multiple Models Quality Work Rapid Feedback Assume Simplicity – “The simplest solution is the best solution.” • Embrace Change – Requirements and available technologies change over time. An approach to development can only be successful if it embraces the reality of change. • Enabling the Next Effort is Your Secondary Goal – Ensure robustness of the current system before you even think about the next version. • Incremental Change – Don’t insist that a model be perfect the first time. Start with an incomplete or generalized model, and refine it over time. • Maximize Stakeholder Investment – Customers deserve final say in determining the distribution of resources. • Model With a Purpose – This requires knowing your audience. Before creating a model, determine its purpose and its audience, and then develop the model just until it is sufficiently detailed and accurate to serve its purpose, and not more. • Multiple Models – Be aware of the types of models available: UML Class & Activity Diagrams, Change Cases & Use Cases, CRC Models, Communication Diagrams, Constraint definitions, UML Deployment Diagrams, Flowcharts, etc. Just as a particular repair job at home is best completed using more than one tool from your toolbox, a particular project generally requires multiple modelling techniques. • Quality Work – Do quality work. • Rapid Feedback – Obtained by working closely with the customer. • Software Is Your Primary Goal – Remember that documentation, models, etc. are a means to an end, and not the end itself . The final product is the software. • Travel Light – Keep the number & complexity of models within your project to a minimum, to reduce the cost of updating and maintaining models. Supplementary principles of Agile Modelling include: • Content is More Important Than Representation – Consider whiteboards or post-it notes as an alternative to CASE tools. These allow you to “take advantage of the benefits of modelling without incurring the costs of creating and maintaining documentation.” [Source: Agile Modelling Principles] • Open and Honest Communication – Enables people to share ideas or even admit shortcomings, which in turn enables the team to make decisions based upon more accurate information.

Agile Practices Active Stakeholder Participation Collective Ownership Create Simple Content Depict Models Simply Display Models Publicly Prove it With Code Use the Simplest Tools

Agile Manifesto Principle Principles Description Individuals & Interactions Self Organization & Motivation Working Software Demo Working Software ( best means to communicate with customer) No Detailed Documentation Customer Collaboration Continuous Customer Interaction To get Proper Product Requirements Cannot gather all requirements Initially Responding to Change Focus on Quick responses to change Continuous Development

People Involved in Agile The Agile Team Architects Developers, Analysts, Designers Quality Assurance, Testers Tech Writers Product Owners / Customer Representatives Project Managers / ScrumMasters Note : Teams are small (~7), preferably co-located, cross functional. Scale by adding teams, not more people

Popular Agile Methods Rational Unified Process Scrum Crystal Clear Extreme Programming Adaptive Software Development Feature Driven Development

Scrum Iterative process of development used with agile software development. Roles in Scrum are the ScrumMaster, the Product Owner and the Team. During each sprint the team creates an increment of potential shippable software Set of features that go into each sprint come from the product backlog A sprint is a set period of time during which specific work has to be completed and made ready for review.

Scrum (..Contd) Which backlog items go into the sprint is determined during the sprint planning meeting. The team then determines how much of this they can commit to complete during the next sprint. During the sprint, no one is able to change the sprint backlog.

What is a Backlog? A backlog is the master list of all functionality Features Epics Stories Requirements Bugs Item Attributes: Description Cost estimate (points or size) Business Value Priority

Product Backlogs vs. Sprint Backlogs A Product Backlog is the master list of all functionality for the product Features Epics Bugs The Sprint Backlog is the list of functionality that the team is committing to complete in the current iteration Storied Requirements Product Management / Owner owns the backlogs

Agile Planning Beginning of iteration Review vision and roadmap Review development status, architecture and previous iterations Determine velocity Review team availability & capacity Review definition of done Review product backlog & select items for iteration / sprint Identify tasks & estimates Identify challenges & risks Review capacity required COMMIT (planning not over until entire team commits to sprint plan) Velocity Velocity is a method for measuring the rate at which teams consistently deliver business value. To calculate velocity, simply add up the estimates of the items successfully delivered an iteration Definition of done Is a checklist of valuable activities required to produce software The team defines definition of done for each iteration, feature, requirement task, etc. Typically Software working? Unit tests written? Code review done? Functional tests written and passed? Non-functional tests written and passed? User documentation done and reviewed? Design documentation updated and reviewed? Release notes updated?

Agile Reports Product / Sprint / Iteration Backlog Release Burn-up chart (to show % complete) Defects – inflow, outflow, # of open defects per week Build quality per day/week Number of tests / tests passed per day/week Velocity over the last x sprint Action items, risks Burndown Charts (to show remaining effort)

Agile Retrospectives Meeting after an increment of work to inspect and adapt their methods and teamwork What went well, What could be improved Team learning Catalyst for change Generate action Sample Agenda Overview Gather data Prioritize Discuss Action Items

Agile Methodologies Feature-driven Development (rare) an iterative development process. This practice is driven from a client-valued functionality (feature) perspective. Test-driven Development (rare) is a software development technique that uses short development iterations based on pre-written test cases that define desired improvements or new functions. Each iteration produces code necessary to pass that iteration's tests.

Agile Methodologies Lean (rare) is a process designed to eliminate waste, amplify learning, make decisions late, fast delivery, empowered teams, product integrity and an fully understood system.

Thank You