KONSEP MANAJEMEN PROYEK (BAB 3)
nama anggota kelompok :
1. Ahmad Ihsan 081401058 2. Imam Matra 101401042 3. Wahyu Eko Putra 101401044 4. Poppy Tania 101401018
Overview
• Project management terdiri dari planning, monitoring, dan kontrol terhadap orang, proses, dan kejadian-kejadian yang timbul selama pengembangan software.
• Setiap orang mengatur pekerjaannya berdasarkan pada lingkup kerja dan aturan masing-masing.
• Software perlu untuk di manage, karena software merupakan suatu hal yang komplek dengan durasi waktu yang lama.
• Project menagement software yang efektif harus fokus pada 4 P agar kesuksesan (People, product, process, dan project)
• Rencana proyek adalah suatu dokumentasi yang ada pada 4P seperti memastikan biaya efektif, produk software kulaitas tinggi.
• Suatu cara untuk memastikan bahwa rencana proyek terlaksana dengan benar adalah dengan meng-observasi bawa suatu produk berkualitas tinggi telah dikerjakan tepat waktu dan budget yang sesuai.
3.1 Spektrum Manajemen
3.1.1 Manusia
Factor manusia sangat penting sehingga Software Enginering Institute telah mengembangkan sebuah model kematangan kemampuan manjemen masusia (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 . Model kematangan manajemen manusia membatasi area praktik berikut kunci bagi masyarakat perangkat lunak: rekruitmen, seleksi, manajemen untuk untuk kerja, pelatihan, kompensasi, perkembangan karir , desain kerja dan organisasi, dan perkemangan tim/kultur. Organisasi yang mencapai tingkat kematangan yang tinggi didalam area manajemen manusia memiliki kemiripan yang lebih tnggi dari implementasi praktik rekaysa perangkat lunak yang efektif.
3.1.2 Masalah
Sebelum proyek direncanakan, obyektifitas dan ruang lingkupnya harus ditetapkan, pemecahan alternatifnya harus dipertimbangkan, teknik dan atas pun harus didefinisikan. Sekali tujuan dan ruang ligkup proyek di pahami, pemecahan alternatifnya dapat di pertimbangkan. Meskipunhanya sedikit saja yang didiskusikan,alternative tersebut memungkinkan manajer dan pelaksanaan memilih sebuah pendekatan ”terbaik” menentukan penghalang yang di sebabkan oleh batas waktu penyampaian, ketentuan anggaran, ketersediaan personil, interface teknis, dan banyak lagi factor yang lain.
3.1.3 Proses
Proses perangkat lunak memberikan suatu kerangka kerja dimana rencana komprehensif bagi pengembangan perangkat lunak dapat di bangun. Sejumlah kecil aktifitas kerangka kerja dapat di aplikasikan pada semua proyek perangkat lunak, tanpa mempedulikan ukuran dan kompleksitasnya.
3.1.4 Project
faktor kritis kesuksesan yang membawa pada manajemen projek yang baik, dan mengembangkan pendekatan terbarukan untuk perencanaan, pengawasan dan pengendalian projek.
3.2 Manusia
Manusia dalam proses rekayasa perangkat lunak. Yang karena itu kita semua, dari wakil presiden teknik senior sampai pelaksanaan yang paling rendah, dengan penuh kepastian mempertimbangkan factor manusia. Para manajer ber argument bahwa manusia merupakan hal yang utama. Namun demikian, tindakan mereka kadang-kadang tidak sesuai dengan perkataan mereka.
3.2.1 Para Pemain
Proses perangkat lunak diisi oleh para pemain yang dapat dikategorikan ke dalam salah satu dalam lima konstituen berikut ini :
Manajer senior, yang menentukan isu-isu bisnis yang sering memiliki pengaruh penting didalam proyek.
Manajer proyek, yang harus merencanakan, memotivasi, mengorganisir dan mengontrol sebuah produk atau aplikasi.
Pelaksanaan , yang menyampaikan ketrampilan teknik yang di perlukan untuk
merekayasa sebuah proyek atau aplikasi.
Pelanggan, yang menentukan jenis kebutuhan bagi perangkat lunak yang akan
direkayasa.
Pemakai akhir, yang berinteraksi dengan perangkat lunak bila perangkat lunak
telah dikeluarkan untuk digunakan.
Setiap proyek perangkat lunak dihuni oleh para pemain seperti yang ditulis.
3.2.2 Pimpinan Tim
Manajemen proyek merupakan kegiatan manusia intensif, dan karena alasan itu para praktisi yang cakap sering melemahkan pemimpin tim. Dalam sebuah buku yang sangat menarik tentang kepemimpinan teknik, jerry Weinberg cenderung menjawab pertanyaan tersebut dengan mengusulkan model kepemimpinan MOI :
Motivasi
Kemampuan untuk member dorongan orang teknik untuk menghasilkan sesuatu dengan kemampuan terbaiknya.
Kemampuan untuk membentuk prosesyang sedang berlangsungyang memungkinkan konsep dasar diterjemahkan kedalam suatu hasil akhir.
Gagasan dan inovasi
Kemampuan untuk mendorong manusia untuk menciptakan dan bertindak kreatif meskipun mereka bekerja didalam suatu ikatan yang dibangun untuk suatu produk atau aplikasi perangkat lunak yang spesifik.
Pandangan lain menurut Edgemon tentang karakteristik yang menentukan seorang manajer proyek yang efektif memberikan tekan pada empat kata kunci:
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 sebelumnya ke situasi yang baru, dan tetap fleksibel untuk mengubah arah jika pendekatan pemecahan masalah semula tidak membuahkan hasil. Identitas manajeral.
Seorang manajer proyek yang baik harus bersentuhan secara langsung dengan proyeknya. Prestasi. Untuk mengoptimasi produktifitas sebuah tim proyek, seorang manajer harus memiliki inisiatif dan prestasi, serta dengan caranya sendiri memperlihatkan bahwa pengambilan resiko yang terkontrol tidak akan dikenai hukuman.
Pengaruh dan pembentukan tim. Seorang manajer proyek yang efektif harus mampu “membaca” manusia; dia harus mampu memahami sinyal verbal dan nonverbal serta bereaksi terhadap kebutuhan-kebutuhan orang-orang yang mengirim sinyal tersebut.
3.2.3 Tim Perangkat Lunak
Struktur tim “terbaik” tergantung pada gaya manajemen sebuah organisasi, jumlah orang yang akan ada tim tersebut, dan tingkat keterampilannya, serta kesulitan masalah secara keseluruhan, Mantei [MAN81] mengusulkan tiga organisasi tim yang umum:
Demokrasi terdesentralisasi(DD). Tim rekayasa perangkat lunak ini tidak memiliki yang permanen . Tetapi “koordinator” dipilih untuk bertugas di dalam durasi waktu yang pendek, yang kemudian diganti oleh yang lain yang mungkin bertugas untuk mengkoordinasi tugas-tugas yang berbeda.
merupakan aktivitas dari kelompok, tetapi implementasi dari pemecahan masalah di pecah di antara sub-sub kelompok oleh pimpinan tim.
Terkontrol tersentralisasi (CC). Koordinasi pemecahan masalah tingkat puncak dan internal tim diatur oleh pimpinan tim. Komonikasi antara pimpinan dan anggota tim bersifat vertical.
Mantei juga menggambarkan tujuh faktor proyek yang harus dipertimbangkan pada saat merencanakan struktur tim rekayasa perangkat lunak:
Kesulitan masalah yang akan dipecahkan
Ukuran program-program resultan pada baris kode atau titik fungsi Waktu tim akan tinggal bersama (umur tim)
Tingkat di mana masalah dapat dimodularisasi
Kualitas yang diperlukan serta keandalan sistem yang dibangun Kepastian tanggal penyampaian
Tingkat sosiabilitas(komunikasi) yang dibutuhkan untuk proyek tersebut. Tim yang tersentralisasi biasa membutuhkan lebih banyak waktu untuk
menyelesaikan sebuah proyek daripada struktur yang tersentralisasi, dan pada saat yang sama merupakan pilihan yang terbaik bila sosiabilitas yang tinggi di perlukan .
Constantine(CON93)mengusulkan empat “paradigma organisasi” bagi tim rekayasaperangkat lunak:
1. Paradigm tertutup membebtuk sebuah tim di sepanjang hirarki otoris tradisional (sama dengan tim CC). Tim semacam itu dapat berkerja dengan baik pada saat memproduksi perangkat lunak yang sangat mirip dengan apa yang dilakukan sebelumnya; tetapi tim kurang inovatif ketika bekerja dalam paradigm tertutup 2. Paradigma random membentuk sebuah tim secara longgar dan tergantung pada
inisatif individual anggota tim. Pada saat terobosan inovasi atau teknologi dibutuhkan, tim yang mengikuti paradigma random akan unggul. Tetapi tim semacam ini dapat berjuang keras bila “unjuk kerja yang teratur” diperlukan. 3. Paradigma terbuka cenderung membentuk tim dengan cara tertentu sehingga
tercapai banyak control yang berhubungan dengan paradigm tertutup, tetapi sekaligus juga banyak inovasi pada saat menggunakan paradigm random. 4. Paradigm sinkron bertumpu pada penggolongan alami dari suatu masalah serta
mengorganisasi anggota tim untuk bekerja pada bagian-bagian kecil masalah dengan komunikasi aktif diantara mereka sendiri.
Ada banyak alasan mengapa proyek perangkat lunak menemui kesulitan. Skala usaha pengembangan yang besar, kompleksitas yang semakin besar, dan kesulitan dalam mengkoordinasi anggota tim. Ketidakpastian adalah umum, membuahkan sebuah aliran perubahan yang terus menerus yang menggelindingkan tim proyek.
Interoperabilitas menjadi cirri-ciri kunci dari banyak sistem. Perangkat lunak yang baru harus berkomunikasi denagn perangkat lunak yang sudah ada dan menyesuiakan diri dengan batasan yang sudah ditentukan sebelumnya oleh sistem atau produk.
Karakteristik modern perangkaqt lunak ini – skala, ketidakpastian, dan
interoperabilitas – adalah kenyataan kehidupan. Kraul dan Streeter [KRA95] menguji kesimpulan teknik koordinasi proyek yang dikatagorikan dalam kelompok berikut: Pendeketan impersonal, formal. Mencakup penyampaian dan dokumen rekayasa perangkat lunak(seperti kode sumber), memo-memo teknis, kejadian penting pada proyek, jadwal dan peranti control proyek, kebutuhan akan perubahan dan
dokumentasi yang berhubungan, laporan pelacakan kesalahan, dan data cadangan. Prosedur interpersonal, formal. Berfokus pada aktivitas jaminan kualitas yang diterapkan pada produk kerja rekayasa perangkat lunak. Hal ini menyangkut pertemuan status pengajian serta perancangan dan inspeksi kode.”
Prosedur interpersonal, informal. Menyangkut pertemuan kelompok untuk penyerbaran informasi dan pemecahan masalah serta “kolokasi” kebutuhan dan pengembangan staff.”
Komunikasi elektronik. Mencangkup surat elektronik, papan bulletin elektronik, Web stes, serta sistem konfersi berbasis video.
Jaringan interpersonal. Dikusi informal dengan orang-orang di luar proyek yang mungkin memiliki pengalaman atau pengetahuan yang dalam yang dapat mendukung anggota tim.
3.3 Masalah (Product)
Seorang manajer proyek perangkat lunak dihadapkan pada sebuah dilemma pada awal proyek rekayasa perangkat lunak. Diperlukan perkiraan kuantitatif dan rencana
secara regular pada saat proyek berjalan. Tetapi walaubagaimanapun diperlukan suatu rencana. Kita harusmengamati masalah pada awal dimulainya sebuah proyek.
3.3.1 Ruang lingkup
Aktivitas manajemen proyek perangkat lunak yang pertama adalah menentukan ruang lingkup perangkat lunak. Ruang lingkup dibatasi dengan menjawab pertanyaan-pertanyaan berikut :
Konteks
Bagaimana perangkat lunak yang akan dibangun dapat memenuhi sebuah sistem,produk atau kontek 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 dan objek data apa yang diperlukan sebagai input.
Fungsi dan unjuk kerja
Fungsi apa yang dilakukan oleh perangkat lunak untuk mentransformasi input data menjadi output. Adakah ciri kerja khusus yang akan ditekankan.
3.3.2 Decomposisi Masalah
Dekomposisi masalah sering juga disebut partitioning (pembagian), merupakan sebuah aktivitas yang mendudukan inti dari analisis kebutuhan perangkat lunak. Dekomposisi diterapkan pada 2 area utama : 1. Fungsionalitasyang harus disampaikan dan 2. Proses yang akan dipakai untuk menyampaikannya.
Sementara ruang lingkup berkembang, pembagian tingkat pertama secara alami berlangsung. Tim proyek belajar bagaimana bagian pemasaran telah berbicara dengan pelanggan yang potensial dan mendapati bahwa fungsi-fungsi berikutini seharusnya menjadi bagian dari copy editing otomatis :
Pengecekan ejaan
Pengecekan tata bahasa kalimat
Pengecekan refrence untuk dokumen-dokumen yang besar. lValidasi refrence subbab dan bab untuk dokumen yang besar.
3.4 Proses
paling sesuai untuk proyek tertentu, yang kemudian menentukan sebuah rencana utama yang didasarkan pada sejumlah aktifitas kerangka kerja proses yang umum. Sekali rencana pendahuluan di bangun,dekomposisi proses dimulai, yaitu rencana sepenuhnya meresfleksikan tugas kerja yang dibutuhkan utuk mengisi aktivitas kerangka kerja yang harus dibuat.
3.4.1 Menggabungkan masalah dan proses
Perencanaan proyek dimulai dengan menggabungkan masalah dan proses. Setiap fungsi yang akan direkayasa oleh tim perangkat lunak harus melampui sejumlah aktivitas kerangka kerja yang sudah ditentukan bagi sebuah organisasi perangkat lunak. Misalnya organisasi sudah mengadopsi serangkaian aktivitas kerangka kerja sebagai berikut :
Komunikasi pelanggan
Tugas-tugas yang diperlukan untuk membangun komunikasi yang efektif diantara pengembang dan pelanggan.
Perencanaan
Tugas-tugas yang diperlukan untuk menentukan sumber-sumber daya,ketepatan waktu dan informasi proyek yang lain.
Analisis Resiko
Tugas-tugas yang diperlukan untuk memperkirakan resiko-resiko manajemen dan teknik
Rekayasa
Tugas-tugas yang diperlukan untuk membangun satu perwakilan aplikasi atau lebih
Kontruksi da rilis
Tugas-tugas yang diperlukan untuk membangun , menguji , memasang dan memberikan dukungan kepada pemakai.
Evaluasi pelanggan
Tugas-tugas yang diperlukan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak yang diciptakan selama masa rekayasa serta diimplementasi selama masa instalasi.
3.4.2 Dekomposisi proses
dilakukan oleh organisasi perangkat lunak. Dekomposisi proses dimulai ketika manajer proyek bertanya : “bagaimana kita menyelesaikan aktifitas CPF ini ?” contohnya proyek yang relative sederhana dan kecil kemungkinan membutuhkan tugas kerja sebagai berikut bagi aktifitas komunikasi pelanggan :
Mengembangkan daftar isu klarifikasi
Bertemu dengan pelanggan untuk menekankan isu klarifikasi Secara bersama mengembangkan pernyataan ruang lingkup. Mengkaji keadaan lapangan dengan seluruh pendapat yang ada. Memodifikasi pernyataan jangkauan sesuai keperluan.
Mengendalikan sebuah proyek yang lebih kompleks yang memiliki ruang lingkup yang lebihluas serta pegaruh bisnis yang signifikan. Proyek semacam itu memerlukan tugas-tugas – tugas-tugas kerja sebagai berikut untuk kegiatan komunikasi pelanggan :
Mengkaji kebutuhan pelanggan
Merencanakan dan menjadwal sebuah pertemuan formal dengan pelangganan
yang di fasilitasi.
Melakukan penelitian untuk menentukan pemecahan yang diusulkan dan
pendekata yang ada.
Mempersiapkan “dokumen kerja” serta agenda untuk pertemuan formal. Mengadakan pertemuan.
Mengkaji setiap perincian kecil tersebut untuk upaya perbaikan,konsistensi dan
mengurangi abiguitas.
Memasang perincian kecil kedalam sebuah dokumen ruang lingkup Mengkaji dokumen yang membatasi dengan semua pendapat yang ada. Memodifikasi dokumen.
3.5 Projek
Para prpofesional industri yang payah sering mengacu aturan 90-90 pada saat mendiskusikan proyek-proyek perangkat lunak yang sukar : 90 persen dari sistem yang pertama menyerap 90 persen dari usaha dan waktu yang diberikan. yang 10 persen terakhir mengambil 90 persen lain dari usaha dan waktu yang diberikan . Pernyataan tersebut menginformasikan bahwa banyak proyek yang menemui kesulitan :
1. Orang-orang software tidak mengerti kebutuhan pelanggan mereka. 2. Ruang lingkup produk didefinisikan buruk.
3. Perubahan dikelola buruk.
4. Perubahan teknologi yang dipilih.
7. Pengguna bertahan.
8. Sponsorship hilang [atau tidak pernah diperoleh dengan benar].
9. Tim proyek tidak memiliki orang-orang dengan keterampilan yang sesuai. 10. Manajer [dan praktisi] menghindari praktek-praktek terbaik dan pelajaran yang dipelajari.
Untuk mengatasi masalah tersebut, pada awal sebuah proyek harus ada waktu yang dialokasikan untuk membangun sebuah rencana yang realistis, selama proyek berlangsung untuk memonitor rencana, dan pada keseluruhan proyek untuk mengontrol kualitas serta perubahannya.
Solusi :
• Mulai dengan hal yang benar • Maintain momentum
• Track progress
• Membuat keputusan cerdas • Conduct a postmortem analysis
3.6 W5HH Principle
• Why is the system being developed?
Jawaban atas pertanyaan ini memungkinkan semua pihak untuk menilai keabsahan alasan bisnis untuk pekerjaan software. Dinyatakan dalam cara lain, apakah tujuan bisnis
membenarkan pemberdayaan orang, waktu, dan uang?
• What will be done by When?
Jawaban atas pertanyaan-pertanyaan ini membantu tim untuk membuat jadwal proyek dengan mengidentifikasi tugas-tugas proyek kunci dan tonggak yang dibutuhkan oleh pelanggan.
• Who is responsible for a function?
Sebelumnya dalam bab ini, kami mencatat bahwa peran dan tanggung jawab masing-masing anggota tim perangkat lunak harus didefinisikan. Jawaban atas pertanyaan ini akan membantu mencapai hal ini.
Tidak semua peran dan tanggung jawab berada dalam tim perangkat lunak itu sendiri. Para pelanggan, pengguna, dan stakeholders lainnya juga memiliki tanggung jawab. • How will the job be done technically and managerially?
Setelah lingkup produk didirikan, manajemen dan strategi teknis untuk proyek tersebut harus didefinisikan.
• How much of each resource is needed?
Jawaban atas pertanyaan ini diperoleh dengan mengembangkan perkiraan (Bab 5) berdasarkan pada jawaban atas pertanyaan sebelumnya.
3.7 Critical Practices (Praktek Kritis)
Praktek-praktek ini adalah konsisten digunakan oleh, dan dianggap kritis oleh, proyek perangkat lunak yang sangat sukses dan organisasi yang kinerjanya 'bottom line' secara konsisten jauh lebih baik daripada rata-rata industri.
• Management resiko formal
• Perkiraan biaya dan jadwal secara empiris/kenyataan • Management project Metric-based
• Nilai penghasilan
• People-aware program management
3.8 Ringkasan
Tiga P memiliki pengaruh yang mendasar pada manajemen proyek perangkat lunak : people (manusia), problem (masalah), dan process (proses).
Manusia harus diorganisasi ke dalam tim-tim yang efektif, termotivasi, untuk melakukan kerja perangkat lunak kualitas tinggi, serta dikoordinasi untuk mencapai komunikasi yang efektif.
Masalah harus dikomunikasikan dari pelanggan ke pengembang, dibagi (didekomposisi) ke dalam bagian-bagian konstituennya, serta ditempatkan untuk kerja oleh tim perangkat lunak.
