U NIT-II

AGILE DEVELOPMENT
 AGILITY
 Agility in context of software engineering
 Agility means effective (rapid and adaptive) response to change, effective
communication among all stockholder.
 Drawing the customer onto team and organizing a team so that it is in
control of work performed.
 The Agile process, light-weight methods are People-based rather than plan-
based methods.
 The agile process forces the development team to focus on software itself
rather than design and documentation.
 The agile process believes in iterative method.
 The aim of agile process is to deliver the working model of software
quickly to the customer For example: Extreme programming is the best
known of agile process.
Agility and the Cost of Change
Agility and the Cost of Change(contd)
 The conventional software project development(software processes) is that
the cost of change increases nonlinearly as a software project development
progresses shown in solid black curve .

 A well-designed agile processes “flattens” the cost of change shown as

solid pink curve , allowing a software team to accommodate changes late in
a software project development without dramatic cost and time impact.
What is Agile process?
Agile process is an Iterative approach to build working software project and is
delivered after each iteration. Each build is incremental in terms of features; the
final build holds all the features required by the customer.

Here is a graphical illustration of the Agile process Model −

 Agile Methodologies
 The most popular Agile methods include Rational Unified Process (1994),
Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive
Software Development, Feature Driven Development, and Dynamic
Systems Development Method (DSDM) (1995). These are now collectively
referred to as Agile Methodologies.
Extreme Programming (XP)

 Extreme Programming:

 Extreme programming uses an object-oriented approach for development

paradigm(process model).

 Extreme programming have a set of rules and practices that occur within
the context of four framework activities: planning, design, coding, and
testing.
Extreme Programming (XP) contd.

Extreme Programming (XP) process

Extreme Programming (XP) contd.
 1. Planning:
 The planning activity begins with the creation of a set of stories that describe required features
and functionality for software to be built.
 Each story is written by the customer and is placed on an index card. The customer assigns a
value to the story based on the overall business value of the feature of function.
 Members of the XP (Extreme Programming) team then assess each story and assign a cost –
measured in development weeks – to it.
 If the story will 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.
 Customers and the XP team work together to decide how to group stories into the next release
to be developed by the XP team.
 Once a basic commitment is made for a release, the XP team orders the stories that will be
developed in one of three ways:
 All stories will be implemented immediately.
 The stories with highest value will be moved up in the schedule and implemented first.
 The riskiest stories will be moved up in the schedule and implemented first.
 As development work proceeds, the customer can add stories, change the value of an existing
story, split stories or eliminate them.
 The XP team then reconsiders all remaining releases and modifies its plan accordingly.
Extreme Programming (XP) contd.
 2. Design :
 XP design follows the KIS (Keep It Simple) principle. A simple design is always
preferred over a more complex representation.
 The design provides implementation guidance for a story as it is written – nothing
less, nothing more.
 XP encourages the use of CRC (Class Responsibility Collaborator) cards as an
effective mechanism for thinking about the software is an object oriented context.
 CRC cards identify and organize the object oriented classes that are relevant to
current software increment.
 The CRC cards are the only design work product produced as a part of XP
process.
 If a difficult design is encounter as a part of the design of a story, XP
recommends the immediate creation of that portion of the design called as ‘spike
solution’.
 XP encourages refactoring – a construction technique.
Extreme Programming (XP) contd.
 3. Coding
 XP recommends that after stories are developed and preliminary design work is done,
the team should not move to cord, but rather develop a series of unit test that will be
exercise each stories.
 Once the unit test has been created, the developer better able to focus on what must
be implemented to pass the unit test.
 Once the code complete, it can be unit tested immediately, thereby providing
instantaneous feedback to the developer.
 A key concept during the coding activity is pair programming. XP recommends that
two people work together at one computer workstation to create code for a story. This
provides a mechanism for real time problem solving and real time quality assurance.
 As pair programmers complete their work, the code they developed is integrated with
the work of others.
 This continuous integration strategy helps to avoid compatibility and interfacing
problems and provides a smoke testing environment that helps to uncover errors
early.
Extreme Programming (XP) contd.
 4. Testing :
 The creation of unit test before coding is the key element of the XP
approach.
 The unit tests that are created should be implemented using a framework
that enables them to be automated. This encourages regression testing
strategy whenever code is modified.
 Individual unit tests are organize into a “Universal Testing Suit”, integration
and validation testing of the system can occur on daily basis. This provides
the XP team with a continual indication of progress and also can raise
warning flags early if things are going away.
 XP acceptance test, also called customer test, are specified by the customer
and focus on the overall system feature and functionality that are visible
and reviewable by the customer.
 A Tool Set for the Agile Process
 Collaborative and communication “tools” are physical whiteboards, poster
sheets, index cards(CRC), and sticky notes that provides information and
coordination among agile developers.
 Active communication tool is pair programming, while passive
communication is “information radiators” such as a flat panel display that
presents the overall status of different components of an increment.
 Project management tools are earned value charts or “graphs of tests created
versus passed it with.
 other agile tools are used to optimize the environment in which the agile
team works (e.g., more efficient meeting areas like zoom ,google meet etc.),
 other agile tools are used to improve the team culture by nurturing social
interactions(e.g., collocated teams), physical devices (e.g., electronic
whiteboards), and process enhancement (e.g., pair programming or time-
boxing)”.
 Core Principles
Principles That Guide Process
 Principle 1. Be agile
 Principle 2. Focus on quality at every step
 Principle 3. Be ready to adapt
 Principle 4. Build an effective team
 Principle 5. Establish mechanisms for communication and coordination
 Principle 6. Manage change
 Principle 7. Assess risk.
 Principle 8. Create work products that provide value for others
 Core Principles contd.
Principles That Guide Practice
Principle 1. Divide and conquer
Principle 2. Understand the use of abstraction
Principle 3. Strive for consistency
Principle 4. Focus on the transfer of information
Principle 5. Build software that exhibits effective modularity
Principle 6. Look for patterns
Principle 7. When possible, represent the problem and its solution from
a number of different perspectives.
Principle 8. Remember that someone will maintain the software
Principles That Guide Each Framework Activity.
Planning Principles
planning is conducted, the following principles always apply:
Principle 1. Understand the scope of the project
Principle 2. Involve stakeholders in the planning activity
Principle 3. Recognize that planning is iterative
Principle 4. Estimate based on what you know.
Principle 5. Consider risk as you define the plan.
Principle 6. Be realistic.
Principle 7. Adjust granularity as you define the plan.
Principle 8. Define how you intend to ensure quality.
Principle 9. Describe how you intend to accommodate change.
Principle 10. Track the plan frequently and make adjustments as required.
Principles That Guide Each Framework Activity contd.

Modeling Principles
Define a set of modeling principles that appropriate for all software
engineers who perform modeling actions and tasks in agile process model:
Principle 1. The primary goal of the software team is to build software,not create models.
Principle 2. Travel light—don’t create more models than you need.
Principle 3. Strive to produce the simplest model that will describe the problem or the software.
Principle 4. Build models in a way that makes them amenable to change.
Principle 5. Be able to state an explicit purpose for each model that is created.
Principle 6. Adapt the models you develop to the system at hand.
Principle 7. Try to build useful models, but forget about building perfect models.
Principle 8. Don’t become dogmatic about the syntax of the model. If it communicates content
successfully, representation is secondary.
Principle 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.
Principle 10. Get feedback as soon as you can.
Principles That Guide Each Framework Activity contd.
Requirements modelling principles.
 Principle 1. The information domain of a problem must be represented and
understood.
 Principle 2. The functions that the software performs must be defined.
 Principle 3. The behaviour of the software (as a consequence of external
events) must be represented.
 Principle 4. The models that depict information, function, and behaviour
 must be partitioned in a manner that uncovers detail in a layered (or
hierarchical) fashion.
 Principle 5. The analysis task should move from essential information
toward implementation detail.
Principles That Guide Each Framework Activity contd.
Design Modeling Principles.
 Principle 1. Design should be traceable to the requirements model.
 Principle 2. Always consider the architecture of the system to be built.
 Principle 3. Design of data is as important as design of processing functions.
 Principle 4. Interfaces (both internal and external) must be designed with care.
 Principle 5. User interface design should be tuned to the needs of the end user.
