Manajemen Proyek Perangkat Lunak TI PDF

MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Pengantar Manajemen Proyek
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
01
Fakultas Ilmu Informatika 87025 Tim Dosen
Komputer
Abstract Kompetensi
Pada bab ini akan dijelaskan Mahasiswa memiliki gambaran
mengenai dasar manajemen umum tentang isi dari manajemen
proyek proyek perangkat lunak
2015 Manajemen Proyek Perangkat Lunak Pusat Bahan Ajar dan eLearning
1 Tim Dosen http://www.mercubuana.ac.id
1. Manajemen Proyek
1. Pengertian Manajemen
Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan,

mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber
daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah
ditentukan.
2. Pengertian Proyek
Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara
untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek
melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor
utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif
untuk menyelesaikan proyek secara efisien dan tepat waktu.
Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan
usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi
kinerja yang dirancang untuk memenuhi kebutuhan customer.
Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai
berikut :
1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan
suatu produk khusus, layanan, dan hasil akhir.
2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas.
3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya
dapat berupa hardware, software, dan sumber daya lainnya.
4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor.
5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek
bersifat unik maka sangat sulit untuk menentukan objektifitas proyek,
mengestimasi waktu proyek, dan biayanya.
Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan
kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek
membantu membedakan proyek tersebut dari yang lainnya dalam organisasi.
Karakteristik utama dari proyek adalah :
1. Penetapan tujuan
2. Masa hidup yang terdefinisi mulai dari awal hingga akhir
3. Biasanya melibatkan beberapa departemen dan professional
4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya
5. Waktu, biaya, dan kebutuhan yang spesifik
Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang
membuat proyek software berbeda dengan proyek lainnya.
1. Invisibility
Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara
langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan
jembatan dan sebagainya.
2. Complexity
Produk software memiliki lebih banyak kompleksitas daripada proyek fisik
termasuk dari sisi biayanya.
3. Conformity
Pengembang software harus menyesuaikan kebutuhan software dan
kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada
dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal
hingga akhir menjadi hal yang penting dalam keberhasilan proyek.
4. Flexibility
Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah
kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah
dengan mudah untuk mengakomodasi perubahan lingkungan bisnis
organisasi dan komponen lainnya.
Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda
terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple
constraint (3 kendala). Setiap manajer proyek 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 ?
Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin
meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus
diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya
melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus
berkompromi dengan mutu atau jadwal.
Gambar 1.1 Triple Constraint

(Sumber : Schwalbe, 2006, p7)
3. Pengertian Perangkat Lunak

Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan:
1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan
kinerja yang diinginkan pada saat dieksekusi atau dijalankan.
2. Struktur – struktur data yang memungkinkan program memanipulasi
informasi sesuai yang diinginkan.
3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari
program – program.
Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware).
Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu :
1. System software membantu user dalam menjalankan hardware dan sistem
komputer. Salah satu contoh system software adalah operating system dan
device drivers. Tujuan dari system software adalah mengisolasi sebanyak
mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit
terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti
printer dan keyboard.
2. Programming Software biasanya menyediakan tools untuk membantu
programmer dalam menulis program – program komputer dan software
dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang
digunakan meliputi text editor, compiler, debbuger, dan sebagainya.
3. Application Software memungkinkan user menyelesaikan satu atau beberapa
tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi
business software, educational software, basis data, dan computer games.
4. Pengertian Manajemen Proyek
Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu
pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud
memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek.
Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan,

mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk
mencapai sasaran jangka pendek yang telah ditentukan.
Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek
antara lain :
1. Manajer Proyek
Elemen paling penting dalam manajemen proyek adalah manajer proyek.
Manajer proyek adalah seseorang yang bertanggung jawab untuk
merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari
anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan
usaha antar area fungsional dan mengintegrasikan perencanaan dan
pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek.
2. Tim proyek
Tim proyek merupakan kumpulan orang yang biasanya berasal dari area
fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk
menyelesaikan pekerjaan proyek.
3. Sistem Manajemen Proyek

Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu
dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat
berdasarkan struktur organisasi, proses informasi, dan pelatihan serta
prosedur yang mengintegrasikan elemen dari organisasi proyek secara
vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam
proyek sedangkan elemen horizontal meliputi unit fungsional dan
departemen yang terlibat dalam proyek.
5. Daur Hidup Manajemen Proyek
Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle)
merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup
proyek terdiri dari :
1. Project Feasibility
Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada
perencanaan.
2. Project Acquisition
Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini
berfokus kepada penyampaian tugas yang nyata dan seharusnya
dilaksanakan.
Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum
melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan
suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap
operasi yang berjalan dalam suatu organisasi.
Gambar 2.2 Fase Daur Hidup Proyek
6. System Development Life Cycle (SDLC)
Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah
kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam
pengembangan sistem informasi. Salah satu model yang popular dan banyak
digunakan dalam daur hidup pengembangan sistem adalah model Waterfall.
7. Model Waterfall
Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran

umpan balik antara tahapan – tahapan dari pengembangan software untuk
meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan
yang meliputi : System feasibility, software plans and requirement, product
design, detailed design, code, integration, implementation, operation and
maintenance.
Kelebihan dari model Waterfall adalah :
1. Mendukung perencanaan sebelum dilakukannya proses desain.
2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan.
3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek.
4. Menyediakan suatu struktur proyek.
Kekurangan dari model Waterfall adalah :
1. Masalah baru diketahui setelah pengerjaan proyek telah selesai.
2. Sering kali kebutuhan user tidak terpenuhi.
3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek.
Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan

pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini
mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi.
Model Waterfall mempunyai beberapa tahapan sebagai berikut:

1. System Feasibility
Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk
piranti lunak serta menentukan daur hidup dari proyek.
2. Software Plans and Requirements
Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti
lunak secara rinci.
3. Product Design
Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur
pengendalian, dan struktur data bagi produk dan komponen lainnya yang
diperlukan sebagai dokumen bagi user dan tahap pengujian.
4. Detailed Design
Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data,
hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap
komponen program.
5. Code
Komponen program secara keseluruhan.
6. Integration
Penyatuan masing – masing fungsi komponen agar piranti lunak dapat
bekerja seharusnya.
7. Implementation
Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi,
dan pelatihan user.
8. Operations and Maintenace
Perawatan bagi sistem yang telah dibuat.
Gambar 2.3 Model Waterfall
(Sumber : http://www.jodypaul.com)
8. Sembilan Area Pengetahuan Manajemen Proyek
Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen

proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer
proyek.
Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang
lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut
merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek
yang lebih spesifik.
Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area
pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui
untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen
integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya
menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek
dengan baik.
I. Referensi
1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course
Technology Inc. ISBN: 978-1418835590
2. Olson, David. 2004. Introduction to Information Systems Project
Management, 2nd Ed. ISBN: 0-07-282402-6
3. Larson, Erick. W. 2000. Project management: the managerial process.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Pengantar Manajemen Proyek

(Lanjutan)
02
Komputer
Abstract Kompetensi
Pada bab ini akan dijelaskan Mahasiswa memiliki gambaran
mengenai dasar manajemen umum tentang isi dari manajemen
proyek proyek perangkat lunak
1. Manajemen Proyek
1. Pengertian Manajemen
Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan,

mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber
daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah
ditentukan.
2. Pengertian Proyek
Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara
untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek
melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor
utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif
untuk menyelesaikan proyek secara efisien dan tepat waktu.
Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan
usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi
kinerja yang dirancang untuk memenuhi kebutuhan customer.
Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai
berikut :
1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan
suatu produk khusus, layanan, dan hasil akhir.
2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas.
3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya
dapat berupa hardware, software, dan sumber daya lainnya.
4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor.
5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek
bersifat unik maka sangat sulit untuk menentukan objektifitas proyek,
mengestimasi waktu proyek, dan biayanya.
Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan
kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek
membantu membedakan proyek tersebut dari yang lainnya dalam organisasi.
Karakteristik utama dari proyek adalah :
1. Penetapan tujuan
2. Masa hidup yang terdefinisi mulai dari awal hingga akhir
3. Biasanya melibatkan beberapa departemen dan professional
4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya
5. Waktu, biaya, dan kebutuhan yang spesifik
Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang
membuat proyek software berbeda dengan proyek lainnya.
1. Invisibility
Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara
langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan
jembatan dan sebagainya.
2. Complexity
Produk software memiliki lebih banyak kompleksitas daripada proyek fisik
termasuk dari sisi biayanya.
3. Conformity
Pengembang software harus menyesuaikan kebutuhan software dan
kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada
dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal
hingga akhir menjadi hal yang penting dalam keberhasilan proyek.
4. Flexibility
Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah
kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah
dengan mudah untuk mengakomodasi perubahan lingkungan bisnis
organisasi dan komponen lainnya.
Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda
terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple
constraint (3 kendala). Setiap manajer proyek 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 ?
Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin
meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus
diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya
melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus
berkompromi dengan mutu atau jadwal.
Gambar 1.1 Triple Constraint

3. Pengertian Perangkat Lunak

Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan:
1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan
kinerja yang diinginkan pada saat dieksekusi atau dijalankan.
2. Struktur – struktur data yang memungkinkan program memanipulasi
informasi sesuai yang diinginkan.
3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari
program – program.
Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware).
Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu :
1. System software membantu user dalam menjalankan hardware dan sistem
komputer. Salah satu contoh system software adalah operating system dan
device drivers. Tujuan dari system software adalah mengisolasi sebanyak
mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit
terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti
printer dan keyboard.
2. Programming Software biasanya menyediakan tools untuk membantu
programmer dalam menulis program – program komputer dan software
dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang
digunakan meliputi text editor, compiler, debbuger, dan sebagainya.
3. Application Software memungkinkan user menyelesaikan satu atau beberapa
tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi
business software, educational software, basis data, dan computer games.
4. Pengertian Manajemen Proyek
Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu
pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud
memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek.
Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan,

mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk
mencapai sasaran jangka pendek yang telah ditentukan.
Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek
antara lain :
1. Manajer Proyek
Elemen paling penting dalam manajemen proyek adalah manajer proyek.
Manajer proyek adalah seseorang yang bertanggung jawab untuk
merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari
anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan
usaha antar area fungsional dan mengintegrasikan perencanaan dan
pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek.
2. Tim proyek
Tim proyek merupakan kumpulan orang yang biasanya berasal dari area
fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk
menyelesaikan pekerjaan proyek.
3. Sistem Manajemen Proyek

Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu
dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat
berdasarkan struktur organisasi, proses informasi, dan pelatihan serta
prosedur yang mengintegrasikan elemen dari organisasi proyek secara
vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam
proyek sedangkan elemen horizontal meliputi unit fungsional dan
departemen yang terlibat dalam proyek.
5. Daur Hidup Manajemen Proyek
Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle)
merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup
proyek terdiri dari :
1. Project Feasibility
Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada
perencanaan.
2. Project Acquisition
Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini
berfokus kepada penyampaian tugas yang nyata dan seharusnya
dilaksanakan.
Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum
melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan
suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap
operasi yang berjalan dalam suatu organisasi.
Gambar 2.2 Fase Daur Hidup Proyek
6. System Development Life Cycle (SDLC)
Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah
kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam
pengembangan sistem informasi. Salah satu model yang popular dan banyak
digunakan dalam daur hidup pengembangan sistem adalah model Waterfall.
7. Model Waterfall
Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran

umpan balik antara tahapan – tahapan dari pengembangan software untuk
meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan
yang meliputi : System feasibility, software plans and requirement, product
design, detailed design, code, integration, implementation, operation and
maintenance.
Kelebihan dari model Waterfall adalah :
1. Mendukung perencanaan sebelum dilakukannya proses desain.
2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan.
3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek.
4. Menyediakan suatu struktur proyek.
Kekurangan dari model Waterfall adalah :
1. Masalah baru diketahui setelah pengerjaan proyek telah selesai.
2. Sering kali kebutuhan user tidak terpenuhi.
3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek.
Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan

pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini
mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi.
Model Waterfall mempunyai beberapa tahapan sebagai berikut:

1. System Feasibility
Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk
piranti lunak serta menentukan daur hidup dari proyek.
2. Software Plans and Requirements
Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti
lunak secara rinci.
3. Product Design
Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur
pengendalian, dan struktur data bagi produk dan komponen lainnya yang
diperlukan sebagai dokumen bagi user dan tahap pengujian.
4. Detailed Design
Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data,
hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap
komponen program.
5. Code
Komponen program secara keseluruhan.
6. Integration
Penyatuan masing – masing fungsi komponen agar piranti lunak dapat
bekerja seharusnya.
7. Implementation
Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi,
dan pelatihan user.
8. Operations and Maintenace
Perawatan bagi sistem yang telah dibuat.
Gambar 2.3 Model Waterfall
(Sumber : http://www.jodypaul.com)
8. Sembilan Area Pengetahuan Manajemen Proyek
Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen

proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer
proyek.
Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang
lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut
merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek
yang lebih spesifik.
Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area
pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui
untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen
integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya
menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek
dengan baik.
I. Referensi
1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course
Technology Inc. ISBN: 978-1418835590
2. Olson, David. 2004. Introduction to Information Systems Project
Management, 2nd Ed. ISBN: 0-07-282402-6
3. Larson, Erick. W. 2000. Project management: the managerial process.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Perencanaan Proyek
Perangkat Lunak
03
Komputer
Abstract Kompetensi
Pada bab ini menjelaskan tentang Mahasiswa memiliki kemampuan
maksud dari perencanaan proyek dalam memulai sebuah proyek
perangkat lunak perangkat lunak
Pemahaman terhadap Proyek Perangkat
Lunak
1. Pemahaman terhadap Proyek Perangkat Lunak
Proyek Software adalah manajemen proyek yang berfokus hanya pada

membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti
berikut ini:
a. Menyelesaikan masalah,
b. Mengerjakan sesuatu hingga selesai,
c. Memiliki batas waktu mulai dan selesainya,
d. Membutuhkan resource/sumber daya dan waktu,
e. Bagi beberapa orang merupakan kesempatan/opportunity dan menarik
Untuk itu sebuah proyek software perlu dikelola. Pengelolaan
(Manajemen) itu berupa persiapan pekerjaan, pelaksanaan rencana,
mengendalikan proyek tersebut dan terakhir menutup proyek dengan sebuah
kesimpulan, yaitu sukses. Secara lebih sistematis, tahapan-tahapan proyek dapat
dilihat pada gambar 3.1:
Gambar 3.1 Tahapan-tahapan Proyek
Tahapan proyek:
1. Initiating: proyek sedang dalam proses untuk dipilih/disetujui, disponsori,
didanai, dan diluncurkan.
2. Planning: perencanaan adalah proses yang berulang (perhatikan gambar).
Perencanaan pada dasarnya menggambarkan proses bagaimana proyek
akan dilaksanakan hingga selesai.
3. Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya.
4. Controlling: selama tim proyek mengerjakan tugasnya, project manager
mengontrolnya.
Closing: setelah proyek diselesaikan project manager akan menutup proyek

software. Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan adalah
bagian yang sangat penting bagi proyek software. Persiapan diwujudkan dalam
bentuk perencanaan proyek. Tulisan ini menjelaskan point kedua yaitu Planning.
2. Faktor-faktor yang mempengaruhi perkiraan biaya
Beberapa faktor yang mempengaruhi terhadap perkiraan biaya pembuatan

perangkat lunak yaitu:
a. Sulit untuk menentukan perkiraan biaya secara akurat selama fase
perencanaan pengembangan S/W karena terlalu banyaknya faktor yang tidak
diketahui pada saat itu.
b. Perkiraan awal disiapkan selama fase perencanaan dan dikemukakan pada
saat presentasi kelayakan proyek. Perbaikan dikemukakan pada saat
presentasi persya-ratan S/W, dan perkiraan akhir dikemukakan pada saat
presentasi perancangan awal.
Faktor-faktor utama yang mempengaruhi biaya perangkat lunak:

a. Kemampuan programmer
Programmer dengan produktivitas tinggi ekuivalen dengan biaya yang kecil.
b. Kompleksitas produk
Tiga katagori produk : aplikasi, utility, dan system
Rasio kompleksitasi ketiganya adalah :
aplikasi : utility : system = 1 : 3 : 9
Misal :
• Jika PM adalah total upaya
(dalam programmer-months)
dan KDSI adalah baris instruksi
dalam product (thousands of
delivered source instructions)
maka estimator PM menurut
Boehm adalah :
aplikasi : PM = 2.4 (KDSI)
utility : PM = 3.0 (KDSI)
• System : PM = 3.6 (KDSI) Untuk
jumlah baris program 60.000,
rasio PM aplikasi : utility :
system 1 : 1.7 : 2.8 (tepatnya
176.6 : 294.2 : 489.6).
(Lihat gambar)
• Estimasi upaya COCOMO
Jika TDEV adalah waktu (dalam bulan) pengembangan sebuah
program (development time), maka estimator TEDV menurut Boehm
TDEV adalah
aplikasi : TDEV = 2.5 (PM)
utility : TDEV = 2.5 (PM)
• System : TDEV = 2.4 (PM)
Untuk jumlah baris program 60.000, ketiga program
memerlukan waktu pengembangan sekitar 18 bulan (tepatnya
TDEV aplikasi : utility : system = 17.9 : 18:3 : 17.4).
Rata-rata jumlah programmer yang diperlukan untuk membuat 60
KDSI per bulan adalah :
aplikasi : 176.6 PM / 17.9 Months = 9.9 programmer
utility : 294.2 PM / 18.3 Months = 16.1 programmer
system : 489.6 PM / 17.4 Months = 28.1 programmer
c. Ukuran produk
Ukuran produk perangkat lunak yang dibuat akan mempengaruhi besarnya
Sumber daya yang dibutuhkan dalam pembuatannya. Tetapi ini harus bisa
terukur karena setiap sumber daya mempunyai nilai optimal tertentu.
d. Waktu yang tersedia

Berbagai penelitian (kecuali Putnam) menunjukkan bahwa proyek S/W
membutuhkan upaya lebih jika waktu pengembangan diperpendek atau
diperpanjang (dimodifikasi) dari waktu normal.
e. Keandalan yang diperlukan

Menurut Boehm, Lima katagori keandalan, efek kegagalan, beserta pengali
upaya (effort multiplier) meliputi:
f. Tingkat teknologi
Tingkat teknologi dalam proyek pengambangan S/W direfleksikan dengan
empat komponen yang digunakan, yaitu:
a) Bahasa pemrograman
b) Mesin abstrak (H/W dan S/W)
c) Praktek-praktek pemrograman
d) Tools.
3. Perencanaan Proyek Perangkat Lunak
Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut pandang
kurang lebih memiliki tujuan sebagai berikut:
1. Bagi Project Manager

a) Untuk menggambarkan status proyek kepada manajer senior dan
stakeholder
b) Untuk merencanakan aktivitas tim proyek
2. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan
3. Bagi Manajer Senior:
a) Untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal
dan terkendali
b) Untuk melihat apakah proyek dilaksanakan secara efisien dan cost
effective
4. Bagi Stakeholder:
a) Untuk memastikan apakah proyek masih berada pada jalurnya
b) Untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek
Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan

atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek,
termasuk dokumen-dokumen yang sebaiknya dibuat. Dokumen Perencanaan Proyek
Rekayasa Perangkat Lunak akan terdiri atas sub-sub dokumen yang meliputi Vision
and Scope, Statement of Work, Resource List, Work Breakdown Structure, Project
Schedule dan Risk Plan.
Vision and Scope

1. Vision and Scope
Dokumen ini adalah hasil kerja pertama dari seorang project manager.
Berikutnya dokumen ini akan menjadi tool utama bagi project manager untuk acuan
bagi dokumendokumen dan proses-proses berikutnya. Dokumen Vision and Scope
yang baik dapat mencegah terjadinya masalah-masalah yang dapat memakan biaya
yang besar.
Dengan menunjukkan dokumen ini, baik kepada stakeholder maupun
anggota tim proyek, diharapkan pemahaman yang sama tentang proyek yang
sedang berjalan dapat diraih. Dokumen ini dapat dibagi menjadi dua bagian, yaitu:
1. Problem Statement
Bagian Problem Statement terdiri atas empat sub bab, antara lain:
a. Latar belakang proyek
Sub bab ini menceritakan dengan cukup mendalam baik latar belakang
masalah maupun penjelasan mengenai mengapa organisasi
memutuskan untuk membangun software untuk mengatasi masalah
tersebut. Pada sub bab ini diceritakan sebab munculnya masalah,
sejarah organisasi dengan permasalahan tersebut dan mengapa
akhirnya diputuskan untuk membangun software yang diproyekkan.
b. Stakeholder
Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan
dalam proyek. Mulai dari customer hingga manajer-manajer senior.
Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus
paham dengan siapa mereka bekerja dan apa bidang kerja mereka.
Daftar juga dilengkapi dengan alasan dicantumkannya stakeholder
tersebut. Untuk proyek-proyek besar tentu saja pencantuman nama
tidak relevan karena akan menjadi terlalu panjang daftarnya.
c. Pengguna
Sub bab ini berisi daftar calon pengguna software. Sama dengan
stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi
dengan alasan dicantumkannya pengguna tersebut.
d. Resiko
Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi
pemicu munculnya masalah, seperti keterlambatan dan permasalahan
lain. Resiko yang dimaksud pada sub bab ini bisa faktor internal
maupun eksternal.
2. Vision of the Solution
Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu:
a. Vision statement
Tujuan vision statement adalah menggambarkan apa yang ingin
dicapai setelah proyek berjalan. Di dalam sub bab ini disebutkan
faktor-faktor apa yang harus terpenuhi untuk menandakan kapan
proyek dinyatakan selesai. Selain itu tujuan dari proyek juga harus
jelas disebutkan di dalam sub bab ini. Waktu terbaik untuk membuat
vision statement adalah setelah tim melakukan proses Requirement
Engineering.
Gambaran produk yang ingin dicapai tersebut akan menjadi batasan
ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang
terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan
waktu tertentu. Project manager yang baik akan mempersembahkan
software tepat seperti yang telah dijanjikan kepada stakeholder dan
user, tepat pada waktunya dengan menghabiskan biaya (menerima
bayaran) tepat sama dengan perjanjiannya dengan customer.
Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi
terhadap software, dengan asumsi bahwa stakeholder atau user akan
menyukainya, maka pendapat itu adalah kesalahan. Antara ruang
lingkup, waktu dan biaya/harga harus ada keseimbangan. Jika ada
penambahan pada ruang lingkup, maka seharusnya ada penambahan
waktu atau biaya, jika tidak maka akan menyebabkan ketidak adilan
bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan
ruang lingkup mestinya diatur dengan Change Control System.
b. Daftar fitur
Sebuah paket software umumnya dapat dibagi-bagi menjadi
beberapa fitur. Jumlah yang umumnya dapat diterima adalah sekitar
sepuluh fitur. Jumlah ini sudah cukup menggambarkan kompleksitas
software namun tetap nyaman dibaca oleh tim pengembang. Tiap fitur
sebaiknya ditulis dalam paragraph yang terpisah atau dalam bentuk
pointer-pointer. Deskripsi fitur-fitur ini tidak perlu sangat detil, cukup
beberapa kalimat yang menggambarkan penjelasan umum tentang fitur
tersebut. Fitur-fitur ini mungkin mengalami penambahan atau
pengurangan, sesuai dengan permintaan stakeholder. Jika perlu,
sebuah fitur dapat dilengkapi dengan use case. Namun tentu saja use
case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder.
3. Ruang lingkup tiap fase (jika perlu)
Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek
software membuat pengerjaan seluruh fitur yang diajukan tidak
mungkin selesai. Oleh karenanya dibuat solusi untuk membagi
software menjadi beberapa fase rilis. Software akan dirilis pada saat
deadline tercapai, namun dengan fitur yang dikurangi. Sedangkan rilis
berikutnya lah yang memuat semua fitur.
Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang
sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal
semacam ini perlu dikonsultasikan kepada tim pengembang.
4. Fitur yang tidak akan dibuat
Terkadang stakeholder meminta fitur yang memang harus
dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam
waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam
ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui
semua pihak agar ada kesepahaman dan agar semua setuju dengan
penghapusan fitur ini.
2. Statement of Work
Statement of Work adalah dokumen yang menggambarkan semua produk

yang akan dihasilkan selama proyek berjalan dan siaa yang akan mengerjakannya.
Secara lebih detil, di dalam SOW akan dirinci:
1. Daftar fitur yang akan dibuat; jika software akan dirilis dalam fase-fase,
maka fiturnya juga harus dibagi ke dalam fase-fase tersebut.
2. Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source code,
test plan, laporan defect, dll) yang akan dibuat.
3. Estimasi usaha setiap work product tersebut
Estimasi dibutuhkan agar proyek dapat berjalan dan selesai tepat waktu.
Project manager perlu membantu timnya untuk membuat estimasi yang tepat.
Sebuah pendekatan perlu diambil untuk menyeragamkan teknik estimasi ini. Salah
satu teknik estimasi yang dapat dipilih adalah Wideband Delphi. Berikut ini
langkah-langkah di dalam Wideband Delhi:
1. Memilih tim estimasi
Project manager memilih seorang moderator dan tim estimasi yang terdiri
atas 3 hingga 7 orang. Jika tim yang telah dipilih merasa bahwa dokumen
Vision and Scope kurang memberikan informasi, maka project manager
harus memperbaiki dokumen tersebut.
2. Kickoff Meeting
Pada rapat ini, tim akan membuat sebuah Work Breakdown Structure dan
mendiskusikan berbagai asumsi yang muncul. Langkah-langkah yang dapat
dijadikan acuan ketika rapat berlangsung kurang lebih sebagai berikut:
a. Moderator menjelaskan metode Wideband Delphi
b. Moderator mereview dokumen Vision and Scope dan dokumen-
dokumen pendukungnya, jika ada anggota tim yang belum
membacanya.
c. Tim mendiskusikan produk yang akan dibuat dengan berbagai
asumsinya,
d. Tim membuat 10 hingga 20 pekerjaan utama sebagai representasi
pekerjaan level tertinggi pada WBS
e. Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll)
tersebut hingga mendapatkan kata sepakat.
3. Individual Preparation
Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap
pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebagai
Individual Preparation. Sebelumnya, moderator mencatat semua asumsi
dan WBS kemudian membagikannya kepada semua anggota tim. Format
berikut ini bisa dijadikan acuan untuk mendokumentasikan Individual
Preparation.
Gambar 3.2. Dokumen Individual Preparation
4. Estimation Session
Pada rapat ini, anggota tim bersama-sama merevisi estimasi-estimasiyang
telah dibuat hingga menemukan kata sepakat. Dokumen berikut dapat
dijadikan acuan sebagai contoh untuk membuat dokumentasi selama
Estimation Session. Kepada setiap anggota tim akan dibagikan dokumen
semacam ini (yang kosong) untuk kemudian direvisi selama jalannya
Estimation Session.
Gambar 3.3 Estimation Form
Berikutnya:
a. Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut
kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada
hadiri. Tabulasi tersebut dapat berbentuk seperti berikut:
Gambar 3.4 Estimasi awal

Estimation Form kemudian dikembalikan kepada anggota tim
b. Anggota kemudian akan melihat tabulasi tersebut. Jika diskusi meminta
perubahan estimasi, maka perubahan tersebut dapat langsung
dituliskan pada Estimation Form yang ada di tangan setiap anggota tim
c. Anggota tim mungkin akan menyampaikan perbedaan pendapat. Tetapi
di dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang
mungkin diperdebatkan justru pekerjaannya. Tahap ini mugkin terbagi
menjadi dua sesi, sesi pertama 40 menit dan sesi kedua 20 menit.
d. Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta
berikutnya pada Estimation Form. Isinya bisa +3, +2, -4 dsb. Nilai total
barunya akan dituliskan pada bagian bawah form.
Tahap-tahap di atas dapat berulang hingga selesai, yaitu jika semua anggota
tim menyetujui estimasi hasil rapat, atau jika rapat sudah berlangsung selama dua
jam. Hasilnya akan menghasilkan tabulasi estimasi seperti berikut:
Gambar 3.5 Estimasi akhir
5. Review
Project manager akan meringkas, mengkompail kemudian mereview hasil
estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek
software.
3. Resource List
Resource list adalah daftar resource (sumber daya) yang digunakan selama
proyek berlangsung. Daftar ini berisi apa saja yang dibutuhkan berdasarkan jadwal
proyek dengan mencantumkan deskripsi resource tersebut serta limit ketersediaan
resource tersebut. Daftar semacam ini umumnya dapat dibuat menggunakan
software manajemen proyek. Tetapi bisa juga dibuat dengan worksheet atau word
processor. Setelah SOW dan Resource List dibuat, seorang project manager harus
membuat jadwal proyek (project schedule). Ini bisa dilakukan dengan urutan sebagai
berikut:
a. Membuat Work Breakdown Structure
b. Estimasi usaha yang dibutuhkan oleh setiap pekerjaan pada WBS
c. Project schedule dibuat dengan mengalokasikan resource dan waktu,
berdasarkan kalender, untuk tiap pekerjaan pada WBS
Jika WBS mengalami revisi (setelah melakukan estimasi, misalnya), misalnya

penambahan, perubahan atau penghapusan pekerjaan, maka revisi ini harus tercatat
di dalam dokumen Project Plan dengan disertai dengan keterangan waktu kapan
dibuatnya perubahan tersebut.
4. Work Breakdown Structure
Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika
diselesaikan akan menghasilkan work product. WBS menyebutkan:
a. Apa saja pekerjaan yang akan dilakukan,
b. Tipe-tipe resource yang dibutuhkan untuk bekerja,
c. Estimasi tiap elemen pekerjaan,
d. Identifikasi lokasi penyimpanan.
Tetapi tidak mencantumkan:

a. Siapa yang mengerjakan pekerjaan-pekerjaan itu,
b. Dan kapan pekerjaan itu akan diselesaikan
5. Project Schedule
Project Schedule atau jadwal proyek dibuat oleh project manager untuk
mengatur manusia di dalam proyek dan menunjukkan kepada organisasi
bagaimana pekerjaan (proyek) akan dilaksanakan. Ini adalah alat untuk memantau
(bagi project manager) apakah proyek dan tim masih terkendali atau tidak.
Project schedule berbentuk kalender yang dihubungkan dengan pekerjaan
yang harus dikerjakan dan daftar resource yang dibutuhkan. Sebelum jadwal dibuat,
WBS harus terlebih dahulu ada, jika tidak maka jadwal tersebut akan terkesan
mengada-ada. Untuk membuat project schedule, ada beberapa software yang bisa
dijadikan pilihan. Pilihan software yang gratis dan open source antara lain: Open
Workbench, dotProject, netOffice dan Tutos. Beberapa hal perlu diperhatikan ketika
membuat project schedule, seperti:
a) Alokasi resource pada tiap pekerjaan
Resource bisa berupa berbagai hal seperti manusia, barang,
peralatan (komputer, proyektor, dll), tempat (ruang rapat, misalnya)
atau layanan (seperti training atau tim pendukung out source) yang
dibutuhkan dan mungkin ketersediaannya terbatas. Bagaimanapun
juga resource yang utama adalah manusia.
Pertama, project manager akan mengalokasikan orang(-orang)
tertentu untuk suatu pekerjaan. Kemudian, selama pekerjaan
tersebut berlangsung, orang tersebut mungkin menjadi terlalu sibuk
sehingga tidak bisa dialokasikan untuk pekerjaan lainnya. Perhatikan
bahwa pemilihan pelaku perlu disesuaikan dengan kemampuan dan
berbagai hal lain karena ada pekerjaan yang dapat dilakukan oleh
siapa saja, tetapi umumnya pekerjaan hanya dapat dikerjakan oleh
satu atau beberapa orang saja.
b) Identifikasikan setiap ketergantungan
Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan
aktivitas, resource atau work product yang dihasilkan
pekerjaan/aktivitas lain. Contoh: test plan tidak mungkin
dilaksanakan selama software belum diimplementasikan/ditulis,
program baru dapat ditulis setelah class atau modul dibuat dan
dideskripsikan pada tahapan desain.
Tiap pekerjaan pada WBS perlu diberi nomor, dengan angka tersebut
bergantung pada nomor pekerjaan syaratnya. Berikut ini adalah
sedikit gambaran tentang bagaimana suatu pekerjaan menjadi
tergantung pada pekerjaan lainnya.
c) Buat jadwalnya
Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan
demikian jadwal bisa dibuat, contoh:
Tiap pekerjaan ditunjukkan dengan kotak, sedangkan

ketergantungan antar pekerjaan ditunjukkan dengan gambar panah.
Kotak hitam berbentuk wajik antara D dan E (pada gambar di atas)
disebut milestone atau pekerjaan tanpa durasi. Milestone digunakan
untuk menunjukkan kejadian penting pada jadwal. Sedangkan kotak
hitam panjang antara C dan D yang juga mengandung potongan
wajik menunjukkan summary task atau dua sub pekerjaan yang
memiliki induk yang sama. Jadwal bisa dibuat dalam bentuk Gantt
Chart, PERT atau diagram semacamnya.
Contoh Gantt Chart yang dibuat dengan sebuah tool manajemen
proyek:
6. Risk Plan
Risk plan adalah daftar resiko/masalah yang mungkin terjadi

selama proyek berlangsung dan bagaimana menangani terjadinya resiko tersebut.
Bagaimanapun juga ketidakpastian adalah musuh semua rencana, termasuk
rencana proyek. Terkadang ada saja waktu-waktu yang tidak menyenangkan bagi
proyek, banyak kesulitan terjadi misalnya suatu resource tiba-tiba tidak tersedia.
Oleh karenanya risk plan adalah persiapan terbaik menghadapi ketidakpastian.
Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk
Plan:
a) Pembahasan resiko potensial
Project manager akan memimpin sebuah sesi/rapat untuk
mengidentifikasikan masalah-masalah yang mungkin akan muncul.
Anggota tim akan dipancing untuk mengemukakan resiko-resiko yang
terpikirkan. Project manager akan menuliskannya di papan tulis setiap
ada yang mengemukakan pendapat yang relevan. Sedikit pendapat
mungkin akan muncul pada awalnya, kemudian berlanjut dengan
tanggapan yang susul-menyusul hingga akhirnya suasana mendingin
sampai akhirnya pendapat terakhir diutarakan.
Resiko yang dimaksud di sini adalah resiko spesifik. Jika suatu resiko
dirasa belum spesifik maka project manager akan memancing agar
permasalahan disampaikan secara lebih spesifik. Sumber masalah yang
baik lainnya adah asumsi-asumsi yang muncul ketika membuat Vision
and Scope dan melakukan estimasi dengan metode Wideband Dephi
b) Estimasi dampat tiap resiko/masalah
Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar dari 1
(masalah dengan resiko kecil) hingga 5 (masalah dengan resiko besar,
kemungkinan munculnya besar, mungkin menghabiskan biaya besar dan
sulit untuk membereskannya).
c) Buat sebuah risk plan
Tim akan mengidentifikasi langkah-langkah yang akan di ambil untuk
mengatasi masalah-masalah yang akan muncul tersebut, dimulai dari
resiko bernilai 5.
Contoh sebuah dokumen risk plan:
Gambar 3.6 Risk Plan
I. Referensi
1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill
2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley
MODUL PERKULIAHAN
Manajemen
Proyek
Perangkat Lunak
Perencanaan Proyek
Perangkat Lunak (Lanjutan)
04
Komputer
Abstract Kompetensi
Pada bab ini menjelaskan Mahasiswa mampu memahami mengenai
tentang maksud dari perencanaan perangkat lunak, mampu memahami
perencanaan proyek perangkat unsur – unsur yang patut diperhitungkan dalam
lunak merencanakan pembuatan perangkat lunak, dan
mampu mengenali metode yang umum digunakan
dalam sebuah perencanaan proyek pengembangan
perangkat lunak.
Perencanaan Proyek Perangkat Lunak
1. Perencanaan Proyek Perangkat Lunak
A. Pendefinisian Masalah
1. Nyatakan masalah yang akan diselesaikan secara tegas, termasuk di

dalamnya batasan masalah dan sasaran yang ingin dicapai. Pernyataan
masalah ditetapkan dalam sudut pandang pelanggan.
• Pernyataan masalah dalam sudut pelanggan misalnya : masalah
penggajian, masalah inventory, atau masalah pengendalian lalu lintas
udara
• Pernyataan masalah dalam sudut pengembang misalnya : masalah
relational data bases, masalah algoritma sorting.
Teknik-teknik yang digunakan untuk mendapatkan informasi kebutuhan
pelanggan meliputi : wawancara dengan pelanggan, pengamatan
terhadap gugus tugas yang bermasalah, kinerja sebenarnya dari gugus
tugas.
2. Rancang sebuah strategi solusi berbasis komputer.
• Solusi harus ekonomis dan dapat diterima secara sosial maupun secara
politik.
• Solusi yang ekonomis adalah sistem komputerisasi yang memberikan
pelayanan dan informasi yang sama dengan sistem lama tetapi
membutuhkan waktu dan personal yang lebih sedikit dalam
pengoperasiannya.
Sistem baru mungkin akan mengurangi keterlibatan personal; hal ini
mungkin akan menimbulkan dampak sosial, bahkan politik.
3. Identifikasi sumber daya yang tersedia.
• Tiga subsistem dalam sistem komputerisasi adalah : perangkat keras,
perangkat lunak, dan personal. Identifikasi juga keterkaitan antar ketiga
subsistem tersebut.
2015
Manajemen Proyek Perangkat Pusat Bahan Ajar dan eLearning
2 Lunak Tim Dosen http://www.mercubuana.ac.id
• Subsistem perangkat keras meliputi perangkat keras beserta periferalnya,
dan dalam beberapa kasus juga meliputi peralatan lain seperti sensor
kendali proses, antena, dan radar.
• Subsistem perangkat lunak meliputi perangkat lunak yang akan
dikembangkan ditambah dengan perangkat lunak yang ada yang boleh
jadi digunakan seadanya atau dalam versi modifikasinya.
Subsistem personal meliputi para operator, pemelihara, dan end user.
4. Tetapkan sasaran dan persyaratan, baik untuk proses pengembangan maupun
produk.
• Sasaran adalah tujuan yang ingin dicapai. Sasaran digunakan sebagai
dasar bagi kerangka kerja proyek pengembangan perangkat lunak, baik
dalam proses pengembangan maupun untuk produk kerja.
• Sasaran dapat dinyatakan secara kualitatif maupun kuantitatif. Contoh :
 Proses (kualitatif) : harus meningkatkan keterampilan personal
 Proses (kuantitatif) : sistem harus selesai dalam 12 bulan
 Produk (kualitatif) : sistem harus membuat pekerjaan user maikin
menarik
 Produk (kuantitatif) : sistem harus mengurangi biaya transaksi sebesar
25%.
• Persyaratan menetapkan spesifikasi kemampuan sistem dalam
menyelesaikan masalah.
• Persyaratan mencakup aspek-aspek : fungsional, kinerja, perangkat
keras, perangkat lunak, personal, dan pengantarmukaan.
• Kalau memungkinkan, nyatakan persyaratan secara kuantitaif untuk
menghindari ketidakjelasan dan perselisihan antara pengembang dengan
pelanggan.
• Contoh persyaratan kuantitatif :
 Akurasi sudut fase harus berada pada kisaran 0.5 derajat
 Tanggapan maksimum terhadap interrup adalah 0.25 detik
 Space maksimum yang digunakan sistem adalah 50 KB memori
utama, tidak termasuk space untuk file-file buffer
2015 Manajemen Proyek Perangkat Pusat Bahan Ajar dan eLearning

 Sistem harus dapat beroperasi dengan kemampuan 95% ketika
dioperasikan selama 24 jam penuh
• Contoh persyaratan kualitatif :
 Akurasi harus cukup tinggi
 Sistem harus mempunyai tanggapan yang baik
 Sistem harus hemat dalam penggunaan memori utama
 Keandalan sistem harus 99%
• Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut
kualitas yang harus dimiliki sistem, di antaranya : portability (S/W tidak
bergantung mesin), realiability (kemampuan program melakukan fungsi
yang diinginkan), efficiency (menggunakan sumber daya minimal),
accuracy (ukuran besarnya error), robustness/integrity (kemampuan
bekerja dengan baik walau mendapat input yang tidak benar), correctness
(hasil sesuai dengan yang diharapkan).
5. Tetapkan kriteria penerimaan sebuah system.
• Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan
menimbulkan perselisihan antara pengembang dan pelanggan. Kriteria
harus dapat diverfikasi dengan suatu metoda baku seperti : peninjauan
langsung, analisa, atau serangkaian uji, terhadap produk yang
dihasilkan.
B. Pengembangan Strategi Solusi

• Kecenderungan untuk menerima begitu saja solusi pertama yang terlintas di
benak kita adalah masalah utama dalam perkeayasaan perangkat lunak. Ini
tidak memberi peluang terhadap solusi lain yang sebenarnya masih
mungkin untuk dipertimbangkan.
• Kembangkan strategi solusi. Strategi bukan merupakan solusi rinci tetapi
penyataan umum tentang sifat-sifat dari solusi yang mungkin.
• Langkah-langkah pengembangan strategi solusi adalah sebagai berikut : 1.
Uraikan beberapa strategi solusi tanpa memperhatikan batasanbatasan
apapun
2. Adakan studi kelayakan terhadap setiap strategi. Perhatikan bahwa an
unreasonable idea will lead to other ideas, some of which may be very
reasonable.
3. Rekomendasikan sebuah strategi solusi, beri catatan mengapa solusi
lain ditolak
4. Buat sebuah daftar prioritas karakteristik produk. Daftar ini penting jika
kondisi tidak memungkinkan untuk mengimplementasikan seluruh
kemampuan produk yang diinginkan seperti yang telah ditentukan
sebelumnya.
C. Perencanaan Proses Pengembangan

1. Tentukan sebuah model life-cycle dan struktur organisasi proyek.
2. Rencanakan konfigurasi managemen, jaminan kualitas, dan kegiatan
validasi
3. Tentukan tools setiap fase proyek, serta teknik-teknik dan notasi yang
digunakan
4. Tetapkan perkiraan biaya untuk pengembangan sistem
5. Tetapkan jadwal pengembangan
6. Tetapkan perkiraan susunan personalia proyek
7. Tetapkan perkiraan sumber daya sistem komputaerisasi yang diperlukan
untuk mengoperasikan dan memelihara sistem
8. Siapkan daftar istilah
9. Identifikasi sumber-sumber informasi dan jadikan sebagai acuan proyek.
D. Life Cycle
Life-cycle sebuah perangkat lunak mencakup semua kegiatan yang yang
perlu dilakukan untuk mendefinisikan, mengembangkan, menguji, mengantarkan,
mengoperasikan, dan memelihara produk perangkat lunak. Beberapa model yang
akan dibahas adalah : model fase (phased model), model biaya (cost model), model
prototipe (prototype model), dan model berurutan (successive model).

E. Model Fase
Model ini membagi life cycle ke dalam sederetan kegiatan (fase). Setiap fase
membutuhkan informasi masukan, proses, dan produk yang terdefinisi dengan baik.
Deretan fase tersebut adalah : analisa, perancangan, implementasi, pengujian, dan
pemeliharaan. Berikut ini model fase dasar yang dinyatakan sebagai waterfall chart :
Gambar 4.1 Life cycle mode fase dari sebuah perangkat lunak
• Subfase perencanaan menghasilkan dua produk : System Definition dan Poject

Plan. Format kedua produk adalah sebagai berikut :
2015 Manajemen Proyek Perangkat Lunak

6 Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
• S
u
b
f
a
s
e
p
e
n
e
t
a
p
a
n
persyaratan menghasilkan sebuah produk : Software Requirements Specifications. Format
2015
7
• Fase perancangan melakukan identifikasi terhadap komponen perangkat lunak

(fungsi, arus data, penyimpanan data), hubungan antar komponen, struktur
perangkat lunak (dekomposisi menjadi modul-modul dan pengatarmukaannya).
Manajemen Proyek Perangkat Lunak Pusat Bahan Ajar dan eLearning

Tim Dosen http://www.mercubuana.ac.id
produk ini adalah sbb :
Fase ini menghasilkan arsitektur rinci, terutama dalam bentuk algoritma-
algoritma.
• Fase implementasi adalah terjemahan langsung arsitektur rinci ke dalam bahasa
pemrograman tertentu.
• Subfase uji integrasi melakukan pengujian terhadap semua modul dan
pengantarmukaan sehingga pada level sistem dapat beroperasi dengan benar
• Subfase uji penerimaan melakukan baerbagi pengujian mengacu kepada
berbagai persyaratan yang telah ditentukan.
• Kegiatan yang meliputi fase pemeliharaan adalah : peningkatan kemampuan,
adaptasi terhadap lingkungan pemrosesan, dan melakukan berbagai koreksi atas
kesalahan yang terjadi
• Penilaian kemajuan proyek akan lebih mudah jika pada model fase tersebut
ditetapkan beberapa tonggak penting ( milestone) yang pada setiap fase atau
antar setiap dua fase yang berurutan. Berikut ini Life cycle mode fase dari
sebuah perangkat lunak yang dilengkapi dengan kegiatan review dan tonggak
penting :

8 Tim Dosen
F. Model Biaya
Model biaya adalah cara pandang lain model fase sebuah perangkat lunak
dengan cara memperhatikan biaya berbagai kegiatan dalam proyek perangkat
lunak. Biaya proyek adalah jumlah biaya dari setiap fase proyek. Biaya setiap fase
mencakup biaya kegiatan dan penyiapan produk pada fase tersebut ditambah
dengan biaya verifikasi konsistensi produk suatu fase terhadap semua fase
sebelumnya.
Gambar 4.2 Model Biaya
Ada 2 sisi penting dari model biaya :
• Karena modl biaya hanyalah cara pandang lain dari model fase maka semua
dokumen yang dihasilkan tepat sama dengan yang dihasilkan pada model fase.
• Biaya verifikasi, apalagi perbaikan, atas suatu produk akan makin besar jika
produk tersebut dihasilkan oleh suatu fase yang jauh di belakang fase saat
verifikasi dilakukan.
G. Model Prototipe
Gambar 4.3 Model Prototipe
Beberap catatan tentang model prototipe :
• Sebuah prototipe adalah model dari sebuah produk perangkat lunak tetapi
dengan beberapa keterbatasan, misalnya : keterbatasan kemampuan, keandalan
yang rendah, dan kinerja yang tidak efisien.
• Alasan penggunaan model prorotipe adalah :
1. untuk menggambarkan format data masukan, pesan-pesan, laporan, dan dialog
interaktif
2. untuk mengeksplorasi isu-isu teknis dalam produk yang diusulkan
3. model fase ‘analisis → perancangan → implementasi’ tidak dapat digunakan
2. Perencanaan Struktur Organisasi
A. Struktur Pelaksana Proyek

Ada 3 format struktur pelaksana proyek : format proyek, format fungsional, dan formta
matriks
1. Format Proyek
• Dibentuk sebuah team yang melakukan pekerjaan proyek dari awal sampai
akhir
• Annggota team mendefinisikan produk, merancang produk,
mengimplementasikan, melakukan uji, melakukan review, dan
mempersiapkan dokumen-dokumen pendukung
• Sebagian anggota team melakukan instalasi dan pemeliharaan, dan
melanjutkan ke proyek baru
• Team proyek biasanya bekerja selama 1-3 tahun dan ditugaskan untuk
proyek berikutnya jika proyek pertama sudah selesai
2. Format Fungsional
• Dalam format ini dibentuk beberapa team untuk melaksanakan pekerjaan
proyek setiap fase. Semua team tidak dibentuk pada saat yang sama.
Anggota team dapat dirotasi.
• Team analisis dan perancangan bertugas untuk mengembangkan System
Definition (SD) dan Project Plan (PP).
• Team pendefinisian produk menerima produk SD dan PP, melakukan analisa
persya-ratan perangkat lunak, dan menyiapkan Software Requirement
Specification (SRS).
• Team perancangan merancang produk yang sesuai dengan SRS dan SD.
• Team implementasi mengimplementasi, debugging, dan melakukan uji per unit
sistem
• Team uji sistem melakukan uji integrasi
• Team kualitas melakukan sertifikasi terhadap semua produk kerja
• Team pemelihara melakukan pemeliharaan produk
3. Format matriks
• Setiap gugus fungsional memiliki team manajemen dan kelompok spsialis
yang hanya melaksanakan fungsinya sendiri.
Gambar 4.4 Struktur Organisasi

12 Tim Dosen
B. Struktur Tim Pemrograman
1 Demokrasi
Gambar 4.5 Struktur Organisasi – Demokrasi

