Praktik Rekayasa Perangkat Lunak Menurut Roger S. Pressman

  Pada bagian sebelumnya, penulis memperkenalkan model proses umum untuk pengembangan perangkat lunak, yang terdiri dari serangkaian aktivitas. Kerangka kerja ini terdiri dari beberapa kegiatan seperti communication, planning, modeling, construction, and deployment, serta kegiatan payung yang membentuk arsitektur dasar untuk praktik rekayasa perangkat lunak. Namun, bagaimana kerangka kerja tersebut dapat diterapkan dalam praktik sehari-hari? Pada bagian berikutnya, Anda akan mempelajari konsep dan prinsip umum yang berlaku untuk aktivitas kerangka kerja tersebut.

1.1 The Essence of Practice

Dalam sebuah karya klasik, How to Solve It, George Polya menjelaskan esensi dari pemecahan masalah dan praktik rekayasa perangkat lunak. Buku ini ditulis sebelum adanya komputer modern. Berikut adalah esensi dari pemecahan masalah dan praktik rekayasa perangkat lunak:

1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality assurance).

Dalam konteks rekayasa perangkat lunak, mengikuti langkah-langkah akal sehat ini dapat membantu menghasilkan serangkaian pertanyaan penting [berdasarkan adaptasi dari Pol45]:

Understand the problem. Kebanyakan dari kita cenderung merasa terlalu percaya diri saat menghadapi masalah, meskipun sulit untuk diakui. Setelah mendengarkan penjelasan singkat, kita sering berpikir bahwa kita mengerti dan dapat segera mulai memecahkan masalah. Namun, pemahaman tidak selalu semudah itu. Oleh karena itu, disarankan untuk meluangkan waktu dan menjawab beberapa pertanyaan sederhana terlebih dahulu:

• Pertanyaan penting dalam pemecahan masalah adalah siapa yang memiliki peran dan kepentingan dalam masalah tersebut?
• Hal-hal apa yang belum diketahui dan dibutuhkan untuk menyelesaikan masalah dengan benar, seperti data, fungsi, dan fitur yang dibutuhkan?
• Dalam pemecahan masalah, apakah memungkinkan untuk memecah masalah menjadi bagian-bagian yang lebih kecil yang lebih mudah dipahami?
• Salah satu pertimbangan penting dalam pemecahan masalah adalah apakah masalah dapat diwakili secara visual atau dengan model analisis yang dapat dibuat?

Plan the solution. Meskipun Anda merasa sudah memahami masalah, sebaiknya hindari terburu-buru untuk melakukan pengkodean. Sebelumnya, lakukanlah sedikit desain untuk memastikan solusi yang dihasilkan dapat efektif dan efisien:

• Apakah Anda pernah menemui masalah yang serupa sebelumnya? Apakah ada pola yang dapat dikenali dalam potensi solusi? Apakah ada perangkat lunak yang dapat menerapkan data, fungsi, dan fitur yang dibutuhkan?
• Apakah masalah serupa pernah diatasi sebelumnya? Jika iya, apakah elemen solusinya dapat digunakan kembali?
• Dapatkah submasalah dijelaskan secara terpisah? Jika memungkinkan, apakah solusi untuk submasalah tersebut terlihat dengan mudah?
• Bisakah Anda mewakili solusi dengan cara yang mengarah pada implementasi yang efektif? Bisakah model desain dibuat?

Carry out the plan. Anda dapat memandang desain yang dibuat sebagai panduan untuk membangun sistem yang diinginkan. Meskipun ada kemungkinan ada jalan tikus atau jalan yang lebih baik yang akan ditemukan selama proses pengembangan, desain akan menjadi panduan yang memudahkan Anda untuk terus melangkah tanpa mengalami kesulitan.

• Dapatkah solusi yang dihasilkan sejalan dengan rencana yang telah dibuat sebelumnya? Apakah kode program dapat ditelusuri dan dipetakan kembali ke dalam model desain yang telah dirancang?
• Dapatkah setiap elemen dari solusi dibuktikan kebenarannya? Sudahkah desain dan kode direview atau bahkan, apakah sudah ada bukti matematis untuk algoritma yang digunakan?

Examine the result. Anda mungkin tidak bisa memastikan kebenaran solusi secara sempurna, namun Anda dapat memastikan bahwa sudah melakukan perancangan pengujian yang cukup untuk mengungkap kesalahan semaksimal mungkin.

• Dapatkah setiap komponen solusi diuji? Sudahkah diterapkan strategi pengujian yang masuk akal?
• Dapatkah solusi menghasilkan output yang sesuai dengan persyaratan data, fungsi, dan fitur yang diperlukan? Apakah perangkat lunak telah melewati validasi terhadap semua kebutuhan yang dimiliki oleh pihak yang berkepentingan?

Tidak mengherankan jika banyak dari pendekatan ini terlihat masuk akal. Sebenarnya, masuk akal untuk mengatakan bahwa pendekatan yang rasional dalam rekayasa perangkat lunak tidak akan pernah mengecewakan Anda.

1.2  General Principles

Definisi kata "prinsip" dalam kamus adalah "hukum atau asumsi mendasar yang penting yang dibutuhkan dalam suatu sistem pemikiran." Dalam pembahasan kali ini, akan dibahas prinsip-prinsip pada berbagai tingkat abstraksi. Beberapa fokus pada rekayasa perangkat lunak secara keseluruhan, sementara yang lain mempertimbangkan aktivitas kerangka kerja generik tertentu seperti komunikasi. Ada juga yang fokus pada tindakan rekayasa perangkat lunak seperti desain arsitektur atau tugas teknis seperti menulis skenario penggunaan. Meskipun fokusnya berbeda-beda, prinsip-prinsip ini membantu dalam membangun pola pikir untuk praktik rekayasa perangkat lunak yang solid. Penting untuk memperhatikan prinsip-prinsip ini karena alasan tersebut.

Tujuh prinsip yang difokuskan pada praktik rekayasa perangkat lunak secara keseluruhan telah diusulkan oleh David Hooker. Prinsip-prinsip tersebut akan dijelaskan pada paragraf berikut:

The First Principle: The Reason It All Exists

Sistem perangkat lunak dibuat dengan tujuan memberikan nilai kepada pengguna. Oleh karena itu, semua keputusan dalam pengembangan harus mempertimbangkan hal ini. Sebelum memutuskan persyaratan sistem, mendefinisikan fungsionalitas, atau memilih platform perangkat keras atau proses pengembangan, Anda harus mempertimbangkan apakah keputusan tersebut akan menambah nilai pada sistem. Jika jawabannya negatif, maka keputusan tersebut harus dihindari. Prinsip-prinsip lain dalam pengembangan perangkat lunak bertujuan untuk mendukung prinsip ini.

The Second Principle: KISS (Keep It Simple, Stupid!)

Desain perangkat lunak harus dipertimbangkan dengan serius dan hati-hati. Ada banyak faktor yang perlu dipikirkan dalam proses desain. Meskipun desain harus sederhana, tetapi tidak boleh terlalu sederhana. Dengan demikian, akan memudahkan pengguna dalam memahami sistem dan memudahkan perawatan. Namun, ini tidak berarti bahwa fitur-fitur, termasuk fitur-fitur internal, harus dihapus demi kesederhanaan. Kebalikan dari itu, desain yang lebih elegan biasanya lebih sederhana. Meskipun prosesnya membutuhkan banyak pemikiran dan upaya untuk mencapai hasil yang disederhanakan. Hasilnya adalah perangkat lunak yang lebih mudah dipelihara dan mengurangi kesalahan.

The Third Principle: Maintain the Vision

Berhasilnya sebuah proyek perangkat lunak sangat bergantung pada adanya visi yang jelas. Tanpa visi yang jelas, proyek tersebut cenderung berakhir dengan konsep yang tidak terstruktur. Tanpa adanya integritas konseptual, sebuah sistem perangkat lunak dapat menjadi kacau dengan berbagai desain yang tidak cocok yang disatukan dengan komponen yang salah. Oleh karena itu, mengorbankan visi arsitektur sebuah sistem perangkat lunak akan melemahkan dan bahkan merusak sistem tersebut, meskipun dirancang dengan baik. Keberhasilan proyek perangkat lunak tergantung pada keberadaan seorang arsitek yang memiliki visi dan dapat menegakkan standar untuk memastikan kesuksesan proyek tersebut.

The Fourth Principle: What You Produce, Others Will Consume

Dalam pembuatan sistem perangkat lunak, sangat jarang dibangun dan digunakan tanpa interaksi dengan orang lain. Karena itu, penting untuk selalu mempertimbangkan fakta bahwa orang lain akan menggunakan, memelihara, dan bergantung pada sistem Anda. Sebelum menentukan, merancang, dan mengimplementasikan sebuah sistem, pastikan untuk mempertimbangkan pemahaman orang lain terhadap sistem tersebut. Penonton untuk produk pengembangan perangkat lunak harus dipertimbangkan dengan memperhatikan pengguna dan para pelaksana. Saat merancang, pertimbangkan orang yang akan memelihara dan memperluas sistem tersebut. Ada kemungkinan orang lain harus men-debug kode yang telah dibuat, sehingga menjadikan mereka sebagai pengguna kode yang telah dibuat. Dengan membuat pekerjaan mereka lebih mudah, akan menambah nilai pada sistem tersebut.

The Fifth Principle: Be Open to the Future

Dalam dunia teknologi informasi yang terus berubah, memiliki sistem perangkat lunak yang dapat bertahan lama memberikan nilai tambah. Namun, dalam realitasnya, kebanyakan sistem perangkat lunak hanya bertahan beberapa bulan karena spesifikasi dan platform perangkat keras yang cepat berubah. Namun, sistem perangkat lunak yang sukses dan dapat bertahan lama harus dirancang dengan cara yang memungkinkannya untuk beradaptasi dengan perubahan dan kemungkinan masalah di masa depan. Oleh karena itu, selalu penting untuk mempertimbangkan kemungkinan jawaban "bagaimana jika" dan membangun sistem yang dapat memecahkan masalah umum, bukan hanya masalah spesifik. Dengan begitu, sistem perangkat lunak yang dapat digunakan kembali seluruhnya dapat terwujud.

The Sixth Principle: Plan Ahead for Reuse

Dengan menggunakan kembali (reuse) kode dan desain yang sudah ada, waktu dan tenaga dapat dihemat. Namun, mencapai tingkat penggunaan kembali yang tinggi bisa menjadi tantangan dalam mengembangkan sistem perangkat lunak. Teknologi berorientasi objek memiliki manfaat utama dalam penggunaan kembali kode dan desain. Namun, untuk benar-benar memanfaatkan potensi penggunaan kembali yang disediakan oleh pemrograman berorientasi objek atau konvensional, perencanaan dan pemikiran sebelumnya diperlukan. Ada berbagai teknik untuk mencapai penggunaan kembali di setiap tahap pengembangan sistem. Merencanakan untuk penggunaan kembali di masa depan dapat mengurangi biaya dan meningkatkan nilai komponen yang dapat digunakan kembali dan sistem di mana komponen tersebut digunakan.

The Seventh principle: Think!

Dalam prinsip terakhir ini, seringkali dilupakan bahwa memiliki pemikiran yang jelas dan lengkap sebelum bertindak cenderung menghasilkan hasil yang lebih baik. Ketika kita memikirkan sesuatu, kita lebih mungkin untuk melakukannya dengan benar dan bahkan memperoleh pengetahuan tentang cara melakukannya dengan lebih baik. Bahkan jika kita melakukan kesalahan setelah memikirkan sesuatu, pengalaman tersebut dapat menjadi berharga. Dampak dari berpikir adalah kita belajar mengenali kapan kita tidak tahu suatu hal, dan pada saat itu kita dapat mencari jawaban yang tepat. Ketika pikiran yang jernih digunakan dalam sistem, hasilnya menjadi lebih baik. Menerapkan enam prinsip sebelumnya membutuhkan pemikiran yang intens, tetapi imbalannya sangat besar. Jika setiap insinyur dan tim perangkat lunak mengikuti tujuh prinsip Hooker, banyak kesulitan dalam membangun sistem berbasis komputer yang kompleks dapat diatasi.

Source: Pressman, Roger S. 2010. Software engineering : A Practitioner’s Approach (7th. Edition). New York: McGraw-Hill Higher Education.