MPPL MANAJEMEN PROYEK

EAS MPPL D 2019 – Natasha Valentina 05111640000183
1 Sebutkan proses-proses dalam manajemen proyek untuk mengerjakan proyek di atas?
a. Konsepsi dan Inisiasi Proyek -> sebuah proyek diperiksa untuk menentukan apakah
dapat direalisasikan
b. Pendefinisian dan Perencanaan Proyek -> menguraikan pekerjaan apa yang akan
dilakukan, menghitung anggaran dan jadwal, dan menentukan sumber daya yang
dibutuhkan
c. Pelaksanaan Proyek -> memulai mengerjakan tanggung jawab masing-masing sesuai
persiapan yang telah ada
d. Kinerja dan Kontrol Proyek -> melihat status proyek apakah sesuai dengan rencana,
menyesuaikan jadwal dan menjaga proyek agar berjalan sesuai target
e. Closing proyek -> melakukan evaluasi untuk menyoroti keberhasilan proyek yang
dilakukan oleh para stakeholders.
2 Jelaskan keuntungan penerapan manajemen proyek di dalam pembuatan aplikasi atau
sistem informasi
a. Mengidentifikasi fungsi dan tanggung jawab masing-masing anggota.
b. Mengidentifikasi batas waktu untuk penjadwalan.
c. Mengukur prestasi terhadap rencana.
d. Mengidentifikasi masalah lebih dini dan menginisiasi tindakan perbaikan.
e. Meningkatkan kemampuan estimasi untuk rencana yang ada.
f. Mengetahui jika sasaran tercapai atau tidak.
g. Meningkatkan produktivitas.
h. Meningkatkan koordinasi antar anggota.
i. Mengontrol proyek di bidang keuangan, fisik, dan sdm.
3 Modul atau fitur apa saja yang harus tersedia di dalam sistem manajemen layanan TI (IT
Service Management) sesuai studi kasus? Jelaskan!
a. Modul pencatatan keluhan -> keluhan ke Biro TI dicatat secara online sehingga
langsung masuk ke database tanpa melalui pengumpulan secara manual.
b. Modul pembagian personel -> berdasarkan keluhan yang masuk, modul ini membagi
personel-personel yang tersedia untuk mengangani keluhan tersebut.
c. Modul review keluhan -> mencatat hasil penanganan keluhan apakah sudah sesuai
harapan atau masih perlu perbaikan lebih lanjut.
d. Modul statistik keluhan -> menampilkan statistik keluhan yang masuk dan
terselesaikan dengan pencatatan per-bulan.
4 Siapa saja user yang akan menggunakan sistem, definisikan dan gambarkan aliran
aktivitasnya (flow activity)
a. Pengguna -> seseorang yang menyampaikan keluhan
b. Personel TI -> seseorang dari Birot TI untuk menyelesaikan keluhan tersebut

5 Jika disediakan dana 500 juta dan waktu pengerjaan 4 bulan, buatlah perencanaan
proyeknya!

PERENCANAAN PROYEK
Aplikasi Layanan Penanganan Keluhan Biro
Teknologi Informasi untuk Badan Pengelola
Keuangan dan Aset Daerah (ALPK)
Disusun oleh:
05111640000183 Natasha Valentina S
Kelas :
Manajemen Proyek Perangkat Lunak (D)
Departemen Infomatika
Fakultas Teknologi Informasi dan Komunikasi
Institut Teknologi Sepuluh Nopember Surabaya
2019

1. Gambaran Umum Proyek
Proyek Aplikasi Layanan Penanganan Keluhan (ALPK) ini
bermaksud untuk menghasilkan produk berupa aplikasi penanganan
keluhan yang dibangun per-modul berdasarkan penganganan keluhan
yang berada di Badan Pengelola Keuangan dan Aset Daerah.
ALPK memetakan seluruh area fungsional penting dari sebuah
layanan keluhan biro IT. Paket ALPK memungkinkan pelayanan terhadap
penanganan kendala dan keluhan yang lebih baikefisiensi dan
pengurangan biaya. ALPK menyediakan kemudahan akses terhadap
informasi yang penting serta memungkinkan pihak manajemen
mengambil keputusan yang lebih baik dan tepat pada waktunya.
ALPK dikembangkan dengan menggunakan teknologi relasional
database system MySQL 5 dan bahasa pemrograman Java 8. ALPK
memberikan keuntungan dengan mempersingkat proses operasional,
meningkatkan administrasi dan pengendalian.
Proses-proses utama dari penanganan keluhan yang didukung oleh
aplikasi ALPK, meliputi:
1. Merekam data keluhan yang masuk.
2. Menghitung jumlah keluhan yang terjadi dan yang terselesaikan per-bulan.
3. Menampilkan status dari alur penyelesaian penanganan keluhan.
4. Menentukan dan mengirimkan personel untuk menangani keluhan.
1.1 Tujuan, Ruang Lingkup dan Sasaran
Tujuan : Membuat produk aplikasi yaitu sistem
informasi yang dikembangkan per-modul
sesuai dengan subsistem yang ada. Modul yang
dibuat pada proyek kali ini terdiri dari 2 modul
utama, yaitu : Aplikasi manajemen keluhan dan
aplikasi penentuan personel biro TI.
Ruang Lingkup : Produk ini ditujukan untuk diterapkan pada
yang memiliki fungsional seperti pada ALPK.
Untuk database aplikasi disiapkan supaya dapat
terhubung dengan data bagian SDM biro TI.
Sasaran : Menghasilkan produk aplikasi layanan
penanganan keluhan yang sesuai dengan
spesifikasi kebutuhan.

Dibawah ini adalah Project Charter Proyek pembangunan ALPK.
Informasi proyek
Tanggal Mei 2019
No.
Proyek
05/19/001 Nama Proyek
Aplikasi Layanan
Penangan Keluhan
Pimpinan proyek Ir. A. Budi Harto Klien MPPL Informatika
Tahapan meliputi
1. Persiapan survey dan pelaksanaan
2. Analisa Kebutuhan user dan software
3. Detail Design
4. Pengembangan aplikasi
5. Evaluasi dan uji coba Aplikasi
6. Penutupan proyek
Tanggal mulai 2 Mei 2019 Total kontrak Rp. 500.000.000,-
Tanggal selesai 28 Agustus 2019 Estimasi biaya Rp. 477.480.000,-
Tujuan Bisnis
Membangun aplikasi layanan penanganan keluhan yang dikembangkan per-modul
sesuai dengan subsistem yang ada di Biro TI.
Deskripsi Produk/ Proyek
• Aplikasi Penanganan Keluhan
• Aplikasi Sistem Informasi Personel Biro TI
Sasaran Proyek
Sasaran proyek menghasilkan spesifikasi, desain , program aplikasi dan uji coba
aplikasi
Critical Success Factors :
Sistem Informasi yang men-support agar Biro TI yang dimodelkan memiliki komitmen
untuk tetap menggunakan business process yang sudah disepakati
Batasan :
Pelaksanaan survey lapangan sepenuhnya dilakukan pada Badan Pengelola Keuangan
dan Aset Daerah.
Asumsi :
Biro TI yang akan mengimplementasikan ALPK sebelumnya tidak mempunyai aplikasi
layanan penanganan keluhan terintegrasi lainya.
Otoritas Pimpinan Proyek :
• Mengatur jadwal, anggaran dana, personel yang bertanggung jawab, dan
sumber daya lain yang digunakan selama pelaksanaan proyek
• Melakukan pengawasan aktifitas pelaksanaan proyek.
• Tidak mencakup dalam hal perekrutan pekerja proyek, karena pekerja
proyek telah ditentukan saat proyek dimulai.
Tanggung jawab pimpinan proyek :
• Membuat rencana proyek dan dokumen pendukung
• Membuat laporan kemajuan/kinerja proyek
• Mengendalikan seluruh kegiatan hingga selesai
• Menjamin proyek berhasil dengan baik dan penyampaian laporan tepat
waktu.
Pimpinan proyek Ir. A. Budi Harto Kepala Cabang Ir. Hari Juned

1.2 Asumsi, Batasan dan Resiko
Asumsi
1. Kebutuhan infrastruktur, usaha yang sebenarnya, dan jadwal akan
diselesaikan setelah dilakukan identifikasi kebutuhan.
2. Ruang lingkup ALPK pada proyek ini dikerjakan dengan
mempertimbangkan fungsional layanan keluhan secaraumum.
3. Detail dokumen kebutuhan (SKPL) akan disiapkan setelah
dilakukan studi biro TI BPKAD dan akan ditanda tangani oleh
klien pada periode tertentu.
4. Perubahan pada persetujuan dokumen kebutuhan akan
diberlakukan seperti perubahan permintaan dan modifikasi yang
akan dianggap sebagai tambahan tagihan pada klien.
5. Persoalan kinerja ditujukan untuk ketersediaan infrastruktur yang
diinginkan oleh klien.
6. Komitmen dari seluruh jajaran managemen dan pekerjaproyek.
7. Kegiatan operasional penanganan keluhan dilakukan secara
manual (belum ada sistem informasi yang digunakan)
8. Kondisi pengembangan aplikasi aman dan kondusif
Batasan
1. Pelaksanaan identifikasi kebutuhan dilakukan terhadap studi
pustaka tentang perancangan aplikasi layanan penanganan keluhan
pada Badan Pengelola Keuangan dan Aset Daerah oleh Bagus
Permadi.
2. Waktu pelaksanaan proyek 4 bulan mulai dari tanggal 2 Mei 2019
hingga 28 Agustus 2019.
3. Anggaran dana yang ditetapkan untuk pelaksanaan dan
pengelolaan proyek tidak melebihi total kontrak proyek, yaitu Rp.
500.000.000,-
Resiko utama yang mungkin muncul :
No. Kategori
Resiko
Daftar
Resiko
1. Teknis - Requirement kurang
- Analisa dan desain salah
- Teknologi yang digunakan berubah

2. Manajemen
proyek
- Estimasi kurang akurat
- Perencanaan kurang lengkap
- Pengawasan dan komunikasi kurang
- Sasaran proyek tidak konsisten
3. Lingkungan - Bencana Alam
- Kondisi Kesehatan Pekerja
4. Keorganisasian - Staf dan pekerja kurang berpengalaman
- Beban kerja yang terlalu menumpuk.
1.3 Penyerahan Proyek
Dokumen dan Produk yang diserahkan sebagai hasil dari
proyek meliputi dua kategori berikut :
1. Project management-related deliverables: Project Plan ,
project charter, project scope statement, WBS, schedule,
cost baseline, status reports, final project presentation, final
project report, dan dokumentasi lain yang berkaitan dengan
project.
2. Product-related deliverables: Spesifikasi Kebutuhan
Perangkat Lunak, Deskripsi Detail Desain, source code
aplikasi.
Media yang digunakan untuk penyerahan bervariasi tergantung
pernyerahannya. Untuk penyerahan dokumentasi Kebutuhan dan
desain sistem menggunakan kertas yang berupa dokumen. Sedangkan
untuk produk atau aplikasi diserahkan dalam bentuk CD. Dokumen-
dokumen tersebut harus terjaga kerahasiaanya. Semua hasil
penyerahan telah di back-up oleh pihak pengembang sistem.
1.4 Ringkasan Jadwal
Secara umum jadwal dari proyek terdiri atas beberapa aktifitas
utama yang di alokasikan untuk tiap aktifitas. Berikut merupakan
ringkasan jadwal untuk proyek pembangunan Aplikasi
Layanan Penanganan Keluhan :
Kegiatan Mei 2019 Juni 2019 Juli 2019 Agustus
2019
I II I II I II I II
Kontrak Proyek
Analisis Kebutuhan
Prototyping
Pemrograman
Uji Coba
Pelatihan
Pelaporan

1.5 Evolusi Perencanaan
Perencanaan proyek ini disusun berdasarkan standard IEEE 1058-1998
Standard for Software Project Management Plans.
Perencanaan proyek yang dirilis pertama kali akan diberikan
kepada sponsor dan dikoordinasi dengan anggota tim untuk di review.
Sedangkan perubahan tehadap perencanaan proyek akan dilakukan
jika diperlukan selama proyek masih berlangsung. Setiap perubahan
penting pada dokumen ini harus disahkan oleh klien dan disebarkan
pada anggota tim.
Penomoran versi pada dokumen perencanaan proyek ini
mengikuti format penanganan dokumen yang ditentukan pada bab
Rencana Tambahan sub-bab Rencana Dokumentasi dalam dokumen
ini.
1.6 Definisi dan Akronim
WBS Work Breakdown Structure
SKPL Spesifikasi Kebutuhan Perangkat Lunak
PERT Program Evaluation and Review Technique
VORD Viewpoint Oriented Requirement Definition
ALPK Aplikasi Layanan Penanganan Keluhan
QA Quality Assurance
UML Unified Modelling Language
SDLC System Development Life Cycle

2. Organisasi Proyek
2.1 Lingkungan Eksternal
Lingkungan eksternal ini membahas tentang bagaimana
hubungan antara team proyek dengan pihak luar. Pihak yang
berhubungan dan mendukung proyek adalah sebagai berikut :
Organization Name of Liaison/Interface
Biro TI BPKAD Pihak Pemesan Aplikasi
User (Pemakai di lapangan) Pegawai pelaksana / pengguna
2.2 Struktur Internal
Struktur organisasi dalam team proyek ini menggunakan tipe
controlled decentralized dimana team telah menunjuk seorang leader
(manajer proyek) sebagai pimpinan proyek. Untuk lebih jelasnya
tentang Komunikasi antar kelompok dan individu dilakukan secara
horisontal. Komunikasi vertikal sesuai dengan hirarki kendali juga
dilakukan.
Untuk lebih jelasnya tentang struktur organisasi dapat dilihat di
gambar di bawah ini :
Penjelasan dari diagram di atas secara umum bahwa tim proyek
ini dipimpin oleh seorang pimpinan proyek yang membawahi 3
bidang, yaitu : analis, programmer, dan surveyor. Antar bidang dapat
saling memberikan saran. Masing –masing bidang bertanggung jawab
pada pimpinan proyek.
2.3 Peran dan Tanggung Jawab

Tiap-tiap anggota tim memiliki tugas dan tanggung jawab
masing- masing yang harus dijalankan. Tugas dan tanggung jawab
tersebut dapat dilihat di tabel berikut :
Jabatan Pembagian
tugas
Pimpinan proyek
• Bertanggung jawab terhadap jalannya proyek
• Membuat perencanaan proyek serta pengawasan
seluruh aktifitas eksekusi proyek
• Membuat/mengumpulkan dokumentasi proyek
setelah selesai dilakukannya tahapan tertentu.
• Membuat laporan pertanggungjawaban setelah
tahap implementasi selesai.
• Memberikan pengarahan, teguran, dan peringatan
kepada anggota team jika terjadi penyimpangan
dalam pelaksanaan proyek.
Analis
• Melakukan analisa kebutuhan kustomer hingga
menghasilkan spesifikasi fungsional dari sistem
informasi.
• Mendesain desain database dan UML diagram dari
sistem sesuai hasil analisa.
• Menetapkan kebutuhan dari sistem dan
menggambarkan fungsionalitas dari sistem.
• Membuat dokumentasi untuk aktifitas analisa dan
desain yakni
berupa Spesifikasi Kebutuhan Perangkat Lunak dan
Deskripsi Detail Desain .
Programmer
• Membuat aplikasi berdasarkan detail desain yang
diberikan oleh pihak analis
• Membuat dokumentasi aplikasi baik itu database,
maupun aplikasi dalam bentuk CD.
• Membuat dokumentasi bantuan aplikasi berupa
panduan instalasi
• Turut serta dalam melaukan ujicoba dan review hasil
ujicoba aplikasi
Surveyor
• Melakukan identifikasi terhadap kebutuhan kustomer
(survey kebutuhan kustomer)
• Membuat kesimpulan awal tentang layanan dari
sistem berdasar identifikasi kebutuhan yang
dilakukan
3. Rencana Proses Managerial
3.1 Rencana Awal
3.1.1 Estimasi
Metode dan hasil estimasi proyek
• Estimasi biaya untuk gaji pekerja menggunakan
pendekatan person/hour.
• Estimasi untuk durasi waktu pengerjaan tiap aktifitas
menggunakan analisa PERT. Analisa ini digunakan
untuk menghadapi ketidakpastian pada durasi

aktifitas/tugas. Penetapan lama perkiraan aktifitas (D)
merupakan faktor dari optimistic Duration (OD),
pesimistic Duration (PD) dan expected Duration (ED)
pada analisa PERT. Rumus analisa PERT :
D =
(1xOD ) + (4 xED ) + (1xPD )
6
Tahapan Optimis Pesimis
Most
Likely
Durasi
tanpa resiko
Durasi
dengan
resiko
Identifikasi
kebutuhan
6 hari 9 hari 7 hari 7 hari 8 hari
Analisa 10 hari 20 hari 18 hari 17 hari 19 hari
Desain 12 hari 18 hari 15 hari 15 hari 17 hari
Pembuatan
aplikasi
10 hari 18 hari 11 hari 12 hari 13 hari
Uji Coba ** 4 hari 8 hari 6 hari 6 hari 6 hari
** Tahapan tanpa tambahan durasi resiko
3.1.2 Pengaturan Kepegawaian
Staff yang diperlukan pada proyek ini untuk keseluruhan
berjumlah 17 orang dengan pembagian sebagai berikut :
Staff Asal Durasi Kerja Jumlah
Manager
Proyek
Internal
Perusahaan
Selama Proyek
berlangsung
1 Orang
Team
Leader
Internal
Perusahaan
Selama Proyek
berlangsung
1 Orang
Surveyor Di sewa Selama fase identifikasi
kebutuhan
2 Orang
Analis Internal
Perusahaan
Selama fase analisa dan
desain
3 Orang
Programmer Internal
Perusahaan
Selama fasepembangunan
aplikasi dan ujicoba
5 Orang
3.1.3 Perolehan Sumber Daya
Perolehan dan perekrutan sumber daya proyek tidak perlu
dilakukan dalam proyek, karena sumber daya proyek telah didapat
atau direkrut oleh perusahaan penanggung jawab proyek (dimana
proyek berlangsung) sesuai dengan kriteria yang ditentukan.
3.1.4 Pelatihan Pekerja Proyek
Berikut adalah daftar rencana training (pelatihan) yang akan
diberikan kepada anggota tim Proyek. Daftar berikut disusun
berdasarkan kendala pada setiap tahap yang kemungkinan terjadi
selama pelaksanaan proyek :

