_SP04

Rapid software development

Traditional Development Process
- Good projects are ones that deliver to the market
o Plan:
 What do you need? -> determine requirements
 What does the program do? -> specify the functionality of the
program
o Build:
 How does the program work?
 Design the structure of the program
 Close and test
o Deliver: initial, corrected or upgraded releases
Rapid software development
- Because of rapidly changing business environments, it is often impossible to
arrive at a stable, consistent set of system requirements  a traditional
model of development (completely specifying the requirements, then
designing, building and testing the system) is impractical
- An approach to development based on iterative specification and delivery is
the only way to deliver software quickly
AGILE METHOD
1. Concept
- Agility is the ability to create and respond to change in order to profit in a
turbulent business environment
- Agile methods are created to cope with the overheads involved in design
methods. These methods:
o Focus on the code rather than the design
o Are based on an iterative approach to software development
(incremental development)
o Are intended to deliver working software quickly and evolve this
quickly to meet changing requirements (incremental delivery)
- Agile methods are probably best suited to small/medium – sized business
systems or PC products.
2. Principles
Principle Description
Customer The customer should be closely involved throughout the
involvement development process
Their role is provide and prioritise new system
requirements and to evaluate the iterations of the system
Incremental The software is developed in increments with the customer
specifying the requirements to be included in each
increment
People not The skills of the development team should be recognized
process and exploited
The team should be left to develop their own ways of
working without prescriptive processes
Embrace Expect the system requirements to change and design the
change system so that it can accommodate these changes
Maintain Focus on simplicity in both the software being developed
simplicity and in the development process used
Wherever possible, actively work to eliminate complexity
from the system.

3. Problems
- 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
- Maintain simplicity requires extra work
- Contracts may be a problem as with approaches to iterative development
- Suitable for the development of small or medium – sized business system
and personal computer products
- Not well suited to:
o Large – scale systems development with the development teams in
different places and where there may be complex interactions with
other hardware and software systems
 o Critical systems development where a detailed analysis of all of the
system requirements is necessary to understand their safety or security
implications.
EXTREME PROGRAMMING (XP)
Perhaps the best – known and most widely used agile method
1. Idea of XP
- Extreme Programming takes an “extreme” approach to iterative
development
o New version may be built several times per day
o Increments are delivered to customers every 2 weeks
o All tests must be run for every build and the build is only accepted if
tests run successfully
2. The XP release cycle

- Incremental planning:
o Requirements are recorded on Story Cards
o Stories to be included in a release are determined by the time available
and their relative priority
o The developers break these Stories into development ‘Tasks’
- Small:
o The minimal useful set of functionality that provides business value is
developed first
o Releases of the system are frequent and incrementally add
functionality to the first release
- Simple Design:
o Enough design is carried out to meet the current requirements and no
more
- Test first development:
 o An automated unit test framework is used to write tests for a new
piece of functionality before that functionality itself is implemented
- Refactoring:
o All developers are expected to refactor the code continuously as soon
as possible code improvements are found
o This keeps the code simple and maintainable
- Pair Programming:
o Developers work in pairs, checking each other’s work and providing
the support to always do a good job
- Collective Ownership:
o The pairs of developers work on all areas of the system, so that no
island of expertise develop and all the developers own all the code
o Anyone can change anything
- Continuous Integration:
o As soon as work on a task is complete it is integrated into the whole
system
o After any such integration, all the unit tests in the system must pass
- Sustainable pace:
o Large amounts of over – time are not considered acceptable as the net
effect is often to reduce code quality and medium term productivity
- On – site Customer:
o A representative of the end – user of the system (the Customer) should
be available full time for the use of the XP team
o In an extreme programming process, the customer is a member of the
development team and is responsible for bringing system
requirements to the team for implementation.
3. XP and agile principles
Principle Description in XP
Customer Full – time customer engagement with the team:
involvement - To help develop stories that define the requirements
- To help prioritize the features to be implemented in
each release
- To help develop acceptance tests which assess
whether or not the system meets its requirements
Incremental Small, frequent system releases
delivery
 People not Pair programming
process Collective ownership
Process that avoids long working hours
Embrace change Regular system releases
Test – first development
Continuous integration
Maintain Constant refactoring of code
simplicity
3.1. 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
- This serves as an informal review process as each line of code is looked at
by more than 1 person
- This 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
Requirements scenarios: Story card for document downloading
- In XP, user requirements are expressed as scenarios or user stories; these are
written on cards.
- The development team break these stories down into implementation tasks.
These tasks are the basic of schedule and cost estimates
- The customer chooses the stories for inclusion in the next release based on
their priorities and the schedule estimates
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, though a company account or
by credit card
Alter this, you get a copyright form from
the system to fill it
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 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.
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 organizational 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.
3.2. Testing in XP
- Test – first development
- Incremental test development from scenarios
- 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 – first development
- Writing test before code clarifies the requirements to be implemented
- Test 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
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 expire date
information to the card issuer
Output:
OK or error message indicating that the
card is invalid

