Sunday, October 6, 2013

Teknik Dokumentasi Aplikasi -Chapter 5-

Product Documentation (Dokumentasi produk):
-Dapat menjelaskan kebutuhan dokumentasi aplikasi
Indikator:
-Menjelaskan pentingnya tahap investigasi terhadap user
-Menjelaskan macam-macam user
Business Case (Kasus bisnis):
Alasan membuat dokumentasi pengguna adalah sebagai berikut:
-Membantu menjalankan software
-Mengurangi biaya maintenance
-Menjadi alat pemasaran: logo perusahaan, nama brand
-Gambar perusahaan menjadi meningkatkan citra perusahaan
Sebelum Anda mulai membuat dokumentasi, mengidentifikasi alasan untuk membuat dokumentasi. Jika dokumentasinya tidak akan meningkatkan keuntungan, jangan membuat dokumentasi. Jangan membuat dokumentasi untuk menjelaskan produk yang rendah. Sebaliknya, ubahlah desain antarmuka-nya.
Investigasi: kunci untuk mendapatkan hasil yang bagus (menulis dokumentasi pengguna)
Tahapan investigasi dimana ide-ide itu dikembangkan. Jika sudah memilih subyek, harus mengetahui mendalam subyeknya.
Harus memperhatikan pelanggan: dikhususkan bagi siapa yang akan membaca buku panduanmu
Analisis audience: Dokumentasi tidak ada gunanya jika tidak menjawab pertanyaan-pertanyaan yang orang bertanya. Oleh karena itu, sebelum Anda mulai menulis, Anda perlu tahu tentang penonton dan tugas-tugas yang mereka lakukan
-Perhatikan siapa yang akan menggunakan buku manual tersebut dan apa tugas yang dikerjakannya.
Kategori audience dari sisi pekerjaan:
a. Data entry clerk: Petugas entri data, kadang-kadang disebut juru ketik, adalah anggota staf yang dipekerjakan untuk mengetik data ke database menggunakan keyboard, scanner optik, atau perekam data. keyboard sering digunakan dapat memiliki kunci spesialis dan beberapa warna untuk membantu dalam tugas dan mempercepat pekerjaan.
b. Supervisor : Suatu pimpinan dari suatu job desk karyawan
c. Sistem administrator: bertanggung jawab mengelola dan memelihara software yang digunakan oleh end-user. Dapat berupa operator, network manager, hingga master teknis yang memecahkan segala permasalahan end-user berkaitan dengan software, atau juga penghubung antara user dengan software developer.
d. Service desk operator: adalah petugas operator pembantu servis pelanggan dimaksudkan untuk memberikan pelanggan atau pengguna akhir dengan menyediakan informasi dan dukungan terkait dengan perusahaan atau produk dan jasa lembaga.
Metode kategorisasi audience membantu untuk:
-Metode membantu membuat dokumentasi yang bisa diaplikasikan dari kebutuhan tipe pengguna
-Role pekerjaan menunjukkan tingkat kemahiran pengguna.
-Sistem administrator biasanya paling pintar dalam menguasai software tapi terkadang end-user bisa lebih pintar / amatir dari sistem administrator.
Analisis tugas: Berbagai jenis pengguna melakukan tugas-tugas yang berbeda. Tugas adalah seperangkat operasi yang digunakan untuk mencapai suatu tujuan. Suatu prosedur adalah daftar instruksi yang memberitahu seseorang bagaimana melakukan tugas tingkat rendah. Sebuah hirarki tugas ada tingkat terendah yang merupakan serangkaian prosedur.
Mungkin, pada tingkat yang lebih tinggi, lebih dari satu orang melakukan tugas.
-Perbedaan tugas dan prosedure
-Kumpulan dari operasi untuk mencapai tujuan
-Harus mengubah prosedur dari kumpulan instruksi untuk menjelaskan seseorang bagaimana mengerjakan tugas yang mudah
-Hirarki tugas yang ada yaitu level terbawah dari prosedur
Hal yang dilakukan untuk menemukan tugas dan prosedur yang dilakukan orang:
1. Mengetahui prosedur yang dibuat dari seseorang:
-Observasi mengenai pekerjaannya
-Mendapatkan informasi yang sudah ada dan membuat software
-Supaya mengetahui kenyataan yang sebenarnya
-Menulis satu / lebih prosedur untuk setiap orang
2. Menentukan panjang dari bukunya:
-Perhatikan banyak halaman yang akan dituliskan
-Orang akan malas mencari-cari jawaban yang diinginkan
-Orang ingin langsung dapat menemukan jawaban yang dicari
3. Melihat sistem:
-Pahami betul alur kerja sistem
-Pembagian dari sistem tuliskan dengan lengkap
4. Memulai investigasi:
-Investigasi mulai awal kerja sistem sampai dengan akhir kerja sistem
-Kesulitan dan kemudahan proses investigasi
-Sebisa mungkin dilihat dari sisi pengguna bukan pembuat sistem
5. Menentukan judul buku dan tipe buku:
-Judul buku dengan jelas menyebutkan apa isi dari buku tersebut
-Pastikan semua kebutuhan dari user tertulis dalam buku tersebut
6. Jangan membuat kebingungan:
-Jangan membuat pembaca menjadi tambah bingung saat membaca dokumentasi
-Pergunakan kata-kata yang bisa dipahami oleh orang awam, jangan hanya penulis sendiri yang paham
By: Azid Malil'ula Wildan M (10410110014)-S1 Komputerisasi Akuntansi

