Development Process for New Requests and Customizations

Workflow

This is a high level illustration of the development process for new requests and customizations.

Click to Enlarge.

Workflow Details

  1. Request Opened
    Change request ticket created by Functional User using JIRA. Business Requirements Document (BRD) is attached if needed.
  2. Request Assigned
    The JIRA ticket is assigned to the BI Manager, who re-assigns it to a System Analyst(SA).
  3. Systems Analyst BRD Review
    The BRD is archived.
    The Systems Analyst reviews the Change Request ticket and the BRD and determines whether they are clear and complete.
  4. User BRD Clarification
    If the Systems Analyst has questions about the BRD, the Systems Analyst consults with Functional User for clarification.
  5. Build/Revise Functional Specification
    The Functional Requirements Document is created by the Systems Analyst.
    The Functional Requirements Document is archived.
  6. Peer Review of Functional Specification
    Functional Requirements Document reviewed by BI Team. If necessary, it is sent back to the Systems Analyst for revision.
  7. User Review of Functional Specification
    Functional Requirements Document reviewed by Functional User. If necessary, it is sent back to the Systems Analyst for revision.
  8. Build Technical Specifications
    The Technical Specification Document is created by ETL Developer, the OBIEE Developer, and/or the Architect.
    The Technical Specification is archived.
  9. Technical Specification Peer Review
    The Technical Specification Document is reviewed by the BI development team. If necessary, it is sent back to the designers for revision.
  10. Technical Specification Manager Review
    Technical Specification Document reviewed by BI Manager. If necessary, it is sent back to the designer(s) for revision.
  11. Development
    Development work begins.
  12. Unit Test
    The developed capability is Unit Tested by the Developer(s).
    Once developers have viable code, it is archived.
  13. Peer Code Review
    New code is reviewed by fellow Developer and Systems Analyst. If necessary, it is sent back to the developer(s) for revision.
    Old code in Test archived before migration.
  14. Approve & Request Migration
    The BI Manager approves the migration of the developed capability to Test. If necessary, requests for the data center to participate in the migration are created.
  15. Migrate to Test
    The appropriate party migrates the various changed components to Test.
  16. Systems Analyst Review
    The Systems Analyst reviews changes in Test before involving users in testing. If necessary, the Systems Analyst specifies needed changes and sends the work back to developer(s) for revision.
  17. UAT
    User Acceptance Testing is done. If necessary, the Systems Analyst reviews User Acceptance Test results, specifices needed changes, and sends the work back to developer(s) for revision.
  18. Approve & Request Migration
    The BI Manager approves the migration of the developed capability to Production. If necessary, requests for the data center to participate in the migration are created.
  19. Migrate to Production
    The appropriate party migrates the various changed components to Production.
  20. Request Closed
    The original JIRA request is closed by the BI Manager.

Glossary


Red line represents an unsuccessful procedure.


Green line represents a successful procedure.

BRD
Business Requirements Document.

Dev
Development.

Functional Spec
Functional Specification or Functional Requirements Document.

Prod
Production.

Technical Spec
Technical Specification Document.

UAT
User Acceptance Test.