View of Analisis Dan Perancangan Sistem Informasi Laporan Kinerja Harian Dosen Dengan Pendekatan Object-Oriented Dan Agile Unified Process (AUP)

(1)

302 Jurnal Teknik Informatika dan Sistem Informasi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

Analisis Dan Perancangan Sistem Informasi Laporan Kinerja Harian Dosen Dengan Pendekatan Object-

Oriented Dan Agile Unified Process (AUP)

Rio Irawan*¹, Slamet Riyadi²

1,2Manajemen Pendidikan Islam, Fakultas Tarbiyah dan Ilmu Keguruan, IAIN Palangka Raya e-mail: *¹rioirawan@iain-palangkaraya.ac.id, ²slametdiyadi@iain-palangkaraya.ac.id

Abstrak

Laporan kinerja harian dosen merupakan pencatatan kegaitan yang dilakukan oleh seorang dosen setiap hari kerja dan kemudian dilaporkan setiap satu tahun sekali kepada bagian kepegawaian di Insitut Agama Islam Negeri (IAIN) Palangka Raya sebagai salah satu tagihan bagi dosen yang mendapatkan tunjangan kinerja. Isi dari laporan ini umumnya terdiri dari kegiatan-kegiatan Tri Dharma yang dilakukan oleh dosen yang bersangkutan meliputi kegiatan mengajar, meneliti, dan melakukan pengabdian kepada masyarakat. Beberapa masalah yang timbul dari proses pelaporan kinerja harian ini adalah kurangnya validitas kegiatan/kinerja yang dilakukan oleh dosen karena laporan dibuat pada akhir tahun dan belum adanya verifikator untuk menilai keabsahan terhadap isi dari laporan tersebut. Berdasarkan hal tersebut, dilakukan perancangan sistem berbasis web yang digunakan untuk melakukan pencatatan pelaporan kinerja harian oleh dosen dan adanya proses verifikasi oleh pejabat yang berwenang. Analisis dan perancangan dilakukan dengan pendekatan object oriented menggunakan Unified Modeling Language (UML), sementara itu metode dalam software engineering yang digunakan Agile Unified Process (AUP). Sementara itu, sistem nantinya mampu menangai pelaporan kinerja harian dosen secara real-time dan wajib melampirkan bukti kinerja yang kemudian akan dilakukan verifikasi oleh pejabat yang berwenang pada periode tertentu agar menghasilkan data yang tingkat validitasnya lebih baik.

Kata kunci : Laporan Kinerja Harian, UML, Object-Oriented, AUP

Abstract

The lecturer's daily performance report is a recording of activities carried out by a lecturer every working day and then reported once a year to the staffing department at the Palangka Raya State Islamic Institute (IAIN) as one of the bills for lecturers who receive performance allowances. The contents of this report generally consist of Tri Dharma activities carried out by the lecturer concerned, including teaching, researching, and community service activities. Some of the problems that arise from this daily performance reporting process are the lack of validity of activities/performance carried out by lecturers because reports are made at the end of the year and there is no verifier to assess the validity of the contents of the report.

Based on this, a web-based system is designed that is used to record daily performance reports by lecturers and a verification process by authorized officials. Analysis and design were carried out using an object-oriented approach using the Unified Modeling Language (UML), while the method in software engineering used the Agile Unified Process (AUP). Meanwhile, the system will be able to handle lecturers' daily performance reporting in real-time and must attach proof of performance which will then be verified by the authorized official for a certain period in order to produce data with a better level of validity.

(2)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 303

Rio, et., al [Analisis dan Perancangan Sistem Informasi Laporan Kinerja Harian Dosen Dengan Pendekatan Object- Oriented dan Agile Unified Process (AUP)]

1. PENDAHULUAN

Teknologi informasi/ sistem informasi merupakan sebuah kebutuhan dalam melakukan pencatatan dan pengelolaan data yang efektif dan efisen, terlebih lagi pada era perkembagan teknologi digital. Dengan penggunaan teknologi infomasi/ sistem informasi proses bisnis suatu kegiatan yang sebelumnya belum tersistem akan menjadi lebih efektif dan efisen dalam pelaksanaannya. Dalam praktiknya seorang dosen selain dituntut untuk melaksanakan Tri Dharma yang yaitu mengajar, meneliti, dan melakukan pengabdian masyarakat juga melakukan pekerjaan-pekerjaan lainnya sebagai kegiatan penunjang.

Adapun tujuan dari pelaporan kinerja harian dosen ini selain sebagai alat instrumen untuk evaluasi dan monitoring kegitan yang dilakukan oleh dosen juga dijadikan salah satu indikator dalam capaian kerja dan untuk mendapatkan tunjangan kinerja. Laporan kinerja harian ini merupakan sebuah tagihan atau output yang harus dibuat oleh dosen-dosen di lingkungan IAIN Palangka Raya khususnya di Fakultas Tarbiyah dan Ilmu Keguruan (FTIK) yang mendapatkan tunjangan kinerja.

Proses pelaporan yang dilakukan setiap akhir tahun tentunya menjadi kendala tersendiri, baik bagi dosen maupun bagi verifikator. Tidak semua dosen akan mencatat kegiatan hariannya, sehingga akan terjadi kerawanan terhadap data yang tidak valid. Proses verifikasi juga menjadi kendala jika hanya didasarkan pada data yang dikumpulkan oleh dosen yang periodenya selama 1 tahun, menjadi hal yang tidak efektif dan efisien untuk melakukan penelurusan jika ingin melakukan pengecekan data. Dengan perkembangan teknologi informasi diharapan mampu untuk memperbaiki proses bisnis pelaporan kinerja harian dosen sehingga menjadi lebih baik, sehingga data yang dihasilkan menjadi lebih valid dan verifikator mudah dalam memantau setiap kegiatan yang dilaporkan oleh dosen.

Salah satu teknologi yang bisa digunakan adalah sistem berbasiskan web atau website.

Penggunaan website sebagai sarana dan media dalam proses pelaporan kinerja dosen dirasakan menjadi alternatif yang baik dan optimal, sebab dengan adanya sistem berbasis website dapat diakses kapanpun dan dimanapun, selain itu website mampu menerima data pelaporan kinerja secara real-time dan vefikator dapat memantau setiap data yang masuk secara real-time juga.

Hasilnya diharapkan data yang laporkan mudah dikontrol sehingga menghasilkan data yang valid, serta memudahkan bagi verikator dalam mengontrol atau memvalidasi data.

Object-Oriented Analysis (OOA) merupakan suatu metode analisis yang menghasilkan prosedur-prosedur atau rekomendasi dalam melakukan pendefinisian persyaratan-persyaratan rekayasa perangkat lunak yang didasarkan pada objek atau kelas tertentu agar mendapatkan gambaran secara lebih rinci terhadap permasalahan yang dihadapi, sedangkan Object-Oriented Design (OOD) adalah tahapan perantara untuk memetakan spesifikasi atau merancang kelas- kelas yang teridentifkasi selama tahapan analisis dan antarmuka pengguna (user interface) sehingga kebutuhan sistem yang akan di buat dengan konsep berorientasi objek ke desain dapat lebih mudah diimplementasikan dengan pemograman berorientasi obyek [1].

Seiring dengan perkembangan metodologi berorientasi objek, perkembangan perangkat lunak juga mengalami perkembangan. Prinsip dalam pengembangan desain berorientasi objek adalah bahwa setiap komputasi harus direpresentasikan sebagai penerapan metode ke objek tertentu, yang kemudian diperlakukan sebagai objek saat ini untuk komputasi [2].

Pengembangan desain digunakan menggunakan Unified Modeling Language, yaitu merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram dan teks-teks pendukung [3].

Salah satu metode rekayasa perangkat lunak atau Software Engineering yang dapat digunakan untuk menghasilkan sebuah perangkat lunak dengan cepat adalah dengan menggunakan Agile Software Development (ASD) [4]–[6]. Dipilihnya ASD sebab terdapat

(3)

304 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

prinsip-prinsip antara lain : 1) Fits just right process; 2) Continuous testing and validation; 3) Consitent team collaboration; 4) Rapid response to change; 5) Ongoing customer involvement;

dan 6) Frequent delivery of working software [5]. Selain itu ASD juga berbeda dari metode lainnya karena fokus pada kolaborasi dan fokus pada working software [7]. Metodologi Agile Unified Process (AUP) terdiri dari tujuh disiplin ilmu atau area kerja yang harus dilakukan selama iterasi termasuk model, implementation, test, deployment, configuration management, project management and environment [8], [9]. Selain itu, AUP terdiri dari empat fase yang meliputi Inception, Elaboration, Construction dan Transition [8], [9]. Dengan menerapkan AUP diharapkan mampu menghasilkan desain perangkat lunak yang optimal sebab salah satu keunggulan dari metode ASD adalah adanya kolaborasi antar tim pengembang dan stakeholder yang bekepentingan serta pada saat development perangkat lunak stakeholder masih dapat berkonstribusi dalam proses pengembangan.

2. METODE PENELITIAN

Penelitian ini menggunakan metode Agile Unified Process (AUP) [10]–[12], dalam rangka melakukan analisis dan perancangan sistem informasi laporan kinerja harian dosen, agar didapatkan gambaran terhadap proses bisnis secara jelas dan rinci pada masing-masing fase-fase dalam penelitian yang dilakukan. Adapun tahapan-tahapan pada metode Agile Unified Process (AUP) secara rinci dapat dilihat pada gambar 1.

Gambar 1. Agile Unified Process Phases (AUP) [10], [11]

Adapun tahapan-tahapan atau fase-fase Agile Unified Process (AUP) yang dilakukan yaitu sebagai berikut :

1. Inception

Pada fase ini dilakukan analisis kebutuhan bisnis, analisis proses bisnis sistem berjalan, melakukan kolaborasi dengan stakeholder, mendeskripsikan kelas-kelas atau objek-objek,

(4)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 305

menentukan ruang lingkup proyek, melakukan penjadwalan proyek, memetakan risiko-risiko yang akan terjadi, menentukan kelayakan proyek, merencanakan model proyek.

2. Elaboration

Pada fase ini dilakukan analisa permasalahan terhadap proses bisnis sistem lama, mengembangkan perencanaan proyek agar sesuai dengan environtment, melakukan tahap rekayasa modeling berbasis UML [13], melakukan modeling basis data yang diperlukan [14], serta menetapkan baseline proyek untuk evaluasi perkembangan proyek, memontoring penjadwalan proyek [15].

3. Construction

Fase ini mulai dilakukan pengkodean sistem yang disesuikan dengan model yang telah dibuat, pendefinisian requirement dan desain model sudah difinalkan. Pada fase ini juga dilakukan proses testing baik secara unit testing hingga pengetesan integrasi sistem (Software Integration Test). Tes dilaukan dengan memperhatikan use case yang telah di buat.

4. Transition

Fase terakhir sebelum dilakukan perangkat lunak di release yaitu melakukan beta testing oleh stakeholder yang berkepentingan untuk menilai software telah sesuai dengan requirement yang telah ditentukan di fase awal. Membuat sebuah dokumentasi (user guide, installation guide, dll). Tahap terakhir adalah proses deployment kepada stakeholder agar software dapat digunakan

3. HASIL DAN PEMBAHASAN

Pada bagian ini akan dijelasakan mengenai hasil dan pembahasan dari Analisis Dan Perancangan Sistem Informasi Laporan Kinerja Harian Dosen Dengan Pendekatan Object- Oriented dan Agile Unified Process (AUP).

3.1 Inception Phase

Pada fase atau tahap ini dilakukan untuk mendapatkan gambaran terkait proses-proses bisnis yang sedang berjalan sehingga akan mendapatkan informasi yang lebih aktual guna pengembangan perancangan sistem informasi yang tepat. Beberapa langkah yang dilakukan pada fase ini antara lain:

a. Pengumpulan Data

Proses pengumpulan data dilakukan dengan melakukan wawancara dengan stakeholder utama yaitu Wakil Dekan 1 Bidang Akademik, serta dengan melibatkan informan dari pihak dosen di Fakultas Tarbiyah dan Ilmu Keguruan (FTIK) IAIN Palangka Raya. Selain itu, teknik dokumentasi dilakukan guna mendapatkan contoh data laporan yang telah diserahkan oleh dosen pada bidang terkait.

b. Analisis Sistem Berjalan

Hasil dari proses wawancara kemudian dilakukan analisis untuk mendapatkan gambaran proses bisnis atau prosedur pelaporan kinerja harian pada sistem berjalan pada saat ini. Alur sistem yang berjalan dapat dilihat pada gambar 2.

(5)

306 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

Gambar 2. Alur Sistem Berjalan c. Analisis Sistem Baru

