Process

In-house Maturity

Software Life Cycle

We use the following lifecycles at BrightSword:

RAD/Spiral Model

Used when requirements are becoming increasingly clear. P rototyping is used as a risk reduction strategy – this detects early design errors and accommodates requirement modifications – and the solution increasingly approaches the desired optimum.

Waterfall Model

Used when requirements are clear and frozen and when the project is a high risk in budget, schedule predictability and control.

Incremental Model

Used when requirements for individual modules of the project can be frozen and the project can be released in logical ‘packets’.

Project Management

We follow a 4-D project management model appropriately applied to the selected software lifecycle approach.

Mutual Accountability

We strongly believe that there should be no surprises in developing and delivering a software solution. One of the critical aspects of client engagement is mutual accountability.

By documenting the requirements and getting customer approval at well-defined stages in the life-cycle, and ensuring that changes in requirement follow a well-defined change-management process, we are able to ensure compliance with a schedule, apply proper development and testing procedures, and ensure that the project costs are kept under control.

By further documenting the constraints to be placed around the solution, and the consequently, its limitations, we can also ensure that the customer is able to properly plan the use of the solution in the foreseeable future.

Global Transparency

All the transparency inherent to our engagement model is facilitated by the infrastructure in place at BrightSword.

Customers can securely view, from any part of the world, the document repository of their project – this ensures that everyone is reading from, and working off, the same document.

Customers can also view their project’s test-results and bug database. This gives them the information they would need to re-prioritize development efforts if necessary. Once in the beta-testing and support phases, they can also raise concerns through the bug-database, and monitor the resolution process online.

Customers can choose to access their source-code repository as the project enters its advanced stages. This is often useful when the customer’s IT team requires information required to properly integrate the solution into an existing environment.

We believe that giving the customer access to our working environment improves the quality of the interaction, and further reinforces the principle of mutual accountability.