Etik Profesi
Teori Pengembangan Software Waterfall Model Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merup...
Teori Pengembangan Software Waterfall Model
Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.
Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata. Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing. Tahapan model waterfall meliputi :
Waterfall Model adalah sebuah metode pengembangan software yang bersifat sekuensial dan terdiri dari 5 tahap yang saling terkait dan mempengaruhi seperti terlihat pada gambar berikut.
>> Tahap – tahap pengembangan waterfall model adalah :
1. 1. Analisis dan definisi persyaratan
Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user, Dalam tahapan ini jasa, kendala dan tujuan dari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.
Beberapa macam requirement:
# User Requirement (Kebutuhan Pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
# System Requirement (Kebutuhan Sistem)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
# Software Requirement Specification (Spesifikasi Kebutuhan Perangkat Lunak)
Gambaran abstrak dari rancangan perangkat lunak yang menjadi dasar bagi perancangan dan implementasi yang lebih detil
1. 2. Perancangan sistem dan perangkat lunak
Perancangan perangkat lunak adalah proses dimana analisa diterjemahkan menjadi “cetak-biru” untuk membangun perangkat lunak. Awalnya, cetak biru menggambarkan pandangan menyeluruh perangkat lunak. Yaitu, desain diwakili pada tingkat yang dapat langsung ditelusuri pada sistem tertentu objektif dan data yang lebih rinci, fungsional, dan persyaratan yang diperlukan. Seperti terjadi pengulangan desain, perbaikan dari desain sebelumnya.
Kegiatan ini menentukan arsitektur sistem secara keseluruhan Fokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural. Proses ini menerjemahkan syarat / kebutuhan ke dalam sebuah representasi perangkat lunak.
Metode Perancangan:
• Perancangan Data
Yaitu transformasi model data yang dihasilkan oleh proses analisis menjadi struktur data yang dibutuhkan pada saat implementasi.
Hasil perancangan data adalah:
- struktur data siap diprogram
- struktur basis data siap dibuat oleh pemrogram
- prosedur/operasi untuk mengakses data, siap deprogram
• Perancangan Arsitektur
Yaitu definisi keterkaitan antar elemen-elemen utama yang akan membentuk program.
Hasil perancangan arsitektural:
Structure Chart yang merepresentasikan gambaran menyeluruh struktur/ arsitektur perangkat lunak, beserta seluruh hierarki kendali/passing parameter, yang siap dituliskan dalam bentuk modul program.
• Perancangan Antarmuka
Yaitu penjabaran komunikasi: internal perangkat lunak, antara perangkat lunak, dengan sistem diluarnya, dan antara perangkat lunak dengan usernya.
Hasil perancangan antarmuka adalah:
- definisi antarmuka modul yang siap untuk diprogram
- definisi / format rancangan layar yang siap diimplementasikan
• Perancangan Prosedur
Yaitu transformasi elemen struktural dari arsitektur program menjadi deskripsi prosedur.
Hasil perancangan prosedur adalah:
- Flow-chart
- Algoritma/pseudocode/program design language
1. 3. Implementasi dan pengujian unit
Pada tahap ini dilakukan kerja untuk membangun perangkat lunak berdasarkan analisa dan pemodelan yang telah dilakukan. Sehigga hasil dari tahap ini adalah basis data dan source code perangkat lunak.
Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan. Perancangan perangkat lunak direalisasikan sebagai serangkaian program.
1. 4. Integrasi dan pengujian sistem
Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah terpenuhi
Setelah source code dihasilkan, perangkat lunak harus diuji untuk menemukan (dan membenarkan) sebanyak mungkin kesalahan yang dibuat.
Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.
Metode pengetesan:
1. Black box testing
Black box testing memperlakukan pengujian perangkat lunak sebagai “kotak hitam” – tanpa pengetahuan tentang pelaksanaan internal.
2. White box testing
White box testing adalah ketika penguji memiliki akses ke struktur data internal dan algoritma termasuk source code.
1. 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.
Proses pemeliharaan perangkat lunak dan keseluruhan sistem bila terjadi kesalahan pada program, atau terjadi perubahan lingkungan perangkat lunak dan juga bila terjadi perubahan requirements dan maintenance yang bersifat preventif untuk mengantisipasi keadaan yang tidak diinginkan.
Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.
Keuntungan dan Kerugian model Waterfall
• Kelebihan waterfall :
# Developer dituntut bekerja secara disiplin
# Simple dan mudah diimplementasikan
# Dokumen lengkap
# Selalu dalam kontrol SQA
# Maintenance mudah, karena dokumen lengkap
• Kekurangan Waterfall :
# Konsumen kesulitan membaca dokumen, komunikasi menjadi sulit
# Alur linier, proses lambat
# Konsumen tidak dapat melihat hasil hingga akhir tahapan
# Personil tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai
# Model ini hanya pas jika requirement nya dapat dipahami dengan baik dan perubahan yang terjadi sangat terbatas selama proses desain berlangsung.
UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu:
• Use Case Diagram untuk memodelkan proses bisnis.
• Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi.
• Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects.
• Collaboration Diagram untuk memodelkan interaksi antar objects.
• State Diagram untuk memodelkan perilaku objects di dalam sistem.
• Activity Diagram untuk memodelkan perilaku Use Cases dan objects di dalam system.
• Class Diagram untuk memodelkan struktur kelas.
• Object Diagram untuk memodelkan struktur object.
• Component Diagram untuk memodelkan komponen object.
• Deployment Diagram untuk memodelkan distribusi aplikasi.
Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan perspektif pengguna sistem. Use case diagram terdiri atas diagram untuk use case dan actor. Actor merepresentasikan orang yang akan mengoperasikan atau orang yang berinteraksi dengan sistem aplikasi. Use case merepresentasikan operasi-operasi yang dilakukan oleh actor.Use case digambarkan berbentuk elips dengan nama operasi dituliskan di dalamnya. Actor yang melakukan operasi dihubungkan dengan garis lurus ke use case.
Sequence diagram menjelaskan secara detail urutan proses yang dilakukan dalam sistem untuk mencapai tujuan dari use case: interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan antar operasi, dan informasi yang diperlukan oleh masing-masing operasi.
Collaboration diagram dipakai untuk memodelkan interaksi antar object di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh object.
Class diagram merupakan diagram yang selalu ada di permodelan sistem berorientasi objek. Class diagram menunjukkan hubungan antar class dalam sistem yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk mencapai suatu tujuan!
State Diagram berfungsi untuk memodelkan keadaan – keadaan yang mungkin dimiliki oleh sebuah objek. Model ini memungkinkan untuk menangkap kejadian – kejadian (event) yang penting dan efeknya setelah kejadian (event) tersebut.
Object diagram dipergunakan untuk memperlihatkan perubahan nilai (data) yang berubah sesuai dengan waktu sehingga kita dapat menjadikan object diagram sebagai acuan uji apakah implementasi dari sistem kita telah berjalan dengan seharusnya atau tidak
Referensi :
http://angga17kireina.wordpress.com
http://id.wikipedia.org/wiki/Unified_Modeling_Language#Use_Case_Diagram
Waterfall model pertama kali diperkenalkanoleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.
Model ini telah diperoleh dari proses rekayasa lainnya dan menawarkan cara pembuatan rekayasa perangkat lunak secara lebih nyata. Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing. Tahapan model waterfall meliputi :
Waterfall Model adalah sebuah metode pengembangan software yang bersifat sekuensial dan terdiri dari 5 tahap yang saling terkait dan mempengaruhi seperti terlihat pada gambar berikut.
>> Tahap – tahap pengembangan waterfall model adalah :
1. 1. Analisis dan definisi persyaratan
Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dengan user, Dalam tahapan ini jasa, kendala dan tujuan dari konsultasi dengan pengguna sistem. Kemudian semuanya dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Dengan kata lain, dalam tahapn ini dilakukan analisa kebutuhan, kemudian diverifikasi klien dan tim SQA.
Beberapa macam requirement:
# User Requirement (Kebutuhan Pengguna)
Pernyataan tentang layanan yang disediakan sistem dan tentang batasan-batasan operasionalnya. Dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.
# System Requirement (Kebutuhan Sistem)
Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
# Software Requirement Specification (Spesifikasi Kebutuhan Perangkat Lunak)
Gambaran abstrak dari rancangan perangkat lunak yang menjadi dasar bagi perancangan dan implementasi yang lebih detil
1. 2. Perancangan sistem dan perangkat lunak
Perancangan perangkat lunak adalah proses dimana analisa diterjemahkan menjadi “cetak-biru” untuk membangun perangkat lunak. Awalnya, cetak biru menggambarkan pandangan menyeluruh perangkat lunak. Yaitu, desain diwakili pada tingkat yang dapat langsung ditelusuri pada sistem tertentu objektif dan data yang lebih rinci, fungsional, dan persyaratan yang diperlukan. Seperti terjadi pengulangan desain, perbaikan dari desain sebelumnya.
Kegiatan ini menentukan arsitektur sistem secara keseluruhan Fokus pada struktur data, arsitektur perangkat lunak, representasi interface, dan detail algoritma prosedural. Proses ini menerjemahkan syarat / kebutuhan ke dalam sebuah representasi perangkat lunak.
Metode Perancangan:
• Perancangan Data
Yaitu transformasi model data yang dihasilkan oleh proses analisis menjadi struktur data yang dibutuhkan pada saat implementasi.
Hasil perancangan data adalah:
- struktur data siap diprogram
- struktur basis data siap dibuat oleh pemrogram
- prosedur/operasi untuk mengakses data, siap deprogram
• Perancangan Arsitektur
Yaitu definisi keterkaitan antar elemen-elemen utama yang akan membentuk program.
Hasil perancangan arsitektural:
Structure Chart yang merepresentasikan gambaran menyeluruh struktur/ arsitektur perangkat lunak, beserta seluruh hierarki kendali/passing parameter, yang siap dituliskan dalam bentuk modul program.
• Perancangan Antarmuka
Yaitu penjabaran komunikasi: internal perangkat lunak, antara perangkat lunak, dengan sistem diluarnya, dan antara perangkat lunak dengan usernya.
Hasil perancangan antarmuka adalah:
- definisi antarmuka modul yang siap untuk diprogram
- definisi / format rancangan layar yang siap diimplementasikan
• Perancangan Prosedur
Yaitu transformasi elemen struktural dari arsitektur program menjadi deskripsi prosedur.
Hasil perancangan prosedur adalah:
- Flow-chart
- Algoritma/pseudocode/program design language
1. 3. Implementasi dan pengujian unit
Pada tahap ini dilakukan kerja untuk membangun perangkat lunak berdasarkan analisa dan pemodelan yang telah dilakukan. Sehigga hasil dari tahap ini adalah basis data dan source code perangkat lunak.
Selama tahap ini, desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Desain yang telah disetujui, diubah dalam bentuk kode-kode program. Tahap ini, kode-kode program yang dihasilkan masih pada tahap modul-modul. Diakhir tahap ini, tiap modul di testing tanpa diintegrasikan. Perancangan perangkat lunak direalisasikan sebagai serangkaian program.
1. 4. Integrasi dan pengujian sistem
Unit program diintegrasikan atau diuji sebagai sistem yang lengkap untuk menjamin bahwa persyaratan sistem telah terpenuhi
Setelah source code dihasilkan, perangkat lunak harus diuji untuk menemukan (dan membenarkan) sebanyak mungkin kesalahan yang dibuat.
Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk meyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Setelah uji coba, sistem disampaikan ke konsumen.
Metode pengetesan:
1. Black box testing
Black box testing memperlakukan pengujian perangkat lunak sebagai “kotak hitam” – tanpa pengetahuan tentang pelaksanaan internal.
2. White box testing
White box testing adalah ketika penguji memiliki akses ke struktur data internal dan algoritma termasuk source code.
1. 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.
Proses pemeliharaan perangkat lunak dan keseluruhan sistem bila terjadi kesalahan pada program, atau terjadi perubahan lingkungan perangkat lunak dan juga bila terjadi perubahan requirements dan maintenance yang bersifat preventif untuk mengantisipasi keadaan yang tidak diinginkan.
Sistem diinstall dan dipakai. Perbaikan mencakup koreksi dari berbagai error, perbaikan dan implementasi unit sistem dan pelayanan sistem.
Keuntungan dan Kerugian model Waterfall
• Kelebihan waterfall :
# Developer dituntut bekerja secara disiplin
# Simple dan mudah diimplementasikan
# Dokumen lengkap
# Selalu dalam kontrol SQA
# Maintenance mudah, karena dokumen lengkap
• Kekurangan Waterfall :
# Konsumen kesulitan membaca dokumen, komunikasi menjadi sulit
# Alur linier, proses lambat
# Konsumen tidak dapat melihat hasil hingga akhir tahapan
# Personil tidak bekerja optimal, karena ada waktu tunggu sebuah tahapan selesai
# Model ini hanya pas jika requirement nya dapat dipahami dengan baik dan perubahan yang terjadi sangat terbatas selama proses desain berlangsung.
UML menyediakan 10 macam diagram untuk memodelkan aplikasi berorientasi objek, yaitu:
• Use Case Diagram untuk memodelkan proses bisnis.
• Conceptual Diagram untuk memodelkan konsep-konsep yang ada di dalam aplikasi.
• Sequence Diagram untuk memodelkan pengiriman pesan (message) antar objects.
• Collaboration Diagram untuk memodelkan interaksi antar objects.
• State Diagram untuk memodelkan perilaku objects di dalam sistem.
• Activity Diagram untuk memodelkan perilaku Use Cases dan objects di dalam system.
• Class Diagram untuk memodelkan struktur kelas.
• Object Diagram untuk memodelkan struktur object.
• Component Diagram untuk memodelkan komponen object.
• Deployment Diagram untuk memodelkan distribusi aplikasi.
Use case diagram digunakan untuk memodelkan bisnis proses berdasarkan perspektif pengguna sistem. Use case diagram terdiri atas diagram untuk use case dan actor. Actor merepresentasikan orang yang akan mengoperasikan atau orang yang berinteraksi dengan sistem aplikasi. Use case merepresentasikan operasi-operasi yang dilakukan oleh actor.Use case digambarkan berbentuk elips dengan nama operasi dituliskan di dalamnya. Actor yang melakukan operasi dihubungkan dengan garis lurus ke use case.
Sequence diagram menjelaskan secara detail urutan proses yang dilakukan dalam sistem untuk mencapai tujuan dari use case: interaksi yang terjadi antar class, operasi apa saja yang terlibat, urutan antar operasi, dan informasi yang diperlukan oleh masing-masing operasi.
Collaboration diagram dipakai untuk memodelkan interaksi antar object di dalam sistem. Berbeda dengan sequence diagram yang lebih menonjolkan kronologis dari operasi-operasi yang dilakukan, collaboration diagram lebih fokus pada pemahaman atas keseluruhan operasi yang dilakukan oleh object.
Class diagram merupakan diagram yang selalu ada di permodelan sistem berorientasi objek. Class diagram menunjukkan hubungan antar class dalam sistem yang sedang dibangun dan bagaimana mereka saling berkolaborasi untuk mencapai suatu tujuan!
State Diagram berfungsi untuk memodelkan keadaan – keadaan yang mungkin dimiliki oleh sebuah objek. Model ini memungkinkan untuk menangkap kejadian – kejadian (event) yang penting dan efeknya setelah kejadian (event) tersebut.
Object diagram dipergunakan untuk memperlihatkan perubahan nilai (data) yang berubah sesuai dengan waktu sehingga kita dapat menjadikan object diagram sebagai acuan uji apakah implementasi dari sistem kita telah berjalan dengan seharusnya atau tidak
Referensi :
http://angga17kireina.wordpress.com
http://id.wikipedia.org/wiki/Unified_Modeling_Language#Use_Case_Diagram
2 komentar
wah makasih mas atas ilmunya :) , bermanfaat banget .
Reply@frozen fox: iya mudah"han bermanfaat ya makasih udah berkunjung ke sni...
Reply