Project Management Concept Ghina Dwi Mulyani (110400150) Dede Dzurrotun Nisa (110400176) Tyas Silvi Ariyani (110400204) Karina Oktaviani (110400287) SDI Kelas A

4P dalam Manajemen Proyek People: Unsur yang paling penting dari sebuah proyek yang sukses. Product: Perangkat lunak yang akan dibangun. Process: Serangkaian kegiatan kerangka kerja dan tugas-tugas rekayasa perangkat lunak untuk mendapatkan pekerjaan yang dilakukan. Project: Semua pekerjaan yang diperlukan untuk membuat produk menjadi kenyataan.

1. People

Orang Terlibat dalam Proses Perangkat Lunak Stakeholders Team Leaders Software Team Agile (cerdas) Teams

1. Stakeholders Senior managers: yang menentukan isu-isu bisnis yang sering memiliki pengaruh yang signifikan pada proyek. Project (technical) managers yang harus merencanakan, memotivasi, mengatur, dan mengendalikan praktisi yang melakukan kerja perangkat lunak.

Stakeholders… Practitioners (Praktisi) yang memberikan keterampilan teknis yang diperlukan untuk merancang sebuah produk atau aplikasi. Customers yang menentukan persyaratan untuk perangkat lunak yang akan direkayasa dan pemangku kepentingan lainnya yang memiliki minat sekeliling dalam hasilnya. End-users yang berinteraksi dengan perangkat lunak setelah dilepaskan untuk produksi penggunaan.

2. Team Leader Jerry Weinberg menunjukkan MOI Model Kepemimpinan: Motivation. Kemampuan untuk mendorong (dengan "mendorong atau menarik") orang-orang teknis untuk menghasilkan kemampuan terbaik mereka. Organization. Kemampuan untuk membentuk proses yang ada (atau menciptakan yang baru) yang akan memungkinkan konsep awal yang akan diterjemahkan menjadi produk akhir. Ideas or innovation. Kemampuan untuk mendorong orang untuk membuat dan merasa kreatif bahkan ketika mereka harus bekerja dalam batas-batas yang ditetapkan untuk produk perangkat lunak tertentu atau aplikasi.

Karakteristik manajer proyek yang efektif: Pemecahan Masalah Diagnostic Keterampilan untuk memecahkan Kemampuan untuk merancang solusi Identitas manajerial Mengontrol proyek Prestasi Inisiatif reward Mendorong risiko Terkendali mengambil

Pengaruh dan team building Pengaruh tim Membaca pikiran orang dan menanggapi sesuai dengan kebutuhan mereka Dikontrol dalam situasi stres

3. Software Teams Faktor-faktor berikut harus dipertimbangkan ketika memilih struktur tim proyek perangkat lunak sulitnya masalah yang harus dipecahkan ukuran program yang dihasilkan dalam baris kode / fungsi poin waktu bahwa tim akan tetap bersama (seumur hidup tim) sejauh mana masalah dapat termodulasi kualitas yang diperlukan dan keandalan sistem yang akan dibangun Kepastian dari tanggal penyampaian tingkat sosialisasi (komunikasi) yang dibutuhkan untuk proyek

Organizational Paradigms (menurut constsntine) closed paradigm - struktur tim di sepanjang hirarki otoritas tradisional random paradigm - struktur tim longgar dan tergantung pada inisiatif individual anggota tim

Organizational Paradigms… open paradigm - upaya untuk menyusun tim dengan cara yang mencapai beberapa kontrol yang berhubungan dengan paradigma tertutup, tetapi juga banyak inovasi yang terjadi ketika menggunakan paradigma random synchronous paradigm - bergantung pada penggolongan masalah dan mengatur anggota tim untuk bekerja pada bagian dari masalah dengan sedikit komunikasi aktif di antara mereka sendiri.

4. Agile Teams Anggota tim harus memiliki kepercayaan satu sama lain. Distribusi keterampilan harus sesuai dengan masalah. Orang yang tidak konvensionil mungkin harus dikeluarkan dari tim, jika kekompakan tim harus dipertahankan.

Team Coordination & Communication Pendekatan Formal Writings (SE dokumentasi, permintaan pelanggan, dll) Pertemuan review Status Desain dan kode inspeksi Comm non-interaktif dan impersonal lainnya. saluran Pendekatan Informal (lebih pribadi) Interpersonal jaringan Berbagi ide-ide atas dasar ad hoc Mencari bantuan dari dalam maupun luar tim proyek ketika masalah muncul Komunikasi Elektronik E-mail, papan buletin elektronik, konferensi video

