It used to be that “Information Systems” requires managing archives containing volumes of paper based data. In other words books, most in hardbound, bulky to say the least and very difficult to keep track and retrieve.
In the 21st century most information are found in servers or databases that requires considerably less space. The retrieval and tracking process is in split seconds, and most of the time this kind of system requires no human librarian. Still this does not mean that the creation of a new information system would be a walk in the park.
A careful understanding of how systems work and how developers work together is required of any project coordinator or manager tasked to develop a new information system.
This paper would look into the use of Systems Development Life Cycle (“SDLC”) as a model for developing a new information system. The study would present a detailed description of SDLC components, that are enumerated as follows: 1) Planning phase; 2) Analysis phase; 3) Design phase; 4) Implementation phase; 5) Maintenance phase.
The Life Cycle
The Systems Development Life Cycle is a popular model used by systems engineers, programmers, and administrators to initiate the development of a new system that is usually related to information technology. For the purpose of simplicity and focus this study would look into the different phases in the life cycle of developing new computer software with the goal of enhancing an organization’s information system.
Before going in-depth into the components comprising the SDLC it is important to note that there is no one person or group who have sole ownership of the SDLC idea.
In other words this so called life cycle theory of systems engineering can be defined in many ways. In fact the phases commonly identified with it – just like the phases in a biological life cycle of insects for instance – can be described in more than one way.
There are some who are comfortable in describing SDLC as having six phases. In the book about system development, Michael Bronzite (2000, p.8) provided a variant of life cycle development model that have six phases:
There are those who are more comfortable in describing SDLC, as having seven phases (Wynmore, 1993, p. 28-37), namely:
§ System Requirements – defining the problem/requirements of the organization
§ Concept Development – finding solutions/ interdisciplinary inputs to see the big picture
§ Full-scale engineering development – working out detailed specifications
§ System Development – production, manufacture, installation and deployment
§ System Test and Integration – test and document results in real environment
§ Modification – reevaluates the system with the goal of improving it
§ Retirement and Replacement – recommend retirement and replacement of system
Now, that a big picture understanding of what SDLC meant – to different organizations and systems engineer – the proponent decided to simplify and add focus to the study by compressing the different stages into only five. This was done to use SDLC in the context of designing a information system using software, hardware and human resources interacting together to improve an organization’s ability to access and store information. The five phases will be discussed in detail in the following pages.
There comes a time in the life of a progressive organization when management and the designated systems engineer will find the need to improve their current information system. It is assumed that at this point the organization sees the development of a new information system very beneficial to the continuing growth and success of the company.
The planning phase is the starting point for all future activities related to system development and it is at this early stage when the feasibility of the products is determined. Then a timeline is drawn up, partly ensuring feasibility of the project and partly to give a heads up on every member of the organization that in the near future there will be specific tasks that will be undertaken by the personnel tasked to do the job.
Another important aspect of this phase is to put on paper the budget for the project. An example would be to figure out how much it will cost if employees will have to be paid overtime rates to finish the project, or the cost of hiring consultants and other experts to pitch in and complete the task. Moreover, in the event that there is a need to purchase new equipment, the budgeting committee will have to ascertain that the company can afford a shopping spree. In this manner, management will already have an idea what it will cost and thus give finality to the feasibility of the undertaking.
The Planning Phase provides a map so to speak of where a team is heading. It can be considered as a bird’s eye view of the battleground and provides for a general idea of the problems and challenges that the team will encounter when they will hit the ground.
A Detailed Look
The Analysis Phase is when the team swoops down and takes a closer look. In other words, the activity required is to have a more detailed analysis of the problem and also the proposed solution to the problem. Harold Kerzner in his book about project management made the following comments regarding the value of analysis and he wrote that there is a need to refine the planning phase which he elaborated as follows:
… a firm identification of the resources required and the establishment of realistic time, cost, and performance parameters. This phase also includes the initial preparation of documentation necessary to support the system (2003, p. 69).
In some cases, the team does not have to start from scratch because there is already an old system in place that only needed upgrading. In the Analysis Phase there is a need to evaluate the old way of doing things and what can be done to improve and enhance it.
In a more technical approach, Wymore pointed out that there is a scientific way of finding a solution to ensure that the created system will be perfect fit for the organization, and he calls it the “trade study”. Wymore elaborated that the trade study basically solves the following problem, “Among all perceived alternatives, find the best X to satisfy the system requirements, where X might be nay one of the design concept […] assignment of system functions to physical components, input/output functional design etc…” (1993, p. 50).
After this stage the team assigned to the project will figure out if a totally new system is required. An example would be the conversion from analog to digital, which can be considered a total paradigm shift. This kind of change will require major changes in the kind of equipment to be used and a major retraining of the employees or the designated users of the new system.
There are two stages in the design phase and the first one is called the “logical design” which deals with, “…cost effectiveness, performance improvement, user friendliness, enhanced office automation, better compatibility with standards and so on” (Bronzite, 2000, p. 9).
This sub-stage aims to make the new system understandable to all concerned personnel. The logical aspect must also consider that whatever is being done can be easily communicated to the users and therefore easily integrated into the whole system.
In this sub-stage the designer of the new system will have to show how the final product would look like or maybe sound like. Examples could be the files to be used, screen layouts, report formats and so on (Bronzite, 2000, p. 10).
When all the planning, designing, and theorizing are all done it is time to execute. And in the age of computers the major part of the system design is in the writing of software followed by testing how it works in the real world.
Writing code is creating the software that will handle the physical components of the system such as networked computers, hardware, and other peripheral equipment needed to do the job.
After designing and coding the software for the new system and before implementing it, a test must first be performed. In the book about designing automated systems, Dustin, Rashka, and Paul asserted that a tests is a very crucial part in the whole process of implementing a new system (1999, p. 13). But the authors did not only stress its importance they were even explicit that the tests must be planned and this is what they wrote:
During this phase, the test team identifies test procedure creation standards and guidelines […] test data requirements; a preliminary test schedule; performance measurement requirements; a procedure to control test configuration and environment; and a defect tracking procedure and associated tracking tool (Dustin, Rashka, and Paul, 1999, p. 13).
Bronzite clarified that the ultimate goal of test planning and the testing methodology itself is to look for weaknesses in the newly designed and newly engineered system. Bronzite described this method as subjecting the system to, “…a set of simulated real-life test sequences to check for a) obvious errors of design, and b) conformance to the original system specifications in terms of operation and performance (2000, p. 10).
The key word in the test sub-phase is “real-life test sequences” this means that potential users must test the system in real time as it is being applied to day to day problems in the office. The new system must contribute to improvement in the performance of the user. At the same time the tester must able to find out the learning curve and also the consistency of the system in diverse conditions.
When the team is satisfied that the final product has passed the test with flying colors then its time to integrate the system into the larger scheme of things. Bronzite was able to put it succinctly by saying that the final leg of the implementation phase is, “The transference of the finished system from the developer’s test-bed conditions to the client’s operational environment” (2000, p. 10).
Wymore adds that in the integration stage, the typical reaction from the systems engineer is described as follows, “…supervises and coordinates integration of the physical components into a system whose physical components will work together to satisfy the customer’s operational need” (1993, p. 52).
The work of those assigned to create a new system is not over after turnover to the client or the manager. Systems development is a continuous process of upgrading, enhancing, bug fixing, maintenance and finally retiring the system when the time comes to replace with a newer model.
Bronzite again was able to summarize the key points of this phase into the following, “All the additional work on the system that is carried out after hand-over. This may include error-fixing, adding extra features, or full performance upgrades (2000, p. 10).
The SDLC is a model of system development that borrows from the life cycle development concept of organisms. Simply put there is a beginning and an end and that it occurs in a cycle. This also means that the stages are progressing from simple to complex.
The beginning phase is the Planning Phase where ideas are birthed. Just like in the biological world, the idea grows into something that could now be used as a basis for working on a new system.
After the basic planning stage, the development of the system is taken further by a detailed analysis of the problem as well as the proposed solution. Sometimes the solution is not a totally alien concept from what the organization is currently doing. This means that sometimes the solution calls for to simply enhance an old model that is currently being in use. The analysis stage would look into the old paradigm and watch closely to figure out its weaknesses or maybe to find out why it is already outmoded and requiring replacement.
The next level is the design phase where the development team is now set to specify the solution in terms of a logical design as well as the physical design. The logical design provides for a mental picture of how things will flow and a logical order of steps to produce a desired result.
The physical design aspect deals with the more tangible part of the design, the things that people see and hear when the system is in place. An example would be the kind of layout that would be displayed on screen after the software is initiated. Another example would be the format of the report when someone desires to see a printout of the data.
After designing, the rubber will meet the road when the plans would be executed. In this stage the systems engineer can decide to either manufacture the equipment needed or buy them. The systems engineer will also order the programmers to begin writing the code using the data taken from the analysis and design phase. In this manner the written code for the software would be according to the specification outlined by the client or by management.
A test will be performed using real time and real office scenarios just so to find out the integrity of the new system. The system will be tested on the basis of improved performance, consistency, and accuracy. When the test results satisfy the specification described by the client then the new system will be integrated into the larger system where employees and the whole office setting will interact.
There can be no perfect system and therefore a final stage is required which is the maintenance phase. This does not simply mean maintaining the status quo of the system since a good systems engineer is unceasing in the search for an excellent system. Therefore feedback from the user will be recorded and improvements will be made. Errors will have to be fixed.
In the end the system will have to be retired or replaced. This sets-up a continuity of the cycle since the systems engineer together with the client will have to do the steps all over again.
In closing the SDLC has proven itself to be a valuable tool in developing a new system. This is because the life cycle model is easily understandable and can also be easily communicated to any member of the development team.
The life cycle model can also easily provide management or the client place to start. In a very complicated world of systems development, the client must not feel overwhelmed at the initial stage. The SDLC model is like a good presentation tool that would enable the client to make a decision whether to pursue a possible solution or not. It is not intimidating at first glance and immediately provides the client with an estimated budget and timeline as to how long the project will last. Sometimes these are the only things needed start solving a problem.