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?

Identifying and defining a requirement

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.