Building Successful Information Systems

The homework assignments will consist of not less than 1 page (standard double-spaced with 1 inch margins all around) of TEXT in length (Title Pages, Tables of Content, figures, pictures, graphs, and references will not be counted as text. Title Page is required. Table of Contents is not required; an Abstract is not required.) At this point, let me remind you that if you use Microsoft Word to produce your paper, its default is 1.25 inches, and you need to change it to one inch. Use only 12 point Times New Roman font on your papers. This will keep paper length consistent for everyone. Since a word processor is likely to be used in preparation of the paper, it is expected that there will be NO spelling errors. I will caution you that ‘Spell Check’ will not catch words spelled correctly but not in the correct context. Accuracy is important. Grammar and spelling errors will be penalized at 1 point per occurrence. Clarity can affect understanding. If your work is difficult to understand, the content is questionable.

Proper credit for references used will be included and will be cited within the paper as well as in a References page. There will be at least two (2) outside references used (the text book does not count as one). In other words, you will have to do some research to back up your conclusions.

Don't use plagiarized sources. Get Your Custom Essay on
Building Successful Information Systems
Just from $13/Page
Order Essay

Note: The APA style of writing has a References page. It does not have a Works Cited page or Bibliography.

Papers will be consistent with the APA style manual format. (The requirement for APA style of writing will be worth at least 30% of your grade.)

In the Main Menu section of Blackboard is a rubric that will be used to grade Research Paper. The rubric will also be used for homework assignments.

There is also a link to the Wayland Library (LRC) and one to the Wayland Writing Center if you need help. I am also available via email.

Topics:

As listed in Assignments in Blackboard.

Attribution:

All works and illustrations used in your paper must be cited; this means crediting the source where you found the information you used to support your work. If you fail to give credit for copyrighted information you present as your own work; that constitutes plagiarism, and will be penalized by a zero for the project. ALL statements of fact MUST be supported by references and citations.

NOTE: An author must be a person and the date is the year of publication.

Citations should be in the format: (Author(s), date) or if for a quote (Author(s), date, page). If the Reference is no longer than one (1) page the citation for a quote should be (Author(s), date, paragraph). If citations are not correct a minimum of 10% will be deducted.

References – This is the source material you used to support your research project. Sources without an author and/or date should not be used. Look in the APA manual or in the Wayland Writing Center/Research and Writing Guides. If References are not correct a minimum of 10% will be deducted.

If neither references nor citations are given for your research for Homework Assignments your score will be 0 for the Assignment.

NOTE 1: References without an author (person) and a date (year of publication) will not be accepted (This means references must have both).

 

 

 

Phase 1: Planning

During the planning phase, which is one of the most crucial phases of the SDLC model, the systems designer must define the problem the organization faces, taking care not to define symptoms rather than the underlying problem. The problem can be identified internally or externally. An example of an internally identified problem would be management voicing concern about the organization’s lack of a competitive edge in the marketplace. An example of an externally identified problem would be suppliers noting inefficiency in the inventory control procedure.

After identifying the problem, an analyst or team of analysts assesses the current and future needs of the organization or a specific group of users by answering the following questions:

Why is this information system being developed?

Who are the system’s current and future users?

Is the system new, or is it an upgrade or extension of an existing system?

Which functional areas (departments) will be using the system?

As part of this assessment, analysts must examine the organization’s strategic goals, how the proposed system can support these goals, which factors are critical to the proposed system’s success, and the criteria for evaluating the proposed system’s performance. Establishing evaluation criteria ensures objectivity throughout the SDLC process.

In addition, analysts must get feedback from users on the problem and the need for an information system. During this phase, they need to make sure users understand the four Ws:

Why—Why is the system being designed? Which decisions will be affected?

Who—Who is going to use the system? Is it going to be used by one decision maker or a group of decision makers? This question is also about types of users. For example, will the Marketing Department be using the system? And will the Manufacturing Department be using the system as suppliers or as consumers of information?

When—When will the system be operational? When in the business process (in what stages) will the system be used?

What—What kind of capabilities will the system provide? How will these capabilities be used?

The end result of this phase should give users and top management a clear view of what the problem is and how the information system will solve the problem. As an example, here is a look at how ABC Furniture is planning for an information system to solve the problem of inaccurate inventory forecasts. Currently, ABC Furniture buys wood from New England Wood (NEW).

Why—ABC Furniture needs an information system to track inventory, generate a more accurate forecast of product demand, and track requirements for wood to be ordered from NEW. Clearly, a more accurate inventory will help reduce inventory costs, improve ABC Furniture’s relationship with NEW and with distributors, ensure the company’s products are available for retailers, and improve ABC’s image in the marketplace.

Who—The main users of the information system will be the procurement group responsible for placing orders with NEW, the manufacturing division responsible for tracking inventory and ensuring that demand for finished goods is met, the sales personnel who take orders from distributors, and possibly distributors who take orders from retailers.

