SE

S 3 MCA
MACFAST
• In 2001, Kent Beck and 16 other noted
software developers, writers, and consultants
(referred to as the “Agile Alliance”) signed the
“Manifesto for Agile Software Development.”
It stated:
• What is it? Agile software engineering
combines a philosophy and a set of
development guidelines. The philosophy
encourages customer satisfaction and early
incremental delivery of software; small, highly
motivated project teams; informal methods;
minimal software engineering work products;
and overall development simplicity.
• Who does it? Software engineers and other project
stakeholders (managers, customers, end users)
work together on an agile team—a team that is
self-organizing and in control of its own destiny.
• Why is it important? The modern business
environment that spawns computer-based systems
and software products is fast-paced and
everchanging. Agile software engineering
represents a reasonable alternative
• What are the steps? Agile development might
best be termed “software engineering lite.”
The basic framework activities—
communication, planning, modeling,
construction, and deployment— remain. But
they morph into a minimal task set that
pushes the project team toward construction
and delivery
• What is the work product? Both the customer and
the software engineer have the same view—the
only really important work product is an operational
“software increment” that is delivered to the
customer on the appropriate commitment date.
• How do I ensure that I’ve done it right? If the agile
team agrees that the process works, and the team
produces deliverable software increments that
satisfy the customer, you’ve done it right.
 Overview

• Agile software engineering represents a reasonable compromise between to

conventional software engineering for certain classes of software and certain
types of software projects
• Agile development processes can deliver successful systems quickly
• Agile development stresses continuous communication and collaboration
among developers and customers
• Agile software engineering embraces a philosophy that encourages customer
satisfaction, incremental software delivery, small project teams (composed of
software engineers and stakeholders), informal methods, and minimal
software engineering work products
• Agile software engineering development guidelines stress on-time delivery of
an operational software increment over analysis and design (the only really
important work product is an operational software increment)
 Manifesto for Agile Software Development
 
• Proposes that it may be better to value:
– Individuals and interactions over processes and tools
– Working software over comprehensive
documentation
– Customer collaboration over contract negotiation
– Responding to change over following a plan
• While the items on the right are still important
the items on the left are more valuable under
this philosophy
• Agility has become today’s buzzword when
describing a modern software process.
• the pervasiveness of change is the primary
driver for agility
• agility is more than an effective response to
change
• Agile software development is a group of
software development methods in which
requirements and solutions evolve through
collaboration between self-organizing, cross-
functional teams. It promotes adaptive
planning, evolutionary development, early
delivery, continuous improvement and
encourages rapid and flexible response to
change.
 AGILITY AND THE COST OF CHANGE

• conventional wisdom in software

development is that the cost of change
increases nonlinearly as a project progresses
 Agility

• An agile team is able to respond to changes during project development

• Agile development recognizes that project plans must be flexible
• Agility encourages team structures and attitudes that make communication
among developers and customers more facile
• Eliminates the separation between customers and developers
• Agility emphasizes the importance of rapid delivery of operational software and
de-emphasizes importance of intermediate work products
• Agility can be applied to any software process as long as the project team is
allowed to streamline tasks and conduct planning in way that eliminate non-
essential work products
• The costs of change increase rapidly as a project proceeds to completion, the
earlier a change is made the less costly it will be
• Agile processes may flatten the cost of change curve by allowing a project team
to make changes late in the project at much lower costs
 Agile Processes

• ~ are based on three key assumptions:

• It is difficult to predict in advance which requirements or customer
priorities will change and which will not
• For many types of software design and construction activities are
interleaved (construction is used to prove the design)
• Analysis, design, and testing are not as predictable from a planning
perspective as one might like them to be
• Therefore to manage unpredictability, Agile processes must be
adapt incrementally to manage unpredictability
• Incremental adaptation requires customer feedback based on
evaluation of delivered software increments (executable
prototypes) over short time periods
 Agility Principles

• Highest priority is to satisfy customer through early and continuous

delivery of valuable software
• Welcome changing requirements even late in development,
accommodating change is viewed as increasing the customer’s
competitive advantage
• Delivering working software frequently with a preference for shorter
delivery schedules (e.g. every 2 or 3 weeks)
• Business people and developers must work together daily during the
project
• Build projects around motivated individuals, given them the
environment and support they need, trust them to get the job done
• Face-to-face communication is the most effective method of conveying
information within the development team
 Agility Principles..

• Working software is the primary measure of progress

