1 / 33

Alternative Methodologies

Alternative Methodologies. Week 13 CMIS 570. Our Plan. TONIGHT: Alternative methods RAD, Developmental prototyping, Spiral Approach, XP, UP. Alternative Development Methods. Ch 17 SDLC Linear, sequential flow of activities requirements  design  construction….

forrest
Download Presentation

Alternative Methodologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alternative Methodologies Week 13 CMIS 570

  2. Our Plan • TONIGHT: • Alternative methods • RAD, Developmental prototyping, Spiral Approach, XP, UP

  3. Alternative Development Methods • Ch 17 • 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 • Developmental prototyping • Spiral Approach • Extreme Programming

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

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

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

  21. Spiral Approach

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

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

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

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

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

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

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

  29. Extreme Programming System Development ApproachFigure 17-7

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

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

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

  33. Oracle Designer ? • So how does Oracle Designer fit in to all of this?

More Related