Perencanaan proyek si

SIFAT RAHASIA

Khusus diproduksi dan didistribusikan kepada yang berhak mengetahui di lingkungan Jurusan Sistem Informasi ITS

RENCANA PENGELOLAAN PROYEK PEMBANGUNAN

SISTEM INFORMASI RUMAH SAKIT TERPADU

(SIRST)

PP-06 SIRST

8 Februari 2007 Release 1

Disiapkan oleh :

EVI SEPTIANA PANE 5203 100 005

sebagai kelengkapan tugas akhir di Jurusan Sistem Informasi, Fakultas teknologi

Informasi, ITS Surabaya .

Abstrak:

Dokumentasi ini berisi seluruh rencana pengelolaan proyek pembangunan Sistem Informasi Rumah Sakit Terpadu (SIRST). Adapun rencana yang dituliskan meliputi 1). Rencana proses manajerial yang meliputi rencana awal, rencana kerja dan rencana penelusuran proyek, rencana manajemen resiko, dan rencana penyelesaian proyek. 2). Rencana proses teknis, meliputi model proses, infrastruktur, penerimaan produk, serta metode, alat bantu dan teknik yang digunakan. 3). Rencana pendukung, meliputi verifikasi dan validasi, penanganan dokumen, jaminan kualitas dan review.

SIFAT RAHASIA


MAKLUMAT VERSI DOKUMEN

Seluruh versi dari dokumen ini didaftar berdasar kronologisnya. Tidak ada hubungan

antara nomor dokumen dan nomor versi perangkat lunak.

Versi Dokumen

Tanggal Alasan Perubahan Versi

Perangkat Lunak

Release 1 Versi 1.0

Dokumen ini dibuat oleh Evi Septiana dengan pengawasan dari Jurusan Sistem

Informasi ITS sebagai upaya untuk menjamin keakurasian dokumen saat akan di

cetak. Penggandaan dokumen, sebaiknya dari versi yang terakhir (up to date) dan

setelah mendapatkan ijin tertulis

Copyright @ 2007 Jurusan Sistem Informasi ITS

Seluruh informasinya adalah hak milik Jurusan Sistem Informasi ITS yang tidak

dipublikasikan dan bersifat rahasia.

Rencana Pengelolaan Proyek Pembangunan SIRSTControl Revisi Dokumen

SIFAT RAHASIA


CONTROL REVISI DOKUMEN

Seluruh revisi yang telah dilakukan pada dokumen ini, dapat diikuti sebagaimana

tabel berikut.

Nomor Revisi

Tanggal Diperiksa oleh

Keterangan singkat perbaikan

1. 1 Februari 2007 Pimpinan Proyek

Evaluasi resiko terhadap jadwal dalam manajemen resiko tidak menggunakan bantuan analsa PERT, tetapi dalam estimasi durasi aktifitas digunakan PERT sebagai bantuan

2. 26 Februari 2007 Pihak Spnsor

Terjadi perubahan pada baseline proyek. (yang merubah durasi waktu penyelesaian proyek dan biaya proyek)

Rencana Pengelolaan Proyek Pembangunan SIRST

SIFAT RAHASIA


HALAMAN PERSETUJUAN

Disetujui oleh : Disetujui oleh : Project Leader

Disiapkan oleh : Evi Septiana Disiapkan oleh : IT Project Manager


Program Studi Sistem Informasi

Rencana Proyek SIRST

No. PP-06 SIRST

Pemilik Disetujui Oleh : Sponsor Tanggal : 08/02/2007

Daftar Isi

1. Gambaran Umum Proyek ............................................................................ 1

1.1 Tujuan, Ruang Lingkup dan Sasaran ............................................................................................ 1

1.2 Asumsi, Batasan dan Resiko ......................................................................................................... 3

1.3 Penyerahan Proyek ........................................................................................................................ 4

1.4 Ringkasan Jadwal dan Anggaran Dana ......................................................................................... 4

1.5 Evolusi Perencanaan ..................................................................................................................... 5

1.6 Referensi ....................................................................................................................................... 6

1.7 Definisi dan Akronim .................................................................................................................... 6

2. Organisasi Proyek ........................................................................................ 7

2.1 Lingkungan Eksternal ................................................................................................................... 7

2.2 Struktur Internal ............................................................................................................................ 7

2.3 Peran dan Tanggung Jawab ........................................................................................................... 8

3. Rencana Proses Managerial ....................................................................... 10

3.1 Rencana Awal ............................................................................................................................. 10

3.1.1 .Estimasi .............................................................................................................................................10

3.1.2 .Pengaturan Kepegawaian...................................................................................................................10

3.1.3 .Perolehan Sumberdaya ......................................................................................................................11

3.1.4 .Pelatihan Pekerja Proyek ...................................................................................................................11

3.2 Rencana Kerja ............................................................................................................................. 12

3.2.1 .Work Breakdown Structure (WBS) ..................................................................................................12

3.2.2 .Alokasi Jadwal...................................................................................................................................12

3.2.3 .Alokasi Sumberdaya ..........................................................................................................................13

3.2.4 .Alokasi Dana .....................................................................................................................................14

3.3 Rencana Penelusuran Poyek ........................................................................................................ 16

3.3.1 .Manajemen Kebutuhan ......................................................................................................................16

3.3.2 .Pengawasan Jadwal ...........................................................................................................................16

3.3.3 .Pengawasan Anggaran Dana .............................................................................................................17

3.3.4 .Pengawasan Kualitas .........................................................................................................................19

3.3.5 .Pelaporan ...........................................................................................................................................19

3.3.6 .Matriks Proyek ..................................................................................................................................21

3.4 Rencana Manajemen Resiko ....................................................................................................... 21

3.5 Rencana Penyelesaian Proyek ..................................................................................................... 25

4. Rencana Proses Teknis ............................................................................... 26

4.1 Model Proses ............................................................................................................................... 26

4.2 Metode, Alat bantu dan Teknik ................................................................................................... 27

4.3 Infrastruktur ................................................................................................................................ 29

4.4 Penerimaan Produk ..................................................................................................................... 32



Rencana Proyek SIRST

No. PP-06 SIRST

Pemilik Disetujui Oleh : Sponsor Tanggal : 08/02/2007

5. Rencana Pendukung ................................................................................... 34

5.1 Verifikasi dan Validasi ................................................................................................................ 34

5.2 Penanganan Dokumen dan Form ................................................................................................ 35

5.3 Jaminan Kualitas ......................................................................................................................... 37

5.4 Review ........................................................................................................................................ 38

LAMPIRAN 1. BASELINE PROYEK ............................................................. 40

LAMPIRAN 2. BASELINE 1 PROYEK .......................................................... 41

LAMPIRAN 3. RESOURCE SHEET PROYEK .............................................. 42

Rencana Pengelolaan Proyek Pembangunan Sistem Informasi Rumah Sakit Terpadu


Rencana Proyek SIRST No. PP-06 SIRST

Pemilik Disetujui Oleh : Sponsor Tanggal : 08/02/2007 Versi Halaman 1

1. Gambaran Umum Proyek

Proyek Sistem Informasi Rumah Sakit Terpadu (SIRST) ini bermaksud

untuk menghasilkan produk berupa aplikasi rumah sakit terintegrasi yang

dibangun per-modul berdasarkan Strategic Business Unit (SBU) yang ada di

rumah sakit.

SIRST memetakan seluruh area fungsional penting dari sebuah rumah

sakit. Paket SIRST memungkinkan pelayanan terhadap pasien yang lebih baik,

keselamatan pasien lebih terjamin, efisiensi dan pengurangan biaya. SIRST

menyediakan kemudahan akses terhadap informasi yang penting di rumah sakit

serta memungkinkan pihak manajemen mengambil keputusan yang lebih baik

dan tepat pada waktunya.

SIRST dikembangkan dengan menggunakan teknologi relasional database

system MySQL 5 dan bahasa pemrograman Delphi 7. SIRST memberikan

keuntungan dengan mempersingkat proses operasional, meningkatkan

administrasi dan pengendalian, memperbaiki tingkat respon terhadap pasien,

pengendalian biaya dan penambahan keuntungan.

Modul SIRST yang akan diimplementasikan pada rumah sakit tidak

mutlak semua modul, setiap modul pada SIRST dapat diimplementasikan sendiri