• Agile processes support sustainable development, developers
and customers should be able to continue development
indefinitely
• Continuous attention to technical excellence and good design
enhances agility
• Simplicity (defined as maximizing the work not done) is essential
• The best architectures, requirements, and design emerge from
self-organizing teams
• At regular intervals teams reflects how to become more effective
and adjusts its behavior accordingly
 The Politics of Agile Development
• No one is against agility. The real question is:
What is the best way to achieve it? As
important, how do you build software that
meets customers’ needs today and exhibits the
quality characteristics that will enable it to be
extended and scaled to meet customers’ needs
over the long term?
• Well, There are no absolute answers to either
of these questions.
 Human Factors
• Proponents of agile software development
take great pains to emphasize the importance
of “people factors.”
• If the members of the software team are to
drive the characteristics of the process that is
applied to build software, a number of key
traits must exist among the people on an agile
team and the team itself:
 Human Factors..

• Traits that need to exist in members of agile

development teams:
– Competence
– Common focus
– Collaboration
– Decision-making ability
– Fuzzy-problem solving ability
– Mutual trust and respect– jelled team
– Self-organization
 – Self-organization implies
• (1) the agile team organizes itself for the work
to be done,
• (2) the team organizes the process to best
accommodate its local environment,
• (3) the team organizes the work schedule to
best achieve delivery of the software
increment.
  
Agile Process Models

• Extreme Programming (XP)

• Adaptive Software Development (ASD)
• Scrum
• Dynamic Systems Development Method (DSDM)
• Crystal
• Feature Driven Development (FDD)
• Lean Software Development (LSD)
• Agile Modeling (AM)
• Agile Unified Process (AUP)
 Extreme Programming
 

• Extreme Programming (XP), the most widely used approach to

agile software development
• Relies on object-oriented approach
• XP Values
– Communication (close, informal between developers and stakeholders)
– Simplicity (developers design for current needs, not future needs)
– Feedback (implemented software – unit tests, customer – user stories
guide acceptance tests, software team – iterative planning)
– Courage (design for today not tomorrow)
– Respect (stakeholders and team members for the software product)
 Extreme Programming ..
Key activities - The XP Process
 

• Planning (user stories created and sorted by customer values)

• Design (simple designs preferred (KIS), CRC cards and design prototypes are
only work products, encourages use of refactoring)
– If a difficult design problem is encountered as part of the design of a story, XP
recommends the immediate creation of an operational prototype of that portion of
the design. Called a spike solution, the design prototype is implemented and
evaluated.
– XP encourages refactoring—a construction technique that is also a method for
design optimization.
– Refactoring is the process of changing a software system in such a way that it does
not alter the external behavior of the code yet improves the internal structure.
– A central notion in XP is that design occurs both before and after coding commences.
– Refactoring means that design occurs continuously as the system is constructed.
 Extreme Programming ..
Key activities - The XP Process
 

• Coding (focuses on unit tests to exercise stories, emphasizes

use of pairs programming to create story code, continuous
integration and smoke testing is utilized)
– A key concept during the coding activity (and one of the most talked
about aspects of XP) is pair programming. XP recommends that two
people work together at one computer workstation to create code
for a story
• Testing (unit tests created before coding are implemented
using an automated testing framework to encourage use of
regression testing, integration and validation testing done on
daily basis, acceptance tests focus on system features and
functions viewable by the customer)
 Industrial XP
• “IXP is an organic evolution of XP. It is imbued with
XP’s minimalist, customer-centric, test-driven spirit.
IXP differs most from the original XP in its greater
inclusion of management, its expanded role for
customers, and its upgraded technical practices.”
• IXP incorporates six new practices that are
designed to help ensure that an XP project works
successfully for significant projects within a large
organization. They are:
 Industrial XP – 6 practices

• Readiness acceptance
– Does an appropriate development environment exists to support IXP?
– Will the team be populated by stakeholders?
– Does the organization have a distinct quality program that support continuous process
improvement?
– Will the organizational culture support new values of the agile team?
– Will the broader project community be populated appropriately?
• Project community (finding the right people for the project team; the concept of the
“team” should morph into that of a community.)
• Project chartering (determining whether or not an appropriate business justification
exists to justify the project)
• Test-driven management (used to establish measurable destinations and criteria for
determining when each is reached)
• Retrospectives (specialized technical review focusing on issues, events, and lessons-
learned across a software increment or entire software release)
• Continuous learning (vital part of continuous process improvement)
 IXP
