Project Charter [PDF]

Citation preview

PROJECT CHARTER 2.1 Project Name Nama proyek yang akan kami kembangkan adalah Badan Eksekutif Mahasiswa Information and Document Management System (BEM INDOMAST)



Universitas Indonesia



2.2 Project Objectives Tujuan pengembangan BEM UI INDOMAST (Badan Eksekutif Mahasiswa Universitas Indonesia Information and Document Management System) adalah sebagai berikut: 1. Menyediakan sarana bagi BEM UI untuk menyebarkan dan menerima informasi dengan lengkap, benar, dan jelas kepada dan dari sesama anggota BEM UI. 2. Menyediakan sarana bagi BEM UI untuk menyebarkan dan menerima informasi dengan lengkap, benar, dan jelas kepada dan dari pihak eksternal. 3. Menyediakan sarana bagi BEM UI untuk menyimpan dan menemukan kembali softcopy suatu dokumen serta mempublikasikan suatu dokumen kepada pihak eksternal. 4. Mewujudkan sistem pengelolaan informasi dan dokumen BEM UI yang berisi informasi dan dokumen yang reliable. 5. Meningkatkan jalinan kerja sama dengan pihak eksternal sampai 40 %. 6. Meningkatkan bantuan ekonomi dari pihak eksternal sampai 30 %. 7. Mewujudkan transparansi dokumen-dokumen yang perlu dipublikasikan dari BEM UI. 2.3 Problem Statement Berbagai masalah nyata yang dialami BEM UI meliputi : 1. Penyampaian informasi antar anggota BEM UI (secara internal) belum berjalan dengan lancar 2. Penyampaian informasi antara BEM UI dengan pihak luar (eksternal) belum berjalan dengan lancar 3. Pengelolaan dokumen atau arsip belum berjalan dengan baik 4. Informasi maupun dokumen yang ada dalam sistem pengelolaan informasi dan dokumen tidak di-update secara rutin 5. Adanya kesempatan untuk menampilkan citra baik BEM UI kepada pihak luar (eksternal) 6. Adanya tuntutan transparansi dalam segala kegiatan yang dilakukan BEM UI, misalnya transparansi laporan keuangan, laporan penerimaan dana dan lain-lain Pernyataan masalah akan dijelaskan pada tabel 2.1 berikut ini. Masing-masing masalah akan diberikan peringkat berdasarkan tingkat kepentingan dan validitasnya. No. Pernyataan Singkat dari Tingkat Visibilitas Peringkat Solusi yang Masalah atau Peluang Kepentingan Ditawarkan 1. Penyampaian informasi antar 3 Bulan High 1 Pengembangan modul anggota BEM UI (internal) repository online dan belum berjalan dengan lancar manajemen news. 2. Penyampaian informasi 3 bulan High 1 Pengembangan modul antara BEM UI dengan pihak pelayanan respond luar (eksternal) belum online, repository berjalan dengan lancar online, dan manajemen news. 3. Pengelolaan dokumen atau 3 bulan High 1 Pengembangan modul arsip belum berjalan dengan repository online baik 4. Sulit dilakukan peng-update4 bulan Medium 3 Pengembangan modulan secara rutin karena hanya modul yang 1 orang administrator yang memungkinkan anggota melakukannya. BEM UI yang terkait untuk melakukan pengupdate-an (tidak hanya mengandalkan administrator). 5. Adanya kesempatan untuk 6 bulan Medium 2 Pengembangan modul



memampilkan citra baik BEM UI kepada pihak eksternal.



6.



Adanya tuntutan tranparansi dalam menghadapi era reformasi. Tabel 2.1 Pernyataan Masalah



6 bulan



Medium



2



repository online, manajemen news, dan pelayanan respond online, dan memungkinkan modulmodul tersebut untuk diupdate dengan rutin Pengembangan modul repository online



