2. MARCO TEÓRICO
3.2. FASE II: PLANIFICACION
3.2.5. EVALUACIÓN DEL AMBIENTE DE CONTROL INTERNO
1.0 Introduction 2.0 Objectives 3.0 Main Content
3.1 Information System Development Stakeholder 3.1.1 MIS System Analysis and Design
3.1.2 MIS Object Oriented Analysis and Design 3.1.3 MIS System Development Life Cycle 3.2 Stages in System Development
3.3 System Analysis 3.3.1 Analysis Tools 3.4 System Design
3.5 System Implementation
3.6 System Review and Maintenance 3.7 Organisation and Method (O&M) 4.0 Conclusion
5.0 Summary
6.0 Tutor-Marked Assignment 7.0 References/Further Reading
1.0 INTRODUCTION
The software is one of the major components of a management information system. Some of the software used in a MIS system is off the shelf. These include packages such as spreadsheet programs, database applications, etc.
However, they are times when off the shelf, software does not meet the business requirements. The solution to this problem is custom made software.
This unit will focus on the methodologies, analysis and design used to develop custom software.
159
2.0 OBJECTIVES
At the end of this unit, you should be able to:
• discuss Information Systems Development Stakeholder
• explain MIS Systems Analysis and Design
analyse MIS Object oriented analysis and design
describe MIS Systems Development Life Cycle (SDLC)
discuss Waterfall Model, Agile Development and Prototyping
enumerate stages in system development 3.0 MAIN CONTENT
3.1 Information Systems Development Stakeholder
A typical information systems development usually has three (3) stakeholders namely:
• Users – Users are the ones who use the system after it has been developed to perform their day to day tasks.
• Project sponsors - this category of the stakeholders is responsible for the financial aspect of the project and ensuring that the project is completed.
• Developers – this category is usually made up of systems analysts and programmers. The system analysts are responsible for collecting the user requirements and writing system requirements.
The programmers develop the required system based on the system requirements that is developed by the system analysts.
The most important stakeholders in a project are users. For a project to be accepted as being completed, the users must accept it and use it. If the users do not accept the system, then the project is a failure.
3.1.1 MIS Systems Analysis and Design
Systems analysis and design refers to two closely related disciplines system analysis and system design.
• System analysis is concerned with understanding the business
160
objectives, goals and developing business processes. The end product of systems analysis is systems specifications.
• System design uses the output from system analysis as its input. The main objective of system design is to interpret the system requirements into architectural, logical and physical designs of how the information system to be implemented.
3.1.2 MIS Object Oriented Analysis and Design
Object-oriented analysis and design (OOAD) is closely related to systems analysis and design. The main difference between object-oriented analysis and design (OOAD) and systems analysis and design is that OOAD uses objects to represent real-world entities.
Object oriented analysis and design uses visual modelling to improve communication among all stakeholders and produce high-quality products.
An object is a representation of a real-world entity such as a customer, a product, an employee, etc. Unified Modelling Language (UML) is a general-purpose language used to create visual designs for a system (see section on UML).
3.1.3 MI S Systems Development Life Cycle (SDLC)
The system development life cycle refers to the processing of planning, creating, testing, and deploying an information system. The main objective of system development life cycle is to produce high-quality information systems that meet or exceed the expectations of the users within the stipulated budget and time frame.
SDLC uses a number of development methodologies to achieve this objective. The next sections will discuss some of the most popular development methodologies.
Waterfall Model
The waterfall model uses a sequential design model. The next stage starts only after the completion of the previous stage. The first stage is usually drawn on the top and the subsequent stages below and to the left bottom.
This forms a waterfall like structure, and it's where the name came from.
161 The main objective of the waterfall model is
• Planning
• Time scheduling
• Budgeting and
• Implementing an entire system at once
The waterfall model is ideal when the user requirements are clearly understood and are not expected to change radically during the development of the information system. The waterfall model is ideal in situations where a project has a fixed- scope, fixed time frame, and fixed price.
The biggest challenge of the waterfall model is adoption to change. It is not easy to incorporate new user requirements.
Agile Development
Agile development is an alternative methodology to traditional project management which promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
A sprint in agile terms is a well-defined task to be accomplished within a given time. Sprint goals and durations are set by the customers and development team.
All stakeholders must meet in person to get the feedback on the sprint before they can move on to the next sprint if any.
Agile methodologies usually follow the agile manifesto. The agile manifesto is based on the following twelve (12) principles
162
1. Customer satisfaction through early and continues delivery of software
2. Welcoming changes in requirements any time of the project 3. Frequent releases of working software usually on a weekly basis 4. Collaboration between business people and developers when
working on a project
5. Projects built around motivated and trusted individuals 6. Efficient and effective Face-to-face meetings
7. Progress is measured based on working software
8. Sustainable development, sponsors, users, and developers should be able to maintain a constant pace indefinitely
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity
11. Self-organizing teams
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
The following diagram illustrates how agile development methodologies are implemented.
Prototyping
A prototype is a semi-functional simulation model of the actual system to be developed. Prototyping development methodologies make use of prototypes. Prototypes allow both developers and users to get feedback early.
Prototyping makes it easy for users to specify their requirements and developers understanding the requirements of the users because of the prototypes. A prototyping methodology stands with identifying the basics system requirements especially the input and output from the system. These requirements are then used to create a simulation model that users can interact with and provide feedback. The user feedback is used to enhance
163 the prototype and make other important decisions such as project costing and feasible time schedules.
The following diagram illustrate the stages of prototyping
3.2 Stages in Systems Development
Introducing computers to organizations involves either replacing existing manual system with automation or replacing existing computer systems with better and more efficient systems. Generally, introducing computers can be likened to construction of an edifice, whereby expert opinion will be sought from land surveyor and soil engineer as to fitness of the land area for the purpose intended, architect would be contacted for suitable design that suits the owner and conducive to the area; the services of building engineers or quantity surveyors will be required to estimate the costs of the project. After the necessary survey plans and architectural designed are approved and costs estimates ascertained, then construction work can commence.
During construction, plans are constantly referred to ensure that the objectives are still being met by the quantity surveyor. When construction is completed the quantity surveyor satisfies that the set objectives have been achieved. The various stages involved in construction of an edifice can be stages and each one with appropriate term.
Similarly introducing computers in an organisation must follow a definite pattern for the desired results to be achieved. The stages involved in development of a new information systems is referred as System Life Cycle. Information systems development involves analyzing the entire organisation which may comprise the organization structure, procedures and computer systems. It is not likely that a computer expert or consultant would randomly recommend a new system without going through the System Life Cycle. However, his efforts may not be distinctively categorized into stages.
164
The computer expert efforts would involve:
• investigation and recording of the existing system
• analysis of the recorded facts
• design of the new system
• implementation and review of the new system The System Life Cycle
Traditionally, stages involved in System Life Cycle can be categorized and in the following order:
• Preliminary survey or initial study
• Feasibility study
• Investigation and fact recording
• Analysis
• Design
• Implementation
• Review and maintenance
The start of a new system life cycle is normally as result of some problems such as failures or limitations of the existing system causing dissatisfaction or awareness of modern developments. Whatever the reason it is management who will initiate the selection of a project for preliminary study or investigation.
Although the detailed study will be done, it is sufficient to know briefly the concept involved in each of the stages as set out below:
Preliminary Survey: The purpose of this study is to establish whether there is a need for a new system and if so specify the objectives of the system. This study is usually carried out by Steering Committee which comprises of the Analyst and/or the data processing (DP) manager with the managers of all the departments concerned.
Feasibility study: The aim of feasibility study is to investigate the project in sufficient depth to be able to provide information which either justifies the development of the new system or shows why the project should not continue. The questions, which this study addresses, include:
(a) What are the likely problem areas, which will need special attention?
(b) What are the likely computer configurations, which would be suitable?
165
(c) What are these configurations likely to cost in terms of money, staff and time to design, to install, to test, and to run?
The findings of the feasibility study are presented to management in the form of a report, which will make appropriate recommendation. If the report findings are in favour of the project then senior management may decide to move to the next stage.
Investigation and Fact Recording: Detailed study is done in this stage. This study is more detailed and comprehensive than the feasibility study. The purpose of this study is to fully understand the existing system and to identify the basic information requirements.
Analysis: Full description of the existing system and the objectives of the proposed system should be analyzed to produce specification of the users‘ requirements. The Requirements Specification should be presented to the management for approval before system design is embarked upon.
Greater emphasis is placed upon this stage to avoid more expensive and frustrating errors, which failed to meet requirements at the design stage.
Design: If management concludes that it should go ahead with a particular system, or further explore several alternatives, the systems analyst will then prepare several proposals which must be complete in every probable and possible detail. The analysis may lead to many possible alternative designs. E.g. combinations of manual and computerized elements may be considered. Once an alternative is selected the purpose of the design stage is to work from the requirements specification to produce System Specification. The system specification will be a detailed set of documents, which provide details of all features of the system.
Implementation: Implementation involves executing the detail set out in the system specification. Two particularly important tasks are programming and staff training. Most computer systems are implemented on a modular basis, i.e. the overall design system will be broken down into a series of sub-units (modules), each one being thoroughly tested before becoming operational. As each module proves to be satisfactory it will be integrated into developing overall system.
Maintenance and Review: Once a system is implemented and in full operation it is examined to see if it has met the objectives set out in the original specification. Unforeseen problems may need to be overcome and that may involve returning to earlier stages in the cycle to take corrective action.
166
Documentation
Some documentation must accompany all stages in the cycle. The most important are:
(a) Feasibility Study Report (b) Requirements Specification (c) System Specification Initial Study
The analyst establishes the need for a new system and its objectives in this stage. He begins his tasks by choosing a particular area of study. The selection process may be carried out by a team of departmental representatives headed by an experienced manager, e.g. Chief Accountant (Steering Committee). The initial study report may recommend that there is no need to have further and costly investigation. Computerization may not be suitable and existing systems may be strengthened or improved possibly after an O & M (Organisation and Method) Study.
Steering Committee
Factors which may lead to the Board or Top Management to set up a Steering Committee and commission a feasibly study is:
• shortcoming or bottlenecks with the existing system
• obsolescence of current data processing equipment
• requirements for increased speed of processing and reduction in costs
• need for an improved information systems
The Steering Committee will normally include representatives of top management from each department affected by the project and the committee will be directly responsible to the Board of Directors.
A typical constitution of the steering committee consists of:
• A Senior Manager as Chairman
• Managers of the user departments
• The Senior member of the DP department
• A representative from any organisation (external) involved, e.g.
consultants.
167 Functions of the Steering Committee would include:
• giving approval to individual DP projects or approval for the next stage of a project to go ahead
• making recommendations to the Board on acquisition of the computer
• monitoring and controlling individual projects e.g. monitoring progress, and actual costs compared with budget
• ensuring that projects are worth their cost i.e. that their benefits (financial or otherwise) outweigh their costs
• appointment of the Feasibility Study Group
• selecting the systems development staff
• negotiating with supplies of hardware and software
• assessing the contribution of each project to the long term corporate objectives of the organisation
• ranking projects in order of priority and assigning resources to the most important projects first
• taking decisions to deter projects when insufficient resources are available
Since steering committee has a responsibility for the costs and benefits of new projects, a senior accountant should ideally be a regular committee.
Feasibility Study
The main objective of a feasibility study is to assess the data processing requirements of the organisation, to investigate and recommend possible solutions and to provide management with information on which a decision can be based.
Composition of Feasibility Study Team
i. Some members of the team should be drawn from the affected departments.
ii. One person with a detailed knowledge of computers and systems design
iii. At least one person with a detailed knowledge of the organisation iv. Consultants might be hired to assist the feasibility study team.
Objectives (Terms of Reference) of Feasibility Study
The objectives of feasibility study must be established by the steering committee with the Board approval for the System Analyst and his team to
168
work upon. These may include to:
• reduce staffing/administrative costs
• improve accounting procedures
• provide a better service for customers/clients
• improve cash flows by producing invoices and statements of account early
• improve the flow of information for management
• improve stock control, better credit control
• improve the accuracy of information and data on business documents In order to achieve the designated objectives, it is necessary to select the areas of the business most likely to achieve them which have several of the following characteristics:
• Large volumes of data to be processed
• High proportion of repetitive operations
• Need for speed (to get information fast)
• Need for accurate information
• Complex processing problems Contents of Feasibility Study Report
• Outline of present system, listing its procedures, input, output file, security features, controls/constraints.
• The basis for reporting back to the steering committee of Board
• The responsibilities of the members of the feasibility study team
• The budget, in respect of time, cost and resources allocated to the study
• The method of working and contacts within affected user departments
• Outline of proposed system with alternatives considered and proposed preferred solutions
Cost Contribution of Using a computer – Some of the elements of costs which must be considered include:
• Equipment costs (capital costs/leasing costs) of computer and peripherals
• Initial system supplies (e.g. tapes, diskettes, ribbon, papers, etc.).
• Installation costs – new building if (necessary)
• The computer room (lighting, air-conditioning) etc.
169 Fact Finding Techniques: the main techniques for gathering facts about a current system include:
Interviewing: This technique is most widely used and it is the most productive. During interview facts about what is happening come to light, together with the opinions of the interviewee regarding weaknesses in the system. The personal contacts are important in getting the co-operation of the people involved, and in giving them the feeling of having made a substantial contribution towards the design of the new system. It is vital to gain the confidence of the individuals concerned at this stage in order for all the facts to be gathered.
Questionnaire: It serves the time of the interviewer but are difficult to design and are generally considered difficult to complete. It is particularly useful when a little information is required from a great number of people.
Moreover, when the study involves many different geographical locations they may be the only practicable method of gathering facts.
Observation: This is best employed in conjunction with other techniques and carried out after the observer has an understanding of the procedures involved. He will be able to spot irregularities. Observation takes into account details relating to the movement of personnel and forms, the speed of operation, working conditions, idle time, number of staff, bottlenecks and delays etc.
Inspection: This involves the examination and inspection of documents regarding number of entries made, their general state, how they are filed and the effectiveness of the filling system. The study of organisation charts, procedure manuals and statistics, can reveal much useful information about a procedure. However, a close study of the forms currently being used should give the best guide to current practice which may, or may not, accord with the original requirements.
Fact Recording: The most useful charting techniques for recording organizational structures, activities, procedures and flow of data are:
Organizational Chart: This indicates the formal grouping of people into departments and showing the line functions and people involved.
Activity Chart: It describes the breakdown of the structure of a department by specifying what each person does.
170
Procedure Flowchart: It shows the flow of information through a specific procedure of projects. It enables the analyst to be reasonably sure that he has covered all aspects of the system. It provides the basis for writing a clear and logical report. It is a means of establishing communication with the people who will eventually operate the system.
3.3 System Analysis
This is an important intermediate stage between investigation (feasibility study) and system design. The analyst must examine all the facts he has gathered in order to make a proper assessment of the existing system. He must not include ideas in the new system. The aim of this stage is to ensure that all feasible alternatives are eventually produced.
Requirement Specification is an important report produced at analysis stage. The analyst is expected to discuss the requirement specification with the user. He must use the specification to bridge the gap between business user and the technical designer. At the end of these discussions the requirements specification should be in an accepted form, estimates for alternative designs should be prepared, and the decision to proceed with a particular design can be made.
The present system may be criticized against the following principles of procedures, after which the strengths and weaknesses of the system should be apparent.
Purpose; Are the purposes being satisfied? Are they still necessary?
Could they be achieved in any other way?
Economical: Is it economical? Benefits should be related to the cost of producing them. Are there more economical methods?
Work flow: Are the work flows satisfactory?
Specialization/Simplification/Standardization: Are the three S‘s being practiced? Is the work capable of being carried out by machine? Can the complex procedures be simplified? Are standard practices observed?
Flexibility: Is the system flexible? What will be the effect on the system of a big increase or decrease in the volumes to be processes?
Exception principle: Is the principle of exception being observed?
Factors requiring action should be highlighted and not submerged in a mass of routine detail.