Proses, oleh Adi S [5105 100 011], Trendyka Z [5105 100 075], M Ali Mas’ud [5105 100 030]

Note: Semuanya menyerahkan tulisannya dalam keadaan yang amat sangat mirip

Definisi Pengembangan Perangkat Lunak

Fritz Bauer memberikan definisi bahwa Rekayasa Perangkat Lunak merupakan pengembangan dan penggunaan prinsip pengembangan suara untuk memperoleh perangkat lunak secara ekonomis yang reliable dan bekerja secara efisien pada mesin nyata.

Sedangkan IEEE telah mengembangkan definisi yang lebih komperhensif yaitu bahwa rekayasa perangkat lunak :

1. Aplikasi dari sebuah pendekatan kuantitatif, disiplin, dan sistematis kepada pengembangan, operasi, dan pemeliharaan perangkat lunak yaitu : aplikasi dari Rekayasa Perangkat Lunak.

2. Studi tentang pendekatan – pendekatan seperti pada nomor 1.


Proses, Metode, dan Alat Bantu

Rekayasa perangkat lunak merupakan sebuah teknologi yang dibentangkan. Banyak pendekatan keteknikan yang harus berada pada sebuah komitmen dasar menuju kualitas. Batu landasan yang menopang rekayasa perangkat lunak merupakan fokus pada kualitas. Fondasi untuk rekayasa perangkat lunak merupakan bentangan proses. Proses – proses rekayasa perangkat lunak adalah perekat yang menjaga bentangan – bentangan teknologi secara bersama – sama dan memungkinkan perkembangan perangkat lunak komputer yang tepat waktu dan rasional. Metode – metode rekayasa perangkat lunak memberikan teknik untuk membangun perangkat lunak. Metode – metode itu menyangkut seragkaian tugas yang luas yang menyangkut analisis kebutuhan, konstruksi program, desain, pengujian, dan pemeliharaan. Rekayasa perangkat lunak mengandalkan pada serangkaian prinsip dasar yang mengatur setiap area teknologi dan menyangkut aktivitas permodelan serta teknik – teknik deskriptif yang lain.

Tool – tool rekayasa perangkat lunak memberikan topangan yang otomatis maupun semi-otomatis pada proses – proses dan metode – metode yang ada. Ketika tool – tool diintegrasikan sehingga informasi yang diciptakan oleh satu tool bias digunakan oleh yang lain, system untuk menopang perkembangan perangkat lunak yang disebut computer-aided software engineering (CASE) terbangun. CASE menggabungkan perangkat lunak, perangkat keras, dan database rekayasa perangkat lunak untuk menciptakan lingkungan rekayasa perangkat lunak yang analog dangan CAD/CAE (Computer Aided Design/Engineering) untuk perangkat keras.

Pandangan Umum Tentang Rekayasa Perangkat Lunak

Rekayasa merupakan analisis, desain, konstruksi, verifikasi, dan manajemen kesatuan teknik (atau sosial). Tanpa memperdulikan kesatuan yang dikembangkan, pertanyaan – pertanyaan berikut harus dimunculkan dan dijawab :

1. Masalah apakah yang akan dipecahkan?

2. Karakteristik kesatuan apakah yang dipakai untuk menyelesaikan masalah tersebut?

3. Bagaimanakah kesatuan (pemecahan tersebut) diadakan?

4. Bagaimanakah kesatuan tersebut dibangun?

5. Pendekatan apakah yang akan dipakai untuk menemukan kesalahan – kesalahan yang dibuat didalam desain dan konstruksi dari kesatuan tersebut?

6. Bagaimananakah kesatuan tersebut ditopang selama proses adaptasi yang lama, pada saat koreksi, serta ketika perbaikan dibutuhkan oleh para pemakai kesatuan tersebut.

Usaha yang berhubungan dengan rekayasa perangkat lunak dapat dikategorikan ke dalam tiga fase umum dengan tanpa memperdulikan area aplikasi, ukuran proyek, atau kompleksitasnya. Masing – masing fase akan memberi tekanan pada pertanyaan – pertanyaan yang telah ditulis diatas.

