Software Development

Policy and Procedures

Version 1.2
Page | 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 version
1.1 January 2011 Chris Smith Revised DLC timescales
1.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











Page | 3

CONTENTS


Section Description

Page
1 Introduction 4

2 Application Development Methodologies 5

2.1 Rapid Application Development 5
2.1.1 Requirements Planning 6
2.1.2 User Design 6
2.1.3 Construction 6
2.1.4 Implementation 6
2.2 Traditional SDLC 7
2.2.1 Requirement Analysis and Design 7
2.2.2 Implementation 7
2.2.3 Verification & Testing 8
2.2.4 Maintenance 8

3 NHS Manchester Approach 9
3.1 Development Approach 9
3.1.1 Document User Requirements 9
3.1.2 Business /System Analysis of User Requirements 9
3.1.3 Database Design 9
3.1.4 User Interface and Application Development 9
3.1.4.1 User Interface Design 10
3.1.4.2 Coding 10
3.1.5 User Acceptance Testing 10
3.1.6 Implementation & Roll Out 10
3.2 Testing and Acceptance 10

4 Governance Arrangements 12
4.1 Software Reviews 12

Appendix 1 Detailed Timescales 13








Page | 4

1. Introduction
The Systems Development Life Cycle (SDLC) is a conceptual model used in project
management that describes the stages involved in an information system development
project from an initial feasibility study through maintenance of a completed application
request.
Various SDLC methodologies have been developed to guide the processes involved
including the waterfall model (the Traditional SDLC method), rapid application development
(RAD), joint application development (JAD), the fountain model and the spiral model.
Sometimes, several models can also be combined to form a hybrid methodology.
Documentation is crucial regardless of the type of model chosen or devised for any
application, and is usually done in parallel with the development process. Some methods
work better for specific types of projects, but in the final analysis, the most important factor
for the success of a project is often how closely a particular plan is followed.

Fig.1 Traditional SDLC versus Rapid Application Development
Generally NHS Manchester (NHSM) employs two methodologies for application
development, Traditional SDLC and RAD. The differences to these approached can be seen
in Fig.1.


Page | 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 of
requirements. Business owner actively participates in prototyping, writing
test cases and performing user acceptance testing.
Cons Dependency on strong cohesive teams and individual commitment to the
project. Decision making relies on the feature functionality team and a
communal decision-making process with lesser degree of centralized PM
and engineering authority
Traditional SDLC (TAD)

Pros Minimizes feature creep by developing in short intervals resulting in
miniature software projects and releasing the product in mini-increments.
Cons Short iteration may not add enough functionality, leading to significant delays
in final iterations. Since Agile emphasises real-time communication
(preferably face-to-face), utilising it is problematic for large multi-team
distributed system development. Agile methods produce very little written
documentation and require a significant amount of post-project
documentation.

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++/C
#
,
VB.NET and Java, are offered by NHSM in visual programming packages often described as
providing rapid application developments.
Page | 6


Fig.2 Rapid Application Development Lifecycle
The structure of the RAD lifecycle, shown in Fig 2, is thus designed to ensure that
developers build the systems that the users really need. This lifecycle, through the following
four phases, includes all of the activities and tasks required to scope and define business
requirements and design, develop, and implement the application system that supports
those requirements.

2.1.1 Requirements Planning

Also known as the Concept Definition phase, this phase defines the business functions and
data subject areas that the system will support and determines the systems scope.

2.1.2 User Design

Also known as the Functional Design phase, this phase uses workshops to model the
systems data and processes and to build a working prototype of critical system components.

2.1.3 Construction

Also known as the Development phase, this phase completes the construction of the
physical application system, builds the conversion system, and develops user aids and
implementation work plans.

2.1.4 Implementation

Also known as the Deployment phase, this stage includes final user testing and training,
data conversion, and the implementation of the application system.
Page | 7


The timescales for RAD within NHSM can be found in Appendix 1

2.2 Traditional SDLC
The Waterfall model methodology is the traditional SDLC method is often described as
Traditional 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.
Page | 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 system
works 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 Appendix 1











