Konsep Manajemen Proyek , oleh Rangga [5105 100 131]

Konsep Manajemen Proyek menyangkut teknik yang dipakai untuk menghitung biaya dan kebutuhan sumber daya serta membangun rencana proyek yang efektif.

SPEKTRUM MANAJEMEN
Manajemen proyek perangkat lunak yang efektif berfokus pada tiga P yaitu people (manusia), problem (masalah), dan process (proses). Urutannya tidak dapat berubah.

Ø Manusia
Faktor manusia sangat penting karena Software Engineering Institute telah mengembangkan sebuah model kematangan kemampuan manajemen manusia (PM-CMM) “untuk mempertinggi kesiapan organisasi perangkat lunak untuk mengerjakan aplikasi yang semakin kompleks dengan membantu menarik, menumbuhkan, memotivasi, menyebarkan, dan memelihara bakat yang dibutuhkan untuk mengembangkan kemampuan perkembangan perangkat lunak mereka”[CUR94].
Model kematangan manajemen manusia membatasi area praktik berikut kunci bagi masyarakat perangkat lunak : rekruitmen, seleksi, manajemen unjuk kerja, pelatihan, kompensasi, perkembangan karir, desain kerja dan organisasi, serta perkembangan tim/kultur. Organisasi yang mencapai tingkat kematangan yang tinggi didalam area manajemen manusia memiliki kemiripan yang lebih tinggi dari implementasi praktik rekayasa perangkat lunak yang efektif.
Dari wakil presiden teknik senior sampai pelaksana yang paling rendah dengan penuh kepastian mempertimbangkan faktor manusia. Para manajer berpendapat bahwa manusia merupakan hal yang utama tetapi tindakan mereka kadang-kadang tidak sesuai dengan perkataan mereka.

– Para Pemain
Para pemain dalam proses pembuatan perangkat lunak dikategorikan menjadi lima konstituen antara lain :
1. Manajer Senior, menentukan isu-isu bisnis yang sering mempunyai pengaruh penting dalam proyek.
2. Manajer (Teknik) Proyek, merencanakan, memotivasi, mengorganisasi, dan mengontrol sebuah produk atau aplikasi.
3. Pelaksana, menyampaikan ketrampilan teknik yang diperlukan untuk merekayasa sebuah produk atau aplikasi.
4. Pelanggan, menentukan jenis kebutuhan bagi perangkat lunak yang akan direkayasa.
5. Pemakai Akhir, yang berinteraksi langsung dengan perangkat lunak bila perangkat lunak telah dikeluarkan untuk digunakan.

– Pimpinan Tim
Dari sini timbul suatu pertanyaan bagaimana kita memilih seorang pemimpin sebuah proyek?Dalam bukunya Jerry Weinberg[WEI86] menjawabnya dengan model kepemimpinan MOI :
§ Motivasi adalah kemampuan untuk memberi dorongan kepada orang teknik agar menghasilkan sesuatu dengan kemampuan terbaiknya.
§ Organisasi adalah kemampuan untuk membantu proses yang sedang berlangsung (atau menemukan proses baru) yang memungkinkan konsep dasar diterjemahkan ke dalam suatu hasil akhir.
§ Gagasan dan inovasi adalah kemampuan untuk mendorong manusia menciptakan dan bertindak kreatif dengan solusi-solusi baru.
Pandangan lain [EDG95] mengenai karakteristik yang menentukan seorang manajer proyek yang efektif yaitu :
§ Pemecahan masalah. Seorang manajer proyek yang efektif dapat mendiagnosis isu-isu organisasi dan teknis yang paling relevan, yang secara sistematis membentuk sebuah pemecahan atau dengan tepat memotivasi para pelaksana yang lain untuk membuat pemecahan, menerapkan hasil pengalaman dari proyek-proyek sebelumnya ke situasi baru dan tetap fleksibel untuk mengubah arah jika pendekatan pemecahan masalah semula tidak membuahkan.
§ Identitas manajerial. Manajer proyek harus bersentuhan langsung dengan proyeknya, memiliki rasa percaya diri untuk melakukan kontrol dan membolehkan orang-orang teknik yang baik untuk mengikuti insting mereka.
§ Prestasi. Manajer proyek harus mempunyai inisiatif dan prestasi.
§ Pengaruh dan pembentukan tim. Manajer proyek yang efektif mampu ‘membaca’ atau memahami manusia dan dapat menguasai diri walaupun dalam kondisi tekanan yang sangat tinggi.

