After a bit of delay here’s the last of the Guide to Programming Series: The Life Cycle of a Typical Program. Why the delay? A lot of personal stuff (like my impromptu trip ^^) but no worries. I’m back, I’m better and I’m focused.

Now, on with the series:

Programs rarely go from the drawing board straight to the market. We usually get to avail of them at the -nth incarnation.

Why? This is because Programs ‘evolve,’ over the course of their development and rarely does a program go from code to product without carrying bugs in them. These computer bugs are errors, flaws, mistakes, etc within a computer program, either in the code or how the program works in general, preventing it from behaving as intended. The usual cause of bugs is human error. Imagine trying to simulate thousands if not millions of lines of code and you get the general idea but I’ll go on into that later.

In perspective, development of a program typically goes as follows:

• Development
• Maintenance
• Upgrade

Now, developers don’t exactly stick to this process tree but it gives you a general idea of what goes on into making a program.

The Development Stage

I posted a similar post on the process of software development but it’s far too advanced, jump to it if you don’t consider yourself a programming novice.

All program begins as a blank screen on somebody’s computer. During the development stage, try and mold ideas to an actual working program.

1. Brainstorming an idea – fairly self-explanatory. For example, if you wanted to create a audio player you ask the basic questions of what features will it have and what formats will it play. Try to generalize the basic features of the program before adding anything else. This way, you’ll know that the program will work with or without these add-ons and not depend on them
2. What are the basic specifics of your program? – Who’s going to use your program? What computer (OS) will run your program? What program language will you use? You can check up on the earlier entry of this series for a complete rundown of questions.
3. Design the program – You can use pseudocode, flowcharts or if you’re advanced enough UML to outline the general structure of your program. It’s better to plan things out than get stuck on it later on
4. Write the program. – After you’re certain you have everything you need, you can start coding. With your needed resources at hand, you’ll spend less time thinking what should be coded next
5. Test the program – You can do this in parts during coding or on the whole program after you complete the whole code. To save time and effort though, I suggest you do it in parts. Also, you don’t have to actually eliminate ALL bugs at this point, just enough to make sure that you won’t run into problems that will potentially stop your program from working (I.E. major bugs). This step is known as alpha testing.
6. Prep the program for release – Congratulations on Version 1.xx.
   

The Maintainance Stage

This is can also be called the Beta Stage of development. Many MMO games go through this by letting players get a taste of the actual game then allow them to file reports on their experiences.

Bugs can either come from the program’s source code or how it is designed, a rare few however are caused by compilers producing incorrect code. Since most programmers prefer to create new programs than maintain and modify existing ones, companies usually assign QA (Quality Assurance) departments for this purpose.  QA’s don’t have to actually know the code that the program works on. Their job is to toy around with your program and try to break it then publish reports or if a bug is found, file a bug report so that the program can move on the production line. Here’s how the beta stage goes:

1. Verify fixes for all reported bugs – This is to ensure that no bug from the Alpha stage gets through.
2. Test the program with all possible scenarios using Manual or Automated testing – This is the main job of the QAs. They basically look for holes in the program, a mishandled exception or a wrong output by manually handling the program or by using scripts like WATIR (applicable only for Web apps)
3. File a SPR (Software Problem Report) if a bug is found – This is so that the development team won’t need to replicate the error to know what’s wrong. This is especially helpful if the bug found can compromise the whole system when executed.

Given the size of current programs (especially corporate scale ones), Beta testing may take weeks to months if not years. If the program has been deployed for public use, a software patch is released to incorporate corrections in the problem.

Note that to enter a job as a QA, you usually just need to learn the tools used for testing and the basic workings of the program that you will test. If you’re looking for a stepping stone in the IT industry and are unsure of your skills as a programmer then applying for QA is probably the best way you can enter the industry.

Pages: 1 2