Software Project Management merupakan bidang yang menarik untuk dipelajari dan

tulisan saya di sini lebih difokuskan kepada apa yang telah saya lakukan selama ini. Suatu

Software Project dapat dilakukan oleh Konsultan atas permintaan User atau juga bisa

merupakan Suatu Internal Development Project , dan dalam tulisan ini, yang dibahas

adalah Software Project yang dilakukan oleh Konsultan yang telah ditunjuk oleh User.

Apa yang saya lakukan dalam suatu software project management selama ini adalah

dengan menerapkan SDLC (software development life cycle) yang tediri dari :

1. Project Kick Off

2. Project Plan : menentukan jadwal dan resource

3. Requirement Gathering & Analysis

4. Design

5. Development / Coding

6. Sistem Integration Test

7. User Acceptance Test

8. Data Migration

9. Go Live

Berikut adalah penjelasan singkat terkait hal-hal tersebut di atas :

Project Kick Off

Tahap ini merupakan awal dari project. Tahapan ini dilakukan dalam suatu rapat yang

dihadiri oleh Tim User dan Konsultan. User menyiapkan summary cakupan project serta

tahapan serta deliverables yang diharapkan. Tahap ini dilakukan dalam bentuk rapat resmi

disertai dengan notulensi. Catatan rapat ini akan didistribusikan ke seluruh pihak yang

terkait dengan project dan menjadi landasan kegiatan selanjutnya. Pada tahap ini juga

ditentukan Person In Charge (PIC) baik dari sisi User maupun dari sisi Konsultan. Project

Kick Off dilakukan dengan merujuk kepada kontrak atau SPK yang telah ditandatangani.

Project Plan

Perencanaan project merupakan tahap yang sangat penting. Pada tahap ini, project

manager membuatkan draft jadwal atas keseluruhan kegiatan project, sehingga dapat

memberikan gambaran kepada setiap orang yang terlibat di project. Project manager juga

menyiapkan resource yang akan dilibatkan pada project. Sehingga target utama dari Plan

Project ini adalah untuk mendapatkan gambaran kapan setiap tahapan project dilakukan

dan kapan selesainya serta siapa saja personal yang terlibat dalam project. Hal ini dapat

dibuat berdasarkan kontrak pekerjaan yang telah dibuat dan ditandangani sebelumnya.

Business Requirement Gathering and Analysis

Pendefinisian masalah merupakan hal yang esensi dari sebuah Software Project. Setiap

bagian/unit/divisi yang akan menjadi pengguna software, wajib mengirimkan

perwakilannya pada proses ini. Tanpa keterwakilan dari salah satu bagian/unit/divisi,

assesment kebutuhan menjadi tidak tepat yang pada ujungnya akan memberikan solusi

software yang tidak sesuai dengan kebutuhan.

Pada tahap ini sering kali terjadi konflik kepentingan antara pekerjaan operasional dengan

menghadiri meeting requirement assessment, untuk itu sangat diperlukan dukungan

penuh dari pimpinan perusahaan dari sisi User untuk memberikan prioritas utama pada

project ini. Solusi konflik kepentingan ini sering kali dengan menetapkan minimal satu

orang perwakilan dari setiap bagian/unit/divisi yang terlibat secara penuh project ini dari

awal sampai akhir. Jadi walaupun masih ada tanggung jawab operasional, PIC ini tetap

memprioritaskan waktunya di project. Untuk melengkapi hal tersebut, penentuan PIC

sebaiknya juga disertai dengan penetapan KPI (Key Performance Indicator) tambahan atas

karyawan tersebut atas keterlibatannya di Project Software ini.

Konsultan biasanya akan mengirimkan Project Manager, Business Analyst dan System

Analyst nya ke meeting ini. Project Manager memastikan meeting ini berjalan tepat waktu,

dihadiri oleh peserta meeting yang diharapkan, menentukan target meeting dan

memastikan agar target pertemuan tercapai. Business Analyst mempelajari kebutuhan

User, membuat hipotesis awal, menyiapkan daftar pertanyaan dan menanyakannya ke

User, mencatat jawaban-jawaban yang diterima, melakukan analysis kebutuhan,

menyiapkan minutes of meeting. System Analyst memberikan konfirmasi kesanggupan

teknis saat dibutuhkan oleh Business Analyst. Hal-hal kritikal akan sangat ditentukan dari

kesanggupan teknis yang dikonfirmasi oleh System Analyst dalam menjawab kebutuhan

User.

Konsultant akan menganalisis seluruh hasil interview dengan pihak user ini. Produk dari

tahap ini adalah dibuatkannya Functional Spesification Document (FSD). FSD akan menjadi

rujukan semua pihak yang terlibat di Project ini. FSD akan menjadi rujukan utama

programmer dalam pembuatan program dimana salah satu isi utama dari FSD adalah

desain screen-screen dari software yang akan dikembangkan. FSD yang salah akan

berdampak pada solusi software yang tidak salah.

Design

Tahap desain sangat menentukan kualitas atas software yang akan dibuat. Pada tahap

desain dilakukan pembuatan Flow Process, Data Flow Diagram, Entity Relationship

Diagram, Program Framework dan Struktur Class dan aspek teknis lainnya. Seluruh

pekerjaan pada tahap disain dibuat berdasarkan FSD yang telah disepakati pada tahap

sebelumnya. Desain solusi yang baik akan sangat memudahkan dalam pembuatan

program yang akan dikembangkan. Data Flow Diagram yang efektif dan efisien akan

membuat solusi menjadi lebih cepat dan lebih mudah direalisasikan. Entity Relationship

Diagram menentukan kualitas database yang akan dibangun. Kesalahan yang sering terjadi

adalah ERD tidak dibuat secara akurat sehingga menghasilkan kualitas database yang

redundan dan tidak efisien. DFD merupakan alur data dari business process yang sedang

dipelajari, sedangkan ERD merupakan tipe hubungan antara 2 atau lebih entitas di dalam

business process tersebut.

Coding/Development

Inti dari project software adalah coding/developmen program. Umumnya, kualitas dari

program sering berdasarkan pada kualitas si programmer yang bersangkutan. Software

Project Management yang baik akan membuatkan struktur class yang lengkap dan stabil

sebagai framework utama. Dengan pembuatan struktur class dan framework yang baku,

variasi dan kesalahan programmer dapat diminimilisasi. Tanpa itu akan terjadi tingkat

variasi dan kesalahan yang sering kali tinggi dan mengurangi kualitas software yang

dibangun, untuk itu peran senior developer dalam suatu project software akan sangat

penting, terutama

Saat ini banyak sekali pilihan bahasa program beserta Integrated Development

Environment-nya (IDE), namun yang saat ini banyak digunakan adalah Java, PHP,

Miscrosoft Visual Studio. Net, serta pengembangan untuk platform mobile seperti Android,

Apple dan Blackberry. Terlepas dari perbedaan pemilihan tools development, penerapan

konsep Object Oriented Programming (OOP) merupakan seuatu keharusan dan tetap dijaga

untuk memberikan kualitas software yang efektif dan efisien, konsep class dan framework

yang baik akan memberikan kemudahan dan keseragaman dalam pengembangan software.

Pembuatan Test Script

Tahap ini dilakukan bersamaan dengan tahapan coding/Development yang dilakkan oleh

Business Analyst bersama tim User, tujuannya adalah membuat suatu skenario test yang

lengkap dan komprehensif sesuai dengan proses real yang diinginkan oleh user sehingga

bisa menggambarkan kondisi proses sebenarnya. Test script ini harus benar-benar

mewakili cerita sebenarnya yang dilengkapi dengan contoh nilai-nilai masukan beserta

hasil yang diharapkan. Dengan adanya test script yang lengkap dan komprehensif, maka

testing bisa dilakukan oleh siapa saja, walaupun tidak terlibat di tahap awal project

software, dimana orang yang akan melakukan testing, cukup memasukan nilai awal sesuai

test script dan melihat apakah nilai yang dihasilkan sudah sesuai dengan hasil perhitungan

manual yang tercantum pada test script. Kasus-kasus test script harus divariasikan sesuai

dengan kemungkinan variasi pada proses sebenarnya.

Sistem Integration Test (SIT)

Pada tahap ini, modul-modul yang telah dikembangkan akan diintegrasikan menjadi suatu

solusi lengkap. Setelah diintegrasikan, sistem akan diujicobakan dengan menggunakan test

script yang sudah dibuat sebelumnya. Pengujian ini dilakkukan oleh internal konsultan

tanpa melibatkan user, namun test script yang digunakan tentunya sudah disesuaikan

dengan keinginan user dan disetujui user. Bila hasil dari ujicoba tidak sesuai dengan

hasilyang tertera di test script, maka program masih salah dan perlu diperbaiki. SIT telah

selesai apabila seluruh input test script telah diujicobakan dan hasilnya juga telah sesuai

dengan yang ada di test script. Business Analyst adalah PIC yang melakukan testing pada

proses SIT ini. Programmer akan melakukan perubahan yang diperlukan sampai diperoleh

hasil yang diharapkan sesuai test script.

User Acceptance Test (UAT)

Tahap ini kurang lebih sama dengan yang dilakukan pada tahap SIT, hanya saja yang

melakukan adalah User dari bagian/unit/divisi terkait. Tantangan yang muncul pada

tahapan ini adalah memastikan agar user terkait dapat menghadiri jadwal UAT sesuai

dengan waktu yang disepakati. Suatu sistem yang diintegrasikan biasanya melibatkan

beberapa bagian/unit/divisi, sehingga ketidakhadiran salah satu perwakilan dari

bagian/unit/divisi tertentu akan memundurkan jadwal UAT sehingga jadwal keseluruhan

juga jadi terganggu. Untuk itu perlu dilakukan pendeketan secara dini ke setiap pimpinan

bagian/unit/divisi terkait sehingga mempunyai kesadaran dan persepsi yang sama

mengenai pentingnya software yang sedang dikembangkan. Walaupun batasan pekerjaan

dan batasan proses ujicoba sudah digariskan dengan testscript yang disepakati

sebelumnya, namun demikian tidak jarang pada saat UAT, user menemukan suatu variasi

testing yang ternyata tidak ada di test script dan hal terburuknya adalah feature yang tidak

tersedia tersebut harus di develop oleh programmer. Hal ini tentunya akan menunda

penyelesaian UAT, namun apabila hal itu memang harus terjadi, maka harus mendapat

persetujuan dari kedua belah pihak. Masalah yang sering terjadi adalah pihak konsultan

sering disalahkan pada saat terjadi kemunduran jadwal karena tidak mendokumentasikan

dengan detail hal-hal yang menjadi new request selama proses UAT. Proses UAT biasanya

adalah proses yang paling sibuk/ramai dibanding tahap lainnya di SDLC, karena pada tahap

ini seluruh pihak terkait biasanya langsung saling berinteraksi, jadi adalah sangat bijaksana

bila seorang Project Manager mengantisipasi hal ini sedini mungkin, salah satunya adalah

pada saat requirement gathering dan pembuatan test script yang seakurat mungkin. Selain

itu, dengan penanganan new request yang baik, masalah keterlambatan penyelesaian UAT

dapat diselesaikan dengan baik.

Data Migration

Software dibuat dengan tujuan untuk menggantikan proses manual yang selama ini terjadi

menjadi suatu proses yang otomatis, atau mengganti sistem lama dengan sistem baru yang

dianggap lebih baik, atau melakukan penambahan program atas existing program. Jenis

manapun dari pengembangan software tersebut di atas harus melalui tahap yang

dinamakan Data Migration atau Migrasi Data. Untuk pelaksanaan data migration, beberapa

hal harus dipersiapkan yaitu : penyiapan existing data yang digunakan secara manual atau

yang digunakan oleh sistem yang lama, pembuatan script untuk melakukan one time

migration dimana data yang lama akan diupload ke sistem baru dengan menggunakan

script migrasi tersebut. Selain itu yang harus disiapkan adalah cut off dimana data

migration akan dilakukan, pemberitahuan ke seluruh pengguna sistem lama kapan cut off

data akan dilakukan dan berapa lama sistem akan off, pembuatan panduan step by step

dalam melakukan migrasi data, dan terakhir adalah pembuatan Fall Back Plan dimana bila

proses migrasi ini gagal, maka data lama akan dikembalikan lagi ke enviroment production,

sistem baru diangkat kembali dan sistem lama di kembalikan lagi. Setelah semua data

terbukti berhasil dimigrasikan dan user sudah melakukan final cek atas data hasil migrasi

di sistem baru, maka migrasi data selesai dilakukan.

Go Live

Ini adalah suatu tahap dimana semua proses SDLC sudah selesai dan user sudah bisa

menggunakan sistem baru dengan existing data. Setelah Go Live bukan berarti tidak ada

problem lagi, sering kali suatu sistem akan terlihat masalahnya pada saat sistem Go Live di

production server, namun dengan penanganan proses project management yang handal,

problem ini seharusnya dapat diminimalisasi.

Support

Untuk menjamin agar sistem berjalan bagus dan stabil setela production, diperlukan

mekanisme support yang efektif, dengan Service Level Agreement (SLA) yang disepakati

oleh User dan Vendor. Issue biasanya digolongkan menjadi Critical/Stopper, Urgent,

Important dan Nice to Have, dan masing-masing kriteria issue ini akan disolusikan dengan

SLA yang berbeda-beda