Proses Software Bab 2.

Presentasi berjudul: "Proses Software Bab 2."— Transcript presentasi:

1 Proses Software Bab 2

2 Tujuan Memahami konsep proses perangkat lunak
Memperkenalkan model proses software Menggambarkan beberapa model proses dan kapan digunakan Menggambarkan secara garis besar model proses untuk rekayasa kebutuhan, pengembangan software,testing dan evolusi Mengenalkan teknologi CASE untuk mendukung aktifitas proses software

3 Proses Software Sekumpulan aktifitas yang saling terkait untuk spesifikasi, desain,implementasi dan testing perangkat lunak.

4 Proses Software Sekumpulan aktifitas terstruktur yang dibutuhkan untuk mengembangkan sistem software, yang meliputi kegiatan : o Spesifikasi perangkat lunak : Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan o Pengembangan (Desain&Implementasi) perangkat lunak : Perangkat lunak yang memenuhi spesifikasi harus di produksi o Validasi perangkat lunak, Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak bekerja sesuai dengan apa yang diinginkan oleh pelanggan

5 Evolusi perangkat lunak : Perangkat lunak harus berkembang kembali untuk memenuhi kebutuhan pelanggan Model proses software adalah representasi abstrak dari proses. Merupakan gambaran dari proses dari beberapa perspektif tertentu.

6 Model Proses Perangkat Lunak(1)
Model waterfall Model ini mengambil kegiatan proses dasar seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian, pemeliharaan dan evolusi

7 Model Proses Perangkat Lunak(2)
Model Pengembangan Evolusioner Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Suatu sistem awal dikembangkan dgn cepat dari spesifikasi abstrak. Sistem ini kemudian diperbaiki dengan masukan dari pelanggan utk menghasilkan sistem yang memuaskan bagi kebutuhan pelanggan.

8 Model Proses Perangkat Lunak(3)
Pengembangan sistem formal Pendekatan ini didasarkan atas pembuatan spesifikasi sistem matematis, dan pentransformsian spesifikasi ini, dengan memakai metode matematis, utk membangun program

9 Model Proses Perangkat Lunak(4)
Pengembangan berdasarkan pemakaian ulang. Pendekatan ini didasarkan atas komponen yang dapat dipakai ulang dalam jumlah yang signifikan. Proses pengembangan sistem terfokus pada integrasi komponen ini ke dalam suatu sistem, dan bukan mengembangkannya dari awal.

10 Model Waterfall(1)

11 Fase model Waterfall(2)
Analisa dan definisi kebutuhan(definisi persyaratan. Pelayanan, batasan, dan tujuan sistem ditentukan melalui konsultasi dgn user. Persyaratan/kebutuhan ini kmd didefinisikan secara rinci dan berfungsi sbg spesifikasi sistem

12 Fase model Waterfall(3)
Desain sistem dan software Proses perancangan sistem membagi kebutuhan/persyaratan dalam sistem perangkat keras atau perangkat lunak. Perancangan perangkat lunak melibatkan identifikasi dan deskripsi abstraksi sistem perangkat lunak yang mendasar dan hubungan-hubungannya. Menentukan arsitektur sistem secara keseluruhan.

13 Fase model Waterfall(4)
Implementasi dan unit testing Pada tahap ini perancangan perangkat lunak direalisasikan sbg serangkaian program atau unit program. Pengujian unit melibatkan verifikasi bahwa setiap unit telah memenuhi spesifikasinya.

14 Fase model Waterfall(5)
Integrasi dan testing sistem Unit program atau program individual diintegrasikan dan diuji sbg sistem yg lengkap utk menjamin bahwa persyaratan sistem telah dipenuhi. Setelah pengujian sistem, PL dikirim kepada pelanggan

15 Fase model Waterfall(6)
Operasi dan maintenance Biasanya (walau tdk sehrsnya), ini merupakan fase siklus yg paling lama. Sistem diinstal dan dipakai. Pemeliharaan mencakup koreksi dari berbagai error yg tdk ditemukan pada tahap2 sblmnya, perbaikan atas implementasi unit sistem dan pengembangan pelayanan sistem dan persyaratan2 baru ditambahkan Kekurangan dari model waterfall adalah kesulitan untuk mengakomodasi perubahan setelah proses berjalan

16 Fase-fase Waterfall menurut Pressman

17 Masalah dengan model waterfall
Terjadinya pembagian proyek menjadi tahap-tahap yang tidak fleksibel, karena komitmen harus dilakukan pada tahap awal proses. Hal ini mengakibatkan sulitnya untuk merespon perubahan kebutuhan pengguna (user). Model air terjun harus digunakan hanya ketika persyaratan dipahami dengan baik.

18 Pengembangan Evolusioner terdiri dari :
Pengembangan Exploratory o Tujuannya : bekerja dengan konsumen utk menyelidiki persyaratan mereka dan mengirimkan sistem akhir. Pengembangan dimulai dgn bagian2 sistem yg dipahami. Sistem berubah dgn adanya tambahan fitur2 baru sesuai usulan pelanggan

19 Pengembangan Evolusioner terdiri dari :
Throw-away prototyping(Prototipe yg dpt dibuang) o Tujuan : mengerti kebutuhan sistem. Dimulai dengan kebutuhan/persyaratan pelanggan yang tidak dipahami/dimengerti dengan baik

20 Pengembangan Evolusioner

21 Pengembangan Evolusioner
Permasalahan o Tidak ada visibilitas proses(proses tidak bisa dilihat). Jika sistem dikembangkan dgn cepat, tidaklah efektif dari segi biaya jika dihasilkan dokumen yg merefleksikan setiap proses sistem. o Sistem biasanya tidak terstruktur dengan baik o Diperlukan alat bantu dan teknik khusus o Untuk sistem interaktif berukuran kecil ( baris kode) atau medium( baris kode) o Untuk sistem besar yg besar dan memiliki waktu hidup lama pengembangan evolusioner menimbulkan masalah o Untuk sistem dengan daur hidup pendek

22 Kelebihan model Pengembangan Evolusioner
Lebih efektif dari pendekatan air terjun dalam menghasilkan sistem yang memenuhi kebutuhan langsung dari pelanggan. Sementara user mendapat pemahaman yang lebih baik dari masalah mereka, sistem perangkat lunak dapat merefleksikannya.

23 Pengembangan Sistem Formal (1)
Proses pengembangan Perangkat Lunak didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan.

24 Pengembangan Sistem Formal
Permasalahan Pendekatan ini memerlukan keahlian khusus dan sesungguhnya utk sebagian besar sistem proses ini tidak memberikan keuntungan biaya/kualitas yg signifikan dibanding pendekatan yg lain

25 Pengembangan Reuse-oriented(1)
Pada sebagian besar proyek PL, terjadi pemakaian ulang. Hal ini biasanya terjadi secara informal ketika orang yang bekerja diproyek tsb mengetahui adanya rancangan/kode yg mirip dgn yg dibutuhkan. Kode tersebut dicari, kmd memodifikasinya sbgmana dibutuhkan dan menggabungkannya dlm sistem.

26 Pengembangan Reuse-oriented(2)
Berbasis systematic reuse dimana sistem diintegrasikan dalam komponen yang sudah ada atau kadang komponen ini merupakan sistem juga (COTS/Commercial-off-the shelf system/sistem siap beli komersial)yg dpt digunakan utk memberikan fungsionalitas khusus seperti format teks, perhitungan numerik, dll

27 Pengembangan Reuse-oriented(3)
Tahap-tahapnya : 1. Analisakomponen Jika diketahui spesifikasi persyaratan, komponen2 utk implementasi spesifikasi tsb akan dicari. Biasanya tdk ada kesesuaian tepat dan komponen yg dipakai hanya memberikan sebagian dari fungsional yg dibutuhkan.

28 Pengembangan Reuse-oriented(4)
2. Modifikasi kebutuhan Pada tahap ini, persyaratan dianalisis dgn menggunakan informasi mengenai komponen yg telah didapat. Persyaratan kemudian dimodifikasi utk merefleksikan komponen yg tersedia. Jika modifikasi tdk mungkin dilakukan, maka kegiatan analisis komponen bisa diulang utk mencari solusi alternatif.

29 Pengembangan Reuse-oriented(5)
3. Desain sistem dengan reuse/pemakain ulang Pada fase ini kerangka kerja sistem dirancang atau kerangka kerja yg telah ada dipakai ulang. Beberapa PL yg baru mungkin perlu dirancang jk komponen yg dpt dipakai ulang tdk tersedia 4. Pengembangan dan integrasi PL yg tdk dpt dibeli akan dikembangkan dan komponen diintegrasikan utk membentuk sistem. Integrasi sistem pd model ini bisa merupakan proses pengembangan dan bukan kegiatan terpisah Pendekatan ini menjadi lebih penting tetapi masih terbatas penggunaannya

30 Pengembangan Re-Usable

31 Pengembangan Reuse-oriented(7)
Keuntungan pengembangan ini adl memperkecil biaya Memungkinkan penyelesaian PL cepat

32 Iterasi Proses Semua model proses yg ada memiliki kelebihan dan kekurangan Utk sistem yg besar perlu digunakan berbagai pendekatan utk berbagai bagian sistem, shg harus digunakan model hibrid atau model proses iteratif Model proses iteratif mengambarkan proses PL sbg suatu siklus kegiatan. Model proses iteratif mencakup 2 pendekatan : o Pengembangan incremental o Pengembangan spiral

33 Pengembangan Incremental(1)
Diusulkan oleh Mills(1980) Pd proses pengembangan inkremental, pelanggan mengidentifikasi scr grs besar layanan (service) yg akan disediakan oleh sistem. Kmd diidentifikasi layanan mana yg paling penting dan mana yg paling tdk penting. Bagian2 (inkrement) yg penting kmd diidentifikasi, setiap inkrement memberikan fungsionalitas sistem. Alokasi layanan pd inkrement bergantung pd prioritas layanan.Layanan dgn prioritas tertinggi dikirimkan terlebih dahulu ke pelanggan.

34 Pengembangan Incremental(2)
Begitu inkrement sistem telah teridentifikasi, persyaratan utk layanan yg hrs diserahkan pd inkrement pertama didefinisikan dgn rinci dan inkrement tsb dikembangkan dgn menggunakan proses pengembangan yg cocok. Pd saat pengembangan, analisis persyaratan utk inkrement berikutnya dpt dilakukan, tetapi perubahan persyaratan utk inkrement yg sdg dikerjakan tdk dpt diterima

35 Pengembangan Incremental(3)
Begitu satu inkrement telah selesai dan diserahkan, maka pelanggan dpt menggunakannya. Ini berarti pelanggan menerima pernyerahan awal dari sebagian fungsionalitas sistem. Demikian seterusnya hinga seluruh inkrement selesai. Integrasi inkrement baru dgn inkrement yg sdh ada akan dilakukan shg fungsionalitas sistem bertambah baik dgn ditambahkannya setiap inkrement yg dikirimkan

36 Pengembangan Inkrement

37 Penjelasan model Inkremen Pressman
Kombinasikan elemet-element dari waterfall dengan sifat iterasi/perulangan. Element-element dalam waterfall dikerjakan dengan hasil berupa produk dengan spesifikasi tertentu, kemudian proses dimulai dari fase pertama hingga akhir dan menghasilkan produk dengan spesifikasi yang lebih lengkap dari yang sebelumnya. Demikian seterusnya hingga semua spesifikasi memenuhi kebutuhan yang ditetapkan oleh pengguna. Produk hasil increment pertama biasanya produk inti (core product), yaitu produk yang memenuhi kebutuhan dasar. Produk tersebut digunakan oleh pengguna atau menjalani review/pengecekan detil. Hasil review tersebut menjadi bekal untuk pembangunan pada increment berikutnya. Hal ini terus dikerjakan sampai produk yang komplit dihasilkan. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi produk yang sudah bisa berfungsi dengan spesifikasi dasar.

38 Model Increment Sommerville

39 Keuntungan Pengembangan Incremental
Pelanggan tdk perlu menunggu sampai seluruh sistem dikirimkan. Increment pertama sdh memenuhi persyaratan mereka yg plg kritis, shg PL dpt segera digunakan. ‘increment’ awal berfungsi sebagai prototype untuk membantu memperoleh kebutuhan ‘increment’ selanjutnya Resiko kegagalan proyek lebih rendah Layanan sistem prioritas tertinggi cenderung menerima testing terbanyak

40 Pemrograman Extreme Diusulkan oleh Beck(1999)
Pendekatan baru untuk pengembangan berbasis pengembangan dan pelepasan fungsional ‘increment’ yang sangat kecil Mempercayakan perbaikan konstan, keterlibatan user dalam tim pengembang dan pemrograman Namun msh terlalu dini utk mengatakan apk ini akan menjadi pendekatan yg umum pengembangan PL

41 Pengembangan Spiral(1)
Diusulkan oleh Boehm(1988) Proses direpresentasikan sebagai spiral bukan sebagai urutan aktivitas dengan melihat sistem sebelumnya (backtracking) Setiap untai/loop dalam spiral merepresentasikan fase dalam proses Dgn demikian untai yg plg dlm berkenaan dgn kelayakan sistem, untai berikutnya dgn definisi persyaratan dan untai berikutnya perancangan sistem demikian seterusnya.

42 Pengembangan Spiral(2)
Setiap untai pd spiral dibagi 4 sektor : 1. Penentuan tujuan. Tujuan yg spesifik utk fase proyek,batasan dan resiko proyek didefinisikan. 2. Penilaian dan pengurangan resiko. Misal jika ada resiko persyaratan tdk sesuai mungkin diperlukan pengembangan sistem prototipe.

43 Pengembangan Spiral(3)
3. Pengembangan dan validasi. Setelah evaluasi resiko, model pengembangan utk sistem kmd dipilih. Contoh: jika resiko interface user adl paling dominan, model pengembangan prototipe evolusiner yg paling cocok, jika resiko utama adl integrasi subsistem maka model pengembangan yg paling cocok adl waterfall.

44 Pengembangan Spiral(4)
4. Perencanaan. Proyek ditinjau dan selanjutnya dibuat keputusan apk akan diteruskan dgn untai spiral berikutnya. Jika diputuskan utk terus, maka dibuat rencana fase proyek berikutnya.

45 Pengembangan Spiral(5)
Perbedaan penting antara model spiral dgn model proses perangkat lunak lainnya adalah dilakukan pertimbangan resiko

46 SPIRAL MODEL

47 RAD (Rapid Application Development)
RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

48 Kelemahan dalam model ini:
Tidak cocok untuk proyek skala besar Proyek bisa gagal karena waktu yang disepakati tidak dipenuhi Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini Resiko teknis yang tinggi juga kurang cocok untuk model ini

49 Gambar Model RAD

50 Fase-fase di atas menggambarkan proses dalam model RAD.
Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi?  kebutuhan dari sistem Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut  analisis kebutuhan dan data Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji.

51 Prototyping Model Kadang-kadang klien hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output. Di lain waktu mungkin dimana tim pembangun (developer) tidak yakin terhadap efisiensi dari algoritma yang digunakan, tingkat adaptasi terhadap sistem operasi atau rancangan form user interface. Ketika situasi seperti ini terjadi model prototyping sangat membantu proses pembangunan software.

52 Proses pada model prototyping yang bisa dijelaskan sebagai berikut:
Pengumpulan kebutuhan: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian-bagian yang akan dibutuhkan berikutnya. Detil kebutuhan mungkin tidak dibicarakan disini, pada awal pengumpulan kebutuhan Perancangan : perancangan dilakukan cepat dan rancangan mewakili semua aspek software yang diketahui, dan rancangan ini menjadi dasar pembuatan prototype. Evaluasi prototype: klien mengevaluasi prototype yang dibuat dan digunakan untuk memperjelas kebutuhan software.

53 Gambar model Prototype

54 Perulangan ketiga proses ini terus berlangsung hingga semua kebutuhan terpenuhi.
Prototype-prototype dibuat untuk memuaskan kebutuhan klien dan untuk memahami kebutuhan klien lebih baik. Prototype yang dibuat dapat dimanfaatkan kembali untuk membangun software lebih cepat, namun tidak semua prototype bisa dimanfaatkan. Sekalipun prototype memudahkan komunikasi antar developer dan klien, membuat klien mendapat gambaran awal dari prototype , membantu mendapatkan kebutuhan detil lebih baik namun demikian prototype juga menimbulkan masalah.

55 Masalah2 yg ada pada Prototype Model :
Dalam membuat prototype banyak hal yang diabaikan seperti efisiensi, kualitas, kemudahan dipelihara/dikembangkan, dan kecocokan dengan lingkungan yang sebenarnya. Jika klien merasa cocok dengan prototype yang disajikan dan berkeras terhadap produk tersebut, maka developer harus kerja keras untuk mewujudkan produk tersebut menjadi lebih baik, sesuai kualitas yang seharusnya. developer biasanya melakukan kompromi dalam beberapa hal karena harus membuat prototype dalam waktu singkat. Mungkin sistem operasi yang tidak sesuai, bahasa pemrograman yang berbeda, atau algoritma yang lebih sederhana.

56 Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.

57 Spesifikasi Perangkat Lunak(1)
Spesfikasi PL ditujukan utk menetapkan layanan apa yg dituntut dari sistem dan batasan pada operasi dan pengembangan sistem Kegiatan ini sering disebut rekayasa persyaratan Rekayasa persyaratan adl proses pengembangan spesifikasi PL Kegiatan ini mencakup pengembangan spesifikasi yg dpt dipahami oleh user sistem dan spesifikasi yg lebih rinci bagi pengembang sistem

58 Spesifikasi Perangkat Lunak(2)
Rekayasa persyaratan merupakan tahap yg sangat kritis dari proses PL krn kesalahan pd tahap ini pd akhirnya menimbulkan masalah pd perancangan dan implementasi sistem

59 Fase Rekayasa Persyaratan(1)
Studi Kelayakan. Studi ini memutuskan apk sistem yg diusulkan efektif dlm hal biaya dari sudut pandang bisnis dan apakah sistem dpt dikembangkan dgn keterbatasan anggaran biaya Perolehan dan analisa kebutuhan. Ini merupakan proses penurunan persyaratan sistem melalui observasi sistem yg ada, diskusi dgn user yg akan memakai dan yg mengadakan, analisis pekerjaan.

60 Fase Rekayasa Persyaratan(2)
3. Spesifikasi Persyaratan. Adalah kegiatan menterjemahkan informasi yg dikumpulkan pd kegiatan analisis menjadi dokumen yg mendefinisikan persyaratan user dan persyaratan sistem 4. Validasi persyaratan. Kegiatan ini memeriksa apk persyaratan dpt direalisasi, konsisten dan lengkap. Kesalahan yg ada dimodifikasi utk menyelesaikan masalah

61 Perancangan Dan Implementasi PL
Merupakan proses pengubahan spesifikasi sistem mjd sistem yg dpt dijalankan. Tahap ini selalu mencakup proses perancangan dan pemrograman PL, tetapi jika digunakan pendekatan evolusioner, maka bisa juga melibatkan perbaikan spesifikasi PL

62 Perancangan PL merupakan deskripsi struktur PL yg akan diimplementasikan, data yg merupakan bagian sistem,interface antara komponen2 sistem dan kadang2 algoritma yg digunakan