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. BRD Created, Request Opened
    A Business Requirements Document (BRD) describing the needed change is created by a Functional User, who then creates a ticket using JIRA and attaches the BRD to the ticket.
  2. Request Assigned
    The JIRA ticket is assigned to the BI Manager, who assigns the work to a System Analyst(SA).
  3. Systems Analyst BRD Review
    The BRD received from the Functional User 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 Specification Document is created or revised by the Systems Analyst.
    The Functional Specification Document is archived.
  6. Peer Review of Functional Specification
    The Functional Specification Document is reviewed by the BI Team and the BI team Manager. If necessary, it is sent back to the Systems Analyst for revision. Once the BI Team approves it, the specification is ready for user review.
  7. User Review of Functional Specification
    The Functional Specification Document is reviewed by Functional Users. If necessary, it is sent back to the Systems Analyst for revision. Once the Functional Users approve it, the specification is ready for BI Management review.
  8. Functional Specification Approval
    The Functional Specification Document is reviewed by the BI Manager. If necessary, it is sent back to the Systems Analyst for revision.
  9. Build Technical Specifications
    The Technical Specification Document is created by a design team made up of ETL Developers, OBIEE Developers, and/or Architects.
    The Technical Specification is archived.
  10. Technical Specification Peer Review
    The Technical Specification Document is reviewed by the BI development team. If necessary, it is sent back to the design team for revision. Once the BI Team approves it, the specification is ready for user BI Manager review.
  11. Technical Specification Manager Review
    The Technical Specification Document reviewed by the BI Manager. If necessary, it is sent back to the design team for revision. Once the BI Manager approves it, the specification is ready for development.
  12. Development
    Development work begins.
  13. Unit Test
    The developed capability is Unit Tested by the Developer(s). Additional development work is done to fix errors until all unit tests are successful.
    Once developers have viable code, it is archived.
  14. Peer Code Review
    New code is reviewed by fellow Developers and Systems Analysts. If necessary, the code is sent back to the developer(s) for revision. Once the code is approved, it is ready ready to be moved into the Test environment.
    Old code in the Test environment is archived before new code is moved into the envrionment.
  15. Approve & Request Promotion
    The BI Manager approves the move of the developed capability into the Test environment. If necessary, requests for the data center to participate in the move are created.
  16. Promote to Test
    The appropriate party moves the various changed components into the Test environment.
  17. Systems Analyst Review
    The Systems Analyst evaluates the changes in the Test environment before involving Functional Users in testing. If necessary, the Systems Analyst identifies problems or specifies needed changes and sends the work back to developer(s) for revision. Once the Systems Analyst is satisfied that the change is ready, Funcationl Users are notified to begin UAT Testing.
  18. UAT & Approval
    User Acceptance Testing is done by Functional Users, who also review test results. If necessary, the Functional Users identify problems or specify needed changes, and send the work back to developer(s) for revision. Once all tests are successful, the Funcitonal Users approve the work.
  19. Approve & Request Promotion
    The BI Manager approves the promotion of the developed capability into the Production environment. If necessary, requests for the data center to participate in the move are created.
  20. Promote to Production
    The appropriate party archives existing code before moving new components into the Production environment.
    The appropriate party moves the various changed components to the Production environment.
  21. Close Request
    The original JIRA request is closed by the BI Manager.

Glossary


A red line represents an unsuccessful outcome to a procedure.


A green line represents a successful outcome to a procedure.

BRD
Business Requirements Document

Dev
Development

ETL
Extract, Transform, Load – The process of populating a data warehouse, and a description of special software tools that do that function.

Functional Spec
Functional Specification or Functional Requirements Document.

Prod
Production

Technical Spec
Technical Specification Document

UAT
User Acceptance Test