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