Rapid software development

|

  m

 
   

 a
ectives
Ô 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

|

  m

 
   

 Topics covered
Ô Agile methods
Ô Extreme programming
Ô Rapid application development
Ô Software prototyping

|

  m

 
   

 Rapid software development
Ô Because of rapidly changing usiness
environments, usinesses have to respond
to new opportunities and competition.
Ô This requires software and rapid
development and delivery is not often the
most critical requirement for software
systems.
Ô Businesses may e willing to accept lower
quality software if rapid delivery of essential
functionality is possi le.

|

  m

 
   

 Requirements
Ô Because of the changing environment, it is
often impossi le to arrive at a sta le,
consistent set of system requirements.
Ô Therefore a waterfall model of development
is impractical and an approach to
development ased on iterative specification
and delivery is the only way to deliver
software quickly.

|

  m

 
   

 ˜haracteristics of RAD processes
Ô The processes of specification, design and
implementation are concurrent. There is no detailed
specification and design documentation is
minimised.
Ô The system is developed in a series of increments.
End users evaluate each increment and make
proposals for later increments.
Ô System user interfaces are usually developed using
an interactive development system.

|

  m

 
   

 An iterative development process

|

  m

 
   

Advantages of incremental development

Ô Accelerated delivery of customer services.

Each increment delivers the highest priority
functionality to the customer.
Ô User engagement with the system. Users
have to e involved in the development
which means the system is more likely to
meet their requirements and the users are
more committed to the system.

|

  m

 
   

\ro lems with incremental development
Ô Management pro lems
‡ \rogress can e hard to
udge and pro lems hard to find
ecause there is no documentation to demonstrate what
has een done.
Ô ˜ontractual pro lems
‡ The normal contract may include a specification; without a
specification, different forms of contract have to e used.
Ô Validation pro lems
‡ Without a specification, what is the system eing tested
against?
Ô Maintenance pro lems
‡ ˜ontinual change tends to corrupt software structure
making it more expensive to change and evolve to meet
new requirements.

|

  m

 
   

 \rototyping
Ô For some large systems, incremental
iterative development and delivery may e
impractical; this is especially true when
multiple teams are working on different sites.
Ô \rototyping, where an experimental system
is developed as a asis for formulating the
requirements may e used. This system is
thrown away when the system specification
has een agreed.

|

  m

 
   

 Yncremental development and prototyping

|

  m

 
   

 ˜onflicting o
ectives
Ô The o
ective of incremental development is
to deliver a working system to end-users.
The development starts with those
requirements which are est understood.
Ô The o
ective of throw-away prototyping is to
validate or derive the system requirements.
The prototyping process starts with those
requirements which are poorly understood.

|

  m

 
   

 Agile methods
Ô 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 ased on an iterative approach to software
development;
‡ Are intended to deliver working software quickly and
evolve this quickly to meet changing requirements.
Ô Agile methods are pro a ly est suited to
small/medium-sized usiness systems or \˜
products.

|

  m

 
   

 \rinciples of agile methods

\

 



    !
  "
 #






$
!%






&!#


! &$

 

$


&!
"%
 



#
\ '
& 
 "


(
#
 & 
$$
!&
$'
"$


#
) 

" )(!%

"

"!






"#
*






! +


!
 &$
 
" 


 #, 
-

!$'



