1. Chapter 2: System Development Methodologies & Automated Systems 1

2. Learning Objectives Understand the evolution of system development methodologies Understand the use of CASE Tools in System Development 2

3. System Development Methodologies Methodology: a formalized approach to implementing the SDLC A set of sequential stages Categories Process oriented Data centered Object-oriented Structured Rapid action development Agile development 3

4. Classes of Methodologies Structured Development Waterfall Development Parallel Development Rapid Application Developmen t Phased Prototyping Agile Development eXtreme Programming (XP) 4

5. Example: Making a Simple Lunch 5

6. Structured Development: Waterfall Development The original structured design methodology (that is still used today) The analysts and users proceed in sequence from one phase to the next The key deliverables for each phase are typically very long (often hundreds of pages in length) and are presented to the project sponsor for approval as the project moves from phase to phase. 6

7. Once the sponsor approves the work that was conducted for a phase, the phase ends and the next one begins. This methodology is referred to as waterfall development because it moves forward from phase to phase in the same manner as a waterfall. While it is possible to go backward in the SDLC (e.g., from design back to analysis), it is extremely difficult. 7

8. 8

9. Pros & Cons ProsCons Identifies system requirements long before programming begins The design must be completely specified before programming begins Minimizes changes to the requirements as the project proceeds A long time elapses between the completion of the system proposal in the analysis phase and the delivery of the system (usually many months or years) 9

10. Structured Development: Parallel Development The parallel development methodology attempts to address the problem of long delays between the analysis phase and the delivery of the system. Instead of doing design and implementation in sequence, it performs a general design for the whole system and then divides the project into a series of distinct subprojects that can be designed and implemented in parallel. Once all subprojects are complete, there is a final integration of the separate pieces, and the system is delivered 10

11. 11

12. Pros & Cons ProsCons It can reduce the schedule time to deliver a system Too many documents Less chance of changes in the business environment causing rework adds a new problem 12

13. Rapid Application Development A second category of methodologies includes rapid application development (RAD)–based methodologies that emerged in the 1990s. RAD-based methodologies attempt to address both weaknesses of structured design methodologies by adjusting the SDLC phases to get some part of the system developed quickly and into the hands of the users. Users can better understand the system and suggest revisions that bring the system closer to what is needed. 13

14. Most RAD-based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases, CASE tools Joint Application Design (JAD) sessions Fourth generation/visual programming languages that simplify and speed-up programming (e.g., Visual Basic), code generators that automatically produce programs from design specifications. It is the combination of the changed SDLC phases and the use of these tools and techniques that improve the speed and quality of systems development. 14

15. RAD: Phased Development A phased development–based methodology breaks the overall system into a series of versions that are developed sequentially. The analysis phase identifies the overall system concept, and the project team, users, and system sponsor then categorize the requirements into a series of versions. The most important and fundamental requirements are bundled into the first version of the system. The analysis phase then leads into design and implementation, but only with the set of requirements identified for version 1. 15

16. Once version 1 is implemented, work begins on version 2. Additional analysis is performed based on the previously identified requirements and combined with new ideas and issues that arose from the users’ experience with version 1. Version 2 then is designed and implemented, and work immediately begins on the next version. This process continues until the system is complete or is no longer in use. 16

17. 17

18. Pros & Cons ProsCons Users Get a System To Use Quickly Users Work with a System that is Intentionally Incomplete Users Can Identify Additional Needs For Later Versions 18

19. RAD: Prototyping A prototyping-based methodology performs the analysis, design, and implementation phases concurrently, and all three phases are performed repeatedly in a cycle until the system is completed. the basics of analysis and design are performed, and work immediately begins on a system prototype, a “quick-and dirty” program that provides a minimal amount of features. First prototype is usually the first part of the system that the user will use. 19

20. 1 st Prototype- shown to the users and project sponsor who provide comments :- re-analyze, re-design, and re-implement a second prototype that provides a few more features. This process continues in a cycle until the analysts, users, and sponsor agree that the prototype provides enough functionality to be installed and used in the organization. After the prototype (now called the system) is installed, refinement occurs until it is accepted as the new system 20

21. 21

22. Pros & Cons ProsCons Users Interact with Prototype Very QuicklyTendency to do Superficial Analysis (Careful Analysis) Initial Design Decisions May Be Poor Users Can Identify Needed Changes And Refine Real Requirements 22

23. RAD: Throwaway Prototyping Similar to prototyping-based methodologies in that they include the development of prototypes. However throwaway prototypes are done at a different point in the SDLC. These prototypes are used for a very different purpose than ones previously discussed, and they have a very different appearance. The throwaway prototyping-based methodologies have a relatively thorough analysis phase that is used to gather information and to develop ideas for the system concept. 23

24. 24

25. Each of these issues is examined by analyzing, designing, and building a design prototype. A design prototype is not a working system. It is a product that represents a part of the system that needs additional refinement, and it only contains enough detail to enable users to understand the issues under consideration. A system that is developed using this type of methodology probably relies on several design prototypes during the analysis and design phases. 25

26. Each of the prototypes is used to minimize the risk associated with the system by confirming that important issues are understood before the real system is built. Once the issues are resolved, the project moves into design and implementation. At this point, the design prototypes are thrown away, which is an important difference between these methodologies and prototyping methodologies, in which the prototypes evolve into the final system. 26

27. Pros & Cons ProsCons Risks are Minimized May Take Longer Than Prototyping Important Issues are Understood Before the Real System is Built 27

28. Agile Development These programming-centric methodologies have few rules and practices, all of which are fairly easy to follow. They focus on streamlining the SDLC by eliminating much of the modeling and documentation overhead, and the time spent on those tasks Projects emphasize simple, iterative application development. Example: extreme programming (XP) 28

29. Agile Development: Extreme Programming Is founded on four core values: communication, simplicity, feedback, and courage. These four values provide a foundation on which XP developers use to create any system. First, the developers must provide rapid feedback to the end users on a continuous basis. Second, XP requires developers to follow the KISS principle.. 29

30. Third, developers must make incremental changes to grow the system and they must not only accept change, they must embrace change. Fourth, developers must have a quality first mentality. XP also supports team members in developing their own skills 30

31. XP Key Principles Three of the key principles that XP uses to create successful systems are Continuous testing, simple coding performed by pairs of developers, and close interactions with end users to build systems very quickly. An XP project begins with user stories that describe what the system needs to do. Then, programmers code in small, simple modules and test to meet those needs. 31

32. Users are required to be available to clear up questions and issues as they arise. XP projects deliver results sooner than even the RAD approaches, and they rarely get bogged down in gathering requirements for the system. 32

33. Pros & Cons ProsCons Fast Delivery of ResultsRequires Discipline Works Well in Projects With Undefined or Changing Requirements Works Best in Small Projects Requires Much User Input 33

34. Selecting the Appropriate Development Methodology 1. Clarity of User Requirements 2. Familiarity of Technology 3. System Complexity 4. System Reliability 5. Short Time Schedules 6. Schedule Visibility 34

35. Which Methodology to Use? 35

36. Automated Tools for System Development Computer-aided software engineering (CASE) is a category of software that automates all or part of the development process. Some CASE software packages are primarily used during the analysis phase to create integrated diagrams of the system and to store information regarding the system components (often called upper CASE). Whereas others are design-phase tools that create the diagrams and then generate code for database tables and system functionality (often called lower CASE). 36

37. Objectives of CASE Improve quality of systems developed Increase speed of development and design Ease and improve testing process through automated checking Improve integration of development activities via common methodologies Improve quality and completeness of documentation Help standardize the development process Improve project management Simply program maintenance Promote reusability Improve software portability 37

38. Benefits of CASE The benefits to using CASE are numerous. Tasks are much faster to complete and alter Development information is centralized Information is illustrated through diagrams, which typically are easier to understand. CASE can reduce maintenance costs Improve software quality, and enforce discipline, and some project teams even use CASE to assess the magnitude of changes to the project. 38

39. The central component of any CASE tool is the CASE repository, otherwise known as the information repository or data dictionary. The CASE repository stores the diagrams and other project information, such as screen and report designs, and it keeps track of how the diagrams fit together. For example, most CASE tools will warn you if you place a field on a screen design that doesn’t exist in your data model. As the project evolves, project team members perform their tasks using CASE. 39

40. Summary There are several methodologies that can be use to develop system:- Waterfall Parallel Phased Development Prototyping XP Criteria for selecting the appropriate methodologies:- Clarity of user requirements Familiarity with technology 40

41. System complexity System reliability Short Time schedules Schedule Visibility Automated Tools System Development CASE Tools Objectives of CASE Tools Benefits of CASE 41