NHS Manchester Application Development Policy v1.2

8/12/2019 NHS Manchester Application Development Policy v1.2

1/14

Software Development

Policy and Procedures

Version 1.2


2/14

2

Approval and Authorisation

Name Job Title Signature Date

Authored by:-

Chris Smith

Head of IT Services

Approved by:-

Mike Jones

Associate Director of IT

Change History

Version Date Author Reason

1.0 January 2011 Chris Smith Issued version1.1 January 2011 Chris Smith Revised DLC timescales1.2 January 2011 Lincoln Aniteye Section 3.1.7 added

Document Review

This policy will be reviewed every two years from date of first or last issue.

Review Date Reviewed By Comments


3/14

3

CONTENTS

Section Description Page

1 Introduction 4

2 Application Development Methodologies 5

2.1 Rapid Application Development 52.1.1 Requirements Planning 62.1.2 User Design 62.1.3 Construction 62.1.4 Implementation 62.2 Traditional SDLC 72.2.1 Requirement Analysis and Design 72.2.2 Implementation 7

2.2.3 Verification & Testing 82.2.4 Maintenance 8

3 NHS Manchester Approach 93.1 Development Approach 93.1.1 Document User Requirements 93.1.2 Business /System Analysis of User Requirements 93.1.3 Database Design 93.1.4 User Interface and Application Development 93.1.4.1 User Interface Design 103.1.4.2 Coding 103.1.5 User Acceptance Testing 10

3.1.6 Implementation & Roll Out 103.2 Testing and Acceptance 10

4 Governance Arrangements 124.1 Software Reviews 12

Appendix 1 Detailed Timescales 13


4/14


5/14

5

2. Application Development Methodologies

Where ever possible NHSM will use Rapid Application Development (RAD) to develop

applications. Where a more formal approach is required (or desired) NHS will use the

Traditional SDLC methodology to develop and deliver applications.

There are a number of pros and cons to the different types of application development

employed by NHSM.

Rapid Application Development (RAD)

Pros Promotes strong collaborative atmosphere and dynamic gathering ofrequirements. Business owner actively participates in prototyping, writingtest cases and performing user acceptance testing.

Cons Dependency on strong cohesive teams and individual commitment to theproject. Decision making relies on the feature functionality team and acommunal decision-making process with lesser degree of centralized PMand engineering authority

Traditional SDLC (TAD)

Pros Minimizes feature creep by developing in short intervals resulting inminiature software projects and releasing the product in mini-increments.

Cons Short iteration may not add enough functionality, leading to significant delaysin final iterations. Since Agile emphasises real-time communication(preferably face-to-face), utilising it is problematic for large multi-teamdistributed system development. Agile methods produce very little writtendocumentation and require a significant amount of post-projectdocumentation.

2.1 Rapid Application Development

Rapid Application Development (RAD) is a concept that products can be developed faster

and of higher quality through:

Gathering requirements using workshops or focus groups

Prototyping and early, reiterative user testing of designs

The re-use of software components

A rigidly paced schedule that defers design improvements to the next product version

Less formality in reviews and other team communication

NHSM employs a number of tools for RAD software development (Visual Studio, Sofia, uDev

and Radical) including requirements gathering tools, prototyping tools, computer-aided

software engineering tools, language development environments and testing tools.

RAD usually embraces object-oriented programming methodology, which inherently fosters

software re-use. The most popular object-oriented programming languages, C++/#,

VB.NET and Java, are offered by NHSM in visual programming packages often described as

providing rapid application developments.


6/14


7/14

7

The timescales for RAD within NHSM can be found in Appendix1

2.2 Traditional SDLC

The Waterfall model methodology is the traditional SDLC method is often described asTraditional Application Development (TAD). Similar to RAD , TAD has distinct phases

involved in the development lifecycle as shown in Fig 3.

Fig.3 Traditional Application Development Lifecycle

In TAD a feasibility study is used to determine if the project should get the go-ahead. If the

project is to proceed, the feasibility study will produce a project plan and budget estimates

for the future stages of development.

2.2.1 Requirement Analysis and Design

Analysis gathers the requirements for the system. This stage includes a detailed study of the

business needs of the organisation. Options for changing the business process may be

considered. Design focuses on high level design like, what programs are needed and how

are they going to interact, low-level design (how the individual programs are going to work),

interface design (what are the interfaces going to look like) and data design (what data will

be required). During these phases, the software's overall structure is defined. Analysis and

Design are very crucial in the whole development cycle. Any glitch in the design phase could

be very expensive to solve in the later stage of the software development. Much care is

taken during this phase. The logical system of the product is developed in this phase.


8/14

8

2.2.2 Implementation

In this phase the designs are translated into code. Computer programs are written using a

conventional programming language or an application generator. Programming tools like

Compilers, Interpreters, Debuggers are used to generate the code. Different high level

