Makalah Uji Kualitas Rekayasa Perangkat Lunak | MUDA MUDI CONDROWANGSAN

Makalah Uji Kualitas Rekayasa Perangkat Lunak



Makalah Uji Kualitas Rekayasa Perangkat Lunak


KELOMPOK :
SOFYAN TOHARI (123090236)
HERRY ARDIANTO N (123090076)
ZAKAR NNAS (123090182)
FEBRIAN BUDI P (123090180)


PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNOLOGI INDUSTRI
UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN” YOGYAKARTA
2012


BAB I
COMPUTER SYSTEM ENGINEERING


Computer system engineering (Rekayasa Sistem Komputer) terdiri atas 2 bagian, yaitu :
1. Hardware engineering
2. Software engineering

Setiap disiplin ini berusaha menunjukkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan saat ini menggantikan peranan hardware sebagai elemen sistem yang sulit direncanakan, sedikit kemungkinan untuk berhasil dengan biaya rendah dan waktu yang cepat, serta paling sukar untuk dikelola.

Apa Sistem itu ?
Sistem adalah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapatkan beberapa metode, prosedur atau pengontrolan dengan cara mengelola informasi.
Elemen-elemen dari sistem berbasis komputer adalah :
1. Software
Program komputer, struktur data dan dokumentasi yang saling berhubungan dan memberikan efek pada metode, prosedur dan kontrol yang diinginkan.
2. Hardware
Peralatan elektronik, (misalnya CPU, memory) yang memberikan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memberikan fungsi external.
3. People / Brainware
User dan operator dari hardware dan software
4. Database
Sekumpulan informasi yang besar, yang diorganisir agar dapat diakses oleh software dan merupakan bagianintegral dari fungsi sistem.
5. Prosedur
Computer system engineering adalah suatu aktifitas pemecahan masalah fungsi sistem yang diinginkan, ditemukan, dianalisis, dan dialokasikan ke elemen-elemen sistem individu.
Computer System Engineering disebut juga Sistem Analis, dimulai dengan :
1. Penetapan tujuan customer
2. Hambatan-hambatan dan representasi fungsi performance yang dapat dialokasikan ke masing-masing elemen sistem. Segera setelah fungsi performance, hambatan dan interface ditetapkan, system engineering selanjutnya melakukan
pekerjaan alokasi. Selama pengalokasian fungsi diserahkan kepada satu / lebih elemen sistem (misalnya software, hardware, people, dll) seringkali alokasi alternatif diusulkan dan dievaluasi.


PERTIMBANGAN HARDWARE
Computer System Engineering selalu mengalokasikan satu / lebih fungsi sistem ke hardware komputer.
Elemen-elemen hardware
1.      CPU - Cenral Processing Units
2.  Adalah unit yang melakukan pekerjaan aritmatik, logika, dan fungsi pengontrol serta berinteraksi dengan komponen lainnya. Sekarang ini, beberapa arsitektur komputer ditambahkan ko-prosesor untuk melakukan fungsi pengolahan khusus ( fungsi kalkulasi ) sehingga performance CPU dapat ditingkatkan.
3.  BUS
4.  Adalah alat komunikasi yang menghubungkan elemen satu dengan elemen lainnya untuk pengiriman instruksi, data dan informasi pengontrolan.
5.  Memory
6.  Memory memberikan tempat penyimpanan instruksi dan data yang dapat diakses langsung / tidak langsung melalui perintah yang dieksekusi oleh CPU dan ko-prosesornya.

Memory terbagi menjadi 2 bagian, yaitu :
A. Memori Primer / Primary Memory / Main Memory
Adalah memory yang terdapat di dalam komputer, terdiri atas 2 bagian yaitu :
i.                    RAM - Random Access Memory
Untuk menyimpan data / instruksi yang bersifat temporary
ii.                  ROM - Read Only Memory / Firmware
Untuk menyimpan perintah dan / atau data yang permanen.
ROM terbagi atas 2 golongan
·         PROM - Programmabel Read Only Memory
Memory ROM yang dapat ditulis / diprogram dan dapat dihapus dengan cara :
1EEPROM - Eraseble Electrical Programmabel ROM
Dihapus dengan kejutan listrik tertentu
1UVPROM - Ultra Violet Programmabel ROM
Dihapus dengan sinar ultra violet
·         b. MASK ROM
ROM yang terjual sudah diprogram pada saat dibuat oleh pabriknya.

