Chapter 15

Development Life Cycle And Systems Analysis

15.1 Quality Information Systems: Vital to Total Quality Management
Heightened global competition has made it imperative for organizations to deliver products - goods and services - of
consistently high quality. The principles of total quality management (TQM) recognize that consistent product
quality results from designing and executing business processes so as to remove error and waste.
Product quality is the result of :
a. Customer focus
b. Introduction and continuous improvement of business processes and product-development processes that reduce
variations
c. Creation of a company-wide quality culture through motivation and training of all its members
d. Continuous measurement and analysis of the accomplished results.
Quality information systems are vital to total quality management, because:
1. Business processes of the firm depend on information systems and, therefore, their quality depends to a large
degree on IS quality
2. Information systems enable most projects of business process design. This IS enabled streamlining of processes
gives fewer opportunities for error, thus leading to higher quality of the processes' outputs.
3. Information systems are a necessary component of the feedback loop in managing an enterprise. IS are necessary
to continually gauge any deviations from the expected norms in the firm's performance and thus help reduce
variance in performance.
International Standards Organization (ISO) 9000 - many companies, particularly in the manufacturing sectors,
comply with the ISO 9000 group of quality standards. Such compliance is mandatory for those selling any of a broad
range of products to the countries of the European Union. Some other countries also require this certification. The
standards aim to ensure quality of products by certifying quality assurance during business processes, such as
product design, manufacturing, delivery, and service support. Extensive quality-oriented information processing is a
prerequisite for a certification of compliance.
Software Quality
There are many attributes of software quality. These include:

1. Effectiveness
2 Usability
3. Efficiency
4. Reliability
5. Maintainability
6. Understandability
7. Modifiability
8. Testability
Effectiveness Refers to the satisfaction of the user and organizational requirements as established during an analysis
of these requirements, possibly using prototyping.
Usability The ease with which the intended users can use the system, depend on the proper user-system interface.
Efficient Efficient operation is reflected mainly in how economically hardware resources are used to satisfy the
given effectiveness requirements
Reliability Refers to the probability that the information system will operate correctly; that is, according to
specifications over a period of time. It may also be defined as the mean time between failures. Software reliability is
rooted in its freedom from defects. If a system must run on different hardware or systems software platforms,
portability should be included as a desired attribute.
Maintainability Refers to ease of understanding, modifying, and testing.
Understandability Is achieved by readable and well-commented system code and by documentation, which includes
the requirements specifications, system documentation, user manuals, and, sometimes special maintenance
documentation.
Modifiability Means that it is relatively easy to identify and change any part of the system that requires maintenance
without affecting its other parts.
Testability Is the ease with which we can demonstrate that a modification resulted in a quality system.
Applying Total Quality Management to Information Systems
The following are the principal aspects of TQM - oriented quality assurance for information systems:

1. Customer focus is achieved by involving end users in the IS development process, particularly during its early
stages when the requirements for the system are being defined. Systems prototyping and joint application
development (JAD) are the principal techniques applied to this end.
Joint Application Development (JAD) is an organizational technique for conducting meetings between the
prospective users of an information system and its developers.
2. The life-cycle oriented systems development, with the inclusion of prototyping, is a process that lends itself to
control, measurement, and continuous improvement. Support with CASE tools helps to ensure product quality.
3. Software development and maintenance teams are the primary human element in ensuring software quality.
4. The quality measurement program can assist in consistent striving for higher quality levels. Such a program rests
on the foundation of software metrics. Software matrices include techniques for measuring the attributes of software
and techniques for measuring the attributes of software development process.
15.2 Stages of the Systems Development Life Cycle [Figure 15.3]
The systems development life cycle (SDLC) gives organizations a means of controlling a large development project
by dividing it into manageable stages with well-defined outputs. SDLC consumes a significant amount of resources
itself - it takes time and money to manage projects in such an elaborate fashion.
Characteristics of the SDLC:
1. Every stage is defined in terms of the activities and responsibilities of the development team members.
2. Each stage terminates in a milestone defined in terms of the subproducts to be delivered, such as system
requirements specifications or coded and tested software modules.
3. Stress to students that developers often need to rework the deliverables produced in earlier stages in the light of
the experience they gain as the development effort progresses and to accommodate legitimate user requests for
change.
4. The effort expended on developing an information system is generally surpassed by the efforts needed for the
system's maintenance, which may cost over time twice as much as the development. Many organizations spend 60 to
70 percent of their IS budgets on systems maintenance.
5. Producing extensive system documentation during the development is necessary to support maintenance. It is
desirable that the documentation necessary for system operation and maintenance be produced as the by-product of
the development process.
Stages of the SDLC and their deliverables
Feasibility Study - recommendation to proceed and system proposal or

