The development phase involves converting design specifications
into executable programs. Effective development standards include
requirements that programmers and other project participants
discuss design specifications before programming begins. The
procedures help ensure programmers clearly understand program
designs and functional requirements.

Programmers use various techniques to develop computer programs.
The large transaction-oriented programs associated with financial
institutions have traditionally been developed using procedural
programming techniques. Procedural programming involves the
line-by-line scripting of logical instructions that are combined to
form a program.

Primary procedural programming activities include the creation
and testing of source code and the refinement and finalization of
test plans. Typically, individual programmers write and review
(desk test) program modules or components, which are small routines
that perform a particular task within an application. Completed
components are integrated with other components and reviewed, often
by a group of programmers, to ensure the components properly
interact. The process continues as component groups are
progressively integrated and as interfaces between component groups
and other systems are tested.

Advancements in programming techniques include the concept of
"object-oriented programming." Object-oriented programming centers
on the development of reusable program routines (modules) and the
classification of data types (numbers, letters, dollars, etc.) and
data structures (records, files, tables, etc.). Linking
pre-scripted module objects to predefined data-class objects
reduces development times and makes programs easier to modify.
Refer to the "Software Development Techniques" section for
additional information on object-oriented programming.

Organizations should complete testing plans during the
development phase. Additionally, they should update conversion,
implementation, and training plans and user, operator, and
maintenance manuals.

Development
Standards
Development standards should be in place to address the
responsibilities of application and system programmers. Application
programmers are responsible for developing and maintaining end-user
applications. System programmers are responsible for developing and
maintaining internal and open-source operating system programs that
link application programs to system software and subsequently to
hardware. Managers should thoroughly understand development and
production environments to ensure they appropriately assign
programmer responsibilities.

Development standards should prohibit a programmer's access to
data, programs, utilities, and systems outside their individual
responsibilities. Library controls can be used to manage access to,
and the movement of programs between, development, testing, and
production environments. Management should also establish standards
requiring programmers to document completed programs and test
results thoroughly. Appropriate documentation enhances a
programmer's ability to correct programming errors and modify
production programs.

Coding standards, which address issues such as the selection of
programming languages and tools, the layout or format of scripted
code, and the naming conventions of code routines and program
libraries, are outside the scope of this document. However,
standardized, yet flexible, coding standards enhance an
organization's ability to decrease coding defects and increase the
security, reliability, and maintainability of application programs.
Examiners should evaluate an organization's coding standards and
related code review procedures.

Library Controls
Libraries are collections of stored documentation, programs, and
data. Program libraries include reusable program routines or
modules stored in source or object code formats. Program libraries
allow programmers to access frequently used routines and add them
to programs without having to rewrite the code. Dynamic link
libraries include executable code programs can automatically run as
part of larger applications.
Library controls should include:

Automated Password Controls - Management should establish
logical access controls for all libraries or objects within
libraries. Establishing controls on individual objects within
libraries can create security administration burdens. However, if
similar objects (executable and non-executable routines, test and
production data, etc.) are grouped into separate libraries, access
can be granted at library levels.

Automated Library Applications - When feasible, management
should implement automated library programs, which are available
from equipment manufacturers and software vendors. The programs can
restrict access at library or object levels and produce reports
that identify who accessed a library and what, if any, changes were
made.

Version Controls
Library controls facilitate software version controls. Version
controls provide a means to systematically retain chronological
copies of revised programs and program documentation.

Development version control systems, sometimes referred to as
concurrent version systems, assist organizations in tracking
different versions of source code during development. The systems
do not simply identify and store multiple versions of source code
files. They maintain one file and identify and store only changed
code. When a user requests a particular version, the system
recreates that version. Concurrent version systems facilitate the
quick identification of programming errors. For example, if
programmers install a revised program on a test server and discover
programming errors, they only have to review the changed code to
identify the error.

Software
Documentation
Organizations should maintain detailed documentation for each
application and application system in production. Thorough
documentation enhances an organization's ability to understand
functional, security, and control features and improves its ability
to use and maintain the software. The documentation should contain
detailed application descriptions, programming documentation, and
operating instructions. Standards should be in place that identify
the type and format of required documentation such as system
narratives, flowcharts, and any special system coding, internal
controls, or file layouts not identified within individual
application documentation.

Management should maintain documentation for internally
developed programs and externally acquired products. In the case of
acquired software, management should ensure (either through an
internal review or third-party certification) prior to purchase,
that an acquired product's documentation meets their organization's
minimum documentation standards. For additional information
regarding acquired software distinctions (open/closed code) refer
to the "Escrowed Documentation" discussion in the "Acquisition"
section.

Examiners should consider access and change controls when
assessing documentation activities. Change controls help ensure
organizations appropriately approve, test, and record software
modifications. Access controls help ensure individuals only have
access to sections of documentation directly related to their job
functions.

System documentation should include:

System Descriptions - System descriptions provide narrative
explanations of operating environments and the interrelated input,
processing, and output functions of integrated application
systems.

System Documentation - System documentation includes system
flowcharts and models that identify the source and type of input
information, processing and control actions (automated and manual),
and the nature and location of output information.

System File Layouts - System file layouts describe collections
of related records generated by individual processing applications.
For example, personnel may need system file layouts to describe
interim files, such as sorted deposit transaction files, in order
to further define master file processing requirements.

Layouts - Layouts represent the format of stored and displayed
information such as database layouts, screen displays, and hardcopy
information.

Program Documentation - Program documentation details specific
data input, processing, and output instructions, and should include
documentation on system security. Program listings/source code and
related narrative comments are the most basic items in program
documentation and consist of technical programming scripts and
non-technical descriptions of the scripts. It is important that
developers update the listings and comment documentation when they
modify programs. Many software development tools are available that
automatically create source listings and narrative
descriptions.
Traditionally, designers and developers have used flowcharts to
present pictorial views of the sequencing of procedural programs
such as COBOL and Assembler. Flowcharts provide a practical way to
illustrate complex programs and routines. Flowcharting software is
available that can automatically chart programs or enable
programmers to chart programs dynamically without the need to draw
them manually.
Programming techniques, such as object-oriented programming, have
contributed to the use of dynamic flowcharting products.
Maintaining detailed documentation of object-oriented code is
particularly important because a primary benefit of the programming
technique is the reuse of program objects.

Naming Conventions - Naming conventions are a critical part of
program documentation. Software programs are comprised of many
lines of code, usually arranged hierarchically into small groups of
code (modules, subroutines, or components), that perform individual
functions within an application. Programmers should name and
document the modules and any related subroutines, databases, or
programs that interact with an application. Standardized naming
conventions allow programmers to link subroutines into a unified
program efficiently and facilitate technicians' and programmers'
ability to understand and modify programs.

Operator Instructions - Organizations should establish operator
instructions regarding all processing applications. The guidance
should explain how to perform particular jobs, including how
operators should respond to system requests or interrupts. The
documentation should only include information pertinent to the
computer operator's function. Program documentation such as source
listings, record layouts, and program flowcharts should not be
accessible to an operator. Operator instructions should be thorough
enough to permit an experienced operator who is unfamiliar with the
application to run a program successfully without assistance.

End-User Instructions - Organizations should establish end-user
instructions that describe how to use an application. Operation
manuals, online help features, and system error messages are forms
of instructions that assist individuals in using applications and
responding to problems.