B. Memory Sekunder
Sifat yang menonjol dari memory jenis ini adalah :
i.                    Waktu akses lambat
ii.                  Kapasitas besar sekali dibandingkan dengan memory primer
iii.                Waktu akses berkisar milidetik dengan kapasitas antara 400.000 sampai 1 billion byte
iv.                Contoh : Floppy disk, harddisk, hardcard, optical disk

APLIKASI HARDWARE
Dapat dikelompokan dalam 3 bagian besar, yaitu :
1. Pengelolahan informasi
2. Pengontrolan proses dan aplikasi real time
3. Tambahan intelegensi

REKAYASA HARDWARE
Untuk komputer digital yang dikembangkan dari perancangan elektronik, proses perancangannya terdiri dari 3
tahap :
1.      Perencanaan dan spesifikasi
2.  Perencanaan dan implementasi prototype
3.  Manufaktur distribusi dan pelayanan
Segera / sesudah analisis dan definisi dijalankan, fungsi dialokasikan ke hardware.

Definisi sistem merupakan langkah pertama dalam fase perencanaan.
Tujuan dari definisi sistem ini adalah :
1. Evaluasi konsep sistem : feasibility, cost benefit, dan businness needs
2. Jelaskan interface, function, dan performance sistem
3. Alokasi fungsi pada hardware, software dan elemen tambahan.

Tujuan dari perencanaan software adalah mengestimasi biaya dan waktu pengembangan. Untuk mencapai ini, lingkup software harus dimengerti dengan sempurna, dan sumber harus ditentukan dengan tepat.
Analisis kebutuhan software memperjelas :
1. Software interfaces
2. Atribut fungsional
3. Karakteristik performance
4. Kendala desain
5. Kriteria validasi














BAB II
SOFTWARE ENGINEER

PERENCANAAN SOFTWARE
Untuk melaksanakan pengembangan proyek software dan berhasil, kita harus mengerti :
1. Ruang lingkup pekerjaan yang dilakukan
2. Sumber yang diinginkan
3. Usaha dan biaya
4. Jadual yang dikehendaki

Perencanaan software adalah :
Langkah kedua dalam fase perencanaan, tetapi merupakan langkah pertama dalam proses rekayasa software yang akan memberikan pengertian kepada 4 hal di atas.
Perencanaan software mengkombinasikan 2 tugas, yaitu :
1.      Riset
2.  Estimasi

Tujuan perencanaan software :Memberikan suatu kerangka yang memungkinkan manajer membuat estimasi yang beralasan tentang sumber, biaya dan jadual.

PROSES DESAIN SOFTWARE
Desain dalam fase pengembangan merupakan langkah pertama, di mana fase pengembangan merupakan fase
kedua dalam siklus hidup software.
Segera sesudah kebutuhan software ditetapkan, dimulailah fase pengembangan yang terdiri dari 4 langkah
berbeda :
1. Desain awal (preliminary design)
2. Detailed Design (Desain primeir)
3. Coding
4. Testin

BAB III
KONSEP MANAJEMEN PROYEK


SPEKTRUM MANAJEMEN
Manajemen proyek Perangkat Lunak (PL) yang efektif berfokus
pada 3 P, dimana harus berurut yaitu
PEOPLE                   : Elemen terpenting dari suksesnya proyek
PRODUCT /
PROBLEM                : Software yang dikembangkan
PROCESS                 : Suatu kerangka kerja dari suatu aktifitas dan kumpulan tugas   
                                       untuk memgembangkan PL
PROJECT (tambahan)        : Penggabungan semua kerja untuk membuat produk menjadi kenyataan

