SOFTWARE ENGINEERING

UNIT 1.3
VARIOUS AGILE FRAMEWORKS

HETAL CHUDASAMA,
DEPARTMENT OF INFORMATIN TECHNOLOGY,
GCET.

1
DIFFERENT AGILE FRAMEWORKS

Extreme Programming (XP)

Scrum
Crystal
Agile Modeling (AM)
Dynamic Systems Development Method (DSDM)
Feature Driven Development (FDD)
Adaptive Software Development (ASD)
2
EXTREME PROGRAMMING (XP)

 One of the most important software development frameworks of Agile (flexible)models, introduced
by Kent beck.
 Extreme programming is, in a nutshell, about good practices taken to an extreme.
 It is lightweight, efficient, low-risk, flexible, predictable, scientific, fun oriented way to develop a
software.
 It targets speed and simplicity with short development cycles and less documentation.
 It is used to improve software quality and responsiveness to customer requirements.
 XP roles (Customers, Programmer, Testers, Tracker, Coach )
 The process structure is determined by five guiding values, five rules, and 12 XP practices
3
 A variant of XP, Industrial XP(IXP) refines XP for large organization.
EXTREME PROGRAMMING
CONCEPTUALIZATION

 Help small teams work with changing requirements

 Introduce idea of writing tests before coding
 It is better to pair while coding
 Build something simple that works and then enhance further
 All team members should collaborate
 Imbibe values such as communication, simplicity, feedback, courage and respect
 It incorporates Object Oriented Approach.
4
EXTREME PROGRAMMING
5 VALUES

 Simplicity : Start developing the important and needed features first without worrying about
future requirements, we should move to the problematic and extra functionalities later on.
Keep the design of the system as simple as possible so that it is easier to maintain, support,
and revise.
 Communication : It focuses on excellent communication and collaboration with stakeholders
and within team members. It bridges the gaps between what the developer is making and
the customer requirement.
 Feedback : Constant feedback, from system , customer, and team members, about previous
efforts, can identify areas for improvement and make necessary adjustments to processes.
Frequent releases gains early and often insights.
 Respect : Everyone respects each other.
 Courage : Giving and accepting feedback, providing realistic estimates, even if stakeholders
don't like the truth, requires courage. 5
EXTREME PROGRAMMING PROCESS MODEL

6
EXTREME PROGRAMMING FRAMEWORK ACTIVITY 1
PLANNING
 Planning activities or planning game
 Listening(requirement gathering)
 User stories (Users describes required functionalities of the software that is to be built)
 Values(Users will also assign priority number) and place in Index card.
 Cost(measured in development weeks)
 High cost → Split the stories, re-assignment of values and costs.
 Commitment(agreement by Customer and developers on stories to be included, release date and other project
matter)
 Release(s/w increment that cover a small part of the functionality or features required ),
 XP team then orders stories that are to be develop.
 Story development Ordering (All stories immediately, Higher value stories first, riskiest stories first)
 Iteration plan (plans about what functionalities to be completed in how much time in every iteration and total number
of iterations)
 Project velocity (Computes number of customer stories implemented in first release)
 Acceptance test (Eligibility criteria for acceptance of software during deployment).
7
 Stories can be added ,change in values assigned to existing stories, split stories or eliminate some stories
 Reconsideration and modification of plan accordingly
Planning activities or planning game
Listening(requirement gathering)
Team members will communicate and collaborate with stakeholders to get
user stories (Users describes required functionalities of the software that is to be built).
Users will also assign values(priority number) to the user stories and will be placed into index card.
XP Team will then assess each stories and assign some cost(measured in development weeks) after
examining the user stories.
In case of higher cost, customers are requested to split the stories, re-assignment of values and costs.
After basic commitment(agreement by Customer and developers on stories to be included, release
date and other project matter) for a release(s/w increment that cover a small part of the functionality
or features required ), XP team then orders stories that are to be develop.
Team generates Iteration plan (plans about What functionalities to be completed in how much time in
every iteration and total number of iterations) from user stories.
After releasing s/w , computes project velocity (number of customer stories implemented in first
release) that helps in deciding delivery date and schedule plan for the subsequent releases,
modification in planning if there is over commitment.
They will also plan acceptance test (Eligibility criteria for acceptance of software during deployment).
As the process progress, user may go on adding new stories and they may also keep changing the
assigned values of the existing stories, split stories or eliminate some stories
8
EXTREME PROGRAMMING FRAMEWORK ACTIVITY 2
DESIGN

 Simplicity without compromising performance, accuracy or efficiency and without excluding core
functionality.
 CRC card Class Responsibility Collaborator(to think about your project in terms of object-oriented
context and tries to identify and organize the classes that are related to current software increment)
 CRC cards are the only design work product produced as a part of process.
 Spike solutions (operational prototype for that much portion of design is to created immediately in
case of difficult design problem)
 It helps in performing risk analysis, exploring different aspects before implementation starts.
 Refactoring (trying to optimize the design by improving internal structure of the design without
affecting its external behavior or functionalities, minimizes the chances of introducing bugs)
9
XP value of simplicity will be rigorously followed.
Simple design (Keep It Simple) without compromising performance, accuracy or efficiency and
without excluding core functionality.
Most immediate or prioritized requirements are to be implemented first in simplest possible way
by eliminating extra functionality which are not needed right now.
CRC card Class Responsibility Collaborator(to think about your project in terms of object-
oriented context and tries to identify and organize the classes that are related to current software
increment) is like a card with class(has some objects who have to perform assigned tasks ),
responsibilities (task assigned) and collaborator (to work together with other objects to perform
assigned task or complete the responsibilities).
CRC cards are the only design work product produced as a part of process.
In case of difficult design problem, spike solutions (operational prototype for that much portion of
design is to created immediately) are created, implemented and evaluated.
It helps in performing risk analysis, exploring different aspects before implementation starts.
Refactoring (trying to optimize the design by improving internal structure of the design without
affecting its external behavior or functionalities)

10
EXTREME PROGRAMMING FRAMEWORK ACTIVITY 3
CODING
 Unit tests (every individual units gets tested for their functionality and feedback)
 Developing unit tests → coding (code must pass that respective unit test to meet the user stories.)
 Pair programing (One person tries to do the proper coding and other member ensures coding
standards, examines the code to provide the assurance that it will pass the unit test, successful
implementation of user stories.)
 Provides real-time problem solving and real-time quality assurance.
 Continuous integration(combing work done by different teams) to avoid compatibility interfacing
problems.
 Smoke testing (helps to uncover error early)
 Applying developed unit tests after coding provides immediate response from software to developer
 Collective Code Ownership (Each team member can change or refactor any part of the code) 11

 40-Hour Work Week (No overtime) , Design occurs both before and after coding.
Before start with the coding, XP team develops a series of unit tests(every individual units gets
tested for their functionality and feedback) to validate the code against the stories included in that
release.
After developing unit tests, team start coding with keeping in mind that the code must pass that
respective unit test to meet the user stories.
Pair programing : One person tries to do the proper coding and other member examines the code
to provide the assurance that it will pass the unit test, successful implementation of user stories. So,
it does real time problem solving and quality assurance.
Continuous integration(combing work done by different teams) will help to avoid combability
interfacing problems.
Applying already developed unit tests after coding will provide immediate response from software to
developer
XP encourages Refactoring : a design technique that improves the internal structure of the code by
removing some complexities, but external behaviors remains unaffected minimizes the chances of
introducing bugs.
Design occurs both before and after coding.

12
EXTREME PROGRAMMING FRAMEWORK ACTIVITY 4
TESTING

 Automated Unit test

 Continuous integration testing (After integrating all units, do they interact properly)
 System testing
 Regression testing strategy
 Acceptance testing or customer test (derived form the user stories and specified by the customer
only, focuses on overall features and functionalities of the system and to check for users'
requirements get fulfilled or not.)
 Integration and validation testing on daily basis.
 Fixing small problems every hour, will take less time than fixing huge problem just before deadline.
13
Continuous integration testing: After integrating all units, do they integrate properly
System testing
Unit test created should be automated which encourages regression testing strategy whenever code is
modified on daily basis.
Acceptance testing or customer test : derived form the user stories and specified by the customer
only, focuses on overall features and functionalities of the system and to check for users requirements
get fulfilled or not.
Fixing small problems every hour, will take less time then fixing huge problem just before deadline.
After getting users feedback software will be ready for next increment.

14
EXTREME PROGRAMMING
ADVANTAGES DISADVANTAGES
Advantages
 Fewer documents
 Collaboration with customers Disadvantages
 Flexibility to developers  Depend heavily on customer interaction
 Easy to manage  Transfer of technology to new team is
 Faster release of working software quite complected due to lack of
documents.
 Visible and accountable
 Code overcomes design
 Less risky
 Constant feedback
 Employee satisfaction and retention
 Supports teamwork 15

 Small team (4-8 people)

SCRUM

 One of the frameworks using which we can implement agile is SCRUM.

 The name has been derived from an activity that occurs during a rugby match, like wise a scrum can be
characterized by developers putting their heads together to address complex problems.
 Lightweight, iterative and incremental model
 Used not only in IT sector but also in research, sales, marketing, banking, pharmaceutical sector also.
 Widely used or adopted model at present.
 Breaks down the development phases into stages or cycle called “sprint”. (to complete work in limited time
duration of 2 weeks to 1 month)
 Once a sprint gets complete, it will get reviewed by stakeholder through meetings, all the suggestions and changes
to be included in next sprint.
 5 core values are commitment, courage, focus, openness, respect. 16
Product
backlog
refinement

1 scrum team

Potentially
Iterative-Incremental shippable product
Development & delivery increment

17
SCRUM ARTIFACTS

 Scrum Teams use tools called Scrum artifacts to solve problems and manage projects.
 The Product Backlog is dynamic and prioritized list of features, requirements, enhancements, and fixes that
must be completed for project success. It is essentially the team’s to-do list, which is constantly revisited and
reprioritized to adapt to market changes. The product owner maintains and updates the list, removing irrelevant
items or adding new requests from customers.
 The Sprint Backlog is the list of items to be completed by the development team in the current Sprint cycle.
Before each Sprint, the team chooses which items it will work on from the Product Backlog. A Sprint Backlog is
flexible and can evolve during a Sprint.
 The Increment is a step towards a goal or vision. It is the usable end product from a Sprint. Teams can adopt
different methods to define and demonstrate their Sprint Goals. It produces potentially Shippable product
increment.

18
SCRUM ROLES

 A Scrum Team needs three specific roles: a Product Owner, Scrum leader, and development team.
 The Product Owner gathers the requirements form customers and provides it to developers.
 focuses on ensuring the development team delivers the most value to the business.
 They understand and prioritize the changing needs of end users and customers.
 Effective product owners do the following:
• Give the team clear guidance on which features to deliver next.
• Bridge the gap between what the business wants and what the team understands.
• Decide when and how frequently releases should happen.

19
SCRUM ROLES

 Scrum masters are responsible for managing entire scrum working.

 Also responsible for doing the following:
• Schedule the resources needed for each Sprint.
• Facilitate other Sprint events and team meetings.
• Lead digital transformation within the team.
• Facilitate any team training when adopting new technologies.
• Communicate with external groups to solve any challenges the team might be facing.

20
SCRUM ROLES

 The Scrum Team (6-8 people) consists of testers, designers, UX specialists, Ops engineers, and developers.
 Team members have different skill sets and cross-train each other, so no one person becomes a bottleneck
in delivering work.
 Scrum development teams do the following:
• Work collaboratively to ensure a successful Sprint completion.
• Champion sustainable development practices.
• Self-organize and approach their projects with an evident we attitude.
• Drive the planning and estimating for how much work they can complete for each Sprint.

21
SCRUM EVENTS

 Scrum events or Scrum ceremonies are a set of sequential meetings that Scrum Teams perform regularly.
 Sprint Planning
 In this event, the team estimates the work to be completed in the next Sprint. Members define Sprint Goals that
are specific, measurable, and attainable. At the end of the planning meeting, every Scrum member knows how
each Increment can be delivered in the Sprint.
 Sprint
 A Sprint is the actual time period when the Scrum Team works together to finish an Increment. Two to four weeks
is the typical length for a sprint. The more complex the work and the more unknowns, the shorter the Sprint
should be.

