System Analysis and Design

uuuu
wwee
Haramaya University
College of Business and Economics
Department of Management
System Analysis and Design

Contents
Preface
Chapter I
System: An Overview
1.1 Data and Information 1
1.2 Types of information 1
1.3 Functional Allocation of Management 2
1.4 System Concept 6
1.5 System Analysis and Design (SAD) 8
1.5.1 Introduction to Information System 8
1.5.2 Types of Information Systems 9
1.5.3 Some important Systems concepts 11
Chapter II
Information Systems Development Project
2.1 Managing Information System Project 15
2.2 Information Systems Project Phase 16
2.3 Representing and Scheduling Project Plans 19
2.3.1 Gantt Charts 20
2.3.2 PERT Charts 22
2.4 Use of project management software 23
Chapter III
The System Development Life Cycle
3.1 Systems Analysis and Design – core concepts 26
3.2 Approaches to Systems Analysis and Design 28
3.3 Role of the System Analyst 30
3.4 System development life cycle (SDLC) 31
3.4.1 Systems Planning and Selection 32
3.4.2 Systems Analysis 34
3.4.3 Systems Design 35
3.4.4 Systems Implementation and operation 35
3.5 Traditional Waterfall SDLC 37

3.6 Alternatives Approaches for System Development 38
Chapter IV
Systems Planning and Selection
4.1 Project Identification and Selection 43
4.2 Project Initiation and Planning 46
4.3 Feasibility Study 48
4.4 Building the Baseline Project Plan 49
4.5 Reviewing the Baseline Project Plan 50
4.6 Electronic Commerce Application 51
Chapter V
Systems Analysis
5.1 System Analysis 55
5.2 Requirements Determination 56
5.3 Traditional Methods for gathering requirements 57
5.3.1 Interviewing 57
5.3.2 Questionnaires 59
5.3.3 Direct observation 60
5.3.4 Analysing Documents 61
5.4 Modern methods for gathering requirements 62

5.4.1 Joint Application Design (JAD) 62
5.4.2 Business Process Re-engineering (BPR) 63
5.4.3 Prototyping 64
Chapter VI
Systems Analysis
6.1 Structuring Systems Requirements 67
6.2 Data Flow Diagrams 67
6.3 Conceptual Data Modeling (E-R Diagram) 77
Chapter VII
System Design
7.1 Systems design 83
7.2 Logical design and Physical design 84
7.3 Designing effective input, output, database and user interface 85
7.3.1 Designing Effective Input 85
7.3.2 Designing Effective Output 86
7.3.3 Designing Effective Databases 88
7.3.4 Designing User Interfaces 89
7.4 Steps of Design Phase 91

Chapter VIII
Systems Implementation
8.1 The Processes of Coding 93
8.2 Software Testing 94
8.3 Installation 96
8.4 Post implementation review 99
8.5 Systems maintenance 99
8.6 Bug-fixing and Enhancements 101
References
1. Davis, William S. Management, information and systems: An

introduction to business information systems. West publishing company,
1995.
2. Elias M. Awad, System Analysis and Design, Galgotia Publication, 2002
3. Kenneth E. Kendall and Julie E. Kendall , Systems Analysis and Design
Prentice Hall PTR, 5th Edition, 2001
4. Kerzner, H. Project Management - A Systems Approach to Planning,
Scheduling, and Controlling Systems Analysis & Design 5th
Edition2007
5. Modern System Analysis & Design, 4th Jefferey A. Hoffer, Joey F.
George and Joseph. S. Valacich, Prentice-Hall, 2005
6. Satzinger, J. W., Jackson, R. B., & Burd, S. Systems Analysis & Design
In A Changing World, Fourth Edition. Boston: Thomson Course
Technology, 2007
7. Systems Analysis and Design, by K.E.Kendell and J.E.Kendell published
by Pearson Education Asia, 2002
8. System Analysis and Design Syllabus V.Rajaraman/ IISc, Bangalore
V1/1-6-04/1
9. Teague, L and C. Pidgeon. Structured Analysis Methods for Computer
Information Systems. Chicago, Ill.: Science Research Associates, 1985
10. Yourdon, E.. A Natural Productivity in Object-Orientation, in Software
Productivity Handbook, J. Keyes (ed), New York, NY:
Windcrest/McGraw-Hill, 1993
Chapter I
System: An Overview
Chapter Objective
Data and Information
Types of information: operational, tactical, strategic and statutory
Management structure – requirements of information at different levels
of management
Functional allocation of management- requirements of information for
various functions
System Concepts , System and its Components , System Analysis and
Design
Why do we need information systems
1.1 Data and Information

Data are raw facts about the organization and its business transactions. Most data
items have little meaning and use by themselves. Data are a collection of items
such as words, numbers, images, and sounds that are not organized and have
little meaning individually. Data are raw facts about people, objects, and events
in an organization. DATA is a raw material with which we begin. Collecting data
costs money and hence one must collect necessary and sufficient data. Data is
generally used by machines and is useless unless it is processed to create
INFORMATION.
INFORMATION is processed data, used by managers to initiate actions and to
run the organization efficiently. The data processed by machines give
information .Information is used to run an organization efficiently and used by
managers to initiate actions
1.2 Types of information: Operational, tactical, strategic, and Statutory

OPERATIONAL: Needed for day to day operations of the organization. E.g.:
Daily Sales, Bill
TACTICAL: Needed to take short range decisions to improve profitability and
performance.
STRATEGIC: Needed for long range planning and directions. This is less
structured.
STATUTORY: Needed by law to send to government authorities. E.g.: Sales tax
return.
2 A Handbook on System Analysis and Design
Example of operational information needed by a shopkeeper

Daily sales account
List of low stock items to be re-ordered
List of overstock items
Long overdue payments
Profit and loss account
It is obtained by simple processing of data; it is well structured, and more
voluminous. Used to streamline day to day operations called Operational
information
Example of tactical information needed by a shopkeeper

Slow or fast moving items
Reliable supplier of items
Sales trends
Tactical information is used to take short range decisions and for better
control of the functioning of the organization. It requires complex and
ingenious processing of data.
Example of strategic information needed by a shopkeeper

Whether to stock different varieties of items
Whether to diversify
Whether to start a new branch in a different locality
Whether to start an e-shop
Strategic information is needed for long range planning. It is less
structured and difficult to obtain by processing raw data. Information to
expand business and explore new opportunities Known as Strategic
Information
Example of statutory information needed by a shopkeeper

Income tax account
Sales tax account
Expiry date
Date of manufacturing
Statutory information consists of reports to be sent to government by
law. Used to provide information to the government Known as Statutory
Information
1.3 Functional Allocation of Management

Management of organizations is divided functionally. Depending on the size of
the organization, each function maybe delegated to different managers. Large
organizations would have a hierarchical management structure with top level
managers, middle level managers and line managers. Top level managers are
expected to make policies and need strategic information.
A Handbook on System Analysis and Design 3
Middle level mangers direct and control the functioning of organization to

achieve optimal performance and need tactical information. Line managers
supervise day today operations and steer operations to meet targets set by
middle level managers. They need operational information. The primary
functional areas of many organizations are: Human Resource Development,
Production, Materials, Finance, Marketing and Research, Design and
Development. Organizations are divided into many departments, each with a
specific set of functions. Even though an organization may have some
specialized functions, many functions such as Accounts, Human resource
development, Stores, Purchase are common among organizations. Each function
in an organization needs operational, tactical and strategic information.
Functional areas of management in any organization are as follows:
Production manager
Marketing manager
Materials manager
Finance manager
Human Resource manager
A. Types of information for production management

Operational Information
1) Monitoring up to date production information by examining assemblies,
detecting likely shortages and giving early warning.
2) Scheduling better production dynamically.
3) Preventive maintenance schedules.
4) Monitoring tool, machine and personnel availability
Tactical Information
1) Identifying and controlling areas of high cost.
2) Identifying critical bottlenecks in production.
3) Identifying alternate production schedules based on tools, machines etc.
4) Performance measures of machines to decide replacement.
Strategic Information:
1) Yearly and monthly production quotas and alternate schedules
2) Policies on machine replacement, augmentation and modernization.
3) Identifying best product mix.
B. Types of information for Marketing Management

Operational Information:
1) Sales analysis by regions, customer class, sales person.
2) Sales target versus achievement.
3) Market share and trends.
4) Seasonal variations.
5) Effect of model changes.

6) Performance of sales outlets
7) Costs of campaigns and benefit.
Tactical Information:
1) Advertising techniques and analysis of their impact.
2) Customer preference surveys.
3) Correlation of prices and sales.
4) Sales force deployment and targets.
5) Exploring alternate marketing channels.
6) Timing of special sales campaigns.
1) Search for new markets and marketing strategies.
2) Analysis of competitors‘ strategy
3) Technology and demographic forecasts and product changes
C. Types of information for Material Management

1) List of excess & deficient items received.
2) List of items rejected.
3) Critical items received.
4) Stores in transit and in inspection.
5) Value of inventory in hand.
6) Goods received, rejected and issued.
1) Developing vendor performance measures.
2) Determining optimal reorder levels.
3) Determining issues of items to shops versus
4) Standard needs.
5) Controlling high value of inventory.
6) Determining impact on material cost and
7) Procurement with design changes and new
8) Product introduction.
1) Developing vendors for critical items
2) Determining optimal levels of inventory
3) Determining proportion of material needed
4) Reducing varieties of inventory
D Types of information for Finance Management

1) Periodic financial report.
2) Budget status to all functional managers.
3) Tax returns.
4) Share transfers.
5) Profit and loss account.
6) Payments and receipts.
7) Payroll, provident fund accounts.
1) Variations between budget and expenses.
2) Large outstanding payments/Receipts.
3) Credit and payment status.
4) Cost increases and pricing.
5) Impact of taxation on pricing
1) Methods of financing.
2) Pricing policies
3) Tax planning.
E. Types of information for Human Resource Management

1) Routine assessment.
2) Skills inventory.
3) Loan/advances and recoveries.
4) Leave record.
1) Performance appraisal.
2) Demographic make-up of personnel and its impact on retirement.
3) Production incentives.
4) Morale of personnel.
5) Absentee reduction.
6) Leave and overtime policies.
7) Personnel deployment policies.
1) Long range human resource requirements at different levels.
2) Policies on human resource development and training
3) Policies on personnel welfare and facilities
1.4 System Concept

System is a collection of parts that work together to achieve a goal/task. A set of
objects and relationships among the objects viewed as a whole and designed to
achieve a purpose
Examples
Solar system
• Digestive systems
• Public transport system
• Central heating system
• Computer system
• Information system
A System is an interrelated set of business procedures (or components) used

within one business unit, working together for some purpose. For Ex. an
inventory system in the materials department keeps track of the raw materials
supply. The system takes input from outside, processes it, and sends the resulting
output back to its environment. A system can also defined as collections of
people using information technology and processes that define how people
carry out their work. The system also includes informal interactions that take
place in an organization Ex. emails, phone calls.
Characteristics of a System
A System has nine characteristics
1. Components – A component is either an irreducible part or an
aggregate of parts, also called as a subsystem.
2. Interrelated Components – The function of one component is tied
to the functions of the others. Output from one is input for another,
the dependence of a part on one or more other parts.
3. Boundary – A system has boundary, within which all of its
components are contained and which establishes the limits of a
system, separating it from other systems. Components within the
boundary can be changed whereas systems outside the boundary
cannot be changed.
4. Purpose – All components work together to achieve the overall
purpose of the system.
5. Environment – A system exist within an environment, everything
outside the system‘s boundary that influences and / or interacts the
system.
6. Interfaces – The points at which the system meets its environment
and there are also interfaces between subsystems.
7. Input – System takes input from its environment
8. Output - System returns output to its environment as a result of its
functioning to achieve the purpose. Output from individual
subsystems may be inputs to other subsystems.

9. Constraints – There are limits to what the system can do (capacity,
speed, and capability), some of these constraints are imposed inside
the system and others are imposed by the environment.
What is subsystem?
A subsystem is simply a system within a system. Automobile is a system
composed of subsystems:
• Engine system
• Body system
• Frame system
Each of these subsystems is composed of sub-sub --systems. Engine system:

carburetor system, generator system, fuel system, and so on
Bad Systems are those which Fail to meet requirements having Poor
performance, Poor reliability and Lack of usability. Examples of difficulties: Not
to schedule, Not to budget, Runaway = 100% over budget or schedule, some
problems are simply ―wicked‖ problems. Reasons for Failure can be many but
some of them are Complexity, Shifting requirements, Bad estimation, Bad
management, new technology and subject to the need for continuing change.
Fig 1.1- Restaurant system

1.5 System Analysis and Design (SAD)

Systems Analysis is understanding and specifying in detail what an information
system should do and System Design is specifying in detail how the parts of an
information system should be implemented.
Definition of SAD: The complex organizational process whereby computer-
based information systems are developed and maintained.
Why is it important?
Success of information systems depends on good SAD
Widely used in industry - proven techniques
Part of career growth in IT - lots of interesting and well-paying jobs!
Increasing demand for systems analysis skills
1.5.1 Introduction to Information System

Information systems are needed when timely processing for fast action is needed;
same data has to be processed in different ways and when organizations require
innovative processing.
An Information System is an arrangement of people, data, processes, interfaces,
networks and technology that interact for the purpose of supporting and
improving both day-to-day operations in a business (data processing) as well as
supporting the problem solving and decision making needs of management
(information services).
The Information System includes the following

Hardware – Computers, servers and printers
Software- System software and application software
Documentation and training materials – The materials created by
Systems Analyst to help users to use the software
Specific job roles – The roles associated with the overall system, such as
the people who run the computers and the software operating.
Controls- which are the parts of the software written to prevent fraud
and theft
People- Who use the software in order to do their job.
Fig 1.2 Components of information system
1.5.2 Types of Information Systems

The main types of IS are
Transaction Processing Systems
Management Information Systems
Decision Support Systems
Expert Systems
Transaction Processing Systems (TPS)

TPS automates the handling and capture of data about transactions or
business activities
For each transaction, the system must capture the data, verify that it is
valid transaction and accept or reject it
Accepted transactions are stored in the system database
Reporting provides summaries of transactions (ex. daily, weekly)
The analysis and design of a TPS requires to focus on the firm‘s current
procedures for processing transactions. How the organization track,
capture, process and output data?
The goal of TPS development is to improve transaction processing by
speeding it up, using fewer people, improving efficiency and accuracy,
integrating it with other organizational information systems, or providing
information not previously available.
Management Information System (MIS)

MIS takes the raw data available through a TPS and converts them into a
meaningful aggregated from.
It provides reports of this information to managers
Developing MIS calls for good understanding of what kind of
information mangers require and how managers use information in their
jobs.
Thus, the System Analyst must develop a good understanding of the
business and the transaction processing systems that provide data for an
MIS
Decision support System (DSS)

Helps the manager to take decisions by analyzing the data
It provides an interactive environment in which decision maker can
quickly manipulate data and models of business operations
DSS has three parts, the first part is composed of a database, extracted
from a TPS or MIS
The second part consists of mathematical or graphical models of
business processes. The third part is made up of a user interface, that
provides a way for the decision maker to communicate with the DSS.
System Analyst is to concentrate on the three main components
database, model base and user dialogue.
Expert Systems (ES)

An Es is different from other information systems, it replicates the
decision making process by applying rules to information in the way
that an expert would
An ES is developed for a particular area of knowledge or domain, Ex
Medical diagnosis, Weather forecasting, etc.
The ES asks questions, and the end user supplies the answers, rules
applied on the answers and the ES provides a recommendation.
The focus on developing and ES is acquiring the knowledge of the expert
in the particular problem domain. Knowledge engineers perform
knowledge acquisition.
Figure-1.4: Types of Information Systems
1.5.3 Some important Systems concepts

Decomposition – is the process of breaking down a system into its
smaller components, decomposing a system also allows us to focus on
one particular part of a system, making it easier to think of how to
modify that one part independently of the entire system.
Modularity is a direct result of decomposition which divides a system
into modules of a relatively uniform size. This makes it easier to
understand the system.
Coupling means that subsystems are dependent on each other, messages
are passed between subsystems. A good system will have very
independent subsystems with minimal flows of data between them. This
makes the system more simple and easier to change just one part of the
system without affecting the other parts.
Cohesion is the extent to which a subsystem performs a single functions.
Generally coupling must be reduced and cohesion increased, so that it
performs only one function.
Learning Chapter 1
1.1. For taking decisions data must be
(A) Very accurate
(B) Massive
(C) Processed correctly

(D) Collected from diverse sources
1.2. Strategic information is needed for

(A) Day to day operations
(B) Meet government requirements
(C) Long range planning
(D) Short range planning
1.3 Strategic information is required by

(A) Middle managers
(B) Line managers
(C) Top managers
(D) All workers
1.4 In motor car manufacturing the following type of information is

operational
(A) Decision on introducing a new model
(B) Scheduling production
(C) Assessing competitor car
(D) Computing sales tax collected
1.5 In a hospital, information system the following type of information is

strategic
(A) Opening a new children‘s ward
(B) Data on births and deaths
(C) Preparing patients‘ bill
(D) Buying an expensive diagnostic system such as CAT scan
1.6 In a hospital, information system the following type of information is

statutory
(A) Opening a new children‘s‘ ward
(B) Data on births and deaths
(C) Preparing patients‘ bill
(D) Buying an expensive diagnostic system such as CAT scan
1.7 Volume of tactical information is

(A) Condensed
(B) Detailed
(C) Summarized
(D) Relevant
1.8 Volume of operational information is

(A) Condensed
(B) Detailed
(C) Summarized
(D) Irrelevant
1.9 Decision support systems are essential for

(A) Day–to-day operation of an organization.
(B) Providing statutory information.
(C) Top level strategic decision making.
(D) Ensuring that organizations are profitable.
1.10 A computer based information system is needed because

(i) The size of organization have become large and data is massive
(ii) Timely decisions are to be taken based on available data
(iii) Computers are available
(iv) Difficult to get clerks to process data
(A) (ii) and (iii)
(B) (i) and (ii)
(C) (i) and (iv)
(D) (iii) and (iv)
Key to Objective Questions

1.1 C 1.2 C 1.3 C 1.4 B 1.5 D 1.6 B 1.7 C 1.8 B 1.9 C 1.10 B
Discussion Questions
1.1 Distinguish between data and information. Give two examples of
different types of information obtained by processing data.
1.2 What is the main difference between strategic and tactical information?
If an information system is to be designed for a hospital, what would be
the strategic and tactical information?
1.3 What type of information is provided by MIS?
1.4 What is the difference between MIS and DSS?
1.5 What will an MIS provide in a marketing function?
Chapter II
Information Systems Development Project
Chapter Objective
Managing Information System Project
Information Systems Project Phase
Representing and Scheduling Project plans
o Representing Project Plans
o GANTT Chart
o PERT chart
Using Commercial project Management Software
2.1 Managing Information System Project

Project is a planned undertaking of a series of related activities to reach an
objective that has a beginning and an end.
Objective of a project
– Solve a business problem (develop a MIS)
– Take advantage of a business opportunities (develop BIS)
– Other non rational reason: spend existing available resources, training
and enhancing skills of employees
Where do projects come from?

– There is no standard and answer varies from organisation to organisation
– Several projects may be submitted and need selection by filling a
―Systems Service Requests‖
Project manager is an individual with a diverse set of skills who is responsible

for managing the project process when the project is accepted
Skills of project manager: They include

– Leadership
– Management (resources, materials, funding)
– Customer relationships
– Technical problem solving
– Conflict management
– Team management & risk management
• Skills needed by a project manager go beyond just building a system

Project manager refers to system analyst‘s role in managing information
system project
• Project manager works in an environment of change.
– He identifies and solves problems
– He is responsible of all aspect of system development project
(time, cost, progress, etc.)
– He is responsible either as a part or the whole project
2.2 Information Systems Project Phase

Project management
Figure 2.1: Phases of Project management
Project management is the controlled process of initiating, planning, executing

and closing-down a project.
Phase 1: Project initiation

It is the phase where activities are performed to assess the size, scope and the
complexity of the project & to establish procedures to support later project
activities.
Phase-1: project initiation activities

1. Establishing the project initiation team
2. Establishing relationship with the customer

3. Establishing the project initiation plan
4. Establishing management procedures
5. Establishing project management environment & project
workbook
1. Establishing the project initiation team

Size: identify project team member who will work within the project
2. Establishing relationship with the customer

– Develop good work relationship & trust between customer or users of
the project & the IS development group (project team) before the project
– Helps customers to understand their problems they might face & propose
improvement
3. Establishing the project initiation plan

– Define the scope (objectives) of the project (even objectives are fuzzy)
– Assign objectives to project team members
– Define roles of each member in the project
– Might lead to the creation of a System Service Request (SSR)
4. Establishing management procedure

– Concern procedures to manage the project such as communication and
reporting procedures,
• Communication procedure
• Funding & billing procedure
• Conflict management
• Regulatory procedure
• Procedures exist or need to be created
5. Establishing project management environment & project workbook

– Establish an environment that includes data related project, called
workbook
Performing the workbook is one important task of project manager.

Workbook
– Workbook can be on line (a web site as SIMNET) or a hard copy
repository that contains
• All project correspondence: minutes, deliverable, input,
output
• Deliverables and reports
• Standard to performing audits
• Management procedures
• Post project review meeting (future)

– Workbook is mainly on line in order to allow different partners
to access the content through different locations.
Phase-2: Project planning

• It consists to define clear discrete activities and the work needed to
complete the activities within a single project (identify time, input and
output).
• Project planning is different than Information System Planning (ISP)
• ISP focuses on assessing the information system needs of the entire
organization
Planning phase activities

1. Describing project scope, alternatives and feasibility
Understand the project, what problem is addressed, what results are to be
achieved, Measures of success, Completion criteria)
2. Dividing the project into manageable tasks and logical order
(Work breakdown structure (e.g. Gantt chart))
3. Estimating resources and creating a resources plan
4. Developing a preliminary schedule (Utilize Gantt and PERT
charts)
5. Developing a communication plan (Outline communication
processes among customers, team members and management,
Types of reports, Frequency of reports)
6. Determine project standards and procedures (Specify how
deliverables are tested and produced)
7. Identifying and assessing risks (Identify sources of risk, Estimate
consequences of risk)
8. Creating a preliminary budget
9. Developing a statement of work (Describe what the project will
deliver for customer)
10. Setting a baseline project plan (Estimate of project‘s tasks and
resources)
Phase-3: Executing the project

It consists to put the planned baseline project into action. Activities during
executing phase
– Executing the base line project plan
• Keep the project schedule
• Ensure the quality of product deliverable
• Motivate people and increase the work team; think as
one member
– Monitoring the project progress against the actual progress

work
• Enable modifications to current plans when needed
• Adjust resources, budget, and time to activities
• Evaluate efficiency of project team member
• E.g. if one dependence activity is changed, you have to
undertake the impact on the other related activities
– PERT and Gantt will help you to fast undertaking changes

– Managing change to the baseline project plan
• Manage the change if it has to occur
• Managing change requires three steps
– Request a change
– Accept change
– Apply change order
Phase-4: Closing down the project

• When does a project end?
– If requirements have been all met (normal end)
– If all objectives have been successfully achieved
– Customers‘ need are not any more valid in the customer business
environment; state-of-the-art technology is available on the
market)
– Running out of money
• Closing-down the project

– Inform all members about the project end during a review
meeting
• Conducting post-project review

– Set a review meeting with management and customers to assess
project‘ strengths and weakness
– Develop new idea for new projects
• Closing the customer contract

– Stop funding and further new projects
2.3 Representing and Scheduling Project Plans

Table 2.1: Gantt VS Pert
Gantt PERT
Visually shows duration of tasks Visually shows dependencies between
tasks
Visually shows time overlap Visually shows which tasks can be done in
between tasks parallel
Visually shows slack time Shows slack time by data in rectangles
Gantt Charts - Useful for depicting simple projects or parts of large projects,
Show start and completion dates for individual tasks
PERT Charts- Show order of activities, Pert is often used in information system
development because Of lesser emphasis on task direction
2.3.1 Gantt Charts

Planning and controlling are key aspects of project management. A standard tool
that allows managers to plan and control a project is a Gantt chart. Henry
Laurence Gantt (1861-1919) developed the Gantt chart in the early 1900s. A
Gantt chart is a horizontal bar chart that shows the timing of each task. An
example of a simple Gantt chart is shown in Figure 2.2.
Figure 2.2: Simple Gantt chart
The Gantt chart allows the project team, as well as the stakeholders, to visualize
the schedule and to determine the completion date. During the project, the project
manager can determine whether the project is on schedule at any point during the
execution. If changes occur, the project team can utilize the Gantt chart to
determine how the changes will affect the completion date. There are various
software packages that can create Gantt charts, but one that is more widely used
is Microsoft Project (see Figure 2.3). Microsoft Project is a powerful tool that
can create sophisticated Gantt charts as well as other planning diagrams.
Figure 2.3: Gantt chart using Microsoft Project
The first step in creating a Gantt chart is to list all of the tasks that are required
for the project. This is commonly referred to as a Work Breakdown Structure or
WBS. For each task, a time to completion needs to be estimated. Finally, the
order of tasks needs to be determined. As an example, consider purchasing a new
television set as a project. In Figure2.3, nine tasks are listed for this project. For
each task an estimated duration is listed. Finally, for every task after the first one,
a predecessor for that task is selected. For example, the predecessor for task 2 is
task 1. Changing task 2's predecessor causes it to shift to the right of task 1.
Figure2.4: Project Tasks
A Gantt chart is a graphical tool that is easy to understand. Gantt charts are
frequently used in presentations and to communicate with stakeholders. The
disadvantage of Gantt charts is that they may not contain all of the information
needed by the project manager to make decisions during the project. The PERT
chart contains more information than is found on a basic Gantt chart.
3.3.2 PERT Charts

Another planning and controlling tool is the Program Evaluation Review
Technique (PERT). This tool can also be referred to as the Critical Path Method
(CPM). Both PERT and CPM can be used interchangeably, but for the purposes
of this lesson, only the PERT term will be utilized.
PERT method is a critical path scheduling technique used for controlling

resources and timing
– PERT = Program Evaluation Review Technique
– It allows to determines critical path scheduling and Slack
Time
Critical path scheduling is a scheduling plan where the order and duration of the
sequence of activities directly affect the completion date of a project.
– Critical path is represented by the sequence of connected
activities that produces the longest overall time period
– It represents the shortest time to complete a project
Slack time refers to the amount of time that an activity can be delayed without
delaying the project duration.
Figure 2.5 PERT Chart Diagram

A PERT chart presents a graphic illustration of a project as a network diagram

consisting of numbered nodes (either circles or rectangles) representing events,
or milestones in the project linked by labeled vectors (directional lines)
representing tasks in the project. The direction of the arrows on the lines
indicates the sequence of tasks. In the diagram, for example, the tasks between
nodes 1, 2, 4, 8, and 10 must be completed in sequence. These are called
dependent or serial tasks. The tasks between nodes 1 and 2, and nodes 1 and 3
are not dependent on the completion of one to start the other and can be
undertaken simultaneously. These tasks are called parallel or concurrent tasks.
Tasks that must be completed in sequence but that don't require resources or
completion time are considered to have event dependency. These are represented
by dotted lines with arrows and are called dummy activities. For example, the
dashed arrow linking nodes 6 and 9 indicates that the system files must be
converted before the user test can take place, but that the resources and time
required to prepare for the user test (writing the user manual and user training)
are on another path. Numbers on the opposite sides of the vectors indicate the
time allotted for the task.
The PERT chart is sometimes preferred over the Gantt chart, another popular
project management charting method, because it clearly illustrates task
dependencies. On the other hand, the PERT chart can be much more difficult to
interpret, especially on complex projects. Frequently, project managers use both
techniques.
2.4 Use of project management software

There are several tools that support the Gantt and Pert charts, allow facilitating
complexity (number of tasks & relationship) of a project and allow defining
tasks, order tasks, assign resources to tasks, Differences between systems. There
are many software.
– E.g. Microsoft‘s Project is a great tool for anyone who oversees
a team, plans a budget, juggles schedules, or has deadlines to
meet
CASE and Visual Development Environments

• Computer-aided Software Engineering (CASE)
– Software tools that provide automated support for some
portion of the systems development process
– Upper CASE
• CASE tools designed to support systems planning and
selection, systems analysis, and systems design phases
of the systems development life cycle
– Lower CASE
• CASE tools designed to support the systems
implementation and operation phase of the systems
development life cycle
Some CASE Tools

• Diagramming
– Microsoft VISIO
• Project Management
– Microsoft Project
• Development all-in-one solutions
– Oracle Developer Suite
– Microsoft Visual Studio
– Sybase PowerBuilder & Power Designer
CASE and Visual Development Environments

• Types of CASE tools
– Diagramming tools
– Computer display and report generators
– Analysis tools used to check for incomplete, inconsistent or
incorrect specifications
– A central repository
– Documentation generators
– Code generators
• Form and report generators
– CASE tools that support the creation of system forms and reports
in order to prototype how systems will look and feel to users
Learning Chapter
2.1 An individual with a diverse set of skills who is responsible for managing
the project process when the project is accepted is known as.
A. Project Developer
B. Project Analyst
C. Project Manager
D. System Manager
2.2 Which one of the following is not true about Project?

A. Every project must have the beginning as well as end.
B. Sources of project varies from organization to organization.
C. project planning is the first stage of project development.
D. Project manager refers to system analyst in IT related project
2.3 Which one of the following is the third activity of project initiation
phase?
A. Establishing the project initiation team
B. Establishing management procedures
C.Establishing relationship with the customer

D. Establishing the project initiation plan
2.4 Which one of the following is not the phase of project management?
A. Initiation
B. Planning
C. Close down
D. Analysis
2.5 Establishing project management environment & project workbook is

the part of
A. Initiation
B. Planning
C. Execution
D. Close Down
2.6 Which of the following is not the activity related to execution phase of
the project?
A. Managing change to the baseline project plan
B. Monitoring the project progress against the actual progress work
C. Establishing management procedure
D. Executing the base line project plan
2.7 It consists to define clear discrete activities and identify time, input and
output for the project.
A. Project Initiation
B. Project Planning
C. Project Execution
D. Close Down
2.8. In which of the following condition project can be close down?

A. If all objectives have been successfully achieved
B. Customers‘ needs are not any more valid
C. Running out of money and Time
D. All
2.9 Which software tool is helping for project diagramming?

A. Microsoft Office
B, Microsoft Project
C. Microsoft ViSIO
D. All
2.10 It is a great tool for anyone who oversees a team, plans a budget,
juggles schedules, or has deadlines to meet.
A. Microsoft Office
B, Microsoft Project
C. Microsoft ViSIO
D. All

2.1 C 2.2 C 2.3 D 2.4 D 2.5 A 2.6 C 2.7 B 2.8 D 2.9 C 2.10 B
1. Who is project manager and what different kinds of skills he required?
2. Discuss the different between the GANTT and PERT chat.
3. Write down the different software which is use for project management.
4 What are different activities which have been done in the first stage of
project management?
5. What are different activities which have been done in the analysis phase?
Chapter III
The System Development Life Cycle
Chapter Objective
Systems analysis and design – core concepts
Approaches to Systems Analysis and Design
Role of the System Analyst
Systems development Life Cycle (SDLC)
Traditional Waterfall Model
Approaches for Development
3.1 Systems Analysis and Design – core concepts

Systems Analysis
Systems Analysis is the study of a business problem domain for the purpose of
recommending improvements and specifying the business requirements for the
solution.
Systems Design
Systems Design is the specification or construction of a technical, computer
based solution for the business requirements identified during systems analysis.
Systems Analysis and Design (SAD)
Information systems analysis and design is a method used by companies
to create and maintain information systems that perform basic business
functions.
The main goal of SAD is to improve organizational systems through
developing or acquiring application software that can help employees
accomplish key business tasks more easily and efficiently.
An application software is designed to support a specific organizational
function or process, such as inventory management, payroll. The goal of
application software is to turn data into information.
An Information System is developed by following Software
Engineering Process, which consists of proven methodologies,
techniques and tool. These three process work together to form an
organization approach to SAD
Figure 3.1 Software Engg. Process
Methodologies are sequence of step by step approaches that helps to

develop the final product. The methodologies incorporate techniques
like, direct observations and interviews with users.
Techniques provide support for a wide range of tasks including
conducting interviews with users, planning and managing the activities
of a project and designing the reports.
Tools are computer programs, such as computer aided software
engineering (CASE) tools, that make it easy to use specific techniques.
3.2 Approaches to Systems Analysis and Design

Every Information System consists of three key components that anyone who
analyzes and designs must understand, they are data, data flows and processing
logic.
Data are raw facts that describe people, objects and events in an organization.
Ex. Customers account no, account type, balance amount
Dataflow are groups of data that move and flow through a system
Ex. customers account number is captured when he uses a credit card for
purchase
Figure-3.2: Data flow

Processing Logic describes the steps that transform the data and the events that
trigger these steps. Ex. processing logic in a credit card bill preparation
Process Oriented approach

Traditionally, Systems Analysts designed an Information System based on what
the system was meant to do, such as billing or inventory control.
The focus was on outputs and processing logic, in other words, on the
flow, use and transformation of data.
The data used as inputs were seen as important also, but secondary to the
application
Each system would contain its own files and data storage areas
The data in each system would match the specifications for that system
only
Each systems was considered ( looked at) separately
The analysis involved in creating drawings / diagrams that show how the
data moves around the system and where it is stored in between flows.
The problems with this approach are, first the existence of several files
of data each locked with different applications and programs. Second,
many of the files in different applications contain same data, updating
the data becomes tedious process, it also difficult to combine data files
created for specific applications.
Figure-3.3: Process Oriented Approach
Data Oriented approach

Over time the approach changed to being a more data-oriented. This was a
response to the problems above
This approach tends to focus on how the data should be represented
independently of where and how data are used in the system
A data model is produced, which describes the data and relationships
between the data. Business rules define how the organization deals with
the data
Databases are designed around the subjects such as customers, suppliers,
parts. This lets use the dame databases for many different applications
This means that the application is independent of data and data
definitions it is called as application independence
Figure-3.4: Data Oriented Approach
Systems Integration approach

Today, systems development focuses on systems integration. Systems integration
allows hardware and software from different vendors to work together in an
application.
3.3 Role of the System Analyst

A system analyst bridges the communication gap between those who
need the information system and those who understand the technology
A system analyst facilitates the study of the problems and needs of a
business to determine how the business systems and information
technology can best solve the problem and accomplish improvements for
the business.
Involving End users – it is important to include the people (users or end
users) who are involved in the system. Since,
- They use the system, or will use the new system
- They know about the data and / or processes in the system
- They require reports from the system
Involving mangers – managers in the business also need to be

considered, since
- They define the business goals for projects
- They need to know what resources are required for a project
- They need to know how long the project will take
- They make the decisions
To succeed as a systems analyst, the skills needed are analytical,

technical, managerial and interpersonal.
Analytical skill enables to understand the organization and its functions,
to identify opportunities and problems and to analyze and solve problems
Technical skill helps to understand the potential and the limitations of
information technology. Must be able to work with programming
languages and operating systems.
Managerial skill helps to manage project, resources, risk and changes.
Interpersonal skill enables to work with end users as well as other
analysts and programmers. Effective written and oral communication

skills: a system analyst plays a major role as liaison among users,
programmers and other analyst. Hence effective written and oral
communication skill, including competence in leading meetings,
interviewing end users, and listening are very much required.
3.4 System development life cycle (SDLC)

Businesses and organizations use various types of information systems to support
the many processes needed to carry out their business functions. Each of these
information systems has a particular purpose or focus, and each has a life of its
own. This ―life of its own‖ concept is called the systems development life cycle
or SDLC, and it includes the entire process of planning, building, deploying,
using, updating, and maintaining an information system. The development of a
new information system involves several different, but related activities. These
activities, or phases, usually include planning, analysis, design,
implementation, and maintenance /support.
The series of steps used to mark the phases of development for an information
system. It is a common methodology for systems development
Figure3.5: System Development Life Cycle
Like any other processes, the development of information system is too

follows a life cycle Ex. a commercial product such as a Mercedes car
follows a life cycle: 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. The life cycle of an information

system may as follows. Someone has idea for an information system and
what it should do. A careful study is done of how the organization
currently handles the work the system will support. Professionals
develop a strategy for designing the new system, which is then either
built or purchased. Once complete, the system is installed in the
organization, and after proper training, the users begin to incorporate the
new system into their daily work.
The common four SDLC steps are 1) Planning and selection 2) Analysis
3) Design and 4) Implementation and operation. The specific steps and
their sequence are meant to be adapted as required for a project, if
necessary the project can return to an earlier phase. Some activities in
one phase in parallel with some activities of another phase. Sometimes
the life cycle is iterative. Each phase has specific outcomes and
deliverables that feed important information to other phase. These
deliverables are reviewed by parties outside the project team, including
managers and executives. The SDLC is a structured approach; it uses
data-oriented approach.
Figure3.6 -: Software Development Life Cycle- Detailed
3.4.1 Systems Planning and Selection

Planning the system requires the user to define what the problem is. The planning
may also include how the user would like to solve the problem. Defining the
scope of the problem is also important in this stage as well. Defining the scope
helps to prevent the project from scope creep. Once the problem is determined,
and one or more solutions have been selected, planning to implement the solution
begins. Multiple scenarios may be enacted to determine the best course of action
for implementing the system.
Course of action should be well documented and take into consideration a

schedule showing anticipated start and completion times of activities
(milestones) leading to the objectives, knowing expenditures required to achieve
objectives, scheduling regular status reviews (are we on course?), anticipating
any organizational restructuring to accommodate the objectives, anticipating and
planning for mitigation of risks that may hinder achievements, implementing
policies and procedures for decision making, and defining a standard level of
performance.
Within the planning according to the John Sazinger "five of the main activities
must exist" as he explains the fives activities should include:
Define the problem
Produce the project schedule
Confirm project feasibility
Staff the project
Launch the project
Why do plans fail? Some of the many reasons are:

Goals/specifications are not understood.
Objectives are too expensive for the time allotted.
Budgets were not accurate.
Project is understaffed or under skilled.
Status reviews were not scheduled or insufficient.
Poor morale (no commitment).
One of the most difficult decisions in planning is to know when to pull the plug
on a project. This will require an effective control and monitoring system. If you
cannot monitor a system you cannot control it. No organization wants to admit
failure but there may come a point when a project can no longer be salvaged.
This is especially critical with Information Technology projects because of
rapidly changing technologies. Most managers are reluctant to prematurely
terminate a project as careers and egos are at stake. The fallacy of sunk costs may
play a role as well. The result is that projects continue beyond the point of no
return. To avoid this problem, monitor and control systems must be put in place
early during the planning stage. It is critical to define and enforce milestones
where a project will be terminated if necessary. A saving grace is that because a
project is terminated it doesn't make it a complete failure. Excessive cost are
saved for the organization and management can walk away with lessons learned
that can be applied to the next project. In general there are two types of
monitoring "INFORMAL" and "FORMAL". Informal are typically general
meetings, email, and observing. The formal include status reports, scheduled
milestones, audits, reviews, and benchmarks. The formal reviews are generally
more costly and are used during system development processes. Both systems
can be used in combination and involve the questions: "what performance
metrics to use" and "how often do reviews occur"? Attention and energy must be
focused on identifying and correcting out-of-control processes.
3.4.2 Systems Analysis

The analysis phase involves gathering requirements for the system. At this stage,
business needs are studied with the intention of making business processes more
efficient. The system analysis phase focuses on what the system will do in an
effort that views all stakeholders, as viable sources of information. In the analysis
phase, a significant amount of time is spent talking with stakeholders and
reviewing the stakeholder‘s input. Common stakeholders for IT projects are:
Architecture office
Testing & certification office
Records management team
Application support group
Once stakeholders have been recognized, the gathering and analysis of the
requirements can begin. Requirement gathering must be related to business needs
or opportunities. Requirement analysis involves capturing requirements and
analyzing requirements. Capturing requirements is communicating with
stakeholders to agree on what the requirements are. Analyzing requirements is
using standard tools to produce a baseline of the requirements. Once the
stakeholders concur on the requirements, the baseline is created and becomes the
formal requirement source. Within this analysis phase, the analyst is discovering
and fact finding. Along with meeting with stakeholders, the analyst must meet
with end users to understand what the user's needs are and to learn about
problems that affect the current system in order to assist with designing a new
and more efficient system. There are several activities that must occur within the
analysis phase:
Gather Information
Define the new system's requirements
Build prototypes for the new system
Prioritize requirements
Evaluate alternatives
Meet with management to discuss new options
It has three sub phases,

First sub phase involves the systems analyst to determine the
requirements of the system, i.e., what the users want from a proposed
system
Next, the requirements gathered are structured (DFD, ERD) according to
their interrelationships, eliminating the redundancies
Third, system analyst has to generate alternative initial designs to match
the requirements, best suited design is selected for the development after
the comparison of all alternative designs
3.4.3 Systems Design

The system analyst converts the description of recommended solution
into logical and physical designs
Logical design involves in designing the user interface, databases and
compute processes, irrespective of the programming languages (
Algorithms, input and output forms, reports, table normalization)
During the Physical design, the analyst team decides the programming
language, database systems to be used, hardware platform, operating
systems and network environment.
The final outcome of the design phase is the physical system
specifications, presented in the form such as a diagram or written report
ready to be turned over to programmers and other system builders for
construction.
The design phase is concerned with the physical construction of the system.
Included are the design or configuration of the network (hardware, operating
system, programming, etc.), design of user interfaces (forms, reports, etc.),
design of system interfaces (for communication with other systems), and security
issues. It is important that the proposed design be tested for performance, and to
ensure that it meets the requirements outlined during the analysis phase. In other
words, the main objective of this phase is to transform the previously defined
requirements into a complete and detailed set of specifications which will be
used during the next phase. Some of the activities that need to take place during
the design phase are:
Design the application
Design and integrate the network
Design and integrate the database
Create a contingency plan
Start a Maintenance, Training and Operations plan
Review the design
Articulate the business processes and procedures
Establish a transition strategy
Deliver the System Design Document
Review final design
3.4.4 Systems Implementation and operation

In this phase the information system is coded, tested and installed in the
organization, and in which the information system is systematically
repaired and improved
Planning for both testing and installation is to be done as early as the
project planning and selection phase, because they both require extensive
analysis in order to develop exactly the right approach.

This phase also includes the initial training to the users and
documentation of the system documented throughout the life cycle.
During operation part, the problems faced by the users should be solved,
and changes and enhancements (new versions) are to be made as per the
users‘ desire to reflect changing business conditions.
There inevitably comes a time, when an information system is no longer
performing as desired, when the costs of keeping a system running
become prohibitive, or when an organization‘s needs have changed
substantially. Such problems indicate that it is time to begin designing
the system‘s replacement, thereby completing the loop and starting the
life cycle over again.
Initiating a project first requires the documenting of needs or requirements. Clear

objectives should be developed from this study with reasons for selecting the
objectives. Deliverables then need to be documented along with the project
scope. Scope can be refined during this initialization process. Assumptions and
constraints should also be documented. All stakeholders should be involved in
this process. This information will become the projects charter and the basis for
initiating the project. The project then follows the PLAN-DO CHECK-ACT
cycle (as defined by Shewhart and modified by Deming, in the ASQ Handbook,
pages 13-14, American Society for Quality, 1999). The results of each cycle will
be link to the next as input. This process should increase the likelihood of
deliverable acceptance.
In order to achieve deliverable of acceptance and meeting of objectives, the new
system being built must be tested. Aligned with this, the end users must be fully
trained so the company will benefit from the new system. There are five
activities that must be performed during the implementation phase:
Construct software components
Verify and test
Convert Data
Training end users and document the system
Install the system
Maintenance and support covers all activities that are required once the system is
in place. Activities include, but are not limited to:
Phone support for users
Physical onsite user support
Resolving any issues that may arise with the new system
Providing support materials/tools for users
The amount of support required may be determined based on the system. If it is a

large system involving many different departments, maintenance and support
may be needed for a longer time. If is a smaller system, maintenance and support
may only be needed for a short time.
Products of SDLC phases:
3.5 Traditional Waterfall SDLC

Often considered the classic approach to the systems development life cycle, the
waterfall model (mostly predictive) describes a development method that is
linear and sequential. Waterfall development has distinct goals for each phase of
development. Once a phase of development is completed, the development
proceeds (drops over the waterfall) into the next phase and there is no turning
back.
The advantage of waterfall development is that it allows for departmentalization
and managerial control. A schedule can be set with deadlines for each stage of
development and a product can proceed through the development process like a
car in a carwash, and theoretically, be delivered on time. Development moves
from concept, through design, implementation, testing, installation,
troubleshooting, and ends up at operation and maintenance. Each phase of
development proceeds in strict order, without any overlapping or iterative steps.
The disadvantage of waterfall development is that it does not allow for much
reflection or revision. Once an application is in the testing stage, it is very
difficult to go back and change something that was not well-thought out in the
concept stage. This pure waterfall model makes it very difficult because there is
no room for error and that is virtually impossible when dealing with humans.
Waterfall approach – each phase falls into next phase:-
Freeze planning specifications before analysis, Freeze analysis specifications
before design
Once go over the waterfall for each phase, do not go back. One phase begins
when another completes, little backtracking and looping
Figure: 3.6 Traditional Water Fall Model
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
3.6 Approaches for Development (Alternatives to Traditional Waterfall

SDLC)
Prototyping, rapid application development (RAD), Joint application design
(JAD) and Participatory design (PD) are four approaches that streamline and
improve the systems analysis and design process.

Prototyping - Designing and building a scaled-down version of the desired
information system with the help of CASE tools. Prototyping is a key tool that
supports rapid application development. The prototyping-based methodologies
perform the analysis, design, and implementation phases concurrently, and all
three phases are performed repeatedly in a cycle until the system is completed.
With these methodologies, a basic analysis and design are performed, and work
immediately begins on a system prototype, a ―quick-and-dirty‖ program that
provides a minimal amount of features.
Rapid Application Development- RAD involves gaining user acceptance of the
interface and developing key system capabilities as quickly as possible. RAD-
based methodologies adjust the SDLC phases to get some part of the system
developed quickly and into the hands of the users. In this way, the users can
better understand the system and suggest revisions that bring the system close to
what is needed. There are process-centered, data centered, and object-oriented
methodologies that follow the basic approaches of the RAD. Most RAD-based
methodologies recommend that analysts use special techniques and computer
tools to speed up the analysis, design, and implementation phases, such as CASE
(computer-aided software engineering) tools, JAD (joint application design)
sessions, fourth-generation/visual programming languages that simplify and
speed up programming (e.g., Visual Basic.NET), and code generators that
automatically produce programs from design specifications. It is the combination
of the changed SDLC phases and the use of
Joint Application Design- In the late 1970 systems development personnel at
IBM developed a new process for collecting IS requirements and reviewing
system design. It is called JAD (Joint Application Design). It is structured
process in which users, mangers, and analysts work together for several days in a
series of intensive meeting to specify or review system requirements
Participatory design- End users are involved in the SD around a table in one
room to agree about system requirements and system design. They responsible
about the freeze of design ―Milestone‖. They have an equal voice in determining
system requirements and in approving system design.
Learning Chapter
3.1 The third phase of SDLC (system development life cycle) is.
A. Design
B. Analysis
C. Planning and selection
D. Implementation
3.2 Which of the following is not true about traditional water fall model?
A. Freeze analysis specifications before planning
B, Freeze analysis specifications before design
C. Go back concept is not allowed

D. One phase begins when another completes
3.3 Coding, testing, installation, Documentation, Training and support is the

part of which phase
A. Design
B. Analysis
D. Implementation
3.4 Which phase of SDLC explanation of alternative system and justification

of current system has been done?
A. Design
B. Analysis
D. Implementation
3.5 Which phase of SDLC functional and technical detailed are specified for
every elements of system?
A. Design
B. Analysis
D. Implementation
3.6 Which of the following is treated as alternative for traditional water fall
model?
A. Prototyping
B. Rapid Application Development (RAD)
C. Joint Application Design (JAD)
D. Participatory design (PD)
E. All
3.7 Which of the following method user has the equal voice in determining
system requirements and in approving system design?
A. Prototyping
E. All
3.8 A significant amount of time is spent talking with stakeholders and

reviewing the stakeholder’s input.
A. Design
B. Analysis
D. Implementation
3.9 Which of the one methodology perform the analysis, design, and
implementation phases concurrently, and all three phases are performed
repeatedly in a cycle until the system is completed.
A. Prototyping
E. All
3.10 Defining scope of the project, feasibility study and constraints are done
in
A. Planning and Selection
B. Analysis
C. Design
D. Implementation

3.1 A 3.2 A 3.3 D 3.4 B 3.5 A 3.6 E 3.7 D 3.8 B 3.9 A 3.10 A
1. Discuss the important and skills of the system analyst in developing the
system.
2. Discuss the three major approaches to System Development?
3. What do you understand by traditional waterfall model of SDLC? Write
its advantages and limitation.
4. Write down some major activities which has been done in
implementation and operation phase of SDLC.
5. What are different approaches for developing System? Discuss any two
of them.
Chapter IV
Chapter Objective
Project Identification and Selection
Project Initiation and Planning
Feasibility Study
Building the Baseline Project Plan
Reviewing the Baseline Project Plan
Electronic Commerce Application: Internet Basics

This first phase of the systems development life cycle deals with the process of
identifying, selecting, initiating, planning projects and assessing project
feasibility.
4.1 Project Identification and Selection

The first step is to identify the need for a system, which can be the result of
o Problems in existing system or process
o New feature required in an existing system
o A new idea for which in Information System is required
o A requirement to improve efficiency in the organization
o Compulsory standards or bench marks by an external
organization Ex. Government
o The need to keep up with competitors
During this activity a senior manager, a business group, an Information System

manager or a steering committee identifies and assess all possible systems
development projects, which are all may yield significant organizational
benefits.
Figure -4.1: Key Sources for Information System projects
The requests for developing information system can come from three key sources
Managers and business units who want to replace or extend and
existing system in order to gain needed information or to provide
a new service to customers.
Information Systems managers who want to make a system more
efficient, less costly to operate or want to move a system to a
new operating environment.
Formal planning group that want to improve an existing system
in order to help the organization meet its corporate objectives,
such as providing better customer service.
The Selection Process may vary in different organizations, but the general
process is discussed below.
General Process of Identifying and Selection Information Systems

development Projects
Process of identifying and selection consists of three activities: Identifying
potential development projects, classifying and ranking projects and selecting
projects for development
Identifying potential development projects: This process may be
performed by a key member of top management, or a steering committee
composed of a cross section manager, or User departments, or the
development group. Projects identified by top management have a
strategic organizational focus, by the steering committees have a cross
functional focus, by the individual departments have a narrow, tactical
focus. The development group identifies projects based on the ease with
existing hardware and systems. Hence, projects may be identified by
both top-down and bottom-up initiatives. The systems analyst should
support these groups, to describe their information needs.
Classifying and ranking IS development projects: Done by top
managers, a steering committee, business units or the IS development
group. The criteria commonly used to evaluate projects are
Value chain analysis: Extent to which activities add greatest
benefits
Strategic alignment: Extent the projects achieves the long term
goals
Potential benefits: Extent to which the project helps to improve
profits, Customer service, etc and the duration of the benefits
Resource availability: Amount and type of resources required for
the project
Project size / duration: Number of individuals and duration to
complete
Technical difficulty / risk: Level of technical difficult to
complete.
Selecting IS development Project: The short and long term projects

most likely to achieve the business objectives are considered. As
business conditions change over time, the relative importance of any
single project may change.
Figure –4. 2: Factors to be considered during the project selection

The factors must be considered when selecting a project are

Perceived needs of the organization
Existing systems and ongoing projects
Resource availability
Evaluation criteria
Current business conditions
Perspective of the decision makers
Deliverables and outcomes

The primary deliverable or end product form the project identification and
selection phase is a schedule of specific IS development projects. These projects
may come from both top down and bottom up sources. The selected project move
into the second activity called Project initiation and planning
Figure- 4.3: Deliverables from Project Identification and selection phase
4.2 Project Initiation and Planning

The objective of project initiation and planning is to transform vague system
requirements into a tangible project description. Proper project initiation and
planning can reduce the time consumption of further phases. Activities
performed in this phase could also be completed during the next phase, System
analysis. A rule of thumb is that 10 – 20 % of the entire effort should be
expended in this phase
General Process of Initiating and Planning Systems development Projects

Project Initiation focuses on activities that will help to organize a team to
conduct project planning. During initiation, one or more analysts are assigned to
work with a customer to establish work standards and communication
procedures.
Project Planning focuses on defining clear, discrete tasks and the work needed
to complete each task. The objective of the project planning is to produce two
documents: a Baseline Project Plan (BPP) and the Statement of Work (SOW).
Figure-4.4: Statement of Work – an example

The BPP is an internal document used by the development team but not shared
with customers. The BPP contains all information collected and analyzed during
the project initiation and planning activity. The BPP reflects the best estimate of
the project‘s scope, benefits, costs, risks and resource requirements. The BPP
specifies detailed project activities for the next life cycle phase- Systems analysis
and less detail for subsequent phases.
The SOW is a short document prepared for the customers that describe what the
project will deliver and outlines all work required to complete the project. The
SOW is a useful communication tool that assures that both system analysts and
customers have a common understanding of the project.
4.3 Feasibility Study

Most Information System projects have budgets and deadlines; the analysis of
factors for feasibility forms the business case (analysis of the assumptions like
resource availability and potential problems and system cost and benefits) that
justifies the expenditure of the resources on the project. The feasibility factors
are in six categories
1. Economic Feasibility- Concerned with assessing the financial benefits and
costs associated with the project. To do this, it is necessary to quantify the
monetary value of the costs and benefits of the project. This is also called a cost-
benefit analysis.
- Benefits and costs can be tangible or intangible
- Tangibles are items which can be quantified in monetary terms
and with certainty. Ex. equipment costs, staff/personnel costs,
materials costs, conversion costs, training costs.
- Intangibles are items for which a value cannot be precisely
determined, and where the value may be the result of subjective
judgment. Ex. Customer goodwill, employee morale.
Operational efficiency
- The sum value of all costs identified for the project gives the
cost of the system
- The sum value of all the benefits identified for the project gives
the benefit of the systems
- These are then used to determine if the project is economically
feasible. There are two methods for doing this are work sheet
method and present value method
2. Operational Feasibility- This process examines whether the new project will
attain its desired objectives. The goal of this study is to understand the degree to
which the proposed system will likely solve the business problems or take
advantage of the opportunities specified in the Systems requirement documents.
An operational Feasibility concern is to does the proposed system solve problems
or take advantage of opportunities?
3. Technical Feasibility- The goal of this study is to understand the

organization‘s ability to construct the proposed system. This analysis also
includes an assessment of the development group‘s understanding of the possible
target hardware, software and operating environments as well as the size,
complexity and the group‘s experience with similar systems
4. Schedule Feasibility- The process of assessing the degree to which the

potential time frame and completion dates for all major activities within a project
meet organizational deadlines and constraints for affecting change.
5. Legal and Contractual Feasibility- The process of assessing potential legal

and contractual ramification due to the construction of a system. Considerations
may include copyright or nondisclosure violation, labor laws, antitrust
legislation, foreign trade regulations and financial reporting standards as well as
current or pending contractual obligations.
6. Political Feasibility- The process of evaluating how key stakeholders within

the organization view the proposed system
4.4 Building the Baseline Project Plan

All the information collected during project initiation and planning is collected
and organized into a document called the Baseline Project Plan. Once the BPP
is completed, a formal review of the project can be conducted with customers.
BPP contains four major sections
1. Introduction
2. System Description
3. Feasibility assessment
4. Management issues
Introduction section provides a brief overview of the entire document and

outlines a recommended course of action for the project. It provides an executive
summary that specifies the project‘s scope, feasibility, justification, resource
requirements and schedules. Additionally, a brief statement of the problem, the
environment in which the system is to be implemented and constraints that affect
the project are provided. Recommendation provides a summary of important
findings from the planning process and recommendations for subsequent
activities. System Description section provides a list of alternatives system
configuration. It provides a description of the selected configuration and a
narrative of input information, tasks performed and resultant information.
Feasibility Assessment outlines project costs and benefits and technical
difficulties. High level project schedules are specified using PERT and Gantt
charts. The greatest amount of project planning effort is typically expended on
feasibility assessment activities. Management Issues provides a description of
the team member roles and reporting relationships

- Communication plan: Provides a description of the
communication procedures
- to be followed by management, team members and the customer
- Project standards and procedures: Provides a description of
how deliverables will be evaluated and accepted by the customer
- Other project-specific topics: Provides a description of any
other relevant issues related to the project uncovered during
planning.
4.5 Reviewing the Baseline Project Plan

Before submitting the BPP to some project approval body, it is to be reviewed by
the users, management and development groups. The objectives of this review is
to assure that the proposed system conforms to organizational standards and to
make sure that all relevant parties understand and agree with the information
contained in the BPP. A common method for performing this review is called a
structured walkthrough, a peer group review of any product created during the
systems development process.
The walkthrough may have specific agenda that highlights what is to be covered
and the expected completion time. Individuals attending the meeting have
specific roles
- Coordinator
- Presenter
- User
- Secretary
- Standard-bearer
- Maintenance oracle
In addition to reviewing the BPP, the walkthrough can be used for the following
activities
- System specifications
- Logical and physical designs
- Code or program segments
- Test procedures and results
- Manuals and documentation
The key advantage of using a structured review process is to ensure that found
review points occur during the project. At each phase of the project, a formal
review should be conducted to make sure that all aspects of the projects are
satisfactory accomplished before assigning additional resources to project. This
conservative approach of reviewing each major activity with continuation
contingent on successful completion of the prior phase is called incremental
commitment.
4.6 Electronic Commerce Application: System Planning and

Selection
Some of the definitions of e-commerce often heard and found in
publications and the media are:
Electronic commerce (EC) is where business transactions take place via
telecommunications networks, especially the internet.
Electronic commerce describes the buying and selling of products,
services, and information via computer networks including the internet.
Electronic commerce is about doing business electronically.
E-commerce is defined as the conduct of a financial transaction by
electronic means.
E-Commerce is one of the most important facets of the Internet to have emerged
in the recent times. E-commerce or electronic commerce involves carrying out
business over the Internet with the assistance of computers, which are linked to
each other forming a network. To be specific e-commerce would be buying and
selling of goods and services and transfer of funds through digital
communications i.e. the internet especially the World Wide Web. Electronic
commerce or e-commerce refers to a wide range of online business activities for
products and services. It also pertains to ―any form of business transaction in
which the parties interact electronically rather than by physical exchanges or
direct physical contact.‖
E-commerce is the use of electronic communications and digital information
processing technology in business transactions to create, transform, and redefine
relationships for value creation between or among organizations, and between
organizations and individuals. It is usually associated with buying and selling
over the Internet, or conducting any transaction involving the transfer of
ownership or rights to use goods or services through a computer-mediated
network.
• Distributing, buying, selling and marketing products and services over
electronic systems
• E-business for commercial transactions
• Involves supply chain management, e-marketing, online marketing, EDI
Three Modes of E-Commerce:

1. Internet-based
Supports business activities between a business and individual consumers
2. Intranet-based
Supports business activities within a single organization
3. Extranet-based
Supports business-to-business activities
A form of Electronic Data Interchange (EDI) – use of telecommunications for

direct transfer of business documents between organizations
Internet Basics
The Internet is a global network connecting millions of computers. More than
100 countries are linked into exchanges of data, news and opinions. According to
Internet World Stats, as of December 31, 2011 there was an estimated
2,267,233,742 Internet users worldwide. This represents 32.7% of the world's
population.
Unlike online services, which are centrally controlled, the Internet is
decentralized by design. Each Internet computer, called a host, is independent. Its
operators can choose which Internet services to use and which local services to
make available to the global Internet community. Remarkably, this anarchy by
design works exceedingly well. There are a variety of ways to access the
Internet. Most online services offer access to some Internet services. It is also
possible to gain access through a commercial Internet Service Provider (ISP).
Who Owns the Internet?

No one actually owns the Internet, and no single person or organization controls
the Internet in its entirety. The Internet is more of a concept than an actual
tangible entity, and it relies on a physical infrastructure that connects networks to
other networks.
Web Browsers
Web browsers are computer programs that can:
- Display Web documents
- Follow links
- Execute other programs
- Enhance applications such as real-time audio or video
Examples of web Browsers are

• Netscape and Internet Explorer
• Google Chrome
• Opera
• Mozilla Firefox
Learning Chapter 4
4.1 The process of evaluating how key stakeholders within the organization
view the proposed system is part of
A. Schedule Feasibility
B. Legal Feasibility
C. Political Feasibility
D. Technical Feasibility
4.2 Use of telecommunications for direct transfer of business documents

between organizations is known as
A. EFT (Electronic Fund Transfer)
B. E-commerce
C. E-Business
D. EDI (Electronic Data Interchange)
4.3 Which one is the Example of web Browser?

A. Internet Explorer
B. Mozilla Firefox
C. Google chrome
D. Opera
E. All
4.4 Which feasibility study concern that the proposed system solves
problems or take advantage of opportunities?
A. Operational Feasibility
B. Technical Feasibility
C. Schedule Feasibility
D. Legal Feasibility
E. All
4.5 Which one is the third stage of system planning and selection?
A. Reviewing the Baseline Project Plan
B. Feasibility Study
C. Project Identification and Selection
D. Project Initiation and Planning
E. Building the Baseline Project Plan
4.6 In which stage of system planning and selection walkthrough method is

used?
A. Reviewing the Baseline Project Plan
B. Feasibility Study
C. Project Identification and Selection
D. Project Initiation and Planning
E. Building the Baseline Project Plan
4.7 Two documents a Baseline Project Plan (BPP) and the Statement of
Work (SOW) is produced in which stage?
A. Project Initiation and Planning
B. Project Identification and Selection
C. Feasibility Study
D. Building the Baseline Project Plan
E. Reviewing the Baseline Project Plan
Key to objective Questions

4.1 C 4.2 D 4.3 E 4.4 A 4.5 B 4.6 A 4.7 A
1. Write the two major differences between BPP and SOW?
2. What are the different types of feasibility study done in planning and
selection stage of SDLC?
3. Write the two major differences between fourth and fifth stage of
planning and selection phase?
4. What are the five stages or steps in the phase of Planning and selection
phase of SDLC?
5. Define E-commerce and write its few advantages.
Chapter V
Systems Analysis
Chapter Objective
System Analysis and its parts
Requirements Determination
Traditional Methods for gathering requirements
(Interviewing, Questionnaire, Observation and Analysing Documents)
Modern methods for gathering requirements
(Joint Application Design, Business Process Re engineering &
Prototyping)
Fig 5.1: System Analysis phase of SDLC
5.1 System Analysis

Systems analysis is a process of collecting factual data, understand the processes
involved, identifying problems and recommending feasible suggestions for
improving the system functioning. This involves studying the business processes,
gathering operational data, understand the information flow, finding out

bottlenecks and evolving solutions for overcoming the weaknesses of the system
so as to achieve the organizational goals. System Analysis also includes
subdividing of complex process involving the entire system, identification of
data store and manual processes.
The major objectives of systems analysis are to find answers for each business
process: What is being done How is it being done, who is doing it, When is he
doing it, Why is it being done and How can it be improved? It is more of a
thinking process and involves the creative skills of the System Analyst. It
attempts to give birth to a new efficient system that satisfies the current needs of
the user and has scope for future growth within the organizational constraints.
The result of this process is a logical system design. Systems analysis is an
iterative process that continues until a preferred and acceptable solution emerges.
System analysis is the study of a business problem for the purpose of
recommending improvements and specifying the business requirements
for the solution
It has three parts: determining requirements, structuring requirements
and selecting the best alternative design strategy. These steps are may be
parallel and repetitive
5. 2 Requirements Determination
Requirement determination means gathering information on what the system
should do from as many sources as possible. An analyst use system requirements
determination to understand current problems and opportunities as well as what
is needed and desired in future systems. The sources can be the users of the
current system, reports, forms and procedures. All the system requirements are
carefully documented and made ready for structuring.
The characteristics of a good systems analyst in determining the requirements are
o Impertinence: You should question about each and every
aspects involved in the system.
o Impartiality: The role of a SA is to find the best solution to a
business problem or opportunity. Not to justify the purchase of
new hardware or to insist some requirements. The issues raised
by all parties must be considered and to find the best
organizational solution.
o Relaxing of Constraints: Assume that anything is possible and
eliminate the infeasible and traditions. Traditions are different
from rules and policies, it may be good but as the organization
and its environments changes, the traditions not to be
appreciated.
o Attention to details: Every fact must fit with every other fact.
One element out of place means that the ultimate system will fail
at some time.
o Reframing: Analysis is, in part, a creative process; the

organization must be viewed in new ways. Not to jump to this
conclusion that ― I worked on a system like that once - this new
system must work the same way as the one I built before‖.
Deliverables and outcomes

The primary deliverables from requirements determination are the types of
information gathered and the information can take many forms such as
transcripts of interviews, notes from observation and analysis of documents,
analyzed responses from questionnaires, set of forms, reports, job descriptions
and other documents.
In addition a SA need to understand the following components of an
organization
o The business objectives that drive what and how work is done
o The information people need to do their jobs
o The data handled within the organization to support the jobs
o When, how and by whom or what the data are moved,
transformed and stored
o The sequence and other dependencies among different data
handling activities
o The rules governing how data are handled and processed
o Policies and guidelines that describe that nature of the business
and the market and environment in which it operates
o Key events affecting data values and when these events occur.
These all information must be organized for the purpose of requirements

structuring
5.3 Traditional Methods for gathering requirements

The traditional ways to get information directly from those who have the
information is by conducting interviews, questionnaires and direct observation
and collecting documentation on the current system and organizational operation
in the form of written procedures, forms, reports and other hard copy.
All the methods can be used to gather requirements and build up information
about the current system. Asking questions and observing can help to gather
knowledge about the informal system, what people actually do in their work.
Analyzing documentation and asking questions can help to gather knowledge
about the formal system- what is expected of the system.
5.3.1 Interviewing
The SA (System Analyst) has to spend a large amount of time in interviewing the
people about their work, the information they use to do it and the types of
information processing that might supplement their work. Other people are too
interviewed to understand organizational direction, policies and expectations that

managers have on the units they supervise. The facts, opinion and speculation
(rumor) are gathered, the body language, emotions and other signs of what
people want and how they assess current systems. SA can sometimes determine
if people are answering truthfully or fully by the words they use, whether they
make direct eye contact, the tone of voice they use or their body language.
Some guidelines to conduct the interview effectively are
o Prepare thoroughly before the interview. Set up an appointment
at a convenient time for the interviewee. The general nature of
the interview should be explained to the interviewee in advance.
o You want the interview to be natural and to some degree, you
want to direct the interview spontaneously as you discover what
expertise the interviewee brings to the session.
o Prepare and interview guide or checklist so that you know in
which sequence to ask your questions and how much time to
spend in each area of the interview.
o The interviewee may provide information you were not
expecting, you may not follow the guide in sequence. However
check off questions you have asked and write remainders to
yourself to return to or skip other questions as the interview
takes place.
Choosing interview Questions

The open-ended and closed-ended questions must be mixed.
Open-ended questions in interviews and on questionnaires that have no
pre-specified answers.
The advantages of open-ended questions: previously unknown
information can surface and interviewee may get more of a sense of
involvement and control in the interview.
The major disadvantage of open-ended questions in the length of time it
can take for the questions to be answered.
Closed-ended questions provide a range of answers from which the
interviewee may choose.
These sorts of questions works well when the major answers to questions
are well known. Another plus is that interviews based on these questions
do not require a large time.
The major disadvantage of closed-ended questions is that useful
information that does not quite fit the defined answers may be
overlooked as the respondent tries to make a choice instead of providing
his or her best answers.
Interview Guidelines
1. Plan the interview.
a. Prepare interviewee: appointment, priming questions.

b. Prepare agenda, checklist, and questions.
2. Listen carefully and take notes (tape record if permitted).

3. Review notes within 48 hours.
4. Be neutral.
5. Seek diverse views
Each question in an interview guide can include both verbal and non-verbal
information.
Individual Interviews: - Interview one person at a time.
Advantages: Easier to schedule than group interviews
Disadvantages: Contradictions and inconsistencies between interviewees.
Follow-up discussions are time consuming
Group Interviews:-Interview several key people together.
Advantages: More effective use of time, Can hear agreements and
disagreements at once, Opportunity for synergies
Disadvantages: More difficult to schedule than individual interviews
5.3.2 Questionnaires
Questionnaires have the advantage of gathering information from many people in
a relatively short time. Interviews are quite expensive and time-consuming
process, but the questionnaires are not expensive. Questionnaires are passive and
often yield less rich information than interviews. Questionnaires are most useful
in the requirements determination process when used for very specific purposes
rather than for more general information gathering.
Choosing Questionnaire Respondents

It must be decided which questionnaire to be given to which group of
people. It should be send to representatives of all users.
The representatives can be selected by any one or combination of these
following
o Those convenient to sample: The people those willing to be
surveyed or those most motivated to respond.
o A random group: the nth person of all users list can be chosen
randomly
o A purposeful sample: Only people who satisfy certain criteria,
such as users of the system.
Designing Questionnaires
Questionnaires are less expensive means that the people can complete
the questionnaire without help. Also answers can be provided at the
convenience of the respondent.
Questionnaires may include closed-end questions and open-end

questions, preferably closed-end questions, because they are easier to
complete and they define the exact coverage required.
A few open-ended questions give the person being surveyed an
opportunity to add insights not anticipated by the designer of the
questionnaire.
The questions must be extremely clear in meaning and logical in
sequence, without ambiguity in question and answers.
Choosing between Interviews and Questionnaires

The interviews are good tools for collecting rich, detailed information
and that interview allow exploration and follow-ups but quite time
intensive and expensive.
The questionnaires are inexpensive and take less time, as specific
information can be gathered from many people at once but the
information gathered is less rich and follow up questions is more
difficult as it often involves interview or phone calls
These differences are important to remember during the analysis phase.
Deciding which method to use and what strategy to employ to gather
information will vary with the system being studied and its
organizational context.
5.3.3 Direct observation

It is also possible to gather information about a system by watching the users of
the system at work. This method can bring more objective information - as the
analyst can see what the person does (behavior), rather than what they say they
do. This can be used to supplement or confirm the information obtained by
asking questions.
Observation can take place in two ways.
1. By the analyst participating in the user‘s work Ex. becoming a
member of the team for a week
2. By watching the users at work – this can be done in person or by
video camera.
The advantages of observation over asking questions is that the analyst

can see what the user‘s behaviour and interactions with the system
actually are, not what they say they are.
There are also disadvantages to observation – while being observed,
people may not behave normally (if they know they are being observed)
– they may change their behaviour. Also the time at which the
observation takes place may mean that the analyst sees only a small
subset of the work done by the user.
The purpose of on-site observation is to get as close as possible to the real system
being studied. It is the process of recognizing and noting people, objects and
occurrences to obtain information. As an observer the analyst must follow a set
of rules. He/she must listen than talk and not give advice or pass a moral
judgment, must not argue or show friendliness towards others. The following
questions can serve as a guide for on-site observations:
What kind of system is it? What does it do?
Who runs the system? Who are the important people in it?
What is the history of the system?
5.3.4 Analyzing Documents (Reports, forms, procedures and manuals)

Another way to gather information about the current system or possible
improvements to it is to review and analyze documentation. This can provide
information about:
1. Problems with existing system
2. Opportunity to meet new need
3. Organizational direction
4. Names of key individuals
5. Values of organization
6. Special information processing circumstances
7. Reasons for current system design
8. Rules for processing data
Relevant types of documentation include:

o Written work procedures for an individual role or a work group
– a work procedure describes how a particular job or task is
carried out, it includes the data and information used and created
in the process.
o Business forms – forms are used for many business functions
Ex. in a bank, there are forms for making deposits, withdrawals,
transfers etc. forms can provide good understanding of a system
because they explicitly show what data flows in and out of the
system.
o Reports generated by current systems- it is possible to work back
from the information on the report to understand what data was
used to generate the report. Analysis of reports can determine
what data needs to be captured over time and over what time
periods, and how the data needs to be manipulated or
transformed.
o Documentation about current computer systems – if the team
that analyzed, designed and built the existing system also
produced good documentation about the system (specifications,
test plans, user manuals etc) then this can be a good source of
information about the system.
Potential Problems with Procedure Documents:

1. May involve duplication of effort
2. May have missing procedures
3. May be out of date
4. May contradict information obtained through interviews
Formal vs. Informal Systems

1. Formal
a. The official way a system works as described in organization‘s documentation
b. Procedure documents describe formal system
2. Informal
a. The way a system actually works in practice
b. Interviews and observation reveal informal system
5.4 Modern methods for gathering requirements

The modern methods are additional techniques to collect information about the
current system, the organizational area requesting the new system, and what the
new system should be like: the modern methods are Joint Application Design and
Prototyping. These techniques reduce the time of collecting and structuring the
requirements.
5.4.1 Joint Application Design (JAD)

JAD is a means to bring together the key users, managers, and systems analysts
involved in the analysis of a current system. The goal of JAD is to collect
systems requirements simultaneously from the key people involved in the
system. JAD sessions are usually conducted in a location away from where the
people normally work, to keep them away from all distractions , so that they can
concentrate fully on systems analysis.
The people involved in a JAD are

- JAD session leader: To organize and run the JAD- should be trained in
facilitation and group management and is usually a systems analyst. Sets the
agenda, resolves conflicts and disagreements, keeps the session on track and
gets all ideas from participants
- Users: Key users of the existing and new system
- Mangers of User group: To provide information about the organization‘s
direction and the motivations and impacts of the systems, also to support the
requirements determined during the JAD.
- Systems Analysts: To learn from users and mangers, may participate and
advise on IS issues
- Sponsor: A senior person in the organization who is supporting and providing

the budget for the development, usually attends only at start and end of session
- Scribe: To take notes during the sessions and record the outcomes of the
meeting ( on a laptop or PC if possible)
- IS staff: To learn from the discussion, may also contribute ideas on technical
feasibility or limitations of systems
JAD sessions are held in a special room equipped with white boards, audiovisual
tools, overhead projector, flip charts and computer generated displays.
Figure-5.2 A typical room layout for a JAD session
5.4.2 Business Process Re-engineering (BPR)

BPR means the search for, and implementation of, radical change is
business processes to achieve breakthrough improvements in products
and services.
BPR is a process in which existing methods of doing business are
replaced with new and updated methods
In many business, the systems in place consists of programs that were
written some time ago and still use old methods and technologies. They
often support only one business unit. These are called legacy systems
These systems were designed around the processes that took place in the
business unit
In some organizations, the management is looking for new ways to

perform current task , ie to improve or change the way things are done-
ie to change the business processes. This is called Business Process Re-
engineering.
The overall process by which current methods are replaced with radically
new methods is referred as BPR.
The new ways of doing things may be very different from the old ways,
but the benefits may be big , since the processes become more efficient.
Since, the legacy systems were built around the business; a business re-
engineering process often requires changes to the information systems.
Major Goals of BPR

a. Reorganize complete flow of data in major sections of an organization
b. Eliminate unnecessary steps
c. Combine steps
d. Become more responsive to future change
5.4.3 Prototyping
Prototyping allows to quickly converting basic requirements into a working,
though limited, version of the desired information system. The user can view and
test the prototype. The goal of prototyping is to support requirements
determination to develop concrete specifications for the ultimate system, not to
build the ultimate system.
Prototyping is most useful in the following circumstances
o User requirements are not clear or well understood
o Only one or a few users involved
o Possible designs are complex
o Communication problems have existed in the past, between
users and analysts
It also has some disadvantages

o Analysts may avoid creating formal documentation of the system
o The prototype may be very influenced by the initial user who
reviews it- and thus might not be adaptable to other users
o Often build as a standalone system, which may result in interfaces
with other systems being ignored during this phase.
Learning Chapter 5
5.1 The overall process by which current methods are replaced with
radically new methods is referred as.
A. JAD (Joint Application Design)
B. RAD (Rapid Application Development)
C. Prototyping
D. Business Process Reengineering
5.2 Which of the following allows to quickly converting basic requirements

into a working, though limited, version of the desired information system?
A. JAD (Joint Application Design)
B. RAD (Rapid Application Development)
C. Prototyping
D. Business Process Reengineering
5.3. Which one is most useful in the requirements determination process

when used for very specific purposes rather than for more general
information?
A. Questionnaires
B. Interview
C. Observation
D. Analysis of Documents
5.4 A person responsible to take notes during the sessions and record the
outcomes of the JAD meeting is known as
A. User
B. Scribe
C. User Manager
D. System Analyst
5.5 Which one of the following is treated as the secondary source of

gathering requirement for the system?
A. Analysing Documents
B. Questionnaire
C. Interview
D. Observation
5.6 One of the following is not the part of system analysis.

A. Determining requirements
B. selecting the best alternative design strategy
C. Analysing requirement
D. structuring requirements
5.7 It is a good tool for collecting rich, detailed information and its allowed
exploration and follow-ups but quite time intensive and expensive.
A. Questionnaires
B. Interview
C. Observation
D. Analysis of Documents
5.8 Which method is treated appropriate when user requirements are not
clear and design is complex?
A. Prototyping
B. JAD (Joint Application Design)
C. BPR (Business Process Reengineering)
D. RAD (Rapid Application Development)
E. All
Key for Objective Questions

5.1 D 5.2 C 5.3 A 5.4 B 5.5 A 5.6 C 5.7 B 5.8 A
1. What are the characteristics of a good systems analyst in determining the
requirements for system?
2. Explain the different sources for analysing of documents in the
organisation for gathering requirements.
3. Write some major characteristics of three main modern method of data
collection.
4. Explain some situation for choosing between interview or questionnaire
method of data collection.
Chapter VI
Systems Analysis
Chapter Objective
Structuring Systems Requirements
Process Modeling (DFD Diagrams)
Conceptual Data Modeling (ER Diagrams)
6.1 Structuring Systems Requirements- The information gathered during the

requirements gathering process needs to be organized into a form that is a
meaningful representation of the existing system and of the requirements for the
new system.
This is done by producing models of the processing elements and data
transformations and then of the structure of the data. This entire process is called
structuring requirements
There are two stages in the structuring process
Process modeling
Conceptual data modeling
Process modeling involves graphically representing the processes, or actions

that capture, manipulate, store and distribute data between a system and its
environment and among the components within a system.
A common form of a process model is a data flow diagram (DFD). DFD is a
graphic that illustrates the movement of data between external entities and the
processes and data stores within a system.
Conceptual Data Modeling involves representing the data in a system or
organization, to show the overall structure of the data. A data model should be
independent of any DBMS and of other implementation considerations.
Entity-Relationship diagram(ER) data models are commonly used
diagrams that show how data is organized in a system.
6.2 Data Flow Diagrams

The DFD is an excellent communication tool for analysts to model processes and
functional requirements. One of the primary tools of the structured analysis
efforts of the 1970's it was developed and enhanced by the likes of Yourdon,
McMenamin, Palmer, Gane and Sarson. It is still considered one of the best
modeling techniques for eliciting and representing the processing requirements
of a system
Data Flow diagramming mechanics

DFD‘s are versatile programming tools. With only four symbols, it can represent
both physical and logical information systems.
Data flow-
It is the directional movement of data to and from external entities, the process
and data stores. If it flows into a data store, means a write, update, delete, etc. if
flows out of data stores, mean read, query, display, select types of transaction.
Symbol: Solid line with arrow. Each data flow is identified with a
descriptive name that represents the information on the data flow.
Example.
Registration data
Process -
It is a work or actions performed on data so that they are transformed, stored, or
distributed. When modeling the data processing of a system, it doesn‘t matter
whether process is performed manually or by a computer.
Depending on the level of the diagram it may represent the whole system
as in a Context (level 0) diagram or a business area, process (activity),
function, etc. in lower levels.
Symbol: Circle or a Rounded Rectangle. Example.
Data Store:
It is repository of information. In the physical model, this represents a file, table.
Symbol: Two parallel lines or open ended rectangle. Example.
External Entity
It is a source/sink (the origin and /or destination of the data). It is a person or
group which interacts with the system and something from outside the system.
E.g. Customer, supplier, government agency, accounting dept, etc. usually
external to the business or system but may be internal
Data must be originated outside a system from one or more sources, and
the system must produce information to one or more sinks.

Symbol: rectangular box which may be shaded. Example.
Developing DFD’s
The DFD for Hoosier burger food ordering system - An example
A context diagram is a DFD that provides a general overview of a system, other
DFD‘s can be used to focus the details of a context diagram. This context
diagram contains only one process, no data stores, four data flows, and three
external entities. The single process labeled ―0‖, represents the entire system. All
context diagrams have only one process labeled ―0‖. No data stores appear on a
context diagram, since the data stores of the system are conceptually inside the
one process.
Figure-6.1: Context diagram (Level-0) for Hoosier burger automated system
After drawing the context diagram, the next step is to analyze the
processes are represented by the single process. There are four main
processes are identified, the processes represent the major functions of
the system, the major functions are
o Capturing data from different sources (process 1)
o Maintaining data stores (process 2 and 3)
o Producing and distributing data to different sinks (process 4)

o High level descriptions of data transformation operations
(process 1)
The flow from first process 1. are 1) the food order is transmitted to the
kitchen, 2) the customer order is transformed into a list of goods sold, 3)
the customer order is transformed into inventory data, and 4) the process
generates a receipt for the customer.
Two of the data flows generated by the process, receive and transform
customer food order, go to external entities, not to concern about what
happens outside of our system..
Figure-6.2: Level 1- diagram of Hoosier Burgers food ordering system

The data labeled Goods Sold go to process 2, update Goods Sold file.
The output for this process is labeled Formatted Goods Sold Data. The
output updates a data store labeled Goods Sold File. Daily Goods Sold
amounts are then used as input to process 4, Produce Management
reports. Similarly the data flow generated by process 1 called Inventory
Data, serves as input for process 3, Update Inventory File. The Daily
Inventory Depletion amounts are then used as input to process 4.
The DFD hides the physical characteristics of the system it describes.
Process 1 and 3 are coupled to each other, since the data flow from
process 1 must be readily accepted by process 3.
Process 2 and 4 are decoupled by placing a buffer, a data store.
Data Flow Diagramming Rules

Process
A. No process can have only outputs. It is making data from nothing. If
an object has only outputs, then it must be a source.
B. No process can have only inputs. If an object has only inputs, then it
must be a sink
C. A process has a verb phrase label
Data Store
D. Data cannot move directly from one data source to another data
source. Data must be moved by a process
E. Data cannot move directly from an outside source to a data store.

Data must be moved by a process that receives data from the source
and places the data into the data store.
F. Data cannot move directly to an outside sink from a data store. Data
must be moved by a process.
G. A data store has a noun phrase label.
External Entity (Source / Sink)

H. Data cannot move directly from a source to a sink. They must be
moved by a process if the data are of any concern to our system.
Otherwise, the data flow is not shown on the DFD.
I. A source/sink has a noun phrase label
Data Flow
J. A data flow has only one direction of flow between symbols. It may
flow in both directions between a process and a data store to show a
read before an update. The latter is usually indicated, however by
two separate arrows because these happen at different times.
K. A fork in a data flow means that exactly the same data go from a
common location to two or more different processes, data stores, or
sources/sinks.
L. A join in a data flow means that exactly the same data come from
any of two or more different processes , data stores, or sources/sinks
to a common location
M. A data flow cannot go directly back to same process it leaves. There

must be at least one other process that handles the data flow,
produces some other data flow, and returns the original data flow to
the beginning process.
N. A data flow to a data store means update (delete or change)

O. A data flow from a data store means retrieve of use
P. A data flow has a noun phrase label. More than one data flow noun
phrase can appear on a single arrow as long as all of the flows on the
same arrow move together as one package.
Decomposition of DFD’s
The act of going from a single system to more component processes is called
decomposition. The functional decomposition is a repetitive process of breaking
the system into finer and finer detail. Each of the processes (or subsystem) is also
candidate for decomposition. Each process may consist of several sub processes.
Each sub process may also be broken down into smaller units.
Decomposition continues until no sub process can logically be broken down any
further. The lowest level of DFD is called primitive DFD. The first process in the
figure-2 can be decomposed into four different outputs. 1) Receive a customer
order, 2) transform the entered order into a printed receipt for the customer, 3)
transform the order into a form meaningful to the kitchens system 4) transform
the order into goods sold data, and 5) transform the order into inventory data.
The decomposition of Process 1 is given below
Figure-6.3: Decomposition of Process 1 (Level-2)
The context and level-0 diagram will show the sources and sinks. No sources or
sinks are represented in figure-3. We can decompose processes 2, 3, or 4 in a
similar manner. In general, a level-n diagram is a DFD that is generated is form n
nested decompositions from a level-0 diagram. As a rule of thumb, no DFD
should have more than about seven processes in it.
The labels for the processes and numbering rules for clear communication,
process names should be clear and concise; it may begin with an action verb,
such as receive, calculate, transform, generate or produce. Process 4 can be
further decomposed into level-1, level-2 as given below.
Figure- 6.4: level-1 and level-2 DFDs of Process 4.0
Balancing DFDs
The conservation of inputs and outputs to a data flow diagram process
when that process is decomposed to a lower level.
For Ex. Process 1, which appears in a level-0 diagram, must have the
same inputs and outputs when decomposed into a level-1 diagram is
called balancing.
The principle of balancing and goal of keeping a DFD as simple as
possible lead to four additional, advanced rules for drawing DFDs.
o A composite data flow on one level can be split into component
data flows at the next level, but no new data can be added and all
data in the composite must be accounted for in one or more sub
flows.
o The input to a process must be sufficient to produce the outputs
from the process. Thus all outputs can be produced, and all data
in inputs move somewhere, either to another process or to a data
store outside the process or on a more detailed DFD showing a
decomposition of that process.
o At the lowest level of DFDs, new data flows may be added to
represent data that are transmitted under exceptional conditions,
these data flows typically represent error messages or
confirmation notices.
o To avoid having data flow lines cross each other, you may repeat
data store or entities on a DFD. Use an additional symbol, like a
double line on the middle vertical line of a data store symbol, or
a diagonal line in a corner of a entity square, to indicate a
repeated symbol.
Additional guidelines for drawing DFDs

Completeness: It refers to whether the DFDs include all the
components necessary for the system you are modeling. If the DFD
contains data flows that do no lead anywhere, or data store, processes, or
external entities that are not connected to anything else, that DFD is not
complete.
Consistency: It refers to whether or not the depiction of the system
shown at one level of a DFD is compatible with the depictions of the
system shown at other level. A gross violation of consistency would be a
level-1 diagram with no level-0 diagram. Another example of
inconsistency would be a data flow that appears on higher level DFD but
not on lower levels.
Timing considerations: On a given DFD, there is no indication of
whether a data flow occurs at what time and there is also no indication of
when a system would run. When you draw DFDs, then draw them as if
the system you are modeling has never started and will never stop.
The iterative nature of drawing DFDs: Iterative development
recognizes that requirements determination and requirements structuring
are interaction, not sequential, subphases of the analysis phase of the
SDLC. One rule of thumb is that it should take you about three revisions
for each DFD.
Drawing primitive DFDs: The lowest level DFD is the primitive DFD,
one rule is to stop drawing when the lowest logical level is reached. It is
not easy to know what the lowest level is, hence few concrete rules for
when to stop decomposing are
o When you have reduced each processes to a single decision or
calculation or to a single database operation such as retrieve,
update, create or delete.
o When each data store represents data about a single entity, such
as customer, employee, product, or order
o When every data flow does not need to be split further to show
that different data are handled in various ways
o When there is a separate process for each choice on all lowest-
level menu options.
Using Data flow diagramming in the analysis process

Gap Analysis: The process of discovering discrepancies between two or
more sets of data flow diagrams or discrepancies within a single DFD.
DFD can be used for gap analysis. Once DFD is completed, it is
examined for problems like redundant data flows, data that are captured
but not used by the system, and data are updated identically in more than
one location.
6.3 Conceptual Data Modeling (E-R Diagram)

An entity-relationship model, a graphical representation of entities and their
relationships to each other, describes the organization of data within databases or
information systems. An entity is a piece of data—an object or concept about
which data is stored. A relationship is how the data is shared between entities.
ER diagram expresses the overall logical structure of a database graphically.
There are three types of relationships between entities:
One-to-one: one instance of an entity (A) is associated with one other
instance of another entity (B). For example, in a database of employees,
each employee name (A) is associated with only one social security
number (B).
One-to-many: one instance of an entity (A) is associated with zero, one
or many instances of another entity (B), but for one instance of entity B
there is only one instance of entity A. For example, for a company with
all employees working in one building, the building name (A) is
associated with many different employees (B), but those employees all
share the same singular association with entity A.
Many-to-many: one instance of an entity (A) is associated with one,
zero or many instances of another entity (B), and one instance of entity B
is associated with one, zero or many instances of entity A. For example,
for a company in which all of its employees work on multiple projects,
each instance of an employee (A) is associated with many instances of a
project (B), and at the same time, each instance of a project (B) has
multiple employees (A) associated with it.
Developing Entity Relationship Diagrams (ERDs)

£ Entity Relationship Diagrams are a major data modeling tool and will
help organize the data in your project into entities and define the
relationships between the entities.
£ This process has proved to enable the analyst to produce a good database
structure so that the data can be stored and retrieved in a most efficient
manner.
INFORMATION
Entity
£ A data entity is anything real or abstract about which we want to store
data.
£ Entity types fall into five classes: roles, events, locations, tangible things
or concepts. E.g. employee, payment, campus, book. Specific examples
of an entity are called instances. E.g. the employee John Jones, Mary
Smith's payment, etc.
Relationship
£ A data relationship is a natural association that exists between one or
more entities. E.g. Employees process payments.
£ Cardinality defines the number of occurrences of one entity for a single
occurrence of the related entity. E.g. an employee may process many
payments but might not process any payments depending on the nature
of her job.
Attribute
£ A data attribute is a characteristic common to all or most instances of a
particular entity. Synonyms include property, data element, field. E.g.
Name, address, Employee Number, pay rate are all attributes of the
entity employee.
£ An attribute or combination of attributes that uniquely identifies one and
only one instance of an entity is called a primary key or identifier. E.g.
Employee Number is a primary key for Employee.
1. Identify Entities Identify the roles, events, locations, tangible things or

concepts about which the end-users want to store data.
2. Find Find the natural associations between pairs of entities using
Relationships a relationship matrix.
3. Draw Rough ERD Put entities in rectangles and relationships on line segments
connecting the entities.
4. Fill in Cardinality Determine the number of occurrences of one entity for a
single occurrence of the related entity.
5. Define PrimaryIdentify the data attribute(s) that uniquely identify one and
Keys only one occurrence of each entity.
6. Draw Key-Based Eliminate Many-to-Many relationships and include primary
ERD and foreign keys in each entity.
7. Identify Attributes Name the information details (fields) which are essential to
the system under development.
8. Map Attributes For each attribute, match it with exactly one entity that it
describes.
9. Draw fully Adjust the ERD from step 6 to account for entities or
attributed ERD relationships discovered in step 8.
10. Check Results Does the final Entity Relationship Diagram accurately
depict the system data?
AN ENTITY RELATIONSHIP DIAGRAM METHODOLOGY

(One way of doing it)
A SIMPLE EXAMPLE
A company has several departments. Each department has a supervisor and at
least one employee. Employees must be assigned to at least one, but possibly
more departments. At least one employee is assigned to a project, but an
employee may be on vacation and not assigned to any projects. The important
data fields are the names of the departments, projects, supervisors and
employees, as well as the supervisor and employee number and a unique project
number.
1. Identify Entities
The entities in this system are Department, Employee, Supervisor and Project.
One is tempted to make Company an entity, but it is a false entity because it has
only one instance in this problem. True entities must have more than one
instance.
2. Find Relationships
We construct the following Entity Relationship Matrix:
Department Employee Supervisor Project

Department is assigned run by
Employee belongs to works on
Supervisor Runs
Project uses
3. Draw Rough ERD

We connect the entities whenever a relationship is shown in the entity
Relationship Matrix.
Learning Chapter six

6.1 Which of the following is not the part of Entity-Relationship (E-R)
Diagram?
A. Relationship
B. Process
C. Attributes
D. Entity
6.2 Which symbol is wrong representation of data flow in DFD?

A.
B.
C.
D.
6.3 Which symbol is correct representation of process in DFD?
6.4 Which data models are commonly used diagrams that show how data is
organized in a system?
A. DFD (Data Flow Diagram)
B. ER (Entity Relationship) Diagram
C. Both
D. None
6.5 Which one is the example of primary key?

A. Employee name
B. Employee Date of birth
C. Employee ID
D. Employee Department
6.6 The act of going from a single system to more component processes is
called..........................
6.7 Three types of relationships between entities are....................... ,

............................. and ................................
6.8 There are two stages in the structuring process ................................. and
..................................
6.9 One rule is to stop drawing DFD is when the lowest logical level is
reached. This lowest level is known as...........................

6.1 B 6.2 C 6.3 B 6.4 B 6.5 C 6.6 Decomposition 6.7 one to one,
one to many and many to many 6.8 process modeling and conceptual data
modeling 6.9 Primitive DFD
1. Draw a simple Data Flow Diagram (DFD) of your choice which shows
its entire symbol.
2. Draw a level1 DFD diagram for banking process.
3. Draw a rough Entity Relationship diagram for a college.
Chapter VII
System Design
Chapter Objective
System Design and its goal
Logical design and Physical design
Designing effective input, output, database and user interface
Steps of Design Phase
7.1. Systems design

Systems design: The design phase of the lifecycle defines how the finished
information system will operate. This is defined in a design specification of the
best structure for the application and the best methods of data input, output and
user interaction via the user interface. The design specification is based on the
requirements collected at the analysis stage.
The goal of systems design

1. A system is effective if it defined requirements and constraints, accepted by
users, and support the organization‘s business objectives.
2. A system is reliable if it adequately handles errors, input errors, processing
errors, hardware failures, and human mistakes.
3. An approach to building a reliable system is to plan errors, detect them as
early as possible, allow for their correction, and prevent them from damaging the
system.
4. A system is maintainable if it is well designed, flexible, and developed with
future modifications in mind.
5. A system can be modifying because Modification is necessary to correct
problems, to adapt to changing user requirements, to enhance the system, and to
take advantage of changing technology.
Aims of system design

A good-quality information system that:
– is easy to use;
– provides the correct functions for end-users;
– is rapid in retrieving data and moving between different screen
views of the data;
– is reliable;
– is secure;
– is well integrated with other systems.
The design phase is concerned with the physical construction of the system.
Included are the design or configuration of the network (hardware, operating
system, programming, etc.), design of user interfaces (forms, reports, etc.),
design of system interfaces (for communication with other systems), and security
issues. It is important that the proposed design be tested for performance, and to
ensure that it meets the requirements outlined during the analysis phase. In other
words, the main objective of this phase is to transform the previously defined
requirements into a complete and detailed set of specifications which will be
used during the next phase. Some of the activities that need to take place during
the design phase are:
Design the application
Design and integrate the network
Design and integrate the database
Create a contingency plan
Start a Maintenance, Training and Operations plan
Review the design
Articulate the business processes and procedures
Establish a transition strategy
Deliver the System Design Document
Review final design
In the design phase, all inputs, computations and outputs of the system should be
converted into a software model so that it can be coded by programmers. The
hardware requirements are also determined at this stage along with a picture of
the overall system architecture.
7.2 Logical design and Physical design

The logical design of a system pertains to an abstract representation of the data
flows, inputs and outputs of the system. This is often conducted via modeling,
using an over-abstract (and sometimes graphical) model of the actual system. In
the context of systems design are included. Logical design includes ER Diagrams
i.e. Entity Relationship Diagrams. The logical design defines the functions and
features of the system and the relationships among its components. Logical
design has done during the system analysis phase. The logical design defines the
functions and features of the system and the relationships among its components
Logical design includes
Output that must be produced by the system
Input needed by the system
Process that must be performed by the system,
without regard to how tasks will be
accomplished physically
Physical design relates to the actual input and output processes of the system.
This is laid down in terms of how data is input into a system, how it is verified /
authenticated, how it is processed, and how it is displayed as In Physical design;
the following requirements about the system are decided. The physical design of
an information system is a plan for the actual implementation of the system
1. Input requirement,
2. Output requirements,
3. Storage requirements,
4. Processing Requirements,
5. System control and backup or recovery.
The physical design of an information system is a plan for the actual

implementation of the system. The physical design is built on the system‘s
logical design and describes a specific implementation. System design usually
begins after completing system analysis phase. Some overlap is possible, you
might return to fact-finding if you discover that you overlooked an important
issue, if user has significant new needs, or if legal or governmental requirements
change. Physical design, in this context, does not refer to the tangible physical
design of an information system. To use an analogy, a personal computer's
physical design involves input via a keyboard, processing within the CPU, and
output via a monitor, printer, etc. It would not concern the actual layout of the
tangible hardware, which for a PC would be a monitor, CPU, motherboard, hard
drive, modems, video/graphics cards, USB slots, etc. It involves a detailed design
of a user and a product database structure processor and a control processor. The
H/S personal specification is developed for the proposed system.
7.3 Designing effective input, output, database and user interface

7.3.1 Designing Effective Input
Objectives
To choose a cost effective method of input
To achieve the highest possible level of accuracy
To ensure that the input is acceptable to and understood by the user
Input Design Stages

Data Recording
Identify the devices and mechanisms that will be used to enter input
Capture the data as close to the originating source as possible
Use electronic devices and automatic entry whenever possible
Avoid human involvement as much as possible
If the information is available in electronic form anywhere, use it instead
of reentering it
Validate and correct information at the time and location it is entered
Examples of input devices are magnetic card readers, bar code readers,
optical character readers and scanners, touch screens and devices,

electronic pens, digitizers etc.
Data Identification and Conversion
Identify all system inputs, their content and transfer into a computer
recognizable format.
Identify all information flows that cross the system boundary
Data Control (Determine different controls necessary for each system
input)
Actual Input Design (Design and prototype the electronic forms)
Data Transmission (Transmit or transport the data to computer)
Data Validation and Correction (Checking of the input data by the
program at the point of entry and correcting the errors if any)
Example – Application form for college admission, Attendance data for the
employees
Reservation form for ticket booking
Input Media:
Source Document Conversion Devices: These devices convert the input to a
computer acceptable form ex. Punch Card Reader, Key to tape, key to disk, key
to cassette devices.
By- Product Data Capture devices: Capture data in a computer acceptable form
as a byproduct of some essential operation. e.g. Billing machines, Cash register,
Accounting machines.
Direct Data Capture Devices: These devices capture data without any
conversion, for example, Optical mark reader, Magnetic Ink Character Reader,
and so on.
Online Data Entry Devices: Teletype writers, Visual Display Units, Audio
response terminals, light pens, and so on.
7.3.2 Designing Effective Output

Objectives To:
Determine the type of each output
List specific outputs based on application design
Specify necessary controls to protect the information provided in the
output
Design and prototype the report layout
Design based on periodicity and volume of output
Ensure timeliness in delivery
Output Characteristics
An output layout is the arrangement of items on the output medium. A layout is
used as a mockup of the actual report or document as it would appear after the
system is in operation. It shows the location of information. The most important

items should be easy to find. All pages should have a title and page number and
date. Print layout chart should read from left to right and from top to bottom.
Columns are labeled and abbreviations avoided. The output design should take
into consideration-
Physical dimensions of the screen
No of columns and rows
Degree of resolution
Number of colors available
Methods of high-lighting
Methods of intensity control
Output Specification contains all variable information and preprinted
details.
Control Information: Summaries and totals and control breaks are
indicated to emphasize specific points of information.
Types of Output
Tabular: It is recommended to present details when only a few narrative
comments or explanations are needed, when details can be described in discrete
categories or when total and subtotals are appropriate. Certain information in the
tabular formats should visibly stand out:-
Exceptions to normal expectations,
Major categories or groups of activities or entities
Summaries
Unique identification information
Time dependent entities
Tabular formats are often appropriate for accounting information

Graphical: These are used for the display of business information. Graphics are
used:
To improve the effectiveness of output reporting for the targeted
recipient
To manage information volume
To suit personal preferences
Types of Graphs
Pie charts describe portions of a whole associated with a particular
development or activity.
Area charts show change in performance along a scale over multiple
time periods. A horizontal scale indicates time and the vertical scale
measures the units of interest. Several items overlaid on the same chart
enable the reader to compare different items.
Curve chart emphasizes the overall trend in expenditure

Step and Bar charts show changes in categories. They do not connect
individual data points instead they measure data points from the
horizontal scale up to proper level on the vertical scale. In bar charts the
individual periods are discrete and in step chart they are shown side by
side.
Maps effectively show variations across geographical areas.
Icons: They are the pictorial representation of entities described by the data.
Properly selected icons communicate information immediately as they duplicate
images that users are already familiar with. They eliminate the necessity for users
to learn abbreviations, notation or special nomenclature. In contrast taking time
to read labels or footnotes usually contributes to complexity. It can also
substitute for tabular report and are especially useful in showing proportions or
comparisons. Icons are commonly used in computer interfaces to represent
documents, printers etc. One must use the same icon to represent identical
concepts. One must avoid labeling the icons. One should use a layout that
maintains space and avoids overcrowding between icons. Also one should
maintain a common size among different types of symbols.
Types of Reports
Detailed reports (Contain detailed information on business transactions.
A report may be for a single transaction or contain information about e.g.
a particular account)
Summary reports (Often used by middle management to track
departmental or division performance)
Exception reports (Conveys information about any extraordinary event)
Executive reports (Normally used for strategic decisions by top
management)
Internal Vs External Outputs

Printed outputs are classified as internal and external outputs.
Internal output is a printed report or document produced for use inside of the
organization (includes types of reports discussed above). External outputs are
printed documents, like statements, notices, form letters, and legal documents,
produced for use outside of the organization (e.g. bank monthly statements you
get in the mail). Some external outputs are called turn-around documents (they
include a portion that is returned to the system as input, e.g. a bill with a payment
stub you fill out and send back)
7.3.3 Designing Effective Databases

Objectives
Efficient Storage of Data

Efficient Retrieval of Data
Efficient Update of Data
Ensuring Data availability
Ensuring Data Integrity
Structuring the data into stable structures, called normalized tables with
minimum of redundancy
_ Developing logical database design that reflects the actual data
requirements
_ Translate logical design into physical design
High Level Design

The High level design is also called the logical design. It is the design of the
database schema. It involves identifying the data objects to be entered into the
database, grouping them into records and grouping records into sets or tables.
This is done through the process of normalization. Among the data items, the key
that uniquely defines all the data items is chosen as the primary key. The primary
key example in Employee table (Schema) can be Emp_Id (Employee Id)
Low Level Design

Low level design is also known as the physical design. It describes the actual
physical storage / organization of the data in the database i.e. the file structure,
indices and the access paths. It entails choosing the appropriate storage format
for each element from the logical database model. It should ensure minimum
storage space and maximum data quality. The techniques that are used are
partitioning, chaining etc. It should specify the amount and type of secondary
storage and processing speed required for efficient access and retrieval
7.3.4 Designing User Interfaces

User Interfaces comprise the passages, messages, prompts and responses used to
enable a conversation between system and user. It also determines the amount of
information that must pass between system and user. The quality of interface is
important as it guides the interaction between system and user. Awkward design
impedes system usage. The interface strategy determines what information is
entered and how responses are made.
Features of a good interface
Strives for consistency
Enables frequent users to use short cuts
Offers informative feedback
Designs dialogs to yield closure
Offers simple error handling
Permits easy reversal of actions
Interface Types
Menu driven: It presents the system with various alternatives.
Menu Alternatives – The menu choices are presented in single word in keyword
dialogue approach. In some systems pull down menu is used. In pull down
menus, the drop down alternatives are displayed, when the keyword is pointed at
by using the mouse. Nested menu are used when there are extensive set of
alternatives to choose from. A selection from a set of choice leads to a
subsequent decision about other alternatives. Decisions are made in top down
fashion.
Menu Interfaces - Menu dialogues can be designed using many interface devices
such as keyboard, mouse, light pen, touch screens etc.
Menu Placement Strategies -The menu of options can be positioned on the
display screen in several ways. It can be a single column or double column
display as used in transaction processing systems and reporting systems. On the
other hand to facilitate retention of information on the display and at the same
time to offer menu selections to users - the menu can be shown horizontally at
the top or bottom of the screen
Keyword based: User invokes the processing activities by entering a command

that the system understands. Three forms of keyword dialogue are
Single command form- User enters the keyword that the system will associate
with specific commands for certain processes
Mnemonic command form– User enters the abbreviation based on longer phrases
that are later correlated with the actual commands
Natural Language form– The users can instruct the system with less rigid
commands. Instead of conventional command syntax, the users can use their own
vocabulary of words for different operations. It relies on the artificial intelligence
and expert systems technology. The user‘s instructions in natural language are
translated into computer oriented / understandable instructions.
Question Answer based: It relies on the presentation of the question to the user.
The answer guides the resultant processing. It has two formats
_ Yes / No answers
_ Narrative responses: This strategy allows for presentations of more
elaborate questions and alternatives than do the other strategies. It
requires the analyst to anticipate every possible answer a user may
provide for a difficult task. The analyst should take care to minimize the
number of words used to speed user-system interaction and to avoid
possible errors.
Based on the design specifications, the software and hardware selection and
acquisition is made and eventually actual program development takes place.
7.4 Steps of Design Phase

The design phase decides 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.
Although most of the strategic decisions about the system were made in the
development of the system concept during the analysis phase, the steps in the
design phase determine exactly how the system will operate. The design phase
has four steps:
1. The design strategy must be developed. This clarifies whether the system
will be developed by the company‘s own programmers, whether it will
be outsourced to another firm (usually a consulting firm), or whether the
company will buy an existing software package.
2. This leads to the development of the basic architecture design for the
system that describes the hardware, software, and network infrastructure
that will be used. In most cases, the system will add or change the
infrastructure that already exists in the organization. The interface design
specifies how the users will move through the system (e.g., navigation
methods such as menus and on-screen buttons) and the forms and reports
that the system will use.
3. The database and file specifications are developed. These define exactly
what data will be stored and where they will be stored.
4. The analyst team develops the program design, which defines the
programs that need to be written and exactly what each program will do.
This collection of deliverables (architecture design, interface design,
database and file specifications, and program design) is the system
specification that is handed to the programming team for
implementation. At the end of the design phase, the feasibility analysis
and project plan are reexamined and revised, and another decision is
made by the project sponsor and approval committee about whether to
terminate the project or continue.
Learning chapter Seven

7.1 Designing of chart, table, graph and icon are the part of
A. Input Design
B. Output Design
C. Database Design
D. User Interface Design
7.2 Which type of Design is usually done into the analysis part of System
Development?
A. Physical Design
B. Logical Design
C. Both
D. None
7.3 Which design defines the functions and features of the system and the
relationships among its components?
A. Physical Design
B. Logical Design
C. Both
D. None
7.4 Which one is the part of physical design for the system?
A. Input requirement,
B. Output requirements,
C. Storage requirements,
D. Processing Requirements,
E. System control and backup or recovery.
F. All
7.5 Which one of the following is not the example of Input Media?
A. Optical mark reader
B. Magnetic Ink Character Reader,
C. Light Pens
D. All
E. None
7.6 Two phases of design are.......................... And..............................
7.7 The person who is coding the design into computer understandable
language is...........................
7.8 When systems are developed by external organisation it is known

as.....................
Key to objective questions
7.1 B 7.2 B 7.3 B 7.4 F 7.5 E 7.6 Logical and Physical design 7.7
Programmer 7.8 Outsourcing
1. What are the different objectives and goals of the design phase of System
Development Life Cycle?
2. Write down about the major consideration for user interface design.
3. Discuss the four major steps of Design phase.
Chapter VIII
Systems Implementation
Chapter objective
The Processes of Coding
System Testing
System Installation
Post implementation review
Systems maintenance
Bug-fixing, Enhancements
The objective of Systems Implementation phase is to convert the final physical

system specifications into working and reliable software and hardware, document
the work that has been done, and provide help for current and future users and
caretakers of the system.
8.1 The Processes of Coding

The system design needs to be implemented to make it a workable system. This
demands the coding of design into computer understandable language, i.e.,
programming language. This is also called the programming phase in which the
programmer converts the program specifications into computer instructions,
which we refer to as programs. It is an important stage where the defined
procedures are transformed into control specifications by the help of a computer
language. The programs coordinate the data movements and control the entire
process in a system. It is generally felt that the programs must be modular in
nature. This helps in fast development, maintenance and future changes, if
required.
The detailed specifications produced during the design phase are translated into
hardware, communications, and executable software. The design must be
translated into a machine-readable form. The code generation step performs this
task. If the design is performed in a detailed manner, code generation can be
accomplished without much complication. Different high level programming
languages are used for coding. With respect to the type of application, the right
programming language is chosen. Depending on the size and complexity of the
system, coding can be an involved, intensive activity. Once coding is begun, the
testing process can begin and proceed in parallel. As each program module is
produced, it can be tested individually, then as a part of a larger program, and
then as part of larger system. The deliverables and outcome from the coding are
the code and program documentation.
8.2 Software Testing

Before actually implementing the new system into operation, a test run of the
system is done for removing the bugs, if any. It is an important phase of a
successful system. After codifying the whole programs of the system, a test plan
should be developed and run on a given set of test data. The output of the test run
should match the expected results. Sometimes, system testing is considered a part
of implementation process. Software Testing is the process of executing a
program or system with the intent of finding errors. Or, it involves any activity
aimed at evaluating an attribute or capability of a program or system and
determining that it meets its required results. Testing is more than just
debugging. The purpose of testing can be quality assurance, verification and
validation, or reliability estimation. Testing is an integral part in software
development. It is broadly deployed in every phase in the software development
cycle. Typically, more than 50% percent of the development time is spent in
testing.
Software testing can be divided into: Correctness testing, Performance

