Lia Ninda Safitri1 , Satrio Agung Wicaksono 2, Mochamad Chandra Saputra

  Vol. 2, No. 6, Juni 2018, hlm. 2286-2294 http://j-ptiik.ub.ac.id

  

Analisis dan Perancangan Sistem Informasi Manajemen Pusat Laktasi :

_{1 2,}

Lactashare

₃ Lia Ninda Safitri , Satrio Agung Wicaksono Mochamad Chandra Saputra

  Program Studi Sistem Informasi, Fakultas Ilmu Komputer, Universitas Brawijaya _{1 2 3} Email: lianindasafitri@gmail.com, satrio@ub.ac.id, 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

  pada tanggal 14 September 2015 mengatakan, 1. WHO merekomendasikan ASI eksklusif selama

   PENDAHULUAN

  6 bulan. Tetapi tidak semua ibu menyusui Dalam pidato Menteri Kesehatan RI yang memiliki kesempatan memberikan ASI eksluisf dibacakan oleh dr. Elizabeth Jane Soepardi, tersebut. Faktor yang mempengaruhi adalah ibu M.Epid. selaku direktur Bina Kesehatan Anak yang bekerja, tidak semua bayi mendapatkan

  Fakultas Ilmu Komputer Universitas Brawijaya

2286