PEOPLE ( MANUSIA)
SEI telah mengembangkan suatu model kematangan kemampuan manajemen manusia (People Management Capability Manurity Model ( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, menyebarkan dan memelihara bakat yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka.

Model kematangan manajemen manusia membatasi pada
Rekruitmen
Seleksi
·         Manajemen unjuk kerja
·         Pelatihan
·         Kompensasi
·         Pemgembangan karir
·         Desain kerja & organisasi
·         Perkembangan karir tim /
·         Kultur
·         =
Manusia dalam pengembangan PL terdiri dari :
a. Player (Pemain)
-   Manajer Senior menentukan isu bisnis yang mempengaruhi dalam proyek
-  Manajer Proyek merencanakan, memotivasi, mengorganisir, mengontrol
    aplikasi/produk
- Pelaksana mempunyai ketrampilan teknik untuk merekayasa aplikasi
- Pelanggan menentukan jenis kebutuhan bagi PL yang akan dibuat
- Pemakai akhir yang berinteraksi dengan PL yang dibuat
b. Team Leader (Pimpinana Tim)
Manajemen proyek merupakan kegiatan manusia intensif sehingga memerlukan praktisi yang cakap.
Model Kepemimpinan (MOI yaitu Motivasi, Organisasi, gagasan & Inovasi) menurut Jerry Weinberg.
Karakteristik yang menentukan manajer proyek efektif yaitu
- Pemecahan Masalah - Prestasi
- Identitas manajerial - Pengaruh & pembentukan tim
c. The Software Team ( Tim PL)
Sumber daya manusia kepada sebuah proyek yang akan membutuhkan n manusia yang bekerja selama k tahun , ada beberapa alternatif untuk menentukan sumber daya.

Mantei, mengusulkan 3 organisasi tim yaitu:
·         Demokrasi terdesentralisasi (DD)
Tidak memiliki pimpinan permanen dan koordinator dipilih untuk tugas pendek bila tugas berbeda maka pimpinan berbeda. Keputusan diambil oleh konsensus kelompok dan
komunikasi secara horizontal
·         Terkontrol terdesentralisasi (CD)
Tim memiliki pimpinan tertentu dan memiliki pimpinan skunder untuk sub-sub masalah. Pemecahan masalah merupakan aktifitas dari kelompok dan implentasi pemecahan pada sub-sub kelompok. Komunikasi antar kelompok dan orang bersifat horizontal tetapi komunikasi secara vertical berjalan bila hirarki kontrol berjalan .
·         Terkontrol tersentralisasi (CC)
Pemecahan tingkat puncak dan internal tim oleh pimpinan tim. Komunikasi dilakukan secara vertical.

7 faktor proyek yang harus dipertimbangkan dalam rencanakan
tim RPL yaitu :
1.      Kesulitan pada masalah
2.  Ukuran program yang dihasilkan (LOC / function)
3.  Waktu tim (umur)
4.  Tingkat dimana dapat dimodularitasi
5.  Kualitas serta keandalan
6.  Kepastian tanggal penyampaian
7.  Tingkat sosiabilitas / komunikasi

Constantine, mengusulkan 4 paradigma organisasional bagi tim RPL
1. Paradigma Tertutup
    Membentuk hirarki otoritas tradisional ( mirip tim CC) tetapi kurang inovatif
2. Paradigma Random
     Membentuk tim longgar & tergantung pada inisiatif individual tim, untuk inovasi
    sangat baik(unggul) bila unjuk kerja tim teratur.
3. Paradigma Terbuka
     Membentuk tim dengan cara tertentu sehingga banyak kontrol, inovasi banyak . Cocok
     untuk masalah yang kompleks tetapi tidak seefesien tim lainnya
4. Paradigma Sinkron
     Mengorganisasikan tim untuk bekerja pada bagian-bagian kecil masalah dengan
     komunikasi aktif pada tim

Coordinatian & Communication Issue (masalah koordinasi & komunikasi)
Proyek PL mengalami kesulitan dikarenakan :
·         Skala usaha pengembangan yang besar sehingga kesulitan dalam mengkoordinasi anggota tim & Kompleksitas yang semakin besar
·         Ketidakpastian mengakibatkan perubahan terus menurus pada proyek
·         Interoperabilitas merupakan ciri dari sistem dan menyesuaikan dengan batasan sistem

Kraul & Streeter menguji sekumpulan teknik koordinasi proyek yang dibagi atas
·         Pendekatan impersonal, formal penyampaian & dokumen RPL (memo, laporan dll)
·         Prosedure interpersonal, formal aktifitas jaminan kualitas yang diterapkan kepada produk kerja RPL (status pengkajian , perancangan & inpeksi kode)
·         Prosedure interpersonal, informal pertemuan kelompok untuk menyebarkan informasi & pemecahan masalah serta pengembangan staf
·         Komunikasi teknik, surat elektronis, web sites, teleconferens, papan buletin elektronik
·         Jaringan interpersonal diskusi informal pada orang diluar proyek untuk mendapatkan pengalaman sehinnga mendukung kerja proyek



















BAB IV
PROSES PL DAN METRIK PROYEK


PROBLEM / PRODUCT
Analisis yang mendetail mengenai kebutuhan PL akan memberikan informasi untuk menghitung perkiraan kuantitatif & perencanaan organisasi. Tetapi itu sulit karena informasi yang diberikan customer tidak lengkap.
Ruang lingkup masalah dibatasi dengan :
·         Konteks
PL yang dibangun memenuhi sistem, produk / konteks bisnis yang lebih besar     serta batasan yang menentukan hasilnya
·         Tujuan informasi
Objek pelanggan yang dihasilkan sbg output dr PL yang dapat digunakan sebagai input
·         Fungsi & unjuk kerja
     PL digunakan untuk mentransformasikan input menjadi output

Pernyataan ruang lingkup dibatasi (data jumlah pemakai simultan,ukuran pengiriman, waktu mak respon ), batasan /& jangka waktu dicatat (biaya produk membatasi jumlah memori) & factor mitigasi (algoritma yang dibutuhkan software aplikasi (pemograman)).

Dekomposisi Masalah / pembagian masalah diterapkan pada :
- Fungsionalitas yang disampaikan
- Proses yang dipakai

PROCESS
Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan sejumlah kumpulan tugas yang berbeda, kemampuanpenyampaian & jaminan kualitas

·         Aktifitas pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran
Model PROSES :
1. Sekunsial Linier
Classic Life Cycle / model air terjun
2. Prototipe
Perencanaan kilat untuk konstruksi oleh prototype
3. Rapid Aplication Development (RAD)
Model sekunsial linier yang menekankan siklus pengembangan yang sangat pendek dengan pendekatan konstruksi berbasis komponen
4. Inkremental (Pertambahan)
Menggabungkan elemen-elemen model sekunsial linier dengan filosopi prototype iterative khusus untuk staffing
5. Spiral
Merangkai sifat iterative dari prototype dengan cara kontrol & aspek sistematis dari sekunsial linier
6. Rakitan Komponen
Paradigma orientrasi obyek menekankan kreasi kelas yang mengenkapsulasi data & algoritma yang dipakai untuk memanipulasi data (gabungan dengan karakter spiral)
7. Perkembangan Komponen
Sering dipakai untuk mengembangkan aplikasi client server
Aktifitas dibagi menjadi :
-          dimensi sistem : desain, assembly & pemakai
-          dimensi komponen : desain & realisasi
8. Metode Formal
Mengkhususkan, mengembangkan, & menverifikasi sistemberbasis komputer dengan notasi matematis yang tepat (Clean room RPL)
9. Teknik Generasi Keempat
Serangkaian alat bantu PL yang secara otomatis memunculkan kode sumber yang berdasarkan pada spesifikasi perekayasaan



Serangkaian aktifitas kerja PL :
1. Komunikasi pelanggan
2. Perencanaan
3. Analisa Resiko
4. Rekayasa
5. Konstruksi dan rilis
6. Evaluasi Pelanggan


PROYEK
Profesional industri sering mengacu pada aturan 90-90 yaitu pada saat mendiskusikan proyek PL yang sukar maka 90 % dr sistem yang pertama menyerap 90 % dari usaha & waktu yang diberikan. 10 %terakhir mengambil 90 % lain dari usaha & waktu yang diberikan.
Dr penyataan tersebut proyek mengalami kesulitan yaitu
1.      Kemajuan mengalami kecacatan
2.      Tidak ada cara untuk mengkalibrasi kemajuan karena tidak memperoleh matrik   
      kuantitatif
3.      Rencana proyek belum dirancang untuk menakomodasi sumber daya yang         diperlukan pada akhir sebuah proyek
4.      Resiko-resiko belum mempertimbangkan secara eksplisit serta belum dibuat rencana untuk mengurangi, mengatur & memonitor
       5.  Jadual yang ada tidak realistis & cacat
Untuk mengatasi masalah tersebut maka diperlukan waktu pada awal proyek untuk membangun rencana yang realistis guna memonitor rencana proyek selama berjalan & pada keseluruhan proyek serta mengontrol kualitas serta perubahannya.







BAB V
PERENCANAAN PROYEK PERANGKAT LUNAK

Proses manajemen proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini adalah estimation (perkiraan). Estimasi membawa resiko yang inheren (dari diri sendiri) dan resiko inilah yang membawa ketidakpastian. Yang mempengaruhi estimasi :
- Project complexity (kompleksitas proyek)
- Project size (ukuran proyek)
- Struktural uncertainty (ketidakpastian struktural)

Tujuan Perencanaan Proyek Perangkat Lunak : menyediakan sebuah kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan terhadap sumber daya, biaya dan jadwal pada awal proyek yang dibatasi oleh waktu.
Aktifitas Perencanaan Proyek PL
1. Menentukan ruang lingkup PL
2. Mengestimasi sumber daya yang dibutuhkan

RUANG LINGKUP PL
Ruang lingkup PL menggambarkan : fungsi, kinerja, batasan, interface dan reliabilitas.
Fungsi yang digambarkan dlm statemen ruang lingkup dievaluasi untuk memberikan awalan yang lebih detail pada saat dimulai estimasi. Kinerja melingkupi pemrosesan dan kebutuhan waktu respon. Batasan mengidentifikasi batas yang ditempatkan pada PL oleh perangkat keras eksternal, memori atau sistem lain.

Informasi yang dibutuhkan (awal pertemuan antara pelanggan dan pengembang)
* Pertanyaan berfokus pada pelanggan, tujuan keseluruhan serta keuntungan.
- Siapa di belakang permintaan kerja ini?
- Siapa yang akan memakai solusi ini?
- Apakah keuntungan ekonomi dari solusi yang sukses?
- Adakah sumber daya lain bagi solusi ini?
* Pertanyaan yang memungkinkan analis memahami masalah lebih baik dan
pelanggan menyuarakan persepsi tentang sebuah solusi.
- Bagaimana Anda (pelanggan) menandai output yg baik yg akan dihasilkan
oleh sebuah solusi yg baik?
- Masalah apa yang dituju solusi ini?
- Dapatkah anda menggambarkan lingkungan dimana solusi akan dipakai?
- Adakah batasan atau isu kinerja khusus yg akan mempengaruhi
PL berinteraksi dengan elemen sistem berbasis komputer. Konsep sebuah
interface diinterpretasi untuk menentukan:
1. Hardware yg mengeksekusi PL dan device yg dikontrol secara tidak
langsung oleh PL
2. Software yg sudah ada dan harus dihubungkan dengan PL yg baru
3. Manusia yg menggunakan PL melalui keyboard atau perangkat I/O lain
4. Prosedur

SUMBER DAYA
1. Manusia
2. Perangkat Lunak
Kategori yg diusulkan BEUNATAN
- Komponen Off-the-self
- Komponen Full-Experience
- Komponen Partial-Experience
- Komponen Baru
3. Lingkungan (Software Engineering Environment - SEE), menggabungkanPL dan 
   Perangkat Keras.

Estimasi biaya dan usaha dapat dilakukan dengan cara :
1. Menunda estimasi sampai akhir proyek.
2. Berdasarkan estimasi pada proyek yg mirip sebelumnya.
3. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan usaha
    proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya PL.

Akurasi estimasi proyek PL didasarkan pada :
1. Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan
    dibuat.
2. Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar.
3. Tingkat dimana rencana proyek mencerminkan kemampuan tim PL.
4. Stabilitas syarat produk serta lingkungan yg mendukung usaha pengembangan PL.

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

MODEL COCOMO
Barry Boehm memperkenalkan hirarki model estimasi PL dengan nama COCOMO (COnstructive COst MOdel = Model Biaya Konstruktif) yang berbentuk sbb :
1. Model COCOMO Dasar
Menghitung usaha pengembangan PL (dan biaya) sbg fungsi dari ukuran program yg diekspresikan dalam baris kode yg diestimasi (LOC).
2. Model COCOMO Intermediate
Menghitung usaha pengembangan PL sbg fungsi ukuran program dan serangkaian 'pengendali biaya' yg menyangkut penilaian yg subyektif thd produk, perangkat keras, personil dan atribut proyek.
3. Model COCOMO Advance
Menghubungkan semua karakteristik versi intermediate dg penilaian thd pengaruh pengendali biaya pd setiap langkah (analis, perancangan, dll) dari proses rekayasa PL.

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

Model dasar ini dapat diperluas dengan mempertimbangkan kumpulan 'atribut pengendali biaya' yg dikelompokkan dalam 4 kategori utama :
1. Atribut produk
-          ukuran keandalan proyek
-          ukuran dari aplikasi database
-          kekompleksan produk
2. Atribut perangkat keras
-          kendala performansi run-time
-          kendala memori
-          lingkungan dari violability dari virtual memori
-          waktu perputaran yg diperlukan
3. Atribut personil
-          kemampuan sistem analis
-          kemampuan software engineering
-          pengalaman aplikasi
-          pengalaman virtual mesin
-          pengalaman bahasa pemrograman
4. Atribut proyek
-          pemakaian alat bantu PL
-          metode aplikasi software engineering
-          jadwal pengembangan

KEPUTUSAN MAKE-BUY
Pada aplikasi PL, dari segi biaya sering lebih efektif membeli dari pada mengembangkan sendiri. Manajer RPL dihadapkan pada keputusan make-buy dengan pilihan :
1. PL dapat dibeli (atau lisensi) off-the-self.
2. Komponen PL full-experience dan partial-experience, dapat diperoleh dankemudian  
    dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.
3. PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi 
    pembeli.

Untuk produk PL yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan:
1. Kembangkan spesifikasi untuk fungsi dan kinerja PL yg diperlukan.
2. Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian.
3          a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi anda.
3          b. Pilih komponen yang reusable yg dapat membantu konstruksi aplikasi yg
                diperlukan.
4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon PL.
5. Evaluasi masing-masing paket PL berdasarkan kualitas produk sebelumnya, dukungan
    penjual, arah proyek, reputasi dsb.
6. Hubungi pemakai PL lain dan mintalah pendapat mereka.

Pada analisis akhir, keputusan make-buy berdasarkan kondisi sbb:
1. Tanggal penyampaian
2. Biaya yang diperlukan
3. Dukungan





MEMBUAT POHON KEPUTUSAN
Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan :
1. membangun sistem X dari permulaan
2. menggunakan lagi komponen partial experience yang ada untuk membangun sistem
3. membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi untuk 
    memenuhi kebutuhan lokal
4. mengkontrakkan pengembangan PL ke vendor luar
























BAB VI
MANAJEMEN RESIKO

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 terhadap kemungkinan resiko. Sumber2 daya dikesampingkan, padahal seharusnya sumber2 daya menjadi masalah yang sebenarnya / penting.
Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & pengaruh proyek diperkirakan, dan diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko.

Sasaran utama adalah menghindari resiko.
Resiko Perangkat Lunak
Karakteristik resiko :
1. Ketidakpastian
2. Kerugian
Kategori resiko :
· Resiko proyek
· Resiko teknis
· Resiko bisnis

Kategori resiko oleh Robert Charette :
· Resiko yang sudah diketahui
· Resiko yang dapat diramalkan
· Resiko yang tidak diharapkan



@ Resiko proyek
Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi bertambah.
Resiko proyek mengidenifikasi :
- biaya - sumber daya
- jadwal - pelanggan
- personil (staffing & organisasi) - 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.
Resiko teknis mengidentifikasi :
- desain potensial - ambiquitas
- implementasi - spesifikasi
- interfacing - ketidakpastian teknik
- verivikasi - keusangan teknik
- masalah pemeliharaan - teknologi yg leading edge
@ Resiko bisnis
Resiko bisnis mengancam viabilitas PL yg akan dibangun. Resiko bisnis membahayakan proyek atau produk.

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).
@ 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 :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg dapat diramalkan
diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya :
- pergantian staf
- komunikasi yg buruk dgn para pelanggan
- mengurangi usaha staff bila permintaan pemeliharaan
sedang berlangsung dilayani
@ Resiko yg tidak diharapkan
resiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
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.
Tipe resiko :
1. resiko generik merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya dapat diidentifikasi dgn pemahaman khusus mengenai
teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.

Metode untuk mengidentifikasi resiko adalah menciptakan checklist item resiko.
Kategori checklist item resiko :
o resiko ukuran produk
o resiko yg mempengaruhi bisnis
o resiko yg dihubungkan dgn karakteristik pelanggan
o resiko definisi proses
o resiko teknologi yang akan dibangun
o resiko lingkungan pengembangan
o resiko yg berhubungan dgn ukuran dan pengalaman staf

Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg lalu sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik langsung dengan kenyataan teknis.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berhubungan dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai keinginan yg berbeda.
- Pelanggan memiliki kepribadian yg berbeda.
- Pelanggan memiliki hubungan yg bervariasi dgn pemasok.
- Pelanggan juga kadang-kadang bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk menyelesaikan suatu proyek tepat waktu & sesuai anggaran.

@ Resiko definisi proses
Bila kualitas merupakan sebuah konsep yg disetujui sbg hal yg penting tetapi tidak tidak ada yg berintdak untuk mencapainya dengan cara yg dapat yg dilakukan, maka proyek tersebut beresiko.

Komponen Risiko dan Driver
Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu menghendaki agar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen risiko PL – kinerja, biaya, dukungan dan  jadwal.
Komponen risiko didefinisikan dgn cara sbb :
·         Risiko kinerja – tingakat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya.
·         Risiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga
·         Risiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan.
·         Risiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.

PROYEKSI RISIKO / PERKIRAAN RISIKO
Dua cara melakukan proyeksi risiko :
1. Probabilitas di mana risiko adalah nyata
2. Konsekuensi masalah yang berhubungan dengan risiko

Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan pengaruh risiko pada proyek dan produk
4. Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada
    kesalahpahaman

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



PENGURANGAN, MONITORING dan MANAJEMEN RISIKO
Aktifitas analisis risiko mempunyai titik tunggal yg memiliki tujuan untuk membantu tim proyek dalam mengembangkan strategi yg berkaitan dengan risiko.
Strategi yg efektif harus :
1. Menghindari risiko
2. Memonitoring risiko
3. Manajemen risiko dan perencanaan kemungkinan

Langkah-langkah untuk mengurangi turnover staf adalah
1. Temui staf yg ada, untuk menentukan penyebab keluar
2. Bertindaklah untuk mengurangi penyebab-penyebab yg ada di bawah kontrol
    manajemen sebelum proyek dimulai
3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-teknik
    untuk memastikan kontiunitas pada saat orang keluar
4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing aktivitas
    pengembangan dapat disebarluaskan
5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa   
    dokumen dikembangkan tepat waktu
6. Lakukan kajian antar teman terhadap semua pekerjaan tersebut sehingga lebih dari satu 
     orang yang terbiasa dengan pekerjaan itu
7. Tentukan backup anggota staf untuk setiap teknologi kritis










BAB VIII
JAMINAN KUALITAS PERANGKAT LUNAK

l  Jaminan kualitas perangkat lunak  adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak.
l  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
l  Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus pengembangan untuk memastikan bahwa setiap produk memenuhi persyaratan yang ditetapkan.
l  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.
l  Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan.


JAMINAN KUALAITAS
l  Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen.
l  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
l  Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan aktivitas.
l  Biaya kualitas dapat dibagi ke dalam biaya-biaya yang dihubungkan dengan :
¡  pencegahan
¡  penilaian
¡  kegagalan.


DEFINISI KUALITAS PL
l  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.
l  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).

