The Systems Development Life Cycle (SDLC)
Posted on April 1, 2008 by Jonathan Carr |
An information system records, processes, organizes, and outputs data for end-users of an organization including, but not limited to, small businesses, corporations, and government agencies. The terms information systems (IS) and information technology (IT) are closely related and sometimes interchangeable although IS is business-focused while IT is more technology-oriented. Sometimes an information system is requested to solve a new problem. Sometimes an older system needs to be re-vamped to take advantage of new technology.
There are many different systems development life cycle (SDLC) layouts, however, they all accomplish the same thing from start to finish. Some have 4 steps, others have as many as 12. It depends on how the phases are expanded. Just as a fisherman will tell you their knot is the best, even though many other knots work, I will show you the way I was taught. In order to maintain a systematic approach during the creation of information systems, the process can be broken down into the following phases which represent the systems development life cycle (SDLC):
I. Initiation
The very first phase of the systems development life cycle (SDLC) is initiation which begins with the creation of a needs analysis. A needs analysis establishes an outline of the system. It concentrates on what exactly the goal is as well as what requirements are needed. What will be the final form or deliverable?
After a needs assessment, a feasibility study is conducted to produce a feasibility report. A feasibility report basically gives a thumbs up or thumbs down on whether or not it makes sense to deploy such a system. Usually feasibility studies are broken down into 4 main areas:
First is economic feasibility. Will this system produce a return on investment (ROI)? Does this system demonstrate a good cost/benefit analysis ratio? Does it make economic sense to commit to and deploy this system?
Next is technical feasibility. Does the right technology exist to perform the needed requirements of the system? Are there any technical limitations and/or hardships associated?
Then comes legal feasibility. Does legal language need to be written for this system? Does red tape need to be applied? Do any legal issues arise from the deployment of this system?
Last but not least is organizational feasibility. Does the system have enough support for proper implementation and maintenance? How much change can the end-users of such a system absorb?
Sometimes more areas are considered during a feasibility study, other than the 4 above. If it is determined (usually by a team) that the system is feasible, then a request for proposal (RFP) is prepared and presented for a green light from the department.
II Analysis
The analysis phase of the systems development life cycle (SDLC) begins with the creation of information-gathering channels. Such channels include documentation, interviews, observation, questionnaires, and measuring. Documentation can help establish what the old system does and how it works. Interviews are a great way to gather information because you can find out exactly what makes an end-user happy. Observation can add insight and out-of-the-box thinking to the mix. Questionnaires are great for collecting information from many people. Measuring is important because you will need to measure things like how much space the new system will take up or how many inputs/outputs will be needed. At this point, all requirements for the creation of the system should be noted.
Once the gathered information from the channels is analyzed, it is put into visual diagrams which include flow block diagrams, organizational charts, task templates, flowcharts, data flow diagrams, entity relationship diagrams, and state-transition diagrams. The most common diagram is a data flow diagram like this:
Data flow diagrams visually demonstrate the inputs, outputs, processes, data stores, and policies of an information system. They are a great way to explain how an information system functions and are vital to the analysis phase of the SDLC.
III. Design
Once the analysis phase is complete and all requirements are established, it is time to record a rough draft of the system logic to be used for development. This is the design phase of the systems development life cycle (SDLC). The goal of the design phase is to generate system specifications. These system specifications satisfy requirements set earlier in the SDLC. They are presented as high level vs. detail and logical vs. physical.
There are several design strategies that can be used. Such strategies include outsourcing (both domestic and overseas), buying off-the-shelf, building in-house, or a combination of the three. In addition to the design strategies, special techniques are used. They are process modeling, data modeling, data modeling, computer-aided software engineering (CASE), and object-oriented design (OOD).
CASE tools represent software that allows for strategic creation of logic. An example of a CASE tool is Microsoft Visio. This CASE tool creates data flow diagrams and flowcharts to illustrate the logic of a system. This is a great way to demonstrate the specifications of a system and achieve the goal outcome of the design phase. Here is an example of a flowchart:
IV. Development
After a solid design is in place, it it time for the development phase of the systems development life cycle (SDLC). The development phase is broken down into coding, testing, and documentation.
Coding is where the programmers come into play. There are many different programming languages to choose from nowadays. The newest ones are Python, Asynchronous Javascript And XML (AJAX). Some older ones include C, C++, Java, Visual Basic, and COBOL. There are many others and they all have their pros and cons, but good programmers know what to use for the appropriate situation. Relational databases are usually designed with structured query language (SQL) using applications like Oracle and Access. The coding phase simply takes the logic from the analysis and design phases and translates it to compiler-friendly executable computer commands. These commands are translated into binary code which is handled by computer hardware at the time of execution.
Testing happens after the code has been written and executed. There are a few types of testing.
First is white box testing. This is carried out by programmers who have access to the source code. They can perform corrective maitnenance on the code as they experience errors.
It is rare that the programmers think of all possible errors though and that is when the testing moves to black box testing. Black box testing is done by people who do not have access to the source code. They simply try to crash the program every way they can. Errors are logged and corrected afterwards. Black box testers often think of things that programmers do not.
Next comes unit testing. As software grows in complexity, it starts to develop hundreds and thousands of independent functions that come together to make the software as a whole function. Unit tests are pieces of code that are written to test each of these functions. If each unit passes independently, then the whole is greater than the sum of its parts. This is also referred to as Automated Regression Testing. It can be run automatically each time a change to the program is made, and the pass/fail results can be automatically logged. Whenever a problem is found that that has not been caught by the test, the test program is enhanced to add another case to verify the new problem. Thus, the Regression Test becomes better and better as the project evolves.
After unit testing comes module testing. Module testing is similar to unit testing, except it tests larger blocks of code. Also, unit testing is usually carried out by the original programmers where module testing is typically administered by software quality assurance (SQA) teams. SQA teams possess a different skill set than programmers. They are more specialized in testing than coding. Once SQA is finished testing, they send error reports back to the programmers and the software advances to the next step.
Alpha testing is the next step. It is when the program has most of the important functions working, and all known serious bugs have been fixed. At this stage, the software package is given to a few people inside the organization (not including the programmers) and a few trusted outside people. During alpha testing, people use the software in their normal work environment and this generates good bug data. The error data is sent back to the programmers and the bugs get fixed.
Last but not least is beta testing. After the alpha testing results have been integrated into the software, the programmers now get to say, “Here is our software package, try to break it if you can.” During beta testing, copies of the software are handed to multiple people. Sometimes companies release it to unlimited people via Internet downloads. This allows for more feedback. After beta testing, the programmers have their final changes to make and it is time to deploy.
The master copy of the software is the final version of the software. At this point there are no more changes except for future patches. The software is burned onto CD-ROMS, DVD-ROMS, and other media for mass-distribution.
Next comes the final part of the development phase which is documentation. Programmers will leave comments all over the source code describing behaviors, instances, variables, etc. This is internal documentation. It is beneficial for programmers in the future (who haven’t engineered the code) to have good internal documentation. This cuts the costs when adaptive and perfective maintenance needs to take place.
Also, there needs to be a support system for the software. This is usually done in the help menu of the application. A more recent approach to a help menu is a Wiki. A Wiki allows for end-users to add to the current documentation as they discover better ways of using the software. This allows for collaborative authoring. End-users can achieve a feeling of visibility and importance by adding to the body of support knowledge. All Wiki additions are moderated so that bogus info does not get thrown up on it. This is called external documentation.
Another type of documentation is called system documentation. Sometimes, programmers leave comments in the source code so that the computer runs the software more efficiently. An example of this would be a comment that tells the computer to allocate a certain size of memory.
Once the program has been written, tested, and documented, it is time to implement (deploy or install) it.
V. Implementation
Implementation is also known as deployment. It is the next phase of the systems development life cycle (SDLC). During this transition, the development environment gets shifted to a production environment. Implementation can be broken down into installation and training.
There are four types of system installations that can take place in an organization. It is easy to learn them as the 4 Ps (Plunge, Parallel, Pilot, and Phased).
Plunge is a direct installation. It is where the new system replaces the old system completely. It is the easiest, quickest, and cheapest, however it carries the most risk. If the installation fails, it can be very difficult and sometimes impossible to go back to an older version of the software. Such an installation is great for brand new installations when no previous system exists.
Parallel is when the new system is installed and ran side by side with the old system. It carries the least risk, however, it has the highest associated costs. It is easy to go back to the old system if the new system fails. Once everyone has adapted to the new system, the old system can be removed.
Pilot aka single location is an installation that takes place in a controlled setting. A small amount of people within an organization uses the new installed system while the rest of the organization uses the old system. It carries the same costs of a parallel installation (dual systems running at the same time), but adds time consumption to deployment. If the installation is successful with the pilot group, then the system can be installed across the entire organization.
Phased is when one piece of the software is installed at a time. It allows an implementation team to focus on each piece of software. It is the easiest installation for large complex systems, however, it consumes the most amount of deployment time.
Each type of installation has advantages and disadvantages. Each situation is unique where one type might be better than others. It is up to the implementation team to decide the best method.
Once the system is installed, it is time to train the end-users on how to use the system. Hopefully the new face of the system doesn’t present a radical change from the old software or else the end-user will experience additional hardships.
In a perfect world, the developers would train the end-users on how to use the system because they have the greatest knowledge of the system. The developers do not require training on what they are training. Also, training is the next logical step in the SDLC for them. The problem is that developers and trainers usually possess different skill sets. There are coaches and there are players. It is rare that a person can successfully do both.
Corporate trainers are people who specialize in training end-users on how to use a new system. They are good teachers, however, they have to be oriented themselves with the system which adds to cost and time.
It depends on the number of people who will be using the system whether corporate trainers should be used or whether the developers should train. If a large amount of people will be using the system, corporate trainers are the way to go. In most cases, software engineers do not want to teach a large amount of people how to use their software. Such a teaching situation would only be sufficient when the number of end-users is small.
VI. Maintenance
The last phase of the systems development life cycle (SDLC) before everything starts again, from the beginning, is maintenance. The four types of maintenance are corrective, adaptive, perfective and preventive.
Corrective maintenance happens directly after the implementation. This is so that mistakes can be corrected immediatly. Bugs may include code tweaks, installation path modification, etc. It can also include the modification of computers so the software runs properly. This part of maintenance decreases with time.
Adaptive maintenance is adding new features that were not necessary in development or were not needed. A software package might be capable of being used in other departments of an organization, therefore, the software must be modified for adaption.
Perfective maintenance is modifying software to become more efficient. An example would be modifying a search algorithm so that the order of magnitude decreases from binary to logarithmic. It can also include hardware upgrades to increase the speed of a system.
Preventive maintenance is acting with the intent of preventing future problems. Disaster recovery is considered preventive. Data backup is also a preventive move.
I think a deployed system goes through all four types of maintenance before it is jarred or zipped up and laid to rest in a software graveyard. Its an interesting life for an information system from birth till death. But remember…nothing is truely dead because from all destruction comes creation.
Creation Image from http://www.aerenlund.dk/rom/rome_day6.html
Data Flow Diagram and Flowchart from my school work
3 Fates image from http://whatfatehasinstoreforyou.blogspot.com
Comments
34 Responses to “The Systems Development Life Cycle (SDLC)”
Leave a Reply
Wow, someone did their homework. Nice Job!
This is better than my textbook for my Systems Analysis & Design course in college. Great work, very detailed.
Great insight about the installation and maintenance. Often, these phases are overlooked because the designers and developers steal most of the visibility.
Take systems analysis and design in school much? Creation and the Three Fates are awesome representations of the SDLC..nice touch!
I know where I’m coming when I have to do my systems management project for school.
I thought the addition of Creation and Three Fates artwork would go hand-in-hand with the SDLC theme. Thank you all.
Your thinking was right-on. I might have to direct students to this article because it is that good.
If it is alright with you Jonathan, I would like to use this blog as part of my lecture notes for my Intro to Systems & Analysis class.
Wow Jon, I am not to savvy in this area but it looks like you put a great effort into this.
I use a different SDLC. Mine is as follows;
Analysis -> Design -> Development -> Deployment -> Support
Hey Andrew! Good to see you back here. Its been some time. Thanks man. I happen to be taking a class right now on Systems Analysis and Development. Creating this blog post was sort of a review for me in preparation for the last week of class. KIT man!
Jeff: That is the beauty of Jonathan’s approach. Like his fisherman knot analogy, different organizations will have different SDLC phases depending on how they are broken down.
For example, Development breaks down to Coding, Testing, and Documentation under Jonathan’s model. Some people like to include testing as its own phase.
SDLCs may differ from place to place, but they all accomplish the same goal in the end.
The only area of your SDLC short-summary that lacks substance is requirements. A more forecful emphasis on requirements in the initiation and analysis phases will result better momentum later on in the SDLC.
Dr. Frasano, I recognize your name from my Java Infix-Postfix Expression Evaluator post. You are free to use this blog however you wish as an educational tool. Good to have you back.
Dr. Hammond, I couldn’t agree more with you. The more you focus on requirements, the less likely you will be suprised down the road when something pops up that should have been thought about and accounted for.
May I ask you both what exactly your specialties are?
Jonathan: I enjoyed your infix to postfix expression evaluator very much. It was nicely written. I am an adjunct professor at the University of Southern California. I received a Doctorate of Management in Information Systems & Technology (DM/IST) in 1997 from Washington State University.
PS: I have subscribed to both your blog’s entries and comments RSS feeds. They pop-up right on my desktop.
My specialty is in parallel computing. I have a PhD in Computer Science from UCONN, 1994. Btw, I added you as a friend on StumbleUpon, the place I found your blog.
Wow, thank you both Dr. Frasano and Dr. Hammond for contributing your expert opinions towards my work. I really appreciate it.
You are right about one thing, most engineers would never want to teach.
I am impressed, but then again, I know how smart you are and how dedicated to computer science. I remember how impressed my yearbook class was when, in your 11th grade year of High School, you put the entire book publication on software and we did a 100% turnover to tecnological production. The company said it would take several years and you did it in one. Those 10 of 12 national firsts have all been due to your foundation. Thank you! I have to laugh now when we think about when you got the technology award at senior academic awards. You were an honor athlete and you also got all the tech awards but one was called C++ and we wondered how you ever got a C with all the A’s hehe Your first award in grammar school for tech still hangs in the building. At four, you played with your first computer ( Texas Instrument-$50 ) and it had a speech synthasizer. YOu taught us everything we know in computers.
I know you are almost finished with your masters and Dad will be so sorry to lose you as you have been an outstanding paralegal and asset to him but we can’t wait to see you work at your number one love and passion. When you were invited to compete in the Junior PGA we thought you might take that turn but as much as you loved the game and had that incredible long shot…you still picked computers. When you had that super run and your team did states you had 30pts in b-ball and six three pointers in a row. I really thought you would take the ball route but again…..the passion is computer science. When your Dad almost died and had 51 weeks in trama units and four years of recovery you were the one by our side putting everything on hold. You are one incredible person!!!!
By the way ….as an English MA+60 I appreciate that your writing skills are also up there and I know when you give a speech everyone stops and is impressed. Nice work, Jon!
Yes men on the way of developing the system, I have appriciated your work, it is good, important for us all who are taking the study of information system. Big up men for your good task. Can you sponsor me for my university studies? Iam at the university of Dodoma, the capital of Tanzania, box 259 Dodoma the above is my email address.
Geofrey, could you please let me know, with more detail, what exactly you are looking for? You can email me at jonathan@tomorrowslogic.com
this site help alot when you want to develop a new system, the note are easy to understand compared to others
I can’t tell if this is an elaborate April fool’s joke or not. You’ve just described the waterfall model, which is the canonical example of a broken development system.
[...] be broken down into the following phases which represent the systems development life cycle SDLC:http://www.atlaseditorials.com/2008/04/01/the-systems-development-life-cycle-sdlc/Systems Development Life Cycle Checklists The System Development …File Format: PDF/Adobe Acrobat - [...]
The waterfall model is not a canonical example of a broken development system if you make sure that the next phase does not begin until the previous phase ends and all team members manage good collaboration and communication. What model would you suggest?
It’s not just about team communication and management. What if the requirements change halfway through the project? And don’t say you only start the project once the requirements are finalized, because they are almost never truly finalized.
I suppose a simple iterative method works well for most cases. I’d suggest just about anything but waterfall. I mean, when the design was created it was created as an example of how to run a project poorly.
Good risk management and contingency planning can allow for a smoother transition when requirements are changed half way through. At that point, a new phased approach must begin. You don’t seem to like the waterfall all that much.
No, I really don’t.
I suppose you’re right about risk management and contingency planning, but it just seems like an iterative solution provides a better solution.
So I am guessing you would sport a more iterative methodology such as Rapid Application Development (RAD)? What are your thoughts on the business/IT workshop environment of Joint Application Development (JAD)?
Sorry to spell out the acronyms, you probably know what they are but other readers might not.
Not necessarily RAD, just an iterative approach in general. Wikipedia is pretty good on this: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Yes, good stuff indeed!
[...] April 1, 2008, I wrote an article titled, The Systems Development Life Cycle (SDLC). It concentrates on all phases associated with an information system. Programming only [...]
[...] it is recommended that the entire process is encapsulated in The Project Life Cycle (PLC) and The Systems Development Life Cycle (SDLC) where [...]