092904006SYAPUTRI ARTAMI S 092904010AYU ANGGRIANI H 092904011RUDI DIAN SYAH 092904030ZUL FADLY SULTHAN 092904035JUMIATI 092904041HUSNAENI 092904043NURHALIMAH.

Presentasi berjudul: "092904006SYAPUTRI ARTAMI S 092904010AYU ANGGRIANI H 092904011RUDI DIAN SYAH 092904030ZUL FADLY SULTHAN 092904035JUMIATI 092904041HUSNAENI 092904043NURHALIMAH."— Transcript presentasi:

1

2 092904006SYAPUTRI ARTAMI S 092904010AYU ANGGRIANI H 092904011RUDI DIAN SYAH 092904030ZUL FADLY SULTHAN 092904035JUMIATI 092904041HUSNAENI 092904043NURHALIMAH

3 kegagalan banyak megaproyek perangkat lunak pada tahun 1960-an dan awal 1970-an merupakan petujuk awal mengenai kesulitan manajemen perangkat lunak. proyek-proyek ini gagal bukan karena manajer atau programer tidak kompeten. Sebaliknya, proyek yang besar dan menantang ini menarik ornga – orang dengan kemampuan diatas rata-rata. Kegagalan yang terjadi ditimbulkan oleh pendekatan manajemen yang digunakan.

4 Kebutuhan akan manajemen merupakan perbedaan penting antara pengembangan perangkat lunak profesional dan pemograman yang amatir. Kita memerlukan majaemen proyek perangkat lunak karena rekayasa perangkat lunak profesional salalu dibatasi oleh anggaran dan jadwal.

5 Manajer perangkat lunak bertanggung jawab dalam merencanakan dan menjadwalkanpengembangan proyek. Mereka mensupervisi pekerjaan untuk menjamin pengerjaan sesuai dengan standar. Menejemen yang baik tidak dapat menjamin keberhasilan proyek. Namun demikian semula, dan gagal memenuhi persyaratan pemesan.

6 Manajemen perangkat lunak melakukan pekerjaan yang sama dengan menejer proyek rekayasa lain. Namundemikian, rekayasa perangkat lunak berbeda dari jenis rekayasa lain karena beberapa hal, manajemen perangkat lunak sangat sulit.

7 Beberapa perbedaan pada Manajemen perangkat lunak 1. Produk pernagkat lunak tidak berwujud. Manjemen proyek pembuatan kapal atau proyek rekayasa sipil dapat melihat produk yang dikembangkan. Jika satu jadwal tidak tepat, efek pada produk akan tampak.bagian-bagian struktur yang bersangkutan jelas tidak selesai. Perangkat lunak tidak dapat dilihat atau disentuh. Manajer proyek perangkat lunak tidak dapat melihat kemajuan. Mereka bergantung pada orang lain yang membuat dokumentasi yang dibutuhkan untuk meninjau kemajuan.

8 2. tidak ada proses perangkat lunak standar. kita tidak memilki pemahaman yang jelas mengenai hubungan antara proses perangkat lunak dan jenis produk. Pada disiplin rekayasa dengan sejarah yang panjang, proses dicoba dan diuji. Proses rekayasa untuk jenis sistem tertentu, seperti jembatan, dipahami dengan baik. Pemahaman kita mengenai proses perangkat lunak telah berkembang dengan signifikan dalam beberapa tahun terakhir ini. Namun demikian, kita tetap tidak dapat meramalkan dengan pasti kapan suatu proses perangkat lunak akan menyebabkan masalah pada pengembangan.

9 3. Proyek perangkat lunak yang besar seringkali merupakan proyek……………….. sangat luas yang dapat dipakai untuk memperkecil ketidakpastian pada rencana. Secara konsekuen, antisipasi masalah lebih sulit. Lebih jauh lagi, perubahan teknologi yang cepat dalam komputer dan komunikasi akan meghapus pengalaman sebelumnya.

10 Kegiatan-kegiatan Manajemen Pekerjaan ini sangat bervariasi, tergantung pada organisasi dan produk perangkat lunak yang dikembangkan. Namun demikian, sebagian besar manajer mengambil tanggung jawab pada beberapa Penulisan proposal

