Dokumen ini merinci perencanaan proyek sistem pendaftaran SNMPTN dan SBMPTN 2017, yang bertujuan untuk menciptakan aplikasi terintegrasi untuk penerimaan mahasiswa baru. Proyek ini mencakup analisis kebutuhan, desain, pembuatan aplikasi, dan pengujian dalam waktu 3 bulan dengan anggaran Rp 500.000.000,-. Tim proyek terdiri dari berbagai posisi, termasuk manajer proyek, analis, programmer, dan penguji, dengan fokus pada keamanan informasi dan efisiensi proses penerimaan.

1. Dokumen Perencanaan Proyek
MPPL-D
Trastian Satria Wibowo (5114100016)
Dimas Hirda P (5114100147)

2. 1. Gambaran Umum Proyek
Proyek Sistem Pendaftaran SNMPTN dan SBMPTN 2017 ini bermaksud untuk
menghasilkan produk berupa aplikasi untuk penerimaan mahasiswa baru 2017 yang
terintegrasi. Sehingga satu calon mahasiswa hanya bisa masuk ke PTN hanya dengan 1 jalur
yaitu SNMPTN atau SBMPTN saja.
Sistem Pendaftaran SNMPTN dan SBMPTN 2017 memberikan kesempatan seluas-
luasnya kepada seluruh siswa lulusan sekolah menengah yang mempunyai prestasi akademik
terbaik di seluruh Indonesia untuk dapat mengikuti pendidikan tinggi program sarjana di
seluruh PTN di Indonesia tanpa adanya deskriminasi.
Sistem Pendaftaran SNMPTN dan SBMPTN 2017 dikembangkan dengan menggunakan
teknologi rasional database system MySQL 5, menggunakan PHP, JavaScript sebagai bahasa
pemrograman dan Laravel sebagai framework untuk aplikasi ini.
Proses-proses utama dari penerimaan mahasiswa baru 2017 yang didukung oleh aplikasi
Sistem Pendaftaran SNMPTN dan SBMPTN 2017, meliputi:
1.1. Tujuan, Ruang Lingkup dan Sasaran
Tujuan : Membuat produk aplikasi yaitu Sistem Pendaftaran SNMPTN dan
SBMPTN 2017 yang terintegrasi.
Ruang Lingkup : Produk ini ditujukan untuk diterapkan pada saat penerimaan calon
mahasiswa baru 2017. Untuk database aplikasi disiapkan supaya
dapat terhubung dengan data center di pusat. Pengembangan
sistem selanjutnya lebih diarahkan kepada bagian keamaan
informasi data.
Sasaran : Menghasilkan produk Sistem Pendaftaran SNMPTN dan
SBMPTN 2017 yang mampu mengoptimalkan proses penerimaan
mahasiswa baru 2017 serta sesuai dengan spesifikasi kebutuhan
untuk penggunanya.
Berikut ini project charter dari aplikasi SNMPTN dan SBMPTN 2017
1.2. Asumsi, Batasan dan Resiko
Asumsi
1. Kebutuhan infrastruktur, usaha yang sebenarnya, dan jadwal akan diselesaikan
setelah dilakukan identifikasi kebutuhan.
2. Ruang lingkup Sistem Pendaftaran SNMPTN dan SBMPTN 2017 pada proyek ini
dikerjakan dengan mempertimbangkan kebutuhan fungsional secara umum.
3. Detail dokumen kebutuhan (SKPL) akan disiapkan setelah dilakukan studi dan
akan ditanda tangani oleh klien pada periode tertentu.
4. Perubahan pada persetujuan dokumen kebutuhan akan diberkalkukan seperti
perbuahan permintaan dan omdifiaksi yang akan dianggap sebagai tambahan
tagihan pada pengguna.
5. Persoalan kinerja ditujukan untuk ketersediaan infrastruktur yang diinginkan oleh
pengguna.
6. Komitmen dari seluruh jajaran manajemen dan pekerja proyek.