Analisis sistem baru ini dilakukan sebagai komparasi dari sistem lama, sehingga akan menghasilkan alur kinerja baru yang lebih baik dari sistem lama dan menjadi acuan pada saat pengembangan desain sistem informasi pada Elaboration Phase. Alur sistem baru dapat dilihat pada gambar 3.

(6)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 307

Gambar 3. Alur Sistem Baru

d. Analisis Kebutuhan Sistem

Berdasarkan hasil analisis dan pengumpulan data didapatkan kebutuhan fungsionalitas sistem dan kebutuhan non fungsionalitas sistem yang diharuskan terdapat pada sistem untuk kemudian dijadikan pondasi sistem pada Constrution Phase. Hasil analisis kebutuhan sistem ini dibagi menjadi 2 (dua) yakni kebutuhan fungsionalitas ssitem yang dapat dilihat pada tabel 1 dan kebutuhan non fungsionalitas ssitem yang dapat dilihat pada tabel 2.

Tabel 1. Analisis Kebutuhan Fungsionalitas Sistem No Kebutuhan Fungsionalitas Sistem (KFS)

1 Sistem mampu memverifikasi proses login sesuai role user (dosen, verifikator, administrator)

2 Sistem menyediakan fungsi pengajuan kinerja harian dosen secara real time

3 Sistem mampu menampilkan data kinerja harian dosen yang telah dan yang sedang dilaporkan

4 Sistem mampu menyediakan fitur verikasi data yang dilakukan oleh verifikator (disetujui, ditolak)

5 Sistem menyediakan fungsi pencetakan data kinerja harian dosen 6 Sistem menyediakan fungsi penggantian profil user dan password

(7)

308 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

Tabel 2. Analisis Kebutuhan Non Fungsionalitas Sistem No Kebutuhan Non Fungsionalitas Sistem (KNFS)

1 Sistem mampu menangani penginputan data pelaporan kinerja harian dosen maksimal 500 data per hari

2 mampu mendapatkan data kinerja yang disetujui dan yang ditolak ataupun yang sedang diajukan/dilaporkan

3 Sistem memastikan bahwa data yang dilaporkan sesuai dengan tanggal real time.

4 Memiliki fitur search 5 Memiliki fitur manual user 3.2 Elaboration Phase

Pada tahapan ini dilakukan pengembangan desain sistem atau model dengan menggunakan UML, yakni use case diagram [13], activity diagram, class diagram, dan sequence diagram.

a. Use Case Diagram

Pada diagram ini menggambarkan hubungan penguna (actor) dengan sistem yang akan dikembangkan. Desain use case diagram dapat dilihat pada gambar 4.

Gambar 4. Use Case Diagram b. Activity Diagram

Diagram ini menjelasakan aktifitas-aktifitas dari setiap proses pengajuan atau pelaporan kinerja harian dosen dari sisi dosen, sistem/apps/software dan dari sisi verifikator data.

Desain model activity diagram dapat dilihat pada gambar 5.

(8)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 309

Gambar 5. Activity Diagram c. Class Diagram

Diagram ini akan menggambarkan atau mendeskripisikan hubungan antar class dan aliran data yang terdapat pada class-class tersebut. Desain model class diagram dapat dilihat pada gambar 6.

Gambar 6. Class Diagram

(9)

310 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

d. Sequence Diagram

Diagram ini menjelasakan mengenai kolaborasi, interaksi dan komunikasi antar objek.

Desain model sequence diagram dapat dilihat pada gambar 7.

Gambar 7. Sequence Diagram 3.3 Constrution Phase

Pada tahap ini dilakukan proses software development dengan memperhatikan pada fase- fase sebelumnya sehingga semua kebutuhan sistem yang ada telah sesuai dengan semestinya.

a. Software Development Preparation

Pada proses ini, digunakan beberapa framework programming dan beberapa tools pendukung yaitu menggunakan Framework Code Igniter, Framework React JS, Mysql Database, Xampp server, Visual Studio Code, Web Browser (Microsoft Edge dan Google Chrome), dan Figma sebagai UI designer.

b. User Interface Design

Berdasarkan fase pemodelan, dibuatlah rancangan user interface sistem. Desain antar muka/

user interface mengacu pada kebutuhan sistem yang telah di analisis pada tabel 1 dan 2.

1) Form Input Kinerja Harian Dosen

Pada halaman ini digunakan dosen untuk melakukan input data kinerja hariannya.

(10)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 311

Gambar 8. Form Input Kinerja Harian Dosen 2) Data Kinerja Harian Dosen

Pada halaman ini merupakan halaman yang berisi data kinerja harian dosen yang disertai dengan status validasinya.

Gambar 9. Data Kinerja Harian Dosen 3) Verifikasi Data Kinerja Harian

Halaman ini merupakan halaman yang berisikan semua data kinerja harian dosen yang kemudian dilakukan verifikasi oleh verifikator.

(11)

312 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

Gambar 10. Desain Verifikasi Data Kinerja Harian UI c. Testing Design

Pengujian perangkat lunak dilakukan dengan menggunakan pengujian Black Box Testing dengan teknik pengujian Equivalence Partitioning. Pengujian yang dilakukan berfokus pada pengujian persyaratan fungsionalitas perangkat lunak. Diharapkan dengan pengujian ini semua fungsionalitas sitem yang diminta oleh stakeholder dapat terrealisasi dan bekerja secara semestinya.

Untuk itu diperlukan serangkaian butir uji coba menggunakan teknik Equivalence Partitioning. Perencanaan pengujian sistem telihat pada seperti pada tabel 3.

Tabel 3. Rencana Pengujian Sistem

Butir Uji Valid Equivalence Invalid Equivalence

Poses Login

Username & password tidak kosong

Username & password kosomg Username & password

terdapat pada database

Username & password tidak terdapat pada database

Filter role user Role user sama Pelaporan Data

LKH

Form tidak boleh kosong Form boleh kosong

Tanggal data LKH real-time Tanggal data LKH tidak sesuai sistem

Data LKH

Data LKH sesuai status pelaporan (disetuji, ditolak, diajukan)

Data LKH tidak terfilter sesuai status LKH

Verifikasi Data LKH

Data LKH disetuji, ter-update disetujui

Data LKH tidak ter-update Data LKH tidak disetuji, ter- Data LKH tidak ter-update

(12)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 313

Butir Uji Valid Equivalence Invalid Equivalence update tidak disetujui

Cetak Data LKH

Range tanggal tidak boleh kosong

Range tanggal kosong

Data sesuai range tanggal Data tampil tidak sesuai range tanggal

Update Profil Form tidak kosong Form kosong Password harus diisi Password tidak diisi 3.4 Transition Phase

Pada fase ini dilakukan demonstrasi perangkat lunak yang telah dikembangkan kepada stakeholder untuk memastikan telah sesuai dengan kebutuhan fungsionalitas dan non fungsionalitas perangkat lunak yang telah di tentukan sebelumnya. Jika terdapat perbubahan atau penambahan permintaan fungsionalitas sistem akan dilakukan analisis apakah penambahan minor atau tidak. Jika penambahan bersifat minor akan dilakukan perbaikan rekayasa perangkat lunak sesuai dengan permintaan. Namun jika perubahan bersifat mayor (luas), maka akan dilakukan analisis ulang dengan stakeholder.

Proses selanjutnya adalah pembuatan dokumentasi perangkat lunak yang telah dibuat, dapat berupa soft file yang kemudian dibagikan ataupun disediakan melekat pada perangkat lunak. Berikutnya adalah proses instalasi sistem agar dapat digunakan oleh stakeholder sesuai dengan kebutuhan, dan diberikan pelatihan singkat untuk mengoperasikan perangkat lunak.

4. KESIMPULAN

Setelah dilakukan pengumpulan data terkait pelaporan kinerja harian dosen, dilakukan proses analisis dan perancangan sistem informasi. Kesimpulan pada penelitian ini adalah sebagai berikut: 1) Analisis dilakukan dengan mengacu pada hasil pengumpulan data dan mendengarkan permasalahan dari stakeholder. 2) Melakukan analisis sistem berjalan untuk memahami dan memberikan alur sistem baru kepada stakeholder. 3) Requirement analysis sistem atau perangkat lunak dilakukan untuk memudahkan dalam pengembangan perangkat lunak dengan menggunakan metode Agile Unified Process (AUP). 4) Melakukan desain perangkat lunak dengan menggunakan Unified Modelling Language (UML). 5) Sistem yang dikembangkan agar memudahkan dosen dalam pelaporan kinerja harian, dan diharapkan menghasilkan data yang tingkat validitasnya lebih baik sebab dilakukan setiap hari dan real-time serta dilakukan validasi oleh pejabat yang berwenang.

5. SARAN