However, in every case, it should stress ease of use.
 Principle 6. Component-level design should be functionally independent.
 Principle 7. Components should be loosely coupled to one another and to the
external environment.
 Principle 8. Design representations (models) should be easily understandable.
 Principle 9. The design should be developed iteratively. With each
 iteration, the designer should strive for greater simplicity.
 Principles That Guide Each Framework Activity contd.
Construction Principles
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.
 • Create a set of unit tests that will be applied once the component
you code is completed.
 Principles That Guide Each Framework Activity contd.
 Construction Principles
Coding Principles.
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.
 • Select meaningful variable names and follow other local coding standards.
 Write code that is self-documenting.
 • Create a visual layout (e.g., indentation and blank lines) that aids
 understanding.
Principles That Guide Each Framework Activity contd.
Construction Principles
Coding Principles.
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.
Principles That Guide Each Framework Activity contd.
Testing Principles:
Testing is a process of executing a program with the intent of finding an error. A
good test case is one that has a high probability of finding an as-yet undiscovered
error. A successful test is one that uncovers an as-yet-undiscovered error.

In a classic book on software testing, states a number of rules that can serve well as
testing objectives:

 Principle 1. All tests should be traceable to customer requirements.

 Principle 2. Tests should be planned long before testing begins.
 Principle 3. The Pareto principle applies to software testing.
 Principle 4. Testing should begin “in the small” and progress toward testing “in
the large.”
 Principle 5. Exhaustive testing is not possible.
 Principles That Guide Each Framework Activity contd.
Deployment Principles:
The delivery of a software increment represents an important milestone for
any software project.
 A number of key principles should be followed as the team prepares to
deliver an increment:
 Principle 1. Customer expectations for the software must be managed.
 Principle 2. A complete delivery package should be assembled and
tested.
 Principle 3. A support regime must be established before the software is
delivered.
 Principle 4. Appropriate instructional materials must be provided to end
users.
 Principle 5. Buggy software should be fixed first, delivered later.
 Requirements Engineering
 The 7 tasks ( inception, elicitation, elaboration, negotiation, specification, validation, and
management) and 4 techniques (called data analysis or conceptual or logical models like
DFD,ERD,STD,DD)that are used to an understanding of requirements is called requirements
engineering.

 From a software process perspective, requirements engineering is a major software engineering

action that begins during the communication activity and continues into the modelling activity. It
must be accommodated to the needs of the process, the project, the product, and the people
doing the work.

 Requirements engineering have seven distinct tasks: inception, elicitation, elaboration,

negotiation, specification, validation, and management. It is important to note that some of these
tasks occur in parallel and all are accommodated to the needs of the software project.

 Requirements engineering builds a bridge to communication and modelling.

Requirements Modelling
Communication Analysis & Design
Engineering
 Requirements Engineering contd.
 Inception:
 At project inception, you establish a basic understanding of the problem,
the people who want a software solution and the preliminary
communication and collaboration between the stakeholders and the
software team.

 Elicitation:
In elicitation you should ask the customer, the users, and others
 What are the objectives for the software system or software product?
 What is to be done?
 How the software system or software product fits into the needs of the
business?
 and finally, how the software system or software product is to be used on a
day-to-day basis?
 Requirements Engineering contd.
Eloboration:
 The information obtained from the customer during inception and elicitation is expanded and
refined during elaboration. This task focuses on developing a refined requirements model that
identifies various aspects of software function, behaviour, and information.

 Elaboration is driven by the creation and refinement of user scenarios that describe how the end
user (and other actors) will interact with the system. Each user scenario is parsed(converted) to
extract analysis classes are business domain entities that are visible to the end user.

 In Elaboration, you should

 Define ,The attributes of each analysis class is identified?
 Identify the services or functionalities that are required by each analysis class is identified?
 identify The relationships and collaboration between analysis classes are identified?
 and produce a variety of supplementary diagrams
 Requirements Engineering contd.
