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 memberikan perangkat lunak, biaya, kualitas, dan jadwal driver  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 kualitas, 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 kualitas yang diperlukan untuk rekayasawan perangkat lunak  Manajemen Proyek - berfokus pada perencanaan dan pengendalian proses pembangunan  Proses Pembangunan merupakan jantung dari proses perangkat lunak; proses-proses lain berada di sekitar itu  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 - metodologi telah diusulkan

11  ETVX pendekatan untuk menentukan langkah  kriteria Entry: kondisi apa yang harus dipenuhi untuk memulai fase ini  Tugas: apa yang harus dilakukan dalam fase ini  Verifikasi: pemeriksaan dilakukan pada output dari tahap ini  kriteria keluar: kapan bisa fase ini dianggap dilakukan dengan sukses  Suatu fase juga menghasilkan info untuk manajemen

12

13 Proses Pengembangan dan Model Proses

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

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

16  Satu set fase dan setiap fase menjadi urutan langkah  Urutan langkah-langkah untuk fase - fase 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 Persyaratan, arsitektur, desain, coding, pengujian, pengiriman  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 kerja.  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  Persyaratan – Rancangan Tingkat Tinggi – Rancangan Rinci - Kode - 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 desain, 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 persyaratan 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 persyaratan dapat dipahami dengan mudah dan keputusan teknologi yang mudah  Untuk proyek yang sudah dikenal mungkin yang paling optimal

25  Prototyping adalah pembatasan persyaratan spesifikasi waterfall  persyaratan pembekuan hanya dengan diskusi, prototipe dibangun untuk memahami persyaratan  Alih-alih Membantu meringankan risiko persyaratan Sebuah model air terjun kecil menggantikan tahap persyaratan

26

27 Pengembangan prototipe Mulai dengan persyaratan awal Hanya fitur kunci yang perlu pemahaman yang lebih baik termasuk dalam prototipe Tidak ada gunanya termasuk fitur-fitur yang dipahami dengan baik diambil untuk meningkatkan pemahaman dari persyaratan Umpan balik dari pengguna

28 Biaya dapat disimpan rendah Membangun hanya fitur yang memerlukan klarifikasi "cepat dan kotor" - kualitas tidak penting, script dll dapat digunakan Hal-hal seperti penanganan eksepsi, pemulihan, standar dihilangkan Biaya dapat beberapa% dari total Belajar dalam membangun prototipe akan membantu dalam membangun, selain persyaratan ditingkatkan

29 Keuntungan: req akan lebih stabil, req beku kemudian, pengalaman membantu dalam pengembangan utama Kekurangan: hit Potensi pada biaya dan jadwal Penerapan: Ketika req sulit untuk memperoleh dan keyakinan dalam p'mint rendah; yaitu di mana p'mint tidak dipahami dengan baik

30 Penghitung yang "semua atau tidak" Kelemahan dari model air terjun Menggabungkan manfaat prototyping dan air terjun Mengembangkan dan menyediakan perangkat lunak secara bertahap Setiap kenaikan lengkap dalam dirinya sendiri Dapat dilihat sebagai urutan air terjun Umpan balik dari satu iterasi yang digunakan dalam iterasi masa depan

31

32  Produk hampir selalu mengikutinya Digunakan umumnya dalam pembangunan disesuaikan juga Bisnis ingin respon cepat untuk sw Tidak dapat membayar resiko semua apa- apa-atau- pendekatan baru seperti XP, Agile,... semua bergantung pada pengembangan iteratif

33  Manfaat: Dapatkan-as-you-membayar, umpan balik untuk perbaikan, Kekurangan: Arsitektur / desain tidak mungkin optimal, pengerjaan ulang dapat meningkatkan, total biaya mungkin lebih Penerapan: di mana waktu respon sangat penting, risiko proyek yang lama tidak dapat diambil, req semua tidak diketahui

34  Bentuk lain Iteratif Iterasi pertama tidak persyaratan dan arsitektur dengan cara terjun Pengembangan dan pengiriman dilakukan secara bertahap dalam iterasi

35

36  Timeboxing Iteratif adalah urutan linier dari iterasi Setiap iterasi adalah air terjun mini - menentukan spesifikasi, maka rencana iterasi Waktu tinju - memperbaiki durasi iterasi, kemudian menentukan spesifikasi Membagi iterasi dalam beberapa tahap yang sama Gunakan konsep pipelining untuk mengeksekusi iterasi secara paralel

37  Waktu Iterasi kemas pengembangan iteratif Umum - memperbaiki fungsi untuk setiap iterasi, kemudian merencanakan dan jalankan Pada iterasi kotak waktu - memperbaiki durasi iterasi dan menyesuaikan fungsi untuk menyesuaikannya Waktu Penyelesaian adalah tetap, fungsi yang akan disampaikan adalah fleksibel

38 Hal ini sendiri sangat berguna dalam banyak situasi Apakah waktu pengiriman diprediksi Secara keseluruhan rilis produk dan pemasaran dapat lebih terencana Membuat parameter waktu tidak bisa ditawar dan membantu memfokuskan perhatian pada jadwal Mencegah kembung persyaratan waktu dev Secara keseluruhan masih tidak berubah

39  - Mengambil Waktu Iterasi kemas lebih lanjut Bagaimana jika kita memiliki beberapa iterasi mengeksekusi secara paralel Dapat mengurangi waktu penyelesaian rata- rata dengan memanfaatkan paralelisme Untuk eksekusi paralel, dapat meminjam konsep-konsep pipelining dari hardware Hal ini menyebabkan Timeboxing Model Proses

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

41  Dengan jenis kotak waktu, dapat menggunakan pipelining untuk mengurangi waktu siklus Seperti pipelining hardware - view iterasi setiap instruksi Sebagai tahap telah mendedikasikan tim, eksekusi simultan dari iterasi yang berbeda adalah mungkin

42  Contoh Sebuah iterasi dengan tiga tahap - Analisis, Membangun, Deploy Tahap-tahap ini appx sama dalam banyak situasi Dapat menyesuaikan dengan menentukan jangka waktu yang sesuai boudaries Dapat menyesuaikan durasi dengan menyesuaikan ukuran tim untuk setiap tahap Memiliki tim terpisah untuk A, B, dan D

43  Pipelined Eksekusi AT mulai dijalankan itu-1 AT selesai, tangan di atasnya-1 ke BT, mulai dijalankan itu-2 AT menyelesaikannya-2, tangan ke BT, BT menyelesaikannya-1, tangan ke DT, AT-3 mulai itu, BT mulai itu-2 (dan DT, hal-1)...

44

45  Timeboxing eksekusi selesai iterasi pertama pada waktu T Kedua selesai pada T + T / 3; ketiga pada T +2 T / 3, dan seterusnya Dalam stabil, pengiriman setiap negara T / 3 waktu Jika T adalah 3 minggu, pengiriman pertama setelah 3 wks, 2 setelah 4 wks, 3 setelah 5 WKS,... Dalam pelaksanaannya linier, waktu pengiriman akan 3 wks, 6 wks, 9 wks,...

46  Timeboxing eksekusi 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  Ukuran Tim Dalam pelaksanaannya linear dari iterasi, tim yang sama melakukan semua tahap Jika setiap tahap memiliki tim dari S, dalam pelaksanaan linear ukuran tim adalah S Dalam pelaksanaannya pipelined, ukuran tim adalah tiga kali (satu untuk setiap tahap) yakni ukuran total dalam tim timeboxing lebih besar, dan ini mengurangi waktu siklus

48  Ukuran Tim 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 memegang Bekerja alokasi yang berbeda untuk memungkinkan tim yang lebih besar untuk berfungsi dengan baik

49

50  Keuntungan: waktu pengiriman lebih pendek, adv lain iteratif, distr. eksekusi Kekurangan: tim besar, telp proj lebih sulit, sinkronisasi tinggi diperlukan, CM adalah sulit Penerapan:. Ketika waktu pengiriman yang singkat v. imp; arsitektur stabil; fleksibilitas dalam pengelompokan fitur

51  Rasional Unified Process model iteratif lain 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 tonggak

