Unit3.pptx

Software Engineering Modeling and Design
Agile Development
 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.
The development guidelines stress delivery over analysis and design, and active
and continuous communication between developers and customers.
Agile Development Process Mr. N. L. Shelake Department of Information Technology

What is an Agile Process?
Any agile software process is characterized in a manner that addresses a number of
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.
 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.

What is an Agile Process?
Any agile software process is characterized in a manner that addresses a number of
key assumptions about the majority of software projects:
Analysis, design, construction, and testing are not as predictable (from a
planning point of view) as we might like.

What is Agility?
 Agility in software engineering refers to the ability of a software development
team to respond quickly and effectively to changes in project requirements or
market demands.
 The team works closely with the customer or product owner to prioritize
features and adjust the project scope as needed.
 Twelve Principles

The Cost of Change

Agile Principles
 Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

Agile Principles
 Welcome changing requirements, even late in development.Agile processes
harness change for the customer’s competitive advantage.

Agile Principles
 Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.

Agile Principles
 Business people and developers must work together daily throughout the
project

Agile Principles
 Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

Agile Principles
 The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation

Agile Principles
 Working software is the primary measure of progress

Agile Principles
Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely

Agile Principles
 Continuous attention to technical excellence and good design enhances
agility.

Agile Principles
 Simplicity—the art of maximizing the amount of work not done—is essential.

Agile Principles
 The best architectures, requirements, and designs emerge from self–organizing
teams.

Agile Principles
 At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

Agile Manifesto
 Document that identifies four key and twelve principles
 Four core values
 Individuals and interactions over processes and tools
 Working s/w over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following plan

SummaryAgile Development
 Fastest Development Methodology
 No Documentation Overhead
 Focus on Code development
 Frequently Delivery
 Customer satisfaction
 Change accepted
 Face to face conversation
 Customer involved in development
 Self organizing, self motivated and highly experienced

Human Factors
 Agile development focuses on the talents and skills of individuals, molding the
process to specific people and teams
 Competence - specific software-related skills, and overall knowledge of the
process that the team has chosen to apply
 Common focus - tasks and bring different skills -focused on one goal-to
deliver a working software increment to the customer within the time
promised
 Collaboration – stakeholders, comp s/w & database
 Decision-making ability - allowed the freedom to control its own destiny
 Mutual trust and respect – among all

Extreme Programming (XP)
 most widely used approach to agile software development.
 XP is lightweight, efficient, low-risk, flexible, predictable and fun way to develop
a software
 Rapidly changing requirements
 XP values - establish a foundation for all work performed as part of XP

XPvalues
 Communication
 Effective communication between s/w engg. and stakeholders
 To establish features and functions for the s/w
 Collaboration between customers & developers continuous feedback, comm.
 Simplicity
 Restricts developers to design only for immediate needs
 Intent is to create a simple design

XPvalues
 Feedback
 Implemented s/w itself, the customer and s/w team members
 By designing and implementing an effective testing strategy
 the software provides the agile team with feedback
 Courage
 Abetter word might be discipline
 “designing for tomorrow”

XPvalues
 Respect
 Respect among members, between other stakeholders and team members and
indirectly, for the s/w itself.
 As they achieve successful delivery of software increments, the team develops
growing respect for the XP process.

The XPProcess

XPvalues
 Planning
 The planning activity begins with listening, requirements gathering
 creation of a set of “stories” (also called user stories)
 basic commitment (agreement on stories to be included, delivery date, and
other project matters)
 Design
 XP design rigorously follows the keep it simple principle
 Asimple design is always preferred over a more complex representation

XPvalues
 Coding
 Refactoring
 Pair programming
 Continuous integration
 Testing
 XP acceptance tests, also called customer tests
 Overall features & functionality that are visible& reviewable by the customer.

