Modern Systems Analysis and Design

Chapter 1
The Systems Development Environment
Information systems analysis and design is a complex, challenging, and stimulating
organizational process that a team of business and systems professionals uses to develop and
maintain computer-based information systems. Although advances in information technology
continually give us new capabilities, the analysis and design of information systems is driven from
an organizational perspective. An organization might consist of a whole enterprise, specific
departments, or individual work groups. Organizations can respond to and anticipate problems and
opportunities through innovative use of information technology. Information systems analysis and
design is therefore an organizational improvement process. Systems are built and rebuilt for
organizational benefits. Benefits result from adding value during the process of creating,
producing, and supporting the organization’s products and services. Thus the analysis and design
of information systems is based on your understanding of the organization’s objectives, structure,
and processes, as well as your knowledge of how to exploit information technology for advantage.
 Complex organizational process(steps)
 Used to develop and maintain computer-based information systems
 Used by a team of business and systems professionals
Application software, software designed to support a specific organizational function or process,
such as inventory management, payroll, or market analysis. In addition to application software, the
total information system includes the hardware and systems software on which the application
software runs, documentation and training materials, the specific job roles associated with the
overall system, controls, and the people who use the software along with their work methods.
Methodologies are comprehensive, multiple-step approaches to systems development that will
guide your work and influence the quality of your final product— the information system. A
methodology adopted by an organization will be consistent with its general management style.
Tools are typically computer programs that make it easy to use and benefit from techniques and
to faithfully follow the guidelines of the overall development methodology. To be effective,
techniques and tools must both be consistent with an organization’s systems development
methodology. Techniques and tools must make it easy for systems developers to conduct the steps

1
called for in the methodology. These three elements—methodologies, techniques, and tools—
work together to form an organizational approach to systems analysis and design
Although many people in organizations are responsible for systems analysis and design, in most
organizations the systems analyst has the primary responsibility. When you begin your career in
systems development, you will most likely begin as a systems analyst or as a programmer with
some systems analysis responsibilities. The primary role of a systems analyst is to study the
problems and needs of an organization in order to determine how people, methods, and information
technology can best be combined to bring about improvements in the organization. A systems
analyst helps system users and other business managers define their requirements for new or
enhanced information services. As such, a systems analyst is an agent of change and innovation.

Developing Information Systems and Systems Development Life Cycle (SDLC)

Most organizations find it beneficial to use a standard set of steps, called a systems development
methodology, to develop and support their information systems. Like many processes, the
development of information systems often follows a life cycle.
For example, a commercial product follows a life cycle in that it is created, tested, and introduced
to the market. Its sales increase, peak, and decline. Finally, the product is removed from the market
and replaced by something else.
System Development Methodology is a standard process followed in an organization to conduct
all the steps necessary to analyze, design, implement, and maintain information systems.
The systems development life cycle (SDLC) is a common methodology for systems development
in many organizations; it features several phases that mark the progress of the systems analysis
and design effort. Every textbook author and information systems development organization uses
a slightly different life-cycle model, with anywhere from 3 to almost 20 identifiable phases.
SDLC is a Traditional methodology used to develop, maintain, and replace information systems.
Phases in SDLC:
1 Planning
2 Analysis
3 Design
4 Implementation
5 Maintenance

2
Planning – an organization’s total information system needs are identified, analyzed, prioritized,
and arranged. The first phase in the SDLC is planning. In this phase, someone identifies the need
for a new or enhanced system. In larger organizations, this recognition may be part of a corporate
and systems planning process. Information needs of the organization as a whole are examined, and
projects to meet these needs are proactively identified.
These needs can then be prioritized and translated into a plan for the information systems
department, including a schedule for developing new major systems. In smaller organizations (as
well as in large ones), determination of which systems to develop may be affected by ad hoc user
requests submitted as the need for new or enhanced systems arises, as well as from a formalized
information planning process. In either case, during project identification and selection, an
organization determines whether resources should be devoted to the development or enhancement
of each information system under consideration. The outcome of the project identification and
selection process is a determination of which systems development projects should be undertaken
by the organization, at least in terms of an initial study.
Two additional major activities are also performed during the planning phase: the formal, yet still
preliminary, investigation of the system problem or opportunity at hand and the presentation
of reasons why the system should or should not be developed by the organization.
A critical step at this point is determining the scope of the proposed system. The project leader and
initial team of systems analysts also produce a specific plan for the proposed project the team will
follow using the remaining SDLC steps.
Analysis – system requirements are studied and structured.
The second phase in the SDLC is analysis. During this phase, the analyst thoroughly studies the
organization’s current procedures and the information systems used to perform organizational
tasks. Analysis has two subphases. The first is requirements determination. In this subphase,
analysts work with users to determine what the users want from a proposed system. The
requirements determination process usually involves a careful study of any current systems,
manual and computerized, that might be replaced or enhanced as part of the project. In the second
part of analysis, analysts study the requirements and structure them according to their

