Issued:

17.06.2020

TERM OF REFERENCE (TOR)

EDUCATIONAL MANAGEMENT
INFORMATION SYSTEM (EMIS)
DEVELOPMENT

2020

KEMENTRIAN AGAMA
 Table of Contents

Table of Contents ...............................................................................................................................................1

Table of Figures ..................................................................................................................................................2
A. Background ................................................................................................................................................3
B. Goals and Objectives..................................................................................................................................3
C. Scope of Work............................................................................................................................................5
D. System Specifications .................................................................................................................................5
1. Software Architecture Specifications .....................................................................................................5
2. System Functional Specifications ...........................................................................................................6
3. Server / Platform Environment Specifications ......................................................................................11
E. Work Results............................................................................................................................................12
1. Documentation ....................................................................................................................................12
2. EMIS ....................................................................................................................................................12
3. Training/Workshop/Support ................................................................................................................12
F. Goods / Services Providers Requirements ................................................................................................13
G. Expert Qualifications ................................................................................................................................14
H. Methodology and Work Schedule ............................................................................................................16
1. Work Methodology..............................................................................................................................16
2. Project Planning Schedule....................................................................................................................19

Terms of Reference Educational Management Information System Page | 1

(EMIS)
Table of Figures

Figure 1 – EMIS Module ......................................................................................................................................4

Figure 2 –Transaction Category ..........................................................................................................................4
Figure 3 – Sprint Activities ..............................................................................................................................16
Figure 4 – The flow between the product backlog and the sprint backlog .........................................................18
Figure 5 – Examples of product backlog hierarchy and sprint backlog ...............................................................18
Figure 6 – Project Planning ..............................................................................................................................19
A. Background
The project Realizing Education’s Promise: Support to Indonesia’s Ministry of Religious Affairs for Improved
Quality of Education (Madrasah Education Quality Reform) –hereinafter referred to as Realizing Education’s
Promise- Madrasah Education Quality Reform [REP-MEQR] (IBRD Loan 8992-ID) aims to improve the quality of
madrasah education management and services within the Ministry of Religious Affairs. The project will be
implemented in five years, starting in early 2020 and ending in 2024 with funding from the World Bank. This
project will be implemented in 34 provinces and 514 districts / cities throughout Indonesia.

The project consists of four project components that can improve student learning outcomes and the
education management system in the Ministry of Religious Affairs. The four components are:
1. Nationwide implementation of e-RKAM (Electronic-based Madrasah Work Plan and Budgeting) System
and Provision of Assistance Funds for Madrasahs. This e-RKAM system enables an increase in the
effectiveness of expenditure through planning and budgeting systems based on performance in madrasas
and BOS schools under the Ministry of Religion that allows madrasas and other religious education units
to plan, budgeting, and monitoring users and more effectively. Provision and assistance are intended to
support the acceleration of the achievement of SNP based on the results of the Evaluation of Madrasah
(EDM) and the implementation of the RKAM.
2. Nationwide implementation of learning Outcomes Assessment system in Madrasah Ibtidaiyah level (MI)
for all students of Class 4. This assessment is expected to be able to measure the impact of funding on
student learning outcomes and identify what aspects need to be improved.
3. Sustainable Professional Policy and Development for Madrasah Teachers, Principals, and Madrasah
Education Personnel. Improving access to quality training allows to increase competency of teacher and
education personnel.
4. Strengthening the System to Support the Improvement of Education Quality. Strengthening the data
collection system so that it can support policy making, as well as strengthening the madrasah
management system and governance at all levels of the Ministry of Religious Affairs, is expected to
improve education system quality in the Ministry of Religious Affairs.

EMIS (Education Management Information Systems) was developed by the Ministry of Religious Affairs in
accordance with the above purposes, it is to improve the quality of madrasah education management and
services within the Ministry of Religious Affairs. EMIS is a web-based information system solution that
functions to collect data on Islamic religious education institutions. The web solution making it easy to input
data of school, Islamic boarding schools (pondok pesantren) and Islamic higher education under the
Directorate General of Islamic Education.

B. Goals and Objectives

Currently there are several data collection applications around EMIS that also collect basic data. This causes
duplication of basic data. Therefore, it is required to improve the EMIS functionalities so that EMIS can be the
only basic data collection application. EMIS performance improvement is also needed to answer user needs
for timely and effective data collection.

Following are the proposed definitions for the functions contained in EMIS:
 Figure 1 – EMIS Module

EMIS is divided into three modules:

1. Institution (Kelembagaan) module. This module will cover key data such as Institutions
(kelembagaan), Facilities and Infrastructure (sarana dan prasarana), Curriculum and Subvention
(kurikulum dan bantuan);
2. Student (Siswa) Module. This module, as the name implies, will cover basic data for students;
3. GTK (Guru dan Tenaga Kependidikan/Teachers and Education Personnel) Module. This module
will handle basic data related to GTK.
Transactions in each module will be in 3 (three) categories, like the chart below:

TRANSACTION PROCESS

1 2 3
GENERAL PROCESS REPORT
Figure 2 –Transaction Category
 1. General Process
a. All data records that are not included in the transactional process are categorized as general
processes;
b. Usually the data in this category is supporting data.
2. Transaction Process
a. All data records that have a specific process are categorized as a transactional process;
b. Usually the data in this category is the main data.
3. Report. There are two types of report, namely:
a. Periodic Automatic Report: which is used to monitor the movement of data regularly so that
it can be corrected immediately if it is not right;
b. Real-Time Report: generated when needed to describe the current state of the data.

C. Scope of Work
The scope of this Educational Management Information System (EMIS) development work is
1. Conduct an EMIS development process following the SCRUM methodology.
2. Assist Product Owner in preparing product backlog based on EMIS Business Requirements Document
(BRD).
3. Create technical proposal based on the product backlog in the form of a Technical Design Document
(TDD) which includes methodology and technology development, software and hardware architecture,
integration guide and data structure. TDD must be constantly updated throughout the project. The
technical proposal must be written in English.
4. Develop EMIS that complies with EMIS specifications.
NOTE: the data in the EMIS functions as a reference for other systems for both KEMENAG's internal
systems and systems that are outside KEMENAG, while EMIS also requires data from other systems, such
as from the DAPODIK system of Ministry of Education and Culture. Therefore, the successful firm is
expected to perform data cleansing and compile a data dictionary to standardize all data referring to
EMIS data and ensure EMIS data uniformity with other systems to which EMIS refers.
5. Provide user manual documentation related to EMIS operations to facilitate users in using and adjusting.
6. Perform all integration and testing activities needed to ensure that all functions and modules work
properly. Integration and testing must be carried out by following the standards set out in the Systems
Development Life Cycle (SDLC) including producing the documents required in these standards;.
7. Provide server environment services and install and host the EMIS on the server environment.
8. Provide training and workshops on use of the EMIS, followed by providing support and guidance by
placing implementors in the KEMENAG environment for a period of 6 months after go-live.
9. Provide support when the system goes live;
10. Provide weekly and monthly work progress reports regularly.

D. System Specifications
1. Software Architecture Specifications
a. To guarantee the scalability and flexibility of the EMIS system in the future, the EMIS will be built
using the concept of a micro services architecture;
b. EMIS deployment uses containerization technology;
c. Communication between services is built using a messaging protocol that has a small payload and
is regulated using message queuing technology;
 d. To speed up response time, data storage is done by using Memory Cache and Relational Data
Base technology;
e. The EMIS architecture must ensure that the EMIS can be integrated with other systems without
location restrictions and platform similarity;
f. The EMIS architecture must guarantee the ease of doing data
backups;
g. The EMIS architecture must support the Disaster Recovery mechanism with automatic failover.
Detail explanation of Disaster Recovery mechanism is defined in EMIS Regulation document
which will be provided in the final phase of the tender;

h. Data validity and integrity. The EMIS architecture must guarantee the validity and integrity of data
inputted by users in any level by guiding users to input data properly and correctly;
i. To simplify troubleshooting when the system is experiencing problems and for the benefit of
auditing system usage, the EMIS architecture must explain the patterns and technologies used for
recording transactions using the EMIS (logging) that can be done properly and correctly.

2. System Functional Specifications

The system functional specification covers all business processes that exist in the current EMIS system
and all business processes listed in the BRD. Both the functional specification and BRD accompany this
TOR and should be considered integral components of the development requirement. The functional
system is summarized in the following table:
 No. Module Functionality Remar
I. Institution
A. General Process
1. Add institution module info type Process to Add institution info type data.
data
2. Change institution module info Process to change the institution info type data
type data
B. Transaction
1. Establish a new private Process to apply an application for establishing and issuing licenses of a
madrasah / institution new private madrasah/institution.
2. Establish a new state Process to apply an application for establishing and issuing
madrasah / institution licenses of a new state madrasah/institution.
3. Changes in the status of The process to apply an application to change the status of
madrasa / institution from private madrasa / institution from private to a state
to state
4. Closing Madrasa / Institution Process to apply an application to close the
madrasah/institution
5. Cancellation of Surat SK IJOP cancellation process
Keputusan Ijin Operasional (SK IJOP)

6. Issuance of EMIS Account The process from registration to issuance of an EMIS

account
7. Closing of an EMIS Account Process of closing an EMIS account.
8. Add / Edit / Delete asset data Process to add/edit/delete asset data
9. Accreditation Review the data and accreditation process of the
institution.
C. Reports
1. Periodic Automatic Reports – Institution Asset Data Report scheduled for the beginning of the
Institution Asset Data semester.
2. Periodic Automatic Reports - Automatic report of curriculum input results and
Curriculum Checks and Student synchronization of the student report card, scheduled at the
Report Cards beginning of the semester.
3. Periodic Automatic Reports - Student data reports for BOS assistance program
Student Data for Bantuan Operasional submissions are scheduled for December 15th, January
Sekolah (BOS) assistance Submission 30th, April 30th and August 31st.

4. Periodic Automatic Reports - Student data reports for PIP assistance program submission
Student Data for PIP assistance are scheduled for December 15th, January 30th, April 30th and August
Submission 31st.
5. Periodic Automatic Reports - Teacher Teacher data reports for TPG assistance program submission,
Data for Tunjangan Profesi Guru (TPG) scheduled at the beginning of the semester.
assistance Submission

6. Periodic Automatic Reports – Automatic report of general data of institution, scheduled at the
General data of institution beginning of the semester
II. Modul GTK
A. Functionalities of this module are mainly handled by Sistem Informasi dan Manajemen Pendidik dan
Tenaga Kependidikan (SIMPATIKA)
Transaction GTK
1. SIMPATIKA – GTK Registration EMIS accommodates the NIK data checking function after getting a
request from SIMPATIKA during the GTK registration process.

2. SIMPATIKA – GTK Mutation EMIS accommodates receiving GTK Mutation Data

from School to Madrasah Information from Kemdikbud, to be forwarded to the
SIMPATIKA Application.
3. SIMPATIKA – Inter-Madrasa The GTK NIK data checking function after getting a request from
Mutations SIMPATIKA during the GTK mutation process between madrasahs.
Terms of Reference Educational Management Information System Page | 7
(EMIS)
 No. Module Functionality Remar
4. SIMPATIKA – GRK Mutation • The GTK NIK data checking function after getting a request from
from Madrasah to General SIMPATIKA during the GTK mutation process.
School • Receive mutation information after the mutation process is
carried out through SIMPATIKA.

5. SIMPATIKA – TPG Eligibility EMIS handles the GTK NIK data checking function after getting a
request from SIMPATIKA during the TPG eligibility process.

6. SIMPATIKA – Inpassing EMIS handles the function of checking GTIK NIK data after
getting a request from SIMPATIKA during the process of verification
and validation of inpassing data.
7. SIMPATIKA – Promotion to become EMIS handles the GTK NIK data checking function after getting a
the Head of Institution request from SIMPATIKA when submitting the application for the head
/ Supervisor of the institution / supervisor promotion.

8. SIMPATIKA – NRG Issuance EMIS handles their process:

• The GTK NIK data checking function after getting a request from
SIMPATIKA during the NRG issuance process.
• Receive NRG issuance request
• Receive NRG issuance information

9. SIMPATIKA – Manage the EMIS handles the function of checking GTIK NIK data after
Number of Institutions / Assisted getting a request from SIMPATIKA during the process of managing
Teachers for Supervisors the number of institutions / assisted teachers.

10. SIMPATIKA – GTK Deactivation EMIS handles the GTK NIK data checking function after getting a
request from SIMPATIKA during the GTK deactivation process.

11. SIMPATIKA – Rombel EMIS sends Data on Number of Classes and Students according to
determination the criteria requested by SIMPATIKA
B. Sіѕtеm Infоrmаѕі dаn Admіnіѕtrаѕі Guru Agаmа (SIAGA) provides functionalities for this module.
Transaction PAI
1. SIAGA – PAI Teacher/PAI EMIS handles process to:
Supervisor Registration • Receive PAI teacher / PAI supervisor registration data
• Check NIK for the registration process of PAI teachers
/ PAI supervisors and forwarded the data to SIAGA
2. SIAGA – PAI Teacher Mutation EMIS handles process to:
• Receive PAI teacher mutation data
• Examination of NIK and NPSN data for the PAI teacher mutation
process from other Apps then forwarded it to SIAGA

3. SIAGA – Check TPG Eligibility Examination of NIK data for the TPG eligibility process from
SIAGA
4. SIAGA –NRG Issuance • Check NIK data for the NRG issuance request process from SIAGA
• Receive information on NRG issuance requests
• Receive NRG issuance information

5. SIAGA – Manage the number of EMIS handles NIK data checking for the process of managing
Assisted Teacher for Supervisor the number of assisted teachers from SIAGA.
6. SIAGA – PAI Teacher • Receive Deactivated PAI teacher data
Deactivation • Checking NIK for the process of deactivating PAI
teachers from SIAGA
7. SIAGA – PAI Supervisor • Check NIK for the process of deactivating PAI
Deactivation supervisors from SIAGA
8. SIAGA – NUPTK Application • Check NIK PTK data for the NUPTK application process from
SIAGA
• Receive information on NUPTK applications
• Receive information on the issuance of NUPTK
Terms of Reference Educational Management Information System Page | 8
(EMIS)
 No. Module Functionality Remar
9. SIAGA – NUPTK • Receive NUPTK information
Acceptance • The process of NUPTK acceptance
10. SIAGA – Inpassing Check NIK PTK data for the inpassing submission process.
11. SIAGA – Inpassing Acceptance Check NIK PTK data for inpassing acceptance process
C. Reports
1. Reports - GTK, PAI and EMIS handles data collection from SIMPATIKA and SIAGA to generate
Supervisor Data GTK, PAI and supervisor reports.
2. Reports – TPG eligibility EMIS handles data collection of certified GTK who have NRG
according to the institution and certain date.
III. Modul Siswa
A. General Process
1. Adding Student Module The process of adding student module info type data. The process of
Infotype Data
2. Change the Student Infotype changing student module info type data.
Data
B. Transaction
1. Admission of New Students The process of inputting data for new student admissions. The process
2. Semester Activities (Report Card, of checking and determining student grade and graduation.
Grade Promotion and Graduation)
3. M2M – (Mutation between Process to apply student mutation between madrasahs
Madrasahs)
4. M2S – (Student Mutation from Application process for student transfer from madrasa to general
Madrasah to General School) school.
5. S2M - (Student transfer from Application process for student transfer from general school to
School to Madrasah) madrasah.
6. L2M – (Transfer of Overseas Application process for student transfer from overseas to madrasah.
Students to Madrasah) Application process for student transfer from madrasah to overseas
7. M2L – Mutasi Madrasah ke Luar institution.
Negeri (Madrasah Mutation to Abroad
Institution)
8. Student Drop Out Input data process for Drop Out student.
9. Capesun / National exam Checking student data to be sent as CAPESUN data.
participant registration
10. Scholarships and assistance Data input process for scholarship recipients or assistance students.

