ACTIVITY DIAGRAM

Pengertian Activity Diagram

  Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Menggambarkan proses bisnis dan urutan aktivitas dalam sebuah proses. Dipakai pada business modeling untuk memperlihatkan urutan aktifitas proses bisnis. Struktur diagram ini mirip flowchart atau Data Flow Diagram pada perancangan terstruktur. Sangat bermanfaat apabila kita membuat diagram ini terlebih dahulu dalam memodelkan sebuah proses untuk membantu memahami proses secara keseluruhan.
Activity diagram dibuat berdasarkan sebuah atau beberapa use case pada use case diagram.


Pengertian Sequence diagram

   Sequence diagram (diagram urutan) adalah suatu diagram yang memperlihatkan atau menampilkan interaksi-interaksi antar objek di dalam sistem yang disusun pada sebuah urutan atau rangkaian waktu. Interaksi antar objek tersebut termasuk pengguna, display, dan sebagainya berupa pesan/message.

Sequence Diagram digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai sebuah respon dari suatu kejadian/even untuk menghasilkan output tertentu. Sequence Diagram diawali dari apa yang me-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.
      Diagram ini secara khusus berasosiasi dengan use case diagram. Sequence diagram juga memperlihatkan tahap demi tahap apa yang seharusnya terjadi untuk menghasilkan sesuatu didalam use case. Sequence diagram juga dapat merubah atribut atay method pada class yang telah dibentuk oleh class diagram, bahkan  menciptakan sebuah class baru. Sequence diagram memodelkan aliran logika dalam sebuah system dalam cara yang visual.
     Sequence diagram biasanya digunakan untuk tujuan analisa dan desain, memfokuskan pada identifikasi method didalam sebuah system. Sequence diagram biasanya dipakai untuk memodelkan :

• Deskripsi tentang system yang ada pada sebuah / beberapa use case pada use case diagram, yang menggambarkan hubungan antara actor dan use case diagram.
• Logika dari method (operation, function atau procedure).
• Logika dari service (high level method).

READ MORE - ACTIVITY DIAGRAM

UML, Diagram Case

Pengertian :

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah sistem. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan sistem perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Use-case diagram adalah gambaran graphical dari beberapa atau semua actor, use-case, dan interaksi diantara komponen-komponen tersebut yang memperkenalkan suatu sistem yang akan dibangun. Use-case diagram menjelaskan manfaat suatu sistem jika dilihat menurut pandangan orang yang berada di luar sistem. Diagram ini menunjukkan fungsionalitas suatu sistem atau kelas dan bagaimana sistem tersebut berinteraksi dengan dunia luar.

Use-case diagram dapat digunakan selama proses analisis untuk menangkap requirement system dan untuk memahami bagaimana sistem seharusnya bekerja. Selama tahap desain, use-case diagram berperan untuk menetapkan perilaku (behavior) sistem saat diimplementasikan. Dalam sebuah model mungkin terdapat satu atau beberapa use-case diagram. Kebutuhan atau requirements system adalah fungsionalitas apa yang harus disediakan oleh sistem kemudian didokumentasikan pada model use-case yang menggambarkan fungsi sistem yang diharapkan (use-case), dan yang mengelilinginya (actor), serta hubungan antara actor dengan use-case (use-case diagram) itu sendiri.

● Use case class digunakan untuk memodelkan dan menyatakan unit fungsi/layanan yang disediakan oleh sistem (or bagian sistem: subsistem atau class) ke pemakai.

● Use case dapat dilingkupi dengan batasan sistem yang diberi label nama sistem.

● Use case adalah sesuatu yang menyediakan hasil yang dapat diukur ke pemakai atau sistem eksternal.

Karakteristik :
– Use cases adalah interaksi atau dialog antara sistem dan actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.

– Use cases diprakarsai oleh actor dan mungkin melibatkan peran actor lain. Use cases harus menyediakan nilai minimal kepada satu actor.

– Use cases bisa memiliki perluasan yang mendefinisikan tindakan khusus dalam interaksi atau use case lain mungkin disisipkan.

– Use case class memiliki objek use case yang disebut skenario. Skenario menyatakan urutan pesan dan tindakan tunggal.

Berikut adalah cara menggambar use-case diagram:

Catatan:
Sebelum membuat use-case diagram, sebaiknya diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.
1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.
2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.
3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula.


sumber : http://nickizoner.blogspot.com/2013/06/mengenal-use-case-diagram.html

ma'scm;aMenggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
Sebuah Use-case dapat meng-include fungsionalitas Use-case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa Use-case yang di-include akan dipanggil setiap kali Use-case yang meng-include dieksekusi secara normal. Sebuah Use-case dapat di-include oleh lebih dari satu Use-case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Contoh Use-case (include)

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
Sebuah Use-case juga dapat meng-extend Use-case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar Use-case menunjukkan bahwa Use-case yang satu merupakan spesialisasi dari yang lain.

Contoh Use-case (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

- See more at: http://kepenakwae.blogspot.com/2013/01/use-case-diagram-uml.html#sthash.LgljEK43.dpuf

Menggambar UML Use-case Diagram 

Use-case diagram merupakan model diagram UML yang digunakan untuk menggambarkan requirement fungsional yang diharapkan dari sebuah system. Use-case diagram menekankan pada “siapa” melakukan “apa” dalam lingkungan system perangkat lunak akan dibangun. Use-case diagram sebenarnya terdiri dari dua bagian besar; yang pertama adalah use case diagram (termasuk gambar use case dependencies) dan use case description. 

Berikut adalah Gambar Notasi Use Case

Berikut adalah cara menggambar use-case diagram:

Catatan:

Sebaiknya membuat use-case diagram, diawali dengan membuat FDD terlebih dahulu. Hal ini sekedar untuk membantu mengidentifikasi proses-proses dalam sistem.

1) Mulai dengan mendaftarkan aktor yang berhubungan dengan Use-case, baik sebagai sender maupun receiver.

2) Komponen dalam use-case diagram adalah Nama Use-case, Deskripsi Use-case dan Pelaku yang berpartisipasi dan perannya.

3) Temukan dependency yang mendemonstrasikan hubungan semantik antara dua Use-case. Jika Use-case “A” berubah dapat mengakibatkan Use-case “B” akan berubah pula. 

Ada 2 macam dependency yang perlu diperhatikan yaitu include dan extend.
Dependency include:
Sebuah Use-case dapat meng-include fungsionalitas Use-case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa Use-case yang di-include akan dipanggil setiap kali Use-case yang meng-include dieksekusi secara normal. Sebuah Use-case dapat di-include oleh lebih dari satu Use-case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Contoh Use-case (include)

Ket:
Pasien harus membuat temu janji sebelum diberikan perawatan yang diperlukan untuk mengobati penyakit yang dideritanya. Use-case “Make Appointment” meng-include fungsionalitas dari Use-case “Get Treatment” sebagai bagian dari proses saat dieksekusi.

Dependency extend:
Sebuah Use-case juga dapat meng-extend Use-case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar Use-case menunjukkan bahwa Use-case yang satu merupakan spesialisasi dari yang lain.

Contoh Use-case (extend):

Ket:
Setelah pasien membuat temu janji dengan dokter, pasien ini  tiba-tiba mendapat halangan sehingga tidak dapat memenuhi janjinya. Oleh karena itu, pasien ini membatalkan janji yang sudah dibuat. Ini merupakan contoh dari kasus extend dimana “Make Appointment” adalah base Use-case dan “Cancel Appointment” merupakan extended Use-case.

Gambar  Contoh Interaksi Antara Aktor dan Sistem (Use-case)

Berikut adalah Contoh Use-case description

Keterangan

Normal course:         

Rangkaian kejadian yang terjadi sesuai harapan
Alternate course:    

Mendokumentasikan kelakuan Use-case jika terjadi exception
Pre-condition:    

Kondisi yang harus dipenuhi sebelum Use-case ini dijalankan. Hal ini dapat dilakukan dengan memberikan penjelasan singkat atau dapat pula berupa nama Use-case.
Post-condition:    

Batasan pada keadaan sistem setelah Use-case ini diesksekusi dengan baik. Dapat berupa nama Use-case.

- See more at: http://kepenakwae.blogspot.com/2013/01/use-case-diagram-uml.html#sthash.LgljEK43.dpuf

READ MORE - UML, Diagram Case

Struktur Data dan Struktur Tabel "Sistem Informasi Perpustakaan"

Struktur Data adalah model logika / matematik yang secara khusus mengorganisasi data

• Struktur data Statis yaitu array/larik,record,himpunan
• Struktur data Dinamis yaitu list/senarai, queque/antrian/giliran,tumpukan/stack/timbunan, pohon, graf 

Kamus data
Data anggota : kd_anggota, nama_anggota, alamat_anggota
Data buku : kd_buku, judul_buku, pengarang_buku, penerbit_buku
Data peminjaman : kd_anggota, kd_buku tgl_pinjam, tgl_kembali
Data Pengembalian : kd_anggota,kd_buku, tgl_pinjam, tgl_kembali, denda
Data petugas : nip, nama_petugas, alamat_petugas

ENTITY RELATIONAL DIAGRAM



 

 

 

 

 

 

Struktur tabel

 1. Tabel Anggota Perpustakaan yang berisi tentang informasi anggota perpustakaan yang berhak melakukan transaksi peminjaman buku

2.  Tabel Buku yang berisi tentang informasi buku-buku yang tersedia di perpustakaan

3.  Tabel Kategori Buku yang menginformasikan kategori buku yang ada di perpustakaan

4.  Tabel Transaksi yang berisi tentang informasi transaksi peminjaman maupun pengembalian buku yang terjadi di perpustakaan

READ MORE - Struktur Data dan Struktur Tabel "Sistem Informasi Perpustakaan"

ERD - Entity Relationship Diagram

ERD merupakan suatu model untuk menjelaskan hubungan antar data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi.
ERD untuk memodelkan struktur data dan hubungan antar data, untuk menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada tiga simbol yang digunakan, yaitu :

1. Entitas

Entias merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain (Fathansyah, 1999: 30). Simbol dari entiti ini biasanya digambarkan dengan persegi panjang.

2. Atribut

Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elips.

3. Hubungan / Relasi

Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Relasi dapat digambarkan sebagai berikut :
Relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B) dalam satu basis data yaitu (Abdul Kadir, 2002: 48) :
1). Satu ke satu (One to one)
Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B.
2). Satu ke banyak (One to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A.
3). Banyak ke banyak (Many to many)
Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B.

Sumber : http://blog.re.or.id/erd-entity-relationship-diagram.htm

READ MORE - ERD - Entity Relationship Diagram

DFD - Data Flow Diagram, Level 1

Data Flow Diagram merupakan alat pemodelan dari proses analisis kebutuhan perangkat lunak. Dalam DFD dibahas fungsi-fungsi apa saja yang diperlukan oleh suatu sistem dan aliran data yang terdapat diantara proses di dalamnya. DFD berguna sebagai alat untuk memverifikasikan apakah sistem yang akan dibangun sudah memenuhi kriteria yang diinginkan oleh user atau belum. Data flow diagram dapat dikembangkan dari level yang paling rendah ke level yang lebih tinggi. DFD level 0 merupakan pengembangan dari diagram konteks, DFD level 1 merupakan pengembangan dari DFD level 0. Tiap proses dari DFD dapat dikembangkan lagi menjadi lebih detail sampai proses-proses tersebut tidak dapat dikembangkan lagi.



Diagram Konteks


Pada diagram ini dapat dilihat bahwa sistem penjualan toko handphone ini melibatkan lima external entity yaitu supplier, pegawai, manager, pimpinan dan costumer. Penjelasan secara singkat dari diagram diatas adalah supplier akan menawarkan barang pada system, lalu system akan memberikan daftar barang apa saja yang akan dibeli, kemudian costumer akan membeli barang. Semua transaksi yang dilakukan baik antara supplier ataupun costumer akan dicatat oleh pegawai. Selanjutnya, system akan memberikan laporan keuangan dan stock barang kepada manager sedangkan laporan yang diberikan pada pimpinan hanyalah laporan keuangan.
Data Flow Diagram level 0


Pada tahap ini terdapat tiga proses utama yang dilakukan oleh system, yaitu proses pengecekan barang, proses transaksi penjualan, dan proses pembuatan laporan.
Data Flow Diagram level 1 proses 1( pengecekkan stock barang)

Tahap ini adalah penjabaran dari proses pertama pada DFD. Sistem akan melakukan pemeriksaan barang terlebih dahulu. Apakah setiap barang yang ada kurang dari sepuluh, karena disini ditetapkan bahwa setiap barang yang jumlah stock nya kurang dari sepuluh akan dipesan ke supplier, tapi jika tidak, maka pemesanan tidak akan dilakukan. Pemesanan juga dapat dilakukan jika terdapat barang baru. Pengecekan dilakukan dengan pegawai akan memasukkan data stock barang pada system dan data akan dimasukkan kedalam data store barang. Selanjtnya adalah pembelian barang kepada supplier. Disini pegawai kembali berperan, pegawai akan memasukkan daftar pembelian, dat suppier dan pembayaran. Semua transaksi disini akan dimasukkan ke dalam data store transaksi. Setelah itu terdapat proses entry data. Entry data disini dimaksudkan untuk memasukkan data-data pembelian yang akan disimpan ke dalam data store supplier dan data store barang. Sehingga data akan mudah untuk diupdate.
Data Flow Diagram level 1 proses 2 (transaksi penjualan)


Pada tahap ini dapat dilihat bahwa pembeli akan melakukan pembelian barang, kemudian system akan memberikan harga barang,barang dan bukti pembayarannya kemudian system akan menyimpan data tersebut ke dalam data store barang, agar pada data store barang diupdate lagi perubahannya. Kemudian dilakukan pemasukkan data penjualan ke dalam data store transaksi dan data store barang.
Data Flow Diagram Level 1 proses 3 (pencatatan data)

Pada proses ini,pembuatan laporan barang akan dilakukan. Sistem akan mengambil data barang dan data stock barang pada data store barang kemudian akan mengolahnya dan laporan jumlah stock barangnya akan diberikan kepda manager, selanjutnya adalah pembuatan laporan transaksi penjualan. Data-data untuk pembuatan laporan transaksi penjualan barang akan diambil dari data store transaksi kemudian akan diolah dan akan menghasilkan laporan keuangan, yang akan diberikan kepada manager dan pimpinan.

Desain Enhanced Entity Relationship Diagram (EERD)

 

READ MORE - DFD - Data Flow Diagram, Level 1

"DIAGRAM KONTEKS"

Diagram konteks (Context Diagram) adalah suatu diagram alir yang tingkat tinggi yang menggambarkan seluruh jaringan, masukan dan keluaran. sistem yang dimaksud adalah untuk menggambarkan sistem yang sedang berjalan. mengidentifikasikan awal dan akhir, data awal dan akhir yang masuk dan keluaran sistem. Diagram ini merupakan gambaran umum sistem yang nantinya akan kita buat. secara uraian dapat dikatakan bahwa diagram konteks itu berisi siapa saja yang memberikan data (input-an) ke sistem serta kepada siapa data informasi yang harus dihasilkan sistem.

Diagram konteks adalah diagram yang terdiri dari suatu proses dan menggambarkan ruang lingkup suatu sistem.Ia akan memberi gambaran tentang keseluruhan sistem. Sistem dibatasi oleh boundary (dapat digambarkan dengan garis putus). Dalam diagram konteks hanya ada satu proses. Tidak boleh ada store dalam diagram konteks.

Contoh diagram konteks

READ MORE - "DIAGRAM KONTEKS"

Model Sekuensial Linier, Prototype, dan RAD

MODEL SEKUENSIAL LINIER

Model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut :

1. Rekayasa dan pemodelan sistem/informasi

Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.

2. Analisis kebutuhan Software

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.

3. Desain

Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.

4. Generasi Kode

Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.

5. Pengujian

Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.

6. Pemeliharaan

Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yangdilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

Kekurangan

Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah :

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.

2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan halini dan mengalami kesulitan untuk mengakomodasi ketidakpastiannatural yang ada pada bagian awal beberapa proyek.

3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka

4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier

Kelebihan

1. Software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik.

2. Document pengembangan sistem sangat terorganisir, karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

MODEL PROTOTYPING

Empat langkah yang menjadi karakteristik metode Prototyping yaitu

1. Pemilihan fungsi, mengacu pada pemilahan fungsi yang harus ditampilkan oleh prototyping. Pemilahan harus selalu dilakukan berdasarkan pada tugas-tugas yang relevan yang sesuai dengan contoh kasus yang akan diperagakan

  

2. Penyusunan Sistem Informasi, bertujuan untuk memenuhi permintaan akan tersedianya prototype

  

3. Evaluasi

  

4. Penggunaan Selanjutnya

Tahapan-tahapan Prototyping

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

Jenis-jenis Prototyping

Feasibility prototyping – digunakan untuk menguji kelayakan dari teknologi yang akan digunakan untuk system informasi yang akan disusun.

Requirement prototyping – digunakan untuk mengetahui kebutuhan aktivitas bisnis user.

Desain Prototyping -  digunakan untuk mendorong perancangan system informasi yang akan digunakan.

Implementation prototyping – merupakan lanjytan dari rancangan protipe, prototype ini langsung disusun sebagai suatu system informasi yang akan digunakan.

Teknik-teknik Prototyping meliputi

1. Perancangan Mode

2. Perancangan Dialog

3. Simulasi

Keunggulan dan Kelemahan Prototyping

Keunggulan Prototyping :

1.     End user dapat berpartisipasi aktif

2.     Penentuan kebutuhan lebih mudah diwujudkan

3.     Mempersingkat waktu pengembangan SI

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 :

1.     Proses analisis dan perancangan terlalu singkat

2.     Mengesampingkan alternatif pemecahan masalah

3.     Bisanya kurang fleksible dalam mengahadapi perubahan

4.     Prototype yang dihasilkan tidak selamanya mudah dirubah

5.     Prototype terlalu cepat selesai

MODEL RAPID APPLICATION DEVELOPMENT (RAD)

Jika menggunkan RAD model, kualitas team harus solid dan punya disiplin tinggi.

Kekurangan :

1. untuk project yang besar dan membutuhkan sumber daya manusia yang cukup.

2. Jika developer dan customer berkomitmen untuk menyelesaikan project dalam waktu yang singkat, maka project akan gagal.

3.  Jika pemodulan project tidak tepat, maka pembangunan komponen untuk RAD akan bermasalah.

Rapid application development (RAD) atau rapid prototyping adalah model proses pembangunan perangkat lunak yang tergolong dalam teknik incremental (bertingkat). RAD menekankan pada siklus pembangunan pendek, singkat, dan cepat. Waktu yang singkat adalah batasan yang penting untuk model ini. Rapid application development menggunakan metode iteratif (berulang) dalam mengembangkan sistem dimana working model (model bekerja) sistem dikonstruksikan di awal tahap pengembangan dengan tujuan menetapkan kebutuhan (requirement) user dan selanjutnya disingkirkan. Working model digunakan kadang-kadang saja sebagai basis desain dan implementasi sistem final.

Model RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat yang dicapai dengan menerapkan :

1.   Component based construction ( pemrograman berbasis komponen bukan prosedural).

2.   Penekanan pada penggunaan ulang (reuse) komponen perangkat lunak yang telah ada.

3.   Pembangkitan kode program otomatis/semi otomatis.

4.   Multiple team (banyak tim), tiap tim menyelesaikan satu tugas yang selevel tapi tidak sama.

Banyaknya tim tergantung dari area dan kompleksitasnya sistem yang dibangun.

Jika keutuhan yang diinginkan pada tahap analisis kebutuhan telah lengkap dan jelas, maka waktu yang dibutuhkan untuk menyelesaikan secara lengkap perangkat lunak yang dibuat adalah berkisar 60 sampai 90 hari. Model RAD hampir sama dengan model waterfall, bedanya siklus pengembangan yang ditempuh model ini sangat pendek dengan penerapan teknik yang cepat.

Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan beberapa tim dalam waktu yang hampir bersamaan dalam waktu yang sudah ditentukan. Model ini melibatkan banyak tim, dan setiap tim mengerjakan tugas yang selevel, namun berbeda. Sesuai dengan pembagian modul sistem.

Kelemahan

Beberapa hal (kelebhan dan kekurangan) yang perlu diperhatikan dalam implementasi pengembangan menggunakan model RAD :

1. Model RAD memerlukan sumber daya yang cukup besar, terutama untuk proyek dengan skala besar.

2. Model ini cocok untuk proyek dengan skala besar.

3. Model RAD memerlukan komitmen yang kuat antara pengembang dan pemesssan, bahkan keduanya bisa tergabung dalam 1 tim

4. kinerja dari perangkat lunak yang dihasilkan dapat menjadi masalah manakala kebutuhan-kebutuhan diawal proses tidak dapat dimodulkan, sehingga pendekatan dengan model ini kurang bagus.

5. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

6. Penghalusan dan penggabungan dari beberapa tim di akhir proses sangat diperlukan dan ini memerlukan kerja keras.

7. Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi

8. Risiko teknis yang tinggi juga kurang cocok untuk model ini.

Kelebihan

1. Fleksibilitas yang lebih besar

2. Sangat mengurangi manual coding

3. Peningkatan keterlibatan pengguna

4. Mungkin lebih sedikit cacat

5. Mungkin dikurangi biaya

6. Singkat siklus pengembangan

Sumber : http://vanrpl.blogspot.com/2014/02/2-model-sekuensial-linier-prototype-dan.html

READ MORE - Model Sekuensial Linier, Prototype, dan RAD

DEFINISI RPL (Rekayasa Perangkat Lunak)

Apa sih RPL itu????

Wikipedia : Rekayasa perangkat lunak adalah satu bidang profesi yang mendalami cara-cara pembangunan perangkat lunak termasuk pembuatan,pemeliharaan,manajemen organisasi pengembangan perangkat lunak dan manajemen kualitas.

IEEE Computer Society : Rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.

Rekayasa Perangkat Lunak adalah pengubahan perangkat lunak itu sendiri guna mengembangkan, memelihara, dan membangun kembali dengan menggunakan prinsip reakayasa untuk menghasilkan perangkat lunak yang dapat bekerja lebih efisien dan efektif untuk pengguna.

Tujuan Rekayasa Perangkat Lunak

Secara lebih khusus kita dapat menyatakan tujuan dan Rekaya Perangkat Lunak ini adalah:

1. Memperoleh biaya produksi perangkat lunak yang rendah.
2. Menghasilkan pereangkat lunak yang kinerjanya tinggi, andal dan tepat waktu
3. Menghasilkan perangkat lunak yang dapat bekerja pada berbagai jenis platform
4. Menghasilkan perangkat lunak yang biaya perawatannya rendah

Kriteria Dalam Merekayasa Perangkat Lunak

1. Dapat terus dirawat dan dipelihara (maintainability)
2. Dapat mengikuti perkembangan teknologi (dependability)
3. Dapat mengikuti keinginan pengguna (robust).
4. Efektif dan efisien dalam menggunakan energi dan penggunaannya.
5. Dapat memenuhi kebutuhan yang diinginkan (usability).

Ruang Lingkup Rekayasa Perangkat Lunak

1. Software Requirements berhubungan dengan spesifikasi kebutuhan dan persyaratan perangkat lunak.
2. Software desain mencakup proses penampilan arsitektur, komponen, antar muka, dan karakteristik lain dari perangkat lunak.
3. Software construction berhubungan dengan detail pengembangan perangkat lunak, termasuk. algoritma, pengkodean, pengujian dan pencarian kesalahan.
4. Software testing meliputi pengujian pada keseluruhan perilaku perangkat lunak.
5. Software maintenance mencakup upaya-upaya perawatan ketika perangkat lunak telah dioperasikan.
6. Software configuration management berhubungan dengan usaha perubahan konfigurasi perangkat lunak untuk memenuhi kebutuhan tertentu.
7. Software engineering management berkaitan dengan pengelolaan dan pengukuran RPL, termasuk perencanaan proyek perangkat lunak.
8. Software engineering tools and methods mencakup kajian teoritis tentang alat bantu dan metode RPL.

Rekayasa Perangkat Lunak dan Disiplin Ilmu Lain

Cakupan ruang lingkup yang cukup luas, membuat RPL sangat terkait dengan disiplin dengan bidang ilmu lain. tidak saja sub bidang dalam disiplin ilmu komputer namun dengan beberapa disiplin ilmu lain diluar ilmu komputer.

Keterkaitan RPL dengan bidang ilmu lain

• Bidang ilmu manajemen meliputi akuntansi, finansial, pemasaran, manajemen operasi, ekonomi, analisis kuantitatif, manajemen sumber daya manusia, kebijakan, dan strategi bisnis. 
• Bidang ilmu matematika meliputi aljabar linier, kalkulus, peluang, statistik, analisis numerik, dan matematika diskrit.
• Bidang ilmu manajemen proyek meliputi semua hal yang berkaitan dengan proyek, seperti ruang lingkup proyek, anggaran, tenaga kerja, kualitas, manajemen resiko dan keandalan, perbaikan kualitas, dan metode-metode kuantitatif.

Baca juga (disini)
Atau bisa download (disini)

READ MORE - DEFINISI RPL (Rekayasa Perangkat Lunak)