Senin, 24 Mei 2010

WATERFALL

WATEEFAL
Definisi Waterfall
A Water fall model adalah salah satu model pengembangan software, dimana kemajuan suatu proses dipandang sebagai terus mengalir ke bawah seperti air terjun.
Tahap – tahap pengembangan waterfall model adalah :

B 1. Analisis dan definisi persyaratan
Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user.
2. Perancangan sistem dan perangkat lunak
Kegiatan ini menentukan arsitektur sistem secara keseluruhan
3. Implementasi dan pengujian unit
Perancangan perangkat lunak direalisasikan sebagai serangkaian program
4. Integrasi dan pengujian sistem
Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sitem telah terpenuhi
5. Operasi dan pemeliharaan
Merupakan fase siklus yang paling lama. Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.
KELEMAHAN & KEUNTUNGAN
A KEUNTUNGAN :
Simple dan mudah diimplementasikan
mudah diatur
Cocok untuk proyek kecil
B KELEMAHAN :
Tidak mengakomodasi perubahan requirement
Resiko ketidakpastian tinggi
Model yang buruk untuk proyek yang berorientasi obyek
Model yang buruk untuk proyek lama
  1. Pengembangan Perangkat Lunak
• Pengembangan Perangkat Lunak untuk suatu sistem informatika atau aplikasi, sangat di tentukan oleh model proses perangkat lunak
• Permasalahan diatas Melibatkan banyak hal seperti user (pegawai dan petugas dari pegawai ), data yang di simpan secara aman dan di akses dengan mudah , dan sistem penghitungan absensi , sehigga model proses yang di gunakan adalah model waterfall.
2 Analisi dan Devinisi persyaratan•
Melakukan kelayakan studi kelayakan yang dapat di lakukan dengan cara survey pada user atau wawancara dengan pihak manajement
• Mendefinisikan tujuan di bangunya sistem dan manfaat adanya sistem yang baru
• Mendefinisikan perangkat sistem yang dimilki
• Mendefinisiksn Perangkat lunak
REFERENSI
A DEFINISI
http://fright.wordpress.com/2009/05/21/water-fall-model/
B CONTOH
http://www.find-pdf.com/cari-contoh++waterfall+.html

MODEL SPIRAL

Model spiral
Definisi
• Model spiral (spiral model) adalah model proses software yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier.

Kelebihan
• Model spiral ini adalah pendekatan yang paling realistik untuk sistem skala besar. Metode ini menggunakan pendekatan evolusioner, sehingga pelanggan dan pengembang dapat mengerti dan bereaksi terhadap suatu resiko yang mungkin terjadi. Model ini membutuhkan konsiderasi langsung terhadap resiko teknis, sehingga diharapkan dapat mengurangi terjadinya resiko yang lebih besar.


Keuntungan
• Mungkin akan agak sulit untuk meyakinkan pelanggan besar, bahwa pendekatan evolusioner ini dapat diatur. Hal ini membutuhkan keahlian tersendiri. Selain itu, jika resiko utama tidak ditemukan, maka masalah bisa muncul kemudian. Sehingga membutuhkan kemampuan manajemen dan perkiraan resiko (risk assessment) yang cukup tinggi.

Tujuan
• untuk pengembangan versi pertambahan software secara cepat. untuk menyelesaikan sistem secara global terlebih dahulu, kemudian untuk feature dari sistem akan dikembangkan kemudian. Sehingga mempercepat dalam pengimplementasian project

Cara Kerja
• Bentuk spiral memberikan gambaran bahwa makin iterasinya membesar, maka menunjukkan makin lengkapnya versi dari perangkat lunak yang digunakan. Selama awal sirkuit, objektif, alternatif dan batasan didefinisikan serta resiko diidentifikasi dan dianalisa. Jika analisa resiko menunjukkan ada ketidakpastian terhadap kebutuhan, maka prototyping harus dibuat pada kuadran engineering. Simulasi dan pemodelan lain dapat digunakan untuk mendefinisikan masalah dan memperbaiki kebutuhan. Pelanggan mengevaluasi hasil engineering (kuadran customer evaluation) dan membuat usulan untuk perbaikan. Berdasarkan masukan dari pelanggan, fase berikutnya adalah planning dan analisis resiko. Setelah analisis resiko, selalu diperiksa apakah proyek diteruskan atau tidak, jika resiko terlalu besar, maka proyek dapat dihentikan.

