Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Rekayasa Perangkat Lunak Materi ke 2 Ir. Waniwatining Astuti, M.T.I.

Presentasi serupa


Presentasi berjudul: "Rekayasa Perangkat Lunak Materi ke 2 Ir. Waniwatining Astuti, M.T.I."— Transcript presentasi:

1 Rekayasa Perangkat Lunak Materi ke 2 Ir. Waniwatining Astuti, M.T.I

2  Kita telah menetapkan ranah permasalahan - perangkat lunak berskala industri  Selain menghasilkan perangkat lunak, biaya, mutu, dan jadwal juga merupakan penggerak pengembangan  RPL didefinisikan sebagai pendekatan sistematis untuk pengembangan perangkat lunak (berskala industri)

3  M & P (mutu & prooduktivitas) adalah tujuan yang penting  M & P tergantung pada orang, proses, dan teknologi  Proses membantu orang menjadi lebih produktif dan membuat kesalahan lebih sedikit  Alat membantu orang menjalankan beberapa tugas dalam proses lebih efisien dan efektif  Jadi, proses membentuk inti

4  Proses berbeda dari produk - produk hasil dari melaksanakan proses pada proyek  RPL berfokus pada proses  Dasarnya: proses yang tepat akan membantu mencapai tujuan proyek dengan M&P yang tinggi

5

6  Sebuah proyek perangkat lunak adalah salah satu contoh dari masalah pengembangan  Proses Pengembangan membawa proyek dari kebutuhan pengguna ke perangkat lunak  Ada tujuan-tujuan lain yaitu jadwal, biaya, dan mutu, selain menghasilkan perangkat lunak  Butuh proses lainnya

7  Proses: Urutan langkah-langkah dilakukan untuk mencapai tujuan tertentu  Proses Perangkat Lunak: Urutan langkah- langkah yang dilakukan untuk memproduksi perangkat lunak dengan mutu yang tinggi, dalam anggaran dan jadwal tertentu  Banyak jenis kegiatan yang dilakukan oleh orang-orang yg berbeda dalam sebuah proyek perangkat lunak  Lebih baik untuk melihat proses PL sebagai proses yang terdiri dari banyak komponen

8  Dua proses utama  Pengembangan - berfokus pada pengembangan dan langkah-langkah mutu yang diperlukan untuk rekayasawan perangkat lunak  Manajemen Proyek - berfokus pada perencanaan dan pengendalian proses pengembangan  Proses pengembangan merupakan jantung dari proses perangkat lunak; proses-proses lain berada di sekitarnya  Ini dijalankan oleh orang yang berbeda  pengembang mengeksekusi proses rekayasa  manajer proyek mengeksekusi proses manajemen

9  Proses lain  Proses manajemen konfigurasi: mengelola evolusi artefak  Proses manajemen perubahan: bagaimana perubahan yang dimasukkan  Proses manajemen proses: manajemen proses itu sendiri  Proses Inspeksi: Bagaimana inspeksi dilakukan pada artefak

10  Proses umumnya satu set fase  Setiap fase melakukan tugas yang didefinisikan dengan baik dan umumnya menghasilkan keluaran  Keluaran antara - produk kerja  Pada tingkat atas, biasanya beberapa fase dalam proses  Cara melakukan fase tertentu – menggunakan metodologi

11  Pendekatan ETVX untuk menentukan langkah  Kriteria masuk: kondisi apa yang harus dipenuhi untuk memulai fase ini  Tugas: apa yang harus dilakukan dalam fase ini  Verifikasi: pemeriksaan dilakukan pada keluaran dari tahap ini  Kriteria keluar: kapan bisa fase ini dianggap diselesaikan dengan sukses  Suatu fase juga menghasilkan informasi untuk manajemen

12

13 Proses Pengembangan dan Model Proses

14  Proyek - untuk membangun sebuah sistem PL dalam biaya dan jadwal dan dengan mutu tinggi yang memuaskan pelanggan  Proses yang cocok diperlukan untuk mencapai tujuan  Proses seharusnya tidak hanya membantu menghasilkan perangkat lunak tetapi membantu mencapai M&P yang tertinggi

15  Proses proyek yang harus diikuti ditentukan dalam perencanaan  Sebuah model proses menentukan proses umum yang optimal untuk suatu kelas masalah  Sebuah proyek dapat memilih proses dengan menggunakan salah satu model proses

16  Satu set fase dan setiap fase berupa urutan langkah  Urutan langkah-langkah untuk fase - fase adalah metodologi untuk itu  Mengapa memiliki fase-fase:  Untuk menggunakan pendekatan ‘bagi-bagi dan taklukkan’  setiap fase menangani bagian yang berbeda dari masalah  membantu dalam validasi berkelanjutan

