SOAL GANJIL 1.

Jelaskan maksud dari spektrum manajemen dan pengertian dari masing masing fokusnya Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus pada 3 P + 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

2. Pengelompokan manusia dlm pengembangan PL ! a. Player (Pemain) - Manajer Senior menentukan isu bisnis yangmempengaruhi dalam proyek - Manajer Proyek merencanakan, memotivasi, mengorganisir, 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 (Pimpinana 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)

3. organisasi tim yg diusulkan Mantei 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.

4. teknik koordinasi proyek oleh kraul dan streeter 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

5. model model proses 1. Sekunsial Linier Classic Life Cycle / model air terjun 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

6. tujuan pengukuran PL Untuk menyatakan kualitas produk Untuk menilai kulitas manusia yg terlibat dalam pembuatan produk. Untuk menilai keuntungan pemakaian metode & alat bantu yg baru. Sebagai dasar untuk melakukan perkiraan. Untuk membantu penyesuaian pemakaian alat bantu yg baru atau pelatihan tambahan.

7. metrik dan indikator Metrics (metrik) : Ukuran kuantitatif dari tingkat dimana sebuah sistem, komponen, atau proses memiliki atribut tertentu. RPL mengumpulkan pengukuran & mengembangkan metrik sehingga diperoleh suatu indicator. Indicator (indicator) : Sebuah metrik atau kombinasi dari metrik yg memberikan pengetahuan kedalam proses PL, sebuah proyek PL, atau produk itu sendiri.

8. indikator proyek 1. memperkirakan status sebuah proyek yg sedang berlangsung 2. menelusuri resiko-resiko potensial 3. menemukan area masalah sebelum masalah menjadi semakin kristis. 4. menyesuaikan aliran kerja atau tugas-tugas. 5. mengevaluasi kemampuan tim proyek untuk mengontrol kualitas hasil kerja RPL.

9. metrik proyek Tujuan metrik proyek : 1. untuk meminimalkan jadwal pengembangan dengan melakukan penyesuaian yg diperlukan untuk menghindari penundaan serta mengurangi masalah & resiko potensial. 2. untuk memperkirakan kualitas produk pada basis yg berlaku, dan bila dibutuhkan, memodifikasi pendekatan teknis untuk meningkatkan kualitas.

10. pengukuran PL secara tidak langsung Yang diukur pada pengukuran tidak langsung adalah : fungsi kualitas kompleksitas efisiensi keandalan kemampuan pemeliharaan

11. yang mempengaruhi estimasi - Project complexity (kompleksitas proyek) - Project size (ukuran proyek) - Struktural uncertainty (ketidakpastian struktural)

12. informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang) * Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan. - Siapa di belakang permintaan kerja ini? - Siapa yang akan memakai solusi ini? - Apakah keuntungan ekonomi dari solusi yang sukses?

- Adakah sumber daya lain bagi solusi ini? * Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan pelanggan menyuarakan persepsi tentang sebuah solusi. - Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan oleh sebuah solusi yg baik? - Masalah apa yang dituju solusi ini? - Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai? - Adakah batasan atau isu kinerja

13. Putnam dan Myers mengusulkan 4 masalah penentuan ukuran : - Fuzzy-logic sizing (logika kabur) Perencana harus mengidentifikasi tipe aplikasi, membuat besarannya dalam skala kuantitatif kemudian dibandingkan dengan rentang orisinil. - Function point sizing Perencana mengembangkan estimasi berdasarkan karakteristik domain informasi. - Standard component sizing PL dibangun dari sejumlah 'komponen standar' yg umum (subsistem, modul, laporan, program interaktif). - Change sizing Digunakan jika PL yang ada harus dimodifikasi dengan banyak cara sebagaibagian dari proyek.

14. kelas proyek PL dalam model COCOMO 1. Model Organik Ukuran proyek relatif kecil, PL yang dibuat atau dikembangkan lebih simpel dengan aplikasi kerja yg baik. Misal program analisis termal yang dikembangkan untuk kelompok transfer panas. 2. Model Semi Detached Ukuran proyek dan kekompleksan perangkat cukup besar dengan pengalaman kerja campuran (ada yg telah berpengalaman dan ada yg belum berpengalaman). Misal sistem pemrosesan transaksi dengan syarat tertentu untuk perangkat keras terminal dan perangkat lunak database. 3. Model Embedded Ukuran proyek dan kekompleksan PL yg dikembangkan atau dikerjakan besar. Misal perangkat lunak kontrol penerbangan untuk pesawat udara.

15. keputusan make-buy 1. PL dapat dibeli (atau lisensi) off-the-self.

2. Komponen PL full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri. 3. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli. Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb: 1. Tanggal penyampaian 2. Biaya yang diperlukan 3. Dukungan

16. definisi konseptual mengenai resiko oleh Robert Charette 1. Resiko berhubungan dengan kejadian di masa yg akan datang. 2. Resiko melibatkan perubahan (spt. perubahan pikiran, pendapat, aksi, atau tempat) 3. Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan.

17. kategori resiko menurut Robert Charette Resiko yang sudah diketahui adalah resiko yg dpt diungkap setelah dilakukan evaluasi secara hati2 terhadap rencana proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya. seperti : - tgl penyampaian yg tdk realitas - kurangnya persyaratan yg terdokumentasi - kurangnya ruag lingkup PL - lingkungan pengembangan yg buruk Resiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya : - pergantian staf - komunikasi yg buruk dgn para pelanggan - mengurangi usaha staff bila permintaan pemeliharaan sedang berlangsung dilayani Resiko yang tidak diharapkan resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.

18. identifikasi resiko dan tipe resiko Identifikasi resiko dalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek.

Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan. Tipe resiko : 1. resiko generik merupakan ancaman potensial pd setiap proyek PL. 2. resiko produk spesifik hanya dapat diidentifikasi dgn pemahaman khusus mengenai teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada. Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko.

19. aktifitas proyeksi resiko Dua cara melakukan proyeksi risiko : 1. Probabilitas di mana risiko adalah nyata 2. Konsekuensi masalah yang berhubungan dengan risiko Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko : 1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan 2. Menggambar konsekuensi risiko 3. Memperkirakan pengaruh risiko pada proyek dan produk 4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman

20. faktor penilaian resiko Tiga factor yg mempengaruhi konsekuensi jika suatu risiko benar-benar terjadi : 1. Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi 2. Ruang lingkupnya; menggabungkan kepelikannya (seberapa seriusnya masalah ini ? ) dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi atau berapa banyak pelanggan terganggu ? ) 3. Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.