• Berbagai keputusan dilakukan melalui kesepakatan kelompok
• Kepemimpinan berotasi sesuai dengan jenis pekerjaan yang sedang
dilaksanakan dan spesialisasi anggota
2 Kepemimpinan
Gambar 4.6 Struktur Organisasi – Kepemimpinan

• Pimpinan merancang produk, mengimplementasikan bagian kritis dari produk,
dan membuat semua keputusan teknis utama
• Programer menuliskan source code, debugging, dokumentasi, dan uji unit

• Pustakawan mengurus listing program, merancang dokment-dokumen, membuat
rencana uji
• Back-up programmer berperan sebagai konsultan bagi pimpinan untuk berbagai
masalah teknis, memelihara hubungan dengan pelanggan dan kelompok
publikasi serta kelompok jaminan kualitas, dan melakukan sejumlah analisis-
perancangan-implementasi di bawah pengawasan pimpinan.
Referensi
1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill
2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley

14 Tim Dosen Pusat Bahan Ajar dan eLearning
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Estimasi Biaya
05
Komputer
Abstract Kompetensi
perencanaan biaya dalam sebuah untuk menganalisis dan menetapkan
proyek biaya dari sebuah proyek yang akan
dijalankan
1. Manajemen Biaya Proyek
1. Pengertian Manajemen Biaya Proyek
Manajemen biaya proyek merupakan salah satu dari 9 area pengetahuan dalam
manajemen proyek. Manajemen biaya proyek diperlukan untuk memastikan bahwa
perencanaan proyek sudah mencakup :
1. Estimasi biaya untuk setiap resource
2. Pengalokasian estimasi biaya setiap resource yang dibutuhkan oleh
setiap work item
Dalam manajemen biaya proyek, terdapat beberapa proses yang dilibatkan
dalam tujuan penyelesaian proyek sesuai dengan anggaran yang disediakan. Proses
tersebut yaitu estimasi, budgeting dan kontrol biaya.
Gambar 5.1 Overview Manajemen Biaya Proyek
Proses estimasi sangat menentukan kelangsungan proyek baik dari mulai tahap
desain, perencanaan, konstruksi, dan maintenance. Berbagai tipe dan cara dalam
mengestimasi biaya akan tergantung pada data/informasi yang tersedia, batas waktu,
dan tujuan dari estimasi tersebut. Peran estimator dalam estimasi biaya proyek
konstruksi dapat ditinjau dari ketelitian, pengalaman dan spesialisasi terhadap proyek
secara keseluruhan.
Untuk mendapatkan jawaban dari rumusan masalah pada bab 1, maka pada bab
ini akan diberikan dasar pemikiran ilmiah yang dilandasi dengan teori¬teori ilmiah yang
diperoleh dari area Manajemen Proyek, terutama dalam area pengetahuan Manajemen
Biaya Proyek.
Dalam landasan teori ini, terdapat 3 sumber utama yang akan dijadikan acuan
dalam pemecahan masalah yaitu :
1. Teori Manajemen Proyek dan lebih spesifik ke manajemen biaya di proyek,
sebagian besar akan diambil dari literatur Manajemen Proyek seperti PMBoK,
dan sumber lainnya yang memberikan teori tentang Manajemen Proyek.
2. Teori Manajemen Biaya Proyek, khususnya yang membahas tentang proses
estimasi biaya proyek, kinerja biaya proyek serta kegiatan-kegiatan yang
termasuk di dalamnya maupun yang memberikan pengaruh terhadap kedua hal
tersebut di atas. Teori ini diperoleh dari berbagai jurnal ilmiah baik nasional
maupun internasional, serta beberapa buku yang membahas tentang estimasi
biaya dan kinerja biaya proyek.
3. Aplikasi pengembangan manajemen biaya proyek khususnya dalam masalah
estimasi dalam sebuah perusahaan konstruksi yang telah memiliki dan
menerapkan sistem estimasi secara lebih akurat dengan data/informasi yang
diberikan, waktu serta tujuan estimasi. Hal ini bertujuan untuk menjadi bahan
pembanding dan masukan bagi penelitian ini.
2. Estimasi Biaya Proyek
1. Definisi
Terdapat beberapa literatur yang membahas mengenai pengertian estimasi

biaya. Dalam AACE International (2004), disebutkan bahwa estimasi merupakan
evaluasi dari keseluruhan elemen dari sebuah proyek atau usaha yang diberikan
berdasarkan kesepakatan terhadap suatu lingkup pekerjaan. Dysert, Larry R.
mengungkapkan bahwa estimasi biaya merupakan sebuah prediksi terhadap biaya yang
akan dibutuhkan dari sebuah proyek berdasarkan data dan lingkup proyek yang
diberikan yang akan dilaksanakan pada sebuah lokasi dan waktu yang telah ditetapkan.
Dalam sebuah estimasi biaya terdapat identifikasi dan pertimbangan dalam
memperkirakan beberapa alternatif biaya untuk memulai dan menyelesaikan proyek.
Jumlah biaya yang akan dikeluarkan dan risiko harus dapat dipertimbangkan, misalnya
seperti membuat keputusan untuk membeli suatu barang atau hanya menyewanya saja
untuk keperluan proyek, berbagi sumber daya dalam rangka mengoptimalkan biaya
dalam proyek. Biaya yang disusun akan memperhitungkan keseluruhan sumber daya
yang dibutuhkan dalam sebuah proyek, termasuk tenaga kerja, material, peralatan, jasa,
dan fasilitas dan beberapa kategori spesial seperti faktor inflasi atau biaya contingency.
Estimasi biaya merupakan penilaian kuantitatif yang mendekati untuk kebutuhan sumber
daya dalam proyek.
Tujuan dari dibuatnya suatu estimasi proyek adalah :
1. Sebagai dasar dalam pembuatan anggaran proyek
2. Sebagai alat untuk mengontrol biaya proyek
3. Untuk memonitor progress, dengan membandingkan anggaran biaya, biaya
estimasi dengan actual di lapangan.
4. Untuk membuat suatu database biaya yang dapat digunakan untuk estimasi-
estimasi berikutnya.
5. Estimasi biaya dan penjadwalan merupakan 2 aktifitas yang sangat berkaitan
erat.
2. Jenis Estimasi Biaya
Dilihat dari kelengkapan datanya dan terhadap tahapan proyek, maka estimasi
biaya dapat dibedakan menjadi 3 yaitu:
1. Preliminary Estimate
Merupakan estimasi biaya pada tahap perencanaan. Pada tahap ini, desain
proyek belum ada, hanya ada dalam bentuk gagasan. Estimasi biaya diberikan
untuk keperluan studi kelayakan. Estimasi dihitung secara kasar berdasarkan
informasi harga dari proyek sejenis per satuan kapasitas produksi atau per
satuan fungsinya atau per satuan luasnya.
2. Semi Detail Estimate

Estimasi ini ada pada tahap conceptual engineering. Estimasi biaya sudah dapat
dihitung secara detail karena basic design proyek sudah ada. Hasil estimasi
biaya pada tahap ini dapat dipergunakan sebagai dasar pertimbangan untuk
menyiapkan dana yang diperlukan bagi proyek tersebut, oleh karena itu sering
juga disebut sebagai budget estimate bagi owner.
3. Definitive Estimate
Estimasi ini ada pada tahap detailed engineering, dimana semua informasi yang
diperlukan untuk pelaksanaan sudah lengkap. Estimasi biaya sudah dapat
dihitung secara detail karena construction drawing sudah ada. Beberapa hal
dipertimbangkan dalam estimasi ini antara lain metode konstruksi, kondisi lokasi
proyek, preliminary work yang akan dilakukan, penggunaan sumber daya
tenaga, alat dan material serta subkontraktor sesuai spesifikasi yang ada serta
waktu pelaksanaan proyek.
3. Metode Estimasi Biaya
Setelah memperoleh data dan informasi yang lengkap mengenai suatu proyek,
maka proses estimasi akan dilanjutkan dengan pengolahan data tersebut. Terdapat
beberapa metode yang digunakan dalam pengolahan data untuk menyusun suatu
estimasi biaya yaitu:
1. Expert Judgment
Dari para ahli dapat diperoleh informasi historikal berdasarkan pengalaman mereka
terutama bagi proyek-proyek sejenis. Dari para ahli juga diperoleh pertimbangan
untuk menggabungkan beberapa metode dalam proses estimasi dan bagaimana
menyelaraskan perbedaan yang ada dalam metode tersebut.
2. Analogous Estimating
Menggunakan nilai dari sebuah parameter, seperti lingkup, biaya, anggaran dan
waktu maupun menggunakan skala perbandingan terhadap ukuran, kompleksitas
proyek sebelumnya yang dijadikan dasar untuk menyusun estimasi biaya proyek
yang serupa.
3. Parametric Estimating
Digunakan sebagai statistik dari hubungan antara data historikal dengan variabel
lainnya seperti luas area untuk menghitung estimasi beberapa parameter seperti
biaya, anggaran dan masa pelaksanaan.
4. Bottom-Up Estimating
Merupakan metode dalam mengestimasi komponen pekerjaan. Biaya dan akurasi
dari tipe ini dipengaruhi oleh ukuran dan kompleksitas dari aktiftas individual maupun
paket pekerjaan.
5. Three-Point Estimates
Keakuratan dalam sebuah estimasi dapat ditingkatkan dengan mempetimbangkan
aspek ketidaktentuan dan risiko. Dalam Program Evaluation and Review Technique
(PERT) digunakan 3 estimasi untuk memperkirakan biaya dari sebuah aktifitas,
yaitu:
1. Most Likely (CM), biaya aktifitas berdasarkan penilaian usaha yang realistik
terhadap suatu pekerjaan
2. Optimistic (CO), biaya aktifitas berdasarkan pertimbangan yang optimis
untuk aktifitas tersebut
3. Pessimistic (CP), biaya aktifitas berdasarkan pertimbangan pesimis
terhadap suatu aktifitas
Ketiga parameter diatas dirumuskan dalam bentuk sebagai berikut :
Untuk metode ini biasanya digunakan untuk perkiraan biaya yang mengandung
unsur ketidakpastian seperti estimasi biaya penelitian karena menggunakan
pertimbangan optimistik, pesimistik.
6. Reserve Analysis
Estimasi biaya yang termasuk biaya tak terduga. Biaya tak terduga tersebut dapat
berupa prosentase dari nilai estimasi, nilai yang tetap, atau dapat dikembangkan dari
metode analisa kuantitatif.
7. Cost of Quality
Menyangkut perhitungan seluruh biaya yang dipersiapkan untuk mencegah adanya
ketidakpuasan terhadap kualitas produk yang akan mengakibatkan rework.
8. Project Management Estimating Software

Beberapa program komputer dapat digunakan sebagai alat untuk membantu dalam
mengestimasi biaya.
9. Vendor Bid Analysis

Metode estimasi biaya, termasuk analisa biaya dari sebuah proyek yang
dimenangkan tanpa melalui proses persaingan karena memperoleh informasi dari
rekanan, tentunya akan diperlukan tambahan biaya.
4. Proses Estimasi Biaya
Proses estimasi biaya merupakan keseluruhan proses dalam estimasi dimulai

dari proses input data, teknik yang digunakan dalam pengolahan data serta output yang
dihasilkan dari sebuah estimasi. Diberikan pula diagram alur data estimasi biaya.
Gambar 5.2 Estimasi biaya: Input, Tools & Teknik, Output
Tahapan input dalam suatu proses estimasi mencakup beberapa hal yang
diperlukan untuk mendukung proses pelaksanaan estimasi seperti:
1. Scope Baseline
Menggambarkan pernyataan lingkup pekerjaan seperti deskripsi produk, kriteria
yang dapat diterima, hasil yang diharapkan, batasan proyek dan asumsi. Dalam
scope baseline terdapat pula WBS yang menggambarkan hubungan dari semua
komponen dalam proyek.
2. Penjadwalan Proyek
Jenis dan jumlah dari sumber daya serta waktu yang dibutuhkan dalam rangka
peyelesaian proyek merupakan faktor yang penting dalam menentukan biaya
proyek.
3. Perencanaan Sumber Daya
Atribut staf proyek, biaya personel, dan bonus bagi karyawan merupakan komponen
yang penting dalam menyusun estimasi biaya.
4. Penyusunan Daftar Risiko

Identifikasi risiko diperlukan untuk pengendalian biaya akibat adanya risiko. Risiko
dapat memberikan dampak dalam aktifitas maupun biaya proyek.
5. Pertimbangan Faktor diluar Lingkungan Perusahaan

Faktor – faktor yang dapat mempengaruhi antara lain kondisi pasar dan informasi
komersial yang ada. Kondisi pasar yang dimaksud adalah ketersediaan produk, jasa
yang diperlukan dalam penyelesaian proyek dan yang dimaksud dengan informasi
komersil adalah database komersil yang memberika data tentang keahlian dan
upah dari sumber daya, serta biaya standard untuk material dan peralatan.
6. Kebijakan Organisasi
Kebijakan organisasi yang berpengaruh terhadap estimasi biaya adalah kebijakan
perusahaan dalam estimasi biaya itu sendiri, informasi historikal serta pelajaran
maupun pengalaman dari proyek sebelumnya.
Dibawah ini juga digambarkan proses penyusunan anggaran biaya sebelum

tahap pelaksanaan :
Gambar 5.3 Proses Penyusunan Anggaran Biaya
Adanya input dari Database Management System dalam penyusunan estimasi

akan sangat membantu terutama untuk proyek dengan skala besar dan sangat
kompleks. Dalam database ini mencakup seluruh aspek yang dibutuhkan berdasarkan
parameter dari proyek-proyek sebelumnya maupun data baru baik itu mengenai harga,
lokasi, tenaga kerja dan lain sebagainya.
Seringkali diperlukan revisi harga sehubungan dengan budget yang disediakan
oleh owner. Oleh karena itu diperlukan revisi kembali harga satuan dan mengoreksi
quantity pekerjaan. Faktor-faktor yang perlu dipertimbangkan pada saat mengubah
harga satuan yaitu :
1. Melakukan construction economy yaitu upaya yang dilakukan dalam proses
pra konstruksi maupun masa konstruksi dengan tujuan menekan biaya
konstruksi termasuk juga untuk menekan kemungkinan terjadinya
pembengkakan biaya.
2. Mengubah construction method
3. Mengubah durasi proyek (bila memungkinkan)
4. Mengganti pemasok sumber daya yang digunakan
5. Mengubah kebijakan keuangan (pembiayaan)
I. Referensi:
1. Project Management Institute, (2008). A Guide to the Project Management Body of
Knowledge, 4th Edition, hal. 165.
2. Perrot, Melvin W., (2004). The Cost Estimator’s Dilemma, AACE International
Transactions, hal. 1.
3. Dysert, Larry R. (2006). Is “Estimate Accuracy” an Oxymoron?, Journal AACE
International Transactions, hal. 1.
4. Project Management Institute, (2008). A Guide to the Project Management Body of
Knowledge, 4th Edition, hal. 168.
5. Asiyanto MBA, IPM, (2005). Construction Project Cost Managament, (Pradnya
Paramita).
6. Jin Han, Kyeong, Park, Moonseo, Lee, Hyun-Soo, Ji, Sae-Hyun, (2008). Cost
Estimation Methodology Using Database Layer in Construction Projects, The 25th
International Symposium on Automation and Robotics in Construction.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Manajemen Resiko
06
Komputer
Abstract Kompetensi
bagaimana mengelola sebuah resiko untuk menganalisis dan mengelola
di dalam proyek perangkat lunak sebuah resiko di dalam proyek
perangkat lunak
1. Manajemen Resiko
1. Pendahuluan
Manajemen resiko adalah proses pengukuran atau penilaian resiko serta

pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah
memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif
resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen
resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal
(seperti bencana alam atau kebakaran, kematian serta tuntutan hukum).
Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu
perangkat lunak untuk memahami dan mengatur ketidak pastian. Pada saat kita
mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi
yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya
pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita
menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan
identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan
resiko tersebut.
Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko
berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga
yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak
terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini
dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik.
Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun tidak
sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas
tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis
pengembangan biasanya merupakan penyebabnya.
Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk
meminimalkan resiko atau paling tidak mendistribusikannya selama pengembangan
tersebut dan idealnya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang
kritis.
Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung
pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi
resiko dan alokasi staf dan sumber daya lainnya erat kaitannya.
Resiko dalam perangkat lunak memiliki dua karakteristik:
• Uncertainty : tidak ada resiko yang 100% pasti muncul.
• Loss : resiko berimbas pada kehilangan.
Dan resiko memiliki kategori:
1) Resiko Proyek
Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi
kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip dan
biaya menjadi bertambah. Resiko proyek mengidenifikasi :
- Biaya - Sumber daya
- Jadwal - Pelanggan
- Personil (staffing & organisasi) - Masalah persyaratan
2) Resiko Teknikal
Resiko teknis mengancam kualitas & ketepatan waktu PL yang akan
dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya
menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi :
- Desain potensial - Ambiquitas
- Implementasi - Spesifikasi
- Interfacing - Ketidakpastian teknik
- Verivikasi - Keusangan teknik
- Masalah pemeliharaan - Teknologi yang leading edge
3) Resiko Bisnis
Resiko bisnis mengancam viabilitas PL yang akan dibangun. Resiko bisnis
membahayakan proyek atau produk. 5 resiko bisnis utama :
a) Pembangunan produk atau sistem yang baik sebenarnya tidak pernah
diinginkan oleh setiap orang (resiko pasar)
b) Pembangunan sebuah produk yangg tidak sesuai dengan
keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
c) Pembangunan sebuah produk dimana sebuah bagian pemasaran
tidak tahu bagaimana harus menjualnya.
d) Kehilangan dukungan manajemen senior sehubungan dengan
perubahan pada fokus atau perubahan pada manusia (resiko
manajemen)
e) Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen
personal (resiko biaya).
4) Resiko yang sudah diketahui
adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hati-
hati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek
sedang dikembangkan, dan sumber informasi reliable lainnya.
seperti :
- Tanggal penyampaian yang tidak realitas
- Kurangnya persyaratan yang terdokumentasi - kurangnya ruang lingkup PL
- Lingkungan pengembangan yang buruk
5) Resiko yang dapat diramalkan
Merupakan diekstrapolasi dari pengalaman proyek sebelumnya.
Misalnya :
- Pergantian staf
- Komunikasi yang buruk dengan para pelanggan
- Mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung
dilayani
6) Resiko yang tidak diharapkan
Resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi
sebelumnya.
Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber2
daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang
sebenarnya / penting.
Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial
diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut
kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran
utama adalah menghindari resiko
2. Masalah-masalah Proses
1. Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan

yang menekankan pentingnya suatu proses standar untuk pengembangan
proses ?
2. Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai
proses PL yang akan digunakan pada proyek ini ?
3. Apakah anggota-anggota staf “ditugasi” ke proses PL pada saat PL
didokumentasi & bersedia menggunakannya ?
4. Apakah proses PL digunakan untuk proyek lain ?
5. Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian
serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ?
6. Apakah standar RPL yang diterbitkan disediakan untuk setiap pengembang PL
& manajer PL ?
7. Sudahkah dokumen outline & contoh-contoh dikembangkan untuk semua yang
ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses
PL ?
8. Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode
dilakukan secara reguler ?
9. Apakah kajian teknis formal terhadap prosedur pengujian & test case dilakukan
secara reguler ?
10. Apakah hasil dari masing-masing kajian teknis formal didokumentasikan,
termasuk kesalahan yang ditemukan & sumber daya yang digunakan ?
11. Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu
proyek sesuai dengan standar RPL ?
12. Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi
diantara system/persyaratan PL, desain, kode, dan test case ?
13. Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke
persyaratan pelanggan yang mempengaruhi PL ?
14. Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan
rencana pengembangan PL yang didokumentasikan untuk masing-masing
subkontrak ?
4
3. Masalah-masalah Teknis
1. Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi

diantara pelanggan & pengembang ?
2. Apakah metode spesifik digunakan untuk analisis PL ?
3. Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur ?
4. Apakah lebih dari 90% dari kode anda ditulis dengan bahasa orde yang lebih
tinggi ?
5. Apakah konvensi spesifik untuk dokumentasi kode didefinisikan & digunakan ?
6. Apakah anda menggunakan metode spesifik untuk desain test case?
7. Apakah digunakan peranti PL untuk mendukung perencanaan & aktivitas
penelusuran ?
8. Apakah digunakan peranti PL manajemen konfigurasi untuk mengontrol &
menelusuri aktivitas perubahan diseluruh proses PL ?
9. Apakah digunakan peranti PL untuk mendukung analisis PL dan desain proses ?
10. Apakah digunakan peranti untuk menciptakan prototipe PL ?
11. Apakah digunakan peranti PL untuk mendukung proses pengujian ?
12. Apakah peranti PL digunakan u ntukmendukung produksi dan manajemen
dokumentasi ?
13. Apakah metriks kualitas dikumpulkan bagi semua proyek PL ?
14. Apakah metrik produktivitas dikumpulkan bagi semua proyek PL?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah `tidak`, maka

proses PL lemah dan berisiko tinggi. Resiko berhubungan dengan kompleksitas
sistem yang akan dibangun dan `kebaruan` teknologi yang dikemas oleh sistem.
Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun :
• Apakah teknologi yang akan dibangun adalah hal yang baru untuk
organisasi anda?
• Apakah persyaratan pelanggan memerlukan kreasi algoritma baru
atau teknologi input atau output?
• Apakah PL berinterface dengan perangkat keras baru atau belum
terbukti?
• Apakah PL yang akan dibangun ber-interace dengan produk PL
yang dipasok oleh vendor yang belum terbukti?
• Apakah PL yang akan dibangun ber-interface dengan suatu sistem
database yang fungsi kinerjanya belum dibuktikan di dalam area
aplikasi ini?
• Apakan diperlukan interface pemakai khusus oleh persyaratan produk?
• Apakah persyaratan untuk produk memerlukan kreasi komponen
program yang tidak sama dengan yang dikembangkan terakhir oleh
organisasi anda?
• Apakah persyaratan memerlukan pemakaian analisis, desain atau
metode pengujian baru?
• Apakah persyaratan memerlukan metode pengembangan PL tidak
konvensional, seperti metode formal, pendekatan Al-based dan
jaringan syaraf buatan?
• Apakah persyaratan meletakkan batasan kinerja yang eksesif pada
produk tersebut?
• Apakah pelanggan tidak yakin pada fungsionalitas yang diminta
dapat ’dilakukan’?
Bila jawaban dari pertanyaan-pertanyaan di atas adalah ’ya’, penyelidikan lebih

lanjut harus dilakukan untuk memperkirakan risiko potensial.
4. Analisa Resiko Lingkungan Pengembangan
Resiko yang berhubungan dengan keberadaan dan kualitas peranti yang akan
digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek,
proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting.
Checklist item resiko yang berhubungan dengan lingkungan pengembangan :
• Apakah peranti manajemen proyek dapat diperoleh?
• Apakah peranti untuk analisis dan desain dapat diperoleh?
• Apakah peranti analisis dan desain penyampaian metode sesuai
bagi produk yang akan dibangun?
• Apakah kompiler atau generasi kode dapat diperoleh dan sesuai
untuk produk yang akan dibangun?
• Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk
yang akan dibangun?
• Apakah peranti manajemen konfigurasi PL dapat diperoleh?
• Apakah lingkungan menggunakan suatu database atau tempat
penyimpanan?
• Apakah semua peranti PL dapat diintegrasikan satu dengan lainnya?
• Sudahkah anggota tim proyek menerima pelatihan dengan masing-
masing peranti?
• Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan
mengenai peranti tersebut?
• Apakah bantuan dan dokumentasi on-line bagi peranti memadai?
Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti

lingkungan pengembangan PL lemah dan berisiko tinggi
5. Komponen Resiko dan Driver
Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu

menghendaki agar manajer proyek mengidentifikasi risiko driver yang mempengaruhi
komponen risiko PL – kinerja, biaya, dukungan dan jadwal. Komponen risiko
didefinisikan dengan cara sbb :
• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi
persyaratannya dan cocok dengan penggunaannya.
• Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga
• Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah
dikoreksi, disesuaikan dan ditingkatkan.
• Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga
dan produk akan disampaikan tepat waktu
Dua cara melakukan proyeksi risiko:
• Probabilitas di mana risiko adalah nyata
• Konsekuensi masalah yang berhubungan dengan risiko
Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4

aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang
dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan pengaruh risiko pada proyek dan produk
4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak
ada kesalahpahaman
6. Pengurangan dan Monitoring Resiko Perangkat Lunak
Aktifitas analisis risiko mempunyai titik tunggal yang memiliki tujuan untuk
membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko.
Strategi yang efektif harus:
1. Menghindari risiko
2. Memonitoring risiko
3. Manajemen risiko dan perencanaan kemungkinan
Langkah-langkah untuk mengurangi turnover staf adalah
1. Temui staf yang ada, untuk menentukan penyebab keluar
2. Bertindaklah untuk mengurangi penyebab-penyebab yang ada di bawah
kontrol manajemen sebelum proyek dimulai
3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-
teknik untuk memastikan kontiunitas pada saat orang keluar
4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas
pengembangan dapat disebarluaskan
5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa
dokumen dikembangkan tepat waktu
6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih
dari satu orang yang terbiasa dengan pekerjaan itu
7. Tentukan backup anggota staf untuk setiap teknologi kritis
Aktifitas pemonitoran dimulai, manajer proyek memonitor factor-faktor yang

dapat memberikan suatu indikasi apakah risiko mungkin sedang menjadi lebih
atau kurang.
Untuk kasus turnover tinggi, factor-faktor yang dapat dimonitor :
1. Sikap umum anggota tim berdasarkan tekanan proyek
2. Tingkat di mana tim disatu – padukan
3. Hubungan interpersonal di antara anggota tim
4. Masalah pontensial dengan kompensasi dan manfaat
5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya
Langkah pengurangan resiko diperlukan bagi definisi standar dokuntasi dan
mekanisme untuk memastikan bahwa dokumen dikembangkan secara tepat waktu,
guna memastikan kontinuitas.Manajemen risiko dan perencanaan kemungkinan
mengasumsikan bahwa usaha pengurangan telah gagal dan risiko menjadi suatu
kenyataan.
Contoh, diandaikan proyek sedang berlangsung dengan baik dan sejumlah
orang mengatakan akan keluar dari proyek tersebut maka strategi pengurangan telah
dilakukan dengan backup , informasi, dokumentasi dan pengetahuan telah disebar ke
semua tim. Manajer proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yang
telah disusun sepenuhnya dan pendatang baru akan ditambah untuk mengejar dan
membagun serta akan ditransfer pengetahuan oleh orang akan keluar.
I. Referensi:
1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997.
2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004.
3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,
2006.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Inisiasi Proyek dan Ruang

Lingkup Manajemen
07
Komputer
Abstract Kompetensi
Modul ini berisi materi tentang Pada akhir pertemuan ini,
penaksiran proyek, elemen- diharapkan mahasiswa memahami
elemen dasar proyek, aspek elemen-elemen dasar proyek, cara
awal, dan proposal awal dan melakukan penaksiran proyek,
pendekatan dalam penaksiran dan membuat proposal
1. Perencanaan, Penaksiran, dan Pengaturan Sumber
Daya Proyek
1. Penaksiran Proyek
Proses manajemen proyek perangkat lunak dimulai dengan serangkaian

aktivitas yang secara kolektif disebut perencanaan proyek. Aktivitas awal dari
perencanaan adalah estimasi. Kapanpun estimasi dilakukan, seorang perencana mulai
melihat pada masa depan dengan suatu tingkat ketidak pastian teretentu, yang akan
menjadi bahan pembahasan untuk menaksir proyek.
Hasil penaksiran akan menjadi dasar bagi semua aktiviotas perencanaan proyek
lebih jauh. Perencanaan proyek merupakan peta jalan bagi suksesnya rekayasa
perangkat lunak. Tanpa penaksiran yang teliti, perencanaan proyek akan menghasilkan
berbagai resiko dimasa depan, misalnya kerugian, kegagalan memenuhi limit waktu
yang sudah disepakati, dan kesulitan-kesulitan lain yang muncul dalam pengerjaan
teknis proyek.
Penaksiran berbagai hal untuk usaha pengembangan suatu perangkat lunak
membutuhkan:
• Pengalaman
• Akses informasi historis
• Keberanian mengkuantifisir data-data
Kualitatif Penaksiran yang dilakukan meliputi:
• Penaksiran kebutuhan sumber daya manusia
• Penaksiran kebutuhan biaya
• Penaksiran kebutuhan waktu dan penjadwalan
Penaksiran membawa resiko ketidak pastian. Ketidak pastian itu sendiri sangat
dipengaruhi oleh:
• Kompleksitas proyek
• Ukuran proyek
• Ketidakpastian structural
A. Kompleksitas Proyek
Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian dalam

perencanaan. Tetap kompleksitas pengukran yang relatif yang dipengaruhi oleh
kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.
Aplikasi real-time dapat dirasakan sebagai sangat kompleks bagi sebuah
kelompok perangkat lunak yang hanya mengembangkan aplikasiaplikasi batch
saja. Tetapi aplikasi yang sama dapat dirasakan sebagai run-of-mill bagi sebuah
kelompok perangkat lunak yang telah terlibat jauh dalam proses kontrol
kecepatan tinggi. Sejumlah pengukuran kompleksitas perangkat lunak kuantitatif
sudah diusulkan. Pengukuran semacam itu diaplikasikan pada tingkat kode dan
desain sehingga sulit digunakan selama perencanaan perangkat lunak (sebelum
kode dan desain ada). Tetapi perkiraan kompleksitas yang lain yang lebih
subyektif dibanding yang lain (seperti faktor penyesuaian kompleksitas function
point yang digambarkan) dapat dibuat pada awal proses perencanaan.
B. Ukuran Proyek
Ukuran proyek merupakan faktor penting lain yang dapat mempengaruhi

akurasi estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai
elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah
sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi
lebih sulit lagi karena elemen-elemen yang akan didekomposisi masih sangat
berat. Seperti dinyatakan dalam hukum Murphy: “Apa yang dapat salah
biarkanlah menjadi salah” – dan bila ada lebih banyak lagi yang dapat gagal,
maka disitu akan terjadi lebih banyak kegagalan.
C. Tingkat ketidakpastian Struktural
Tingkat ketidakpastian struktural juga berpengaruh dalam risiko estimasi.

Santayana pernah mengatakan, “Mereka yang tidak dapat mengingat masa lalu
terkutuk untuk mengulanginya lagi. “Dengan melihat kembali, kita dapat
mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat
dimana masalah muncul. Bila metrik perangkat lunak yang komprehensif dapat
diperoleh pada proyek yang telah lalu, maka estimasi dapat dilakukan dengan
kepastian yang lebih tinggi; jadwal dapat dibuat untuk menghindari kesulitan-
kesulitan yang terjadi dimasa lalu, dan risiko keseluruhan dapat dikurangi.
Resiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif
yang dibuat untuk sumber daya, biaya, dan jadwal. Bila ruang lingkup proyek
tidak dipahami dengan baik atau syarat proyek merupakan subjek terjadinya
perubahan, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana
perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface (yang
diisikan ke dalam spesifikasi sistem). Perencana, dan lebih penting lagi
pelanggan, harus mengetahui bahwa variabilitas pada kebutuhan perangkat
lunak berarti ketidakstabilan biaya dan jadwal.
Sebagai observasi akhir mengenai estimasi, kita perlu
mempertimbangkan apa yang pernah dikatakan oleh Aristoteles :Ini merupakan
tanda dari pikiran yang diperintah untuk menjadi puas dengan tingkat ketelitian
yang diijinkan oleh sifat dari sebuah subjek, dan tidak untuk mencari ketepatan
bila hanya perkiraan kebenaran saja yang dimungkinkan.
Manajer proyek tidak boleh obsesif terhadap penaksiran. Pendekatan-
pendekatan rekayasa perangkat lunak modern (seperti model proses
evolusioner) memakai pandangan pengembangan yang interaktif. Pada
pendekatan semacam ini dimungkinkan untuk melihat lagi penaksiran (bila lebih
banyak lagi informasi diketahui) dan merevisinya bila pelanggan mengubah
kebutuhannya.
2. Elemen Dasar dalam Penaksiran Proyek

Secara umum penakasiran proyek berimplikasi pada biaya. Sebagaimana sudah
diketahui bersama, proyek pengembangan perangkat lunak adalah sebuah jasa. Bahan
bakunya adalah waktu kerja setiap anggota timnya. Sehingga muara dalam penaksiran
proyek adalah membuat taksiran berapa lama waktu yang dibutuhkan tim untuk
menyelesaikan proyek tersebut. Dengan hitungan-hitungan sederhana, estimasi waktu
menjadi dasar dalam menghitung biaya proyek.Tentunya waktu keterlibatan setiap
anggota tim tidaklah sama. Akan sangat memboroskan kalau seorang anggota tim tetap
dialokasikan waktunya pada suatu tugas proyek, padahal dia belum dapat atau tidak lagi
mengerjakan apapun. Sehingga secara objektif harga sebuah proyek perangkat lunak
merupakan akumulasi dari biaya yang harus dibayarkan kepada setiap anggota tim
berdasarkan keterlibatannya.
Langkah-langkah Pendetilan
Untuk menghasilkan harga yang lebih teliti, langkah-langkah yang dapat dilakukan
adalah sebagai berikut :
1. Dekomposisi masalah
2. Definisikan secara detil task-task yang mesti ada pada setiap sub masalah
3. Definisikan anggota tim yang akan ditugaskan pada setiap task
4. Perkirakan waktu yang dibutuhkan oleh setiap anggota tim tersebut untuk
menyelesaikan suatu task
5. Tentukan tarif setiap anggota tim dalam pengerjaan proyek
6. Buat taksiran biaya lain-lain yang muncul, misalnya biaya akomodasi, biaya
atk, biaya peralatan, dan pembelian tools.
Kematangan setiap individu dalam tim akan mempengaruhi kebutuhan waktu

penyelesaian sebuah task yang ditugaskan kepadanya. Sehingga tim dengan
kematangan individu anggotanya yang rendah berdampak pada panjang kebutuhan
waktu. Disisi lain kematangan seorang individu juga mempengaruhi tarif yang ditetapkan
baginya.
3. Aspek Teknis
Pengkajian aspek teknis dilakukan sejajar dengan aspek-aspek lain setelah
penelitian pemasaran menunjukkan adanya faedah untuk melanjutkan studi kelayakan.
Maksud dan tujuan pengkajian aspek teknis adalah sebagai berikut:
• Pada tahap awal bertujuan untuk merumuskan gagasan yang timbul ke dalam
batasan yang konkret dari segi teknis.
• Hasil pengkajian aspek teknis dipakai sebagai masukan pengkajian aspek-
aspek lain.
• Akhirnya lingkungan aspek teknis sampai kepada kegiatan desain
engineering terinci, menghasilkan cetak biru (blue print) proyek yang

5 Ida Nurhaida, ST., MT.
akan dibangun.
Pengkajian aspek teknis itu sendiri mencakup beberapa hal antara lain sebagai
berikut:
• Menentukan letak geografis
• Mencari dan memilih teknologi proses produksi
• Menentukan kapasitas produksi
• Denah atau tatak letak industry
• Bangunan instalasi
Keputusan yang diambil dari pengkajian yang dilakukan diatas merupakan keputusan
penting. Setidaknya ada 3 alasan mengapa keputusan tersebut penting bati kelanjutan
proyek yaitu:
• Merupakan komitmen jangka panjang, yang bila tidak tepat sulit diperbaiki
• Berpengaruh besar terhadap biaya pembangunan proyek
• Mempunyai dampak permanen terhadap biaya operasi/produksi
4. Proposal Awal dan Pendekatan dalam

Penawaran
Proposal awal proyek merupakan upaya awal tim proyek untuk menggolkan
sebuah proyek. Proposal awal mestinya berpijak pada suatu memo kesepahaman
antara pemilik proyek yang meliputi:
• Pendefinisian masalah
• Rekomendasi penyelesaian
• Gambaran umum sistem perangkat lunak
• Keuntungan-keuntungan yang didapatkan dengan implementasi sistem
perangkat lunak
1. Perencanaan Proyek
Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan
sebuah kerangka kerja yang memungkin kan seorang pimpinan proyek membuat
estimasi yang dapat dipertanggung jawabkan mengenai sumber daya, biaya dan
jadwal. Batasan dalam estimasi adalah:
• Waktu terbatas
• Sumber daya terbatas
Estimasi dalam proyek perangkat lunak memiliki ketidak pastian yang
cukup tinggi. Sehinga selagi proyek berjalan, estimasi mesti selalu disesuaikan
dan diperbaharui. Lebih khas lagi, estimasi biasanya membentuk suatu skenario
kasus terburuk dan kasus terbaik.
Proses perencanaan dapat dicapai melalui suatu proses penemuan
informasi yang menunjuk ke estimasi yang dapat dipertanggung jawabkan.
Tugas-tugas yang mesti ditangani oleh seorang perencana proyek sistem
perangkat lunak adalah:
• Mendefinisikan ruang lingkup system
• Mengidentifikasi kebutuhan-kebutuhan dalam pelaksanaan proyek
• Mengestimasi sumber daya yang diperlukan
2. Ruang Lingkup
Ruang lingkup merupakan pendeskripsi teknis proyek dalam suatu
statement yang dapat dimengerti pada tingkat manajemen dan teknis. Ruang
lingkup perangkat lunak menggambarkan:
• Fungsi
• Kinerja,
• Batasan
• Interface
• Keandalan
Fungsi-fungsi yang digambarkan dalam statement ruang lingkup
dievaluasi, untuk mendapatkan suatu model yang detil maka fungsi-fungsi
proses tersebut akan didekomposisi menjadi sub-sub fungsi yang pada akhirnya
akan memudahkan dalam estimasi jadwal dan biaya yang diorientasikan secara
fungsional.
Contoh :
Sebuah sistem perangkat lunak admisnitrasi akademik, akan menghasilkan
fungsi-fungsi sebagai berikut:
• Preparasi data mahasiswa
• Preparasi data kurikulum
• Pengisian KRS
• Menentukan kelas
• Mengoptimalkan jadwal
• Mengisi nilai
Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu

respon. Untuk contoh sistem informasi akademik diatas, kinerja akan
ditentukan oleh pengaturan jadwal suatu pemrosesan. Misalnya, perubahan
kurikulum harus sudah dilakukan sebelum pengisian KRS. Ketika ingin
diwujudkan suatu sistem yang online dan dapat diakses oleh seluruh
mahasiswa, masalah kemanan data menjadi ukuran kinerja sistem. Perangkat
lunak yang dikembangkan akan dibatasi oleh perangkat keras yang
diaksesnya.
Disamping informasi teknis yang didefinisikan dalam dokumen
kebutuhan pelanggan (customer request), diperlukan informasi-informasi lain
yang untuk mendefiniskan ruang lingkup antar lain:
1. Deskripsi pelanggan (yang meminta)

2. Pemakai
3. Karakteristik output yang baik menurut pemakai
4. Solusi yang akan diambil
3. Kebutuhan
Yang dimaksudkan sebagai kebutuhan dalam hal ini adalah segala
sesuatu yang diperlukan untuk mendukung proyek perangkat lunak. Kebutuhan
dapat dikelompokkan atas:
1. Literatur
2. Pelatihan khusus sumber daya
3. Fasilitas lain-lain
Dalam perencanaan proyek perangkat lunak, harus teridentifikasi dari
awal kebutuhankebutuhan yang diperlukan sehingga proyek dapat berjalan
sesuai dengan yang direncanakan.
4. Sumber Daya
Tugas selanjutnya seorang perencana proyek perangkat lunak adalah
mengestimasi kebutuhan sumber daya untuk pengembangan perangkat lunak,
yaitu:
1. Perangkat keras
2. Perangkat lunak (utilitas)
3. Lingkungan
4. Manusia
5. Estimasi Proyek
Estimasi proyek perangkat lunak meliputi:
1. Estimasi biaya
2. Estimasi waktu
Berikut adalah model sederhana penaksiran proyek:
No Dekomposisi Kualifikasi Rate Man Scheduling Waktu Biaya
Konsultan Days Nyata
1. Sub Masalah 1
1.1. Task 1
1.1.1 Sub task 1
1.1.1.1. Sub sub task 1 Proyek Manajer $ 100 5 $ 500
1.1.1.2. Sub sub task 2 Sistem Analis 1 $ 80 12 $ 960
1.1.1.3. Sub sub task 3 Programmer 1 $ 60 6 $ 360
1.1.2. Sub task 2
Sub sub task 1 Sistem Analis 1 $ 80 20 $ 1.600
Sub sub task 2 Sistem Analis 2 $ 80 20 $ 1.600
dst
Total $ xxxxxx
Pada umumnya perusahan memiliki batasan jumlah dana yang akan
diinvestasikan pada suatu proyek. Hal ini berarti tidak semua proyek yang
diajukan akan dijalankan. Beberapa proyek memiliki prioritas yang lebih tinggi
dibandingkan dengan yang lain. Sebagai contoh, proyek yang terkait dengan
pemerintahan akan memiliki prioritas yang lebih tinggi dibadingkan dengan
proyek-proyek yang lain.
Pemilihan proyek dapat dilakukan dengan dua cara sebagai berikut:
• Constrained optimization
• Benefit Comparison Methods
Umumnya organisasi menggunakan pendekatan ini. Benefit comparison
methods menggunakan accessible formulas, model perbandingan, and sistem
untuk menentukan proyek yang akan dikerjakan.
I. Referensi:
1. Software Engineering, Roger S. Pressman,McGrawHill 1997.
2. Management Information System, Raymond McLeod, Prentice Hall 2000.
3. Software Project Management for Dummies, Teresa Luckey, Joseph Phillips,
Wiley Publishing Inc., 2006.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Critical Success Factor
09
Komputer
Abstract Kompetensi
Modul ini berisi materi tentang Pada akhir pertemuan ini,
bagaimana penerapan critical diharapkan mahasiswa memahami
success factor pada sebuah penerapan critical success factor
manajemen proyek perangkat pada sebuah manajemen proyek
lunak perangkat lunak
1 Hendra Prastiawan, S.Si., M.T http://www.mercubuana.ac.id
1. Critical Success Factor
1. Pengertian Critical Success Factor
Critical Success Factor (CSF) adalah istilah untuk suatu elemen yang
diperlukan untuk suatu organisasi atau proyek untuk mencapai misinya. Ini adalah
faktor kritis atau aktivitas yang diperlukan untuk menjamin keberhasilan sebuah
perusahaan atau organisasi. Critical Success factor menurut Maciariello & Kirby
(1991:78) [14] adalah sebagai berikut:.
" The Importance of Identifying those relatively few variables that are crucial to
the attainment of strategy, goals, objectives then is ultimately derived from limited
information processing ability of the manager. We call these crucial variables Critical
variable or Critical Success factor". Selain ini Critical Success Factors disimpulkan juga
sebagai: "Critical Success Factors are thosevariables that are at least partially out of the
control of management to those values the strategy, goals,and objectives organization
are most sensitif".
Konsep "faktor keberhasilan" dikembangkan oleh D. Ronald Daniel dari
McKinsey & Company pada tahun 1961 Proses ini disempurnakan oleh John F. Rockart
pada tahun 1981. Pada 1995, James A. Johnson dan Michael Friesen diterapkan untuk
pengaturan berbagai sektor, termasuk Engineering.
2. Identifikasi Critical Success Factor
Dalam mengidentifikasi Critical Success Factors, ada 2 tipe dari Critical

Successs factor,yaitu:
1. Faktor interal, dimana faktor-faktor yang ada tersebut berada dalam kemampuan
manajemen dan usaha seperti harga, 'mantas, dan biaya
2. Faktor eksternal, dimana faktor-faktor tersebut berada diluar kemampuan dari
perusahaan untuk mengontrolnya. Seperti peraturan pemerintah dan tindakan
para pesaing di dalam menetukan harga, perilaku konsumen, kinerja pengawas,
dan lain-lain.
3. Kriteria Critical Success Factor
Sukses adalah suatu kata yang umum dan luas sehingga sulit untuk
mendefinisikannya dan mendapatkan kesepakatan ketika ditanyakan kepada individu
yang berbeda. Pernyataan tersebut diutarakan karena usaha mendefinisikan sukses
adalah seperti mendapatkan konsensus dan sekelompok orang akan definisi "seni yang
indah'. Begitu juga pada proyek, 'criteria kesuksesan proyek tidaklah sama setiap
proyek, karena target masing-masing proyek berbeda-beda. Pendefinisian kesuksesan
Proyek secara umum adalah penyelesaian proyek tanpa melewati batasan waktu, biaya,
dan kinerja. Akan tetapi saat ini,definsi kesuksesan proyek sudah berubah menjadi
penyelesaian pekerjaan:
• Dalam periode waktu yang sudah dialokasikan
• Dalam biaya yang sudah direncanakan
• Pada tingkat kinerja dan spesifikasi yang memadai
• Diterima oleh customer / user
• Bila nama pelanggan bisa digunakan sebagai referensi
• Dengan perubahan scope yang minimum dan disepakati
• Tanpa mengganggu aliran pekerjaan utama dari organisasi
• Tanpa mengganggu budaya perusahaan
Pandangan akan kesuksesan memang cenderung mengalami perubahan

hingga saat ini dan juga sudah berkembang dan tahun ke tahun dari definisi
sederhana yang dibatasi pada fase implementasi dan project life cycle menjadi definisi
yang merefleksikan apresiasi kesuksesan dan keseluruhan project and product life
cycle.
Penelitian lain yang dilakukan oleh Atkinson (1999) [20]. Menyatakan penilaian
sukses dibagi menjadi 2 kategori yaitu:
• Pengukuran kesuksesan selama implementasi proyek ("doing it right") seperti
pada aspek biaya, waktu, dan mutu.
• Kriteria sukses mengikuti pelaksanaan proyek ("getting it right"), dimana
termasuk pengaruh pada outcome bisnis pelanggan yang dihasilkan dari
proyek, dan bagaimana proyek itu mempersiapkan organisasi untuk masa
depan.
Sejalan dengan pendapat Atkinson diatas, penelitian lain oleh Shenhar et al.
(2001) [21], mengidentifikasi 4 dimensi kesuksesan yaitu:
• Efisiensi proyek
• Pengaruh pada pelanggan
• Kesuksesan bisnis secara langsung dan organisasional
• Mempersiapkan masa depan
Sedangkan Shatz (2006) [22] memaparkan tools yang dinamakan "slider" dalam
determinasi kesuksesan proyek, yaitu:
• Slider 1 : Level kepuasan Stakeholder
• Slider 2 : Sesuai dengan tujuan dan persyaratan
• Slider 3 : Sesuai Budget
• Slider 4 : Sesuai Deadline
• Slider 5 : Pesyaratan Added – Value
• Slider 6 : Persyaratan Kualitas
• Slider 7 : Kepuasan Tim
Songer dan Molenaar (1997) [23], menjabarkan 'criteria sukses dan suatu proyek
beserta definisinya seperti tercantum dalam tabel dibawah ini
Tabel 9.1 Kriteria Sukses dan Definisinya
Kriteria Sukses Definisi

Proyek disesuaikan pada atau didalam biaya
Sesuai Budget L er i ii yang di-kontrak-an
Sesuai Jadwal Proyek diselesaikan pada atau sebelum
jadwal yang di-kontrak-an
Sesuai Spesifikasi Proyek yang diselesaikan sesuai atau melebihi
semua spesifikasi teknis yang disediakan
sesuai dengan owner yang diselesaikan sesuai atau
Proyek
keinginan user melebihi tujuan fungsional yang diinginkan
tingkat kemampuan staff oleh user
Proyek yang diselesaikan sesuai atau melebihi
pekerja yang standar tingkat kemampuan pekerja yang
berkualitas tinggi dapat diterima pada semua area
meminimalisasi proses konstruksi terjadi perselisihan
ketidakpuasan konstruksi dengan staff manajemen proyek owner
.
Pada penelitian Thomas, Tucker, dan Kelly (1998) [24], mengutip dari
penelitian oleh Ashley et al. (1987) [25], menyatakan bahwa kesuksesan diukur oleh
biaya, jadwal, kualitas, keamanan, dan kepuasan partsipan. Akan tetapi walapun
mudah untuk diukur, tetapi pada aspek kepuasan dan kualitas dinilai cuk up subjektif.
Kemudian pada penelitian lebih lanjut oleh Thamhain (1992) [26], menyatakan bahwa
lebih dari 60% manajer Engineering yang disurvey setuju bahwa 3 karakteristik yang
paling banyak digunakan dalam penilaian kesuksesan proyek mencakup:
• Kesuksesan proyek secara teknis
• Kinerja tepat waktu
• Kinerja on-budget
Westerveld (2002) [27], dalam penelitiannya mencoba menghubungkan 'criteria