testing, Reliability testing and Security testing.
Correctness testing
Correctness is the minimum requirement of software, the essential purpose of
testing. Correctness testing will need some type of vision, to tell the right
behavior from the wrong one. The tester may or may not know the inside details
of the software module under test, e.g. control flow, data flow, etc. Therefore,
either a white-box point of view or black-box point of view can be taken in
testing software.
Black-box testing
The black-box approach is a testing method in which test data are
derived from the specified functional requirements without regard to the
final program structure. It is also termed data-driven, input/output driven
or requirements-based testing.
White-box testing
Contrary to black-box testing, software is viewed as a white-box, or
glass-box in white-box testing, as the structure and flow of the software
under test are visible to the tester. Testing plans are made according to
the details of the software implementation, such as programming
language, logic, and styles. Test cases are derived from the program
structure.
Performance testing
Performance has always been a great concern and a driving force of computer
evolution. Performance evaluation of a software system usually includes:
resource usage, throughput, and stimulus-response time and queue lengths
detailing the average or maximum number of tasks waiting to be serviced by
selected resources. Typical resources that need to be considered include network

bandwidth requirements, CPU cycles, disk space, disk access operations, and
memory usage.
Reliability testing
Software reliability refers to the probability of failure-free operation of a system.
It is related to many aspects of software, including the testing process. Directly
estimating software reliability by quantifying its related factors can be difficult.
Testing is an effective sampling method to measure software reliability. The
robustness of a software component is the degree to which it can function
correctly in the presence of exceptional inputs or stressful environmental
conditions.
Stress testing, or load testing, is often used to test the whole system
rather than the software alone. In such tests the software or system are
exercised with or beyond the specified limits. Typical stress includes
resource exhaustion, bursts of activities, and sustained high loads.
Security testing
Software quality, reliability and security are tightly coupled. Flaws in software
can be exploited by intruders to open security holes. With the development of the
Internet, software security problems are becoming even more severe. Many
critical software applications and services have integrated security measures
against malicious attacks. The purpose of security testing of these systems
include identifying and removing software flaws that may potentially lead to
security violations, and validating the effectiveness of security measures.
Simulated security attacks can be performed to find vulnerabilities.
By scope, software testing can be categorized as follows: Unit testing,

Integration testing, System testing, Acceptance testing.
Unit testing
Each module or unit or component is tested alone in an attempt to discover any
errors that may exist in the code.
Integration Tests
The process of bringing together all of the modules that a program comprises for
testing purposes. Modules are typically integrated in a top-down, incremental
fashion.
Subsystem/System Testing
It is the bringing together of all the programs that a system comprises for testing
purposes. All results should be documented on the Test Analysis Report, Test
Problem Report and on the Test Analysis Approval Determination. Any failed
components should be migrated back to the development phase for rework, and
the passed components should be migrated ahead for security testing.
Acceptance Testing
It is the process whereby actual users test a completed information system. The
end result of which is the users acceptance of it.
When to stop testing?

Testing is potentially endless. We cannot test till all the defects are unearthed and
removed -- it is simply impossible. At some point, we have to stop testing and
ship the software. The question is when. Realistically, testing is a trade-off
between budget, time and quality. It is driven by profit models. The pessimistic
and unfortunately most often used approach is to stop testing whenever some or
any of the allocated resources -- time, budget, or test cases -- are exhausted. The
optimistic stopping rule is to stop testing when either reliability meets the
requirement, or the benefit from continuing testing cannot justify the testing cost.
8.3 Installation
After having the user acceptance of the new system developed, the
implementation phase begins. Implementation is the stage of a project during
which theory is turned into practice. The major steps involved in this phase are:
1. Acquisition and Installation of Hardware and Software
2. Conversion
3. User Training
4. Documentation
1. Acquisition and Installation of Hardware and Software

The hardware and the relevant software required for running the system must be
made fully operational before implementation. Install the software product in the
target environment as designed and in accordance with the Installation Plan. The
resources and information necessary to install the software product shall be
determined and be available. The developer shall assist the acquirer with the set-
up activities. Where the installed software product is replacing an existing
system, the developer shall support any parallel running activities that are
required. Ensure that the software code and databases initialize, execute, and
terminate as specified in the contract. The installation events and results shall be
documented.
2. Conversion
The conversion is also one of the most critical and expensive activities in the
system development life cycle. The data from the old system needs to be
converted to operate in the new format of the new system. The database needs to
be setup with security and recovery procedures fully defined. With the
implementation of any system, typically there is old data which is to be included
in the new system. This data can be in a manual or an automated form.

Regardless of the format of the data, the tasks in this section are twofold, data
input and data verification.
When replacing a manual system, hard copy data will need to be entered into the
automated system. Some sort of verification that the data is being entered
correctly should be conducted throughout this process. This is also the case in
data transfer, where data fields in the old system may have been entered
inconsistently and therefore affect the integrity of the new database. Verification
of the old data becomes imperative to a useful computer system. One of the ways
verification of both system operation and data integrity can be accomplished is
through parallel operations. A parallel operation consists of running the old
process or system and the new system simultaneously until the new system is
certified. In this way if the new system fails in any way, the operation can
proceed on the old system while the bugs are worked out.
3. User Training
During this phase, all the programs of the system are loaded onto the user‘s
computer. After loading the system, training of the user starts. Main topics of
such type of training are:
How to execute the package
How to enter the data
How to process the data (processing details)
How to take out the reports
It is always a good business practice to provide training before the end user uses
the new system. Because there has been a previously designed training plan
established, complete with the system user manual, the execution of the plan
should be relatively simple. Typically what prevents a plan from being
implemented is lack of funding. Good budgeting should prevent this from
happening.
After the users are trained about the computerized system, working has to shift
from manual to computerized working. The process is called ‗Changeover‘. The
following strategies are followed for changeover of the system.
(i) Direct Changeover: This is the complete replacement of the old system
by the new system. It is a risky approach and requires comprehensive
system testing and training.
(ii) Parallel run: In parallel run both the systems, i.e., computerized and
manual, are executed simultaneously for certain defined period. The
same data is processed by both the systems. This strategy is less risky but
more expensive because of the following:
Manual results can be compared with the results of the computerized
system.
The operational work is doubled.
Failure of the computerized system at the early stage does not affect the
working of the organization, because the manual system continues to
work, as it used to do.
(iii) Pilot run: In this type of run, the new system is run with the data from
one or more of the previous periods for the whole or part of the system. The
results are compared with the old system results. It is less expensive and
risky than parallel run approach. This strategy builds the confidence and the
errors are traced easily without affecting the operations.
4. Documenting the system

The documentation of the system is also one of the most important activities in
the system development life cycle. This ensures the continuity of the system.
There are generally two types of documentation prepared for any system. These
are:
User or Operator Documentation
System Documentation
The user documentation is a complete description of the system from the users‘
point of view detailing how to use or operate the system. It also includes the
major error messages likely to be encountered by the users. The system
documentation contains the details of system design, programs, their coding,
system flow, data dictionary, process description, etc. This helps to understand
the system and permit changes to be made in the existing system to satisfy new
user needs
System documentation is detailed information about a system‘s design
specifications, its internal workings, and its functionality. It is meant for
maintenance programmers. It is further divided into internal and external
documentation. Internal documentation is part of the program source code or is
generated at compile time. External documentation includes the outcome of all of
the structured diagramming techniques such as DFD and ERD.
User documentation is written or visual information about an application
system, how it works and how to use it. The kinds of user documents are
reference guide, user‘s guide, release description, system administrator‘s guide
and acceptance sign-off. The reference guide consists of exhaustive list of the
system‘s functions and commands usually in alphabetical order. The purpose of
the reference guide is to provide information on how users can use computer
systems to perform specific tasks. The information in user‘s guide is typically
ordered by how often tasks are performed and how complex they are. The release
description contains information about a new system release, including a list of
complete documentation for the new release, features and enhancements, known
problems and how they have been dealt with in the new release and information
about installation. The systems administrator‘s guide is intended to those who
will install and administer a new system and contains information about the
network on which the system will run, software interfaces for peripherals such as
printers, trouble shooting, and setting up user accounts. The acceptance sign-off
allows users to test for proper system installation and then signify their
acceptance of the new system and its documentation with their signatures.
8.4 Post implementation review

After the system has been fielded a post-implementation review is conducted to
determine the success of the project through its implementation phase. The
purpose of this review is to document implementation experiences to recommend
system enhancements and provide guidance for future projects.
The Post-Implementation Review is used to evaluate the effectiveness of
the system development after the system has been in production for a
period of time (normally 6 months).
The objectives are to determine if the system does what it is designed to
do: Does it support the user as required in an effective and efficient
manner? The review should assess how successful the system is in terms
of functionality, performance, and cost versus benefits, as well as assess
the effectiveness of the life-cycle development activities that produced
the system. The review results can be used to strengthen the system as
well as system development procedures.
The review is scheduled to follow the release of a system or system
revision by an appropriate amount of time to allow determination of the
effectiveness of the system. A representative from the functional
development group or other member of the major user organization
participates in the review.
The System Proponent ensures that all documentation and all personnel
needed to participate in the review are accessible.
The reviewer and an assigned team collect the information needed for
the Post-Implementation Review by interviewing end users and their
managers, system administrators, and computer operations personnel.
The report is then prepared and provided to the user organization that
requested it and the information systems organization, which may jointly
use the findings to initiate other actions.
The Post-Implementation Review is a free-form report, and not all
sections are relevant or necessary to the final product.
8.5 Systems maintenance

Maintenance is necessary to eliminate errors in the system during its working life
and to tune the system to any variations in its working environments. It has been
seen that there are always some errors found in the systems that must be noted
and corrected. It also means the review of the system from time to time. The
review of the system is done for:
knowing the full capabilities of the system

knowing the required changes or the additional requirements
Studying the performance.
If a major change to a system is needed, a new project may have to be set up to

carry out the change. The new project will then proceed through all the above life
cycle phases.
Systems Operations
Operations support is an integral part of the day to day operations of a
system. In small systems, all or part of each task may be done by the
same person. But in large systems, each function may be done by
separate individuals or even separate areas. The Operations Manual is
developed in previous SDLC phases. This document defines tasks,
activities and responsible parties and will need to be updated as changes
occur.
Systems operations activities and tasks need to be scheduled, on a
recurring basis, to ensure that the production environment is fully
functional and is performing as specified. The following is a checklist of
systems operations key tasks and activities:
o Ensure that systems and networks are running and available
during the defined hours of Operations;
o Implement non-emergency requests during scheduled Outages,
as prescribed in the Operations Manual;
o Acquisition and storage of supplies (i.e. paper, toner, tapes,
removable disk);
o Perform backups (day-to-day protection, contingency);
o Perform the physical security functions including ensuring
adequate UPS, Personnel have proper security clearances and
proper access privileges etc.;
o Ensure contingency planning for disaster recovery is current and
tested ;
o Ensure users are trained on current processes and new processes;
o Maintain performance measurements, statistics, and system logs.
Examples of performance measures include volume and
frequency of data to be processed in each mode, order and type
of operations;
Data / Software Administration

Data / Software Administration is needed to ensure that input data and
output data and data bases are correct and continually checked for
accuracy and completeness.
The backup and recovery processes for data bases are normally different
than the day-to-day volume backups. The backup and recovery process
of the data bases should be done as a Data / Software Administration
task by a data administrator.
A checklist of Data / Software Administration tasks and activities are:
o Performing a periodic Verification / Validation of data, correct
data related problems
o Installing, configuring, upgrading and maintaining data base(s).
This includes updating processes, data flows, and objects
o Developing and performing data / data base backup and recovery
routines for data integrity and recoverability.
o Developing and maintaining a performance and tuning plan for
online process and data bases.
8.6 Bug-fixing and Enhancements

Identify Problem and Modification Process
One fact of life with any system is that change is inevitable. Users need an
avenue to suggest change and identified problems. A User Satisfaction Review
which can include a Customer Satisfaction Survey can be designed and
distributed to obtain feedback on operational systems to help determine if the
systems are accurate and reliable. Systems administrators and operators need to
be able to make recommendations for upgrade of hardware, architecture and
streamlining processes. Daily operations of the system /software may necessitate
that maintenance personnel identify potential modifications needed to ensure that
the system continues to operate as intended and produces quality data.
Daily maintenance activities for the system, takes place to ensure that any
previously undetected errors are fixed. Maintenance personnel may determine
that modifications to the system and databases are needed to resolve errors or
performance problems. Also modifications may be needed to provide new
capabilities or to take advantage of hardware upgrades or new releases of system
software and application software used to operate the system. New capabilities
may take the form of routine maintenance or may constitute enhancements to the
system or database as a response to user requests for new/improved capabilities.
New capabilities needs may begin a new problem modification process described
above.
8.1 Which of the following is not a computer language?

A. HTML
B. Oracle
C. Ms-Office
D. Visual Basic
8.2 Which of the following is necessary to eliminate errors in the system

during its working life and to tune the system to any variations in its
working environments?
A. Coding
B. Maintenance
C. Training
D. All
8.3 This is also called the programming phase in which the programmer
converts the program specifications into computer instructions
A. Coding
B. Maintenance
C. Training
D. Implementation
8.4 White box testing and black box testing is the part of
A. Correctness testing
B. Performance testing
C. Reliability testing
D. Security testing.
8.5 This changeover is most risky approach and requires comprehensive

system testing and training
A. Direct changeover
B. Parallel run
C. Pilot run
D. All
8.6. The users are trained about the computerized system; working has to
shift from manual to computerized working. The process is
called.................................
8.7 ........................... means the review of the system from time to time
8.8 There are generally two types of documentation prepared for any
system. These are..................................and...........................................

8.1 C 8.2 B 8.3 A 8.4 A 8.5 A 8.6 Changeover 8.7 Maintenance
8.8 User Documentation and System Documentation

1. Write the major steps involved in implementation.
2. Discuss the different types of software testing.
3. What is post implementation review and why it is so important?

System Analysis and Design

Uploaded by

Copyright:

Available Formats

System Analysis and Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Analysis and Design

Uploaded by

Copyright:

Available Formats

uuuu

System Analysis and Design

2.4 Use of project management software 23

3.5 Traditional Waterfall SDLC 37

5.4 Modern methods for gathering requirements 62

7.4 Steps of Design Phase 91

1. Davis, William S. Management, information and systems: An

1.1 Data and Information

1.2 Types of information: Operational, tactical, strategic, and Statutory

Example of operational information needed by a shopkeeper

Example of tactical information needed by a shopkeeper

Example of strategic information needed by a shopkeeper

Example of statutory information needed by a shopkeeper

1.3 Functional Allocation of Management

Middle level mangers direct and control the functioning of organization to

A. Types of information for production management

B. Types of information for Marketing Management

5) Effect of model changes.

C. Types of information for Material Management

D Types of information for Finance Management

E. Types of information for Human Resource Management

1.4 System Concept

A System is an interrelated set of business procedures (or components) used

subsystems may be inputs to other subsystems.

Each of these subsystems is composed of sub-sub --systems. Engine system:

Fig 1.1- Restaurant system

1.5 System Analysis and Design (SAD)

1.5.1 Introduction to Information System

The Information System includes the following

Fig 1.2 Components of information system

1.5.2 Types of Information Systems

Transaction Processing Systems (TPS)

Management Information System (MIS)

Decision support System (DSS)

Expert Systems (ES)

Figure-1.4: Types of Information Systems

1.5.3 Some important Systems concepts

(C) Processed correctly

1.2. Strategic information is needed for

1.3 Strategic information is required by

1.4 In motor car manufacturing the following type of information is

1.5 In a hospital, information system the following type of information is

1.6 In a hospital, information system the following type of information is

1.7 Volume of tactical information is

1.8 Volume of operational information is

1.9 Decision support systems are essential for

1.10 A computer based information system is needed because

Key to Objective Questions

Information Systems Development Project

2.1 Managing Information System Project

Where do projects come from?

Project manager is an individual with a diverse set of skills who is responsible

Skills of project manager: They include

• Skills needed by a project manager go beyond just building a system

2.2 Information Systems Project Phase

Figure 2.1: Phases of Project management

Project management is the controlled process of initiating, planning, executing

Phase 1: Project initiation

Phase-1: project initiation activities

2. Establishing relationship with the customer