Manajemen Proyek Perangkat Lunak

Transkripsi

1 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Pengantar Manajemen Proyek Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini akan dijelaskan mengenai dasar manajemen proyek Kompetensi Mahasiswa memiliki gambaran umum tentang isi dari manajemen proyek perangkat lunak 1

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

3 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 : 3

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

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

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

7 Gambar 2.2 Fase Daur Hidup Proyek (Sumber : Schwalbe, 2006, p55) 6. System Development Life Cycle (SDLC) Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah kerangka kerja untuk menggambarkan tahap tahap yang terlibat dalam pengembangan sistem informasi. Salah satu model yang popular dan banyak digunakan dalam daur hidup pengembangan sistem adalah model Waterfall. 7. Model Waterfall Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran umpan balik antara tahapan tahapan dari pengembangan software untuk meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan tahapan yang meliputi : System feasibility, software plans and requirement, product design, detailed design, code, integration, implementation, operation and maintenance. Kelebihan dari model Waterfall adalah : 1. Mendukung perencanaan sebelum dilakukannya proses desain. 2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan. 3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek. 4. Menyediakan suatu struktur proyek. Kekurangan dari model Waterfall adalah : 1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi. 7

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

9 Gambar 2.3 Model Waterfall (Sumber : 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 9

10 menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek dengan baik. I. Referensi 1. Schwalbe. Kathy Introduction to Project Management. Course Technology Inc. ISBN: Olson, David Introduction to Information Systems Project Management, 2nd Ed. ISBN: Larson, Erick. W Project management: the managerial process. 10

11 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Pengantar Manajemen Proyek (Lanjutan) Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini akan dijelaskan mengenai dasar manajemen proyek Kompetensi Mahasiswa memiliki gambaran umum tentang isi dari manajemen proyek perangkat lunak 1

12 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 2

13 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 : 3

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

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

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

17 Gambar 2.2 Fase Daur Hidup Proyek (Sumber : Schwalbe, 2006, p55) 6. System Development Life Cycle (SDLC) Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah kerangka kerja untuk menggambarkan tahap tahap yang terlibat dalam pengembangan sistem informasi. Salah satu model yang popular dan banyak digunakan dalam daur hidup pengembangan sistem adalah model Waterfall. 7. Model Waterfall Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran umpan balik antara tahapan tahapan dari pengembangan software untuk meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan tahapan yang meliputi : System feasibility, software plans and requirement, product design, detailed design, code, integration, implementation, operation and maintenance. Kelebihan dari model Waterfall adalah : 1. Mendukung perencanaan sebelum dilakukannya proses desain. 2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan. 3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek. 4. Menyediakan suatu struktur proyek. Kekurangan dari model Waterfall adalah : 1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi. 7

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

19 Gambar 2.3 Model Waterfall (Sumber : 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 9

20 menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek dengan baik. I. Referensi 1. Schwalbe. Kathy Introduction to Project Management. Course Technology Inc. ISBN: Olson, David Introduction to Information Systems Project Management, 2nd Ed. ISBN: Larson, Erick. W Project management: the managerial process. 10

21 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Perencanaan Proyek Perangkat Lunak Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini menjelaskan tentang maksud dari perencanaan proyek perangkat lunak Kompetensi Mahasiswa memiliki kemampuan dalam memulai sebuah proyek perangkat lunak 1

22 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 2

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

24 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 , rasio PM aplikasi : utility : system 1 : 1.7 : 2.8 (tepatnya : : 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 , ketiga program memerlukan waktu pengembangan sekitar 18 bulan (tepatnya TDEV aplikasi : utility : system = 17.9 : 18:3 : 17.4). 4

25 Rata-rata jumlah programmer yang diperlukan untuk membuat 60 KDSI per bulan adalah : aplikasi : PM / 17.9 Months = 9.9 programmer utility : PM / 18.3 Months = 16.1 programmer system : 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. 5

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

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

28 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 8

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

30 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 dokumendokumen 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 10

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

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

33 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 13

34 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 14

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

36 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: 16

37 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 17

38 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 18

39 I. Referensi 1. Presman, Rouger S Software Enigineering, 4 th Edition. Mc. Graw Hill 2. Sommerville,Ian Software Engineering, 7 th Edition. Addison Wesley 19

40 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Perencanaan Proyek Perangkat Lunak (Lanjutan) Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini menjelaskan tentang maksud dari perencanaan proyek perangkat lunak 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.

41 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 Manajemen Proyek Perangkat Lunak

42 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 3 Manajemen Proyek Perangkat Lunak

43 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 4 Manajemen Proyek Perangkat Lunak

44 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). 5 Manajemen Proyek Perangkat Lunak

45 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 : 6

46 S u b f a s e p e n e t a p a n persyaratan menghasilkan sebuah produk : Software Requirements Specifications. Format 7 Fase perancangan melakukan identifikasi terhadap komponen perangkat lunak (fungsi, arus data, penyimpanan data), hubungan antar komponen, struktur perangkat lunak (dekomposisi menjadi modul-modul dan pengatarmukaannya).

47 produk ini adalah sbb :

48 Fase ini menghasilkan arsitektur rinci, terutama dalam bentuk algoritmaalgoritma. 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 :

49 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 9

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

51 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 11 Definition (SD) dan Project Plan (PP). Manajemen Proyek Perangkat Lunak

52 Team pendefinisian produk menerima produk SD dan PP, melakukan analisa persya-ratan perangkat lunak, dan menyiapkan Software Requirement Specification (SRS). Team perancangan merancang produk yang sesuai dengan SRS dan SD. Team implementasi mengimplementasi, debugging, dan melakukan uji per unit sistem Team uji sistem melakukan uji integrasi Team kualitas melakukan sertifikasi terhadap semua produk kerja Team pemelihara melakukan pemeliharaan produk 3. Format matriks Setiap gugus fungsional memiliki team manajemen dan kelompok spsialis yang hanya melaksanakan fungsinya sendiri. Gambar 4.4 Struktur Organisasi 12

53 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 13 Manajemen Proyek Perangkat Lunak

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

55 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Estimasi Biaya Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini menjelaskan tentang perencanaan biaya dalam sebuah proyek Kompetensi Mahasiswa memiliki kemampuan untuk menganalisis dan menetapkan biaya dari sebuah proyek yang akan dijalankan 1

56 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 2

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

58 2. Estimasi Biaya Proyek 1. Definisi Terdapat beberapa literatur yang membahas mengenai pengertian estimasi biaya. Dalam AACE International (2004), disebutkan bahwa estimasi merupakan evaluasi dari keseluruhan elemen dari sebuah proyek atau usaha yang diberikan berdasarkan kesepakatan terhadap suatu lingkup pekerjaan. Dysert, Larry R. mengungkapkan bahwa estimasi biaya merupakan sebuah prediksi terhadap biaya yang akan dibutuhkan dari sebuah proyek berdasarkan data dan lingkup proyek yang diberikan yang akan dilaksanakan pada sebuah lokasi dan waktu yang telah ditetapkan. Dalam sebuah estimasi biaya terdapat identifikasi dan pertimbangan dalam memperkirakan beberapa alternatif biaya untuk memulai dan menyelesaikan proyek. Jumlah biaya yang akan dikeluarkan dan risiko harus dapat dipertimbangkan, misalnya seperti membuat keputusan untuk membeli suatu barang atau hanya menyewanya saja untuk keperluan proyek, berbagi sumber daya dalam rangka mengoptimalkan biaya dalam proyek. Biaya yang disusun akan memperhitungkan keseluruhan sumber daya yang dibutuhkan dalam sebuah proyek, termasuk tenaga kerja, material, peralatan, jasa, dan fasilitas dan beberapa kategori spesial seperti faktor inflasi atau biaya contingency. Estimasi biaya merupakan penilaian kuantitatif yang mendekati untuk kebutuhan sumber daya dalam proyek. Tujuan dari dibuatnya suatu estimasi proyek adalah : 1. Sebagai dasar dalam pembuatan anggaran proyek 2. Sebagai alat untuk mengontrol biaya proyek 3. Untuk memonitor progress, dengan membandingkan anggaran biaya, biaya estimasi dengan actual di lapangan. 4. Untuk membuat suatu database biaya yang dapat digunakan untuk estimasiestimasi berikutnya. 5. Estimasi biaya dan penjadwalan merupakan 2 aktifitas yang sangat berkaitan erat. 4

59 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: 5

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

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

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

63 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 : 9

64 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) 10

65 I. Referensi: 1. Project Management Institute, (2008). A Guide to the Project Management Body of Knowledge, 4th Edition, hal Perrot, Melvin W., (2004). The Cost Estimator s Dilemma, AACE International Transactions, hal Dysert, Larry R. (2006). Is Estimate Accuracy an Oxymoron?, Journal AACE International Transactions, hal Project Management Institute, (2008). A Guide to the Project Management Body of Knowledge, 4th Edition, hal 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. 11

66 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Manajemen Resiko Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Pada bab ini menjelaskan tentang bagaimana mengelola sebuah resiko di dalam proyek perangkat lunak Kompetensi Mahasiswa memiliki kemampuan untuk menganalisis dan mengelola sebuah resiko di dalam proyek perangkat lunak 1

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

68 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) 3