11 Beberapa atau seluruh tahap kegiatan manajemen  Perencanaan dan penjadwalan proyek  Pembiayaan proyek  Pemantauan dan peninjauan proyek  Pemilihan dan evaluasi personel  Penulisan laporan dan presentasi

12 Tahap pertama proyek peragkat lunak dapat melibatkan penulisan proposal untuk melaksanakan proyek tersebut. Proposal mendeskripsikan tujuan proyekdan bagaimana pelaksanaannya. Penulisan proposal merupakan pekerjaan kritis karena keberadaan banyak organisasi perangkat lunak bertanggung pada banyaknya proposal yang telah disetujui dan kontrak yang didapat.

13 Pemantauan proyek merupakan kegiatan proyek yang berkesinambungan. Manajer harus mengetahui kemajuan proyek dan membandingkan kemajuan dan biaya yang sebesarnya dikeluarkan dengan biaya yang direncanakan. Pemantauan informal seringkali dapat meramalkan masalah proyek yang potensial karena pemantauan ini dapat mengungkapkan kesulitan pada saat kejadian.

14 selama berjalannnya proyek adalah normal untuk memiliki sejumlah tinjauan manajemen proyek formal. Tinjauan ini berhubungan dengan peninjauan kemajuan secara keseluruhan dan pengembangan teknis proyek terebut dan mempertimbangkan status proyek terhadap tujuan organisasi yang memesan perangkat lunak tersebut.

15 waktu pengembangan untuk proyek perangkat lunak besar bisa memakan waktu beberapa tahun. Selama itu, tujuan organisasi bisa dipastikan berubah- ubah. Perubahan – perubahan ini dapat menyebabkan perangkat lunak tidak lagi dibutuhkan atau sudah tidak sesuainya bagi persyaratan proyek yang asli.

16 Alasan kebanyakan kasus manajer harus menerima tim proyek yang kurang ideal. 1. Anggaran prroyek mungkin tidak memenuhi penggunaan staf yang harus dibayar mahal. 2. Staf dengan pengalaman yang sesuai mungkin tidak tersedia baik di dalam maupun di luar organisasi. 3. Organisasi mungkin ingin mengembangkan keahlian karyawannya. Staf yang tidak berpengalaman bisa ditugaskan pada suatu proyek untuk belajar dan memproleh pengalaman.

17 Perencanaan Proyek Manajemen yang efektif bagi proyek perangkat lunak bertumpu pada perencanaan kemajuan proyek yang menyeluruh. Manajemen proyek harus mengantisipasi masalah yang mungkin muncul dan menyiapkan solusi tentatif terhadap masalah-malasah tersebut. Rencana ini berubah seiring berjalannya proyek dan tersediannya informasi yang lebih baik.

18 selain rencana proyek, manajer munkin juga harus membuat rencana lainnya. Pseudo-code yang ditunjukan pada Peraga 4.2 mendeskripsikan proses perencanaan proyek untuk pengembangan perangkat lunak. Kerana informasi proyek akan kita dapatkan selama belangsungnya proyek, perncanaan harus direvisi secara reguler. Tujuan bisnis yang utama merupakan faktor penting yang harus diperhitungkan ketika merumuskan rencana proyek.

19 Jika tujuan tersebut berubah, perubahan terhadap rencana proyek perlu dilakukan RencanaKeterangan Rencana kualitasMendeskripsikan prosedur kualitas dan standar yang akan digunakan pada sebuah proyek. Rencana validasiMendeskripsikan pendekatan, sumber daya, dan jadwal yang digunakan untuk validasi. Rencana manajemen konfigurasiMendeskripsikan prosedur dan struktur manajemen konfigurasi yang akan digunakan. Encana pemeliharaanMeramalkan pemeliharaan sistem, biaya pemeliharaan, dan usaha yang dibutuhkan. Peraga 4.1 Jenis- jenis rencana

20 Proses perencanaan dimulai dengan penilaian batasan-batasan ( tanggal penyerahan yang diminta, staf yang tersedia, anggaran total, dll ) yang dipengaruhi proyek. Tahap-tahap kemajuan dan apa yang harus diserahkan pada saat itu kemudian didefenisikan. Proses kemudian memasuki loop.

21 Manajer proyek merevisi asumsi-asumsi proyek dengan bertambah banyaknya informasi yang masuk. Jika proyek tertunda, mereka mungkin harus melakukan negosiasi ulang mengenai batasan proyek dan apa yang harus yang diserahkan kepada pelanggan. tujuan tinjauan ini adalah untuk menemukan pendekatan alternatif terhadap pengembangan yang masuk dalam batasan-batasan proyek dan memenuhi jadwal.

22 Rencana Proyek rencana proyek menentukan sumberdaya yang tersedia bagi proyek, pembagian pekerjaan, dan jadwal untuk melakukan pekerjaan tersebut. Pada beberapa organisasi, rencana proyek merupakan satu dokumen yang mencakup semua jenis rencana. struktur rencana yang saya deskripsikan disini adalah untuk jenis rencana yang kedua. Perincian rencana proyek bervariasi, tergantung pada jenis proyek dan organisasi.

23 Sebagian besar rencana harus mencakup bagian-bagian berikut ini : 1. Pendahuluan. Bagian ini dengan singkat mendeskripsikan tujuan proyek dan menetukan batasan-batasan yang mempengaruhi manajemen proyek. 2. Organisasi proyek. Bagian ini mendeskripsikan bagaimana tim pengembangan diorganisir, siapa saja yang terlibat dan perannya dalam tim. 3. Analisis risiko. Bagian ini mendiskripsikan risiko proyek yang mungkin timbul, kemungkinan munculnya risiko-risiko tersebut dan strategi pengurangan risiko yang diusulkan.

24 4. Persyaratan sumberdaya perangkat keras dan perangkat lunak. Bagian ini mendeskripsikan perangkat keras dan perangkat lunak pendukung yang dibutuhkan untuk melakukan pengembangan. 5. Pembagian kerja. Bagian ini mendiskripsikan pembagian proyek menjadi kegiatan-kegiatan, dan identifikasi patokan dan hasil yang diharapkan dari setiap kegiatan. 6. Jadwal proyek. Bagian ini mendeskripsikan ketergantungan antara kegiatan, perkiraan waktu yang diperlukan untuk mencapai setiap patokan dan alokasi SDM bagi kegiatan-kegiatan tersebut. 7. Monitor dan mekanisme pelaporan. Bagian ini mendeskripsikan laporan manajemen yang dihasilkan, kapan laporan itu harus diberikan, dan mekanisme pemantauan proyek yang digunakan.

25 Patokan (milestone) dan Hasil yang dapat diserahkan (deliverable) Manajer memerlukan informasi. Karena perangkat lunak tidak berwujud, informasi ini hanya dapat diberikan sebagai dokumen yang mendiskripsikan status perangkat lunak yang sedang dikembangkan. Tanpa informasi ini, tidaklah mungkin dilakukan penilaian kemajuan dan perkiraan biaya, sehingga jadwal tidak dapat di update.

26 Penjadwalan Proyek penjadwalan proyek merupakan pekerjaan yang sangat menantang bagi manajer perangkat lunak. Manajer memperkirakan waktu dan sumber daya yang diperlukan untuk menyelesaikan kegiatan dan mengaturnya dalam urutan yang logis. jika proyek tersebut canggih dari segi teknis dari segi teknis, perkiraan awal hampir pasti akan optimis tis bahkan jika manajer mencoba memperhitungkan semua kemungkinan.

27 Kegiatan proyek normalnya harus berdurasi setidak-tidaknya seminggu. Dalam perkiraan jadwal, manajer tidak boleh mengasumsikan bahwa setiap tahap proyek akan bebas dari masalah. Sebagaimana halnya waktu kelender, manajer juga harus memperkirakan sumber daya yang diperlukan untuk menyelesaikan setiap pekerjaan.

28 suatu kaidah yang baik untuk di ikuti adalah membuat estimasi seolah tidak akan ada masalah, kemudian menaikkan nya untuk memperhintungkan masalah yang diantisiapasi. jadwal proyek biasanya dipresentasikan sebagai seperangkat diagram yang menunjukan pembagian pekerjaan, ketergantungan kegiatan, dan alokasi staf.

