Analisis Sistem, Salah Satu Penyebab Kekacauan Proyek

Analisis sistem :) Waktu ngedenger itu, sejujurnya kepala gw bingung. Bingung, apa yang musti dilakukan duluan? Gimana menyimpulkan bahwa si pengguna kebutuhannya adalah modul ini, ini, ini dan itu? Kalau softwarenya kecil, dan dipake oleh sedikit orang masih gak masalah. Tapi gimana kalo softwarenya besar, dipake oleh banyak orang yang tersebar di divisi-divisi? Software yang dibuat, harus bisa mengintegrasikan proses-proses yang ada. Gimana kita bisa memulai ngumpulin kebutuhan untuk bikin software "raksasa" itu?

Nah, kepusingan ini muncul pada saat dapet proyek ERP perusahaan manufaktur, dan yang terakhir Sistem Informasi Hotel. Nah Sistem Informasi Hotel, bagian Front Officenya aja udah besar dan kompleks, ditambah lagi Back Office, yang kalo diliat-liat kebutuhanya udah kayak ERP buat perusahaan manufaktur. Cuma gak ada modul untuk Produksinya. Pusing lah sudah..

Di buku Robert L. Glass, judulnya Facts And Fallaces Of Software Engineering, di Fact no 23, dia bilang gini,

One of the two common causes of runaway projects is unstable requirments.

Ternyata bener banget :) Gw ngalamin masalah di proyek-proyek besar itu.

Beberapa waktu ini, gw lagi sering belajar manajemen. Tadi malem mulai belajar tentang Software Project Planning. Yang dibutuhin dari planning, salah satunya adalah data-data dari masa lalu. Akhirnya mulai mikir, kalo untuk programming, bisa kita ukur waktunya, untuk disain juga bisa. Karena ada framework, jadi lebih mudah antisipasinya. Waktu mulai mikir analisis........ deng deng..... pusing pun datang. Karena memang gak pernah dipikir sampe tuntas, tahapan-tahapan untuk analisis yang kita pake di kantor.

Akhirnya sepanjang jalan dari rumah ke kantor (jalan kaki nih, kan deket), gw mikirin langkah apa aja yang musti dikerjain. Sampe kantor, gw tambahin di file software_dev_workflow.xls (file yang isinya hasil mikir tentang step-step pengembangan software), begini isinya,

1. Pahami struktur organisasi customer. Dengan memahami struktur organisasi, dapat membantu kita buat mecah-mecah masalah menjadi lebih kecil. Contoh, hotel terdiri dari departemen Front Office, Food And Beverage, Accounting, Marketing dan HRD.
   
2. Pahami proses yang terjadi di setiap departemen dan hubungannya dengan departemen lain. Contoh, untuk melakukan pembelian, bagian gudang membuat Purchase Requisition dan diberikan ke bagian Procurement, bagian Procurement membuat Purchase Order, lalu dikirimkan ke Vendor...dst dst.
   
3. Kumpulkan dokumen-dokumen yang digunakan di setiap departemen. Sewaktu proses terjadi di dalam dan antar departemen, ada dokumen-dokumen yang digunakan. Dokumen ini digunakan sebagai landasan dikerjakannya sesuatu, atau dasar pencatatan akuntansi. Dengan mempelajari dokumen-dokumen tersebut, kita bisa memahami data-data yang digunakan, dan persetujuan yang diperlukan oleh tingkatan yang lebih tinggi. Contoh, untuk proses pembelian tadi bisa dilihat dokumen-dokumenya di contoh di atas. Lalu di Purchase Order, perlu ditandatangani oleh Departement Head Accounting.
4. Pahami pencatatan-pencatatan yang dibuat oleh komponen-komponen yang ada. Contoh, pelajari pencatatan utang yang dibuat oleh bagian Account Payable.
5. Pelajari laporan-laporan yang dibuat. Dengan mempelajari laporan-laporan yang dibuat, kita dapat menyimpulkan data-data tambahan yang perlu disimpan yang data tersebut tidak ada di dokumen dan pencatatan. Lalu, kita juga dapat menyimpulkan kebutuhan laporan mereka. Contoh, laporang Aging AP berisi informasi hutang yang kita miliki per periode tertentu (3 bulan, 6 bulan, > 12 bulan).
6. Buat Use Case. Setelah kita pahami beberapa komponen di atas, kita sudah mulai dapat simpulkan gimana kira-kira nanti pengguna akan mengakses sistem.
7. Definisikan modul-modul yang perlu dibuat dan integrasinya dengan modul lain. Kalo udah ada use case, mudah untuk menentukan modul-modul apa saja yang perlu dibuat. Contoh, perlu dibuat modul Invoice, modul ini akan terintegrasi dengan Incoming Payment.
   
8. Buat aturan untuk setiap modul. Contoh, di modul Point Of Sales, dilarang ada penghapusan bill. Pembatalan bill harus dilakukan dengan mekanisme void, di mana sistem akan membuat transaksi pembalik dari bill yang di-void.

Baru segini yang kepikiran nih. Hmm, ntar di perjalanan disempurnain lagi deh :)

Para Project Manager dan System Analyst, harus sangat merhatiin masalah prosedur analisis sistem. Karena kesuksesan dan kegagalan proyek software, bisa disebabkan oleh yang satu ini.

NB:
Karena sejauh ini pekerjaan yang gw dapet adalah ngembangin sistem informasi, jadi yang disebutin di atas adalah langkah-langkah untuk analisis software Sistem Informasi.

Project Management Dan Ocean 11 - 12 - 13

Baru selesai nonton Ocean 13 di kantor. Sekalian nunggu ujan reda. Gw suka semua film Ocean, walaupun yang kedua banyak anehnya (masa pake nyaru jadi Julia Robert......dsb dsb). Di film2 itu diceritain beberapa orang yang jago di bidangnya masing-masing, lalu mereka kerja sama untuk mencuri :) Mereka semua percaya diri dengan kemampuan mereka, dan tau sekali apa yang harus dilakukan untuk menyelesaikan pekerjaan. Lalu pada saat pengerjaan, mereka semua melakukanya dengan sempurna.

Setelah nonton film itu gw mikir. Mungkin gak ya kita develope software sehebat mereka nyuri :D? Semua komponen dalam tim tau apa dan kapan mereka mengerjakan pekerjaaanya. Semua tau, jika apa yang mereka lakukan gagal, akan menghancurkan seluruh proyek. Dan semua merasa punya tanggung jawab besar terhadap proyek.

Kalo diperhatiin, yang pertama mereka miliki adalah pengetahuan terhadap tujuan mereka. Setelah itu mereka pecah jadi tujuan2 yang lebih kecil. Lalu pecah lagi sampai lebih kecil lagi. Sampai mereka bisa menentukan kapan melakukan apa dalam hitunggan menit, bahkan detik. Gak dijelasin rinci gimana mereka memmbuat jadwal sih. Cuma pasti mereka pake Work Breakdown Structure (WBS) ya :D. Dengan begitu mereka bisa membuat rencana yang sangat rinci dan akurat.

Yang kedua adalah orang2 yang sangat hebat di bidangnya masing-masing. Ada yang jago hacking, jago bahan peledak, jago akrobat dsb dsb.

Yang ketiga, mereka punya relasi yang luar biasa :) Kayanya setiap butuh sesuatu ada aja channelnya.

Yang keempat, mereka punya Danny Ocean, pemimpin yang memang jago :)

Dan yang menarik, mereka melakukan semua itu dengan kereeeeeen.

Gak Enaknya Radang Sinus

Pernah ngerasain sakit gigi yang luar biasa pastinya kan? Nah bayangin kalo sakit kaya gitu adanya di kepala. Sakitnya mulai dari jidat sampe ke belakang leher. Subhanallah, itu sakit yang paling gak enak yang pernah gw rasain. Hari ini yang paling parah. Sampe mata mau melek gak bisa.

Sinus itu ada di beberapa tempat di sekitar hidung dan jidat. Sebenernya sinus itu rongga yang dibentuk dari beberapa lempengan tulang. Jadi gak bisa diangkat tu sinus. Nah, kalo udah radang sinus, cairan yang seharusnya bisa keluar dari rongga itu jadi gak bisa keluar. Ini yang nyebabin kepala sakit lwar byasa. Yang gw heran, idung segede gaban begini masih kena radang sinus :D Tapi sodara-sodara berhidung gaban pun kena sinus si.

Gw udah beli buku tentang Sinusistis buatan Harvard Medical School. Di situ diceritain banyak tentang sinus. Cuman istilahnya istilah kedokteran semua. Otak gw jadi gak fokus kalo udah muncul bahasa-bahasa latin :D. Kebanyakan baca buku Ilmu Komputer kalik.

Cara pengobatannya macem-macem, ada yang minum obat, ada irigasi, ada operasi dsb dsb. Nah gw ngobatin kalo lagi kambuh sinus ada beberapa alternatif:

1. Minum obat. Tadi minum clarinase udah gak mempan. Kayanya mau minum yang lebih keras nih laen kali.
2. Kilik idung biar bersin :D. Kalo gak parah-parah amat mah lumayan ilang. Ingusnya jadi keluar.
3. Olesin bagian yang sakit pake minyak babah. Ini baru tadi dicobain. Gak tau tuh minya mereknya apa. Yang jelas ada gambar engko engko cina. Minyak ini dari Singapur. Dikirimin sama keluarga yang ada di sana.
4. Olah raga. Tsah. Beberapa hari belakangan lagi merutinkan lari pagi. Efeknya lwaarbyasa. BUkan cuma sinus, tapi gak enak badan dan ngantuk2 pun hilang seketika.

Sekian pembahasan ngasal tentang penyakit tergakenak di dunia ini (at least untuk sekarang, mudah2an gak dikasih ayng lebih berat dah).

Mungkinkah Paralalelisme Tugas di Tim Software?

Minggu ini, kami bertiga menjadwalkan presentasi dua proyek ke customer. Akhrinya proyek yang satu di pegang Harry, proyek yang satu di pegang Dankos. Gw bantu mereka diskusi dan nyusun-nyusun jadwal dan ngerinciin pekerjaan yang harus selesai pada waktunya dan kapan ngerjainya - simply to say, me-manage. Semakin hari, perkara manajemen ini semakin pusing. Padahal timnya kecil. Tapi memang proyeknya juga aga gak masuk diakal dikerjain dengan jumlah tim segini. Tapi gimanapun, semua harus selesai.

Mengenai paralelisme tugas. Satu orang, bertanggung jawab untuk mengerjakan beberapa pekerjaan. Sebelum kita bahas tentang paralelismenya, kita bahas dulu, pekerjaan apa aja yang harus ada waktu kita ngembangin software.

1. Project Management, kita yang kerjaannya selalu teknis, akan memandang sebelah mata pekerjaan ini. Kita terbiasa membuat software yang (setidaknya menurut kita) bagus. Karena itu kita mikir, kitalah (para engineer) superhero :). Kalo di proyek kecil, ok. Tapi kalo udah agak besar sedikit. Rasain sendiri deh tuh :) Project Manager (PM) tugasnya bikin perencanaan secara umum, bikin jadwal, bagi-bagi pekerjaan, dan kontrol pekerjaan2 itu. (mungkin ada yang kurang nih). Bayangin apa yang PM musti bisa? Dia harus paham seluruh proses (analisis, disain, coding, testing, deployment) yang ada di tim, dia juga harus bisa memprediksi lama waktu pengerjaan berdasarkan pemahaman proses tersebut dan berdasarkan kemampuan anggota2 tim.
2. Analisis sistem, ini juga pekerjaan yang dianggap enteng. Mungkin yang baca tulisan ini pernah mengalami proyek yang ga beres2, modul-modul yang gak kepake setelah dibikin, modul-modul yang salah akhirnya harus dirombak, laporan-laporan yang kacau... dsb dsb. Nah, dosa-dosa ini sebagian besar disebabkan oleh orang yang mengerjakan project management dan analisis sistem :) Kenapa begitu? Kalo sistem analis salah, maka itu akan jadi domino effect, semua pekerjaan salah, karena yang dikerjain selama ini adalah sesuatu yang dipahami secara salah, atau solusi yang disimpulkan tidak tepat. PM salah, soalnya dia tidak kontrol keadaan ini.
3. Disain sistem, pekerjaan ini juga gak mudah. Mari kita liat faktanya. Berapa banyak programmer jago yang bisa disain dengan baik? Yang paham betul tentang loosly coupling, cohession, modularitas dsb dsb. Banyak banget programmer jago, cuma dari segi disain, belum tentu bagus. Apa manfaat disain yang bagus? Manfaatnya adalah memudahkan ketika ada perubahan, dan pada masa maintenance.
   
4. Programming. Pekerjaan yang kita semua sukai :)
   
5. Testing. Ada banyak fase-fase testing. Setiap orang dalam tim harus melakukan testing berdasarkan tingkatanya masing-masing. Programmer, harus melakukan tes, apakah pekerjaanya sudah berjalan dengan baik dan benar. Benar, artinya input, proses, dan output sudah benar. Baik, artinya sudah sesuai dengan disain. Disainer harus testing apakah pekerjaan sudah sesuai dengan disain atau belum, dan apakah memenuhi spesifikasi yang dijelaskan analis. Analis juga harus testing, apakah pekerjaan sudah memenuhi kebutuhan client atau belum, dan apakah semua proses sudah benar. Idealnya proses ini dikerjakan oleh orang-orang khusus.
6. Deployment. Proses ini isinya instal, pelatihan, terus perbaiki kalo ada masalah. Untuk aplikasi2 kecil, proses ini sangat mudah. Gimana kalo softwarenya udah dipake banyak divisi dengan kemampuan komputer yang seadanya? Kalo analisisnya ngaco, disainya ngaco, programmingnya berantakan, datanglah hari-hari penuh derita untuk tim pengembang.
7. Maintenance. Proses ini harusnya sudah tidak terlalu ribet. Karena software harusnya sudah berjalan lancar. Tapi ada aja yang gak seharusnya :)

Seluruh pekerjaan di atas, disadari atau tidak, HARUS bin WAJIB dikerjakan pada pengembangan software. Kalo ada salah satu yang gak diperhatiin, maka hari-hari penuh derita yang dateng.

Sekarang bicara paralelisme. Satu orang ngerjain beberapa tugas. Setelah didaftarin di atas, kebayang gak pusingnya kalo ada satu kerjaan dipegang oleh dua orang? Misal, PM digabung sama sistem analis. Orang itu harus bikin planing, jadwal.........., dia juga harus ketemu customer, wawancara, simpukan solusi.................. Bisa kebayang bebannya?

Lalu gimana dengan programmer dan disainer dijadikan satu? Ini yang sering dianggap biasa. Yang akhirnya software yang dihasilkan disainya kacau balau berantakan. Orang-orang yang maintain bisa gila ngurusinnya.

Sekarang, gimana kalo timnya kecil? Apakah tidak bisa paralelisme? Menurut gw sih bisa, tapi harus diliat kombinasi paralelisme yang pas. Sekarang mikir dulu, ntar kalo dah ketemu yang pas gimana baru tulis lagi :)

Novel

Kalo ada judul "Novel", di blog ini, pantesnya yang di bahas adalah sistem operasi Novel. Tapi bukan. Gw mau tulis tentang pengalaman gw baca novel tadi malem. Lebih khusus lagi, novel cinta. (yassalaam)

Dua hari lalu, gw nganter sepupu-sepupu gw ke Ekalokasari (sebuah plaza yang adanya di Tajur, Bogor). Mereka mau pulang ke Jerman, jadi pengen belanja-belanja. Setelah muter-muter di situ, yang terakhir dimasukkin adalah Gramedia.

Ade gw seneng banget baca novel-novel karangan Habiburrahman El Shirazy (mudah2an bener nih spellingnya). Pas masuk Gramedia, ada tumpukkan novel barunya (setidaknya gw dan ade gw belom pernah liat). Gak pake mikir, langsung dia beli. Judul novelnya "Dalam Mihrab Cinta" (ahuhhuy gak kuwat). Pas dia beli, gw bilang "An kakak duluan yang baca yeh." Dia jawab, "enak aje, pulang langsung Aan mau baca."

Kemaren sore, radang sinus kambuh lagi. Kepala sakit lagi. Padahal gw udah olah raga :(. Makin parah aja nih kayanya. Sehabis makan siang, gw minum obat (Clarinase). Biasanya kalo minum obat ini terus tidur, pas bangun udah sembuh. Karena gak ngantuk, gw ambil aja novel Dala Mihrab Cinta. Ade gw lagi ga ada di rumah. Gw naek ke atas, slonjoran di tempat tidur sambil baca, supaya ngantuk.

Ternyata dalam novel ini ada tiga novelet. Novelet kalo gak salah artinya adalah novel kecil. Judul novelet yang pertama adalah "Takbir Cinta Zaharana" (yassalaam). Setiap baca judulnya langsung muncul kesan gombal di kepala gw :D. Nama Zaharana ini bagus juga ya. Cuma ga tau nih artinya bagus apa nggak.

Di novelet itu diceritain gimana seorang perempuan yang udah lulus S2 ITB dan jadi dosen belum juga nikah sampe umur di atas 30. Kayanya keadaan seperti itu masalah yang sangat besar buat perempuan ya. Dia beberapa kali dilamar tapi dia tolak, karena dia pengen pendamping yang sesuai sama dia. Berenti sampe di sini, karena tujuan gw bukan nulis resensi :D. Kalo mo tau silahkan baca bukunya. Takut-takut yang baca malah kesel karena diceritain duluan.

Gw udah lama pengen "bisa nikmatin" novel. Cuma gw ngerasa itu gak terlalu banyak manfaat. Dan takut kalo gw suka, gw jadi seringan baca novel daripada yang laen. Tapi setelah baca novelet tadi, ternyata gw salah.

Gw sangat suka nonton film yang bagus. Film yang ceritanya bagus, dan karakter-karakter di dalamnya juga bagus. Karena banyak yang kita bisa pelajarin dari film kaya gitu. Film terkhir yang gw sukaaa banget, walaupun udah beribu2 kali (hiperbola) nonton adalah Forest Gump.

Nah ternyata novel juga begitu. Setidaknya novel yang kemaren gw baca tentang si Zaharana ;;).

Cuman, menurut temen gw yang seneng novel, novel itu malah kurang bagus. Terlalu mengada-ngada katanya. Berarti novel-novel lain lebih bagus dari yang itu ya.

Jadi sekarang gw mendeklarasikan hobi baru gw :D, "Baca Novel".