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.
Tidak ada komentar:
Posting Komentar