Standards for Developing and Maintaining Computer Applications

If you develop or maintain computer applications for administrative purposes at UCSD, read the following recommended and required standards.

Background

The University of California has defined standards for developing and maintaining computer applications used for administrative purposes. These standards are presented in the IS-10 (pdf) document. UC San Diego follows these standards in absence of specific local policy. Any department or vendor hired by the campus that develops, installs, or maintains administrative applications must consider these standards. Deciding when they apply depends on the nature of the application, not on who is developing it.

You need to consider two primary characteristics of applications when determining whether or not these standards apply:

1. Risk of the application
   • Determine how essential the system is to the operation of the department/ University. A system is considered High Risk if a failure of the system to function correctly and on schedule could result in a major failure by the department/ University to perform essential functions, a significant loss of funds to the University, or a significant liability or legal exposure to the University.
2. Size and complexity of the application
   • Development: small/simple - When considering the development or installation of a system, a small or simple application is one that would take less than one year of effort (staff time) to develop and implement, or less than $150,000 in cost.
   • Maintenance: small/simple - When considering the maintenance of a system, a small or simple application is one that would take less than one month of effort (staff time) to modify and implement, or less than $15,000 in cost.

Application of the Standards: The following table outlines when these development and maintenance standards must be followed (required), should be followed (recommended), or may be followed (optional). In all cases, you should use your best judgment in applying these standards.

A. Maintenance standards for small modifications to low-risk applications (See IS-10 section 4.2): You must:

• Log and retain the request for change (e-mail is sufficient)
• Document and date the program changes

B. Maintenance standards for modifications to high-risk applications or large/ complex systems (See IS-10 section 4.3): You must consider the following:

1. Source control: Changes to existing systems and application software requires:
   • Procedures for segregating production and test code
   • Procedures for checking source code in and out
   • Procedures for testing the changes in stages of increasing impact
   • Standards for identifying the changes that were made (including the date of the change and the name of the programmer)
   • Procedures for notifying others of the changes
   • Procedures for user review of functionality and presentation
   • Criteria for installing the modified source code in production mode
2. User participation: Involve users at appropriate stages of the change process. For enhancements and program fixes, document user participation (in the form or a log or other format, including e-mail) so it is clear that changes were not made at the discretion of the technical staff alone. If changes do not affect the functionality of an application (e.g., a calculation) and are done for security, reliability, or performance reasons, user participation is not necessary. Follow procedures for the:
   • Receipt of requests for enhancements or identification of system problems
   • Identification, discussion, and resolution of issues associated with the proposed changes
   • Priorities for proposed changes, and discussion and resolution of differences regarding priorities
   • If appropriate, cost and time estimates for proposed changes
   • User review and acceptance of testing
   • User review and acceptance of completion of the changes and readiness for production

C. Maintenance standards for modifications to large/ complex applications (See IS-10 section 4.4): You must follow the standards in Section 2 of the UCOP IS-10 document Systems Development and Maintenance Standards (pdf).

System Development tracks and phases: The IS-10 standards document describes the phases of a systems development project (See IS-10 section 2). The exact methods employed for systems development will vary depending on the specific project. Although every systems project is unique, there are three key characteristics which will influence the overall approach chosen for systems development:

1. The overall size and complexity of the application
2. The technology to be used for developing the application
3. Whether the system will be a purchased package, or custom developed

Three separate development approaches or "tracks" have been identified for consideration:

• Prototyping: appropriate for custom development of smaller systems or systems that use newer technology such as Web-based development tools
• Traditional life cycle approach: more suited to custom development of larger systems, such as mainframe applications
• Vendor package: covers the purchase and implementation of vendor packages.

Some phases of project development apply to a combination of two or more approaches, whereas others are unique to one approach. The Project Leader is responsible for making recommendations regarding the best approach for a project, and keeping appropriate records. (See IS-10 section 1.3 for more information on the tracks, and section 2 for more information on the development phases)

*Note (See IS-10 section 2.7 - Purpose): The feasibility study is only necessary under circumstances where significantly different options are available for providing a systems solution to the functional needs identified in the Systems Definition phase (section 2.3 - Prototyping) or the Requirements Definition phase (section 2.5 Traditional or Vendor).

This page has a friendly link that’s easy to remember: http://blink.ucsd.edu/go/is10standards

Technology

Developing & Implementing Applications

• Standards
• Planning Phase
• Analysis Phase
• Prototype Phase
• Design Phase
• Development Phase
• Training Phase
• Implementation Phase