Alternative Methodologies

Our Plan


Alternative methods

RAD, Developmental prototyping, Spiral
Approach, XP, UP

Alternative Development
Methods



Linear, sequential flow of activities requirements  design  construction…

Alternative Development
Methods



“new-thinking” requirements

 innovative, creative application

 associated technical uncertainties and learning associated uncertainty in user requirements

Alternative Development
Methods








Risk management
Joint Application Design
Tool Based development
Software Reuse


Rework


Using the wrong software
Not meeting minimum quality standards

Shifting requirements and project changes

Improper tools and techniques

Cost of Change in Each Project Phase
Figure 13-1


Collection of development approaches, techniques, tools, and technologies, proven to shorten development schedules

Perspective

Sequential vs. iterative approaches

Project characteristics important in determining approach


Collection of guidelines used to help an analyst complete system development activities

Risk management



JAD
Tool-based development
Software reuse



Systematic process of identifying and mitigating software development risks
Principles of risk management


Most risks can be identified if specific attention is directed to them
Risks appear, disappear, increase, and decrease as the development process proceeds

Small risks should be monitored and large risks mitigated

Every project should use risk management

Steps in Risk Management
From Figure 13-10
Identify project risks
Estimate risk outcomes & probabilities
Prioritize risks
Develop & implement mitigation strategies
Project completed


Shortens development time by including all key decision makers

Can be incorporated into any development approach

Well suited to iterative development approaches


Used to expedite the investigation of systems requirements

Seeks to compress fact-finding, modeling, policy formation, and verification activities into a shorter time frame

Critical factor is to have all important stakeholders present


Generally conducted in special room

Limits interruptions

May be off-site

Resources


Overhead projector, white board, flip charts, and work material
Electronic support


CASE Tools
Group support systems

High-Tech JAD Facility
Figure 4-15


Chooses tool(s) that best match system requirements and doesn’t develop any requirements not easily implemented with selected tool(s)

System limited by tool

No one tool is best for all development approaches


Mechanism that allows software used for one purpose to be reused for another

Possible time savings

Effort required to identify reusable software


Effort required for modification
Extent to which software must be repackaged

Developmental Prototyping
Approach




A prototype system that is not intended to be thrown away
Becomes all or part of the final system
As opposed to a “discovery prototype”


Used to discover or refine system requirements or design parameters
Disposable – not intended to become part of final system

Developmental Prototyping
Approach

When to use this approach?

When some of the following:



Some requirements cannot be fully specified independent of detailed design
Technical feasibility for some functions is unknown or uncertain
Prototype development tools are powerful enough to create fully functional systems

NOTE: DP approach works best when most of the requirements are understood up front.

Developmental Prototyping
Approach



Approach 1:


Develop simple base prototype
Then, add features in subsequent development phases
Approach 2:


Develop a series of independent prototypes
Later, combine them to form complete system

Spiral Approach

Spiral Approach


An iterative development approach in which each iteration may include a combination of planning, analysis, design, or implementation steps
Incorporates Development Prototyping, but is a more radical departure from traditional
SDLC

Spiral Approach


Feasibility study




High-level user requirements survey
Generation of implementation alternatives
Choice of overall design and implementation strategy
Gather just enough info to begin developing the first prototype

Spiral Approach


A set of system features is implemented in each prototype
For each prototype, development follows a sequential (SDLC-like) path through:

Analysis





Design
Construction
Testing
Integration with previous prototype
Planning for next prototype

Spiral Approach

Strategies for deciding which features to implement in early vs. later prototypes:

May do “must haves” and “should haves” in earlier prototypes

Leaving “nice to haves” for later prototypes


May include heavily-used functions in early prototypes
 e.g., data entry and data retrieval functions
May include uncertain or poorly defined user requirements in early prototypes

Why?

Spiral Approach

Benefits:

High parallelism

Many opportunities to overlap activities among prototyping cycles



High user involvement

Frequent and continual user participation, as they are involved in multiple prototyping cycles (planning, analysis, testing)
Steady resource commitment

Resource consumption more evenly spread out
Frequent product delivery

With good planning and decisions on features to be incorporated in early prototypes, early prototypes can be rolled out to the user as working versions

Spiral Approach

Drawbacks:

More complex to manage



More activities occur in parallel
More people working on the project at earlier stages
Rework more likely

Because not all analysis and design occurs before construction

Quality and maintenance may suffer

Design decisions that may seem optimal when looking at a portion of the system may be less than optimal when looking at the entire system

As modifications and enhancements are made, system typically becomes less efficient, less reliable, more difficult to maintain


Rapid development approach focused on creating user stories, delivering releases of a system, and quickly testing

Developed by Kent Beck in 1990’s

Borrows heavily on earlier development approaches

Extreme Programming System Development
Approach
Figure 17-7






Continuous automated testing
Continuous integration
Heavy user involvement
Team programming
Specific attention to human interactions and limitations



Small development teams (12 or less)
Talented development personnel with broad range of skills

Limited scope of projects

Stand-alone


New systems
Minimal interface to legacy system

Extensive use of high-quality OO development and testing tools

Comparison of Traditional, Spiral, and XP
Development
Figure 17-8

Oracle Designer ?
