Software Standards Policy

Version: 1.00Issue Date: 4/6/2015

This Software Standards Policy specifies requirements for software project management and design requirements.

1.0 Overview

This Software Standards Policy will help ensure the quality of software generated by, generated for, and used by the organization. This Software Standards Policy will improve the security of the organization by ensuring that software is generated with fewer security flaws.

2.0 Purpose

This Software Standards Policy is intended to ensure that software used by the organization or generated by or for the organization has fewer flaws. Software generated by or for the organization should meet a uniform quality standard.

3.0 Scope

This Software Standards Policy applies to any and all software generated for the organization, software generated by the organization, and software used by the organization. This policy is effective as of the issue date and does not expire unless superceded by another policy.

4.0 Third Party Software Contract Requirements

  • When software is developed, all source code must be owned by our organization or code not owned by our organization must be placed in software escrow so that if the contractor goes out of business our organization will still be able to maintain the software. Circumstances under which the escrowed software would be released must be defined and should include poor service response times which are defined, business termination, and not fulfilling the obligations of the maintenance agreement. This is especially true of business critical software.
  • If software is purchased with a license agreement from a third party, a fixed support contract must be established at the time of purchase. An annual maintenance fee may be negociated for support services. Items covered by the support contract should be specified and may vary depending on the business need. Software enhancements, bug corrections, consultations, user training, technical training, and maintenance should be considered.
  • If the contractor developing software outsources their work to another third party, the contract should require any deliverables to be reviewed and approved by the business stakeholders. The subcontractor must be held to the minimum standards of our organization's policies, procedures, and the contract.
  • Any third party that is testing software with confidential data must guarantee that the data will be kept securely and confidential.
  • When the finished software cannot be owned, broad licensing rights of the software must be obtained.

5.0 Software Project Management

  • Functional requirements for the project must be created at the start of the project.
  • The System Development Life Cycle (SDLC) methodology used must provide an information gathering period of time where project requirement information from the customer and users may be accumulated. The following functional items must be considered:
    • Program control requirements information from the customer and users.
    • Security requirements from the customer and users.
    • Internal and application controls covering both security and program access and operation must be considered. Controls that consider timeliness, authorization, completeness, and accuracy of information must be considered.
    • System availability requirements must be determined and considered during the design phase.
    • The SDLC must provide a procedure that can ensure that proper technical and user documentation and reference materials were created and made available before the system is accepted.
  • Program specifications must be created based on the functional requirements. The project designers must follow the program specifications.
    • The application control specification must comply with organizational security policy.
    • Program specifications should provide proper backup planning for data along with planning for hardware redundancy and failure tolerance based on the system availability requirements determined in the functional requirements.
  • Part of the program specification includes the input requirements definition.
    • The input requirements definition must correlate with the use of the data and allow the data to be captured appropriately considering the data source. For example, user input should be validated in case of accidental errors or attempts to use the interface to attack the system.
    • The input requirements definition must consider all data and data sources including data already stored on the system, data that is manipulated, and data that is captured.
    • The input requirements definition must require all data put into the system to be validated and checked for potentially harmful content where harmful content may be input. The input requirements definition should specify the input validation method.
    • The input requirements definition allows for automatic correction of input errors where it is possible and safe.
    • The input requirements definition must specify that only valid input is processed.
    • The input requirements definition must specify that the system should check all input for attempts to compromise the system deliberately.
  • During all phases of the project, the following must be considered:
    • The system must be maintainable.
    • The system must be modular in a nature to keep it maintainable.
    • The system must be properly documented for technical staff including database format and source code documentation.
    • The system must be properly documented for users.
    • The system must be properly tested.
    • System maintenance staff must be properly trained.
    • Users must be properly trained.
    • The system should be able to operate on multiple platforms.
  • Version Control - The Configuration Management Policy must be followed when developing software so the configuration of the software is controlled by a source code librarian and the Software Version Control Team.
  • The project plan must allow time to create effective documentation and allow for assignment of this task. Documentation requirements must be met during the SDLC process.

6.0 Design Requirements

  • Processing requirements
    • The sequence of programs and subprograms used should be documented.
    • The steps to be taken when a processing failure occurs should be planned. All types of failures should be considered including an inability to access a file, inability to access a database, user error or unexpected input, and any case where an alternate possibility exists.
  • Preliminary system level requirements
    • A system interface includes anything that exchanges data with the system including user input, and data source, the data format, and the data structure. Interfaces to the system must be determined before the system level requirements are finalized.
  • Documentation Requirements
    • Flowcharts or pseudocode covering the design and functionality of the project are required. Flowcharts or pseudocode must be done in a manner which can be understood by people who are not technically oriented. Sufficient detail must be included in flowcharts or pseudocode to allow the programmers to code accurately.
    • Code should be documented to minimum standards specified in the Software Standards Specification. This documentation includes documentation about each processing function. Comments should reference the design and requirements documentation.
    • All file formats must be documented.
    • All database formats/schemas must be documented.
    • Documentation must be designed appropriate for the skill level of the user and should not assume technical expertise unless expertise is assured.
    • User documentation must inform users about how to use the program and provide information about available commands and screens. User manuals must be written as simply and direct as possible.
    • User manuals must comply with user manual guidelines and instructions.
    • End users must have a part in the development or review of user manuals before they are finalized.
    • The owner of the documentation including user manuals must be established with set responsibility for maintaining the manuals and system maintenance procedures.
    • Project stakeholders must be informed about the documentation standards.
    • A structured training program must be created.
    • A method to monitor the effectiveness of the project documentation must be created. User feedback should be used to help determine the effectiveness of the documentation and training.
    • When needs for improvement in documentation or training are found, they must be reported to the owners of the documentation and training materials so improvement can be made.
    • Tools for creation, maintenance, and version tracking of documentation and training materials are used when possible.
    • Documentation and training templates are created and used where possible to increase efficiency and maximize consistency of documentation.

