Rancangan perangkat lunak

Rancangan perangkat lunak atau desain perangkat lunak (bahasa Inggris: software design) adalah proses mengonsepkan cara kerja sistem perangkat lunak sebelum diterapkan atau diubah.^[1] Rancangan perangkat lunak juga merujuk pada hasil langsung dari proses perancangan – yaitu konsep tentang cara kerja perangkat lunak yang terdiri dari dokumentasi rancangan dan konsep yang tak terdokumentasi.

Rancangan perangkat lunak biasanya diarahkan oleh tujuan untuk sistem yang dihasilkan dan melibatkan pemecahan masalah dan perencanaan – termasuk arsitektur perangkat lunak tingkat tinggi dan rancangan komponen dan algoritma tingkat rendah.

Dalam maksud proses pengembangan air terjun, rancangan perangkat lunak adalah kegiatan mengikuti spesifikasi persyaratan dan sebelum pengodean.^[2]

Proses umum

Proses perancangan memungkinkan seorang perancang untuk memodelkan berbagai aspek sistem perangkat lunak sebelum sistem tersebut ada.

Daya cipta, pengalaman lama, pemahaman tentang apa yang membuat perangkat lunak "baik", dan komitmen terhadap kualitas merupakan faktor keberhasilan untuk rancangan yang cakap. Namun, proses perancangan tidak selalu merupakan tata cara yang mudah.

Model rancangan perangkat lunak dapat dibandingkan dengan rencana arsitektur untuk sebuah rumah. Rencana tingkat tinggi menggambarkan keseluruhan rumah (misalnya, rekacitra rumah dalam tiga dimensi). Rencana tingkat rendah memberikan panduan untuk membangun setiap rincian (misalnya, pemasangan pipa). Demikian pula, model rancangan perangkat lunak memberikan berbagai tampilan solusi perangkat lunak yang diusulkan.

Rancangan berulang untuk Komponen Perangkat Lunak

Sistem perangkat lunak pada dasarnya menghadapi ketidakpastian, dan ukuran komponen perangkat lunak dapat memengaruhi hasil sistem secara kentara, baik secara positif maupun negatif. Neal Ford dan Mark Richards mengusulkan pendekatan berulang (iterative) untuk mengatasi tantangan dalam mengidentifikasi dan menyesuaikan ukuran komponen. Metode ini menekankan penyempurnaan berkelanjutan saat tim mengembangkan pemahaman yang lebih bernuansa tentang perilaku dan persyaratan sistem.^[3]

Pendekatan ini biasanya melibatkan daur (cycle) dengan beberapa tahap:^[3]

Strategi pemisahan tingkat tinggi ditetapkan, yang sering dikategorikan sebagai teknis atau berdasarkan domain. Pedoman untuk satuan terkecil yang dapat dikerahkan (disebarkan), disebut sebagai "kuanta," ditetapkan. Walau keputusan mendasar ini dibuat lebih awal, keputusan tersebut dapat ditinjau kembali nanti dalam daur tersebut jika perlu.
Komponen awal diidentifikasi berdasarkan strategi yang ditetapkan.
Persyaratan ditetapkan pada komponen yang diidentifikasi.
Peran dan tanggung jawab setiap komponen dianalisis untuk memastikan kejelasan dan mengurangi tumpang tindih.
Karakteristik arsitektur, seperti skalabilitas, daya tahan kesalahan, dan kemudahan perawatan, dinilai.
Komponen dapat disusun ulang berdasarkan umpan balik dari tim pengembangan.

Daur ini berfungsi sebagai kerangka kerja umum dan dapat disesuaikan dengan berbagai domain.

Nilai

Dokumentasi rancangan perangkat lunak dapat ditinjau ulang atau disajikan untuk memungkinkan batasan, spesifikasi, dan bahkan persyaratan disesuaikan sebelum pengodean. Perancangan ulang dapat terjadi setelah peninjauan ulang simulasi atau purwarupa (prototipe) yang terprogram. Dimungkinkan pula perancangan perangkat lunak dalam proses pengkodean, tanpa rencana atau analisis persyaratan,^[4] tetapi untuk proyek yang lebih rumit hal ini kurang memungkinkan. Rancangan terpisah sebelum pengodean memungkinkan perancang banyak disiplin dan pakar subjek bekerja sama dengan pemrogram untuk menghasilkan perangkat lunak yang berguna dan secara teknis baik.

Analisis persyaratan

Salah satu komponen rancangan perangkat lunak adalah analisis persyaratan perangkat lunak (APRL). APRL adalah bagian dari proses pengembangan perangkat lunak yang mencantumkan spesifikasi yang digunakan dalam rekayasa perangkat lunak.

Keluaran analisis adalah masalah yang lebih kecil untuk dipecahkan. Sebaliknya, rancangan berfokus pada kemampuan, dan dengan begini beberapa rancangan untuk masalah yang sama dapat muncul. Bergantung pada lingkungannya, rancangan sering kali beragam, apakah dibuat dari kerangka kerja yang andal atau diterapkan dengan pola rancangan yang sesuai.

Rujukan

^ Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 DOI:10.1007/978-3-540-92966-6_6.
^ Freeman, Peter; David Hart (2004). "A Science of design for software-intensive systems". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054. S2CID 14331332.
^ ^a ^b Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454.
^ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136