SYSTEM ANALYSIS Notes

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 41

1

SYSTEM ANALYSIS AND DESIGN

SYSTEM ANALYSIS: It is a process of collecting and interpreting facts, identifying the problems,
and decomposition of a system into its components. System analysis is conducted for the
purpose of studying a system or its parts in order to identify its objectives.
It is a problem solving technique that improves the system and ensures that all the components of
the system work efficiently to accomplish their purpose.
Analysis specifies what the system should do.

Introduction
What is a System?
Is a group of related interacting components, which work together to achieve a desired
purpose or a set of objectives. The system takes inputs, performs processing of goods or
data to give some desired outputs.

Sometimes there may be control element for the processing to give some desired level of output
and avoid or reduce effect the interaction with the environment.
A typical system is shown in fig.1.1

A system has the following features or characteristics:


1. Purpose: Set of objectives to fulfill
2. Components and subsystems: Perform some functions
3. Boundary : Define what is inside and outside the system and is not of interest or
scope of the system.
4. Environment : Other systems outside the boundary
5. Interacts with environment : Gets inputs and outputs to and from environment
6. Control : Compares the output with desired objectives such as profit margin, or
rate of output./

Subsystem
Subsystem A A Subsy
stem
B
Inputs outputs

Boundaries and
interface
2

fig.1.1
Purpose
Created to achieve a desired set of objectives for the organization or company.
Some typical quantified objectives are:
 Increase company productivity by 50% in the next two years
 Reduce the wastage by 20%
 Reduce time taken to process one hundred certificates to one day.
 Serve customers in a more efficient manner: serve 30 customers in one hour from the
current 20 customers per hour
 Maximize profits by 20%

Components
Components together make up the system with each component having its own characteristics
but interacts, through an interface, with other computers.

Subsystems
A subsystem is a system which is a part of a bigger system and which performs a specific
function. Subsystems may consist f several components. The components for a particular
subsystem perform a specific task. Human body breathing blood circulation, and sensory
subsystems.
Subsystems communicate with other subsystems. Subsystems help to reduce complexity of a
system and enhance understand of components and system characteristics or functional
requirements. It should be noted that good system is made up of independent subsystems with
minimum which can be quality checked to reduce errors

Boundary
Defines the components, which are within and outside the system, but interacts with the system
and can affect the system. It defines the limit of the system since it is related to other systems in
the environment.

Environment
The system boundary defines the limits of the system beyond which it is not concerned. It
however has an interface to the environment to get information and give information. For
example, a payroll system is affected by the income tax laws in a country and should be changed
to reflect the required income tax deductions using the given formulae for calculating the tax.
The system gives out the environment the tax remittance.

Interaction
3

Is the passing of messages to one component or sub-system another that each can understand.
For example the braking of a car passes a signal from the braking sub-system to the electrical
sub-system and the mechanical sub-system to stop the car.

Feedback
Monitors the output to check that it conforms to the expected goals and objectives. Variations
from the goals or output are fed back to the system in order to adjust the system towards the set
goals.

Components of System
The components or elements of a system as opposed to its features are the physical parts that
comprise the system. These are:

An IS can be represented diagrammatically as having the following elements.

Data
Input Processes Information

--Output
--Reports

Storage

Input: Are the devices and process of feeding the system with the necessary data to be recorded
and or processed by the system
Data: The raw materials to be processed. The data is recorded and maintained in an appropriate
format for processing purposes
Processing systems: Consisting of components and subsystems that perform the processing of
data. It transforms input data to output data
Output: Are the devices and product that come from the processing of data. The expected
outputs that can be used to monitor performance or get information about the system. Some of
the outputs may be in the form of standard reports used for different purposes.
Feedback: The control elements that take part of the output data and combine it with the input to
provide better control of the output.
4

Types of systems.

a) Deterministic systems.

A system that functions according to some predetermined procedures, and hence their future
behavior can be predicted accurately depending on the situation events.

For the future to be predicted accurately, the current state of affairs and the operation behavior or
properties is precisely known. E.g. behavior of a planet in orbit, a computer program.

b) Probabilistic system.

They operate on probability i.e. chance events hence their future behavior cannot be predicted
definitely e.g. social systems.

An information system is both deterministic and probabilistic system.

Deterministic – on the assumption that definite information is expected from the input data,
worked upon according to some predetermined miles, in form of input instruction.

Probabilistic – the expected output from the information. System may be unexpected
composition, due to the fact that the variations in the type of input introduce a variety of
uncertainties.

c) Cybernetic systems

Are systems that have to adapt to their environments for their survival.

Are also described as adoptive or self-organizing, self-monitoring self-regulating systems.

e.g. organizations, human, plants etc.

d) Closed and open systems

Closed systems: A system that does not interact with its event. It does not communicate from
(no inputs) or to no outputs its environment.

Are more relevant scientific than social systems.

Open system: A system, which communicates with its event. E.g. Business and information
systems.
5

They get disorganized and therefore should be regulated.

The process where a system is regulated is known as negative feedback.

The systems concept is made more useful by the inclusions of

i. Feedback: data about performance of a system.


ii. Control: System that monitors and evaluates feedback to determine whether the
system is moving toward the achievement of the goal.

NB

 A system performing properly generates positive feedback, which signals the control
function to maintain the systems current course toward its goal.
 A system whose performance is deteriorating deviating from the attainment of it goal
generates negative feedback.

Entropy: Characteristic where performance of most system tends to deteriorate over time
also known as tendency of a system to lose its homeostasis.

Approaches to information systems.

There are major disciplines that contribute problems, issues, and solutions in the study of IS the
field can be divided into: -

(i) Technical approach

(ii) Behavioral approach

IS are social technical systems. Through composed of machines, devices and "hard" physical
technology, they require social, organizational and intellectual instruments to make them work
properly.

Technical approach.

Emphasizes mathematically based, normative models to study information systems, as well as


the physical technology and formal capabilities of these systems.

Disciplines that contribute to the technical approach are: -

Computer Science – establishing theories of compatibility, method of computation and methods


of efficient data storage and access.
6

Management Science – emphasizes the development of models for decision-making and


management practices.

Operations Research- focus on mathematical techniques for optimizing selected parameters of


organizations e.g. transportation, inventory control and transaction costs.

Behavioral approach
Part of IS field is concerned with behavior problems and issues e.g. System utilization,
implementation creative design which cannot the expressed with the e normative models used in
technical approach.

Behavioral disciplines play part (role).

Sociology focus on impact of IS on groups, organizations and society.

Political science investigate the political impacts and uses of IS.

Psychology is concerned with individual responses to IS and cognitive models of human


reasoning.