Fase definisi (Definition Phase) berfokus pada “apa”; dimana pada definisi ini pengembang perangkat lunak harus mengidentifikasi informasi apa yang akan diproses, fungsi dan unjuk kerja apa yang dibutuhkan, tingkah laku system seperti apa yang diharapkan, interface apa yang akan dibangun, batasan desain apa yang ada, dan kriteria validasi apa yang dibutuhkan untuk mendefinisikan sistem yang sukses.

Fase pengembangan (Development Phase) berfokus pada how (bagaimana) yaitu dimana selama masa pengembangan perangkat lunak, teknisi harus mendefinisikan bagaimana dat dikonstruksikan, bagaimana fungsi – fungsi diimplementasikan, bagaimana interface ditandai, bagaimana rancangan akan diterjemahkan ke dalam bahasa pemrograman, serta bagaimana pengujian akan dilakukan.

Fase pemeliharaan (Maintenance Phase) berfokus pada perubahan, yang dihubungkan dengan koreksi kesalahan, penyesuaian yang dibutuhkan ketika lingkungan perangkat lunak berkembang, serta perubahan sehubungan dengan perkembangan yang disebabkan oleh perubahan kebutuhan pelanggan. Fase pemeliharaan mengaplikasikan lagi langkah – langkah pada fase definisi dan fase pengembangan, tetapi semuanya tetap tergantung pada konteks perangkat lunak yang ada. Ada empat tipe perubahan yang terjadi selama masa fase pengembangan, yaitu:

a. Koreksi

b. Adaptasi

c. Perkembangan

d. Pencegahan

Fase dan langkah – langkah yang berhubungan, seperti yang digambarkan pada pandangan umum kita tentang rekayasa perangkat lunak, harus diimbangi dengan sejumlah aktivitas pelindung (umbrella activities). Kegiatan – kegiatan khusus didalam kategori ini menyangkut :

a. Kontrol dan pelacakan proyek perangkat lunak

b. Review teknis formal

c. Jaminan kualitas perangkat lunak

d. Manajemen konfigurasi perangkat lunak

e. Penghasilan dan penyiapan dokumen

f. Manajemen reusabilitas

g. Pengukuran

h. Manajemen resiko

Proses Perangkat Lunak

Sebuah kerangka kerja proses umum dibangun dengan mendefinisikan sejumlah kecil aktivitas kerangka kerja yang bisa diaplikasikan ke semua proyek perangkat lunak, tanpa melihat ukuran atau kompleksitasnya. Sejumlah task set- tiap koleksi rekayasa perangkat lunak yang mengerjakan tugas – tugas, tonggak proyek, hasil usaha perangkat lunak dan bisa dipesan, serta titik jaminan kualitas- memungkinkan aktivitas kerangka kerja disesuaikan dengan karakteristik proyek perangkat lunak dan kebutuhan tim proyek. Akhirnya, aktivitas pelindung- seperti jaminan kualitas perangkat lunak, manajemen konfigurasi perangkat lunak- lampiran model proses. Aktivitas pelindung tidak tergantung pada satupun aktivitas kerangka kerja dan terjadi pada seluruh proses.

trio1

[gambar 1] Proses Perangkat Lunak

Rekayasa perangkat lunak Institute (SEI) telah mengembangkan model komprehensif yang didasarkan atas sekumpulan kapabilitas rekayasa perangkat lunak yang harus ada sebagai organisasi yang mencapai tingkat kematangan proses yang berbeda. Untuk menentukan keadaan suatu organisasi dalam hal kematangan prosesnya, SEI menggunakan perkiraan kuesioner serta skema gradasi lima poin. Skema gradasi tersebut menentukan pemenuhan dengan sebuah model kematangan kapabilitas yang mendefiniskan aktivitas kunci yang dibutuhkan pada tingkat kematangan proses yang berbeda. Pendekatan SEI memberikan sebuah pengukuran terhadap efektivitas global dari sebuah praktek perekayasaan perangkat lunak perusaahaan dan membangun lima tingkat kematangan proses, yang didefinisikan dengan cara berikut :

a. Level 1

Initial – Proses perangkat lunak yang ditandai sebagai ad hoc, dan bahkan kadang – kadang bersifat kacau.

