Usaha untuk mengatasi permasalahan rekayasa perangkat lunak

Masalah perangkat lunak (software engineering) biasanya dipilih berdasarkan 3 aspek antara lain sifat dari proyek dan aplikasi, metode dan alat bantu yang digunakan serta kontrol dan output yang dibutuhkan. Perekayasaan perangkat lunak berupa penggunaan metode pengembangan perangkat lunak berkualitas tinggi secara ekonomi dan handal. Dari usaha-usaha tersebut dihasilkan alternatif paradigma, alternatif metodologi dan perangkat bantu komputer.

1. Siklus Hidup

Pengesetan dan piranti teknik serta metode yang digunakan oleh para ahli software dalam proyek disebut Metodologi Proyek. Metodologi proyek diterapkan dalam konteks tahap-tahap pengembangan software (software live cycle) , yang disebut fase, yang merupakan tahapan yang harus dilalui oleh produk software dari konsep awal sampai tahap akhir. Model tahap-tahap tersebt merupakan enyajian dari tahap-tahap pengembangan software yang juga dapat berisikan alur informasi, saat penentuan keputusan, dan sebagainya.

Langkah-langkah dari model tahapan penyusunan dapat merupakan fase temoporal yang membentuk urutan dalam waktu atau fase logis yang menunjukkan tahap-tahap bukan membentuk urutan temporal. Sebagai contoh implementasi secara logis akan mendahului pengujian, namun bagian fase implementasi dan pengujian dapat terjadi secara serempak. Jadi moedl tahapan yang menggunakan fase logis dapat memiliki fase implementasi sebelum fase pengujian, sedangkan model yang menggunakan fase temporal mungkin fase-fase ini kan bertumpang tindih.

2. Model Spiral

Permodelan dalam suatu perangkat lunak merupakan suatu hal yang dilakukan di tahapan awal. Di dalam suatu rekayasa dalam perangkat lunak sebenarnya maih memungkinkan tanpa melakukan suatu permodelan. Hal ini tidak dapat lagi dilakukan dalam suatu industri perangkat lunak. Permodelan dalam perangkat lunak merupakan suatu yang harus ikerjakan di bagian awal dari rekayasa, dan permodelan ini akan mempengaruhi pekerjaan-pekerjaan dalam rekayasa perangkat lunak tersebut. dalam prakteknya, setiap langkah sering tumpang tindih dan sering memberi informasi satu ama lain.

Proses perangkat lunak tidak linier dan sederhana tapi mengandung urutan iterasi dari aktivitas pengembangan. Selama langkah terakhir, perangkat lunak telah digunakan. Kesalahan dan kelalaian dalam menentukan kebutuhan perangkat lunak original dapat diatasi.

Namun sayang, model yang banyak mengandung iterasi sehingga membuat kesulitan bagi pihak manajemen untuk memeriksa seluruh rencana dan laporan. Maka dari itu, seteleh sedikit iterasi, biasanya bagian yang telah dikembangkan akan dihentikan dan dilanjutkan dengan keinginan user. Mungkin juga sistem terstruktur secara jelek yang sebenarnya merupakan masalah desain akan dibiarkan karena terkalahkan oleh trik implementasi.

3. Pendekatan Waterfall

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

  • Penentuan dan analisis spesifikasi
  • Desain sistem dan perangkat lunak
  • Implementasi dan ujicoba unit
  • Integrasi dan uji coba sistem
  • Operasi dan pemeliharaan

Masalah pendekatan waterfall adalah ketidakluwesan pembagian project ke dalam langkah yang nyata atau jelas. Sistem yang disampaikan kadang-kadang tidak dapat digunakan sesuai keinginan customer. Namun demikian model waterfall mencerminkan kepraktisan engineering. Konsekwensinya, model proses perangkat lunak yang bredasarkan pada pendekatan ini digunakan dalam pengembangan sistem perangkat lunak dan hardware yang luas.
4. Pendekatan Evolusioner

Pendekatan evolusioner ini berdasarkan pada ide pengembangan dan implementasi awal yang akan menghasilkan komentar pemakai sehingga dapat dilakukan perbaikan melalui banyak versi sampai sistem yang mencukupi dapat dikembangkan. Selain memiliki kegiatan-kegiatan terpisah model ini memberikan umpan balik dengan cepat dan serempak. Ada 2 tipe pada model ini yaitu :

