4 RPL Slide

http://www.hendra-jatnika.web.id

REKAYASA PERANGKAT LUNAK


PERKENALAN DOSEN- M AHASISWA Nama Tempat Tinggal Pendidikan

: Hendra Jatnika : Garut – Bandung Bandung : 1. D3 Informatika MIPA UNPAD Bandung 2. S1 STMIK-IM Bandung 3. S2 STMIK-LIKMI Bandung

Kegiatan : Dosen Politeknik Piksi Ganesha 2. LP3i Bandung 3. A2K-Proklamasi 4. UNIBI : Konsultan IT/Si 1.

Hp ( Mhs ) Profile Email

: 022-97733557 : hendra-jatnika.web.id : [email protected] (Konsultasi )

: [email protected] [email protected] ( ( tugas )


PERANGKAT LUNAK Perangkat Lunak (Software) tidak (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




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.




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.


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


PERBEDAAN ANTARA RPL DENGAN C OMPUTER S CIENCE ? 

Intinya, computer science berhubungan dengan teori dan metode yang mendasari sistem komputer dan perangkat lunak, sedangkan RPL berhubungan dengan praktek dalam memproduksi perangkat lunak.

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.


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.

2. 3.

Spesifikikasi Perangkat Lunak  Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan. Pengembangan Perangkat Lunak  Perangkat lunak yang memenuhi spesifikasi harus di produksi Validasi Perangkat Lunak  Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.


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).


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

MODEL ATAU PROSES PL 1.

2.

PARADIGMA UMUM PADA


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. Pengembangan evolusioner  Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki


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.


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.




REKAYASA PERANGKAT LUNAK

PERANCANGAN ARSITEKTUR PERANGKAT LUNAK

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.

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.

CONTOH ARSITEKTUR PERANGKAT LUNAK ( 1 )


Model Analisis (DFD level atomik) id_mhs Petugas 1.2.3

info_mhs

mahasiswa

Cari Info Mahasiswa

Arsitektur Perangkat Lunak (Fisik) call Script dan Procedure Cari(NIM)

Search NIM : NIM

Cari Nama

Kelas

query/select Tabel Mahasiswa

CONTOH ARSITEKTUR PERANGKAT LUNAK ( 2 )


Model Analisis (DFD level atomik) 1 Tambah Data Barang

id_barang

Bagian Penjualan

Modul Pemanggil

rec_barang id_supplier Barang

rec_supplier

rec_supplier Supplier

2 Tambah Data Supplier

Arsitektur Perangkat Lunak (Structure Chart) Kelola Data Induk

Proses 2.0

Proses 1.0 Tambah Data Barang id_barang supplier

Tambah Data Supplier rec_barang

id_supplier

rec_supplier

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.

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

CONTOH STRUCTURE CHART : PASCAL ( 1 )


modul pemanggil

A

notasi untuk parameter input yang dikirimkan kepada modul yang dipanggil

x, y

p, q

B

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

•

•

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

CONTOH STRUCTURE CHART : PASCAL ( 2 )


•

•

Modul A akan memanggil modul B jika kondisi dalam modul A dipenuhi. Modul A akan memanggil modul C secara berulang.

Potongan kode program dalam bahasa Pascal

A

B

Procedure C; Begin ... End ; Procedure B; Begin ... End ; Procedure A; Begin

C

CONTOH STRUCTURE CHART : PHP


FormInput.html ...

FormInput

...

Rekam.php

Rekam

id

id

getId

saveId

} function saveId(id) { } id = getId();

CONTOH STRUCTURE CHART : DELPHI


main.pas unit main; ... var Form1: TForm1; implementation uses Rekam; procedure TForm1.Click(Sender: TObject); begin frmRekam.Show; end ;

Main

. end

Rekam rekam.pas unit Rekam; ... var frmRekam: TForm1;

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.

TRANSFORMASI DFD - STRUCTURE CHART ( 2 )


Transform Analysis

Transaction Analysis


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. ) merupakan salah satu fungsi Perencanaan (planning 


Macam Perencanaan 

Perencanaan pembangunan nasional



Regional



Sektoral



Perncanaan personalia/tenaga kerja



Perencanaan peralatan



Perencanaan keuangan



Perencanaan produksi



Perencanaan pemasaran/penjualan


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.

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).


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


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




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


Pembentukan diagr am anak panah sebagai : tahapan per encanaan 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 ).


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.


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.


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




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




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 :


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.


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.






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).


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 (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.


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)


2. 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

http://www.hendra-jatnika.web.id 



1.

2.

3. 4. 5. 6. 7. 8.

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 Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan L sedemikian rupa sehinga hubungan berikut ini terpenuhi. A, B, dan C kegiatan dalam suatu proyek yang bisa dimulai secara serentak (simultan). A dan B mendahului D. B mendahului E, F dan H. F dan C mendahului G. E dan A mendahului I dan J C, D, F dan J mendahului K. K mendahului L.


Jawab.




1.

Contoh pembuatan diagram anak panah 2 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.





1.

2. 3. 4.

5. 6. 7. 8.

Contoh pembuatan diagram anak panah 3 Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan J sedemikian rupa sehinga hubungan berikut ini terpenuhi. Proyek dimulai dari kegiatan A, Kegiatan B dan C baru bisa dimulai kalau A sudah selesai. Kegiatan D dan E baru bisa dimulai kalau C sudah selesai. Kegiatan F dan G baru bisa dimulai kalau B sudah selesai. Kegiatan H baru bisa dimulai kalau E sudah selesai. Kegiatan I baru bisa dimulai kalau D sudah selesai. Kegiatan J baru bisa dimulai kalau G dan H sudah selesai.



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 / 

Keuntungan tidak langsung dari pemakaian network adalah sebagai berikut :


1.

2.

3.

sebelum menyusun suatu network seorang analis harus mengkajirencana secara keseluruhan, merinci dan mengurangi menjadi komponen-komponen kegiatan yang terpisahpisah. Seorang analis harus memikirkan interelasi dari kegiatan-kegiatan. Seorang analis harus memperhitungkan batas waktu untuk mesing-masing unsur kegiatan, sebab setiap kegiatan memerlukan sejumlah


MANAJEMEN PROYEK PERANGKAT LUNAK

1

SOFTWARE PROJECT MANAGEMENT

1 7 O c t -1 0


M ANAJEMEN ? 

Kumpulan orang-orang dalam organisasi ( profesional/non profesioanal )



Bersifat Kekuasaan, mengatur dan memerintah



Pengambilan keputusan dan deadline



Bersifat Strategis, Taktis dan teknis

1 7 O c t -1 0 2


A PAKAH PROYEK ITU ? 

Definisi kamus bahwa Proyek adalah perencanaan / perancangan yang spesifik atau pekerjaan terencana atau pekerjaan yang besar (Longman Concise English Dictionary, 1982)

1 7 O c t -1 0 3


A PAKAH 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

1 7 O c t -1 0 4


M ASALAH 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 



























1 7 O c t -1 0 5


PROYEK PERANGKAT LUNAK VS TIPE PROYEK L AIN 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 

1 7 O c t -1 0 6


PROYEK PERANGKAT LUNAK VS TIPE PROYEK L AIN Karakteristik MPPL 1.

Tidak nampak

2.

Komplek

3.

Flexible

1 7 O c t -1 0 7


FOKUS MPPL (MANAJEMEN PROYEK PERANGKAT LUNAK ) 1 7 O c t -1 0 8


M ANAJEMEN PERSONEL, PRODUK RODUK DAN 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 

1 7 O c t -1 0 9


P ARADIGMA R REKAYASA P PERANGKAT LUNAK


A RTI RTI P ARADIGMA 

Berasal dari bahasa Yunani yang berarti suatu model, teladan, arketif dan ideal.



Paradigma adalah suatu model dalam teori ilmu pengetahuan atau kerangka berpikir.

A RTI 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 .



MODEL W ATERFALL


SEBAGAI MODEL RAKAYASA PERANGKAT LUNAK

Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. 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


Gambar model waterfall

Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance


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.


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.


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.



SETIAP LOOP DALAM

MODEL INI MEWAKILI SEBUAH

TAHAP DARI PROSES PERANGKAT LUNAK . TAHAP YANG TETAP DALAM MODEL INI.

TIDAK ADA M ANAJEMEN

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 PROYEK .

SELAMA PEMBUATAN


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)




P ADA

IMPLEMENTASINYA ,

MODEL

SPIRAL

INI

JUGA BANYAK DIGUNAKAN, TETAPI BIASANYA DIKOMBINASIKAN LAIN.

DENGAN

PERMODELAN

YANG

WATERFALL, YANG SANGAT

