Software Development Process

Introduction

At its most elemental, a software development process needs to address four questions: What should we build? In what order should we build it? How will we know it is built? And How do we get better at the process?

Analysis – What should we build?

The need for changes can come from external drivers (customer requests, regulatory changes), from competitor matching, from internal efficiencies or from speculative investigation. All putative changes need to have analysis performed on them to identify if and how they should be undertaken.

Identifying and defining a requirement

Scope

There should be a checklist of questions used to help define the scope of any change. This list would be based on both business domain knowledge and knowledge of the existing system structure. Where an item is considered to be out of scope this still needs to be noted with an appropriate comment. In addition each change request will have unique features not covered by a common checklist that still need to be analysed.

Definition of done

The proofs required to decide that a particular change has been done need to be documented up-front. What tests will be performed and what results would be expected, what new user interface changes would be available and what new or altered process flows would occur.

Interfaces

Where a change interacts with the existing system or with third party data or functionality providers, the rules of the interaction (as interfaces) need to be documented and ownership of these interfaces established.

Greenfield build v. Buy and integrate

In order to guide the decision on what should be created in house we split the entirety of the business process into domains which are then classified as being core to the business, supporting and generic. The supporting and generic domains are usually best served by buying in software or services.

Impact of change

Some changes will alter the way the existing software works – either by changes to the software itself or by changes to the way the software is used subsequent to the change being implemented.

Where a new change makes existing code or processes entirely redundant then it makes sense to remove these prior remnants as they might still have an associated cost if left in place.

Project management – In which order should we build it?

Prioritising change requests and new developments is a collaborative process which requires knowledge of what is on each person’s plate at the moment and the delivery expectations linked to any outstanding work items.

This can be visualised on a Kanban board , or a SCRUM burndown chart. The Kanban board is best suited to resource views and smaller work items whereas a multi-person, multi-month project is more suited to a burndown chart.

Quality Control – How will we know it is built?

Reducing sources of errors

We can reduce the number of run-time errors by adopting some coding standards and by adding tooling to surface any non-compliance with these standards to the developer as they are working.

Unit testing

Unit testing is creating tests for small aspects of the software (units) to be run automatically by a unit testing framework both on the developers machine and also as part of the build process to prevent untested code getting into the production product. Unit tests are best suited to well defined units of operation such as calculations (e.g. fixed income accruals, CUSIP/ISIN validation etc.) but are not as well suited for testing the user interface nor the storage and retrieval of data in the database.

Continuous improvement – How do we get better at the process?

There is no single prescriptive software development process that is guaranteed to work in all circumstances so there is a need to evaluate what we are doing and to see where improvements can be made.

Retrospectives

Periodically or at defined points in the project life cycle performing a retrospective analysis along the lines of What went well, what went wrong, what can we improve?