– Tim Perangkat Lunak
Dalam organisasi yang mengembangkan perangkat lunak, struktur tim terbaik tergantung oleh gaya manajemen suatu organisasi, jumlah orang dalam tim, tingkat ketrampilannya, dan kesulitan masalah secara keseluruhan.
Mantei [MAN81] mendefinisikan tiga organisasi yang umum antara lain :
§ Demokratis terdesentralisasi (DD). Tim rekayasa ini tidak memiliki pemimpin yang permanen. Tetapi ada koordinator yang dipilih untuk tugas dalam waktu pendek yang akan diganti oleh yang lain mungkin untuk mengkoordinasi tugas yang berbeda. Keputusan dan pendekatan masalah dibuat oleh konsensus kelompok. Komunikasi antara anggota tim bersifat horizontal.
§ Terkontrol terdesentralisasi (CD). Memiliki pemimpin tertentu yang mengkoordinasi tugas-tugas khusus serta memiliki pimpinan-pimpinan sekunder yang bertanggung jawab atas masalah sub-sub tugas. Pemecahan masalah adalah aktivitas dari kelompok namun implementasi dari pemecahan masalah dipecahkan oleh masing-masing sub-sub kelompok oleh pimpinan tim. Komunikasi antar kelompok dan orang bersifat horizontal tetapi komunikasi vertikal sepanjang hierarki kontrol juga terjadi.
§ Terkontrol tersentralisasi (CC). Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur pimpinan tim. Komunikasi antara pimpinan dan anggota tim bersifat vertikal.
rangga1
[gambar 1]

Mantei juga menggambarkan tujuh faktor proyek yang harus dipertimbangkan saat merencanakan struktur tim :
§ Kesulitan masalah yang dipecahkan.
§ Ukuran program-program resultan pada baris kode atau titik fungsi.
§ Waktu tim akan tinggal bersama (umur tim).
§ Tingkat dimana masalah dapat dimodularisasi.
§ Kualitas yang diperlukan serta kehandalan sistem yang dibangun.
§ Kepastian tanggal penyampaian.
§ Tingkat sosiabilitas (komunikasi) yang dibutuhkan untuk proyek tersebut.

Team Type DD CD CC

Difficulty tinggi rendah rendah
Size kecil besar besar
Team Life Time panjang singkat singkat
Modularity rendah tinggi tinggi
Reliability tinggi tinggi rendah
Delivery date longgar longgar ketat/pasti
Sociability tinggi rendah rendah

Constantine [CON93] mengusulkan empat “paradigma organisasional” untuk rekayasa perangkat lunak :
§ Paradigma tertutup sama dengan tim CC karena membentuk tim di sepanjang hirarki otoritas tradisional. Tim jenis ini akan efektif dalam memproduksi perangkat lunak yang mirip dengan apa yang dilakukan sebelumnya. Kelemahannya tim kurang inovatif.
§ Paradigma random sebuah tim yang tergantung inisiatif individual anggota tim sehingga terobosan inovasi atau teknologi akan unggul. Kelemahannya akan berjuang keras bila “unjuk kerja yang teratur” diperlukan.
§ Paradigma terbuka membentuk tim dengan cara tertentu dan memerlukan banyak kontrol tetapi banyak inovasi. Kerja dilakukan secara kolaboratif dengan komunikasi sarat konsensus pada pengambilan keputusan. Cocok untuk pemecahan masalah-masalah yang kompleks tetapi tidak bekerja seefisien tim yang lain.
§ Paradigma sinkron bergantung pada penggolongan alami dari suatu masalah serta mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif diantara mereka sendiri.
Chief pemrogram tim merupakan organisasai tim perangkat lunak yang paling awal dan merupakan sebuah struktur sentralisasi terkontrol. Inti dari tim ini terdiri dari seorang senior engineer yang merencanakan, mengkoordinasi, dan mengkaji semua aktivitas teknik tim; technical staff (terdiri dari dua samapi lima orang) yang melakukan analisa serta mengembangkan aktivitas, dan backup engineer yang mendukung senior engineer dalam aktivitasnya atau juga menggantikan senior engineer untuk masalah-masalah tertentu yang berhubungan dengan kelangsungan proyek. Senior engineer dapat dibantu oleh seorang spesialis, staf pembantu, dan seorang ahli pustaka perangkat lunak. Ahli pustaka ini bertindak sebagai pengontrol, koordinator, dan evaluator yang potensial dari konfigurasi perangkat lunak.