The study of MIS arose in the 1960s to focus on computer-based IS (CBIS) aimed at managers.
MIS combines the theoretical work of computer science management sciences and OR with
practical orientation towards building systems and applications.

It also pays attention to behavioral issues.

MI
S

Compute Operation

Science Research

Mgt

Science Sociology

Social-technical systems.
7

A social-technical systems perspective helps to avoid a purely technical approach to IS. E.g. the
fact that IS is rapidly declining cost and growing in power does not necessarily translate into
productivity enhancement or bottom-line profits.

Technology must be changed and designed in such a way as to fit organizational and individual
needs. Sometimes technology must be de-optimized must accomplish this.

Organizations and individuals must also be changed through training, learning and planned
organizational change in order to allow the technology to operate and proper.

The performance of system is optimized when both technology and the organization mutually
adjust to one another until a satisfactory fit is obtained.

Kinds of systems.

There are 4 main kinds of IS that serve different organizational levels.

a) Operational level systems.

IS monitoring the elementary activities and transactions of the organization. E.g. Sales,
receipts, cash deposits, payroll credit decision, flow of materials in a factory.

b) Knowledge level systems.

IS that support knowledge and data workers in an organization. Their purpose is to help
the business firm interpret new knowledge into the business and to help the organization
control the flow of paperwork.

c) Management level systems.

Systems designed to serve the monitoring controlling decision-making and administrative


activities of middle managers.

They address the question: Are things working well?

They compare the current day's output with that of a month or a year ago.

They produce periodic report rather than instant information on operations.

Other management level systems tend to focus on less structured decisions for which
information requirement are not always clear. They answer what if questions. e.g. what
would be the impact on production schedule if we were to double sales in the month of
December.

d) Strategic level Systems


8

They help senior management tackle and address strategies issues and long-term trends,
both in the firm and i.e. the external event.

Principal concern is matching changes in external environment with existing


organizational capacity. E.g. what will employment level be in 5 years, what are the long
term industry cost trends.

NB

IS may also be differential by functional specialty major original functions e.g. sales
marketing, manufacturing finance, accounting and human resources are each served by
their own IS.

Sub-functions in an organization may also have their on IS e.g. in manufacturing there


may be systems for inventory management. Process control plant maintenance, computer
aided engineering and material requirements planning. be systems for inventory
management.

Major types of systems: -


IS can be classified based on organisational level they serve.

 Executive support systems (ESS) at strategic level.


 Management Information Systems (MIS) and Decision Support Systems (DSS) at
management level.
 Knowledge work systems (KWS) and office automation systems (OAS) at knowledge
level.
 Transaction processing systems (TPS) operational level.
 Systems at each level in turn are specialized to serve each of the major functional areas.
1. Transaction processing system (TPS)
A TPS collects and stores information about transactions, and controls some aspects of
transactions. A transaction is an event of interest to the organisation. E.g. a sale at a store.
A TPS is a basic Business System. It
 Serves the most elementary day-to-day activities of an organisation;
 Supports the operational level of the business;
 Supplies data for higher-level management decisions.
 Is often critical to survival of the organisation
 Mostly for predefined, structured tasks
 Can have strategic consequences (eg airline reservation system)
 Usually has high volumes of input and output
 Provides data which is summarised into information by systems used by higher levels of
management
 Need to be fault-tolerant.
9

On-line transaction processing: A transaction processing mode in which transactions entered on-
line are immediately processed by the CPU.
Sub-species of TPS:
2. Office automation system (OAS)
OAS provides individuals effective ways to process personal and organisational data, perform
calculations, and create documents.
e.g. word processing, spreadsheets, file managers, personalcalendars, presentation packages For
are used for increasing personal productivity. They reduce “paper warfare”. OAS software tools
are often integrated (e.g. Word processor can import a graph from a spreadsheet) and designed
for easy operation.

OAS Subspecies
Communication systems: helps people work together by sharing information in many different
formsTeleconferencing (including audioconferencing, computer conferencing,
videoconferencing), electronic mail, voice mail, fax
Groupware system: helps teams work together by providing access to team data, structuring
communication, and making it easier to schedule meetings. For sharing information, controlling
work flows, communication/integration of work
3. Management information system (MIS)
converts TPS data into information for monitoring performance and managing an organisation.
Transactions recorded in a TPS are analyzed and reported by an MIS.
They have large quantities of input data and they produce summary reports as output. Used by
middle managers. An example is an annual budgeting system.
4. Executive information system (EIS)
Also known as an Executive Support System (ESS), it provides executives information in a
readily accessible, interactive format. They are an MIS for executive use. An EIS/ESS usually
allows summary over the entire organisation and also allows drilling down to specific levels of
detail.
Used by top level (strategic) management. They are designed to the individual. They let the CEO
of an organisation tie in to all levels of the organisation. They are very expensive to run and
require extensive staff support to operate.

5. Decision support system (DSS)


helps strategic management staff (often senior managers) make decisions by providing
information, models, or analysis tools. For support of semistructured and unstructured decisions
(structured decisions can be automated). Used for analytical work, rather than general office
support.
They are flexible, adaptable and quick. The user controls inputs and outputs. They support the
decision process and often are sophisticated modelling tools so managers can make simulations
and predictions.
Their inputs are aggregate data, and they produce projections.
6.Knowledge Work Systems (Kws) are used by technical staff. KWS use modelling functions to convert
design specifications into graphical designs. They may include computer-aided design/ manufacture
(CAD/CAM).
Stakeholders: Players in the Systems Game
• A stakeholder is any person who has an interest in an existing or proposed information
system. Stakeholders can be technical or nontechnical workers. They may also include
both internal and external workers.
• Information workers are those workers whose jobs involve the creation, collection,
processing, distribution, and use of information.
• Knowledge workers are a subset of information workers whose responsibilities are
based on a specialized body of knowledge.
• System owners – an information system’s sponsor and executive advocate, usually
responsible for funding the project of developing, operating, and maintaining the
information system.

• System users – a “customer” who will use or is affected by an information system on a


regular basis – capturing, validating, entering, responding to, storing, and exchanging
data and information.

Other Stakeholders

External Service Provider (ESP) – a systems analyst, system designer, or system builder
who sells his or her expertise and experience to other businesses to help those businesses
purchase, develop, or integrate their information systems solutions; may be affiliated with a
consulting or services organization.

Project Manager – an experienced professional who accepts responsibility for planning,


monitoring, and controlling projects with respect to schedule, budget, deliverables, customer
satisfaction, technical standards, and system quality.

Internal System Users


• Clerical and service workers
• Technical and professional staff
• Supervisors, middle managers, and executive managers

