Download Rapid Application Development: Agile Methods and Prototyping - Prof. Marvin V. Zelkowitz and more Study notes Software Engineering in PDF only on Docsity!
CMSC435 - 1
Agile methods
Objectives
l To explain how an iterative, incremental
development process leads to faster delivery
of more useful software
l To discuss the essence of agile development
methods
l To explain the principles and practices of
extreme programming
l To explain the roles of prototyping in the
software process
CMSC435 - 3
COTS and Reuse
l An effective approach to rapid development is
to configure and link existing off the shelf
systems.
l For example, a requirements management
system could be built by using:
A database to store requirements;
A word processor to capture requirements
and format reports;
A spreadsheet for traceability
management;
Incremental development
l Develop system as a series of builds, each adds new
functionality.
Concept of iterative enhancement developed at
UMD in the 1970s.
l Features:
Accelerated delivery of customer services. Each
increment delivers the highest priority
functionality to the customer.
User engagement with the system. Users have to
be involved in the development which means the
system is more likely to meet their requirements
and the users are more committed to the system.
CMSC435 - 7
RAD environment tools
l Generally organized around business
applications:
Database programming language
Interface generator
Links to office applications
Report generators
A RAD environment
DB programming language
Inter face generator
Office systems
Report generator
Database management system
Rapid application development environment
CMSC435 - 9
Interface generation
l Many applications are based around complex forms
and developing these forms manually is a time-
consuming activity.
l 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.
Problems with RAD
l Management problems
Progress can be hard to judge and problems hard to find because there is no documentation to demonstrate what has been done.
l Contractual problems
The normal contract may include a specification; without a specification, different forms of contract have to be used.
l Validation problems
Without a specification, what is the system being tested against?
l Maintenance problems
Continual change tends to corrupt software structure making it more expensive to change and evolve to meet new requirements.
CMSC435 - 13
Software prototyping
l A prototype is an initial version of a system
used to demonstrate concepts and try out
design options.
l 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
l Improved system usability.
l A closer match to users’ real needs.
l Improved design quality.
l Improved maintainability.
l Reduced development effort.
CMSC435 - 15
Throw-away prototypes
l Prototypes should be discarded after
development as they are not a good basis for a
production system:
It may be impossible to tune the system to
meet non-functional requirements;
Prototypes are normally undocumented;
The prototype structure is usually
degraded through rapid change;
The prototype probably will not meet
normal organizational quality standards.
Conflicting objectives
l The objective of incremental development is
to deliver a working system to end-users. The
development starts with those requirements
which are best understood.
l The objective of throw-away prototyping is to
validate or derive the system requirements.
The prototyping process starts with those
requirements which are poorly understood.
CMSC435 - 19
Agile methods
l Dissatisfaction with the overheads involved in design
methods led to the creation of agile methods. These
methods:
Focus on the code rather than the design;
Are based on an iterative approach to software
development;
Are intended to deliver working software quickly
and evolve this quickly to meet changing
requirements.
l Agile methods are probably best suited to
small/medium-sized business systems or PC products.
l Not “one definition” of agile methods, but a set of
related techniques. We’ll discuss XP, SCRUM, Pair
Programming. There are others.
Agile Manifesto
l Kenny Beck and 16 others met in 2001:
l Issued “The Agile Manifesto”:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
- Individuals and interaction over process and
tools,
- Working software over comprehensive
documentation,
- Customer collaboration over contract
negotiation,
- Responding to change over following a plan.
That is, while there is a value in the items on the
right, we value the items on the left more.
CMSC435 - 21
Principles of agile methods
Principle Description
Customer involvement The customer should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.
Incremental delivery The software is developed in increments with the custom er specifying the requirements to be included in each increment.
People not process The skills of the development team should be recognized and exploited. The team should be left to develop their own ways of working without prescriptive processes.
Embrace change Expect the system requirements to change and design the system so that it can accommodate these changes.
M aintain simplicity Focus on simplicity in both the software being developed and in the development process used. W herever possible, actively work to eliminate complexity from the system.
Problems with agile methods
l It can be difficult to keep the interest of
customers who are involved in the process.
l Team members may be unsuited to the intense
involvement that characterizes agile methods.
l Prioritizing changes can be difficult where
there are multiple stakeholders.
l Maintaining simplicity requires extra work.
l Contracts may be a problem as with other
approaches to iterative development.
l But agile does not mean “no process” as
opponents to it claim.
CMSC435 - 25
Basics of user stories
l A user story represents a feature customers want in the software.
l A user story is developed by a customer
Customer writes user story on index card.
- Developers do not write stories
- Stories must be testable
- Stories should be independent Developer estimates development time Acceptance tests are developed by customer and developer Iterate. Divide big stories into smaller ones
l User stories are collected
l Stories to be implemented next are discussed after each iteration
Team Software Process
CMSC435 - 27
Extreme programming
l Perhaps the best-known and most widely used
agile method.
l 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.
12 rules of Extreme Programming
1. The planning game: At the start of each iteration, customers, managers,
and developers meet to flesh out, estimate, and prioritize requirements for the next release. The requirements are called “user stories” and are captured on “story cards” in a language understandable by all parties.
2. Small releases: An initial version of the system is put into production
after the first few iterations. Subsequently, working versions are put into production anywhere from every few days to every few weeks.
3. Metaphor: Customers, managers, and developers construct a metaphor, or
set of metaphors after which to model the system.
4. Simple design: Developers are urged to keep design as simple as possible,
“say everything once and only once”
5. Tests: Developers work test-first; they write acceptance tests for their
code before they write the code itself. Customers write functional tests for each iteration and at the end of each iteration, all tests should run.
6. Refactoring: As developers work, the design should be evolved to keep it
as simple as possible.
CMSC435 - 31
13 Technical Practices of XP - 2
l … l Ten-minute build, structure project and its tests such that the whole system can be built and all tests run in ten minutes so that the system will be tested often l Test-first programming, all stories have at least one acceptance test. When the acceptance test(s) for a user story all pass, the story is considered to be fulfilled. l Continuous integration, programmers check in the code base completed code and its associated tests several times a day. Code may only be checked in if all its associated unit tests and all of unit tests of the entire code base pass. l Incremental design, rather than an anticipatory detailed design prior to implementation. Invest in the design of the system every day
l Most XP groups use a daily Stand Up meeting to discuss prior day’s work, plans for today, and possible problems Why a stand up meeting?
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 PDF version so it is automatically deleted from your computer.
CMSC435 - 33
Task cards for document downloading
Task 1: Implement principal workflow
Task 2: Implement article catalog and selection
Task 3: Implement payment collection
Payment may be made in 3 different ways. The user selects which way they wish to pay. If the user has a library subscription, then they can input the subscriber key which should be checked by the system. Alternatively , they can input an organization account number. If this is valid, a debit of the cost of the article is posted to this account. Finally , they may input a 16 digit credit card number and expiry date. This should be checked for validity and, if valid a debit is posted to that credit card account.
Testing in XP
l Test-first development.
l Incremental test development from scenarios.
l User involvement in test development and
validation.
l Automated test harnesses are used to run all
component tests each time that a new release
is built.
CMSC435 - 37
Pair programming
l In XP, programmers work in pairs, sitting together to
develop code.
l This helps develop common ownership of code and
spreads knowledge across the team.
l It serves as an informal review process as each line of
code is looked at by more than 1 person.
l It encourages refactoring as the whole team can
benefit from this.
l Measurements suggest that development productivity
with pair programming is similar to that of two people
working independently. (??? – Other studies show 30%
cost)
The XP release cycle
Break down stories to tasks
Select user stories for this release
Plan release
Release software
Evaluate system
Develop/integrate/ test software
CMSC435 - 39
XP and agile principles
l Incremental development is supported
through small, frequent system releases.
l Customer involvement means full-time
customer engagement with the team.
l People not process through pair programming,
collective ownership and a process that avoids
long working hours.
l Change supported through regular system
releases.
l Maintaining simplicity through constant
refactoring of code.
XP and change
l 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.
l XP, however, maintains that this is not
worthwhile as changes cannot be reliably
anticipated.
l Rather, it proposes constant code
improvement (refactoring) to make changes
easier when they have to be implemented.
