8. PROJECT SCHEDULING &
TRACKING
8.1
8.1 Konsep DasarKonsep 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
8.4 Rincian Task-task UtamaRincian Task-task Utama
8.5
8.5 Penentuan Task NetworkPenentuan Task Network
8.6 Penjadwalan
8.7
8.1 Konsep Dasar
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 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
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
Prinsip-prinsip Dasar
1. Compartmentalization (pembagian). Proyek harus
dibagi-bagi ke dalam sejumlah tugas dan aktivitas yang dapat ditangani. Untuk melakukan ini, baik produk
maupun proses harus didekomposisi.
2. 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.
3. 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.
4. Effort Validation (validasi kerja). Dengan alokasi waktu,
manajer harus menjamin bahwa tidak terjadi alokasi yang melebihi jumlah staf yang ada dalam suatu waktu.
5. Defined responsibilities (batasan tanggungjawab).
Setiap tugas yang dijadwalkan harus ditugaskan kepada
satu anggota tim tertentu.
6. Defined outcomes (batasan keluaran). Setiap tugas
yang dijadwalkan harus memiliki keluaran tertentu.
7. Defined milestones (tonggak ukur). Setiap tugas atau
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.
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
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
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
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.
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.
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
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.
8.3.3 Tingkat Kesulitan
Degree of rigor (tingkat kesulitan) adalah suatu fungsi dari berbagai karakteristik proyek.
Terdapat 4 degree of rigor.
o casual,
o structured, o strict,
o quick reaction.
Manajer proyek harus mengembangkan suatu cara yang sistematis untuk pemilihan degree of rigor yang sesuai untuk suatu proyek.
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
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
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
• 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
A d a p t a t i o n C r it e r ia
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
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.
P r o j e c t
D e f i n i t i o n P l a n n i n g
E n g i n e e r i n g /
C o n s t r u c t i o n R e l e a s e
C u s t o m e r E v a l u a t i o n
C o n c e p t d e v e l o p m e n t 1 . 1 C o n c e p t s c o p i n g
1 . 2 P r e l i m i n a r y c o n c e p t p l a n n i n g 1 . 3 T e c h n o l o g y r i s k a s s e s s m e n t
1 . 4 P r o o f o f c o n c e p t
1 . 5 C o n c e p t i m p l e m e n t a t i o n
1 . 6 C u s t o m e r r e a c t i o n
N e w A p p l i c a t i o n D e v e l o p m e n t P r o j e c t s
A p p l i c a t i o n E n h a n c e m e n t P r o j e c t s
P r o je c t D e f in i t io n
P la n n in g
E n g in e e r in g / C o n s t r u c t io n
R e le a s e C u s t o m e r
E v a lu a t io n
C u s t o m e r r e a c t io n C o n c e p t s c o p i n g
P r e li m in a r y c o n c e p t p l a n n in g T e c h n o lo g y r i s k a s s e s s m e n t
P r o o f o f c o n c e p t
8.4 Rincian Task-task Utama
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
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
8.5 Penentuan Task Network
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.
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
W o r k t a s k s w e e k 1 w e e k 2 w e e k 3 w e e k 4 w e e k 5
1 . 1 . 1 I d e n t i f y n e e d a n d b e n e f i t s M e e t w i t h c u s t o m e r s
I d e n t i f y n e e d s a n d p r o je c t c o n s t r a i n t s E s t a b l i s h p r o d u c t s t a t e m e n t
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
8.7 Project Plan
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
Project Planning Content
Project Planning Content
I.
I. PendahuluanPendahuluan
A.
A. Tujuan RencanaTujuan Rencana
B.
B. Ruang Lingkup dan Tujuan ProyekRuang Lingkup dan Tujuan Proyek
1.
1. Pernyataan Ruang LingkupPernyataan Ruang Lingkup
2.
2. Fungsi-Fungsi UtamaFungsi-Fungsi Utama
3.
3. Isu-isu KinerjaIsu-isu Kinerja
4.
4. Batasan Manajemen dan TeknisBatasan Manajemen dan Teknis
II.
II. Estimasi ProyekEstimasi Proyek
A.
A. Data Historis yang Digunakan untuk EstimasiData Historis yang Digunakan untuk Estimasi
B.
B. Teknik-teknik EstimasiTeknik-teknik Estimasi
C.
C. Estimasi Usaha, Biaya, DurasiEstimasi Usaha, Biaya, Durasi
III.
III. Strategi Manajemen RisikoStrategi Manajemen Risiko
A.
A. Tabel RisikoTabel Risiko
B.
B. Pembahasan Risiko untuk DikelolaPembahasan Risiko untuk Dikelola
C.
C. Rencana RMMM untuk setiap RisikoRencana RMMM untuk setiap Risiko
IV.
IV. JadwalJadwal
V.
V. Sumber Daya ProyekSumber Daya Proyek
VI.
VI. Staf OrganisasiStaf Organisasi
VII.
VII. Pelacakan dan Mekanisme KontrolPelacakan dan Mekanisme Kontrol
VIII.
VIII. LampiranLampiran
***
