Menjelaskan hubungan antara kebutuhan project dan sistem yang sedang dikembangkan. Tujuannya yaotu Sebagian besar metodologi yang berorientasi pada proses dimaksudkan untuk merekam program saat mereka terjadi dan memberikan informasi kembali ke manajer, peneliti lain, pembuat kebijakan untuk membantu mereka dalam memahami kerja dari proyek yang lebih baik.
Namun ada beberapa tujuan lain, sama pentingnya, yang proses dicari dan mereka. Ketepatan menjelaskan langkah-langkah pembuatan aplikasi sistem SDLC (System Development Life Circle):
· Observasi: membutuhkan data / requirement
· Analisa
· Desain
· Coding
· Testing
· Implementasi
Fungsinya mencatat seluruh proses dari proses maintenance-nya (pemeliharaannya). Rencana, Jadwal, Kualitas proses dokumen dan organisasi serta standar proyek adalah proses dokumentasi. Tujuannya adalah untuk pengembangan sistem, agar dapat dikelola dan itu termasuk komponen penting.
Proses dokumentasi perangkat lunak harus mencakup langkah-langkah berikut :
1. Mengidentifikasi tujuan untuk penulis teknis - Apakah ini sebuah dokumen instruksional ? Sebuah dokumen dukungan ?
2. Ikuti aturan tata bahasa - Tanpa struktur kalimat yang tepat , seseorang tidak akan mampu mengikuti isi dari dokumentasi perangkat lunak dengan cara yang efektif .
3. Screen shot adalah membantu - Jika memungkinkan, gunakan screen shot dari program perangkat lunak untuk menunjukkan pembaca apa petunjuk dalam dokumen mengacu . Gunakan gambar layar yang lebih kecil untuk fokus pada langkah-langkah atau tugas-tugas tertentu .
4. Menulis untuk pembaca tingkat terendah - Sementara dokumen teknis mungkin tampaknya ditulis untuk pembaca tingkat atas , pastikan bahwa menulis juga bisa diakses pembaca tingkat terendah . Ingat , audiens yang lebih luas berarti menulis teknis harus sederhana .
5. Gunakan format yang luas - Dokumen tidak boleh blok teks , melainkan harus mencakup margin yang lebih luas dan ruang putih yang memungkinkan untuk membaca lebih mudah . Ketika Anda melakukan ini, Anda akan memastikan pembaca dapat membaca , menyerap aspek-aspek teknis dari apa yang perlu dilakukan , dan kemudian pindah ke langkah berikutnya ( s ) .
6. Sertakan referensi , sesuai kebutuhan - Jika referensi telah digunakan , mereka harus dimasukkan dalam dokumen sebagai sumber untuk informasi lebih lanjut .
7. Memiliki dokumen teknis terakhir - Sebelum dokumentasi perangkat lunak disampaikan , harus ditinjau dalam tim teknis menulis , QA dan UKM untuk memastikan efektivitas serta ketepatan .
Dokumentasi perangkat lunak biasanya tidak otomatis dihasilkan oleh program komputer . Instruksi yang efektif , penjelasan dan pedoman yang dibuat oleh penulis teknis yang memahami apa yang pembaca perlu ketahui dan bagaimana informasi ini dapat disajikan dalam cara yang mudah diakses .
Penggunaan proses software yang tradisional menggunakan SDLC SDLC (System Development Life Circle). Penggunaan secara tradisional cenderung banyak yang menolak karena butuh biaya, waktu untuk memproduksi dokumen, dan produksinya menjadi lambat. Jika ada perubahan, dokumen segera ditulis khusus dokumen yang out-of-date.
Agile vs Waterfall Methodology
Apa itu metodologi waterfall ?
Sama seperti konstruksi dan manufaktur workflow , metodologi waterfall adalah proses desain berurutan . Ini berarti bahwa masing-masing dari delapan tahap ( konsepsi , inisiasi , analisis , desain, konstruksi , pengujian , implementasi, dan pemeliharaan ) selesai, pengembang beralih ke langkah berikutnya.
Karena proses ini adalah berurutan , setelah langkah telah selesai , pengembang tidak bisa kembali ke langkah sebelumnya - bukan tanpa menggaruk seluruh proyek dan mulai dari awal . Tidak ada ruang untuk perubahan atau kesalahan , sehingga hasil proyek dan rencana yang luas harus ditetapkan di awal dan kemudian diikuti dengan seksama .
Kapan kita harus menggunakan metodologi waterfall ?
1 . Ketika ada gambaran yang jelas tentang apa produk akhir harus .
2 . Ketika klien tidak akan memiliki kemampuan untuk mengubah lingkup proyek setelah dimulai .
3 . Ketika definisi, bukan kecepatan , adalah kunci keberhasilan .
Apa itu Metodologi Agile ?
Agile muncul sebagai " solusi " untuk kerugian dari metodologi waterfall . Alih-alih proses desain berurutan , metodologi Agile berikut pendekatan bertahap .
Pengembang mulai dengan proyek desain sederhana , dan kemudian mulai bekerja pada modul kecil . Bekerja pada modul ini dilakukan dalam sprint mingguan atau bulanan , dan pada akhir setiap sprint , prioritas proyek dievaluasi dan tes dijalankan . Ini sprint memungkinkan untuk bug yang ditemukan , dan umpan balik pelanggan untuk dimasukkan ke dalam desain sebelum sprint berikutnya dijalankan . Proses ini , dengan kurangnya desain awal dan langkah-langkah , sering dikritik karena sifat kolaboratif yang berfokus pada prinsip, bukan proses .
Kapan kita harus menggunakan metodologi Agile ?
1 . Ketika produksi cepat adalah lebih penting daripada kualitas produk .
2 . Ketika klien akan dapat kesempatan lingkup proyek .
3 . Bila tidak ada gambaran yang jelas tentang apa produk akhir akan terlihat seperti .
4 . Bila Anda memiliki pengembang terampil yang mudah beradaptasi dan mampu berpikir secara mandiri .
5 . Ketika produk ini ditujukan untuk industri dengan cepat berubah standar .
Keuntungan Metodologi Agile & Waterfall:| Waterfall | Agile |
| Metodologi waterfall menekankan catatan tetap teliti . Memiliki catatan tersebut memungkinkan untuk kemampuan untuk memperbaiki program yang ada di masa depan . | Metodologi Agile memungkinkan untuk perubahan yang akan dilakukan setelah perencanaan awal . Re - menulis ke program , sebagai klien memutuskan untuk membuat perubahan , diharapkan . |
| Dengan metodologi waterfall , klien tahu apa yang diharapkan . Mereka akan memiliki gagasan tentang ukuran , biaya , dan jadwal untuk proyek . Mereka akan memiliki ide yang pasti tentang apa program mereka akan dilakukan di akhir. | Karena metodologi Agile memungkinkan Anda untuk membuat perubahan , lebih mudah untuk menambahkan fitur yang akan membuat Anda tetap up to date dengan perkembangan terbaru dalam industri Anda . |
| Dalam kasus perputaran karyawan , dokumentasi kuat air terjun memungkinkan untuk dampak proyek minimal. | Pada akhir setiap sprint , prioritas proyek dievaluasi . Hal ini memungkinkan klien untuk menambah umpan balik mereka sehingga mereka akhirnya mendapatkan produk yang mereka inginkan . |
| Bisa diprediksi | Pengujian pada akhir setiap sprint memastikan bahwa bug ditangkap dan diurus dalam siklus pengembangan . Mereka tidak akan ditemukan di akhir . |
Kerugian Metodologi Agile & Waterfall:
| Waterfall | Agile |
| Setelah langkah telah selesai , pengembang tidak bisa kembali ke tahap sebelumnya dan membuat perubahan . | Dengan manajer proyek yang kurang berhasil , proyek ini dapat menjadi serangkaian kode sprint . Jika ini terjadi, proyek ini kemungkinan akan datang dalam anggaran terlambat dan berakhir. |
| Metodologi waterfall sangat bergantung pada persyaratan awal . Namun, jika persyaratan ini rusak dengan cara apapun , proyek ini hancur. | Sebagai proyek awal tidak memiliki rencana definitif , produk akhir bisa terlalu berbeda dari apa yang awalnya dimaksudkan . |
| Jika kesalahan persyaratan ditemukan , atau perubahan perlu dibuat , proyek ini harus dimulai dari awal dengan semua kode baru . |
-
|
| Seluruh produk hanya diuji di akhir. Jika bug ditulis lebih awal , tetapi menemukan terlambat, keberadaan mereka mungkin telah mempengaruhi bagaimana kode lain ditulis . Selain itu , godaan untuk menunda pengujian menyeluruh sering sangat tinggi, karena penundaan ini memungkinkan kemenangan-kemenangan jangka pendek tinggal di - jadwal . |
-
|
| Rencananya tidak memperhitungkan berkembang kebutuhan klien . Jika klien menyadari bahwa mereka membutuhkan lebih dari yang mereka pikir , dan menuntut perubahan , proyek akan datang dalam anggaran akhir dan dampaknya . |
-
|
Tapi, tetap perlu ada dokumentasi yang menjelaskan user untuk menggunakan dan berpotensi untuk dijual. Yang umum berupa Web-based documentation bisa berupa instruksi manual yang menjelaskan bagaimana cara menggunakannya. Ketika dikembangkan oleh tim yang dipecah dari beberapa negara-negara yang berbeda dengan menggunakan Agile, bisa langsung bertemu dengan klien.
Kontrak harus menyebutkan dokumentasi yang akan diproduksi tim pembuat kontrak, anggotanya serta dokumentasinya. Dokumentasi kemungkinan juga membutuhkan untuk software yang jangka hidupnya panjang. Dokumen tidak perlu detil, paling tidak logikanya mampu dibuat keputusan. Jika saat butuh sistem lain untuk kita, dan kita harus mengetahui sistem lain tersebut. Jika terjadi perubahan dari sistem yang dibuat jelas bisa dapat diketahui dan dapat diperbaiki dengan cepat.
Jika awal kejadian mengetahui kesalahannya, pada saat analisis kebanyakan dikerjakan dengan benar. Akibatnya desainnya berbeda dengan permintaan dari klien. Jika kesalahan dapat dikerjakan maka bisa dikerjakan dengan mudah.
Sumber Pustaka:
http://www.uio.no/studier/emner/matnat/ifi/INF5730/h04/undervisningsmateriale/ProcessDocumentation.ppt
http://www.writingassist.com/newsroom/proper-software-documentation-in-seven-steps-or-less/
http://www.base36.com/2012/12/agile-waterfall-methodologies-a-side-by-side-comparison/
Thanks to Google Translate.
By: Azid Malil'ula Wildan M (10410110014)-S1 Komputerisasi Akuntansi
