SDLC (Siklus Hidup Pengembangan PL

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