BPI Custom Software Development – Examples

4.2.1 Custom System Development Methodology

Overview:

• Package modifications
• Software enhancements
• “Bug fixes, meaning correction of errors
• New system development.

• Requirements
• Conceptual Design
• Detail Design
• Development
• Quality Assurance
• Implementation
• Post-Implementation Review.

4.2.1 Custom System Development Methodology, Continued

Policies:

1. Procedures and standards for custom software development shall be followed for all custom software projects.
2. The decision whether to proceed with custom development or to acquire a package solution should be made at the conclusion of the requirements phase.
3. The Supervisor of system development and the user(s) will review, approve, and sign off all deliverables at each phase in the System Development Life Cycle (SDLC)
4. The User(s) and their Departmental Manager(s) will review, approve and sign off the following deliverables:

• Requirements Document
• Conceptual Design Document
• User Documentation
• User Training Materials
• Implementation Plan.

4.2.1.1 Requirements

Overview:

Policies:

1. Requirements are mandatory for all new development projects and software enhancements.
2. The Requirements Document must be approved and signed off by the Supervisor of System Development, the user(s), and the User Department Manager(s) prior to proceeding with the conceptual design phase.

Procedures:

1. The Supervisor of System Development receives a copy of a Problem Report form (SPUR), containing a general description of a software modification desired by user(s).
2. The Supervisor of System Development reviews the nature of the request and determines whether development of requirements is necessary.
3. If requirements are necessary, the Supervisor of System Development assigns an Analyst to this task.

4.2.1.2 Conceptual Design

Overview:

Policies:

1. A conceptual design document is mandatory for all new development projects.
2. A conceptual design document is mandatory for software enhancements (as defined in the System Development Overview).
3. The conceptual design document must be approved and signed off by the Supervisor of System Development, the user(s), and the User Department Manager(s) prior to proceeding with the detail design phase.

4.2.1.3 Detail Design

Overview:

Policies:

1. A detail design document is mandatory for all new development projects, and all software enhancements, minor and major.
2. The detail design document must be approved and signed off by the Supervisor of System Development prior to proceeding with the development phase.

Procedures:

1. Following approval of the conceptual design document, the Supervisor of System Development assigns development of the detail design to an available Analyst.
2. The Analyst develops the detail design document according to standards described in this section. This process involves applying technical knowledge of system construction to the conceptual design. The development of the detail design document consists of the following tasks:
1. Review and refine the process and database descriptions contained in the conceptual design document
2. Design system processing logic
3. Design system inputs, outputs and interfaces
4. Design manual procedures including special forms

4.2.1.4 Development

Overview:

Policies:

Procedures:

1. The Supervisors of System Development and Programming assign the task of coding to an available Programmer or Programmer Analyst.
2. The Programmer, Analyst and appropriate Supervisor will conduct a structured walkthrough of the system.
3. The Supervisor of System Development assigns the task of developing documentation and training materials to an available analyst.
4. The Analyst prepares unit testing test scripts for use by the Programmer.
5. The Programmer performs coding and unit testing.
6. The Analyst develops documentation and training materials.
7. The Supervisors of System Development and Programming review, approve and sign off on the code, unit testing results, and the documentation and training materials.
8. The tested code is moved into the QA environment, following change management procedures described in section 5.1.
1. The project plan is revised, if necessary.

4.2.1.5 Quality Assurance

Overview:

Policies:

1. All software must undergo a formal quality assurance review and approval prior to installation in production. This includes:
1. Custom software
2. Custom modifications to package software
3. Package upgrades
4. New packages
5. Enhancements and bug fixes.
2. All documentation and training materials must undergo a formal quality assurance review and approval prior to system implementation. The approvals will be documented on the Systems Development Checklist (SD0407).

4.2.1.6 Implementation

Overview:

Policies:

Procedures:

1. The Analyst develops a detailed plan or checklist for application implementation using the Production Run Sheet ( ____ ). Specific details of this are described in the standards section below. This checklist must be reviewed, approved and signed off by the Supervisor of System Development.
2. Install hardware, control software, and communications (if required). This task includes:
1. Facility preparation, if required
2. Test of hardware to ensure proper functioning.
3. Schedule down time on the system with all locations to prepare for conversion (refer to standard operating procedure manual for application-specific information).
4. The Librarian installs the new application software. This task includes:
1. Archive previous version of system
2. Move executable objects to the production environment
3. Update data dictionaries (if required)
4. Establish accounts and security for new users (if required)
5. Update technical, user and operations documentation

4.2.1.7 Post-Implementation Review

Overview:

Policies:

Procedures:

1. A self review session is held by MIS project team members within three weeks of system cutover. The review session discusses which aspects of the project went well and which areas require improvement. Specific topics may include project management and estimating, quality of system specifications user relations and overall team management. Results of this session are summarized in memo form and circulated among the project team members. Recommendations may form the basis of revision to standard system development methodologies.
2. A quality survey of system users is conducted between 30 and 90 days following implementation. The User Feedback form (SD0405) is distributed to all system users. Results are tabulated and circulated among the project team. A follow-up meeting is conducted to review the results and generate suggestions for improving the quality of the system development process.
3. System development metrics reports are compiled 90 days following implementation. These reports provide statistics on the amount of work effort and various quality measures for the system.

4.2.1.8 Training

Overview:

Policies:

1. Training should be included in the implementation plan for all application upgrades. Training should be provided to users, programmers and systems operations staff as required, prior to system installation.
2. For those user departments with their own training staff, Management Information Systems is responsible for training the trainers. The Supervisor of System Development is responsible for deciding whether MIS or the vendor will conduct user training.

Procedures:

1. The Analyst responsible for the application reviews documentation of the new system compared with the existing environment to determine the amount of training required and the issues to be addressed during the development of the training program.
2. The Analyst documents the training requirements for the software upgrade and develops a training workplan. The Supervisor reviews the requirements and workplan.
3. The software upgrade training requirements and workplan are reviewed, approved and signed off by the Manager and Supervisor of System Development. The approved training workplan is incorporated into the implementation work plan.

4.2.2 Custom Development Standards

Overview:

4.2.2.1 Technical Documentation

Overview:

Standards:

1. Standards for technical documentation are described in the detail design phase (section 4.2.1.4). These include:
1. Refined process and database descriptions
2. Functional decomposition of modules within the application
3. System processing logic for each module
4. System inputs, outputs and interfaces
5. Control provisions
6. Security provisions including ACLs and application level passwords.
7. Other aspects of the technical environment.
2. Additional documentation is provided by in-line comments in program code. Standards for in-line comments are described in sections 4.1.3.1 and 4.2.2.4.

4.2.2.2 User Documentation

Overview:

• Training materials
• Introductory guides and overviews
• Reference guides providing a comprehensive list of software functions
• Quick reference guides, such as function reference cards.

Standards:

1. All written documentation and training materials must use DecWrite word processing software unless this material is developed by a vendor in another format.
2. Training materials follows standards in sections 4.1.2.5 and 4.2.1.8.
3. Introductory guides and overviews describe system functions in general terms, emphasizing specific business functions that the software supports. Basics of transaction processing are provided without exception processing and detailed validation.

4.2.2.3 Operations Documentation

Overview:

Standards:

1. Operation documentation is developed as part of the Detail Design phase of the SDLC (section 4.2.1.3) and follows standards described in this section.
2. The Production Run Sheet (SD0410) includes specific run instructions for programs, including program installation, run instructions and error recovery. Supplementary operations procedures are written in memo format and attached to the Production Run Sheet.
3. All operation documentation is to consist of step-by-step procedures, including specific prompts and the response required by the operator. Error conditions and exception processes are fully described.

4.2.2.4 Coding Standards

Overview:

1. Custom programming within the Tolas application
2. Custom programming within the PROMIS (Patient-Reported Outcomes Measurement Information System) application
3. Custom programming using Oracle.

Standards:

1. The beginning of every program consists of a comments section listing:
2. Program name
3. Purpose of program
4. Author and date program created
5. Subroutines used by the program
6. Files used by the program
7. The argument list for each subroutine used.

4.2.2.5 Naming Standards

Overview:

Standards:

1. Subsystem names consist of three character mnemonics (e.g., LOT, PRO).
2. Module names use the format:
1. mmmmmmmmm.xxx
2. Here:
3. mmmmmmmmm is a descriptive name of up to nine characters
4. xxx is a file type extension.
3. Subroutine names consist of the subsystem name, module name, and subroutine name separate by underscores (e.g.,ÊLOT_MODULE_SUBMOD).
4. Mainline routines called from a PROMIS (Patient-Reported Outcomes Measurement Information System) menu use the format sssmain.for where sss is the three character subsystem name.
5. Mainline routines invoked as PROMIS (Patient-Reported Outcomes Measurement Information System) detached processes use the format sssserver.for where sss is the subsystem name.
6. Mainline routines used to initialize the PROMIS (Patient-Reported Outcomes Measurement Information System) tables use the format sssinit.for where sss is the subsystem name.
7. Include files use the format aaa:sssDEF.FOR where aaa is the include file type and sss is the subsystem name.
8. Parameters used as constants use the format TYP_nnnnn defined in the PROMIS (Patient-Reported Outcomes Measurement Information System) parameter definition files.

4.2.2.6 Screen Display Standards

Overview:

Standards:

1. Screen standards are described in the Introducing…TOLAS manual. These include:
1. Menu screens described in chapter 2
2. Field formats and error messages described in chapter 4
3. Function key definitions and menu-level command options described in chapter 6.

4.2.2.7 Printed Report Standards

Overview:

Standards:

1. The standard PROMIS (Patient-Reported Outcomes Measurement Information System) report heading consists of the following: