Uploaded by Siwin Chey

Manajemen-Proyek-Perangkat-Lunak-TI

advertisement
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Pengantar Manajemen Proyek
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
01
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini akan dijelaskan
mengenai dasar manajemen
proyek
Mahasiswa
memiliki
gambaran
umum tentang isi dari manajemen
proyek perangkat lunak
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
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
2015
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 :
2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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 :
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
5
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Gambar 2.2 Fase Daur Hidup Proyek
(Sumber : Schwalbe, 2006, p55)
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.
2015
7
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek
dengan baik.
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.
2015
Larson, Erick. W. 2000. Project management: the managerial process.
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Pengantar Manajemen Proyek
(Lanjutan)
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
02
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini akan dijelaskan
mengenai dasar manajemen
proyek
Mahasiswa
memiliki
gambaran
umum tentang isi dari manajemen
proyek perangkat lunak
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
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
2015
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 :
2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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 :
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
5
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Gambar 2.2 Fase Daur Hidup Proyek
(Sumber : Schwalbe, 2006, p55)
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.
2015
7
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek
dengan baik.
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.
2015
Larson, Erick. W. 2000. Project management: the managerial process.
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Perencanaan Proyek
Perangkat Lunak
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
03
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini menjelaskan tentang
maksud dari perencanaan proyek
perangkat lunak
Mahasiswa memiliki kemampuan
dalam memulai sebuah proyek
perangkat lunak
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
(Manajemen)
itu
itu
sebuah
berupa
proyek
software
persiapan
perlu
pekerjaan,
dikelola.
Pengelolaan
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
2015
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
delivered
maka
source
estimator
of
instructions)
PM
menurut
Boehm adalah :
aplik asi : 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)
u ti l ity : T D E V = 2. 5 (P M)
•
System : TDEV = 2.4 (PM)
Unt uk
j umlah
bari s
prog ram
60. 000,
k et ig a
prog ram
memerluk an wak t u pengembangan sekitar 18 bulan (tepatnya
TDEV aplikasi : utility : system = 17.9 : 18:3 : 17.4).
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
5
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
7
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 e stimasi 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. Moderat or mere v iew dok umen Vis ion and Scope dan d ok umen dok umen
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
2015
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
11
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
12
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
13
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
14
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
pekerjaan/aktivitas
atau
lain.
work
Contoh:
product
test
plan
yang
tidak
dihasilkan
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.
2015
15
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
16
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
6. Risk Plan
Ris k p la n ad a l ah daf t ar r es ik o/ ma sa l a h ya ng mu ng k i n t e rj a d i
s e l am a pr o yek 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
2015
17
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
18
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Referensi
1.
Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill
2.
Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley
2015
19
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Ma n a j e me n
Pr o ye k
Perangkat Lunak
Perencanaan Proyek
Perangkat Lunak (Lanjutan)
Fakultas
Program Studi
Fakultas Ilmu
Komputer
2015
1
Informatika
Tatap Muka Kode MK
04
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini menjelaskan
tentang maksud dari
perencanaan proyek perangkat
lunak
Mahasiswa
mampu
memahami
mengenai
perencanaan perangkat lunak, mampu memahami
unsur – unsur yang patut diperhitungkan dalam
merencanakan pembuatan perangkat lunak, dan
mampu mengenali metode yang umum digunakan
dalam sebuah perencanaan proyek pengembangan
perangkat lunak.
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
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
3
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id

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
2015
4
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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).
2015
5
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
6
Manajemen Proyek Perangkat Lunak
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
Tim Dosen
Pusat Bahan Ajar dan eLearning
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 :
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
mengimplementasikan,
melakukan
produk,
uji,
merancang
melakukan
review,
produk,
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).
2015
11
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
 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
2015
12
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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

2015
Programer menuliskan source code, debugging, dokumentasi, dan uji unit
13
Manajemen Proyek Perangkat
Lunak Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
 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 analisisperancangan-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
2015
14
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Estimasi Biaya
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
05
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini menjelaskan tentang
perencanaan biaya dalam sebuah
proyek
Mahasiswa
memiliki
kemampuan
untuk menganalisis dan menetapkan
biaya dari sebuah proyek yang akan
dijalankan
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 estimasiestimasi berikutnya.
5. Estimasi biaya dan penjadwalan merupakan 2 aktifitas yang sangat berkaitan
erat.
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
5
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
7
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 :
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
pembengkakan biaya.
2. Mengubah construction method
3. Mengubah durasi proyek (bila memungkinkan)
4. Mengganti pemasok sumber daya yang digunakan
5. Mengubah kebijakan keuangan (pembiayaan)
2015
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
kemungkinan
terjadinya
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.
2015
11
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Manajemen Resiko
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
06
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Pada bab ini menjelaskan tentang
bagaimana mengelola sebuah resiko
di dalam proyek perangkat lunak
Mahasiswa
memiliki
kemampuan
untuk menganalisis dan mengelola
sebuah resiko di dalam proyek
perangkat lunak
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
keseluruhan strategi bisnis bagi perusahaan (resiko strategi)
2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
dengan
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 hatihati 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
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 ?
2015
5
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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?
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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 :
2015
7
•
Apakah peranti manajemen proyek dapat diperoleh?
•
Apakah peranti untuk analisis dan desain dapat diperoleh?
•
Apakah peranti analisis dan desain penyampaian metode sesuai
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 teknikteknik 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
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
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.
2015
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Inisiasi Proyek dan Ruang
Lingkup Manajemen
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
07
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Modul ini berisi materi tentang
penaksiran
proyek,
elemenelemen dasar proyek, aspek
awal, dan proposal awal dan
pendekatan dalam penaksiran
Pada akhir pertemuan ini,
diharapkan mahasiswa memahami
elemen-elemen dasar proyek, cara
melakukan penaksiran proyek,
dan membuat proposal
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
•
Kompleksitas proyek
•
Ukuran proyek
•
Ketidakpastian structural
2
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 kesulitan2015
3
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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. Pendekatanpendekatan
rekayasa
perangkat
evolusioner)
memakai
pandangan
lunak
modern
pengembangan
(seperti
model
yang
interaktif.
proses
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
2015
4
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 aspekaspek lain.
•
Akhirnya lingkungan aspek teknis sampai kepada kegiatan desain
engineering terinci, menghasilkan ce tak biru (blue print) proyek yang
2015
2013
Manajemen Proyek Perangkat Lunak
Tim Dosen
5
5
Manajemen Proyek Perangkat Lunak
Ida Nurhaida, ST., MT.
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
6
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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:
2015
7
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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.
2015
8
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
1.
Sub Masalah 1
1.1.
Task 1
1.1.1
Sub task 1
Kualifikasi
Konsultan
Rate Man
Days
Scheduling
Biaya
Waktu
Nyata
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
Sub sub task 1
Sistem Analis 1
$ 80
20
$ 1.600
Sub sub task 2
Sistem Analis 2
$ 80
20
$ 1.600
1.1.2.
Sub task 2
dst
Total
2015
9
Manajemen Proyek Perangkat Lunak
Tim Dosen
$ xxxxxx
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
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.
2015
10
Manajemen Proyek Perangkat Lunak
Tim Dosen
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Critical Success Factor
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
09
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Modul ini berisi materi tentang
bagaimana penerapan critical
success factor pada sebuah
manajemen proyek perangkat
lunak
Pada akhir pertemuan ini,
diharapkan mahasiswa memahami
penerapan critical success factor
pada sebuah manajemen proyek
perangkat lunak
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
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.
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
3
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
Sesuai Budget L er i ii
Definisi
Proyek disesuaikan pada atau didalam biaya
yang di-kontrak-an
Sesuai Jadwal
Proyek diselesaikan pada atau sebelum
jadwal yang di-kontrak-an
Sesuai Spesifikasi
sesuai dengan
keinginan user
Proyek yang diselesaikan sesuai atau melebihi
semua spesifikasi teknis yang disediakan
Proyek yang diselesaikan sesuai atau
melebihi tujuan fungsional yang diinginkan
tingkat kemampuan staff
pekerja yang
berkualitas tinggi
Proyek yang diselesaikan sesuai atau melebihi
standar tingkat kemampuan pekerja yang
dapat diterima pada semua area
2015
4
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
meminimalisasi
ketidakpuasan konstruksi
proses konstruksi terjadi perselisihan
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
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
Success Factors from the
Literature
Pinto & Belassi
CoolePimo Kerzner Slevin
Wateridge Belout Clarke Daview Muller
&
1996
1987
2005
1995
1998 1999
1989
2002
Tukel
Corposite Understanding
Common Understanding with
stakeholders on Success criteria
Executive Commitment
X
X
X
X
X
X
X
X
X
Organizational adaptability
Communication
X
Project manager selection criteria
project manager leadership /
empowerment
X
X
X
X
X
X
X
X
X
X
Environment
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
X
X
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
X
Success Factors from the
Literature
CoolePinto & Belassi
Pimo Kerzner Slevin
Wateridge Belout Clarke Daview Muller
&
2005
1996
1987
1995
1998 1999
2002
Tukel
1989
Commitment to planning & control
Project mission / common goal /
direction
X
X
X
X
X
X
X
top management support
X
X
client consultation / acceptance
X
monitor performance and feedback
X
personnel / teamwork
X
X
X
Technical task ability
X
X
X
Trouble shooting / risk management
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Project Ownership
Urgency of Project
X
X
X
X
X
Duration and size of Project
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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
2015
7
Critical Success Factor
Technical Performance
Project manager eksperience
Project manager competence
Schedulling
Control system and responsibilities
Monitoring & feed back
Continous involment in the project
Clear Goals
General management support
organize and delegate authorithy
Clear Goals
Goal commitment of project team
adequate project team capability
Planning & control techniques
Task-Social orientation absence of
Project summary
Top Management Support
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Source, year
Ruben & Seeling, 1967
Ruben & Seeling, 1967
Sayles & Chandler, 1971
Sayles & Chandler, 1971
Sayles & Chandler, 1971
Sayles & Chandler, 1971
Sayles & Chandler, 1971
Martin, 1976
Martin, 1976
Martin, 1976
Baker, Murphy, and Fisher, 1983
Baker, Murphy, and Fisher, 1983
Baker, Murphy, and Fisher, 1983
Baker, Murphy, and Fisher, 1983
Baker, Murphy, and Fisher, 1983
Clealand King, 1983
Clealand King, 1983
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
X
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Financial Support
facility support
market intelligent
schedule
manpower and organisation
acquisition
information and communication channels
Project Objectives
Technical Innovation Uncertainty
Politics
Vommunity Involvement
Schedule duration urgency
Implementation problem
Project Objectives
Top Management support
Project planning
Communication with client
Human relations
Technical task
Client Acceptence
Project Control
Communication and problem handling
Top management support
Client consultation
Availability of resources
Project manager performance
The project manager and team members
The organization
Early and continual client consultation
Technology
Schedulling system
Project team
Clealand King, 1983
Clealand King, 1983
Clealand King, 1983
Clealand King, 1983
Clealand King, 1983
Clealand King, 1983
Clealand King, 1983
Morris and Hughes, 1987
Morris and Hughes, 1987
Morris and Hughes, 1987
Morris and Hughes, 1987
Morris and Hughes, 1987
Morris and Hughes, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Pinto and Slevin, 1987
Tuke & Rom, 1995
Tuke & Rom, 1995
Tuke & Rom, 1995
Tuke & Rom, 1995
Walid and Oya, 1996
Walid and Oya, 1996
Pinto and Kharbanda, 1995
Pinto and Kharbanda, 1995
Pinto and Kharbanda, 1995
Pinto and Kharbanda, 1995
50
Top management support and continual "
what if " approach
Pinto and Kharbanda, 1995
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
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
banyak berkembang dan pengembangan teoritis telah mengarah pada prinsipprinsip 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
tindakan¬tindakan:
kesuksesan
menolak
proyek
proyek,
yang
yang
disertai
berpotesi
tidak
dengan
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:
2015
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
10
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Jaminan Kualitas Perangkat
Lunak
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
10
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Jaminan kualitas perangkat lunak
adalah aktivitas pelindung yang
diaplikasikan pada seluruh proses
perangkat lunak
Mahasiswa mengenal, memahami
dan
mampu menjamin kualitas
perangkat lunak yang dihasilkan.
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
data yang diperlukan
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
3
•
Pengerjaan kembali
•
Perbaikan
•
Analisis mode kegagalan
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
4
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
ditemukan
Jumlah
Unit Biaya
Total
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
Kajian tidak
2015
7
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
783
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.
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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. Da fta r it em k eg i at a n y an g m enj adi petunj uk bagi p ros edu r s aa t
k o rek s i di l ak uk an. Da fta r m as al ah b i as any a di l am pi rk a n pa da
l ap or an .
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.
2015
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.
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
10
Spesifikasi yang tidak lengkap atau keliru (IES)
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
mengandung ambiguitas (HCI)
12.
Dan msih banyak lagi (MIS)
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
2015
11
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
atau
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Negosiasi
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
11
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Negosiasi merupakan salah satu
faktor yang penting di dalam sebuah
proyek perangkat lunak
Mahasiswa mengenal, memahami
dan
memiliki
kemampuan
bernegosiasi didalam sebuah aktivitas
proyek perangkat lunak.
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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):
2015
3
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
4
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
supporting arguments)
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
menudukung
(Developing
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.
2015
7
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
10
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
11
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
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.
2015
12
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Kerjasama Tim
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
12
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Kerjasama tim dibutuhkan didalam
pelaksanaan sebuah proyek
perangkat lunak
Mahasiswa mengenal, memahami
dan memiliki kemampuan bekerja
secara tim di dalam sebuah proyek
perangkat lunak
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
3
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
4
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 masalahmasalah
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.
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
7
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
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. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media
Group.
2015
10
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Manajemen Kualitas Suatu
Proyek
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
13
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Kualitas suatu proyek menjadi
elemen yang penting di dalam suatu
proyek agar produk yang dihasilkan
berkualitas
Mahasiswa mengenal, memahami
dan memiliki kemampuan membuat
suatu proyek dengan kualitas yang
baik
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
3
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
4
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 ideide untuk perbaikan dan untuk menyediakan sebuah standar yang digunakan untuk
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
menunjukkan
bagaimana
berkaitan.
Flowchart
1.
alir
adalah
berbagai
teknik
setiap
elemen
yang
umum
dari
diagram
yang
suatu
sistem
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
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
mengidentifikasi kebutuhan untuk kegiatan lebih lanjut di daerah lain.
3. Penjaminan Kualitas
2015
7
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
dapat
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
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
•
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).
Referensi:
1. A Guide to the Project Management Body of Knowledge.
2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and
Management, New York, McGraw-Hill International Edition.
2015
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
3. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media
Group.
2015
10
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
MODUL PERKULIAHAN
Manajemen Proyek
Perangkat Lunak
Analisa Waktu (SPA dan SPL)
Fakultas
Program Studi
Fakultas Ilmu
Komputer
Informatika
2015
1
Tatap Muka
14
Kode MK
Disusun Oleh
87025
Tim Dosen
Abstract
Kompetensi
Analisa waktu diperlukan agar
proyek perangkat lunak yang akan
dijalankan sesuai dengan waktu
yang telah ditentukan dan tidak
mengalami keterlambatan
Mahasiswa mengenal, memahami
dan memiliki kemampuan untuk
menganalisa waktu yang dibutuhkan
di dalam sebuah proyek perangkat
lunak
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 akibatakibatnya 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
2015
2
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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 masingmasing 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
2
3
4
5
6
10
11
12
13
14
15
Diminta:
Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas.
Jawab:
Kasus
Lama Kegiatan (Hari)
Jumlah Kejadian
10
1
1
2015
3
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
2
3
4
5
6
Jumlah
11
12
13
14
15
75
1
1
1
1
1
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:
Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 6 kasus
dengan masing-masing kejadian, sebagai berikut:
Kasus
Lama Kegiatan (Hari)
Jumlah Kejadian
10
11
12
13
14
15
100
200
350
500
250
100
1
2
3
4
5
6
Diminta:
Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas.
Jawab:
Kasus
1
2
3
2015
4
Lama Kegiatan
(Hari)
10
11
12
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Jumlah
Kejadian
100
200
350
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Bobot
10 * 100 = 1.000
11 * 200 = 2.200
12 * 350 = 4.200
4
5
6
LPER =
13
14
15
Jumlah Bobot
=
500
250
100
1.500
18.900
Jumlah Peristiwa
13 * 500 = 6.500
14 * 250 = 3.500
15 * 100 = 1.500
18.900
= 12.6 hari
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:
Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 3 kasus
(tidak mungkin lebih atau kurang dari 3 kasus), sebagai berikut ;
Kasus
1 (LO)
2 (LM)
3 (LP)
Lama Kegiatan
(Hari)
10
13
15
Jumlah Kejadian
LO = Lama kegiatan optimis
LM = Lama kegiatan most likely (yang
paling sering terjadi)
LP = Lama kegiatan pesimis
Diminta:
Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas.
Jawab ;
LPER = 1 * LO + 4 * LM + 1 * LP
6
LPER = 1 * 10 + 4 * 13 + 1 * 15
= 12.8
6
2015
5
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
6
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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)
2015
7
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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
2015
8
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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:
2015
9
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
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.
Referensi:
1. A Guide to the Project Management Body of Knowledge.
2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and
Management, New York, McGraw-Hill International Edition.
2015
10
Manajemen Proyek Perangkat Lunak
Hendra Prastiawan, S.Si., M.T
Pusat Bahan Ajar dan eLearning
http://www.mercubuana.ac.id
Download
Random flashcards
Rekening Agen Resmi De Nature Indonesia

9 Cards denaturerumahsehat

sport and healty

2 Cards Nova Aulia Rahman

Nomor Rekening Asli Agen De Nature Indonesia

2 Cards denaturerumahsehat

Secuplik Kuliner Sepanjang Danau Babakan

2 Cards oauth2_google_2e219703-8a29-4353-9cf2-b8dae956302e

Create flashcards