Consultancy for Enhancement of Existing Mobile Application for the Management of Working Days from Public Works Programme for LODA MEIS

Expression of interest (EoI)

Consultancy for Enhancement of existing mobile application for the management of working days from public works programme for LODA MEIS

Reference Number: 83467171

Date of Publication: 21.06.2024

0. Context

The Deutsche Gesellschaft für Internationale Zusammenarbeit (GIZ) GmbH is a federally owned international cooperation enterprise for sustainable development with worldwide operations. The GIZ Office in Kigali covers GIZ’s portfolio in Rwanda and Burundi. GIZ Rwanda/Burundi implements projects on behalf of the German Federal Ministry for Economic Cooperation and Development, the European Union and other commissioning authorities in the following priority areas: Sustainable Economic Development, Good Governance, Climate, Energy and Sustainable Urban Development, Digitalization and Digital Economy, Mineral Governance, Peace and Security in the Great Lakes Region.

1.1. Brief information on the project

The Social Protection policy in Rwanda highlights the continued process of establishing a comprehensive, life-cycle-based social protection system that ensures a minimum level of income security to all Rwandans at critical points in their lives and protects them against a wide range of socio-economic risks. It is built on four pillars of (i) social security, (ii) social care services, (iii) short-term social assistance and (iv) livelihood and employment support and aims to not only secure the eradication of extreme poverty but also promote human capital development and social transformation as the foundation for long-term prosperity and support the delivery of equitable and inclusive development.

GIZ’s global programme ‘Global Alliances for Social Protection’ (GASP) facilitates cross-border knowledge exchange, learning, and innovation about adaptive social protection (ASP) with the aim of strengthening social protection systems that are adaptive to shocks (e. g. large-scale shocks such as climate shocks) and crises. The programme collaborates with a series of national, multilateral, and international partners and implements a variety of exchange formats, with a view to scaling up innovations and strengthening social protection systems in partner countries.

GASP has country packages in Rwanda and Uzbekistan to support the implementation of social protection strategies in partner countries. This takes place in the form of a complementary technical assistance to build and implement social protection systems that are adaptive and responsive to shocks in the long-term. The intervention in countries builds on a strategic partnership with the World Bank and other partners.

The country component Rwanda focuses on strengthening dynamic, inclusive, and responsive aspects of the Rwandan social protection system. Amongst others it works on strengthening the digital elements of the social protection system, such as the dynamic social registry and the social protection Management Information System (MEIS) to increase the efficiency of social protection service delivery.

It is within this framework that GIZ, in cooperation with the Local Administrative Entities Agency (LODA), is looking for a software company to support the LODA in the further development of mobile application to be integrated with the LODA MEIS. Over the past two years, LODA has made significant progress in the development of MEIS and roll-out of a digital payment feature in social protection. The required functionalities via mobile application are about the management of the publics works attendance and some refinements of the underlying reporting module to streamline programme administration.

1.2. Tasks to be performed by the contractor and Technology stack

The MEIS platform was developed in 2014. Since then, many new features have been added to the platform. MEIS is a tailor-made solution, developed using the following tools: Java, Jasper reports, dynamic web pages created by JSF components, and XHTML. The most relevant backend technologies are PostgreSQL as a database with the Post-GIS extension to store geospatial data and a JBoss application server as a runtime environment for the Java EE web application. The implementation of the communication interface uses REST Web Service between MEIS and the mobile application (mMEIS).

MEIS already has a public works module and a survey mobile app (mMeis) developed using the Flutter framework, which needs to be extended. The mobile MEIS app (mMeis) will be extended to use for the management of daily attendance for public works beneficiaries. The product will not be developed from scratch; additional functionality will be developed, while others that already exist will be enhanced. The final product will be integrated with MEIS for data synchronization and metadata retrieval. The architecture of MEIS will also be improved to accommodate the changes along with an improved reporting feature.

1.2.1. Enhancement of the existing mMeis mobile app

The existing mMeis mobile app must be enhanced to provide attendance management functionality needed for classic public works component.

The enhanced business process flow is as follows:

• Field Registration (Enrollment).

Step 1: The Team supervisor will retrieve the classic public works project into the MEIS mobile App together with the approved eligible beneficiaries for the project and the beneficiary’s key information / personal data, such as Names, Date of Birth, National ID, Unique program ID number, Telephone number.

Step 2: If the data does not match with the beneficiary’s information on field, update the Data in MEIS and go back to the Step 1

• Field data capture for working days.

Step 3: The Mobile App will create an input record for attendance record (attendance sheet that would require daily updates).

Step 4: The Team supervisor will check the work completed and select the current date of attendance in the MEIS Mobile App. The time and GPS coordinates of the project will be automatically recorded without user input.

• Classic Payroll Creation

Step 5: The Mobile App will update the MEIS classic public works payroll creation module by the end of the workday.

Step 6: The uploaded timesheet will be reviewed. commented for each person and approved in bulk or rejected for modification at the end of each work period by the social protection sector officer.

Step 7: At the end of the billable period, the MEIS payroll creation module will close all records that have been submitted from the MEIS mobile App and format the records into an electronic payroll that is submitted to District for approval and payment processing.

Step 8: End.

1.2.2. The functional requirements are as follows:

1: cPW Attendance Sheet Menu

A menu labeled “cPW Attendance Sheet” shall be added within the mobile app.

Features: Users should be able to navigate to this menu to access and manage attendance-related functionalities for cPW projects.

The menu should provide options for recording, reviewing, and updating attendance data.

2:Retrieve Approved Eligible List

The mobile app shall have the capability to retrieve the approved eligible list for cPW projects.

Features:

• The retrieved list should include household code, first name, last name, and ID, photo of eligible beneficiaries associated with cPW sector projects recorded in MEIS.
• The list shall be dynamically updated based on the real information available on site and modifications should be approved within MEIS.

3: Import Project Functionality of cPW and ePW

The mobile app shall feature functionality to import cPW and ePW projects.

Features:

• Users with appropriate permissions should be able to import new projects into the mobile app.
• Project import shall be based on the sector, cell and village location assigned to the user, ensuring relevance to their work area.

4: A separate menu for the ePW project will be added to the mobile app

Features:

• Users with appropriate permissions should be able to import new projects into the mobile app.
• On the ePW project, the supervisor shall submit feedback in the mobile app for those who did not attend, and they should not be included in the payroll.

