EnterApp

Web Services Council

Enterprise Applications
Development Guidelines and Procedures

Programming Specifications and Standards

Programmers will obtain program design or modification specifications, a database dictionary, and other appropriate information from which they will design the new program or implement the program modifications from the project leader. These specifications should be written. However, it is understood that subsequent clarification of detail may be communicated by word of mouth.

Written specifications will vary according to complexity and detail involved, depending on the project and expertise of the individual receiving them. Written specifications will be kept with program listings serving to provide the IT staff member with a record of the purpose or original intent of the project.

Programming Specifications

Prior to any coding, the programmer will do the following:

  1. Structure Chart
  2. Prepare a Structure Chart to understand the general program flow. This may be in a draft, even hand-written form. The final chart must be completed prior to final acceptance of the program at the option of the project leader. This is generally only required when complexity warrants.

  3. Review Problem Areas
  4. Review promptly any problem area with the project leader to ensure that the correct approach is being taken. If a question is general in nature, i.e. syntax, MPE commands, etc., any IT staff member may be consulted when the project leader originating the specifications is not available. However, to avoid confusion, only the project leader originating the specifications should be consulted for questions specific to the program.

  5. Programming Language
  6. Unless otherwise agreed to by the project leader and the appropriate section manager, all programs will be written utilizing a PowerHouse non-procedural language such as QUICK, QUIZ, QTP, and PDL. The appropriateness of the language should be used to determine which language should be used, not the knowledge or skills of the programmer. Non Powerhouse programs are not to be developed for production work without IT manager approval. In addition, Powerhouse Web is not to be developed for production work without IT manager approval. As an exception to this rule, any language may be used to create a program which will be run and immediately discarded. BASIC may be used wherever possible due to the speed with which such an undocumented program may be written.

  7. Program Review
  8. All programs should to be reviewed by another IT staff member before they are turned over to the project leader. The purpose of this is to share ideas and techniques and alert each other of any inadvertent standards violations. A program is to be accepted by the project leader only after receiving from the programmer a new source listing containing dated changes and maintenance history. Documentation and structure charts must also be supplied on request. The project leader will move the program from development to production or direct the programmer to make the change only after final approval.

  9. Setup and Implementation
  10. All batch processes or jobs to be placed in production are normally placed in the JOBS group of the appropriate account. New programs can be set up as Security 3000 menu items and placed in the menu specific to the customers requiring them. After a program has been placed into production it must no longer be run by an IT staff member. This will eliminate confusion for Production and Reporting. This will also help to clearly differentiate between developmental work and production procedures. Exceptions are very seldom required, however, after management review. When an IT staff member assumes control of a production run they also assume responsibility for coordination with Production and Reporting.