Tambahan Class Diagram

CLASS DIAGRAM

PENDAHULUAN
Sejarah UML
Unified Modelling Language (UML) adalah sebuah “bahasa” yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem.
Banyak Perangkat Lunak yang mendukung pembuatan diangram UML contohnya:
1. StarUML
2. Acceleo
3. ArgoUML
Namun software yang dipakai Lab.Informatika Universitas Gunadarma adala star UML.
StarUML adalah sebuah proyek open source untuk mengembangkan cepat, fleksibel, extensible, featureful, dan bebas-tersedia UML / platform MDA berjalan pada platform Win32.Tujuan dari proyek StarUML adalah untuk membangun sebuah alat pemodelan perangkat lunak dan juga platform yang menarik adalah pengganti alat UML komersial seperti Rational Rose, Bersama dan sebagainya.


Kemudian pilih empty project, pilih model, add dan klik model



Pilih model, add diagram dan klik class diagram



Maka akan muncul komponen-komponen class diagram disamping kiri layar

Gambar.tampilan awal

Class diagram adalah diagam yang digunakan untuk menampilkan beberapa kelas serta paket-paket yang ada dalam sistem/perangkat lunak yang sedang kita gunakan.
Class diagram memberi kita gambaran (diagram statis) tentang sistem/perangkat lunak dan relas-relasi yang ada didalamnya.

Definisi Class DiagramClass adalah kumpulan objek-objek dengan dan yang mempunyai struktur umum, behavior umum, relasi umum, dan semantic/kata yang umum. Class-class ditentukan/ditemukan dengan cara memeriksa objek-objek dalam sequence diagram dan collaboration diagram. Sebuah class digambarkan seperti sebuah bujur sangkar dengan tiga bagian ruangan. Class sebaiknya diberi nama menggunakan kata benda sesuai dengan domain/bagian/kelompoknya (Whitten L. Jeffery et al, 2004).

Class Diagram adalah diagram yang menunjukan class-class yang ada dari sebuah sistem dan hubungannya secara logika. Class diagram menggambarkan struktur statis dari sebuah sistem. Karena itu class diagram merupakan tulang punggung atau kekuatan dasar dari hampir setiap metode berorientasi objek termasuk UML (Henderi, 2008). Sementara menurut (Whitten L. Jeffery et al 2004:432) class diagram adalah gambar grafis mengenai struktur objek statis dari suatu sistem, menunjukan class-class objek yang menyusun sebuah sistem dan juga hubungan antara class objek tersebut.

Elemen-eleman class diagram dalam pemodelan UML terdiri dari: Class-class, struktur class, sifat class (class behavior), perkumpulan/gabungan (association), pengumpulan/kesatuan (agregation), ketergantungan (dependency), relasi-relasi turunannya, keberagaman dan indikator navigasi, dan role name (peranan/tugas nama).
Simbol-simbol class diagram
1. Class: Class adalah blok - blok pembangun pada pemrograman berorientasi obyek.Sebuah class digambarkan sebagai sebuah kotak yang terbagi atas 3 bagian. Bagian atas adalah bagian nama dari class. Bagian tengah mendefinisikan property/atribut class. Bagian akhir mendefinisikan methodmethod dari sebuah clas.


2. Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many).


3. Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid.


4. Dependency : Kadangkala sebuah class menggunakan class yang lain. Hal ini disebut dependency. Umumnya penggunaan dependency digunakan untuk menunjukkan operasi pada suatu class yang menggunakan class yang lain. Sebuah dependency dilambangkan sebagai sebuah panah bertitik-titik.


5. Aggregation : Aggregation mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi.





Keterangan:
• Class / table departemen memiliki ber-Agregasi dengan class / table pegawai,alasannya karena departemen dapat berdiri sendiri tanpa ada pegawai tetapi kinerjanya tidak sempurna. Banyak pegawai dapat bekerja pada satu departemen jadi many to 1.
• Class/table transaksi tidak dapat berdiri sendiri tanpa adanya class/table produk. Begitu juga dengan table produk tidak bisa berdiri sendiri tanpa adanya departemen.
• Banyak pelanggan dapat melakukan banyak tansaksi
• 1 transaksi dapat mencakup banyak produk.

Read More

Membuat Use Case

Use Case Diagram adalah gambaran graphical dari beberapa atau semua actor, use case, dan interaksi diantaranya yang memperkenalkan suatu sistem. Use case diagram tidak menjelaskan secara detil tentang penggunaan use case, tetapi hanya memberi gambaran singkat hubungan antara usecase, aktor, dan sistem.Didalam use case ini akan diketahui fungsi - fungsi apa saja yang berada pada sistem yang dibuat.

Cara Membuat

Setelah membuka UMLet silahkan klik bagian kanan atas lalu pilih Use Case. lalu buatlah desain dengan cara men-drag komponen-komponen yang berada di kanan.   Berikut merupakan contoh dari Use Case Diagram Element - elemen pada Use Case Diagram Actor : Mempresentasikan seseorang atau sesuatu(seperti perangkat,sistem lain) yang berinteraksi dengan sistem.Actor hanya berinteraksi dengan use case tetapi tidak memiliki kontrol atas use case. Use Case : Adalah gambaran fungsionalitas dari suatu sistem, sehingga customer atau pengguna sistem paham dan mengerti mengenai kegunaan sistem yang akan dibangun. Association : Menghubungkan link antar element. <<Include>> : Yaitu kelakuan yang harus terpenuhi agar sebuah event dapat terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari use case lainnya.

Relasi Dalam Use Case

Ada beberapa relasi yang terdapat pada use case diagram: 1. Association, menghubungkan link antar element. 2. Generalization, disebut juga inheritance (pewarisan), sebuah elemen dapat  merupakan spesialisasi dari elemen lainnya. 3. Dependency, sebuah element bergantung dalam beberapa cara ke element lainnya. 4. Aggregation, bentuk assosiation  dimana sebuah elemen berisi elemen lainnya. Penjelasan Pada use case diatas, actornya adalah guru pendidik dan tenaga kependidikan. Tugas - tugas dari setiap actor berbeda-beda, dan dicantumkan pada use case yang ada. Tetapi, sebelum mereka bisa melakukan tugas tersebut ada include yang mengharuskan mereka untuk login kedalam system.

Read More

activity model Diagram