When—The system must become operational within the next four months because the company’s main competitor is planning to open a new store in six months. Furthermore, the system must support the materials-ordering stage, the production-planning stage, and the shipping stage of the manufacturing process. It must also supply information for the marketing campaign that ABC Furniture is planning to run in five months and support ABC’s expansion into a new region.

What—On the inbound side, the system must track pending and received deliveries, quantities of raw materials, orders placed for raw materials, and raw material levels from all of ABC’s suppliers, including NEW. On the operations side, the system must provide information on inventory levels of all products, raw materials, work in progress at each stage of manufacturing, quality of raw materials received, quality of finished goods inspected, and rejects. On the outbound side, the system must track placed orders, unfulfilled orders, and fulfilled orders for each finished product as well as the order history for each distributor and retailer demand.

Formation of the Task Force

To ensure an information system’s success, users must have input in the planning, requirements-gathering and analysis, design, and implementation phases. For this reason, a task force is formed, consisting of representatives from different departments (including IT), systems analysts, technical advisors, and top management. This team collects user feedback and works toward getting users involved from the beginning.

The system designers and analysts should explain the goals and benefits of the new system so the task force knows what to look for in user input. Generally, an information system has two groups of users from whom the task force should gather feedback: internal and external. Internal users are employees who will use the system regularly, and they can offer important feedback on the system’s strengths and weaknesses. External users are not employees but do use the system; they include customers, contractors, suppliers, and other business partners. Although external users are not normally part of the task force, their input is essential.

Using a task force for designing an information system is similar to using the joint application design approach. Joint application design (JAD) is a collective activity involving users, top management, and IT professionals. It centers on a structured workshop (called a JAD session) in which users and system professionals come together to develop an application. It involves a detailed agenda, visual aids, a leader who moderates the session, and a scribe who records the specifications. It results in a final document containing definitions for data elements, workflows, screens, reports, and general system specifications. An advantage of the JAD approach is that it incorporates varying viewpoints from different functional areas of an organization to help ensure that collected requirements for the application are not too narrow and one-dimensional in focus.Phase 3: Design

During the design phase, analysts choose the solution that is the most realistic and offers the highest payoff for the organization. The details of the proposed solution are outlined, and the output of this phase is a document with exact specifications for implementing the system, including files and databases, forms and reports, documentation, procedures, hardware and software, networking components, and general system specifications. For large projects in particular, computer-aided systems engineering tools (discussed in the next section) are helpful in the analysis and design phases.

During the design phase, analysts choose the solution that is the most realistic and offers the highest payoff for the organization.

The design phase consists of three parts: conceptual design, logical design, and physical design. The conceptual design is an overview of the system and does not include hardware or software choices. The logical design makes the conceptual design more specific by indicating hardware and software, such as specifying Linux servers, Windows clients, an object-oriented programming language, and a relational DBMS. These choices usually require changing the conceptual design to fit the platforms and programming languages chosen. Finally, the physical design is created for a specific platform, such as choosing Dell servers running Ubuntu Linux, Dell laptops running Windows 10 and Internet Explorer, Java for the programming language, and SQL Server 2016 for the relational DBMS.

Feasibility Study

Feasibility is the measure of how beneficial or practical an information system will be to an organization; it should be measured continuously throughout the SDLC process (see the information box “A Feasible Project Becomes Unfeasible”). Upper management is often frustrated by information systems that are unrelated to the organization’s strategic goals or have an inadequate payoff, by poor communication between system users and designers, and by designers’ lack of consideration for users’ preferences and work habits. A detailed feasibility study that focuses on these factors can help ease management’s frustration with investing in information systems.

A Feasible Project Becomes Unfeasible

WestJet Airlines, a Canadian discount airline in Calgary, announced in July 2007 that it was stopping development on a new reservation system called AiRES, even though it had invested $30 million in the project. The problem was not with Travelport, the company developing the system. WestJet simply grew faster than anticipated, and the original specifications for the reservation system did not address this fast growth. Management wanted to add features, such as the capability to partner with international carriers, but the system had been planned to fit a small discount airline, not a large international airline. WestJet suspended the work of 150 internal IT specialists and about 50 outside consultants. This example shows the need for conducting feasibility studies through a project’s life cycle. If WestJet had continued the project, the potential losses would have been more than $30 million.

Feasibility is the measure of how beneficial or practical an information system will be to an organization; it should be measured continuously throughout the SDLC process.

During the planning phase, analysts investigate a proposed solution’s feasibility and determine how best to present the solution to management in order to obtain funding. The tool used for this purpose is a feasibility study, and it usually has five major dimensions, discussed in the following sections: economic, technical, operational, scheduling, and legal.

Economic Feasibility

