Analisis dan Perancangan Sistem Informasi Manajemen Pusat Laktasi : Lactashare

Transkripsi

1 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer e-issn: X Vol. 2, No. 6, Juni 2018, hlm Analisis dan Perancangan Sistem Informasi Manajemen Pusat Laktasi : Lactashare Lia Ninda Safitri 1, Satrio Agung Wicaksono 2, Mochamad Chandra Saputra 3 Program Studi Sistem Informasi, 1 lianindasafitri@gmail.com, 2 satrio@ub.ac.id, 3 andra@ub.ac.id Abstrak Lactashare merupakan startup yang bergerak di bidang sosial. Tujuan startup ini membantu menyebarluaskan donor ASI di Indonesia mengingat cakupan ASI ekslusif di Indonesia belum sesuai target nasional yaitu sebesar 80%. Faktor yang mempengaruhi adalah ibu yang bekerja, tidak semua bayi mendapatkan inisiasi menyusui dini (IMD), produksi ASI tidak banyak, dan jumlah konselor laktasi sedikit. Untuk itu Lactashare membutuhkan suatu sistem informasi manajemen yang mendukung proses bisnisnya. Untuk membangun sistem informasi terdapat konsep yang dibuat untuk dasar pembangunan sistem yaitu Software Development Life Cycle (SDLC). Salah satu framework SDLC adalah Use Case Driven Object Modeling with UML atau yang biasa disebut ICONIX process. ICONIX terdiri dari enam proses. Penelitian ini menjelaskan bagaimana membangun sistem yang dibutuhkan Lactashare pada tahap menganalisis kebutuhan dan merancang sistem mengunakan ICONIX process. Evaluasi merupakan aktivitas penting dalam manajemen kebutuhan. Evaluasi yang digunakan adalah traceability matrix dan correctness. Traceability matrix merujuk pada kemampuan mendeskripsikan dan menelusuri perkembangan kebutuhan awal hingga deskripsi kebutuhan akhir. Correctness digunakan untuk melihat tingkat kebenaran fitur yang dibuat terhadap kebutuhan yang dijabarkan. Hasil dari penelitian ini adalah artefak-artefak yang dihasilkan dari tiap proses ICONIX serta hasil evaluasi dari traceability matrix dan correctness menunjukan bahwa hasil perancangan telah memenuhi kebutuhan sistem. Kata kunci: ICONIX, traceability matrix, correctness, analisis dan perancangan sistem. Abstract Lactashare is a startup in social movement.the startup aims to disseminate breastmilk donation in Indonesia because of the national exclusive breastmilk target 80% that has not been reached. It affected by several factors, such as working mother, no baby initial milking, low production of breastmilk, and the limited of lactation counselor. Therefore, Lactashare needs a management information system that support the business process. The concept needed to build system base in development of information system is Software Development Life Cycle (SDLC). One of SDLC framework is Use case Driven Object Modeling with UML or named as ICONIX. ICONIX consists of six process. This research provide an insight to build a system that support Lactashare in requrements analysis and system designing phase in ICONIX process. Evaluation is an important activity in Requirements management. Evaluations that used in this research are tracebilty matrix and Correctness. Tracebility matrix refers to the ability to describe and trace the Requirements growth from the start to the end. Correctness used to observe the correct level of a features that made to the described Requirements. The result of this research are artifact of every ICONIX process and traceability matrix and correctness show that design system is correct to the requirement. Keywords: ICONIX, tracebility matrix, correctness, analysis and design system 1. PENDAHULUAN Dalam pidato Menteri Kesehatan RI yang dibacakan oleh dr. Elizabeth Jane Soepardi, M.Epid. selaku direktur Bina Kesehatan Anak pada tanggal 14 September 2015 mengatakan, WHO merekomendasikan ASI eksklusif selama 6 bulan. Tetapi tidak semua ibu menyusui memiliki kesempatan memberikan ASI eksluisf tersebut. Faktor yang mempengaruhi adalah ibu yang bekerja, tidak semua bayi mendapatkan Fakultas Ilmu Komputer Universitas Brawijaya 2286