3.3. Refactoring
- XP processes refactoring to make changes easier when they have to be
implemented
- Refactoring is the process of constant code improvement where cod is
reorganized and rewritten to make it more efficient, easier to understand, etc.
- Refactoring is required because frequent releases mean that code is
developed incrementally and therefore tends to become messy
- Refactoring should not change the functionality of the system
- Automated testing simplifies refactoring as you can see if the changed code
still runs the tests successfully
4. Problem with XP
- Customer involvement:
o It may be difficult or impossible to find a customer who can represent
all stakeholders and who can be taken off their normal work to
become part of the XP team
o For generic products, there is no ‘customer’ – the marketing team may
not be typical of real customers
- Architectural design
 o The incremental style of development can mean that inappropriate
architectural decisions are made at an early stage of the process
o Problems with these may not become clear until many features have
been implemented and refactoring the architecture is very expensive
- Test complacency:
o It is easy for a team to believe that because it has many tests, the
system is properly tested
o Because of the automated testing approach, there is a tendency to
develop tests that are easy to automate rather than tests that are ‘good’
tests
RAPID APPLICATION DEVELOPMENT
1. Concept
- 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
2. Characteristics of RAD processes
- The processes of specification, design and implementation are concurrent
- The user requirements document defines only the most important
characteristics of the system
- There is no detailed specification
- Design documentation is minimized
- The system is developed in a series of increments
- End users evaluate each increment and make proposals for later increments
- System user interface are usually developed using an interactive
development system
3. RAD environment tools
- Database programming language: embed knowledge of the database
structure; include fundamental database manipulation operations
- Interface generator: create forms for data input and display
- Links to office applications: inks to office applications such as a spreadsheet
for the analysis and manipulation of numeric information or a word
processor for report template creation
- Report generators: define and create reports from information in the
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:
o Interactive form definition using drag and drop techniques
o Form linking where the sequence of forms to be presented is specified
o Form verification where allowed ranges in form fields is defined
COST (Commercial Off The Shelf) reuse
- An effective approach to rapid development is to configure and link existing
off the shelf systems
- For example, a requirements management system could be built by using:
o A database to store requirements
o A word processor to capture requirements and format reports
o A spreadsheet for traceability management
Database programming languages
- Domain specific languages for business systems based around a database
management system
- Normally include a database query language, a screen generator, a report
generator and a spreadsheet
- May be integrated with a CASE toolset
- The language + environment is sometimes known as a fourth – generation
language (4GL)
- Cost – effective for small to medium sized business systems
RAPID PROTOTYPING
1. Concepts
1.1. Prototype
- A prototype is an initial version of a software system that is used to
demonstrate concepts, try out design options and, generally, to find out more
about the problem and its possible solutions
- A prototype is used:
o In the requirements engineering process: help customers and
developers understand the requirements for the system
  Requirements elicitation: users can experiment with a prototype
to see how the system supports their work
 Requirements validation: the prototype can reveal errors and
omissions in the requirements
o In the system design process: explore particular software solutions
and to support user interface design
o In the testing process: run back – to –back tests with the system that
will be delivered to the customer
-  Prototyping is the rapid development of a system. Prototyping can be
considered as a risk reduction activity which reduces requirements, design
and testing risks.
1.2. Prototyping process

1.3. Prototyping benefits

- Misunderstandings between software users and developers are exposed
- Missing services may be detected and confusing services may be identified
- A working system is available early in the process
- The prototype may serve as a basis for deriving a system specification
- The system can support user training and system testing
- Improved system usability
- Closer match to the system needed
- Improved design quality
- Improved maintainability
- Reduced overall development effort
1.4. Approaches to prototyping
 1.4.1. Evolutionary prototyping
- Specification, design and implementation are inter – twined
- The system is developed as a series of increments that are delivered to the
customer
- Techniques for rapid system development are used such as CASE tools and
4GLs
- User interfaces are usually developed using a GUI development toolkit

Advantages and Problems

- Advantages:
o Accelerated delivery of the system
 Rapid delivery and deployment are sometimes more important