- recommendation to abandon
Requirements analysis - requirements specifications
Logical design - conceptual design or programs and databases
Physical design - detailed design of systems modules and databases
- specification of system hardware and software
Coding and testing - accepted system with complete documentation
Conversion - installed operational system
Postimplementation review - recommendation for enhancement of the system and of the
development method - recommendation for organizational adjustment
15.3 Systems Analysis
The task of systems analysis is to establish in detail what the proposed system will do (as opposed to how this will
be accomplished technologically).
Characteristics of systems analysis include:
1. Establishing the objectives of the new system, conducting an analysis of its costs and the benefits to be
derived from it, and outlining the process of systems implementation.
2. Detailed systems analysis must also establish who the system users are, what information they should get
and in what form, and how this information will be obtained from the incoming data and from the databases.
Feasibility Study
The main objective of the feasibility study, the introductory phase of development, is to establish whether the
proposed system is feasible or, to be more accurate, desirable, before resources are committed to the full-scale
project.
In a feasibility study, systems analysts perform a preliminary investigation of the business problem or opportunity
represented by the proposed system development project. Specifically, they undertake the following tasks:
1. Define the problem or the opportunity which the system will address
2. Establish the overall objectives of the new system

3. Identify the users of the system

4. Establish the scope of the system.
5. Propose general hardware/systems software options for the new system
6. Perform a make-or-buy analysis for the application
7. Perform a value assessment, such as the cost-benefit analysis, based in part on the estimate of the development
project size
8. Assess the project risk
9. Recommend whether to proceed with the project, or whether to abandon the project
The five essential aspects of a feasibility study include:
1. Legal feasibility - will the proposed system conform to laws and regulations?
2. Ethical feasibility - will the proposed system conform to the norms of ethics?
3. Technological feasibility - do we have the technology and skills needed to develop and operate the system?
4. Economic feasibility - will the system result in competitive advantage or another payoff to the enterprise?
5. Organizational feasibility - will the organizational change result in an acceptable quality of working life for those
affected by the system?
- Will the political changes caused by the system be accepted?
- Will the organization benefit as a whole?
Requirements Analysis
The principal objective of requirements analysis, the main systems analysis stage, is to produce the requirements
specifications for the system, which set out in detail what the system will do. Requirements (also known as
functional) specifications establish an understanding between the system developers, its future users, the
management and other stakeholders.
Requirements analysis needs to establish:
1. What outputs the system will product, what inputs will be needed, what processing steps will be necessary to
perform inputs into outputs, and what data stores will have to be maintained by the system.

2. What volumes of data will be handled, what numbers of users in various categories will be supported and with
what levels of service, what file and database capacities the system will need to maintain, and other quantitative
estimates of this type.
3. What interface will be provided for the users to interact with the system, based on the skills and computer
proficiency of the intended users.
4. What control measures will be undertaken in the system
Techniques for information gathering in systems analysis: [Figure 15.5]
Techniques for gathering information during systems analysis can be grouped into four categories. A combination of
these approaches is usually employed. They include:
1. Asking the users
2. Deriving from an existing system
3. Deriving from the analysis of the business area
4. Experimenting with the system under development
1. Asking the Users:
Interviewing the users requires considerable skill and preparation. Interviews are a very rich but costly and timeconsuming communication channel.
Characteristics of interviews include:
1. Both open-ended and closed-ended questions may be employed where appropriate. Open-ended questions aim to
draw the user out into a longer explanation or opinion, and closed-ended questions can be answered with yes, no, or
a specific brief response.
2. The interviewing process must be planned, since managers at several levels may have to be questioned.
3. The analyst has to prepare for each interview by establishing the position, activities, and background of the
interviewee. In a structured interview, the analyst relies on a prepared list of questions. In an unstructured interview,
the direction unfolds as the person being interviewed answers the largely-open ended questions; follow-up questions
are then asked.
4. During the interview, the analyst must convey a clear understanding of the purpose of the interview, ask specific
questions in terms understandable to the interviewee, listen rather than anticipate answers, control the interview but
be open to a suddenly discovered rich source of information, and create a record of what is learned.

