Principles That Guide Each Framework Activity (Prinsip yang Memandu Setiap Kegiatan Kerangka Kerja) Menurut Roger S. Pressman

 Pada bagian selanjutnya, saya memperhatikan prinsip-prinsip yang memiliki dampak signifikan terhadap kesuksesan setiap aktivitas dalam kerangka kerja generik yang didefinisikan sebagai bagian dari proses pengembangan perangkat lunak. Dalam banyak situasi, prinsip-prinsip yang dibahas untuk setiap kegiatan dalam kerangka kerja tersebut merupakan pengembangan dari prinsip-prinsip yang telah dijelaskan dalam pembahasan sebelumnya. Prinsip-prinsip tersebut mewakili inti dari konsep-konsep yang disajikan pada tingkat abstraksi yang lebih rendah.

1.1 Communication Principles

Sebelum menganalisis, memodelkan, atau menentukan persyaratan pelanggan, langkah awal yang harus dilakukan adalah mengumpulkan persyaratan tersebut melalui kegiatan komunikasi. Seorang pelanggan menghadapi masalah yang mungkin dapat diselesaikan melalui solusi berbasis komputer. Anda merespons permintaan bantuan dari pelanggan tersebut, dan proses komunikasi pun dimulai. Namun, dalam perjalanan dari komunikasi menuju pemahaman, seringkali terdapat hambatan yang perlu diatasi.

Menghadapi tantangan, komunikasi yang efektif adalah salah satu aspek kritis yang perlu diperhatikan dalam berinteraksi dengan rekan teknis, pelanggan, pemangku kepentingan, dan manajer proyek. Dalam konteks ini, saya menjelaskan prinsip-prinsip komunikasi yang berlaku khususnya dalam komunikasi dengan pelanggan. Namun, banyak prinsip yang sama berlaku untuk segala bentuk komunikasi yang terjadi dalam proyek pengembangan perangkat lunak.

Principle 1. Listen. Upayakan untuk memberikan perhatian penuh pada kata-kata yang diucapkan oleh pembicara, alih-alih langsung merencanakan respons Anda terhadap kata-kata tersebut. Jika ada hal yang tidak jelas, mintalah klarifikasi, namun hindari gangguan yang berkelanjutan. Janganlah pernah mengajukan argumen terhadap kata-kata atau tindakan Anda sendiri (seperti menggerakkan mata atau menggelengkan kepala) saat seseorang sedang berbicara.

Principle 2. Prepare before you communicate. Sisihkan waktu untuk memperoleh pemahaman yang mendalam tentang masalah sebelum berinteraksi dengan orang lain. Jika perlu, lakukan penelusuran tambahan untuk memahami istilah khusus dalam domain bisnis tersebut. Jika Anda memiliki tanggung jawab untuk mengadakan pertemuan, persiapkan agenda sebelum pertemuan berlangsung.

Principle 3. Someone should facilitate the activity. Dalam setiap pertemuan komunikasi, penting untuk memiliki seorang pemimpin atau fasilitator yang bertugas menjaga kelancaran percakapan agar tetap produktif. Tugas fasilitator tersebut meliputi menengahi konflik yang muncul dan memastikan penerapan prinsip-prinsip lainnya.

Principle 4. Face-to-face communication is best. Namun, umumnya lebih efektif apabila terdapat representasi lain dari informasi yang relevan. Sebagai contoh, salah satu peserta dapat menciptakan gambar atau dokumen "strawman" yang berfungsi sebagai titik pusat dalam diskusi.

Principle 5. Take notes and document decisions. Situasi seringkali dapat menyebabkan hal-hal terlewatkan atau terlewat dalam komunikasi. Oleh karena itu, setiap peserta yang terlibat dalam interaksi harus bertindak sebagai "perekam" yang mencatat semua poin dan keputusan penting.

Principle 6. Strive for collaboration. Kolaborasi dan mencapai konsensus terjadi saat tim menggunakan pengetahuan kolektif mereka untuk menjelaskan fungsi atau fitur dari produk atau sistem. Setiap bentuk kolaborasi yang dilakukan bertujuan untuk membangun kepercayaan di antara anggota tim dan menciptakan tujuan bersama bagi tim tersebut. 

Principle 7. Stay focused; modularize your discussion. Seiring dengan meningkatnya jumlah orang yang terlibat dalam suatu komunikasi, kemungkinan adanya pergeseran topik dari satu topik ke topik berikutnya juga semakin besar. Oleh karena itu, fasilitator bertanggung jawab menjaga agar percakapan tetap terfokus pada satu topik secara modular, dan beralih ke topik berikutnya hanya setelah topik sebelumnya diselesaikan (tetapi, perlu melihat Prinsip 9).

Principle 8. If something is unclear, draw a picture. Hingga saat ini, komunikasi verbal hanya memiliki keterbatasan. Dalam beberapa kasus, sebuah sketsa atau gambar seringkali dapat memberikan kejelasan yang tidak dapat dicapai hanya dengan kata-kata.

Principle 9. (a) Once you agree to something, move on. (b) If you can’t agree to something, move on. (c) If a feature or function is unclear and cannot be clarified at the moment, move on. Seperti halnya kegiatan rekayasa perangkat lunak lainnya, komunikasi juga membutuhkan waktu. Alih-alih terus-menerus mengulangi hal yang sama, peserta yang terlibat perlu menyadari bahwa banyak topik membutuhkan diskusi (lihat Prinsip 2) dan terkadang "melanjutkan" adalah pendekatan terbaik untuk mencapai fleksibilitas dan keterampilan dalam komunikasi.