b. Level 2

Repeatable – Proses – proses manajemen proyek dasar dibangun untuk menulusuri masalah biaya, jadwal, dan fungsionalitas. Disiplin proses yang perlu ada untuk mengulangi sukses – sukses proyek yang terdahulu dengan penerapan yang sama.

c. Level 3

Defined – Proses perangkat lunak, baik untuk aktivitas manajemen atau perekayasaan didokumentasikan, distandarkan, dan diintregasikan ke dalam proses perangkat lunak organisasi besar. Semua proyek menggunakan versi proses organisasi yang didokumentasikan dan disahkan untuk pengembangan dan pemeliharaan perangkat lunak. Tingkat ini menyangkut semua ciri yang didefinisikan pada tingkat 3.

d. Level 4

Managed – Pengukuran detail terhadap proses perangkat lunak dan kualitas produksi dikumpulkan. Produk dan proses perangkat lunak dipahami secara kuantitatif dan dikontrol dengan menggunakan pengukuran secara detail. Tingkat ini termasuk semua karakteristik yang didefinisikan pada tingkat 3.

e. Level 5

Optimizing – Pertambahan proses yang terus – menerus dimungkinkan oleh umpan balik kuantitatif dari prose dan dari gagasan inovatif pengujian serta teknologi. Tingkat ini termasuk semua ciri yang didefinisikan pada tingkat 4.

Lima tingkat yang didefinisikan oleh SEI ini disimpulkan dari sebuah konsekuensi respon evaluasi ke assessment questionnaire yang didasarkan pada CMM. Hasil dari kuesioner tersebut didestilasi menjadi sebuah tingkatan numeric tunggal yang memberikan identifikasi terhadap kematangan proses organisasi.

SEI telah menggabungkan area proses kunci dengan masing – masing tingkat kematangan. KPA menggambarkan fungsi – fungsi rekayasa perangkat lunak yang harus ada untuk memenuhi praktek yang baik pada suatu tingkat tertentu. Setiap KPA digambarkan dengan mengidentifikasikan ciri – ciri sebagai berikut :

a. Tujuan – objektif keseluruhan yang harus dicapai oleh KPA.

b. Komitmen – kebutuhan yang harus dipenuhi untuk mencapai tujuan, dan yang membuktikan dari maksud mencapai tujuan.

c. Kemampuan – hal – hal tersebut harus ada yang akan memungkinkan organisasi untuk memenuhi komitmennya.

d. Aktivitas – tugas – tugas khusus yang dibutuhkan untuk mencapai fungsi – fungsi dari KPA.

e. Metode untuk memonitor informasi – sikap dimana kegiatan dimonitor pada saat dipakai.

f. Metode – metode untuk memverifikasi informasi – sikap dimana praktek yang sesuai untuk KPA diverifikasi.

Model – Model Proses Perangkat Lunak

Untuk menyelesaikan masalah didalam suatu industri, rekayasa perangkat lunak atau tim perekayasa harus menggabungkan strategi pengembangan yang melingkupi lapisan proses, metode, dan alat – alat bantu serta fase – fase generik yang telah dijelaskan sebelumnya. Strategi ini sering diacukan sebagai model proses atau paradigma rekayasa perangkat lunak. Model proses untuk rekayasa perangkat lunak dipilih berdasarkan sifat aplikasi dan proyeknya, metode dan alat – alat bantu yang akan dipakai, dan kontrol serta penyampaian yang dibutuhkan.

Racoon (RAC95) mengusulkan sebuah model “chaos” yang menggambarkan “perkembangan perangkat lunak sebagai sebuah kesatuan dari pemakai ke pengembang dan ke teknologi”. Pada saat kerja bergerak maju menuju sebuah system yang lengkap, keadaan yang digambarkan di atas secara rekursif diaplikasikan kepada kebutuhan pemakai dan spesifikasi teknis perangkat lunak pengembang.

Model Sekuensial Linear (Water Fall)

