COURSE AIS 4: INFORMATION SYSTEM ANALYSIS AND DESIGN

DEVELOPER AND Principal Author:

THEIR BACKGROUND Olivette P. Flores, CPA
Email address: opflores@tsu.edu.ph

Editor: Henry D. Rufino, CPA, MBA

Chairperson, Accountancy and Accounting Technology Department
Email address: hdrufino@tsu.edu.ph

COURSE This course introduces the student to the software development life cycle and
DESCRIPTION its phases. It emphasizes the importance of the systems analysis and design
stage to software development and its inter- dependencies with the other
stages. It provides the student with an understanding of how the systems
analysis and design is performed using business process analysis. The final
output of the course is a system analysis design proposal or recommendation
for an identified industry or organization.
COURSE OUTLINE 1. Planning Phase of System Development Life Cycle
2. Analysis Phase of System Development Life Cycle
3. Design Phase of System Development Life Cycle
4. Implementation Phase of System Development Life Cycle
CHAPTER NO. 1
TITLE Planning Phase of System Development Life Cycle
I. RATIONALE

This module covers the topics on System Development Life Cycle. This module gives an overview
on the different phases of SDLC focusing on the first phase which is the Planning Phase. The topics
at hand focuses on the importance of the role played in information systems development by the
systems analyst and the various approaches to the SDLC that can be used to structure a
development project.

INSTRUCTION TO THE USERS

This module covers the planning phase, the first phase in System Development Life Cycle. In its
developmental activities section, it provides substantial discussions of the topics. It is designed to
be comprehensive yet concise enough to include all relevant principles, rules and concepts. Further
readings as to items that are critical in understanding the whole course shall be included here for
student’s strong g knowledge foundation.

II. LEARNING OBJECTIVES

1. Explain the role played in information systems development by the systems analyst.
2. Describe the fundamental systems development life cycle and its four phases.
3. Explain how organizations identify IS development projects.
4. Explain the importance of linking the information system to business needs.
5. Describe various approaches to the SDLC that can be used to structure a development project.
6. Explain how to select a project methodology based on project characteristics.
7. Discuss how to create a project work plan.
III. CONTENT
A. PREPARATORY ACTIVITIES

This module covers the overview of fundamental systems development life cycle and its phases.
Also, it will highlight the importance of linking the information system to business needs.
Therefore, it is ideal to review the topics in AIS 1 and AIS 2 that explains the relevance of
Accounting Information System to organizations first before going to this introductory topic of
the course.

B. DEVELOPMENTAL ACTIVITIES

Please refer to the discussion below

 CHAPTER 1 PLANNING PHASE

TOPIC 1: THE SYSTEMS ANALYST AND INFORMATION SYSTEMS DEVELOPMENT

The Systems Analyst

▪ The systems analyst is a key person analyzing the business, identifying opportunities for
improvement, and designing information systems to implement these ideas.
▪ The systems analyst assists and guides the project team, so the team develops the right system in
an effective way.
▪ Systems analysts must understand how to apply technology in order to solve problems.
▪ Systems analysts may also serve as change agents who identify the organization improvements
needed, design systems to implement those changes, and train/motivate others to use the
systems.

*The systems analyst plays a key role in information systems development projects.

What are the skills that a Systems Analyst must possess?

1. Introduces change to the organization and people
2. Leads a successful organization change effort
3. Understands what to change and knows how to change it
4. Must have technical skills, as well as, business skills
5. Communicate effectively and give presentations
6. Must be able to deal fairly, honestly, and ethically with other project members, managers,
and systems users

Systems Analyst Roles

As organizations and technology have become more complex, most large organizations now build
project teams that incorporate several analysts with different, but complementary, roles. In smaller
organizations, one person may play several of these roles. Here we briefly describe these roles and how
they contribute to a systems development project.

Project Team Specialization

▪ Systems Analyst
▪ Business Analyst
▪ Infrastructure Analyst
▪ Change management Analyst
▪ Project manager