69 c) Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya. d) Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (resiko manajemen) e) Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko biaya). 4) Resiko yang sudah diketahui adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hatihati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya. seperti : - Tanggal penyampaian yang tidak realitas - Kurangnya persyaratan yang terdokumentasi - kurangnya ruang lingkup PL - Lingkungan pengembangan yang buruk 5) Resiko yang dapat diramalkan Merupakan diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya : - Pergantian staf - Komunikasi yang buruk dengan para pelanggan - Mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung dilayani 6) Resiko yang tidak diharapkan Resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya. Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber 2 daya dikesampingkan, padahal seharusnya sumber 2 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 4

70 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? 5

71 4 3. Masalah-masalah Teknis 1. Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang? 2. Apakah metode spesifik digunakan untuk analisis PL? 3. Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur? 4. Apakah lebih dari 90% dari kode anda ditulis dengan bahasa orde yang lebih tinggi? 5. Apakah konvensi spesifik untuk dokumentasi kode didefinisikan & digunakan? 6. Apakah anda menggunakan metode spesifik untuk desain test case? 7. Apakah digunakan peranti PL untuk mendukung perencanaan & aktivitas penelusuran? 8. Apakah digunakan peranti PL manajemen konfigurasi untuk mengontrol & menelusuri aktivitas perubahan diseluruh proses PL? 9. Apakah digunakan peranti PL untuk mendukung analisis PL dan desain proses? 10. Apakah digunakan peranti untuk menciptakan prototipe PL? 11. Apakah digunakan peranti PL untuk mendukung proses pengujian? 12. Apakah peranti PL digunakan u ntukmendukung produksi dan manajemen dokumentasi? 13. Apakah metriks kualitas dikumpulkan bagi semua proyek PL? 14. Apakah metrik produktivitas dikumpulkan bagi semua proyek PL? Bila mayoritas jawaban terhadap pertanyaan tersebut adalah `tidak`, maka proses PL lemah dan berisiko tinggi. Resiko berhubungan dengan kompleksitas sistem yang akan dibangun dan `kebaruan` teknologi yang dikemas oleh sistem. Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun : Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda? Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output? Apakah PL berinterface dengan perangkat keras baru atau belum terbukti? 6

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

