View
73
Download
0
Category
Tags:
Preview:
Citation preview
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
Recommended