This lesson is primarily concerned with planning associated with programming writing, but the programming/planning process extends far beyond programming to every area of our lives.
The steps involved in programming are: (we call these the 5 D's)
Now, is the process complete -- well, actually it is not. Instead of calling this the programming process, we should call it call it the PROGRAMMING CYCLE. At some point, you will decide that the car which was just purchased will need to be replaced. So, you start the process all over again.
Let's consider another example. Suppose you were in charge of building the next level of passenger airplanes. To define the problem, you would do an extensive investigation into the needs, costs and feasibility of the project. When designing a solution, you would have your team draw up extensive blueprints. You might even build a PROTOTYPE or a scale model of the proposed airplane. The next step would be to build the plane or to do it (I suppose that you could use the word develop here but DO IT sounds a little more positive.) In the next step, you would debug and test. Now, we have really simplified this - in real life, each individual part (the engine, the controls, the brakes, etc.) of the proposed plane will go through each of these steps. So, how do you test a big plane. Do you fill it with paying passengers and take off. I can hear the pilot saying:
Ladies and Gentlemen, welcome to the first flight of this brand new airplane. It is a design that has never been flown before. We are very proud of this plane and honestly believe that it will fly. Our best engineers and builders worked on this plane. Please prepare for take-off.
I don't know about you, but I would be headed for the exit.
How do they test a big plane such as this one? Well, on the first day, they start it up and roll down the runway and turn around and come back to the hangar. Why do they do this? Well, it checks out the controls, the engines and most importantly - the brakes. If you have every flown, then you understand that you really want the brakes to work when you land. Before the next flight, the engineers and maintenance guys will check the plane out - just to make sure that everything is working right. On the next day, a few more systems will be checked out. The pilot will go a little faster and then take it back to the hangar for a check-out. Eventually, the pilot will actually get the plane into the air. The testing phase was done in a STEPWISE manner - in phases, with each phase becoming more extensive. After this stage has been completed, then the document and maintain stage will occur. Again, the five steps or stages were completed.
In the solution of every problem, these 5 stages can be identified. Obviously, depending upon the specific issue, sometimes one stage is emphasized more strongly than the other. Sometimes the initial stages are emphasized more than the later stages - but in all problems, each stage is present.
In programming, we find that if you spend a significant part of your time in the initial stages, then it greatly simplifies the later stages. Compare this to building a house. In the initial stages, where the house only exists in a blueprint, it is relatively easy to move a wall. Just erase a line and redraw it. After the house has been built, it takes considerable effort (much more than erasing a line) to move the wall. This same concept carried over to programming. Put significant effort into the early stages and it makes the latter stages much easier.
We have covered these stages in general terms and have discussed some examples. Next, we will go over the specific details that should be considered during each phase or stage of the problem solving process.
We all have known people that give very good answers - but they answered the wrong question. Often this happens because people do not understand what the underlying issue is in a given situation. For this reason, we need to ask questions. In this first stage, we need to identify the needs, determine the feasibility, understand the current situation and identify new requirements. Many companies will want to redo their web pages on a regular basis because the tools which are available today simply were not available just two years ago. Especially in the computer/technology world - everything changes. So, in this stage, keep the following questions in mind:
At this point, the developer has several different design techniques which are available. Certainly, a very important one is to rely on past experience -- also, look at what is currently being done. For example, in this web page design course, we have encouraged you to critically look at pages written by other individuals. Sometimes you will find something that you like and at other times you will find things that you dislike.
One useful design tool is a STORYBOARD. On a storyboard, the developer can sketch out some ideas. These ideas can be shared with others. And many times, issues that will eventually be raised can be raised and settled early in the development process, this simple step can save lots of time and money. Other design tools include various types of diagrams,
pseudocode and flowcharts. Basically, the purpose of these tools is to provide some sort of graphical
representation of the system which is to be developed.
Another useful design tool is the PROTOTYPE. A prototype is a model of the system to be created. A scale model of a proposed shopping center can be used to help 'sell' the idea to investors.
It is also useful during this stage to go through a 'design walkthrough'. In a walkthrough, an overview of the design is presented to users, programmers, consultants and others. In many situations, the comments can be rather blunt. It is possible that the designer may feel that the comments are directed towards the designer instead of the design. Sometimes, it can be quite uncomfortable.
During the walkthrough, it is important to be committed to the process. It is important to understand that the comments are critiques NOT criticisms. However, when you are in the middle of an intense discussion - it is very difficult to distinguish between the two. At these times, it is important to remember another concept - a concept called EGOLESS PROGRAMMING. A programmer who practices egoless programming will separate the programmer's ego from the program being developed. Again, this is a very difficult thing to do, but the idea is to use all of the comments, suggestions and ideas which are presented to create the best product possible. The main thing is to turn out the best program possible - sometimes the programmer has to do what is best for the product instead of what they personally want to do.
During this phase, the following questions will need to be covered:
In many situations, the client will want a TURNKEY system. A turnkey system is a complete system - it is ready to 'turn the key' and start it up when it is delivered to the client.
In a large programming project, the various programming tasks will be spread across many different individuals or departments. Programmers will work in teams to perform tasks that they couldn't accomplish individually. Teams allow large projects to be completed quickly.
Generally, if the first two steps have been properly completed, then this step can be accomplished fairly quickly.
Step 4 - Debug and Test
During the debugging phase, errors in programming code are corrected.
During this phase of the programming process, the program will be tested as completely as possible. In this phase, the experience of the programming team is very useful as they try to 'crash' their own program. This phase of testing is commonly called an alpha test. The software isn't certified or approved for routine use until it has survived a beta test. Beta testing is done by users who are not on the primary programming team. Shortcomings and errors found in the program are reported back to the development team.
Documentation can vary greatly from project to project and can be written during or after the program has been developed. Programming documentation can be included in the code of the program. Programming documentation is useful to the programmer who is reading the programming code.
User documentation consists of training manuals, operations manuals and other reference materials that describe how to use the system.
Documentation has one major goal which is to inform and instruct. Therefore, it must be clearly written, easily referenced and complete. Unfortunately, most documentation in the technology field is inadequate because the systems change so rapidly. Another major problem is that documentation is often written by the ones who wrote the programmer. The designers and developers who write the documentation are more interested in writing code that they are in writing documentation. Another major problem is that documentation is written by people who know what they are doing and is read by those who don't know what they are doing. This one thing can explain why documentation is so difficult to read and understand.
In the maintenance phase of the project, programs will be updated. For web pages, this is especially important. It seems that a web page is never completely up-to-date - it is always in need of updating.
At some point in this process, the project will need to be installed. There are several different schemes that can be used to complete this process: direct, parallel, pilot and phased. Direct involves a immediate switch from the old to the new system. The parallel method involves running both the new and old systems for a time. The pilot method allows the new system to be checked out by a smaller group of users before the switch-over. With the phased approach, the new system is gradually phased in by introducing portions of the overall system over time.
In web page development, the two installation schemes that are most commonly used are: direct and phased. Direct is usually used when a new web page is installed. Phased is used when the web page is changed gradually - over time.
Of course, these are just a few of the questions that might be asked at this stage. The important thing is to ask questions until you have a good level of confidence that you understand the situation.
Step 2 - Design a solution
It is important to create a document (or contract) which outlines the responsibilities of the programmer and those of the client. Such a document helps to prevent misunderstandings as the project develops. The more extensive this document is, the better it is for everyone.
Step 3 - DO IT! (Also called - Development)
Step 5 - Document and Maintain
In 1962, a Mariner I probe was launched. It's destination was Venus, but in the programming, the programmer had inserted a period instead of a comma in the FORTRAN code. This error was not detected until after the rocket had been launched. Instead of going to Venus, the rocket had to be destroyed - it's cost was 16 million dollars. If the error had been detected in the early stages, the cost would have been much less.
During the Gulf War, an American Patriot Missile failed to intercept a SCUD missile and an American Arm barracks was hit. The missile killed 28 soldiers. The problem was traced to a software problem that led to a system failure.
Another incident involved an unmanned Arian 5 rocket. On June 4, 1996, at 40 seconds after lift-off, the rocket exploded. The cause was a software error in the inertial reference system. No one was harmed, but the loss was calculated at 500 million dollars.
A technology called Smart Ship has helped the Navy cut costs, but it also cut the USS Yorktown's propulsion for almost 3 hours in 1997. The missile cruiser lost propulsion after a Windows NT application attempted to divide by zero. Other problems in clock software were the suspected culprits when Patriot missiles lost accuracy in 1991, failing to stop a Scud missile strike on a barracks in Dhahran, Saudi Arabia. And the inflexible software aboard the USS Vincennes contributed to misidentifying a target and downing a Iranian Airbus in 1988.
Greyhound spent at least $6 million in the early 1990s building TRIPS. But TRIPS failed miserably when installed in 1993, crashing when Greyhound offered sale prices on bus fares. To avoid using the system, agents wrote tickets by hand while customers waited in line and missed buses. Ridership plunged 12% in one month. Just weeks after launching TRIPS, Greyhound disabled it and traced the problems. The debacle spurred a $61.4 million loss for the first half of 1994. TRIPS is in use today, but Greyhound never regained its status as a transportation powerhouse.
To meet 1999s Halloween and Christmas candy rush, Hershey sped up the rollout of a $112 million inventory and shipment system. Inaccurate inventory data and other problems caused shipment delays and incomplete orders. Hershey sales fell 12% in the quarter after the system went live - down $150 million compared with the year before.
Poor planning has always been with us - even before computers. The MAGINOT LINE is a very extensive defensive line built by the French at the end of World War I to prevent the Germans from invading them. A great idea except the Germans simply went around it. It was a huge undertaking and took a lot of effort and money. However, as it turns out, it was quite simply an idea that wasn't worth the effort.
Even if you never write another line of programming code, the problem solving process described in this lesson can be of great benefit to you. As we go through life, we all will encounter problems and issues - effective problem solving skills can be a great asset.
It is a lot of fun to do the really neat stuff in programming, but employers want consistency. Employers want employees that have good problem solving skills. The world's best Java programmer is virtually useless unless he or she can make the program work in the real world. To make it work in the real world, problems have to be solved. Problem solving is not glamorous, not considered to be leading edge but it is the foundation upon which all effective programming is based.