17  Umumnya memiliki kegiatan: analisis kebutuhan, arsitektur, perancangan, pemrograman, pengujian, penyerahan  Model yang berbeda melakukan fase-fase tersebut dengan cara yang berbeda

18  Sebuah model proses menentukan proses umum, biasanya sebagai satu set dari tahap- tahap pekerjaan.  Model ini akan cocok untuk kelas proyek tertentu  Jadi, model menyediakan struktur generik dari proses yang dapat diikuti oleh beberapa proyek untuk mencapai tujuannya

19  Urutan linear tahap/fase  Kebutuhan – Rancangan Tingkat Tinggi – Rancangan Rinci - Pemrograman - Pengujian – Penyerahan  Suatu fase dimulai hanya ketika fase sebelumnya telah selesai; tidak ada umpan balik  Fase membagi proyek, masing-masing menangani masalah yang terpisah

20

21  Urutan linear menyiratkan setiap tahap harus memiliki beberapa keluaran  Keluaran harus divalidasi/diverivikasi  Keluaran dari fase sebelumnya: produk kerja  Keluaran umum dari waterfall: SRS, rencana proyek, dokumen rancangan, rencana dan laporan pengujian, kode akhir, dokumen pendukung

22  Secara konseptual sederhana, membagi masalah ke dalam tahap yang berbeda yang dapat dilakukan secara independen  Pendekatan alami untuk pemecahan masalah  Mudah untuk mengelola dalam kontrak - setiap fase adalah milestone

23  Menganggap bahwa kebutuhan dapat ditetapkan dan dibekukan di awal  Menetapkan perangkat keras dan teknologi lainnya terlalu dini  Mengikuti pendekatan "big bang" – “all or nothing delivery”; terlalu berisiko  Sangat berorientasi dokumen, membutuhkan dokumen pada akhir setiap tahap

24  Penggunaan Waterfall  Telah digunakan secara luas  Cocok untuk proyek-proyek di mana kebutuhan dapat dipahami dengan mudah dan keputusan teknologi yang mudah  Untuk proyek yang sudah dikenal mungkin ini yang paling optimal

25  Purwarupa mengatasi keterbatasan spesifikasi kebutuhan waterfall  Sebagai ganti pembekuan kebutuhan hanya dengan diskusi, purwarupa dibangun untuk memahami kebutuhan  Membantu meringankan risiko kebutuhan  Sebuah model waterfall kecil menggantikan tahap kebutuhan

26

27  Pengembangan purwarupa  Mulai dengan kebutuhan awal  Hanya fitur kunci yang perlu pemahaman yang lebih baik yang termasuk dalam purwarupa  Tidak ada gunanya memasukkan fitur-fitur yang dipahami dengan baik  Umpan balik dari pengguna diambil untuk meningkatkan pemahaman dari kebutuhan

28  Biaya dapat disimpan rendah  Hanya membangun fitur yang memerlukan klarifikasi  "cepat dan kotor" - mutu tidak penting, skrip dll dapat digunakan  Hal-hal seperti penanganan eksepsi, pemulihan, dan standar dihilangkan  Biaya bisa beberapa % saja dari total  Belajar dalam membangun purwarupa akan membantu dalam pengembangan, selain kebutuhan yang ditingkatkan

29  Keunggulan: kebutuhan akan lebih stabil, kebutuhan dibekukan kemudian, pengalaman membantu dalam pengembangan utama  Kelemahan: berpotensi meningkatkan biaya dan jadwal  Penerapan: Ketika kebutuhan sulit untuk diperoleh dan keyakinan dalam kebutuhan rendah; yaitu di mana kebutuhan tidak dipahami dengan baik

30  Mengatasi masalah "semua atau tidak sama sekali" yang merupakan kelemahan dari model waterfall  Menggabungkan manfaat purwarupa dan waterfall  Mengembangkan dan menyediakan perangkat lunak secara bertahap  Setiap peningkatan merupakan bagian yang lengkap  Dapat dilihat sebagai waterfall yg berurutan  Umpan balik dari satu iterasi yang digunakan dalam iterasi yang berikutnya

31

32  Setiap iterasi hampir selalu diikuti produk yang dihasilkan  Digunakan umumnya dalam pengembangan custom juga  Bisnis ingin respon cepat untuk PL  Tidak dapat menghadapi risiko “semua atau tidak sama sekali”  Pendekatan baru seperti XP, Agile,... semua bergantung pada pengembangan iteratif

33  Keunggulan: Mendapatkan sesuai yang dibayar, umpan balik untuk perbaikan  Kelemahan: Arsitektur/rancangan mungkin tidak optimal, pengerjaan ulang dapat meningkat, total biaya mungkin lebih besar  Penerapan: di mana waktu respon sangat penting, risiko proyek yang lama tidak dapat diambil, semua kebutuhan tidak diketahui

34  Iterasi pertama membuat kebutuhan dan arsitektur dengan cara waterfall  Pengembangan dan penyerahan dilakukan secara bertahap dalam iterasi

35

36  Iteratif adalah urutan linier dari iterasi  Setiap iterasi adalah waterfall mini - menentukan spesifikasi, kemudian rencana iterasi  Timeboxing – menetapkan durasi iterasi, kemudian menentukan spesifikasi  Membagi iterasi dalam beberapa tahap yang sama  Menggunakan konsep pipelining untuk mengeksekusi iterasi secara paralel

37  Pengembangan iteratif umum – menetapkan fungsi untuk setiap iterasi, kemudian merencanakan dan jalankan  Pada iterasi kotak waktu – menetapkan durasi iterasi dan menyesuaikan fungsi yang akan dimasukkan  Waktu penyelesaiannya tetap, fungsi yang akan disampaikan fleksibel

38  Hal ini sendiri sangat berguna dalam banyak situasi  Waktu pengiriman dapat diprediksi  Rilis produk secara keseluruhan dan pemasaran dapat lebih terencana  Membuat parameter waktu tidak bisa ditawar dan membantu memfokuskan perhatian pada jadwal  Mencegah penggelembungan kebutuhan  Waktu pengembangan secara keseluruhan masih tidak berubah

39  Bagaimana jika kita memiliki beberapa iterasi yang dieksekusi secara paralel  Dapat mengurangi waktu penyelesaian rata- rata dengan memanfaatkan paralelisme  Untuk eksekusi paralel, dapat meminjam konsep-konsep pipelining dari perangkat keras  Hal ini menghasilkan Model Proses Timeboxing

40  Dasar  Pengembangan dilakukan secara iteratif dalam kotak waktu berdurasi tetap  Setiap kotak waktu dibagi dalam tahap yang tetap  Setiap tahap melakukan tugas yang jelas yang dapat dilakukan secara mandiri  Setiap tahap kira-kira sama dalam hal durasi  Ada sebuah tim khusus untuk setiap tahap  Ketika tim satu tahap selesai, tim itu menyerahkan proyek kepada tim berikutnya

41  Dengan kotak waktu jenis ini, dapat menggunakan pipelining untuk mengurangi waktu siklus  Seperti pipelining perangkat keras – memandang iterasi sebagai satu instruksi  Sebagai tahap memiliki tim khusus, eksekusi simultan dari iterasi yang berbeda adalah memungkinkan

42  Sebuah iterasi dengan tiga tahap – (A)nalisis, (B)angun, (S)erahkan  Tahap-tahap ini lebih kurang sama dalam banyak situasi  Dapat menyesuaikan durasi dengan menentukan batas yang sesuai  Dapat menyesuaikan durasi dengan menyesuaikan ukuran tim untuk setiap tahap  Memiliki tim terpisah untuk masing-masing tahap

43  Tim A mulai menjalankan iterasi 1  Tim A selesai, menyerahkan iterasi 1 ke Tim B, dan mulai menjalankan iterasi 2  Tim A menyelesaikan iterasi 2, menyerahkan ke Tim B, Tim B menyelesaikan iterasi 1, menyerahkan ke Tim S, Tim A memulai iterasi 3, Tim B mulai iterasi 2 (dan Tim S, iterasi 1) ...

44

45  Iterasi pertama selesai pada waktu T  Kedua selesai pada T + T / 3; ketiga pada T +2 T / 3, dan seterusnya  Dalam keadaan stabil, pengiriman setiap T / 3 waktu  Jika T adalah 3 minggu, pengiriman pertama setelah 3 minggu, 2 setelah 4 minggu, 3 setelah 5 minggu,...  Dalam pelaksanaan linier, waktu pengiriman akan 3 minggu, 6 minggu, 9 minggu,...

46  Jangka waktu iterasi masing-masing masih sama  Jumlah pekerjaan dilakukan dalam kotak waktu juga sama  Produktivitas dari kotak waktu sama  Namun, waktu siklus rata-rata atau waktu pengiriman telah dikurangi menjadi sepertiga

