Chapter 14 Current Trends in System Development

1. Chapter 14Current Trends in System Development Chapter 17 Systems Analysis and Design in a Changing World, 3rd Edition

2. Rapid Application Development • RAD is overused and poorly understood • Software developers claim they do, but cannot precisely define • Equated with tools and techniques • Prototyping, fourth-generation programming languages, CASE tools • Object-oriented analysis, design, and development • Tool vendors and methodologies claim RAD • Competing and confusing claims

3. Reasons for Slow Development • Rework • Using the wrong software • Not meeting minimum quality standards • Shifting requirements and project changes • Changes to design and construction • Improper tools and techniques for project • Reduces quality, increases development time

4. Cost of Change in Each Project Phase

5. What is RAD? • Collection of development approaches, techniques, tools, and technologies • RAD proven to shorten development schedules • No universal RAD approach shortens every project schedule • No technique, tools or technology fits perfectly • Key is identifying overall development approach and matching set of techniques, tools, techniques most suitable to approach and specific project

6. RAD in Perspective • Conventional SDLC approach typically sequential • Completely define requirements before design • Make major design decisions before implementation • Systems were simple, development tools were primitive, hardware was expensive and slow • Project characteristics determine approach • Iterative approaches better for large project and/or uncertain requirements

7. Development Approach as a Function of Project Characteristics

8. Prototyping Approach to Development • Discovery prototype • Used in analysis or early design • Uncover or refine system requirements • Can be thrown away • Developmental prototype • Not thrown away • Part of iterative development until final system complete

9. System Development Based on Developmental Prototypes Planning Analysis Architectural Design Analysis & Design Construction Testing & Evaluation Additional Implementation

10. When to Use a Prototyping Approach • When to use: • Requirements cannot be fully specified outside of architectural or detailed design • Technical feasibility unknown or uncertain • Development tools powerful enough to create functional system • When not to use: • System is non-interactive or internally complex • Strict security or performance requirements exist

11. Prototyping Tool Requirements • Development speed • Flexibility and power • Techniques and capabilities • WYSIWYG (what you see is what you get) • Generation of complete programs, program skeletons, or database schemas from diagrams • Rapid customization of software libraries or components • Error-checking and debugging capabilities

12. Project Conditions Determine Prototyping Tools • Suitability for technical environment in which system will be deployed • Ability to implement all system requirements • Ability to interface with software developed with other tools • Object-oriented, component-based, and Web service technologies and standards make software interoperability more achievable.

13. Spiral Approach to Development • Iterative development approach • Each iteration may include combination of planning, analysis, design, or development steps • More radical departure from traditional development than prototyping development

14. The Spiral Life Cycle

15. Steps in the Spiral Development Approach • Criteria for feature selection for each prototype • User priorities • Uncertain requirements • Function reuse • Implementation risk • Break into categories • “Must have”, “Should have”, “Nice to have” • Complete high priorities earlier to reduce risk

16. Benefits and Risks of Spiral Development • Benefits • High parallelism • High user involvement • Gradual resource commitment • Frequent product delivery • Risks • Management difficulties and design complexity • More potential for rework

17. Cumulative Cost Plotted Against Time

18. eXtreme Programming (XP) • Rapid development approach • Focused on creating user stories, delivering releases of system, and quickly testing • Developed by Kent Beck in mid-1990’s • Borrows heavily on earlier development approaches such as prototyping, object-oriented development, and pair programming

19. eXtreme Programming System Development Approach

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

21. Comparison of Traditional, Spiral, and XP Development

22. 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 interfaces to legacy system • Extensive use of high-quality OO development and testing tools

23. The Unified Process • Comprehensive development approach • Originally developed by Jacobsen, Booch, and Rumbaugh in late 1990s • Dominant approach for developing software with OO models and tools • Adopts iteration from prototyping and spiral development approaches • Exclusive reliance on OO models, tools, and techniques

