SHREE

VAKRATUNDA MAHAAKAAYA SURYAKOTI SAMAPRABHA

1
NIRVIGNAM KURUMEDEVA SARVAKARYESHU
WITH BLESSING OF MY GURUJI

Dr. Shivanand M. Handigund

M. Tech. (IITD), Ph. D. (IITB)

2
3
 SOFTWARE ENGINEERING

WHAT IS AGILITY
 Changes in the software being built, changes to the team
members, changes because of new technology, changes
of all kinds that may have an impact on the product they
build or the project that creates the product.
 An agile team recognizes that software is developed by
individuals working in teams and that the skills of these
people, their ability to collaborate is at the core for the
success of the project
 Change is the primary driver for agility. But agility is more
than an effective response to change.
 It emphasizes rapid delivery of operational software and
de-emphasizes the importance of intermediate work
products. Agility can be applied to any software process
4
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

AGILITY AND COST OF CHANGE

The cost of change increases nonlinearly as a project
progresses fig 3.1
Proponents of agility argue that a well-designed agile
process “flattens” the cost of change curve (Figure 3.1,
shaded, solid curve), allowing a software team to
accommodate changes late in a software project without
dramatic cost and time impact.

WHAT IS AN AGILE PROCESS

Key assumptions about the majority of software projects
 It is difficult to predict in advance which software requirements will
persist and which will change. It is equally difficult to predict how
customer priorities will change as the project proceeds.
5
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 For many types of software, design and construction are

interleaved. That is, both activities should be performed in tandem
so that design models are proven as they are created. It is difficult
to predict how much design is necessary before construction is
used to prove the design.
 Analysis, design, construction, and testing are not as predictable
(from a planning point of view) as we might like.
 An agile process, therefore, must be adaptable. An agile
software process must adapt incrementally. To accomplish
incremental adaptation, an agile team requires customer
feedback
 An incremental development strategy should be instituted.
Software increments (executable prototypes or portions of
an operational system) must be delivered in short time
periods so that adaptation keeps pace with change
6
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

Agility Principles
12 agility principles for those who want to achieve agility:
 1. Our 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. 7
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

.
 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.
 12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
The Politics of Agile Development
 There is considerable debate about the benefits and
applicability of agile software development as opposed
to more conventional software engineering processes
8
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

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

Human Factors:
 “Agile development focuses on the talents and skills of
individuals, molding the process to specific people and
teams.”
 A number of key qualities must exist among the people
on an agile team and the team itself:
9
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Competence. encompasses innate talent, specific

software-related skills, and overall knowledge of the
process
 Common focus.
focus all team members should be focused
on one goal—to deliver a working software increment to
the customer within the time promised
 Collaboration: To accomplish about assessing,
analyzing, and using information, team members must
collaborate with one another and all other stakeholders.
 Decision-making ability.
ability Any good software team
(including agile teams) must be allowed the freedom to
control its own destiny i.e. team is given autonomy
 Fuzzy problem-solving ability.ability the problem solving
today may not be the problem to be solved tomorrow
10
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Mutual trust and respect; A jelled team exhibits the

trust and respect that are necessary to make them “so
strongly knit that the whole is greater than the sum of
the parts.”
 Self-organization.