2.4 Initial Scope of Project Masalah-masalah yang dipilih untuk dipecahkan beserta solusi untuk mengatasinya dan signifikansinya adalah sebagai berikut : 1. Penyampaian informasi antar anggota BEM UI (internal) yang belum berjalan dengan lancar. Solusi : Pengembangan modul repository online dan manajemen news. 2. Penyampaian informasi antara BEM UI dengan pihak luar (eksternal) yang belum berjalan dengan lancar. Solusi : Pengembangan modul pelayanan respond online, repository online, dan manajemen news. 3. Pengelolaan dokumen atau arsip yang belum berjalan dengan baik. Solusi : Pengembangan modul repository online. 4. Sulitnya dilakukan peng-update-an secara rutin karena hanya 1 orang administrator yang melakukannya. 5. Adanya kesempatan untuk menampilkan citra baik BEM UI kepada pihak eksternal. Solusi : Pengembangan modul repository online, manajemen news, dan pelayanan respond online, dan memungkinkan modul-modul tersebut untuk di-update dengan cepat 6. Adanya tuntutan tranparansi dalam menghadapi era reformasi. Solusi : Pengembangan modul repository online. Untuk mengatasi masalah-masalah yang dipilih tersebut, maka akan dikembangan BEM UI INDOMAST (Badan Eksekutif Mahasiswa Universitas Indonesia Information and Document Management System) yang akan mendukung fungsi-fungsi berikut : 1. Repository online Repository online memungkinkan BEM UI untuk menyimpan dokumen atau arsip, menemukan dokumen atau arsip yang telah tersimpan, serta meng-upload dokumen atau arsip agar dapat diakses oleh pihak eksternal. 2. Pelayanan respond online Pelayanan respond online memungkinkan pihak eksternal untuk mengkontak biro/bidang tertentu ataupun semua biro/bidang secara online, memungkinkan BEM UI untuk untuk memberikan respon secara online, dan memungkinkan pihak eksternal untuk membaca respon yang diberikan oleh BEM UI secara online. 3. Manajemen news Manajemen news memungkinkan BEM UI untuk mempublikasikan news kepada pihak internal ataupun kepada pihak eksternal. User BEM UI INDOMAST dapat digolongkan menjadi user internal dan user eksternal. User internal adalah anggota BEM UI, sedangkan user eksternal adalah pengguna sistem di luar BEM UI. 2.5 Project Vision Beberapa visi yang ingin dicapai dari pelaksanaan proyek BEM UI INDOMAST adalah sebagai berikut : 1. Meningkatkan kinerja BEM UI. 2. Mengurangi resiko terjadinya kesalahpahaman antara sesama anggota BEM UI maupun antara anggota BEM UI dengan pihak eksternal. 3. Mengurangi resiko terjadinya kehilangan dokumen-dokumen penting, seperti surat, laporan keuangan, proposal, laporan pertanggungjawaban, dan lain-lain. 4. Meningkatkan kepercayaan pihak eksternal kepada BEM UI. 5. Meningkatkan kerja sama dalam BEM UI dan juga kerja sama antara BEM UI dengan pihak eksternal.