Teknik Dokumentasi Aplikasi -Chapter 4-

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

Teknik Dokumentasi Aplikasi -Chapter 3-

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

Sunday, September 29, 2013

Teknik Dokumentasi Aplikasi -Chapter 2-

Proses Dokumentasi
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.

clip_image002

Agile vs Waterfall Methodology

clip_image004

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:
Catatan Materi Kuliah TDA pert 2
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

Sunday, September 8, 2013

Teknik Dokumentasi Aplikasi Chapter 1

1. Definisi
A. Dokumentasi
Pengertian dokumentasi secara teknis yaitu: manual, instruksi, tutorial, prosedur, spesifikasi, dll, yang menyertai sebuah peralatan atau perangkat lunak, dan memberikan bimbingan untuk penggunaan yang tepat dan pemeliharaan suatu proyek.
Dokumentasi dapat dianggap sebagai materi yang tertulis atau sesuatu yang menyediakan informasi tentang suatu subyek. Dokumentasi dapat berisi tentang deskripsi-deskripsi, penjelasan-penjelasan, bagan alir, daftar-daftar, cetakan hasil komputer, contoh-contoh obyek dari sistem informasi.
B. Aplikasi / Softtware (Perangkat Lunak)
Menurut Kamus Besar Bahasa Indonesia, Perangkat lunak adalah istilah umum untuk data yang diformat dan disimpan secara digital, termasuk program komputer, dokumentasinya, dan berbagai informasi yang bisa dibaca dan ditulis oleh komputer. Dengan kata lain, bagian sistem komputer yang tidak berwujud. Istilah ini menonjolkan perbedaan dengan perangkat keras komputer.
Jadi, Aplikasi ini adalah Informasi yang diorganisir dalam bentuk sistem operasi, utilitas, program, dan aplikasi yang memungkinkan komputer untuk bekerja.
Software terdiri dari instruksi hati-hati terorganisir dan kode yang ditulis oleh programmer dalam berbagai bahasa komputer khusus. Software dibagi umum menjadi dua kategori utama: (1) Sistem perangkat lunak: mengontrol dasar (dan terlihat oleh pengguna) fungsi komputer dan datang biasanya diinstal dengan mesin. Lihat juga BIOS dan Sistem Operasi. (2) perangkat lunak Aplikasi: menangani banyak sekali umum dan khusus tugas pengguna ingin melakukan, seperti akuntansi, komunikasi, pengolahan data, pengolah kata.
C. Teknik Dokumentasi Aplikasi
Adalah Software dokumentasi atau kode sumber (source code) dokumentasi teks yang menyertai perangkat lunak komputer tertulis. Itu baik menjelaskan bagaimana ia beroperasi atau bagaimana menggunakannya, dan dapat berarti hal yang berbeda untuk orang-orang dalam peran yang berbeda.
Jadi, Teknik Dokumentasi Aplikasi adalah Informasi yang komprehensif tentang kemampuan, detil desain, fitur, dan keterbatasan dari sistem atau perangkat lunak aplikasi. Ini juga termasuk persyaratan lisensi perangkat lunak, dan datang biasanya sebagai dokumen cetak atau sebagai bagian dari perangkat lunak pada disk atau CD. Juga disebut software manual.
D. Analisa/ Pendapat dari para Ahli
Scott Ambler menggambarkan dokumen perangkat lunak sebagai "setiap artefak eksternal ke kode sumber yang tujuannya adalah untuk menyampaikan informasi secara terus-menerus" [1], dan model perangkat lunak sebagai "sebuah abstraksi yang menggambarkan satu atau lebih aspek masalah atau solusi potensial mengatasi masalah "[1].
Ambler menggambarkan hubungan antara model, dokumen dan dokumentasi bawah pada Gambar di bawah ini.
clip_image002[4]
Ambler menggambarkan model sebagai artefak sementara yang mungkin atau tidak mungkin diubah menjadi dokumen permanen dan merupakan bagian dari dokumentasi perangkat lunak.
Kami setuju bahwa beberapa artefak, seperti model perangkat lunak, mungkin memiliki umur relatif sementara terhadap artefak lainnya. Namun, persepsi kami adalah model dan dokumen keduanya hanya subset dari gagasan dokumentasi secara keseluruhan. Dokumen tidak perlu artefak permanen dalam sistem perangkat lunak, juga harus semua model sekali pakai. Dokumentasi adalah sebuah abstraksi pengetahuan tentang sistem perangkat lunak dan hanya selama dokumen atau model (atau artefak lainnya) dapat secara efektif mengkomunikasikan pengetahuan apakah itu merupakan bagian dari dokumentasi perangkat lunak proyek, bahkan jika hanya untuk umur pendek. Bahkan, kami juga mengakui bahwa kode sumber itu sendiri adalah salah satu jenis artefak seperti juga menyampaikan pengetahuan tentang sistem perangkat lunak.
2. Tujuan Penggunaan Dokumentasi Aplikasi :
a. Dokumentasi aplikasi harus bertindak sebagai media komunikasi antara anggota
tim pengembangan.
b. Dokumentasi aplikasi harus berupa repositori sistem informasi yang akan digunakan oleh
insinyur pemeliharaan sistem.
c. Dokumentasi aplikasi harus memberikan informasi kepada manajemen untuk membantu mereka merencanakan,
d. anggaran dan jadwal proses pengembangan perangkat lunak.
e. Beberapa dokumen aplikasi harus memberitahu pengguna bagaimana menggunakan dan mengelola sistem.
f. Mempelajari cara mengoperasikan sistem
g. Sebagai bahan pelatihan
h. Dasar pengembangan sistem lebih lanjut
i. Dasar bila akan memodifikasi atau memperbaiki sistem di kemudian hari
j. Materi acuan bagi Auditor
k. Back-up
l. Mempermudah komunikasi di antara sesama pegawai
m. Menghilangkan ketergantungan yang kritis
3. Software Crisis
Adalah Sebuah krisis perangkat lunak adalah ketidaksesuaian antara apa yang perangkat lunak dapat hasilkan dan kapasitas sistem komputer , serta harapan dari pengguna mereka . Ini menjadi masalah yang berkembang di abad ke-20 sebagai komputasi yang tumbuh dengan pesat dan perangkat lunak tidak dapat mengikuti . Sebagai kompleksitas sistem yang tumbuh , begitu juga kebutuhan pengguna , yang mengharapkan kinerja semakin lebih dari perangkat lunak mereka . Pemrogram mungkin berjuang untuk mengikuti , menciptakan krisis perangkat lunak .
Perangkat lunak dari konsumen biasanya bergerak melalui serangkaian lambat fase pengembangan , tetapi membuat sebagian kecil dari volume bisnis di industri . Sebagian besar pengembangan perangkat lunak tenggelam ke dalam sistem untuk aplikasi tertentu. Perangkat lunak ini biasanya memerlukan investasi yang besar dari pelanggan, serta pemrograman yang ekstensif dari personil dituntut dengan mengembangkan , menguji , dan memelihara itu .
Gejala yang paling terlihat dari krisis perangkat lunak:
a. Hasil yang terlambat, lebih dari anggaran
b. Produk tidak memenuhi persyaratan yang ditentukan
c. dokumentasi yang tidak memadai
d. Perangkat lunak tidak efisien dan kualitasnya rendah
e. Kompleksitas proyek perangkat lunak meningkat sebagai perangkat keras kemampuan meningkat.
f. Perangkat lunak sistem yang lebih besar lebih sulit dan mahal untuk dipertahankan.
g.Permintaan perangkat lunak baru meningkat lebih cepat daripada kemampuan untuk menghasilkan perangkat lunak baru.

Beberapa pengamatan pada krisis perangkat lunak:
Menurut (Booch, hal. 8) adalah Sebuah penyakit yang telah dilakukan pada panjang ini disebut normal, Karena:
a. Persyaratan sistem perangkat lunak target harus bergerak
b. Ada kemungkinan tidak cukupnya pengembang baik di sekitar untuk membuat semua perangkat lunak baru yang diperlukan pengguna
c. Sebagian besar waktu pengembang harus sering didedikasikan untuk pemeliharaan atau pelestarian software geriatri.

By: Azid Malil'ula Wildan M (10410110014)-S1 Komputerisasi Akuntansi

SUMBER PUSTAKA:
1. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&ved=0CDwQFjAC&url=http%3A%2F%2Fftp.gunadarma.ac.id%2Fhandouts%2FS1_Sistem%2520Informasi.1%2FFebriani%2FDOKUMENTASI.doc&ei=bn8uUrjFHYfZrQfN1IH4Dg&usg=AFQjCNGB4DbojQnpncuo1gMpCGwWpqO_vA&sig2=rTodgHd0nSBPATaqhwglpQ&bvm=bv.51773540,d.bmk
2. http://fairuzelsaid.wordpress.com/2012/01/11/perangkat-lunak/
3. www.businessdictionary.com
4. http://www.princeton.edu/~achaney/tmve/wiki100k/docs/Software_documentation.html
5. http://www.wisegeek.com/what-is-a-software-crisis.htm
6. http://www.ics.uci.edu/~ziv/ooad/intro_to_se/tsld010.htm
7. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=9&cad=rja&ved=0CHwQFjAI&url=http%3A%2F%2Fwww.site.uottawa.ca%2F~tcl%2Fgradtheses%2Faforward%2Faforward_thesis.doc&ei=m4suUvWGOoOErAe89YDwDg&usg=AFQjCNEtr9BruMm07l8xuieI0uas8-lJXg&sig2=kcnONmT8bmJJ2LqyjWohAA&bvm=bv.51773540,d.bmk
8. Software Documentation-Ian Sommerville. Lancaster University, UK
9. https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=7&cad=rja&ved=0CEkQFjAG&url=http%3A%2F%2Fwww.buet.ac.bd%2Fiict%2Fiictcourses%2Fict6010%2Flecture_1.pdf&ei=RJAuUqugI4m4rgfNlYCACg&usg=AFQjCNGmTH9-jZhKdwiNcfjlR_DbIHc5Pw&sig2=3DydQyRGZDHyAUE5e7_sdg&bvm=bv.51773540,d.bmk

Thursday, April 4, 2013

KARAKTER PANCASILA YANG PLURALISTIS


Membangun karakter bangsa sejak dulu didengungkan dalam ruang lingkup Bhinneka Tunggal Ika. Ada yang menyebut istilah karakter lokal mengisyaratkan bagi suatu suku bangsa atau individu namun kalau sudah menjadi kelompok sifat seseorang bisa berubah.Sifat kelompok ini tidak bisa disebut karakter kelompok. Bagaimana kelompok ini lalu menjadi masyarakat, selanjutnya kelompok masyarakat menjadi suatu suku dan akhirnya menaji suatu bangsa memang timbul kesulitan menyebutnya sifat bangsa apalagi karakter bangsa.Selama ini kita kurang memahami Pancasila secara  menyeluruh.Sebagai falsafah bangsa Pancasila sebenarnya harus bisa kita hayati secara menyeluruh.

Dalam suatu masyarakat bangsa yang pluralistk atau multikultural merupakan suatu keharusan dalam menjaga keutuhan negara-bangsa (nation state) Indonesia. 

Budaya dan masyarakat merupakan suatu kesatuan yang tidak dapat dipisahkan,karena budaya dibentuk oleh masyarakat atau tidak ada budaya tanpa masyarakat demikian juga sebaliknya masyarakat merupakan pendukung dari kebudayaan sehingga tidak ada masyarakat tanpa budaya. Sehingga hubungan antara budaya dan masyarakat
adalah hubungan yang bersifat timbal-balik; kebudayaan membentuk manusia, tetapi manusia juga membentuk kebudayaan.

Terwujudnya persatuan dan kesatuan bangsa Indonesia yang terdiri dari berbagai suku bangsa ini adalah didukung oleh adanya Kebudayaan Nasional Indonesia. Oleh karena itu keadaan yang beraneka ragam tersebut bukanlah merupakan suatu perbedaan yang saling bertentangan, namun perbedaan itu justru merupakan daya
penarik ke arah suatu kerjasama persatuan dan kesatuan dalam suatu sintesa dan resultan, sehingga seluruh keanekaragaman itu terwujud dalam suatu kerjasama yang luhur, yaitu
persatuan dan kesatuan bangsa.

Dalam suatu masyarakat bangsa yang pluralistik atau majemuk merupakan suatu keharusan dalam menjaga keutuhan negara-bangsa (nation state) Indonesia. Secara konstitusional kita memiliki landasan yang kuat bagi integrasi nasional yaitu Ideologi
Pancasila. Manusia juga merupakan faktor strategis, yaitu kajian difokuskan pada esensi manusia Indonesia memahami paham kebangsaan dalam zaman yang berubah cepat. Sehubungan dengan hal itu maka perlu dipahami bahwa kuatnya kebersamaan dalam persamaan kebangsaan tumbuh karena 
(1) persamaan nasib pada masa lampau, 
(2) persamaan kepentingan masa kini, 
(3) persamaan aspirasi kemasa yang akan datang. 
Hasrat yang kuat akan kebersamaan kini memerlukan perawatan yang
sekasama.

Dalam membina budaya pulralistik di tanah air ada beberapa faktor yang menyebabkan timbulnya kebutuhan akan kebijaksanaan dan arah perkembangan kebudayaan nasional. Salah satu faktor tersebut adalah: 
(1) semakin intensifnya interaksi sosial budaya antara sesama warga negara Indonesia yang mempunyai latar belakang kebudayaan yang beraneka ragam. Dimana tujuan pembinaan dan pengembangan kebudayaan adalah diarahkan untuk memberi wawasan budaya dan makna pada pembangunan nasional dan segenap dimensi kehidupan masyarakat, berbangsa, dan bernegara serta ditujukan untuk meningkatkan harkat dan martabat manusia Indonesia serta memperkuat jatidiri dan kepribadian bangsa.