programming languages like C, C++, C# , VB.NET (.NET Framework) Pascal, Java are used

for coding. With respect to the type of application, the right programming language is

chosen.

2.2.3 Verification Testing

In this phase the system is tested. Normally programs are written as a series of individual

modules, these subject to separate and detailed test. The system is then tested as a whole.

The separate modules are brought together and tested as a complete system. The system is

tested to ensure that interfaces between modules work (integration testing), the systemworks on the intended platform and with the expected volume of data (volume testing) and

that the system does what the user requires (acceptance/beta testing).

2.2.4 Maintenance

Inevitably the system will need maintenance. Software will definitely undergo change once it

is delivered to the customer. There are many reasons for the change. Change could happen

because of some unexpected input values into the system. In addition, the changes in the

system could directly affect the software operations. The software should be developed to

accommodate changes that could happen during the post implementation period including

rigorous regression testing.

The timescales for TAD within NHSM can be found in Appendix1


9/14

9

3. NHS Manchester Approach

NHSM takes a staged approach to application development. A series of Joint Application

Development (JAD) meetings are usually held between the Development Team & Users

(Customers) throughout the application development life-cycle. These JAD sessions help

developers to fully understand the applications requirements and iron out anyissues/problems with users before the system is designed, based on the user-provided

information.

It is also impressed on users that cancelled, rescheduled meetings and/or unplanned

changes to the application design may seriously impact and delay the projects delivery date.

3.1 Development Approach

The NHSM development approach can be broken up into the following six stages:

3.1.1 Document User Requirements

This stage deals with identifying current System documentation, including manual systems

(if any) and any specify Business rules. At this stage there will also be an assessment of:

The Impact of Current rules & Issues

Specific Workflow Required

The Data Elements Required

Business Activities/Functions Required

Reports Required

Any potential Issues/Risks will also be documented at this stage as will any training needs.

3.1.2 Business/System Analysis of User Requirements & Documentation

This stage deals with the identification & documentation of data requirements and data

analysis. This stage will also design the Data Model, Identifying, defining and documenting

main business functions/processes/activities and elementary processes that operate upon

the data.

One other key activity for this stage will be to develop test scripts that will be used in the later

stages of the development.

3.1.3 Database Design

This stage deals with the design of the physical database and will include such tasks as:

The setup & test of the development physical database

Population of database with test data

At this point in time Joint Application Development (JAD) meetings will be initiated to ensure

database design is inline with user requirements.

3.1.4 User Interface Application Development & Documentation

This stage is actually broken down into two sub-stages.


10/14

10

3.1.4.1 User Interface Design

Initially the stage focuses on the overall application structure/flow and the design &

documentation of the user interface screens/forms. This will also involve the writing of the

program logic specifications that implement the business rules as depicted in the user

requirements.

3.1.4.2 Coding

This sub-stage deals with the coding, validation and unit testing of each form/screen to

perform the specified application function. This will also involve the coding of data

processing & Batch Trigger modules.

Other activities will include:

Coding search & Report Modules

Testing end-to-end flow of the system & resolve any functional or flow problems.

3.1.5 User Acceptance Testing

This stage ensures users have adequate storage capacity and deals with the setup of the

physical user database in the staging environment (see also 3.2) to be populated with live

data. The application is installed in the user environment and the system fully tested with any

issues being fully documented for urgent resolution.

3.1.6 Implementation & Roll Out

At this stage the application & database in configured in the production (live) environment.

Users can then populate the database with live data with final assurance checks beingundertaken. Implement backup requirements will then be fully implemented before final user

sign-off.

3.1.7 Post Implementation Review

After implementation a JAD session will be held to undertake a post implementation review.

This will typically be four weeks from the date of implementation (Go-Live). This will allow for

the review of any user/technical issues to be resolved.

3.2 Testing and Acceptance

NHSM operates a full test environment for the proofing of applications before delivering toUser Acceptance Testing (UAT). This environment typically consists of the following:

1 staging SQL server (V2005)

2 test SQL servers (1x2005 and 1 x 2008)

1 test IIS server 2003 (ie6, ie7 and ie8)

All changes are trialled within the test environment for a number of weeks iteratively beforeusers acceptance testing.

User acceptance testing is then performed on the staging SQL server and test IIS before achange control package is completed for approval to deploy live.


11/14

11

All applications deemed to be fit for deployment live are raised as a change control package

and presented to the Change Control Board which meets fortnightly on the 1stand 3rd

Monday of every month.


12/14


13/14

13

Appendix 1 Detailed Timescales

/

(

)

()

()

1

2 2

,

( ), ,

& ,

, ,

/, ,

/, .

.

2 /

&

3 8

&

, , ,

, &

, /

.

3

1 3 , &

&


14/14

Documents

NHS Manchester Application Development Policy v1.2