You are on page 1of 54

Rapid Software Development

CSC 3325: Software Engineering II


Dr. Bouchaib Falah

1
Objectives

To explain how an iterative, incremental development process


leads to faster delivery of more useful software
To discuss the essence of agile development methods
To explain the principles and practices of extreme
programming
To explain the roles of prototyping in the software process
Topics Covered

Agile methods
Extreme programming
Scrum
Rapid application development
Software prototyping
Rapid Software Development
Because of rapidly changing business environments,
businesses have to respond to new opportunities and
competition.
This requires rapid development and delivery of software
Businesses may be willing to accept lower quality software if
rapid delivery of essential functionality is possible.
Requirements

Because of the changing environment, it is often impossible to


arrive at a stable, consistent set of system requirements.
Therefore a waterfall model of development is impractical and
an approach to development based on iterative specification
and delivery is the only way to deliver software quickly.
Characteristics of RAD Processes

RAD is a process through which the development cycle of


an application is expedited.
The processes of specification, design and implementation
are concurrent. There is no detailed specification and
design documentation is minimized.
The system is developed in a series of increments. End
users evaluate each increment and make proposals for
later increments.
Agile Methods
Dissatisfaction with the overheads involved in design methods
led to the creation of agile methods. These methods:
choose to do things in small increments with minimal planning, rather
than long-term planning.
Each iteration is worked on by a team through a full software
development cycle in order to minimize the overall risk, and allows the
project to adapt to changes more quickly.
Each iteration is ended by release with minimal bugs
Are intended to deliver working software quickly and evolve this quickly
to meet changing requirements.
emphasize face-to-face communication over written documents in order
to prevent problems being hidden.
Principles of Agile Methods
Customer should be involved throughout the development
process
Customer satisfaction by rapid, continuous delivery of useful
software.
Working software is delivered frequently (weeks rather than
months)
Even late changes in requirements are welcomed
Business people and developers must work together daily
throughout the project.
Face-to-face conversation within a development team is the most
efficient and effective method of conveying information.
Principles of Agile Methods

Projects are built around motivated individuals, who should


be trusted and be given the environment and the support
they need to get the job done
Continuous attention to technical excellence and good
design
Simplicity--the art of maximizing the amount of work not
done--is essential
Principles of Agile Methods
Problems with Agile Methods

It can be difficult to keep the interest of customers who are


involved in the process.
Team members may be unsuited to the intense involvement
that characterizes agile methods.
Prioritizing changes can be difficult where there are multiple
stakeholders.
Maintaining simplicity requires extra work.
Agile Techniques

Specific tools and techniques


Continuous Integration
Pair Programming
Test Driven Development
Design Patterns
Code Refactoring
Agile Methods

Agile methods are "adaptive" method.


Adaptive methods focus on adapting quickly to changing
realities
Agile Methods:
Adaptive Unified Process (AUP)
Extreme Programming (XP)
Scrum
Feature Driven Development (FDD)
Agile Modeling (AM)
Extreme Programming

Perhaps the best-known and most widely used agile method.


Extreme Programming (XP) takes an extreme approach to
iterative development.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;
All tests must be run for every build and the build is only accepted if tests
run successfully.
Extreme Programming

XP uses OO approach
Perfect and very successful with Risky projects with dynamic
requirement.
designed to deliver the software the customer needs when it is
needed
Emphasizes team work. Managers, customers, and developers
are all part of a team dedicated to delivering quality software.
Extreme Programming

XP compasses a set of rules and practices that occur during


the 4 phases of the life cycle:
Planning
Design
Coding
Testing
XP Rules: Planning

Customer writes set of stories (user stories) in index cards


Used to create time estimates for the release planning
meeting
A release planning meeting is used to create release plan
Customer assign a value priority and XP team assesses
and assigns a cost for each story and may require to split
the stories (if more than 3 weeks).
Customer and XP team work together to decide how to
group stories into the next release.
After the first release, XP team computes project velocity.
XP Rules: Design

A system metaphor must be chosen.


XP encourages the use of CRC (Class Responsibility
Collaborator) cards.
If XP design faces difficulties, Operational prototype (Spike
solution) is created.
Refactoring construction technique is used
XP Rules: Coding

XP team develops series of unit tests that will exercise each


story before moving to coding.
Once the unit test has been created, XP team focus on
what must be implemented to pass the unit test.
The key concept of coding activity is Pair Programming
(Two heads are often better than one).
After finishing the implementation, that code will be
integrated with the work of others in a daily basis in order to
avoid compatibility and interfacing problems.
XP Rules: Testing

Integration and validation testing occur on a daily basis-


Customer specifies customer tests (XP acceptance tests)
that are derived from the stories and focus on overall
system features and functionality.
XP and Agile Principles

Incremental development is supported through small, frequent


system releases.
Customer involvement means full-time customer engagement
with the team.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of code.
Story Card for Document
Downloading

Downloading and printing an article

First, you select the article that you want from a displayed list.
You
then have to tell the system how you will pay for it - this can either
be through a subscription, through a company account or by credit
card.
After this, you get a copyright form from the system to fill in and,
when you have submitted this, the article you want is downloaded
onto your computer .
You then choose a printer and a copy of the article is printed.
You
tell the system if printing has been successful.
If the article is a print-only article, you can
t keep the P DF version
so it is automatically deleted from your computer .
XP and Change

Conventional wisdom in software engineering is to design for


change. It is worth spending time and effort anticipating
changes as this reduces costs later in the life cycle.
XP, however, maintains that this is not worthwhile as changes
cannot be reliably anticipated.
Rather, it proposes constant code improvement (refactoring) to
make changes easier when they have to be implemented.
Testing in XP

Test-first development.
Incremental test development from stories.
User involvement in test development and validation.
Automated test harnesses are used to run all component tests
each time that a new release is built.
Test Case Description

Test 4: Test credit card validity

Input:
A string representing the credit card number and two integers representing
the month and year when the card expires
Tests:
Check that all bytes in the string are digits
Check that the month lies between 1 and 12 and the
year is greater than or equal to the current year
.
Using the first 4 digits of the credit card number
,
check that the card issuer is valid by looking up the
card issuer table. Check credit card validity by submitting the card
number and expiry date information to the card
issuer
Output:
OK or error message indicating that the card is invalid
Test-First Development (TFD)

Writing tests before code clarifies the requirements to be


implemented.
Tests are written as programs rather than data so that they can
be executed automatically. The test includes a check that it has
executed correctly.
All previous and new tests are automatically run when new
functionality is added. Thus checking that the new functionality
has not introduced errors.
Pair Programming

In XP, programmers work in pairs, sitting together to develop


code.
This helps develop common ownership of code and spreads
knowledge across the team.
It serves as an informal review process as each line of code is
looked at by more than 1 person.
It encourages refactoring as the whole team can benefit from
this.
Measurements suggest that development productivity with pair
programming is similar to that of two people working
independently.
Chapter3Agilesoftwaredevelopment 28

Scrum
The Scrum approach is a general agile method but its focus is
on managing iterative development rather than specific agile
practices.
There are three phases in Scrum.
The initial phase is an outline planning phase where you establish the
general objectives for the project and design the software architecture.
This is followed by a series of sprint cycles, where each cycle develops
an increment of the system.
The project closure phase wraps up the project, completes required
documentation such as system help frames and user manuals and
assesses the lessons learned from the project.

Chapter3Agilesoftwaredevelopment 29

The Scrum process


The Scrum process
Scrum has been used by:
Microsoft Intuit
Yahoo Nielsen Media
Google First American Real Estate
Electronic Arts BMC Software
High Moon Studios Ipswitch
Lockheed Martin John Deere
Philips Lexis Nexis
Siemens Sabre
Nokia Salesforce.com
Capital One Time Warner
BBC Turner Broadcasting
Intuit Oce
Scrum has been used for:
Commercial software
Video game development
In-house development
FDA-approved, life-critical
Contract development systems
Fixed-price projects Satellite-control software
Financial applications Websites
ISO 9001-certified Handheld software
applications Mobile phones
Embedded systems
Network switching
24x7 systems with applications
99.999% uptime
requirements ISV applications
the Joint Strike Fighter Some of the largest
applications in use
JASS2006 AgileProjectManagementScrum 33

The Process
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
JASS2006 AgileProjectManagementScrum 34

Sprint Planning Meeting


A collaborative meeting in the beginning of each Sprint
between the Product Owner, the Scrum Master and the Team
Takes 8 hours and consists of 2 parts (before lunch and after
lunch)
JASS2006 AgileProjectManagementScrum 35

Parts of Sprint Planning Meeting


1st Part:
Creating Product Backlog
Determining the Sprint Goal.
Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog
Sprints
Scrum projects make progress in a series of sprints
Analogous to Extreme Programming iterations
Typical duration is 24 weeks or a calendar month at most
A constant duration leads to a better rhythm
Product is designed, coded, and tested during the sprint
Chapter3Agilesoftwaredevelopment 37