KAJIAN PERANGKAT LUNAK
l  Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting.
l  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.
l  Kajian perangkat lunak berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean.



BAB IX
PENGUJIAN PERANGKAT LUNAK

Dasar-dasar Pengujian PL
         Pengujian menyajikan anomali yang menarik bagi perekayasa PL.
         Pada proses rekayasa PL, perekayasa pertama-tama berusaha membangun PL dari konsep abstrak ke implementasi yang dapat dilihat, baru kemudian dilakukan pengujian.
         Perekayasa menciptkan sederetan test-case yang dimaksudkan untuk membongkar PL yang sudah dibangun.
         Pada dasarnya,  pengujian merupakan satu langkah dalam proses rekayasa PL yang dapat dianggap (secara psikologis) sebagai hal yang destruktif daripada konstruktif.
         Haruskah pengujian peninggalkan rasa bersalah pada pengembang PL?
         Apakah pengujian benar-benar bersifat merusak?

Jawaban untuk 2 pertanyaan tersebut adalah “TIDAK”.


SASARAN PENGUJIAN
         Glen Myers tahun 79, menyatakan sejumlah aturan yang berfungsi sebagai sasaran pengujian:

1.      Pengujian adalah proses eksekusi suatu program dengan maksud menemukan kesalahan.
2.      Test-case yang baik adalah test-case yang memiliki probabilitas untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.
3.      Pengujian yang sukses adalah pengujian yang mengungkap semua kesalahan yang belum pernah ditemukan sebelumnya.

         Sasaran Pengujian tersebut mengimplikasikan adanya perubahan titik pandang yang dramatis.
         Sasaran berlawanan dengan pandangan yang biasanya dipegang: bahwa pengujian yang berhasil adalah adalah pengujian yang tidak ada kesalahan yang ditemukan.
         Sasaran kita adalah mendisain pengujian yang secara sistematis mengungkap kelas kesalahan yang berbeda dan melakukannya dengan jumlah waktu dan usaha minimum.
         Bila pengujian dilakukan secara sukses (sesuai dengan sasaran), maka akan ditemukan kesalahan di dalam perangkat lunak.
         Sebagai keuntungan sekunder, pengujian menunjukkan bahwa fungsi perangkat lunak bekerja sesuai dengan spesifikasi dan bahwa persyaratan kinerja telah dipenuhi.
         Sebagai tambahan, data yang dikumpulkan pada saat pengujian dilakukan, memberikan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa menunjukkan kualitas perangkat lunak secara keseluruhan.