Model sekuensial linier untuk software engineering, sering disebut juga dengan siklus kehidupan klasik atau model air terjun. Model ini mengusulkan sebuah pendekatan kepada perkembangan software yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dimodelkan setelah siklus rekysa konvensional, model sekuensial linier melingkupi aktivitas – aktivitas sebagai berikut :

1. Rekayasa dan permodelan sistem

Karena sistem merupakan bagian dari sebuah sistem yang lebih besar, kerja dimulai dengan membangun syarat dari semua elemen sistem dan mengalokasikan beberapa subset dari kebutuhan ke software tersebut. Pandangan sistem ini penting ketika software harus berhubungan dengan elemen-elemen yang lain seperti software, manusia, dan database. Rekayasa dan anasisis system menyangkut pengumpulan kebutuhan pada tingkat sistem dengan sejumlah kecil analisis serta disain tingkat puncak. Rekayasa informasi mancakup juga pengumpulan kebutuhan pada tingkat bisnis strategis dan tingkat area bisnis.

2. Analisis kebutuhan software

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khusunya pada software. Untuk memahami sifat program yang dibangun, analis harus memahami domain informasi, tingkah laku, unjuk kerja, dan interface yang diperlukan. Kebutuhan baik untuk sistem maupun software didokumentasikan dan dilihat lagi dengan pelanggan.

3. Desain

Desain software sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda, struktur data, arsitektur software, representasi interface, dan detail (algoritma) prosedural. Proses desain menterjemahkan syarat/kebutuhan ke dalam sebuah representasi software yang dapat diperkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi software.

4. Generasi kode

Desain harus diterjemahkan kedalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.

5. Pengujian

Sekali program dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal software, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional, yaitu mengarahkan pengujian untuk menemukan kesalahan – kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.

6. Pemeliharaan

Software akan mengalami perubahan setelah disampaikan kepada pelanggan (perkecualian yang mungkin adalah software yang dilekatkan). Perubahan akan terjadi karena kesalahan – kesalahan ditentukan, karena software harus disesuaikan untuk mengakomodasi perubahan – perubahan di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai akibat dari perangkat peripheral atau sistem operasi yang baru), atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja. Pemeliharaan software mengaplikasikan lagi setiap fase program sebelumnya dan tidak membuat yang baru lagi.

trio2
[gambar 2]

Masalah yang kadang terjadi ketika model sekuensial linier diaplikasikan adalah:

1. Jarang sekali proyek nyata mengikuti aliran sekuensial yang dianjurkan oleh model. Meskipun model linier bisa mengakomodasi iterasi, model ini melakukannya dengan cara tidak langsung. Sebagai hasilnya, perubahan – perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan.

2. Kadang – kadang sulit bagi pelanggan untuk menyatakan semua kebutuhannya secara eksplisit. Model linier sekuensial memerlukan hal ini dan mengalami kesulitan untuk mengakomodasi ketidakpastian natural yang ada pada bagian awal beberapa proyek.

3. Pelanggan harus bersifat sabar. Sebuah versi kerja dari program – program kerja itu tidak akan diperoleh sampai akhir waktu proyek dilalui. Sebuah kesalahan besar, jika tidak terdeteksi sampai program yang bekerja tersebut dikaji ulang, bisa menjadi petaka.

4. Pengembang sering melakukan penundan yang tidak perlu. Sifat alami dari siklus kehidupan klasik membawa kepada blocking state di mana banyak anggota tim proyek harus menunggu tim yang lain untuk melengkapi tugas yang saling memiliki ketergantungan. Blocking state cenderung menjadi lebih lazim pada awal dan akhir sebuah proses sekuensial linier.

Model Prototipe

Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek – aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Perancangan kilat membawa kepada konstruksi sebuah prototipe. Prototipe tersebut dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan software. Iterasi terjadi pada saat prototipe disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukannya.

trio3
[gambar 3]

Secara ideal prototipe berfungsi sebagai sebuah mekanisme untuk mengidentifikasi kebutuhan software. Bila prototipe yang sedang bekerja dibangun, pengembang harus mempergunakan fragmen – fragmen program yang ada atau mengaplikasikan alat –alat bantu (contohnya report generator, window manager, dll) yang memungkinkan program yang bekerja untuk dimunculkan secara cepat.

