System Analysis & Design Discussion

Module 1: Systems Planning

This module addresses the first phase in the systems development life cycle (SDLC). You will learn about significant systems development techniques, methodologies, and tools. You will also learn about the classic SDLC. Finally, you will learn how to evaluate a systems request and then perform a feasibility study that will result in a preliminary investigation report.

After completing this module, you should be able to:

· demonstrate an understanding of the classical systems development life cycle

· describe several alternative development approaches

· describe the contents of a functional specification document

· produce a preliminary investigation report

Systems are created for the primary purpose of solving problem. If there is no problem, there is no need to develop a system. Developing an application in response to a specific request involves an awareness of a system, systems thinking, and the problem domain.

Definition of a System

A system is a collection of definable components that influence each other is such a way that they function as a single, goal-oriented entity. There are three major components in every system—input, processing, and output.

Systems Thinking

The definition of systems thinking varies depending on with whom you are speaking, e.g., a psychologist, an engineer, a manager, a programmer, and so on. For our purposes, we will use the terminology provided by Barry Richmond at High Performance Systems. According to Richmond (1991), systems thinking "in practice, is a continuum of activities that range from conceptual to the technical." In essence, a system begins as an inner vision of how the input, process, and output fit together and then moves on until the system can be explicitly defined in a procedure manual.

Establishing the Domain

Every system has a boundary to the surrounding "environment" that creates a working domain. The problem domain, as it is often referred to, includes all relevant data and excludes all irrelevant data. A good application should provide a comprehensive solution that is within the boundary and should exclude everything else.

Capacity planning is a type of analysis important to determining the systems requirements for a new software application. The actual requirements will vary from application to application, but the critical components of any information system—hardware to be used, software parameters, user specifications, and so on—must be identified and addressed.

Capacity Planning Defined

The definition of capacity planning varies depending on the needs of a particular application. For example,

· data communications—involves the amount of bandwidth necessary to support an application

· underutilized resources—involves consolidating systems and servers while still meeting business objectives

· storage management—involves the use of direct attached storage (DAS), storage area networks (SAN), and network-attached storage (NAS)

· systems development—involves the hardware and software configuration that will be required given a particular user load

· client-server relationship—involves the balance between production and customer demands

· customer service—involves having the right quantity of support personnel at the right time to match the load of customers

Short-Term

Short-term capacity planning includes the day-to-day adjustments that must be made to ensure an optimum balance to the system. The staff must have the expertise, discretion, and flexibility to resolve unforeseen contingencies.

Medium-Term

Medium-term capacity planning involves forecasting the potential demands on various components of the system (e.g., requirements planning, machine scheduling, staffing fluctuations, and materials needed).

Long-Term

Long-term capacity planning is geared to the strategies and policies of the organization and will require months to years. Examples include: production sites, warehouses, computer upgrades, and investments in new facilities.

In the late 1940s, statistical sampling and quality control procedures in the manufacturing arena were still considered confidential by the U.S. government. During the 1950s and 1960s, most of the management science improvements were provided as discrete, custom applications made available to one or only a few locations. During the 1970s, however, the environment began to change—everyone became interested in the "systems approach" to problem solving. In project management it is the Project Management Body of Knowledge (PMBOK) standards; in education it is the Instructional Systems Design (ISD) methodology; and in software applications it is the Systems Analysis and Design (SAD) paradigm. The basic framework of all of these systems approaches can be defined as a five-phase process.

Phase 1: Systems Planning

The first phase of the SDLC involves an initial study of the system about which the request is directed. The purpose is to get a clear picture of the physical system of interest. An accurate determination of the existing system involves two related procedures: a preliminary survey of "what is?" and identifying the scope of the corrective actions needed to create the "what will be?"

The second component of the initial study is a more detailed and in-depth study in which the user's requirements and the limitations of the present study are specified. Once the significant findings of the initial study have been discovered, a feasibility study is performed. The main goal of the feasibility study is not to solve the problem but to achieve the scope of the new system.

Phase 2: Systems Analysis