2.6 Project Constraint Project constraints pengembangan BEM UI INDOMAST adalah sebagai berikut : 1. Schedule: BEM UI INDOMAST harus diselesaikan paling lama pada saat berakhirnya semester perkuliahan, yaitu sekitar Bulan Juni. 2. Cost: Biaya pengembangan BEM UI INDOMAST tidak boleh melebihi biaya yang telah dialokasikan oleh BEM UI 3. Policy: BEM UI INDOMAST harus sesuai dengan kebijakan yang berlaku di perusahaan, termasuk teknik/ peraturan-peraturan mengenai alur proses bisnis perusahaan. 4. Technology: BEM UI INDOMAST harus kompatibel dengan software yang sudah ada. 2.7 Project Methodology FAST menyediakan berbagai alternatif rute-rute dalam melewati fase-fase pengembangan sistem diatas, ruterute tersebut dibedakan berdasarkan tipe proyek, tujuan teknologi, kemampuan tim developer, dan strategi pengembangan proyek itu sendiri. Rute-rute tersebut antara lain MDD (Model-driven development), RAD (Rapid application development), dan COTS (Commercial off the shelf). Setelah dipertimbangkan dan dibicarakan oleh seluruh tim pengembang maka rute yang sesuai dengan proyek ini yaitu RAD, karena menggunakan prototype untuk menyatukan analisa dan desain dari requirement-requirement user. Dalam pengerjaan proyek ini digunakan metodologi FAST (Framework for the Application of Systems Techniques). FAST metodologi terdiri dari fase-fase pengembangan yaitu: Preliminary Investigation Phase, Problem Analysis Phase, Requirements Analysis Phase, Logical Design Phase, Decision Analysis Phase, Design Phase, Construction Phase, Implementation Phase, dan Operation and Support Phase 2.8 Project Documentation and Communication Berikut ini adalah petunjuk yang akan digunakan sebagai sarana dokumentasi dan komunikasi proyek : 1. System Analyst dan Programmer melakukan komunikasi secara langsung setiap hari Senin Rabu, dan Kamis untuk membahas mengenai perkembangan dari implementasi yang telah dilakukan oleh Programmer, serta System Analyst memberikan requirement yang harus dipenuhi. 2. System Analyst dan System Owner melakukan komunikasi secara langsung seminggu sekali untuk membahas mekanisme proses bisnis yang sedang berjalan. 3. Project Manager dan System Analyst melakukan pertemuan secara langsung setiap dua minggu sekali untuk melakukan quality assurance management. 4. Project Team secara keseluruhan akan mengadakan pertemuan setiap bulannya untuk membahas mengenai perkembangan proyek yang telah dilaksanakan. 5. Project Team dapat menggunakan sarana e-mail sebagai alat komunikasi untuk membahas permasalahan yang dihadapi oleh masing-masing anggota tim. 2.9 Project Organization and Staffing Approach Struktur organisasi proyek BEM INDOMAST digambarkan pada gambar 2.1 berikut ini.



System Owner



Project Manager



Database Designer



Interface Designer



System Analyst



Customer Representative



Programmer



Documentator



Programmer



Gambar 2.1 Struktur Organisasi dan Staf Proyek Nama-nama tim dalam struktur orgaisasi proyek BEM INDOMAST dijelaskan pada tabel 2.2 berikut.



No. 1. 2. 4. 5. 6. 7. 8. 9.



Jabatan System Owner Project Manager System Analyst Documentator Programmer Database Designer Interface Designer Customer Representative



Nama BEM UI Muhammad Fajar Rizqi Lisa Rienellda Irsal Dennita, Nelly Viona Syavita, Dennita Nelly R. Ayu P Wawan



Tabel 2.2 Staf Proyek



2.10 Time Estimation of Project Development Estimasi waktu lamanya pengerjaan proyek adalah sebagai berikut : 1. Preliminary Investigation: 25 Febuari 2004 – 05 Maret 2004 (10 hari kerja) 2. Problem Analysis: 08 Maret 2004 – 17 Maret 2004 (10 hari kerja) 3. Requirements Analysis: 22 Maret 2004 – 31 Maret 2004 (10 hari kerja) 4. Decision Analysis: 03 April 2004 – 12 April 2004 (10 hari kerja) 5. Design: 16 April 2004 – 27 April 2004 (12 hari kerja) 6. Construction: 02 Mei 2004 – 12 Mei 2004 (11 hari kerja) 7. Implementation: 15 Mei 2004 – 20 Mei 2004 (6 hari kerja)



2.11 Resource Allocation Tabel 2.3 berikut ini akan menjelaskan tugas utama dari para pengembang proyek yang telah disebutkan diatas. No. Jabatan Tugas Utama 1. Project Manager  Bertanggung jawab atas pelaksanaan proyek. (PM)  Mengkoordinasikan segala kegiatan yang bersangkutan dengan proyek.  Menententukan project deliverables  Mengkoordinasikan pengalokasian sumber daya. 2. System Analyst  Menganalisa system requirments. (SA)  Mempelajari domain permasalahan yang terkait dengan proyek ini.  Merancang sistem.  Memastikan bahwa sistem yang dikerjakan sesuai dengan yang diharapkan. 3. Database Designer  Mendesain database yang diperlukan. (DD)  Melakukan implementasi database yang telah dirancang.  Mengintegrasikan database dengan sistem. 4. Interface Designer  Merancang sistem interaksi untuk sistem. (ID)  Melakukan implementasi sistem interaksi yang sudah dirancang. 5. Programmer (PR)  Melakukan implementasi dari design yang telah dibuat  Melakukan bugfix 6. Documentator  Mengumpulkan semua dokumen yang diperlukan dalam pembuatan (DC) sistem.  Melakukan system testing.  Membuat dokumentasi sistem.  Membuat petunjuk penggunaan sistem (user manual). Tabel 2.3 Pengalokasian Sumber Daya Staf 2.12 Work Breakdown Structure Tabel 2.4 menggambarkan pembagian tugas dan deskripsi tugas pengembang proyek. Phase