• Apart from the above,
• Story-driven development (SDD) insists that
stories for acceptance tests be written before a
single line of code is generated.
• Domain-driven design (DDD) is an improvement
on the “system metaphor” concept used in XP.
• Pairing,
• Iterative usability are also used as part of I X P
 XP Issues
• XP practices are worthwhile, but others have
been overhyped, and a few are problematic.
• the codependent nature of XP practices are
both its strength and its weakness.
• Because many organizations adopt only a
subset of XP practices, they weaken the
efficacy of the entire process.
 XP Issues..
 

• Major ones are:

• Requirement volatility (can easily lead for scope creep that
causes changes to earlier work design for the then current needs)
• Conflicting customer needs (many project with many customers
make it hard to assimilate all customer needs)
• Requirements expressed informally (with only user stories and
acceptance tests, its hard to avoid omissions and inconsistencies)
• Lack of formal design (complex systems may need a formal
architectural design to ensure a product that exhibits quality and
maintainability) http://industrialxp.org
 XP..
• Every software process has flaws and that
many software organizations have used XP
successfully. The key is to recognize where a
process may have weaknesses and to adapt it
to the specific needs of your organization.
 OTHER AGILE PROCESS MODELS
• Many other agile process models have been proposed and
are in use across the industry. Among the most common are:
• • Adaptive Software Development (ASD)
• • Scrum
• • Dynamic Systems Development Method (DSDM)
• • Crystal
• • Feature Drive Development (FDD)
• • Lean Software Development (LSD)
• • Agile Modeling (AM)
• • Agile Unified Process (AUP)
 Adaptive Software Development

• ASD has been proposed by Jim Highsmith as a technique for building

complex software and systems.
• Highsmith says that an agile, adaptive development approach based on
collaboration is “as much a source of order in our complex interactions as
discipline and engineering.”
• He defines an ASD “life cycle” (Figure ) that incorporates three phases,
speculation, collaboration, and learning.
• During speculation, the project is initiated and adaptive cycle planning is
conducted.
• Adaptive cycle planning uses project initiation information—the
customer’s mission statement, project constraints (e.g., delivery dates or
user descriptions), and basic requirements—to define the set of release
cycles (software increments) that will be required for the project.
 Adaptive Software Development

• Self-organization arises when independent agents cooperate to create a solution to a

problem that is beyond the capability of any individual agent
• Emphasizes self-organizing teams, interpersonal collaboration, and both individual and
team learning
• Adaptive cycle characteristics
– Mission-driven
– Component-based
– Iterative
– Time-boxed
– Risk driven and change-tolerant
• Phases
– Speculation (project initiated and adaptive cycle planning takes place)
– Collaboration (requires teamwork from a jelled team, joint application development is preferred
requirements gathering approach)
– Learning (components implemented and testes, focus groups provide feedback, formal technical
reviews, postmortems)
 ASD..
• Collaboration is, above all, a matter of trust.
People working together must trust one
another to (1) criticize without animosity, (2)
assist without resentment, (3) work as hard as
or harder than they do, (4) have the skill set to
contribute to the work at hand, and (5)
communicate problems or concerns in a way
that leads to effective action.
 Adaptive Software Development..

• Motivated people use collaboration in a way that

multiplies their talent and creative output beyond their
absolute numbers. This approach is a recurring theme in
all agile methods. But collaboration is not easy.
• The ASD philosophy has merit regardless of the process
model that is used. ASD’s overall emphasis on the
dynamics of self-organizing teams, interpersonal
collaboration, and individual and team learning yield
software project teams that have a much higher likelihood
of success.
 Scrum
• Scrum (the name is derived from an activity
that occurs during a rugby match*) is an agile
software development method that was
conceived by Jeff Sutherland and his
development team in the early 1990s.
Scrum
 Scrum..
• Scrum principles are consistent with the agile
manifesto and are used to guide development
activities within a process that incorporates
the following framework activities:
requirements, analysis, design, evolution, and
delivery.
 Scrum

• Scrum principles
– Small working team used to maximize communication, minimize
overhead, and maximize sharing of informal knowledge
– Process must be adaptable to both technical and business
challenges to ensure best product produced
– Process yields frequent increments that can be inspected, adjusted,
tested, documented and built on
– Development work and people performing it are partitioned into
clean, low coupling partitions
– Testing and documentation is performed as the product is built
– Provides the ability to declare the product done whenever required
 Scrum..

