Bentuk umum model proses software terdiri dari serangkaian kegiatan yang membentuk suatu kerangka untuk praktek rekayasa perangkat lunak. Umumnya kerangka kegiatan terdiri dari komunikasi, perencanaan, pemodelan, konstruksi, dan penyebaran-dan umbrella activities untuk membangun sebuah arsitektur kerangka kerja rekayasa perangkat lunak. Tapi bagaimana menggunakannya pada praktek rekayasa perangkat lunak? Dalam bagian berikut, akan mempertimbangkan konsep-konsep umum dan prinsip-prinsip yang berlaku untuk kerangka aktivitas.
1. Esensi dari Praktek
Esensi dari Praktek Rekayasa Perangkat Lunak diantaranya:
- Memahami Permasalahan (Komunikasi dan Analisis)
- Merencanakan Solusi (Pemodelan dan Desain Perangkat Lunak)
- Melaksanakan Rencana (Pembuatan Kode)
- Memeriksa Akurasi Hasil (Menguji dan Quality Assurance)
Dalam konteks rekayasa perangkat lunak, langkah-langkah awal membawa serangkaian pertanyaan penting [diadaptasi dari POL45]
Memahami masalah
- Siapa yang memiliki wewenang untuk menyelesaikan masalah ini? Apakah itu adalah yang berkepentingan terhadap masalah ini?
- Apa yang tidak diketahui? Apakah data, fungsi, fitur, dan perilaku yang diperlukan untuk menyelesaikan masalah?
- Apakah masalah dapat di pecah? Apakah mungkin untuk mewakili masalah yang lebih kecil yang mungkin lebih mudah untuk di mengerti?
- Dapatkah masalah di wakili dengan grafik? Dapatkah model analisis dibuat?
Merencanakan Solusi
- Pernahkah Anda melihat masalah yang serupa? Apakah pola tersebut teridentifikasi sebagai solusi yang berpotensi? Apakah ada aplikasi yang mengimplementasi data, fungsi, fitur dan perilaku yang memenuhi?
- Apakah masalah yang serupa tersebut sudah terselesaikan? Jika ya, apakah elemen dari solusi tersebut dapat digunakan kembali?
- Apakah sub-masalah dapat di definisikan? Jika ya, apakah solusi tersebut sudah sangat siap untuk sub-masalah?
- Dapatkah Anda mewakili sebuah solusi dengan cara yang mengarah ke pelaksanaan yang efektif? Apakah design model dapat di buat?
Melaksanakan Rencana
- Apakah solusi tersebut sesuai dengan rencana? Apakah source code dapat ditelusuri ke design model?
- Apakah setiap komponen dari solusi itu mungkin untuk diperbaiki? Apakah design dan kode tersebut telah di tinjau ulang, atau belum, apakah hasil perbaikan sudah dibuktikan terhadap algoritma?
Memeriksa Hasil
- Apakah mungkin untuk menguji setiap komponen dari solusi? Apakah sudah diterima hasil dari strategi pengujian yang sudah di implementasi?
- Apakah solusi tersebut membuahkan hasil yang dapat diterima oleh data, fitur, dan perilaku yang sesuai? Apakah software telah di validasi dengan requirement dari stakeholder?
2. Prinsip Dasar
Kamus mendefinisikan kata prinsip sebagai “hukum penting yang mendasari atau asumsi yang dibutuhkan dalam suatu sistem pemikiran.” Beberapa fokus pada rekayasa perangkat lunak secara keseluruhan, yang lain menganggap aktivitas kerangka kerja spesifik generik (misalnya, komunikasi pelanggan), dan yang lain lagi fokus pada tindakan rekayasa perangkat lunak (misalnya, desain arsitektur) atau tugas-tugas teknis (misalnya, menulis skenario penggunaan). Terlepas dari tingkat fokusnya, prinsip membantu kita membangun suatu pola pikir untuk praktek rekayasa perangkat lunak yang solid. Itu semua penting untuk alasan tersebut.
David Hooker [HOO96] telah mengusulkan tujuh prinsip-prinsip dasar yang berfokus pada praktek rekayasa perangkat lunak secara keseluruhan. Seperti yang terdapat di bawah ini :
Prinsip Pertama: Alasan Semua Ini Ada
Sebuah sistem perangkat lunak ada untuk satu alasan: untuk memberikan nilai bagi para penggunanya. Semua keputusan harus dibuat dengan pikiran ini. Sebelum menetapkan kebutuhan sistem, sebelum mencatat sepotong fungsionalitas sistem, sebelum menentukan platform perangkat keras atau proses pembangunan, tanyakan pada diri Anda pertanyaan seperti: Apakah ini merupakan nilai tambah ke sistem? Jika jawabannya tidak, jangan lakukan itu. Semua prinsip lain mendukung prinsip yang satu ini.
Prinsip Kedua: KISS (Keep It Simple, Stupid!)
Software desain bukanlah proses yang sembarangan. Ada banyak faktor untuk dipertimbangkan dalam setiap usaha desain. Semua desain harus sesederhana mungkin, tetapi tidak sederhana. Fasilitas ini lebih mudah dipahami, dan memiliki perawatan sistem yang mudah. Ini bukan berarti untuk mengatakan bahwa fitur, bahkan fitur internal, harus dibuang agar lebih sederhana. Memang, desain yang lebih elegan biasanya yang lebih sederhana. Sederhana juga tidak berarti “cepat dan kotor”. Pada kenyataannya, sering membutuhkan banyak pemikiran dan kerja selama beberapa iterasi untuk menyederhanakan. Hal ini berimbas pada perangkat lunak yang lebih dipelihara dan kurang rentan terhadap kesalahan.
Prinsip Ketiga: Menjaga Visi
Sebuah visi yang jelas sangat penting untuk keberhasilan suatu proyek perangkat lunak.Tanpa visi, proyek hampir tak ada batasan nya dan akhirnya menjadi “dua [atau lebih] pemikiran” tentang dirinya sendiri. Tanpa integritas konseptual, sistem bisa menjadi desain yang tidak kompatibel.
Mengkompromikan visi arsitektur dari sebuah sistem perangkat lunak yang melemah dan akhirnya akan gagal bahkan sistem yang dirancang dengan baik sekalipun. Memiliki arsitek yang diberdayakan yang dapat memegang visi dan menegakkan kepatuhan membantu memastikan proyek perangkat yang sangat sukses.
Prinsip Keempat: Apa yang Anda Buat, Orang lain akan Menggunakannya
Jarang sekali kekuatan-industri sistem perangkat lunak dibangun dan digunakan dalam ruang hampa. Dalam beberapa cara atau yang lainnya, orang lain akan menggunakan, memelihara, membuat dokumen, atau tergantung pada kemampuan untuk memahami system anda. Jadi, selalu tentukan, desain, dan implementasikan agar orang lain memahami apa yang Anda lakukan. Pengguna untuk setiap produk pengembangan perangkat lunak memiliki potensi yang besar. Jadi pehatikan apa saja yang mereka butuhkan. Desain, menjaga implementasi dalam pikiran. Perhatikan apa saja yang harus dipelihara dan dapat memperluas sistem. Seseorang mungkin harus men-debug kode yang anda tulis, dan membuat mereka menjadi pengguna kode Anda. Membuat pekerjaan mereka lebih mudah, menambah nilai ke sistem.
Prinsip Kelima: Jadilah Terbuka untuk Masa Depan
Sebuah sistem yang tahan lama memiliki nilai lebih. Dalam lingkungan komputasi sekarang, dimana spesifikasi berubah dalam waktu singkat dan platform perangkat keras menjadi usang hanya dalam beberapa bulan, masa hidup perangkat lunak biasanya diukur dalam bulan bukan tahun. Bagaimanapun juga, benar “kekuatan-industri” sistem perangkat lunak harus bertahan jauh lebih lama. Agar hal ini tercapai, sistem ini harus siap untuk beradaptasi dengan perubahan lainnya. Sistem yang membuat hal ini berhasil adalah sistem yang telah dirancang dari awal. Jangan pernah desain sendiri ke sudut. Selalu bertanya “bagaimana jika,” dan mempersiapkan diri untuk semua jawaban yang mungkin dengan menciptakan sistem yang memecahkan masalah umum, bukan hanya sesuatu yang spesifik. Hal ini bisa sangat mungkin menyebabkan penggunaan kembali dari seluruh sistem.
Prinsip Keenam: Rencanakan untuk Reuse
Penggunaan reuse menghemat waktu dan usaha. Mencapai penggunaan kembali yang tinggi bisa dibilang tujuan paling sulit untuk dicapai dalam mengembangkan sistem perangkat lunak. Penggunaan kembali kode dan desain telah dinyatakan sebagai manfaat utama menggunakan teknologi yang berorientasi pada objek. Meskipun, laba atas investasi ini tidak otomatis. Untuk memanfaatkan kemungkinan penggunaan kembali yang pemrograman berorientasi objek [pemrograman konvensional] diperlukan pemikiran dan perencanaan. Ada banyak teknik untuk merealisasikan setiap tingkat proses pengembangan sistem. Salah satunya adalah dengan mendesain secara rinci dan tingkat kode yang sudah dikenal dan didokumentasikan. Literatur baru membahas kembali desain dalam bentuk pola perangkat lunak. Namun, ini hanya bagian dari persaingan.
Kesempatan berkomunikasi untuk reuse kepada orang lain dalam organisasi adalah yang terpenting. Bagaimana bisa Anda menggunakan kembali sesuatu yang Anda tidak tahu keberadaannya? Perencanaan ke depan untuk reuse mengurangi biaya dan meningkatkan nilai dari kedua komponen yang dapat digunakan kembali dan sistem dimana mereka tergabung.
7 Prinsip ketujuh : Pikirkan!
Prinsip terakhir ini mungkin adalah prinsip yang paling diabaikan. Penempatan yang jelas, berfikir matang sebelum melakukan tindakan, hampir selalu membuahkan hasil yang lebih baik. Ketika Anda berfikir tentang sesuatu, Anda mungkin akan melakukannya dengan benar. Anda juga mendapat pengetahuan baru tentang bagaimana cara untuk melakukannya dengan benar. Jika anda berfikir tentang sesuatu dan masih salah melakukannya, hal tersebut menjadi pengalaman yang berharga. Efek samping dari berfikir adalah pembelajaran untuk mengetahui ketika Anda tidak mengetahui sesuatu, dan titik dimana anda mencari jawabannya. Ketika pemikiran jernih telah masuk ke dalam sistem, nilai akan keluar. Penerapan enam prinsip pertama membutuhkan intensitas, meskipun membutuhkan potensial yang lebih banyak.
Jika setiap software engineer dan setiap software tim hanya mengikuti ketujuh prinsip Hooker, banyak kesulitan yang kita alami dalam membangun sistem berbasis komputer kompleks yang akan dieliminasi.
