Pengelolaan Proyek Sistem Informasi

Presentasi berjudul: "Pengelolaan Proyek Sistem Informasi"— Transcript presentasi:

1 Pengelolaan Proyek Sistem Informasi
Fase Definisi

2 Outline Framework PPSI Metodologi Software Product RD
Go/No Go Decision Perencanaan Proyek

3 Framework PPSI “Project always begin with Problem” (John J. Rakos)

4 Framework PPSI Proyek yang baik adalah proyek yang mencapai titik kesetimbangan antara waktu, biaya dan kualitas

5 Framework PPSI Project Scope Management: Proses yang dibutuhkan untuk menentukan lingkup proyek termasuk segala proses dan semua pekerjaan yang dibutuhkan untuk menyelesaikan proyek, meliputi: initiation scope planning scope definition scope verification scope change control

6 Framework PPSI Project Time Management: Proses yang dibutuhkan untuk memastikan penggunaan waktu dalam penyelesaian proyek, meliputi: activity definition activity sequencing activity duration estimating schedule development schedule control

7 Framework PPSI Project Cost Management: Proses yang dibutuhkan untuk melakukan pengaturan pelaksanaan dengan budget yang sudah disetujui, meliputi: resource planning cost estimating cost budgeting cost control

8 Framework PPSI Project Quality Management: Proses yang dibutuhkan untuk memastikan bahwa proyek akan diselesaikan sesuai yang ditetapkan dalam pelaksanaanya, meliputi: quality planning quality assurance quality control

9 Framework PPSI Project Human Resource Management: Proses yang dibutuhkan untuk membuat pemanfaatan SDM yang paling efektif yang terlibat dengan proyek tersebut, meliputi: organizational planning staff acquisition team development

10 Framework PPSI Project Communications Management: Proses yang dibutuhkan untuk memastikan proyek tepat waktu, menyediakan bagian-bagian informasi, koleksi, penyebaran, penyimpanan dan disposisi terakhir informasi proyek, meliputi: communications planning information distribution performance reporting administrative closure

11 Framework PPSI Project Risk Management: Proses yang berkonsentrasi dengan identifikasi, analisa dan merespon resiko proyek, misalnya: risk identification risk quantification risk response development risk response control

12 Framework PPSI Project Procurement Management: Proses yang dibutuhkan untuk mendefinisikan kebutuhan dan layanan dari luar organisasi yang dapat mempengaruhi kelangsungan proyek, misalnya: procurement planning solicitation planning solicitation source selection contract administration contract close-out

13 Framework PPSI Project Integration Management: Proses yang dibutuhkan untuk memastikan berbagai variasi elemen proyek terkoordinasi dengan baik, meliputi: project plan development project plan execution overall change control

14 Metodologi Sounds familiar?
Schedule slips – the day for delivery comes and you have to tell the customer that the software won’t be ready for another six months Project cancelled – after numerous slips, the project is cancelled without ever going into production System goes sour – the software is successfully put into production, but after a couple of years the cost of making the changes or the defect rate rises so much that the system must be replaced Defect rate – the software is put into production, but the defect rate is so high that it isn’t used Kent Beck

15 Metodologi Sounds familiar? (con’td)
Business misunderstood – the software is put into production, but it doesn’t solve the business problem that was originally posed Business changes – the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing, business problem False feature rich – the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money Staff turnover – after two years, all the good programmers on the project begin to hate the program and leave Kent Beck

16 Metodologi Yang kita inginkan adalah: On Time On Budget
Have the required features Met the quality standards Productivity Predictability Repeatability

17 Metodologi Metodologi adalah deskripsi dari proses untuk membawa suatu produk software melalui semua atau sebagian dari life cycle Biasanya berfokus pada fase life cycle dan relasi antara fase yang satu dengan lainnya

18 Metodologi Software Life Cycle
Requirements specification resulting in the product requirements document Design resulting in the Software architecture Construction (implementation or coding) resulting in the actual software Integration Testing and debugging Installation Maintenance

19 Metodologi Contoh dari metodologi yang ada:
MSF (Microsoft Solutions Framework) XP (Extreme Programming) RUP (Rational Unified Process) CMMI (Capability Maturity Model Integration) SCRUM Feature Driven Development (FDD) Formal Methods (Formal to the Extreme) Hajar BlehTM Programming

20 Metodologi Mengapa ada banyak metodologi?
We develop many different types of applications Many different software development cultures and competitive environments Ego (The drive to be unique)