5. The analyst should analyze the results immediately following an interview session.
Questionnaires:
Questionnaires are an efficient way of asking many users at once, particularly users who are dispersed in the field.
Characteristics of questionnaires:
1. Increasingly, questionnaires are distributed on diskettes or intranets.
2. An easy-to-fill-out questionnaire with concise and closed-ended questions is most likely to meet with success.
Simple yes/no questions and checklists are preferable.
3. Questionnaires have limitations as compared with interviews, in part because of their requisite simplicity.
4. Generally, questionnaires are employed together with other, more powerful, means of eliciting user requirements.
5. Group decision-making processes such as the Delphi method, brainstorming, and nominal group techniques may
also be used in search of creative new solutions. These techniques are sometimes used during JAD sessions.
2. Deriving from an existing system
The requirements for a proposed system may be derived from an existing information system. The possibilities are:
1. The system that will be replaced by the proposed system
2. A system similar to the proposed one that has been installed elsewhere and is accessible to the analyst
3. A proprietary package, whose functionality may be analyzed.
Data Analysis the requirements for the proposed system are derived from the data contained in the outputs of the
existing system and inputs to it. The data can also be obtained from the existing programs and systems
documentation, such as procedures, manuals, organization charts, file descriptions, operations manuals, and so forth.
Document Analysis concentrates on the analysis of business documents, such as orders or invoices.
Observing Work the work of an intended user or by actually participating in the work, the analyst learns first-hand
about the inadequacies of the existing system.
3. Deriving the Requirements from the Analysis of the Business Area
Informational analysis of the business unit to be served by a system may be carried out with Business Systems
Planning. As well, the critical success factors methodology can be used to establish the CSFs of the individual
managers and support them with information.

A method that will also help establish the informational needs of an individual manager is decision analysis. It
consists of the following steps:
1. Identify the key decisions that a manager makes
2. Define the steps of the process whereby the manager makes these decisions
3. Define the information needed for the decision process
4. Establish what components of this information will be delivered by the information system and what data will be
needed to do so.
4. Experimenting with the System as it is being Developed
Experimenting with the system under development is the prototyping approach.
Characteristics of the prototype approach include:
1. An initial system version that embodies some of the requirements is built.
2. The users are able to define their requirements in an Aas compared to something@ manner - which is much easier
than defining them without such a comparison.
3. Prototype may be discarded after it has been put to such use, or it may evolve into the system to be delivered.
15.4 Techniques and Tools of Structured Systems Analysis: Data Flow Diagrams
The purpose of systems analysis is to devise a logical model of the proposed system. Using the methodology known
as structured systems analysis, we graphically describe the system as interacting processes that transform input data
into output data. These processes may then become code modules as the system is further designed and
programmed.
Data Flow Diagrams [Figure 15.7]
The principal tool used in structured analysis is the data flow diagram (DFD), which graphically shows the flow and
transformation of data in the system. A DFD representation of a system is the graphical depiction of what the system
will do.
There are four symbols employed in a DFD. These include:
1. Process - circle
2. Data flow - line

3. Data store - parallel lines

4. External entity - square
Process
Characteristics of a process include:
1. A process (shown as circle) as the term is used in structured analysis, transforms inputs into outputs.
2. The name of the process very briefly explains what the process does.
3. Since the processes are the Aactive@ components of the system, their names reflect this.
4. All processes in a DFD are numbered.
Data Flow
A data flow, shown as a line ending in an arrow, represents a flow of data into or out of a process.
Characteristics of a data flow:
1. Flows show the movement of data between all the components of a DFD.
2. Although during the initial analysis we may consider physical data flows in the existing system, ultimate analysis
will deal with their logical data content.
Data Store
A data store, shown as a parallel line, shows a repository of data maintained by the system.
Characteristics of a data store:
1. A repository may become a data file or a database component - such decisions are made during system design.
2. Both data stores and data flows are data structures
3. Data store names are frequently in the plural, to distinguish them from data flows.
External Entity
An external entity is represented as a square. It is a source from which the system draws data or a receiver of
information from the system.
Characteristics of external entities

