1. Agile SDLC Methodology

2. 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.

3. 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

4. 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

5. 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)

6. 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

7. 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

8. Agile SDLC

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

10. Components of Agile MethodologyNo
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

11. 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.

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

13. 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

14. 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

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

16. 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.

17. 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.

18. 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

19. 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

20. 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?

21. 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)

22. 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

23. 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.

24. 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.

25. Thank You