Economic feasibility assesses a system’s costs and benefits. Simply put, if implementing the system results in a net gain of $250,000 but the system costs $500,000, the system is not economically feasible. To conduct an economic feasibility study, the systems analyst team must identify all costs and benefits—tangible and intangible—of the proposed system. The team must also be aware of opportunity costs associated with the information system. Opportunity costs measure what you would miss by not having a system or feature. For example, if your competitor has a Web site and you do not, what is the cost of not having a site, even if you do not really need one? What market share are you likely to lose if you do not have a Web site?

To assess economic feasibility, the team tallies tangible development and operating costs for the system and compares them with expected financial benefits of the system. Development costs include the following:

Hardware and software

Software leases or licenses

Computer time for programming, testing, and prototyping

Maintenance costs for monitoring equipment and software

Personnel costs—salaries for consultants, systems analysts, network specialists, programmers, data entry clerks, computer operators, secretaries, and technicians

Supplies and other equipment

Training employees who will be using the system

Operating costs for running the system are typically estimated, although some vendors and suppliers can supply costs. These costs can be fixed or variable (depending on rate of use). After itemizing these costs, the team creates a budget. Many budgets do not allow enough for development costs, especially technical expertise (programmers, designers, and managers), and for this reason, many information system projects go over budget.

An information system’s scope and complexity can change after the analysis or design phases, so the team should keep in mind that an information system project that is feasible at the outset could become unfeasible later. Integrating feasibility checkpoints into the SDLC process is a good idea to ensure the system’s success. Projects can always be canceled or revised at a feasibility checkpoint, if needed.

To complete the economic feasibility study, the team must identify benefits of the information system, both tangible and intangible. Tangible benefits can be quantified in terms of monthly or annual savings, such as the new system allowing an organization to operate with three employees rather than five or the new system resulting in increased profits. The real challenge is assessing intangible costs and benefits accurately; attaching a realistic monetary value to these factors can be difficult.

Intangible benefits are difficult to quantify in terms of dollar amounts, but if they are not at least identified, many information system projects cannot be justified. Examples of intangible benefits include improved employee morale, better customer satisfaction, more efficient use of human resources, increased flexibility in business operations, and improved communication. For example, you could quantify customer service as maintaining current total sales and increasing them by 10 percent to improve net profit. Other measures have been developed to assess intangibles, such as quantifying employee morale with rates of on-time arrival to work or working overtime. Customer satisfaction, though intangible, can be measured by using satisfaction surveys, and the Internet has made this method easier.

After collecting information on costs and benefits, the team can do a cost-effectiveness analysis. This analysis is based on the concept that a dollar today is worth more than a dollar one year from now. If the system does not produce enough return on the investment, the money can be better spent elsewhere. The most common analysis methods are payback, net present value (NPV), return on investment (ROI), and internal rate of return (IRR). The final result of this task is the cost-benefit analysis (CBA) report, used to sell the system to top management. This report can vary in format but should include the following sections: executive summary, introduction, scope and purpose, analysis method, recommendations, justifications, implementation plans, summary, and appendix items, which can include supporting documentation. Some examples of useful supporting documentation are organizational charts, workflow plans, floor plans, statistical information, project sequence diagrams, and timelines or milestone charts.

Technical Feasibility

Technical feasibility is concerned with the technology that will be used in the system. The team needs to assess whether the technology to support the new system is available or feasible to implement. For example, a full-featured voice-activated monitoring system is not technically feasible at this point. However, given the pace of technological development, many of these problems will eventually have solutions. Lack of technical feasibility can also stem from an organization lacking the expertise, time, or personnel to implement the new system. This problem is also called “a lack of organizational readiness.” In this case, the organization can take steps to address its shortcomings and then consider the new system. Extensive training is one solution to this problem.

The major question to answer when conducting operational feasibility is whether the information system is worth implementing.

Operational Feasibility

Operational feasibility is the measure of how well the proposed solution will work in the organization and how internal and external customers will react to it. The major question to answer is whether the information system is worth implementing. To assess operational feasibility, the team should address the following questions:

Is the system doing what it is supposed to do? For example, will the information system for ABC reduce orders for raw materials by tracking inventory more accurately?

Will the information system be used?

Will there be resistance from users?

Will top management support the information system?

Will the proposed information system benefit the organization?

Will the proposed information system affect customers (both internal and external) in a positive way?

Scheduling Feasibility

Scheduling feasibility is concerned with whether the new system can be completed on time. For example, an organization might need a wireless network immediately because of a disaster that destroyed the existing network. However, if the new system cannot be delivered in time, the loss of customers could force the organization out of business. In this case, the proposed system is not feasible from a schedule viewpoint. The problem of missing deadlines is common in the information systems field, but designers can often minimize this problem by using project management tools (discussed later in the chapter).

Legal Feasibility

Legal feasibility is concerned with legal issues; it typically addresses questions such as the following:

Will the system violate any legal issues in the country where it will be used?

Are there any political repercussions of using the system?

Is there any conflict between the proposed system and legal requirements? For example, does the system take the Information Privacy Act into account? Prototyping