berdasarkan keberadaan SBU di rumah sakit. Namun akan lebih baik jika pihak

rumah sakit menerapkan semua modul yang tersedia. Dan yang paling penting

adalah SIRST dapat dengan mudah dikustomisasi sesuai dengan kebutuhan pada

rumah sakit manapun.

Proses-proses utama dari rumah sakit yang didukung oleh aplikasi SIRST,

meliputi :

1. Pendaftaran / registrasi pasien dan layanan konsumen

2. Perhitungan tagihan pasien rawat inap, rawat jalan dan pembelian obat.

3. Pelayanan medis pada rawat inap dan rawat jalan

4. Penyediaan bahan medis dan obat

5. Penyediaan barang-barang non-medis dan hubungannya dengan supplier.

1.1 Tujuan, Ruang Lingkup dan Sasaran

Tujuan : Membuat produk aplikasi yaitu sistem informasi

rumah rakit yang dikembangkan per-modul sesuai

dengan subsistem yang ada di rumah sakit. Modul

yang dibuat pada proyek kali ini terdiri dari 4 modul





utama, yaitu : Aplikasi manajemen rumah sakit

(pengadaan, layanan konsumen dan kasir), aplikasi

apotek, aplikasi rawat inap dan aplikasi rawat jalan.

Ruang Lingkup : Produk ini ditujukan untuk diterapkan pada Rumah

Sakit manapun yang memiliki fungsional seperti pada

SIRST. Untuk database aplikasi disiapkan supaya

dapat terhubung dengan data bagian SDM rumah

sakit. Pengembangan sistem selanjutnya lebih

diarahkan pada bagian keuangan.

Sasaran : Menghasilkan produk sistem informasi rumah sakit

yang mampu bersaing di pasaran serta sesuai dengan

spesifikasi kebutuhan untuk segala jenis rumah sakit .

Dibawah ini adalah Project Charter Proyek pembangunan SIRST.

Informasi proyek

Tanggal Januari ‘07 No. Proyek

01/07/001 Nama Proyek Sistem informasi RS Terpadu

Pimpinan proyek Ir. A. Holil Noor Klien Sistem Informasi

Tahapan yang diliputi 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 1 Februari 2007 Total kontrak Rp. 50.000.000,-

Tanggal selesai 5 Mei 2007 Estimasi biaya proyek Rp. 43.705.600,-

Tujuan Bisnis Membangun sistem informasi rumah sakit yang dikembangkan per-modul sesuai dengan subsistem yang ada di Rumah Sakit. Deskripsi Produk/ Proyek

Aplikasi Sistem Informasi Manajemen Rumah Sakit (layanan konsumen, pengadaan, dan kasir) Aplikasi Sistem Informasi Apotek Aplikasi Sistem Informasi Rawat Jalan Aplikasi Sistem Informasi Rawat Inap

Sasaran Proyek Sasaran proyek menghasilkan spesifikasi, desain , program aplikasi dan uji coba aplikasi Critical Success Factors :

Sistem Informasi yang men-support agar Rumah sakit yang dimodelkan memiliki komitmen untuk tetap menggunakan business process yang sudah disepakati

Batasan : Pelaksanaan survey lapangan sepenuhnya dilakukan pada Rumah Sakit Ibu dan Anak Permata Bunda. Asumsi :

Sistem Informasi manajemen rumah sakit meliputi fungsi : Registrasi pasien baru Pembayaran tagihan pasien





Logistik rumah sakit. Rumah Sakit yang akan mengimplementasikan SIRST sebelumnya tidak mempunyai sistem informasi rumah sakit 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. Holil Noor Kepala Cabang Ir. Khakim Ghozali

1.2 Asumsi, Batasan dan Resiko

Asumsi

1. Kebutuhan infrastruktur, usaha yang sebenarnya, dan jadwal akan

diselesaikan setelah dilakukan identifikasi kebutuhan.

2. Ruang lingkup SIRST pada proyek ini dikerjakan dengan

mempertimbangkan fungsional rumah sakit secara umum.

3. Detail dokumen kebutuhan (SKPL) akan disiapkan setelah dilakukan

studi di rumah sakit 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 pekerja proyek.