Activity Number



Activity Name



Estimated Hours



Preliminary Investigation



Dependent Upon 1,2,3,4 in preliminary investigation phase



1 2 3 4



List of problems, opportunities, or directives Negotiate scope Plan the project Present the project plan



Role All



12



All



5 12 2



All All All



Problem Analysis



1,2,3,4 in problem analysis phase 1 2 3 4



Analyze the current system Establish system improvements objectives Update the project plan Present findings and recommendation



20 12



SA and PM SA and PM



4 6



SA and DC PM and SA



Requirements Analysis



1,2,3,4 in requirements analysis phase 1



Identify business



12



SA and PM



2 3 4



requirements Analyze system requirements Prioritize business requirements Update the project plan



12



PM and SA



8



PM



4



Descision Analysis



SA and DC 1,2,3,4 in decision analysis phase



1 2 3 4



Identify candidate solutions Analyze candidate solutions Recommend a target solution Recommend a project solution



12 12 6



PM and SA SA and PM SA



6



SA



Design



1,2,3,4,5 in design phase 1 2 3 4 5



Design the application architecture Design the system database Design the system interface Design the application logic Update the project plan



24



SA and DD



24 40 40 16



DD ID SA, DA , ID and PR SA and DC



Construction



1,2,3,4,5 in construction phase 1 2 3 4 5



Interface building Network environment building Database system building Application engine construction System integration



24 24



ID SA and DB



24 32



DB SA and PR



32



Implementation



PR and DB 1,2,3,4,5,6,7 in implementation phase



1 2 3 4 5 6 7



Network testing Database testing Program testing System testing Preparation and documentation release Software installation User acceptance test



4 4 4 4 8



PM and SA PM and SA DC DC DC



8 8



PR and DB PM and DC



Tabel 2.4 Work Breakdown Structure



2.13 Cost Estimation Metode Estimasi Metode estimasi biaya yang digunakan dalam pengerjaan proyek ini adalah Function-Oriented Metrics, dengan menggunakan metode function point (FP). Metode estimasi FP merupakan metode estimasi biaya berbasis permasalahan (problem-based estimation). Dengan menggunakan metode ini, Sistem yang dirancang



