SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) IN COMPUTER SCIENCE

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