Tentang Activity Diagram

Activity diagram memiliki pengertian yaitu lebih fokus kepada menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses. Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis. Memiliki struktur diagram yang mirip flowchart atau data flow diagram pada perancangan terstruktur. Memiliki pula manfaat yaitu apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan. Dan activity dibuat berdasarkan sebuah atau beberapa use case pada use case diagram.

Terdapat beberapa hal penting yang harus diketahui, yaitu ;

• Activity mengambarkan sebuah pekerjaan atau tugas dalam workflow
• Pada UML, activity digambarkan dengan simbol kotak

• Start state dengan tegas menunjukan dimulainya suatu workflow pada sebuah activity diagram
• Hanya ada satu start state dalam sebuah workflow
• Pada UML, start state digambarkan dengan simbol lingkaran yang solid

• End state menggambarkan akhir atau terminal dari pada sebuah activity diagram
• Bisa terdapat lebih dari satu end state pada sebuah activity diagram
• Pada UML, end state digambarkan dengan simbol sebuah bull's eye

• State transition menunjukan kegiatan apa berikutnya setelah suatu kegiatan sebelumnya
• Pada UML, state transition digambarkan oleh sebuah solid line dengan panah

• Decision adalah suatu titik atau point pada activity diagram yang mengindikasikan suatu kondisi dimana ada kemungkinan perbedaan transisi
• Pada UML, decision digambarkan dengan sebuah simbol diamond

Swimlanes

Obyek swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu.

• Mulailah dengan node awal untuk titik awal. 
• Tambahkan partisi jika relevan untuk analisis yang dibuat. 
• Tambahkan aksi untuk setiap langkah utama dari use case. 
• Tambahkan alur dari setiap aksi ke aksi lain, keputusan atau node akhir. Setiap aksi hanya mendapat satu alur masuk dan satu alur keluar menuju ke forks, joins, decisions, dan merges. 
• Tambahkan decisions jika alur dipecah menjadi beberapa pilihan. Jangan lupa untuk menggabungkan kembali dengan merge. 
• Tambahkan forks dan joins jika aktivitas akan dilakukan secara paralel.

Contoh Activity Diagram

Studi kasus : Penarikan Uang dari Account Bank Melalui ATM

Read More

tugas pertemuan Ke 4 Mengenai UML

Pengertian Unified Modeling Language (UML)

Unified Modeling Language (UML)

Unified Modeling Language (UML) digunakan untuk melakukan pemodelan sistem/perangkat lunak dengan menggunakan tools yang ada. Dengan pemodelan menggunakan UML, rekayasa dan pengembangan perangkat dapat dilakukan dengan fokus pengembangan dan desain perangkat lunak terhadap:

1. Tinjauan umum bagaimana arsitektur sistem secara keseluruhan

2.  Penelaah bagaimana objek-objek dalam sistem saling mengirimkan pesan (message) dan saling bekerjasama satu sama lain

3.  Menguji apakah sistem/perangkat lunak sudah berfungsi seperti yang seharusnya

4. Dokumentasi sistem/perangkat lunak untuk keperluan-keperluan tertentu di masa yang akan datang

Setiap sistem yang komplek seharusnya bisa dipandang dari sudut pandang yang berbedabeda sehingga bisa dilakukan pemahaman secara menyeluruh. Dalam upaya-nya tersebut, UML menyediakan sembilan jenis diagram yang dapat dikelompokkan berdasarkan sifatnya yang statis ataupun dinamis. Kesembilan jenis diagram untuk UML adalah:

1.    Use-Case Diagram - bersifat statis, memperlihatkan himpunan use-case dan aktor-aktor. Diagram ini sangat penting terutama untuk memodelkan ataupun mengorganisasikan perilaku dari sistem yang dibutuhkan pengguna

2.     Class Diagram - bersifat statis tetapi sering pula memuat kelas-kelas aktif dan memperlihatkan himpunan kelas-kelas, antarmuka-antarmuka, kolaborasi-kolaborasi, serta relasi-relasi

3.   Statechart Diagram - bersifat dinamis yang memperlihatkan state – state dari sistem, memuat state, transisi, event, serta aktivitas. Penting untuk memperlihatkan sifat dinamis dari antarmuka (interface), kelas, kolaborasi, terutama penting pada pemodelan system-sistem yang reaktif

4.     Activity Diagram - bersifat dinamis. Merupakan tipe khusus dari diagram state yang memperlihatkan aliran dari suatu aktivitas ke aktivitas lainnya dalam suatu sistem

5.     Sequence Diagram - bersifat dinamis yang menekankan pada pengiriman pesan (message) dalam suatu waktu tertentu

6.      Collaboration Diagram - bersifat dinamis yang menekankan organisasi struktural dari objek-objek yang menerima serta mengirim pesan (message)

7.    Component Diagram - bersifat statis.diagram ini berhubungan dengan digram kelas dimana komponen secara tipical dipetakan ke dalam satu atau lebih kelas-kelas, antarmuka (interface) ataupun kolaborasi

8.      Diagram Objek - bersifat statis, memperlihatkan objek-objek serta serta relasi-relasi antar-objek. Selain itu juga memperlihatkan instansiasi statis dari segala sesuatu yang dijumpai pada diagram kelas

9.  Depeloyment Diagram - bersifat statis, diagram memperlihatkan konfigurasi saat aplikasi dijalankan (run-time). Digram ini sangat berguna saat aplikasi kita berlaku sebagai aplikasi yang dijalankan pada banyak mesin (distributed computing)

 

 

 

“Merancang Sistem Dengan UML: Mulai Dari Mana?”