2. Product

1. The Product Scope Scope (cakupan) Context. Bagaimana perangkat lunak yang akan dibangun sesuai dengan sistem yang lebih besar, produk, atau konteks bisnis dan apa kendala yang dikenakan sebagai akibat dari konteks? Information objectives. Apa obyek data pelanggan terlihat (Bab 8) yang dihasilkan sebagai output dari perangkat lunak? Apa objek data yang dibutuhkan untuk input? Function and performance. Apa fungsi apakah perangkat lunak melakukan untuk mengubah data input menjadi output? Apakah ada karakteristik kinerja khusus yang akan ditangani? Lingkup proyek perangkat lunak harus jelas dan dimengerti pada tingkat manajemen dan teknis.

2. Problem Decomposition Disebut juga partisi atau masalah elaborasi Kegiatan ini pada intinya analisis kebutuhan Membagi dan menaklukkan kebijakan untuk masalah yang kompleks

3. Process

The Process Setelah kerangka proses telah dibentuk Pertimbangkan karakteristik proyek Menentukan tingkat ketelitian yang diperlukan Tentukan satu set tugas untuk setiap kegiatan rekayasa perangkat lunak

Melding the Problem and the Process

Process decomposition Cara suatu proses dekomposisi tergantung pada kompleksitas proyek Dekomposisi melibatkan menguraikan tugas pekerjaan yang terlibat dalam setiap kegiatan proses kerangka

4. Project

Proyek mendapat kesulitan ketika: Software orang tidak memahami kebutuhan pelanggan mereka. Ruang lingkup produk buruk didefinisikan. Perubahan dikelola buruk. Perubahan teknologi yang dipilih. Kebutuhan bisnis berubah [atau tidak jelas]. Tenggat waktu yang realistis. Users are resistant. Sponsorship hilang [atau tidak pernah diperoleh benar]. Tim proyek tidak memiliki orang-orang dengan keterampilan yang sesuai. Manajer [dan praktisi] menghindari praktek-praktek terbaik dan pelajaran.

How to avoid problems? Start on the right foot (Mulai pada kaki kanan). Melibatkan pemahaman rinci tentang proyek Menetapkan tujuan & harapan yang realistis Memilih tim yang tepat Memfasilitasi tim Maintain momentum (Mempertahankan momentum). Memberikan insentif Mengurangi birokrasi dan memberikan otonomi kepada anggota tim tetapi dengan pengawasan Track progress (Melacak kemajuan). Menilai kemajuan sebagai produk kerja yang dihasilkan.

Make smart decisions (Membuat keputusan cerdas). Bila mungkin, gunakan komponen perangkat lunak yang ada / software COTS Pilih pendekatan standar dan tetap sederhana Hindari risiko dan mengalokasikan lebih banyak waktu dari yang diperlukan untuk tugas-tugas yang kompleks / berisiko Conduct a postmortem analysis (Melakukan analisis postmortem). Bandingkan jadwal yang direncanakan dan aktual Mengumpulkan dan menganalisis metrik proyek (standar) Dapatkan umpan balik dari tim dan pelanggan Menetapkan catatan pelajaran yang dipelajari untuk setiap proyek

W5HH Principle

(Why) Mengapa sistem yang berkembang? Membantu menilai validitas alasan bisnis untuk kerja perangkat lunak. Ini menjawab jika tujuan bisnis membenarkan pengeluaran orang, waktu dan uang (When) Kapan itu dilakukan? Untuk membantu tim membangun jadwal proyek dengan mengidentifikasi ketika tugas harus dilakukan dan kapan tonggak yang dicapai

(What) Apa yang akan dilakukan? Untuk menetapkan set tugas yang dibutuhkan untuk proyek (Who) Siapa yang bertanggung jawab untuk fungsi? Untuk menetapkan peran dan tanggung jawab setiap anggota tim (Where) Di mana mereka organisatoris berada? Untuk menunjukkan bahwa semua peran dan tanggung jawab yang tidak terbatas pada tim perangkat lunak itu sendiri, pelanggan, pengguna dan stakeholder juga memiliki tanggung jawab.

(How) Bagaimana akan menjadi pekerjaan secara teknis maupun manajerial? Setelah lingkup produk adalah menetapkan, strategi teknis dan manajemen harus didefinisikan untuk itu. (How) Berapa banyak dari setiap sumber daya yang dibutuhkan? Dengan mengembangkan perkiraan berdasarkan jawaban dari pertanyaan sebelumnya.

End