Beberapa saran yang dapat dijadikan rujukan agar penelitian ini memiliki beberapa manfaat lebih kedepannya yaitu setiap kegaitan yang dilaporkan oleh dosen agar diberikan skor, dan menentukan batas skor untuk penentuan kinerja, sehingga proses pelaporan data kinerja dapat secara langsun memberikan hasil akhir kinerja.

(13)

314 Jatisi ISSN 2407-4322 Vol. 10, No. 2, Juni 2023, Hal. 302-315 E-ISSN 2503-2933

DAFTAR PUSTAKA

[1] G. Booch, R. A. Maksimchuk, M. W. Engle, B. J. Young, J. Connallen, and K. A.

Houston, Object-oriented analysis and design with applications, third edition, Vol. 33, No. 5. 2008. doi: 10.1145/1402521.1413138.

[2] B. Dathan, S. Ramnath, A. I. Approach, and S. Edition, Object-Oriented Analysis , Design and Implementation, Second Edi. New York: Spriger, 2015.

[3] R. A. Sukamto and M. Shalahuddin, Rekayasa Perangkat Lunak Terstruktur dan Berorientasi Objek. Bandung: Informatika, 2014.

[4] M. Al-Zewairi, M. Biltawi, W. Etaiwi, and A. Shaout, “Agile Software Development Methodologies: Survey of Surveys,” J. Comput. Commun., Vol. 05, No. 05, pp. 74–97, 2017, doi: 10.4236/jcc.2017.55007.

[5] O. Hazzan and Y. Dubinsky, Agile Software Engineering. London: Springer, 2008.

[6] M. Kropp, C. Anslow, A. Meier, and R. Biddle, “Satisfaction, Practices, and Influences In Agile Software Development,” ACM Int. Conf. Proceeding Ser., vol. Part F137700, 2018, doi: 10.1145/3210459.3210470.

[7] I. K. Raharjana, Pengembangan Sistem Informasi Menggunakan Metodologi Agile.

Yogyakarta: Deepublish, 2017.

[8] R. Kumar, P. Maheshwary, and T. Malche, “Inside Agile Family Software Development Methodologies,” Int. J. Comput. Sci. Eng., Vol. 7, No. 6, pp. 650–660, 2019, doi:

10.26438/ijcse/v7i6.650660.

[9] C. Edeki, “Agile Unified Process,” Int. J. Comput. Sci. Mob. Appl. IJCSMA, Vol. 1, pp.

13–17, 2013, [Online]. Available:

http://www.ijcsma.com/publications/september2013/V1I304.pdf

[10] Lisana, “Review On The Effectiveness of Agile Unified Process In Software Development With Vague System Requirements,” ARPN J. Eng. Appl. Sci., Vol. 9, No. 10, pp. 1763–

1768, 2014.

[11] S. W. Ambler, “The Agile Unified Process (AUP),”

https://www.ambysoft.com/unifiedprocess/agileUP.html (accessed Feb. 06, 2022), 2005.

[12] D. Yong, “Design and Practice of Software Architecture In Agile Development,” J. Phys.

Conf. Ser., Vol. 2074, No. 1, 2021, doi: 10.1088/1742-6596/2074/1/012008.

[13] N. Santos, J. Pereira, N. Ferreira, and R. J. Machado, “Modeling in Agile Software Development: Decomposing Use Cases Towards Logical Architecture Design,” in PROFES 2018 Product Focused Software Process Improvement, Springer, 2018, pp.

396–408. doi: 10.1007/978-3-030-03673-7_31.

(14)

Jatisi ISSN 2407-4322

Vol. 10, No. 2, Juni 2023, Hal. 302-315 E- ISSN 2503-2933 315

[14] R. Irawan and R. Kaestria, “Pemodelan Basis Data Dengan Pendekatan Model Data Berorientasi Objek Pada Native Apps Lokasi Tempat Ibadah di Kota Palangka Raya,” J.

Sains Komput. dan Teknol. Inf., Vol. 2, No. 2, pp. 36–43, 2020, doi:

10.33084/jsakti.v2i2.1479.

[15] B. G. Tavares, M. Keil, C. E. Sanches da Silva, and A. D. de Souza, “A Risk Management Tool for Agile Software Development,” J. Comput. Inf. Syst., Vol. 61, No. 6, pp. 561–570, 2021, doi: 10.1080/08874417.2020.1839813.