P. 1
Model Metodologi Waterfall

Model Metodologi Waterfall

|Views: 2,038|Likes:

More info:

Published by: aiiu-wahyuni-jrs-3477 on Oct 22, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOCX, PDF, TXT or read online from Scribd
See more
See less

07/17/2013

pdf

text

original

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 perkerjaanpekerjaan 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 :
y y y y y y y y

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:
y

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.

y

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.

y

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.

y

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
y

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.

y

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.

y

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.

y

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

y

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.

Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. Namun. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. dari segi teknik dan manajemen. Karena masalah-masalah tersebut. pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Pengembangan evolusioner lebih tepat untuk . Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. y Ketrampilan khusus jarang dimiliki Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. y Sistem-sistem biasanya kurang terstruktur Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Evolusi perangkat lunak terlihat sulit dan mahal. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. model ini memiliki masalah mendasar yaitu: y Proses tidak visibel. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Untuk memecahkan masalah-masalah tersebut. Namun. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. ( seperti model waterfall ). Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. 2. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini.

Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Setiap loop dibagi dalam 4 sektor 1. sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Disini. Pengembangan sistem yang memiliki masa hidup yang relatif singkat. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Spiral Boehm Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. akan dibuat analisis rincinya. Rencan rinci manajemen juga ditulis lengkap. Model Boehm bebrbentuk spiral. 2. Contohnya. sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Jadi.Pengembangan sistem yang relatif kecil. hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek. tidak terlalu mahal. tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Kemudian diambil langkah-langkah untuk mengurangi resiko. Pendekatan alternatif diusulkan oleh Boehm (1988). Pembuatan tujuan Tujuan. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. contohnya. Jika pemodelan digunakan. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Perkiraan dan pengurangan resiko Untuk setiap resiko yang telah diidentifikasi. jika ada resiko bahwa . Contohnya. sistem AI dan interfaces pemakai. Tidak ada tahap yang tetap dalam model ini. Setiap loop mewakili sebuah tahap dari proses perangkat lunak.

resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. model spiral ini juga banyak digunakan. Pemodelan waterfall. Dalam contoh diatas. tetapi biasanya dikombinasikan dengan model yang lain. resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. Manajemen Resiko Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Resiko adalah sebagai hasil ketidakcukupan informasi. waterfall. Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance. Misalnya. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini. 4. Perencanaan Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya.persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. Resiko adalah konsep yang sulit didefinisikan secara tepat. 3. 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. jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. dan seterusnya. yang sangat bagus dengan menggunakan prototyping. Kemudian dapat diikuti oleh model konvensional. kegunaan. Pada implementasinya. Model spiral encompasses model lainnya. jika bertujuan menggunakan pemprograman bahasa baru (new programming language). Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaik- . Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Contohnya. yang sangat bagus dalam menentukan millestones dan pemodelan spiral. model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah. sebuah model pengembangan untuk sistem dipilih. Pengembangan dan validasi Setelah evaluasi resiko.

Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk. pembuatan model/contoh. Setiap alternatif diperhitungan bertentangan dengan tujuan. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. simulasi dan seterusnya. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. dan pemodelan ini akan mempengaruhi perkerjaanpekerjaan dalam rekayasa perangkat lunak tersebut. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa. demikian juga halnya dengan industri perangkat lunak. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral.baiknya kemudian diperhitungkan. 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. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Namun beberapa proses lebih . Proses Di dalam suatu industri dikenal berbagai macam proses. Untuk menggunakan model spiral.

Setelah setiap langkah didefinisikan. Ini akan memperlambat proses. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. Model Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. Model proses perangkat lunak masih menjadi object penelitian. apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak Reliability. y Pengembangan secara evolusioner . implementasi desain perangkat lunak. jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur.cocok dari lainnya untuk beberapa tipe aplikasi. Contohnya. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. antara lain: y Pendekatan Waterfall Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah. dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga Maintainability. Robustness. proses juga memiliki atribut dan karakteristik seperti : y y y y y y y y Understandability. dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan Rapidity. uji coba dst. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas Supportability. Seperti produk. langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. yaitu sejauh mana aktivitas proses dapat didukung oleh CASE Acceptability. seperti spesifikasi kebutuhan. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak. Visibility.

Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Langkah-langkah yang penting dalam model ini adalah y Penentuan dan analisis spesifikasi Jasa. pengembangan dan validasi. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam . y Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. y Transformasi formal Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. Waterfall Model ini telah diperoleh dari proses engineering lainnya. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. saat ini banyak digunakan dalam pengembangan sistem. Kemudian sistem disampaikan. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. Metode penggunaan kembali (reuse) umum di jepang. terlalu cepat untuk berkomentar tentang keefektifannya. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars.Pendekatan ini interleaves aktivitas spesifikasi. Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner. Bagaimanapun juga reuse masih suatu penelitian. kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. y Desain sistem dan perangkat lunak Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Teknik ini menganggap bagian-bagian dari sistem sudah ada. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian.

biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. ini adalah phase yang terpanjang. setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi. Pemodelan Waterfall Dalam prakteknya. Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. Namun demikian model waterfall mencerminkan kepraktisan engineering. dibiarkan atau diprogram. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Sistem dipasang dan digunakan. Setelah ujicoba. y Integrasi dan ujicoba sistem Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Sayangnya.bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan. setelah sedikit iterasi. Masalah-masalah selama resolusi selanjutnya. Konsekuensinya. Selama di langkah terakhir. 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. sistem disampaikan ke kastamer y Operasi dan pemeliharaan Normalnya. Gambar 1. y Implementasi dan ujicoba unit Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu. 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 . Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. perangkat lunak telah digunakan.

Evolusi perangkat lunak terlihat sulit dan mahal. model ini memiliki masalah mendasar yaitu: y Proses tidak visibel. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. y Ketrampilan khusus jarang dimiliki Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Namun. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer.mencukupi dapat dikembangan. Kebanyakan . Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini 1. dari segi teknik dan manajemen. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. 2. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. 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. y Sistem-sistem biasanya kurang terstruktur Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Namun. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini.

tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Pengembangan evolusioner lebih tepat untuk Pengembangan sistem yang relatif kecil. Tidak ada tahap yang tetap dalam model ini. sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Jadi. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. Model Boehm bebrbentuk spiral. Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Setiap loop dibagi dalam 4 sektor 1. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Untuk memecahkan masalah-masalah tersebut. Contohnya. Jika pemodelan digunakan. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Disini. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. ( seperti model waterfall ).sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Pembuatan tujuan . Pengembangan sistem yang memiliki masa hidup yang relatif singkat. tidak terlalu mahal. 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. Contohnya. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Karena masalah-masalah tersebut. Pendekatan alternatif diusulkan oleh Boehm (1988). Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek.

Kemudian diambil langkah-langkah untuk mengurangi resiko. . Manajemen Resiko Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Misalnya. Perencanaan Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. model spiral ini juga banyak digunakan. yang sangat bagus dengan menggunakan prototyping. Pengembangan dan validasi Setelah evaluasi resiko. jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. Pemodelan waterfall. contohnya. Resiko adalah konsep yang sulit didefinisikan secara tepat. yang sangat bagus dalam menentukan millestones dan pemodelan spiral. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. akan dibuat analisis rincinya. 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. merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini. Pada implementasinya. Model spiral encompasses model lainnya. hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan. 3. Kemudian dapat diikuti oleh model konvensional. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. sebuah model pengembangan untuk sistem dipilih. Perkiraan dan pengurangan resiko Untuk setiap resiko yang telah diidentifikasi. Contohnya. 2. model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Rencan rinci manajemen juga ditulis lengkap.Tujuan. waterfall. resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien. 4. tetapi biasanya dikombinasikan dengan model yang lain. jika bertujuan menggunakan pemprograman bahasa baru (new programming language).

dan seterusnya. kegunaan. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. pembuatan model/contoh. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk. .Resiko adalah sebagai hasil ketidakcukupan informasi. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Setiap alternatif diperhitungan bertentangan dengan tujuan. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah. dan pemodelan ini akan mempengaruhi perkerjaanpekerjaan dalam rekayasa perangkat lunak tersebut. Untuk menggunakan model spiral. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa. Ini biasanya menghasilkan identifikasi sumber resiko proyek. simulasi dan seterusnya. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaikbaiknya kemudian diperhitungkan. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail. 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. resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance. Dalam contoh diatas.

dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan Rapidity. Model proses perangkat lunak masih menjadi object penelitian. Seperti produk. bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. antara lain: y Pendekatan Waterfall . yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. Robustness. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Pembuatan perangkat lunak untuk suata perubahan adalah penting. proses juga memiliki atribut dan karakteristik seperti : y y y y y y y y Understandability. apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk.Proses Di dalam suatu industri dikenal berbagai macam proses. Ini akan memperlambat proses. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas Supportability. Visibility. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. demikian juga halnya dengan industri perangkat lunak. jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga Maintainability. Model Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. 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. Contohnya. tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak.

Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable. saat ini banyak digunakan dalam pengembangan sistem. seperti spesifikasi kebutuhan. Waterfall Model ini telah diperoleh dari proses engineering lainnya. Metode penggunaan kembali (reuse) umum di jepang. langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. y Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian. pengembangan dan validasi. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian.Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Kemudian sistem disampaikan. y Transformasi formal Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. . Teknik ini menganggap bagian-bagian dari sistem sudah ada. uji coba dst. Setelah setiap langkah didefinisikan. implementasi desain perangkat lunak. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. terlalu cepat untuk berkomentar tentang keefektifannya. y Pengembangan secara evolusioner Pendekatan ini interleaves aktivitas spesifikasi. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Langkah-langkah yang penting dalam model ini adalah y Penentuan dan analisis spesifikasi Jasa. Bagaimanapun juga reuse masih suatu penelitian.

setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. perangkat lunak telah digunakan.y Desain sistem dan perangkat lunak Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Setelah ujicoba. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi. Sistem dipasang dan digunakan. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi. . Gambar 1. Masalah-masalah selama resolusi selanjutnya. biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. y Integrasi dan ujicoba sistem Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. setelah sedikit iterasi. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Selama di langkah terakhir. Pemodelan Waterfall Dalam prakteknya. sistem disampaikan ke kastamer y Operasi dan pemeliharaan Normalnya. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Sayangnya. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. Maka dari itu. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan. model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. dibiarkan atau diprogram. ini adalah phase yang terpanjang. y Implementasi dan ujicoba unit Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. Konsekuensinya. Namun demikian model waterfall mencerminkan kepraktisan engineering. Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas.

model ini memiliki masalah mendasar yaitu: y Proses tidak visibel. Pemprograman evolusioner Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. y Sistem-sistem biasanya kurang terstruktur Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Namun. pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Evolusi perangkat lunak terlihat sulit dan mahal. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. Namun. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini.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. dari segi teknik dan manajemen. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini 1. 2. y Ketrampilan khusus jarang dimiliki . Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.

Contohnya. Spiral Boehm Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Jika pemodelan digunakan. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disini. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jadi. sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Model Boehm bebrbentuk spiral.Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Contohnya. Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. tidak terlalu mahal. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Pengembangan sistem yang memiliki masa hidup yang relatif singkat. ( seperti model waterfall ). Karena masalah-masalah tersebut. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Tidak ada tahap yang tetap dalam model ini. Pengembangan evolusioner lebih tepat untuk Pengembangan sistem yang relatif kecil. Untuk memecahkan masalah-masalah tersebut. tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Setiap loop dibagi dalam 4 sektor . sistem AI dan interfaces pemakai. sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas.

Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. contohnya.1. Manajemen Resiko Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. Pada implementasinya. sebuah model pengembangan untuk sistem dipilih. Misalnya. waterfall. Pengembangan dan validasi Setelah evaluasi resiko. Pemodelan 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. Perencanaan Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Model spiral encompasses model lainnya. Kemudian dapat diikuti oleh model konvensional. Contohnya. model spiral ini juga banyak digunakan. akan dibuat analisis rincinya. Resiko adalah konsep yang sulit didefinisikan secara tepat. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. tetapi biasanya dikombinasikan dengan model yang lain. jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. model pengembangan yang sesuai adalah transformasi formal dan seterusnya. 2. yang sangat bagus dengan menggunakan prototyping. merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini. 3. Kemudian diambil langkah-langkah untuk mengurangi resiko. yang sangat bagus dalam menentukan millestones dan pemodelan spiral. Rencan rinci manajemen juga ditulis lengkap. Perkiraan dan pengurangan resiko Untuk setiap resiko yang telah diidentifikasi. 4. Pembuatan tujuan Tujuan. hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. jika bertujuan menggunakan pemprograman bahasa baru .

