SOFTWARE ENGINEERING

Slide Set 03: An Agile view of Process

An Agile View of Process 1

 Agility
• Effective response to change.
• Effective communication among all stakeholders.
• Drawing the customer onto the team; eliminate the “us and them”
attitude.
• Organizing a team so that it is in control of the work performed.
• Rapid, incremental delivery of software.

An Agile View of Process 2

 Principles to achieve agility – by the Agile
Alliance
1. Highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.
7. Working software is the primary measure of progress

An Agile View of Process 3

8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely.
9. Continuous attention to technical excellence and good design
enhances agility
10. Simplicity--the art of maximizing the amount of work not done--is
essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.The team tunes and adjusts its behavior to become
more effective
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.

An Agile View of Process 4

 Agile Software Process – Three Key
Assumptions
• Difficulty in predicting changes of requirements and customer
priorities.
• For many types of s/w, design and construction are interleaved
• Analysis, design, construction, and testing are not as predictable as
we assume.

An Agile View of Process 5

 Agile Software Process
• An agile process must be adaptable
• It must adapt incrementally.
• Requires customer feedback
• An effective catalyst for customer feedback is an operational
prototype.

An Agile View of Process 6

 Human Factor(Better way to achieve agile)
• Key point:
• The Process molds to the needs of the people and team, not the
other way around.
• A number of key traits must exist among the people on an agile team
and the team itself
• Competence
• Common focus
• Collaboration
• Decision-making ability
• Fuzzy problem-solving ability
• Mutual trust and respect
• Self-organization

An Agile View of Process 7

 Agile Process Model
• Extreme Programming (XP)
• Adaptive Software Development (ASD)
• Dynamic Systems Development Method (DSDM)
• Scrum
• Feature Driven Development (FDD)
• Agile Modeling (AM)

An Agile View of Process 8

 Extreme Programming
• The most widely used agile process, originally proposed by Kent
Beck.
• XP uses an object-oriented approach as its preferred development
paradigm.
• Defines four (4) framework activities
• Planning
• Design
• Coding
• Testing

An Agile View of Process 9

Figure 4.1: Extreme Programming

An Agile View of Process 10

 XP-Planning
• Begins with the creation of a set of stories (also called user stories) describes
features and functionalities for software to be developed.
• Each story is written by the customer and is placed on an index card.
• The customer assigns a value (i.e. a priority) to the story based on overall
business values of feature or functions.
• Agile team assesses each story and assigns a cost.
• Stories are grouped to form a deliverable increment
• A commitment is made on delivery date
• After the first increment “project velocity” is used to help define subsequent
delivery dates for other increments.
• Customer can add stories, change value of stories ,split stories or eliminate
them. XP team then reconsider all remaining release and modify its plan
accordingly.
An Agile View of Process 11
 XP-Design
• Follows the KIS (keep it simple) principle
• Encourage the use of CRC (class-responsibility-collaborator)
cards for thinking about software in object oriented context
• For difficult design problems, suggests the creation of “spike
solutions”—a design prototype
• Encourages “refactoring”—an iterative refinement of the internal
program design
• Design occurs both before and after coding commences

An Agile View of Process 12

 XP-Coding
• Recommends the construction of a series of unit tests for each of
the stories before coding commences
• Encourages “pair programming”
• Mechanism for real-time problem solving and real-time quality
assurance
• Keeps the developers focused on the problem at hand
• Needs continuous integration with other portions (stories) of the
s/w, which provides a “smoke testing” environment

An Agile View of Process 13

 XP-Testing
• Unit tests should be implemented using a framework to make
testing automated. This encourages a regression testing strategy.

• Integration and validation testing can occur on a daily basis

• Acceptance tests, also called customer tests, are specified by the

customer and executed to assess customer visible functionality

• Acceptance tests are derived from user stories

An Agile View of Process 14

 Adaptive Software Development (ASD)
• Self-organization arises when independent agents cooperate to
create a solution to a problem that is beyond the capability of any
individual agent (for building complex software and system)
• Adaptive cycle characteristics
• Mission-driven planning
• Uses “time-boxing”
• Explicit consideration of risks
• Emphasizes collaboration for requirements gathering
• Emphasizes “learning”

An Agile View of Process 15

Figure 4.2:Adaptive Software Development

An Agile View of Process 16

Speculation:
• The project is initiated and adaptive cycle planning is conducted.
• Information about customer mission statement, project constraints (e.g
delivery date, or user description) and its basic requirements –to define
set of release requirements )that will be required for the project,.
Collaboration:
• People working together must have trust one anther to
• Criticize without animosity
• Assist without resentment
• Work as hard or harder as they do
• Have skill set to contribute to work at hand
• Communicate problem that leads to effective actions

An Agile View of Process 17

Learning
• ASD team learn in 3 ways
• Focus group: customer and end user provide feedback on
software increment that are being delivered. It provides direct
indication whether or not product is satisfying business needs.
• Formal technical reviews: Team reviews the component that
are being developed ,improving quality and learning as they
proceed.
• Post-mortem: ASD team become introspective, addressing its
own performance and process, intent of learning and
improving its approach.

An Agile View of Process 18

Dynamic Systems Development Method
• Provides a framework for building and maintaining systems which
meet tight time constraints using incremental prototyping in a
controlled environment.
• Uses Pareto principle (80% of project can be delivered in 20% time
required to deliver the entire project).
• DSDM keep the time and resources fixed and functionality can be
variable. Simply system will be delivering in a fixed time.
• DSDM process consists of few phases, which are “feasibility study,
business study, functional model iteration, design and build
iteration, and implementation”.
• The first two are done once and the rest of the three are iterative and
incremental, any iteration must be completed in fixed time. This fixed
time is called a time box.

An Agile View of Process 19

Figure 4.3:Dynamic System Development Method

An Agile View of Process 20

Guiding principles

• Active user involvement.

• Teams empowered to make decisions.
• Fitness for business purpose is criterion for deliverable
acceptance.
• Iterative and incremental development needed to converge on
accurate business solution.
• All changes made during development are reversible.
• Requirements are baselined at a high level.
• Testing throughout life-cycle.

An Agile View of Process 21

 DSDM Lifecycle
• It consist of three different iterative cycles, preceded by two additional
lifecycle.
Feasibility Study:
• Establishes the basic business requirement and constraints associated with
application to be built and then assesses whether the application is a viable
candidate for DSDM process.
• Feasibility report and outline plane are prepared.
Business Study:
• Establishes functional and information requirement that will allow the
application to provide business value; also defines basic application
architecture and identifies the maintainability requirement for the
application.
• System architecture and outline plane are defined.

An Agile View of Process 22

Functional model iteration:
• Produces a set of incremental prototypes that demonstrates
functionality for the customer.
• The intent during this iterative cycle is to gather requirements by
eliciting feedback from user as they exercise the prototype.
• Prototype code and analysis model is prepared
Design and build iteration:
• Revisit prototypes built during the functional model iteration to
ensure that each has been engineered in the manner that will
enable it to provide operational business value for the end user.
• Functional model iteration and design and built iteration occurs
concurrently.

An Agile View of Process 23

Implementation:
• Places latest increment into the operational environment.
• Increment may not be 100% complete
• Changes may be requested as increment is put into place.
• DSDM development work continuous by returning to the function
model iteration activity.

An Agile View of Process 24

Advantages
• User is consider as the owner of the solution.
• Risk is minimized up to enough extent by due to it iterative and
incremental nature.
• The solution obtained fulfils the exact requirement of the user all the
times.
• User is trained before the system implementation.
• The system implementation goes in very smooth way.

Disadvantage
• More user involvement can be danger some time if the user is not an
appropriate one.
An Agile View of Process 25
 SCRUM
• Scrum (the name is derived from an activity that occurs during a
rugby match)
• Proposed by Jeff Sutherland and his development team in the
early 1990s.
Scrum Role
• Product owner
• Team
• Scrum Master

An Agile View of Process 26

 SCRUM MASTER
• Combination of Coach, Fixer and Gatekeeper.
• Make sure project is progressing smoothly and team members has
tools that need to get job done.
• Set meetings, monitor work done and facilitate release planning
• Protect team and keep them focus on task

An Agile View of Process 27