kesuksesan proyek sebagai result area dengan Critical Successs Factor (CSF) sebagai
organisational area, sehingga memperlihatkan kedua area tersebut merupakan 2 hal
yang saling berkaitan satu dengan lainnya.
Critical Successs Factor (CSF) merupakan suatu istilah dalam dunia bisnis untuk
suatu elemen yang penting bagi suatu perusahaan atau proyek untuk mencapai misi
tujuannya. Faktor-faktor tersebut diperlukan untuk memastikan kesuksesan bisnis
tersebut. Jadi CSF merupakan suatu hal yang vital. Berikut ini beberapa definisi dari
CSF yang pernah diutarakan oleh peneliti terdahulu:
• Faktor-faktor yang terbatas, yang bila dipenuhi secara baik, akan menjamin
suksesnya kinerja persaingan (competitive performance) dari suatu organisasi.
Faktor-faktor tersebut adalah sedikit area dimana segala sesuatunya hams
berjalan dengan benar bagi berjalannya bisnis. Jika usaha pada area ini tidak
cukup, maka hasil organisasi untuk periode tersebut akan lebih sedikit dari yang
diharapkan (Rockart, 1979) [28]. Rockart juga menyimpulkan bahwa CSF adalah
area aktivitas yang hams menerima perhatian khusus dan konstan dari
management.
• Beberapa hal/ faktor yang hams berjalan baik untuk menjamin sukses bagi
manajer atau organisasi dan karenanya, faktor-faktor tersebut menjelaskan
bidang-bidang dalam manajerial atau perusahaan yang hams diberi perhatian
khusus dan terns menerus untuk mendapatkan hasil yang berkualitas tinggi.
• Kejadian (events) atau keadaan (circumstances) yang membutuhkan perhatian
khusus dan manajemen karena pengaruhnya yang penting terhadap
perusahaan/organisasi. Dapat bersifat internal atau eksternal dan pengaruhnya
dapat positif maupun negatif (Ferguson and Dickinson, 1982) [30]
• Item yang hams dimiliki dan dibutuhkan oleh proyek untuk mencapai tujuan.
Drickhammer (2006) [32] mengutarakan bahwa pengidentifikasian CSF

merupakan salah satu proses perencanaan yang penting dalam pencapaian tujuan
proyek dimana berada di dalam constraints waktu, biaya, dan kualitas (Wiley,2004) [33].
Kuen, Zallani dan Fernando ( 2009) [34] sebagaimana mengutip dari Mobey dan Parker
(2002) [35], menyatakan bahwa dalam usaha peningkatan peluang keberhasilan suatu
proyek, adalah penting bagi organisasi untuk memiliki pemahaman dan apa itu CSF,
untuk menilai secara sistematis dan kuantitatif CSF tersebut mengantisipasi efek-efek
yang mungkin terjadi,dan kemudian memilih metode dalam menghadapinya. Dengan
demikian, melalui identifikasi CSF, keberhasilan proyek diharapkan dapat tercapai.
Mereka juga membuat suatu ringkasan akan CSF yang telah diidentifikasikan
oleh peneliti terdahulu. Ringkasan tersebut dituangkan dalam bentuk tabel seperti yang
terlihat pada tabel dibawah ini.
Tabel 9.2 Summary dari Literatur Review Akan CSF
Pinto & Belassi Coole-

Pimo Kerzner Slevin & Wateridge Belout Clarke Daview Muller
Success Factors from the
1996 1987 1989 Tukel 1995 1998 1999 2002 2005
Literature
1996
Corposite Understanding X X X
Common Understanding with
stakeholders on Success criteria X
Executive Commitment X X X X
Organizational adaptability X
Communication X X X
Project manager selection criteria X X X X X
project manager leadership /
empowerment X X X X X
Environment X
Pinto & Belassi Coole-
Pimo Kerzner & Wateridge Belout Clarke Daview Muller
Success Factors from the Slevin
1996 1987 1989 Tukel 1995 1998 1999 2002 2005
Literature
1996
Commitment to planning & control X X X X X
Project mission / common goal /
direction X X X X
top management support X X X
client consultation / acceptance X X X
monitor performance and feedback X X X X
personnel / teamwork X X X X X X X
Technical task ability X X X
Trouble shooting / risk management X X X
Project Ownership X X
Urgency of Project X X
Duration and size of Project X X X
Remarks : X Success factor(s) that is determined by the researcher either on a conceptual or empirical basis
Pada tabel 9.3, memperlihatkan perkembangan CSF untuk proyek yang

telah diringkas oleh Tom, Austeng, Mengesha (2004) [36], dimana CSF berkembang
dari pendekatan mekanistik pada determinasi proyek yang bergantung pada sistem
teknis murni menjadi kombinasi antara sistem sosial dan teknis
No Critical Success Factor Source, year

1 Technical Performance Ruben & Seeling, 1967
2 Project manager eksperience Ruben & Seeling, 1967
3 Project manager competence Sayles & Chandler, 1971
4 Schedulling Sayles & Chandler, 1971
5 Control system and responsibilities Sayles & Chandler, 1971
6 Monitoring & feed back Sayles & Chandler, 1971
7 Continous involment in the project Sayles & Chandler, 1971
8 Clear Goals Martin, 1976
9 General management support Martin, 1976
10 organize and delegate authorithy Martin, 1976
11 Clear Goals Baker, Murphy, and Fisher, 1983
12 Goal commitment of project team Baker, Murphy, and Fisher, 1983
13 adequate project team capability Baker, Murphy, and Fisher, 1983
14 Planning & control techniques Baker, Murphy, and Fisher, 1983
15 Task-Social orientation absence of Baker, Murphy, and Fisher, 1983
16 bureucracy
Project summary Clealand King, 1983
17 Top Management Support Clealand King, 1983
18 Financial Support Clealand King, 1983
19 facility support Clealand King, 1983
20 market intelligent Clealand King, 1983
21 schedule Clealand King, 1983
22 manpower and organisation Clealand King, 1983
23 acquisition Clealand King, 1983
24 information and communication channels Clealand King, 1983
25 Project Objectives Morris and Hughes, 1987
26 Technical Innovation Uncertainty Morris and Hughes, 1987
27 Politics Morris and Hughes, 1987
28 Vommunity Involvement Morris and Hughes, 1987
29 Schedule duration urgency Morris and Hughes, 1987
30 Implementation problem Morris and Hughes, 1987
31 Project Objectives Pinto and Slevin, 1987
32 Top Management support Pinto and Slevin, 1987
33 Project planning Pinto and Slevin, 1987
34 Communication with client Pinto and Slevin, 1987
35 Human relations Pinto and Slevin, 1987
36 Technical task Pinto and Slevin, 1987
37 Client Acceptence Pinto and Slevin, 1987
38 Project Control Pinto and Slevin, 1987
39 Communication and problem handling Pinto and Slevin, 1987
40 Top management support Tuke & Rom, 1995
41 Client consultation Tuke & Rom, 1995
42 Availability of resources Tuke & Rom, 1995
43 Project manager performance Tuke & Rom, 1995
44 The project manager and team members Walid and Oya, 1996
45 The organization Walid and Oya, 1996
46 Early and continual client consultation Pinto and Kharbanda, 1995
47 Technology Pinto and Kharbanda, 1995
48 Schedulling system Pinto and Kharbanda, 1995
49 Project team Pinto and Kharbanda, 1995
50 Top management support and continual " Pinto and Kharbanda, 1995
what if " approach
Berdasarkan pada perkembangan CSF pada tabel 2.3 tersebut,

sebagaimana mengutip dari Belout (1998) [37], terlihat bahwa pada awalnya
terdapat dominasi dari sistem teknis dan hanya sedikit indikasi dari pertimbangan
akan sistem tingkah laku (behavioral system). Saat ini manajemen proyek telah
banyak berkembang dan pengembangan teoritis telah mengarah pada prinsip-
prinsip organisasi dan tingkah laku (behaviour).
Naoum, Fong, dan Walker (2004) [38], dalam penelitiannya dalam
mengidentifikasi CSF yang berkontribusi pada keberhasilan suatu manajemen
proyek, menemukan bahwa terdapat 10 CSF, yaitu:
1. Pembentukan tujuan proyek dan 'criteria klien
2. Tingkat partisipasi tim proyek dalam decision making
3. Kejelasan scope dan definisi pekerjaan
4. Karakteristik manajer proyek
5. Organisasi klien
6. Kerjasama tim proyek
7. Teknik perencanaan dan programming
8. Proses seleksi dalam pembentukan tim
9. Kewenangan dan pengaruh manajer proyek
10. Estimasi biaya proyek
Penelitian atas CSF memiliki manfaat yang sangat signifikan terutama dalam
bidang konstruksi dan Manajemen Proyek, diantaranya adalah (Permono, 2010):
1. Untuk meminimalisir variasi yang banyak sepanjang implementasi proyek.
2. Untuk mengantisipasi efek-efek yang mungkin terjadi, kemudian memilih
metode y ang dapat diterapkan untuk mengatasinya
3. Dapat memprediksi kesuksesan proyek, yang disertai dengan
tindakan¬tindakan: menolak proyek yang berpotesi tidak sukses,
mengidentifkasi proyek yang layak untuk dikerjakan, mengidentifikasi
masalah pada proyek yang sedang berjalan dan mengambil tindakan
koreksi
4. Lebih memungkinkan pencapaian kepuasan client, mempertahankan
reputasi, dan mendapatkan kontrak tambahan dalam kompetisi yang terus
meningkat
I. Referensi:
1. Maciariello, J. A., & Kirby, C. J. (1994). Management Control Systems: Using
Adaptive Systems to Attain Control. Upper Saddle River, NJ: Prentice Hall.
2. Johnson, James A. and Michael Friesen (1995). The Success Paradigm:
Creating Organizational Effectiveness Through Quality and Strategy New York:
Quorum Book.
3. Judgev, K. & Muller, R. 2005, "A Retrospective Look at Our Evolving
Understanding of Project Success", Project Management Journal.
4. Kerzner, 2001, Strategic planning for project management using a project
management maturity model, Wiley & Sons, New York, page 158.
5. Judgev, K. & Muller, R. 2005, "A Retrospective Look at Our Evolving
Understanding of Project Success", Project Management Journal.
6. Shenhar, Aaron J, and R. Max Wideman (2002) Matcing project
Management Style with project type for optimum success PM Forum website
7. Songer, A.D. dan Molenaar, K.R. (1997), Project Characteristics for
Successful Public-sector Design-Build, J. Constr. Eng. Manage.
8. Ashley, D.B., Lurie, C.S. dan Jaselskis, E.J. (1987), Determinants of
Construction Projects Success, Proj. Mgmt. J., 18(2), 69-77
9. Thamhain (2004) Team Leadership effectiveness in technology based
project environment. Project environment journal.
10. Rockart, John F. 1986 "A Primer on Critical Success Factors" published in
The Rise of Managerial Computing: The Best of the Center for Information
Systems Research, edited with Christine V. Bullen. (Homewood, IL: Dow
Jones-Irwin), 1981, OR, McGraw-Hill School Education Group.
11. Boynlon, A.C., and Zmud, R.W. 1984. "An Assessment of Critical Success
Factors," Sloan Management Review (25:4), pp. 17-27.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Jaminan Kualitas Perangkat

Lunak
10
Komputer
Abstract Kompetensi
Jaminan kualitas perangkat lunak Mahasiswa mengenal, memahami
adalah aktivitas pelindung yang dan mampu menjamin kualitas
diaplikasikan pada seluruh proses perangkat lunak yang dihasilkan.
perangkat lunak
1. Pengantar
1. Pendahuluan
Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan

pada seluruh proses perangkat lunak.
Jaminan kualitas perangkat lunak atau software quality assurance meliputi:
1. Pendekatan manajemen kualitas.
2. Teknologi rekayasa perangkat lunak yang efektif (metode dan peranti).
3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses
perangkat lunak.
4. Strategi pengujian multitiered (deret bertingkat).
5. Kontrol dokumentasi perangkat lunak dan perubahan.
6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan
perangkat lunak.
7. Mekanisme pengukuran dan pelaporan.
2. Kontrol kualitas
Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian

yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa
setiap produk memenuhi persyaratan yang ditetapkan.
Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki
spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat
membandingkan output dari setiap proses. Kalang (loop) menjadi penting untuk
meminimalkan cacat yang dihasilkan.
3. Kontrol kualitas
Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.

Tujuan jaminan kualitas adalah untuk memberikan data yang diperlukan oleh
manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat
memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran.
4. Biaya kualitas
Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar

kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi
tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas
yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya
kualitas serta memberikan basis perbandingan yang ternormalisasi.
Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan:
a) Pencegahan
Biaya pencegahan meliputi:
1) Perencanaan
2) Kajian teknis formal
3) Perlengkapan pengujian
4) Pelatihan
b) Penilaian
Biaya penilaian meliputi:
1) Inspeksi in-proses dan interproses
2) Pemeliharaan dan kalibrasi peralatan
3) Pengujian
c) Kegagalan
Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang
muncul sebelum produk disampaikan kepada pelanggan.
1) Biaya kegagalan internal
Biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk
sebelum produk dipasarkan. Biaya kegagalan internal meliputi:
• Pengerjaan kembali
• Perbaikan
• Analisis mode kegagalan
2) Biaya kegagalan eksternal
Biaya yang berhubungan dengan cacat yang ditemukan setelah
produk disampaikan kepada pelanggan. Biaya kegagalan eksternal
meliputi:
• Resolusi keluhan
• Penggantian dan pengembalian produk
• Dukungan help line
• Kerja jaminan
Biaya relatif mendapatkan dan membetulkan cacat bertambah secara dramatis

pada saat kita melangkah dari pencegahan ke pendeteksian dan dari kegagalan internal ke
kegagalan eksternal.
Gambar 10.1 Biaya Relatif pembetulan kesalahan
5. Jaminan Kualitas Perangkat Lunak
Kualitas perangkat lunak didefinisikan sebagai konformansi terhadap kebutuhan
fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan
yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan
bagi semua perangkat lunak dikembangkan secara profesional.
Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu:
1. Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas
diukur.
2. Standar yang telah ditentukan menetapkan serangkaian kriteria
pengembangan yang menuntun cara perangkat lunak direkayasa.
3. Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya
kebutuhan akan kemampuan pemeliharaan yang baik).
Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang

yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang
pelanggan. Kelompok SQA harus dapat menjawab pertanyaanpertanyaan dibawah
ini untuk memastikan bahwa kualitas perangkat lunak benar-benar terjaga.
1. Apakah perangkat lunak cukup memenuhi faktor kualitas.
2. Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar
yang telah ditetapkan sebelumnya?
3. Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian
dari aktivitas SQA?
6. Aktivitas SQA
Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan
dengan dua konstituen yang berbeda:
• Perekayasa perangkat lunak yang mengerjakan kerja teknis.
• Kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas,
kesalahan, penyimpanan rekaman, analisis, dan pelaporan.
Tugas kelompok SQA adalah membantu tim rekayasa perangkat lunak dalam
pencapaian produk akhir yang berkualitas tinggi.
Aktivitas yang dilakukan (atau difasilitasi) oleh kelompok SQA yang
independen:
1. Menyiapkan rencana SQA untuk suatu proyek. Rencana tersebut
mengindentifikasikan hal-hal berikut:
• Evaluasi yang dilakukan
• Audit dan kajian yang dilakukan
• Standar yang dapat diaplikasikan pada proyek
• Prosedur untuk pelaporan & penelusuran kesalahan
• Dokumen yang dihsilkan oleh kelompok SQA
• Jumlah umpan balik yang diberikan pada tim proyek perangkat lunak
2. Berpartisipasi dalam pengembangan deskripsi proses pengembangan proyek

3. Mengkaji aktivitas rekayasa perangkat lunak untuk memverifikasi
pemenuhan proses perangkat lunak yang sudah ditentukan.
4. Mengaudit produk kerja perangkat lunak yang ditentukan untuk membuktikan
kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari
proses perangkat lunak.
5. Memastikan bahwa deviasi pada kerja dan produk perangkat lunak
didokumentasikan & ditangani sesuai dgn rosedur pendokuementasian.
6. Mencatat ketidak-sesuaian dan melaporkannya kepada manajemen senior.
7. Mengkoordinasi kontrol dan manajemen perubahan, dan membantu
mengumpulkan dan menganalisis metrik perangkat lunak.
7. Kajian Perangkat Lunak
Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting.
Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu
kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari
kesalahan yg kemudian akan dihilangkan. Kajian perangkat lunak berfungsi untuk
“memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain,
dan pengkodean.
8. Kajian Teknik Formal

FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh
perekayasa perangkat lunak. Kajian teknik formal atau walktrough adalah pertemuan
kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk
menemukan kesalahan.
Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak
awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak.
Tujuan FTR adalah:
1. Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai
representasi PL.
2. Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat.
3. Memastikan bahwa PL disajikan sesuai dgn standar yg sudah ditentukan
sebelumnya.
4. Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam
5. Membuat proyek lebih dapat dikelola.
FTR berfungsi sebagai dasar pelatihan yang memungkinkan perekayasa yunior

mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain,
dan implementasi. FTR juga berfungsi untuk mengembangkan backup dan
kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak
yang tidak mereka ketahui sebelumnya
Masing-masing FTR dilakukan sebagai suatu pertemuan dan akan berhasil
hanya bila direncanakan, dikontrol dan dihadirkan dengan tepat. Dalam paragraf
berikut, panduan yang mirip dengan walktrough disajikan sebagai kajian teknis
formal representatif.
Tabel 10.1 Perbandingan Biaya Pengembangan
Kesalahan yang Jumlah Unit Biaya Total
ditemukan
Kajian dilakukan
Selama desain 22 1.5 33
Sebelum pengujian 36 6.5 234
Selama pengujian 15 15 315
Setelah peluncuran 3 67 201
Total 783
Kajian tidak
dilakukan
Sebelum pengujian 22 6.5 143
Selama pengujian 82 15 1230
Setelah peluncuran 12 67 804
Total 2177
9. Pertemuan Kajian
Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus
mematuhi batasan-batasan berikut ini:
• Antara 3 & 5 orang (khususnya) harus dilibatkan dalam kajian.
• Persiapan awal harus dilakukan, tetapi waktu yang dibutuhkan harus
tidak lebih dari 2 jam dari kerja bagi setiap orang.
• Durasi pertemuan kajian harus kurang dari 2 jam.
Pertemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan prosedur.

Salah satu dari pengkaji berperan sebagai pencatat, yaitu seseorang yang mencatat
semua masalah penting yang muncul selama pengkajian. FTR dimulai dengan
pengenalan agenda dan pendahuluan dari prosedur. Bila ada masalah kesalahan
ditemukan akan dicatat.
Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan
apakah akan:
1. Menerima produk kerja tanpa modifikasi lebih lanjut.
2. menolak produk kerja sehubungan dengan kesalahan yangada (sekali
dbetulkan, kajiann lain harus dilakukan), atau
3. Menerima produk kerja secara sementara (kesalahan minor telah terjadi & harus
dikoreksi, tetapi kajian tambahan akan diperlukan). Keputusan kemudian dibuat.
Semua peserta FTR melengkapinya dengan tanda tangan yang menunjukkan

partisipasi mereka dalam kajian serta persetujuan mereka terhadap pertemuan tim kajian.
10. Kajian Teknik Formal
Selama FTR, seorang pengkaji (pencatat) secara aktif mencatat semua masalah
yang sudah dimunculkan, yang kemudian dirangkum pada akhir pertemuan sehingga
dihasilkan daftar masalah kajian. Sebagai tambahan, laporan rangkuman kajian yang
sederhana telah diselesaikan di mana rangkuman kajian merupakan jawaban dari tiga
pertanyaan berikut:
1. Apa yang dikaji?
2. Siapa yang melakukan?
3. Penemuan apa yang dihasilkan dan apa kesimpulannya?
Daftar masalah kajian mempunyai dua tujuan:

1. Mengidentifikasi area masalah pada produk.
2. Daftar item kegiatan yang menjadi petunjuk bagi prosedur saat
koreksi dilakukan. Daftar masalah biasanya dilampirkan pada
laporan.
11. Pedoman Kajian
Pedoman untuk melakukan kajian teknis formal harus dilakukan sebelumnya,

didistribusikan kepada semua pengkaji, disetujui, dan kemudian dilaksanakan. Kajian yang
tidak terkontrol sering dapat menjadi lebih buruk daripada bila tidak ada kajian sama sekali.
Berikut ini serangkaian pedoman minimum untuk kajian teknis formal:
1. Kajian produk, bukan produser.
2. Menetapkan agenda dan menjaganya.
3. Membatasi perdebatan dan bantahan.
4. Menetapkan area masalah, tetapi tidak tergoda untuk menyelesaikannya
setiap masalah yang dicatat.
5. Mengambil catatan tertulis.
6. Membatasi jumlah peserta dan mewajibkan persiapan awal.
7. Mengembangkan daftar bagi masing masing produk kerja yang akan dikaji.
8. Mengalokasikan sumber-sumber daya dan jadwal waktu untuk FTR.
9. Melakukan pelatihan bagi semua pengkaji.
10. Mengkaji kajian awal Anda.
12. Pendekatan Formal Terhadap SQA
Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai
melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar
pengembangan perangkat lunak yang diterima.
Pada lebuh dari dua dekade, segmen komunitas rekayasa perangkat lunak yang kecil
tetapi vokal telah memperlihatkan bahwa dibutuhkan suatu pendekatan yang lebih formal
terhadap jaminan kualitas perangkat lunak. Pembuktian matematis terhadap kebenarannya
dapat diaplikasikan untuk menunjukkan bahwa program menyesuaikan diri secara tepat
dengan spesifikasinya.
13. Pendekatan Formal Terhadap SQA

Jaminan kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh
industri untuk menjadi lebih kuantitatif terhadap kualitas. Pada perangkat lunak, jaminan
kualitas statistik mengimplikasikan langkah-langkah berikut ini:
1. Informasi tentang cacat perangkat lunak dikumpulkan dan dipilah-
pilahkan.
2. Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai
ke penyebab pokoknya.
3. Dengan menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri
sampai 20 persen dari semua kemungkinan penyebab), mengisolasi yang 20
persen tersebut (vital few).
4. Sekali penyebab vital few telah diidentifikasi, beralih untuk
membetulkan maslah yang menyebabkan cacat.
Banyak kesalahan ditemukan pada waktu perangkat lunak sedang dalam

