SDLC (Siklus Hidup Pengembangan PL · PDF filePelanggan yang terlibat sepanjang siklus ......
Transcript of SDLC (Siklus Hidup Pengembangan PL · PDF filePelanggan yang terlibat sepanjang siklus ......
SDLC (SIKLUS HIDUP
PENGEMBANGAN PL)Ni Wayan Sumartini Saraswati
MODEL PROSES PERANGKAT LUNAK
� Model proses perangkat lunak merupakandeskripsi yang disederhanakan dari prosesperangkat lunak yang dipresentasikan dengansudut pandang tertentu.
Model, sesuai sifatnya merupakan� Model, sesuai sifatnya merupakanpenyederhanaan, sehingga model prosesperangkat lunak merupakan abstraksi dariproses 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 danprosedur kerja (input, output danketergantungannya).
b. Model aliran data (data flow) b. Model aliran data (data flow)
� Model ini merepresentasikan proses sebagai satu set kegiatan yang masing masing melakukantransformasi data.
c. Model peran/aksi
� Model ini merepresentasikan peran orang yang terlibat pada proses perangkat lunak dan kegiatanyang menjadi tanggung jawabnya dalampenyelesaian 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. 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)
tertentutertentu
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 � - 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. 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� 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� 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 pekerjaanyang dibuat seolah-olah menjadi temporary finish atau selesai sementara atas sekelompokatau serangkaian pekerjaan-pekerjaan yang menjadi bagian dari schedule besar.
Critical Path Method / CPM adalah suatu� Critical Path Method / CPM adalah suaturangkaian item pekerjaan dalam suatu proyekyang menjadi bagian kritis atas terselesainyaproyek secara keseluruhan. Ini artinya, tidakterselesaikannya tepat waktu suatu pekerjaanyang masuk dalam pekerjaan kritis akanmenyebabkan proyek akan mengalamiketerlambatan karena waktu finish proyek akanmenjadi 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.� 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 danPersyaratan - mengalokasikansumber daya
� Persyaratan Produk danSpesifikasi Analisis - spesifikasilengkap dari sistem perangkatlunak
� Produksi, operasi danpemeliharaan - menyediakanuntuk peningkatan dan koreksi
� Pengujian Sistem danpenerimaan - memeriksa seluruhsistem perangkat lunak dalamlingkungannya
lunak
� Arsitektur atau Tingkat TinggiDesain - mendefinisikanbagaimana fungsi perangkatlunak memenuhi desain
� Desain rinci - mengembangkanalgoritma untuk masing-masingkomponen arsitektur
� Integrasi dan Pengujian - periksamodul interkoneksi denganbenar
� Unit testing - periksa setiapmodul bertindak seperti yang diharapkan
� Coding - mengubah algoritmake 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� 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� 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� 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� 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 parsialdibuat
� Model adalah sumber untuk spesifikasi persyaratanparsial
� Sebuah prototipe dibangun dengan atribut dasar dankritis
� Sebuah prototipe dibangun dengan atribut dasar dankritis
� 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 sistemkarena mereka sedang terlibat dalampengembangan
� Pengembang belajar dari pelanggan
� Sebuah produk akhir yang lebih akuratSebuah produk akhir yang lebih akurat
� Persyaratan tak terduga terakomodasi
� Memungkinkan untuk pengembangan dandesain yang fleksibel
� Terpantau, tanda-tanda kemajuan tahapanproses terlihat
� Interaksi dengan prototipe merangsangkesadaran terhadap fungsionalitas tambahanyang 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� 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� 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 useryang menangkap informasi dari user
� Fase konstruksi – productivity tools, such as code
generators, screen generators, etc. inside a time-
box. (“Do until done”)
� Fase Cutover -- installation of the system, user
acceptance testing and user training
KELEBIHAN RAD MODEL
� Mengurangi waktu siklus dan peningkatanproduktivitas dengan lebih sedikit orang berartibiaya yang lebih rendah
� Pendekatan time-box meringankan biaya danjadwal risiko
Pelanggan yang terlibat sepanjang siklus� Pelanggan yang terlibat sepanjang sikluslengkap meminimalkan risiko tidak mencapaikepuasan pelanggan dan kebutuhan bisnis
� Fokus bergerak dari dokumentasi untuk kode(WYSIWYG).
� Menggunakan konsep pemodelan untukmenangkap informasi tentang bisnis, data, danproses.
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� 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� 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� 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� 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" � 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 penambahandefinisi 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 ketetapi 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, sub-
kontrak, dllkontrak, 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, dllburuk, 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� Periksa kode
� produk uji
SPIRAL QUADRANT? RENCANA FASE
BERIKUTNYA
Kegiatan khas
� Mengembangkan rencana proyek
� Mengembangkan rencana pengelolaan
konfigurasi
Mengembangkan rencana uji� Mengembangkan rencana uji
� Mengembangkan rencana instalasi
KELEBIHAN MODEL SPIRAL
� Memberikan indikasi awal risiko yang tidakdapat diatasi, tanpa banyak biaya
� Pengguna melihat sistem lebih awal karena alatprototyping cepat
� Fungsi berisiko tinggi yang kritis dikembangkanlebih duluFungsi berisiko tinggi yang kritis dikembangkanlebih dulu
� Desain tidak harus sempurna
� Pengguna dapat terikat erat dengan semualangkah siklus hidup
� Umpan balik lebih awal dan terjadi lebih seringdari pengguna
� Biaya kumulatif dikaji teratur
KELEMAHAN MODEL SPIRAL
� Waktu yang dihabiskan untuk mengevaluasi risikoterlalu besar untuk proyek-proyek kecil atau berisikorendah
� Waktu yang dihabiskan untuk perencanaan, pengaturan ulang tujuan, melakukan analisis risikodan prototyping mungkin berlebihandan prototyping mungkin berlebihan
� Model yang kompleks
� Keahlian penilaian risiko diperlukan
� Spiral mungkin akan berlangsung terus tanpa batas
� Pengembang harus ditugaskan kembali selamakegiatan fase non-pembangunan
� Mungkin sulit untuk menentukan tujuan, milestone diverifikasi yang menunjukkan kesiapan untukmelanjutkan iterasi berikutnya
KAPAN DIGUNAKAN MODEL SPIRAL
� Ketika penciptaan prototipe sesuai
� Ketika biaya dan risiko evaluasi penting
� Untuk media untuk proyek-proyek berisikotinggi
� Komitmen proyek jangka panjang tidak� Komitmen proyek jangka panjang tidakbijaksana karena potensi perubahan prioritasekonomi
� Pengguna tidak yakin kebutuhan mereka
� Persyaratan yang kompleks
� Lini produk baru
� Perubahan signifikan diharapkan (penelitian daneksplorasi)
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. 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 � 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)� 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 lunakperangkat lunak
� Komunikasi antara rekan tim dilakukan dengan
kode
� Siklus hidup dan perilaku dari obyek yang
kompleks didefinisikan dalam kasus uji - lagi
dalam kode
DISKUSI