Quick Links

FREE IT Trainings

FREE JAVA Seminars

1,200 watts inverters for just =N=15,000

Get Fast and Reliable internet access for as low as =N=5,000

Earn BIG profit as our sub-dealer on bulk recharge cards! (available Nationwide)

2,400 lumens projectors as low as =N=100,000 (rental from =N=2,500)

Telephone boxes /PABX @ =N=500 and =N=15,000 respectively

Computer Tables from =N=2,500 only

FREE Downloads

Investment Portfolio Mgt. (MaxINVEST)

Multi-Level Record Management Software (MaxRECORD)

Membership Information System (MaxMEMBER)

e-Item Vending Software (MVEND)

Network e-Messaging and File Transfer with Voice and Video (MaxCHAT)

Programming Project - A Client's Responsibilities

This document outlines what you can expect as a Client of Maxtech Solutions Concept when the company is creating a program for you. It is very important that you understand that, unless otherwise agreed to beforehand, you will need to devote many hours of your time in order to get the most of your program. If you are not involved in the program creation, you will receive the program we decide to build, which is likely not what you wanted in the first place. Please review this document and ensure you understand everything in it. During the entire process, starting now, when in doubt, ask.

Maxtech Solutions Concept follows standard procedures of program creation. These procedures are not just customs, but are practices that have been developed over the years to ensure the final product is the one the customer requested.

One thing that surprises many clients is that the actual act of writing the program, called coding, is a very minor part of program creation. The rule of thumb is that the more time that is spent "up front", documenting what the program does, the less time will be required to modify the program after it is written.

Accordingly, the following list outlines the steps commonly used to create a program.

  1. Create the Problem Definition
    This is a document written in a weird mixture of English and Computer, but even so, you must understand everything about it. This is the document the programmer will follow when creating the following steps, and ambiguities will lead to failure. Ambiguities pop up any time people converse in different languages, and programming is a language all to itself. Do not allow the programmer to gloss over anything, do not fail to understand everything and have the document modified to show this understanding. This document is the Bible when it comes to your program, and minor changes to it at a later date can cause a cascade effect throughout the remainder of the project, resulting in a project that is over budget and late. Your programmer/analyst should cover this document, in detail, and refuse to proceed to the next step until it is complete and agreed to by all. You and the programming team lead should sign this document before any further work is done, and before a final bid is given and accepted for the time and money required for the project.

  2. Define the Data Structures
    Your project may or may not require data structures. A simple web site will, of course, not require any data structures. But a full blown database/cgi program will. As an example, an online address book must include all fields you want stored, ie all information you want to store and retrieve. Do you want to know a birthday for each entry? Are we talking only about Nigerianís contacts, or do we need to be set up for International addresses. This definition is required for any project that will store/retrieve information.

  3. Define Screens
    Sketches of all screens should occur here. Prototype screens could also be created, to be used in the following steps. If data structures were defined in the previous steps, display information for all data visible from the data structure should be included. At this point, our problem definition should be showing its effectiveness since the flow of the project will have been defined there, resulting in a simple list of screens that must be created.

  4. Define Program Flow
    How do we get from Screen 1 to Screen 2 above? What actions need to be taken (defined in the Project Definition) for each screen to move to subsequent screens.

  5. Define Reports
    In Projects requiring data structures, there are reports that need to be created. Do you need to know how many people have signed up for your new service? At this point, the information from the Data Structure Definition and Screen Definitions above should be combined to give the actual definition of report creation. All of the following questions should be answered:

    • How do you want the reports sorted?

    • What information should be on each report.

    • How do you want to limit the amount of information displayed.

    • In what format do you want the information displayed.

  6. Build Data Structures
    At this point, the programmer actually creates the data structure and delivers a representation of it to you. There is no reason for you to understand every nuance of this representation so long as the data structure was defined well in step 2) above.

  7. Populate Test Data
    You should assist the programmer in creating test data to populate the data structures created. Enough information should be manually placed into the data structures for testing by the programmer during the following steps.

  8. Build Screens
    At this point, the screen designer takes the sketches created in Define Screens and makes them a (possibly non-functional) reality. The first screen will define the "look and feel" of the application, and even the smallest detail should be exactly to your specifications before any additional screens are created. Colors, general layout, and the overall usability of the screen should be looked at carefully. Once approved, the following screens can be created and you should review each, in detail.

  9. Write Program
    The programmer now writes the "glue" that puts the screens together.

  10. Test Program
    The programmer has already tested the project, correct? The worst person to test any program, web site, or any project, is the person who created it. At this point, someone other than the programmer must test it. The programmer has tested it (a process called alpha testing) when they wrote it. But, with very few exceptions, a programmer is a programmer. The programmer does not know how you will use the program, and they can not be expected to see outside the box long enough to give a good test. They have been working on this project for a while, and have pre-conceived ideas about how it will work. As an example, a programmer would be unlikely to put AAAAA in a age field. Why should they? It is for ages.
    In this stage, called beta testing, the program must be tested by others. Each beta tester should have a copy of the Problem Definition and use it to test the program. Good beta testers fall into one of the following categories:

    • Other Programmers
      Getting another programmer to test a project is great, as experienced programmers know many common flaws that occur in programs.

    • Professional Testers
      There are many people who test programs for a living. They sometimes have automated tools that assist them, and the more experienced have knowledge of many types of bugs that creep into programs.

    • The End User
      Get as many end-users of the program to test as possible. There is no substitute for end user beta testing. Each user should actively attempt to break the program. An incentive program for the end-user who finds the most bugs, or who offers the most suggestions that are implemented is a great way to find (and fix) deficiencies before delivery.

    • Computer Illiterate Individuals
      This is the class of people that tend to find the most usability errors. Something that might be intuitive to an end user who has been using a similar program for years might be totally unintelligible to your target audience if they will contain people who do not use computers much (or at all).