52  Tahapan dalam proyek fase Inception: berakhir dengan tonggak Siklus Hidup Tujuan; visi dan kemampuan tingkat tinggi dari sistem didefinisikan Elaborasi fase: Siklus Hidup tonggak arsitektur; persyaratan yang paling didefinisikan dan arsitektur yang dirancang Konstruksi fase: tonggak awal kemampuan operasional Transisi fase: Produk rilis; transisi produk dari pengembangan untuk produksi

53

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

55  Inti alur kerja dan fase Rekayasa tugas yang disebut inti alur kerja proses sub proses ini sesuai dengan persyaratan tugas, pelaksanaan pengujian desain, proj Mgmt, dll Banyak sub proses mungkin aktif dalam fase, volume aktivitas umumnya berbeda tergantung pada proyek

56

57  proses Sub aktif dalam semua tahap Volume aktivitas di setiap fase berbeda tergantung pada proyek Oleh karena itu, proyek dapat menggunakan RUP untuk mengimplementasikan air terjun dengan memiliki persyaratan proses aktif hanya dalam fase elaborasi Atau prototyping dengan memiliki banyak kegiatan konstruksi dalam fase elaborasi RUP Oleh karena itu kerangka kerja yang fleksibel

58  Agile pendekatan yang dikembangkan di tahun 90-an sebagai reaksi terhadap dokumen pendekatan didorong Sebagian besar pendekatan tangkas memiliki beberapa prinsip umum perangkat lunak Bekerja adalah ukuran kemajuan Perangkat Lunak harus disampaikan sedikit demi sedikit Bahkan perubahan akhir harus diperbolehkan Lebih suka tatap muka commn atas dokumentasi umpan balik terus-menerus dan pelanggan diperlukan keterlibatan Lebih suka desain sederhana yang berkembang Pengiriman tanggal diputuskan oleh tim yang diberdayakan

59  Banyak metodologi tangkas telah diusulkan; pemrograman ekstrim (XP) adalah salah satu yang paling populer Sebuah proyek XP mulai dengan cerita-cerita pengguna, yang descr pendek dari kebutuhan pengguna tidak termasuk Rincian 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 Perkiraan kasar perencanaan Release dilakukan Menetapkan cerita akan dibangun di mana rilis, dan tanggal untuk rilis Sering rilis dan kecil didorong tes juga dibangun dari cerita-cerita pengguna; digunakan untuk menguji sebelum rilis Penerimaan Bugs ditemukan di AT adalah tetap dalam rilis berikutnya

61  Pengembangan dilakukan dalam iterasi dari beberapa minggu masing-masing Iterasi dimulai dengan perencanaan, di mana cerita akan dilaksanakan dipilih - berisiko tinggi bernilai tinggi dipilih pertama Rincian cerita yang diperoleh selama pembangunan dan dilaksanakan Gagal AT iterasi sebelumnya juga tetap

62  XP - Proses Keseluruhan

63  Sebuah Iterasi Suatu eksekusi iterasi memiliki beberapa praktek yang unik pemrograman Pasangan: pemrograman dilakukan dalam pasangan programmer Test Driven Development - unit test otomatis ditulis sebelum kode Sederhana solusi, refactoring untuk meningkatkan desain ketika kebutuhan muncul Sering integrasi

64

65  cocok untuk situasi di mana volume dan kecepatan persyaratan yang tinggi  Pelanggan bersedia untuk terlibat berat dengan tim  Tim ini collocated dan tidak terlalu besar (kurang dari 20 atau lebih)  Membutuhkan kemampuan yang kuat dalam anggota tim

66 StrengthWeaknessTypes of Projects Simple Easy to execute Intuitive and logical Easy contractually All or nothing – too risky Req frozen early May chose outdated hardware/tech Disallows changes No feedback from users Encourages req bloating Well understood problems, short duration projects, automation of existing manual systems

67 StrengthWeaknessTypes of Projects Helps req elicitation Reduces risk Better and more stable final system Front heavy Possibly higher cost and schedule Encourages req bloating Disallows later change Systems with novice users; or areas with req uncertainity. Heavy reporting based systems can benefit from UI proto

