Log Book (Sept 9th, 2012) for Supervisor

TAHAP ANALISIS

Berdasarkan hasil studi literature, maka ada beberapa hal yang bisa disimpulkan. Proses pembuatan software secara umum ada 4 tahap yaitu perencanaan, analisis, perancangan, dan impelementasi.

Perencanaan terutama mengenai permintaan pembuatan sistem dari stakeholder/bisnis yang membutuhkan. Lalu dibuat semacam timeline dan juga budget untuk pembuatan sistem ini.

Setelah adanya perencanaan, maka dijalankan proses analisis. Kegiatan utama dalam proses analisis ini adalah mendefinisikan dan mengklarifikasikan kebutuhan-kebutuhan (requirements).

Kegiatan utama proses analisis :

1. mendefinisikan sistem berjalan (the as-is system)
2. mengindentifikasikan kemajuan (improvement) jika menggunakan sistem baru
3. mendefinisikan kebutuhan-kebutuhan dari sistem yang akan dibuat (the to-be system)

Pada metode SDLC tradisional, seperti waterfall atau pararel, kegiatan proses analisis ini lebih dijalankan setiap tahapnya, sedangkan di metode SDLC yang baru seperti RAD atau Agile, proses pendefinisian sistem berjalan tidak dikerjakan secara maksimal, lebih terfokus pada sistem baru yang akan dibuat. Keberhasilan dari proses analisis ini sangat terpengaruh oleh kemampuan dari System Analyst yang melakukan analisis.

DEFINISI KEBUTUHAN (REQUIREMENTS)

Requirements determination (penentuan kebutuhan) dilakukan untuk mentransformasi permintaan system dari pernyataan tingkat tinggi kebutuhan-kebutuhan bisnis menjadi langkah terperinci, yaitu daftar yang tepat mengenai apa harus disediakan oleh sistem baru sehingga meningkatkan nilai dari bisnis itu sendiri. (Roth, p. 104)

Kebutuhan-kebutuhan ini secara sistematis akan didukung, diklarifikasi dan dikonfirmasi dengan cara membuat use-case, membangun process-model dan data-model yang kemudian akan digunakan pada tahap perancangan selanjutnya.

Kebutuhan-kebutuhan sendiri ada 5 (lima) kategori yaitu :

• Kebutuhan bisnis (business requirements)
• Kebutuhan pengguna (user requirements)
• Kebutuhan fungsional sistem (functional requirements)
• Karakteristik sistem yang dibutuhkan (nonfunctional requirements)
• Bagaimana sistem dibangun (system requirements)

Dari 5 kategori diatas, untuk mendefinisikannya pun dimulai dari kegiatan pertama yaitu kebutuhan bisnis, kebutuhan ini didefiniskan biasanya sudah dari awal perencanaan. Ketika tahap perencanaan ketika sistem diminta dibuat oleh bisnis, maka terdapat permintaan bisnis terhadap sistem, dari situ akan diturunkan menjadi kebutuhan-kebutuhan bisnis.

Untuk mencapai kebutuhan-kebutuhan bisnis yang diharapkan, maka ada tugas,pekerjaan,proses ataupun aktivitas yang dilakukan oleh pengguna bisnis (business user). Karena pemikiran tersebut, maka jika sistem bisa memenuhi kebutuhan user, maka kebutuhan bisnis ini akan terpenuhi (Roth, p. 105).

Menurut Roth pada halaman 105 paragraf ke-2 kalimat ke-2.

“A good starting place is to concentrate on what the user actually needs to accomplish with the system in order to fullfill user needed job or task. ... (end of paragrah)... By understanding what the user needs to do in terms of tasks to perform, the analyst can then determine ways in which the new system can support the user’s needs.”

