SIKLUS HIDUP PEMBANGUNAN SOFTWARE © 2008, 2012 εμραμαδηάν

Pendekatan Pembangunan SOFTWARE (1) Masa lalu (pertengahan abad XX): Tidak ada acuan proses pembangunan perangkat lunak tidak terstruktur. Perangkat lunak sulit dikelola dan dikendalikan.

Pendekatan Pembangunan SOFTWARE (2) Menurut Knott dan Dawson (1999:20), pembangun-an perangkat lunak secara terstruktur memberikan keuntungan sbb: Memecah masalah menjadi lebih kecil shg mudah dipahami. Lebih fokus. Mendukung perencanaan dan pengendalian  meningkatkan waktu estimasi. Kemajuan terukur. Pengkodean dan dokumentasi lebih baik.

PDLC (Program Development Life Cycle) SDLC (Software Development Life Cycle)

Software Development Life Cycle (SDLC)

Requirements (Kebutuhan)

Requirements (Kebutuhan) Problem membutuhkan solusi Pemahaman user terhadap masalah subjektiv (tidak sempurna) Analis bersama user mendefinisikan kebutuhan user. Hasilnya requirement definiton (definisi kebutuhan) yang mudah dipahami oleh user.

Spesifikasi kebutuhan Analis sistem menulis kembali hal-hal yg tidak jelas dalam definisi kebutuhan. Hasilnya adalah requirement specification (spesifikasi kebutuhan). Dokumen terstruktur Lebih formal Tidak ada interpretasi ganda Sebagai dasar kontrak antara client dan developer

spesifikasi fungsional Analis sistem menspesifikasikan sebuah sistem yg memenuhi spesifikasi kebutuhan. Hasilnya adalah functional specification (spesifikasi fungsional).

spesifikasi fungsional Functional specification (spesifikasi fungsional) merupakan dokumen yang berisi: Pendahuluan Latar belakang mengapa sistem diperlukan Tujuan proyek Kebutuhan fungsional Kebutuhan nonfungsional

Kebutuhan fungsional Data Proses (apa yang dilakukan sistem) User-interface (antarmuka pemakai)

Kebutuhan nonfungsional Pembakuan Limitasi (biaya, tgl penyerahan, konfigurasi, bahasa, sumber daya) Kebutuhan kinerja Kebutuhan verifikasi

desain Desain Basis data Proses Human computer interaction (HCI) ERD (Entity Relationship Diagram) Normalisasi Proses DFD (data flow diagram) Human computer interaction (HCI) screen layout (menu, form, pesan kesalahan, dsb) navigasi antarlayar Report (laporan) Object oriented  UML (unified modeling language)

build Build Coding (Pengkodean) Konstruksi  Mengintegrasikan modul/objek

Pengujian (Testing) Apakah sistem bekerja dengan baik? Apakah masih ada error/bug ‘kutu’?

Level Pengujian Unit testing (pengujian unit) dilakukan pada unit modul Integration testing (pengujian integrasi). Apakah komponen sistem berinteraksi dengan benar? System testing – Pengujian akhir pada sistem secara keseluruhan. Acceptance testing – oleh user/client dg/tanpa kehadiran pengembang, bagaimana sistem dioperasikan pd lingkungan kerja normal dg data real & dilakukan secara real time. Regression testing – pengujian dilakukan untuk meyakinkan tidak ada ‘kutu’ baru setelah adanya perubahan yang cukup berarti pada PL.

Pengujian Statis/Dinamis Pengujian kode sumber hendaknya dilakukan secara statis maupun dinamis. Pengujian statis dilakukan dg menginspeksi kode pd layar/ kertas, desain, spesifikasi, dsb. Pengujian dinamis dilakukan dg menjalankan program untuk mengidentifikasi adanya error. Pengujian dinamis dapat dilakukan dengan cara: White box Black box

penguji Siapakah yg melakukan pengujian & evaluasi? User: alpha testing, beta testing Client Pengguna awam  skema warna, user interface Pengguna ahli  hal-hal teknis Pembimbing Pengembang

Rencana Pengujian

Pengujian Tambahan Volume testing ‘pengujian volume’ Usability testing  user friendly Installability  kestabilan pd sistem berbeda Recovery testing pengujian pemulihan kalau terjadi kegagalan Documentation testing ‘pengujian dokumentasi’ on-line dan off-line

Implementasi Set up perangkat lunak Set up file data / basis data Acceptance testing Pelatihan Implementasi prosedur kerja Dokumentasi