System Development
Written by MTB | 
| 
| 
Overview
System Development Process
The key processes have been summarised in Application Lifecycle Management (ALM).
As previously mentioned Meridian uses its archetype model based IDME or Clinixian wherever possible to create new applications.
The following is a brief overview of each of the processes within the ALM. Two versions of this are given one for the conventional software development using .NET and SQL Server and Visual Studio and the other using Meridian's archetype model tools IDME or Clinixian.
Developing Conventional Solutions
Developing solutions using conventional technology
Initial Scoping and Planning
This is to ensure that we understand the scope of the proposed solution and that the customer understands what is in and what is not included. This is normally used as the basis of any contract. In some cases the scope has to be refined as part of the project and needs to be done before any development is undertaken. The preferred approach is to do this prior to darfting the contract. Once the project scope has been agreed then this forms the basis for producing an implementation plan and costing.
Requirements Specification
In many cases the customer has already produced a requirements specification. If not this needs to be done as part of the project. Requirements specification defines what business requirements the customer wants the system to support. Part of this is to identify the Use Cases the solution will include and will often involve examination of "what is" looking at workflows and existing processes. Producing the requirements specification sometimes involves changes to the scope of the project which means a variation has to be agreed if it means more or less effort.
System Architecture Design
Examines technical options and defines the structure, distribution and integration of softwre and hardware components both with each other and with the customer's infrastructure.
Detail Design
This involves specifying the details of the user interfaces, the database schema and reports and the navigation between the screens as well as any rules that need to be coded. This part of the project can be phased if there is more than one module or the work can be partitioned in some logical way. Part of this design also involves defining test cases.
By using prototyping approach this detailed design will result in a solution that will be a much better fit to actual customer requirements. We use protyping tools that not only show the user what the screens look like but can also emulate the flow from one screen to another.
Build and Unit Test
This activity is to build the system using the detailed design information produced in Detail Design. This includes unit testing which is testing carried out by the programmer to ensure that the software meets a set of test criteria they have defined based on the use cases in the requirements analysis and the test criteria in the detailed design. This build will include messaging and integration with relevant components of the customer's infrastructure.
System's Integration
This activity determines the data that is required to be incorporated in HL7 or XML messages and the various message types relevant to this solution. It involves configuration of the HL7 Server for the particular application.
Integration Testing
Once a module is finished its integration with the customers infrastructure needs to be tested to make sure the end to end processes work as intended. In a health setting this often involves the messaging between core hospital or regional systems such as the patient administration system and
Installation and Commissioning
Once the system has been fully tested the next stage Installation into the training and production environments. This is followed by user acceptance testing based on scripted test cases.
Handover
Once the system has been accepted it can start to be used in production. This involves running end user training courses run by the trainers who were trained during the installation and commissioning stage. There is normally agreement in the contract that there is a period of post implementation support to iron out any defects not identified during testing and ensure that the customer understands how to use the system.
Developing IDME based Solutions
Developing solutions using IDME or Clinixian
Initial Scoping and Planning
This is to ensure that we understand the scope of the proposed solution and that the customer understands what is in and what is not included. This is normally used as the basis of any contract. In some cases the scope has to be refined as part of the project and needs to be done before any development is undertaken. The preferred approach is to do this prior to darfting the contract. Once the project scope has been agreed then this forms the basis for producing an implementation plan and costing.
Requirements Specification
In many cases the customer has already produced a requirements specification. If not this needs to be done as part of the project. Requirements specification defines what business requirements the customer wants the system to support. Part of this is to identify the Use Cases the solution will include and will often involve examination of "what is" looking at workflows and existing processes. Producing the requirements specification sometimes involves changes to the scope of the project which means a variation has to be agreed if it means more or less effort.
System Architecture Design
Examines technical options and defines the structure, distribution and integration of softwre and hardware components both with each other and with the customer's infrastructure. The use of IDME or Clinixian is identified in this activity.
Detail Design (IDME Methodology)
This is where there is most difference to a conventional development approach.
The key steps in this activity is to:
- Attend modelling training
- Identify the data to be recorded and validation rules
- Define the navigation of the data.
- Define the orgnisation of the data into groups and sub groups and collections of data items (threads)
- Attend rules training
- Define the key business rules
- Attend report training
- Define the standard reports and on screen reports.
- Define the interfaces with other systems
- Define data migration
Build and Unit Test
What happens here is that we train an assigned expert user to be the solution administrator once the application has been built. We help this person to do the modelling as defined above. A key benefit of IDME and Clinixian is in being able to run the application progressivley during the build so as to check how the model and rules will work as they are developed.
The customer task involves:
- Building the model
- Writing rules
- Developing reports
- Testing the interfaces work.
System's Integration
This activity determines the data that is required to be incorporated in HL7 or XML messages and the various message types relevant to this solution. It involves configuration of the HL7 Server for the particular application
Integration Testing
Once a module is finished its integration with the customers infrastructure needs to be tested to make sure the end to end processes work as intended. In a health setting this often involves the messaging between core hospital or regional systems such as the patient administration system and laboratory systems.
Installation and Commissioning
Once the system has been fully tested the next stage Installation into the training and production environments. This is followed by user acceptance testing based on scripted test cases.
Handover
Once the system has been accepted it can start to be used in production. This involves running end user training courses run by the trainers who were trained during the installation and commissioning stage. There is normally agreement in the contract that there is a period of post implementation support to iron out any defects not identified during testing and ensure that the customer understands how to use the system.