1. Entities are external to the system; they are beyond the system boundary.
2. External entities may also be other systems with which the given system interacts.
Using Data Flow Diagrams: From Context Diagram to Level-0 [Figure 15.9]
Our fundamental requirement concerning tools for systems development is that they lend themselves to a process of
progressive refinement, bringing in the details gradually. This helps manage the complexity of the analysis process.
DFD levelling is such a process of progressive refinement.
A context diagram shows only the system interfaces (inputs and outputs) flowing to or from external entities. A
context diagram shows the system as a single process bearing the system's name, with its principal incoming and
outgoing data flows, as they are known at this early stage of analysis. If there are too many to show, a table may be
employed to show inputs and outputs in two columns.
Figure 15.9 - use this figure to discuss a level-0 DFD of a simple order processing system.
Levelling Data Flow Diagrams [Figure 15.10]
Levelling is the gradual refinement of DFD's, which brings more and more detail into the picture. In doing so, it is
necessary to ensure quality by following these basic principles of DFD levelling:
1. The top level DFD is the context diagram of the system. Subsequent levels are obtained by progressively breaking
down individual processes into separate DFDs.
2. Decomposition is governed by the balancing rule, which ensures consistency. The balancing rule states that data
flows coming into and leaving a process must correspond to those coming into and leaving the lower level DFD that
shows this process in more detail.
3. No more than 10 processes should be shown on a given DFD to prevent cluttering the diagram.
4. Not all processes have to be broken down - only those whose complexity warrants it.
5. The levelling process is not over until it's over. That is, as you introduce more detail into the analysis by levelling,
you will note omissions in higher level DFDs - and you will correct them.
6. The numbering rules for processes is as follows. Use 1, 2, 3, and so on in the level - 0 DFD. If you decompose,
say process 3, the processes shown on process 3's level-1 DFD will be numbered 3.1, 3.2, 3.3, and so on.
15.5 Techniques and Tools of Structured Systems Analysis: Description of Entities
The entities that appear in the data flow diagrams are described in further detail in a data dictionary. Data
dictionaries have evolved into powerful tools as repositories of descriptions of all project entities.

Description of Processes: Basic Logic Constructs [Figure 15.11, 15.12, 15.13 & 15.14]
The principal tool that is used to show how the primitive DFD processes transform their input into outputs is through
describing their logic. The principal tool for this specification is structured English, which is a form
of pseudocode - a code describing the processing logic to a human rather than to a computer.
Constructs used to express any processing logic include sequence, loop, and decision. An additional construct
represents multiple choice.
Sequence - specified that one action be carried out after another
Loop - specifies that certain actions be carried out repeatedly while the given condition holds
Decision - specifies alternative courses of action, depending on whether a certain condition holds or not. It expresses
this thought: AIf a given condition exists, one action should be taken, or else the alternative action
Multiple Choice - frequently, a need arises to choose one of a set of several actions, based on a condition that may
have more than two outcomes. Though this situation may be expressed with nested IF constructs, it is far easier to
express it with the multiple selection (CASE) construct.
Description of Complex Decisions in Processes: Decision Tables and Trees [Figure 15.15]
Decision tables and decision trees help us consider all the possible actions that need be taken under a given set of
circumstances in a complete and unambiguous fashion.
A decision table specifies in tabular form the actions to be carried out when given conditions exist.
To design a decision table:
1. Specify the name of the table as its heading, and insert a reference to it at the place in the process description
where the table applies
2. List all possible conditions in the condition stub
3. List all possible actions in the action stub
4. Fill in the condition entries by marking the presence (Y) or absence (N) of the conditions. The number of rules,
that is, entries in the right-hand side of the table equals the number of possible combinations of conditions.
5. For every condition entry, mark with an X an action entry opposite the action(s) to be taken under these
circumstances.
Decision trees present conditions as branches of a tree, going from left to right.

Characteristics of decision trees

1. They are easier to read than are decision tables, but the greater the number of conditions, the more tedious they are
to draw up.
2. They are better for checking the completeness of the policy represented.
Data Dictionaries and the Description of Data
All the descriptions of the DFD entities are entered into the data dictionary of the project. We need to plan what data
and what relationships among data are stored in an organization's databases. The principal vehicle for managing data
is the data dictionary.
The composition of each data store and data flow appearing in the DFDs must be described in the dictionary.
Generally, both data flows and the records in the data stores are data structures, that is, they are composed of more
elementary data entities.