Again Sistem
1. Customer Communication: komunikasi antara pengembang dengan pelanggan.
2. Planning: penentuan tujuan, alternatif dan batasan.
3. Risk Analysis: analisa alternatif dan identifikasi/pemecahan resiko.
4. Engineering: pengembangan level berikutnya dari produk.
5. Construction and release: testing, instalasi, dan menyediakan support termasuk dengan training pada user dan pembuatan dokumentasi.
6.Customer Evaluation: penilaian terhadap hasil engineering.

PROSES-PROSES PERANGKAT LUNAK

Serangkaian kegiatan dan hasil yang berhubungan dengannya, yang menuju pada dihasilkannya produk perangkat lunak.
Kegiatan-kegiatan mendasar yg umum bagi semua proses Perangkat Lunak :
1. Spesifikikasi Perangkat Lunak à Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan (Perancangan dan Implementasi) Perangkat Lunak à Perangkat lunak yang memenuhi spesifikasi harus di produksi
3. Validasi Perangkat Lunak à Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan.
4. Evolusi Perangkat Lunak à Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.
Model Proses Perangkat Lunak
A. Model air terjun (waterfall) à Biasa juga disebut siklus hidup perangkat lunak. Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
1. Analisis dan Definisi Persyaratan à Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user sistem.
2. Perancangan sistem dan Perangkat Lunak à Proses perancangan sistem membagi persyaratan dalam sistem perangkat keras atau perangkat lunak. Menentukan arsitektur sistem secara keseluruhan.

1. Implementasi dan pengujian unit à Perancangan perangkat lunak direalisasikan sebagai serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.
2. Integrasi dan Pengujian Sistem à Unit program atau program individual diintegrasikan dan diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim ke User.
3. Operasi dan Pemeliharaan à Biasanya merupakan fase siklus yg paling lama (walaupun tidak seharusnya). Sistem diinstall dan di pakai.
Pemeliharaan mencakup koreksi dan berbagai error yg tdk ditemukan pada tahap2 sebelumnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem.
Gambar model waterfall









Masalah dengan model waterfall
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses.

1.Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user).
2.Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.
B. Pengembangan Evolusioner Berdasarkan pada ide untuk mengembangkan implementasi awal, memperlihatkannya kepada user untuk dikomentari, dan memperbaikinya versi demi versi sampai sistem yang memenuhi persyaratan diperoleh.

Tidak ada kegiatan spesifikasi, pengembangan, dan validasi yang terpisah. Kegiatan2 ini dilakukan pada saat yang bersamaan dengan umpan balik yang cepat untuk masing2 kegiatan.

Gambar model Pengembangan Evolusioner












Ada 2 jenis pengembangan evolusioner :
1. Pengembangan Eksplotari à Tujuan proses ini adalah bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Harusnya diawali dengan kebutuhan yang sudah dimengerti.

1. Prototipe yang dapat dibuang (throw-away) à Berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.

Kelebihan model Pengembangan Evolusioner
1.Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan.
2.Sementara user mendapat pemahaman yang lebih baik dari masalah mereka, sistem perangkat lunak dapat merefleksikannya.
C. Model Pengembangan Sistem
Formal
Proses pengembangan Perangkat Lunak didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan.

Ada 2 jenis pengembangan evolusioner :
1. Pengembangan Eksplotari à Tujuan proses ini adalah bekerja dengan pelanggan untuk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Harusnya diawali dengan kebutuhan yang sudah dimengerti.

1. Prototipe yang dapat dibuang (throw-away) à Berkonsentrasi pada eksperimen, dengan persyaratan pelanggan yang tidak dipahami dengan baik.

Kelebihan model Pengembangan Evolusioner
 Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan.

 Sementara user mendapat pemahaman yang lebih baik dari masalah mereka, sistem perangkat lunak dapat merefleksikannya.