Dalam contoh diatas. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. demikian juga halnya dengan industri perangkat lunak. Ini biasanya menghasilkan identifikasi sumber resiko proyek. Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaikbaiknya kemudian diperhitungkan. Pemodelan Dalam Rekayasa Perangkat Lunak Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. pembuatan model/contoh. simulasi dan seterusnya. resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien.(new programming language). Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. dan seterusnya. 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. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. kegunaan. . Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Setiap alternatif diperhitungan bertentangan dengan tujuan. Proses Di dalam suatu industri dikenal berbagai macam proses. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Resiko adalah sebagai hasil ketidakcukupan informasi. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. Untuk menggunakan model spiral. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan.

Model Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. Kemudian sistem disampaikan. Sistem itu mungkin diimplementasikan kembali dengan pendekatan yang lebih terstruktur untuk menghasilkan sistem yang kuat dan maintable. y Transformasi formal Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu . dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan Rapidity. seperti spesifikasi kebutuhan. Sistem awal dengan cepat dikembangkan dari kastamer untuk memproduksi sistem yang memenuhi kebutuhan kastamer. Contohnya. yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. proses juga memiliki atribut dan karakteristik seperti : y y y y y y y y Understandability. y Pengembangan secara evolusioner Pendekatan ini interleaves aktivitas spesifikasi. Ini akan memperlambat proses. implementasi desain perangkat lunak.Seperti produk. pengembangan dan validasi. antara lain: y Pendekatan Waterfall Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah. tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak. Visibility. uji coba dst. bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. Robustness. langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga Maintainability. apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak Reliability. Setelah setiap langkah didefinisikan. yaitu sejauh mana aktivitas proses dapat didukung oleh CASE Acceptability. apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas Supportability. Model proses perangkat lunak masih menjadi object penelitian.

Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara.program. Metode penggunaan kembali (reuse) umum di jepang. Langkah-langkah yang penting dalam model ini adalah y Penentuan dan analisis spesifikasi Jasa. kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Teknik ini menganggap bagian-bagian dari sistem sudah ada. terlalu cepat untuk berkomentar tentang keefektifannya. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. saat ini banyak digunakan dalam pengembangan sistem. Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. y Implementasi dan ujicoba unit Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. y Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. y Integrasi dan ujicoba sistem . Waterfall Model ini telah diperoleh dari proses engineering lainnya. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. y Desain sistem dan perangkat lunak Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. Bagaimanapun juga reuse masih suatu penelitian. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan.

perangkat lunak telah digunakan. ini adalah phase yang terpanjang. Sayangnya. Dalam prakteknya. Sistem dipasang dan digunakan. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti.Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. dibiarkan atau diprogram. Setelah ujicoba. Masalah-masalah selama resolusi selanjutnya. Pemprograman evolusioner Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. sistem disampaikan ke kastamer y Operasi dan pemeliharaan Normalnya. Namun demikian model waterfall mencerminkan kepraktisan engineering. model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. . Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini 1. Selama di langkah terakhir. Maka dari itu. setelah sedikit iterasi. 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. model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Konsekuensinya. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain.

Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. . dari segi teknik dan manajemen. Evolusi perangkat lunak terlihat sulit dan mahal. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Namun. ( seperti model waterfall ). pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. model ini memiliki masalah mendasar yaitu: y Proses tidak visibel. kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas.2. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Untuk memecahkan masalah-masalah tersebut. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Karena masalah-masalah tersebut. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. y Sistem-sistem biasanya kurang terstruktur Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. Pengembangan evolusioner lebih tepat untuk Pengembangan sistem yang relatif kecil. y Ketrampilan khusus jarang dimiliki Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Namun. Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer.

jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. Pendekatan alternatif diusulkan oleh Boehm (1988). Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Spiral Boehm Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. tidak terlalu mahal. Perusahaan biasanya bekerja dengan beberapa model umum dengan tahap tambahan untuk proyek khusus atau ketika masala-masalah ditemukan selama pembuatan proyek. Pembuatan tujuan Tujuan. Contohnya. Jadi. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. Jika pemodelan digunakan. . Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Tidak ada tahap yang tetap dalam model ini. Model Boehm bebrbentuk spiral. Contohnya. Setiap loop dibagi dalam 4 sektor 1. Disini.Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Rencan rinci manajemen juga ditulis lengkap. sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. 2. akan dibuat analisis rincinya. Perkiraan dan pengurangan resiko Untuk setiap resiko yang telah diidentifikasi. tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. sistem AI dan interfaces pemakai. Pengembangan sistem yang memiliki masa hidup yang relatif singkat. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. Kemudian diambil langkah-langkah untuk mengurangi resiko. contohnya.

Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaikbaiknya kemudian diperhitungkan. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Model spiral encompasses model lainnya. Pada implementasinya. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail. Manajemen Resiko Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. 4. Perencanaan Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. Kemudian dapat diikuti oleh model konvensional. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. waterfall. Resiko adalah konsep yang sulit didefinisikan secara tepat. yang sangat bagus dengan menggunakan prototyping. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. jika bertujuan menggunakan pemprograman bahasa baru (new programming language). Ini biasanya menghasilkan identifikasi sumber resiko proyek. model spiral ini juga banyak digunakan. Resiko adalah sebagai hasil ketidakcukupan informasi. dan seterusnya. jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan. yang sangat bagus dalam menentukan millestones dan pemodelan spiral. model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance. Setiap alternatif diperhitungan bertentangan dengan tujuan. Pengembangan dan validasi Setelah evaluasi resiko. tetapi biasanya dikombinasikan dengan model yang lain. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah.3. resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien. Pemodelan waterfall. Contohnya. Dalam contoh diatas. Misalnya. kegunaan. pembuatan . 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. sebuah model pengembangan untuk sistem dipilih. merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini.

dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga Maintainability. Perbedaan proses yang digunakan akan menguraikan aktivitas-aktivitas proses dalam cara-cara yang berlainan. Modifikasi perangkat lunak biasanya lebih dari 60 % dari total biaya pembuatan perangkat lunak. simulasi dan seterusnya. yaitu sejauh mana aktivitas proses dapat didukung oleh CASE Acceptability. Proses perangkat lunak komplek dan melibatkan banyak aktivitas. apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas Supportability. Visibility. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya masih memungkinkan tanpa melakukan suatu pemodelan. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. Robustness. Namun beberapa proses lebih cocok dari lainnya untuk beberapa tipe aplikasi. Hal itu tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. apakah proses yang telah ditentukan oleh insinyur dapat diterima dan digunakan dan mampu bertanggung jawab selama pembuatan produk perangkat lunak Reliability. dan pemodelan ini akan mempengaruhi perkerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. Proses Di dalam suatu industri dikenal berbagai macam proses. Presentasi ini terus bertambah karena lebih banyak perangkat lunak dihasilkan dan dipelihara. Untuk menggunakan model spiral. dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan . apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. yaitu sejauh mana proses secara eksplisit ditentukan dan bagaimana kemudahan definisi proses itu dimengerti. demikian juga halnya dengan industri perangkat lunak. Seperti produk. Tipe produk yang berbeda mungkin dihasilkan oleh sebuah perusahaan dengan menggunakan proses yang berbeda. Pemodelan delam perangkat lunak merupakan suatu yang harus dikerjakan di bagian awal dari rekayasa. Perusahaan yang berbeda menggunakan proses yang berbeda untuk menghasilkan produk yang sama. Pemodelan Dalam Rekayasa Perangkat Lunak Pemodelan dalam suatu rekayasa perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk. proses juga memiliki atribut dan karakteristik seperti : y y y y y y y Understandability.model/contoh.

y Penggabungan sistem dengan menggunakan komponen-komponen yang dapat digunakan kembali. Setelah setiap langkah didefinisikan. Dua pertama dari pendekatan-pendekatan diatas yaitu waterfall dan pengembangan evolusioner. antara lain: y Pendekatan Waterfall Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah. y Pengembangan secara evolusioner Pendekatan ini interleaves aktivitas spesifikasi. uji coba dst. Proses pengembangan sistem lebih berfokus pada penggabungan bagian-bagian daripada pengembangan tiap bagian. pengembangan dan validasi. langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. saat ini banyak digunakan dalam pengembangan sistem. Ini akan memperlambat proses. 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. Model Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak. Contohnya. jika pengembangkan proses cepat dilakukan mungkin kita perlu mengurangi visibility proses karena pembuatan proses yg nyata berarti pembuatan dokumen secara teratur. Beberapa sistem sudah dibuat dengan menggunakan transformasi correctness preserving tapi ini masih menjadi penelitian. Teknik ini menganggap bagian-bagian dari sistem sudah ada. seperti spesifikasi kebutuhan. implementasi desain perangkat lunak.y Rapidity. Transformasi ini adalah correctnesspreserving ini berarti bahwa kita dapat yakin program yang dikembangkan sesuai dengan spesifikasi. Model proses perangkat lunak masih menjadi object penelitian. . y Transformasi formal Pendekatan ini berdasarkan pembuatan spesifikasi sistem formal secara matematik dan transformasi spesifikasi dengan menggunakan metode matematik atau dengan suatu program. bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi.

Gambar 1. Proses tersebut menghasilkan sebuah arsitektur sistem keseluhan. Di US metode ini dimulai 1995 dengan anggaran 150 million dolars. Uji unit termasuk pengujian bahwa setiap unit sesuai spesifikasi. Kemudian semuanya itu dibuat dalam bentuk yang dapat dimengerti oleh user dan staf pengembang. Desain perangkat lunak termasuk menghasilkan fungsi sistem perangkat lunak dalam bentuk yang mungkin ditransformasi ke dalam satu atau lebih program yang dapat dijalankan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. terlalu cepat untuk berkomentar tentang keefektifannya. Bagaimanapun juga reuse masih suatu penelitian. kendala dan tujuan dihasilkan dari konsultasi dengan pengguna sistem. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baru ditemukan. Waterfall Model ini telah diperoleh dari proses engineering lainnya. y Implementasi dan ujicoba unit Selama tahap ini desain perangkat lunak disadari sebagai sebuah program lengkap atau unit program. y Desain sistem dan perangkat lunak Proses desain sistem membagi kebutuhan-kebutuhan menjadi sistem perangkat lunak atau perangkat keras. sistem disampaikan ke kastamer y Operasi dan pemeliharaan Normalnya.Metode penggunaan kembali (reuse) umum di jepang. setiap langkah sering tumpang tindih dan saling memberi informasi satu sama lain. Setelah ujicoba. Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari . y Integrasi dan ujicoba sistem Unit program diintegrasikan dan diuji menjadi sistem yang lengkap untuk menyakinkan bahwa persyaratan perangkat lunak telah dipenuhi. Pemodelan Waterfall Dalam prakteknya. Metode ini sekiranya akan diakui oleh Eropa dan Amerika Utara. ini adalah phase yang terpanjang. Langkah-langkah yang penting dalam model ini adalah y Penentuan dan analisis spesifikasi Jasa. Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. Sistem dipasang dan digunakan.