Salah satu pertanyaan yang paling sering saya temukan dari para mahasiswa adalah apa saja step-step yang harus ditempuh dalam merancang sistem berbasis UML? Saya biasanya akan memperbaiki pertanyaan ini karena UML pada dasarnya hanya kumpulan diagram atau teknik visualisasi; UML tidak mendikte langkah-langkah pengembangan sistem! Lalu apa yang harus dilakukan dalam merancang sebuah sistem?
Saya yakin para mahasiswa telah memperoleh mata kuliah pengembangan sistem informasi sebelumnya, tapi kenapa mereka bertanya demikian disaat mereka harus merancang sistem yang nyata (misalnya untuk skripsi)? Salah satu penyebabnya adalah analisa & perancangan terlalu teoritis sehingga tidak mendukung implementasi/pembuatan kode program.
Dari beberapa buku analisa & perancangan yang saya baca, buku Use Case Driven Object Modeling with UML: Theory and Practice adalah salah satu buku yang spesial dan sangat membantu. Bukan hanya dilengkapi dengan humor, tetapi buku ini memberikan metode analisa & perancangan yang sangant berguna saat diterapkan dalam pembuatan kode program!   Buku yang memakai metode ICONIX Process ini ditulis oleh analyst yang memiliki latar belakang programmer.
Saya tahu bahwa sangat sulit merangkum sebuah buku 438 halaman dalam sebuah artikel blog, tapi saya ingin menunjukkan bahwa diagram UML hasil analisa & perancangan bukanlah sekedar basa basi yang dihasilkan analyst.   Dengan metode yang salah, analyst kerap terlihat tidak berguna di mata developer.   Metode yang salah juga menyebabkan mahasiswa lebih senang membuat kode program terlebih dahulu, baru melakukan reverse engineering untuk menghasilkan diagram UML.   Dengan kata lain, sistem dibuat tanpa analisas & perancangan, sementara diagram UML hanya produk sampingan yang menambah ketebalan skripsi tanpa fungsi yang sangat berarti.
Gambar berikut ini memperlihat proses analisa & perancangan sistem informasi dengan ICONIX process:

Proses analisa & perancangan sistem yang saya rangkum dari buku Use Case Driven Object Modeling With UML: Theory and Practice adalah sebagai berikut ini:

1. Membuat Functional Requirement

Gunakan Microsoft Word untuk menuliskan functional requirement (apa yang dapat dilakukan oleh sistem?).   Tahap ini melibatkan business analyst, pelanggan, end user, dan project stakeholders lainnya.  Functional requirement bersifat tidak terstruktur dan tidak dapat dipakai dalam perancangan secara langsung.
Berikut ini adalah contoh potongan dari function requirement untuk sebuah sistem bengkel motor yang sederhana:

Sistem harus dapat memproses work order untuk motor mulai dari antri, sedang dikerjakan 
oleh seorang mekanik, selesai di-servis, dan proses pembayaran. 
Sebuah work order memiliki informasi jenis pekerjaan dan sparepart yang dijual. 
Harga ongkos servis berdasarkan jenis pekerjaan dan tipe motor.

2. Membuat Domain Model (sederhana)

Salah satu fungsi domain model adalah menyamakan istilah yang akan pakai diproses selanjutnya.   Misalnya, apakah saya akan memakai istilah ‘work order’ atau ‘pekerjaan servis’?   Apa saya akan memakai sebutan ‘sparepart‘ atau ‘suku cadang‘?   Walau terlihat sepele, perbedaan istilah seringkali menimbulkan salah paham dalam komunikasi tim.
Pada tahap ini, domain model adalah class diagram yang hanya memakai relasi pewarisan (is-a/adalah sebuah) dan agregasi (has-a/memiliki sebuah).   Class diagram ini belum memiliki atribut dan operasi.   Nantinya, di proses selanjutnya, domain model akan diperbaiki dan dikembangkan menjadi lebih detail.
Gambar berikut ini memperlihatkan contoh domain model untuk functional requirement di langkah 1:

3. Membuat Use Case

Use case mendefinisikan behavioral requirements berdasarkan functional requirement (dan sumber lainnya).   Berbeda dengan anjuran dari buku analisis sisfo lain,  buku ini menyarankan untuk membuat use case dengan maksimal 2 paragraf!   Tidak perlu mengikuti template yang detail!   Sebuah use case yang panjang & detail malah akan memperlambat kita.   Tim yang membuat use case bisa jadi akhirnya hanya mengisi form yang kosong tanpa banyak berpikir panjang (misalnya sekedar copy paste) sehingga proses membuat use case hanya sekedar ritual tanpa analisa mendalam.
Kalimat yang dipakai dalam use case harus berupa kalimat aktif, misalnya “pengguna men-klik tombol Login”. Kalimat pasif seperti “Sistem menyediakan tombol Login” adalah ciri-ciri functional requirement dan bukan bagian dari use case.
Use case harus mengandung nama di domain model.   Dengan demikian, saya bisa menghubungkan class-class yang akan dirancang dengan use case.   Setiap halaman/layar yang direferensikan di dalam use case sebaiknya diberi nama yang konsisten, misalnya Halaman Tambah Sparepart atau Screen TambahSparepart.
Sebuah use case hampir mirip seperti dokumentasi sistem. Kita perlu menspesifikasikan seperti apa cara pakai sistem (termasuk respon sistem) sebelum sebuah sistem dibuat. Berikut ini adalah contoh use case diagram berdasarkan functional requirement di langkah 1 dan memakai domain model dari langkah 2:

Sebuah use case selain memiliki sunny-day scenario, sebaiknya juga memiliki rainy-day scenario (apa yang akan terjadi bila sesuatu salah?) atau alternatif. Sebagai contoh, berikut ini contoh use case scenario untuk use case diagram di atas:

Membuat WorkOrder baru
Basic Scenario
 Front Desk memilih Motor di Screen ListMotor dan men-klik tombol untuk membuat WorkOrder. 
 Sistem akan membuat sebuah WorkOrder baru dengan status sedang antri.
Alternate Scenario
 Motor belum terdaftar - Front Desk terlebih dahulu menambah Motor baru dengan 
    men-klik tombol untuk menambah Motor baru sebelum mengerjakan langkah 
    yang ada di Basic Scenario.
 Motor sudah memiliki WorkOrder yang sedang antri - Sistem akan menampilkan pesan kesalahan.
[Catatan: pada saat membuat use case ini, terlihat bahwa dibutuhkan use case menambah Motor. 
Agar ringkas, use case tersebut akan diabaikan.]

Mengubah Status WorkOrder menjadi sedang dikerjakan oleh Mekanik
Basic Scenario
 Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk 
 menandakan bahwa Workorder tersebut sedang dikerjakan. 
 Sistem akan menampilkan Screen PengerjaanWorkOrder. Front Desk memilih nama Mekanik 
 yang mengerjakan WorkOrder dan men-klik tombol untuk menyimpan perubahan. 
 Sistem akan mengubah status WorkOrder menjadi sedang dikerjakan 
 serta mencatat tanggal & jam mulai dikerjakan.