• Scrum emphasizes the use of a set of software

process patterns that have proven effective for
projects with tight timelines, changing
requirements, and business criticality. Each of
these process patterns defines a set of
development actions:
 Scrum..

• Process patterns defining development activities are:

– Backlog (prioritized list of requirements or features the provide
business value to customer, items can be added at any time)
– Sprints (work units required to achieve one of the backlog items,
must fir into a predefined time-box, affected backlog items
frozen)
– Scrum meetings (15 minute daily meetings)
• What was done since last meeting?
• What obstacles were encountered?
• What will be done by the next meeting?
– Demos (deliver software increment to customer for evaluation)
 Scrum..
• A team leader, called a Scrum master, leads the
meeting and assesses the responses from each
person. The Scrum meeting helps the team to uncover
potential problems as early as possible. Also, these
daily meetings lead to “knowledge socialization”and
thereby promote a self-organizing team structure.
• Demos—deliver the software increment to the
customer so that functionality that has been
implemented can be demonstrated and evaluated by
the customer.
 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% required to deliver the entire project)*
• Each increment only delivers enough functionality to
move to the next increment
• Uses time boxes to fix time and resources to determine
how much functionality will be delivered in each
increment
 Dynamic Systems Development Method

• Guiding principles
– Active user involvement
– Teams empowered to make decisions
– Fitness foe business purpose is criterion for deliverable
acceptance
– Iterative and incremental develop needed to converge on
accurate business solution
– All changes made during development are reversible
– Requirements are baselined at a high level
– Testing integrates throughout life-cycle
– Collaborative and cooperative approach between stakeholders
 Dynamic Systems Development Method

• The DSDM Consortium (www.dsdm.org) is a worldwide group of

member companies that collectively take on the role of “keeper” of the
method. The consortium has defined an agile process model, called the
DSDM life cycle that defines three different iterative cycles, preceded by
two additional life cycle activities:
• Life cycle activities
– Feasibility study (establishes requirements and constraints)
– Business study (establishes functional and information requirements needed to
provide business value)
– Functional model iteration (produces set of incremental prototypes to
demonstrate functionality to customer)
– Design and build iteration (revisits prototypes to ensure they provide business
value for end users, may occur concurrently with functional model iteration)
– Implementation (latest iteration placed in operational environment)
 Crystal
• Alistair Cockburn and Jim Highsmith created
the Crystal family of agile methods
• The Crystal family is actually a set of example
agile processes that have been proven
effective for different types of projects.
 Crystal

• Alistair Cockburn and Jim Highsmith created the Crystal*

family of agile methods
• Development approach that puts a premium on
maneuverability during a resource-limited game of invention
and communication with the primary goal of delivering useful
software and a secondary goal of setting up for the next game
• Incremental development strategy used with 1 to 3 month
time lines
• Reflection workshops conducted before project begins,
during increment development activity, and after increment is
delivered
 Feature Driven Development
• Feature Driven Development (FDD) was
originally conceived by Peter Coad and his
colleagues as a practical process model for
object-oriented software engineering.
 Feature Driven Development

• Practical process model for object-oriented software

engineering
• Feature is a client-valued function, can be implemented in two
weeks or less
• FDD Philosophy
– Emphasizes collaboration among team members
– Manages problem and project complexity using feature-based
decomposition followed integration of software increments
– Technical communication using verbal, graphical, and textual means
– Software quality encouraged by using incremental development,
design and code inspections, SQA audits, metric collection, and use of
patterns (analysis, design, construction)
 FDD..
• In the context of FDD, a feature “is a client-valued function
that can be implemented in two weeks or less”.
• The emphasis on the definition of features provides the
following benefits:
– Because features are small blocks of deliverable functionality,
users can describe them more easily; understand how they relate
to one another more readily; and better review them for
ambiguity, error, or omissions.
– Features can be organized into a hierarchical business-related
grouping.
– Because features are small, their design and code representations
are easier to inspect effectively ……
FDD..
 FDD..
• Coad and his colleagues suggest the following template
for defining a feature:
• <action> the <result> <by for of to> a(n) <object>
– where an <object> is “a person, place, or thing (including
roles, moments in time or intervals of time, or catalog-entry-
like descriptions).”
• Eg:
• Add the product to shopping cart
• Display the technical-specifications of the product
• Store the shipping-information for the customer
 FDD..