Systems Analyst
➢ focuses on the IS issues surrounding the system
➢ develops ideas and suggestions for ways IT can improve business process, helps design new
business processes, helps design new business process, designs the new information system, and
ensures that all IS standards are maintained.

Business Analyst
➢ focuses on the business issues surrounding the system
➢ identifies the business value that the system will create
➢ develops ideas for improving the business processes
➢ helps design new business processes and policies
Infrastructure Analyst
➢ Focuses on technical issues surrounding the ways the system will interact with the organization’s
technical infrastructure
➢ Ensures that the new information system conforms to organization standards
➢ Identifies infrastructure changes

Change management Analyst

➢ Focuses on the people and management issues surrounding the system installation
➢ Ensures that adequate documentation and support are available to users
➢ Provides user training
➢ Develops strategies to overcome resistance to change

Project Manager
➢ Highly experienced systems analyst
➢ Ensures that the project is completed on time and within budget
➢ Makes sure the system delivers the expected vale to the organization

The roles and the names used to describe them may vary from organization to organization. In
addition, there is no single typical career path through these professional roles. Some people may
enter the field as a more technically-oriented programmer/analyst. Others may enter as a business-
oriented functional specialist with an interest in applying IT to solve business problems.

Career Paths for System Developers

The Systems Development Life Cycle (SDLC)

All system development projects follow essentially the same fundamental process called the system
development life cycle (SDLC).

The SDLC is composed of four fundamental phases:

➢ Planning - Why build the system?

➢ Analysis - Who, what, when, where will the system be?
➢ Design - How will the system work?
➢ Implementation - System delivery
 Each of the phases include a set of steps, which rely on techniques that produce specific document
files that provide understanding about the project.

Processes and Deliverables

Process Product
Planning Project Plan
Analysis System Proposal
Design System Specification
Implementation New System and Maintenance Plan

Phase 1: Planning

▪ This phase is the fundamental process of understanding why an information system should be
built.
▪ The Planning phase will also determine how the project team will go about building the
information system.
▪ The Planning phase is composed of two planning steps.
1. During project initiation, the system’s business value to the organization is identified
(How will it lower costs or increase revenues?)
2. During project management, the project manager creates a work plan, staffs the
project, and puts techniques in place to help the project team control and direct the
project through the entire SDLC.

Phase 2: Analysis

▪ The analysis phase answers the questions of who will use the system, what the system will do,
and where and when it will be used.
▪ During this phase the project team investigates any current system(s), identifies improvement
opportunities, and develops a concept for the new system.
▪ This phase has three analysis steps:
1. Analysis strategy: This is developed to guide the projects team’s efforts. This includes
an analysis of the current system.
2. Requirements gathering: The analysis of this information leads to the development
of a concept for a new system. This concept is used to build a set of analysis models.
3. System proposal: The proposal is presented to the project sponsor and other key
individuals who decide whether the project should continue to move forward.
▪ The system proposal is the initial deliverable that describes what business requirements the new
system should meet.
▪ The deliverable from this phase is both an analysis and a high-level initial design for the new
system.
Phase 3: Design

▪ In this phase, it is decided how the system will operate, in terms of the hardware, software, and
network infrastructure; the user interface, forms, and reports that will be used; and the specific
programs, databases, and files that will be needed.
▪ Five Design steps:
1. Design Strategy: This clarifies whether the system will be developed by the company
or outside the company.
2. Architecture Design: This describes the hardware, software, and network
infrastructure that will be used.
3. Database and File Specifications: These documents define what and where the data
will be stored.
4. Program Design: Defines what programs need to be written and what they will do.

Phase 4: Implementation

▪ During this phase, the system is either developed or purchased (in the case of packaged software).
▪ This phase is usually the longest and most expensive part of the process.
▪ The phase has three steps:
1. System Construction: The system is built and tested to make sure it performs as
designed.
2. Installation: Prepare to support the installed system.
3. Support Plan: Includes a post-implementation review.

Project Identification and Initiation

Projects are identified when someone recognizes a business need that can be satisfied through the use of
information technology. Project initiation is the point at which an organization creates and assesses the
original goals and expectations for a new system. The first step in the process is to identify the business
value for the system by developing a system request that provides basic information about the proposed
system. Next, the analysts perform a feasibility analysis to determine the technical, economic, and
organizational feasibility of the system.

System Request
The business value for an information system is identified and then described in a system request. This
form contains the project’s sponsor, business need, business requirements, and business value of the
information system, along with any other issues or constraints that are important to the project. The
document is submitted to an approval committee who determines whether the project would be a wise
investment of the organization’s time and resources.

Feasibility Analysis
Once the need for the system and its business requirements have been defined, the approval committee
may authorize the systems analyst to prepare a more detailed business case to better understand the
proposed information system project. Feasibility analysis guides the organization in determining whether
to proceed with the project. Feasibility analysis also identifies the important risks associated with the
project that must be managed if the project is approved. As with the system request, each organization
has its own process and format for the feasibility analysis, but most include techniques to assess three
areas: technical feasibility, economic feasibility, and organizational feasibility. The results of evaluating
these three feasibility factors are combined into a feasibility study deliverable that is submitted to the
approval committee at the end of project initiation.
 CHAPTER 1 PLANNING PHASE

TOPIC 2: PROJECT SELECTION AND MANAGEMENT

CIOs (Chief Information Officers) are challenged to select projects that will provide highest return on
the IT investments. Project portfolio management has become a critical success factor for IT departments.
A selected system development project must undergo a thorough process of project management. A
critical success factor for project management is to start with a realistic assessment of the work and then
manage the project according to the plan. Finally, the project manager monitors the project and refines
estimates as work proceeds.

Project Selection

Many IT organizations tackle several important initiatives simultaneously. For example, new
software applications may be under development; new business models may be under consideration;
organizational structures may be revised; new technical infrastructures may be evaluated.

Systems projects today are evaluated in the context of an entire portfolio of projects.
Determination of a project’s contribution to an entire portfolio of a project reinforces the need for a
feasibility study. Portfolio management takes into consideration the different of projects that exist in an
organization. An approval committee (steering committee) must be selective about where to allocate
resources as most organizations have limited funds. If there are several potentially high-payoff projects,
and they all have the same risk, then maybe only one of the projects will be selected.

Ways to Classify Projects

Size What is the size? How many people are needed to work on the project?
Cost How much will the project cost the organization?
Purpose What is the purpose of the project? Is it meant to improve the technical
infrastructure? support a current business strategy? improve operations?
demonstrate an innovation?
Length How long will the project take before completion? How much time will go by
before value is delivered to the business?
Risk How likely is it that the project will succeed or fail?
Scope How much of the organization is affected by the system? a department? a
division? the entire corporation?
Economic Value How much money does the organization expect to receive in return for the
amount the project costs?

Creating the Project Plan

Once the project is launched by being selected by the approval committee, it is time to carefully
plan the project. The project manager will follow a set of project management guidelines, sometimes
referred to as the project management life cycle, as he or she organizes, guides, and directs the project
from inception to completion. Generally speaking, the project management phases consist of initiation,
planning, execution, control, and closure.

Project Methodology Options

As we discussed in Chapter 1, the Systems Development Life Cycle (SDLC) provides the foundation
for the processes used to develop an information system. A methodology is a formalized approach to
implementing the SDLC (i.e., it is a list of steps and deliverables). There are many different systems
development methodologies, and they vary in terms of the progression that is followed through the
phases of the SDLC. Some methodologies are formal standards used by government agencies, while others
have been developed by consulting firms to sell to clients.

• Waterfall Development
• Parallel Development
• V-model (variation of the Waterfall Development)
• Rapid Application Development (RAD)
- Iterative Development
- System prototyping
• Agile Development