Alternate Scenario
 Status WorkOrder yang dipilih bukan sedang antri - Sistem akan menampilkan pesan kesalahan.

Menambah Sparepart yang dipakai selama pengerjaan WorkOrder
Basic Scenario
 Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder dan memilih menu untuk 
 menambah Sparepart di WorkOrder. Sistem akan menampilkan Screen TambahSparepart yang 
 berisi daftar Sparepart untuk WorkOrder yang dipilih. Disini Front Desk akan mengisi 
 data ItemSparepart dengan memilih Sparepart, memasukkan jumlah Sparepart, lalu men-klik 
 tombol Tambah ItemSparepart. Sistem akan memperbaharui daftar ItemSparepart di layar.
 Front Desk men-klik tombol Simpan untuk selesai. Sistem akan menyimpan perubahan Sparepart 
 pada WorkOrder terpilih.
Alternate Scenario
 Terdapat lebih dari satu jenis Sparepart yang perlu ditambahkan - Front Desk kembali 
   menambah data ItemSparepart. Setelah semua ItemSparepart selesai dimasukkan, Front Desk 
   men-klik tombol Simpan di Screen TambahSparepart. Sistem akan menyimpan perubahan.
 Status WorkOrder yang dipilih bukan sedang dikerjakan - Sistem akan menampilkan pesan 
   kesalahan.
[Catatan: pada saat membuat use case ini, terlihat bahwa ada yang kurang pada domain model, 
  yaitu ItemSparepart. Segera update domain model! Terlihat juga bahwa dibutuhkan sebuah 
  metode untuk menghapus Sparepart dan meng-edit jumlah Sparepart terpakai. 
  Agar ringkas, use case tersebut akan diabaikan.]

Mengubah status WorkOrder menjadi selesai dikerjakan
Basic Scenario
 Front Desk memilih sebuah WorkOrder di Screen ListWorkOrder, lalu memilih menu untuk mengubah 
 status WorkOrder menjadi selesai dikerjakan. Sistem akan menampilkan dialog konfirmasi. 
 Bila kasir menkonfirmasi, Sistem akan mengubah status WorkOrder tersebut menjadi selesai 
 dikerjakan dan mencatat jam selesai dikerjakan. Front Desk kemudian mengerjakan 
 use case "Mencetak rincian WorkOrder termasuk biaya".
Alternate Scenario
 Status WorkOrder bukan sedang dikerjakan - Sistem akan menampilkan pesan kesalahan.

Mencetak rincian WorkOrder termasuk biaya
Basic Scenario
 Front Desk memilih tombol untuk mencetak. Sistem kemudian mencetak detail WorkOrder 
 ke printer. 
 Detail WorkOrder yang dicetak meliputi tanggal, plat nomor motor, jam mulai dikerjakan, 
 jam selesai dikerjakan, nama mekanik yang mengerjakan, rincian seluruh Sparepart yang dipakai 
 (jumlah & harga eceran tertinggi Sparepart), ongkos servis dan total yang harus dibayar.
Alternate Scenario
 Status WorkOrder bukan selesai dikerjakan - Sistem akan menampilkan pesan kesalahan.
[Catatan: use case ini dipisahkan dari use case "Mengubah status WorkOrder menjadi 
 selesai dikerjakan" karena dianggap nanti akan ada use case lain yang dapat 
 mencetak rincian WorkOrder tetapi tidak ditampilkan disini.]

4. Requirements Review

Pada saat melakukan analisa dalam membuat use case, saya menemukan hal yang masih kurang.   Misalnya, saya perlu menambahkan class ItemSparepart pada domain model.   Selain itu, pada beberapa situasi, saya bahkan bisa menemukan ada use case yang masih kurang, misalnya use case “Tambah Motor baru“.
Pada langkah ini, saya kembali memastikan bahwa use case & domain model telah dibuat dengan baik.   Pelanggan juga perlu dilibatkan untuk memastikan bahwa use case (behavioral requirement) & functional requirement sesuai dengan yang diharapkan.   Ingatlah selalu bahwa bagian terpenting dari sebuah sistem bukanlah seberapa keren design pattern yang diterapkan di class diagram, tetapi sejauh mana sistem tersebut memberikan profit bagi penggunanya (memenuhi requirements).

5. Melakukan Robustness Analysis

Analisis adalah memikirkan “apa” (what),  sementara perancangan adalah memikirkan “bagaimana” (how). Salah satu alasan mahasiswa sering mengabaikan UML dan langsung terjun ke coding adalah celah yang cukup jauh antara analisis dan perancangan sehingga mereka memilih merancang secara eksperimental dengan langsung coding.   Umumnya mereka berakhir dalam jebakan siklus perubahan “coding” terus menerus (guna memperbaiki rancangan).   Padahal, perubahan “coding” adalah sesuatu yang sangat memakan waktu dan upaya bila dibandingkan dengan mengubah diagram UML.
Robustness analysis dipakai untuk menjembatani analisis dan perancangan.   Robustness analysis harus diterapkan pada setiap use case yang ada.  Pada Enterprise Architect, robustness analysis dapat digambarkan dengan menggunakan Analysis Diagrams (terdapat di kategori Extended).
Berikut ini adalah contoh hasil robustness analysis untuk use case yang ada:





Semakin detail robustness analysis, maka semakin banyak hal yang kurang dari use case dan domain model yang akan ditemukan.   Yup! Pada awalnya saya ragu kenapa saya harus menambah control “mengisi jumlah”, “mengisi nama”, dsb untuk setiap field yang ada.   Tapi saya cukup terkejut saat menemukan dari hal sepele tersebut, saya menemukan beberapa alternate scenario yang kurang.
Sebagai contoh, saya menemukan bahwa saya lupa menambahkan alternate scenario “jumlah Sparepart tidak mencukupi” saat melakukan analisa robustness pada use case “Menambah Sparepart yang dipakai selama pengerjaan WorkOrder”.   Semakin cepat saya menyadari ada yang kurang, semakin baik! Idealnya adalah sebelum coding dilakukan. Robustness analysis adalah salah satu senjata yang ampuh untuk itu.
Saya juga menemukan bahwa pada use case “Mengubah Status WorkOrder menjadi sedang dikerjakan oleh Mekanik”, saya lupa menuliskan bahwa Front Desk officer juga perlu memilih JenisPekerjaan.   Saya perlu segera mengubah teks use case tersebut.
Selain itu, terkadang saya juga dapat menemukan ada class yang kurang pada domain model.   Misalnya, dari hasil robutsness analysis, terlihat bahwa saya perlu menambahkan class Mekanik di domain model.
Pada tahap ini, saya juga perlu mengisi domain model dengan atribut, seperti yang terlihat pada gambar berikut ini:

6. Preliminary Design Review

Kembali lagi seluruh tim melakukan review dan memastikan bahwa semua yang telah dibuat sesuai dengan requirement.   Ini adalah langkah terakhir dimana pelanggan (stackholder) terlibat!   Hal ini karena langkah berikutnya melibatkan proses techincal.  Akan berbahaya bila membiarkan pelanggan yang non-technical atau semi-technical mengambil keputusan untuk hal-hal yang bersifat teknis (misalnya framework atau database yang dipakai).   Walaupun demikian, pelanggan boleh memberikan komentar mengenai tampilan.
Setelah langkah ini, tidak ada lagi perubahan requirement.  Lalu bagaimana bila pelanggan ingin menambah requirement? Buat sebuah rilis atau milestone baru dengan kembali lagi ke langkah pertama di atas.

7. Menentukan Technical Architecture

Tentukan framework apa yang akan dipakai.   Sebagai contoh, saya akan membuat sebuah aplikasi desktop dengan Griffon.  Pola arsitektur yang dipakai menyerupai Model View ViewModel (MVVM) dimana terdapat perbedaan antara domain model dan view model.   Saya juga mengasumsikan penggunaan sebuah plugin fiktif yang dirujuk sebagai simple-jpa.   Gambar berikut ini memperlihatkan contoh arsitektur yang dipakai:

8. Membuat Sequence Diagram

Object oriented pada dasarnya adalah menggabungkan antara data dan operasi ke dalam sebuah entitas.   Saat ini, domain model baru berisi data.  Oleh sebab itu, dibutuhkan sebuah upaya untuk menemukan operasi untuk domain model.   Caranya adalah dengan memakai sequence diagram.
Saat membuat sequence diagram, sertakan juga elemen dalam arsitektur teknis/framework.   Misalnya penggunaan MVC akan menyebabkan ada class baru seperti controller.  Yup! Penggunaan MVC akan membuat operasi tersebar ke controller.   Hal ini sering dikritik karena bukan  pendekatan OOP melainkan kembali ke zaman prosedural.  Baca buku Object Design: Roles, Responsibilities, and Collaborations untuk pendekatan yang OOP, akan tetapi jangan lupa kalau kita dibatasi oleh framework yang dipakai (ehem, seharusnya bukan framework yang membatasi kita, melainkan kita yang tegas dalam memilih framework).
Selama membuat sequence diagram, ingatlah selalu bahwa tujuannya adalah menemukan operasi (behavior) untuk setiap class yang ada, bukan menunjukkan step-by-step operasi secara detail!   Untuk menjaga agar tidak tersesat menjadi membuat flow-chart yang detail, jangan memikirkan focus of control (matikan saja fitur tersebut!).
Sequence diagram dibuat untuk setiap use case yang ada, berdasarkan hasil robustness anaylsis. Gambar berikut ini memperlihat contoh sequence diagram yang dihasilkan (agar sederhana, operasi penyimpanan data oleh simple-jpa tidak ditampilkan):





Proses analisa yang berulang kali lagi-lagi membantu saya menemukan kekurangan.   Saya selama ini ternyata lupa bahwa pada use case “Menambah Sparepart yang dipakai selaman pengerjaan WorkOrder”, sistem harus mengurangi jumlah stok Sparepart bila pengguna men-klik tombol simpan.   Oleh sebab itu, saya segera memperbaharui teks use case.
Selain itu, saya juga menemukan sebuah kesalahan yang saya buat dari awal dan tidak terdeteksi hingga sekarang, yang berhubungan dengan class OngkosServis.   Gambar berikut ini memperlihatkan perancangan awal class tersebut:

Bila membuat ERD atau design tabel, ini adalah sesuatu yang dapat diterima (ongkos disimpan dalam tabel yang mewakili hubungan one-to-many dari JenisPekerjaan ke TipeMotor). Tetapi, bila diterapkan ke dalam domain model, maka akan terjadi kejanggalan saat saya memakai domain model tersebut di sequence diagram. Untuk memperoleh ongkos servis, apa saya harus membuat instance objek OngkosServis baru? Bila diterapkan ke coding, maka ini berarti untuk memperoleh ongkos servis, saya harus selalu melakukan query JPQL  yang kira-kira terlihat seperti berikut ini:

TipeMotor tipeMotor = model.selectedTipeMotor
JenisPekerjaan jenisPekerjaan = model.selectedJenisPekerjaan
Query query = 
  em.createQuery("SELECT o.harga FROM OngkosServis o WHERE " + 
      "o.tipeMotor = :tipeMotor AND o.jenisPekerjaan = :jenisPekerjaan") 
query.setParameter("tipeMotor", tipeMotor)
query.setParameter("jenisPekerjaan", jenisPekerjaan)
Long ongkos = query.getSingleResult()

Terlihat ada yang tidak beres! Bukankah OOP harus intuitive & bisa dipakai dengan mudah? Kenapa tiba2 harus melakukan query secara eksplisit untuk memperoleh sebuah ongkos servis? Selain itu, class OngkosServis tidak pernah dipakai secara langsung di kode program, hanya dipakai di query saja!
Oleh sebab itu, saya memperbaikinya dengan membuang class OngkosServis, dan menambahkan atribut ongkosServis di class JenisPekerjaan dengan tipe data berupa Map<TipeMotor,Long>. Dengan demikian, saya bisa memakainya seperti berikut ini:

TipeMotor tipeMotor = model.selectedTipeMotor
JenisPekerjaan jenisPekerjaan = model.selectedJenisPekerjaan
Long ongkos = jenisPekerjaan.getOngkosServis(tipeMotor)

