KONSEP MANAJEMEN PROYEK

dokumen-dokumen yang mirip
BAB III KONSEP MANAJEMEN PROYEK

SOFTWARE PROJECT MANAGEMENT

Konsep Manajemen Proyek

Manajemen Proyek Sistem Informasi DAY-1. Wiratmoko Yuwono, ST

MANAJEMEN PROYEK PERANGKAT LUNAK SOFTWARE PROJECT MANAGEMENT

STAKEHOLDER DAN TEAM MEMBER RPL. Ni Wayan Sumartini Saraswati

MANAJEMEN PROYEK PERANGKAT LUNAK PROYEK Proyek adalah suatu kegiatan mengkoordinasikan segala sesuatu dengan menggunakan perpaduan sumber daya

5. Aktivitas generic dalam semua proses perangkat lunak antara lain adalah : a. Spesifikasi dan pengembangan b. Validasi dan evolusi c.

MANAJEMEN PROYEK PERANGKAT LUNAK

Manajemen Proyek. Bima Cahya Putra, M.Kom

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

Konsep Manajemen sebuah Proyek bisa difokuskan pada beberapa komponen berikut ini:

Teknik Informatika S1

Bab 4 Metodologi Pengembagan Sistem(Perangkat Lunak)

MODEL PENGEMBANGAN SISTEM

MANAJEMEN PROYEK SOFTWARE

Metode-Metode Pengembangan Desain Aplikasi

A Layered Technology

Ratna Wardani. Department of Electronic Engineering Yogyakarta State University

Pertemuan 3. Manajemen Proyek Perangkat Lunak. Proses Dalam Manajemen PL

Manajemen Proyek Perangkat Lunak

Rekayasa Perangkat Lunak DEPARTEMEN PENDIDIKAN NASIONAL UNIVERSITAS PENDIDIKAN INDONESIA 2008

Dibuat Oleh : 1. Andrey ( )

Pertemuan 3. Manajemen Proyek Perangkat Lunak

REKAYASA PERANGKAT LUNAK

P14 Manajemen Proyek Sistem Informasi. A. Sidiq P.

PENGEMBANGAN PERANGKAT LUNAK

Pertemuan 3 Metodologi Pengembangan Sistem Informasi

REKAYASA PERANGKAT LUNAK

BAB III KONSEP MANAJEMEN PROYEK. Kegagalan banyak mega proyek perangkat lunak pada tahun 1960-anmerupakan

BAB III MANAJEMEN PROYEK SISTEM INFORMASI

PERTEMUAN 2 METODE PENGEMBANGAN SISTEM

Jenis Metode Pengembangan Perangkat Lunak

PERTEMUAN 2 METODE PENGEMBANGAN SISTEM

BAB 4 PROSES PERANGKAT LUNAK & METRIK PROYEK

PROSES PERANGKAT LUNAK & METRIK PROYEK

APLIKASI PERHITUNGAN HONOR MENGAJAR DOSEN TIDAK TETAP YANG BERBASIS PRESENSI DENGAN MENGGUNAKAN BARCODE Oleh: Wiwik Sulistiyorini (A

BAB II LANDASAN TEORI

Tujuan Perkuliahan. PENGANTAR RPL (Pert. 2 chapter 1 Pressman) Agenda. Definisi Software (Perangkat Lunak) Lunak) 23/09/2010

MANAJEMEN RESIKO. Aprilia Sulistyohati, S.Kom. Jurusan Teknik Informatika Universitas Islam Indonesia. Your Logo

REKAYASA PERANGKAT LUNAK

REKAYASA PERANGKAT LUNAK

Manajemen Proyek Perangkat Lunak Disiapkan oleh: Umi Proboyekti, S.Kom, MLIS

Pengelolaan Proyek Sistem Informasi. Manajemen Sumber Daya Proyek

BAB 6 METODOLOGI SIKLUS HIDUP SISTEM