7.0 General Quality Programming Requirements

  • Stored procedures for database access
  • Minimum documentation of code
  • Routines/program code containing functionality which is commonly used such as password reset, login screens, validating and parsing of user input, and display screens should be created and placed in a library where it can be shared with other programmers in the organization. This code should be optimized and designed to be secure. All shared code should be reviewed for flaws before it is shared.
  • Programmers are required to use the library of shared code wherever possible to support their project. This will decrease development cost and increase security since the shared code was previously reviewed for flaws.

8.0 Data Collection Design

  • All data put into the system must be validated and checked for potentially harmful content where harmful content may be input.
  • All user input into the system must be validated for accidental errors or attempts to use the input to attack the system. An example is that email addresses input must be checked to be sure they are email addresses and only one email address. If a text dropdown box is used for input, the system must be sure that only content from a legitimate selection of the dropdown box was entered.
  • All user input must be validated on the system side and not only on the client side.
  • The data collection system must be designed to be sure no input data is lost due to poor system performance.

9.0 Software Help Function

  • Help based on features the user is using (context sensitive) should be available for all user system functions, screens, and dialog boxes.
  • Help functions should help the user efficiently complete tasks or fix problems.

10.0 Output Requirements

  • Output requirements should be designed around the use of the system, required details, types of users, how often the output is generated, and how the output is generated.
  • An output requirements definition shall be created which documents the expected output format. Consideration must be given for how to provide confidentiality, integrity, and availability needs.
  • The output requirements must specify requirements for output validation which ensures complete and accurate information to be output.
  • The type of data being output is classified and the security needs of the data must be considered. The level of security of the data must be considered.

11.0 Data Handling and Storage

  • Available data integrity mechanisms to prevent data corruption should be used. It should be possible to restore data from backup when the data in the system has become corrupt.
  • A backup plan should provide a limitation to the amount of data that can be lost due to data corruption.
  • Data that is sent across unsecured media must be digitally signed with a signature that can be verified by a certification authority. This will provide data integrity.

12.0 Testing

  • A code review must be performed to be sure programs are meeting coding standards of quality and security including standard organizational design and naming conventions.
  • Test plans and testing procedures related to the project should be developed based on organizational test standards.
  • The test plan should be walked through before testing is begun. The tester's tasks and responsibilities should be reviewed along with test scenarios, test standards, and system acceptance criteria based on testing.
  • Testers that were not involved in the system development should be used to perform testing against the system.
  • System owners and/or end users should test the system and indicate whether the system meets their expectations. The end users or system owners should indicate in writing whether the system requirements have been met and tested successfully.
  • Tests should be performed using code (use executable code or build code from versioned source code) received from the librarian who controls the distribution and version control of software.
  • Data used for tests may be real system data or test data but test data must be similar to live data in type and how it performs on the system.
  • Notes and reports from testing must be kept during the life of the system.
  • Test results should be kept confidential and should not be allowed to be changed.
  • Test results must be used to itemize problems and issues that must be resolved. Items must be prioritized and corrected.
  • If any program is put into production with known errors, senior management must acknowledge that and approve it in writing prior to operating the system in the production phase.

13.0 Enforcement

Since proper software standards and quality are important for the security of the organization, employees that purposely violate this policy may be subject to disciplinary action up to and including denial of access, legal penalties, and/or dismissal. Any employee aware of any violation of this policy is required to report it to their supervisor or other authorized representative. Any third party that violates this policy may be subject to financial penalties including but not limited to termination of their contract or contracts.

14.0 Other Requirements

  • Software Standards Specification
  • A SDLC Methodology must be created and documented
  • Develop a process that requires end user groups to be involved in the development and testing of user manuals. The process should:
    • Require ownership of user manuals so it is determined who is responsible for the maintenance of the manuals after the system has been developed and has entered the maintenance phase of the project.
    • An operations manual template should be developed and used as part of the process for creating user manuals.
    • The user manual creation should require the involvement of the users when user manuals are created.
    • User manual updates should require the involvement of the users.
  • Develop instructions and guidelines about how to write user and technical manuals.
  • Develop a process for creating training materials and performing user training.
    • Require ownership of user training materials so it is determined who is responsible for the maintenance of the materials after the system has been developed and has entered the maintenance phase of the project.
    • A template for training materials should be developed and used when training materials are developed or updated.
    • The user training material creation and update process should require the involvement of the users.
    • The development of the manuals should be on schedule so they are available for the users when needed. The process should provide for updating the manuals on a timely basis as the system is modified.
    • Manuals should be distributed only to individuals who have a need for them and it should be done in a timely manner.
    • Users should be able to provide feedback about the effectiveness of the manuals and training program.
  • Develop organizational software test standards which are documented well and provides information about different types of tests including user testing, acceptance testing, integration testing, unit testing, and load testing. The adequacy and performance of help functions and manuals must be considered as part of testing.


Approved by:__________________________ Signature:_____________________ Date:_______________