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.

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

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

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

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

Jika proses yang salah digunakan akan mengurangi kualitas kegunaan produk yang dikembangkan. Setelah setiap langkah didefinisikan. 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. 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. tapi sekarang ada banyak model umum atau paradigma yang berbeda dari pengembangan perangkat lunak. 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. Ini akan memperlambat proses. Robustness.cocok dari lainnya untuk beberapa tipe aplikasi. Seperti produk. Visibility. bagaimana kecepatan proses pengiriman sistem dapat secara lengkap memenuhi spesifikasi. seperti spesifikasi kebutuhan. apakah aktivitas-aktivitas proses mencapai titik akhir dalam hasil yang jelas sehingga kemajuan dari proses tersebut dapat terlihat nyata/jelas Supportability. y Pengembangan secara evolusioner . dapatkah proses berkembang untuk mengikuti kebutuhan atau perbaikan Rapidity. langkah tersebut di sign off dan pengembangan dilanjutkan pada langkah berikutnya. dapatkah proses terus berjalan walaupun terjadi masalah yang tak diduga Maintainability. Karena banyaknya variasi dalam model proses yang digunakan maka tidak mungkin menghasilkan gambaran-gambaran yang reliabel untuk alokasi biaya dalam aktivitas-aktivitas ini. Model Tidak mungkin untuk mengoptimalkan semua atribut proses secara serentak. yaitu sejauh mana aktivitas proses dapat didukung oleh CASE Acceptability. uji coba dst. proses juga memiliki atribut dan karakteristik seperti : y y y y y y y y Understandability. implementasi desain perangkat lunak. apakah proses didesain sedikian rupa sehingga kesalahan proses dapat dihindari sebelum terjadi kesalahan pada produk. Contohnya. antara lain: y Pendekatan Waterfall Berisi rangkaian aktivitas proses seperti yang telah diuraikan diatas dan disajikan dalam proses yang terpisah. Pembuatan perangkat lunak untuk suata perubahan adalah penting. Proses perangkat lunak komplek dan melibatkan banyak aktivitas.

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

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

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

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

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

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

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

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

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

dari segi teknik dan manajemen. Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh kastamer. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas-tugas mereka. Pemodelan Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhankebutuhan kastamer dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Pemprograman evolusioner Dimana tujuan proses adalah bekerjasama dengan kastamer untuk menghasilkan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/kastamer. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem. model ini memiliki masalah mendasar yaitu: y Proses tidak visibel. 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. y Ketrampilan khusus jarang dimiliki . Selain memiliki aktivitas-aktivitas yang terpisah model ini memberikan feedback dengan cepat dan serentak Terdapat 2 tipe pada model ini 1. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Namun. Evolusi perangkat lunak terlihat sulit dan mahal. Namun. Manager-manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan.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. 2. 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pada tahap ini. aliran informasi (information flow) pada fungsifungsi bisnis dimodelkan untuk mengetahui informasi apa yang mengendalikan proses bisnis. informasi apa yang hasilkan.Model Metodologi RAD Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya siklus pengembangan. . siapa yang membuat informasi itu. sehingga proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara global) . 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. dan siapa yang mengolahnya. kemana saja informasi mengalir. Model RAD menekankan pada fase-fase berikut : 1.

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

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

Kelemahan : · · Model ini bersifat iteratif atau berulang-ulang prosesnya. pada komponen yang sudah mewakili kebutuhan umum. · Teknik dan tools yang tidak optimal pada prototipe yang akan tetap digunakan pada softare sesungguhnya Component Based Model Keunggulan : · · Lebih memungkinkan untuk mengurangi beban biaya dan waktu pengembangan. Menggunakan model reuse.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. Extreme Programming Keunggulan : .

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

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

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

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

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

. . Salah satu strategi yang sering dipakai sebagai model proses atau paradigma rekayasa perangkat lunak yaitu dengan menggunakan model waterfall.y penyedia layanan untuk mendapatkan detail dan akurat persyaratan . .... Model waterfall merupakan pendekatan perangkat lunak yang sistematik dan sekuensial yang . Sering ada menjadi banyak dan dari komunikasi untuk memahami persyaratan tersebut.

Sign up to vote on this title
UsefulNot useful