Lecture 5 System Analysis and Design PDF

# System Analysis and Design ## Chapter 2 Agenda Part 3 - Systems Development Methodologies - RAD - Agile Development - Selecting the Appropriate Development Methodology ## Systems Development Methodologies - SDM - Structured Design - Rapid Application Development (RAD) - A...

# System Analysis and Design ## Chapter 2 Agenda Part 3 - Systems Development Methodologies - RAD - Agile Development - Selecting the Appropriate Development Methodology ## Systems Development Methodologies - SDM - Structured Design - Rapid Application Development (RAD) - Agile Development ## Rapid Application Development (RAD) - These are a newer class of systems development methodologies that emerged in the 1990s. - RAD based methodologies attempt to address 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. - In this way, the user's can better understand the system and suggest revisions. - Most RAD based methodologies recommend that analysts use special techniques and computer tools to speed up the analysis, design, and implementation phases such as; - CASE tools - Joint Application Design (JAD) sessions - Fourth generation programming languages that simplify and speed up programming (e.g., Perl, Python, Ruby, SQL), - And code generators that automatically produce programs from design specifications. - The combination of the changed SDLC phases and the use of these tools and techniques improves the speed and quality of systems development. - However, there is one possible problem with RAD based methodologies: managing user expectations. - As a user better understands the information technology, the systems requirements tend to expand. ## Rapid Application Development (RAD) - RAD - Phased Development - Prototyping - Throwaway Prototyping ## Phased Development - A phased development based methodology breaks an overall system into a series of versions which are developed sequentially. - The analysis phase identifies the overall system concept and the project team, user's, 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. - 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/issues that arose from the user's 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. <start_of_image> Schematic Diagram: ``` Planning v Analysis v System Version 3 Analysis v v Implementation Analysis v v System Version 2 Design v v Implementation Implementation v v System Version 1 Phased Development ``` - Phased development based methodologies have the advantage of quickly getting a useful system into the hands of the users. - Although the system does not perform all the functions the users need at first, it does begin to provide business value sooner than if the system were delivered after completion. - Likewise, because users begin to work with the system sooner, they are more likely to identify important additional requirements sooner than with structured design situations. - The major drawback to phased development is that users begin to work with systems that are intentionally incomplete. - It is critical to identity the most important and useful features and include them in the first version and to manage user's expectations along the way. ## 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. - With these methodologies, 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 number of features. - The first prototype is usually the first part of the system that is used. This is shown to the users and the project sponsor who provide comments. - These comments are used to reanalyze, redesign, and reimplement a second prototype which 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. Schematic Diagram: ``` Planning v Analysis v Design v System Prototype v Implementation v System Prototyping ``` - The key advantage of a prototyping based methodology is that it very quickly provides a system within which the users can interact, even if it is not ready for widespread organizational use at first. - Prototyping reassures the user's that the project team is working on the system (there are no long delays in which the user's see little progress). - Prototyping helps to more quickly refine real requirements. - Rather than attempting to understand a system specification on paper, the user's can interact with the prototype to better understand what it can and cannot do. - Its fast paced system releases challenge attempts to conduct careful, methodical analysis. - Often the prototype undergoes such significant changes that many initial design decisions become poor ones. - This can cause problems in the development of complex systems because fundamental issues and problems are not recognized until well into the development process. ## Throwaway Prototyping - Throwaway prototyping based methodologies are like 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 those 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. - However, user's may not completely understand many of the features they suggest and there may be challenging technical issues to be solved. Each of these issues are 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 contains only enough detail to enable user's to understand the issues under consideration. - For example, suppose users are not completely clear on how an order entry system should work. - The analyst team might build a series of HTML pages viewed using a Web browser to help the users visualize such a system. In this case, a series of mockup screens appear to be a system, but they really do nothing. - Or suppose that the project team needs to develop a sophisticated graphics program in Java. - The team could write a portion of the program with pretend data to ensure that they could do a full-blown program successfully. Schematic Diagram: ``` Planning v Analysis v Design v Design Prototype v Implementation v System Throwaway Prototyping ``` - A system developed using tis type of methodology probably relies on several design prototypes during the analysis and design phases. - 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. - Throwaway prototyping based methodologies balance the benefits of well-thought-out analysis and design phases with the advantages of using prototypes to refine key issues before a system is built. - It may take longer to deliver the final system as compared to prototyping-based methodologies (because the prototypes do not become the final system), but this type of methodology usually produces more stable and reliable systems. ## Systems Development Methodologies - SDM - Structured Design - Rapid Application Development (RAD) - Agile Development ## Agile Development - Agile development approach is an iterative and flexible approach to software development that emphasizes collaboration, adaptability, and continuous improvement. - It has gained popularity due to its ability to accommodate changing requirements and deliver high-quality software in a more efficient and adaptable manner. - The key principles of agile development include; - Customer collaboration over contract negotiation - Individuals and interactions over processes and tools - Working software over comprehensive documentation. - Responding to change over following a plan. - They typically involve breaking down the project into small, manageable increments called "sprints" or "iterations," with each iteration delivering a working piece of software. - The development team holds regular meetings, such as daily stand-ups, to discuss progress, identify and address any roadblocks, and plan the next steps. - Continuous feedback adaptation are fundamental to agile methodologies. At the end of each iteration, the team reviews the progress, gathers feedback, and incorporates it into the subsequent iterations. - This iterative approach allows for early and frequent delivery of working software, increasing customer satisfaction, and reducing the risk of large-scale failures. ## Agile Development - AD - Extreme Programming - Scrum - Kanban ## Extreme Programming (XP) - Founded on four core values: communication, simplicity, feedback, and courage. - First, the developers must provide rapid feedback to the end user's on a continuous basis. - Second, XP requires developers to follow the KISS principle. - Third, developers must make incremental changes to grow the system, and they must not only accept change, but they must also embrace change. - Fourth, developers must have a quality-first mentality. XP also supports team members in developing their own skills. Schematic Diagram: ``` Planning/feedback loops v Release Plan ----------------------> Code Months Iteration Plan -----------------------> Code Weeks Acceptance Test -----------------------> Code Days Stand-up Meeting -----------------------> Code One Day Pair Negotiation -----------------------> Code Hours Unit Test -----------------------> Code Minutes Pair Programming -----------------------> Code Seconds XP Loop ``` - 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. - After a superficial planning process, projects perform analysis, design, and implementation phases iteratively. - Testing and efficient coding practices are core to XP. In fact, code is tested each day and is placed into an integrative testing environment. If bugs exist, the code is backed out until it is completely free of errors. - XP relies heavily on refactoring, which is a disciplined way to restructure code to keep it simple. - 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. - Users are required to be available to clear up questions and issues as they arise. - Standards are very important to minimize confusion, so XP teams use a common set of names, descriptions, and coding practices. - XP projects deliver results sooner than even the RAD approaches, and they rarely gt bogged down in gathering requirements for the system. - For small projects with highly motivated, cohesive, stable, and experienced teams, XP should work just fine. However, the project success is doubtful if the project is large, or the teams aren't jelled. - Due to the lack of analysis and design documentation, there is only code documentation associated with XP so maintaining large systems built with XP may be impossible. ## Selecting the Appropriate Development Methodology - Because there are many methodologies, the first challenge faced by analysts is to select which methodology to use. - Choosing a methodology is not simple, because no one methodology is always best. (If it were, we'd simply use it everywhere!) Many organizations have standards and policies to guide the choice of methodology. - Clarity of User Requirements - Familiarity with Technology - System Complexity - System Reliability. - Short Time Schedules. - Schedule Visibility - Clarity of User Requirements: When the user requirements for a system are unclear, it is difficult to understand them by talking. - Users normally need to interact with technology to really understand what a new system can do and how to best apply it to their needs. Prototyping- and throwaway prototyping-based RAD methodologies are usually more appropriate when user requirements are unclear because they provide prototypes for users to interact with early in the SDLC. - Familiarity with Technology: When the system will use new technology with which the analysts and programmers are not familiar (e.g., the first Web development project with Java), risks increase because the tools might not be capable of doing what is needed. - Throwaway prototyping-based methodologies are particularly appropriate if users lack familiarity with technology because they explicitly encourage the developers to develop design prototypes for areas with high risks. - Phased development-based methodologies are good as well, because they create opportunities to investigate the technology in some depth before the design is complete. Although you might think prototyping-based methodologies are also appropriate, they are much less appropriate because the early prototypes that are built usually only scratch the surface of the new technology. It is generally only after several prototypes and several months that the developers discover weaknesses or problems in the new technology. - System Complexity: Require careful and detailed analysis and design. - Throwaway prototyping-based methodologies are particularly well suited to such detailed analysis and design, as opposed to prototyping-based methodologies, which are not. - The traditional structured design-based methodologies can handle complex systems, but without the ability to get the system or prototypes into the user's hands early on, some key issues maybe overlooked. - Although phased development-based methodologies enable users to interact with the system early in the process, we have observed that project teams who follow these tend to devote less attention to the analysis of the complete problem domain that they might using other methodologies. - System Reliability: Is usually an important factor in system development after all, who wants an unreliable system? However, reliability is just one factor among several. For some applications reliability is truly critical (e.g., medical equipment, missile control systems). Throwaway prototyping methodologies are the most appropriate when system. - Prototyping methodologies are generally not a good choice when reliability is critical because it lacks the careful analysis and design phases that are essential for dependable systems. - Short Time Schedules: Projects that have short time schedules are well suited for RAD-based methodologies. This is due to them being designed to increased the speed of development. - Prototyping and phased development-based methodologies are excellent choices when timelines are short. - Waterfall-based methodologies are the worst choice when time is as a premium-because they do not allow for easy schedule changes. - Schedule Visibility: One of the greatest challenges in systems development determining whether a project is on schedule. - This is particularly true of the structured design methodologies because design and implementation occur at the end of the project. - The RAD-based methodologies move many of the critical design decisions earlier in the project to help project managers recognize and address risk factors and keep expectations in check. ## Summary - Systems Development Methodologies - RAD - Agile Development - Selecting The Appropriate Development Methodology