membangun menuju lebih baik adalah rasa syukur atas...
TRANSCRIPT
1
Membangun Menuju lebih baik
Adalah rasa syukur atas kehidupan yang diberikan
Kenikmatan kehidupan harus diusahakan,
Tetapi harus dalam kebenaran,
2
METHODE PEMBANGUNAN SOFTWARE
Pengenalan Software Engineering
Taslim Rochmadi
Cetakan pertama
Tahun 2013
ISBN 978-979-3733-70-8
3
Kata Pengantar
Di dalam suatu peralatan yang dibuat saat ini, kita telah mencapai suatu garis dimana apa yang
dibuat tidak hanya berbentuk barang yang bersifat statis, diam saja. Namun saat ini telah banyak
barang peralatan manusia yang dapat berfungsi dinamis. Dengan suatu sentuhan atau apapun
yang diperintahkan manusia, maka peralatan tersebut melakukan sesuai perintah tersebut.
Berbagai peralatan manusia akan dibuat dengan berbagai kemampuan. Ini dimungkinkan karena
adanya system software yang mulanya diterapkan pada suatu system computer. Prinsip awal
dimana computer mengerjakan berbagai perhitungan, memudahkan manusia dalam melakukan
pekerjaan menghitung yang rumit serta membutuhkan waktu banyak, kemudian computer
membantu penyimpanan data dan pengadministrasian dokumen. Semua itu membutuhkan
software. Jadi software yang ada didalam computer.
Namun dengan semakin murahnya peralatan hadware computer, baik itu prosessor maupun
peripheral dan memori yang ada didalamnya, maka peralatan yang digunakan manusia yang
mengandung perlatan prosessor dengan softwarenya itu semakin banyak dan berkembang.
Dimulai dari peralatan komunikasi maka akan merambah ke peralatan yang lainnya.
Maka peralatan yang dibutuhkan manusia nanti akan mempunyai hardware dan dikontrol oleh
software. Software perlu dikembangkan bersama sama dengan hardware yang dibentuk atau
direkayasa. Software demikian penting karena tampa itu sebuah hadware tidak dapat mempunyai
fungsi sebagai yang dikehendaki. Seolah olah barang itu mati dan barang itu hidup hanya dengan
ada dan tidak adanya software didalamnya.
Manusia memang selalu membutuhkan sesuatu, dari kebutuhan itu ingin selalu memenuhinya.
Usaha yang berkali kali untuk melakukan inovasi, mengembangkan sesuatu, membuat produk
baru, penemuan penemuan ide dan metode, yang tadinya tak diperhatikan akan memberi
padanya beberapa keuntungan, menjalankan kembali roda perekonomian, adanya celah dan
perkembangan, serta memberi kemudahan kemudahan dalam kehidupannya. Dengan software
ada berbagai kemungkinan baru terkuak berbagai inovasi dan kreativitas yang terbuka lebar.
Buku software engineering ini dimaksud untuk mengenal lebih dalam mengenai teknik membuat
software dalam suatu lingkungan hardware yang telah siap untuk dilakukan pengembangan
system software. Karena luasnya lingkup software maka bahasan engineering atau rekayasa
terhadap teknik pembuatan software bertumpu pada pembuatan software aplikasi atau software
yang bersifat kompleks.
Dengan kompleksitas software, maupun kompleksitas system yang akan dibangun, maka buku ini
disusun untuk bagian awalnya, merupakan dasar dalam mempelajari perekayasaan software.
Didalamnya ada konsep dasar serta bentuk dasar yang perlu bagi pemula untuk mengembangkan
software.
4
Daftar isi
Daftar isi.......................................................................................................................................... 4
BAB 1 : PEMBUKAAN............................................................................................................... 7
1.1 Introduksi untuk Software Engineering ...................................................................... 9
1.1.1 Membahas apa itu Software Engineering ......................................................... 9
1.1.2 Software Engineering ........................................................................................... 9
1.1.3 Engineering dan Teknik ..................................................................................... 11
1.2 Software ....................................................................................................................... 12
1.3 Penggunaan Software dalam peralatan dan pelaksanaan pekerjaan manusia . 12
1.4 Sifat atau karakteristik Software ............................................................................... 13
1.5 Jenis Software ............................................................................................................ 17
1.6 Perubahan yang terjadi dalam Software Engineering .......................................... 19
1.6.1 Evolusi Software ................................................................................................. 20
1.6.2 Role software ...................................................................................................... 23
Kesimpulan ............................................................................................................................... 26
BAB 2 : Pengertian Proses dalam Software Engineering ................................................. 27
2.1 Pembahasan secara umum tentang proses pada SE ........................................... 27
2.2 Pembahasan pada tataran Teknologi ...................................................................... 28
2.3 Pembahasan pada tataran Framework ................................................................... 30
2.3.1 Umbrella activity ................................................................................................. 31
2.3.2 Framework activity ................................................................................................... 32
2.4 Proses SE yang diterapkan dalam Proyek software ............................................. 32
2.4.1 Proses Generik SE ............................................................................................. 32
2.4.2 Proses pada Industri yang mature .................................................................. 34
2.4.3 Keterkaitan Proses dengan pelaksana dan Teknologi yang digunakan ..... 36
2.4.4 Keterkaitan Teknologi (OO, Web, tools) .......................................................... 37
2.4.5 Keterkaitan Proses dengan Produk ...................................................................... 38
Bab 3 : Proses Model Pembangunan Software ................................................................... 39
3.1 Pengertian proses model .......................................................................................... 39
3.1.1 Jenis Proses Model yang dikenal ..................................................................... 39
3.1.2 Prasyarat Proses Model, Kelebihan dan Kelemahan .................................... 41
3.2 Garis besar bentuk proses Model ............................................................................ 42
3.2.1 Proses Model Dasar ........................................................................................... 43
3.2.2 Proses Model Yang Dikembangkan....................................................................... 48
5
BAB 4 : Pembangunan Software ........................................................................................... 51
4.1 Pengembangan Software secara Praktis ..................................................................... 51
4.1.1 Pengertian SE secara praktis ................................................................................. 52
4.1.2 Esensi dari prilaku Praktis....................................................................................... 53
4.2.Prinsip prinsip Kepraktisan ............................................................................................ 53
4.3 Pelaksanaan SE secara praktis .................................................................................... 56
4.3.1 Komunikasi ............................................................................................................... 56
4.3.2 Planning .................................................................................................................... 57
4.3.3 Modeling .................................................................................................................... 58
4.3.4 Konstruksi ................................................................................................................. 58
4.3.5 Deployment .............................................................................................................. 59
4.4 Pengembangan software Profesional ......................................................................... 61
4.5 Pengembangan dalam Sistem Proyek ........................................................................ 62
Kesimpulan ............................................................................................................................... 63
Bab 5 : Requirements Engineering ........................................................................................ 65
5.1 Dokumen Requirement................................................................................................... 66
5.2 Metode mendapatkan requirement software ............................................................... 70
5.3 Menggambarkan hasil requirement .............................................................................. 71
5.4 Menegosiasi requirement ............................................................................................... 72
5.5 Memvalidasi requirement ............................................................................................... 72
5.6 Menentukan Kwalitas...................................................................................................... 73
5.7 Software measurement dan metric ............................................................................... 78
5.8 Review dan inspeksi ....................................................................................................... 84
BAB 6 : Pembangunan System Modeling ........................................................................... 89
6.1 Desain Architectural ........................................................................................................ 89
6.1.1 Arsitektur data .......................................................................................................... 90
6.1.2 Struktur Program ...................................................................................................... 90
6.1.3 Desain Arsitektur ..................................................................................................... 91
6.1.4 Urutan Desain Arsitektur ................................................................................... 93
6.2 Design Software .............................................................................................................. 94
6.2.1 Desain level komponen ........................................................................................... 94
6.2.2 Desain interface ....................................................................................................... 95
6.2.3 Desain data ............................................................................................................... 96
6.3 Sistem modeling .............................................................................................................. 96
6.3.1 UML...................................................................................................................... 97
6.3.2 Context models ........................................................................................................ 98
6
6.3.3 Interaction models .............................................................................................. 99
6.3.4 Structural models.................................................................................................... 102
6.3.5 Behavioral models .................................................................................................. 103
Bab 7 : Testing ....................................................................................................................... 107
7.1 Perbedaan Testing, Validasi, Verifikasi dan Inspeksi ............................................... 108
7.2 Meyiapkan Testing / Planning terhadap Testing .................................................. 110
7.3 Mengembangkan testing / developing ........................................................................ 112
7.4 Testing strategi .............................................................................................................. 113
7.4.1 Unit testing .............................................................................................................. 114
7.4.2 Integrating testing ................................................................................................... 117
7.4.3 Validation testing .................................................................................................... 125
7.4.4 System testing ........................................................................................................ 126
7.5 Test-driven development .............................................................................................. 128
Bab 8 : Evolusi Software ........................................................................................................ 133
8.1 Pengembangan software dan Evolusinya .................................................................. 133
8.2 Proses evolusi ................................................................................................................ 136
8.3 Dinamika Evolution ........................................................................................................ 138
8.3.1 Software maintenance ........................................................................................... 140
8.3.2 Maintenance prediction.......................................................................................... 141
8.3.3 Software reengineering.......................................................................................... 144
Index ........................................................................................................................................... 147
Glossary ...................................................................................................................................... 152
Referensi ..................................................................................................................................... 155
7
BAB 1 : PEMBUKAAN
Di dalam suatu peralatan yang dibuat saat ini, kita telah mencapai suatu garis
dimana apa yang dibuat tidak hanya berbentuk barang yang bersifat statis, diam
saja. Namun saat ini telah banyak barang peralatan manusia yang dapat berfungsi
dinamis. Dengan suatu sentuhan atau apapun yang diperintahkan manusia, maka
peralatan tersebut melakukan sesuai perintah tersebut.
Berbagai peralatan manusia akan dibuat dengan berbagai kemampuan. Ini
dimungkinkan karena adanya system software yang mulanya diterapkan pada
suatu system computer. Prinsip awal dimana computer mengerjakan berbagai
perhitungan, memudahkan manusia dalam melakukan pekerjaan menghitung
yang rumit serta membutuhkan waktu banyak, kemudian computer membantu
penyimpanan data dan pengadministrasian dokumen. Semua itu membutuhkan
software. Jadi software yang ada didalam computer.
Namun dengan semakin murahnya peralatan hadware computer, baik itu
prosessor maupun peripheral dan memori yang ada didalamnya, maka peralatan
yang digunakan manusia yang mengandung perlatan prosessor dengan
softwarenya itu semakin banyak dan berkembang. Dimulai dari peralatan
komunikasi maka akan merambah ke peralatan yang lainnya.
Hardware akan dengan cepat diproduksi dan semakin murah, sementara dengan
adanya software maka kwalitas barang akan semakin meningkat, harga atau nilai
tambah banyak terletak pada software dari pada pada hardwarenya. Dengan
demikian software akan semakin berpengaruh daripada hardware. Kemampuan
software yang ada didalamnya akan menunjukkan kwalitas barang itu.
Maka peralatan yang dibutuhkan manusia nanti akan mempunyai hardware dan
dikontrol oleh software. Software perlu dikembangkan bersama sama dengan
hardware yang dibentuk atau diciptakan. Software demikian penting karena tampa
itu sebuah hadware tidak dapat mempunyai fungsi sebagai yang dikehendaki.
8
Seolah olah barang itu mati dan barang itu hidup dengan ada dan tidak adanya
software didalamnya.
Manusia memang selalu membutuhkan sesuatu, dari kebutuhan itu ingin selalu
memenuhinya. Usaha yang berkali kali untuk melakukan inovasi,
mengembangkan sesuatu, membuat produk baru, penemuan penemuan ide dan
metode, yang tadinya tak diperhatikan akan memberi padanya beberapa
keuntungan, menjalankan kembali roda perekonomian, adanya celah dan
perkembangan, serta memberi kemudahan kemudahan dalam kehidupannya.
Manusia selalu dalam ujian, antara melakukan sesuatu yang berakibat kebaikan
dan sesuatu yang berakibat buruk. Untuk itulah maka dia harus selalu
menyeimbangkan dirinya karena amanah tanggung jawab yang dia dapatkan
dengan kemampuannya itu untuk menjalankan arah tujuannya disesuaikan
dengan keputusannya disebabkan karena ujian yang ia dapatkan itu.
Buku software engineering ini dimaksud untuk mengenal lebih dalam mengenai
teknik membuat software dalam suatu lingkungan hardware yang telah siap untuk
dilakukan pengembangan system software. Karena luasnya lingkup software
maka bahasan engineering atau rekayasa terhadap teknik pembuatan software
bertumpu pada pembuatan software aplikasi atau software yang bersifat
kompleks.
Dengan kompleksitas software, maupun kompleksitas system yang akan
dibangun, maka buku ini disusun dalam beberapa bagian. Untuk bagian ini dibahas
khusus mengenani metoda pembuatan software yang dilaksanakan dalam kaedah
perekayasaan atau engineering yang benar. Dengan membaca buku ini
diharapkan pengembang software mempunyai wawasan yang lebih baik, tidak
hanya pada level programming tetapi lebih banyak melihat pada level diatas
programming.
Memperluas wilayah jangkauan metodologis yang dengan pengetahuan ini dapat
membentuk kelompok kerja yang lebih kokoh, fleksible serta mempunyai
komitmen dalam membentuk software yang lebih berkwalitas, lebih cepat
penyelesaiannya serta hasil karya yang lebih professional.
9
Susunan sudut padang itu dibahas tentang cara engineering dasar, dengan
maksud untuk mengenalkan pokok pokok konsep dan pelaksanaan engineering
secara garis besar, sehingga mahasiswa mendapat gambaran apa itu software
engineering.
1.1 Introduksi untuk Software Engineering
1.1.1 Membahas apa itu Software Engineering
Perekayasaan mungkin adalah kata yang agak aneh, kadang penggunaannya
di Indonesia ini agak untuk hal yang negative, padahal sesungguhnya
perekayasaan atau engineering adalah kata yang didalamnya penuh dengan
bentuk usaha manusia, dalam mengolah pikir serta kentrampilan, dalam satu
kesatuan, didalamnya pun ada semacam seni bila dipandang kebebasan
berpikir yang digunakan.
Perekayasaan software adalah warna sendiri dalam bidang ini, yaitu bidang
software, sebab pada awalnya engineering lebih banyak pada hardware.
Software engineering dengan demikian adalah bentuk yang khusus diakhir era
ini berkembang dengan pesat.
1.1.2 Software Engineering
Software engineering adalah disiplin teknik yang berkaitan dengan semua
aspek perangkat lunak produksi dari tahap awal spesifikasi sistem sampai
pemeliharaan system ( setelah software itu telah mulai digunakan) . Dalam
definisi ini, ada dua frase kunci:
a. Teknik yang dilakukan Engineers atau insinyur adalah suatu disiplin
membuat sesuatu yang bekerja. Mereka menerapkan teori, metode,dan
alat-alat di mana keduanya tepat. Namun, mereka menggunakannya
dengan selektif dan selalu mencoba untuk menemukan solusi untuk
masalah bahkan ketika tidak ada atau tak berlaku teori dan metode.
Insinyur juga mengakui bahwa mereka harus bekerja untuk menghadapi
kendala organisasi dan keuangan sehingga mereka harus mencari solusi
dalam hal Kendala ini.
10
b. Semua aspek rekayasa perangkat lunak untuk bentuk produksi Software
tidak hanya peduli dengan proses teknis dari pengembangan perangkat
lunak. Ini juga mencakup kegiatan seperti manajemen proyek perangkat
lunak dan pengembangan alat, metode, dan teori untuk mendukung
produksi perangkat lunak.
Software Engineering (Rekayasa perangkat lunak) dimaksudkan untuk dapat
mendukung pengembangan perangkat lunak secara profesional, berbeda
dengan cara pada pemrograman individu. Didalamnya termasuk termasuk
teknik cara memperoleh program spesifikasi, melakukan desain, dan evolusi.
Dengan software engineering ini diharapkan dapat membantu untuk
mendapatkan pandangan yang luas,Beberapa hal penting dapat diringkas
dalam beberapa pertanyaan yang sering diajukan, dapat dilihat pada table 1.1.
Banyak orang berpikir bahwa software hanyalah kata lain untuk program
komputer. Sebagaimana pengertian diatas, perangkat lunak tidak hanya
program itu sendiri, tetapi juga semua dokumentasi terkait dan data konfigurasi
yang diperlukan untuk membuat program beroperasi dengan benar. Seorang
profesional mengembangkan sistem perangkat lunak sering lebih dari satu
program. Sistem ini biasanya terdiri dari beberapa program terpisah dan file
konfigurasi yang digunakan untuk mengatur
program-program ini. Dengan demikian maka termasuk dokumentasi sistem,
yang menggambarkan struktur dari sistem, dokumentasi pengguna, yang
menjelaskan bagaimana menggunakan sistem, dan situs bagi pengguna untuk
men-download informasi produk terbaru.
Ini adalah salah satu perbedaan penting antara pembangunan perangkat lunak
profesional dan amatir. Jika anda menulis sebuah program untuk diri sendiri,
tidak ada orang lain yang akan menggunakannya dan anda tidak perlu khawatir
tentang menulis panduan program, mendokumentasikan program desain, dll.
11
1.1.3 Engineering dan Teknik
Software engineering adalah disiplin teknik yang berkaitan dengan produksi
semua aspek perangkat lunak dari tahap awal spesifikasi sistem sampai
pemeliharaan sistem, hingga setelah perangkat lunak itu telah mulai digunakan,
semuanya bisa masih dalam lingkup engineering. Dalam definisi ini, ada dua
frase kunci:
a. Teknik adalah disiplin Engineers untuk membuat sesuatu bekerja. Mereka
menerapkan teori, metode, dan alat-alat dimana keduanya tepat. Namun,
mereka menggunakannya selektif dan selalu mencoba untuk menemukan
solusi untuk suatu masalah, bahkan ketika tidak ada teori dan metode.
Insinyur juga mengakui bahwa mereka harus bekerja untuk memecahkan
kendala organisasi dan keuangan sehingga mereka mencari solusi dari
berbagai kendala.
b. Semua aspek produksi rekayasa perangkat lunak tidak hanya peduli
dengan proses teknis dari pengembangan perangkat lunak, tetapi juga
mencakup kegiatan seperti manajemen proyek perangkat lunak dan
pengembangan alat, metode,dan teori untuk mendukung produksi
perangkat lunak.
c. Teknik ini adalah tentang mendapatkan hasil kualitas yang diperlukan
dalam lingkup suatu jadwal dan anggaran. Hal ini sering kali memerlukan
kompromi, yang membuat-insinyur tidak bisa menjadi perfeksionis.
Berbeda dengan Orang-orang menulis program untuk diri mereka sendiri,
bagaimanapun, bisa menghabiskan waktu sebanyak seperti yang mereka
inginkan pada pengembangan program.
Secara umum, insinyur perangkat lunak mengadopsi pendekatan yang
sistematis dan terorganisir untuk mereka bisa bekerja dengan baik , karena hal
ini merupakan cara yang paling efektif untuk menghasilkan perangkat lunak
berkualitas tinggi.
12
Teknik adalah tentang memilih metode yang paling sesuai untuk satu set
kumpulan keadaan sehingga pendekatan yang lebih kreatif kurang formal untuk
pengembangan mungkin bisa efektif dalam beberapa situasi.
1.2 Software
Apa itu software?
Untuk memperoleh pemahaman tentang perangkat lunak (software), software
berbeda dari hal-hal yang biasa manusia bangun. Software adalah sesuatu yang
bersifat logis, berbeda daripada elemen sistem yang bersifat fisik. Oleh karena itu,
Software memiliki karakteristik yang sangat berbeda daripada hardware.
Definisi yang biasa dilakukan dalam teksbook, software mempunyai kesatuan dari
3 hal dibawah ini :
1. Software adalah suatu instruksi (program komputer) yang bila di
eksekusi atau dijalankan akan membentuk feature, fungsi ataupun
kinerja tertentu.
2. Software didalamnya ada struktur data yang memungkinkan program
untuk memanipulasi(melakukan perubahan yang diinginkan) terhadap
informasi secara memadai atau terukur, dan
3. Didalam software ada dokumen yang menggambarkan operasi dan
penggunaan program.
Software is (1) instructions (computer programs) that when executed provide desired
features, function, and performance; (2) data structures that enable the programs to
adequately manipulate information; and (3) documents that describe the operation and
use of the programs.
1.3 Penggunaan Software dalam peralatan dan pelaksanaan
pekerjaan manusia
Ada beragam software yang dikembangkan untuk membuat kinerja komputer
menjadi maksimal. Seiring semakin berkembangnya teknologi dalam dunia
teknologi informasi,software komputer juga mengalami banyak kemajuan. Dari
yang awalnya hanya software untuk kebutuhan administrasi saja,sekarang
berkembang dengan munculnya software dalam segala bidang kehidupan.
13
Misalnya saja software untuk desain gambar, software untuk mengedit video,
software untuk mengatur pekerjaan industri, software untuk melihat perubahan
kesehatan, hingga sampai software untuk mengingatkan kita tentang suatu acara.
Dengan makin banyaknya software komputer yang semakin berkembang dari
waktu ke waktu. Tentu saja akan mempermudah pekerjaan manusia.
Alat yang berfungsi sebagaimana computer, ada prosessor, ada memori, dan
pheripheralnya semakin banyak, dan itu kita sebut saja peralatan pintar
(intelligent), alat itu memerlukan software, maka demikian banyak dibutuhkan
software untuk menjalankan alat alat tersebut.
Semua software komputer bisa digunakan sesuai dengan perintah dari
penggunanya. Karena itu kehebatan dari suatu software tergantung dari
penggunaannya. Jika seorang pengguna mempunyai keahlian yang tinggi alam
menggunakan suatu software,maka pekerjaan yang dihasilkannya tentu akan
mempunyai kualitas yang tinggi juga. Lain halnya jika seorang pengguna kurang
memilki kemampuan dalam menggunakan software, tentu saja hasil pekerjaan
yang digunakannya akan berkualitas kurang bagus.
Penggunaan peralatan dengan demikian untuk masa mendatang, bila kita tidak
tahu kerja software, alat tersebut sangat kuno, kecanggihan peralatan tergantung
pada software yang dimasukkan didalamnya.
1.4 Sifat atau karakteristik Software
Berdasarkan definisi software tersebut diatas, untuk lebih mengerti tentang
software, maka perlu dikenal sifat atau karakteristik software itu sendiri. Disini ada
3 karakteristik utama suatu software:
1. Software dikembangkan atau direkayasa, tidak diproduksi dalam
pengertian klasik.
Meskipun ada beberapa kesamaan antara pengembangan perangkat lunak dan
peragkat keras pada proses manufaktur, disini ada bentuk yang berbeda secara
fundamental.
14
a. Dalam kedua proses pengembangan, kualitas tinggi dicapai melalui
desain yang baik, sedang pada fase manufacturing untuk hardware
kualitas dapat diperiksa dan dilakukan dengan mudah, dan kualitasnya
teridentifikasi, dikenal, serta terukur, sedang untuk software tidak ada
(atau tidak mudah dilakukan perbaikan), pengukuran kwalitas sulit
dilaksanakan pada fase manufacturing (pemrograman).
b. Kedua kegiatan tergantung pada orang, tetapi hubungan antara orang-
orang yang bekerja dalam posisinya agar dicapai suatu tahapan hasil
tertentu, adalah berbeda.
c. Kedua kegiatan memerlukan pembangunan “produk”, tetapi pendekatan
yang dilakukan berbeda.
d. Biaya untuk software terkonsentrasi di bidang teknik engineeringnya.
Sedang pada Hardware terkonsentrasi pada pelaksanaan produksi.
Ini berarti bahwa proyek-proyek perangkat lunak tidak dapat dikelola sebagai
manufaktur proyek di bentuk fisik.
2. Software tidak Usang
Bila besi, yang kita gunakan untuk bahan peralatan, maka besi itu dengan
perjalanan waktu akan aus auatu usang, baik itu berkarat, atau kekuatannya
semakin melemah, atau bentuk lain, dalam pengertian kita bahwa semakin lama
akan semakin besar kerusakannya.
Gambar 1.1 menggambarkan tingkat kegagalan sebagai fungsi waktu untuk
hardware. Hubungan antara jumlah kesalahan dan waktu, hasilnya sering disebut
"kurva bak mandi,", kurva itu menunjukkan bahwa pada produk hardware secara
relativ tingkat kegagalan yang tinggi pada awal hidupnya (kegagalan sering
disebabkan cacat desain atau manufaktur). Cacat ini kemudian dikoreksi, dan
tingkat kegagalan yang menurun ke tingkat keadaan yang mendekati tampa
kesalahan atasu tampa masalah untuk beberapa periode waktu. Seiring dengan
berjalannya waktu, walau bagaimanapun, tingkat kegagalan akan naik lagi, karena
sebagai komponen hardware akan menderita akumulasi misal terpengaruh debu,
getaran, suhu yang ekstrem, dan banyak terpengaruh berbagai hal termasuk
penyakit, lingkungan lainnya. Sederhananya, perangkat keras mulai aus
15
Gambar 1.1: Kurva kesalahan untuk peralatan jenis Hardware
Sedangkan pada Software tidak terpengaruh terhadap faktor lingkungan
sebagaimana yang menyebabkan hardware jadi aus. Oleh karena itu, tingkat
kegagalan kurva untuk Software mengambil bentuk "kurva ideal", tidak naik lagi.
Adapun yang ditunjukkan pada Gambar 1.2. Cacat yang tidak ditemukan akan
menyebabkan tingkat kegagalan yang tinggi pada awal kehidupan dari sebuah
program. Cacat itu dikoreksi (mudah-mudahan, tanpa menimbulkan kesalahan
lain), dan kurva menjadi menurun dan merata seperti yang ditunjukkan sebagai
kurva ideal. Kurva ideal adalah terlalu menyederhanakan model kegagalan yang
sebenarnya dari software. Kesimpulan implikasinya jelas-bahwa perangkat lunak
tidak aus. Yang dikenal disini adalah itu deteriorate, atau merosot, memburuk,
menurun mutunya.
Gambar 1.2: Kurva Kesalahan pada Software, yang Ideal dan adanya Perubahan.
Kenyataanya Software sering dilakukan perubahan, maka akibat aktivitas ini,
diperoleh kurva actual, kontradiksi yang tampak dapat dijelaskan dengan kurva
sebagai berikut: Selama hidupnya, software akan mengalami perubahan. Karena
16
berbagai hal perlu dirubah (karena factor teknis, requirement, lingkungan, dll),
dengan perubahan yang dibuat, ada kemungkinan bahwa kesalahan akan
diperkenalkan (terjadi), ini menyebabkan adanya kegagalan, maka kurva
membentuk spike seperti yang ditunjukkan pada Gambar 1.2. Sebelum kurva
dapat kembali ke tingkat steady-state kegagalan asli, perubahan lain diminta,
menyebabkan kurva spike lagi. Jadi hasilnya, Perlahan-lahan, tingkat kegagalan
minimum mulai naik-perangkat lunak menjadi memburuk karena perubahan.
Aspek lain untuk menggambarkan perbedaan antara perangkat keras dan
perangkat lunak dapat juga di bedakan sebagai berikut. Ketika komponen
hardware habis dipakai, diganti dengan spare part baru. Adapun bagian perangkat
lunak tidak mungkin menggantinya dengan suku cadang lain. Setiap kegagalan
pada software menunjukkan kesalahan dalam desain atau dalam proses melalui
mana desain diterjemahkan ke dalam mesin-kode untuk dieksekusi. Oleh karena
itu, pemeliharaan perangkat lunak melibatkan berbagai persyaratan yang
kompleksitas nya lebih besar dari pemeliharaan perangkat keras.
3. Software dibuat secara customize
Lihatlah bagaimana cara perangkat keras untuk produk berbasis komputer
dirancang dan dibangun. Para insinyur awalnya membuat desain, skema
sederhana dibuat pada sirkuit digital, kemudian melakukan beberapa analisis
fundamental untuk memastikan bahwa fungsi yang tepat akan tercapai, dan
kemudian pergi ke rak di mana catalog komponen digital yang ada. Setiap sirkuit
terpadu CHIP memiliki nomor bagian, fungsi didefinisikan dan divalidasi,
antarmuka yang terdefinisi dengan baik, dan satu set standar pedoman integrasi.
Setelah setiap komponen dipilih, bisa diambil dari rak, dan dipasang sebagai
disiplin teknik yang berkembang, koleksi komponen desain standar dibuat.
Sekrup standar digunakan dan sirkuit terpadu hanya dua dari ribuan komponen
standar yang digunakan, insinyur mechanical dan listrik bekerjasama karena
mereka melakukan desain baru suatu sistem. Dan Komponen dapat digunakan
kembali, apa yang telah dibuat sebelumnya, sehingga insinyur dapat
berkonsentrasi pada unsur-unsur yang benar-benar inovatif desain, yaitu bagian-
bagian yang mewakili beberapa hal baru. Dengan demikian dalam dunia hardware,
penggunaan kembali komponen adalah bagian alami dari proses rekayasa. Dalam
17
dunia perangkat lunak, itu hanya mulai dicapai dalam skala yang luas, dan hanya
akhir akhir ini.
Untuk itu sebuah komponen perangkat lunak harus dirancang dan
diimplementasikan sehingga dapat digunakan kembali dalam berbagai program
yang berbeda. Dengan bentuk encapsulated, komponen software yang dapat
digunakan kembali, dapat dibuat baik data dan proses yang diterapkan pada data.
Dengan demikian, memungkinkan insinyur perangkat lunak untuk membuat
aplikasi baru dari parts.
Antarmuka pengguna saat ini dibangun dengan komponen yang dapat digunakan
kembali yang memungkinkan penciptaan grafis jendela, pull-down menu, dan
berbagai macam mekanisme interaksi dikerjakan dengan lebih mudah. Dalam hal
ini Struktur data dan detail proses, diperlukan untuk membangun antarmuka,
terkandung dalam sebuah perpustakaan komponen reusable untuk konstruksi
antarmuka.
1.5 Jenis Software
Saat ini ada sekitar 7 jenis software yang dapt dibedakan sebagai berikut:
1. Sistem Software.
Sistem Software adalah kumpulan program yang ditulis untuk melayani
program lain. System Software terletak berhubungan dengan erat dengan
hardware. Daerah sistem software ditandai dengan interaksi yang besar
dengan hardware komputer, dapat digunakan oleh beberapa pengguna
bersama sama, operasi yang konkuren ini membutuhkan scheduling,
berbagi sumber daya, dan adanya proses manajemen yang canggih, struktur
data yang kompleks, serta interface eksternal ganda.
Gambar 1.3: Letak system software dan software Aplikasi terhadap Hardware
hardware
System Software
Software Aplikasi
18
2. Software Aplikasi.
Aplikasi perangkat lunak, atau software aplikasi adalah terdiri dari program
mandiri yang menyelesaikan kebutuhan bisnis yang spesifik.
Yang dimaksud Aplikasi disini adalah karena digunakan untuk
menyelesaikan sesuatu dalam proses bisnis, membantu kalkulasi teknis dan
data atau dengan cara memfasilitasi operasi bisnis atau manajemen / teknis,
hingga pengambilan keputusan. Selain pengolahan data konvensional,
Software aplikasi digunakan untuk mengontrol fungsi bisnis secara real-time
(misalnya, point-of-sale transaction, real-time manufaktur kontrol proses).
3. Engineering Scientific software.
Ini adalah bagian dari software Aplikasi yang digunakan khusus untuk
menyelesaikan jenis pekerjaan engineering atau teknik dan Scientific,
dimana didalamnya ditandai adanya algoritma, rekayasa dan dengan
jangkauan berkisar dari astronomy ke vulkanologi, dari analisis otomotif stres
ke ruang orbit satelit, rumusan dinamika, dan dari biologi molekuler hingga
DNA.
Wilayah software ini juga bergerak menjauh dari algoritma numerik
konvensional. Misalnya Aplikasi komputer-aided design, simulasi sistem,
dan lainnya.
4. Embeded Software (Perangkat lunak yang tertanam).
Perangkat lunakyang tertanam dan berada dalam suatu produk atau sistem
dan digunakan untuk melaksanakan dan mengontrol fitur dan fungsi bagi
pengguna akhir-dan untuk sistem itu sendiri.
Embeded software dapat melakukan fungsi terbatas dan esoteris (misalnya,
keypad kontrol untuk oven microwave) atau menyediakan fungsi yang
signifikan dan kontrol capability (misalnya, fungsi digital dalam sebuah mobil
seperti kontrol bahan bakar, dashboard, sistem pengereman, dll ).
Software seperti ini menyatu antara software aplikasi dan sistem
softwarenya, karena kadang membutuhkan interaksi yang kuat dengan
hardware.
19
5. Product-Line Software.
Software ini jenis software aplikasi yang digunakan dalam proses bisnis,
misalkan inventory control, word processing, spreadsheets, computer
graphics, multimedia, entertainment, database management, personal and
business financial applications dan seterusnya.
Saat ini sudah demikian banyak macamnya, bahkan untuk peralatan yang
smart, software ini mudah di download,serta mudah diinstalall.
6. WEB Application
Ini bagian dari software Aplikasi yang mempunyai ruang lingkup yang luas,
mempunyai span beragam aplikasi. Dalam bentuk yang paling sederhana,
webapps bisa sedikit lebih dari satu set file hypertext, didalamnya terkait ada
dalam formasi dengan menggunakan teks dan grafis yang terbatas. Dan bisa
meluas menjadi seperti e-commerce dan aplikasi B2B, webapps ini
berkembang ke dalam lingkungan komputasi yang lebih canggih yang tidak
hanya menyediakan fitur mandiri, fungsi komputasi, dan konten ke pengguna
akhir, tetapi juga terintegrasi dengan database perusahaan dan system
business aplikasi.
Pembangunan kurang formal kadang sangat cocok untuk pengembangan
sistem berbasis web, yang membutuhkan perpaduan perangkat lunak dan
keterampilan desain grafis.
7. Artificial Intelligence Software
Artificial intelligence software ini memanfaatkan nonnumerical-
Algorithms untuk memecahkan masalah kompleks yang tidak mudah untuk
perhitungan atau analisis secara langsung. Aplikasi dalam area ini meliputi
robotika, expert systems, pattern recognition (image and voice), artificial
neural networks, theorem proving, and game playing.
1.6 Perubahan yang terjadi dalam Software Engineering
Awal tahun 1940-an menulis software telah mulai berkembang menjadi
sebuah profesi. Penulisan software langsung berhubungan dengan
20
Kwalitas. Kualitas dapat merujuk pada bagaimana perangkat lunak
dipertahankan, untuk stabilitas, kecepatan, kegunaan, testability, mudah
dibaca, ukuran, biaya, keamanan, dan jumlah kesalahan/ kekurangan atau
"bug", serta kualitas yang kurang dapat terukur seperti keanggunan,
keringkasan, dan kepuasan pelanggan.
Maka perubahan software berkaitan dengan bagaimana cara terbaik untuk
memaksimalkan kualitas perangkat lunak dan bagaimana menciptakannya.
1.6.1 Evolusi Software
Dari awal software selalu terjadi evolusi, evolusi ini terjadi diluar dari domain
application, ukuran besarnya (size), atau kompleksitasnya, perangkat lunak
komputer ini akan berkembang dari waktu ke waktu. Perubahan software yang
sering disebut sebagai pemeliharaan software, mendorong proses evolusi ini
dan terjadi ketika mengoreksi kesalahan. Penyesuaian software ini karena
adanya lingkungan baru, ketika ada permintaan pelanggan dengan fitur baru
atau fungsi baru, dan ketika aplikasi dilakukan re-engineering untuk
mendapatkan keuntungan yang bersifat lebih daripada yang lama.
1. Era Awal
Pada awalnya suatu software dibuat untuk mesin hardware yang baru dibuat.
Software dibuat karena adanya mesin hardware, karena computer baru
selalu muncul, maka orang harus menulis ulang semua program mereka
untuk bisa berjalan di mesin-mesin yang baru.
Perangkat keras komputer (hardware) saat itu adalah untuk aplikasi-spesifik.
Misal untuk perhitungan ilmiah, perhitungan perbankan, dan tugas khusus
lainnya. Sehingga ada tugas ilmiah dan bisnis yang memerlukan mesin yang
berbeda. Software saat itu masih sangat tergantung mesin dan berarti juga
menggunakan bahasa mesin itu.
Karena adanya kebutuhan untuk sering menerjemahkan perangkat lunak
lama untuk memenuhi kebutuhan mesin-mesin baru, timbulah software
dengan bahasa ‘high-order’, bahasa yang dikembangkan lebih mudah diingat
manusia seperti FORTRAN, COBOL, dan ALGOL.
Awalnya Vendor hardware menyerahkan sistem perangkat lunak secara
gratis sebagai tambahan dari perangkat keras, Hardware waktu itu tidak bisa
21
dijual tanpa software. Kemudian beberapa perusahaan mulai menjual jasa
membangun perangkat lunak yang dikustom untuk keperluan khususnya,
tetapi saat itu tidak ada perusahaan software yang menjual paket perangkat
lunak.
Era awal ini sekitar 1945-1965. Istilah Rekayasa perangkat lunak pertama
kali muncul di akhir 1950-an dan awal 1960-an. Istilah yang ada pada teknik
sipil, listrik, dan teknik komputer diambil programmer, rekayasa juga berarti
untuk perangkat lunak.
Awal resmi profesi rekayasa perangkat lunak diperoleh pada konferensi
rekayasa perangkat lunak pada tahun 1968 di Garmisch, Jerman.
2. Era perkembangan
Manny Lehman [e.g., LEH97a] dan rekan-rekannya memiliki analisis detail tentang
industry-grade software dan systems, dalam upaya mengembangkan teori evolusi
yang ada di software “a unified theory for software evolution.” Hasil yang diperoleh
ada 8 Hukum yang patut dicatat yaitu:
The Law of Continuing Change (1974). E-type systems' must be continually
adapted, or else they become progressively less satisfactory. jenis E-sistem
'harus terus menerus disesuaikan, kalau tidak akan menjadi semakin
kurang memuaskan.
The Law of Increasing Complexity (1974). As an E-type system evolves its
complexity increases unless work is done to maintain or reduce it. Sebagai
Jenis E-system akan berkembang meningkat kompleksitasnya kecuali ada
pekerjaan yang dilakukan untuk mempertahankan atau mengurangi itu.
The Law of Self-Regulation (1974). The E-type system evolution process is self-
regulating with distribution of product and process measures close to normal.
Jenis E-system mempunyai proses evolusi regulasi mandiri, dengan
distribusi pengukuran produk dan proses yang normal.
The Law of Conservation of Organizational Stability (1980). The average
effective global activity rate in an evolving E-type system is invariant over
product lifetime. Rata-rata aktivitas tingkat global yang efektif dalam jenis
E-sistem berkembang secara invarian selama hidup produk.
22
The Law of Conservation of Familiarity (1980). As an E-type system evolves
all associated with it, developers, sales personnel, and users, for example,
must maintain mastery of its content and behavior to achieve satisfactory
evolution. Excessive growth diminishes that mastery. Hence the average
incremental growth remains invariant as the system evolves. Sebagai E-
sistem yang berevolusi pada semua yang berhubungan dengan
itu,misalnya pengembang, sales, dan pengguna, harus tetap menguasai
content dan perilaku untuk mencapai evolusi yang memuaskan.
Pertumbuhan yang berlebihan mengurangi penguasaan hal itu. Oleh karena
itu dengan pertumbuhan rata-rata yang inkremental tetap invarian sebagai
sistem berevolusi.
The Law of Continuing Growth (1980). The functional content of E-type
systems must be continually increased to maintain user satisfaction over the
system's lifetime. Content fungsional dari E-sistem harus terus ditingkatkan
untuk menjaga kepuasan pengguna selama seumur hidup dari system itu.
The Law of Declining Quality (1996). The quality of E-type systems will appear
to be declining unless they are rigorously maintained and adapted to opera-
tional environment changes. Kualitas E-sistem akan terlihat selalu menurun
kecuali ada usaha perawatan dan penyesuaian dengan operasional dari
perubahan lingkungan.
The Feedback System Law (1996). E-type evolution processes constitute
multilevel, multiloop, multiagent feedback systems and must be treated as
such to achieve significant improvement over any reasonable base. Proses
evolusi E-System merupakan proses yang bertingkat, multiloop, multiagen
dengan sistem umpan balik dan harus diperlakukan sebagai adanya agar
mencapai perbaikan yang signifikan diatas dasar yang masuk akal.
23
1.6.2 Role software
Table 1.1
Pertanyaan Jawaban
Apa itu software? Program komputer dan dokumentasi terkait. Produk perangkat lunak dapat dikembangkan untuk pelanggal tertentu atau dapat dikembangkan untuk pasar secara umum.
Apa yang dimaksud dengan atribut perangkat lunak yang baik?
Perangkat lunak yang baik harus memberikan apa yang diperlukan, yaitu tentang fungsionalitas dan kinerja untuk pengguna dan harus bisa dipertahankan, dapat diandalkan, dan dapat digunakan.
Apa rekayasa perangkat lunak (software engineering)?
Software engineering adalah disiplin teknik yang berkaitan dengan semua aspek produksi perangkat lunak.
Apa aktivitas fundamental dalam software engineering?
Spesifikasi perangkat lunak, pengembangan perangkat lunak, software validasi, dan evolusi perangkat lunak.
Apa perbedaan antara teknik rekayasa perangkat lunak dan ilmu komputer(software engineering and computer science)?
Ilmu komputer berfokus pada teori dan fundamental, sedang rekayasa perangkat lunak bersangkutan dengan praktik mengembangkan dan memberikan perangkat lunak yang berguna.
Apa perbedaan antara software engineering and system engineering (rekayasa perangkat lunak dan rekayasa sistem)?
Rekayasa sistem berkaitan dengan semua aspek sistem berbasis komputer, pembangunan termasuk hardware, software, dan proses rekayasa. Rekayas Perangkat lunak merupakan bagian dari proses yang lebih umum diatas .
Apa tantangan kunci yang dihadapi software engineering ?
Mengatasi keragaman yang meningkat, adanya tuntutan untuk mengurangi waktu pengiriman, dan cara mengembangkan perangkat lunak yang dapat dipercaya.
Berapa biaya rekayasa perangkat lunak?
Kira-kira 60% untuk biaya pengembangan perangkat lunak , 40% untuk menguji. Untuk perangkat lunak yang bersifat kustomise ,biaya evolusi sering melebihi biaya pengembangan.
Apa saja teknik rekayasa software yang terbaik dan bagaimana metode nya?
Sementara semua proyek perangkat lunak harus profesional dikelola dan dikembangkan, teknik yang berbeda sesuai untuk berbagai jenis sistem. Misalnya, permainan harus selalu dikembangkan dengan menggunakan serangkaian prototipe, sedangkan sistem kontrol keselamatan yang kritis membutuhkan spesifikasi lengkap dan dianalisis dengan baik untuk dikembangkan. Anda tidak bisa, karena itu, mengatakan bahwa salah satu metode lebih baik daripada yang lain.
Apa perbedaan rekayasa perangkat lunak biasa dan yang dibuat dalam bentuk Web ?
Dengan Web menyebabkan ketersediaan jasa perangkat lunak dan kemungkinan pengembangan layanan berbasis sistem. Pengembangan sistem berbasis Web telah menyebabkan kemajuan penting dalam bahasa pemrograman dan penggunaan kembali perangkat lunak(software reuse).
24
Rekayasa perangkat lunak adalah penting untuk dua alasan:
1. Semakin banyaknya individu dan masyarakat bergantung pada sistem
perangkat lunak yang canggih. Kita harus mampu menghasilkan sistem
yang dapat diandalkan dan dipercaya secara ekonomi dan
cepat.
2. Hal ini biasanya lebih murah, dalam jangka panjang, bila menggunakan
metode rekayasa perangkat lunak dan teknik untuk sistem perangkat lunak,
daripada hanya menulis program seolah-olah itu adalah
proyek pemrograman pribadi. Untuk sebagian besar jenis sistem, sebagian
besar biaya adalah biaya untuk mengubah perangkat lunak setelah
program itu telah mulai digunakan.
3. Pendekatan sistematis yang digunakan dalam rekayasa perangkat lunak
kadang-kadang disebut proses perangkat lunak. Sebuah proses perangkat
lunak adalah urutan kegiatan yang mengarah ke produksi suatu produk
software. Ada empat kegiatan mendasar yang umum untuk semua proses
perangkat lunak.
Kegiatan-kegiatan ini adalah:
1. Spesifikasi perangkat lunak, dimana pelanggan dan perekayasa
mendefinisikan perangkat lunak yang akan diproduksi dan kendala pada
operasi.
2. Pengembangan perangkat lunak, di mana perangkat lunak ini dirancang
dan diprogram.
3. Software validasi, di mana software tersebut akan diperiksa untuk
memastikan bahwa itu adalah apa yang pelanggan membutuhkan.
4. Software evolusi, di mana perangkat lunak tersebut dimodifikasi untuk
mencerminkan pelanggan yang berubah dan pasar persyaratan.
Berbagai jenis sistem perlu proses pembangunan yang berbeda. Misalnya,
real-time software, untuk software di dalam pesawat terbang, ini harus benar-benar
ditentukan sebelum pembangunan dimulai. Dalam sistem e-commerce, spesifikasi
dan program biasanya dikembangkan bersama-sama. Akibatnya, kegiatan generik
dapat diselenggarakan di berbagai cara dan dijelaskan pada berbagai tingkat detail
tergantung pada jenis perangkat lunak sedang dikembangkan.
25
Rekayasa perangkat lunak terkait dengan ilmu komputer dan rekayasa sistem:
a. Ilmu komputer berkaitan dengan teori dan metode yang mendasari
komputer dan perangkat lunak sistem, sedangkan rekayasa perangkat
lunak bersangkutan dengan cara praktek memproduksi perangkat lunak.
Beberapa pengetahuan tentang ilmu komputer sangat penting untuk
insinyur perangkat lunak, sebagaimana bahwa beberapa pengetahuan
fisika sangat penting untuk insinyur listrik. Teori ilmu pengetahuan
komputer, adalah yang paling sering berlaku untuk bentuk program-
program yang relatif kecil. Teori ilmu pengetahuan komputer tidak selalu
dapat diterapkan untuk program besar, atau masalah yang kompleks, atau
menjadi solusi yang mana membutuhkan perangkat lunak.
b. Rekayasa sistem berkaitan dengan semua aspek pengembangan dan
evolusi sistem yang kompleks di mana perangkat lunak memainkan peran
utama. Rekayasa Sistem berkaitan dengan hardware, kebijakan
pembangunan dan proses desain, sistem distribusi/penyebaran, serta
rekayasa perangkat lunak. Insinyur system terlibat dalam menentukan
sistem, mendefinisikan arsitektur secara keseluruhan, dan kemudian
mengintegrasikan bagian-bagian yang berbeda untuk menciptakan sistem
hingga selesai.
26
Kesimpulan
Software telah berkembang cepat sejak tahun 1970 an, menjadi kunci
evolusi berbagai macam hal baik di perusahaan, pemerintahan, berbagai
peralatan, menggunakan software.
Software ini pun berevolusi pula, apa akhir ini penggunaan yang mobile,
dan kebutuhan informasi padat conten dibutuhkan, berkembang dalam
lingkungan jaringan yang luas,maka software jenis Web-based cukup
merajai penggunaannya.
Software engineering sebagai pengetahuan baik untuk ilmu dan
ketrampilan, mengarahkan kita untuk mengerti tentang proses, metode, dan
alat bantu. Untuk memudahkan kita bisa membuat software yang semakin
kompleks dan dengan waktu yang semakin terbatas.
27
BAB 2 : Pengertian Proses dalam Software
Engineering
Bahasan tentang proses dalam software engineering adalah berhubungan dengan
aktiviiitas dalam produksi untuk membuat software. Aktivitas ini termasuk
development dari penggunaan programing yang standard ataupun penggunaan
bahsa pemrograman seperti Java dan C.
Pada proses ini maka perlu kita mengerti tentang Prosess ini, tentang framework
aktivitas yang generic dalam membangun software, bagaimana proses
pemodelannya, atau pola dari proses itu, apa prospek atau kelebihan dan
kekurangan suatu model dan seterusnya.
Ada beberapa bentuk proses software tetapi biasanya ada dalam 4 aktivitas
berikut:
1. Mendefinisikan software spesifikasi, disini fungsionalitas software,
batatasan operasi ditentukan
2. Mekakukan desain danimplementasi software, software yang sudah
dispesifikasi seharusnya dibuat;
3. Software validation, artinya melakukan validasi untuk memastikan
kesesuaian dengan kebutuaan dan keinginan customer;
4. Software evolusi, maksudnya adalah membuat software yang selalu
mengikuti perubahan sesuai dengan kebutuhan customer.
2.1 Pembahasan secara umum tentang proses pada SE
Jika akan melakukan pengembangan atau membuat suatu produk, atau suatu
sistem, yang harus dilakukan adalah membuat langka langkah yang dapat
diprediksi, langkah langkah ini sering disebut roadmap, yang bisa membantu untuk
memberi gambaran yang lebih jelas terhadap yang akan dikerjakan sehingga akan
28
tepat waktu dan mempunyai hasil yang high quality. Road map ini bagi
pembangunan software kita bisa namanakan sebagai proses software.
Apa yang menjadikan hal ini adalah penting, ini karena dengan adanya software
proses maka akan dibentuk atau akan diusahakan suatu pembangunan software
yang dilaksanakan bisa lebih stabil, terkontrol, terorganisasi, sehingga aktivitas
yang ada dari pra engineering, manajer bisa beradaptasi dalam langkah langkah
yang diinginkan, mulai proses mendifinisikan, membangun dan mengetes dapat
diatur sedemikian rupa.
Hasil dari pekerjaan ini adalah program, dokumen, dan data yang diproduksi
sebagai konsekwensi aktivitas dan tugas yang telah didefinisikan dalam proses.
Untuk itu maka perlu ada sejumlah mekanisme proses yang dapat memastikan
maturity atau kedewasaan dari proses software, karena akan mempengaruhi
quality, timeline, log term viability dari produk.
2.2 Pembahasan pada tataran Teknologi
Secara teknologi dapat kita mulai dari definisi yang lebih komprehensip
disampaikan oleh IEEE, software engineering adalah :
(1) the application of systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software; thas is the application of
engineering to software.
(2) the study of approaches as in (1);
Software engineering adalah proses, tapi dalam tataran teknologi ata dalam
tataran cara pengembangan dapat disusun suatu pemabagian berdasarkan
teknologinya, sehingga terbentuk lapisan lapisan teknologi; penelaahan atas
teknologi itu dapat kita lihat lapisan berikut’
Gambar 2.1 : lapisan teknologi dalam software engineering
29
a.Lapisan pertama, atau lapisan terbawah adalah suatu teknologi yang
mensupport untuk mendapatkan hasil qualitas yang memuaskan, atau
berintikan pada quality focus.
Layer pertama ini perlu mendapatkan komitment pada seluruh komponen
pembuat software baik dalam level manajemen maupun hingga pada hasil
teknisi yang terbawah. Untuk itu secara organisasional kita kenal misalnya
Total Quality management, Sig sigma, dan lainnya. Prinsipnya harus
menjalankan improvement pada proses, culture, yang akhirnya dapat
meningkatkan dan mengefektivkan pendekatan untuk memfokuskan pada
kwualitas.
b.Lapisan ke 2 adalah proses, maksudnya pada lapisan ini terdapat teknik
tetentu untuk melaksanakan proses. Sehingga sering juga disebut sebagai
lapisan Proses Method, lapisan yang membahas teknik atau metode proses.
Didalam lapisan ini kita membahas mengenai cara yang terbaik untuk
membuat software yang disusun berdasarkan suatu urutan spesifik. Dengan
urutan proses yang spesifik itu software dibangun. Jadi pada lapisan ini
dibahas metode proses yang paling tepat untuk membangun suatu software
berdasarkan berbagai hal yang mempengaruhinya.
c.Lapisan ketiga, yaitu method. Lapisan method membahas setiap method
secara detail. Yang dibahas disini adalah method, yaitu requiremen, atacara
mendapatkan requirement dengan cara method komunikasi tertentu, juga
tetang metode lain misalnya analisis, method desain dan seterusnya. Setiap
metode tersebut dibahas tekniknya atau cara pengerjaannya secara
mendetail. Sehingga terselesaikan suatu metode sampai tuntas untuk
membangun software.
d.Lapisan ke 4 (empat) adalah lapisan perangkat alat bantu atau tools,
didalamnya membahas dengan detail penggunaan tools, untuk
melaksanakan suatuhal dalam metode, misalakan mau menganalisis dipakai
tools untuk analisis, untuk melakukan desain digunakan tools untuk
membantu mempermudah pelaksanaan desain, misalakan dengan CAD
(computer aided design)
Dengan demikian pelaksanaan pengembangan software bila dipandang dari sudut
teknologi maka akan mendapatkan 4 layer tersebut, yang masing masing layer ada
30
tema dan batasan teknis yang menyertainya. Pengembangan teknik ada pada tiap
tiap layer tersebut. Dengan pengertian itu maka akan terjadi perkembangan teknis
yang terstruktur baik.
2.3 Pembahasan pada tataran Framework
Pada tataran framework, proses adalah suatu urutan aktivitas yang ada dalam
framework tersebut. Suatu proses framework akan menjadikan pondasi untuk
melaksanakan proses pengembangan software secara komplet, dengan
mengidentifikasi beberapa framework activity, dapat kita memakainya dalam
seluruh jenis software applikasi, untuk proyek proyek software apapun tampa
memandang besarannya maupun kompleksitasnya. Framework Prosess dalam
pelaksanaan perlu adanya arahan dan perlindungan dari Umbrella Activity/
aktivitas payung yang melindungi aktivitas framework ini agar dapat berjalan
dengan baik.
31
Gambar 2.2 : Framework Prosess Software
2.3.1 Umbrella activity
Umbrella antara lain :
1. Software project tracing and control, memungkinkan software team untuk
assess terhagap kemajuan projek, progress terhadap perencanaannya dan
melakukan sesuatu aksi yang penting untuk memaintain schedule.
2. Risk management
3. Software quality assurance
4. Formal technical review
5. Measurement
6. Softwareconfiguration management,
32
7. Reusability management
8. Work produk preparation dan production.
2.3.2 Framework activity
Adalah aktifitas yang telah didefinisikan, terdiri dari berbagai software
engineering action. Selain itu dalam framework aktiviti akan dapat dipilah dalam
beberapa kumpulan tugas. Setiap tugas ada tugas kerja, hasil produk kerja,
pokok pokok kwalitas yang harus dicapai, dan milestone atau perkiraan kapan
dapat diselesaikan.
Pada gambar 2.2 cukup jelas untuk dijelaskan bahwa didalam framework
activity terdapat kumpulan tugas, yang didalamnya minimal ada tugas, hasil
produk kerja, kwalitas yang diminta, dan kapan akan diselesaikan.
Bentuk framework activity bisa dirubah kedalam diagram gant chart, sehingga
jelas schedule waktunya.
2.4 Proses SE yang diterapkan dalam Proyek software
2.4.1 Proses Generik SE
Yang dimaksud dengan proses Generik adalah framework activity yang
dilakukan sebagai hal yang mesti dilakukan, sehingga dalam pengembangan
software hal ini biasanya tidak tak terlewatkan. Aktivitas ini ada lima hal yaitu
melakukan komunikasi untuk mendapatkan requirement, melakukan
perencanaan, modeling adalah melakukan analisis dan desain yang berarti juga
membuat suatu model yang bisa menggambarkan software tersebut. Keempat
adalah konstruksi atau pemrograman dan juga disebut koding, yang terakhir
adalah deployment, ini meletakkan software pada sistem yang berjalan atau
lingkungan realnya.
a generic process framework for software engineering defines five framework
activities—communication, planning, modeling, construction, and deployment.
In addition, a set of umbrella activities—project tracking and control, risk
33
management, quality assurance, configuration management, technical reviews,
and others—are applied throughout the process.
Bentuk generic ini pada intinya ada lima hal yang harus dikerjakan dalam membuat
software yaitu :
1. Komunikasi, untuk menghasilkan persyaratan, atau kebutuhan dari kenapa
software itu dibuat, ini sering disebut requirement software. Kita lakukan
komunikasi untuk mendapatkan itu dengan jelas, dan tidak ada keraguan
lagi.
2. Perencanaan , atau planning adalah pekerjaan untuk merencanakan
berbagai hal yang berhubungan dengan pelaksanaan pembangunan
software. Lebih detail akan lebih baik, didalamnya tercatat apa saja yang
akan dilakukan, waktunya, resiko yang dihadapi, serta kwalitas yang
diinginkan.
3. Modeling, disini dibahas tentang penggambaran seperti apa software yang
akan dibuaat, baik dengan narasi maupun dengan diagram dan gambar
yang memudahkan kedua pihak yaitu desainer dan pembuat program di
satu sisi serta penerima program atau customer software yang akan
34
menggunkan software itu. Dalam Modeling ini dapat dipilah menjadi model
analisis dan model desain.
4. Konstruksi, adalah pelaksanaan pembuatan kode atau proses
pemrograman. Ini adalah mengejawantahkan atau merealisasikan apa
yang sudah disarankan atau digambarkan dalam modeling.
5. Deployment, penyerahan dan pemasangan software pada lingkungan
pengguna, didalamnya ada instalasi dan training di pengguna, kemudian
darisana diperoleh feedback untuk mendapatkan kekurangan yang ditemui,
memperbaiki secepatnya, serta mengevaluasi software yang barusaja
selesai.
2.4.2 Proses pada Industri yang mature
Untuk membangun software, suatu perusahaan pengembang software,
sebagai industry, selalu berusaha untuk bisa membuat proses pengembangan
software teruji dan berhasil secara nyata, dengan telah berulangkali bisa dapat
dibutikan berhasil maka proses yang digunakan dapat dikatakan telah dewasa
atau mature.
Software engineering institute, telah mendevelop suatu proses yang
komprehensip, berbentuk meta model yang dapat memperlihatkan kapabilitas
atau kemampuan system dan software engineering, oleh organisasi / industry
sehingga organisasi itu mencapai pada level kemampuan proses dari
kapabilitas dan maturity seberapa tinggi.
Perbedaan Level ini digambarkan pada CMMI (The Capability Maturity Model
Integration), yang bisa menggambarkan baik bentuk model yang continue
maupun stage model.
Untuk pembagiannya, hasil level kapabilitas antara lain sebagai berikut:
1. Level 0 : Incomplete. Bila pada proses area ( misal manajeme requirement)
disini belum terbentuk atau belum menemukan goal atau tujuan, objective nya
belum didefinisikan, atau juga bila tujuan yang didefinisikan di CMMI level 1
tidak dapat dipenuhi.
2. Level 1: Performed. Seluruh tujuan spesifik dari proses area, sebagaimanan
didefinisikan oleh CMMI, ada. Work task, memenuhi untuk memproduksi unttuk
sampai terjadinya work produk/ hasil kerja.
35
3. Level 2 : Managed. Seluruh kriteria level 1 terpenuhi, ditambah dengan sudah
adanya kebijakan organisasi yang mendefinisikan dan conform untuk seluruh
kerja yang berhubungan dengan proses area pengembangan; sehingga
seluruh orang bekerja dan mempunyai resources yang cukup untuk
mengerjakan tugasnya. Kemudian seluruh steholder active ikut dalam proses
sebagaimana dibutuhkan, tugas dan hasil produk termonitor dan terkontrol serta
dapat direview, dan juga dapat dievaluasi sebagai tambahan proses.
4. Level 3 : Defined. Bila seluruh kriteria level 2 terpenuhi, dan disini ditambahkan
kriteria bahwa proses dilaksanakan atau diselesaikan oleh organisasi sesuai
dengan guideline cara penyelesaian/ tailoring/ developing yang ada. Dan ini ada
kontribusi terhadap hasil kerja , pengukuran, dan proses improvement yang
lainnya, sehingga informasi ini menjadi asset dalam proses organisasi.
5. Level 4 : Optimized. Bila seluruh kapabilitas level 4 terpenuhi dan ditambah
dengan bisa mengadaptasi dan mengoptimasi proses area dengan
menggunakan pengukuran quantitative / statistical, untuk memenuhi keinginan
customer dan melakukan continuity improvement terhadap proses area yang
menjadi pokok bahasan.
Dengan level tersebut, CMMI yang mendefinisikan untuk setiap proses area.
Maka dengan definisi yang ada di CMMI akan teridentifikasi untuk setiap area
proses dalam suatu organisasi sudah ada dilevel keberapa.
Untuk stage model hasil yang diperoleh adalah lima level maturity, daripada 5
kapability level sebagai tersebut diatas. Adapun hubungan maturity level dan
proses area ada sebagai tabel berikut.
36
Table 2.1 maturity level dan proses area
2.4.3 Keterkaitan Proses dengan pelaksana dan Teknologi yang digunakan
Dari penjelasan diatas kita bisa mengerti bahwa dalam pembuatan software
atau dalam prosess software, suatu perusahaan software menjadi obyek
evaluasi, kemampuan atau capabilitasnya, kemampuan improvemennya, bisa
memenuhi syarat atau tidak.
Untuk mendukung hal itu ada keterkaitan antara proses dan personal atau team
yang mengerjakan sebetulnya, serta teknologi yang dipakainya.
Maka dalam bahasan ini sebenarnya yang ingin dibahas adalah factor
pelaksana dan factor teknologi seperti apa yang dapat meningkatkan
perusahaan memenuhi syarat pengembang yg baik.
Keterkaitan dengan Pelaksana (perorangan atau Team)
37
Sederhananya bahwa proses software yang terbaik adalah proses software
yang bisa dilakukan oleh orang yang mengerjakan dengan efektive, setiap
software engineer akan melakukan dan mengciptakan proses sesuai dengan
kemampuan dia, dan dalam team akan diminta biasanya lebih luas dari apa
yang dia bisa lakukan.
Bahasan keterkaitan pelaksana dengan software proses ini adalah
mengingat pelaksanaan pengerjaan software yang spesifik dapat
dilaksanakan perseorangan maupun dam team, maka dalam bahasan ini
pertama adalah bahwa untuk personal, mau tak mau dalam meningkatkan
kemampuan harus ada edukasi dan training terus menerus, melakukan
seleksi dan evaluasi.
Sedang pada team software, keterkaitan proses dengan team juga akan
sangat erat, pertama seluruh team harus sudah mengenal proses dan proses
area yang menjadi tugasnya, pembagian job dan kemampuan yang sudah
teruji dan teridentifikasi dengan baik. Kemampuan memnuhi jadwal atau
skedul yang telah ditetapkan dengan beban yang sesuai, dan berbagai hal
komunikasi serta penggunaan tools yang sesuai serta dapat terintegrasi.
2.4.4 Keterkaitan Teknologi (OO, Web, tools)
Kita mengenal perkembangan teknologi, step by step teknologi berkembang,
didalamnya ada lompatan lompatan. Dalam hal ini ada pertanyaan tentang
seberapa besar kecepatan perubahan teknologi yang ikut dalam pengembagan
software, seberapa signifikan efek yang mempengaruhinya, dan apa akibat
resultan dari perubahan itu.
Yang menunjang berbagai perkembangan pengembangan software
diantaranya adalah tingginya extreme computation, nano technology, high
bandwidth, ubiquitous network, robotics dan lain lain.
Secara jelas dalam periode akhir ini adalah perkembangan OO (object
Oriented) dan Web demikian mempengaruhi sekali perkembangan kemajuan
software, teknologi software demikian cepat merambah dan dengan demikan
proses demikian terpengaruh dengan teknik yang menuju untuk merealisasikan
OO dan Web tersebut.
38
Keterkaitan proses dengan teknologi diantaranya adalah ‘proses technology
tools’ yang dibuat untuk berbagai segi dalam pengembangan software, baik
untuk membantu dalam mengorganisasi, menganalisis proses yang sedang
dihadapi,mengorganisir tugas kerja, melakukan control dan memonitor
perkembangan, serta memenej qualitas teknis.
Dengan teknologi proses tools bisa juga untuk membuat model secara
otomatis, yang bisa membantu merepresentasikan berbagai hal termasuk suatu
model jaringan, typical workflow, untuk dapat lebih mudah dianalisis, membuat
struktur proses alternative sehingga semuanya itu bisa membuat pekerjaan
lebih murah serta bisa mengurangi waktu pengembangan.
2.4.5 Keterkaitan Proses dengan Produk
Sedang keterkaitan produk dengan proses, untuk pengembangan software,
pada 10 tahun teakhir ini ada sedikit perubahan dimana ‘problem’ yang dihadapi
yang tadinya lebih banyak problem produk, saat ini mulai bergeser pada
‘problem’ proses.
Kita lihat perkembangan keterkaitan dalam proses ini misalkan pertama kita
dulu menggunakan programming language yang terstruktur, ini mempengaruhi
berkembangnya proses menjadi adanya metode structural analisis, yang diikuti
dengan produk data encapsulated, sehingga pelu kita memperbaiki proses
untuk mencapai capabilitas maturity (CMMI), tetapi ini tak berhenti kita
memperbaiki metode dengan object oriented, serta development model dengan
Agile.
Secara aktivitas, orang adalah melakukan proses dan kemudian menghasilkan
produk, ada asimilasi yang cepat dalam pengembangan software misalkan
dengan penggunaan reuse, maka ada penerimaan dualitas antara produk dan
proses seolah menyatu walaupun berbeda, tapi dengan potensial kenaikan
kemudahan maka pikiran reusable meningkat. Proses menjadi suatu creative
proses walau dari end produk masih dapat dilakukan metaphore untuk
membentuk end produk baru lagi.
39
Bab 3 : Proses Model Pembangunan Software
3.1 Pengertian proses model
Pada pengembangan suatu software biasanya melalui suatu proses setahap demi
setahap. Kegiatan yang dikerjakan dalam membuat atau merekayasa software
ada yang spesifik selalu dilakukan, seperti melakukan pencarian data, kebutuhan
atau apa yang ingin dihasilkan dari software yang akan dibuat. Juga kegiatan
analisis dan desain suatu software yang akan dibuat. Pelaksanaan pengetesan
terhadap software yang telah dibuat dan beberpa hal lainnya.
Tahapan yang dilalui ini dalam proses pembuatan software dapat dilakukan dalam
berbagai bentuk. Hasil yang terbentuk mulai dari awal hingga akhir sehingga suatu
software dapat digunakan dengan baik ini adalah yang disebut dengan Proses
Model.
Dengan demikian proses model ini adalah urutan tertentu dalam membangun
software, yang secara nyata atau telah dipraktekkan bisa membentuk software
dengan baik, serta dapat dipertanggung jawabkan bahwa dengan cara tersebut
ada kemungkinan keberhasilan yang nyata.
Proses model dengan demikian adalah cara dasar untuk membangun software.
Merupakan urutan urutan pokok pekerjaan yang diatur sedemikian rupa sehingga
terangkum secara rapi terkoordinasi, dapat membentuk bangunan pembentukan
software yang teruji dan terbukti bisa menghasilkan software sesuai dengan yang
diharapkan sebelumnya.
3.1.1 Jenis Proses Model yang dikenal
Pada saat ini beberapa jenis proses model dikenali dikarenakan persoalan
waktu kapan software itu dibuat, besar dan kecilnya software dibuat, untuk
tujuan atau keperluan apa dia dibuat, serta dibuat pada masa apa dibuat, disini
40
ada pengaruh penggunaan Bahasa pemrograman, sifat kebutuhan dari
penerima software, kecanggiahan software, kompleksitas software, dan
keamanan informasi yang dikandung dalam software tersebut.
Dengan demikian maka jenis proses model yang dikenal dapat dibagi menjadi :
1. Jenis proses model awal
2. Jenis proses model Konservatif
3. Jenis proses model agile
Pembagian itu bermakna bahwa pelaksanaan pembuatan software, pada jenis
proses model awal ini adalah bahwa pada waktu pembuatan software yang
masih terpengaruh Bahasa mesin dan pengembang yang masih sangat
individual, dimana proses modelnya masih belum banyak terdokumenasi,
sehingga tidak mudah untuk dijadikan acuan untuk suatu proses yang bisa
dilaksanakan untuk pengembangan proses selanjutnya.
Sedang pada jenis proses model Konserfatif adalah temuan proses model yang
dikembangkan dalam rangka membuat software pada masa masa dimana
sudah mulai demikan banyak perusahaan perusahaan software bermunculan.
Terjadi kustomisasi, atau banyaknya pesanan dari perusahaan besar untuk
dibuatkan software. Pada masa ini software dibuat dimana software hause lebih
mempunyai keunggulan untuk mempromosikan kemampuannya dan tidak
begitu terpengaruh atas kebutuhan customer.
Jenis proses model konservatif ini mulai dari model waterfalls yang mempunyai
aktivitas kegiatan yang sidah baku diantaranya adalah pencaran kebutuhan,
analisis, perancangan, pengembangan atau koding, testing serta implementasi.
Disana factor waktu pengerjaan agak lebih longgar, lebih difokuskan pada hasil
kwalitas yang sesuai dengan yang diinginkan customer.
Sedang jenis proses model terakhir kali ini adalah proses model yang berusaha
untuk menghasilkan software secepat mungkin, meskipun demikian tetap masih
dapat menjaga kwalitas yang diinginkan. Jenis proses model ini kita kenal
dengan proses model jenis Agile.
41
3.1.2 Prasyarat Proses Model, Kelebihan dan Kelemahan
Prasyarat proses model adalah beberapa hal dalam pembuatan software ini
dimana hasil usaha kita dalam membangun software akhirnya menemukan cara
yang efektiv, dan sukses yang sesuai dengan berbagai hal baik kebutuhan,
kemampuan, kebutuhan bisnis atau tujuan organisasi, dan berbagai lingkungan
yang mempengaruhi kwalitas software itu.
Beberapa identifikasi prasyarat yang memberikan batasan terhadap pembuatan
Proses Model, antara lain :
a. Mudah untuk diimplentasikan
b. Mempunyai kejelasan aktivitas yang dilaksanakan
c. Urutan yang terencana dan mempunyai keteraturan,
d. Proses yang ditunjukkan dapat diulangi dengan hasil yang jelas hasilnya
e. Ada awal dan akhir yang dapat diperkirakan waktunya.
Prasyarat yang denkat dengan pelaksanaan pengembangan suatu software
yang juga menjadi prasyarat suatu proses model adalah:
a. Kemampuan pelaksana, teknologi yang dikuasai
b. Sistem kerjasama dan cara berkomunikasi
c. Pembagian tanggung jawab, job atau tugas, serta aktivitas yang harus
dilaksanakan
d. Perlengkapan dan resources lain yang digunakan
Kapan terjadinya suatu proses model disebut mempunyai kelebihan dan
mempunyai kekurangan, ini perlu ada kejelasan agar kita mengetahui bahwa
proses model itu tidak mensti dikatakan bagus terus. Sebab perkembangan
teknologi, perkembangan tools yang kita gunakan akan mempengaruhi hasil
yang diperoleh, juga proses model ini akan terpengaruh pada berbagai
teknologi dan tools yang digunakan.
Kelebihan suatu proses model akan diperoleh bila proses model itu ternyata
dapat dilakukan berkali kali, dengan berbagai kondisi baik lingkungan maupun
kebutuhan hasil software yang diinginkan, tetap menghasilkan sesuai dengan
kwalitas yang diinginkan.
42
Kelemahan atau kekurangan suatu Proses Model biasanya akan dapat dengan
cepat diperoleh bila ternyata kita menggunakan proses model itu mengalami
kegagalan dalam mendapatkan hasil yang diinginkan. Adapun diperolehnya
kelemahan ini adalah karena berbagai factor yang kita tidak ketahui
sebelumnya, yang tidak disebutkan oleh prasyarat proses model tersebut
sehingga, kita gunakan proses model itu untuk menyelesaikan suatu
pembangunan software ternyata tidak berhasil. Padahal kita telah memenuhi
prasyarat yang ditentukan proses model itu.
3.2 Garis besar bentuk proses Model
Disini secara singkat dikemukakan tentang garis besar bentuk proses model
adalah suatu urutan yang jelas dari pokok-pokok aktivitas yang telah diketahui,
maka dengan urutan proses tertentu akan menghasilkan pengembangan software
yang diinginkan.
Pokok pokok aktivitas ini antara lain adalah :
1. Melakukan komunikasi untuk mendapatkan kebutuhan apa yang diinginkan
2. Melakukan analisa terhadap permasalahan yang dihadapi, sehingga
diperoleh suatu solusi menggunakan teknologi informasi,
3. Melakukan perancangan atu membentuk suatu model yang bisa
dilaksanakan untuk dibangun dengan software
4. Melaksanakan pembangunan software
5. Melaksanakan pengujian atau testing, termasuk melaksanakan evaluasi
terhadap hasil pengembangan atau pembangunan software
6. Melakukan monitoring atas hasil diterapkannya software pada lingkungan
yang adaserta melakukan koreksi untuk perbaikannya.
Dari keenam pokok aktivitas ini Proses model dibentuk dan dilaksanakan.
Terjadinya proses model adalah percampuran dari aktivitas ini dengan para
pekerja yang mempunyai keahlian dibidangnya, melaksanakan dalam arahan
manajeman dan pengorganisasian yang baik sehingga bisa terbentuk suatu hasil
software yang diinginkan.
43
Dengan demikian garis besar bentuk proses model adalah pelaksanaan seluruh
aktivitas pokok tersebut sehingga terbagun software yang diinginkan.
3.2.1 Proses Model Dasar
Disini digambarkan beberapa proses model yang dianggap sebagai proses
model dasar, mengingat proses model itu dibentuk berdasarkan atas bentuk
dasar atau bentuk proses yang dibentuk dari bentuk dasarnya, seperti bentuk
line, spiral, iterative, evolusi dan bentuk dasar lainnya.
Untuk lebih gampangnya disini digambarkan beberapa proses model yang
termasuk sebagai proses model dasar.
3.2.1.1 Waterfalls
Dari bentuk dasar line, atau proses yang berurutan, bisa terbentuk model
waterfalls. Proses model dasar yang berbentuk line, merupakan pelaksanaan
pokok aktivitas yang dilaksanakan secara berurutan sehingga dapat
terbentuk suatu urutan pekerjaan sampai terbentuknya software yang
diinginkan. Gambaran bentuk dasar ‘line’ ini dapat dilihat pada gambar
berikut.
Gambar 3.1 : Proses model dasar , Line
Proses dasar line ini menjadi bentuk dasar dari waterfalls dengan pengertian
bahwa aktivitas pokok yang dilaksanakan, bila sudah selesai kemudian
dilaksanakan ke proses aktivitas pokok selanjutnya, sehingga seperti air
terjun yang memenuhi suatu cekungan, dan jatuh ke cekungan selanjutnya
yang lebih dibawah. Proses ini dapat digambarkan sebagai gambar berikut.
Gambar 3.2 : Bentuk proses model Waterfalls dasar
44
Waterfalls dasar ini dalam perkembangannya bisa dilakukan modifikasi,
dikarenakan dalam pelaksanaan pembuatan software secara realitas tidak
bisa dilakukan demikian, pada kenyataannya kita melakukan dengan adanya
iterasi atau setelah mencapai proses aktivitas pokok lanjutan, ternyata harus
kembali ke proses pokok sebelumnya, sehingga proses itu berputar kembali
ke sebelumnya. Proses waterfalls yang diperbaiki ini kadang masih disebut
sebagai proses modell waterfalls, namun dengan catatan ada proses iterasi.
Gambar 3.3 : Pproses model Waterfalls iterativ
3.2.1.2 Incremental Model
Proses model ini adalah memandang sebuah software yang akan dibuat,
dilakukan pemecahan terlebih dahulu atas bagian bagiannya, kemudian satu
persatu bagian software itu dibuat secara incremental. Yaitu mengerjakan
bagian yang paling awal yang harus dikerjakan, kemudian mengerjakan
bagian software yang lainnya dengan cara yang sama, atau dengan proses
model yang sama misalkan dengan waterfalls.
Pelaksanaan incremental ini dilkerjakan bisa dengan urutan sesuai aktivitas
pokok dan membuat grup kerja sesuai dengan keahliannya, sehingga dapat
dilaksanakan dengan lebih terencana dengan baik. Penggambaran
incremental model ini menjadi sebagai berikut.
Gambar 3.4 : Incremental model
45
Bentuk yang termasuk dalam incremental model ini disebut juga dengan
RAD adalah suatu proses model yang dilakukan dengan incremental,
hasilnya adalah juga pelaksanaan pengembangan software yang dimulai dari
bentuk paling sederhana dari suatu software. Software yang akan dibuat
yang pertama adalah bentuk awal software yang bisa dibuat dengan cepat.
Bagian paling mudah dan sederhana. Katakanlah mulai dari fitur paling
dasar, kemudian dengan selesainya software itu, terbentuk awal software,
bagian lain software, baru akan dibuat pada iterasi selanjutnya, fitur fitur baru
juga ditambahkan pada proses iterasi selanjutnya.
Gambaran proses model dari jenis RAD ini dapat digambarkan sebagai
berikut.
Gambar 3.5 : Proses Model RAD
3.2.1.3 Evolusional
Yang termasuk proses model evolusional ini adalah prototyping, spiral dan
concurrent development model. Kekhususan dari model ini adalah bahwa
pengembangan software dilaksanakan dengan cara perubahan yang sedikit
demi sedikit. Atau disebut sebagai evolusi.
46
Prototyping
Pertama yang dilakukan adalah membuat suatu software yang merupakan
contoh. Contoh atau prototip ini merupakan bentuk dasar dari software yang
ingin dibuat. Prototip ini adalah suatu software yang dapat dipakai sebagai
contoh, gambaran bagi penerima software atau customer yang
menginginkan software untuk dapat melihat lebih jelas sehingga dapat
menjelaskan lebih baik keinginan yang dibutuhkan.
Setiap kali ada penjelasan kebutuhan dari customer, maka proses
pengembangan untuk memenuhi kebutuhan tersebut dilaksanakan sesuai
urutan pokok kegian hingga dikatakan software selesai.
Gambar 3.6 : Proses method Prototyping
Spiral
Proses model spiral termasuk proses model evolusional. Gambaran
pelaksanaan proses model spiral ini digambarkan dalam bentuk gambar
spiral sebagai gambar dibawah.
47
Gambar 3.7 : Proses Model Spiral
Concurrent Development Model
Pada proses model Concurrent development model ini merupakan suatu
pengembangan dari proses model evolusi yang mempunyai kekhususan
pada adanya Concurent, atau lebih dapat disebut dengan saling bersaingan
untuk menyelesaikan suatu proyek pengembangan software.
48
Gambar 3.8 : proses model Concurrent Development Model
3.2.1.4 Model yang spesial
Proses model yang special masih termasuk proses model dasar, dikarenakan
mempunyai hal yang mendasar dalam mengembangkan software. Tetapi
proses model ini termasuk special karena pelaksanaan yang special atau
menggunakan hal hal yang special tersebut.
Sebagai contoh disini ada tiga, yaitu Component base development, Formal
methods, dan Aspect oriented software development.
3.2.2 Proses Model Yang Dikembangkan
Proses model yang dikembangkan akhir akhir ini merupakan hasil berbagai
kreativitas yang masih termasuk membangun proses model, dikarenakan
mempunyai berbagai hal pembaharuan yang mendasar dalam rangka
mengembangkan suatu software.
Perkembangan teknologi, perkembangan lingkungan usaha, perkembangan
49
3.2.2.1 Unified Process
Unified Process (UP) adalah proses development yang menggunakan use-
case-driven, architecture centric, iterative dan incremental; kerangka proses
pembangunan memanfaatkan UMLObject management Group (OMG).
UP muncul sebagai bentuk penyatuan pendekatan rasional,sebagai hasil
pengalaman pelanggan, terutama hasil pengalaman Ivar Jacobson dengan
Ericcson di Swedia. Dimana UP adalah ‘ide’ kerangka proses yang
menyediakan infrastruktur untuk melaksanakan proyek, tetapi tidak semua
rincian. Jadi adalah suatu framework software development process. Suatu
lifecycle model yang terdiri dari context, collaboration, interaction. Atau ada
juga yang membagi menjadi cyclus yang terdiri dari Inception, Elaboration,
Construction, transition.
Gambar 3.9: Unified Process (UP)
Extreem Programing
Gambar 3.10 : XP Extrem Programing
50
FDD
Gambar 3.11 : FDD
Scrum
Gambar 3.12 : Scrum
51
BAB 4 : Pembangunan Software
Software merupakan bentuk bangunan non fisik. Membangun software berarti
membangun hal yang non fisik. Tidak ada fisik yang terbentuk dari sebuah
bangunan software. Namun demikian ada kesatuan Software yang terbentuk
dalam hasil kerja dan usaha membangun software.
Software memang tak dapat berdiri sendiri, dia pasti berhubungan dengan
Hardware, hardware yang bisa ditempati software itu pun selalu ada
persyaratannya. Persyaratan ini untuk menjadikan software bisa sesuai dengan
lingkungan hardware yang tersedia. Hardware yang umum dipakai oleh software
adalah computer. Tetapi masih banyak peralatan lain yang bisa menggunakan
software. Peralatan itu bahkan ada yang langsung memberikan berbagai
kemudahan dan layanan terhadap kita Manusia. Ada di peralatan rumah tangga,
peralatan kendaraan, peralatan khusus, dan berbagai alat bantu.
Membangun software berarti membentuk satu kesatuan sistem, yang mempunyai
ruanglingkup, tujuan tertentu. Maka untuk aktifitas membangun software ini
istilahnya sedikit berubah yaitu pengembangn software, karena dari istilah
software development. Dimana dalam pengembangan software ini sebetulnya
terkait dengan adanya bentuk software sebelumnya, baru membangun sesuatu
yang baru.
Dengan membuat suatu software tertentu, saat ini kita bisa menggunakan salah
satu Bahasa pemrograman. Bahasa pemrograman ini sebetulnya juga software,
yang dapat berhubungan dan berkoneksi sengan hardware yang digunakan,
dengan demikian maka membuat software adalah ber prinsip mengembangkan
software.
4.1 Pengembangan Software secara Praktis
Pengembangan software dapat dilakukan seorang diri atau berkelompok. Pada
pengembangan software secara individual maka kreativitas dan kemampuan
52
individu itu sangat berpengaruh. Sedang pada pengembangan yang diusahakan
dengan berkelompok adalah suatu pengembangan yang diusahakan mengingat
berbagai sebab. Diantranya adalah karena kompleksitasyang tinggi, waktu
penyelesaian yang mendesak, permasalahan dokumentasi, dan persyaratan
software yang harus lengkap, seperti mudah ditelusur kesalahan, bisa diaudit dan
lain sebagainya. Keadaan itu membutuhkan lebih banyak orang, lebih banyak
pemikiran dan lebih banyak spesialisai, maka perlu dilakukan dengan berkelompok
atau termentuknya suatu Tim pengembangan software.
Pengembangan software yang mau tak mau adah pekerjaan perekayasaan atau
engineering. Merupakan pelaksanaan pekerjaan yang sebetulnya harus tertata
rapi sebagai pekerjaan keinsinyuran, dimana ada cara, methode, urutan atau
prosedur. Dan pekerjaan ini mempunyai perhitungan yang teliti, mulai dari awal
seperti perencanaannya, hingga akhir pekerjaan, atau dianggap sudah selesai dan
dapat diterma oleh pengguna.
4.1.1 Pengertian SE secara praktis
Pada software engineering kita kenal framework aktivitas, atau binkai kerja
yang memberikan beberapa batasan atau pemilahan kerja sehubungan
pengembangan software seperti komunikai untuk mendapatkan kebutuhan
untuk apa dan seperti apa software dibuat, melakukan perencanaan, melakukan
analisis dan perancangan, melakukan konstruksi atau pemrograman,
melakukan pengetesan dan melakukan istalasi ke sistem yang berjalan.
Juga adanya Umbrela activity, aktifitas untuk melindungi kegiatan
penegembangan software ini agar terlindung hingga selesai, kegiatan
dipersiapkan tak boleh dilupakan.
Kemudian apa yang dimaksud dengan Cara Praktis untuk hal ini, cara yang
berusaha untuk mengembangkan software dengan maksud sesederhana
mungkin sebagai cara pemecahan problem. Untuk itu sebetulnya untuk ini perlu
pengetahuan yang lebih banyak dari yang biasanya. Dengan ilmu yang sudah
banyak dimiliki dalam membuat software maka akan dapat membuat software
secara praktis.
53
4.1.2 Esensi dari prilaku Praktis
Dalam melaksanakan pengembangan software dengan cara praktis ini,
didalamnya ada esensi dari prilaku praktis, atau yaitu :
1. Mengetahui problem
2. Merencanakan suatu solusi
3. Mencari jalan keluar, membuat solusi
4. Melakukan pengecekan hasil
Untuk konsep itu di perekayasaan software ini antara lain menjadi sebagai
berikut:
1. Dengan komunikasi dan analis diharapkan cepat mengetahui problem
atau masalah yang dihadapi
2. Modeling dan desain software merupakan perencanaan solusi
3. Membuat atau memprogram/koding adalah membentuk jalan keluar,
menghasilkan solusi
4. Testing dan pelaksanaan jaminan Quality yang ditetapkan
Dengan esensi tersebut penetapan pengembangan secara praktis
diarahkan, karena dengan hal tersebut cukup jelas apa yang dilaksanakan.
Cara praktis tetap mempunyai dasar, dan pengetahuan yang lebih detil
tentang yang terbut diatas.
4.2.Prinsip prinsip Kepraktisan
Adanya prinsip prinsip kepraktisan yang ada dalam pengembangan software ini
adalah untuk tetap bisa menjadikan software secara praktis dilaksanakan, bahwa
usulan dasar/prinsip utama pada kerekayasaan software ini menurut David Hooker
menyarankan tujuh hal yaitu :
1. The Reason It All Exist
Kenapa suatu software itu dibutuhkan, ini sebab yang harus ada, hal yang
pasti software harus mempunyai nilaiatau value terhadap penggunanya.
Sebelum menspesifikasikan sistem requirement, seharusnya sudah ada
dikepala,apa nilai yang diperileh user. Sebelum menentukan fungsional
54
suatu hal, ata sebelum menentukan platform hadware, tentukan apa
nilai/value dari software yang akan dibuat. Ini ada dan jelas apa value nya.
2. KISS (Keep It Simple Stupid)
Dalam perkara desain atau rancangan, ada berbagai hal/berbagai bentuk
bisa dimungkinkan. Suatu rancangan software seharusnya diusahakan
semudah, sesimple mungkin, dengan demikian harapannya realisasi
rancangan itu juga akan mudah. Tetapi rancangan ini tak boleh kacau, dia
harus bisa menjelaskan sebaik mungkin, karena rancangan ini harus
memudahkan untuk dimengerti, rancangan harus mudah mengelola sistem.
Pengertian simple disini jauh dari bentuk ‘quick and dirty’, Karen dalam
membangun software ini dalah menggunakan prinsip supaya bisa tetap di
maintain atau dirawat serta bisa dikembangkan dengan kesalahan yang
minimal’
3. Maintain the Vision
Visi yang jelas adalah penting untuk penyelesaian atau suksesnya suatu
proyek software. Integritas konseptual harus dimiliki agar tidak ada dua
pandangan atau dua visi atau lebih. Ini diharapkan sehingga dalam
pelaksanaan kebawah harus terjadi kesinambungan kekompakan, adanya
saling kait mengkait, terbentuknya kesatuan yang saling nyekrup satu sama
lainnya.
Disini harus ada Visi rancangan Arsitektur yang sudah dikomromisasi
keseluruh pelaksana atau stageholder, sehingga dengan adanya ini maka
akan bisa tetap dipegang visinya, dapat ditegakkan apa yang jadi harapan
atau kesetaraan juga complient dari software yang dibuat, serta dapat
memastikan software proyek yang sukses.
4. What You Produce, Other Will Consume
Apa yang anda buat spesifikasi, apa yang anda desain, apa saja yang bisa
anda implementasikan anda ketahui,usahakan orang lain mengerti apa
yang anda usahakan. Dengan demikian nanti apa yang anda usahakan
akan lebih tersebar, dan audian anda akan banyak, ada yang bisa sebagai
pengguna, ada yang bisa sebagai debugger, dan lain sebagainya, sehingga
55
software anda akan sempurna. Membuat menjadi lebih mudah, dan
menambah value terhadap sistem yang dibuat.
5. Be Open to the Future
Membuat sistem atau produk bisa tahan lama pada saat ini sangatlah sulit,
life time produk biasanya terbatas waktunya. Lebih lebih saat ini selalu
terjadi perubahan pada lingkungan Teknologi Informasi, lingkungan
computer berubah terus, spesifikasi platform dan sebagainya. Maka produk
software harus open atau terbuka dan siap untuk bisa berkembang atau
berubah pada waktu yang akan datang. Untuk menjadikan software yang
kita buat lebih sukses, maka harus bisa beradaptasi terhadap masa depan,
siap beradaptasi dan prepare atas semua kemungkinan.
6. Plan Ahead for Reuse
Penggunaan software ‘reuse’ akan sangat mengurangi effort,usaha yang
harus kita keluarkan. Oleh karena itu dalam mengembangkan sistem baru
juga supaya apa yang akan kita kembangkan ini membuat rencana yang
baik sehingga apa yang kita buat mungkin nanti bisa dipergunakan lagi.
Bagian bagian tertentu akan dapat dijadikan sebagai software ‘Reuse’.
Dengan sistem object orientet, hal ini telah sukses banyak dilakukan, untuk
mengembangkan lebih lanjut maka banyak teknik untuk meralisasikan pada
proses pengembangan software, pada level tertentu disetiap level kita perlu
mengenal tekniknya.
7. Think!
Jika anda berpikir tentang sesuatu, dan anda merasa benar, dan
mengerjakannya, dan ternyata benar, maka anda merasa memperoleh
pengetahuan tettang hal itu, maka anda akan mengerjakan dengan cara itu.
Bila anda berpikir itu,kemudian anda lakukan ternyata salah, maka anda
akan mendapatkan pengalaman yang berharga.
Efek samping berfikir adalah belajar untuk membangun atau membentuk
pengetahuan, apa yang anda tidak tahu saat ini.
56
4.3 Pelaksanaan SE secara praktis
Pengembangan software secara praktis dalam pelaksanaannya dapat
dikemukakan sebagai cara pelaksanaan software engineering secara praktis yang
mempunyai urutan proses dan framework dengan bentuk sebagai dalam sistem
pembangunan software dalam menggunakan proses model Waterfall yang dasar,
yang mempunyai komponen Komunikasi, planning, Modeling, Konstruksi dan
Deployment yang dapat dijelaskan sebagai berikut.
4.3.1 Komunikasi
Sebelum kebutuhan customer dapat dilakukan analisis, atau dilakukan
pemodelan, termasuk juga bisa dibentuk spesifikasinya, maka diperlukan untuk
dilakukan komunikasi. Disini komunikasi, mulai dari perihal global gingga
mendetail. Biasanya akan dimulai dari hal yang lebih global atau menyeluruh,
supaya terbentuk gambaran keseluruhan, baru akan meningkat yang lebih
mendetail, terus dilakukan hingga tergambar dengan komunikasi ini semua
yang diinginkan.
Karena biasanya customer datang kepembuat software adalah keinginan agar
dapat dibuatkan software sesuai yang ia bayangkan. Developer seharusnya
merespon sehingga dapat menghasilkan kesimpulan tertentu. Untuk itu
diperlukan komunikasi efektif, komunikasi ini perlu dijalankan dan merupakan
aktifitas menentukan dari software engineering. Komunikasi yang efektif ini
mempunyai konsep dan prinsip sebagai berikut:
1. Dengarkan, focus pada kata kata yang diucapkan, bertanya jika tak jelas
2. Mempersiapkan sebelum melakukan komunikasi, bila perlu riset untuk
memengerti bisnis semacam yang dihadapi
3. Bila perlu ada fasilitator yang dapat memberikan jasanya sehingga
memudahkan komukasi dan aktivitas ini lancar
4. Face to face, atau ketemu muka adalah hal yang paling baik bagi
keduanya. Tetapi ada baiknya juga bila ada informan yang bisa
menunjukan permasalaha atau dokumen yang menjadi permasalahan.
5. Buat catatan dan dokumen tentang decision yang telah dilakukan
6. Tingkatkan bentuk kolaborasi, bentuk kerjasama yang semakin mendalam
57
7. Selalu focus, membentuk modul modul atau kelompok bahasan, sehingga
lebih banyak orang bisa ikut membantu.
8. Bila tidak jelas bisa dibuat gambar. Sehingga bisa menjadikan jelas.
9. Bila jelas, atau tak tetap jelas, bila ada konflik, tetap harus jalan.
Aktivitas Komunkasi ini bertujuan untuk membantu ketemunya Objectiv dan
Goal (tujuan sasaran), obyektive dan tujuan ini tidak sama dengan yang ada di
perencanaan
4.3.2 Planning
Ada banyak filosofi dan konsep perencanaan, yang minimalis, yang lengkap,
ada yang jenis cekatan/agile dan sebagainya. Disisni diletakkan hal yang
penting saja bagaimana sesuatu planning disiapkan. Langkah langkah itu
antara lain :
1. Mengerti pada ruang lingkup yang dihadapi
2. Mengikut sertakan customer dalam planning, sebab customer tau man
yang prioritas mana yang penting.
3. Usahakan perencanaan ini dibuat secara iterative, maksudnya untuk
ddapat disesuaikan terhadap perubahan
4. Estimasi berdasarkan apa yang anda ketahui
5. Memperkirakan resiko sebagaimana dalam mendefinisikan planning ini
6. Lakukan dengan realistis
7. Detail elemen yang diketahui merupakan bahan yang baik untuk
merepresentasikan planning
8. Definisikan bagaimana kamu berniat untuk memastikan qualitasnya
9. Menggambarkan bagaimana niat untuk mengakomodasi perubahan
10. Sering melakukan traking untuk planning dan buat adjustment jika
diperlukan.
Pada cara lain yang juga dapat digunakan untuk cara praktis diantaranya dari
Boehm, yang terkenal dengan W5H2 adalah supaya dapat menyusun hasil
perencanaan dengan pertanyaan :
58
4.3.3 Modeling
Membuat model adalah untuk memperoleh keuntungan dalam pengertian yang
lebih baik dari actual entity yang akan dibuat. Model adalah suatu bentuk kecil
yang diharapkan menjadi bentuk yang sama dari hasil yang direncanakan. Bila
kita membuat model fisik, seperti rumah , gedung, kapal, pesawat, maka dengan
maket dan gambar fisik bisa dibentuk dengan baik dapat dilihat.
Sebaliknya untuk membuat model bagi software, sesuatu yang tak kelihatan,
maka penggambaran memerlukan pemikiran tersendiri. Model arsitektur dan
model fungsi untu memperlihatkan keadaan dan fitur software, juga model
kelakuan sistem dibuat agar bisa tergambar sesuai dengan keinginan user.
Pembuatan model dalam pengembangan software begitu penting, didalamnya
ada dua bentuk model utama, yaitu model analisis yang kedua adalah model
desain atau model rancangan. Model analisi merepresentasikan keinginan user
atau kebutuhan kenapa software akan dibuat. Sedang model desain adalah
merepresentasikan karakteristik agar dapat dibuat oleh paktisi atau
programmer.
Untuk sementara penjelasan lebih detail ada pada bab modeling atau pada
analisis dan desain.
4.3.4 Konstruksi
Kegiatan konstruksi secara lebih detail adalah melakukan coding atau
pemrograman, dan kemudian kegiatan yang disebut testing.
Pada kegiatan coding atau programing ada beberapak mungkinan dapat
dilakukan, yaitu
59
1. Kreasi secara langsung penyusunan program dengan menggunakan
Bahasa progam untuk menghasilkan source program.
2. Pembentukan (generasi) source code secara otomatis melalui suatu
interface yang bisa berbentuk intermediate design, yang dapat
memngambarkan komponen yang akan dibuat
3. Menggunakan otomatik generasi kode yang bisa membuat executable
code menggunakan bahasa pemrograman generasi ke empat.
Sedang pada kegiatan testing adalah kegiatan yang mempunyai aktivitas untuk
melakukan percobaan, melakukan pencarian kesalahan, dan bila ditemukan
untuk dilakukan perbaikan sehingga sesuai dengan ketentuan awal.
Pelaksanaan testing dapat dibagi bagi bisa dalam setiap modul atau code,
setiap obyek yang pernah dibuat, atau untuk menemukan kesalahan yang lebih
luas, misalkan dengan integrasi testing dan validasi testing serta acceptance
tes, atau tes penerimaan.
4.3.5 Deployment
Aktivitas deploymeny terdiri dari tiga biah aktivitas bagian yaitu delivery, support dan
feedback. Maksudnya pelaksanaan deliveri adalah penyampaian terhadap hasil
software yang telah ditest oleh developer untuk diterima dan dipasang atau
diinstalasi ditempat user. Pelaksaannya kemudian oleh user yang disupport oleh
developer. Installasi software ini sebaiknya mempunyai waktu yang sudah ditetapkan
agar dapat bekerja ber sama sama, untuk mulusnya penyerahan, karena disana ada
aseptan test.
Untuk proses model yang cukup modern biasanya evolusion, maka delivery
mdilakukan pertahap. Setiap delivery cycle ada peningkatan, didalamnya ada
penyerahan penggunaan fungsi atau fiture, dimana developer bertanggung jawab
agar user dapat menggunakannya. Mengoperasikan software yang diterimanya
secara benar, dan memang benar sesuai dengan requirement yang telah ditentukan.
Maka setelah delivery ada support agar user melaksanakan sesuai urutan, sesuai
aturan atau prosedur yang diharuskan dalam menggunakan software tersebut.
Selama user mencoba dan mengawali dalam penggunaan, banyak sekali
kemungkinan user akan memberikan feedback yang bermanfaat untuk kedepannya,
60
dan perbaikan software. Feedback user biasanya untuk kemudahan pengerjaan,
untuk reliability dan karakter lain.
Keuntungan feedback ini bagi developer adalah:
1. Untuk dipakai dalam modifikasi atas increment berikutnya,
2. Untuk mendifinisikan perubahan dalam pembuatan perencanaan
incrementselanjutnya,
3. Penting untuk jadi bahan modifikasi desain jika ada change akomomodasi
4. Merevisi perencanaan untuk increment selanjutnya akibat perubahan
Tugas yang ada dalam deployment antara lain:
1. Create delivery media
a. Memasang dan mengetes semua executable file
b. Memasang dan mengetest seluruh data file
c. Mengcreate dan mengetest seluruh dokumentasi user
d. Mengimplementasikan cara trouble shooting
e. Melakukan pengetesan dengan group user yang representatif
2. Establish human support person atau group
a. Buat dokumentasi atau support tools untuk user
b. Membentuk kontak mekanisme
c. Membentuk problem-loging mekanisme
d. Membentuk problem-reporting mekanisme
e. Membentuk problem/error dokumentasi database
3. Establish mekanisme user feedback
a. Definisikan feedback proses
b. Definisikan feedback form
c. Adakan feedback database
d. Definisikan feedbac assesment proses
4. Desiminasi deliveri media kesemua user
5. Conduct on-going support-function
a. Membuat urtan atau asistensi untuk intalasi dan start-up
b. Membuat asistensi untuk trouble shooting
6. Collect user feedback
a. Buat log feedback
b. Buat komunikasi dengan user yang memberi feedback
61
c. Penelitian terhadap feedback
4.4 Pengembangan software Profesional
Pengembangan software secara professional adalah cita cita kita, bahwa
pengembangan software seharusnya mempunyai cara yang dapat
dipertanggungjawabkan hasilnya. Software yang terbentuk itu adalah mempunyai sifat
sifat tertentu yang jelas bahwa software itu dibuat secara profesional. Software yang
dibuat secara professional mempunyai karak teristik yang harus kita kenal untuk kita
bisa membuatnya yang seperti itu.
Sebagai contoh ada orang dapat membuat mobil atau pesawat. Hasil mobil dan
pesawat yang dibuat itu dapat dengan mudah dikatakan hasil yang sekedar bisa jalan
atau bisa terbang, atau hasil kerja yang profesional. Hasil professional lebih dari
sekedar bisa jalan dan bisa terbang, mungkin dia aman waktu dikendarai, mudah
dikontrol dan diatur, dapat dipercaya untuk keselamatannya, mempunyai kekuatan
yang sudah terukur, dan masih banyak sifat lagi yang bisa disebut untuk menunjukkan
bahwa memang mobil dan pesawat tersebut dibuat secara professional.
Untuk suatu software demikian pula. Software hasil produk professional pasti orang
sudah akan dapat mengatakannya walaupun software itu hal yang tak kelihatan, oleh
karena itu marilah kita menyusun karakteristik apa yang seharusnya ada dari hasil
software yang kita buat, untuk menuju ke produk yang professional.
Kenapa produk software itu perlu yang professional, sebab hasil produk software harus
memberikan trust atau kepercayaan bagi user, disamping delivery yang diinginkan
cepat dan tepat waktu, serta heterogenitas dimana software yang dibuat itu diatas
sistem platform atau software yang bermacam macam juga user dapat mengakses dari
berbagai bentuk peralatan yang dia punyai.
Tanggung jawab Profesional lebih luas daripada aplikasi teknikal skill, harus punya
etikal responsibility. Dimana tanggung jawab etik itu lebih dari mengikuti atau patuh
terhadap hukum saja.
Diantara tanggung jawab professional ini adalah:
1. Confidentiality
Harus siap dengan confidentialitas klient maupun pekerja, walau tak ada
perjanjian.
2. Competence
62
Harus bisa mengerti kompetensi seseorang, dan beban kerja yang sesuai
kemampuannya itu
3. Intellectual computer property right
Harus mengerti hukum local dan harus mengikuti penggunaan intellectual
property
4. Computer misuse
Tidak menggunakan pengetahuan tekniknya untuk penggunaan lain misalnya
untuk penyebaran virus dll.
Pengembangan software secara professional belum dijelaskan disini secara mendetail,
mengingat perkembangan yang cepat dari teknik pengembangan yang disesuaikan
dengan keadaan zaman, dimana saat ini terlalu banyak terjadi perubahan dalam
lingkungan, baik itu lingkungan bisnis maupun lingkunagan teknis yang juga
berkembang dengan cepat.
4.5 Pengembangan dalam Sistem Proyek
Software professional akan terbentuk bila memang diusahakan untuk menjadi hasil
dengan sifat yang diharapkan tersebut, adapun jalannya mesti bermacam macam.
Secara khusus kita bisa pilah dalam pengembangan software itu ada dua level yaitu
Manajemen dan level Konstruksi. Salah satu hal yang bisa dijadikan acuan adalah
bahwa software itu dibuat berdasarkan pengembangan dalam sistem proyek. Maka
level manajemen ada manajemen proyek dan planning proyek, manajemen konfigurasi,
quality assurance, training dan instalasi dan lain lagi, sedang pada level konstruksi
terdiri dari requirement atau mendapatkan kebutuannya, analisis, desain,
programming/koding, testing dan lainnya.
Sistem proyek yang dimaksud disini bahwa pembuatan suatu software dimulai dari awal
hingga titik akhir pengembangan yang dianggap selesai. Jadi ada besaran waktu,
usaha, biaya yang dikumpulkan. Software engineering sendiri jadinya mesti ada
komponen 4P, yaitu proyek, people, process, product.
Untuk membangun secara professional kita perlu lebih meng implementasikan pada
level Konstruksi penggunaan Lapisan Teknologi pada metode pembangunan software.
63
Untuk dapat lebih mendetail tentang pengembangan software yang professional ini,
perlu juga diperhatikan akan teknologi yang digunakan, sebab teknologi berkembang
terus, dan dengan teknologi itu akan menghasilkan produk produk yang lebih baik pada
penggunaan yang tepat.
Untuk software penggunaan teknologi dapat dipisah pada 4 level, atau dapat kita
memilahnya menjadi empat lapisan atau layer teknologi.
Yang pertama adalah layer Qualitas, dimana suatu produk software dipandang
Qualitasnya, hasil yang dibuat harus memenuhi qualitas dengan karakteristik seperti
apa. Kemudian ini terpampang atau dapat didetailkan dalam quality assurance
manajemen,
Layer kedua adalah Proses model, merupakan teknik dalam pengembangan software,
yang menapaki atau konsern pada cara urutan yang paling baik dalam menyelesaikan
suatu proyek software. Urutan yang harus dilakukan dalam rangka juga membangun
kerjasama diantara pekerja dan aktivitas yang harus diselesaikan. Pengembangan
software pada layer ini sedikit banyak telah diterangkan pada bab sebelum ini.
Layer ketiga adalah Metode, yang membahas metode atau cara yang harus dilakukan
dari setiap framework-activity dari aktivitas mecari kebutuhan, melakukan analisis,
melakukan desain dan seterusnya, dengan demikian disana banyak bersifat ke teknis
cara penyelesaian. Disini detail melaksanakan aktivitas itu diutarakan. Untuk buku ini
diniatkan membahas hal ini lebih mendetail.
Layer ke empat, lapisan tools, atau alat bantu. Disini dibahas tentang penggunaan
alatbantu, cara melakukan dengan alat bantu, jadi alat bantu untuk melakukan aktivitas
yang ada di layer 4. Untuk itu harus mengetahui dengan alat itu apa yang dapat
dikerjakan, serta mengerti bagaimana menggunakannya. Sebagaimana ada obeng,
ada palu, ada gunting dan sebagainya itu, masing masing mempunyai fungsi dan dalam
penggunaannya perlu mempunyai ketrampilan dalam menggunakannya.
Kesimpulan
Pembangunan software mempunyai suatu urutan proses, yang berasal menurut
pengalaman disusun secara praktis. Penyusunan pembangunan software secara
praktis adalah membuat software dengan cara paling sederhana dengan
pengetahuan dari setiap metode pembangunan yaitu komunikasi atau information
gathering, planning atau perencanaan untuk pembangunan software, Modeling
64
yang merupakan usaha menggambarkan software dengan hasil analisis, dan
desain software yang akan dibuat. Kemudian bagaimana melaksanakan
konstruksi pengembangan software, serta yang ter akhir adalah dengan
menyerahkan dan mendeployment software itu pada penerima atau pemakai
software.
65
Bab 5 : Requirements Engineering
Persyaratan kebutuhan sistem perangkat lunak sering diklasifikasikan sebagai
kebutuhan fungsional atau kebutuhan non-fungsional:
1. Kebutuhan fungsional adalah statemen dari sistem yang harus menyediakan
layanan, bagaimana sistem harus bereaksi terhadap input tertentu, dan
bagaimana sistem harus berperilaku dalam situasi tertentu. Dalam beberapa
kasus, persyaratan fungsional juga secara eksplisit menyatakan apa yang harus
tidak dilakukan sistem.
2. Kebutuhan non-fungsional adalah batasan / kendala pada layanan atau fungsi
yang ditawarkan oleh sistem. Batasan ini termasuk kendala waktu, kendala pada
proses pembangunan, dan kendala yang dikenakan oleh standar yang ada.
Kebutuhan non-fungsional ini berlaku untuk sistem secara keseluruhan, daripada
hanya fitur sistem untuk individual atau jasa tertentu saja.
Gambar 5.1 : Requirement non fungsional
66
5.1 Dokumen Requirement
Dokumen Requirement/Persyaratan/kebutuhan perangkat lunak (spesifikasi
kebutuhan perangkat lunak atau SRS) adalah pernyataan resmi yang harus
diterapkan oleh pengembang sistem. Ini mencakup kebutuhan pengguna untuk
sistem dan spesifikasi rinci dari persyaratan sistem.
Pengguna dan persyaratan sistem, terintegrasi ke dalam satu deskripsi, bisa juga
kebutuhan pengguna didefinisikan dalam persyaratan spesifikasi sistem. Jika ada
banyak persyaratan, maka persyaratan sistem rinci itu dapat disajikan dalam
dokumen yang terpisah.
Dokumen persyaratan yang penting untuk kontraktor luar yang sedang
mengembangkan sistem perangkat lunak memerlukan metode pengembangan
cepat dan tangkas, karena persyaratan berubah begitu cepat, sehingga dokumen
persyaratan bisa kedaluwarsa, daripada seperti yang tertulis.
Daripada dokumen formal, bisa dilakukan cara pendekatan seperti Extreme
Programming (Beck, 1999) mengumpulkan kebutuhan pengguna secara bertahap
dan menulis ini pada kartu sebagai bentuk cerita kepada pengguna. Pengguna
kemudian memprioritaskan persyaratan tertentu untuk pelaksanaan, dalam waktu
berikutnya dari pengembangan sistem.
Untuk sistem bisnis dimana persyaratan sering berubah, pendekatan XP ini adalah
satu yang baik. Selain itu perlu untuk menulis dokumen pendek, untuk pendukung
yang mendefinisikan bisnis dan ketergantungan persyaratan untuk sistem; Hal ini
untuk memudahkan untuk persyaratan yang berlaku bagi sistem secara
keseluruhan, ketika membangun persyaratan fungsional untuk rilis sistem
berikutnya.
Dokumen persyaratan/kebutuhan memiliki beragam rangkaian, mulai dari
manajemen senior, para insinyur yang bertanggung jawab untuk mengembangkan
perangkat lunak. Gambar 5.2, diambil dari Kotonya dan Sommerville, 1998,
menunjukkan kemungkinan pengguna dokumen dan bagaimana mereka
menggunakannya.
67
Gambar 5.2 : Dokumen dan pengguna Requirement
Keragaman pengguna menjadikan dokumen requirement/persyaratan harus
dikompromikan dan dikomunikasikan dengan pelanggan, karena didalamnya
mendefinisikan persyaratan secara terinci agar pengembang dan penguji
terinformasikan, termasuk informasi tentang evolusi sistem. Informasi tentang
perubahan diantisipasi agar dapat membantu desainer sistem menghindari dari
membuat keputusan desain yang ketat, dan insinyur bisa membantu pemeliharaan
sistem yang bisa menyesuaikan sistem dengan persyaratan baru.
68
Tingkat detail yang harus dimasukkan dalam dokumen persyaratan tergantung
pada jenis sistem yang sedang dikembangkan serta proses pembangunan yang
digunakan.
Critical Sistem harus memiliki persyaratan yang lebih rinci, karena kebutuhan
keselamatan dan keamanan harus dianalisis lebih detail. Lebih lebih bila sistem
dikembangkan oleh sebuah perusahaan terpisah (misalnya, melalui outsourcing),
spesifikasi sistem harus benar benar rinci dan tepat. Sedang jika dikerjakan secara
inhouse, proses pembangunan berulang digunakan, dokumen requiremen /
persyaratan bisa dibuat jauh lebih rinci dan setiap ambiguitas dapat dihilangkan
dan diselesaikan selama pengembangan sistem.
Tabel 5.1 menunjukkan satu kemungkinan adanya organisasi untuk melakukan
dokumentasi persyaratan/kebutuhan yang didasarkan pada standar IEEE, (IEEE
1998). Standar ini adalah standar generik yang dapat disesuaikan dengan
penggunaan tertentu. Standar bisa diperluas untuk menyertakan informasi tentang
prediksi yang akan datang dan evolusi sistem. Informasi ini membantu pengelola
sistem dan memungkinkan desainer untuk mendukung fitur sistem di masa
mendatang.
Tentu, informasi yang termasuk dalam dokumen Requiremen/persyaratan
tergantung pada jenis perangkat lunak yang dikembangkan serta cara pendekatan
pembangunan yang digunakan.
Jika pendekatan evolusioner diadopsi untuk produk perangkat lunak, dokumen
persyaratan akan banyak hal rinci, sebagaimana disarankan di atas. Fokusnya ada
pada mendefinisikan kebutuhan pengguna pada level/tingkat tinggi, dan
persyaratan sistem non-fungsional. Kemudian perancang dan programmer dapat
menggunakan penilaian itu untuk memutuskan bagaimana bisa memenuhi
persyaratan yang digariskan pengguna untuk sistem yang akan dibuat.
Ketika perangkat lunak yang merupakan bagian dari proyek sistem besar,
mencakup interaksi hardware dan software, biasanya diperlukan cara untuk
menentukan persyaratan pada tingkat rinci. Ini berarti bahwa dokumen
persyaratan cenderung sangat panjang dan harus mencakup sebagian besar bab
yang ditunjukkan pada table 5.1.
69
Tabel 5.1 : Dokumen Requirement
Gambar 5.3 : Proses requirement engineering
70
5.2 Metode mendapatkan requirement software
Untuk mendapatkan requiremen/persyaratan/kebutuhan suatu software yang akan
dibuat perlu suatu cara atau metode yang mengarahkan kesana. Sebelumnya harus
dimengerti pula bahwa requirement ini adalah sebagai :
1. Jembatan untuk mendesain dan mengkonstruksi
2. Tugas yang ada dalam requirement engineering
3. Mengawali proses requirement engineering
4. Eliciting requirement
Urutan metode ini diantaranya adalah pertama melakukan studi kelayakan awal, tahap
selanjutnya dari proses rekayasa persyaratan adalah persyaratan elisitasi dan analisis.
Dalam kegiatan ini, insinyur perangkat lunak bekerja dengan pelanggan dan sistem
pengguna akhir untuk mencari tahu tentang domain aplikasi, layanan apa sistem harus
menyediakan, kinerja yang diperlukan dari sistem, kendala hardware, dan sebagainya.
Persyaratan elisitasi dan analisis dapat melibatkan berbagai macam orang yang
berbeda dalam sebuah organisasi.
Seorang pemangku kepentingan adalah orang yang memiliki beberapa pengaruh
langsung maupun tidak langsung pada persyaratan sistem. Sedang stakeholder adalah
pemakai akhir yang akan berinteraksi dengan sistem dan orang lain dalam suatu
organisasi yang terpengaruh oleh sistem itu. Stakeholder sistem lainnya adalah insinyur
yang mengembangkan atau mempertahankan sistem lain yang terkait, manajer bisnis,
para ahli, dan perwakilan serikat pekerja.
Dengan demikian para pemangku kepentingan ini akan bersama sama untuk
menentukan requirement software yang akan dibuat.
Kegiatan proses untuk mendapatkan Requirement ini adalah:
a. Penemuan Requirement, ini adalah proses interaksi dengan stakeholder, dari
sistem untuk menemukan kebutuhan mereka. Juga Domain persyaratan dari
para pemangku kepentingan dan dokumentasi yang diperoleh/ditemukan
selama kegiatan ini. Ada beberapa teknik untuk melengkapi cara yang dapat
digunakan untuk penemuan kebutuhan, yang dibahas nanti.
b. Persyaratan klasifikasi dan organisasi, Kegiatan ini adalah mengambil koleksi
persyaratan yang terstruktur, persyaratan kelompok terkait, dan kemudian
71
mengatur mereka ke kelompok yang koheren. Cara yang paling umum dalam
pengelompokan persyaratan adalah dengan menggunakan model arsitektur
sistem, untuk mengidentifikasi sub-sistem dan untuk mengasosiasikan
persyaratan dengan masing-masing sub-sistem. Dalam prakteknya, teknik
mendapatkan persyaratan dan desain arsitektur tidak dapat terpisah.
c. Persyaratan yang prioritas dan yang dinegosiasi. Ketika beberapa pemangku
kepentingan terlibat, akan bisa terjadi konflik. Karena kegiatan ini berkaitan
dengan memprioritaskan kebutuhan, maka untuk mencari dan menyelesaikan
persyaratan, menghindari konflik melalui negosiasi. Biasanya, para pemangku
kepentingan harus bertemu untuk menyelesaikan perbedaan dan menyepakati
persyaratan dengan kompromi.
Gambar 5.4 : proses mendapatkan requirement
5.3 Menggambarkan hasil requirement
Bentuk standar yang digunakan untuk menentukan kebutuhan fungsional,
informasi berikut harus disertakan:
1. Penjelasan fungsi atau badan yang ditentukan.
2. Penjelasan tentang input dan darimana berasal.
3. Penjelasan tentang output dan kemana pergi.
4. Informasi tentang informasi yang dibutuhkan untuk perhitungan, atau hal
lain yang digunakan dalam sistem.
5. Uraian tentang tindakan yang akan diambil.
72
6. Jika pendekatan fungsional digunakan, ada pra-kondisi yang menetapkan
apa yang harus benar sebelum fungsi ini dipanggil, dan pasca-kondisi
menentukan apa yang benar setelah fungsi ini dipanggil.
7. Penjelasan tentang efek samping dari operasi.
Menggunakan spesifikasi terstruktur menghilangkan beberapa masalah yang
ada pada bentuk spesifikasi bahasa alami. Yaitu bahwa Variabilitas dalam
spesifikasi berkurang dan persyaratan yang terorganisasi secara lebih efektif.
Namun kadang sulit untuk menulis persyaratan dalam cara yang jelas dan tidak
ambigu, terutama ketika perhitungan yang kompleks harus ditentukan.
Untuk mengatasi masalah ini, maka dapat ditambahkan informasi untuk
persyaratan bahasa alami, misalnya, dengan menggunakan tabel atau model
grafis dari sistem. Ini dapat menunjukkan bagaimana melanjutkan perhitungan,
bagaimana perubahan sistem state, bagaimana pengguna berinteraksi dengan
sistem, dan bagaimana urutan dari tindakan yang dilakukan.
5.4 Menegosiasi requirement
Sebagaimana telah dijelaskan diatas bahwa pemangku kepentingan karena prioritas
kebutuhan yang berlainan, harus melakukan negosiasi agar requirement yang
disampaikannya dapat diterima. Untuk itu engineer harus benar benar jeli dalam
memengerti kebutuhan tersebut, bisa memberikan gambaran yang jelas akan
penggunaan sistem yang akan dibuat, serta memberi gambaran penerimaan atas
requirement itu walaupun kadang perlu bentuk yang belum tergambar pada pemangku
kepentingan tersebut.
5.5 Memvalidasi requirement
Requirement yang telah didokumentasikan perlu adanya Validasi, berarti ada proses
yang meriview dan kemudian di putuskan oleh yang berwenang dalam suatu pertemuan
bahwa memang telah valid suatu persyaratan yang tertulis padanya.
73
5.6 Menentukan Kwalitas
Pada software penentuan Kualitas tidak dilakukan pada suatu grup tertentu. Disini tidak
ada fase QA. Aktivitas QA adalah aktifitas yang dilakukan melalui proses produksi
software, sehingga dalam menentukan kwalitas dari produk software sedikit berbeda
dengan pelaksanaan di produk fisik. Untuk menentukan kwalitas software ini lihatlah
proses yang dilakukan dan hal hal yang masuk dalam software Quality serta bagaimana
manajemen kwalitas dilakukan, bagaimana menverifikasi dan memvalidasinya.
5.6.1 Software quality
Manajemen mutu perangkat lunak untuk sistem perangkat lunak memiliki tiga
keprihatinan utama:
1. Pada tingkat organisasi, manajemen kualitas yang bersangkutan dengan
membangun kerangka proses organisasi dan standar yang akan
menyebabkan software highquality. Ini berarti bahwa tim manajemen mutu
harus bertanggung jawab untuk menentukan proses pengembangan
perangkat lunak yang akan digunakan dan standar yang harus diterapkan
pada perangkat lunak dan dokumentasi terkait, termasuk persyaratan
sistem, desain, dan kode.
2. Pada tingkat proyek, manajemen mutu melibatkan penerapan proses
kualitas tertentu, memeriksa bahwa proses-proses yang direncanakan telah
diikuti, dan memastikan bahwa output proyek konforman dengan standar
yang berlaku untuk proyek itu.
3. Manajemen mutu di tingkat proyek juga membangun rencana mutu untuk
sebuah proyek. Rencana mutu sebaiknya menetapkan tujuan kualitas
proyek dan menentukan proses apa dan standar apa yang akan digunakan.
Gambar 5.5 Manajemen Mutu
74
Manajemen mutu melakukan pemeriksaan independen atas proses
pengembangan perangkat lunak. Proses manajemen mutu adalah memeriksa
deliverable proyek, dan untuk memastikan bahwa mereka konsisten dengan
standar organisasi dan tujuan. Tim QA harus independen dari tim pengembangan
sehingga mereka dapat mengambil pandangan objektif dari perangkat lunak. Hal
ini memungkinkan mereka untuk melaporkan kualitas perangkat lunak tanpa
dipengaruhi oleh isu-isu yang ada pada pengembangan perangkat lunak.
Idealnya, tim manajemen mutu tidak harus dikaitkan dengan kelompok
pengembangan tertentu, tetapi harus memiliki tanggung jawab organisasi yang
lebih luas untuk menerapkan manajemen mutu. Mereka harus independen dan
mampu melaporkan kepada manajemen tingkat lebih atas. Alasan ini adalah
bahwa manajer proyek harus menjaga anggaran proyek dan jadwal.
Jika masalah muncul, mereka mungkin tergoda untuk berkompromi pada kualitas
produk untuk bisa memenuhi jadwal mereka. Tim manajemen mutu independen
lah yang memastikan bahwa tujuan kualitas tidak terganggu oleh anggaran dan
jadwal pertimbangan jangka pendek. Dalam perusahaan kecil, ini praktis tidak
mungkin. Maka manajemen mutu dan pengembangan perangkat lunak harus pasti
terkait dengan orang yang memiliki tanggung jawab keduanya, pengembangan
dan kualitas.
Perencanaan mutu adalah proses mengembangkan rencana kualitas untuk
sebuah proyek. Rencana mutu sebaiknya menetapkan kualitas software yang
diinginkan dan menggambarkan bagaimana ini harus dinilai. Oleh karena itu
mendefinisikan apa yang dimaksud software 'berkualitas tinggi', adalah
sebenarnya berarti untuk sistem tertentu. Tanpa definisi ini, insinyur dapat
membuat asumsi yang berbeda-beda dan kadang bertentangan, tentang yang
menjadi atribut produk yang mencerminkan karasteristiknya hal paling (paling baik,
paling kuat dst.), untuk menunjukkan pentingnya kualitas. Perencanaan mutu yang
formal merupakan bagian integral dari proses pembangunan yang berbasis
rencana.
Humphrey (1989), dalam buku manajemen software, menunjukkan struktur garis
besar rencana mutu, didalamnya termasuk:
1. Produk pengenalan, Penjelasan mengenai produk, pasar yang
dimaksudkan, dan harapan kualitas untuk produk.
75
2. Produk berencana, Tanggal rilis kritis dan tanggung jawab untuk produk,
rencana untuk distribusi dan pelayanan produk.
3. Proses deskripsi, Proses pengembangan dan proses layanan serta standar
yang harus digunakan untuk pengembangan produk dan pelaksanaan
manajemen yang harus dilakukan.
4. Tujuan Kualitas, Tujuan kualitas dan rencana untuk produk, termasuk
didalamnya identifikasi dan justifikasi atribut kualitas produk yang kritis.
5. Risiko dan manajemen risiko, Risiko utama yang dapat mempengaruhi
kualitas produk dan tindakan yang akan diambil untuk menghadapi risiko
tersebut.
Dasar-dasar manajemen mutu yang ditetapkan oleh manufaktur industry, bisa
men-drive untuk meningkatkan kualitas produk yang sedang dibuat. Sebagai
bagian dari hal ini, maka perlu mengembangkan definisi 'kualitas', yang didasarkan
pada kesesuaian dengan spesifikasi rinci produk (Crosby, 1979) dan konsep
toleransi.
Asumsi yang mendasarinya adalah bahwa produk bisa sepenuhnya ditentukan
dan prosedur dapat menetapkan dan bisa memeriksa sebuah produk manufaktur
terhadap spesifikasinya.
Produk biasanya tidak akan pernah tepat memenuhi spesifikasi, sehingga
toleransi diizinkan. Jika produk itu 'hampir benar', maka bisa digolongkan sebagai
produk yang diterima.
Kualitas perangkat lunak tidak bisa secara langsung sebanding dengan kualitas di
bidang manufaktur. Ide toleransi ini tidak berlaku untuk sistem digital, karena
alasan berikut mustahil untuk sampai pada kesimpulan yang obyektif, apakah
sistem perangkat lunak sudah memenuhi spesifikasinya:
a. Persyaratan/requirement rekayasa, sulit untuk ditulis spesifikasinya secara
lengkap dan jelas. Pengembang perangkat lunak dan pelanggan dapat
menafsirkan persyaratan dalam cara yang berbeda dan kadang mustahil
untuk mencapai kesepakatan pada apakah ya atau tidak software itu sesuai
dengan spesifikasinya.
b. Spesifikasi biasanya mengintegrasikan persyaratan dari beberapa kelas
pemangku kepentingan. Persyaratan ini pasti harus kompromi dan pasti
tidak semua disertakan dalam persyaratan itu, dari semua kelompok
76
pemangku kepentingan. Stakeholder yang dikecualikan, akan menjadi
menganggap sistem sebagai sistem berkualitas buruk, meskipun
menyepakati persyaratan.
c. Tidak mungkin untuk mengukur karakteristik kualitas tertentu (misalnya,
kemampuan pemeliharaan) secara langsung, sehingga mereka tidak dapat
menentukan dengan cara yang jelas, bagaimana membahas kesulitan
pengukuran.
Karena masalah ini, maka penilaian kualitas perangkat lunak adalah proses
subjektif, dimana tim manajemen mutu harus menggunakan penilaian mereka
untuk memutuskan apakah tingkat sudah dapat diterima, dan kualitas telah
dicapai. Tim manajemen mutu harus mempertimbangkan, apakah ya atau tidak
software ini cocok untuk tujuan yang telah ditetapkan.
Ini perlu melibatkan pertanyaan tentang karakteristik sistem. Dan menjawabnya.
Sebagai contoh:
a. Apakah memiliki standar pemrograman dan standar dokumentasi
yang diikuti dalam proses pembangunan?
b. Apakah perangkat lunak telah diuji dengan benar?
c. Apakah perangkat lunak cukup diandalkan untuk mulai digunakan?
d. Apakah kinerja perangkat lunak dapat diterima untuk penggunaan
normal?
e. Apakah perangkat lunak itu yang dapat digunakan?
f. Apakah perangkat lunak tersebut terstruktur dengan baik dan dapat
dimengerti?
Tabel 5.2 : Atribut Kwalitas
Ada asumsi umum dalam manajemen kualitas untuk perangkat lunak, dimana
akhirnya sistem akan diuji terhadap persyaratan.
77
Penghakiman pada apakah sesuai atau tidak ini harus didasarkan pada hasil tes.
Oleh karena itu, tim QA harus meninjau tes yang telah dikembangkan dan
memeriksa catatan tes, memeriksa pengujian yang telah dilakukan apakah sudah
dilakukan dengan benar.
Tim manajemen mutu bertanggung jawab terhadap pengujian sistem, atau sebuah
kelompok pengujian sistem yang terpisah bertanggung jawab untuk ini.
Kualitas subjektif dari perangkat lunak sistem sebagian besar didasarkan pada
karakteristik non-fungsional.
Oleh karena itu kualitas perangkat lunak tidak hanya apakah fungsi telah benar,
tetapi juga tergantung pada atribut sistem non-fungsional.
Boehm, et al. (1978) menyatakan bahwa ada 15 atribut kualitas perangkat lunak
yang penting, Atribut ini berhubungan dengan : ketergantungan, kegunaan,
efisiensi, dan pemeliharaan.
Atribut ketergantungan biasanya adalah atribut kualitas yang paling penting,
kinerja perangkat lunak juga sangat penting. Pengguna akan menolak perangkat
lunak yang terlalu lambat. Untuk sistem apapun perlu dioptimalkan untuk semua
ini atributnya.
Meningkatkan atribut ketahanan kadang dapat menyebabkan hilangnya kinerja. Ini
yang menjadikan adanya kesalahan, maka Rencana mutu karenanya harus
menentukan kualitas yang paling penting, atribut mana untuk yang diperlukan.
Mungkin efisiensi sangat penting maka faktor-faktor lain harus dikorbankan untuk
mencapai hal ini.
Rencana mutu tersebut juga harus mencakup definisi dari proses penilaian
kualitas. Ini harus disepakati untuk menilai apakah ada beberapa atribut yang juga
hadir dalam produk, seperti pemeliharaan atau ketahanan.
Asumsi yang mendasari manajemen kualitas perangkat lunak adalah bahwa
kualitas perangkat lunak secara langsung berhubungan dengan kualitas proses
pengembangan perangkat lunak. Ini berasal dari sistem manufaktur dimana
kualitas produk erat terkait dengan proses produksi.
Sebuah proses manufaktur melibatkan mengkonfigurasi, menyiapkan, dan
mengoperasikan mesin yang terlibat dalam proses. Setelah mesin beroperasi
dengan benar, kualitas produk secara alami mengikuti. Untuk itu mengukur
kualitas produk dan mengubah proses, adalah kerja iterasi sampai diperoleh
tingkat kualitas yang dibutuhkan.
78
Ada hubungan yang jelas antara proses dan kualitas produk di bidang manufaktur
karena prosesnya relatif mudah untuk standarisasi dan untuk dipantau. Setelah
sistem manufaktur dikalibrasi, mereka dapat dijalankan lagi untuk keluaran produk
berkualitas tinggi.
Namun, perangkat lunak tidak diproduksi-dirancang berkali kali hanya satu
macam. Dalam pengembangan perangkat lunak, sekali jadi versi lain berubah lagi,
oleh karena itu hubungan antara kualitas, proses dan kualitas produk lebih
kompleks. Pengembangan perangkat lunak adalah proses kreatif daripada proses
mekanis, sehingga pengaruh keterampilan individu dan pengalaman adalah
signifikan.
Faktor eksternal, seperti kebaruan aplikasi atau tekanan komersial untuk
melepaskan produk awal, juga mempengaruhi kualitas produk, terlepas dari
proses yang digunakan.
Tidak ada keraguan lagi bahwa proses pengembangan yang digunakan memiliki
pengaruh yang signifikan pada kualitas perangkat lunak dan bahwa proses yang
baik, lebih mungkinkan untuk mengarah pada hasil perangkat lunak yang
berkualitas baik.
Gambar 5.6: Standarisasi Perangkat lunak
5.7 Software measurement dan metric
Pengukuran Software berkaitan dengan cara menurunkan nilai numerik atau profil
untuk atribut dari komponen perangkat lunak, sistem, atau proses. Dengan
membandingkan nilai-nilai satu sama lain dan dengan menggunakan standar yang
berlaku di seluruh organisasi. Maka ukuran akan dapat ditemukan.
Misalnya, sebuah organisasi bermaksud untuk memperkenalkan perangkat lunak-
pengujian baru. Sebelum memperkenalkan alat ini, perlu dicatat jumlah cacat
perangkat lunak yang ditemukan dalam waktu yang ditentukan. Ini adalah dasar
79
untuk menilai efektivitas alat. Setelah menggunakan alat untuk beberapa waktu,
dengan mengulangi proses ini, maka jika cacat telah ditemukan dalam jumlah
waktu yang sama, setelah alat telah diperkenalkan, dapat diputuskan bahwa
ukuran dan hasil pengukuran diperoleh, dan ia menunjukkan menyediakan
dukungan yang berguna untuk proses validasi perangkat lunak.
Tujuan jangka panjang dari pengukuran perangkat lunak adalah dengan
menggunakan pengukuran di tempat tinjauan, diperoleh penilaian tentang kualitas
perangkat lunak. Menggunakan pengukuran perangkat lunak, sistem bisa dinilai
dengan menggunakan berbagai metric. Dari pengukuran ini, nilai kualitas sistem
dapat disimpulkan.
Metrik perangkat lunak adalah karakteristik dari sistem perangkat lunak, sistem
dokumentasi, atau proses pembangunan yang dapat diukur secara obyektif.
Contoh metrik yang termasuk ukuran produk adalah baris kode;
Jumlah kesalahan yang dilaporkan dalam produk perangkat lunak yang dikirimkan;
dan jumlah orang-hari yang diperlukan untuk mengembangkan komponen sistem.
Software metrik dapat berupa metrik kontrol atau metrik prediktor. Metrik kontrol
mendukung manajemen proses, dan metrik prediktor membantu memprediksi
karakteristik perangkat lunak. Kontrol metrik biasanya berhubungan dengan
proses perangkat lunak. Contoh kontrol atau proses metrik adalah upaya rata-rata
dan waktu yang dibutuhkan untuk memperbaiki cacat yang dilaporkan.
Metrik prediktor yang berhubungan dengan perangkat lunak itu sendiri dan
kadang-kadang dikenal sebagai 'metrik produk'. Contoh metrik prediktor adalah
kompleksitas cyclomatic dari sebuah modul,
Gambar 5.7 menentukan software metrik
80
Gambar 5.8 : atribut internal dan eksternal
metrik produk
Metrik produk adalah metrik predictor, yang digunakan untuk mengukur atribut internal
sistem perangkat lunak. Contoh metrik produk adalah : ukuran sistem, diukur dalam
baris kode, atau beberapa metode yang terkait dengan setiap objek kelas dalam OO.
Metrik produk terbagi ke dalam dua kelas:
1. metrik dinamis, yang dikumpulkan oleh pengukuran yang dilakukan dari sebuah
program di eksekusi. Metrik ini dapat dikumpulkan selama pengujian sistem atau
setelah sistem telah mulai digunakan. Sebuah contoh mungkin jumlah laporan
bug atau waktu yang dibutuhkan untuk menyelesaikan suatu perhitungan.
2. metrik statis, yang dikumpulkan oleh pengukuran yang dilakukan dari
representasi sistem, seperti desain, program, atau dokumentasi. Contoh metric
statis ini adalah ukuran kode dan panjang rata-rata pengidentifikasi ukuran kode
yang digunakan.
Jenis metrik terkait dengan atribut kualitas berbeda, metrik dinamis membantu untuk
menilai efisiensi dan keandalan program. Sedang metrik statis membantu menilai
kompleksitas, saling pengertian, dan pemeliharaan sistem perangkat lunak atau sistem
komponen.
Biasanya ada hubungan yang jelas antara metrik dinamis dan karasteristik kualitas
perangkat lunak. Hal ini karena cukup mudah untuk mengukur waktu eksekusi yang
81
diperlukan untuk fungsi tertentu dan untuk menilai waktu yang dibutuhkan untuk
memulai sebuah sistem. Semua berhubungan langsung ke efisiensi sistem.
Metrik statis, seperti yang ditunjukkan pada Gambar, memiliki hubungan tidak langsung
dengan atribut kualitas. Sejumlah besar metrik yang berbeda telah diusulkan dan
banyak percobaan telah dicoba untuk menurunkan dan memvalidasi hubungan antara
metrik ini dan atribut seperti kompleksitas sistem dan pemeliharaan. Tetapi tak satu pun
dari percobaan ini telah konklusif, tapi ukuran Program dan kompleksitas kontrol
tampaknya menjadi prediktor paling dapat diandalkan, dimengerti, berhubungan
dengan kompleksitas sistem, dan pemeliharaan.
Tabel 5.3 : deskripsi software metrik
Software component analysis
Analisis komponen perangkat lunak
Proses pengukuran yang mungkin menjadi bagian dari proses penilaian kualitas
perangkat lunak ditunjukkan pada Gambar 24,13. Setiap komponen sistem dapat
dianalisis secara terpisah dengan menggunakan berbagai metrik. Nilai-nilai metrik
82
ini kemudian dapat dibandingkan untuk komponen yang berbeda, dengan data
pengukuran historis yang dikumpulkan pada proyek-proyek sebelumnya.
Pengukuran anomali, yang menyimpang secara signifikan dari norma, mungkin
menyiratkan bahwa ada masalah dengan kualitas komponen ini.
Tabel 5.4 : Deskripsi Object Oriented Metrik
Tahap kunci dalam proses pengukuran komponen ini adalah:
1. Pilih pengukuran harus dibuat pertanyaan terhadap pengukuran yang
dimaksudkan untuk menjawab, maka harus dirumuskan dan pengukuran yang
diperlukan dilakukan untuk menjawab pertanyaan-pertanyaan yang
didefinisikan. Pengukuran yang tidak secara langsung relevan dengan
pertanyaan-pertanyaan ini tidak perlu dikumpulkan. (Basili dan Rombach, 1988),
83
2. Pilih komponen yang akan dinilai, tidak perlu menilai, nilai metrik untuk semua
komponen dalam sistem perangkat lunak. Anda dapat memilih wakil dari
komponen untuk pengukuran, yang memungkinkan untuk membuat penilaian
secara keseluruhan. Bisa suatu saat fokus pada komponen inti dari sistem yang
sedang digunakan. Menilai Kualitas komponen ini lebih penting daripada kualitas
komponen yang jarang digunakan.
3. Mengukur Karakteristik komponen, komponen yang dipilih untuk diukur dan
nilai-nilai metrik terkait dihitung. Ini biasanya melibatkan representasi
pengolahan komponen (desain, kode, dll) dengan menggunakan alat bantu
pengumpulan data otomatis. Alat bantu ini special ditulis atau sudah ada fitur
yang sudah didesain, atau sudah digunakan.
4. Mengidentifikasi pengukuran anomaly, Setelah pengukuran komponen telah
dibuat, kemudian membandingkan mereka satu sama lain, ini dengan
pengukuran sebelumnya yang telah tercatat dalam database pengukuran.
Anomaly adalah harus mencari nilai-nilai yang luar biasa tinggi atau rendah
untuk setiap metrik, karena ini menunjukkan bahwa mungkin ada masalah
dengan komponen yang menunjukkan nilai ini.
5. Analisis komponen anomaly, Ketika telah diidentifikasi komponen yang memiliki
nilai anomali untuk metrik pilihan Anda, Anda harus memeriksa mereka untuk
memutuskan apakah ya atau tidak, adanya nilai metrik anomaly itu, ini berarti
bahwa kualitas komponen dikompromikan. Metrik nilai anomali untuk
kompleksitas tidak selalu berarti komponen berkualitas buruk. Karena ada
beberapa alasan lain untuk nilai tinggi, sehingga mungkin tidak berarti bahwa
ada masalah kualitas komponen.
Gambar 5.9 : Pengukuran Komponen software
Anda harus selalu memelihara data yang dikumpulkan sebagai sumber daya
organisasi dan menyimpannya sebagai catatan sejarah dari semua proyek bahkan
ketika data belum digunakan selama proyek tertentu. Setelah database
pengukuran yang cukup besar telah didirikan, maka dapat dibuat perbandingan
84
kualitas perangkat lunak di seluruh proyek dan memvalidasi hubungan antara
atribut komponen internal dan karakteristik kualitas.
5.8 Review dan inspeksi
Ulasan dan inspeksi adalah kegiatan QA yang memeriksa kualitas deliverable
proyek. Ini melibatkan pemeriksaan perangkat lunak, dokumentasi dan catatan
dari proses untuk menemukan kesalahan dan kelalaian dan untuk melihat apakah
standar kualitas telah diikuti.
Ulasan dan inspeksi yang digunakan bersama program pengujian sebagai bagian
dari proses umum verifikasi dan validasi perangkat lunak.
Selama Review/ulasan, sekelompok orang menguji perangkat lunak dan
dokumentasi yang terkait, mencari potensi masalah dan ketidaksesuaian dengan
standar.
Tim peninjau membuat penilaian informasi tentang tingkat kualitas dari sistem atau
proyek deliverable. Manajer proyek kemudian dapat menggunakan penilaian ini
untuk membuat keputusan, perencanaan dan mengalokasikan sumber daya untuk
proses pembangunan.
Ulasan tentang Quality didasarkan pada dokumen yang telah dihasilkan selama
proses pengembangan perangkat lunak.
Spesifikasi perangkat lunak, desain, atau kode, model proses, rencana uji,
prosedur manajemen konfigurasi, standar proses, dan manual pengguna semua
dapat ditinjau. Tinjauan tersebut harus memeriksa konsistensi dan kelengkapan
dokumen atau kode, yang dikaji dan dipastikan bahwa standar kualitas telah diikuti.
Ulasan tidak hanya tentang memeriksa kesesuaian dengan standar. Tetapi juga
digunakan untuk membantu menemukan masalah dan kelalaian dalam perangkat
lunak atau dokumentasi proyek.
Kesimpulannya bahwa tinjauan harus secara resmi dicatat sebagai bagian dari
proses manajemen mutu. Jika masalah telah ditemukan, komentar pengulas harus
ditulis atau siapa pun yang bertanggung jawab untuk mengoreksi kesalahan atau
kelalaian dicatat.
Tujuan tinjauan dan inspeksi adalah untuk meningkatkan kualitas perangkat lunak,
bukan untuk menilai kinerja dari orang-orang di tim pengembangan. Tinjauan
adalah proses public untuk deteksi kesalahan, maka kesalahan yang dibuat oleh
85
individu yang terungkap ke seluruh tim pemrograman. Untuk memastikan bahwa
semua pengembang terlibat secara konstruktif dengan proses pemeriksaan,
manajer proyek harus sensitif terhadap masalah individual. Mereka harus
mengembangkan budaya kerja yang memberikan dukungan tanpa menyalahkan
ketika kesalahan ditemukan.
Meskipun ulasan yang berkualitas memberikan informasi bagi manajemen tentang
perangkat lunak yang sedang dikembangkan, ulasan kualitas tidak sama seperti
ulasan kemajuan manajemen.
Gambar 5.10 : Review
Proses Review
Meskipun ada banyak variasi dalam rincian tinjauan, proses peninjauan biasanya
terbagi dalam tiga fase:
a. Kegiatan Pra-ulasan, kegiatan ini adalah persiapan yang penting untuk
tinjauan menjadi efektif. Biasanya, kegiatan pra-ulasan behubungan dengan
ulasan perencanaan dan review persiapan. Perencanaan ulasan melibatkan
penyiapan tim review, mengatur waktu dan tempat untuk meninjau, dan
mendistribusikan dokumen-dokumen yang akan diperiksa. Selama
persiapan, tim dapat bertemu untuk mendapatkan gambaran dari perangkat
lunak yang ditinjau. Anggota tim membaca dan memahami perangkat lunak
atau dokumen dan standar yang relevan. Mereka bekerja independen untuk
menemukan kesalahan, kelalaian, dan penyimpangan dari standar. Reviewer
dapat memasok komentar tertulis, jika mereka tidak dapat menghadiri
pertemuan ulasan.
b. Review pertemuan, Selama pertemuan kajian, seorang penulis dari dokumen
atau program yang sedang diulas harus 'bersama sama berjalan melalui'
dokumen dengan tim peninjau. Waktu Review itu sendiri harus relatif pendek,
dua jam paling banyak. Salah satu anggota tim untuk memimpin ulasan dan
yang lain harus secara resmi mencatat semua keputusan dan tindakan
ulasan yang akan diambil. Selama pemeriksaan, ada yang bertanggung
86
jawab untuk memastikan bahwa semua komentar tertulis dianggap. Tinjauan
harus ditandatangani, termasuk catatan komentar dan tindakan yang
disepakati selama pemeriksaan.
c. Kegiatan Pasca ulasan, Setelah pertemuan kajian selesai, isu dan
permasalahan yang muncul selama review harus dibenahi. Ini termasuk
memperbaiki bug, perangkat lunak refactoring, sehingga sesuai dengan
standar kualitas, atau termasuk menulis ulang dokumen. Masalah yang
ditemukan dalam tinjauan kualitas kadang sedemikian rupa sehingga ulasan
manajemen juga diperlukan, ulasan ini untuk memutuskan, misalnya, apakah
lebih banyak sumber daya harus tersedia untuk memperbaikinya.
Tim peninjau biasanya harus memiliki inti terdiri dari tiga sampai empat orang yang
terpilih sebagai kepala pengulas. Salah satu anggota harus menjadi desainer
senior yang akan mengambil tanggung jawab untuk membuat keputusan teknis
yang signifikan. Pokok pengulas dapat mengundang anggota proyek lainnya,
seperti desainer subsistem yang terkait, untuk berkontribusi dalam review. Mereka
mungkin tidak terlibat dalam meninjau seluruh dokumen tetapi harus
berkonsentrasi pada bagian-bagian yang mempengaruhi pekerjaan mereka.
Atau, tim peninjau dapat menyebarkan dokumen dan meminta komentar tertulis
dari spektrum yang luas dari anggota proyek. Manajer proyek tidak perlu terlibat
dalam review, kecuali masalah yang diantisipasi memerlukan perubahan rencana
proyek.
Inspeksi Program
Inspeksi program adalah 'peer review' di mana anggota tim bekerja sama untuk
menemukan bug dalam program yang sedang dikembangkan. Inspeksi dapat
menjadi bagian dari proses verifikasi dan validasi. Mereka merupakan komplemen
pengujian karena mereka tidak memerlukan program yang akan dieksekusi. Ini
berarti bahwa versi lengkap dari sistem dapat diverifikasi dan bahwa representasi
seperti model UML dapat diperiksa.
Gilb dan Graham (1993) menyatakan bahwa salah satu cara yang paling efektif
untuk menggunakan inspeksi adalah untuk meninjau kasus uji untuk sistem.
Pemeriksaan dapat menemukan masalah dengan tes, jadi bisa meningkatkan
efektivitas tes ini dalam mendeteksi bug program.
87
Inspeksi Program melibatkan anggota tim dari berbagai latar belakang yang
melakukan dengan hati-hati, baris demi baris ulasan dari kode sumber program.
Mereka mencari cacat dan masalah dan menggambarkan ini pada pertemuan
inspeksi.
Cacat adalah kesalahan logis, anomali dalam kode menunjukkan kondisi yang
salah atau ada fitur yang telah dihilangkan dari kode. Tim peninjau meneliti model
desain atau kode program secara rinci dan menyoroti anomali dan masalah untuk
perbaikan.
Selama inspeksi, daftar kesalahan pemrograman sering digunakan untuk
memfokuskan pencarian bug. Checklist ini didasarkan pada contoh-contoh dari
buku atau dari pengetahuan cacat yang umum dalam domain aplikasi tertentu.
menggunakan cek-list / daftar periksa yang berbeda untuk bahasa pemrograman
yang berbeda karena setiap bahasa memiliki kesalahan karakteristik sendiri-
sendiri. Humphrey(1989), dalam diskusi komprehensif inspeksi, memberikan
sejumlah contoh daftar periksa inspeksi.
Item dalam checklist bervariasi sesuai dengan bahasa pemrograman karena
berbagai tingkat pemeriksaan yang mungkin pada saat kompilasi. Sebagai contoh,
sebuah compiler Java, cek yang berfungsi memiliki nomor, parameter yang benar;
sedang kompiler C tidak.
Sebagian besar perusahaan yang telah memperkenalkan inspeksi telah
menemukan bahwa mereka sangat efektif dalam menemukan bug. Fagan (1986)
melaporkan bahwa lebih dari 60 persen dari kesalahan dalam sebuah program
dapat dideteksi dengan menggunakan inspeksi program yang informal.
Mills et al.(1987) menunjukkan bahwa pendekatan yang lebih formal untuk
inspeksi, berdasarkan argumen kebenaran, dapat mendeteksi lebih dari 90%
terhadap kesalahan dalam sebuah program.
McConnell (2004) membandingkan unit testing, di mana tingkat deteksi cacat
adalah sekitar 25%, dengan inspeksi, di mana tingkat deteksi cacat adalah 60%.
Dia juga menjelaskan contoh di mana pengenalan peer review menyebabkan
peningkatan 14% dalam produktivitas dan penurunan 90% dalam cacat Program.
Proses tangkas jarang menggunakan inspeksi atau peer review proses formal.
Sebaliknya, mereka bergantung pada anggota tim bekerja sama untuk memeriksa
kode masing-masing, dan pedoman informal seperti 'cek sebelum check-in', yang
menunjukkan bahwa programmer harus memeriksa kode mereka sendiri. Praktisi
88
pemrograman ekstrim berpendapat bahwa pasangan pemrograman adalah
pengganti yang efektif untuk diperiksa karena ini adalah proses pemeriksaan terus-
menerus.
Pair programming mengarah ke pengetahuan yang mendalam tentang program,
karena kedua programmer harus memahami kerjanya secara rinci, kedalaman
pengetahuan itu terkadang sulit dicapai dalam proses pemeriksaan dan yang lain
saat memasangkan kedalam pemrograma
n dapat menemukan bug, ini yang kadang-kadang tidak akan ditemukan dengan
resmi.
Tabel 5.4 : Inspeksi - Chek
Namun, pasangan pemrograman juga dapat menyebabkan saling kesalah
pahaman terhadap persyaratan, di mana kedua anggota pasangan membuat
kesalahan yang sama. Selanjutnya, pasangan mungkin enggan untuk mencari
kesalahan karena pasangan tidak ingin memperlambat kemajuan proyek. Orang-
orang yang terlibat tidak bisa seobjektif tim inspeksi eksternal dan kemampuan
mereka untuk menemukan cacat mungkin dikompromikan oleh hubungan kerja
yang erat.
89
BAB 6 : Pembangunan System Modeling
System modeling adalah bagaimana menunjukkan gambaran system software
sehingga bisa memudahkan komunikasi dalam melakukan desain atau development
suatu sistem software.
Tujuan dari bab ini adalah untuk memperkenalkan beberapa jenis model sistem atau
diagram yang dapat dikembangkan sebagai bagian dari rekayasa persyaratan dan
sistem proses desain. Diharapkan bila telah membaca bab ini, kita akan:
a. Memahami dari gambaran global Arsitektur ke gambaran detail dalam diagram
lebih rinci
b. Memahami bagaimana model grafis yang dapat digunakan untuk mewakili
sistem perangkat lunak;
c. Mengerti mengapa berbagai jenis model yang diperlukan dan perspektif
pemodelan sistem dasar konteks, interaksi, struktur, dan perilaku;
d. Beberapa jenis diagram dalam Unified Modeling Language (UML) diperkenalkan
dan memahami bagaimana diagram tersebut dapat digunakan dalam pemodelan
sistem;
e. Menyadari ide-ide yang mendasari bentuk rekayasa model-driven, di mana
sistem secara otomatis dihasilkan dari model struktural dan perilaku.
Dalam menjelaskan lebih detail tentang modeling dalam perangkat lunak ini diperlukan juga untuk mengenal Context models; Interaction models ; Structural models; Behavioral models; dan Model-driven engineering
6.1 Desain Architectural
Dalam rangka mendesain, ada beberapa step yang harus dilakukan, multistep proses
ini untuk merepresentasikan data dan struktur program, karakteristik interface, dan
detail procedural yang disintesa dari informasi requirement. Adapun langkah awal
adalah membentuk arsitektur desain.
Apakah itu desain arsitektur, Arsitektural desain adalah gambaran struktur data dan
komponen program yang dibutuhkan untuk membangun suatu sistem berbasis
computer.
Dalam sistem yang besar dan komplek maka desain arsitektur ini bisa dipisahkan lagi
antara struktur data menjadi desain database atau desain datawarehouse yang
menjadi dasar Arsitektur data untuk sistem, serta sistem arsitektur yang dibutuhkan
sesuai dengan hasil kerekayasaan sistem, serta analisis requirement.
Desain Arsitektur penting karena bisa menggambarkan dengan lebih menyeluruh,
sehingga secara kesatuan sistem terlihat dengan baik, memberikan gambaran global
90
atau big picture, sehingga kita dapat menentukan bahwa itu benar, tidak salah, tampa
menyebutkan yang detail.
Step yang dilakukan dimulai dari desain data dan proses untuk menurunkan salah satu
atau lebih gambaran struktur arsitektural daripada sistem. bisa pula membentuk suatu
alternative dengan bentuk style atau pattern arsitektural alternative, serta
menganalisanya untuk menjadikan struktur yang terbaik untuk kebutuhan customer
serta sifat sifat atribut bagi kualitasnya. Maksudnya kalau dengan style tertentu atau
mengikuti pattern atau pola tertentu, maka desain itu akan sesuai dengan style dan pola
yang dipilih, tinggal dianalisis sesuai dengang kebutuhan user serta mencukupi dengan
kwalitasnya.
Hasil produk desain arsitektur adalah arsitektur data dan struktur program, untuk detail
dari arsitektur data dan struktur programnya adalah sebagai berikut.
6.1.1 Arsitektur data
Untuk membentuk arsitektur data maka dilaksanakan terlebih dulu desain data,
desain data ini adalah dari translasi obyek data yang telah didefinisikan sebagai
bagian dari model analisis yang bisa dirubah menjadi struktur data pada level
component software.
Jika diperlukan suatu arsitektur database pada layer aplikasi, yang didesain dan di
bangun untuk suatu sistem yang baru.
Data desain pada level arstektur adalah suatu bentuk cara desain yang lebih luas
dari pada yang ada dalam satu aplikasi. Bila suatu perusahaan mempunyai banyak
aplikasi dan juga banyak database, maka ada suatu sistem yang memberikan
kemudahan, atau disini data tidak lagi secara terus menerus berubah sesuai dengan
prinsip database, tetapi suatu data yang membentuk datawarehouse yang
didalamnya terkumpul dari database databse yang ada. Dengan menggunakan cross
fugsional dapat digunakan untuk meng ekstak informasi untuk mendapatkan
informasi yang penting. Proses ini sering disebut dengan data mining. Kemudian
keuntungan dengan penggunaan datawarehouse dan data mining ini bisa dibangun
suatu KDD Knowledge Discovery in Database. Untuk itu maka suatu arsitektur
datawarehouse pelu dibangun.
6.1.2 Struktur Program
Arsitektur dari struktur program adalah suatu bentuk garis besar yang membentuk
gambaran yang menyeluruh dari software yang ingin kita bangun. Bentuk arsitektur
yang dapat kita bangun dapat diperoleh dari tipical yang kita punya dengan di
sejajarkan atau ditepatkan dengan realitas desain yang ada sehingga terbentuk
arsitektur lengkap yang diinginkan. Hal ini bisa juga dengan pola arsitektur tertentu
sebagaimana yang diinginkan.
91
6.1.3 Desain Arsitektur
Style Arsitektur
Dalam rangka desain arsitektur ini kita perlu mengenal beberapa style arsitektur dan
pola arsitektur, untuk style arsitektur yaitu :
a. Arsitektur Data center
Bentuk ini mempunyai kelebihan dalam mengintegrasikan, atau mempunyai
kemampuan integral ability. Komponen yang sudah ada bisa dirubah, bisa
pula menabah komponen. Karena komponen klient relative bebas.
Gambar 6.1 arsitektur data center
b. Arsitektur data flow
Arsitektur tipikal ini mempunyai kekhususan untuk diaplikasikan bila input
data ingin ditransformasikan melalui suatu serial manipulasi data atau
berbagai bentuk komputasi.
Sehingga perlu membangun suatu struktur seperti pipa dan filter, dimana
filter-filter itu tersambung melalui pipa. Bangunan arsitektur dibuat
sedemikian rupa sesuai dengan kebutuhan dan proses yang ingin
dilaksanakan, sehingga terbentuk arsitektur dataflow sebagai hal tersebut.
Jika flow itu hanya satu garis saja, atau serenteng saja, itu disebut sebagai
batch sequensial.
92
Gambar 6.2 : arsitektur Data flow
c. Arsitektur Call and return
Tipikal style arsitektur ini mempunyai kehususan desainer untuk
mendapatkan struktur program yang relative mudah melakukan modifikasi
Dua bentuk substyle yang ada pada tipe ini adalah:
i. Arsitektur main program/sub program: yaitu yang merupakan bentuk
klasik , struktur program yang membagi fungsi dalam control hierarchie.
ii. Arsitektur Remote procedure call. Merupakan arsitekture yang
component program bik main program atau sub program terpisah
dalam berbagai computer.
d. Arsitektur object oriented
Komponen dari sistem selalu di encapsulasi. Yang bisa dimanipulasi seperti
data dan operasi di encapsulated. Komunikasi dan koordinasi diantara
component dilaksanakan dengan ‘message passing’
e. Arsitektur Layer, bentuk arsitektur yang ber lapis lapis .
Arsitektur ini sebagai gambar berikut; program terbagi pada beberapa lapis
tertentu. Dimana lapis paling dekat dengan software sistem operasi adalah
lapisan pertamanya sedang pada lapisan terakhir adalah yang berbubungan
dengan user, atau merupakan interface ke user.
93
Gambar 6.3 : Arsitektur Layering
Arsitektur berdasarkan pola atau patern
Diatas itu adalah arsitektur yang relative menjadi pokok atau bentuk dasar. Untuk
kenyataan dalam pelaksanaan dapat dilakukan suatu penggabungan bentuk
untuk penyesuaian, atau memperbaiki arsitektur sehingga cocok sesuai
kebutuhan.
Desain arsitektur yang mengikuti suatu pola atau pattern suatu arsitektur software
merujuk pada suatu pola tertentu.
Diantara pola yang dikenal adalah :
a. Concurrency
Aplikasi yang dibuat ini mempunyai arsitektur yang bisa menghandel
beberapa tugas secara konkuren, atau bersamasama seolah secara parallel.
Untuk itu bentuk arsitektur akan didesain khusus untuk bisa bekerja parallel.
b. Persistensi
Disini menjadi ada duajenis pola persisten,yaitu persisten yang ada dipola
database , yaitu di pola database management system (DBMS) dan
persisten yang merupakan hasil pola aplikasi yang mempunyai level
persisten yang membangun fitur persistensi pada aplikasi.
c. Distribution.
Komponen yang terdistribusi biasanya memerlukan komunikasi intens,
untuk menangani komunikasi ini mak kemudian diperlukan semacam broker,
untuk itu kemudian pola arsisektur ini menjadi semacam broker arsitektur.
6.1.4 Urutan Desain Arsitektur
Dengan urutan dibawah dapat dipakai untuk melaksanakan desain arsitektur :
94
1) Mendefinisikan tipe dari arsitektur dengan
a) Mendifinisikan Node
Suatu elemen dimana input dan output ada dalam satu
kesatuan
b) Medifinisikan detector
Peralatan sensor atau yang memberikan informasi terhadap
sistem atau target sistem
c) Mendifinisikan indicator
Semua mekanisme untuk indikasi keluaran dari sistem
d) Mendifinisikan controller
Mekanisme yang bisa membolehkan atau tidak melakukan
terhadap suatu node, sehingga apabila terkoneksi dalam
network dapat dilakukan komunikasi dengan yang lainnya.
2) Menggambarkan sistem secara instant, atau high level, kontek system dapat
direpresentasikan, tipe arsitektur terlihat, dan problem domain dapat didefinisikan;
sehingga struktur sistem bisa tergambar jelas nantinya, komponen software utama
atau mayoritas sudah dapat diidentifikasi.
6.2 Design Software
Desain adalah implementasi detail dari hasil arsitektur modeling. Bentuk arsitektur itu
didetailkan hingga bentuk gambarannya akan siap menjadi suatu software. Maka
desain disini masuk dalam modeling yang detail. Kedetilan dari desain ini bila kita
melihat bahwa setelah arsitektur desain yang masih bersifat global menyeluruh, maka
desain selanjutnya mengacu hal yang lebih rinci dan parsial.
Desain kemudian secara pokok dapat dilaksanakan terdiri dari tiga hal yaitu desain
komponen level, desain interface, dan desain untuk data yang aada apda software itu.
Desain adalah modeling, maksudnya bahwa desain itu terbatas untuk memberi arahan,
bentuk model yang akhirnya bisa dilaksanakan oleh programmer atau praktisi secara
tepat. Dengan demikian desain adalah suatu bentuk yang masih akan dihaluskan oleh
programmer disesuaikan dengan berbagai keadaan terutama supaya bisa tetap
menyatu dalam kesatuan sistem.
6.2.1 Desain level komponen
Desain level komponen ini mendefinisikan data struktur,algoritma, karakteristik
interface dan mekanisme komunikasi yang berlokasi di dalam suatu komponen
software, atau suatu modul software atau suatu obyek dalam OO software.
Desain ini untuk bisa menjelaskan atau menjadikan bahwak komponen yang
didesain ini dapat bekerja dan kemudian dapat berhubungan dengan lingkungannya,
sesuai dengan apa yang telah didesain dalam layer desain arsitektur.
95
Secara garis besar urutan kerjanya adalah pertama mendefinisikan atau
membentuk narasi untuk setiap komponen itu, kemudian mentranslasikan pada
desain yang detail dengan penggambaran diagramatik untuk menspesifikasikan data
struktur internal, detail local interface, dan logik prosessing. Misalnya dengan UML
atau bentuk representasi lainnya.
Dengan demikian maka hasil desain ini adalah diagram diagram tersebut yang
digunakan untuk menggambarkan komponen yang akan dibuat. Baik itu tabulasi,
narasi maupun diagram. Adapun bila sudah selesai sebaiknya bisa dilakukan
evaluasi dan pengecekan untuk memastikan benar dan tidaknya desain itu.
Untuk desain level komponen ini pelaksanaaan desain akan berbeda beda
dikarenakan ada 3 konsp yang bisa digunakan yaitu konsep sesuai pandangan
obyek oriented, konsep procedural konvesional, serta ada konsep sesuai pandangan
proses atau disebut proses related view.
6.2.2 Desain interface
Focus desain interface adalah ada 3 hal yaitu desain interface antar komponen
desain interface antar software atau alat yang bukan orang, serta interface dengan
Manusia, berarti interface antara Manusia dan computer.
Bila kita mengkhususkan pada yang ketiga, maka kita membahas interface dengan
Manusia atau yang sering dikenal dengan user interface. Userinterface mempunyai
maksud khusus, diantaranya menciptakan komunikasi yang efektive antara
computer dan Manusia. Hal ini berarti harus diikuti dengan prinsip desain yang baik,
dimana teridentifikasi obyek interface dan aksi, serta layout screen yang bisa dengan
mudah diterjemahkan user.
Interface untuk user ini penting karena persepsi user dengan bekerjanya software
perlu adanya gambaran yang menyatu, sehingga tidak menimbulkan frustasi pada
user.
Langkah langkah desain interface yang dilakukan antara lain adalah :
Identifikasi user, tugas, dan kebutuhan lingkungan;
Membuat user scenario,;
menganalisis untuk mendefinisikan obyek dan aksi dari interface;
Hasilnya adalah bisa dipakai sebagai dasar membuat screen lay out.
Kemudian dibuat :
graphical desain,
penempatan icon,
deskripsi definisi sreen text,title, mayor, minor item, dan sebagainya.
Setelah jadi desain ini, bisa dievaluasi; dengan maksud untuk mendapatkan kwalitas
yang tinggi. Disamping itu saat ini banyak tool/alat bantu yang dapat digunakan untuk
mempercepat pembuatan interface.
96
Theo Mandel dalam medesain interface memberikan 3 golden rule, sebagai dasar
desain interface, yaitu:
a. Tempatkan user dalam control oleh software
b. Kurangi beban memori atau ingatan yang harus di gunakan user
c. Buatlah bentuk interface selalu konsisten.
6.2.3 Desain data
Data desain adalah suatu aktivitas mentranslasi objek data didefinisikan sebagai
bagian dari analisis model untuk membentuk struktur pada komponen level dari
software. Suatu arsitektur database pada level applikasi, bisa juga dibuat untuk
mendesain dan membangun secara spesifik untuk sistem baru.
Konsep data modeling:
Petama suatu data objek untuk merepresentasikan suatu composite informasi yang
harus dimengerti software. Composite disini maksudnya adalah berbeda dengan
atribut atau property. Data objek bisa eksternal entity, sesuatu, kejadian, event
(alarm), suatu jabatan dll.
Dengan demikian data objek dapat direpresentasikan sebagai tabel.
Atribut data sebaliknya didefinisikan sebagai property dari data objek. Atribut suatu
obyek data menggambarkan karakteristiknya dan pada beberapahal menjadi
reference pada obyek lain.
6.3 Sistem modeling
Pemodelan sistem adalah proses pengembangan model abstrak dari suatu sistem,
dengan masing-masing model menyajikan pandangan yang berbeda, atau dengan
perspektif lain terhadap sistem itu. Pemodelan sistem umumnya adalah untuk
mewakili sistem, dengan menggunakan beberapa jenis notasi grafis, yang
sekarang hampir selalu didasarkan pada notasi grafis sesuai dengan Unified
Modeling Language (UML).
Bentuk pemodelan tidak tertutup pada bentuk diatas, bisa juga dengan
mengembangkan bentuk formal (matematika) dari model sistem, ini biasanya
untuk menggambarkan pada sistem spesifikasi rinci.
Model yang digunakan selama proses rekayasa, adalah persyaratan untuk
membantu mempermudah, menurunkan berbagai persyaratan untuk sistem, dan
juga selama proses desain untuk menggambarkan sistem. Bagi pengembang atau
perekayasa/insinyur digunakan untuk menerapkan sistem dan setelah
implementasi untuk mendokumentasikan struktur sistem dan operasinya.
97
Mengembangkan model, ada dua, dari sistem yang ada dan membuat sistem yang
akan dikembangkan:
1. Model sistem yang ada, digunakan sebagai persyaratan selama rekayasa.
Model ini membantu menjelaskan sistem seperti apa, yang ada pada sistem,
apa saja yang tidak dan dapat digunakan sebagai dasar untuk membahas
kekuatan dan kelemahan. Kemudian hasil ini mengarah pada persyaratan
untuk membuat sistem baru.
2. Model sistem baru digunakan selama rekayasa, sebagai persyaratan untuk
membantu menjelaskan persyaratan yang diajukan kepada pemangku
kepentingan sistem lainnya. Perekayasa/Insinyur menggunakan model ini
untuk membahas proposal desain dan mendokumentasikan sistem untuk
implementasi. Dalam proses rekayasa model-driven, bisa memungkinkan
untuk menghasilkan implementasi sistem lengkap atau parsial dari model
sistem.
6.3.1 UML
UML (The Unified Modeling Language) adalah satu set terdiri dari 13 jenis
diagram yang berbeda yang dapat digunakan untuk membuat model sistem
perangkat lunak. Awal diagram itu muncul dari pekerjaan pada 1990-an, pada
pemodelan berorientasi objek.
Sebuah revisi besar menghasilkan UML 2 diselesaikan pada tahun 2004. UML
ini secara universal diterima sebagai pendekatan standar untuk
mengembangkan model sistem perangkat lunak. Beberapa Varian telah
diusulkan untuk pemodelan sistem yang lebih umum lihat --- http:..
//www.SoftwareEngineering-9.com/ web / UML /)
Survey tahun 2007 (Erickson dan Siau, 2007) menunjukkan bahwa sebagian
besar pengguna UML berpikir bahwa ada lima jenis diagram yang dapat
mewakili esensi sistem:
(1) Activity diagram, yang menunjukkan kegiatan yang terlibat dalam proses
atau dalam pengolahan data.
98
(2) Use Case/Gunakan diagram kasus, yang menunjukkan interaksi antara
sistem dan lingkungannya.
(3) Sequence diagram, yang menunjukkan interaksi antara aktor dan sistem
dan antara komponen sistem.
(4) diagram Class, yang menunjukkan kelas objek dalam sistem dan
hubungan antara kelas-kelas ini.
(5) State diagram, yang menunjukkan bagaimana sistem bereaksi terhadap
kejadian internal dan eksternal.
Ketika mengembangkan model sistem, sering diperlukan fleksibilitas dalam
menampilkan cara dan notasi grafis yang digunakan. Ini untuk tidak tetap kaku
dalam menampilkan rincian notasi. Detail dan kekakuan dari model tergantung
pada bagaimana menggunakannya.
Ada tiga cara di mana model grafis yang umum digunakan:
1. Sebagai sarana untuk memfasilitasi diskusi tentang sistem yang ada atau
yang diusulkan.
2. Sebagai cara untuk mendokumentasikan sistem yang ada.
3. Sebagai deskripsi sistem rinci yang dapat digunakan untuk menghasilkan
implementasi sistem.
6.3.2 Context models
Pada tahap awal dalam spesifikasi sistem, kita harus memutuskan batas-batas
sistem. Ini melibatkan kerja dengan para pemangku kepentingan, untuk
memutuskan apa fungsi harus dimasukkan dalam sistem dan apa yang
disediakan oleh lingkungan sistem.
Ada kemungkinan harus memutuskan bahwa bisa membuat dukungan
otomatis untuk beberapa proses bisnis, tetapi ada yang harus dilaksanakan
dengan proses manual, atau memerlukan dukungan oleh sistem lain yang
berbeda.
Juga harus melihat kemungkinan adanya tumpang tindih dalam fungsi, dengan
sistem yang ada, dan harus memutuskan mana fungsi baru harus
dilaksanakan. Keputusan keputusan itu harus dibuat pada awal proses, untuk
99
bisa membatasi biaya pengembangan sistem, dan memperkirakan waktu yang
dibutuhkan untuk memahami persyaratan sistem dan pelaksanaan desain.
Dalam beberapa kasus, batas antara sistem dan lingkungannya relatif jelas.
Sebagai contoh, di mana sistem otomatis menggantikan manual yang ada atau
sistem komputerisasi, lingkungan sistem baru biasanya sama dengan
lingkungan sistem yang sudah ada.
Dalam kasus lain, ada lebih banyak fleksibilitas, dan bisa memutuskan apa
yang merupakan batas antara sistem dan lingkungannya. Sebagai contoh,
dalam mengembangkan spesifikasi untuk sistem informasi pasien. Sistem ini
dimaksudkan untuk mengelola informasi tentang pasien yang datang ke klinik
kesehatan untuk perawatan yang telah ditentukan. Dalam mengembangkan
spesifikasi untuk sistem ini, harus memutuskan apakah sistem harus fokus
secara eksklusif pada pengumpulan informasi tentang konsultasi, atau apakah
harus juga mengumpulkan informasi pribadi pasien.
Keuntungan mengandalkan sistem lain untuk informasi pasien adalah bahwa
kita bisa menghindari duplikasi data. Kerugiannya, bahwa menggunakan
sistem lain bisa membuat lebih lambat dalam mengakses informasi.
6.3.3 Interaction models
Dalam suatu sistem didalamnya melibatkan berbagai interaksi dalam beberapa
jenis. Diantranya adalah interaksi pengguna, yang melibatkan input pengguna
dan output sistem, interaksi antara sistem yang sedang dikembangkan dan
sistem yang ada, atau interaksi antara komponen-komponen sistem lainnya.
Unutk membuat modeling interaksi pengguna sangat penting karena bisa
membantu dalam mengidentifikasi kebutuhan pengguna. Pemodelan sistem
interaksi ini menyoroti masalah komunikasi yang mungkin timbul.
Interaksi komponen pemodelan membantu kita memahami dengan baik, jika
struktur sistem yang diusulkan bisa memberikan kinerja sistem yang diperlukan
dan diandalkan.
Pendekatan yang terkait dengan pemodelan interaksi:
(a) Gunakan Use Case/kasus pemodelan, yang sebagian besar digunakan
untuk model interaksi antara sistem dan aktor eksternal (pengguna atau
sistem lain).
100
(b) Sequence diagram, yang digunakan untuk memodelkan interaksi antara
sistem komponen, meskipun agen eksternal dapat juga dimasukkan.
Use case modeling
Pemodelan use case pada awalnya dikembangkan oleh Jacobson et al.
(1993) pada 1990-an dan dimasukkan ke dalam rilis pertama dari UML
(Rumbaugh et al., 1999). Pemodelan use case secara luas digunakan untuk
mendukung kebutuhan elisitasi, memberikan gambaran dasar. Sebuah use
case dapat diambil atau dimaksud sebagai menggambarkan skenario
sederhana yang bisa menggambarkan apa yang terjadi dan pengguna
mengharapkan dari sistem.
Setiap use case merupakan aktivitas dengan tugas diskrit yang melibatkan
interaksi eksternal dengan sistem. Dalam bentuknya yang paling sederhana,
case/kasus penggunaan ditampilkan sebagai elips, dan actor terlibat dalam
kasus digambarkan sebagai orang
Definisi dari batas sistem dibuat mungkin ditentukan oleh faktor-faktor non-
teknis, jadi bisa hal social, organisasi, dan nilai tertentu. Sebagai contoh,
batas sistem bisa sengaja diposisikan pada hal tertentu, sehingga proses
analisis dilakukan pada semua yang ditentukan itu; sehingga seorang
manajer jelas dan tidak perlu banyak dikonsultasikan;
Setelah beberapa keputusan tentang batas-batas sistem telah dibuat, bagian
dari kegiatan analisis adalah definisikan konteks, dan dependensi yang
sistem telah diketahui dengan lingkungannya. Kegiatan ini akan
menghasilkan model arsitektur sederhana, adalah langkah pertama dalam
kegiatan ini.
Gambar 5.1 adalah model konteks sederhana yang menunjukkan sistem
informasi pasien dan sistem lain dalam lingkungannya. Sistem ini juga
terhubung ke sistem untuk pelaporan manajemen dan alokasi tempat tidur
rumah sakit dan sistem statistik yang mengumpulkan informasi untuk
penelitian. Akhirnya, ada sistem resep untuk menghasilkan resep untuk obat
pasien.
101
Model konteks biasanya menunjukkan lingkungan yang meliputi beberapa
hal yang otomatis dari sistem. Namun tidak menunjukkan tipe hubungan
antar sistem dalam lingkungan dan sistem yang sedang dikembangkan.
Sistem eksternal menghasilkan data untuk sistem, bisa berbagi data dengan
sistem, atau terhubung secara langsung, dengan melalui jaringan. Mereka
mungkin secara fisik terletak dekat atau berada di bangunan terpisah, semua
hubungan ini dapat mempengaruhi persyaratan dan desain sistem yang
didefinisikan, dan ini harus diperhitungkan. Oleh karena itu, model konteks
yang sederhana, digunakan bersama dengan model lainnya, seperti model
proses bisnis. Untuk menggambarkan kontek dan proses kerja manusia dan
proses otomatis dimana sistem perangkat lunak digunakan.
Sequence Diagram
Sequence diagram di UML terutama digunakan untuk model interaksi antara
aktor dan objek dalam suatu sistem dan interaksi antar hal tersebut.
UML Squence diagram ini memiliki sintaks yang kaya untuk diagram urutan,
yang memungkinkan banyak hal yang berbeda jenis interaksinya yang dapat
dimodelkan. Seperti namanya Squence, diagram urutan menunjukkan urutan
interaksi yang berlangsung selama waktu tertentu pada use case.
Gambar 5.6 adalah contoh dari diagram urutan yang menggambarkan dasar-
dasar notasi. Dalam diagram ada interaksi yang terlibat, penggunaan informasi
pasien telihat dalam view, dimana medis Resepsionis dapat melihat beberapa
informasi pasien. Actor dan benda-benda lain yang terlibat, tercantum di
bagian atas diagram, dengan garis ber-titik yang ditarik secara vertikal.
Interaksi antara obyek ditunjukkan dengan panah yang dijelaskan. Persegi
panjang pada garis putus-putus menunjukkan garis hidup objek bersangkutan
(yaitu waktu hidup dari instance objek yang terlibat dalam perhitungan).
Anda harus membaca urutan interaksi dari atas ke bawah. Penjelasan pada
panah menunjukkan panggilan ke objek, parameter mereka, dan nilai-nilai
kembali. Dalam contoh ini, juga ditunjukkan notasi yang digunakan untuk
menunjukkan alternatif.
102
6.3.4 Structural models
Model struktural perangkat lunak, untuk menampilkan organisasi dari suatu
sistem, komponen yang membentuk sistem dan hubungan antar komponen itu.
Model struktural adalah model statis, yang menunjukkan struktur dari desain
sistem, atau model dinamis, yang menunjukkan organisasi dari sistem ketika
melakukan eksekusi.
Membuat model struktural dari suatu sistem, adalah ketika membahas dan
merancang arsitektur sistem. Desain arsitektur merupakan topik yang sangat
penting dalam teknik membangun perangkat lunak. Sedang komponen UML,
paket, dan berbagai diagram, bisa digunakan saat menyajikan model arsitektur.
Pada bagian ini, fokus pada penggunaan diagram kelas untuk memodelkan
struktur statis dari objek kelas dalam sistem software.
Diagram kelas
Diagram kelas digunakan ketika mengembangkan suatu model sistem
berorientasi objek untuk menunjukkan kelas dalam sistem dan hubungan antara
kelas-kelas ini. Sebuah objek kelas dapat dianggap sebagai suatu definisi
umum dari satu jenis objek sistem. Sebuah asosiasi adalah hubungan antara
kelas yang menunjukkan bahwa ada hubungan antara kelas-kelas ini.
Akibatnya, setiap kelas mungkin harus memiliki beberapa hal berhubung
dengan keadaan terkait kelas.
Ketika mengembangkan model pada tahap awal dari proses rekayasa
perangkat lunak, objek merupakan sesuatu di dunia nyata, seperti pasien,
resep, dokter, dll. Sewaktu implementasi dikembangkan, biasanya harus
menentukan objek implementasi tambahan yang digunakan untuk menyediakan
sistem fungsionalitas yang dibutuhkan. Pemodelan benda dunia nyata sebagai
contoh adalah bagian dari persyaratan atau proses desain perangkat lunak
awal.
Diagram kelas dalam UML dapat diungkapkan pada berbagai tingkat detail.
Tahap pertama pengembangan model biasanya untuk melihat dunianya,
mengidentifikasi hal penting, dan mewakilkan ini sebagai kelas.
Cara termudah menulis nama kelas dalam sebuah kotak, mencatat adanya
asosiasi dengan menggambar garis antara kelas. Contoh, Gambar 5.8 adalah
103
diagram kelas sederhana menampilkan dua kelas: Pasien dan Rekam Pasien
dengan hubungan/asosiasi antara mereka.
Pada Gambar 5.8, menggambarkan fitur lebih lanjut dari kelas diagram-
kemampuan untuk menampilkan berapa banyak benda yang terlibat. Dalam
contoh ini, setiap ujung asosiasi dijelaskan dengan 1, yang berarti bahwa ada
1: 1 hubungan antara objek dari kelas-kelas. Artinya, setiap pasien memiliki
tepat satu record dan setiap record mengelola informasi mengenai tepat satu
pasien.
Dengan menggunakan *, seperti yang ditunjukkan pada Gambar 5.9,
menunjukkan jumlah yang tak terbatas yang terlibat.
Pada tingkat detail, diagram kelas terlihat seperti model data semantik.
Semantic Model Data yang digunakan dalam desain database, menunjukkan
entitas data, terkait atribut, dan hubungan antara entitas tersebut. Pendekatan
ini untuk pemodelan adalah pertama kali diusulkan pada pertengahan 1970-an
oleh Chen (1976); beberapa varian telah dikembangkan sejak saat itu (Codd,
1979; Hammer dan McLeod, 1981; Hull dan Raja, 1987), semua dengan bentuk
dasar yang sama.
6.3.5 Behavioral models
Model perilaku adalah suatu model dari perilaku dinamis dari sistem yang
sedang mengeksekusi/berjalan. Model ini menunjukkan apa yang terjadi atau
apa yang seharusnya terjadi ketika sistem merespon stimulus dari
lingkungannya.
Aktivasi rangsangan ini dari dua jenis:
i) Data, data tiba yang harus diproses oleh sistem.
ii) Acara, peristiwa terjadi yang memicu sistem pengolahan. Acara memiliki
keterkaitan dengan data tetapi hal ini tidak selalu terjadi.
Data dikendalikan oleh input data ke sistem, dengan relatif sedikit eksternal
pengolahan acara. Pengolahan mereka melibatkan urutan tindakan pada data
dan generasi terhadap output.
104
Sebagai contoh, sistem penagihan telepon akan menerima informasi tentang
panggilan yang dibuat oleh pelanggan, menghitung biaya panggilan tersebut,
dan menghasilkan tagihan untuk dikirim ke pelanggan tersebut.
Sebaliknya, sistem real-time sering event driven dengan pengolahan data
minimal. Sebagai contoh, darat sistem switching telepon merespon acara-acara
seperti 'receiver lolos' dengan menghasilkan nada panggil, atau menekan
tombol pada handset dengan menangkap nomor telepon, dll
Data-driven modeling
Pemodelan data-driven
Model data-driven menunjukkan urutan tindakan yang terlibat dalam
pengolahan data input dan menghasilkan output yang terkait. Model ini sangat
berguna untuk analisis persyaratan karena dapat digunakan untuk
menunjukkan proses ‘end-to-end’ dalam suatu sistem. Artinya, mereka
menunjukkan seluruh urutan tindakan yang berlangsung dari input yang
diproses sampai dengan output yang merupakan respon sistem.
Model data-driven adalah yang pertama dari bentuk model perangkat lunak
grafis. Pada 1970-an, metode terstruktur seperti DeMarco Structured Analysis
(DeMarco, 1978) memperkenalkan diagram aliran data (DFD) sebagai cara
menggambarkan langkah-langkah pengolahan dalam suatu sistem. Model
aliran data berguna karena pelacakan dan mendokumentasikan bagaimana
data yang terkait dengan proses tertentu bisa bergerak melalui sistem,
sehingga dapat membantu analis dan desainer memahami apa yang sedang
terjadi.
Diagram aliran data sederhana dan intuitif dan biasanya untuk menjelaskan
kepada pengguna, dari gambaran sistem yang potensial, kemudian dapat
berpartisipasi dalam memvalidasi model.
UML tidak mendukung diagram aliran data karena mereka awalnya diusulkan
dan digunakan untuk pengolahan pemodelan data. Dengan alasan ini maka
DFDs fokus pada fungsi sistem dan tidak mengenali obyek sistem. Namun,
karena sistem data-driven begitu umum dalam bisnis, UML 2.0 diperkenalkan
diagram aktivitas/activity diagram, yang mirip dengan diagram aliran data.
105
Sebagai contoh, Gambar 5.14 menunjukkan rantai pengolahan yang terlibat
dalam perangkat lunak pompa insulin. Dalam diagram ini, Anda dapat melihat
langkah-langkah pengolahan (direpresentasikan sebagai kegiatan) dan
mengalir di antara langkah-langkah (direpresentasikan sebagai objek) data.
Cara alternatif untuk menunjukkan urutan pengolahan dalam suatu sistem
adalah dengan menggunakan diagram urutan UML/Squence diagram. Ini
dapat digunakan untuk model interaksi, tetapi ini hanya dikirim dari kiri ke
kanan, maka mereka hanya menunjukkan pengolahan data sekuensial dalam
sistem.
Gambar itu mengilustrasikan menggunakan model urutan pengolahan
pesanan dan mengirimnya ke pemasok. Model urutan menyoroti objek dalam
sistem, sedangkan diagram aliran data menyorot fungsi.
Pemodelan Event-driven
Event modeling untuk menunjukkan bagaimana sistem merespon peristiwa
eksternal dan internal. Hal ini didasarkan pada asumsi bahwa sistem memiliki
jumlah terbatas dari state dan bahwa peristiwa (stimuli) dapat menyebabkan
transisi dari satu keadaan ke keadaan lain. Sebagai contoh, sistem
pengendalian katup dapat bergerak dari keadaan 'Valve terbuka' ke state ‘Valve
ditutup' ketika perintah operator (stimulus) yang diterima. Pandangan dari suatu
sistem sangat cocok untuk sistem real-time. Pemodelan berbasis acara ini
diperkenalkan pada metode desain real-time seperti yang diusulkan oleh Ward
dan Mellor (1985) dan Harel (1987, 1988).
UML mendukung pemodelan berdasarkan aktivitas menggunakan diagram
state, yang didasarkan pada Statecharts (Harel, 1987, 1988). Diagram state
menunjukkan sistem state dan peristiwa yang menyebabkan transisi dari satu
keadaan ke keadaan lain. Mereka tidak menunjukkan aliran data dalam sistem,
tetapi mencakup informasi tambahan mengenai perhitungan yang dilakukan di
masing-masing state.
Dengan contoh perangkat lunak kontrol untuk microwave oven yang sangat
sederhana, untuk menggambarkan model-event. Oven microwave nyata
sebenarnya jauh lebih kompleks, tetapi sistem disederhanakan agar lebih
mudah dipahami. Microwave sederhana ini memiliki saklar untuk memilih,
106
penuh atau setengah, keypad numerik untuk memasukkan waktu memasak,
tombol start / stop, dan layar alfanumerik.
Dengan asumsikan bahwa urutan tindakan dalam menggunakan microwave
adalah:
a. Pilih tingkat daya (baik setengah kekuatan atau kekuasaan penuh).
b. Masukkan waktu memasak menggunakan keypad numerik.
c. Tekan Mulai dan makanan dimasak untuk waktu tertentu.
Untuk alasan keamanan, oven tidak boleh beroperasi ketika pintu terbuka dan,
pada saat penyelesaian memasak, bel dibunyikan. Oven memiliki layar
alfanumerik yang sangat sederhana yang digunakan untuk menampilkan
berbagai peringatan dan pesan peringatan.
Dalam state diagram UML, persegi panjang bulat mewakili state sistem. Panah
berlabel merupakan stimulus yang memaksa transisi dari satu keadaan ke
keadaan lain. Dapat ditunjukkan awal dan akhir state dengan menggunakan
lingkaran penuh, seperti dalam diagram aktivitas. Dari Gambar 5.16, Anda
dapat melihat bahwa sistem dimulai dalam keadaan menunggu dan respon
awalnya untuk baik penuh daya atau tombol setengah-daya.
107
Bab 7 : Testing
Testing atau Pengujian ini dimaksudkan untuk menunjukkan bahwa software
program dapat melakukan apa yang dimaksudkan, aktivitas ini untuk melakukan
dan untuk menemukan cacat dari software Program sebelum digunakan.
Menguji perangkat lunak adalah menjalankan sebuah program dengan
menggunakan data buatan. Kemudian memeriksa hasil uji coba itu untuk melihat
kesalahan, anomali, atau informasi tentang atribut non-fungsional dari program.
Proses pengujian memiliki dua tujuan yang berbeda:
1. Untuk menunjukkan kepada pengembang dan pelanggan bahwa perangkat
lunak memenuhi persyaratan. Untuk perangkat lunak yang dikustom, dibuat
secara mandiri, harus ada setidaknya satu kali tes, pada setiap kebutuhan,
sesuai yang ada dalam dokumen persyaratan. Sedang untuk produk
perangkat lunak generik, harus ada tes untuk semua fitur sistem, ditambah
lagi dengan kombinasi dari fitur fitur itu, terutama yang akan dimasukkan
dalam rilis produk baru.
2. Untuk menemukan situasi di mana perilaku dari software ini ketahuan tidak
benar, tidak diinginkan, atau tidak sesuai dengan spesifikasinya. Hasil
pengujian ini adalah konsekuensi dari adanya cacat perangkat lunak.
Pengujian atas Cacat ini berkaitan dengan menghilangkan perilaku sistem
yang tidak diinginkan, seperti sistem crash, interaksi yang tidak diinginkan
dengan sistem lain, perhitungan yang salah, dan korupsi data, data hilang
dan lainnya.
Gambar 7.1 Proses testing/pengujian software program
108
Testing can only show the presence of errors, not their absence Testing is part of a broader process of software verification and validation (V & V). Verification and validation are not the same thing, although they are often confused.
7.1 Perbedaan Testing, Validasi, Verifikasi dan Inspeksi
Perbedaan diantara hal itu oleh Barry Boehm, diekspresikan dengan pertanyaan: _ ‘Validation: Are we building the right product?’ _ ‘Verification: Are we building the product right?’
Verifikasi dan validasi adalah proses yang berhubungan dengan memeriksa
perangkat lunak yang sedang dikembangkan, apakah memenuhi spesifikasi
dan memberikan fungsi yang diinginkan atau yang diharapkan oleh orang-
orang membayar harga untuk perangkat lunak itu.
Proses-proses pengecekan diatas dimulai segera setelah persyaratan
tersedia, dan semua tahapan proses pembangunan terus dilalui.
Tujuan verifikasi adalah untuk memeriksa bahwa perangkat lunak tersebut
telah memenuhi kebutuhan fungsional dan non-fungsional yang telah
ditetapkan.
Sedang Validasi, adalah proses yang lebih umum, yaitu dengan tujuan untuk
memastikan bahwa perangkat lunak bisa memenuhi harapan pelanggan. Ini
tidak saja hanya memeriksa kesesuaian dengan spesifikasi, tetapi lebih dari
itu, untuk menunjukkan bahwa perangkat lunak dapat melakukan apa yang
pelanggan mengharapkan hal itu bisa dilakukan.
Validasi ini penting karena spesifikasi persyaratan tidak selalu mencerminkan
sistem dan kebutuhan pengguna, keinginan nyata atau kebutuhan
pelanggan.
Tujuan utama dari proses verifikasi dan validasi adalah untuk membangun
keyakinan bahwa sistem perangkat lunak adalah 'sesuai dengan tujuan'.
Ini berarti bahwa sistem harus cukup baik untuk bisa digunakan, mempunyai
tingkat kepercayaan yang diperlukan, disini tergantung pada tujuan sistem,
harapan para pengguna sistem, dan lingkungan pemasaran.
Testing Berhubungan dengan Keadaan pemasaran Saat ini untuk sistem
software:
109
1. Tujuannya Software yang lebih kritis atau yang lebih penting, adalah ke
handal an. Misalnya, tingkat kepercayaan yang diperlukan untuk perangkat
lunak yang digunakan untuk control sistem keamanan- ini jauh lebih tinggi
dari yang dibutuhkan, orang lebih kritis untuk prototipe yang telah
dikembangkan, maka diperlukan untuk menunjukkan ide-ide produk yang
baru.
2. Harapan pengguna relative rendah, karena pengalaman mereka dengan
perangkat lunak, sering software tidak dapat diandalkannya dari segi kualitas,
mengakibatkan mereka tidak terkejut ketika perangkat lunak mereka gagal.
Ketika sistem baru dipasang, pengguna dapat mentolerir kegagalan, tetapi
karena manfaat penggunaan lebih besar, daripada harus dengan biaya
pemulihan kegagalan. ( jika demikian tidak perlu mencurahkan banyak waktu
untuk pengujian perangkat lunak.) Namun, sebagai perangkat lunak yang
sudah mature, pengguna berharap untuk lebih dapat diandalkan sehingga
pengujian lebih menyeluruh dari versi itu mungkin diperlukan.
Dalam lingkungan yang kompetitif, sebuah perusahaan perangkat lunak
dapat memutuskan untuk melepaskan Software program walau belum
sepenuhnya diuji dan di-debugg, karena mereka ingin menjadi yang pertama
ke pasar. Jika sebuah produk software sangat murah, pengguna mungkin
bersedia untuk mentolerir tingkat yang lebih rendah dari kehandalan.
Inspeksi
Pengujian perangkat lunak, proses verifikasi dan validasi mungkin melibatkan
inspeksi perangkat lunak dan hasilnya adalah ulasan inspeksi itu. Inspeksi
dan ulasannya, adalah menganalisa dan memeriksa persyaratan sistem,
model desain, source program (kode sumber program), dan tes sistem.
Inspeksi ini juga disebut teknik 'statis' V & V , di mana kita tidak perlu menjalankan
perangkat lunak untuk memverifikasi hal itu. Inspeksi sebagian besar
berfokus pada kode sumber (source code) dari sistem, tetapi setiap
representasi dibaca tidak saja dari perangkat lunak, tetapi bisa dari dokumen
yang menyertai, seperti persyaratan atau model desain, itu semua dapat
110
diperiksa. Ketika memeriksa sistem, kita perlu menggunakan semua
pengetahuan dari sistem, domain aplikasi, dan bahasa pemrograman,
termasuk pula bahasa pemodelan untuk menemukan kesalahan.
Ada tiga keuntungan dari inspeksi perangkat lunak:
1. Selama pengujian, kesalahan dapat menutupi (hide) kesalahan lainnya.
Ketika kesalahan menyebabkan output yang tak terduga, ini menyebabkan
kita tidak pernah bisa yakin jika anomali keluaran itu adalah karena
kesalahan baru atau efek samping dari kesalahan asli. Karena pemeriksaan
adalah proses statis, maka kita tidak perlu khawatir dengan kesalahan antara
interaksi. Akibatnya, kadang sesi pemeriksaan tunggal dapat menemukan
banyak kesalahan dalam sistem.
2. Versi lengkap dari suatu sistem dapat diperiksa tanpa biaya tambahan. Jika
program tidak lengkap, maka perlu mengembangkan dan memanfaatkan tes
khusus untuk menguji bagian-bagian yang tersedia untuk diuji itu. Ini jelas
menambah biaya pengembangan sistem.
3. Mencari cacat program pada inspeksi dapat juga mempertimbangkan atribut
kualitas yang lebih luas dari sebuah program, seperti kepatuhan terhadap
standar, portabilitas, dan kemudahan perawatan. Dengan inspeksi anda
dapat mencari inefisiensi, algoritma yang tidak pantas, dan gaya
pemrograman yang buruk, dengan demikian bentuk program itu bisa
membuat sistem sulit untuk dipertahankan dan dan diperbarui.
Program Inspeksi adalah ide lama dan telah ada beberapa penelitian dan
percobaan yang telah menunjukkan bahwa inspeksi yang lebih efektif untuk
penemuan cacat dari program pengujian.
7.2 Meyiapkan Testing / Planning terhadap Testing
Perencanaan pengujian berkaitan dengan penjadwalan dan resourcing semua
kegiatan dalam proses pengujian. Perencanaan atau planing ini melibatkan
mendefinisikan proses pengujian, dengan mempertimbangkan orang-orang dan
waktu yang tersedia. Biasanya, rencana uji akan dibuat, yang mendefinisikan apa
yang harus diuji, jadwal pengujian hasil dari prediksi, dan bagaimana hasil tes akan
disimpan. Untuk sistem yang kritis, rencana uji juga dapat mencakup rincian tes
yang akan dijalankan pada perangkat lunak.
111
Gambar 7.2 merupakan urutan model abstrak dari proses pengujian 'tradisional'.
Test case/ Uji kasus adalah spesifikasi dari input ke pengujian, dan juga output
yang diharapkan dari sistem (hasil tes), ditambah pernyataan dari apa yang
sedang diuji.
Uji data/ test data adalah input yang telah dirancang untuk menguji sistem. Uji data
kadang-kadang dapat dihasilkan secara otomatis, tetapi test case/uji kasus tidak
mungkin di generasi secara otomatis. Diperlukan orang yang paham terhadap
sistem yang seharusnya terlibat untuk menentukan hasil tes diharapkan.
Pelaksanaan pengujian dapat dilakukan otomatis. Kemudian hasil secara
otomatis itu dibandingkan dengan hasil prediksi, sehingga tidak perlu bagi
seseorang untuk mencari kesalahan dan anomali dalam uji coba, karena dengan
cepat akan terlihat.
Gambar 7.2 : model pengujian tradisional
Biasanya, sistem perangkat lunak komersial harus melalui tiga tahap pengujian:
1. Development testing / pengujian oleh Pengembangan, di mana sistem ini
diuji didalam pengembangan untuk menemukan bug dan cacat. Perancang
dan programer sistem kemungkinan akan terlibat dalam proses pengujian.
2. Release testing, di mana tim penguji yang terpisah pisah, melakukan tes
versi lengkap terhadap sistem, ini sebelum dilepaskan untuk pengguna.
Tujuan dari pengujian ini adalah untuk memeriksa bahwa sistem telah
memenuhi persyaratan stakeholder dari sistem.
3. User Testing/Pengguna, di mana pengguna atau calon pengguna dari
sebuah sistem menguji sistem di lingkungan mereka sendiri. Untuk produk
perangkat lunak, kadang 'user' mungkin merupakan kelompok internal
marketing yang memutuskan apakah perangkat lunak dapat dipasarkan,
dirilis, dan dijual.
Aceptance testing/ pengujian untuk Penerimaan adalah salah satu jenis
pengujian pengguna di mana pelanggan secara formal menguji sistem untuk
112
memutuskan apakah itu bisa diterima dari pemasok sistem atau jika ada yang
masih kurang atau ada kesalahan maka perlu pengembangan lebih lanjut.
Dalam prakteknya, proses pengujian biasanya melibatkan campuran pengujian
manual dan otomatis. Dalam pengujian manual, tester menjalankan program
dengan beberapa data uji dan membandingkan hasilnya dengan harapan mereka.
Mereka mencatat dan melaporkan perbedaan kepada para pengembang program
tersebut. Dalam pengujian otomatis, tes dikodekan dalam program yang
dijalankan, jadi tes dijalankan setiap kali, pada sistem (yang dikembangkan) yang
akan diuji
7.3 Mengembangkan testing / developing
Pengembangan pengujian mencakup semua kegiatan pengujian yang dilakukan
oleh tim pengembangan sistem. Tester dari software ini biasanya programmer
yang mengembangkan perangkat lunak, yang tidak mengerjakan sistem itu,
meskipun hal ini tidak selalu terjadi.
Untuk sistem kritis, proses yang lebih formal dapat digunakan, dengan kelompok
pengujian terpisah dalam tim pengembangan. Mereka bertanggung jawab untuk
mengembangkan tes dan memelihara catatan detail dari hasil tes.
Selama pengembangan, pengujian dapat dilakukan pada tiga tingkat granularity:
1. Unit Testing, di mana unit program individu atau kelas objek yang diuji. Unit
pengujian harus fokus pada pengujian fungsi obyek atau metode.
2. Componen testing/Komponen pengujian, di mana beberapa unit individu
yang terintegrasi untuk terciptakannya komponen komposit. Pengujian
komponen harus fokus pada pengujian interface komponen.
3. Syatem testing/Pengujian sistem, di mana beberapa atau semua komponen
dalam sebuah sistem yang terintegrasi dan terbentuk suatu sistem, ini diuji
secara keseluruhan. Pengujian sistem harus fokus pada pengujian interaksi
komponen.
Pengembangan pengujian terutama untuk melakukan proses pengujian dalam
rangka mendapatkan cacat, dalam hal ini tujuan pengujian adalah untuk
menemukan bug dalam perangkat lunak. Oleh karena itu biasanya disisipkan
dengan debugging-proses, Dengan menemukan masalah, maka dengan kode dan
mengubah program dapat dilakukan untuk memperbaiki masalah cacat ini.
113
Debug
Debugging adalah proses memperbaiki kesalahan dan masalah yang telah
ditemukan dalam pengujian. Dengan menggunakan informasi dari tes program
debugger, menggunakan pengetahuan mereka tentang bahasa pemrograman dan
hasil yang diinginkan dari tes untuk menemukan dan memperbaiki kesalahan
program.
Proses ini sering didukung oleh alat debugging interaktif yang menyediakan
informasi tambahan tentang pelaksanaan program.
7.4 Testing strategi
Testing strategi adalah road map yang menggambarkan langkah langkah
sebagian dari testing, bila langkah ini untuk dipakai dalam planning suatu testing,
pelaksanaan, berapa waktu, effort, dan sumber daya yang dibutuhkan.
Setiap suatu testing strategi mempunyai planning/perencanaan test, desain test
case, eksekusi testing dan hasil data koleksi testing, serta evaluasinya.
Gambaran strategi testing ini dapat dilihat dari gambar berikut. Bila kita mau
membuat suatu software urutannya adalah mulai dari requirement sistem hingga
pembuatan kode. Ini sesuai dengan putaran yang berlawanan dengan putaran
jarum jam, sebaliknya strategi testing dilaksanakan mulai dari yang kecil atau yang
detail, mengetes kode program yang dibuat baru sampai ke sistem testing. Ini
berarti putaran sesuai dengan arah jarum jam. Mulai unit testing, integrasi testing,
validasi testing, dan kemudian sistem testing.
Gambar 7.3 : Strategi testing
Dalam pelaksanaan testing ini secara terpisah ada suatu cara yang digunakan
untuk pengetesan terhadap programing konvensional software, untuk testing
terhadap object oriented programing dan untuk aplikasi dalam sistem Web.
114
Strategi untuk pengujian WebApp mengadopsi prinsip-prinsip dasar untuk semua
pengujian perangkat lunak dan menerapkan strategi dan taktik yang digunakan
untuk sistem berorientasi objek. Langkah-langkah berikut ini merangkum cara
pendekatan strategi dalam aplikasi sistem Web:
1. Model konten untuk web-app ditinjau untuk mengungkap adanya
kesalahan.
2. Model antarmuka ditinjau untuk memastikan bahwa semua use case dapat
diakomodasi.
3. Model desain untuk WebApp ditinjau untuk mengungkap kesalahan
navigasi.
4. User interface diuji untuk mengungkap kesalahan dalam presentasi dan /
atau mekanik navigasi.
5. Setiap komponen fungsional adalah unit yang diuji.
6. Navigasi seluruh arsitektur diuji.
7. WebApp diimplementasikan dalam berbagai konfigurasi lingkungan yang
berbeda dan diuji untuk kompatibilitas dengan konfigurasi masing-masing.
8. Tes keamanan/security test, dilakukan dalam upaya untuk mengeksploitasi
kerentanan dalam web-app atau dalam lingkungannya.
9. Pengujian kinerja / performance test, dilakukan.
10. WebApp diuji dengan dikendalikan dan dipantau dari pengguna akhir.
Hasil interaksi mereka dengan sistem dievaluasi untuk konten dan navigasi
kesalahan, kekhawatiran kegunaan, kekhawatiran kompatibilitas, dan kehandalan
WebApp serta kinerja.
Karena banyak webapps berkembang terus menerus, maka proses pengujian
adalah kegiatan yang berlangsung terus, biasanya dilakukan oleh staf pendukung
yang menggunakan tes regresi berasal dari tes yang dikembangkan saat webapp
pertama direkayasa.
7.4.1 Unit testing
Pada proses unit testing ini pertama harus melakukan planning, menentukan
modul mana yang akan dilakukan pengetesan, menyiapkaan test case, dimana
setiap testcase disesuaikan, atau dipersiapkan interface, lokaldata struktur,
115
batasan atau boundary condition, independent pat yang akan ditest, serta error
handling yang akan diperoleh.
Mengingat modul berada lingkungan tertentu dalam arsitektur program. Maka
dalam pelaksanaan unit testing ini harus disimulasikan sesuai dengan keadaan
nyata yang ada. Maka modul yang berada diatas modul yang akan kita tes dibuat
semacam control yang sudah jelas proses kerjaanya yang disebut dengan driver,
driver ini akan mengontrol kerja modul yang ditest, serta memberikan pengeluaran
hasil test. Sedang modul dibawah modul yang kita test, kita buat Stub, yang
merupakan beban, atau sesuatu sub program yang bersifat dummy.
Gambar 7.4 : unit testing
Untuk unit testing pada obyek oriented programing, maka pengetesan pada level
unit testing ini dilakukan pada class. Mengingat pada suatu class itu bisa terjadi
superclass dan subclass atau inheritnya, tetapi operasinya sama misalnya X,
perbedaannya hanya pada kontek privat atribut. Maka penanganan unit testing ini
akan mengetes class. Atau menjadi class testing.
Testing untuk OO ini di drive oleh operasi yang ter entcapsulasi, oleh class dan
state behavior dari class. Berbeda dengan konvensional yang bertumpu pada
algoritma detail dari modul, dan data yang mengalir melalui interface modul itu.
Test case/Uji kasus tidak diterapkan pada komponen individu, melainkan untuk
antarmuka komponen komposit, dibuat dengan menggabungkan komponen-
116
komponen ini. Maka kesalahan antarmuka dalam komponen komposit mungkin
tidak terdeteksi. Dengan menguji objek individu, karena kesalahan ini hasil dari
interaksi antara benda-benda di komponen, kesalahan mungkin bisa diketahui.
Ada berbagai jenis antarmuka antara komponen program, maka akibatnya bisa
berbagai jenis kesalahan antarmuka dapat terjadi misalnya:
1. Parameter interface ini adalah antarmuka di mana data atau kadang-
kadang fungsi referensi diwariskan dari satu komponen ke yang lain.
Metode dalam suatu objek memiliki antarmuka parameter.
2. interface Memori bersama, ini adalah antarmuka dimana blok memori
dibagi antara komponen. Data ditempatkan dalam memori dengan satu
subsistem dan diambil dari sana dengan sub-sistem lain. Jenis
antarmuka sering digunakan dalam embedded system, dimana sensor
menghasilkan data yang dikirim serta diambil dan diproses oleh
komponen sistem lainnya.
3. interface prosedural ini adalah antarmuka dimana salah satu komponen
merangkum serangkaian prosedur yang dapat dipanggil oleh komponen
lainnya. Objek dan komponen reusable memiliki bentuk antarmuka
juga.
4. Pesan lewat antarmuka, ini adalah salah satu komponen permintaan
layanan dari komponen lain dengan melewatkan pesan untuk itu lewat
antarmuka. Sebuah pesan kembali untuk mendapatkan hasil
pelaksanaan layanan. Beberapa sistem berorientasi objek memiliki
bentuk antarmuka, seperti halnya sistem client-server.
Kesalahan antarmuka adalah salah satu bentuk yang paling umum dari kesalahan
yang ada dalam sistem yang kompleks (Lutz, 1993).
Kesalahan ini ada dalam tiga kelas:
Interface misuse atau Penyalahgunaan Antarmuka, adalah sebuah komponen
melakukan panggilan beberapa komponen lain dan membuat kesalahan dalam
penggunaan antarmuka. Ini Jenis kesalahan umum dengan parameter antarmuka,
di mana parameter tipe yang salah atau diteruskan dalam urutan yang salah, atau
nomor yang salah dari parameter dapat dilewatkan padanya.
Interface misunderstanding atau Antarmuka kesalahpahaman, adalah sebuah
komponen yang memanggil salah dalam memahami spesifikasi antarmuka,
117
kesalahan yang disebut oleh komponen dan membuat kesalahan asumsi tentang
perilakunya. Hal ini disebut komponen tidak berperilaku seperti yang diharapkan,
yang kemudian menyebabkan perilaku tak terduga dalam komponen panggilan.
Sebagai contoh, metode pencarian biner, dapat disebut dengan parameter array
terurut. Maka kemudian Pencarian kemudian akan menjadi gagal.
Timing error, Kesalahan Timing ini terjadi dalam sistem real-time yang
menggunakan memori bersama atau antarmuka penyampaian pesan. Produser
data dan konsumen data dapat Uji Kasus.
7.4.2 Integrating testing
Integration testing / Pengujian integrasi adalah teknik sistematis untuk
membangun arsitektur perangkat lunak, pada saat yang sama juga melakukan tes
untuk mengungkap kesalahan yang terkait dengan interfacing. Tujuannya adalah
untuk mengambil komponen unit-diuji dan membangun struktur program yang
telah ditentukan oleh desain.
Sering ada kecenderungan untuk mencoba integrasi nonincremental; yaitu, untuk
membangun program menggunakan pendekatan "big bang". Semua komponen
digabungkan terlebih dahulu. Seluruh program diuji secara keseluruhan. Dan
kekacauan hasilnya!, Satu kumpulan kesalahan ditemui. Koreksi jadi sulit karena
isolasi, juga penyebab diperumit oleh hamparan luas dari seluruh program. Setelah
kesalahan ini bisa diperbaiki, yang baru bisa muncul dan proses berlanjut dalam
satu lingkaran yang tampaknya tak berujung. Integrasi Incremental adalah
antitesis dari pendekatan big bang. Program ini dibangun dan diuji sedikit demi
sedikit, di mana kesalahan lebih mudah untuk diisolasi dan benar terlihat; interface
lebih mungkin untuk diuji sepenuhnya; dan pendekatan uji sistematis dapat
diterapkan.
Top-down integration.
Pengujian Integrasi Top-down adalah pendekatan bertahap dari pengujian untuk
jenis pembangunan arsitektur perangkat lunak, dimana Modul diintegrasikan
dengan bergerak ke bawah melalui hirarki control, dimulai dengan modul kontrol
utama (program utama). Modul bawahan (dan akhirnya bawahan) ke modul kontrol
utama digabungkan ke dalam struktur baik secara depth-first atau breadth-first.
118
Mengacu pada Gambar 17.5, integrasi depth-first mengintegrasikan semua
komponen pada jalur kontrol utama dari struktur program. Pemilihan jalur utama
adalah agak sewenang-wenang dan tergantung pada karakteristik khusus aplikasi.
Misalnya, memilih jalur kiri, komponen M1, M2, M5 akan diintegrasikan pertama.
Berikutnya, M8 atau (jika perlu untuk memfungsikan M2) M6 akan diintegrasikan.
Kemudian, jalur kontrol pusat dan kanan dibangun. Integrasi breadth-first
menggabungkan semua komponen bawahan langsung pada setiap tingkat,
bergerak di struktur horizontal.
Dari gambar, komponen M2, M3, dan M4 akan diintegrasikan pertama. Tingkat
kontrol berikutnya, M5, M6, dan sebagainya, berikut. Proses integrasi dilakukan
dalam serangkaian lima langkah:
1. modul kontrol utama digunakan sebagai test driver dan stub yang
menggantikan semua komponen bawahan langsung ke modul kontrol
utama.
2. Tergantung pada pendekatan integrasi yang dipilih (yaitu, kedalaman atau
keluasan pertama), Rintisan bertopik bawahan diganti satu per satu dengan
komponen yang sebenarnya.
3. Pengujian dilakukan karena setiap komponen terintegrasi.
4. Setelah menyelesaikan setiap set tes, rintisan lain diganti dengan
komponen nyata.
5. pengujian regresi (dibahas kemudian dalam bagian ini) dapat dilakukan
untuk memastikan bahwa kesalahan baru belum diperkenalkan.
Strategi top-down terdengar relatif tidak rumit, tetapi dalam prakteknya, masalah
logistik dapat timbul. Yang paling umum dari masalah ini terjadi ketika proses pada
tingkat rendah dalam hirarki diperlukan untuk menguji tingkat atas memadai.
Rintisan mengganti modul tingkat rendah pada awal pengujian top-down; Oleh
karena itu, tidak ada data yang signifikan dapat mengalir ke atas dalam struktur
program. Sebagai tester, Anda yang tersisa dengan tiga pilihan:
(1) menunda banyak tes sampai ada topic, dan diganti dengan modul yang
sebenarnya,
(2) mengembangkan topik yang melakukan fungsi terbatas yang
mensimulasikan modul sebenarnya, atau
(3) mengintegrasikan perangkat lunak dari bagian bawah hirarki ke atas.
119
Bottom-up integration.
Bottom-up integration testing, atau Pengujian integrasi bottom-up, seperti
namanya, mulai konstruksi dan pengujian dengan modul atom (yaitu, komponen
pada tingkat terendah dalam struktur program). Karena komponen yang
terintegrasi dari bawah ke atas, fungsi yang disediakan oleh komponen bawahan
ke tingkat tertentu akan selalu tersedia dan kebutuhan akan stub dihilangkan.
Sebuah strategi integrasi bottom-up dapat dilaksanakan dengan langkah-langkah
berikut:
1. komponen tingkat rendah digabungkan menjadi cluster (kadang-kadang
disebut membangun) yang melakukan subfunction software tertentu.
2. Seorang pengemudi (program pengendalian untuk pengujian) ditulis untuk
mengkoordinasikan uji kasus input dan output.
3. Cluster diuji.
4. Driver dihapus dan cluster dikombinasikan bergerak ke atas dalam struktur
program.
Integrasi mengikuti pola diilustrasikan pada Gambar 17.6. Komponen digabungkan
untuk membentuk cluster 1, 2, dan 3. Masing-masing kelompok diuji menggunakan
driver (ditampilkan sebagai blok putus-putus). Komponen dalam kelompok 1 dan
2 adalah bawahan Ma. Driver D1 dan D2 akan dihapus dan cluster yang
dihubungkan langsung ke Ma. Demikian pula, sopir D3 untuk klaster 3 dihapus
sebelum integrasi dengan modul Mb. Kedua Ma dan Mb akhirnya akan
diintegrasikan dengan komponen Mc, dan sebagainya.
Integrasi ini bergerak ke atas, kebutuhan untuk tes driver terpisah dengan
demikian berkurang. Bahkan, jika atas dua tingkat struktur program yang
terintegrasi top down, jumlah driver dapat dikurangi secara substansial dan
integrasi cluster sangat sederhana.
Regression testing dalam pengujian Integrasi.
Setiap kali sebuah modul baru ditambahkan sebagai bagian dari pengujian
integrasi, ada perubahan perangkat lunak. Ada jalur baru aliran data ditetapkan,
baru kemudian I/O dapat terjadi, dan kemudian kontrol logika baru bisa dipanggil.
Perubahan ini dapat menyebabkan masalah dengan fungsi-fungsi yang
sebelumnya bekerja sempurna. Dalam konteks strategi uji integrasi, pengujian
120
regresi adalah reexecution dari beberapa subset dari tes yang telah dilakukan, ini
untuk memastikan bahwa perubahan belum menyebarkan efek samping yang
tidak diinginkan. Dalam konteks yang lebih luas, tes sukses (dalam bentuk apapun)
bila menghasilkan penemuan kesalahan, dan kesalahan kemudian harus
dikoreksi. Setiap kali software dikoreksi, beberapa aspek dari konfigurasi
perangkat lunak (program, dokumentasi, atau data yang mendukungnya) berubah.
Pengujian regresi membantu untuk memastikan bahwa perubahan (karena
pengujian atau untuk alasan lain) tidak memperkenalkan perilaku yang tidak
diinginkan, karena bisa menjadikan kesalahan tambahan. Pengujian regresi dapat
dilakukan secara manual, dengan mengeksekusi kembali subset dari semua kasus
uji atau menggunakan alat capture / playback otomatis. Alat capture / playback
memungkinkan software engineer untuk menangkap testcase (kasus uji) dan hasil
untuk pemutaran berikutnya, dan kemudian dapat di perbanding kan. Regresion
test Suite (subset dari tes yang akan dijalankan) berisi tiga kelas yang berbeda
dari test case / kasus uji:
Sebuah sampel yang representatif dari tes yang akan melaksanakan semua
fungsi perangkat lunak.
Tes tambahan yang berfokus pada fungsi software yang mungkin akan
terpengaruh oleh perubahan itu.
Tes yang berfokus pada komponen software yang telah berubah. Sebagai
pengujian integrasi hasil, jumlah tes regresi dapat tumbuh cukup besar.
Oleh karena itu, regresi test suite harus dirancang untuk hanya menyertakan tes
yang menangani satu atau lebih kelas kesalahan di setiap fungsi program utama.
Hal ini tidak praktis dan tidak efisien untuk mengeksekusi ulang setiap tes untuk
setiap fungsi program yang selalu terjadi perubahan.
Smoke testing.
Smoke testing atau pengujian Asap adalah sebuah pendekatan pengujian
integrasi yang umum digunakan ketika perangkat lunak produk dikembangkan. Hal
ini dirancang sebagai mekanisme bolak-balik untuk proyek yang waktu-kritis, yang
memungkinkan tim software untuk menilai proyek secara sering. Pada intinya,
pendekatan asap-pengujian meliputi kegiatan sebagai berikut:
1. Komponen Software yang telah diterjemahkan ke dalam kode
diintegrasikan ke dalam bangunan sistem. Sebuah bangunan sistem
121
mencakup semua file data, library/perpustakaan, modul yang dapat
digunakan kembali, dan komponen rekayasa yang diperlukan untuk
melaksanakan satu atau lebih fungsi produk.
2. Serangkaian tes ini dirancang untuk mengekspos kesalahan yang akan
membuat bangunan sistem bisa benar menjalankan fungsinya. Tujuannya
adalah agar harus dapat untuk mengungkap kesalahan "showstopper",
yaitu kesalahan yang memiliki kemungkinan tertinggi, sehingga
melemparkan proyek perangkat lunak ini menjadi mundur di belakang
jadwal yang seharusnya.
3. Membangun sistem secara terintegrasi dengan lainnya, dan seluruh
produk (dalam bentuk yang sekarang) adalah hasil uji asap yang dilakukan
setiap hari. Pendekatan integrasi bisa dilakukan top down atau bottom up.
Frekuensi harian pengujian seluruh produk bisa mengejutkan, tetapi sering tes ini
memberikan informasi yang baik kepada manajer dan para praktisi penilai yang
bekerja realistis, karena bisa melihat hasil kemajuan dari pengujian integrasi.
McConnell [McC96] menggambarkan uji asap dengan cara sebagai berikut:
Tes asap harus memberikan latihan untuk seluruh sistem dari ujung ke ujung.
Tidak harus lengkap, tetapi harus mampu mengekspos masalah besar. Uji asap
harus cukup menyeluruh, bahwa dalam proses pembangunan, dapat
mengasumsikan bahwa hasil yang dibangun itu cukup stabil untuk diuji lebih teliti.
Pengujian Asap memberikan sejumlah manfaat bila diterapkan di proyek
perangkat lunak yang timecritical:
Risiko Integrasi diminimalkan. Karena tes asap yang dilakukan setiap hari,
sehingga ketidak cocokan dan kesalahan show-stopper lain bisa terungkap
lebih awal, maka akan mengurangi kemungkinan dampak kemunduran
jadwal yang serius ketika kesalahan yang terungkap.
Kualitas produk akhir ditingkatkan. Karena pendekatan konstruksi
(integrasi) yang berorientasi, pengujian asap mempunyai kemungkinan
untuk mengungkap kesalahan fungsional serta kesalahan desain arsitektur
dan komponen-tingkat. Jika kesalahan ini dikoreksi lebih awal, kualitas
produk yang lebih baik akan dihasilkan.
Diagnosis kesalahan dan koreksi disederhanakan. Seperti semua
pendekatan pengujian integrasi, kesalahan yang ditemukan selama
pengujian asap mungkin terkait dengan " kesalahan bertahap dari software
122
baru", yaitu adanya kesalahan karena software yang baru saja ditambahkan
ke edisi itu, ini adalah kemungkinan penyebab kesalahan yang baru bisa
ditemukan.
Kemajuan lebih mudah untuk menilai. Dengan setiap hari dilakukan
pengujian, perangkat lunak telah diuji terintegrasi akan lebih terbukti
bekerja. Hal ini meningkatkan moral tim dan memberikan informasi kepada
manajer adanya indikasi yang baik bahwa kemajuan sedang dibuat.
Strategic options.
Tentang kelebihan dan kekurangan dari pengujian terintegrasi top-down terhadap
pengujian integrasi bottom-up. Secara umum, keuntungan dari salah satu strategi
cenderung menghasilkan kerugian bagi strategi lainnya. Kerugian utama dari
pendekatan top-down adalah kebutuhan untuk stub dan kesulitan petugas
pengujian untuk dapat berhubungan dengan sistem. Meskipun demikian
kekurangan yang terkait ini dapat diimbangi oleh keuntungan dari pengujian fungsi
kontrol utama pada awalnya. Kerugian utama dari integrasi bottom-up adalah
bahwa "program sebagai entitas, tidak ada ditambahkan sampai modul terakhir".
Keuntungannya adalah mudah mendesain testcase/uji kasus.
Pemilihan strategi integrasi tergantung pada karakteristik perangkat lunak dan
jadwal proyek. Secara umum, pendekatan gabungan (disebut pengujian sandwich)
yang menggunakan tes top-down untuk tingkat atas dari struktur program,
ditambah dengan tes bottom-up untuk tingkat bawah, ini sebuah kompromi terbaik.
Pengujian integrasi dilakukan agar tester harus dapat mengidentifikasi modul kritis.
Adapun sebuah modul kritis biasanya memiliki satu atau lebih dari karakteristik
berikut:
1. membahas beberapa persyaratan perangkat lunak,
2. memiliki tingkat kontrol yang tinggi (relatif tinggi dalam struktur program),
3. modul adalah kompleks atau rawan kesalahan, atau
4. memiliki persyaratan kinerja yang pasti. Modul kritis harus diuji sedini
mungkin. Selain itu, tes regresi harus fokus pada fungsi modul kritis.
Integration test work products.
Rencana keseluruhan untuk integrasi perangkat lunak dan deskripsi tes khusus
didokumentasikan dalam Test Spesifikasi. Produk kerja ini menggabungkan
123
rencana uji dan prosedur pengujian dan menjadi bagian dari konfigurasi perangkat
lunak.
Pengujian dibagi menjadi Phase dan Builds, yang menunjukkan pada karakteristik
fungsional dan perilaku tertentu dari perangkat lunak tersebut. Sebagai contoh,
pengujian integrasi untuk sistem keamanan rumah mungkin dibagi ke dalam tahap
pengujian berikut:
interaksi pengguna (command, input dan output, representasi tampilan,
pengolahan kesalahan dan representasi laporan)
pengolahan Sensor (akuisisi output sensor, penentuan kondisi sensor,
tindakan yang diperlukan sebagai konsekuensi dari kondisi baik senso
maupun lingkungan)
Fungsi Komunikasi (kemampuan untuk berkomunikasi dengan stasiun
pemantauan pusat)
pengolahan Alarm (tes tindakan perangkat lunak yang terjadi ketika alarm
ditemui)
Masing-masing fase uji integrasi ini, mengarah pada kategori fungsional yang luas
dalam perangkat lunak, dan umumnya dapat dikaitkan dengan domain tertentu
dalam arsitektur perangkat lunak. Oleh karena itu Program, pembangunan
kelompok modul, diciptakan untuk bisa sesuai dengan setiap tahap
pengembangan. Berikut kriteria dan tes yang sesuai, bisa diterapkan untuk semua
fase pengujian:
1. Integritas antarmuka. Antarmuka internal dan eksternal diuji karena setiap
modul (atau cluster) dimasukkan ke dalam struktur.
2. Validitas fungsional. Pengujian dirancang untuk mengungkap kesalahan
fungsional dilakukan. Isi informasi. Pengujian dirancang untuk mengungkap
kesalahan yang terkait dengan struktur data lokal atau global.
3. Kinerja. Tes yang dirancang untuk memverifikasi batas kinerja yang telah
ditetapkan selama perancangan perangkat lunak dilakukan.
4. Jadwal untuk integrasi, pengembangan perangkat lunak, dan berbagai topik
terkait, dibahas sebagai bagian dari rencana uji. Tanggal mulai dan berakhir
untuk setiap tahap ditetapkan, dan "adanya ketersediaan jendela" untuk
modul unit-diuji didefinisikan.
5. Sebuah deskripsi singkat dari stub dan driver berkonsentrasi pada
karakteristik yang memerlukan upaya khusus.
124
6. Lingkungan pengujian dan sumber daya dijelaskan. Konfigurasi hardware
yang tidak biasa, simulator eksotis, alat uji khusus atau teknik tertentu
adalah beberapa dari banyak topik yang juga akan dibahas.
Prosedur pengujian rinci yang diperlukan untuk mencapai rencana uji perlu
dijelaskan selanjutnya. Urutan integrasi dan tes di setiap langkah integrasi yang
sesuai harus juga dijelaskan. Sebuah daftar dari semua kasus uji/test case dan
hasil yang diharapkan juga disertakan.
Riwayat hasil aktual tes, masalah, atau keanehan dicatat dalam Laporan Uji yang
dapat ditambahkan ke Uji Spesifikasi. Informasi yang terkandung dalam bagian ini
dapat menjadi vital selama pekerjaan perawatan perangkat lunak. Untuk itu maka
Referensi yang tepat dan lampiran juga perlu disajikan.
Seperti semua elemen lain dari konfigurasi perangkat lunak, format uji spesifikasi
dapat disesuaikan dengan kebutuhan lokal dari organisasi rekayasa perangkat
lunak. Hal ini penting untuk dicatat, bahwa strategi integrasi (yang terkandung
dalam rencana test) dan rincian pengujian (dijelaskan dalam prosedur test)
merupakan bahan penting dan harus muncul.
Integration Testing dalam konteks OO
Karena perangkat lunak berorientasi objek tidak memiliki struktur pengendalian
hirarkis yang jelas, tidak sebagaimana bisa dibuat top-down tradisional dan strategi
integrasi bottom-up, maka cara itu memiliki sedikit makna di OO.
Selain itu, untuk mengintegrasikan operasi satu per satu ke dalam kelas
(konvensional, pendekatan integrasi incremental) sering tidak mungkin karena
"interaksi langsung dan tidak langsung dari komponen yang membentuk kelas".
Ada dua strategi yang berbeda untuk pengujian integrasi pada sistem OO [Bin94b].
Pertama, thread-based testing, ini mengintegrasikan set kelas yang dibutuhkan
untuk merespon satu input atau event untuk sistem. Setiap thread diintegrasikan
dan diuji secara individual. Pengujian regresi diterapkan untuk memastikan bahwa
tidak ada efek samping terjadi.
Kedua, Use-based testing, dimulai pada pembangunan sistem dengan menguji
kelas-kelas tertentu yang disebut kelas yang independen, yang menggunakan
sangat sedikit bentuk kelas Server. Setelah kelas independen diuji, lapisan
berikutnya kelas yang disebut dependent class/ klas tergantung, yang
125
pengujiannya menggunakan kelas independen. Urutan lapisan pengujian
tergantung kelas selanjutnya sampai seluruh sistem yang dibangun diuji semua.
Penggunaan driver dan stub juga berubah ketika pengujian integrasi sistem OO
dilakukan. Driver dapat digunakan untuk menguji operasi pada tingkat terendah
dan untuk pengujian seluruh kelompok kelas. Driver juga dapat digunakan untuk
menggantikan user interface sehingga tes terhadap fungsi sistem dapat dilakukan
sebelum pelaksanaan.
Pengujian kelas untuk perangkat lunak OO, sama dengan modul pengujian untuk
perangkat lunak konvensional. Hal ini tidak dianjurkan untuk menguji operasi
dalam sistem yang terisolasi. Maka merupakan strategi penting untuk pengujian
integrasi perangkat lunak OO adalah thread-based testing. Kumpulan kelas
threat yang menanggapi masukan atau event, perlu dilakukan dengan tes ini.
Tes Use-based ber fokus pada kelas yang tidak bekerja sama secara berat dengan
kelas-kelas lain.
Dalam situasi di mana kolaborasi antara kelas diperlukan tetapi satu atau lebih dari
kelas-kelas itu berkolaborasi belum sepenuhnya. Pengujian Cluster merupakan
salah satu langkah dalam pengujian integrasi perangkat lunak OO. Di sini,
sekelompok klas berkolaborasi (ditentukan dengan memeriksa CRC dan object-
relationship model) dilaksanakan dengan merancang uji kasus, yang berusaha
mengungkap kesalahan dalam kolaborasi.
7.4.3 Validation testing
Pengujian validasi dimulai pada puncak dari pengujian integrasi, akhir pengujian
integrasi, ketika masing-masing komponen telah diuji, perangkat lunak benar-
benar telah dirakit sebagai sebuah paket, dan kesalahan interfacing telah
ditemukan dan diperbaiki. Pada validasi, perbedaan antara perangkat lunak
konvensional, perangkat lunak berorientasi objek, dan webapps menghilang, taka
da bedanya. Pengujian Validasi berfokus pada tindakan-pengguna yang terlihat
dan output-pengguna yang dikenali dari sistem.
Validasi dapat didefinisikan dalam banyak cara, tapi definisi sederhananya adalah
bahwa validasi dikatakan baik, berhasil jika fungsi perangkat lunak dapat cukup
sesuai dengan yang diharapkan oleh pelanggan.
126
Pada titik ini pengembang perangkat lunak, mungkin protes: "Siapa atau apa yang
menjadi wasit dari harapan/kebutuhan yang masuk akal dari pengguna".
Jika Spesifikasi Kebutuhan Perangkat Lunak telah diberikan, dan software telah
dikembangkan, itu berarti semua atribut kebutuhan pengguna tergambar dan
terlihat pada perangkat lunak, maka berarti itu berisi bagian dari Kriteria Validasi
yang membentuk dasar untuk pendekatan pengujian-validasi.
Kriteria Validation-Test
Validasi perangkat lunak dicapai melalui serangkaian tes yang menunjukkan
kesesuaian dengan persyaratan yang telah dikemukakan. Sebuah rencana uji
menguraikan kelas tes yang akan dilakukan, dan juga prosedur tes akan
mendefinisikan kasus uji spesifik, yang dirancang untuk memastikan bahwa
semua persyaratan fungsional dari software akan terpuaskan kepada pengguna,
semua karakteristik perilaku software juga akan dicapai, semua konten yang
akurat dapat disajikan dengan benar, semua persyaratan kinerja dicapai,
dokumentasi dibuat dengan benar, serta kegunaan dan persyaratan lainnya
terpenuhi (misalnya, transportability, kompatibilitas, pemulihan kesalahan,
pemeliharaan).
Setiap kasus uji validasi telah dilakukan, jika salah satu dari dua kondisi ada:
1. Fungsi atau karakteristik kinerja sesuai dengan spesifikasi dan diterima atau
2. Penyimpangan dari spesifikasi ditemukan dan daftar kekurangan dibuat.
Penyimpangan atau kesalahan yang ditemukan pada tahap ini, dalam sebuah
proyek jarang dapat dikoreksi sebelum pengiriman dijadwalkan. Oleh karena itu
hal ini sering diperlukan untuk bernegosiasi dengan pelanggan, untuk menjadi
sebuah metode dalam menyelesaikan kekurangan.
7.4.4 System testing
Ketika kesalahan ditemukan, para pengembang elemen sistem yang berbeda
akan saling menyalahkan untuk masalah tersebut. Daripada terlibat dalam konflik
seperti itu, harus mengantisipasi masalah itu dengan interfacing secara potensial,
yaitu dengan:
1. Melihat jalur kesalahan penanganan desain, yang menguji semua informasi
yang datang dari unsur-unsur lain dari sistem,
127
2. Melakukan serangkaian tes yang dapat mensimulasikan data yang buruk
atau memperlihatkan kesalahan potensial lainnya pada antarmuka
perangkat lunak,
3. Mencatat hasil tes untuk digunakan sebagai "bukti", dan
4. Berpartisipasi dalam perencanaan dan desain sistem tes untuk memastikan
perangkat lunak diuji secara memadai.
Sistem Tes/Pengujian sistem sebenarnya serangkaian tes yang berbeda,
bertujuan utama untuk melaksanakan/mengoperasikan sistem berbasis komputer.
Meskipun masing-masing tes memiliki tujuan yang berbeda, semua pekerjaan
adalah untuk memverifikasi bahwa elemen sistem telah terintegrasi dengan baik
dan bisa melakukan fungsi-fungsi yang telah dialokasikan.
Pada bagian berikut, dibahas jenis tes sistem yang berharga untuk sistem berbasis
software.
Sistem Test melibatkan proses mengintegrasikan komponen untuk membuat versi
sistem dan kemudian menguji sistem yang terintegrasi tersebut. Pengujian sistem
adalah mengecek komponen yang kompatibel, bisa berinteraksi dengan benar dan
mentransfer data yang tepat pada waktunya, serta tepat di antarmuka mereka.
Ini kelihatannya tumpang tindih dengan pengujian komponen, tetapi
sesungguhnya ada dua perbedaan penting:
1. Selama pengujian sistem, komponen Re-use yang telah terpisah dapat
dikembangkan dan off-the-shelf pada sistem, komponen itu dapat
diintegrasikan dengan komponen yang baru dikembangkan. Sistem yang
sudah lengkap kemudian diuji.
2. Komponen yang dikembangkan oleh anggota tim yang berbeda atau
kelompok dapat diintegrasikan pada tahap ini. Pengujian sistem adalah
kolektif dan bukan proses individual. Di beberapa perusahaan, pengujian
sistem mungkin melibatkan tim pengujian terpisah tanpa keterlibatan dari
perancang dan programer.
Pengujian sistem harus fokus pada pengujian interaksi antara komponen dan
benda-benda yang membentuk sebuah sistem. Anda juga dapat menguji
komponen atau sistem yang dapat digunakan kembali untuk memeriksa bahwa
mereka bekerja seperti yang diharapkan ketika mereka terintegrasi dengan
komponen baru.
128
Pengujian interaksi ini harus menemukan bug komponen yang hanya terungkap
ketika komponen yang digunakan oleh komponen lain dalam sistem. Pengujian
interaksi juga membantu menemukan kesalah pahaman yang dibuat oleh
pengembang komponen, tentang komponen lain dalam sistem.
Karena fokus pada interaksi, pengujian berbasis kasus yang digunakan adalah
pendekatan yang efektif untuk pengujian sistem. Biasanya, setiap kasus
penggunaannya diimplementasikan oleh beberapa komponen atau objek dalam
sistem. Test case / Pengujian kasus menggunakan kekuatan interaksi ini.
Diagram urutan membantu untuk merancang uji kasus-kasus tertentu yang
dibutuhkan, karena dapat menunjukkan apa yang menjadi input yang diperlukan
dan apa yang menjadi output yang dibuat:
a. Sebuah input dari permintaan laporan harus memiliki pengakuan yang
terkait. Sebuah laporan pada akhirnya harus dikembalikan dari permintaan.
Selama pengujian, harus diciptakan secara ringkas dari data yang
digunakan untuk memudahkan memeriksa bahwa laporan itu disusun
dengan benar.
b. Sebuah permintaan masukan untuk laporan hasilnya diringkas. Ini dapat
diuji dalam isolasi dengan menciptakan data mentah sesuai dengan
ringkasan yang telah disiapkan, hal ini untuk uji yang lain dan diperiksa
bahwa objek laporan adalah benar menghasilkan ringkasan ini. Data
mentah ini juga bisa digunakan untuk menguji objek laporan itu.
7.5 Test-driven development
Untuk kebanyakan sistem, sulit untuk mengetahui bagaimana pengujian sistem
dilakukan, dimana pengujian jauh sangat penting, tetapi juga kapan harus berhenti
melakukan pengujian.
Pengujian yang mendalam, di mana setiap urutan eksekusi program diuji, adalah
hal yang mustahil. Oleh karena itu pengujian harus didasarkan pada subset dari
kemungkinan uji kasus. Idealnya, perusahaan perangkat lunak harus memiliki
kebijakan untuk memilih subset ini. Kebijakan ini didasarkan pada kebijakan
pengujian umum, seperti kebijakan bahwa semua pernyataan program harus
dijalankan minimal sekali. Atau, mereka mendasarkan pada pengalaman
129
penggunaan sistem dan fokus pada pengujian fitur dari sistem operasional.
Sebagai contoh:
1. Semua fungsi sistem yang diakses melalui menu harus diuji.
2. Kombinasi fungsi (misalnya, teks format) yang diakses melalui menu yang
sama harus diuji.
3. Dimana input pengguna disediakan, semua fungsi harus diuji dengan
masukan yang benar maupun yang salah.
Hal ini jelas dari pengalaman dengan produk perangkat lunak besar seperti
pengolah kata atau spreadsheet bahwa pedoman yang sama biasanya digunakan
selama pengujian produk.
Bila fitur dari perangkat lunak yang digunakan dalam isolasi, masalah timbul ketika
kombinasi dari fitur kurang umum digunakan, dan belum diuji bersama-sama.
Sebagai contoh bagaimana dalam pengolah kata yang umum digunakan,
penggunakan catatan kaki dengan layout multicolumn menyebabkan tata letak
yang salah dari teks.
Pengujian sistem otomatis biasanya lebih sulit daripada pengujian komponen yan
otomatis. Unit pengujian otomatis bergantung pada cara memprediksi output
kemudian memasukkan pengkodean prediksi ini dalam sebuah program. Prediksi
ini kemudian dibandingkan dengan hasilnya. Namun dalam pelaksanaan sistem
untuk menghasilkan output yang besar tidak dapat dengan mudah diprediksi.
--
Recovery Testing / Pemulihan Pengujian
Banyak sistem berbasis komputer harus pulih dari kesalahan dan melanjutkan
proses dengan sedikit atau tanpa downtime. Biasanya sistem harus fault tolerant;
yaitu, kesalahan pengolahan tidak harus menyebabkan fungsi sistem secara
keseluruhan berhenti. Untuk itu, kegagalan sistem harus diperbaiki dalam jangka
waktu tertentu agar kerusakan ekonomi yang parah tak akan terjadi.
Pengujian pemulihan adalah tes sistem yang memaksa perangkat lunak untuk
gagal dalam berbagai cara dan memverifikasi bahwa pemulihan dilakukan dengan
benar.
Jika dilakukan pemulihan otomatis (dilakukan oleh sistem itu sendiri), diantaranya
adalah: reinitialization, mekanisme checkpointing, pemulihan data, dan me-restart,
semua perlu dievaluasi untuk kebenarannya. Jika pemulihan membutuhkan
130
campur tangan manusia, mean-waktu ke-perbaikan (MTTR) dievaluasi untuk
menentukan apakah itu ada dalam batas yang dapat diterima.
Security Testing/Pengujian Keamanan
Setiap sistem berbasis komputer yang mengelola informasi sensitif atau yang bisa
menyebabkan tindakan yang tidak benar, tindakan itu dapat membahayakan,
adanya individu yang mencari target untuk melakukan penetrasi yang tidak benar
atau ilegal.
Penetrasi mencakup berbagai kegiatan: hacker yang berusaha untuk menembus
sistem, karyawan yang tidak puas yang mencoba untuk menembus untuk
membalas dendam, orang yang tak jujur berusaha untuk menembus demi
keuntungan pribadi yang terlarang, dan sebagainya.
Pengujian keamanan mencoba untuk memverifikasi bahwa mekanisme
perlindungan yang dibangun pada sistem akan dapat melindungi dari penetrasi
yang tidak benar.
"keamanan sistem harus diuji untuk mendapatkan kekebalan dari serangan
berasal dari depan, tetapi juga harus diuji untuk kekebalan dari serangan sayap
atau serangan belakang."
Selama pengujian keamanan, tester memainkan peran dari individu yang
menginginkan untuk menembus sistem. Tester akan mencoba untuk mendapatkan
password melalui eksternal, dari sarana administrasi; dapat menyerang sistem
dengan perangkat lunak yang dirancang khusus untuk memecah setiap
pertahanan yang telah dibangun; mungkin membanjiri sistem, sehingga
menyangkal pelayanan kepada orang lain; sengaja dapat menyebabkan
kesalahan sistem, berharap untuk menembus selama pemulihan; mungkin
menelusuri data yang tidak aman, berharap menemukan kunci untuk masuk
sistem.
Tester diberikan cukup waktu dan sumber daya, pengujian keamanan yang baik
pada akhirnya akan menembus sebuah sistem. Peran perancang sistem adalah
untuk membuat biaya penetrasi lebih besar dari nilai informasi yang akan
diperoleh.
Stress Testing /Pengujian tekanan
Stress test yang dirancang untuk menghadapi program dengan situasi abnormal.
Pada dasarnya, tester yang melakukan stress testing bertanya: "Seberapa tinggi
kita bisa engkol ini sebelum gagal?"
131
Stress testing mengeksekusi sistem dengan cara yang menuntut sumber daya
dalam jumlah yang abnormal,bisa juga tentang frekuensi, atau volume. Sebagai
contoh,
1. tes khusus dapat dirancang yang menghasilkan sepuluh potong per detik,
ketika satu atau dua adalah tingkat rata-rata,
2. tarif input data dapat ditingkatkan dengan urutan besarnya untuk
menentukan bagaimana fungsi masukan akan merespon,
3. uji kasus yang memerlukan memori maksimum atau sumber daya lainnya
yang dijalankan,
4. uji kasus yang dapat menyebabkan meronta-ronta dalam sistem operasi
virtual yang dirancang,
5. uji kasus yang dapat menyebabkan perburuan yang berlebihan untuk disk
data-penduduk diciptakan. Pada dasarnya, tester mencoba untuk
memecahkan program.
Sebuah variasi stress testing adalah teknik yang disebut tes kepekaan. Dalam
beberapa situasi (yang paling umum terjadi pada algoritma matematika), rentang
yang sangat kecil dari data yang terdapat dalam batas-batas data yang valid untuk
sebuah program dapat menyebabkan pengolahan ekstrim dan bahkan salah atau
penurunan kinerja yang mendalam. Pengujian sensitivitas mencoba untuk
mengungkap kombinasi data dalam kelas input yang valid yang dapat
menyebabkan ketidak stabilan atau pengolahan yang tidak tepat.
Performance test/Pengujian Kinerja
Untuk real-time dan embedded system, software yang menyediakan fungsi yang
diperlukan tetapi tidak sesuai dengan persyaratan kinerja tidak dapat diterima.
Kinerja pengujian dirancang untuk menguji kinerja run-time software dalam
konteks sebuah sistem terintegrasi. Kinerja pengujian terjadi sepanjang semua
langkah dalam proses pengujian. Bahkan pada tingkat unit, kinerja modul individu
dapat dinilai sebagai tes dilakukan. Namun, tidak sampai semua elemen sistem
yang terintegrasi sepenuhnya bahwa kinerja sebenarnya dari sistem dapat
dipastikan.
Tes kinerja sering digabungkan dengan stress testing dan biasanya membutuhkan
baik hardware dan software instrumentasi. Artinya, itu sering perlu untuk mengukur
pemanfaatan sumber daya (misalnya, siklus prosesor) dengan cara menuntut.
Instrumentasi eksternal dapat memantau interval eksekusi, peristiwa log (misalnya
132
menyela) yang terjadi. Dengan instrumenting sistem, tester dapat mengungkap
situasi yang menyebabkan degradasi dan kegagalan sistem.
Deployment Test
Dalam banyak kasus, perangkat lunak harus dijalankan pada berbagai platform
dan di bawah lebih dari satu lingkungan sistem operasi. Pengujian Deployment,
kadang-kadang disebut pengujian konfigurasi, melaksanakan perangkat lunak di
setiap lingkungan di mana itu adalah untuk beroperasi. Selain itu, pengujian
penyebaran memeriksa semua prosedur instalasi dan instalasi perangkat lunak
khusus (misalnya, "installer") yang akan digunakan oleh pelanggan, dan semua
dokumentasi yang akan digunakan untuk memperkenalkan perangkat lunak
kepada pengguna akhir.
Sebagai contoh, pertimbangkan versi Internet yang dapat diakses dari perangkat
lunak SafeHome yang akan memungkinkan pelanggan untuk memantau sistem
keamanan dari lokasi terpencil.
SafeHome WebApp harus diuji dengan menggunakan semua browser Web yang
mungkin ditemui. Sebuah tes penyebaran lebih menyeluruh dapat meliputi
kombinasi dari Web browser dengan berbagai sistem operasi (misalnya, Linux,
Mac OS, Windows). Karena keamanan merupakan masalah besar, satu set
lengkap tes keamanan akan diintegrasikan dengan tes penyebaran.
133
Bab 8 : Evolusi Software
Pengembangan perangkat lunak dan evolusinya dapat dianggap sebagai suatu
yang terintegrasi, karena proses yang dilakukan berulang-ulang, yang dapat
diwakili menggunakan model spiral.
Untuk sistem software yang di-kustom, biaya perawatan biasanya melebihi biaya
pengembangan perangkat lunak. Meskipun demikian kadang masih digunakan,
karena perusahaan memerlukan perubahan terus menerus. Kita mengetahui
bahwa proses evolusi perangkat lunak didorong oleh permintaan untuk perubahan,
termasuk analisis dampak perubahan, perencanaan pelaksanaan rilis, dan
pelaksanaan perubahan.
Ada beberapa ungkapan yang perlu diperhatikan berhubungan dengan evolusi
software, antara lain:
Perawatan, ada tiga jenis perawatan perangkat lunak, yaitu memperbaiki bug,
memodifikasi perangkat lunak untuk bisa bekerja di lingkungan yang baru, dan
yang ketiga merubah, yaitu menerapkan persyaratan baru.
Software rekayasa ulang , ini berkaitan dengan restrukturisasi dan
redocumenting software, untuk membuatnya lebih mudah untuk memahami dan
perubahan.
Refactoring, yang dimaksud disini adalah membuat perubahan program kecil
yang berguna untuk melestarikan fungsi, bentuk ini dapat juga dianggap sebagai
perawatan pencegahan.
Nilai bisnis , ini suatu nilai berdasar sistem warisan yang diperoleh sebelumnya,
dan didalamnya ada kualitas aplikasi software, untuk menentukan nilai bisnis ini
lingkungannya harus dinilai, untuk menentukan apakah sistem perlu harus diganti,
diubah, atau dipertahankan.
8.1 Pengembangan software dan Evolusinya
Pengembangan perangkat lunak tidak berhenti ketika sistem disampaikan kepada
pengguna, tetapi seharusnya tetap berlanjut sepanjang masa sistem masih bisa
bekerja. Setelah digunakan, sistem software itu pasti harus berubah jika ingin tetap
berguna. Sebab selalu ada perubahan bisnis dan perubahan harapan pengguna,
itu semua menghasilkan persyaratan baru untuk perangkat lunak yang ada.
134
Bagian dari perangkat lunak tertentu mungkin harus dimodifikasi, ini karena bisa
terjadi untuk memperbaiki kesalahan yang ditemukan dalam operasi, untuk
beradaptasi dengan perubahan hardware dan platform software, dan bisa juga
untuk meningkatkan performa atau karakteristik non-fungsional lainnya.
Evolusi Software penting dilakukan karena organisasi yang telah
menginvestasikan uang dalam jumlah besar, baik dalam perangkat lunak maupun
hardware, mereka menjadi bergantung pada sistem ini, sistem software ini
menjadi aset bisnis penting dan mereka harus berinvestasi dalam perubahan
sistem untuk mempertahankan nilai aset tersebut. Akibatnya, sebagian besar
perusahaan besar menghabiskan dana cukup besar untuk mempertahankan
sistem yang ada, atau melakukan evolusi dari pada pengembangan sistem baru.
Evolusi software dapat dipicu oleh perubahan kebutuhan bisnis, atau berdasarkan
adanya laporan dari cacat perangkat lunak, atau oleh adanya perubahan ke sistem
lain.
Untuk menggambarkan situasi di mana sistem perangkat lunak harus
dikembangkan dan dikelola dalam lingkungan di mana mereka bergantung pada
banyak sistem perangkat lunak lain.Ini disebut ‘brownfield’ ( istilah ini
dikembangkan oleh Hopkins dan Jenkins (2008). Oleh karena itu, evolusi sistem
tidak dapat atau jarang dilakukan dalam proses yang ter-isolasi, artinya harus ada
interaksi dengan software yang ada di lingkungan itu.
Perubahan lingkungan menyebabkan perubahan sistem yang kemudian dapat
memicu perubahan lingkungan lebih lanjut. Yang diperlukan adalah juga harus
bisa menilai bagaimana suatu software dapat mempengaruhi sistem lain dalam
lingkungan operasional.
Sistem perangkat lunak yang berguna sering memiliki seumur hidup yang sangat
panjang. Sebagai contoh, militer atau infrastruktur sistem yang besar, seperti
sistem kontrol lalu lintas udara, mungkin memiliki masa pakai 30 tahun atau lebih.
Sistem bisnis juga sering berusia lebih dari 10 tahun. Untuk yang hal ini maka
perusahaan dapat menggunakan software untuk bertahun tahun, dan
mendapatkan laba atas investasi software itu. Untuk ini jelas biasanya mempunyai
persyaratan dari sistem yang terpasang, sebab apa yang berubah, sebagai yang
ada di bisnis dan perubahan lingkungan sudah terlihat dan diperkirakan dengan
baik. Oleh karena itu, rilis baru dari sistem, perubahan menggabungkan, dan
update, biasanya dibuat secara berkala.
135
Evolusi ada juga kemungkinan akan diskontinuitas sebagaimana seharusnya yang
ada dalam proses spiral. Suatu Persyaratan dan dokumen desain, bisa jadi tidak
lulus untuk suatu perusahaan, tapi bisa digunakan ke perusahaan lain. Dari segi
organisasi, Perusahaan juga dapat menggabungkan atau mereorganisasi dan
kemudian mewarisi software dari perusahaan lain, dan baru kemudian
menemukan hal yang harus diubah. Maka dilakukan perubahan.
Ketika transisi dari pengembangan untuk evolusi tidak mulus, proses mengubah
perangkat lunak setelah jadi sering disebut 'perawatan perangkat lunak'.
Perawatan melibatkan kegiatan proses tambahan, seperti pemahaman Program
misalnya, disamping itu masih ada kegiatan normal pengembangan perangkat
lunak, yang ini selalu dilakukan untuk memperbaiki yang ada.
Rajlich dan Bennett (2000) mengusulkan pandangan alternatif dari siklus hidup
evolusi perangkat lunak. Dalam model yang dibuat ini, mereka membedakan
antara evolusi dan servis. Evolusi adalah fase di mana perubahan yang signifikan
terhadap arsitektur perangkat lunak dan fungsi dapat dilakukan, adanya
perubahan yang dibuat relatif kecil, tetapi itu perubahan penting.
Selama evolusi, software yang digunakan berjalan dengan sukses, dan ada aliran
secara konstan diusulkan untuk perubahan, usulan usulan yang memenuhi
persyaratan.
Namun, sebagai perangkat lunak yang dimodifikasi, strukturnya cenderung
menurun dan kemudian perubahan menjadi lebih komplek dan lebih mahal. Hal
ini sering terjadi setelah beberapa tahun penggunaan, ketika perubahan
lingkungan lainnya terjadi, perubahan lingkungan itu sering juga terjadi misalnya
pada perangkat keras dan sistem operasi.
Berdasarkan jajak pendapat industri informal Erlikh (2000) menunjukkan bahwa
85-90% dari biaya perangkat lunak organisasi adalah biaya evolusi. Survei lain
juga menunjukkan bahwa sekitar dua pertiga dari biaya perangkat lunak adalah
biaya evolusi. Yang pasti, biaya perubahan perangkat lunak adalah bagian besar
dari anggaran TI untuk semua perusahaan.
136
Gambar 8.1 siklus evolusi software
8.2 Proses evolusi
Proses evolusi software bervariasi tergantung pada jenis perangkat lunak yang
dipelihara,juga tergantung proses pengembangan yang digunakan dalam sebuah
organisasi dan keterampilan orang yang terlibat. Dalam beberapa organisasi,
evolusi dapat menjadi proses yang informal di mana permintaan perubahan
sebagian besar berasal dari percakapan antara pengguna sistem dan
pengembang. Ada juga yang menggunakan proses formal dengan dokumentasi
terstruktur, dan diproduksi pada setiap tahap dalam proses.
Proses evolusi ini dimulai dari adanya proposal perubahan.
Proposal perubahan adalah driver untuk sistem yang bisa berevolusi di semua
organisasi.
Kedua mengadakan Perubahan proposal, ini berasal dari persyaratan yang ada,
yang belum diimplementasikan dalam sistem yang sudah dirilis, ditambah dengan
permintaan pada persyaratan yang baru, laporan bug dari seluruh stakeholder
terhadap sistem, dan ide-ide baru untuk perbaikan, terutama dari tim
pengembangan sistem perangkat lunak.
Proses identifikasi perubahan dan evolusi sistem yang siklik dan terus menerus
sepanjang masa sistem, maka dalam mengubah proposal harus dikaitkan dengan
komponen dan usulan yang harus diubah. Hal ini memungkinkan untuk melihat
dan menilai biaya dan dampak perubahan, sehingga sesuai proses umum
manajemen perubahan, dimana harus memastikan bahwa versi mempunyai
urutan yang benar dari komponen yang terjadi perubahan, dan termasuk dalam
perencanaan setiap rilis sistem. .
137
Gambar 8.2: proses Evolusi
Gambar 8.2, diadaptasi dari Arthur (1988), menunjukkan gambaran dari proses
evolusi. Proses ini meliputi kegiatan dasar analisis perubahan, perencanaan
pelaksanaan rilis, implementasi sistem, dan merilis sebuah sistem untuk
pelanggan. Biaya dan dampak dari perubahan ini dinilai untuk melihat berapa
banyak komponen sistem dipengaruhi oleh perubahan, dan berapa banyak biaya
untuk menerapkan perubahan.
Jika perubahan yang diajukan diterima, rilis baru dari sistem direncanakan.
Kemudian selama perencanaan rilis dilakukan, semua perubahan yang diajukan
(perbaikan kesalahan, adaptasi, dan fungsi baru) boleh dianggap bisa dilakukan.
Baru nanti menginjak tentang keputusan terhadap apa yang akan dilakukan
perubahan, Keputusan tersebut kemudian baru dibuat, menentukan mana yang
berubah, dan kemudian bisa menyusun untuk menerapkan dalam versi berikutnya
dari sistem perubahan ini. Perubahan diimplementasikan dan divalidasi, dan versi
baru dari sistem dilepaskan. Proses ini berjalan secara iterasi, dengan selalu
menambah satu set baru perubahan yang diusulkan untuk rilis berikutnya.
Maka pelaksanaan perubahan sebagai iterasi dari proses pembangunan, di mana
revisi sistem dirancang, dilaksanakan, dan diuji. Perbedaan yang penting adalah
bahwa tahap pertama pelaksanaan perubahan perlu melibatkan pemahaman
Program, lebih lebih bila pengembang sistem yang asli tidak bertanggung jawab
atas implementasi perubahan. Selama fase pemahaman program, harus dipahami
bagaimana program ini disusun, bagaimana memberikan fungsionalitas, dan
bagaimana perubahan yang diusulkan dapat mempengaruhi program. Semua itu
untuk memastikan bahwa perubahan diimplementasikan, dan tidak menimbulkan
masalah baru ketika diimplementasikan/diperkenalkan ke dalam sistem yang ada.
Selama proses evolusi, persyaratan dianalisis secara rinci dan implikasi dari
perubahan yang muncul, yang tadinya tidak jelas/tak diketahui dalam proses
138
analisis perubahan sebelumnya, maka perubahan yang diusulkan dapat
dimodifikasi dan didiskusikan lagi kepada pelanggan, agar untuk selanjutnya
mereka mengerti apa yang diperlukan sebelum software diimplementasikan.
Perubahan permintaan terkadang berhubungan dengan masalah sistem yang
harus ditangani segera. Perubahan mendesak dapat timbul karena tiga alasan:
1. Jika sistem mempunyai kesalahan serius, yang harus diperbaiki untuk
memungkinkan operasi dapat normal lagi dan bisa untuk dilanjutkan.
2. Jika perubahan pada lingkungan sistem operasi memiliki efek tak terduga yang
mengganggu operasi normal.
3. Jika ada perubahan yang tak terduga bagi bisnis dalam menjalankan sistem,
seperti munculnya pesaing baru atau pengenalan undang-undang baru yang
mempengaruhi sistem.
Dalam suatu kasus, ada kebutuhan untuk membuat perubahan dengan cepat,
maka berarti bahwa tidak mungkin dapat melakukan perubahan yang mengikuti
proses analisis perubahan formal. Dan yang dilakukan adalah memperbaiki secara
darurat terhadap program untuk memecahkan masalah secara langsung, tidak
melakukan modifikasi persyaratan dan desain, ini mempunyai bahaya bahwa
persyaratan, desain perangkat lunak, dan kode menjadi tidak konsisten. Walaupun
berniat dan diusahakan untuk mendokumentasikan perubahan ini , baik dalam
persyaratan dan desain, agar perbaikan darurat tambahan untuk yang akan datang
bisa dilakukan, biasanya sulit dilakukan, sebab perubahannya ini mengambil
prioritas di atas dokumentasi. Akhirnya, perubahan dari software yang asli
dilupakan dan dokumentasi sistem dan kode tidak pernah disesuaikan.
8.3 Dinamika Evolution
Dinamika evolusi terhadap program software adalah studi tentang perubahan
sistem. Pada 1970-an dan 1980-an, Lehman dan Belady (1985) melakukan
beberapa studi empiris perubahan sistem dengan maksud untuk memahami lebih
lanjut tentang karakteristik evolusi perangkat lunak. Pekerjaan dilanjutkan pada
1990-an sebagai Lehman dan lain-lain menyelidiki pentingnya umpan balik dalam
proses evolusi (Lehman, 1996;. Lehman et al, 1998;. Lehman et al, 2001). Dari
139
penelitian tersebut, mereka mengusulkan 'Hukum Lehman’ untuk melakukan
perubahan program yang menyangkut perubahan sistem (Gambar 9.7).
Tabel 8.1 Hukum Leman
Lehman dan Belady mengklaim bahwa persyaratan ini cenderung berlaku untuk
semua jenis sistem perangkat lunak, untuk organisasi besar (apa yang mereka
sebut sistem E-type). Pada hal ini, sistem di mana persyaratan berubah, adalah
untuk mencerminkan perubahan kebutuhan bisnis. Maka Rilis baru dari sistem
sangat penting untuk sistem, untuk memberikan perbaikan pada nilai bisnis.
Hukum pertama menyatakan bahwa pemeliharaan sistem adalah proses yang tak
terelakkan. Ini dikarenakan perubahan lingkungan sistem, persyaratan baru
muncul dan sistem harus diubah.
Ketika sistem dimodifikasi, dan diperkenalkan kembali ke lingkungan, ini akan
mempromosikan perubahan lingkungan lagi, ada yang lebih, maka menimbulkan
kebutuhan barulagi, sehingga proses evolusi dimulai lagi.
Hukum kedua menyatakan bahwa, sebagai suatu sistem berubah, struktur
terdegradasi. Satu-satunya cara untuk menghindari hal ini terjadi, adalah perlu
untuk berinvestasi dalam perawatan pencegahan. Bisa terjadi akan menghabiskan
waktu memperbaiki struktur perangkat lunak tanpa menambah fungsionalitas. Hai
140
ini jelas berarti ada biaya tambahan, untuk menerapkan perubahan sistem yang
diperlukan.
Hukum ketiga adalahyang paling menarik dan paling diperdebatkan dalam ‘hukum
Lehman’ ini, menunjukkan bahwa sistem yang besar memiliki dinamika mereka
sendiri, dinamuka ini dibentuk pada tahap awal dalam proses pembangunan. Ini
menentukan “tren kotor” dari proses pemeliharaan sistem dan membatasi jumlah
kemungkinan perubahan sistem.
Lehman dan Belady juga menunjukkan bahwa persyaratan ini merupakan
konsekuensi dari faktor-faktor struktural yang mempengaruhi, dan juga perubahan
pada sistem kendala, serta faktor organisasi yang mempengaruhi proses evolusi.
8.3.1 Software maintenance
Pemeliharaan perangkat lunak adalah proses umum mengubah sistem, setelah
software itu telah disampaikan ke pengguna. Istilah ini biasanya diterapkan untuk
perangkat lunak hasil kustom di mana kelompok pengembang terpisah.
Perubahan yang dibuat untuk perangkat lunak biasanya perubahan sederhana
untuk memperbaiki kesalahan coding, sedang perubahan yang lebih luas untuk
memperbaiki kesalahan desain, atau perangkat tambahan yang signifikan untuk
memperbaiki kesalahan spesifikasi atau mengakomodasi kebutuhan baru, relative
jarang.
Perubahan diimplementasikan dengan memodifikasi komponen sistem yang ada
dan, jika perlu, dengan menambahkan komponen baru ke sistem.
Ada tiga jenis perawatan perangkat lunak:
141
1. Perbaikan kesalahan Coding, kesalahan biasanya relatif murah untuk
memperbaiki; kesalahan desain lebih mahal karena mereka melibatkan menulis
ulang beberapa komponen program; Persyaratan kesalahan paling mahal, adalah
karena adanya desain ulang sistem yang ekstensif yang diperlukan.
2. Adaptasi Lingkungan, Jenis pemeliharaan ini diperlukan ketika beberapa aspek
dari lingkungan sistem seperti perangkat keras, sistem operasi platform atau
perubahan perangkat lunak pendukung lainnya ada perubahan. Sistem aplikasi
harus dimodifikasi untuk beradaptasi dalam rangka untuk mengatasi perubahan
lingkungan itu.
3. Fungsi penambahan, Jenis pemeliharaan ini diperlukan bila persyaratan sistem
berubah sebagai respons terhadap organisasi atau bisnis perubahan. Skala
perubahan yang diperlukan untuk perangkat lunak ini sering jauh lebih besar
daripada untuk pemeliharaan jenis lain.
Dalam prakteknya, tidak ada yang jelas perbedaan antara jenis pemeliharaan itu.
Bila untuk menyesuaikan sistem dengan lingkungan baru, dapat ditambahkan
fungsionalitas untuk mengambil keuntungan dari fitur lingkungan yang baru.
Kesalahan perangkat lunak sering terkena karena pengguna menggunakan sistem
dengan cara yang tak terduga. Mengubah sistem untuk mengakomodasi cara
mereka bekerja adalah cara terbaik untuk memperbaiki kesalahan ini.
8.3.2 Maintenance prediction
Manajer biasanya membenci kejutan, terutama jika kejutan itu menghasilkan biaya
tak terduga yang tinggi. Oleh karena itu kita harus mencoba untuk memprediksi,
perubahan sistem apa yang mungkin diusulkan dan bagian mana dari sistem
cenderung menjadi yang paling sulit untuk mempertahankan. Dan kita juga harus
mencoba untuk memperkirakan biaya pemeliharaan secara keseluruhan untuk
sistem dalam jangka waktu tertentu.
Gambar 9.10 menunjukkan cara-cara prediksi ini dan pertanyaan-pertanyaan
yang terkait.
Memprediksi jumlah permintaan perubahan untuk sistem, membutuhkan
pemahaman tentang hubungan antara sistem dan lingkungan eksternalnya.
Beberapa sistem memiliki hubungan yang sangat kompleks dengan lingkungan
142
eksternal, dan perubahan lingkungan yang pasti mengakibatkan perubahan pada
sistem.
Untuk mengevaluasi hubungan antara sistem dan lingkungannya, kita harus
menilai:
1. Jumlah dan kompleksitas sistem antarmuka. Semakin besar jumlah interface
dan keadaan yang lebih kompleks dari antarmuka ini, semakin besar kemungkinan
bahwa perubahan antarmuka akan diperlukan sebagai persyaratan baru yang
diusulkan.
2. Jumlah persyaratan sistem inheren stabil. Adalah persyaratan yang
mencerminkan kebijakan dan prosedur organisasi yang cenderung lebih stabil
daripada persyaratan yang didasarkan pada karakteristik domain yang stabil.
3. Proses bisnis di mana sistem ini digunakan. Sebagai proses bisnis berkembang,
mereka akan menghasilkan permintaan perubahan sistem. Semakin banyak
proses bisnis yang menggunakan sistem, semakin banyak tuntutan untuk
perubahan sistem.
Gambar 8.3 : prediksi akibat perubahan
Selama bertahun-tahun, para peneliti telah melihat hubungan antara kompleksitas
Program, yang diukur dengan metrik seperti kompleksitas cyclomatic (McCabe,
1976), dan rawatan (Banker et al, 1993;. Coleman et al, 1994;. Kafura dan Reddy,
1987 ; Kozlov et al, 2008).. Tidaklah mengherankan bahwa studi ini telah
menemukan bahwa sistem yang lebih kompleks atau komponen yang komplek,
sehingga semakin mahal hal itu untuk mempertahankannya. Pengukuran
143
kompleksitas sangat berguna dalam mengidentifikasi komponen program yang
cenderung mahal, ini untuk menjaga keadaan mendatang. Kafura dan Reddy
(1987) meneliti sejumlah komponen sistem dan menemukan bahwa upaya
pemeliharaan cenderung berfokus pada sejumlah kecil komponen kompleks.
Untuk mengurangi biaya pemeliharaan, harus mencoba untuk mengganti
komponen sistem yang kompleks itu dengan alternatif yang lebih sederhana.
Setelah sistem telah dimasukkan ke dalam operasi layanan, kita dapat
menggunakan data proses untuk membantu memprediksi pemeliharaan. Contoh
metrik proses yang dapat digunakan untuk menilai perawatan adalah sebagai
berikut:
1. Jumlah permintaan untuk pemeliharaan korektif. Peningkatan jumlah bug dan
kegagalan laporan menunjukkan bahwa lebih banyak kesalahan yang
diperkenalkan yang ada dalam program daripada yang sedang diperbaiki selama
proses pemeliharaan. Ini menunjukkan penurunan perawatan.
2. Rata-rata waktu yang diperlukan untuk analisis dampak, ini mencerminkan
jumlah komponen program yang dipengaruhi oleh permintaan perubahan. Jika
saat ini meningkat, itu berarti semakin banyak komponen yang terpengaruh dan
pemeliharaan menurun.
3. Rata-rata waktu yang dibutuhkan untuk melaksanakan permintaan. Perubahan
ini tidak sama dengan waktu untuk analisis dampak, meskipun mungkin
berkorelasi dengan hal itu. Ini adalah jumlah waktu yang dibutuhkan untuk
mengubah sistem dan melakukan dokumentasi, setelah menilai komponen yang
terpengaruh. Peningkatan waktu yang dibutuhkan untuk mengimplementasikan
perubahan mungkin menunjukkan penurunan perawatan.
4. Jumlah perubahan yang luar biasa permintaannya. Peningkatan jumlah ini dari
waktu ke waktu menyiratkan penurunan perawatan. Menggunakan diprediksi
informasi tentang permintaan perubahan dan prediksi tentang sistem
pemeliharaan untuk memprediksi biaya pemeliharaan.
Kebanyakan manajer menggabungkan informasi ini dengan intuisi dan
pengalaman untuk memperkirakan biaya. Model estimasi ‘The COCOMO 2’ , untuk
estimasi biaya (Boehm et al., 2000), menunjukkan bahwa perkiraan untuk usaha
144
pemeliharaan perangkat lunak dapat didasarkan pada upaya untuk memahami
kode yang ada, dan upaya untuk mengembangkan kode baru.
8.3.3 Software reengineering
Untuk membuat sistem perangkat lunak hasil warisan agar lebih mudah untuk
mempertahankan, kita harus dapat merekayasa ulang sistem ini, usaha ini untuk
memperbaiki struktur dan dimengerti software itu. Hal ini disebut sebagai software
reengineering.
Reengineering mungkin melibatkan redocumenting sistem, refactoring arsitektur
sistem, menerjemahkan program untuk bahasa pemrograman modern, dan
memodifikasi serta memperbarui struktur dan nilai-nilai data sistem. Fungsi dari
software ini tidak berubah, biasanya kita harus menghindari membuat perubahan
besar pada arsitektur sistem.
Ada dua manfaat penting dari rekayasa ulang ini, bukan melakukan penggantian:
1. Mengurangi risiko. Ada risiko tinggi dalam pembangunan kembali software
bisnis penting. Karena kesalahan dapat dilakukan dalam sistem spesifikasi atau
mungkin ada masalah pada pembangunan. Keterlambatan dalam
memperkenalkan perangkat lunak baru dapat berarti ada kesempatan bisnis yang
hilang dan biaya tambahan yang dikeluarkan.
2. Mengurangi biaya. Biaya rekayasa ulang dapat secara signifikan kurang dari
biaya pengembangan perangkat lunak baru. Mengutip contoh dari sistem
komersial yang biaya implementasi ulang diperkirakan mencapai $ 50 juta. Sistem
ini berhasil direkayasa ulang sebesar $ 12 juta. Dengan teknologi perangkat lunak
modern, biaya relative untuk implementasi ulang mungkin bisa kurang dari ini,
yang jelas masih akan jauh murah untuk biaya rekayasa ulang.
Gambar 9.11 adalah model umum dari proses rekayasa ulang. Input ke proses
adalah program warisan dan output adalah versi perbaikan dan direstrukturisasi
dari program
145
Gambar 8.4 : Reengineering
Kegiatan dalam proses rekayasa ulang ini adalah sebagai berikut:
1. Sumber Menggunakan alat terjemahan, program ini dikonversi dari bahasa
pemrograman lama ke versi yang lebih modern dari bahasa yang sama atau
bahasa yang berbeda.
2. reverse engineering Program ini dianalisis dan informasi yang diambil dari itu.
Hal ini membantu untuk mendokumentasikan organisasi dan fungsi. Sekali lagi,
proses ini biasanya sepenuhnya otomatis.
3. Peningkatan Struktur Program Struktur kontrol program dianalisis dan
dimodifikasi untuk membuatnya lebih mudah untuk membaca dan memahami. Hal
ini sebagian dapat otomatis tetapi beberapa intervensi manual biasanya
diperlukan.
4. bagian Program modularisasi terkait program dikelompokkan bersama-sama
dan, bila perlu, redundansi dihapus. Dalam beberapa kasus, tahap ini mungkin
melibatkan refactoring arsitektur (misalnya, sebuah sistem yang menggunakan
beberapa toko data yang berbeda dapat refactored untuk menggunakan repositori
tunggal). Ini adalah proses manual.
5. data rekayasa ulang data diproses oleh program ini diubah untuk mencerminkan
perubahan program. Ini mungkin berarti mendefinisikan ulang skema database
dan mengkonversi database yang ada dengan struktur baru. Anda harus biasanya
juga membersihkan data. Hal ini melibatkan menemukan dan memperbaiki
kesalahan, menghapus catatan duplikat, dll Peralatan yang tersedia untuk
mendukung data reengineering.
Program rekayasa ulang mungkin tidak selalu membutuhkan semua langkah, tidak
perlu ada terjemahan kode sumber jika masih menggunakan bahasa
146
pemrograman aplikasi yang sama. Jika dapat melakukan semua rekayasa ulang
secara otomatis, kemudian memulihkan dokumentasi melalui reverse engineering,
tidak diperlukan usaha yang besar. Data rekayasa ulang hanya diperlukan jika
struktur data ada dalam perubahan program yang selama sistem dalam rekayasa
ulang.
Untuk membuat sistem yang direkayasa ulang dapat beroperasi dengan suatu
perangkat lunak baru (software yang baru), harus mengembangkan layanan
adaptor, untuk menyembunyikan interface asli dari sistem software dan perangkat
lunak yang baru, sehingga terjadi suatu interface yang terstruktur-baik yang dapat
digunakan oleh komponen lainnya. Proses pada sistem warisan ini berarti ada
pembungkus, yang berarti juga adalah teknik penting untuk bisa mengembangkan
layanan, yang dapat digunakan kembali dalam skala yang besar.
147
Index A acceptance testing, 42, 70, activities (software engineering activities), 6, 9, activity diagrams (UML), 19, 29 Adaptive Software Development, 59, 80 aggregation, agile methods, 29, 56–81 architectural design and, 14 agile modeling, 59, 80, alpha testing, 42, 22 ambiguity, measurements and, 77, analysis and design workflow, 52 Analyze, Measure, Improve (AMI) method, 71 application system architectures, 64–71, 72 assessment, 25 application frameworks, 31–34, 448 architectural description languages (ADLs), 154 architectural design, 3 architectural modeling, architectural patterns (styles), arrays, unbounded, aspect-oriented design and programming, assertion checking, assets, assurance (dependability/security assurance), assessment (security requirements), 33 attributes, of software, 6, 8, 24 auditable processes, 36 authentication requirements, 39 authorization requirements, 32 automated activities, 37 automated testing, 42, 69, 70, 77 automatic static analysis, 39–40 availability (system availability), 95–99 avoidance
B baselines, 684, 690 batch processing systems, 11, 163 behavioral models, 133–38, 143 beta testing, 42, 228 black-box testing, 215 block diagrams, 150, 179 Boehm’s spiral model. See spiral models boundaries (system boundaries), brainstorming, 314, 598 broadcast models, bug fixing, build script generation, business-critical systems, businesses business process models, business risks, business services,
C callbacks, 43 CASE (Computer-Aided Software Engineering) tools, catalog interface design, catalog service operations, CBSE. See component-based software engineering centralized control, change, 43–45. change avoidance, 44 change control board (CCB), change implementation, change management, change persistence, change proposals, change tolerance, characteristic error checking, checking requirements (functional reliability checklists) Chidamber and Kemerer’s (CK) metrics suite,
CIMs (computation independent models), class diagrams, Cleanroom process, client-server systems, CM. See configuration management CMMI process improvement framework, CMM Maturity model. See People Capability Maturity COCOMO II model, codelines, collective ownership, commercial-off-the-shelf systems. See COTS communications (process analysis), 716 compartmentalization, 384 competence, 14 compilers, completeness, complex systems, component analysis (reuse-based development), component-based software engineering (CBSE) components (software components), 35–36 composition, 6 Computer-Aided Software Engineering tools. See CASE tools concept reuse, conceptual views, 1 concern-oriented requirements engineering, 57 confidentiality, 14 configuration control, configuration item, configuration management (CM), consistency, construction phase consumer/producer processes (circular buffer), context models, contingency plans (risk management), Controller component (MVC), 5 control/predictor measurements, CORBA (Common Object Request Broker costs. See also estimation techniques COTS (commercial-off-the-shelf) systems, CRF (change request form), critical systems critical systems engineering, Crystal, customer involvement (agile methods), 60, 62, 65 customization component model and, 45 cyclomatic complexity, 72,
D damage limitation, 302, 319 data acquisition systems, 553, 554, 560, 569 database design, 40 database support (WAFs), 433 data clumping, 251 data collection system architecture data collection systems, 11 data-driven modeling, 134–35 data-flow diagrams (DFDs), 134 data management and communications layer, data mining, data reengineering, debugging, decentralized P2P architecture, defect testing, 41 demands, software failures and, 4 DeMarco’s Structured Analysis, denial of service attacks, dependability (software dependability), dependable operational processes, dependable programming guidelines, dependable software processes, dependable system architectures, deployment deployment-time configuration, 439–40 derivation history, 689 design (software design), 24, 28, design description languages, 95
148
design refactoring, deterministic system, DFDs (data-flow diagrams), distributed architectures, distributed component architectures, distributed software engineering, distributed systems, diversity documentation, 5, 24, dose checking test case, 69, 70 driver verification system, DSDM, 57, 59, 81 duplicate code, 68, 251 dynamic memory allocation, dynamic perspective (RUP), 50 dynamic web pages,
E early design model, 39–40 efficiency, 8, 12, 24 elaboration phase (RUP), 51 elicitation/analysis (requirements elicitation/analysis), embedded software systems, 11, 17–18, embedded systems design, 5–47 embrace change (agile manifesto), 60 emergent system properties, enduring requirements, enterprise application frameworks, Enterprise Resource Planning systems. See ERP entertainment systems, 11 entity-oriented services, environmental adaptation, 3–44 Environmental Control pattern, environment assessment, CASE tools and, 37, 58, environment workflows, 52 equipment inventory system, equity trading system, equivalence partitioning, 214–15 ergonomics, systems engineering and, 275 ERP (Enterprise Resource Planning) errors error tolerance, 293 esteem needs, 604 estimation risks, 598, 599 estimation techniques (project planning), 633–46 experience-based techniques, 634 ethical/professional responsibility, 14–17, 2 E-type systems, 240 event-based controls, 164 event-driven modeling, 135–38 event metrics, 711–12, 729 evolution (software evolution), 6, 9, 24, 28, 43, executable system creation, 695 Executable UML (xUML), 142 experience-based techniques (estimation techniques), 634 experience-based testing, 405 explicit security policies, 380–81 exposure, 3 exposure assessment (security requirements), exposure limitation and recovery, 305 extensions, core systems with, 576–77 external requirements, 88–89 extreme programming (XP), 64–72, 77
F failure propagation, 27 failures fat-client model, 49 fault (system faults), 29 fault tree analysis, 17–19, 36 feasibility assessment (security requirements), 31 feasibility studies, 37, 10 floating-point numbers, 59 formal logic (hazard analysis), 17
formal methods (software development), formal verification, 34, 39, functional emergent properties, 26–71 functional reliability specification, 32 functional requirements, 84–87, functional specialization (software product lines), function reuse, 42
G generalization 131–33, 185–6, 190, 201 generator-based reuse, 431 generic development process, 53, 178 generic software products, 6–7 glue code, 468, 469, 476 GNU build system, 196 GNU General Public License (GPL), 200 growth modeling, reliability, 402–3 guideline-based testing, 213 guidelines
H handlers, exceptions, hardware reliability, hazard, hazard-driven approach to requirements derivation, heterogeneity challenge, 10 high-availability systems, high speed data acquisition systems, honesty (people management), host-target development, human errors, human needs hierarchy,
I identification requirements, 329 IDEs (Interactive Development Environments) ECLIPSE environment and, 37, 68, 80, 197, 204, IEC (International Electrotechnical Commission) implementation (system implementation), improvement identification and prioritization in-car information system, 512–13 inception phase (RUP), 50–51 incremental delivery, 34, 44, 47–48, 60 incremental development, 30, 32–34, 5 incremental integration, testing and, 219 incremental planning (XP), 66 independent development, 691 informal safety argument (insulin pump), 416–17 information systems, 18, 167–69 inheritance, 13,12, 67 input/output mapping, input/output messages (UML), 524 input processing, default, 360–61 inputs, validity checks of, 356–57, 383 insider attacks, 369 inspection checklist, 667 inspections, 208–9, 218, 585, 663– informal safety argument and, 416–17 integration, reuse and, 35 integrity requirements, 329 intellectual property rights, 14 interaction models, 124–28, 179–81, 485–86 interaction-oriented people, 606 Interactive Development Environments. See IDEs interactive transaction-based applications, 11 interception, 483 interface design, 39, 188, 189 interface misunderstanding, 217 interface misuse, 217 interface specification, 188–89 interface testing, 217 internal/external software relationships, 670 International Electrotechnical Commission (IEC) Internet banking system, 494 Internet worm, 305, 308, 383, 392 interpreting measurements, 676–77, 713
149
interrupts, 360, 483 interviewing, 104–5, 715 intolerable risks, 315 introspection (process analysis), 716 intrusion detection requirements, 330 inventory management system, 581 inversion of control, in frameworks, 434 ISO 92001 standards framework, 660–63 iterative development/delivery, 45, 52, 53 Iterator pattern, 192
J Java join points, JUnit,
L language processing systems, layered architecture pattern, 15 layered protection architecture, learning (process analysis), legacy systems Lehman’s laws, Lesser General Public License, GNU, licensing life cycles Linux, logical view, logs, 35
M maintainability, 8, 18, 24, 9 maintenance (software maintenance), 8, 24, 43, malware, 14, 290, 501 management (software management), 12, 24 management; process improvement; project management; project planning; quality manifesto, agile, 56, 59, 60, 141, 688, 708 master-slave architectures, 490–91 mathematical specifications, 95. See also formal methods. MDA. See model-driven architecture MDD. See model-driven development MDE. See model-driven engineering measurement. See also metrics medical records system. See MHC-PMS Mental Health Care-Patient Management System. See MHC-PMS message passing interfaces, 217 metrics middleware, 19 minimization strategies (risk management), 601 model checking, 34, 39 Model component (MVC), 155 model-driven architecture (MDA), 138–41 model-driven development (MDD), 40 model-driven engineering (MDE), 138–42, models, 11, 95, 118–46 Model-View-Controller. See MVC modification attack, 483 modification timestamps, 696 motivation (people management), 603–7 multi-tier client-server architectures, 493–95 MVC (Model-View-Controller), MySQL, 199, 433
N natural language specification, 94, 96–97 .NET framework, 36, 14 neutron flux data acquisition, 554 non-determinism, 268, 271–72, 282 non-functional non-repudiation requirements, 330 nuclear systems, 17 N-version programming, 95, 352–53
O object classes, 182–84, 189 object constraint language (OCL), 14, 4 objective setting (spiral model), 49 object level reuse, Object Management Group (OMG), object-oriented design, open source development, 19–20, 22 operational profiles, 22, 40 operation incompatibility, 46 operation incompleteness, 46 operation/maintenance (life-cycle phase), operation stage (sociotechnical systems), organizational constraints (process analysis), organizational design patterns, organizational requirements, organizational risks, overhead costs,
P p2p architectures. See peer-to-peer architectures pair programming, 66, 71–72 parallelism, 360 parameter incompatibility, 469 parameter interfaces, 16 partition testing, 23–15 password checkers, 40 path testing, 21 patient information system. See MHC-PMS patterns (design patterns), peer-to-peer (p2p) architectures, People Capability Maturity Model (P-CMM), people management, 595, 602–7 performance Petri net analysis, 31 PIMs (platform independent models), 140, 141 pipe and filter compiler architecture, 170, 171 pipe and filter pattern, plan-driven development processes, project planning and, platform independent models (PIMs), 140, 141 platform-level protection, 377, 378 platform specialization (software product lines) platform specific models (PSMs), 140, 141 pointers, polymorphism, post-architecture model, 642–45 post/pre-conditions (software processes), 28 practice perspective prediction, maintenance, 246–48 preliminary risk analysis, 312, 330 pre/post-conditions (software processes), 28 preventative maintenance. See refactoring primary safety-critical software, 300 privacy probability of failure on demand problem tracking, procedural interfaces, process (software processes), 12, 27–55 Process Pipeline pattern, procurement/acquisition stage (sociotechnical systems), producer-consumer pattern, product instance development, productivity, software, professional/ethical responsibility, professional software development. program architectures. See application architectures program evolution dynamics, 240–42 program generators, 430 program inspections, 208–9, 21 program libraries, 43 programmer/tester pairs, 210–11 programming. See also extreme programming program structure improvement, 249
150
project duration/staffing (COCOMO II), 645–46 project management, 593–617 project planning, 595, 618–50 plan-driven development and, 623–26 project plans, 623–24 project risks, 596–97 proposal writing, 595 protection architecture, layered, 378 protection systems, 349–50
prototyping (system prototyping), 44, 45–46, 53, 109,
Q QoS. See quality of service
quality management, 651–80 quality of service (QoS), 484, 504 quality of service extensions, 576 quantitative reliability specifications, 324–26 questionnaires, 714, 715
R rapid software development, rate of occurrence of failure (ROCOF), Rational Unified Process. See RUP real-time operating systems (RTOS), real-time systems, reasonableness checks, recognition strategy (survivability), recoverability, design for, recovery strategy (survivability), recursion, redundancy, diversity and, reengineering (software reengineering), refactoring, reference architectures, regression testing, regulation, of software, release management, release testing, reliability (system reliability), requirements, remote procedure calls (RPCs), repairability, replicated architectures, reporting, repository architectural pattern, representation checks, requirements (software requirements), 12, 83 reviews, 11 risks, requirements engineering, 6, 9, 12, 24, resistance strategy (survivability), resource allocation system, architecture of, resource management systems, 7–69, 17 resource utilization metrics, respect (people management), responsibility, ethical/professional, restart capabilities, RESTful services, reuse (software reuse), 12, 24, reuse model (COCOMO II), reuse-oriented software engineering, reverse engineering, reviews, review process, rework, risk, robustness (process characteristic), roles (software processes), 28 RPCs (remote procedure calls), RTOS. See real-time operating systems Ruby, 12, RUP (Rational Unified Process),
S SaaS. See software as a service
safety, safety-critical systems and, 300 secure, 38 software failures and, 65 security risk management and, 330 specification, safety claim hierarchy safety-critical systems, safety needs (human needs hierarchy), SAP, scenario-based analysis, scenarios, schedule representation, scheduling (project planning), SCI (software configuration item), Scrum, secure deployment, secure systems design, security, specification, self-monitoring architectures, 52 self-oriented people, self-realization needs, semantic data models, semicentralized P2P architecture, sensor-based data collection systems, 18 separation of concerns, sequence diagrams, service engineering process, service implementation/deployment, service interface design, service interfaces, service-oriented architectures (SOAs), services, servicing, shared memory interfaces, simplicity (agile methods), simulation, simulators, single point of failure (avoidance), SOAs. See service-oriented architectures social needs, sociotechnical systems, Software CMM Maturity model, software component analysis, software components. software configuration item (SCI), ‘software crisis’, software development tools. See CASE tools software diversity, software engineering software life cycle, 30–32. See also waterfall model software measurement/metrics, 668–77 software pricing (project planning), 621–23 software processes. See processes software productivity, 638 software product lines, 434–40, 448 software reengineering. See reengineering software reliability. See reliability software requirements specification (SRS) software reuse. See reuse software systems. See systems source code checksums, source code translation, specifications (software specifications), 6, 9, spiral models, 48–50, sprints (Scrum), 73, 78, 665 SQL (Structured Query Language), SQL poisoning attack, SRS (software requirements specification), staff allocation chart, staged CMMI model, stand-alone applications, Statecharts, state diagrams (UML), static analysis, static analyzers, static models, static perspective (RUP), 50 static software product metrics, static verification, statistical testing,
151
stimulus/response (embedded systems), –41 storage management, story cards, stress testing, structural models, structural testing, structured analysis methods, 100, 134 structured arguments, 411–13, 418 structured design methods, 40, 178 structured natural language, 95 Structured Query Language. See SQL structured specifications, subsystem models, 185, 186 subsystems, 267 success criteria (sociotechnical systems), survivability, 293, 386–90 Survivable Systems Analysis, sustainable pace (XP), 66 system architectures, 348–55 system availability. See availability system boundaries, system building, system deployment, system design, system development, system documentation. See documentation system evolution, system errors and, system faults, system infrastructure frameworks, system integration, system level (reuse), system maintenance security requirements, 330 system modeling. See models system operation, system procurement (system acquisition), 27 system requirements, systems (software systems). systems approach (human errors), system security design, 375–86 systems engineering, 6, 9, 26 Systems Engineering Capability Model, system specification (V-spec), system testing, 42,
T task cards, task-oriented people, task-oriented services, team spirit (case study), teamwork, technology risks, test automation, test case test-driven development (TDD), test-first development, testing (software testing), test planning, 27 thin-client model, 2 threat identification (security requirements), threats, timing analysis (real-time systems), timing errors, TMR (triple modular redundancy), tool-based checking, tool support (process analysis), traceability (requirements traceability), traffic management system, 491 transaction processing systems, transformational development process, 396 transition phase (RUP), 51 translation tools, 37, 140, 141, 249 triple modular redundancy (TMR), 352 trust, 8, 10, 291–92 two-tier client-server architectures, 492–93
U UML (Unified Modeling Language) unbounded arrays, 360 Unified Modeling Language. See UML Unified Software Development Process, 50, 55 unit testing, Universal Description, Discovery, and Integration (UDDI), universal resource identifiers (URIs), URIs (universal resource identifiers), usability use cases, user actions, logging, 33 user-defined error checking, user interaction (WAFs), user interface design, 45, user requirements, user stories, user testing, utility services,
V vacation package workflow, 528 validation (software validation), 6, 9, 24, 28, verification v., 206–7 validity checks, 110, 356–57, 383 vehicle dispatcher system, 437 verifiability, 110 verification (software verification) validation v., version instance, version management (VM), version repository, vertical software packages, View component (MVC), viewpoints, views, architectural, viruses, visualizer components, VM. See version management volatile requirements, VOLERE requirements engineering method, V-spec, V & V (verification and validation),
W waterfall model, 29, 30–32, 53 weather information system, 22 weather stations. See wilderness weather stations weaving (AOSE), 572 web application frameworks (WAFs), web-based systems, 13–14 Web Service Definition Language. white-box testing, 585, 586 wicked problems, 111, 272, 287 wilderness weather stations, 22–23 Wizard of Oz prototype, 46 work environments, 613 workflows, 51–52, 529–33 workspace, 684 worms,
WSDL (Web Service Definition Language),
X XML, 510 XML-based protocols, 509 XP. See extreme programming xUML (Executable UML), 142
Z zero-defects software, 32, 396
152
Glossary
architectural pattern (style) Deskripsi arsitektur perangkat lunak yang dicoba dan diuji di sejumlah sistem perangkat lunak yang berbeda-beda. Pola deskripsi arsitektur meliputi informasi tentang penggunaan pola dan pengorganisasian komponen arsitektur. Availability Kesiapan sistem untuk memberikan layanan ketika diminta. Ketersediaan biasanya dinyatakan sebagai angka desimal, sehingga ketersediaan dari 0.999 berarti bahwa sistem dapat memberikan layanan 999 dari 1.000 unit waktu. bar chart Sebuah grafik yang digunakan oleh manajer proyek untuk menunjukkan tugas-tugas proyek, jadwal terkait dengan tugas itu, serta orang yang melaksanakan/bekerja aktivitas itu, yang ditunjukkan kapan awal tugas dan kapan mengakhiri. black-box testing Sebuah pendekatan untuk pengujian, dimana penguji tidak memiliki akses ke kode program sistem atau komponen-komponennya. Tes tersebut dilakukan berdasar dari spesifikasi sistem. C Bahasa pemrograman yang pada awalnya dikembangkan untuk melaksanakan sistem Unix. C adalah Bahasa untuk implementasi sistem dengan bahasa tingkat rendah, yang memungkinkan akses untuk ke perangkat keras dan yang dapat dikompilasi ke kode dengan efisien. Hal ini banyak digunakan untuk pemrograman sistem tingkat rendah dan pengembangan embedded system. C++ Sebuah bahasa pemrograman berorientasi objek yang merupakan superset dari C.. CASE (Computer-Aided Software Engineering) Proses pengembangan perangkat lunak menggunakan bantuan/dukungan yang otomatis. class diagram diagram UML, diagram yang menunjukkan kelas, objek dalam sistem dan hubungan mereka. client–server architecture Model arsitektur untuk sistem terdistribusi di mana fungsi sistem ditawarkan sebagai satu set layanan yang disediakan oleh server. Server ini diakses oleh klien komputer yang memanfaatkan layanan. Cleanroom software engineering Sebuah pendekatan untuk pengembangan perangkat lunak di mana tujuannya adalah untuk menghindari adanya kesalahan dalam membangun perangkat lunak (analogi dengan Cleanroom digunakan dalam fabrikasi semikonduktor). Proses ini melibatkan spesifikasi perangkat lunak formal, transformasi terstruktur dari spesifikasi untuk sebuah program, pengembangan argumen kebenaran, dan statistic program pengujian. cloud computing Penyediaan komputasi dan / atau aplikasi layanan melalui Internet menggunakan 'Awan' server dari penyedia eksternal. 'Awan' disini adalah server dan network diimplementasikan menggunakan sejumlah besar komputer komoditas dan teknologi virtualisasi untuk membuat penggunaan yang efektif dari sistem ini. component-based software engineering (CBSE) Pengembangan perangkat lunak dengan menyusun independen, komponen software deployable yang konsisten dengan model komponen. configuration item Sebuah unit terkecil yang dapat dianggap mesin, bisa dokumen atau file kode program, yang tunduk, dan dapat dirubah di mana perubahan telah dikontrol oleh manajemen konfigurasi. configuration management- manajemen konfigurasi Proses pengelolaan perubahan pada produk perangkat lunak yang berkembang, Manajemen konfigurasi melibatkan perencanaan konfigurasi, manajemen versi, membangun sistem, dan manajemen perubahan. Constructive Cost Modeling (COCOMO) Sebuah keluarga model estimasi biaya jenis algoritmik. COCOMO pertama kali diusulkan pada awal 1980-an dan telah dimodifikasi dan diperbarui sejak itu, mencerminkan teknologi baru dan mengubah praktek rekayasa perangkat lunak. distributed system Sistem perangkat lunak di mana subsistem perangkat lunak atau komponen dieksekusi pada prosessor berbeda. domain Sebuah masalah khusus atau area bisnis dimana sistem perangkat lunak digunakan. Contoh domain yang termasuk kontrol real-time, pengolahan data bisnis, dan telekomunikasi sistem switching. event-based systems Sistem di mana kontrol operasi ditentukan oleh peristiwa yang dihasilkan dalam lingkungan sistem. Kebanyakan sistem real-time adalah sistem berbasis event. extreme programming (XP) Sebuah proses pengembangan software dengan digunakan metode tangkas, pengembangan perangkat lunak yang menggunakan praktek-praktek tersebut denagan persyaratan berbasis skenario, pengembangan pola test first, dan pair programmig. fault tolerance Kemampuan sistem untuk melanjutkan eksekusi walaupun setelah ada kesalahan terjadi. formal methods Metode pengembangan perangkat lunak, dimana perangkat lunak dimodelkan menggunakan konstruksi matematika resmi, transformasi Formal ini mengkonversi model ke kode. Metode ini banyak digunakan dalam membuat spesifikasi dan pengembangan sistem yang kritis. Gantt chart Nama alternative dari bar chart. incremental development-pembangunan inkremental
153
Sebuah pendekatan dalam pengembangan perangkat lunak di mana perangkat lunak disampaikan dan disebarkan secara bertahap. iterative development-pengembangan berulang Sebuah pendekatan untuk pengembangan perangkat lunak di mana proses spesifikasi, desain, pemrograman, dan pengujian yang disisipkan, dilakukan berulang. J2EE Java 2 Platform Enterprise Edition. Sebuah sistem middleware kompleks yang mendukung pengembangan aplikasi web berbasis komponen di Bahasa Java. Termasuk didalamnya komponen model untuk komponen Java, API, dll. Java Bahasa pemrograman yang sudah luas, digunakan untuk pemrograman berorientasi objek yang dirancang oleh Sun dengan tujuan independensi platform. maintenance Proses pembuatan perubahan ke sistem setelah aplikasi itu telah masuk dalam operasi. mean time to failure (MTTF) Rata-rata waktu antara kegagalan sistem yang diamati; digunakan dalam spesifikasi keandalan. object-oriented (OO) development Sebuah pendekatan untuk pengembangan perangkat lunak di mana abstraksi fundamental dalam Sistem adalah obyek independen. Jenis abstraksi yang sama digunakan selama spesifikasi, desain dan pengembangan open source Sebuah pendekatan untuk pengembangan perangkat lunak di mana kode sumber untuk sistem dibuat oleh pengguna, publik dan eksternal didorong untuk berpartisipasi dalam pengembangan sistem. pair programming Sebuah situasi pembangunan software di mana programmer bekerja berpasangan, bukan secara individual, untuk mengembangkan kode; ini bagian mendasar dari cara pemrograman ekstrim.. program inspection Sebuah review di mana sekelompok inspektur memeriksa program, baris demi baris, dengan tujuan mendeteksi kesalahan program. Pemeriksaan sering digunakan dengan checklist, untuk mendapatkan kesalahan pemrograman. quality assurance (QA)- jaminan kualitas (QA) Proses keseluruhan mendefinisikan bagaimana kualitas perangkat lunak dapat dicapai dan bagaimana organisasi pengembangan perangkat lunak tahu bahwa perangkat lunak telah memenuhi tingkat kualitas yang diperlukan. quality plan - rencana mutu Sebuah rencana yang mendefinisikan kualitas proses dan prosedur yang harus digunakan. ini melibatkan cara memilih dan mendapatakan isi standar untuk produk dan proses, dan mendefinisikan atribut kualitas sistem yang paling penting. reengineering Modifikasi sistem perangkat lunak untuk membuat lebih mudah untuk dipahami dan diubah. Reengineering ini bisa melibatkan perangkat lunak, data restrukturisasi, organisasi, penyederhanaan Program, dan redocumentation. reengineering, business process Mengubah proses bisnis untuk memenuhi tujuan organisasi baru seperti mengurangi biaya dan eksekusi lebih cepat. requirements management proses pengelolaan perubahan persyaratan, untuk memastikan bahwa perubahan yang dibuat telah dianalisis dengan benar dan dilacak melalui sistem. scenario Penjelasan tentang satu cara yang khas, menggunakan diagram di mana sistem yang digunakan atau pengguna melakukan beberapa aktivitas. sequence diagram Sebuah diagram yang menunjukkan urutan interaksi yang diperlukan untuk menyelesaikan beberapa operasi. Dalam UML, diagram urutan dapat berhubungan dengan kasus yang digunakan. software architecture Sebuah model struktur dasar dan organisasi sistem perangkat lunak. software life cycle Sering digunakan sebagai nama lain untuk proses pengembangan perangkat lunak; awalnya diciptakan untuk merujuk kepada model waterfalls yang ada dari proses perangkat lunak. spiral model Sebuah model proses pembangunan di mana proses ini direpresentasikan sebagai spiral, dengan setiap putaran spiral menggabungkan berbagai tahap dalam proses. Ketika anda bergerak dari satu putaran spiral ke yang lain, anda mengulangi semua tahapan proses. state diagram Sebuah Jenis diagram UML yang menunjukkan keadaan sistem dan peristiwa yang memicu transisi dari satu keadaan ke keadaan lain. test-driven development Sebuah pendekatan untuk pengembangan perangkat lunak di mana tes executable yang ditulis sebelum kode program. Himpunan tes dijalankan secara otomatis setelah perubahan ke program. Unified Modeling Language (UML) Sebuah bahasa grafis yang digunakan dalam pengembangan berorientasi objek yang mencakup beberapa jenis model sistem yang memberikan pandangan yang berbeda dari suatu sistem. UML menjadi standar de facto untuk pemodelan berorientasi objek. use case Sebuah spesifikasi satu jenis interaksi dengan sistem. user interface design Proses perancangan cara di mana pengguna sistem dapat mengakses fungsi sistem, dan cara bahwa informasi yang dihasilkan oleh sistem akan ditampilkan. Validation-pengesahan
154
Proses memeriksa bahwa sistem memenuhi kebutuhan dan harapan pelanggan.. verification Proses memeriksa bahwa sistem apakah memenuhi spesifikasinya waterfall model Sebuah model proses perangkat lunak yang melibatkan tahap perkembangan diskrit: spesifikasi, desain, implementasi, pengujian, dan pemeliharaan. Pada prinsipnya, satu tahap harus lengkap sebelum maju ke tahap berikutnya white-box testing Sebuah pendekatan untuk pengujian program, dimana tes didasarkan pada pengetahuan tentang struktur program dan komponen-komponennya. Akses ke kode sumber sangat penting untuk pengujian white box testing ini. workflow Definisi detail tentang proses bisnis yang dimaksudkan untuk mencapai suatu tugas tertentu. Alur kerja biasanya dinyatakan dalam bentuk grafis dan menunjukkan kegiatan proses individu dan informasi yang diproduksi dan dikonsumsi oleh masing-masing aktivitas. WSDL An XML-based notation untuk mendfinisikan interface pada web services. XML Extended Markup Language. XML adalah bahasa markup teks yang mendukung pertukaran data terstruktur. Setiap field data dibatasi oleh tag yang memberikan informasi tentang bidang itu. XML sekarang sangat banyak digunakan dan telah menjadi dasar protokol untuk layanan web. XP Singkatan Extreme Programming. Z Dasar Model, formal specification language yang di developed di University of Oxford di England.
155
Referensi Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach, 2d ed.,Addison-Wesley, 2008. Jalote, P., An Integrated Approach to Software Engineering, Springer, 2006.
Pfleeger, S., Software Engineering: Theory and Practice, 3d ed., Prentice-Hall, 2005.
Schach, S., Object-Oriented and Classical Software Engineering, 7th ed., McGraw-Hill, 2006.
Sommerville, I., Software Engineering, 8th ed., Addison-Wesley, 2006. Tsui, F., and O. Karam, Essentials of Software Engineering, Jones & Bartlett Publishers, 2006.
Boehm, B. and Turner, R. (2003). Balancing Agility and Discipline: A Guide for the Perplexed. Boston: Addison-Wesley.
Budgen, D. (2003). Software Design (2nd Edition). Harlow, UK.: Addison-Wesley.
Krutchen, P. (2003). The Rational Unified Process—An Introduction (3rd Edition). Reading, MA:Addison-Wesley. Rettig, M. (1994). ‘Practical Programmer: Prototyping for Tiny Fingers’. Comm. ACM, 37 (4), 21–7.
Rumbaugh, J., Jacobson, I. and Booch, G. (1999). The Unified Software Development Process. Addison-Wesley.
Pressman, Roger S., Software engineering : a practitioner’s approach / Roger S. Pressman. — 7th ed.,2010
Schmidt, D. C. (2006). ‘Model-Driven Engineering’. IEEE Computer, 39 (2), 25–31. Beck, K. (2000). extreme Programming explained. Reading, Mass.: Addison-Wesley.
Cockburn, A. (2001). Agile Software Development. Reading, Mass.: Addison-Wesley.
Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams. Boston: Addison-Wesley. Cohn, M. (2009). Succeeding with Agile: Software Development Using Scrum. Boston:Addison-Wesley.
Demarco, T. and Boehm, B. (2002). ‘The Agile Methods Fray’. IEEE Computer, 35 (6), 90–2.
Denning, P. J., Gunderson, C. and Hayes-Roth, R. (2008). ‘Evolutionary System Development’. Comm. ACM,.
Drobna, J., Noftz, D. and Raghu, R. (2004). ‘Piloting XP on Four Mission-Critical Projects’. IEEE Software, 21 (6), Hopkins, R. and Jenkins, K. (2008). Eating the IT Elephant: Moving from Greenfield
S. Robertson and J. Robertson, 2006, Addison-Wesley ;Mastering the Requirements Process, 2nd edition.
B. H. C. Cheng and J. M. Atlee, Proc. Conf on Future of Software Engineering,
Rumbaugh, J., Jacobson, I. and Booch, G. (2004). The Unified Modeling Language Reference Manual, 2nd ed. Boston: Addison-Wesley.
Schmidt, D. C. (2006). ‘Model-Driven Engineering’. IEEE Computer, 39 (2), 25–31.
Stahl, T. and Voelter, M. (2006). Model-Driven Software Development: Technology, Engineering, Management. New
York: John Wiley & Sons. Ward, P. and Mellor, S. (1985). Structured Development for Real-time Systems. Englewood Cliffs, NJ: Prentice Hall.
Bass, L., Clements, P. and Kazman, R. (2003). Software Architecture in Practice, 2nd ed. Boston: Addison-Wesley.
Booch, G. (2009). ‘Handbook of software architecture’. http://www.handbookofsoftwarearchitecture.com/.
Bosch, J. (2000). Design and Use of Software Architectures. Harlow, UK: Addison-Wesley. Buschmann, F., Henney, K. and Schmidt, D. C. (2007a). Pattern-oriented Software Architecture
Buschmann, F., Henney, K. and Schmidt, D. C. (2007b). Pattern-oriented Software Architecture
Coplien, J. H. and Harrison, N. B. (2004). Organizational Patterns of Agile Software Development. Englewood Cliffs,
NJ: Prentice Hall. Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented
Software. Reading, Mass.: Addison-Wesley.
Hunter, D., Rafter, J., Fawcett, J. and Van Der Vlist, E. (2007). Beginning XML, 4th ed. Indianapolis,Ind.: Wrox Press.
Kircher, M. and Jain, P. (2004). Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management. New York: John Wiley & Sons.
Lange, C. F. J., Chaudron, M. R. V. and Muskens, J. (2006). ‘UML software description and architecture description’.
IEEE Software, 23 (2), 40–6.
Lewis, P. M., Bernstein, A. J. and Kifer, M. (2003). Databases and Transaction Processing: An Application-oriented Approach. Boston: Addison-Wesley.
Martin, D. and Sommerville, I. (2004). ‘Patterns of interaction: Linking ethnomethodology and design’. ACM Trans. on
Computer-Human Interaction, 11 (1), 59–89.
C. Larman, Prentice Hall, 2004. Applying UML and Patterns: An Introduction to Object-oriented Analysis and Design and Iterative Development, 3rd edition. Larman writes clearly on object-oriented design and, as well as discussing the
use of the UML. This is a good introduction to using patterns in the design process.
K. Fogel, O’Reilly Media Inc., 2008, Producing Open Source Software: How to Run a Successful Free Software Project.
His book is a comprehensive guide to the background to open source software, licensing issues, and the practicalities of running an open source development project.
Kircher, M. and Jain, P. (2004). Pattern-Oriented Software Architecture Volume 3: Patterns for Resource Management.
New York: John Wiley & Sons.
Massol, V. (2003). JUnit in Action. Greenwich, CT: Manning Publications. Pilato, C., Collins-Sussman, B. and Fitzpatrick, B. (2008). Version Control with Subversion. Sebastopol, Calif.: O’Reilly
Media Inc.
St. Laurent,A.(2004). Understanding Open Source and Free Software Licensing. Sebastopol, Calif.: O’Reilly Media Inc.
Jeffries, R. and Melnik, G. (2007). ‘TDD: The Art of Fearless Programming’. IEEE Software, 24, 24–30. Kaner, C. (2003). ‘The power of ‘What If . . .’ and nine ways to fuel your imagination: Cem Kaner on
scenario testing’. Software Testing and Quality Engineering, 5 (5), 16–22.
Martin, R. C. (2007). ‘Professionalism and Test-Driven Development’. IEEE Software, 24 (3), 32–6.
Massol, V. and Husted, T. (2003). JUnit in Action. Greenwich, Conn.: Manning Publications Co.