BAB1. PENDAHULUAN Siklus hidup sistem (SLC) SDLC Systems Development Life Cycle Siklus Hidup Pengembangan Sistem Systems Life Cycle

Hanif Fakhrurroja, MT

1. MODEL WATERFALL KOMUNIKASI PERENCANAAN PEMODELAN PENYERAHAN KE PELANGGAN / PENGGUNA KONSTRUKSI. Permulaan proyek. Analisis perancangan

Tugas Softskill. Universitas Gundarma. : Sistem Informasi Manajemen. : Waldhi Supriono NPM : Kelas : 2 DB 12

BAB 7.PENJADWALAN & PENELUSURAN PROYEK

BAB 7.PENJADWALAN & PENELUSURAN PROYEK

A. Tujuan dan Ruang Lingkup Proyek Perancangan Rekayasa Perangkat Lunak

MAKALAH REKAYASA PERANGKAT LUNAK ( SIKLUS HIDUP PERANGKAT LUNAK )

Lecture s Structure. Siklus Hidup Sistem. Metodologi Siklus Hidup Sistem

Rekayasa Perangkat Lunak (Software Engineering)

THE SOFTWARE PROCESS

BAB I PENDAHULUAN. Hampir semua perusahaan menyadari besarnya peranan teknologi. dalam menunjang bisnis yang dijalani. Berbagai macam proyek teknologi

BAB II TINJAUAN PUSTAKA Definisi Faktor Sukses, Kontraktor dan Perumahan

MANAJEMEN PROYEK WEB

PENGELOLAAN PROYEK SISTEM INFORMASI

Metodologi pengembangan sistem METODOLOGI PENGEMBANGAN SISTEM INFORMASI DIAN PALUPI RINI, M.KOM 1

BAB 1 PENDAHULUAN. 1.1 Latar Belakang

Tantangan Dasar Desain Organisasi

BAB 1 BAB 1 PENDAHULUAN

BAB 1 PENDAHULUAN. 1.1 Latar Belakang. 1.2 Rumusan Masalah

chapter 7 Integrating quality activities in the project life cycle Empat model proses pengembangan perangkat lunak akan dibahas dalam bagian ini:

BAB II LANDASAN TEORI

BAB 2 LANDASAN TEORI

TUJUAN KULIAH BAHASAN

COMPUTER SYSTEM ENGINEERING

Dibuat Oleh : 1. Andrey ( )

MATERI PEMODELAN PERANGKAT LUNAK KELAS XI RPL

SISTEM INFORMASI AKUNTANSI

BAB II LANDASAN TEORI

STMIK AMIKOM YOGYAKARTA

Estimasi Proyek Perangkat Lunak. Universitas Gunadarma

REKAYASA PERANGKAT LUNAK I ALIF FINANDHITA, M.T. - TEKNIK INFORMATIKA UNIKOM 1

MANAJEMEN PROYEK : KONTEKS DAN PROSES

REKAYASA PERANGKAT LUNAK. 3 sks Sri Rezeki Candra Nursari reezeki2011.wordpress.com

Pertemuan 2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

BAB III LANDASAN TEORI. yang disusun guna menyelesaikan masalah secara sistematis. Pada bab ini akan

BAB III OBJEK DAN METODE PENELITIAN. berlokasi di Jl. Leuwi Panjang No. 111 Bandung Telpon Terbaik dalam pelayanan servis di bengkel.

Pengembangan Sistem Informasi

Pertemuan 4 Manajemen Proyek (2) Rekayasa Perangkat Lunak

BAB 1 Teknik dan Metode Manajemen Proyek

BAB V PENGEMBANGAN SISTEM PENDUKUNG KEPUTUSAN

Proyek Pengembangan Sistem Informasi

Ign.F.Bayu Andoro.S, M.Kom. Mata Kuliah Rekayasa Perangkat Lunak

Pengembangan Sistem Informasi

Paktikum : 4-7 Judul Praktikum : System Development Life Cycle (SDLC)

Hanif Fakhrurroja, MT

BAB III LANDASAN TEORI

STRUKTUR ORGANISASI. By Nina Triolita, SE, MM. Pertemuan Ke 10 Pengantar Bisnis

Chapter 1 The software quality challenge

BAB I PENDAHULUAN 1.1. Latar Belakang

BAB I PENDAHULUAN. 1.1 Latar Belakang Masalah. Penjualan adalah proses kegiatan menjual, yaitu dari kegiatan penetapan

PENGANTAR MANAJEMEN PROYEK PERANGKAT LUNAK MATA KULIAH MANAJEMEN PROYEK PERANGKAT LUNAK

BAB 7.PENJADWALAN & PENELUSURAN PROYEK

REKAYASA PERANGKAT LUNAK I

SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC) Siklus Hidup Perangkat Lunak (SWDLC/Software Development Life Cycle)

Transkripsi:

KONSEP MANAJEMEN PROYEK Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3 P, dimana harus berurut yaitu PEOPLE : Elemen terpenting dari suksesnya proyek PRODUCT / PROBLEM : Software yang dikembangkan PROCESS : Suatu kerangka kerja dari suatu aktifitas dan kumpulan tugas untuk memgembangkan PL PROJECT (tambahan) : Penggabungan semua kerja untuk membuat produk menjadi kenyataan 3.1 PEOPLE ( MANUSIA) SEI telah mengembangkan suatu model kematangan kemampuan manajemen manusia (People Management Capability Manurity Model ( PM CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka. Model kematangan manajemen manusia membatasi pada Rekruitmen Seleksi Manajemen unjuk kerja Pelatihan Kompensasi Pemgembangan karir Desain kerja & organisasi Perkembangan karir tim / kultur

Manusia dalam pengembangan PL terdiri dari : a. Player (Pemain) - Manajer Senior menentukan isu bisnis yang mempengaruhi dalam proyek - Manajer Proyek merencanakan, memotivasi, mengorga-nisir,mengontrol aplikasi/produk - Pelaksana mempunyai ketrampilan teknik untuk merekayasa aplikasi - Pelanggan menentukan jenis kebutuhan bagi PL yang akan dibuat - Pemakai akhir yang berinteraksi dengan PL yang dibuat b. Team Leader (Pimpinan Tim) Manajemen proyek merupakan kegiatan manusia intensif sehingga memerlukan praktisi yang cakap. Model Kepemimpinan (MOI yaitu Motivasi, Organisasi, gagasan & Inovasi) menurut Jerry Weinberg. Karakteristik yang menentukan manajer proyek efektif yaitu - Pemecahan Masalah - Prestasi - Identitas manajerial - Pengaruh & pembentukan tim c. The Software Team ( Tim PL) Sumber daya manusia kepada sebuah proyek yang akan membutuhkan n manusia yang bekerja selama k tahun, ada beberapa alternatif untuk menentukan sumber daya tersebut : - n orang mengerjakan tugas fungsional berbeda sebanyak m dengan sedikit kombinasi kerja & koordinasi tanggung jawab manajer proyek - n orang mengerjakan tugas fungsional berbeda sebanyak m (m<n), seorang pemimpin tim ad hoc dapat dipilih, koordinasi bertanggung jawab manajer PL

- n orang diatur di dalam tim, setiap orang mengerjakan >= 1 tugas fungsional, setiap tim mempunyai sebuah struktur spesifik yang ditentukan untuk semua tim yang bekerja pada sebuah proyek, koordinasi dikontrol oleh tim itu sendiri dan oleh manajer proyek PL ( sistem ini paling produktif) Mantei, mengusulkan 3 organisasi tim yaitu: Demokrasi terdesentralisasi (DD) Tidak memiliki pimpinan permanen dan koordinator dipilih untuk tugas pendek bila tugas berbeda maka pimpinan berbeda. Keputusan diambil oleh konsensus kelompok dan komunikasi secara horizontal Terkontrol terdesentralisasi (CD) Tim memiliki pimpinan tertentu dan memiliki pimpinan skunder untuk sub-sub masalah. Pemecahan masalah merupakan aktifitas dari kelompok dan implentasi pemecahan pada sub-sub kelompok. Komunikasi antar kelompok dan orang bersifat horizontal tetapi komunikasi secara vertical berjalan bila hirarki kontrol berjalan. Terkontrol tersentralisasi (CC) Pemecahan tingkat puncak dan internal tim oleh pimpinan tim. Komunikasi dilakukan secara vertical. 7 faktor proyek yang harus dipertimbangkan dalam rencanakan tim RPL yaitu : 1. Kesulitan pada masalah 2. Ukuran program yang dihasilkan (LOC / function) 3. Waktu tim (umur) 4. Tingkat dimana dapat dimodularitasi 5. Kualitas serta keandalan 6. Kepastian tanggal penyampaian 7. Tingkat sosiabilitas / komunikasi

Pengaruh Karakteristik Proyek pada Struktur Tim Tipe Tim DD (Demokrasi terdesentralisasi) CD (Terkontrol terdesentralisasi) CC (Terkontrol tersentralisasi) Tingkat Kesulitan o Tinggi x o Rendah x x Ukuran o Besar x x o Kecil x Umur Tim o Singkat x x o Panjang x Modularitas o Tinggi x x o Rendah x Keandalan o Tinggi x x o Rendah x Tanggal Pengiriman o Ketat/pasti x o Longgar x x Sosiabilitas o Tinggi x o Rendah x x Sedangkan Constantine, mengusulkan 4 paradigma organisasional bagi tim RPL 1. Paradigma Tertutup Membentuk hirarki otoritas tradisional ( mirip tim CC/(Terkontrol tersentralisasi)) tetapi kurang inovatif

2. Paradigma Random Membentuk tim longgar & tergantung pada inisiatif individual tim, untuk inovasi sangat baik(unggul) bila unjuk kerja tim teratur. 3. Paradigma Terbuka Membentuk tim dengan cara tertentu sehingga banyak kontrol, inovasi banyak. Cocok untuk masalah yang kompleks tetapi tidak seefesien tim lainnya 4. Paradigma Sinkron Mengorganisasikan tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif pada tim d. Coordinatian & Communication Issue (masalah koordinasi & komunikasi) Proyek PL mengalami kesulitan dikarenakan : Skala usaha pengembangan yang besar sehingga kesulitan dalam mengkoordinasi anggota tim & Kompleksitas yang semakin besar Ketidakpastian mengakibatkan perubahan terus menurus pada proyek Interoperabilitas merupakan ciri dari sistem dan menyesuaikan dengan batasan sistem Kraul & Streeter menguji sekumpulan teknik koordinasi proyek yang dibagi atas Pendekatan impersonal, formal penyampaian & dokumen RPL (memo, laporan dll) Prosedure interpersonal, formal aktifitas jaminan kualitas yang diterapkan kepada produk kerja RPL (status pengkajian, perancangan & inpeksi kode) Prosedure interpersonal, informal pertemuan kelompok untuk menyebarkan informasi & pemecahan masalah serta pengembangan staf Komunikasi teknik, surat elektronis, web sites, teleconferens, papan buletin elektronik

Jaringan interpersonal diskusi informal pada orang diluar proyek untuk mendapatkan pengalaman sehinnga mendukung kerja proyek 3.2 PROBLEM / PRODUCT Analisis yang mendetail mengenai kebutuhan PL akan memberikan informasi untuk menghitung perkiraan kuantitatif & perencanaan organisasi. Tetapi itu sulit karena informasi yang diberikan customer tidak lengkap. Ruang lingkup masalah dibatasi dengan : - Konteks PL yang dibangun memenuhi sistem, produk / konteks bisnis yang lebih besar serta batasan yang menentukan hasilnya - Tujuan informasi Objek pelanggan yang dihasilkan sbg output dr PL yang dapat digunakan sebagai input - Fungsi & unjuk kerja PL digunakan untuk mentransformasikan input menjadi output Pernyataan ruang lingkup dibatasi (data jumlah pemakai simultan, ukuran pengiriman, waktu mak respon ), batasan /& jangka waktu dicatat (biaya produk membatasi jumlah memori) & factor mitigasi (algoritma yang dibutuhkan software aplikasi (pemograman)) Dekomposisi Masalah / pembagian masalah diterapkan pada : - Fungsionalitas yang disampaikan - Proses yang dipakai

3.3 PROCESS Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan - Sejumlah kumpulan tugas yang berbeda, kemampuan penyampaian & jaminan kualitas - Aktifitas pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran Model PROSES : 1. Sekunsial Linier Classic Life Cycle / model air terjun(waterfall model) 2. Prototipe Perencanaan kilat untuk konstruksi oleh prototype 3. Rapid Aplication Development (RAD) Model sekunsial linier yang menekankan siklus pengembangan yang sangat pendek dengan pendekatan konstruksi berbasis komponen 4. Inkremental (Pertambahan) Menggabungkan elemen-elemen model sekunsial linier dengan filosopi prototype iterative khusus untuk staffing

5. Spiral Merangkai sifat iterative dari prototype dengan cara kontrol & aspek sistematis dari sekunsial linier 6. Rakitan Komponen Paradigma orientrasi obyek menekankan kreasi kelas yang mengenkapsulasi data & algoritma yang dipakai untuk memanipulasi data (gabungan dengan karakter spiral) 7. Perkembangan Komponen Sering dipakai untuk mengembangkan aplikasi client server Aktifitas dibagi menjadi : - dimensi sistem : desain, assembly & pemakai - dimensi komponen : desain & realisasi 8. Metode Formal Mengkhususkan, mengembangkan, & menverifikasi sistem berbasis komputer dengan notasi matematis yang tepat (Clean room RPL) 9. Teknik Generasi Keempat Serangkaian alat bantu PL yang secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasaan 1,2 3 (konvensional) sisanya evolusioner Harus ditentukan model paling banyak memawakili pelanggan, karakteristik produk & lingkungan proyek Serangkaian aktifitas kerja PL : 1. Komunikasi pelanggan 2. Perencanaan 3. Analisa Resiko 4. Rekayasa 5. Konstruksi dan rilis 6. Evaluasi Pelanggan

Dekomposisi Proses Bila batasan waktu yang ketat diberikan dan masalah dapat dipecah-pecah, model RAD mungkin pilihan yang paling tepat. Tugas kerja yang actual bervariasi sehingga dekomposi proses dimulai pada saat bagaimana menyesesaikan kerja proses secara umum. 3.5 PROYEK Profesional industri sering mengacu pada aturan 90-90 yaitu pada saat mendiskusikan proyek PL yang sukar maka 90 % dr sistem yang pertama menyerap 90 % dari usaha & waktu yang diberikan. 10 %terakhir mengambil 90 % lain dari usaha & waktu yang diberikan. Dr penyataan tersebut proyek mengalami kesulitan yaitu 1. Kemajuan mengalami kecacatan 2. Tidak ada cara untuk mengkalibrasi kemajuan karena tidak memperoleh matrik kuantitatif 3. Rencana proyek belum dirancang untuk mengakomodasi sumber daya yang diperlukan pada akhir sebuah proyek 4. Resiko-resiko belum mempertimbangkan secara eksplisit serta belum dibuat rencana untuk mengurangi, mengatur & memonitor 5. Jadual yang ada tidak realistis & cacat Untuk mengatasi masalah tersebut maka diperlukan waktu pada awal proyek untuk membangun rencana yang realistis guna memonitor rencana proyek selama berjalan & pada keseluruhan proyek serta mengontrol kualitas serta perubahannya.