INTRODUCTION
SYSTEM
DEVELOPMENT LIFE CYCLE (SDLC)
Systems
are created to solve problems. One can think of the systems approach as an
organized way of dealing with a problem. In this dynamic world, the subject
System Analysis and Design (SAD), mainly deals with the software development
activities.
DEFINITION
OF A SYSTEM
A
system is a collection of components that work together to realize some
objectives. Basically there are three major components in every system, namely input,
processing and output.
SYSTEM
LIFE CYCLE
System
life cycle is an organizational process of developing and maintaining systems.
System development life cycle means combination of various activities.
Definition
The
systems development life cycle (SDLC) is the process of understanding
how an information system (IS) can support business needs, designing the
system, building it, and delivering it to users.
System
life cycle is a series of stages that are worked through during the development
of a new information system.
Factors
that influences the need for a new system
-
Manual method could not cope with the volume of work
-
Old system is inefficient due to poor hardware or software version
-
Company procedures have changed with practice
-
Problem of duplication of information
-
The nature of business has changed to real-time and online systems
Planning
The
planning phase is the fundamental process of understanding why an
information system should be built and determining how the project team will go
about building or developing it. It has two steps:
1.
During project initiation, the system’s business value to the
organization is identified how will it lower costs or increase revenues? Most
ideas for new systems come from outside the IS area (from the marketing department,
accounting department, etc.) in the form of a system request.
2.
Once the project is approved, it enters project management. During
project management, the project manager creates a work plan, staffs
the projects, and puts techniques in place to help the project team control and
direct the project through the entire SDLC.
System
Development Project Team
This
is a group of people that are working together by bringing their ideas on the
development of a new information system.
System
Analysts: These
are the people who are responsible for finding out about the current or
existing system, investigates the performance of the system and its
shortcomings.
Programmers:
These are people that write computer programmes that matches the design
specifications given by the system analysts.
STAGES OF SYSTEM LIFE CYCLE
Problem definition
- Problem identification
- Feasibility study
- System Analysis
- System Design
- Implementation
- Documentation
- Maintenance
- Evaluation
Steering Committee
The committee is collection of members from the various
departments within the organization. The set of people commissioned by the
management to exercise control over system development and to ensure that the
needs of various users are met.
Functions of Steering committee
- Ensuring that all the information Technology activities are
inline with the strategic plans of the organization as a whole.
- Providing leadership at senior level for the utilization
and management of information technology.
- Ensuring that resources allocation and decision are
effective
- Creating the terms of reference for the project team
- Monitoring the progress of the various projects
- Coordinating requirement in any organization restructuring
Types of Feasibility study
The areas to be considered or covered when carrying out
feasibility study
i. Technical feasibility
- A technical feasibility study is concerned with the ability
of organization to cope with the technological requirement of the system.
- The hardware and software capability of dealing with the
volume of transactions and required response time without any disruption to
business operations.
- This is mainly with specifying the performance requirement
of the system and then assessing whether a proposed system will be able to meet
those performance specifications.
ii. Operational Feasibility
- The system must fit in with the way that the organization
run its business and plan to run its business in the future.
- It must provide each user with the required information in
a timely manner.
- It also considers whether the proposed solution is
desirable within the existing managerial and organization framework.
iii. Social Feasibility
- Social feasibility indicates how well a proposed
information system support the objectives of an organization strategic plan for
information system.
iv. Economic feasibility study (cost benefit analysis)
This feasibility appraises whether the benefits of the
proposed solution outweigh the cost this presenting a clear understanding of
the business value of the proposed system.
Cost analysis
The goal is to determine whether expected cost saving,
increased revenue, increase profits and reduction on required investment exceed
the cost of developing and operating a proposed system.
Benefits
- Savings in labour costs
- Benefits due to faster processing
- Better customer service
- Better decision making
- Error reduction
Types of cost
i. Development cost
ii. Operating cost
Development cost: This is the
cost incurred from the feasibility study until the system is handled over for
maintenance.
Installation cost::
This involves preparation cost, delivery charges and other arising from any new
equipment or computer required
Capital cost:: This cost
involves equipment cost required for the application
Migration cost: This
involves Staff training, File conversion, System testing and Changeover cost.
ii. Operating cost: The cost involves the following
- Hardware and software costs
- Staff cost,
- Supplier and stationary
- System maintenance
- Third party services
- Space costs
Feasibility study committee members
- Department members: provides useful data/information to the
committee concerning their various departments e.g sources of data, data
volume, types of data.
- Board of Directors: provides confirmation on the
preparedness of the company to face computerization project and to confirm the
committee’s financial reports to the board.
- Senior analyst: Provides the lead of other members in fact
finding process.
- Outside Consultant: To complement the experience of the
analyst and to ensure integrity and accuracy of information system
-
A Certified
Accountant: To provide financial and technical advice relating to cost and
benefits.
Functions and duties of
Feasibility study committee
- To determine if the implementation of a computer system can
be justified from the cost
- To analyze the current operation of the company
- To evaluate carefully quotation or bids received from
computer manufacturer and software houses.
Feasibility study Reports (Summary)
- Introduction to the proposal , contents and title page
- Terms of reference
- Description of the existing system and its shortcoming
- Specification and outline of the proposed system
- The expected cost of developing, implementation, and
operating the proposed system
- Likely benefits from the proposed system
- Suggested Hardware and software and other applications
- Information about the organization that uses the proposed
system
- Alternative consideration and the reasons for rejecting
them
- Conclusion and recommendations
- Management summary
SYSTEM ANALYSIS
At this stage, this system Analyst investigates the current
or existing system to verify more about its performance and what is being done
, why is it being done and what is responsible doing it and how it is being
done.
The system analyst gives detail by:
- Identifying the purpose of the new proposed system
- He identifies the functional requirement of the proposed
information system
- Identifying the information system processing and
communication requirement
- He analyses the detail information needs of an organization
- He translates business problems into information
requirement and system
- He carries out investigation of problems with the existing
system
- He recommends the software and hardware need and
requirement
- He delivers the detail reports to be used at the system
design stage.
SYSTEM ANALYST
The systems analyst focuses on the Information System
issues surrounding the system. This person develops ideas and suggestions for
how Information Technology can improve business processes, designs the new
business processes with help from the business analyst, designs the new
information system, and ensures that all IS standards are maintained.
Infrastructure Analyst
The infrastructure analyst focuses on the technical
issues surrounding how the system will interact with the organization’s
technical infrastructure (e.g., hardware, software, networks, and databases).
Change Management Analyst
The change management analyst focuses on the people
and management issues surrounding the system installation. The roles of this
person include ensuring that adequate documentation and support are available
to users, providing user training on the new system, and developing strategies
to overcome resistance to change.
Project Manager
The project manager is responsible for ensuring that
the project is completed on time and within budget and that the system delivers
all benefits that were intended by the project sponsor. The role of the project
manager includes managing the team members, developing the project plan,
assigning resources, and being the primary point of contact when people outside
the team have questions about the project.
What the system analyst must
possess (qualities of a System analyst)
- System analyst must understand the business application
- He must have ability to communicate with users
- He must understand the technical specification and
programming details.
- He must have logical mind
- He must be competent above average
Activities of the system analysis stage
- Data gathering and evaluation
- Establishing information requirement and solution
alternative
- Selecting the required package
During this stage, the analyst will use several methods to
find out the major facts about the performance of the system to deduce his
reports on investigation.
Method of Fact finding (Research making techniques)
i. Interview: This method
involves gathering of information by face-to-face by asking question directly
from the respondent about the existing system.
Expectation of the interviewer
- He must plan for the interview
- He must have clear purpose of his interview
- He must prepare thoroughly for the interview
- He must explain the to the respondents the purpose of
interview
- He must outline a list question to be asked during the
interview.
- He should put the interview at ease
- He must summarize the main points o the interview at the
end the event
Limitations
- The interviewee may refuse to cooperate with the
interviewer
- The interview requires a skillful interviewer
- It is time consuming for the interviewer
ii. Questionnaire: The
questionnaire method is the way of providing some related questions on paper
document and distributed to the respondents. It is a useful way of gathering
information quickly because people are often more honest and say what they
really feel about the system during the filling of a questionnaire leaflet
rather than asking them questions fac-to-0face on interview.
Limitations
- Response rate may be poor at times or response rate are
often low
- Analysis of a lengthy questionnaire can be costly
- Questionnaire that are not well designed provides little
information
- There is physical contact for discussion with the
Factors to be considered when
designing questionnaire
- Brief introduction to the subject matter for clarity ad
simplicity
- Questionnaire must be kept simple and short to avoid
ambiguities
- Using simple multi-choice questions rather than comments
- Having clear idea of the information that is required for
the questionnaire
iii. Observation: This
method is by watching and examining the reaction and the performance of the
system and studying it efficiency. It gives more accurate picture of what
actually happen in the system than interview or questionnaire because the
Analyst himself experiences the performance of the system. It also consumes
time of the analyst.
Advantages
- It is cheaper
- It shows actually what happen to the system
- It is used to gain confirmation that a system as outlined
in theory
Disadvantages
- It is time consuming
- Observation does not reveal the beliefs and attitudes of
the people involved unlike interview
- Human nature may dictate that different behavior will occur
when individual is aware he is being observed.
SYSTEM REQUIREMENTS ANALYSIS
The purpose of System Requirements Analysis is to
obtain a thorough and detailed understanding of the business need as defined in
Project Origination and captured in the Business Case, and to break it down
into discrete requirements, which are then clearly defined, reviewed and agreed
upon with the Customer Decision-Makers. During System Requirements Analysis,
the framework for the application is developed, providing the foundation for
all future design and development efforts.
THIS PHASE CONSISTS OF THE FOLLOWING PROCESSES:
Prepare for System Requirements Analysis, where steps are taken to ensure that the project environment
and
Project Team members are adequately prepared to both capture
and analyze the system requirements;
Determine Business Requirements, where
in-scope and out-of-scope business requirements are identified, business rules
are defined and documented, and interfaces to and from the new application are
discussed;
Define Process Model, where
a pictorial top-down representation of the major business processes that
interact with the system is diagrammed and decomposed into manageable functions
and sub-functions until no further breakdown is feasible;
Define Logical Data Model, where
data that supports the processes and business rules is logically modeled,
identifying entities and their relationships to other entities, and defining
attributes with their business definitions;
Reconcile Business Requirements With Models, where the Project Team ensures that the Process and Logical.
Data Models accommodate all requirements and business rules.
Produce Functional Specification, where interfaces, processes and data are merged to describe
systematically how the Consumer will use the application, and how data will be
retrieved, processed and stored.
Functional Specification
Document describing the logical grouping of related processes
and functions within the new system, along with the mapping of these processes
to both the business requirements that they satisfy and the data items with
which they interact.
General Functional Specifications
The General Functional Specifications section details
those specifications that are common to all aspects of the system (e.g., the
menu structure, security, accessibility, overall performance requirements,
etc.).
Three graphical representations of the overall system should
be included:
• System Context Diagram, showing how this system will
interact with other existing systems,
• Business Flow Diagram, showing how Customer and Consumer
business units will interact with the system; and
• System Interface Diagram, showing the application structure
(menu structure and navigation of online components), organization of reports
and other batch interfaces, and utilities.
Detailed Functional
Specifications
The Detailed Functional Specifications section lists
functional specifications for each aspect of the system. The structure of this
section is dependent on system organization. For example, if the system is
organized to follow the business unit structure, with each sub-system
supporting a specific Customer or Consumer group, then each Sub-system
Description should list main characteristics and functions of that group;
SUB-SYSTEM
The Sub-system Description describes the sub-system in
a narrative.
Component Type
Depending on system structure (and Functional Specification
document), it may be useful to organize system components by type (such
as screens vs. reports, or tracking vs. auditing). If that is the case,
Component Type Description would provide a rationale for such structural breakdown, and
describe common elements of all components within that type.
Component Type Description
Component
- Component Description
- Component Mockup (where appropriate)
- Component Business Flow
• Cross-reference to Business Requirement(s), Logical Data
and Process Models
• Flowchart
• Detailed Business Rules for each Flowchart element
Technical Specifications
This section documents in detail the technical
specifications, regulations and existing constraints that must be considered in
relation to business requirements. These include considerations such as
accessibility, encryption, security, disaster recovery, and other technical
areas.
Operational Specifications
This section should document in detail the operational
specifications that must be considered in relation to business requirements.
These include considerations such as system performance, data archival, audit
and controls, system administration, software quality assurance and business
continuity.
Transitional Specifications
This section documents in detail the transitional
specifications that must be considered in relation to business requirements.
These include considerations such as data conversion, system testing,
documentation, training and deployment.
SYSTEM ANALYSIS REPORT
After the above fact finding method have been carried out,
the system analyst then prepares a document known as analysis report on the
information gathered on the existing system, performance and solutions.
The following contents are included:
- Sources of information used
- Description of the existing system, and its problems or weaknesses
- System requirement for the proposed system,
- Recommendation for implementation
- Flow charts and data flow diagram
- Organization chats of the system
- Specimen documents
- Summary and conclusion
Request For Proposal (RFP)
This is detailed lists of questions submitted to vendors of
package or computer services to determine if the vendor’s products can meet the
specific requirement of the organization.
SYSTEM DESIGN
This stage evolves after the feasibility study and system
analysis have been carried out. It involves the description of the new system
and its structure, coding of instructions called programming to make a
structured system in a well defined format in order to meet the specified
requirement.
Activities involved in system
design
- Creating logical design specification
- Creating physical design specification
- Managing the technical formation of the system
- Translating design specification into program code
- Configuring the package to user requirement
- Training technical staff on the package
- Redesigning organizational procedures
Normally, the design proceeds in two stages:
• Preliminary or General Design
• Structured or Detailed Design
Preliminary or General Design:
In the preliminary or general design, the features of the new system are
specified. The costs of implementing these features and the benefits to be
derived are estimated. If the project is still considered to be feasible, we
move to the detailed design stage.
Structured or Detailed Design:
In the detailed design stage, computer oriented work begins in earnest. At this
stage, the design of the system becomes more structured. Structure design is a
blue print of a computer system solution to a given problem having the same
components and inter-relationships among the same components as the original
problem. Input, output, databases, forms, codification schemes and processing
specifications are drawn up in detail.
There are several tools and techniques used for
describing the system design of the system. These tools and techniques are:
• Flowchart
• Data flow diagram (DFD)
• Data dictionary
• Structured English
• Decision table
• Decision tree
The system design involves:
i. Defining precisely the required system output
ii. Determining the data requirement for producing the output
iii. Determining the medium and format of files and databases
iv. Devising processing methods and use of software to
produce output
v. Determine the methods of data capture and data input
vi. Designing Input forms
vii. Designing Codification Schemes
viii. Detailed manual procedures
ix. Documenting the Design
Logical Design
This is the design of the system in concept, and what the
system is meant to achieve, rather than detailed implementation.
It specifies the layout of the components of the system and
their relationship to each other as they would appear to users, and show what
the system solution will do when fully and physically implemented.
It also describes input, process, and output function to be
performed and business procedures as well as data model and control.
Physical Design
This is the process of translating the logical model into the
specific technical design for the new system.
It also shows that exact design as to how a particular procedure
will be implemented in software.
Design methods
The design methods given below can be used in a variety of
computing situations. In the life cycle, they are used to very good effect in
the creation of programs and testing.
Top down design
This method starts with a general description of the task and
then subdivides into sections which add more detail. The lowest level
represents the most specific modules.
2nd level
2nd level
2nd level
Top level
3rd level
3rd level
3rd level
3rd level
3rd level
4th level
4th level 15
Bottom up design
This method starts at the lowest level with modules or
procedures and then joins them to create the next level up. By progressively
combining segments, the top level is achieved.
Objectives of system design
To design a system, which meets the users requirement or
needs
To design a system within the fund or budgeted cost
To design a system which processes data accurately
To design a system that is simple to operate
To design a system the is flexible for maintenance and review
To design a system which will give room for future expansion
PROTOTYPING
"Prototyping is
an engineering technique used to develop partial but functional versions of a
System or applications. When extended to system design and construction, a
prototype can evolve into the final, implemented system.
Prototyping is a working model of a system or useable system
or system components that is built inexpensively, quickly and with the
intention of being modified or replaced.
Types of prototyping
- Mock-up This is produced for demonstration purposes
at the early stage of a project design to help the designer to make decision on
what to do.
- Trial prototyping: This is a simplified working
model of a proposed system, it has the capability of a real system.
- Rapid prototyping: This is known as Rapid
Application Development (RAD). It is an alternative to the conventional life
cycle. It is most frequently used for small scale system.
- Feasibility prototyping is used to test the
feasibility of a specific technology that might be applied to the business
problem. For example, we might use Microsoft Access to build a quick
but-incomplete prototype of the feasibility of moving a mainframe application
to a PC-based environment
Advantages of prototyping
- It makes the employees to be involved in the development of
the new system
- It makes the development faster and testing of working
model of a new system is interactive
- It allows use to determine if the system will work toward
achieving the set up goals.
- It gives graphical representation of the end product
- It describes the structure of the real system
Disadvantages of Prototyping
- The tools often require data to be in a specific format
- The development process may become sloppy and unstructured
resulting to high cost or waste of money and resources
Major Step/stages of prototyping
- Identifying the system specification/requirement
- Developing the first or usable prototype
- Implementation and usage of the formed prototype
- Revise and enhance the prototype for improvement
Development tools used in
prototyping
- High level language
- End-user query language
- Report Writer
- Integrated data dictionaries
Joint Application Development (JAD)
"As previously described, modern structured analysis and
information engineering both emphasize model-driven development. Prototyping
places emphasis on construction of the working prototypes.
- Joint application development (JAD) uses highly
organized and intensive workshops to bring together system owners, users,
analysts, designers, and builders to jointly define and design systems.
Synonyms include joint application design and joint requirements
planning.
- A JAD-trained Systems analyst usually plays the role of
facilitator for a workshop that will typically run from three to five full
working days. This workshop may replace months of traditional interviews and
follow-up meetings.
- JAD provides a working environment in which to accelerate
methodology activities and deliverables. It promotes enhanced system owner and
user participation in system development.
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 helps in fast development, maintenance and future
changes, if required.
MODEL
A Model is used to describe any representation of real life
system or object or situation which may be physical or abstract in nature.
- It is used to demonstrate the behaviour of a real system
prior to its construction and design.
- It is cheaper to design
- It saves time
- It is easier to control than its real system
Stages/Steps involved in
constructing a model
- Identifying the objectives and purposes of the model
- Define the logic of the model
- Code the model
- Test the model
- Revise the model
Computer-based model
- It has the ability to handle large volume of data
- It is faster in operation
- Ability to test various possible circumstances
- Ability to guide in producing reliable and quality
decisions and policies
In a system design stage, the following factors or
criteria can be evaluated.
- What hardware does the solution require
- What benefits does the solution offer
- How long will it take to design a new system
- What are the set back factors that may drawback the system
design
When these factors have been defined and identified in
detailed, the design of the new system may then commence.
SYSTEM SPECIFICATIONS
There is need to define the specification that
describes the detail about the input, process, output and storage methods in
the design stage.
It is the process of giving the detail documentation of the
proposed new system during system development life cycle.
Why defining system specification?
- To enable programmer to design the right and accurate
program for the implementation
- To give final approval by the management by communicating
the detail to the management
- To alert the operating staff of all necessary procedures
and operation
- To record all system detail for control and evaluation and
modification
- To enable the management to know the actual cost of the
proposed system
PROGRAM SPECIFICATIONS
A program specification is the definition of what a
computer program is expected to do. It can be informal, in which case it
can be considered as a blueprint or user manual from a developer point of view,
or formal, in which case it has a definite meaning defined in
mathematical or programmatic terms.
A program describes a computation -- its purpose is to be
executed on a computer and perform that computation. Programs are written in a
precisely and formally defined programming language, e.g., Java, C, Pascal. A
program specification describes the results that a program is expected to
produce, its primary purpose is to be understood not executed. Specifications
provide the foundation for programming methodology.
Areas of the system specification
Input
- What data will be needed for input
- The sources of these data
- The method of data input (Data captured modes and devices):
on-screen data capture method
- What mode or media of screen will be needed and how the
input screen needs to look like
File specification
- File description
- Record layout
- Procedures of processing
Output
- What output is required from the system (Softcopy or
Hardcopy)
- What are the output control methods to be used
- The layout needed on printout
- How and what the output screen look like
- Distribution procedures
Data Storage
- What data files are required
- What field will the records in each file need
- What data validation check will be used to make sure data
are sensible and correct
- What options will be available to user
Backing & Recovery Procedures
- How could the file be backup and what method is to be used
- How often will backup be carried out
- Where will backup files be kept
- How will data be restored if it is lost or damaged
- What field will the records in each file need
Security Procedures
- How will data be protected from unauthorized users?
- Will some users need different levels of access from other
users?
- Data Access method and procedures
HUMAN INTERFACE
This involved the design of a system which describes or
allows the human-machine interaction.
It is used to represent interaction between the human being
and the computer machine to allow communication while processing data into
information.
Factors to be considered
- Input design (Screen design)
- Control: input interfaces which all correction)
- User guidance
- Error message alert
- Help option for recovery
,
End-User Computing
This can be defined as the direct hand on use of computer
It is also refers to the situation in which users are
involved the specification, development and use of the system and its resources
and application. The end-users include: Manager, Executive, professional staff,
workers and secretaries etc.
The following are the roles of the end-user in
system development
- Presentation of information
- Writing and typing (word)
- Routine transaction processing
- Searching, retrieving information (Dbase)
- Accounting and calculation (spreadsheet)
- End-user programming and coding
- Aiding information communication
Advantages of End-User Computing
- They translate their information needs into application
- They are able to adapt their system to their needs
- End-user are able to satisfy their own requirement in data
processing
- They can exercise autonomy and responsibility for the
system
SYSTEM TEST PLAN
This plan must be carried out on the new system after the
design, the test data will be used to generate the expected results so as to
view how it is.
There are Top-Down test (Each module is tested) and Bottom-up
test (The entire system is tested) methods under which the following tests
could be examined.
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.
Using the test data following test run are carried out:
• System test
• Program test
SYSTEM TESTING
System Test: After carrying out
the program test for each of the programs of the system and errors removed,
then system test is done. At this stage the test is done on actual data.
Unit testing
Each component is tested separately with suitable test data
to ensure that it functions properly and as required.
<
Integration testing
A number of components are tested together to ensure that
they interact correctly to produce the desired response.
System Testing
Using suitable test data, the whole system is tested to
ensure that all the parts function correctly and meet the specification
outcomes.
Acceptance testing
The programs are finally tested with real data in the
environment where they will eventually be used. A number of end users can put
the program through its paces to ensure it meets their expectations with
relation to speed, ease of use, volume of data, consistency, etc.
Dry run
One of the techniques used by the programmer to ensure that
individual modules of a program work correctly is to use dry run.
This involves working through a section of code manually to try to locate any
errors.
PROGRAM TESTING
Program test: When the
programs have been coded, compiled and brought to working conditions, they must
be individually tested with the prepared test data. Any undesirable happening
must be noted and debugged (error corrections).
A number of different strategies can be used to help ensure
the program works correctly.21
Top-down
testing
The various branches of the complete system are tested.
Eventually each component is tested and interrelationships checked.
Bottom-up testing
Individual modules are tested as they are written and
combined to form larger units which are then tested together. Eventually the
whole system is tested.
TYPES OF DATA TEST:
- Normal test: This test method is used to heck that
the new system can handle the set of data that would be expected during
day-to-day use.
- Extreme test: This test involves the use of checking
that the system can cope with the data that lies on the boundaries of what is
acceptable.
- Erroneous/abnormal test: This test is used to check
that the system can identify data that are wrong and reject it.
Benchmark test: This is a standard test conducted prior to purchase or
lease, used to determine how well a hardware or software system might perform
when actually implemented.
<
Reasons for benchmark test
- To ascertain the performance of the system
- To determine speed of data processing on different
applications
- To ascertain the performance of the software prior to
acquisition
- To ensure that correct input of data will lead to correct
output of information
- To ensure the technical capability of the hardware
- To ensure that correct software were developed.
DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical
representation of the "flow" of data through an information system,
modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated. DFDs can also
be used for the visualization of data processing (structured design).
A DFD shows what kinds of data will be input to and output
from the system, where the data will come from and go to, and where the data
will be stored. It does not show information about the timing of processes, or
information about whether processes will operate in sequence or in parallel
(which is shown on a flowchart).
Process Control Flow Diagram
A flow diagram can be developed for the process control
system for each critical activity. Process control is normally a closed cycle
in which a sensor provides information to a process control software
application through a communications system. The application determines if the
sensor information is within the predetermined (or calculated) data parameters
and constraints. The results of this comparison are fed to an actuator, which
controls the critical component. This feedback may control the component
electronically or may indicate the need for a manual action
System
Customer
Database 22
Flowchart
and types
System flowchart: Show
system flow, its components relationship between the system structures.
Program flowchart: Shows
the logical structures of a program modules and their relationship
Importance of flowchart
- It shows the logic used in computer programs and system
- It is easy to prepare and reuse whenever needs arises
- It is a diagrammatic representation of an information
system
- It uses a standard set of symbols to describe pictorially
the flow of data through a system
- It is an analytical technique used to describe some aspect
of an information system in a clear, concise and logical manner.
Selecting the Appropriate Development Methodology
Since there are many methodologies, the first challenge faced
by analysts is to select which methodology to use. Choosing a methodology is
not simple, because no one methodology is always best (if it were, we’d simply
use it everywhere!). Many organizations have standards and policies to guide
the choice of methodology.
i. Clarity of User Requirements When
the user requirements for what the system should do are unclear, it is
difficult to understand them by talking about them and explaining them with
written reports. Users normally need to interact with technology to really
understand what the new system can do and how to best apply it to their needs.
The RAD methodologies of prototyping and throwaway prototyping are usually more
appropriate when user requirements are unclear because they provide prototypes
for users to interact with early in the SDLC. Agile development may also be
appropriate if on-site user input is available.
<
ii. Familiarity with Technology When
the system will use new technology with which the analysts and programmers are
not familiar (e.g., the first Web development project with Java), applying the
new technology early in the methodology will improve the chance of success. If
the system is designed without some familiarity with the base technology, risks
increase because the tools may not be capable of doing what is needed.
Throwaway prototyping-based methodologies are particularly appropriate for a
lack of familiarity with technology because they explicitly encourage the
developers to create design prototypes for areas with high risks.
iii. System Complexity Complex
systems require careful and detailed analysis and design. Throwaway
prototyping-based methodologies are particularly well suited to such detailed
analysis and design, but prototyping-based methodologies are not. The
traditional structured design-based methodologies can handle complex systems,
but without the ability to get the system or prototypes into users’ hands early
on, some key issues may be overlooked.
iv. System Reliability System
reliability is usually an important factor in system development. After all,
who wants an unreliable system? However, reliability is just one factor among
several. For some applications reliability is truly critical (e.g., medical
equipment, missile control systems), while for other applications it is merely
important 23
(e.g.,
games, Internet video). Throwaway prototyping-based methodologies
are most appropriate when system reliability is a high priority, because they
combine detailed analysis and design phases with the ability for the project
team to test many different approaches through design prototypes before
completing the design.
v. Short Time Schedules Projects
that have short time schedules are well suited for RAD-based methodologies
because those methodologies are designed to increase the speed of development.
Prototyping and phased development-based methodologies are excellent choices
when timelines are short because they best enable the project team to adjust
the functionality in the system on the basis of a specific delivery date. If
the project schedule starts to slip, it can be readjusted by removing
functionality from the version or prototype under development. Waterfall based
methodologies are the worst choice when time is at a premium because they do
not allow for easy schedule changes.24
SYSTEM
IMPLEMENTATION
The system implementation stage involves setting up,
configuring and installing the new system to make sure or ascertain if it
matches the design specification. It may involve the following: Creating
data file, setting up data validation check, entering enough data ready for
testing the system, creating input and output screen, setting up the user
interface and setting up the system security.
,
Implementation involves:
- Installing the hardware and software required
- Transferring data from the existing system to the new
system (conversion)
- Training users how to use or operate the new system
- Documentation of the system for use
Master File Conversion
This is when the files are converted to the new system before
the system is fully installed to avoid any data loss.
Stages
- Production of control total
- Transaction of data into input document designed for easy
data entry
- Insertion of new data required
- Verification of transcribed data
- Data is used to create new file for running the processing
- Printing out the file for comparison with old file
- Printing out the control total lists
The hardware and the relevant software required for running
the system must be made fully operational before implementation. 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 (Data bank) needs to be setup with
security and recovery procedures fully defined.
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
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.
METHODS OF SYSTEM IMPLEMENTATION
i. Direct changeover method: This method
involves changing from the use of existing system to the new system completely
at once. It is the quickest way but it may be disruptive if any errors are
found afterwards. It involves training of the staff to master the use. It
involves preparation of database and lower administrative cost. There is
feedback if the system does not work.25
Disadvantages:
- Risky because there is no backup in case of failure
- There is no basis for comparison
ii. Parallel running method: This involves
operation of the new and old system alongside with each other for a short
period of time. The problems of new one can be sorted without any disruption.
It requires training of staff. Old system serves as a backup
Disadvantages
- It may be stressful and difficult for user to operate two
systems at a time,
- There is higher running and maintenance cost.
- Duplication of efforts
iii. Phase running method: This method involves
introducing the new system in smaller parts (modules) while leaving the
remaining parts of the old system in place. This is done until the whole parts
of the new system are fully and completely installed. It allows the user to get
use to one part before installing or introducing the other. Modules can be
repaired without affecting other parts.
Disadvantages
- There is possibility of the two systems not compatible.
- It takes longer time before installation is completed
iv. Pilot running method: The whole system
covering one area is changed and nothing else is changed until ensures new
system is working correctly. It involves spread of cost of installation and
training.
Disadvantages
- There may not be possibility of isolating one area of the
business
- The cost of installation is high
- Not all parts of the organization enjoying the first installation
- Full data items are not use at the initial stage
Post-Implementation and Reasons
Post Implementation is an evaluation of a new system in terms
of the extent to which the system accomplishes the stated goals and objectives.
It includes the following reasons:
- To confirm that the planned objectives are being met and so
as to take necessary actions
- To ensure that the system is able to cope and adapt to
changes
- To deal with unforeseen problems arising in operation
26
SYSTEM
DOCUMENTATION
Documentation is the process of delivering totally the use of
the new system to the users, it involve the following:
- The manual and procedural instructions about the system
- Training and guidelines to the staff or users
- The input and output sample report and documentation
- The flowchart and design structure of the system
These are provided along with the new system during or after
implementation stage.
i. Technical documentation
- It is designed to be used by a technician
- It shows how the system was put together and works
- It enables the technician to correct or alter the system
when necessary
Technical documentation includes
(contents):
- System Objectives and overviews
- Technical specification
- Data Dictionary
- Program specifications
- Details of hardware and software required for the system
- Details of data structures (data types, field names etc)
- Data validation check and procedures
- Dataflow Diagram (Diagram showing how data moves through
the system)
- Flowchart describing how the system works
- Details of expected inputs and outputs
ii. User Documentation
- It is designed for non-computer literate user of the system
- It provides training guides to teach the check operators
- It provides simple instruction for using the system
- It directs the user what to do when something goes wrong
User documentation includes
(contents):
- System objectives and overview
- Input stage activities
- Processing and storage activities
- List of hardware and software required to use the system
- How to install the new system
- How to start/stop the system
- Explanation on Error messages that might occur
- A troubleshooting guide
- Examples of input and output samples reports
Types of manual
- Use manual: Provides information that cater for the users
and novices
- Operational manual: Provides information for the technical
users27
SYSTEM
MAINTENANCE
After a new system has been successfully installed and tested
and has been confirmed acceptable. It must be supervised often and time to-time
to ensure its required specification is effective to maintain its integrity.
Changes may also occur to correct any problem that was not found during testing
simply to improve the way the system works.
Maintenance includes Preventive
maintenance, Perfective maintenance, Adaptive maintenance and
Corrective maintenance.
i. Preventive maintenance
This is a type of maintenance carried out in advance of a
problem occurring. Preventive maintenance may be carried out at a time most
convenient to the organization.
ii. Perfective maintenance
This type of maintenance is carried out in order to perfect
the software or to improve it so that the processing is enhanced. It is usually
carried out to improve the performance, maintainability, overall effectiveness
or other attributes of a System. This may be prompted by the availability of
new technology, the development of new techniques or by request for system
enhancement from users.
iii. Adaptive maintenance
This is carried out to take account of anticipated changes in
processing environment, possibly, through. User requirement being changed or
ill-defined as a system is being designed. - The significant change in the
system environment. The system grown beyond the limit that was originally envisaged
for it.
iv. Corrective maintenance. This is as a result of
system failure. It is carried out to correct faults in hardware and software.
Corrective maintenance is reactive and is usually carried out as a result of a
negative experience with the System.
Reasons for system maintenance (The needs for system
maintenance)
- It is a preventive measure against system failure to
improve reliability and minimize down time.
- To keep up-to-date with technological advancement
- The need to meet the dynamic nature of user’s requirements
- To confirm if the system is able to achieve the desirable
output
- To solve unforeseen problems
- To determine if the system is justified in terms of cost
benefits and analysis
- To prolong the lifespan of a system
- To maintain the system availability, efficiency and
integrity
- To increase productivity in terms of output
28
SYSTEM
EVALUATION
A working definition of evaluation is “the process of
assembling evidence that a system
meets, or fails to meet, a prescribed assurance target.”
After a project or system has been implemented, it should be reviewed
periodically to make sure that it is still meeting its objectives. A good
way of evaluating a solution is to ask the users of the system if the system
has been working as required and given the correct report as formerly
specified. Evaluation is very important after system implementation, it is the
process of checking the new system if it meets all expectations by the
following techniques.
- Analyzing the new system compared with the old system and performance
- Going through the requirement one-by-one and ensures all is
alright
- Getting feedback from the users (Users responses towards
using the new system)
- Check the system against the requirement specification
During this stage, the users should be able to tell the
following,
- How effective and efficient the system is,
- Time of running to generate report, and any constraint that
arises.
- Also comparing the operation of the new system to the old
one, does it produce appropriate result or solution?,
- State if there is any improvement to be done on the new
system.
These are the reports to be identified by the users to enable
know how perfect the system is.
METHODS/TECHNIQUES OF EVALUATION
i. Development Evaluation
This is carried out to see if the system was developed within
a time schedule and budgeted amounts, if the system is not well planned, it
will over run schedule and overshoot the budgeted amount when developed.
,
ii. Operation Evaluation
This evaluation involves the ability of a system hardware and
software to cope with the demand of the system and users to see if they are
capable of performing their jobs effectively.
<
ii. Information Evaluation
This is carried out to verify the extent to which information
system is able to generate information to meet the decision making needs of the
organization.
,
Evaluating criteria that may be used in System Life Cycle
- Realized benefits
- Actual cost
- Response timing
- User satisfaction
- Problem areas
- Error rates
Aspect of software that must be evaluated during system
design
- Operating system with
the software will operate
- The programming language to be used to write the software
package
- The utility programs to be included in the software
- The portability of the software
- The maintainability of the software
- The future expansion capability of the software
- The cost and writability of the software
29
Aspect
of Hardware that must be evaluated during system design
- The capacity of the hardware
- The compatibility with software and other components
- The cost of hardware
- How durable and functional the hardware is
Factors that leads to system failure
- If feasibility study is not done properly
- If investigation is not carried out as required to generate
accurate report and identify the actual problems
- Poor system design and prototyping
- Wrong system modeling and structures
- Lack of adequate technical skills and technology backup
- Inadequate system security
Measures to be taken to avoid system failure
- Provision of adequate security for the system
- Use of antivirus software
- Provision of proper infrastructure such as reliable power
supply
- Provision of adequate induction and training
- Restriction of access to the system using software
SYSTEM AMENDMENT REQUESTS
This is a memorandum sets policy on identifying, processing,
tracking, and reporting on requests for amendment of system to perfect if
operation or performance.
Structural changes:
relates to changes in the system architecture or structures by amending any
part not working effectively for corrections.
Operational changes:
Relates to the nature of system operation in terms of speed and time to
generate output in terms of efficiency.30
nice informative post. Thanks you for sharing.
ReplyDeleteWe are an experienced team in one of the Best software company and product specialist for software development and implementation.
NodeJS Development
Web development