Pengelolaan Proyek Sistem Informasi

Pengelolaan Proyek Sistem InformasiFase Definisi

OutlineFramework PPSIMetodologiSoftware Product RDGo/No Go DecisionPerencanaan Proyek

Framework PPSI“Project always begin with Problem”

(John J. Rakos)

Framework PPSIProyek yang baik adalah proyek

yang mencapai titik kesetimbangan antara waktu, biaya dan kualitas

Framework PPSIProject 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

Framework PPSIProject Time Management:

Proses yang dibutuhkan untuk memastikan penggunaan waktu dalam penyelesaian proyek, meliputi: ◦activity definition ◦activity sequencing ◦activity duration estimating ◦schedule development ◦schedule control

Framework PPSIProject Cost Management:

Proses yang dibutuhkan untuk melakukan pengaturan pelaksanaan dengan budget yang sudah disetujui, meliputi: ◦resource planning ◦cost estimating ◦cost budgeting ◦cost control

Framework PPSIProject Quality Management:

Proses yang dibutuhkan untuk memastikan bahwa proyek akan diselesaikan sesuai yang ditetapkan dalam pelaksanaanya, meliputi: ◦quality planning ◦quality assurance ◦quality control

Framework PPSIProject 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

Framework PPSIProject 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

Framework PPSIProject Risk Management:

Proses yang berkonsentrasi dengan identifikasi, analisa dan merespon resiko proyek, misalnya:◦risk identification ◦risk quantification ◦risk response development ◦risk response control

Framework PPSIProject 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

Framework PPSIProject Integration

Management: Proses yang dibutuhkan untuk memastikan berbagai variasi elemen proyek terkoordinasi dengan baik, meliputi:◦project plan development ◦project plan execution ◦overall change control

MetodologiSounds 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

MetodologiSounds 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

MetodologiYang kita inginkan adalah:

◦On Time ◦On Budget◦Have the required features◦Met the quality standards◦Productivity◦Predictability◦Repeatability

MetodologiMetodologi 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

MetodologiSoftware 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

MetodologiContoh 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

MetodologiMengapa ada banyak

metodologi?◦We develop many different types of

applications◦Many different software development

cultures and competitive environments

◦Ego (The drive to be unique)

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

Software Product RDStakeholder

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)

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

Software Product RD

Software Product RDMasalah 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

Software Product RDMasalah 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

Go/No Go DecisionStudi kelayakan bisnis adalah

suatu kegiatan yang cukup mendalam dan komprehensif untuk mengetahui apakah pengembangan usaha yang akan dilakukan layak atau tidak

Go/No Go DecisionMenurut 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

Go/No Go DecisionFaktor-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

Go/No Go DecisionFaktor yang mempengaruhi

seseorang untuk melakukan pengambilan keputusan:◦Kondisi internal dan eksternal

organisasi◦Ketersediaan informasi◦Ketrampilan pengambil keputusan

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

Perencanaan ProyekMeyakinkan 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

Perencanaan ProyekPPPWBSProject Network DiagramProject CostProject SchedulePPP Outline

Perencanaan ProyekPreliminary 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

Perencanaan ProyekWork 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


◦ 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


◦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





Perencanaan ProyekAKTIFITAS USAHA PRECEDENT

Definition 20 -

Analysis 35 Definition

Design 25 Analysis

Program A (control) 20 Design

Program B (registration)

30 Design

Program C (warehouse)

25 Design

System test 10 Program A, B, C

Documentation 20 Design

Acceptance 5 System Test, Documentation

Training 10 Documentation

Operation 10 Acceptance

TOTAL 210 person - days

Perencanaan ProyekProject 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”

Perencanaan ProyekProject Network Diagram

Perencanaan ProyekProject 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

Perencanaan ProyekProject 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

Perencanaan ProyekProject Schedule

Gantt Chart menggunakan Microsoft Project

Perencanaan ProyekPPP Outline

Merupakan garis besar yang diusulkan untuk PPP


◦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


◦ 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

Documents

Pengelolaan Proyek Sistem Informasi