PERANCANGAN MANAJEMEN PROYEK PEMBANGUNAN
PERANGKAT LUNAK SISTEM INFORMASI PELABUHAN
STUDI KASUS DI PT DYCODE COMINFOTECH
DEVELOPMENT
TESIS
Diajukan untuk memenuhi salah satu syarat ujian guna memperoleh gelar Magister Sistem Informasi
ANGGI CIPTA LESTARI
57.101.11.047
JURUSAN MAGISTER SISTEM INFORMASI
FAKULTAS PASCA SARJANA
RIWAYAT HIDUP
Nama Lengkap : Anggi Cipta Lestari
Email : anggiclestari@yahoo.com
PENDIDIKAN
1993 – 1999 : SDP Negeri Sabang Bandung 1999 – 2002 : SMP Negeri 44 Bandung
2002 – 2005 : SMA Negeri 7 Bandung 2006 – 2010 : Teknik Informatika,
Universitas Komputer Indonesia Bandung 2012 – 2014 : Magister Sistem Informasi,
v
DAFTAR ISI
Halaman
ABSTRAK………..………. i
ABSTRACT………..……… ii
KATA PENGANTAR………..………... iii
DAFTAR ISI………..……….. v
DAFTAR GAMBAR………..………. viii
DAFTAR TABEL……….………... ix
BAB I PENDAHULUAN 1.1 Latar Belakang Penelitian …….………... 1
1.2 Identifikasi Masalah...………... 2
1.3 Tujuan Penelitian………...……… 3
1.4 Manfaat Penelitian……… 3
1.5 Pembatasan Masalah………..……... 4
1.6 Sistematika Penulisan……… 5
BAB II TINJAUAN PUSTAKA 2.1 Konsep Dasar Sistem Informasi...……….………….... 7
2.2 Definisi Proyek………..……….... 8
2.3 Definisi Manajemen Proyek..………... 12
vi
2.5 Proses Pengembangan Perangkat Lunak………... 15
2.6 Program/Project Evaluation and Review Technique (PERT) dan Critical Path Method (CPM)……...………... 17
2.7 A Guide to the Project Management Body of Knowledge (PMBOK) ………...……….. 24
2.8 Function Point………...………... 26
BAB III METODOLOGI PENELITIAN 3.1 Metode Penelitian …………... 30
3.1.1 Pengumpulan Data……….………... 31
3.1.2 Ruang Lingkup Proyek ……….……… 32
3.1.3 Perancangan struktur kerja …………... 32
3.1.4 Estimasi waktu………... 33
3.1.5 Estimasi Tingkat Kompleksitas Perangkat Lunak ……... 33
3.1.6 Manajemen Resiko ………...……… 37
3.1.7 Rekomendasi….………...……… 38
BAB IV HASIL PENELITIAN DAN PEMBAHASAN 4.1 Ruang Lingkup Proyek ………….……….……… 39
4.2 Perancangan struktur kerja ……….…... 41
4.3 Estimasi waktu………... 46
4.4 Estimasi Tingkat Kompleksitas Perangkat Lunak ………….... 58
vii
4.5.1 Identifikasi Risiko ………...………... 62 4.5.2 Analisis kemungkinan dan konsekuensi risiko……… 64
4.5.3 Mitigasi Risiko………..……….. 67
BAB V KESIMPULAN DAN SARAN
5.1 Kesimpulan………...……… 71
5.2 Saran………...……….. 72
73
Daftar Pustaka
Albrecht, A., “Software Function, Source Lines of Code, and Development Effort Estimation: A Software Science Validation” IEEE Trans. Software Eng., 1983.
Boehm, B., Clark, B., Horowitz, E., Westland, C., Madachy, R., and Selby, R.,
Cost Models for Future Life Cycle Processes: COCOMO II, Science Publisher, Amsterdam, 1995
Heizer, Jay, Render, Barry, “Principles of Operations Management, 5th Ed.”, Prentice Hall, Inc., New Jersey, 2004.
Jogianto HM., MBA., Akt., Ph.D., “Analisis dan Desain Sistem Informasi”, Yogyakarta: Andi, 2005.
J. Baik, B. Boehm, and B.M. Steece, “Disaggregating and Calibrating CASE Tool Variable in COCOMO II”, IEEE vol 28 no 11, 2002.
Kerzner, H., “Project Management (9th ed.)”, USA: John Wiley & Sons, 2006. Pinto, J.K., “Project Management: Achieving Competitive Advantage, 2nd Ed.”,
Pearson, 2010.
Pressman, Roger S., “Software Engineering A Pratitioner’s Approach: 6th Ed.”, McGraw Hill, New York, 2005.
Project Management Institute, “PMBOK - A Guide to the Project Management Body of Knowledge” Newtown Square, PA: Project Management Institute,
4th edition, 2008.
Robbins, Stephen & Coulter, Mary., “Management, 8th Edition” NJ: Prentice Hall, 2007.
74 Soeharto, Iman, “Manajemen Proyek: Dari Konseptual Sampai Operasional”,
Jakarta: Erlangga, 1999.
Stoneburner, Gary et. al, “Risk Management Guide for Information Technology Systems”, U.S. Departement of Commerce, 2002.
Thomas, G. L., Ronen, B., & Edward, A. S.,“Critical Chain: A New Project Management Paradigm or Old wine in New Bottles?”, Engineering
Management Journal, 2006.
Yasmi Afrizal. 2013. Mengapa Proyek Perangkat Lunak Gagal ( Penerapan Manajemen Resiko Dalam Proyek Perangkat Lunak ), Jurnal Sistem Informasi Universitas Komputer Indonesia, Volume 19 Apr 2013
iii
KATA PENGANTAR
ميحرلا نمحرلا ه مسب
Segala puji dan syukur penulis panjatkan kepada yang dipertuhan agung Allah SWT, Raja di dunia dan akhirat, Kaisar alam semesta yang atas ijin-Nya
penulis dapat menyelesaikan penelitian dalam bentuk tesis yang berjudul:
“PERANCANGAN MANAJEMEN PROYEK PEMBANGUNAN
PERANGKAT LUNAK SISTEM INFORMASI PELABUHAN STUDI KASUS DI PT DYCODE COMINFOTECH DEVELOPMENT”. Tak lupa shalawat serta salam penulis panjatkan pada Rasulullah Muhammad SAW.
Adapun maksud dan tujuan penelitian ini yaitu untuk merencanakan pembangunan sistem informasi pelabuhan sehingga menghasilkan estimasi waktu pengerjaan proyek dan estimasi tingkat kompleksitas perangkat lunak sistem
informasi yang akan dibangun, serta mengetahui jenis-jenis risiko dan cara meminimalisasi risiko-risiko tersebut.
Selama penelitian ini, penulis tidak akan dapat menyelesaikannya tanpa bantuan dan dorongan dari berbagai pihak. Dengan kerendahan hati dan penuh rasa hormat, penulis mengucapkan banyak terima kasih kepada:
1. Mamam dan Papap, orang yang paling penulis hormati, cintai, dan banggakan diseluruh dunia; Ibu, abah, teteh, a’Lukman, ade, joy dan
iv
2. Direktorat Jendral Pendidikan Tinggi (DIKTI) yang telah memberikan kesempatan kepada penulis untuk memperoleh beasiswa untuk melanjutkan pendidikan ini;
3. Bapak Dr. Eng. Ana Hadiana selaku pembimbing I yang telah memberikan perhatian dan bimbingan kepada penulis dengan penuh
kesabaran;
4. Bapak Yasmi Afrizal, S.Kom., M.Kom selaku pembimbing II yang telah memberikan perhatian dan bimbingan kepada penulis dengan penuh
kesabaran;
5. Seluruh staf PT Dycode Cominfotech Development;
6. Teman-teman mahasiswa Program Pasca Sarjana UNIKOM, teman seperjuangan tesis, teman-teman MSI-1; Sita, Ajeng, Esson, Rani, Okeu,
finally, we did it guys! Senang berada ditengah-tengah kalian selama 2 tahun ini;
7. Irfan Aris Nur Hakim, atas kesabaran yang tidak terbatas, atas kepalan
tangan dan ungkapan ‘semangat!’-nya, dan segalanya, dan segalanya. Terima kasih banyak;
Akhirul kalam semoga tesis ini dapat bermanfaat dan menjadi keberkahan buat semuanya. Amiin Yaa Raabbal’alamiin.
Bandung, Januari 2014
1
BAB I
PENDAHULUAN
1.1 Latar Belakang Penelitian
Seiring dengan perkembangan teknologi yang begitu pesat, saat ini
teknologi informasi (TI) telah menjadi kebutuhan yang penting. Salah satu pemanfaatan teknologi informasi adalah dengan dibangunnya perangkat lunak untuk membantu proses bisnis sebuah perusahaan agar menjadi lebih efektif dan
efisien.
PT. Dycode Cominfotech Development, atau dikenal dengan sebutan Dycode, merupakan sebuah perusahaan yang bergerak di bidang teknologi
informasi (TI), khususnya dalam pengembangan perangkat lunak baik desktop,
web maupun mobile. Proyek-proyek pengembangan perangkat lunak biasa didapatkan dari perorangan maupun organisasi, organisasi swasta maupun pemerintahan.
Dalam pembangunan perangkat lunak diperlukan perencanaan yang baik
untuk mengurangi risiko-risiko yang akan terjadi saat pembangunan. Pembangunan perangkat lunak sering kali mengalami kesulitan dalam
perencanaannya, karena karakteristik perangkat lunak yang tidak sama dengan proyek fisik. Kesulitan yang sering dihadapi dalam estimasi proyek perangkat lunak berkaitan dengan sifat perangkat lunak khususnya kompleksitas dan
2 Dalam menentukan estimasi waktu pengembangan perangkat lunak, biasanya seorang manajer proyek akan membuat perkiraan dengan cara membandingkan ukuran besar dan kompleksitas perangkat lunak yang akan
dikembangkan dengan proyek serupa yang pernah dilakukan sebelumnya. Apabila manajer proyek sudah cukup berpengalaman, dalam arti sudah relatif
sering menangani proyek serupa, maka penentuan estimasi tersebut relatif tidak akan menemui kesulitan. Lain halnya apabila manajer proyek tersebut belum banyak pengalaman, maka ia akan menemui kesulitan.
Saat ini PT. Dycode Cominfotech Development mendapatkan kesempatan untuk menangani sebuah proyek sistem informasi pelabuhan. Dengan terbatasnya
waktu pelaksanaan proyek dan melihat kompleksitas perangkat lunak yang akan dikembangkan maka diperlukan manajemen proyek yang baik untuk mengelola proyek agar dapat diselesaikan dalam waktu dan biaya yang telah dianggarkan
dan juga meminimalisasi risiko-risiko yang mungkin akan terjadi.
1.2 Identifikasi Masalah
Berdasarkan latar belakang di atas, dapat dikemukakan bahwa identifikasi masalah yang muncul adalah sebagai berikut:
1. Bagaimana menentukan estimasi waktu pengerjaan pembangunan perangkat lunak sistem informasi pelabuhan tersebut.
2. Bagaimana menentukan estimasi tingkat kompleksitas perangkat lunak
3 3. Bagaimana mengidentifikasi risiko yang mungkin terjadi saat pelaksanaan
proyek dan bagaimana cara meminimalisasi risiko-risiko tersebut.
1.3 Tujuan Penelitian
Tujuan dari dilakukan penelitian ini adalah:
1. Menghasilkan estimasi waktu pengerjaan proyek pembangunan perangkat
lunak sistem informasi pelabuhan.
2. Menghasilkan estimasi tingkat kompleksitas perangkat lunak sistem informasi pelabuhan yang akan dibangun tersebut.
3. Mengetahui jenis-jenis risiko yang mungkin akan dihadapi saat pelaksanaan proyek dan cara meminimalisasi risiko-risiko tersebut.
1.4 Manfaat Penelitian
Adapun manfaat yang dapat diambil dari penelitian ini adalah:
1. Hasil penelitian dapat menjadi model acuan bagi PT. Dycode Cominfotech Development untuk melakukan manajemen proyek perangkat lunak lainnya di masa mendatang.
4 1.5 Pembatasan Masalah
Untuk melaksanakan penelitian yang terarah, maka diperlukan batasan masalah agar memudahkan dalam pembahasan dan tujuan penelitian dapat
tercapai. Berikut ini merupakan batasan-batasan masalah dalam penelitian:
1. Penelitian didasarkan pada studi kasus di PT. Dycode Cominfotech
Development.
2. Metode penelitian pada penelitian ini mengacu pada pedoman manajemen proyek A Guide to the Project Management Body of Knowledge
(PMBOK).
3. Manajemen proyek tidak meliputi proyek perangkat keras (hardware) dan jaringan.
4. Manajemen proyek pada penelitian ini dibatasi pada penentuan estimasi
jadwal, estimasi tingkat kompleksitas perangkat lunak dan manajemen risiko.
5. Metode yang akan digunakan dalam proses estimasi jadwal adalah
Program/Project Evaluation and Review Technique (PERT) dan Critical Path Method (CPM).
5 1.6 Sistematika Penulisan
Berikut merupakan sistematika penulisan dalam penelitian ini yaitu:
BAB I PENDAHULUAN
Bab I berisi mengenai latar belakang penelitian, identifikasi masalah, tujuan penelitian, manfaat penelitian, pembatasan masalah dan asumsi
serta sistematika penulisan.
BAB II TINJAUAN PUSTAKA
Di dalam bab ini, akan dibahasa mengenai dasar-dasar teori dan tinjauan
pustaka yang menunjang terhadap penelitian yang dilakukan.
BAB III METODOLOGI PENELITIAN
Bab ini menjelaskan tentang metodologi penelitian yang digunakan pada penelitian serta metode pengumpulan data yang digunakan yaitu studi
pustaka, wawancara dan observasi.
BAB IV HASIL PENELITIAN DAN PEMBAHASAN
Bab ini menampilkan pembahasan dari manajemen proyek pembangunan
perangkat lunak sistem informasi pelabuhan di PT. Dycode Cominfotech Development agar dapat diketahui estimasi biaya untuk pembangunan
6 BAB V KESIMPULAN DAN SARAN
Bab ini berisi kesimpulan dan saran dari hasil penelitian dan pembahasan dari manajemen proyek pembangunan perangkat lunak sistem informasi
7
BAB II
TINJAUAN PUSTAKA
2.1 Konsep Dasar Sistem Informasi
Dalam perancangan suatu sistem informasi diarahkan kepada
pemanfaatan teknologi secara maksimal yang terdiri dari beberapa elemen atau komponen yang membentuk jaringan kerja dan mempunyai tujuan yang ingin dicapai. Pendekatan yang menekankan pada prosedur, mendefinisikan sebuah
sistem sebagai suatu kesatuan dari beberapa komponen atau subsistem yang saling berinteraksi untuk mencapai suatu tujuan tertentu (Jogianto, 2005).
Suatu sistem dapat terdiri dari sistem bagian (subsystems). Sebagai misal, sistem komputer dapat terdiri dari subsistem yang lebih kecil lagi atau terdiri dari komponen-komponen. Subsistem perangkat keras (hardware) dapat terdiri dari alat masukkan, alat pemroses, alat keluaran dan simpanan luar. Subsistem-subsistem saling berinteraksi dan saling berhubungan membentuk satu kesatuan hingga tujuan/sasaran sistem tersebut dapat tercapai. Interaksi dari
subsistem-subsistem sedemikian rupa, sehingga dicapai suatu kesatuan yang terpadu atau terintegrasi.
8 Informasi merupakan hal yang sangat penting didalam mengambil keputusan. Informasi tersebut didapatkan dari sistem informasi atau disebut juga dengan processing systems atau information processing systems atau information generating systems. Sistem informasi merupakan suatu sistem didalam suatu organisasi yang mempertemukan kebutuhan pengolahan transaksi, mendukung
operasional, bersifat manajerial dan kegiatan strategi dari suatu organisasi dan menyediakan pihak luar tertentu dengan laporan-laporan yang diperlukan (Jogianto, 2005).
2.2 Definisi Proyek
Proyek dalam bisnis dan ilmu pengetahuan biasanya didefinisikan sebagai
sebuah usaha kolaboratif dan juga seringkali melibatkan penelitian atau desain, yang direncanakan untuk mencapai tujuan tertentu. Proyek dapat juga didefinisikan sebagai usaha sementara, temporer, dan bukan permanen, yang
memiliki sasaran khusus dengan waktu pelaksanaan yang tegas.
Proyek merupakan usaha sementara yang dilakukan untuk menciptakan
sebuah produk atau jasa yang unik. Kata sementara digunakan untuk membedakan proyek dengan produksi karena setiap proyek memiliki waktu
mulai dan waktu akhir yang pasti. Keberhasilan proyek berarti proyek memberikan pelayanan terhadap apa yang diinginkan, harga yang telah disepakati dan memiliki tim proyek yang berusaha menciptakan kesuksesan itu (PMI, 2008).
Secara umum proyek dapat didefinisikan sebagai suatu rangkaian pekerjaan atau usaha yang memiliki keterbatasan waktu, anggaran, sumber daya,
9 Proyek dinyatakan berhasil apabila memenuhi kebutuhan setiap orang yang memiliki kepentingan dalam proyek yang mencakup tiga kondisi yaitu scope, cost dan schedule. Ketiga kondisi tersebut saling berkaitan satu sama lain,
semakin lama sebuah proyek berlangsung maka semakin besar biaya yang dibutuhkan, semakin banyak biaya dalam proses proyek maka semakin lama juga
waktu yang dibutuhkan, semakin lama sebuah proyek berlangsung maka semakin banyak peluang yang ada untuk mengubah ruang lingkup dan semakin banyak perubahan luang lingkup maka akan membutuhkan biaya yang lebih banyak juga
dan meningkatkan jadwal.
Berdasarkan pengertian proyek di atas, ciri-ciri proyek antara lain:
a. Memiliki tujuan tertentu berupa hasil kerja akhir. b. Sifatnya sementara karena siklus proyek relatif pendek.
c. Dalam proses pelaksanaannya, proyek dibatasi oleh jadwal, anggaran
biaya, dan mutu hasil akhir.
d. Merupakan kegiatan nonrutin, tidak berulang-ulang.
e. Keperluan sumber daya berubah, baik macam maupun volumenya. Proyek dapat dikelompokkan menjadi beberapa jenis, yaitu:
a. Proyek Engineering-Konstruksi
10 b. Proyek Engineering-Manufaktur
Dimaksudkan untuk membuat produk baru, meliputi pengembangan produk, manufaktur, perakitan, uji coba fungsi dan operasi produk yang
dihasilkan.
c. Proyek Penelitian dan Pengembangan
Bertujuan untuk melakukan penelitian dan pengembangan dalam rangka menghasilkan produk tertentu.
d. Proyek Pelayanan Manajemen
Proyek pelayanan manajemen tidak memberikan hasil dalam bentuk fisik, tetapi laporan akhir, misalnya merancang sistem informasi manajemen.
e. Proyek Kapital
Proyek kapital merupakan proyek yang berkaitan dengan penggunaan dana kapital untuk investasi.
f. Proyek Radio-Telekomunikasi
Bertujuan untuk membangun jaringan telekomunikasi yang dapat
menjangkau area yang luas dengan biaya minimal. g. Proyek Konservasi Bio-Diversity
Proyek konservasi bio-diversity merupakan proyek yang berkaitan dengan usaha pelestarian lingkungan.
Kegiatan-kegiatan dalam sebuah proyek berlangsung dari titik awal,
11 Gambar 2.1 Hubungan Keperluan Sumber Daya Terhadap Waktu dalam Siklus Proyek
(Soeharto, 1999)
Salah satu sistematika penahapan yang disusun oleh PMI (Project
Management Institute) terdiri dari tahap-tahap konseptual, perencanaan dan pengembangan (PP/Definisi), implementasi, dan terminasi (PMI, 2008).
a. Tahap Konseptual
Dalam tahap konseptual, dilakukan penyusunan dan perumusan gagasan, analisis pendahuluan, dan pengkajian kelayakan. Deliverable akhir pada tahap ini
adalah dokumen hasil studi kelayakan. b. Tahap PP/Definisi
Kegiatan utama dalam tahap PP/Definisi adalah melanjutkan evaluasi hasil kegiatan tahap konseptual, menyiapkan perangkat (berupa data, spesifikasi teknik, engineering, dan komersial), menyusun perencanaan dan membuat
12 ini adalah dokumen hasil analisis lanjutan kelayakan proyek, dokumen rencana strategis dan operasional proyek, dokumen anggaran biaya, jadwal induk, dan garis besar kriteria mutu proyek.
c. Tahap Implementasi
Pada umumnya, tahap implementasi terdiri dari kegiatan
desain-engineering yang rinci dari fasilitas yang hendak dibangun, pengadaan material dan peralatan, manufaktur atau pabrikasi, dan instalasi atau konstruksi. Deliverable akhir pada tahap ini adalah produk atau instalasi proyek yang telah
selesai.
d. Tahap Terminasi
Kegiatan pada tahap terminasi antara lain mempersiapkan instalasi atau produk beroperasi (uji coba), penyelesaian administrasi dan keuangan lainnya. Deliverable akhir pada tahap ini adalah instalasi atau produk yang siap beroperasi
dan dokumen pernyataan penyelesaian masalah asuransi, klaim, dan jaminan. e. Tahap Operasi atau Utilitas
Dalam tahap ini, kegiatan proyek berhenti dan organisasi operasi mulai bertanggung jawab atas operasi dan pemeliharaan instalasi atau produk hasil
proyek.
2.3 Definisi Manajemen Proyek
Manajemen proyek adalah ilmu dan seni yang berkaitan dengan
13 sasaran yang telah ditentukan, yaitu lingkup, mutu, jadwal, dan biaya, serta memenuhi keinginan para stake holder (PMI, 2008).
Dalam manajemen proyek, penentuan waktu penyelesaian kegiatan ini
merupakan salah satu kegiatan awal yang sangat penting dalam proses perencanaan karena penentuan waktu tersebut akan menjadi dasar bagi
perencanaan yang lain, yaitu (Schwalbe, 2007):
1. Penyusunan jadwal (scheduling), anggaran (budgeting), kebutuhan sumber daya manusia (manpower planning), dan sumber organisasi yang
lain.
2. Proses pengendalian (controlling).
Manajemen Proyek meliputi tiga fase, yaitu: a. Perencanaan
Fase ini mencakup penetapan sasaran, mendefinisikan proyek, dan
organisasi timnya. b. Penjadwalan
Fase ini menghubungkan orang, uang, dan bahan untuk kegiatan khusus dan menghubungkan masing-masing kegiatan satu dengan yang lainnya.
c. Pengendalian
Perusahaan mengawasi sumber daya, biaya, kualitas, dan anggaran. Perusahaan juga merevisi atau mengubah rencana dan menggeser atau
14 Adapun tujuan dari manajemen proyek seperti yang dinyatakan oleh adalah sebagai berikut:
a. Tepat waktu (on time)
yaitu waktu atau jadwal yang merupakan salah satu sasaran utama proyek, keterlambatan akan mengakibatkan kerugian, seperti penambahan biaya,
kehilangan kesempatan produk memasuki pasar. b. Tepat anggaran (on budget)
yaitu biaya yang harus dikeluarkan sesuai dengan anggaran yang telah
ditetapkan.
c. Tepat spesifikasi (on specification)
dimana proyek harus sesuai dengan spesifikasi yang telah ditetapkan.
2.4 Manajemen Waktu Proyek
Manajemen waktu proyek adalah semua proses yang terdiri dari
pemenuhan waktu proyek sesuai dengan yang telah ditentukan. Manajemen waktu proyek terdiri dari beberapa proses, antara lain:
1. Pendefinisian Aktivitas
Didalam proses ini terdapat proses mengidentifikasi tindakan spesifik
yang akan dilakukan untuk menghasilkan penyaluran proyek. 2. Proses Pengurutan Aktivitas
Proses mengidentifikasi dan mendokumentasikan keterkaitan antar
15 3. Proses Perkiraan Sumber Daya Aktivitas.
Proses memperkirakan tipe dan kuantitas dari material, pekerja, peralatan dan perbekalan yang dibutuhkan untuk melaksanakan setiap aktivitas.
4. Proses Prkiraan Durasi Aktivitas
Proses perkiraan jumlah periode waktu kerja yang dibutuhkan untuk
menyelesaikan aktivitas tunggal dengan sumber daya yang telah diperkirakan.
5. Proses Pembuatan Jadwal
Proses menganalisa urutan pekerjaan, jangka waktu, persyaratan, sumber daya dan kendala jadwal untuk membuat jadwal proyek.
6. Proses Pengendalian Jadwal
Proses pemantauan status proyek untuk memperbarui kemajuan proyek dan mengelola perubahan pada jadwal yang telah ditentukan sebelumnya.
2.5 Proses Pengembangan Perangkat Lunak
RUP, singkatan dari Rational Unified Process, adalah suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, suatu divisi dari IBM sejak 2003. RUP bukanlah suatu proses tunggal dengan aturan yang konkrit, melainkan suatu kerangka proses yang dapat diadaptasi dan dimaksudkan untuk disesuaikan oleh organisasi pengembang dan tim proyek perangkat lunak yang akan memilih elemen proses sesuai dengan
kebutuhan mereka. (Wikipedia, 2013)
Dengan mengombinasikan pengalaman dari banyak perusahaan,
16 1. Pengembangan iteratif, dengan risiko sebagai pemicu iterasi primer 2. Kelola persyaratan
3. Terapkan arsitektur yang berbasis komponen
4. Visualisasikan model perangkat lunak 5. Secara kontinyu, verifikasi kualitas
6. Kendalikan perubahan
Pada RUP didefinisikan terdapat empat fasa siklus proyek. Fasa-fasa ini memungkinkan untuk disajikan dalam bentuk umum mirip dengan pendekatan air
terjun, walaupun esensi kunci dari proses terdapat dalam iterasi dalam setiap fasenya. Setiap fase memiliki sebuah objektif kunci dan titik pencapaian akhir
yang menandakan ketercapaian objektif. Visualisasi dari fase RUP berikut dengan sumbu waktu dinamakan sebagai grafik RUP hump. (Wikipedia, 2013)
1. Fasa Insepsi
Objektif primer adalah untuk membatasi sistem dengan cukup sebagai dasar untuk memvalidasi biaya awal dan penganggaran. Pada fasa ini,
ditentukan kasus bisnis yaitu: konteks bisnis, faktor sukses (perkiraan pendapatan, pengenalan ke pasar, dan lain-lain), dan perkiraan finansial.
Sebagai pelengkap kasus bisnis adalah model penggunaan, perencaan proyek, penilaian risiko tahap awal, dan deskripsi proyek disusun.
2. Fasa Elaborasi
17 mulai terlihat bentuknya. Pada fase ini, masalah analisis domain dibuat dan arsitektur proyek mulai mendapatkan bentuk dasarnya.
3. Fasa Konstruksi
Objektif primer adalah untuk membangun sistem perangkat lunak. Fase ini fokus pada pengembangan komponen dan fitur lain dari sistem. Pada
fase inilah saat banyak dilakukan pengkodean. Pada proyek yang lebih besar, beberapa iterasi konstruksi dikembangkan sebagai usaha untuk memecah kasus penggunaan menjadi segmen terkelola yang menunjukkan
purwarupa. 4. Fasa Transisi
Objektif primer adalah sebagai perantara sistem dari pengembangan ke produksi, yang tersedia untuk pengguna akhir. Aktivitas dalam fase ini termasuk pelatihan kepada pengguna akhir dan pengelola sistem dan
pengujian beta untuk memvalidasi terhadap harapan pengguna akhir.
2.6 Program/Project Evaluation and Review Technique (PERT) dan Critical Path Method (CPM)
PERT atau Project Evaluation and Review Technique adalah sebuah model Management Science untuk perencanaan dan pengendalian sebuah proyek. Teknik PERT (Project Evaluation and Review Technique) adalah suatu metode yang bertujuan untuk mengurangi adanya penundaan, maupun gangguan
produksi, serta mengkoordinasikan berbagai bagian suatu pekerjaan secara menyeluruh dan mempercepat selesainya proyek. Teknik ini memungkinkan
18 anggaran dari suatu pekerjaan telah ditentukan terlebih dahulu sebelum dilaksanakan. Dalam PERT digunakan distribusi peluang berdasarkan tiga perkiraan waktu untuk setiap kegiatan, antara lain waktu optimis, waktu pesimis,
dan waktu realistis.
Waktu optimis adalah perkiraan waktu yang mempunyai kemungkinan
yang sangat kecil untuk dapat dicapai, kemungkinan terjadinya hanya satu kali dari 100. Waktu pesimis adalah suatu perkiraan waktu yang lain yang mempunyai kemungkinan sangat kecil untuk dapat direalisasikan, kemungkinan
terjadinya juga hanya satu kali dalam 100, sedangkan waktu realistis atau waktu yang paling mungkin adalah waktu yang berdasarkan pikiran estimator. Perkiraan
waktu optimis biasanya dinyatakan oleh huruf a, waktu realistis oleh huruf m, dan waktu pesimis dinyatakan oleh huruf b.
Ada beberapa hal perlu diperhatikan dalam menentukan angka estimasi,
diantaranya (PMI, 2008):
1. Estimator perlu mengetahui fungsi dari a, m, dan b dalam hubungannya
dengan perhitungan-perhitungan dan pengaruhnya terhadap metode PERT.
2. Di dalam proses estimasi angka-angka a, m, dan b bagi masing-masing kegiatan, jangan sampai dipengaruhi atau dihubungkan dengan target kurun waktu penyelesaian proyek.
3. Bila tersedia data-data pengalaman masa lalu (historical record), maka data demikian akan berguna untuk bahan pembanding dan banyak
19 Dari kurva distribusi pada gambar 2.2 dapat dijelaskan arti a, b, dan m. Kurva waktu yang menghasilkan puncak kurva adalah m. Kurva a dan b terletak di pinggir kanan kiri dari kurva distribusi, yang menandai batas rentang waktu
kegiatan.
Gambar 2.2 Tiga Macam Taksiran Waktu pada Distribusi Beta (Siswanto, 2007)
Ketiga angka perkiraan waktu tadi, yaitu a, b, m, dihubungkan menjadi satu angka yang disebut te atau kurun waktu yang diharapkan. Angka te adalah
angka rata-rata jika kejadian tersebut dikerjakan berulang dalam jumlah besar. Dalam menentukan angka te dipakai asumsi bahwa kemungkinan terjadinya
peristiwa optimis (a) dan pesimis (b) adalah sama, sedangkan jumlah waktu yang paling mungkin (m) adalah 4 kali lebih besar dari dua peristiwa lainnya.
20 Metode Jalur Kritis (Critical Path Method - CPM), yakni metode untuk merencanakan dan mengawasi proyek-proyek serta merupakan sistem yang paling banyak dipergunakan diantara semua sistem lain yang memakai prinsip
pembentukan jaringan. Dengan CPM, jumlah waktu yang dibutuhkan untuk menyelesaikan berbagai tahap suatu proyek dianggap diketahui dengan pasti,
demikian pula hubungan antara sumber yang digunakan dan waktu yang diperlukan untuk menyelesaikan proyek. CPM adalah model manajemen proyek yang mengutamakan biaya sebagai objek yang dianalisis. CPM merupakan
analisa jaringan kerja yang berusaha mengoptimalkan biaya total proyek melalui pengurangan atau percepatan waktu penyelesaian total proyek yang
bersangkutan.
Network planning (Jaringan Kerja) pada prinsipnya adalah hubungan ketergantungan antara bagian-bagian pekerjaan yang digambarkan atau
divisualisasikan dalam diagram network. Dengan demikian dapat dikemukakan bagian-bagian pekerjaan yang harus didahulukan, sehingga dapat dijadikan dasar
untuk melakukan pekerjaan selanjutnya dan dapat dilihat pula bahwa suatu pekerjaan belum dapat dimulai apabila kegiatan sebelumnya belum selesai
dikerjakan.
Simbol-simbol yang digunakan dalam menggambarkan suatu network
adalah sebagai berikut:
a. Anak Panah mewakili sebuah kegiatan atau aktivitas yaitu tugas yang dibutuhkan oleh proyek. Kegiatan di sini didefinisikan sebagai hal yang
21 (sumber tenaga, peralatan, material, biaya). Kepala anak panah menunjukkan arah tiap kegiatan, yang menunjukkan bahwa suatu kegiatan dimulai pada permulaan dan berjalan maju sampai akhir dengan arah dari
kiri ke kanan. Baik panjang maupun kemiringan anak panah ini sama sekali tidak mempunyai arti. Jadi, tak perlu menggunakan skala.
b. Lingkaran Kecil atau Node mewakili sebuah kejadian atau peristiwa atau event. Kejadian didefinisikan sebagai ujung atau pertemuan dari satu atau beberapa kegiatan. Sebuah kejadian mewakili satu titik dalam waktu yang
menyatakan penyelesaian beberapa kegiatan dan awal beberapa kegiatan baru. Titik awal dan akhir dari sebuah kegiatan karena itu dijabarkan
dengan dua kejadian yang biasanya dikenal sebagai kejadian kepala dan ekor. Kegiatan-kegiatan yang berawal dari saat kejadian tertentu tidak dapat dimulai sampai kegiatan-kegiatan yang berakhir pada kejadian yang
sama diselesaikan. Suatu kejadian harus mendahulukan kegiatan yang keluar dari simpul/node tersebut.
c. Anak panah putus-putus menyatakan kegiatan semu atau dummy activity. Setiap anak panah memiliki peranan ganda dalam mewakili kegiatan dan
22 d. Anak panah tebal merupakan kegiatan pada lintasan kritis.
Dalam penggunaannya, simbol-simbol ini digunakan dengan mengikuti aturan-aturan sebagai berikut:
a. Di antara dua kejadian yang sama, hanya boleh digambarkan satu anak panah.
b. Nama suatu aktivitas dinyatakan dengan huruf atau dengan nomor kejadian.
c. Aktivitas harus mengalir dari kejadian bernomor rendah ke kejadian
bernomor tinggi.
d. Diagram hanya memiliki sebuah saat paling cepat dimulainya kejadian
23 Tabel 2.1 Perbandingan Dua Pendekatan Menggambarkan Jaringan Kerja (Principles of
Operations Management, 2004)
Pada prinsipnya yang menyangkut perbedaan PERT dan CPM adalah
sebagai berikut:
1. PERT digunakan pada perencanaan dan pengendalian proyek yang belum pernah dikerjakan, sedangkan CPM digunakan untuk menjadwalkan dan
24 2. Pada PERT digunakan tiga jenis waktu pengerjaan yaitu yang tercepat,
terlama serta terlayak, sedangkan pada CPM hanya memiliki satu jenis informasi waktu pengerjaan yaitu waktu yang paling tepat dan layak
untuk menyelesaikan suatu proyek.
3. Pada PERT yang ditekankan tepat waktu, sebab dengan penyingkatan
waktu maka biaya proyek turut mengecil, sedangkan pada CPM menekankan tepat biaya.
4. Dalam PERT anak panah menunjukkan tata urutan (hubungan
presidentil), sedangkan pada CPM tanda panah adalah kegiatan. Diagram PERT digambarkan seperti gambar 2.4.
Gambar 2.4 Diagram PERT (Wikipedia, 2006)
Dimana:
Early Start : Waktu tercepat untuk memulai kegiatan
Duration : Durasi kegiatan
Early Finish : Waktu tercepat selesai kegiatan
Task Name : Nama Kegiatan
Late Start : Waktu terlama untuk memulai kegiatan
Slack : Waktu tunda yang diperbolehkan
LateFinish : Waktu terlama selesai kegiatan
2.7 A Guide to the Project Management Body of Knowledge (PMBOK)
25 oleh para professional dalam manajemen proyek. PMBOK merupakan standar yang ditetapkan oleh American National Standard tentang aplikasi pengetahuan, keterampilan, alat-alat, dan teknik untuk memenuhi keperluan proyek yang
diterbitkan oleh Project Management Institute (PMI). Project Management Institute (PMI) adalah sebuah institusi di Amerika yang sengaja dibentuk untuk memfasilitasi perkembangan manajemen proyek. (PMI, 2008).
Di dalam PMBOK terdiri atas 44 proses yang dibagi menjadi 5 proses utama dalam life cycle proyek yaitu initiating, planning, executing, controlling and monitoring, closing dan 9 area pengetahuan tentang proyek (integration, scope, time, cost, quality, human resources, communications, risks, procurement). Lima tahap proses dalam PMBOK menerapkan variasi dari
Deming Cycle untuk peningkatan yang berkelanjutan. Dalam membuat penjadwalan proyek, PMBOK menjelaskan penggunaan metode yang disebut
26 Gambar 2.5 Project Management Process Group and Knowledge Areas
Sumber: PMBOK 4th Edition, 2008
2.8 Function Point
27
analysis (FPA) adalah takaran tidak langsung untuk ukuran fungsional suatu sistem.
Function Point Analysis dikembangkan pertama kali oleh Allan J. Albrecht di pertengahan 1970 dengan tujuan mencoba menyelesaikan kesulitan terkait dengan Line of Code (LOC), dan membantu dalam pengembangan sebuah mekanisme untuk meramalkan beban (effort) terkait dengan pengembangan perangkat lunak. Function Point pertama dipublikasikan pada tahun 1979, kemudian tahun 1983. Tahun 1984, Albrecht memperbaiki metode ini dan sejak
1986, ketika International Function Point User Group (IFPUG) dibentuk, beberapa versi Function Point Counting Practices Manual diterbitkan oleh IFPUG. (Albrecht, 1983).
Dalam metode Function Points, ukuran sebuah sistem dapat dihitung dengan 3 komponen, yaitu information processing size (Unadjusted Function Points-UFP), Technical complexity adjustment factors, dan Function Points.
Function Point di dalam sebuah perangkat lunak diidentifikasi dan dikategorikan ke dalam salah satu dari lima tipe fungsi pengguna, yaitu: External Input (EI), External Outputs (EO), Internal Logical File (ILF), External Interface Files (EIF) dan External Inquiry (EQ), kemudian dinilai kompleksitasnya dan diberi sejumlah nilai Function Points.
28
External Outputs (EO) merupakan sebuah proses dasar dimana hasil data dilewatkan dari dalam ke keluar dari batasan aplikasi, contohnya aplikasi menghasilkan berkas XML atau CSV. External Outputs menampilkan informasi melalui logika pemrosesan, tidak hanya mengambil data. External Outputs dapat berupa data laporan atau output file yang dikirim ke aplikasi lain. Laporan dan file tersebut dibuat dari satu atau lebih Internal Logical File (ILF) dan External Interface Files (EIF).
Fungsi utama External Inquiry (EQ) adalah menyediakan informasi ke
user melalui pengambilan atau pemrosesan data atau informasi kontrol dari
Internal Logical File (ILF) atau External Interface Files (EIF). Tampilan beberapa tipe laporan dan pencarian merupakan komponen yang tepat untuk
External Inquiry. External Inquiry tidak mengubah ILF atau EIF, hanya mengambil data untuk ditampilkan.
Internal Logical File (ILF) adalah kelompok data atau kelompok informasi kontrol yang digunakan dalam aplikasi. Peran utama ILF yaitu
menyimpan data yang dipelihara oleh satu atau lebih proses dalam aplikasi, contohnya tabel, file dan informasi kontrol seperti user preferences.
External Interface File (EIF) adalah kelompok data berelasi atau informasi kontrol yang dirujuk oleh aplikasi, tapi dipelihara oleh aplikasi lain. Sebuah External Interface File yang dihitung untuk sebuah aplikasi harus merupakan Internal Logical File di aplikasi lain.
Setiap bagian dari tipe fungsi kemudian diklasifikasikan berdasarkan 3
29 menentukan bobot yang akan diaplikasikan pada jumlah fungsi untuk menentukan kuantitas Unadjusted Function Points (UFP). Adapun kriteria yang menentukan ketiga tingkatan kompleksitas, dapat dilihat pada tabel 2.2.
Tabel 2.2 Kriteria Tingkatan Kompleksitas
Tingkat
Kompleksitas Kriteria
Simple
1. Waktu yang diperlukan untuk pengerjaan sebentar 2. Jumlah sub menu sedikit
3. Dapat dikerjakan oleh 1 orang
Average
1. Waktu yang diperlukan untuk pengerjaan rata-rata 2. Jumlah sub menu rata-rata
3. Dapat dikerjakan oleh 1 orang walau memakan waktu agak lama dari seharusnya
Complex
1. Waktu yang diperlukan untuk pengerjaan lama 2. Jumlah sub menu banyak
3. Harus dikerjakan bersama-sama
39
BAB IV
HASIL PENELITIAN DAN PEMBAHASAN
4.1 Ruang Lingkup Proyek
Rational Unified Process (RUP), suatu kerangka kerja proses pengembangan perangkat lunak iteratif yang dibuat oleh Rational Software, salah satu divisi dari IBM memdefinisikan terdapat 4 (empat) tahapan dalam pembangunan perangkat lunak,yaitu:
1. Tahap Inception merupakan tahap awal dimana akan dilakukan pembuatan jadwal pengerjaan dan anggaran biaya serta analisis risiko yang akan terjadi.
2. Tahap Elaboration merupakan tahap dimana akan dilakukan analisis sistem yang sedang berjalan pada saat ini.
3. Tahap Construction merupakan tahap pembangunan sistem.
4. Tahap Transition merupakan tahapan sistem telah selesai dibangun dan dilakukan pengetesan oleh user.
Sistem yang akan dibangun adalah Sistem Informasi Pelabuhanuntuk digunakan dalam manajemen terminal petikemas dan bertujuan untuk
meningkatkan pelayanan kepada pengguna jasa, efisiensi dan kelancaran manajemen pengelolaan operasional, keuangan dan sumber daya manusia (SDM).
40 bongkar petikemas merupakan proses penerimaan petikemas dari kapal sampai ke lapangan dan kemudian dapat diambil oleh agen yang bersangkutan. Alur muat petikemas merupakan proses penerimaan petikemas dari agen untuk disimpan di
lapangan atau langsung dimuat ke kapal.
Pada kedua alur tersebut terdapat beberapa proses seperti pra-pelayanan,
perencanaan penggunaan lapangan penumpukan, realisasi manajemenpetikemas, pelayanan perpindahan petikemas, sistem antrian pada gate, penghitungan jasa, pengaturan anggaran dan monitoring.Pra-pelayanan jasa bongkar muat
petikemasmerupakan perencanaan untuk bongkar muat petikemas.Perencanaan penggunaan lapangan penumpukanmerupakan perencanaan alokasi petikemas
pada lapangan.Realisasi manajemenpetikemas merupakan pencatatan proses bongkar muat petikemas dengan keadaan yang sebenarnya. Pelayanan perpindahan petikemas merupakan suatu keadaan dimana petikemas dipindahkan
dari kapal yang satu ke kapal yang lainnya atau perpindahan alokasi pada lapangan. Sistem antrian pada gate merupakan sistem antrian petikemas yang akan dimuat atau dibongkar sebelum masuk gate atau ketika akan keluar dari
gate sehingga data petikemas yang masuk dan keluar tercatat dengan baik.Penghitungan jasa merupakan perhitungan jumlah biaya yang digunakan dalam penggunaan jasa bongkar atau muat. Monitoring merupakan proses memonitor kegiatan yang terjadi dilapangan, menampilkan data kondisi dermaga,
41 4.2 Perancangan struktur kerja
Perancangan struktur kerja merupakan rincian kegiatan-kegiatan yang telah dideskripsikan pada tahap sebelumnya dan dipecah menjadi bagian-bagian
yang lebih kecil lagi. Perancangan struktur kerja ini nantinya akan menjadi acuan untuk penjadwalan proyek.
Rincian kegiatan dalam pembangunan sistem informasi pelabuhan disusun berdasarkan 4 tahapan pembangunan perangkat lunak, yaitu Inception,
42 Tabel 4.1 Rincian Struktur Kerja
No Tahap Kode
Kegiatan Nama Kegiatan Nama Sub Kegiatan
1 Inception A1 Pembuatan jadwal dan penganggaran
A2 Penilaian risiko
2 Elaboration B1 Survey lapangan
B2 Wawancara dengan client tentang alur proses dilapangan
B3 Pengambilan data-data yang diperlukan dalam rencana pembuatan desain aplikasi
B4 Pembuatan dokumen SRS (Software Requirement Specification)
B5 Pembuatan dokumen SDD (Software Design Document)
3 Construction Pembangunan Aplikasi, yang terdiri dari:
C11 Pra-pelayanan Perancanaan Kedatangan Kapal
C12 Perencanaan Alokasi Lapangan
C13 Perencanaan Perpindahan Kapal
C14 Perencanaan Perpindahan Alokasi
C21 Kegiatan pada Kapal Konfirmasi Kedatangan dan Memulai Layanan pada Kapal
C22 Konfirmasi Bongkar Petikemas
C23 Konfirmasi MuatPetikemas
C24 Konfirmasi Perpindahan Kapal
C25 Konfirmasi Buka dan Tutup Palka
C26 Konfirmasi Selesai Layanan pada Kapal
C31 Kegiatan pada Lapangan Konfirmasi Penempatan Petikemas di Lapangan
43
No Tahap Kode Kegiatan Nama Kegiatan Nama Sub Kegiatan
3 Construction C41 Kegiatan pada Gate Konfirmasi Petikemas Keluar dari Gate
C42 Konfirmasi Petikemas Masuk Melalui Gate
4 Transition D1 Deploy keseluruhan aplikasi ke server
D2 Penyesuaian integrasi aplikasi yang dibangun
5 Production E1 Pembuatan dokumentasi akhir proyek
E2 Garansi aplikasi selama 3 bulan (maintanance)
44 4.3 Estimasi Waktu
Berdasarkan rancangan struktur kerja yang telah disusun sebelumnya, maka dapat dibuat jadwal pengerjaan kegiatan.Pada hasil penjadwalan proyek
sistem informasi pelabuhan ini berdasarkan hasil diskusi dengan pihak perusahaan terdapat hubungan antar aktivitas atau kegiatan yang dapat dilihat
pada tabel 4.2. Pada hubungan antar kegiatan dapat dilihat lintasan kritis proyek dan hubungan keterkaitan dari setiap pekerjaan.
Tabel 4.2 Hubungan antar kegiatan
No Kode Kegiatan Durasi Predecessor
45
No Kode Kegiatan Durasi Predecessor
26 C41 3 d C38
Hubungan antar kegiatan dapat juga digambarkan dengan diagram node
46
47 Berdasarkan data hubungan keterkaitan antar kegiatan dapat diketahui jalur kritis (critical path) di dalam penjadwalan terdapat lebih dari satu. Berikut ini adalah kombinasi critical path yang ada di dalam penjadwalan:
1. A1-B3-B4-B5-C11-C12-C21-C24-C26-C31-C37-C38-C41-C51-C52-C53-C54-C55-C56-C61-C63-D1-D2-D3-D4-D5-D6-D7-D8-E1-E2-E3.
2. A2-B3-B4-B5-C11-C12-C21-C24-C26-C32-C37-C38-C41-C51-C52-C53-C54-C55-C56-C61-C64-D1-D2-D3-D4-D5-D6-D7-D8-E1-E2-E3. 3.
A1-B3-B4-B5-C11-C12-C21-C24-C26-C31-C37-C38-C42-C51-C52-C53-C54-C55-C56-C62-C63-D1-D2-D3-D4-D5-D6-D7-D8-E1-E2-E3. 4.
A2-B3-B4-B5-C11-C12-C21-C24-C26-C32-C37-C38-C42-C51-C52-C53-C54-C55-C56-C62-C64-D1-D2-D3-D4-D5-D6-D7-D8-E1-E2-E3. Hasil perhitungan dari kombinasi critical path untuk penjadwalan adalah 204 days.
49 Selain kegiatan dan durasi, untuk menentukan hubungan antar kegiatan juga berdasarkan ketergantungan kegiatan dan sumber daya. Sumber daya yang terlibat di dalam proyek ini adalah:
1. Manajer Proyek 1 Orang (MP) 2. Sistem Analis 1 Orang (SA)
3. Aplikasi Desainer 1 Orang (AD) 4. Database Administrator 1 Orang (DA)
5. Technical Leader 1 Orang (TL) 6. Quality Assurance (QA) atau tester 7. Programmer4 Orang (P)
8. Dokumentasi 1 Orang (D)
Jadwal kegiatan disusun berdasarkan tahapan pengerjaan proyek dan sumber daya yang terlibat dalam pengerjaan kegiatan.
1. Tahap Inception
1.1 Pembuatan jadwal dan penganggaran
Sumber daya yang dibutuhkan: Manajer Proyek. 1.2 Penilaian risiko
Sumber daya yang dibutuhkan: Manajer Proyek. 2. Tahap Elaboration
2.1 Survey lapangan
50 2.2 Wawancara dengan client tentang alur proses dilapangan
Sumber daya yang dibutuhkan: Manajer Proyek, Technical Leader, Sistem Analis.
2.3 Pengambilan data-data yang diperlukan dalam rencana pembuatan desain aplikasi
Sumber daya yang dibutuhkan: Manajer Proyek, Technical Leader, Sistem Analis, Database Administrator.
2.4 Pembuatan dokumen SRS (Software Requirement Specification)
Sumber daya yang dibutuhkan: Manajer Proyek, Technical Leader, Sistem Analis dan Dokumentasi.
2.5 Pembuatan dokumen SDD (Software Design Document)
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Aplikasi Desainer dan Dokumentasi.
3. Tahap Construction
3.1 Pembangunan Aplikasi
Sumber daya yang dibutuhkan: Database Administrator, Technical Leader, Sistem Analis, Aplikasi Desainer dan Programmer.
4. Tahap Transition
4.1 Deploy keseluruhan aplikasi ke server
Sumber daya yang dibutuhkan: Technical Leader. 4.2 Penyesuaian integrasi aplikasi yang dibangun
51 4.3 Testing aplikasi di data center dan di beberapa lokasi
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Quality Assurance dan Programmer.
4.4 Full Cycle Test
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Quality Assurance dan Programmer.
4.5 Bug fixing
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Programmer.
4.6 User Acceptance Test (UAT)
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Quality Assurance, Programmer dan user.
4.7 Pembuatan User Manual
Sumber daya yang dibutuhkan: Sistem Analis dan Dokumentasi.
4.8 Transfer Knowledge
Sumber daya yang dibutuhkan: Technical Leader, Sistem Analis, Programmer dan user.
5. Tahap Production
5.1 Pembuatan dokumentasi akhir proyek
Sumber daya yang dibutuhkan:Manajer Proyek, Dokumentasi.
5.2 Garansi aplikasi selama 3 bulan (maintanance)
52 5.3 Serah terima pekerjaan aplikasi
Sumber daya yang dibutuhkan:Manajer Proyek, user.
Penjadwalan dengan sumber daya disusun dengan bantuan tools
55
Slack merupakan jumlah dari delay yang diijinkan sebelum suatu kegiatan terlambat dan sangat berpengaruh di dalam pengerjaan proyek. Dengan menggunakan Microsoft Project 2007 maka dihasilkan slack yang dapat dilihat pada tabel 4.4.
57 Setelah diketahui data jumlah slack maka dapat diketahui bahwa dalam penjadwalan proyek ini terdapat critical path yaitu 2-3-7-8-9-13-14-18-21-23-25-30-37-38-39-40-41-42-49-50-51-52-53-54-55-56-58-59-60, seperti dapat dilihat pada gambar 4.3.
58 Berdasarkan jadwal yang telah dibuat dapat diestimasikan untuk pengerjaan proyek berjumlah 204 hari kerja.
4.4 Estimasi Kompleksitas Perangkat Lunak
Estimasi kompleksitas perangkat lunak dengan menggunakan model
Function Point dimana langkah pertama adalah memberikan penilaian bobot pada setiap bagian dari lima tipe fungsi untuk menentukan kuantitas Unadjusted Function Points (UFP).
Penilaian bobot dilakukan dengan berdiskusi dengan pihak perusahaan,
yaitu PT Dycode, untuk menentukan apa saja yang termasuk ke dalam setiap fungsi pengguna beserta nilai bobot dari masing-masing fungsi yang
59 Tabel 4.5 Hasil perhitungan UFP
Fungsi Pengguna Penjelasan Simple Average Complex Total
External Input (EI)
Input Perencanaan Kedatangan Kapal 4 x 3 = 12 12
Input Perencanaan Alokasi Lapangan 3 x 6 = 18 18
Input Perencanaan Perpindahan Kapal 2 x 3 = 6 6
Input Perencanaan Perpindahan Alokasi 2 x 3 = 6 6
Input Konfirmasi Bongkar Petikemas 2 x 3 = 6 6
Input Konfirmasi Perpindahan Kapal 2 x 3 = 6 6
Input Konfirmasi Kedatangan dan Memulai Layanan pada Kapal 4 x 4 = 16 16
Input Konfirmasi Buka dan Tutup Palka 2 x 3 = 6 6
Input Konfirmasi Selesai Layanan pada Kapal 1 x 6 = 6 6
Input Konfirmasi Penempatan Petikemas di Lapangan 1 x 3 = 3 4 x 6 = 24 27
Input Konfirmasi Pengangkatan Petikemas dari Lapangan 1 x 3 = 3 1 x 4 = 4 3 x 6 = 18 25
Input Jenis Petikemas 2 x 3 = 6 6
Input Konfirmasi Penerimaan Petikemas 2 x 3 = 6 6
Input Konfirmasi Pengiriman Petikemas 2 x 3 = 6 6
60
Fungsi Pengguna Penjelasan Simple Average Complex Total
External Output (EO)
Pencetakan Jobslip 7 x 4 = 28 28
Pencetakan Invoice 1 x 7 = 7 7
Pencatatan Hasil Perhitungan Layanan 17 x 4 = 68 68
61 Setelah mengakumulasi UFP kemudian menghitung akumulasi Value Adjustment Factor (VAF). VAF dihitung berdasarkan pada keseluruhan kompleksitas sistem dengan menggunakan 14 General System Characteristics
(GSC), dimana nilai masing-masing dari GSC berskala 0 (nol) sampai 5 (lima).Skala 0 (nol) menunjukkan tidak adanya pengaruh dan skala 5
(lima)menunjukkan adanya pengaruh yang luas terhadap keseluruhan proyek. Pemberian nilai dari masing-masing GSC dilakukan dengan berdiskusi dengan pihak perusahaan, yaitu PT Dycode, untuk menentukan tingkat kepentingan dari
masing-masing GSC. Tabel 4.6 memperlihatkan hasil kompleksitas sistem menggunakan GSC.
Tabel 4.6 Hasil perhitungan bobot GSC
General System Characteristic Kepentingan
Data Communication 5
Distributed Data/Processing 4
Performance Objectives 4
Heavily Used Configuration 3
Transaction Rate 3
Conversion / Installation Ease 3
Operational Ease 3
Multiple Site Use 2
Facilitate Change 3
62 Setelah mendapatkan nilai VAF dilakukan perhitungan Adjusted Function Point
(AFP). AFP adalah perhitungan dari perkalian VAF dengan UFP dengan rumus (3.1) sehingga menghasilkan nilai AFP sebagai berikut:
AFP = 2419 * (0.65 + 0.01 * 47) = 3034.39 FP
Berdasarkan perhitungan AFP, maka estimasi yang didapatkan untuk
perangkat lunak sistem informasi pelabuhan yang akan dibuat adalah 3034.39 FP. Nilai AFP menunjukan tingkat kompleksitas dari suatu perangkat lunak. Dimana berdasarkan standar kompleksitas dari perusahaan untuk sebuah aplikasi berbasis
web, nilai AFP 3034.39 FP termasuk perangkat lunak yang kompleks.
4.5 Manajemen risiko 4.5.1 Identifikasi risiko
Proses manajemen risiko diawali dengan identifikasi risikoyang bertujuan mengidentifikasi serta membuat daftar risiko yang mungkin terjadi. Proses
identifikasi kejadian ini dilakukan dengan pendekatan diskusi dan wawancara dengan pihak perusahaan yang menghasilkan daftar lengkap risiko.Identifikasi
63 Tabel 4.7 Identifikasi risiko
Kode Risiko Jenis Risiko Deskripsi Risiko
R1 Kebutuhan Penambahan atau perubahan spesifikasi kebutuhan dari user
R2 Susah atau dipersulit dalam pengambilan data
R3 Bisnis model yang akan dibuat belum fix
R4 Estimasi Perkiraan ukuran sistem perangkat lunak tidak sesuai
R5 Perkiraan jadwal perbaikan sistem terlalu rendah
R6 Organisasi Terjadi perubahan struktur organisasi di perusahaan
R7 Terjadi masalah keuangan dalam organisasi
R8 Personal Ada staff yang sakit sehingga berpengaruh pada aktifitas pengembangan
R9 Terjadi konflik internal
R10 Kurang koordinasi di dalam tim, kurangnya kerjasama dalam tim
R11 Kekurangan resource yang memiliki kompetensi yang diharapkan
R12 Resources ada yang mengundurkan diri
R13 Sistem analis lambat menangkap bisnis model yang akan dibangun
R14 User belum mengerti cara penggunaan aplikasi setelah dilakukan training
R15 Tools dan Terjadi kerusakan tools yang digunakan untuk mengembangkan sistem R16 Teknologi Tingkat kesulitan pekerjaan yang tidak terprediksi sebelumnya
R17 Aplikasi tidak jalan sebagaimana mestinya
R18 Teknologi yang digunakan tidak compatible dengan kebutuhan yang ada
R19 Tools yang digunakan untuk pengembangan tidak efisien
R20 Database yang digunakan tidak dapat memproses transaksi sebanyak yang dibutuhkan
R21 Eksternal Bencana alam
R22 Perubahan kebijakan pemerintah
64 Selanjutnya, setelah semua risiko diidentifikasi, dilakukan proses penilaian terhadap masing risiko untuk mengetahui kategori dari masing-masing risiko.
4.5.2 Analisis kemungkinan dan konsekuensi risiko
Pada tahap ini, berdasarkan identifikasi risiko yang telah dilakukan
sebelumnya, dilakukan pengidentifikasian mengenai probabilitas terjadinyarisiko beserta dampak yang mungkin ditimbulkanjika risiko tersebut terjadi, sehingga akan dihasilkan tingkat kepentingan dari masing-masing risiko.
Penilaian risiko pada dasarnya mengacu pada dua faktor, yaitu kuantitas risiko dan kualitas risiko.Kuantitas risiko terkait dengan berapa banyak nilai, atau
dampak, yang rentan terhadap risiko sedangkan kualitas risiko terkait dengan kemungkinan suatu risiko muncul. Tujuan penilaian risiko adalah untuk mendapatkan daftar risiko yang telah dinilai berdasarkan tingkat dampak dan
kemungkinan terjadinya.
Hasil penilaian risiko tersebut kemudian dipetakan untuk mengetahui
risiko-risiko utama yang harus menjadi menjadi prioritas untuk ditangani.
Penilaian probabilitas dari setiap risikodan dampak yang ditimbulkan dibuat dalam suatu skala yaitu 0 sampai 1, dimana skala tersebut menyatakan
tingkatan dari rendah, sedang dan tinggi, seperti dijelaskan pada tabel 4.8. Tabel 4.8 Nilai Skala Risiko
Skala Nilai Risiko
0-0.3 Rendah
0.4-0.7 Sedang
65 Pemberian nilai probabilitas dan dampak dari setiap risiko dilakukan dengan berdiskusi dengan pihak perusahaan, yaitu PT Dycode, dimana nilai terdiri dari suatu skala yaitu 0 sampai 1 yang menyatakan tingkatan dari rendah,
sedang dan tingginya probabilitas dan dampak dari masing-masing risiko.
Tabel 4.9 berikut ini akan memperlihatkan hasil perhitungan probabilitas
dan dampak risikoyang telah didiskusikan berdiskusi pihak perusahaan,beserta hasil perhitungan tingkat kepentingan dari masing-masing risiko (risk exposure). Tingkat kepentingan dari masing-masing risikodihitung dengan menggunajan
rumus (4.1) sebagai berikut:
Risk Exposure = Probability (Outcome) * Loss(Outcome) (4.1) Dimana:
Risk Exposure : tingkat kepentingan risiko
Probability (Outcome) : nilai probabilitas risiko
Loss(Outcome) : nilai dampak yang ditimbulkan risiko
Tabel 4.9 Hasil perhitungan tingkat kepentingan risiko
Kode Risiko Probabilitas Dampak Tingkat Kepentingan Risiko
66
Kode Risiko Probabilitas Dampak Tingkat Kepentingan Risiko
R14 0.6 0.4 0.24
Berdasarkan hasil perhitungan tingkat kepentingan risiko,kemudian dibuat matriks risiko. Tabel 4.10 merupakan matriks risiko yang dihasilkan dari hasil perhitungan kepentingan risiko.
67 Tabel 4.11 Kategori Tingkat Risiko
Kode
Dalam melakukan penanganan terhadap risiko terdapat empat alternatiftindakan yang dapat dilakukan, yaitu:
1. Menerima Risiko (Acceptance)
68 Tindakan ini biasanya diterapkan pada risiko-risiko yang tingkat risikonya rendah bagi perusahaan, sehingga apabila dilakukan penanganan residual risk menimbulkan biaya yang tidak sebanding dengan keuntungannya.
2. Menghindari Risiko (Avoidance)
Avoidance adalah tindakan perusahaan untuk tidak melakukan usaha tertentu yang mengandung risiko yang tidak diinginkan. Tindakan ini biasanya diterapkan pada risiko-risiko yang tingkat risikonyatidak dapat diterima oleh perusahaan atau berdampak sangat tinggi bagi perusahaan,
dimanapenanganannya akan menimbulkan biaya yang sangat tinggi serta tidak efisien.
3. Mengurangi Risiko (Mitigation)
Mitigation adalah tindakan perusahaan dengan menggunakan semua sumber daya yang dimilikinya berusaha untuk dapat meminimalkan risiko
tanpa menghilangkan peluang perusahaan untuk meraih keuntungan. Tindakanini dapat dilakukan terhadap salah satu dari kedua faktor, yaitu:
a. Mengurangi kemungkinan terjadinya risiko, biasanya dengan melakukan proses perubahan desain dan engineering, prosedur quality assurance atau audit secara periodik.
b. Mengurangi dampak akibat terjadinya suatu risiko, biasanya diterapkan pada risiko yang berdampak tinggi dan kemungkinannya
69 4. Membagi Risiko (Transfer)
Transfer adalah tindakan perusahaan untuk memindahkan risiko kepada pihak ketiga yang dapat mengelola risiko antara lain melalui kesepakatan
kontrak dengan asuransi.
Dari hasil penilaian risiko kemudian dilakukan penanganan mitigasi risiko
atau tindakan pengendalian risiko. Tindakan pengendalian terhadap masing-masing risiko dapat dilihat pada tabel 4.12.
Tabel 4.12 Tindakan Pengendalian Risiko
Tingkat Risiko Kode
Risiko Tindakan Pengendalian Risiko
Risiko Tinggi R1
1. Selalu mengacu kepada desain yang sudah disepakati, karena perubahan yang tidak bisa dibendung akan mengakibatkan terjadinya keterlambatan pengerjaan.
2. Memberikan pemahaman kepada user dalam cara penggunaan aplikasi.
3. Setiap perubahan akan dikumpulkan dan di catat dalam suatu dokumen yang nantinya di tandatangan bersama dengan user.
Risiko Tinggi R7
Membuat dokumen untuk diajukan ke senior manajer untuk menggambarkan pentingnya proyek ini terhadap kemajuan bisnis
perusahaan.
Risiko Tinggi R8
1. Memanfaatkan resource yang ada dengan menambah jam kerja dan pemahaman tentang teknologi.
2. Mengorganisasi pekerjaan sehingga setiap bagian dapat memahami proses bagian lain. Risiko Tinggi R10 Segera perbaiki komunikasi di dalam tim
Risiko Tinggi R18
1. Sebelum pemilihan teknologi, sebaiknya dilakukan Proof of Concept (POC). 2. Mencari teknologi alternatif.
3. Kebutuhan bisnis disesuaikan dengan teknologi yang ada.
70 Tingkat Risiko Kode
Risiko Tindakan Pengendalian Risiko Risiko Sedang R2
Memberi pengertian kepada user, bahwa jika terjadi hal seperti ini dapat memperlambat waktu pengerjaan proyek.
Risiko Sedang R3
1. Mengkaji bersama untuk memastikan bisnis model fix dan tidak akan ada perubahan yang mendasar nantinya.
2. Mencari referensi dengan mengkontak user yang sudah kompeten.
Risiko Sedang R5
Memberi pengertian kepada user bahwa perbaikannya memakan waktu yang tidak sedikit.
Risiko Sedang R9 Segera perbaiki komunikasi di dalam tim
Risiko Sedang R12
1. Melihat kemungkinan untuk menambah
resource untuk membantu pekerjaan agar tetap bisa diselesaikan.
2. Memanfaatkan resource yang ada dengan menambah jam kerja dan pemahaman tentang teknologi.
Risiko Sedang R17 Melakukan perbaikan ulang.
Risiko Sedang R20
Mencari tau database yang memiliki daya kerja tinggi dan melihat kemungkinan mengganti
engine database.
Risiko Sedang R21 Mempersiapkan memiliki backup data yang aman.
Risiko Sedang R23 Melakukan komunikasi dengan pihak user
Risiko Rendah R4
Melakukan re-schedule project dan
mengkomunikasikannya kepada tim dan pihak user.
Risiko Rendah R6
Memberi penjelasan kepada pihak perusahaan agar tidak terjadi perubahan kepentingan dalam proyek ini.
Risiko Rendah R11
Memanfaatkan resource yang ada diberikan training terlebih dahulu agar lebih memahami yang akan dikerjakan.
Risiko Rendah R16 Identifikasi permasalahan yang menyebabkan keterlambatan.
71 BAB V
KESIMPULAN DAN SARAN
5.1. Kesimpulan
Berdasarkan uraian hasil penelitian dan pembahasan yang telah dilakukan
selama penelitian mengenai perancangan manajemen proyek perangkat lunak untuk sistem informasi pelabuhan, maka dapat diambil kesimpulan sebagai berikut:
a. Manajemen proyek estimasi waktu pengerjaan proyek pembangunan perangkat lunak sistem informasi pelabuhan dengan menggunakan metode
Program/Project Evaluation and Review Technique (PERT) dan Critical Path Method (CPM) menghasilkan estimasi waktu pengerjaan yaitu selama 204 hari.
b. Manajemen proyek estimasi tingkat kompleksitas perangkat lunak sistem informasi pelabuhan yang akan dibangun dengan menggunakan model
Function Point menghasilkan nilai perangkat lunak sebesar 3034.39 FP, dimana nilai tersebut untuk sebuah aplikasi berbasis web termasuk
perangkat lunak yang kompleks.
c. Manajemen proyek menghasilkan 23 jenis-jenis risiko yang mungkin akan dihadapi saat pelaksanaan proyek dan menghasilkan langkah-langkah
72 5.2. Saran
Berdasarkan kesimpulan di atas, maka saran yang diharapkan yaitu pelaksaanan proyek dilakukan sesuai dengan perencanaan yang telah dibuat.
Kemudian seiring berjalannya proyek tetap dilakukan monitoring untuk mengontrol kesesuaian antara estimasi dengan kenyataan saat dilakukan proyek