Backlog
• Prioritized list of project requirements.
• Features that provide business value for the customer.
• Items can be added to the backlog at any time
• The product manager assesses the backlog and updates priorities as
required.
Sprints
• Consist of work units that are required to achieve a requirement
defined in the backlog that must be fit into a predefined time-box
(typically 30 days).
• Changes (e.g., backlog work items) are not introduced during the sprint.
Hence, the sprint allows team members to work in a short-term, but
stable environment.
• Sprint are short duration miles stone.
• Need atleast 4 or dozen of sprint to get to release.
• Plan for 1-2 sprints focusing only on defect backlogs

An Agile View of Process 28

Demos
Deliver the software increment to the customer so that functionality
that has been implemented can be demonstrated and evaluated by
the customer.
It contain functions that can be delivered within the time-box that
was established mostly not all functionalities. .
Scrum meetings—are short (typically 15 minutes) meetings held
daily by the Scrum team.
Three key questions
• What did you do since the last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

An Agile View of Process 29

 Scrum process frame work
• The heart of Scrum is a Sprint, a time-box of two
weeks. or one month during which a potentially
releasable product increment is created.

• A new Sprint starts immediately after the

conclusion of the previous Sprint.

• Sprints consist of the Sprint planning, daily

scrums, the development work, the Sprint review,
and the Sprint retrospective.

Figure 4.4:Scrum process frame work

An Agile View of Process 30

Scrum Process Flow

Figure 4.5:Scrum Process flow

An Agile View of Process 31

• In Sprint planning, the work to be performed in the Sprint is
planned collaboratively by the Scrum Team.

• The Daily Scrum Meeting is a 15-minute time-boxed event for the

Scrum Team to synchronize the activities and create a plan for that
day.

• A Sprint Review is held at the end of the Sprint to inspect the

Increment and make changes to the Product Backlog, if needed.

• The Sprint Retrospective occurs after the Sprint Review and prior to
the next Sprint Planning. In this meeting, the Scrum Team is to
inspect itself and create a plan for improvements to be enacted
during the subsequent Sprint.
An Agile View of Process 32
 Agile Process
Pros
• Is a very realistic approach to software
development.
• Promotes teamwork and cross training.
• Functionality can be developed rapidly
and demonstrated.
• Resource requirements are minimum.
• Suitable for fixed or changing
requirements
An Agile View of Process
Cons
• Not suitable for handling complex
dependencies.
• More risk of sustainability,
maintainability and extensibility.
• An overall plan, an agile leader and
agile PM practice is a must without
which it will not work.
• Strict delivery management dictates the
scope, functionality to be delivered, and
adjustments to meet the deadlines.
33
Pros Cons

• Delivers early partial working solutions. • Depends heavily on customer

interaction, so if customer is not clear,
• Good model for environments that change team can be driven in the wrong
steadily. direction.

• Minimal rules, documentation easily • There is very high individual

employed. dependency, since there is minimum
documentation generated.
• Enables concurrent development and
delivery within an overall planned context.
• Transfer of technology to new team
• Little or no planning required members may be quite challenging due
to lack of documentation.
• Easy to manage

• Gives flexibility to developers

An Agile View of Process 34

 Agile vs Traditional SDLC models
• Agile is based on the adaptive software development methods where
as the traditional SDLC models like waterfall model is based on
predictive approach.
• Predictive teams in the traditional SDLC models usually work with
detailed planning and have a complete forecast of the exact tasks and
features to be delivered in the next few months or during the product
life cycle.
• Predictive methods entirely depend on the requirement analysis and
planning done in the beginning of cycle.

• Any changes to be incorporated go through a strict change control

management and prioritization.
An Agile View of Process 35
• Agile uses adaptive approach where there is no detailed planning
and there is clarity on future tasks only in respect of what features need
to be developed.

• There is feature driven development and the team adapts to the

changing product requirements dynamically.

• The product is tested very frequently, through the release iterations,

minimizing the risk of any major failures in future.

• Customer interaction is the backbone of Agile methodology, and open

communication with minimum documentation are the typical features
of Agile development environment.

• The agile teams work in close collaboration with each other and are
most often located in the same geographical location.

An Agile View of Process 36

An Agile View of Process 37