proses_perangkat_lunak_-_model-model_proses

Rekayasa Perangkat LunakProses Perangkat Lunak - Model-model Proses

Pertemuan 1

Bentar Priyopradono, S.Kom., M.Cs

Tujuan dan SasaranApa yang dimaksud dengan prose-proses perangkat lunak?Aktivitas-aktivitas yang mendasar, yang selalu ada dalam setiap proses rekayasa perangkat lunak?Bagai mana proses-proses rekayasa perangkat lunak dimodelkan dan bagaimana pola prosesnya?Apa itu model proses dan apa kekuatan serta kelemahannya?

Proses & Model Proses PLKerangka kerja untuk tugas-tugas yang dibutuhkan untuk membangun perangkat lunak dengan kualitas tinggi Strategi pengembangan PL yang melingkupi lapisan proses, metode dan alat bantu yang digunakan

Model Proses Perangkat LunakRPL didefinisikan sebagai sejumlah aktivitas-aktivitas kerja, tindakan-tindakan, serta pekerjaan-pekerjaan, yang harus dilaksanakan saat produk kerja dibuat.Masing-masing aktivitas kerja, tindakan-tidakan, serta pekerjaan-pekerjaan tersebut berada dalam kerangka kerja atau model yang mendefinisikan hubungan antar satu proses dengan proses yang lainnya.

Kerang Kerja Proses Perangkat Lunak

Proses Kerangka Kerja

Aktivitas-aktivitas penyangga

Aktivitas Kerangka Kerja # 1Tindakan-tindakan rekayasa perangkat lunak # 1.1

Satuan Pekerjaan-pekerjaan

Pekerjaan produk-produk kerja titik jaminan kualitas project milestones

Satuan Pekerjaan-pekerjaan

Pekerjaan produk-produk kerja titik jaminan kualitas project milestones

Tindakan-tindakan rekayasa perangkat lunak # 1.k

Proses Perangkat Lunak

Aktivitas Kerangka Kerja # nTindakan-tindakan rekayasa perangkat lunak # 1.1

Satuan Pekerjaan-pekerjaan

Pekerjaan produk-produk kerja titik jaminan kualitas project milestones

Satuan Pekerjaan-pekerjaan

Pekerjaan produk-produk kerja titik jaminan kualitas project milestones

Tindakan-tindakan rekayasa perangkat lunak # 1.k

Mendefinisikan Aktivitas Kerangka KerjaUntuk proyek perangkat lunak bersekala

kecil, spesifikasi kebutuhan pada umumnya bersifat langsung dan aktifitas komunikasi mungkin bisa dilakukan hanya dengan/melalui pembicaraan telepon.Aliran Proses

Komunikasi

Perencanaan

Pemodelan

Kontruksi

Penyerahan ke

Pelanggan / Pengguna

[a] aliran proses linier

Mendefinisikan Aktivitas Kerangka KerjaKomunika

siPerencana

anPemodela

nKontruksi

Penyerahan ke

Pelanggan / Pengguna

[b] aliran proses iteratif

Komunikasi

Perencanaan

Pemodelan

Kontruksi

Penyerahan ke

Pelanggan / Pengguna

[c] aliran proses evolusioner

Peluncuran suatuversi perangkat lunak

Mendefinisikan Aktivitas Kerangka Kerja

[d] aliran proses paralel

Komunikasi

Perencanaan

Pemodelan

Kontruksi

Penyerahan ke

Pelanggan / Pengguna

waktu

Mendefinisikan Aktivitas Kerangka KerjaMembuat kontak dengan pemesan melalui

teleponMembahas spesifikasi kebutuhan dan mencatatnyaMenorganisasi catatan-catatan menjadi pernyataan-pernyataan ringkas tertulis tentang spesifikasi kebutuhanMengirimkannya kepemesan melalu email untuk meminta persetujuan

Mendefinisikan Aktivitas Kerangka KerjaSaat proyek semakin komplek dan melibatkan banyak stakeholder, aktivitas komunikasi sebaiknya memiliki 6 tindakan nyata:

Pertemuan awal [inception]Proses bertanya-tanya dan melakukan penelitian [elicitation]Mendapatkan rincian [elaboration]Pembicaraan yang lebih serius [negotiation]Penulisan spesifikasi [specification]Pemeriksaan apakah segala sesuatunya berjalan dengan baik [validation]

Mendefinisikan Himpunan PekerjaanMendefinisikan pekerjaan-pekerjaan nyata yang harus diselesaikan untuk memenuhi sasaran tertentu dari suatu aksi rekayasa perangkat lunak.Untuk proyek yang kecil:

Membuat daftar para stakeholder untuk proyek Perangkat lunak yang akan dilaksanakan.Mengundang semua stakeholder untuk menghadiri pertemuan informal.Bertanya pada masing-masing stakeholder untuk membuat daftar fitur-fitur serta fungsi-fungsi.Mendiskusikan spesifikasi kebutuhan dan menggambarkan daftar spesifikasi kebutuhan yang bersifat final.Melakukan prioritasi untuk masing-masing spesifikasi kebutuhan.

Mendefinisikan Himpunan PekerjaanUntuk proyek yang lebih besar/komplek:

Membuat daftar para pemegang saham untuk RPL.Melakukan pembicaraan dengan stakeholder secara terpisah untuk mendapatkan kebutuhan dan keinginan secara keseluruhan.Mengembangkan daftar fungsi dan fitur yang bersifat awal berdasarkan masukan-masukan dari para stakeholder.Mencatat batasan-batasan yang akan diterapkan pada sistem/perangkat lunak

Pola-pola prosesMendeskripsikan permasalahan-permasalahan yang berkaitan dengan proses, yang dijumpai selama pekerjaan RPL berlangsungMendeskripsikan suatu permasalahan [dan solusinya] dan menghubungkan dengan aktivitas kerangka kerja [misal perencanaan dan menghubungkannya dengan aktifitas kerja peramalan/estimasi biaya proyek]

Waterfall Model

Requirement Definition

System and Software Design

Implementation and Unit

Testing

Integration and Unit Testing

Operation and Maintenance

Aktifitas Waterfall ModelRequirements analysis and definition: Mengumpulkan kebutuhan secara lengkap kemudian kemudian dianalisis dan didefinisikan kebutuhan yang harus dipenuhi oleh program yang akan dibangun.System and software design: Desain dikerjakan setelah kebutuhan selesai dikumpulkan secara lengkap. Implementation and unit testing: desain program diterjemahkan ke dalam kode kode dengan menggunakan bahasa pemrograman yang sudah ditentukan. Program yang dibangun langsung diuji.Integration and system testing: Penyatuan unit unit program kemudian diuji secara keseluruhan (system testing).

Aktifitas Waterfall ModelOperation and maintenance: mengoperasikan program dilingkungannya dan melakukan pemeliharaan, seperti penyesuaian atau perubahan karena adaptasi dengan situasi sebenarnya.Kekurangan yang utama dari model ini adalah kesulitan dalam mengakomodasi perubahan setelah proses dijalani. Fase sebelumnya harus lengkap dan selesai sebelum mengerjakan fase berikutnya.

Prototyping ModelSebagian besar customer hanya memberikan beberapa kebutuhan umum software tanpa detil input, proses atau detil output.

Aktifitas Prototyping ModelRequirements: developer dan klien bertemu dan menentukan tujuan umum, kebutuhan yang diketahui dan gambaran bagian bagian yang akan dibutuhkan berikutnya. Design: 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.

Evolutionary ModelIteratif, hasil proses berupa produk yang makin lama makin lengkap sampai versi terlengkap dihasilkan sebagai produk akhir dari proses.

Karakteristik IteratifModel ini cocok jika jumlah anggota tim pengembang/pembangun PL tidak cukup. Mampu mengakomodasi perubahan secara fleksibel. Produk yang dihasilkan pada increment pertama bukanlah prototype, tapi Produk yang sudah bisa berfungsi dengan spesifikasi dasar.

Spiral Model (Original: Boehm)

Spiral Model (Original: Boehm)Customer communication: membangun komunikasi yang baik dengan pengguna/customer. Planning: mendefinisikan resources, batas waktu, informasi informasi lain seputar proyek Risk analysis: identifikasi resiko managemen dan teknis Engineering: pembangunan contoh contoh aplikasi, misalnya prototype Construction and release: pembangunan, test, install dan support. Customer evaluation: mendapatkan feedback dari pengguna beradasarkan evaluasi PL pada fase engineering dan fase instalasi.

Spiral Model (Original: Boehm)Pada model spiral, resiko sangat dipertimbangkan. Resiko adalah sesuatu yang mungkin mengakibatkan kesalahan.Model spiral merupakan pendekatan yang realistik untuk PL berskala besar.Pengguna dan pembangun bisa memahami dengan baik software yang dibangunkarena setiap kemajuan yang dicapai selama proses dapat diamati dengan baik.

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 RAD model 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

RAD model

Fase fase dalam RAD modelBusiness modelling : menjawab 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.

Fase fase dalam RAD modelApplication 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.

V modelV model adalah metode pengembangan perangkat lunak yang mengijinkan pada setiap prosesnya untuk dilakukan testing dan validasi. Jadi proses baru menggunakan hasil dari proses lama sebagai acuannya. Ini memungkinkan meminimalisasikan kesalahan pada prosesnya.

V model

Keuntungan V modelBahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frameMeminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnyaPenyesuaian yang cepat pada projek yang baruMemudahkan dalam pembuatan dokumen projekBiaya yang murah dalam perawatan dan modifikasinya

Kerugian V modelBahasa yang digunakan untuk merepresentasikan konsep V model menggunakan bahasa formal. Contoh : dengan menggunakan objek model ataupun frame-frameMeminimalisasikan kesalahan pada hasil akhir karena ada test pada setiap prosesnyaPenyesuaian yang cepat pada projek yang baruMemudahkan dalam pembuatan dokumen projekBiaya yang murah dalam perawatan dan modifikasinyaAktifitas V-Model hanya difokuskan pada projectnya saja, bukan pada keseluruhan organisasi. V-Model adalah proses model yang hanya dikerjakan sekali selama project saja, bukan keseluruhan organisasi.Prosesnya hanya secara sementara. Ketika project selesai, jalannya proses model dihentikan. Tidak berlangsung untuk keseluruhan organisasi.

Kerugian V modelMetode yang ditawarkan terbatas. Sehingga kita tidak memiliki cara pandang dari metode yang lain. Kita tidak memiliki kesempatan untuk mempertimbangkan jika ada tools lain yang lebih baik.Toolnya tidak selengkap yang dibicarakan. SDE (Software Development Environment).Tidak ada tools untuk hardware di V-Model. Tool yang dimaksud adalah “software yang mendukung pengembangan atau pemeliharaan / modifikasi dari system IT.

Penerapan V ModelV model biasa digunakan pada proyek-proyek dengan skala yang besar. Sebagai contohnya yaitu digunakan di Jerman untuk mengatur sistem administrasi pemerintahannya dalam hal ini pada bagian BWB (Bundesamt für Wehrtechnik und Beschaffung = German Federal Office for Procurement).

Component based Development ModelComponent based development sangat berkaitan dengan teknologi berorientasi objek. Pada pemrograman berorientasi objek, banyak class yang dibangun dan menjadi komponen dalam suatu software. Class class tersebut bersifat reusable artinya bisa digunakan kembali. Model ini bersifat iteratif atau berulang ulang prosesnya.

Proses Component based Development ModelComponent Based Software Engineering

(CBSE) adalah proses yang menekankan perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada. CBSE terdiri dari dua bagian yang terjadi secara paralel yaitu software engineering (component based development) dan domain engineerin.

Proses Component based Development ModelDomain engineering menciptakan model domain

bagi aplikasi yang akan digunakan untuk menganalisis kebutuhan pengguna. Identifikasi, pembangunan, pengelompokan dan pengalokasikan komponen komponen software supaya bisa digunakan pada sistem yang ada dan yang akan datang. Software engineering (component based development) melakukan analisis terhadap domain model yang sudah ditetapkan kemudian menentukan spesifikasi dan merancang berdasarkan model struktur dan spesifikasi sistem, kemudian melakukan pembangunan software dengan menggunakan komponen komponen yang sudah ditetapkan berdasarkan analisis dan rancangan yang dihasilkan sebelumnya hingga akhirnya menghasilkan software.

Proses Component based Development Model