MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Pengantar Manajemen Proyek Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 01 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini akan dijelaskan mengenai dasar manajemen proyek Mahasiswa memiliki gambaran umum tentang isi dari manajemen proyek perangkat lunak Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Manajemen Proyek 1. Pengertian Manajemen Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan, mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah ditentukan. 2. Pengertian Proyek Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif untuk menyelesaikan proyek secara efisien dan tepat waktu. Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi kinerja yang dirancang untuk memenuhi kebutuhan customer. Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai berikut : 1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan suatu produk khusus, layanan, dan hasil akhir. 2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas. 3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya dapat berupa hardware, software, dan sumber daya lainnya. 4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor. 5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek bersifat unik maka sangat sulit untuk menentukan objektifitas proyek, mengestimasi waktu proyek, dan biayanya. Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id membantu membedakan proyek tersebut dari yang lainnya dalam organisasi. Karakteristik utama dari proyek adalah : 1. Penetapan tujuan 2. Masa hidup yang terdefinisi mulai dari awal hingga akhir 3. Biasanya melibatkan beberapa departemen dan professional 4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya 5. Waktu, biaya, dan kebutuhan yang spesifik Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang membuat proyek software berbeda dengan proyek lainnya. 1. Invisibility Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan jembatan dan sebagainya. 2. Complexity Produk software memiliki lebih banyak kompleksitas daripada proyek fisik termasuk dari sisi biayanya. 3. Conformity Pengembang software harus menyesuaikan kebutuhan software dan kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal hingga akhir menjadi hal yang penting dalam keberhasilan proyek. 4. Flexibility Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah dengan mudah untuk mengakomodasi perubahan lingkungan bisnis organisasi dan komponen lainnya. Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple constraint (3 kendala). Setiap manajer proyek harus memperhatikan hal – hal penting dalam manajemen proyek : 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Ruang lingkup (scope) : apa yang ingin dicapai dalam proyek ? produk atau layanan apa yang pelanggan harapkan dari proyek tersebut ? • Waktu (time) : berapa lama waktu yang dibutuhkan untuk menyelesaikan proyek? Bagaimana jadwal kegiatan proyek akan dilaksanakan ? • Biaya (cost) : berapa biaya yang dibutuhkan untuk dapat menyelesaikan proyek ? Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus berkompromi dengan mutu atau jadwal. Gambar 1.1 Triple Constraint (Sumber : Schwalbe, 2006, p7) 3. Pengertian Perangkat Lunak Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan: 1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan kinerja yang diinginkan pada saat dieksekusi atau dijalankan. 2. Struktur – struktur data yang memungkinkan program memanipulasi informasi sesuai yang diinginkan. 3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari program – program. Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware). Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu : 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. System software membantu user dalam menjalankan hardware dan sistem komputer. Salah satu contoh system software adalah operating system dan device drivers. Tujuan dari system software adalah mengisolasi sebanyak mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti printer dan keyboard. 2. Programming Software biasanya menyediakan tools untuk membantu programmer dalam menulis program – program komputer dan software dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang digunakan meliputi text editor, compiler, debbuger, dan sebagainya. 3. Application Software memungkinkan user menyelesaikan satu atau beberapa tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi business software, educational software, basis data, dan computer games. 4. Pengertian Manajemen Proyek Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek. Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan, mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk mencapai sasaran jangka pendek yang telah ditentukan. Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek antara lain : 1. Manajer Proyek Elemen paling penting dalam manajemen proyek adalah manajer proyek. Manajer proyek adalah seseorang yang bertanggung jawab untuk merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan usaha antar area fungsional dan mengintegrasikan perencanaan dan pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek. 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Tim proyek Tim proyek merupakan kumpulan orang yang biasanya berasal dari area fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk menyelesaikan pekerjaan proyek. 3. Sistem Manajemen Proyek Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat berdasarkan struktur organisasi, proses informasi, dan pelatihan serta prosedur yang mengintegrasikan elemen dari organisasi proyek secara vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam proyek sedangkan elemen horizontal meliputi unit fungsional dan departemen yang terlibat dalam proyek. 5. Daur Hidup Manajemen Proyek Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle) merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup proyek terdiri dari : 1. Project Feasibility Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada perencanaan. 2. Project Acquisition Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini berfokus kepada penyampaian tugas yang nyata dan seharusnya dilaksanakan. Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap operasi yang berjalan dalam suatu organisasi. 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 2.2 Fase Daur Hidup Proyek (Sumber : Schwalbe, 2006, p55) 6. System Development Life Cycle (SDLC) Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam pengembangan sistem informasi. Salah satu model yang popular dan banyak digunakan dalam daur hidup pengembangan sistem adalah model Waterfall. 7. Model Waterfall Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran umpan balik antara tahapan – tahapan dari pengembangan software untuk meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan yang meliputi : System feasibility, software plans and requirement, product design, detailed design, code, integration, implementation, operation and maintenance. Kelebihan dari model Waterfall adalah : 1. Mendukung perencanaan sebelum dilakukannya proses desain. 2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan. 3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek. 4. Menyediakan suatu struktur proyek. Kekurangan dari model Waterfall adalah : 1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi. 2015 7 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek. Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi. Model Waterfall mempunyai beberapa tahapan sebagai berikut: 1. System Feasibility Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk piranti lunak serta menentukan daur hidup dari proyek. 2. Software Plans and Requirements Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti lunak secara rinci. 3. Product Design Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur pengendalian, dan struktur data bagi produk dan komponen lainnya yang diperlukan sebagai dokumen bagi user dan tahap pengujian. 4. Detailed Design Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data, hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap komponen program. 5. Code Komponen program secara keseluruhan. 6. Integration Penyatuan masing – masing fungsi komponen agar piranti lunak dapat bekerja seharusnya. 7. Implementation Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi, dan pelatihan user. 8. Operations and Maintenace Perawatan bagi sistem yang telah dibuat. 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 2.3 Model Waterfall (Sumber : http://www.jodypaul.com) 8. Sembilan Area Pengetahuan Manajemen Proyek Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer proyek. Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek yang lebih spesifik. Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek dengan baik. Referensi 1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course Technology Inc. ISBN: 978-1418835590 2. Olson, David. 2004. Introduction to Information Systems Project Management, 2nd Ed. ISBN: 0-07-282402-6 3. 2015 Larson, Erick. W. 2000. Project management: the managerial process. 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Pengantar Manajemen Proyek (Lanjutan) Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 02 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini akan dijelaskan mengenai dasar manajemen proyek Mahasiswa memiliki gambaran umum tentang isi dari manajemen proyek perangkat lunak Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Manajemen Proyek 1. Pengertian Manajemen Menurut Soeharto (1999, p21), Manajemen adalah proses merencanakan, mengorganisasikan, memimpin, dan mengendalikan kegiatan anggota serta sumber daya yang lain untuk mencapai sasaran organisasi (perusahaan) yang telah ditentukan. 2. Pengertian Proyek Menurut Schwalbe (2006, p4), Proyek adalah suatu usaha yang bersifat sementara untuk menghasilkan suatu produk atau layanan yang unik. Pada umumnya, proyek melibatkan beberapa orang yang saling berhubungan aktifitasnya dan sponsor utama dari proyek biasanya tertarik dalam penggunaan sumber daya yang efektif untuk menyelesaikan proyek secara efisien dan tepat waktu. Menurut Larson (2000, p4), Proyek adalah kegiatan yang kompleks, tidak rutin, dan usaha satu waktu yang dibatasi oleh waktu, anggaran, sumber daya, dan spesifikasi kinerja yang dirancang untuk memenuhi kebutuhan customer. Menurut Schwalbe (2006, pp5-6), atribut dari suatu proyek adalah sebagai berikut : 1. Sebuah proyek memiliki tujuan yang khusus. Proyek harus menghasilkan suatu produk khusus, layanan, dan hasil akhir. 2. Proyek bersifat sementara. Proyek memiliki awal dan akhir yang jelas. 3. Proyek membutuhkan sumber daya bias dari beberapa area. Sumber daya dapat berupa hardware, software, dan sumber daya lainnya. 4. Proyek harus memiliki pelanggan utama (primary customer) / sponsor. 5. Proyek melibatkan ketidakpastian – ketidakpastian, karena setiap proyek bersifat unik maka sangat sulit untuk menentukan objektifitas proyek, mengestimasi waktu proyek, dan biayanya. Menurut Larson (2000, p4), tujuan utama dari proyek adalah untuk memuaskan kebutuhan customer. Disamping kemiripan, karateristik dari sebuah proyek 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id membantu membedakan proyek tersebut dari yang lainnya dalam organisasi. Karakteristik utama dari proyek adalah : 1. Penetapan tujuan 2. Masa hidup yang terdefinisi mulai dari awal hingga akhir 3. Biasanya melibatkan beberapa departemen dan professional 4. Biasanya melakukan sesuatu yang belum pernah dilakukan sebelumnya 5. Waktu, biaya, dan kebutuhan yang spesifik Menurut Hughes (2006, p4), Proyek software mempunyai karakteristik tertentu yang membuat proyek software berbeda dengan proyek lainnya. 1. Invisibility Dalam sebuah proyek software, kemajuannya tidak dapat dilihat secara langsung dan berbeda dengan proyek fisik lainnya misalnya pembuatan jembatan dan sebagainya. 2. Complexity Produk software memiliki lebih banyak kompleksitas daripada proyek fisik termasuk dari sisi biayanya. 3. Conformity Pengembang software harus menyesuaikan kebutuhan software dan kebutuhan dari client. Hal ini perlu mendapat perhatian karena pada dasarnya individual memiliki ketidakkonsistenan. Konsistensi mulai dari awal hingga akhir menjadi hal yang penting dalam keberhasilan proyek. 4. Flexibility Software yang dapat diubah dengan mudah biasanya dilihat sebagai sebuah kekuatan. Hal ini berarti tampilan sistem software diharapkan dapat diubah dengan mudah untuk mengakomodasi perubahan lingkungan bisnis organisasi dan komponen lainnya. Menurut Schwalbe (2006, p7), setiap proyek memiliki batasan yang berbeda terhadap ruang lingkup, waktu, dan biaya yang biasanya disebut sebagai triple constraint (3 kendala). Setiap manajer proyek harus memperhatikan hal – hal penting dalam manajemen proyek : 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Ruang lingkup (scope) : apa yang ingin dicapai dalam proyek ? produk atau layanan apa yang pelanggan harapkan dari proyek tersebut ? • Waktu (time) : berapa lama waktu yang dibutuhkan untuk menyelesaikan proyek? Bagaimana jadwal kegiatan proyek akan dilaksanakan ? • Biaya (cost) : berapa biaya yang dibutuhkan untuk dapat menyelesaikan proyek ? Ketiga batasan tersebut memiliki sifat saling tarik – menarik. Artinya, jika ingin meningkatkan kinerja produk yang telah disepakati dalam kontrak, maka harus diikuti dengan meningkatkan mutu, yang selanjutnya berakibat pada naiknya biaya melebihi anggaran. Sebaliknya, bila ingin menekan biaya maka biasanya harus berkompromi dengan mutu atau jadwal. Gambar 1.1 Triple Constraint (Sumber : Schwalbe, 2006, p7) 3. Pengertian Perangkat Lunak Menurut Pressman (2003, p6), Perangkat lunak (software) merupakan: 1. Instruksi – instruksi (program komputer) yang menyediakan fungsi dan kinerja yang diinginkan pada saat dieksekusi atau dijalankan. 2. Struktur – struktur data yang memungkinkan program memanipulasi informasi sesuai yang diinginkan. 3. Dokumen – dokumen yang mengambarkan operasi dan kegunaan dari program – program. Perangkat lunak (software) atau program memungkinkan komputer untuk melakukan tugas – tugas spesifik yang ditujukan kepada komponen fisik sistem (hardware). Secara umum, sistem komputer terbagi menjadi 3 kelas utama yaitu : 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. System software membantu user dalam menjalankan hardware dan sistem komputer. Salah satu contoh system software adalah operating system dan device drivers. Tujuan dari system software adalah mengisolasi sebanyak mungkin programmer aplikasi dari penggunaan bagian aplikasi yang rumit terutama memori dan fitur hardware lainnya serta peralatan lainnya seperti printer dan keyboard. 2. Programming Software biasanya menyediakan tools untuk membantu programmer dalam menulis program – program komputer dan software dengan menggunakan bahasa pemrograman yang lebih tepat. Tools yang digunakan meliputi text editor, compiler, debbuger, dan sebagainya. 3. Application Software memungkinkan user menyelesaikan satu atau beberapa tugas spesifik yang berkaitan dengan komputer. Aplikasi ini meliputi business software, educational software, basis data, dan computer games. 4. Pengertian Manajemen Proyek Menurut Schwable (2006, p9), Manajemen proyek merupakan aplikasi dari ilmu pengetahuan, skills, tools, dan teknik untuk aktifitas suatu proyek dengan maksud memenuhi atau melampaui kebutuhan stakeholder dan harapan dari sebuah proyek. Menurut Soeharto (1999, p28), Manajemen proyek adalah kegiatan merencanakan, mengorganisir, memimpin, dan mengendalikan sumber daya perusahaan untuk mencapai sasaran jangka pendek yang telah ditentukan. Menurut Nicholas (2001, p11), terdapat 3 elemen penting dalam manajemen proyek antara lain : 1. Manajer Proyek Elemen paling penting dalam manajemen proyek adalah manajer proyek. Manajer proyek adalah seseorang yang bertanggung jawab untuk merencanakan, mengarahkan, dan mengintegrasikan usaha kerja dari anggota untuk mencapai tujuan proyek. Manajer proyek mengkoordinasikan usaha antar area fungsional dan mengintegrasikan perencanaan dan pengendalian dari biaya, jadwal, dan pembagian tugas dalam suatu proyek. 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Tim proyek Tim proyek merupakan kumpulan orang yang biasanya berasal dari area fungsional yang berbeda yang akan saling bekerja sama dengan tujuan untuk menyelesaikan pekerjaan proyek. 3. Sistem Manajemen Proyek Manajer proyek dan tim proyek harus ada dan digunakan sebagai alat bantu dalam sebuah sistem manajemen proyek. Sistem manajemen proyek dibuat berdasarkan struktur organisasi, proses informasi, dan pelatihan serta prosedur yang mengintegrasikan elemen dari organisasi proyek secara vertikal dan horizontal. Elemen vertikal meliputi pemecahan tugas dalam proyek sedangkan elemen horizontal meliputi unit fungsional dan departemen yang terlibat dalam proyek. 5. Daur Hidup Manajemen Proyek Menurut Schwalbe (2006, pp 53-55), Daur hidup proyek (Project Life Cycle) merupakan kumpulan dari tahapan – tahapan proyek. Tahapan dari daur hidup proyek terdiri dari : 1. Project Feasibility Terdiri dari tahap konsep dan pengembangan. Tahapan ini berfokus kepada perencanaan. 2. Project Acquisition Terdiri dari tahap implementasi dan penyelesaian (Close-Out). Tahap ini berfokus kepada penyampaian tugas yang nyata dan seharusnya dilaksanakan. Sebuah proyek harus dapat menyelesaikan setiap tahapan dengan sukses sebelum melanjutkan ke tahap berikutnya. Pendekatan daur hidup proyek ini menyediakan suatu pengendalian manajemen yang lebih baik dan hubungan yang tepat terhadap operasi yang berjalan dalam suatu organisasi. 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 2.2 Fase Daur Hidup Proyek (Sumber : Schwalbe, 2006, p55) 6. System Development Life Cycle (SDLC) Menurut Schwalbe (2006, p57), Daur hidup pengembangan sistem (SDLC) adalah kerangka kerja untuk menggambarkan tahap – tahap yang terlibat dalam pengembangan sistem informasi. Salah satu model yang popular dan banyak digunakan dalam daur hidup pengembangan sistem adalah model Waterfall. 7. Model Waterfall Menurut Olson (2003, p127), Model Waterfall dapat mengenali perputaran umpan balik antara tahapan – tahapan dari pengembangan software untuk meminimalisasi kerja ulang. Model Waterfall terdiri dari tahapan – tahapan yang meliputi : System feasibility, software plans and requirement, product design, detailed design, code, integration, implementation, operation and maintenance. Kelebihan dari model Waterfall adalah : 1. Mendukung perencanaan sebelum dilakukannya proses desain. 2. Membagi sistem yang dikembangkan ke dalam beberapa tujuan. 3. Memudahkan manajer proyek untuk mengawasi kemajuan jalannya proyek. 4. Menyediakan suatu struktur proyek. Kekurangan dari model Waterfall adalah : 1. Masalah baru diketahui setelah pengerjaan proyek telah selesai. 2. Sering kali kebutuhan user tidak terpenuhi. 2015 7 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Tidak menyediakan tanggapan yang cepat terhadap sistem informasi proyek. Menurut Schwalbe (2006, p57), Model Waterfall memiliki tahapan – tahapan pengembangan dan dukungan sistem linear dan terdefinisi dengan baik. Model ini mengasumsikan bahwa kebutuhan akan tetap stabil setelah mereka terdefinisi. Model Waterfall mempunyai beberapa tahapan sebagai berikut: 1. System Feasibility Studi kelayakan dengan menentukan konsep yang diperlukan bagi produk piranti lunak serta menentukan daur hidup dari proyek. 2. Software Plans and Requirements Spesifikasi fungsi, tampilan, dan kinerja yang dibutuhkan dari produk piranti lunak secara rinci. 3. Product Design Spesifikasi dari seluruh rancangan piranti lunak dan perangkat keras, struktur pengendalian, dan struktur data bagi produk dan komponen lainnya yang diperlukan sebagai dokumen bagi user dan tahap pengujian. 4. Detailed Design Spesifikasi dari seluruh rancangan struktur pengendalian, struktur data, hubungan tampilan ukuran, kunci algoritma, dan asumsi bagi setiap komponen program. 5. Code Komponen program secara keseluruhan. 6. Integration Penyatuan masing – masing fungsi komponen agar piranti lunak dapat bekerja seharusnya. 7. Implementation Operasional kerja dari piranti lunak termasuk tugas, konversi data, instalasi, dan pelatihan user. 8. Operations and Maintenace Perawatan bagi sistem yang telah dibuat. 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 2.3 Model Waterfall (Sumber : http://www.jodypaul.com) 8. Sembilan Area Pengetahuan Manajemen Proyek Menurut Schwalbe (2006, pp11-12), Sembilan area pengetahuan manajemen proyek menggambarkan kunci utama yang harus dikembangkan oleh manajer proyek. Empat inti dari area pengetahuan manajemen proyek meliputi manajemen ruang lingkup proyek, waktu, biaya, dan manajemen kualitas. Proses – proses tersebut merupakan inti dari area pengetahuan karena mereka memimpin untuk tujuan proyek yang lebih spesifik. Empat area pengetahuan untuk memfasilitasi manajemen proyek adalah sumber daya manusia, komunikasi, resiko, dan manajemen pengadaan proyek. Disebut area pendukung karena proses – proses tersebut merupakan proses – proses yang dilalui untuk mencapai tujuan proyek. Area pengetahuan yang terakhir adalah manajemen integrasi proyek yang menyatukan semua area pengetahuan yang ada sebelumnya 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id menjadi satu kesatuan yang utuh untuk mencapai tujuan terlaksananya proyek dengan baik. Referensi 1. Schwalbe. Kathy. 2006. Introduction to Project Management. Course Technology Inc. ISBN: 978-1418835590 2. Olson, David. 2004. Introduction to Information Systems Project Management, 2nd Ed. ISBN: 0-07-282402-6 3. 2015 Larson, Erick. W. 2000. Project management: the managerial process. 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Perencanaan Proyek Perangkat Lunak Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 03 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini menjelaskan tentang maksud dari perencanaan proyek perangkat lunak Mahasiswa memiliki kemampuan dalam memulai sebuah proyek perangkat lunak Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pemahaman terhadap Proyek Perangkat Lunak 1. Pemahaman terhadap Proyek Perangkat Lunak Proyek Software adalah manajemen proyek yang berfokus hanya pada membuat dan mengupdate software. Sifat manajemen proyek haruslah seperti berikut ini: a. Menyelesaikan masalah, b. Mengerjakan sesuatu hingga selesai, c. Memiliki batas waktu mulai dan selesainya, d. Membutuhkan resource/sumber daya dan waktu, e. Bagi beberapa orang merupakan kesempatan/opportunity dan menarik Untuk (Manajemen) itu itu sebuah berupa proyek software persiapan perlu pekerjaan, dikelola. Pengelolaan pelaksanaan rencana, mengendalikan proyek tersebut dan terakhir menutup proyek dengan sebuah kesimpulan, yaitu sukses. Secara lebih sistematis, tahapan-tahapan proyek dapat dilihat pada gambar 3.1: Gambar 3.1 Tahapan-tahapan Proyek 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Tahapan proyek: 1. Initiating: proyek sedang dalam proses untuk dipilih/disetujui, disponsori, didanai, dan diluncurkan. 2. Planning: perencanaan adalah proses yang berulang (perhatikan gambar). Perencanaan pada dasarnya menggambarkan proses bagaimana proyek akan dilaksanakan hingga selesai. 3. Executing: setelah proyek direncanakan, tim proyek memulai pekerjaannya. 4. Controlling: selama tim proyek mengerjakan tugasnya, project manager mengontrolnya. Closing: setelah proyek diselesaikan project manager akan menutup proyek software. Banyak proyek gagal di awal, bukan di akhir. Artinya, persiapan adalah bagian yang sangat penting bagi proyek software. Persiapan diwujudkan dalam bentuk perencanaan proyek. Tulisan ini menjelaskan point kedua yaitu Planning. 2. Faktor-faktor yang mempengaruhi perkiraan biaya Beberapa faktor yang mempengaruhi terhadap perkiraan biaya pembuatan perangkat lunak yaitu: a. Sulit untuk menentukan perkiraan biaya secara akurat selama fase perencanaan pengembangan S/W karena terlalu banyaknya faktor yang tidak diketahui pada saat itu. b. Perkiraan awal disiapkan selama fase perencanaan dan dikemukakan pada saat presentasi kelayakan proyek. Perbaikan dikemukakan pada saat presentasi persya-ratan S/W, dan perkiraan akhir dikemukakan pada saat presentasi perancangan awal. Faktor-faktor utama yang mempengaruhi biaya perangkat lunak: a. Kemampuan programmer Programmer dengan produktivitas tinggi ekuivalen dengan biaya yang kecil. 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id b. Kompleksitas produk Tiga katagori produk : aplikasi, utility, dan system Rasio kompleksitasi ketiganya adalah : aplikasi : utility : system = 1 : 3 : 9 Misal : • Jika PM adalah total upaya (dalam programmer-months) dan KDSI adalah baris instruksi dalam product (thousands delivered maka source estimator of instructions) PM menurut Boehm adalah : aplik asi : PM = 2.4 (KDSI ) utility : PM = 3.0 (KDSI) • System : PM = 3.6 (KDSI) Untuk jumlah baris program 60.000, rasio PM aplikasi : utility : system 1 : 1.7 : 2.8 (tepatnya 176.6 : 294.2 : 489.6). (Lihat gambar) • Estimasi upaya COCOMO Jika TDEV adalah waktu (dalam bulan) pengembangan sebuah program (development time), maka estimator TEDV menurut Boehm TDEV adalah aplikasi : TDEV = 2.5 (PM) u ti l ity : T D E V = 2. 5 (P M) • System : TDEV = 2.4 (PM) Unt uk j umlah bari s prog ram 60. 000, k et ig a prog ram memerluk an wak t u pengembangan sekitar 18 bulan (tepatnya TDEV aplikasi : utility : system = 17.9 : 18:3 : 17.4). 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Rata-rata jumlah programmer yang diperlukan untuk membuat 60 KDSI per bulan adalah : aplikasi : 176.6 PM / 17.9 Months = 9.9 programmer utility : 294.2 PM / 18.3 Months = 16.1 programmer system : 489.6 PM / 17.4 Months = 28.1 programmer c. Ukuran produk Ukuran produk perangkat lunak yang dibuat akan mempengaruhi besarnya Sumber daya yang dibutuhkan dalam pembuatannya. Tetapi ini harus bisa terukur karena setiap sumber daya mempunyai nilai optimal tertentu. d. Waktu yang tersedia Berbagai penelitian (kecuali Putnam) menunjukkan bahwa proyek S/W membutuhkan upaya lebih jika waktu pengembangan diperpendek atau diperpanjang (dimodifikasi) dari waktu normal. e. Keandalan yang diperlukan Menurut Boehm, Lima katagori keandalan, efek kegagalan, beserta pengali upaya (effort multiplier) meliputi: f. Tingkat teknologi Tingkat teknologi dalam proyek pengambangan S/W direfleksikan dengan empat komponen yang digunakan, yaitu: a) Bahasa pemrograman b) Mesin abstrak (H/W dan S/W) c) Praktek-praktek pemrograman d) Tools. 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Perencanaan Proyek Perangkat Lunak Perencanaan proyek Rekayasa Perangkat Lunak dari berbagai sudut pandang kurang lebih memiliki tujuan sebagai berikut: 1. Bagi Project Manager a) Untuk menggambarkan status proyek kepada manajer senior dan stakeholder b) Untuk merencanakan aktivitas tim proyek 2. Bagi anggota Tim Proyek: untuk memahami konteks pekerjaan 3. Bagi Manajer Senior: a) Untuk memastikan apakah biaya dan waktu yang dialokasikan masuk akal dan terkendali b) Untuk melihat apakah proyek dilaksanakan secara efisien dan cost effective 4. Bagi Stakeholder: a) Untuk memastikan apakah proyek masih berada pada jalurnya b) Untuk memastikan kebutuhan mereka sedang diakomodir oleh proyek Perencanaan proyek rekayasa perangkat lunak membahas berbagai tindakan atau pekerjaan yang perlu dilakukan oleh semua yang terlibat di dalam proyek, termasuk dokumen-dokumen yang sebaiknya dibuat. Dokumen Perencanaan Proyek Rekayasa Perangkat Lunak akan terdiri atas sub-sub dokumen yang meliputi Vision and Scope, Statement of Work, Resource List, Work Breakdown Structure, Project Schedule dan Risk Plan. Vision and Scope 1. Vision and Scope Dokumen ini adalah hasil kerja pertama dari seorang project manager. Berikutnya dokumen ini akan menjadi tool utama bagi project manager untuk acuan 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id bagi dokumendokumen dan proses-proses berikutnya. Dokumen Vision and Scope yang baik dapat mencegah terjadinya masalah-masalah yang dapat memakan biaya yang besar. Dengan menunjukkan dokumen ini, baik kepada stakeholder maupun anggota tim proyek, diharapkan pemahaman yang sama tentang proyek yang sedang berjalan dapat diraih. Dokumen ini dapat dibagi menjadi dua bagian, yaitu: 1. Problem Statement Bagian Problem Statement terdiri atas empat sub bab, antara lain: a. Latar belakang proyek Sub bab ini menceritakan dengan cukup mendalam baik latar belakang masalah maupun penjelasan mengenai mengapa organisasi memutuskan untuk membangun software untuk mengatasi masalah tersebut. Pada sub bab ini diceritakan sebab munculnya masalah, sejarah organisasi dengan permasalahan tersebut dan mengapa akhirnya diputuskan untuk membangun software yang diproyekkan. b. Stakeholder Pada sub bab ini akan diberikan daftar stakeholder yang dilibatkan dalam proyek. Mulai dari customer hingga manajer-manajer senior. Stakeholder ini bisa berupa nama atau jabatan. Tim proyek harus paham dengan siapa mereka bekerja dan apa bidang kerja mereka. Daftar juga dilengkapi dengan alasan dicantumkannya stakeholder tersebut. Untuk proyek-proyek besar tentu saja pencantuman nama tidak relevan karena akan menjadi terlalu panjang daftarnya. c. Pengguna Sub bab ini berisi daftar calon pengguna software. Sama dengan stakeholder, bisa berupa nama atau jabatan. Daftar juga dilengkapi dengan alasan dicantumkannya pengguna tersebut. d. Resiko Sub bab ini akan diisi dengan faktor-faktor yang mungkin menjadi pemicu munculnya masalah, seperti keterlambatan dan permasalahan lain. Resiko yang dimaksud pada sub bab ini bisa faktor internal maupun eksternal. 2015 7 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Vision of the Solution Bagian Vision of the Solution juga akan terdiri atas empat sub bab, yaitu: a. Vision statement Tujuan vision statement adalah menggambarkan apa yang ingin dicapai setelah proyek berjalan. Di dalam sub bab ini disebutkan faktor-faktor apa yang harus terpenuhi untuk menandakan kapan proyek dinyatakan selesai. Selain itu tujuan dari proyek juga harus jelas disebutkan di dalam sub bab ini. Waktu terbaik untuk membuat vision statement adalah setelah tim melakukan proses Requirement Engineering. Gambaran produk yang ingin dicapai tersebut akan menjadi batasan ruang lingkup (scope) yang harus diperhatikan oleh semua pihak yang terlibat di dalam project. Ruang lingkup ini membutuhkan biaya dan waktu tertentu. Project manager yang baik akan mempersembahkan software tepat seperti yang telah dijanjikan kepada stakeholder dan user, tepat pada waktunya dengan menghabiskan biaya (menerima bayaran) tepat sama dengan perjanjiannya dengan customer. Mungkin ada pendapat bahwa memberikan sedikit bonus fungsi terhadap software, dengan asumsi bahwa stakeholder atau user akan menyukainya, maka pendapat itu adalah kesalahan. Antara ruang lingkup, waktu dan biaya/harga harus ada keseimbangan. Jika ada penambahan pada ruang lingkup, maka seharusnya ada penambahan waktu atau biaya, jika tidak maka akan menyebabkan ketidak adilan bagi tim proyek/pengembang. Begitu juga sebaliknya. Perubahan ruang lingkup mestinya diatur dengan Change Control System. b. Daftar fitur Sebuah paket software umumnya dapat dibagi-bagi menjadi beberapa fitur. Jumlah yang umumnya dapat diterima adalah sekitar sepuluh fitur. Jumlah ini sudah cukup menggambarkan kompleksitas software namun tetap nyaman dibaca oleh tim pengembang. Tiap fitur sebaiknya ditulis dalam paragraph yang terpisah atau dalam bentuk 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id pointer-pointer. Deskripsi fitur-fitur ini tidak perlu sangat detil, cukup beberapa kalimat yang menggambarkan penjelasan umum tentang fitur tersebut. Fitur-fitur ini mungkin mengalami penambahan atau pengurangan, sesuai dengan permintaan stakeholder. Jika perlu, sebuah fitur dapat dilengkapi dengan use case. Namun tentu saja use case dibuat agar cukup simpel untuk dipahami oleh semua stakeholder. 3. Ruang lingkup tiap fase (jika perlu) Terkadang deadline yang diberikan untuk mengerjakan sebuah proyek software membuat pengerjaan seluruh fitur yang diajukan tidak mungkin selesai. Oleh karenanya dibuat solusi untuk membagi software menjadi beberapa fase rilis. Software akan dirilis pada saat deadline tercapai, namun dengan fitur yang dikurangi. Sedangkan rilis berikutnya lah yang memuat semua fitur. Fitur-fitur yang ada pada rilis awal seharusnya adalah fitur yang sifatnya lebih penting daripada fitur lainnya, menurut stakeholder. Hal semacam ini perlu dikonsultasikan kepada tim pengembang. 4. Fitur yang tidak akan dibuat Terkadang stakeholder meminta fitur yang memang harus dibuang/ditinggalkan karena tidak masuk akal untuk diselesaikan dalam waktu yang tersedia, atau karena sebab-sebab lain. Fitur-fitur semacam ini perlu dicantumkan pada sub bab ini. Ini dicantumkan untuk diketahui semua pihak agar ada kesepahaman dan agar semua setuju dengan penghapusan fitur ini. 2. Statement of Work Statement of Work adalah dokumen yang menggambarkan semua produk yang akan dihasilkan selama proyek berjalan dan siaa yang akan mengerjakannya. Secara lebih detil, di dalam SOW akan dirinci: 1. Daftar fitur yang akan dibuat; jika software akan dirilis dalam fase-fase, maka fiturnya juga harus dibagi ke dalam fase-fase tersebut. 2. Deskripsi hasil kerja (work product: spesifikasi kebutuhan, source code, test plan, laporan defect, dll) yang akan dibuat. 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Estimasi usaha setiap work product tersebut Estimasi dibutuhkan agar proyek dapat berjalan dan selesai tepat waktu. Project manager perlu membantu timnya untuk membuat estimasi yang tepat. Sebuah pendekatan perlu diambil untuk menyeragamkan teknik e stimasi ini. Salah satu teknik estimasi yang dapat dipilih adalah Wideband Delphi. Berikut ini langkah-langkah di dalam Wideband Delhi: 1. Memilih tim estimasi Project manager memilih seorang moderator dan tim estimasi yang terdiri atas 3 hingga 7 orang. Jika tim yang telah dipilih merasa bahwa dokumen Vision and Scope kurang memberikan informasi, maka project manager harus memperbaiki dokumen tersebut. 2. Kickoff Meeting Pada rapat ini, tim akan membuat sebuah Work Breakdown Structure dan mendiskusikan berbagai asumsi yang muncul. Langkah-langkah yang dapat dijadikan acuan ketika rapat berlangsung kurang lebih sebagai berikut: a. Moderator menjelaskan metode Wideband Delphi b. Moderat or mere v iew dok umen Vis ion and Scope dan d ok umen dok umen pendukungnya, jika ada anggota tim yang belum membacanya. c. Tim mendiskusikan produk yang akan dibuat dengan berbagai asumsinya, d. Tim membuat 10 hingga 20 pekerjaan utama sebagai representasi pekerjaan level tertinggi pada WBS e. Tim mendiskusikan estimasi terhadap WBS (jam, minggu, halaman, dll) tersebut hingga mendapatkan kata sepakat. 3. Individual Preparation Setelah kicoff meeting tiap anggota berusaha mengestimasi tiap-tiap pekerjaan di dalam WBS secara mandiri. Tahapan ini disebut sebagai Individual Preparation. Sebelumnya, moderator mencatat semua asumsi dan WBS kemudian membagikannya kepada semua anggota tim. Format 2015 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id berikut ini bisa dijadikan acuan untuk mendokumentasikan Individual Preparation. Gambar 3.2. Dokumen Individual Preparation 4. Estimation Session Pada rapat ini, anggota tim bersama-sama merevisi estimasi-estimasiyang telah dibuat hingga menemukan kata sepakat. Dokumen berikut dapat dijadikan acuan sebagai contoh untuk membuat dokumentasi selama Estimation Session. Kepada setiap anggota tim akan dibagikan dokumen semacam ini (yang kosong) untuk kemudian direvisi selama jalannya Estimation Session. 2015 11 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 3.3 Estimation Form Berikutnya: a. Moderator dapat mengumpulkan Estimation Form. Estimasi tersebut kemudian ditabulasikan di papan tulis kemudian ditunjukkan kepada hadiri. Tabulasi tersebut dapat berbentuk seperti berikut: Gambar 3.4 Estimasi awal Estimation Form kemudian dikembalikan kepada anggota tim b. Anggota kemudian akan melihat tabulasi tersebut. Jika diskusi meminta perubahan estimasi, maka perubahan tersebut dapat langsung dituliskan pada Estimation Form yang ada di tangan setiap anggota tim c. Anggota tim mungkin akan menyampaikan perbedaan pendapat. Tetapi di dalam rapat ini tidak akan dibahas estimasi individu. Jadi yang mungkin diperdebatkan justru pekerjaannya. Tahap ini mugkin terbagi menjadi dua sesi, sesi pertama 40 menit dan sesi kedua 20 menit. 2015 12 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id d. Rapat akan merevisi estimasi individu dengan mengisikan kolom Delta berikutnya pada Estimation Form. Isinya bisa +3, +2, -4 dsb. Nilai total barunya akan dituliskan pada bagian bawah form. Tahap-tahap di atas dapat berulang hingga selesai, yaitu jika semua anggota tim menyetujui estimasi hasil rapat, atau jika rapat sudah berlangsung selama dua jam. Hasilnya akan menghasilkan tabulasi estimasi seperti berikut: Gambar 3.5 Estimasi akhir 5. Review Project manager akan meringkas, mengkompail kemudian mereview hasil estimasi untuk kemudian digunakan sebagai dasar perencanaan proyek software. 3. Resource List Resource list adalah daftar resource (sumber daya) yang digunakan selama proyek berlangsung. Daftar ini berisi apa saja yang dibutuhkan berdasarkan jadwal proyek dengan mencantumkan deskripsi resource tersebut serta limit ketersediaan resource tersebut. Daftar semacam ini umumnya dapat dibuat menggunakan software manajemen proyek. Tetapi bisa juga dibuat dengan worksheet atau word processor. Setelah SOW dan Resource List dibuat, seorang project manager harus membuat jadwal proyek (project schedule). Ini bisa dilakukan dengan urutan sebagai berikut: a. Membuat Work Breakdown Structure b. Estimasi usaha yang dibutuhkan oleh setiap pekerjaan pada WBS 2015 13 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id c. Project schedule dibuat dengan mengalokasikan resource dan waktu, berdasarkan kalender, untuk tiap pekerjaan pada WBS Jika WBS mengalami revisi (setelah melakukan estimasi, misalnya), misalnya penambahan, perubahan atau penghapusan pekerjaan, maka revisi ini harus tercatat di dalam dokumen Project Plan dengan disertai dengan keterangan waktu kapan dibuatnya perubahan tersebut. 4. Work Breakdown Structure Work Breakdown Structure, disingkat WBS, berisi daftar pekerjaan yang jika diselesaikan akan menghasilkan work product. WBS menyebutkan: a. Apa saja pekerjaan yang akan dilakukan, b. Tipe-tipe resource yang dibutuhkan untuk bekerja, c. Estimasi tiap elemen pekerjaan, d. Identifikasi lokasi penyimpanan. Tetapi tidak mencantumkan: a. Siapa yang mengerjakan pekerjaan-pekerjaan itu, b. Dan kapan pekerjaan itu akan diselesaikan 5. Project Schedule Project Schedule atau jadwal proyek dibuat oleh project manager untuk mengatur manusia di dalam proyek dan menunjukkan kepada organisasi bagaimana pekerjaan (proyek) akan dilaksanakan. Ini adalah alat untuk memantau (bagi project manager) apakah proyek dan tim masih terkendali atau tidak. Project schedule berbentuk kalender yang dihubungkan dengan pekerjaan yang harus dikerjakan dan daftar resource yang dibutuhkan. Sebelum jadwal dibuat, WBS harus terlebih dahulu ada, jika tidak maka jadwal tersebut akan terkesan mengada-ada. Untuk membuat project schedule, ada beberapa software yang bisa dijadikan pilihan. Pilihan software yang gratis dan open source antara lain: Open 2015 14 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Workbench, dotProject, netOffice dan Tutos. Beberapa hal perlu diperhatikan ketika membuat project schedule, seperti: a) Alokasi resource pada tiap pekerjaan Resource bisa berupa berbagai hal seperti manusia, barang, peralatan (komputer, proyektor, dll), tempat (ruang rapat, misalnya) atau layanan (seperti training atau tim pendukung out source) yang dibutuhkan dan mungkin ketersediaannya terbatas. Bagaimanapun juga resource yang utama adalah manusia. Pertama, project manager akan mengalokasikan orang(-orang) tertentu untuk suatu pekerjaan. Kemudian, selama pekerjaan tersebut berlangsung, orang tersebut mungkin menjadi terlalu sibuk sehingga tidak bisa dialokasikan untuk pekerjaan lainnya. Perhatikan bahwa pemilihan pelaku perlu disesuaikan dengan kemampuan dan berbagai hal lain karena ada pekerjaan yang dapat dilakukan oleh siapa saja, tetapi umumnya pekerjaan hanya dapat dikerjakan oleh satu atau beberapa orang saja. b) Identifikasikan setiap ketergantungan Sebuah pekerjaan disebut memiliki ketergantungan jika melibatkan aktivitas, resource pekerjaan/aktivitas atau lain. work Contoh: product test plan yang tidak dihasilkan mungkin dilaksanakan selama software belum diimplementasikan/ditulis, program baru dapat ditulis setelah class atau modul dibuat dan dideskripsikan pada tahapan desain. Tiap pekerjaan pada WBS perlu diberi nomor, dengan angka tersebut bergantung pada nomor pekerjaan syaratnya. Berikut ini adalah sedikit gambaran tentang bagaimana suatu pekerjaan menjadi tergantung pada pekerjaan lainnya. 2015 15 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id c) Buat jadwalnya Tiap pekerjaan juga memiliki jangka waktu pekerjaan. Dengan demikian jadwal bisa dibuat, contoh: Tiap pekerjaan ditunjukkan dengan kotak, sedangkan ketergantungan antar pekerjaan ditunjukkan dengan gambar panah. Kotak hitam berbentuk wajik antara D dan E (pada gambar di atas) disebut milestone atau pekerjaan tanpa durasi. Milestone digunakan untuk menunjukkan kejadian penting pada jadwal. Sedangkan kotak hitam panjang antara C dan D yang juga mengandung potongan wajik menunjukkan summary task atau dua sub pekerjaan yang memiliki induk yang sama. Jadwal bisa dibuat dalam bentuk Gantt Chart, PERT atau diagram semacamnya. Contoh Gantt Chart yang dibuat dengan sebuah tool manajemen proyek: 2015 16 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 6. Risk Plan Ris k p la n ad a l ah daf t ar r es ik o/ ma sa l a h ya ng mu ng k i n t e rj a d i s e l am a pr o yek berlangsung dan bagaimana menangani terjadinya resiko tersebut. Bagaimanapun juga ketidakpastian adalah musuh semua rencana, termasuk rencana proyek. Terkadang ada saja waktu-waktu yang tidak menyenangkan bagi proyek, banyak kesulitan terjadi misalnya suatu resource tiba-tiba tidak tersedia. Oleh karenanya risk plan adalah persiapan terbaik menghadapi ketidakpastian. Langkah-langkah berikut dapat menjadi acuan untuk mendapatkan Risk Plan: a) Pembahasan resiko potensial Project manager akan memimpin sebuah sesi/rapat untuk mengidentifikasikan masalah-masalah yang mungkin akan muncul. Anggota tim akan dipancing untuk mengemukakan resiko-resiko yang terpikirkan. Project manager akan menuliskannya di papan tulis setiap 2015 17 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id ada yang mengemukakan pendapat yang relevan. Sedikit pendapat mungkin akan muncul pada awalnya, kemudian berlanjut dengan tanggapan yang susul-menyusul hingga akhirnya suasana mendingin sampai akhirnya pendapat terakhir diutarakan. Resiko yang dimaksud di sini adalah resiko spesifik. Jika suatu resiko dirasa belum spesifik maka project manager akan memancing agar permasalahan disampaikan secara lebih spesifik. Sumber masalah yang baik lainnya adah asumsi-asumsi yang muncul ketika membuat Vision and Scope dan melakukan estimasi dengan metode Wideband Dephi b) Estimasi dampat tiap resiko/masalah Tim akan memberikan rating untuk setiap resiko. Nilainya berkisar dari 1 (masalah dengan resiko kecil) hingga 5 (masalah dengan resiko besar, kemungkinan munculnya besar, mungkin menghabiskan biaya besar dan sulit untuk membereskannya). c) Buat sebuah risk plan Tim akan mengidentifikasi langkah-langkah yang akan di ambil untuk mengatasi masalah-masalah yang akan muncul tersebut, dimulai dari resiko bernilai 5. Contoh sebuah dokumen risk plan: Gambar 3.6 Risk Plan 2015 18 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Referensi 1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill 2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley 2015 19 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Ma n a j e me n Pr o ye k Perangkat Lunak Perencanaan Proyek Perangkat Lunak (Lanjutan) Fakultas Program Studi Fakultas Ilmu Komputer 2015 1 Informatika Tatap Muka Kode MK 04 Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini menjelaskan tentang maksud dari perencanaan proyek perangkat lunak Mahasiswa mampu memahami mengenai perencanaan perangkat lunak, mampu memahami unsur – unsur yang patut diperhitungkan dalam merencanakan pembuatan perangkat lunak, dan mampu mengenali metode yang umum digunakan dalam sebuah perencanaan proyek pengembangan perangkat lunak. Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Perencanaan Proyek Perangkat Lunak 1. Perencanaan Proyek Perangkat Lunak A. Pendefinisian Masalah 1. Nyatakan masalah yang akan diselesaikan secara tegas, termasuk di dalamnya batasan masalah dan sasaran yang ingin dicapai. Pernyataan masalah ditetapkan dalam sudut pandang pelanggan. Pernyataan masalah dalam sudut pelanggan misalnya : masalah penggajian, masalah inventory, atau masalah pengendalian lalu lintas udara Pernyataan masalah dalam sudut pengembang misalnya : masalah relational data bases, masalah algoritma sorting. Teknik-teknik yang digunakan untuk mendapatkan informasi kebutuhan pelanggan meliputi : wawancara dengan pelanggan, pengamatan terhadap gugus tugas yang bermasalah, kinerja sebenarnya dari gugus tugas. 2. Rancang sebuah strategi solusi berbasis komputer. Solusi harus ekonomis dan dapat diterima secara sosial maupun secara politik. Solusi yang ekonomis adalah sistem komputerisasi yang memberikan pelayanan dan informasi yang sama dengan sistem lama tetapi membutuhkan waktu dan personal yang lebih sedikit dalam pengoperasiannya. Sistem baru mungkin akan mengurangi keterlibatan personal; hal ini mungkin akan menimbulkan dampak sosial, bahkan politik. 3. Identifikasi sumber daya yang tersedia. Tiga subsistem dalam sistem komputerisasi adalah : perangkat keras, perangkat lunak, dan personal. Identifikasi juga keterkaitan antar ketiga subsistem tersebut. 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Subsistem perangkat keras meliputi perangkat keras beserta periferalnya, dan dalam beberapa kasus juga meliputi peralatan lain seperti sensor kendali proses, antena, dan radar. Subsistem perangkat lunak meliputi perangkat lunak yang akan dikembangkan ditambah dengan perangkat lunak yang ada yang boleh jadi digunakan seadanya atau dalam versi modifikasinya. Subsistem personal meliputi para operator, pemelihara, dan end user. 4. Tetapkan sasaran dan persyaratan, baik untuk proses pengembangan maupun produk. Sasaran adalah tujuan yang ingin dicapai. Sasaran digunakan sebagai dasar bagi kerangka kerja proyek pengembangan perangkat lunak, baik dalam proses pengembangan maupun untuk produk kerja. Sasaran dapat dinyatakan secara kualitatif maupun kuantitatif. Contoh : Proses (kualitatif) : harus meningkatkan keterampilan personal Proses (kuantitatif) : sistem harus selesai dalam 12 bulan Produk (kualitatif) : sistem harus membuat pekerjaan user maikin menarik Produk (kuantitatif) : sistem harus mengurangi biaya transaksi sebesar 25%. Persyaratan menetapkan spesifikasi kemampuan sistem dalam menyelesaikan masalah. Persyaratan mencakup aspek-aspek : fungsional, kinerja, perangkat keras, perangkat lunak, personal, dan pengantarmukaan. Kalau memungkinkan, nyatakan persyaratan secara kuantitaif untuk menghindari ketidakjelasan dan perselisihan antara pengembang dengan pelanggan. Contoh persyaratan kuantitatif : Akurasi sudut fase harus berada pada kisaran 0.5 derajat Tanggapan maksimum terhadap interrup adalah 0.25 detik Space maksimum yang digunakan sistem adalah 50 KB memori utama, tidak termasuk space untuk file-file buffer 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Sistem harus dapat beroperasi dengan kemampuan 95% ketika dioperasikan selama 24 jam penuh Contoh persyaratan kualitatif : Akurasi harus cukup tinggi Sistem harus mempunyai tanggapan yang baik Sistem harus hemat dalam penggunaan memori utama Keandalan sistem harus 99% Sasaran dan persyaratan dapat juga ditetapkan melalui atribut-atribut kualitas yang harus dimiliki sistem, di antaranya : portability (S/W tidak bergantung mesin), realiability (kemampuan program melakukan fungsi yang diinginkan), efficiency (menggunakan sumber daya minimal), accuracy (ukuran besarnya error), robustness/integrity (kemampuan bekerja dengan baik walau mendapat input yang tidak benar), correctness (hasil sesuai dengan yang diharapkan). 5. Tetapkan kriteria penerimaan sebuah system. Kriteria harus dinyatakan sedemikian rupa sehingga tidak akan menimbulkan perselisihan antara pengembang dan pelanggan. Kriteria harus dapat diverfikasi dengan suatu metoda baku seperti : peninjauan langsung, analisa, atau serangkaian uji, terhadap produk yang dihasilkan. B. Pengembangan Strategi Solusi Kecenderungan untuk menerima begitu saja solusi pertama yang terlintas di benak kita adalah masalah utama dalam perkeayasaan perangkat lunak. Ini tidak memberi peluang terhadap solusi lain yang sebenarnya masih mungkin untuk dipertimbangkan. Kembangkan strategi solusi. Strategi bukan merupakan solusi rinci tetapi penyataan umum tentang sifat-sifat dari solusi yang mungkin. Langkah-langkah pengembangan strategi solusi adalah sebagai berikut : 1. Uraikan beberapa strategi solusi tanpa memperhatikan batasanbatasan apapun 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Adakan studi kelayakan terhadap setiap strategi. Perhatikan bahwa an unreasonable idea will lead to other ideas, some of which may be very reasonable. 3. Rekomendasikan sebuah strategi solusi, beri catatan mengapa solusi lain ditolak 4. Buat sebuah daftar prioritas karakteristik produk. Daftar ini penting jika kondisi tidak memungkinkan untuk mengimplementasikan seluruh kemampuan produk yang diinginkan seperti yang telah ditentukan sebelumnya. C. Perencanaan Proses Pengembangan 1. Tentukan sebuah model life-cycle dan struktur organisasi proyek. 2. Rencanakan konfigurasi managemen, jaminan kualitas, dan kegiatan validasi 3. Tentukan tools setiap fase proyek, serta teknik-teknik dan notasi yang digunakan 4. Tetapkan perkiraan biaya untuk pengembangan sistem 5. Tetapkan jadwal pengembangan 6. Tetapkan perkiraan susunan personalia proyek 7. Tetapkan perkiraan sumber daya sistem komputaerisasi yang diperlukan untuk mengoperasikan dan memelihara sistem 8. Siapkan daftar istilah 9. Identifikasi sumber-sumber informasi dan jadikan sebagai acuan proyek. D. Life Cycle Life-cycle sebuah perangkat lunak mencakup semua kegiatan yang yang perlu dilakukan untuk mendefinisikan, mengembangkan, menguji, mengantarkan, mengoperasikan, dan memelihara produk perangkat lunak. Beberapa model yang akan dibahas adalah : model fase (phased model), model biaya (cost model), model prototipe (prototype model), dan model berurutan (successive model). 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id E. Model Fase Model ini membagi life cycle ke dalam sederetan kegiatan (fase). Setiap fase membutuhkan informasi masukan, proses, dan produk yang terdefinisi dengan baik. Deretan fase tersebut adalah : analisa, perancangan, implementasi, pengujian, dan pemeliharaan. Berikut ini model fase dasar yang dinyatakan sebagai waterfall chart : Gambar 4.1 Life cycle mode fase dari sebuah perangkat lunak Subfase perencanaan menghasilkan dua produk : System Definition dan Poject Plan. Format kedua produk adalah sebagai berikut : 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id S u b f a s e p e n e t a p a n persyaratan menghasilkan sebuah produk : Software Requirements Specifications. Format 2015 7 Fase perancangan melakukan identifikasi terhadap komponen perangkat lunak (fungsi, arus data, penyimpanan data), hubungan antar komponen, struktur perangkat lunak (dekomposisi menjadi modul-modul dan pengatarmukaannya). Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id produk ini adalah sbb : Fase ini menghasilkan arsitektur rinci, terutama dalam bentuk algoritma algoritma. Fase implementasi adalah terjemahan langsung arsitektur rinci ke dalam bahasa pemrograman tertentu. Subfase uji integrasi melakukan pengujian terhadap semua modul dan pengantarmukaan sehingga pada level sistem dapat beroperasi dengan benar Subfase uji penerimaan melakukan baerbagi pengujian mengacu kepada berbagai persyaratan yang telah ditentukan. Kegiatan yang meliputi fase pemeliharaan adalah : peningkatan kemampuan, adaptasi terhadap lingkungan pemrosesan, dan melakukan berbagai koreksi atas kesalahan yang terjadi Penilaian kemajuan proyek akan lebih mudah jika pada model fase tersebut ditetapkan beberapa tonggak penting ( milestone) yang pada setiap fase atau antar setiap dua fase yang berurutan. Berikut ini Life cycle mode fase dari sebuah perangkat lunak yang dilengkapi dengan kegiatan review dan tonggak penting : 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id F. Model Biaya Model biaya adalah cara pandang lain model fase sebuah perangkat lunak dengan cara memperhatikan biaya berbagai kegiatan dalam proyek perangkat lunak. Biaya proyek adalah jumlah biaya dari setiap fase proyek. Biaya setiap fase mencakup biaya kegiatan dan penyiapan produk pada fase tersebut ditambah dengan biaya verifikasi konsistensi produk suatu fase terhadap semua fase sebelumnya. Gambar 4.2 Model Biaya 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Ada 2 sisi penting dari model biaya : Karena modl biaya hanyalah cara pandang lain dari model fase maka semua dokumen yang dihasilkan tepat sama dengan yang dihasilkan pada model fase. Biaya verifikasi, apalagi perbaikan, atas suatu produk akan makin besar jika produk tersebut dihasilkan oleh suatu fase yang jauh di belakang fase saat verifikasi dilakukan. G. Model Prototipe Gambar 4.3 Model Prototipe 2015 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Beberap catatan tentang model prototipe : Sebuah prototipe adalah model dari sebuah produk perangkat lunak tetapi dengan beberapa keterbatasan, misalnya : keterbatasan kemampuan, keandalan yang rendah, dan kinerja yang tidak efisien. Alasan penggunaan model prorotipe adalah : 1. untuk menggambarkan format data masukan, pesan-pesan, laporan, dan dialog interaktif 2. untuk mengeksplorasi isu-isu teknis dalam produk yang diusulkan 3. model fase ‘analisis → perancangan → implementasi’ tidak dapat digunakan 2. Perencanaan Struktur Organisasi A. Struktur Pelaksana Proyek Ada 3 format struktur pelaksana proyek : format proyek, format fungsional, dan formta matriks 1. Format Proyek Dibentuk sebuah team yang melakukan pekerjaan proyek dari awal sampai akhir Annggota team mendefinisikan mengimplementasikan, melakukan produk, uji, merancang melakukan review, produk, dan mempersiapkan dokumen-dokumen pendukung Sebagian anggota team melakukan instalasi dan pemeliharaan, dan melanjutkan ke proyek baru Team proyek biasanya bekerja selama 1-3 tahun dan ditugaskan untuk proyek berikutnya jika proyek pertama sudah selesai 2. Format Fungsional Dalam format ini dibentuk beberapa team untuk melaksanakan pekerjaan proyek setiap fase. Semua team tidak dibentuk pada saat yang sama. Anggota team dapat dirotasi. Team analisis dan perancangan bertugas untuk mengembangkan System Definition (SD) dan Project Plan (PP). 2015 11 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Team pendefinisian produk menerima produk SD dan PP, melakukan analisa persya-ratan perangkat lunak, dan menyiapkan Software Requirement Specification (SRS). Team perancangan merancang produk yang sesuai dengan SRS dan SD. Team implementasi mengimplementasi, debugging, dan melakukan uji per unit sistem Team uji sistem melakukan uji integrasi Team kualitas melakukan sertifikasi terhadap semua produk kerja Team pemelihara melakukan pemeliharaan produk 3. Format matriks Setiap gugus fungsional memiliki team manajemen dan kelompok spsialis yang hanya melaksanakan fungsinya sendiri. Gambar 4.4 Struktur Organisasi 2015 12 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id B. Struktur Tim Pemrograman 1 Demokrasi Gambar 4.5 Struktur Organisasi – Demokrasi Berbagai keputusan dilakukan melalui kesepakatan kelompok Kepemimpinan berotasi sesuai dengan jenis pekerjaan yang sedang dilaksanakan dan spesialisasi anggota 2 Kepemimpinan Gambar 4.6 Struktur Organisasi – Kepemimpinan Pimpinan merancang produk, mengimplementasikan bagian kritis dari produk, dan membuat semua keputusan teknis utama 2015 Programer menuliskan source code, debugging, dokumentasi, dan uji unit 13 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pustakawan mengurus listing program, merancang dokment-dokumen, membuat rencana uji Back-up programmer berperan sebagai konsultan bagi pimpinan untuk berbagai masalah teknis, memelihara hubungan dengan pelanggan dan kelompok publikasi serta kelompok jaminan kualitas, dan melakukan sejumlah analisisperancangan-implementasi di bawah pengawasan pimpinan. Referensi 1. Presman, Rouger S. 1997. Software Enigineering, 4th Edition. Mc. Graw Hill 2. Sommerville,Ian. 2004. Software Engineering, 7th Edition. Addison Wesley 2015 14 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Estimasi Biaya Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 05 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini menjelaskan tentang perencanaan biaya dalam sebuah proyek Mahasiswa memiliki kemampuan untuk menganalisis dan menetapkan biaya dari sebuah proyek yang akan dijalankan Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Manajemen Biaya Proyek 1. Pengertian Manajemen Biaya Proyek Manajemen biaya proyek merupakan salah satu dari 9 area pengetahuan dalam manajemen proyek. Manajemen biaya proyek diperlukan untuk memastikan bahwa perencanaan proyek sudah mencakup : 1. Estimasi biaya untuk setiap resource 2. Pengalokasian estimasi biaya setiap resource yang dibutuhkan oleh setiap work item Dalam manajemen biaya proyek, terdapat beberapa proses yang dilibatkan dalam tujuan penyelesaian proyek sesuai dengan anggaran yang disediakan. Proses tersebut yaitu estimasi, budgeting dan kontrol biaya. Gambar 5.1 Overview Manajemen Biaya Proyek 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Proses estimasi sangat menentukan kelangsungan proyek baik dari mulai tahap desain, perencanaan, konstruksi, dan maintenance. Berbagai tipe dan cara dalam mengestimasi biaya akan tergantung pada data/informasi yang tersedia, batas waktu, dan tujuan dari estimasi tersebut. Peran estimator dalam estimasi biaya proyek konstruksi dapat ditinjau dari ketelitian, pengalaman dan spesialisasi terhadap proyek secara keseluruhan. Untuk mendapatkan jawaban dari rumusan masalah pada bab 1, maka pada bab ini akan diberikan dasar pemikiran ilmiah yang dilandasi dengan teori¬teori ilmiah yang diperoleh dari area Manajemen Proyek, terutama dalam area pengetahuan Manajemen Biaya Proyek. Dalam landasan teori ini, terdapat 3 sumber utama yang akan dijadikan acuan dalam pemecahan masalah yaitu : 1. Teori Manajemen Proyek dan lebih spesifik ke manajemen biaya di proyek, sebagian besar akan diambil dari literatur Manajemen Proyek seperti PMBoK, dan sumber lainnya yang memberikan teori tentang Manajemen Proyek. 2. Teori Manajemen Biaya Proyek, khususnya yang membahas tentang proses estimasi biaya proyek, kinerja biaya proyek serta kegiatan-kegiatan yang termasuk di dalamnya maupun yang memberikan pengaruh terhadap kedua hal tersebut di atas. Teori ini diperoleh dari berbagai jurnal ilmiah baik nasional maupun internasional, serta beberapa buku yang membahas tentang estimasi biaya dan kinerja biaya proyek. 3. Aplikasi pengembangan manajemen biaya proyek khususnya dalam masalah estimasi dalam sebuah perusahaan konstruksi yang telah memiliki dan menerapkan sistem estimasi secara lebih akurat dengan data/informasi yang diberikan, waktu serta tujuan estimasi. Hal ini bertujuan untuk menjadi bahan pembanding dan masukan bagi penelitian ini. 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Estimasi Biaya Proyek 1. Definisi Terdapat beberapa literatur yang membahas mengenai pengertian estimasi biaya. Dalam AACE International (2004), disebutkan bahwa estimasi merupakan evaluasi dari keseluruhan elemen dari sebuah proyek atau usaha yang diberikan berdasarkan kesepakatan terhadap suatu lingkup pekerjaan. Dysert, Larry R. mengungkapkan bahwa estimasi biaya merupakan sebuah prediksi terhadap biaya yang akan dibutuhkan dari sebuah proyek berdasarkan data dan lingkup proyek yang diberikan yang akan dilaksanakan pada sebuah lokasi dan waktu yang telah ditetapkan. Dalam sebuah estimasi biaya terdapat identifikasi dan pertimbangan dalam memperkirakan beberapa alternatif biaya untuk memulai dan menyelesaikan proyek. Jumlah biaya yang akan dikeluarkan dan risiko harus dapat dipertimbangkan, misalnya seperti membuat keputusan untuk membeli suatu barang atau hanya menyewanya saja untuk keperluan proyek, berbagi sumber daya dalam rangka mengoptimalkan biaya dalam proyek. Biaya yang disusun akan memperhitungkan keseluruhan sumber daya yang dibutuhkan dalam sebuah proyek, termasuk tenaga kerja, material, peralatan, jasa, dan fasilitas dan beberapa kategori spesial seperti faktor inflasi atau biaya contingency. Estimasi biaya merupakan penilaian kuantitatif yang mendekati untuk kebutuhan sumber daya dalam proyek. Tujuan dari dibuatnya suatu estimasi proyek adalah : 1. Sebagai dasar dalam pembuatan anggaran proyek 2. Sebagai alat untuk mengontrol biaya proyek 3. Untuk memonitor progress, dengan membandingkan anggaran biaya, biaya estimasi dengan actual di lapangan. 4. Untuk membuat suatu database biaya yang dapat digunakan untuk estimasiestimasi berikutnya. 5. Estimasi biaya dan penjadwalan merupakan 2 aktifitas yang sangat berkaitan erat. 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Jenis Estimasi Biaya Dilihat dari kelengkapan datanya dan terhadap tahapan proyek, maka estimasi biaya dapat dibedakan menjadi 3 yaitu: 1. Preliminary Estimate Merupakan estimasi biaya pada tahap perencanaan. Pada tahap ini, desain proyek belum ada, hanya ada dalam bentuk gagasan. Estimasi biaya diberikan untuk keperluan studi kelayakan. Estimasi dihitung secara kasar berdasarkan informasi harga dari proyek sejenis per satuan kapasitas produksi atau per satuan fungsinya atau per satuan luasnya. 2. Semi Detail Estimate Estimasi ini ada pada tahap conceptual engineering. Estimasi biaya sudah dapat dihitung secara detail karena basic design proyek sudah ada. Hasil estimasi biaya pada tahap ini dapat dipergunakan sebagai dasar pertimbangan untuk menyiapkan dana yang diperlukan bagi proyek tersebut, oleh karena itu sering juga disebut sebagai budget estimate bagi owner. 3. Definitive Estimate Estimasi ini ada pada tahap detailed engineering, dimana semua informasi yang diperlukan untuk pelaksanaan sudah lengkap. Estimasi biaya sudah dapat dihitung secara detail karena construction drawing sudah ada. Beberapa hal dipertimbangkan dalam estimasi ini antara lain metode konstruksi, kondisi lokasi proyek, preliminary work yang akan dilakukan, penggunaan sumber daya tenaga, alat dan material serta subkontraktor sesuai spesifikasi yang ada serta waktu pelaksanaan proyek. 3. Metode Estimasi Biaya Setelah memperoleh data dan informasi yang lengkap mengenai suatu proyek, maka proses estimasi akan dilanjutkan dengan pengolahan data tersebut. Terdapat beberapa metode yang digunakan dalam pengolahan data untuk menyusun suatu estimasi biaya yaitu: 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Expert Judgment Dari para ahli dapat diperoleh informasi historikal berdasarkan pengalaman mereka terutama bagi proyek-proyek sejenis. Dari para ahli juga diperoleh pertimbangan untuk menggabungkan beberapa metode dalam proses estimasi dan bagaimana menyelaraskan perbedaan yang ada dalam metode tersebut. 2. Analogous Estimating Menggunakan nilai dari sebuah parameter, seperti lingkup, biaya, anggaran dan waktu maupun menggunakan skala perbandingan terhadap ukuran, kompleksitas proyek sebelumnya yang dijadikan dasar untuk menyusun estimasi biaya proyek yang serupa. 3. Parametric Estimating Digunakan sebagai statistik dari hubungan antara data historikal dengan variabel lainnya seperti luas area untuk menghitung estimasi beberapa parameter seperti biaya, anggaran dan masa pelaksanaan. 4. Bottom-Up Estimating Merupakan metode dalam mengestimasi komponen pekerjaan. Biaya dan akurasi dari tipe ini dipengaruhi oleh ukuran dan kompleksitas dari aktiftas individual maupun paket pekerjaan. 5. Three-Point Estimates Keakuratan dalam sebuah estimasi dapat ditingkatkan dengan mempetimbangkan aspek ketidaktentuan dan risiko. Dalam Program Evaluation and Review Technique (PERT) digunakan 3 estimasi untuk memperkirakan biaya dari sebuah aktifitas, yaitu: 1. Most Likely (CM), biaya aktifitas berdasarkan penilaian usaha yang realistik terhadap suatu pekerjaan 2. Optimistic (CO), biaya aktifitas berdasarkan pertimbangan yang optimis untuk aktifitas tersebut 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Pessimistic (CP), biaya aktifitas berdasarkan pertimbangan pesimis terhadap suatu aktifitas Ketiga parameter diatas dirumuskan dalam bentuk sebagai berikut : Untuk metode ini biasanya digunakan untuk perkiraan biaya yang mengandung unsur ketidakpastian seperti estimasi biaya penelitian karena menggunakan pertimbangan optimistik, pesimistik. 6. Reserve Analysis Estimasi biaya yang termasuk biaya tak terduga. Biaya tak terduga tersebut dapat berupa prosentase dari nilai estimasi, nilai yang tetap, atau dapat dikembangkan dari metode analisa kuantitatif. 7. Cost of Quality Menyangkut perhitungan seluruh biaya yang dipersiapkan untuk mencegah adanya ketidakpuasan terhadap kualitas produk yang akan mengakibatkan rework. 8. Project Management Estimating Software Beberapa program komputer dapat digunakan sebagai alat untuk membantu dalam mengestimasi biaya. 9. Vendor Bid Analysis Metode estimasi biaya, termasuk analisa biaya dari sebuah proyek yang dimenangkan tanpa melalui proses persaingan karena memperoleh informasi dari rekanan, tentunya akan diperlukan tambahan biaya. 2015 7 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 4. Proses Estimasi Biaya Proses estimasi biaya merupakan keseluruhan proses dalam estimasi dimulai dari proses input data, teknik yang digunakan dalam pengolahan data serta output yang dihasilkan dari sebuah estimasi. Diberikan pula diagram alur data estimasi biaya. Gambar 5.2 Estimasi biaya: Input, Tools & Teknik, Output Tahapan input dalam suatu proses estimasi mencakup beberapa hal yang diperlukan untuk mendukung proses pelaksanaan estimasi seperti: 1. Scope Baseline Menggambarkan pernyataan lingkup pekerjaan seperti deskripsi produk, kriteria yang dapat diterima, hasil yang diharapkan, batasan proyek dan asumsi. Dalam scope baseline terdapat pula WBS yang menggambarkan hubungan dari semua komponen dalam proyek. 2. Penjadwalan Proyek Jenis dan jumlah dari sumber daya serta waktu yang dibutuhkan dalam rangka peyelesaian proyek merupakan faktor yang penting dalam menentukan biaya proyek. 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Perencanaan Sumber Daya Atribut staf proyek, biaya personel, dan bonus bagi karyawan merupakan komponen yang penting dalam menyusun estimasi biaya. 4. Penyusunan Daftar Risiko Identifikasi risiko diperlukan untuk pengendalian biaya akibat adanya risiko. Risiko dapat memberikan dampak dalam aktifitas maupun biaya proyek. 5. Pertimbangan Faktor diluar Lingkungan Perusahaan Faktor – faktor yang dapat mempengaruhi antara lain kondisi pasar dan informasi komersial yang ada. Kondisi pasar yang dimaksud adalah ketersediaan produk, jasa yang diperlukan dalam penyelesaian proyek dan yang dimaksud dengan informasi komersil adalah database komersil yang memberika data tentang keahlian dan upah dari sumber daya, serta biaya standard untuk material dan peralatan. 6. Kebijakan Organisasi Kebijakan organisasi yang berpengaruh terhadap estimasi biaya adalah kebijakan perusahaan dalam estimasi biaya itu sendiri, informasi historikal serta pelajaran maupun pengalaman dari proyek sebelumnya. Dibawah ini juga digambarkan proses penyusunan anggaran biaya sebelum tahap pelaksanaan : 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Gambar 5.3 Proses Penyusunan Anggaran Biaya Adanya input dari Database Management System dalam penyusunan estimasi akan sangat membantu terutama untuk proyek dengan skala besar dan sangat kompleks. Dalam database ini mencakup seluruh aspek yang dibutuhkan berdasarkan parameter dari proyek-proyek sebelumnya maupun data baru baik itu mengenai harga, lokasi, tenaga kerja dan lain sebagainya. Seringkali diperlukan revisi harga sehubungan dengan budget yang disediakan oleh owner. Oleh karena itu diperlukan revisi kembali harga satuan dan mengoreksi quantity pekerjaan. Faktor-faktor yang perlu dipertimbangkan pada saat mengubah harga satuan yaitu : 1. Melakukan construction economy yaitu upaya yang dilakukan dalam proses pra konstruksi maupun masa konstruksi dengan tujuan menekan biaya konstruksi termasuk juga untuk menekan pembengkakan biaya. 2. Mengubah construction method 3. Mengubah durasi proyek (bila memungkinkan) 4. Mengganti pemasok sumber daya yang digunakan 5. Mengubah kebijakan keuangan (pembiayaan) 2015 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id kemungkinan terjadinya Referensi: 1. Project Management Institute, (2008). A Guide to the Project Management Body of Knowledge, 4th Edition, hal. 165. 2. Perrot, Melvin W., (2004). The Cost Estimator’s Dilemma, AACE International Transactions, hal. 1. 3. Dysert, Larry R. (2006). Is “Estimate Accuracy” an Oxymoron?, Journal AACE International Transactions, hal. 1. 4. Project Management Institute, (2008). A Guide to the Project Management Body of Knowledge, 4th Edition, hal. 168. 5. Asiyanto MBA, IPM, (2005). Construction Project Cost Managament, (Pradnya Paramita). 6. Jin Han, Kyeong, Park, Moonseo, Lee, Hyun-Soo, Ji, Sae-Hyun, (2008). Cost Estimation Methodology Using Database Layer in Construction Projects, The 25th International Symposium on Automation and Robotics in Construction. 2015 11 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Manajemen Resiko Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 06 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Pada bab ini menjelaskan tentang bagaimana mengelola sebuah resiko di dalam proyek perangkat lunak Mahasiswa memiliki kemampuan untuk menganalisis dan mengelola sebuah resiko di dalam proyek perangkat lunak Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Manajemen Resiko 1. Pendahuluan Manajemen resiko adalah proses pengukuran atau penilaian resiko serta pengembangan strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu. Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta tuntutan hukum). Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian. Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan resiko tersebut. Mengapa manajemen resiko itu penting? Sikap orang ketika menghadapi resiko berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa resiko itu penting untuk ditangani dengan baik. Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun tidak sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis pengembangan biasanya merupakan penyebabnya. Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikannya selama pengembangan tersebut dan idealnya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis. 2015 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi resiko dan alokasi staf dan sumber daya lainnya erat kaitannya. Resiko dalam perangkat lunak memiliki dua karakteristik: • Uncertainty : tidak ada resiko yang 100% pasti muncul. • Loss : resiko berimbas pada kehilangan. Dan resiko memiliki kategori: 1) Resiko Proyek Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip dan biaya menjadi bertambah. Resiko proyek mengidenifikasi : - Biaya - Sumber daya - Jadwal - Pelanggan - Personil (staffing & organisasi) - Masalah persyaratan 2) Resiko Teknikal Resiko teknis mengancam kualitas & ketepatan waktu PL yang akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin. Resiko teknis mengidentifikasi : - Desain potensial - Ambiquitas - Implementasi - Spesifikasi - Interfacing - Ketidakpastian teknik - Verivikasi - Keusangan teknik - Masalah pemeliharaan - Teknologi yang leading edge 3) Resiko Bisnis Resiko bisnis mengancam viabilitas PL yang akan dibangun. Resiko bisnis membahayakan proyek atau produk. 5 resiko bisnis utama : a) Pembangunan produk atau sistem yang baik sebenarnya tidak pernah diinginkan oleh setiap orang (resiko pasar) b) Pembangunan sebuah produk yangg tidak sesuai keseluruhan strategi bisnis bagi perusahaan (resiko strategi) 2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id dengan c) Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya. d) Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (resiko manajemen) e) Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (resiko biaya). 4) Resiko yang sudah diketahui adalah resiko yang dapat diungkap setelah dilakukan evaluasi secara hatihati terhadap rencana proyek, bisnis, dan lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya. seperti : - Tanggal penyampaian yang tidak realitas - Kurangnya persyaratan yang terdokumentasi - kurangnya ruang lingkup PL - Lingkungan pengembangan yang buruk 5) Resiko yang dapat diramalkan Merupakan diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya : - Pergantian staf - Komunikasi yang buruk dengan para pelanggan - Mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung dilayani 6) Resiko yang tidak diharapkan Resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya. Strategi reaktif memonitor proyek terhadap kemungkinan resiko. Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang sebenarnya / penting. Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Masalah-masalah Proses 1. Apakah manajemen senior anda mendukung suatu pernyataan kebijaksanaan yang menekankan pentingnya suatu proses standar untuk pengembangan proses ? 2. Sudahkah organisasi anda mengembangkan suatu diskripsi tertulis mengenai proses PL yang akan digunakan pada proyek ini ? 3. Apakah anggota-anggota staf “ditugasi” ke proses PL pada saat PL didokumentasi & bersedia menggunakannya ? 4. Apakah proses PL digunakan untuk proyek lain ? 5. Sudahkah organisasi anda mengembangkan atau mendapatkan serangkaian serangkaian kursus pelatihan RPL bagi para manajer dan staf teknik ? 6. Apakah standar RPL yang diterbitkan disediakan untuk setiap pengembang PL & manajer PL ? 7. Sudahkah dokumen outline & contoh-contoh dikembangkan untuk semua yang ditentukan sebagai bagian yang dapat disampaikan sebagai bagian dari proses PL ? 8. Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain, dan kode dilakukan secara reguler ? 9. Apakah kajian teknis formal terhadap prosedur pengujian & test case dilakukan secara reguler ? 10. Apakah hasil dari masing-masing kajian teknis formal didokumentasikan, termasuk kesalahan yang ditemukan & sumber daya yang digunakan ? 11. Apakah mekanisme untuk memastikan bahwa kerja yang dilakukan pada suatu proyek sesuai dengan standar RPL ? 12. Apakah manajemen konfigurasi digunakan untuk memelihara konsistensi diantara system/persyaratan PL, desain, kode, dan test case ? 13. Apakah digunakan suatu mekanisme untuk mengontrol perubahan ke persyaratan pelanggan yang mempengaruhi PL ? 14. Adakah pernyataan mengenai kerja, spesifikasi persyaratan pelanggan, dan rencana pengembangan PL yang didokumentasikan untuk masing-masing subkontrak ? 2015 5 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 4 3. Masalah-masalah Teknis 1. Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi diantara pelanggan & pengembang ? 2. Apakah metode spesifik digunakan untuk analisis PL ? 3. Apakah anda melihat suatu metode spesifik untuk data & desain arsitektur ? 4. Apakah lebih dari 90% dari kode anda ditulis dengan bahasa orde yang lebih tinggi ? 5. Apakah konvensi spesifik untuk dokumentasi kode didefinisikan & digunakan ? 6. Apakah anda menggunakan metode spesifik untuk desain test case? 7. Apakah digunakan peranti PL untuk mendukung perencanaan & aktivitas penelusuran ? 8. Apakah digunakan peranti PL manajemen konfigurasi untuk mengontrol & menelusuri aktivitas perubahan diseluruh proses PL ? 9. Apakah digunakan peranti PL untuk mendukung analisis PL dan desain proses ? 10. Apakah digunakan peranti untuk menciptakan prototipe PL ? 11. Apakah digunakan peranti PL untuk mendukung proses pengujian ? 12. Apakah peranti PL digunakan u ntukmendukung produksi dan manajemen dokumentasi ? 13. Apakah metriks kualitas dikumpulkan bagi semua proyek PL ? 14. Apakah metrik produktivitas dikumpulkan bagi semua proyek PL? Bila mayoritas jawaban terhadap pertanyaan tersebut adalah `tidak`, maka proses PL lemah dan berisiko tinggi. Resiko berhubungan dengan kompleksitas sistem yang akan dibangun dan `kebaruan` teknologi yang dikemas oleh sistem. Checklist item resiko yang berhubungan dengan teknologi yang akan dibangun : • Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda? • Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output? • Apakah PL berinterface dengan perangkat keras baru atau belum terbukti? 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Apakah PL yang akan dibangun ber-interace dengan produk PL yang dipasok oleh vendor yang belum terbukti? • Apakah PL yang akan dibangun ber-interface dengan suatu sistem database yang fungsi kinerjanya belum dibuktikan di dalam area aplikasi ini? • Apakan diperlukan interface pemakai khusus oleh persyaratan produk? • Apakah persyaratan untuk produk memerlukan kreasi komponen program yang tidak sama dengan yang dikembangkan terakhir oleh organisasi anda? • Apakah persyaratan memerlukan pemakaian analisis, desain atau metode pengujian baru? • Apakah persyaratan memerlukan metode pengembangan PL tidak konvensional, seperti metode formal, pendekatan Al-based dan jaringan syaraf buatan? • Apakah persyaratan meletakkan batasan kinerja yang eksesif pada produk tersebut? • Apakah pelanggan tidak yakin pada fungsionalitas yang diminta dapat ’dilakukan’? Bila jawaban dari pertanyaan-pertanyaan di atas adalah ’ya’, penyelidikan lebih lanjut harus dilakukan untuk memperkirakan risiko potensial. 4. Analisa Resiko Lingkungan Pengembangan Resiko yang berhubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk. Lingkungan proses PL mendukung tim proyek, proses dan produk. Lingkungan yang salah dapat menjadi sumber resiko yang penting. Checklist item resiko yang berhubungan dengan lingkungan pengembangan : 2015 7 • Apakah peranti manajemen proyek dapat diperoleh? • Apakah peranti untuk analisis dan desain dapat diperoleh? • Apakah peranti analisis dan desain penyampaian metode sesuai Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id bagi produk yang akan dibangun? • Apakah kompiler atau generasi kode dapat diperoleh dan sesuai untuk produk yang akan dibangun? • Apakah peranti pengujian dapat diperoleh dan sesuai untuk produk yang akan dibangun? • Apakah peranti manajemen konfigurasi PL dapat diperoleh? • Apakah lingkungan menggunakan suatu database atau tempat penyimpanan? • Apakah semua peranti PL dapat diintegrasikan satu dengan lainnya? • Sudahkah anggota tim proyek menerima pelatihan dengan masing- masing peranti? • Apakah ada pakar lokal untuk menjawab pertanyaan-pertanyaan mengenai peranti tersebut? • Apakah bantuan dan dokumentasi on-line bagi peranti memadai? Bila mayoritas jawaban terhadap pertanyaan tersebut adalah ’tidak’, berarti lingkungan pengembangan PL lemah dan berisiko tinggi 5. Komponen Resiko dan Driver Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu menghendaki agar manajer proyek mengidentifikasi risiko driver yang mempengaruhi komponen risiko PL – kinerja, biaya, dukungan dan jadwal. Komponen risiko didefinisikan dengan cara sbb : • Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya. • Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga • Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan. • Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Dua cara melakukan proyeksi risiko: • Probabilitas di mana risiko adalah nyata • Konsekuensi masalah yang berhubungan dengan risiko Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko : 1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan 2. Menggambar konsekuensi risiko 3. Memperkirakan pengaruh risiko pada proyek dan produk 4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman 6. Pengurangan dan Monitoring Resiko Perangkat Lunak Aktifitas analisis risiko mempunyai titik tunggal yang memiliki tujuan untuk membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko. Strategi yang efektif harus: 1. Menghindari risiko 2. Memonitoring risiko 3. Manajemen risiko dan perencanaan kemungkinan Langkah-langkah untuk mengurangi turnover staf adalah 1. Temui staf yang ada, untuk menentukan penyebab keluar 2. Bertindaklah untuk mengurangi penyebab-penyebab yang ada di bawah kontrol manajemen sebelum proyek dimulai 3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknikteknik untuk memastikan kontiunitas pada saat orang keluar 4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas pengembangan dapat disebarluaskan 5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa dokumen dikembangkan tepat waktu 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih dari satu orang yang terbiasa dengan pekerjaan itu 7. Tentukan backup anggota staf untuk setiap teknologi kritis Aktifitas pemonitoran dimulai, manajer proyek memonitor factor-faktor yang dapat memberikan suatu indikasi apakah risiko mungkin sedang menjadi lebih atau kurang. Untuk kasus turnover tinggi, factor-faktor yang dapat dimonitor : 1. Sikap umum anggota tim berdasarkan tekanan proyek 2. Tingkat di mana tim disatu – padukan 3. Hubungan interpersonal di antara anggota tim 4. Masalah pontensial dengan kompensasi dan manfaat 5. Keberadaan pekerjakan di dalam perusahaan dan di luarnya Langkah pengurangan resiko diperlukan bagi definisi standar dokuntasi dan mekanisme untuk memastikan bahwa dokumen dikembangkan secara tepat waktu, guna memastikan kontinuitas.Manajemen risiko dan perencanaan kemungkinan mengasumsikan bahwa usaha pengurangan telah gagal dan risiko menjadi suatu kenyataan. Contoh, diandaikan proyek sedang berlangsung dengan baik dan sejumlah orang mengatakan akan keluar dari proyek tersebut maka strategi pengurangan telah dilakukan dengan backup , informasi, dokumentasi dan pengetahuan telah disebar ke semua tim. Manajer proyek akan menyesuaikan lagi jadwal dengan fungsi-fungsi yang telah disusun sepenuhnya dan pendatang baru akan ditambah untuk mengejar dan membagun serta akan ditransfer pengetahuan oleh orang akan keluar. Referensi: 1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997. 2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004. 3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall, 2006. 2015 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Inisiasi Proyek dan Ruang Lingkup Manajemen Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 07 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Modul ini berisi materi tentang penaksiran proyek, elemenelemen dasar proyek, aspek awal, dan proposal awal dan pendekatan dalam penaksiran Pada akhir pertemuan ini, diharapkan mahasiswa memahami elemen-elemen dasar proyek, cara melakukan penaksiran proyek, dan membuat proposal Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Perencanaan, Penaksiran, dan Pengaturan Sumber Daya Proyek 1. Penaksiran Proyek Proses manajemen proyek perangkat lunak dimulai dengan serangkaian aktivitas yang secara kolektif disebut perencanaan proyek. Aktivitas awal dari perencanaan adalah estimasi. Kapanpun estimasi dilakukan, seorang perencana mulai melihat pada masa depan dengan suatu tingkat ketidak pastian teretentu, yang akan menjadi bahan pembahasan untuk menaksir proyek. Hasil penaksiran akan menjadi dasar bagi semua aktiviotas perencanaan proyek lebih jauh. Perencanaan proyek merupakan peta jalan bagi suksesnya rekayasa perangkat lunak. Tanpa penaksiran yang teliti, perencanaan proyek akan menghasilkan berbagai resiko dimasa depan, misalnya kerugian, kegagalan memenuhi limit waktu yang sudah disepakati, dan kesulitan-kesulitan lain yang muncul dalam pengerjaan teknis proyek. Penaksiran berbagai hal untuk usaha pengembangan suatu perangkat lunak membutuhkan: • Pengalaman • Akses informasi historis • Keberanian mengkuantifisir data-data Kualitatif Penaksiran yang dilakukan meliputi: • Penaksiran kebutuhan sumber daya manusia • Penaksiran kebutuhan biaya • Penaksiran kebutuhan waktu dan penjadwalan Penaksiran membawa resiko ketidak pastian. Ketidak pastian itu sendiri sangat dipengaruhi oleh: 2015 • Kompleksitas proyek • Ukuran proyek • Ketidakpastian structural 2 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id A. Kompleksitas Proyek Kompleksitas proyek berpengaruh kuat terhadap ketidak pastian dalam perencanaan. Tetap kompleksitas pengukran yang relatif yang dipengaruhi oleh kebiasaan dengan usaha yang sudah dilakukan pada masa sebelumnya. Aplikasi real-time dapat dirasakan sebagai sangat kompleks bagi sebuah kelompok perangkat lunak yang hanya mengembangkan aplikasiaplikasi batch saja. Tetapi aplikasi yang sama dapat dirasakan sebagai run-of-mill bagi sebuah kelompok perangkat lunak yang telah terlibat jauh dalam proses kontrol kecepatan tinggi. Sejumlah pengukuran kompleksitas perangkat lunak kuantitatif sudah diusulkan. Pengukuran semacam itu diaplikasikan pada tingkat kode dan desain sehingga sulit digunakan selama perencanaan perangkat lunak (sebelum kode dan desain ada). Tetapi perkiraan kompleksitas yang lain yang lebih subyektif dibanding yang lain (seperti faktor penyesuaian kompleksitas function point yang digambarkan) dapat dibuat pada awal proses perencanaan. B. Ukuran Proyek Ukuran proyek merupakan faktor penting lain yang dapat mempengaruhi akurasi estimasi. Bila ukuran bertambah maka ketergantungan diantara berbagai elemen perangkat lunak akan meningkat dengan cepat. Dekomposisi masalah sebagai suatu pendekatan yang sangat penting dalam proses estimasi menjadi lebih sulit lagi karena elemen-elemen yang akan didekomposisi masih sangat berat. Seperti dinyatakan dalam hukum Murphy: “Apa yang dapat salah biarkanlah menjadi salah” – dan bila ada lebih banyak lagi yang dapat gagal, maka disitu akan terjadi lebih banyak kegagalan. C. Tingkat ketidakpastian Struktural Tingkat ketidakpastian struktural juga berpengaruh dalam risiko estimasi. Santayana pernah mengatakan, “Mereka yang tidak dapat mengingat masa lalu terkutuk untuk mengulanginya lagi. “Dengan melihat kembali, kita dapat mengingat lagi hal-hal yang terjadi dan dapat menghindari tempat-tempat dimana masalah muncul. Bila metrik perangkat lunak yang komprehensif dapat diperoleh pada proyek yang telah lalu, maka estimasi dapat dilakukan dengan kepastian yang lebih tinggi; jadwal dapat dibuat untuk menghindari kesulitan2015 3 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id kesulitan yang terjadi dimasa lalu, dan risiko keseluruhan dapat dikurangi. Resiko diukur melalui tingkat ketidakpastian pada estimasi kuantitatif yang dibuat untuk sumber daya, biaya, dan jadwal. Bila ruang lingkup proyek tidak dipahami dengan baik atau syarat proyek merupakan subjek terjadinya perubahan, maka risiko dan ketidakpastian menjadi sangat tinggi. Perencana perangkat lunak harus melengkapi fungsi, kinerja, dan definisi interface (yang diisikan ke dalam spesifikasi sistem). Perencana, dan lebih penting lagi pelanggan, harus mengetahui bahwa variabilitas pada kebutuhan perangkat lunak berarti ketidakstabilan biaya dan jadwal. Sebagai observasi akhir mengenai estimasi, kita perlu mempertimbangkan apa yang pernah dikatakan oleh Aristoteles :Ini merupakan tanda dari pikiran yang diperintah untuk menjadi puas dengan tingkat ketelitian yang diijinkan oleh sifat dari sebuah subjek, dan tidak untuk mencari ketepatan bila hanya perkiraan kebenaran saja yang dimungkinkan. Manajer proyek tidak boleh obsesif terhadap penaksiran. Pendekatanpendekatan rekayasa perangkat evolusioner) memakai pandangan lunak modern pengembangan (seperti model yang interaktif. proses Pada pendekatan semacam ini dimungkinkan untuk melihat lagi penaksiran (bila lebih banyak lagi informasi diketahui) dan merevisinya bila pelanggan mengubah kebutuhannya. 2. Elemen Dasar dalam Penaksiran Proyek Secara umum penakasiran proyek berimplikasi pada biaya. Sebagaimana sudah diketahui bersama, proyek pengembangan perangkat lunak adalah sebuah jasa. Bahan bakunya adalah waktu kerja setiap anggota timnya. Sehingga muara dalam penaksiran proyek adalah membuat taksiran berapa lama waktu yang dibutuhkan tim untuk menyelesaikan proyek tersebut. Dengan hitungan-hitungan sederhana, estimasi waktu menjadi dasar dalam menghitung biaya proyek.Tentunya waktu keterlibatan setiap anggota tim tidaklah sama. Akan sangat memboroskan kalau seorang anggota tim tetap dialokasikan waktunya pada suatu tugas proyek, padahal dia belum dapat atau tidak lagi mengerjakan apapun. Sehingga secara objektif harga sebuah proyek perangkat lunak 2015 4 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id merupakan akumulasi dari biaya yang harus dibayarkan kepada setiap anggota tim berdasarkan keterlibatannya. Langkah-langkah Pendetilan Untuk menghasilkan harga yang lebih teliti, langkah-langkah yang dapat dilakukan adalah sebagai berikut : 1. Dekomposisi masalah 2. Definisikan secara detil task-task yang mesti ada pada setiap sub masalah 3. Definisikan anggota tim yang akan ditugaskan pada setiap task 4. Perkirakan waktu yang dibutuhkan oleh setiap anggota tim tersebut untuk menyelesaikan suatu task 5. Tentukan tarif setiap anggota tim dalam pengerjaan proyek 6. Buat taksiran biaya lain-lain yang muncul, misalnya biaya akomodasi, biaya atk, biaya peralatan, dan pembelian tools. Kematangan setiap individu dalam tim akan mempengaruhi kebutuhan waktu penyelesaian sebuah task yang ditugaskan kepadanya. Sehingga tim dengan kematangan individu anggotanya yang rendah berdampak pada panjang kebutuhan waktu. Disisi lain kematangan seorang individu juga mempengaruhi tarif yang ditetapkan baginya. 3. Aspek Teknis Pengkajian aspek teknis dilakukan sejajar dengan aspek-aspek lain setelah penelitian pemasaran menunjukkan adanya faedah untuk melanjutkan studi kelayakan. Maksud dan tujuan pengkajian aspek teknis adalah sebagai berikut: • Pada tahap awal bertujuan untuk merumuskan gagasan yang timbul ke dalam batasan yang konkret dari segi teknis. • Hasil pengkajian aspek teknis dipakai sebagai masukan pengkajian aspekaspek lain. • Akhirnya lingkungan aspek teknis sampai kepada kegiatan desain engineering terinci, menghasilkan ce tak biru (blue print) proyek yang 2015 2013 Manajemen Proyek Perangkat Lunak Tim Dosen 5 5 Manajemen Proyek Perangkat Lunak Ida Nurhaida, ST., MT. Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id akan dibangun. Pengkajian aspek teknis itu sendiri mencakup beberapa hal antara lain sebagai berikut: • Menentukan letak geografis • Mencari dan memilih teknologi proses produksi • Menentukan kapasitas produksi • Denah atau tatak letak industry • Bangunan instalasi Keputusan yang diambil dari pengkajian yang dilakukan diatas merupakan keputusan penting. Setidaknya ada 3 alasan mengapa keputusan tersebut penting bati kelanjutan proyek yaitu: • Merupakan komitmen jangka panjang, yang bila tidak tepat sulit diperbaiki • Berpengaruh besar terhadap biaya pembangunan proyek • Mempunyai dampak permanen terhadap biaya operasi/produksi 4. Proposal Awal dan Pendekatan dalam Penawaran Proposal awal proyek merupakan upaya awal tim proyek untuk menggolkan sebuah proyek. Proposal awal mestinya berpijak pada suatu memo kesepahaman antara pemilik proyek yang meliputi: • Pendefinisian masalah • Rekomendasi penyelesaian • Gambaran umum sistem perangkat lunak • Keuntungan-keuntungan yang didapatkan dengan implementasi sistem perangkat lunak 1. Perencanaan Proyek Tujuan perencanaan proyek perangkat lunak adalah untuk menyediakan sebuah kerangka kerja yang memungkin kan seorang pimpinan proyek membuat estimasi yang dapat dipertanggung jawabkan mengenai sumber daya, biaya dan jadwal. Batasan dalam estimasi adalah: 2015 6 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Waktu terbatas • Sumber daya terbatas Estimasi dalam proyek perangkat lunak memiliki ketidak pastian yang cukup tinggi. Sehinga selagi proyek berjalan, estimasi mesti selalu disesuaikan dan diperbaharui. Lebih khas lagi, estimasi biasanya membentuk suatu skenario kasus terburuk dan kasus terbaik. Proses perencanaan dapat dicapai melalui suatu proses penemuan informasi yang menunjuk ke estimasi yang dapat dipertanggung jawabkan. Tugas-tugas yang mesti ditangani oleh seorang perencana proyek sistem perangkat lunak adalah: • Mendefinisikan ruang lingkup system • Mengidentifikasi kebutuhan-kebutuhan dalam pelaksanaan proyek • Mengestimasi sumber daya yang diperlukan 2. Ruang Lingkup Ruang lingkup merupakan pendeskripsi teknis proyek dalam suatu statement yang dapat dimengerti pada tingkat manajemen dan teknis. Ruang lingkup perangkat lunak menggambarkan: • Fungsi • Kinerja, • Batasan • Interface • Keandalan Fungsi-fungsi yang digambarkan dalam statement ruang lingkup dievaluasi, untuk mendapatkan suatu model yang detil maka fungsi-fungsi proses tersebut akan didekomposisi menjadi sub-sub fungsi yang pada akhirnya akan memudahkan dalam estimasi jadwal dan biaya yang diorientasikan secara fungsional. Contoh : Sebuah sistem perangkat lunak admisnitrasi akademik, akan menghasilkan fungsi-fungsi sebagai berikut: 2015 7 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Preparasi data mahasiswa • Preparasi data kurikulum • Pengisian KRS • Menentukan kelas • Mengoptimalkan jadwal • Mengisi nilai Pertimbangan kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Untuk contoh sistem informasi akademik diatas, kinerja akan ditentukan oleh pengaturan jadwal suatu pemrosesan. Misalnya, perubahan kurikulum harus sudah dilakukan sebelum pengisian KRS. Ketika ingin diwujudkan suatu sistem yang online dan dapat diakses oleh seluruh mahasiswa, masalah kemanan data menjadi ukuran kinerja sistem. Perangkat lunak yang dikembangkan akan dibatasi oleh perangkat keras yang diaksesnya. Disamping informasi teknis yang didefinisikan dalam dokumen kebutuhan pelanggan (customer request), diperlukan informasi-informasi lain yang untuk mendefiniskan ruang lingkup antar lain: 1. Deskripsi pelanggan (yang meminta) 2. Pemakai 3. Karakteristik output yang baik menurut pemakai 4. Solusi yang akan diambil 3. Kebutuhan Yang dimaksudkan sebagai kebutuhan dalam hal ini adalah segala sesuatu yang diperlukan untuk mendukung proyek perangkat lunak. Kebutuhan dapat dikelompokkan atas: 1. Literatur 2. Pelatihan khusus sumber daya 3. Fasilitas lain-lain Dalam perencanaan proyek perangkat lunak, harus teridentifikasi dari awal kebutuhankebutuhan yang diperlukan sehingga proyek dapat berjalan sesuai dengan yang direncanakan. 2015 8 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 4. Sumber Daya Tugas selanjutnya seorang perencana proyek perangkat lunak adalah mengestimasi kebutuhan sumber daya untuk pengembangan perangkat lunak, yaitu: 1. Perangkat keras 2. Perangkat lunak (utilitas) 3. Lingkungan 4. Manusia 5. Estimasi Proyek Estimasi proyek perangkat lunak meliputi: 1. Estimasi biaya 2. Estimasi waktu Berikut adalah model sederhana penaksiran proyek: No Dekomposisi 1. Sub Masalah 1 1.1. Task 1 1.1.1 Sub task 1 Kualifikasi Konsultan Rate Man Days Scheduling Biaya Waktu Nyata 1.1.1.1. Sub sub task 1 Proyek Manajer $ 100 5 $ 500 1.1.1.2. Sub sub task 2 Sistem Analis 1 $ 80 12 $ 960 1.1.1.3. Sub sub task 3 Programmer 1 $ 60 6 $ 360 Sub sub task 1 Sistem Analis 1 $ 80 20 $ 1.600 Sub sub task 2 Sistem Analis 2 $ 80 20 $ 1.600 1.1.2. Sub task 2 dst Total 2015 9 Manajemen Proyek Perangkat Lunak Tim Dosen $ xxxxxx Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pada umumnya perusahan memiliki batasan jumlah dana yang akan diinvestasikan pada suatu proyek. Hal ini berarti tidak semua proyek yang diajukan akan dijalankan. Beberapa proyek memiliki prioritas yang lebih tinggi dibandingkan dengan yang lain. Sebagai contoh, proyek yang terkait dengan pemerintahan akan memiliki prioritas yang lebih tinggi dibadingkan dengan proyek-proyek yang lain. Pemilihan proyek dapat dilakukan dengan dua cara sebagai berikut: • Constrained optimization • Benefit Comparison Methods Umumnya organisasi menggunakan pendekatan ini. Benefit comparison methods menggunakan accessible formulas, model perbandingan, and sistem untuk menentukan proyek yang akan dikerjakan. Referensi: 1. Software Engineering, Roger S. Pressman,McGrawHill 1997. 2. Management Information System, Raymond McLeod, Prentice Hall 2000. 3. Software Project Management for Dummies, Teresa Luckey, Joseph Phillips, Wiley Publishing Inc., 2006. 2015 10 Manajemen Proyek Perangkat Lunak Tim Dosen Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Critical Success Factor Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 09 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Modul ini berisi materi tentang bagaimana penerapan critical success factor pada sebuah manajemen proyek perangkat lunak Pada akhir pertemuan ini, diharapkan mahasiswa memahami penerapan critical success factor pada sebuah manajemen proyek perangkat lunak Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Critical Success Factor 1. Pengertian Critical Success Factor Critical Success Factor (CSF) adalah istilah untuk suatu elemen yang diperlukan untuk suatu organisasi atau proyek untuk mencapai misinya. Ini adalah faktor kritis atau aktivitas yang diperlukan untuk menjamin keberhasilan sebuah perusahaan atau organisasi. Critical Success factor menurut Maciariello & Kirby (1991:78) [14] adalah sebagai berikut:. " The Importance of Identifying those relatively few variables that are crucial to the attainment of strategy, goals, objectives then is ultimately derived from limited information processing ability of the manager. We call these crucial variables Critical variable or Critical Success factor". Selain ini Critical Success Factors disimpulkan juga sebagai: "Critical Success Factors are thosevariables that are at least partially out of the control of management to those values the strategy, goals,and objectives organization are most sensitif". Konsep "faktor keberhasilan" dikembangkan oleh D. Ronald Daniel dari McKinsey & Company pada tahun 1961 Proses ini disempurnakan oleh John F. Rockart pada tahun 1981. Pada 1995, James A. Johnson dan Michael Friesen diterapkan untuk pengaturan berbagai sektor, termasuk Engineering. 2. Identifikasi Critical Success Factor Dalam mengidentifikasi Critical Success Factors, ada 2 tipe dari Critical Successs factor,yaitu: 1. Faktor interal, dimana faktor-faktor yang ada tersebut berada dalam kemampuan manajemen dan usaha seperti harga, 'mantas, dan biaya 2. Faktor eksternal, dimana faktor-faktor tersebut berada diluar kemampuan dari perusahaan untuk mengontrolnya. Seperti peraturan pemerintah dan tindakan para pesaing di dalam menetukan harga, perilaku konsumen, kinerja pengawas, dan lain-lain. 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Kriteria Critical Success Factor Sukses adalah suatu kata yang umum dan luas sehingga sulit untuk mendefinisikannya dan mendapatkan kesepakatan ketika ditanyakan kepada individu yang berbeda. Pernyataan tersebut diutarakan karena usaha mendefinisikan sukses adalah seperti mendapatkan konsensus dan sekelompok orang akan definisi "seni yang indah'. Begitu juga pada proyek, 'criteria kesuksesan proyek tidaklah sama setiap proyek, karena target masing-masing proyek berbeda-beda. Pendefinisian kesuksesan Proyek secara umum adalah penyelesaian proyek tanpa melewati batasan waktu, biaya, dan kinerja. Akan tetapi saat ini,definsi kesuksesan proyek sudah berubah menjadi penyelesaian pekerjaan: • Dalam periode waktu yang sudah dialokasikan • Dalam biaya yang sudah direncanakan • Pada tingkat kinerja dan spesifikasi yang memadai • Diterima oleh customer / user • Bila nama pelanggan bisa digunakan sebagai referensi • Dengan perubahan scope yang minimum dan disepakati • Tanpa mengganggu aliran pekerjaan utama dari organisasi • Tanpa mengganggu budaya perusahaan Pandangan akan kesuksesan memang cenderung mengalami perubahan hingga saat ini dan juga sudah berkembang dan tahun ke tahun dari definisi sederhana yang dibatasi pada fase implementasi dan project life cycle menjadi definisi yang merefleksikan apresiasi kesuksesan dan keseluruhan project and product life cycle. Penelitian lain yang dilakukan oleh Atkinson (1999) [20]. Menyatakan penilaian sukses dibagi menjadi 2 kategori yaitu: • Pengukuran kesuksesan selama implementasi proyek ("doing it right") seperti pada aspek biaya, waktu, dan mutu. • Kriteria sukses mengikuti pelaksanaan proyek ("getting it right"), dimana termasuk pengaruh pada outcome bisnis pelanggan yang dihasilkan dari proyek, dan bagaimana proyek itu mempersiapkan organisasi untuk masa depan. 2015 3 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Sejalan dengan pendapat Atkinson diatas, penelitian lain oleh Shenhar et al. (2001) [21], mengidentifikasi 4 dimensi kesuksesan yaitu: • Efisiensi proyek • Pengaruh pada pelanggan • Kesuksesan bisnis secara langsung dan organisasional • Mempersiapkan masa depan Sedangkan Shatz (2006) [22] memaparkan tools yang dinamakan "slider" dalam determinasi kesuksesan proyek, yaitu: • Slider 1 : Level kepuasan Stakeholder • Slider 2 : Sesuai dengan tujuan dan persyaratan • Slider 3 : Sesuai Budget • Slider 4 : Sesuai Deadline • Slider 5 : Pesyaratan Added – Value • Slider 6 : Persyaratan Kualitas • Slider 7 : Kepuasan Tim Songer dan Molenaar (1997) [23], menjabarkan 'criteria sukses dan suatu proyek beserta definisinya seperti tercantum dalam tabel dibawah ini Tabel 9.1 Kriteria Sukses dan Definisinya Kriteria Sukses Sesuai Budget L er i ii Definisi Proyek disesuaikan pada atau didalam biaya yang di-kontrak-an Sesuai Jadwal Proyek diselesaikan pada atau sebelum jadwal yang di-kontrak-an Sesuai Spesifikasi sesuai dengan keinginan user Proyek yang diselesaikan sesuai atau melebihi semua spesifikasi teknis yang disediakan Proyek yang diselesaikan sesuai atau melebihi tujuan fungsional yang diinginkan tingkat kemampuan staff pekerja yang berkualitas tinggi Proyek yang diselesaikan sesuai atau melebihi standar tingkat kemampuan pekerja yang dapat diterima pada semua area 2015 4 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id meminimalisasi ketidakpuasan konstruksi proses konstruksi terjadi perselisihan dengan staff manajemen proyek owner . Pada penelitian Thomas, Tucker, dan Kelly (1998) [24], mengutip dari penelitian oleh Ashley et al. (1987) [25], menyatakan bahwa kesuksesan diukur oleh biaya, jadwal, kualitas, keamanan, dan kepuasan partsipan. Akan tetapi walapun mudah untuk diukur, tetapi pada aspek kepuasan dan kualitas dinilai cuk up subjektif. Kemudian pada penelitian lebih lanjut oleh Thamhain (1992) [26], menyatakan bahwa lebih dari 60% manajer Engineering yang disurvey setuju bahwa 3 karakteristik yang paling banyak digunakan dalam penilaian kesuksesan proyek mencakup: • Kesuksesan proyek secara teknis • Kinerja tepat waktu • Kinerja on-budget Westerveld (2002) [27], dalam penelitiannya mencoba menghubungkan 'criteria kesuksesan proyek sebagai result area dengan Critical Successs Factor (CSF) sebagai organisational area, sehingga memperlihatkan kedua area tersebut merupakan 2 hal yang saling berkaitan satu dengan lainnya. Critical Successs Factor (CSF) merupakan suatu istilah dalam dunia bisnis untuk suatu elemen yang penting bagi suatu perusahaan atau proyek untuk mencapai misi tujuannya. Faktor-faktor tersebut diperlukan untuk memastikan kesuksesan bisnis tersebut. Jadi CSF merupakan suatu hal yang vital. Berikut ini beberapa definisi dari CSF yang pernah diutarakan oleh peneliti terdahulu: • Faktor-faktor yang terbatas, yang bila dipenuhi secara baik, akan menjamin suksesnya kinerja persaingan (competitive performance) dari suatu organisasi. Faktor-faktor tersebut adalah sedikit area dimana segala sesuatunya hams berjalan dengan benar bagi berjalannya bisnis. Jika usaha pada area ini tidak cukup, maka hasil organisasi untuk periode tersebut akan lebih sedikit dari yang diharapkan (Rockart, 1979) [28]. Rockart juga menyimpulkan bahwa CSF adalah area aktivitas yang hams menerima perhatian khusus dan konstan dari management. • Beberapa hal/ faktor yang hams berjalan baik untuk menjamin sukses bagi manajer atau organisasi dan karenanya, faktor-faktor tersebut menjelaskan bidang-bidang dalam manajerial atau perusahaan yang hams diberi perhatian 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id khusus dan terns menerus untuk mendapatkan hasil yang berkualitas tinggi. • Kejadian (events) atau keadaan (circumstances) yang membutuhkan perhatian khusus dan manajemen karena pengaruhnya yang penting terhadap perusahaan/organisasi. Dapat bersifat internal atau eksternal dan pengaruhnya dapat positif maupun negatif (Ferguson and Dickinson, 1982) [30] • Item yang hams dimiliki dan dibutuhkan oleh proyek untuk mencapai tujuan. Drickhammer (2006) [32] mengutarakan bahwa pengidentifikasian CSF merupakan salah satu proses perencanaan yang penting dalam pencapaian tujuan proyek dimana berada di dalam constraints waktu, biaya, dan kualitas (Wiley,2004) [33]. Kuen, Zallani dan Fernando ( 2009) [34] sebagaimana mengutip dari Mobey dan Parker (2002) [35], menyatakan bahwa dalam usaha peningkatan peluang keberhasilan suatu proyek, adalah penting bagi organisasi untuk memiliki pemahaman dan apa itu CSF, untuk menilai secara sistematis dan kuantitatif CSF tersebut mengantisipasi efek-efek yang mungkin terjadi,dan kemudian memilih metode dalam menghadapinya. Dengan demikian, melalui identifikasi CSF, keberhasilan proyek diharapkan dapat tercapai. Mereka juga membuat suatu ringkasan akan CSF yang telah diidentifikasikan oleh peneliti terdahulu. Ringkasan tersebut dituangkan dalam bentuk tabel seperti yang terlihat pada tabel dibawah ini. Tabel 9.2 Summary dari Literatur Review Akan CSF Success Factors from the Literature Pinto & Belassi CoolePimo Kerzner Slevin Wateridge Belout Clarke Daview Muller & 1996 1987 2005 1995 1998 1999 1989 2002 Tukel Corposite Understanding Common Understanding with stakeholders on Success criteria Executive Commitment X X X X X X X X X Organizational adaptability Communication X Project manager selection criteria project manager leadership / empowerment X X X X X X X X X X Environment 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T X X Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id X Success Factors from the Literature CoolePinto & Belassi Pimo Kerzner Slevin Wateridge Belout Clarke Daview Muller & 2005 1996 1987 1995 1998 1999 2002 Tukel 1989 Commitment to planning & control Project mission / common goal / direction X X X X X X X top management support X X client consultation / acceptance X monitor performance and feedback X personnel / teamwork X X X Technical task ability X X X Trouble shooting / risk management X X X X X X X X X X X X X X Project Ownership Urgency of Project X X X X X Duration and size of Project X X Remarks : X Success factor(s) that is determined by the researcher either on a conceptual or empirical basis Pada tabel 9.3, memperlihatkan perkembangan CSF untuk proyek yang telah diringkas oleh Tom, Austeng, Mengesha (2004) [36], dimana CSF berkembang dari pendekatan mekanistik pada determinasi proyek yang bergantung pada sistem teknis murni menjadi kombinasi antara sistem sosial dan teknis No 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 2015 7 Critical Success Factor Technical Performance Project manager eksperience Project manager competence Schedulling Control system and responsibilities Monitoring & feed back Continous involment in the project Clear Goals General management support organize and delegate authorithy Clear Goals Goal commitment of project team adequate project team capability Planning & control techniques Task-Social orientation absence of Project summary Top Management Support Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Source, year Ruben & Seeling, 1967 Ruben & Seeling, 1967 Sayles & Chandler, 1971 Sayles & Chandler, 1971 Sayles & Chandler, 1971 Sayles & Chandler, 1971 Sayles & Chandler, 1971 Martin, 1976 Martin, 1976 Martin, 1976 Baker, Murphy, and Fisher, 1983 Baker, Murphy, and Fisher, 1983 Baker, Murphy, and Fisher, 1983 Baker, Murphy, and Fisher, 1983 Baker, Murphy, and Fisher, 1983 Clealand King, 1983 Clealand King, 1983 Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id X 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 Financial Support facility support market intelligent schedule manpower and organisation acquisition information and communication channels Project Objectives Technical Innovation Uncertainty Politics Vommunity Involvement Schedule duration urgency Implementation problem Project Objectives Top Management support Project planning Communication with client Human relations Technical task Client Acceptence Project Control Communication and problem handling Top management support Client consultation Availability of resources Project manager performance The project manager and team members The organization Early and continual client consultation Technology Schedulling system Project team Clealand King, 1983 Clealand King, 1983 Clealand King, 1983 Clealand King, 1983 Clealand King, 1983 Clealand King, 1983 Clealand King, 1983 Morris and Hughes, 1987 Morris and Hughes, 1987 Morris and Hughes, 1987 Morris and Hughes, 1987 Morris and Hughes, 1987 Morris and Hughes, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Pinto and Slevin, 1987 Tuke & Rom, 1995 Tuke & Rom, 1995 Tuke & Rom, 1995 Tuke & Rom, 1995 Walid and Oya, 1996 Walid and Oya, 1996 Pinto and Kharbanda, 1995 Pinto and Kharbanda, 1995 Pinto and Kharbanda, 1995 Pinto and Kharbanda, 1995 50 Top management support and continual " what if " approach Pinto and Kharbanda, 1995 Berdasarkan pada perkembangan CSF pada tabel 2.3 tersebut, sebagaimana mengutip dari Belout (1998) [37], terlihat bahwa pada awalnya terdapat dominasi dari sistem teknis dan hanya sedikit indikasi dari pertimbangan akan sistem tingkah laku (behavioral system). Saat ini manajemen proyek telah 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id banyak berkembang dan pengembangan teoritis telah mengarah pada prinsipprinsip organisasi dan tingkah laku (behaviour). Naoum, Fong, dan Walker (2004) [38], dalam penelitiannya dalam mengidentifikasi CSF yang berkontribusi pada keberhasilan suatu manajemen proyek, menemukan bahwa terdapat 10 CSF, yaitu: 1. Pembentukan tujuan proyek dan 'criteria klien 2. Tingkat partisipasi tim proyek dalam decision making 3. Kejelasan scope dan definisi pekerjaan 4. Karakteristik manajer proyek 5. Organisasi klien 6. Kerjasama tim proyek 7. Teknik perencanaan dan programming 8. Proses seleksi dalam pembentukan tim 9. Kewenangan dan pengaruh manajer proyek 10. Estimasi biaya proyek Penelitian atas CSF memiliki manfaat yang sangat signifikan terutama dalam bidang konstruksi dan Manajemen Proyek, diantaranya adalah (Permono, 2010): 1. Untuk meminimalisir variasi yang banyak sepanjang implementasi proyek. 2. Untuk mengantisipasi efek-efek yang mungkin terjadi, kemudian memilih metode y ang dapat diterapkan untuk mengatasinya 3. Dapat memprediksi tindakan¬tindakan: kesuksesan menolak proyek proyek, yang yang disertai berpotesi tidak dengan sukses, mengidentifkasi proyek yang layak untuk dikerjakan, mengidentifikasi masalah pada proyek yang sedang berjalan dan mengambil tindakan koreksi 4. Lebih memungkinkan pencapaian kepuasan client, mempertahankan reputasi, dan mendapatkan kontrak tambahan dalam kompetisi yang terus meningkat I. Referensi: 2015 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Maciariello, J. A., & Kirby, C. J. (1994). Management Control Systems: Using Adaptive Systems to Attain Control. Upper Saddle River, NJ: Prentice Hall. 2. Johnson, James A. and Michael Friesen (1995). The Success Paradigm: Creating Organizational Effectiveness Through Quality and Strategy New York: Quorum Book. 3. Judgev, K. & Muller, R. 2005, "A Retrospective Look at Our Evolving Understanding of Project Success", Project Management Journal. 4. Kerzner, 2001, Strategic planning for project management using a project management maturity model, Wiley & Sons, New York, page 158. 5. Judgev, K. & Muller, R. 2005, "A Retrospective Look at Our Evolving Understanding of Project Success", Project Management Journal. 6. Shenhar, Aaron J, and R. Max Wideman (2002) Matcing project Management Style with project type for optimum success PM Forum website 7. Songer, A.D. dan Molenaar, K.R. (1997), Project Characteristics for Successful Public-sector Design-Build, J. Constr. Eng. Manage. 8. Ashley, D.B., Lurie, C.S. dan Jaselskis, E.J. (1987), Determinants of Construction Projects Success, Proj. Mgmt. J., 18(2), 69-77 9. Thamhain (2004) Team Leadership effectiveness in technology based project environment. Project environment journal. 10. Rockart, John F. 1986 "A Primer on Critical Success Factors" published in The Rise of Managerial Computing: The Best of the Center for Information Systems Research, edited with Christine V. Bullen. (Homewood, IL: Dow Jones-Irwin), 1981, OR, McGraw-Hill School Education Group. 11. Boynlon, A.C., and Zmud, R.W. 1984. "An Assessment of Critical Success Factors," Sloan Management Review (25:4), pp. 17-27. 2015 10 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Jaminan Kualitas Perangkat Lunak Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 10 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak Mahasiswa mengenal, memahami dan mampu menjamin kualitas perangkat lunak yang dihasilkan. Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Pengantar 1. Pendahuluan Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak. Jaminan kualitas perangkat lunak atau software quality assurance meliputi: 1. Pendekatan manajemen kualitas. 2. Teknologi rekayasa perangkat lunak yang efektif (metode dan peranti). 3. Kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak. 4. Strategi pengujian multitiered (deret bertingkat). 5. Kontrol dokumentasi perangkat lunak dan perubahan. 6. Prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak. 7. Mekanisme pengukuran dan pelaporan. 2. Kontrol kualitas Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses. Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan. 3. Kontrol kualitas Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas adalah untuk memberikan 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T data yang diperlukan Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran. 4. Biaya kualitas Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Studi tentang biaya kualitas dilakukan untuk memberikan garis dasar bagi biaya kualitas yang sedang digunakan, untuk mengidentifikasi kemungkinan pengurangan biaya kualitas serta memberikan basis perbandingan yang ternormalisasi. Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan: a) Pencegahan Biaya pencegahan meliputi: 1) Perencanaan 2) Kajian teknis formal 3) Perlengkapan pengujian 4) Pelatihan b) Penilaian Biaya penilaian meliputi: 1) Inspeksi in-proses dan interproses 2) Pemeliharaan dan kalibrasi peralatan 3) Pengujian c) Kegagalan Biaya kegagalan adalah biaya yang akan hilang bila tidak ada cacat yang muncul sebelum produk disampaikan kepada pelanggan. 1) Biaya kegagalan internal Biaya yang diadakan bila kita mendeteksi suatu kesalahan dalam produk sebelum produk dipasarkan. Biaya kegagalan internal meliputi: 2015 3 • Pengerjaan kembali • Perbaikan • Analisis mode kegagalan Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2) Biaya kegagalan eksternal Biaya yang berhubungan dengan cacat yang ditemukan setelah produk disampaikan kepada pelanggan. Biaya kegagalan eksternal meliputi: • Resolusi keluhan • Penggantian dan pengembalian produk • Dukungan help line • Kerja jaminan Biaya relatif mendapatkan dan membetulkan cacat bertambah secara dramatis pada saat kita melangkah dari pencegahan ke pendeteksian dan dari kegagalan internal ke kegagalan eksternal. Gambar 10.1 Biaya Relatif pembetulan kesalahan 5. Jaminan Kualitas Perangkat Lunak 2015 4 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Kualitas perangkat lunak didefinisikan sebagai konformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional. Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu: 1. Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukur. 2. Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun cara perangkat lunak direkayasa. 3. Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik). Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan. Kelompok SQA harus dapat menjawab pertanyaanpertanyaan dibawah ini untuk memastikan bahwa kualitas perangkat lunak benar-benar terjaga. 1. Apakah perangkat lunak cukup memenuhi faktor kualitas. 2. Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya? 3. Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA? 6. Aktivitas SQA Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda: • Perekayasa perangkat lunak yang mengerjakan kerja teknis. • Kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan. Tugas kelompok SQA adalah membantu tim rekayasa perangkat lunak dalam pencapaian produk akhir yang berkualitas tinggi. 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Aktivitas yang dilakukan (atau difasilitasi) oleh kelompok SQA yang independen: 1. Menyiapkan rencana SQA untuk suatu proyek. Rencana tersebut mengindentifikasikan hal-hal berikut: • Evaluasi yang dilakukan • Audit dan kajian yang dilakukan • Standar yang dapat diaplikasikan pada proyek • Prosedur untuk pelaporan & penelusuran kesalahan • Dokumen yang dihsilkan oleh kelompok SQA • Jumlah umpan balik yang diberikan pada tim proyek perangkat lunak 2. Berpartisipasi dalam pengembangan deskripsi proses pengembangan proyek 3. Mengkaji aktivitas rekayasa perangkat lunak untuk memverifikasi pemenuhan proses perangkat lunak yang sudah ditentukan. 4. Mengaudit produk kerja perangkat lunak yang ditentukan untuk membuktikan kesesuaian dengan produk kerja yang ditentukan tersebut sebagai bagian dari proses perangkat lunak. 5. Memastikan bahwa deviasi pada kerja dan produk perangkat lunak didokumentasikan & ditangani sesuai dgn rosedur pendokuementasian. 6. Mencatat ketidak-sesuaian dan melaporkannya kepada manajemen senior. 7. Mengkoordinasi kontrol dan manajemen perubahan, dan membantu mengumpulkan dan menganalisis metrik perangkat lunak. 7. Kajian Perangkat Lunak Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting. Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari kesalahan yg kemudian akan dihilangkan. Kajian perangkat lunak berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean. 8. Kajian Teknik Formal 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak. Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan. Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak. Tujuan FTR adalah: 1. Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL. 2. Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat. 3. Memastikan bahwa PL disajikan sesuai dgn standar yg sudah ditentukan sebelumnya. 4. Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam 5. Membuat proyek lebih dapat dikelola. FTR berfungsi sebagai dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi. FTR juga berfungsi untuk mengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya Masing-masing FTR dilakukan sebagai suatu pertemuan dan akan berhasil hanya bila direncanakan, dikontrol dan dihadirkan dengan tepat. Dalam paragraf berikut, panduan yang mirip dengan walktrough disajikan sebagai kajian teknis formal representatif. Tabel 10.1 Perbandingan Biaya Pengembangan Kesalahan yang ditemukan Jumlah Unit Biaya Total Kajian dilakukan Selama desain 22 1.5 33 Sebelum pengujian 36 6.5 234 Selama pengujian 15 15 315 Setelah peluncuran 3 67 201 Total Kajian tidak 2015 7 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 783 dilakukan Sebelum pengujian 22 6.5 143 Selama pengujian 82 15 1230 Setelah peluncuran 12 67 804 Total 2177 9. Pertemuan Kajian Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus mematuhi batasan-batasan berikut ini: • Antara 3 & 5 orang (khususnya) harus dilibatkan dalam kajian. • Persiapan awal harus dilakukan, tetapi waktu yang dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap orang. • Durasi pertemuan kajian harus kurang dari 2 jam. Pertemuan kajian dihadiri oleh pimpinan kajian, pengkaji, dan prosedur. Salah satu dari pengkaji berperan sebagai pencatat, yaitu seseorang yang mencatat semua masalah penting yang muncul selama pengkajian. FTR dimulai dengan pengenalan agenda dan pendahuluan dari prosedur. Bila ada masalah kesalahan ditemukan akan dicatat. Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan: 1. Menerima produk kerja tanpa modifikasi lebih lanjut. 2. menolak produk kerja sehubungan dengan kesalahan yangada (sekali dbetulkan, kajiann lain harus dilakukan), atau 3. Menerima produk kerja secara sementara (kesalahan minor telah terjadi & harus dikoreksi, tetapi kajian tambahan akan diperlukan). Keputusan kemudian dibuat. Semua peserta FTR melengkapinya dengan tanda tangan yang menunjukkan partisipasi mereka dalam kajian serta persetujuan mereka terhadap pertemuan tim kajian. 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 10. Kajian Teknik Formal Selama FTR, seorang pengkaji (pencatat) secara aktif mencatat semua masalah yang sudah dimunculkan, yang kemudian dirangkum pada akhir pertemuan sehingga dihasilkan daftar masalah kajian. Sebagai tambahan, laporan rangkuman kajian yang sederhana telah diselesaikan di mana rangkuman kajian merupakan jawaban dari tiga pertanyaan berikut: 1. Apa yang dikaji? 2. Siapa yang melakukan? 3. Penemuan apa yang dihasilkan dan apa kesimpulannya? Daftar masalah kajian mempunyai dua tujuan: 1. Mengidentifikasi area masalah pada produk. 2. Da fta r it em k eg i at a n y an g m enj adi petunj uk bagi p ros edu r s aa t k o rek s i di l ak uk an. Da fta r m as al ah b i as any a di l am pi rk a n pa da l ap or an . 11. Pedoman Kajian Pedoman untuk melakukan kajian teknis formal harus dilakukan sebelumnya, didistribusikan kepada semua pengkaji, disetujui, dan kemudian dilaksanakan. Kajian yang tidak terkontrol sering dapat menjadi lebih buruk daripada bila tidak ada kajian sama sekali. Berikut ini serangkaian pedoman minimum untuk kajian teknis formal: 1. Kajian produk, bukan produser. 2. Menetapkan agenda dan menjaganya. 3. Membatasi perdebatan dan bantahan. 4. Menetapkan area masalah, tetapi tidak tergoda untuk menyelesaikannya setiap masalah yang dicatat. 2015 5. Mengambil catatan tertulis. 6. Membatasi jumlah peserta dan mewajibkan persiapan awal. 7. Mengembangkan daftar bagi masing masing produk kerja yang akan dikaji. 8. Mengalokasikan sumber-sumber daya dan jadwal waktu untuk FTR. 9. Melakukan pelatihan bagi semua pengkaji. 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 10. Mengkaji kajian awal Anda. 12. Pendekatan Formal Terhadap SQA Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima. Pada lebuh dari dua dekade, segmen komunitas rekayasa perangkat lunak yang kecil tetapi vokal telah memperlihatkan bahwa dibutuhkan suatu pendekatan yang lebih formal terhadap jaminan kualitas perangkat lunak. Pembuktian matematis terhadap kebenarannya dapat diaplikasikan untuk menunjukkan bahwa program menyesuaikan diri secara tepat dengan spesifikasinya. 13. Pendekatan Formal Terhadap SQA Jaminan kualitas statistik mencerminkan trend yang sedang tumbuh di seluruh industri untuk menjadi lebih kuantitatif terhadap kualitas. Pada perangkat lunak, jaminan kualitas statistik mengimplikasikan langkah-langkah berikut ini: 1. Informasi tentang cacat perangkat lunak dikumpulkan dan dipilah- pilahkan. 2. Melakukan suatu usaha untuk menelusuri masing-masing cacat sampai ke penyebab pokoknya. 3. Dengan menggunakan prinsip Pareto (80 persen cacat dapat ditelusuri sampai 20 persen dari semua kemungkinan penyebab), mengisolasi yang 20 persen tersebut (vital few). 4. Sekali penyebab vital few telah diidentifikasi, beralih untuk membetulkan maslah yang menyebabkan cacat. Banyak kesalahan ditemukan pada waktu perangkat lunak sedang dalam proses pengembangan. Cacat yang lain ditemukan setelah perangkat lunak diluncurkan kepada pemakai akhir. Meskipun ratusan kesalahan yang berbeda diluncurkan, semuanya dapat ditelusuri dari satu (atau lebih) penyebab berikut ini: 1. 2015 10 Spesifikasi yang tidak lengkap atau keliru (IES) Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Kesalahan interpretasi komunikasi pelanggan (MMC) 3. Deviasi intersioanl dari spesifikasi (IDS) 4. Pelanggaran standar pemrograman (VPS) 5. Kesalahan dalam representasi data (EDRIMI) 6. Kesalahan dalam logika desain (EDL) 7. Interface modul yang tidak konsisten (IMI) 8. Pengujian yang tidak lengkap atau keliru (IET) 9. Dokumentasi yang tidak lengkap atau tidak akurat (IID) 10. Kesalahan dalam penerjemahan bahasa pemrograman desain (PLT) 11. Antarmuka manusia dengan komputer yang tidak konsisten mengandung ambiguitas (HCI) 12. Dan msih banyak lagi (MIS) Referensi: 1. Presman, Rouger S, Software Enigineering, 4th Edition, Mc. Graw Hill,1997 2. Sommerville,Ian, Software Engineering, 7th Edition, Addison Wesley, 2004 3. Kendall & Kendall, Systems Analysis and Design, 6th Edition, Prentice Hall,2006 2015 11 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id atau MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Negosiasi Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 11 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Negosiasi merupakan salah satu faktor yang penting di dalam sebuah proyek perangkat lunak Mahasiswa mengenal, memahami dan memiliki kemampuan bernegosiasi didalam sebuah aktivitas proyek perangkat lunak. Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Pengantar 1. Pendahuluan Negosiasi tidak hanya digunakan di dalam bisnis yang bertujuan untuk meraih laba, namun juga sangat bermanfaat di dalam menjalankan dan mencapai tujuan proyek Teknologi Informasi. Teknik negosiasi yang dapat digunakan di dalam proyek TI pada prinsipnya sama dengan teknik negosiasi di dalam bisnis, politik, hukum, social, dan lain-lain Seperti halnya di dalam bisnis, negosiasi selalu mengarah kepada keberhasilan suatu tujuan. Di dalam bernegosiasi prinsip dasar yang harus sama-sama disadari adalah adanya prinsip member dan menerima. Namun seberapa besar porsi member dan porsi menerima tergantung kepada kemampuan bernegosiasi. Semakin tinggi kemampuan seseorang bernegosiasi, semakin banyak akan menerima keuntungan dari proses negosiasi. Demikian juga sebaliknya, semakin rendah kempuan seseorang bernegosiasi, semakin kecil keuntungan dari proses negosiasi dan bahkan mungkin bisa menimbulkan kerugian yang tidak diinginkan. Oleh karena itu, di dalam menjalankan suatu proyek TI, seorang Project Manager atau Project Lead TI harus dapat menjadi negosiator yang ulung, yang dapat mengetahui secara pasti kapan harus memberi atau menerima. Seorang negosiator yang ulung haruslah memiliki daya peka / kepekaan yang tinggi terhadap situasi dan suasana di dalam proses negosiasi. Daya peka tersebut dapat digunakan oleh seorang negosiator ulung menekan lawan negosiasinya. Kemampuan negosiasi tidak hanya digunakan untuk menekan lawan negosiasi, tetapi juga membela diri pada saat tertekan. Teknik bernegosiasi bukanlah teknik pandai berbicara, namun lebih kepada teknik berbicara pada saat dan situasi yang tepat. Negosiasi adalah seni, yang dapat dipelajari dan bersifat unik karena selain dapat menguntungkan atau merugikan pihak lawan, dapat juga sebagai proses kerja sama / kolaborasi dua pihak yang berbeda kepentingan dengan tujuan akhir hasil yang terbaik bagi kedua belah pihak. 2. Teori Negosiasi 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Pengenalan Pengertian Negosiasi (The Nature of Negotiation) Negosiasi dapat terjadi setiap saat, antar teman, antar keluarga, antar rekan bisnis, antar pengacara, antar penegak hukum, antar Negara dan lain sebagainya. Negosiasi bukanlah suatu proses timbal balik, namun merupakan kemampuan diplomasi, kemampuan penjualan yang unggul, kemampuan daya juang yang tinggi yang terjadi di dalam kehidupan sehari-hari. Adakalanya negosiasi digunakan di dalam situasi yang penting seperti negosiasi pekerjaan baru ataupun situasi yang sangat sederhana seperti tugas mencuci piring. Namun demikian struktur dan proses negosiasi tetaplah sama pada level individu maupun organisasi. Adapun karakteristik dari negosiasi antara lain: 1. Terdapat dua atau lebih pihak yang terlibat di dalam proses negosiasi. 2. Terdapat perbedaan kepentingan ( conflict ) antara dua atau lebih pihak yang terlibat di dalam proses negosiasi. 3. Negosiasi dilakukan oleh pihak yang berkepentingan karena mereka berpikir bahwa mereka dapat menggunakan pengaruhnya untuk mendapatkan kesepakatan yang lebih baik dengan cara bernegosiasi dibandingkan dengan begitu saja mengalah terhadap lawan negosiasi. 4. Pihak – pihak yang bernegosiasi akan lebih suka melakukan kesepakatan dibandingkan harus berseteru secara terbuka, menyerah begitu saja, memutuskan komunikasi atau memeruskan perselisihan ketingkat yang lebih tinggi. 5. Negosiasi adalah proses memberi dan menerima. 6. Negosiasi yang sukses akan mempengaruhi manajemen secara intangibles dan tangibles. Tingkatan Perbedaan Kepentingan (conflict): 2015 3 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Perbedaan kepentingan di dalam diri seseorang (Intra personal or intra psychic conflict) 2. Perbedaan kepentingan antar seseorang (Inter Personal Conflict) 3. Perbedaan kepentingan di dalam kelompok (Intra Group Conflict) 4. Perbedaan kepentingan antar kelompok (Inter Group Conflict) Hal-hal yang dapat menimbulkan Conflict: 1. Proses kompetisi (competitive process) 2. Interpretasi yang berbeda dan bias (Misperception and Bias) 3. Emosi (Emotionality) 4. Komunikasi yang tidak kondusif (Decreased Communication) 5. Issue yang tidak jelas (Blurred Issues) 6. Komitmen yang kaku (Rigid Commitment) 7. Memperbesar perbedaan dan memperkecil persamaan (Magnified Differences dan Minimized Similarities) 8. Perbedaan kepentingan yang di perluas (Escalation of the Conflict) Strategi untuk menghadapi perbedaan kepentingan (conflict): 1. Kompetisi/ Bersaing (Contending / Competing / Dominating) 2. Penurut (Yielding / Accommodating / Obliging) 3. Menghindar (Inaction / Avoiding) 4. Kolaborasi / menyelesaikan masalah (Collaborating / Integrating) 5. Kompromi (Compromising) 2. Frame, Strategi dan Rencana Negosiasi Sebelum melakukan negosiasi, negotiator harus mempersiapkan rencana dan strategi yang efektif , yang merupakan kunci keberhasilan dari tujuan negosiasi. Apabila tidak menggunakan rencana dan startegi maka negosiasi hanya akan menghasilkan kesempatan dibandingkan usaha untuk mendapatkan tujuan yang diinginkan. Kerangka Masalah ( Framing the Problem ) - Proses Mendefinisikan Seberapa Penting Masalah, ada 3 pendekatan yang dapat dipelajari yaitu: 2015 4 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Kerangka yang berhubungan dengan suatu keputusan yang sederhana (Frames as cognitive heuristics – simple decision rules) 2. Kerangka yang berhubungan dengan pengalaman, latar belakang dan pengetahuan training yang berbeda-beda (Frames as categories of experience) 3. Kerangka yang berhubungan dengan pilihan dan prioritas (Frames as issue development ) Setelah negotiator mempunyai kerangka atas masalah yang terjadi, negotiator juga harus mempunyai strategi untuk menentukan tujuan yang akan dicapai. Negotiator harus dapat mengantisipasi apa yang akan dicapai di dalam negosiasi dan menyiapkan segala sesuatu yang mungkin akan sejak awal. Untuk itu negotiator harus dapat mengetahui aspek-aspek yang terkait dengan tujuan yang dapat berpengaruh secara langsung maupun tidak langsung terhadap hasil negosiasi. 4 Aspek yang terkait dengan tujuan, yang berpengaruh secara langsung terhadap tujuan negosiasi yaitu: 1. Harapan bukanlah tujuan, namun merupakan kebutuhan untuk mencapai tujuan. 2. Tujuan kita seringkali terkait dengan tujuan pihak lain. 3. Terdapat batasan untuk dapat mencapai tujuan kita. 4. Tujuan yang efektif haruslah kongkrit/ spesifik dan dapat diukur. Aspek yang terkait dengan tujuan, yang berpengaruh secara tidak langsung terhadap tujuan negosiasi yaitu: 1. Untuk tujuan yang sederhana, kejadian di masa lalu tidak berpengaruh terhadap negosiasi. Misalnya : proses jual beli mobil, mengabaikan siapa pemilik sebelumnya. 2. Untuk tujuan yang lebih kompleks, kejadian di masa lalu berpengaruh terhadap negosiasi. Misalnya : proses pemutusan kredit, haruslah mempertimbangkan kredibilitas nasabah di masa yang lalu. Bagaimana hubungan antara strategi dan taktik ? Perbedaan utamanya adalah pada skala, perspektif dan tingkat kepentingan. Taktik lebih besifat jangka pendek, didesain lebih adaptif terhadap perubahan untuk mendukung high level strategi, lebih 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id stabil, berkelanjutan dan mengarahkan perilaku yang lebih taktis. Taktik merupakan bagian dari strategi yang lebih terstruktur, terarah dan terdorong oleh pertimbangan strategis. Bagaimana hubungan antara strategi dan perencanaan ? Perencanaan merupakan bagian dari proses strategi. Bagaimana perencanaan dihasilkan akan menjadi petunjuk yang strategis. 4 tipe strategi untuk negosiasi adalah: 1. Kompetisi (Competition) 2. Kolaborasi (Collaboration) 3. Akomodasi (Accommodation) 4. Menghindar (Avoidance) Kunci sukses negosiasi bukanlah bagaimanana proses negosiasi itu sendiri yang dapat dianggap permainan ataupun sandiwara, namun perencanaan yang handal sebelum dilakukannya negosiasi. Kelemahan di dalam melakukan perencanaan sebelum melakukan negosiasi adalah keterbatasan waktu untuk membuat rencana, antara lain: 1. Negotiator gagal menyusun tujuan yang jelas 2. Negotiator tidak dapat mengetahui kekuatan dan kelemahannya untuk mendukung posisinya terhadap argument pihak lawan 3. Negotiator tidak cukup cepat dan pandai untuk memberi dan menerima hasil negosiasi yang dapat membuat situasi down, dimana pihak lawan menyerang dengan cara-cara yang mungkin saja bisa bertentangan dengan ketentuan, tidak mempuyai dasar yang kuat ataupun tidak efektif. Perencanaan negosiasi yang efektif mencakup: 1. Definisikan isu-isu (defining issues) 2. Kumpulkan isu-isu dan definisikan scenario tawar menawar (assembling issues and defining the bargaining mix) 3. Definisikan kepentingan (defining interest) 4. Konsultasi dengan pihak lain (consulting with others) 5. Identifikasi Batasan (Identifying Limits) 6. Tetapkan sasaran (Setting Targets) 7. Kembangan pendapat-pendapat yang supporting arguments) 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id menudukung (Developing 8. Analisa pihak lawan (Analyzing the other party) 3. Strategi dan Taktik Tawar Menawar Untuk lebih memahami struktur dasar dari situasi kompetisi dan tawar menawar serta strategi dan taktik tawar menawar, kita harus memahami terlebih dahulu bagaimana proses tawar menawar dimulai. Tawar menawar dimulai dari menetapkan hal-hal yang menjadi pembuka, sasaran dan perlawanan di dalam proses negosiasi. Kita akan dengan mudah mengetahui hal-hal yang menjadi pembuka dan sasaran pihak lawan, namun kita akan mengalami kesulitan untuk mengetahui strategi perlawanan pihak lawan, karena pada umumnya disembunyikan oleh lawan. Mengetahui strategi perlawanan pihak lawan adalah kunci utama kesuksesan di dalam proses tawar menawar. Perbedaan antara strategi perlawanan yang kita miliki dengan strategi perlawanan pihak lawan akan menentukan sukses tidaknya proses negosiasi. Jika perbedaan tersebut bernilai positif maka akan terjadi proses negosiasi. Jika perbedaan tersebut bernilai negative makan tidak akan terjadi proses negosiasi. Di dalam proses negosiasi umumnya isu yang dibahas lebih dari satu, sehingga di dalam proses tawar menawar akan terdapat lebih dari satu hal-hal yang menjadi pembuka, sasaran dan perlawanan dari pihak lawan. Proses tawar menawar secara gabungan akan menghasilkan sekumpulan isu yang sama, hubungan timbal balik dan menghasilkan perilaku konsesi yang saling menguntungkan. Proses tawar menawar pada dasarnya adalah suatu situasi konflik, dimana pihak-pihak yang saling berlawanan ingin mendapatkan keuntungan,dengan cara menyembunyikan informasi, mencoba untuk mengalihkan atau menggunakan aksi-aksi manipulasi. Semua taktik ini akan dengan mudah menghasilkan interaksi dari diskusi yang tenang menjadi diskusi yang panas. Negosiasi merupakan jalan keluar untuk menyelesaikan suatu konflik dengan cara memaksa untuk menghasilkan suatu kesepakatan tanpa menimbulkan perkelahian. Oleh karenanya, untuk menghasilkan negosiasi yang sukses, kedua belah pihak yang bernegosiasi haruslah merasa hasil negosiasi merupakan hasil yang terbaik, yang dapat dihasilkan nilainya dapat diterima dan didukung. Bagaimanapun juga negosiasi adalah suatu proses yang dibutuhkan, bukan hanya keahlian tetapi juga pengertian/ pemahaman dan perencanaan yang baik. 2015 7 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 4. Strategi dan Taktik Negosiasi Terpadu Struktur dasar dari proses negosiasi terpadu adalah ditentukannya beberapa tujuan negosiasi oleh seorang negosiator yang memungkinkan pihak-pihak yang terlibat di dalam proses negosiasi dapat mencapai sasaran-sasaran yang diingikannya. Negosiasi terpadu adalah proses mendefinisikan beberapa tujuan dan terikat dengan seperangkat prosedur yang memungkingkan kedua belah pihak yang bernegosiasi memaksimalkan sasaran mereka. Negosiasi terpadu yang sukses akan memerlukan beberapa proses. Pertama, setiap pihak yang melakukan negosiasi haruslah saling memahami kebutuhan dan tujuannya. Kedua, setiap pihak yang melakukan negosiasi haruslah dapat menciptakan arus informasi bebas dan pertukaran pemikiran yang terbuka. Ketiga, setiap pihak yang melakukan negosiasi haruslah fokus terhadap persamaan, bukan kepada perbedaan yang ada. Terakhir setiap pihak yang melakukan negosiasi haruslah sepakat untuk mencari solusi yang terbaik agar sejalan dengan tujuan kedua belah pihak. 5. Komunikasi, Persepsi dan Bias Kognitif Terdapat dua kritikal proses terkait dengan upaya negotiator menjadikan proses negosiasi menjadi berarti dan komunikasi berjalan yaitu persepsi ( perception ) dan pengetahuan ( cognition ). Komunikasi seperti apa yang dibutuhkan di dalam proses negosiasi ? Negosiasi bukanlah sekedar proses pertukaran pilihan solusi, namun lebih luas dari itu, negosiasi mencakup sejumlah topik yang luas di dalam suatu lingkungan dimana setiap pihak yang bernegosiasi berupaya untuk saling mempengaruhi satu sama lain. Negosiasi juga dapat dilihat dari perspektif linguistic. Apabila di lihat dari sudut pandang persepsi dan negosiasi itu sendiri serta persepsi proses negosiasi terdapat 4 (empat) distorsi persepsi yaitu: 1. Stereotyping 2. Halo Effects, 3. Selective Perception 4. Projection 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Kerangka masalah (frame) mempengaruhi persepsi di dalam proses negosiasi. Selain itu juga kerangka masalah dan isu-isu pengembangan akan berpengaruh kepada persepsi negotiator selama proses negosiasi berlangsung. Berdasarkan hasil penelitian, diperoleh satu kesimpulan bahwa terdapat bias kognitif (cognitive bias) dari satu atau lebih area permintaan keterangan didalam proses negosiasi. Terdapat 11 (sebelas) perbedaan bias kognitif ( cognitive bias ) yaitu: 1. Irational escalation of commitment 2. Mithical fixed-pie beliefs 3. Anchoring and adjustment 4. Framing 5. Availability of information 6. The winner’s curse 7. Overconfidence 8. The law of small number 9. Self-serving biases 10. Ignoring of others’ cognitions 11. Reactive devaluation Di dalam proses negosiasi perbedaan persepsi dan bias kognitif haruslah di jaga agar tidak menjadi perbedaan yang signifikan. Cara meningkatkan komunikasi di dalam proses negosiasi adalah dengan menggunakan teknik : the use of questions, listening dan role reversal. Cara memperbaiki suasana hati dan emosi di dalam proses negosiasi adalah dengan menggunakan teknik komunikasi, dengan menggunakan 2 (dua) model komunikasi yaitu: 1. Cold communication, mencakup : penuh perhitungan (calculating), tenang (calm) dan kontrol (control). 2. Warm communication, mencakup : suasana panas (hot), marah (angry), bersemangat (passionate) 6. Mengetahui Pengaruh Negosiasi Apabila kita berbicara tentang pengaruh negosiasi, kita akan mulai membahasnya dari sifat kekuasaan. Ada 3 (tiga) sifat kekuasaan yaitu informasi dan 2015 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id keahlian, kontrol atas sumber daya dan lokasi di dalam struktur organisasi baik untuk kekuasaan yang bersifat formal maupun informal. Negosiasi yang merupakan proses tawar menawar atau penggunaan sumber kekuasaan yang berbeda-beda untuk memperoleh atau menggunakan keuntungan sementara atas negosiasi dengan pihak lain. Ada 4 (empat) cara yang dapat digunakan untuk mempengaruhi proses negosiasi, yaitu: 1. Message factors, yaitu cara dimana isi dari pesan (posisi pernyataan, daya tarik, dan lain-lain) dapat disusun dan disampaikan untuk meningkatkan efektifitas. 2. Source factors, yaitu cara dimana pengirim pesan dapat meningkatkan kredibilitas dan ketertarikan agar membuat pesan menjadi lebih dapat dipercaya dan lebih terkesan ramah. 3. Receiver factors, yaitu cara dimana penerima pesan dapat menentukan dan mengarahkan apa yang dikomunikasikan oleh pengirim pesan atau menolak secara halus dampak persuasif dari pesan yang disampaikan. 4. Context factors, atau elemen yang melekat dalam struktur sosial ( seperti hubungan antar pihak yang bernegosiasi, pengaturan pengiriman pesan atau banyaknya waktu yang dibutuhkan untuk mengkomunikasikan pesan ) yang dapat menentukan apakah suatu pesan berlebih atau kurang dapat diterima / kurang lengkap. Ada 2 (dua) hal yang dapat dipelajari terkait dengan pengaruh negosiasi yaitu: 1. Pengaruh di dalam negosiasi dapat sangat sukar dipahami ataupun dilakukan dalam sekejap. 2. Pihak-pihak yang bernegosiasi biasanya harus menghabiskan banyak waktu untuk merancang cara untuk mendapatkan dukungan dan memposisikan mereka di dalam proses negosiasi. 7. Etika Bernegosiasi Etika bernegosiasi dapat menjadi suatu hal yang sangat kritis untuk memilih strategi tertentu dan pilihan taktis di dalam proses negosiasi. Apabila pihak-pihak yang bernegosiasi memilih untuk memilih taktik yang tidak etis, umumnya keputusan yang 2015 10 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id diambil menggunakan pendekatan kekuasaan yang lebih besar. Adapun konsep etika negosiasi adalah sebagai berikut: 1. Pada saat ada pihak yang terlibat negosiasi tidak setuju dengan proses negosiasi, hal ini dapat menjadi proses negosiasi yang beretika atau tidak beretika. Penelitian membuktikan bahwa terdapat lebih banyak konvergensi hasil negosiasi dari pada sesuatu yang diharapkan 2. Keputusan untuk menggunakan taktik yang tidak jujur mugkin saja bisa dipahami dengan membuat suatu model keputusan. Hal ini sangat jelas tergambar dimana individu berbeda-beda dan variabel-variabel situasi yang dapat mempengaruhi suatu keputusan 3. Pada saat memutuskan untuk menggunakan taktik yang tidak jujur, seorang negotiator umumnya lebih banyak dipengaruhi oleh motivasi individu, ekspektasi tentang apa yang akan dilakukan oleh negosiator lainnya dan hubungan antar pihak yang bernegosiasi di kemudian hari 4. Pihak-Pihak yang melakukan proses negosiasi dengan cara yang tidak jujur, sebaiknya mengevaluasi kembali penggunaan taktik ini untuk proses negosiasi di kemudian hari. Karena meskipun jenis taktik ini bisa digunakan untuk jangka waktu yang singkat, namun akan menjadi tidak efektif untuk jangka waktu yang panjang 8. Mengatur Negosiasi yang Sulit Proses negosiasi sering kali menghadapi kebutuan seperti komunikasi yang terputus, kemarahan yang memuncak dan rasa tidak percaya, polarisasi posisi dan penolakan terhadap suatu kompromi, adanya ultimatum, ketidakmampuan akan hal yang sederhana di dalam hal memenuhi kepuasan hasil negosiasi di kedua belah pihak. Adapun teknik-teknik yang dapat digunakan untuk mengatur negosiasi yang sulit adalah: 1. Menurunkan tingkat ketegangan dengan cara memisahkan pihak yang bersitegang untuk masa tenang dalam kurun waktu tertentu/ yang cukup, membicarakan tentang emosi dan perasaan atau mencoba untuk mengsikronisasikan dengan menurunkan ringkat eskalasi dari konflik 2. Lakukan peningkatan komunikasi yang akurat dengan cara menyampaikan pendapat orang lain atau sebaliknya 2015 11 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Menjaga agar isu tetap dalam koridor terkontrol sehingga tidak akan menjadi isu yang bertambah atau lebih besar dan menjadi isu yang kelompok-kelompok kecil 4. Tentukan posisi komunalitas, cara-cara untuk mendefinisikan isu-isu untuk dapat mencapai tujuan kedua belah pihak ( kerangka yang terintegrasi ) dan tujuan lainnya yang akan menyatukan pihak-pihak yang bernegosiasi mencapai tujuan bersama 5. Ciptakan suasana dimana setiap pihak yang bernegosiasi memilki pilihan yang diinginkan sesuai yang diharapkan dan nyaman untuk pihak lawan dengan cara mengemas usulan yang lebih baik Referensi: 1. Astra Human resources Management. 2001. Jakarta, Astra International 2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and Management, New York, McGraw-Hill International Edition. 3. Hariwijaya. 2010. Strategi Lobi dan Negosiasi, Yogyakarta, Oriza. 4. Jimmy Joses Sembiring. Smart HRD. 2010. Jakarta, Visimedia. 5. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media Group. 2015 12 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Kerjasama Tim Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 12 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Kerjasama tim dibutuhkan didalam pelaksanaan sebuah proyek perangkat lunak Mahasiswa mengenal, memahami dan memiliki kemampuan bekerja secara tim di dalam sebuah proyek perangkat lunak Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Pengantar 1. Pendahuluan Penyelenggaraan teamwork dilakukan karena pada saat ini tekanan persaingan semakin meningkat, para ahli menyatakan bahwa keberhasilan organisasi akan semakin bergantung pada teamwork daripada bergantung pada individu-individu yang menonjol. Konsep tim maknanya terletak pada ekspresi yang menggambarkan munculnya sinergi pada orang-orang yang mengikatkan diri dalam kelompok yang disebut dengan tim. Tracy (2006) menyatakan bahwa teamwork merupakan kegiatan yang dikelola dan dilakukan sekelompok orang yang tergabung dalam satu organisasi. Teamwork dapat meningkatkan kerja sama dan komunikasi di dalam dan di antara bagianbagian perusahaan. Biasanya teamwork beranggotakan orang-orang yang memiliki perbedaan keahlian sehingga dijadikan kekuatan dalam mencapai tujuan perusahaan. Pernyataan di atas diperkuat Dewi (2007) kerja tim (teamwork) adalah bentuk kerja dalam kelompok yang harus diorganisasi dan dikelola dengan baik. Tim beranggotakan orang-orang yang memiliki keahlian yang berbeda-beda dan dikoordinasikan untuk bekerja sama dengan pimpinan. Terjadi saling ketergantungan yang kuat satu sama lain untuk mencapai sebuah tujuan atau menyelesaikan sebuah tugas. Dengan melakukan teamwork diharapkan hasilnya melebihi jika dikerjakan secara perorangan. Stephen dan Timothy (2008) menyatakan teamwork adalah kelompok yang usaha-usaha individualnya menghasilkan kinerja lebih tinggi daripada jumlah masukan individual. Teamwork menghasilkan sinergi positif melalui usaha yang terkoordinasi. Hal ini memiliki pengertian bahwa kinerja yang dicapai oleh sebuah tim lebih baik daripada kinerja perindividu di suatu organisasi ataupun suatu perusahaan. Teori yang dikemukakan oleh Stephen dan Timothy (2008) senada dengan teori tim yang efektif yang dikemukakan oleh Smither, Houston, McIntire (1996). Manurut Smither, Houston, McIntire (1996), tim yang efektif adalah sebuah tim yang memungkinkan anggotanya untuk bisa menghasilkan penyelesaian tugas yang lebih besar jumlahnya dibandingkan dengan hasil kerja perorangan karena hasil kerjanya merupakan hasil dari kontribusi anggota-anggota tim secara bersama-sama. 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pernyataan tersebut juga didukung oleh Burn (2004), yang menyatakan bahwa efektifitas tim atau tim yang efektif merupakan tim kerja yang anggota-anggotanya saling berkolaborasi untuk mencapai tujuan bersama dan memiliki sikap yang saling mendukung dalam kerjasama tim. 2. Jenis Kerjasama Tim Menurut Daft (2000) jenis teamwork terdiri dari 6 (enam) jenis, yaitu: 1. Tim Formal Tim formal adalah sebuah tim yang dibentuk oleh organisasi sebagai bagian dari struktur organisasi formal. 2. Tim Vertikal Tim vertikal adalah sebuah tim formal yang terdiri dari seorang manajer dan beberapa orang bawahannya dalam rantai komando organisasi formal. 3. Tim Horizontal Tim horizontal adalah sebuah tim formal yang terdiri dari beberapa karyawan dari tingkat hirarki yang hampir sama tapi berasal dari area keahlian yang berbeda. 4. Tim dengan Tugas Khusus Tim dengan tugas khusus adalah sebuah tim yang dibentuk diluar organisasi formal untuk menangani sebuah proyek dengan kepentingan atau kreativitas khusus. 5. Tim Mandiri Tim Mandiri adalah sebuah tim yang terdiri dari 5 hingga 20 orang pekerja dengan beragam keterampilan yang menjalani rotasi pekerjaan untuk menghasilkan sebuah produk atau jasa secara lengkap, dan pelaksanaannya diawasi oleh seorang annggota terpilih. 2015 3 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 6. Tim Pemecahan Masalah Tim pemecahan masalah adalah biasanya terdiri dari 5 hingga 12 karyawan yang dibayar perjam dari departemen yang sama, dimana mereka bertemu untuk mendiskusikan cara memperbaiki kualitas, efisiensi, dan lingkungan kerja. Sedangkan menurut Hariandja (2006) ada 3 (tiga) tipe tim, yaitu: 1. Problem solving team Sebuah tim yang dibentuik untuk mengatasi berbagai masalah yang muncul dalam upaya memperbaiki produktivitas. Pada dasarnya, kegiatan tim ini adalah mengidentifikasikan berbagai masalah, mendiskusikan bagaimana memecahkan masalah tersebut dan melakukan tindakan untuk memperbaiki. Anggota tim biasanya berasal dari satu departemen yang beranggotakan kurang lebih sepuluh orang yang melakukan pertemuan rutin setiap minggu. 2. Self managed team Sebuah tim yang dimaksudkan untuk memperbaiki produktivitas dengan memberikan kewenangan pada kelompok untuk mengatur kerja mereka, misalnya menjadwal kerja, menentukan metode kerja, mengawasi anggota, memberi reward dan hukuman bagi anggota dan merekrut anggota. Keanggotaan ini biasanya berasal dari satu departemen yang melakukan tugas yang sama. 3. Cross functional team Sebuah tim yang ditujukan untuk menyelesaikan tugas-tugas khusus, misalnya pengembangan produk baru atau perencanaan dan perubahan sistem kompensasi. Anggota tim ini berasal dari berbagai departemen yang memiliki keahlian dan orientasi yang berbeda yang bekerjasama untuk mencapai suatu tujuan. 3. Tahap Perkembangan Teamwork Hal yang sangat mendasar dalam mewujudkan keutuhan sebuah tim agar dapat berkinerja dan berdaya guna adalah dengan melakukan perancangan tim yang baik. 2015 4 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Pentingnya perancangan tim yang baik diuraikan Griffin (2004) dengan membagi ke dalam 4 (empat) tahap perkembangan, yaitu: 1. Forming Forming (pembentukan), adalah tahapan di mana para anggota setuju untuk bergabung dalam suatu tim. Karena kelompok baru dibentuk maka setiap orang membawa nilai-nilai, pendapat dan cara kerja sendiri-sendiri. Konflik sangat jarang terjadi, setiap orang masih sungkan, malu-malu, bahkan seringkali ada anggota yang merasa gugup. Kelompok cenderung belum dapat memilih pemimpin (kecuali tim yang sudah dipilih ketua kelompoknya terlebih dahulu). 2. Storming Storming (merebut hati), adalah tahapan di mana kekacauan mulai timbul di dalam tim. Pemimpin yang telah dipilih seringkali dipertanyakan kemampuannya dan anggota kelompok tidak ragu-ragu untuk mengganti pemimpin yang dinilai tidak mampu. Faksi-faksi mulai terbentuk, terjadi pertentangan karena masalahmasalah pribadi, semua bersikeras dengan pendapat masing-masing. Komunikasi yang terjadi sangat sedikit karena masing-masing orang tidak mau lagi menjadi pendengar. 3. Norming Norming (pengaturan norma), adalah tahapan di mana individu-individu dan subgroup yang ada dalam tim mulai merasakan keuntungan bekerja bersama dan berjuang untuk menghindari team tersebut dari kehancuran (bubar). Karena semangat kerjasama sudah mulai timbul, setiap anggota mulai merasa bebas untuk mengungkapkan perasaan dan pendapatnya kepada seluruh anggota tim. 4. Performing Performing (melaksanakan), adalah tahapan merupakan titik kulminasi di mana team sudah berhasil membangun sistem yang memungkinkannya untuk dapat bekerja secara produktif dan efisien. Pada tahap ini keberhasilan tim akan terlihat dari prestasi yang ditunjukkan. 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 4. Peranan Anggota Tim Selanjutnya Williams (2008) membagi ada 5 (lima) hal yang menunjukkan peranan anggota dalam membangun kerja tim yang efektif, yaitu: 1. Para anggota mengerti dengan baik tujuan tim dan hanya dapat dicapai dengan baik pula dengan dukungan bersama, dan oleh karena itu mempunyai rasa saling ketergantungan, rasa saling memiliki tim dalam melaksanakan tugas. 2. Para anggota menyumbang keberhasilan tim dengan menerapkan bakat dan pengetahuannya untuk sasaran tim, dapat bekerja dengan secara terbuka, dapat mengekspresikan gagasan, opini dan ketidaksepakatan, peranan dan pertanyaannya disambut dengan baik. 3. Para anggota berusaha mengerti sudut pandang satu sama lain, didorong untuk mengembangkan keterampilannya dan menerapkan pada pekerjaan, untuk itu mendapat dukungan dari tim. 4. Para anggota mengakui bahwa konflik adalah hal yang normal, atau hal yang biasa, dan berusaha memecahkan konflik tersebut dengan cepat dan konstruktif (bersifat memperbaiki). 5. Para anggota berpartisipasi dalam keputusan tim, tetapi mengerti bahwa pemimpin mereka harus membuat peraturan akhir setiap kali tim tidak berhasil membuat suatu keputusan, dan peraturan akhir itu bukan merupakan persesuaian. 5. Dimensi Tim yang Efektif Menurut Johnson dan Johnson (dalam Smither, Houston, dan Mclntire, 1996), ada 9 dimensi dalam model efektifitas tim yang dapat digunakan untuk mengevaluasi anggota tim dan mengidentifikasikan kekuatan serta kelemahan yang ada di dalam tim, yaitu: 1. Pemahaman, relevansi, dan komitmen pada tujuan Setiap anggota tim harus memahami tujuan tim secara jelas dan memiliki kemauan untuk mewujudkan tujuan-tujuan tim karena tujuan tim adalah merupakan hasil dari tujuan bersama dimana tujuan tim pada akhirnya akan mendorong terwujudnya kerjasama dalam tim sehingga kerjasama dalam tim 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id mampu untuk meningkatkan prestasi, produktivitas, dan menciptakan hubungan kerja yang positif diantara sesama anggotanya. 2. Komunikasi mengenai ide dan perasaan Komunikasi di antara anggota tim harus melibatkan penyampaian dan penerimaan informasi tentang ide-ide dan perasaan. Dalam tim yang tidak efektif, komunikasi sering satu arah dan memfokuskan secara eksklusif hanya pada ide saja. Dengan mengabaikan atau menekan perasaan, maka tim berisiko kehilangan informasi yang berharga dan dapat melemahkan kohesivitas tim. 3. Kepemimpinan yang berpartisipasi Kepemimpinan harus berpartisipasi dan mendistribusikan peran kepemimpinannya kepada semua anggota tim. 4. Fleksibel dalam menggunakan prosedur pembuatan keputusan Prosedur pengambilan keputusan harus sesuai dengan kebutuhan tim dan sifat keputusannya. Keterbatasan waktu, keterampilan anggota dan implikasi dari semua keputusan tim harus dinilai secara hati-hati. Sebagai contoh, ketika keputusan-keputusan penting dibuat maka akan membutuhkan dukungan dari anggota tim untuk mengimplementasikan dan melakukan strateginya dengan efektif. 5. Manajemen konflik yang konstruktif Tim yang tidak efektif sering mencoba untuk mengabaikan atau menekan konflik, sedangkan tim yang efektif dapat menggunakan konflik dengan cara yang konstruktif. Ketika dikelola dengan baik, konflik dapat menyebabkan pengambilan keputusan yang baik pula yakni memecahkan masalah dengan lebih kreatif, dan jumlah partisipasi anggota tim yang lebih tinggi. 6. Kekuasaan berdasarkan keahlian, kemampuan, dan informasi Anggota tim harus mampu mempengaruhi dan dipengaruhi oleh orang lain untuk mengkoordinasikan kegiatan tim. Kekuasaan dan saling mempengaruhi ini harus terwujudkan secara merata dalam tim. Apabila kekuasaan dan kegiatan saling mempengaruhi ini hanya dipusatkan pada beberapa orang anggota tim saja 2015 7 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id maka kemungkinan efektifitas tim, komunikasi dan kohesivitas tim akan menjadi berkurang. 7. Kohesi Tim Dalam tim yang kohesif, setiap anggota merasa saling menyukai antara satu sama lainnya dan merasa puas dengan keanggotaan tim mereka. Meskipun kohesi tidak mengarah kepada efektifitas namun ia memiliki peranan yang penting dalam mewujudkan tim yang efektif yaitu ketika ia dikombinasikan dengan dimensi lain dari efektifitas tim maka sebuah tim yang memiliki kohesivitas yang tinggi cenderung meningkatkan produktivitas. 8. Strategi pemecahan masalah Tim harus mampu mengenali masalah dan menghasilkan solusi secara tepat. Setelah solusinya diimplementasikan, tim harus mengevaluasi keefektifan dari solusi tersebut. Ketika sebuah tim mampu untuk mengenali masalah-masalah yang sering muncul dan menyelesaikannya dengan memberikan solusi yang tepat maka sebuah tim yang efektif juga akan mampu untuk mengidentifikasikan kemungkinan-kemungkinan masalah-masalah yang akan muncul dikemudian hari serta mampu memberikan solusi yang inovatif. 9. Efektivitas interpersonal Anggota tim harus mampu untuk berinteraksi dengan anggota tim lainnya secara efektif sehingga membuat efektifitas interpersonal anggota tim menjadi meningkat. Efektifitas interpersonal dapat diukur dengan menggabungkan konsekuensi tindakan anggota kelompok dengan tujuan anggota tim. Kecocokan antara tujuan anggota tim dan konsekuensi dari peningkatan perilaku mereka, maka membuat interpersonal efektifitas anggota tim juga juga menjadi meningkat. 6. Manfaat dan Fungsi Tim Kerja 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Richard Y. Chang & Mark J. Curtin (1998) menyatakan manfaat tim bagi individu dan tim bagi organisasi, yaitu: 1. Manfaat tim bagi individu 1) Pekerjaan lebih bervariasi 2) Lebih banyak kebebasan untuk membuat dan menindaklanjuti keputusan yang benar 3) Meningkatkan kesempatan untuk mempelajari keahlian baru 2. Manfaat tim bagi organisasi 1) Meningkatkan komitmen terhadap keputusan yang diambil 2) Meningkatkan produktivitas tim kerja 3) Lebih fleksibel dalam operasional kerja 4) Meningkatkan rasa tanggungjawab 7. Kekuatan Kerja Tim Team (tim) atau TEAM, bukanlah sekedar kata, melainkan juga merupakan akronim untuk suatu kebenaran yang dahsyat, yaitu Together Everyone Achieve More. Konsep dari tim ini terbentuk dari kata yang sering kita dengar berulang kali, yaitu sinergi. Kata sinergi ini berasal dari bahasa Yunani sunergos, ”sun” berarti bersama dan ”ergon” berarti bekerja. Sinergi berarti interaksi dari dua individu atau lebih atau kekuatan yang memungkinkan kombinasi tenaga mereka melebihi jumlah tenaga individu mereka. Kerja tim adalah kemampuan untuk bekerja sama menuju satu visi yang sama, kemampuan mengarahkan pencapaian individu ke arah sasaran organisasi. Itulah rangsangan yang memungkinkan orang biasa mencapai hasil yang luar biasa. Dalam kajian perilaku organisasi (organizational behavior), terdapat demonstrasi tentang bagaimana kerjasama dapat menghasilkan suatu hal yang luar biasa. Beberapa orang disuruh untuk membentuk beberapa tim yang beranggotakan lima orang, di mana setiap orang belum memiliki kemampuan untuk menganalisis bidang kerjasama tim dengan baik. Setiap orang dalam kelompok diminta untuk memberikan peringkat terhadap suatu hal berdasarkan urutan dari hal yang dianggap paling penting, sampai tidak penting. Setelah itu setiap pendapat dari setiap orang digabungkan untuk mendapatkan rata-rata 2015 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id peringkat untuk setiap kelompok. Apa yang terjadi? Kesimpulan rata-rata kelompok mendekati jawaban yang telah diberikan. Bahkan apabila hasil dari setiap kelompok disatukan dan diambil rata-ratanya, maka penilaian dari setiap kelompok hampir sama dengan penilaian para ahli di bidang tersebut. Demonstrasi nyata lain mengenai prinsip sinergi dapat kita lihat pula dalam kontes kuda penghela dalam kontes kuda penghela di suatu pekan raya kota. Kuda juara dalam kontes tersebut mampu menghela gerobak seberat 2.250 kilogram. Juara kedua sanggup menarik beban sebesar 2.000 kilogram. Dalam teori, berarti kedua kuda tersebut secara bersama-sama harus mampu menggerakkan maksimum 4.250 kilogram. Untuk uji coba teori tersebut, pemilik kedua kuda memadukan kedua kuda dan membebaninya dengan gerobak. Semua orang yang melihat terperangah. Kedua kuda tersebut mampu menarik beban seberat 6.000 kilogram, atau 1.750 kilogram lebih berat dibanding jumlah upaya yang mampu mereka lakukan sendiri-sendiri. Sinergi dapat dipakai untuk menyatukan tenaga individu, menutup keterbatasan individu, untuk menggandakan upaya individu, supaya sasaran yang lebih banyak dan lebih besar dapat dicapai. Referensi: 1. Astra Human resources Management. 2001. Jakarta, Astra International 2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and Management, New York, McGraw-Hill International Edition. 3. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media Group. 2015 10 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Manajemen Kualitas Suatu Proyek Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 13 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Kualitas suatu proyek menjadi elemen yang penting di dalam suatu proyek agar produk yang dihasilkan berkualitas Mahasiswa mengenal, memahami dan memiliki kemampuan membuat suatu proyek dengan kualitas yang baik Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Manajemen Kualitas Proyek 1. Manajemen Mutu Proyek Proyek Manajemen Mutu mencakup proses yang diperlukan untuk memastikan bahwa proyek akan memenuhi kebutuhan yang dilakukan. Ini mencakup "semua aktivitas dari fungsi manajemen keseluruhan yang menentukan kebijakan mutu, tujuan, dan tanggung jawab dan menerapkan mereka dengan cara seperti perencanaan mutu, jaminan mutu, pengendalian mutu, dan peningkatan kualitas, dalam sistem mutu". 1. Kualitas Perencanaan-mengidentifikasi standar kualitas yang relevan dengan proyek dan menentukan bagaimana memuaskan mereka. 2. Penjaminan Kualitas-mengevaluasi kinerja proyek secara keseluruhan secara teratur untuk memberikan keyakinan bahwa proyek akan memenuhi standar kualitas yang relevan. 3. Kontrol kualitas (Quality Control) - pemantauan proyek tertentu untuk menentukan apakah mereka sesuai dengan standar mutu yang relevan dan mengidentifikasi cara untuk menghilangkan penyebab kinerja yang tidak memuaskan. Proses ini berinteraksi satu sama lain dan dengan proses di bidang pengetahuan lain juga. Setiap proses mungkin melibatkan usaha dari satu atau lebih individu atau kelompok individu, berdasarkan kebutuhan proyek. Setiap proses umumnya terjadi setidaknya sekali dalam setiap tahapan proyek. Meskipun proses yang disajikan di sini sebagai elemen diskrit dengan antarmuka welldefined, dalam praktiknya mereka mungkin tumpang tindih dan berinteraksi dengan cara yang tidak rinci di sini. Pendekatan dasar untuk manajemen mutu yang dijelaskan dalam bagian ini dimaksudkan agar kompatibel dengan Organisasi Internasional untuk Standarisasi (ISO), sebagaimana tercantum dalam ISO 9000 dan 10000 serangkaian standar dan pedoman. Pendekatan umum juga harus kompatibel dengan a) pendekatan eksklusif untuk manajemen mutu seperti yang direkomendasikan oleh Deming, Juran, Crosby, dan lain-lain, dan b) pendekatan Nonproprietary seperti Total Quality Management (TQM), Continuous Improvement, dan lain-lain. Proyek manajemen mutu harus mengatasi baik manajemen proyek dan hasil proyek. Produk istilah generik yang sering digunakan, dalam kualitas literatur tentang, untuk merujuk ke baik barang dan jasa. Kegagalan untuk memenuhi persyaratan kualitas dalam dimensi baik dapat memiliki konsekuensi negatif yang serius untuk setiap atau semua stakeholder proyek. 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Memenuhi kebutuhan pelanggan dengan lembur tim proyek bisa menghasilkan konsekuensi negatif dalam bentuk gesekan karyawan meningkat. Rapat tujuan proyek jadwal oleh kesibukan pemeriksaan kualitas direncanakan dapat menghasilkan konsekuensi negatif ketika kesalahan tidak terdeteksi. Kualitas adalah "totalitas karakteristik suatu entitas yang menanggung pada kemampuannya untuk memuaskan kebutuhan lain atau tersirat" (2). Lain kebutuhan dan tersirat adalah input untuk kebutuhan proyek berkembang. Sebuah aspek penting dari manajemen mutu dalam konteks proyek ini adalah kebutuhan untuk mengubah kebutuhan tersirat menjadi persyaratan melalui cakupan manajemen proyek. Tim manajemen proyek harus berhati-hati untuk tidak membingungkan antara kualitas dengan grade. Grade adalah "sebuah kategori atau peringkat yang diberikan kepada badan usaha yang memiliki penggunaan fungsional yang sama tetapi karakteristik teknis yang berbeda" (3). Rendahnya kualitas selalu masalah, kadar rendah mungkin tidak. Sebagai contoh, sebuah produk perangkat lunak mungkin akan berkualitas tinggi (tidak ada bug yang jelas, manual dibaca) dan kadar rendah (sejumlah fitur yang terbatas), atau berkualitas rendah (banyak bug, kurang terorganisir dokumentasi pengguna) dan tinggi grade (fitur yang banyak) . Menentukan dan memberikan tingkat yang dibutuhkan baik kualitas dan kelas merupakan tanggung jawab dari manajer proyek dan tim manajemen proyek. Tim manajemen proyek juga harus menyadari bahwa manajemen mutu modern melengkapi manajemen proyek. Sebagai contoh, kedua disiplin menyadari pentingnya: 1. Kepuasan pelanggan-pengertian, mengelola, dan mempengaruhi kebutuhan sehingga harapan pelanggan terpenuhi. Hal ini membutuhkan kombinasi dari kesesuaian dengan persyaratan (proyek harus menghasilkan apa yang dikatakan itu akan menghasilkan) dan kesesuaian untuk digunakan (produk atau jasa yang dihasilkan harus memenuhi kebutuhan nyata). 2. Pencegahan ataau inspeksi atas biaya mencegah kesalahan yang terlalu jauh lebih sedikit daripada biaya mengoreksi mereka, seperti diungkapkan oleh inspeksi. 3. Tanggung jawab manajemen-keberhasilan membutuhkan partisipasi dari semua anggota tim, tetapi tetap tanggung jawab manajemen untuk menyediakan sumber daya yang dibutuhkan untuk sukses 4. Proses dalam fase-siklus yang berulang-rencana do-check-tindakan yang dijelaskan oleh Deming dan lain-lain sangat mirip dengan kombinasi fase dan proses dibahas dalam Bab 3, Manajemen Proses suatu Proyek. Selain itu, inisiatif peningkatan mutu 2015 3 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id dilakukan oleh organisasi khusus (misalnya, TQM, Continuous Improvement, dan lain-lain) dapat meningkatkan kualitas manajemen proyek serta kualitas produk proyek. Namun, ada perbedaan penting yang tim manajemen proyek harus menyadari-sifat sementara proyek berarti bahwa investasi dalam peningkatan kualitas produk, terutama cacat pencegahan dan penilaian, sering harus ditanggung oleh organisasi melakukan sejak proyek mungkin tidak cukup lama untuk menuai hasilnya terakhir. 2. Perencanaan Kualitas Perencanaan kualitas yang melibatkan mengidentifikasi standar kualitas yang relevan dengan proyek dan menentukan bagaimana memuaskan mereka. Ini adalah salah satu proses memfasilitasi kunci dalam perencanaan proyek dan harus dilakukan secara teratur dan secara paralel dengan proses perencanaan proyek lainnya. Sebagai contoh, perubahan dalam produk dari proyek yang diperlukan untuk memenuhi standar kualitas diidentifikasi mungkin memerlukan penyesuaian biaya atau jadwal, atau kualitas produk yang diinginkan mungkin memerlukan analisis risiko rinci tentang masalah diidentifikasi. Sebelum pembangunan Seri ISO 9000, kegiatan digambarkan di sini sebagai perencanaan mutu secara luas didiskusikan sebagai bagian dari jaminan mutu. Teknik-teknik perencanaan mutu dibahas di sini adalah yang paling sering digunakan pada proyek. Ada banyak orang lain yang mungkin berguna pada proyek-proyek tertentu atau dalam beberapa area aplikasi. Tim proyek juga harus menyadari salah satu prinsip dasar mutu modern kualitas manajemen direncanakan dalam, tidak diperiksa masuk. 1. Masukan untuk Perencanaan Kualitas • Kualitas kebijakan. Kebijakan mutu adalah "keseluruhan tujuan dan arah organisasi dalam hal mutu, sebagaimana dinyatakan secara resmi oleh 2015 4 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id manajemen puncak". Kebijakan mutu organisasi melakukan sering dapat diadopsi "sebagaimana adanya" untuk digunakan oleh proyek ini. Namun, jika organisasi melakukan tidak memiliki kebijakan mutu formal, atau jika proyek tersebut melibatkan beberapa organisasi yang melakukan (seperti dengan perusahaan patungan), maka tim manajemen proyek akan perlu untuk mengembangkan kebijakan mutu untuk proyek tersebut. Terlepas dari asal kebijakan mutu, tim manajemen proyek bertanggung jawab untuk memastikan bahwa para stakeholder proyek sepenuhnya menyadari hal itu. • Lingkup pernyataan. Pernyataan lingkup adalah masukan kunci untuk perencanaan mutu karena kiriman dokumen proyek besar, serta tujuan proyek yang berfungsi untuk menetapkan persyaratan stakeholder penting. • Produk deskripsi. Meskipun unsur-unsur deskripsi produk dapat diwujudkan dalam pernyataan ruang lingkup, deskripsi produk seringkali akan berisikan detil tentang masalah teknis dan masalah lainnya yang dapat mempengaruhi kualitas perencanaan. • Standar dan peraturan. Tim manajemen proyek harus mempertimbangkan standar aplikasi setiap daerah khusus atau peraturan yang dapat mempengaruhi proyek. • Proses output lainnya. Selain pernyataan lingkup dan deskripsi produk, proses di daerah pengetahuan lainnya dapat menghasilkan output yang harus dianggap sebagai bagian dari perencanaan mutu. Sebagai contoh, pengadaan perencanaan dapat mengidentifikasi persyaratan kualitas kontraktor yang harus tercermin dalam rencana manajemen mutu secara keseluruhan. 2. Alat dan Teknik Perencanaan Kualitas • Analisis manfaat/biaya. Proses perencanaan kualitas harus mempertimbangkan pengorbanan biaya manfaat. Manfaat utama dari memenuhi persyaratan kualitas pengerjaan ulang kurang, yang berarti produktivitas yang lebih tinggi, biaya lebih rendah, dan kepuasan stakeholder meningkat. Biaya utama memenuhi persyaratan kualitas adalah biaya yang terkait dengan kegiatan manajemen kualitas proyek. Jelas sekali dari disiplin manajemen mutu yang manfaat lebih besar daripada biaya. • Pembandingan. Pembandingan melibatkan membandingkan praktek proyek aktual atau yang direncanakan untuk orang-orang dari proyek lain untuk menghasilkan ideide untuk perbaikan dan untuk menyediakan sebuah standar yang digunakan untuk 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id mengukur kinerja. Proyek-proyek lain mungkin berada dalam organisasi untuk melakukan atau di luar itu, dan mungkin dalam wilayah aplikasi yang sama atau di negara lain. • Flowchart. Sebuah diagram menunjukkan bagaimana berkaitan. Flowchart 1. alir adalah berbagai teknik setiap elemen yang umum dari diagram yang suatu sistem digunakan dalam manajemen mutu meliputi: ➢ Diagram penyebab-akibat, juga disebut diagram Ishikawa atau diagram tulang ikan, yang menggambarkan bagaimana berbagai faktor yang mungkin terkait dengan potensi masalah atau efek. Gambar 8-2 adalah contoh umum diagram sebab-akibat. ➢ Sistem atau proses flow chart, yang menunjukkan bagaimana berbagai elemen dari suatu sistem saling berhubungan. Gambar 8-3 adalah contoh diagram alir proses untuk review desain. ➢ Flowchart dapat membantu tim proyek mengantisipasi apa dan dimana masalah kualitas mungkin terjadi, dan dengan demikian dapat membantu mengembangkan pendekatan untuk memperbaiki masalah tersebut. • Desain eksperimen. Desain eksperimen adalah metode statistik yang membantu mengidentifikasi faktor yang mungkin mempengaruhi variabel tertentu. Teknik ini paling sering diterapkan pada produk dari proyek (misalnya, desainer otomotif mungkin ingin menentukan kombinasi suspensi dan ban akan menghasilkan karakteristik perjalanan paling diinginkan dengan biaya yang wajar). Namun, juga dapat diterapkan untuk proyek masalah manajemen, seperti pengorbanan biaya dan jadwal. Misalnya, insinyur senior akan biaya lebih dari insinyur junior, tetapi juga dapat diharapkan untuk menyelesaikan pekerjaan yang ditugaskan dalam waktu kurang. Sebuah "percobaan" dirancang tepat (dalam hal ini, komputasi biaya proyek dan jangka waktu untuk berbagai kombinasi insinyur senior dan junior) sering akan memungkinkan penentuan solusi optimal dari sejumlah kasus yang relatif terbatas. • Biaya kualitas. Biaya kualitas mengacu pada biaya total dari semua upaya untuk mencapai produk/kualitas layanan, dan mencakup semua bekerja untuk memastikan kesesuaian dengan persyaratan, serta semua karya yang dihasilkan dari ketidaksesuaian dengan kebutuhan. Ada tiga jenis biaya yang terjadi: biaya 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id pencegahan, biaya penilaian, dan biaya kegagalan, di mana yang terakhir ini dipecah menjadi biaya internal dan eksternal. 3. Keluaran dari Kualitas Perencanaan • Rencana pengelolaan kualitas. Rencana manajemen mutu harus menjelaskan bagaimana tim manajemen proyek akan menerapkan kebijakan kualitasnya. Dalam ISO 9000 istilah, harus menjelaskan sistem kualitas proyek: "struktur organisasi, tanggung jawab, prosedur, proses, dan sumber daya yang dibutuhkan untuk menerapkan manajemen mutu". Rencana manajemen mutu memberikan masukan terhadap rencana proyek secara keseluruhan dan harus ditujukan pada pengendalian mutu, jaminan mutu, dan peningkatan kualitas proyek. Rencana manajemen mutu dapat formal maupun informal, sangat rinci, atau luas berbingkai, berdasarkan persyaratan proyek. • Operasional definisi. Definisi operasional menjelaskan, dalam hal yang sangat spesifik, apa sesuatu itu dan bagaimana ia diukur oleh proses kontrol kualitas. Sebagai contoh, tidak cukup untuk mengatakan bahwa pertemuan tanggal jadwal yang direncanakan adalah ukuran kualitas manajemen, tim manajemen proyek juga harus menunjukkan apakah setiap kegiatan harus mulai tepat waktu atau hanya selesai tepat waktu; apakah aktivitas individu akan diukur, atau hanya deliverables tertentu, dan jika demikian, yang mana. definisi operasional juga disebut metrik di beberapa area aplikasi. • Daftar pembanding. Checklist adalah alat terstruktur, biasanya unsur tertentu, digunakan untuk memverifikasi bahwa satu set langkah yang diperlukan telah dilakukan. Daftarpembanding mungkin sederhana atau kompleks. Mereka biasanya diungkapkan sebagai imperatif ("Lakukan ini!") Atau interrogatories ("Apakah Anda melakukan ini?"). Banyak organisasi telah daftar standar tersedia untuk memastikan konsistensi dalam tugas-tugas sering dilakukan. Di beberapa daerah aplikasi, daftar juga tersedia dari asosiasi profesional atau penyedia layanan komersial. • Masukan pada proses lainnya. Proses perencanaan mutu mengidentifikasi kebutuhan untuk kegiatan lebih lanjut di daerah lain. 3. Penjaminan Kualitas 2015 7 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id dapat Jaminan Kualitas adalah semua kegiatan yang terencana dan sistematis diterapkan dalam sistem mutu untuk menyediakan keyakinan bahwa proyek itu akan memenuhi standar mutu yang relevan. Hal ini harus dilakukan di seluruh proyek. Sebelum pembangunan Seri ISO 9000, kegiatan yang diuraikan di bawah kualitas perencanaan secara luas sebagai bagian dari jaminan kualitas. Jaminan Kualitas sering disediakan oleh Departemen Jaminan Kualitas atau suatu unit organisasi, tetapi tidak harus. Jaminan dapat diberikan kepada tim manajemen proyek dan pengelolaan organisasi bermasalah (jaminan mutu internal), atau mungkin diberikan kepada pelanggan dan orang lain tidak secara aktif terlibat dalam pekerjaan proyek (jaminan mutu eksternal). 1. Masukan untuk Jaminan Kualitas • Rencana manajemen kualitas. • Hasil pengukuran pengendalian kualitas. Kontrol kualitas adalah pengukuran catatan pengujian kontrol kualitas dan pengukuran dalam format untuk perbandingan dan analisis. • Definisi operasional. 2. Alat dan Teknik untuk Penjaminan Kualitas • Perencanaan kualitas alat dan teknik. • Quality audit. Suatu audit mutu adalah review kegiatan terstruktur lainnya manajemen mutu. Tujuan dari audit kualitas adalah untuk mengidentifikasi pelajaran yang dapat memperbaiki kinerja proyek ini atau proyek lain dalam organisasi pertunjukan. Kualitas audit dapat dijadwalkan secara acak, dan mereka dapat dilakukan dengan benar terlatih dalam-rumah auditor atau oleh pihak ketiga, seperti lembaga pendaftaran sistem kualitas. 3. Hasil dari Jaminan Kualitas 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id • Peningkatan kualitas. Peningkatan kualitas termasuk mengambil tindakan untuk meningkatkan efektivitas dan efisiensi dari proyek untuk memberikan manfaat tambahan bagi para pemangku kepentingan proyek. Dalam kebanyakan kasus, peningkatan kualitas pelaksanaan akan membutuhkan persiapan permintaan perubahan atau mengambil tindakan korektif, dan akan ditangani sesuai dengan prosedur pengendalian perubahan yang terintegrasi. 4. Pengendalian Mutu (quality control) Kendali mutu melibatkan hasil pemantauan proyek spesifik untuk menentukan apakah mereka memenuhi standar mutu yang relevan, dan mengidentifikasi cara untuk menghilangkan penyebab hasil yang tidak memuaskan. Ini harus dilakukan selama proyek. hasil proyek meliputi hasil produk keduanya, seperti kiriman, dan hasil manajemen proyek, seperti biaya dan kinerja jadwal. Kontrol kualitas sering dilakukan oleh Departemen Quality Control atau yang serupa pada unit organisasi, tetapi tidak harus. Tim manajemen proyek harus memiliki pengetahuan tentang pengendalian kualitas statistik, terutama sampling dan probabilitas, untuk membantu mengevaluasi output kontrol kualitas. Di antara mata pelajaran lainnya, tim mungkin berguna untuk mengetahui perbedaan antara: • Pencegahan (kesalahan menjaga dari proses) dan pemeriksaan (kesalahan menjaga dari tangan pelanggan). • Atribut Sampling (hasilnya sesuai, atau tidak) dan sampling variabel (hasilnya adalah nilai pada skala kontinu yang mengukur tingkat kesesuaian). • Khusus menyebabkan (kejadian luar biasa) dan menyebabkan acak (variasi proses normal). • Toleransi (hasilnya dapat diterima jika berada dalam kisaran yang ditentukan oleh toleransi) dan batas kontrol (proses ini dalam kendali jika hasilnya jatuh dalam batas-batas kontrol). Referensi: 1. A Guide to the Project Management Body of Knowledge. 2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and Management, New York, McGraw-Hill International Edition. 2015 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 3. Sutarto Wijono, 2010, Psikologi Industri & Organisasi, Jakarata, Kencana Prenada Media Group. 2015 10 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id MODUL PERKULIAHAN Manajemen Proyek Perangkat Lunak Analisa Waktu (SPA dan SPL) Fakultas Program Studi Fakultas Ilmu Komputer Informatika 2015 1 Tatap Muka 14 Kode MK Disusun Oleh 87025 Tim Dosen Abstract Kompetensi Analisa waktu diperlukan agar proyek perangkat lunak yang akan dijalankan sesuai dengan waktu yang telah ditentukan dan tidak mengalami keterlambatan Mahasiswa mengenal, memahami dan memiliki kemampuan untuk menganalisa waktu yang dibutuhkan di dalam sebuah proyek perangkat lunak Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 1. Analisa Waktu 1. Pendahuluan Alasan dilakukan analisa waktu dalam penerapan network planning pada penyelenggaraan proyek, antara lain: 1. Analisa waktu merupakan langkah pertama sebelum melakukan analisa lebih lanjut yaitu analisa sumber daya dan analisa biaya. 2. Untuk melakukan analisa waktu pada tahap perencanaan (disain model), data yang diperlukan relatif tidak terlalu sukar penyediaannya. 3. Untuk melakukan analisa waktu pada tahap pemakaian (operasi) pengumpulan dan pengolahan datanya relatif lebih mudah. Yang dimaksud dengan analisa waktu dalam penyelenggaraan proyek adalah mempelajari tingkah laku pelaksanaan kegiatan selama penyelenggaraan proyek. Dengan analisa waktu ini diharapkan bisa ditetapkan skala prioritas pada tiap tahap, dan bila terjadi perubahan waktu pelaksanaan kegiatan, segera bisa diperkirakan akibatakibatnya sehingga keputusan yang diperlukan dapat segera diambil. Ada beberapa tujuan analisa waktu, antara lain: 1. Dengan analisa waktu memungkinkan disesuaikannya umur perkiraan proyek dengan umur proyek yang direncanakan dengan cara yang rasional, sepanjang masih memungkinkan. 2. Umur rencana proyek dapat ditentukan lamanya sesuai dengan tingkat probabilitas yang dikehendaki. 3. Untuk menekan tingkat ketidakpastian dalam waktu pelaksanaan selama penyelenggaraan proyek, dengan demikian diharapkan timing yang tepat bisa ditentukan. Dan dengan menentukan timing yang tepat analisa sumber daya dan analisa biaya, segera bisa dilakukan. 4. Cara kerja yang efisien bisa diselenggarakan sehingga waktu penyelenggaraan menjadi efisien pula. 2. Faktor Penentu Lama Kegiatan 2015 2 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Lama kegiatan adalah jangka waktu yang dibutuhkan untuk menyelesaikan kegiatan yang bersangkutan, yaitu mulai dari saat awal pada saat kegiatan mulai dikerjakan sampai dengan saat akhir pada saat kegiatan selesai dikerjakan. Adapun satuan untuk mengukur lama kegiatan tergantung dari macam kegiatannya, bisa dalam detik, menit, jam atau hari, dan sebagainya. Ada 2 faktor penentu lama kegiatan, yaitu: 1. Faktor teknis, antara lain ; volume pekerjaan, sumber daya, ruangan, jam kerja per hari, dan sebagainya. 2. Faktor non teknis, antara lain ; banyaknya hari kerja dalam seminggu, banyaknya hari libur, cuaca, dan sebagainya. 3. Cara Menentukan Lama Kegiatan A. Cara rata-rata Cara rata-rata relatif mudah namun kurang tepat atau kurang memadai dikarenakan menyamaratakan tiap kasus meskipun pada kenyataannya masingmasing kasus terdiri dari tiap kasus yang berbeda-beda. Contoh: Diketahui: Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 6 kasus (alternatif), sebagai berikut: KASUS LAMA KEGIATAN (HARI) 1 2 3 4 5 6 10 11 12 13 14 15 Diminta: Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas. Jawab: Kasus Lama Kegiatan (Hari) Jumlah Kejadian 10 1 1 2015 3 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2 3 4 5 6 Jumlah 11 12 13 14 15 75 1 1 1 1 1 6 LPER = 75 / 6 = 12.5 hari B. Cara pembobotan Cara pembobotan relatif lebih tepat dibandingkan cara rata-rata, karena memperhatikan jumlah dan peran kejadian tiap kasus. Namun cara ini sukar karena perlu data yang relatif banyak. Contoh: Diketahui: Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 6 kasus dengan masing-masing kejadian, sebagai berikut: Kasus Lama Kegiatan (Hari) Jumlah Kejadian 10 11 12 13 14 15 100 200 350 500 250 100 1 2 3 4 5 6 Diminta: Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas. Jawab: Kasus 1 2 3 2015 4 Lama Kegiatan (Hari) 10 11 12 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Jumlah Kejadian 100 200 350 Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Bobot 10 * 100 = 1.000 11 * 200 = 2.200 12 * 350 = 4.200 4 5 6 LPER = 13 14 15 Jumlah Bobot = 500 250 100 1.500 18.900 Jumlah Peristiwa 13 * 500 = 6.500 14 * 250 = 3.500 15 * 100 = 1.500 18.900 = 12.6 hari 1.500 C. Cara lintasan kritis Cara lintasan kritis merupakan cara yang memiliki keuntungan dari kedua cara tersebut diatas, karena membutuhkan data relatif lebih sedikit tetapi tetap memperhatikan peran kejadian tiap kasus. Pertimbangan terakhir dalam penentuan cara yang akan dipakai, bergantung pada tersedianya data dan tingkat kebenaran data yang tersedia tersebut. Lama kegiatan hasil dari ketiga cara tersebut masing-masing disebut lama kegiatan perkiraan (LPER) dan masing-masing dianggap mempunyai kemungkinan berhasil 50% dan mempunyai kemungkinan gagal 50%. Contoh: Diketahui: Suatu pekerjaan dengan volume tertentu dapat diselesaikan dalam 3 kasus (tidak mungkin lebih atau kurang dari 3 kasus), sebagai berikut ; Kasus 1 (LO) 2 (LM) 3 (LP) Lama Kegiatan (Hari) 10 13 15 Jumlah Kejadian LO = Lama kegiatan optimis LM = Lama kegiatan most likely (yang paling sering terjadi) LP = Lama kegiatan pesimis Diminta: Hitung lama kegiatan perkiraan (LPER) pekerjaan diatas. Jawab ; LPER = 1 * LO + 4 * LM + 1 * LP 6 LPER = 1 * 10 + 4 * 13 + 1 * 15 = 12.8 6 2015 5 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Saat Paling Awal (SPA) Saat paling awal (SPA) maksudnya adalah saat paling awal suatu peristiwa mungkin terjadi, dan tidak mungkin terjadi sebelumnya. Penentuan SPA ini bertujuan untuk mengetahui saat paling awal mulai melaksanakan kegiatan-kegiatan yang keluar dari peristiwa yang bersangkutan. Ada beberapa syarat yang harus dipenuhi untuk menentukan atau menghitung saat paling awal semua peristiwa-peristiwa pada sebuah network diagram, antara lain; 1. Network diagram yang tepat telah tersedia. 2. Nomor-nomor peristiwa ditetapkan menurut atau memenuhi persyaratan yaitu peristiwa awal network diagram diberi nomor 1, peristiwa akhir diberi nomor maksimum yang sama dengan banyaknya peristiwa yang ada di network yang bersangkutan. 3. Semua kegiatan yang ada dalam network diagram telah ditetapkan lama kegiatan perkiraan. Secara formatif untuk menentukan saat paling awal suatu peristiwa adalah sebagai berikut: 1. Sebuah kegiatan menuju ke sebuah peristiwa Keterangan ; SPA j = SPA I + L X = Kegiatan j = Peristiwa akhir kegiatan X i = Peristiwa awal kegiatan X L = Lama kegiatan X yang diperkirakan SPA i = Saat paling awal peristiwa awal SPA j = Saat paling awal peristiwa akhir 2015 6 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id 2. Untuk beberapa kegiatan menuju ke sebuah peristiwa ditentukan waktu paling awal yang maksimum. SPA j = maksimum (SPA I + L) Prosedur untuk menghitung saat paling awal dalam sebuah network diagram adalah sebagai berikut: 1) Hitung atau tentukan saat paling awal dari peristiwa-peristiwa mulai dari nomor 1 berturut-turut sampai dengan nomor maksimum. 2) Pada posisi awal SPA (1) = 0 3) Pada setiap posisi j, SPA j = max (SPA i + L), untuk setiap posisi atau peristiwa i yang dihubungkan langsung oleh satu kegiatan dengan posisi j, contoh: Keterangan ; Pada posisi atau peristiwa 3 menuju posisi 6 terdapat jumlah waktu paling awal lebih maksimum dibandingkan dengan posisi atau peristiwa 4 menuju posisi 6, maka SPA j pada posisi atau peristiwa 6 adalah 14. 3. Saat Paling Lambat (SPL) 2015 7 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Saat paling lambat (SPL) adalah saat paling lambat suatu peristiwa boleh terjadi, dan tidak boleh sesudahnya (meskipun itu mungkin) sehingga proyek mungkin selesai pada waktu yang telah direncanakan. Adapun syarat yang harus dipenuhi agar bisa menentukan atau menghitung saat paling lambat (SPL) semua peristiwa-peristiwa pada sebuah network diagram adalah: • Telah tersedianya network diagram yang tepat. • Telah dihitung saat paling awal (SPA) dari posisi atau peristiwa awal (nomor 1) sampai dengan posisi akhir pada network diagram tersebut. • Jika hanya ada sebuah kegiatan keluar dari sebuah peristiwa, maka SPL (saat paling lambat) peristiwa tersebut adalah saat paling lambat mulainya kegiatan tersebut. Secara formulatif untuk menentukan saat paling lambat suatu peristiwa adalah sebagai berikut: 1. Untuk sebuah kegiatan keluar dari sebuah peristiwa Keterangan ; SPA i = SPA j - L X = Kegiatan j = Peristiwa akhir kegiatan X i = Peristiwa awal kegiatan X L = Lama kegiatan X yang diperkirakan SPA i = Saat paling awal peristiwa awal SPA j = Saat paling awal peristiwa akhir SPL i = Saat paling lambat peristiwa awal SPL j = Saat paling lambat peristiwa akhir 2. Untuk beberapa kegiatan keluar dari sebuah peristiwa ditentukan waktu paling lambat yang minimum 2015 8 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id SPL i = minimum (SPL j – L) Prosedur untuk menghitung saat paling awal dalam sebuah network diagram adalah sebagai berikut: 1) Hitung atau tentukan saat paling lambat (SPL) dari peristiwa-peristiwa mulai dari nomor maksimal kemudian mundur berturut-turut sampai dengan posisi awal. 2) Saat paling lambat (SPL) sama dengan Saat paling awal peristiwa akhir (maksimal), SPL j = SPA j 3) Pada setiap posisi i, SPL i = min (SPL j – L), untuk setiap posisi atau peristiwa j yang dihubungkan langsung oleh satu kegiatan dengan posisi I 4) Pada posisi awal SPL 1 = 0 Sedangkan Umur Proyek ditentukan oleh saat paling awal kegiatan yang paling awal mulai dikerjakan, yaitu SPA peristiwa awal network dengan dan ditentukan oleh saat paling awal kegiatan akhir yang paling akhir selesai, yaitu SPA peristiwa akhir network diagram dengan syarat SPA awal network diagram sama dengan nol, contoh: 2015 9 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id Keterangan ; 1) Pada posisi atau peristiwa posisi 2 menuju 3, maka SPL 2 = 9 – 5 = 4 2) Pada posisi atau peristiwa dari posisi 3 menuju posisi 4 lebih kecil jumlah waktu lambatnya (7 – 3 = 4) dibandingkan posisi atau peristiwa dari posisi 3 menuju posisi 6 (14 – 9 = 5), sehingga pada kasus tersebut SPL i pada posisi atau peristiwa 3 diambil waktu yang minimum adalah 4. Referensi: 1. A Guide to the Project Management Body of Knowledge. 2. Ivancevich, J.M., Konopaske, R and Matteson, MT., 2005, Organizational Behavior and Management, New York, McGraw-Hill International Edition. 2015 10 Manajemen Proyek Perangkat Lunak Hendra Prastiawan, S.Si., M.T Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id
![Modul Riset Advertising dan Marcomm [TM10]](http://s1.studylibid.com/store/data/000142912_1-88be32367fda1f7012482a2ad163e17b-300x300.png)