Tahapa
n /
Staff
Permasalahan Jenis pelatihan
Metode
Pelatihan
Analisa Kebutuhan
Analis 1. Sistem yang kompleks
membuat analis kesulitan
dalam membuat strukturisasi
viewpoint dengan metode
VORD .
(Technical training)
tentang analisa
kebutuhan dengan VORD
dan cara penggunaan
VORDTool.
Konsultasi
dan mencari
studi pustaka
/ referensi ttg
VORD.
Detail Desain Aplikasi
Analis 1. Kesulitan dalam membuat
Class diagram UML
karena banyaknya relasi
dan entitas.
tentang cara
menggambar Class
Diagram yang benar
sesuai
kesulitan yg dialami.
Konsultasi
dan
Perkuliahan
(diterangkan)
2. Kesulitan membuat desain
database akibat relasi yang
rumit serta penentuan
pembagian database
tentang penyempurnaan
desain database melalui
normalisasi dan
penentuan atribut entitas
yang sesuai.
Konsultasi
dan
Perkuliahan
(diterangkan)
3. Kesulitan membuat
Sequence Diagram
UML.
tentang pembuatan
Sequence Diagram yg
benar sesuai
dengan kesulitan yg
dialami.
Konsultasi
dan
Perkuliahan
(diterangkan)
Pembuatan aplikasi
Programmer 1. Pengaturan koneksi
database. Antara Java 8
dengan MySql
tentang cara membuat
koneksi database
Penjelasan,
praktek dan
studi pustaka
2. Kesulitan pembuatan
modul admin dan
konfigurasi setting
database pada saat
instalasi aplikasi.
tentang pembuatan
modul instalasi dan
file untuk konfigurasi
saat instalasi
Penjelasa
n,
praktek
dan
mencari
sumber lain.

3.2 Rencana Kerja
3.2.1 Work Breakdown Structure (WBS)
WBS merupakan pembagian sebuah proyek kedalam aktifitas-
aktifitas yang, lebih kecil. Aktifitas-aktifitas tersebut diberi identitas
untuk menentukan hubungan antar aktifitas. WBS berguna untuk
perencanaan proyek, terutama mengenai perkiraan waktu pengerjaan
dan sumberdaya yang digunakan. WBS pada proyek ini disusun
berdasarkan metode pengembangan aplikasi waterfall serta aktifitas
pengembangan aplikasi pada umumnya. Level dekomposisi yang
dilakukan pada WBS dibawah ini hingga pada level 5.
Deliverable atau produk yang dihasilkan pada tiap aktifitas
adalah seperti berikut :
No. Aktifitas (Outline level dua) Produ
k
1. Identifikasi Kebutuhan Form identifikasi kebutuhan
yang telah berisi jawaban.
2. Analisa kebutuhan Dokumen SKPL dan Dokumen
Kebutuhan
3. Desain sistem Dokumen Deskripsi Detail
sistem
4. Pembuatan Aplikasi Aplikasi ALPK
5. Uji Coba Aplikasi Hasil testing danperformance
aplikasi.
Dekomposisi WBS yang dibangun untuk pelaksanaan proyek
pembangunan ALPK dapat dilihat lebih jelas pada kolom task name
dalam lampiran 1. Baseline proyek. Selain aktifitas yang dikerjakan
tercantum pula durasi, sumber daya yang digunakan dan predecessor
dari tiap aktifitas.
3.2.2 Alokasi Jadwal
Sebelum melakukan alokasi jadwal, terlebih dahulu harus
disusun daftar aktfiitas yang akan dikerjakan dalam proyek beserta
sumber daya proyek yang dibutuhkan. Susunan aktifitas proyek ALPK
yang dibuat berupa WBS (selengkapnya dapat dilihat pada subbab
3.2.1). Sedangkan mengenai sumber daya proyek selengkapnya
dijelaskan pada subbab 3.2.3 (alokasi sumber daya). Alokasi jadwal
dilakukan dengan bantuan gantt chart.
Tahap pertama dalam melakukan alokasi jadwal yaitu

mengatur dependensi(keterkaitan) antar aktifitas yang sudah tersusun.
Keterkaitan tiap aktifitas dicatat dalam kolom predecessor (pada gantt
chart) dengan menggunakan ID aktifitas dalam WBS. Setelah
keterkaitan dibangun baru kemudian menentukan tanggal mulai dan
durasi untuk tiap aktifitas. Saat seluruh tanggal dan durasi telah
ditentukan untuk tiap aktifitas, jadwal proyek telah selesai dan siap
untuk disimpan sebagai baseline proyek.
Pada jadwal proyek ALPK terdapat lintasan kritis proyek, yaitu
tahap analisa kebutuhan dan desain sistem. Durasi untuk kedua
tahapan tersebut 36 hari (57% dari durasi waktu pelaksanaan proyek
keseluruhan). Batasan waktu dari pelaksanaan proyek menurut
project charter yaitu tanggal 28 Agustus 2019. Sedangkan milestone
untuk tiap aktifitas dapat dilihat selengkapnya pada subbab 4.1 bagian
milestone utama.
3.2.3 Alokasi Sumberdaya
Sumberdaya yang diperlukan dan dialokasikan pada proyek
terbagi atas 2 kelompok utama, yaitu :
- Work: Yakni berupa tenaga kerja yang terdiri atas pimpinan
proyek, surveyor, analis, dan programmer. Pada kategori work
terdapat sumberdaya set komputer karena penggunaan komputer
pada pelaksanaan aktifitas dihitung sesuai dengan lama
pemakaian komputer oleh tenaga kerja, sehingga dapat
meminimalkan biaya sewa komputer.
- Material: Merupakan barang habis yang terdiri dari barang-
barang keperluan kantor (kertas, alat tulis dan CD), biaya utilitas
(sewa kantor, listrik dan air) serta biaya akomodasi pelaksanaan
rapat atau review hasil aktifitas.
Jumlah pekerja yang dibutuhkan beserta kemampuan yang
dimiliki dicantumkan pada tabel berikut :
Staf Jumlah Tahapan
pekerjaan
Kemampuan yang
dimiliki
Manajer Proyek dan
Team Leader
2 Orang Seluruh tahapan
pada proyek.
- Kemampuan koordinasi
dan komunikasi yang
baik
- Kemampuan manajerial
dan manajemen proyek
IT.
- Kemampuan

menyelesaikan
masalah
Surveyor 2 Orang Identifikasi
kebutuhan
- Mampu bekerja sama
dengan user aplikasi
- Mampu berkomunikasi
dan
negosiasi
- Kritis dan detail
dalam bertanya.
Analis 3 Orang Analisa Kebutuhan - Mampu
mengelompokkan layanan
dan fungsi dari sistem
berdsar hasil identifikasi
kebutuhan
- Memahami metode
analisa kebutuhan yang
digunakan
- Mampu
menuliskan dokumentasi
kebutuhan .
- Mampu membuat
dokumen
SKPL yang detail.
Desain sistem - Mengerti cara membuat
diagram-diagram UML
- Mampu
mengoperasikan software
untuk desain UML yaitu
power Designer 12.
- Mengerti tentang
Database
Programmer 5 Orang Pembuatan aplikasi - Menguasai
bahasa pemrograman
Java 8
- Menguasai MySql 5
sebagai DBMS
- Mengerti fungsi
dan penggunaan
komponen / package yg
ditambahkan pada Java 8
- Mampu melakukan
koneksi dari database ke
Java.
Uji Coba aplikasi - Memahami aplikasi yang
dibuat
- Mengerti tentang teknik
testing yang digunakan
- Menguasai masalah
keamanan software dan
database.
3.2.4 Alokasi Dana
Berikut merupakan tabel pemetaan dana pada setiap aktifitas

(outline level 3 ) yang terjadi dan telah diasumsikan total biaya
berdasarkan lama pengerjaan proyek dan sumber daya yang telah
terhitung didalamnya :
Kegiatan
Durasi
(hari)
Biaya Kegiatan
Requirement Phase
Melakukan studi kelayakan 1 Rp 2,650,000
Menganalisis alur bisnis 2 Rp 3,140,000
Melakukan wawancara untuk kebutuhan organisasi 1 Rp 1,700,000
Melakukan wawancara untuk kebutuhan operator 1 Rp 140,000
Melakukan wawancara untuk kebutuhan pemakai 2 Rp 410,000
Melakukan wawancara untuk kebutuhan teknis 2 Rp 460,000
Mendaftar kebutuhan sistem 2 Rp 780,000
Mengkonfirmasi dan menvalidasi daftar kebutuhan 1 Rp 1,140,000
Total Requirement Phase 12 Rp 10,420,000
Design Phase
Mendesain pembuatan perangkat lunak 2 Rp 2,360,000
Mendesain database yang digunakan 2 Rp 26,500,000
Mendesain high level interface 3 Rp 42,550,000
Menyampaikan konsep desain 1 Rp 3,830,000
Mendesain low level interface 5 Rp 66,000,000
Menjelaskan spesifikasi desain 1 Rp 4,620,000
Total Design Phase 14 Rp 145,860,000
Development Phase
Implementasi kebutuhan 7 Rp 94,520,000
Implementasi interface 5 Rp 53,150,000
Integrasi 3 Rp 66,350,000
Melakukan deployment sistem 2 Rp 49,290,000
Membuat dokumentasi hasil implementasi 2 Rp 560,000

Total Development Phase 19 Rp 263,870,000
Testing Phase
Membuat skenario uji coba 1 Rp 1,800,000
Melakukan uji coba 4 Rp 4,750,000
Melakukan evaluasi hasil uji coba 1 Rp 3,700,000
Membuat dokumentasi uji coba 1 Rp 1,450,000
Total Testing Phase 7 Rp 11,700,000
Maintenance Phase
Melakukan pelatihan sistem 4 Rp 41,500,000
Melakukan serahan perangkat lunak 1 Rp 1,800,000
Transisi 1 Rp 1,900,000
Mempresentasikan laporan akhir 2 Rp 2,950,000
Total Maintenance Phase 8 Rp 48,150,000
Total Hari Kerja dan Biaya 60 Rp 480,000,000
Estimasi biaya untuk setiap resource yang digunakan pada proyek
adalah sebagai berikut :
Unit Cost Total
WBS Level1
Totals
WBS Item
1. Project Management
Rp
60,000,000
Project Manager 1
Rp
1,500,000
Rp
1,500,000
Team Leader 1
Rp
12,000,000
Rp
12,000,000
System Analyst 1
Rp
8,000,000
Rp
8,000,000
Programmer 5
Rp
6,000,000
Rp
30,000,000
Ahli Kelembagaan 1
Rp
3,500,000
Rp
3,500,000
Technical Support 1
Rp
2,000,000
Rp
2,000,000
Tenaga Dokumentasi 1
Rp
1,500,000
Rp
1,500,000
Administrasi 1
Rp
1,500,000
Rp
1,500,000
2. Hardware
Rp
120,000,000