21 Software Product RD Tujuan dan lingkup produk, baik dari sudut teknis maupun bisnis Identifikasi stakeholder Perkiraan pasar Gambaran tentang produk Kebutuhan (requirement), mencakup: functional requirements (e.g. what a product should do) usability requirements technical requirements (e.g. security, network, platform, integration, client) environmental requirements support requirements interaction requirements (e.g. how the software should work with other systems) Batasan Evaluasi dan performa

22 Software Product RD Stakeholder
Bukan hanya pihak yang mempekerjakan analis, tetapi juga termasuk: anyone who operates the system (normal and maintenance operators) anyone who benefits from the system (functional, political, financial and social beneficiaries) anyone involved in purchasing or procuring the system organizations which regulate aspects of the system (financial, safety, and other regulators)

23 Software Product RD people or organizations opposed to the system (negative stakeholders) organizations responsible for systems which interface with the system under design those organizations who integrate horizontally with the organization for whom the analyst is designing the system

24 Software Product RD

25 Software Product RD Masalah dalam requirement: Stakeholder
Users do not understand what they want or users don't have a clear idea of their requirements Users will not commit to a set of written requirements Users insist on new requirements after the cost and schedule have been fixed Communication with users is slow Users often do not participate in reviews or are incapable of doing so Users are technically unsophisticated Users do not understand the development process Users do not know about present technology Steve McConnell

26 Software Product RD Masalah dalam requirement: Engineer/developer
Engineer/developer starts coding/implementation immediately before they really understand the whole requirement from analyst, which usually causes lots of defect fixing or reworking in test/verification phase Technical personnel and end-users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client Analysis may often be carried out by engineers or programmers, rather than personnel with the domain knowledge to understand a client's needs properly

27 Go/No Go Decision Studi kelayakan bisnis adalah suatu kegiatan yang cukup mendalam dan komprehensif untuk mengetahui apakah pengembangan usaha yang akan dilakukan layak atau tidak

28 Go/No Go Decision Menurut Kasmir dan Jakfar ada lima tujuan mengapa sebelum suatu usaha atau proyek dijalankan perlu dilakukan studi kelayakan yaitu: Menghindari resiko kerugian Memudahkan perencanaan Memudahkan pelaksanaan pekerjaan Memudahkan pengawasan Memudahkan pengendalian

29 Go/No Go Decision Faktor-faktor penyebab kegagalan suatu bisnis:
Data dan informasi tidak lengkap atau adanya ketidaklengkapan dan kepalsuan data Tidak teliti atau adanya kecerobohan yang menyebabkan kesalahan Salah perhitungan atau adanya kesalahan saat perhitungan ataupun rumus-rumus yang digunakan Pelaksanaan pekerjaan salah atau adanya pekerja yang tidak mengerjakan proyek berdasarkan pedoman yang ditetapkan Kondisi lingkungan atau adanya unsur-unsur yang tidak dapat dikendalikan Unsur sengaja atau adanya kesalahan yang disengaja oleh peneliti dengan berbagai sebab. Hal ini sangat fatal

30 Go/No Go Decision Faktor yang mempengaruhi seseorang untuk melakukan pengambilan keputusan: Kondisi internal dan eksternal organisasi Ketersediaan informasi Ketrampilan pengambil keputusan

31 Go/No Go Decision Aspek-aspek penilaian dalam studi kelayakan adalah:
Aspek hukum: untuk meneliti kelengkapan, kesempurnaan dan keaslian izin-izin dan dokumen-dokumen Aspek pasar dan pemasaran: meneliti besar pasar dan kemampuan perusahaan menguasainya, serta menilai strateginya Aspek keuangan: menilai perolehan pendapatan dan biaya yang dikeluarkan Aspek teknis/operasional: menentukan lokasi, layout gedung dan ruangan serta teknologi yang digunakan Aspek manajemen: meneliti kesiapan SDM yang menjalani usaha Aspek ekonomi dan sosial: menilai manfaat usaha terhadap ekonomi dan sosial masyarakat Aspek dampak lingkungan: menilai dampak lingkungan yang dapat ditimbulkan

32 Perencanaan Proyek Meyakinkan rekan-rekan yang lain bahwa proyek tersebut sebaiknya dibuat dengan membuat sebuah proposal Sebuah proposal adalah dokumen yang merinci biaya dan jadwal proyek serta garis besar langkah langkah yang akan digunakan oleh suatu perusahaan untuk memproduksi produk

33 Perencanaan Proyek PPP WBS Project Network Diagram Project Cost
Project Schedule PPP Outline

34 Perencanaan Proyek Preliminary Project Plan (PPP)
Sebuah rencana untuk proyek software yang menjabarkan akrifitas yang diinginkan, berapa lama setiap aktifitas dilakukan, kapan aktifitas ini harus mengambil tempat dan berapa banyak sumber daya yang dihabiskan pada setiap aktifitas untuk memproduksi hasil yang diinginkan

35 Perencanaan Proyek Work Breakdown Structure (WBS)
Dekomposisi suatu proyek menjadi komponen yang lebih kecil Memiliki struktur tree Komponennya dapat berupa produk, data, layanan, atau campuran WBS menyediakan kerangka kerja yang dibutuhkan untuk perkiraan biaya dan kontrol sehingga memudahkan pengembangan penjadwalan

36 Perencanaan Proyek Work Breakdown Structure (WBS) 100% rule
“the sum of the work at the “child” level must equal 100% of the work represented by the “parent” and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work” Rule of thumb 80 hours rule: no single activity or group of activities at the lowest level of detail of the WBS to produce a single deliverable should be more than 80 hours of effort no activity or group of activities at the lowest level of detail of the WBS should be longer than a single reporting period “if it makes sense” rule: one can apply "common sense" when creating the duration of a single activity or group of activities necessary to produce a deliverable defined by the WBS

37 Perencanaan Proyek Work Breakdown Structure (WBS)
Sampai kapan dilakukan? dapat diperkirakan secara realistis komponen sudah tidak mungkin untuk dibagi lagi dapat dilaksanakan mengikuti aturan-aturan yang disebutkan sebelumnya menghasilkan suatu hasil yang dapat diperkirakan

38 Perencanaan Proyek Work Breakdown Structure (WBS)

39 Perencanaan Proyek Work Breakdown Structure (WBS)

40 Perencanaan Proyek Work Breakdown Structure (WBS)

41 Perencanaan Proyek Work Breakdown Structure (WBS)

42 Perencanaan Proyek AKTIFITAS USAHA PRECEDENT Definition 20 - Analysis
35 Design 25 Program A (control) Program B (registration) 30 Program C (warehouse) System test 10 Program A, B, C Documentation Acceptance 5 System Test, Documentation Training Operation TOTAL 210 person - days

43 Perencanaan Proyek Project Network Diagram
Menggambarkan urutan komponen proyek dan ketergantungannya (dependency) “The work breakdown structure show the "part-whole" relations. In contrast, the project network shows the "before-after" relations”

44 Perencanaan Proyek Project Network Diagram

45 Perencanaan Proyek Project Cost
Jika kontrak dari proyek sudah disetujui, manajer proyek dapat menghitung harga kotor, untuk tenaga kerja dengan mengalikan jumlah biaya buruh per hari dengan biaya rata-rata per hari Jika anda menghitung biaya secara manual dan anda yakin bahwa total perkiraan dari 210 orang/hari, harga proyek dengan mengalikan 210 denga rata-rata biaya per hari, dan menambah biaya tetap peralatan

46 Perencanaan Proyek Project Schedule
Salah satu kesulitan tugas ini adalah mengalokasikan sumber daya manusia yang akan melakukan pekerjaan yang akan dilaksanakan, terutama ketika tugas berjalan secara serentak. Kesulitan lain adalah memutuskan bagaimana mempersingkat pekerjaan yang akan dilakukan dengan menggunakan sumber daya yang ada

47 Perencanaan Proyek Project Schedule
Gantt Chart menggunakan Microsoft Project

48 Perencanaan Proyek PPP Outline
Merupakan garis besar yang diusulkan untuk PPP

49 Perencanaan Proyek PPP Outline
Project team, organisasi dari tim proyek, siapa yang membuat laporan untuk siapa, siapa berkomunikasi dengan siapa dan lain-lain Biaya proyek, perkiraan dan perhitungan yang dipergunakan untuk menentukan harga/biaya Jadwal proyek, Merupakan inti dari proyek Pemeriksaan ulang, tujuan dari setiap pemeriksaan dan siapa yang akan menghadirinya, catat tanggung jawab semua orang yang terlibat didalamnya

50 Perencanaan Proyek PPP Outline
Laporan, bentuk dan isi dari laporan status, laporan milestone dan dokumen proyek lain dirinci disini, serta daftar orang yang menerima tiap laporan dan apa tanggapannya setelah menerima laporan tersebut Dokumentasi, dokumen mana yang akan diproduksi dan tanggapan yang bersangkutan dari 2 jenis dokumen didalam proyek: pengguna dan manajemen proyek Kesimpulan, fakta-fakta yang diberikan kepada anda (kadang-kadang lisan) oleh pengguna