2 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2287 inisiasi menyusui dini (IMD), produksi ASI tidak banyak, dan jumlah konselor laktasi sedikit. Faktor faktor tersebut menyebabkan cakupan ASI ekslusif di Indonesia belum sesuai target nasional sebesar 80%. Dilaporkan dari SDKI 2012 bahwa pencapaian ASI eklusif hanya mencapai 42%. Sedangkan laporan dari Dinas Kesehatan Provinsi tahun 2013, cakupan pemberian ASI 0 6 bulan hanya mencapai 54,5% (Pusat Komunikasi Publik Sekertariat Kementrian Kesehatan Republik Indonesia, 2015). Maka dari itu, dr. Meralda Nindyasti Eka Budiastutie membuat startup bernama Lactashare untuk membantu menyebarluaskan Donor ASI di Indonesia. Lactashare sendiri membutuhkan suatu sistem informasi yang membantu proses pendaftaran pendonor ASI, kesepakatan pendomor dan penerima ASI, hingga pengiriman ASI yang disesuaikan dengan keadaan Indonesia. Untuk membangun sistem informasi terdapat konsep yang dibuat untuk dasar pembangunan sistem yaitu Software Development Life Cycle (SDLC). Salah satu metodologi SDLC adalah use case Driven Object Modeling with UML atau yang biasa disebut ICONIX. ICONIX terdiri dari 6 proses yaitu requirement, analisys/preliminary design, preliminary design review, detail design, critical design review dan implementation. Dalam membangun sistem informasi, dibutuhkan analisis kebutuhan. Kebutuhan disesuaikan dengan kebutuhan proses, proyek, produk, dan orang-orang yang melakukan pekerjaan. Kebutuhan perangkat lunak membangun jembatan untuk perancangan dan konstruksi (Pressman, 2010 hal.120). Setelah analisis dilakukan, perlu adanya perancangan yang sesuai dengan analisa tersebut. Perancangan ditujukan untuk memudahkan membangun solusi dari masalah dengan tujuan memenuhi kebutuhan dan kebutuhan perangkat lunak. Menurut Pressman (2010) dalam bukunya Software Engineering Practitioner s Approach mengatakan Kita semua ingin membangun perangkat lunak untuk membuat hal-hal yang lebih baik, menghindari hal-hal buruk yang selalu mengintai dalam bayang-bayang saat upaya kita mengalami kegagalan. Untuk berhasil kita harus disiplin ketika merancang dan membangun perangkat lunak. Kita perlu pendekatan rekayasa.. Penelusuran kebutuhan merupakan aktivitas yang penting dalam manajemen kebutuhan terutama pada proyek yang besar dan kompleks. Requirement Traceability (RT) merujuk pada kemampuan untuk mendeskripsikan dan menelusuri perkembangan kebutuhan awal hingga deskripsi kebutuhan akhir (Leffingwell dalam Pertiwi, 2016). Kemudian evaluasi analisis kebutuhan dan perancangan selanjutnya adalah correctness, correctness digunakan untuk melihat tingkat kebenaran fitur yang dibuat terhadap kebutuhan yang dijabarkan. Maka dengan latar belakang yang telah dijabarkan penulis tertarik untuk melakukan penelitian dengan judul Analisis dan Perancangan Sistem Informasi Manajemen Pusat Laktasi : Lactashare. Diharapkan dengan penelitian ini untuk membantu memberikan solusi jawaban untuk pembangunan awal Donor ASI digital di Lactashare untuk Indonesia. 2. LANDASAN KEPUSTAKAAN 2.1 Kajian Pustaka Kajian pustaka yang digunakan pada penelitian ini adalah buku dari Doug Rosenberg and Matt Stephens (2007) yang berjudul use case Driven Object Modelling with UML Theory and Practice. Tujuan buku ini untuk menjelaskan metode ICONIX secara keseluruhan dengan contoh kasus dan latihan. Penelitian selanjutnya dari Bella Pertiwi (2016) berjudul Analisis dan Perancangan Sistem Informasi Izin Lokasi (Siloka) Pada Dinas Cipta Karya Dan Tata Ruang Kabupaten Malang dengan Pendekatan Berorientasi Objek. Penelitian tersebut betujuan untuk membangun sistem informasi menggunakan OOP dan mengevaluasi dengan traceability matrix. Penelitian terakhir dari Ali Mili dan Fariouz Tchier berjudul Software Testing Concept and Operation. Buku tersebut menjelaskan bagaimana testing untuk pengujian perangkat lunak. 2.2 Sistem Informasi Menurut O Brien (2014), sistem informasi adalah kombinasi mengorganisir manusia, perangkat keras, perangkat lunak, jaringan komunikasi, sumber data, kebijakan dan prosedur terorganisasi yang menyimpan, mengambil, mengubah dan memisah informasi dalam sebuah organisasi.

3 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Analisis dan Desain Sistem Informasi Menurut Mahdi (2012) analisis dan desain sistem infromasi adalah metode yang digunakan oleh perusahaan untuk membuat dan memelihara sistem yang memelihara sistem bisnis yang mempunya fungsi dasar. 2.4 Proses Bisnis Proses bisnis adalah suatu kumpulan aktivitas atau pekerjaan terstruktur yang saling terkait untuk menyelesaikan suatu masalah tertentu atau yang menghasilkan produk atau layanan demi meraih tujuan tertentu. Menurut Weske (2012) bahwa proses bisnis merupakan serangkaian aktivitas yang dibentuk yang saling bekerjasama dalam sebuah organisasi dan lingkungan teknis. 2.5 Use case Driven Object Modelling with UML (ICONIX Process) Use Case Driven Object Modelling with UML atau ICONIX prosess merupakan proses yang mengacu pada use case. use case ditentukan pada awal pengembangan menjadi dasar dalam menentukan model serta perilaku dari sistem yang sedang dibangun (Rosernberg & Stephens, 2007). Gambar 1. Proses ICONIX Sumber : Rosernberg & Stephens (2007) Terlihat pada gambar 1 ICONIX prosess terdiri dari beberapa tahap, tiap tahap menghasilkan produk jadi yang selanjutnya digunakan dalam mengerjakan tahap berikutnya. Produk yang dihasilkan pada tiap tahap didokumentasikan untuk membantu proses pengembangan. Banyak iterasi yang terjadi pada saat melakukan domain model, analisa use case, dan sebagainya. Model statis yang dihasilkan terus diperbaiki secara bertahap dengan bantuan model dinamis yaitu use case, robustness analysis dan sequence diagram. Terdapat 6 tahap ICONIX prosess yaitu Requirement, Analysis / Preliminary Design, Milestone 2 : Preliminary Design Review (PDR), Detailed Design, dan Milestone 3: Critical Design Review (CDR) Requirement Tahap ini memiliki empat tahap yaitu yang Functional Requirement yang menghasilkan analisa kebutuhan dan fitur distem. Kedua adalah domain modeling yang menghasilkan domain model. Domain model sendiri akan menjadi class diagram seiring perancangan dibuat. Ketiga adalah behavioral requirement yang merupakan tahap pembuatan GUI storyboard, use case diagram dan use case scenario. Keempat adalah milestone pertama yaitu requirement review, dimana Proses kontrol terhadap kesesuaian use case dengan kebutuhan klien Analysis / Preliminary Design Tahap analysis / preliminary design merupakan tahap dimana dibuatnya robustness diagram dan pemberbaharuan domain model. Yang selanjutnya pada milestone kedua yang akan ditinjau apakah robustness diagram sesuai sengan kebutuhan dan use case Detailed Design Tahap detailed design merupakan tahap dimana dibuatnya sequence diagram yang mengacu dengan robustness diagram dan use case serta pemberbaharuan domain model. Domain model dibersihkan sehingga menjadi class diagram. Yang selanjutnya pada milestone ketiga yang akan ditinjau apakah sequence sesuai dengan kebutuhan dan use case. 2.6 Unified Modelling Language Domain modelling Domain modeling merupakan pemodelan awal untuk menemukan istilah (berupa kelaskelas) yang dipakai dalam sistem. Tujuannya adalah membuat semua orang mempunyai pandangan yang sama tentang permasalahan dengan istilah-istilah yang sama yang menjadi representasi benda-benda dan konsep-konsep dari dunia nyata. (Rosernberg & Stephens, 2007) Robustness Diagram Robustness diagram adalah hybrid diantara class diagram dan activity diagram. Robustness diagram adalah representasi bergambar dari perilaku yang dijelaskan use case, menunjukan