Page | 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 any
issues/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.
Page | 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 being
undertaken. 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 to
User 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 before
users acceptance testing.
User acceptance testing is then performed on the staging SQL server and test IIS before a
change control package is completed for approval to deploy live.
Page | 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 1
st
and 3
rd

Monday of every month.

Page | 12

4. Governance Arrangements
NHSM employs rigours governance arrangements with regards to the monitoring testing and
deployment of new applications and system enhancements, including (but not limited to) the
following:
Software Review Board
Change Control Board
Application Development Master Schedule
User Acceptance Testing
4.1 Software Reviews
The NHSM Software Review Board (SRB) meets monthly and comprises of the following
members:
Application Development Manager
Head of IT Services
Head of Programmes
Associate Director for IM&T
All changes/enhancements and new projects are present to the SRB for consideration,
resourcing, scheduling and ultimately approval for development.
The SRB also reviews all WIP developments and tracks progress against the Master
Schedule (as shown in Fig. 4). Where appropriate monthly highlight reports are provided to
individual project managers (within the programme team) informing of any potential
risks/delays etc.

Fig.4 Sample Master Schedule
The Software Development Team meets every Monday to review progress against
timescales and address any internal issues.
Visual Source Safe is used for definitive version control, Acronis recovery is used for
systems backup & recovery; and all servers are backed up and included in the overall
disaster recovery plans.
Page | 13

Appendix 1 Detailed Timescales

Stage
R
A
D

P
h
a
s
e

T
A
D

P
h
a
s
e

Activity/Tasks Maximum Duration
(Varies depending on
complexity of the
application)
RAD
(weeks)
TSDLC
(Weeks)
1
R
e
q
u
i
r
e
m
e
n
t
s

P
l
a
n
n
i
n
g

R
e
q
u
i
r
e
m
e
n
t

A
n
a
l
y
s
i
s

a
n
d

D
e
s
i
g
n

Document User Requirements
Tasks cover the following areas:-




2






2
Tasks cover the following areas:-
Current System documentation, including
manual systems (if any), Specify Business rules,
Impact of Current rules & Issues, Specify
Required Workflow, Data Elements, Business
Activities/Functions, Required Reports,
Potential Issues/Risks, Training needs. Develop
test scripts.
2 Business/System Analysis of User Requirements
& Documentation




3






8
Tasks cover the following areas:-
Identification & documentation of data
requirements, data analysis, Design Data Model,
Identify, define & Document main business
functions, processes/activities and elementary
processes that operate on the data.
3
U
s
e
r

D
e
s
i
g
n

Database Design

1


3



Tasks cover the following areas:-
Design physical database, Setup & test
Development physical database & Populate with
test data

Page | 14

4
C
o
n
s
t
r
u
c
t
i
o
n

User Interface Application Development &
Documentation


3


9
Tasks cover the following areas:-
Specify Application Logic & Flow
Design overall application structure & flow,
Design & document user interface
screens/forms, Write program logic
specifications
Coding & Testing User interface Forms/Screens
& application Flow
Code, validate & test each form/screen to
perform the specified application function, Code
data processing & Batch Trigger modules, Code
search & Report Modules, Test end-to-end flow
of the system & resolve any functional or flow
problems.




5




21
5
I
m
p
l
e
m
e
n
t
a
t
i
o
n

V
e
r
i
f
i
c
a
t
i
o
n

a
n
d


T
e
s
t
i
n
g

User Acceptance Testing


1



2
Tasks cover the following areas:-
Ensure User has adequate storage capacity,
Setup physical user database to be populated by
the Users, Install application in User
environment, User tests system & documents
problems/issues, if any for resolution.
6
I
m
p
l
e
m
e
n
t
a
t
i
o
n

Implementation & Roll Out



1




4
Tasks cover the following areas:-
Capacity Requirements, Setup database in the
Production environment,
Install application to the Production
environment, Users Populate database with Live
Data. Implement Backup requirements. User
sign-off.
Total Estimated Development Time (weeks) 16 48