3. 7. Kondisi pengembangan aplikasi aman dan kondusif.
Batasan
1. Waktu pelaksaan proyek 3 bulan mulai dari tanggal 1 Juni 2017 hingga 1 Agustus
2017.
2. 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
 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
5 Eksternal  Perubahan keuangan akibat kondisi yang
tidak kondusif
1.3. Penyerahan Proyek
Dokumen dan Produk yang diserahkan sebagai hasil dari proyek meliputi dua
kategori berikut :
1. Project management-related deliverables: Term of Reference, Project Plan,
project charter, project scope statement, WBS, schedule, cost baseline, status
reports, final project presentation, final project report, time and cost
management reports 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 penyerahannya.
Untuk penyerahan dokumentasi kebutuhan dan desain sistem menggunakan kertas yang
berupa dokumen. Sedangkan untuk produk datau aplikasi diserahkan dalam bentuk USB
Drive. Dokumen-dokumen tersebut harus terjada kerahasiannya. Semua hasil penyerahan
telah di back-up oleh pihak pengembang sistem.
1.4. Ringkasan Jadwal dan Anggaran Dana
Secara umum jadwal dari proyek terdiri atas beberapa aktifitas utama beserta
dengan anggaran dana yang di alokasikan untuk tiap aktifitas. Berikut merupakan
ringkasan jadwal beserta anggaran dana untuk proyek pembangunan Sistem Pendaftaran
SNMPTN dan SBMPTN 2017:

4. 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 terhadap
perencanaan proyek akan dilakukan jika diperlukan selama proyek masih berlangsung.
Setiap perubahan penting pada dokumen ini harus disahkan oleh pengguna dan disebarkan
kepada 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. Referensi
 ANSI, “PMBOK Guide”, Edisi ke-3, American National Standard, 2004.
 Hughes, Bob, dan Cotterel, Mike, “ Software Project Management”, Edisi
ke-2, The McGraw-Hill Companies, 1999.
 “Project Risk Management Handbook”, Edisi ke-1, Office of Project
Management Process Improvement, www.dot.ca.gov/hq/projmgmt, 2003.
 IEEE Computer Society , “IEEE 1058-1998 Standard for Software Project
Management Plans “, IEEE Computer Society, 1998.
1.7. Definisi dan Akronim
WBS Work Breakdown Structure
SKPL Spesifikasi Kebutuhan Perangkat Lunak
PERT Program Evaluation and Review Technique
VORD Viewpoint Oriented Requirement Definition
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 tim
proyek dengan pihak luar. Pihak yang berhubungan dan mendukung proyek adalah
sebagai berikut:
Organization Name of Liaison/Interface
Kementrian Riset Teknologi dan
Pendidikan Tinggi (Customer)
Pihak Pemesan Aplikasi
Data Center Kementrian Riset Teknologi
dan Pendidikan Tinggi
Penyedia database calon mahasiswa baru
Calon Mahasiswa Baru 2017 (Pemakai di
lapangan)
Pengguna

5. 2.2. Struktur Internal
Struktur organisasi dalam team proyek ini menggunakan tipe controlled
decentralized dimana tema telah menunjuk seorang leader (manajer proyek) sebagai
pemimpin proyek. Untuk lebih jelasnya tentang komunikasi antar kelompok dan individu
dilakukan secara horizontal.
Untuk lebih jelasnya tentang struktur organisasi dapat dilihat di gambar di bawah
ini :
Diagram Struktur Internal
Penjelasan dari diagram diatas secara umum bahwa tim proyek ini dipimpin oleh
seorang pemimpin proyek yang membawahi 5 bidang, yaitu: analis, programmer, trainers,
database administrator dan quality assurance. 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 semua proses pengerjaan
proyek
 Membuat perencanaan proyek serta pengawasan seluruh
aktifitas eksekusi proyek
 Membuat / mengumpulkan dokumentasi proyek setelah
selesai dilakukannya tahapan tertentu.
 Membuat laporan pertanggungjawaban setelah taham
implementasi selesai
 Memberikan pengarahan, teguran, dan peringatan kepada
anggota tim jika terjadi penyimpangan dalam pelaksanaan
proyek.
Analis  Melakukan analisa kebutuhan customer hinggal
menghasilkan spesifikasi fungsional dari sistem
informasi.
Project Manager
Trainers System Analyst
Staff
Programmer
Database
Administrator
Quality
Assurance

6.  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 SKPL.
Programmer  Membuat aplikasi harus berdasarkan detail desain yang
diberikan oleh pihak analis
 Membuat dokumentasi aplikasi baik itu database, maupun
aplikasi dalam bentuk USB Drive
 Membuat dokumentasi bantuan aplikasi berupa panduan
instalasi.
 Turut serta dalam melakukan ujicoba review hasil ujicoba
aplikasi.
Database
Administrator
 Mendefinisikan pola struktur database
 Mendefinisikan struktur penyimpanan dan metode akses
 Memberi kekuasaan pada user untuk
Quality Assurance  Menafsirkan dan menerapkan standar jaminan kualtias
dari sebuah sistem
 Mengevaluasi kecukupan standar jaminan kualitas.
 Meninjau pelaksaan dan efisiensi kuaitas dan inspeksi
sistem agar berjalan sesuai rencana.
Trainers  Memberikan informasi dan cara penggunaan dari sebuah
sistem kepada pengguna
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.
3.1.2. Pengaturan Kepegawaian
Staff yang diperlukan pada proyek ini untuk keseluruhan berjumlah 10
orang dengan pembagian sebagai berikut:
Staff Asal Durasi Kerja Jumlah
Pimpinan proyek Internal
Perusahaan
Selama proyek
berlangsung
1 orang
Analis Internal
Perusahaan
Selama fase identifikasi
kebutuhan
1 orang

7. Programmer Internal
Perusahaan
Selama fase
pembangunan aplikasi
dan ujicoba
3 orang
Database
Administrator
Internal
Perusahaan
Selama fase
pembangunan aplikasi
dan ujicoba
2 Orang
Quality Assurance Di Sewa Selama fase ujicoba
aplikasi
1 orang
Trainer Di Sewa Selama fase ujicoba dan
penggunaan aplikasi
2 orang
3.1.3. Perolehan Sumberdaya
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. Oleh karena itu rencana perolehan sumber daya beserta proses dan
penanggung jawabnya tidak akan dijelaskan disini.
3.2. Rencana Kerja
3.2.1. Work Breakdown Structure
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 sebagai
berikut:
No Aktifitas Produk
1 Identifkasi Kebutuhan Form identifikasi kebutuhan yang telah berisi
jawaban.
2 Analisa Kebutuhan Dokumen SKPL dan DPPL
3 Desain Sistem Dokumen Deskripsi Detail Sistem
4 Pembuatan Aplikasi Aplikasi Sistem Pendaftaran SNMPTN dan
SBMTPN 2017
5 Uji Coba Aplikasi Hasil testing dan performance aplikasi.
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 Sistem Pendaftaran SNMPTN dan SBMTPN
2017 yang dibuat berupa WBS (selengkapnya dapat dilihat pada subbab 3.2.1).

8. Sedangkan mengenai sumber daya proyek selengkapnya dijelaskan pada subbab
3.2.3 (alokasi sumber daya)
Tahap pertama dalam melakukan alokasi jadwal yaitu mengatur dependensi
(keterkaitan) antar aktifitas yang sudah tersusun. Keterkaitan tiap aktifitas dicatat
dalam kolom predecessor 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
3.2.3. Alokasi Sumber Daya
Sumberdaya yang diperlukan dan dilakukan 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
Staff Jumlah Tahapan
Pekerjaan
Kemampuan yang dimiliki
Project Manager 1 Orang Seluruh tahapan
pada proyek
-Kemampuan koordinasi
dan komunikasi yang baik
-Kemampuan manajerial
dan manajemen proyek IT
-Kemampuan
menyelesaikan masalah
Analis 1 Orang Identifikasi
Kebutuhan
-Mampu berkomunikasi
dengan klien
-Mampu berpikir seperti
pengguna
-Kritis dan detail dalam
berpikir
Analisis
Kebutuhan
-Mampu mengelompokan
fungsi dari identifikasi
kebutuhan
-Memahami metode analisis
yang digunakan
-Mampu membuat dokumen
SKPL yang detail
Desain Sistem -Mampu membuat diagram –
diagram UML

9. -Mengerti tentang database
-Menguasai tools pembuatan
diagram, seperti power
designer
Programmer 3 Orang Pembuatan
Aplikasi
-Menguasai bahasa
pemrograman html, php
-Menguasai kerangka kerja
laravel
-Menguasai mySql sebagai
DBMS
-Mampu mendesain front-
end dengan baik
Ujicoba Aplikasi -Mengerti teknik uji coba
yang digunakan
-Memahasi keseluruhan
sistem yang dibuat
Database
Administrator
2 Orang Pembuatan
Aplikasi
-Mengerti struktur database
yang digunakan
-Mampu menentukan hak
akses
Quality
Assurance
1 Orang Ujicoba Aplikasi -Mampu mengevaluasi
kualitas
-Mampu menginspeksi
sistem hingga sesuai
rencana
Trainer 2 Orang Ujicoba dan
Training Aplikasi
-Mampu mengsosialisasikan
penggunaan aplikasi
3.2.4. Alokasi Dana
Berikut merupakan tabel pemetaan dana pada setiap aktifitas yang terjadi dan telah
diasumsikan total biaya berdasarkan lama pengerjaan proyek dan sumber daya yang
telah terhitung didalamnya:
Aktifitas Biaya Total
Pengadaan 4 PC Rp 20.520.000,00
Planning Rp 47.520.000,00
Penggalian kebutuhan Rp 3.100.000,00
Persiapan identifikasi kebutuhan Rp 4.275.000,00
Pelaksanaan identifikasi kebutuhan Rp 2.125.000,00
Pengolahan dan penyimpulan hasil
identifikasi
Rp 1.500.000,00
Total biaya penggalian kebutuhan Rp 11.000.000,00
Analisa kebutuhan Rp 21.000.000,00
Identifikasi view point Rp 2.150.000,00
Strukturisasi view point Rp 2.000.000,00

10. Dokumentasikan kebutuhan view
point
Rp 6.000.000,00
Pembuatan SKPL Rp 7.850.000,00
Review analisa kebutuhan Rp 1.770.000,00
Total biaya analisa kebutuhan Rp 40.770.000,00
Desain Rp 5.530.000,00
Buat deskripsi detail desain Rp 6.500.000,00
Review desain sistem Rp 1.750.000,00
Total biaya desain Rp 13.780.000,00
Implementasi Rp 40.500.000,00
Pembuatan tabel dan relasi database
Oracle
Rp 3.700.000,00
Pembuatan modul / method program Rp 8.150.000,00
Review hasil aplikasi Rp 1.475.000,00
Total biaya implementasi Rp 53.825.000,00
Testing Rp 30.000.000,00
Input master data Rp 1.955.000,00
Uji coba per-subsistem Rp 2.200.000,00
Uji coba keseluruhan sistem Rp 3.700.000,00
Review hasil uji coba / testing Rp 1.550.000,00
Total biaya testing Rp 39.405.000,00
Evaluasi Rp 7.000.000,00
Evaluasi per-subsistem Rp 6.500.000,00
Evaluasi keseluruhan sistem Rp 26.000.000,00
Review hasil evaluasi Rp 1.500.000,00
Total biaya evaluasi Rp 40.000.000,00
Pembelian SSL Rp 9.980.000,00
Pembelian server Rp 183.800.000,00
Instalasi server Rp 21.000.000,00
Deployment di server Rp 11.920.000,00
Total biaya deployment Rp 226.700.000,00
Trainer Rp 12.000.000,00
Training operator Rp 7.500.000,00
Training perwakilan dari pengguna Rp 7.500.000,00
Total biaya trainning Rp 27.000.000,00
Pengadaan 1 PC Rp 5.130.000,00
Total biaya pengadaan 4 PC Rp 20.520.000,00
TOTAL Rp 500.000.000,00
3.3. Rencana Penelusuran Proyek
3.3.1. Manajemen Kebutuhan
Proses pengukuran terhadap perubahan kebutuhan proyek didasarkan pada
presentase perubahan yang diminta dibandingkan dengan presentase pengerjaan
proyek yang telah selesai dilakukan.

11. 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.

12. 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.
3.3.3. Pengawasan Anggaran Dana
Pemantauan dilakukan dengan melihat biaya aktual yang timbul dan
membandingkanya dengan baseline cost (anggaran).
Pengawasan terhadap biaya dalam sebuah proyek merupakan satusatunya
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 :
1. 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.
2. 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.
3. 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.

13. 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 :
1. 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.
2. Pertemuan status review : adalah pertemuan yang diadakan secara
rutin dengan seluruh anggota tim proyek untuk mendapat perubahan
informasi yang terjadi mengenai proyek.
3. 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.
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:

14. 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 mendapat perubahan
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.

15. 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 matriks pada proyek ini akan digambarkan pada tabel
berikut:
Matriks Bagaimana mengukur
matriks
Penanggung Jawab
Waktu penyelesaian Untuk setiap tahapan
dalam proyek, catat
waktu atau tanggal mulai
tahapan sejak awal
permulaan aktifitas
dikerjakan
Pimpinan proyek dan
pekerja yang
bertanggung jawab pada
setiap tahapan
Mulai proyek Dihitung pada akhir
bagian
Pimpinan proyek
Selesai proyek Dihitung pada akhir
bagian
Pimpinan proyek
Presentasi milestone
yang telah dicapai
Beberapa persen
milestone yang tercapai
dari satu per empat
waktu pelaksaan proyek
Pimpinan proyek
Kesuksesan
(penyelesaian persen)
Pada akhir bagian,
berapa persen pekerjaan
yang berakhir secara
normal dibandingkan
dengan pekerjaan yang
selesai tertunda atau
sengaja dihentikan.
Pimpinan proyek dan
pekerja yang
bertangugng 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.
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

16. kecenderungan dari hasil identifikasi resiko sebagai output dari proses
ini.
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 pengiirman 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
diserahkan kepada 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 antar satu aktifitas dengan yang lain.
Review yang direncanakan
No Tanggal Tahapan Review Terhadap
1 21/07/17 Identifikasi kebutuhan Dokumen hasil identifikasi
kebutuhan pada pengguna / klien.
Menyimpulkan sementara layanan
apa yang dibutuhkan oleh pengguna
dari sistem yang akan dibangun.
2 23/08/17 Analisa kebutuhan Dokumen SKPL yang dihasilkan
dari tahapan analisa. Menyetujui