The Sprint cycle


Sprints are fixed length, normally 24 weeks. They correspond
to the development of a release of the system in XP.
The starting point for planning is the product backlog, which is
the list of work to be done on the project.
The selection phase involves all of the project team who work
with the customer to select the features and functionality to be
developed during the sprint.
Chapter3Agilesoftwaredevelopment 38

The Sprint cycle


Once these are agreed, the team organize themselves to
develop the software. During this stage the team is isolated
from the customer and the organization, with all
communications channelled through the so-called Scrum
master.
The role of the Scrum master is to protect the development
team from external distractions.
At the end of the sprint, the work done is reviewed and
presented to stakeholders. The next sprint cycle then begins.
Chapter3Agilesoftwaredevelopment 39

Teamwork in Scrum
The Scrum master is a facilitator who arranges daily
meetings, tracks the backlog of work to be done, records
decisions, measures progress against the backlog and
communicates with customers and management outside of the
team.
The whole team attends short daily meetings where all team
members share information, describe their progress since the
last meeting, problems that have arisen and what is planned
for the following day.
This means that everyone on the team knows what is going on and, if
problems arise, can re-plan short-term work to cope with them.
The Product Owner

Responsiblefortheproductbacklog
Representstheusers
Clearlyexpressesbacklogitems
Ordersthembyvalue
Ensuresvisibility
The Development Team

Responsiblefordeliveringapotentiallyshippable
incrementofworkingsoftware.
Selforganized
canchangeonlybetweensprints
shouldbefulltime
Crossfunctional
Definespractices
5to10persons
Scrum Master

Responsibleforthescrumprocess

Removesimpediments
Facilitatesscrumevents
Facilitatescommunication
The product Backlog

Singlesourceofrequirementsforanychangestobe
madetotheproduct.

Livinglistthatisnevercomplete
Ordered:value,risk,priority&necessity
Estimatedbytheteam
Daily Scrum

15minutetimeboxedeventfortheTeam
tosynchronizeactivities.

Whathasbeenaccomplishedsincelastmeeting?
Whatwillbedonebeforethenextmeeting?
Whatobstaclesareintheway?
The Sprint Review

4hourtimeboxedmeeting
Productowneridentifieswhathasbeendone
Teamdiscusseswhatwentwell,whatproblemsit
raninto&thosethatweresolved
Teamdemonstrateswhatithasdoneinademo
Productownerdiscussesthebacklogasitstands
Entiregroupcollaboratesonwhattodonext
Rapid Application Development

Agile methods have received a lot of attention but other


approaches to rapid application development have been used
for many years.
These are designed to develop data-intensive business
applications and rely on programming and presenting
information from a database.
Interface Generation

Many applications are based around complex forms and


developing these forms manually is a time-consuming activity.
RAD environments include support for screen generation
including:
Interactive form definition using drag and drop techniques;
Form linking where the sequence of forms to be presented is specified;
Form verification where allowed ranges in form fields is defined.
Visual Programming

Scripting languages such as Visual Basic support visual


programming where the prototype is developed by creating a
user interface from standard items and associating
components with these items
A large library of components exists to support this type of
development
Visual Programming with Reuse

Menu component
Date component

File Edit Views Layout Options Help

General
12th January 000
2 Index
Range checking
3.876
script

User prompt
component +
Draw canvas script
component

Tree display
component
Software Prototyping

A prototype is an initial version of a system used to


demonstrate concepts and try out design options.
A prototype can be used in:
The requirements engineering process to help with requirements
elicitation and validation;
In design processes to explore options and develop a UI design;
In the testing process to run back to back tests.
Benefits of Prototyping

Improved system usability.


A closer match to users real needs.
Improved design quality.
Improved maintainability.
Reduced development effort.
The Prototyping Process

Establish Defi ne
Develop Evaluate
prototype prototype
prototype prototype
objectives functionality

Prototyping Outline Executable Evaluation


plan defi nition prototype report
Key points

An iterative approach to software development leads to faster


delivery of software.
Agile methods are iterative development methods that aim to
reduce development overhead and so produce software faster.
Extreme programming includes practices such as systematic
testing, continuous improvement and customer involvement.
The approach to testing in XP is a particular strength where
executable tests are developed before the code is written.
Key points
Rapid application development environments include database
programming languages, form generation tools and links to
office applications.
A throw-away prototype is used to explore requirements and
design options.
When implementing a throw-away prototype, start with the
requirements you least understand; in incremental
development, start with the best-understood requirements.

You might also like