Monday, September 11, 2017

BPI Custom Software Development – Examples

BPI Custom Software Development – Examples

The following are excerpts from a Software Development Life Cycle methodology and Custom System Development Standards. These examples should provide the practitioner with guidelines to follow for a custom software development project.

4.2.1 Custom System Development Methodology

Overview:


This section governs the development of any custom software by MIS staff or outside vendors. Specifically included in the definition of "custom" software are:

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

Development of custom software is governed by a phased approach referred to as the "System Development Life Cycle" or SDLC. The phases of the SDLC are:
  • Requirements
  • Conceptual Design
  • Detail Design
  • Development
  • Quality Assurance
  • Implementation
  • Post-Implementation Review.
Each stage builds on the activities of the prior stage. Each phase has its own set of tasks and deliverables, which will be described in more detail in the appropriate section of this manual.

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.
The sign off will be documented on the System Development Checklist (SD0407).
Procedures:
The diagram illustrates the custom software System Development Life Cycle.

4.2.1.1 Requirements

Overview:


The purpose of requirements definition is to develop the overall scope of the system development effort, to provide a general overview of the functions required, and to assist management in making a decision regarding whether or not to proceed with the project.

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:

The specific steps involved in requirements definition are:

  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:


The conceptual design phase produces a more detailed description of the functions of the proposed application. It is intended to provide the user(s) with a nontechnical description of system functions.

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:

The detail design document provides the instructions for the programmer and other staff to construct the system. The detail design specification should be clear and precise enough to permit staff to construct the system based on their technical skills alone, without further clarification of the business functions of the system.

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:

Development is the process of implementing the application system described in the previous phases. This phase involves coding and development of documentation and training materials.

Policies:


Procedures:

The following are the procedures for development:

  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:

Quality assurance ensures system acceptability, both in terms of performing the functions specified by the user and in terms of meeting coding and design standards described in sections 4.2.1.4 and 4.2.2.4. Quality assurance policies, standards and procedures apply to new development, enhancements, "bug fixes" and all modification of package software.
Quality Assurance plays an additional role in the MIS environment. This involves maintaining records of any failure of quality assurance standards, analyzing the failures to note those which are most significant, and recommending changes in MIS policies, procedures, and standards which will improve software quality.
Preparation of test scripts and performing of test procedures is the responsibility of the development team. The separate Quality Assurance function ensures that these test scripts and test results meet applicable standards. Preparation of documentation and training materials is likewise the responsibility of the development team, with Quality Assurance performing a quality review of these deliverables.

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:

Implementation is the process of installing the fully tested and accepted system (or individual programs) in the production environment.

Policies:

Procedures:

Note that specific responsibilities are not assigned to each task. Responsibility for tasks is specified in the implementation plan which should, at minimum, contain all these tasks.
The specific steps involved in implementation are:
  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:

Post-implementation review provides feedback to MIS on the quality of system development projects. This is an opportunity for MIS to evaluate their procedures and methods, review their strengths and weaknesses, and improve them.

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:

Training is performed in the Implementation phase of the SDLC. Training plans are important enough to justify special consideration in the description of the SDLC process. Training policies, procedures, and standards applying to package software are described in section 4.1.2.5.

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:

The following is the procedure for training associated with a custom application change or new development:
  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:

This section contains standards for custom software development. These standards are intended to apply to the development phase of the SDLC and, to a lesser extent, the detail design phase. These standards are intended for use as a guide by programmers and documentation writers.

4.2.2.1 Technical Documentation

Overview:

This section contains standards for technical documentation. Technical documentation includes any information regarding detail design and system development required by MIS to maintain and enhance the application. Technical documentation may reside in hardcopy specifications or as in-line comments in code.

Standards:

The following describes the standards for application technical documentation:
  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:

This section includes standards for any documentation whose intended audience is the user of the application. User documentation encompasses:
  • Training materials
  • Introductory guides and overviews
  • Reference guides providing a comprehensive list of software functions
  • Quick reference guides, such as function reference cards.

Standards:

The following standards apply to the various types of user documentation for all custom applications:
  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:

Programs may require intervention by system operators, either on a periodic basis (initiating periodic batch processing) or on an exception basis (program abort). Documentation of regular and exception procedures for use of operations staff must follow standards in this section to ensure they are clear and readable.

Standards:

The following standards apply to system operations documentation:
  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:

This section includes standards for programming, including structured coding and use of parameters and common blocks. Standards are described that are common to all applications as well as those that only apply to certain systems. Standards that only apply to certain systems are described separately for:
  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 applying specifically to package software modification are described in section 4.1.3.

Standards:

The following programming standards apply to all applications:
    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:

This section contains standards for naming programs, files, and other objects associated with the various system applications.

Standards:

The following are PROMIS (Patient-Reported Outcomes Measurement Information System) naming 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:

This section contains standards for design and use of on-line screens. These standards include screen layouts, function key use, and field attributes such as use of bold or underlined fields.

Standards:

The following screen design standards apply to Tolas applications:
  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.
The following screen design standards apply to PROMIS (Patient-Reported Outcomes Measurement Information System) applications:

4.2.2.7 Printed Report Standards

Overview:

This section contains standards for report layout. These standards include report headings, footings, subtotal and control-break printing.

Standards:

The following printed report standards apply to all applications:
  1. The standard PROMIS (Patient-Reported Outcomes Measurement Information System) report heading consists of the following:
COL
ROW
TEXT   
1
1   
"SSI"
centered
1   
Report name
118
1   
"Page n" for page number
1   
2   
“Report Generated :"
centered
2
"CONFIDENTIAL"
21
2   
Current Date
33
2   
Current Time
1   
3   
"Report Period :"
21
3   
From Period Date
33   
3   
From Period Time
42
3   
"-"
45
3   
To Period Date
55
3   
To Period Time
at

No comments:

Post a Comment