fasilkom.mercubuana.ac.idfasilkom.mercubuana.ac.id/.../manajemen-proyek-perangkat-lunak-ti.pdf ·...

2015 1 Manajemen Proyek Perangkat Lunak Pusat Bahan Ajar dan eLearning

Tim Dosen http://www.mercubuana.ac.id

MODUL PERKULIAHAN

Manajemen Proyek Perangkat Lunak

Pengantar Manajemen Proyek

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Fakultas Ilmu

Komputer

Informatika

01 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

http://www.mercubuana.ac.id/



1. Manajemen Proyek

1. Pengertian Manajemen

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

mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber

daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah

ditentukan.

2. Pengertian Proyek

Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara

untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek

melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor

utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif

untuk menyelesaikan proyek secara efisien dan tepat waktu.

Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan

usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi

kinerja yang dirancang untuk memenuhi kebutuhan customer.

Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai

berikut :

1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan

suatu produk khusus, layanan, dan hasil akhir.

2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas.

3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya

dapat berupa hardware, software, dan sumber daya lainnya.

4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor.

5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek

bersifat unik maka sangat sulit untuk menentukan objektifitas proyek,

mengestimasi waktu proyek, dan biayanya.

Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan

kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek




membantu membedakan proyek tersebut dari yang lainnya dalam organisasi.

Karakteristik utama dari proyek adalah :

1. Penetapan tujuan

2. Masa hidup yang terdefinisi mulai dari awal hingga akhir

3. Biasanya melibatkan beberapa departemen dan professional

4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya

5. Waktu, biaya, dan kebutuhan yang spesifik

Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang

membuat proyek software berbeda dengan proyek lainnya.

1. Invisibility

Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara

langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan

jembatan dan sebagainya.

2. Complexity

Produk software memiliki lebih banyak kompleksitas daripada proyek fisik

termasuk dari sisi biayanya.

3. Conformity

Pengembang software harus menyesuaikan kebutuhan software dan

kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada

dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal

hingga akhir menjadi hal yang penting dalam keberhasilan proyek.

4. Flexibility

Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah

kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah

dengan mudah untuk mengakomodasi perubahan lingkungan bisnis

organisasi dan komponen lainnya.

Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda

terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple

constraint (3 kendala). Setiap manajer proyek harus memperhatikan hal – hal

penting dalam manajemen proyek :




• Ruang lingkup (scope) : apa yang ingin dicapai dalam proyek ? produk atau

layanan apa yang pelanggan harapkan dari proyek tersebut ?

• Waktu (time) : berapa lama waktu yang dibutuhkan untuk menyelesaikan

proyek? Bagaimana jadwal kegiatan proyek akan dilaksanakan ?

• Biaya (cost) : berapa biaya yang dibutuhkan untuk dapat

menyelesaikan proyek ?

Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin

meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus

diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya

melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus

berkompromi dengan mutu atau jadwal.

Gambar 1.1 Triple Constraint

(Sumber : Schwalbe, 2006, p7)

3. Pengertian Perangkat Lunak Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan:

1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan

kinerja yang diinginkan pada saat dieksekusi atau dijalankan.

2. Struktur – struktur data yang memungkinkan program memanipulasi

informasi sesuai yang diinginkan.

3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari

program – program.

Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware).

Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu :




1. System software membantu user dalam menjalankan hardware dan sistem

komputer. Salah satu contoh system software adalah operating system dan

device drivers. Tujuan dari system software adalah mengisolasi sebanyak

mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit

terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti

printer dan keyboard.

2. Programming Software biasanya menyediakan tools untuk membantu

programmer dalam menulis program – program komputer dan software

dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang

digunakan meliputi text editor, compiler, debbuger, dan sebagainya.

3. Application Software memungkinkan user menyelesaikan satu atau beberapa

tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi

business software, educational software, basis data, dan computer games.

4. Pengertian Manajemen Proyek

Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu

pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud

memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek.

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

mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk

mencapai sasaran jangka pendek yang telah ditentukan.

Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek

antara lain :

1. Manajer Proyek

Elemen paling penting dalam manajemen proyek adalah manajer proyek.

Manajer proyek adalah seseorang yang bertanggung jawab untuk

merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari

anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan

usaha antar area fungsional dan mengintegrasikan perencanaan dan

pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek.




2. Tim proyek

Tim proyek merupakan kumpulan orang yang biasanya berasal dari area

fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk

menyelesaikan pekerjaan proyek.

3. Sistem Manajemen Proyek

Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu

dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat

berdasarkan struktur organisasi, proses informasi, dan pelatihan serta

prosedur yang mengintegrasikan elemen dari organisasi proyek secara

vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam

proyek sedangkan elemen horizontal meliputi unit fungsional dan

departemen yang terlibat dalam proyek.

5. Daur Hidup Manajemen Proyek

Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle)

merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup

proyek terdiri dari :

1. Project Feasibility

Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada

perencanaan.

2. Project Acquisition

Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini

berfokus kepada penyampaian tugas yang nyata dan seharusnya

dilaksanakan.

Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum

melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan

suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap

operasi yang berjalan dalam suatu organisasi.




Gambar 2.2 Fase Daur Hidup Proyek


6. System Development Life Cycle (SDLC)

Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah

kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam

pengembangan sistem informasi. Salah satu model yang popular dan banyak

digunakan dalam daur hidup pengembangan sistem adalah model Waterfall.

7. Model Waterfall

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

umpan balik antara tahapan – tahapan dari pengembangan software untuk

meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan

yang meliputi : System feasibility, software plans and requirement, product

design, detailed design, code, integration, implementation, operation and

maintenance.

Kelebihan dari model Waterfall adalah :

1. Mendukung perencanaan sebelum dilakukannya proses desain.

2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan.

3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek.

4. Menyediakan suatu struktur proyek.

Kekurangan dari model Waterfall adalah :

1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi.




3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek.

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

pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini

mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi.

Model Waterfall mempunyai beberapa tahapan sebagai berikut:

1. System Feasibility

Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk

piranti lunak serta menentukan daur hidup dari proyek.

2. Software Plans and Requirements

Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti

lunak secara rinci.

3. Product Design

Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur

pengendalian, dan struktur data bagi produk dan komponen lainnya yang

diperlukan sebagai dokumen bagi user dan tahap pengujian.

4. Detailed Design

Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data,

hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap

komponen program.

5. Code

Komponen program secara keseluruhan.

6. Integration

Penyatuan masing – masing fungsi komponen agar piranti lunak dapat

bekerja seharusnya.

7. Implementation

Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi,

dan pelatihan user.

8. Operations and Maintenace

Perawatan bagi sistem yang telah dibuat.




Gambar 2.3 Model Waterfall

(Sumber : http://www.jodypaul.com)

8. Sembilan Area Pengetahuan Manajemen Proyek

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

proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer

proyek.

Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang

lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut

merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek

yang lebih spesifik.

Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area

pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui

untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen

integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya


http://www.jodypaul.com/



menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek

dengan baik.

I. Referensi

1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course

Technology Inc. ISBN: 978-1418835590

2. Olson, David. 2004. Introduction to Information Systems Project

Management, 2nd Ed. ISBN: 0-07-282402-6

3. Larson, Erick. W. 2000. Project management: the managerial process.




MODUL PERKULIAHAN


Pengantar Manajemen Proyek (Lanjutan)


Fakultas Ilmu

Komputer

Informatika

02 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




1. Manajemen Proyek

1. Pengertian Manajemen

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

mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber

daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah

ditentukan.

2. Pengertian Proyek

Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara

untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek

melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor

utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif

untuk menyelesaikan proyek secara efisien dan tepat waktu.

Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan

usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi

kinerja yang dirancang untuk memenuhi kebutuhan customer.

Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai

berikut :

1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan

suatu produk khusus, layanan, dan hasil akhir.

2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas.

3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya

dapat berupa hardware, software, dan sumber daya lainnya.

4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor.

5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek

bersifat unik maka sangat sulit untuk menentukan objektifitas proyek,

mengestimasi waktu proyek, dan biayanya.

Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan

kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek




membantu membedakan proyek tersebut dari yang lainnya dalam organisasi.

Karakteristik utama dari proyek adalah :

1. Penetapan tujuan

2. Masa hidup yang terdefinisi mulai dari awal hingga akhir

3. Biasanya melibatkan beberapa departemen dan professional

4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya

5. Waktu, biaya, dan kebutuhan yang spesifik

Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang

membuat proyek software berbeda dengan proyek lainnya.

1. Invisibility

Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara

langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan

jembatan dan sebagainya.

2. Complexity

Produk software memiliki lebih banyak kompleksitas daripada proyek fisik

termasuk dari sisi biayanya.

3. Conformity

Pengembang software harus menyesuaikan kebutuhan software dan

kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada

dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal

hingga akhir menjadi hal yang penting dalam keberhasilan proyek.

4. Flexibility

Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah

kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah

dengan mudah untuk mengakomodasi perubahan lingkungan bisnis

organisasi dan komponen lainnya.

Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda

terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple

constraint (3 kendala). Setiap manajer proyek harus memperhatikan hal – hal

penting dalam manajemen proyek :




• Ruang lingkup (scope) : apa yang ingin dicapai dalam proyek ? produk atau

layanan apa yang pelanggan harapkan dari proyek tersebut ?

• Waktu (time) : berapa lama waktu yang dibutuhkan untuk menyelesaikan

proyek? Bagaimana jadwal kegiatan proyek akan dilaksanakan ?

• Biaya (cost) : berapa biaya yang dibutuhkan untuk dapat

menyelesaikan proyek ?

Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin

meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus

diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya

melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus

berkompromi dengan mutu atau jadwal.

Gambar 1.1 Triple Constraint


3. Pengertian Perangkat Lunak Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan:

1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan

kinerja yang diinginkan pada saat dieksekusi atau dijalankan.

2. Struktur – struktur data yang memungkinkan program memanipulasi

informasi sesuai yang diinginkan.

3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari

program – program.

Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan

tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware).

Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu :




1. System software membantu user dalam menjalankan hardware dan sistem

komputer. Salah satu contoh system software adalah operating system dan

device drivers. Tujuan dari system software adalah mengisolasi sebanyak

mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit

terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti

printer dan keyboard.

2. Programming Software biasanya menyediakan tools untuk membantu

programmer dalam menulis program – program komputer dan software

dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang

digunakan meliputi text editor, compiler, debbuger, dan sebagainya.

3. Application Software memungkinkan user menyelesaikan satu atau beberapa

tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi

business software, educational software, basis data, dan computer games.

4. Pengertian Manajemen Proyek

Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu

pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud

memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek.

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

mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk

mencapai sasaran jangka pendek yang telah ditentukan.

Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek

antara lain :

1. Manajer Proyek

Elemen paling penting dalam manajemen proyek adalah manajer proyek.

Manajer proyek adalah seseorang yang bertanggung jawab untuk

merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari

anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan

usaha antar area fungsional dan mengintegrasikan perencanaan dan

pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek.




2. Tim proyek

Tim proyek merupakan kumpulan orang yang biasanya berasal dari area

fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk

menyelesaikan pekerjaan proyek.

3. Sistem Manajemen Proyek

Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu

dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat

berdasarkan struktur organisasi, proses informasi, dan pelatihan serta

prosedur yang mengintegrasikan elemen dari organisasi proyek secara

vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam

proyek sedangkan elemen horizontal meliputi unit fungsional dan

departemen yang terlibat dalam proyek.

5. Daur Hidup Manajemen Proyek

Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle)

merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup

proyek terdiri dari :

1. Project Feasibility

Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada

perencanaan.

2. Project Acquisition

Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini

berfokus kepada penyampaian tugas yang nyata dan seharusnya

dilaksanakan.

Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum

melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan

suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap

operasi yang berjalan dalam suatu organisasi.




Gambar 2.2 Fase Daur Hidup Proyek


6. System Development Life Cycle (SDLC)

Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah

kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam

pengembangan sistem informasi. Salah satu model yang popular dan banyak

digunakan dalam daur hidup pengembangan sistem adalah model Waterfall.

7. Model Waterfall

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

umpan balik antara tahapan – tahapan dari pengembangan software untuk

meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan

yang meliputi : System feasibility, software plans and requirement, product

design, detailed design, code, integration, implementation, operation and

maintenance.

Kelebihan dari model Waterfall adalah :

1. Mendukung perencanaan sebelum dilakukannya proses desain.

2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan.

3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek.

4. Menyediakan suatu struktur proyek.

Kekurangan dari model Waterfall adalah :

1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi.




3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek.

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

pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini

mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi.

Model Waterfall mempunyai beberapa tahapan sebagai berikut:

1. System Feasibility

Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk

piranti lunak serta menentukan daur hidup dari proyek.

2. Software Plans and Requirements

Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti

lunak secara rinci.

3. Product Design

Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur

pengendalian, dan struktur data bagi produk dan komponen lainnya yang

diperlukan sebagai dokumen bagi user dan tahap pengujian.

4. Detailed Design

Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data,

hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap

komponen program.

5. Code

Komponen program secara keseluruhan.

6. Integration

Penyatuan masing – masing fungsi komponen agar piranti lunak dapat

bekerja seharusnya.

7. Implementation

Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi,

dan pelatihan user.

8. Operations and Maintenace

Perawatan bagi sistem yang telah dibuat.




Gambar 2.3 Model Waterfall