BAGUS DALAM MENENTUKAN MILLESTONES DAN PERMODELAN DENGAN

SPIRAL, YANG MENGGUNAKAN

SANGAT

BAGUS

PROTOTYPING,

MERUPAKAN KOMBINASI YANG SERING DIPAKAI DI

DALAM

PERANGKAT

KONTRAK -KONTRAK

UNTUK LUNAK .


BILA TAHAPAN RISK ANALYSIS TIDAK DAPAT DILEWATI, MAKA PROSES DIHENTIKAN, TIDAK MENGIJINKAN PROSES KEMBALI KE TAHAPAN SEBELUMNYA . RISK A NALYSIS 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

PRIORITAS

http://www.hendra-jatnika.web.id 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

PERBEDAAN SPRILAL BAHWA

MENDASAR

DENGAN MODEL

ANTARA http://www.hendra-jatnika.web.id MODEL

MODEL

SPIRAL

LAINNYA ADALAH

DENGAN

EKSPLISIT

MENYADARI RESIKO-RESIKO YANG ADA . ADALAH

KONSEP YANG

SECARA TEPAT. ADALAH

SESUATU

SULIT

SECARA

RESIKO

DIDEFINISIKAN

INFORMAL

YANG

RESIKO

SEDERHANA YANG

DAPAT

MENYEBABKAN

KESALAHAN.

CONTOHNYA ,

JIKA BERTUJUAN

MENGGUNAKAN PEMROGRAMAN BAHASA BARU

(NEW

PROGRAMMING LANGUGE), RESIKO YANG

MUNGKIN ADALAH ALAT DIGUNAKAN

TIDAK

PENGUMPUL

RELIABLE

DAN

YANG TIDAK


UNTUK MENGGUNAKAN

MODEL SPIRAL,

BOEHM

MENYARANKAN SEBUAH BENTUK UMUM YANG DIPENUHI SPIRAL.

DALAM

BENTUK

INI

SETIAP

DAERAH

MUNGKIN

DILENGKAPI

PADA SEBUAH LEVEL ABSTRAK ATAU PERKIRAAN YANG IMBANG DARI PENGEMBANGAN PRODUK .

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

Tahapan Incremental Model adalah : 

Requirement



Specification


Architecture Design



T AHAPAN-TAHAPAN

TERSEBUT DILAKUKAN

SECARA BERURUTAN.

SETIAP

BAGIAN YANG

SUDAH SELESAI DILAKUKAN TESTING, DIKIRIM KE PEMAKAI UNTUK LANGSUNG DAPAT DIGUNAKAN.

P ADA INCREMENTAL MODEL, TIGA TAHAPAN AWAL HARUS DISELESAIKAN TERLEBIH DAHULU



UNTUK MENGANTISIPASI KONDISI YANG TERJADI PADA MODEL M ORE RISKY INCREMENTAL, DIPERKENALKAN MODEL I NCREMENTAL M ODEL. MODEL INI MENERAPKAN SISTEM KERJA SETELAH DAFTAR KEBUTUHAN DIDAPATKAN YANG PARALEL. DARI PEMAKAI, TIM SPESIFIKASI MEMBUAT SPESIFIKASI UNTUK MODUL PERTAMA . SETELAH SPESIFIKASI PERTAMA SELESAI, TIM TIM SPESIFIKASI SEBELUMNYA DESAIN MENINDAK LANJUTI. JUGA LANGSUNG MEMBUAT SPESIFIKASI UNTUK MODEL KEDUA , DAN SETERUSNYA .


MODEL METODOLOGI RAD (R APID A PPLICATION DEVELOPMENT )


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.

http://www.hendra-jatnika.web.id •

•

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.


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


1. CLASSIC LIFE C YCLE P ARADIGMA SISTEM ENGINEERING

 

B. Perancangan



C. Pengkodean



D. Pengujian



E. Maintenance

ANALYS DESIGN

A. Analisis

CODE TESTING MAINTENANCE


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.


3. PROTOTYPE P ARADIGMA 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




3. PROTOTYPE P ARADIGMA REQUIMENTS GATHERING "QUICK DESIGN" BUILD PROTOTYPE EVALUA TED AND REFINEMENTS ENGINEER PRODUCT

4. THE 4TH GENERATION TECHNIQUE P ARADIGMA 


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.

4. THE 4TH GENERATION TECHNIQUE P ARADIGMA REQUIMENTS GATHERING

