REKAYASA PERANGKAT LUNAK

Transkripsi

1 REKAYASA PERANGKAT LUNAK Page 1 / 224

2 PERKENALAN DOSEN- MAHASISWA Nama : Hendra Jatnika Tempat Tinggal : Garut Bandung Pendidikan : Kegiatan : Dosen 1. D3 Informatika MIPA UNPAD Bandung 2. S1 STMIK-IM Bandung 3. S2 STMIK-LIKMI Bandung 1. Politeknik Piksi Ganesha 2. LP3i Bandung 3. A2K-Proklamasi 4. UNIBI : Konsultan IT/Si Hp ( Mhs ) : Profile : hendra-jatnika.web.id hendranetid@ymail.com (Konsultasi ) : mailtugashendranet@ymail.com ( tugas ) FB/Google : hendra jatnika Page 2 / 224

3 PERANGKAT LUNAK Perangkat Lunak (Software) tidak sama dengan program komputer. Perangkat lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan, yang diperlukan untuk membuat agar program beroperasi dengan benar. Sistem Perangkat Lunak terdiri dari : Sejumlah program yg terpisah File-file konfigurasi Dokumentasi sistem Dokumentasi User Page 3 / 224

4 Dua tipe produk perangkat lunak : Produk Generik Sistem stand-alone standar yg diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped. Contoh : pengolah kata (word processor). Produk pesanan (yang disesuaikan) Sistem yg dipesan oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan sistem kontrol lalu lintas udara. Page 4 / 224

5 Perbedaan PENTING antara tipe2 perangkat lunak : Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak. Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut. Page 5 / 224

6 REKAYASA PERANGKAT LUNAK RPL atau Software Engineering (SE) Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Ada 2 istilah kunci disini : disiplin rekayasa Perekayasa membuat suatu alat bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan selektif dan selalu mencoba mencari solusi terhadap permasalahan. semua aspek produksi perangkat lunak RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL. Page 6 / 224

7 PERBEDAAN ANTARA RPL DENGAN COMPUTER SCIENCE? Intinya, computer science berhubungan dengan teori dan metode yang mendasari sistem komputer dan perangkat lunak, sedangkan RPL berhubungan dengan praktek dalam memproduksi perangkat lunak. Page 7 / 224

8 PERBEDAAN RPL DENGAN REKAYASA SISTEM? Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem. Page 8 / 224

9 PROSES PERANGKAT LUNAK Serangkaian kegiatan dan hasil-hasil relevannya yang menghasilkan perangkat lunak sebagian besar dilakukan oleh perekayasa perangkat lunak. Ada 4 kegiatan/aktivitas pada proses PL : 1. Spesifikikasi Perangkat Lunak Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan. 2. Pengembangan Perangkat Lunak Perangkat lunak yang memenuhi spesifikasi harus di produksi 3. Validasi Perangkat Lunak Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan. 4. Evolusi Perangkat Lunak Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan. Page 9 / 224

10 MODEL PROSES PERANGKAT LUNAK Merupakan deskripsi yang disederhanakan dari proses perangkat lunak di presentasikan dengan sudut pandang tertentu. Bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat pada rekayasa perangkat lunak (Perekayasa PL). Page 10 / 224

11 CONTOH JENIS MODEL PROSES PL 1. Model aliran kerja (workflow) menunjukkan kegiatan pada proses bersama dengan input, output, dan ketergantungannya. Merepresentasikan pekerjaan manusia. 2. Model aliran data (data flow) merepresentasikan proses sebagai suatu set kegiatan yang melakukan transformasi data. Menunjukkan bagaimana input ke proses, misalnya spesifikasi ditransformasi menjadi output, misalnya menjadi desain. 3. Model peran/aksi merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg menjadi tanggung Page jawab 11 / 224 mereka.

12 MODEL ATAU PARADIGMA UMUM PADA PROSES PL 1. Model air terjun (waterfall) Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya. 2. Pengembangan evolusioner Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan Page 12 / 224 kebutuhan pelanggan.

13 3. Pengembangan Sistem Formal Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program. 4. Pengembangan berdasarkan pemakaian ulang (Reusable) Teknik ini menganggap bahwa bagianbagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian sistem dan bukan pengembangannya dari awal. Page 13 / 224

14 BIAYA REKAYASA PERANGKAT LUNAK Umumnya sekitar 60% untuk biaya pengembangan (development) dan 40% biaya pengujian (testing). Distribusi biaya yang tepat selama proses perangkat lunak bergantung pada proses yang digunakan dan jenis perangkat lunak yang dikembangkan. Page 14 / 224

15 REKAYASA PERANGKAT LUNAK PERANCANGAN ARSITEKTUR PERANGKAT LUNAK Page 15 / 224

16 ARSITEKTUR PERANGKAT LUNAK An abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections. The interconnections define provide by which components interact. How the system is decomposed and organized into components and must describe the interfaces between these components. Page 16 / 224 2

17 ARSITEKTUR PERANGKAT LUNAK ( 2 ) Gambaran bagaimana elemen/komponen fungsional perangkat lunak disusun, diorganisasi dan distrukturkan sehingga: Hubungan antar elemen/komponen dapat dijelaskan. Interface yang menghubungkan elemen/komponen dapat didefinisikan. Wujud dan penempatan elemen/komponen dalam tempat penyimpanan sekunder secara fisik dapat ditetapkan. Page 17 / 224 3

18 CONTOH ARSITEKTUR PERANGKAT LUNAK ( 1 ) Model Analisis (DFD level atomik) id_mhs Petugas info_mhs Cari Info Mahasiswa Arsitektur Perangkat Lunak (Fisik) call mahasiswa Search NIM : Cari Script dan Procedure Cari(NIM) query/select Tabel Mahasiswa NIM Nama Kelas display hasil query Page 18 / 224 4

19 CONTOH ARSITEKTUR PERANGKAT LUNAK ( 2 ) Model Analisis (DFD level atomik) 1 Tambah Data Barang id_barang Bag ian Penjualan Modul Pemanggil rec_barang Barang rec_supplier Supplier rec_supplier id_supplier 2 Tambah Data Supplier Proses 1.0 Arsitektur Perangkat Lunak (Structure Chart) Kelola Data Induk Proses 2.0 Tambah Data Barang Tambah Data Supplier id_barang supplier rec_barang id_supplier rec_supplier Modul-modul atomik (procedure, function) Baca Id_Barang Rekam Barang Baca Id_Supplier Rekam Supplier Page 19 / 224 5

20 STRUCTURE CHART Diagram untuk menggambarkan arsitektur perangkat lunak secara keseluruhan tanpa memperlihatkan proses pemilihan dan pengulangannya secara rinci. Menggambarkan arsitektur perangkat lunak seperti diagram organisasi sebuah perusahaan. Page 20 / 224 6

21 SIMBOL STRUCTURE CHART Simbol Arti Modul Pemanggilan modul Data atau elemen kontrol yang dikirimkan atau diterima dari satu modul Pengulangan di dalam modul Penyeleksian kondisi di dalam modul Page 21 / 224 7

22 CONTOH STRUCTURE CHART : PASCAL ( 1 ) notasi untuk parameter input yang dikirimkan kepada modul yang dipanggil x, y A B p, q modul pemanggil notasi untuk parameter output yang diberikan pada modul pemanggil modul yang dipanggil Procedure A; Var p, q : Real; Procedure B(x, y : Real); Begin p :=... { manipulasi nilai p } q :=... { manipulasi nilai q } End; Begin B(x, y); { call procedure B } End; Page 22 / 224 Modul A memanggil modul B dengan data x dan y sebagai parameternya. Modul B mengirimkan data p dan q sebagai return value ke modul A. Potongan kode program dalam bahasa Pascal 8

23 CONTOH STRUCTURE CHART : PASCAL ( 2 ) Modul A akan memanggil modul B jika kondisi dalam modul A dipenuhi. A Modul A akan memanggil modul C secara berulang. Potongan kode program dalam bahasa Pascal B Procedure C; Begin... End; Procedure B; Begin... End; Procedure A; Begin If True Then B; {call procedure B} While True Do C; {call procedure C} End; Page 23 / 224 C 9

24 CONTOH STRUCTURE CHART : PHP FormInput.html <html>... <form method=post action=rekam.php>... </html> Rekam.php <? // Rekam.php function getid() { } function saveid(id) { } id = getid(); saveid(id)?> id getid FormInput Rekam id saveid Page 24 /

25 CONTOH STRUCTURE CHART : DELPHI main.pas unit main;... var Form1: TForm1; implementation uses Rekam; procedure TForm1.Click(Sender: TObject); begin frmrekam.show; end; end. rekam.pas unit Rekam;... var frmrekam: TForm1; implementation... end. Page 25 / 224 Main Rekam 11

26 TRANSFORMASI DFD - STRUCTURE CHART ( 1 ) Ubah diagram konteks menjadi modul utama (top module atau executive module) dari structure chart. Ubah DFD level-1 menjadi modul-modul yang dipanggil oleh modul utama. Jika pemanggilan modul untuk proses-proses pada DFD level-1 membutuhkan data atau event tertentu, tambahkan sebuah modul untuk membaca data atau event tersebut. Ubah DFD level-2, 3, 4, dst. menjadi modul-modul lainnya sesuai dengan fungsinya dengan pendekatan Transform Analysis dan atau Transaction Analysis. Page 26 /

27 TRANSFORMASI DFD - STRUCTURE CHART ( 2 ) Transform Analysis Transaction Analysis Page 27 /

28 PENJADWALAN PROYEK DAN ANALISIS JARINGAN KERJA Proyek merupakan kombinasi dari kegiatan-kegiatan (activities) yang saling berkaitan dan harus dilaksanakan dengan mengikuti suatu urutan tertentu sebelum seluruh tugas dapat diselesaikan sacara tuntas. Pada umumnya suatu proyek adalah usaha satu waktu (one-time effort). Maksudnya urutan kegiatan-kegiatan yang sama mungkin tidak terulang lagi di waktu yang akan datang. Perencanaan adalah penentuan mengenai apa yang harus dicapai, kapan dan bagaimana hal tersebut itu dilaksanakan. Perencanaan (planning) merupakan salah satu fungsi manajemen dan bertujuan untuk memecahkan persoalan. Page 28 / 224