(Sumber : http://www.jodypaul.com)

8. Sembilan Area Pengetahuan Manajemen Proyek

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

proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer

proyek.

Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang

lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut

merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek

yang lebih spesifik.

Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber

daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area

pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui

untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen

integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya


http://www.jodypaul.com/



menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek

dengan baik.

I. Referensi

1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course

Technology Inc. ISBN: 978-1418835590

2. Olson, David. 2004. Introduction to Information Systems Project

Management, 2nd Ed. ISBN: 0-07-282402-6

3. Larson, Erick. W. 2000. Project management: the managerial process.




MODUL PERKULIAHAN


Perencanaan Proyek Perangkat Lunak


Fakultas Ilmu

Komputer

Informatika

03 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




Pemahaman terhadap Proyek Perangkat

Lunak

1. Pemahaman terhadap Proyek Perangkat Lunak

Proyek Software adalah manajemen proyek yang berfokus hanya pada

membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti

berikut ini:

a. Menyelesaikan masalah,

b. Mengerjakan sesuatu hingga selesai,

c. Memiliki batas waktu mulai dan selesainya,

d. Membutuhkan resource/sumber daya dan waktu,

e. Bagi beberapa orang merupakan kesempatan/opportunity dan menarik

Untuk itu sebuah proyek software perlu dikelola. Pengelolaan

(Manajemen) itu berupa persiapan pekerjaan, pelaksanaan rencana,

mengendalikan proyek tersebut dan terakhir menutup proyek dengan sebuah

kesimpulan, yaitu sukses. Secara lebih sistematis, tahapan-tahapan proyek dapat

dilihat pada gambar 3.1:

Gambar 3.1 Tahapan-tahapan Proyek




Tahapan proyek:

1. Initiating: proyek sedang dalam proses untuk dipilih/disetujui, disponsori,

didanai, dan diluncurkan.

2. Planning: perencanaan adalah proses yang berulang (perhatikan gambar).

Perencanaan pada dasarnya menggambarkan proses bagaimana proyek

akan dilaksanakan hingga selesai.

3. Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya.

4. Controlling: selama tim proyek mengerjakan tugasnya, project manager

mengontrolnya.

Closing: setelah proyek diselesaikan project manager akan menutup proyek

software. Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan adalah

bagian yang sangat penting bagi proyek software. Persiapan diwujudkan dalam

bentuk perencanaan proyek. Tulisan ini menjelaskan point kedua yaitu Planning.

2. Faktor-faktor yang mempengaruhi perkiraan biaya

Beberapa faktor yang mempengaruhi terhadap perkiraan biaya pembuatan

perangkat lunak yaitu:

a. Sulit untuk menentukan perkiraan biaya secara akurat selama fase

perencanaan pengembangan S/W karena terlalu banyaknya faktor yang tidak

diketahui pada saat itu.

b. Perkiraan awal disiapkan selama fase perencanaan dan dikemukakan pada

saat presentasi kelayakan proyek. Perbaikan dikemukakan pada saat

presentasi persya-ratan S/W, dan perkiraan akhir dikemukakan pada saat

presentasi perancangan awal.

Faktor-faktor utama yang mempengaruhi biaya perangkat lunak:

a. Kemampuan programmer

Programmer dengan produktivitas tinggi ekuivalen dengan biaya yang kecil.




b. Kompleksitas produk

Tiga katagori produk : aplikasi, utility, dan system

Rasio kompleksitasi ketiganya adalah :

aplikasi : utility : system = 1 : 3 : 9

Misal :

• Jika PM adalah total upaya

(dalam programmer-months)

dan KDSI adalah baris instruksi

dalam product (thousands of

delivered source instructions)

maka estimator PM menurut

Boehm adalah :

aplikasi : PM = 2.4 (KDSI)

utility : PM = 3.0 (KDSI)

• System : PM = 3.6 (KDSI) Untuk

jumlah baris program 60.000,

rasio PM aplikasi : utility :

system 1 : 1.7 : 2.8 (tepatnya

176.6 : 294.2 : 489.6).

(Lihat gambar)

• Estimasi upaya COCOMO

Jika TDEV adalah waktu (dalam bulan) pengembangan sebuah

program (development time), maka estimator TEDV menurut Boehm

TDEV adalah

aplikasi : TDEV = 2.5 (PM)

utility : TDEV = 2.5 (PM)

• System : TDEV = 2.4 (PM)

Untuk jumlah baris program 60.000, ketiga program

memerlukan waktu pengembangan sekitar 18 bulan (tepatnya

TDEV aplikasi : utility : system = 17.9 : 18:3 : 17.4).




Rata-rata jumlah programmer yang diperlukan untuk membuat 60

KDSI per bulan adalah :

aplikasi : 176.6 PM / 17.9 Months = 9.9 programmer

utility : 294.2 PM / 18.3 Months = 16.1 programmer

system : 489.6 PM / 17.4 Months = 28.1 programmer

c. Ukuran produk

Ukuran produk perangkat lunak yang dibuat akan mempengaruhi besarnya

Sumber daya yang dibutuhkan dalam pembuatannya. Tetapi ini harus bisa

terukur karena setiap sumber daya mempunyai nilai optimal tertentu.

d. Waktu yang tersedia

Berbagai penelitian (kecuali Putnam) menunjukkan bahwa proyek S/W

membutuhkan upaya lebih jika waktu pengembangan diperpendek atau

diperpanjang (dimodifikasi) dari waktu normal.

e. Keandalan yang diperlukan

Menurut Boehm, Lima katagori keandalan, efek kegagalan, beserta pengali

upaya (effort multiplier) meliputi:

f. Tingkat teknologi

Tingkat teknologi dalam proyek pengambangan S/W direfleksikan dengan

empat komponen yang digunakan, yaitu:

a) Bahasa pemrograman

b) Mesin abstrak (H/W dan S/W)

c) Praktek-praktek pemrograman

d) Tools.




3. Perencanaan Proyek Perangkat Lunak Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut pandang

kurang lebih memiliki tujuan sebagai berikut:

1. Bagi Project Manager

a) Untuk menggambarkan status proyek kepada manajer senior dan

stakeholder

b) Untuk merencanakan aktivitas tim proyek

2. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan

3. Bagi Manajer Senior:

a) Untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal

dan terkendali

b) Untuk melihat apakah proyek dilaksanakan secara efisien dan cost

effective

4. Bagi Stakeholder:

a) Untuk memastikan apakah proyek masih berada pada jalurnya

b) Untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek

Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan

atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek,

termasuk dokumen-dokumen yang sebaiknya dibuat. Dokumen Perencanaan Proyek

Rekayasa Perangkat Lunak akan terdiri atas sub-sub dokumen yang meliputi Vision

and Scope, Statement of Work, Resource List, Work Breakdown Structure, Project

Schedule dan Risk Plan.

Vision and Scope

1. Vision and Scope

Dokumen ini adalah hasil kerja pertama dari seorang project manager.

Berikutnya dokumen ini akan menjadi tool utama bagi project manager untuk acuan




bagi dokumendokumen dan proses-proses berikutnya. Dokumen Vision and Scope

yang baik dapat mencegah terjadinya masalah-masalah yang dapat memakan biaya

yang besar.

Dengan menunjukkan dokumen ini, baik kepada stakeholder maupun

anggota tim proyek, diharapkan pemahaman yang sama tentang proyek yang

sedang berjalan dapat diraih. Dokumen ini dapat dibagi menjadi dua bagian, yaitu:

1. Problem Statement

Bagian Problem Statement terdiri atas empat sub bab, antara lain:

a. Latar belakang proyek

Sub bab ini menceritakan dengan cukup mendalam baik latar belakang

masalah maupun penjelasan mengenai mengapa organisasi

memutuskan untuk membangun software untuk mengatasi masalah

tersebut. Pada sub bab ini diceritakan sebab munculnya masalah,

sejarah organisasi dengan permasalahan tersebut dan mengapa

akhirnya diputuskan untuk membangun software yang diproyekkan.

b. Stakeholder

Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan

dalam proyek. Mulai dari customer hingga manajer-manajer senior.

Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus

paham dengan siapa mereka bekerja dan apa bidang kerja mereka.

Daftar juga dilengkapi dengan alasan dicantumkannya stakeholder

tersebut. Untuk proyek-proyek besar tentu saja pencantuman nama

tidak relevan karena akan menjadi terlalu panjang daftarnya.

c. Pengguna

Sub bab ini berisi daftar calon pengguna software. Sama dengan

stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi

dengan alasan dicantumkannya pengguna tersebut.

d. Resiko

Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi

pemicu munculnya masalah, seperti keterlambatan dan permasalahan

lain. Resiko yang dimaksud pada sub bab ini bisa faktor internal

maupun eksternal.




2. Vision of the Solution

Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu:

a. Vision statement

Tujuan vision statement adalah menggambarkan apa yang ingin

dicapai setelah proyek berjalan. Di dalam sub bab ini disebutkan

faktor-faktor apa yang harus terpenuhi untuk menandakan kapan

proyek dinyatakan selesai. Selain itu tujuan dari proyek juga harus

jelas disebutkan di dalam sub bab ini. Waktu terbaik untuk membuat

vision statement adalah setelah tim melakukan proses Requirement

Engineering.

Gambaran produk yang ingin dicapai tersebut akan menjadi batasan

ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang

terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan

waktu tertentu. Project manager yang baik akan mempersembahkan

software tepat seperti yang telah dijanjikan kepada stakeholder dan

user, tepat pada waktunya dengan menghabiskan biaya (menerima

bayaran) tepat sama dengan perjanjiannya dengan customer.

Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi

terhadap software, dengan asumsi bahwa stakeholder atau user akan

menyukainya, maka pendapat itu adalah kesalahan. Antara ruang

lingkup, waktu dan biaya/harga harus ada keseimbangan. Jika ada

penambahan pada ruang lingkup, maka seharusnya ada penambahan

waktu atau biaya, jika tidak maka akan menyebabkan ketidak adilan

bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan

ruang lingkup mestinya diatur dengan Change Control System.

b. Daftar fitur

Sebuah paket software umumnya dapat dibagi-bagi menjadi

beberapa fitur. Jumlah yang umumnya dapat diterima adalah sekitar

sepuluh fitur. Jumlah ini sudah cukup menggambarkan kompleksitas

software namun tetap nyaman dibaca oleh tim pengembang. Tiap fitur

sebaiknya ditulis dalam paragraph yang terpisah atau dalam bentuk




pointer-pointer. Deskripsi fitur-fitur ini tidak perlu sangat detil, cukup

beberapa kalimat yang menggambarkan penjelasan umum tentang fitur

tersebut. Fitur-fitur ini mungkin mengalami penambahan atau

pengurangan, sesuai dengan permintaan stakeholder. Jika perlu,

sebuah fitur dapat dilengkapi dengan use case. Namun tentu saja use

case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder.

3. Ruang lingkup tiap fase (jika perlu)

Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek

software membuat pengerjaan seluruh fitur yang diajukan tidak

mungkin selesai. Oleh karenanya dibuat solusi untuk membagi

software menjadi beberapa fase rilis. Software akan dirilis pada saat

deadline tercapai, namun dengan fitur yang dikurangi. Sedangkan rilis

berikutnya lah yang memuat semua fitur.

Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang

sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal

semacam ini perlu dikonsultasikan kepada tim pengembang.

4. Fitur yang tidak akan dibuat

Terkadang stakeholder meminta fitur yang memang harus

dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam

waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam

ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui

semua pihak agar ada kesepahaman dan agar semua setuju dengan

penghapusan fitur ini.

2. Statement of Work

Statement of Work adalah dokumen yang menggambarkan semua produk

yang akan dihasilkan selama proyek berjalan dan siaa yang akan mengerjakannya.

Secara lebih detil, di dalam SOW akan dirinci:

1. Daftar fitur yang akan dibuat; jika software akan dirilis dalam fase-fase,

maka fiturnya juga harus dibagi ke dalam fase-fase tersebut.

2. Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source code,

test plan, laporan defect, dll) yang akan dibuat.




3. Estimasi usaha setiap work product tersebut

Estimasi dibutuhkan agar proyek dapat berjalan dan selesai tepat waktu.

Project manager perlu membantu timnya untuk membuat estimasi yang tepat.

Sebuah pendekatan perlu diambil untuk menyeragamkan teknik estimasi ini. Salah

satu teknik estimasi yang dapat dipilih adalah Wideband Delphi. Berikut ini

langkah-langkah di dalam Wideband Delhi:

1. Memilih tim estimasi

Project manager memilih seorang moderator dan tim estimasi yang terdiri

atas 3 hingga 7 orang. Jika tim yang telah dipilih merasa bahwa dokumen

Vision and Scope kurang memberikan informasi, maka project manager

harus memperbaiki dokumen tersebut.

2. Kickoff Meeting

Pada rapat ini, tim akan membuat sebuah Work Breakdown Structure dan

mendiskusikan berbagai asumsi yang muncul. Langkah-langkah yang dapat

dijadikan acuan ketika rapat berlangsung kurang lebih sebagai berikut:

a. Moderator menjelaskan metode Wideband Delphi

b. Moderator mereview dokumen Vision and Scope dan dokumen-

dokumen pendukungnya, jika ada anggota tim yang belum

membacanya.

c. Tim mendiskusikan produk yang akan dibuat dengan berbagai

asumsinya,

d. Tim membuat 10 hingga 20 pekerjaan utama sebagai representasi

pekerjaan level tertinggi pada WBS

e. Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll)

tersebut hingga mendapatkan kata sepakat.

3. Individual Preparation

Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap

pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebagai

Individual Preparation. Sebelumnya, moderator mencatat semua asumsi

dan WBS kemudian membagikannya kepada semua anggota tim. Format




berikut ini bisa dijadikan acuan untuk mendokumentasikan Individual

Preparation.

Gambar 3.2. Dokumen Individual Preparation

4. Estimation Session

Pada rapat ini, anggota tim bersama-sama merevisi estimasi-estimasiyang

telah dibuat hingga menemukan kata sepakat. Dokumen berikut dapat

dijadikan acuan sebagai contoh untuk membuat dokumentasi selama

Estimation Session. Kepada setiap anggota tim akan dibagikan dokumen

semacam ini (yang kosong) untuk kemudian direvisi selama jalannya

Estimation Session.




Gambar 3.3 Estimation Form

Berikutnya:

a. Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut

kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada

hadiri. Tabulasi tersebut dapat berbentuk seperti berikut:

Gambar 3.4 Estimasi awal

Estimation Form kemudian dikembalikan kepada anggota tim

b. Anggota kemudian akan melihat tabulasi tersebut. Jika diskusi meminta

perubahan estimasi, maka perubahan tersebut dapat langsung

dituliskan pada Estimation Form yang ada di tangan setiap anggota tim

c. Anggota tim mungkin akan menyampaikan perbedaan pendapat. Tetapi

di dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang

mungkin diperdebatkan justru pekerjaannya. Tahap ini mugkin terbagi

menjadi dua sesi, sesi pertama 40 menit dan sesi kedua 20 menit.




d. Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta

berikutnya pada Estimation Form. Isinya bisa +3, +2, -4 dsb. Nilai total

barunya akan dituliskan pada bagian bawah form.

Tahap-tahap di atas dapat berulang hingga selesai, yaitu jika semua anggota

tim menyetujui estimasi hasil rapat, atau jika rapat sudah berlangsung selama dua

jam. Hasilnya akan menghasilkan tabulasi estimasi seperti berikut:

Gambar 3.5 Estimasi akhir

5. Review

Project manager akan meringkas, mengkompail kemudian mereview hasil

estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek

software.

3. Resource List

Resource list adalah daftar resource (sumber daya) yang digunakan selama

proyek berlangsung. Daftar ini berisi apa saja yang dibutuhkan berdasarkan jadwal

proyek dengan mencantumkan deskripsi resource tersebut serta limit ketersediaan

resource tersebut. Daftar semacam ini umumnya dapat dibuat menggunakan

software manajemen proyek. Tetapi bisa juga dibuat dengan worksheet atau word

processor. Setelah SOW dan Resource List dibuat, seorang project manager harus

membuat jadwal proyek (project schedule). Ini bisa dilakukan dengan urutan sebagai

berikut:

a. Membuat Work Breakdown Structure

