Fakultas Ilmu Komputer
2286
Analisis dan Perancangan Sistem Informasi Manajemen Pusat Laktasi :
Lactashare
Lia Ninda Safitri1, Satrio Agung Wicaksono2, Mochamad Chandra Saputra3 Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya
Email: 1lianindasafitri@gmail.com, 2satrio@ub.ac.id, 3andra@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 ICONIXsertahasil evaluasi dari traceability matrix dan correctness menunjukan bahwahasil 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
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
2.3Analisis 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.4Proses 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 domainmodel, 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).
2.5.1 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.
2.5.2 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.
2.5.3 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 2.6.1 Domain modelling
Domain modeling merupakan pemodelan awal untuk menemukan istilah (berupa kelas-kelas) 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)
2.6.2 Robustness Diagram
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 robustnessdiagram dan langkah yang mendeskripsikan use casetext. (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 domainmodel. 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
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
4.2.1 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.
Tabel1.Fitur Sistem
Kode Fitur Nama Fitur
FEAT-1 Tampil Informasi
FEAT-2 Mendaftar Sebagai Member
FEAT-3 Mendaftar Sebagai Resipien
FEAT-4 Mendaftar Sebagai Pendonor
FEAT-5 Identifikasi Pengguna
FEAT-6 Mengelola Data Admin
FEAT-7 Mengelola Data Konsultan
FEAT-8 Mengelola Data Member
FEAT-9 Mengelola Data Resipien
FEAT-10 Mengelola Data Pendonor
FEAT-11 Memvalidasi Pedaftaran Resipien
FEAT-12 Memvalidasi Pedaftaran Pendonor
FEAT-13 Mengelola Profil / Data Member
FEAT-14 Mengelola Data Donor ASI
FEAT-15 Mengelola Data Butuh ASI
FEAT-16 Mengelola Data Keluarga
FEAT-17 Konsultasi Online
FEAT-18 Mengelola Daftar Rekomendasi
Pendonor
FEAT-19 Melihat Profil Resipien
FEAT-20 Mengirim permintaan Donor ASI
FEAT-21 Melihat Profil Pendonor
FEAT-22 Memvalidasi Permintaan ASI
FEAT-23 Berkirim Pesan
FEAT-24 Tampilan Notifikasi
FEAT-25 Informasi Mahram
FEAT-26 Sertifikat ibu Persusuan
FEAT-27 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.
4.2.2 Domain Modeling
Pada domain modeling, teridentifikasi kata benda dan istilah (noun dan noun-phrase) pada fase functional requirement. Setelah istilah-istilah disaring didapatkan 40 domain. Domain model telah menjelaskan hubungan agregasi (has-a) dan generalisasi (is-a) dari obyek / istilah yang disebutkan.
4.2.3 Behavioral Requirement
Pada tahap ini telah dibangun GUI storyboard atau rancangan tampilan awal yang menggambarkan jalannya sistem.
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.
4.2.4 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.
4.3.1 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.
4.3.2 Memperbaharui Domain Model
Dalam tahap ini domainmodel 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 entityclass.
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
4.5.1Sequence Diagram
Diagramsequence 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 :
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.
4.5.2 Memperbaharui Domain Model
Hasil perbaharuan domainmodel 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 memvalidasipermintaan 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.
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 non-fungsional, use case dengan use casescenario, use case dengan robustness diagram dan sequencediagram.
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.
dan 28 sequencediagram.
5.2 Correctness
Gambar 11. Hasil (RP)
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(RP). 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.
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 sequencediagram.
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.
DAFTAR PUSTAKA
H.M., Jogiyanto, 1990. Analisis & Desain Sistem Informasi Pendekatan terstruktur Teori dan Praktek Aplikasi Bisnis, Yogyakarta : Andi Offset.
Leffingwell, D. 2002. The Role of Requirements Traceability in System Development, [Online]. Tersedia di : [http://www.unf.edu/~Broggio/cen6016/p rinted.RoleofRTinSystemDevelopment.R ationalEdge.Sep02.pdf]
Mahdi, F., A., Information Systems Analysis and
Design. [e-Book] <
http://www.uotechnology.edu.iq/dep-cs/mypdf/subjects/2is/2isad.pdf> > [Diakses: 22 Juli 2017]
Mili, Ali., Tchier, Farioruz., 2014. Software Testing Concepts And Operations. USA:Wiley
O’Brien, James A., Gorge M. Marakas, 2014. Sistem Informasi Manajemen Edisi 9 Buku 1. Jakarta : Salemba Empat.
Pertiwi, Bella, 2016. 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., 2010. Software Engineering
: A Practitioner’s Approach—7th ed, US : McGraw-Hill
Pusat Komunikasi Publik Sekretariat Kementrian Kesehatan Republik Indonesia. Tersedia di : http://www.depkes.go.id/article/print/160 81000002/beri-asi-sampai-2-tahun-untuk-wujudkan-keluarga-sehat.html
Rosenberg, D., Matt Stephens., 2007. Use Case
Driven Object Modeling with UML : Theory and Practice, New York : Apress