29 Macam Perencanaan Perencanaan pembangunan nasional Regional Sektoral Perncanaan personalia/tenaga kerja Perencanaan peralatan Perencanaan keuangan Perencanaan produksi Perencanaan pemasaran/penjualan Page 29 / 224

30 Pokok-pokok perencanaan adalah sebagai berikut : (1).Menentukan target, tanpa adanya target sukar untuk membuat evaluasi. (2).Kegiatan-kegiatan yang harus dilakukan. (3).Urutan kegiatan. (4).Jangka waktu yang diperlukan oleh masingmasing. (5).Tersedianya alat ukuran/standar. (6).Memperhatikan contingency factor. Page 30 / 224

31 TEKNIK PERENCANAAN CPM (Critical Path Method) PERT (Project Evaluation and Review Technique) Berguna untuk menyusun perencanaan, penjadwalan dan pengawasan/pengontrolan proyek PERT dan CPM pada dasarnya merupakan metode yang berorientasikan waktu, dalam arti bahwa keduanya akan berakhir dengan penentuan penjadwalan waktu (a time schedule). Page 31 / 224

32 Perbedaan yang paling menonjol ialah perkiraan waktu yang diperlukan untuk melaksanakan kegiatan : deterministic dalam CPM, probabilistis dalam PERT teknik penjadwalan proyek (project Shedulling technique) Page 32 / 224

33 Teknik penjadwalan proyek (project Shedulling technique) Terdiri dari tiga tahapan yaitu : 1.Perencanaan, 2.Penjadwalan 3.Pengontrolan/pengawasan Page 33 / 224

34 Tahapan perencanaan Dimulai dengan memecah/ menguraikan proyek menjadi kegiatan-kegiatan (activities). Perkiraan waktu, untuk kegiatan-kegiatan ini kemudian ditentukan dan diagram jaringan kerja (network) yang dinyatakan dengan gambar anak panah (arrow) Keseluruhan diagram anak panah memberikan suatu representasi grafis mengenai keterkaitan antara berbagai kegiatan suatu proyek Page 34 / 224

35 Pembentukan diagram anak panah sebagai tahapan perencanaan mempunyai tujuan : untuk mempelajari jenis pekerjaan yang berbeda secara rinci, mungkin dapat menimbulkan saran untuk perbaikan sebelum proyek dilaksanakan. Yang lebih penting lagi ialah kegunaannya untuk mengembangkan suatu jadwal untuk proyek (project schedulling). Page 35 / 224

36 TAHAPAN PENJADWALAN Jadwal harus mampu menunjukkan kegiatan-kegiatan yang kritis dilihat dari segi waktu yang memerlukan perhatian khusus kalau proyek harus selesai tepat pada waktunya. Jadwal harus menunjukkan banyaknya waktu yang mengambang (slack/fload time) yang dapat dipergunakan ketika kegiatan tertunda atau kalau sumberdaya yang terbatas dipergunakan secara efektif (mencapai sasaran/tujuan yang dikehendaki). Tujuan akhir dari tahap penjadwalan ialah membentuk a time chart yang dapat menunjukkan waktu mulai dan selesainya setiap kegiatan serta hubungannya satu sama lain dalam proyek. Page 36 / 224

37 Tahapan Pengawasan Meliputi penggunaan diagram anak panah dan grafik waktu (time chart) untuk membuat laporan kemajuan secara periodik. Jaringan kerja (network) perlu diperbarui dan dianalisis dan kalau perlu suatu jadwal baru ditentukan untuk sisa bagian proyek yang belum selesai. Page 37 / 224

38 Tiga tahapan proyek dimulai dengan pembentukan diagram anak panah, cara penyajian data untuk grafik waktu dan cara mengalokasikan sumber yang terbatas berbagai kegiatan/ aktifitas. Page 38 / 224

39 PEMBENTUKAN DIAGRAM ANAK PANAH Diagram anak panah (arrow diagram) menggambarkan keterkaitan antara kegiatan atau aktivitas proyek. Suatu anak panah (arrow) biasanya dipergunakan untuk mewakili suatu kegiatan dengan ujungnya menunjukkan arah kemajuan dalam proyek. Hubungan suatu kegiatan dengan kegiatan yang terjadi sebelumnya ditunjukkan oleh adanya kejadian (event). Yang dimaksud dengan kejadian ialah saat yang menggambarkan permulaan atau pengakhiran suatu kegiatan (activity), Page 39 / 224

40 Setiap kegiatan digambarkan sebagai anak panah, pangkal anak panah sebagai awal dan ujungnya sebagai akhir suatu kejadian. Anak panah menggambarkan apa yang dikerjakan mendahului, sebelum kegiatan itu dikerjakan. Setiap anak panah di ujung dan pangkalnya diberi tanda kejadian yang diberi nomor, seperti : Page 40 / 224

41 atau Kegiatan mulai dari kejadian 15 atau i dan berakhir dengan kejadian 16 atau j. untuk selanjutnya kejadian A ditulis kegiatan A (15,16) atau kegiatan A(i,j), artinya dimulai pada titik i dan berakhir pada titik j. selanjutnya i disebut pangkal dan j ujung. Page 41 / 224

42 Contoh lain : Kegiatan B baru bisa dikerjakan kalau A sudah selesai. Jadi A harus dikerjakan terlebih dahulu sebelum B. Tanda lingkaran 1, 2, dan 3 merupakan event. Kegiatan B baru bisa dikerjakan kalau A dan B sudah selesai. Jadi A dan B harus diselesaikan dahulu, kemudian baru C dimulai. B dan C baru bisa dimulai kalau A sudah selesai. Page 42 / 224

43 Kejadian (event) tidak memerlukan waktu, digambarkan sebagai lingkaran pada pangkal anak panah (saat dimulainya kegiatan) dan pada ujung anak panah (saat akhir/selesainya kegiatan). Pemberian nomor pada kejadian harus memenuhi persyaratan yaitu nomor awal (pangkal) harus lebih kecil dari pada nomor akhir (ujung). Page 43 / 224

44 Untuk selanjutnya perhatikan aturan-aturan berikut : 1. Setiap kegiatan hanya boleh diwakili oleh satu anak panah saja didalam jaringan kerja, (kecuali kalau satu kegiatan dipecah menjadi kegiatan yang lebih kecil). 2. Tidak boleh ada dua kegiatan diwakili oleh pangkal dan ujung anak panah yang sama. Dalam hal ini harus dipergunakan anak panah boneka (dummy arrow). Perhatikan ilustrasi berikut. Pangkal (1) dan ujung (2), A dan B sama. Page 44 / 224

45 A (1,2) B juga (1,2), ini tidak boleh dan harus diatasi dengan menggunakan anak panah boneka seperti berikut ini. D = Dummy, dengan garis putus-putus. Page 45 / 224

46 Suatu anak panah boneka (dummy) untuk menggambarkan kegiatan yang tidak memakan waktu (kegiatan boneka sering juga disebut semu atau buatan, bukan sesungguhnya). Alasan penggunaan kegiatan boneka (dummy activity) adalah : 1. Menghindarkan keragu-raguan dalam indikasi, seperti gambar di atas A (1,2), B (1,2), keduanya mempunyai indikasi yang sama, membingungkan. Lihat gambar a), b), c) dan d) untuk mengatasinya, di mana : A(1,2), B(1,3) D(2,3) A(2,3), B(1,3) D(1,2) A(1,3), B(2,3) D(1,2) A(1,3), B(1,2) D(2,3) Page 46 / 224

47 Page 47 / Memberikan gambaran urutan logik yang benar. Contoh : Air limbah yang akan dibuang dari saluran pembuangan 1 (Outlet 1) ke sungai dialirkan menuju IPAL I (3), saluran outlet 2 sebelum ke sungai juga akan melewati IPAL I (3), karena beban pengolahan pada IPAL I terbatas, maka kapasitas limbah yang tidak terolah disalurkan ke IPAL II (4), sedangkan yang sudah terolah langsung dapat dibuang ke sungai (5) Kegiatan A :Saluran Outlet 1 menuju IPAL I (3) Kegiatan B :Saluran Outlet 2 menuju IPAL I (3) Kegiatan C :Saluran IPAL I (3) ke IPAL II (4) Kegiatan D :Saluran IPAL I (3) ke sungai (5)

48 Pada gambar di atas terlihat bahwa kegiatan C belum dapat berlangsung sebelum kegiatan B, yang berarti bahwa kegiatan C dapat beroperasi apabila kegiatan B sudah berjalan, sedangakan D dapat berjalan setelah kegiatan A atau B apabila berjalan tidak bersamaan. Contoh pembuatan diagram anak panah 1 1. Gambarkan diagram anak panah yang mencakup kegiatan A, B, C,.., dan L sedemikian rupa sehinga hubungan berikut ini terpenuhi. 2. A, B, dan C kegiatan dalam suatu proyek yang bisa dimulai secara serentak (simultan). 3. A dan B mendahului D. 4. B mendahului E, F dan H. 5. F dan C mendahului G. 6. E dan A mendahului I dan J 7. C, D, F dan J mendahului K. 8. K mendahului L. 9. I, G dan L merupakan aktifitas terminal di proyek. Page 48 / 224

49 Jawab. Page 49 / 224

