Pengembangan Sistem Evolusioner pada RPL

        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, yaitu :

1. Pemprograman evolusioner
        Dimana tujuan proses adalah bekerjasama dengan pelanggan untuk menghasilkan kebutuhan‐kebutuhan dan menyampaikan sistem akhir kepada pemakai atau pelanggan. Pengembangan dimulai dengan bagian‐bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features
sesuai yang diusulkan oleh pelanggan.

2. Pemodelan
        Dimana tujuan pengembangan evolusioner pada tipe ini adalah mengetahui kebutuhan‐kebutuhan pelanggan dan mengembangkan difinisi kebutuhan yang lebih baik untuk sistem. Model/contoh difikuskan pada penelitian bagian‐bagian kebutuhan pelanggan yang kurang dimengerti.

        Pemprograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemprograman evolusioner banyak digunakan dalam pengembangan sistem AI (artificial intelligence) yang berusaha untuk menyamai kemampuan manusia. Kita tidak mungkin membuat spesifikasi yang rinci untuk perangkat lunak yang menyamai manusia karena kita tidak mengerti bagaimana manusia menjalankan tugas‐tugas mereka.

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

•  Proses tidak visibel.

Manager‐manager membutuhkan "deliverables" yang teratur untuk mengukur kemajuan. Jika sistem dikembangkan dengan cepat akan terjadi pemborosan pada pembuatan dokumen yang menggambarkan setiap versi sistem.

•  Sistem‐sistem biasanya kurang terstruktur

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

•  Ketrampilan khusus jarang dimiliki

Tidak jelas batasan ketrampilan yang normal dalam rekayasa perangkat lunak yang mungkin dapat digunakan secara efektif dalam model pengembangan ini. Kebanyakan sistem yang dikembangkan melalui cara ini telah diimplementasikan oleh kelompok kecil yang memiliki ketrampilan yang tinggi
dan motivasi yang kuat.


       Untuk memecahkan masalah‐masalah tersebut, kadang‐kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan mevalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas ( seperti model waterfall ). Karena masalah‐masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk pengembangan sistem yang relatif kecil. Masalah‐masalah mengenai perubahan sistem yang ada dihindari dengan mengimplementasi ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika pemodelan digunakan, tidak terlalu mahal.

Read More

pengertian QoS ( Quality of Service )

QoS merupakan kependekan dari Quality of Service. Dalam buku Quality of Service yang ditulis oleh Paul Ferguson, didefinisikan bahwa QoS adalah suatu pengukuran tentang seberapa baik jaringan dan merupakan suatu usaha untuk mendefinisikan karakteristik dan sifat dari suatu servis. QoS biasanya digunakan untuk mengukur sekumpulan atribut performansi yang telah dispesifikasikan dan biasanya diasosiasikan dengan suatu servis. Pada jaringan berbasis IP, IP QoS mengacu pada performansi dari paket-paket IP yang lewat melalui satu atau lebih jaringan.

QoS didesain untuk membantu end user menjadi lebih produktif dengan memastikan bahwa dia mendapatkan performansi yang handal dari aplikasi-aplikasi berbasis jaringan.

QoS mengacu pada kemampuan jaringan untuk menyediakan layanan yang lebih baik pada trafik jaringan tertentu melalui teknologi yang berbeda-beda. QoS merupakan suatu tantangan yang cukup besar dalam jaringan berbasis IP dan internet secara keseluruhan. Tujuan dari QoS adalah untuk memuaskan kebutuhan-kebutuhan layanan yang berbeda, yang menggunakan infrastruktur yang sama. QoS menawarkan kemampuan untuk mendefinisikan atribut-atribut layanan jaringan yang disediakan, baik secara kualitatif maupun kuantitatif.

Read More

Langkah‐langkah dalam Pengembangan Sistem Waterfall

Model ini menawarkan cara pembuatan perangkat lunak secara lebih nyata. Langkah‐langkah yang penting dalam model ini adalah :

1. 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.

2. 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.

3.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.

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

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

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

       Sayangnya, model yang banyak mengandung iterasi sehingga membuat sulit bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, setelah sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan langkah pengembangan selanjutnya. Masalahmasalah 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 pelanggan. 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.

Read More