22
SCRUM EVENTS
 Daily Scrum or stand-up
 A Daily Scrum is a short meeting in which team members check in and plan for the day. They report on work
completed and voice any challenges in meeting Sprint Goals. It is called a stand-up because it aims to keep the
meeting as short as practical—like when everybody is standing.
 Sprint Review
 At the end of the Sprint, the team gets together for an informal session to review the work completed and
showcase it to stakeholders. The Product Owner might also rework the Product Backlog based on the current
Sprint.
 Sprint Retrospective
 The team comes together to document and discuss what worked well and what didn’t work during the Sprint,
what could be improved and what we will commit to include in the next sprint. These Ideas generated are used
to improve future Sprints.

23
SCRUM BOARD

24
SCRUM
ADVANTAGES DISADVANTAGES
Advantages Disadvantages

 Freedom and adaptation

 High-quality, low-risk product  Efficient for small size team only

 Reduced development time up-to 40%  No changes in current sprint

 High rate of Customer satisfaction

25
ADAPTIVE SOFTWARE DEVELOPMENT (ASD)

1. Speculation 2. Collaboration 3. Learning

 Proposed by Jim Highsmith

 Technique to built complex software system using
iterative approach.
 Focuses on human collaboration and team
self-organization.
 ASD life cycle incorporates three phases :
speculation, collaborating, and learning.

26

ASD Life cycle

ASD LIFE CYCLE

ASD LIFE CYCLE PHASES

Speculation Collaborating Learning

• Adaptive cycle planning • Recurring step • Learning should be

• ACP uses project initiation • Enhances talent & creativity emphasized as much as
information to define set of • Encompasses progress toward completion.
release cycles. communication & teamwork • ASD team learns in three
• (customer’s mission statement, • Emphasize individualism ways: focus groups, technical
project constraints, and • Trust each other to reviews, and project
• basic requirements) • criticize, assist, hard work, postmortem.
• Always adopts changes. skill set contribution,
• Information obtained on problem or concern
completion of life cycle is used discussion effectively.
to review and adjust the plan
to better fit the planned work
in reality. 27
DYNAMIC SYSTEM DEVELOPMENT METHOS (DSDM)

 Agile software development framework approach.

 For systems which meets tight time constraints through incremental prototyping approach.
 It is modified version of Pareto principle – 80% of an application can be delivered in 20% of the time it
would take to deliver thee complete(100%) application.
 It is an iterative software process in which each iteration follows the 80% rule.
 Only enough work is required for each increment to facilitate movement to the next iteration.
 Remaining details can be added later in case of more business requirements or changes requested.

28
DSDM LIFE CYCLE
DSDM life cycle defines three different iterative cycles, preceded by two additional life cycle activities.
Business study
Feasibility study
Functional and information
Basic requirements
requirements to provide
Constraints,
business value,
Assesses viability
Application architecture
Maintainability requirement

Functional model iteration Design and build iteration Implementation

Set of incremental prototypes
(deliverable applications),
Additional requirements during
iterative cycles through users’
feedback during prototype
exercise.
Revisits already built protype
in FMI to ensure that it
provides operational business
value for end users.
FMI and DBI may occurs
concurrently
Latest software increment into
operational environment,
Continue working with FMI
incase of, increment is not
100% complete or changes
requested by users. 29
FEATURE DRIVEN DEVELOPMENT (FDD)
 Originally conceived by Peter Coad and extended
by Stephen Palmer and John Felsing.
 Adaptive agile process that can be applied to
moderately sized and larger software projects.  Client-valued function implemented in two weeks or less.

 Adopted philosophy:  Benefits of emphasis on definition of features (small blocks

of deliverable software increment with functionality):
 Emphasize collaboration among FDD team
members.  Users can describe features, relevance and review, more
easily
 Manage problem and project complexity through
divide and conquer approach.  Hierarchical business-related grouping organization of
features
 Communicating technical details through verbal,
graphical, and text-based means.  Team develops operational features every two weeks

 Emphasize software quality assurance through :  Design and code representation of features are easier to
incremental development strategy, design and code inspect effectively. 30

inspection, software quality assurance audits,  Project planning, scheduling, and tracking are driven by
collection of metrics, and use of patterns. feature hierarchy.