b. Estimasi usaha yang dibutuhkan oleh setiap pekerjaan pada WBS




c. Project schedule dibuat dengan mengalokasikan resource dan waktu,

berdasarkan kalender, untuk tiap pekerjaan pada WBS

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

penambahan, perubahan atau penghapusan pekerjaan, maka revisi ini harus tercatat

di dalam dokumen Project Plan dengan disertai dengan keterangan waktu kapan

dibuatnya perubahan tersebut.

4. Work Breakdown Structure

Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika

diselesaikan akan menghasilkan work product. WBS menyebutkan:

a. Apa saja pekerjaan yang akan dilakukan,

b. Tipe-tipe resource yang dibutuhkan untuk bekerja,

c. Estimasi tiap elemen pekerjaan,

d. Identifikasi lokasi penyimpanan.

Tetapi tidak mencantumkan:

a. Siapa yang mengerjakan pekerjaan-pekerjaan itu,

b. Dan kapan pekerjaan itu akan diselesaikan

5. Project Schedule

Project Schedule atau jadwal proyek dibuat oleh project manager untuk

mengatur manusia di dalam proyek dan menunjukkan kepada organisasi

bagaimana pekerjaan (proyek) akan dilaksanakan. Ini adalah alat untuk memantau

(bagi project manager) apakah proyek dan tim masih terkendali atau tidak.

Project schedule berbentuk kalender yang dihubungkan dengan pekerjaan

yang harus dikerjakan dan daftar resource yang dibutuhkan. Sebelum jadwal dibuat,

WBS harus terlebih dahulu ada, jika tidak maka jadwal tersebut akan terkesan

mengada-ada. Untuk membuat project schedule, ada beberapa software yang bisa

dijadikan pilihan. Pilihan software yang gratis dan open source antara lain: Open




Workbench, dotProject, netOffice dan Tutos. Beberapa hal perlu diperhatikan ketika

membuat project schedule, seperti:

a) Alokasi resource pada tiap pekerjaan

Resource bisa berupa berbagai hal seperti manusia, barang,

peralatan (komputer, proyektor, dll), tempat (ruang rapat, misalnya)

atau layanan (seperti training atau tim pendukung out source) yang

dibutuhkan dan mungkin ketersediaannya terbatas. Bagaimanapun

juga resource yang utama adalah manusia.

Pertama, project manager akan mengalokasikan orang(-orang)

tertentu untuk suatu pekerjaan. Kemudian, selama pekerjaan

tersebut berlangsung, orang tersebut mungkin menjadi terlalu sibuk

sehingga tidak bisa dialokasikan untuk pekerjaan lainnya. Perhatikan

bahwa pemilihan pelaku perlu disesuaikan dengan kemampuan dan

berbagai hal lain karena ada pekerjaan yang dapat dilakukan oleh

siapa saja, tetapi umumnya pekerjaan hanya dapat dikerjakan oleh

satu atau beberapa orang saja.

b) Identifikasikan setiap ketergantungan

Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan

aktivitas, resource atau work product yang dihasilkan

pekerjaan/aktivitas lain. Contoh: test plan tidak mungkin

dilaksanakan selama software belum diimplementasikan/ditulis,

program baru dapat ditulis setelah class atau modul dibuat dan

dideskripsikan pada tahapan desain.

Tiap pekerjaan pada WBS perlu diberi nomor, dengan angka tersebut

bergantung pada nomor pekerjaan syaratnya. Berikut ini adalah

sedikit gambaran tentang bagaimana suatu pekerjaan menjadi

tergantung pada pekerjaan lainnya.




c) Buat jadwalnya

Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan

demikian jadwal bisa dibuat, contoh:

Tiap pekerjaan ditunjukkan dengan kotak, sedangkan

ketergantungan antar pekerjaan ditunjukkan dengan gambar panah.

Kotak hitam berbentuk wajik antara D dan E (pada gambar di atas)

disebut milestone atau pekerjaan tanpa durasi. Milestone digunakan

untuk menunjukkan kejadian penting pada jadwal. Sedangkan kotak

hitam panjang antara C dan D yang juga mengandung potongan

wajik menunjukkan summary task atau dua sub pekerjaan yang

memiliki induk yang sama. Jadwal bisa dibuat dalam bentuk Gantt

Chart, PERT atau diagram semacamnya.

Contoh Gantt Chart yang dibuat dengan sebuah tool manajemen

proyek:




6. Risk Plan

Risk plan adalah daftar resiko/masalah yang mungkin terjadi

selama proyek berlangsung dan bagaimana menangani terjadinya resiko tersebut.

Bagaimanapun juga ketidakpastian adalah musuh semua rencana, termasuk

rencana proyek. Terkadang ada saja waktu-waktu yang tidak menyenangkan bagi

proyek, banyak kesulitan terjadi misalnya suatu resource tiba-tiba tidak tersedia.

Oleh karenanya risk plan adalah persiapan terbaik menghadapi ketidakpastian.

Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk

Plan:

a) Pembahasan resiko potensial

Project manager akan memimpin sebuah sesi/rapat untuk

mengidentifikasikan masalah-masalah yang mungkin akan muncul.

Anggota tim akan dipancing untuk mengemukakan resiko-resiko yang

terpikirkan. Project manager akan menuliskannya di papan tulis setiap




ada yang mengemukakan pendapat yang relevan. Sedikit pendapat

mungkin akan muncul pada awalnya, kemudian berlanjut dengan

tanggapan yang susul-menyusul hingga akhirnya suasana mendingin

sampai akhirnya pendapat terakhir diutarakan.

Resiko yang dimaksud di sini adalah resiko spesifik. Jika suatu resiko

dirasa belum spesifik maka project manager akan memancing agar

permasalahan disampaikan secara lebih spesifik. Sumber masalah yang

baik lainnya adah asumsi-asumsi yang muncul ketika membuat Vision

and Scope dan melakukan estimasi dengan metode Wideband Dephi

b) Estimasi dampat tiap resiko/masalah

Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar dari 1

(masalah dengan resiko kecil) hingga 5 (masalah dengan resiko besar,

kemungkinan munculnya besar, mungkin menghabiskan biaya besar dan

sulit untuk membereskannya).

c) Buat sebuah risk plan

Tim akan mengidentifikasi langkah-langkah yang akan di ambil untuk

mengatasi masalah-masalah yang akan muncul tersebut, dimulai dari

resiko bernilai 5.

Contoh sebuah dokumen risk plan:

Gambar 3.6 Risk Plan




I. Referensi

1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill

2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley


MODUL PERKULIAHAN


Perencanaan Proyek Perangkat Lunak (Lanjutan)


Fakultas Ilmu

Komputer

Informatika

04 87025 Tim Dosen

Abstract Kompetensi

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.

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

Pada bab ini menjelaskan tentang maksud dari perencanaan proyek perangkat lunak

Manajemen Proyek Perangkat Lunak Tim Dosen

2 0 1 5 1


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.



2 0 1 5 2


• 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



2 0 1 5 3


Sistem harus dapat beroperasi dengan kemampuan 95% ketika

dioperasikan selama 24 jam penuh

• Contoh persyaratan kualitatif :

Akurasi harus cukup tinggi

Sistem harus mempunyai tanggapan yang baik

Sistem harus hemat dalam penggunaan memori utama

Keandalan sistem harus 99%

• Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut

kualitas yang harus dimiliki sistem, di antaranya : portability (S/W tidak

bergantung mesin), realiability (kemampuan program melakukan fungsi

yang diinginkan), efficiency (menggunakan sumber daya minimal),

accuracy (ukuran besarnya error), robustness/integrity (kemampuan

bekerja dengan baik walau mendapat input yang tidak benar), correctness

(hasil sesuai dengan yang diharapkan).

5. Tetapkan kriteria penerimaan sebuah system.

• Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan

menimbulkan perselisihan antara pengembang dan pelanggan. Kriteria

harus dapat diverfikasi dengan suatu metoda baku seperti : peninjauan

langsung, analisa, atau serangkaian uji, terhadap produk yang

dihasilkan.

B. Pengembangan Strategi Solusi

• Kecenderungan untuk menerima begitu saja solusi pertama yang terlintas di

benak kita adalah masalah utama dalam perkeayasaan perangkat lunak. Ini

tidak memberi peluang terhadap solusi lain yang sebenarnya masih

mungkin untuk dipertimbangkan.

• Kembangkan strategi solusi. Strategi bukan merupakan solusi rinci tetapi

penyataan umum tentang sifat-sifat dari solusi yang mungkin.

• Langkah-langkah pengembangan strategi solusi adalah sebagai berikut : 1.

Uraikan beberapa strategi solusi tanpa memperhatikan batasanbatasan

apapun



2 0 1 5 4


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



2 0 1 5 5


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 :


2 0 1 5 6 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

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



2 0 1 5 7


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



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


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 1 0


Beberap catatan tentang model prototipe :

• Sebuah prototipe adalah model dari sebuah produk perangkat lunak tetapi

dengan beberapa keterbatasan, misalnya : keterbatasan kemampuan, keandalan

yang rendah, dan kinerja yang tidak efisien.

• Alasan penggunaan model prorotipe adalah :

1. untuk menggambarkan format data masukan, pesan-pesan, laporan, dan dialog

interaktif

2. untuk mengeksplorasi isu-isu teknis dalam produk yang diusulkan

3. model fase ‘analisis → perancangan → implementasi’ tidak dapat digunakan

2. Perencanaan Struktur Organisasi

A. Struktur Pelaksana Proyek

Ada 3 format struktur pelaksana proyek : format proyek, format fungsional, dan formta

matriks

1. Format Proyek

• Dibentuk sebuah team yang melakukan pekerjaan proyek dari awal sampai

akhir

• Annggota team mendefinisikan produk, merancang produk,

mengimplementasikan, melakukan uji, melakukan review, dan

mempersiapkan dokumen-dokumen pendukung

• Sebagian anggota team melakukan instalasi dan pemeliharaan, dan

melanjutkan ke proyek baru

• Team proyek biasanya bekerja selama 1-3 tahun dan ditugaskan untuk

proyek berikutnya jika proyek pertama sudah selesai

2. Format Fungsional

• Dalam format ini dibentuk beberapa team untuk melaksanakan pekerjaan

proyek setiap fase. Semua team tidak dibentuk pada saat yang sama.

Anggota team dapat dirotasi.

• Team analisis dan perancangan bertugas untuk mengembangkan System

Definition (SD) dan Project Plan (PP).



2 0 1 5 11


• 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


2 0 1 5 1 2 Pusat Bahan Ajar dan eLearning



B. Struktur Tim Pemrograman

1 Demokrasi

Gambar 4.5 Struktur Organisasi – Demokrasi

• Berbagai keputusan dilakukan melalui kesepakatan kelompok

• Kepemimpinan berotasi sesuai dengan jenis pekerjaan yang sedang

dilaksanakan dan spesialisasi anggota

2 Kepemimpinan

Gambar 4.6 Struktur Organisasi – Kepemimpinan

• Pimpinan merancang produk, mengimplementasikan bagian kritis dari produk,

dan membuat semua keputusan teknis utama

• Programer menuliskan source code, debugging, dokumentasi, dan uji unit



2 0 1 5 1 3


• Pustakawan mengurus listing program, merancang dokment-dokumen, membuat

rencana uji

• Back-up programmer berperan sebagai konsultan bagi pimpinan untuk berbagai

masalah teknis, memelihara hubungan dengan pelanggan dan kelompok

publikasi serta kelompok jaminan kualitas, dan melakukan sejumlah analisis-

perancangan-implementasi di bawah pengawasan pimpinan.

Referensi

1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill

2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley


2 0 1 5 1 4 Pusat Bahan Ajar dan eLearning





MODUL PERKULIAHAN


Estimasi Biaya


Fakultas Ilmu

Komputer

Informatika

05 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




1. Manajemen Biaya Proyek

1. Pengertian Manajemen Biaya Proyek

Manajemen biaya proyek merupakan salah satu dari 9 area pengetahuan dalam

manajemen proyek. Manajemen biaya proyek diperlukan untuk memastikan bahwa

perencanaan proyek sudah mencakup :

1. Estimasi biaya untuk setiap resource

2. Pengalokasian estimasi biaya setiap resource yang dibutuhkan oleh

setiap work item

Dalam manajemen biaya proyek, terdapat beberapa proses yang dilibatkan

dalam tujuan penyelesaian proyek sesuai dengan anggaran yang disediakan. Proses

tersebut yaitu estimasi, budgeting dan kontrol biaya.

Gambar 5.1 Overview Manajemen Biaya Proyek




Proses estimasi sangat menentukan kelangsungan proyek baik dari mulai tahap

desain, perencanaan, konstruksi, dan maintenance. Berbagai tipe dan cara dalam

mengestimasi biaya akan tergantung pada data/informasi yang tersedia, batas waktu,

dan tujuan dari estimasi tersebut. Peran estimator dalam estimasi biaya proyek

konstruksi dapat ditinjau dari ketelitian, pengalaman dan spesialisasi terhadap proyek

secara keseluruhan.

Untuk mendapatkan jawaban dari rumusan masalah pada bab 1, maka pada bab

ini akan diberikan dasar pemikiran ilmiah yang dilandasi dengan teori¬teori ilmiah yang

diperoleh dari area Manajemen Proyek, terutama dalam area pengetahuan Manajemen

Biaya Proyek.

Dalam landasan teori ini, terdapat 3 sumber utama yang akan dijadikan acuan

dalam pemecahan masalah yaitu :

1. Teori Manajemen Proyek dan lebih spesifik ke manajemen biaya di proyek,

sebagian besar akan diambil dari literatur Manajemen Proyek seperti PMBoK,

dan sumber lainnya yang memberikan teori tentang Manajemen Proyek.

2. Teori Manajemen Biaya Proyek, khususnya yang membahas tentang proses

estimasi biaya proyek, kinerja biaya proyek serta kegiatan-kegiatan yang

termasuk di dalamnya maupun yang memberikan pengaruh terhadap kedua hal

tersebut di atas. Teori ini diperoleh dari berbagai jurnal ilmiah baik nasional

maupun internasional, serta beberapa buku yang membahas tentang estimasi

biaya dan kinerja biaya proyek.

3. Aplikasi pengembangan manajemen biaya proyek khususnya dalam masalah

estimasi dalam sebuah perusahaan konstruksi yang telah memiliki dan

menerapkan sistem estimasi secara lebih akurat dengan data/informasi yang

diberikan, waktu serta tujuan estimasi. Hal ini bertujuan untuk menjadi bahan

pembanding dan masukan bagi penelitian ini.




2. Estimasi Biaya Proyek

1. Definisi

Terdapat beberapa literatur yang membahas mengenai pengertian estimasi

biaya. Dalam AACE International (2004), disebutkan bahwa estimasi merupakan

evaluasi dari keseluruhan elemen dari sebuah proyek atau usaha yang diberikan

berdasarkan kesepakatan terhadap suatu lingkup pekerjaan. Dysert, Larry R.

mengungkapkan bahwa estimasi biaya merupakan sebuah prediksi terhadap biaya yang

akan dibutuhkan dari sebuah proyek berdasarkan data dan lingkup proyek yang

diberikan yang akan dilaksanakan pada sebuah lokasi dan waktu yang telah ditetapkan.

Dalam sebuah estimasi biaya terdapat identifikasi dan pertimbangan dalam

memperkirakan beberapa alternatif biaya untuk memulai dan menyelesaikan proyek.

Jumlah biaya yang akan dikeluarkan dan risiko harus dapat dipertimbangkan, misalnya

seperti membuat keputusan untuk membeli suatu barang atau hanya menyewanya saja

untuk keperluan proyek, berbagi sumber daya dalam rangka mengoptimalkan biaya

dalam proyek. Biaya yang disusun akan memperhitungkan keseluruhan sumber daya

yang dibutuhkan dalam sebuah proyek, termasuk tenaga kerja, material, peralatan, jasa,

dan fasilitas dan beberapa kategori spesial seperti faktor inflasi atau biaya contingency.

Estimasi biaya merupakan penilaian kuantitatif yang mendekati untuk kebutuhan sumber

daya dalam proyek.

Tujuan dari dibuatnya suatu estimasi proyek adalah :

1. Sebagai dasar dalam pembuatan anggaran proyek

2. Sebagai alat untuk mengontrol biaya proyek

3. Untuk memonitor progress, dengan membandingkan anggaran biaya, biaya

estimasi dengan actual di lapangan.

4. Untuk membuat suatu database biaya yang dapat digunakan untuk estimasi-

estimasi berikutnya.

5. Estimasi biaya dan penjadwalan merupakan 2 aktifitas yang sangat berkaitan

erat.




2. Jenis Estimasi Biaya

Dilihat dari kelengkapan datanya dan terhadap tahapan proyek, maka estimasi

biaya dapat dibedakan menjadi 3 yaitu:

1. Preliminary Estimate

Merupakan estimasi biaya pada tahap perencanaan. Pada tahap ini, desain

proyek belum ada, hanya ada dalam bentuk gagasan. Estimasi biaya diberikan

untuk keperluan studi kelayakan. Estimasi dihitung secara kasar berdasarkan

informasi harga dari proyek sejenis per satuan kapasitas produksi atau per

satuan fungsinya atau per satuan luasnya.

2. Semi Detail Estimate

Estimasi ini ada pada tahap conceptual engineering. Estimasi biaya sudah dapat

dihitung secara detail karena basic design proyek sudah ada. Hasil estimasi

biaya pada tahap ini dapat dipergunakan sebagai dasar pertimbangan untuk

menyiapkan dana yang diperlukan bagi proyek tersebut, oleh karena itu sering

juga disebut sebagai budget estimate bagi owner.

3. Definitive Estimate

Estimasi ini ada pada tahap detailed engineering, dimana semua informasi yang

diperlukan untuk pelaksanaan sudah lengkap. Estimasi biaya sudah dapat

dihitung secara detail karena construction drawing sudah ada. Beberapa hal

dipertimbangkan dalam estimasi ini antara lain metode konstruksi, kondisi lokasi

proyek, preliminary work yang akan dilakukan, penggunaan sumber daya

tenaga, alat dan material serta subkontraktor sesuai spesifikasi yang ada serta

waktu pelaksanaan proyek.

3. Metode Estimasi Biaya

Setelah memperoleh data dan informasi yang lengkap mengenai suatu proyek,

maka proses estimasi akan dilanjutkan dengan pengolahan data tersebut. Terdapat

beberapa metode yang digunakan dalam pengolahan data untuk menyusun suatu

estimasi biaya yaitu:




1. Expert Judgment

Dari para ahli dapat diperoleh informasi historikal berdasarkan pengalaman mereka

terutama bagi proyek-proyek sejenis. Dari para ahli juga diperoleh pertimbangan

untuk menggabungkan beberapa metode dalam proses estimasi dan bagaimana

menyelaraskan perbedaan yang ada dalam metode tersebut.

2. Analogous Estimating

Menggunakan nilai dari sebuah parameter, seperti lingkup, biaya, anggaran dan

waktu maupun menggunakan skala perbandingan terhadap ukuran, kompleksitas

proyek sebelumnya yang dijadikan dasar untuk menyusun estimasi biaya proyek

yang serupa.

3. Parametric Estimating

Digunakan sebagai statistik dari hubungan antara data historikal dengan variabel

lainnya seperti luas area untuk menghitung estimasi beberapa parameter seperti

biaya, anggaran dan masa pelaksanaan.

4. Bottom-Up Estimating

Merupakan metode dalam mengestimasi komponen pekerjaan. Biaya dan akurasi

dari tipe ini dipengaruhi oleh ukuran dan kompleksitas dari aktiftas individual maupun

paket pekerjaan.

5. Three-Point Estimates

Keakuratan dalam sebuah estimasi dapat ditingkatkan dengan mempetimbangkan

aspek ketidaktentuan dan risiko. Dalam Program Evaluation and Review Technique

(PERT) digunakan 3 estimasi untuk memperkirakan biaya dari sebuah aktifitas,

yaitu:

1. Most Likely (CM), biaya aktifitas berdasarkan penilaian usaha yang realistik

terhadap suatu pekerjaan

2. Optimistic (CO), biaya aktifitas berdasarkan pertimbangan yang optimis

untuk aktifitas tersebut




3. Pessimistic (CP), biaya aktifitas berdasarkan pertimbangan pesimis

terhadap suatu aktifitas

Ketiga parameter diatas dirumuskan dalam bentuk sebagai berikut :

Untuk metode ini biasanya digunakan untuk perkiraan biaya yang mengandung

unsur ketidakpastian seperti estimasi biaya penelitian karena menggunakan

pertimbangan optimistik, pesimistik.

6. Reserve Analysis

Estimasi biaya yang termasuk biaya tak terduga. Biaya tak terduga tersebut dapat

berupa prosentase dari nilai estimasi, nilai yang tetap, atau dapat dikembangkan dari

metode analisa kuantitatif.

7. Cost of Quality

Menyangkut perhitungan seluruh biaya yang dipersiapkan untuk mencegah adanya

ketidakpuasan terhadap kualitas produk yang akan mengakibatkan rework.

8. Project Management Estimating Software

Beberapa program komputer dapat digunakan sebagai alat untuk membantu dalam

mengestimasi biaya.

9. Vendor Bid Analysis

Metode estimasi biaya, termasuk analisa biaya dari sebuah proyek yang

dimenangkan tanpa melalui proses persaingan karena memperoleh informasi dari

rekanan, tentunya akan diperlukan tambahan biaya.




4. Proses Estimasi Biaya

Proses estimasi biaya merupakan keseluruhan proses dalam estimasi dimulai

dari proses input data, teknik yang digunakan dalam pengolahan data serta output yang

dihasilkan dari sebuah estimasi. Diberikan pula diagram alur data estimasi biaya.

Gambar 5.2 Estimasi biaya: Input, Tools & Teknik, Output

Tahapan input dalam suatu proses estimasi mencakup beberapa hal yang

diperlukan untuk mendukung proses pelaksanaan estimasi seperti:

1. Scope Baseline

Menggambarkan pernyataan lingkup pekerjaan seperti deskripsi produk, kriteria

yang dapat diterima, hasil yang diharapkan, batasan proyek dan asumsi. Dalam

scope baseline terdapat pula WBS yang menggambarkan hubungan dari semua

komponen dalam proyek.

2. Penjadwalan Proyek

Jenis dan jumlah dari sumber daya serta waktu yang dibutuhkan dalam rangka

peyelesaian proyek merupakan faktor yang penting dalam menentukan biaya

proyek.




3. Perencanaan Sumber Daya

Atribut staf proyek, biaya personel, dan bonus bagi karyawan merupakan komponen

yang penting dalam menyusun estimasi biaya.

4. Penyusunan Daftar Risiko

Identifikasi risiko diperlukan untuk pengendalian biaya akibat adanya risiko. Risiko

dapat memberikan dampak dalam aktifitas maupun biaya proyek.

5. Pertimbangan Faktor diluar Lingkungan Perusahaan

Faktor – faktor yang dapat mempengaruhi antara lain kondisi pasar dan informasi

komersial yang ada. Kondisi pasar yang dimaksud adalah ketersediaan produk, jasa

yang diperlukan dalam penyelesaian proyek dan yang dimaksud dengan informasi

komersil adalah database komersil yang memberika data tentang keahlian dan

upah dari sumber daya, serta biaya standard untuk material dan peralatan.

6. Kebijakan Organisasi

Kebijakan organisasi yang berpengaruh terhadap estimasi biaya adalah kebijakan

perusahaan dalam estimasi biaya itu sendiri, informasi historikal serta pelajaran

maupun pengalaman dari proyek sebelumnya.

Dibawah ini juga digambarkan proses penyusunan anggaran biaya sebelum

tahap pelaksanaan :




Gambar 5.3 Proses Penyusunan Anggaran Biaya

Adanya input dari Database Management System dalam penyusunan estimasi

akan sangat membantu terutama untuk proyek dengan skala besar dan sangat

kompleks. Dalam database ini mencakup seluruh aspek yang dibutuhkan berdasarkan

parameter dari proyek-proyek sebelumnya maupun data baru baik itu mengenai harga,

lokasi, tenaga kerja dan lain sebagainya.

Seringkali diperlukan revisi harga sehubungan dengan budget yang disediakan

oleh owner. Oleh karena itu diperlukan revisi kembali harga satuan dan mengoreksi

quantity pekerjaan. Faktor-faktor yang perlu dipertimbangkan pada saat mengubah

harga satuan yaitu :

1. Melakukan construction economy yaitu upaya yang dilakukan dalam proses

pra konstruksi maupun masa konstruksi dengan tujuan menekan biaya

konstruksi termasuk juga untuk menekan kemungkinan terjadinya

pembengkakan biaya.

2. Mengubah construction method

3. Mengubah durasi proyek (bila memungkinkan)

4. Mengganti pemasok sumber daya yang digunakan

5. Mengubah kebijakan keuangan (pembiayaan)




I. Referensi:

1. Project Management Institute, (2008). A Guide to the Project Management Body of

Knowledge, 4th Edition, hal. 165.

2. Perrot, Melvin W., (2004). The Cost Estimator’s Dilemma, AACE International

Transactions, hal. 1.

3. Dysert, Larry R. (2006). Is “Estimate Accuracy” an Oxymoron?, Journal AACE

International Transactions, hal. 1.

4. Project Management Institute, (2008). A Guide to the Project Management Body of

Knowledge, 4th Edition, hal. 168.

5. Asiyanto MBA, IPM, (2005). Construction Project Cost Managament, (Pradnya

Paramita).

6. Jin Han, Kyeong, Park, Moonseo, Lee, Hyun-Soo, Ji, Sae-Hyun, (2008). Cost

Estimation Methodology Using Database Layer in Construction Projects, The 25th

International Symposium on Automation and Robotics in Construction.




MODUL PERKULIAHAN


Manajemen Resiko


Fakultas Ilmu

Komputer

Informatika

06 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




1. Manajemen Resiko

1. Pendahuluan

Manajemen resiko adalah proses pengukuran atau penilaian resiko serta

pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah

memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif

resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen

resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal

(seperti bencana alam atau kebakaran, kematian serta tuntutan hukum).

Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu

perangkat lunak untuk memahami dan mengatur ketidak pastian. Pada saat kita

mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi

yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya

pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita

menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan

identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan

resiko tersebut.

Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko

berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga

yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak

terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini

dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik.

Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun tidak

sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas

tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis

pengembangan biasanya merupakan penyebabnya.

Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk

meminimalkan resiko atau paling tidak mendistribusikannya selama pengembangan

tersebut dan idealnya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang

kritis.




Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung

pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi

resiko dan alokasi staf dan sumber daya lainnya erat kaitannya.

Resiko dalam perangkat lunak memiliki dua karakteristik:

• Uncertainty : tidak ada resiko yang 100% pasti muncul.

• Loss : resiko berimbas pada kehilangan.

Dan resiko memiliki kategori:

1) Resiko Proyek

Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi

kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip dan

biaya menjadi bertambah. Resiko proyek mengidenifikasi :

- Biaya - Sumber daya

- Jadwal - Pelanggan

- Personil (staffing & organisasi) - Masalah persyaratan

2) Resiko Teknikal

Resiko teknis mengancam kualitas & ketepatan waktu PL yang akan

dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya

menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi :

- Desain potensial - Ambiquitas

- Implementasi - Spesifikasi

- Interfacing - Ketidakpastian teknik

- Verivikasi - Keusangan teknik

- Masalah pemeliharaan - Teknologi yang leading edge

3) Resiko Bisnis

Resiko bisnis mengancam viabilitas PL yang akan dibangun. Resiko bisnis

membahayakan proyek atau produk. 5 resiko bisnis utama :

a) Pembangunan produk atau sistem yang baik sebenarnya tidak pernah

diinginkan oleh setiap orang (resiko pasar)

b) Pembangunan sebuah produk yangg tidak sesuai dengan

keseluruhan strategi bisnis bagi perusahaan (resiko strategi)




c) Pembangunan sebuah produk dimana sebuah bagian pemasaran

tidak tahu bagaimana harus menjualnya.

d) Kehilangan dukungan manajemen senior sehubungan dengan

perubahan pada fokus atau perubahan pada manusia (resiko

manajemen)

e) Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen

personal (resiko biaya).

4) Resiko yang sudah diketahui

adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hati-

hati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek

sedang dikembangkan, dan sumber informasi reliable lainnya.

seperti :

- Tanggal penyampaian yang tidak realitas

- Kurangnya persyaratan yang terdokumentasi - kurangnya ruang lingkup PL

- Lingkungan pengembangan yang buruk

5) Resiko yang dapat diramalkan

Merupakan diekstrapolasi dari pengalaman proyek sebelumnya.

Misalnya :

- Pergantian staf

- Komunikasi yang buruk dengan para pelanggan

- Mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung

dilayani

6) Resiko yang tidak diharapkan

Resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi

sebelumnya.

Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber2

daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang

sebenarnya / penting.

Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial

diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut

kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran

utama adalah menghindari resiko




2. Masalah-masalah Proses

1. Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan

yang menekankan pentingnya suatu proses standar untuk pengembangan

proses ?

2. Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai

proses PL yang akan digunakan pada proyek ini ?

3. Apakah anggota-anggota staf “ditugasi” ke proses PL pada saat PL

didokumentasi & bersedia menggunakannya ?

4. Apakah proses PL digunakan untuk proyek lain ?

5. Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian

serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ?