Prinsip Pengujian
         Sebelum mengaplikasikan metode untuk mendisain test-case yang efektif, perekayasa PL harus memahami prinsip dasar yang menuntun pengujian PL.
         Davis, tahun 1995, mengusulkan serangkaian prinsip pengujian yang telah diadaptasi untuk digunakan pada kuliah ini, yaitu:

Semua pengujian harus dapat ditelusuri sampai kepersyaratan pelanggan.

         Sebagaimana telah diketahui, sasaran pengujian PL adalah untuk mengungkap kesalahan.

         Hal ini memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan) adalah cacat yang menyebabkan program gagal memenuhi persyaratannya.

Pengujian harus direncanakan lama sebelum pengujian itu mulai.

         Perencanaan pengujian dapat mulai segera setelah model persyaratan dilengkapi.
         Definisi detil mengenai test-case dapat dimulai segera setelah model disain diteguhkan. Dengan demikian semua pengujian dapat direncanakan dan dirancang sebelum semua kode dibangkitkan.

Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar.

         Pengujian pertama yang direncanakan dan dieksekusi biasanya berfokus pada modul program individual.
         Selagi pengujian berlangsung maju, pengujian mengubah fokus dalam usaha menemukan kesalahan pada cluster model yang terintegrasi, dan akhirnya pada sistem secara keseluruhan.

Pengujian yang mendalam tidaklah mungkin.

         Jumlah jalur permutasi untuk program yang berukuran menengahpun sangat besar. Karena itulah maka tidak mungkin mengeksekusi setiap kombinasi jalur skema pengujian.
         Tetapi dimungkinkan untuk secara adekuat mencakup logika program dan memastikan bahwa semua kondisi dalam disain prosedural telah diuji.
         Pengujian perangkat lunak merupakan    
        proses eksekusi suatu program dengan maksud menemukan kesalahan
        elemen kritis dalam jaminan kualitas perangkat lunak
        aktifitas yang mempresentasikan kajian pokok dari spesifikasi, disain dan pengkodean




Semoga dengan postingan diatas yang berjudul Makalah Uji Kualitas Rekayasa Perangkat Lunak dapat bermanfaat untuk sobatku semuanya, dan apabila berkenan cobalah untuk share buat temannya di facebook ataupun media social lainnya.

0 Response to "Makalah Uji Kualitas Rekayasa Perangkat Lunak"

Post a Comment