Keuntungan Membangun Software Menggunakan Prototipe

Apakah prototipe itu? Prototipe adalah pendekatan ke desain sistem yang mengembangkan model kerja yang disederhanakan dari sistem. Prototipe, atau rancngan awal ini, dapat dengan cepat dan murah untuk dibangun dan diberikan pada para pemakai atau diuji.

Keuntungan dari prototipe

• Menghasilkan syarat yang lebih baik dari produksi yang dihasilkan oleh metode ‘spesifikasi tulisan’.
• User dapat mempertimbangkan sedikit perubahan selama masih bentuk prototipe.
• Memberikan hasil yang lebih akurat dari pada perkiraan sebelumnya, karena fungsi yang diinginkan dan kerumitannya sudah dapat diketahui dengan baik.
• User merasa puas. Pertama, user dapat mengenal melalui komputer. Dengan melakukan prototipe (dengan analisis yang sudah ada), user belajar mengenai komputer dan aplikasi yang akan dibuatkan untuknya. Kedua, user terlibat langsung dari awal dan memotivasi semangat untuk mendukung analisis selama proyek berlangsung.

Langkah-langkah pembuatan prototipe :

1. Langkah Pertama
Permintaan bermula dari kebutuhan user.
2. Langkah Kedua
Bangunlah sistem prototipe untuk menemukan kebutuhan awal yang diminta.
3. Langkah Ketiga

Biarkan user menggunakan prototipe. Analis harus memberikan pelatihan, membantu dan duduk bersama-sama dengan user, khususnya untuk pertama kali. Anjurkan perubahan. User harus melihat fungsi-fungsi dan sifat dari prototipe, lihat bagaimana ia memecahkan masalah bisnis dan mengusulkan perbaikan.

4. Langkah Keempat

Implementasikan saran-saran perubahan.

5. Langkah Kelima

Ulangi langkah ketiga sampai user merasa puas.

6. Langkah Keenam

Merancang dan membangun suatu sistem akhir seperti sebelumnya.

sumber : liapsa.staff.gunadarma.ac.id

Teknik Estimasi

Estimasi merupakan sebuah proses pengulangan. Pemanggilan ulang estimasi yang pertama dilakukan selama fase definisi, yaitu ketika anda menulis rencana pendahuluan proyek. Hal ini perlu dilakukan, karena anda membutuhkan estimasi untuk proposal. Setelah fase analisis direncanakan ulang, anda harus memeriksa estimasi dan merubah rencana pendahuluan proyek menjadi rencana akhir proyek.

TEKNIK–TEKNIK ESTIMASI

Ada tiga teknik yang digunakan untuk melakukan estimasi, yaitu :

1. Keputusan Profesional

Katakanlah bahwa anda merupakan orang yang memiliki pengalaman yang luas dalam membuat program “report generation modules”. Anda melakukannya dengan pendekatan merancang report tersebut dan memperkirakan berapa lama waktu yang dibutuhkan untuk membuat program tersebut. Setelah mempelajari rancangan program selama 5 menit, programmer lalu menutup matanya selama 5 menit (dia tidak tidur, tetapi berhitung), dan kemudian mengatakan “15 hari”. Inilah yang disebut Keputusan Profesional murni.

Keuntungan dari teknik ini adalah cepat , dan jika seseorang sudah ahli dalam teknik ini, maka estimasinya pasti akan lebih akurat. Sedangkan kerugian dari teknik ini adalah bahwa anda membutuhkan seorang ahli yang berpengalaman dalam bidang ini, dan beberapa ahli tersebut akan bekerja keras untuk mendapatkan estimasi yang tepat.

 

2. Sejarah

Jalan keluar dari ketergantungan pada orang dan untuk membuat estimasi lebih khusus, yaitu anda harus mengerti tentang sejarahnya. Tulislah berapa lama masing-masing tugas dapat diselesaikan dan siapa yang bertanggung jawab atas tugas tersebut.

Anda dapat membandingkan tuagas yang akan diestimasik dengan tugas yang sama yang dikerjakan lebih awal, setelah itu mulailah dengan melakukan estimasi. Hal ini dimaksudkan agar anda menjabarkan suatu proyek ke dalam beberapa tugas yang biasanya diulang dan mudah untuk dibandingkan.

 

3. Rumus-rumus

Ada beberapa rumus yang digunakan dalam software estimasi. Software yang baik untuk diketahui adalah COCOMO (Referensi 15). COCOMO dapat digunakan untuk memperkirakan biaya proyek, usaha (person months), jadwal, dan jumlah staf untuk masing-masing fase berikut ini :