Prototyping has been around for many years in physical science because building a small working model first is easier and less expensive than building the entire system. Prototypes can also be tested to detect potential problems and devise solutions.

Prototyping has gained popularity in designing information systems because needs can change quickly and lack of specifications for the system can be a problem. Typically, a small-scale version of the system is developed, but one that is large enough to illustrate the system’s benefits and allow users to offer feedback. Prototyping is also the fastest way to put an information system into operation. Prototypes are usually used for the following purposes:

Gathering system requirements—During the planning phase, designing a prototype and showing it to users is a good way to gather additional information and refine requirements for the proposed system.

Helping to determine system requirements—If users are not sure about the type of information system they want, a prototype can serve as a valuable tool for demonstrating the system’s functional capabilities, after which users can be asked for their reactions.

Determining a system’s technical feasibility—If a system is not technically feasible or appears to be unfeasible, a prototype can be used to show users that a particular task can be done. This type of prototype is called a proof-of-concept prototype.

Selling the proposed system to users and management—Prototypes are sometimes used to sell a proposed system to users and management by showing some of its features and demonstrating how beneficial it could be to the organization. This type of prototype is called a selling prototype.

Prototyping is usually done in four steps:

Define the initial requirements.

Develop the prototype.

Review and evaluate the prototype.

Revise the prototype.

Defining the initial requirements involves agreement between users and designers that prototyping is the most suitable approach for solving a problem. After agreeing on the approach, users and designers work together to gather information about the prototype’s components and how these components relate to one another. The team might decide on one of the following approaches for constructing the prototype: using an external vendor, using software packages or fourth-generation programming languages, or using high-level programming languages and developing the prototype from scratch.

Including users and top management in the construction phase is essential because some problems that crop up during construction can be solved only by users or top management. For example, top management typically must solve problems of financing a system, and lack of specifications is a problem better suited for users to solve. In addition, during this phase, users and top management can learn more about the problems the information system will solve, and the team of users and designers can learn a lot about decision making in the organization.

After completing the prototype, users begin using it and evaluating its performance. Depending on the outcome, one of the following decisions is made: revise the prototype, cancel the information system project, develop a new prototype, or build a complete system based on the prototype. Regardless of the decision, the prototype has provided useful information to the team of users and designers. At this point, the problem is better defined, and the system’s operations are understood more clearly.

Prototyping Development Tools