50 Contoh pembuatan diagram anak panah 2 1. Gambarkan diagram anak panah yang mencakup kegiatan A, B, C,.., dan M sedemikian rupa sehinga hubungan berikut ini terpenuhi. 2. A dan B dapat dimulai secara serentak. 3. C dan D dapat dimulai kalau A sudah selesai. 4. E dapat dimulai kalau C sudah selesai. 5. G dapat dimulai kalau E sudah selesai. 6. F dapat dimulai kalau D sudah selesai. 7. H dapat dimulai kalau C, D, E, F dan G sudah selesai. 8. I dan J dapat dimulai kalau B sudah selesai. 9. K dapat dimulai kalau J sudah selesai. 10. L dapat dimulai kalau I, J, dan K sudah selesai. 11. M dapat dimulai kalau H dan L sudah selesai. 12. M kegiatan terminal. Page 50 / 224

51 Page 51 / 224

52 Contoh pembuatan diagram anak panah 3 1. Gambarkan diagram anak panah yang mencakup kegiatan A, B, C,.., dan J sedemikian rupa sehinga hubungan berikut ini terpenuhi. 2. Proyek dimulai dari kegiatan A, 3. Kegiatan B dan C baru bisa dimulai kalau A sudah selesai. 4. Kegiatan D dan E baru bisa dimulai kalau C sudah selesai. 5. Kegiatan F dan G baru bisa dimulai kalau B sudah selesai. 6. Kegiatan H baru bisa dimulai kalau E sudah selesai. 7. Kegiatan I baru bisa dimulai kalau D sudah selesai. 8. Kegiatan J baru bisa dimulai kalau G dan H sudah selesai. 9. Kegiatan I dan J merupakan kegiatan terminal. Page 52 / 224

53 Page 53 / 224

54 ARTI DAN KEGUNAAN JARINGAN KERJA ATAU NETWORK Kebaikan langsung yang dapat dipetik dari pemakaian analisis Network adalah sebagai berikut : 1. Dapat mengenali (identifity) jalur kritis (critical path)dalam hal ini adalah jalur elemen-elemen kegiatan yang kritis dalam skala waktu penyelesaian proyek sebagai keseluruhan. 2. Mempunyai kemampuan mengadakan perubahanperubahan semberdaya dan memperhitungkan efek terhadap waktu selesainya proyek. 3. Mempunyai kemampuan memperkirakan efek-efek dari hasil yang dicapai suatu kegiatan terhadap keseluruhan rencana apabila diimplementasikan / dilaksanakan. Page 54 / 224

55 Keuntungan tidak langsung dari pemakaian network adalah sebagai berikut : 1. sebelum menyusun suatu network seorang analis harus mengkajirencana secara keseluruhan, merinci dan mengurangi menjadi komponen-komponen kegiatan yang terpisahpisah. 2. Seorang analis harus memikirkan interelasi dari kegiatan-kegiatan. 3. Seorang analis harus memperhitungkan batas waktu untuk mesing-masing unsur kegiatan, sebab setiap kegiatan memerlukan sejumlah waktu tertentu untuk penyelesaiannya. Page 55 / 224

56 MANAJEMEN PROYEK PERANGKAT LUNAK 17-Oct-10 1 SOFTWARE PROJECT MANAGEMENT Page 56 / 224

57 MANAJEMEN? Kumpulan orang-orang dalam organisasi ( profesional/non profesioanal ) Bersifat Kekuasaan, mengatur dan memerintah Pengambilan keputusan dan deadline Bersifat Strategis, Taktis dan teknis 17-Oct-10 2 Page 57 / 224

58 APAKAH PROYEK ITU? Definisi kamus bahwa Proyek adalah perencanaan / perancangan yang spesifik atau pekerjaan terencana atau pekerjaan yang besar (Longman Concise English Dictionary, 1982) 17-Oct-10 3 Page 58 / 224

59 APAKAH PROYEK ITU? Karakteristik karateristik Proyek Tugas non rutin Perlu perencanaan Tujuan spesifik yang akan dicapai atau produk spesisfik yang akan dibuat Proyek harus ditentukan jangka waktu Pekerjaan dikerjakan untuk seseorang bukan untuk diri kita Pekerjaan melibatkan beberapa spesialis Sumber daya proyek yang tersedia dibatasi Proyek itu pekerjaan besar / komplek 17-Oct-10 4 Page 59 / 224

60 MASALAH PROYEK PERANGKAT LUNAK Masalah-masalah yang diidentifikasi oleh mahasiswa sistem komputer dan informasi yang telah menyelesaikan penempatan industri : Spesifikasi pekerjaan yang kurang Manajemen mengabaikan IT Pengetahuan area aplikasi yang kurang Standard yang kurang Update dokumentasi yang kurang Aktifitas sebelumnya yang tidak lengkap pada waktunya termasuk pengiriman perangkat yang terlambat Komunikasi antara teknisi dan user yang kurang Komunikasi yang kurang menyebabkan duplikasi pekerjaan Komitmen yang kurang khusunya ketika proyek terikat pada satu orang kemudian keluar Kemampuan Keahlian teknikal yang kurang Perubahan kebutuhan hukum Perubahan lingkungan perangkat lunak Tekanan deadline Pengendalian kualitas yang kurang Management jarak jauh Pelatihan yang kurang 17-Oct-10 5 Page 60 / 224

61 PROYEK PERANGKAT LUNAK VS TIPE PROYEK LAIN Banyak teknik manajemen proyek umum yang dapat diaplikasikan dengan MPLL, tapi menurut Fred Brooks memberi catatan bahwa produk proyek perangkat lunak mempunyai karakteristik tertentu. Satu cara untuk melihat MPLL adalah sebagai proses membuat visible dari invisible 17-Oct-10 6 Page 61 / 224

62 PROYEK PERANGKAT LUNAK VS TIPE PROYEK LAIN Karakteristik MPPL 1. Tidak nampak 2. Komplek 3. Flexible 17-Oct-10 7 Page 62 / 224

63 FOKUS MPPL (MANAJEMEN PROYEK PERANGKAT LUNAK ) 17-Oct-10 8 Page 63 / 224

64 MANAJEMEN PERSONEL, PRODUK DAN PROSES Manajemen proyek perangkat lunak mengatur 4 hal penting : Personel Masalah (problem) berkaitan dengan Produk proses dan Proyek tambahan (tapi sangat penting) Empat hal ini berurutan mulai dari yang paling penting. Personel mendapat tempat paling penting karena tanpa personel yang baik dan tepat maka 3 hal lain tidak bisa berjalan dengan baik. Page 64 / Oct-10 9

65 PARADIGMA REKAYASA PERANGKAT LUNAK Page 65 / 224

66 ARTI PARADIGMA Berasal dari bahasa Yunani yang berarti suatu model, teladan, arketif dan ideal. Paradigma adalah suatu model dalam teori ilmu pengetahuan atau kerangka berpikir. Page 66 / 224

67 ARTI REKAYASA PERANGKAT LUNAK Adalah Manipulasi,membuat atau menciptakan sesuatu yang sifatnya khayalan logic yang di wujudkan dalam urutan-urutan perintah (Coding) beserta data-datanya sehingga menjadi suatu aplikasi yang dapat digunakan. Page 67 / 224

68 MODEL WATERFALL SEBAGAI MODEL RAKAYASA PERANGKAT LUNAK Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya. Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing. Tahapan model waterfall meliputi : Page 68 / 224

69 Gambar model waterfall Requirements definition System and software design Implementation and unit testing Integr ation and system testing Operation and maintenance Page 69 / 224

70 1. Requirment adalah tahap dilakukan analisa kebutuhan, kemudian diverfikasi klien dan tim SQA (Software Quantity Assurance). Specification adalah dokumentasi spesifikasi. 2. Design adalah tahap membagi kebutuhankebutuhan menjadi sistem perangkat lunak, dalam tahap ini menghasilkan sebuah arsitektur keseluruhan perangkat lunak. 3. Implementation adalah tahap dimana kode-kode program yang di buat di testing atau di uji. Page 70 / 224

71 4. Intergration adalah tahap dimana suatu perangkat lunak yang di buat diuji dan yakin menjadi suatu sistem yang lengkap dan memenuhi persyaratan perangkat lunak. 5. Operaton mode & Retirement, ini adalah tahap terpanjang. Sistem dipasang dan digunakan. Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya. Page 71 / 224

72 MODEL SPIRAL DALAM REKAYASA PERANGKAT LUNAK Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara explisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum. Model yang di usulkan Boehm berbentuk spiral. Page 72 / 224

73 Page 73 / 224

74 SETIAP LOOP DALAM MODEL INI MEWAKILI SEBUAH TAHAP DARI PROSES PERANGKAT LUNAK. TIDAK ADA TAHAP YANG TETAP DALAM MODEL INI. MANAJEMEN HARUS MEMUTUSKAN BAGAIMANA MEMBENTUK PROYEK KE DALAM TAHAP-TAHAP. PERUSAHAAN BIASANYA BEKERJA DENGAN BEBERAPA MODEL UMUM DENGAN TAHAP TAMBAHAN UNTUK PROYEK KHUSUS ATAU KETIKA MASALAH-MASALAH DITEMUKAN SELAMA PEMBUATAN PROYEK. Page 74 / 224

75 SETIAP LOP DIBAGI DALAM 4 SEKTOR SEBAGAI BERIKUT Determine objectives (Menentukan Permasalahan) Risk Analysis (Analisis Resiko) Engineering / develop (Melakukan proses rekayasa perangkat lunak) Plan next phase (Penentuan rencana-rencana untuk tahap selanjutnya) Page 75 / 224

76 PADA IMPLEMENTASINYA, MODEL SPIRAL INI JUGA BANYAK DIGUNAKAN, TETAPI BIASANYA DIKOMBINASIKAN DENGAN YANG LAIN. PERMODELAN WATERFALL, YANG SANGAT BAGUS DALAM MENENTUKAN MILLESTONES DAN PERMODELAN SPIRAL, YANG SANGAT BAGUS DENGAN MENGGUNAKAN PROTOTYPING, MERUPAKAN KOMBINASI YANG SERING DIPAKAI DI DALAM KONTRAK-KONTRAK UNTUK PERANGKAT LUNAK. Page 76 / 224

77 BILA TAHAPAN RISK ANALYSIS TIDAK DAPAT DILEWATI, MAKA PROSES DIHENTIKAN, TIDAK MENGIJINKAN PROSES KEMBALI KE TAHAPAN SEBELUMNYA. RISK ANALYSIS YANG DILAKUKAN ADALAH : Project risk, mempengaruhi rencana proyek, contoh kekurangan sumber daya Technical risk, mempengaruhi tahap aktual, contoh : personil tidak terlatih di tahap tersebut Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software, contoh : software tidak diperlukan Page 77 / 224

78 PRIORITAS RESIKO DAPAT DIKATEGORIKAN SEBAGAI BERIKUT : Catastropik (luar biasa), contoh : penurunan kualitas yang luar biasa, biaya yang tidak terkontrol Critical (kritis), contoh : tidak tepat waktu, biaya di luar perkiraan Marginal (ringan), contoh : penjadwalan yang terlambat Negligible (tidak berarti), contoh : penggunaan waktu proyek tidak optimal Page 78 / 224

79 PERBEDAAN MENDASAR ANTARA MODEL SPRILAL DENGAN MODEL LAINNYA ADALAH BAHWA MODEL SPIRAL DENGAN EKSPLISIT MENYADARI RESIKO-RESIKO YANG ADA. RESIKO ADALAH KONSEP YANG SULIT DIDEFINISIKAN SECARA TEPAT. SECARA INFORMAL RESIKO ADALAH SESUATU YANG SEDERHANA YANG DAPAT KESALAHAN. MENYEBABKAN CONTOHNYA, JIKA BERTUJUAN MENGGUNAKAN PEMROGRAMAN BAHASA BARU (NEW PROGRAMMING LANGUGE), RESIKO YANG MUNGKIN ADALAH ALAT PENGUMPUL YANG DIGUNAKAN TIDAK RELIABLE DAN TIDAK MENGHASILKAN CODE OBYEK YANG EFISIEN. Page 79 / 224

80 UNTUK MENGGUNAKAN MODEL SPIRAL, BOEHM MENYARANKAN SEBUAH BENTUK UMUM YANG DIPENUHI DALAM SETIAP DAERAH SPIRAL. BENTUK INI MUNGKIN DILENGKAPI PADA SEBUAH LEVEL ABSTRAK ATAU PERKIRAAN YANG IMBANG DARI PENGEMBANGAN PRODUK. Page 80 / 224

81 MODEL INCREMENTAL DALAM REKAYASA PERANGKAT LUNAK Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangun berhenti jika produk telah mencapai seluruh fungsi yang diharapkan. Pada awal tahapan dilakukan penentuan kebutuhan dan spesifikasi. Kemudian dilakukan perancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-bagian pada tahapan selanjutnya. Page 81 / 224

82 Tahapan Incremental Model adalah : Requirement Specification Architecture Design TAHAPAN-TAHAPAN TERSEBUT DILAKUKAN SECARA BERURUTAN. SETIAP BAGIAN YANG SUDAH SELESAI DILAKUKAN TESTING, DIKIRIM KE PEMAKAI UNTUK LANGSUNG DAPAT DIGUNAKAN. PADA INCREMENTAL MODEL, TIGA TAHAPAN AWAL HARUS DISELESAIKAN TERLEBIH DAHULU SEBELUM TAHAP MEMBANGUN TIAP MODAL. Page 82 / 224

83 Page 83 / 224

84 UNTUK MENGANTISIPASI KONDISI YANG TERJADI PADA MODEL INCREMENTAL, DIPERKENALKAN MODEL MORE RISKY INCREMENTAL MODEL. MODEL INI MENERAPKAN SISTEM KERJA YANG PARALEL. SETELAH DAFTAR KEBUTUHAN DIDAPATKAN DARI PEMAKAI, TIM SPESIFIKASI MEMBUAT SPESIFIKASI UNTUK MODUL PERTAMA. SETELAH SPESIFIKASI PERTAMA SELESAI, TIM DESAIN MENINDAK LANJUTI. TIM SPESIFIKASI SEBELUMNYA JUGA LANGSUNG MEMBUAT SPESIFIKASI UNTUK MODEL KEDUA, DAN SETERUSNYA. Page 84 / 224

85 MODEL METODOLOGI RAD (RAPID APPLICATION DEVELOPMENT) Page 85 / 224

86 Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya siklus pengembangan. Model ini memecah suatu proyek menjadi bagian-bagian kecil yang mana tiap bagiannya dibangun dengan model yang mirip dengan Waterfall. Tujuan utama model ini adalah menyelesaikan suatu proyek per bagian, sehingga proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara global) RAD adalah model proses pembangunan PL yang incremental. RAD menekankan pada siklus pembangunan yang pendek/singkat. RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction. Waktu yang singkat adalah batasan yang penting untuk model ini. Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari. Page 86 / 224

87 Fase-fase di atas menggambarkan proses dalam model RAD. Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan. Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi? kebutuhan dari sistem Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut analisis kebutuhan dan data Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis. Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan. Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan interface harus tetap diuji. Page 87 / 224

88 Model Build and Fixed Model rekayasa perangkat lunak (RPL) ini adalah model RPL paling sederhana, sangat cocok untuk proyek-proyek kecil yang terbatas komplesitasnya karena dibangun dengan persyaratan minimal, dan umumnya tidak ada spesifikasi usaha maupun desain, dan bahkan pengujiannya sering kali diabaikan Page 88 / 224

89 1. CLASSIC LIFE CYCLE PARADIGMA SISTEM ENGINEERING ANALYS DESIGN CODE TESTING A. Analisis B. Perancangan C. Pengkodean D. Pengujian E. Maintenance MAINTENANCE Page 89 / 224

90 2. BERORIENTASI OBJEK Paradigma pembangunan perangkat lunak berbasis objek adalah bagaimana merepresentasikan dunia nyata ke dalam sebuah sistem sehingga pemecahan suatu masalah tidak dilihat dari cara menyelesaikan masalah tersebut tetapi dititikberatkan pada objek-objek apa sajakah yang dapat memecahkan masalah tersebut. Page 90 / 224

91 3. PROTOTYPE PARADIGMA Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari software, mengidentifikasi segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh merupakan keharusan kemudian dilakukan perancangan kilat. Perancangan kilat berfokus pada penyajian dari aspek aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Page 91 / 224

92 3. PROTOTYPE PARADIGMA REQUIMENTS GATHERING "QUICK DESIGN" BUILD PROTOTYPE EVALUATED AND REFINEMENTS ENGINEER PRODUCT Page 92 / 224

93 4. THE 4TH GENERATION TECHNIQUE PARADIGMA Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian menghasilkan source code dan object code secara otomatis sesuai dengan spesifikasi yang ditentukan developer. Page 93 / 224

94 4. THE 4TH GENERATION TECHNIQUE REQUIMENTS PARADIGMA GATHERING "DESIGN STRATEGICS" IMPLEMENTATION USING 4GT PRODUCT Page 94 / 224

95 TUGAS!! Buat Perbandingan tiap Model, dan penerpan kasus 1. Waterfall 2. Spiral 3. Incerementa 4. Rad 5. Build and Fixed Page 95 / 224

96 Perencanaan Proyek Perencanaan PL & Manajemen Resiko 1 RPL 5-6 Page 96 / 224

97 Perencanaan Proyek Perangkat Lunak Tujuan : membuat kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai sumberdaya, biaya & jadwal.estimasi dibuat dengan kerangka waktu yang terbatas pada awal sebuah proyek PL & diperbaharui secara teratur selama proyek berjalan. Why? So the end result gets done on time, with quality! 2 RPL 5-6 Page 97 / 224

98 Langkah Perencanaan PL: Scoping memahami permasalahan dan apa yang harus dikerjakan Estimation estimasi waktu? Estimasi SDM?estimasi PL/PK? Risk apa saja yang mungkin terjadi? Bagaimana mengatasinya? Apa yang harus dilakukan untuk mengatasi resiko yang terjadi? Schedule bagimana mengalokasikan semua sumber daya sesuai dengan waktu yang telah ditentukan? Control strategy bagaimana kualitas kontrol?bagaimana mengkontrol segala sesuatu jika terjadi perubahan? 3 RPL 5-6 Page 98 / 224

99 Bagaimana memahami lingkup PL/scope? Memahami kebutuhan customer Memahami konteks bisnis yang ada Memahami permasalahan proyek Memahami motivasi customer terhadap PL yang akan dikerjakan Memahami setiap bagian jika terjadi perubahan RPL 5-6 Page 99 / 224 4

100 Sumber Daya Proyek Manusia Komponen PL PK & PL 5 RPL 5-6 Page 100 / 224

101 Sumber Daya Manusia Dimulai dengan mengevaluasi lingkup serta memilih kecakapan yang dibutuhkan untuk menyelesaikan proyek, baik posisi organisasi(manajer, perekayasa PL senior dll) maupun specialist(telekomunikasi, database, jaringan dll) ditentukan. 6 RPL 5-6 Page 101 / 224

102 Komponen PL Komponen Off-the-self : PL yang ada dapat diperoleh dari bagian proyek sebelumnya yang siap untuk digunakan pada proyek saat ini & telah divalidasi seluruhnya. Komponen Full-Experience : spesifikasi, kode, desain atau pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu & serupa dengan proyek saat ini. Dimana setiap anggota tim memiliki pengalaman penuh pada bidang aplikasi sehingga modifikasi komponen resikonya relatif rendah 7 RPL 5-6 Page 102 / 224

103 Komponen Partial-Experience : aplikasi, kode, desain atau data pengujian yang ada pada proyek yang lalu yang dihubungkan dengan proyek PL saat ini tetapi membutuhkan modifikasi substansial & berisiko sedang Komponen Baru : komponen PL yang harus dibangun oleh Tim proyek untuk kebutuhan saat ini & berisiko tinggi 8 RPL 5-6 Page 103 / 224

104 PL & PK PK menyediakan sebuah platform yang mendukung PL yang dibutuhkan untuk menghasilkan produk kerja yang merupakan keluaran dari RPL yang baik 9 RPL 5-6 Page 104 / 224