The supervisor should be able to upload a picture of the completed work as a verification of work done that then triggers the payment for the beneficiaries inscribed in that project.

5: Monitoring page for ePW Beneficiaries’ Attendance in MEIS

On the ePW module, the feedback shall be visualized sector by sector in MEIS.

6: Photo capture on site

The mobile application shall provide the functionality for users to capture on-site photos using the device’s camera and subsequently upload them to the MEIS/ cPW & ePW attendance page where they are associated with an individual and their attendance record.

The app should support common image file formats (e.g., JPEG, PNG) to ensure compatibility with the MEIS.

• The app should provide a mechanism to store photos temporarily in case of no internet connectivity and automatically upload them when a connection is re-established.
• Users should have the ability to attach relevant metadata (e.g., date, time, location) to the uploaded photo.

7: GIS coordinate of the Project

The mobile application shall incorporate automatic mechanisms to collect and record GIS coordinates (latitude and longitude) for the project.

Features:

The application shall leverage the device’s GPS functionality to automatically capture and record the current location’s coordinates for a project.

8: Log sheets Generation

Log sheets should be generated in accordance with the configured date range

9: Search functionality

Search functionality by names or ID should be added on mobile app in the log sheets while recording the working days

10: Attended date

Select the attended date ( should be the current date )

11: Calendar Integration

The MEIS shall integrate a calendar function that displays the days of the selected month, highlighting non-working days such as weekends and holidays, and it shall be synchronized with the mobile app

12: Recording Previous Worked Days Due to Non-TechnicalIssues

The Mobile app shall provide functionality to address scenarios where worked days were not recorded on the current date due to non-technical issues.

13: Backdating Permission

• Additional permission shall be granted to users to backdate in the attendance and record the previous worked days.
• Users with the appropriate role or permissions shall be able to access and modify attended dates for a specified period.
• The MEIS shall log and track changes made during backdating for auditing purposes

14:Household attendance sheets approval

• The MEIS shall facilitate the approval of attendance within MEIS, allowing for either a bulk approval or an individual approval process, following the submission of attendance sheets .

15:Prevent changes

No further changes can be made on the log sheet after submission and approval and the system automatically generates payment list after approving final log sheets.

16:Modification and Cancellation of Approved Log Sheets

The system shall provide functionality for users to modify approved log sheets upon request, get them approved, or initiate cancellations, allowing for corrections or adjustments after the initial approval.

17: Project and Eligible list data

A new REST service (in JSON format) should be developed to facilitate the transmission of project data from the server to the mobile app.

Webservice to exchange data between MEIS and the mobile app.

A REST service must be developed to exchange data between the MEIS and the mobile app.

 The functional requirements are:

18: Data Exchange

