Software Engineering

Unit - II
 UNIT- II
• Agility: Cost of Change- Agile Process- Extreme Programming-
Other Agile Process Models: Scrum- Dynamic Systems
Development Method- Agile Modeling- Agile Unified Process-
Tool Set for the Agile Process

• Characteristics of a Software Engineer: Software Team and

Team Structure - Agile Teams - Impact of Social Media -
Software Engineering Using the Cloud - Collaboration Tools

• Software Engineering Knowledge: Core Principles - Principles

That Guide Each Framework Activity - Work Practices.
 Agility - Intro
• Software development methodology to build software incrementally using
short iterations of 1 to 4 weeks

• An agile team is a nimble team able to respond to changes.

➔ Change is what software development is very much about
➔ 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
 Agility Software Development

Agile software development is an iterative and incremental

(evolutionary) approach to software development which is
performed in a highly collaborative manner by self-organizing
teams within an effective governance framework with "just
enough" ceremony that produces high quality solutions in a cost
effective and timely manner which meets the changing needs of
its stakeholders.
 What is Agility?
● Agility is an effective response to change. It encourages team
structures and attitudes that make communication more facile (too
easy)

● It emphasizes rapid delivery of operational software

● It adopts the customer as a part of the development team and

recognizes that planning has its limit and that a project plan must
be flexible
 Agility & the Cost of Change
• The conventional wisdom in software development is that the cost of change
increases non linearly as a project progresses.

• It is relatively easy to accommodate a change when a software team is

gathering requirements.

• But if team is in middle of validation testing and an important stakeholder is

requesting a change.
 Agility & the Cost of Change [Cont..]

• The time and cost required to ensure that the change is made
without unintended side effects is nontrivial.

• A well-designed agile process flattens the cost of change curve,

allowing a software team to accommodate changes late in a
software project without dramatic cost and time impact.
 What is an Agile Process?
Agile process is characterized in a manner that addresses a number of
key assumptions about majority of the software projects:

1. It is difficult to predict in advance which software requirements will

persist and which will change. It is difficult to predict how customer
priorities will change as the project proceeds.
2. For many type of projects, design and construction are interleaved.
3. Analysis, design, construction and testing are not as predictable as
we might like.

An agile process must adapt incrementally.

 Agility Principles
1. Our first priority is to satisfy the customer through early and continuous delivery of
valuable software

2. Welcome changing requirements

3. Deliver working software frequently (weeks rather than months)

4. Business people and developers must work together daily throughout the project

5. Build Projects around motivated individuals. Give them 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 daily cooperation between business
people and developers
 Agility Principles
7. Working software is the primary measure of progress.

8. Agile process 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 the 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.
 Human Factors
Agile development focuses on the talents and skills of individuals,
molding the process to specific people and teams. Key traits must
exist among the people on effective software team

• Competence (Skill) : Competence encompasses innate talent,

specific software-related skills, and overall knowledge of the
process that team has chosen to apply

• Common focus : Although members of agile team may perform

different tasks and bring different skills to the project, all should
be focused on one goal- to deliver a working software increment
to the customer within the time promised
 Human Factors
• Collaboration : SE is about assessing, analyzing, and using
information that is communicated to the software team; creating
information that will help all stakeholders understand the work of
the team. To accomplish these tasks, team members must
collaborate.
• Decision-making ability : Any good team must be allowed the
freedom to control its own destiny. Decision-making authority for
both technical and project issues.
• Fuzzy problem-solving ability : The team must accept the fact that
the problem that they are solving today may not be solved
tomorrow. Lessons learned from any problem-solving activity may
be benefit to the team later in project.
 Human Factors
• Mutual trust and respect : The agile team must become
a “jelled” team. 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 parts.”

• Self-organization : The agile team must organize itself

for the work to be done. The team organizes the work
schedule to best achieve delivery of the software
increment.
 Extreme Programming
• XP used approach to agile software development, emphasizes business results
first and takes an incremental, get-something-started approach to building the
product, using continual testing and revision.

XP Values
• “Beck” defines a set of five values that establish a foundation for all work
performed as part of XP—communication, simplicity, feedback, courage, and
respect.

• Each of these values is used as a driver for specific XP activities, actions, and
tasks.
 XP Values