24. How the UP Organizes Software Development • UP’s SDLC includes four high-level activities: • Inception– similar to project planning • Elaboration– defining requirements in more detail and concentrate on analysis, design, construction for high risk and complex activities • Construction– complete programming, testing, and installation for lower-risk and simpler activities • Transition– test and deploy entire production system

25. Iterations and Disciplines • Timeboxing - organizing a complex task or project into series of equal-length time intervals • More effective when iterations are relatively short and each iteration produces concrete result • Frequent testing, immediate user feedback, motivation, and greater accomplishment • Disciplines include business modeling, requirements, design, implementation, and project management

26. UP Development is Series of Iterations

27. When to Use the Unified Process • Benefits and risks mirror spiral development • Major obstacles to adopt UP include: • Complex project management (compared to sequential development) required • Need to adopt OO models, tools, techniques throughout project • UP’s formal steps, well-defined roles, attention to model building and validation makes UP preferred approach for large-scale development

28. Rapid Development Techniques • Collection of guidelines used to help an analyst complete system development activities or tasks • Risk management • Joint application design (JAD) • Tool-based development • Software reuse • Object frameworks

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

30. Major Categories of Development Schedule Risk

31. Steps in Risk Management Identify project risks Estimate risk outcomes & probabilities Prioritize risks Develop & implement mitigation strategies Project completed

32. Joint Application Design • Effective technique for quickly defining system requirements • Shortens development time by including all key decision makers • Can be incorporated into any development approach • Well suited to iterative development approaches

33. Tool-Based Development • Chooses tool(s) that best match system requirements • Do not develop any requirements not easily implemented with selected tool (s) • Applies generic 80/20 or 90/10 rule - resources best used to construct system that satisfies 80% or 90% of requirements most easily implemented • System limited by tool • No tool works for all development approaches

34. Software Reuse • Mechanism that allows software used for one purpose to be reused for another • Can shorten development schedule • Possible time savings must also consider • Effort required to identify reusable software • Effort required for modification • Extent to which software must be repackaged

35. Comparison of Various OO Code Reuse Methods

36. Object Frameworks • Set of foundation classes specifically designed to be reused in wide variety of programs or systems • User-interface classes • Generic data structure classes • Relational database interface classes • Classes specific to an application area • Programmers modify class attributes and methods for requirements of specific applications

37. Impact of Object Frameworks on Design • Frameworks must be chosen before detailed design begins • System must conform to specific assumptions about application program structure and operation that framework imposes • Development personnel must be trained on frameworks • Multiple frameworks might be required • Early compatibility and integration testing

38. Components • Standardized and interchangeable software module that is fully assembled and ready to use • Well-defined interfaces to connect component to clients or other components • Components are reusable packages of executable code • Structured design and object frameworks are methods of reusing source code

39. Component Standards and Infrastructure • Interoperability of components requires standards • Common Object Request Broker Architecture (CORBA) • Component Object Model Plus (COM+) • Enterprise JavaBean (EJB) • Simple Object Access Protocol (SOAP) and .NET • Web services

40. Component Communication Using SOAP

41. Components and the Development Life Cycle • Purchased components can form part or all of system • Components provide one model for designing and deploying systems • Component issues • Internally developed components • Object-oriented techniques • Designing components for reuse

42. Activities Added to SDLC Phases when Components are Purchased

43. Components and System Performance • Examine component-based designs to estimate network traffic patterns • Examine existing server capacity and network infrastructure to determine communication ability • Upgrade network and server prior to development • Test system performance and make adjustments • Continuously monitor system performance • Redeploy components, upgrade server capacity, and upgrade network to reflect changed conditions

44. Summary • Rapid application development (RAD) has goal of speeding application development • RAD techniques include risk management, joint application design, tool-based design, and software reuse • RAD approaches include prototyping, eXtreme programming, spiral development, the Unified Process • RAD tools include object frameworks and components and supporting infrastructure

45. Summary (continued) • Developer must examine project characteristics to determine which RAD concepts are likely to speed development • Software reuse and inheritance • Providing a library of reusable source code • Can be quickly adapted to new application requirements and operating environment • Components are units of reusable executable code that can be plugged into applications