Server 1
Rp
20,000,000
Rp
20,000,000
Perangkat Client 10
Rp
10,000,000
Rp
100,000,000
3. Software
Rp
205,000,000
Software Desain 2
Rp
40,000,000
Rp
80,000,000
Software Database 1
Rp
25,000,000
Rp
25,000,000
Software Automated
Integration 1
Rp
60,000,000
Rp
60,000,000
Software Automated
Deployment 1
Rp
40,000,000
Rp
40,000,000
4. Testing (10% dari total
hardware dan software)
Rp
32,500,000
5. Training and Support
Rp
14,900,000
Trainee Costs 10
Rp
150,000
Rp
1,500,000
Travel Costs 8
Rp
400,000
Rp
3,200,000
Trainer 12
Rp
600,000
Rp
7,200,000
System Analyst 1
Rp
800,000
Rp
800,000
Programmer 5
Rp
400,000
Rp
2,000,000
Technical Support 1
Rp
200,000
Rp
200,000
6. Reserves (20% dari total
estimasi)
Rp
45,480,000
TOTAL
Rp
477,880,000

3.3 Rencana Penelusuran Poyek
3.3.1 Manajemen Kebutuhan
Proses pengukuran terhadap perubahan kebutuhan proyek
didasarkan pada presentase perubahan yang diminta
dibandingkan dengan presentase pengerjaan proyek yang telah
selesaidilakukan.
Proses pelaporannya itu sendiri dilakukan dengan cara
meminta perubahan secara langsung kepada tim proyek. Tim
proyek ini kemudian akan melakukan pengukuran apakah
perubahan kebutuhan dalam skala besar atau kecil. Skala ini akan
digunakan untuk menginisialisasi perubahan terhadap
penjadwalan proyek, anggaran dana dan sumber daya manusia
yang digunakan.
Kontrol terhadap perubahan kebutuhan akan terus
dilakukan sepanjang pengerjaan proyek sehingga pengerjaan
proyek mencapai hasil yang maksimal dan tidak sampai
menyimpang dari spesifikasi permintaan perubahan oleh
kustomer ataupun dari stakeholder lain. Kontrol ini akan
dilakukan secara bersama-sama oleh tim sponsor sendiri dan juga
oleh pimpinan proyek..
3.3.2 Pengawasan Jadwal
Mengelola dan mengatur jadwal secara aktif merupakan
cara terbaik untuk memastikan bahwa proyek berjalan tepat waktu.
Dan untuk melakukan proses tersebut, ada beberapa masukan
yang harus tersedia dan dapat dipahami. Input tersebut antara lain
:
▪ Baseline jadwal : adalah versi baseline jadwal terkini yang
disetujui dari jadwal proyek yang menyediakan dasar
sebagai pembanding dan pelaporan dari kinerja proyek.
Jadwal proyek menjelaskan dengan detil rencana tanggal
permulaan dan akhir dari setiap aktifitas.
▪ Laporan kinerja : merupakan hal pertama yang kebanyakan
digunakan sebagai mekanisme komunikasi untuk mendaftar
pekerjaan apa yang harus dikerjakan dan siapa yang

mengerjakan. Laporan kinerja yang baik seharusnya
menunjukkan tanggal yang direncanakan, tanggal
sebenarnya dan durasi yang sebenarnya dari pekerjaan setiap
aktifitas. Saat semua masukan telah dibuat, dibutuhkan alat
bantu dan teknik yang digunakan untuk meninjau ulang
jadwal. Jika sebuah kondisi terjadi dimana pada kenyataan
pelaksanaan proyek berbeda dengan jadwal sebenarnya, alat
bantu dan teknik tesebut dapat digunakan untuk
memperbaiki situasi yang terjadi. Pimpinan proyek akan
melakukan evaluasi seberapa banyak perkerjaan yang
berhasil diselesaikan dibandingkan dengan performa aktual
dan perbedaan jadwal. Jika ditemukan kasus perbedaan
jadwal maka pimpinan proyek wajib mencari penyebabnya.
Berikut adalah beberapa teknik dan metode yang digunakan
untuk melakukan pengawasan jadwal pada proyek ini :
1. Laporan kemajuan proyek : adalah ketika sebuah laporan
yang dibuat menjelaskan tentang tanggal mulai dan
selesai yang sebenarnya dari aktifitas. Dan durasi yang
belum dikerjakan dari aktifitas yang belum selesai
dikerjakan.
2. Analisa perbedaan : adalah analisa yang membandingkan
antara data perencanaan dengan kinerja yang sebenarnya
untuk menemukan penundaan yang terjadi pada jadwal
proyek.
3. Pengukuran kinerja : adalah perkiraan tingkat kesulitan
dari penundaan yang terjadi dengan mengukur kinerja
proyek dibandingkan terhadap rencana proyek. Alat ukur
yang umum digunakan adalah diagram perbandingan
jadwal, yaitu merupakan cara untuk menunjukkan
perbedaan antara kinerja sebenarnya dengan yang
direncanakan.
Diagram,tersebut menghasilkan informasi tentang kondisi
terkini dari proyek dan dapat digunakan untuk
menentukan apakah proyek sesuai atau tidak dengan
jadwal yang ditentukan.

3.3.3 Pengawasan Anggaran Dana
Pemantauan dilakukan dengan melihat biaya aktual yang timbul
dan membandingkanya dengan baseline cost (anggaran). Apakah
biaya aktual berada dalam rentang kendali atau tidak, dapat dilihat
pada tampilan Gantt Chart – Cost dalam lampiran 1 Baseline proyek..
Pengawasan terhadap biaya dalam sebuah proyek merupakan
satu- satunya cara untuk memastikan bahwa anggaran proyek
merupakan bagian dari kesuksesan proyek. Pengawasan biaya
meliputi penanganan perubahan permintaan melalui proses
pengawasan perubahan yang terintegasi. Perubahan permintaan dapat
berubah-ubah antara kemungkinan overrun pada keuangan yang sah
dan penggunaan sumber daya yang tidak sesuai.
Ada beberapa masukan, alat bantu dan teknik, serta keluaran
untuk melakukan pengawasan terhadap biaya proyek. Masukan yang
digunakan pada proyek ini adalah :
menunjukkan tanggal yang direncanakan, tanggal sebenarnya
dan durasi yang sebenarnya dari pekerjaan setiap aktifitas.
▪ Baseline biaya : merupakan anggaran dana pada sutau
tahapan. Tujuan dari baseline baiya ini adalah untuk
menyediakan dsaar pengukuran, pengawasan dan
pengendalian dari keseluruhan kinerja proyek.
▪ Rencana Manajemen proyek : rencana manajemen proyek dan
rencana manajemen anggaran dana menjelaskan tentang
kebijakan dan prosedur dari perusahaan yang harus dipatuhi.
Untuk alat bantu dan teknik yang digunakan pada pengawasan biaya
proyek ini, yaitu antara lain :
1. Manajemen perbedaan: hal ini menggambarkan berbagai
tingkat dari perbedaan (durasi dan biaya) yang harus dikelola.
2. Review kinerja proyek: review kinerja proyek
membandingkan biaya setiap aktifitas yang mengalami
kelebihan biaya, aktitas yang dijadwalkan, serta milestone

yang telah dicapai.
Sedangkan hasil dari proses pengawasan proyek antara lain :
1. Usulan tindakan perbaikan : merupakan langkah-langkah yang
harus dilakukan oleh pimpinan proyek untuk memastikan
bahwa setiap pekerjaan yang akan datang akan mendukung
rencana manajemen proyek saat ini.
2. Permintaan perubahan : permintaan perubahan biasanya
dihasilkan dari usulan tindakan perbaikan.
3. Pengukuran kinerja : adalah perkiraan tingkat kesulitan dari
penundaan yang terjadi dengan mengukur kinerja proyek
dibandingkan terhadap rencana proyek.
4. Pembaharuan baseline biaya: pembaharuan terhadap baseline
biaya menyetujui perubahan pada baseline biaya saat ini.
Dengan memperbaharui baseline maka dapat digunakan
sebagai ukuran yang realistik pada kinerja anggaran dana
proyek.
3.3.4 Pengawasan Kualitas
Pengawasan terhadap kualitas merupakan proses perbandingan
antara produk yang dihasilkan dengan standar kualitas yang telah
ditetapkan pada perencanaan kualitas sebelumnya.
Teknik yang dilakukan untuk melakukan pengawasan terhadap
kualitas, yaitu :
▪ Pengukuran pengendalian kualitas : merupakan hasil dari
aktifitas membandingkan produk dari proyek dengan standar
dan proses kualitas yang telah ditetapkan. Hal ini merupakan
pemeriksaaan yang sebenarnya untuk memastikan kualitas
dari produk dan jasa yang dibangun.
▪ Pertemuan status review : adalah pertemuan yang diadakan
secara rutin dengan seluruh anggota tim proyek untuk
mendapatperubahan informasi yang terjadi mengenai proyek.
menunjukkan tanggal yang direncanakan, tanggal sebenarnya

dan durasi yang sebenarnya dari pekerjaan setiap aktifitas.
3.3.5 Pelaporan
Pelaporan adalah proses pengumpulan keseluruhan data baseline
dan mendistribusikan informasi tersebut kepada sponsor ataupun
anggota tim proyek. Kegunaan dari laporan adalah untuk menjelaskan
bagaimana sumber daya digunakan untuk memenuhi sasaran proyek.
Pelaporan harus memuat informasi yang berkaitan dengan ruang
lingkup, jadwal, biaya, resiko dan kualitas.
Yang menjadi masukan dalam proses pelaporan , yaitu :
1. Deliverables : adalah segala produk, layanan, atau hasil yang
berbeda yang harus dihasilkan untuk menyelesaikan sebuah
proses, tahapan dari proyek. Ketika seluruh produk yang
dihasilkan telah disetujui, maka tahap pelaksanaan proyek
dinyatakan selesai dan penutupan proyek dapat dimulai.
2. Pengukuran pengendalian kualitas : merupakan hasil dari
aktifitas membandingkan produk dari proyek dengan standar
dan proses kualitas yang telah ditetapkan. Hal ini merupakan
pemeriksaaan yang sebenarnya untuk memastikan kualitas
dari produk dan jasa yang dibangun.
3. Pengukuran kinerja : adalah perkiraan tingkat kesulitan dari
penundaan yang terjadi dengan mengukur kinerja proyek
dibandingkan terhadap rencana proyek.
4. Informasi kinerja aktifitas : adalah sumber data mengenai
informasi status dan kualitas dari seluruh aktifitas yang telah
selesai dikerjakan. Hal ini digunakan untuk memastikan
apakah seluruh aktifitas yang dibutuhkan telah benar-benar
selesai dikerjakan dan kontrak proyek telah diakhiri.
5. Permintaan perubahan yang telah disetujui.
Dari beberapa masukan yang ada tersebut diolah dengan beberapa alat
bantu dan teknik berikut, antara lain :
1. Pertemuan status review : adalah pertemuan yang diadakan
secara rutin dengan seluruh anggota tim proyek untuk
mendapatperubahan informasi yang terjadi mengenai proyek.
2. Sistem pelaporan waktu : adalah catatan yang mendukung
informasi tentang waktu yang dihabiskan untuk setiap aktifitas

pada proyek.
3. Sistem pelaporan biaya : adalah catatan yang mendukung
informasi tentang biaya yang dihabiskan untuk setiap aktifitas
pada proyek.
Dengan menggunakan alat bantu dan teknik tersebut diatas akan
sangat membantu dalam proses pembuatan laporan performa proyek
yang efisien. Proses pelaporan berkaitan dengan dokumentasi
performa proyek secara keseluruhan. Beberapa keluaran dari proses
pelaporan , yaitu :
1. Laporan kinerja
2. Permintaan perubahan
3. Usulan tindakan perbaikan
3.3.6 Matriks Proyek
Mengumpulkan matriks (ukuran) pada sebuah proyek merupakan
salah satu proses manajemen proyek yang paling baik dilakukan tetapi
sangat sulit untuk diterapkan. Yang penting untuk dijadikan matrik
pada proyek adalah informasi tentang estimasi durasi, durasi aktual
dan informasi tentang estimasi biaya serta biaya aktual.
Matriks proyek merupakan alat bantu untuk pengendalian kualitas
dan manajemen proyek. Matriks mengukur atribut yang berbeda dari
proyek. Matriks dapat digunakan untuk menemukan lokasi yang
mungkin menjadi penyebab masalah.
Yang menjadi matrik pada proyek ini akan digambarkan pada
tabel berikut :
Matriks
(Ukuran)
Bagaimana mengukur
matrik
Penanggung
jawab
Waktu
penyelesaian
Untuk setiap tahapan dalam
proyek, catat waktu atau
tanggal mulai tahapan sejak
awal permulaan aktifitas
dikerjakan.
Pimpinan Proyek&
pekerj yang
bertanggung jawab
pada setiap tahapan.
Mulai proyek Dihitung pada akhir bagian Pimpinan Proyek
Selesai proyek Dihitung pada akhir bagian Pimpinan Proyek
Presentase
Milestone yang
telah dicapai
Berapa persen milestone yang
tercapai dari ¼ waktu
pelaksanaan proyek
Pimpinan Proyek
Kesuksesan
(penyelesaian)
persen
Pada akhir bagian, berapa
persen pekerjaan yang berakhir
secara normal dibandingkan
dengan pekerjaan yang selesai
tertunda.
Pimpinan Proyek&
pekerj yang
bertanggung jawab
pada setiap
tahapan.

3.4 Rencana Manajemen Resiko
Proses pengelolaan resiko membantu untuk menentukan resiko yang
potensial dari sebuah proyek. Manajemen resiko terdiri atas 3 proses
utama, yaitu :
1. Identifikasi resiko → merupakan aktifitas yang digunakan untuk
melakukan identifikasi resiko potensial yang mungkin terjadi
serta menjelaskan hubunganya. Setelah proses identifikasi resiko
biasanya diikuti dengan proses analisa resiko secara kualitatif.
Output dari proses ini adalah daftar resiko yang mungkin terjadi
dan detail semua resiko yang telah terindetifikasi, termasuk
kategori resiko, penyebab resiko, kemungkinan terjadi, dampak
dari resiko, serta penanggung jawab resiko.
Tahapan
terjadi
Resiko
Daftar Resiko Asal Resiko Pengaruh resiko
Penanggung
jawab
A. Perencanaan
Proyek
Estimasi kurang
akurat
Salah
menggunakan
teknik estimasi
Budget over cost
dan
Time overrun
Pimpinan
proyek
Perencanaan
kurang lengkap
Kurang
pertimbangan
membuat
perencanaan
Pelaksanaan
proyek tidak
berjalan lancar.
Pimpinan
proyek
Kurang
pengawasan dan
komunikasi antar
anggota tim
proyek
Tidak ada
pengaturan
komunikasi antar
anggota tim proyek
Hasil kerja tidak
sempurna /
penyelesaian
masalah terlambat.
Pimpinan
proyek
Ruang lingkup,
jadwal,biaya,sasaran
proyek kurang jelas
Tidak detail dalam
menentukan
sasaran proyek.
Pelaksanaan
proyek tidak
berjalan lancar
karena sasaran
tidak jelas
Pimpinan
proyek
Perubahan
keuangan
Perubahan durasi
kerja
Budget over cost Pimpinan
proyek
Tidak mempunyai
cukup waktu untuk
merencanakan
Kurang cepat
membuat
perencanaan
Keputusan yang
diambil sesaat dan
berubah- ubah
Pimpinan
proyek
Beban kerja
berlebihan yang
tidak diantisipasi
Tidak melakukan
resourcelevelling
Resource yang
digunakan
menumpuk dan
kerja tidak bisa
maksimal
Pimpinan
proyek
B. Identifikasi
kebutuhan
Perubahan
permintaan akibat
error
Kurang komunikasi
dengan pengguna
Surveyor
Requirement kurang Identifikasi
kebutuhan kurang
lengkap
Sistem yang
dihasilkan tidak
sesuai requirement
Surveyor

C.
Analisa
kebutuh
an
Pekerja yang
kurang
berpengalaman
Kriteria yang salah
pada proses
perekrutan
Hasil pekerjaan
kurang sempurna
Kepala
Personalia
Penggunaan teknik
analisa kebutuhan
yang kurang tepat
Penentuan teknik
analisa kurang
tepat
Hasil Analisa tidak
valid
Analis
Kehilangan pekerja
pada saat penting
(mis. krn sakit)
Karena lingkungan
kerja kotor / kondisi
fisik pekerja
kurang fit.
Aktifitas yang
penting dapat
terganggu /
terlambat
Semua
anggota tim
D. Desain
sistem
Desain sistem
kurang lengkap
Hasil analisa kurang
lengkap
Kesulitan dalam
pembuatan aplikasi
Analis
Pekerja yang
kurang
berpengalaman
Kriteria yang salah
pada proses
perekrutan
Hasil pekerjaan
kurang sempurna
Kepala
Personalia
Kehilangan pekerja
pada saat penting
(mis. krn sakit)
Karena lingkungan
fisik pekerja
kurang fit.
Aktifitas yang
penting dapat
terganggu /
terlambat
Semua
anggota tim
E. Pembuatan
aplikasi
Pekerja yang
kurang
berpengalaman
Kurang teliti pada
perekrutan pekerja
Hasil pekerjaan
kurang sempurna
Kepala
Personalia
Tahapan
terjadi
Resiko
Daftar Resiko Asal Resiko Pengaruh resiko
Penanggung
jawab
Kehilangan pekerja
pada saat penting
(mis. krn sakit)
Karena lingkungan
fisik pekerja
kurang fit.
Aktifitas yang
penting dapat
terganggu /
terlambat
Semua
anggota tim
Penggunaan
teknologi berubah
Penentuan
teknologi tidak
dipertimbangkan
Butuh waktu untuk
belajar teknologi
baru
Programmer
Kerusakan &
kegagalan dari segi
teknis (komputer
rusak,listrik
padam,dll)
Kecerobohan
pekerja dalam
menggunakan
komputer / faktor
eksternal (pihak
PLN)
Aktifitas yang
penting dapat
terganggu /
terlambat
Semua
anggota tim
F. Uji Coba
Aplikasi
Kehilangan pekerja
pada saat –saat
yang penting (mis.
Krn sakit)
Karena lingkungan
fisik pekerja
kurang fit.
Aktifitas yang
penting dapat
terganggu /
terlambat
Semua
anggota tim
2. Analisa hasil resiko → membutuhkan hasil dari proses identifikasi
resiko sebagai input pada proses ini. Proses ini merubah dari daftar
resiko yang ada dengan pemberian prioritas dan penggolongan
resiko. Hasil akhirnya untuk meminimalkan dampak dari resiko
yang sudah teridentifikasi, kemudian merubah kemungkinan
terjadi dari daftar resiko, dan kecenderungan dari hasil identifikasi
resiko sebagai output dari proses ini.

No. Daftar Resiko
Kemungkina
n resiko
Akibat
resiko
Tindakan Penjelasan
Tindakan
A. Estimasi kurang akurat Tinggi Tinggi Dikurangi Penyesuaian jadwal
dan sumber daya
Perencanaan kurang
lengkap
Tinggi Tinggi Dikurangi Membuat detail dari
perencanaan
sebelumnya &
terdokumentasi (Project
Plan)
Kurang pengawasan dan
komunikasi antar anggota
tim proyek
Sedang Tinggi Dihindari Lebih sering
melakukan pertemuan
dengan anggota tim
untuk evaluasi dan
review.
Ruang lingkup,
jadwal,biaya,sasaran proyek
kurang jelas
Rendah Tinggi Dikurangi Membuat detail dari
sasaran proyek supaya
lebih jelas maksudnya.
Perubahan keuangan Sedang Sedang Dikurangi Menyesuaikan jadwal
dan sumber daya di
akhir tiap
tahap
Tidak mempunyai cukup
waktu untuk merencanakan
Tinggi Sedang Dikurangi Memaksimalkan waktu
yang ada untuk
merencanakan.
Beban kerja berlebihan
yang tidak diantisipasi
Rendah Sedang Dihindari Melakukan resource
levelling.
B. Perubahan permintaan
akibat error
Rendah Sedang Dikurangi Melakukan komunikasi
yang efisien dan rutin
Requirement kurang Sedang Tinggi Dicegah Melakukan studi
pustaka terlebih dahulu
sebelum

No. Daftar Resiko
Kemungkina
n resiko
Akibat
resiko
Tindakan Penjelasan
Tindakan
menyusun pertanyaan
identifikasi kebutuhan
C. Pekerja yang kurang
berpengalaman
Tinggi Tinggi Dikurangi Memperpanjang durasi
aktifitas /
memberikan
pelatihan yang
relevan
Penggunaan teknik analisa
kebutuhan yang kurang
tepat
Sedang Tinggi Dihindari Sebelumnya sudah
mempelajari karakter
proyek yg akan
dikerjakan dan memilih
teknik analisa yang
sesuai.
Kehilangan pekerja pada
saat penting (mis. Krn
sakit)
Sedang Tinggi Dikurangi Melakukan tindakan
antisipasi saat aktifitas
penting
(memperpanjang
durasi kerja, digantikan
dgn
pekerja lain)
D. Desain sistem kurang
lengkap
Sedang Tinggi Dikurangi Melakukan review pada
dokumentasi akhir
tahapan analisa.
Pekerja yang kurang
berpengalaman
pengerjaan aktifitas /
memberikan pelatihan
yang
relevan
Kehilangan pekerja ahli
pada saat penting (mis.
Krn sakit)
antisipasi saat aktifitas
penting (digantikan dgn
pekerja lain)
E. Pekerja yg ditunjuk kurang
berpengalaman
pengerjaan aktifitas
Kehilangan pekerja pada
sakit)
antisipasi saat
aktifitas penting
(memperpanjang
durasi kerja &
digantikan
dgn pekerja lain)
Penggunaan teknologi
berubah
Rendah Rendah Dihindari Mempertimbangkan
teknologi yang
digunakan
dengan sistem yang
akan dibangun.
Kerusakan & kegagalan
dari segi teknis (komputer
rusak,listrik padam,dll)
Sedang Sedang Dikurangi Melakukan back-up
data penting tiap hari.
Menyediakan peralatan
untuk supply listrik
(diesel)
F. Kehilangan pekerja pada
sakit)
Rendah Rendah Dikurangi Menggantikan tugas
pekerja ahli dengan
pekerja lain.

3. Evaluasi Jadwal terhadap resiko → dengan mengidentifikasi dan
menganalisa resiko akan terlihat pengaruh resiko tersebut terhadap
durasi aktifitas yang sudah direncanakan. Dengan demikian akan
dapat dilakukan evaluasi pengaruh resiko tersebut terhadap rencana
aktifitas.
3.5 Rencana Penyelesaian Proyek
Penutupan proyek mengikuti pola yang sama dengan semua proses
dalam manajemen proyek lainya, terdiri dari masukan dan keluaran yang
berhubungan dengan penutupan sebuah proyek, begitu juga alat bantu
atau teknik yang digunakan untuk membantu proses tersebut.
Masukan yang ada digunakan untuk memeriksa penyelesaian dan
mengesahkan semua hal penting yang telah diputuskan.. Masuka yang
ada antara lain :
1. Rencana manajemen proyek
2. Informasi kinerja pekerjaan
3. Hasil yang dikirimkan
Untuk memastikan bahwa semua hal penting telah selesai dilakukan
dan proyek telah memenuhi sasaran, pimpinan proyek akan melanjutkan
dengan menggunakan alat bantu dan teknik yang sama dengan proses
sebelumnya. Ada tiga hal yang menajdi output pada tahap penyelesaian
proyek, yaitu :
1. Penerimaan dan pengiriman hasil akhir proyek
2. Laporan akhir penutupan proyek
Pada penyelesaian proyek juga harus dipastikan bahwa semua tahapan
telah benar-benar selesai dilakukan. Dan semua produk dan dokumentasi
yang dihasilkan telah di serahkan pada klien.
4. Rencana Proses Teknis
4.1 Model Proses
Gambar berikut menunjukkan keterkaitan antara aktifitas proyek yang
utama dengan proses pendukung.

Sedangkan gambar berikut menjelaskan tentang alur informasi dan
produk yang dihasilkan masing-masing aktifitas antara satu aktifitas
dengan yang lain.
Review yang direncanakan
No. Tanggal Tahapan Review
terhadap
1. 5/02/19 Identifikasi
kebutuhan
Dokumen hasil identifikasi kebutuhan pada
pengguna/klien.
Menyimpulkan sementara layanan apa yang
dibutuhkan oleh pengguna dari sistem yang akan
dibangun.
2. 5/20/19 Analisa
kebutuhan
Dokumen SKPL yang dihasilkan dari tahapan
analisa. Menyetujui spesifikasi kebutuhan sistem
yang telah dijelaskan
pada dokumen tersebut.
3. 6/14/19 Desain
sistem
Dokumen deskripsi detail desain sistem. Dokumen
ini menjelaskan dengan rinci proses dan data dari
masing-masing proses pada sistem. Review
dilakukan terhadap seluruh isi dokumen ini.
4. 7/12/19 Pembuatan
aplikasi
Aplikasi yang telah dibangun, apakah telah sesuai
dengan
perencanaan pada desain sistem.
5. 8/1/19 Uji coba
aplikasi
Hasil uji coba aplikasi apakah sudah memuat semua
skenario yang mungkin diterapakan pada aplikasi.
Milestone utama

No. Tanggal Tahapan Produk yang
dihasilkan
Hasil yang harus
dicapai
1. 2-05-2019 Identifikasi
Kebutuhan
Pertanyaan identifikasi
kebutuhan
Pertanyaan identifikasi
kebutuhan selesai dibuat
Kebutuhan
Form identifikasi
kebutuhan dan
pertanyaan identifikasi
kebutuhan
Persiapan Identifikasi
kebutuhan selesai
Kebutuhan
Form identifikasi
kebutuhan telah terisi
dan dijawab oleh user
Pelaksanaan Identifikasi
Kebutuhan selesai
Kebutuhan
Hasil identifikasi
kebutuhan
telah dievaluasi dan di
review
Tahap Identifikasi
Kebutuhan selesai
5. 14-05-2019 Analisa
Kebutuhan
Dokumentasi
kebutuhan viewpoint
Dokumentasi viewpoint
selesai
6. 16-05-2019 Analisa
Kebutuhan
SKPL Dokumen SKPL selesai
dibentuk
7. 20-05-2019 Analisa
Kebutuhan
Hasil analisa yang telah
dievaluasi
Tahap Analisa Kebutuhan
selesai
8. 3-06-2019 Desain
sistem
Dokumen deskripsi
detail
desain
Dokumen Deskripsi Detail
desain selesai
9. 14-06-2019 Desain
sistem
Detail desain yang telah
direview
Tahap detail desain
10. 12-07-2019 Pembuatan
aplikasi
Aplikasi rumah sakit Tahap pembuatan
aplikasi selesai
11 1-08-2019 Uji coba
aplikasi
Aplikasi yang telah
diuji coba
Tahap uji coba aplikasi
selesai.
Project Deliverable
Dokumen dan produk yang diserahkan sebagai hasil dari proyek
meliputi dua kategori berikut :
• Project management-related deliverables: project Plan , project
charter, scope statement, WBS, schedule, cost baseline, status
reports, final project presentation, final project report, dan
dokumentasi lain yang berkaitan dengan project.
• Product-related deliverables: Spesifikasi Kebutuhan Perangkat
Lunak, Deskripsi detail desain, source code aplikasi..
4.2 Metode, Alat bantu dan Teknik
Merupakan metodologi, alat bantu serat teknik yang digunakan selama
proyek berlangsung.

Metode
Metode pengembangan aplikasi pada proyek ini menggunakan
Waterfall SDLC. Pendekatan pengembangan aplikasi dimulai pada
level sistem dan prosesnya melalui gambar berikut :
Metode ini digunakan karena tergolong mudah jika diterapkan pada
proyek dengan kebutuhan user yang stabil (tidak berubah-ubah). Pada
akhir setiap tahapan dalam metode ini selalu dihasilkan sebuah
dokumen yang akan digunakan sebagai pedoman bagi tahapan
selanjutnya.
Metode lain yang juga dgunakan pada proyek adalah UML. UML
merupakan proses rekayasa perangkat lunak. UML menyediakan
pendekatan perancangan perangkat lunak yang berorientasi objek
melalui gambaran berbagai diagram rancangan perangkat lunak.
Alat bantu dan Teknik
Untuk tahapan analisa kebutuhan dilakukan dengan menggunakan
metode VORD dan software VORDTool sebagai alat bantu untuk
mengelola requirement dari pengguna, sedangkan spesifikasi
kebutuhan yang dihasilkan dikumpulkan dalam bentuk dokumen
SKPL.
Pada tahapan desain menggunakan UML diagram untuk memodelkan
spesifikasi kebutuhan aplikasi dengan alat bantu Power designer 12.
Diagram UML yang akan dibuat meliputi : Use case diagram, Class
diagram, dan Sequence diagram. Dokumen hasil desain yaitu

deskripsi detail desain yang selanjutnya akan diserahkan pada
programmer untuk membangun program aplikasi.
Program aplikasi dibuat dengan menggunakan bahasa pemrograman
Java 8 yang berorientasi objek. Sedangkan untuk database digunakan
MySQL 5.0. Tahapan terakhir, yaitu uji coba menggunakan unit
testing kemudian dilanjutkan dengan Integration testing.
Secara umum hasil dari seluruh tahapan terdiri dari 3 hal, yaitu :
1. Dokumen Spesifikasi kebutuhan Perangkat Lunak (SKPL)
2. Dokumen Deskripsi Detail Desain
3. Aplikasi Aplikasi Layanan Penanganan Keluhan, meliputi 2
Aplikasi: Aplikasi layanan penanganan keluhan dan Aplikasi
penanganan personel Biro TI.
4.3 Infrastruktur
Bagian ini akan menjelaskan tentang rencana untuk membangun dan
memelihara lingkungan pembangunan sistem, baik dari segi perangkat
keras, perangkat lunak, jaringan, kebijakan, standard, prosedur serta
fasillitas lain yang diperlukan utnuk melaksanakan proyek ALPK. Sumber
daya yang terlibat meliputi komputer yang digunakan, LAN (Local Area
Network), aplikasi yang membantu dalam melakukan analisa dan
pembuatan desain, aplikasi untuk melakukan implementasi desain (bahasa
pemograman), aplikasi untuk membantu aktifitas manajemen proyek, dan
segala sumber daya lain yang terlibat pada pengembangan proyek ini.
Perangkat keras :
Dibutuhkan 5 buah personal komputer dengan spesifikasi sebagai berikut :
1. Hard disk drive minimal 20 GB
2. Memori minimal 256MB DRAM
3. Processor Intel Pentium IV 2GHz atau yang setara.
4. Monitor min. 15”, LAN Card, VGA Card minimal 64Mb
5. CD- ROM/RW
Dibawah ini adalah susunan infrastrukutur ALPK dari segi antar muka
perangkat keras :

`
`
`
`
`
`
Perangkat lunak yang diperlukan untuk pembangunan ALPK :
1. Sistem operasi : Windows XP home atau profesionaledition
2. Analisa : VordTool
3. Desain : Power Designer 12
4. Database : DBMS MySQL server 5.0.2, MySQL Front, SQL
Yog.
5. Pemograman : Java 8, Spring, Express Quantum Grid Component
dan VCL Skin Component
6. Pendukung : Microsoft office 2003 (Word dan Project), SnagIt
dan HyperSnap Acrobat reader, Web browser.
Yang dijadikan sebagai standar dalam proyek pembangunan ALPK, antara lain :
1. IEEE 830 tentang Software Requirement spesification dan IEEE 1233
tentang Sistem Requirement Spesification yang digunakan untuk
membuat dokumen SKPL.
2. IEEE 1016 tentang Software design description sebagai panduan dalam
membuat deskripsi detil desain perangkat lunak.
3. IEEE 1058-1998 Standard for Software Project ManagementPlans.
4. PMBOK Guide tahun 2004.
Personel yang terlibat dalam proyek ini, antara lain (lebih jelas dapat dilihat
pada subbab 3.1.2 pengaturan kepegawaian) :
1. Seorang manajer proyek
2. Seorang team leader
3. 3 orang surveyor
administrator
firewall
Komputer
server
Hub D-link
Client 4
Client 1
Staff
Staff Biro TI
Client 5
Client 2
Staff
Staff_pengadaan
Client 6
Client 3
Staff
Staff Layanan

4. 2 orang analis
5. 5 orang programmer
4.4 Penerimaan Produk
Rencana penerimaan produk ALPK ini menjelaskan secara singkat
mengenai tanggung jawab dari sumber daya yang terlibat dan
menggambarkan kriteria dari penerimaan masing-masing produk yang
harus diselesaikan selama proyek berlangsung. Aktifitas penerimaan
produk disebarkan pada sepanjang siklus hidup proyek untuk menandai
adanya kemajuan terhadap tujuan hasil akhir produk. Oleh karena itu,
rencana ini tidak hanya ditujukan pada penerimaan akhir produk saja, tetapi
juga peneriman dari seluruh aktifitas yang kritis sebagai bagian dari
proses pembangunan produk.
Peran dan Tanggung Jawab Staff
Staff Tanggung
Jawab
Pimpinan proyek ▪ Membuat dan memelihara pengendalian versi dari
rencana penerimaan produk dan memastikan bahwa
rencana penerimaan produk telah dijalankan.
▪ Berpartisipasi dan memimpin review pada akhir tiap
tahapan.
Perwakilan kustomer ▪ Bekerja sama dengan analis dan programmer untuk
untuk membuat, memelihara, dan menjalankan
rencana penerimaan produk proyek ALPK
Analis dan Programmer ▪ Bekerja sama dengan perwakilan kustomer untuk
membuat, memelihara, dan menjalankan rencana
penerimaan produk proyek ALPK
▪ Menetapkan produk yang dihasilkan pada tiap
tahapan serta
membuat kriteria dan metode penerimaan hasil akhir
produk pada tiap tahapan.
Kriteria Penerimaan produk :
Artifa
ct
Kriteria Penerimaan Metode Evaluasi
ADMINISTRASI PROYEK
Detail Jadwal Proyek Jadwal proyek yan gtelah dibuat
masih dalam rentang waktu
yang ditentukan dalam project
charter
Review antara tim proyek
dengan pihak stakeholder
Rencana Pengelolaan
Kebutuhan
Dokumen rencana dikirim dan
disetujui untuk dilakukan
proses review dan persetujuan
Proses review
PERKEMBANGAN
KEMAJUAN

Use Case / Dokumen
Kebutuhan
Use case dikirim dan disetujui
untuk setiap proses review dan
persetujuan
use case.
Review dan persetujuan
use case, Verifikasi dan
validasi
kebutuhan.
Class Diagram Persetujuan proyek Proses pembuatan dan
review dari activity
diagram
Desain database Persetujuan proyek Proses pembuatan dan
review
Artifact Kriteria Penerimaan Metode Evaluasi
dari desain database
Desain antar muka Persetujuan proyek , review tim
desain sistem (analis)
Prosedur persetujuan
desain antar muka.
Skenario uji coba unit Persetujuan untuk tiap skenario
uji coba unit.
Proses persetujuan
pada rencana uji coba
Skenario uji coba
integrasi
Persetujuan untuk tiap skenario
uji coba integrasi.
Proses persetujuan
pada rencana uji coba
PRODUK AKHIR
Dokumentasi dan
training yang
diadakan
Kehadiran peserta training,
tanggal pelaksanaan training
Daftar kehadiran peserta
Hasil uji coba sistem Review hasil uji coba,
persetujuan proyek
Dijelaskan pada rencana
uji coba
Verifikasi dan
Validasi
kesiapan sistem
Dilakukan pada setiap akhir
tahapan
Menggunakan daftar
aktfitas.
5. Rencana Pendukung
5.1 Verifikasi dan Validasi
Rencana verifikasi dan validasi ini menjelaskan tentang aktifitas yang
dilakukan untuk melakukan verifikasi dan validasi dari proyek
pembangunan ALPK. Pelaksanaan proses verifikasi dan validasi dalam
proyek ini tidak dilakukan oleh tim SQA, melainkan menjadi salah satu
tanggung jawab dari pimpinan proyek. Proyek pembangunan ALPK
melakukan beberapa aktifitas verifikasi dan validasi berikut ini :
Review:
Review merupakan proses atau pertemuan (rapat) yang dilakukan selama
sebuah hasil produk telah selesai dan siap ditampilkan kepada seluruh
anggota tim proyek untuk persetujuan. Review memiliki aturan yang jelas
dan prosedur yang sudah pasti, yang dapat dilihat pada bagian Jaminan
kualitas (sub bab 5.3). Tabel berikut menunjukkan jadwal pelaksanaan
review selama pelaksanaan proyek berlangsung.
terhadap
1. 5/02/19 Identifikasi
kebutuhan
Dokumen hasil identifikasi kebutuhan pada
pengguna/klien.
Menyimpulkan sementara layanan apa yang