Lalu untuk mendenisikan kebutuhan user ini, didefinisikanlah use-case. Dengan use-case maka sistem berjalan bisa digambarkan dan juga bisa didefinisikan bagaimana sistem baru berjalan sesuai dengan kebutuhan dari user. Setelah use-case didefinisikan dan kebutuhan user ter-indenfitikasi, maka bisa dilihat kebutuhan fungsional dari sistem yang akan dibuat.

Menurut Roth pada halaman 105 paragraf 3 kalimat 2,

“A functional requirement relates directly to a process the system has to perform as a part of supporting a user task, and/or information it needs to provide as the user is performing is performing a task.”

Functional Requirements ini bisa dilihat dari dua sudut pandang, object-orinted atau information-oriented. Functional Requirements ini akan lebih didefinisikan secara rinci dengan menggunakan Process-Model. Process Models digunakan untuk menjelaskan hubungan proses fungsi dengan pengguna sistem, bagaiaman fungsi/proses berhubungan satu dengan lainnya, bagaimana data di masukan dan dihasilkan oleh fungsi/proses, dan bagaimana fungsi/proses dibuat dan mengguna data yang disimpan.

Process Model mengklarifikasi komponen S/W yang dibutuhkan untuk memenuhi kebutuhan fungsional dimana kebutuhan fungsional ini dimulai dengan mendefinisikan data yang harus di track agar tugas pengguna bisa diselesaikan. Komponen data ini akan didefinisikan pada Data Model.

Kebutuhan pengguna dan kebutuhan fungsional akan digunakan pada fase design/perancangan. Kebutuhan pada fase design yang dilihat dari sudut pandang developer akan disebut sebagai System Requirements.

Sedangkan untuk Nonfunctional Requirements contohnya sistem bisa diakses secara mobile. Nonfunctional Requirements digunakan pada fase design ketika ingin memutuskan user interface, the h/w and s/w, dan arsitektur sistem. Bidang2 yang termasuk nonfunctional : operational, performance, security, and cultural and political.

Berdasarkan penelitian Standish Group alasan utama proyek TI gagal adalah kurangnya partisipasi dari pegguna. Tapi di sisi yang lain, pengguna bisnis mungkin tidak semuanya menyadari adanya kesempatan-kesempatan yang bisa ditawarkan teknologi terbaru untuk menyelesaikan kebutuhan bisnisnya. Makanya sangat perlu adanya sebuah kerjasama tim antara pengembang dan juga stakeholder dari sistem yang akan dibangun.

Ada 5 teknik yang paling  umum digunakan untuk mendapatkan dan mendifinisikan kebutuhan-kebutuhan yaitu :

• Wawancara
• Sesi JAD (Joint Application Development)
• Kuesioner
• Analisis Dokumen
• Observasi

Kesimpulan dari beberapa teknik di atas adalah pentingnya pemilihan orang untuk dilakukan analisis, sangat tergantung dengan sumber daya manusia, baik dari sisi system analyst, maupun dari perusahaan/stakeholder bisnis yang membutuhkan sistem.

STRATEGI ANALISIS KEBUTUHAN

Ada 9 strategi untuk melakukan analisis kebutuhan  :

• Analisis Masalah
• Analisis Penyembab Utama (Root Cause)
• Analisis Durasi

Analisis ini akan meneliti berapa lama waktu yang dibutuhkan ketika menjalankan sistem yang berjalan.  Pada analisis ini, seorang analis harus mengkakulasi dan membandingkannya dengan praktikal terbaik (best practice), apakah ada rentang waktu yang terlalu lama dengan yang diharapkan. Jika ya maka akan butuh sekali perubahan besar dalam proses kerja di sistem yang akan dibuat untuk mempercepat waktu penyelesaian sistem. Yang bisa dikerjakan adalah pengintegrasian proses atau membuat proses menjadi pararel.

• Acitivity-Based Costing
• Informal Benchmarking
• Outcome Analysis
• Technology Analysis
• Activity Elimination