A new REST service dedicated to data exchange (in JSON format ) from the mobile application to MEIS should be developed. Data validation (Data handling shall be performed during the transfer process to ensure accuracy and integrity .

19: Update of data

A RESTful API shall be developed to support the retrieval of updated data, with a focus on adding missing households.

The API shall follow REST principles for efficient and secure data retrieval

20: Data preparation for upload

Conversion of database objects to JSON for upload. The upload function is to be implemented and the user needs an option to trigger the upload.

21: Secure Data Transmission

Access to the exchange service shall be restricted to authenticated and authorized users.

22: Error Handling and Reporting

Error-handling mechanisms shall be implemented to manage errors that may occur during data exchange.

 Clear and informative error messages shall be provided to the mobile application for prompt issue resolution

23: Reporting

The following enhancements are required to the reporting capabilities of MEIS:

24: Attendance Summary Report Generation

The MEIS shall be capable of generating an attendance summary report in the required formats, including PDF and Excel. The report shall provide attendance data at different hierarchical levels such as Province, District, Sector, Cells, and Village

The report shall include metrics indicating the number of households attended versus the number of eligible households at each hierarchical level, based on the specified date range

25: Data Entry Status

A summary report displaying the submitted and not submitted working days.

26: Dashboard to track payment and payroll details preparation

A dashboard to track payment and payroll details in the MEIS. The dashboard will focus on giving us insights into specific areas, such as the number of workers (CPW beneficiaries) during different period, how workers are distributed by gender and age groups in different locations and distinguishing between timesheets that supervisors have submitted to the MEIS.

1.2.3. Additional cross-cutting requirements

Technical wise related tasks: the contractor is responsible for providing the following services:

• Create a design and user interface (UI) for the application: Consider the user experience (UX) and ensure the app is intuitive and easy to navigate.
• Database design: Plan and design the database structure that will store the relevant information, such as user profiles, work schedules, tasks, and any other necessary data.
• Front-end development: Develop the user interface and front-end components of the mobile application.
• Back-end development: Build the back-end objects that will support the application’s functionality. This includes developing server-side logic, APIs, and integrating with any external systems or services required.
• Data storage and synchronization(integration): Implement mechanisms to store and synchronize data between the mobile app and the server/database [MEIS]. This ensures that user data is securely stored and can be accessed across devices or platforms if needed.
• User engagement and feedback: when developing a Minimum Viable Product (MVP); engage with a representative group of users to gather requirements to ensure that the initial release meets the essential needs and expectations of the target audience and elicit feedback. Summarize the feedback received and agree with LODA on which to implement in the final product delivered.
• Test cases: Testing and quality assurance: Conduct thorough testing to identify and fix any bugs or issues in the application. Perform unit testing, integration testing, and user acceptance testing to ensure the app functions correctly and meets the defined requirements. Consider usability testing to gather feedback from potential users.
• Deployment and Release: Follow the guidelines and requirements of each platform to ensure smooth and entire functionality of the developed platform.

1.2.4. Detailed expected activities from the contractor.

Some features or functionalities of the mobile application for managing worked days from public works.

a. Mobile application module for managing the workers’ attendance days from public works.

• Design, develop and document system functionalities/IT architecture for a mobile application that will be integrated with LODA MEIS
• Develop a mobile application for managing of the workers’ attendance days from public works with the latest technologies, efficient source codes (clean, well designed, testable, and well documented) with the following main functionalities:

1. User-friendly interface: Design the application with a clean and intuitive interface that allows users to easily input the worked days in a month.
2. Calendar integration: Incorporate a calendar function that displays the days of the selected month, highlighting non-working days such as weekends and holidays.
3. Customizable holidays: Provide an option for users to add their own holidays or non-working days (referring to public holidays allowed by Government of Rwanda)
4. Calculation logic: Implement the necessary algorithms to calculate the number of working days based on the provided inputs and the predefined non-working days.
5. Notifications: Enable users to set reminders or notifications for upcoming holidays or non-working days, ensuring they are aware of any changes in the regular working schedule.
6. Offline functionality: Allow the application to function offline, so users can access it even without an internet connection so later the data will be uploaded into the central system (LODA MEIS) once the internet is available.
7. Multiple language support: shifting from one language to another (Kinyarwanda and English) to allow multiple users from different language capacities.
8. History and tracking: Provide a history or tracking feature that allows users to view previously calculated working days for reference or future planning.
9. Share and export: Enable users to share or export the calculated working days for a given month, either through email, messaging apps, or other means.
10. Reminders and alerts: Offer the option to set reminders for important dates or deadlines related to work or projects.
11. Direct upload into the central system (LODA MEIS) for further validation of worked days at advanced levels and finally for completing payment processes within 10 days as agreed in the public works payment procedures.

• Develop unit and system testing cases to find out system issues and debug / track / resolve by analysing the sources of issues and the impact on hardware, network or service operations and quality., and report test
• Work closely with LODA Team and other stakeholders for MEIS for capturing all expected functionalities from the mobile application.
• Ensure security policy appliance in software development
• Working closely and regularly with LODA Business Analyst to align the development processes towards the expected product.
• Analyse and develop statutory and analytical reports for various system modules.
• Creating wireframes and system prototypes to decide on layout and workflows.
• Implementing required system Integrations for interoperability
• Perform required systems upgrades in case required for accommodating the new mobile application.
• Ensuring source code ownership and secured source code repository of the sector’s software projects
• Ensuring proper version control and releases management to LODA
• Performing quality assurance and testing (create test plans and perform tests)
• Ensuring software performance optimization
• Ensuring the sector’s data integrity and security
• Deploying developed solutions to production environment
• Participate in the training of the system users.

b. Capacity development and knowledge transfer measures to LODA which will include coaching and mentoring of team members, including the integration of local stakeholders in project activities. At the end of the assignment LODA officers should be able to do all required maintenance and adjustments in the app.

c. Conducting relevant workshops and meetings. Meetings with relevant stakeholders should be conducted to ensure that all stakeholders understand and align on the project goals, scope and objectives, identify and mitigate risks, for showcasing the state/progress of the developed product, and to review the project timelines and milestones.

Further workshops should be conducted to ensure knowledge transfer, specifically two workshops:

• Technical knowledge transfer to LODA
• Training system users and software testing

1.2.5. Data protection and information security

The provisions on data protection and information security of the current version of GIZ’s General Terms and Conditions of Contract (section 1.10 Data protection) apply.

Data protection in general

The performance of the contract may be associated with the processing of personal data by the contractor, who would alone define the nature of such data and how such processing would be carried out. In such cases, the contractor shall act as an independent DATA CONTROLLER and must alone comply with ALL applicable data protection obligations, including regional and local laws. The contractor must process personal data only when a given goal cannot be reasonably attained without such data. The data protection principles such as lawfulness, data minimization, accuracy, purpose limitation, storage limitation, transparency, integrity and confidentiality, and accountability, as well as the numerous rights of the data subject must be paid due attention. The EUs General Data Protection Regulation´s (GDPR)’s data transfer rules must be considered whenever personal data leaves the EU for a third country. The GIZ is NOT in any way responsible for such processing.

If the contractor is not subject to the GDPR and the applicable laws do not contain any explanation on the data protection principles and rights mentioned here, the definitions and meanings provided by the GDPR (Regulation (EU) 2016/679) should be considered.

Data protection in case of development of a data processing system

When developing data processing systems on behalf of the GIZ, the contractor must comply with the provisions of the GDPR and some local laws (which must be verified, especially in non-EU countries) regulating such systems, as they (the systems) are meant for the processing of personal data. In this regard, compliance with the requirements of data protection by design and by default becomes imperative, when creating Apps, software, websites, monitoring cameras, and any other tool that is used to process personal data.

At the centre of such considerations for privacy by design and by default are data protection principles and the rights of the data subjects. The most relevant data protection principles here are: lawfulness, transparency, data minimization, storage limitation, accuracy, and most especially, integrity and confidentiality. The principle of integrity and confidentiality, for instance, demands the application of privacy enhancing technologies, such as access control (through strong passwords), authentication, encryption, pseudonymization etc., to protect against data breaches. The practical implication of these principles is well elaborated in Annex 1. (“THE DEVELOPMENT OF A DATA PROCESSING SYSTEM UNDER THE GDPR”).

Parallel to the above-mentioned principles are the numerous rights accorded to the data subject, which cannot be given less weight. As a matter of fact, the GDPR requires the controller to facilitate the exercise of the data subject’s rights. The system must foresee and provide the possibility for the exercise of the following rights: the rights to rectification; erasure; and data portability; the right to withdraw consent; rights to restrict or object to processing (with these last two requiring the temporal deactivation of the profile without deleting his personal data). See Annex 1.

The technology used to ensure compliance with these provisions must reflect the state of art and must be enough to mitigate any threat to the rights and freedoms of the data subject, such as losing control over his personal data. It shall be tested periodically reviewed and updated.

Information security

The data center(s) of the contractor or its subcontractor(s) should be certified according to ISO27001 and thus meet all the requirements of ISO standards.

The contractor’s processes for developing and operating websites or learning platforms or web-based tools should be ISO 27001 certified or should follow the best practices of ISO 27001 and of further security recommendations like Open Worldwide Application Security Project.

This means that the following points must be considered by the contractor and if they are not within the contractor’s responsibility or scope of work, they must at least be discussed with the partner’s project team in order to close any existing security gaps.

The Contractor must inform the Client immediately and in an appropriate form about security incidents that may affect the Client. If the Customer has appointed an IT security officer or another person to receive such information, the information must be sent directly to this person. At the end of the contract, the Contractor shall immediately and without being requested to do so return all documents, auxiliary means, materials or objects received from the Client which were not permanently left to the Contractor for the purpose of executing the contract as intended. This shall also apply to all copies. Furthermore, all performance results in any form shall be handed over to the Client; insofar as the granting of exclusive rights has been agreed, this shall apply including the copies made.

The Customer shall be permitted to demand secure deletion (i.e. non-constructible) or destruction in whole or in part instead of surrender. This shall be proven to the Client upon request and at its discretion by means of a corresponding declaration or otherwise.

Separate environments for development, test and production must be provided.

A firewall must be installed upstream of the server (e.g., authorized IP addresses/GEO blocking or address ranges for logging on to the system can be entered here or also excluded for this purpose). Up-to-date anti-virus software must be used on the server and configured accordingly for automatic updates.

Network communication between the components of the application should be encrypted. Hard-coded keys (symmetric/asymmetric) should not be included in the application. If this is unavoidable, the handling of the key must be described. The information security risks related to the storage of the key must be evaluated. The transmission of authentication information (especially passwords) must be encrypted. The storage and transmission of sensitive and/or personal data must comply with current encryption standards.

When implementing API interfaces, it is essential to harden them against malicious code injection (SQL injection, etc.) via the URL.

There must be a documented authorization concept for each application (e.g. in the operating manual).

A password policy must be implemented, which should look like this:

• minimum number of digits e.g. 12
• latin capital letters (A-Z)
• lower case Latin letters (a-z)
• basic digits (0-9)
• non-alphanumeric characters (like !, $, #, -, &)
• your password must not contain the whole or parts of your login name!
• after e. g. 5 wrong entries the account should be locked for 3 minutes
• password age e. g. 90 days
• password history, at least 5 different passwords in before a previously used password is accepted again, new passwords that differ only by consecutive numbers should not be accepted.

Passwords must not be stored in plain text. Passwords may only be stored as hash values. The hash algorithm must conform to the current recommendations of the BSI (technical guidelines). Hard-coded passwords must not be included in the application. The transmission of authentication information (especially passwords) must be encrypted.

2-factor authentication should be implemented; Google Authenticator is not to be used for this. 2FA is to be possible via multiple channels (app, SMS or e-mail).

Session cookies used for logins must be deleted after logging out from the client.

A system log is to be implemented in which at least logins and logouts of all users and actions such as updates, backups, uploads and downloads, changes to account data and authorizations, as well as all security-relevant actions and events are to be logged and documented. The inclusion of further log data is still to be discussed in detail with the project. The system log is to be documented in the operating manual.

In order to minimize operating errors (human errors), the ergonomics of the application should be designed safely according to the need for protection.

1.3. Payment milestones and acceptance criteria:

Milestones/partial works	Deadline/place/person responsible	Criteria for acceptance
1.3.1 Technical report on agreed implementation plan and user acceptance testing approach.	15th July 2024 Contractor and UI/UX and Business Analyst	Report summitted and accepted
1.3.2 Minimum viable prototype (MVP) of mobile app ready for initial feedback	15st August 2024. Contractor and UI/UX and Business Analyst	Version of mobile app with enough features to satisfy users and gather feedback from them and reflecting insights on how the mobile app is respoding to the requirements and its expectations. Report summarising feedback from users consulted on the MVP version of the mobile app is accepted
1.3.3 Expertise Advisors Final version of mobile app ready for user acceptance testing	15st September 2024. Contractor and UI/UX and Business Analyst	The final version mobile app should go through a comprehensive development and testing process, including the following checklist: a. Development Checklist:  Feature Completeness: Verify that all planned features have been implemented and are functional. User Interface (UI) and User Experience (UX): Ensure that the UI is intuitive and follows design guidelines. Check for a consistent and positive user experience throughout the app. Performance: Test the mobile app for responsiveness and smooth performance on various devices. Address any lag, crashes, or performance issues. Compatibility: Ensure the mobile app works seamlessly across different devices, screen sizes, and orientations. Security: Implement secure coding practices. Encrypt sensitive data and ensure secure communication. Localization: If applicable, verify that the mobile app supports multiple languages. b. Testing Checklist: Unit Testing: Confirm that unit tests for individual components have been conducted. Integration Testing: Test the interactions between different components to ensure seamless integration. MEIS offers a REST API for data exchange. This API allows authorized users to access and retrieve data from the system using HTTP requests. The API supports various data formats, including XML and JSON. To integrate your mobile application with MEIS, the contractor will need to identify the specific endpoints and parameters for the API. Regression Testing: Verify that new changes haven’t introduced issues in existing functionalities. User Authentication and Authorization: Confirm that user authentication and authorization mechanisms are secure and functional. Data Accuracy: Ensure that data displayed in the app is accurate and complete. Error Handling: Test error scenarios to ensure the app provides meaningful error messages and gracefully handles unexpected situations. Network Conditions: Test the app under various network conditions, including low connectivity and offline modes. c. User Acceptance Testing (UAT) Preparation: Documentation: Provide comprehensive documentation for users participating in UAT. UAT Environment Setup: Set up a dedicated environment for UAT, mirroring the production environment as closely as possible. Test Data: Prepare realistic test data to be used during UAT. Communication: Communicate the UAT plan, goals, and expectations to the testing team or end-users. d. UAT Execution: User Training: provide training sessions for users participating in UAT. Feedback Collection: Establish a structured process for collecting user feedback during UAT. Issue Tracking: Use a robust issue tracking system to record and prioritize identified issues. Iterative Testing: Allow for multiple rounds of UAT to address issues and incorporate user feedback. e. Post-UAT: Bug Fixes: Address and fix all reported issues promptly. Performance Optimization: Fine-tune performance based on user feedback and usage patterns. Final Confirmation: Conduct a final round of testing to ensure all reported issues have been resolved. Deployment Planning: Plan the deployment of the final version to production, considering downtimes and user impact. Communication: Communicate the release schedule and any potential impact to the end-users of existing platform (MEIS).
1.3.4 User acceptance testing completed and accepted by both parties.	15th December 2024. Contractor and UI/UX and Business Analyst	Final user acceptance testing report is accepted and signed by client

Period of assignment: from contract start until December 2024

2. Concept

2.1. Technical-methodological concept

The technical-methodological concept outlines the development methodology and the software development life cycle (SDLC) that will be used in the development of mobile app. It includes design, development, testing, and deployment phases, as well as the tools and platforms that will be used to develop the mobile application. The technical-methodological concept serves as a blueprint that guides the development team throughout the project’s lifecycle, from planning and design to development and deployment, ensuring that the final mobile application meets the requirements and expectations of the users.

The technical proposal should include detailed information about:

1. The proposed solution, including the technical approach and the technology stack (1.1)
2. Project management and development methodology: Design of project management process and description of methodolgy for development/implementation with regard to work packages and milestones (1.2)
3. Operational plan/personnel assignment plan: Operational plan that includes a personnel assignment plan for all of the specialist staff, depiction of assignment periods (time period and expert days) and necessary work steps. (1.3)
4. Description of processes of testing and documenting the IT solution, and deployment: Description of process for testing and documenting the IT solution and IT security and documentation standards used. (1.4)
5. Description on planned knowledge management and transfer of knowledge to LODA ensuring Government ownership over the developed solution (2.1)
6. Description of approach to collaborate with LODA and GIZ (2.2)

2.2. Project management of the contractor

The contractor will work closely with LODA staff under the clear terms and proper reporting channels, as well as with GIZ. The regular meetings will be planned for monitoring and exchange of progress of work. The development partners with LODA will be invited for certain meetings to provide feedback and recommendations. LODA staff and designated development partners will participate in user acceptance testing processes (strategy for establishing cooperation with relevant actors)

3. Personnel concept

The overall needed human effort for developing and testing the expected mobile application is estimated to be three (3) experts as a whole development team. It is assumed that at minimum a team with the following IT expertise will be needed to finalise the development-related tasks:

1	Team leader and System architect
2	Mobile developer
3	UI/UX Designer and Business Analyst

3.1. Team Leader and System Architect (one expert)

Tasks of the team leader and system architect

Project management

• Provide leadership and guidance to the development team.
• Foster a positive and collaborative team culture.
• Manage team dynamics, motivation, and conflict resolution.
• Work with project managers to define project scope, goals, and deliverables.
• Develop project plans, schedules, and timelines.
• Facilitate communication within the team and with stakeholders.
• Serve as a liaison between the development team and upper management.
• Communicate project progress, issues, and risks.
• Allocate resources effectively based on project requirements and team members’ skills.
• Monitor and manage workloads to ensure tasks are distributed appropriately.
• Identify project risks and develop mitigation strategies.
• Anticipate and address potential issues that may impact project timelines or quality.
• Ensure adherence to coding standards and best practices.
• Mentor team members and facilitate their professional development.
• Identify training needs and opportunities for skill enhancement.
• Encourage a culture of continuous learning within the team.

System architecture

• Develop the overall system architecture based on project requirements.
• Define the structure and organization of the system components.
• Select appropriate technologies including hardware, software, and networking technologies.
• Optimize the system by addressing scalability, performance, reliability, availability, and define and privacy security considerations.
• Integrate different hardware and software systems into a cohesive whole, ensuring that they work together seamlessly.
• Stay informed about emerging technologies and industry best practices.
• Collaborate with stakeholders to gather and analyse system requirements.
• Translate requirements into a technical design that meets business objectives.
• Create prototypes or proof-of-concept implementations to validate design decisions.
• Identify and address technical challenges early in the development process.
• Plan and design how different system components will integrate.
• Define data flow, APIs, and communication protocols between subsystems.
• Create and maintain technical documentation for the system architecture.
• Ensure that documentation is accessible and understandable to the development team.
• Work closely with business analyst, mobile developer, and other stakeholders to align technical solutions with business goals.
• Communicate technical decisions and constraints to non-technical stakeholders.

Qualifications of the team leader and system architect

• Education/training (3.1.1): university degree (‘Diplom’/Master) in systems and software development, IT system development, computer science or similar areas (10 points)
• Language (3.1.2): proficient in English language both spoken and written (C1) (10 points)
• General professional experience (3.1.3):
  • 8 years of professional experience in the systems and software development (5 points)
  • which includes 5 years of experience in web enabled MIS development of comparable projects, preferably in the social protection sector (5 points).
• Specific professional experience (3.1.4):
  • 4 years in designing the data systems structure and organization of the system components, select appropriate technologies including hardware, software, and networking technologies, optimize the system by addressing scalability, performance, reliability, availability, define and privacy security considerations. Integrate different hardware and software systems into a cohesive whole data system, ensuring that they work together seamlessly. (4 points)
  • 4 year’s experience in Web enabled MIS, Mobile application development with proven experience in design of web-based information systems using Java EE standards like JSF (Java Server Faces), JPA (Java Persistence API) and JAXB (Java API for XML Bindings) and the build tool Maven, Prime-Faces component library and AJAX web applications, PostgreSQL database, Boss and clustering implementation, Jasper-Reports (6 points)
• Leadership/management experience (3.1.5): 4 years of management/leadership experience as project team leader or manager in an IT company (10 points)
• Regional or international experience (3.1.6): 5 years of experience in digitalisation projects in Africa (10 points)
• Development cooperation (DC) experience (3.1.7): 3 years of experience in DC projects (10 points)

3.2. Mobile application developer (one expert)

Tasks of the mobile application developer

• Developing software applications that run on mobile devices, including smartphones and tablets.
• Testing the written code/modules and debug them to ensure that the application works as intended.
• Design user interfaces that are optimized for mobile devices, ensuring that they are easy to use and visually appealing.
• Integrate the mobile application with back-end systems, such as databases or web services and and external APIs to ensure that they have access to the data and functionality expected.
• Ensure the mobile app is compatible with different mobile devices, operating systems, and screen sizes.
• Consider platform-specific guidelines and design principles.
• Develop features and functionalities based on the project requirements.
• Implement best practices for security, performance, and maintainability.
• Write code specific to the target platform (Android) and use cross-platform frameworks (Flutter) to write code that can run on multiple platforms.
• Ensure a balance between code reusability and platform-specific optimizations.
• Implement data synchronization and communication between the mobile app and servers.
• Conduct unit testing to ensure individual components work as expected.
• Perform integration testing to validate interactions between different parts of the application.
• Conduct device-specific testing to ensure compatibility across various devices.
• Identify and fix bugs and issues in the code by using debugging tools and logs to troubleshoot problems.
• Optimize the performance of the mobile application for speed and responsiveness.
• Implement security best practices to protect user data and ensure data integrity by securing communication channels and storage of sensitive information.
• Use version control systems (e.g., Git) to manage and track changes in the codebase.
• Collaborate with the project team members using version control workflows.
• Document code, APIs, and system architecture for future reference.
• Create user documentation or developer guides as needed.
• Prepare the mobile application for deployment to the application hosting site (National data center)
• Follow submission guidelines and requirements for each platform.
• Address and fix issues reported by users after the application is released.
• Release updates and improvements based on user feedback and changing requirements.

Qualifications of the Mobile application developer

• Education/training (3.2.1): university degree ( ‘Diplom’/bachelor’s degree) in computer science, software engineering, information technology, or a related field. (10 points)
• Language (3.2.2): proficient in English language both spoken and written (C1) (10 points)
• General professional experience (3.2.3):
  • 5 years of professional experience in designing data systems in social protection or other development projects (4 points);
  • 3 years of experience in web enabled MIS and Mobile application development of comparable projects (6 points).
• Specific professional experience (3.2.4):
  • 5 years of experience in developing software applications that run on mobile devices, including smartphones and tablets. Testing the written code/modules and debug them to ensure that the application works as intended. Design user interfaces that are optimized for mobile devices, ensuring that they are easy to use and visually appealing. Integrate the mobile application with back-end systems, such as databases or web services and and external APIs to ensure that they have access to the data and functionality expected. Ensure the mobile application is compatible with different mobile devices, operating systems, and screen sizes. (4 points)
  • 4 years of experience in design of web-based information systems using Java EE standards like JSF (Java Server Faces), JPA (Java Persistence API) and JAXB (Java API for XML Bindings) and the build tool Maven, Prime-Faces component library and AJAX web applications, PostgreSQL database, JBoss and clustering implementation, Jasper-Reports (6 points)
• Development cooperation (DC) experience (3.2.6): 3 years of experience in DC projects (10 points)

3.3 UI/UX Designer and Business Analyst (one expert)

Tasks of the UI/UX Designer and Business Analyst

• Conduct document review for the software requirement and specifications to understand the target audience, their preferences, and behavior.
  • Create user personas to guide design decisions based on user needs and expectations.
  • Define the user interface (UI) and user experience (UX) design.
  • Develop wireframes that outline the basic structure and layout of the mobile application.
  • Build interactive prototypes to demonstrate the flow and functionality of the mobile app.
  • Use prototyping tools to simulate user interactions and gather feedback from stakeholders.
  • Design icons and graphics that represent features, actions, and content within the mobile app.
  • Design layouts that are responsive and adaptable to different screen sizes and resolutions.
  • Consider the diverse range of mobile devices, from smartphones to tablets.
  • Conduct usability testing to gather feedback on the design from potential users.
  • Work closely with developers to ensure the feasibility and effective implementation of the design.
  • Ensure that the UI design follows accessibility standards to make the app usable for individuals with disabilities.
  • Creating use cases and user stories while developing a mobile app.
  • Prepare and implement user acceptance testing scenarios.
  • Gather feedback from users and stakeholders and use collected feedback to iteratively improve the software development process together with the development team.
  • Train users
  • Define and track key quality metrics for the developed mobile app to assess the effectiveness/quality of the developed app.
  • Maintain comprehensive documentation, including user manual, technical documentation, inline code comments and data governance framework documentation for the developed mobile app within the entire platform of MEIS.

Qualifications of the UI/UX Designer and Business analyst

• Education/training (3.3.1): university degree (‘Diploma’/bachelor’s degree in graphic design, interaction design, user experience design, web design, visual design, or human-computer interaction. (10 points)
• Language (3.2.2):
  • proficient in English language both spoken and written (C1) (2 points) and
  • proficient in Kinyarwanda (C2) (8 points)
• General required experiences (3.2.3):
  • 5 years of professional experience in designing data systems in social protection or other development projects (2 points);
  • 3 years of experience in web enabled MIS and Mobile application development of comparable projects (3 points);
  • 3 years of professional experience in UI/UX design, mobile system design, business analysis and interaction design. (2 points)
  • 3 years experience in data systems for social protection, preferably in Rwanda (3 points)
• Specific professional experience (3.2.4):
  • 3 years´ experience in creating use cases and user stories, prepare and implement user acceptance testing scenarios. Gather feedback from users and stakeholders and use collected feedback to iteratively improve the software development process, train data system users. Define and track key quality metrics for the data systems and documenting user manual, technical documentation, and data governance framework documentation for the data systems. (2 points)
  • 3 years of experience in carrying out business analysis for complex data systems using UI design tools such as Sketch, Adobe XD, Figma, or Adobe Creative Suite. (4 points)
  • 3 years of experience in typography, color theory, and iconography for creating visually appealing user interfaces. (1 point)
  • 3 years of experience in creating wireframes, user flows, and interactive prototypes to communicate design concepts. Proficiency in creating interactive prototypes using tools like InVision, Marvel, or Proto.io. (3 points)

• Regional or international experience (3.2.5): 4 years of experience in digitalisation projects in Africa including Rwanda. (10 points)
• Development cooperation (DC) experience (3.2.6): 3 years of experience in DC projects (10 points)
• Other (3.2.7):
  • Understanding of responsive design principles to ensure a consistent user experience across various device sizes. (1 points)
  • Understanding of accessibility principles to ensure inclusive design for users with different abilities. Implementation of accessible design elements in compliance with standards (e.g., WCAG). (4 points)
  • Understanding of mobile application security principles, including secure coding practices, encryption, and data protection. (5 points)

Soft skills of all team members

In addition to their specialist qualifications, the following qualifications are required of team members:

• Team skills: proven capacity to work in a team.
• Initiative
• Communication skills
• Socio-cultural skills
• Efficient, partner- and client-focused working methods
• Interdisciplinary thinking

4. Costing requirements

Payment is based on a fixed lump sum price. The following payment plan with partial acceptances is envisaged; the proportions do not necessarily reflect the contractor’s efforts.

4.1 Fixed package price

Pos.	Cost element/partial works	Percentage	Comment
1.3.1	Technical report on agreed implementation plan and user acceptance testing approach	10%	For acceptance criteria see chapter 1.3., position 1.3.1
1.3.2	Minimum viable prototype (MVP) of mobile app ready for initial feedback	10%	For acceptance criteria see chapter 1.3., position 1.3.2
1.3.3	Final Version of mobile app ready for user acceptance testing	60%	For acceptance criteria see chapter 1.3., position 1.3.3
1.3.4	User acceptance testing completed and accepted by both parties.	20%	For acceptance criteria see chapter 1.3., position 1.3.4

With the acceptance of all 4 positions by GIZ, the final acceptance has taken place and the work is completed in terms of reference.

 When submitting the offer, the bidder is requested to present its calculation for each of the work packages in the “Explanations” column of the price list, including a breakdown of the expected number of expert days required and the daily fees.

The following basic calculations (for expert days) for the contract for works are a reference value based on the acceptance criteria for each partial work/milestone specified in Chapter 2 (Tasks to be performed by the contractor).

Quantitative requirements for the main services/tasks

Milestones/partial works	Estimated expert days for orientation	Deadline/place/person responsible
Technical report on agreed implementation plan and user acceptance testing approach.	15	15th July 2024
Minimum viable prototype (MVP) of mobile app ready for initial feedback	30	15st August 2024
Final version of mobile app ready for user acceptance testing	85	15th September 2024
User acceptance testing completed and accepted by both parties	20	15th December 2024
150

4.2 Travel costs

Sustainability aspects for travel

GIZ would like to reduce greenhouse gas emissions (CO2 emissions) caused by travel. When preparing your tender, please incorporate options for reducing emissions, such as selecting the lowest-emission booking class (economy) and using means of transport, airlines and flight routes with a higher CO2 efficiency. For short distances, travel by train (second class) or e-mobility should be the preferred option.

If they cannot be avoided, CO2 emissions caused by air travel should be offset. GIZ specifies a budget for this, through which the carbon offsets can be settled against evidence.

There are many different providers in the market for emissions certificates, and they have different climate impact ambitions. The Development and Climate Alliance (German only) has published a list of standards (German only). GIZ recommends using the standards specified there.

The specified lump sums are the maximum amounts the tenderer can include in the tender. In other words, the tenderer can also offer lower individual lump-sum amounts. The corresponding lump sums are to be entered into the price schedule by the tenderer. Higher lump sums must not be included in the tender.

Lump sums that are not entered in the following table are to be offered by the tenderer (with no upper limit).

Travel expense item	Number/quantity	Lumpsum up to
0	0	0
Total number of regional/domestic flights	0	0
CO2 offset for flights	0	0 0
Transport costs (rail, car, local public transport)	980	420 RWF
Per diem allowances	25	25,000RWF
Accommodation allowances	25	34,000RWF
Other travel expenses (visas, project-related travel expenses outside the seat of business, etc.)	0	0 Against evidence

All travel activities must be agreed in advance with the officer responsible for the project. Travel expenses must be kept as low as possible.

Workshops and training

Required workshops will be funded by GIZ directly and do not need to be part of the financial proposal.

5. Inputs of GIZ or other actors

GIZ and/or other actors are expected to make the following available:

• Workstations on LODA premises
• Logistics for workshops: GIZ-Rwanda through the social protection project will fund any workshop as required. The workshops should be organised by the contractor.

6. Requirements on the format of the tender

The structure of the tender must correspond to the structure of the ToRs. In particular, the detailed structure of the concept (Chapter 3) should be organised in accordance with the positively weighted criteria in the assessment grid (not with zero). The tender must be legible (font size 11 or larger) and clearly formulated. It must be drawn up in English (language).

The complete tender must not exceed 15 pages (excluding CVs). If one of the maximum page lengths is exceeded, the content appearing after the cut-off point will not be included in the assessment. External content (e.g. links to websites) will also not be considered.

The CVs of the personnel proposed in accordance with Chapter 3 of the ToRs must be submitted using the format specified in the terms and conditions for application. The CVs shall not exceed 4 pages each. They must clearly show the position and job the proposed person held in the reference project and for how long. The CVs can also be submitted in English (language).

As the contract to be concluded is a contract for works, please offer a fixed lump sum price that covers all relevant costs (fees, travel expenses etc.). The price bid will be evaluated based on the specified lump sum price. In addition, please also provide the underlying daily rate. A breakdown of days is not required.

7. Optional services/tasks (MEIS IT architect upgrade)

After the services put out to tender are completed or in progress, important elements of these tasks can be continued or extended, specifically:

7.1. Type and scope

Upgrade from JBoss 7 to 8:

Currently version 7.3.4 of JBoss Enterprise Application Platform is used for LODA MEIS. The need for upgrade from JBoss 7 to 8 version will be evaluated upon the feedback from the test scenarios of the developed mobile app and the decision whether the upgrade is to be done or not will be taken accordingly. Further, the architecture of MEIS may be improved to accommodate the changes along with an improved reporting features that will be incorporated.

Once it will be found necessary to upgrade the JBoss 7 to 8 version to accommodate the developed mobile application; the contractor will be requested to provide the following optional services:

1. Analyse application dependencies: Before upgrading, it’s important to analyse the application’s dependencies to ensure that they are compatible with JBoss 8. This may involve identifying any deprecated or unsupported APIs that need to be updated.
2. Upgrade JBoss binaries: Install the JBoss 8 binaries on the target system and configure the environment variables to point to the new installation.
3. Entity mapping in Java classes with recent Hibernate naming schemes involves mapping Java classes to database tables and columns using Hibernate annotations.
4. Update Naming Scheme for Managed Beans: it is an important aspect of creating a maintainable and scalable Java web application.
5. Migrate configuration files: Migrate the JBoss 7 configuration files to JBoss 8. This may involve updating any configuration elements that have changed between the two versions.
6. Clustering and failover server: techniques used to improve the reliability and availability of servers in a distributed computing environment and the ability of a server to automatically switch to a backup server in case of a failure.
7. Clustering and failover database: techniques used to improve the reliability and availability of databases in a distributed computing environment and the ability of a database to automatically switch to a backup database in case of a failure.
8. SMS and USSD gateway for two factor -authentication: gateways for two-factor authentication (2FA) due to their ease of use and wide availability across most mobile devices.
9. MEIS Logs Regular monitoring.
10. Test application functionality: Test the application’s functionality to ensure that it works as expected on JBoss 8. This may involve running automated tests and manual testing to ensure that all features and functionalities work properly.
11. Update custom modules: If the application uses any custom modules, update them to ensure that they are compatible with JBoss 8.
12. Update deployment descriptors: Update the deployment descriptors to ensure that they are compatible with JBoss 8. This may involve updating XML schemas, metadata, and other configuration elements.
13. Update third-party libraries: Update any third-party libraries used by the application to ensure that they are compatible with JBoss 8.

7.2. Requirements for implementing optional services/tasks.

Exercising the optional tasks will depend on the decision taken from the feedback collected from the test scenarios of the developed mobile app and decide whether the upgrade is to be done or not. And it is expected to be made in the period of July 2024 onwards.

The optional tasks will be implemented by means of a contract extension based on the individual approaches already offered.

7.3. Quantitative requirements for the optional services/tasks

Sn	Milestones/partial works	Criteria for acceptance	Deadline/ place/person responsible
1	7.3.1 Final version of upgraded JBoss 8 with features functioning This includes improved performance, enhanced security, advanced management tools for easier configuration, monitoring, and administration of applications, deployment, enhanced scalability and integration capabilities	Joint tests to be done by LODA, developers and GIZ passed successfully according to the following checklist: JBoss 8 server (wild fly) starts up without error. Migrated files are accessed from the servers. Functionality of Clustering and failover from both servers and databases) Functionality of SMS and USSD gateway for two factor authentication for some system users. Log monitoring and aggregation services are accessible
2	7.3.2 Technical Report on the upgrade Process from JBoss 7 to JBoss 8	Final user acceptance testing report on the upgrade process from JBoss 7 to JBoss is accepted and signed by client

Deadlines will be agreed upon in case the optional services/ tasks are adopted.

Requirements on the format of the tender for the main and optional services

• Please submit two price schedules: one price schedule for the main service and one price schedule for the optional service (main service + optional service).
• Please designate each one in the file name.

7.4. Costing requirements

Payment is based on a fixed lump sum price. The following payment plan with partial acceptances is envisaged; the proportions do not necessarily reflect the contractor’s efforts.

7.4.1 Fixed package price

Pos.	Cost element/partial works	Percentage	Comment
7.3.1	Final version of upgraded JBoss 8 with features functioning	80%	See 7.3, position 1 for acceptance criteria
7.3.2	Technical Report on the upgrade Process from JBoss 7 to JBoss 8	20%	See 7.3, position 2 for acceptance criteria

With the acceptance of all 2 positions by GIZ, the final acceptance has taken place and the work is completed in terms of reference.

 When submitting the offer, the bidder is requested to present its calculation for each of the work packages in the “Explanations” column of the price list, including a breakdown of the expected number of expert days required and the daily fees.

The following basic calculations (for expert days) for the contract for works are a reference value based on the acceptance criteria for each partial work/milestone specified in Chapter 2 (Tasks to be performed by the contractor).

Quantitative requirements for the main services/tasks

Milestones/partial works	Estimated expert days for orientation	Deadline/place/person responsible
7.3.1 Final version of upgraded JBoss 8 with features functioning	36
7.3.2 Technical Report on the upgrade Process from JBoss 7 to JBoss 8	4
40

Deadlines will be agreed upon in case the optional services/ tasks are adopted.

7.4.2 Travel Costs

Sustainability aspects for travel

GIZ would like to reduce greenhouse gas emissions (CO2 emissions) caused by travel. When preparing your tender, please incorporate options for reducing emissions, such as selecting the lowest-emission booking class (economy) and using means of transport, airlines and flight routes with a higher CO2 efficiency. For short distances, travel by train (second class) or e-mobility should be the preferred option.

If they cannot be avoided, CO2 emissions caused by air travel should be offset. GIZ specifies a budget for this, through which the carbon offsets can be settled against evidence.

There are many different providers in the market for emissions certificates, and they have different climate impact ambitions. The Development and Climate Alliance (German only) has published a list of standards (German only). GIZ recommends using the standards specified there.

The specified lump sums are the maximum amounts the tenderer can include in the tender. In other words, the tenderer can also offer lower individual lump-sum amounts. The corresponding lump sums are to be entered into the price schedule by the tenderer. Higher lump sums must not be included in the tender.

Lump sums that are not entered in the following table are to be offered by the tenderer (with no upper limit).

Lump sums that are not entered in the following table are to be offered by the tenderer (with no upper limit).

Travel expense item	Number/quantity	Lumpsum up to
Total number of international flights	0	0
Total number of regional/domestic flights	0	0
CO2 offset for flights	0	0 0
Transport costs (rail, car, local public transport)	0	0
Per diem allowances	0	0
Accommodation allowances	0	0
Other travel expenses (visas, project-related travel expenses outside the seat of business, etc.)	0	0 Against evidence

8. Submission of the offer

Technical Proposal

Participating companies must submit the following documents:

• A completed “Self-declaration of eligibility for the award form” (attached) together with the required documents. Non-submission if the completed form and required documents by any bidder will lead to a rejection of the entire bid.
• Technical Proposal (attached template for technical proposal MUST be used)
• Up to date CVs of proposed experts

Financial offer:

Financial offer indicates the all-inclusive total contract price.  The costs must be in RWF and VAT excluded (Price sheet attached MUST be used).

Please submit electronically your EoI (technical & Financial offer) in 2 separated emails and should be in PDF files to this email ONLY: RW_Quotation@giz.de until latest 5^th July 2024. Eligibility documents are submitted together with Technical proposal in 1 email.

Please you must write on each email subject this sentence: 83467171-Technical/financial offer, without this sentence, your offer may not be considered

Hard copies are not allowed this time

GIZ reserves all rights

Annexes

• Eligibility assessment grid
• Technical assessment grid
• Price sheet
• Technical proposal template
• Self-declaration of eligibility for the award

List of abbreviations

API application programming interface

ASP Adaptive Social Protection

cPW classic Public Works

ePW expanded Public Works

GASP Global Alliances for Social Protection

GISGeographic Information System

GIZ The Deutsche Gesellschaft für Internationale Zusammenarbeit

GPS Global Positioning System

HTTP Hypertext Transfer Protocol

JSON JavaScript Object Notation

LODA The Local Administrative Entities Development Agency

MEIS Monitoring and Evaluation Information System

SDLC Software Development Life Cycle

TA Technical Assistance

TORs Terms of reference

UAT User Acceptance Testing

UI User Interface

UX User experience

XML Extensible Markup Language