Waterfall Development. Analysts and users proceed sequentially from one phase to the next. The key
deliverables for each phase are typically voluminous (often, hundreds of pages) and are presented to
the approval committee and project sponsor for approval as the project moves from phase to phase.
Once the work produced in one phase is approved, the phase ends and the next phase begins. As the
project progresses from phase to phase, it moves forward in the same manner as a waterfall. While it
is possible to go backward through the phases (e.g., from design back to analysis), it is quite difficult.
(Imagine yourself as a salmon trying to swim upstream in a waterfall).

Parallel Development. This methodology evolved to address the lengthy time frame of waterfall
development. Instead of doing the design and implementation in sequence, a general design for the whole
system is performed. Then the project is divided into a series of subprojects that can be designed and
implemented in parallel. Once all subprojects are complete, there is a final integration of the separate
pieces, and the system is delivered. Parallel development reduces the time required to deliver a system,
so changes in the business environment are less likely to produce the need for rework.
V-model. Another variation of waterfall development that pays more explicit attention to testing. the
development process proceeds down the left-hand slope of the V, defining requirements and designing
system components. At the base of the V, the code is written. On the upward-sloping right side of the
model, testing of components, integration testing, and, finally, acceptance testing is performed. A key
concept of this model is that as requirements are specified and components designed, testing for those
elements is also defined. In this manner, each level of testing is clearly linked to a part of the analysis or
design phase, helping to ensure high quality and relevant testing and maximize test effectiveness.

Rapid Application Development (RAD). It is a collection of methodologies that emerged in response to

the weaknesses of waterfall development and its variations. RAD incorporates special techniques and
computer tools to speed up the analysis, design, and implementation phases in order to get some portion
of the system developed quickly and into the hands of the users for evaluation and feedback. CASE
(computer-aided software engineering) tools, JAD (joint application development) sessions, fourth-
generation/visual programming languages (e.g., Visual Basic.NET), and code generators may all play a role
in RAD. While RAD can improve the speed and quality of systems development, it may also introduce a
problem in managing user expectations. As systems are developed more quickly and users gain a better
understanding of information technology, user expectations may dramatically increase and system
requirements may expand during the project (sometimes known as scope creep or feature creep).

Iterative development breaks the overall project into a series of versions that are developed
sequentially. The most important and fundamental requirements are bundled into the first version of the
system. This version is developed quickly by a mini-waterfall process, and once implemented, the users
can provide valuable feedback to be incorporated into the next version of the system.

System prototyping performs the analysis, design, and implementation phases concurrently in
order to quickly develop a simplified version of the proposed system and give it to the users for evaluation
and feedback. The system prototype is a “quick and dirty” version of the system and provides minimal
features. Following reaction and comments from the users, the developers reanalyze, redesign, and
reimplement a second prototype that corrects deficiencies and adds more features. This cycle continues
until the analysts, users, and sponsor agree that the prototype provides enough functionality to be
installed and used in the organization. System prototyping very quickly provides a system for users to
evaluate and reassures users that progress is being made.
 System Development

Iterative Development

Throwaway prototyping. It includes the development of prototypes but uses the prototypes primarily to
explore design alternatives rather than as the actual new system (as in system prototyping). throwaway
prototyping has a thorough analysis phase that is used to gather requirements and to develop ideas for
the system concept. Many of the features suggested by the users may not be well understood, however,
and there may be challenging technical issues to be solved. Each of these issues is examined by analyzing,
designing, and building a design prototype. A design prototype is not intended to be a working system. It
contains only enough detail to enable users to understand the issues under consideration.

Agile Development. It is a group of programming-centric methodologies that focus on streamlining the

SDLC. Much of the modeling and documentation overhead is eliminated; instead, face-to-face
communication is preferred. A project emphasizes simple, iterative application development in which
every iteration is a complete software project, including planning, requirements analysis, design, coding,
testing, and documentation. Extreme programming emphasizes customer satisfaction and teamwork.
Selecting the Appropriate Development Methodology

As the previous section shows, there are many methodologies. The first challenge faced by project
managers is to select which methodology to use. Choosing a methodology is not simple, because no one
methodology is always best. Many organizations have standards and policies to guide the choice of
methodology. You will find that organizations range from having one “approved” methodology to having
several methodology options to having no formal policies at all.