73 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 masingmasing 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 8

74 Dua cara melakukan proyeksi risiko: Probabilitas di mana risiko adalah nyata Konsekuensi masalah yang berhubungan dengan risiko Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko : 1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan 2. Menggambar konsekuensi risiko 3. Memperkirakan pengaruh risiko pada proyek dan produk 4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman 6. Pengurangan dan Monitoring Resiko Perangkat Lunak Aktifitas analisis risiko mempunyai titik tunggal yang memiliki tujuan untuk membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko. Strategi yang efektif harus: 1. Menghindari risiko 2. Memonitoring risiko 3. Manajemen risiko dan perencanaan kemungkinan Langkah-langkah untuk mengurangi turnover staf adalah 1. Temui staf yang ada, untuk menentukan penyebab keluar 2. Bertindaklah untuk mengurangi penyebab-penyebab yang ada di bawah kontrol manajemen sebelum proyek dimulai 3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknikteknik untuk memastikan kontiunitas pada saat orang keluar 4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas pengembangan dapat disebarluaskan 5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa dokumen dikembangkan tepat waktu 9

75 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, 4 th Edition, Mc. Graw Hill, Sommerville,Ian, Software Engineering, 7 th Edition, Addison Wesley, Kendall & Kendall, Systems Analysis and Design, 6 th Edition, Prentice Hall,

