Saat ini saya sedang mengerjakan kelulusan saya untuk studi "Pengembangan Perangkat Lunak" saya, di mana saya harus mengembangkan perangkat lunak yang kompleks secara individu di perusahaan eksternal. Ini semua perlu dilakukan secara terstruktur, membuat semua dokumen yang sesuai.
Untuk proyek ini saya telah memilih untuk bekerja dengan dokumen standar IEEE: Dokumen Persyaratan Perangkat Lunak (SRS), Dokumen Arsitektur Perangkat Lunak (SAD) dan Dokumen Desain Perangkat Lunak (SDD). Meskipun diajarkan sebaliknya di sekolah, untuk proyek ini saya telah memilih untuk membuat SDD setelah pengembangan (bukan sebelumnya). Alasan saya adalah:
Perusahaan tempat saya magang telah memberi saya instruksi untuk membuat perangkat lunak yang kompleks, memuaskan serangkaian persyaratan tertentu, dengan cara eksperimental. Karena jumlah kebebasan yang mereka berikan kepada saya dalam definisi proyek, hampir tidak ada yang pasti sebelumnya, dan paling baik dapat ditemui saat bereksperimen dalam proses pengembangan. Selain itu, saya membuat perangkat lunak secara individual , itu tidak akan bermanfaat bagi siapa pun di perusahaan bagi saya untuk membuat Desain Perangkat Lunak ini sebelumnya. Melakukannya sebelumnya hanya akan menghabiskan banyak waktu untuk mengubahnya nanti, karena saya dapat yakin bahwa dengan ketidakpastian dalam proyek, desain yang saya buat sebelumnya harus banyak diubah . Ini terasa kontraproduktif bagi saya.
Apakah ini pembenaran yang baik untuk membuat SDD setelah pengembangan? Jika tidak, apakah akan ada pembenaran yang baik untuk itu?
Sunting: Alasan untuk membuat SDD setelahnya adalah agar pengembang di masa depan melanjutkan proyek. Saya tidak akan dapat menyelesaikan seluruh proyek dalam periode kelulusan saya, jadi pengembang lain harus melanjutkan basis kode saat ini.
sumber
Jawaban:
Di IEEE Std 1016 Bagian 3.1 Desain perangkat lunak dalam konteks, Anda dapat menemukan paragraf ini:
Penulis IEEE Std 1016 mengakui bahwa SDD mungkin tidak dibuat di muka. Satu dapat dibuat setelah sistem perangkat lunak ada untuk menangkap informasi untuk pihak yang berkepentingan.
Bagian 1.1 Ruang Lingkup juga menyediakan beberapa informasi menarik:
Dalam konteks pertanyaan ini, kata kuncinya adalah "manajemen konfigurasi". Manajemen konfigurasi tidak hanya berlaku untuk sistem perangkat lunak yang sedang dibuat, tetapi juga dokumentasi terkait.
Dalam situasi pribadi Anda, dan dalam banyak situasi, membuat SDD di muka adalah sia-sia. Jawaban David Arno hampir menjadi apa yang saya anggap sebagai jawaban yang benar. Desain sebenarnya dari sistem perangkat lunak Anda adalah kodenya. Namun, Anda "membuat SDD sebelum" atau "membuat SDD setelah" bukan satu-satunya pilihan Anda. Anda memiliki opsi ketiga - mengembangkan SDD dengan sistem perangkat lunak.
Jika Anda mengikuti standar seperti IEEE Std 1016, Anda memiliki persyaratan untuk SDD. Secara khusus, Bagian 4 dari standar ini mendefinisikan konten yang Anda miliki. Saat Anda mengerjakan keputusan desain, mulailah untuk menciptakan berbagai sudut pandang, pandangan, dan overlay. Saat Anda mengambil keputusan, tangkap alasan desainnya.
Ini akan memungkinkan pihak yang tertarik untuk mengikuti evolusi desain perangkat lunak tanpa perlu menggali ke dalam kode. Tentu saja, orang mungkin memiliki komentar atau saran. Jika Anda memperbarui SDD, mereka dapat melacak kemajuan Anda dan memberikan umpan balik tentang pendekatan awal, yang kemudian dapat Anda masukkan ke dalam produk serta SDD. Ketika Anda beralih dari proyek, jika kode perangkat lunak dan SDD sinkron, seseorang harus dapat dengan mudah masuk dan mengambil pekerjaan.
sumber
Jika semua yang Anda cari dari SDD adalah untuk mengkomunikasikan desain dengan orang lain, maka ya, Anda dapat membuatnya setelah pengembangan. Hanya masalahnya, itu kemudian disebut dokumentasi.
Namun, saya ingin menunjukkan bahwa SDD dapat melayani tujuan lain juga. Ini juga dapat membantu Anda untuk berpikir tentang desain dan memastikan Anda "gagal cepat". Ini adalah hal yang baik, terutama jika banyak hal yang tidak pasti sebelumnya karena Anda dapat membuang pendekatan yang tidak akan berhasil sepanjang seluruh implementasi sejak dini. Hal ini juga dapat mencegah Anda memfokuskan pada detail teknis untuk segera, dengan tidak melakukan pengkodean apa pun sampai Anda mengetahui desainnya.
Saya menyarankan Anda untuk setidaknya mencoba SDD sebelumnya. Jika Anda mengalami hal-hal di mana Anda tidak yakin bagaimana cara kerjanya, Anda kemudian dapat membuat prototipe kecil dari masalah yang Anda coba selesaikan. Ini akan memberi Anda pengalaman dalam memecahkan masalah spesifik untuk proyek Anda yang akan bermanfaat bagi kualitas solusi lengkap dalam jangka panjang.
sumber
Satu dokumen desain terperinci yang akan Anda buat adalah kodenya. Itu persis memberitahu kompiler bagaimana membangun aplikasi Anda. Dengan demikian, desain Anda tidak dapat lengkap sebelum bangunan terakhir sebelum pengiriman.
Dokumen desain lain yang Anda buat, seperti SDD, perlu diperbarui setelah Anda menyelesaikan desain (kode) Anda. Oleh karena itu, ada alasan kuat untuk menulis SDD sesudahnya: Anda hanya perlu melakukannya sekali.
Konter yang jelas untuk ini adalah, "seberapa sering Anda benar-benar menulis SDD setelah acara"? Aplikasi dikirim, jadi Anda tidak ingin menghabiskan waktu untuk mendokumentasikan pada tahap itu. Tetapi ini berlaku sama untuk memperbarui yang sudah ada. Mana yang lebih buruk, tidak ada SDD atau SDD yang salah dan tidak bisa dipercaya?
Ada dua alasan untuk menulisnya terlebih dahulu. Pertama, ini mungkin merupakan persyaratan wajib bagi Anda untuk melakukannya (tidak baik; tetapi itu terjadi). Kedua, membuat dokumen seperti itu dapat membantu Anda merumuskan strategi keseluruhan untuk desain. Tapi itu bisa dilakukan dengan sama baiknya dengan menggambar, menulis catatan dll secara informal. Dan karena itu perlu ditulis ulang nanti, ada banyak manfaat untuk pendekatan "cepat dan kotor" untuk proses desain makro di muka.
sumber
The app is shipped, so you aren't likely to want to spend time documenting at that stage.Dalam hal ini aplikasi tidak akan selesai dalam periode kelulusan saya, jadi kami membutuhkan dokumentasi untuk pengembang lain untuk dapat melanjutkan pengembangan produk.Bagi saya, itu bukan argumentasi yang bagus.
Jika benar-benar diperlukan, saya akan berdebat dengan fokus yang kuat pada pengembangan prototipe untuk pemahaman yang lebih baik tentang domain masalah yang tidak diketahui. Namun, bahkan dalam kasus-kasus itu, beberapa desain akan berguna sebelumnya.
sumber
Ada kasus yang harus dibuat untuk melakukannya di depan pula . Karena Anda melakukan ini untuk belajar menulis dokumen seperti ini. Melewati pekerjaan ini karena mungkin tidak 100% diperlukan di sini berarti Anda melewatkan pembelajaran Anda.
Kompromi dapat berupa menulisnya selama implementasi. Sebelum setiap komponen / modul / layar atau subdivisi lain dari program Anda, Anda perlu memikirkannya bagaimana Anda akan membuatnya. Kemudian Anda menambahkan keputusan Anda ke dokumen desain Anda dan kemudian menerapkannya.
Jika ada perubahan nanti, Anda memperbarui dokumen.
Ini memiliki beberapa keunggulan dibandingkan dengan menulis setelah fakta:
Anda akan belajar untuk terus memperbarui dokumen desain ketika persyaratan berubah, kebiasaan yang bermanfaat
Anda akan belajar untuk memikirkan desain sebelum implementasi
Tidak membosankan seperti menulis dokumen desain setelah faktanya
Jika Anda kehabisan waktu, Anda akan memiliki dokumen desain yang menggambarkan apa yang Anda miliki sejauh ini sehingga orang lain dapat melanjutkan pekerjaan Anda
Tidak banyak pekerjaan ekstra dengan cara ini
Karena proyek Anda berjalan, Anda mungkin tidak yakin mengapa Anda sendiri melakukan sesuatu seperti itu dua bulan lalu, dan Anda akan memiliki catatan untuk memberi tahu Anda.
sumber
Dokumen Desain Sistem, catatan persyaratan dasar ditambah pembaruan (fitur baru) saat proyek bergerak maju dengan atribut desain dan solusi baru. Dipertahankan sampai proyek / solusi telah disampaikan. Berguna, itu berkomunikasi dengan semua pihak.
sumber