C. Reports
1. Periodic Automatic Reports - Student Reports on completeness of Student and Parent data scheduled at the
and Parent Data beginning of the semester. This report will identify all data that has not
2. been filled.
3. Periodic Automatic Reports – Reports are scheduled at the beginning of the semester containing Data
Student Achievement Data on Student Achievements in the previous semester.
Student data reports that are filtered by class/study group and
4. Student data filtered by Class and sex/gender
Sex/Gender (Madrasah Diniyah)
5. Student data filtered by origin Student data reports that are filtered by origin
Madrasah/School and sex/gender Madrasah/School and sex/gender
(Madrasah Diniyah)
6. Student Situation at the End of the
Previous Academic Year (Madrasah Student data reports filtered by the passing-to-next-grade status (Naik
Ibtidaiyah, Madrasah Tsanawiyah, atau Tidak Naik Kelas) based on every Rombel (Class/Study group)
Madrasah Aliyah)
Terms of Reference Educational Management Information System Page | 9
(EMIS)
No. Module Functionality Remar
7. Students mutation data in the This report is based on student who:
current Academic Year 1. Transferred Out
(Madrasah Ibtidaiyah, 2. Drop Out
Madrasah Tsanawiyah, 3. Transferred In
Madrasah Aliyah) 4. Drop Out and Re-enter the school Reports are
grouped by class and sex/gender This report generates
8. The origin of students in the current data that displays:
school year (Madrasah Ibtidaiyah, 1. The number of registrants according to the school
Madrasah Tsanawiyah, Madrasah origin and sex/gender
Aliyah) 2. The number of students accepted filtered by student
gender. Note, the maximum number of accepted students must
be the same as the number of registrants
9. Students situation in the Current This report generates data that displays:
Academic Year (Madrasah 1. Number of poor students per class filtered by sex/gender.
Ibtidaiyah, Madrasah Note: the maximum number of poor students is the same as the
Tsanawiyah, Madrasah Aliyah) number of students in table
6
2. Number of students with special needs and disabilities per class
filtered by sex/gender. Students with special needs are students
who need specificity both in terms of learning aids and attention.
For example, for special needs such as Tuna Netra, Tuna Rungu,
Tuna Grahita. And for disabilities such as learning disabilities,
specific learning difficulties, children with exceptional intelligence
abilities. Note: the maximum number of students with this need is
the same as the number of students at report 6.
3. Number of rombel (study group) per class
This report generates data that displays:
10. Student data based on Age, Class - Number of students per class and filtered by sex/gender.
and Gender of the current Academic Note: the number of students per class and per sex/gender must
Year (Madrasah Ibtidaiyah, be the same as and synchronous with the number of students in
Madrasah Tsanawiyah, Madrasah Report
Aliyah) 6
11. Number of students and Rombel / This report generates data that displays:
Classes based on school hours of 1. The total number of students based on school hours and
the year (Madrasah Ibtidaiyah, sex/gender. Note: the number of students must be the same
Madrasah Tsanawiyah, Madrasah and synchronous with the number of students in Report 4 and
Aliyah) Report 5.
2. The total number of rombel/classes based on school
hours. Note the number of these groups must be the same and
synchronous with the number of classes available in Report 4

12. Santri data based on the living Reports on number of students that live on and outside
location premise based on gender
13. Santri data based on Regional This report generates data that displays:
Origin The number of santri filtered by original regional background and
grouped by sex/gender. (Total number of santri in this report must be
the same as the total number of santri in Santri Report 1)
This report generates data that displays:
14. Santri data based on learning status The number of santri who stay/not stay at pesantren filtered by
and living location (on or outside sex/gender and pesantren type. (Note: the total number of santri in this
premise) report must be the same as the total number of santri in Santri Report
1. (Info on the number of santri attached in the application))
This report generates data that displays:
The number of santri who stay/not stay (mukim/tidak
15. Santri data based on Education
Units under the Ministry of
Terms of Reference Educational Management Information System Page | 10
(EMIS)
 No. Module Functionality Remar
Religious Affairs (inside mukim) at Pondok Pesantren, in accordance with the
Pondok Pesanteran education unit that followed under the Ministry of
environment) Religious Affairs inside the school environment. This report is filtered by
sex/gender.
16. Santri data based on Education Units This report generates data that displays:
under the Ministry of Religious Affairs The number of santri who stay/not stay (mukim/tidak mukim) at
(outside the Pondok Pesanteran Pondok Pesantren, in accordance with the education unit that
environment) followed under the Ministry of Religious Affairs outside the school
environment. This report is filtered by sex/gender.
17. Santri data based on Education Units This report generates data that displays:
under the Kemendiknas (inside Pondok The number of santri who stay/not stay (mukim/tidak mukim) at
Pesanteran environment) Pondok Pesantren, in accordance with the education unit that
followed under the Kemendiknas inside the school environment.
This report is filtered by sex/gender.
18. Santri data based on Education Units This report generates data that displays:
under the Kemendiknas (outside The number of santri who stay/not stay (mukim/tidak mukim) at
Pondok Pesanteran environment) Pondok Pesantren, in accordance with the education unit that
followed under the Kemendiknas outside the school environment.
This report is filtered by sex/gender.
19. Santri who only study in Diniyah / This report generates data that displays:
only recite and learning Al-Quran at The number of students inside or outside the Pontren who only studied
Pondok Pesantren at diniyah / only learning Al-Qur’an at the pontren
20. Santri data based on Equality This report generates data that displays:
Education Program The number of students inside or outside the pontren participating
in the equality education program.
21. Santri report based on Wajar Dikdas This report generates data that displays:
Program filtered by Age and Gender (PP The number of students enrolled in the Wajar Dikdas
Salafiyah only) Program filtered by Age and Gender.
22. Santri report based on Wajar Dikdas This report generates data that displays:
program participant (PP Salafiyah Only) the number of students taking part in the Wajar Dikdas
Program filtered by study period and sex/gender.

3. Server / Platform Environment Specifications

a. The server environment where the EMIS will be installed must support the following technologies:
1) Container service;
2) Memory Caching and Relational Database;
3) Service mesh to monitor and control EMIS microservices;
4) Load balancing;
5) Application Programming Interface (API) gateway;
6) Message publishing & subscription;
7) Message Queueing.
b. Having enough resources (bandwidth, computing power) to serve 8000 - 10,000 concurrent users.
c. The Relational Database engine used must have at least the following features:
1) Auto failover to stand by database. If a problem occurs in the main database, the database
system can automatically make transition to a stand-by database.
2) Automatic Conversion. When there is a problem with the main database and the system has
automatically transitioned to standby-database, the database system will automatically make

Terms of Reference Educational Management Information System Page | 11

(EMIS)
 standby-database as the main database and vice versa (the main database becomes the
standby-database)
3) Scheduler. Scheduler is needed to run certain tasks at a predetermined time, such as
performing automatic database backups.
4) Capturing data history for data audit purposes.
d. Has a data storage capacity that can store data of 2 Terabytes for 5 years (online) and 20 years in
the form of off-line storage.
e. Pass the security testing according to the Open Source Security Testing methodology guide, which
consists of:
1) Vulnerability scanning;
2) Security Planning;
3) Penetration Testing;
4) Risk Assessment;
5) Security Auditing;
6) Posture Assessment;
7) Ethical Hacking.

E. Work Results
The expected results of the work are as follows:
1. Documentation
a. User Manual;
b. Product Backlog and Technical Design Document;
c. User Acceptance Test Document and Test Report;
d. All application documentation needed to use and adjust the application correctly, completely,
easily and precisely, without involving other parties outside in the future.
e. Weekly and monthly progress reports.

2. EMIS
a. EMIS that has been implemented and is go-live as a whole and meets the specifications of
functionality, architecture and hardware platforms;
b. Source Code of EMIS;
c. Library and components used in developing EMIS;
d. Data dictionary that has been through the process of data cleansing. The resulting data dictionary
must be standardized so that it can be a reference for systems that require data from EMIS both
internal systems in the KEMENAG and also the external systems, and vice versa the EMIS system
data dictionary must also have unity with data from other systems that are used as a reference to
the EMIS system like the DAPODIK system of KEMDIKBUD.

3. Training/Workshop/Support
a. Documentation of training implementation (Training Record);
b. Copy of training / workshop material.
c. Records of completed training events and activities, including registers of
participants. d. 6 months support after go live.
F. Goods / Services Providers Requirements
The following are the requirements that must be met by goods / services provider.

1. Service provider must be a legal Business Entity;

2. Able to provide the Deed of Establishment and its amendments;
3. Not being blacklisted by World Bank, the Government or Private institutions shown by Declaration Of Non
Bankruptcy and is not in legal matters to participate in procurement;
4. Having an office in Jakarta proved by a certificate of domicile of the company is an advantage.
5. The team that will carry out EMIS development work must include representatives based in Jakarta.
6. Having experience and success in implementing at least 2 (two) IT systems based on micro services;
7. Having experience implementing information systems in government sector in the field of Education will
be a plus.
8. Having good English and Bahasa Indonesia communication skills both verbal and written
9. Having experience providing long-term system service and maintenance that has standard procedures;
10. Have a knowledge / technology transfer method;
11. Have team Resources that are experienced in similar industries (see next section for details).
12. Have financial capacity
 G. Expert Qualifications
The following are the skills that the EMIS development team must possess.
EXPERTISE EXPERT QUALIFICATION EXPERTISE DESCRIPTION

Scrum Master Bachelor's degree with a

• Have a deep understanding of SCRUM
minimum of 7 years’ work
and have been a Scrum Master at least in 3
experience
projects with good results.

• Able to ensure all members in the team

understand and execute the Scrum
process properly.

• Able to help the product owner in

preparing the product backlog.

• Able to help the product owner in

developing system development
strategies.

• Able to facilitate and coaching the

development team so that the system
development process runs effectively and
produces a proper system.
Project administrator Bachelor's degree with a Support Scrum Masters related to the
minimum of 2 years’ work administration of project and at least have
experience or D3 degree with experience in similar Information Technology / IT
a minimum of 4 years’ work projects in 1 full cycle.
experience
Technical Writing Bachelor's degree with a Able to write technical documents and at least
minimum of 2 years’ work have experience in similar Information
experience or D3 degree with Technology / IT projects in 1 full cycle.
a minimum of 4 years’ work
experience
Business Analysis Master’s degree with a Able to collect data, analyze and detail the system
minimum of 5 years’ work requirements contained in the product backlog
experience document
Designing System Architecture Master’s degree with a Able to make a system design based on micro
minimum of 7 years’ work services concept and have experience in
experience creating micro services- based system designs.

Designing User Interface Bachelor's degree with a Able to design a user friendly and effective
Experience (UIX) minimum of 2 years’ work interface
experience
Software engineering Bachelor's degree with a Able to build IT systems based on services and
minimum of 5 years’ work have experience in integrating systems. Having
experience experience developing systems in the education
sector will be a plus.

Terms of Reference Educational Management Information System Page | 14

(EMIS)
 EXPERTISE EXPERT QUALIFICATION EXPERTISE DESCRIPTION

Cloud Engineering Bachelor's degree with a Having knowledge and experience in the
minimum of 5 years’ work management and deployment of cloud co
experience based systems
Software Quality Assurance Bachelor's degree with a Good ability in testing software and systems
Engineering minimum of 5 years’ work experienced in conducting automated testin
experience testing and security testing software.

Administrating Database Bachelor's degree with a Having certification as a database administra

minimum of 5 years’ work the database engine to be used.
experience
Change management Master’s degree with a minimum Able to develop and implement change man
of 5 years’ work experience in implementing the EMIS system

Assistance/Implementor Bachelor's degree with a Mastering the system and having good soft s
minimum of 3 years’ work aiding in using the system to users
experience
Terms of Reference Educational Management Information System Page | 15
(EMIS)
 H. Methodology and Work Schedule
1. Work Methodology
SCRUM INTRODUCTION
To ensure everyone who will be involved in the project understands the mechanism of SCRUM
approach and its terminologies, everyone involved in the project must attend SCRUM
Introduction Training given by the Ministry of Religious Affairs.

As already explained, in the SCRUM method, the system is built in several iterations called
sprints. The picture below shows the activities in a sprint.

Figure 3 – Sprint Activities

TEAM COMPOSITION
To enhance project success the team composition for this project will consist of cross functional
skills as follows:

a) From Vendor/Developer
• Scrum Master
• Project Administrator
• Technical Writer
• Business Analyst
• System Architect
• UIX Designer
• Software engineer
• Cloud Engineer
• Software Quality Assurance Engineer
• Database Administrator
• Change management Consultant
• Assistance
b) From Ministry of Religious Affairs (KEMENAG)

• Product Owner

Terms of Reference Educational Management Information System Page | 16