47  Dalam pelaksanaan linear dari iterasi, tim yang sama melakukan semua tahap  Jika setiap tahap memiliki tim dari S, dalam pelaksanaan linear ukuran tim adalah S  Dalam pelaksanaan pipelined, ukuran tim adalah tiga kali (satu tim untuk setiap tahap)  Tapi, ukuran total dalam tim timeboxing lebih besar, dan ini mengurangi waktu siklus

48  Hanya dengan meningkatkan ukuran tim kita tidak bisa mengurangi waktu siklus - Hukum Brook  Timeboxing memungkinkan cara yang terstruktur untuk menambah tenaga kerja untuk mengurangi waktu siklus  Perhatikan bahwa kita tidak dapat mengubah waktu iterasi - Hukum Brook masih berlaku  Alokasi pekerjaan yang berbeda untuk memungkinkan tim yang lebih besar untuk berfungsi dengan baik

49

50  Keunggulan: waktu pengiriman lebih pendek, mendapatkan juga keuntungan lain dari pendekatan iteratif, distribusi eksekusi  Kelemahan: tim besar, manajemen proyek lebih sulit, sinkronisasi tinggi diperlukan, manajemen konfigurasi sulit  Penerapan: Ketika waktu pengiriman yang singkat sangat penting; arsitektur stabil; fleksibilitas dalam pengelompokan fitur

51  Rational Unified Process merupakan model iteratif juga  Pengembangan perangkat lunak dibagi menjadi siklus, setiap siklus memberikan suatu sistem sepenuhnya bekerja  Setiap siklus dilaksanakan sebagai proyek terpisah  Pelaksanaan siklus ini dibagi menjadi empat fase berturut-turut, setiap tahap berakhir dengan pencapaian milestone

52  Tahapan dalam proyek:  Fase Insepsi: berakhir dengan milestone sasaran siklus hidup; visi dan kemampuan tingkat tinggi dari sistem didefinisikan  Fase Elaborasi: milestone arsitektur siklus hidup; kebutuhan yang paling didefinisikan dan arsitektur yang dirancang  Fase Konstruksi: milestone kemampuan operasional awal  Fase Transisi: rilis produk; transisi produk dari pengembangan ke produksi

53

54  Setiap fase itu sendiri dapat dilakukan dalam beberapa iterasi, iterasi masing-masing memiliki pelanggan eksternal / internal  Secara umum konstruksi memiliki beberapa iterasi; elaborasi juga bisa dilakukan dalam beberapa iterasi

55  Tugas rekayasa yang disebut alur kerja proses inti  sub proses ini berkenaan dengan tugas-tugas kebutuhan, perancangan, pelaksanaan pengujian, manajemen proyek, dll  Banyak sub proses mungkin aktif dalam satu fase, volume aktivitas umumnya berbeda tergantung pada proyek

56

57  Sub-sub proses aktif dalam semua fase  Volume aktivitas di setiap fase berbeda tergantung pada proyek  Oleh karena itu, proyek dapat menggunakan RUP untuk mengimplementasikan waterfall dengan memiliki proses kebutuhan aktif hanya dalam fase elaborasi  Atau purwarupa dengan memiliki banyak kegiatan konstruksi dalam fase elaborasi  Oleh karena itu RUP merupakan kerangka kerja yang fleksibel

58  Pendekatan tangkas (agile) yang dikembangkan di tahun 90-an sebagai reaksi terhadap pendekatan yang dikendalikan dokumen  Sebagian besar pendekatan tangkas memiliki beberapa prinsip umum  Ukuran kemajuan adalah bagian perangkat lunak yg bisa berjalan  Perangkat Lunak harus disampaikan sedikit demi sedikit  Bahkan perubahan akhir harus diperbolehkan  Lebih suka komunikasi tatap muka dibanding dokumentasi  umpan balik terus-menerus dan keterlibatan pelanggan diperlukan  Lebih suka rancangan sederhana yang berkembang  Tanggal Pengiriman diputuskan oleh tim

59  Banyak metodologi tangkas telah diusulkan; pemrograman ekstrim (XP) adalah salah satu yang paling populer  Sebuah proyek XP dimulai dengan cerita- cerita pengguna, yang merupakan deskripsi singkat kebutuhan pengguna  Rincian tidak termasuk  Setiap cerita pengguna yang ditulis pada kartu yang terpisah sehingga mereka dapat dikombinasikan dengan cara beda

60  Tim memperkirakan berapa lama waktu yang dibutuhkan untuk menerapkan cerita pengguna  Perkiraannya kasar  Perencanaan rilis dilakukan  Menetapkan cerita yang akan dibangun di rilis mana, dan tanggal untuk rilis  Disarankan rilis yang sering dan kecil  Uji penerimaan juga dibangun dari cerita-cerita pengguna; digunakan untuk menguji sebelum rilis  Bugs yang ditemukan di uji penerimaan, diperbaiki dalam rilis berikutnya