17. spesifikasi kebutuhan sistem yang
dijelaskan pada dokumen tersebut.
3 01/10/17 Desain sistem Dokumen edskripsi detail desain
sistem. Dokumen ini menjelaskan
dengan rinci proses dari data dri
amsing-masing proses pada sistem.
Review dilakukan terhadap seluruh
isi dokumen ini.
4 25/11/17 Pembuatan aplikasi Aplikasi yang telah dibangun,
apakah telah sesuai dengan
perencanaan pada desain sistem
5 23/12/17 Uji coba aplikasi Hasil uji coba aplikasi apakah sudah
memuat semua skenario yang
mungkin diterapkan pada aplikasi.
Milestone utama
No Tanggal Tahapan Produk yang
dihasilkan
Hasil yang harus
dicapai
1 05/07/17 Identifikasi
kebutuhan
Pertanyaan
identifikasi
kebutuhan
Pertanyaan identifikasi
kebutuhan selesai
dibuat
2 08/07/17 Identifikasi
kebutuhan
Form identifikasi
kebutuhan dan
pertanyaan
identifikasi
kebutuhan
Persiapan identifikasi
kebutuhan selesai
3 13/07/17 Identifikasi
kebutuhan
Form identifikasi
kebutuhan telah
terisi dan dijawab
oleh user
Pelaksanaan
identifikasi kebutuhan
selesai
4 21/07/17 Identifikasi
kebutuhan
Hasil identifikasi
kebutuhan telah
dievaluasi dan di
review
Tahap identifikasi
kebutuhan selesai
5 25/07/17 Analisa
kebutuhan
Dokumentasi
kebutuhan
berdasarkan
viewpoint
Dokumentasi
viewpoint telah selesai
6 10/08/17 Analisa
kebutuhan
SKPL Dokumen SKPL
selesai dibentuk
7 23/08/17 Analisa
kebutuhan
Hasil analisa yang
telah dievaluasi
Tahap analisa
kebutuhan selesai
8 10/09/17 Desain sistem Dokumen deskirpsi
detail desain
Dokumen deskripsi
detail desain selesai
9 01/10/017 Desain sistem Detail desain yang
telah direview
Tahap detail desain

18. 10 25/11/17 Pembuatan
aplikasi
Aplikasi Sistem
Pendaftaran
SNMPTN dan
SBMPTN 2017
Tahap pembuatan
aplikasi selesai
11 23/12/17 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 serta 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

19. 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 HTML, PHP
dan JavaScript dan dengan menggunakan framework Laravel. Sedangkan untuk database
digunakan MySQL. 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 Sistem Pendaftaran SNMPTN dan SBMPTN 2017
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 Sistem Pendaftaran SNMTPN dan SBMPTN 2017: 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 personal komputer dengan spesifikasi sebagai berikut:
1. Hard disk drive minimal 500GB
2. Memori minimal 4096MB RAM DDR4
3. Processor Intel i5

20. 4. Monitor min 16”, Lan Card, VGA Card minimal 2048MB
5. CD-ROM/RW
Perangkat lunak yang diperlukan untuk membangun Sistem Pendaftaran SNMTPN dan
SBMPTN 2017:
1. Sistem operasi : Windows 10
2. Analisa : VordTool
3. Desain : Power Designer 12
4. Database : DBMS MySQL server
5. Pemrograman : HTML, PHP, JavaScript
6. Pendukung : Microsoft office 2016, Acrobat reader, Web browser.
Yang dijadikan sebagai standar dalam proyek pembangunan Sistem Pendaftaran
SNMPTN dan SBMPTN 2017, 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 Management Plans.
Personil yang terlibat dalam proyek, antara lain:
1. Project Manager sebanyak 1 orang
2. Sistem analis sebanyak 1 orang
3. Programmer sebanyak 3 orang
4. Database administrator sebanyak 2 orang
5. Quality Assurace sebanyak 1 orang
6. Trainers sebanyak 2 orang
4.4. Penerimaan Produk
Rencana penerimaan proyek Sistem Pendaftaran SNMPTN dan SBMPTN 2017 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 proyek saja,
tetapi juga peneriman dari seluruh aktifitas yang kritis sebagai bagian dari proses
pembangunan produk
Peran dan Tanggung Jawab Staff
Staff Tanggung Jawab
Pemimpin proyek  Membuat dan memeliharan pengendalian versi dari
rencana penerimaan produk dan memastikan bahwa
rencana penerimaan produk telah dijalankan
 Berpartisipasi da memimpin review pada akhir tiap
tahapan
Perwakilan
customer
 Bekerja sama dengan analis dan progammer untuk
membuat, memelihara, dan menjalankan rencana

21. penerimaan proyek Sistem Pendaftaran SNMPTN dan
SBMPTN 2017
Analis dan
Programmer
 Bekerja sama dengan perwakilan customer untuk
membuat, memelihara, dan menjalankan rencana
penerimaan produk proyek Sistem Pendaftaran
SNMPTN dan SBMPTN 2017
 Menetapkan proyek yang dihasilkan pada tiap tahapan
serta mmebuat kriteria dan metode penerimaan hasil
akhir produk pada tiap tahapan.
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 Pendaftaran SNMPTN
dan SBMPTN 2017. Pelaksanaan proses verifikasi dan validasi dalam proyek ini tidak
dilakukan oleh tim SQA, melainkan menjadi salah satu tanggung jawab dari pimpinan
proyek. Proyek pembangunan Pendaftaran SNMPTN dan SBMPTN 2017 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:
No Tanggal Tahapan Review Terhadap
1 21/07/17 Identifikasi
kebutuhan
Dokumen hasil identifikasi
kebutuhan pada pengguna.
Menyimpulkan semetara layanan
apa yang dibutuhkan oleh
pengguna dari sistem yang akan
dibangun.
2 23/08/17 Analisa kebutuhan Dokumen SKPL yang dihasilkan
dari tahapan analisa. Menyetujui
spesifikasi kebutuhan sistem yang
telah dijelaskan pada dokumen
tersebut.
3 01/10/17 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.

22. 4 1/12/17 Pembuatan aplikasi Aplikasi yang telah dibangun,
apakah telah sesuai dengan
perencanaan pada desain sistenm
5 23/12/17 Uji coba aplikasi Hasil uji coba aplikasi apakah
sudah memuat semua skenario
yang mungkin diterapkan pada
aplikasi.
Uji Coba:
Uji coba aplikasi dilakukan 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:
No Tanggal Tahapan Review Terhadap
1 10/12/17 Uji coba aplikasi Keseluruhan aplikasi Sistem
Pendaftaran SNMPTN dan
SMBPTN 2017 tahap pertama
2 20/12/17 Uji coba aplikasi Keseluruhan aplikasi Sistem
Pendaftaran SNMPTN dan
SMBPTN 2017 tahap kedua
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 Sistem Pendaftaran SNMPTN dan SMBPTN 2017.
Metode untuk melakukan verifikasi dan validasi kebutuhan adalah dengan
melakukan review terhadap dafatr kebutuhan
5.2. Penanganan Dokumen dan Form
Rencana dokumentasi ini menjelaskan tentang bentuk, format dan jenis
dokumentasi hasil dari proyek Sistem Pendaftaran SNMPTN dan SMBPTN 2017 ini.
Dokumen dan form yang dihasilkan proyek ditujukan pada dua kelompok pengguna, yaitu
kepada pengembang dan kepada klien
Penamaan Dokumen
Semua dokumen diberi nama yang unik menurut struktur berikut:

23. Sistem Pendaftaran SNMPTN dan SMBPTN 2017 nomor-judul-versi, dimana:
Nomor : adalah nomor dokumen
Judul : adalah judul dokumen
Versi : adalah kode dua digit yang menunjukkan versi dokumen
Versi Dokumen
Struktur berikut digunakan untuk pemberian versi dokumen:
Vn.sv, dimana:
V menunjukkan bahwa ini adalah nomor versi
n adalah nomor versi utama; sebelum dikeluarkan secara formal, nomornya 0 dan
kemudian bertambah 1 dimulai setelah dikeluarkan secara formal.
sv adalah nomor subversi (nomor dari 0-9)
5.3. Jaminan Kualitas
Bagian ini bertujuan untuk mnyediakan referensi tunggal mengenai kualitas dalam
proyek pembangunan Sistem Pendaftaran SNMPTN dan SMBPTN 2017. 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.

24. 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.
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-kode program.