Negotiation:
 It’s relatively common for different customers or users to propose
conflicting requirements, arguing that their version is “essential for our
special needs.”
 You have to reconcile these conflicts through a process of negotiation.
Customers, users, and other stakeholders are asked to rank requirements
and then discuss conflicts in priority. Using an iterative approach that
prioritizes requirements, assesses their cost and risk, and addresses internal
conflicts, requirements are eliminated, combined, and/or modified so that
each party achieves some measure of satisfaction.
 Requirements Engineering contd.
Specification:
 A specification can be a
 Written Document(SRS-software requirements specification )
 Set of Graphical Models
 Formal Mathematical Model
 Collection of Usage Scenarios(use cases)
 Prototype(frame work or model )
 or Any Combination of these.
 Requirements Engineering contd.
 Validation:

 The work products produced as a consequence of requirements engineering are assessed for quality during a
validation step.

 Requirements validation examines the specification to ensure that all software requirements have been
stated unambiguously(clearly).
 Requirements validation examines the specification to ensure that all software requirements inconsistencies,
omissions, and errors have been detected and corrected.
 Requirements validation examines the specification to ensure that the work products conform to the
standards established for the process, the project, and the product.

 The primary requirements validation mechanism is the technical review.

 The review team (that validates requirements) includes software engineers, customers, users, and other
stakeholders who examine the specification. Looking for
 Errors in content or interpretation
 Areas where clarification may be required
 Missing information
 Inconsistencies (a major problem when large products or systems are engineered)
 Conflicting requirements
 Unrealistic (unachievable)requirements.
 Requirements Engineering contd.
Requirements management(or maintenance):
 Requirements for computer-based systems change, and the desire to change
requirements continue throughout the life of the system.
 Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at any
time as the project proceeds. Many of these activities are identical to the
software configuration management (SCM) techniques.
 Requirements Elicitation
 Requirements Elicitation (also called requirements gathering) combines
elements of problem solving, elaboration, negotiation, and specification of
requirements engineering.

 Requirements elicitation (also called requirements gathering) approaches or

methods or techniques
 Collaborative Gather Requirements
 Quality function deployment (QFD)
 Usage Scenarios
 Elicitation Work Products
 Requirements Elicitation cond.
 Collaborative(involve one or more parties) Gathering Requirements
 The following are basic guidelines:
• Meetings are conducted and attended by both software engineers and other stakeholders.
• Rules for preparation and participation are established.
• An agenda is suggested that is to cover all important points.
• A “facilitator” (can be a customer, a developer, or an outsider) controls the meeting.
• A “definition mechanism” (can be work sheets, flip charts, or wall stickers or
an electronic bulletin board, chat room, or virtual forum) is used.
 Requirements Elicitation cond.
 Quality function deployment (QFD):
 Quality function deployment (QFD) is a quality management technique that translates
 the needs of the customer into technical requirements for software. QFD “concentrates on maximizing
customer satisfaction from the software engineering process”. QFD high lights an understanding of what
is valuable to the customer and then deploys these values throughout the engineering process.

 QFD has three types of requirements :

 Normal requirements: The objectives and goals that are stated for a product or system during meetings
with the customer. If these requirements are present, the customer is satisfied. Examples of normal
requirements might be requested types of graphical displays, specific system functions, and defined
levels of performance.

 Expected requirements: These requirements are implicit to the product or system and may be so
fundamental that the customer does not explicitly state them. Their absence will be a cause for
significant dissatisfaction.
Examples of expected requirements are: ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation.

 Exciting requirements: These features go beyond the customer’s expectations and prove to be very
satisfying when present.
For example, software for a new mobile phone comes with standard features, but is coupled with a set of
unexpected capabilities (e.g., multitouch screen, visual voice mail) that delight every user of the product.
 Requirements Elicitation cond.
 Usage Scenarios
The scenarios are often called use cases provide a description of how the system functions and features will be used by
different classes of end users.

 Elicitation Work Products

 The work products produced as a consequence of requirements elicitation will vary depending on the size of the system or