68 StrengthWeaknessTypes of Projects Regular deliveries, leading to biz benefit Can accommodate changes naturally Allows user feedback Avoids req bloating Naturally prioritizes req Allows reasonable exit points Reduces risks Overhead of planning each iteration Total cost may increase System arch and design may suffer Rework may increase For businesses where time is imp; risk of long projects cannot be taken; req not known and evolve with time

69 StrengthWeaknessTypes of Projects All benefits of iterative Planning for iterations somewhat easier Very short delivery times PM becomes more complex Team size is larger Complicated – lapses can lead to losses Where very short delivery times are very important Where flexibility in grouping features Arch is stable

70 StrengthWeaknessTypes of Projects All benefits of iterative Provides a flexible framework for a range of projects For each project, one has to design the process Can be applied to a wide range as it allows flexibility

71 StrengthWeaknessTypes of Projects Agile and responsive Short delivery cycles Continuous feedback can lead to better acceptance Can tend to become ad-hoc Lack of documentation can be an issue Continuous code change is risky Where requirements are changing a lot, customer is deeply engaged in development, and where the size of the project is not too large

72  Model yang akan digunakan harus dipilih berdasarkan pada sifat dari masalah  Contoh: Membangun sistem lelang kecil untuk Univ, jadwal yang ketat, beberapa req inti, pelanggan hanya waktu di mulai,...  Model Cocok: Iteratif pengiriman - lakukan req dalam 1 item, dan dua putaran pengiriman, meminimalkan risiko,...

73  Contoh: produk yang sangat kompetitif, perubahan req cepat; outsourcing adalah diinginkan untuk mengurangi biaya,...  Model: XP tidak OK sebagai tim collocated diperlukan; berulang mungkin tidak memberikan cukup cepat;  timeboxing paling cocok

74  Proses merupakan sarana untuk mencapai tujuan proyek QP tinggi  Proses mendefinisikan model proses generik, yang dapat membentuk dasar dari proses proyek  Proses biasanya memiliki tahap, setiap tahap berfokus pada tugas diidentifikasi  Banyak model bagi proses pembangunan telah diusulkan

75 Dibahas Pengembangan model proses Air Terjun Prototyping Iteratif RUP Timeboxing Agile atau XP Masing-masing memiliki kekuatan dan kelemahan dan akan bekerja dengan baik untuk beberapa jenis proyek

76 Proses Manajemen Proyek

77  Pengembangan proses pengembangan ke tahap membagi dan kegiatan  Untuk menjalankannya secara efisien, harus mengalokasikan sumber daya, mengelola mereka, memantau kemajuan, mengambil tindakan korektif,...  Ini semua adalah bagian dari proses PM  Oleh karena itu, proses PM adalah bagian penting dari pelaksanaan proyek

78  Ada tiga fase yang luas  Perencanaan  Pemantauan dan pengendalian  Analisis  Pemutusan  Perencanaan merupakan kegiatan utama yang menghasilkan sebuah rencana, yang merupakan dasar pemantauan

79 Selesai sebelum proyek dimulai  Kunci tugas  Biaya dan perkiraan jadwal  Staf  Pemantauan dan rencana risiko Mgmt  Jaminan Kualitas rencana  Dll  Apakah mendiskusikan perencanaan secara rinci nanti

80  Berlangsung selama durasi proyek dan mencakup proses pengembangan  Monitor semua parameter kunci seperti biaya, jadwal, risiko  Membawa tindakan korektif bila diperlukan  Kebutuhan informasi tentang proses dev - disediakan oleh metrik

81  analisis Pemutusan dilakukan ketika proses pembangunan selesai  Tujuan Dasar: untuk menganalisis Perf proses, dan mengidentifikasi pelajaran  Juga disebut analisis postmortem

82

83  Proses memiliki dampak yang besar pada kualitas dan produktivitas  Berbeda proses yang bekerja dalam sebuah proyek perangkat lunak  Kami telah berfokus pada proses pembangunan dan proses manajemen proyek  Proses adalah struktur model proses umum, yang bekerja baik untuk beberapa jenis masalah  Sebuah proyek harus memilih model proses yang paling cocok untuk itu (dan penjahit itu untuk memenuhi persyaratan)


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

Presentasi serupa


Iklan oleh Google