Masalah-masalah selama resolusi selanjutnya. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. 2. 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. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata/jelas. dibiarkan atau diprogram. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan kastamer. Selama di langkah terakhir. model proses perangkat lunak yang berdasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas. Sayangnya. biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Model/contoh difikuskan pada penelitian bagian-bagian kebutuhan kastamer yang kurang dimengerti. Namun. model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini 1. Pemberhentian yang prematur dari persyaratan akan berarti bahwa sistem tidak akan sesuai dengan keinginan user. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Maka dari itu. . Namun demikian model waterfall mencerminkan kepraktisan engineering. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. setelah sedikit iterasi. perangkat lunak telah digunakan. Pemprograman evolusioner Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.aktivitas pengembangan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi. Konsekuensinya. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem.

Pengembangan evolusioner lebih tepat untuk Pengembangan sistem yang relatif kecil. sistem AI dan interfaces pemakai. tidak terlalu mahal. y Sistem-sistem biasanya kurang terstruktur Kecenderungan perubahan yang terus menerus akan mengurangi stuktrur dari perangkat lunak. ( seperti model waterfall ). sebuah sistem yang mungkin dikembangkan secara khusus untuk peluncuran produk baru. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Karena masalah-masalah tersebut. Pengembangan sistem yang memiliki masa hidup yang relatif singkat. Evolusi perangkat lunak terlihat sulit dan mahal. Jika pemodelan digunakan. sistem dikembangkan untuk mendukung beberapa aktivitas yang dibatasi oleh waktu. Pengembangan sistem atau bagian-bagian dari sistem yang besar dimana tidak memungkinkan untuk menyatakan spesifikasi secara rinci. y Ketrampilan khusus jarang dimiliki Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Disini. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Contohnya. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas. Untuk memecahkan masalah-masalah tersebut. Spiral Boehm . model ini memiliki masalah mendasar yaitu: y Proses tidak visibel.Pendekatan evolusioner biasanya lebih efektif daripada pendekatan waterfall untuk hal pengembangan perangkat lunak yang harus dengan segera dapat memenuhi kebutuhan kastamer. dari segi teknik dan manajemen. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi dan motivasi yang kuat. Namun. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Contohnya. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan meimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan.

Model Boehm bebrbentuk spiral. hambatan dalam proses ataupun produk serta resiko-resiko proyek ditentukan. tidak mudah melupakan model tersebut walaupun masih terdapat masalah-masalah yang ditimbulkan dalam model tersebut. Rencan rinci manajemen juga ditulis lengkap. akan dibuat analisis rincinya.Model proses nyata waterfall yang berorientasi dokumen telah diambil sebagai standar umum oleh banyak agen pemerintah dan pembuat perangkat lunak. Manajemen harus memutuskan bagaimana membentuk proyek kedalam tahap-tahap. Setiap loop mewakili sebuah tahap dari proses perangkat lunak. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem. 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. jika ada resiko bahwa persyaratan-persyaratan tidak tepat maka sebuah model contoh mungkin dapat dikembangkan. Pembuatan tujuan Tujuan. contohnya. Misalnya. Perkiraan dan pengurangan resiko Untuk setiap resiko yang telah diidentifikasi. Pendekatan alternatif diusulkan oleh Boehm (1988). model pengembangan yang sesuai adalah transformasi formal dan seterusnya. Kemudian diambil langkah-langkah untuk mengurangi resiko. Jadi. sebuah model pengembangan untuk sistem dipilih. jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan model contoh (prototipe) Jika resiko keselamatan yang diutamakan. Pembuatan strategi-strategi alternatif direncanakan sesuai dengan resiko yang ada. Tidak ada tahap yang tetap dalam model ini. . Boehm mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. 3. Model perbaikan tersebut juga harus memenuhi kebutuhan-kebutuhan pembuat perangkat lunak. Pengembangan dan validasi Setelah evaluasi resiko. Kita membutuhkan sebuah proses yang lebih baik untuk manajemen yang dapat menggunakan semua model umum seperti yang telah kita bicarakan sebelumnya. Perencanaan Jika diputuskan untuk melanjutkan pada loop spiral berikutnya maka proyek dibicarakan kembali dan rencana dibuat untuk tahap selanjutnya. 4. 2.

Dalam contoh diatas. resiko mungkin dapat diatasi dengan survey pasar untuk menemukan alat pengumpul mana yang dapat digunakan dan bagaimana kebaikan alat tersebut. Setiap alternatif diperhitungan bertentangan dengan tujuan.Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sisten perangkat lunak. Ini biasanya menghasilkan identifikasi sumber resiko proyek. yang sangat bagus dengan menggunakan prototyping. merupakan kombinasi yang sering dipakai di dalam kontrak-kontrak untuk perangkat lunak dewasa ini. dan seterusnya. yang sangat bagus dalam menentukan millestones dan pemodelan spiral. Manajemen Resiko Perbedaan yang mendasar antara model spiral dengan model lainnya adalah bahwa model spiral dengan eksplisit menyadari resiko-resiko yang ada. model spiral ini juga banyak digunakan. tetapi biasanya dikombinasikan dengan model yang lain. resiko yang mungkin adalah alat pengumpul yang digunakan tidak reliabel dan tidak menghasilkan code objek yang efesien. Resiko adalah sebagai hasil ketidakcukupan informasi. kegunaan. Pemodelan digunakan pada salah satu psiral untuk memecahkan masalah kebutuhan. Resiko tersebut dapat dipecahkan dengan pengenalan beberapa kegiatan yang dapat menutupi informasi yang kurang menyakinkan. Boehm menyarankan sebuah bentuk umum yang dipenuhi dalam setiap daerah spiral. . jika bertujuan menggunakan pemprograman bahasa baru (new programming language). Contohnya. simulasi dan seterusnya. pembuatan model/contoh. Siklus spiral dimulai dengan penguraian tujuan-tujuan seperti performance. Model spiral encompasses model lainnya. Jika sistem ternyata tidak sesuai maka keputusan untuk menggunakan bahasa baru harus diubah. Secara informal resiko adalah sesuatu yang sederhana yang dapat menyebabkan kesalahan. 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. Cara alternatif dalam pencapaian tujuan dan hambatan dipergunakan dengan sebaikbaiknya kemudian diperhitungkan. Langkah selanjutnya adalah mengevaluasi resiko-resiko ini dengan aktivitas seperti analisis yang lebih detail. waterfall. Kemudian dapat diikuti oleh model konvensional. Pemodelan waterfall. Untuk menggunakan model spiral. Pada implementasinya. Resiko adalah konsep yang sulit didefinisikan secara tepat. Bentuk ini mungkin dilengkapi pada sebuah level abtrak atau perkiraan rinci yang imbang dari pengembangan produk.