6. Apakah standar RPL yang diterbitkan disediakan untuk setiap pengembang PL

& manajer PL ?

7. Sudahkah dokumen outline & contoh-contoh dikembangkan untuk semua yang

ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses

PL ?

8. Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode

dilakukan secara reguler ?

9. Apakah kajian teknis formal terhadap prosedur pengujian & test case dilakukan

secara reguler ?

10.Apakah hasil dari masing-masing kajian teknis formal didokumentasikan,

termasuk kesalahan yang ditemukan & sumber daya yang digunakan ?

11.Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu

proyek sesuai dengan standar RPL ?

12.Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi

diantara system/persyaratan PL, desain, kode, dan test case ?

13.Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke

persyaratan pelanggan yang mempengaruhi PL ?

14.Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan

rencana pengembangan PL yang didokumentasikan untuk masing-masing

subkontrak ?




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?

4




• Apakah PL yang akan dibangun ber-interace dengan produk PL

yang dipasok oleh vendor yang belum terbukti?

• Apakah PL yang akan dibangun ber-interface dengan suatu sistem

database yang fungsi kinerjanya belum dibuktikan di dalam area

aplikasi ini?

• Apakan diperlukan interface pemakai khusus oleh persyaratan produk?

• Apakah persyaratan untuk produk memerlukan kreasi komponen

program yang tidak sama dengan yang dikembangkan terakhir oleh

organisasi anda?

• Apakah persyaratan memerlukan pemakaian analisis, desain atau

metode pengujian baru?

• Apakah persyaratan memerlukan metode pengembangan PL tidak

konvensional, seperti metode formal, pendekatan Al-based dan

jaringan syaraf buatan?

• Apakah persyaratan meletakkan batasan kinerja yang eksesif pada

produk tersebut?

• Apakah pelanggan tidak yakin pada fungsionalitas yang diminta

dapat ’dilakukan’?

Bila jawaban dari pertanyaan-pertanyaan di atas adalah ’ya’, penyelidikan lebih

lanjut harus dilakukan untuk memperkirakan risiko potensial.

4. Analisa Resiko Lingkungan Pengembangan

Resiko yang berhubungan dengan keberadaan dan kualitas peranti yang akan

digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek,

proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting.

Checklist item resiko yang berhubungan dengan lingkungan pengembangan :

• Apakah peranti manajemen proyek dapat diperoleh?

• Apakah peranti untuk analisis dan desain dapat diperoleh?

• Apakah peranti analisis dan desain penyampaian metode sesuai




bagi produk yang akan dibangun?

• Apakah kompiler atau generasi kode dapat diperoleh dan sesuai

untuk produk yang akan dibangun?

• Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk

yang akan dibangun?

• Apakah peranti manajemen konfigurasi PL dapat diperoleh?

• Apakah lingkungan menggunakan suatu database atau tempat

penyimpanan?

• Apakah semua peranti PL dapat diintegrasikan satu dengan lainnya?

• Sudahkah anggota tim proyek menerima pelatihan dengan masing-

masing peranti?

• Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan

mengenai peranti tersebut?

• Apakah bantuan dan dokumentasi on-line bagi peranti memadai?

Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti

lingkungan pengembangan PL lemah dan berisiko tinggi

5. Komponen Resiko dan Driver

Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu

menghendaki agar manajer proyek mengidentifikasi risiko driver yang mempengaruhi

komponen risiko PL – kinerja, biaya, dukungan dan jadwal. Komponen risiko

didefinisikan dengan cara sbb :

• Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi

persyaratannya dan cocok dengan penggunaannya.

• Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga

• Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah

dikoreksi, disesuaikan dan ditingkatkan.

• Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga

dan produk akan disampaikan tepat waktu




Dua cara melakukan proyeksi risiko:

• Probabilitas di mana risiko adalah nyata

• Konsekuensi masalah yang berhubungan dengan risiko

Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4

aktifitas proyeksi risiko :

1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang

dirasakan

2. Menggambar konsekuensi risiko

3. Memperkirakan pengaruh risiko pada proyek dan produk

4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak

ada kesalahpahaman

6. Pengurangan dan Monitoring Resiko Perangkat Lunak

Aktifitas analisis risiko mempunyai titik tunggal yang memiliki tujuan untuk

membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko.

Strategi yang efektif harus:

1. Menghindari risiko

2. Memonitoring risiko

3. Manajemen risiko dan perencanaan kemungkinan

Langkah-langkah untuk mengurangi turnover staf adalah

1. Temui staf yang ada, untuk menentukan penyebab keluar

2. Bertindaklah untuk mengurangi penyebab-penyebab yang ada di bawah

kontrol manajemen sebelum proyek dimulai

3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-

teknik untuk memastikan kontiunitas pada saat orang keluar

4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas

pengembangan dapat disebarluaskan

5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa

dokumen dikembangkan tepat waktu




6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih

dari satu orang yang terbiasa dengan pekerjaan itu

7. Tentukan backup anggota staf untuk setiap teknologi kritis

Aktifitas pemonitoran dimulai, manajer proyek memonitor factor-faktor yang

dapat memberikan suatu indikasi apakah risiko mungkin sedang menjadi lebih

atau kurang.

Untuk kasus turnover tinggi, factor-faktor yang dapat dimonitor :

1. Sikap umum anggota tim berdasarkan tekanan proyek

2. Tingkat di mana tim disatu – padukan

3. Hubungan interpersonal di antara anggota tim

4. Masalah pontensial dengan kompensasi dan manfaat

5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya

Langkah pengurangan resiko diperlukan bagi definisi standar dokuntasi dan

mekanisme untuk memastikan bahwa dokumen dikembangkan secara tepat waktu,

guna memastikan kontinuitas.Manajemen risiko dan perencanaan kemungkinan

mengasumsikan bahwa usaha pengurangan telah gagal dan risiko menjadi suatu

kenyataan.

Contoh, diandaikan proyek sedang berlangsung dengan baik dan sejumlah

orang mengatakan akan keluar dari proyek tersebut maka strategi pengurangan telah

dilakukan dengan backup , informasi, dokumentasi dan pengetahuan telah disebar ke

semua tim. Manajer proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yang

telah disusun sepenuhnya dan pendatang baru akan ditambah untuk mengejar dan

membagun serta akan ditransfer pengetahuan oleh orang akan keluar.

I. Referensi:

1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997.

2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004.

3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,

2006.




MODUL PERKULIAHAN


Inisiasi Proyek dan Ruang Lingkup Manajemen


Fakultas Ilmu

Komputer

Informatika

07 87025 Tim Dosen

Abstract Kompetensi

Modul ini berisi materi tentang penaksiran proyek, elemen-elemen 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




1. Perencanaan, Penaksiran, dan Pengaturan Sumber

Daya Proyek

1. Penaksiran Proyek

Proses manajemen proyek perangkat lunak dimulai dengan serangkaian

aktivitas yang secara kolektif disebut perencanaan proyek. Aktivitas awal dari

perencanaan adalah estimasi. Kapanpun estimasi dilakukan, seorang perencana mulai

melihat pada masa depan dengan suatu tingkat ketidak pastian teretentu, yang akan

menjadi bahan pembahasan untuk menaksir proyek.

Hasil penaksiran akan menjadi dasar bagi semua aktiviotas perencanaan proyek

lebih jauh. Perencanaan proyek merupakan peta jalan bagi suksesnya rekayasa

perangkat lunak. Tanpa penaksiran yang teliti, perencanaan proyek akan menghasilkan

berbagai resiko dimasa depan, misalnya kerugian, kegagalan memenuhi limit waktu

yang sudah disepakati, dan kesulitan-kesulitan lain yang muncul dalam pengerjaan

teknis proyek.

Penaksiran berbagai hal untuk usaha pengembangan suatu perangkat lunak

membutuhkan:

• Pengalaman

• Akses informasi historis

• Keberanian mengkuantifisir data-data

Kualitatif Penaksiran yang dilakukan meliputi:

• Penaksiran kebutuhan sumber daya manusia

• Penaksiran kebutuhan biaya

• Penaksiran kebutuhan waktu dan penjadwalan

Penaksiran membawa resiko ketidak pastian. Ketidak pastian itu sendiri sangat

dipengaruhi oleh:

• Kompleksitas proyek

• Ukuran proyek

• Ketidakpastian structural




A. Kompleksitas Proyek

Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian dalam

perencanaan. Tetap kompleksitas pengukran yang relatif yang dipengaruhi oleh

kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya.

Aplikasi real-time dapat dirasakan sebagai sangat kompleks bagi sebuah

kelompok perangkat lunak yang hanya mengembangkan aplikasiaplikasi batch

saja. Tetapi aplikasi yang sama dapat dirasakan sebagai run-of-mill bagi sebuah

kelompok perangkat lunak yang telah terlibat jauh dalam proses kontrol

kecepatan tinggi. Sejumlah pengukuran kompleksitas perangkat lunak kuantitatif

sudah diusulkan. Pengukuran semacam itu diaplikasikan pada tingkat kode dan

desain sehingga sulit digunakan selama perencanaan perangkat lunak (sebelum

kode dan desain ada). Tetapi perkiraan kompleksitas yang lain yang lebih

subyektif dibanding yang lain (seperti faktor penyesuaian kompleksitas function

point yang digambarkan) dapat dibuat pada awal proses perencanaan.

B. Ukuran Proyek

Ukuran proyek merupakan faktor penting lain yang dapat mempengaruhi

akurasi estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai

elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah

sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi

lebih sulit lagi karena elemen-elemen yang akan didekomposisi masih sangat

berat. Seperti dinyatakan dalam hukum Murphy: “Apa yang dapat salah

biarkanlah menjadi salah” – dan bila ada lebih banyak lagi yang dapat gagal,

maka disitu akan terjadi lebih banyak kegagalan.

C. Tingkat ketidakpastian Struktural

Tingkat ketidakpastian struktural juga berpengaruh dalam risiko estimasi.

Santayana pernah mengatakan, “Mereka yang tidak dapat mengingat masa lalu

terkutuk untuk mengulanginya lagi. “Dengan melihat kembali, kita dapat

mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat

dimana masalah muncul. Bila metrik perangkat lunak yang komprehensif dapat

diperoleh pada proyek yang telah lalu, maka estimasi dapat dilakukan dengan

kepastian yang lebih tinggi; jadwal dapat dibuat untuk menghindari kesulitan-




kesulitan yang terjadi dimasa lalu, dan risiko keseluruhan dapat dikurangi.

Resiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif

yang dibuat untuk sumber daya, biaya, dan jadwal. Bila ruang lingkup proyek

tidak dipahami dengan baik atau syarat proyek merupakan subjek terjadinya

perubahan, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana

perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface (yang

diisikan ke dalam spesifikasi sistem). Perencana, dan lebih penting lagi

pelanggan, harus mengetahui bahwa variabilitas pada kebutuhan perangkat

lunak berarti ketidakstabilan biaya dan jadwal.

Sebagai observasi akhir mengenai estimasi, kita perlu

mempertimbangkan apa yang pernah dikatakan oleh Aristoteles :Ini merupakan

tanda dari pikiran yang diperintah untuk menjadi puas dengan tingkat ketelitian

yang diijinkan oleh sifat dari sebuah subjek, dan tidak untuk mencari ketepatan

bila hanya perkiraan kebenaran saja yang dimungkinkan.

Manajer proyek tidak boleh obsesif terhadap penaksiran. Pendekatan-

pendekatan rekayasa perangkat lunak modern (seperti model proses

evolusioner) memakai pandangan pengembangan yang interaktif. Pada

pendekatan semacam ini dimungkinkan untuk melihat lagi penaksiran (bila lebih

banyak lagi informasi diketahui) dan merevisinya bila pelanggan mengubah

kebutuhannya.

2. Elemen Dasar dalam Penaksiran Proyek

Secara umum penakasiran proyek berimplikasi pada biaya. Sebagaimana sudah

diketahui bersama, proyek pengembangan perangkat lunak adalah sebuah jasa. Bahan

bakunya adalah waktu kerja setiap anggota timnya. Sehingga muara dalam penaksiran

proyek adalah membuat taksiran berapa lama waktu yang dibutuhkan tim untuk

menyelesaikan proyek tersebut. Dengan hitungan-hitungan sederhana, estimasi waktu

menjadi dasar dalam menghitung biaya proyek.Tentunya waktu keterlibatan setiap

anggota tim tidaklah sama. Akan sangat memboroskan kalau seorang anggota tim tetap

dialokasikan waktunya pada suatu tugas proyek, padahal dia belum dapat atau tidak lagi

mengerjakan apapun. Sehingga secara objektif harga sebuah proyek perangkat lunak




merupakan akumulasi dari biaya yang harus dibayarkan kepada setiap anggota tim

berdasarkan keterlibatannya.

Langkah-langkah Pendetilan

Untuk menghasilkan harga yang lebih teliti, langkah-langkah yang dapat dilakukan

adalah sebagai berikut :

1. Dekomposisi masalah

2. Definisikan secara detil task-task yang mesti ada pada setiap sub masalah

3. Definisikan anggota tim yang akan ditugaskan pada setiap task

4. Perkirakan waktu yang dibutuhkan oleh setiap anggota tim tersebut untuk

menyelesaikan suatu task

5. Tentukan tarif setiap anggota tim dalam pengerjaan proyek

6. Buat taksiran biaya lain-lain yang muncul, misalnya biaya akomodasi, biaya

atk, biaya peralatan, dan pembelian tools.

Kematangan setiap individu dalam tim akan mempengaruhi kebutuhan waktu

penyelesaian sebuah task yang ditugaskan kepadanya. Sehingga tim dengan

kematangan individu anggotanya yang rendah berdampak pada panjang kebutuhan

waktu. Disisi lain kematangan seorang individu juga mempengaruhi tarif yang ditetapkan

baginya.

3. Aspek Teknis

Pengkajian aspek teknis dilakukan sejajar dengan aspek-aspek lain setelah

penelitian pemasaran menunjukkan adanya faedah untuk melanjutkan studi kelayakan.

Maksud dan tujuan pengkajian aspek teknis adalah sebagai berikut:

• Pada tahap awal bertujuan untuk merumuskan gagasan yang timbul ke dalam

batasan yang konkret dari segi teknis.

• Hasil pengkajian aspek teknis dipakai sebagai masukan pengkajian aspek-

aspek lain.

• Akhirnya lingkungan aspek teknis sampai kepada kegiatan desain

engineering terinci, menghasilkan cetak biru (blue print) proyek yang

2 0 1 3 5 Manajemen Proyek Perangkat Lunak

Ida Nurhaida, ST., MT. 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:




• Waktu terbatas

• Sumber daya terbatas

Estimasi dalam proyek perangkat lunak memiliki ketidak pastian yang

cukup tinggi. Sehinga selagi proyek berjalan, estimasi mesti selalu disesuaikan

dan diperbaharui. Lebih khas lagi, estimasi biasanya membentuk suatu skenario