Prototipe bisa juga menjadi masalah karena alasan sebagai berikut:

1. Pelanggan melihat apa yang tampak sebagai versi software yang bekerja tanpa melihat bahwa prototipe itu dijalin bersama – sama “dengan permen karet dan baling wire”, tanpa melihat bahwa di dalam untuk membuatnya bekerja, kita belum menyantumkan kualitas software secara keseluruhan atau kemampuan pemeliharaan untuk jangka waktu yang panjang. Ketika diberi informasi bahwa produk harus dibangun lagi agar tingkat kualitas yang tinggi bisa dijaga, pelanggan akan meneriakan kecurangan dan permintaan agar dipakai “beberapa campuran” untuk membuat prototipe menjadi sebuah produk yang bekerja yang lebih sering terjadi, sehingga manajemen pengembangan software menjadi penuh dengan belas kasihan.

2. Pengembang sering membuat kompromi – kompromi implementasi untuk membuat prototipe bekerja dengan cepat. Sistem operasi atau bahasa pemrograman yang tidak sesuai bisa dipakai secara sederhana karena mungkin diperoleh dan dikenal; algoritma yang tidak efisien secara sederhana bisa diimplementasikan untuk mendemonstrasikan kemampuan. Setelah selang waktu tertentu, pengembang mungkin mengenali pilihan – pilihan tersebut dan melupakan semua alasan mengapa mereka tidak cocok. Pilihan yang kurang ideal telah menjadi bagian integral dari sebuah sistem.

Meskipun berbagai masalah bisa terjadi, prototipe bisa menjadi paradigma yang efektif bagi Software Engineering. Kuncinya adalah mendefinisikan aturan main pada saat awal; yaitu pelanggan dan pengembang keduanya harus setuju bahwa prototipe dibangun untuk berfungsi sebagai mekanisme pendefinisian kebutuhan. Prototipe kemudian disingkirkan (paling tidak sebagian), dan software aktual direkayasa dengan tertuju kepada kualitas dan kemampuan pemeliharaan.

Model Rapid Aplication Development

Rapid Aplication Development (RAD) adalah sebuah model proses perkembangan software sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Model RAD ini merupakan sebuah adaptasi “kecepatan tinggi” dari model sekuensial linier di mana perkembangan cepat dicapai dengan menggunakan pendekatan kontruksi berbasis komponen. Jika kebutuhan dipahami dengan baik, proses RAD memungkinkan tim pengembangan menciptakan “sistem fungsional yang utuh” dalam periode waktu yang sangat pendek (kira-kira 60 sampai 90 hari). Karena dipakai terutama pada aplikasi sistem konstruksi, pendekatan RAD melingkupi fase – fase sebagai berikut :

1. Business modeling

Aliran informasi di antara fungsi – fungsi bisnis dimodelkan dengan suatu cara untuk menjawab pertanyaan – pertanyaan berikut : informasi apa yang mengendalikan proses bisnis? Informasi apa yang di munculkan? Siapa yang memunculkanya? Ke mana informasi itu pergi? Siapa yang memprosesnya?

2. Data modeling

Aliran informasi yang didefinisikan sebagai bagian dari fase business modelling disaring ke dalam serangkaian objek data yang dibutuhkan untuk menopang bisnis tersebut. Karakteristik (disebut atribut) masing – masing objek diidentifikasi dan hubungan antara objek – objek tersebut didefinisikan.

3. Proses modeling

Aliran informasi yang didefinisikan di dalam fase data modeling ditransformasikan untuk mencapai aliran informasi yang perlu bagi implementasi sebuah fungsi bisnis. Gambaran pemrosesan diciptakan untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data.

4. Application Generation

RAD mengasumsikan pemakaian teknik generasi ke empat. Selain menciptakan perangkat lunak dengan menggunakan bahasa pemrograman generasi ketiga yang konvensional, RAD lebih banyak memproses kerja untuk memkai lagi komponen program yang ada ( pada saat memungkinkan) atau menciptakan komponen yang bisa dipakai lagi (bila perlu). Pada semua kasus, alat – alat bantu otomatis dipakai untuk memfasilitasi konstruksi perangkat lunak.

5. Testing and turnover

Karena proses RAD menekankan pada pemakaian kembali, banyak komponen program telah diuji. Hal ini mengurangi keseluruhan waktu pengujian. Tetapi komponen baru harus di uji dan semua interface harus dilatih secara penuh.

trio4
[gambar 4]

Kekurangan model RAD adalah:

1. Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusia yang memadai untuk menciptakan jumlah tim RAD yang baik.

2. RAD menuntut pengembangan dan pelanggan memiliki komitmen di dalam aktivitas rapid-fire yang diperlukan untuk melengkapi sebuah sistem, di dalam kerangka waktu yang sangat diperpendek. Jika komitmen tersebut tidak ada, proyek RAD akan gagal.

Model Spiral

Model spiral (spiral model) adalah model proses software yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model ini berpotensi untuk pengembangan versi pertambahan software secara cepat. Di dalam model spiral, software dikembangkan di dalam suatu deretan pertambahan. Selama awal iterasi, rilis inkremental bisa merupakan sebuah model atau prototipe kertas. Selama iterasi berikutnya, sedikit demi sedikit dihasilkan versi sistem rekayasa yang lebih lengkap.

Model spiral dibagi menjadi sejumlah aktifitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas, yaitu :

1. Komunikasi Pelanggan

Tugas – tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembangan dan pelanggan.

2. Perencanaan

Tugas – tugas yang dibutuhkan untuk mendefinisikan sumber – sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.

3. Analisis Risiko

Tugas – tugas yang dibutuhkan untuk menaksir risiko – risiko, baik manajemen maupun teknis.

4. Perekayasaan

Tugas – tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut.

5. Konstruksi dan peluncuran

Tugas – trugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (instal) dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).

6. Evaluasi pelanggan

Tugas – tugas yang dibutuhkan untuk memperoleh umpan balik dari pelnggan dengan didasarkan pada evaluasi representasi software, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.

trio5
[gambar 5]

Kekurangan model spiral adalah sulitnya untuk meyakinkan konsumen (khusunya dalam situasi kontrak) bahwa pendekatan evolusioner bisa dikontrol. Model spiral memerlukan keahlian penaksiran risiko yang msuk akal , dan sangat bertumpu pada keakhlian ini untuk mencapai keberhasilan. Jika resiko mayor tidak ditemukan dan diatur, pasti akan terjadi masalah. Akhirnya model itu sendiri masih baru dan belum dipergunakan secara luas seperti paradigma sekuensial dan prototipe.

Model Formal

Model metode formal mencakup sekumpulan aktivitas yang membawa kepada spesifikasi matematis perangkat lunak komputer. Metode formal memungkinkan perekayasa perangkat lunak untuk mengkhususkan, mengembangkan, dan memverifikasi system berbasis computer dengan menggunakan notasi matematis yang tepat. Variasi didalam pendekatan ini, disebut juga clean-room rekayasa perangkat lunak, sedang diaplikasikan oleh banyak organisasi pengembang perangkat lunak.

Bila metode formal dipakai selama masa pengembangan, metode itu memberika mekanisme untuk mengeliminasi banyak masalah yang sulit dipecahkan dengan menggunakan paradigma perangkat lunak yang lain. Ambiguitas, ketidaklengkapan, dan ketidak-konsistenan bisa ditemukan dan diperbaiki secara lebih mudah, tidak melalui kajian ad hoc tetapi melalui aplikasi analisis matematis. Jika metode formal dipakai selama masa perancangan, mereka berfungsi sebagai dasar verifikasi program sehingga memungkinkan perekayasa perangkat lunak untuk menemukan dan memperbaiki kesalahan yang mungkin saja tidak terdeteksi.

Meskipun belum menjadi pendekatan utama, model metode formal sudah menawarkan janji perangkat lunak yang bebas cacat/kesalahan, tetapi perhatian tentang kemampuan aplikasinya didalam lingkungan bisnis sudah mulai disuarakan:

1. Pengembangan model formal banyak memakan waktu dan mahal.

2. Karena beberapa pengembang perangkat lunak perlu mempunyai latar belakang yang diperlukan untuk mengaplikasikan metode formal, maka diperlukan pelatihan yang ekstensif.

3. Sulit untuk menggunakan model – model sebagai sebuah mekanisme komunikasi bagi pemakai yang secara teknik belum canggih.

Meskipun demikian, sepertinya metode formal ini akan memperoleh banyak penganut diantara pengembang perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan (misalnya pengembang perangkat medis dan penerbangan pesawat), serta diantara pengembang yang harus menderita karena factor ekonomis yang harus dialami oeh perangkat lunak.

Produk dan Proses

Bila proses lemah maka tidak diragukan lagi hasilnya juga akan buruk. Tetapi ketergantungan yang obsessive pada proses juga berbahaya. Secara singkat Margaret David mengomentari dualitas hasil dan proses sebagai berikut :

Sekitar setiap sepuluh tahun lebih atau kurang dari lima, komunitas perangkat lunak kembali mendefinisikan “masalah” dengan menggeser fokusnya dari isu produk ke isu proses. Demikianlah, kita telah mempergunakan bahasa program terstruktur (produk) diikuti dengan metode analisis terstruktur (proses) diikuti dengan enkapsulasi data (produk) diikuti dengan penekanan pada rekayasa perangkat lunak Institute’s Software Development Capability Maturity Model (proses).

Sementara tendensi natural dari pendulum adalah kembali lagi ke titik tengah diantara dua titik ujung, focus komunitas perangkat lunak bergeser secara konstan karena gaya baru diaplikasikan ketika ayunan yang terdahulu gagal. Ayunan – ayunan tersebut menjadi pengganggu di antara mereka sendiri karena mereka meragukan pelaksana perangkat lunak rata – rata dengan mengubah secara radikal apa artinya melakukan pekerjaan. Belum lagi untuk melakukannya dengan baik. Ayunan itu juga akan memecahkan “masalah”, karena gagal selama produk dan proses diperlakukan seperti membentuk sebuah dikotomi dan bukan dualitas.

Semua kegiatan manusia bisa menjadi proses, tetapi masing – masing dari kita menarik diri dari kegiatan – kegiatan yang menghasilkan representasi atau contoh yang dapat dipergunakan atau dihargai oleh satu orang atau lebih tersebut, yaitu bahwa kita tidak merasa puas terhadap penggunaan kembali produk kita oleh kita sendiri atau orang lain.

Kerja masyarakat perangkat lunak akan berubah didalam tahun ini dan yang akan dating. Dualitas produk dan proses merupakan elemen penting didalam menjaga manusia – manusia kreatif agar terjalin sementara rekayasa pemrograman dan perangkat lunak diselesaikan.

0 Responses to “Proses, oleh Adi S [5105 100 011], Trendyka Z [5105 100 075], M Ali Mas’ud [5105 100 030]”



  1. Tinggalkan sebuah Komentar

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




Arsip

RSS My Blog

  • Pindahan! Februari 13, 2012
    Para pembaca sekalian, mulai hari ini blog ini pindah ya.. alamatnya di www.handyeka.com Posting-posting terbaru akan muncul di alamat baru tersebut. Terima kasih :)
  • Selamat Tahun Baru 2012! Januari 26, 2012
    Selamat tahun baru 2012!! Bagaimana tahun 2011 yang baru saja kita lewati ini? pasti banyak up-and-down nya. Biasanya orang kalau ngomongin tahun baru mesti nanyain resolusi tahun baru, tapi kali ini saya ga mau nanya-nanya tentang resolusi, hahaha.. kenapa? karena … Continue reading →
  • Adele – Someone Like You Oktober 10, 2011
    Pernahkah Anda merasakan jatuh cinta.. namun pada akhirnya Anda hanya bisa mengagumi dia yang Anda cinta karena Anda berdua sayangnya tidak bisa bersatu.. namun ia akhirnya bisa bahagia.. meskipun bukan bersama Anda.. Sakit.. dan penuh emosi jiwa pastinya.. tapi apakah … Continue reading →

RSS Recipee World

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Indonesia Travel Guide

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Music Info Online

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

%d blogger menyukai ini: