Tenaga Ahli Konsultan Individual
Tenaga
Ahli Konsultan Individual
merupakan posisi pekerjaan yang akan di bahas kali ini. dalam tulisan saya di sini, lebih difokuskan kepada pengalaman saya sebagai Tenaga Ahli Konsultan
Individual pada suatu Proyek Pembangunan
Portal Aplikasi SIPP(Sistem Informasi
Perencanaan & Pengendalian) dengan menerapkan SDLC (Software Development Life Cycle) yang terdiri 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 dan contoh terkait hal-hal tersebut
diatas :
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. Berikut beberapa dokumen terkait proses Kick
Of Meeting :
a)
SK
Kegiatan Pengadaan
b)
KAK
(Kerangka Acuan Kerja)
c)
RAB
(Rencana Anggaran Biaya)
Source : http://wendyprasetya.blogspot.co.id/2016/08/rencana-anggaran-biaya-adalah-suatu.html
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. . Berikut beberapa dokumen terkait proses Project
Plan :
a)
Time Schedule/ Gantt Chart
Source : http://wendyprasetya.blogspot.co.id/2016/08/time-schedule-merupakan-rencana-alokasi.html
b)
Infrastructure Readiness
c)
Struktur Organisasi Implementasi/SK Tim Pendukung
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. Berikut beberapa dokumen terkait proses Business Requirement Gathering and Analysis :
a. Undangan SK Tim Terlampir *Pemaparan Portal Aplikasi SIPP*
b. Absensi
c. Dokumentasi foto
d. Notulen Rapat
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. Berikut beberapa dokumen terkait proses 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. Berikut beberapa dokumen terkait proses Design :
a.Sketsa Design (Form Home Portal Aplikasi SIPP, Form Entri Masterdata, Form Transaksi)
b.Layout Design (Form Home Portal Aplikasi SIPP, Form Entri Masterdata, Form Transaksi)
c.Work flow proses bisnis
d.Rancangan Algoritma Program
e.Form Report (Design by Excel, Script Query, Preview Report)
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
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. Berikut beberapa dokumen terkait proses Coding/Development :
a.Script Backend & Frontend
b.Dokumentasi (Dalam bentuk capture/Screenshoot) tampilan backend & Frontend
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. Pada tahapan proses ini dokumen SIT biasanya tergantung perusahaan developer, dikarenakan template dokumen nya tidak selalu sama.
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. Contoh dokumen terkait proses UAT dapat dilihat disini :
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. Pada tahapan proses ini dokumen Data Migration biasanya tergantung perusahaan developer, dikarenakan template dokumen nya tidak selalu sama.
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/Maintenance
Untuk menjamin agar sistem berjalan bagus dan stabil setelah 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. Contoh dokumen terkait proses support maintenance :
Untuk menjamin agar sistem berjalan bagus dan stabil setelah 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. Contoh dokumen terkait proses support maintenance :
Comments
Post a Comment