105 Estimasi Proyek PL (Biaya & Usaha ) Estimasi sampai akhir proyek Estimasi pada proyek-proyek yang mirip & sudah dilakukan sebelumnya Estimasi dengan menggunakan teknik dekomposisi Estimasi dengan menggunakan model empiris 10 RPL 5-6 Page 105 / 224

106 TeknikDekomposisi Dekomposisi Masalah Dekomposisi Proses Statement of Scope performa parse" functional decomposition Page 106 / 224 RPL

107 Dekomposisi Masalah Estimasi berdasarkan baris kode (LOC) & titik fungsi (FP). Data LOC & FP digunakan dalam 2 cara : Sebagai variabel estimasi yang dipakai untuk mengukur masing-masing elemen PL Sebagai Metrik Baseline yang dikumpulkan dari proyek yang lalu & dipakai dalam hubungnya dengan variabel estimasi untuk mengembangkan proyeksi usaha & biaya 12 RPL 5-6 Page 107 / 224

108 Estimasi berbasis LOC Dimana fungsi PL diidentifikasi sbb: Interface pemakai & fasilitas kontrol (UICF) Analisis geometri 2 dimensi (2DGA) Analisis geometri 3 dimensi (3DGA) Manajemen database (DBM) Fasilitas tampilan grafiskomputer(cgdf) Kontrol periperal (PC) Modul analisis desain (DAM) 13 RPL 5-6 Page 108 / 224

109 Dekomposisi Proses Dengan perkiraan proses yang akan digunakan yaitu proses yang didekomposisi ke dalam serangkain aktivitas.tugas yang relatif sangat kecil & usaha yang dibutuhkan untuk menyelesaikan masing-masing tugas yang diperkirakan. 14 RPL 5-6 Page 109 / 224

110 Model Perkiraan Empiris Menggunakan rumusan yang ditarik secara empiris untuk memprediksi usaha sebagai fungsi LOC & FP dimana harga LOC & FP diperkirakan dengan menggunakan tabel yang telah ditentukan. 15 RPL 5-6 Page 110 / 224

111 Model COCOMO(COnstructive COst MOdel), menurut Barry Boehm, hirarki modelnya dibagi sbb: Model 1 Model COCOMO Dasar, dimana menghitung usaha pengembangan PL (&Biaya) sebagai fungsi dari ukuran program yang diekpresikan dalam baris kode yang diestimasi. Proyek PL a b b b c b d b Organik 2,4 1,05 2,5 0,38 Semi-detached 3,0 1,12 2,5 0,35 Embedded 3,6 1,20 2,5 0,32 16 RPL 5-6 Page 111 / 224

112 Model COCOMO dibagi menjadi 3 kelas Proyek PL : Mode Organik : proyek PL yang sederhana & relatif kecil Mode Semi-detached : proyek PL menengah (dalam ukuran & kompleksitas) Mode Embedded : proyek PL yang harus dikembangkan ke dalam serangkaian PK 17 RPL 5-6 Page 112 / 224

113 Model 2 Model COCOMO Intermediate Menghitung usaha pengembangan PL sebagai fungsi ukuran program & serangkain pengendali biaya yang menyangkut penilaian yang subyektif terhadap produk, PK & atribut proyek Proyek PL a i bi Organik 2,4 1,05 Semi-detached 3,0 1,12 Embedded 3,6 1,20 18 RPL 5-6 Page 113 / 224

114 Model 3 Model COCOMO Advance Menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengedali biaya pada setiap langkah (analisis, perancangan, dll) dari proses RPL. 19 RPL 5-6 Page 114 / 224

115 Outsourcing Karena banyaknya area aplikasi PL, biaya dll, manajer PL dihadapkan pada keputusan make buy/outsourcing yaitu: Off-the-self = Perangkat PL dapat dibeli atau lisensi Full/ pastial experience = komponen PL dapat diperoleh & dimodifikasi serta diintegrasikan sesuai dengan kebutuhan Custom built = PL dapat dibuat oleh pihak lain untuk memenuhi spesifikasi pembeli 20 RPL 5-6 Page 115 / 224

116 Untuk produk PL yang mahal, dapat dilakukan sbb : Kembangkan spesifikasi untuk fungsi & kinerja PL yang dilakukan. Tentukan karakteristik yang dapat diukur kapan saja dibutuhkan. Perkirakan biaya internal untuk mengembangkan & tanggal penyampaian Pilih 3 atau 4 calon aplikasi yang paling cocok dengan aplikasi anda Pilih komponen yang reusable yang dapat membantu konstruksi aplikasi yang diperlukan 21 RPL 5-6 Page 116 / 224

117 Kembangkan sebuah matrik perbandingan yang menyajikan perbandingan dari fungsi-fungsi pokok & lakukan pengujian untuk membandingkan calon PL Evaluasi masing-masing paket PL/komponen berdasarkan kualitas produk sebelumnya, dukungan penjual, arah proyek, reputasi dll Hubungi pemakai PL lain & mintalah pendapat mereka 22 RPL 5-6 Page 117 / 224

118 Analisa terakhir untuk memutuskan outsourcing sbb: Apakah tanggal penyampaian produk PL akan lebih cepat daripada PL yang dikembangkan internal? Apakah biaya akuisisi ditambah biaya pemesanan akan lebih kecil daripada biaya pengembangan PL internal? Apakah biaya dukungan luar (kontrak pemeliharaan) lebih rendah daripada biaya dukungan internal? 23 RPL 5-6 Page 118 / 224

119 Manajemen Resiko What can go wrong? What is the likelihood? What will the damage be? What can we do about it? 24 RPL 5-6 Page 119 / 224

120 Risk Management Paradigm track plan control RISK analyze identify 25 RPL 5-6 Page 120 / 224

121 Macam Resiko : Risiko Proyek mengancam rencana proyek, berhub. Dengan biaya, jadwal, SDM, pelanggan & masalah persyaratan PL Risiko Teknik mengancam kualitas & ketepatan waktu PL yg dihasilkan, berhub. Dengan spesifikasi, keusangan teknik, dll Risiko yang sudah diketahui, yaitu risiko yang dapat diketahui setelah dilakukan evaluasi terhadap rencana proyek, bisnis, dl 26 RPL 5-6 Page 121 / 224

122 Risiko Bisnis mengancam viabilitas PL yang akan dibangun, berhub. Dengan : Pembangunan produk & sistem yang baik sekali yg tidak diinginkan oleh pelanggan. Pembangunan produk yang tidak sesuai dengan strategi bisnis perusahaan Pembangunan produk dimana bag. Pemasaran tidak tahu bagaimana harus menjualnya. Kehilangan dukungan dari manajemen senior sehub. Dgn perubahan manusia Kehilangan hal-hal yg berhub. Dgn biaya 27 RPL 5-6 Page 122 / 224

123 Risiko yang dapat diramalkan dimana risiko ini diekstrapolasi dari pengalaman proyek sebelumnya Page 123 / 224 RPL

124 Metode yang digunakan untuk mengidentifikasi Risiko adalah dengan checklist item risiko yang dibagi menjadi: Ukuran produk Ukuran database? Jumlah program, file, transaksi? Jumlah PL yang dipakai? Pengaruh bisnis Pengaruh produk terhadap perusahaan? Penyelesaian produk? Jumlah produk/sistem yang berhub. Dengan PL yang dibangun? 29 RPL 5-6 Page 124 / 224

125 karakteristik pelanggan pelanggan yang mau berpartisipasi dalam penyusunan PL? pelanggan yang memahami proses PL? pelanggan yang memiliki pemahaman akan apa yang diperlukan? definisi Proses apakah dibutuhkan PL untuk membangun prototype PL? apakah metode spesifikasi yang digunakan? 30 RPL 5-6 Page 125 / 224

126 Lingkungan pengembang Apakah pengujian dapat diperoleh & sesuai dengan produk yang akan dibangun? Apakah semua peranti saling terintegrasikan? Teknologi pengembang & yang akan dibangun : Apakah diperlukan interface khusus untuk persyaratan produk? Apakah teknologi yang dipakai adalag teknologi baru? 31 RPL 5-6 Page 126 / 224

127 Ukuran & pengalaman staf Apakah orang-orang yang terbaik didapatkan? Jumlah orang yang bekerja paruh waktu / tidak? 32 RPL 5-6 Page 127 / 224

128 Pengurangan, Monitoring & manajemen Risiko : Menghindari risiko o Bagaimana mengurangi turnover staf o Menentukan standart dokumentasi & mekanismenya o Melakukan kajian terhadap semua pekerjaan sehingga lebih dari 1 orang yang terbiasa dgn pekerjaan tersebut. o Menentukan backup staf, dll Monitoring risiko Memonitor factor-faktor yang dapat memberikan indikasi terhadap suatu risiko : hub. Interpersonal diantara tim, sikap umum tim terhadap tekanan proyek, dll 33 RPL 5-6 Page 128 / 224

129 Manajemen risiko Jika usaha pencegahan sudah diupayakan ( backup ada, informasi terdokumentasi & pengetahuan telah disebarkan ke seluruh Tim) & ternyata gagal, maka diperlukan : o Untuk anggota tim yang akan pergi untuk mentransfer pengetahuan pada anggota tim pengganti 34 RPL 5-6 Page 129 / 224

130 MATERI 1. Manajemen Resiko 2. Kualitas Perangkat Lunak 3. SQA Page 130 / 224 7/8/2010 1

131 Manajemen Resiko Perangkat Lunak Page 131 / 224 7/8/2010 2