4 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2289 kelas dan perilaku sistem yang berpartisipasi. Setiap kelas diwakili ikon grafis. Robustness diagram membaca lebih banyak activity diagram atau flowchart. Ada korelasi langsung 1:1 antara alur dari aksi pada robustness diagram dan langkah yang mendeskripsikan use case text. (Rosernberg & Stephens, 2007) 2.7 Traceability matrix Penelusuran kebutuhan merupakan aktivitas yang penting dalam manajemen kebutuhan terutama pada proyek yang besar dan kompleks. Requirement Traceability (RT) merujuk pada kemampuan untuk mendeskripsikan dan mengikuti perkembangan kebutuhan awal hingga deskripsi kebutuhan akhir (Leffingwell dalam Pertiwi, 2016). Gambar 2. Traceability matrix Fitur dengan use case Sumber : Leffingwell (2002) Gambar Traceability matrix menunjukan penelusuran antara kebutuhan dan definisi sistem dengan rancangan, implementasi dan test case. Penelusuran bisa dilakukan dari kebutuhan pengguna dengan fitur sistem, penelusuran fitur dengan persyaratan sistem, penelusuran fitur dengan use case, penelusuran use case dengan skenario use case dan penelusuran use case dengan use case realization (Leffingwell, 2002). 2.8 Correctness Pengujian perangkat lunak ini adalah melihat kadidat sistem terhadap kebutuhan dan memeriksa apakah kandidat sistem tersebut memiliki fungsi yang sesuai dengan spesifikasi kebutuhannya (Mili & Tchier, 2014). 3. METODOLOGI Metodologi penelitian yang digunakan dalam penelitian ini terdapat beberapa langkah. Pertama studi literatur, dimana dilakukannya pengumpulan literature dan refensi yang dibutuhkan dari jurnal, buku maupun e-book untuk mendukung penelitian dengan penjelasan teori.kemudian pengumpulan data dengan metode wawancara, pengamatan / observasi dan studi pustaka. Daftar pertanyaan wawancara sendiri dan domain objective didapatkan dari buku dari Yogiyanto, H.M., dengan judul Analisis & Desain Sistem Informasi Pendekatan terstruktur Teori dan Praktek Aplikasi Bisnis" yang mereferensi "Joseph W. Wilkinson, Accounting and Information Systems dengan penyesuaian. Masuk pada tahap berikutnya yaitu analisa kebutuhan. Pada tahap ini dilakukan analisa proses bisnis dan masuk pada metode ICONIX proses pertama (Requirement), pada tahap bagian functional requirement dan domain modeling. Kemudian tahap metodologi selanjutnya adalah perancangan dengan melewati metode ICONIX tahap selanjutnya yaitu behavioral requirement dan milestone 1 : requirement review. Proses ICONIX selanjutnya adalah Analysis / Preliminary Design dimana pembuatan robustness diagram dilakukan dan memperbaharui domain model. Lanjut meninjau kesesuaian diagram dengan kebutuhan pada milestone 2 : Preliminary Design Review. Jika telah sesuai maka dilanjutkan proses Detail design dengan membuat sequence diagram dan membersihkan domain model menjadi class diagram. Terakhir adalah mengevaluasi analisis dan perancangan menggunakan traceability matrix dan correctness. 4. ANALISIS DAN PERANCANGAN 4.1 Analisa Proses Bisnis Analisis proses bisnis dilakukan dengan melakukan pemodelan menggunakan Bussiness Process Modelling Notation / BPMN untuk menggambarkan proses bisnis saat ini dan yang akan diusulkan pada Lactashare. Proses bisnis yang telah diidentifikasi adalah : 1. Mendaftar menjadi member 2. Konsultasi 3. Member menjadi pendonor 4. Member menjadi resipien 5. Donor ASI Berikut adalah contoh pemodelan proses bisnis yang telah dibuat :

