HW: Ch. 1 problems and exercises
1. Why is it important to use systems analysis and design methodologies when building a system? Why not just build the system in whatever way appears to be “quick and easy”? What value is provided by using an “engineering” approach? 2. How might prototyping be used as part of the SDLC?
3. Compare Figures 1-2 and 1-3. What similarities and differences do you see? 4. Compare Figures 1-2 and 1-4. Can you match steps in Figure 1-4 with phases in Figure 1-2? How might you explain the differences between the two figures? 5. Compare Figures 1-2 and 1-12. How do they differ? How are they similar? Explain how Figure 1-12 conveys the idea of speed in development.
6. Compare Figures 1-2 and 1-9. How does Figure 1-9 illustrate some of the problems of the traditional waterfall approach that are not illustrated in Figure 1-2? How does converting Figure 1-9 into a circle (like Figure 1-2) fix these problems? 7. Explain how object-oriented analysis and design differs from the traditional approach. Why isn’t RUP (Figure 1-13) represented as a cycle? Is that good or bad? Explain your response
It is important to use system analysis and design methodologies because it will ensure that your work is well thought out, complete, and comprehensible to others on your project team. By following the methodologies, support will be provided for a wide range of tasks, including conducting thorough interviews to determine what your system should do, planning and managing the activities in a systems development project, diagramming the system’s logic, and designing the reports your system will generate. You cannot just build a system in a way that appears to be quick and easy because if you develop something, put it on the market and it does not work, you will have to take it off the market and will have to fix the problem. By using an engineering approach, you can go through a cycle and go straight to the analysis part to see what is going on and why the system is not performing rather than, going back to square one.
The prototype would be used as part of the SDLC by planning, analysis, design, implementation, and maintenance. Information systems can be analyzed in this circular motion. For example, if you have a system that is fully developed and goes on the market, but does not really work as intended, you can go back to the cycle, see what went wrong, fix the problem so it does not happen again, put the system back on the market, and learn from it.
Figure 1-2 and figure 1-3 are similar because they both show how the cycle should be followed when analyzing a system. Figure 1-2 is different from figure 1-3 because the life cycle appears to be in order, but it is not. The specific steps and their sequence are meant to be used for a project that is consistent with management approaches.
Figures 1-2 and 1-4 are similar in fact that even figure 1-2 seems simpler than figure 1-4 they are actually still use in the same approach and that when implementing the life cycle every company takes the same approach. In Figure 1-2, starts with planning and the cycle ends with implementation. With figure 1-4, this figure starts with and initiation and ends with a disposition. This plan is mostly used by medium to large corporations.
Figure 1-2 and figure 1-12 are similar because they both use the same type of prototype or model. However figure 1-2 focuses specifically on how the cycle should be followed when analyzing a system. And figure 1-12 focuses specifically focuses on developing a system that pledges to be not only better and cheaper systems, but be more rapid in deployment by having systems developers and end users work together in real time to develop systems. Figure 1-12 conveys the idea of speed development by focusing work on system function and user interface requirements at the expense of detailed business analysis and concern for system performance issues. RAD usually looks at the system being developed in isolation from other systems, thus eliminating the time-consuming activities of coordinating with existing standards and systems during design and development. And RAD is less on sequence and structure and puts more emphasis on doing different tasks in parallel with each other and on using prototyping expansively.
Figure 1-9 shows us that instead of systems requirements being produced in analysis, systems specifications being created in design, coding, and testing are done at the beginning of implementation. The current practice combines all of these activities into a single analysis, design, code, and test process. By converting figure 1-9 into a circle, developing or redesigning a system can ensure that your work is well thought out, complete, and comprehensible to others on your project team. And it is much simpler than going back and forth between designing and analyzing something. You have to implement it to see if it works and if it does not, you will have to go back to the drawing board.
Object-oriented analysis and design is different from the traditional approach because object-oriented analysis and design develops methodologies and techniques based on objects rather than data or processes. The main goal is to make systems elements more reusable, thus improving system quality and the productivity of systems analysis and design. RUP in figure 1-13 is not represented as a cycle because this model it is represented how a system is made before it is distributed out. I believe that can be good and bad. It can be good because you have a plan on how to make a system before it is distributed. It can be bad because you do not have a plan if the system crashes and needs to be analyzed to see what happen so it will not happen again and what maintenance needs to be done before it goes back on the market.