• Effective communication between software engineers and other stakeholders,
XP emphasizes close, yet informal collaboration between customers and
developers, the establishment of effective metaphors3 for communicating
important concepts, continuous feedback, and the avoidance of voluminous
documentation as a communication medium.

• To achieve simplicity, XP restricts developers to design only for immediate

needs, rather than consider future needs. If the design must be improved, it
can be refactored at a later time.

• Feedback is derived from three sources: the implemented software itself, the
customer, and other software team members. By designing and implementing
an effective testing strategy the software provides the agile team with
feedback. XP makes use of the unit test as its primary testing tactic.
 XP Values

• Agile XP team must have the discipline (courage) to design for today,
recognizing that future requirements may change dramatically,
demanding substantial rework of the design and implemented code.

• 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 as its
preferred development paradigm
and encompasses a set of rules
and practices that occur within
the context of four framework
activities: planning, design,
coding, and testing.
 The XP Process
Key XP activities are
• Planning:-
• The planning activity (also called the planning game) begins with listening - a
requirements gathering activity
• Enables the technical members of the XP team to understand the business context for
the software and to get a broad feel for required output and major features and
functionality.
Design:-
• A simple design is preferred over a more complex representation.
• 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 a method for design
optimization.
 The XP Process [Cont..]
• Fowler describes refactoring in the following manner:
“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. It is a
disciplined way to clean up code” [that minimizes the chances of introducing bugs]

• Coding :- After stories are developed and preliminary design work is done, the team does
not move to code, but rather develops a series of unit tests that will exercise each of the
stories that is to be included in the current release.
Once the code is complete, it can be unit-tested immediately, thereby providing
instantaneous feedback to the developers.

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 (two heads are often better than
one) and real-time quality assurance.
 The XP Process [Cont..]
Testing:-
• The creation of unit tests before coding commences is a key element of the XP
approach.
• The unit tests that are created enables to be automated. This encourages a
regression testing strategy whenever code is modified. As the individual unit
tests are organized into a “universal testing suite” integration and validation
testing of the system can occur on a daily basis.

Wells states: “Fixing small problems every few hours takes less time than fixing
huge problems just before the deadline.”

XP acceptance tests - called customer tests, are specified by the customer and
focus on overall system features and functionality that are visible and reviewable
by the customer.
 XP Industrial Process
Joshua Kerievsky describes Industrial Extreme Programming (IXP) in the
following manner:

“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.
 XP Industrial Process - Six new practices
Readiness assessment
(1) An appropriate development environment exists to support IXP
(2) Team will be populated by the proper set of stakeholders,
(3) Organization has a distinct quality program & supports continuous
improvement,
(4) Organizational culture will support the new values of an agile team
(5) Broader project community will be populated appropriately.
Project community.
• ClassicXP suggests that the right people be used to populate the agile team to
ensure success.
•
• Team must be well- trained, adaptable and skilled, and have the proper
temperament to contribute to a self-organizing team.
• When XP is to be applied for a significant project in a large organization, the
concept of the “team” should morph into that of a community.
 XP Industrial Process - Six new practices
Project chartering
• Chartering also examines the context of the project to determine how it
complements, extends, or replaces existing systems or processes.
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. Test-driven management establishes a series
of measurable “destinations” and then defines mechanisms for determining whether
or not these destinations have been reached.
Retrospectives
• An IXP team conducts a specialized technical review after a software increment is
delivered. Called a retrospective, the review examines “issues, events, and
lessons-learned” across a software increment and/or the entire software release. The
intent is to improve the IXP process.
Continuous learning
Because learning is a vital part of continuous process improvement, members of the XP
team are encouraged (and possibly, incented) to learn new methods and techniques that
can lead to a higher quality product.
 Other Agile Process Models
• 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)
 Scrum
• Jeff Sutherland - 1990s.
Scrum principles are
consistent with the agile
• Requirements, analysis,
design, evolution, and
delivery - Within each
framework activity, work
tasks occur within a process
pattern called a sprint.
• The work conducted within a
sprint is adapted to the
problem at hand and is
defined and often modified in
real time by the Scrum team.
 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:

• Backlog - prioritized list of project requirements or 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.
 Scrum