5 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2290 Gambar 3. Proses Bisnis Donor ASI Saat Ini Gambar 4. Proses Bisnis Usulan Donor ASI Terlihat perbedaan alur yang terjadi dari gambar 3 dan 4. Gambar 3 merupakan proses donor ASI yang terjadi pada saat ini. Dan gambar 4 tentang proses bisnis usulan serta aktivitas-aktivitas yang difasilitasi oleh sistem. 4.2 Requirement Functional Requirement Telah dilakukan identifikasi aktor serta analisis dan spesifikasi kebutuhan sistem. Dan didapatkan enam aktor dari identifikasi aktor tersebut yaitu Pengguna, Member, Pendonor, Resipien, Admin, Konsultan Hasil dari analisis dan spesifikasi kebutuhan adalah terdefinisinya 16 kebutuhan fungsional yang berdasar pada proses bisnis usulan, 40 spesifikasi kebutuhan fungsional, 1 kebutuhan non-fungsional dan 27 fitur dengan 56 rincian fitur. Kode Fitur FEAT-1 FEAT-2 FEAT-3 FEAT-4 FEAT-5 FEAT-6 FEAT-7 FEAT-8 FEAT-9 FEAT-10 Tabel 1. Fitur Sistem Nama Fitur Tampil Informasi Mendaftar Sebagai Member Mendaftar Sebagai Resipien Mendaftar Sebagai Pendonor Identifikasi Pengguna Mengelola Data Admin Mengelola Data Konsultan Mengelola Data Member Mengelola Data Resipien Mengelola Data Pendonor FEAT-11 FEAT-12 FEAT-13 FEAT-14 FEAT-15 FEAT-16 FEAT-17 FEAT-18 FEAT-19 FEAT-20 FEAT-21 FEAT-22 FEAT-23 FEAT-24 FEAT-25 FEAT-26 FEAT-27 Memvalidasi Pedaftaran Resipien Memvalidasi Pedaftaran Pendonor Mengelola Profil / Data Member Mengelola Data Donor ASI Mengelola Data Butuh ASI Mengelola Data Keluarga Konsultasi Online Mengelola Daftar Rekomendasi Pendonor Melihat Profil Resipien Mengirim permintaan Donor ASI Melihat Profil Pendonor Memvalidasi Permintaan ASI Berkirim Pesan Tampilan Notifikasi Informasi Mahram Sertifikat ibu Persusuan Keandalan Sistem Pada tabel 1 terlihat fitur fitur apa saja yang harus ada pada sistem yang disesuaikan dengan kebutuhan sistem yang telah di identifikasi sebelumnya Domain Modeling Pada domain modeling, teridentifikasi kata benda dan istilah (noun dan noun-phrase) pada fase functional requirement. Setelah istilahistilah disaring didapatkan 40 domain. Domain model telah menjelaskan hubungan agregasi (has-a) dan generalisasi (is-a) dari obyek / istilah yang disebutkan Behavioral Requirement Pada tahap ini telah dibangun GUI storyboard atau rancangan tampilan awal yang menggambarkan jalannya sistem. Gambar 5. Rancangan Tampilan Daftar Member Gambar 5 menunjukan perancangan

