Presentasi sedang didownload. Silahkan tunggu

Presentasi sedang didownload. Silahkan tunggu

Proses Perangkat Lunak

Presentasi serupa


Presentasi berjudul: "Proses Perangkat Lunak"— Transcript presentasi:

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

2 Rekayasa Perangkat Lunak
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 Proses, Orang, Teknologi
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 Perangkat Lunak
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 The software Development Problem

6 Proyek dan Proses 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 Perangkat Lunak ...
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 Komponen Perangkat Lunak Proses
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 Komponen Proses ... 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 Spesifikasi 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 Spesifikasi ETVX 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 Pendekatan ETVX

13 Proses Pengembangan dan Model Proses

14 Proyek Perangkat Lunak
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 Proses Proyek dan Model Proses
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 Proses Pengembangan 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 Proses Pengembangan Umumnya memiliki kegiatan: analisis Persyaratan, arsitektur, desain, coding, pengujian, pengiriman Model yang berbeda melakukan fase-fase tersebut dengan cara yang berbeda

18 Model Proses 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 Model Waterfall 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 Waterfall... 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 Keuntungan Waterfall 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 Kerugian Waterfall 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 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 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 Prototyping

27 Prototyping 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 Prototyping… 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 Prototyping… 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 Pengembangan Iteratif
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 Peningkatan Iteratif

32 Iteratif… 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 Iteratif… 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 Bentuk lain dari Iterasi ...

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 Time boxed iteration 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 Timeboxing - 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 Timeboxing Model - 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 Timeboxing… 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 Timeboxing Eksekusi

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 Alokasi Kerja Tim

50 Timeboxing…  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 RUP Model  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  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 Tahapan dan Milestones

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 Sub proses dan tahapan

57 RUP…  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 Extreme Programming atau Agile Model Proses
 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 XP ...  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 Proses Keseluruhan  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 Proses Keseluruhan…  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 Sebuah Iterasi

65 XP - Ringkasan 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 Ringkasan - waterfall Strength Weakness Types 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 Ringkasan - Prototyping
Strength Weakness Types 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 Ringkasan - Iteratif Strength Weakness Types 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 Ringkasan - Timeboxing
Strength Weakness Types 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 Ringkasan - RUP Strength Weakness Types 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 Ringkasan - XP Strength Weakness Types 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 Menggunakan Model Proses dalam Proyek
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 Menggunakan Model Proses …
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 ringkasan 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 Ringkasan… 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 Latar Belakang 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 Proses Tahapan AM Ada tiga fase yang luas
Perencanaan Pemantauan dan pengendalian Analisis Pemutusan Perencanaan merupakan kegiatan utama yang menghasilkan sebuah rencana, yang merupakan dasar pemantauan

79 Perencanaan 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 Pemantauan dan pengendalian
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 analisis Pemutusan dilakukan ketika proses pembangunan selesai Tujuan Dasar: untuk menganalisis Perf proses, dan mengidentifikasi pelajaran Juga disebut analisis postmortem

82 Hubungan dengan Proses Dev

83 Ringkasan 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 "Proses Perangkat Lunak"

Presentasi serupa


Iklan oleh Google