Bagaimana bis atau angkot bisa berhenti???

halte_gelael.jpg


Ini adalah salah satu tempat berhenti bis/angkot di jalan Dago (salah satu jalan utama di Bandung). Lihatlah suasananya seperti apa? Taksi, parkir mobil pribadi, motor, kios pulsa….. Tidak mungkin polisi tidak melihat! Walikota sadar engga ya? Wah, saya tidak bisa berkomentar lagi deh! Bagaimana menurut anda?

Nemu tiga lagi dosen ITB yang nge-Blog

Tiga lagi dosen ITB yang saya temukan nge-Blog:

  1. Pak Waskita, banyak tulisan sebelumnya yang disajikan di web pribadi, dan baru start-up di WordPress.
  2. Pak Soni (Kusprasapta) yang hobby ngutak-ngutik robot. Masih belum rajin tampaknya. Semoga segera tambah rajin berbagi ilmu robotnya!
  3. Pak Bambang Setiabudi (Arsitek), dengan blog spesifik tentang Arsitektur Mesjid. Melihat tanggal postingnya, Pak Bambang sudah mulai sejak akhir 2005. Saya temukan link-nya dari blog Pak Waskita.

Banyak Perusahaan Tidak Mempunyai Standar Dokumentasi Pengembangan Software

Bagaimanapun bentuknya, saya kira perusahaan-perusahaan besar pada umumnya mempunyai standar proses pengembangan software yang secara umum biasanya disebut SDLC (Software Development Life Cycle). Di beberapa perusahaan yang manajemen TI nya sudah mapan, SDLC tersebut biasanya diterapkan secara konsisten baik untuk pengembangan software oleh pihak internal, maupun pengembangan software yang melibatkan pihak eksternal (outsourcing). SDLC yang diterapkan secara ketat secara tidak langsung akan meningkatkan kualitas software yang dihasilkan. Bagian dari SDLC juga mensyaratkan adanya dokumentasi software yang baik.

Apakah SDLC saja serta keberadaan dokumentasi software sudah cukup? Jawabannya biasanya baru diketahui setelah ada masalah-masalah berkaitan dengan software aplikasi yang sudah pernah dibuat. Beberapa permasalahan tipikal diantaranya adalah sebagai berikut:

  1. Dokumentasi software ternyata tidak lengkap, ada bagian penting dari software yang tidak dijelaskan dengan cukup, sehingga sulit untuk memahaminya.
  2. Format dan struktur dokumen berbeda-beda
  3. Cara pemodelan berbeda-beda. Mungkin ada yang masih menggunakan flowchart + ER Diagram saja, ada yang menambahkan Data Flow Diagram (DFD), ada yang mencampur adukan UML dengan DFD, atau ada yang secara penuh sudah menerapkan UML.

Permasalahan-permasalahan tersebut di atas akan menghambat tujuan-tujuan sebagai berikut:

  1. Melakukan modifikasi software menjadi sulit dilakukan. Kadang perusahaan ingin melakukan modifikasi kecil dari software yang sudah dibuat dan sudah diluar masa garansi. Tapi sulit dilakukan karena hambatan dokumentasi.
  2. Melakukan pengembangan lebih lanjut menggunakan vendor lain. Dokumentasi yang buruk, yang hanya dimengerti oleh pembuatnya saja, menyulitkan dipahami oleh pihak lain yang akan meneruskan pekerjaan tersebut.
  3. Melakukan integrasi dengan aplikasi lain. Ketika sistem berkembang dan ada tuntutan integrasi, dokumentasi yang buruk mungkin akan menyulitkan untuk memahami struktur data, cara berkomunikasi data, apalagi kalau ada keperluan modifikasi algoritma untuk mencapai tujuan integrasi.

Bagaimana solusinya? Sederhana!

Buatlah standar (template) dokumentasi pengembangan software aplikasi di perusahaan anda. Standar dokumentasi berbeda dengan standar proses pengembangan (SDLC).

Semua pengembangan software, baik yang dilakukan oleh pihak internal maupun cara outsource harus membuat dokumentasi sesuai standar tersebut. Hal yang harus diingat adalah:

Jangan membuat standar dokumentasi yang bentuknya tidak biasa. Saya sarankan untuk mengadopsi dari suatu standar, lalu lakukan penyesuaian minor. Untuk pemodelannya, saya menganjurkan untuk menggunakan UML secara penuh.

Nah, kalau ini sudah tercapai, anda buka dokumen software manapun selalu sama bentuknya dan kelengkapannya cenderung lebih terjamin karena mengikuti template yang sudah ada.

Semoga bermanfaat!