6 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2291 tampilan form pendaftaran member, form dibuat berdasar kebutuhan dengan alur disesuaikan dengan proses bisnis Lactashare. Gambar 6. Use case Diagram Gambar 6 merupakan use case yang telah dibuat. Setelah itu use case dengan ICONIX oleh Doug Rosenberg dan Matt Stephen, di organisir ke dalam package. Pengelompokan use case ke dalam package berdasarkan pada fungsi-fungsi yang memiliki kesamaan tujuan. Hasil dari pengelompokkan tersebut adalah terdapat 5 package yaitu general, konsultasi, donor ASI, filter dan admin. Gambar 7. Use case diagram Package Donor ASI Gambar 7 merupakan use case diagram untuk package donor ASI. Terlihat gelembung (bubble) kasus dalam use case diagram yang dapat dilaksanakan oleh aktor Milestone 1 = Requirement review Pada tahap ini hasil dari behavioral requirement yaitu GUI storyboard, use case dan domain model di tinjau kembali dengan hasil functional requirement. Pihak yang meninjau dari tiga elemen yaitu pelanggan (customer), pihak pemasaran (marketing), dan pengguna akhir (end user). Hasil yang didapatkan adalah pembaharuan functional requirement dan pada GUI storyboard terutama pada UX dan penambahan rancangan tampilan untuk memastikan permintaan ASI yang kita kirim. 4.3 Analysis and Preliminary Design Proses ini adalah proses pembuatan perancangan yang berdasar pada hasil proses sebelumnya. Pada proses ini dibuat robustness diagram dan memperbaharui domain model Robustness Diagram Robustness analysis pada penelitian menggunakan Robustness diagram yang mana diagram ini merupakan gambaran objek dari use case yang telah dibuat. Berikut adalah salah satu Robustness diagram yang telah dibuat : Gambar 8. Robustness Diagram Memvalidasi Permintaan ASI Dalam gambar 8 terlihat Robustness diagram suatu objek berbicara ke objek berikutnya, yang menjelaskan alur sistem yang akan dibuat Memperbaharui Domain Model Dalam tahap ini domain model diperbaharui. Perbaharuan Berdasarkan pada use case, use case Scenario dan Robustness Analysis yang telah dibuat maka terdapat data atau atribut yang dapat dimasukkan dalam domain model. Maka domain yang telah diisi dengan atribut menjadi entity atau model dalam class diagram. Hasilnya adalah teridentifikasi 14 entity class. 4.4 Milestone 2 : Preliminary Design Riview Pada proses ini terdapat pembaharuan robustness diagram memvalidasi permintaan ASI karena diagram sebelumnya dianggap ambigu bagi pelanggan. Arah relasi diperbaharui dan penambahan entity yang kurang telah ditambahkan. 4.5 Detail Design Proses dimana sequence diagram dibuat dan pemberbaharuan domain model setelah sequence diagram dibuat sehingga dapat dibersihkan menjadi class diagram.