didekomposisikan menjadi beberapa fungsi permasalahan yang dapat mempermudah dalam pengestimasian biaya. Dalam FP, system didekomposisikan menjadi beberapa domain informasi, antara lain jumlah input, jumlah output, jumlah inquiries dari pengguna, jumlah berkas dan jumlah interface eksternal. Selain itu ada juga 14 pertanyaan yang mendeskripsikan nilai penyesuaian kompleksitas (complexity adjustment values). Untuk menghitung function point, perumusannya adalah sebagai berikut: FP = jumlah total x [(0.65 + (0.01 x  Fi)] Dimana jumlah total adalah jumlah masukan FP, dan Fi adalah nilai penyesuaian kompleksitas. Tabel 2.5 akan menjabarkan Complexity Adjustment Values dalam perhitungan biaya proyek. Complexity Adjustment Values Faktor Nilai Backup and recovery 4 Komunikasi data 5 Distribusi pemrosesan 0 Critical performance 0 Lingkungan pengoperasian 3 Masukan data secara online 0 Transaksi input melalui banyak screen 0 Update berkas utama secara online 4 Informasi mengenai nilai domain 0 Pemrosesan internal 5 Desain program untuk penggunaan kembali 4 Konversi/instalasi desain 4 Instalasi multiple 2 Aplikasi yang didesain untuk perubahan 5 32  Fi = Tabel 2.5 Complexity Adjustment Values Tabel 2.6 berikut ini menjabarkan Computing Function Point Metrics dalam perhitungan biaya proyek. Computing Function Point Metrics Bobot pengali Faktor Pengukur Jumlah Mudah Sedang Sulit Jumlah masukan dari user



30



X



3



4



5



=



90



Jumlah keluaran



20



X



3



4



5



=



80



Jumlah inquiries



20



X



3



4



5



=



100



Jumlah berkas



20



X



3



4



5



=



80



Jumlah interface eksternal



0



X



3



4



5



=



0



Jumlah total



350 Tabel 2.6 Computing Function Point Metrics



= jumlah total x [0.65 + (0.01 x  Fi)] = 350 x [0.65 + (0.01 x 32)] = 350 x (0.65 + 0.32) = 608 x 1.03 = 227,82 Estimasi Biaya Sumber Daya Manusia : FPestimated



Lama Proyek Biaya Dokumentasi = Total Biaya =



= 4 bulan = US$ 5 per FP/person-month 1 halaman /FP 227,82 x US$ 5 = US$ 1139,1



WBS



Pada prinsipnya Work Breakdown Structure (WBS) adalah pemecahan atau pembagian pekerjaan ke dalam bagian yang lebih kecil (sub-kegiatan), alasan perlunya WBS adalah : 1. Pengembangan WBS di awal Project Life Cycle memungkinkan diperolehnya pengertian cakupan proyek dengan jelas, dan proses pengembangan WBS ini membantu semua anggota untuk lebih mengerti tentang proyek selama tahap awal. 2. WBS membantu dalam pengawasan dan peramalan biaya, jadwal, dan informasi mengenai produktifitas yang meyakinkan anggota manajemen proyek sebagai dasar untuk membuat perundingan.



WBS merupakan elemen penting, karena memberikan kerangka yang membantu, antara lain dalam : 1. 2. 3. 4. 5.



Penggambaran program sebagai ringkasan dari bagian-bagian yang kecil. Pembuatan perencanaan. Pembuatan network dan perencanaan pengawasan. Pembagian tanggung jawab. Penggunaan WBS ini memungkinkan bagian-bagian proyek terdefinisi dengan jelas.



Work Breakdown Structure (WBS) atau struktur rincian pekerjaan adalah daftar pekerjaan atau tugas-tugas (sering disebut dengan istilah task) yang akan dikerjakan dalam sebuah proyek. Pada dasarnya WBS merupakan suatu daftar yang bersifat top down dan secara hirarkis menerangkan komponen-komponen yang harus dibangun dan pekerjaan yang berkaitan dengannya. 1. Struktur WBS Struktur dalam WBS mendefinisikan tugas-tugas yang dapat diselesaikan secara terpisah dari tugas-tugas lain, memudahkan alokasi sumber daya, penyerahan tanggung jawab, pengukuran dan pengendalian proyek. Pembagian tugas menjadi sub tugas yang lebih kecil tersebut dengan harapan menjadi lebih mudah untuk dikerjakan dan diestimasi lama waktunya. Model WBS memberikan beberapa keuntungan, antara lain :   



Memberikan daftar pekerjaan yang harus diselesaikan Memberikan dasar untuk mengestimasi, mengalokasikan sumber daya, menyusun jadwal, dan menghitung biaya Mendorong untuk mempertimbangkan secara lebih serius sebelum membangun suatu proyek .



2. Perbedaan Level Dan Tingkat Kedetailan WBS



Setiap organisasi menggunakan terminologinya sendiri untuk mengklasifikasi komponen WBS sesuai levelnya dalam hirarki. Sebagai contoh, beberapa organisasi memperlihatkan level-level yang berbeda sebagai tugas (task), sub-tugas (sub-task) dan paket pekerjaan (work package) sebagaimana yang ditunjukkan dalam bagan diatas. Sementara organisasi lain mungkin menggunakan istilah fase (phase), entri (entry) dan aktifitas (activity). WBS mungkin saja disusun mengikuti pembagian atau pentahapan dalam siklus hidup proyek ( the project life cycle). Level-level yang lebih tinggi dari struktur umumnya dikerjakan oleh kelompok-kelompok. Level yang paling rendah dalam hirarki seringkali terdiri dari aktifitas-aktifitas dilakukan secara individual, kendati demikian sebuah WBS yang menitikberatkan pada “deliverable” tidak memerlukan aktifitas-aktifitas yang spesifik. 3. Peran WBS Dalam Perencanaan Proyek WBS merupakan pondasi untuk perencanaan proyek. WBS dibuat sebelum ketergantungan diidentifikasi dan lamanya aktifitas pekerjaan diestimasi. WBS juga dapat digunakan untuk mengidentifikasi tugas-tugas dalam model perencanaan proyek. Oleh karena itu, idealnya rancangan WBS sendiri harusnya telah diselesaikan sebelum pengerjaan perencanaan proyek (project plan) dan penjadwalan proyek (project schedule). Dengan memanfaatkan daftar pekerjaan pada WBS, akan dapat diperkirakan lamanya waktu yang dibutuhkan untuk menyelesaikan setiap pekerjaan tersebut. Perkiraan bisa dilakukan dengan mempertimbangan beberapa hal, antara lain ketersediaan sumber daya dan kompleksitas. Selanjutnya dilakukan penjabaran dalam kalender (flow time). Beberapa model pendekatan bisa digunakan untuk menghitung perkiraan waktu yang diperlukan : - Most optimistic : Merupakan waktu ideal untuk menyelesaikan pekerjaan, diasumsikan segala sesuatunya berjalan lancar, dan sempurna. - Most likely : Merupakan waktu yang dibutuhkan pada kondisi kebanyakan, tipikal dan normal. Most pessimistic :Merupakan waktu yang dibutuhkan ketika keadaan paling sulit terjadi. Selanjutnya, estimasi waktu dilakukan dan dibagi dalam unit (misal 8 jam/hari). Estimasi waktu untuk suatu proyek Intranet (seperti contoh diatas) lebih sulit dari proyek pengembangan aplikasi lainnya. Hal ini karena masih sedikit proyek yang dapat digunakan sebagai patokan menghitung waktu pelaksanaan. Dalam mengestimasi waktu ini juga harus dipertimbangkan beberapa hal, misal pengalaman teknologi server yang digunakan, keahlian Perl, CGI, Java, HTML, browser, dan juga bekerja dalam lingkungan TCP/IP. Setelah WBS berhasil disusun dan perkiraan lama waktu pelaksanaan telah dihitung, selanjutnya dilakukan penyusunan jadwal kerja. Pada dasarnya ada dua jenis model deskripsi penjadwalan, yaitu : - Bar Chart : Yang hanya menerangkan flow time dari setiap pekerjaan dan tanpa keterkaitan antar pekerjaan. Deskripsi ini paling baik digunakan pada presentasi - Network diagram : Yang menunjukkan keterkaitan antar tugas dan mengidentifikasi saat kritis pada jadwal. 4.



Kesalahan dan Kesalahpahaman Sebuah kerja Struktur Breakdown bukan merupakan daftar kengkap kerja melainkan komprehensif lingkup proyek. Sebuah WBS bukanlah rencana proyek sebuah jadwal atau daftar kronologis. Dianggap miskin praktek untuk menyusun jadwal proyek (misalnya dengan menggunakan perangkat lunak manajemen proyek) sebelum merancang WBS yang tepat. Ini akan mirip dengan penjadwalan kegiatan konstruksi rumah sebelum menyelesaikan desain rumah.Tanpa memusatkan perhatian pada hasil yang direncanakan, sangat sulit untuk mengikuti 100% Aturan di semua tingkat dari hirarki WBS. Sebuah WBS bukanlah sebuah hirarki organisasi. Beberapa praktisi melakukan kesalahan dengan membuat WBS bahwa bayang-bayang bagan organisasi. Meskipun tanggung jawab umum yang akan ditugaskan untuk elemen organisasi, sebuah WBS yang bayangan struktur organisasi tidak deskriptif lingkup proyek dan tidak berorientasi hasil. WBS update, selain elaborasi progresif detail, memerlukan perubahan formal kontrol. Ini adalah alasan lain mengapa WBS harus berorientasi hasil dan tidak metode preskriptif. Metode dapat, dan lakukan, sering berubah, tetapi perubahan dalam hasil direncanakan memerlukan tingkat yang lebih tinggi formalitas. Jika hasil dan tindakan dicampur, perubahan DNS mungkin terlalu kaku untuk tindakan dan terlalu informal bagi hasil. -