C. Model Pengembangan Sistem
Formal
1 Proses pengembangan Perangkat Lunak didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan.
Masalah pada model Pengembangan Evolusioner
2 Kurangnya visibilitas proses à Jika sistem dikembangkan dengan cepat, tidaklah efektif dari segi biaya jika dihasilkan dokumen yang merefleksikan setiap versi sistem.
3 Sistem seringkali memiliki struktur yang buruk à Perubahan yang terus-menerus cenderung merusak struktur perangkat lunak. Penyesuaian perubahan menjadi kian sulit dan mahal.

A Membutuhkan kemampuan khusus.
Masalah dalam Pengembangan Metode Formal
B Memerlukan keahlian khusus dan pelatihan untuk mengaplikasikannya

C Untuk sebagian besar sistem, metode ini tidak memberikan keuntungan biaya atau kualitas yang signifikan dibandingkan dengan pendekatan yang lain.
D. Model Pengembangan Berorientasi
Pemakaian Ulang (Re-Usable)
1 Bergantung pada sejumlah besar komponen perangkat lunak yang dapat dipakai ulang, yang bisa didapat, dan berapa kerangka kerja integrasi untuk komponen-komponen ini.
2 Komponen-komponen ini dapat juga sistem yang disebut COTS (Commercial Off-The-Shelf Systems/Sistem Siap Beli Komersial) yang dapat digunakan untuk memberikan fungsionalitas khusus seperti format teks, perhitungan numerik,dll.
Gambar Model Pengembangan Berorientasi
Pemakaian Ulang (Re-Usable)









B. SPIRAL MODEL


1 proses digambarkan sebagai spiral.
2 Setiap loop mewakili satu fase dari software process.
3 Loop paling dalam berfokus pada kelayakan dari sistem, loop selanjutnya tentang definisi dari kebutuhan, loop berikutnya berkaitan dengan desain sistem dan seterusnya

Setiap Loop dibagi menjadi beberapa sektor :
1. Objective settings (menentukan tujuan): menentukan tujuan dari fase yang ditentukan. Batasan-batasan pada proses dan produk sudah diketahui. Perencanaan sudah disiapkan. Resiko dari proyek sudah diketahui. Alternatif strategi sudah disiapkan berdasarkan resiko-resiko yang diketahui, dan sudah direncanakan.

2. Risk assessment and reduction (Penanganan dan pengurangan resiko): setiap resiko dianalisis secara detil pada sektor ini. Langkah-langkah penanganan dilakukan, misalnya membuat prototype untuk mengetahui ketidakcocokan kebutuhan.



3. Development and Validation (Pembangunan dan pengujian): Setelah evaluasi resiko, maka model pengembangan sistem dipilih.
 Misalnya jika resiko user interface dominan, maka membuat prototype User Interface.
 Jika bagian keamanan yang bermasalah, maka menggunakan model formal dengan perhitungan matematis,
 Jika masalahnya adalah integrasi sistem model waterfall lebih cocok.

4. Planning : Proyek dievaluasi atau ditinjau-ulang dan diputuskan untuk terus ke fase loop selanjutnya atau tidak. Jika melanjutkan ke fase berikutnya rencana untuk loop selanjutnya.

 Pada model spiral, resiko sangat dipertimbangkan.
 Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan.
 Model spiral merupakan pendekatan yang realistik untuk PL berskala besar.
 Pengguna dan pembangun (Perekayasa) bisa memahami dengan baik software yang dibangun karena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik.
 Namun demikian, waktu yang cukup panjang mungkin bukan pilihan bagi pengguna, karena waktu yang lama sama dengan biaya yang lebih besar.
RAD (Rapid Application Development)
1 RAD adalah model proses pembangunan PL yang incremental.
2 RAD menekankan pada siklus pembangunan yang pendek/singkat.
3 RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.
1 Waktu yang singkat adalah batasan yang penting untuk model ini.
2 Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

Rabu, 19 Mei 2010

Model Pengembangan Evolusioner dalam Rekayasa Perangkat Lunak

Model Pengembangan Evolusioner dalam Rekayasa
Perangkat Lunak