7 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer Sequence Diagram Diagram sequence yang telah dibuat adalah 28 buah yang utama. Istilah atau pemberian nama untuk entity, aktor dan boundary yang digunakan merupakan istilah yang telah dipakai dalam domain model yang telah dibuat. Alur sequence diagram mengikuti robustness diagram yang sebelumnya mengikuti use case scenario. Maka sequence diagram yang dibuat mengikuti use case scenario sebelumnya. Berikut adalah contoh sequence diagram yang telah dibuat : 5. EVALUASI 5.1 Traceability matrix Perunutan telah dilakukan dengan merunutkan proses bisnis dengan fitur, kebutuhan dengan fitur, fitur dengan use case, fitur / kebutuhan sistem dengan kebutuhan nonfungsional, use case dengan use case scenario, use case dengan robustness diagram dan sequence diagram. Gambar 9. Sequence Diagram Melihat Rekomendasi Pendonor Gambar 9 menggambarkan sequence diagram Melihat Rekomendasi Pendonor. Terdapat satu aktor, satu boundary, satu controller dan satu entity Memperbaharui Domain Model Hasil perbaharuan domain model pada tahap ini adalah penambahan fungsi-fungsi yang telah didefinisikan pada sequence diagram, serta penambahan domain yang baru muncul pada sequence. Sehingga terlihat entity, interface dan control class. Kemudian dibersihkan dan domain model dan menjadi 1 class diagram utuh. 4.6 Milestone 3 : Detail Design Riview Pada proses ini telah dilakukan peninjauan dari seorang programmer. Peninjauan telah dilakukan dengan memeriksa perancangan, dan didapatkan pemberharuan diagram sequence memvalidasi permintaan ASI. Perbedaan dengan diagram yang dibuat sebelumnya adalah terdapat fungsi deldonor() pada controller mengelola informasi mahram dan sertifikat. Fungsi ini berfungsi untuk menghapus data pada donor ASI karena permintaan donor ASI ditolak. Gambar 10. Traceability matrix Fitur dengan use case Gambar 10 menunjukan use case yang dibuat dan kolom menunjukan fitur yang yang dijabarkan. Tanda x menunjukan pemenuhan fitur oleh use case yang dibuat. Dan tidak ada baris yang kosong (semua baris terisi x). Hal ini menunjukkan bahwa semua fitur terpenuhi kebutuhannya oleh use case. Dari hasil semua traceability matrix dapat dianalisis bahwa fitur dan bisnis proses memiliki kerunutan antara aktivitas pada pemodelan proses bisnis dengan pendefinisian fitur. Dari 13 aktivitas proses bisnis dapat ditelusuri ke 14 fitur. Seluruh fitur dapat dikaitkan dengan kebutuhan dan tidak terdapat definisi fitur yang tidak berasal dari kebutuhan dan pengguna. Dari 16 kebutuhan fungsional dapat ditelusiri ke 26 fitur. Pendefinisian use case mendukung fitur dari yang sudah didefinisikan sebelumnya. Dari 26 fitur telah ditelusuri ke 28 use case. Seluruh skenario pada use case memiliki keruntuan dengan masing-masing use case yang bersangkutan. Robustness diagram dan sequence diagram memiliki kerunutan dengan use case diagram yang telah dibuat. Maka 28 use case dapat dirunutkan ke 28 robustness diagram

