Pemodelan Dalam Rekayasa Perangkat Lunak

Home
Halaman Muka

Sajian Utama
Sajian Khusus
Komunikasi
Komputer
Kendali

Elektronika Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih
memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam
suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus
dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-
pekerjaan dalam rekayasa perangkat lunak tersebut.

Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri
perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses
dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda
untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih
cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan
mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.
Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak.
Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak
komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
 Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
 Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
 Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
 Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
 Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
 Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
 Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi
spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika
pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena
pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat
proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

 Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak,
uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

 Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin
diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk
menghasilkan sistem yang kuat dan maintable.
  Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu
program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat
yakin program yang dikembangkan sesuai dengan spesifikasi.

 Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan

kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap
bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh
Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.
Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang
keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara
pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

 Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

 Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.

 Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.
  Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan
ke kastamer

 Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.
Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu
sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi,
biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah
pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau
diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan
sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya
merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang
nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan
kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini
digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan
komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang
mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini
memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan

kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer.
 Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-
kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk
sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang
kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.
Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun,
pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial
intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai
manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal
pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.
Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

 Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan
dokumen yang menggambarkan setiap versi sistem.

 Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat
lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

 Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang
mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan
sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil
yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan
evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan
mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari
beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan
melalui cara ini. Pengembangan evolusioner lebih tepat untuk
Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang
sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan,
tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.
Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk
baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan
untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum
oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model
tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita
membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua
model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus
memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh
Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana
membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model
umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan
selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan.
Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif
direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa
 persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat
dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika
resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin
pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah
transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan
kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam
keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan
digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti
oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse
digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan
dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones
dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan
kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral
dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit
didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat
menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru
(new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak
reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan
pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam
contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat
pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem
ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan
seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-
baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan.
Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah
mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan
model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan
sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi
pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Pemodelan Dalam Rekayasa Perangkat Lunak

Home
Halaman Muka

Sajian Utama
Sajian Khusus
Komunikasi
Komputer
Kendali

Elektronika Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih
memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam
suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus
dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-
pekerjaan dalam rekayasa perangkat lunak tersebut.

Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri
perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses
dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda
untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih
cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan
mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak.
Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak
komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
 Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
 Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
 Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
 Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
 Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
 Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
 Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi
spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika
pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena
pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat
proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

 Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak,
uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

 Pengembangan secara evolusioner

 Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin
diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk
menghasilkan sistem yang kuat dan maintable.

 Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu
program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat
yakin program yang dikembangkan sesuai dengan spesifikasi.

 Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan

kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap
bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh
Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.
Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang
keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara
pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

 Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

 Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
 bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.

 Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

 Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan
ke kastamer

 Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.
Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu
sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi,
biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah
pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau
diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan
sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya
merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang
nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan
kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini
digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan
komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang
mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini
memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan

kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer.
Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-
kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk
sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang
kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.
Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun,
pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial
intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai
manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal
pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.
Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

 Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan
dokumen yang menggambarkan setiap versi sistem.

 Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat
lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

 Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang
mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan
 sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil
yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan
evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan
mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari
beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan
melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang
sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan,
tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.
Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk
baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan
untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum
oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model
tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita
membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua
model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus
memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh
Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana
membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model
umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan
selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan
 Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan.
Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif
direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa
persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat
dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika
resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin
pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah
transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan
kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam
keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan
digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti
oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse
digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan
dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones
dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan
kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral
dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit
didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat
menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru
(new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak
reliabel dan tidak menghasilkan code objek yang efesien.
Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan
pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam
contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat
pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem
ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan
seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-
baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan.
Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah
mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan
model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan
sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi
pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Pemodelan Dalam Rekayasa Perangkat Lunak

Home
Halaman Muka

Sajian Utama
Sajian Khusus
Komunikasi
Komputer
Kendali

Elektronika Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang
dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih
memungkinkan tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam
suatu industri perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus
dikerjakan di bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-
pekerjaan dalam rekayasa perangkat lunak tersebut.
Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri
perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses
dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda
untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih
cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan
mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak.
Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak
komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
 Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
 Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
 Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
 Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
 Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
 Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
 Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi
spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika
pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena
pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat
proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:
  Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak,
uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

 Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin
diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk
menghasilkan sistem yang kuat dan maintable.

 Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu
program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat
yakin program yang dikembangkan sesuai dengan spesifikasi.

 Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan

kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap
bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh
Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.
Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang
keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara
pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

 Penentuan dan analisis spesifikasi

 Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

 Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.

 Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

 Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan
ke kastamer

 Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.
Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu
sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi,
biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah
pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau
diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan
sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya
merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang
nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan
kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini
digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan
komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang
mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini
memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan

kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer.
Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-
kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk
sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang
kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.
Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun,
pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial
intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai
manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal
pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.
Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

 Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan
dokumen yang menggambarkan setiap versi sistem.

 Sistem-sistem biasanya kurang terstruktur

 Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat
lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

 Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang
mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan
sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil
yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan
evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan
mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari
beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan
melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang
sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan,
tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.
Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk
baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan
untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum
oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model
tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita
membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua
model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus
memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh
Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.
Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana
membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model
umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan
selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan.
Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif
direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa
persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat
dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika
resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin
pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah
transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan
kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam
keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan
digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti
oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse
digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan
dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones
dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan
kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.
Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral
dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit
didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat
menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru
(new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak
reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan
pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam
contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat
pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem
ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan
seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-
baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan.
Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah
mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan
model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan
sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi
pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Pemodelan Dalam Rekayasa Perangkat Lunak

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di
tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan
tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri
perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di
bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam
rekayasa perangkat lunak tersebut.

Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri
perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses
dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda
untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih
cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan
mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.
Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak.
Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak
komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
 Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
 Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
 Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
 Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
 Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
 Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
 Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi
spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika
pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena
pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat
proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

 Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak,
uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

 Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin
diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk
menghasilkan sistem yang kuat dan maintable.
  Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu
program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat
yakin program yang dikembangkan sesuai dengan spesifikasi.

 Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan

kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap
bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh
Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.
Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang
keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara
pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

 Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

 Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.

 Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.
  Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan
ke kastamer

 Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu
sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi,
biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah
pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau
diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan
sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya
merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang
nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan
kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini
digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan
komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang
mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini
memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan

kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer.
 Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-
kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk
sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang
kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.
Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun,
pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial
intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai
manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal
pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.
Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

 Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan
dokumen yang menggambarkan setiap versi sistem.

 Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat
lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

 Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang
mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan
sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil
yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan
evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan
mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari
beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan
melalui cara ini. Pengembangan evolusioner lebih tepat untuk
Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang
sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan,
tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.
Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk
baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan
untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm

Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum
oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model
tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita
membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua
model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus
memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh
Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana
membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model
umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan
selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan.
Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif
direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa
 persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat
dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika
resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin
pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah
transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan
kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam
keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan
digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti
oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse
digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan
dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones
dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan
kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral
dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit
didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat
menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru
(new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak
reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan
pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam
contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat
pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem
ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan
seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-
baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan.
Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah
mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan
model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan
sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi
pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

Pemodelan Dalam Rekayasa Perangkat Lunak

Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di
tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan
tanpa melakukan suatu pemodelan. Hal itu tidak dapat lagi dilakukan dalam suatu industri
perangkat lunak. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di
bagian awal dari rekayasa, dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam
rekayasa perangkat lunak tersebut.

Proses

Di dalam suatu industri dikenal berbagai macam proses, demikian juga halnya dengan industri
perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses
dalam cara-cara yang berlainan. Perusahaan yang berbeda menggunakan proses yang berbeda
untuk menghasilkan produk yang sama. Tipe produk yang berbeda mungkin dihasilkan oleh
sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih
cocok dari lainnya untuk beberapa tipe aplikasi. Jika proses yang salah digunakan akan
mengurangi kualitas kegunaan produk yang dikembangkan.

Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin
menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas
ini.

Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak.
Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara.
Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak
komplek dan melibatkan banyak aktivitas.

Seperti produk, proses juga memiliki atribut dan karakteristik seperti :

 Understandability, yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana
kemudahan definisi proses itu dimengerti.
 Visibility, apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas
sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas
 Supportability, yaitu sejauh mana aktivitas proses dapat didukung oleh CASE
 Acceptability, apakah proses yang telah ditentukan oleh insinyur dapat diterima dan
digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak
 Reliability, apakah proses didesain sedikian rupa sehingga kesalahan proses dapat
dihindari sebelum terjadi kesalahan pada produk.
  Robustness, dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga
 Maintainability, dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan
 Rapidity, bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi
spesifikasi.

Model

Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Contohnya, jika
pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena
pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Ini akan memperlambat
proses.

Model proses perangkat lunak masih menjadi object penelitian, tapi sekarang ada banyak model
umum atau paradigma yang berbeda dari pengembangan perangkat lunak, antara lain:

 Pendekatan Waterfall

Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam
proses yang terpisah, seperti spesifikasi kebutuhan, implementasi desain perangkat lunak,
uji coba dst. Setelah setiap langkah didefinisikan, langkah tersebut di sign off dan
pengembangan dilanjutkan pada langkah berikutnya.

 Pengembangan secara evolusioner

Pendekatan ini interleaves aktivitas spesifikasi, pengembangan dan validasi. Sistem awal
dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi
kebutuhan kastamer. Kemudian sistem disampaikan. Sistem itu mungkin
diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk
menghasilkan sistem yang kuat dan maintable.

 Transformasi formal

Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan
transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu
program. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat
yakin program yang dikembangkan sesuai dengan spesifikasi.

 Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan

kembali.

Teknik ini menganggap bagian-bagian dari sistem sudah ada. Proses pengembangan
sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap
bagian.
Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner,
saat ini banyak digunakan dalam pengembangan sistem. Beberapa sistem sudah dibuat dengan
menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.
Metode penggunaan kembali (reuse) umum di jepang. Metode ini sekiranya akan diakui oleh
Eropa dan Amerika Utara. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.
Bagaimanapun juga reuse masih suatu penelitian, terlalu cepat untuk berkomentar tentang
keefektifannya.

Waterfall

Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara
pembuatan perangkat lunak secara lebih nyata.

Langkah-langkah yang penting dalam model ini adalah

 Penentuan dan analisis spesifikasi

Jasa, kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Kemudian
semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang.

 Desain sistem dan perangkat lunak

Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau
perangkat keras. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.
Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam
bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat
dijalankan.

 Implementasi dan ujicoba unit

Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau
unit program. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi.

 Integrasi dan ujicoba sistem

Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan
bahwa persyaratan perangkat lunak telah dipenuhi. Setelah ujicoba, sistem disampaikan
ke kastamer

 Operasi dan pemeliharaan

Normalnya, ini adalah phase yang terpanjang. Sistem dipasang dan digunakan.
Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah
sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai
kebutuhan baru ditemukan.
Gambar 1. Pemodelan Waterfall

Dalam prakteknya, setiap langkah sering tumpang tindih dan saling memberi informasi satu
sama lain. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari
aktivitas pengembangan. Selama di langkah terakhir, perangkat lunak telah digunakan.
Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak
manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi,
biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah
pengembangan selanjutnya. Masalah-masalah selama resolusi selanjutnya, dibiarkan atau
diprogram. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan
sesuai dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya
merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang
nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan
kastamer. Namun demikian model waterfall mencerminkan kepraktisan engineering.
Konsekuensinya, model proses perangkat lunak yang berdasarkan pada pendekatan ini
digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.

Pengembangan Evolusioner

Model ini berdasarkan pada ide pengembangan pada implementasi awal yang akan menghasilkan
komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang
mencukupi dapat dikembangan. Selain memiliki aktivitas-aktivitas yang terpisah model ini
memberikan feedback dengan cepat dan serentak

Terdapat 2 tipe pada model ini

1. Pemprograman evolusioner

Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan

kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer.
Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem
dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.

2. Pemodelan

Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan-
kebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk
sistem. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang
kurang dimengerti.
Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci.
Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun,
pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial
intelligence) yang berusaha untuk menyamai kemampuan manusia.

Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai
manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka.
Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal
pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.
Namun, dari segi teknik dan manajemen, model ini memiliki masalah mendasar yaitu:

 Proses tidak visibel.

Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan
dokumen yang menggambarkan setiap versi sistem.

 Sistem-sistem biasanya kurang terstruktur

Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat
lunak. Evolusi perangkat lunak terlihat sulit dan mahal.

 Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang
mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan
sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil
yang memiliki ketrampilan yang tinggi dan motivasi yang kuat.
Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan
evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan
mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari
beberapa proses yang lebih luas. ( seperti model waterfall ).

Karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan
melalui cara ini. Pengembangan evolusioner lebih tepat untuk

Pengembangan sistem yang relatif kecil.

Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang
sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan,
tidak terlalu mahal.

Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

Disini, sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu.
Contohnya, sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk
baru.

Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan
untuk menyatakan spesifikasi secara rinci. Contohnya, sistem AI dan interfaces pemakai.

Spiral Boehm
Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum
oleh banyak agen pemerintah dan pembuat perangkat lunak. Jadi, tidak mudah melupakan model
tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kita
membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua
model umum seperti yang telah kita bicarakan sebelumnya. Model perbaikan tersebut juga harus
memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pendekatan alternatif diusulkan oleh
Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa
resiko yang disadari mungkin membentuk dasar model proses umum.

Model Boehm bebrbentuk spiral. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

Tidak ada tahap yang tetap dalam model ini. Manajemen harus memutuskan bagaimana
membentuk proyek kedalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model
umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan
selama pembuatan proyek.

Setiap loop dibagi dalam 4 sektor

1. Pembuatan tujuan

Tujuan, hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan.
Rencan rinci manajemen juga ditulis lengkap. Pembuatan strategi-strategi alternatif
direncanakan sesuai dengan resiko yang ada.

2. Perkiraan dan pengurangan resiko

Untuk setiap resiko yang telah diidentifikasi, akan dibuat analisis rincinya. Kemudian
diambil langkah-langkah untuk mengurangi resiko. contohnya, jika ada resiko bahwa
persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat
dikembangkan.

3. Pengembangan dan validasi

Setelah evaluasi resiko, sebuah model pengembangan untuk sistem dipilih. Misalnya, jika
resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin
pengembangan evolusioner dengan menggunakan model contoh (prototipe)

Jika resiko keselamatan yang diutamakan, model pengembangan yang sesuai adalah
transformasi formal dan seterusnya. Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem.

4. Perencanaan

Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan
kembali dan rencana dibuat untuk tahap selanjutnya.
Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam
keseluruhan sisten perangkat lunak. Model spiral encompasses model lainnya. Pemodelan
digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Kemudian dapat diikuti
oleh model konvensional, waterfall. Transformasi formal digunakan untuk mengembangkan
bagian-bagian sistem yang memiliki persyaratan keselamatan yang tinggi dan pendekatan reuse
digunakan untuk pengimplementasian bagian-bagian lain dari sistem data manajemen.

Pada implementasinya, model spiral ini juga banyak digunakan, tetapi biasanya dikombinasikan
dengan model yang lain. Pemodelan waterfall, yang sangat bagus dalam menentukan millestones
dan pemodelan spiral, yang sangat bagus dengan menggunakan prototyping, merupakan
kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

Manajemen Resiko

Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral
dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah konsep yang sulit
didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat
menyebabkan kesalahan. Contohnya, jika bertujuan menggunakan pemprograman bahasa baru
(new programming language), resiko yang mungkin adalah alat pengumpul yang digunakan tidak
reliabel dan tidak menghasilkan code objek yang efesien.

Resiko adalah sebagai hasil ketidakcukupan informasi. Resiko tersebut dapat dipecahkan dengan
pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Dalam
contoh diatas, resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat
pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Jika sistem
ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.

Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance, kegunaan, dan
seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik-
baiknya kemudian diperhitungkan. Setiap alternatif diperhitungan bertentangan dengan tujuan.
Ini biasanya menghasilkan identifikasi sumber resiko proyek. Langkah selanjutnya adalah
mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail, pembuatan
model/contoh, simulasi dan seterusnya. Untuk menggunakan model spiral, Boehm menyarankan
sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Bentuk ini mungkin dilengkapi
pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.
 Model Metodologi Waterfall 

Model ini sering juga disebut dengan classic life cycle. Dalam metode ini membutuhkan
pendekatan sistematis dan squencial dalam pengembangan peranglkat lunak, dimulai dari tingkat
sistem dan kemajuan melalui analisis, desain, coding, testig dan pemeliharaan. pemodelan ini
mengikuti beberapa aktivitas berikut :

 Rekayasa dan Pemodelan Sistem/Informasi (System/Information Engineering and

Modeling). Tahap ini sering disebut juga dengan Project Definition.

  Analisis Kebutuhan Perangkat Lunak (Software Requirements Analysis). Proses

pengumpulan kebutuhan diintensifkan ke perangkat lunak. Hasilnya harus
didokumentasikan dan di-review ke pelanggan.
 Desain (Design). Proses desain mengubah kebutuhan-kebutuhan menjadi bentuk
karakteristik yang dimengerti perangkat lunak sebelum dimulai penulisan program.
 Penulisan Program (Coding). Desain tadi harus diubah menjadi bentuk yang dimengerti
mesin (komputer). Maka dilakukan langkah penulisan program.
 Testing. Setelah kode program selesai dibuat, dan program dapat berjalan, testing dapat
dimulai. Testing difokuskan pada logika internal dari perangkat lunak, fungsi eksternal,
dan mencari segala kemungkinan kesalahan.

 Support/Maintenance. Perangkat lunak setelah diberikan pada pelanggan, mungkin dapat

ditemui error ketika dijalankan dilingkungan pelanggan. Pemeliharaan ini dapat
berpengaruh pada semua langkah yang dilakukan sebelumnya. 

Kelebihan dari metode WaterFall  :

Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno, daripada menggunakan
pendekatan asal-asalan. Selain itu, metode ini juga masih masuk akal jika kebutuhan sudah
diketahui dengan baik.
Kekurangan dari metode  Waterfall :

1.  Pada kenyataannya, jarang mengikuti urutan sekuensial seperti pada teori. Iterasi sering
terjadi menyebabkan masalah baru.
2. Sulit bagi pelanggan untuk menentukan semua kebutuhan secara eksplisit.
3. Pelanggan harus sabar, karena pembuatan perangkat lunak akan dimulai ketika tahap
desain sudah selesai. Sedangkan pada tahap sebelum desain bisa memakan waktu yang
lama.
4. Kesalahan di awal tahap berakibat sangat fatal pada tahap berikutnya.
  Model Metodologi RAD 

Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang
menekankan pada sedikitnya siklus pengembangan. Model ini memecah suatu proyek menjadi
bagian-bagian kecil yang mana tiap bagiannya dibangun dengan model yang mirip dengan
Waterfall. Tujuan utama model ini adalah menyelesaikan suatu proyek per bagian, sehingga
proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara
global) .

 Model RAD menekankan pada fase-fase berikut :

1.  Business modeling. Pada tahap ini, aliran informasi (information flow) pada fungsi-
fungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses
bisnis, informasi apa yang hasilkan, siapa yang membuat informasi itu, kemana saja
informasi mengalir, dan siapa yang mengolahnya.
 2. Data modeling. Aliran informasi yang didefinisikan dari business modeling, disaring lagi
agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung
bisnis tersebut. Karakteristik (atribut) setiap objek ditentukan beserta relasi antar
objeknya.
3. Process modeling. Objek-objek data yang didefinisikan sebelumnya diubah agar bisa
menghasilkan aliran informasi untuk diimplementasikan menjadi funsi bisnis.
Pengolahan deskripsi dibuat untuk menambah, merubah, menghapus, atau mengambil
kembali objek data.
4. Application generation. RAD bekerja dengan menggunakan fourth generation techniques
(4GT). Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional
menggunakan bahasa pemrograman generasi ketiga (third generation programming
languages), tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau
membuat komponen baru (jika perlu). Dalam semua kasus, alat bantu untuk otomatisasi
digunakan untuk memfasilitasi pembuatan perangkat lunak.
5. Testing and turnover. Karena menekankan pada penggunaan kembali komponen yang
telah ada (reuse), sebagian komponen-komponen tersebut sudah diuji sebelumnya.
Sehingga mengurangi waktu testing secara keseluruhan. Kecuali untuk komponen-
komponen baru.                        

Kelebihan :
RAD memang lebih cepat dari  Waterfall. jika kebutuhan dan batasan project sudah diketahui
dengan baik. Juga jika proyek memungkinkan untuk dimodularisasi.

Kekurangan :

1. Tidak semua project bisa dipecah (dimodularisasi), sehingga belum tentu RAD dipakai
pada semua proyek.
2. Karena project dipecah menjadi be
berapa bagian, maka dibutuhkan banyak orang untuk membentuk suatu tim yang
mengerjakan tiap bagian tersebut.
3. Membutuhkan komitmen antara pengemang dengan pelanggan.
4. Karena dibuat dengan reuse komponen-komponen yang sudah ada, fasilitas-fasilitas pada
tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya
sehingga kualitas program bisa menurun.

Sekuensial Linier (Waterfall) Model

Keunggulan:

 software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang
baik.
  Document pengembangan sistem sangat terorganisir, karena setiap fase harus
terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya.

Kekurangan :

 membutuhkan keahlian yang baik atau yang telah berpengalaman dalam mengembangkan
perangkat lunak, dalam arti metode ini kurang cocok bagi pemula.
 Diperlukan majaemen yang baik, karena proses pengembangan tidak dapat berulang
sebelum menghasilkan suatu produk, yaitu aplikasi. Jadi apabila dalam suatu proses
seperti perancangan tidak selesai tepat waktu, maka akan mempengaruhi keseluruhan
proses pengembangan perangkat lunak.

·         Iterasi sering terjadi menyebabkan masalah baru

·         Client kesulitan untuk menyatakan semua ke inginannya secara eksplisit diawal tahap
pengembangan

·         Hasil software yang dikembangkan baru akan diketahui lama setelah proyek
pengembangan dimulai

RAD Model

Keunggulan :

·         Setiap fungsi mayor dapat dimodulkan dalam waktu tertentu kurang dari 3 bulan dan dapat
dibicarakan oleh tim RAD yang terpisah dan kemudian diintegrasikan sehingga waktunya lebih
efisien

·         RAD mengikuti tahap pengembangan sistem seperti umumnya, tetapi mempunyai
kemampuan untuk menggunakan kembali komponen yang ada sehingga pengembang tidak perlu
membuat dari awal lagi dan waktu yang lebih singkat

Kelemahan :

·         Model yang besar (skala proyek), membutuhkan resources yg baik dan solid

·         Membutuhkan komitmen pengembang dan user yang sama agar cepat selesai sesuai
dengan rencana

 
Prototyping Model

Keungggulan :

·         Adanya kominuikasi yang baik antara pengembang dan pelanggan

·         Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan

·         Pelangggan  berperan aktif dalam pengembangan sistem

·         Lebih menghemat waktu dalam pengembangan sistem

·         Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya 

Kelemahan :

·         Ketidaksadaran user bahwa ini hanya suatu model awal bukan model akhir

·         Pengembang kadang-kadang membuat implementasi yang sembarangan.

·         Teknik dan tools yang tidak optimal pada prototipe yang akan tetap digunakan pada
softare sesungguhnya

Component Based Model

Keunggulan :

·         Lebih memungkinkan untuk mengurangi beban biaya dan waktu pengembangan.

·         Menggunakan model reuse, pada komponen yang sudah mewakili kebutuhan umum.        

Kelemahan :

·         Model ini bersifat iteratif atau berulang-ulang prosesnya.

·          Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini.

Extreme Programming

Keunggulan :
  Communication/Komunikasi : Komunikasi dalam XP dibangun dengan melakukan
pemrograman berpasangan (pair programming). Developer didampingi oleh pihak klien
dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam
pemrograman sambil berkomunikasi dengan developer. Selain itu perkiraan beban tugas
juga diperhitungkan.
 Simplicity/ sederhana: Menekankan pada kesederhanaan dalam pengkodean: “What is the
simplest thing that could possibly work?” Lebih baik melakukan hal yang sederhana dan
mengembangkannya besok jika diperlukan. Komunikasi yang lebih banyak
mempermudah, dan rancangan yang sederhana mengurangi penjelasan.
 Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes, unit
test atau system integration dan jangan menunda karena biaya akan membengkak (uang,
tenaga, waktu).
 Courage / Berani: Banyak ide baru dan berani mencobanya, berani mengerjakan kembali
dan setiap kali kesalahan ditemukan, langsung diperbaiki.

Kelemahan :

 Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.
 Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk
melakukan apa yang diperlukan hari itu juga).

 PENGANTAR MODEL PROSES PERANCANGAN PERANGKAT LUNAK

 1.1.  Pendahuluan.

 Dalam pengembangan sebuah perangkat lunak dibutuhkan suatu metodologi yang akan
memandu tim pengembang dalam merancang perangkat lunak. Perancangan dimulai
dengan menetapkan kebutuhan perangkat lunak tersebut sampai pada implementasi dan
penyebaran atau distribusi.

 Prinsip-prinsip perancangan perangkat lunak menjadi basis proses rekayasa aplikasi

bisnis telah banyak di terapkan. Dimana sebuah metodologi merupakan kerangka pijakan
utama dalam perancangan perangkat lunak profesional untuk menghasilkan aplikasi yang
sesuai dengan kebutuhan bisnis sebuah organisasi. Tahapan-tahapan dalam membangun
sebuah perangkat lunak akan sangat berguna untuk memastikan apakah elemen-elemen
proyek pengembangan perangkat lunak telah dikelola dengan baik dan benar.

 Microsoft Solution Framework (MSF) merupakan metodologi alternatif perancangan

perangkat lunak yang menggabungkan dua metodologi yang berbeda menjadi satu
kesatuan yang utuh untuk menghasilkan sebuah solusi perangkat lunak yang lebih
dinamis dengan mengadopsi kelebihan dari masing-masing metodologi. Kedua
metodologi tersebut adalah Waterfall dan Spiral. Metodologi Waterfall menggambarkan
sebuah model proses yang statis dengan tahapan-tahapan berlapis yang menggunakan
sebuah milestone sebagai transisi pada setiap tahap perancangan, sementara metodologi
Spiral (iterative) menerapkan model proses secara sirkular tanpa adanya cekpoint atau
milestone. Namun kelebihan metodologi spiral adalah mengenai kebutuhan
 pengembangan secara keberlanjutan dan adanya keterlibatan pemakai dalam
pembangunan perangkat lunak sehingga perangkat lunak akan selalu berkembang dengan
versi dan fitur yang lebih baru.

 Keberhasilan pengembangan perangkat lunak bergantung pada pengelolaan proyek

perangkat lunak secara keseluruhan. Menetapkan sebuah metodologi yang memiliki
dinamisasi tinggi dalam tahap-tahap perancangan model proses perangkat lunak akan
sangat berpengaruh pada kualitas perangkat lunak yang dihasilkan. Model proses
merupakan tahap-tahap aktivitas proyek yang menggambarkan daur hidup suatu proyek.
Microsoft Solution Framework (MSF) adalah metodologi perancangan dan
pengembangan aplikasi bisnis yang diperkenalkan oleh sebuah vendor software besar
yaitu Microsoft Corporation. Prinsip-prinsip pengembangan perangkat lunak dengan
metodologi MSF memiliki perencanaan berbasis milestone (model waterfall), dan
memberikan hasil yang dapat diprediksi (model spiral/iterative) disertai umpan balik dan
kreativitas dari tim pengembang.

 Gambar 1. Model Waterfall                     Gambar 2. Model Spiral/Iterative

 Gambar 3. Model Microsoft Solution Framework (MSF)

 1.2.  Model Proses Pengembangan Perangkat Lunak.

 1.2.1. Model Proses Waterfall (Sequential).

 Model ini menggunakan milestone sebagai titik transisi dan pengujian, artinya setiap
aktivitas pada tahap pengembangan harus diselesaikan sebelum menuju tahap
pengembangan berikutnya. Sehingga model ini sangat sesuai untuk perangkat lunak
dengan syarat-syarat yang telah didefinisikan secara lengkap sebelumnya karena besar
kemungkinan tidak adanya perubahan aplikasi dimasa yang akan datang. Kondisi
semacam ini akan sangat berpengaruh pada perangkat lunak dan menimbulkan masalah
terhadap kebutuhan iterasi dimana aplikasi akan terus berkembang dengan penyesuaian-
penyesuaian terhadap kebutuhan, proses bisnis dan lingkungan aplikasi yang terus
berubah dari waktu kewaktu. Namun kelebihan dari model ini adalah karena adanya titik
transisi yang jelas pada setiap tahap, maka akan memudahkan tim pengembang perangkat
lunak dalam memonitor penjadwalan proyek, menetapkan tanggung jawab dan
akuntabilitas peran personal dalam proyek perangkat lunak.

 Kelemahan dari model ini adalah adanya kendala dalam mengakomodasi perubahan
setelah proses pengembangan telah berjalan. Fase sebelumnya harus lengkap dan selesai
sebelum memasuki tahap berikutnya. Beberapa kendala yang muncul pada model
waterfall adalah :

 a. Aspek perubahan pada perangkat lunak sulit dilakukan karena sifatnya yang kaku
dimana kebutuhan perangkat lunak harus lengkap.

 b. Karena sifat kakunya, model ini cocok manakala kebutuhan telah dikumpulkan secara
lengkap sehingga perubahan bisa ditekan sekecil mungkin. Akan tetapi pada
kenyataannya sangat jarang sekali pengguna dapat mendefinisikan kebutuhan awal secara
lengkap, oleh karena perubahan kebutuhan adalah sesuatu yang wajar terjadi.

 c. Waterfall pada umumnya digunakan untuk rekayasa sistem perangkat lunak

berkapasitas besar dimana proyek dikerjakan di beberapa tempat berlainan, dan terbagi
menjadi beberapa bagian sub-proyek.


 Gambar 4. Tahapan Pada Model Proses Waterfall (Sommervile, 2001)

 Sesuai dengan namanya “waterfall” atau air terjun, model waterfall menggunakan
tahapan-tahapan seperti air terjun, dimana tahapan-tahapan tersebut terbagi menjadi lima
tahapan.

 1. Requirements analysis and definition : pada tahap ini tim pengembang mengumpulkan
kebutuhan secara lengkap kemudian dianalisis dan mendefinisikan kebutuhan-kebutuhan
proses bisnis yang harus dipenuhi oleh perangkat lunak (solusi bisnis) yang akan
dibangun.

 2. System and software design : pada tahap ini tim pengembang mendesain sistem dan
aplikasi meliputi desain konseptual, logikal dan fisikal .

 3. Implementation and unit testing : pada tahap ini desain yang telah di rancang
diimplementasikan dengan menterjemahkan ke dalam kode-kode program menggunakan
sebuah bahasa pemrograman, sekaligus melakukan pengujian terhadap unit-unit program
yang telah dibuat.

 4. Integration and system testing : tim pengembang menyatukan unit-unit program

kemudian melakukan pengujian sistem perangkat lunak secara keseluruhan.

 5. Operation and maintenance : tim pengembang melakukan pengoperasian program dan

melakukan pemeliharaan terhadap perangkat lunak dengan penyesuaian atau perubahan
terhadap situasi sebenarnya.

 1.2.2. Model Proses Spiral (Iterative).

 Model ini berbasiskan pada kebutuhan terhadap aplikasi secara keberlanjutan untuk
menyaring kebutuhan-kebutuhan tersebut dan estimasi proyek secara keseluruhan. Model
 ini menerapkan perancangan model proses yang lebih dinamis dengan terus beradaptasi
terhadap kebutuhan proses bisnis dimasa yang akan datang sehingga versi aplikasi terus
berkembang dengan fitur-fitur yang mengalami peningkatan dari waktu kewaktu.

 Kebutuhan waktu untuk pengembangan aplikasi yang cepat dengan kapasitas proyek
yang relatif kecil sangat relefan dengan model spiral ini. Keterlibatan pelanggan dengan
tim pengembang perangkat lunak akan sangat sering terjadi karena pelanggan akan
memberikan feedback dan persetujuan setiap tahap dalam pengembangan aplikasi
perangkat lunak. Dengan adanya feedback dari pelanggan maka estimasi waktu terhadap
penyelesaian proyek perangkat lunak menjadi semakin jelas.

 Gamba
r 5. Tahapan Pada Model Proses Spiral (Boehm, 1988)

 Pengembangan perangkat lunak dengan model spiral memiliki kelemahan karena tidak
adanya milestone sebagai titik transisi dan pengujian maka dikhawatirkan proses
pengembangan sistem akan mengalami kekacauan dari segi waktu penyelesaian solusi
sistem. Oleh karenanya model ini hanya sesuai untuk aplikasi-aplikasi kecil yang tidak
terintegrasi dan terdistribusi.

 Model spiral terbagi menjadi empat quadrant, dimana setiap quadrant merepresentasikan
sebuah manajemen proses dengan tahapan-tahapan identify, design, construct dan
 evaluate (Dean Muench, 1994). Sistem akan melalui tahapan-tahapan proses yang akan
berulang sebagai berikut :

 1. Mendefinisikan tujuan dan kebutuhan bisnis, mengembangkan desain konseptual,

rancangan konsep, rencana pengujian, dan analisis terhadap resiko dengan melibatkan
pemakai.

 2. Mendefinisikan kebutuhan sistem, mengembangkan desain logikal, mengkompilasi

(software-build) rancangan awal, mengevaluasi hasil dengan melibatkan pemakai.

 3. Mendifinisakan kebutuhan subsistem, menghasilkan desain fisikal, mengkompilasi

rancangan berikutnya, mengevaluasi hasil dengan melibatkan pemakai.

 4. Mendefinisikan kebutuhan setiap unit, menghasilkan desain akhir, mengkompilasi

rancangan akhir, mengevaluasi keselur

 Result Waterfall sebagai model rekayasa perangkat lunak

 Model Mengambil kegiatan dasar seperti spesifikasi,air terjun (waterfall)
pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses
yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, ...
 ... perangkat lunak. Rangkaian tugas ini meliputi aktivitas kerangka kerja, tindakan
rekayasa perangkat lunak, tugas, produk kerja, jaminan kualitas dan mekanisme
kontrol pada setiap proyek. Metode dalam model proses. Waterfall model ... Hasil
iterasi dari model ini nantinya akan berupa prototype software yang berfungsi sebagai
gambaran umum kepada klien. Fungsi-fungsi yang ada di prototype masih standar,
biasanya pada prototype hanya terdapat interface dan fungsi dasar. ...
 Proses yang dicari (selain yang termasuk dalam database yang tercantum di atas) untuk
Evaluasi dan Penilaian dalam Rekayasa Perangkat Lunak (Kemudahan) (Sebelumnya
Empiris Penilaian dalam Software Rekayasa) dan Konferensi ... Meskipun waterfall
adalah model pembangunan perangkat lunak tertua, menarik untuk dicatat bahwa hanya
salah satu dari lima penelitian dari beberapa waktu yang lalu (1988). Empat penelitian
lainnya relatif baru-baru ini, mulai dari 2004 sampai 2006. ...
 Dengan demikian, tim proyek mulai menggunakan pendekatan berorientasi obyek,
dimana modul yang mengandung komponen itu disebut objek (yang mengandung data
dan proses) digunakan sebagai blok bangunan untuk sistem. Ide dibalik pendekatan
berorientasi ..... UML (Unified Modelling Language) adalah bahasa pemodelan standar
pada rekayasa perangkat lunak. Dengan menggunakan UML akan berdampak pada
peningkatan produktifitas dan dan kualitas serta pengurangan biaya dan waktu. ...
 mendapatkan sumber daya perangkat lunak. Ketika perusahaan memutuskan untuk
menciptakan sendiri perangkat lunak aplikasinya, programer dapat menyiapkan
dokumentasi yang lebih terinci yang hasil akhirnya adalah software library dari ...
 SDLC (Systems Development Life Cycle ) siklus hidup pengembangan sistem), dalam
rekayasa sistem dan rekayasa perangkat lunak, adalah proses pembuatan dan
 pengubahan sistem serta model dan metodologi yang digunakan untuk ... Analisis
persyaratan kadang-kadang memerlukan individu / tim dari klien serta sebagai pihak
penyedia layanan untuk mendapatkan detail dan akurat persyaratan . Sering ada menjadi
banyak dan dari komunikasi untuk memahami persyaratan tersebut. ...
 Salah satu strategi yang sering dipakai sebagai model proses atau paradigma rekayasa
perangkat lunak yaitu dengan menggunakan model waterfall. Model waterfall
merupakan pendekatan perangkat lunak yang sistematik dan sekuensial yang ...