29 Diagram batang dan jaringan kegiatan Diangram batang dan jaringan kegiatan merupakan notasi grafis yang dipakai untuk mengilustrasikan jadwal proyek. Diagram batang menunjukan siapa yang bertanggung jawab untuk setiap kegiatan dan kapan kegiatan tersebut dijadwalkan dimulai dan berakhir.

30 PekerjaanDurasi (hari)Ketergantungan T18 T215 T315T1 (M1) T410 T510T2, T4 (M2) T65T1, T2 (M3) T720T1 (M1) T825T4 (M5) T915T3, T6 (M4) T1015T5, T7 (M7) T117T9 (M6) T1210T11 (M8) Peraga 4.5 Durasi dan keuntungan pekerjaan

31 lihatlah rangkaian kegiatan yang ditunjukan pada Peraga 4.5. Table tersebut menunjukan kegiatan, durasi dan saling ketergantungannya. Dari peraga 4.5 anda dapat melihat bahwa perkerjaan T3 bergantung pada T1. ini berarti bahwa T1 harus selesai sebelum T3 dimulai. pada tool manajement proyek yang dipakai unutk memebuat diagram ini, semua kegiatan harus berakhir pada patokan. Suatu patokan bisa dimulai ketika patokan sebelumnya(yang munkin tergantungpada beberapa kegiatan) telah dicapai.

32 Dengan demikian kolom, pada kolom ketiga di peraga 4.5, saya juga telah menunjukan patokan patokan yang bersangkutan dengannya, yang dicapai ketika pekerjaan pada kolom tersebut berakhir (lihat Peraga 4.6). Sebelum menuju ke patokan ke patokan yang lainnya, semua jalur yang menuju ke patokan tersebut harus telah selesai. Sebagai contoh,pekerjaan T9, yang ditunjukan pada Peraga 4.6, tidak dapat dimulai sampai pekerjaan T3 dan T6 selesai. Kedatangan pada patokan M4 menunjukan bahwa pekerjaan-pekerjaan ini telah selesai.

33

34 Dilain pihak, penundaan kegiatan yang tidak berada pada jalur kritis tidak perlu menyebabkan ketidaktepatan jadwal secara keseluruhan. Selama penundaan tidak memperlama kegiatan ini sedemikian besar sehingga waktu total melampaui jalur kritis, jadwal proyek tidak akan terpengaruh. Peraga 4.7 merupakan cara alternatifuntuk mempersentasikan informasikan jadwal proyek. Gambar tersebut merupakan diangram batang (kadang kala disebut diagram Gantt, sesuai penemunya) yang menuntujukan kalender proyek dan tanggal dimulainya dan selesainya kegiatannya.

35 Peraga 4.7 Diangram batang kegiatan

36 Peraga 4.9 Alokasi waktu vs diagram waktu

37 Perga 4.8 juga dapat diproses dengan tool pendukung manajemen proyek dan diagram batang dibuat untuk menunjukan periode waktu ketika satf dipekerjakan pada proyek (Peraga 4.9 ) Organisasi besar biasanya memperkerjakan sejumlah spesialis yang bekerja pada proyek sebagaimana diburtuhkan. Hal ini dapat menyebabkan masalah penjadwalan. Jika satu proyek tertunda katika seorang spesialis sedangkan mengerjakannya, hal ini bisa menimbulkan efek tak terduga pada proyek lain.

38 Manajemen Risiko satu tugas penting bagi manajer proyek adalah mengantisipasi risiko yang dapat mempengaruhi jadwal proyek atau kualitas perangkat lunak yang sedang dikembangkan, dan mengambil tidakkan guna menghindari risiko ini.

39 1. Risiko proyek, Risiko yang mempengaruhi jadwal atau sumber daya proyek. 2. Risiko Produk. Risiko yang mempengaruhi kualitas atau kinerja perangkat lunak yang dikembangkan. 3. Risiko bisnis, Risioko yang mempengaruhi organisasi yang sedang mengembangkan atau mengadakan perangkat lunak tersebut.

40 Manajer risioko sangat penting bagi proyek perangkat lunak akibat adanya ketidakpastian yang dihadapi sebagian besar proyek. Jenis-jenis risiko yang yang dapat mempengaruhi proyej yang bergantung pada proyek tersebut dan lingkungan organisasi dimana perangkat lunak tersebut dikembangkan. Namun demikian, banyak risiko yang bersifat universal dan mendeskripsikan bebertapa dinataranya pada Peraga 4.10

