8. PROJECT SCHEDULING & TRACKING 8.1 Konsep Dasar 8.1.1 Penyebab Keterlambatan Proyek PL 8.1.2 Prinsip-prinsip Dasar 8.2 Hubungan Manusia dan Kerja 8.2.1 Contoh 8.2.2 Distribusi Effort 8.3 Penentuan Rangkaian Tugas Proyek PL 8.3.1 Rangkaian Tugas (Task Set) 8.3.2 Beberapa Tipe Proyek 8.3.3 Tingkat Kesulitan 8.3.4 Penentuan Kriteria Adaptasi 8.3.5 Penghitungan Nilai Task Set Selector 8.3.6 Contoh Perhitungan TSS 8.3.7 Contoh Perhitungan TSS utk Proyek Pengembangan Aplikasi Baru 8.3.8 Memilih Task-task Rekayasa PL 8.3.9 Contoh task-task utama rekayasa perangkat lunak 8.4 Rincian Task-task Utama 8.5 Penentuan Task Network 8.6 Penjadwalan 8.7 Project Plan

8.1 Konsep Dasar 8.1.1 Penyebab Keterlambatan Proyek PL Batas penyerahan yang tidak realistis yang ditetapkan oleh seseorang di luar grup rekayasa PL dan memaksakannya pada manajer dan praktisi dalam grup tsb. Perubahan kebutuhan pelanggan yang tidak tercermin dalam jadwal. Memandang rendah jumlah sumber daya yang akan diperlukan untuk mengerjakan pekerjaan tsb. Resiko-resiko yang dapat diprediksi dan/atau resiko-resiko yang tidak dapat diprediksi yang belum dipertimbangkan ketika proyek dimulai. Kesulitan-kesulitan teknis yang belum dapat diramalkan sebelumnya.

Kesulitan-kesulitan manusia yang tidak dapat diprediksi sebelumnya. Miskomunikasi di antara staf proyek yang mengakibatkan keterlambatan. Ketidakmampuan manajer proyek untuk mengetahui bahwa proyek tidak mengikuti jadwal dan tidak melakukan tindakan yang dapat mengatasi masalah tsb. Batas waktu yang agresif (tidak realistik) adalah sebuah kenyataan. Seringkali batas waktu tersebut ditetapkan berdasarkan alasan-alasan yang disetujui oleh orang yang menetapkan batas waktu tersebut, tetapi seharusnya juga disetujui oleh orang yang mengerjakannya.

8.1.2 Prinsip-prinsip Dasar Realitas RPL : ada ratusan tugas kecil yang harus dikerjakan untuk mencapai tujuan yang lebih besar. Tugas manajer proyek : menentukan tugas-tugas proyek, mengindentifikasi tugas-tugas yang kritis, dan menelusuri kemajuannya untuk memastikan bahwa penundaan dapat direorganisasi setiap hari. Solusi : manajer harus mempunyai jadwal yang telah ditetapkan dengan derajat resolusi yang memungkinkan manajer memonitor kemajuan dan mengontrol proyek tersebut. Penjadwalan proyek PL : suatu kegiatan mendistribusikan beban kerja terestimasi sepanjang durasi proyek yang telah direncanakan dengan mengalokasikan beban kerja pada tugas-tugas rekayasa PL. Prinsip-prinsip dasarnya sbb

Prinsip-prinsip Dasar Compartmentalization (pembagian). Proyek harus dibagi-bagi ke dalam sejumlah tugas dan aktivitas yang dapat ditangani. Untuk melakukan ini, baik produk maupun proses harus didekomposisi. Interdependency (saling ketergantungan). Saling ketergantungan dari setiap tugas dan aktivitas yang dibagi-bagi harus ditentukan. Beberapa tugas harus dikerjakan berurutan; yang lain dapat dikerjakan secara bersamaan. Beberapa kegiatan tidak dapat dimulai karena harus menunggu hasil dari kegiatan lain. Beberapa kegiatan lainnya dapat bekerja secara bebas.

Time allocation (alokasi waktu) Time allocation (alokasi waktu). Masing-masing tugas yang akan dijadwalkan harus dialokasikan dalam sejumlah satuan kerja (misalnya kerja orang-hari). Selain itu harus ditetapkan waktu mulai dan waktu selesai. Effort Validation (validasi kerja). Dengan alokasi waktu, manajer harus menjamin bahwa tidak terjadi alokasi yang melebihi jumlah staf yang ada dalam suatu waktu. Defined responsibilities (batasan tanggungjawab). Setiap tugas yang dijadwalkan harus ditugaskan kepada satu anggota tim tertentu. Defined outcomes (batasan keluaran). Setiap tugas yang dijadwalkan harus memiliki keluaran tertentu. Defined milestones (tonggak ukur). Setiap tugas atau grup tugas harus terkait dengan project milestone.

8.2 Hubungan Manusia dan Kerja 8.2.1 Contoh Misal ada 4 orang SE, masing-masing mampu menghasilkan 5000 LOC/th bila bekerja sendiri-sendiri dalam proyek individual. Bila ke-4 SE tersebut ditempatkan pada sebuah tim untuk proyek (mis 1 tahun) terdapat 6 jalur komunikasi. Masing-masing jalur komunikasi tsb butuh waktu yang harus disisihkan dari waktu membuat PL.

Krn overhead yang berkaitan dgn komunikasi untuk masing-masing jalur komunikasi diasumsikan produktivitas tim perjalur berkurang dengan 250 LOC/th. Produktivitas tim menjadi : 4*5000 – 6*250 = 18.500 LOC/th atau berkurang (1500/2000) x 100% = 7,5% dari yang diharapkan shg dpt menyebabkan proyek terlambat. Misal bila 2 bln sebelum penyerahan, ditambahkan lagi 2 SE shg jumlah jalur menjadi 14. Diasumsikan per SE tambahan: 840 LOC / 2 bln shg produktivitas tim menjadi : 4*5000 + 2*840 – 14*250 = 18.180 LOC/th (vs 18.500). Ini menunjukkan bahwa Jumlah Tenaga Kerja tidak memiliki hubungan linier dengan Produktivitas Kerja.

Suatu hubungan empirik yang menyatakan jumlah LOC (L) dengan effort (E) dan waktu pengembangan (t), adalah; L = P x (E/B)1/3 t4/3 dengan P adalah parameter produktivitas (antara 2000 sampai 28.000), B adalah faktor keahlian khusus (antara 0,16 sampai 0,39; lih 6.5.2.3). Bila persamaan tersebut ditata lagi akan diperoleh : E = L3/(P3t4) Misal sebuah proyek PL real time membutuhkan usaha 33.000 LOC dan 12 person-year. Bila 8 orang ditugaskan dalam tim, maka proyek akan terselesaikan kira-kira dalam 1,3 tahun. Tetapi jika waktu penyelesaian diulur 6 bln lagi (diselesaikan dalam 1,75 tahun) dengan rumus di atas diperoleh E = 3,8 person-year, artinya tenaga kerja dapat dikurangi hingga 4 orang saja. Mana yg menguntungkan?

8.2.2 Distribusi Effort Distribusi beban kerja yang dianjurkan dalam phase-phase definisi & pengembangan adalah 40 - 20 - 40; 40% atau lebih beban kerja dialokasikan untuk tugas-tugas front-end (analisis & design); 40% dipakai dalam back-end testing dan 20% untuk coding. Distribusi effort tergantung pada karakteristik proyek. Effort yang dihabiskan dalam perencanaan proyek jarang mencapai lebih dari 2% atau 3%. Analisis persyaratan-persyaratan dapat menghabiskan 10% sampai 25% effort. Sedangkan effort yang dihabiskan dalam analisis atau pembuatan prototype tergantung pada ukuran dan kompleksitas proyek; 20% s/d 25% biasanya dihabiskan untuk perancangan PL.

Karena beban kerja juga diberikan dalam software design, kesulitan-kesulitan yang akan dihadapi dalam coding juga akan berkurang; kisaran antara 15% s/d 20% dari effort keseluruhan dapat dicapai. Testing dilanjutkan dengan debugging dapat mencapai 30% s/d 40%. Kekritisan PL sering dipengaruhi oleh jumlah testing yang diperlukan. Untuk PL yang human-rated persentasenya bahkan lebih tinggi.