3
interrelationships and eliminate any redundancies. The output of the analysis phase is a
description of (but not a detailed design for) the alternative solution recommended by the
analysis team. Once the recommendation is accepted by those with funding authority, the analysts
can begin to make plans to acquire any hardware and system software necessary to build or operate
the system as proposed.
Design – a description of the recommended solution is converted into logical and then physical
system specifications.
The third phase in the SDLC is design. During design, analysts convert the description of the
recommended alternative solution into logical and then physical system specifications. The
analysts must design all aspects of the system, from input and output screens to reports, databases,
and computer processes. The analysts must then provide the physical specifics of the system they
have designed, either as a model or as detailed documentation, to guide those who will build the
new system.
Logical design – all functional features of the system chosen for development in analysis are
described independently of any computer platform. That part of the design process that is independent
of any specific hardware or software platform is referred to as logical design
Physical design – the logical specifications of the system from logical design are transformed
into the technology-specific details from which all programming and system construction can
be accomplished. Once the overall high-level design of the system is worked out, the analysts begin
turning logical specifications into physical ones. This process is referred to as physical design. As
part of physical design, analysts design the various parts of the system to perform the physical
operations necessary to facilitate data capture, processing, and information output. This can be done
in many ways, from creating a working model of the system to be implemented to writing detailed
specifications describing all the different parts of the system and how they should be built.
In many cases, the working model becomes the basis for the actual system to be used. During physical
design, the analyst team must determine many of the physical details necessary to build the final
system, from the programming language the system will be written in, to the database system that will
store the data, to the hardware platform on which the system will run. Often the choices of language,
database, and platform are already decided by the organization or by the client, and at this point these
information technologies must be taken into account in the physical design of the system. The final
product of the design phase is the physical system specifications in a form ready to be turned over to

4
 programmers and other system builders for construction. Figure 1-6 illustrates the differences between
logical and physical design.
Implementation – the information system is coded, tested, installed and supported in the
organization
During implementation, analysts turn system specifications into a working system that is tested
and then put into use. Implementation includes coding, testing, and installation. During coding,
programmers write the programs that make up the system. Sometimes the code is generated by the
same system used to build the detailed model of the system. During testing, programmers and
analysts test individual programs and the entire system in order to find and correct errors.
During installation, the new system becomes part of the daily activities of the organization.
Application software is installed, or loaded, on existing or new hardware, and users are introduced
to the new system and trained. Testing and installation should be planned for as early as the project
initiation and planning phase; both testing and installation require extensive analysis in order to
develop exactly the right approach.
Implementation activities also include initial user support such as the finalization of
documentation, training programs, and ongoing user assistance.
Maintenance – an information system is systematically repaired and improved. In maintenance,
programmers make the changes that users ask for and modify the system to reflect evolving business
conditions. These changes are necessary to keep the system running and useful

The Traditional Waterfall SDLC

There are several criticisms of the traditional life-cycle approach to systems development; one
relates to the way the life cycle is organized. To better understand these criticisms, it is best to see
the form in which the life cycle has traditionally been portrayed, the so-called waterfall.

5
Problems with Waterfall Approach
 System requirements “locked in” after being determined (can't change)
 Limited user involvement (only in requirements phase)
 Too much focus on milestone deadlines of SDLC phases to the detriment of sound
development practices
Different Approaches to Improving Development
 CASE(computer-aided software engineering) Tools
 Agile Methodologies
 eXtreme Programming
Computer-Aided Software Engineering (CASE) Tools
 Diagramming tools enable graphical representation.
 Computer displays and report generators help prototype how systems “look and feel”.
 Analysis tools automatically check for consistency in diagrams, forms, and reports.
 A central repository provides integrated storage of diagrams, reports, and project
management specifications.
 Documentation generators standardize technical and user documentation.
 Code generators enable automatic generation of programs and database code directly from
design documents, diagrams, forms, and reports.

6
 A class diagram from IBM’s Rational Rose

Agile Methodologies
The Agile Methodologies group argues that software development methodologies adapted from
engineering generally do not fit with real-world software development.

7
  Motivated by recognition of software development as fluid, unpredictable, and
dynamic
 Three key principles
 Adaptive rather than predictive
 Emphasize people rather than roles
 Self-adaptive processes
When to use Agile Methodologies?
 If your project involves:
 Unpredictable or dynamic requirements
 Responsible and motivated developers
 Customers who understand the process and will get involved

eXtreme Programming (pair programming)

 Short, incremental development cycles
 Automated tests
 Two-person programming teams
 Coding and testing operate together
Advantages:
 Communication between developers
 High level of productivity
 High-quality code
Object-Oriented Analysis and Design (OOAD)
 Based on objects rather than data or processes
 Object: a structure encapsulating attributes and behaviors of a real-world entity
 Based on objects rather than data or processes
 Object: a structure encapsulating attributes and behaviors of a real-world entity

Rational Unified Process (RUP)

 An object-oriented systems development methodology

 RUP establishes four phase of development: inception, elaboration, construction,
and transition.
 Each phase is organized into a number of separate iterations.

8
9