CMIS 470 Structured Systems Design

1. CMIS 470Structured Systems Design RAD, JAD, Extreme Programming, Developmental Prototyping, Spiral Approach Week 8

2. Our Plan • This week: • Alternative methods • RAD, Extreme Programming, Developmental prototyping, Spiral Approach

3. Alternative Development Methods • Ch 13 • SDLC • Linear, sequential flow of activities requirements  design  construction…

4. Alternative Development Methods • Reasons SDLC may not always be practical or ideal: • Requirements can’t be completely specified • “new-thinking” requirements • innovative, creative application • Technology is new • associated technical uncertainties and learning • associated uncertainty in user requirements

5. Alternative Development Methods • Rapid Application Development • Risk management • Joint Application Design • Tool Based development • Software Reuse • Extreme Programming • Developmental prototyping • Spiral Approach

6. Reasons for Slow Development • Rework • Using the wrong software • Not meeting minimum quality standards • Shifting requirements and project changes • Improper tools and techniques

7. Cost of Change in Each Project PhaseFigure 13-1

8. What is RAD? • Collection of development approaches, techniques, tools, and technologies, proven to shorten development schedules • Perspective • Sequential vs. iterative approaches • Project characteristics important in determining approach

9. RAD Techniques • Collection of guidelines used to help an analyst complete system development activities • Risk management • JAD • Tool-based development • Software reuse

10. Risk Management • 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

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

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

13. JAD Sessions • 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

14. JAD Facilities • 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

15. High-Tech JAD FacilityFigure 4-15

16. Tool-Based Development • 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

17. Software Reuse • 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

18. Extreme Programming (XP) • 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

19. Extreme Programming System Development ApproachFigure 13-7

20. XP Principles and Techniques • Continuous automated testing • Continuous integration • Heavy user involvement • Team programming • Specific attention to human interactions and limitations

21. When to Use XP • 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

22. Developmental Prototyping Approach • Developmental Prototype • 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

23. 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.

24. Developmental Prototyping Approach • Two Types of DP Approaches: • 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

25. Spiral Approach

26. 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

27. Spiral Approach • In the initial planning stage (at the center of the spiral): • 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

28. 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

29. 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?

30. 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

31. 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

32. Comparison of Traditional, Spiral, and XP Development Figure 13-8

33. Oracle Designer ? • So how does Oracle Designer fit in to all of this? • Developmental prototyping TOOL • Therefore useful in employing Developmental Prototyping Approach or Spiral Approach

34. To-Do’s • Due this week: • 1st status report