1. Chapter 13 Current Trends in System Development
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
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
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