8.3. Penentuan Rangkaian Tugas Proyek PL 8.3.1 Rangkaian Tugas (Task Set) Sejumlah model proses: linier sequensial, iterative, evolutionary, dsb, penuh dengan sekumpulan task yang memungkinkan tim PL menentukan, mengembangkan, dan pada akhirnya memelihara PL komputer. Tidak ada satu set tunggal yang cocok untuk semua proyek. Oleh karena itu proses PL yang efektif harus menentukan sekumpulan task set, masing-masing dirancang untuk memenuhi kebutuhan-kebutuhan tipe proyek yang berbeda.

Task set adalah sekumpulan task-task pekerjaan rekayasa PL, milestones, dan deliverables yang harus dipenuhi untuk menyelesaikan proyek. Task set yang dipilih harus memberikan disiplin yang cukup untuk mencapai kualitas PL yang tinggi, tetapi harus tidak membebani tim proyek dengan kerja yang tidak perlu. Task set dirancang untuk mengakomodasi berbagai tipe proyek dan tingkat kesulitan (degree of rigor) yang berbeda.

8.3.2 Beberapa Tipe Proyek Proyek-proyek pengembangan konsep. Proyek-proyek pengembangan aplikasi baru. Proyek-proyek peningkatan kemampuan aplikasi yang sudah ada. Proyek-proyek perawatan aplikasi. Proyek-proyek reengineering.

8.3.3 Tingkat Kesulitan Degree of rigor (tingkat kesulitan) adalah suatu fungsi dari berbagai karakteristik proyek. Terdapat 4 degree of rigor. casual, structured, strict, quick reaction. Manajer proyek harus mengembangkan suatu cara yang sistematis untuk pemilihan degree of rigor yang sesuai untuk suatu proyek. Untuk memenuhi hal tersebut, kriteria adaptasi proyek didefinisikan dan nilai task set selector dihitung, sbb.

8.3.4 Penentuan Kriteria Adaptasi Kriteria adaptasi dipakai untuk menentukan degree of rigor bagi proses PL yang akan dipakai pada proyek. Sebelas kriteria adaptasi (grade 1-5) untuk proyek PL: ukuran proyek, jumlah user, kekritisan misi yang diemban, umur (lamanya) aplikasi tersebut akan dipakai, kestabilan dalam persyaratan, kemudahan komunikasi customer/developer, kemapanan (maturity) teknologi yang dipakai, kendala-kendala pada kinerja, karakteristik embedded/nonembedded, project staffing, dan reengineering factors.

Masing-masing kriteria adaptasi diberi grade antara 1 s/d 5 Masing-masing kriteria adaptasi diberi grade antara 1 s/d 5. Grade1 merepresentasikan suatu proyek yang membutuhkan subset yang kecil pada task-task proses dan persyaratan-persyaratan metodologi dan dokumentasi adalah minimal. Grade 5 merepresentasikan suatu proyek yang memiliki satu set task-task proses lengkap yang harus dipergunakan, seluruh persyaratan-persyaratan metode, dan dokumentasinya substansial.

8.3.5 Penghitungan Nilai Task Set Selector(TSS) Memilih task set yang sesuai untuk sebuah proyek dengan langkah-langkah berikut. Periksa masing-masing kriteria adaptasi dan beri grade yang sesuai berdasarkan karakteristik proyek. Periksa faktor bobot (nilai berkisar antara 0.8 s/d 1.2) yang diberikan pada masing-masing kriteria. Faktor bobot menunjukkan tingkat pentingnya (relatif) dari kriteria adaptasi tertentu pada tipe PL yang dibuat terhadap lingkungan lokal.

Grade * weighting_factor * entry_point_multiplier Kalikan grade dengan faktor bobot dan dengan entry point multiplier (bernilai 0 atau 1; yang menunjukkan relevansi kriteria adaptasi dengan tipe proyek) untuk tipe proyek yang sedang dikerjakan. Grade * weighting_factor * entry_point_multiplier Hitung task set selector dengan mengambil nilai rata-rata dari product. Lihat tabel berikut.

8.3.6 Contoh Perhitungan TSS

8.3.7 Contoh Perhitungan TSS untuk Proyek Pengembangan Aplikasi Baru