Scrum meetings - are short (typically 15 minutes) meetings held daily by the
Scrum team. Three key questions are asked and answered by all team members
o What did you do since the last team meeting?
o What obstacles are you encountering?
o What do you plan to accomplish by the next team meeting?
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”
Demos - deliver the software increment to the customer so that functionality that
has been implemented can be demonstrated and evaluated by the customer. It is
important to note that the demo may not contain all planned functionality, but
rather those functions that can be delivered within the time-box that was
established.
 Dynamic Systems Development Method (DSDM)

• DSDM is an agile software development approach that “provides a

framework for building and maintaining systems which meet tight time
constraints through the use of incremental prototyping in a controlled project
environment”
• The DSDM philosophy is borrowed from a modified version of the Pareto
principle - 80 percent of an application can be delivered in 20 percent of the
time.
• It would take to deliver the complete (100 percent) application.
• DSDM is an iterative software process in which each iteration follows the 80
percent rule. That is, only enough work is required for each increment to
facilitate movement to the next increment.
• The remaining detail can be completed later when more business
requirements are known or changes have been requested and accommodated.
 DSM Life Cycle
• The DSDM life cycle that defines three different iterative cycles, preceded
by two additional life cycle activities:
• Feasibility study - establishes the basic business requirements and
constraints associated with the application to be built and then assesses
whether the application is a viable candidate for the DSDM process

• Business study - establishes the functional and information

requirements that will allow the application to provide business value;
Defines the basic application architecture and identifies the
maintainability requirements for the application.

• Functional model iteration - produces a set of incremental prototypes

that demonstrate functionality for the customer.
 DSM Life Cycle
• Design and build iteration - revisits prototypes built during functional
model iteration to ensure that each has been engineered in a manner that
will enable it to provide operational business value for end users.
• In some cases, functional model iteration and design and build iteration
occur concurrently.

• Implementation - places the latest software increment into the operational

environment.
(1) the increment may not be 100 percent complete or
(2) changes may be requested as the increment is put into place.

In either case, DSDM development work continues by returning to the

functional model iteration activity.
 Agile Modeling (AM)
• Agile Modeling (AM) is a practice-based methodology for effective modeling
and
• documentation of software-based systems.

• 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
• Agile Modeling suggests a wide array of “core” and “supplementary” modeling
principles, those that make AM unique are :

• Model with a purpose. A developer who uses AM should have a specific goal
in mind before creating the model. Once the goal for the model is identified, the
type of notation to be used and level of detail required will be more obvious.

• Use multiple models. There are many different models and notations that can
be used to describe software. Only a small subset is essential for most projects.
AM suggests that to provide needed insight, each model should present a
different aspect of the system and only those models that provide value to their
intended audience should be used.
 Agile Modeling
• Travel light. As software engineering work proceeds, keep only those models that
will provide long-term value and jettison the rest. Every work product that is kept
must be maintained as changes occur. This represents work that slows the team down.
Ambler notes that “Every time you decide to keep a model you trade-off agility for the
convenience of having that information available to your team in an abstract manner

• Content is more important than representation. Modeling should impart information

to its intended audience. A syntactically perfect model that imparts little useful content
is not as valuable as a model with flawed notation that nevertheless provides valuable
content for its audience.

• Know the models and the tools you use to create them. Understand the strengths and
weaknesses of each model and the tools that are used to create it.

• Adapt locally. The modeling approach should be adapted to the needs of the agile
team.
 Agile Unified Process (AUP)
• The Agile Unified Process (AUP) adopts a “serial in the large” and “iterative in
the small” philosophy for building computer-based systems.

• By adopting the classic UP phased activities - inception, elaboration,

construction, and transition - AUP provides a serial overlay that enables a team
to visualize the overall process flow for a software project. However, within
each of the activities, the team iterates to achieve agility and to deliver
meaningful software increments to end users as rapidly as possible. Each AUP
iteration addresses the following activities.

• Modeling. UML representations of the business and problem domains are created.
 Agile Unified Process (AUP)
• Implementation. Models are translated into source code.
• Testing. Like XP, the team designs and executes a series of tests to uncover
errors and ensure that the source code meets its requirements.
• Deployment. Like the generic process activity deployment in this context
focuses on the delivery of a software increment and the acquisition of
feedback from end users.
• Configuration and project management. In the context of AUP, configuration
management addresses change management, risk management, and the
control of any persistent work products that are produced by the team.
Project management tracks and controls the progress of the team and
coordinates team activities.
Environment management. Environment management coordinates a process
infrastructure that includes standards, tools, and other support technology
available to the team.