76 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Inisiasi Proyek dan Ruang Lingkup Manajemen Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Modul ini berisi materi tentang penaksiran proyek, elemenelemen dasar proyek, aspek awal, dan proposal awal dan pendekatan dalam penaksiran Kompetensi Pada akhir pertemuan ini, diharapkan mahasiswa memahami elemen-elemen dasar proyek, cara melakukan penaksiran proyek, dan membuat proposal 1

77 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 2

78 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- 3

79 kesulitan yang terjadi dimasa lalu, dan risiko keseluruhan dapat dikurangi. Resiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek merupakan subjek terjadinya perubahan, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface (yang diisikan ke dalam spesifikasi sistem). Perencana, dan lebih penting lagi pelanggan, harus mengetahui bahwa variabilitas pada kebutuhan perangkat lunak berarti ketidakstabilan biaya dan jadwal. Sebagai observasi akhir mengenai estimasi, kita perlu mempertimbangkan apa yang pernah dikatakan oleh Aristoteles :Ini merupakan tanda dari pikiran yang diperintah untuk menjadi puas dengan tingkat ketelitian yang diijinkan oleh sifat dari sebuah subjek, dan tidak untuk mencari ketepatan bila hanya perkiraan kebenaran saja yang dimungkinkan. Manajer proyek tidak boleh obsesif terhadap penaksiran. Pendekatanpendekatan rekayasa perangkat 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 4

80 merupakan akumulasi dari biaya yang harus dibayarkan kepada setiap anggota tim berdasarkan keterlibatannya. Langkah-langkah Pendetilan Untuk menghasilkan harga yang lebih teliti, langkah-langkah yang dapat dilakukan adalah sebagai berikut : 1. Dekomposisi masalah 2. Definisikan secara detil task-task yang mesti ada pada setiap sub masalah 3. Definisikan anggota tim yang akan ditugaskan pada setiap task 4. Perkirakan waktu yang dibutuhkan oleh setiap anggota tim tersebut untuk menyelesaikan suatu task 5. Tentukan tarif setiap anggota tim dalam pengerjaan proyek 6. Buat taksiran biaya lain-lain yang muncul, misalnya biaya akomodasi, biaya atk, biaya peralatan, dan pembelian tools. Kematangan setiap individu dalam tim akan mempengaruhi kebutuhan waktu penyelesaian sebuah task yang ditugaskan kepadanya. Sehingga tim dengan kematangan individu anggotanya yang rendah berdampak pada panjang kebutuhan waktu. Disisi lain kematangan seorang individu juga mempengaruhi tarif yang ditetapkan baginya. 3. Aspek Teknis Pengkajian aspek teknis dilakukan sejajar dengan aspek-aspek lain setelah penelitian pemasaran menunjukkan adanya faedah untuk melanjutkan studi kelayakan. Maksud dan tujuan pengkajian aspek teknis adalah sebagai berikut: Pada tahap awal bertujuan untuk merumuskan gagasan yang timbul ke dalam batasan yang konkret dari segi teknis. Hasil pengkajian aspek teknis dipakai sebagai masukan pengkajian aspekaspek lain. Akhirnya lingkungan aspek teknis sampai kepada kegiatan desain engineering terinci, menghasilkan cetak biru (blue print) proyek yang Ida Nurhaida, ST., MT.

81 berikut: akan dibangun. Pengkajian aspek teknis itu sendiri mencakup beberapa hal antara lain sebagai 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: 6