8 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2293 dan 28 sequence diagram. 5.2 Correctness Gambar 11. Hasil (R P) Gambar 11 menjelaskan akhir evaluasi, terlihat fitur-fitur tersebut sangat sesuai (totally correctness). Spesifikasi kebutuhan dimasukkan dalam himpunan R dan fitur-fitur yang dibuat ditempatkan pada himpunan P. himpunan R dan himpunan P di iriskan dan akan menghasilkan nilai dom(r P). setelah dilakukan evaluasi nilai dom(r P) = dom(r). Sesuai dengan teori correctness maka fitur-fitur yang dibuat dinyatakan memiliki proporsi total correctness / benar. 6. KESIMPULAN 1. Pada proses requirement terdapat emapat tahap. Yaitu tahap functional requirement, behavioral requirement, dan milestone 1 : requirement review. Tahap functional requirement menghasilkan 16 kebutuhan fungsional yang berdasar pada proses bisnis usulan yang telah dibuat, 40 spesifikasi kebutuhan fungsional, satu kebutuhan non-fungsional dan 27 fitur dengan 56 rincian fitur. Tahap domain modeling menghasilkan 40 domain. Tahap behavioral requirement yang menghasilkan GUI storyboard, use case package dan use case scenario. use case diagram menghasilkan 28 use case. use case package diagram menghasilkan 5 package usecase diagram. Dan hasil dari use case scenario adalah 28 skenario. Pada tahap milestone 1 : requirement riview Terdapat tinjauan lanjut dari ketiga element dan telah diperbaiki. 2. Tahap analisys / preliminary design menghasilkan 28 robustnest diagram. Kemudian memperbaharui domain modeling dengan memasukkan atribut yang telah disebutkan pada use case scenario dan robustness diagram, serta penambahan domain baru yang muncul setelah robustness dibuat. 3. Hasil dari tahap milestone 2 : preliminary design riview adalah pembaharuan robustness diagram memvalidasi permintaan ASI karna diagram, sebelumnya ambigu bagi pelanggan. 4. Tahap detail design membuat sequence diagram menghasilkan 28 sequence diagram. Dan di akhir domain model di bersihkan mengasilkan class diagram. 5. Hasil dari tahap milestone 3 : critical design riview adalah pembaharuan robustness diagram memvalidasi permintaan ASI karena diagram sebelumnya ambigu bagi pelanggan. 6. Hasil evaluasi sistem menggunakan traceability matrix menunjukan bahwa setiap kebutuhan memiliki kode yang dapat dilacak ke dalam fitur, kebutuhan dan diagram perancangan. Tinjauan menunjukkan bahwa alur pengguna sudah sesuai dengan alur pada spesifikasi kebutuhan. Dari 13 aktivitas proses bisnis dapat ditelusuri ke 14 fitur.dari 16 kebutuhan fungsional dapat ditelusiri ke 26

9 Jurnal Pengembangan Teknologi Informasi dan Ilmu Komputer 2294 fitur.dari 26 fitur telah ditelusuri ke 28 use case. Seluruh skenario pada use case memiliki keruntuan dengan masing-masing use case yang bersangkutan. Dan 28 use case dapat dirunutkan ke 28 robustness diagram dan 28 sequence diagram. Hasil evaluasi dengan correctness menunjukan bahwa setiap kebutuhan sistem mendukung fitur dan juga sebaliknya. Maka sesuai dengan prasyarat rumus correctness dengan tipe proporsisi total correctness atau benar. Driven Object Modeling with UML : Theory and Practice, New York : Apress Weske,M.,2012.Business Process Management, Second Edition. London : Springer. DAFTAR PUSTAKA H.M., Jogiyanto, Analisis & Desain Sistem Informasi Pendekatan terstruktur Teori dan Praktek Aplikasi Bisnis, Yogyakarta : Andi Offset. Leffingwell, D The Role of Requirements Traceability in System Development, [Online]. Tersedia di : [ rinted.roleofrtinsystemdevelopment.r ationaledge.sep02.pdf] Mahdi, F., A., Information Systems Analysis and Design. [e-book] < > [Diakses: 22 Juli 2017] Mili, Ali., Tchier, Farioruz., Software Testing Concepts And Operations. USA:Wiley O Brien, James A., Gorge M. Marakas, Sistem Informasi Manajemen Edisi 9 Buku 1. Jakarta : Salemba Empat. Pertiwi, Bella, Analisis Dan Perancangan Sistem Informasi Izin Lokasi (Siloka) Pada Dinas Cipta Karya Dan Tata Ruang Kabupaten Malang Dengan Pendekatan Berorientasi Objek, S1. Universitas Brawijaya. Pressman, Roger S., Software Engineering : A Practitioner s Approach 7th ed, US : McGraw-Hill Pusat Komunikasi Publik Sekretariat Kementrian Kesehatan Republik Indonesia. Tersedia di : /beri-asi-sampai-2-tahununtuk-wujudkan-keluarga-sehat.html Rosenberg, D., Matt Stephens., Use Case