132 Defenisi konseptual mengenai resiko : (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. Page 132 / 224 7/8/2010 3

133 Strategi Resiko Reaktif vs Proaktif Strategi Reaktif Memonitor proyek yg berjalan terhadap kemungkinan resiko. Strategi Proaktif Dimulai sebelum kerja teknis diawali, dan diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko. Page 133 / 224 7/8/2010 4

134 Kategori resiko oleh Robert Charette 1. Resiko yang sudah diketahui ( pasti ) 2. Resiko yang dapat diestimasi 3. Resiko yang tidak diharapkan Page 134 / 224 7/8/2010 5

135 Resiko Perangkat Lunak Karakteristik resiko : 1. Ketidakpastian 2. Kerugian Kategori resiko : 1. Resiko proyek ( Mou) 2. Resiko teknis 3. Resiko bisnis ( Market) Page 135 / 224 7/8/2010 6

136 Resiko proyek Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami perubahan & biaya menjadi bertambah. Resiko proyek mengidenifikasi : 1. Biaya 2. Sumber daya 3. Jadwal 4. Pelanggan 5. Personil (staffing & organisasi) 6. Masalah persyaratan Page 136 / 224 7/8/2010 7

137 Resiko Teknis Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan. Bila resiko teknis menjadi kenyataan maka Implementasinya menjadi sangat sulit atau tidak mungkin terlaksana. Resiko teknis mengidentifikasi : 1. Desain-Perancangan 2. Coding 3. Spesifikasi 4. Interfacing Page 137 / 224 7/8/2010 8

138 5. Ketidakpastian teknik 6. Verivikasi 7. Keusangan teknik 8. Masalah pemeliharaan 9. Teknologi Page 138 / 224 7/8/2010 9

139 Resiko bisnis Resiko bisnis mengancam PL yg akan dibangun secara keseluruhan. Resiko bisnis membahayakan proyek atau produk dan nama baik. 5 resiko bisnis utama : 1.Pembangunan produk atau sistem yg baik sebenarnya tdk pernah diinginkan oleh setiap orang (resiko pasar) 2.Pembangunan sebuah produk yg tidak sesuai dgn keseluruhan strategi bisnis bagi perusahaan (resiko strategi) 3.Pembangunan sebuah produk dimana sebuah bagian pemasaran tidak tahu bagaimana harus menjualnya. 4.Kehilangan dukungan manajemen senior sehubungan dg perubahan pd fokus atau perubahan pd manusia (resiko manajemen) 5.Kehilangan hal2 yg berhubungan dgn biaya atau komitmen personal (resiko biaya). Page 139 / 224 7/8/

140 Resiko yg 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 : 1. Tgl penyampaian yg tdk realitas 2. Kurangnya persyaratan yg terdokumentasi 3. Kurangnya ruag lingkup PL 4. Lingkungan pengembangan yg buruk Page 140 / 224 7/8/

141 Resiko yg dapat diramalkan / Estimasi Dazari pengalaman proyek sebelumnya. Misalnya : 1. Pergantian staf 2. Penggantian Resouce Page 141 / 224 7/8/

142 Identifikasi 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. Page 142 / 224 7/8/

143 Resiko yg mempengaruhi bisnis 1. Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar. 2. Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik langsung dengan kenyataan teknis. Page 143 / 224 7/8/

144 Resiko yg dihubungkan dgn karakteristik pelanggan Karakteristik pelanggan : 1. Pelanggan mempunyai keinginan yg berbeda. 2. Pelanggan memiliki kepribadian yg berbeda. 3. Pelanggan memiliki hubungan bisnis 4. Pelanggan juga kadang-kadang bertentangan. Page 144 / 224 7/8/

145 Komponen Resiko 1. Resiko kinerja tingkat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya. 2. Resiko biaya tingkat ketidakpastian dimana biaya proyek akan dijaga 3. Resiko dukungan tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan. 4. Resiko jadwal tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu. Page 145 / 224 7/8/

146 Proyeksi / estimasi resiko 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 Page 146 / 224 7/8/

147 Menilai pengaruh risiko Tiga faktor yg mempengaruhi konsekuensi jika suatu resiko benar-benar terjadi : 1. Sifatnya - resiko 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 besa pelanggan terganggu? ) 3. Timingnya - mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan. Page 147 / 224 7/8/

148 Faktor Yang Mempengaruhi Kualitas Produk Page 148 / 224 7/8/

149 Penggunaan Waktu Seorang Programmer Penulisan program Membaca program dan membuat manual Mengkomunikasi pekerjaan Kegiatan pribadi (libur, sakit, dsb) Lain-lain (kamar kecil, telefon pribadi, rehat kopi, dsb) Pelatihan Surat menyurat Tabel aktivitas programmer (Bell Lab. Study, sampel : 70 programmer) AKTIVITAS % WAKTU Waktu Efektif upaya perbaikan atas kegagalan (48%) Waktu overhead (39%) Page 149 / 224 7/8/

150 Diagram distribusi aktivitas programer untuk dua buah proyek perangkat lunak. Page 150 / 224 7/8/

151 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (1) Kemampuan pribadi : - dua aspek dasar kemampuan : kecakapan umum dan terbiasa dengan aplikasi tertentu. - seorang yang cakap dalam pemrograman belum tentu cakap pula dalam aplikasi sains, atau sebaliknya. - ketidakakraban dengan lapangan aplikasi akan menghasilkan produktivitas rendah dan kualitas yang buruk. - yang dimaksud dengan kecakapan umum adalah kemampuan dasar dalam menulis program komputer dengan benar sedangkan ukuran produktivitas seorang programmer adalah banyak baris yang dihasilkan oleh programmer tersebut per hari. Page 151 / 224 7/8/

152 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (2) Komunikasi team - meningkatnya ukuran produk yang dihasilkan akan menurunkan produktivitas programmer akibat meningkatnya kerumitan antara komponen-komponen program dan akibat meningkatnya komunikasi yang perlu dilakukan antara programmer, manajer, dan pelanggan. - jumlah lintasan komunikasi antar programmer yang terjadi dalam sebuah proyek adalah n(n-1)/2, dimana n adalah jumlah programmer yang terlibat dalam proyek tersebut. - penambahan lebih banyak programmer dalam sebuah proyek yang sedang ber-jalan akan menurunkan produktivitas, kecuali jika para programmer baru tersebut mempunyai tugas yang tidak bergantung kepada hasil kerja programmer lama. - Hukum Brooks : Adding more programmers to a late project may make it later. Page 152 / 224 7/8/

153 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (3) Kerumitan produk - tiga level kerumitan produk : program aplikasi, program utility, program level sistem. Page 153 / 224 7/8/

154 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (4) Notasi yang tepat bahasa pemrograman menetapkan notasi (baca : token, reserve word) baku, terutama untuk hal-hal yang berkaitan dengan matematika. penetapan notasi antar programer (baca : perancang produk) harus dilakukan sehingga dapat dimengerti dengan jelas. Page 154 / 224 7/8/

155 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (5) Pendekatan sistematis sistem menetapkan teknik dan prosedur baku. pembakuan dalam pengembangan dan pemeliharaan perangkat lunak masih belum mantap. Page 155 / 224 7/8/

156 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (6) Kendali perubahan kelenturan sebuah produk perangkat lunak merupakan sebuah kekuatan, tetapi di pihak lain juga merupakan sumber kesulitan dalam proses perancangannya. perubahan terhadap produk harus tetap meminta persetujuan manajer sebagai penanggung jawab proyek. dampak perubahan harus dapat ditelusuri, diuji, dan didokumentasikan. Page 156 / 224 7/8/

157 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (7) Tingkat teknologi peran penggunaan teknologi dalam proyek perangkat lunak misalnya menyangkut bahasa pemrograman, lingkungan mesin yang digunakan, teknik pemrograman, dan penggunaan tools tertentu. bahasa pemrograman modern menyediakan fasilitas penyesuaian pendefinisisan dan penggunaan data, konstruksi aliran kendali, fasilitas modular, dan concurent programming Page 157 / 224 7/8/

158 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (8) Tingkat keandalan setiap produk harus mempunyai keandalan standar. peningkatan keandalan dihasilkan melalui perhatian yang sangat besar pada tahap analisa. peningkatan keandalan akan menurunkan produktivitas. Boehm : rasio produktivitas antara dua produk dengan keandalan terendah dengan yang tertinggi adalah 2:1. Page 158 / 224 7/8/

159 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (9) Pemahaman permasalahan -pelanggan adalah penyumbang utama terhadap kegagalan dalam memahami masalah 1. tidak memahami permasalahan perusahaannya 2. tidak mengerti kemampuan dan keterbatasan komputer, 3. tidak mempunyai pengetahuan dasar tentang logika dan algoritma. -software engineer tidak memahami lapangan aplikasi, gagal mendapatkan informasi kebutuhan pelanggan karena pelanggan bukan seorang end user. Page 159 / 224 7/8/

160 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (10) Ketersediaan waktu penetapan lama proyek dan jumlah programmer terlibat harus mempertimbangkan kemampuan pribadi setiap programmer serta kemapuan komunikasi antar mereka. jumlah programmer yang makin banyak akan meningkatkan overhead di antaranya akibat keperluan komunikasi. jumlah programmer yang makin sedikit berarti memperbanyak beban kerja kepada setiap programmer. proyek 1 bulan dengan 6 programmer bisa saja diganti dengan proyek 6 bulan dengan 1 programmer atau proyek 3 bulan dengan 3 programmer. Page 160 / 224 7/8/

161 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (11) Persyaratan keterampilan berbagai keterampilan harus ada dalam sebuah proyek perangkat lunak, misalnya : 1. keterampilan berkomunikasi dengan pelanggan untuk memastikan keinginannya dengan sejelas-jelasnya, 2. kemampuan dalam pendefinisian masalah dan perancangan, 3. kemampuan implementasi dengan penulisan program yang benar, 4. kemampuan debugging secara deduktif dengan kerangka what if, 5. dokumentasi, 6. kemampuan bekerja dengan pelanggan. Semua keterampilan tersebut harus senantiasa dilatih. Page 161 / 224 7/8/

162 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (12) Fasilitas dan sumber daya Fasilitas non teknis yang tetap perlu diperhatikan yang berkaitan dengan motivasi programmer misalnya : mesin yang baik, serta tempat yang tenang, atau ruang kerjanya dapat ditata secara pribadi. Page 162 / 224 7/8/