Cara di-atas jauh lebih intuitive dan mudah dipahami. Query database tetap terjadi, tetapi kali ini secara implisit (secara otomatis) oleh Hibernate tanpa campur tangan developer.
Ini adalah alasan kenapa saya selalu memberikan pesan pada mahasiswa agar tidak memikirkan proses penyimpanan data saat membuat domain model.   Jangan menyamakan domain model dan ERD.   Pada saat merancang domain model, pikirkan bagaimana class-class yang ada akan saling berinteraksi dan dipakai oleh developer.   Bahkan bila tidak memakai ORM seperti Hibernate, tetap jangan memikirkan bagaimana penyimpanan data di domain model, melainkan buat ERD terpisah untuk dipakai oleh persistence layer (DAO).

9. Critical Design Review

Kembali melakukan review untuk memastikan bahwa tidak ada yang kurang pada sequence diagram. Pastikan bahwa setiap class yang ada telah memiliki atribut dan operasi yang didefinisikan secara lengkap (memiliki nama, tipe data, parameter, dsb).
Berikut ini adalah contoh hasil domain model yang telah dilengkapi dengan operasi dan multiplicity:

Getter dan setter tidak perlu ditampilkan karena hanya akan membuat class diagram terlihat ‘penuh’.
Versi bidirectional-nya akan terlihat seperti pada gambar berikut ini:

Selain domain model, saya juga menemukan terdapat class-class lain yang dihasilkan yang berkaitan dengan penggunaan framework, yang terlihat seperti pada gambar berikut ini:

10. Coding

Disini developer berperan mengubah rancangan (design) menjadi kode program.   Karena semua telah direncanakan dan dipikirkan sebelumnya, maka proses coding dapat dianggap sebagai sebuah pembuktian (test) bahwa rancangan yang dibuat sudah benar. Terkadang terdapat beberapa hal yang lolos dari perancangan dan baru terungkap saat coding; pada kasus tersebut, perubahan pada rancangan harus segera dilakukan sehingga kode program dan rancangan bisa tetap sinkron.
Bila pembuatan kode program tiba-tiba menjadi tidak terkendali (pada kasus skripsi, mahasiswa tiba-tiba merasa seolah otaknya hendak meledak dan jadi malas coding), maka ada beberapa kemungkinan:

• Hasil rancangan tidak bagus.
• Programmer tidak mengikuti hasil rancangan yang bagus dan mengerjakannya sesuka hatinya.
• Programmer tidak diikutsertakan dalam proses perancangan
• Mahasiswa tidak mau pikir panjang/hanya copy paste di bab analisa & perancangan, dalam pikirannya mau segera fokus ke bab implementasi dan kode program;
• Mahasiswa hanya memikirkan bab analisa & perancangan, tidak mau peduli dampaknya pada saat membuat kode program nanti.

 

Read More

tugas pertemuan ke 2 (pengaruh LIFE CYCLE (SDLC) dan Peranan Case Tools,Model Proses

SDLC (Systems Development Life Cycle)

1) Carilah informasi mengenai SDLC (Systems Development Life Cycle) secara Lengkap.
SDLC adalah tahapan-tahapan pekerjaan yang dilakukan oleh analis sistem dan programmer dalam membangun sistem informasi. Langkah yang digunakan meliputi :
1. Melakukan survei dan menilai kelayakan proyek pengembangan sistem informasi
2. Mempelajari dan menganalisis sistem informasi yang sedang berjalan
3. Menentukan permintaan pemakai sistem informasi
4. Memilih solusi atau pemecahan masalah yang paling baik
5. Menentukan perangkat keras (hardware) dan perangkat lunak (software)
6. Merancang sistem informasi baru
7. Membangun sistem informasi baru
8. Mengkomunikasikan dan mengimplementasikan sistem informasi baru
9. Memelihara dan melakukan perbaikan/peningkatan sistem informasi baru bila diperlukan

System Development Lyfe Cycle (SDLC) adalah keseluruhan proses dalam membangun sistem melalui beberapa langkah. Ada beberapa model SDLC. Model yang cukup populer dan banyak digunakan adalah waterfall. Beberapa model lain SDLC misalnya fountain, spiral, rapid, prototyping, incremental, build & fix, dan synchronize & stabilize.
Dengan siklus SDLC, proses membangun sistem dibagi menjadi beberapa langkah dan pada sistem yang besar, masing-masing langkah dikerjakan oleh tim yang berbeda.
Dalam sebuah siklus SDLC, terdapat enam langkah. Jumlah langkah SDLC pada referensi lain mungkin berbeda, namun secara umum adalah sama. Langkah tersebut adalah
1. Analisis sistem, yaitu membuat analisis aliran kerja manajemen yang sedang berjalan
2. Spesifikasi kebutuhan sistem, yaitu melakukan perincian mengenai apa saja yang dibutuhkan dalam pengembangan sistem dan membuat perencanaan yang berkaitan dengan proyek sistem
3. Perancangan sistem, yaitu membuat desain aliran kerja manajemen dan desain pemrograman yang diperlukan untuk pengembangan sistem informasi
4. Pengembangan sistem, yaitu tahap pengembangan sistem informasi dengan menulis program yang diperlukan
5. Pengujian sistem, yaitu melakukan pengujian terhadap sistem yang telah dibuat
6. Implementasi dan pemeliharaan sistem, yaitu menerapkan dan memelihara sistem yang telah dibuat

2) Carilah gambar mengenai SDLC.

Contoh SDLC metode Waterfall 

Contoh SDLC metode daur hidup pengembangan

Contoh SDLC Metode development

3) Keahlian pengembangan sistem terdiri dari : Keahlian komunikasi (Communication skill), Kemampuan Analitis (Analytical ability), Kreativitas (Creativity), Kepemimpinan (Leadership). Jelaskan masing-masingnya secara Lengkap.
Keahlian Pengembangan Sistem
Dengan cara yang sama,kita dapat mengidentifikasi jenis-jenis keahlian pengembangan yang berbeda dan memiliki arti yang penting.

a.) Keahlian komunikasi (communications skills) melibatkan kemampuan untuk menyampaikan informasi kepada satu orang atau lebih dengan menggunakan komunikasi lisan,tulisan,atau gambar.
b.) Kemampuan analitis (analytical ability) melibatkan studi dan pemahaman akhir atas suatu situasi dengan tujuan merumuskan respons atau solusi.
c.) Kreativitas (creativity) penciptaan ide atau solusi baru yang sepenuhnya atau separuhnya baru.
d.) Kepemimpinan (leadership) kemampuan untuk mengarahkan orang lain untuk melaksanakan tugasnya.

Model Pengembangan Sistem Informasi

A.     PENDAHULUAN

Ada banyak macam pemodelan dalam pengembangan system informasi. Pemodelan dari pengembangan system ini berupa metode – metode, prosedur – prosedur – prosedur, konsep – konsep pekerjaan, aturan – aturan yang akan digunakan sebagai pedoman dan apa yang harus dikerjakan selama mengerjakan selama pengembangan system informasi. Tujuan dari pengembangan system informasi ini agar dapat memenuhi kebutuhan user, dilakukan tepat waktu, tidak melampaui anggaran biaya, mudah dipergunakan, mudah dipahami dan mudah dirawat.

B.     MODEL PROSES PENGEMBANGAN SISTEM INFORMASI
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
SDLC (System Development Life Cycle) merupakan siklus yang menggambarkan perangkat lunak yang dibangun. SDLC juga merupakan pola yang diambil untuk mengembangkan sistem perangkat lunak, yang terdiri dari tahap-tahap:

1. Rencana (planning),
2. Analisis (analysis),
3. Desain (design),
4. Implementasi (implementation),
5. Uji coba (testing) dan
6. Pengelolaan (maintenance). 

Dalam rekayasa perangkat lunak, konsep SDLC mendasari berbagai jenis metodologi pengembangan perangkat lunak. Metodologi-metodologi ini membentuk suatu kerangka kerja untuk perencanaan dan pengendalian pembuatan sistem informasi, yaitu proses pengembangan perangkat lunak. Terdapat 3 jenis metode siklus hidup sistem yang paling banyak digunakan, yakni:

• Siklus hidup sistem tradisional (traditional system life cycle), Berupa definisi masalah, Studi kelayakan, Analisa, Desain, dan Implementasi. 

• Siklus hidup menggunakan protoyping (life cycle using prototyping) Merupakan salah satu metode siklus hidup sistem yang didasarkan pada konsep model bekerja (working model)

• Siklus hidup sistem orientasi objek (object-oriented system life cycle). Dasar dari konsep obyek oriented adalah obyek, class, asosiasi dan inheritance menjadi kemudi dalam proses pembuatan dari tahap paling awal dan menyediakan dasar tunggal bagi daur hidup sistem.

Model-model yang digunakan pada Software Development Life Cycle (SDLC) yaitu:

1. MODEL WATERFALL

Merupakan model pengembangan system yang paling mudah dan paling sering digunakan. Model pengembangan ini bersifat linear dari tahap awal pengembangan system yaitu tahap perencanaan sampai tahap akhir pengembangan system yaitu tahap pemeliharaan. Tahapan berikutnya tidak akan dilaksanakan sebelum tahapan sebelumnya selesai dilaksanakan dan tidak bisa kembali atau mengulang ke tahap sebelumnya.
Tahap-tahap yang dilakukan pada model Waterfall ini digambarkan pada gambar berikut ini :

Kelebihan dan Kelemahan Waterfall

Kelebihan Model Waterfall :

1.      Merupakan model pengembangan paling handal dan paling lama digunakan.

2.      Cocok untuk system software berskala besar.

3.      Cocok untuk system software yang bersifat generic.

4.      Pengerjaan project system akan terjadwal dengan baik dan mudah dikontrol.

Kekurangan Model Waterfall :

1.      Persyaratan system harus digambarkan dengan jelas.

2.      Rincian proses harus benar-benar jelas dan tidak boleh berubah-ubah.

3.      Sulit untuk mengadaptasi jika terjadi perubahan spesifikasi pada suatu tahapan pengembangan.

2. MODEL ITERASI
Merupakan model pengembangan system yang bersifat dinamis dalam artian setiap tahapan proses pengembangan system dapat diulang jika terdapat kekurangan atau kesalahan. Setiap tahapan pengembangan system dapat dikerjakan berupa ringkasan dan tidak lengkap, namun pada akhir pengembangan akan didapatkan system yang lengkap pada pengembangan system.
Model Iterasi digambarkan sebagai berikut :

Kelebihan dan Kelemahan Model Iterasi
Kelebihan Model Iterasi :
1.      Dapat mengakomodasi jika terjadi perubahan pada tahapan pengembangan yang telah dilaksanakan.
2.      Dapat disesuaikan agar system bisa dipakai selama hidup software computer.
3.      Cocok untuk pengembangan sistem dan perangkat lunak skala besar.
4.      Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap resiko setiap tahapan karena system terus bekerja selama proses.

Kekurangan Model Iterasi :
1.      Hanya berlaku untuk Short-Lifetime system.
2.      Tahapan proses tidak terlihat sedang berada ditahapan mana suatu pekerjaan.
3.      Memerlukan alat ukur kemajuan secara regular.
4.      Perubahan yang sering terjadi dapat merubah struktur system.
5.      Memerlukan tenaga ahli dengan kemampuan tinggi.


Terdapat dua jenis Model Iterasi, yaitu :
1.      Model Incremental, merupakan model pengembangan system yang dipecah sehingga model pengembangannya secara increment/bertahap. Kebutuhan pengguna diprioritaskan dan prioritas tertinggi dimasukkan dalam awal increment.
Tahapan Incremental Model :
·        Requirement
·        Specification
·        Architecture

DesignTahapan-tahapan tersebut dilakukan secara berurutan. Setiap bagian yang sudah selesai dilakukan testing, dikirim ke pemakai untuk langsung dapat digunakan.

Model ini menerapkan sistem kerja yang paralel. Setelah daftar kebutuhan didapatkan dari pemakai, tim spesifikasi membuat spesifikasi untuk modul pertama. Setelah spesifikasi pertama selesai, tim desain menindak lanjuti. Tim spesifikasi sebelumnya juga langsung membuat spesifikasi untuk model kedua, dan seterusnya.

Kelebihan dan Kekurangan Model Incremental
Kelebihan Model Incremental :
1.      Penambahan kemampuan fungsional akan lebih mudah diuji, diverifikasi, dan divalidasi dandapat menurunkan biaya yang dikeluarkan untuk memperbaiki system.
2.      Nilai penggunaan dapat ditentukan pada setiap increament sehingga fungsionalitas sistemdisediakan lebih awal
3.      Increment awal berupa prototype untuk membantu memahami kebutuhan pada incrementberikutnya.
4.      Memiliki risiko lebih rendah terhadap keseluruhan pengembagan sistem.
5.      Prioritas tertinggi pada pelayanan sistem adalah yang paling diuji

Kekurangan Model Incremental
1.      Tiap bagian tidak dapat diintegrasikan
2.      Setiap tambahan yang dibangun harus dimasukkan kedalam struktur yang ada tanpamenurunkan kualitas dari yang telah dibangun system tersebut sampai saat ini.
3.      Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut

Model Incremental digambarkan sebagai berikut :

2.  Model Spiral, merupakan model pengembangan system yang digambarkan berupa spiral. Model spiral ini tidak merepresentasikan rangkaian tahapan dengan penelusuran balik (back-tracking), tidak ada fase-fase tahapan yang tetap seperti spesifikasi atau perancangan. Setiap untaian pada pada spiral menunjukkan fase software process. Model ini merupakan perbaikan dari model waterfall dan prototype. Mengabungkan keuntungan model air terjun dan prototype dan memasukkan analissis resiko
Beberapa hal yang dilakukan dalam Model Spiral :
1.      Mendefinisikan kebutuhan dengan sedetail mungkin
2.      Pembuatan desain untuk sistem yang baru
3.      Pembuatan prototipe dari pembuatan desain, pembuatan prototipe selanjutnya berdasarkan evaluasi prototipe sebelumnya
4.      Proses prototipe dilakukan berulang-ulang sampai customer puas
5.      Sistem dibuat berdasarkan prototipe yang memuaskan customer
6.      Sistem di tes dan dievaluasi

Kelebihan dan Kekurangan Model Spiral :
Kelebihan Model Spiral :
1.      Dapat digunakan untuk sistem yang besar
2.      Sangat cocok sebagai mekanisme mengurangi resiko
Kelemahan Model Spiral :
1.      Terlalu banyak memikirkan resiko yang akan terjadi
2.      Masih jarang digunakan
3.      Metode ini lambat dan mahal karena setiap tahapan yang dilalui harus menikutsertakan pemesan

Model Spiral ini digambarkan sebagai berikut :

 MODEL RAPID APPLICATION DEVELOPMENT (RAD)
Merupakan model pengembangan system yang melakukan beberapa penyesuaian terhadap SDLC pada beberapa bagian sehingga lebih cepat untuk sampai ke tangan pengguna system. metodologi ini biasanya mensyaratkan beberapa teknik dan alat-alat khusus agar proses bisa cepat, misalnya melakukan sesi Joint Application Development(JAD), penggunaan alat-alat Computer Aided Software Engineering (CASE Tools), kode generator dan lain-lain.
Model RAD ini digambarkan sebagai berikut :

MODEL PROTOTYPING
Merupakan model pengembangan system yang proses iterative dalam pengembangan sistem dimana requirement diubah ke dalam sistem yang bekerja (working system) yang secara terus menerus diperbaiki melalui kerjasama antara user dan analis. Prototype juga bisa dibangun melalui beberapa tool pengembangan untuk menyederhanakan proses. Prototyping merupakan bentuk dari Rapid Application Development (RAD). Dalam metode ini, pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan system.
Tahapan-tahapan dalam Prototyping adalah sebagai berikut:
1. Pengumpulan kebutuhan Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak, mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.
2. Membangun prototyping Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyajian kepada pelanggan (misalnya dengan membuat input dan format output)
3. Evaluasi protoptyping Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.
4. Mengkodekan sistem Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai
5. Menguji sistem Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain.
6. Evaluasi Sistem Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Jika ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.
7. Menggunakan sistem Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan.


Kelebihan dan Kelemahan Prototyping
Kelebihan Prototyping adalah:

1. Adanya komunikasi yang baik antara pengembang dan pelanggan
2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
3. Pelanggan berperan aktif dalam pengembangan sistem
4. Lebih menghemat waktu dalam pengembangan sistem
5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.

Kelemahan Prototyping adalah :

1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum memikirkan kemampuan pemeliharaan untuk jangka waktu lama.
2. Pengembang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya merupakan cetak biru sistem .
3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak mencerminkan teknik perancangan yang baik

Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri sebagai berikut:

1. Resiko tinggi Yaitu untuk masalah - masalah yang tidak terstruktur dengan baik, ada perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak menentu.
2. Interaksi pemakai penting. Sistem harus menyediakan dialog on-line antara pelanggan dan komputer.
3. Perlunya penyelesaian yang cepat
4. Perilaku pemakai yang sulit ditebak
5. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan penggunaan perangkat keras yang mutakhir
6. Perkiraan tahap penggunaan sistem yang pendek

Model Prototyping digambarkan sebagai berikut :

DAFTAR PUSTAKA

Anonymous, Model Pada Software Defelopment Life Cycle, URL : http://itsum.wordpress.com/2010/09/26/model-pada-software-development-life-cycle-sdlc/, Diunduh 1 April 2012

Anonymous, Model Incremental, URL : http://www.scribd.com/dharmabolu/d/51777057-Model-Incremental, Diunduh 1 April 2012

Fakultas Ilmu Komputer Universitas Indonesia, Prinsip – Prinsip Sistem Informasi, URL : http://lecturer.eepis-its.edu/~arna/Modul_RPL/3.%20Proses%20Software.pdf, Diunduh 1 April 2012

Proboyekti, Umi, Software Proces Model I, URL : http://lecturer.ukdw.ac.id/othie/softwareprocess.pdf, Diunduh 1 April 2012

Solihin, Firdaus, Model SDLC, URL : http://fsolihin.files.wordpress.com/2009/03/si-4-model-sdlc.pdf, Diunduh 1 April 2012

Sukamto, Rosa Ariani, System Development Life Cycle (SDLC), URL : http://www.gangsir.com/download/Minggu2-SDLC.pdf, Diunduh 1 April 2012

Udienkhusy, Kelebihan dan Kekurangan Setiap Model Pada Software Development Life Cycle, URL : http://blog.udienskhusy.com/269/kelebihan-dan-kekurangan-setiap-model-pada-software-development-life-cycle, Diunduh 1 April 2012

Sumber: http://effendyhaqee.blogspot.com/2012/04/model-pengembangan-sistem-informasi.html

Read More