proses pengembangan. Cacat yang lain ditemukan setelah perangkat lunak
diluncurkan kepada pemakai akhir. Meskipun ratusan kesalahan yang berbeda
diluncurkan, semuanya dapat ditelusuri dari satu (atau lebih) penyebab berikut ini:
1. Spesifikasi yang tidak lengkap atau keliru (IES)
2. Kesalahan interpretasi komunikasi pelanggan (MMC)
3. Deviasi intersioanl dari spesifikasi (IDS)
4. Pelanggaran standar pemrograman (VPS)
5. Kesalahan dalam representasi data (EDRIMI)
6. Kesalahan dalam logika desain (EDL)
7. Interface modul yang tidak konsisten (IMI)
8. Pengujian yang tidak lengkap atau keliru (IET)
9. Dokumentasi yang tidak lengkap atau tidak akurat (IID)
10. Kesalahan dalam penerjemahan bahasa pemrograman desain (PLT)
11. Antarmuka manusia dengan komputer yang tidak konsisten atau
mengandung ambiguitas (HCI)
12. Dan msih banyak lagi (MIS)
I. Referensi:
1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997
2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004
3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,2006
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Negosiasi
11
Komputer
Abstract Kompetensi
Negosiasi merupakan salah satu Mahasiswa mengenal, memahami
faktor yang penting di dalam sebuah dan memiliki kemampuan
proyek perangkat lunak bernegosiasi didalam sebuah aktivitas
proyek perangkat lunak.
1. Pengantar
1. Pendahuluan
Negosiasi tidak hanya digunakan di dalam bisnis yang bertujuan untuk meraih laba,
namun juga sangat bermanfaat di dalam menjalankan dan mencapai tujuan proyek Teknologi
Informasi. Teknik negosiasi yang dapat digunakan di dalam proyek TI pada prinsipnya sama
dengan teknik negosiasi di dalam bisnis, politik, hukum, social, dan lain-lain Seperti halnya di
dalam bisnis, negosiasi selalu mengarah kepada keberhasilan suatu tujuan.
Di dalam bernegosiasi prinsip dasar yang harus sama-sama disadari adalah adanya
prinsip member dan menerima. Namun seberapa besar porsi member dan porsi menerima
tergantung kepada kemampuan bernegosiasi. Semakin tinggi kemampuan seseorang
bernegosiasi, semakin banyak akan menerima keuntungan dari proses negosiasi. Demikian juga
sebaliknya, semakin rendah kempuan seseorang bernegosiasi, semakin kecil keuntungan dari
proses negosiasi dan bahkan mungkin bisa menimbulkan kerugian yang tidak diinginkan.
Oleh karena itu, di dalam menjalankan suatu proyek TI, seorang Project Manager atau
Project Lead TI harus dapat menjadi negosiator yang ulung, yang dapat mengetahui secara pasti
kapan harus memberi atau menerima. Seorang negosiator yang ulung haruslah memiliki daya
peka / kepekaan yang tinggi terhadap situasi dan suasana di dalam proses negosiasi. Daya peka
tersebut dapat digunakan oleh seorang negosiator ulung menekan lawan negosiasinya.
Kemampuan negosiasi tidak hanya digunakan untuk menekan lawan negosiasi, tetapi
juga membela diri pada saat tertekan. Teknik bernegosiasi bukanlah teknik pandai berbicara,
namun lebih kepada teknik berbicara pada saat dan situasi yang tepat. Negosiasi adalah seni,
yang dapat dipelajari dan bersifat unik karena selain dapat menguntungkan atau merugikan pihak
lawan, dapat juga sebagai proses kerja sama / kolaborasi dua pihak yang berbeda kepentingan
dengan tujuan akhir hasil yang terbaik bagi kedua belah pihak.
2. Teori Negosiasi
1. Pengenalan Pengertian Negosiasi (The Nature of Negotiation)
Negosiasi dapat terjadi setiap saat, antar teman, antar keluarga, antar
rekan bisnis, antar pengacara, antar penegak hukum, antar Negara dan lain
sebagainya. Negosiasi bukanlah suatu proses timbal balik, namun merupakan
kemampuan diplomasi, kemampuan penjualan yang unggul, kemampuan daya
juang yang tinggi yang terjadi di dalam kehidupan sehari-hari. Adakalanya
negosiasi digunakan di dalam situasi yang penting seperti negosiasi pekerjaan
baru ataupun situasi yang sangat sederhana seperti tugas mencuci piring.
Namun demikian struktur dan proses negosiasi tetaplah sama pada level individu
maupun organisasi.
Adapun karakteristik dari negosiasi antara lain:
1. Terdapat dua atau lebih pihak yang terlibat di dalam proses negosiasi.
2. Terdapat perbedaan kepentingan ( conflict ) antara dua atau lebih
pihak yang terlibat di dalam proses negosiasi.
3. Negosiasi dilakukan oleh pihak yang berkepentingan karena mereka
berpikir bahwa mereka dapat menggunakan pengaruhnya untuk
mendapatkan kesepakatan yang lebih baik dengan cara bernegosiasi
dibandingkan dengan begitu saja mengalah terhadap lawan negosiasi.
4. Pihak – pihak yang bernegosiasi akan lebih suka melakukan
kesepakatan dibandingkan harus berseteru secara terbuka, menyerah
begitu saja, memutuskan komunikasi atau memeruskan perselisihan
ketingkat yang lebih tinggi.
5. Negosiasi adalah proses memberi dan menerima.
6. Negosiasi yang sukses akan mempengaruhi manajemen secara
intangibles dan tangibles.
Tingkatan Perbedaan Kepentingan (conflict):
1. Perbedaan kepentingan di dalam diri seseorang (Intra personal or intra psychic
conflict)
2. Perbedaan kepentingan antar seseorang (Inter Personal Conflict)
3. Perbedaan kepentingan di dalam kelompok (Intra Group Conflict)
4. Perbedaan kepentingan antar kelompok (Inter Group Conflict)
Hal-hal yang dapat menimbulkan Conflict:

1. Proses kompetisi (competitive process)
2. Interpretasi yang berbeda dan bias (Misperception and Bias)
3. Emosi (Emotionality)
4. Komunikasi yang tidak kondusif (Decreased Communication)
5. Issue yang tidak jelas (Blurred Issues)
6. Komitmen yang kaku (Rigid Commitment)
7. Memperbesar perbedaan dan memperkecil persamaan (Magnified
Differences dan Minimized Similarities)
8. Perbedaan kepentingan yang di perluas (Escalation of the Conflict)
Strategi untuk menghadapi perbedaan kepentingan (conflict):

1. Kompetisi/ Bersaing (Contending / Competing / Dominating)
2. Penurut (Yielding / Accommodating / Obliging)
3. Menghindar (Inaction / Avoiding)
4. Kolaborasi / menyelesaikan masalah (Collaborating / Integrating)
5. Kompromi (Compromising)
2. Frame, Strategi dan Rencana Negosiasi
Sebelum melakukan negosiasi, negotiator harus mempersiapkan rencana dan

strategi yang efektif , yang merupakan kunci keberhasilan dari tujuan negosiasi. Apabila
tidak menggunakan rencana dan startegi maka negosiasi hanya akan menghasilkan
kesempatan dibandingkan usaha untuk mendapatkan tujuan yang diinginkan.
Kerangka Masalah ( Framing the Problem ) - Proses Mendefinisikan Seberapa
Penting Masalah, ada 3 pendekatan yang dapat dipelajari yaitu:
1. Kerangka yang berhubungan dengan suatu keputusan yang sederhana (Frames as
cognitive heuristics – simple decision rules)
2. Kerangka yang berhubungan dengan pengalaman, latar belakang dan
pengetahuan training yang berbeda-beda (Frames as categories of experience)
3. Kerangka yang berhubungan dengan pilihan dan prioritas (Frames as issue
development )
Setelah negotiator mempunyai kerangka atas masalah yang terjadi, negotiator

juga harus mempunyai strategi untuk menentukan tujuan yang akan dicapai. Negotiator
harus dapat mengantisipasi apa yang akan dicapai di dalam negosiasi dan menyiapkan
segala sesuatu yang mungkin akan sejak awal. Untuk itu negotiator harus dapat
mengetahui aspek-aspek yang terkait dengan tujuan yang dapat berpengaruh secara
langsung maupun tidak langsung terhadap hasil negosiasi.
4 Aspek yang terkait dengan tujuan, yang berpengaruh secara langsung
terhadap tujuan negosiasi yaitu:
1. Harapan bukanlah tujuan, namun merupakan kebutuhan untuk mencapai tujuan.
2. Tujuan kita seringkali terkait dengan tujuan pihak lain.
3. Terdapat batasan untuk dapat mencapai tujuan kita.
4. Tujuan yang efektif haruslah kongkrit/ spesifik dan dapat diukur.
Aspek yang terkait dengan tujuan, yang berpengaruh secara tidak langsung
terhadap tujuan negosiasi yaitu:
1. Untuk tujuan yang sederhana, kejadian di masa lalu tidak berpengaruh terhadap
negosiasi. Misalnya : proses jual beli mobil, mengabaikan siapa pemilik
sebelumnya.
2. Untuk tujuan yang lebih kompleks, kejadian di masa lalu berpengaruh terhadap
negosiasi. Misalnya : proses pemutusan kredit, haruslah mempertimbangkan
kredibilitas nasabah di masa yang lalu.
Bagaimana hubungan antara strategi dan taktik ? Perbedaan utamanya adalah

pada skala, perspektif dan tingkat kepentingan. Taktik lebih besifat jangka pendek,
didesain lebih adaptif terhadap perubahan untuk mendukung high level strategi, lebih
stabil, berkelanjutan dan mengarahkan perilaku yang lebih taktis. Taktik merupakan
bagian dari strategi yang lebih terstruktur, terarah dan terdorong oleh pertimbangan
strategis.
Bagaimana hubungan antara strategi dan perencanaan ? Perencanaan
merupakan bagian dari proses strategi. Bagaimana perencanaan dihasilkan akan
menjadi petunjuk yang strategis. 4 tipe strategi untuk negosiasi adalah:
1. Kompetisi (Competition)
2. Kolaborasi (Collaboration)
3. Akomodasi (Accommodation)
4. Menghindar (Avoidance)
Kunci sukses negosiasi bukanlah bagaimanana proses negosiasi itu sendiri yang
dapat dianggap permainan ataupun sandiwara, namun perencanaan yang handal
sebelum dilakukannya negosiasi.
Kelemahan di dalam melakukan perencanaan sebelum melakukan negosiasi
adalah keterbatasan waktu untuk membuat rencana, antara lain:
1. Negotiator gagal menyusun tujuan yang jelas
2. Negotiator tidak dapat mengetahui kekuatan dan kelemahannya untuk
mendukung posisinya terhadap argument pihak lawan
3. Negotiator tidak cukup cepat dan pandai untuk memberi dan menerima hasil
negosiasi yang dapat membuat situasi down, dimana pihak lawan menyerang
dengan cara-cara yang mungkin saja bisa bertentangan dengan ketentuan, tidak
mempuyai dasar yang kuat ataupun tidak efektif.
Perencanaan negosiasi yang efektif mencakup:

1. Definisikan isu-isu (defining issues)
2. Kumpulkan isu-isu dan definisikan scenario tawar menawar (assembling
issues and defining the bargaining mix)
3. Definisikan kepentingan (defining interest)
4. Konsultasi dengan pihak lain (consulting with others)
5. Identifikasi Batasan (Identifying Limits)
6. Tetapkan sasaran (Setting Targets)
7. Kembangan pendapat-pendapat yang menudukung (Developing
supporting arguments)
8. Analisa pihak lawan (Analyzing the other party)
3. Strategi dan Taktik Tawar Menawar
Untuk lebih memahami struktur dasar dari situasi kompetisi dan tawar menawar
serta strategi dan taktik tawar menawar, kita harus memahami terlebih dahulu
bagaimana proses tawar menawar dimulai. Tawar menawar dimulai dari menetapkan
hal-hal yang menjadi pembuka, sasaran dan perlawanan di dalam proses negosiasi. Kita
akan dengan mudah mengetahui hal-hal yang menjadi pembuka dan sasaran pihak
lawan, namun kita akan mengalami kesulitan untuk mengetahui strategi perlawanan
pihak lawan, karena pada umumnya disembunyikan oleh lawan. Mengetahui strategi
perlawanan pihak lawan adalah kunci utama kesuksesan di dalam proses tawar
menawar.
Perbedaan antara strategi perlawanan yang kita miliki dengan strategi
perlawanan pihak lawan akan menentukan sukses tidaknya proses negosiasi. Jika
perbedaan tersebut bernilai positif maka akan terjadi proses negosiasi. Jika perbedaan
tersebut bernilai negative makan tidak akan terjadi proses negosiasi. Di dalam proses
negosiasi umumnya isu yang dibahas lebih dari satu, sehingga di dalam proses tawar
menawar akan terdapat lebih dari satu hal-hal yang menjadi pembuka, sasaran dan
perlawanan dari pihak lawan. Proses tawar menawar secara gabungan akan
menghasilkan sekumpulan isu yang sama, hubungan timbal balik dan menghasilkan
perilaku konsesi yang saling menguntungkan. Proses tawar menawar pada dasarnya
adalah suatu situasi konflik, dimana pihak-pihak yang saling berlawanan ingin
mendapatkan keuntungan,dengan cara menyembunyikan informasi, mencoba untuk
mengalihkan atau menggunakan aksi-aksi manipulasi.
Semua taktik ini akan dengan mudah menghasilkan interaksi dari diskusi yang
tenang menjadi diskusi yang panas. Negosiasi merupakan jalan keluar untuk
menyelesaikan suatu konflik dengan cara memaksa untuk menghasilkan suatu
kesepakatan tanpa menimbulkan perkelahian. Oleh karenanya, untuk menghasilkan
negosiasi yang sukses, kedua belah pihak yang bernegosiasi haruslah merasa hasil
negosiasi merupakan hasil yang terbaik, yang dapat dihasilkan nilainya dapat diterima
dan didukung. Bagaimanapun juga negosiasi adalah suatu proses yang dibutuhkan,
bukan hanya keahlian tetapi juga pengertian/ pemahaman dan perencanaan yang baik.
4. Strategi dan Taktik Negosiasi Terpadu
Struktur dasar dari proses negosiasi terpadu adalah ditentukannya beberapa

tujuan negosiasi oleh seorang negosiator yang memungkinkan pihak-pihak yang terlibat
di dalam proses negosiasi dapat mencapai sasaran-sasaran yang diingikannya.
Negosiasi terpadu adalah proses mendefinisikan beberapa tujuan dan terikat dengan
seperangkat prosedur yang memungkingkan kedua belah pihak yang bernegosiasi
memaksimalkan sasaran mereka.
Negosiasi terpadu yang sukses akan memerlukan beberapa proses. Pertama,
setiap pihak yang melakukan negosiasi haruslah saling memahami kebutuhan dan
tujuannya. Kedua, setiap pihak yang melakukan negosiasi haruslah dapat menciptakan
arus informasi bebas dan pertukaran pemikiran yang terbuka. Ketiga, setiap pihak yang
melakukan negosiasi haruslah fokus terhadap persamaan, bukan kepada perbedaan
yang ada. Terakhir setiap pihak yang melakukan negosiasi haruslah sepakat untuk
mencari solusi yang terbaik agar sejalan dengan tujuan kedua belah pihak.
5. Komunikasi, Persepsi dan Bias Kognitif
Terdapat dua kritikal proses terkait dengan upaya negotiator menjadikan proses
negosiasi menjadi berarti dan komunikasi berjalan yaitu persepsi ( perception ) dan
pengetahuan ( cognition ). Komunikasi seperti apa yang dibutuhkan di dalam proses
negosiasi ? Negosiasi bukanlah sekedar proses pertukaran pilihan solusi, namun lebih
luas dari itu, negosiasi mencakup sejumlah topik yang luas di dalam suatu lingkungan
dimana setiap pihak yang bernegosiasi berupaya untuk saling mempengaruhi satu sama
lain. Negosiasi juga dapat dilihat dari perspektif linguistic.
Apabila di lihat dari sudut pandang persepsi dan negosiasi itu sendiri serta
persepsi proses negosiasi terdapat 4 (empat) distorsi persepsi yaitu:
1. Stereotyping
2. Halo Effects,
3. Selective Perception
4. Projection
Kerangka masalah (frame) mempengaruhi persepsi di dalam proses negosiasi.
Selain itu juga kerangka masalah dan isu-isu pengembangan akan berpengaruh kepada
persepsi negotiator selama proses negosiasi berlangsung. Berdasarkan hasil penelitian,
diperoleh satu kesimpulan bahwa terdapat bias kognitif (cognitive bias) dari satu atau
lebih area permintaan keterangan didalam proses negosiasi. Terdapat 11 (sebelas)
perbedaan bias kognitif ( cognitive bias ) yaitu:
1. Irational escalation of commitment
2. Mithical fixed-pie beliefs
3. Anchoring and adjustment
4. Framing
5. Availability of information
6. The winner’s curse
7. Overconfidence
8. The law of small number
9. Self-serving biases
10. Ignoring of others’ cognitions
11. Reactive devaluation
Di dalam proses negosiasi perbedaan persepsi dan bias kognitif haruslah di jaga
agar tidak menjadi perbedaan yang signifikan. Cara meningkatkan komunikasi di dalam
proses negosiasi adalah dengan menggunakan teknik : the use of questions, listening
dan role reversal. Cara memperbaiki suasana hati dan emosi di dalam proses negosiasi
adalah dengan menggunakan teknik komunikasi, dengan menggunakan 2 (dua) model
komunikasi yaitu:
1. Cold communication, mencakup : penuh perhitungan (calculating), tenang (calm)
dan kontrol (control).
2. Warm communication, mencakup : suasana panas (hot), marah (angry),
bersemangat (passionate)
6. Mengetahui Pengaruh Negosiasi
Apabila kita berbicara tentang pengaruh negosiasi, kita akan mulai

membahasnya dari sifat kekuasaan. Ada 3 (tiga) sifat kekuasaan yaitu informasi dan
keahlian, kontrol atas sumber daya dan lokasi di dalam struktur organisasi baik untuk
kekuasaan yang bersifat formal maupun informal. Negosiasi yang merupakan proses
tawar menawar atau penggunaan sumber kekuasaan yang berbeda-beda untuk
memperoleh atau menggunakan keuntungan sementara atas negosiasi dengan pihak
lain. Ada 4 (empat) cara yang dapat digunakan untuk mempengaruhi proses negosiasi,
yaitu:
1. Message factors, yaitu cara dimana isi dari pesan (posisi pernyataan, daya tarik,
dan lain-lain) dapat disusun dan disampaikan untuk meningkatkan efektifitas.
2. Source factors, yaitu cara dimana pengirim pesan dapat meningkatkan
kredibilitas dan ketertarikan agar membuat pesan menjadi lebih dapat dipercaya
dan lebih terkesan ramah.
3. Receiver factors, yaitu cara dimana penerima pesan dapat menentukan dan
mengarahkan apa yang dikomunikasikan oleh pengirim pesan atau menolak
secara halus dampak persuasif dari pesan yang disampaikan.
4. Context factors, atau elemen yang melekat dalam struktur sosial ( seperti
hubungan antar pihak yang bernegosiasi, pengaturan pengiriman pesan atau
banyaknya waktu yang dibutuhkan untuk mengkomunikasikan pesan ) yang
dapat menentukan apakah suatu pesan berlebih atau kurang dapat diterima /
kurang lengkap.
Ada 2 (dua) hal yang dapat dipelajari terkait dengan pengaruh negosiasi yaitu:
1. Pengaruh di dalam negosiasi dapat sangat sukar dipahami ataupun dilakukan
dalam sekejap.
2. Pihak-pihak yang bernegosiasi biasanya harus menghabiskan banyak waktu
untuk merancang cara untuk mendapatkan dukungan dan memposisikan mereka
di dalam proses negosiasi.
7. Etika Bernegosiasi
Etika bernegosiasi dapat menjadi suatu hal yang sangat kritis untuk memilih
strategi tertentu dan pilihan taktis di dalam proses negosiasi. Apabila pihak-pihak yang
bernegosiasi memilih untuk memilih taktik yang tidak etis, umumnya keputusan yang
diambil menggunakan pendekatan kekuasaan yang lebih besar. Adapun konsep etika
negosiasi adalah sebagai berikut:
1. Pada saat ada pihak yang terlibat negosiasi tidak setuju dengan proses
negosiasi, hal ini dapat menjadi proses negosiasi yang beretika atau tidak
beretika. Penelitian membuktikan bahwa terdapat lebih banyak konvergensi hasil
negosiasi dari pada sesuatu yang diharapkan
2. Keputusan untuk menggunakan taktik yang tidak jujur mugkin saja bisa dipahami
dengan membuat suatu model keputusan. Hal ini sangat jelas tergambar dimana
individu berbeda-beda dan variabel-variabel situasi yang dapat mempengaruhi
suatu keputusan
3. Pada saat memutuskan untuk menggunakan taktik yang tidak jujur, seorang
negotiator umumnya lebih banyak dipengaruhi oleh motivasi individu, ekspektasi
tentang apa yang akan dilakukan oleh negosiator lainnya dan hubungan antar
pihak yang bernegosiasi di kemudian hari
4. Pihak-Pihak yang melakukan proses negosiasi dengan cara yang tidak jujur,
sebaiknya mengevaluasi kembali penggunaan taktik ini untuk proses negosiasi di
kemudian hari. Karena meskipun jenis taktik ini bisa digunakan untuk jangka
waktu yang singkat, namun akan menjadi tidak efektif untuk jangka waktu yang
panjang
8. Mengatur Negosiasi yang Sulit

Proses negosiasi sering kali menghadapi kebutuan seperti komunikasi yang
terputus, kemarahan yang memuncak dan rasa tidak percaya, polarisasi posisi dan
penolakan terhadap suatu kompromi, adanya ultimatum, ketidakmampuan akan hal
yang sederhana di dalam hal memenuhi kepuasan hasil negosiasi di kedua belah pihak.
Adapun teknik-teknik yang dapat digunakan untuk mengatur negosiasi yang sulit adalah:
1. Menurunkan tingkat ketegangan dengan cara memisahkan pihak yang
bersitegang untuk masa tenang dalam kurun waktu tertentu/ yang cukup,
membicarakan tentang emosi dan perasaan atau mencoba untuk
mengsikronisasikan dengan menurunkan ringkat eskalasi dari konflik
2. Lakukan peningkatan komunikasi yang akurat dengan cara menyampaikan
pendapat orang lain atau sebaliknya
3. Menjaga agar isu tetap dalam koridor terkontrol sehingga tidak akan menjadi isu
yang bertambah atau lebih besar dan menjadi isu yang kelompok-kelompok kecil
4. Tentukan posisi komunalitas, cara-cara untuk mendefinisikan isu-isu untuk dapat
mencapai tujuan kedua belah pihak ( kerangka yang terintegrasi ) dan tujuan
lainnya yang akan menyatukan pihak-pihak yang bernegosiasi mencapai tujuan
bersama
5. Ciptakan suasana dimana setiap pihak yang bernegosiasi memilki pilihan yang
diinginkan sesuai yang diharapkan dan nyaman untuk pihak lawan dengan cara
mengemas usulan yang lebih baik
I. Referensi:
1. Astra Human resources Management. 2001. Jakarta, Astra International
2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and
Management, New York, McGraw-Hill International Edition.
3. Hariwijaya. 2010. Strategi Lobi dan Negosiasi, Yogyakarta, Oriza.
4. Jimmy Joses Sembiring. Smart HRD. 2010. Jakarta, Visimedia.
5. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media
Group.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Kerjasama Tim
12
Komputer
Abstract Kompetensi
Kerjasama tim dibutuhkan didalam Mahasiswa mengenal, memahami
pelaksanaan sebuah proyek dan memiliki kemampuan bekerja
perangkat lunak secara tim di dalam sebuah proyek
perangkat lunak
1. Pengantar
1. Pendahuluan
Penyelenggaraan teamwork dilakukan karena pada saat ini tekanan persaingan

semakin meningkat, para ahli menyatakan bahwa keberhasilan organisasi akan semakin
bergantung pada teamwork daripada bergantung pada individu-individu yang menonjol.
Konsep tim maknanya terletak pada ekspresi yang menggambarkan munculnya sinergi
pada orang-orang yang mengikatkan diri dalam kelompok yang disebut dengan tim.
Tracy (2006) menyatakan bahwa teamwork merupakan kegiatan yang dikelola
dan dilakukan sekelompok orang yang tergabung dalam satu organisasi. Teamwork
dapat meningkatkan kerja sama dan komunikasi di dalam dan di antara bagianbagian
perusahaan. Biasanya teamwork beranggotakan orang-orang yang memiliki perbedaan
keahlian sehingga dijadikan kekuatan dalam mencapai tujuan perusahaan.
Pernyataan di atas diperkuat Dewi (2007) kerja tim (teamwork) adalah bentuk
kerja dalam kelompok yang harus diorganisasi dan dikelola dengan baik. Tim
beranggotakan orang-orang yang memiliki keahlian yang berbeda-beda dan
dikoordinasikan untuk bekerja sama dengan pimpinan. Terjadi saling ketergantungan
yang kuat satu sama lain untuk mencapai sebuah tujuan atau menyelesaikan sebuah
tugas. Dengan melakukan teamwork diharapkan hasilnya melebihi jika dikerjakan
secara perorangan.
Stephen dan Timothy (2008) menyatakan teamwork adalah kelompok yang
usaha-usaha individualnya menghasilkan kinerja lebih tinggi daripada jumlah masukan
individual. Teamwork menghasilkan sinergi positif melalui usaha yang terkoordinasi.
Hal ini memiliki pengertian bahwa kinerja yang dicapai oleh sebuah tim lebih baik
daripada kinerja perindividu di suatu organisasi ataupun suatu perusahaan.
Teori yang dikemukakan oleh Stephen dan Timothy (2008) senada dengan teori
tim yang efektif yang dikemukakan oleh Smither, Houston, McIntire (1996). Manurut
Smither, Houston, McIntire (1996), tim yang efektif adalah sebuah tim yang
memungkinkan anggotanya untuk bisa menghasilkan penyelesaian tugas yang lebih
besar jumlahnya dibandingkan dengan hasil kerja perorangan karena hasil kerjanya
merupakan hasil dari kontribusi anggota-anggota tim secara bersama-sama.
Pernyataan tersebut juga didukung oleh Burn (2004), yang menyatakan bahwa
efektifitas tim atau tim yang efektif merupakan tim kerja yang anggota-anggotanya saling
berkolaborasi untuk mencapai tujuan bersama dan memiliki sikap yang saling
mendukung dalam kerjasama tim.
2. Jenis Kerjasama Tim
Menurut Daft (2000) jenis teamwork terdiri dari 6 (enam) jenis, yaitu:
1. Tim Formal
Tim formal adalah sebuah tim yang dibentuk oleh organisasi sebagai bagian dari
struktur organisasi formal.
2. Tim Vertikal
Tim vertikal adalah sebuah tim formal yang terdiri dari seorang manajer dan
beberapa orang bawahannya dalam rantai komando organisasi formal.
3. Tim Horizontal
Tim horizontal adalah sebuah tim formal yang terdiri dari beberapa karyawan dari
tingkat hirarki yang hampir sama tapi berasal dari area keahlian yang berbeda.
4. Tim dengan Tugas Khusus

Tim dengan tugas khusus adalah sebuah tim yang dibentuk diluar organisasi
formal untuk menangani sebuah proyek dengan kepentingan atau kreativitas
khusus.
5. Tim Mandiri
Tim Mandiri adalah sebuah tim yang terdiri dari 5 hingga 20 orang pekerja
dengan beragam keterampilan yang menjalani rotasi pekerjaan untuk
menghasilkan sebuah produk atau jasa secara lengkap, dan pelaksanaannya
diawasi oleh seorang annggota terpilih.
6. Tim Pemecahan Masalah
Tim pemecahan masalah adalah biasanya terdiri dari 5 hingga 12 karyawan
yang dibayar perjam dari departemen yang sama, dimana mereka bertemu untuk
mendiskusikan cara memperbaiki kualitas, efisiensi, dan lingkungan kerja.
Sedangkan menurut Hariandja (2006) ada 3 (tiga) tipe tim, yaitu:

1. Problem solving team
Sebuah tim yang dibentuik untuk mengatasi berbagai masalah yang muncul
dalam upaya memperbaiki produktivitas. Pada dasarnya, kegiatan tim ini adalah
mengidentifikasikan berbagai masalah, mendiskusikan bagaimana memecahkan
masalah tersebut dan melakukan tindakan untuk memperbaiki. Anggota tim
biasanya berasal dari satu departemen yang beranggotakan kurang lebih
sepuluh orang yang melakukan pertemuan rutin setiap minggu.
2. Self managed team

Sebuah tim yang dimaksudkan untuk memperbaiki produktivitas dengan
memberikan kewenangan pada kelompok untuk mengatur kerja mereka,
misalnya menjadwal kerja, menentukan metode kerja, mengawasi anggota,
memberi reward dan hukuman bagi anggota dan merekrut anggota.
Keanggotaan ini biasanya berasal dari satu departemen yang melakukan tugas
yang sama.
3. Cross functional team

Sebuah tim yang ditujukan untuk menyelesaikan tugas-tugas khusus, misalnya
pengembangan produk baru atau perencanaan dan perubahan sistem
kompensasi. Anggota tim ini berasal dari berbagai departemen yang memiliki
keahlian dan orientasi yang berbeda yang bekerjasama untuk mencapai suatu
tujuan.
3. Tahap Perkembangan Teamwork
Hal yang sangat mendasar dalam mewujudkan keutuhan sebuah tim agar dapat
berkinerja dan berdaya guna adalah dengan melakukan perancangan tim yang baik.
Pentingnya perancangan tim yang baik diuraikan Griffin (2004) dengan membagi ke
dalam 4 (empat) tahap perkembangan, yaitu:
1. Forming
Forming (pembentukan), adalah tahapan di mana para anggota setuju
untuk bergabung dalam suatu tim. Karena kelompok baru dibentuk maka setiap
orang membawa nilai-nilai, pendapat dan cara kerja sendiri-sendiri. Konflik
sangat jarang terjadi, setiap orang masih sungkan, malu-malu, bahkan seringkali
ada anggota yang merasa gugup. Kelompok cenderung belum dapat memilih
pemimpin (kecuali tim yang sudah dipilih ketua kelompoknya terlebih dahulu).
2. Storming
Storming (merebut hati), adalah tahapan di mana kekacauan mulai timbul di
dalam tim. Pemimpin yang telah dipilih seringkali dipertanyakan kemampuannya
dan anggota kelompok tidak ragu-ragu untuk mengganti pemimpin yang dinilai
tidak mampu. Faksi-faksi mulai terbentuk, terjadi pertentangan karena masalah-
masalah pribadi, semua bersikeras dengan pendapat masing-masing.
Komunikasi yang terjadi sangat sedikit karena masing-masing orang tidak mau
lagi menjadi pendengar.
3. Norming
Norming (pengaturan norma), adalah tahapan di mana individu-individu dan
subgroup yang ada dalam tim mulai merasakan keuntungan bekerja bersama
dan berjuang untuk menghindari team tersebut dari kehancuran (bubar). Karena
semangat kerjasama sudah mulai timbul, setiap anggota mulai merasa bebas
untuk mengungkapkan perasaan dan pendapatnya kepada seluruh anggota tim.
4. Performing
Performing (melaksanakan), adalah tahapan merupakan titik kulminasi di mana
team sudah berhasil membangun sistem yang memungkinkannya untuk dapat
bekerja secara produktif dan efisien. Pada tahap ini keberhasilan tim akan
terlihat dari prestasi yang ditunjukkan.
4. Peranan Anggota Tim
Selanjutnya Williams (2008) membagi ada 5 (lima) hal yang menunjukkan

peranan anggota dalam membangun kerja tim yang efektif, yaitu:
1. Para anggota mengerti dengan baik tujuan tim dan hanya dapat dicapai dengan
baik pula dengan dukungan bersama, dan oleh karena itu mempunyai rasa
saling ketergantungan, rasa saling memiliki tim dalam melaksanakan tugas.
2. Para anggota menyumbang keberhasilan tim dengan menerapkan bakat dan
pengetahuannya untuk sasaran tim, dapat bekerja dengan secara terbuka, dapat
mengekspresikan gagasan, opini dan ketidaksepakatan, peranan dan
pertanyaannya disambut dengan baik.
3. Para anggota berusaha mengerti sudut pandang satu sama lain, didorong untuk
mengembangkan keterampilannya dan menerapkan pada pekerjaan, untuk itu
mendapat dukungan dari tim.
4. Para anggota mengakui bahwa konflik adalah hal yang normal, atau hal yang
biasa, dan berusaha memecahkan konflik tersebut dengan cepat dan konstruktif
(bersifat memperbaiki).
5. Para anggota berpartisipasi dalam keputusan tim, tetapi mengerti bahwa
pemimpin mereka harus membuat peraturan akhir setiap kali tim tidak berhasil
membuat suatu keputusan, dan peraturan akhir itu bukan merupakan
persesuaian.
5. Dimensi Tim yang Efektif
Menurut Johnson dan Johnson (dalam Smither, Houston, dan Mclntire, 1996),
ada 9 dimensi dalam model efektifitas tim yang dapat digunakan untuk mengevaluasi
anggota tim dan mengidentifikasikan kekuatan serta kelemahan yang ada di dalam tim,
yaitu:
1. Pemahaman, relevansi, dan komitmen pada tujuan
Setiap anggota tim harus memahami tujuan tim secara jelas dan memiliki
kemauan untuk mewujudkan tujuan-tujuan tim karena tujuan tim adalah
merupakan hasil dari tujuan bersama dimana tujuan tim pada akhirnya akan
mendorong terwujudnya kerjasama dalam tim sehingga kerjasama dalam tim
mampu untuk meningkatkan prestasi, produktivitas, dan menciptakan hubungan
kerja yang positif diantara sesama anggotanya.
2. Komunikasi mengenai ide dan perasaan

Komunikasi di antara anggota tim harus melibatkan penyampaian dan
penerimaan informasi tentang ide-ide dan perasaan. Dalam tim yang tidak
efektif, komunikasi sering satu arah dan memfokuskan secara eksklusif hanya
pada ide saja. Dengan mengabaikan atau menekan perasaan, maka tim berisiko
kehilangan informasi yang berharga dan dapat melemahkan kohesivitas tim.
3. Kepemimpinan yang berpartisipasi

Kepemimpinan harus berpartisipasi dan mendistribusikan peran
kepemimpinannya kepada semua anggota tim.
4. Fleksibel dalam menggunakan prosedur pembuatan keputusan

Prosedur pengambilan keputusan harus sesuai dengan kebutuhan tim dan sifat
keputusannya. Keterbatasan waktu, keterampilan anggota dan implikasi dari
semua keputusan tim harus dinilai secara hati-hati. Sebagai contoh, ketika
keputusan-keputusan penting dibuat maka akan membutuhkan dukungan dari
anggota tim untuk mengimplementasikan dan melakukan strateginya dengan
efektif.
5. Manajemen konflik yang konstruktif

Tim yang tidak efektif sering mencoba untuk mengabaikan atau menekan konflik,
sedangkan tim yang efektif dapat menggunakan konflik dengan cara yang
konstruktif. Ketika dikelola dengan baik, konflik dapat menyebabkan
pengambilan keputusan yang baik pula yakni memecahkan masalah dengan
lebih kreatif, dan jumlah partisipasi anggota tim yang lebih tinggi.
6. Kekuasaan berdasarkan keahlian, kemampuan, dan informasi

Anggota tim harus mampu mempengaruhi dan dipengaruhi oleh orang lain untuk
mengkoordinasikan kegiatan tim. Kekuasaan dan saling mempengaruhi ini harus
terwujudkan secara merata dalam tim. Apabila kekuasaan dan kegiatan saling
mempengaruhi ini hanya dipusatkan pada beberapa orang anggota tim saja
maka kemungkinan efektifitas tim, komunikasi dan kohesivitas tim akan menjadi
berkurang.
7. Kohesi Tim
Dalam tim yang kohesif, setiap anggota merasa saling menyukai antara satu
sama lainnya dan merasa puas dengan keanggotaan tim mereka. Meskipun
kohesi tidak mengarah kepada efektifitas namun ia memiliki peranan yang
penting dalam mewujudkan tim yang efektif yaitu ketika ia dikombinasikan
dengan dimensi lain dari efektifitas tim maka sebuah tim yang memiliki
kohesivitas yang tinggi cenderung meningkatkan produktivitas.
8. Strategi pemecahan masalah

Tim harus mampu mengenali masalah dan menghasilkan solusi secara tepat.
Setelah solusinya diimplementasikan, tim harus mengevaluasi keefektifan dari
solusi tersebut. Ketika sebuah tim mampu untuk mengenali masalah-masalah
yang sering muncul dan menyelesaikannya dengan memberikan solusi yang
tepat maka sebuah tim yang efektif juga akan mampu untuk mengidentifikasikan
kemungkinan-kemungkinan masalah-masalah yang akan muncul dikemudian
hari serta mampu memberikan solusi yang inovatif.
9. Efektivitas interpersonal
Anggota tim harus mampu untuk berinteraksi dengan anggota tim lainnya secara
efektif sehingga membuat efektifitas interpersonal anggota tim menjadi
meningkat. Efektifitas interpersonal dapat diukur dengan menggabungkan
konsekuensi tindakan anggota kelompok dengan tujuan anggota tim. Kecocokan
antara tujuan anggota tim dan konsekuensi dari peningkatan perilaku mereka,
maka membuat interpersonal efektifitas anggota tim juga juga menjadi meningkat.
6. Manfaat dan Fungsi Tim Kerja
Richard Y. Chang & Mark J. Curtin (1998) menyatakan manfaat tim bagi individu dan tim
bagi organisasi, yaitu:
1. Manfaat tim bagi individu
1) Pekerjaan lebih bervariasi
2) Lebih banyak kebebasan untuk membuat dan menindaklanjuti keputusan
yang benar
3) Meningkatkan kesempatan untuk mempelajari keahlian baru
2. Manfaat tim bagi organisasi

1) Meningkatkan komitmen terhadap keputusan yang diambil
2) Meningkatkan produktivitas tim kerja
3) Lebih fleksibel dalam operasional kerja
4) Meningkatkan rasa tanggungjawab
7. Kekuatan Kerja Tim
Team (tim) atau TEAM, bukanlah sekedar kata, melainkan juga merupakan
akronim untuk suatu kebenaran yang dahsyat, yaitu Together Everyone Achieve More.
Konsep dari tim ini terbentuk dari kata yang sering kita dengar berulang kali, yaitu
sinergi. Kata sinergi ini berasal dari bahasa Yunani sunergos, ”sun” berarti bersama dan
”ergon” berarti bekerja. Sinergi berarti interaksi dari dua individu atau lebih atau
kekuatan yang memungkinkan kombinasi tenaga mereka melebihi jumlah tenaga
individu mereka.
Kerja tim adalah kemampuan untuk bekerja sama menuju satu visi yang sama,
kemampuan mengarahkan pencapaian individu ke arah sasaran organisasi. Itulah
rangsangan yang memungkinkan orang biasa mencapai hasil yang luar biasa. Dalam
kajian perilaku organisasi (organizational behavior), terdapat demonstrasi tentang
bagaimana kerjasama dapat menghasilkan suatu hal yang luar biasa. Beberapa orang
disuruh untuk membentuk beberapa tim yang beranggotakan lima orang, di mana setiap
orang belum memiliki kemampuan untuk menganalisis bidang kerjasama tim dengan
baik. Setiap orang dalam kelompok diminta untuk memberikan peringkat terhadap suatu
hal berdasarkan urutan dari hal yang dianggap paling penting, sampai tidak penting.
Setelah itu setiap pendapat dari setiap orang digabungkan untuk mendapatkan rata-rata
peringkat untuk setiap kelompok. Apa yang terjadi? Kesimpulan rata-rata kelompok
mendekati jawaban yang telah diberikan. Bahkan apabila hasil dari setiap kelompok
disatukan dan diambil rata-ratanya, maka penilaian dari setiap kelompok hampir sama
dengan penilaian para ahli di bidang tersebut.
Demonstrasi nyata lain mengenai prinsip sinergi dapat kita lihat pula dalam
kontes kuda penghela dalam kontes kuda penghela di suatu pekan raya kota. Kuda
juara dalam kontes tersebut mampu menghela gerobak seberat 2.250 kilogram. Juara
kedua sanggup menarik beban sebesar 2.000 kilogram. Dalam teori, berarti kedua kuda
tersebut secara bersama-sama harus mampu menggerakkan maksimum 4.250
kilogram. Untuk uji coba teori tersebut, pemilik kedua kuda memadukan kedua kuda dan
membebaninya dengan gerobak. Semua orang yang melihat terperangah. Kedua kuda
tersebut mampu menarik beban seberat 6.000 kilogram, atau 1.750 kilogram lebih berat
dibanding jumlah upaya yang mampu mereka lakukan sendiri-sendiri. Sinergi dapat
dipakai untuk menyatukan tenaga individu, menutup keterbatasan individu, untuk
menggandakan upaya individu, supaya sasaran yang lebih banyak dan lebih besar
dapat dicapai.
I. Referensi:
1. Astra Human resources Management. 2001. Jakarta, Astra International
Group.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Manajemen Kualitas Suatu

Proyek
13
Komputer
Abstract Kompetensi
Kualitas suatu proyek menjadi Mahasiswa mengenal, memahami
elemen yang penting di dalam suatu dan memiliki kemampuan membuat
proyek agar produk yang dihasilkan suatu proyek dengan kualitas yang
berkualitas baik
1. Manajemen Kualitas Proyek
1. Manajemen Mutu Proyek
Proyek Manajemen Mutu mencakup proses yang diperlukan untuk memastikan

bahwa proyek akan memenuhi kebutuhan yang dilakukan. Ini mencakup "semua aktivitas
dari fungsi manajemen keseluruhan yang menentukan kebijakan mutu, tujuan, dan
tanggung jawab dan menerapkan mereka dengan cara seperti perencanaan mutu, jaminan
mutu, pengendalian mutu, dan peningkatan kualitas, dalam sistem mutu".
1. Kualitas Perencanaan-mengidentifikasi standar kualitas yang relevan dengan
proyek dan menentukan bagaimana memuaskan mereka.
2. Penjaminan Kualitas-mengevaluasi kinerja proyek secara keseluruhan secara
teratur untuk memberikan keyakinan bahwa proyek akan memenuhi standar
kualitas yang relevan.
3. Kontrol kualitas (Quality Control) - pemantauan proyek tertentu untuk menentukan
apakah mereka sesuai dengan standar mutu yang relevan dan mengidentifikasi
cara untuk menghilangkan penyebab kinerja yang tidak memuaskan.
Proses ini berinteraksi satu sama lain dan dengan proses di bidang pengetahuan
lain juga. Setiap proses mungkin melibatkan usaha dari satu atau lebih individu atau
kelompok individu, berdasarkan kebutuhan proyek. Setiap proses umumnya terjadi
setidaknya sekali dalam setiap tahapan proyek. Meskipun proses yang disajikan di sini
sebagai elemen diskrit dengan antarmuka welldefined, dalam praktiknya mereka mungkin
tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini.
Pendekatan dasar untuk manajemen mutu yang dijelaskan dalam bagian ini
dimaksudkan agar kompatibel dengan Organisasi Internasional untuk Standarisasi (ISO),
sebagaimana tercantum dalam ISO 9000 dan 10000 serangkaian standar dan pedoman.
Pendekatan umum juga harus kompatibel dengan a) pendekatan eksklusif untuk
manajemen mutu seperti yang direkomendasikan oleh Deming, Juran, Crosby, dan lain-lain,
dan b) pendekatan Nonproprietary seperti Total Quality Management (TQM), Continuous
Improvement, dan lain-lain. Proyek manajemen mutu harus mengatasi baik manajemen
proyek dan hasil proyek. Produk istilah generik yang sering digunakan, dalam kualitas
literatur tentang, untuk merujuk ke baik barang dan jasa. Kegagalan untuk memenuhi
persyaratan kualitas dalam dimensi baik dapat memiliki konsekuensi negatif yang serius
untuk setiap atau semua stakeholder proyek.
Memenuhi kebutuhan pelanggan dengan lembur tim proyek bisa menghasilkan
konsekuensi negatif dalam bentuk gesekan karyawan meningkat. Rapat tujuan proyek
jadwal oleh kesibukan pemeriksaan kualitas direncanakan dapat menghasilkan
konsekuensi negatif ketika kesalahan tidak terdeteksi.
Kualitas adalah "totalitas karakteristik suatu entitas yang menanggung pada
kemampuannya untuk memuaskan kebutuhan lain atau tersirat" (2). Lain kebutuhan dan
tersirat adalah input untuk kebutuhan proyek berkembang. Sebuah aspek penting dari
manajemen mutu dalam konteks proyek ini adalah kebutuhan untuk mengubah kebutuhan
tersirat menjadi persyaratan melalui cakupan manajemen proyek.
Tim manajemen proyek harus berhati-hati untuk tidak membingungkan antara
kualitas dengan grade. Grade adalah "sebuah kategori atau peringkat yang diberikan
kepada badan usaha yang memiliki penggunaan fungsional yang sama tetapi karakteristik
teknis yang berbeda" (3). Rendahnya kualitas selalu masalah, kadar rendah mungkin tidak.
Sebagai contoh, sebuah produk perangkat lunak mungkin akan berkualitas tinggi (tidak ada
bug yang jelas, manual dibaca) dan kadar rendah (sejumlah fitur yang terbatas), atau
berkualitas rendah (banyak bug, kurang terorganisir dokumentasi pengguna) dan tinggi
grade (fitur yang banyak) . Menentukan dan memberikan tingkat yang dibutuhkan baik
kualitas dan kelas merupakan tanggung jawab dari manajer proyek dan tim manajemen
proyek.
Tim manajemen proyek juga harus menyadari bahwa manajemen mutu modern
melengkapi manajemen proyek. Sebagai contoh, kedua disiplin menyadari pentingnya:
1. Kepuasan pelanggan-pengertian, mengelola, dan mempengaruhi kebutuhan
sehingga harapan pelanggan terpenuhi. Hal ini membutuhkan kombinasi dari
kesesuaian dengan persyaratan (proyek harus menghasilkan apa yang dikatakan itu
akan menghasilkan) dan kesesuaian untuk digunakan (produk atau jasa yang
dihasilkan harus memenuhi kebutuhan nyata).
2. Pencegahan ataau inspeksi atas biaya mencegah kesalahan yang terlalu jauh lebih
sedikit daripada biaya mengoreksi mereka, seperti diungkapkan oleh inspeksi.
3. Tanggung jawab manajemen-keberhasilan membutuhkan partisipasi dari semua
anggota tim, tetapi tetap tanggung jawab manajemen untuk menyediakan sumber
daya yang dibutuhkan untuk sukses
4. Proses dalam fase-siklus yang berulang-rencana do-check-tindakan yang dijelaskan
oleh Deming dan lain-lain sangat mirip dengan kombinasi fase dan proses dibahas
dalam Bab 3, Manajemen Proses suatu Proyek. Selain itu, inisiatif peningkatan mutu
dilakukan oleh organisasi khusus (misalnya, TQM, Continuous Improvement, dan
lain-lain) dapat meningkatkan kualitas manajemen proyek serta kualitas produk
proyek. Namun, ada perbedaan penting yang tim manajemen proyek harus
menyadari-sifat sementara proyek berarti bahwa investasi dalam peningkatan
kualitas produk, terutama cacat pencegahan dan penilaian, sering harus ditanggung
oleh organisasi melakukan sejak proyek mungkin tidak cukup lama untuk menuai
hasilnya terakhir.
2. Perencanaan Kualitas
Perencanaan kualitas yang melibatkan mengidentifikasi standar kualitas yang

relevan dengan proyek dan menentukan bagaimana memuaskan mereka. Ini adalah salah
satu proses memfasilitasi kunci dalam perencanaan proyek dan harus dilakukan secara
teratur dan secara paralel dengan proses perencanaan proyek lainnya. Sebagai contoh,
perubahan dalam produk dari proyek yang diperlukan untuk memenuhi standar kualitas
diidentifikasi mungkin memerlukan penyesuaian biaya atau jadwal, atau kualitas produk
yang diinginkan mungkin memerlukan analisis risiko rinci tentang masalah diidentifikasi.
Sebelum pembangunan Seri ISO 9000, kegiatan digambarkan di sini sebagai perencanaan
mutu secara luas didiskusikan sebagai bagian dari jaminan mutu.
Teknik-teknik perencanaan mutu dibahas di sini adalah yang paling sering digunakan pada
proyek. Ada banyak orang lain yang mungkin berguna pada proyek-proyek tertentu atau dalam
beberapa area aplikasi. Tim proyek juga harus menyadari salah satu prinsip dasar mutu modern
kualitas manajemen direncanakan dalam, tidak diperiksa masuk.
1. Masukan untuk Perencanaan Kualitas

• Kualitas kebijakan. Kebijakan mutu adalah "keseluruhan tujuan dan arah
organisasi dalam hal mutu, sebagaimana dinyatakan secara resmi oleh
manajemen puncak". Kebijakan mutu organisasi melakukan sering dapat
diadopsi "sebagaimana adanya" untuk digunakan oleh proyek ini. Namun, jika
organisasi melakukan tidak memiliki kebijakan mutu formal, atau jika proyek
tersebut melibatkan beberapa organisasi yang melakukan (seperti dengan
perusahaan patungan), maka tim manajemen proyek akan perlu untuk
mengembangkan kebijakan mutu untuk proyek tersebut. Terlepas dari asal
kebijakan mutu, tim manajemen proyek bertanggung jawab untuk memastikan
bahwa para stakeholder proyek sepenuhnya menyadari hal itu.
• Lingkup pernyataan. Pernyataan lingkup adalah masukan kunci untuk perencanaan
mutu karena kiriman dokumen proyek besar, serta tujuan proyek yang berfungsi untuk
menetapkan persyaratan stakeholder penting.
• Produk deskripsi. Meskipun unsur-unsur deskripsi produk dapat diwujudkan dalam
pernyataan ruang lingkup, deskripsi produk seringkali akan berisikan detil tentang
masalah teknis dan masalah lainnya yang dapat mempengaruhi kualitas
perencanaan.
• Standar dan peraturan. Tim manajemen proyek harus mempertimbangkan standar
aplikasi setiap daerah khusus atau peraturan yang dapat mempengaruhi proyek.
• Proses output lainnya. Selain pernyataan lingkup dan deskripsi produk, proses di
daerah pengetahuan lainnya dapat menghasilkan output yang harus dianggap sebagai
bagian dari perencanaan mutu. Sebagai contoh, pengadaan perencanaan dapat
mengidentifikasi persyaratan kualitas kontraktor yang harus tercermin dalam rencana
manajemen mutu secara keseluruhan.
2. Alat dan Teknik Perencanaan Kualitas

• Analisis manfaat/biaya. Proses perencanaan kualitas harus mempertimbangkan
pengorbanan biaya manfaat. Manfaat utama dari memenuhi persyaratan kualitas
pengerjaan ulang kurang, yang berarti produktivitas yang lebih tinggi, biaya lebih
rendah, dan kepuasan stakeholder meningkat. Biaya utama memenuhi persyaratan
kualitas adalah biaya yang terkait dengan kegiatan manajemen kualitas proyek. Jelas
sekali dari disiplin manajemen mutu yang manfaat lebih besar daripada biaya.
• Pembandingan. Pembandingan melibatkan membandingkan praktek proyek aktual
atau yang direncanakan untuk orang-orang dari proyek lain untuk menghasilkan ide-
ide untuk perbaikan dan untuk menyediakan sebuah standar yang digunakan untuk
mengukur kinerja. Proyek-proyek lain mungkin berada dalam organisasi untuk
melakukan atau di luar itu, dan mungkin dalam wilayah aplikasi yang sama atau di
negara lain.
• Flowchart. Sebuah diagram alir adalah setiap diagram yang
menunjukkan bagaimana berbagai elemen dari suatu sistem
berkaitan. 1. Flowchart teknik yang umum digunakan dalam
manajemen mutu meliputi:
➢ Diagram penyebab-akibat, juga disebut diagram Ishikawa atau diagram tulang
ikan, yang menggambarkan bagaimana berbagai faktor yang mungkin terkait
dengan potensi masalah atau efek. Gambar 8-2 adalah contoh umum diagram
sebab-akibat.
➢ Sistem atau proses flow chart, yang menunjukkan bagaimana berbagai
elemen dari suatu sistem saling berhubungan. Gambar 8-3 adalah contoh
diagram alir proses untuk review desain.
➢ Flowchart dapat membantu tim proyek mengantisipasi apa dan dimana
masalah kualitas mungkin terjadi, dan dengan demikian dapat membantu
mengembangkan pendekatan untuk memperbaiki masalah tersebut.
• Desain eksperimen. Desain eksperimen adalah metode statistik yang membantu
mengidentifikasi faktor yang mungkin mempengaruhi variabel tertentu. Teknik ini
paling sering diterapkan pada produk dari proyek (misalnya, desainer otomotif
mungkin ingin menentukan kombinasi suspensi dan ban akan menghasilkan
karakteristik perjalanan paling diinginkan dengan biaya yang wajar). Namun, juga
dapat diterapkan untuk proyek masalah manajemen, seperti pengorbanan biaya dan
jadwal. Misalnya, insinyur senior akan biaya lebih dari insinyur junior, tetapi juga dapat
diharapkan untuk menyelesaikan pekerjaan yang ditugaskan dalam waktu kurang.
Sebuah "percobaan" dirancang tepat (dalam hal ini, komputasi biaya proyek dan
jangka waktu untuk berbagai kombinasi insinyur senior dan junior) sering akan
memungkinkan penentuan solusi optimal dari sejumlah kasus yang relatif terbatas.
• Biaya kualitas. Biaya kualitas mengacu pada biaya total dari semua upaya untuk
mencapai produk/kualitas layanan, dan mencakup semua bekerja untuk memastikan
kesesuaian dengan persyaratan, serta semua karya yang dihasilkan dari
ketidaksesuaian dengan kebutuhan. Ada tiga jenis biaya yang terjadi: biaya
pencegahan, biaya penilaian, dan biaya kegagalan, di mana yang terakhir ini dipecah
menjadi biaya internal dan eksternal.
3. Keluaran dari Kualitas Perencanaan

• Rencana pengelolaan kualitas. Rencana manajemen mutu harus menjelaskan
bagaimana tim manajemen proyek akan menerapkan kebijakan kualitasnya. Dalam
ISO 9000 istilah, harus menjelaskan sistem kualitas proyek: "struktur organisasi,
tanggung jawab, prosedur, proses, dan sumber daya yang dibutuhkan untuk
menerapkan manajemen mutu". Rencana manajemen mutu memberikan masukan
terhadap rencana proyek secara keseluruhan dan harus ditujukan pada pengendalian
mutu, jaminan mutu, dan peningkatan kualitas proyek. Rencana manajemen mutu
dapat formal maupun informal, sangat rinci, atau luas berbingkai,
berdasarkan persyaratan proyek.
• Operasional definisi. Definisi operasional menjelaskan, dalam hal yang sangat spesifik,
apa sesuatu itu dan bagaimana ia diukur oleh proses kontrol kualitas. Sebagai contoh,
tidak cukup untuk mengatakan bahwa pertemuan tanggal jadwal yang direncanakan
adalah ukuran kualitas manajemen, tim manajemen proyek juga harus menunjukkan
apakah setiap kegiatan harus mulai tepat waktu atau hanya selesai tepat waktu;
apakah aktivitas individu akan diukur, atau hanya deliverables tertentu, dan jika
demikian, yang mana. definisi operasional juga disebut metrik di beberapa area
aplikasi.
• Daftar pembanding. Checklist adalah alat terstruktur, biasanya unsur tertentu,
digunakan untuk memverifikasi bahwa satu set langkah yang diperlukan telah
dilakukan. Daftarpembanding mungkin sederhana atau kompleks. Mereka biasanya
diungkapkan sebagai imperatif ("Lakukan ini!") Atau interrogatories ("Apakah Anda
melakukan ini?"). Banyak organisasi telah daftar standar tersedia untuk memastikan
konsistensi dalam tugas-tugas sering dilakukan. Di beberapa daerah aplikasi, daftar
juga tersedia dari asosiasi profesional atau penyedia layanan komersial.
• Masukan pada proses lainnya. Proses perencanaan mutu dapat
mengidentifikasi kebutuhan untuk kegiatan lebih lanjut di daerah lain.
3. Penjaminan Kualitas
Jaminan Kualitas adalah semua kegiatan yang terencana dan sistematis diterapkan
dalam sistem mutu untuk menyediakan keyakinan bahwa proyek itu akan memenuhi
standar mutu yang relevan. Hal ini harus dilakukan di seluruh proyek. Sebelum
pembangunan Seri ISO 9000, kegiatan yang diuraikan di bawah kualitas perencanaan
secara luas sebagai bagian dari jaminan kualitas.
Jaminan Kualitas sering disediakan oleh Departemen Jaminan Kualitas atau suatu unit
organisasi, tetapi tidak harus. Jaminan dapat diberikan kepada tim manajemen proyek dan
pengelolaan organisasi bermasalah (jaminan mutu internal), atau mungkin diberikan kepada
pelanggan dan orang lain tidak secara aktif terlibat dalam pekerjaan proyek (jaminan mutu
eksternal).
1. Masukan untuk Jaminan Kualitas

• Rencana manajemen kualitas.
• Hasil pengukuran pengendalian kualitas. Kontrol kualitas adalah pengukuran catatan
pengujian kontrol kualitas dan pengukuran dalam format untuk perbandingan dan analisis.
• Definisi operasional.
2. Alat dan Teknik untuk Penjaminan Kualitas

• Perencanaan kualitas alat dan teknik.
• Quality audit. Suatu audit mutu adalah review kegiatan terstruktur lainnya manajemen
mutu. Tujuan dari audit kualitas adalah untuk mengidentifikasi pelajaran yang dapat
memperbaiki kinerja proyek ini atau proyek lain dalam organisasi pertunjukan. Kualitas
audit dapat dijadwalkan secara acak, dan mereka dapat dilakukan dengan benar terlatih
dalam-rumah auditor atau oleh pihak ketiga, seperti lembaga pendaftaran sistem kualitas.
3. Hasil dari Jaminan Kualitas
• Peningkatan kualitas. Peningkatan kualitas termasuk mengambil tindakan untuk
meningkatkan efektivitas dan efisiensi dari proyek untuk memberikan manfaat tambahan
bagi para pemangku kepentingan proyek. Dalam kebanyakan kasus, peningkatan kualitas
pelaksanaan akan membutuhkan persiapan permintaan perubahan atau mengambil
tindakan korektif, dan akan ditangani sesuai dengan prosedur pengendalian perubahan yang
terintegrasi.
4. Pengendalian Mutu (quality control)
Kendali mutu melibatkan hasil pemantauan proyek spesifik untuk menentukan

apakah mereka memenuhi standar mutu yang relevan, dan mengidentifikasi cara untuk
menghilangkan penyebab hasil yang tidak memuaskan. Ini harus dilakukan selama proyek.
hasil proyek meliputi hasil produk keduanya, seperti kiriman, dan hasil manajemen proyek,
seperti biaya dan kinerja jadwal. Kontrol kualitas sering dilakukan oleh Departemen Quality
Control atau yang serupa pada unit organisasi, tetapi tidak harus.
Tim manajemen proyek harus memiliki pengetahuan tentang pengendalian kualitas
statistik, terutama sampling dan probabilitas, untuk membantu mengevaluasi output kontrol
kualitas. Di antara mata pelajaran lainnya, tim mungkin berguna untuk mengetahui
perbedaan antara:
• Pencegahan (kesalahan menjaga dari proses) dan pemeriksaan (kesalahan menjaga dari
tangan pelanggan).
• Atribut Sampling (hasilnya sesuai, atau tidak) dan sampling variabel (hasilnya adalah nilai
pada skala kontinu yang mengukur tingkat kesesuaian).
• Khusus menyebabkan (kejadian luar biasa) dan menyebabkan acak (variasi proses normal).
• Toleransi (hasilnya dapat diterima jika berada dalam kisaran yang ditentukan oleh toleransi)
dan batas kontrol (proses ini dalam kendali jika hasilnya jatuh dalam batas-batas kontrol).
I. Referensi:
1. A Guide to the Project Management Body of Knowledge.
Group.
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Analisa Waktu (SPA dan SPL)
14
Komputer
Abstract Kompetensi
Analisa waktu diperlukan agar Mahasiswa mengenal, memahami
proyek perangkat lunak yang akan dan memiliki kemampuan untuk
dijalankan sesuai dengan waktu menganalisa waktu yang dibutuhkan
yang telah ditentukan dan tidak di dalam sebuah proyek perangkat
mengalami keterlambatan lunak
1. Analisa Waktu
1. Pendahuluan
Alasan dilakukan analisa waktu dalam penerapan network planning pada

penyelenggaraan proyek, antara lain:
1. Analisa waktu merupakan langkah pertama sebelum melakukan analisa lebih
lanjut yaitu analisa sumber daya dan analisa biaya.
2. Untuk melakukan analisa waktu pada tahap perencanaan (disain model), data
yang diperlukan relatif tidak terlalu sukar penyediaannya.
3. Untuk melakukan analisa waktu pada tahap pemakaian (operasi) pengumpulan
dan pengolahan datanya relatif lebih mudah.
Yang dimaksud dengan analisa waktu dalam penyelenggaraan proyek adalah

mempelajari tingkah laku pelaksanaan kegiatan selama penyelenggaraan proyek.
Dengan analisa waktu ini diharapkan bisa ditetapkan skala prioritas pada tiap tahap, dan
bila terjadi perubahan waktu pelaksanaan kegiatan, segera bisa diperkirakan akibat-
akibatnya sehingga keputusan yang diperlukan dapat segera diambil.
Ada beberapa tujuan analisa waktu, antara lain:
1. Dengan analisa waktu memungkinkan disesuaikannya umur perkiraan proyek
dengan umur proyek yang direncanakan dengan cara yang rasional, sepanjang
masih memungkinkan.
2. Umur rencana proyek dapat ditentukan lamanya sesuai dengan tingkat
probabilitas yang dikehendaki.
3. Untuk menekan tingkat ketidakpastian dalam waktu pelaksanaan selama
penyelenggaraan proyek, dengan demikian diharapkan timing yang tepat bisa
ditentukan. Dan dengan menentukan timing yang tepat analisa sumber daya dan
analisa biaya, segera bisa dilakukan.
4. Cara kerja yang efisien bisa diselenggarakan sehingga waktu penyelenggaraan
menjadi efisien pula.
2. Faktor Penentu Lama Kegiatan
Lama kegiatan adalah jangka waktu yang dibutuhkan untuk menyelesaikan
kegiatan yang bersangkutan, yaitu mulai dari saat awal pada saat kegiatan mulai
dikerjakan sampai dengan saat akhir pada saat kegiatan selesai dikerjakan. Adapun
satuan untuk mengukur lama kegiatan tergantung dari macam kegiatannya, bisa dalam
detik, menit, jam atau hari, dan sebagainya.
Ada 2 faktor penentu lama kegiatan, yaitu:
1. Faktor teknis, antara lain ; volume pekerjaan, sumber daya, ruangan, jam kerja
per hari, dan sebagainya.
2. Faktor non teknis, antara lain ; banyaknya hari kerja dalam seminggu, banyaknya
hari libur, cuaca, dan sebagainya.
3. Cara Menentukan Lama Kegiatan
A. Cara rata-rata
Cara rata-rata relatif mudah namun kurang tepat atau kurang memadai
dikarenakan menyamaratakan tiap kasus meskipun pada kenyataannya masing-
masing kasus terdiri dari tiap kasus yang berbeda-beda.
Contoh:
Diketahui:
Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 6 kasus
(alternatif), sebagai berikut:
KASUS LAMA KEGIATAN (HARI)
1 10
2 11
3 12
4 13
5 14
6 15
Diminta:
Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas.
Jawab:
Kasus Lama Kegiatan (Hari) Jumlah Kejadian
1 10 1
2 11 1
3 12 1
4 13 1
5 14 1
6 15 1
Jumlah 75 6
LPER = 75 / 6 = 12.5 hari
B. Cara pembobotan
Cara pembobotan relatif lebih tepat dibandingkan cara rata-rata, karena
memperhatikan jumlah dan peran kejadian tiap kasus. Namun cara ini sukar
karena perlu data yang relatif banyak.
Contoh:
Diketahui:
dengan masing-masing kejadian, sebagai berikut:
Kasus Lama Kegiatan (Hari) Jumlah Kejadian
1 10 100
2 11 200
3 12 350
4 13 500
5 14 250
6 15 100
Diminta:
Jawab:
Kasus Lama Kegiatan Jumlah Bobot
(Hari) Kejadian
1 10 100 10 * 100 = 1.000
2 11 200 11 * 200 = 2.200
3 12 350 12 * 350 = 4.200
4 13 500 13 * 500 = 6.500
5 14 250 14 * 250 = 3.500
6 15 100 15 * 100 = 1.500
1.500 18.900
LPER = Jumlah Bobot = 18.900 = 12.6 hari

Jumlah Peristiwa 1.500
C. Cara lintasan kritis

Cara lintasan kritis merupakan cara yang memiliki keuntungan dari kedua cara
tersebut diatas, karena membutuhkan data relatif lebih sedikit tetapi tetap
memperhatikan peran kejadian tiap kasus.
Pertimbangan terakhir dalam penentuan cara yang akan dipakai, bergantung
pada tersedianya data dan tingkat kebenaran data yang tersedia tersebut. Lama
kegiatan hasil dari ketiga cara tersebut masing-masing disebut lama kegiatan
perkiraan (LPER) dan masing-masing dianggap mempunyai kemungkinan
berhasil 50% dan mempunyai kemungkinan gagal 50%.
Contoh:
Diketahui:
(tidak mungkin lebih atau kurang dari 3 kasus), sebagai berikut ;
Kasus Lama Kegiatan Jumlah Kejadian
(Hari)
1 (LO) 10 LO = Lama kegiatan optimis
2 (LM) 13 LM = Lama kegiatan most likely (yang
3 (LP) 15 paling sering terjadi)
LP = Lama kegiatan pesimis
Diminta:
Jawab ;
LPER = 1 * LO + 4 * LM + 1 * LP
6
LPER = 1 * 10 + 4 * 13 + 1 * 15 = 12.8
6
2. Saat Paling Awal (SPA)
Saat paling awal (SPA) maksudnya adalah saat paling awal suatu peristiwa
mungkin terjadi, dan tidak mungkin terjadi sebelumnya. Penentuan SPA ini bertujuan
untuk mengetahui saat paling awal mulai melaksanakan kegiatan-kegiatan yang keluar
dari peristiwa yang bersangkutan.
Ada beberapa syarat yang harus dipenuhi untuk menentukan atau menghitung
saat paling awal semua peristiwa-peristiwa pada sebuah network diagram, antara lain;
1. Network diagram yang tepat telah tersedia.
2. Nomor-nomor peristiwa ditetapkan menurut atau memenuhi persyaratan yaitu
peristiwa awal network diagram diberi nomor 1, peristiwa akhir diberi nomor
maksimum yang sama dengan banyaknya peristiwa yang ada di network yang
bersangkutan.
3. Semua kegiatan yang ada dalam network diagram telah ditetapkan lama
kegiatan perkiraan.
Secara formatif untuk menentukan saat paling awal suatu peristiwa adalah
sebagai berikut:
1. Sebuah kegiatan menuju ke sebuah peristiwa
Keterangan ;
SPA j = SPA I + L
X = Kegiatan
j = Peristiwa akhir kegiatan X
i = Peristiwa awal kegiatan X
L = Lama kegiatan X yang diperkirakan
SPA i = Saat paling awal peristiwa awal
SPA j = Saat paling awal peristiwa akhir
2. Untuk beberapa kegiatan menuju ke sebuah peristiwa ditentukan waktu paling
awal yang maksimum.
SPA j = maksimum (SPA I + L)

Prosedur untuk menghitung saat paling awal dalam sebuah network diagram
adalah sebagai berikut:
1) Hitung atau tentukan saat paling awal dari peristiwa-peristiwa mulai dari
nomor 1 berturut-turut sampai dengan nomor maksimum.
2) Pada posisi awal SPA (1) = 0
3) Pada setiap posisi j, SPA j = max (SPA i + L), untuk setiap posisi atau
peristiwa i yang dihubungkan langsung oleh satu kegiatan dengan posisi j,
contoh:
Keterangan ;
Pada posisi atau peristiwa 3 menuju posisi 6 terdapat jumlah waktu paling awal
lebih maksimum dibandingkan dengan posisi atau peristiwa 4 menuju posisi 6,
maka SPA j pada posisi atau peristiwa 6 adalah 14.
3. Saat Paling Lambat (SPL)
Saat paling lambat (SPL) adalah saat paling lambat suatu peristiwa boleh terjadi,
dan tidak boleh sesudahnya (meskipun itu mungkin) sehingga proyek mungkin selesai
pada waktu yang telah direncanakan.
Adapun syarat yang harus dipenuhi agar bisa menentukan atau menghitung saat
paling lambat (SPL) semua peristiwa-peristiwa pada sebuah network diagram adalah:
• Telah tersedianya network diagram yang tepat.
• Telah dihitung saat paling awal (SPA) dari posisi atau peristiwa awal (nomor
1) sampai dengan posisi akhir pada network diagram tersebut.
• Jika hanya ada sebuah kegiatan keluar dari sebuah peristiwa, maka SPL
(saat paling lambat) peristiwa tersebut adalah saat paling lambat mulainya
kegiatan tersebut.
Secara formulatif untuk menentukan saat paling lambat suatu peristiwa adalah
sebagai berikut:
1. Untuk sebuah kegiatan keluar dari sebuah peristiwa
Keterangan ;
SPA i = SPA j - L
X = Kegiatan
j = Peristiwa akhir kegiatan X
i = Peristiwa awal kegiatan X
L = Lama kegiatan X yang diperkirakan
SPA i = Saat paling awal peristiwa awal
SPA j = Saat paling awal peristiwa akhir
SPL i = Saat paling lambat peristiwa awal
SPL j = Saat paling lambat peristiwa akhir
2. Untuk beberapa kegiatan keluar dari sebuah peristiwa ditentukan waktu paling
lambat yang minimum
SPL i = minimum (SPL j – L)
Prosedur untuk menghitung saat paling awal dalam sebuah network diagram
adalah sebagai berikut:
1) Hitung atau tentukan saat paling lambat (SPL) dari peristiwa-peristiwa mulai
dari nomor maksimal kemudian mundur berturut-turut sampai dengan posisi
awal.
2) Saat paling lambat (SPL) sama dengan Saat paling awal peristiwa akhir
(maksimal), SPL j = SPA j
3) Pada setiap posisi i, SPL i = min (SPL j – L), untuk setiap posisi atau
peristiwa j yang dihubungkan langsung oleh satu kegiatan dengan posisi I
4) Pada posisi awal SPL 1 = 0
Sedangkan Umur Proyek ditentukan oleh saat paling awal kegiatan yang paling
awal mulai dikerjakan, yaitu SPA peristiwa awal network dengan dan ditentukan oleh
saat paling awal kegiatan akhir yang paling akhir selesai, yaitu SPA peristiwa akhir
network diagram dengan syarat SPA awal network diagram sama dengan nol, contoh:
Keterangan ;
1) Pada posisi atau peristiwa posisi 2 menuju 3, maka SPL 2 = 9 – 5 = 4
2) Pada posisi atau peristiwa dari posisi 3 menuju posisi 4 lebih kecil jumlah waktu
lambatnya (7 – 3 = 4) dibandingkan posisi atau peristiwa dari posisi 3 menuju posisi
6 (14 – 9 = 5), sehingga pada kasus tersebut SPL i pada posisi atau peristiwa 3
diambil waktu yang minimum adalah 4.
I. Referensi:
1. A Guide to the Project Management Body of Knowledge.

Manajemen Proyek Perangkat Lunak TI PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Manajemen Proyek Perangkat Lunak TI PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

MODUL PERKULIAHAN

Pengantar Manajemen Proyek

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan,

Gambar 1.1 Triple Constraint

3. Pengertian Perangkat Lunak

Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

4. Pengertian Manajemen Proyek

Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan,

3. Sistem Manajemen Proyek

5. Daur Hidup Manajemen Proyek

Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran

Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan

Model Waterfall mempunyai beberapa tahapan sebagai berikut:

8. Sembilan Area Pengetahuan Manajemen Proyek

Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen

Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

Pengantar Manajemen Proyek

Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan,

Gambar 1.1 Triple Constraint

3. Pengertian Perangkat Lunak

Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

4. Pengertian Manajemen Proyek

Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan,

3. Sistem Manajemen Proyek

5. Daur Hidup Manajemen Proyek

Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran

Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan

Model Waterfall mempunyai beberapa tahapan sebagai berikut:

8. Sembilan Area Pengetahuan Manajemen Proyek

Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen

Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

Proyek Software adalah manajemen proyek yang berfokus hanya pada

Gambar 3.1 Tahapan-tahapan Proyek

Closing: setelah proyek diselesaikan project manager akan menutup proyek

2. Faktor-faktor yang mempengaruhi perkiraan biaya

Beberapa faktor yang mempengaruhi terhadap perkiraan biaya pembuatan

Faktor-faktor utama yang mempengaruhi biaya perangkat lunak:

d. Waktu yang tersedia

e. Keandalan yang diperlukan

1. Bagi Project Manager

Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan

Vision and Scope

Statement of Work adalah dokumen yang menggambarkan semua produk

Gambar 3.2. Dokumen Individual Preparation

Gambar 3.4 Estimasi awal

Gambar 3.5 Estimasi akhir

Jika WBS mengalami revisi (setelah melakukan estimasi, misalnya), misalnya

4. Work Breakdown Structure

Tetapi tidak mencantumkan:

Tiap pekerjaan ditunjukkan dengan kotak, sedangkan

Risk plan adalah daftar resiko/masalah yang mungkin terjadi

Gambar 3.6 Risk Plan

1. Nyatakan masalah yang akan diselesaikan secara tegas, termasuk di

2015 Manajemen Proyek Perangkat Pusat Bahan Ajar dan eLearning

B. Pengembangan Strategi Solusi

C. Perencanaan Proses Pengembangan

2015 Manajemen Proyek Perangkat Pusat Bahan Ajar dan eLearning

• Subfase perencanaan menghasilkan dua produk : System Definition dan Poject

2015 Manajemen Proyek Perangkat Lunak

• Fase perancangan melakukan identifikasi terhadap komponen perangkat lunak

Manajemen Proyek Perangkat Lunak Pusat Bahan Ajar dan eLearning

2015 Manajemen Proyek Perangkat Lunak