Industrial XP
 IXP is an organic evolution of XP
 Incorporate six new practices
 Readiness assessment
 an appropriate development environment exists to support IXP
 the team will be populated by the proper set of stakeholders
 the organization has a distinct quality program and supports continuous
improvement
 the broader project community will be populated appropriately

Industrial XP
 Project community
 Classic XP suggests that the right people be used to populate the agile
team to ensure success
 The implication is that people on the team must be well-trained,
adaptable and skilled, and have the proper temperament to contribute to a
self-organizing team
 Acommunity may have a technologist and customers who are central to
the success of a project as well as many other stakeholders (e.g., legal
staff, quality auditors, manufacturing or sales types)

Industrial XP
 Project charactering
 Project itself to determine appropriate business justification-overall goal-
objectives
 Chartering also examines the context of the project to determine how it
complements, extends, or replaces existing systems or processes.

Industrial XP
 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.

Industrial XP
 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.

Industrial XP
 Continuous Learning
 Because learning is a vital part of continuous process improvement,
members of the XP team are encouraged to learn new methods and
techniques that can lead to a higher quality product.

OtherAgile Process Models
 The most widely used of all agile process models is Extreme Programming
(XP). But 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)
 Feature Driven Development (FDD)

Scrum
 Is an agile software development method that was conceived by Jeff
Sutherland and his development team in the early 1990s.
 Scrum principles are consistent with the agile manifesto
 used to guide development activities within a process that incorporates the
following framework activities:
 requirements
 analysis
 design
 Evolution
 delivery

Scrum
 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 emphasizes the use of a set of software process patterns that have
 proven effective for projects with tight timelines, changing requirements,
and business criticality.

Scrum
 Each of these process patterns defines a set of development actions:
 Backlog—a prioritized list of project requirements or features that provide
business value for the customer. Items can be added to the backlog at any
time (this is how changes are introduced).
 The product manager assesses the backlog and updates priorities as
required.

Scrum
 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.
 Changes are not introduced during the sprint.
 Scrum meetings—are short meetings held daily by the Scrum team.
 Three key questions are asked and answered by all team members :
 What did you do since the last team meeting?
 What obstacles are you encountering?
 What do you plan to accomplish by the next team meeting?

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

Scrum
 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

Scrum Role
 AScrum team consists of three roles: the Scrum Master, the product
owner, and the development team.
 While there is only one Scrum Master and one product owner, there are
generally several development team members.
 Scrum teams are small.
 The Scrum Guide recommends 10 or fewer total members to ensure optimal
communication and productivity

Scrum Master
 AScrum Master is responsible for ensuring a Scrum team is operating as
effectively as possible with Scrum values.
 This means they keep the team on track, plan and lead meetings, and work
out any obstacles the team might face
 Scrum Masters might also work in a larger role within an organization to
help it incorporate Scrum concepts into their work.
 Because they are both a leader and a behind-the-scenes supporter, they are
often described as the “servant leader” of the Scrum team.

Scrum Master
 Scrum can look different from organization to organization and team to team,
making the specific tasks of a Scrum Master varied. Broadly, however, a Scrum Master
might have the following responsibilities:
 Facilitate daily Scrum meetings (also called “daily standups”)
 Lead sprint planning meetings
 Conduct “retrospective” reviews to see what went well and what can be improved
for the following sprint
 Keep a pulse on team members, through individual meetings or other means of
communication.
 Manage obstacles that arise for the team by communicating with stakeholders
outside of the team

Product Owner
 Aproduct owner ensures the Scrum team aligns with overall product
goals.
 They understand the business needs of the product, like customer
expectations and market trends.
 Because they have to understand how the Scrum team fits into bigger
picture goals,
 product owners usually stay in touch with product managers and other
stakeholders outside the team.

Product Owner
 Product owners might find themselves with the following responsibilities:
 Manage the product backlog by ordering work by priority
 Set the product vision for the team
 Communicate with external stakeholders and translate their needs to
the team
 Make sure the team is focused on hitting product needs through
communication and evaluating progress

Development Team
 Adevelopment team is composed of professionals who do the hands-on
work of completing the tasks in a Scrum sprint.
 This means development team members can be computer engineers,
designers, writers, data analysts, or any other role needed to reach sprint
goals.
 The development team doesn’t just wait for orders; they usually collaborate
to map out goals and plans for achieving them.
 Not all development team members will always have the same
responsibilities

Development Team
Development team can be tasked with the following:
 Help in sprint planning and goal setting
 expertise to program, design, or improve products
 Use data to find best practices for development
 Test products and prototypes, plus other forms of quality assurance
 Self-Organized scrums teams
Software Engineering Modeling and Design – Overview Agile Development Process

Scrum Cycle Description
A Scrum sprint cycle is a time-boxed period when a team delivers a set
amount of work.
It is typically two to four weeks in duration and each sprint starts the
moment the previous one is completed.
The Scrum sprint cycle is often referred to as a process of continuous
development.
It delivers a consistent work task for product releases and keeps the
project’s momentum going until complete.

Stages of the Scrum sprint cycle
The official Scrum Guide mentions following events that represent the
Scrum sprint cycle
Sprint planning - Kicking off the Sprint and defining what needs to be
completed
Daily Scrum - Developers meet for fifteen minutes every day to share
what they have worked on, any issues blocking them, and what they will
be working on next
Sprint review - Evaluate what was delivered and decide what should be
worked on in the next sprint

Stages of the Scrum sprint cycle
Sprint retrospective -Areview of the process to improve the next sprint

Sprint planning
Sprint planning is an event in scrum that defines what can be delivered in
the upcoming sprint and how that work will be achieved.
In scrum, the sprint is a set period of time where all the work is done.
Sprint goal, sprint start-end, sprint agenda

Burndown Chart in Scrum
Aburn down chart is a graphical representation of work left to do versus
time
It is often used in agile software development methodologies such as
Scrum.
burn down charts can be applied to any project containing measurable
progress over time.
Typically, in a burn down chart, the outstanding work is often on the vertical
axis, with time along the horizontal.
 It is useful for predicting when all of the work will be completed.

In the Daily Scrum the Development Team updates the Sprint Burn Down
and plots the remaining work of the day. A burndown chart is almost a
“must” have tool for a Scrum team for the following main reasons:
monitoring the project scope
Keeping the team running on schedule
Comparing the planned work against the team progression.

Sprint Review?
A sprint review is a key event in the Scrum framework for
agile software development.
It is held at the end of each sprint, which is a time-boxed
period of typically two to four weeks during which a
development team works on a set of prioritized user stories
or tasks.

Sprint Review?
During Review, demonstrates the work they have
completed during the sprint to the product owner,
stakeholders, and other members of the organization.
goal of the review is to assess the progress of the team,
obtain feedback from stakeholders, and plan for the next
sprint

Sprint Review?
typically involves a presentation of the working
software or product increment that the team has developed
during the sprint.
The team walks through the completed user stories or
tasks, highlighting any challenges or accomplishments that
occurred during the sprint

Sprint Review?
Stakeholders, including the product owner and other
members of the organization, are invited to provide
feedback on the work completed during the sprint.
They may ask questions or provide suggestions for
improvement. This feedback is then taken into consideration
when planning for the next sprint.

Sprint Review?
The sprint review is a critical event in the Scrum framework
that provides an opportunity for the development team to
showcase their work, obtain feedback, and plan for the
next sprint. It is a valuable tool for ensuring that the team is
on track and delivering value to stakeholders

Sprint Retrospective?
The development team reflects on the previous Sprint and
examines how they can improve their processes, teamwork,
and collaboration.
The goal of the retrospective is to identify what went well,
what didn't go well, and what changes the team can make
to become more effective in the next Sprint.