dibutuhkan oleh pengguna dari sistem yang akan
dibangun.
2. 5/20/19 Analisa
kebutuhan
Dokumen SKPL yang dihasilkan dari tahapan
analisa. Menyetujui spesifikasi kebutuhan sistem
yang telah dijelaskan
pada dokumen tersebut.
3. 6/14/19 Desai
n
siste
m
Dokumen deskripsi detail desain sistem. Dokumen
ini menjelaskan dengan rinci proses dan data dari
masing-masing proses pada sistem. Review
dilakukan terhadap seluruh isi
dokumen ini.
4. 7/12/19 Pembuatan
aplikasi
Aplikasi yang telah dibangun, apakah telah sesuai
dengan perencanaan pada desain sistem.
5. 8/1/19 Uji coba
aplikasi
Hasil uji coba aplikasi apakah sudah memuat semua
scenario yang mungkin diterapakan pada aplikasi.
Uji Coba :
Uji coba aplikasi dilkukan menggunakan beberapa teknik pengujian
aplikasi meliputi :
1. Black box testing
2. Unit testing
3. Integration testing
Hasil dari uji coba aplikasi akan dituliskan pada dokumen hasil uji coba
aplikasi beserta skenario yang dilakukan pada saat uji coba. Tabel
dibawah ini menunjukkan jadwal pelaksanaan uji coba selama
pelaksanaan proyek berlangsung :
terhadap
1. 01/08/19 Uji coba
aplikasi
Masing-masing modul aplikasi dalam APLK.
2. 14/08/19 Uji coba
aplikasi
Keseluruhan aplikasi ALPK.
Penjadwalan proses verifikasi dan validasi
Proses verifikasi dan validasi dilakukan pada setiap tahpan dalam
pelaksanaann aktifitas proyek. Merupakan tanggung jawab pimpinan
proyek untuk merencanakan review pada seluruh dokumen hasil aktifitas
proyek. Setiap sebuah aktifitas diselesaikan, hasil dari aktifitas tersebut di
review sesuai denagn kriteria penerimaan masing-masing produk. Produk
yang dimaksud disini bisa berupa dokumen, form, laporan kinerja atau
aplikasi. Tabel berikut menunjukkan jadwal uji coba dan review yang
akan dilakukan selama proyek pembangunan ALPK.

Metode untuk melakukan verifikasi dan validasi kebutuhan adalah
dengan melakukan review terhadap dafatr kebutuhan. Berikut merupakan
gambaran proses review kebutuhan yang dilakukan dalam proyek :
5.2 Penanganan Dokumen dan Form
Rencana dokumentasi ini menjelaskan tentang bentuk, format dan
jenis dokumentasi hasil dari proyek ALPK ini. Dokumen dan form yang
dihasilkan proyek ditujukan pada dua kelompok pengguna, yaitu kepada
pengembang dan kepada klien.
Tabel berikut menunjukkan daftar dokumen dan form yang harus
disiapkan, bentuknya, penamaan serta penomoran versi dokumen dan
form, penanggung jawab pembuat dokumen dan form, penanggung jawab
review dokumen dan form.
No. Jenis
Dokumen/Form
Bentuk
dokumen/for
m
Pembuat
dokumen/for
m
Penanggung jawab
review
dokumen/form
1. Perencanaan proyek
(PP-06 ALPK)
Dokumen Pimpinan
proyek
Seluruh tim
manajemen proyek dan
sponsor.
2. Project Scope
Statement
(ALPK 062 PSS v1.0)
Dokumen Pimpinan
proyek
Seluruh tim
manajemen
proyek dan sponsor.
3. SKPL (PP-11 ALPK) Dokumen Analis Programmer
4. Deskripsi Detail Desain
(PP- 21 ALPK)
Dokumen Analis Programmer
5. Project Charter (ALPK
061
PC v1.0)
Dokumen PMO Pihak sponsor
6. Risk Management (ALPK
066 RMG v1.0)
Dokumen Pimpinan
proyek
Seluruh tim
manajemen
proyek dan sponsor.
7. Change request form
(dibuat saat terjadi
permintaan perubahan
Form Seluruh tim
proyek
Pihak yang terkait
dengan permintaan
perubahan

saja)
8. Status report (ALPK 074
SR
v1.0)
Form Pimpinan
proyek
Seluruh tim
manajemen
proyek dan sponsor.
9. Laporan kemajuan
proyek (ALPK 075 PR
v1.0)
Form Pimpinan
proyek
Seluruh tim
manajemen proyek dan
sponsor.
11. Hasil pembahasan
pertemuan
Form Pimpinan
proyek
Pimpinan proyek
12. Laporan akhir
penerimaan proyek
(ALPK 081 FPR v1.0)
Dokumen Pimpinan
proyek
Pihak sponsor
13 Deliverableacceptance
(ALPK 082 DVA v1.0)
Dokumen Pimpinan
proyek
Pihak sponsor
5.3 Jaminan Kualitas
Bagian ini bertujuan untuk mnyediakan referensi tunggal mengenai
kualitas dalam proyek pembangunan ALPK. Pada bagian ini tidak
tercantum detail review, alat bantu dan teknik , serta berbagai kriteria
pengukuran kualitas. Bagian ini menjelaskan hal hal yang penting
berkaitan dengan jaminan kualitas.
Dokumen ini menjelaskan bagaimana perusahaan memproses
pengembangan mulai dari titik awal hingga mencapai kualitas perangkat
lunak yang paling tinggi.
Sasaran kualitas → bagian ini menjelaskan tentang kebutuhan kualitas
kebutuhan dari produk yang akan dibangun.Produk yang akan dibangun
harus memenuhi seluruh kebutuhan yang dijelaskan pada SKPL.
Kesesuaian antara produk dengan SKPL akan diperiksa pada saat uji
penerimaan produk (dapat dilihat pada subbab 4.4 Penerimaan produk).
Berdasarkan verifikasi klien ditentukan bahwa seluruh uji coba terhadap
produk telah dilewati dengan hasil yang memuaskan, sehingga produk
dianggap sebagai produk dengan kualitas yang juga memuaskan Hal ini
berarti bahwa produk sesuai dengan seluruh kebutuhan yang telah
disampaikan oleh klien dan diterima oleh klien.
Manajemen → menjelaskan tentang struktur organisasi dari tim atau pihak
yang akan melakukan penjaminan kualitas produk dari proyek,
bertanggung jawab dan mengkomunikasikan antara anggota tim untuk
membantu proses penjaminan kualitas. (dapat dilihat pada subbab 2.3

peran dan tanggung jawab).
Dokumentasi → Memberikan daftar dokumen yang dirancang untuk
memeriksa kesesuaian produk dengan standar kualitas yang ditentukan.
Daftar dokumen yang harus ada dan dibuat selama proyek berlangsung
dapat dilihat lebih lengkap pada subbab 5.2, Penanganan dokumen.
Matrik → Matrik menjelaskan mengenai matrik yang akan diukur pada
titik pengendalian tertentu selama pembangunan produk dan hal tersebut
akan digunakan untuk mengendalikan proses pembangunan perangkat
lunak. Mengenai marik yang diukur dalam proyek telah dijelaskan pada
subbab 3.3.6.
Rencana review → menjelaskan detail jadwal, sumber daya yang
digunakan, metode dan proses yang akan digunakan selama proses
review. Proses review yang lebih lengkap dituliskan pada subbab 5.4.
Alat bantu, teknik dan metodologi → menjelaskan alat bantu, teknik
dan metodologi yang digunakan dalam proyek. Dapat dilihat pada subbab
4.2
Manajemen resiko → dokumen ini memberikan informasi bagaimana
mengelola resiko yang berkaitan dengan proyek. Bagian ini menjelaskan
tugas dari pengelolaan resiko yang harus dilakukan, menjelaskan
tanggung jawab dan seluruh sumber daya tambahan yang dibutuhkan
untuk pengelolaan resiko yang efektif. Pada subbab 3.4 sudah dijelaskan
mengenai rencana pengelolaan resiko pada proyek ini.
Catatan kualitas → menjelaskan tentang proses dari penelusuran hal
yang penting berkaitan dengan kualitas .
5.4 Review
Review pada proyek terbagi atas tiga review utama, yaitu :
1. Review kebutuhan → fokus pada dokumen SKPL yang merupakan
hasil dari tahapan analisa kebutuhan. Proses ini dilakukan pada akhir
tahap analisa.

2. Review arsitektur → fokus pada dokumen detil desain yang merupkan
hasil dari tahap desain sistem. Dilakukan pada akhir tahap desain.
3. Review kode program→ fokus pada verifikasi kode-kodeprogram.
Review harus dilakukan terhadap setiap produk yang dihasilkan oleh
aktifitas utama dalam proyek. Tabel berikut menunjukkan jadwal detail
rencana review yang dilakukan selama proyek berlangsung :
No.
Tanggal
Review
Tahapan Review terhadap
Sumber
daya
review
Bentuk
presenta
si
review
1. 2-05-
2019
Identifikasi
kebutuhan
Ketepatan pertanyaan
yang ditulis pada form
survey, bagian (pihak)
yang akan dituju saat
survey
Surveyor Daftar
pertanyaan
2. 5-05-
2019
Idenitifikasi
kebutuhan
Pengumpulan dan
penyimpulan hasil
identifikasi
kebutuhan
Surveyor Dokumen
hasil survey
3. 8-05-
2019
Analisa
kebutuhan
Strukturisasi viewpoint
yang dibuat,
dokumentasi
kebutuhan dari hasil
survey
Analis Dokumentas
i kebutuhan
user
4. 12-05-
2019
Analisa
kebutuhan
Isi dan pembahasan
dalam
dokumen SKPL
Analis Dokumen
SKPL
5. 14-05-
2019
Desain
sistem
Rancangan database
sistem dan UML diagram
Analis ERD dan
diagram
UML
6. 16-05-
2019
Desain
sistem
Rancangan alur
tampilan
aplikasi
Analis Form
tampilan
aplikasi
(Grafis)
7. 20-06-
2019
Desain
sistem
Isi dan pembahasan
dalam dokumen
deskripsi detail
desain sistem
keseluruhan
Analis Dokumen
Deskripsi
detail
desain
8. 7-07-
2019
Pembuatan
aplikasi
Aplikasi yang telah
dibangun (fungsi-
fungsinya)
Programme
r
Hasil
aplikasi
serta
laporan

9. 01-08-
2019
Uji coba
aplikasi
Hasil uji coba aplikasi Programmer Laporan
hasil uji
coba sistem
dan
scenario uji
coba yang
dilakukan
terhadap
sistem.

MPPL MANAJEMEN PROYEK

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MPPL MANAJEMEN PROYEK

Similar to MPPL MANAJEMEN PROYEK (20)

Recently uploaded

Recently uploaded (20)

MPPL MANAJEMEN PROYEK