a. Pemrogramaman evolusioner

    Tujuan proses adalah bekerja sama dengan cusomer untuk menghasilakan kebutuhan-kebutuhan dan menyampaikan sistem akhir kepada pemakai/ customer. Pengembangan dimulai dengan bagian-bagian sistem yang dimengerti. Sistem dikembangkan melalui penambahan features sesuai yang diusulkan oleh customer. 2.

    b. Pemodelan

    Pemrograman evolusioner penting saat sulit untuk membuat spesifikasi sistem secara rinci. Beberapa orang mungkin setuju bahwa semua sistem masuk dalam tipe ini. Namun, pemrograman evolusioner banayk digunakan dalam pengembangan sistem pakar (artifacial intelegence) yang berusaha untuk menyamai kemampuan manusia.

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

    • proses tidak visibel
    • sistem biasanya kurang terstruktur
    • ketrampilan khusus jarang dimiliki

      Untuk memecahkan masalah-masalah tersebut, kadang-kadang tujuan dari pengembangan evolusioner adalah mengembangkan contoh sistem. Contoh ini digunakan untuk mengerti dan memvalidasikan spesifikasi sistem. Disinilah pengembangan evolusioner merupakan bagian dari beberapa proses yang lebih luas (seperti model waterfall).

      Oleh karena masalah-masalah tersebut, sistem dengan skala besar biasanya tidak dikembangkan melalui cara ini. Pengembangan evolusioner lebih tepat untuk pengembangan yang relatif kecil. Masalah-masalah mengenai perubahan sistem yang ada dihindari dengan mengimplementasikan ulang sistem keseluruhan kapanpun perubahan yang signifikan diperlukan. Jika permodelan digunakan, tidak terlalu mahal. Pengembangan sistem yang memiliki masa hidup yang relatif singkat.

      5. Spiral Boehm

      Boehm (1988) mengusulkan sebuah model yang secara eksplisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model umum. Model yang diusulkan oleh Boehm ini berbentuk spiral. Tak ada tahap yang ditetapkan dalam model ini. Manajemen harus memutuskan bagaimana membentuk proyek ke dalam tahap-tahap. Perusahaan biasanya bekerja dengan beberapa model umum dengan tambahan untuk proyek khusus atau ketika masalah-masalah ditemukan selama pembuatan proyek. Setiap loop dibagi dalam 4 sektor yaitu :

      • Pembuatan tujuan

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

      • Perkiraan dan pengurangan resiko

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

      • Pengembangan dan validasi
      Setelah evaluasi resiko, jika resiko sebuah model pengembangan untuk sistem dipilih. Misalnya, jika resiko interface pengguna yang dominan maka model pengembangan yang tepat mungkin pengembangan evolusioner dengan menggunakan contoh (prototype). Jika resiko keselamatan yang diutamakan, model pengembangan sesuai adalah transformasi formal. Model waterfall mungkin tepat digunakan jika resiko yang diutamakan adalah integrasi sistem.
      • Perencanaan

      Jika diputuskan untuk melanjutkan pada loop spiral berikutnya, maka prosyek yang dibicarakan kembalai dan rencana perlu dibuat untuk tahap selanjutnya. Tidak perlu untuk menggunakan satu model tunggal pada setiap loop spiral bahkan dalam keseluruhan sistem perangkat lunak. Model spiral encompasses model lainnya. Pemodelan digunakan pada salah satu spiraluntuk memecahkan masalah kebutuhan.

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

      DAFTAR BACAAN

      Adri Kristianto, Rekayasa Perangkat Lunak (Konsep Dasar), Gava Media Yogyakarta, 2004

      Al Bahra bin Ladjamuddin, Rekayasa Perangkat Lunak, Graha Ilmu, Yogyakarta, 2004

      Barbee Teasley Mynatt, Software Engineering with Student Project Guidance, Prentice Hall Int. 1990.

      3 Balasan ke Usaha untuk mengatasi permasalahan rekayasa perangkat lunak

      1. agus sukoco mengatakan:

        ya itu adalah solusi untuk software engineering

      2. EWIN mengatakan:

        tambahin dong materinya

      3. goesty mengatakan:

        kirimin donk link2 untuk mencari dampak dari pengembangan perangkat lunak dan permasalahan yang ditimbulkan akibat dampak tersebut. thanks sblm na..

      Tinggalkan Balasan

      Isikan data di bawah atau klik salah satu ikon untuk log in:

      Logo WordPress.com

      You are commenting using your WordPress.com account. Logout / Ubah )

      Gambar Twitter

      You are commenting using your Twitter account. Logout / Ubah )

      Foto Facebook

      You are commenting using your Facebook account. Logout / Ubah )

      Foto Google+

      You are commenting using your Google+ account. Logout / Ubah )

      Connecting to %s

      %d blogger menyukai ini: