Agile Models

8/8/2019
1
 What is Agile Software Development?
• Agile: Easily moved, light, nimble, active software
processes

• How agility achieved?

– Fitting the process to the project

– Avoidance of things that waste time

2
 Agile Model
• To overcome the shortcomings of the waterfall model of
development.
– Proposed in mid-1990s
• The agile model was primarily designed:
– To help projects to adapt to change requests
• In the agile model:
– The requirements are decomposed into many small incremental parts
that can be developed over one to four weeks each.

3
 Ideology: Agile Manifesto
• Individuals and interactions over
– process and tools
• Working Software over
– comprehensive documentation
• Customer collaboration over
– contract negotiation
• Responding to change over http://www.agilemanifesto.org

– following a plan

4
• XP Agile Methodologies
• Scrum
• Unified process
• Crystal
• DSDM
• Lean

5
 Agile Model: Principal Techniques
• User stories:
– Simpler than use cases.
• Metaphors:
– Based on user stories, developers propose a common vision of what is
required.
• Spike:
– Simple program to explore potential solutions.
• Refactor:
– Restructure code without affecting behavior, improve efficiency, structure, etc.

6
• At a time, only one increment is planned, developed,
deployed at the customer site.
Agile Model: Nitty Gritty
– No long-term plans are made.

• An iteration may not add significant functionality,

– But still a new release is invariably made at the end of each
iteration

– Delivered to the customer for regular use.

7
 Methodology
• Face-to-face communication favoured over written
documents.
• To facilitate face-to-face communication,
– Development team to share a single office space.
– Team size is deliberately kept small (5-9 people)
– This makes the agile model most suited to the development of
small projects.

8
 Face-to-face
at whiteboard
Effectiveness of Face-to-face
conversation
Communication Modes
Communication Effectiveness

Video
conversation
Modeling
Phone Options
conversation

Videotape
Email
conversation

Audiotape
Documentation
Options
Paper

Cold Hot
Richness of Communication Channel
Copyright 2002-2005 Scott W. Ambler
Original Diagram Copyright 2002 Alistair Cockburn

9
 Agile Model: Principles
• The primary measure of progress:
– Incremental release of working software
• Important principles behind agile model:
– Frequent delivery of versions --- once every few weeks.
– Requirements change requests are easily accommodated.
– Close cooperation between customers and developers.
– Face-to-face communication among team members.

10
• Travel light: Agile Documentation
– You need far less documentation than you think.
• Agile documents:
– Are concise
– Describe information that is less likely to change
– Describe “good things to know”
– Are sufficiently accurate, consistent, and detailed
• Valid reasons to document:
– Project stakeholders require it
– To define a contract model
– To support communication with an external group
– To think something through

11
 Agile Software Requirements Management