Important factors to consider in selecting the development methodology:

• Clarity of User Requirements
• Familiarity with Technology
• System Complexity
• System Reliability
• Short Time Schedules
• Schedule Visibility

Estimating the Project Time Frame

As the previous section illustrated, some development methodologies have evolved in an attempt to
accelerate the project through the SDLC as rapidly as possible while still producing a quality system.
Regardless of whether time is a critical issue on a project or not, the project manager will have to
develop a preliminary estimate of the amount of time the project will take. Estimation16 is the process
of assigning projected values for time and effort.

There are two basic ways to estimate the time required to build a system. The simplest method uses the
amount of time spent in the planning phase to predict the time required for the entire project. The idea
is that a simple project will require little planning, and a complex project will require more planning; so
using the amount of time spent in the planning phase is a reasonable way to estimate overall project
time requirements. A more precise approach to estimation is called the function point approach. This
approach is a more complex—and, it is hoped, more reliable—way of estimating time and effort for a
project.
Developing the Work Plan

▪ Identify Tasks. Remember that the overall objectives for the system were recorded on the system
request, and the project manager’s job is to identify all the tasks that will be needed to accomplish
those objectives. This is a daunting task, certainly. The methodology that was selected by the
project manager should be a valuable resource, however. The methodology that seems most
appropriate for the project provides a list of steps and deliverables.
▪ The Project Work Plan. The project work plan is the mechanism used to manage the tasks that
are listed in the work breakdown structure. It is the project manager’s primary tool for managing
the project. Using it, the project manager can tell whether the project is ahead of or behind
schedule, how well the project was estimated, and what changes need to be made to meet the
project deadline.

Staffing the Project

Staffing the project includes determining how many people should be assigned to the project, matching
people’s skills with the needs of the project, motivating them to meet the project’s objectives, and
minimizing project team conflict that will occur over time.

▪ The staffing plan describes the kinds of people working on the project.
▪ The project charter describes the project’s objectives and rules.
▪ A functional lead manages a group of analysts.
▪ A technical lead oversees progress of programmers and technical staff members.

Motivation. Assigning people to tasks isn’t enough; project managers need to motivate the people to
make the project a success. Motivation has been found to be the number-one influence on people’s
performance,17 but determining how to motivate the team can be quite difficult.

▪ Use monetary rewards cautiously

▪ Use intrinsic rewards
o Recognition
o Achievement
o The work itself
o Responsibility
o Advancement
o Chance to learn new skills
Handling Conflict. The third component of staffing is organizing the project to minimize conflict among
group members.

Conflict Avoidance Strategies:

Coordinating Project Activities

CASE (Computer-Aided Software Engineering) tools – A category of software that automate all or part of
the development process.
- Upper CASE
- Lower CASE
- Integrated CASE
CASE comes in a wide assortment of flavors in terms of complexity and functionality, and there are many
good programs available in the marketplace, such as the Visible Analyst Workbench, Oracle Designer,
Rational Rose, and the Logic Works suite. The benefits of using CASE are numerous. With CASE tools, tasks
are much faster to complete and alter; development information is centralized; and information is
illustrated through diagrams, which typically are easier to understand. Potentially, CASE can reduce
maintenance costs, improve software quality, and enforce discipline; and some project teams even use
CASE to assess the magnitude of changes to the project.

Standards. Standards are created to ensure that team members are performing tasks in the same way
and following the same procedures.

• Formal rules for naming files

• Forms indicating goals reached
• Programming guidelines

Documentation standards
Coding standards
Procedural standards
The date and project name should appear as a header on all
documentation.
All margins should be set to 1 inch.
All deliverables should be added to the project binder and recorded
in its table of contents.
All modules of code should include a header that lists the
programmer, last date of update, and a short description of the
purpose of the code.
Indentation should be used to indicate loops, if-then-else
statements, and case statements.
On average, every program should include one line of comments for
every five lines of code
Record actual task progress in the work plan every Monday morning
by 10 A.M.
Report to project update meeting on Fridays at 3:30 P.M.
 All changes to a requirements document must be approved by the