(EMIS)
CREATING THE PRODUCT BACKLOG
a) Prior to the project execution and entering the first iteration, the appointed Product Owner from the
Ministry of Religious Affairs will collaborate with the Scrum Master to compose the product
backlog. The product backlog is a list of brief descriptions of the functionalities that will be
built. In SCRUM the items in the product backlog are called user stories.
b) Product backlog not only contains a list of user stories that must be built but also must be
sorted according to the urgency and value of the functionality.
c) At the beginning of the project the product backlog is usually just a list of user stories sorted
by urgency and value. But in line with the project journey, the product backlog can also
contain bugs and request changes.
d) Product backlog is dynamic both in terms of the number and sequence of user stories in it.
Product backlog is not static like the document requirements in the waterfall method.

CREATING THE SPRINT BACKLOG

a) At the beginning of each sprint, the Product Owner will attend a sprint planning meeting with
the Development Team to discuss and to prioritize the functionalities that must be built in
the sprint.
b) The list of user stories that will be built in a sprint is called the sprint backlog. In the sprint
backlog, the user story of the product backlog will be further analyzed and equipped with
supporting documents such as: UI Design, UML diagrams, test scenarios etc.
c) At the end of each sprint, the Product Owner and stakeholder must evaluate the software that
has been produced in the sprint, this event is called a sprint review. Based on the results of
the sprint review, the Product Owner can make changes to the product backlog either by
adding or subtracting user stories or making changes to the order of user stories. If the
reorganization of the product backlog affects the working time of the project, both parties
must consider the project working time.

The following figure shows how the flow between the product backlog and the sprint backlog.
 Figure 4 – The flow between the product backlog and the sprint backlog

The following figure shows the hierarchy between the product backlog and the sprint backlog.

Figure 5 – Examples of product backlog hierarchy and sprint backlog

DEFINITION OF DONE
To ensure high quality for the project, both KEMENAG and developer may refine the “Definition of
Done” at every iteration. The initial Iteration Deliverables is as follows:
a) Must comply with the Business Requirement Document, where this document contains a
description of the functions of the product.
b) System shall be tested:
• Unit tested
 • Functionally tested
• Stress tested
• Security tested
c) Up-to-date documentations
d) In the sprint-review phase, the functionality is immediately deemed to be not “Done” or
“Undone”. Any “Undone” item from the current Sprint shall be carried over to the next
iteration and reprioritized by the Product Owner.

DEPLOYMENT
At the end of every iteration Product Owner may ask to deploy the “Done” functionalities into
Production environment.

2. Project Planning Schedule

As explained at the beginning of this chapter, the implementation of EMIS development is carried out
in several sprints using the SCRUM methodology, where the number of sprints is at least 6 sprints.
At the end of each sprint, a sprint review will be conducted where the company's performance will
be evaluated by the PMU team. In case the evaluation leads to a conclusion of underperformance,
the PMU can terminate the contract according to established procedures and criteria.

PR O JE L A NCTNPLIANNNGING
SPRINT I (30 CALENDAR
DAYS)

PENDAMPINGAN ON
SITE SPRINT 1

SPRINT 2 (30
CALENDAR DAYS)

PENDAMPINGAN ON
SITE SPRINT 2

SPRINT 3 (30 CALENDAR

DAYS)

PENDAMPINGAN ON
SITE SPRINT 3

SPRINT 4 (30 CALENDAR

DAYS)
PENDAMPINGAN ON
SITE SPRINT 4

SPRINT 5 (30 CALENDAR

DAYS)

PENDAMPINGAN ON
SITE SPRINT 5
SPRINT 6 (30 CALENDAR
DAYS)

Figure 6 – Project Planning

I. Duration of Assignment
The Consultants Firm will be contracted for 11 months with the possibility of extensions until December
2023, provided performance is of sufficient quality to justify extension. Consultant performance evaluation
will be conducted at least once in one fiscal year, but possibly more frequently, by PMU.

J. Source of Funds
The budget for the consultant will be financed by the World Bank Loan Number 8299-ID through budget
allocation (DIPA) at Directorate General Islamic Education, Ministry of Religious Affairs year 2020, 2021 and
2022.

Jakarta, 22 June 2020

Dedicated Commitment Officer

Abdullah Faqih