Proses Software
description
Transcript of Proses Software
Proses Software
Bab 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
Proses Software
Sekumpulan aktifitas yang saling terkait untuk spesifikasi, desain,implementasi dan testing perangkat lunak.
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
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.
Model Proses Perangkat Lunak(1) Model waterfall Model ini mengambil kegiatan proses
dasar seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian, pemeliharaan dan evolusi
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.
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
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.
Model Waterfall(1)
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
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.
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.
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
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
Fase-fase Waterfall menurut Pressman
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.
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
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
Pengembangan Evolusioner
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 (100.000 baris kode) atau medium(500.000 baris kode) o Untuk sistem besar yg besar dan memiliki waktu hidup lama pengembangan evolusioner menimbulkan masalah o Untuk sistem dengan daur hidup pendek
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.
Pengembangan Sistem Formal (1) Proses pengembangan Perangkat Lunak
didasarkan pada transformasi matematis dari spesifikasi sistem menjadi program yang dapat dijalankan.
Requirementsdefinition
Formalspecification
Formaltransformation
Integration andsystem testing
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
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.
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
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.
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.
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
Pengembangan Re-Usable
Requirementsspecification
Componentanalysis
Developmentand integration
System designwith reuse
Requirementsmodification
Systemvalidation
Pengembangan Reuse-oriented(7) Keuntungan pengembangan ini adl
memperkecil biaya Memungkinkan penyelesaian PL cepat
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
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.
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
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
Pengembangan Inkrement
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.
Model Increment Sommerville
Valida teincrement
Develop systemincrement
Design systemarchitecture
Integrateincrement
Valida tesystem
Define outline requirements
Assign requirements to increments
System incomplete
Finalsystem
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
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
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.
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.
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.
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.
Pengembangan Spiral(5) Perbedaan penting antara model
spiral dgn model proses perangkat lunak lainnya adalah dilakukan pertimbangan resiko
SPIRAL MODEL
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.
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
Gambar Model RAD
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.
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.
Proses pada model prototyping yang bisa dijelaskansebagai 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.
Gambar model Prototype
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.
Masalah2 yg ada pada Prototype Model :1. 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.
2. 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.
Agar model ini bisa berjalan dengan baik, perlu disepakati bersama oleh klien dan developer bahwa prototype yang dibangun merupakan alat untuk mendefinisikan kebutuhan software.
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
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
Fase Rekayasa Persyaratan(1)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
2. 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.
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
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
Perancangan PL merupakan deskripsi struktur PL yg akan diimplementasikan, data yg merupakan bagian sistem,interface antara komponen2 sistem dan kadang2 algoritma yg digunakan