Principle 10. Negotiation is not a contest or a game. It works best when both parties win. Terdapat berbagai situasi di mana Anda dan pihak-pihak terkait harus melakukan negosiasi terkait fungsi dan fitur, prioritas, serta tenggat waktu pengiriman. Apabila tim telah berhasil berkolaborasi dengan baik, semua pihak memiliki tujuan yang serupa. Namun, dalam negosiasi diperlukan kompromi dari semua pihak untuk mencapai kesepakatan. 

1.2 Planning Principles

Melalui aktivitas komunikasi, Anda dapat menetapkan tujuan dan sasaran secara keseluruhan (meskipun dapat berubah seiring waktu). Namun, pemahaman tentang tujuan dan sasaran tersebut berbeda dengan menetapkan rencana untuk mencapainya. Aktivitas perencanaan melibatkan serangkaian praktik manajemen dan teknis yang memungkinkan tim perangkat lunak untuk merancang suatu peta jalan dalam mencapai tujuan strategis dan tujuan taktisnya. 

Meskipun berusaha dengan segenap daya upaya, tidak mungkin untuk secara tepat memprediksi bagaimana perkembangan proyek perangkat lunak akan terjadi. Tidak ada cara yang mudah untuk menentukan secara pasti masalah teknis tak terduga yang akan dihadapi, informasi penting yang mungkin tetap tersembunyi hingga akhir proyek, terjadinya kesalahpahaman, atau perubahan dalam masalah bisnis. Namun, tim perangkat lunak yang baik tetap harus merencanakan pendekatannya.

Terdapat beragam filosofi perencanaan yang berbeda. Beberapa individu menganut pendekatan "minimalis" yang berargumen bahwa perubahan sering kali mengurangi kebutuhan akan rencana terperinci. Sebaliknya, ada yang mengikuti pendekatan "tradisionalis" yang berpendapat bahwa rencana yang terperinci memberikan peta jalan yang efektif, dan semakin rinci rencana tersebut, semakin rendah kemungkinan tim tersesat. Selain itu, ada juga yang mengikuti pendekatan "agilists" yang berpendapat bahwa dalam beberapa kasus, "permainan perencanaan" yang cepat mungkin diperlukan, dan peta jalan akan muncul secara bertahap saat "pekerjaan nyata" pada perangkat lunak dimulai.

Apa tindakan yang sebaiknya diambil? Pada banyak proyek, terlalu banyak perencanaan memakan waktu dan tidak memberikan hasil yang signifikan karena banyaknya perubahan yang terjadi. Namun, perencanaan yang minim dapat menyebabkan kekacauan. Seperti halnya dalam kehidupan, perencanaan harus dilakukan dengan sewajarnya, cukup untuk memberikan panduan yang bermanfaat bagi tim — tidak terlalu banyak dan tidak terlalu sedikit. Terlepas dari tingkat keakuratan perencanaan yang dilakukan, prinsip-prinsip berikut tetap berlaku:

Principle 1. Understand the scope of the project. Tidak mungkin merencanakan perjalanan jika Anda tidak mengetahui tujuan akhirnya. Lingkup memberikan tim perangkat lunak arah dan tujuan yang jelas.

Principle 2. Involve stakeholders in the planning activity. Pemangku kepentingan berperan dalam menentukan prioritas dan mengatur batasan proyek. Untuk menghadapi situasi ini, para rekayasa perangkat lunak harus sering kali melakukan negosiasi terkait urutan pengiriman, jadwal waktu, dan masalah-masalah terkait proyek lainnya.

Principle 3. Recognize that planning is iterative. Rencana proyek tidaklah tetap dan tidak mengikat. Ketika pekerjaan dimulai, kemungkinan besar akan terjadi perubahan. Oleh karena itu, rencana harus disesuaikan agar dapat mengakomodasi perubahan tersebut. Selain itu, model proses inkremental yang bersifat iteratif menuntut adanya perencanaan ulang setelah setiap pengiriman peningkatan perangkat lunak berdasarkan umpan balik yang diterima dari pengguna.

Principle 4. Estimate based on what you know. Tujuan dari estimasi adalah untuk memberikan perkiraan mengenai usaha, biaya, dan durasi tugas berdasarkan pemahaman tim saat ini tentang pekerjaan yang perlu dilakukan. Jika informasi yang tersedia tidak jelas atau tidak dapat diandalkan, maka estimasi juga akan menjadi tidak dapat diandalkan. 

Principle 5. Consider risk as you define the plan. Apabila Anda telah mengidentifikasi risiko-risiko yang memiliki dampak dan probabilitas tinggi, maka perlu dilakukan perencanaan kontinjensi. Selain itu, rencana proyek (termasuk jadwal) harus disesuaikan agar dapat mengantisipasi kemungkinan terjadinya satu atau lebih risiko tersebut.

Principle 6. Be realistic. Setiap orang tidak selalu bekerja dengan produktivitas 100 persen setiap hari. Kehadiran gangguan dalam komunikasi manusia adalah hal yang umum. Ketidaktepatan dan ambiguitas adalah bagian dari kehidupan. Perubahan merupakan hal yang tak terhindarkan. Bahkan para insinyur perangkat lunak terbaik pun tidak luput dari membuat kesalahan. Realitas ini dan faktor-faktor lainnya harus dipertimbangkan dalam pembuatan rencana proyek.

Principle 7. Adjust granularity as you define the plan. Granularitas mengacu pada tingkat detail yang diperhatikan saat mengembangkan rencana proyek. Rencana yang memiliki "perincian tinggi" memberikan detail yang signifikan mengenai tugas kerja dengan periode waktu yang relatif pendek (sehingga pelacakan dan pengendalian dilakukan secara teratur). Sementara itu, rencana dengan "perincian rendah" memberikan gambaran lebih umum tentang tugas kerja dalam jangka waktu yang lebih panjang. Secara umum, tingkat detail perencanaan berkurang seiring berjalannya waktu proyek dari tanggal saat ini. Dalam beberapa minggu atau bulan mendatang, proyek dapat direncanakan dengan detail yang lebih rinci. Namun, aktivitas yang akan terjadi berbulan-bulan mendatang tidak memerlukan tingkat detail yang tinggi (terlalu banyak perincian dapat berubah). 

Principle 8. Define how you intend to ensure quality. Dalam rencana tersebut, perlu dijelaskan bagaimana tim perangkat lunak akan menjaga kualitas. Jika tinjauan teknis dijadwalkan, hal itu harus tercantum dalam rencana. Selain itu, jika pemrograman berpasangan akan digunakan selama tahap konstruksi, hal tersebut harus secara eksplisit didefinisikan dalam rencana.

Principle 9. Describe how you intend to accommodate change. Meskipun telah dilakukan perencanaan terbaik, tidak dapat dihindari adanya perubahan yang tidak terkendali. Oleh karena itu, penting bagi Anda untuk mengidentifikasi bagaimana perubahan akan diakomodasi selama proses rekayasa perangkat lunak berlangsung. Sebagai contoh, apakah pelanggan diperbolehkan untuk meminta perubahan kapan saja? Jika ada permintaan perubahan, apakah tim harus segera mengimplementasikannya? Bagaimana penilaian terhadap dampak dan biaya perubahan dilakukan?

Principle 10. Track the plan frequently and make adjustments as required. Proyek perangkat lunak seringkali mengalami keterlambatan dari jadwal yang telah ditetapkan, dan hal ini terjadi secara bertahap dari hari ke hari. Oleh karena itu, penting untuk melakukan pelacakan kemajuan setiap hari, dengan tujuan untuk mengidentifikasi area masalah dan situasi di mana pekerjaan yang direncanakan tidak sesuai dengan pekerjaan yang sebenarnya dilakukan. Jika terjadi selip, maka rencana proyek harus disesuaikan agar dapat mengatasi permasalahan tersebut.

Untuk mencapai efektivitas maksimal, penting bagi setiap individu dalam tim perangkat lunak untuk terlibat dalam aktivitas perencanaan. Hal ini diperlukan agar anggota tim merasa terlibat secara penuh dan berkomitmen terhadap rencana tersebut.

1.3 Modeling Principles

Kami mengembangkan suatu model untuk memperoleh pemahaman yang lebih baik tentang entitas yang akan dibangun. Jika entitas tersebut adalah objek fisik seperti bangunan, pesawat, atau mesin, kami dapat membuat model yang menyerupai bentuk dan ukurannya secara proporsional namun dalam skala yang lebih kecil. Namun, ketika yang dibangun adalah perangkat lunak, model yang kami buat harus memiliki bentuk yang berbeda. Model tersebut harus mampu menggambarkan informasi yang terkait dengan transformasi perangkat lunak, termasuk arsitektur, fungsi, fitur yang diinginkan oleh pengguna, dan perilaku sistem selama proses transformasi berlangsung. Model ini harus mencapai tujuan ini dengan menggunakan tingkat abstraksi yang berbeda, pertama-tama mewakili perangkat lunak dari perspektif pelanggan, dan kemudian menggambarkannya dengan lebih detail pada tingkat teknis.

Dalam rekayasa perangkat lunak, terdapat dua jenis model yang dapat dibuat: model kebutuhan dan model desain. Model kebutuhan, juga dikenal sebagai model analisis, bertujuan untuk menggambarkan kebutuhan pelanggan dengan memperlihatkan perangkat lunak dalam tiga domain yang berbeda: domain informasi, domain fungsional, dan domain perilaku. Di sisi lain, model desain digunakan untuk merepresentasikan karakteristik perangkat lunak yang membantu praktisi dalam membangunnya dengan efektif, termasuk arsitektur, antarmuka pengguna, dan rincian komponen yang lebih terperinci.

Dalam karya mereka tentang pemodelan yang fleksibel, Scott Ambler dan Ron Jeffries menggambarkan serangkaian prinsip pemodelan yang dirancang khusus bagi mereka yang menggunakan pendekatan agile process model namun tetap relevan bagi semua insinyur perangkat lunak yang terlibat dalam aktivitas dan tugas pemodelan:

Principle 1. The primary goal of the software team is to build software, not create models. Agility melibatkan pengiriman perangkat lunak kepada pelanggan dengan cepat. Oleh karena itu, penting untuk menciptakan model yang mendukung tujuan ini, sementara menghindari model yang memperlambat proses atau tidak memberikan wawasan yang berarti.

Principle 2. Travel light—don’t create more models than you need. Setiap model yang dibuat harus selalu diperbarui ketika terjadi perubahan. Lebih penting lagi, setiap model baru memerlukan waktu untuk dibangun (melalui proses pengkodean dan pengujian). Oleh karena itu, disarankan untuk hanya membuat model-model yang dapat mempermudah dan mempercepat pembangunan perangkat lunak.

Principle 3. Strive to produce the simplest model that will describe the problem or the software. Hindarilah kelebihan dalam pembangunan perangkat lunak. Dengan menjaga kesederhanaan model, perangkat lunak yang dihasilkan juga akan bersifat sederhana. Dampaknya adalah perangkat lunak yang lebih mudah untuk diintegrasikan, diuji, dan dipelihara (dimodifikasi). Selain itu, model yang sederhana lebih mudah dipahami dan diberikan kritik oleh anggota tim perangkat lunak, menciptakan umpan balik yang berkelanjutan yang akan mengoptimalkan hasil akhir.

Principle 4. Build models in a way that makes them amenable to change. Harapkan bahwa model Anda akan mengalami perubahan, namun jangan meremehkan dalam membuat asumsi ini. Sebagai contoh, karena persyaratan akan berubah, seringkali ada kecenderungan untuk mengabaikan pentingnya model persyaratan. Mengapa demikian? Karena Anda menyadari bahwa persyaratan juga akan berubah. Masalah dengan pendekatan ini adalah tanpa memiliki model persyaratan yang cukup komprehensif, Anda akan merancang (model desain) yang selalu kehilangan fitur dan fungsi yang krusial.

Principle 5. Be able to state an explicit purpose for each model that is created. Ketika Anda membuat sebuah model, selalu tanyakan pada diri sendiri alasan mengapa Anda melakukannya. Jika Anda tidak dapat memberikan justifikasi yang kuat untuk keberadaan model tersebut, maka jangan membuang waktu untuk membuatnya.

Principle 6. Adapt the models you develop to the system at hand. Dalam beberapa kasus, mungkin perlu mengadaptasi notasi atau aturan yang digunakan dalam pemodelan untuk aplikasi tertentu. Misalnya, untuk aplikasi video game, diperlukan teknik pemodelan yang berbeda dibandingkan dengan perangkat lunak yang mengontrol mesin mobil waktu nyata.

Principle 7. Try to build useful models, but forget about building perfect models. Saat membangun persyaratan dan model desain, seorang insinyur perangkat lunak akan mencapai titik dimana keuntungan yang diperoleh semakin berkurang. Ini berarti, upaya yang diperlukan untuk membuat model yang sepenuhnya lengkap dan konsisten secara internal tidak sebanding dengan manfaat yang diperoleh dari sifat tersebut. Namun, hal ini tidak berarti bahwa pemodelan harus diabaikan atau memiliki kualitas rendah. Pemodelan tetap perlu dilakukan dengan mempertimbangkan langkah-langkah rekayasa perangkat lunak yang akan datang. Terus-menerus berusaha untuk mencapai model yang "sempurna" tidak akan memenuhi kebutuhan fleksibilitas dan ketangkasan yang diperlukan.

Principle 8. Don’t become dogmatic about the syntax of the model. If it communicates content successfully, representation is secondary. Walaupun penting bagi setiap anggota tim perangkat lunak untuk menggunakan notasi yang konsisten saat melakukan pemodelan, yang paling penting dari sebuah model adalah kemampuannya untuk menyampaikan informasi yang diperlukan untuk tugas-tugas rekayasa perangkat lunak selanjutnya. Jika model berhasil mencapai tujuan tersebut, kesalahan sintaksis dapat diampuni.

 Principle 9. If your instincts tell you a model isn’t right even though it seems okay on paper, you probably have reason to be concerned. Apabila Anda merupakan seorang insinyur perangkat lunak berpengalaman, ada baiknya Anda mempercayai insting Anda. Pengalaman dalam pekerjaan perangkat lunak membawa banyak pelajaran yang terkadang tersimpan dalam alam bawah sadar. Jika ada suatu kepercayaan yang mengatakan bahwa model desain akan gagal (meskipun tidak dapat dibuktikan secara eksplisit), ada alasan kuat untuk meluangkan waktu tambahan untuk memeriksa model tersebut atau bahkan mengembangkan model yang berbeda.

Principle 10. Get feedback as soon as you can. Semua model perlu dievaluasi oleh tim pengembang perangkat lunak. Tujuan dari proses peninjauan ini adalah untuk mendapatkan umpan balik yang berguna dalam memperbaiki kesalahan pemodelan, mengklarifikasi interpretasi yang salah, serta menambahkan fitur atau fungsi yang mungkin terlewatkan secara tidak sengaja.

Requirements modeling principles. Dalam tiga dekade terakhir, telah terjadi perkembangan yang signifikan dalam metode pemodelan kebutuhan. Para peneliti telah mengidentifikasi masalah yang terkait dengan analisis kebutuhan beserta penyebabnya, dan telah mengembangkan berbagai notasi pemodelan dan rangkaian heuristik yang relevan untuk mengatasi masalah tersebut. Setiap metode analisis memiliki perspektif yang unik, tetapi semua metode tersebut terkait dengan sekumpulan prinsip operasional yang serupa:

Principle 1. The information domain of a problem must be represented and understood. Domain informasi meliputi aliran data masuk ke sistem (dari pengguna akhir, sistem lain, atau perangkat eksternal), aliran data keluar dari sistem (melalui antarmuka pengguna, antarmuka jaringan, laporan, grafik, dan alat lainnya), serta penyimpanan data yang mengumpulkan dan mengatur objek data yang persisten (yaitu, data yang tetap ada secara permanen).

Principle 2. The functions that the software performs must be defined. Fungsi perangkat lunak memberikan manfaat langsung kepada pengguna akhir dan juga menyediakan dukungan internal untuk fitur-fitur yang terlihat oleh pengguna. Beberapa fungsi mengubah data yang mengalir ke dalam sistem. Dalam situasi lain, fungsi memiliki pengaruh pada berbagai tingkat kontrol terhadap pemrosesan internal perangkat lunak atau elemen sistem eksternal. Fungsi dapat dijelaskan pada berbagai tingkat abstraksi, mulai dari tujuan umum hingga deskripsi rinci tentang elemen pemrosesan yang harus dilakukan.

Principle 3. The behavior of the software (as a consequence of external events) must be represented. Perilaku perangkat lunak komputer dikendalikan oleh interaksinya dengan lingkungan eksternal. Interaksi ini melibatkan input yang diberikan oleh pengguna akhir, data kontrol yang diperoleh dari sistem eksternal, atau pemantauan data yang dikumpulkan melalui jaringan. Semua elemen ini berkontribusi pada perilaku khusus yang ditampilkan oleh perangkat lunak.

Principle 4. The models that depict information, function, and behavior must be partitioned in a manner that uncovers detail in a layered (or hierarchical) fashion. Pemodelan kebutuhan merupakan langkah awal dalam memecahkan masalah dalam rekayasa perangkat lunak. Langkah ini membantu dalam pemahaman yang lebih baik terhadap masalah yang dihadapi dan membentuk dasar untuk merancang solusi yang tepat. Masalah yang kompleks seringkali sulit untuk diselesaikan secara keseluruhan. Oleh karena itu, penting untuk menerapkan strategi divide-and-conquer atau memecah masalah besar dan kompleks menjadi sub-masalah yang lebih kecil dan lebih terkelola. Pendekatan ini dikenal sebagai partisi atau pemisahan perhatian, dan merupakan strategi kunci dalam proses pemodelan kebutuhan.

Principle 5. The analysis task should move from essential information toward implementation detail. Pemodelan kebutuhan dimulai dengan menggambarkan masalah dari perspektif pengguna akhir, tanpa memperhatikan detail implementasi solusi. Misalnya, dalam konteks video game, masalah intinya adalah memerintahkan protagonis untuk bergerak melalui labirin berbahaya. Pada tahap ini, fokus utamanya adalah mengidentifikasi esensi masalah tersebut. Detail implementasi, yang biasanya termasuk dalam model desain, menjelaskan bagaimana esensi tersebut akan diwujudkan. Dalam konteks video game, contohnya bisa menggunakan input suara, mengetik perintah keyboard, mengarahkan joystick (atau mouse) ke arah tertentu, atau menggunakan perangkat yang responsif terhadap gerakan.

Dengan menerapkan prinsip-prinsip ini, seorang insinyur perangkat lunak mengadopsi pendekatan sistematis dalam memecahkan suatu masalah. Namun, bagaimana prinsip-prinsip ini diterapkan dalam praktik? Pertanyaan ini akan dijelaskan lebih lanjut dalam pembahasan berikutnya.

Design Modeling Principles. Model desain perangkat lunak memiliki kemiripan dengan rencana arsitektur untuk sebuah rumah. Dimulai dengan menggambarkan keseluruhan objek yang akan dibangun (seperti rendering tiga dimensi rumah), model tersebut kemudian dikembangkan secara bertahap untuk memberikan panduan dalam membangun setiap detail (seperti tata letak saluran air). Secara serupa, model desain yang dibuat untuk perangkat lunak menyajikan berbagai tampilan sistem yang berbeda.

Terdapat banyak metode yang dapat digunakan untuk mengembangkan elemen-elemen desain perangkat lunak. Beberapa metode mengambil pendekatan yang didasarkan pada data, di mana struktur data menentukan arsitektur program dan komponen pemrosesan yang dihasilkan. Metode lain menggunakan pola, dengan menggunakan informasi tentang domain masalah (model persyaratan) untuk mengembangkan gaya arsitektur dan pola pemrosesan. Ada pula metode yang berorientasi objek, di mana objek dalam domain masalah menjadi penggerak dalam pembuatan struktur data dan metode yang memanipulasinya. Meskipun beragam, semua metode ini mengikuti seperangkat prinsip desain yang dapat diterapkan terlepas dari metode yang digunakan:

Principle 1. Design should be traceable to the requirements model. Model persyaratan menggambarkan domain informasi yang terkait dengan masalah, fungsi-fungsi yang terlihat oleh pengguna, perilaku sistem, serta kelas-kelas persyaratan yang membungkus objek bisnis dan metode yang terlibat. Model desain berfungsi untuk menerjemahkan informasi tersebut ke dalam sebuah arsitektur yang terdiri dari sejumlah subsistem yang mengimplementasikan fungsi-fungsi utama, serta kumpulan komponen yang mewujudkan kelas-kelas kebutuhan. Seluruh elemen dalam model desain harus dapat dilacak keterhubungannya dengan model persyaratan.

Principle 2. Always consider the architecture of the system to be built. Arsitektur perangkat lunak merujuk pada kerangka sistem yang akan dikembangkan. Arsitektur ini memiliki pengaruh yang luas, termasuk pada antarmuka, struktur data, alur kontrol program, metode pengujian, pemeliharaan sistem, dan aspek lainnya. Oleh karena itu, dalam proses desain, pertimbangan arsitektural harus menjadi prioritas utama. Setelah arsitektur telah ditetapkan, maka baru masalah komponen pada tingkat yang lebih terperinci dapat dipertimbangkan.

Principle 3. Design of data is as important as design of processing functions. Desain data memegang peranan penting dalam desain arsitektur. Pentingnya bagaimana objek data diimplementasikan dalam desain tidak boleh diabaikan begitu saja. Melalui desain data yang terstruktur dengan baik, alur program dapat disederhanakan, desain dan implementasi komponen perangkat lunak menjadi lebih mudah, dan efisiensi pemrosesan secara keseluruhan dapat ditingkatkan.

Principle 4. Interfaces (both internal and external) must be designed with care. Hubungan antara aliran data di antara komponen sistem memiliki dampak yang signifikan pada efisiensi pemrosesan, penyebaran kesalahan, dan kesederhanaan desain. Dengan merancang antarmuka dengan baik, integrasi antar komponen menjadi lebih mudah dilakukan dan membantu penguji dalam melakukan validasi terhadap fungsi komponen tersebut.

Principle 5. User interface design should be tuned to the needs of the end user. However, in every case, it should stress ease of use. Antarmuka pengguna merupakan bagian yang terlihat secara langsung dari perangkat lunak. Meskipun fungsi internalnya sangat canggih dan struktur datanya komprehensif, serta arsitektur yang baik dirancang, jika desain antarmukanya buruk, seringkali akan menciptakan persepsi bahwa perangkat lunak tersebut "buruk".

Principle 6. Component-level design should be functionally independent. Kemandirian fungsional mengacu pada tingkat "kesatuan pikiran" dalam sebuah komponen perangkat lunak. Fungsionalitas yang dimiliki oleh komponen tersebut haruslah kohesif, artinya fokus pada satu fungsi atau subfungsi saja.

Principle 7. Components should be loosely coupled to one another and to the external environment. Hubungan antara komponen dapat terjadi melalui berbagai cara, seperti antarmuka komponen, pengiriman pesan, atau penggunaan data global. Ketika tingkat hubungan antara komponen meningkat, risiko propagasi kesalahan juga meningkat, dan pemeliharaan keseluruhan perangkat lunak menjadi lebih sulit. Oleh karena itu, penting untuk menjaga hubungan antara komponen seminimal mungkin.

Principle 8. Design representations (models) should be easily understandable. Maksud dari desain adalah untuk menyampaikan informasi kepada para profesional yang akan mengimplementasikannya dalam bentuk kode, kepada mereka yang akan melakukan pengujian perangkat lunak, dan kepada pihak lain yang mungkin akan melakukan pemeliharaan di masa depan. Jika desain tersebut sulit dipahami, maka tidak akan efektif sebagai alat komunikasi.

Principle 9. The design should be developed iteratively. With each iteration, the designer should strive for greater simplicity. Seperti dalam sebagian besar proses kreatif, desain melibatkan iterasi berulang. Iterasi awal bertujuan untuk meningkatkan desain dan memperbaiki kesalahan, sementara iterasi berikutnya bertujuan untuk menyederhanakan desain sebanyak mungkin.

Dengan menerapkan prinsip-prinsip desain ini secara tepat, Anda akan menghasilkan desain yang mencerminkan faktor kualitas eksternal dan internal. Faktor kualitas eksternal mengacu pada atribut perangkat lunak yang dapat dengan mudah dilihat oleh pengguna (seperti kecepatan, keandalan, kebenaran, dan kegunaan). Sementara itu, faktor kualitas internal merupakan hal yang sangat penting bagi para insinyur perangkat lunak. Hal ini berhubungan dengan desain yang berkualitas tinggi dari perspektif teknis. Untuk mencapai faktor kualitas internal ini, perancang harus memiliki pemahaman yang baik tentang konsep desain dasar.

1.4 Construction Principles

Aktivitas konstruksi melibatkan serangkaian tugas yang meliputi pengkodean dan pengujian untuk menghasilkan perangkat lunak yang siap digunakan oleh pelanggan atau pengguna akhir. Dalam rekayasa perangkat lunak modern, pengkodean dapat dilakukan melalui beberapa cara, seperti (1) langsung membuat kode sumber dalam bahasa pemrograman tertentu seperti Java, (2) menggunakan representasi perantara untuk menghasilkan kode sumber secara otomatis dari komponen yang akan dibangun, atau (3) menghasilkan kode yang dapat dieksekusi secara otomatis menggunakan "bahasa pemrograman generasi keempat" seperti Visual C++.

Pada awalnya, fokus pengujian berpusat pada level komponen, yang sering disebut sebagai pengujian unit. Selain itu, ada tingkatan pengujian lain yang meliputi (1) pengujian integrasi yang dilakukan saat sistem sedang dibangun, pengujian validasi yang mengevaluasi apakah persyaratan telah terpenuhi untuk sistem secara keseluruhan (atau peningkatan perangkat lunak), dan (3) pengujian penerimaan yang dilakukan oleh pelanggan untuk memastikan bahwa semua fitur dan fungsi yang dibutuhkan berjalan dengan baik. Beberapa prinsip dan konsep dasar berikut ini berlaku dalam konteks pengkodean dan pengujian:

Coding Principles. Ada beberapa prinsip dasar yang dapat diterapkan dalam tugas pengkodean, dan prinsip-prinsip ini sejalan dengan gaya pemrograman, bahasa pemrograman, dan metode pemrograman yang digunakan. Berikut ini beberapa prinsip dasar yang dapat dijelaskan:

Preparation principles: Sebelum Anda memulai menulis kode, penting untuk memastikan bahwa Anda

• Sebelum memulai, ada baiknya Anda memahami dengan baik masalah yang ingin Anda selesaikan.
• Sangat penting untuk memiliki pemahaman yang mendalam tentang prinsip-prinsip dan konsep dasar desain sebelum melangkah lebih jauh.
• Tentukan bahasa pemrograman yang sesuai dengan persyaratan perangkat lunak yang akan dikembangkan dan lingkungan operasional tempatnya akan digunakan.
• Pilihlah lingkungan pemrograman yang menyediakan berbagai alat yang dapat memfasilitasi tugas Anda.
• Buatlah himpunan pengujian unit yang akan diterapkan setelah penyelesaian komponen kode yang Anda buat.

Programming principles: Ketika Anda memulai proses penulisan kode, pastikanlah bahwa Anda

• Ketika Anda memulai proses penulisan kode, pastikanlah bahwa Anda
• Perhatikan kemungkinan menggunakan pendekatan pemrograman berpasangan.
• Pilihlah jenis struktur data yang sesuai untuk memenuhi kebutuhan desain yang ada.
• Memahami secara mendalam arsitektur perangkat lunak dan menciptakan antarmuka yang konsisten dengan arsitektur tersebut.
• Upayakan untuk menjaga kesederhanaan logika kondisional sebisa mungkin.
• Buatlah struktur loop yang terjalin dengan cara yang memudahkan pengujian.
• Pilihlah nama variabel yang memiliki makna dan sesuai dengan standar pengkodean yang berlaku di lingkungan pengembangan.
• Tulislah kode yang memiliki dokumentasi yang jelas dan dapat dipahami tanpa perlu penjelasan tambahan.
• Buatlah tata letak visual yang menggunakan lekukan dan spasi kosong untuk memperjelas dan memudahkan pemahaman.

Validation Principles: Setelah menyelesaikan kode sumber awal, pastikan Anda

• Apabila diperlukan, lakukan pencarian kode.
• Melakukan pengujian unit dan memperbaiki kesalahan yang ditemukan merupakan langkah yang harus dilakukan.
• Melakukan refaktor kode adalah proses mengubah struktur dan desain kode yang sudah ada tanpa mengubah fungsionalitasnya.

Testing Principles. Dalam salah satu buku yang menjadi referensi utama tentang pengujian perangkat lunak, Glen Myers mengungkapkan sejumlah prinsip yang dapat dijadikan pedoman yang efektif dalam melakukan pengujian:

• Pengujian adalah langkah-langkah yang dilakukan untuk menjalankan program dengan tujuan mengidentifikasi kesalahan atau kekurangan yang mungkin terjadi.
• Test case yang efektif adalah yang memiliki kemungkinan besar untuk mengungkapkan kesalahan yang belum terdeteksi sebelumnya.
• Tes yang sukses adalah tes yang berhasil mengidentifikasi kesalahan yang belum terdeteksi sebelumnya.

Tujuan ini mengimplikasikan perubahan yang signifikan dalam pandangan beberapa pengembang perangkat lunak. Mereka menggeser pandangan umum yang menyatakan bahwa pengujian yang berhasil adalah pengujian yang tidak menemukan kesalahan. Tujuan Anda adalah merancang pengujian yang secara sistematis mengidentifikasi berbagai jenis kesalahan dan melakukannya dengan waktu dan usaha yang minimal.

Jika pengujian berhasil dilakukan sesuai dengan tujuan yang telah disebutkan sebelumnya, maka akan terungkap kesalahan dalam perangkat lunak. Sebagai hasil tambahan, pengujian juga mengindikasikan bahwa fungsi perangkat lunak tampaknya berfungsi sesuai dengan spesifikasinya, dan bahwa persyaratan perilaku dan kinerja tampaknya terpenuhi. Selain itu, data yang terkumpul selama pengujian memberikan petunjuk tentang keandalan yang baik dan beberapa indikasi tentang kualitas keseluruhan perangkat lunak. Namun, penting untuk diingat bahwa pengujian tidak dapat membuktikan ketiadaan kesalahan dan kekurangan; pengujian hanya dapat menunjukkan keberadaan kesalahan dan kekurangan dalam perangkat lunak. Pernyataan ini perlu diingat dengan sengaja saat melakukan pengujian yang sedang berlangsung.

Davis mengusulkan sekumpulan prinsip pengujian yang telah disesuaikan untuk digunakan dalam buku ini:

Principle 1. All tests should be traceable to customer requirements. Pengujian perangkat lunak bertujuan untuk mendeteksi kesalahan. Oleh karena itu, kesalahan yang paling serius (dalam konteks pengguna) adalah yang menyebabkan program tidak memenuhi persyaratannya.

Principle 2. Tests should be planned long before testing begins. Pembuatan rencana pengujian dapat dimulai segera setelah model persyaratan selesai. Penentuan detail kasus uji dapat dimulai segera setelah model desain dikonsolidasikan. Dengan demikian, seluruh pengujian dapat direncanakan dan didesain sebelum kode dikembangkan.

Principle 3. The Pareto principle applies to software testing. Dalam situasi ini, prinsip Pareto menunjukkan bahwa sebagian besar, yaitu sekitar 80 persen, dari kesalahan yang terdeteksi selama pengujian mungkin berasal dari sekitar 20 persen komponen program. Tantangannya adalah mengidentifikasi komponen yang menjadi perhatian ini dan melakukan pengujian yang komprehensif terhadapnya.

Principle 4. Testing should begin “in the small” and progress toward testing “in the large”. Pada tahap awal perencanaan dan pelaksanaan pengujian, biasanya difokuskan pada pengujian komponen secara individual. Namun, seiring berjalannya pengujian, perhatian bergeser untuk mencari kesalahan dalam kelompok komponen yang terintegrasi dan akhirnya dalam sistem secara keseluruhan.

Principle 5. Exhaustive testing is not possible. Banyaknya kemungkinan permutasi jalur, bahkan untuk program berukuran sedang, sangatlah besar. Oleh karena itu, tidak memungkinkan untuk menjalankan setiap kombinasi jalur selama pengujian. Namun, ada cara untuk mencakup logika program dengan baik dan memastikan bahwa semua kondisi dalam desain tingkat komponen telah diuji.

1.5 Deployment Principles

Seperti yang telah saya catat sebelumnya, aktivitas implementasi melibatkan tiga langkah utama: pengiriman, dukungan, dan umpan balik. Dalam model proses perangkat lunak yang modern, yang bersifat evolusioner atau inkremental, proses penyebaran tidak terjadi hanya sekali, tetapi berulang kali seiring perangkat lunak bergerak menuju penyelesaian. Setiap siklus pengiriman memberikan peningkatan pada perangkat lunak yang dapat digunakan oleh pelanggan dan pengguna akhir, dengan menyediakan fungsi dan fitur baru. Setiap siklus dukungan memberikan dokumentasi dan bantuan manusia untuk semua fungsi dan fitur yang diperkenalkan sepanjang siklus penerapan. Setiap siklus umpan balik memberikan panduan berharga kepada tim perangkat lunak, yang menghasilkan modifikasi pada fungsi, fitur, dan pendekatan yang akan diadopsi pada peningkatan berikutnya.

Pengiriman peningkatan perangkat lunak adalah langkah penting dalam setiap proyek perangkat lunak. Saat tim bersiap untuk melakukan pengiriman, ada beberapa prinsip utama yang harus diikuti:

Principle 1. Customer expectations for the software must be managed. Terlalu sering, pelanggan memiliki harapan yang melebihi yang telah dijanjikan oleh tim, yang pada akhirnya menyebabkan kekecewaan. Hal ini mengarah pada umpan balik yang tidak produktif dan dapat merusak semangat tim. Dalam bukunya tentang mengelola ekspektasi, Naomi Karten menekankan pentingnya berhati-hati dalam komunikasi dan penyampaian pesan. Sebagai seorang insinyur perangkat lunak, penting untuk berhati-hati dalam menghindari menyampaikan pesan yang bertentangan dengan pelanggan, seperti memberikan janji yang tidak dapat realistis atau memberikan lebih dari yang dijanjikan pada satu peningkatan perangkat lunak dan kemudian kurang dari yang dijanjikan pada peningkatan berikutnya.

Principle 2. A complete delivery package should be assembled and tested. Media penyimpanan seperti CD-ROM atau media lainnya (termasuk unduhan berbasis web) yang berisi seluruh perangkat lunak yang dapat dijalankan, file data pendukung, dokumen pendukung, dan informasi relevan lainnya harus dikompilasi dan dites beta secara menyeluruh dengan pengguna sebenarnya. Semua skrip instalasi dan fitur operasional lainnya juga harus diuji secara menyeluruh dalam berbagai konfigurasi komputasi yang berbeda, termasuk perangkat keras, sistem operasi, perangkat periferal, dan pengaturan jaringan yang berbeda.

Principle 3. A support regime must be established before the software is delivered. Harapan pengguna akhir adalah adanya respons cepat dan informasi yang akurat ketika mereka menghadapi pertanyaan atau masalah. Jika dukungan yang diberikan bersifat acak atau bahkan tidak ada sama sekali, kepuasan pelanggan akan segera terganggu. Oleh karena itu, perlu adanya perencanaan dukungan, persiapan bahan pendukung, dan pengaturan mekanisme pencatatan yang tepat sehingga tim pengembang perangkat lunak dapat melakukan evaluasi terperinci terhadap jenis dukungan yang dibutuhkan.

Principle 4. Appropriate instructional materials must be provided to end users. Tim pengembang perangkat lunak menyediakan lebih dari sekadar perangkat lunak itu sendiri. Jika diperlukan, perlu dikembangkan alat bantu pelatihan yang sesuai. Selain itu, panduan pemecahan masalah harus disediakan, dan jika perlu, informasi mengenai "apa yang berbeda pada peningkatan perangkat lunak ini" harus dipublikasikan.

Principle 5. Buggy software should be fixed first, delivered later. Dalam situasi yang mendesak, beberapa organisasi perangkat lunak menghasilkan peningkatan kualitas yang rendah dengan memberikan peringatan kepada pelanggan bahwa bug akan diperbaiki pada rilis selanjutnya. Hal ini merupakan kesalahan yang tidak seharusnya dilakukan. Ada sebuah pepatah dalam bisnis perangkat lunak yang mengatakan: "Pelanggan mungkin melupakan jika Anda memberikan produk berkualitas tinggi dengan sedikit keterlambatan, tetapi mereka tidak akan pernah melupakan masalah yang ditimbulkan oleh produk berkualitas rendah. Perangkat lunak tersebut akan mengingatkan mereka setiap harinya."

Pengguna akhir mendapatkan manfaat dari perangkat lunak yang disampaikan, namun juga memberikan umpan balik yang berharga bagi tim perangkat lunak. Dalam penggunaan metode inkremental, pengguna akhir diharapkan memberikan komentar mengenai fitur dan fungsi, kemudahan penggunaan, keandalan, serta karakteristik lain yang relevan.

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