External System Users


• Customers
• Suppliers
• Partners
• Employees
• Remote users - users who are not physically located on the premises but who still
requires access to information systems.
• Mobile users - users whose location is constantly changing but who requires
access to information systems from any location
System Designers and System Builders
System designer – a technical specialist who translates system users’ business requirements and
constraints into technical solution. She or he designs the computer databases, inputs, outputs,
screens, networks, and software that will meet the system users’ requirements.
System builders – a technical specialist who constructs information systems and components
based on the design specifications generated by the system designers.

Steps in building a system


a) Analysis-Conceptualization and formalization of problem to be solved:-concept, analysis,
user requirements, requirement specifications.
b) Design-Actualization of the system
-Design method and techniques
-Management process-provides facilities that require for development teams.
c) Coding-Translation of the design into software programs using the the required software.
d) Testing-Is execution of the coded programs using the required software
e) Implementation-Translating the tested programs onto the final software and hardware
machines and physical environment.
A good design uses suitable design methods that allow design to communicate with the client
and the programmer, who generate the final source code. Note that there will be some details that
may not be captured exactly the same way the client desired since this depends on both the client
and designer.

Characteristics of good system


Good system-User friendly to users
-Meets the desired organization goals and quality
-Meets users requirement
-Economical
People involved in developing software system
System analyst: coordinates the development team and users
Development team-Translates user organization requirement into a system that fulfils the
intended goals.
Management-Which guides the strategic objective of the organization and organization policy on
functions and relation.
Users- Use the system carries out tasks, responsibilities in the organization
Systems Analysts

Systems analyst – a specialist who studies the problems and needs of an organization to
determine how people, data, processes, and information technology can best accomplish
improvements for the business.
• A programmer/analyst (or analyst/programmer) includes the responsibilities
of both the computer programmer and the systems analyst.
A business analyst focuses on only the non-technical aspects of systems analysis and design

The Systems Analyst as a Problem-Solver


• By "Problems" that need solving, we mean:

• Problems, either real or anticipated, that require corrective action


• Opportunities to improve a situation despite the absence of complaints
• Directives to change a situation regardless of whether anyone has complained
about the current situation
The Role of system Analyst

The system analysts have strategic position in the creating and use information resource in an
organization. Some of the roles are discussed here below:

Work of a system analyst

The work of a system analyst is to develop a new system that will operate effectively, efficiently
and economically and at the same time meet the user and management requirements. The tasks
in system analysis are:

1 Investigate how the current system operates and its problems and advantages
2 Analyse the performance of the current system with reference to organization goals
and objectives
3 Conceptualize, develop and evaluate the idea on the proposed solution to improve the
old system
4 Identify user requirement and translate the into additional system specification
5 Design the new system will meet the identified system
6 Quality control management. Implements the system and ensure that it meets the
requirement of the user.
Role in an organization
The analyst is an important link person between
 User and Management: Communication channel that can justify the use to increase
performance of the users and company.
 User and the computer, Advises the user on suitable technological solutions and practice
using computer organization and technology. Advises the use of technology in line with
organization goals to maximize performance or profit and user comfort.
He acts in the following capacities or roles in organization
 Catalyst between user and their job performance examining opportunity and solution and
their use to increase user comfort, satisfaction and performance.
 Advisor to user on the effective use of computers
 Educator-Educates the novice and the occasional user on their responsibility and their
role in analysis and design process
 Salesman-Sells the concepts to departmental heads/first line ,manager and convince them
on the advantage of new system
 Agent of change-A person who brings new technology that changes people job
environment and therefore user resist change. The analyst should be able to resist peoples
fears of computers and the effect of change on their jobs by
-Justifying solution to different types users and organization as whole
-Understand user’s expectations
-Resolve conflicts imposed on the system
-Analyses the systems behaviors, partition problem into subsystem and put the system together to
satisfy user requirement
-Formulate solution in a language understood by the user
 Communicator-To put ideas across wide range of people inside and outside the
organization.
 Resolve conflict-Arising from different people and departments in line with companies
roles and objectives.
 Consultant – Expert in the field

Skills Needed by the Systems Analyst


• Working knowledge of information technology
• Computer programming experience and expertise
• General business knowledge
• General problem-solving skills
• Good interpersonal communication skills
• Good interpersonal relations skills
• Flexibility and adaptability
• Character and ethics
Necessary skills for system analyst

System analysts should have a lot of skills in order to serve the organization.

Some of the skills

Analytical skills: To break into components subsystems and assemble together

Communication skills: To convey concepts and ideas across the large organization

Good user rapport-Necessary in order to reduce hostility to change in work environment

Interpretation skills: Necessary to specify system and user environment

Listening skills: allows users and managers to give suggestions about problems and possible
solutions and feel they have been appreciated

Analysis and Design-Develop a model and translate ideas into system using a methodological
approach and techniques to communicate with development team members

Team Management-To plan, manage projects and project teams.

Imaginative and creative- Remove ambiguity in the system, resolve conflicts and produce agreed
upon operation and problem solution.

Constraints in Analysis and Design of the systems

When a project has been agreed upon and approved by management, the system analyst and the design
team is faced with constraints in the management of the project. The constraints in the development of a
system may arise from the project requirements or from the users of the system arising from how it
affects them and their performance.

The new system constraints

Some of the constraints in the new system development are

Scope: Define clearly the scope or boundary of the project and define which sections
should be outside the project boundary.

Budget: The project is allocated a given budget for hardware, software and the
development team. The analyst needs to plan very carefully in order to fit within
the budget requirement. This requires careful planning and project
management and control.

Time scale The cost of a project is normally tied to some time scale and budget for a client
or the organization. The time scales may be to cope with competitive market
forces, which may costly to the organization if not done within the required time
scales.
Technology A client or organization may require that the software should run on the existing
software and hardware and there may also be other current technology to
compare against.

Environment: The system may be required to word on different physical circumstances that
may require special equipment and tools, for example, in water , high
temperatures or a hazardous environment.

Project team Are there trained people in the organization who can handle the project and does
the company have to source the specialist from other organizations.

User constraints

The constraints that arise from the user are

Conflicting needs Conflicts in the word plain between it should be done and priority in the
organization. Some departmental different departments that may cause
conflict in terns o how heads may have interests they may wish to
protect

Resistance to change people normally may not be willing to change their work practices which
has been routine practices or may result in an increase in the work load.

Fear of computers the users may fear that computers will result in the loss of their jobs and
therefore become unwilling to cooperate with the analyst.

Approaches to design
(i) Systems development life cycle (SDLC)
(ii) Prototyping

Systems Development Life Cycle (SDLC)


It is defined as the formal step – by –step process that many organizations follow during analysis
and design. The scope of an SDLC may vary. In some cases, the effort will be so large that
dozens of people will be involved for a long time. In others, the scope will be much smaller.

- The number of steps or phases can also vary. One way to look at the SDLC is to divide it into
the following stages:
 Problem recognition/ Project initiation
 Feasibility study/ Planning
 Analysis
 Design
 Development/Implementation
 Evaluate/Review of new system and maintenance of system

Note that one phase does not have to be completed before the next one can begin i.e. the phases
often overlap. The degree of overlap depends on the project’s size and the amount of resources
committed to the project.

Who participates?
 The user group staff
 Management
 Technical staff; systems analysts and programmers

The systems analyst is generally in charge of the systems development process. He studies the
needs and problems of an organisation and determines how computer technology – data capture,
input, processing, storage and electronic communications (known today as information
technology) interacts with data, activities, and people to deliver accurate , timely and useful
information to the people.

Overview of phases
a) PROJECT INITIATION
Requests for computer based information systems can come from various sources such as:
 Steering committee formed to decide whether, having evaluated the project’s potential
benefits, it is in the organisation’s interest to implement the project.
 The user department (e.g. payroll department, marketing department) may fill out a project
request and submit it to management.
 Top management may decide on its own to replace an archaic system, for example the
manual accounting system, with a more modern and efficient one.
 The government e.g. to fulfill a legislative requirement, such as to comply with VAT reports’
requirements by the Kenya Revenue Authority.
 Computer specialists. e.g. systems analysts.

b) FEASIBILITY STUDY/ PLANNING


It’s a stage of system development which performs preliminary investigation to a system to
identify needs of the system based on user needs.

There are a number of parameters to consider before engaging in running the feasibility study,
including;
 User needs
 Business requirements
 Opportunities and problems
 Market
Requirements Engineering.
This is a process of gathering system requirements, that entails the users analyzing the
requirements and consequently producing a document specification.
Requirements Engineering Process.
• Feasibility Studies
• Requirements Gathering
• Requirements Specification
• Requirements Analysis and Validation

System requirements.
This is a description of features and functionalities of targeted systems, and the requirements that
deliver expectations of users from the system product. There are two types;
• Functional
• Non-Functional

1. Functional Requirements
These are requirements which relate to the functional aspects of a system (functionality) e.g the
search criteria in a system; reports, databases, records and sales.
2. Non-Functional Requirements
These are requirements that are not related to the functionality of the system. They represent the
expectations of the users e.g security, performance, cost e.t.c.

NB: Requirements are classified logically as;


• Must have- the system can’t perform without
• Should have- they enhance the system’s functionality
• Could have- the system can perform without
• Wish list- they do not directly relate to the objective of the system.

User Interface requirements.


These are system requirements that define the interactions between the user and the system.
A user interface should have the following:
• Ease of use/operation.
• Quick response
• Effective handling of errors
• Simplicity and consistency.
NB: Software systems are rejected mainly due to poor interface.

Requirements of a user interface.


o Content presentation
o Easy navigation e.g scroll bars, buttons like next, click, e.t.c
o Simplicity of usage
o Responsiveness
o Efficient feedback mechanism
o Consistent interface elements
o Strategic use of colors and texture
o User help features
o Grouping of related elements.

Activities of System Planning


1. Feasibility Study
2. Performing a Cost Benefit Analysis(CBA)
3. Determine project activities that must be completed on time according to
specifications and within the stipulated budget.
4. Project or system scheduling.

Objectives of a feasibility study


 To decide whether the stated objectives are attainable
 To define the major problems existing in the area under study e.g. sales order processing.
 To assess the potential that exists for savings in money, staff and effort.
 To estimate the time required and the cost of a full investigation.
 To develop and briefly examine alternative solutions e.g. buying a fitting application package
that meets the stated objectives.
 To identify any requirements for specialist staff, e.g. programmers
 To produce a precise and straightforward report covering aims of the study and
recommending further actions

Areas of feasibility study


 Technical feasibility
Will the system perform to the required specification i.e. are current computer resources, i.e.
hardware and software adequate to cope with the new system, can they upgraded. If not, does the
technology exist to meet the specification.
 Economic feasibility
Covers the question of whether the benefits of the new system are greater than the costs
involved. Both development costs (staff time, hardware and software, etc) and operational
(maintenance, stationery, etc) must be taken into account.
 Operational feasibility
- Concerned with predicting whether the system will operate and operate once it is installed. Are
users in favor of the current system? Have they expressed desire for a new system? Will they
resist the new system and can such resistance be eroded?
 Social feasibility
Deals with users’ perception and impact on one system
 Legal feasibility
It determines whether the proposed new system conflicts with the legal reguirements.it considers
copy rights, labor laws and other intellectual property rights
The Feasibility Report
This is produced at the end of a feasibility study.
Contents
 Background
- Reasons/objective of the study
- Topic of the study
- Terms of reference i.e. how the system was selected for the study, and details about the
scope of the study.
 Existing system, i.e. a description of the system currently operating.
 System requirements i.e. derived from the existing system, and for new requirements, from
management, users and operators.
 Development plan i.e. a suggested project plan, and how it will be implemented.
 Costs and benefits i.e. a detailed analysis of the costs that will be incurred in developing,
installing and operating the system and the monetary value of the various types of benefits that
the new system will bring.
 Alternatives considered i.e. identification of the various alternatives that have been
considered, together with explanations of why they have been rejected in favor of the
recommended approach.
 Conclusions and recommendations: either:
(i) Proceed with the full detailed analysis
(ii) Review the terms of reference or the scope of the study before proceeding further
or making any judgement on feasibility
(iii) Scrap the project as it is not feasible, that the resources could be better spent
elsewhere.

C) ANALYSIS
System analysis is a process of analyzing the system requirements have been identified during
planning to create a representation of the new system analysis provides through understanding of
the system requirements it answer the following question
1. Who will use this system?
2. Where and when will the system be used?
3. What will the system do?
Note: Users must keep in mind that although systems analysts may be computers, they are not
necessarily knowledgeable about the business functions performed by the user. It is the user’s
responsibility to make sure the analyst is well informed about the current system.

Techniques for information gathering


- Interviewing
- Questionnaires
- Document/Records
- Observation

Techniques of recording information


The analyst can use many tools or techniques. Modeling tools enable the analyst to present
graphical (pictorial representations) of a system or part of a system.

e) Modeling tools include (among others):


- Data flow diagrams
- Decision tables
- Decision trees

Data Flow Diagrams (DFDs)


Definition:
Data Flow Diagramming is a means of representing a system at any level of detail with a graphic
network of symbols showing data flows, data stores, data processes, and data
sources/destinations.
Purpose/Objective:
The purpose of data flow diagrams is to provide a semantic bridge between users and systems
developers. The diagrams are:
 Graphical, eliminating thousands of words;
 Logical representations, modeling WHAT a system does, rather than physical models
showing HOW it does it;
 Hierarchical, showing systems at any level of detail; and
 Jargon less, allowing user understanding and reviewing.

The goal of data flow diagramming is to have a commonly understood model of a system. The
diagrams are the basis of structured systems analysis. Data flow diagrams are supported by other
techniques of structured systems analysis such as data structure diagrams, data dictionaries, and
procedure-representing techniques such as decision tables, decision trees, and structured English.

Data flow diagrams have the objective of avoiding the cost of:
 User/developer misunderstanding of a system, resulting in a need to redo systems or in
not using the system.
 Having to start documentation from scratch when the physical system changes since the
logical system, WHAT gets done, often remains the same when technology changes.
 Systems inefficiencies because a system gets "computerized" before it gets
"systematized".
 Being unable to evaluate system project boundaries or degree of automation, resulting in
a project of inappropriate scope.

DFD Symbols
1. Entity – business, person that can send data or receive data from the system. Entity symbol
represents sources of data to the system or destinations of data from the system.
2. Data Store - where data is deposited, or stored.

3. Data Flow –Shows movement of data between other components.

4. Process - Shows what is done to data. It represents an activity that transforms or manipulates
the data (combines, reorders, converts, etc.).

Entities:
 Are named with appropriate name.
 Can be duplicated, one or more times, on the diagram to avoid line crossing.
 Determine the system boundary. They are external to the system being studied. They are
often beyond the area of influence of the developer.
 Can represent another system or subsystem.
 Go on margins/edges of data flow diagram.

Data Flows:
 Are represented with a line with an arrowhead on one end. A fork in a data flow means
that the same data goes to two separate destinations. The same data coming from several
locations can also be joined.
 Should only represent data, not control.
 Are ALWAYS named. Name is not to include the word "data".
 Are referenced by a combination of the identifiers of the constructs that the data flow
connects. (14-A references a data flow from process 14 to external entity A)

Data Stores:
 Are generic for physical files (index cards, desk drawers, magnetic disk, magnetic tape,
shirt pocket, human memory, etc.)
 Are named with an appropriate name, not to include the word "file", and numbered with a
number preceded with a capital letter D
 Can be duplicated, one or more times, to avoid line crossing.
 Can show two or more systems that share a data store. This is done by adding a solid
stripe on the left boundary. This can occur in the case of one system updating the data
store, while the other system only accesses the data. For ex ample, the data store could be
a freight rate book that one system builds and maintains, but is used by the represented
system.
 Are detailed in the data dictionary or with data description diagrams.

Processes:
 Show data transformation or change. Data coming into a process must be "worked on" or
transformed in some way. Thus, all processes must have inputs and outputs. In some
(rare) cases, data inputs or outputs will only be shown at more detailed levels of the
diagrams. Each process in always "running" and ready to accept data.
 Are represented by a rounded corner rectangle
 Are named with one carefully chosen verb and an object of the verb. There is no subject.
Name is not to include the word "process". Each process should represent one function or
functions. If there is an “and” in the name, you likely have more than one function (and
process)
 Have physical location shown only for existing physical systems or physical design is
being represented
 Are numbered within the diagram as convenient. Levels of detail are shown by decimal
notation. For example, top level process would be Process 14, next level of detail
Processes 14.1-14.4, and next level with Processes 14.3.1-14.3.6.
 Should generally move from top to bottom and left to right.

Procedure:
The procedure for producing a data flow diagram is to:
 Identify and list external entities providing inputs/receiving outputs from system;
 Identify and list inputs from/outputs to external entities;
 Create a context diagram with system at centre and external entities sending and
receiving data flows;
 Identify the business functions included within the system boundary;
 Identify the data connections between business functions;
 Confirm through personal contact sent data is received and vice-versa;
 Trace and record what happens to each of the data flows entering the system (data
movement, data storage, data transformation/processing)
 Attempt to connect any diagram segments into a rough draft;
 Verify all data flows have a source and destination;
 Verify data coming out of a data store goes in;
 Redraw to simplify--ponder and question result;
 Review with "informed";
 Explode and repeat above steps as needed

 .

Example
A purchasing department receives a purchase requisition from the stores. The requisition is
checked, and an invalid requisition is returned to the stores for correction. An order is made out
using a file of approved suppliers, and sent to the appropriate supplier. A copy order is filed. The
requisition is filed.

When the goods are received, the invoice is compared with the filed order copy, and an invalid
invoice is returned to the supplier. Valid invoices are passed to the accounts department for
payment and fulfilled orders are filed.

Draw a DFD for the above.

Decision Tree
It is a diagram used to analyse decisions that should be made given certain conditions. A decision
tree will describe an action to be taken if certain conditions are fulfilled.

With trees, we describe the sequence of events and the final outcomes.

Example:
A company’s customers are either local or foreign, a company customer or an individual person,
known or unknown to the company’s credit controller, and either able or not able to provide an
acceptable reference.

Credit is allowed to some customers depending on the above factors as follows:


Local companies known to the credit controller are allowed credit of up to $1,000, if unknown
$400. Foreign companies with an acceptable reference get $700, otherwise $300. Individuals
who are local customers and provide and an acceptable reference get $100, otherwise no credit.
Foreign individuals are allowed $50 on providing an acceptable reference, otherwise nothing.

Decision Table
A decision table is a two-dimensional matrix with one horizontal row for each condition and
each action and one vertical column for each combination of values and resulting actions

Condition stub Condition entry


(List of conditions) (Y(es), N(os) column
entries)

Action entry (Crosses


Action stub (Xs) marking actions
(List of actions) taken)

The number of columns required in the condition entry is calculated using the formula 2n, where
n is the number of conditions.

Example
The delivery charge to be added to customer’s invoices is determined as follows:

If the order value is at least £100,000 and the delivery distance is within 1 km, the delivery
charge is £1,000. If the distance is more than 1 km, the delivery charge is £1,500. If the order
value is less than £100,000 and the delivery distance is within 1 km, the deliver y distance is
£2,000, else £3,000. Draw a decision table from the above.
Solution
There are 2 conditions;
Order value equal or greater than £100,000?
Delivery distance within 1 km?

And
4 actions;
Charge £1,000
Charge £1,500
Charge £2,000
Charge £3,000

The number of rules or columns is 2n (n - number of conditions is 2).


22 = 4.

The table looks as follows:


Order value > = £100,000? Y Y N Y
Delivery distance within 1 km? Y N Y N
Charge £1,000 X
Charge £1,500 X
Charge £2,000 X
Charge £3,000 X

Structured English
This method uses narrative statements to describe a procedure. Analysts are required to identify
the conditions that occur in a process, decisions that must be made when these conditions occur
and alternatives actions to take.

Developing structured statements


Structured English uses three basic types of statements to describe a process:
 Sequence structures
A sequence structure is a single step or action included in a process. For example, in an Accounts
Payable processing system, the following sequence of five steps would apply;
1. Accept invoice for processing
2. Prepare payment voucher using invoice
3. Revise account balance sue using payment voucher
4. Write supplier cheques
5. Mail cheque to supplier
The steps are carried out in the order in which they occur.
 Decision structures
Decision structures occur when two or more actions can be taken, depending on the value for a
specific condition.
Through the use of IF/THEN/ELSE phrases, the structure points out alternatives in the decision
process quite clearly.
e.g. IF Order Value Over Ksh. 10000 THEN
Process Order
ELSE
Reject Order
ENDIF

 Iteration structures
In routine operating activities, it is common to find that certain activities are repeated while a
condition exists or until a condition occurs. Iteration instructions permit analysts to describe
these cases.

e.g.
REPEAT
Read Order Amount
Calculate New Balance = Order Amount + Old Balance
IF New Balance > Credit Limit THEN
IF Customer has Pending Invoice THEN
Reject Order
ELSE
Investigate Customer Account
END IF
ELSE
IF Customer has Pending Invoice THEN
Process Order
Send Customer Reminder letter
ELSE
Process Order without query
END IF
END IF
UNTIL All orders are processed

d). DESIGN

It is the process of defining the structure components interfaces and data required to satisfy
analyzed requirements system design produces the following designs
1. Interface design
2. Input design
3. Database and field design
4. Output design
The analyst now considers the manual and computerised procedures that will address the system
features such as inputs (data), outputs (reports), files, security, user interface (screens and
dialogues).
Systems Design details how a system will meet the information requirements as determined by
the systems analysis i.e. how it will fulfill the objectives

 It is the overall plan or model for the system.


 It consists of all specifications that give the system its form and structure
 It is an exacting and creative task demanding imagination sensitivity to detail and expert
skills
 Have three objectives.

1. System designer is responsible for “considering alternative technology configurations for


carrying out and developing the system as described by the analyst” - by analyzing
performance of different hardware, software, security, changeability, portability etc of
hardware
2. Management and control of the technical realization, testing and training. Also actual
procurement of Hardware, consultants, Software needed by the system.
3. Detail system specification that will deliver the functions identified during system analysis,
which should address all components of the system solution.

There are two aspects of design:


Logical design – It lays out the components of the system and their relationship to each other, as
they would appear to user.
 Showa what the user would do not how
 Describes input and outputs, processing functions procedures and controls

Physical design – This is the actual physical implementation of the system, for example
specifying the input medium, output medium, storage media, actual software to install, etc.
It is the process of translating the abstract logical model into the specific technical design for the
new system
 Produces actual specifications for Hardware, Software, physical database, input/output
media, manual procedure and specific control

End users must participate to specify requirements (that drive its system building efforts), give
the priorities, needs and biases. This increases acceptance, and reduces unfamiliarity, power
transfer and inter-group conflicts.

E). IMPLEMENTATION
It involves coding, testing and installing system the developer is responsible for translating
design to physical system after coding the system is tested to ensure individual programs are
functional
METHODOLOGY OF IMPLEMENTING SDLC
Methodology is a formal approach used to implement SDLC .it involves a series of steps and
deliverables
The methodology are broadly categorized in two

Category 1
Process oriented
Data oriented
Object oriented

Category 2
Structured oriented
Rapid Application Development (RAD)
Agile
PROGRAMMING/ IMPLEMENTING/ DEVELOPMENT

Definition
1. Programming is the process of translating system specifications prepared during design
stage into (program code (solution)) a full operational system.
2. Programming is the process of translating system specification into program code

System development environment (SDE) is a workshop that offers the required hardware and
Software tools required by the developer and should have: -
 Language translators – compilers and assemblers
 Module linkers and libraries
 Error reporting features
 Specification requirements and validation features
 Documentation processing and production
 Estimation, planning and process monitoring tools
 Testing tools etc

Input Design
- Concerned with the way data will be captured organized and converted from a human
sensible form to a computer sensible form.

Data is first recorded in documents from which it is entered to the computer. As it is entered, it is
visually displayed on the screen. The input forms’ and the screens should therefore be well
designed to ensure that correct data is input to the computer and that the data entry process is as
easy and error free as possible.

Factors to be considered in input design


- Accuracy – the way forms are designed should enable proper completion or filling
- Ease of use – No extra time should be spent in deciding what to do.
- Consistency – Forms and screens should group related data on the same area
- Simplicity – Only the necessary information should be included in the form.
- Attractiveness – The forms should be visually attractive through high quality presentation
of graphics, charts, colour.
- Cost – Input medium and input capture methods must be cost effective to use.

Specifically, good input documents should be designed with the following in mind:
- Fields for all data should be included, but no unnecessary data should be added.
- Documents should have a clear title.
- Documents should be designed to be human sensible where input is manual and machine
sensible where non- manual methods such as MICR are used.
- Layout should be natural e.g. a customer name should appear before customer address.
- Layout should be convenient for the input user, i.e. laid out in the same order as the fields
appear on the input screen
- It must be clear that a document has already been input; i.e. appropriate controls must be
designed to ensure that it is not input twice, or overlooked altogether.
- Fields to be completed must be clearly titled, with narrative if necessary, to show exactly
what can be placed in each
TESTING

Definition 1
The exhaustive and thorough process that determines whether the system
produces the desired results under known conditions
 50% of budget is in testing
 Test data must be carefully prepared, results reviewed and corrections
made in the system

To ensure testing is clear and comprehensive a systematic test plan must be


employed

NB: the development team and users prepare Test plan with details on
how tests will be carried out. It must detail: -
 Expected inputs
Expected outputs
 Expected error reactions
 Expected communications
 Expected termination etc

Definition 2
Testing involves actual execution of program code using representative
test data sets to exercise the program and outputs are examined to detect
any deviation from the expected output

Definition 3
Testing is classified as dynamic verification and validation activities

Reviews can be applied to:


 Requirement specifications
 High level system designs
 Detailed designs
 Program code
 User documentation
 Operation of delivered system

Objectives of Testing
1. To demonstrate the operation of the software.
2. To detect errors in the software and therefore:
 Obtain a level of confidence,
 Produce measure of quality.

METHODS/TYPES OF TESTING

Functional testing
A software testing technique whereby the internal workings of the item being tested are not
known by the tester. For example, in a black box test on software design the tester only knows
the inputs and what the expected outcomes should be and not how the program arrives at those
outputs. The tester does not ever examine the programming code and does not need any further
knowledge of the program other than its specifications.
The advantages of this type of testing include:
• The test is unbiased because the designer and the tester are independent of each other.
• The tester does not need knowledge of any specific programming languages.
• The test is done from the point of view of the user, not the designer.
• Test cases can be designed as soon as the specifications are complete.
The disadvantages of this type of testing include:
• The test can be redundant if the software designer has already run a test case.
• The test cases are difficult to design.
• Testing every possible input stream is unrealistic because it would take a inordinate amount of
time; therefore, many program paths will go untested.

White Box Testing


Also known as glass box, structural, clear box and open box testing.
A software testing technique whereby explicit knowledge of the internal workings of the item
being tested are used to select the test data.
Unlike black box testing, white box testing uses specific knowledge of programming code to
examine outputs. The test is accurate only if the tester knows what the program is supposed to
do. He or she can then see if the program diverges from its intended goal. White box testing does
not account for errors caused by omission, and all visible code must also be
readable.For a complete software examination, both white box and black box tests are required.

THE TESTING PROCESS


Systems in this case are tested, as a single unit therefore testing should proceed in stages, where
testing is carried out incrementally in conjunction with system implementation.
The most widely used testing process consists of 5 stages:
(a) Unit testing
(b) Module testing
(c) Sub-system testing
(d) System testing
(e) Acceptance (alpha) testing.

(A) UNIT TESTING


Unit testing is where individual components are tested independently to ensure they operate
correctly.
(B) MODULE TESTING
A module is a collection of dependent components e.g. an object class, an abstract data type or
collection of procedures and functions.
Module testing is where related components (modules) are tested without other system modules.
(C) SUB-SYSTEM TESTING
Sub-systems are integrated to make up a system.
Sub-system testing aims at finding errors of unanticipated interactions between sub-systems and
system components. Sub-system testing also aims at validating that the system meets the
functional and non-functional components.

(D) ACCEPTANCE TESTING (ALPHA TESTING)


Acceptance testing is also known as alpha testing or last testing.
In this case the system is tested with real data (from client) and not simulated test data.
Acceptance testing:
 Reveals errors and omissions in systems requirements definition.
 Test whether the system meets the users’ needs or if the system performance is acceptable.
Acceptance testing is carried out till users /clients agree it’s an acceptable implementation of the
system.

N/B 1:Beta testing


Beta testing approach is used for software to be marketed.
It involves delivering it to a number of potential customers who agree to use it and report
problems to the developers.
After this feedback, it is modified and released again for another beta testing or general use.

N/B 2:
The five steps of testing are based on incremental system integration i.e.
(Unit testing – module testing – sub-system testing - system testing- acceptance testing). But
object oriented development is different and levels have clear/ distinct
 Operations and data forms objects –units
 Object integrated forms class (equivalent to) –modules
Therefore class testing is cluster testing.
Good Quality System should have some measurable qualities: -
 Correctness
 Maintainability
 Integrity
 Usability

Correctness ensures the System operates correctly and provides the value to its user and performs
the required functions therefore defects must be fixed/ corrected

Maintainability is the ease with which system can be corrected if an error is encountered, adept if
its environment changes or enhance if the user desires a change in requirements

Integrity is the measure of the system ability to withstand attacks (accidental or intentional) to its
security in terms of data (processing, performance), program and documentation

Usability is the measure of user friendliness of a system as measured in terms of physical and
intellectual skills required to learn the system, the time required to become moderately
Efficient in using it, the net increase in productivity if used by moderately efficient user, and the
general user attitude towards the system.

Output Design
It is important that computer-printed documents and VDU displays (screens) are well designed
because they are the contact between end users and the information system. The layout and
content must be absolutely clear and the presentation of a good standard.

Guidelines to effective output design


 Purpose; Where appropriate, the conditions giving rise to the production of the output should
be specified – i.e. what needs to happen first for a particular item or report to be produced as
output
 Frequency of production; is it produced weekly or daily or by the hour? Is there any urgency
in its production?
 Volume; if output volumes are very large, high-speed printers should be appropriate.
 Sequence; For instance, it might be desirable to print out exception reports such as lists of
slow payers before printing a full debtors listing.
 Output Medium; The choice of output medium will have regard to whether a hard copy is
required or not.
 Content and Format; Printouts (Reports, Receipts, etc) must be well designed, because they
are the primary point of communication between information systems and users. The layout and
contents of any piece of output must be clear and designed to a high standard of presentation.
 Screen displays; Whenever displays are being designed, it is vital to consider their purpose
and present the information so that users can quickly see and understand it. The VDU is used
both as an input and output device in many systems.
 Identification; All output report documents and VDU screen displays must be clearly
specified and uniquely identified.

User Interface Design


An interface is the means through the user communicates with the computer system
- An interface should be user friendly i.e. it should be helpful to the user, tolerant to the user
and adaptable. The user should be happy and confident in using it. Generally, user friendliness in
a system should combine the following qualities:
(i) Ease of data entry
(ii) Intuitiveness; Users being able to make reasonable guesses
(iii) ‘On – line’ help
(iv) Use of proper dialogue and prompts such as guide instructions and warning signs
(v) Escapability – The user can cancel a command.

User interface dialogues


An interface system can have one or more of the following types of dialogue:
(i) Menu selection
(ii) Form filling
(iii) Graphical user interface
(iv) Command driven interface

Menu selection
A menu is a list of items to choose from. For example, a menu for sales ledger might include the
following items;

Customer Details
1. Batched Data Entry
2. Invoice Production
3. Receipts
4. Refunds

5. Contra Entries

By specifying Customer Details for instance, the operator will be specifying that he or she wants
to call up details of customers.

Form Filling
In this method, data items are displayed, each having an adjacent blank box. The values of these
are entered from the keyboard and displayed immediately, thus allowing the user to check for
correctness and completeness. It is a suitable method for repeatedly entering a large amount of
data such as customer’s remittances.
Customer remittances

24835
Customer account no.

Customer reference 359/165

Date of remittance 18 12 94

456.70
Amount

CH
Method of payment

Method of payment codes

CA Cash CH Cheque CT Credit transfer

Screen formatting for this purpose usually includes:


- Use of different colours in various areas.
- Flashing items for some sections such as totals
- Large characters for titles.
- Highlighting such as bold, italics, underline for instructions, titles and headings.
- Paging or scrolling depending on the volume of information

Command Driven Interface


The computer asks the user for a specific input. Based on the input, the computer responds with
some information or asks for more information. The process continues until all the data has been
entered into the computer or retrieved by the user. For example, ATM(Automatic Teller
Machine) system.

Graphical User Interface


This is used to make computers user-friendlier to people without experience of using them or
who might have difficulty in using them. Dialogue is conducted through the use of images rather
than typed text. It involves the use of WIMP (Windows, Icons, Mouse, Pull Down Menus).
Windows – Are rectangular sections of flexible size which can be opened and closed. This
enables documents to be viewed and edited together and sections of one can be inserted into
another.

Icons – Are images of objects used to represent a function or file in an obvious way, for example
the picture of a printer to denote the printing process, waster paper bin to indicate delete.

Mouse
This is a device moved around the desktop and a pointer used to pick out and activate an icon or
button.

Pull down menu


A menu bar is shown across the top of the VDU screen. Using the mouse to move the pointer to
the required item in the menu, the pointer ‘pulls down’ a subsidiary menu that can be used to
select further items.

Design of processing
The design of processing is largely a matter of interconnecting the sub-systems of output, input
and logical files so as to create a system that provides the requirements of each application. A
business application splits naturally into several routines. A routine is a type of computer work
hat produces some usable output, and is carried out as a series of related processing jobs on the
computer.

Routines vary in complexity from one organisation to another but typically relate to the
applications as below:

Application Routines (procedures)


Sales Accounting Order acceptance (daily)
Credit control (daily)
Invoicing (weekly)
Statement preparation (monthly)
Payroll Gross wage computations (weekly)
Payslip printing (weekly)
Payroll analysis (quarterly)
Production control Job scheduling (daily)
Labour planning (weekly)
Materials requirements (monthly)

The processes, jobs used in conjunction with each other to form routines are mainly of the
following types:
Data acceptance ; It validates, edits and totals the source data and prints error messages and
control tasks.
Sorting ;It sorts transaction records into the sequential order before processing.
Referencing; To look up data from a master file e.g. prices, balances and to apply these to
transaction records.
Updating; The master file records are updated by data from the transaction records.
Amending; Involves inserting new records, deleting obsolete records and making changes to
master file records. For instance , a record is inserted for each new product, removed for every
dead product and alterations made to the prices of products.
File printing; Updated records are copied from the master, summarized then printed, e.g. of the
stock levels of all the materials.
Document printing; Master files and transaction files are used to print documents such as
invoices, payslips, statements, etc.

POOR QUALITY SYSTEM


 High cost of maintenance and correcting errors (unnecessary maintenance)
 Low productivity
 Unreliability
 Risk of injury – of safely critical systems (e.g. robots)
 Loss of business due to errors
 Lack of confidence to (in ) the developers by clients.
CONVERSION

Definition
The process of changing from the old system to the new system. Starts by checking if the system
will work under real conditions

Four main conversion strategies can be employed


1. Parallel strategy is the safe and conservative conversion approach where both old system and
its potential replacement are run together for a time until the new system is proved to be
functioning correctly.
2. Direct cut over strategy is a risky conversion approach in which the new system completely
replaces the old one on appointed date.
3. Pilot study strategy is introduction of the new system to a limited area of the organization
until it is proven to be fully functional, after which full conversion can take place
4. Phased approach strategy introduces the new system in stages (either by functions or
organizational units)

NB: A formal conversion plan provides a schedule of all activities required to install a new
system
Conversion requires
- End user training
- Detailed documentation- user & system documentayion
F). MAINTENANCE
It is the final phase after the system has been installed
The process is continuous throughout the life cycle of a system
Maintenance is concerned with the changes in Hardware, Software, documentation, or
procedures to a production system to correct errors, meet new requirements or improve
processing efficiency.

The maintenance stage of system development involves


a) correcting errors discovered after other stages of system development
b) improving implementation of the system units
c) enhancing system services as new requirements are perceived

Information is fed back to all previous development phases and errors and omissions in original
software requirements are discovered, program and design errors found and need for new
software functionality identified.

Definition 1
Maintenance is the process of changing a system after it has been delivered and is in use.
Simple - correcting coding errors
Extensive - correcting design errors.
Enhancement- correcting specification errors or accommodate new requirements.

Definition 2
Maintenance is the evolution i.e. process of changing a system to maintain its ability to survive.
Types of maintenance
There are four different types of maintenance:
a) Corrective maintenance:
This involves fixing discovered errors in software. (Coding errors, design errors, requirement
errors.)
b) Adaptive maintenance:
This is changing the software to operate in a different environment (operating system, hardware)
this doesn’t radically change the software functionality.
c) Perfective maintenance:
Implementing new functional or non-functional system requirements, generated by software
customers as their organization or business changes.
d) Preventive maintenance:
Making changes on software to prevent possible problems or difficulties (collapse, slow down,
stalling, self-destructive e.g. Y2K).
Maintenance cost (fixing bugs) is usually higher than what software originally cost due to: -
I. Program’s being maintained may be old, and not consistent to modern software
engineering techniques. They may be unstructured and optimized for efficiency rather
than understandability.
II. Changes made may introduce new faults, which trigger further change requests. This is
mainly since complexity of the system may make it difficult to assess the effects of a
change.
III. Changes made tend to degrade system structure, making it harder to understand and make
further changes (program becomes less cohesive.)
IV. Loss of program links to its associated documentation therefore its documentation is
unreliable therefore need for a new one.

Factors affecting maintenance


Module independence
Use of design methods that allow easy change through concepts such as functional independence
or object classes (where one can be maintained independently)
Quality of documentation
A program is easier to understand when supported by clear and concise documentation.
Programming language and style
Use of a high level language and adopting a consistent style through out the code.
Program validation and testing
Comprehensive validation of system design and program testing will reduce corrective
maintenance.
Configuration management
Ensure that all system documentation is kept consistent through out various releases of system
(documentation of new editions.)
Understanding of current system and staff availability
Original development staff may not always be available. Undocumented code can be difficult to
understand (team management).
Application domain
Clear and understood requirements.

Staff availability vs No. of customers to support

Availability of software tools


Hardware stability

Dependence of program on external environment

MAINTENANCE PROCESS
Maintenance process is triggered by
(a) A set of change requests from users, management or customers.
(b) Cost and impact of the changes are assumed, If acceptable, new release is planned (involving
elements of adaptive, corrective and perfective maintenance).
Changes are implemented and validated and new versions of system released.

You might also like