• A feature set groups related features into
business-related categories and is defined as:
• <action><-ing> a(n) <object>
• For example: Making a product sale is a
feature set that would encompass the features
noted earlier and others.
 Feature Driven Development

• Framework activities
– Develop overall model (contains set of classes depicting business
model of application to be built)
– Build features list (features extracted from domain model, features are
categorized and prioritized, work is broken up into two week chunks)
– Plan by feature (features assessed based on priority, effort, technical
issues, schedule dependencies)
– Design by feature (classes relevant to feature are chosen, class and
method prologs are written, preliminary design detail developed,
owner assigned to each class, owner responsible for maintaining design
document for his or her own work packages)
– Build by feature (class owner translates design into source code and
performs unit testing, integration performed by chief programmer)
 FDD..
• FDD provides greater emphasis on project
management guidelines and techniques than
many other agile methods.
• To accomplish deadlines, FDD defines six
milestones during the design and
implementation of a feature: “design
walkthrough, design, design inspection, code,
code inspection, promote to build”
 Lean Software Development Principles
 

• Lean Software Development (LSD) has adapted the principles

of lean manufacturing to the world of software engineering.
The lean principles that inspire the LSD process are:
• Eliminate waste
• Build quality in
• Create knowledge
• Defer commitment
• Deliver fast
• Respect people
• Optimize the whole
 LSD..
• eliminate waste within the context of an agile
software project can be interpreted to mean
(1) adding no extraneous features or
functions, (2) assessing the cost and schedule
impact of any newly requested requirement,
(3) removing any superfluous process steps,….
 Agile Modeling
• At “The Official Agile Modeling Site,” Scott Ambler describes
agile modeling (AM) in the following manner:
• Agile Modeling (AM) is a practice-based methodology for
effective modeling and documentation of software-based
systems.
• Simply put, Agile Modeling (AM) is a collection of values,
principles, and practices for modeling software that can be
applied on a software development project in an effective and
light-weight manner.
• Agile models are more effective than traditional models because
they are just barely good, they don’t have to be perfect.
 Agile Modeling

• Practice-based methodology for effective modeling and documentation of software

systems in a light-weight manner
• Modeling principles
– Model with a purpose
– Use multiple models
– Travel light (only keep models with long-term value)
– Content is more important than representation
– Know the models and tools you use to create them
– Adapt locally
• Requirements gathering and analysis modeling
– Work collaboratively to find out what customer wants to do
– Once requirements model is built collaborative analysis modeling continues with the customer
• Architectural modeling
– Derives preliminary architecture from analysis model
– Architectural model mist be realistic for the environment and must be understandable by
developers
 Agile Unified Process

• ~ adopts classic UP phased activities (inception, elaboration,

construction, transition) to enable team to visualize overall software
project flow
• Within each activity team iterates to achieve agility and delivers
meaningful software increments to end-users as rapidly as possible
• Each AUP iteration addresses
– Modeling (UML representations of business and problem domains)
– Implementation (models translated into source code)
– Testing (uncover errors and ensure source code meets requirements)
– Deployment (software increment delivery and acquiring feedback)
– Configuration and project management (change management, risk
management, persistent work product control)
– Environment management (standards, tools, technology)
 A TOOL SET FOR THE AGILE PROCESS
• Some proponents of the agile philosophy argue that automated
software tools (e.g., design tools) should be viewed as a minor
supplement to the team’s activities, and not at all pivotal to the success
of the team.
• Collaborative and communication “tools” are generally low tech and
incorporate any mechanism (“physical proximity, whiteboards, poster
sheets, index cards, and sticky notes”) that provides information and
coordination among agile developers.
• physical devices (e.g., electronic whiteboards), and process
enhancement (e.g., pair programming or time-boxing)”
• Are any of these things really tools?
• They are, if they facilitate the work performed by an agile team
member and enhance the quality of the end product
 SUMMARY
• An agile philosophy for software engineering
stresses four key issues: the importance of self-
organizing teams that have control over the
work they perform, communication and
collaboration between team members and
between practitioners and their customers, a
recognition that change represents an
opportunity, and an emphasis on rapid delivery
of software that satisfies the customer.
• Extreme programming (XP) is the most widely
used agile process. Organized as four
framework activities—planning, design,
coding, and testing
• Feature Driven Development (FDD) is
somewhat more “formal” than other agile
methods, but still maintains agility by focusing
the project team on the development of
features