Self-organization self-organization implies three things:
(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

EXTREME PROGRAMMING
 Extreme Programming (XP), the most widely used
approach to agile software development
11
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

XP Values:
 A set of five values that establish a foundation for all
work performed as part of XP—communication,
simplicity, feedback, courage, and respect
 to achieve effective communication, XP emphasizes
close, yet informal (verbal) collaboration between
customers, and developers, the establishment of
effective metaphors (“a story that everyone—customers,
programmers, and managers— can tell about how the
system works)
 To achieve simplicity, XP restricts developers to design
only for immediate needs, rather than consider future
needs.
12
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Feedback is derived from three sources: the

implemented software itself, the customer, and other
software team members.
 An agile XP team must have the discipline (courage) to
design for today, recognizing that future requirements
may change dramatically, thereby demanding
substantial rework of the design and implemented code.
 The agile team inculcates respect among it members,
between other stakeholders and team members, and
indirectly, for the software itself.
The XP Process
 Extreme Programming uses an object-oriented
approach. Four framework activities: planning, design,
coding, and testing.
13
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Planning. The planning activity begins with listening a

requirements gathering activity that enables the
technical members of team to understand the business
context for the software.
 Listening leads to the creation of a set of “stories”
(also called user stories) that describe required output,
features, and functionality for software to be built.
 Members of the XP team then assess each story and
assign a cost—measured in development weeks—to it. If
the story is estimated to require more than three
development weeks, the customer is asked to split the
story into smaller stories and the assignment of value
and cost occurs again
14
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Once a basic commitment (agreement on stories to be

included, delivery date, and other project matters) is
made for a release, the XP team orders the stories that
will be developed in one of three ways: (1) all stories will
be implemented immediately (within a few weeks), (2)
the stories with highest value will be moved up in the
schedule and implemented first, or (3) the riskiest stories
will be moved up in the schedule and implemented first.
 Project velocity is the number of customer stories
implemented during the first release. Project velocity can
be used to (1) estimate delivery dates and schedule for
subsequent releases (2) determine whether an
overcommitment has been made. If an overcommitment
occurs, end delivery dates are changed.
15
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Design. XP design rigorously follows the KIS (keep it

simple) principle. XP encourages the use of CRC cards
 CRC (class-responsibility collaborator) cards identify and
organize the object-oriented classes that are relevant to
the current software increment.
 If a difficult design problem is encountered, XP
recommends the immediate creation of an operational
prototype of that portion of the design. called a spike
solution
 XP encourages refactoring—a construction technique
that is also a method for design optimization. It is a
disciplined way to clean up code [and modify/simplify the
internal design] that minimizes the chances of
introducing bugs.
16
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 Coding. key concept during the coding activity is pair

programming. Two people work together at one
computer workstation to create code for a story. each
person takes on a slightly different role.
 The pair programmers have integration responsibility.
This “continuous integration” strategy helps to avoid
compatibility and interfacing problems and provides a
“smoke testing” environment to uncover errors early.
 Testing.
Testing The creation of unit tests before coding
commences is a key element of the XP approach.
 Integration and validation testing of the system can
occur on a daily basis “Fixing small problems every
few hours takes less time than fixing huge problems
just before the deadline.”
17
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 XP acceptance tests, also called customer tests, are

specified by the customer and focus on overall system
features and functionality that are visible and reviewable
by the customer

Industrial XP
 Industrial Extreme Programming (IXP) is an organic
evolution of XP. It is imbued with XP’s minimalist,
customer-centric, test-driven spirit
 IXP incorporates six new practices
1. Readiness assessment. The organization should
conduct a readiness assessment The assessment
determines whether (1) an appropriate development
environment exists (2) team with proper stakeholders,
18
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

 (3) distinct quality program and supports continuous

improvement, (4) the organizational culture will support
the agile team, and (5) the broader project community
will be populated appropriately
2. Project community. Classic XP suggests that the right
people be used to populate the agile team to ensure
success. A community may have a technologist and
customers who are central to the success of a project as
well as many other stakeholders
3. Project chartering. The IXP team assesses the project
itself to determine whether an appropriate business
justification for the project exists and whether the project
will further the overall goals and objectives of the
organization
19
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

4. Test-driven management. An IXP project requires

measurable criteria for assessing the state of the
project and the progress that has been made to date
5. Retrospectives. team conducts a specialized technical
review after a software increment is delivered. Called a
retrospective, the review examines “issues, events, and
lessons-learned”
6. Continuous learning. For continuous process
improvement, members of team are encouraged to
learn new methods and techniques that can lead to a
higher quality product
The XP Debate
• XP is continuously evolving and that many of the issues
raised by critics have been addressed
20
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• Issues that continue to trouble some critics of XP are:

• Requirements volatility. Because the customer is an
active member of the XP team, changes to
requirements are requested informally
• Conflicting customer needs. Many projects have
multiple customers, each with his own set of needs
• Requirements are expressed informally. User stories
and acceptance tests are the only explicit indicator of
requirements.
• Lack of formal design: Design of all kinds should be
relatively informal.

21
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

OTHER AGIL PROCESS MODELS:

• Many agile process models have been proposed and
are in use across the industry.
• Among the most common are:
• Adaptive Software Development (ASD): ASD
focus on human collaboration and team self-
organization. Figure 3.3
• Scrum: process that incorporates the following
framework activities: requirements, analysis, design,
evolution, and delivery. Process patterns defines a
set of development actions : Backlog, Sprints,
Scrum meetings, Demos

22
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• Dynamic Systems Development Method (DSDM);

Pareto principle—80 percent of an application can
be delivered in 20 percent of the time. DSDM life
cycle; Feasibility study, Business study, Functional
model iteration, Design and build iteration,
Implementation
• Crystal: Development approach that puts a
premium on “maneuverability”. “a resource limited,
cooperative game of invention and communication, with a
primary goal of delivering useful, working software and a
secondary goal of setting up for the next game”
• Feature Drive Development (FDD): FDD adopts a
philosophy that (1) emphasizes collaboration among
people on an FDD team;
23
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• (2) manages problem and project complexity using

feature-based decomposition followed by the
integration of software increments, and (3)
communication of technical detail using verbal,
graphical, and text-based means. A feature “is a
client-valued function that can be implemented in
two weeks or less
• Lean Software Development (LSD): The lean
principles that inspire the LSD process can be
summarized as eliminate waste, build quality in,
create knowledge, defer commitment, deliver fast,
respect people, and optimize the whole.

24
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• Agile Modeling (AM): It 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
• Modeling principles: Model with a purpose, Use multiple
models, Travel light, Content is more important than
representation, Know the models and the tools you use to
create them, Adapt locally.
• Agile Unified Process (AUP): adopts a “serial in
the large” and “iterative in the small” philosophy for
building computer-based systems.
• Each AUP iteration addresses the activities: Modeling,
Implementation, Testing, Deployment, Configuration and
project management, Environment management
25
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

SOFTWARE ENGINEERING KNOWLEDGE

•Many software practitioners think of software engineering
knowledge as knowledge of specific technologies: Java, Perl,
html, C++, Linux, Windows NT, and so on.
•core principles—the elemental ideas that guide software
engineers in the work that they do—now provide a
foundation from which software engineering models,
methods, and tools can be applied and evaluated

CORE PRINCIPLES
•Principles That Guide Process: The following set of core
principles:
•1. Be agile, 2. Focus on quality at every step,
•3. Be ready to adapt, 4. Build an effective team.
26
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• 5. Establish mechanisms for communication and

coordination. 6. Manage change. 7. Assess risk.
• 8. Create work products that provide value for others.

Principles That Guide Practice

• The following set of core principles are fundamental to the
practice of software engineering:
• 1. Divide and conquer. 2. Understand the use of
abstraction, 3. Strive for consistency, 4. Focus on the
transfer of information, 5. Build software that exhibits
effective modularity. 6. Look for patterns. 7. When
possible, represent the problem and its solution from a
number of different perspectives. 8. Remember that
someone will maintain the software.
27
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

PRINCIPLES THAT GUIDE EACH FRAMEWORK ACTIVITY

•The core principles stated at a lower level of abstraction.
•COMMUNICATION PRINCIPLES:
•Communication principles as they apply to customer
communication 1. Listen. 2. Prepare before you
communicate, 3. Someone should facilitate the activity. 4.
Face-to-face communication is best. 5. Take notes and
document decisions. 6. Strive for collaboration, 7. Stay
focused; modularize your discussion, 8. If something is
unclear, draw a picture. 9. (a) Once you agree to something,
move on. (b) If you can’t agree to something, move on. (c) If
a feature or function is unclear and cannot be clarified at the
moment, move on. 10. Negotiation is not a contest or a
game. It works best when both parties win.
28
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• PLANNING PRINCIPLES: The planning activity

encompasses a set of management and technical
practices that enable the software team to define a road
map as it travels toward its strategic goal and tactical
objectives.
• When planning is conducted, the principles always apply:
• 1. Understand the scope of the project, 2. Involve
stakeholders in the planning activity. 3. Recognize that
planning is iterative. 4. Estimate based on what you know.
5. Consider risk as you define the plan. 6. Be realistic. 7.
Adjust granularity as you define the plan. 8. Define how
you intend to ensure quality. 9. Describe how you intend to
accommodate change. 10. Track the plan frequently and
make adjustments as required.
29
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• MODELING PRINCIPLES: representing the information

that software transforms, the architecture and functions
that enable the transformation to occur, the features that
users desire, and the behavior of the system as the
transformation is taking place
• 1. The primary goal of the software team is to build
software, not create models. 2. Travel light—don’t create
more models than you need. 3. Strive to produce the
simplest model that will describe the problem or the
software 4. Build models in a way that makes them
amenable to change. 5. Be able to state an explicit
purpose for each model that is created. 6. Adapt the
models you develop to the system at hand 7. Try to build
useful models, but forget about building perfect models.
30
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• 8. Don’t become dogmatic about the syntax of the model.

If it communicates content successfully, representation is
secondary 9. If your instincts tell you a model isn’t right
even though it seems okay on paper, you probably have
reason to be concerned. 10. Get feedback as soon as you
can.

Requirements modeling principles:

• All analysis methods are related by a set of operational
principles:
• 1. The information domain of a problem must be
represented and understood. 2. The functions that the
software performs must be defined. 3. The behavior of the
software (as a consequence of external events) must be
represented.
Dr. AJEET A. C.
31
 SOFTWARE ENGINEERING

• 4. The models that depict information, function, and

behavior must be partitioned in a manner that uncovers
detail in a layered (or hierarchical) fashion. 5. The analysis
task should move from essential information toward
implementation detail

Design Modeling Principles.

• The software design model is analogous to an architect’s
plans for a house. The design model that is created for
software provides a variety of different views of the
system.
• Set of design principles that can be applied regardless of
the method that is used:
• 1. Design should be traceable to the requirements model.
32
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• 2. Always consider the architecture of the system to be

built. 3. Design of data is as important as design of
processing functions. 4. Interfaces (both internal and
external) must be designed with care. 5. User interface
design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use. 6.
Component-level design should be functionally
independent. 7. Components should be loosely coupled to
one another and to the external environment. 8. Design
representations (models) should be easily understandable.
9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity.

33
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

CONSTRUCTION PRINCIPLES.
•The construction activity encompasses a set of coding and
testing tasks that lead to operational software that is ready
for delivery to the customer or end user.
Coding Principles
•Preparation principles: Before you write one line of
code, be sure you
• Understand of the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of
the software to be built and the environment in which it
will operate.
• Select a programming environment that provides tools
that will make your work easier.
.Dr. AJEET A. C. 34
 SOFTWARE ENGINEERING

• Create a set of unit tests that will be applied once the

component you code is completed.
• Programming principles: As you begin writing code,
be sure you
• Constrain your algorithms by following structured
programming practice.
• Consider the use of pair programming.
• Select data structures that will meet the needs of the
design.
• Understand the software architecture and create
interfaces that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily
testable.
35
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

• Select meaningful variable names and follow other local

coding standards.
Validation Principles: After you’ve completed your first
coding pass, be sure you
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.
Testing Principles: set of testing principles
• 1. All tests should be traceable to customer
requirements. 2. Tests should be planned long before
testing begins. 3. The Pareto principle applies to
software testing 4. Testing should begin “in the small”
and progress toward testing “in the large.” 5. Exhaustive
testing is not possible.
36
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

DEPLOYMENT PRINCIPLES:
•The deployment activity encompasses three actions:
delivery, support, and feedback.
•A number of key principles should be followed as the team
prepares to deliver an increment: 1. Customer expectations
for the software must be managed. 2. A complete delivery
package should be assembled and tested. 3. A support
regime must be established before the software is delivered.
4. Appropriate instructional materials must be provided to
end users. 5. Buggy software should be fixed first, delivered
later.

37
Dr. AJEET A. C.
 SOFTWARE ENGINEERING

QUESTIONS
What is Agility? How the Agility change the cost?
What is an Agile Process
What are the principles of Agility
State the key qualities of Human Factor in Agility
Write a note on a) XP values b) XP process
What are the practices used in Industrial Extreme Programming
Explain the various Agile Process Models used in the Industry
State and Explain the Core Principles of Agile
State and Explain the Principles that guide Frame Work Activity
State and Explain the Construction Principles of Agility
State and Explain the Agility Deployment Principles

38
Dr. AJEET A. C.
 NACC: AN ACCREDATION PROCESS

Our endeavor
is
Class Edification

39
Dr. AJEET A. C.