product to be built.

For most systems, the work products include

• A statement of need and feasibility.
• A bounded statement of scope for the system or product.
• A list of customers, users, and other stakeholders who participated in requirements elicitation.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraints that apply to each..
• A set of usage scenarios that provide insight into the use of the system or product under different
operating conditions.
• Any prototypes developed to better define requirements.
Each of these work products is reviewed by all people who have participated in requirements elicitation
 DEVELOPING USE CASES
A use case tells a stylized story about how an end user (playing one of a
number of possible roles) interacts with the system under a specific set of
circumstances. The story may be narrative text, an outline of tasks or
interactions, a template-based description, or a diagrammatic
representation. Regardless of its form, a use case depicts the software or
system from the end user’s point of view.
Building the Requirements(Analysis) Model
Elements of the Requirements(Analysis ) Model
 Scenario-based model elements—represented by UML Use Case Diagram
 Class-based model elements--represented by UML Class Diagram.
 Behavioural model elements--represented by UML State Diagram
 Flow-oriented model elements--represented by UML Data Flow Diagram
Building the Requirements Model Contd.

Scenario-based model elements—represented by UML Use Case

Diagram:

A use case tells a stylized story about how an end user (playing one of a
number of possible roles) interacts with the system under a specific set of
circumstances. The story may be narrative text, an outline of tasks or
interactions, a template- based description, or a diagrammatic representation.
Regardless of its form, a use case depicts the software or system from the end
user’s point of view.
Building the Requirements Model Contd.
Class-based model elements –represented by UML Class diagram:
 Each usage scenario implies a set of objects(called as class) that are
manipulated as an actor interacts with the system. These objects are
categorized into classes. A class is a collection(or set) of objects that have
similar attributes and common behaviors.
Building the Requirements Model Contd.
Behavioural Model elements—represented by UML state
diagram:
 The state diagram is one method for representing the behaviour of a system
by depicting its states and the events that cause the system to change state.
 A state is any externally observable mode of behaviour. In addition, the
state diagram indicates actions (e.g., process activation) taken as a
consequence of a particular event.
Building the Requirements Model Contd.
Flow-oriented elements:
Information is transformed(moved) as it flows through a computer-based
system. The system accepts input in a variety of forms, applies functions to
transform it, and produces output in a variety of forms. Input may be a control
signal transmitted by a transducer, a series of numbers typed by a human
operator, a packet of information transmitted on a network link, or a
voluminous data file retrieved from secondary storage. The transform(s) may
comprise a single logical comparison, a complex numerical algorithm, or a
rule-inference approach of an expert system. Output may light a single LED
or produce a 200-page report. In effect, we can create a flow model for any
computer-based system, regardless of size and complexity.
NEGOTIATING REQUIREMENTS
 Boehm [Boe98] defines a set of negotiation activities at the beginning of
each software process iteration. Rather than a single customer
communication activity, the following activities are defined:
 1. Identification of the system or subsystem’s key stakeholders.
 2. Determination of the stakeholders’ “win conditions.”
 3. Negotiation (combine/delete/modify requirements)of the stakeholders’
win conditions to compose them into a set of win-win conditions for all
concerned (including the software team).

Requirements prioritization and negotiation Inevitably, when multiple stakeholders

are involved, requirements will conflict. This activity is concerned with
prioritizing requirements and finding and resolving requirements conflicts
through negotiation. Usually, stakeholders have to meet to resolve differences
and agree on compromise requirements.
 Validating Requirements.
During the requirements validation process, different types of checks should be
carried out on the requirements in the requirements document.
These checks include:
1. Validity checks :A user may think that a system is needed to perform certain
functions. However, further thought and analysis may identify additional or
different functions that are required.

2. Consistency checks :Requirements in the document should not conflict. That is,
there should not be contradictory constraints or different descriptions of the same
system function.

3. Completeness checks :The requirements document should include requirements that

define all functions and the constraints intended by the system user.

4. Realism checks :Using knowledge of existing technology, the requirements should

be checked to ensure that they can actually be implemented. These checks should
also take account of the budget and schedule for the system development.