Systems development on a large scale was first attempted by the US military in its Department of Defense (DOD) and by the National Aeronautics and Space Administration (NASA). They were therefore instrumental in developing the framework of a sequence of stages or phases for developing a system.
This sequence of distinct stages that a system goes through in its entire life is called the system development life cycle (Anderson 1991). The idea in such frameworks is to understand the detailed issues pertaining to the system in concept development, requirement definition, design, implementation, test and integration, installation, acceptance and operations.
These are done in a structured manner for different levels like system level, subsystem level, specification level, etc. The system itself follows a life-cycle called System Development Life Cycle (SDLC). The key characteristics is such SDLC is that each stage has a definite output and that the outputs include the plan for taking the process forward, the outputs are ratified all outstanding issues in each stage are resolved and that there is mutual agreement between the rectifiers and the developers on the criteria for acceptance. However, these life cycles are typical of large aerospace projects or military projects.
They can be applied only to very large-scale applications. Typically, MIS applications do not fall under this category. Hence, the MIS oriented systems development life cycle frameworks are a little different.
MIS Oriented System Development Life Cycle
MIS oriented system development life cycle is a little different from the above SDLC of large scale aerospace or defense projects. The MIS oriented SDLC is tailored to suit the requirements of business systems. MIS oriented SDLC also has distinct stages and progression from one stage to the next is only allowed after the tasks of that stage is completed to satisfaction. The direction of progression is linear and unidirectional. The SDLC in such cases involves the following distinct stage or phases:
System Definition Phase
System definition is that phase in which the system takes shape and form logically, but not physically. In this phase a series of stages and steps are taken to come up with a set of guidelines on the basis of which the actual construction of the system can be done. The key steps in this phase are the preliminary analysis, feasibility study, and information analysis and system design. In this phase, critical information about the system is gathered from the user, about its requirement, feasibility of such a system is studied and analysis of information is then done which is then translated into a design or blueprint for construction of the system.
Preliminary analysis itself can be segregated into several steps. Preliminary analysis is sometimes called preliminary investigation and is norm211yconducted before the design of information system. This is typically the first step in the life cycle of a system. In this step, the management of the organization is engaged in the process to understand the following:
- The problem/issue that the proposed system seeks to solve
- Information requirement
- Information users, generators and recipients
- Frequency of use of information
- Volume load on the system (amount of data to be transacted by the system)
- Scope of the system
- Boundaries of the system
The main idea is to understand the broad specification of the proposed system by understanding its requirements, objectives, scope and boundaries. Data is gathered and the management of the organization is engaged in the process so that there is no gap in understanding. The following steps are taken in the preliminary investigation stage:
Assessment and survey of situation/environment:
This is the stage when the general environment under which the new system will be required to operate is scanned. In this stage, meetings are held with managers at different levels to understand the overall objectives, mandate, charter and background of the organization. The constraints and limitations of the problem are also understood. The management's perception of the problem is understood at this stage. The main tasks in this stage are to understand:
- The mission, mandate, charter, objective and background of the organization.
- The actual organizational structure and power centers along with their basic information flows.
- The boundaries, input, output, etc., of the existing system.
- The users of the systems and segregate them according to their role and level of usage of the system.
- The problem and accurately define it.
- The maturity of IS usage in the organization and organizational culture.
- The expectation of the management.
Analysis of current system
In this stage, the existing system is studied in detail for two purposes which are:
- To find the constraints of the system and to find its shortcomings.
- To find if the system can be upgraded and reused.
In this stage, detailed meetings are held with the MIS department personnel and the CIO to find the current system performance and its limitations. A manual of the current system is studied. The user's view about the system is also studied to arrive at conclusions about the current system and the reasons for its up gradation or replacement.
Analyze the system requirements and specify the requirements
In this stage, the requirements of users are defined. This is one of the most important stages in the life cycle of the system as the work done in this stage will shape the development process of the system and the work done subsequently will be damaged irreversibly if the work done at this stage is not done properly. Active user interaction is required in this stage to understand the need and requirements of the user. The users' expectation from the system has to be understood clearly before proceeding with the development process. This stage ends with the deliverable system requirement specification which is a formal document identifying the requirements of the system. This information in the SRS document is fed into the analysis and design stage as basic data.
Business Process Re-engineering and Process Improvement
Sometimes in order to develop a good information system that will serve the purpose of management even in the future, it becomes very essential to have a re-look at the way business processes are conducted in a firm. The rationale for this is that the manner in which business is conducted changes with time and an information system that is designed over such out dated business processes would not provide any worthwhile value to managers.
Business organizations are a continuing entity but the products or services that they offer change with time. Even the manner in which it conducts business changes with time. New ways of doing business emerge over time. New markets emerge. New products and services emerge. New geographies emerge. New technologies emerge. All this changes the organization fundamentally. If however, the organization continues to engage with its customers (internal as well as external) in the same way as it had been doing in the past then it risks losing business and efficiency. It has to change its process to remain competitive. However, organizations cannot change individual processes on an ad hoc basis and neither can they change the processes in isolation. Concerted efforts are required and a complete scientific exercise is required to change processes of doing business and to ensure, at the same time, that the business does not suffer from this changed effort. This scientific exercise of overhauling the process of doing business is called business process reengineering (BPR). For example, we are all aware of the process of drawing money from banks. In earlier times, if we needed money, we had to deposit a signed cheque at the bank counter and the counter clerk would give a token then after some time he would announce the token number for the particular token holder to collect the cash. The time spent in between is used by some other clerks who physically check whether the signature on the cheque is that what is recorded against your account. If they get a perfect match, the counter calls the token number and you get your cash. Now, this process of checking of the signature on the cheque and comparing it against the officially recorded version to find out whether it is one and the same is easily done if an information system which is made available to the counter clerk. If the system is so designed that the clerk can himself check the authenticity of the signature by comparing it against the digital picture of the official signature of the account holder on a computer screen in front of him then this process can be done away with. The clerk can just take the cheque from the customer and check the authenticity of the signature on the system and if found correct Can deliver the cash to the customer. We can see here that the process of cash delivery has been reengineered due to the introduction of technology. This change or rather improvement in the actual business process by the introduction of technology or otherwise is called re engineering and the process by which this is done is called BPR. Sometimes BPR is resorted to even when there is no immediate trigger for change in the business process. Most BPR exercises are conducted when a system is being designed for the business. Sometimes, in order to develop a good information system which will serve the purpose of management even in the future? It becomes very essential to have a re-look at the way business processes are conducted in a firm. The rationale for this is the manner in which business is conducted changes with time and the information system designed over such dated business processes would not provide any worthwhile value to managers.
The principles around which BPR activities are performed are:
- Focus on outcomes. In BPR should be on the outcomes rather than activities or functions. A broader view of the process is required.
- Keep users of process outputs/outcomes in the BPR team. This will ensure that real life issues are taken care of.
- Link parallel activities. Treat parallel activities by linking them instead of integrating them to get the full measure of the processing rather than having a simplistic view.
- Capture data once. This is very important as in most cases duplication of data capture happens. This can be avoided by capturing data at the source.
- Eliminate geographical segregation. This is another important concept. This means that a process may be physically distributed in different geographies but in cyberspace, this has little meaning. We must therefore create a virtual space incorporating this geographical diversity and then conduct BPR. This will help reduce a lot of complexity.
BPR is sometimes seen as an algorithm of tasks to conclude that ensures better efficiency. Hence, models have been designed to perform BPR.
As is evident, BPR is a scientific exercise comprising of a set of logical micro tasks. Therefore, it may be worthwhile to define the BPR exercise in the form of a model.
- Business objective definition-In this the goals of the business are crystallized. The goals may be cost reduction, time reduction, etc. Essentially in this stage the BPR team must identify the major driver for the processes in the overall business perspective.
- Process identification-In this stage the critical process that helps in the attainment of the business objectives are identified and ranked according to their perceived importance in the overall business.
- Process evaluation-In this stage the process is examined in detail by first pictorial depiction the process (that may be done after actually passing through/seeing the process in action) and then finding out the areas that are redundant or can be made redundant after adequate use of managerial or technological intervention. In this stage the process is examined from a cost and time perspective which helps to understand the efficiency of the process. In most cases, this exercise results in process improvement.
- Process specification-In this stage process specifications are plotted in a process diagram.
- Prototyping-In this stage, a working model of the software that mimics the process is created in collaboration with the developers and the customers. This prototype acts as the basis for further development.
- Refinement-The feedback on the prototype is factored in the new design and a process of refinement of the prototype starts. This step may involve several stages of refinement to arrive at a fully functional system.
This is a broad template that ensures that the BPR exercise is done systematically and not on an ad hoc basis.
Process improvement-It is the activity of critically examining a process with the objective of making it more efficient. In most cases, it involves the shortening of the process, reduction of people handling the process, intervention of technology, changing the manner of doing tasks within the process, reduction of cycle time of tasks in the process and reduction in the cost of conducting the process. This is achieved by first examining the process and passing through it. Then a process map is created and bottlenecks and redundancies identified. These areas are then worked upon to-make the process more efficient.
Webster's New Collegiate Dictionary defines feasible as capable of being done or carried out. Capable of being used or dealt with successfully. As is clear from this definition, feasibility from a systems perspective looks at whether a system can be developed successfully given the technical endowment/environment/possibility, resource constraints and organizational desirability. In a feasibility study, we analyze whether the system should at all be developed and if yes, then how. This is done with respect to certain dimensions. It is essentially a techno managerial analysis to establish the capability to complete successfully the development of the system given the ground realities. There are several dimensions of feasibility, like technical, economic, organizational, legal, ethical, social-economic and social-political. However, the first three are the major dimensions. We will discuss them in details.
Dimensions of feasibility
Technical feasibility indicates whether the proposed system can be developed given the present and near future technological state. If the current technological environment does not support a system development technically then the system is deemed infeasible. However, in the business context, MIS development is rarely faced with technical feasibility problems. Technology in such systems is well-developed and not cutting edge. Hence, not an important feasibility problem.
After the assessment of technical feasibility, one has to check the economic feasibility of a system. Economic feasibility is the study to find if the system will be economically feasible for the organization. Several tools to find the economical feasibility of a system are in use, like cost-benefit analysis, net present value, internal rate of return, etc. These techniques are applied to measure the economic cost-benefit and the return on investment of a system. A system will only be economically feasible if the benefits or returns from the system are several times more than its cost. Typically, the system should not only recover the cost of development but should give an acceptable return on investment by improving processes, decision-making capability, efficiency, etc., in the organization. Measuring economic feasibility may be difficult in some cases where the benefits are not clearly understood or may be risky or may be very complicated to calculate. Sometimes the economic benefit from a system may not be direct but indirect. In such cases, the economic feasibility may be very difficult.
Organizational feasibility deals with the capability of the organization to make operational successfully the system, several issues come to the fore in such feasibility analysis. They are:
- Whether the organization is mature enough, information system usage wise, to warrant implementation of the proposed system?
- Are the employees capable of handling a system like the proposed system?
- Does the installation of the proposed system hamper the work schedule in any manner?
- Is the proposed system compatible to related systems in the organization?
- Does the installation of the proposed system involve job cuts and very large-scale change?
The suitable answers to the above issues will indicate whether the system is feasible organizationally.
Steps of a feasibility study
The following steps are taken to conduct a suitable feasibility study
- Define the objectives of the feasibility study: It is always better to define the objectives of the feasibility study upfront before embarking on the actual study. This clears away any ambiguity and sets the focus of the study.
- Study the current environment: This is important as the system is going to work under a set of environmental variables and not in isolation. Hence, the current environment needs to be studied.
- Analyze information requirement: Information requirement for the system should be studied, as the feasibility of getting such information may itself be an issue. If the proposed system is such that the information requirement from it is not feasible then the project becomes infeasible even if developing the system may be feasible.
- Generation of alternative solutions: One must use this opportunity of conducting a feasibility study to come up with alternative solutions as this is the last stage where substantial monetary resources is not required. All stages and phases after this will involve large amounts of material resources. So this, in a way is the last opportunity for the organization to look at alternative solutions realized during the feasibility study. The entire system is given a re-look as this is a good time to brainstorm about alternative solutions.
- Report preparation: This is the last step of the feasibility study in which a formal document is prepared indicating the feasibility of the project. If the system is feasible then, the report gives clear indications to that effect. This is a formal document and is referred to by the organization at various stages of the development process.
Information System Analysis
This is also called the logical or conceptual design stage as in this stage a thorough analysis of the system (from a logical perspective) is done. The system defined in broad terms is segregated in a hierarchy of black boxes (each denoting some functionality). Each box is a module with a specific role in the overall setup. In this step for the first time the system takes a conceptual shape. The logical modular design of the system is then discussed with the management and after suitable changes the physical design is prepared.
In this stage, the logical design of the system and its inter dependencies on its subsystems is designed as per the requirements stated in the earlier stage. At this stage, the entire system is fully conceptualized and logically defined in abstract terms in a logical design document. Data flows, data stores and processes which make the system are designed and depicted in specific design documents. Subsystem dependencies and their data flows, data stores and processes are also designed and integrated with the overall system. A complete logical view of the system which fulfils all the requirements that is prepared at this stage.
A comprehensive project plan is also prepared at this stage which includes the activity wise time schedules of development of the system, work force requirement at each activity and timelines thereof, budget, training requirements, testing plan, installation plan, change management plan, resource plan, organization plan and documentation plan. However, the actual content of the project plan may vary from project to project depending upon the scope and size of the proposed project and the amount of developmental effort that needs to be put in for the project.
In this stage, the details of the system are elaborated. In this stage, the logical design is elaborated and a physical design documents is prepared. This design document contains all implementation details of the system, like hardware details, database structures, data structures, network and communication details, application software details and interface details.
Details about data sources input and output files, processing, testing and information flow is part of the design. In this stage the entire system is put on papers and explained in diagrammatic terms. A lot of diagrammatic tools are used at this stage to create the design. These tools need some getting used to as they are technical tools which mean specific activities for each symbol. This is required as not everything can be explained in plain English. Rather a design diagram indicating the physical data flow or a use case indicating the objects and their inter-relationships give a better idea to the developer who is the intended user for the design document.
System Construction Phase
In this phase the system is actually constructed. The phase has two steps. The first step is the application programme development. In this stage the design document is thoroughly studied and based on the design and an application programme is created. This is an activity requiring the maximum workforce and material resources in the entire life cycle of a system. Also with the application program, the procedures to interact with the system are also developed so that various levels of users can interact with the system with different modes of interaction.
In this stage the actual software that is the major part of the system is developed. Actual codes (lines of code or LOC) are written in a computer programming language under a software environment to create the software for the system. The number of LOC determines the size and cost of preparation of the software. A model called COCOMO model is used before embarking of the project to estimate the project time and cost. Estimation of the software cost and effort is an important exercise that has to be done before starting the coding process. Function points in the software are identified and the effort required for each function point is estimated. Another alternative is to estimate the LOC and then make an estimate of the time and effort. Programming can be done with a top-down approach or a bottom-up approach depending upon the strategy of development. Typically, this step involves the following:
- Database design and creation of database structures-the data has to be stored in a data repository. Typically, relational databases are used for data storage. These relational database management systems have to be designed and structures have to be created so that the data from the application can be stored in the database. Hence database, tables and views are created which are crucial for data storage.
- User interface design and development-the user will interact with the system by means of the user interface. This has to be designed in a user-friendly manner and developed as per design. Typically, graphical user interfaces are created.
- Programming to create functionalities-the core functionalities of each module has to be coded. This is done in this step. Based on the design specification and the logical flow of the system, the coding for functionalities is done, keeping track of the interdependencies.
- Creating connectivity with the database and the application-the application will need to interact with the database by transacting with it. Hence, connectivity is required. This sometimes become an important issue as the database may be housed in a different geographical location under a different operating environment than the application complicating the data management.
- Incorporation of the business logic into the software-the application is developed to suit the process needs and requirement of the business and hence all data validation and processes are as per the business logic of the organization. This has to be incorporated in the software. Typically, this is incorporated in a middle tier.
The codes are then tested for errors. Load testing is also performed to check if the software will hold when the pressure of actual volume of data is loaded onto it.
In this stage, the user's interaction with the system is laid down. Not all users are allowed to conduct all functions in the system. Different levels of users will have different access. The procedures for the user to access information from the system have to be clearly stated to the user in the form of operating procedures, manuals, etc. This will help the user navigate through the system without any problem. Key tasks are given in a flow chart pattern to help the user gain fast understanding of the system.
In this stage, the system is implemented in the organization after the coding and testing is over. Implementation is not a straightforward issue. It involves a lot of managerial interventions. Typically, implementation tasks can be the following:
- Planning for implementation-in this step the implementation plan is prepared. Action points are spelt out and schedules are prepared.
- Communicating the implementation-clear communication is initiated with the user community so that there is no ambiguity. Users must know when to expect the new system so that they can prepare themselves for the new system.
- Organizing the MIS personnel-the MIS department will be the custodian of the system and hence they have to be organized in order to take care of the system.
- Selecting and procuring the hardware-steps are initiated to procur8 hardware, rules and procedures are prepared for this.
- Procuring the system software (OS)-steps are initiated to procure system software, rules and procedures are prepared for this.
- Create and deploy the database-as per the software design a database is created with all the required structures. Rules and procedures are created along with security interventions.
- Train users-training is initiated for the users to enable them to work on the new system.
- Create and develop physical infrastructure-physical infrastructure is created and developed to house the new system.
- Transition to the new system-is the process of transition from the old system to the new system.
Major problems can crop up during implementation and the task of an implementer is often that of a fire fighter. Trouble shooting of system and people related issues in this phase are routine.
In the stage when the system is in operation the major tasks are those related to maintenance to ensure that the system functions smoothly. At the beginning of the operation phase, a post audit may be conducted to find out the efficacy of the new system.