"DESIGN STRA TEGICS" IMPLEMENTATION USING 4GT PRODUCT



TUGAS !! Buat Perbandingan tiap Model, dan penerpan kasus 1.

Waterfall

2.

Spiral

3.

Incerementa

4.

Rad

5.

Build and Fixed


Perencanaan Proyek Perencanaan PL & Manajemen Resiko


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!




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? 












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




Sumber Daya Proyek

Manusia Komponen PL PK & PL




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.




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






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




PL & PK 

PK menyediakan sebuah platform yang mendukung PL yang dibutuhkan untuk menghasilkan produk kerja yang merupakan keluaran dari RPL yang baik


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




TeknikDekomposisi  

Dekomposisi Masalah Dekomposisi Proses

Statement of Scope

performa parse"

functional decomposition




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




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)

  




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.


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.




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

ab

bb

cb

db

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




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




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

ai

bi

Organik

2,4

1,05

Semi-detached

3,0

1,12




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.




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




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








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




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?


Manajemen Resiko

W h at What What What

c an g o w r o n g ? i s t h e l i k el i h o o d ? w ill the damage be? c an w e d o a b o u t i t ?




Risk Management Paradigm control track

RISK plan analyze

identify


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




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




Risiko yang dapat diramalkan dimana risiko ini diekstrapolasi dari pengalaman proyek sebelumnya






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? 
















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?




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?




Ukuran & pengalaman staf  

Apakah orang-orang yang terbaik didapatkan?

Jumlah orang yang bekerja paruh waktu / tidak?


 



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


 

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


MATERI 1. Manajemen Resiko 2. Kualitas Perangkat Lunak 3. SQA


Manajemen Resiko Perangkat Lunak

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.


Strategi Resiko Reaktif vs Proaktif Strategi Reaktif Memonitor proyek kemungkinan resiko.

yg

berjalan

terhadap

Strategi Proaktif Dimulai sebelum kerja teknis diawali, dan diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.


Kategori resiko oleh Robert Charette 1. Resiko yang sudah diketahui ( pasti ) 2. Resiko yang dapat diestimasi 3. Resiko yang tidak diharapkan


Resiko Perangkat Lunak Karakteristik resiko : 1. Ketidakpastian 2. Kerugian

Kategori resiko : 1. Resiko proyek ( Mou) 2. Resiko teknis 3. Resiko bisnis ( Market)


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

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


5. 6. 7. 8. 9.

Ketidakpastian teknik Verivikasi Keusangan teknik Masalah pemeliharaan Teknologi


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


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


Resiko yg dapat diramalkan / Estimasi Dazari pengalaman proyek sebelumnya.

Misalnya : 1. Pergantian staf 2. Penggantian Resouce


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.


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.


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.


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.


Proyeksi / estimasi resiko Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko : 1

Membangun suatu skala yang kemungkinan risiko yang dirasakan

merefleksikan

2 Menggambar konsekuensi risiko

3 Memperkirakan pengaruh risiko pada proyek dan produk 4 Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman


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.


Faktor Yang Mempengaruhi Kualitas Produk


Penggunaan Waktu Seorang Programmer Tabel aktivitas programmer (Bell Lab. Study, sampel : 70 programmer) %

AKTIVITAS

WAKTU

Penulisan program

13

Membaca program dan membuat manual

16

Mengkomunikasi pekerjaan

32

Kegiatan pribadi (libur, sakit, dsb)

13

Lain-lain (kamar kecil, telefon pribadi, rehat kopi, dsb)

15

Pelatihan

6

Surat menyurat

5

Waktu Efektif upaya perbaikan atas kegagalan (48%)

Waktu overhead

(39%)


Diagram distribusi aktivitas programer untuk dua buah proyek perangkat lunak.


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.


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.


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



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.



Pendekatan sistematis •

•

sistem menetapkan teknik dan prosedur baku. pembakuan dalam pengembangan dan pemeliharaan perangkat lunak masih belum mantap.



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.



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



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


Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (9) Pemahaman permasalahan

- pelanggan adalah penyumbang utama terhadap kegagalan dalam memahami masalah 1. 2. 3.

tidak memahami permasalahan perusahaannya tidak mengerti kemampuan dan keterbatasan komputer, 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



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.



Persyaratan keterampilan berbagai keterampilan harus ada dalam sebuah proyek perangkat lunak, misalnya : 1. 2. 3. 4. 5. 6.