kasus terburuk dan kasus terbaik.

Proses perencanaan dapat dicapai melalui suatu proses penemuan

informasi yang menunjuk ke estimasi yang dapat dipertanggung jawabkan.

Tugas-tugas yang mesti ditangani oleh seorang perencana proyek sistem

perangkat lunak adalah:

• Mendefinisikan ruang lingkup system

• Mengidentifikasi kebutuhan-kebutuhan dalam pelaksanaan proyek

• Mengestimasi sumber daya yang diperlukan

2. Ruang Lingkup

Ruang lingkup merupakan pendeskripsi teknis proyek dalam suatu

statement yang dapat dimengerti pada tingkat manajemen dan teknis. Ruang

lingkup perangkat lunak menggambarkan:

• Fungsi

• Kinerja,

• Batasan

• Interface

• Keandalan

Fungsi-fungsi yang digambarkan dalam statement ruang lingkup

dievaluasi, untuk mendapatkan suatu model yang detil maka fungsi-fungsi

proses tersebut akan didekomposisi menjadi sub-sub fungsi yang pada akhirnya

akan memudahkan dalam estimasi jadwal dan biaya yang diorientasikan secara

fungsional.

Contoh :

Sebuah sistem perangkat lunak admisnitrasi akademik, akan menghasilkan

fungsi-fungsi sebagai berikut:




• Preparasi data mahasiswa

• Preparasi data kurikulum

• Pengisian KRS

• Menentukan kelas

• Mengoptimalkan jadwal

• Mengisi nilai

Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu

respon. Untuk contoh sistem informasi akademik diatas, kinerja akan

ditentukan oleh pengaturan jadwal suatu pemrosesan. Misalnya, perubahan

kurikulum harus sudah dilakukan sebelum pengisian KRS. Ketika ingin

diwujudkan suatu sistem yang online dan dapat diakses oleh seluruh

mahasiswa, masalah kemanan data menjadi ukuran kinerja sistem. Perangkat

lunak yang dikembangkan akan dibatasi oleh perangkat keras yang

diaksesnya.

Disamping informasi teknis yang didefinisikan dalam dokumen

kebutuhan pelanggan (customer request), diperlukan informasi-informasi lain

yang untuk mendefiniskan ruang lingkup antar lain:

1. Deskripsi pelanggan (yang meminta)

2. Pemakai

3. Karakteristik output yang baik menurut pemakai

4. Solusi yang akan diambil

3. Kebutuhan

Yang dimaksudkan sebagai kebutuhan dalam hal ini adalah segala

sesuatu yang diperlukan untuk mendukung proyek perangkat lunak. Kebutuhan

dapat dikelompokkan atas:

1. Literatur

2. Pelatihan khusus sumber daya

3. Fasilitas lain-lain

Dalam perencanaan proyek perangkat lunak, harus teridentifikasi dari

awal kebutuhankebutuhan yang diperlukan sehingga proyek dapat berjalan

sesuai dengan yang direncanakan.




4. Sumber Daya

Tugas selanjutnya seorang perencana proyek perangkat lunak adalah

mengestimasi kebutuhan sumber daya untuk pengembangan perangkat lunak,

yaitu:

1. Perangkat keras

2. Perangkat lunak (utilitas)

3. Lingkungan

4. Manusia

5. Estimasi Proyek

Estimasi proyek perangkat lunak meliputi:

1. Estimasi biaya

2. Estimasi waktu

Berikut adalah model sederhana penaksiran proyek:

No Dekomposisi Kualifikasi

Konsultan

Rate Man Scheduling

Days

Waktu

Nyata

Biaya

1. Sub Masalah 1

1.1. Task 1

1.1.1 Sub task 1

1.1.1.1. Sub sub task 1 Proyek Manajer $ 100 5 $ 500

1.1.1.2. Sub sub task 2 Sistem Analis 1 $ 80 12 $ 960

1.1.1.3. Sub sub task 3 Programmer 1 $ 60 6 $ 360

1.1.2. Sub task 2

Sub sub task 1 Sistem Analis 1 $ 80 20 $ 1.600

Sub sub task 2 Sistem Analis 2 $ 80 20 $ 1.600

dst

T o t a l $ xxxxxx




Pada umumnya perusahan memiliki batasan jumlah dana yang akan

diinvestasikan pada suatu proyek. Hal ini berarti tidak semua proyek yang

diajukan akan dijalankan. Beberapa proyek memiliki prioritas yang lebih tinggi

dibandingkan dengan yang lain. Sebagai contoh, proyek yang terkait dengan

pemerintahan akan memiliki prioritas yang lebih tinggi dibadingkan dengan

proyek-proyek yang lain.

Pemilihan proyek dapat dilakukan dengan dua cara sebagai berikut:

• Constrained optimization

• Benefit Comparison Methods

Umumnya organisasi menggunakan pendekatan ini. Benefit comparison

methods menggunakan accessible formulas, model perbandingan, and sistem

untuk menentukan proyek yang akan dikerjakan.

I. Referensi:

1. Software Engineering, Roger S. Pressman,McGrawHill 1997.

2. Management Information System, Raymond McLeod, Prentice Hall 2000.

3. Software Project Management for Dummies, Teresa Luckey, Joseph Phillips,

Wiley Publishing Inc., 2006.


2015 1

Manajemen Proyek Perangkat Lunak Pusat Bahan Ajar dan eLearning

Hendra Prastiawan, S.Si., M.T http://www.mercubuana.ac.id

MODUL PERKULIAHAN


Critical Success Factor


Fakultas Ilmu

Komputer

Informatika

09 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


2015 2



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 3



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 4



Sejalan dengan pendapat Atkinson diatas, penelitian lain oleh Shenhar et al.

(2001) [21], mengidentifikasi 4 dimensi kesuksesan yaitu:

• Efisiensi proyek

• Pengaruh pada pelanggan

• Kesuksesan bisnis secara langsung dan organisasional

• Mempersiapkan masa depan

Sedangkan Shatz (2006) [22] memaparkan tools yang dinamakan "slider" dalam

determinasi kesuksesan proyek, yaitu:

• Slider 1 : Level kepuasan Stakeholder

• Slider 2 : Sesuai dengan tujuan dan persyaratan

• Slider 3 : Sesuai Budget

• Slider 4 : Sesuai Deadline

• Slider 5 : Pesyaratan Added – Value

• Slider 6 : Persyaratan Kualitas

• Slider 7 : Kepuasan Tim

Songer dan Molenaar (1997) [23], menjabarkan 'criteria sukses dan suatu proyek

beserta definisinya seperti tercantum dalam tabel dibawah ini

Tabel 9.1 Kriteria Sukses dan Definisinya

Kriteria Sukses Definisi

Sesuai Budget Leri i i

Proyek disesuaikan pada atau didalam biaya

yang di-kontrak-an

Sesuai Jadwal Proyek diselesaikan pada atau sebelum

jadwal yang di-kontrak-an

Sesuai Spesifikasi Proyek yang diselesaikan sesuai atau melebihi

semua spesifikasi teknis yang disediakan

owner sesuai dengan

keinginan user

Proyek yang diselesaikan sesuai atau

melebihi tujuan fungsional yang diinginkan

oleh user tingkat kemampuan staff Proyek yang diselesaikan sesuai atau melebihi

pekerja yang

berkualitas tinggi

standar tingkat kemampuan pekerja yang

dapat diterima pada semua area


2015 5



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 cukup 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 6



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

Pimo

1996

Kerzner

1987

Pinto & Slevin 1989

Belassi & Tukel 1996

Wateridge 1995

Belout 1998

Clarke 1999

Coole-Daview 2002

Muller 2005

Corposite Understanding X X X Common Understanding with stakeholders on Success criteria

X

Executive Commitment X X X X

Organizational adaptability X

Communication X X X

Project manager selection criteria X X X X X

project manager leadership / empowerment X X X

X

X

Environment X


2015 7



Success Factors from the Literature

Pimo

1996

Kerzner

1987

Pinto &

Slevin 1989

Belassi & Tukel 1996

Wateridge 1995

Belout 1998

Clarke 1999

Coole-Daview 2002

Muller 2005

Commitment to planning & control X X X X X

Project mission / common goal / direction X

X

X X

top management support X X X

client consultation / acceptance X X X

monitor performance and feedback X X X X

personnel / teamwork X X X X X X X

Technical task ability X X X

Trouble shooting / risk management X X X

Project Ownership X X

Urgency of Project X X

Duration and size of Project X X X

Remarks : X Success factor(s) that is determined by the researcher either on a conceptual or empirical basis

Pada tabel 9.3, memperlihatkan perkembangan CSF untuk proyek yang

telah diringkas oleh Tom, Austeng, Mengesha (2004) [36], dimana CSF berkembang

dari pendekatan mekanistik pada determinasi proyek yang bergantung pada sistem

teknis murni menjadi kombinasi antara sistem sosial dan teknis

No Critical Success Factor Source, year

1 Technical Performance Ruben & Seeling, 1967

2 Project manager eksperience Ruben & Seeling, 1967

3 Project manager competence Sayles & Chandler, 1971

4 Schedulling Sayles & Chandler, 1971

5 Control system and responsibilities Sayles & Chandler, 1971

6 Monitoring & feed back Sayles & Chandler, 1971

7 Continous involment in the project Sayles & Chandler, 1971

8 Clear Goals Martin, 1976

9 General management support Martin, 1976

10 organize and delegate authorithy Martin, 1976

11 Clear Goals Baker, Murphy, and Fisher, 1983

12 Goal commitment of project team Baker, Murphy, and Fisher, 1983

13 adequate project team capability Baker, Murphy, and Fisher, 1983

14 Planning & control techniques Baker, Murphy, and Fisher, 1983

15 Task-Social orientation absence of bureucracy

Baker, Murphy, and Fisher, 1983

16 Project summary Clealand King, 1983

17 Top Management Support Clealand King, 1983


2015 8



18 Financial Support Clealand King, 1983

19 facility support Clealand King, 1983

20 market intelligent Clealand King, 1983

21 schedule Clealand King, 1983

22 manpower and organisation Clealand King, 1983

23 acquisition Clealand King, 1983

24 information and communication channels Clealand King, 1983

25 Project Objectives Morris and Hughes, 1987

26 Technical Innovation Uncertainty Morris and Hughes, 1987

27 Politics Morris and Hughes, 1987

28 Vommunity Involvement Morris and Hughes, 1987

29 Schedule duration urgency Morris and Hughes, 1987

30 Implementation problem Morris and Hughes, 1987

31 Project Objectives Pinto and Slevin, 1987

32 Top Management support Pinto and Slevin, 1987

33 Project planning Pinto and Slevin, 1987

34 Communication with client Pinto and Slevin, 1987

35 Human relations Pinto and Slevin, 1987

36 Technical task Pinto and Slevin, 1987

37 Client Acceptence Pinto and Slevin, 1987

38 Project Control Pinto and Slevin, 1987

39 Communication and problem handling Pinto and Slevin, 1987

40 Top management support Tuke & Rom, 1995

41 Client consultation Tuke & Rom, 1995

42 Availability of resources Tuke & Rom, 1995

43 Project manager performance Tuke & Rom, 1995

44 The project manager and team members Walid and Oya, 1996

45 The organization Walid and Oya, 1996

46 Early and continual client consultation Pinto and Kharbanda, 1995

47 Technology Pinto and Kharbanda, 1995

48 Schedulling system Pinto and Kharbanda, 1995

49 Project team Pinto and Kharbanda, 1995

50 Top management support and continual " 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 9



banyak berkembang dan pengembangan teoritis telah mengarah pada prinsip-

prinsip organisasi dan tingkah laku (behaviour).

Naoum, Fong, dan Walker (2004) [38], dalam penelitiannya dalam

mengidentifikasi CSF yang berkontribusi pada keberhasilan suatu manajemen

proyek, menemukan bahwa terdapat 10 CSF, yaitu:

1. Pembentukan tujuan proyek dan 'criteria klien

2. Tingkat partisipasi tim proyek dalam decision making

3. Kejelasan scope dan definisi pekerjaan

4. Karakteristik manajer proyek

5. Organisasi klien

6. Kerjasama tim proyek

7. Teknik perencanaan dan programming

8. Proses seleksi dalam pembentukan tim

9. Kewenangan dan pengaruh manajer proyek

10. Estimasi biaya proyek

Penelitian atas CSF memiliki manfaat yang sangat signifikan terutama dalam

bidang konstruksi dan Manajemen Proyek, diantaranya adalah (Permono, 2010):

1. Untuk meminimalisir variasi yang banyak sepanjang implementasi proyek.

2. Untuk mengantisipasi efek-efek yang mungkin terjadi, kemudian memilih

metode y ang dapat diterapkan untuk mengatasinya

3. Dapat memprediksi kesuksesan proyek, yang disertai dengan

tindakan¬tindakan: menolak proyek yang berpotesi tidak sukses,

mengidentifkasi proyek yang layak untuk dikerjakan, mengidentifikasi

masalah pada proyek yang sedang berjalan dan mengambil tindakan

koreksi

4. Lebih memungkinkan pencapaian kepuasan client, mempertahankan

reputasi, dan mendapatkan kontrak tambahan dalam kompetisi yang terus

meningkat

I. Referensi:


2015 10



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 1



MODUL PERKULIAHAN


Jaminan Kualitas Perangkat Lunak


Fakultas Ilmu

Komputer

Informatika

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


2015 2



1. Pengantar

1. Pendahuluan

Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan

pada seluruh proses perangkat lunak.

Jaminan kualitas perangkat lunak atau software quality assurance meliputi:

1. Pendekatan manajemen kualitas.

2. Teknologi rekayasa perangkat lunak yang efektif (metode dan peranti).

3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses

perangkat lunak.

4. Strategi pengujian multitiered (deret bertingkat).

5. Kontrol dokumentasi perangkat lunak dan perubahan.

6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan

perangkat lunak.

7. Mekanisme pengukuran dan pelaporan.

2. Kontrol kualitas

Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian

yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa

setiap produk memenuhi persyaratan yang ditetapkan.

Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki

spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat

membandingkan output dari setiap proses. Kalang (loop) menjadi penting untuk

meminimalkan cacat yang dihasilkan.

3. Kontrol kualitas

Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.

Tujuan jaminan kualitas adalah untuk memberikan data yang diperlukan oleh


2015 3



manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat

memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran.

4. Biaya kualitas

Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar

kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi

tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas

yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya

kualitas serta memberikan basis perbandingan yang ternormalisasi.

Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan:

a) Pencegahan

Biaya pencegahan meliputi:

1) Perencanaan

2) Kajian teknis formal

3) Perlengkapan pengujian

4) Pelatihan

b) Penilaian

Biaya penilaian meliputi:

1) Inspeksi in-proses dan interproses

2) Pemeliharaan dan kalibrasi peralatan