High
{ Each iteration implement the highest-
Priority priority requirements

Each new requirement is

prioritized and added to
the stack

Requirements may be
reprioritized at any time

Requirements may be
removed at any time

Low
Priority
Requirements Copyright 2004 Scott W. Ambler

12
 Adoption Detractors
• Sketchy definitions, make it possible to have
– Inconsistent and diverse definitions
• High quality people skills required
• Short iterations inhibit long-term perspective
• Higher risks due to feature creep:
– Harder to manage feature creep and customer expectations
– Difficult to quantify cost, time, quality.

13
 Agile Model Shortcomings
• Derives agility through developing tacit knowledge
within the team, rather than any formal document:
– Can be misinterpreted…
– External review difficult to get…
– When project is complete, and team disperses,
maintenance becomes difficult…

14
 Agile Model versus Iterative Waterfall Model
• The waterfall model steps through in a planned sequence:
– Requirements-capture, analysis, design, coding, and testing .
• Progress is measured in terms of delivered artefacts:
– Requirement specifications, design documents, test plans, code
reviews, etc.
• In contrast agile model sequences:
– Delivery of working versions of a product in several increments.

15
 Agile Model versus Iterative Waterfall Model

• As regards to similarity:
– We can say that Agile teams use the waterfall
model on a small scale.

16
 Agile versus RAD Model
• Agile model does not recommend developing
prototypes:
– Systematic development of each incremental feature
is emphasized.
• In contrast:
– RAD is based on designing quick-and-dirty prototypes, which
are then refined into production quality code.

17
 Agile versus exploratory programming
• Similarity:
– Frequent re-evaluation of plans,
– Emphasis on face-to-face communication,
– Relatively sparse use of documents.
• Agile teams, however, do follow defined and disciplined
processes and carry out rigorous designs:
– This is in contrast to chaotic coding in exploratory programming.

18
 Extreme Programming
(XP)

8/8/2019
19
 Extreme Programming Model
• Extreme programming (XP) was proposed by Kent
Beck in 1999.
• The methodology got its name from the fact that:
– Recommends taking the best practices to extreme
levels.
– If something is good, why not do it all the time.

20
• If code review is good: Taking Good
– Always review --- pair programming Practices to Extreme
• If testing is good:
– Continually write and execute test cases --- test-driven
development
• If incremental development is good:
– Come up with new increments every few days
• If simplicity is good:
– Create the simplest design that will support only the
currently required functionality.

21
 Taking to Extreme
• If design is good,
– everybody will design daily (refactoring)

• If architecture is important,
– everybody will work at defining and refining the architecture
(metaphor)

• If integration testing is important,

– build and integrate test several times a day (continuous integration)

22
• Communication: 4 Values
– Enhance communication among team members and with the
customers.
• Simplicity:
– Build something simple that will work today rather than something that
takes time and yet never used
– May not pay attention for tomorrow
• Feedback:
– System staying out of users is trouble waiting to happen
• Courage:
– Don’t hesitate to discard code

23
 Best Practices
• Coding:
– without code it is not possible to have a working system.
– Utmost attention needs to be placed on coding.
• Testing:
– Testing is the primary means for developing a fault-free product.
• Listening:
– Careful listening to the customers is essential to develop a good quality
product.

24
• XP Planning an increment
• Begins by creating “user stories”
• Agile team assesses each story and assigns a cost Extreme
• Few stories are grouped into a deliverable increment Development
• Delivery date planned Activities
• XP Design
• Follows the KIS principle
• Encourage the use of CRC cards
• For difficult design problems, suggests the creation of “spike solutions”—a
design prototype
• Encourages “refactoring”—refinement of the internal program design

25
• XP Coding
• Recommends the construction of unit test cases before coding
commences (test-driven development)
Extreme
• Encourages “pair programming” Program
• XP Testing Development
Activities
• All unit tests are executed daily
• “Acceptance tests” are defined by the customer and executed to assess
customer visible functionalities

26
 Full List of XP Practices
1. Planning – determine scope of the next release by combining business priorities and
technical estimates

2. Small releases – put a simple system into production, then release new versions in very
short cycles

3. Metaphor – all development is guided by a simple shared story of how the whole
system works

4. Simple design – system is to be designed as simple as possible

5. Testing – programmers continuously write and execute unit tests

27
 Full List of XP Practices
7. Refactoring – programmers continuously restructure the system
without changing its behavior to remove duplication and simplify
8. Pair-programming -- all production code is written with two
programmers at one machine
9. Collective ownership – anyone can change any code anywhere in
the system at any time.
10. Continuous integration – integrate and build the system many
times a day – every time a task is completed.

28
 Full List of XP Practices

11. 40-hour week – work no more than 40 hours a week as a rule

12. On-site customer – a user is a part of the team and available full-
time to answer questions

13. Coding standards – programmers write all code in accordance with

rules emphasizing communication through the code

29
 Emphasizes Test-Driven Development (TDD)
• Based on user story develop test cases
• Implement a quick and dirty feature every couple of days:
– Get customer feedback
– Alter if necessary
– Refactor
• Take up next feature

30
 Project Characteristics that Suggest Suitability
of Extreme Programming
• Projects involving new technology or research projects.
– In this case, the requirements change rapidly and unforeseen
technical problems need to be resolved.

• Small projects:
– These are easily developed using extreme programming.

31
 Practice Questions
• What are the stages of iterative waterfall model?
• What are the disadvantages of the iterative waterfall model?
• Why has agile model become so popular?
• What difficulties might be faced if no life cycle model is
followed for a certain large project?

32
 Suggest Suitable Life Cycle Model
• A software for an academic institution to automate its:
– Course registration and grading
– Fee collection
– Staff salary
– Purchase and store inventory
• The software would be developed by tailoring a similar software
that was developed for another educational institution:
– 70% reuse
– 10% new code and 20% modification

33
 Practice Questions
• Which types of risks can be better handled using the spiral
model compared to the prototyping model?
• Which type of process model is suitable for the following
projects:
– A customization software
– A payroll software for contract employees that would be add on
to an existing payroll software

34
 Practice Questions
• Which lifecycle model would you select for the following project
which has been awarded to us by a mobile phone vendor:
– A new mobile operating system by upgrading the existing operating
system
– Needs to work well efficiently with 4G systems
– Power usage minimization
– Directly upload backup data on a cloud infrastructure maintained by the
mobile phone vendor

35
Scrum

36
 Scrum: Characteristics
• One of the agile processes

• Self-organizing teams

• Product development progresses in a series of month-long

sprints

• Requirements are listed in a product backlog

37
 Daily
Scrum
Sprint Sprint
planning review
Scrum
Sprint
Product backlog backlog Product
increment

38
 Sprint
• Scrum projects progress in a series of “sprints”
– Analogous to XP iterations or time boxes
– Target duration is one month
• Software increment is designed, coded, and
tested during a sprint
• No changes entertained during a sprint
39
 Sprint
• Fundamental process flow of Scrum

• A month-long iteration, during which an incremental product

functionality completed

• NO outside influence can interfere with the Scrum team during

the Sprint

• Each day begins with the Daily Scrum Meeting

40
 Scrum Framework
• Roles : Product Owner, ScrumMaster, Team

• Ceremonies : Sprint Planning, Sprint Review, Sprint

Retrospective, and Daily Scrum Meeting

• Artifacts : Product Backlog, Sprint Backlog, and Burndown

Chart

41
 Key Roles and Responsibilities in Scrum Process
• Product Owner
– Acts on behalf of customers to represent their interests.
• Development Team
– Team of five to nine people with cross-functional skill sets.
• Scrum Master (aka Project Manager)
– Facilitates scrum process and resolves impediments and acts as a
buffer between the team and outside interference.

42
 Product Owner
• Defines the features of the product
• Decides on release date and content
• Prioritizes new features
• Adjusts features and priority every iteration, as needed
• Accepts or rejects work results.

43
 The Scrum Master
• Represents management
• Removes impediments
• Ensures that the team is fully functional and
productive
• Shield the team from external interferences

44
 Scrum Team
• Typically 5-10 people
• Cross-functional
– QA, Programmers, UI Designers, etc.
• Teams are self-organizing
• Membership can change only between sprints

45
 Ceremonies
• Sprint Planning Meeting

• Daily Scrum

• Sprint Review Meeting

46
 Sprint Planning
•Goal is to produce Sprint Backlog
•Product owner works with the Team to negotiate what
Backlog Items the Team will work on in order to meet
Release Goals

•Scrum Master ensures Team agrees to realistic goals

47
• Daily
• 15-minutes
• Stand-up meeting Daily Scrum
• Not for problem solving
• Three questions:
1. What did you do yesterday
2. What will you do today?
3. What obstacles are in your way?

48
• Is NOT a problem solving session Daily Scrum
• Is NOT a way to collect information about WHO is behind the
schedule

• Is a meeting in which team members make informal

commitments to each other and to the Scrum Master

• Is a good way for a Scrum Master to track the progress of the

Team

49
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features
• Informal
– 2-hour prep time rule Sprint Review
• Participants Meeting
– Customers
– Management
– Product Owner
– Other teammates

50
 Product Backlog
• A list of all desired work on the project

– Usually a combination of
• story-based work (“allow user to search and replace”)

• task-based work (“improve exception handling”)

• List is prioritized by the Product Owner.

51
 Product Backlog
• Requirements for a system, expressed as a prioritized list
of Backlog Items

– Managed and owned by Product Owner

– Spreadsheet (typically)

52
Sample
Product
Backlog

53
 Sprint Backlog
• A subset of Product Backlog Items, which define the work
for a Sprint

– Created by Team members

– Each Item has it’s own status

– Updated daily

54
 Sprint Backlog during the Sprint
• Changes occur:
– Team adds new tasks whenever they need to in order to meet
the Sprint Goal
– Team can remove unnecessary tasks
– But: Sprint Backlog is only updated by the team

• Estimates are updated whenever there’s new information

55
 Burn down Charts
• Are used to represent “work done”.
• Are remarkably simple but effective Information
disseminators
• Three Types:
– Sprint Burn down Chart (progress of the Sprint)
– Release Burn down Chart (progress of release)
– Product Burn down chart (progress of the Product)

56
 Sprint Burn down Chart
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to complete
• Ideally should burn down to zero to the end of the Sprint
• Usually is not a straight line

57
Sprint Burndown Chart

58
 Release Burndown Chart
• Will the next release be done on right time?

• How many more sprints?

• X-axis: sprints

• Y-axis: amount of story

points remaining

59
 Product Burndown Chart
• Is a “big picture” view of project’s progress (all the releases)

60
 Scalability of Scrum
• A typical Scrum team is 6-10 people

• Jeff Sutherland proposed and experimented with

up to over 800 people

• "Scrum of Scrums" also called "Meta-Scrum“

61
Requirements Analysis and Specification

RAJIB MALL
Computer Science and Engineering Department
IIT KHARAGPUR

62
 What are Requirements?
• A Requirement is:
– A capability or condition required from the system.
• What is involved in requirements analysis and specification?
– Determine what is expected by the client from the system. (Gather
and Analyze)
– Document those in a form that is clear to the client as well as to the
development team members. (Document)
 Understanding and specifying requirements
For toy problems: understanding and specifying requirements is
rather easy…
For industry-standard problems: Probably the hardest, most
problematic and error prone among development tasks…
The task of requirements specification :
Input: User needs that are hopefully fully understood by the users.

Output: Precise statement of what the software will do.

 Requirements for Products

• When a company plans to develop a generic product:

– Who gives the requirements?

• The sales personnel!

 Activities in Requirements Analysis and Specification

Requirements Gathering

Requirements Analysis

Requirements Specification

SRS Document
 Requirements Engineering Process
Feasibility
Study Requirements
gathering
Requirements
analysis
Feasibility Requirements
report specification

SRS Document
 Requirements Analysis and Specification
• Requirements Gathering:
– Fully understand the user requirements.
• Requirements Analysis:
– Remove inconsistencies, anomalies, etc. from requirements.
• Requirements Specification:
– Document requirements properly in an SRS document.
• Good SRS reduces development cost:
– Req. errors are expensive to fix later Need for SRS…
– Req. changes cost a lot (typically 40% of requirements change later)

– Good SRS can minimize changes and errors

– Substantial savings --- effort spent during req. saves multiple times that effort

• An Example:

Cost
– Cost of fixing errors in req. , design , coding , acceptance
testing and operation increases exponentially
• Establishes the basis for agreement between the
customers and the suppliers What are the Uses of
an SRS Document?
• Forms the starting point for development.
• Provide a basis for estimating costs and schedules.
• Provide a basis for validation and verification.
• Provide a basis for user manual preparation.
• Serves as a basis for later enhancements.
 Forms A Basis for User Manual
• The SRS serves as the basis for writing User Manual for the
software:

– User Manual: Describes the functionality from the perspective

of a user --- An important document for users.

– Typically also describes how to carry out the required tasks with
examples.
 SRS Document: Stakeholders
• SRS intended for a diverse audience:
– Customers and users use it for validation, contract, ...
– Systems (requirements) analysts
– Developers, programmers to implement the system
– Testers use it to check whether requirements have been met
– Project Managers to measure and control the project
• Different levels of detail and formality is needed for each audience
• Different templates for requirements specifications used by companies:
– Often variations of IEEE 830
User needs Requirement process..

Gathering
• Specification and
Analysis
review may lead to
Specification further gathering
Review
and analysis.
SRS Document
 Faculty Name
Department Name 74