The orderly process that an organization goes through when identifying its applications software program requirements is referred to as the software development cycle. As mentioned earlier, you need to understand these steps so that you will be able to tell a programmer in terms he or she can understand exactly what your programming requirements are. Although this section on programming is not detailed enough to allow you to communicate on the level or a program it will tell you the basics that you as a user need to understand about programming.
Want to buy this BOOK CLICK HERE
Consider all possible ways of solving a problem and specify the objectives of the intended program including who (which departments) will use the information produces.
– Specify program objectives or the intended program users.
– Specify output requirements.
– Specify processing requirements.
– Study the feasibility or the program.
– Document the analysis and objective specification process.
This may involve using flowcharts flow diagrams data dictionaries that catalog and identify the data elements that will be used sketches of display screen formats and report layouts and so on.
Step 1 usually involves meeting that include the programmer’s users and the systems analyst designer who designed the system or which the program will be a part. At this point a make-or-buy decision is made. If an off-the-shelf program exists that you can buy or solve your problems, you will not have to make (create) our own custom software. However, if you do have to create your own software, you must then proceed to step 2.
After the problem has been defined, the program must be logically designed. This process is not unlike outlining a long term papers organization before you actually begin to write it. The programme must work out algorithms or process specification, before the program is written. An algorithm is a set or well-defined rules for the solution of a problem in a particular number of steps. (This type of problem-solving method is contrasted with exploratory, or trial-and-error, methods.) The programmer may use a variety of tools to do this including flowcharts, pseudo code and structure charts (discussed later in this chapter). You probably won’t ever need to use any these tools because they are used mostly by programmers mapping out complex logic or by those using third-generation languages. However, you should have a basic idea of how they are used in order to appreciate the detail that is necessary for a programmer to create a program. The more detail you can give the programmer about your own processing requirements the better4 the resulting program will be.
After the program has been designed programmes systems designers and users check its logic and documentation by means of a structured walkthrough.’’
Translate the processing requirements of the program into the necessary programming (high-level) language statements and then enter the coded instructions into the computer. (This is usually done in a terminal and the instructions are stored on disk. The programmer can modify the instructions as necessary.)
Review the program carefully to ensure that it is doing exactly what it is supposed to. Repeat ‘’structured walkthroughs,’’ conduct ‘’desk-checking’’ by proofreading a printout of the program and using test data review output reports to determine that they are in the correct format and contain all the required information the user can play an important role in identifying the problem areas or bugs in a program by participating in tests to see how it handles the types of tasks it was asked to do including trying to break the program by inputting unusual test data. The programme can then fix the problems or debug the program.
Clearly document all the steps, procedures, logic tools, and testing results, as well as the goals of the program and other program and other specific facts. Although listed as step 5 the activity of documenting the program should go on throughout the design and coding process. The documentation or manual tells future program operators users and programmers who may later have to modify the program exactly what the program does how it does it and how to use it. Documentation also helps programmers track down errors. (Users must assume some responsibility to see that the new software is adequately documented.)