Cloud Specifications
      Back to home
      1. Help Centre
      2. Technical & Security
      3. Cloud Specifications

      Development Processes

      Description of processes and procedures related to the development of FMI products

      This article is for IT and security professionals

      Development Process

      FMI products are developed using the agile Scrum methodology. This formal methodology provides a balance between responsiveness to new features and the quality and stability of the production environment.
      An abbreviated overview of the process follows.

      1. The Product Owner is responsible for the management of all new work for the system, including Features, Bugs and User Stories. Working with the development team and customers to ensure the right work is done.
      2. A prioritised Backlog of work to be done is delivered to the development team at the beginning of each Release and each Sprint. Each Release is sub-divided into Sprints.
      3. The development team works on the items for the release using a formalised process of commitments and testing.
        1. All work in FMI is reviewed internally using a Pull Request system before it can be marked as Done.
        2. Testing is done during this review process using both automated and manual testing processes
      4. At the end of the development, the code is marked as Code Complete and a separate User Acceptance Test (UAT) environment is created.
      5. UAT testing occurs on this environment and Bugs are reported directly against UAT.
      6. Go/No-Go decision on each release, allowing the case where no release is better than a bad release.
      7. Final release to Production, using a gated continuous delivery pipeline so that the necessary steps are performed exactly as they were with UAT.
      8. Release notes are sent to clients highlighting features and bug fixes.

      Quick Facts

      • Development release cycles consist of 2x two-week sprints.
      • Releases are scheduled once per month on the third Thursday of the month.
        • Releases typically contain 2x sprints worth of work.
        • As sprints aren't aligned to months, occasionally there are additional sprints worth of work per release.
        • If additional time is available between code-complete and the release, this is used for additional testing.
      • Key dates
        • To UAT - first day after Code Complete.
        • To Production - third Thursday of the month.
        • Release Notes published - third Friday of the month.
      • Hot Fixes are occasionally scheduled for Priority 1 (production down, no workaround) issues, or for time-sensitive issues (e.g., regulatory dates).
      • The entire automated release process is used whether a scheduled monthly release or a hot-fix.
      • Additional internal approvals are required to ensure fixes are as low-risk as possible and all departments are aware.
      • RCAs and Retrospectives are used to analyse all needs for hot-fixes and improve our internal processes.