7. Kegiatan operasional rumah sakit 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 sistem informasi rumah sakit pada Rumah Sakit Ibu

Anak Permata Bunda oleh Bagus Permadi Teknik Informatika- ITS

2004.





2. Waktu pelaksanaan proyek 3 bulan mulai dari tanggal 1 Februari 2007

hingga 5 Mei 2007.

3. Anggaran dana yang ditetapkan untuk pelaksanaan dan pengelolaan

proyek tidak melebihi total kontrak proyek, yaitu Rp. 50.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.

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: 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 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 informasi rumah sakit terpadu :

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

Schwalbe, Kathy, “Information Technology Project Management”, Edisi

ke-4, Course Technology, Inc, 2004

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

Bug Huntress, “Quality Assurance Plan”, versi 1.0,

www.bughuntress.com, 2002

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

SIRST Sistem Informasi Rumah Sakit Terpadu

QA Quality Assurance

UML Unified Modelling Language

SDLC System Development Life Cycle

IRNA Instalasi Rawat Inap

IRJA Instalasi Rawat Jalan





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

Rumah Sakit (Customer) Pihak Pemesan Aplikasi

User (Pemakai di lapangan) Pegawai pelaksana / pengguna

Yang digambarkan dalam structured diagram berikut :

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 :

6

)1()4()1( xPDxEDxODD

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

Pimpinan proyek

Internal Perusahaan

Selama Proyek berlangsung 1 Orang

Surveyor Di sewa Selama fase identifikasi kebutuhan

4 Orang

Analis Internal Perusahaan

Selama fase analisa dan desain 4 Orang

Programmer Internal Perusahaan

Selama fase pembangunan aplikasi dan ujicoba

4 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.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 :

Tahapan / 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.

(Technical training) 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

(Technical training) tentang penyempurnaan desain database melalui normalisasi dan penentuan atribut entitas yang sesuai.


3. Kesulitan membuat Sequence Diagram UML.

(Technical training) tentang pembuatan Sequence Diagram yg benar sesuai dengan kesulitan yg dialami.


Pembuatan aplikasi

Programmer 1. Pengaturan koneksi database. Antara Delphi 7 dengan MySql melalui komponen ZeosDbo

(Technical training) tentang cara membuat koneksi dbase melalui ZeosDbo

Penjelasan, praktek dan studi pustaka

2. Kesulitan pembuatan modul admin dan konfigurasi setting database pada saat instalasi aplikasi.

(Technical training) tentang pembuatan modul instalasi dan file untuk konfigurasi database saat instalasi

Penjelasan, 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) Produk

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 SIRST 5. Uji Coba Aplikasi Hasil testing dan performance

aplikasi.

Dekomposisi WBS yang dibangun untuk pelaksanaan proyek

pembangunan SIRST 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 SIRST 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 pada

Microsoft Project 2003.

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 SIRST 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 5 Mei

2007. Sedangkan milestone untuk tiap aktifitas dapat dilihat selengkapnya

pada subbab 4.1 bagian milestone utama. Untuk jadwal proyek lebih lengkap

dapat dilihat pada lampiran 1. Baseline proyek

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 :

Staff Jumlah Tahapan pekerjaan Kemampuan yang dimiliki

Pimpinan proyek 1 Orang Seluruh tahapan pada proyek.

- Kemampuan koordinasi dan komunikasi yang baik

- Kemampuan manajerial dan manajemen proyek IT.

- Kemampuan menyelesaikan masalah

Surveyor 4 Orang Identifikasi kebutuhan - Mampu bekerja sama dengan user aplikasi

- Mampu berkomunikasi dan negosiasi





- Kritis dan detail dalam bertanya.

Analis 4 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 4 Orang Pembuatan aplikasi - Menguasai bahasa

pemrograman Delphi 7 - Menguasai MySql 5 sebagai

DBMS - Mengerti fungsi dan

penggunaan komponen / package yg ditambahkan pada Delphi 7

- Mampu melakukan koneksi dari database ke Delphi.

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 :

Aktifitas Biaya Total Pelaksanaan dan Monitoring Rp. 1.800.000,-

Identifikasi kebutuhan

Persiapan Identifikasi kebutuhan Rp. 1.014.800

Pelaksanaan identifkasi kebutuhan Rp. 908.100

