A guide to the considerations of a Software Product Design and Development project.

General

This general guide helps businesses to promote consistency, sustainability and simplified growth. When considering the procurement of software and solutions, the following considerations ought to be applied.

Businesses, however, will need to decide which considerations to implement based on their own needs and requirements. This may be informed by the existing software and solutions. Software Product Design and Development comprises three main activities:

• Design (see 1.1);

• Development (see 1.2);

• Testing (not included in this general guide).

1.1 Design

The design stage is key to the delivery of a software product that matches your requirements. These requirements may be derived from a simple, internal specification, in which case a packaged software product may be appropriate, or from very specific, complex requirements in which case a bespoke development may be more suitable. The steps involved in designing a software product are typically seen as the business generation stages. They consist of the following.

1.1.1 Technical Analysis Internal

Your Supplier should undertake a review of the technical requirements they need to complete the project, taking into account any risks they may feel are associated with the project. This will help them ensure that it is viable for them to complete the application and that they understand what is required technically. They will look at the proposed development and take into account both appropriate human and material resources to ensure that the project can be successfully completed on time and to budget.

1.1.2 Technical Analysis External (bespoke development)

Undertake a review of your technical requirements in taking on the project. Make sure you have the required operational and support capabilities needed to ensure the correct use and support of the application once installed. Review the technical infrastructure to ensure it is capable of running the application to be written and ensure that you have sufficient operational capability to run and maintain the application correctly. Draw up some recommendations with your Supplier aimed at ensuring the satisfactory delivery of the agreed project objectives.

1.1.3 Requirements Gathering and Specification (Customer) (bespoke development)

Ask your Supplier to produce a specification that can be signed by both parties as a true and accurate representation of the requirements. This needs to be an explicit statement of requirements in a format that you can understand which clearly sets out the scope and proposed workings of the software. A Supplier should prepare documentation for you which clearly sets out:

• the scope;

• censorship;

• deliverables;

• development method;

• testing plan;

• budget;

• overall cost;

• change management;

• reviews;

• any additional or known future requirements;

• security;

• timescale.

1.1.4 Development Approach (bespoke development)

Make sure the proposed solution is fit for your business’ purpose and works within the bounds of your business’ future IT aspirations. Assess your needs against the software platform(s) proposed. Take into account system expansion, budget, functionality, scalability and reliability as well as results from customer analysis.

1.1.5 Risk Management Business (bespoke development)

Understand the business and technology risks associated with the project and discuss potential risks with your Supplier. Assess the risk to your business and to your Supplier if more than one developer is involved in the project and identify what controls need to be in place to manage the project effectively across all parties involved. Make sure you clearly understand and be prepared to accept the risk to your own business in undertaking the project. Look carefully at the scope of the proposed development schedule and assess the likelihood that you will change the scope of the project. Assess the risks associated with you not fully understanding what you are going to get as part of the project. Aim to minimise mismatches in expectation due to you or your Supplier not fully understanding each other’s business. Take into account any potential risk to your business should the current proposal overrun in time and cost.

1.1.6 Intellectual Property Rights (IPR ) (bespoke development)

Ask your Supplier for a clear statement on IPR and the supply of source code. Understand exactly what is being bought and what potential risks there are to your business. Where bespoke applications or system changes are being written, make sure your Supplier provides you with the necessary code or provides a clear Escrow agreement. Ensure that they clearly state any timescales involved in the release of code and any exit policy for the purchase of source code should it become necessary.

1.2 Development

Software product development can range from being very complex where only a competent programmer can develop an application, through to simple developments which may be achievable by a business person supported with appropriate training. Not only does the development environment including language need to be carefully considered but also the development method.

1.2.1 Documentation and Records

Your Supplier should have enough relevant software documentation to allow them to support your business. Typical documentation could include process flowcharts, specification details, customer objectives, agreed critical success factors, issues, changes and current software releases.

1.2.2 Development Stages

Your Supplier should identify and use a standard set of development components. This will allow them to achieve consistency of development across all projects allowing maintenance and future development to be completed more efficiently. Ensure they break down the project into its component parts, for example:

• security;

• encryption;

• user interfaces;

• database selection;

• APIs.

1.2.3 Development Method

An appropriate method of development for the software product should be identified. Appropriate methods of development include:

• Waterfall;

• Fountain;

• Spiral;

• Agile;

• Cleanroom;

• RUP;

• XP;

• RAD.

1.2.4 Software Design

Ensure your Supplier can describe the features and operations of the software product in detail. Get them to demonstrate that the project concept is proven and sufficient detail is supplied to individual developers to allow coding to be completed on time and to budget. Ask them to develop screen layouts, operating rules and process diagrams. Ensure that they produce pseudocode and any other documentation deemed necessary for the project.

1.2.5 Traceability

Your Supplier should produce documentation showing how the requirements analysis relates to the software design.

1.2.6 Software Interface Design

Make sure your Supplier develops routines for interfacing with other components such as:

• Other software applications / components;

• Hardware;

• Operating Systems;

• Cross platform.

1.2.7 Human Interface Design

Make sure your Supplier develops methods for interfacing with Customers taking into account any user security constraints such as:

• Screen layouts;

• Handheld devices;

• Audio;

• Peripherals such as printers.

1.2.8 Critical Functions

Ensure your Supplier identifies components that are safety, security or business critical. Analyse the requirements specification and document any components that are critical to:

• a User of the software package;

• the safety of the User;

• the integrity and security of the data to be used and recorded by the software product.

1.2.9 Prototype Development

If appropriate, your Supplier may develop a software prototype to trial. Make sure that your expectation is in line with the product before too much investment has been made in the development. Ask your Supplier to ensure that coding allows other programmers to understand what has been written so that programs are not dependent on individuals.

1.2.10 Data Migration Planning (bespoke development)

Work with your supplier to assess the need to migrate data from any existing application(s) and the viability of automating the data migration. Take into account the views of the Users and length of time when assessing whether to re-key or migrate data electronically.

1.2.11 Version Control

It is important that software revisions can be accurately tracked according to market release. A system should be in place to prevent incorrect software versions being released. Ask your Supplier to provide appropriate evidence that all projects are managed and tracked, clearly identifying changes and their impact. Make sure that through project management, these are discussed with you during the development. Your Supplier may use a system to identify software version levels. They should show you how they identify superseded software and maintain an accurate library of development history. Ensure they track all patches and record coding changes both within the software and as part of external documentation.

1.2.12 Software Design Sign Off

Your Supplier should give you the opportunity to sign off the prototype before development of the remainder of the software product.

1.2.13 Data Migration (Testing)

It is good practice to test the transfer of data into the new software product. This ensures your data can be quickly and easily transferred into the new software product minimising the need to re-key data. Your Supplier should write automated routines for importing data from your existing software products to remove the need for re-keying and minimise the chances of data transfer errors and to speed up implementation. Make sure your Supplier develops these alongside the development of the software product. Ensure your Supplier adheres to the requirements of the DPA (1998) in respect of the illegal use of live Customer information for testing purposes.

1.2.14 Quality

Ask your Supplier to show you that there is a robust testing mechanism in place. This ensures that your business is not adversely affected by any newly installed software. Agree a complete set of business objectives, functional and non-functional specifications, which are used to manage the progress of the project and your expectation. Ensure your Supplier keeps records of all testing carried out and the results of the testing.

1.2.15 Verification

Ensure your software is developed in a consistent and controlled manner. Ask your Supplier to analyse the method of development against those set out as part of the project initiation activities.

1.2.16 Internal Validation

Your Supplier should establish a set of validation criteria that ensures the objectives of the project are tested. This ensures that the software product works according to the design specification in all target operating environments. Your Supplier may use different staff internally to test the software as well as any documentation to be supplied. Ensure your Supplier takes into account all requirements of the DPA (1998) in using live Customer data for testing purposes.

1.2.17 External Review

Ensure that you have the opportunity to try out the software product prior to installation, in conjunction with the documentation to be supplied with the product. This will allow any further
development to be undertaken without disruption to your business. Ensure your Supplier takes into account all requirements of the DPA (1998) in using live Customer data for testing purposes.

1.2.18 Regression Testing

Ensure your Supplier carries out regression testing on any software components modified after initial testing. Ensure that previously tested software components are re-checked and any new errors fixed. Re-test any software components that have been modified. This will ensure that no errors are introduced into the software where software may have been working correctly previously.

1.2.19 Portability Testing

Your Supplier should carry out testing of software components on all target hardware and operating system platforms. This should be done in line with the environments in which the software will operate.

1.2.20 Data Migration (Transfer)

Ensure your Supplier transfers data into the new software product in accordance with the data migration checks previously and successfully completed. Your Supplier must adhere to the requirements of the DPA (1998) in respect of the illegal use of live Customer information for testing purposes.

1.2.21 Software Delivery Medium

Agree with your Supplier the most appropriate medium and method of receiving the software product, for example, CD or download, post or internet. Agree the number of copies to be supplied.

1.2.22 Software Product Documentation

Where you have chosen to have documentation, ensure that it is provided in a format that you understand. Documentation may either be supplied in written format, as part of ‘Help’ features within the software product or provided online and held centrally by the developer.

1.2.23 Sourcing Decisions

Your Supplier should consider the most appropriate sources for the skills and competencies needed to deliver the project professionally.

1.2.24 Re-use

Where appropriate your Supplier may use standard templates for coding and software product development that can be applied to all projects. Whilst all software designs and developments will be different, there are often sections of code that can be used across many applications. Using the same code helps to minimise the risk to projects as they are already proven.