Assuming that the new system is feasible, it will be developed. It is at this point that the system will be analyzed. Systems analysis involves the comprehensive and detailed study of the current business processes that will lead to an understanding of the specifications for the new system. This will include the operations currently performed by the system and their relationships to each other.

Phase 3: Systems Design

Based on the results of the detailed systems analysis, the new system must be designed. This systems design phase is usually considered to be critical phase in the development of a system. If the replacement system is not designed to actually solve the user's problem or does not resolve problems in an effective and efficient manner, it is not worth the time and effort required to get it on line. From a software application standpoint, the design phase includes writing new code and testing that code. Part of the testing requirements involves getting the approval of the user who made the initial request.

Phase 4: Systems Implementation

After the user has accepted the new system, the implementation phase begins. This is the point where the theory is converted into practice. The programs developed will be loaded onto the user's computer. Then the training of the users begins. In the definition of a system it was pointed out that there are three major components in every system—input, processing, and output. Accordingly, the training efforts must include the following:

· how to enter the data

· how to process the data (processing details)

· how to take out the reports

Phase 5: Systems Operation and Report

Systems operation is an ongoing process that requires continuous maintenance in order to keep the system functioning as designed. It is during this maintenance phase, as it is often called, that the errors are detected, corrected, and documented. If a major change to the system is warranted, either because of new procedures or obsolescent ones, it may be necessary to create a new application. If such a drastic action were required, the SDLC would be completed.

SDLC Variants

There are many variants to the traditional SDLC, such as the scientific method and the project life cycle. Some of these variants are shown in the figure below.

Figure 1.1 Variants of the Traditional SDLC

Modeling

At its simplest, a model is an abstract representation of an existing problem situation. It is commonly presented in the form of a chart, a graph, or some form of mathematical relationship(s). In its most complete form, a model is a functional relationship including variables, parameters, and equations.

Prototyping

A prototype is an early example of what a final product might look and act like. Maner (1997a) defines a prototype as "an easily modified and extensible model (representation, simulation, or demonstration) of a planned software system, likely including its interface and input/output functionality."

CASE

CASE is an acronym for two seemingly separate, but equivalent, types of engineering. The first is computer-aided systems engineering and the second is computer-aided software engineering. Despite the apparent confusion, both versions of CASE mean the same thing—the design, development, and use of computer software. According to the Software Engineering Institute (2001), a CASE tool is "a computer-based product aimed at supporting one or more software engineering activities within a software development process."

Joint Application Development

Joint Application Development (JAD) is a technique developed at IBM in the late 1970s. The Information Systems Branch of the Human Resource Services at The University of Texas at Austin has produced a definition, purpose, philosophy, and scope of JAD (2000):

"JAD Definition: Joint Application Development (JAD) is a management process that helps IS work effectively with users to develop information technology solutions that really work.

"JAD Purpose: to define the project, design a solution, and monitor the project until it reaches completion.

"JAD Philosophy: The JAD process is based on four simple ideas:

1. People who actually do a job have the best understanding of that job.

2. People who are trained in information technology have the best understanding of the possibilities of that technology.

3. Information systems and business processes rarely exist in isolation—they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.

4. The best information systems are designed when all of these groups work together on a project as equal partners.

"JAD Scope: The JAD should cover the complete development life cycle of a system. The JAD is usually a 3 to 6 month well-defined project. For large-scale projects, it is recommended that the project be approached incrementally, and that separate JAD's be used for each increment."

Rapid Application Development

Rapid Application Development (RAD) is a system built by programmers for use by programmers. Essentially, RAD tools allow programmers to build graphical user interfaces that would normally require considerable development and expense. Maner (1997b) has provided a workable definition, principles, and target projects for RAD:

"RAD Definition: a software development process that allows usable systems to be built in as little as 60-90 days, often with some compromises.

"Principles Behind the RAD Definition:

· In certain situations, a usable 80% solution can be produced in 20% of the time that would have been required to produce a total solution.

· In certain situations, the business requirement for a system can be fully satisfied even if some of its operational requirements are not satisfied.

· In certain situations, the acceptability of a system can be assessed against the agreed minimum useful set of requirements rather than all requirements.

"Problems Addressed by RAD:

· With conventional methods, there is a long delay before the customer gets to see any results.

· With conventional methods, development can take so long that the customer's business has fundamentally changed by the time the system is ready for use.

· With conventional methods, there is nothing until 100% of the process is finished, then 100% of the software is delivered."

The sole purpose for a new system is the resolution of a problem in the old system.

A Problem versus an Opportunity

The requirement for a new system does not necessarily mean that something undesirable, referred to as a problem, must be replaced. Often the new system is required in order to bring something desirable, referred to as an opportunity, into reality.

Extracting a Problem Statement

Developing a new system, regardless of how simple or complex its structure, is undertaken for only one purpose—to provide a solution to a problem. However, establishing the most elegant and technologically sophisticated solution is absolutely worthless if the wrong problem has been addressed. Far too often the "obvious" problem is nothing more than a symptom of the "true" problem. For example, suppose that the obvious problem is that the employee turnover rate is too high. Turnover rate is never a problem, it is only an indicator of some true problem such as poor employee morale, increased demand for certain skills, higher compensation paid by the competition, or better employee benefits elsewhere. Each true problem will require a different solution.

· The first, and arguably most important, step in solving a problem is awareness that a problem actually exists. If one does exist, you must carefully identify the boundaries of the problem. This problem domain will set the criteria for what information is related to the problem and what information is irrelevant. It is during this step that we attempt to find out what we currently know. In our example, the problem domain includes all the factors that can cause employee turnover.

· Identifying the problem domain requires a comprehensive search of existing factual knowledge. That is:

· What do we already know about the problem domain?

· What do former employees give as the reasons why they are leaving the company?

· Are there possible reasons beyond what was stated in their exit interviews?

· What are the lessons learned, if any, from previous efforts to reduce employee turnover?

· Expand your search to include factual knowledge that may be available outside of the company.

· Why do individuals leave other companies in order to work for this company?

· Are there any skills-specific studies on employee turnover (e.g., studies on accountants, programmers, engineers, nurses, etc.)?

· To further reveal existing factual knowledge, develop a list of questions based on knowledge cues that will help to establish mastery of the subject matter. Common knowledge cues include terms such as: list, define, describe, label, identify, recall, collect, examine, tabulate, recognize, who, what, when, where, and how.

· Existing knowledge also includes conventions, jargon, and abstractions that may be implied but not expressly stated. Using techniques such as free association and brainstorming can specify existing intuitive knowledge. Intuitive knowledge is often nonverbal: that is, it is expressed in the form of symbols, images, and metaphors. Intuitive knowledge includes those hunches we often describe using the phantom senses, such as: "I can see what is really going on here," "I smell trouble brewing," "I feel that something is wrong here," and "We're so close, I can taste the victory."

Specifying the Problem Domain

The problem domain should include an exhaustive set of knowledge—both factual and intuitive. Although the completed problem domain is necessary, it is not sufficient for solving problem. The knowledge contained in the problem domain must go through several transformations before you can begin planning a course of action for resolution.

· The first transformation will be to understand what you already know. Understanding, or comprehension as it is often called, can be defined as the ability to grasp the meaning of the information contained in the problem domain. Thus, understanding occurs when the knowledge elements provided in the problem domain are treated by one of five methods: estimation, manipulation, translation, interpretation, or extrapolation.

· Estimation is the judging of something with respect to its worth or significance. The estimation does not need to be precise, only approximate. Estimation is most often used in the absence of historical data. For example, I may not know the exact price of new computer system but I can estimate that it will be about $3,000, which will be closer to the exact price than half that amount or twice that amount.

· Manipulation occurs when information can be more meaningful if put into another abstract representation. For example, of the 241 employees who have left this company to go elsewhere, 77 stated that they felt that their superiors did not appreciate their work. Another way to look at this information is that there is a one in three chance that the next employee who quits will do so because he or she feels unappreciated.

· Translation is the act of converting the meaning of a knowledge element into a different, but equivalent, meaning. Translation can occur by paraphrasing the information, explaining it in more comprehensible terms. For example, "her locution implied a pyrrhonist disposition regarding incipient remuneration" can be paraphrased to "she doubts that she will get a pay raise."

· Interpretation is an explanation in light of someone's beliefs or a particular set of circumstances. While a translation attempts to provide equivalence in meaning, an interpretation is a subjectively filtered restatement. For example, there is an old maxim that says, "One man's trash is another man's treasure."

· Extrapolation is a prediction of some future outcome, given past experience or known data. For example, over the past two decades nurses have left their profession after about fifteen years of working; therefore, we can expect this trend to continue during the foreseeable future.

Once the problem statement has been extracted from the existing system study, there will be a need to determine whether the creation of a workable solution can actually be attained, given the constraints and limitations that that are in control.

Definition of Feasibility

In a very fundamental sense, feasibility is a subject judgment about the likelihood of something actually occurring. For example, the feasibility of becoming a millionaire by the end of this year is remote if you are working at a job that pays the minimum wage. However, the feasibility of becoming the cause of an accident is quite high if you drink and drive every day.

Feasibility and Related Reports

Once a problem has been identified, there is a need for feasibility and technical reports. Depending on the findings of these reports, a plan of action will be developed. When the plan has been accepted, there will be a need for progress reports at periodic intervals and a formal report at the end of the effort. Before spending time and effort on the development of a new system, it is important to make sure that the effort can, in fact, be done with the resources that will be available and that there can be an acceptable profit margin once the new system has been implemented. It is foolish to enter the systems analysis phase of the SDLC if it doesn't make good business sense.

The report to be prepared is one that provides a studied opinion of the problem. There are three closely related reports that can be used for the studied opinion: feasibility, recommendation, and evaluation.

· The feasibility report studies a problem situation and an approach for providing a viable solution. It provides the data and reasoning behind the determination of whether the solution is technologically possible and whether it is practical from a business perspective. The outcome of a feasibility report is yes, no, or maybe. The feasibility report answers the question, "Should we implement Project X?"

· A recommendation report provides a statement of the problem, a selection of possible solutions, and a recommendation of one of those possibilities. The recommendation report answers the question, "Which option should we choose?"

· An evaluation report provides an opinion or judgment rather than a yes-no-maybe answer or a recommendation. It provides a studied opinion on the value or worth of something. An evaluation report compares something of value to a set of criteria and determines how well it meets those requirements. Therefore, the evaluation report answers the question, "Will the proposed solution resolve the problem?"

The structure of this closely related group of reports is common for each. The structural principle fundamental to these reports is that you provide your recommendation, choice, or judgment, as well as the data and the conclusions that support it. The elements of this group of reports include:

· introduction

· technical background

· background on the situation

· requirements and criteria

· discussion of the options

· category-by-category comparisons

· conclusions

· recommendation or final opinion

Thus, the traditional feasibility report starts with background and criteria, then moves to comparisons, and ends with conclusions and recommendations.

Executive Report

An alternative to the traditional feasibility report is to move the conclusions and recommendations to the front of the report and then provide the background, criteria, and comparisons as appendixes. This so-called executive report allows the busy decision-maker to see the most important information right away, and turn to the detailed discussion only if there are questions.

Since the new system has never existed before, there will be no blueprint or road map to help—you must create them as you go. All that will be available is a best guess about what "might be" when the new system is completed. The best guess is arrived at after considering all the information given in a problem domain. The three most important estimates are time, cost, and outcome.

Time Required

Estimating the time required to complete a task or set of tasks that you have never approached before can be rather intimidating. Checking the time it has taken others to do similar tasks can be beneficial. But if this is truly a novel task it may be necessary to rely on approximations. For example, will the task take one hour or one day? One day or one week? One week or one month? And so on. During the planning phase, you should overestimate rather than underestimate the time required—the estimates can be fine-tuned as you progress through the SDLC.

Costs Anticipated

The cost of creating a new system can be accomplished in one of two ways. The bottom-up approach requires the approximate costing of each task and then accumulating these costs until the total cost for the entire effort is accomplished. The alternative is the top-down approach that is used when a set budget is provided and you must complete the entire effort while staying within the confines of the budgeted amount.

Outcome Desired

An estimate of the outcome desired has to be a workable solution to the original problem. If some other outcome results, the entire effort is a waste of time and money.