dataesr/scientific-paragraphs-categorization huggingface dataset:
Thereafter, the model is used to generate the application. Imogene is developed using the Eclipse framework, the Eclipse Modeling Framework including Ecore meta model (to describe model) and the plugins furnished by Eclipse for code generation from the model. 9 www. dia-installer. de One-to-one, one-to-many, many-to-one and one-tomany relations between classes The source code corresponds to the relation between classes as prescribed by the Object relational mapping 10   Table  2 : Some mapping elements between PIM, PSM and source code As the Eclipse EMF, the Imogene platform provides graphical tools to model business entities and generation tools to generate a set of applications based on the model. The modeling phase consists of defining the forms (with their fields) which will be used to collect/manage data.
V RESULTS Globally, this research allowed us to demonstrate that the combination of Scrum and MDA allows effective development of epidemiological surveillance software when the MDA tool is mature enough to generate the entire source code. In effect, Scrum practices allow users to participate in the entire process of modeling and generation, which make the solution acceptable by end users. The details of the research results are given in the following subsections: Section 5. 1 presents the results of the survey beside the health workers, Section 5. 2 presents the results obtained during the implementation of the approach, and Section 5. 3 presents the results of the evaluation of the approach by people who participated to this research. The results obtained, the finding and the lessons learned allowed us to provide an answer to the research question in Section 5.
• On the question: "What is your knowledge on the use of IT tools?" Six health personnel affirm that they have basic knowledge on IT tools like Word and Excel. One of the six affirms that she already used an electronic health record. All the people from the Regional and the NTCP affirm that they have good knowledge on the use of Word and Excel, but they prefer to hire IT experts to build the Excel files they need for their statistics. • On the question "What do you expect from epidemiological surveillance software?" Only one health worker estimated that he did not see what would be the benefit of the electronic system to his work. From the others, if we want to improve their work with an electronic tool, this tool must: (1) Solve the previous problems and be close as possible to the current tools (data collection sheets and reports) to facilitate the easy use; (2) Data management such as patient registration and following, sharing patient information to entitled users, automatic generation of patient cards, easy identification of lost sigh patients, easy identification of all health centers where TB patients are treated; (3) Allow the production and distribution of basic statistics automatically.
Pre-Intervention The aim of the Pre-Intervention was to produce a preliminary list of interventions for the NTCP to assess, enhance and approve. Then, the following activities were planned: Establishment of a working group, identification of the problem faced by the current system, stakeholders survey to gain more insights in the problem, reflection on the solution, software specification and analysis. Specification, analysis, product backlog definition and validation were implemented by following the Scrum iteration practice. Then, three iterations of one week each were conducted. The  work was divided into tasks (for instance, writing the specifications of data collection, identification of actors) and the Scrum meetings make it easy to define common goals and commit to achieving the goal with the product owner.
Then, the first version of the specification went through an approval process with the working group team and was validated. Scrum iterations were very useful during the specifications and analysis. In effect, in order to understand very well what was really needed, interviews were made, transcribed by the re-searchers and validated during the Scrum meetings with the working group. This was a cycle composed by the software specification (or update), analysis (or update), validation of specification and analysis (or update) and product backlog definition (or update). The positive effect that we observed was the openness that the Scrum meetings give to us in order to communicate with the working group. The involvement of the NTCP staff was very useful to avoid poorly written requirements specifications.
The Sprint Review Meetings permitted us to adopt the software specification, analysis and design with the whole staff at the NTCP. We designated the user management module and the data management module as our initial list of interventions which we presented to the NTCP for discussion and deliberation. Lesson learned. The first lesson we learned was that epidemiological surveillance systems requirements cannot be fixed and change generally. Then, we should be careful of the approach and tools to use for the development. This lesson led to a deep reflection by the software team on the choice of the development approach to use. Given the limits of the code-centric approach presented in the introduction, insight was then to model and generate the software instead of coding it. Then, the combination of Scrum that were already chosen with MDA were adopted.
Then, a closed collaboration between the University of Yaounde I and MEDES allowed us to build good skills in the modeling and the generation of data collection applications with Imogene. A deep analysis of Imogene by the researchers shows that it permits to model and generate only two modules of the TB surveillance software: the data management module and the user management module. 3. User Interfaces (UI) Design: during this intervention, a deep discussion with the working group and the constraints of the Imogene platform on the design of UI allowed us to decide how the elements on the UI will be organized to resemble the manual management tools. 4. Platform Independent Model design: this intervention consisted of determining the entities, their properties, their relationships. Once these elements were determined, we set-up a UML class diagram using Dia.
5. Additional information such as field description, field name in French and English were added to the PSM using the Imogene editor. The screenshot of the epicam model obtained during this intervention is given in appendix C. This model was used to generate the first prototype of the application. This first prototype consisted of: • An administration application: Used to manage health workers information, their roles, and their access rights on data; • A Web application: Containing the main user interfaces needed. It is used for the registration of patients and their follow-up; • Offline application: The offline application has the same functionalities as the Web application, but is used in an asynchronous mode. When Internet connection is not available, the system uses the local database as storage system and the local database is synchronized with the server when the Internet is available; • Synchronization application: Used to synchronize the client with the server (updating local or remote database).
Next iterations. After the development of the data collection module, five iterations were conducted. These iterations permitted us to integrate all the information that was not present in the PIM and correct some typology errors. This involved the design, the development, and the testing. The design consisted of the updating of the PSM, the development consisted of the generation of a new version of the platform. Lessons learned many lessons were learned during this Sprint: • We should be careful when using a tool for the complete generation of the software: we remarked that it is difficult to find a tool that fits the requirements of a specific context. • Domain experts are not generally available: NTCP staff were involved in the modeling and the generation of the software. However, we noted during the Scrum meetings that they were not generally attending.
It should be noted that most health workers in the NTCP are nurses, physicians, lab technicians, epidemiologists. They have full time employment and their commitment to the project was during their spare time. This constrains the implementation of the interventions. • Modeling can be a difficult task for domain experts: among the domain experts that were involved in the modeling, only 2/11 (18%) installed the modeling environment and 3/11 (27%) estimated that installing and using the modeling environment is out of their competencies. After a deep reflection during ad hoc meetings between the researchers, the MEDES engineer, the NTCP staff and CPC expert it was decided to develop and update the Imogene platform with the user management module that fit to the NTCP needs. This new intervention was put as a main priority.
Given that medical data is very sensitive, it was decided to prioritize the development of this module. Then, the second Sprint was dedicated to the development of the generator of user management modules that fulfill epidemiological user management. Only the developers (supervised by the MEDES engineers) and the product owner were involved in the development of this module. The main role of the product owner was to verify that the user management module allowed us to generate the user management system of TB surveillance at the NTCP. It was noted during the specifications and analysis that users have different roles. In some hospitals where there is not enough staff, a user may be the person who consults the patient and gives its medication. With the user management module, when the administrator creates a user, she/he allows her/him to read/modify the data.
When a user login, she/he can access only the data she/he is entitled to. The appendix E presents a screenshot of the UML model and the user interface allowing the creation of a role and the attribution of rights to users. We used the same tools used to develop Imogene to develop this module: the programming language was Java, the Integrated Development Environment was Eclipse Kepler for Java EE, the Google Web Toolkit to develop User Interface, the Spring 3 framework, the Spring security framework, code management with Maven and git, the modeling environment was Eclipse Modeling Framework and the code generation environment was composed of oAW (involved Xtext, Xpand, MWE components). Before the development of this module, the developers were trained on these technologies. After the development, this module was integrated in the source code generator of Imogene.
Once the generator of the user management module was developed and integrated into Imogene, the epicam model (appendix C) was updated manually and used to generate a new version of the prototype. It should be noted that this version of the prototype allowed us to manage users and TB data. Tests and experimentation. The second Sprint permitted us to obtain a first working version of the system that the end users in the field can use in a real environment. After the tests and the Scrum review meeting with the working group, we decided to validate the developed platform in the field. Then, we deployed it in six hospitals in Douala and Yaounde (which are the largest cities in Cameroon). Eight health personnel were involved in this validation which lasted one month. The goal were to evaluate the perceived usefulness and the perceived ease of use of the end users: • Perceived usefulness: All the users found the tool useful for data management.
They found Scrum advantageous in the development of their system. Sprint 4: Developing the reporting and mapping modules. During the fourth Sprint, the reporting and the mapping modules were developed (by the developers supervised by MEDES engineers) in two months, organized in 5 Sprints. The reporting module was developed using Business Intelligence and Reporting Tool (BIRT  16  ). The mapping module was developed using Open Street Map (OSM  17  ). During the Scrum meetings with the working group, the users validated these modules. Then, they were tested, validated at the NTCP and integrated in the code generator. A new version of the platform was validated by the users in the field.
Not complete The installation difficulties discourage the health worker to continue the experience. Table  7 : List of interventions implemented during the sixth Sprint Sprint 5: Developing the SMS module. The fifth Sprint consisted of the development of the SMS module in one month with 3 Sprints. To this end, we used Spring Rest API. Actually, to send SMS using the platform, we decided to use a service provided by an SMS provider. The SMS module was tested, validated at the NTCP and integrated in the code generator. The new version of the epidemiological surveillance software generator containing a new version of user management module, reporting module, mapping module and SMS module were named EPICAM 18 and hosted on github. We found the development of additional modules arduous than the development of code-centric application.
Thus, after the development of the platform, the goal of the current Sprint was to prepare the health workers to take charge of the updating. As presented before, only three NTCP staff followed the development to the end, only two were involved in the modeling task and one of them moved to another job. The main goal of this Sprint was to allow the health personnel to update the system using Scrum and MDA. Then it involved the simulation of the following interventions: building the product backlog and organization into Sprints, validation of the product backlog by the working group, organizing and conducting Scrum meetings (daily and review), modeling the PIM with Dia, installing the MDA tool, manual transformation of the PIM into PSM, generation of the new version of the software, deployment on a local machine and validation by the NTCP.
These interventions were planned to be executed by the health personnel, supervised by the researchers. The summary of their implementations is presented by the table  7. The team conducted two-weeks of iterations, trial, errors and learning. During the first week, the modeling environment was installed and the product backlog was defined. This product backlog contained the following interventions: adding new forms with new fields for data collection, constructing the PIM, transforming the PIM into PSM. Since the EPICAM platform (used for the modeling and the generation) is based on the Eclipse platform, we observed that installing 18 https://github. com/UMMISCO/EPICAM these tools by non-informatics experts is not an easy task. This did non encourage the latter to continue with the experience and he stopped after the second week.
Perceived ease of Use To measure perceived ease of use, we considered the developers evaluation and the stakeholders evaluation. We measure the degree to which these participants believe that using the combination of Scrum and MDA is free of effort. As developers, globally, we can say that the application of Scrum and MDA for the development of epidemiological surveillance software is easy to use. In effect, once the features were validated and integrated in a Sprint Backlog, it generally took us a maximum of one week to update the model and generate a new version of the software. The integration of Scrum in the development was very easy. In effect, once the different roles were introduced, the NTCP designed the product owner. The researchers explained his tasks and he conducted them very well without any difficulties.
Perceived Usefulness As we have done above, in the following paragraphs, we present the developers and noninformatic experts views of perceived usefulness. Developers found the combination of Scrum and MDA very useful in our work of software development. In effect, combined with MDA, the Scrum Process permitted us to gradually build models and generate the executable source code which are updated with the gradual expansion of the epidemiological surveillance. This has a significant impact on qualities such as: programming productivity and satisfaction, development cost-effectiveness, timelines and customer satisfaction. • Programming productivity and satisfaction: we found the approach useful because it allowed us to develop/update as fast as possible the software. The use of models allowed us to reduce complexity in the development and the Scrum practices allowed us to better organize the work between us and the communication with the customers.
In effect, to develop the system, all the tasks to perform are prioritized and consigned in the product backlog. Depending on the size of the product backlog, one or many Sprints can be put in place. The Scrum meetings and the face-to-face communications were very useful to clear up any misunderstanding and facilitate the discussion and the decisions during the development. During the Sprints, the developers tasks involved the modeling and generation of the software. The use of Scrum iterations allowed us to repeat during any Sprint until all the tasks planned are completed. For instance, once the first model was built and the software generated, during the users evaluation, modifications to apply were identified and the cycle resumed. The repetition of iterations helped us to learn from the errors and reinforce what went well, achieving continuous improvement.
The use of Scrum practices such as Product Backlog and Scrum meetings allowed us to facilitate the development of the solution. The modification of the model and generation of the new software have made it more valuable. In addition, the approach reduced costs by saving the time that may be used to debug a system because of the problem of software regression. It should be noted that the EPICAM platform can be reused for the development of several epidemiological surveillance software. We concluded that the combination of Scrum and MDA has a positive effect on development cost effectiveness. On the other hand, the development of additional modules for the generation tool was time consuming and has had a negative effect on the cost-effectiveness. • Timelines: the Scrum planning meetings, Scrum daily meetings facilitated the organization and prioritization of tasks.
The Product Backlog allowed us to define the different tasks and prioritize them so as to deliver the first working version as soon as possible. The one week duration of iterations were useful to ensure that the development is advancing in a good way. The development of this first working version was greatly facilitated by the use of models. In effect, once the requirement and the analysis were defined, the transformation into product backlog with prioritized and estimated tasks allowed us to have insights on the main features of the software and develop the first working version of the platform as soon as possible. In conclusion, the approach presented in this research has a positive impact in the timelines of the development. • Customer satisfaction: Scrum practices and MDA approach have had positive effects in customer satisfaction.
Different Scrum Meetings with the NTCP staff and the end users allowed us to build a product which was as close to the users as possible. At the end, we observed that the software was accepted by the end user. Some of them found the user interface close to the tools they were using in their work. For the development phase, during the Scrum meetings, when the customer or the end users proposed to add or modify something, these tasks were added in the product backlog and the modifications were planned. These modifications and the testing took one Sprint of less than one week because in most time, it was question to modify the models and regenerate the updated solution. The stakeholders were very satisfied because during the Scrum weekly meetings, they found their remarks integrated in the solution.
Sprint reviews were very positive, because we could also get a view of what other types of requirements the stakeholders had. As prescribed by Scrum, the goal of producing a working version of the system for iteration reviews was a good way of noticing and communicating integration problems that would otherwise be communicated only after the overall implementation. This practice has a positive effect because the end users and the customer no longer wait until the end of the project before they have the results. The fact that the customer commenced to use the software was useful to the development. The sprint review meeting shows the customer the new features and changes implemented in the Sprint. The Scrum team inspected the work done by the end users. Then, we found the approach very useful to reduce time-to-market.
The end users started using the tool and got accustomed to it as soon as possible. This helps to realize if changes are necessary. In fact, sooner the changes are detected, the less its impact and cost. After the success of the deployment in 25 pilot health centers, the NTCP extended the deployment in twenty new health centers. In conclusion, the use of Scrum and MDA allows us to deliver a regularly working version of the software. This provided positive impacts in customer satisfaction. Even if the approach has been found useful, we also found that the immaturity of the MDA tool can have negative effects in the development. It can slow down the programmer productivity and satisfaction, augment the development cost because new generators must be developed, and be costly in time. Non-informatic experts also found the combination of Scrum and MDA useful.
They were impressed by the rapidity with which new versions of the software were proposed every time where the changes were necessary. However, they found that they don't have good knowledge in the use of models and modeling tools to use the approach to update the system. The interview of the user and a deep observation on the use gave more insights on the non adoption of the method. The main bottleneck of the adoption was the installation of the tool and the UI. Developing tools based on Eclipse and Eclipse plugins such as EMF, etc. have had a negative effect on the acceptance of the approach by the stakeholders.
Conclusion The lessons learned in this research and the main finding allow us to provide a scientific answer to the research question, independently to TB surveillance. This is required because the pilot project presented in Section II aims to study the epidemiological surveillance of TB in order to propose solutions that can be generalized to any other cases. We found that to mesh Scrum and MDA for the development and maintenance of epidemiological surveillance software, the following points should be considered: • MDA framework (such as EPICAM for epidemiological surveillance) should be mature enough to generate the entire source code. In effect, the development of additional modules was not an easy task on the one hand because of the reverse engineering of the Imogene platform and on the other hand, because it is not easy to build a tool that should generate source code for all the surveillance systems.
Globally, we found that when the MDA tool is mature enough to generate the entire source code, the combination of Scrum and MDA allows effective development of epidemiological surveillance software. In effect, combining Scrum and MDA with an appropriate MDA tool has a positive impact on programmer productivity and satisfaction, development cost-effectiveness, timelines, and customer satisfaction. Scrum practices and models developed showed to be efficient practices to validate the evolution of the development and, therefore, facilitates more productive software development because customers are integrated and misunderstanding problems are solved as soon as possible. This was particularly observed during the validation of the Platform Independent Model by the National Tuberculosis Control Program staff and the validation of the software by end users.