Project Scheduling Tugas Matakuliah SDI
Aris Andriyani (110400075) Astrini Ranuem (110400076) Immar Pertawijaya (110400082) Wiradika Adi Wijaya (110400099)
PROJECT SCHEDULING
1. Konsep Dasar Beberapa penyebab keterlambatan penyelesaian proyek: 1. Deadline yang tidak realistis, menekan tim proyek 2. Perubahan kebutuhan konsumen 3. Kesalahan dalam mendeskripsikan tugas dan penentuan jumlah SDM yang dibutuhkan 4. Tidak mempertimbangkan resiko 5. Kesulitan teknis 6. Kesulitan personil 7. Miscommunication antara staf proyek 8. Kegagalan managemen proyek menyadari bahwa proyek dijalankan tidak sesuai jadwal dan kurangnya tindakan untuk memperbaiki masalah.
Tim software harus ditanya dalam menentukan deadline yang realistis sehingga dapat di diagnosa instrumen untuk diperkenalkan ke pasar. Setelah diukur dan dianalisis resikonya, dapat ditentukan kesimpulannya, software yang diminta membutuhkan berapa lama untuk dibuat dengan staf yang sesuai.
2. Project Scheduling Software projecy scheduling adalah sebuah kegiatan untuk mengukur rencana pelaksanaan proyek dengan membagi tugas secara spesifik dari software engineering. Macroscopic schedule perlu dibuat di awal perencanaan projek untuk mengidentifikasi seluruh process utama dan fungsi dari produk. Setelah macroscopic schedule dibuat disaring lagi menjadi jadwal yang lebih mendetail. Seorang proyek manager harus menentukan semua tugas dari proyek, bangun jaringan yang menunjukkan keterhubungan, identifikasi tugas yang harus didahulukan diantara kegiatan yang lain.
2.1. Basic Principles 1. compartmentalization (Pembagian). Proyek harus dibagi-bagi ke dalam sejumlah tugas & aktifitas yang dapat dikendalikan untuk dapat menyelesaikan semua permasalahan yang ada (melakukan dekomposisi masalah). 2. interpendency (Saling Ketergantungan ). Adanya saling ketergantungan dari setiap tugas & aktifitas yang dibagi harus ditentukan dari awal penjadwalan proyek 3. Time allocation (Alokasi Waktu ). Setiap tugas yang akan dijadwalkan harus dialokasikan kedalam sejumlah satuan kerja 4. effort validation (Validasi Kerja ). Setiap proyek memiliki staff tertentu, dimana pada saat pembagian tugas, harus dipastikan bahwa tidak akan kelebihan alokasi waktu atau jumlah SDM pada saat tertentu. 5. defined responsibilty. Setiap tugas yang telah dijadwalkan harus ditugaskan pada setiap member dalam tim. 6. defined outcomes. Setiap tugas yang telah dijadwalkan harus dipastikan hasilnya( produk atau bagian dari produk). 7. define milestone.Setiap tugas harus dikaitkan dengan inti dari proyek. Inti dari proyek terpenuhi ketika satu atau lebih produk telah di review kualitasnya dan disetujui.
2.2. the relationship between people and effort Dalam proyek pengembangan software yang kecil, seseorang bisa menganalisis kebutuhan, mendesign, mengenerate kode dan menghubungkan tes. untuk proyek yang semakin besar membutuhkan banyak orang untuk dilibatkan. Produktifitas tidak berbanding lurus dengan jumlah orang yang mengerjakan tugas. Seringkali hal tersebut diatasi dengan solusi penambahan personal pada akhir proyek, namun solusi ini dikhawatirkan dapat menyebabkan adanya overhead komunikasi antar personal dalam proyek karena terlalu banyak personal yang terlibat dalam proyek. Kurva 27.1 menunjukkan usaha dalam proyek sebagai fungsi dari waktu penyampaian.
Suatu proyek tim memiliki estimasi usaha Ed untuk mencapai watu penyampaian td. Hal tersebut menunjukkan jadwal dan sumber daya yang sudah optimal. Penyampaian suatu proyek tidak bisa kurang dari 0,75 td karena akan meningkatkan resiko kegagalan. Hubungan antara waktu penyelesaian proyek dengan usaha dapat dituliskan dalam fungsi: L= P X E1/3t4/3 L= hubungan P= produktivitas E= effort (person- year) t= durasi proyek
2.3. Effort Distribution distribusi usaha (effort distribution) yang direkomendasikan di seluruh proses perangkat lunak sering disebut sebagai 40-20-40 Rule. 40% dari semua usaha dialokasikan untuk analisis dan desain front-end. 40% untuk pengujian back-end. 20% untuk coding. Karakteristik dari tiap project menentukan/mendikte distribusi usaha. Perencanaan proyek (project planning) membutuhkan tidak lebih dari 2-3% usaha, kecuali perencanaan organisasi berkomitmen untuk pengeluaran besar dengan resiko tinggi. Komunikasi pelanggan (customer communication) dan analisa kebutuhan (requirements analysis) terdiri dari 10-25% dari usaha proyek (project effort). Usaha yang dikeluarkan pada analisis atau prototipe harus meningkat proposional secara langsung dengan ukuran dan kompleksitas proyek. 20-25% dari usaha, umumnya diterapkan pada desain software. Waktu yang dihabiskan untuk design review dan iterasi berikutnya juga harus diperhatikan.
Karena usaha diterapkan pada software design, pengkodean harus mengikuti dengan tingkat kesulitan yang relatif kecil. 15-20% dari keseluruhan usaha dapat dicapai. Pengujian (testing) dan debugging selanjutnya terhitung 30-40% dari usaha pengembangan perangkat lunak (software develompent effort). Tingkat kritikal dari software sering menentukan jumlah pengujian/testing yang dibutuhkan.
3.
mendefinisikan satu set tugas untuk proyek perangkat lunak (defining a task set for the software project) terlepas dari model proses yang dipilih, pekerjaan yang dilakukan oleh tim software dicapai melalui
serangkaian
tugas
yang
memungkinkan
Anda
untuk
mendefinisikan,
mengembangkan, dan mendukung software komputer. Tidak ada rangkaian tugas tunggal yang cocok untuk semua proyek. Rangkaian tugas yang akan sesuai untuk sebuah sistem kompleks yang besar kemungkinan akan dianggap berlebihan, produk software relatif sederhana. Oleh karena itu, proses perangkat lunak yang efektif harus mendefinisikan kumpulan rangkaian tugas, masing-masing dirancang untuk memenuhi kebutuhan berbagai jenis proyek. rangkaian tugas adalah kumpulan dari tugas rekayasa perangkat lunak, tonggak, produk kerja, dan jaminan kualitas yang harus dilakukan untuk menyelesaikan suatu proyek tertentu. rangkaian tugas harus memberikan kedisiplinan yang cukup untuk mencapai kualitas software yang tinggi. namun, pada saat yang sama, tidak seharusnya tim proyek menanggung pekerjaan yang tidak diperlukan. dalam rangka untuk mengembangkan jadwal proyek (project schedule), rangkaian set tugas harus didistribusikan pada garis waktu proyek (project time line). rangkaian tugas akan tergantung pada jenis proyek dan tingkat ketelitian tim software yang telah diputuskan. meskipun sulit untuk mengembangkan taksonomi komprehensif dari jenis proyek perangkat lunak, kebanyakan organisasi software menghadapi proyek berikut: 1. proyek pembangunan konsep yang dimulai untuk menjelajahi/mengeksplor beberapa konsep bisnis baru atau aplikasi dari beberapa teknologi baru 2. proyek pengembangan aplikasi baru yang dilakukan sebagai konsekuensi dari permintaan pelanggan yang spesifik
3. proyek peningkatan aplikasi yang terjadi ketika software yang sudah ada mengalami modifikasi besar untuk fungsi, kinerja, atau interface yang diamati oleh pengguna akhir (end user) 4. proyek pemeliharaan aplikasi yang mengoreksi, mengadaptasi, atau memperpanjang software yang ada dengan cara-cara yang mungkin tidak secepatnyaa jelas bagi pengguna akhir 5. proyek rekayasa yang dilakukan dengan maksud membangun kembali (warisan) sistem yang sudah ada secara keseluruhan atau sebagian bahkan dalam jenis proyek tunggal, banyak faktor yang mempengaruhi tugas yang ditetapkan untuk dipilih. ini meliputi: ukuran proyek, jumlah pengguna yang potensial, kekritisan misi, usia aplikasi (application longevity), stabilitas kebutuhan, kemudahan pelanggan / komunikasi pengembang/developer, kematangan teknologi yang berlaku, kendala performansi, karakteristik tertanam dan tidak tertanam, staf proyek, dan faktor rekayasa ulang. Ketika diambil dalam kombinasi, faktor-faktor ini memberikan indikasi dari tingkat ketelitian dengan proses software yang harus diterapkan.
3.1. satu set tugas contoh (a task set example) proyek pengembangan konsep yang dimulai ketika potensi untuk beberapa teknologi baru harus dieksplorasi. Belum ada kepastian bahwa teknologi akan berlaku/diterapkan, tetapi pelanggan (misalnya, marketing) percaya bahwa manfaat potensial masih ada. Proyek pengembangan konsep dapat dicapai dengan menerapkan tindakan berikut: 1.1 Konsep Penjajakan (concept scoping) menentukan ruang lingkup proyek secara keseluruhan 1.2 Perencanaan konsep awal (preliminary concept planning) menetapkan kemampuan organisasi untuk melakukan pekerjaan tersirat dari ruang lingkup proyek (project scope) 1.3 penilaian risiko Teknologi (technology risk assessment) mengevaluasi risiko yang berkaitan dengan teknologi yang akan dilaksanakan sebagai bagian dari ruang lingkup proyek (project scope) 1.4 pembuktian konsep (proof of concept) menunjukkan kelangsungan hidup teknologi baru dalam konteks perangkat lunak/software
1.5 Implementasi Konsep (concept implementation) menerapkan representasi konsep dengan cara yang dapat ditinjau oleh pelanggan dan digunakan untuk "pemasaran" yang bertujuan ketika konsep harus dijual kepada pelanggan atau manajemen lainnya 1.6 Reaksi Pelanggan (customer reaction) dengan konsep mengumpulkan feedback pada konsep teknologi baru dan menargetkan aplikasi pelanggan yang spesifik 1.7 Sebuah pengamatan/scan cepat dari tindakan ini harus menghasilkan beberapa kejutan. Bahkan, aliran rekayasa perangkat lunak untuk proyek-proyek pengembangan konsep sedikit lebih dari akal sehat.
3.2. Penyempurnaan Rekayasa Perangkat Lunak Tindakan (refinement of software engineering actions) Tindakan rekayasa perangkat lunak yang dijelaskan di bagian sebelumnya dapat digunakan untuk menentukan jadwal makroskopik untuk sebuah proyek. Namun, jadwal makroskopik harus disempurnakan untuk membuat jadwal proyek secara rinci. Perbaikan dimulai dengan mengambil setiap tindakan dan mendekomposisikannya menjadi serangkaian tugas. Sebagai contoh dekomposisi tugas, pertimbangkan Aksi 1.1, perbaikan Konsep Penjajakan Tugas dapat dicapai dengan menggunakan format garis besar (outline format), tetapi dalam buku ini, pendekatan bahasa desain proses digunakan untuk menggambarkan aliran dari tindakan ruang lingkup konsep Definisi Tugas: Tindakan 1.1 Konsep doping 1.1.1 Mengidentifikasi kebutuhan, manfaat dan pelanggan potensial 1.1.2 Tentukan keluaran / kontrol yang diinginkan dan masukan peristiwa yang mendorong aplikasi: Memulai tugas 1.1.2 1.1.2.1 TR: mengulas/review penjelasan tertulis tentang kebutuhan 1.1.2.2 Turunkan daftar pelanggan yang terlihat output / input 1.1.2.3 TR: review output
/ input dengan pelanggan dan merevisi yang diperlukan:
EndTask tugas 1.1.2 1.1.3 Mendefinisikan fungsi / perilaku untuk setiap fungsi utama: Memulai tugas 1.1.3 1.1.3.1 TR: review Output dan input data object diturunkan dalam tugas 1.1.2;
1.1.3.2 Turunkan model fungsi / perilaku; 1.1.3.3 TR: review fungsi / perilaku dengan pelanggan dan merevisi yang diperlukan; EndTask tugas 1.1.3 1.1.4 Isolasi unsur-unsur teknologi yang akan diimplementasikan dalam perangkat lunak; 1.1.5 Penelitian ketersediaan perangkat lunak yang ada; 1.1.6 Menentukan kelayakan teknis; 1.1.7 Membuat perkiraan ukuran dengan cepat; 1.1.8 Membuat definisi ruang lingkup; EndTask Definisi: Tindakan 1.1 Tugas dan subtasks tercatat dalam perbaikan bentuk dasar proses desain bahasa untuk jadwal rinci untuk tindakan ruang lingkup konsep
4.
Mendefinisikan Jaringan Tugas (defining a task network) Tugas individu dan subtasks memiliki ketergantungan berdasarkan urutan mereka. Selain itu, ketika lebih dari satu orang yang terlibat dalam proyek rekayasa perangkat lunak, ada kemungkinan bahwa kegiatan pembangunan dan tugas akan dilakukan secara paralel. Ketika ini terjadi, tugas yang bersamaan harus dikoordinasikan sehingga mereka menjadi lengkap ketika nantinya tugas mengharuskan produk dari kinerja mereka Sebuah jaringan tugas, juga disebut jaringan kegiatan, adalah representasi grafis dari aliran tugas untuk sebuah proyek. Hal ini kadang-kadang digunakan sebagai mekanisme melalui mana urutan tugas dan dependensi input ke alat penjadwalan proyek otomatis. Dalam bentuk yang paling sederhana (digunakan saat membuat jadwal makroskopik), jaringan tugas menggambarkan tindakan rekayasa perangkat lunak utama. Sifat konkruen dari software mengarah ke angka dari kenutuhan penjadwalan penting. Karena tugas serupa terjadi asynchronous, Anda harus menentukan intertask dependensi untuk memastikan kemajuan yang berkelanjutan menuju penyelesaian. Selain itu, Anda harus menyadari tugas-tugas yang terletak pada jalur kritis. Artinya, tugas yang harus diselesaikan pada jadwal jika proyek secara keseluruhan akan selesai sesuai jadwal. Dalam sebuah jaringan tugas rinci (pendahulu untuk jadwal rinci), setiap tindakan yang ditunjukkan pada gambar akan diperluas. Misalnya, Tugas 1.1 akan diperluas untuk menampilkan semua tugas yang rinci dalam penyempurnaan Tindakan 1.1
5.
Scheduling Beberapa hal yang menjadi aspek penting dalam scheduling antara lain adalah sebagai berikut. 1. Jaringan Tugas (jaringan aktivitas) adalah representasi grafis dapat dari tugas yang saling ketergantungan dan dapat membantu menentukan jadwal kasar untuk proyek tertentu 2. Penjadwalan alat harus digunakan untuk menjadwalkan setiap proyek non-sepele. 3. Evaluasi program dan teknik tinjauan (PERT) dan metode jalur kritis (CPM)) adalah teknik
kuantitatif
yang
memungkinkan
perencana
perangkat
lunak
untuk
mengidentifikasi rantai tugas tergantung pada proyek struktur rincian kerja (WBS) yang menentukan durasi waktu proyek. 4. Timeline (Gantt) grafik memungkinkan perencana perangkat lunak untuk menentukan tugas-tugas apa yang akan perlu dilakukan pada titik waktu tertentu (berdasarkan perkiraan untuk usaha, waktu mulai, dan durasi untuk setiap tugas). 5. Indikator terbaik dari kemajuan penyelesaian dan sukses review produk kerja perangkat lunak didefinisikan. 6. Time-Boxing adalah praktek memutuskan apriori jumlah waktu yang tetap yang dapat dihabiskan untuk setiap tugas. Ketika batas waktu tugas itu terlampaui, pengembangan pindah ke tugas berikutnya (dengan harapan bahwa sebagian besar pekerjaan penting selesai sebelum waktu habis).
5.1. Timeline Chart Ketika membuat schedule dalam proyek pembuatan software, terdiri dari serangkaian tugas. Time Ine chart merupakan alat peraga visual yang bermanfaat dalam pembebanan dan penjadwalan. Menunjukan penggunaan sumber daya, seperti pusat kerja dan tenaga kerja.
5.2. Tracking The Schedule Jika Project schedule telah terbentuk akan menjadi sebuah roda map yang mendefinisakan rincian tugas penting untuk tinjau dan di kontrol sebagai proses proyek. Tracking dapat di capai dengan beberapa cara yang berbeda, Yaitu:
Melakukan meeting secara periodik yang mana setiap anggota tim melaporkan perogress dan masalah secara berkala.
Evaluasi hasil dari semua review sepanjang proses software engineering
Memastikan apakah tugas-tugas penting dalam telah tercapai dalam schedule date
Membandingkan proses yang sebenarnya terjadi dengan rencana proses dalam schedul untuk masing-masing proyek pada Resources Table
Meeting informally dengan praktisi untuk memperoleh peniliaian subjektif dari progres dan masalah on The horizon
Menggunakan earned value analysis untuk mengakses progres secara kuantitatif.
5.3. Tracking Increment Progress for OO Projects
Technical milestone: OO analysis complete o Semua kelas hirarki didefinisikan dan ditijau ulang o Kelas atribut dan operasi didefinisikan dan ditinjau ulang o hubungan Class didefinisikan dan ditinaju ulang o Model perilaku didefinisikan dan ditinjau ulang o Reusable digolongkan dan diidentifikasi
Technical milestone: OO design complete
o Subsistem didefinisikan dan ditinjau ulang o Kelas dialokasikan untuk subsistem dan ditinjau ulang o Alokasi Tugas o telah ditetapkan dan ditinjau ulang o Tanggung jawab dan kolaborasi telah diidentifikasi o Atribut dan operasi telah dirancang dan ditinjau ulang o Model komunikasi telah dibuat dan ditinjau ulang
Technical milestone: OO programming complete o Setiap desain kelas model baru telah diterapkan o Kelas diekstraksi dari perpustakaan reuse telah dilaksanakan o Prototipe atau kenaikan telah dibangun
Technical milestone: OO testing complete o kebenaran dan kelengkapan OOA dan OOD model telah ditinjau o jaringan Kelas-tanggung-kolaborasi telah dikembangkan dan ditinjau o Uji kasus dirancang dan tes tingkat kelas telah dilakukan untuk setiap kelas o Uji kasus dirancang, pengujian cluster selesai, dan kelas telah terintegrasi o tes tingkat Sistem yang lengkap
5.4. WebApp Project Scheduling
Selama iterasi pertama makroskopik dikembangkan dengan mengalokasikan usaha untuk tugas-tugas tertentu (dipahami bahwa ini adalah jadwal berubah)
Proyek ini dipecah menjadi bertahap dan bertahap disempurnakan untuk jadwal rinci masing-masing dimulai (beberapa bertahap dapat dikembangkan secara paralel)
Setiap tugas dalam daftar tugas untuk setiap kenaikan disesuaikan dalam salah satu dari empat cara seperti jadwal rinci dibuat o tugas diterapkan sebagaimana mestinya o Tugas dihilangkan karena tidak diperlukan untuk peningkatan tersebut o (custom) tugas baru ditambahkan o Tugas yang disempurnakan (diuraikan) menjadi sejumlah bernama subtasks yang masing-masing menjadi bagian dari jadwal
Proses ini berlanjut sampai setiap kenaikan direncanakan selesai
6. Earned Value Analysis earned value merupakan suatu ukuran kuantitatif yang diberikan untuk setiap tugas sebagai persen proyek selesai sejauh ini. 1. Total jam untuk menyelesaikan tugas masing-masing proyek diperkirakan (BCWS - biaya yang dianggarkan kerja terjadwal) 2. Upaya untuk menyelesaikan proyek dihitung dengan menjumlahkan upaya untuk menyelesaikan setiap tugas (BAC - anggaran pada penyelesaian) 3. Setiap tugas yang diberikan nilai yang diperoleh berdasarkan persentase kontribusi estimasi terhadap total (BCWP - biaya yang dianggarkan dari pekerjaan yang telah diselesaikan). Hal ini menghitung biaya yang sebenarnya pekerjaan yang dilakukan (ACWP) pada setiap titik dalam proyek dan untuk menghitung indikator kemajuan untuk kedua jadwal dan biaya berdasarkan langkah-langkah ini