82 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: 7

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

84 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: N o Dekomposisi Kualifikasi Rate Man Scheduling Waktu Biaya Konsultan Da ys Nyata 1. Sub Masalah Task Sub task Sub sub task 1 Proyek Manajer $ $ Sub sub task 2 Sistem Analis 1 $ $ Sub sub task 3 Programmer 1 $ 60 6 $ Sub task 2 Sub sub task 1 Sistem Analis 1 $ $ Sub sub task 2 Sistem Analis 2 $ $ dst T o t a l $ xxxxxx 9

85 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 Management Information System, Raymond McLeod, Prentice Hall Software Project Management for Dummies, Teresa Luckey, Joseph Phillips, Wiley Publishing Inc.,

86 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Critical Success Factor Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Modul ini berisi materi tentang bagaimana penerapan critical success factor pada sebuah manajemen proyek perangkat lunak Kompetensi Pada akhir pertemuan ini, diharapkan mahasiswa memahami penerapan critical success factor pada sebuah manajemen proyek perangkat lunak 1 Hendra Prastiawan, S.Si., M.T

87 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 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. 2 Hendra Prastiawan, S.Si., M.T

88 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. 3 Hendra Prastiawan, S.Si., M.T

89 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 beserta definisinya seperti tercantum dalam tabel dibawah ini proyek Tabel 9.1 Kriteria Sukses dan Definisinya Kriteria Sukses Sesuai Budget L eri ii Sesuai Jadwal Sesuai Spesifikasi sesuai dengan keinginan user tingkat kemampuan staff pekerja yang berkualitas tinggi Definisi Proyek disesuaikan pada atau didalam biaya yang di-kontrak-an Proyek diselesaikan pada atau sebelum jadwal yang di-kontrak-an Proyek yang diselesaikan sesuai atau melebihi semua spesifikasi teknis yang disediakan Proyek yang diselesaikan sesuai atau melebihi tujuan fungsional yang diinginkan Proyek yang diselesaikan sesuai atau melebihi standar tingkat kemampuan pekerja yang dapat diterima pada semua area 4 Hendra Prastiawan, S.Si., M.T

90 meminimalisasi proses konstruksi terjadi perselisihan ketidakpuasan konstruksi dengan staff manajemen proyek owner. Pada penelitian Thomas, Tucker, dan Kelly (1998) [24], mengutip dari penelitian oleh Ashley et al. (1987) [25], menyatakan bahwa kesuksesan diukur oleh biaya, jadwal, kualitas, keamanan, dan kepuasan partsipan. Akan tetapi walapun mudah untuk diukur, tetapi pada aspek kepuasan dan kualitas dinilai 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 5 Hendra Prastiawan, S.Si., M.T

91 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 Pinto & Belassi Kerzner Slevin & Tukel 1996 Wateridge 1995 Corposite Understanding X X X Common Understanding with stakeholders on Success criteria X Executive Commitment X X X X Organizational adaptability X Belout 1998 Communication X X X Clarke 1999 Coole- Daview 2002 Project manager selection criteria X X X X X project manager leadership / empowerment X X X X X Environment X Muller Hendra Prastiawan, S.Si., M.T

92 Success Factors from the Literature Pimo 1996 Pinto & Belassi Kerzner Slevin & Tukel 1996 Wateridge 1995 Belout 1998 Clarke 1999 Coole- Daview 2002 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 Muller 2005 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, Project manager eksperience Ruben & Seeling, Project manager competence Sayles & Chandler, Schedulling Sayles & Chandler, Control system and responsibilities Sayles & Chandler, Monitoring & feed back Sayles & Chandler, Continous involment in the project Sayles & Chandler, Clear Goals Martin, General management support Martin, organize and delegate authorithy Martin, Clear Goals Baker, Murphy, and Fisher, Goal commitment of project team Baker, Murphy, and Fisher, adequate project team capability Baker, Murphy, and Fisher, Planning & control techniques Baker, Murphy, and Fisher, Task-Social orientation absence of Baker, Murphy, and Fisher, bureucracy Project summary Clealand King, Top Management Support Clealand King, Hendra Prastiawan, S.Si., M.T