2. desain. Desain tadi harus diubah menjadi bentuk yang dimengerti mesin (komputer). Dalam metode ini membutuhkan pendekatan sistematis dan squencial dalam pengembangan peranglkat lunak. jarang mengikuti urutan sekuensial seperti pada teori. Proses pengumpulan kebutuhan diintensifkan ke perangkat lunak. testig dan pemeliharaan. Pada kenyataannya. karena pembuatan perangkat lunak akan dimulai ketika tahap desain sudah selesai. Testing. 4. Perangkat lunak setelah diberikan pada pelanggan. Support/Maintenance. Testing difokuskan pada logika internal dari perangkat lunak. Pemeliharaan ini dapat berpengaruh pada semua langkah yang dilakukan sebelumnya. testing dapat dimulai. Selain itu. . dimulai dari tingkat sistem dan kemajuan melalui analisis. metode ini juga masih masuk akal jika kebutuhan sudah diketahui dengan baik. Maka dilakukan langkah penulisan program. y y y y y Kelebihan dari metode WaterFall : Metode ini masih lebih baik digunakan walaupun sudah tergolong kuno. mungkin dapat ditemui error ketika dijalankan dilingkungan pelanggan. coding. Analisis Kebutuhan Perangkat Lunak (Software Requirements Analysis). Penulisan Program (Coding). Sedangkan pada tahap sebelum desain bisa memakan waktu yang lama. dan program dapat berjalan. dan mencari segala kemungkinan kesalahan. Pelanggan harus sabar. Desain (Design). Iterasi sering terjadi menyebabkan masalah baru. Hasilnya harus didokumentasikan dan di-review ke pelanggan. daripada menggunakan pendekatan asal-asalan. Kekurangan dari metode Waterfall : 1. Tahap ini sering disebut juga dengan Project Definition. Proses desain mengubah kebutuhan-kebutuhan menjadi bentuk karakteristik yang dimengerti perangkat lunak sebelum dimulai penulisan program. fungsi eksternal. Setelah kode program selesai dibuat. 3.Model Metodologi Waterfall Model ini sering juga disebut dengan classic life cycle. Sulit bagi pelanggan untuk menentukan semua kebutuhan secara eksplisit. pemodelan ini mengikuti beberapa aktivitas berikut : y Rekayasa dan Pemodelan Sistem/Informasi (System/Information Engineering and Modeling). Kesalahan di awal tahap berakibat sangat fatal pada tahap berikutnya.

siapa yang membuat informasi itu. Model RAD menekankan pada fase-fase berikut : 1. kemana saja informasi mengalir. . Model ini memecah suatu proyek menjadi bagian-bagian kecil yang mana tiap bagiannya dibangun dengan model yang mirip dengan Waterfall. Business modeling. Tujuan utama model ini adalah menyelesaikan suatu proyek per bagian. Pada tahap ini. dan siapa yang mengolahnya.Model Metodologi RAD Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya siklus pengembangan. informasi apa yang hasilkan. aliran informasi (information flow) pada fungsifungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis. sehingga proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara global) .

Kecuali untuk komponenkomponen baru. Tidak semua project bisa dipecah (dimodularisasi). Karena dibuat dengan reuse komponen-komponen yang sudah ada. maka dibutuhkan banyak orang untuk membentuk suatu tim yang mengerjakan tiap bagian tersebut. 4. Juga jika proyek memungkinkan untuk dimodularisasi. Pengolahan deskripsi dibuat untuk menambah. Testing and turnover. Application generation. 3. Data modeling. Sekuensial Linier (Waterfall) Model Keunggulan: y software yang dikembangkan dengan metode ini biasanya menghasilkan kualitas yang baik. Sehingga pada tahap ini sangat jarang digunakan pemrograman konvensional menggunakan bahasa pemrograman generasi ketiga (third generation programming languages). Karakteristik (atribut) setiap objek ditentukan beserta relasi antar objeknya. 3. alat bantu untuk otomatisasi digunakan untuk memfasilitasi pembuatan perangkat lunak. sebagian komponen-komponen tersebut sudah diuji sebelumnya. Aliran informasi yang didefinisikan dari business modeling. Process modeling. Kekurangan : 1. disaring lagi agar bisa dijadikan bagian-bagian dari objek data yang dibutuhkan untuk mendukung bisnis tersebut. sehingga belum tentu RAD dipakai pada semua proyek. tetapi lebih ditekankan pada reuse komponen-komponen (jika ada) atau membuat komponen baru (jika perlu). Kelebihan : RAD memang lebih cepat dari Waterfall. merubah.2. 2. Membutuhkan komitmen antara pengemang dengan pelanggan. RAD bekerja dengan menggunakan fourth generation techniques (4GT). fasilitas-fasilitas pada tiap komponen belum tentu digunakan seluruhnya oleh program yang me-reuse-nya sehingga kualitas program bisa menurun. Dalam semua kasus. Karena project dipecah menjadi be berapa bagian. menghapus. jika kebutuhan dan batasan project sudah diketahui dengan baik. 5. atau mengambil kembali objek data. Objek-objek data yang didefinisikan sebelumnya diubah agar bisa menghasilkan aliran informasi untuk diimplementasikan menjadi funsi bisnis. Sehingga mengurangi waktu testing secara keseluruhan. Karena menekankan pada penggunaan kembali komponen yang telah ada (reuse). . 4.