Preliminary Design – our Analysis Phase

Detailed Design (DD) – our Design Phase

Code and Unit Tes (CUT)  - same as ours

System Test – our System Test and Acceptance Phase

sumber : http://liapsa.staff.gunadarma.ac.id/

STANDAR PROFESI DI EROPA

Standar Praktek dikembangkan oleh COTEC yang dirancang untuk membantu Asosiasi Nasional untuk membangun dan mengembangkan kode nasional sesuai dengan standar Eropa praktek untuk terapis okupasi. Hal ini dimaksudkan untuk penerapan umum namun dapat dimodifikasi untuk daerah spesialis misalnya pediatri praktek, kepedulian masyarakat, dll. Jika ada kelompok seperti ingin melakukan ini, setiap dealth masalah dalam Standar Praktek harus diberikan dan bijaksana dalam mempertimbangkan informasi karena mereka telah disertakan untuk relevansi mereka untuk satu atau kegiatan lain dari praktek profesional. Sangat penting bahwa isu-isu yang termasuk dalam Standar Praktek harus saat ini dan relevan dengan anggota profesi yang menggunakan atau untuk yang menggunakannya dimaksudkan.

Standar COTEC Praktek adalah pernyataan kebijakan yang membantu untuk mengatur dan menjaga standar praktek profesional yang baik. Dalam kasus dimana keputusan harus dibuat mengenai perilaku tidak profesional dari seorang ahli terapi kerja, Kode dapat digunakan sebagai panduan untuk standar perilaku profesional yang tepat.

Wakil untuk COTEC diminta untuk memastikan bahwa, ketika kode sedang diterjemahkan ke dalam bahasa Eropa lainnya, hal itu dilakukan sehingga oleh penutur asli. Hal ini dianjurkan karena memiliki frase dan istilah yang kadang-kadang sulit diterjemahkan.
Ada dua bagian utama dalam dokumen ini:

- Kode Etik Federasi Dunia Kerja Therapist
- Standar Praktek dirancang oleh COTEC pada tahun 1991 dan sekarang diperbaharui pada tahun 1996.

Disusun bersama dengan perwakilan dari Asosiasi Nasional oleh Kode Etik dan Standar Praktek Komite Dokumen Maria McGuinn (Ketua & Sekretaris) Judith Marti dan Dirk de Vylder.

Kode Etik
Kode Etik Federasi Dunia Kerja Therapist menggambarkan perilaku yang tepat terapis okupasi berlatih di semua bidang terapi pekerjaan. Karena semua Asosiasi Nasional Terapi Pekerjaan di Eropa adalah anggota atau anggota Associate WFOT maka dipandang tepat yang harus COTEC basis Standar Praktek pada kode ini.

Pribadi atribut
Pekerjaan terapis memiliki integritas pribadi, kehandalan, pikiran yang terbuka dan loyalitas berkaitan dengan konsumen dan bidang profesional keseluruhan.

Tanggung jawab terhadap penerima Occupational Layanan Terapi
Pekerjaan terapis pendekatan semua konsumen dengan hormat dan dengan memperhatikan untuk situasi masing-masing. Pekerjaan terapis akan tidak diskriminasi terhadap konsumen berdasarkan ras, warna kulit, cacat, cacat, asal-usul kebangsaan, umur, jenis kelamin, preferensi seksual, agama, keyakinan politik atau status dalam masyarakat. pribadi preferensi konsumen dan kemampuan untuk berpartisipasi akan diperhitungkan dalam perencanaan penyediaan layanan. Kerahasiaan informasi pribadi’s konsumen dijamin dan setiap rincian pribadi disampaikan hanya dengan persetujuan mereka.

Perilaku dalam tim Terapi Pekerjaan dan dalam tim multidisiplin
Pekerjaan terapis bekerja sama dan menerima tanggung jawab dalam satu tim dengan mendukung tujuan medis dan psikososial yang telah ditetapkan. terapis Kerja menyediakan laporan tentang kemajuan intervensi mereka dan memberikan anggota lain dari tim dengan informasi yang relevan.

Mengembangkan pengetahuan profesional
Pekerjaan terapis berpartisipasi dalam pengembangan profesional melalui belajar sepanjang hidup dan selanjutnya menerapkan diperoleh pengetahuan dan keterampilan dalam kerja profesional mereka.