41 Peraga 4.10 Risiko perangkat lunak yang mungkin terjadi

42 Peraga 4.11 Proses manajemen Risiko

43 Proses manajemen Risiko di ilustrasikan pada Peraga 4.11 1) Identifikasi risiko. Risiko Proyek, produk dan bisnis yang mungkin terjadi di identifikasi. 2) Nanalisis risiko. Kemungkinan dan konsekuensi risiko-risiko yang di nilai. 3) Perancangan risiko. Dibuat rencana untuk menangani risiko apakah dengan menghindari atau meminimasi afeknya pada proyek. 4) Monitor risiko. Risiko dinilai secara konstan dan rencana unutk meringankan risiko direvisi seiring bertabahnya informasi mengenai risiko tersebut.

44 Identifikasi Risiko Indentifikasi risiko merupakan tahap awaldari manajemen risiko. Tahap ini berkenaan dengan penemuan risiko yang mungkin terjadi pada suatu proyek. Pada prinsipnya, risiko-risiko ini tidak boleh dinilai atau diberi prioritas pada thap ini walaupun, pada prakteknya,risiko dengan konsekuensi yang sangat kecil atau risiko dengan kemungkinan yang sangat rendah biasanya tidak diperhitungkan.

45 Jenis-Jenis Risiko 1) Risko Manusia. 2) Risiko Organisasi 3) Risiko alat bantu 4) Risiko Prasyaratan 5) Risiko ekstimasi

46 Peraga 4.12 Risiko dan jenis risiko

47 Analisis Risiko hasil proses analisis ini harus dimbulasikan dengan table yang disusun menurut keseriusan risiko. Peraga 4.13 mengilustrasikan risiko yang diidentifikasi pada Peraga 4.12. Jelas bahwa penilaian probabilitas dan keseriusan di sini bisa berubah. Tentu saja, baik probalitas maupun penilaian efek risiko bisa berubah dengan tersedianya rencana manajemen risiko. Dengan demikian table ini harus di- update pada setiap iterasi proses risiko.

48 Peraga 4.13 Analisis Risiko

49 Perancangan Risiko Proses perancangan risiko memperhitungkan masing-masing risiko kunci yang telah dikenali dan mengidentifikasi strategi unutk menangani risiko tersebut. Tidak ada proses sederhan yang dapat kita ikuti untuk menetapkan rencana manajemen risiko. Peraga 4.14 menunjukan strategi yang mungkin, yang didentifikasi untuk risiko-risiko kunci pada Peraga 4.13.

50 Peraga 4.1.4 Strategi manajemen Risiko

51 Strategi-strategi ini dibagi menjadi 3 kategori : 1) Strategi menghindar. Strategi ini ditunjukan unutk memperkecil probabilitas munculnya risiko tersebut. 2) Strategi minimasi. Strategi ini ditunjukan untuk memperkecil dampak risiko yang ada. 3) Rencana Kontijensi. Dengan mengikuti strategi ini, jika terjadi yang terburuk.

52 Pemantauan Risiko Pemantauan risiko mencakup penilaian secara reguler dari setiap risiko yang teridetifikasi unutk memutuskan apakah probalitas terjadinya risiko tersebut menjadi lebih besar atau lebih kecil dan apakah efeknya telah berubah. Pemantauan risiko harus merupakan proses yang berkesinambungan dan pada setiap peninjauan kemajuan manajemen, setiap risiko kunci harus dipikirkan secara terpisah dan dibahas dalam rapat.

53 Peraga 4.15 Faktor-faktor risiko

54 Hal-hal penting Manajemen proyek perangkat lunak yang baik sangat penting jika proyek rekayasa perangkat lunak akan dikembangkan tepat waktu dan dalam batasan-batasan anggaran yang ada. Manajemen perangkat lunak berbeda dari manajemen rekasaya lain. Manajer perqangkat lunak memilki peran yang beragam Patokan (milistone) proyek adalah hasil yang dapat dimana laporan formal mengenai kemajuan harus diberikan ke manajemen. Risiko proyek yang besar harus didentifikasi dan dinilai unutk menrapkan probalitas dan konsekuensinya pada proyek.