SDLC (SIKLUS HIDUP PENGEMBANGAN PL) Ni Wayan Sumartini Saraswati
MODEL PROSES PERANGKAT LUNAK Model proses perangkat lunak merupakan deskripsi yang disederhanakan dari proses perangkat lunak yang dipresentasikan dengan sudut pandang tertentu. Model, sesuai sifatnya merupakan penyederhanaan, sehingga model proses perangkat lunak merupakan abstraksi dari proses sebenarnya yang dideskripsikan. Model proses juga bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak dan peran orang yang terlibat pada rekayasa perangkat lunak.
JENIS MODEL PROSES PERANGKAT LUNAK a. Model aliran kerja (work flow) Model ini memandang proses dari urutan dan prosedur kerja (input, output dan ketergantungannya). b. Model aliran data (data flow) Model ini merepresentasikan proses sebagai satu set kegiatan yang masing masing melakukan transformasi data. c. Model peran/aksi Model ini merepresentasikan peran orang yang terlibat pada proses perangkat lunak dan kegiatan yang menjadi tanggung jawabnya dalam penyelesaian sebuah sistem.
LIFE CYCLE Life-cycle sebuah perangkat lunak mencakup semua kegiatan yang yang perlu dilakukan untuk mendefinisikan, mengembangkan, menguji, mengantarkan, mengoperasikan, dan memelihara produk perangkat lunak.
BEBERAPA MODEL YANG AKAN DIBAHAS : model fase (phased model) model biaya (cost model) model prototipe (prototype model) model berurutan (successive model).
CAPABILITY MATURITY MODEL (CMM) Penanda untuk mengukur kematangan proses perangkat lunak organisasi CMM mendefinisikan 5 tingkat kematangan proses berdasarkan Proses Key Area (KPA) tertentu
CMM LEVELS Level 5 - Optimisasi (<1%) - Manajemen perubahan proses - Manajemen perubahan teknologi - Pencegahan cacat Level 4 - Managed (<5%) - Manajemen kualitas perangkat lunak - Proses manajemen kuantitatif Level 3 - Definisi (<10%) - Peer review - Koordinasi antarkelompok - Perangkat lunak rekayasa produk - Perangkat lunak manajemen terpadu - Program pelatihan - Definisi proses organisasi - Fokus proses organisasi Level 2 - Repeatable (Pengulangan) (~ 15%) - Manajemen konfigurasi perangkat lunak - Jaminan kualitas perangkat lunak - Pelacakan proyek perangkat lunak dan pengawasan - Perencanaan proyek perangkat lunak Persyaratan manajemen Level 1 - Initial (~ 70%)
SDLC Sebuah kerangka kerja yang menggambarkan kegiatan yang dilakukan pada setiap tahap dari proyek pengembangan perangkat lunak.
SDLC
TAHAPAN DAN KEGIATAN PENDUKUNG
SDLC DAN DOKUMEN
TAHAPAN PROJECT RPL
MODEL WATERFALL
TAHAPAN Analisis Persyaratan - mendefinisikan informasi yang dibutuhkan, fungsi, perilaku, kinerja dan interface. Desain - struktur data, arsitektur perangkat lunak, representasi interface, detail algoritma. Implementasi - source code, database, dokumentasi pengguna, pengujian. Pengujian – pengujian keseluruhan termasuk pengujian fungsional Instalasi – implementasi pada konsumen. Pemeliharaan – tindakan corrective maupun adaptive .
KELEBIHAN MODEL WATERFALL Mudah dimengerti, mudah digunakan Menyediakan struktur untuk staf berpengalaman Milestones dipahami dengan baik Membentuk stabilitas persyaratan Baik untuk pengendalian manajemen (rencana, staf, track) Bekerja dengan baik ketika kualitas lebih penting daripada biaya atau jadwal
KEKURANGAN MODEL WATERFALL Semua persyaratan harus diketahui dimuka Hasil Kerja yang dibuat untuk setiap fase dianggap beku - menghambat fleksibilitas Dapat memberikan kesan kemajuan palsu Tidak mencerminkan sifat pemecahan masalah pengembangan perangkat lunak - iterasi dari fase Integrasi adalah salah satu Ledakan Besar di akhir Sedikit kesempatan bagi pelanggan untuk melihat sistem (sampai mungkin sudah terlambat)
MILESTONE DAN CRITICAL PATH Milestone adalah suatu bagian item pekerjaan yang dibuat seolah-olah menjadi temporary finish atau selesai sementara atas sekelompok atau serangkaian pekerjaan-pekerjaan yang menjadi bagian dari schedule besar. Critical Path Method / CPM adalah suatu rangkaian item pekerjaan dalam suatu proyek yang menjadi bagian kritis atas terselesainya proyek secara keseluruhan. Ini artinya, tidak terselesaikannya tepat waktu suatu pekerjaan yang masuk dalam pekerjaan kritis akan menyebabkan proyek akan mengalami keterlambatan karena waktu finish proyek akan menjadi mundur atau delay.
CRITICAL PATH
CRITICAL PATH
MILESTONES
KAPAN METODE WATERFALL DIGUNAKAN Persyaratan yang sangat dipahami Definisi produk stabil Teknologi dipahami Versi baru dari produk yang sudah ada Porting produk yang sudah ada ke platform baru.
V-SHAPED SDLC MODEL
APA ITU V- SHAPED MODEL Sebuah varian dari Waterfall yang menekankan verifikasi dan validasi produk. Pengujian produk direncanakan secara paralel dengan fase yang sesuai perkembangannya.
FASE DALAM V-SHAPED MODEL Perencanaan proyek dan Persyaratan - mengalokasikan sumber daya Persyaratan Produk dan Spesifikasi Analisis - spesifikasi lengkap dari sistem perangkat lunak Arsitektur atau Tingkat Tinggi Desain - mendefinisikan bagaimana fungsi perangkat lunak memenuhi desain Desain rinci - mengembangkan algoritma untuk masing-masing komponen arsitektur
Produksi, operasi dan pemeliharaan - menyediakan untuk peningkatan dan koreksi Pengujian Sistem dan penerimaan - memeriksa seluruh sistem perangkat lunak dalam lingkungannya Integrasi dan Pengujian - periksa modul interkoneksi dengan benar
Unit testing - periksa setiap modul bertindak seperti yang diharapkan Coding - mengubah algoritma ke dalam perangkat lunak
KELEBIHAN V-SHAPED Menekankan pada perencanaan untuk verifikasi dan validasi produk dalam tahap awal pengembangan produk Setiap penyerahan hasil kerja harus diuji Manajemen proyek dapat melacak kemajuan dengan milestone. Mudah digunakan
KEKURANGAN V-SHAPED Tidak mudah menangani peristiwa bersamaan Tidak menangani iterasi atau fase Tidak mudah menangani perubahan dinamis dalam persyaratan Tidak mengandung kegiatan analisis risiko
KAPAN V-SHAPED DIGUNAKAN Pilihan yang sangat baik untuk sistem yang memerlukan keandalan tinggi - aplikasi kontrol pasien rumah sakit Semua persyaratan dikenal di muka Ketika dapat dimodifikasi untuk menangani perubahan kebutuhan di luar tahap analisis Solusi dan teknologi diketahui
PROTOTYPE MODEL
STRUCTURED EVOLUTIONARY PROTOTYPING MODEL Pengembang membangun sebuah prototipe selama fase persyaratan Prototipe dievaluasi oleh pengguna akhir Pengguna memberikan umpan balik korektif Pengembang lebih menyempurnakan prototipe Ketika pengguna puas, kode prototipe dibawa sampai ke standar yang diperlukan untuk produk akhir.
LANGKAH STRUCTURED EVOLUTIONARY PROTOTYPING MODEL Sebuah rencana proyek awal dikembangkan Sebuah model tulisan bahasa tingkat tinggi parsial dibuat Model adalah sumber untuk spesifikasi persyaratan parsial Sebuah prototipe dibangun dengan atribut dasar dan kritis Perancang membangun
- database - user interface - fungsi algoritmik Perancang menunjukkan prototipe, pengguna mengevaluasi masalah dan menyarankan perbaikan. Loop ini terus berlanjut sampai pengguna puas
KELEBIHAN MODEL PROTOTYPE Pelanggan dapat "melihat" persyaratan sistem karena mereka sedang terlibat dalam pengembangan Pengembang belajar dari pelanggan Sebuah produk akhir yang lebih akurat Persyaratan tak terduga terakomodasi Memungkinkan untuk pengembangan dan desain yang fleksibel Terpantau, tanda-tanda kemajuan tahapan proses terlihat Interaksi dengan prototipe merangsang kesadaran terhadap fungsionalitas tambahan yang diperlukan
KEKURANGAN MODEL PROTOTYPE Kecenderungan untuk meninggalkan pengembangan program terstruktur demi pembangunan “code-dan-fix" Reputasi buruk untuk metode “quick-and-dirty” Perawatan secara keseluruhan mungkin terabaikan Pelanggan mungkin ingin prototipe yang diserahkan Proses dapat tak berakhir (kekeliruan ruang lingkup)
KAPAN MODEL PROTOTYPE DIGUNAKAN Persyaratan tidak stabil atau perlu diklarifikasi Sebagai tahapan klarifikasi kebutuhan pada model waterfall Untuk Mengembangkan user interface Demonstrasi berumur pendek Baru, pengembangan asli Dengan porsi analisis dan desain dari pengembangan berorientasi objek.
RAPID APPLICATION MODEL (RAD)
RAD MODEL Fase perencanaan kebutuhan (sebuah workshop menggunakan diskusi terstruktur terhadap problem bisnis Fase definisi pengguna – alat terotomatisasi yang menangkap informasi dari user Fase konstruksi – productivity tools, such as code generators, screen generators, etc. inside a timebox. (“Do until done”) Fase Cutover -- installation of the system, user acceptance testing and user training
KELEBIHAN RAD MODEL Mengurangi waktu siklus dan peningkatan produktivitas dengan lebih sedikit orang berarti biaya yang lebih rendah Pendekatan time-box meringankan biaya dan jadwal risiko Pelanggan yang terlibat sepanjang siklus lengkap meminimalkan risiko tidak mencapai kepuasan pelanggan dan kebutuhan bisnis Fokus bergerak dari dokumentasi untuk kode (WYSIWYG). Menggunakan konsep pemodelan untuk menangkap informasi tentang bisnis, data, dan proses.
KEKURANGAN RAD MODEL Proses percepatan pembangunan harus memberikan tanggapan cepat bagi pengguna Risiko tidak pernah mencapai penutupan Sulit untuk digunakan dengan sistem lama Membutuhkan sistem yang dapat modular Pengembang dan pelanggan harus berkomitmen untuk kegiatan cepat dalam jangka waktu singkat.
KAPAN MENGGUNAKAN RAD Persyaratan cukup dipahami dengan baik Pengguna yang terlibat sepanjang siklus hidup Proyek dapat disusun menjadi timebox Fungsi disampaikan secara bertahap Kinerja tinggi tidak diperlukan Risiko teknis Rendah Sistem dapat modularized
TIMEBOX MANAGEMENT Dalam manajemen waktu, timeboxing mengalokasikan jangka waktu tertentu, yang disebut kotak waktu, untuk setiap kegiatan yang direncanakan. Beberapa pendekatan manajemen proyek menggunakan timeboxing. Hal ini juga digunakan untuk penggunaan individu untuk mengatasi tugas-tugas pribadi dalam kerangka waktu yang lebih kecil. Ini sering melibatkan penyerahan hasil pekerjaan dan tenggat waktu, yang akan meningkatkan produktivitas pengguna.
INCREMENTAL SDLC MODEL
INCREMENTAL SDLC MODELS Membuat sebuah implementasi parsial dari total sistem Lalu perlahan-lahan menambah fungsionalitas yang meningkat Model inkremental memprioritaskan persyaratan sistem dan kemudian menerapkan mereka dalam grup. Setiap rilis berikutnya dari sistem menambahkan fungsi untuk rilis sebelumnya, sampai semua fungsi yang dirancang telah dilaksanakan.
KELEBIHAN INCREMENTAL SDLC MODELS Mengembangkan bagian berisiko tinggi atau fungsi besar terlebih dahulu Setiap rilis memberikan produk operasional Pelanggan dapat merespon tiap pembangunan Menggunakan "membagi dan menaklukkan" pemecahan tugas Menurunkan biaya penyerahan project awal Pengiriman produk awal lebih cepat Pelanggan mendapatkan fungsi penting lebih awal Risiko perubahan kebutuhan berkurang
KEKURANGAN INCREMENTAL SDLC MODELS Membutuhkan perencanaan dan desain yang baik Membutuhkan definisi awal sistem yang lengkap dan berfungsi penuh untuk memungkinkan definisi penambahan Interface modul yang terdefinisi dengan baik diperlukan (beberapa akan dikembangkan jauh sebelum yang lain) Total biaya dari sistem yang lengkap tidak lebih rendah
KAPAN INCREMENTAL SDLC DIPERLUKAN Risiko, pendanaan, jadwal, kompleksitas program, atau kebutuhan untuk manfaat realisasi awal. Sebagian besar persyaratan diketahui di awal tetapi diharapkan berkembang dari waktu ke waktu Kebutuhan untuk mendapatkan fungsi dasar konsumen lebih awal Pada proyek yang memiliki jadwal pengembangan yang panjang Pada sebuah proyek dengan teknologi baru
INCREMENTAL SDLC MODEL
SPIRAL SDLC MODEL
DESKRIPSI MODEL SPIRAL Menambahkan analisis risiko, dan 4GL RAD prototyping untuk model air terjun Setiap siklus melibatkan urutan yang sama dari langkah-langkah sebagai model proses waterfall
QUADRANT SPIRAL? TENTUKAN TUJUAN, ALTERNATIF DAN KENDALA Tujuan: fungsionalitas, kinerja, antarmuka hardware / software, faktor penentu keberhasilan, dll Alternatif: membangun, reuse, membeli, subkontrak, dll Kendala: biaya, jadwal, antarmuka, dll
SPIRAL QUADRANT? MENGEVALUASI ALTERNATIF, MENGIDENTIFIKASI DAN MENGATASI RISIKO
Alternatif studi relatif terhadap tujuan dan kendala Mengidentifikasi risiko (kurangnya pengalaman, teknologi baru, jadwal yang ketat, proses yang buruk, dll Mengatasi risiko (mengevaluasi apakah uang bisa hilang oleh pengembangan sistem berkelanjutan
SPIRAL QUADRANT? MENGEMBANGKAN PRODUK Kegiatan khas: Membuat desain desain ulasan mengembangkan kode Periksa kode produk uji
SPIRAL QUADRANT? RENCANA FASE BERIKUTNYA Kegiatan khas Mengembangkan rencana proyek Mengembangkan rencana pengelolaan konfigurasi Mengembangkan rencana uji Mengembangkan rencana instalasi
KELEBIHAN MODEL SPIRAL Memberikan indikasi awal risiko yang tidak dapat diatasi, tanpa banyak biaya Pengguna melihat sistem lebih awal karena alat prototyping cepat Fungsi berisiko tinggi yang kritis dikembangkan lebih dulu Desain tidak harus sempurna Pengguna dapat terikat erat dengan semua langkah siklus hidup Umpan balik lebih awal dan terjadi lebih sering dari pengguna Biaya kumulatif dikaji teratur
KELEMAHAN MODEL SPIRAL Waktu yang dihabiskan untuk mengevaluasi risiko terlalu besar untuk proyek-proyek kecil atau berisiko rendah Waktu yang dihabiskan untuk perencanaan, pengaturan ulang tujuan, melakukan analisis risiko dan prototyping mungkin berlebihan Model yang kompleks Keahlian penilaian risiko diperlukan Spiral mungkin akan berlangsung terus tanpa batas Pengembang harus ditugaskan kembali selama kegiatan fase non-pembangunan Mungkin sulit untuk menentukan tujuan, milestone diverifikasi yang menunjukkan kesiapan untuk melanjutkan iterasi berikutnya
KAPAN DIGUNAKAN MODEL SPIRAL Ketika penciptaan prototipe sesuai Ketika biaya dan risiko evaluasi penting Untuk media untuk proyek-proyek berisiko tinggi Komitmen proyek jangka panjang tidak bijaksana karena potensi perubahan prioritas ekonomi Pengguna tidak yakin kebutuhan mereka Persyaratan yang kompleks Lini produk baru Perubahan signifikan diharapkan (penelitian dan eksplorasi)
AGILE SDLC Pengembangan perangkat lunak Agile adalah sekelompok metode pengembangan perangkat lunak di mana persyaratan dan solusi berkembang melalui kolaborasi antara pengorganisasian mandiri, tim lintas fungsional. Ini mendorong perencanaan adaptif, perkembangan evolusioner, penyerahan project dini, perbaikan terus-menerus dan mendorong respon yang cepat dan fleksibel untuk berubah.
AGILE SDLC’S Mempercepat atau memotong satu atau lebih fase siklus hidup perangkat lunak Biasanya kurang lingkup formal dan dikurangi Digunakan untuk aplikasi waktu-kritis Digunakan dalam organisasi yang mempekerjakan metode disiplin
AGILE SDLC
SPRINT
BEBERAPA METODE AGILE SDLC Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Clear Dynamic Software Development Method (DSDM) Rapid Application Development (RAD) Scrum Extreme Programming (XP) Rational Unify Process (RUP)
EXTREME PROGRAMMING - XP Untuk tim kecil-menengah mengembangkan perangkat lunak dengan jelas atau cepat berubah persyaratan Coding adalah aktivitas utama di seluruh proyek perangkat lunak Komunikasi antara rekan tim dilakukan dengan kode Siklus hidup dan perilaku dari obyek yang kompleks didefinisikan dalam kasus uji - lagi dalam kode
DISKUSI