93 18 Financial Support Clealand King, facility support Clealand King, market intelligent Clealand King, schedule Clealand King, manpower and organisation Clealand King, acquisition Clealand King, information and communication channels Clealand King, Project Objectives Morris and Hughes, Technical Innovation Uncertainty Morris and Hughes, Politics Morris and Hughes, Vommunity Involvement Morris and Hughes, Schedule duration urgency Morris and Hughes, Implementation problem Morris and Hughes, Project Objectives Pinto and Slevin, Top Management support Pinto and Slevin, Project planning Pinto and Slevin, Communication with client Pinto and Slevin, Human relations Pinto and Slevin, Technical task Pinto and Slevin, Client Acceptence Pinto and Slevin, Project Control Pinto and Slevin, Communication and problem handling Pinto and Slevin, Top management support Tuke & Rom, Client consultation Tuke & Rom, Availability of resources Tuke & Rom, Project manager performance Tuke & Rom, The project manager and team members Walid and Oya, The organization Walid and Oya, Early and continual client consultation Pinto and Kharbanda, Technology Pinto and Kharbanda, Schedulling system Pinto and Kharbanda, Project team Pinto and Kharbanda, 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 8 Hendra Prastiawan, S.Si., M.T

94 banyak berkembang dan pengembangan teoritis telah mengarah pada prinsipprinsip organisasi dan tingkah laku (behaviour). Naoum, Fong, dan Walker (2004) [38], dalam penelitiannya dalam mengidentifikasi CSF yang berkontribusi pada keberhasilan suatu manajemen proyek, menemukan bahwa terdapat 10 CSF, yaitu: 1. Pembentukan tujuan proyek dan 'criteria klien 2. Tingkat partisipasi tim proyek dalam decision making 3. Kejelasan scope dan definisi pekerjaan 4. Karakteristik manajer proyek 5. Organisasi klien 6. Kerjasama tim proyek 7. Teknik perencanaan dan programming 8. Proses seleksi dalam pembentukan tim 9. Kewenangan dan pengaruh manajer proyek 10. Estimasi biaya proyek Penelitian atas CSF memiliki manfaat yang sangat signifikan terutama dalam bidang konstruksi dan Manajemen Proyek, diantaranya adalah (Permono, 2010): 1. Untuk meminimalisir variasi yang banyak sepanjang implementasi proyek. 2. Untuk mengantisipasi efek-efek yang mungkin terjadi, kemudian memilih metode y ang dapat diterapkan untuk mengatasinya 3. Dapat memprediksi 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: 9 Hendra Prastiawan, S.Si., M.T

95 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 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), Thamhain (2004) Team Leadership effectiveness in technology based project environment. Project environment journal. 10. Rockart, John F "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 "An Assessment of Critical Success Factors," Sloan Management Review (25:4), pp Hendra Prastiawan, S.Si., M.T

96 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Jaminan Kualitas Perangkat Lunak Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak Kompetensi Mahasiswa mengenal, memahami dan mampu menjamin kualitas perangkat lunak yang dihasilkan. 1 Hendra Prastiawan, S.Si., M.T

97 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 2 Hendra Prastiawan, S.Si., M.T

98 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 3 Hendra Prastiawan, S.Si., M.T

99 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 4 Hendra Prastiawan, S.Si., M.T

100 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. 5 Hendra Prastiawan, S.Si., M.T

101 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 6 Hendra Prastiawan, S.Si., M.T

102 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 Sebelum pengujian Selama pengujian Setelah peluncuran Kajian tidak Total Hendra Prastiawan, S.Si., M.T

103 dilakukan Sebelum pengujian Selama pengujian Setelah peluncuran Total 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. 8 Hendra Prastiawan, S.Si., M.T

104 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. 9 Hendra Prastiawan, S.Si., M.T

105 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 dipilahpilahkan. 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) 10 Hendra Prastiawan, S.Si., M.T