kete ketera ramp mpil ilan an ber berko komu muni nika kasi si den denga gann pela pelang ngga gann untu untukk memastikan keinginannya dengan sejelas-jelasnya, kema kemamp mpua uann dala dalam m pend pendef efin inisi isian an mas masal alah ah dan dan pera peranc ncan anga gan, n, kema kemamp mpua uann impl implem emen enta tasi si deng dengan an penu penuli lisa sann progr program am yan yangg bena benar, r, kemampuan debugging secara deduktif dengan kerangka “what if ”, dokumentasi, kema kemamp mpua uann beke bekerj rjaa deng dengan an pela pelang ngga gan. n.



Fasilitas dan sumber daya

•

Fasilitas non teknis yang tetap perlu diperhatikan yang berkaitan dengan motivasi programmer programmer misalnya : mesin yang baik, serta tempat yang tenang, atau ruang kerjanya dapat ditata secara pribadi.



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.



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.



Sasaran yang tepat

•

Sasaran utama dari teknik perangkat lunak adalah pengembangan produk-produk perangkat lunak yang tepat untuk digunakan.



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.



Faktor lain •

Faktor lain di antaranya adalah : keakraban, akses, dan stabilitas terhadap sistem komputer dalam mengembangkan atau memodifikasi perangkat lunak.

Masalah Manajerial


Sejumlah masalah yang seringkali muncul :

1. 2. 3. 4. 5. 6. 7. 8. 9. 10

Buruknya perencanaan proyek Buruknya prosedur dan teknik pemilihan manajer proyek Tidak diketahui dengan tepat siapa penanggung jawab buruknya hasil proyek Buruknya kemampuan untuk menetapkan sumber daya yang dibutuhkan proyek Kriteria keberhasilan proyek tidak tepat Buruknya struktur organisasi proyek Pemilihan teknik menajemen yang tidak tepat Tidak diterapkan prosedur, metoda, dan teknik dalam perancangan sistem kendali yang memungkinkan manajer dapat mengontrol proyeknya dengan baik Tidak digunakannya prosedur, teknik, dan strategi yang dapat menyediakan kejelasan perkembangan proyek Standar dan teknik untuk mengukur kualitas kerja dan


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

JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE)



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.


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.


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.


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. –

–

–


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.


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). –

–

–


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


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.


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.


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.


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; –

–

–

–


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.


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 –

–

–


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


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.

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

Sistem Management Kualitas Berdasarkan ISO 9001:2008


1.

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


Sistem Management Kualitas Berdasarkan ISO 9001:2008 4.

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.


Sistem Management Kualitas Berdasarkan ISO 9001:2008 7.

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:2008

8.

Kerjasama yang saling menguntungkan dengan pemasok : Supplier bukanlah Pembantu, tetapi mitra usaha, business partner karena itu harus terjadi pola hubungan saling menguntungkan.


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


VALIDASI SOFTWARE


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


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


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


Kepastian Verifikasi & Validasi 

Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran – Fungsi – Fungsi Software • Tingkatkepastian tergantung pada bagaimana kritikal software terhadapa sebuah organisasi – Harapan – Harapan User • User mungkin mempunyai harapan yang rendah terhadap software yang ada – Lingkungan – Lingkungan pemasaran • Lebih awal melempar sebuah produk ke pasar lebih penting daripada menemukan kekurangan dalam program

RPL

5


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

RPL

6


Verifikasi Statik Statik & Dinamik Dinamik (cont.)

RPL

7


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


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


Pengembangan Model Verifikasi

RPL

10


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


Proses Testing (cont.)

RPL

12


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


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


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


Contoh Faults, Errors & Failures 



RPL

Suppose node 6 should be X:= C*(A+2*B) • Failure-less 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

16


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


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


Proses Defect Testing

RPL

19


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


White Box Testing

RPL

21


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


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


Program Flow Graph (cont.)

RPL

24


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


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


Black Box Testing (cont.)

RPL

27


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


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


PENGUJIAN BERORIENTASI OBJEK


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


Testing Levels 

Testing operations pada objects



Testing object classes



Testing clusters cooperating objects



Testing OO system secara lengkap

RPL

32


Pengujian Class 

RPL

Menguji terhadap semua operation yg ada dan perubahan atribut-atributnya.

33

4 RPL Slide

Recommend Documents