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