163 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (13) Pelatihan yang cukup Banyak programmer yang dilatih dalam bidangbidang : ilmu komputer, teknik elektro, akuntansi, matematika, tetapi jarang yang mendapat pelatihan dalam bidang teknik perangkat lunak. Page 163 / 224 7/8/

164 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (14) Kemampuan manajemen seringkali manajer proyek tidak mempunyai, atau hanya sedikit mengetahui, latar belakang teknik perangkat lunak. di sisi lain terjadi promosi jabatan menjadi manajer dimana yang berpromosi tidak atau kurang mempunyai kemampuan manajemen. Page 164 / 224 7/8/

165 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (15) Sasaran yang tepat Sasaran utama dari teknik perangkat lunak adalah pengembangan produk-produk perangkat lunak yang tepat untuk digunakan. Page 165 / 224 7/8/

166 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (16) Peningkatan kualitas Dua aspek yang menimbulkan keinginan untuk meningkatkan kualitas produk adalah : 1. seberapa banyak fungsi, keandalan, dan kemampuan dapat diberikan melalui sejumlah pengembangan 2. masalah mendasar dari keterbatasan teknologi perangkat lunak. Page 166 / 224 7/8/

167 Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (17) Faktor lain Faktor lain di antaranya adalah : keakraban, akses, dan stabilitas terhadap sistem komputer dalam mengembangkan atau memodifikasi perangkat lunak. Page 167 / 224 7/8/

168 Masalah Manajerial Sejumlah masalah yang seringkali muncul : 1. Buruknya perencanaan proyek 2. Buruknya prosedur dan teknik pemilihan manajer proyek 3. Tidak diketahui dengan tepat siapa penanggung jawab buruknya hasil proyek 4. Buruknya kemampuan untuk menetapkan sumber daya yang dibutuhkan proyek 5. Kriteria keberhasilan proyek tidak tepat 6. Buruknya struktur organisasi proyek 7. Pemilihan teknik menajemen yang tidak tepat 8. Tidak diterapkan prosedur, metoda, dan teknik dalam perancangan sistem kendali yang memungkinkan manajer dapat mengontrol proyeknya dengan baik 9. Tidak digunakannya prosedur, teknik, dan strategi yang dapat menyediakan kejelasan perkembangan proyek 10. Standar dan teknik untuk mengukur kualitas kerja dan produktivitas programmer dan analis pengolahan data tidak dijalankan Page 168 / 224 7/8/

169 Beberapa solusi yang dapat dilakukan : 1. lakukan pendidikan dan pelatihan terhadap manajemen puncak dan manajer proyek 2. laksanakan penggunaaan standar, prosedur, dan pendokumentasian 3. lakukan analisa data dari proyek sebelumnya untuk menentukan metode yang efektif 4. tetapkan tujuan dengan menyatakan kualitas yang diinginkan 5. tetapkan kualitas dengan acuan standar peluncuran produk 6. tetapkan kriteria keberhasilan proyek 7. siapkan rencana darurat 8. kembangkan kejujuran, akurasi biaya, dan perkiraan jadwal proyek yang dapat diterima manajemen dan pelanggan 9. pilih manajer proyek berdasarkan kemampuannya memimpin proyek, bukan berdasarkan kemampuan teknik atau (apalagi) memang tidak ada orang lain lagi 10.buat penetapan kerja yang spesifik untuk setiap pelaksana dan tetapkan standar kerja. Page 169 / 224 7/8/

170 JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE) Page 170 / 224 7/8/

171 JAMINAN KUALITAS PL Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak. SQA meliputi : pendekatan manajemen kualitas teknologi rekayasa perangkat lunak yang efektif (metode dan peranti) kajian teknik formal yang diaplikasikan pada keseluruhan proses perangkat lunak strategi pengujian multitiered (deret bertingkat) kontrol dokumentasi perangkat lunak dan perubahan prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak mekanisme pengukuran dan pelaporan. Page 171 / 224 7/8/

172 KONTROL KUALITAS Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan. Konsep kunci kualitas kontrol adalah bahwa semua produk kerja memiliki spesifikasi yang telah ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses. Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan. Page 172 / 224 7/8/

173 JAMINAN KUALAITAS Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. Tujuan jaminan kualitas adalah : untuk memberikan data yang diperlukan oleh manajemen untuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran. Page 173 / 224 7/8/

174 BIAYA KUALITAS Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas. Biaya kualitas dapat dibagi ke dalam biayabiaya yang dihubungkan dengan : pencegahan penilaian kegagalan. Page 174 / 224 7/8/

175 DEFINISI KUALITAS PL Kualitas perangkat lunak didefinisikan sebagai: Konformansi terhadap kebutuhan fungsional dan kinerja yang dinyatakan secara eksplisit, standar perkembangan yang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional. Page 175 / 224 7/8/

176 DEFINISI KUALITAS PL (cont.) Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu: Kebutuhan perangkat lunak merupakan fondasi yang melaluinya kualitas diukur. Standar yang telah ditentukan menetapkan serangkaian kriteria pengembangan yang menuntun cara perangkat lunak direkayasa. Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik). Page 176 / 224 7/8/

177 DEFINISI KUALITAS PL (cont.) Kelompok SQA berfungsi sebagai perwakilan inhouse pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan. Apakah perangkat lunak cukup memenuhi faktor kualitas Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya? Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA? Page 177 / 224 7/8/

178 AKTIVITAS SQA Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda : perekayasa perangkat lunak yang mengerjakan kerja teknis kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan. Page 178 / 224 7/8/

179 KAJIAN PERANGKAT LUNAK Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting. Kajian perangkat lunak adalah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd berbagai titik selama pengembangan PL & berfungsi untuk mencari kesalahan yg kemudian akan dihilangkan. Kajian perangkat lunak berfungsi untuk memurnikan produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean. Page 179 / 224 7/8/

180 KAJIAN TEKNIK FORMAL (Formal Technic Review FTR) FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak. Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan. Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak. Page 180 / 224 7/8/

181 Formal Technic Review FTR (cont.) Tujuan FTR adalah Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL; Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat; Memastikan bahwa PL disajikan sesuai dgn standar yg sudah ditentukan sebelumnya; Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam; Membuat proyek lebih dapat dikelola. Page 181 / 224 7/8/

182 Formal Technic Review FTR (cont.) FTR berfungsi dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi. mengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya. Page 182 / 224 7/8/

183 PERTEMUAN KAJIAN Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus mematuhi batasan-batasan berikut ini : Antara 3 & 5 orang (khususnya) harus dilibatkan dalam kajian; Persiapan awal harus dilakukan, tetapi waktu yang dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap person Durasi pertemuan kajian harus kurang dari 2 jam Page 183 / 224 7/8/

184 PERTEMUAN KAJIAN (cont.) Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan...(ada 3) kemudian ambil keputusan Setelah pertemuan kajian akan dilakukan Pelaporan Kajian & Penyimpanan Rekaman Apa yang dikaji? Siapa yang melakukan? penemuan apa yang dihasilkan dan apa kesimpulannya? Adanya Pedoman Kajian Page 184 / 224 7/8/

185 PENDEKATAN FORMAL TERHADAP SQA Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima. Page 185 / 224 7/8/

186 Sistem Management Kualitas Berdasarkan ISO 9001:2008 System ISO 9001:2008 focus pada effectifitas proses continual improvement dengan pilar utama pola berpikir dimana dalam setiap process senantiasa melakukan perencanaan yang matang, implementasi yang terukur dengan jelas, dilakukan evaluasi dan analisis data yang akurat serta tindakan perbaikan yang sesuai dan monitoring pelaksanaannya agar benar-benar bisa menuntaskan masalah yang terjadi di organisasi. Pilar berikutnya yang digunakan demi menyukseskan proses implementasi ISO 9001 ini, maka ditetapkanlah Delapan prinsip manajemen mutu yang bertujuan untuk mengimprovisasi kinerja system agar proses yang berlangsung sesuai dengan focus utama yaitu effectivitas continual improvement, 8 prinsip manajemen yang dimaksud adalah Page 186 / 224 7/8/

187 Sistem Management Kualitas Berdasarkan ISO 9001: Customer Focus : Semua aktifitas perencanaan dan implementasi system semataa untuk memuaskan customer. 2. Leadership : Top Management berfungsi sebagai Leader dalam mengawal implementasi System bahwa semua gerak organisasi selalu terkontrol dalam satu komando dengan commitment yang sama dan gerak yang synergy pada setiap elemen organisasi 3. Keterlibatan semua orang : Semua element dalam organisasi terlibat dan concern dalam implementasi system management mutu sesuai fungsi kerjanya masingmasing, bahkan hingga office boy sekalipun hendaknya senantiasa melakukan yang terbaik dan membuktikan kinerjanya layak serta berqualitas, pada fungsinya sebagai office boy. Page 187 / 224 7/8/

188 Sistem Management Kualitas Berdasarkan ISO 9001: Pendekatan Proses : Aktifitas implementasi system selalu mengikuti alur proses yang terjadi dalam organisasi. Pendekatan pengelolaan proses dipetakan melalui business process. Dengan demikian, pemborosan karena proses yang tidak perlu bisa dihindari atau sebaliknya, ada proses yang tidak terlaksana karena pelaksanaan yang tidak sesuai dengan flow process itu sendiri yang berdampak pada hilangnya kepercayaan pelanggan 5. Pendekatan System ke Management : Implementasi system mengedepankan pendekatan pada cara pengelolaan (management) proses bukan sekedar menghilangkan masalah yang terjadi. Karena itu konsep kaizen, continual improvement sangat ditekankan. Pola pengelolaannya bertujuan memperbaiki cara dalam menghilangkan akar (penyebab) masalah dan melakukan improvement untuk menghilangkan potensi masalah Perbaikan berkelanjutan : Improvement, adalah roh implementasi ISO 9001:2008 Page 188 / 224 7/8/

