Software Development Processes

Traditional/Waterfall Prototyping Rapid Application Development (RAD) Evolutionary◦ Incremental◦ Spiral◦ Component Assembly

Agile Methods (e.g. XP) Formal Methods Fourth Generation Techniques

Project Definition

System Delivery

Maintenance

Requirements Analysis

Design

Component Testing

Integration Testing

System Testing

Program Implementation

Most widely used, though no longer state-of-the-art Each step results in documentation May be suitable for well-understood developments using

familiar technology Not suited to new, different systems because of

specification uncertainty Difficulty in accommodating change after the process has

started Can accommodate iteration but indirectly Working version not available till late in process Often get blocking states

Specifying requirements is often very difficult Users don’t know exactly what they want until

they see it Prototyping involves building a mock-up of

the system and using to obtain for user feedback

Closely related to what are now called “Agile Methods”

Listen to Customer

Build/ReviseMock-up

Customertest-drivesmock-up

Ideally mock-up serves as mechanism for identifying requirements

Users like the method, get a feeling for the actual system

Less ideally may be the basis for completed product◦ prototypes often ignore quality/performance/maintenance

issues◦ may create pressure from users on deliver earlier◦ may use a less-than-ideal platform to deliver e.g Visual

Basic - excellent for prototyping, may not be as effective in actual operation

Similar to waterfall but uses a very short development cycle (60 to 90 days to completion)

Uses component-based construction and emphasises reuse and code generation

Use multiple teams on scaleable projects Requires heavy resources Requires developers and customers who are

heavily committed Performance can be a problem Difficult to use with new technology

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Business

modelling

Data modelling

Process modelling

Application

generation

Testing and

turnover

Team 1 Team 2 Team 3

Applies an iterative philosophy to the waterfall model Divide functionality of system into increments and use a linear

sequence of development on each increment First increment delivered is usually the core product, i.e only basic

functionality Reviews of each increment impact on design of later increments Manages risk well Extreme Programming (XP), and other Agile Methods, are

incremental, but they do not implement the waterfall model steps in the standard order

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

analysis deliverydesign coding testing

1st Increment

2nd Increment

3rd Increment

4th Increment

Project Definition

Development cycles through multiple (3-6) task regions (6 stage version)◦ customer communication◦ planning◦ risk analysis◦ engineering◦ construction and release◦ customer evaluation

Incremental releases ◦ early releases may be paper or prototypes◦ later releases become more complicated

Models software until it is no longer used

Not a silver bullet, but considered to be one of the best approaches

Is a realistic approach to the problems of large scale software development

Can use prototyping during any phase in the evolution of product

Requires excellent management and risk assessment skills

Incorporates features of the spiral model Usually based on object technologies, but not

necessarily e.g. Visual Basic (older versions) Compose applications from pre-packaged

software components Can greatly boost productivity and reuse Relies heavily on quality and robustness of the

software components Fits into the Engineering/Construction task region

of the spiral model

In the last few years, a group of influential writers and consultants have got behind a group of software development processes known collectively as “Agile Methods”

Agile Methods reject the notion that we should design for future change – don’t “borrow trouble”

There is a “Manifesto for Agile Software Development”:“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 interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan”

Seductive, isn’t it?◦ Beware: it is not yet widely accepted in industry, and its own

proponents admit that it is not always a good choice

The best-known agile development process eXtreme Programming (XP), introduced by Kent Beck in 1999. It’s main principles are:◦ Rapid feedback

Very frequent builds – many per day Tests written first◦ Assume simplicity

Don’t borrow trouble – but “simplicity” is not easy. It can often take skill, effort and experience to recognize the simplest solution (as we will see with Design Patterns later in the semester)

◦ Incremental change◦ Embracing change◦ Quality work

The XP methodology has many practices. Beck emphasizes that you can’t pick and choose: if you’re not doing them all, you’re not doing XP◦ The Planning Game◦ Small releases◦ Metaphor◦ Simple Design◦ Testing – tests are written first, by both programmers and customer◦ Refactoring◦ Pair programming◦ Collective ownership◦ Continuous integration◦ 40-hour week◦ On-site customer◦ Coding standards

XP is very appealing to many programmers – often because they think can get away from heavy documentation◦ in fact the test-first practice creates a lot of documentation, though in

code form Beck himself indicates that there are situations where XP

is not appropriate. These include:◦ When it is not supported by the company culture

e.g. belief in big specifications, or overtime seen as a proxy for commitment to company

◦ More than 10 or 20 programmers (this is a big one!)◦ Project too big for regular complete integration◦ Where it inherently takes a long time to get feedback◦ Where you can’t realistically test

e.g. already in production using a $1,000,000 machine that is already at full capacity

◦ When the physical environment is wrong

Use of mathematical techniques to specify the requirements of the system e.g the B method, Z, VDM, Object-Z

Mainly used in life or mission-critical applications, e.g heart pacemakers, NASA

Can get very high quality software Problems◦ Time-consuming and expensive◦ Few developers have necessary skills, so extensive training

required◦ Difficult to use as a tool to communicate with users

The use of CASE and 4GL tools which let you specify the software at a high-level

Example: Hamilton-1 uses a formal specification language to generate complete system from requirements analysis ($100,000 per license)

Use of 4GT has grown considerably in the last decade

Some indications of productivity improvements for small and intermediate applications

Large projects require as much or more analysis, design and testing to achieve the time gains from the elimination of coding

Often problems with efficiency of automatically generated code