typically led by the Scrum Master, who facilitates the
discussion and helps the team identify areas for improvement
The team reviews the results of the Sprint, including the
completed user stories or tasks, any issues that arose, and
any feedback received from stakeholders during the Sprint
review.

The team then identifies specific action items that they can
take to improve their processes, teamwork, and
collaboration, documented in a Sprint backlog and become
part of the plan for the next Sprint.
Tool for the development team to continuously improve
their processes and become more effective.

Agile Practices - 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.
Refactoring allows a software engineer to improve the internal structure of a
design (or source code) without changing its external functionality or
behavior.

Refactoring
It is a disciplined way to clean up code [and modify/simplify the internal
design] that minimizes the chances of introducing bugs.
In essence, when you refactor you are improving the design of the code after
it has been written.
refactoring can be used to improve the efficiency, readability, or
performance of a design or the code that implements a design.

Pair Programming
XP recommends that two people work together at one computer workstation
to create code for a story.
This provides a mechanism for realtime problem solving (two heads are
often better than one) and real-time quality assurance (the code is reviewed
as it is created).
It also keeps the developers focused on the problem at hand. In practice,
each person takes on a slightly different role

Pair Programming
For example,
one person might think about the coding details of a particular portion of
the design while the other ensures that coding standards (a required part of
XP) are being followed or that the code for the story will satisfy the unit
test that has been developed to validate the code against the story

Pair Programming + continuous integration
As pair programmers complete their work, the code they develop is
integrated with the work of others. In some cases this is performed on a
daily basis by an integration team.
 In other cases, the pair programmers have integration responsibility.
This “continuous integration” strategy helps to avoid compatibility and
interfacing problems and provides a “testing” environment that helps to
uncover errors early

Pair Programming
Pair programming can be characterized as a continuous desk check. Rather
than scheduling a review at some point in time,
pair programming encourages continuous review as a work product (design
or code) is created.

Test-Driven Development
Requirements drive design, and design establishes a foundation for
construction
requirements for a software component serve as the basis for the creation of
a series of test cases that exercise the interface and attempt to find errors in
the data structures and functionality delivered by the component
TDD is not really a new technology but rather a trend that emphasizes the
design of test cases before the creation of source code.

Test-Driven Development

Exploratory Testing
Exploratory testing is a testing approach where testers test the
system while exploring it on the fly without any test documents to
refer to.
test design, and test execution take place parallel
mainly useful in projects where rapid deliveries are expected, and
frequent changes are integrated
testers may need to test the system frequently and quickly.

Scripted Testing
Scripted testing is an approach where the testing team sticks to the
script that consists of test cases and detailed steps
Testing Team follows these written test cases and executes them
and tries to find any bugs in the system.
the testing team prepares various documents such as test plan, test
case specification, and many others based on the requirements
specification
goal of scripted testing is to keep the necessary documents ready
before the testing process

Scripted Testing vs Exploratory Testing
Scripted Testing Exploratory Testing
Before starting the testing, the testing
team prepares the documents
required for the testing process such
as test plan, test cases.
The testing team does not need any
test documents to start the testing.
Testers test the system by following
the steps mentioned in test plan and
test cases.
Testers test the system based on their
skills and understanding of the
system without following any test
documents

Scripted Testing vs Exploratory Testing
Scripted Testing Exploratory Testing
Scripted testing is used in projects where
there is enough time reserved for the testing
phase. For example, projects being
developed using traditional software
development methodologies.
Exploratory testing is used in projects
where there isn’t enough time for the test
planning phase or test document creation.
Examples include projects developed using
agile methodology as they demand rapid
delivery
For scripted testing, clear and complete
requirements specification is a must.
While conducting exploratory testing,
testers can proceed further even without
incomplete or no documentation. This is
because they can explore the system on
their own and learn the functionalities

Thank You

Unit3.pptx

More Related Content

What's hot

Similar to Unit3.pptx

More from Nitin Shelake

Recently uploaded

Unit3.pptx