– Masalah Koordinasi dan Komunikasi
Ada beberapa masalah yang ditemui pada proyek perangkat lunak. Hal ini dikarenakan :
§ Skala usaha pengembangan yang besar, kompleksitas yang besar, dan kesultian dalam mengkoordinasi anggota tim.
§ Ketidakpastian, menghasilkan sebuah aliran perubahan yang terus-menerus.
§ Interoperabilitas, perangkat lunak baru harus berkomunikasi dengan perangkat lunak yang sudah ada dan menyesuaikan diri dengan batasan yang sudah ditentukan sebelumnya oleh sistem.
Untuk mengatasi hal itu tim rekayasa perangkat lunak harus membangun metode yang efektif untuk mengkoordinasi orang-orang yang mengerjakan pekerjaan tersebut.
Kraul dan Streeter [KRA95] menguji sekumpulan teknik koordinasi proyek yang dikategorikan dalam kelompok berikut :
§ Pendekatan impersonal, formal : penyampaian dan dokumen rekayasa perangkat lunak (kode sumber), memo-memo teknik, kejadian penting pada proyek dan sebagainya.
§ Prosedur interpersonal, formal : menyangkut pertemuan status pengkajian serta perancangan dan inspeksi kode.
§ Prosedur interpersonal, informal : pertemuan kelompok untuk penyebaran informasi dan pemecahan masalah serta “kolokasi kebutuhan dan pengembangan staf”.
§ Komunikasi elektronik : surat elektronik, papan buletin elektronik, website dan sebagainya.
§ Jaringan interpersonal : diskusi informal dengan orang-orang diluar proyek yang telah memiliki pengalaman atau pengetahuan yang dapat mendukung anggota tim.

Ø Masalah
Pada awal proyek perangkat lunak diperlukan perkiraan kuantitatif dan rencana organisasi tetapi informasi yang solid tidak dapat diperoleh. Analisis yang mendetail tentang kebutuhan perangkat lunak akan memberikan informasi yang memadai untuk suatu perhitungan yang mungkin dapat memakan waktu berminggu-minggu atau bahkan berbulan-bulan.
Beberapa aspek penting antara lain ruang lingkup dan dekomposisi masalah.

– Ruang Lingkup
Ruang lingkup proyek perangkat lunak harus tidak ambigu dan dapat dipahami pada tingkat teknik maupun menajemen. Batasan-batasan dari ruang lingkup :
§ Konteks. Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem, produk, atau konteks bisnis yang lebih besar, serta batasan apa yang ditentukan sebagai hasil dari konteks tersebut?
§ Tujuan Informasi. Objek data pelanggan apa yang dihasilkan sebagai output dari perangkat lunak? Objek data apa yang diperlukan sebagai input?
§ Fungsi dan Unjuk Kerja. Fungsi apa yang dilakukan oleh perangkat lunak untuk mentranformasikan input data menjadi output? Adakah ciri kerja khusus yang akan ditekankan?

– Dekomposisi Masalah
Dekomposisi masalah (partitioning) merupakan sebuah aktivitas yang berkedudukan inti dari analisis kebutuhan perangkat lunak. Dekomposisi diterapkan pada dua area utama yaitu fungsionalitas yang harus disampaikan dan proses yang akan dipakai untuk menyampaikannya.
Dekomposisi Fungsional adalah identifikasi fungsional dari software, kemampuan yang diinginkan oleh pelanggan dan menentukan method/ feature untuk memenuhi fungsional

Contoh fungsi-fungsi untuk word processor :
– pengejaan ejaan
– pengecekan tata bahasa dan kalimat
– pengecekan referensi untuk dokumen-dokumen besar
– validasi referensi subbab dan bab untuk dokumen yang besar

Ø Proses
Inti masalah disini adalah bagaimana memilih model proses yang sesuai bagi perangkat lunak yang akan direkayasa oleh sebuah tim proyek. Beberapa macam-macam model proses antara lain :
§ Model sekuensial linier
§ Model prototype
§ Model RAD
§ Model incremental
§ Model spiral
§ Model asembli komponen
§ Model pengembangan kongkuren
§ Model metode formal
§ Model teknik generasi keempat

Beberapa aspek dalam proses antara lain
– Menggabungkan Masalah dan Proses
Perencanaan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi akan direkayasa oleh tim perangkat lunak harus melampaui sejumlah aktivitas kerangka kerja yang sudah ditentukan.
Sekumpulan aktifitas yang dilakukan untuk membuat perangkat lunak :
§ Komunikasi pelanggan, untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.
§ Perencanaan, untuk menentukan sumber-sumber daya, ketepatan waktu, dan informasi proyek lain.
§ Analisa risiko, untuk memperkirakan risiko-risiko manajemen dan teknis.
§ Rekayasa, untuk membangun satu perwakilan aplikasi atau lebih.
§ Konstruksi dan rilis, untuk membangun, menguji, memasang, dan memberikan dukungan kepada pemakai(dokumentasi).
§ Evaluasi pelanggan, untuk memperoleh umpan balik pelanggan dan hasil evaluasi.

– Dekomposisi Proses
Inti dari dekomposisi proses antara lain
a. Memilih proses model, jadi tim perangkat lunak harus memiliki tingkat fleksibilitas yang signifikan dalam memilih model proses yang paling tepat untuk karakteristik proyek yang akan dikerjakan. Sebagai contoh : untuk proyek yang besar dan terus dikembangkan melalui versi-versi misalnya sangat cocok pada model proses MSF.
b. Mendefinisikan perencanaan proyek berdasarkan proses model yang dipilih.
c. Mengontrol aktivitas beradasarkan proses model – Common process framework (CPF) adalah invarian dan berfungsi sebagai dasar bagi semua kerja perangkat lunak yang dilakukan oleh organisasi perangkat lunak.

RANGKUMAN

Manajemen proyek perangkat lunak merupakan umbrella activity dalam rekayasa perangkat lunak. People, problem, process mempunyai pengaruh yang mendasar dalam manajemen proyek perangkat lunak. Manusia harus diorganisasi ke dalam tim-tim efektif, termotivasi, untuk melakukan kerja perangkat lunak kualitas tinggi serta dikoordinasi untuk mencapai komunikasi yang efektif. Masalah harus dikomunikasikan dengan baik dari pelanggan ke pengembang dan didekomposisikan ke dalam bagian-bagian kerja. Proses juga harus sesuai dengan manusia dan masalah.

3 Responses to “Konsep Manajemen Proyek , oleh Rangga [5105 100 131]”


  1. 1 amorin November 28, 2009 pukul 7:13 am

    tulisan yang menarik. jangan berhenti menulis ya.
    tetap semangat!

  2. 2 ika Mei 12, 2010 pukul 3:11 am

    tulisannya bgs,trims bgt ya


Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s




Arsip

RSS My Blog

  • Pindahan! Februari 13, 2012
    Para pembaca sekalian, mulai hari ini blog ini pindah ya.. alamatnya di www.handyeka.com Posting-posting terbaru akan muncul di alamat baru tersebut. Terima kasih :)
  • Selamat Tahun Baru 2012! Januari 26, 2012
    Selamat tahun baru 2012!! Bagaimana tahun 2011 yang baru saja kita lewati ini? pasti banyak up-and-down nya. Biasanya orang kalau ngomongin tahun baru mesti nanyain resolusi tahun baru, tapi kali ini saya ga mau nanya-nanya tentang resolusi, hahaha.. kenapa? karena … Continue reading →
  • Adele – Someone Like You Oktober 10, 2011
    Pernahkah Anda merasakan jatuh cinta.. namun pada akhirnya Anda hanya bisa mengagumi dia yang Anda cinta karena Anda berdua sayangnya tidak bisa bersatu.. namun ia akhirnya bisa bahagia.. meskipun bukan bersama Anda.. Sakit.. dan penuh emosi jiwa pastinya.. tapi apakah … Continue reading →

RSS Recipee World

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Indonesia Travel Guide

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

RSS Music Info Online

  • Sebuah galat telah terjadi; umpan tersebut kemungkinan sedang anjlok. Coba lagi nanti.

%d blogger menyukai ini: