The Systems Development Life Cycle (SDLC) involves planning, analysis, design, implementation and finally operation and support. At any point in the in the planning, analysis and design production can be easily halted. The steps are:

• Preliminary Investigation or Feasibility Study: This phase looks at the business considerations, anticipated benefits and costs and makes a recommendation of whether or not to consider with the systems analysis based on economic, technical, operational and other business factors. Frequently this is a result of a request or a problem that appears to exist. It can also be based on length of time the existing system has been in service, efficiency considerations or the desire to find out if there is a better way etc.
• Systems Analysis: This phase looks at the existing system (whether it is manual or computerized) and also looks at the business requirements. The analyst develops a logical model of requirements, data and processing. The end product is the systems requirements document that gives alternative approaches complete with estimated costs. A presentation is usually made of the analysis finds and decisions are made as to whether to proceed. Recommendations are made as to (1) modifying an existing system, (2) developing a new system in house, (3) purchasing a commercial software package that is developed for the system being considered, or (4) contracting for the work to be done by a service organization.
• Systems Design: This phase will design the new system according to the decisions made in the analysis phase. The type of design depends of these decisions. If you are going outside, the design becomes more of a negotiation phase where you try to determine the correct package and discuss the compromises that must be made. You must have gone through an in-depth analysis and you must have made some design consideration decisions before you are in a position to view outside sources and make reasonable decisions.
• Systems Implementation: In this phase, programs are written and tested using a variety of languages and methodologies. The system should be documented, tested rigorously and finally installed for operation. If the system was acquired from an external source it must be installed and tested rigorously. The goal here is to find the errors at this stage before they become part of production. This stage should also include assessment and evaluation of whether the system lives up to the original conception and whether it meets the cost and benefit analysis.
• Systems Operation and Support: At this stage, you are maintaining and improving the system according to company and user feedback. No matter how many times you asked for feedback during the other stages, you will find that changes will now be suggested. Maintenance must be done to correct errors that did not appear in testing, to make changes that are important to the implementation of the system and to make changes caused by changing events such as new government regulations. There should be a period of very attentive maintenance and support and then the system should start to follow the standard system maintenance features maintained by the company.

• Strategic planning involves long term objectives and strategies. When developing a system it must be compatible with the companies strategic planning, mission and objectives
• Systems projects are frequently started as a result of a request to correct problems or to improve the quality of services or information provided. For example this might be to provide better security or more information. The source can be from users of the system, management, the IT department, customers, or government regulations. Frequently things have changes in the technology available and the changes can have an impact on cost or performance. Frequently the change is made because of competition. The Web is an excellent example of this.
• Feasibility looks at economic, operational and technical issues. If there is an existing system then a review of that system is part of the process.
• The preliminary investigation needs to understand the problem or the reasons for the proposed change, it needs to define the scope of the project, it needs to do fact-finding including interviewing and surveying as well as reviewing of the existing way that things are handled (both technically and manually). It needs to make a realistic judgement on the economic, operational and technical benefits and the time and cost involved. Management can then make the decision to continue, postpone or cancel the project.

• Systems analysis involves analyzing the existing system (technical or manual) and understanding the results of the preliminary investigation. Requirements must be explored in more depth. Additional interviews surveys and fact-finding techniques must be used. Observation of the existing system is key to understanding. The end product of analysis is a through understanding of the old system and the objectives for the new system and modeling of the system to be developed. This involves both modeling both the output and input data and the processing that is to be done. A complete understanding is required. Data flow diagrams are frequently a tool of systems analysis at this stage. DFDs show the movement of data through the system including its input, processing and output. The symbols used are for external entities, data flow, processing and data store. Context diagrams show the big picture, focusing on external entities, and data flow to and from the system. Essentially it shows what is being handled in the system and thereby sets the scope and the boundaries. From there you expand the coverage of the system by drawing a level 0 diagram that shows the major processing, data storage and the flow of the data. This is then broken down to show the detail in subsequent lower level diagrams. In my opinion the DFD is a wonderful tool for the analysis phase, I personally prefer looking at systems flowcharts when I am in the design phase.
• A data dictionary is developed to store the information. It should describe each of the elements in the DFD (external entities, data stores, data flows and processing).
• Other tools that are used to model the design are decision tables, decision trees, pseudocode and logic flowcharts - these will then feed into the design phase and the development phase.
• Object modeling is used when the system is being designed with object oriented concepts.