project manager.
Specification requirement Name of program to be created
standards Description of the program’s purpose
Special calculations that need to be computed
Business rules that must be incorporated into the program
Due date
User interface design standards Labels will appear in boldface text, left-justified, and followed by a
colon. The tab order of the screen will move from top left to bottom
right. Accelerator keys will be provided for all updatable fields.
Documentation. Another technique that project teams put in place during the planning phase is good
documentation, which includes detailed information about the tasks of the SDLC. A simple way to set up
your documentation is to get some binders and use dividers to separate content according to the major
phases of the project. An additional divider should contain internal communication, such as the minutes
from status meetings, written standards, letters to and from the business users, and a dictionary of
relevant business terms.

• Project binder
• Table of contents
• Continual updating

Managing and Controlling the Project

The science (or art) of project management is in making trade-offs among three important concepts:
- the size of the system,
- the time to complete the project, and
- the cost of the project.

Refining the Estimates. The estimates that are produced during the planning phase will need to be
refined as the project progresses. This does not necessarily mean that estimates were poorly done at
the start of the project; it is virtually impossible to develop an exact assessment of the project’s
schedule before the analysis and design phases are conducted. A project manager should expect to be
satisfied with broad ranges of estimates that become more and more specific as the project’s product
becomes better defined.

Managing Scope. the most common reason for schedule and cost overruns occurs after the project is
underway— scope creep. Scope creep happens when new requirements are added to the project after
the original project scope was defined and “frozen.” It can happen for many reasons: Users may suddenly
understand the potential of the new system and realize new functionality that would be useful;
developers may discover interesting capabilities to which they become very attached; a senior manager
may decide to let this system support a new strategy that was developed at a recent board meeting.

Timeboxing. This technique sets a fixed deadline for a project and delivers the system by that deadline
no matter what, even if functionality needs to be reduced. Time boxing ensures that project teams don’t
get hung up on the final “finishing touches” that can drag out indefinitely, and it satisfies the business by
providing a product within a relatively fast time frame.

Managing Risk. One final facet of project management is risk management, the process of assessing and
addressing the risks that are associated with developing a project. Many things can cause risks: weak
personnel, scope creep, poor design, and overly optimistic estimates. The project team must be aware
of potential risks so that problems can be avoided or controlled well ahead of time.

• Risk assessment
• Actions to reduce risk
• Revised assessment
IV. SYNTHESIS / GENERALIZATION

• The systems analyst is a key person in the development of information systems. The systems
analyst helps to analyze the business situation, identify opportunities for improvements, and
design an information system that adds value to the organization.
• All system development projects follow essentially the same fundamental process called the
system development life cycle (SDLC). The SDLC starts with a planning phase, analysis phase,
design phase and ends with the implementation phase.
• Projects are identified when someone recognizes a business need that can be satisfied through
the use of information technology.
• The project selection process takes into account all of the projects in the organization, using
portfolio management. The approval committee weighs many factors and makes trade-offs
before a project is selected.

V. EVALUATION

1. What are the six general skills all project team members should have?
2. Compare and contrast the role of a systems analyst, business analyst, and infrastructure
analyst.
3. Describe the major phases in the systems development life cycle (SDLC).
4. Describe the principal steps in the planning phase. What are the major deliverables?
5. Describe how projects are selected in organizations.
6. Describe the factors that the project manager must evaluate when a project falls behind
schedule.
VI. ASSIGNMENT / AGREEMENT

For further reading: Alan Dennis et. al., System Analysis and Design

The next topic is the Design Phase of the System Development Life Cycle. Learner / student is
advised to read in advance the topic in the book of John W. Satzinger et. al., Object- Oriented
Analysis and Design with the Unified Process.

REFERENCES

Alan Dennis et. al., System Analysis and Design

John W. Satzinger et. al., Object- Oriented Analysis and Design with the Unified Process
Priti Srinivas Sajja,(2017) Essence of Systems Analysis and Design