LIM, MARYLYN GRACE C.
OOA
Book: Systems Analysis and Design: an Active Approach
Author: George M. Marakas
Reference No.: QA
76.9
S88
M37
2001
Chapter 8: Moving from Analysis to Design
Quote: “There are many hows but only one what. Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity.
Review:
As what the title of chapter 8 says, “Moving from analysis to design”. This chapter talks about designing a system. After analyzing the current system, it’s now time to design a new system. Before a system analyst could design and implement their proposed solution, they should have a design strategy. Design strategy is a process in pursuing the physical development of the system. This is an approach that is being followed to transform the logical system requirement into a functional, physical IS.
There are 8 selection of design strategy. 1.) Generating alternative design strategies. Even if the proposed system is the exact solution to the problem of the current system, there is still a feasibility assessment that is being conducted which includes determining the viability of pursuing the physical system on a number if dimensions. 2.) Do nothing. A system analyst should know the existence of the problem and fully understand its implement a solution to the problem. So that all the hard work of the analyst will be worth it. 3.) Explore all possible non-automated solution. It is important that analyst should give attention to the potential for solving the problem in a non-automated manner. This says that before an analyst inject the complexities of automation to the solution; they must first look to portions of solution that can be affected without computer. 4.) Buy versus make. This is to let the analyst know how to acquire the physical system components, especially the software applications, which led to one of the 3 basic approaches. A.) buy a COTS solution and customize it to fit in the system. B.) develop a custom software application or C.) Outsource the project to an external developer. 5.) COTS. This provides a solution that is well tested, proven and readily available than a custom-developed application. 6.) Custom software development. If an analyst builds the software from scratch it would be advantage for him because he has the complete control over the look, feel and functionality of the new system. 7.) Outsourcing. This can help bring opportunities to bring increased value to the business. 8.) Hardware design strategy issues. Other than focusing software development, analyst should also focus on issues related to hardware, as it relates to the application software under development and the business needs of the organization.
The dimensions of system feasibility allow the analyst to insure that the business case for the development and implementation of the new system is made from a fact-based perspective. In order to do this feasibility analyst, there are 5 primary dimensions being looked at. 1.) Technical feasibility. This determines the practicality of a specific technical solution and the availability of technology to implement it. 2.) Operational feasibility. This focuses on issues related to how well the new system will work within the organization and how the users feel about it. 3.) Human factor feasibility. This focuses on issues regarding system usability and end-user training. 4.) Legal and political feasibility. This focuses on issues that may be associated with the new system or any political impacts likely as a result of its deployment. 5.) Economic feasibility. This identifies the financial and net economic impacts to the organization of the new system.
Comments (0)
You don't have permission to comment on this page.