1. Develop Programming &
Database Standards
Programming Standards
Insuring the quality and consistency of any custom software
requires the use of some form of programming standards. Standard techniques and methods make programs
easier to debug during testing, and easier to maintain and enhance
afterward.
Standards are necessary whether the entire system is being
custom-developed, or whether package software is being supplemented with
modifications, data interfaces, or conversion programs for one-time use. The content and complexity of the programming
standards will depend directly on the programming language(s) being used and
the software being written or modified.
Programming languages vary widely in their complexity, ease of
use, and the skill level required for use.
For example, most PC-based Data Base Manage Systems (DBMS's) include a
set of commands to format and manipulate data, and perform other
functions. The programming facility in
these DBMS's is often fairly intuitive and straightforward. Programs or procedures using these facilities
can often be developed by an end user who is familiar with database
concepts. Normally, there is no compiler
involved, and no tracking of "source" and "object" versions
of programs.
At the other end of the spectrum, coding in more traditional
languages such as COBOL and RPG requires a professional programmer, complex and
detailed logic, and more extensive development time.
Therefore, the programming standards which need to be
developed in this activity depend greatly on the technical environment. However, the following questions should help
to begin the thought process by which standards will be developed for the
project:
1. Will all programming be done in the same
language, on the same machine?
2. What CASE (Computer-Aided System Engineering)
tools will be used in the design process? (An "upper case" tool may
be useful in depicting a design for a new program or interface.)
3. What components will be required in the high
level design for each custom item? (For example: Program Summary,
Description of Inputs, Processing Flow, Description of Outputs)
4. What documentation will be required in the detailed
design for each custom item? (For example: Program Summary, Detailed
Flowchart, List of Input Data Elements, Processing Steps, List of Output Data
Elements)
5. How will programs be named (for example, all
program names might begin with "P", followed by an application code,
followed by a sequential number, etc.)
6. Will data items be defined within programs,
or externally?
7. Will all the programs be structured the same
way? Will program logic be top-down,
with subroutines at the end?
8. Will common processes be defined in external
programs, to be called from various other programs?
9. Within each program, how should comments be
used and formatted?
Database Standards
Database standards are similar to programming standards in
that they depend heavily on the technical environment. Database standards used with a DOS, Windows,
or OS/2-based Data Base Management System will be very different from those
developed for custom software written for an IBM mainframe, a DEC VAX, or an
AS/400.
If the only custom development in the project involves package
software modifications, interfaces, and conversions, there may be no need
to develop additional database
standards. Rather, the standards used by
the software developer should be thoroughly reviewed and understood before
programming begins. Many software
vendors offer technical training with a focus in the area of database
standards.
If, however, an entire application system is being
custom-built, data base standards need to be developed, documented, and
followed. The dependency on the DBMS or file architecture being used (ex: VSAM,
ISAM, DB2, UNIX, Oracle, dBASE, Microsoft Access, etc.) is even greater here
than with programming standards.
The kinds of questions which must be answered in the process
of developing a set of database standards, and in beginning to actually design
the database, include:
1. Is the database a true relational
database? If so, how
"normalized" will the data structures need to be? (Normalization is a
concept central to database design.)
2. How will the required files or tables be
organized?
3. How will records within these files be
organized?
4. How are fields organized within each record? (DBMS
vendors often use terms like "table" rather than "file",
"occurrence" rather than "record" and "attribute"
rather than "field", but the concepts are similar.)
5. How are data structures (files, records,
fields) to be named?
6. What CASE tool, if any, will be used to
support database design?
7. How will changes to an existing database be
reviewed and approved?
Using package software eliminates most, if not all, of the
database standards development effort and design work. However, programming of modifications or
interfaces should not begin until a thorough understanding of the existing
database standards is gained by all programming resources.
Standards Review
Once programming and database standards are developed and
documented, they should be reviewed and understood by the organization which
will be responsible for technical support after implementation. This is particularly crucial if a software
vendor or third party is providing implementation programming, and the
Information Systems department or Operations staff will support the system
after it goes into live use.
2. Obtain Requirements
Definition Approval
Types of Custom Programs
In a package software implementation, custom programming can
be broken down into separate, identifiable programming items. Each item may be categorized as a
modification, interface, or conversion item.
Modifications include changes to the vendor's programs, or
creation of supplemental programs for processing or reporting purposes. Modifications should be done to a software
package only when absolutely necessary.
They are usually expensive, add risk to the project, and make future
software upgrades more difficult. If a
modification is required, using a supplemental program, external to the
vendor's programs, is easier to implement and maintain. Supplemental programs are therefore the
preferred approach to software modifications.
Interfaces are links between the solution being implemented
and another automated system. Interfaces
normally pass data from one system to another, sometimes including complex
processing, validation, and reporting.
The systems being interfaced may be on the same hardware platform or may
be on separate machines. For example, a
PC-to-mainframe interface is a common element in a total software solution.
Interface programs will be used regularly throughout the life
of the system, perhaps monthly, daily, or even continuously, depending on
whether the programs run in a batch or on-line mode. For this reason, interface programming must
be developed with a view toward future maintenance and enhancement, including
thorough technical documentation and adherence to programming standards.
Conversion programs are developed for one-time use in the
automated conversion of data from the old system to the new system. A conversion program is needed when the
volume of data which needs to be moved from the old database to the new
database is too large to key in manually.
As a rule of thumb, data items which would take more than 40 to 60 hours
to enter manually typically give rise to an automated conversion program. While conversion programs must be thoroughly
tested before they are used to convert live data, they are usually not used
again after the project is completed, and therefore are often not documented as
carefully as a modification or interface program.
For discussion purposes, project team programmers and
Information Systems personnel often group all three types of programming items
under the term "modifications" or "mods".
Modification Requests
The life cycle of any custom programming item begins with the Custom Software Control Form. A copy of this form is included at the end of
the Development / Programming section
of this guide.
Completing this form establishes a control number for each
development item, and includes other important summary-level information. The control number is used to track the
status of the development item, whether is evaluated and rejected, or whether
it is approved, programmed and implemented.
Requirements Definition
In order for the development item to be approved for
programming, it must include some form of Requirements Definition. A Requirements Definition is a detailed
statement of what the a modification will accomplish. It does not include technical information,
and does not always need to describe how
the modification will be implemented.
The Requirements Definition states clearly what functions the
programming item will add to the system, and how it will interact with the
system user. Layouts of screens and
reports may be included, since a system user will see these components. The Requirements Definition, often referred
to as a "functional design", should be developed by project team
analysts, with support from technical team members. Participation of a technical resource helps
to assign a preliminary cost estimate to the request.
All Requirements Definition documentation (which may include
narrative, screen layouts, report templates, etc.) should be attached to the
Custom Software Control Form. The
"List Other Documentation Attached:" field on the form is used to
note which related items are attached.
The request form is now ready for review by a representative
of user management. This would typically
not be a member of the project team, but a department manager or other
individual who speaks with authority on behalf of the potential system users.
The modification request may then be approved, rejected, or
sent back to the project team for revision.
Once a cost factor has been assigned to the total set of development
items, the Executive Sponsor should approve them as a group. Modifications which are approved at the
Requirements Definition stage move on to the Walk Through High Level Designs activity.
3. Walk Through High-Level
Designs
After the functional requirements have been approved by user
representatives, the high-level design may be developed, reviewed, and approved
for further development. In some cases, a
high-level design will have already been done as part of the Requirements
Definition.
CASE Tools
The use of CASE (Computer-Aided System Engineering) tools has
grown substantially over the past two decades.
A CASE tool can be extremely useful in supporting design work, at both a
high level and a detailed level.
CASE tools are usually categorized as either Upper CASE or
Lower CASE tools. The wide variety of
CASE tools available makes it difficult to accurately define each category, but
in general an Upper CASE tool could be expected to:
Reside on a PC or Workstation
Assist a developer in generating graphical
documentation, such as flowcharts, brackets, Entity Relationship Diagrams, Data
Flow Diagrams, or other charts.
Possibly provide logic to support process
analysis, pseudo-code, or prototyping.
On the other hand, a Lower CASE tool might:
Reside on a larger mainframe or midrange
hardware platform.
Support the definition of field sizes,
valid data values, record layouts, and other detailed database specifications.
Actually generate program code in a
specific language, based on screen or report layouts designed within the CASE
tool by software developers.
Be designed to work with a certain vendor's
application software, with the CASE tool often developed and provided by that
vendor.
In general, the descriptive terms "Upper" and
"Lower" refer to the level of detail at which these tools support the
system development or modification effort.
An Upper CASE tool may be quite helpful in designing interfaces,
conversions, and modifications in a package software implementation, but is not
really necessary.
In a custom development project, however, an Upper Case tool
is almost required. Generating
consistent high-level design documentation for a complex custom development
project, without a CASE tool, can be tedious and time-consuming.
Performing the Design Work
On a custom development project, or where package software is
being heavily modified or enhanced, user-participation during the design
activity is required. A number of JAD
(Joint Application Development) sessions may be conducted for this
purpose. Care must be taken in
organizing such sessions so that a balance is maintained between user
personnel, project team analysts, and technical team members.
In package software installations where modifications and
other custom programming are expected to be minor in relation to the total
system, design work may be done by the project team without constant user
participation. However, caution should
be exercised in assuming that the project team understands the user
requirements. An enhancement designed in
isolation from the user community is likely to fail the user management review
and have to be redone.
Documenting the High-Level Design
A basic, straightforward approach to a high-level design
document would include the following:
Program Summary
Description of Inputs
Processing Flow
Description of Outputs
At the end of the Development
/ Programming section of this guide is a sample high-level design document,
prepared under the basic guidelines listed above. This particular sample document would
describe a program designed to calculate sales tax for sales orders already
entered into an Order Processing system.
The design documentation may be attached to, or filed with,
the Custom Software Control Form for each development item. A separate Custom Development Project Binder
should be maintained for this purpose.
User Management Review
When all the design documents, including cost and schedule
estimates, are complete for this activity, they should be reviewed by project
management with user and technical representatives, in a formal meeting
scheduled for this purpose. Simply
distributing the documents to key personal and waiting for sign-off does not
allow for an interactive dialog and in-depth review.
Revisiting the Project Work Plan
When the high-level designs have been approved for all custom
development items, the project work plan should be revisited. In particular, the scheduled deadlines for
Phase 3, Programming / Development,
and Phase 4, System Integration,
should be evaluated. The scope of any
custom programming may have been expanded during the last two activities, and
target dates for the remainder of the project will be impacted.
Cost estimates for all approved programming and design work
should be factored into the overall project budget, which should be revised and
reviewed with the executive sponsor.
At this stage, the project team has determined:
Which custom development items will be
included in the project.
How long each item will take to design,
code, and test.
How much each item will cost.
4. Perform Detailed Design
The Programming Supervisor
A programming supervisor should be appointed before the
detailed design is started. The
programming supervisor role is normally not a full-time position. Instead this resource may be selected from
among the programming team, and would typically have design and coding
assignments as well.
The programming supervisor monitors the status of design,
code, and test activity for all custom development items. A sample Custom Development Status Table,
used for this purpose, is provided at the end of the Programming / Development section of this guide. The status table should be updated by the
programming supervisor each week during the development period, and reviewed
with the project manager.
Using the status table as a tracking tool requires the
programming supervisor to meet regularly with the members of the design and
programming team, and insures that summary status information is available for
management.
Performing the Detailed Design Work
During the detailed design activity, a strategic decision must
be made concerning the assignment of design responsibility vs. coding
responsibility:
Will the designer of a custom item also be
its programmer, or will some team members do all the design while others
perform all coding work?
The primary advantage to having the same person design and
code a program or modification is that individual's familiarity with the
modification. The chances of a
requirement or design detail being missed during coding are reduced under this
strategy.
However, there are advantages to separating the design and
coding assignments. First of all, this
strategy helps insure that the project's design standards are followed
accurately. A programmer will not even
be able to begin without a good set of design specifications. As a result, the practice of documenting a
program's design after it is coded, which often leads to cutting corners, will
be reduced or eliminated.
Second, the skill sets for detailed design and coding and not
exactly the same. A senior-level
technical resource usually makes a good designer, while a less-experienced,
lower-cost resource may be assigned to programming.
If the project requires a great deal of custom development
work (more than 200 or 300 hours total), dividing the design and coding tasks
among separate team members would provide the best use of the available
skills. On the other hand, if only a
handful of small modifications have been identified, assigning design and
coding tasks to the same resource may be the best strategy.
The output of the detailed design work should be based on
the documentation for the high-level design developed earlier. Beyond that, the content and appearance of
the design documentation will depend on the database environment, the extent of
the modifications, the utilities and languages being used, and any CASE tool
supporting the design activity.
The completed designs should be reviewed and approved by the
technical manager for the project. If
the project has no technical manager, then a representative should be selected
from the organization (MIS Department, Operations Group, Maintenance Team,
etc.) which will support the system once it is in place. This group will need to understand and use
these same specifications when the time comes to enhance or upgrade the system
at some point in the future.
5. Code and Unit Test
The Code and Unit Test
activity brings together the output of the previous activities:
Programming and Database Standards
Requirements Definition
High-Level Design
Detailed Design
This activity also generates the final product from the Programming / Development phase.
To manage the quality of the programming product, the
standards developed in the Develop
Programming and Database Standards activity must be strictly followed. Applying the standards as code is written is
the correct approach to using programming and documentation rules. It is much harder, and riskier, to retrofit a
set of standards after the development is complete.
Budget and Schedule Tracking
Programming and unit testing (testing individual programs) are
among the most resource-intensive activities in most implementations. This is true whether "coding" means
typing lines of code into a mainframe-based program editor, or using a
high-level data definition language in a PC-based database and development
environment, or manipulating icons in a state-of-the-art GUI (Graphical User
Interface) platform.
For this reason, project budget tracking and scope control are
critical. All time spent on programming
and unit testing work should be recorded and monitored using the Custom
Development Status Table described earlier.
Scope Management
A Scope Impact Assessment form should be completed when the
work to be done includes scope not previously identified. For example, if custom programs are being
developed to report on purchasing activity from the Purchase Order files, an
additional scope might be a requirement to update those files when such a
report is printed.
If programming estimates are based on extracting and printing
data, and now these same programs will need to generate file updates, a scope
change has occurred. Failing to
document, and receive approval for, this scope change will cause the
development team to appear to be behind schedule and over budget.
The additional scope therefore needs to be identified,
documented, estimated, approved, and added to the overall programming budgets
and schedule.
Unit Testing
Unit testing is a concept often misunderstood by project and
user management. A thorough unit test of
a single program does not remove the need for an extensive System Test of the
entire software solution. A unit test
ensures that the program is operational, and that the program functions
match the detailed design.
Other industry names for test activities include:
String Test (testing how data is passed
from one program to another)
Integration Test (testing how major pieces
of software work together)
These kinds of tests are appropriately scheduled as components
of the System Test, which occurs in the System
Integration phase.
Complete
Quality Management Checklists
At the completion of all other activities in the Development / Programming phase, the
appropriate Project Manager's Checklists need to be reviewed or completed.
Project Manager's
Checkpoints, end of Development / Programming Phase:
Review Programming and Conversion
Checklist
Review & Complete Project
Administration Checklist
