cse3308 - software engineering: analysis and design, 2004lecture 1b.1 software engineering: analysis...
Post on 15-Dec-2015
233 Views
Preview:
TRANSCRIPT
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.1
Software Engineering: Analysis and Design - CSE3308
Software Development Processes
CSE3308/DMS/2004/4
Monash University - School of Computer Science and Software Engineering
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.2
Lecture Outline
Traditional/Waterfall Prototyping Rapid Application Development (RAD) Evolutionary
Incremental Spiral Component Assembly
Agile Methods (e.g. XP) Formal Methods Fourth Generation Techniques
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.3
The Waterfall ModelProject
Definition
System Delivery
Maintenance
Requirements Analysis
Design
Component Testing
Integration Testing
System Testing
Program Implementation
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.4
Waterfall Model 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.5
Prototyping
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”
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.6
Prototyping
Listen to Customer
Build/ReviseMock-up
Customertest-drivesmock-up
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.7
Prototyping
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.8
Rapid Application Development
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.9
Rapid Application Development
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.10
Incremental Development
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.11
Incremental Development
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.12
The Spiral Model
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.13
Spiral Model
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.14
Spiral Model
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.15
Component Assembly
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.16
Component Assembly
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.17
Agile Methods 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.18
Agile Methods: XP
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 and effort to recognize the simplest solution
Incremental change Embracing change Quality work
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.19
Agile Methods: XP (2)
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.20
Agile Methods: When not to try XP 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.21
Formal Methods
Use of mathematical techniques to specify the requirements of the system e.g 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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.22
Fourth Generation Techniques
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.23
Fourth Generation Techniques
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
CSE3308 - Software Engineering: Analysis and Design, 2004 Lecture 1B.24
References
Pressman, R., Software Engineering: A Practitioner's Approach, McGraw-Hill, 2000, (Chapters 1 and 2).
Martin, Robert C., Agile Software Development: Principles, Patterns, and Practices, Prentice Hall, 2002.
Beck, Kent, eXtreme Programming eXplained: Embrace Change, Addison-Wesley, 1999.
top related