karena proses pengembangan tidak dapat berulang sebelum menghasilkan suatu produk. dalam arti metode ini kurang cocok bagi pemula. 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. Jadi apabila dalam suatu proses seperti perancangan tidak selesai tepat waktu. membutuhkan resources yg baik dan solid · Membutuhkan komitmen pengembang dan user yang sama agar cepat selesai sesuai dengan rencana . yaitu aplikasi.y Document pengembangan sistem sangat terorganisir. maka akan mempengaruhi keseluruhan proses pengembangan perangkat lunak. karena setiap fase harus terselesaikan dengan lengkap sebelum melangkah ke fase berikutnya. Diperlukan majaemen yang baik. Kekurangan : y y membutuhkan keahlian yang baik atau yang telah berpengalaman dalam mengembangkan perangkat lunak. 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).

Menggunakan model reuse. Extreme Programming Keunggulan : . · 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.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. Sistem yang tidak bisa dimodularisasi tidak cocok untuk model ini. pada komponen yang sudah mewakili kebutuhan umum. Kelemahan : · · Model ini bersifat iteratif atau berulang-ulang prosesnya.

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. waktu). Feedback / Masukan/Tanggapan: Setiap feed back ditanggapi dengan melakukan tes. Prinsip-prinsip perancangan perangkat lunak menjadi basis proses rekayasa aplikasi bisnis telah banyak di terapkan. langsung diperbaiki. Kedua metodologi tersebut adalah Waterfall dan Spiral. Keberhasilan pengembangan perangkat lunak bergantung pada pengelolaan proyek perangkat lunak secara keseluruhan. Courage / Berani: Banyak ide baru dan berani mencobanya. 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. tenaga.y y y y Communication/Komunikasi : Komunikasi dalam XP dibangun dengan melakukan pemrograman berpasangan (pair programming). Tidak bisa membuat kode yang detail di awal (prinsip simplicity dan juga anjuran untuk melakukan apa yang diperlukan hari itu juga). Komunikasi yang lebih banyak mempermudah. Developer didampingi oleh pihak klien dalam melakukan coding dan unit testing sehingga klien bisa terlibat langsung dalam pemrograman sambil berkomunikasi dengan developer. Pendahuluan. 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.1. berani mengerjakan kembali dan setiap kali kesalahan ditemukan. sementara metodologi Spiral (iterative) menerapkan model proses secara sirkular tanpa adanya cekpoint atau milestone. dan rancangan yang sederhana mengurangi penjelasan. Perancangan dimulai dengan menetapkan kebutuhan perangkat lunak tersebut sampai pada implementasi dan penyebaran atau distribusi. unit test atau system integration dan jangan menunda karena biaya akan membengkak (uang. Menetapkan sebuah metodologi yang memiliki . Selain itu perkiraan beban tugas juga diperhitungkan. 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. Dalam pengembangan sebuah perangkat lunak dibutuhkan suatu metodologi yang akan memandu tim pengembang dalam merancang perangkat lunak. Dimana sebuah metodologi merupakan kerangka pijakan utama dalam perancangan perangkat lunak profesional untuk menghasilkan aplikasi yang sesuai dengan kebutuhan bisnis sebuah organisasi. PENGANTAR MODEL PROSES PERANCANGAN PERANGKAT LUNAK 1. Metodologi Waterfall menggambarkan sebuah model proses yang statis dengan tahapan-tahapan berlapis yang menggunakan sebuah milestone sebagai transisi pada setiap tahap perancangan. Kelemahan : y y y y y y y y Developer harus selalu siap dengan perubahan karena perubahan akan selalu diterima.

Microsoft Solution Framework (MSF) adalah metodologi perancangan dan pengembangan aplikasi bisnis yang diperkenalkan oleh sebuah vendor software besar yaitu Microsoft Corporation. Model ini menggunakan milestone sebagai titik transisi dan pengujian. Model Microsoft Solution Framework (MSF) 1. y y Gambar 1. Kondisi semacam ini akan sangat berpengaruh pada perangkat lunak dan menimbulkan masalah terhadap kebutuhan iterasi dimana aplikasi akan terus berkembang dengan penyesuaianpenyesuaian terhadap kebutuhan. Model proses merupakan tahap-tahap aktivitas proyek yang menggambarkan daur hidup suatu proyek. 1. maka akan memudahkan tim pengembang perangkat y . Model Proses Waterfall (Sequential). dan memberikan hasil yang dapat diprediksi (model spiral/iterative) disertai umpan balik dan kreativitas dari tim pengembang.2. Prinsip-prinsip pengembangan perangkat lunak dengan metodologi MSF memiliki perencanaan berbasis milestone (model waterfall).dinamisasi tinggi dalam tahap-tahap perancangan model proses perangkat lunak akan sangat berpengaruh pada kualitas perangkat lunak yang dihasilkan. 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.1. artinya setiap aktivitas pada tahap pengembangan harus diselesaikan sebelum menuju tahap pengembangan berikutnya. Model Proses Pengembangan Perangkat Lunak. Model Spiral/Iterative y y y y Gambar 3. Model Waterfall Gambar 2. proses bisnis dan lingkungan aplikasi yang terus berubah dari waktu kewaktu.2. Namun kelebihan dari model ini adalah karena adanya titik transisi yang jelas pada setiap tahap.

oleh karena perubahan kebutuhan adalah sesuatu yang wajar terjadi. dan terbagi menjadi beberapa bagian sub-proyek. y . Tahapan Pada Model Proses Waterfall (Sommervile.y y y y lunak dalam memonitor penjadwalan proyek. c. Fase sebelumnya harus lengkap dan selesai sebelum memasuki tahap berikutnya. 1. b. sekaligus melakukan pengujian terhadap unit-unit program yang telah dibuat. logikal dan fisikal . 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. Aspek perubahan pada perangkat lunak sulit dilakukan karena sifatnya yang kaku dimana kebutuhan perangkat lunak harus lengkap. Implementation and unit testing : pada tahap ini desain yang telah di rancang diimplementasikan dengan menterjemahkan ke dalam kode-kode program menggunakan sebuah bahasa pemrograman. System and software design : pada tahap ini tim pengembang mendesain sistem dan aplikasi meliputi desain konseptual. Akan tetapi pada kenyataannya sangat jarang sekali pengguna dapat mendefinisikan kebutuhan awal secara lengkap. y y y y y y Gambar 4. 4. model waterfall menggunakan tahapan-tahapan seperti air terjun. Karena sifat kakunya. Beberapa kendala yang muncul pada model waterfall adalah : a. Integration and system testing : tim pengembang menyatukan unit-unit program kemudian melakukan pengujian sistem perangkat lunak secara keseluruhan. dimana tahapan-tahapan tersebut terbagi menjadi lima tahapan. Kelemahan dari model ini adalah adanya kendala dalam mengakomodasi perubahan setelah proses pengembangan telah berjalan. 2001) Sesuai dengan namanya ³waterfall´ atau air terjun. 2. menetapkan tanggung jawab dan akuntabilitas peran personal dalam proyek perangkat lunak. Waterfall pada umumnya digunakan untuk rekayasa sistem perangkat lunak berkapasitas besar dimana proyek dikerjakan di beberapa tempat berlainan. 3. model ini cocok manakala kebutuhan telah dikumpulkan secara lengkap sehingga perubahan bisa ditekan sekecil mungkin.

Operation and maintenance : tim pengembang melakukan pengoperasian program dan melakukan pemeliharaan terhadap perangkat lunak dengan penyesuaian atau perubahan terhadap situasi sebenarnya.2.2. Oleh karenanya model ini hanya sesuai untuk aplikasi-aplikasi kecil yang tidak terintegrasi dan terdistribusi. 1. . y y Gambar 5. Model ini berbasiskan pada kebutuhan terhadap aplikasi secara keberlanjutan untuk menyaring kebutuhan-kebutuhan tersebut dan estimasi proyek secara keseluruhan. Model Proses Spiral (Iterative).y y y y 5. Dengan adanya feedback dari pelanggan maka estimasi waktu terhadap penyelesaian proyek perangkat lunak menjadi semakin jelas. 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. Kebutuhan waktu untuk pengembangan aplikasi yang cepat dengan kapasitas proyek yang relatif kecil sangat relefan dengan model spiral ini. 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. 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. Tahapan Pada Model Proses Spiral (Boehm.

Dengan menggunakan UML akan berdampak pada peningkatan produktifitas dan dan kualitas serta pengurangan biaya dan waktu... perangkat lunak.. construct dan evaluate (Dean Muench.. mengkompilasi rancangan berikutnya. mengkompilasi (software-build) rancangan awal. Dengan demikian. 2. mulai dari 2004 sampai 2006. Meskipun waterfall adalah model pembangunan perangkat lunak tertua. Hasil iterasi dari model ini nantinya akan berupa prototype software yang berfungsi sebagai gambaran umum kepada klien. programer dapat menyiapkan dokumentasi yang lebih terinci yang hasil akhirnya adalah software library dari . 3. Analisis persyaratan kadang-kadang memerlukan individu / tim dari klien serta sebagai pihak . biasanya pada prototype hanya terdapat interface dan fungsi dasar. . .. jaminan kualitas dan mekanisme kontrol pada setiap proyek. Empat penelitian lainnya relatif baru-baru ini. dimana setiap quadrant merepresentasikan sebuah manajemen proses dengan tahapan-tahapan identify. design. Ide dibalik pendekatan berorientasi . perancangan perangkat lunak. tim proyek mulai menggunakan pendekatan berorientasi obyek.. . .y y y y y Model spiral terbagi menjadi empat quadrant. adalah proses pembuatan dan pengubahan sistem serta model dan metodologi yang digunakan untuk . SDLC (Systems Development Life Cycle ) siklus hidup pengembangan sistem)... 1994).. Metode dalam model proses. mengevaluasi hasil dengan melibatkan pemakai. mengevaluasi hasil dengan melibatkan pemakai. rencana pengujian. menarik untuk dicatat bahwa hanya salah satu dari lima penelitian dari beberapa waktu yang lalu (1988). dalam rekayasa sistem dan rekayasa perangkat lunak. Mendefinisikan tujuan dan kebutuhan bisnis. mengembangkan desain logikal. dan analisis terhadap resiko dengan melibatkan pemakai.. validasi.. Ketika perusahaan memutuskan untuk menciptakan sendiri perangkat lunak aplikasinya. dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan... mengkompilasi rancangan akhir. mengevaluasi keselur y y y y y y y Result Waterfall sebagai model rekayasa perangkat lunak Model Mengambil kegiatan dasar seperti spesifikasi..... tindakan rekayasa perangkat lunak.air terjun (waterfall) pengembangan. Fungsi-fungsi yang ada di prototype masih standar. dimana modul yang mengandung komponen itu disebut objek (yang mengandung data dan proses) digunakan sebagai blok bangunan untuk sistem. mengembangkan desain konseptual. 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 .. tugas. 4. . Rangkaian tugas ini meliputi aktivitas kerangka kerja. produk kerja. mendapatkan sumber daya perangkat lunak.. Waterfall model .. Sistem akan melalui tahapan-tahapan proses yang akan berulang sebagai berikut : 1. Mendefinisikan kebutuhan sistem. rancangan konsep. Mendefinisikan kebutuhan setiap unit... menghasilkan desain fisikal. UML (Unified Modelling Language) adalah bahasa pemodelan standar pada rekayasa perangkat lunak. menghasilkan desain akhir. Mendifinisakan kebutuhan subsistem.

. . 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 .... Sering ada menjadi banyak dan dari komunikasi untuk memahami persyaratan tersebut. .y penyedia layanan untuk mendapatkan detail dan akurat persyaratan .

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->