Software Processes
Proses-proses Perangkat Lunak
Topik
Proses Perangkat Lunak
Aktivitas Fundamental di dalam RPL
Deskripsi Proses Perangkat Lunak
Proses Perangkat Lunak
Proses perangkat lunak (software process) adalah sekumpulan aktivitas yang saling berkaitan di dalam sebuah produksi perangkat lunak.
Aktivitas-aktivitas bisa berbentuk pengembangan perangkat lunak, memodifikasi sistem yang ada, atau menggabungkan beberapa komponen-
komponen.
Aktivitas Fundamental dalam RPL
Terdapat empat aktivitas fundamental dalam RPL
Spesifikasi Perangkat Lunak
Perancangan dan Implementasi Perangkat Lunak
Validasi Perangkat Lunak
Evolusi Perangkat Lunak
Setiap aktivitas bisa terdiri dari sub-aktivitas
lainnya.
Spesifikasi Perangkat Lunak
Mendefinisikan fungsi-fungsi dan batasan-batasan perangkat lunak yang akan dibangun.
Fungsionalitas dan batasan dibuat berdasarkan
kebutuhan pengguna PL.
Perancangan dan Implementasi PL
Pembangunan perangkat lunak sesuai dengan
spesifikasi yang telah didefinisikan.
Validasi Perangkat Lunak
Melakukan validasi perangkat lunak yang telah terbangun berdasarkan spesifikasi.
Memastikan perangkat lunak sesuai dengan
kebutuhan pengguna.
Evolusi Perangkat Lunak
Mengakomodasi perubahan-perubahan sesuai
dengan kebutuhan pengguna PL.
Deskripsi Proses Perangkat Lunak
Setiap proses dapat memiliki deskripsi yang terdiri dari:
Produk (products): keluaran dari sebuah proses, sebagai contoh: model arsitektur PL merupakan keluaran dari aktivitas perancangan PL.
Peranan (roles): Setiap orang yang terlibat didalam proses memiliki peranan yang spesifik, sebagai
contoh: manajer proyek, programmer, tester, dll.
Pre-conditions dan post-conditions: merupakan
kondisi-kondisi yang harus terpenuhi sebelum dan
Plan-driven dan Agile Processes
Plan-driven: Aktivitas-aktivitas proses
direncanakan diawal dan kemajuan dihitung berdasarkan perencanaan tersebut.
Agile: Perencanaan dilakukan secara bertahap
(incremental) dan proses berubah sesuai dengan
kebutuhan pengguna PL yang selalu berubah.
Software Process Models
Model-model Proses PL
Topik
Model-model Proses Perangkat Lunak
Model Waterfall
Incremental development
Reuse-oriented software engineering
Model Proses Perangkat Lunak
Model proses PL adalah representasi dari sebuah proses perangkat lunak.
Setiap model proses merepresentasikan sebuah proses PL dari sudut pandang tertentu.
Setiap model proses hanya merepresentasikan
sebagian informasi dari keadaan sebenarnya
(parsial).
Model-model Proses PL
Model Waterfall
Termasuk proses plan-driven. Setiap aktivitas dilakukan secara berurutan.
Incremental development
Spesifikasi, pengembangan, dan validasi dilakukan secara berselang-seling. Proses bisa termasuk plan- driven atau agile.
Reuse-oriented software engineering
Menggabungkan komponen-komponen reusable yang
sudah ada ketika membangun PL.
Model Proses PL dalam Dunia Nyata
Model-model proses tidak digunakan secara terpisah dan eksklusif.
Model-model proses dapat saling dikombinasikan sesuai dengan kebutuhan PL.
Dalam satu pembangunan sistem, berbagai model
proses dapat dikombinasikan.
Model Waterfall
Model Waterfall terdiri dari beberapa fase, yaitu:
Analisa dan definisi kebutuhan (Requirement analysis and definition)
Desain sistem dan perangkat lunak (System and software design)
Implementasi dan unit testing (Implementation and unit testing)
Uji coba sistem dan uji coba terintegrasi (Integration and system testing)
Pengoperasian dan perawatan (Operation and
maintenance)
Ilustrasi Model Waterfall
Requirements Definition
System and Software Design
Implementation and Unit Testing
Integration and System Testing
Kelemahan Model Waterfall
Setiap fase dilakukan jika fase sebelumnya sudah selesai.
Sehingga model ini sulit mengakomodasi perubahan kebutuhan pengguna PL.
Spesifikasi kebutuhan PL harus sudah lengkap dan terdefinisi di fase awal.
Sangat sedikit sistem-sistem yang spesifikasi kebutuhannya sudah jelas di fase awal.
Terkadang di fase implementasi, programmer
menemukan desain yang tidak sesuai akan tetapi
tidak bisa kembali ke fase desain.
Penggunaan Model Waterfall
Model ini cocok untuk sistem yang spesifikasi kebutuhannya sudah jelas dan tidak memiliki banyak perubahan.
Model ini juga banyak digunakan pada sistem-
sistem besar yang dikerjakan secara terpisah di
banyak tempat.
Incremental Development
Pada model ini PL dibangun dalam versi-versi kecil.
Setiap versi terdiri dari aktivitas spesifikasi, pengembangan, dan validasi.
Model ini diawali dengan implementasi versi awal yang berisi implementasi kebutuhan minimum.
Pengguna melihat versi awal dan memberikan umpan balik.
Umpan balik tersebut digunakan untuk implementasi versi selanjutnya.
Aktivitas-aktivitas ini dilakukan sampai mencapai
versi final.
Ilustrasi Incremental Development
Specification
Development Outline
Description
Initial Version
Initial Version Intermediate
Versions Concurrent Activities
Keuntungan dari Incremental Dev.
Biaya untuk mengakomodasi perubahan kebutuhan dari pengguna PL bisa ditekan.
Lebih mudah untuk mendapatkan umpan balik dari hasil implementasi.
Pengguna PL dapat memberikan komentar dan umpan balik berdasarkan hasil implementasi.
Pengguna lebih sering menerima dan melihat PL
yang sedang dikembangkan.
Kelemahan Incremental Dev.
Kemajuan tidak tampak dari proses.
Karena tidak ada dokumentasi yang merepresentasikan setiap versi.
Membuat dokumentasi untuk setiap versi tidak efisien dalam biaya.
Kualitas struktur sistem menurun seiring dengan peningkatan versi.
Perubahan-perubahan membuat kualitas struktur
sistem menurun. Oleh karena itu perlu investasi
Reuse-oriented Software Engineering
Sistem dibangun memanfaatkan komponen-
komponen yang sudah ada (COTS: Commercial-off- the shelf systems).
Terdiri dari beberapa tahapan:
Analisa komponen (Component analysis)
Modifikasi kebutuhan (Requirement modification)
Desain sistem dengan penggunaan kembali (System design with reuse)
Pengembangan dan integrasi (Development and
integration)
Ilustrasi Reuse-oriented SE
Requirements
specification Component
Analysis Requirement
modification System design with reuse
Development
and integration System
validation
Tipe Komponen Perangkat Lunak
Tipe-tipe komponen yang dapat digunakan, yaitu:
Web services.
Sekumpulan obyek-obyek (Collections of objects) yang terintegrasi dalam sebuah component
framework sebagai contoh: .NET atau J2EE.
Perangkat lunak yang didesain untuk kondisi khusus
(stand-alone software systems).
Keuntungan Reuse-oriented SE
Meminimalisir besar PL yang harus dibangun.
Meminimalisir biaya dan resiko.
Waktu pengembangan yang lebih cepat.
Waktu delivery PL yang lebih singkat.
Kelemahan Reuse-oriented SE
Spesifikasi kebutuhan pengguna terkadang harus dikorbankan untuk dapat menyesuaikan dengan spesifikasi komponen PL yang ada.
Akibatnya, sistem yang dibangun mungkin tidak
sesuai dengan keinginan pengguna PL.
Process Activities
Aktivitas Proses
Topik
Aktivitas di dalam Proses PL
Spesifikasi
Pengembangan
Validasi
Evolusi
Aktivitas di dalam Proses PL
Terdapat empat aktivitas fundamental didalam proses PL, yaitu:
Spesifikasi (specification)
Pengembangan (development)
Validasi (validation)
Evolusi (evolution)
Aktivitas-aktivitas tersebut dilakukan dalam urutan yang berbeda sesuai dengan model proses yang
diadaptasi.
Pada model waterfall, aktivitas-aktivitas dilakukan secara berurutan.
Spesifikasi PL
Spesifikasi PL adalah proses memahami dan
mendefinisikan layanan yang harus disediakan oleh sistem dan batasan yang dimiliki oleh sistem.
Proses dalam rekayasa kebutuhan
Feasibility study
Apakah sistem ini memungkinkan untuk dibangun baik secara teknis maupun finansial?
Requirements elicitation and analysis
Apa yang dibutuhkan oleh pengguna dari sistem?
Requirements specification
Mendefinisikan kebutuhan secara detil
Requirements validation
Memeriksa keabsahan dari definisi kebutuhan
Proses dalam Rekayasa Kebutuhan
Feasibility study
Requirement elicitation and
analysis
Requirement specification
Requirement validation Feasibility
report System
models
User and system requirements
Perancangan dan Implementasi PL
Sebuah proses yang mewujudkan spesifikasi PL menjadi sistem yang berjalan.
Perancangan PL
Merancang struktur PL yang merupakan realisasi dari spesifikasi PL.
Implementasi PL
Menerjemahkan struktur PL menjadi sistem yang
berjalan.
Proses Perancangan
Platform information
Requirement specification
Data description
Architectural design
Interface design
Component design Database design
Design inputs
Design activities
Design outputs
Aktivitas Perancangan
Desain arsitektur (architectural design),
mengidentifikasi struktur sistem secara keseluruhan, komponen-komponen utama, dan relasi antar
komponen.
Desain antarmuka (interface design), mendefinisikan antarmuka komponen-komponen dalam sistem.
Desain komponen (component design), merancang bagaimana tiap komponen bekerja.
Desain basisdata (database design), merancang struktur
basisdata yang sesuai dengan kebutuhan sistem.
Validasi PL
Verifikasi dan validasi ditujukan untuk memeriksa bahwa sistem telah sesuai dengan spesifikasi dan memenuhi kebutuhan dari pengguna PL.
Uji coba termasuk bagian dari verifikasi dan
validasi PL.
Tahapan Uji Coba (2)
Component
testing System testing Acceptance
Testing
Tahapan Uji Coba (2)
Uji coba komponen (component testing)
Tiap komponen diuji coba secara independen (terisolasi).
Komponen ini dapat berupa fungsi, obyek, atau sekumpulan fungsi-fungsi dan obyek.
Uji coba sistem (system testing)
Melakukan uji coba sistem secara keseluruhan (integrasi antar komponen-komponen).
Uji coba penerimaan (acceptance testing)
Melakukan uji coba dengan menggunakan data dari
Tahapan Uji Coba dalam proses Plan- driven
Acceptance test plan
System integration test
plan
Sub-system integration test
plan Requirement
specification
System specification
System design
Module and unit code
and test Detailed
design
Service Acceptance
test
System integration
test
Sub-system integration
test
Evolusi PL
Perangkat lunak bisa berubah dan fleksibel.
Perangkat lunak harus dapat berubah sesuai
dengan perubahan kebutuhan yang disesuaikan
dengan perubahan situasi bisnis.
Evolusi Sistem
Existing
systems New system
Define system requirements
Assess existing systems
Propose system changes
Modify systems
Penanganan Perubahan
Topik
Perubahan di dalam Perangkat Lunak
Prototipe Perangkat Lunak
Incremental Delivery
Perubahan di dalam PL
Perubahan tidak bisa dihindari pada proyek PL besar.
Perubahan tuntutan bisnis memicu perubahan kebutuhan sistem.
Teknologi baru yang memberikan peluang untuk meningkatkan sistem yang sudah ada.
Perubahan platform yang menyebabkan perubahan pada aplikasi.
Perubahan menimbulkan biaya lebih, termasuk
Mengurangi Biaya
Menghindari perubahan, terdapat aktivitas didalam model proses yang dapat mengantisipasi
perubahan.
Sebuah prototipe sistem dapat menunjukan fitur-fitur utama kepada pengguna PL.
Tolerasi terhadap perubahan, model proses
dirancang sehingga perubahan dapat diakomodasi dengan biaya yang relatif rendah.
Model proses incremental dapat mengakomodasi
perubahan di versi selanjutnya.
Prototipe Perangkat Lunak
Prototipe adalah versi awal dari sebuah sistem yang digunakan untuk menunjukkan konsep dan
mencoba beberapa opsi desain.
Prototipe dapat digunakan di:
Proses rekayasa kebutuhan
Proses perancangan
Proses uji coba
Keuntungan Prototipe
Peningkatan kegunaan sistem
Hasil mendekati dengan kebutuhan nyata dari pengguna PL
Peningkatan kualitas desain
Peningkatan keterawatan
Meminimalisir upaya pengembangan.
Proses Pengembangan Prototipe
Establish prototype objectives
Prototyping plan
Define prototype functionality
Outline definition
Develop prototype
Executable prototype
Evaluate prototype
Evaluation report
Incremental Delivery
Memecah fungsi-fungsi yang dibutuhkan kedalam beberapa tahap daripada menyelesaikan sistem besar sekaligus dalam satu tahap.
Memberi skala prioritas terhadap kebutuhan
pengguna. Kebutuhan dengan prioritas tinggi
diutamakan di tahap-tahap awal.
Incremental Delivery
Keuntungan Incremental Delivery
Fungsionalitas PL dapat disampaikan kepada pengguna PL lebih awal.
Prototipe pada tahap awal berguna untuk
menjaring kebutuhan untuk tahap selanjutnya.
Resiko yang lebih rendah terhadap kegagalan
proyek.
Kelemahan Incremental Delivery
Kebanyakan sistem membutuhkan infrastruktur dasar yang digunakan oleh bagian-bagian dari sistem.
Sulit untuk mengidentifikasi infrastruktur tsb ketika kebutuhan tidak terdefinisi dengan detil ditahap awal.
Pada proses iteratif, spesifikasi dikerjakan berbarengan dengan pembangunan PL.
Di banyak organisasi, spesifikasi sistem yang lengkap
merupakan bagian dari kontrak. Sehingga proses ini
Referensi