Model pengembangan evolusioner ini berdasarkan pada implementasi awal yang akan menghasilkan komentar pemakai, sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangkan. Selain memiliki aktivitas-aktivitas yang terpisah, model ini memberikan umpan balik dengan cepatdan serentak.
Ada 2 tipe dalam model pengembangan evolusioner :
dalam tipe ini, tujuan proses adalah bekerja sama dengan konsumen untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/konsumen. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh konsumen.
permodelan
dalam tipe yang kedua ini, tujuan proses adalah mengetahui kebutuhan-kebutuhan konsumen dan mengembangkan definisi kebutuhan yang lebih baik untuk sistem. Model atau contoh difokuskan pada penelitian bagian-bagian kebutuhan konsumen yang kurang dimengerti.
Pemrograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemrograman evolusioner banyak digunakan dalam pengembangan sistem kecerdasan buatanyang berusaha menyamai kemampuan manusia.
Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.
Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan konsumen. Namun, dari segi teknik dan manajemen, metode ini memiliki masalah mendasar yaitu :
Proses tidak visiblemanager-manager membutuhkan “deliverables” yang teratur untuk mengukur kemajuan. Jika sistem dikemangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.
Sisem-sistem biasanya kurang terstruktur
Kecenderungan perubahan yang terus menerus akan mengurangi struktur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal.
ketrampilan khusus jarang dimiliki
Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan menvalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas (seperti model waterfall).
Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui model ini.
Pengembangan evolusioner lebih tepat untuk :
Pengembangan sistem yang relatif kecil.
Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan mengimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika permodelan digunakan, tidak terlalu mahal.
Pengembangan sistem yang memiliki masahidup yang relatif singkat. Di sini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Contohnya sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Contohnya sistem AI dan interface pemakai.
TUJUAN
1. .Menjelaskan mengapa konteks dari system harus di permodelkan sebagai bagian dari proses requeirement engineering .
2. mengambarkan konsep permodelan perilaku, permodelan data, dan permodelan objek.
3. Memperkenalkan beberapa notasi yang digunakan pada UML (unifed modeling laguange)
4. Memperkenalkan pendekatan Metode formal dan metode Pemodelan form
Pemodelan Perangkat lunak dan modelnya.
1. Pemodelan perangkat lunak membantu rekayasa untuk memahami fungsionalitas dari system.
2.model di gunakan untuk berkomunikasi dengan pada stakeholder.
3.Model yang berbeda akan menampilkan suatu system dari sudud pandang yang berbeda juga.
Sudut pandang pemodelan
1. .Sudud pandang luar (external) akan menampilkan lingkungan atau konteks dari sitem
2. Model proses atau aktifitas Menampilkan proses atau pembangun dari system sama halnya dengan mengambarkan segala aktifitas yang di dukung oleh system
3. Sudut pandang perilaku memperihatkan perilaku dari system tersebut
4. Sudut pandang structural memperlihatkan arsitektur dari system atau data
Model data
1. Kebanyakan system perangkat lunak besar mengumakan database yang juga cukup besar.
2. Bagian terpenting dari pemodelan system adalah mencari bentuk logic data yang di proses dalam proses
3. pemodelan mencari bentuk logic ini merupakan semantic data model
4. contoh pemodelan data yang terkenal adalah mengunakan tehnik ERA modeling.
5. Model ini juga kurang detil, sehingga dibutuhkan deskripsi lebih detil dari masing entitas, atribut dan relasi. Mzka dapat di gunakan data dictionary
Model obyek
1. Model obyek mengambarkan suatu system dalam kelas –kelas obyek
2. kelas obyek merupakan abstraksi dari suatu set obyek dengan atribut dan operasi yang dimiliki oleh masing-masing obyek.
3. model obyek yang berbeda dapat di hasilkan :
• model inheritance
• model aggregasi
• model interaksi

Dharwiyanti, Sri (2003), Pengantar Unified Modeling Language (UML), www.ilmukomputer.com
Kristianto, Adi (2003), Perancangan Sistem Informasi dan Aplikasinya, Gava Media Yogyakarta
Wijana, Katon (1997), Modul Rekayasa Perangkat Lunak, Universitas Kristen Duta Wacana Yogyakarta