Pengolahan dan penyimpulan hasil identifikasi Rp. 966.950

Total Biaya Identifikasi kebutuhan Rp. 2.889.850,-

Analisa Rp. 2.040.750

Identifikasi view point Rp. 900.000

Strukturisasi view point Rp. 900.000

Dokumentasikan kebutuhan view point Rp. 3.000.000

Pembuatan SKPL Rp. 2.850.000

Review analisa kebutuhan Rp. 750.400





Total Biaya Analisa Rp. 10.441.150,-

Desain Sistem Rp. 1.829.650

Buat Deskripsi Detail desain Rp. 7.500.000

Review desain sistem Rp. 750.400

Total Biaya Desain Sistem Rp. 10.080.050,-

Pembuatan Aplikasi Rp. 1.407.100

Pembuatan tabel dan relasi database Rp. 1.348.800

Pembuatan modul/method program Rp. 8.092.800

Review hasil aplikasi Rp. 475.200

Total Biaya Pembuatan Apliakasi Rp. 11.323.900,-

Uji Coba Rp. 649.050

Input master data Rp. 449.600

Uji coba per-subsistem dan review hasil uji coba Rp. 2.348.800

Uji Coba keseluruhan sistem dan review hasil Rp. 3.723.200

Total Biaya Uji Coba Rp. 7.170.650,-

TOTAL Rp. 43.705.600,-

Estimasi biaya untuk setiap resource yang digunakan pada proyek adalah

sebagai berikut :

No. Nama Sumberdaya Jenis

Sumberdaya Satuan Biaya Standard

Biaya Overtime

1. Surveyor Pekerja Per-jam Rp. 9.400,- Rp. 14.100,-

2. Sistem analist Pekerja Per-jam Rp. 18.750.- Rp. 28.100,-

3. Programmer Pekerja Per-jam Rp. 28.100,- Rp. 42.150,-

4. Project Manager Pekerja Per-jam Rp. 34.400,- Rp. 51.600,-

5. Set Komputer Utilitas Per-jam Rp. 12.500,- Rp. 12.500,-

6. Sewa ruangan Utilitas Per-bulan Rp. 500.000,- --

7. Sewa Listrik Utilitas Per-hari Rp. 6.700,- --

8. Biaya Air Utilitas Per-bulan Rp. 100.000,- --

9. Kertas ATK Rim Rp. 23.000,- --

10. Compact Disc(CD) ATK Biji Rp. 2.000,- --

11. Alat tulis ATK Biji Rp. 850,- --

12. Biaya perjalanan Akomodasi Per-Orang Rp. 850.000,- --

13. Akomodasi rapat Akomodasi Per-Rapat Rp. 200.000,- --

Selengkapnya mengenai biaya untuk tiap sumber daya dapat dlihat pada

lampiran 2. Resource Sheet proyek.





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 selesai dilakukan.

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 :







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.







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

informasi yang terjadi mengenai proyek.







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.



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.

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 & pekerja 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 atau sengaja dihentikan.

Pimpinan Proyek & pekerja 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 resource levelling

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 kebutuhan

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


Kriteria yang salah pada proses perekrutan


Kepala Personalia




Semua anggota tim

E. Pembuatan aplikasi


Kurang teliti pada perekrutan pekerja


Kepala Personalia





Tahapan terjadi Resiko

Daftar Resiko Asal Resiko Pengaruh resiko Penanggung

jawab




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)


Semua anggota tim

F. Uji Coba Aplikasi Kehilangan pekerja pada saat –saat yang penting (mis. Krn sakit)



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 Kemungkinan

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 Kemungkinan

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.


Tinggi Tinggi Dikurangi Memperpanjang durasi pengerjaan aktifitas / memberikan pelatihan yang relevan

Kehilangan pekerja ahli pada saat penting (mis. Krn sakit)

Sedang Tinggi Dikurangi Melakukan tindakan antisipasi saat aktifitas penting (digantikan dgn pekerja lain)

E. Pekerja yg ditunjuk kurang berpengalaman

Tinggi Tinggi Dikurangi Memperpanjang durasi pengerjaan aktifitas

Kehilangan pekerja pada saat penting (mis. Krn sakit)

