Proses sebagai problem solving : pengembangan perangkat lunak (PL) dapat dianggap sebagai lingkaran pemecahan masalah. Untuk menyelesaikan masalah besar, dipecah menjadi kecil terus-menerus sampai paling kecil, kemudian diselesaikan (recursive).
Keterangan gambar : status quo (idle)
Model proses / daur hidup PL : model proses untuk Rekayasa Perangkat Lunak (RPL) dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan tool yang digunakan, serta kontrol dan deliverable yang diinginkan.
Linear sequential model (classic life cycle / model cycle)
Model yang paling luas dipakai dan tertua. Mengusulkan suatu pendekatan sekuensial dan sistematis pada pengembangan PL. Meliputi aktivitas-aktivitas :
• System / information engineering (rekayasa dan pemodelan sistem) : menyangkut pengumpulan kebutuhan (requirement gathering) pada level sistem dengan sejumlah kecil analisis serta top desain.
• Analisis : kebutuhan PL, proses requirement gathering diintesifkan dan difokuskan, khususnya pada PL. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan sistem maupun PL didokumentasikan dan direview bersama user.
• Desain : fokus pada 4 hal : desain database, arsitektur PL, interface, dan algoritma prosedural. Proses desain menerjemahkan kebutuhan ke dalam representasi PL sebelum dimulai coding.
• Coding : menerjemahkan desain ke dalam bahasa yang dimengerti mesin.
• Testing : fokus pada :
-Logika internal PL : memastikan bahwa semua statement telah diuji
-Fungsi eksternal : mengarahkan testing untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang diberikan akan menghasilkan output sesuai yang diinginkan.
• Maintenance
Kelemahan model :
• Meskipun mengakomodasi iterasi, model linier melakukannya secara tidak langsung sehingga perubahan-perubahan dapat menyebabkan keraguan saat tim proyek berjalan
• Jika user sulit menyatakan semua kebutuhannya secara explisit, model ini sulit mengakomodasi ketidakpastian itu
• User harus bersabar karena hasil baru bisa dinikmati setelah testing (akhir waktu). Jika ada kesalahan besar yang tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
• Pengembang sering melakukan penundaan yang tidak perlu. Anggota tim harus menunggu anggota tim lain selesai mengerjakan tugasnya yang mempunyai keterkaitan dan ketergantungan tinggi.
Keterangan gambar : status quo (idle)
Model proses / daur hidup PL : model proses untuk Rekayasa Perangkat Lunak (RPL) dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan tool yang digunakan, serta kontrol dan deliverable yang diinginkan.
Linear sequential model (classic life cycle / model cycle)
Model yang paling luas dipakai dan tertua. Mengusulkan suatu pendekatan sekuensial dan sistematis pada pengembangan PL. Meliputi aktivitas-aktivitas :
• System / information engineering (rekayasa dan pemodelan sistem) : menyangkut pengumpulan kebutuhan (requirement gathering) pada level sistem dengan sejumlah kecil analisis serta top desain.
• Analisis : kebutuhan PL, proses requirement gathering diintesifkan dan difokuskan, khususnya pada PL. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan sistem maupun PL didokumentasikan dan direview bersama user.
• Desain : fokus pada 4 hal : desain database, arsitektur PL, interface, dan algoritma prosedural. Proses desain menerjemahkan kebutuhan ke dalam representasi PL sebelum dimulai coding.
• Coding : menerjemahkan desain ke dalam bahasa yang dimengerti mesin.
• Testing : fokus pada :
-Logika internal PL : memastikan bahwa semua statement telah diuji
-Fungsi eksternal : mengarahkan testing untuk menemukan kesalahan-kesalahan dan memastikan bahwa input yang diberikan akan menghasilkan output sesuai yang diinginkan.
• Maintenance
Kelemahan model :
• Meskipun mengakomodasi iterasi, model linier melakukannya secara tidak langsung sehingga perubahan-perubahan dapat menyebabkan keraguan saat tim proyek berjalan
• Jika user sulit menyatakan semua kebutuhannya secara explisit, model ini sulit mengakomodasi ketidakpastian itu
• User harus bersabar karena hasil baru bisa dinikmati setelah testing (akhir waktu). Jika ada kesalahan besar yang tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.
• Pengembang sering melakukan penundaan yang tidak perlu. Anggota tim harus menunggu anggota tim lain selesai mengerjakan tugasnya yang mempunyai keterkaitan dan ketergantungan tinggi.
Tidak ada komentar:
Posting Komentar