Promosi profesi
Pekerjaan terapis berkomitmen untuk perbaikan dan pengembangan profesi pada umumnya. Mereka juga prihatin dengan mempromosikan terapi okupasi yang lain masyarakat organisasi profesional, dan mengatur badan-badan di, nasional dan internasional tingkat regional.
World Federation of Occupational Therapist: Komite Praktek Profesional; Maret 1990.

Konsumen
Untuk tujuan Standar COTEC Praktek konsumen istilah digunakan untuk menjelaskan pasien, klien dan / atau wali. Hal ini juga termasuk mereka yang terapis kerja bertanggung jawab.

referensi: http://www.cotec-europe.org/eng/35/

STANDAR PROFESI DI USA DAN KANADA

Pejabat Keuangan Pemerintah Asosiasi dari Amerika Serikat dan Kanada adalah organisasi profesional pejabat publik bersatu untuk meningkatkan dan mempromosikan manajemen profesional sumber daya keuangan pemerintah dengan mengidentifikasi, mengembangkan dan memajukan strategi fiskal, kebijakan, dan praktek untuk kepentingan publik.

Untuk lebih tujuan tersebut, aparat pemerintah membiayai semua diperintahkan untuk mematuhi standar hukum, moral, dan profesional perilaku dalam pemenuhan tanggung jawab profesional mereka. Standar perilaku profesional sebagaimana diatur dalam kode ini diwujudkan dalam rangka meningkatkan kinerja semua orang yang terlibat dalam keuangan publik.

I. Pribadi Standar

petugas pembiayaan Pemerintah harus menunjukkan dan didedikasikan untuk cita-cita tertinggi kehormatan dan integritas dalam semua hubungan masyarakat dan pribadi untuk mendapat rasa hormat, kepercayaan, dan keyakinan yang mengatur pejabat, pejabat publik lainnya, karyawan, dan masyarakat.
• Mereka harus mencurahkan waktu, keterampilan, dan energi ke kantor mereka baik secara independen dan bekerja sama dengan profesional lainnya.
• Mereka harus mematuhi praktek profesional disetujui dan standar yang dianjurkan.

II. Tanggung jawab sebagai Pejabat Publik

petugas pembiayaan Pemerintah harus mengakui dan bertanggung jawab atas tanggung jawab mereka sebagai pejabat di sektor publik.
• Mereka harus sensitif dan responsif terhadap hak-hak publik dan kebutuhan-kebutuhannya berubah.
• Mereka harus berusaha untuk memberikan kualitas kinerja tertinggi dan nasihat.
• Mereka akan bersikap bijaksana dan integritas dalam pengelolaan dana dalam tahanan mereka dan dalam semua transaksi keuangan.
• Mereka harus menjunjung tinggi baik surat dan semangat undang-undang, konstitusi, dan peraturan yang mengatur tindakan mereka dan melaporkan pelanggaran hukum kepada pihak yang berwenang.

III. Pengembangan Profesional

petugas pembiayaan Pemerintah bertanggung jawab untuk menjaga kompetensi mereka sendiri, untuk meningkatkan kompetensi kolega mereka, dan untuk memberikan dorongan untuk mereka yang ingin memasuki bidang keuangan pemerintah. petugas Keuangan harus meningkatkan keunggulan dalam pelayanan publik.

IV. Integritas Profesional – Informasi

petugas pembiayaan Pemerintah harus menunjukkan integritas profesional dalam penerbitan dan pengelolaan informasi.
• Mereka tidak akan sadar tanda, berlangganan, atau mengizinkan penerbitan pernyataan atau laporan yang berisi salah saji atau yang menghilangkan fakta material apapun.
• Mereka harus menyiapkan dan menyajikan laporan dan informasi keuangan sesuai dengan hukum yang berlaku dan praktek yang berlaku umum dan pedoman.
• Mereka harus menghormati dan melindungi informasi rahasia yang mereka memiliki akses berdasarkan kantor mereka.
• Mereka harus sensitif dan responsif terhadap pertanyaan dari masyarakat dan media, dalam kerangka kebijakan pemerintah negara bagian atau lokal.

V. Integritas Profesional – Hubungan