than functionality or long – term software maintainability
o User engagement with the system
 Not only is the system more likely to meet user requirements,
they are more likely to commit to the use of the system
- Problems:
 o Management problems
 Existing management processes assume a waterfall model of
development
 Specialist skills are required which may not be available in all
development teams
o Maintenance problems
 Continual change tends to corrupt system structure so long –
term maintenance in expensive
o Contractual problems
1.4.2. Throw – away prototyping
- Used to reduce requirements risk
- The prototype is developed from an initial specification, delivered for
experiment then discarded
- The throw – away prototype should NOT be considered as a final system
o Some system characteristics may have been left out
o There is no specification for long – term maintenance
o The system will be poorly structured and difficult to maintain

1.4.3. Prototype delivery

- Developers may be pressurized to deliver a throw – away prototype as a
final system
- This is not recommended
o It may be impossible to tune the prototype to meet non – functional
requirements
o The prototype is inevitably undocumented
 o The system structure will be degraded through changes made during
development
o Normal organizational quality standards may not have been applied
1.4.4. Prototypes as specifications
- Some parts of the requirements (e.g. safety – critical functions) may be
impossible to prototype and so don’t appear in the specification
- An implementation has no legal standing as a contract
- Non – functional requirements cannot be adequately tested in a system
prototype
2. Techniques
- Various techniques may be used for rapid development
o Dynamic high – level language development
o Database programming
o Component and application assembly
- These are not exclusive techniques – they are often used together
- Visual programming is an inherent part of most prototype development
systems
2.1. Dynamic high – level languages
- Languages which include powerful data management facilities
- Need a large run – time support system Not normally used for large system
development
- Some languages offer excellent UI development facilities
- Some languages have an integrated support environment whose facilities
may be used in the prototype
Language Type Application domain
Smalltalk Object – oriented Interactive systems
Java Object – oriented Interactive systems
Prolog Logic Symbolic processing
Lisp List – based Symbolic processing

Choice of prototyping language:

- What is the application domain of the problem?
- What user interaction is required?
- What support environment comes with the language?
- Different parts of the system may be programmed in different languages.
However, there may be problems with language communications.
2.2. Component and application assembly
- Prototypes can be created quickly from a set of reusable components plus
some mechanism to ‘glue’ these component together
- The composition mechanism must include control facilities and a
mechanism for component communication
- The system specification must take into account the availability and
functionality of existing components
2.2.1. Prototyping with reuse
- Application level development
o Entire application systems are integrated with the prototype so that
their functionality can be shared
o For example, if text preparation is required, a standard word processor
can be used
- Component level development
o Individual components are integrated within a standard framework to
implement the system
o Frame work can be a scripting language or an integration framework
such as CORBA
- Reusable component composition:

o Reusable software components

o Component composition framework
o Executable prototype
o Control and integration code
2.2.2. User interface prototyping
- It is impossible to pre – specify the look and feel of a user interface in an
effective way prototyping is essential
- UI development consumes an increasing part of overall system development
costs
- User interface generators may be used to ‘draw’ the interface and simulate
its functionality with components associated with interface entities
- Web interfaces may be prototyped using a web site editor
a. Compound documents
- For some applications, a prototype can be created by developing a
compound document
- This is a document with active elements (such as a spreadsheet) that allow
user computations
- Each active element has an associated application which in invoked when
that element is selected
- The document itself is the integrator for the different applications
Application linking in compound documents

b. 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
- These may be tailored to suit the specific application requirements
Visual programming with reuse

Problems with visual development

- Difficult to coordinate team – based development
- No explicit system architecture
- Complex dependencies between parts of the program can cause
maintainability problems
CONCLUSION
Key point
- Extreme programming includes practices such as systematic testing,
continuous improvement and customer involvement
- Customers are involved in developing requirements which are expressed as
simple scenarios
- The approach to testing in XP is a particular strength where executable tests
are developed before the code is written
- Key problems with XP include difficulties of getting representative
customers and problems of architectural design
- A prototype can be used to give end – users a concrete impression of the
system’s capabilities
- Prototyping is becoming increasingly used for system development where
rapid development is essential
- Throw – away prototyping is used to understand the system requirements
- In evolutionary prototyping, the system is developed by evolving an initial
version to the final version
- Rapid development of prototypes is essential. This may require leaving out
functionality or relaxing non – functional constraints
- Prototyping techniques include the use of very high – level languages,
database programming and prototype construction from reusable
components
- Prototyping is essential for parts of the system such as the user interface
which cannot be effectively pre – specified. Users must be involved in
prototype evaluation