Rancangan perangkat lunak: Perbedaan antara revisi
Impor teks terkontrol dari Wikipedia bahasa Indonesia; revisi 27183715; atribusi sumber disertakan. |
Presentation V4: sitasi, referensi, Math, Wikimedia Commons, dan atribusi |
||
| Baris 1: | Baris 1: | ||
'''Rancangan perangkat lunak''' atau '''desain perangkat lunak''' () adalah proses mengonsepkan cara kerja [[sistem perangkat lunak]] sebelum [[penerapan|diterapkan]] atau diubah. | [[File:W3sDesign_Prototype_Design_Pattern_UML.jpg|thumb|right|280px|W3sDesign Prototype Design Pattern UML]] | ||
'''Rancangan perangkat lunak''' atau '''desain perangkat lunak''' () adalah proses mengonsepkan cara kerja [[sistem perangkat lunak]] sebelum [[penerapan|diterapkan]] atau diubah.<ref>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 .</ref> | |||
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 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. | 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 [[Model air terjun|proses pengembangan air terjun]], rancangan perangkat lunak adalah kegiatan mengikuti [[persyaratan perangkat lunak|spesifikasi persyaratan]] dan sebelum [[Pemrograman|pengodean]]. | Dalam maksud [[Model air terjun|proses pengembangan air terjun]], rancangan perangkat lunak adalah kegiatan mengikuti [[persyaratan perangkat lunak|spesifikasi persyaratan]] dan sebelum [[Pemrograman|pengodean]].<ref>Peter Freeman. ''A Science of design for software-intensive systems''. ''Communications of the ACM''. 2004. Vol. 47 (8). hlm. 19–21 [20]. doi:10.1145/1012037.1012054.</ref> | ||
== Proses umum == | == Proses umum == | ||
| Baris 14: | Baris 16: | ||
== Rancangan berulang untuk Komponen Perangkat Lunak == | == 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.<ref>''Fundamentals of Software Architecture: An Engineering Approach''. O'Reilly Media. 2020. ISBN 978-1492043454.</ref> | |||
Pendekatan ini biasanya melibatkan daur (''cycle'') dengan beberapa tahap:<ref>''Fundamentals of Software Architecture: An Engineering Approach''. O'Reilly Media. 2020. ISBN 978-1492043454.</ref> | |||
Pendekatan ini biasanya melibatkan daur (''cycle'') dengan beberapa tahap: | |||
* 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. | * 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. | ||
| Baris 29: | Baris 30: | ||
== Nilai == | == Nilai == | ||
[[Dokumen rancangan perangkat lunak|Dokumentasi rancangan perangkat lunak]] dapat ditinjau ulang atau disajikan untuk memungkinkan batasan, spesifikasi, dan bahkan persyaratan disesuaikan sebelum [[pemrograman|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,<ref>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</ref> 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. | |||
[[Dokumen rancangan perangkat lunak|Dokumentasi rancangan perangkat lunak]] dapat ditinjau ulang atau disajikan untuk memungkinkan batasan, spesifikasi, dan bahkan persyaratan disesuaikan sebelum [[pemrograman|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, 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 == | == 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]]. | 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]]. | ||
| Baris 39: | Baris 38: | ||
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 perangkat lunak|kerangka kerja]] yang andal atau diterapkan dengan [[pola rancangan]] yang sesuai. | 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 perangkat lunak|kerangka kerja]] yang andal atau diterapkan dengan [[pola rancangan]] yang sesuai. | ||
== | == Referensi == | ||
<references /> | |||
== Sumber dan atribusi == | |||
Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Rancangan+perangkat+lunak&oldid=27183715 Wikipedia bahasa Indonesia], revisi 27183715 (2025-04-24T00:04:11Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Gambar pada artikel ini bersumber dari Wikimedia Commons dan mengikuti ketentuan lisensi masing-masing berkas. Mohon gunakan konten dan media secara bijak serta sesuai dengan ketentuan lisensi yang berlaku. | |||
<!-- WIKI_UNISSULA_PRESENTATION_V4 --> | |||
Revisi terkini sejak 23 Agustus 2026 04.06
Rancangan perangkat lunak atau desain perangkat lunak () 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:[4]
- 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,[5] 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.
Referensi
- ↑ 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 .
- ↑ Peter Freeman. A Science of design for software-intensive systems. Communications of the ACM. 2004. Vol. 47 (8). hlm. 19–21 [20]. doi:10.1145/1012037.1012054.
- ↑ Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. 2020. ISBN 978-1492043454.
- ↑ 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
Sumber dan atribusi
Konten artikel ini diadaptasi dari Wikipedia bahasa Indonesia, revisi 27183715 (2025-04-24T00:04:11Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Gambar pada artikel ini bersumber dari Wikimedia Commons dan mengikuti ketentuan lisensi masing-masing berkas. Mohon gunakan konten dan media secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.