Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "Chapter 13 Current Trends in System Development Chapter 17 Systems Analysis and Design in a Changing World, 3 rd Edition."— Presentation transcript:

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

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

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

4 Cost of Change in Each Project Phase

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

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

7 Development Approach as a Function of Project Characteristics

8 Prototyping Approach to Development u Discovery prototype l Used in analysis or early design l Uncover or refine system requirements l Can be thrown away u Developmental prototype l Not thrown away l 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 u When to use: l Requirements cannot be fully specified outside of architectural or detailed design l Technical feasibility unknown or uncertain l Development tools powerful enough to create functional system u When not to use: l System is non-interactive or internally complex l Strict security or performance requirements exist

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

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

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

14 The Spiral Life Cycle

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

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

17 Cumulative Cost Plotted Against Time

18 eXtreme Programming (XP) u Rapid development approach u Focused on creating user stories, delivering releases of system, and quickly testing  Developed by Kent Beck in mid-1990 ’ s u 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 u Continuous automated testing u Continuous integration u Heavy user involvement u Team programming or pair programming u Specific attention to human interactions and limitations

21 Comparison of Traditional, Spiral, and XP Development

22 When to Use XP u Small development teams (12 or less) u Talented development personnel with broad range of skills u Limited scope of projects l Stand-alone l New systems l Minimal interfaces to legacy system u Extensive use of high-quality OO development and testing tools

23 The Unified Process u Comprehensive development approach l Originally developed by Jacobsen, Booch, and Rumbaugh in late 1990s l Dominant approach for developing software with OO models and tools l Adopts iteration from prototyping and spiral development approaches l 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 u Timeboxing - organizing a complex task or project into series of equal-length time intervals u More effective when iterations are relatively short and each iteration produces concrete result l Frequent testing, immediate user feedback, motivation, and greater accomplishment u Disciplines include business modeling, requirements, design, implementation, and project management

26 UP Development is Series of Iterations

27 When to Use the Unified Process u Benefits and risks mirror spiral development u Major obstacles to adopt UP include: l Complex project management (compared to sequential development) required l 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 u Collection of guidelines used to help an analyst complete system development activities or tasks l Risk management l Joint application design (JAD) l Tool-based development l Software reuse l Object frameworks

29 Risk Management u Systematic process of identifying and mitigating software development risks l Most risks can be identified if specific attention is directed to them l Risks appear, disappear, increase, and decrease as development process proceeds l Small risks should be monitored and large risks mitigated u 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 u Effective technique for quickly defining system requirements u Shortens development time by including all key decision makers u Can be incorporated into any development approach u Well suited to iterative development approaches

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

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

35 Comparison of Various OO Code Reuse Methods

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

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

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

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

40 Component Communication Using SOAP

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

42 Activities Added to SDLC Phases when Components are Purchased

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

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

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

Download ppt "Chapter 13 Current Trends in System Development Chapter 17 Systems Analysis and Design in a Changing World, 3 rd Edition."

Similar presentations

Ads by Google