(
!&!#

|

  m

 
   

 \ro lems with agile methods
Ô Yt can e difficult to keep the interest of customers
who are involved in the process.
Ô Team mem ers may e unsuited to the intense
involvement that characterises agile methods.
Ô \rioritising changes can e difficult where there are
multiple stakeholders.
Ô Maintaining simplicity requires extra work.
Ô ˜ontracts may e a pro lem as with other
approaches to iterative development.

|

  m

 
   

 Extreme programming
Ô \erhaps the est-known and most widely
used agile method.
Ô Extreme \rogramming (X\ takes an
µextreme¶ approach to iterative development.
‡ New versions may e uilt several times per
day;
‡ Yncrements are delivered to customers every 2
weeks;
‡ All tests must e run for every uild and the
uild is only accepted if tests run successfully.

|

  m

 
   

 The X\ release cycle

|

  m

 
   

 Extreme programming practices 1

  
 

.
  
       
 
   
  

  



 
   






 


 

 #     
   


   /
 0#

.
 


 &  && 


 
 
 


 
    &
#.
 &   
&  


  
 
& 


   &

#

 
 



       
  

  #
&
     1 

 
&
  
    
& 
 

 && 


  & 
& 


 
&


   #
.&
 
1   
   &
    
 

 
 
 
   
& #
   
 






#

|

  m

 
   

 Extreme programming practices 2

\

\"

"   '


-'
"
  '



"

!
"2 #

3 
 

   '


 !-



 (
 

  

# !

"
!
"#

 "

 
 '

'



"


!# 
!
"

-



!
#




 4
"
  5






 
 %

!




!
35
  

 5 !6 7
 



 
  8\
# 

("

"-

  
 



  
"
"!
%

 


#

|

  m

 
   

 X\ and agile principles
Ô Yncremental development is supported through
small, frequent system releases.
Ô ˜ustomer involvement means full-time customer
engagement with the team.
Ô \eople not process through pair programming,
collective ownership and a process that avoids long
working hours.
Ô ˜hange supported through regular system releases.
Ô Maintaining simplicity through constant refactoring of
code.

|

  m

 
   

 Requirements scenarios
Ô Yn X\, user requirements are expressed as
scenarios or user stories.
Ô These are written on cards and the
development team reak them down into
implementation tasks. These tasks are the
asis of schedule and cost estimates.
Ô The customer chooses the stories for
inclusion in the next release ased on their
priorities and the schedule estimates.

|

  m

 
   

 Story card for document downloading

|

  m

 
   

 X\ and change
Ô ˜onventional wisdom in software
engineering is to design for change. Yt is
worth spending time and effort anticipating
changes as this reduces costs later in the life
cycle.
Ô X\, however, maintains that this is not
worthwhile as changes cannot e relia ly
anticipated.
Ô Rather, it proposes constant code
improvement (refactoring to make changes
easier when they have to e implemented.
|

  m

 
   

 Testing in X\
Ô Test-first development.
Ô Yncremental 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 uilt.

|

  m

 
   

 Task cards for document downloading

|

  m

 
   

 Test case description

|

  m

 
   

 Test-first development
Ô Writing tests efore code clarifies the
requirements to e implemented.
Ô Tests are written as programs rather than
data so that they can e 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.

|

  m

 
   

 \air programming
Ô Yn X\, programmers work in pairs, sitting together to
develop code.
Ô This helps develop common ownership of code and
spreads knowledge across the team.
Ô Yt serves as an informal review process as each line
of code is looked at y more than 1 person.
Ô Yt encourages refactoring as the whole team can
enefit from this.
Ô Measurements suggest that development
productivity with pair programming is similar to that
of two people working independently.

|

  m

 
   

 Rapid application development
Ô Agile methods have received a lot of
attention ut other approaches to rapid
application development have een used for
many years.
Ô These are designed to develop data-
intensive usiness applications and rely on
programming and presenting information
from a data ase.

|

  m

 
   

 RAD environment tools
Ô Data ase programming language
Ô Ynterface generator
Ô Links to office applications
Ô Report generators

|

  m

 
   

 A RAD environment

|

  m

 
   

 Ynterface generation
Ô Many applications are ased around complex forms
and developing these forms manually is a time-
consuming activity.
Ô RAD environments include support for screen
generation including:
‡ Ynteractive form definition using drag and drop
techniques;
‡ Form linking where the sequence of forms to e
presented is specified;
‡ Form verification where allowed ranges in form fields is
defined.

|

  m

 
   

 Visual programming
Ô Scripting languages such as Visual Basic
support visual programming where the
prototype is developed y creating a user
interface from standard items and
associating components with these items
Ô A large li rary of components exists to
support this type of development
Ô These may e tailored to suit the specific
application requirements

|

  m

 
   

 Visual programming with reuse

|

  m

 
   

 \ro lems with visual development

Ô Difficult to coordinate team- ased

development.
Ô No explicit system architecture.
Ô ˜omplex dependencies etween parts of the
program can cause maintaina ility pro lems.

|

  m

 
   

 ˜aTS reuse
Ô An effective approach to rapid development
is to configure and link existing off the shelf
systems.
Ô For example, a requirements management
system could e uilt y using:
‡ A data ase to store requirements;
‡ A word processor to capture requirements and
format reports;
‡ A spreadsheet for tracea ility management;

|

  m

 
   

 ˜ompound documents
Ô For some applications, a prototype can e created
y 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 is invoked when that element is selected.
Ô The document itself is the integrator for the different
applications.

|

  m

 
   

 Application linking

|

  m

 
   

 Software prototyping
Ô A prototype is an initial version of a system
used to demonstrate concepts and try out
design options.
Ô A prototype can e used in:
‡ The requirements engineering process to help
with requirements elicitation and validation;
‡ Yn design processes to explore options and
develop a UY design;
‡ Yn the testing process to run ack-to- ack tests.

|

  m

 
   

 Benefits of prototyping
Ô Ymproved system usa ility.
Ô A closer match to users¶ real needs.
Ô Ymproved design quality.
Ô Ymproved maintaina ility.
Ô Reduced development effort.

|

  m

 
   

 Back to ack testing

|

  m

 
   

 The prototyping process

|

  m

 
   

 Throw-away prototypes
Ô \rototypes should e discarded after
development as they are not a good asis
for a production system:
‡ Yt may e impossi le to tune the system to meet
non-functional requirements;
‡ \rototypes are normally undocumented;
‡ The prototype structure is usually degraded
through rapid change;
‡ The prototype pro a ly will not meet normal
organisational quality standards.

|

  m

 
   

 sey 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 X\ is a particular strength
where executa le tests are developed efore the
code is written.

|

  m

 
   

 sey points
Ô Rapid application development environments
include data ase 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 est-understood requirements.

|

  m