Numerous tools can be used for constructing a system prototype. Widely used tools include spreadsheet packages, such as Microsoft Excel, and database management packages, such as Microsoft Access, whereas Visual Basic is commonly used to code the logic required for processes. CASE tools and third- and fourth-generation programming languages can be used to quickly develop prototypes. Prototyping tools for user interface design include GUImagnets (www.guimagnets.com), Designer Vista (http://designervista.com), and GUI Design Studio (www.carettasoftware.com/guidesignstudio).

Advantages and Disadvantages of Prototyping

As mentioned, prototyping offers several advantages:

It provides a method for investigating an environment in which the problem is poorly defined and information is difficult to gather.

It reduces the need to train information system users because the users are involved in developing the system.

It reduces costs because building a model is less expensive than building the complete system. If users and top management decide the system should not be developed, the organization has not lost all the money that would have been spent on building a complete system.

It increases the system’s chance of success by encouraging users’ involvement.

It is easier to modify a prototype than a complete system.

It improves documentation because users and designers can walk through several versions of the system.

It improves communication among users, top management, and information systems personnel because seeing a concrete model often prompts potential users of the system to ask questions, express opinions, point out shortcomings and strengths, and so forth.

Even with all these advantages, prototyping has some disadvantages:

It might require more support and assistance from users and top management than they are willing to offer.

The prototype might not reflect the final system’s actual operation and, therefore, could be misleading.

Developing a prototype might lead analysts and designers to forego comprehensive testing and documentation. If the prototype works, the team might be convinced that the final system will work, too, and this assumption can be misleading.

Phase 4: Implementation

During the implementation phase, the solution is transferred from paper to action, and the team configures the system and procures components for it. A variety of tasks takes place in the implementation phase, including the following:

Acquiring new equipment

Hiring new employees

Training employees

Planning and designing the system’s physical layout

Coding

Testing

Designing security measures and safeguards

Creating a disaster recovery plan

Phase 5: Maintenance

During the maintenance phase, the information system is operating, enhancements and modifications to the system have been developed and tested, and hardware and software components have been added or replaced. The maintenance team assesses how the system is working and takes steps to keep the system up and running. As part of this phase, the team collects performance data and gathers information on whether the system is meeting its objectives by talking with users, customers, and other people affected by the new system. If the system’s objectives are not being met, the team must take corrective action. Creating a help desk to support users is another important task in this phase. With the ongoing nature of the SDLC approach, maintenance can lead to starting the cycle over at the planning phase if the team discovers the system is not working correctly.

Bidgoli, H. (2019) Management Information Systems (9th ed.) Cengage. https://www.cengage.com/

Chapter 10

Computer-Aided Systems Engineering

Systems analysts use computer-aided systems engineering (CASE) tools to automate parts of the application development process. These tools are particularly helpful for investigation and analysis in large-scale projects because they automate parts of the design phase. Analysts can use them to modify and update several design versions in an effort to choose the best version. CASE tools support the design phase by helping analysts do the following:

Keep models consistent with each other

Document models with explanations and annotations

Ensure that models are created according to specific rules

Create a single repository of all models related to a single system, which ensures consistency in analysis and design specifications

Track and manage changes to the design

Create multiple versions of the design

CASE tools are similar to computer-aided design (CAD) tools used by architects and engineers. Their capabilities vary, depending on the product, but generally include the following:

Graphics tools, such as data flow diagrams, to illustrate a system’s operation

Dictionary tools designed to record the system’s operation in detail

Prototyping tools for designing input and output formats, forms, and screens

Code generators to minimize or eliminate programming efforts

Project management tools to help control the system’s schedule and budget

Several CASE tools are available, including CA ERwin Process Modeler (http://erwin.com), Oracle Designer (www.oracle.com/technetwork/developer-tools/designer/overview/index-082236.html), and Visible System’s Visible Analyst (www.visible.com/Products/Analyst/vacorporate.htm). CASE tools usually include the following output:

Specifications documents

Documentation of the analysis, including models and explanations

Design specifications with related documentation

Logical and physical design documents based on the conceptual design

Code modules that can be incorporated into the system

Phase 2: Requirements Gathering and Analysis

In the requirements-gathering and analysis phase, analysts define the problem and generate alternatives for solving it. During this phase, the team attempts to understand the requirements for the system, analyzes these requirements to determine the main problem with the current system or processes, and looks for ways to solve problems by designing the new system.

The first step in this phase is gathering requirements. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach described earlier in the chapter. The intent is to find out the following:

What users do

How they do it

What problems they face in performing their jobs

How the new system would address these problems

What users expect from the system

What decisions are made

What data is needed to make decisions

Where data comes from

How data should be presented

What tools are needed to examine data for the decisions that users make

All this information can be recorded, and the team uses this information to determine what the new system should do (process analysis) and what data is needed for this process to be performed (data analysis).

The team uses the information collected during the requirements-gathering phase to understand the main problems, define the project’s scope—including what it should and should not do—and create a document called the “system specifications.” This document is then sent to all key users and task force members for approval. The creation of this document indicates the end of the analysis phase and the start of the design phase.

There are two major approaches to the analysis and design of information systems: the structured systems analysis and design (SSAD) approach and the object-oriented approach. (The object-oriented approach was introduced in Chapter 3 with the discussion of object-oriented databases.) The onset of the Web plus the release of Java, an object-oriented language, created the push for a different approach than SSAD. To understand the difference between the two approaches, first realize that any system has three parts: process, data, and user interface. Analyzing requirements in the analysis phase is done from the perspective of the process and data. The SSAD approach treats process and data independently and is a sequential approach that requires completing the analysis before beginning the design. The object-oriented approach combines process and data analysis, and the line between analysis and design is so thin that analysis and design seem to be a single phase instead of the two distinct phases shown in Exhibit 10.1.

These two approaches use different tools for creating analysis models. Table 10.1 shows some examples of tools used in the SSAD approach.

Table 10.1
Examples of Tools Used in SSAD Analysis Models

Modeling Tool

 

What Is Analyzed

 

What It Is Used For

 

Data flow diagram (DFD)

 

Process analysis and design

 

Helps break down a complex process into simpler, more manageable, and more understandable subprocesses; shows how data needed by each process flows between processes and what data is stored in the system; also helps define the system’s scope

 

Flowchart

 

Process analysis

 

Illustrates the logical steps in a process but does not show data elements and associations; can supplement a DFD and help analysts understand and document how a process works

 

Context diagram

 

Process analysis and design

 

Shows a process at a more general level and is helpful for showing top management and the task force how a process works

 

Conceptual data model (such as an entity relationship model)

 

Data analysis

 

Helps analysts understand the data requirements a system must meet by defining data elements and showing the associations between them

Exhibit 10.2 shows an example of a data flow diagram for ABC’s inventory management system, and Exhibit 10.3 shows a context diagram.

Exhibit 10.2
Data Flow Diagram for ABC’s Inventory Management System
Exhibit 10.3
Context Diagram for ABC’s Inventory Management System

Notice in Exhibit 10.2 that processes are indicated with a circle. Anything that interacts with the system but is not part of it is considered an “external entity” and is shown as a blue rectangle. Data stores (databases, file systems, even file cabinets) are shown as gray rectangles.

In Exhibit 10.3, the DFD has been simplified into a context diagram, also called a “Level 0 diagram.” Each process in this context diagram could be broken down into a separate diagram called “Level 1.”

Both modeling tools show data flows between processes and external entities, and the DFD also shows data flows between processes and data stores. These data flows are general, so they do not show specific data elements. For example, “Purchase order” is shown in Exhibit 10.2 instead of all the pieces of data making up a purchase order, such as order number, order date, item number, and item quantity.

The models created during the analysis phase constitute the design specifications. After confirming these specifications with users, analysts start designing the system.

Phase 2: Requirements Gathering and Analysis

In the requirements-gathering and analysis phase, analysts define the problem and generate alternatives for solving it. During this phase, the team attempts to understand the requirements for the system, analyzes these requirements to determine the main problem with the current system or processes, and looks for ways to solve problems by designing the new system.

The first step in this phase is gathering requirements. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach described earlier in the chapter. The intent is to find out the following:

What users do

How they do it

What problems they face in performing their jobs

How the new system would address these problems

What users expect from the system

What decisions are made

What data is needed to make decisions

Where data comes from

How data should be presented

What tools are needed to examine data for the decisions that users make

All this information can be recorded, and the team uses this information to determine what the new system should do (process analysis) and what data is needed for this process to be performed (data analysis).

The team uses the information collected during the requirements-gathering phase to understand the main problems, define the project’s scope—including what it should and should not do—and create a document called the “system specifications.” This document is then sent to all key users and task force members for approval. The creation of this document indicates the end of the analysis phase and the start of the design phase.

There are two major approaches to the analysis and design of information systems: the structured systems analysis and design (SSAD) approach and the object-oriented approach. (The object-oriented approach was introduced in Chapter 3 with the discussion of object-oriented databases.) The onset of the Web plus the release of Java, an object-oriented language, created the push for a different approach than SSAD. To understand the difference between the two approaches, first realize that any system has three parts: process, data, and user interface. Analyzing requirements in the analysis phase is done from the perspective of the process and data. The SSAD approach treats process and data independently and is a sequential approach that requires completing the analysis before beginning the design. The object-oriented approach combines process and data analysis, and the line between analysis and design is so thin that analysis and design seem to be a single phase instead of the two distinct phases shown in Exhibit 10.1.

These two approaches use different tools for creating analysis models. Table 10.1 shows some examples of tools used in the SSAD approach.

Table 10.1
Examples of Tools Used in SSAD Analysis Models

Modeling Tool

 

What Is Analyzed

 

What It Is Used For

 

Data flow diagram (DFD)

 

Process analysis and design

 

Helps break down a complex process into simpler, more manageable, and more understandable subprocesses; shows how data needed by each process flows between processes and what data is stored in the system; also helps define the system’s scope

 

Flowchart

 

Process analysis

 

Illustrates the logical steps in a process but does not show data elements and associations; can supplement a DFD and help analysts understand and document how a process works

 

Context diagram

 

Process analysis and design

 

Shows a process at a more general level and is helpful for showing top management and the task force how a process works

 

Conceptual data model (such as an entity relationship model)

 

Data analysis

 

Helps analysts understand the data requirements a system must meet by defining data elements and showing the associations between them

Exhibit 10.2 shows an example of a data flow diagram for ABC’s inventory management system, and Exhibit 10.3 shows a context diagram.

Exhibit 10.2
Data Flow Diagram for ABC’s Inventory Management System
Exhibit 10.3
Context Diagram for ABC’s Inventory Management System

Notice in Exhibit 10.2 that processes are indicated with a circle. Anything that interacts with the system but is not part of it is considered an “external entity” and is shown as a blue rectangle. Data stores (databases, file systems, even file cabinets) are shown as gray rectangles.

In Exhibit 10.3, the DFD has been simplified into a context diagram, also called a “Level 0 diagram.” Each process in this context diagram could be broken down into a separate diagram called “Level 1.”

Both modeling tools show data flows between processes and external entities, and the DFD also shows data flows between processes and data stores. These data flows are general, so they do not show specific data elements. For example, “Purchase order” is shown in Exhibit 10.2 instead of all the pieces of data making up a purchase order, such as order number, order date, item number, and item quantity.

The models created during the analysis phase constitute the design specifications. After confirming these specifications with users, analysts start designing the system.

Phase 2: Requirements Gathering and Analysis

In the requirements-gathering and analysis phase, analysts define the problem and generate alternatives for solving it. During this phase, the team attempts to understand the requirements for the system, analyzes these requirements to determine the main problem with the current system or processes, and looks for ways to solve problems by designing the new system.

The first step in this phase is gathering requirements. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach described earlier in the chapter. The intent is to find out the following:

What users do

How they do it

What problems they face in performing their jobs

How the new system would address these problems

What users expect from the system

What decisions are made

What data is needed to make decisions

Where data comes from

How data should be presented

What tools are needed to examine data for the decisions that users make

All this information can be recorded, and the team uses this information to determine what the new system should do (process analysis) and what data is needed for this process to be performed (data analysis).

The team uses the information collected during the requirements-gathering phase to understand the main problems, define the project’s scope—including what it should and should not do—and create a document called the “system specifications.” This document is then sent to all key users and task force members for approval. The creation of this document indicates the end of the analysis phase and the start of the design phase.

There are two major approaches to the analysis and design of information systems: the structured systems analysis and design (SSAD) approach and the object-oriented approach. (The object-oriented approach was introduced in Chapter 3 with the discussion of object-oriented databases.) The onset of the Web plus the release of Java, an object-oriented language, created the push for a different approach than SSAD. To understand the difference between the two approaches, first realize that any system has three parts: process, data, and user interface. Analyzing requirements in the analysis phase is done from the perspective of the process and data. The SSAD approach treats process and data independently and is a sequential approach that requires completing the analysis before beginning the design. The object-oriented approach combines process and data analysis, and the line between analysis and design is so thin that analysis and design seem to be a single phase instead of the two distinct phases shown in Exhibit 10.1.

These two approaches use different tools for creating analysis models. Table 10.1 shows some examples of tools used in the SSAD approach.

Table 10.1
Examples of Tools Used in SSAD Analysis Models

Modeling Tool

 

What Is Analyzed

 

What It Is Used For

 

Data flow diagram (DFD)

 

Process analysis and design

 

Helps break down a complex process into simpler, more manageable, and more understandable subprocesses; shows how data needed by each process flows between processes and what data is stored in the system; also helps define the system’s scope

 

Flowchart

 

Process analysis

 

Illustrates the logical steps in a process but does not show data elements and associations; can supplement a DFD and help analysts understand and document how a process works

 

Context diagram

 

Process analysis and design

 

Shows a process at a more general level and is helpful for showing top management and the task force how a process works

 

Conceptual data model (such as an entity relationship model)

 

Data analysis

 

Helps analysts understand the data requirements a system must meet by defining data elements and showing the associations between them

Exhibit 10.2 shows an example of a data flow diagram for ABC’s inventory management system, and Exhibit 10.3 shows a context diagram.

Exhibit 10.2
Data Flow Diagram for ABC’s Inventory Management System
Exhibit 10.3
Context Diagram for ABC’s Inventory Management System

Notice in Exhibit 10.2 that processes are indicated with a circle. Anything that interacts with the system but is not part of it is considered an “external entity” and is shown as a blue rectangle. Data stores (databases, file systems, even file cabinets) are shown as gray rectangles.

In Exhibit 10.3, the DFD has been simplified into a context diagram, also called a “Level 0 diagram.” Each process in this context diagram could be broken down into a separate diagram called “Level 1.”

Both modeling tools show data flows between processes and external entities, and the DFD also shows data flows between processes and data stores. These data flows are general, so they do not show specific data elements. For example, “Purchase order” is shown in Exhibit 10.2 instead of all the pieces of data making up a purchase order, such as order number, order date, item number, and item quantity.

The models created during the analysis phase constitute the design specifications. After confirming these specifications with users, analysts start designing the system.

 

Phase 2: Requirements Gathering and Analysis

In the requirements-gathering and analysis phase, analysts define the problem and generate alternatives for solving it. During this phase, the team attempts to understand the requirements for the system, analyzes these requirements to determine the main problem with the current system or processes, and looks for ways to solve problems by designing the new system.

The first step in this phase is gathering requirements. Several techniques are available for this step, including interviews, surveys, observations, and the JAD approach described earlier in the chapter. The intent is to find out the following:

What users do

How they do it

What problems they face in performing their jobs

How the new system would address these problems

What users expect from the system

What decisions are made

What data is needed to make decisions

Where data comes from

How data should be presented

What tools are needed to examine data for the decisions that users make

All this information can be recorded, and the team uses this information to determine what the new system should do (process analysis) and what data is needed for this process to be performed (data analysis).

The team uses the information collected during the requirements-gathering phase to understand the main problems, define the project’s scope—including what it should and should not do—and create a document called the “system specifications.” This document is then sent to all key users and task force members for approval. The creation of this document indicates the end of the analysis phase and the start of the design phase.

There are two major approaches to the analysis and design of information systems: the structured systems analysis and design (SSAD) approach and the object-oriented approach. (The object-oriented approach was introduced in Chapter 3 with the discussion of object-oriented databases.) The onset of the Web plus the release of Java, an object-oriented language, created the push for a different approach than SSAD. To understand the difference between the two approaches, first realize that any system has three parts: process, data, and user interface. Analyzing requirements in the analysis phase is done from the perspective of the process and data. The SSAD approach treats process and data independently and is a sequential approach that requires completing the analysis before beginning the design. The object-oriented approach combines process and data analysis, and the line between analysis and design is so thin that analysis and design seem to be a single phase instead of the two distinct phases shown in Exhibit 10.1.

These two approaches use different tools for creating analysis models. Table 10.1 shows some examples of tools used in the SSAD approach.

Table 10.1
Examples of Tools Used in SSAD Analysis Models

Modeling Tool

 

What Is Analyzed

 

What It Is Used For

 

Data flow diagram (DFD)

 

Process analysis and design

 

Helps break down a complex process into simpler, more manageable, and more understandable subprocesses; shows how data needed by each process flows between processes and what data is stored in the system; also helps define the system’s scope

 

Flowchart

 

Process analysis

 

Illustrates the logical steps in a process but does not show data elements and associations; can supplement a DFD and help analysts understand and document how a process works

 

Context diagram

 

Process analysis and design

 

Shows a process at a more general level and is helpful for showing top management and the task force how a process works

 

Conceptual data model (such as an entity relationship model)

 

Data analysis

 

Helps analysts understand the data requirements a system must meet by defining data elements and showing the associations between them

Exhibit 10.2 shows an example of a data flow diagram for ABC’s inventory management system, and Exhibit 10.3 shows a context diagram.

Exhibit 10.2
Data Flow Diagram for ABC’s Inventory Management System
Exhibit 10.3
Context Diagram for ABC’s Inventory Management System

Notice in Exhibit 10.2 that processes are indicated with a circle. Anything that interacts with the system but is not part of it is considered an “external entity” and is shown as a blue rectangle. Data stores (databases, file systems, even file cabinets) are shown as gray rectangles.

In Exhibit 10.3, the DFD has been simplified into a context diagram, also called a “Level 0 diagram.” Each process in this context diagram could be broken down into a separate diagram called “Level 1.”

Both modeling tools show data flows between processes and external entities, and the DFD also shows data flows between processes and data stores. These data flows are general, so they do not show specific data elements. For example, “Purchase order” is shown in Exhibit 10.2 instead of all the pieces of data making up a purchase order, such as order number, order date, item number, and item quantity.

The models created during the analysis phase constitute the design specifications. After confirming these specifications with users, analysts start designing th

The Homework College
Calculate your paper price
Pages (550 words)
Approximate price: -

Why Work with Us

Top Quality and Well-Researched Papers

We ensure that our writers and editors work within the work guidelines and follow all paper instructions to the letter. When placing an order, you choose the academic field and expert level (high school, college, university, or professional). Our team then assigns your paper to a writer with a respective qualification or degree to ensure that you receive quality work.

Professional and Experienced Academic Writers

We employ professional writers with more than two years of experience in academic and business writing. Most of our writers and editors are native English speakers to ensure quality and professional work. We are confident that our team of professional writers can handle all types of business and academic writing work.

Free Unlimited Revisions

We provide a free revision service for all orders. If you feel that our writers missed something, you can request a revision of your paper at no additional cost. When we deliver your work, you have seven days to go through it and request a revision or modification if you are not satisfied. You can also contact our support team directly for any clarifications and queries on revision.

Prompt Delivery and 100% Money-Back-Guarantee

We ensure that all papers are delivered on time. In case we need more time to master your paper requirements and deliver quality work, we may contact you and discuss a deadline extension. If a deadline extension is not feasible, depending on the work and submission deadlines, we guarantee a 100% refund.

Original & Confidential

To ensure that we deliver plagiarism-free work, we use various writing and plagiarism checking tools. Our professional editors' team carefully goes through all work and references used in papers to ensure proper referencing and that original work has been done. We also guarantee confidentiality in all the services that we provide.

24/7 Customer Support

Our support team is available round the clock for any customer queries and communication. We guarantee 24/7 customer support and assistance. Feel free to contact us at any time of day for questions and follow-ups.

Try it now!

Calculate the price of your order

Total price:
$0.00

How it works?

Follow these simple steps to get your paper done

Place your order

Fill in the order form and provide all details of your assignment.

Proceed with the payment

Choose the payment system that suits you most.

Receive the final file

Once your paper is ready, we will email it to you.

Our Services

You do not have to spend sleepless nights worrying about your paper. We got you covered. We offer all kinds of writing services.

Essays

Essay Writing Service

Regardless of the type of academic paper you need and its urgency, we have writers on call ready to work on your paper. Feel free to choose the field, educational level, and type of paper you want, and we will deliver it at an affordable price. We are here for all your academic and business paper needs. With our round the clock service, we guarantee that you will receive your work on time.

Admissions

Admission Essays & Business Writing Help

Admission essays are written by students wishing to join a college, graduate school or university, as applications for enrollment. We guarantee quality admission essays and business papers with our professional writing and customer care support services.

Reviews

Editing Support

We have experienced academic writers and editors who are on standby to make all the necessary changed to your paper at your request. We ensure that your paper is polished and appropriately formatted (APA, Harvard, Chicago/Turabian, MLA formats) before it is delivered.

Reviews

Revision Support

We provide revision support, where you can request a revision of a delivered paper if you feel that it can be improved or repolished. Your paper is checked by an experienced writer or editor for revamping and improvement upon a revision request. Revision service is free, and you can use it as many times as you wish until you are satisfied with your paper.