Pada analisis ini, manager dan system analyst akan bekerjasama meng-indentifikasikan bagaimana organisasi dapat menghapus beberapa aktivitas bisnis, bagaimana fungsi tersebut bisa berjalan tanpa aktivitas tersebut, dan apa resiko yang mungkin muncul karenanya.

• Comparing Analysis Strategies

USE-CASE DAN DFD

DFD dibuat berdasarkan Use-Case yang sudah di-indentifikasi dan didefinisikan. Sedangkan use-case adalah cara menggambarkan user-requirements dari sistem yang akan dibuat. Karena menurut Roth, kunci dari berhasilnya memenuhi kebutuhan bisnis adalah memenuhi kebutuhan pengguna dalam menjalankan tugas-tugasnnya, karena sebagai pengembang diharapkan bisa membuat sistem yang berguna dan bisa digunakan, oleh sebab itu perlu adanya analisis dari user-requirements.

Namun menurut Roth juga, secara tradisional cara mendapatkan kebutuhan adalah dengan menanyakan ke pengguna apa yang mereka mau kerjakan dan dikerjakan oleh sistem yang baru. Hal ini sangat menantang bagi pengguna karena :

1. Pengguna tidak tahu apa yang bisa ataupun yang tidak bisa dikerjakan oleh sistem. Ketidak-mengertian user mengenai kemanjuan teknologi dan kapabilitas serta limitasi dari sebuah sistem informasi
2. Pengguna juga akan kesulitan bagaimana caranya untuk mengubah bisnis proses yang sudah berjalan.
3. Banyak pengguna mendeskripsikan hal-hal yang mereka mau pada sistem baru, bukan kebutuhan yang dibutuhkan secara nyata pada sistem baru.
4. Pengguna mengalami kesulitan membaca process ataupun data-modelling yang dibuat oleh system analyst.

Oleh karena hal-hal tersebut, konsep dari use-case sendiri terlah ber-evolusi menjadi sebuah komponen penting ketika mementukan kebutuhan-kebutuhan untuk sistem baru. Use case sangat berharga untuk aplikasi sistem bisnis dan websites, use-case tidak berguna untuk batch processes, aplikasi perhitungan  intensif, atau data-warehousing.

KESIMPULAN SEMENTARA

Dari studi literature yang saya baca ini, saya masih menangkap hal-hal sebagai berikut :

• User requirements masih diletakan pada tahapan ke-2 dalam menentukan kebutuhan sesudah mendapatkan kebutuhan bisnis, karena dianggap untuk memenuhi kebutuhan bisnis, semua aktivitas akan dikerjakan oleh penggunanya. Jadi kebutuhan pengguna masih merupakan kunci dari penentuan kebutuhan.
• Pada strategi analisis, sudah diberikan adanya strategi analisis durasi, activity elimination, dan outcome analysis, jadi secara strategi nya pun seharusnya sudah memperhatikan masalah meng-efesien-kan proses kerja yang ada
• Pada proses peng-indentifikasian use-case juga sudah ada dan disadari beberapa kelemahan dari cara tradisional mendapatkan kebutuhan pengguna
• Sangat disadari bahwa jika kondisi seperti ini, maka diperlukan keahlian dan kematangan dari seorang system analyst untuk menentukan keberhasilan dari sebuah proyek IT dan juga semakin literate pengguna bisnis terhadap teknologi informasi, maka semakin menentukan besarnya keberhasilan. (Masih sangat tergantung dengan sumber daya manusia dalam analisisnya)

Hal-hal yang masih bisa dikritisi :

• Melakukan perubahan pada metode analisis agar dapat mengeleminasi kelemahan pada pengguna bisnis (business users) dalam proses penentapan kebutuhan ?
• Melakukan modifikasi pada model use case ?
• Menambahkan process requirements ?
• Melakukan eksperimen mengapa dengan teori seperti ini tapi ternyata di lapangan tidak bisa digunakan ?