106 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, 4 th Edition, Mc. Graw Hill, Sommerville,Ian, Software Engineering, 7 th Edition, Addison Wesley, Kendall & Kendall, Systems Analysis and Design, 6 th Edition, Prentice Hall, Hendra Prastiawan, S.Si., M.T

107 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Negosiasi Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Negosiasi merupakan salah satu faktor yang penting di dalam sebuah proyek perangkat lunak Kompetensi Mahasiswa mengenal, memahami dan memiliki kemampuan bernegosiasi didalam sebuah aktivitas proyek perangkat lunak. 1 Hendra Prastiawan, S.Si., M.T

108 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 2 Hendra Prastiawan, S.Si., M.T

109 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): 3 Hendra Prastiawan, S.Si., M.T

110 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: 4 Hendra Prastiawan, S.Si., M.T

111 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 5 Hendra Prastiawan, S.Si., M.T

112 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) 6 Hendra Prastiawan, S.Si., M.T

113 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. 7 Hendra Prastiawan, S.Si., M.T

114 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 8 Hendra Prastiawan, S.Si., M.T

115 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 9 Hendra Prastiawan, S.Si., M.T

116 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 10 Hendra Prastiawan, S.Si., M.T

117 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 11 Hendra Prastiawan, S.Si., M.T

118 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 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 Strategi Lobi dan Negosiasi, Yogyakarta, Oriza. 4. Jimmy Joses Sembiring. Smart HRD Jakarta, Visimedia. 5. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media Group. 12 Hendra Prastiawan, S.Si., M.T

119 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Kerjasama Tim Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Kerjasama tim dibutuhkan didalam pelaksanaan sebuah proyek perangkat lunak Kompetensi Mahasiswa mengenal, memahami dan memiliki kemampuan bekerja secara tim di dalam sebuah proyek perangkat lunak 1 Hendra Prastiawan, S.Si., M.T

120 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. 2 Hendra Prastiawan, S.Si., M.T

121 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. 3 Hendra Prastiawan, S.Si., M.T

122 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. 4 Hendra Prastiawan, S.Si., M.T

123 Pentingnya perancangan tim yang baik diuraikan Griffin (2004) dengan membagi ke dalam 4 (empat) tahap perkembangan, yaitu: 1. Forming Forming (pembentukan), adalah tahapan di mana para anggota setuju untuk bergabung dalam suatu tim. Karena kelompok baru dibentuk maka setiap orang membawa nilai-nilai, pendapat dan cara kerja sendiri-sendiri. Konflik sangat jarang terjadi, setiap orang masih sungkan, malu-malu, bahkan seringkali ada anggota yang merasa gugup. Kelompok cenderung belum dapat memilih pemimpin (kecuali tim yang sudah dipilih ketua kelompoknya terlebih dahulu). 2. Storming Storming (merebut hati), adalah tahapan di mana kekacauan mulai timbul di dalam tim. Pemimpin yang telah dipilih seringkali dipertanyakan kemampuannya dan anggota kelompok tidak ragu-ragu untuk mengganti pemimpin yang dinilai tidak mampu. Faksi-faksi mulai terbentuk, terjadi pertentangan karena masalahmasalah pribadi, semua bersikeras dengan pendapat masing-masing. Komunikasi yang terjadi sangat sedikit karena masing-masing orang tidak mau lagi menjadi pendengar. 3. Norming Norming (pengaturan norma), adalah tahapan di mana individu-individu dan subgroup yang ada dalam tim mulai merasakan keuntungan bekerja bersama dan berjuang untuk menghindari team tersebut dari kehancuran (bubar). Karena semangat kerjasama sudah mulai timbul, setiap anggota mulai merasa bebas untuk mengungkapkan perasaan dan pendapatnya kepada seluruh anggota tim. 4. Performing Performing (melaksanakan), adalah tahapan merupakan titik kulminasi di mana team sudah berhasil membangun sistem yang memungkinkannya untuk dapat bekerja secara produktif dan efisien. Pada tahap ini keberhasilan tim akan terlihat dari prestasi yang ditunjukkan. 5 Hendra Prastiawan, S.Si., M.T

124 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 6 Hendra Prastiawan, S.Si., M.T

125 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 7 Hendra Prastiawan, S.Si., M.T

126 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 8 Hendra Prastiawan, S.Si., M.T

127 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 9 Hendra Prastiawan, S.Si., M.T

128 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 kilogram. Juara kedua sanggup menarik beban sebesar kilogram. Dalam teori, berarti kedua kuda tersebut secara bersama-sama harus mampu menggerakkan maksimum 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 kilogram, atau 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 Jakarta, Astra International 2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and Management, New York, McGraw-Hill International Edition. 3. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media Group. 10 Hendra Prastiawan, S.Si., M.T

129 MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Manajemen Kualitas Suatu Proyek Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh Fakultas Ilmu Komputer Informatika Abstract Kualitas suatu proyek menjadi elemen yang penting di dalam suatu proyek agar produk yang dihasilkan berkualitas Kompetensi Mahasiswa mengenal, memahami dan memiliki kemampuan membuat suatu proyek dengan kualitas yang baik 1 Hendra Prastiawan, S.Si., M.T

130 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 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. 2 Hendra Prastiawan, S.Si., M.T

131 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 3 Hendra Prastiawan, S.Si., M.T

132 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 4 Hendra Prastiawan, S.Si., M.T

133 manajemen puncak". Kebijakan mutu organisasi melakukan sering dapat diadopsi "sebagaimana adanya" untuk digunakan oleh proyek ini. Namun, jika organisasi melakukan tidak memiliki kebijakan mutu formal, atau jika proyek tersebut melibatkan beberapa organisasi yang melakukan (seperti dengan perusahaan patungan), maka tim manajemen proyek akan perlu untuk mengembangkan kebijakan mutu untuk proyek tersebut. Terlepas dari asal kebijakan mutu, tim manajemen proyek bertanggung jawab untuk memastikan bahwa para stakeholder proyek sepenuhnya menyadari hal itu. Lingkup pernyataan. Pernyataan lingkup adalah masukan kunci untuk perencanaan mutu karena kiriman dokumen proyek besar, serta tujuan proyek yang berfungsi untuk menetapkan persyaratan stakeholder penting. Produk deskripsi. Meskipun unsur-unsur deskripsi produk dapat diwujudkan dalam pernyataan ruang lingkup, deskripsi produk seringkali akan berisikan detil tentang masalah teknis dan masalah lainnya yang dapat mempengaruhi kualitas perencanaan. Standar dan peraturan. Tim manajemen proyek harus mempertimbangkan standar aplikasi setiap daerah khusus atau peraturan yang dapat mempengaruhi proyek. Proses output lainnya. Selain pernyataan lingkup dan deskripsi produk, proses di daerah pengetahuan lainnya dapat menghasilkan output yang harus dianggap sebagai bagian dari perencanaan mutu. Sebagai contoh, pengadaan perencanaan dapat mengidentifikasi persyaratan kualitas kontraktor yang harus tercermin dalam rencana manajemen mutu secara keseluruhan. 2. Alat dan Teknik Perencanaan Kualitas Analisis manfaat/biaya. Proses perencanaan kualitas harus mempertimbangkan pengorbanan biaya manfaat. Manfaat utama dari memenuhi persyaratan kualitas pengerjaan ulang kurang, yang berarti produktivitas yang lebih tinggi, biaya lebih rendah, dan kepuasan stakeholder meningkat. Biaya utama memenuhi persyaratan kualitas adalah biaya yang terkait dengan kegiatan manajemen kualitas proyek. Jelas sekali dari disiplin manajemen mutu yang manfaat lebih besar daripada biaya. Pembandingan. Pembandingan melibatkan membandingkan praktek proyek aktual atau yang direncanakan untuk orang-orang dari proyek lain untuk menghasilkan ideide untuk perbaikan dan untuk menyediakan sebuah standar yang digunakan untuk 5 Hendra Prastiawan, S.Si., M.T

134 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 6 Hendra Prastiawan, S.Si., M.T

135 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 7 Hendra Prastiawan, S.Si., M.T

136 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 8 Hendra Prastiawan, S.Si., M.T