61  Pengembangan dilakukan dalam iterasi yang masing-masing beberapa minggu  Iterasi dimulai dengan perencanaan, di mana cerita akan dilaksanakan dipilih – yang berisiko tinggi dan bernilai tinggi dipilih pertama  Rincian cerita diperoleh selama pembangunan dan dilaksanakan  Uji penerimaan yang gagal pada iterasi sebelumnya juga diperbaiki

62

63  Suatu eksekusi iterasi memiliki beberapa praktek yang unik  Pemrograman berpasangan: pemrograman dilakukan dalam pasangan pemrogram  Pengembangan yand dikendalikan pengujian – pengujian unit otomatis ditulis sebelum kode program  Solusi sederhana, refactoring untuk meningkatkan rancangan ketika diperlukan

64

65  Cocok untuk situasi di mana volume dan kecepatan kebutuhan yang tinggi  Pelanggan bersedia untuk sangat terlibat dengan tim  Tim tidak terlalu besar (kurang dari 20)  Membutuhkan kemampuan yang kuat dalam anggota tim

66  Model yang akan digunakan harus dipilih berdasarkan pada sifat dari masalah  Contoh: Membangun sistem lelang kecil untuk Univ, jadwal yang ketat, beberapa kebutuhan inti, pelanggan hanya terlibat di awal,...  Model Cocok: Iteratif - lakukan kebutuhan dalam iterasi pertama, dan dua putaran penyerahan; meminimalkan risiko,...

67  Contoh: produk yang sangat kompetitif, perubahan kebutuhan yang cepat; pengalihdayaan (outsourcing) diinginkan untuk mengurangi biaya,...  Model: timeboxing paling cocok

68  Proses merupakan sarana untuk mencapai tujuan proyek yaitu mutu dan produktivitas yang tinggi  Proses mendefinisikan model proses generik, yang dapat membentuk dasar dari proses proyek  Proses biasanya memiliki tahap, setiap tahap berfokus pada tugas yg bisa diidentifikasi  Banyak model bagi proses pengembangan telah diusulkan

69  Model proses pengembangan yang dibahas  Waterfall  Purwarupa  Iteratif  RUP  Timeboxing  Agile atau XP  Masing-masing memiliki keunggulan dan kelemahan dan akan bekerja dengan baik untuk beberapa jenis proyek

70 Proses Manajemen Proyek

71  Proses pengembangan membagi pengembangan ke dalam fase-fase dan kegiatan-kegiatan  Untuk menjalankannya secara efisien, harus mengalokasikan sumber daya, mengelola mereka, memantau kemajuan, mengambil tindakan korektif,...  Ini semua adalah bagian dari proses manpro  Oleh karena itu, proses manpro adalah bagian penting dari pelaksanaan proyek

72  Ada tiga fase besar  Perencanaan  Pemantauan dan pengendalian  Analisis penghentian  Perencanaan merupakan kegiatan utama yang menghasilkan sebuah rencana, yang merupakan dasar pemantauan

73  Harus selesai sebelum proyek dimulai  Tugas utama  Estimasi biaya dan jadwal  Pengelolaan staf  Pemantauan dan rencana manajemen risiko  Rencana jaminan mutu  Dll  Akan didiskusikan perencanaan secara rinci nanti

74  Berlangsung selama durasi proyek dan mencakup proses pengembangan  Memantau semua parameter kunci seperti biaya, jadwal, risiko  Mengambil tindakan korektif bila diperlukan  Memerlukan informasi tentang proses pengembangan - disediakan oleh metrik

75  Analisis penghentian dilakukan ketika proses pengembangan selesai  Tujuan Dasar: untuk menganalisis kinerja proses, dan mengidentifikasi pelajaran yang diperoleh  Juga disebut analisis postmortem

76

77  Proses memiliki dampak yang besar pada mutu dan produktivitas  Proses-proses yang berbeda digunakan dalam sebuah proyek perangkat lunak  Fokus pada proses pembangunan dan proses manajemen proyek  Model proses adalah struktur proses umum, yang bekerja baik untuk beberapa jenis masalah  Sebuah proyek harus memilih model proses yang paling cocok untuk itu (dan menyesuaikannya untuk memenuhi kebutuhan)


Download ppt "Rekayasa Perangkat Lunak Materi ke 2 Ir. Waniwatining Astuti, M.T.I."

Presentasi serupa


Iklan oleh Google