Software Development Policy and Procedures Version 1. January 2011 Chris Smith Revised DLC timescales 1. January 2011 Lincoln Aniteye Section 3.1. Added Document Review This policy will be reviewed every two years from date of first or last issue.
Software Development Policy and Procedures Version 1. January 2011 Chris Smith Revised DLC timescales 1. January 2011 Lincoln Aniteye Section 3.1. Added Document Review This policy will be reviewed every two years from date of first or last issue.
Software Development Policy and Procedures Version 1. January 2011 Chris Smith Revised DLC timescales 1. January 2011 Lincoln Aniteye Section 3.1. Added Document Review This policy will be reviewed every two years from date of first or last issue.
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
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