Policies: Process Method
 |
JHZ-CS's Process Method defines task relationships by inputs and outputs. Inputs are a dependency originating from a previously completed task outputs. Tasks are grouped into Phases divided into Stages organized by sequence of occurrence. Task completion is a requirement to commencing with subsequent tasks. Hence, JHZ-CS's Process Method is referred to as a "Phased Staged" approach. |
Project Phases & Stages
-
Project Proposal Phase
-
Requirements Analysis
Input: Initial Design Request
Output: Project Proposal -
Project Initiation
Input: Project Proposal
Output: Project Agreement
-
-
Design Phase
- External Design (function)
- Internal Design (logic)
Input: Project Agreement
Output: Function and Logic Specifications -
Development Phase
- External Interface Coding
- Logic Coding
- Unit Test
Input: Function and Logic Specifications
Output: Unit Tested Code/Components -
Function Test Phase
Testing is performed in an integrated emulated production environment.
- New Function Test
- Regression Test
- Progression Test Stage (when required)
Input: Unit Tested Code/Components, Function and Logic Specifications
Output: Tested Code/Components -
Integration Verification Test Phase
- Code Integration
- Integration Test
- Customer Verification
Input: Tested Code/Components
Output: New Function(s)
Optional Project Phases
-
User Documentation Phase
Input: Design Specifications
Output: Users Guides and References -
User Training Phase
Input: Users Guides, References, and Training Materials
Output: Trained User base -
Skill Transfer Phase
Technical information transfer intended for future in-house maintenance and support (can be formal, informal, or documentation may serve as substitute)
Input: Code and documentation
Output: Trained Technical Personnel
Project Documentation
Project documentation provides specification of requirements. The documentation serves as reference for project communications and progress monitoring. The documentation's purpose continues following project completion. It serves as technical reference for maintenance, skill transfers, training and as baseline specification for subsequent enhancements.
Parallel co-development project environments benefit from formal project documentation assisting in communication of co-dependent component technical information required by multiple groups.
-
Project Proposal
The Project Proposal is a living document during the Initial Requirements Analysis and Proposal Stages. It begins as a response to a request for proposal. It defines project purpose, objective, requirements, pre-requisites, dependencies and terms that include copyright ownership, cost, and time of completion. It includes design considerations, recommendations and suggestions. It is input to the Project Agreement.
The Project Proposal undergoes a series of reviews and revisions until a mutual understanding is reached pertaining to the project requirements, objectives and approach. This review process concludes with the Project Proposal becoming the Project Agreement; however, the Project Agreement does not become active until signed by all parties, start-of-work payment received and funds cleared.
-
Project Agreement
The Project Agreement explicitly defines project purpose, objectives, requirements and terms including copyright ownership, cost and time of completion. It is the result of the Project Proposal Phase. Upon mutual agreement, acceptance and approval, along with satisfaction of project initiation requirements described in the agreement, the project is officially initiated and commences to the Design Phase.
-
The Function Specification
The Function Specification defines all external aspects of new and existing interfacing components impacted by the project; components that accept input and/or produce output. Inputs and outputs may be user initiated or machine initiated. It describes each external component elements, attributes and aspects pertaining to its inputs and outputs. The Function Specification serves as: input to the Logic Specification, input for coding user and machine interfaces, and input to Function Test. The Function Specification does not describe logic aspects. Those are described in the Logic Specification.
-
The Logic Specification
The Logic Specification defines internal logic and processing aspects of components created or impacted by the project. It describes logical processes operating on inputs and producing outputs defined in the Function Specification. It defines "component to component" and "component to sub-component" relationships. The Logic Specification serves as input along with the Function Specification to Coding, Unit Test and Function Test and serves as process flow logic map for subsequent projects.
Design Changes Policy
Design Changes are changes that are made after completion of a project's Design Phase. Design changes occur as a result of unanticipated changes in requirements from that of the original requirements. Typically design changes are a result of additional beneficial functionality being identified and desired during development phases. In order to assure smooth project progression and an on-time completion, JHZ-CS utilizes a design change policy.
All design change requests are treated as a separate enhancement project request. This isolates the design change request from the on-going project eliminating its impact. Upon completion of the on-going project a subsequent enhancement project follows with completion of the on-going project as a pre-requisite. References to the completed project's documentation eliminates re-work and duplication of effort.
All design change requests may be grouped into a single enhancement project; also following the JHZ-CS "Process Method."
Exceptions occur when a design change request is minor without impact to the current project's terms, cost and time of completion. Major changes rendering large portions of a project to no longer be purposeful require conversion of the project into a new project request. Degree of impact of each design change request is determined at the sole discretion of JHZ-CS.