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