• – 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).

  2.1 Kajian Pustaka

  2.2 Sistem Informasi

  bagaimana testing untuk pengujian perangkat lunak.

  Operation ”. Buku tersebut menjelaskan

  Penelitian terakhir dari Ali Mili dan Fariouz Tchier berjudul “Software Testing Concept and

  ”. Penelitian tersebut betujuan untuk membangun sistem informasi menggunakan OOP dan mengevaluasi dengan traceability matrix .

  Sistem Informasi Izin Lokasi (Siloka) Pada Dinas Cipta Karya Dan Tata Ruang Kabupaten Malang dengan Pendekatan Berorientasi Objek

  (2016) berjudul “Analisis dan Perancangan

  ICONIX secara keseluruhan dengan contoh kasus dan latihan. Penelitian selanjutnya dari Bella Pertiwi

  menjelaskan metode

  case Driven Object Modelling with UML Theory and Practice ”. Tujuan buku ini untuk

  Kajian pustaka yang digunakan pada penelitian ini adalah buku dari Doug Rosenberg and Matt Stephens (2007) yang berjudul “ use

  2. LANDASAN KEPUSTAKAAN

  inisiasi menyusui dini (IMD), produksi ASI tidak banyak, dan jumlah konselor laktasi sedikit.

  “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.

  Maka dengan latar belakang yang telah dijabarkan penulis tertarik untuk melakukan penelitian dengan judul

  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.

  Requirement Traceability (RT) merujuk pada

  Penelusuran kebutuhan merupakan aktivitas yang penting dalam manajemen kebutuhan terutama pada proyek yang besar dan kompleks.

  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 meng atakan “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.”.

  analisys/preliminary design, preliminary design review, detail design, critical design review dan implementation .

  atau yang biasa disebut ICONIX. ICONIX terdiri dari 6 proses yaitu requirement,

  use case Driven Object Modeling with UML

  Untuk membangun sistem informasi terdapat konsep yang dibuat untuk dasar pembangunan sistem yaitu Software Development Life Cycle (SDLC). Salah satu metodologi SDLC adalah

  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.

  Faktor

  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.

  2.3 Analisis dan Desain Sistem Informasi

  model. Domain model sendiri akan menjadi class diagram seiring perancangan dibuat. Ketiga adalah behavioral requirement yang merupakan tahap pembuatan GUI

  2.6.2 Robustness Diagram Robustness diagram adalah hybrid diantara class diagram dan activity diagram. Robustness diagram adalah representasi bergambar dari

  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.1 Domain modelling Domain modeling merupakan pemodelan

  2.6 Unified Modelling Language

  ketiga yang akan ditinjau apakah sequence sesuai dengan kebutuhan dan use case.

  mengacu dengan robustness diagram dan use case serta pemberbaharuan domain model. Domain model dibersihkan sehingga menjadi class diagram . Yang selanjutnya pada milestone

  Tahap detailed design merupakan tahap dimana dibuatnya sequence diagram yang

  2.5.3 Detailed Design

  Yang selanjutnya pada milestone kedua yang akan ditinjau apakah robustness diagram sesuai sengan kebutuhan dan use case.

  diagram dan pemberbaharuan domain model.

  Tahap analysis / preliminary design merupakan tahap dimana dibuatnya robustness

  2.5.2 Analysis / Preliminary Design

  yaitu requirement review, dimana Proses kontrol terhadap kesesuaian use case dengan kebutuhan klien.

  storyboard, use case diagram dan use case scenario. Keempat adalah milestone pertama

  domain

  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.

  analisa kebutuhan dan fitur distem. Kedua adalah domain modeling yang menghasilkan

  Functional Requirement yang menghasilkan

  Tahap ini memiliki empat tahap yaitu yang

  2.5.1 Requirement

  Analysis / Preliminary Design, Milestone 2 : Preliminary Design Review (PDR), Detailed Design, dan Milestone 3: Critical Design Review (CDR).

  tahap ICONIX prosess yaitu Requirement,

  model dinamis yaitu use case, robustness analysis dan sequence diagram. Terdapat 6

  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

  Gambar 1. Proses ICONIX Sumber : Rosernberg & Stephens (2007)

  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).

   Use Case Driven Object Modelling with UML atau ICONIX prosess merupakan proses

  2.5 Use case Driven Object Modelling with UML (ICONIX Process)

  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.4 Proses Bisnis

  perilaku yang dijelaskan use case, menunjukan kelas dan perilaku sistem yang berpartisipasi. Setiap kelas diwakili ikon grafis. Robustness

  diagram membaca lebih banyak activity diagram atau flowchart . Ada korelasi langsung

  requirement review. Proses ICONIX selanjutnya

  Berikut adalah contoh pemodelan proses bisnis yang telah dibuat :

  Mendaftar menjadi member 2. Konsultasi 3. Member menjadi pendonor 4. Member menjadi resipien 5. Donor ASI

  menggambarkan proses bisnis saat ini dan yang akan diusulkan pada Lactashare. Proses bisnis yang telah diidentifikasi adalah : 1.

  Process Modelling Notation / BPMN untuk

  Analisis proses bisnis dilakukan dengan melakukan pemodelan menggunakan Bussiness

  4.1 Analisa Proses Bisnis

  4. ANALISIS DAN PERANCANGAN

  Terakhir adalah mengevaluasi analisis dan perancangan menggunakan traceability matrix dan correctness.

  telah sesuai maka dilanjutkan proses Detail design dengan membuat sequence diagram dan membersihkan domain model menjadi class diagram.

  milestone 2 : Preliminary Design Review. Jika

  adalah Analysis / Preliminary Design dimana pembuatan robustness diagram dilakukan dan memperbaharui domain model. Lanjut meninjau kesesuaian diagram dengan kebutuhan pada

  selanjutnya adalah perancangan dengan melewati metode ICONIX tahap selanjutnya yaitu behavioral requirement dan milestone 1 :

  1:1 antara alur dari aksi pada robustness diagram dan langkah yang mendeskripsikan use case text. (Rosernberg & Stephens, 2007)

  modeling. Kemudian tahap metodologi

  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

  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.

  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).

  2.8 Correctness

  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).

  Sumber : Leffingwell (2002)

  Gambar 2. Traceability matrix Fitur dengan use case

  kemampuan untuk mendeskripsikan dan mengikuti perkembangan kebutuhan awal hingga deskripsi kebutuhan akhir (Leffingwell dalam Pertiwi, 2016).

  Requirement Traceability (RT) merujuk pada

  Penelusuran kebutuhan merupakan aktivitas yang penting dalam manajemen kebutuhan terutama pada proyek yang besar dan kompleks.

  2.7 Traceability matrix

3. METODOLOGI

  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.

  Gambar 5 menunjukan perancangan

  Gambar 5. Rancangan Tampilan Daftar Member

  storyboard atau rancangan tampilan awal yang menggambarkan jalannya sistem.

  Pada tahap ini telah dibangun GUI

  4.2.3 Behavioral Requirement

  (has-a) dan generalisasi (is-a) dari obyek / istilah yang disebutkan.

  model telah menjelaskan hubungan agregasi

  Pada domain modeling, teridentifikasi kata benda dan istilah (noun dan noun-phrase) pada fase functional requirement. Setelah istilah- istilah disaring didapatkan 40 domain. Domain

  4.2.2 Domain Modeling

  Pada tabel 1 terlihat fitur fitur apa saja yang harus ada pada sistem yang disesuaikan dengan kebutuhan sistem yang telah di identifikasi sebelumnya.

  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

  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

4.2 Requirement

4.2.1 Functional Requirement

   1. 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

  Tabel

  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.

  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 tampilan form pendaftaran member, form dibuat berdasar kebutuhan dengan alur disesuaikan dengan proses bisnis Lactashare.

  Gambar 6. Use case Diagram

  berikutnya, yang menjelaskan alur sistem yang akan dibuat.

  diagram dibuat sehingga dapat dibersihkan menjadi class diagram.

  Proses dimana sequence diagram dibuat dan pemberbaharuan domain model setelah sequence

  4.5 Detail Design

  ASI karena diagram sebelumnya dianggap ambigu bagi pelanggan. Arah relasi diperbaharui dan penambahan entity yang kurang telah ditambahkan.

  robustness diagram memvalidasi permintaan

  Pada proses ini terdapat pembaharuan

  4.4 Milestone 2 : Preliminary Design Riview

  adalah teridentifikasi 14 entity class.

  domain yang telah diisi dengan atribut menjadi entity atau model dalam class diagram. Hasilnya

  telah dibuat maka terdapat data atau atribut yang dapat dimasukkan dalam domain model. Maka

  case Scenario dan Robustness Analysis yang

  Perbaharuan Berdasarkan pada use case, use

  4.3.2 Memperbaharui Domain Model Dalam tahap ini domain model diperbaharui.

  diagram suatu objek berbicara ke objek

  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

  Dalam gambar 8 terlihat Robustness

  Gambar 8. Robustness Diagram Memvalidasi Permintaan ASI

  diagram ini merupakan gambaran objek dari use case yang telah dibuat. Berikut adalah salah satu Robustness diagram yang telah dibuat :

  menggunakan Robustness diagram yang mana

  4.3.1 Robustness Diagram Robustness analysis pada penelitian

  Proses ini adalah proses pembuatan perancangan yang berdasar pada hasil proses sebelumnya. Pada proses ini dibuat robustness diagram dan memperbaharui domain model.

  4.3 Analysis and Preliminary Design

  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.

  requirement yaitu GUI storyboard, use case dan domain model di tinjau kembali dengan hasil functional requirement. Pihak yang meninjau

  Pada tahap ini hasil dari behavioral

  Gambar 7 merupakan use case diagram untuk package donor ASI. Terlihat gelembung (bubble) kasus dalam use case diagram yang dapat dilaksanakan oleh aktor.

  Gambar 7. Use case diagram Package Donor ASI

  package yaitu general, konsultasi, donor ASI, filter dan admin.

4.2.4 Milestone 1 = Requirement review

  4.5.1 Sequence Diagram Diagram sequence yang telah dibuat adalah

  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.

  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 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.

  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

  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

  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 case scenario,

  use case dengan robustness diagram dan sequence diagram.

  Gambar 10. Traceability matrix Fitur dengan use case

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.

  sequence diagram memiliki kerunutan dengan use case diagram yang telah dibuat. Maka 28 use case dapat dirunutkan ke 28 robustness diagram

  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. dan 28 sequence diagram.

  6. KESIMPULAN 1.

  Pada proses requirement terdapat emapat

5.2 Correctness

  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

  menghasilkan 28 use case. use case

  diagram 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 Gambar 11. Hasil (R P) diagram memvalidasi permintaan ASI

  Gambar 11 menjelaskan akhir evaluasi, karena diagram sebelumnya ambigu bagi terlihat fitur-fitur tersebut sangat sesuai (totally pelanggan.

  correctness ). Spesifikasi kebutuhan dimasukkan 6.

  Hasil evaluasi sistem menggunakan dalam himpunan R dan fitur-fitur yang dibuat

  traceability matrix menunjukan bahwa

  ditempatkan pada himpunan P. himpunan R dan setiap kebutuhan memiliki kode yang dapat himpunan P di iriskan dan akan menghasilkan dilacak ke dalam fitur, kebutuhan dan nilai dom(R

  P). setelah dilakukan evaluasi nilai

  diagram perancangan. Tinjauan dom(R P) = dom(R). Sesuai dengan teori

  menunjukkan bahwa alur pengguna sudah

  correctness maka fitur-fitur yang dibuat

  sesuai dengan alur pada spesifikasi dinyatakan memiliki proporsi total correctness / kebutuhan. Dari 13 aktivitas proses bisnis benar. dapat ditelusuri ke 14 fitur.Dari 16 kebutuhan fungsional dapat ditelusiri ke 26 fitur.Dari 26 fitur telah ditelusuri ke 28 use Driven Object Modeling with UML :

  case . Seluruh skenario pada use case Theory and Practice , New York : Apress

  memiliki keruntuan dengan masing-masing Weske,M.,2012.Business Process Management,

  use case yang bersangkutan. Dan 28 use Second Edition . London : Springer. 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.

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