Catatan Materi Kuliah TDA pert 5http://www.literateprogramming.com/documentation.pdf
http://www.techscribe.co.uk/ta/how-to-write-user-documentation.htm
Thanks to Google Translate
Product documentation
-Menjelaskan produk yang disampaikan dan harus berkembang dengan pengembangan produk perangkat lunak.
- Menjelaskan mengenai bentuk bukunya, bentuk bukunya berupa:
1. Buku panduan pengenalan
2. Buku panduan pelatihan
3. Buku panduan pengguna
4. Buku panduan referensi
5. Buku panduan struktur database, dsb.
- Ada hubungannya dengan cara menyampaikan produknya dan mempunyai umur panjang
- Ada kategori: user documentation, user manual
- Sistem dokumentasi: Semua prinsip dari proses dokumentasi. Menjelaskan bagaimana sistem bekerja, tetapi bukan cara mengoperasikannya.
Contoh: Persyaratan Spesifikasi, Desain Arsitektur, Rancangan rinci, Komentar Source Code, Termasuk keluaran seperti javadoc, Test Plan, Termasuk test case, V & V rencana dan hasil, Daftar bugs yang dikenal
- User dokumentasi: harus bisa membuat dokumentasi untuk memudahkan tugas dari user yang berbeda-beda dan dilihat dari pengalaman dan pengetahuan
- End-user: tidak membutuhkan proses pembuatan software tapi membutuhkan software tersebut untuk membantu tugasnya
- Sistem Administrator: bertanggjung jawab mengelola dan mengetahui permintaan dan pemetaan sistem software yang digunakan end-user.
Jenis-jenis dari user:
a. Manager & sistem evaluator
b. System administrator
c. Novice users
d. Experienced users
e. System Administrators
-Ada lima bidang penting yang harus didokumentasikan untuk rilis resmi dari aplikasi perangkat lunak. Ini tidak selalu masing-masing harus memiliki dokumen mereka sendiri, tetapi topik harus ditutup secara menyeluruh.
1. Deskripsi Fungsional perangkat lunak:
-Secara garis besar mengenai kebutuhan dan sedikit tentang servis yang disediakan
-Membutuhkan tentang penjelasan sistem
-User harus bisa membaca dokumen dan menentukan sistem yang akan dibutuhkan dan dibuat
2. Sistem/Instruksi instalasi: dibutuhkan oleh sistem administrator untuk menyediakan informasi mendetail bagaimana cara menginstall sistem di lingkungan sistem yang spesifik dan mencantumkan gambaran file-file apa yang membentuk suatu sistem/aplikasi
3. Introduction manual:
-Lebih ke penggunaan normalnya
-Menjelaskan bagaimana memulai software dan bagaimana pengguna menggunakan sistem fasilitas pada umumnya
4. Sistem referensi:
-Menjelaskan semua kegunaan dan fungsi yang dimiliki sistem/aplikasi
-Tersedia daftar error message-nya dan menjelaskan bagaimana memulihkan error
-Sistem harus komplit
-Teknik formal deskriptif seharusnya digunakan
5. Sistem dokumentasi: mencakup semua gambaran sistem itu sendiri mulai dari spesifikasi kebutuhan hingga hasil pengetesan yang dapat diterima termasuk dokumen requirement plan, yang harus ada:
a. Requirement: Kebutuhan pengguna dan perangkat lunak
b. Dokumentasi yang menjelaskan desain arsitektur
c. Deskripsi arsitektur
d. Deskripsi fungsional dan antarmuka
e. Source code, dengan penamaan yang standar yang dicetak harus sesuai fungsinya. Ex: source code dari transaksi
f. Dokumen validasi menjelaskan bagaimana setiap program berjalan.
Sumber Pustaka:
Catatan Materi Kuliah TDA pert 4
http://www.eecs.ucf.edu/~turgut/COURSES/EEL6883_SEII_Spr07/PaperPresentations/Sommerville-p143.ppt
http://www.literateprogramming.com/documentation.pdf
-Thanks to Google Translate-
By: Azid Malil'ula Wildan M (10410110014)-S1 Komputerisasi Akuntansi
Dokumentasi Proses
Kategori dokumen. Kebutuhan Dokumen:
A. Persyaratan umum semua dokumentasi perangkat lunak
· Harus menyediakan komunikasi antara anggota tim
· Harus bertindak sebagai penyimpanan informasi yang akan digunakan oleh teknisi pemeliharaan
· Harus menyediakan informasi yang cukup untuk manajemen untuk memungkinkan mereka untuk melakukan semua kegiatan pengelolaan program yang terkait
· Harus menjelaskan kepada pengguna bagaimana untuk mengoperasikan dan mengelola sistem
-Dalam semua proyek perangkat lunak beberapa jumlah dokumentasi harus dibuat sebelum kode yang ditulis. Ex: Rancangan dokumen, dll
-Dokumentasi harus dilanjutkan setelah kode telah selesai. Ex: Manual pengguna, dll
-Dua jenis utama dari dokumentasi dibuat adalah Proses dan Produk dokumen.
-Kualitas Dokumen: Menyediakan dokumentasi menyeluruh dan profesional adalah penting untuk setiap ukuran tim pengembangan produk. Masalahnya adalah bahwa banyak perangkat lunak profesional tidak memiliki keterampilan menulis untuk membuat dokumen tingkat profesional
Proses Dokumentasi:
-Proses dokumentasi akan menghasilkan software artifak. Software artifak yaitu segala sesuatu dari software (model/deskripsi) yang dikembangkan dan dipakai selama pengembangan dan pemeliharaan software.
- Contoh spesifikasi requirement, arsitektur, dan desain model. Dokumentasi ini dibuat untuk memungkinkan adanya keberhasilan pengelolaan produk perangkat lunak. Dibagi menjadi 5 kategori:
1. Perencanaan, estimasi, penjadwalan: diproduksi oleh para manajer yang digunakan untuk memproduksi dan mengontrol proses software-nya. Di buku lain disebutkan ada project management documents, perencanaan proyek, jadwal proyek, dan model laporan yang lain, ex: laporan rapat
2. Laporan: bagaimana sumberdaya digunakan selama proses pengembangan, seperti laporan project regular
3. Standar: Standar memainkan peran penting dalam pengembangan, pemeliharaan dan kegunaan dokumentasi. Standar dapat bertindak sebagai dasar untuk dokumentasinya berkualitas. Tetapi tidak cukup baik pada mereka sendiri. Biasanya menetapkan konten tingkat tinggi dan organisasi. contohnya seperti: CSC, IEEE / EIA 12207 0-1996, software life circle, IEEE / EIA 12207 1-1997, life circle data, IEEE / EIA 12207 2-1997, implementation consideration
4. Kertas kerja: seringkali dari teknik prinsip komunikasi dokumen dari proyek, seperti: coret-coretan kerja. Yang merekam ide dan pemikiran pekerjaan engineer dalam suatu pengerjaan proyek. Berupa detil desain yang berisi analisis dan metodologi desain, yang berupa workflow.
5. Komunikasi: merupakan detil komunikasi tiap hari antara manajer dan karyawan dari teknik pengembang.
Karakteristik:
-Memiliki umur yang relatif pendek
-Hanya penting untuk proses pengembangan internal. Kecuali dalam kasus di mana pelanggan membutuhkan pandangan ke data.
-Beberapa item, seperti kertas yang menggambarkan keputusan desain harus digali dan dipindahkan ke dalam kategori dokumentasi produk ketika mereka menjadi diimplementasikan
-Karakteristik yang umum dari dokumentasi adalah pasti akan kadaluarsa .
-Perencanaan biasanya dibuat secara mingguan / bulanan. Laporan progress-nya juga dilaporkan
-Software historian sedikit sekali penggunaannya yang kadaluarsa dan tidak bisa membuat, menyimpan setelah sistem dihasilkan
-Untuk proyek internal, untuk mengurangi jumlah proses dokumentasi. untuk orang luar, harus dibuatkan dokumentasi yang benar yaitu kontrak antara pelanggan dan pemasok, yang berisi dokumentasi apa saja yang dihasilkan.
- Tim pengembang juga membutuhkan evidence (catatan kecil) sebagai bukti pembuatan software. Dan the regulatory requirements yaitu proses mendapatkan sertifikasi.
Sumber Pustaka:
Catatan Materi Kuliah TDA pert 3
http://www.eecs.ucf.edu/~turgut/COURSES/EEL6883_SEII_Spr07/PaperPresentations/Sommerville-p143.ppt
http://www.literateprogramming.com/documentation.pdf
-Thanks to Google Translate -
By: Azid Malil'ula Wildan M (10410110014)-S1 Komputerisasi Akuntansi
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 . |
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 . |
-
|