189 Sistem Management Kualitas Berdasarkan ISO 9001: Pendekatan Fakta sebagai Dasar Pengambilan Keputusan : Setiap keputusan dalam implementasi system selalu didasarkan pada fakta dan data. Tidak ada data (bukti implementasi) sama dengan tidak dilaksanakannya system ISO 9001: Kerjasama yang saling menguntungkan dengan pemasok : Supplier bukanlah Pembantu, tetapi mitra usaha, business partner karena itu harus terjadi pola hubungan saling menguntungkan. Page 189 / 224 7/8/

190 TUGAS INDIVIDU!! Pelajari 3 bahasan diatas dikarenakan bersifat pemahaman dan wawasan, sebagai evaluasi dosen pertemuan selanjutnya Quiz. Materi Selanjutnya bersifat teknis : 1. Paradigma Perangkat lunak 2. Konsep, Tools dan Prinsip Design Perangkat lunak 3. Strategi, teknik dan Pengujian Page 190 / 224 7/8/

191 VALIDASI SOFTWARE Page 191 / 224

192 Verifikasi vs. Validasi Verifikasi: Are we building the product right Software seharusnya sesuai dengan spesifikasinya Validasion:"Are we building the right product. Software seharusnya melakukan apa yang benar-benar disyaratkan oleh user. RPL 2 Page 192 / 224

193 Proses Verifikasi & Validasi Adalahkeseluruhan proses daur hidup V & V harus diterapkan pada setiap tahapan dalam proses software Mempunyai dua obyektif prinsipal - Menemukan kekurangan dalam sebuah sistem; - Memperkirakan apakah sistem berguna dan dapat digunakan atau tidak dalam situasi operasional RPL 3 Page 193 / 224

194 Tujuan Verifikasi & Validasi Verifikasi dan validasi harus memberikan kepastian bahwa software sesuai dengan tujuannya. Hal ini bukan berarti benar-benar bebas dari kekurangan Harus cukup baik untuk tujuan penggunaannya dan tipe dari penggunaan akan menentukan derajat kepastian yang dibutuhkan RPL 4 Page 194 / 224

195 Kepastian Verifikasi & Validasi Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran Fungsi Software Tingkatkepastian tergantung pada bagaimana software terhadapa sebuah organisasi Harapan User kritikal User mungkin mempunyai harapan yang rendah terhadap software yang ada Lingkungan pemasaran Lebih awal melempar sebuah produk ke pasar lebih penting daripada menemukan kekurangan dalam program RPL 5 Page 195 / 224

196 Verifikasi Statik & Dinamik Software inspection. Berhubungan dengan analisis representasi sistemstatik untuk menemukan masalah (verifikasi statik) Dapat menjadi tambahan dari tool-based document dan code analysis Software testing. Berhubungan dengan pelaksanaan dan memperhatikan perilaku produk (dinamik verifikasi) Sistem dijalankan dengan data tes dan perilaku operasionalnya diperhatikan RPL 6 Page 196 / 224

197 Verifikasi Statik & Dinamik (cont.) RPL 7 Page 197 / 224

198 Pengujian Program Dapat mengungkapkan keberadaan kesalahan bukan ketidakberadaannya Hanya teknik validasi untuk persyaratan nonfunctional sebagai sebuah software dapat dijalankan untuk melihat bagaimana perilakunya Harusnya digunakan dalam hubungannya dengan verifikasi statik untuk menyediakan penanganan Verifikasi &Validasi yang menyeluruh RPL 8 Page 198 / 224

199 Tipe Pengujian Pengujian Kekurangan Test dirancang untuk menemukan kekurangan sistem Uji kekurangan yang berhasil salah satunya adalah menunjukkan keberadaan kekurangan dalam sebuah sistem Pengujian Validasi Ditujukan untuk memperlihatkan bahwa software sesuai dengan persyaratannya Tes yang berhasil adalah salahsatu yang menunjukkan bahwa persyaratan telah diterapkan secara tepat RPL 9 Page 199 / 224

200 Pengembangan Model Verifikasi RPL 10 Page 200 / 224

201 Proses Testing System Testing Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system Acceptance Testing Pengujian terakhir sebelum sistem dipakai oleh user. Melibatkan pengujian dengan data dari pengguna sistem. Biasa dikenal sebagai alpha test ( beta test untuk software komersial, dimana pengujian dilakukan oleh potensial customer) RPL 11 Page 201 / 224

202 Proses Testing (cont.) RPL 12 Page 202 / 224

203 Proses Testing (cont.) Component testing - Pengujian komponen- komponen program - Biasanya dilakukan oleh component developer (kecuali untuk system kritis) Integration testing - Pengujian kelompok komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system - Dilakukan oleh tim penguji yang independent - Pengujian berdasarkan spesifikasi sistem RPL 13 Page 203 / 224

204 Rencana Pengujian Proses testing - Deskripsi fase-fase utama dalam pengujian Pelacakan Kebutuhan - Semua kebutuhan user diuji secara individu Item yg diuji - Menspesifikasi komponen sistem yang diuji Jadual testing Prosedur Pencatatan Hasil dan Prosedur Kebutuhan akan Hardware dan Software Kendala-kendala - Mis: kekurangan staff, alat, waktu dll. RPL 14 Page 204 / 224

205 Failures & Faults Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan Fault: kesalahan dalam source code yang mungkin menimbulkan failure ketika code yg fault tsb dijalankan RPL 15 Page 205 / 224

206 Contoh Faults, Errors & Failures Suppose node 6 should be X:= C*(A+2*B) Failure-less fault:» executing path (1,2,4,5,7,8) will not reveal this fault because 6 is not executed» nor will executing path (1,2,3,5,6,8) because C = 0 Need to make sure proper test cases are selected the definitions of C at nodes 3 and 4 both affect the use of C at node 6»executing path (1,2,4,5,6,8) will reveal the failure,but only if B /= 0 RPL 16 Page 206 / 224

207 Prioritas Testing Hanya test yang lengkap yg dapat meyakinkan sistem terbebas dari kesalahan, tetap hal ini sangat sulitd ilakukan. Prioritas dilakukan terhadap pengujian kemampuans istem, bukan masing-masing komponennya. Pengujian untuk situasi yg tipikal lebih penting dibandingkan pengujian terhadap nilai batas. RPL 17 Page 207 / 224

208 Test Data & Test Kasus Test data:input yang yang direncankan digunakan oleh sistem. Test cases:input yang digunakan untuk menguji sistem dan memprediksi output dari input jika sistem beroperasi sesuai dengan spesifikasi. RPL 18 Page 208 / 224

209 Proses Defect Testing RPL 19 Page 209 / 224

210 Struktural Testing Disebut juga white-box testing Penentuan test case disesuaikan dengan struktur sistem. Knowledge program digunakan untuk mengidentifikasi test case tambahan. Tujuannya untuk menguji semua statement program (debug). RPL 20 Page 210 / 224

211 White Box Testing RPL 21 Page 211 / 224

212 Path Testing Tujuannya meyakinkan bahwa himpunan test case akan menguji setiap path pada suatu program paling sedikit satu kali. Titik awal untuk path testing adalah suatu program flow graph yang menunjukkan node-node yang menyatakan program decisions (mis.: if-thenelse condition) dan busur menyatakan alur kontrol Statements dengan conditions adalah node-node dalam flow graf. RPL 22 Page 212 / 224

213 Program Flow Graph Menggambarkan alur kontrol.setiap cabang ditunjukkan oleh path yg terpisah dan loop ditunjukkan oleh arrows looping kembali ke loop kondisi node. Digunakan sebagai basis untuk menghitung cyclomatic complexity. Cyclomatic complexity = Jumlah edges Jumlah Node + 2. Cyclomatic complexity menyatakan jumlah test untuk menguji control statements RPL 23 Page 213 / 224

214 Program Flow Graph (cont.) RPL 24 Page 214 / 224

215 Independent Path 1, 2, 3, 8, 9 1, 2, 3, 4, 6, 7, 2 1, 2, 3, 4, 5, 7, 2 1, 2, 3, 4, 6, 7, 2, 8, 9 Test cases harus ditentukan sehingga semua path tsb tereksekusi. RPL 25 Page 215 / 224

216 Black Box Testing Pendekatan pengujian dimana program dianggap sebagai suatu black-box ( kotak hitam ) Program test case berbasiskan spesifikasi Test planning dapat dimulai sejak awal proses pengembangan sistem RPL 26 Page 216 / 224

217 Black Box Testing (cont.) RPL 27 Page 217 / 224

218 Black Box Testing (cont.) Pengujian black box berusaha menemukan kesalahan dalam kategori: Fungsi-fungsi yang tidak benar atau hilang Kesalahan interface Kesalahan dalam struktur data atau akses database eksternal Kesalahan kinerja Inisialisasi dan kesalahan terminasi RPL 28 Page 218 / 224

219 Partisi Ekivalensi Input data dan output hasil terdapat diklas yang berbeda yang sesuai dengan klas inputnya Masing-masing klas equivalensi partition diprosres dimana program akan memproses anggota klas-klas tersebut secara equivale. Test cases dipilih dari masing-masing partisi RPL 29 Page 219 / 224

220 PENGUJIAN BERORIENTASI OBJEK Page 220 / 224

221 Object Oriented Testing Komponen yang diuji adalah classobject. Lebih besar dibandingkan pengujian suatu function sehingga pendekatan white-box testing perlu diperluas. Tidak jelasnya top suatu system untuk top-down integration dan testing. RPL 31 Page 221 / 224

222 Testing Levels Testing operations pada objects Testing object classes Testing clusters cooperating objects Testing OO system secara lengkap RPL 32 Page 222 / 224

223 Pengujian Class Menguji terhadap semua operation yg ada dan perubahan atribut-atributnya. RPL 33 Page 223 / 224

224 Cluster Testing Cluster testing digunakan untuk test integrasi terhadap kooperatif object. Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut. RPL 34 Page 224 / 224