Sedang Tinggi Dikurangi Melakukan tindakan 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 saat penting (mis. Krn 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. 9/02/07 Identifikasi kebutuhan

Dokumen hasil identifikasi kebutuhan pada pengguna/klien. Menyimpulkan sementara layanan apa yang dibutuhkan oleh pengguna dari sistem yang akan dibangun.

2. 8/03/07 Analisa kebutuhan

Dokumen SKPL yang dihasilkan dari tahapan analisa. Menyetujui spesifikasi kebutuhan sistem yang telah dijelaskan pada dokumen tersebut.

3. 3/04/07 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. 19/04/07 Pembuatan aplikasi

Aplikasi yang telah dibangun, apakah telah sesuai dengan perencanaan pada desain sistem.

5. 2/05/07 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-02-2007 Identifikasi Kebutuhan

Pertanyaan identifikasi kebutuhan

Pertanyaan identifikasi kebutuhan selesai dibuat

2. 5-02-2007 Identifikasi Kebutuhan

Form identifikasi kebutuhan dan pertanyaan identifikasi kebutuhan

Persiapan Identifikasi kebutuhan selesai

3. 8 02-2007 Identifikasi Kebutuhan

Form identifikasi kebutuhan telah terisi dan dijawab oleh user

Pelaksanaan Identifikasi Kebutuhan selesai

4. 12 02 2007 Identifikasi Kebutuhan

Hasil identifikasi kebutuhan telah dievaluasi dan di review

Tahap Identifikasi Kebutuhan selesai

5. 28-02-2007 Analisa Kebutuhan

Dokumentasi kebutuhan berdsar viewpoint

Dokumentasi viewpoint selesai


SKPL Dokumen SKPL selesai dibentuk


Hasil analisa yang telah dievaluasi

Tahap Analisa Kebutuhan selesai

8. 3-04-2007 Desain sistem Dokumen deskripsi detail desain

Dokumen Deskripsi Detail desain selesai

9. 5-04-2007 Desain sistem Detail desain yang telah direview

Tahap detail desain

10. 25-04-2007 Pembuatan aplikasi

Aplikasi rumah sakit Tahap pembuatan aplikasi selesai

11 2-5-2007 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 penggua, 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 Delphi

7 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 Sistem Informasi Rumah Sakit terpadu, meliputi 7 Aplikasi :

kasir, pengadaan, apotek, perawat IRNA, perawat IRJA, Dokter rumah

sakit, dan layanan konsumen.

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 SIRST. 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 SIRST dari segi antar muka

perangkat keras :





administrator

`

`

`

`

`

`Staff_apotek

Staff_poliklinik

Staff_Rawat inap

kasir

Staff_pengadaan

Staff_Layanan konsumen

firewall

Hub D-link

Client 1

Client 2

Client 3

Client 4

Client 5

Client 6

Komputer server

Perangkat lunak yang diperlukan untuk pembangunan SIRST :

1. Sistem operasi : Windows XP home atau profesional edition

2. Analisa : VordTool

3. Desain : Power Designer 12

4. Database : DBMS MySQL server 5.0.2, MySQL Front, SQL Yog dan

ZeosDbo 6.6.0 component

5. Pemograman : Borland Delphi 7, Express Quantum Grid Component dan

VCL Skin Component

6. Pendukung : Microsoft office 2003 (Word dan Project), SnagIt dan

HyperSnap Acrobat reader, Web browser.

Berikut merupakan infrastruktur antar muka perangkat lunak dari SIRST :





Sedangkan gambar berikut menunjukkan infrastruktur antar muka komunikasi

dari SIRST :

Yang dijadikan sebagai standar dalam proyek pembangunan SIRST, 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.

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 pimpinan proyek (merangkap tugas sebagai pihak QA)

2. 4 orang surveyor





3. 4 orang analis

4. 4 orang programmer

4.4 Penerimaan Produk

Rencana penerimaan produk SIRST 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 SIRST

Analis dan Programmer Bekerja sama dengan perwakilan kustomer untuk membuat, memelihara, dan menjalankan rencana penerimaan produk proyek SIRST

Menetapkan produk yang dihasilkan pada tiap tahapan serta membuat kriteria dan metode penerimaan hasil akhir produk pada tiap tahapan.

Kriteria Penerimaan produk :

Artifact 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

SIRST. Pelaksanaan proses verifikasi dan validasi dalam proyek ini tidak

dilakukan oleh tim SQA, melainkan menjadi salah satu tanggung jawab dari

pimpinan proyek. Proyek pembangunan SIRST 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.


1. 9/02/07 Identifikasi kebutuhan

Dokumen hasil identifikasi kebutuhan pada pengguna/klien. Menyimpulkan sementara layanan apa yang dibutuhkan oleh pengguna dari sistem yang akan dibangun.


Dokumen SKPL yang dihasilkan dari tahapan analisa. Menyetujui spesifikasi kebutuhan sistem yang telah dijelaskan pada dokumen tersebut.

3. 3/04/07 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.


Aplikasi yang telah dibangun, apakah telah sesuai dengan perencanaan pada desain sistem.


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 :



Masing-masing modul aplikasi dalam SIRST (modul apotek, modul rawat jalan, modul rawat inap dan modul manajemen rumah sakit)


Keseluruhan aplikasi SIRST.

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

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 SIRST 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/form Pembuat

dokumen/form Penanggung jawab review

dokumen/form

1. Perencanaan proyek (PP-06 SIRST)

Dokumen Pimpinan proyek Seluruh tim manajemen proyek dan sponsor.

2. Project Scope Statement (SIRST 062 PSS v1.0)


3. SKPL (PP-11 SIRST) Dokumen Analis Programmer

4. Deskripsi Detail Desain (PP-21 SIRST)

Dokumen Analis Programmer

5. Project Charter (SIRST 061 PC v1.0)

Dokumen PMO Pihak sponsor

6. Risk Management (SIRST 066 RMG v1.0)


7. Change request form (dibuat saat terjadi permintaan perubahan saja)

Form Seluruh tim proyek

Pihak yang terkait dengan permintaan perubahan

8. Status report (SIRST 074 SR v1.0)

Form Pimpinan proyek Seluruh tim manajemen proyek dan sponsor.

9. Laporan kemajuan proyek (SIRST 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 (SIRST 081 FPR v1.0)

Dokumen Pimpinan proyek Pihak sponsor

13 Deliverable acceptance (SIRST 082 DVA v1.0)

Dokumen Pimpinan proyek Pihak sponsor

Keterangan penomoran dokumen : 06x : Untuk dokumen hasil tahapan perencanaan proyek 07x : Untuk dokumen hasil tahapan pelaksanaan dan pengawasan proyek 08x : Untuk dokumen hasil tahapan penutupan proyek Penamaan dokumen

Semua dokumen diberi nama yang unik menurut struktur berikut:

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

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 presentasi

review 1. 2/02/07 Identifikasi

kebutuhan Ketepatan pertanyaan yang ditulis pada form survey, bagian (pihak) yang akan dituju saat survey

Surveyor Daftar pertanyaan





2. 9/02/07 Idenitifikasi kebutuhan

Pengumpulan dan penyimpulan hasil identifikasi kebutuhan

Surveyor Dokumen hasil survey


Strukturisasi viewpoint yang dibuat, dokumentasi kebutuhan dari hasil survey

Analis Dokumentasi kebutuhan user


Isi dan pembahasan dalam dokumen SKPL

Analis Dokumen SKPL

5. 20/03/07 Desain sistem Rancangan database sistem dan UML diagram

Analis ERD dan diagram UML

6. 29/03/07 Desain sistem Rancangan alur tampilan aplikasi

Analis Form tampilan aplikasi (Grafis)

7. 3/04/07 Desain sistem Isi dan pembahasan dalam dokumen deskripsi detail desain sistem keseluruhan

Analis Dokumen Deskripsi detail desain


Aplikasi yang telah dibangun (fungsi-fungsinya)

Programmer Hasil aplikasi serta laporan


Hasil uji coba aplikasi Programmer Laporan hasil uji coba sistem dan scenario uji coba yang dilakukan terhadap sistem.





LAMPIRAN 1. BASELINE PROYEK





LAMPIRAN 2. UPDATE BASELINE PROYEK





LAMPIRAN 3. RESOURCE SHEET PROYEK