8.3.8 Memilih Task-task Rekayasa PL Untuk membuat jadwal proyek, task set harus didistribusikan pada garis waktu proyek. Task set tergantung pada tipe proyek dan degree of rigor. Masing-masing tipe proyek dapat didekati dengan menggunakan model proses (linier sekuensial, iterative, atau evolutionary). Dalam beberapa hal, suatu tipe proyek dapat beralih, secara perlahan, menuju tipe proyek lainnya (sebagai contoh, proyek pengembangan konsep baru dapat dilanjutkan menjadi proyek pengembangan aplikasi baru, dst).

8.3.9 Contoh task-task utama rekayasa perangkat lunak untuk pengembangan konsep adalah; concept scoping, preliminary concept planning, technology risk assessment, proof of concept, concept implementation, customer reaction to concept. Sifat dasar dari task-task pengembangan konsep adalah iterative. Bila model proses linier yang dipilih, maka dapat dilihat gambar berikut.

8.4 Rincian Task-task Utama Task-task utama dapat dipakai untuk menentukan jadwal makroskopik bagi suatu proyek. Jadwal makroskopik tersebut harus dirinci lagi untuk menghasilkan jadwal proyek terinci. Rincian tersebut dapat dimulai dengan mendekomposisi task-task utama ke dalam set-set subtask.

Contoh task refinement untuk proyek pengembangan konsep: concept scoping task, dengan menggunakan process design language. Tugas I.1 Penentuan Ruang Lingkup Konsep I.1.1 Mengindentifikasi kebutuhan, keuntungan, dan pelanggan potensial I.1.2 Menentukan kejadian output/kontrol dan input yang diharapkan, yang mengendalikan aplikasi Memulai Tugas I.1.2 I.1.2.1 Mengkaji deskripsi kebutuhan yang ditulis I.1.2.2 Memperoleh daftar output/input yang tampak pada dokumen dst ..........

8.5 Penentuan Task Network Task-task dan subtask-subtask mempunyai saling ketergantungan berdasarkan pada urutan pengerjaannya. Selain itu bila lebih dari satu orang bekerja pada proyek tersebut, ada kemungkinan task-task dikerjakan secara paralel, task konkuren ini harus dikoordinasikan. Task network adalah representasi grafis dari aliran task untuk suatu proyek.

Contoh Task Network

8.6 Penjadwalan Penjadwalan proyek PL tidak berbeda dengan penjadwalan multitask engineering effort lainnya. Tool-tool & teknik-teknik umum untuk penjadwalan proyek dapat dipakai untuk proyek PL dengan sedikit modifikasi. Program Evaluation and Review Technique (PERT) dan Critical Path Method (CPM) adalah dua metoda penjadwalan proyek yang dapat dipakai pada proyek pengembangan PL.

Tracking the Schedule Tracking dapat dipenuhi dengan sejumlah cara yang berbeda. Adakan pertemuan berkala untuk membahas status proyek; setiap anggota tim melaporkan kemajuan dan masalah-masalah yang dihadapi. Evaluasi hasil semua review yang dilakukan selama proses rekayasa PL. Tentukan apakah formal project milestone telah dipenuhi sesuai dengan tanggal yang telah terjadwal? Bandingkan waktu mulai sebenarnya dengan waktu mulai terjadwal untuk masing-masing proyek task. Pertemuan informal dengan para praktisi untuk mendapatkan penilaian subyektifnya atas kemajuan saat itu dan problem-problem yang tampak.

8.7 Project Plan Setiap langkah dalam proses rekayasa PL harus menghasilkan suatu hasil kerja yang dapat diperiksa dan dapat bertindak sebagai dasar untuk langkah berikutnya. Software project plan dihasilkan di akhir dari planning tasks. Dia memberikan informasi tentang cost dan jadwal yang akan dipakai selama proses rekayasa PL.

Project Planning Content Pendahuluan Tujuan Rencana Ruang Lingkup dan Tujuan Proyek Pernyataan Ruang Lingkup Fungsi-Fungsi Utama Isu-isu Kinerja Batasan Manajemen dan Teknis Estimasi Proyek Data Historis yang Digunakan untuk Estimasi Teknik-teknik Estimasi Estimasi Usaha, Biaya, Durasi Strategi Manajemen Risiko Tabel Risiko Pembahasan Risiko untuk Dikelola Rencana RMMM untuk setiap Risiko Jadwal Sumber Daya Proyek Staf Organisasi Pelacakan dan Mekanisme Kontrol Lampiran ***