3) Pengujian

c) Kegagalan

Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang

muncul sebelum produk disampaikan kepada pelanggan.

1) Biaya kegagalan internal

Biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk

sebelum produk dipasarkan. Biaya kegagalan internal meliputi:

• Pengerjaan kembali

• Perbaikan

• Analisis mode kegagalan


2015 4



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 5



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 6



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 7



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 783

Kajian tidak


2015 8



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 9



10. Kajian Teknik Formal

Selama FTR, seorang pengkaji (pencatat) secara aktif mencatat semua masalah

yang sudah dimunculkan, yang kemudian dirangkum pada akhir pertemuan sehingga

dihasilkan daftar masalah kajian. Sebagai tambahan, laporan rangkuman kajian yang

sederhana telah diselesaikan di mana rangkuman kajian merupakan jawaban dari tiga

pertanyaan berikut:

1. Apa yang dikaji?

2. Siapa yang melakukan?

3. Penemuan apa yang dihasilkan dan apa kesimpulannya?

Daftar masalah kajian mempunyai dua tujuan:

1. Mengidentifikasi area masalah pada produk.

2. Daftar item kegiatan yang menjadi petunjuk bagi prosedur saat

koreksi dilakukan. Daftar masalah biasanya dilampirkan pada

laporan.

11. Pedoman Kajian

Pedoman untuk melakukan kajian teknis formal harus dilakukan sebelumnya,

didistribusikan kepada semua pengkaji, disetujui, dan kemudian dilaksanakan. Kajian yang

tidak terkontrol sering dapat menjadi lebih buruk daripada bila tidak ada kajian sama sekali.

Berikut ini serangkaian pedoman minimum untuk kajian teknis formal:

1. Kajian produk, bukan produser.

2. Menetapkan agenda dan menjaganya.

3. Membatasi perdebatan dan bantahan.

4. Menetapkan area masalah, tetapi tidak tergoda untuk menyelesaikannya

setiap masalah yang dicatat.

5. Mengambil catatan tertulis.

6. Membatasi jumlah peserta dan mewajibkan persiapan awal.

7. Mengembangkan daftar bagi masing masing produk kerja yang akan dikaji.

8. Mengalokasikan sumber-sumber daya dan jadwal waktu untuk FTR.

9. Melakukan pelatihan bagi semua pengkaji.


2015 10



10. Mengkaji kajian awal Anda.

12. Pendekatan Formal Terhadap SQA

Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai

melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar

pengembangan perangkat lunak yang diterima.

Pada lebuh dari dua dekade, segmen komunitas rekayasa perangkat lunak yang kecil

tetapi vokal telah memperlihatkan bahwa dibutuhkan suatu pendekatan yang lebih formal

terhadap jaminan kualitas perangkat lunak. Pembuktian matematis terhadap kebenarannya

dapat diaplikasikan untuk menunjukkan bahwa program menyesuaikan diri secara tepat

dengan spesifikasinya.

13. Pendekatan Formal Terhadap SQA

Jaminan kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh

industri untuk menjadi lebih kuantitatif terhadap kualitas. Pada perangkat lunak, jaminan

kualitas statistik mengimplikasikan langkah-langkah berikut ini:

1. Informasi tentang cacat perangkat lunak dikumpulkan dan dipilah-

pilahkan.

2. Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai

ke penyebab pokoknya.

3. Dengan menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri

sampai 20 persen dari semua kemungkinan penyebab), mengisolasi yang 20

persen tersebut (vital few).

4. Sekali penyebab vital few telah diidentifikasi, beralih untuk

membetulkan maslah yang menyebabkan cacat.

Banyak kesalahan ditemukan pada waktu perangkat lunak sedang dalam

proses pengembangan. Cacat yang lain ditemukan setelah perangkat lunak

diluncurkan kepada pemakai akhir. Meskipun ratusan kesalahan yang berbeda

diluncurkan, semuanya dapat ditelusuri dari satu (atau lebih) penyebab berikut ini:

1. Spesifikasi yang tidak lengkap atau keliru (IES)


2015 11



2. Kesalahan interpretasi komunikasi pelanggan (MMC)

3. Deviasi intersioanl dari spesifikasi (IDS)

4. Pelanggaran standar pemrograman (VPS)

5. Kesalahan dalam representasi data (EDRIMI)

6. Kesalahan dalam logika desain (EDL)

7. Interface modul yang tidak konsisten (IMI)

8. Pengujian yang tidak lengkap atau keliru (IET)

9. Dokumentasi yang tidak lengkap atau tidak akurat (IID)

10. Kesalahan dalam penerjemahan bahasa pemrograman desain (PLT)

11. Antarmuka manusia dengan komputer yang tidak konsisten atau

mengandung ambiguitas (HCI)

12. Dan msih banyak lagi (MIS)

I. Referensi: 1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997

2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004

3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,2006


2015 1



MODUL PERKULIAHAN


Negosiasi


Fakultas Ilmu

Komputer

Informatika

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


2015 2



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 3



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 4



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 5



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 6



stabil, berkelanjutan dan mengarahkan perilaku yang lebih taktis. Taktik merupakan

bagian dari strategi yang lebih terstruktur, terarah dan terdorong oleh pertimbangan

strategis.

Bagaimana hubungan antara strategi dan perencanaan ? Perencanaan

merupakan bagian dari proses strategi. Bagaimana perencanaan dihasilkan akan

menjadi petunjuk yang strategis. 4 tipe strategi untuk negosiasi adalah:

1. Kompetisi (Competition)

2. Kolaborasi (Collaboration)

3. Akomodasi (Accommodation)

4. Menghindar (Avoidance)

Kunci sukses negosiasi bukanlah bagaimanana proses negosiasi itu sendiri yang

dapat dianggap permainan ataupun sandiwara, namun perencanaan yang handal

sebelum dilakukannya negosiasi.

Kelemahan di dalam melakukan perencanaan sebelum melakukan negosiasi

adalah keterbatasan waktu untuk membuat rencana, antara lain:

1. Negotiator gagal menyusun tujuan yang jelas

2. Negotiator tidak dapat mengetahui kekuatan dan kelemahannya untuk

mendukung posisinya terhadap argument pihak lawan

3. Negotiator tidak cukup cepat dan pandai untuk memberi dan menerima hasil

negosiasi yang dapat membuat situasi down, dimana pihak lawan menyerang

dengan cara-cara yang mungkin saja bisa bertentangan dengan ketentuan, tidak

mempuyai dasar yang kuat ataupun tidak efektif.

Perencanaan negosiasi yang efektif mencakup:

1. Definisikan isu-isu (defining issues)

2. Kumpulkan isu-isu dan definisikan scenario tawar menawar (assembling

issues and defining the bargaining mix)

3. Definisikan kepentingan (defining interest)

4. Konsultasi dengan pihak lain (consulting with others)

5. Identifikasi Batasan (Identifying Limits)

6. Tetapkan sasaran (Setting Targets)

7. Kembangan pendapat-pendapat yang menudukung (Developing

supporting arguments)


2015 7



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 8



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 9



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 10



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 11



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 12



3. Menjaga agar isu tetap dalam koridor terkontrol sehingga tidak akan menjadi isu

yang bertambah atau lebih besar dan menjadi isu yang kelompok-kelompok kecil

4. Tentukan posisi komunalitas, cara-cara untuk mendefinisikan isu-isu untuk dapat

mencapai tujuan kedua belah pihak ( kerangka yang terintegrasi ) dan tujuan

lainnya yang akan menyatukan pihak-pihak yang bernegosiasi mencapai tujuan

bersama

5. Ciptakan suasana dimana setiap pihak yang bernegosiasi memilki pilihan yang

diinginkan sesuai yang diharapkan dan nyaman untuk pihak lawan dengan cara

mengemas usulan yang lebih baik

I. Referensi:

1. Astra Human resources Management. 2001. Jakarta, Astra International

2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and

Management, New York, McGraw-Hill International Edition.

3. Hariwijaya. 2010. Strategi Lobi dan Negosiasi, Yogyakarta, Oriza.

4. Jimmy Joses Sembiring. Smart HRD. 2010. Jakarta, Visimedia.

5. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media

Group.


2015 1



MODUL PERKULIAHAN


Kerjasama Tim


Fakultas Ilmu

Komputer

Informatika

12 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


2015 2



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 3



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 4



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 5



Pentingnya perancangan tim yang baik diuraikan Griffin (2004) dengan membagi ke

dalam 4 (empat) tahap perkembangan, yaitu:

1. Forming

Forming (pembentukan), adalah tahapan di mana para anggota setuju

untuk bergabung dalam suatu tim. Karena kelompok baru dibentuk maka setiap

orang membawa nilai-nilai, pendapat dan cara kerja sendiri-sendiri. Konflik

sangat jarang terjadi, setiap orang masih sungkan, malu-malu, bahkan seringkali

ada anggota yang merasa gugup. Kelompok cenderung belum dapat memilih

pemimpin (kecuali tim yang sudah dipilih ketua kelompoknya terlebih dahulu).

2. Storming

Storming (merebut hati), adalah tahapan di mana kekacauan mulai timbul di

dalam tim. Pemimpin yang telah dipilih seringkali dipertanyakan kemampuannya

dan anggota kelompok tidak ragu-ragu untuk mengganti pemimpin yang dinilai

tidak mampu. Faksi-faksi mulai terbentuk, terjadi pertentangan karena masalah-

masalah pribadi, semua bersikeras dengan pendapat masing-masing.

Komunikasi yang terjadi sangat sedikit karena masing-masing orang tidak mau

lagi menjadi pendengar.

3. Norming

Norming (pengaturan norma), adalah tahapan di mana individu-individu dan

subgroup yang ada dalam tim mulai merasakan keuntungan bekerja bersama

dan berjuang untuk menghindari team tersebut dari kehancuran (bubar). Karena

semangat kerjasama sudah mulai timbul, setiap anggota mulai merasa bebas

untuk mengungkapkan perasaan dan pendapatnya kepada seluruh anggota tim.

4. Performing

Performing (melaksanakan), adalah tahapan merupakan titik kulminasi di mana

team sudah berhasil membangun sistem yang memungkinkannya untuk dapat

bekerja secara produktif dan efisien. Pada tahap ini keberhasilan tim akan

terlihat dari prestasi yang ditunjukkan.


2015 6



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 7



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 8



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 9



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 10



peringkat untuk setiap kelompok. Apa yang terjadi? Kesimpulan rata-rata kelompok

mendekati jawaban yang telah diberikan. Bahkan apabila hasil dari setiap kelompok

disatukan dan diambil rata-ratanya, maka penilaian dari setiap kelompok hampir sama

dengan penilaian para ahli di bidang tersebut.

Demonstrasi nyata lain mengenai prinsip sinergi dapat kita lihat pula dalam

kontes kuda penghela dalam kontes kuda penghela di suatu pekan raya kota. Kuda

juara dalam kontes tersebut mampu menghela gerobak seberat 2.250 kilogram. Juara

kedua sanggup menarik beban sebesar 2.000 kilogram. Dalam teori, berarti kedua kuda

tersebut secara bersama-sama harus mampu menggerakkan maksimum 4.250

kilogram. Untuk uji coba teori tersebut, pemilik kedua kuda memadukan kedua kuda dan

membebaninya dengan gerobak. Semua orang yang melihat terperangah. Kedua kuda

tersebut mampu menarik beban seberat 6.000 kilogram, atau 1.750 kilogram lebih berat

dibanding jumlah upaya yang mampu mereka lakukan sendiri-sendiri. Sinergi dapat

dipakai untuk menyatukan tenaga individu, menutup keterbatasan individu, untuk

menggandakan upaya individu, supaya sasaran yang lebih banyak dan lebih besar

dapat dicapai.

I. Referensi:

1. Astra Human resources Management. 2001. Jakarta, Astra International




Group.


2015 1



MODUL PERKULIAHAN


Manajemen Kualitas Suatu Proyek


Fakultas Ilmu

Komputer

Informatika

13 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


2015 2



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 3



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 4



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 5



manajemen puncak". Kebijakan mutu organisasi melakukan sering dapat

diadopsi "sebagaimana adanya" untuk digunakan oleh proyek ini. Namun, jika

organisasi melakukan tidak memiliki kebijakan mutu formal, atau jika proyek

tersebut melibatkan beberapa organisasi yang melakukan (seperti dengan

perusahaan patungan), maka tim manajemen proyek akan perlu untuk

mengembangkan kebijakan mutu untuk proyek tersebut. Terlepas dari asal

kebijakan mutu, tim manajemen proyek bertanggung jawab untuk memastikan

bahwa para stakeholder proyek sepenuhnya menyadari hal itu.

• Lingkup pernyataan. Pernyataan lingkup adalah masukan kunci untuk perencanaan

mutu karena kiriman dokumen proyek besar, serta tujuan proyek yang berfungsi untuk

menetapkan persyaratan stakeholder penting.

• Produk deskripsi. Meskipun unsur-unsur deskripsi produk dapat diwujudkan dalam

pernyataan ruang lingkup, deskripsi produk seringkali akan berisikan detil tentang

masalah teknis dan masalah lainnya yang dapat mempengaruhi kualitas

perencanaan.

• Standar dan peraturan. Tim manajemen proyek harus mempertimbangkan standar

aplikasi setiap daerah khusus atau peraturan yang dapat mempengaruhi proyek.

• Proses output lainnya. Selain pernyataan lingkup dan deskripsi produk, proses di

daerah pengetahuan lainnya dapat menghasilkan output yang harus dianggap sebagai

bagian dari perencanaan mutu. Sebagai contoh, pengadaan perencanaan dapat

mengidentifikasi persyaratan kualitas kontraktor yang harus tercermin dalam rencana

manajemen mutu secara keseluruhan.

2. Alat dan Teknik Perencanaan Kualitas

• Analisis manfaat/biaya. Proses perencanaan kualitas harus mempertimbangkan

pengorbanan biaya manfaat. Manfaat utama dari memenuhi persyaratan kualitas

pengerjaan ulang kurang, yang berarti produktivitas yang lebih tinggi, biaya lebih

rendah, dan kepuasan stakeholder meningkat. Biaya utama memenuhi persyaratan

kualitas adalah biaya yang terkait dengan kegiatan manajemen kualitas proyek. Jelas

sekali dari disiplin manajemen mutu yang manfaat lebih besar daripada biaya.

• Pembandingan. Pembandingan melibatkan membandingkan praktek proyek aktual

atau yang direncanakan untuk orang-orang dari proyek lain untuk menghasilkan ide-

ide untuk perbaikan dan untuk menyediakan sebuah standar yang digunakan untuk


2015 6



mengukur kinerja. Proyek-proyek lain mungkin berada dalam organisasi untuk

melakukan atau di luar itu, dan mungkin dalam wilayah aplikasi yang sama atau di

negara lain.

• Flowchart. Sebuah diagram alir adalah setiap diagram yang

menunjukkan bagaimana berbagai elemen dari suatu sistem

berkaitan. 1. Flowchart teknik yang umum digunakan dalam

manajemen mutu meliputi:

➢ Diagram penyebab-akibat, juga disebut diagram Ishikawa atau diagram tulang

ikan, yang menggambarkan bagaimana berbagai faktor yang mungkin terkait

dengan potensi masalah atau efek. Gambar 8-2 adalah contoh umum diagram

sebab-akibat.

➢ Sistem atau proses flow chart, yang menunjukkan bagaimana berbagai

elemen dari suatu sistem saling berhubungan. Gambar 8-3 adalah contoh

diagram alir proses untuk review desain.

➢ Flowchart dapat membantu tim proyek mengantisipasi apa dan dimana

masalah kualitas mungkin terjadi, dan dengan demikian dapat membantu

mengembangkan pendekatan untuk memperbaiki masalah tersebut.

• Desain eksperimen. Desain eksperimen adalah metode statistik yang membantu

mengidentifikasi faktor yang mungkin mempengaruhi variabel tertentu. Teknik ini

paling sering diterapkan pada produk dari proyek (misalnya, desainer otomotif

mungkin ingin menentukan kombinasi suspensi dan ban akan menghasilkan

karakteristik perjalanan paling diinginkan dengan biaya yang wajar). Namun, juga

dapat diterapkan untuk proyek masalah manajemen, seperti pengorbanan biaya dan

jadwal. Misalnya, insinyur senior akan biaya lebih dari insinyur junior, tetapi juga dapat

diharapkan untuk menyelesaikan pekerjaan yang ditugaskan dalam waktu kurang.

Sebuah "percobaan" dirancang tepat (dalam hal ini, komputasi biaya proyek dan

jangka waktu untuk berbagai kombinasi insinyur senior dan junior) sering akan

memungkinkan penentuan solusi optimal dari sejumlah kasus yang relatif terbatas.

• Biaya kualitas. Biaya kualitas mengacu pada biaya total dari semua upaya untuk

mencapai produk/kualitas layanan, dan mencakup semua bekerja untuk memastikan

kesesuaian dengan persyaratan, serta semua karya yang dihasilkan dari

ketidaksesuaian dengan kebutuhan. Ada tiga jenis biaya yang terjadi: biaya


2015 7



pencegahan, biaya penilaian, dan biaya kegagalan, di mana yang terakhir ini dipecah

menjadi biaya internal dan eksternal.

3. Keluaran dari Kualitas Perencanaan

• Rencana pengelolaan kualitas. Rencana manajemen mutu harus menjelaskan

bagaimana tim manajemen proyek akan menerapkan kebijakan kualitasnya. Dalam

ISO 9000 istilah, harus menjelaskan sistem kualitas proyek: "struktur organisasi,

tanggung jawab, prosedur, proses, dan sumber daya yang dibutuhkan untuk

menerapkan manajemen mutu". Rencana manajemen mutu memberikan masukan

terhadap rencana proyek secara keseluruhan dan harus ditujukan pada pengendalian

mutu, jaminan mutu, dan peningkatan kualitas proyek. Rencana manajemen mutu

dapat formal maupun informal, sangat rinci, atau luas berbingkai,

berdasarkan persyaratan proyek.

• Operasional definisi. Definisi operasional menjelaskan, dalam hal yang sangat spesifik,

apa sesuatu itu dan bagaimana ia diukur oleh proses kontrol kualitas. Sebagai contoh,

tidak cukup untuk mengatakan bahwa pertemuan tanggal jadwal yang direncanakan

adalah ukuran kualitas manajemen, tim manajemen proyek juga harus menunjukkan

apakah setiap kegiatan harus mulai tepat waktu atau hanya selesai tepat waktu;

apakah aktivitas individu akan diukur, atau hanya deliverables tertentu, dan jika

demikian, yang mana. definisi operasional juga disebut metrik di beberapa area

aplikasi.

• Daftar pembanding. Checklist adalah alat terstruktur, biasanya unsur tertentu,

digunakan untuk memverifikasi bahwa satu set langkah yang diperlukan telah

dilakukan. Daftarpembanding mungkin sederhana atau kompleks. Mereka biasanya

diungkapkan sebagai imperatif ("Lakukan ini!") Atau interrogatories ("Apakah Anda

melakukan ini?"). Banyak organisasi telah daftar standar tersedia untuk memastikan

konsistensi dalam tugas-tugas sering dilakukan. Di beberapa daerah aplikasi, daftar

juga tersedia dari asosiasi profesional atau penyedia layanan komersial.

• Masukan pada proses lainnya. Proses perencanaan mutu dapat

mengidentifikasi kebutuhan untuk kegiatan lebih lanjut di daerah lain.

3. Penjaminan Kualitas


2015 8



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 9



• Peningkatan kualitas. Peningkatan kualitas termasuk mengambil tindakan untuk

meningkatkan efektivitas dan efisiensi dari proyek untuk memberikan manfaat tambahan

bagi para pemangku kepentingan proyek. Dalam kebanyakan kasus, peningkatan kualitas

pelaksanaan akan membutuhkan persiapan permintaan perubahan atau mengambil

tindakan korektif, dan akan ditangani sesuai dengan prosedur pengendalian perubahan yang

terintegrasi.

4. Pengendalian Mutu (quality control)

Kendali mutu melibatkan hasil pemantauan proyek spesifik untuk menentukan

apakah mereka memenuhi standar mutu yang relevan, dan mengidentifikasi cara untuk

menghilangkan penyebab hasil yang tidak memuaskan. Ini harus dilakukan selama proyek.

hasil proyek meliputi hasil produk keduanya, seperti kiriman, dan hasil manajemen proyek,

seperti biaya dan kinerja jadwal. Kontrol kualitas sering dilakukan oleh Departemen Quality

Control atau yang serupa pada unit organisasi, tetapi tidak harus.

Tim manajemen proyek harus memiliki pengetahuan tentang pengendalian kualitas

statistik, terutama sampling dan probabilitas, untuk membantu mengevaluasi output kontrol

kualitas. Di antara mata pelajaran lainnya, tim mungkin berguna untuk mengetahui

perbedaan antara:

• Pencegahan (kesalahan menjaga dari proses) dan pemeriksaan (kesalahan menjaga dari

tangan pelanggan).

• Atribut Sampling (hasilnya sesuai, atau tidak) dan sampling variabel (hasilnya adalah nilai

pada skala kontinu yang mengukur tingkat kesesuaian).

• Khusus menyebabkan (kejadian luar biasa) dan menyebabkan acak (variasi proses normal).

• Toleransi (hasilnya dapat diterima jika berada dalam kisaran yang ditentukan oleh toleransi)

dan batas kontrol (proses ini dalam kendali jika hasilnya jatuh dalam batas-batas kontrol).

I. Referensi: 1. A Guide to the Project Management Body of Knowledge.




2015 10




Group.


2015 1



MODUL PERKULIAHAN


Analisa Waktu (SPA dan SPL)


Fakultas Ilmu

Komputer

Informatika

14 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


2015 2



1. Analisa Waktu

1. Pendahuluan

Alasan dilakukan analisa waktu dalam penerapan network planning pada

penyelenggaraan proyek, antara lain:

1. Analisa waktu merupakan langkah pertama sebelum melakukan analisa lebih

lanjut yaitu analisa sumber daya dan analisa biaya.

2. Untuk melakukan analisa waktu pada tahap perencanaan (disain model), data

yang diperlukan relatif tidak terlalu sukar penyediaannya.

3. Untuk melakukan analisa waktu pada tahap pemakaian (operasi) pengumpulan

dan pengolahan datanya relatif lebih mudah.

Yang dimaksud dengan analisa waktu dalam penyelenggaraan proyek adalah

mempelajari tingkah laku pelaksanaan kegiatan selama penyelenggaraan proyek.

Dengan analisa waktu ini diharapkan bisa ditetapkan skala prioritas pada tiap tahap, dan

bila terjadi perubahan waktu pelaksanaan kegiatan, segera bisa diperkirakan akibat-

akibatnya sehingga keputusan yang diperlukan dapat segera diambil.

Ada beberapa tujuan analisa waktu, antara lain:

1. Dengan analisa waktu memungkinkan disesuaikannya umur perkiraan proyek

dengan umur proyek yang direncanakan dengan cara yang rasional, sepanjang

masih memungkinkan.

2. Umur rencana proyek dapat ditentukan lamanya sesuai dengan tingkat

probabilitas yang dikehendaki.

3. Untuk menekan tingkat ketidakpastian dalam waktu pelaksanaan selama

penyelenggaraan proyek, dengan demikian diharapkan timing yang tepat bisa

ditentukan. Dan dengan menentukan timing yang tepat analisa sumber daya dan

analisa biaya, segera bisa dilakukan.

4. Cara kerja yang efisien bisa diselenggarakan sehingga waktu penyelenggaraan

menjadi efisien pula.

2. Faktor Penentu Lama Kegiatan


2015 3



Lama kegiatan adalah jangka waktu yang dibutuhkan untuk menyelesaikan

kegiatan yang bersangkutan, yaitu mulai dari saat awal pada saat kegiatan mulai

dikerjakan sampai dengan saat akhir pada saat kegiatan selesai dikerjakan. Adapun

satuan untuk mengukur lama kegiatan tergantung dari macam kegiatannya, bisa dalam

detik, menit, jam atau hari, dan sebagainya.

Ada 2 faktor penentu lama kegiatan, yaitu:

1. Faktor teknis, antara lain ; volume pekerjaan, sumber daya, ruangan, jam kerja

per hari, dan sebagainya.

2. Faktor non teknis, antara lain ; banyaknya hari kerja dalam seminggu, banyaknya

hari libur, cuaca, dan sebagainya.

3. Cara Menentukan Lama Kegiatan

A. Cara rata-rata

Cara rata-rata relatif mudah namun kurang tepat atau kurang memadai

dikarenakan menyamaratakan tiap kasus meskipun pada kenyataannya masing-

masing kasus terdiri dari tiap kasus yang berbeda-beda.

Contoh:

Diketahui:

Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 6 kasus

(alternatif), sebagai berikut:

KASUS LAMA KEGIATAN (HARI)

1 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

1 10 1


2015 4



2 3 4 5 6

11 12 13 14 15

1 1 1 1 1

Jumlah 75 6

LPER = 75 / 6 = 12.5 hari

B. Cara pembobotan

Cara pembobotan relatif lebih tepat dibandingkan cara rata-rata, karena

memperhatikan jumlah dan peran kejadian tiap kasus. Namun cara ini sukar

karena perlu data yang relatif banyak.

Contoh:

Diketahui:


dengan masing-masing kejadian, sebagai berikut:

Kasus Lama Kegiatan (Hari) Jumlah Kejadian

1 2 3 4 5 6

10 11 12 13 14 15

100 200 350 500 250 100

Diminta:


Jawab:

Kasus Lama Kegiatan (Hari)

Jumlah Kejadian

Bobot

1 2 3

10 11 12

100 200 350

10 * 100 = 1.000 11 * 200 = 2.200 12 * 350 = 4.200


2015 5



4 5 6

13 14 15

500 250 100

13 * 500 = 6.500 14 * 250 = 3.500 15 * 100 = 1.500

1.500 18.900

LPER = Jumlah Bobot = 18.900 = 12.6 hari

Jumlah Peristiwa 1.500

C. Cara lintasan kritis

Cara lintasan kritis merupakan cara yang memiliki keuntungan dari kedua cara

tersebut diatas, karena membutuhkan data relatif lebih sedikit tetapi tetap

memperhatikan peran kejadian tiap kasus.

Pertimbangan terakhir dalam penentuan cara yang akan dipakai, bergantung

pada tersedianya data dan tingkat kebenaran data yang tersedia tersebut. Lama

kegiatan hasil dari ketiga cara tersebut masing-masing disebut lama kegiatan

perkiraan (LPER) dan masing-masing dianggap mempunyai kemungkinan

berhasil 50% dan mempunyai kemungkinan gagal 50%.

Contoh:

Diketahui:


(tidak mungkin lebih atau kurang dari 3 kasus), sebagai berikut ;

Kasus Lama Kegiatan (Hari)

Jumlah Kejadian

1 (LO) 2 (LM) 3 (LP)

10 13 15

LO = Lama kegiatan optimis LM = Lama kegiatan most likely (yang paling sering terjadi) LP = Lama kegiatan pesimis

Diminta:


Jawab ;

LPER = 1 * LO + 4 * LM + 1 * LP

6

LPER = 1 * 10 + 4 * 13 + 1 * 15 = 12.8

6


2015 6



2. Saat Paling Awal (SPA)

Saat paling awal (SPA) maksudnya adalah saat paling awal suatu peristiwa

mungkin terjadi, dan tidak mungkin terjadi sebelumnya. Penentuan SPA ini bertujuan

untuk mengetahui saat paling awal mulai melaksanakan kegiatan-kegiatan yang keluar

dari peristiwa yang bersangkutan.

Ada beberapa syarat yang harus dipenuhi untuk menentukan atau menghitung

saat paling awal semua peristiwa-peristiwa pada sebuah network diagram, antara lain;

1. Network diagram yang tepat telah tersedia.

2. Nomor-nomor peristiwa ditetapkan menurut atau memenuhi persyaratan yaitu

peristiwa awal network diagram diberi nomor 1, peristiwa akhir diberi nomor

maksimum yang sama dengan banyaknya peristiwa yang ada di network yang

bersangkutan.

3. Semua kegiatan yang ada dalam network diagram telah ditetapkan lama

kegiatan perkiraan.

Secara formatif untuk menentukan saat paling awal suatu peristiwa adalah

sebagai berikut:

1. Sebuah kegiatan menuju ke sebuah peristiwa

Keterangan ;

SPA j = SPA I + L

X = Kegiatan

j = Peristiwa akhir kegiatan X

i = Peristiwa awal kegiatan X

L = Lama kegiatan X yang diperkirakan

SPA i = Saat paling awal peristiwa awal

SPA j = Saat paling awal peristiwa akhir


2015 7



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 8



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 9



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 10



Keterangan ;

1) Pada posisi atau peristiwa posisi 2 menuju 3, maka SPL 2 = 9 – 5 = 4

2) Pada posisi atau peristiwa dari posisi 3 menuju posisi 4 lebih kecil jumlah waktu

lambatnya (7 – 3 = 4) dibandingkan posisi atau peristiwa dari posisi 3 menuju posisi

6 (14 – 9 = 5), sehingga pada kasus tersebut SPL i pada posisi atau peristiwa 3

diambil waktu yang minimum adalah 4.

I. Referensi: 1. A Guide to the Project Management Body of Knowledge.




fasilkom.mercubuana.ac.idfasilkom.mercubuana.ac.id/.../manajemen-proyek-perangkat-lunak-ti.pdf ·...

Documents