5. Realization of the interfacing solution for the DPS and evaluation of working prototype
5.3 Evaluation of the prototype
Using the standard methodologies, a developed DPS needs to be evaluated and each step of the process should be summarized. The W-model, also called the validation and verification model, has been used to evaluate the system and represents the structured test of the system development life cycle (SDLC). Validation of the system or of part of the system means that the final result fulfills the user’s expectations (it answers the question “did we build the right system?”), whereas the verification checks that the result meets requirements, regulations, or existing standards (it answers the question “did we build the system right?”) [34]. The W-model, which is an extension of the widely used V-W-model, shows the parallelism of development and testing activities more clearly. Figure 5.8 illustrates the W-model, and contains two “V”s depicted with blue and red lines representing the SDLC and testing procedures, respectively. The W-model covers system testing to discover and debug system failures [139]. Testing or review of the system starts once the SDLC is initiated. Thus, possible failures at each stage of the SDLC can be detected and analyzed in the earlier stages of development.
Figure 5.8. W-model for the evaluation of the DPS. The blue line represents the SDLC, whereas the red line represents the corresponding testing procedures.
The W-model is a widely used standard system development process and describes all steps, including the system design and coding. As the developed DPS solution applies to the commercial products that have already been developed, tested, and operated within multiple clinical environments, the model has been adapted to the specification of MS-BB. The W-model is used for the following purposes: (1) to determine that final DPS meets the
101
requirements defined at the beginning of the study, (2) to ensure that DPS is correctly set up and the interfacing solution is effectively developed, and (3) to ensure that the developed system can be operated successfully.
The W-model of the DPS is made up of the following phases, which are validated with the corresponding test activity:
1. Requirements definition – The first step of the SDLC is shadowed by a review of the requirements. Once the requirements were collected, the fulfillment of the requirements according to the wishes of the stakeholders was determined. This means that the requirements should be clearly defined so that users (stakeholders) with different backgrounds can understand them. Then, the ambiguous requirements regarding the preparation of glass slides, barcode processing, and viewing interface were considered with the pathologists and IT technicians in detail to avoid any contradictions about these features. The requirements were reviewed during regular meetings with stakeholders. As a result, they were categorized into different groups and prioritized according to need (described in Chapter 3).
2. Requirements specification – This is shadowed by the review/test of the specifications.
Multiple glass slides have been scanned several times using two different scanners to test the functional and non-functional requirements and ensure to that the chosen product is able to fulfill the requirements. During the scanning process, technical details like file size, file formats and structure, image metadata, barcode processing, scanning time, conversion tools, and batch processing functionality were evaluated. Furthermore, the requirements for viewing the digital images were checked in various viewing applications, such as OMERO, Zeiss, PathXL, Imagescope, etc. Interfacing requirements were reviewed with the manufacturers of the system. Test results were evaluated along with the responsible stakeholders and the next steps were determined according to the matches and failures detected during the testing process. Some additional missing features, like the automated entry of metadata, were discovered during testing of the scanning process. Thus, not all but most of the requirements were verified and validated during the requirements engineering phase. Test results are presented in Appendix D.
3. System design – This is the phase in which the architecture, DP workflow, and interfaces were designed. To validate this stage, review/test of the system design were performed, by which the expected failures were detected and discussed with IT
technicians. For example, there was an incompatibility in the web services of the existing systems that required modification on the server side. Furthermore, the structure of image folders in the database for digital images was determined incorrectly and the images could not to be automatically stored. Once the faults were discovered, the corresponding parts of the system design were modified and tested again.
4. Implementation (set up & coding) – This is the base of the W-model where the system design is transformed into the implementation of the system and converted into codes for the web service interface. During this phase, individual components of the DP workflow and web service interface were tested.
5. Build the integrated DPS – This is the phase where the DPS is set up as a complete system and the internal modules have the ability to communicate with each other. In addition, it ensures that the whole system can interact with external systems, such as LIMS. To validate this step, integration and system tests were performed. Using the integration test, components of the DPS, such as scanner, image server, database, and viewer, were combined and tested as a complete system. Using the system test, the complete functionality of the system and communication with the LIMS were tested for different cases.
6. Run system – In this phase, the developed DPS is ready to use in real time within the biobank environment. To detect faults during the running process, user acceptance tests were performed. Five main use case scenarios that described the whole DP workflow from various user perspectives were carried out several times. The user acceptance tests verified that the DPS meets to the requirements and can be used as a working prototype. User acceptance tests also covered load and performance defects.
Several cases were tested to measure the data transfer rate and the speed of image loading on the viewing interface.
7. Operation and maintenance – This is the last step of the W-model. Once the system was set up, the main pathologist began a live operation of the system. Initial training was provided for the pathologist and the assistant who will work with the system. All technical components such as preparation, scanning, storage, viewing, and interpretation of digital glass slides were explained and discussed during the training.
Therefore, 800 glass slides were prepared, digitized, and stored and are available via web viewer directly from the LIMS. Because it was the beginning phase of the operation
103
of the system for the biobank project, each step of the operation was inspected very carefully. There were some failures detected during operation that were related to the connection between the scanner and the server, firewall settings, and other minor incidents. Once the system was launched, the operational concept for the users of the DPS was provided. This concept involves operational workflow including all use cases, personnel, and IT resources used in the process, as well as the estimation of the storage environment for the following years. In addition, for the successful operation of the DPS, it is vital to manage the information system risks and to deal with challenging events.
Therefore, the concept also describes the most likely adverse events that already occurred or that might occur in the future during system operation. The problems and feasible risks were analyzed and effective solutions and controlling mechanisms were identified. Thus, the risks to the system will be mitigated to an acceptable level and the DPS will work effectively. As the operation and maintenance of the system is an ongoing process after the development of the DPS, this step is not explained in detail in this thesis. On the other hand, because the DPS is dedicated for the KKNMS research network, a detailed operational concept is available only for the the KKNMS researchers and is not involved in this thesis. The most important part of the concept, such as use cases, are presented in Appendix B.
All these steps were used in the validation and verification of the working system and led to the successful operation and maintenance of the sustainable system for the coming years.