CS507 Information Systems Solved Subjective Short Questions Answers from Text Book (chapter 11- 14)
An information system is a sociotechnical entity, an arrangement of both technical and social elements. Information systems change involves hardware and software, but in addition it involves changes in jobs, skills, management and organization. When we design a new information system, we are redesigning the organization, reordering its technical and social elements.
The major categories of an information systems plan can be found in Table 10.1.
Both approaches attempt to gain a clear understanding of the organization's long and short-term information requirements. Both use interviews of managers to gain the information needed.
Enterprise analysis approaches the problem by looking at the entire organization in terms of organizational units, functions, processes and data elements. This approach takes a large sample of managers and asks them how they use information, where they get the information, what their environment is like, what their objectives are, how they make decisions and what their data needs are. This data is aggregated into subunits, functions, processes, and data matrices. From this information, conclusions are drawn about the organization-wide information systems requirements.
The CSF approach interviews a smaller number of top managers who are asked to identify their goals and the objectives essential to those goals. These critical success factors (CSFs) are aggregated to develop a picture of the overall organization's CSFs. The last step is to designate systems that are needed to deliver these critical success factors.
A business process is a set of logically related tasks performed to achieve a defined business outcome. Business process redesign is business re-engineering, changing a business process to improve speed, service and quality. It serves to reorganize work flows, combining steps to cut waste and eliminating repetitive, paper-intensive tasks, sometimes eliminating jobs as well. Business process redesign can be used to reshape how the organization carries out its business, even the nature of the business itself. Traditional automation automates the business process as it is in order to speed up the existing tasks, while rationalization of procedures changes some procedures largely within the framework of traditional business functions, eliminating obvious bottlenecks, making operating procedures more efficient, whereas business process redesign tries to streamline processes that transcend traditional functions.
System analysis is the analysis of the problem that the organization will try to solve with an information system. It consists of defining the problem, identifying its causes, specifying solutions and identifying the information requirements that must be met by a system solution.
System design shows how the system will fulfill the information requirements specified in system analysis. It has three objectives: considering alternative technology configurations, the management and control of the technical realization of the system, and detailing the system specifications.
Feasibility determines whether a solution is achievable given organizational resources and constraints. The three major areas of feasibility are: technical feasibility, which determines whether a proposed system can be implemented with available hardware, software and technical expertise; economic feasibility, which determines whether the proposed system will be cost-effective; and operational feasibility which determines whether the proposed system can function within the existing managerial and organizational framework.
Information requirements involves identifying who needs what information, where, when and how. They define the objectives of the new or modified system and contain a detailed description of the functions the new system must perform. Gathering information requirements is perhaps the most difficult task of the systems analyst, and faulty requirements analysis is a leading cause of systems failure and high systems development costs.
Information requirements are difficult to determine because business functions can be very complex and/or poorly defined. A manual system or a routine set of inputs and outputs may not exist. Procedures may vary from individual to individual, and users may disagree on how things are or should be done. Defining information requirements is a laborious process, requiring a great deal of research and often many reworkings by the analyst.
Logical design describes the components of an information system and their relationship to each other as they would appear to users. It shows what the system solution will be but not how it will actually be implemented. Physical design translates the abstract logical model into the specific technical design for the system. It produces the actual specifications for hardware, software, physical databases, input/output media, manual procedures and specific controls.
Testing is critical to the success of a system because it is the only way to ascertain whether the system will produce the right results. Three stages of information system testing are:
Conversion is the process of changing from the old system to the new one. A detailed conversion plan is essential to insure that all aspects of conversion are treated properly and validated. They include data conversion, procedure conversion and training.
Programming translates the design specification into software, thus providing the actual instructions for the computer. Programming constitutes a smaller portion of the systems development cycle than design and perhaps testing activities.
Production is the operation of the system once it has been installed and conversion is complete. The system will be reviewed during production by both users and technical specialists to determine how well it has met its original objectives and to decide whether any revisions or modifications are needed.
Maintenance is modifications to hardware, software, documentation or procedures to a production system to correct errors, meet new requirements or improve processing efficiency.
Financial models assume all relevant alternatives have been examined, that all costs and benefits are known, and that these costs and benefits can be expressed in terms of money. These assumptions are rarely met in the real world. Only tangible benefits can be quantified and assigned a monetary value. Intangible benefits cannot be immediately quantified but may lead to quantifiable gains in the long run. These models can be selectively used to support political decisions made for organizational reasons having nothing to do with the cost and benefits of a system. Financial models do not always express the risks and uncertainty of their own cost and benefit estimates. They also fail to consider the fact that costs are usually up front while benefits tend to be back-loaded. No financial model can adjust for the fact that information technology can easily change during the course of the project.
In addition, firms can invest in capital projects for many noneconomic reasons that are not captured by financial models. They may be undertaken to support strategic considerations or to meet government requirements or to satisfy some non-market public demand.
These two approaches can be used to select and evaluate information systems investments using nonfinancial and strategic considerations:
Portfolio analysis compares a portfolio of potential projects based upon the projects' expected risks and benefits. Projects are categorized as high or low risk and high or low benefits (benefits are not necessarily financial). Thus, four ratings are achieved: high risk-high benefits, high risk-low benefits, low risk-high benefits, and low risk-low benefits. High benefit-low risk projects are generally preferred, while low benefit-high risk projects are to be avoided.
The scoring model is a result, in a single score for a project that can then be used to compare against other projects scored the same way. Criteria are listed and weighted, and then alternative projects are rated by criteria, by those involved in judging the projects. Scoring models are meant to be relatively "objective" techniques, but involve many qualitative judgments. They are used most commonly to confirm, rationalize, and support decisions rather than to make decisions. Their greatest value often is the agreement on criteria to be used to judge the system.
As in the Lantech example, you are examining overall process improvement not just the cost/benefits of the intranet, for example. The system may have indirect upstream or downstream process flow benefits that the traditional analysis may not catch. The bigger picture of process improvement examines the whole process improvement not just one part. The Amdahl example shows that intranets may be overvalued.
TQM is a concept that makes quality control a responsibility to be shared by all people in an organization. For TQM the achievement of quality is an end in itself, and everyone is expected to contribute.
IS can contribute to TQM in a number of ways:
Software is central to many corporations because a wide range of departments, representing every phase of business, rely upon it, from payroll, financial systems and manufacturing to sales, research and management. A bug can result in lost sales, low quality or problemed products, even the loss of millions of dollars. In addition, a software bug in certain systems, such as some related to automobiles and airlines, can result in the loss of lives.
A number of software quality problems exist. Complex programs cannot be developed without bugs, and they cannot be tested in a way to uncover all bugs. When bugs are found, many times the programs operate no better after they are fixed than before. The definition of software quality is a problem, particularly achieving a definition that is measurable, agreed upon by both IS and users and actually reflecting the needs of the users. High cost of maintenance is the result of inadequate software quality.
The following can be done to significantly improve software quality.
1) The adoption and use of an appropriate development methodology should improve the overall quality of software. Within that methodology, organizations should:
2) Development of appropriate software metrics can help firms measure the functioning of the system while it is in production (input, output, capacity, performance and value metrics).
3)Attention to testing and to using effective methods for testing the system throughout the development phases (including use of walkthroughs where appropriate).
4) Resource allocation to place more project resources earlier in the development cycle.
5) The use of quality tools such as programming tools and project management software.
Structured analysis is a popular methodology for graphically modeling the flow of data throughout a system. The methodology can illustrate the inputs, processes and outputs of a system in different levels of abstraction, progressing from the most abstract upper level to successively lower levels of detail. A system can be thus broken down into a hierarchy of subsystems, functions and tasks, with the interfaces between these subsystems, functions and tasks clearly defined.
Data flow diagrams are the primary mechanism for analyzing and documenting a system through structured analysis. The data flow diagrams depict all of the component processes of a system and the flow of data between them. The diagrams can be "leveled" or broken down into successive layers of detail.
The data dictionary contains specific information about the components of the data flows and data stores in an information system. The components of each data flow or data store are listed and each data element defined.
Process specifications describe how data are being transformed by each of the processes of the data flow diagrams.
The main principle of structured design is that a system should be designed from the top down in a hierarchical fashion, each level of design encompassing greater levels of detail. The design should first capture the main functions of a program or system and then break these functions down into subfunctions until the lowest level of detail is reached. In this manner all program modules of a system can be hierarchically classified and related to each other. The resulting software design should be clearer and better organized and controlled.
Structured programming extends the principles governing structured design to the writing of programs. It is also based upon the principle of modularization which also follows from top-down development. Each of the boxes at the lowest level of the structure chart represents a logical unit that performs one or a small number of functions. Each of these functions becomes a program module.
System flowcharts graphically detail the flow of data throughout an entire information system. They depict all of the procedures that take input data and convert them to their final form. Using specialized symbols and flow lines, the system flowchart shows the overall structure of the system, traces the flow of information and work, shows the physical media on which data are input, output and stored, and highlights key processing and decision points.
Traditional structured methodology focuses on what the new system is intended to do and then develops the procedures and data to do it. Object oriented development de-emphasizes system procedures and instead creates a model of a system composed of individual objects that combine data and procedures. The objects are independent of any specific system. These objects can then be placed into any system being built that needs to make use of the data and functions. In addition in traditional structured methodologies all work is done serially, with work on each phase begun only when the previous phase is completed. Object oriented development theoretically allows simultaneous work on design and programming.
CASE stands for computer-aided software (or systems) engineering. It is an automation of step-by-step methodologies for software and systems development to reduce the amount of repetitive work the developer needs to do and to free the developer for more creative problem-solving efforts.
CASE can promote quality in IS by enforcing a standard development methodology, improving communication between users and technical specialists, automating error-prone portions of analysis and design, and facilitating revision of design specifications. It can also be used to generate code modules that have fewer errors and are structured. Finally, CASE facilitates the creation of clear documentation.
Software reengineering is a methodology that allows difficult-to-maintain unstructured software to be upgraded so that it can be maintained more easily. This allows organizations to continue to use software that otherwise might have to be abandoned. Reverse engineering is a group of tools that can be used for software reengineering. These tools read and analyze the existing program code and file and database descriptions and produce structured documentation of the system. These descriptions can then be revised if needed and then used to generate new, structured, maintainable code.
An information system "failure" may mean that a system falls apart but it usually means that the system is under-utilized or not used at all. This is because the system does not perform the functions for which it is intended or does so in a way that is too difficult or time-consuming to use. Users may have to develop "parallel" manual procedures to make the system work properly or rely on manual procedure entirely.
Information system failure is indicated by the following problems: reports that are neglected or never read: automated systems that are not used; data within a system that is not trusted; high operational costs; processing delays; chronic production problems.
The following are recognized as measures of system success:
Implementation refers to all of the organizational activities involved in the adoption, management and routinization of an innovation. For IS, implementation is the entire process of introducing, building and installing the system and can be considered a complex process of deliberate organizational change.
There are three major approaches to implementation in scholarly literature: 1) a focus on actors and roles, suggesting that organizations should promote actors with innovative characteristics and develop organizational roles championing innovation. 2) a focus on strategies of innovation, believing that successful innovations must have support from top-down and/or bottom-up. 3) a focus on general organizational change factors supportive of long-term routinization of innovations.
One of the most important determinants in system success and failure is the pattern of the implementation process. Especially critical facets of the implementation process are:
System failure may be due to factors outside the organization. An organization may be faced with external "environmental" pressures which it cannot meet because to do so would run counter to its inherent characteristics. However, many instances of system failure and negative implementation outcome are caused by factors within the organization.
While business re -engineering failures are often the result of the failure of management to identify the critical problems to be solved, in many other cases failure is the result if poor implementation and change in management practices and so are much the same as causes of systems implementation failure.
The "user-designer communications gap" refers to the conflict between the "technical" orientation of IS specialists and the "business" orientation of end-users. Often the objectives, priorities and language of communication between these groups is so different that they have entirely divergent goals. If serious, the "user-designer communications gap" prolongs implementation time. Users and IS specialists must spend additional time and effort trying to mutually understand one another. Users often forfeit their control over implementation to technical specialists. The result is an information system that makes sense to the technicians but doesn't meet users' business requirements.
Implementation problems at different stages of the life cycle (students may list other problems):
Influencing the level of project risk are:
External integration tools help solidify the relationship between implementation activities and end-users at all organizational levels. Such tools are most useful for projects that are not well-structured and which require heavy user involvement and commitment. Internal integration tools promote cohesion and unity within the implementation team. They are most useful for projects with high technical complexity. Formal planning and control tools help structure and sequence tasks and monitor progress towards goals. They are most valuable for managing projects that are large and/or well-structured.
End-user resistance to IS projects can be overcome by the following strategies:
Information system design must consider careful planning and orchestration of organizational change. Changes in job functions, organizational structure, power relationships, procedures and behavior will have to be addressed. Technical solutions must be developed around an appropriate "social design" for an information system.