BAB 2 LANDASAN TEORI 2.1 Manajemen Proyek 2.1.1 Pengertian

BAB 2
LANDASAN TEORI
2.1
Manajemen Proyek
2.1.1
Pengertian Manajemen
Manajemen proyek terdiri dari dua kata yaitu Manajemen dan Proyek.
Manajemen merupakan suatu metode/teknik atau proses untuk mencapai suatu
tujuan tertentu secara sistematik dan efektif, melalui tindakan-tindakan
perencanaan
(Planning),
pengorganisasian
(Organizing),
pelaksanaan
(Actuating) dan pengawasan (Controlling) dengan menggunakan sumber daya
yang ada secara efisien.(http://library.gunadarma.ac.id)
Menurut Fayol pengertian Manajemen adalah Fungsi-fungsi untuk
merencanakan, mengorganisir, memimpin, dan mengendalikan.
(http://library.gunadarma.ac.id)
Menurut Stoner pengertian Manajemen adalah Proses perencanaan,
pengorganisasian, pengarahan dan pengawasan terhadap usaha-usaha para
anggota organisasi dengan menggunakan sumber daya organisasi lainnya, agar
mencapai tujuan organisasi yang telah ditetapkan.(http://library.gunadarma.ac.id)
Menurut Robbins & Coulter (1999, p8) pengertian Manajemen adalah
Proses mengkoordinasi dan mengintegrasikan kegiatan-kegiatan kerja agar
diselesaikan secara efisien dan efektif dengan dan melalui orang lain.
7
2.1.2
Pengertian Proyek
Menurut Schwalbe (2000, p4), Proyek adalah suatu usaha yang bersifat
sementara untuk menghasilkan suatu produk atau layanan yang unik. Dalam hal
proyek sistem informasi berarti proyek tersebut berupa sistem aplikasi yang
terdiri atas beberapa modul program, tetapi proyek software bervariasi
cakupannya, mulai dari membangun sistem yang besar sampai hanya membuat
program satu modul saja. Proyek normalnya melibatkan beberapa orang yang
saling berhubungan aktivitasnya dan sponsor utama dari proyek biasanya tertarik
dalam penggunaan sumber daya efektif untuk menyelesaikan proyek secara
efisien dan tepat waktu.
Menurut Rakos (1990, p1) proyek adalah sekumpulan aktivitas yang
menghasilkan suatu deliverable atau produk. Proyek selalu dimulai dengan
sebuah masalah, kemudian user meminta tim proyek untuk memberikan solusi
atas masalah yang ada, solusi tersebut adalah hasil dari proyek.
Menurut Gray dan Larson (2000, p4), Proyek adalah sesuatu yang
kompleks, tidak rutin, usaha yang tepat waktu yang dibatasi oleh time, budget,
resources, dan performance
specifications yang didesain untuk kebutuhan
customer.
Menurut Olson (2003, p2), suatu proyek melibatkan aktivitas yang baru
dan kompleks, tujuan yang dapat didefinisikan melintasi bebagai level organisasi
dan merupakan aktivitas yang unik. Karena proyek melibatkan banyak aktivitas,
maka proyek biasanya mengandung tingkat ketidakpastian dan resiko yang
tinggi. Oleh karena itu pula, tingkat sumber daya yang diperlukan untuk
penyelesaian proyek biasanya sulit diestimasi.
8
Menurut Schwalbe (2000, p5), setiap proyek memiliki batasan yang
berbeda terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai
triple constrain (Tiga Kendala). Setiap proyek manajer harus memperhatikan
hal-hal penting dalam manajemen proyek :
•
Ruang lingkup (scope) : Apa yang ingin dicapai dalam proyek ? Produk atau
layanan apa yang pelanggan harapkan dari proyek tersebut ?
•
Waktu (time) : Berapa lama waktu yang dibutuhkan untuk menyelesaikan
proyek ? Bagaimana jadwal kegiatan proyek akan dilaksanakan ?
•
Biaya (cost) : Berapa biaya yang dibutuhkan untuk dapat menyelesaikan
proyek ?
2.1.3
Pengertian Manajemen Proyek
Menurut Schwalbe (2000, p7), Manajemen Proyek merupakan aplikasi
dari ilmu pengetahuan, skills, tools, dan teknik untuk aktivitas suatu proyek
dengan maksud memenuhi atau melampaui kebutuhan stakeholder dan harapan
dari sebuah proyek.
Menurut Soeharto (1997, p28), Manajemen Proyek adalah merencanakan,
mengorganisir, memimpin dan mengendalikan sumber daya perusahaan untuk
mencapai sasaran jangka pendek yang telah ditentukan. Lebih jauh, manajemen
proyek menggunakan pendekatan sistem dan hierarki (arus kegiatan) vertikal dan
horizontal.
9
2.2
Oracle Corporation
Bisnis Oracle adalah bagaimana mengelola, menggunakan, membagikan,
dan memelihara informasi. Salah satu perusahaan software terbesar di dunia,
Oracle merupakan salah satu vendor yang menawarkan solusi-solusi untuk setiap
permasalahan dari bisnis anda seperti database, middleware, business
intelegence, business applications, dan collaborations. Dengan Oracle, anda
mendapatkan informasi yang membantu anda mengukur hasil, menjalankan
proses bisnis, dan berkomunikasi dengan setiap kebenaran untuk perusahaan
anda.(http://oracle.com)
2.2.1
Oracle Financial
Oracle Financial adalah Produk dari Oracle yang mendukung berbagai
kegiatan usaha dan memiliki modul–modul seperti General Ledger (GL),
Account Revenue (AR), Account Payable (AP), Cash Management, Purchasing,
dan Purchasing Inventory, dll.
Oracle Financial adalah suatu kumpulan aplikasi yang mengotomatisasi
dan mengalirkan semua arus informasi proses bisnis anda, mempunyai business
intelligence yang akan selalu mendapatkan infomasi tentang keputusan,
menjalankan operasi-operasi, dan mengurangi biaya. Suatu kesatuan model data
menyediakan setiap laporan informasi keuangan perusahaan anda secara akurat,
termasuk laporan 360-degree atas customer anda. Dan Oracle Financial, terusmenerus menjalankan teknologi yang memberikan anda suatu kinerja dan
skalabilitas dalam memimpin perusahaan anda.
Oracle Financial adalah bagian dari Oracle E-Business Suite, melengkapi
dengan aplikasi-aplikasi E-Business Suite lainnya termasuk Oracle Marketing
10
dan Oracle Supply Chain Management. Mengimplementasikan satu atau
beberapa bagian aplikasi atau mengimplementasikan semua bagian Oracle EBusiness Suite adalah cara tercepat untuk kualitas terbaik informasi perusahaan.
Oracle E-Business Suite Financial 11i.10 menawarkan kemampuan-kemampuan
baru yang memperbaiki aliran informasi seluruh perusahaan anda termasuk
Enterprise Planning and Budgeting.(http://oracle.com)
2.3
Faktor–faktor Penyebab Kegagalan Proyek Piranti Lunak
Menurut Rakos (1990,p.2). Ada beberapa masalah yang menyebabkan
sebuah proyek gagal antara lain :
1. Kegagalan pada saat memulai
Banyak proyek yang melenceng karena mereka tidak menentukan arah
yang jelas. Banyak orang-orang yang memulai sebuah proyek tanpa tujuan
dan perencanaan yang jelas, sehingga memungkinkan kegagalan di awal
memulai proyek.
Perencanaan adalah mengetahui waktu di masa depan ke mana anda akan
pergi, bagaimana anda akan mendapatkannya dan bagaimana anda akan bisa
membuktikan bahwa anda ada disana.
2. Kegagalan pada saat tahap pembuatan
Setelah membuat perencanaan proyek, anda akan menganalisa masalah
dan merancang suatu desain. Kemudian tahap pembuatan dan pengembangan
dapat dimulai. Proyek dapat gagal di tahap ini, jika hasil analisa dan desain
tidak didokumentasikan dengan tepat.
11
3. Kegagalan pada saat akhir
Pada saat akhir proyek dapat gagal karena saat batas waktu tiba, produk
yang dijanjikan belum selesai dibuat atau produk telah selesai dibuat tetapi
aplikasi yang dihasilkan diserahkan tanpa dilakukan pengujian terlebih
dahulu sehingga belum diketahui kegagalan yang akan muncul dari aplikasi
tersebut atau sistem yang diberikan kepada user tidak sesuai dengan kinerja
yang dijanjikan.
2.4
Tahapan Pengelolaan Proyek Piranti Lunak
Pendekatan yang akan digunakan melibatkan beberapa area penting seperti :
• Project Methodology FastGoLive
Gambar 2.1
Project Methodology FastGoLive
PT. Sapora Nusantara Consulting akan menggunakan phase-phase seperti di
bawah ini :
12
1. Project Initiation and Planning
Pada phase ini SAPORA Consulting dan TPK KOJA akan mengembangkan
secara detail Work Plan, dokumen Project Scope, Objective dan Approach
sebagai panduan untuk proyek eksekusi.
2. Operation Analysis (as is) & Business Process Design (to be)
Praktek bisnis tertentu dikumpulkan untuk mendapatkan kebutuhan.
Pengumpulan informasi dari departemen yang terlibat seperti Purchasing,
Accounting, Finance dan Billing.
Pada phase selanjutnya proses-proses bisnis didesain meliputi peran-peran
dan tanggung jawab departemen. Alur proses meliputi Planning and
Budgeting, Request to Pay, Order to Cash, Cash Management and
Management / Financials Reporting. Aktivitas ini adalah suatu dasar untuk
mengembangkan setup document.
3. Business Process Configuration
Pada phase ini, modul-modul aplikasi Oracle dikonfigurasikan berdasarkan
pada setup document, Custom Reports, Interface dan data conversion scripts
yang dikembangkan. Dan departemen-departemen pengguna (end users)
didaftarkan ke dalam sistem.
4. Business Process Training & Bussiness Process Testing
Pada phase ini, terdapat pengembangan dari user manual dan training end
user untuk menggunakan sistem dalam memproses transaksi bisnis dan
melaporkan hasil keuangan.
Kemudian pada phase pengujian (testing), skenario tes dalam masing-masing
departemen terdapat pengembangan kemudian dilanjutkan dengan Users
13
Acceptance Test (UAT). Masalah-masalah lain selama UAT akan dianalisis
dan diperbaiki.
5. GoLive Preparation / Transition
Selama peralihan sistem produksi disiapkan, custom reports didaftarkan,
Interface diinstal, end users didaftarkan, master data dan historical data
dikonversikan ke dalam sistem produksi. Sistem produksi siap untuk
digunakan.
6. GoLive & Support
Sistem berjalan, semua departemen menggunakan sistem untuk transaksi
proses yang dihubungkan kepada tanggung jawab mereka. SAPORA akan
mendukung pemakai sistem sekitar 6 bulan.
Menurut Rakos (1990, p125), pada umumnya masa garansi (warranty
period) dalam industri piranti lunak adalah enam bulan sampai satu tahun.
Penyediaan garansi berupa salah satu atau kombinasi dari tiga cara berikut :
1. Menyediakan seseorang pada pihak user untuk menjawab permasalahan.
Orang ini seharusnya merupakan project leader atau anggota tim proyek
senior yang mengetahui setiap aspek dari sistem.
2. Menyediakan seseorang yang dapat menjawab permasalahan dan dapat
diakses via telepon. Semua anggota tim proyek harus bisa diakses .
3. Menyediakan seseorang yang dapat menjawab pertanyaan dalam satu
periode waktu yang singkat setelah panggilan telepon diterima.
Tim proyek sudah selesai dengan keseluruhan proyek, jika :
14
•
Warranty disediakan.
•
Tinjauan ulang pasca proyek diadakan dan semua hal yang dapat
bermanfaat bagi proyek mendatang didokumentasikan.
•
Tanggung jawab dan metode pemeliharaan yang berjalan harus
didefinisikan.
2.5
Alternate Organizational Structure
Menurut Olson (2003, p38), Struktur organisasi menggambarkan laporan
secara hierarki dan jaringan komunikasi resmi dalam suatu organisasi. Galbraith
telah menggambarkan 3 form dasar dari organisasi proyek, yaitu : functional,
project, dan matrix. Setiap jenis dari 3 stuktur organisasi tersebut terdapat
kelebihan masing-masing, dan masing-masing bekerja baik di dalam tipe-tipe
tertentu dari lingkungan. Penggunaan struktur organisasi tergantung kepada
tujuan dari organisasi, tipe kerja yang harus dilakukan dan lingkungan dalam yang
beroperasi.
2.5.1
Functional Organization
Menurut Olson (2003, p38), Functional organization bekerja baik dalam
perulangan, lingkungan yang stabil. Subelements organisasi didefinisikan dengan
aktivitas atau fungsi spesial. Semua bagian akuntan di dalam perusahaan
dikumpulkan di dalam satu lokasi di mana mereka bekerja bersama-sama.
Keuntungan dari organisasi functional adalah spesialis bekerja bersama dan
dapat mengembangkan kemampuan profesional di dalam cara yang paling
15
efisien. Akuntan fokus pada masalah akuntansi dan menjadi terlatih dengan
sangat bagus di dalam akuntansi.
Gambar 2.2
Functional Organization
Sumber : Olson (2003, p38)
2.5.2
Project Organization
Menurut Olson (2003, p39), Project organization murni terdiri dari
membuat suatu pemisahan, organisasi mandiri terutama untuk menyelesaikan
suatu proyek istimewa atau terbilang luar biasa. Ketika proyek selesai, tidak ada
alasan bagi organisasi untuk melanjutkan. Pada tabel 2.3 menggambarkan
bagaimana kemampuan dapat dikelompokkan oleh proyek
Pusat
proyek
dihubungkan
kepada
organisasi
induk
untuk
menggambarkan sumber daya manusia dan personnel yang dibutuhkan. Kadangkadang organisasi proyek adalah organisasi yang berdiri sendiri. Organisasi
proyek parsial juga exist. Pada struktur organisasi ini seorang manajer proyek
16
bertanggung jawab untuk beberapa aktivitas, padahal aktivitas lain juga
membutuhkan lebih banyak dukungan. Seperti akuntansi berhubungan dengan
divisi fungsional. Ini adalah perjanjian yang sudah biasa.
Gambar 2.3
Project Organization
Sumber : Olson (2003, p39)
2.5.3
Matrix Organization
Menurut Olson (2003, p41), Matrix Organization adalah suatu struktur
gridlike dari hubungan antara pelaporan dan kekuasaan yang menutupi organisasi
fungsi tradisional. Matrix Organization digunakan dalam organisasi yang
menggunakan tim proyek dan grup produksi yang minimal.
Penggambaran kunci dari organisasi matrix adalah garis multiple dari
kekuasaan. Spesialis melaporkan kepada manajer fungsional mereka dengan
menanggapi isu-isu yang meliputi spesialisasi dan laporan mereka kepada
manajer proyek untuk kewajiban yang spesifik. Spesialis fungsional ditunjuk
17
untuk proyek yang akan diimplementasikan. Spesialis ini membuat keputusan
karir personal pada tempat fungsional permanen mereka.
Gambar 2.4
Matrix Organization
Sumber : Olson (2003, p41)
Ada beberapa masalah yang diperkenalkan dalam bentuk matrix
organization. Struktur pelaporan yang ganda menciptakan kondisi yang
membingungkan pada bagian yang tinggi dari struktur tersebut. Di dalam tim
matrix organization tersebut harus terdapat prinsip yang tegas dalam hal perintah
atasan. Pada sistem matrix, dengan dua sumber daya potensial dari perintah,
telah ditemukan dalam menyelesaikan masalah karena permintaan yang tidak
dapat digabungkan dan prioritas dari dua manajer dari individual yang spesifik.
18
2.6
Area Pengetahuan Manajemen Proyek
2.6.1
Manajemen Ruang Lingkup Proyek
Menurut Soeharto (1997, p49), Lingkup proyek adalah total jumlah
kegiatan atau pekerjaan yang harus dilakukan untuk menghasilkan produk yang
diinginkan oleh proyek tersebut.
Menurut Schwalbe (2000, p76), ruang lingkup mewakili semua kinerja
yang terlibat dalam menciptakan produk dari proyek dan proses untuk
menciptakan proyek tersebut. Sedangkan ruang lingkup proyek mencakup semua
proses yang terlibat dalam pendefinisian dan pengaturan mengenai apa yang
termasuk atau tidak di dalam proyek. Hal ini untuk menyakinkan bahwa tim
proyek dan stakeholder mempunyai pengertian yang sama mengenai produk
yang akan diproduksi sebagai hasil dari proyek dan proses yang akan digunakan
dalam memproduksi proyek tersebut.
Proses utama yang terlibat di dalam manajemen ruang lingkup proyek
adalah :
1) Initiation (Inisiasi)
Proses ini melibatkan tanda mulainya organisasi untuk memulai proyek atau
melanjutkan fase berikut dari sebuah proyek. Keluaran dari proses inisiasi
proyek adalah sebuah project charter. Project charter merupakan kunci
dokumen untuk pengenalan formal mengenai keberadaan dan penyediaan
keseluruhan proyek. Menurut Schwalbe (2000, p88) project charter terdiri
dari :
•
Judul proyek dan tanggal pengesahan
•
Nama manajer proyek dan informasi yang dapat dihubungi
19
•
Deskripsi proyek secara objektif
•
Penjelasan mengenai rencana pengaturan proyek
•
Peraturan dan tanggung jawab
•
Bagian persetujuan dari pihak stakeholder proyek
•
Bagian komentar mengenai proyek dari pihak stakeholder proyek.
2) Scope Planning (Perencanaan Ruang Lingkup)
Proses ini melibatkan dokumen pengembangan untuk menyediakan dasar
dari keputusan yang akan riter dari proyek, mencakup kriteria untuk
menentukan apakah proyek atau fase telah diselesaikan sepenuhnya. Tim
proyek menciptakan sebuah pernyataan ruang lingkup dan perencanaan
manajemen proyek sebagai hasil dari proses perencanaan ruang lingkup.
3) Scope Definition (Pendefinisian Ruang Lingkup)
Proses ini melibatkan pembagian dari proyek besar menjadi kecil, lebih
mudah diatur. Tim proyek menciptakan sebuah Work Breakdown Structure
(WBS ) selama proses ini.
Menurut Schwalbe (2000, p92), WBS adalah sebuah analisis yang
berorientasi keluaran dari pekerjaan yang terlibat dalam proyek yang
mendefinisikan keseluruhan ruang lingkup proyek. WBS merupakan
dokumen dasar dalam manajemen proyek karena menyediakan dasar untuk
perencanan dan pengaturan jadwal proyek, biaya dan perubahan. Seorang
yang ahli dalam manajemen proyek percaya bahwa kegiatan yang tidak
seharusnya dilakukan dalam proyek bilamana kegiatan tersebut tidak
termasuk dalam WBS.
20
Menurut Schwalbe (2000, pp95-97), ada beberapa pendekatan yang dapat
digunakan untuk membangun WBS, meliputi :
a. Menggunakan Guidelines
Jika pendekatan untuk mengembangkan suatu WBS masih berjalan
maka sangat penting untuk mengikuti guidelines tersebut.
b. The Analogy Approach
Di dalam pendekatan analogi, digunakan WBS proyek yang sudahsudah yang mirip sebagai tahap untuk memulai. Beberapa organisasi
menyimpan WBS dan dokumen lain dalam file untuk membantu
orang yang bekerja dalam proyek. Dengan melihat contoh dari WBS
proyek yang mirip, akan memungkinkan untuk mengerti cara yang
berbeda untuk membuat sebuah WBS.
c. The Top-down dan bottom-up Approach
Untuk menggunakan pendekatan top-down, mulai dengan perihal
yang besar dari proyek dan pecahkan menjadi perihal yang lebih rinci.
Proses ini melibatkan proses penyaringan kerja menjadi detil yang
lebih besar. Dengan pendekatan bottom-up, anggota tim harus
mengidentifikasi sebanyak mungkin tugas khusus yang berhubungan
dengan proyek. Kemudian anggota tim akan mengagregasi tugas
tersebut dan mengatur mereka menjadi aktivitas yang dirangkum.
Untuk menciptakan WBS yang baik membutuhkan beberapa iterasi. Berikut
ini ada beberapa prinsip yang dapat digunakan untuk membuat WBS yang
baik :
21
1. Sebuah jenis kerja hanya muncul sekali dalam WBS
2. Content pekerjaan dari sebuah perihal WBS adalah jumlah perihal
WBS di bawahnya.
3. Perihal WBS adalah tanggung jawab dari seorang individu, meskipun
banyak orang yang bekerja di dalamnya.
4. WBS harus konsisten dengan jalan di mana pekerjaan dilakukan,
harus membantu anggota tim dulu dan tujuan lain bila perlu.
5. Anggota tim proyek harus terlibat dalam membangun WBS untuk
meyakinkan konsistensi dan buy-in.
6. Setiap perihal WBS harus didokumentasikan untuk meyakinkan
pengertian yang akurat mengenai hal yang termasuk dan yang tidak
termasuk dalam ruang lingkup kerja.
7. WBS harus menjadi sebuah alat yang fleksibel untuk mengakomodasi
perubahan yang tak terduga sementara menjaga pengaturan content
pekerjaan dalam proyek agar sesuai dengan pernyataan ruang lingkup.
4) Scope Verification (Verifikasi Ruang Lingkup)
Proses ini melibatkan penerimaan formal dari ruang lingkup proyek. Kunci
proyek pemegang saham, seperti pelanggan dan sponsor untuk proyek, secara
formal menerima jalannya proyek ini selama proses ini.
5) Scope Change Control (Pengontrolan Perubahan Ruang Lingkup)
Proses ini melibatkan pengontrolan perubahan terhadap ruang lingkup
proyek. Perubahan ruang lingkup, tindakan koreksi, dan pengajaran dari
keluaran (output) proses ini.
22
2.6.2
Manajemen Waktu Proyek
Menurut Soeharto (1997, p49), Waktu atau jadwal merupakan salah satu
sasaran utama proyek. Keterlambatan akan mengakibatkan berbagai bentuk
kerugian, misalnya, penambahan biaya, kehilangan kesempatan produk
memasuki pasaran dan lain-lain. Pengelolaan waktu meliputi perencanaan,
penyusunan, dan pengendalian jadwal. Salah satu teknik yang spesifik untuk
maksud tersebut adalah mengelola float atau slack pada jaringan kerja, serta
konsep cadangan waktu yang diperkenalkan oleh D.H. Bush, (1991).
Menurut Schwalbe (2000, pp111-112), Manajemen waktu proyek secara
sederhana didefinisikan, yang melibatkan proses yang dibutuhan untuk
meyakinkan pemenuhan waktu dari proyek. Tetapi, pencapaian hasil ini tidak
sederhana.
Proses utama yang terlibat didalam manajemen waktu proyek adalah :
1. Pendefinisian Aktivitas (Activity Definition)
Melibatkan pengidentifikasian aktivitas yang khusus di mana anggota tim
proyek dan pemegang saham harus bekerja untuk menghasilkan pengarahan
proyek. Sebuah aktivitas atau tugas adalah elemen kerja, biasanya ditemukan
di dalam WBS yang mempunyai durasi yang diharapkan, biaya, dan
kebutuhan akan sumber daya.
2. Barisan Aktivitas (Activity Squencing)
Melibatkan pengidentifikasian dan pendokumentasian hubungan antara
aktivitas proyek.
23
3. Perkiraan Durasi Aktivitas (Activity Duration Estimating)
Melibatkan perkiraan periode jumlah kerja yang dibutuhkan untuk
menyelesaikan tugas individu.
4. Pengembangan Jadwal (Schedule Development)
Melibatkan analisis urutan aktivitas, perkiraan durasi aktivitas dan kebutuhan
sumber daya untuk menciptakan jadwal proyek.
Menurut Schwalbe (2000, p118), Penjadwalan proyek bisa digambarkan
dengan menggunakan :
a. Critical Path Method (CPM)
CPM disebut juga teknik analisis jalur kritis (Critical Path Analysis)
yaitu teknik analisis jaringan proyek yang digunakan untuk memprediksi
total durasi proyek. Langkah ini bertujuan mengkaji secara analitis berapa
lama waktu penyelesaian proyek. CPM dapat digambarkan sebagai
berikut :
24
a
b
E
c
A
a
5
a
b
15
C
15
b
c
5
c
10
F
a
B
b
8
c
a
b
D
c
Gambar 2.5
Critical Path Method
(http://google.com)
Keterangan :
Event, tanda dimulai atau berakhirnya kegiatan.
Kegiatan (membutuhkan sumber daya terutama waktu)
Garis lurus, arah anak panah menuju kejadian atau event
berikutnya.
Jalur kritis dari kegiatan.
Kegiatan semu (tidak membutuhkan sumber daya apapun)
Hanya merupakan garis penghubung peristiwa antara dua
25
kegiatan yang tidak saling tergantung.
A
A menunjukan kode pekerjaan atau nama pekerjaan.
15
15 menunjukkan waktu yang dibutuhkan menyelesaikan
kegiatan atau pekerjaan A dengan peristiwa berikutnya.
•
a
: Menyatakan suatu kegiatan
•
b
: LF/LS
•
c
: ES/EF
•
ES (Earliest Start Time) = waktu mulai paling awal
sebuah
kejadian.
•
EF (Earliest Finish Time) = waktu selesai paling awal sebuah
kegiatan. Bila hanya ada satu kegiatan terdahulu, maka EF suatu
kegiatan terdahulu merupakan ES selanjutnya.
•
LS (Latest Start)
= waktu paling akhir kegiatan boleh dimulai
tanpa memperlambat proyek secara keseluruhan.
•
LF (Latest Finish) = waktu paling akhir suatu kegiatan boleh selesai
tanpa memperlambat penyelesaian proyek.
•
D (Duration)
= kurun waktu suatu kegiatan, dengan satuan
waktu berupa hari, minggu, bulan.
b. Gantt Chart
Menurut Schwalbe (2000, p119), Gantt Chart menyediakan suatu format
standard untuk menggambarkan informasi mengenai jadwal proyek
dengan menampilkan kegiatan proyek, jadwal mulai dan jadwal selesai
dalam format kalender. Gantt Chart menunjukan informasi tugas (task)
26
dalam proyek sebagai suatu serial batang (bars) sepanjang skala waktu
(timescale). Bars secara grafik menunjukkan durasi task dengan tanggal
mulai dan selesai seiring dengan kemajuan terhadap waktu.
5. Pengontrolan Jadwal (Schedule Control)
Melibatkan pengontrolan dan pengaturan perubahan terhadap perubahan
jadwal.
2.6.3
Manajemen Biaya Proyek
Menurut Soeharto (1997, p49), Pengelolaan biaya meliputi segala aspek
yang berkaitan dengan hubungan antara dana dan kegiatan proyek. Mulai dari
proses memperkirakan jumlah keperluan dana, mencari, dan memilih sumber
serta macam pembiayaan, perencanaan, serta pengendalian alokasi pemakaian
biaya sampai kepada akuntansi dan administrasi pinjaman dan keuangan. Agar
pengelolaan bisa efektif, terutama dalam aspek perencanaan dan pengendalian
biaya proyek, maka disusun bermacam-macam teknik dan metode. Misalnya
teknik menyusun anggaran biaya proyek, identifikasi varians, konsep nilai hasil,
dan lain-lain.
Menurut Schwalbe (2000, p144), Manajemen biaya proyek melibatkan
proses yang dibutuhkan untuk meyakinkan bahwa proyek terselesaikan dengan
anggaran yang dianjurkan. Seorang manajer proyek harus dapat meyakinkan
bahwa proyek sudah didefinisikan dengan baik, mempunyai anggaran yang
realistis di mana tim proyek terlibat dalam hal penganjuran tersebut. Merupakan
tugas manajer proyek untuk memuaskan stakeholder proyek sementara
melanjutkan penekanan untuk mengurangi dan mengontrol biaya.
Proses yang terlibat di dalam manajemen biaya proyek adalah :
27
1. Perencanaan Sumber Daya (Resources Planning)
Proses ini melibatkan penentuan sunber daya (orang, peralatan, dan material)
dan kuantitas dari tiap sumber daya yang akan digunakan dalam melakukan
aktivitas proyek. Keluaran dari proses ini adalah daftar dari kebutuhan
sumber daya.
2. Perkiraan Biaya (Cost Estimating)
Proses ini melibatkan pengembangan sebuah pendekatan atau perkiraan dari
biaya sumber daya yang dibutuhkan untuk menyelesaikan proyek. Keluaran
utama dari proses ini merupakan perkiraan biaya, mendukung perincian, dan
sebuah perencanaan manajemen biaya.
3. Penganggaran Biaya (Cost Budgeting)
Proses ini melibatkan pengalokasian perkiraan biaya keseluruhan terhadap
peralatan kerja individu untuk membangun sebuah dasar untuk pengukuran
kerja. Keluaran utama dari proses ini adalah dasar biaya (cost baseline).
4. Pengontrolan Biaya (Cost Control)
Proses ini melibatkan pengontrolan perubahan terhadap anggaran proyek.
Keluaran utamanya adalah revisi perkiraan biaya, update penganggaran,
tindakan pembetulan, perkiraan pada penyelesaian, dan pelajaran yang
didapat.
2.6.4
Manajemen Sumber Daya Manusia Proyek
Menurut Soeharto (1997, p50), Pengelolaan sumber daya terdiri dari
pengelolaan sumber daya manusia dan nonmanusia. Dalam hal ini, sering
dikatakan salah satu fungsi pengelolaan yang mungkin tersulit adalah
pengelolaan sumber daya manusia mulai dari inventarisasi kebutuhan, merekrut
28
atau mengajukan keperluan, membentuk tim, melatih, memotivasi serta
membimbing agar menjadi suatu tim yang tangguh untuk menangani kegiatan
proyek yang menjadi tanggung jawabnya. Adapun pengelolaan sumber daya
nonmanusia antara lain adalah sumber daya yang berbentuk material, seperti
peralatan konstruksi dan lain-lain.
Menurut Schwalbe (2000, p211), Manajemen sumber daya manusia
proyek
melibatkan proses yang dibutuhkan untuk melakukan efektivitas
penggunaan orang yang terlibat dengan proyek. Manajemen sumber daya
manusia menyangkut semua stakeholder proyek seperti : sponsor, pelanggan,
anggota tim proyek, staf pendukung, para penjual yang mendukung proyek, dan
lain-lain.
Proses utama yang terlibat di dalam manajemen sumber daya manusia
proyek adalah :
1. Perencanaan organisasional (Organizational Planning)
Proses ini melibatkan pengidentifikasian, penugasan, dan pendokumentasian
peranan proyek, tanggung jawab, dan melaporkan hubungan. Kunci keluaran
dari proses ini meliputi peranan dan tanggung jawab penugasan yang sering
ditampilkan dalam bentuk matrik dan sebuah bagan organisasional mengenai
proyek.
2. Akuisisi Staf (Staff Acquisition)
Proses ini melibatkan cara mendapatkan kebutuhan personil yang ditugaskan
untuk bekerja dalam proyek. Mendapatkan personil merupakan salah satu
tantangan yang penting dari proyek TI apalagi untuk mendapakan personil
yang berkualitas.
29
3. Pengembangan Tim (Team Development)
Proses ini melibatkan pembangunan individu dan kemampuan tim untuk
meningkatkan kerja proyek. Pembangunan individu dan kemampuan tim
merupakan tantangan bagi proyek TI.
2.6.5
Manajemen Resiko Proyek
Menurut Soeharto (1997, p50), dalam konteks proyek, mengelola resiko
berarti mengidentifikasi secara sistematis dari jenis, besar dan sumber timbulnya
resiko selama siklus proyek, kemudian menyiapkan tanggapan yang tepat untuk
menghadapi resiko tersebut.
Menurut Schwalbe (2000, p273), Manajemen resiko proyek merupakan
pengetahuan untuk mengidentifikasi, menugaskan, dan menanggapi resiko
melalui daur hidup proyek dan perhatian dalam memenuhi objektif proyek.
Menurut Schwalbe (2004, p393), tujuan dari manajemen resiko proyek dapat
dilihat dengan meminimalkan potensi resiko sementara memaksimalkan potensi
peluang atau pengeluaran.
Proses utama yang terlibat di dalam manajemen resiko proyek adalah :
1. Perencanaan Manajemen resiko (Risk Mangement Planning)
Pada proses ini memutuskan bagaimana pendekatan dan rencana kegiatan
manajemen resiko untuk suatu proyek. Dengan meninjau project charter,
WBS, aturan dan tanggung jawab, toelransi resiko stakeholder, dan
kebijaksanaan manajemen resiko organisasi, tim proyek dapat merumuskan
suatu perencanaan manajemen resiko.
30
2. Identifikasi Resiko (Risk Identification)
Menentukan resiko mana yang paling berpengaruh pada proyek dan
mendokumentasikan karakteristik dari setiap resiko yang ada.
3. Banyaknya Resiko
Pada proses ini melibatkan pengevaluasian resiko dan interaksi resiko untuk
menafsir kemungkinan output proyek. Alat atau teknik untuk menghitung
resiko yaitu jumlah uang yang diharapkan, menghitung riter resiko, estimasi
PERT, simulasi dan penilaian dari para ahli.
4. Pengembangan Tanggapan Terhadap Resiko (Risk Response Planning)
Dalam proses ini tim mengambil langkah-langkah untuk meningkatkan
peluang dan mengembangkan tanggapan terhadap ancaman. Hasil dari proses
ini adalah perencanaan manajemen resiko.
5. Pengontrolan dan Pengawasan Resiko (Risk Monitoring and Control)
Melibatkan pengawasan terhadap resiko yang diketahui, identifikais resikoresiko baru, mengurangi resiko dan mengevaluasi keefektifan dari penurunan
resiko seluruhnya dalam daur hidup proyek. Hasil utama dari proses ini
adalah tindakan pembetulan terhadap resiko dan update perencaan
manajemen resiko.
Menurut Rakos (1990, p23), setiap proyek akan tepat waktu dan sesuai
dengan anggaran apabila tidak ada kesalahan dalam proyek. Sangat penting
untuk berkonsentrasi pada segala sesuatu yang dapat menimbulkan masalah dan
mencoba untuk menghindarinya. Ini dinamakan dengan manajemen resiko.
Manajemen resiko terdiri dari empat tahapan :
31
1. Mengantisipasi Resiko
Yang pertama dan hal yang paling penting dalam manajemen resiko adalah
selalu waspada terhadap segala sesuatu yang dapat menimbulkan masalah.
Metode terbaik untuk mengidentifikasi resiko yang mungkin terjadi adalah
melihat pada sejarah dan membuat suatu daftar kesalahan di masa lalu
sehingga kita dapat mengantisipasi masalah-masalah yang mungkin akan
timbul.
2. Mengeliminasi Resiko yang mungkin akan timbul
Pada tahap ini adalah suatu ide yang bagus untuk memprioritaskan macammacam resiko dari resiko terbesar sampai terkecil. Sehingga kita dapat
menentukan resiko mana yang paling utama harus ditangani dan
mengesampingkan macam-macam yang tidak terlalu penting.
3. Mengurangi Dampak dari Resiko
Pada tahap ini, macam-macam resiko yang tidak dapat dieliminasi atau
dikesampingkan, harus mendefinisikan rencana pendekatan situasional. Anda
dapat meringkas rencana-rencana pendekatan situasional anda menggunakan
dengan menggunakan tabel.
4. Tetap pada Control ketika sesuatu berjalan tidak semestinya
Dan pada akhirnya, disamping usaha-usaha yang telah dilakukan akan ada
hal-hal yang tetap berjalan tidak dengan semestinya. Jangan terlalu paranoid
(bahkan jika setiap orang melawan) dan tetap mengendalikan sebaik yang
anda bisa.
32
2.7
Metode Estimasi Proyek
2.7.1
Function Point Analysis
Menurut Olson (2003, p167), Metode Function Point (FP) merupakan
suplemen dasar ukuran suatu proyek untuk estimasi. Metode ini dapat digunakan
untuk mengestimasi biaya dan waktu yang didasarkan pada spesifikasi
kebutuhan, dan berdiri sendiri dari teknologi yang digunakan. Metode Albrecht
sangat kritis karena perhitungan menggunakan jalur alternatif, bobot yang
disebabkan, dan sistem yang besar sangat ringan.
Menurut Pressman (1997, pp85-87), Function yang berdasarkan software
metrics adalah suatu ukuran dari fungsionalitas yang diterima oleh aplikasi
sebagai suatu nilai normalisasi. Sejak ”fungsionalitas” tidak dapat diukur secara
langsung, maka itu diukur secara tidak langsung menggunakan ukuran lainnya.
Function yang berdasarkan metrics pertama kali disarankan oleh Albrecht
[ALB79], yang mempelopori suatu ukuran yang disebut function point. Function
points diukur dihasilkan menggunakan suatu hubungan secara empiris yang
didasarkan pengukuran dari sumber informasi software dan penilaian terhadap
kompleksitas software yang dapat dihitung (secara langsung) .
Function points dihitung dengan melengkapi tabel 2. 2 . Karakteristik
lima sumber informasi yang ditetapkan, dan menghitung semua yang disediakan
di dalam lokasi tabel yang sesuai. Lima sumber informasi ini adalah :
33
Tabel 2.1 Menghitung Function Points metrics
Weighting factor
Measurement parameter
count
simple
average
complex
count
Number of user inputs
X
3 +
X
4
+
X
6
=
Number of user outputs
X
4 +
X
5
+
X
7
=
Number of user inquiries
X
3 +
X
4
+
X
6
=
Number of files
X
7 +
X
10
+
X
15
=
Number of external interfaces
X
5 +
X
7
+
X
10
=
Count = total
Number of user inputs. Setiap user inputs yang menyediakan aplikasi
berorientasi data yang terdapat pada software. Inputs harus dibedakan dari
inquiries yang akan dihitung secara terpisah.
Number of user outputs. Setiap user outputs yang menyediakan aplikasi
berorientasi informasi kepada user dihitung. Pada konteks ini outputs menunjuk
kepada laporan, screens, pesan kesalahan dan banyak lagi. Jenis data individual
yang terdapat dalam laporan tidak dihitung secara terpisah.
34
Number of user inquiries. Suatu inquiry didefinisikan sebagai online
input yang menghasilkan dalam generasi dari beberapa tanggapan software
menengah dalam form dari suatu online output. Setiap inquiry dihitung.
Number of files. Setiap master file (suatu pengelompokkan data secara
logic yang mungkin merupakan satu bagian dari database yang besar atau suatu
file yang terpisah) dihitung.
Number of external interface. Semua mesin yang dapat membaca
interface (contohnya, data file dalam disket) yang digunakan untuk
memindahkan informasi ke sistem lain dihitung.
Setelah data diatas dikumpulkan, nilai kompleksitas digabungkan dengan
masing-masing hitungan. Organisasi yang menggunakan metode function point
mengembangkan kriteria untuk menentukan apakah entry itu termasuk kedalam
simple, average, atau complex. Pada akhirnya penentuan dari kompleksitas itu
bersifat subjective (menurut penilaian organisasi sendiri).
Tabel 2.2 Menentukan Kompleksitas Function Points
Semantic
Statement
1-5
6-10
11+
Processing
Steps
1-10
Low
Low
Average
11-20
Low
Average
High
21+
Average
High
High
Processing Steps merupakan seri dari transformasi yang dibatasi oleh
kumpulan Semantic Statement. Sebagai aturan umum, transformasi diselesaikan
35
dengan algorithm yang menghasilkan perubahan dasar input data yang diproses
menjadi output data.
Tingkatan dari kompleksitas yang ditandai untuk masing-masing
transformasi merupakan fungsi dari beberapa processing steps dan semantic
statements.
Untuk menghitung function points (FP), rumus yang digunakan adalah :
FP = count total x [0.65 + 0.01 x Σ Fi ]
Fi (i = 1 s/d 14) adalah “nilai ketetapan kompleksitas” berdasarkan dari
tanggapan kepada pertanyaan-pertanyaan [ART85] yang ada pada tabel di bawah
ini.
Rate each factor on a scale of 0 to 5 :
0
1
2
No
Incidental
Moderate
3
Average
4
Significant
5
Essential
36
Tabel 2.3 Menghitung Function Points
Fi :
Apakah sistem membutuhkan backup dan recovery yang dapat diandalkan?
Apakah data komunikasi dibutuhkan?
Apakah ada fungsi-fungsi pemrosesan terdistribusi?
Apakah kinerja merupakah hal yang penting?
Apakah sistem akan berjalan pada lingkungan operasional yang berat?
Apakah sistem memerlukan masukan data secara on-line?
Apakah masukan data secara on-line membutuhkan transaksi input pada berbagai layar atau operasi?
Apakah master files di-update secara on-line?
Apakah input, output, atau inquiries kompleks?
Apakah pemrosesan internal kompleks?
Apakah kode dirancang untuk dapat digunakan kembali?
Apakah konversi dan instalasi termasuk didalam perancangan?
Apakah sistem dirancang untuk instalasi di organisasi yang berbeda?
Apakah aplikasi dirancang untuk memfasilitasi perubahan dan memudahkan penggunaan oleh pengguna?
2.7.2
Lines Of Code (LOC)
Menurut Olson (2003, pp166-167), Metode lines of code dan function
point memulai dengan pendekatan secara ilmiah dari mengumpulkan catatan
secara histori atas pengalaman proyek terdahulu. Data secara histori ini adalah
dasar untuk mengidentifikasi hubungan antara ukuran-ukuran kunci yang penting
(seperti person-months dari effort dan biaya-biaya pengeluaran) dan faktor lain
yang juga penting (contohnya halaman-halamam dari dokumentasi yang
37
dihasilkan, pesan-pesan kesalahan yang ditemukan, kerusakan sistem, dan
penunjukkan sumber daya manusia)
Ketika menjumpai suatu proyek baru, estimasi dibuat berdasarkan lines of
code yang dibutuhkan oleh proyek. Sebagai contoh, jika sebuah proyek
diestimasi hingga terdapat 10,000 lines of code, estimasi dari ukuran-ukuran ini
adalah sebagai berikut :
Tabel 2.4 Lines of Code Operation
Budget
Average of Past Projects :
Effort
LOC
33 mos.
20,543
Average per KLOC
1.606
Documentation
($, Thousands)
(pages)
Errors
Defects
People
4
351
1,194
201
52
15.673
58.122
9.784
2.531
SLOC :
estimate lines of code, multiply
2.7.3
Effort
1.606 x 10,000 LOC = 16 person-months
Budget
15.673 x 10,000 LOC = $157,000
Documentation
58.122 x 10,000 LOC = 581 pages
Errors
9.784 x 10,000 LOC = 98
Defects
2.531 x 10,000 LOC = 25
People
0.195 x 10,000LOC = 2 people
Constructive Cost Model (COCOMO)
Menurut Olson (2003, pp170-171), Dasar model COCOMO menghitung
usaha pengembangan software berdasarkan dari ukuran program. Model
0.195
38
menengah juga mempertimbangkan suatu set dari harga yang mencerminkan
produk secara spesifik, hardware, personnel, dan karakteristik proyek.
Untuk yang relatif kecil, proyek software sederhana dibangun oleh tim
kecil dengan pengalaman yang bagus, formula-formula COCOMO untuk personmonths atas effort dan pengembangan waktu dalam bulan secara kronologis
sebagai berikut (Organik):
Person-months = 2.4 x KLOC 1.05 = E for effort
Duration (months) = 2.5 x E 0.38
Di mana KLOC berarti ribuan lines of code. Di bawah ini tipe untuk
pekerjaan yangterdiri dari 50,000 lines of code
Person-months = 2.4 x 50 1.05 = 145.925 months
Duration = 2.5 x 145.925 0.38 = 16.6 months
Untuk proyek software dengan ukuran menengah dan agak kompleks,
dibangun oleh tim dengan pengalaman campuran dan menghadapi banyak
kerumitan dibandingkan kebutuhan rata-rata, formulanya adalah (semi detached):
Person-months = 3.0 x KLOC 1.12
Duration (months) = 2.5 x E 0.35
Suatu pekerjaan dengan tipe ini yang mengandung 50,000 lines of code,
perhitungannya adalah :
Person-months = 3.0 x 50 1.12 = 239.865 months
Duration = 2.5 x 239.865 0.35 = 17.0 months
Akhirnya, untuk pembangunan proyek software di bawah kondisi yang
sangat rumit, formulanya adalah (embadded) :
Person-months = 3.6 x KLOC 1.2
39
Duration (months) = 2.5 x E 0.32
Suatu pekerjaan yang mengandung 50,000 lines of code dengan kondisi
yang sangat rumit ini adalah :
Person-months = 3.6 x 50 1.2 = 393.610 months
Duration = 2.5 x 393.610 0.32 = 16.9 months