Professional Testers and programmers have a good idea of how to test a program, but normal end users do not. Following are some guidelines to be used when testing the program at this point. You should ensure that each tester has the following list and understands each of the points.

    • Test Every Link, Button or Action
      Every time, each time, test every link, button, action in the entire program. Even if the programmer has only made one small change, those changes sometimes have cascade effects throughout the program that will fix one problem while breaking something else. Test everything, every time you are asked to test the program.

    • Put incorrect information in fields
      What happens if you put 234.01.7619400 as a phone number? Does the program understand using periods to separate the parts of a phone number? Should we be able to place International numbers in this field. What happens if we put a -1 in a quantity field? Or 0. Or 9,999,999. Can we put control characters into fields? Try to break the program. It is better to break the program now than later, when it might be a mission critical application that will cost money and time to repair.

    • Leave required fields blank, or duplicate existing entries
      If an important information is required at some point, what happens if it is left out. Or, if you have a customer ID that must be unique amongst all of the data you store, what happens if you successfully duplicate that customer ID.

  1. Deliver Program
    At this point, if all of the above were carried out, the program is ready to be used. It should be delivered with documentation (created while the programmer worked on the system and during testing).

One final point to be made. I reiterate that the Problem Definition is the Bible of the project. Adding or modifying the Problem Definition after it is approved has many negative effects that will result in a poorer deliverable that costs more and is delivered late. The effects result from the following.

  • Cascading Effects
    Even a minor change to the problem definition at the end of the project can cause a rippling cascade of changes to the project as a whole. As an example, lets say we forgot to include a birthday field in an address book; a simple change.
    Now the programmer must add the field to the database, then find all screens that use the field and modify them. The coding now must be modified to ensure the birthday field is populated and validated correctly. On a large project, the programmer may have to go through hundreds of screens and thousands of lines of code to determine where to modify the project to make this one simple change. Then, all documentation must be updated and, since the project has been modified, the entire beta test phase must be restarted from scratch. On a simple project, adding this item may have resulted in 1 or 2 additional hours of work (most likely, less than an hour overall), but if added at the end of the project, it could result in tens of hours of code rewrite, screen modifications, documentation modifications and testing.

  • Programmer Disorientation
    Programmers tend to be very task oriented, linear thinkers. Once they get their minds around a project, they tend to see a clear path to the end and proceed from Point A to Point B in a very structured manner. Any intrusion that causes them to deviate from this path is frustrating as it clouds the path. In extreme cases, where many changes are introduced over the course of a project, it can result in a total disorientation by the programmers involved resulting in a project that they, and you, feel will never be completed.

What is the solution? Determine if the change is required in this release. Most projects do not end once it is delivered. Many enhancements are found that would make a project better, easier to use, or gather and disperse information in more easily recognizable manner. For these items, create a list of enhancements for inclusion in future modifications. How to differentiate is one of the most difficult parts of a project manager, but a good rule of thumb is: will the resulting project be unusable without the modification in question. If a report gives incorrect information, then it must be fixed before use. However, if the same report would be easier to understand if delivered graphically instead of textually, then this is a good candidate for modification after the project is released and in use. Remember, each modification made results in more out of pocket money and more time spent before you can