520 likes | 776 Views
Pengelolaan Proyek Sistem Informasi. Fase Definisi. Outline. Framework PPSI Metodologi Software Product RD Go/No Go Decision Perencanaan Proyek. Framework PPSI. “Project always begin with Problem” (John J. Rakos ). Framework PPSI.
E N D
PengelolaanProyekSistemInformasi FaseDefinisi
Outline • Framework PPSI • Metodologi • Software Product RD • Go/No Go Decision • PerencanaanProyek
Framework PPSI • “Project always begin with Problem” (John J. Rakos)
Framework PPSI • Proyekyang baikadalahproyek yang mencapaititikkesetimbanganantarawaktu, biayadankualitas
Framework PPSI • Project Scope Management: Proses yang dibutuhkanuntukmenentukanlingkupproyektermasuksegalaprosesdansemuapekerjaan yang dibutuhkanuntukmenyelesaikanproyek, meliputi: • initiation • scope planning • scope definition • scope verification • scope change control
Framework PPSI • Project Time Management:Proses yang dibutuhkanuntukmemastikanpenggunaanwaktudalampenyelesaianproyek, meliputi: • activity definition • activity sequencing • activity duration estimating • schedule development • schedule control
Framework PPSI • Project Cost Management:Proses yang dibutuhkanuntukmelakukanpengaturanpelaksanaandengan budget yang sudahdisetujui, meliputi: • resource planning • cost estimating • cost budgeting • cost control
Framework PPSI • Project Quality Management:Proses yang dibutuhkanuntukmemastikanbahwaproyekakandiselesaikansesuai yang ditetapkandalampelaksanaanya, meliputi: • quality planning • quality assurance • quality control
Framework PPSI • Project Human Resource Management:Proses yang dibutuhkanuntukmembuatpemanfaatan SDM yang paling efektif yang terlibatdenganproyektersebut, meliputi: • organizational planning • staff acquisition • team development
Framework PPSI • Project Communications Management:Proses yang dibutuhkanuntukmemastikanproyektepatwaktu, menyediakanbagian-bagianinformasi, koleksi, penyebaran, penyimpanandandisposisiterakhirinformasiproyek, meliputi: • communications • planning • information distribution • performance reporting • administrative closure
Framework PPSI • Project Risk Management:Proses yang berkonsentrasidenganidentifikasi, analisadanmeresponresikoproyek, misalnya: • risk identification • risk quantification • risk response development • risk response control
Framework PPSI • Project Procurement Management:Proses yang dibutuhkanuntukmendefinisikankebutuhandanlayanandariluarorganisasi yang dapatmempengaruhikelangsunganproyek, misalnya: • procurement planning • solicitation planning • solicitation • source selection • contract administration • contract close-out
Framework PPSI • Project Integration Management:Proses yang dibutuhkanuntukmemastikanberbagaivariasielemenproyekterkoordinasidenganbaik, meliputi: • project plan development • project plan execution • overall change control
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
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
Metodologi • Yang kitainginkanadalah: • On Time • On Budget • Have the required features • Met the quality standards • Productivity • Predictability • Repeatability
Metodologi • Metodologiadalahdeskripsidariprosesuntukmembawasuatuproduk software melaluisemuaatausebagiandarilife cycle • Biasanyaberfokuspadafaselife cycledanrelasiantarafase yang satudenganlainnya
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
Metodologi • Contohdarimetodologi 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) • HajarBlehTM Programming
Metodologi • Mengapaadabanyakmetodologi? • We develop many different types of applications • Many different software development cultures and competitive environments • Ego (The drive to be unique)
Software Product RD • Tujuandanlingkupproduk, baikdarisudutteknismaupunbisnis • Identifikasi stakeholder • Perkiraanpasar • Gambarantentangproduk • 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 • Evaluasidanperforma
Software Product RD • Stakeholder Bukanhanyapihak yang mempekerjakananalis, tetapijugatermasuk: • 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 • Masalahdalam 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 RD • Masalahdalam 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 Decision • Studikelayakanbisnisadalahsuatukegiatan yang cukupmendalamdankomprehensifuntukmengetahuiapakahpengembanganusaha yang akandilakukanlayakatautidak
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
Go/No Go Decision • Faktor-faktorpenyebabkegagalansuatubisnis: • Data daninformasitidaklengkapatauadanyaketidaklengkapandankepalsuandata • Tidaktelitiatauadanyakecerobohan yang menyebabkankesalahan • Salahperhitunganatauadanyakesalahansaatperhitunganataupunrumus-rumus yang digunakan • Pelaksanaanpekerjaansalahatauadanyapekerja yang tidakmengerjakanproyekberdasarkanpedoman yang ditetapkan • Kondisilingkunganatauadanyaunsur-unsuryang tidakdapatdikendalikan • Unsursengajaatauadanyakesalahan yang disengajaolehpenelitidenganberbagaisebab. Hal inisangatfatal
Go/No Go Decision • Faktoryang mempengaruhiseseoranguntukmelakukanpengambilankeputusan: • Kondisiinternal daneksternalorganisasi • Ketersediaaninformasi • Ketrampilanpengambilkeputusan
Go/No Go Decision • Aspek-aspekpenilaiandalamstudikelayakanadalah: • Aspekhukum: untukmenelitikelengkapan, kesempurnaandankeaslianizin-izindandokumen-dokumen • Aspekpasardanpemasaran: menelitibesarpasardankemampuanperusahaanmenguasainya, sertamenilaistrateginya • Aspekkeuangan: menilaiperolehanpendapatandanbiaya yang dikeluarkan • Aspekteknis/operasional: menentukanlokasi, layout gedungdanruangansertateknologi yang digunakan • Aspekmanajemen: menelitikesiapan SDM yang menjalaniusaha • Aspekekonomidansosial: menilaimanfaatusahaterhadapekonomidansosialmasyarakat • Aspekdampaklingkungan: menilaidampaklingkungan yang dapatditimbulkan
PerencanaanProyek • Meyakinkanrekan-rekanyang lain bahwaproyektersebutsebaiknyadibuatdenganmembuatsebuah proposal • Sebuah proposal adalahdokumen yang merincibiayadanjadwalproyeksertagarisbesarlangkahlangkah yang akandigunakanolehsuatuperusahaanuntukmemproduksiproduk
PerencanaanProyek • PPP • WBS • Project Network Diagram • Project Cost • Project Schedule • PPP Outline
PerencanaanProyek • Preliminary Project Plan (PPP) Sebuahrencanauntukproyeksoftware yang menjabarkanakrifitas yang diinginkan, berapa lama setiapaktifitasdilakukan, kapanaktifitasiniharusmengambiltempatdanberapabanyaksumberdaya yang dihabiskanpadasetiapaktifitasuntukmemproduksihasilyang diinginkan
PerencanaanProyek • Work Breakdown Structure (WBS) • Dekomposisisuatuproyekmenjadikomponen yang lebihkecil • Memilikistrukturtree • Komponennyadapatberupaproduk, data, layanan, ataucampuran • WBS menyediakankerangkakerja yang dibutuhkanuntukperkiraanbiayadankontrolsehinggamemudahkanpengembanganpenjadwalan
PerencanaanProyek • 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
PerencanaanProyek • Work Breakdown Structure (WBS) • Sampaikapandilakukan? • dapatdiperkirakansecararealistis • komponensudahtidakmungkinuntukdibagilagi • dapatdilaksanakanmengikutiaturan-aturan yang disebutkansebelumnya • menghasilkansuatuhasil yang dapatdiperkirakan
PerencanaanProyek • Work Breakdown Structure (WBS)
PerencanaanProyek • Work Breakdown Structure (WBS)
PerencanaanProyek • Work Breakdown Structure (WBS)
PerencanaanProyek • Work Breakdown Structure (WBS)
PerencanaanProyek • Project Network Diagram • Menggambarkanurutankomponenproyekdanketergantungannya (dependency) • “The work breakdown structure show the "part-whole" relations. In contrast, the project network shows the "before-after" relations”
PerencanaanProyek • Project Network Diagram
PerencanaanProyek • Project Cost • Jikakontrakdariproyeksudahdisetujui, manajerproyekdapatmenghitunghargakotor, untuktenagakerjadenganmengalikanjumlahbiayaburuh per haridengan biaya rata-rata per hari • Jikaandamenghitungbiayasecaramanual danandayakinbahwa total perkiraandari 210 orang/hari, hargaproyek dengan mengalikan 210 denga rata-rata biaya per hari, dan menambah biayatetapperalatan
PerencanaanProyek • Project Schedule • Salahsatukesulitantugasiniadalahmengalokasikansumberdayamanusia yang akan melakukan pekerjaan yang akan dilaksanakan, terutama ketikatugasberjalansecaraserentak. Kesulitan lain adalahmemutuskanbagaimanamempersingkatpekerjaan yang akandilakukandenganmenggunakansumberdaya yang ada
PerencanaanProyek • Project Schedule Gantt Chart menggunakan Microsoft Project
PerencanaanProyek • PPP Outline Merupakangarisbesar yang diusulkanuntuk PPP
PerencanaanProyek • PPP Outline • Project team, organisasidaritimproyek, siapayang membuatlaporanuntuksiapa, siapaberkomunikasidengansiapadanlain-lain • Biayaproyek, perkiraandanperhitungan yang dipergunakanuntukmenentukanharga/biaya • Jadwalproyek, Merupakanintidariproyek • Pemeriksaanulang, tujuan dari setiap pemeriksaan dan siapa yang akan menghadirinya, catattanggungjawabsemuaorang yang terlibatdidalamnya
PerencanaanProyek • PPP Outline • Laporan, bentukdanisidarilaporan status, laporan milestone dandokumenproyek lain dirincidisini, sertadaftarorang yang menerimatiaplaporandanapatanggapannyasetelahmenerimalaporantersebut • Dokumentasi, dokumenmana yang akandiproduksidantanggapan yang bersangkutandari 2 jenisdokumendidalamproyek: penggunadanmanajemenproyek • Kesimpulan, fakta-faktayang diberikankepadaanda (kadang-kadanglisan) olehpengguna