• Systems design involves making decisions based on the analysis that was completed. Designers decide whether to do an in-house system (new or modified version of current), whether to contract the work out (outsourcing), whether to buy a commercial package, or whether to contract for the modification of a commercial package (this would be a value added situation where value is added to a commercial package making it a unique package for your companies needs). Note that a horizontal software package is a package that can be used across a lot of types of operations. For example a spreadsheet, a payroll package or an accounting package are horizontal package. A vertical package works for a particular business so there is a hospital package, a nursing home package, a bank package etc. Clearly you are looking at time and cost considerations in making this determination. Making your own gives you the opportunity to have exactly what you want but frequently time and cost cannot justify this choice.
• If you decide to buy a package or contract the work you must first completely understand your systems requirements, the volume of data that you are dealing with and where you are willing to compromise. Then you must prepare a request for proposal (RFP). Next you need to identify potential vendors by reading trade journals, talking to people at conferences, talking to people in the business, contracting with a consultant etc. You then need to evaluate the potentials by talking to existing users and observing the software being used, testing the software, reading about others experiences. You ten need to decide on the purchase. Here you want to look carefully at the agreements and the maintenance. You need to consider where you would be if the company went out of business and set up a contingency plan. You then need to install, test and evaluate the product.

• Prototyping involves testing the concepts in a "quick and dirty way". Using many of today's database packages or commercial packages, you can set up sample data that let you test the concepts. Generators (report, screen etc) make this an easier process. Many of the case tools allow for generating prototypes.
• Design output
• Design input including user interface (Interface should be easy to use and consistent, it should be effective and efficient to use, it should make checking data and correcting easy to do, it should make help obtainable, it should provide appropriate messages, guidance and feedback to the user, it should make it easy for the user to move around and it should protect the data).
• Design data structures and data file storage
• Database management systems (DBMS) provide the storage structure, the interface between the database and the user accessing the data, a language to manipulate the data and usually some kind of query capability and generator. (Data warehousing is gathering and storing data in special configuration that supports the needs of the company and data mining analyzes and looks for specified or valuable patterns and relationships in the data).
• Once the logical design is in place, it needs to result in a physical plan that can be implemented. Topics to be considered here are the integration of the web, security, initial and ongoing costs, interfacing with legacy systems.

• Design a particular application
• Code
• Test the application separately using test data, test using independent test data, test using actual data, test integration with other applications, systems test. If you write a program you will test it with data you create and with data created by someone else such as the analyst. If live data is available it should be tested there as well. You then need to do integration testing where you test whether the output from one program can be read as input by another program. Finally you test the entire system. There can be complications here because of hardware and other practical considerations.
• Data must be converted to the new system
• There are a couple of ways to finally implement the system. One is to implement it in parallel with the existing system so you can test the results from both (parallel). One is to implement in parts or in stages (phased). Another way is to implement at test sites (pilot). For example, if you are implementing a nursing home package, you could implement at a test site before distributing to all of your clients. The other way is to just cross your fingers and implement the new system (direct). This may be driven by changes in technology that do not allow the parallel implementation
• Documentation of the system should include program documentation, system documentation, operations documentation and user documentation.
• Operations and user documentation should be supplemented with training. Training can be in house, at a training site etc. Tutorials and other automated tools can also be used.
• As the project is being implemented, evaluation should be done

• Documentation, training and help desk are necessary support components
• Maintenance should be very responsive at first and moving eventually to the planned maintenance schedule where requests are made and only emergencies are handled immediately.
• Maintenance includes correcting problems like that got picked up once the system was implemented. It can also include adapting things such as the report where we decide two things should be next to each other or the screen where we decide the progression is wrong. We can also do things that will perfect the system.
• A maintenance plan should be devised where there is a backup plan, a plan to handle requests for changes, a plan to test the system and see if it is meeting standards etc.