petugas pembiayaan Pemerintah harus bertindak dengan kehormatan, integritas, dan kebajikan dalam semua hubungan profesional.
• Mereka harus menunjukkan kesetiaan dan kepercayaan dalam urusan dan kepentingan pemerintah yang mereka layani, dalam batas-batas Kode Etik ini.
• Mereka tidak akan sadar menjadi pihak atau membiarkan aktivitas ilegal atau tidak layak.
• Mereka harus menghormati hak, tanggung jawab, dan integritas dari rekan-rekan mereka dan pejabat publik lainnya dengan siapa mereka bekerja dan asosiasi.
• Mereka harus mengatur semua hal personil dalam lingkup kewenangan mereka sehingga keadilan dan ketidakberpihakan mengatur keputusan mereka.
• Mereka akan mempromosikan kesempatan kerja yang sama, dan dengan berbuat demikian, menentang diskriminasi, pelecehan, atau praktik yang tidak adil lainnya.

VI. Konflik Kepentingan

petugas pembiayaan Pemerintah harus secara aktif menghindari munculnya atau kenyataan benturan kepentingan.
• Mereka harus melaksanakan tugas mereka tanpa bantuan dan harus menahan diri dari terlibat dalam hal-hal di luar kepentingan keuangan atau pribadi yang tidak sesuai dengan kinerja tidak memihak dan tujuan tugas mereka.
• Mereka tidak akan, secara langsung atau tidak langsung, mencari atau menerima keuntungan pribadi yang akan mempengaruhi, atau tampaknya mempengaruhi, pelaksanaan tugas resmi mereka.
• Mereka tidak akan menggunakan milik umum atau sumber daya untuk keuntungan pribadi atau politik.

Referensi : http://www.gfoa.org/index.php?option=com_content&task=view&id=98&Itemid=108

STANDAR PROFESI DI INDONESIA DAN REGIONAL

Institusi pemerintah telah mulai melakukan klasifikasi pekerjaan dalam bidang teknologi informasi ini. Klasifikasi pekerjaan ini telah diterapkan sejak 1992. Bagaimanapun juga, klasifikasi pekerjaan ini masih belum dapat mengakomodasi klasifikasi pekerjaan pada teknologi informasi. Terlebih lagi, deskripsi pekerjaan setiap klasifikasi pekerjaan masih tidak jelas dalam membedakan setiap sel pekerjaan.

Beberapa perusahaan yang dimiliki oleh pemerintah mempunyai klasifikasi pekerjaannya sendiri. Begitu juga dengan beberapa perusahaan swasta yang besar, telah mengembangkan klasifikasi pekerjaan mereka sendiri juga. Belum adanya standardisasi klasifikasi pekerjaan ini terkadang menimbulkan kesulitan bagi para profesional TI.

Departemen Tenaga Kerja berkeinginan untuk mengeluarkan standard kompetensi untuk teknologi informasi. IPKIN diharapkan memberikan sumbangan untuk formulasi standard kompetensi pada Teknologi Informasi. Dengan mengacu ke model regional (model SRIG-PS), standard kompetensi yang akan diterapkan di Indonesia akan mudah dapat diterima dan disetarakan di negara-negara lain di region ini. Bagaimanapun juga, suatu persetujuan bilateral harus dicapai antara Pemerintah kedua negara.

Klasifikasi Pekerjaan TI pada Institusi Pemerintah

Sejak tahun 1991, ada sekitar lebih dari 400 profesional pada Teknologi Informasi yang bekerja pada institusi pemerintah. Pemerintah Indonesia telah menspesifikasi klasifikasi pekerjaan untuk teknologi informasi, untuk tingkat programmer dan tingkat sistem analis. Tingkat-tingkat ini lebih tinggi dari tingkat operator. Klasifikasi ini diterapkan untuk memberikan skema pengembangan profesi yang berkesinambungan.

Sumber : http://openstorage.gunadarma.ac.id/~mwiryana/IPKIN/SRIG-PS/st_page2.html

STANDAR PROFESI ACM DAN IEEE

ACM(Association for Computing Machinery) atau Asosiasi untuk Permesinan Komputer adalah sebuah serikat ilmiah dan pendidikan komputer pertama di dunia yang didirikan pada tahun 1947.
SIG dan ACM, mensponsori konferensi yang bertujuan untuk memperkenalkan inovasi baru dalam bidang tertentu. Tidak hanya mensponsori konferensi ,ACM juga pernah mensponsori pertandingan catur antara Garry Kasparov dan computer IBM DeepBlue.

ACM telah menciptakan sebuah perpustakaan digital dimana ia telah membuat seluruh publikasi yang tersedia .ACM perpustakaan digital merupakan koleksi terbesar didunia informasi mengenai mesin komputasi dan berisi arsip jurnal ,majalah ,prosiding konferensi online,danisu-isu terkini ACM publikasi.

IEEE(Institute of Electrical and Electronics Engineers) adalah sebuah organisasi profesi nirlaba yang terdiri dari banyak ahli dibidang teknik yang mempromosikan pengembangan standar-standar dan bertindak sebagai pihak yang mempercepat teknologi baru dalam semua aspek dalam industry dan rekayasa (engineering),yang mencakup telekomunikasi,jaringankomputer,kelistrikan, antariksa, danelektronika.
•Tujuan inti IEEE adalah mendorong inovasi teknologi dan kesempurnaan untuk kepentingan kemanusiaan.
•Visi IEEE adalah akan menjadi penting untuk masyarakat teknis global dan professional teknis dimana-mana dan dikenal secara universal untuk kontribusi teknologi dan teknis yang professional dalam meningkatkan kondisi perkembangan global.
•Proses pembangunan IEEE standar dapat dipecah melalui tujuh langkah dasar yaitu:
1.Mengamankan Sponsor,
2.Meminta Otorisasi Proyek,
3.Perakitan Kelompok Kerja,
4.Penyusunan Standard,
5.Pemungutan suara,
6.Review Komite,
7.Final Vote.

•Perbedaan antara ACM dan IEEE adalah, ACM berfokus pada ilmu komputer teoritis dan aplikasi pengguna akhir, sementara IEEE lebih memfokuskan pada masalah-masalah hardware dan standardisasi. Cara lain untuk menyatakan perbedaan yaitu ACM adalah ilmuwan komputer dan IEEE adalah untuk insinyur listrik, meskipun subkelompok terbesar adalah IEEE Computer Society.
•ACM memiliki empat “Boards“ yaitu:
1.publikasi,
2.SIG Governing Board,
3.pendidikan, dan
4.Badan Layanan Keanggotaan

LANGKAH - LANGKAH PEMROGRAMAN

Langkah 1. Rencana Penggabungan (Plan The Integration)
Membuat program memerlukan rangkaian langkah demi langkah. Merencanakan urutan dimana anda akan menggabungkan bagian-bagian program. Pada Bagian ini merinci beberapa metode untuk menggabungkan bagian-bagian tersebut, tetapi anda harus merencanakan urutan penggabungan ini sekarang, karena anda harus menulis program supaya dapat digabungkan. Ini disebut Rencana Tes Sistem (System Test Plan).

Langkah 2. Mendisain Modul (Design The Module)
Programmer menerima beberapa tingkatan desain dari fase desain. Tugasnya adalah memecah modul secara rinci ke tingkat yang lebih rendah sampai mencapai keadaan programmer siap untuk melakukan pemrograman. Ini disebut desain modul.

Langkah 3. Telusuri Disain Modul (Walk Through The Module Design)
Seperti pada tingkat atas dan menengah dari desain, pertukaran harus dibuat sebaiknya pada tingkat yang paling rendah. Telusuri desain dari masing-masing modul sebelum melakukan pengkodean. Penelusuran ini sangat kecil, hanya programmer yang tepat, supervisor dan mungkin programmer lainnya yang perlu diperhatikan. Kegunaan dari penelusuran disain modul adalah untuk memastikan bahwa disain yang terbaik yang telah dilakukan, semua fungsi telah dialamatkan dan semua bagian telah ditangani.

Langkah 4. Rencana Bagaimana Menguji Modul (Plan How To Test The Module)
Programmer harus menyiapkan rencana pengujian modul dan data pengujian sebelum dikodekan. Rencana pengujian dilakukan setelah kode ditetapkan. Mereka cenderung hanya menguji bagian kode yang paling ‘sulit’. Pimpinan proyek bisa saja melakukan tuntutan pada penelusuran rencana pengujian sepanjang disain modul sedang dilaksanakan. Kerjakan penelusuran ini bersama-sama.

Langkah 5. Kode Setiap Modul (Code Each Module)
Berikut ini adalah ringkasan dari sebuah program terstruktur, yaitu :
- Jika berukuran kecil. Aturan dasarnya adalah kira-kira 100 baris kode yang dapat dieksekusi dan listingnya tidak lebih dari 2 halaman.
- Satu entry, satu exit.
- Referensi secara keseluruhan sedikit.
- Konstruksi terstruktur yang digunakan : berurutan, IF/THEN/ELSE, CASE, WHILE, UNTIL, CALL (bukan GO TO).

Langkah 6. Menguji Modul (Test The Module)
Programmer menguji modul dengan menetapkan lingkungan yang tepat, menyediakan beberapa input, membiarkan modul langsung memproses secara logik dan mendapatkan hasilnya. Beberapa input mungkin tidak sebenarnya, terutama jika modul tersebut tidak menyediakan input yang sebenarnya.
Modul seharusnya diuji dalam dua tahap, yaitu :
· Tahap Pertama disebut pengujian “White Box”. Programmer harus mengetahui isi di dalam modul dan menyediakan data pengujian, sehingga masing-masing path logical dalam program dapat dieksekusi.
· Tahap Kedua atau pengujian “Black Box” dapat dilakukan. Dalam pengujian ini, programmer mengabaikan bagian dalam dari modul – data disediakan secara berurut dan dianggap seperti pemakaian sebenarnya.

Langkah 7. Menguji Level Terendah dari Integrasi (Test The Lowest Levels Of Integration)
Jika modul utama memanggil sub-modul, programmer harus menggabungkan dan menguji semua modul secara bersama-sama. Bahkan jika programmer tidak bertanggung jawab untuk menulis sub-modul, programmer harus menguji perintah CALL dan RETURN dari seluruh modul.
Metode terbaik untuk melakukan hal ini adalah membuat sebuah “program stub” (potongan program) sebagai pengganti sub-modul. Potongan program ini dapat terdiri dari empat baris program yang menunjukkan bahwa kontrol sudah diterima dengan baik, tampilkan parameter penerima, jika perlu lakukan pengontrolan kembali dengan beberapa parameter yang tidak sebenarnya.

Langkah 8. Menyimpan Semua Hasil Pengujian; Penggabungan Modul-modul Yang Telah Diuji (Save The Results Of All Tests; Submit Finished Modules To Integration)
Hasil pengujian digunakan untuk menyusun statistik yang menunjukkan penyebab, cara perbaikan serta biaya-biaya yang dibutuhkan untuk memperbaiki kesalahan-kesalahan program. Pimpinan proyek biasanya menguasai/mengepalai penggabungan ini pada sistem berukuran kecil sampai sedang.
Software seperti CMS (Code Management System) sangat berguna untuk menajemen konfigurasi, menjamin program tetap berjalan sesuai versinya dan mengubah ke source code.

Langkah 9. Memulai Dokumentasi User (Get Started On The User Documentation)
Apakah programmer bertanggung jawab pada dokumentasi user atau tidak, tahapan ini adalah waktu terbaik untuk menjawabnya. Dokumen-dokumen berikut mungkin harus ditulis :
- Tuntunan Pemakai (User’s Guide)
Dokumen ini dapat ditulis oleh programmer, penulis teknis atau bahkan user sendiri. Tampilkan kembali FS yang mempunyai bagian rinci mengenai menu, layar, form, dan user interface lainnya.
USER’S GUIDE yang baik adalah terbagi dalam bagian-bagian yang menunjukkan tingkatan user yang berbeda-beda. Sebagai contoh, dalam USER’S GUIDE sistem ABC, harus ada bagian yang disebut “Registrar’s Functions” atau “Warehouse Functions” atau lainnya. Materinya harus disesuaikan agar user dapat menggunakan secara normal. Hal ini membuat USER’S GUIDE berguna untuk mempelajari sistem.
Urutan popular lainnya untuk USER’S GUIDE adalah menelusuri menu-menu perintah secara logika. Pada akhir dari USER’S GUIDE ini disediakan referensi dari setiap perintah, menu, form dan pesan yang ditampilkan secara alphabet.
- Tuntunan Pemeliharaan (Maintenance Guide).
Bagaimana anda menemukan programmer untuk merinci dokumen dari program mereka untuk pemeliharaan berikutnya ? Kebanyakan Manajer proyek mengalami kesulitan dalam hal berikut : programmer enggan untuk melakukan dokumentasi sebelum program ditulis; dan beruntunglah menemukannya setelah semuanya selesai dikerjakan. Programmer berpikir bahwa pemeliharaan memerlukan penjelasan secara rinci dari logika pemrograman. Sangat membosankan untuk menulisnya dan sebenarnya tidak perlu.
Berikut ini adalah solusi sederhana tentang hal tersebut : lebih baik merinci spesifikasi disain tingkat modul secara struktur, mendokumentasikan sendiri kode, dirasa cukup untuk pemeliharaan sistem.