AIS-1-MIDTERM-REVIEWER.pdf

AIS 1: CHAPTER 5: SYSTEM ANALYSIS Systems Analysis vs. Systems Design Repository – a location (or set of locations) where systems analysts, systems designers, and system builders keep all of the documentatio...

AIS 1: CHAPTER 5: SYSTEM ANALYSIS Systems Analysis vs. Systems Design Repository – a location (or set of locations) where systems analysts, systems designers, and system builders keep all of the documentation Systems analysis – a problem-solving technique that associated with one or more systems or projects. decomposes a system into its component pieces for the purpose of studying how well those component parts work and interact ❖ A network directory of computer-generated files that contain to accomplish their purpose. project correspondence, reports, and data ❖ A CASE tool dictionary or encyclopedia (Chapter 3) Systems design – a complementary problem-solving technique ❖ Printed documentation (binders and system libraries) (to systems analysis) that reassembles a system’s component ❖ An intranet website interface to the above components pieces back into a complete system—hopefully, an improved system. This may involves adding, deleting, and changing Model-Driven Analysis Methods pieces relative to the original system. Model-driven analysis – a problem-solving approach that emphasizes Information systems analysis – those development phases in the drawing of pictorial system models to document and validate both an information systems development project the primarily existing and/or proposed systems. Ultimately, the system model becomes focus on the business problem and requirements, independent the blueprint for designing and constructing an improved system. of any technology that Model – a representation of either reality or vision. Since “a picture is CONTEXT OF SYSTEMS ANALYSIS worth a thousand words,” most models use pictures to represent the reality or vision. Model-Driven Methods Structured analysis – a model-driven, process-centered technique used to either analyze an existing system, define business requirements for a new system, or both. The models are pictures that illustrate the system’s component pieces: processes and their associated inputs, outputs, and files. Information engineering (IE) – a model-driven and data-centered, but process-sensitive technique for planning, analyzing, and designing information systems. IE models are pictures that illustrate and synchronize the system’s data and processes. Object-oriented analysis (OOA) – a model-driven technique that integrates data and process concerns into constructs called objects. OOA models are pictures that illustrate the system’s objects from various perspectives such as structure and behavior, and interactions of the objects.  A SIMPLE DATA MODEL Object – the encapsulation of the data (called properties) that describes a discrete person, object, place, event, or thing, with all the processes (called methods) that are allowed to use or update the data and properties. The only way to access or update the object’s data is to use the object’s predefined processes. A SIMPLE PROCESS MODEL A SIMPLE OBJECT MODEL  Accelerated Systems Analysis Requirements Discovery Methods Accelerated systems analysis approaches emphasize the construction of Requirements discovery – the process, used by systems analysts prototypes to more rapidly identify business and user of identifying or extracting system problems and solution requirements for a new system. requirements from the user community. Approaches include: PROTOTYPE – a small-scale, incomplete, but Fact-finding – the process of collecting information about system working sample of a desired system. problems, opportunities, solution requirements, and priorities. Sampling of existing documentation, reports, forms, databases, etc Accelerated systems analysis approaches Research of relevant literature ❖ Discovery Prototyping Observation of the current system ❖ Rapid Architected Analysis Questionnaires and surveys Interviews Discovery prototyping – a technique used to identify the users’ business requirements by having them react Joint requirements planning (JRP) – the use of facilitated to a quick-and-dirty implementation of those workshops to bring together all of the system owners, users, and requirements. analysts, and some systems designer and builders to jointly perform systems analysis. Advantages: JRP is generally considered a part of a larger method called joint ➔ Prototypes cater to the “I’ll know what I want when I see it” way of application development (JAD), a more comprehensive application thinking that is characteristic of many users and managers. of the JRP techniques to the entire systems development process. Business process redesign (BPR) – the application of systems analysis Disadvantages: methods to the goal of dramatically changing and improving ➔ Can become preoccupied with final “look and feel” prematurely the fundamental business processes of an organization, independent of ➔ Can encourage a premature focus on, and commitment to, design information technology. ➔ Users can be misled to believe that the completed system can be built rapidly using prototyping tools SYSTEMS ANALYSIS METHODS AND AGILE METHODS Rapid architected analysis – an approach that attempts to derive system Agile method – the integration of various approaches of systems models (as described earlier in this section) from existing systems or analysis and design for applications as deemed appropriate to the discovery prototypes. problem being solved and the system being developed. Reverse engineering – the use of technology that reads the program Most commercial methodologies do not impose a single approach code for an existing database, application program, and/or user interface (structured analysis, IE, OOA) on systems analysts. and automatically generates the equivalent system model. Instead, they integrate all popular approaches into a collection of agile methods. System developers are given the flexibility to select from a variety of tools and techniques to best accomplish the tasks at hand, The hypothetical FAST methodology operates this way. FAST SYSTEMS ANALYSIS PHASES Cause-and-effect analysis – a technique in Scope Definition Phase which problems are studied to determine their causes and effects. Is the project worth looking at? In practice, effects can be symptomatic of more deeply rooted or basic problems which, in turn, must be analyzed for causes and Problem Analysis Phase effects until such a time as the causes and effects do not yield symptoms of other problems. Is a new system worth building? System Improvement Objectives Requirements Analysis Phase Objective – a measure of success. It is something that you What do the users need and want from the new system? expect to achieve, if given sufficient resources. Reduce the number of uncollectible customer accounts by 50 percent Logical Design Phase within the next year. Increase by 25 percent the number of loan applications that can be What must the new system do? processed during an eight-hour shift. Decrease by 50 percent the time required to reschedule a production Decision Analysis Phase lot when a workstation malfunctions. What is the best solution? Constraint – something that will limit your flexibility in defining a solution to your objectives. Essentially, constraints Scope Definition Phase cannot be changed. The new system must be operational by April 15. Steering body – a committee of executive business and system The new system cannot cost more than $350,000. managers that studies and prioritizes competing project The new system must be web-enabled. proposals to determine which projects will return the most value The new system must bill customers every 15 days. to the organization and thus should be approved for continues systems development. Functional vs. Nonfunctional Requirements Also called a steering committee. Functional requirement – a description of activities and services a Project charter – the final deliverable for the preliminary system must provide. investigation phase. A project charter defines the project scope, inputs, outputs, processes, stored data plan, methodology, standards, and so on. Preliminary master plan includes preliminary schedule and resource Nonfunctional requirement – a description of other features, assignments (also called a baseline plan). characteristics, and constraints that define a satisfactory system. Detailed plan and schedule for completing the next phase of the Performance, ease of learning and use, budgets, deadlines, project. documentation, security, internal auditing controls Expressing System Requirements Schedule feasibility – Can the solution be designed and implemented within an acceptable time period? Draft Functional and Nonfunctional Requirements - Could use simple list of system improvement objectives Candidate Systems Matrix - Increasingly systems analysts express functional requirements using Use Cases Use case – a business scenario or event for which the system must provide a defined response. Use cases evolved out of object-oriented analysis; however, their use has become common in many other methodologies for systems analysis and design. Prioritize System Requirements Prioritization of requirements can be facilitated using timeboxing. Timeboxing – a technique that delivers information systems functionality and requirements through versioning. 1. The development team selects the smallest subset of the system that, if fully implemented, will return immediate value to the systems owners and users. Candidate Systems Matrix (concluded) 2. That subset is developed, ideally with a time frame of six to nine months or less. 3. Subsequently, value-added versions of the system are developed in similar time frames. - A mandatory requirement is one that must be fulfilled by the minimal system, version 1.0 - A desirable requirement is one that is not absolutely essential to version 1.0. It may be essential to the vision of a future version. FEASIBILITY Technical feasibility – Is the solution technically practical? Does our staff have the technical expertise to design and build this solution? Operational feasibility – Will the solution fulfill the users’ requirements? To what degree? How will the solution change the users’ work environment? How do users feel about such a solution? Economic feasibility – Is the solution cost-effective? Feasibility Matrix