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 memperlihatkan pengembangan sistem berbasis komputer tehnik engineering. Untuk hardware komputer telah sedemikian maju dan relatif jenuh. Sebaliknya software komputer mulai berkembang, dan dikala 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 ialah sekumpulan elemen yang saling berinteraksi untuk mencapai suatu tujuan. Sedangkan Computer Based System diorganisir untuk mendapat beberapa metode, mekanisme atau pengontrolan dengan cara mengelola informasi.
Elemen-elemen dari sistem berbasis komputer ialah :
1. Software
Program komputer, struktur data dan dokumentasi yang saling berafiliasi dan memperlihatkan imbas pada metode, mekanisme dan kontrol yang diinginkan.
2. Hardware
Peralatan elektronik, (misalnya CPU, memory) yang memperlihatkan kemampuan komputasi serta peralatan elektromedia (misalnya sensor, motor, pompa) yang memperlihatkan fungsi external.
3. People / Brainware
User dan operator dari hardware dan software
4. Database
Sekumpulan informasi yang besar, yang diorganisir biar sanggup diakses oleh software dan merupakan bagianintegral dari fungsi sistem.
5. Prosedur
Computer system engineering ialah suatu aktifitas pemecahan problem 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 sanggup 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 melaksanakan pekerjaan aritmatik, logika, dan fungsi pengontrol serta berinteraksi dengan komponen lainnya. Sekarang ini, beberapa arsitektur komputer ditambahkan ko-prosesor untuk melaksanakan fungsi pengolahan khusus ( fungsi kalkulasi ) sehingga performance CPU sanggup 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 memperlihatkan kawasan penyimpanan isyarat dan data yang sanggup diakses pribadi / tidak pribadi melalui perintah yang dihukum 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 penggalan yaitu :
i. RAM - Random Access Memory
Untuk menyimpan data / isyarat 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 sanggup ditulis / diprogram dan sanggup 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 dikala dibentuk oleh pabriknya.
B. Memory Sekunder
Sifat yang menonjol dari memory jenis ini ialah :
i. Waktu saluran lambat
ii. Kapasitas besar sekali dibandingkan dengan memory primer
iii. Waktu saluran berkisar milidetik dengan kapasitas antara 400.000 hingga 1 billion byte
iv. Contoh : Floppy disk, harddisk, hardcard, optical disk
APLIKASI HARDWARE
Dapat dikelompokan dalam 3 penggalan 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 / setelah analisis dan definisi dijalankan, fungsi dialokasikan ke hardware.
Definisi sistem merupakan langkah pertama dalam fase perencanaan.
Tujuan dari definisi sistem ini ialah :
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 ialah 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 ialah :
Langkah kedua dalam fase perencanaan, tetapi merupakan langkah pertama dalam proses rekayasa software yang akan memperlihatkan 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 perihal 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 setelah 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 administrasi insan (People Management Capability Manurity Model ( PM – CMM ) ) untuk mempertinggi kesiapan organisasi PL dalam membuat aplikasi yang semakin kompleks sehingga menarik, menumbuhkan, memotivasi, mengembangkan dan memelihara talenta yang dibutuhkan untuk mengembangkan kemapuan mengembankan PL mereka.
Model kematangan administrasi insan 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 memilih informasi bisnis yang mempengaruhi dalam proyek
- Manajer Proyek merencanakan, memotivasi, mengorganisir, mengontrol
aplikasi/produk
- Pelaksana mempunyai ketrampilan teknik untuk merekayasa aplikasi
- Pelanggan memilih jenis kebutuhan bagi PL yang akan dibuat
- Pemakai simpulan yang berinteraksi dengan PL yang dibuat
b. Team Leader (Pimpinana Tim)
Manajemen proyek merupakan kegiatan insan intensif sehingga memerlukan praktisi yang cakap.
Model Kepemimpinan (MOI yaitu Motivasi, Organisasi, gagasan & Inovasi) berdasarkan Jerry Weinberg.
Karakteristik yang memilih manajer proyek efektif yaitu
- Pemecahan Masalah - Prestasi
- Identitas manajerial - Pengaruh & pembentukan tim
c. The Software Team ( Tim PL)
Sumber daya insan kepada sebuah proyek yang akan membutuhkan n insan yang bekerja selama k tahun , ada beberapa alternatif untuk memilih sumber daya.
Mantei, mengusulkan 3 organisasi tim yaitu:
· Demokrasi terdesentralisasi (DD)
Tidak mempunyai pimpinan permanen dan koordinator dipilih untuk kiprah pendek bila kiprah berbeda maka pimpinan berbeda. Keputusan diambil oleh konsensus kelompok dan
komunikasi secara horizontal
· Terkontrol terdesentralisasi (CD)
Tim mempunyai pimpinan tertentu dan mempunyai pimpinan skunder untuk sub-sub masalah. Pemecahan problem 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 acara yang dihasilkan (LOC / function)
3. Waktu tim (umur)
4. Tingkat dimana sanggup 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 ( ibarat tim CC) tetapi kurang inovatif
2. Paradigma Random
Membentuk tim longgar & tergantung pada inisiatif individual tim, untuk penemuan
sangat baik(unggul) bila unjuk kerja tim teratur.
3. Paradigma Terbuka
Membentuk tim dengan cara tertentu sehingga banyak kontrol, penemuan banyak . Cocok
untuk problem yang kompleks tetapi tidak seefesien tim lainnya
4. Paradigma Sinkron
Mengorganisasikan tim untuk bekerja pada bagian-bagian kecil problem 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 mengembangkan informasi & pemecahan problem serta pengembangan staf
· Komunikasi teknik, surat elektronis, web sites, teleconferens, papan buletin elektronik
· Jaringan interpersonal diskusi informal pada orang diluar proyek untuk mendapat pengalaman sehinnga mendukung kerja proyek
BAB IV
PROSES PL DAN METRIK PROYEK
PROBLEM / PRODUCT
Analisis yang mendetail mengenai kebutuhan PL akan memperlihatkan informasi untuk menghitung asumsi kuantitatif & perencanaan organisasi. Tetapi itu sulit alasannya informasi yang diberikan customer tidak lengkap.
Ruang lingkup problem dibatasi dengan :
· Konteks
PL yang dibangun memenuhi sistem, produk / konteks bisnis yang lebih besar serta batasan yang memilih hasilnya
· Tujuan informasi
Objek pelanggan yang dihasilkan sbg output dr PL yang sanggup 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 problem diterapkan pada :
- Fungsionalitas yang disampaikan
- Proses yang dipakai
PROCESS
Proses PL memperlihatkan suatu kerangka kerja dimana planning komprehensip bagi pengembangan PL yang sanggup dibangun dengan sejumlah kumpulan kiprah yang berbeda, kemampuanpenyampaian & jaminan kualitas
· Aktifitas pelindung, jaminan kualitas PL, administrasi 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 digunakan untuk memanipulasi data (gabungan dengan huruf spiral)
7. Perkembangan Komponen
Sering digunakan 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 dikala mendiskusikan proyek PL yang sukar maka 90 % dr sistem yang pertama menyerap 90 % dari perjuangan & waktu yang diberikan. 10 %terakhir mengambil 90 % lain dari perjuangan & waktu yang diberikan.
Dr penyataan tersebut proyek mengalami kesulitan yaitu
1. Kemajuan mengalami kecacatan
2. Tidak ada cara untuk mengkalibrasi kemajuan alasannya tidak memperoleh matrik
kuantitatif
3. Rencana proyek belum dirancang untuk menakomodasi sumber daya yang diharapkan pada simpulan sebuah proyek
4. Resiko-resiko belum mempertimbangkan secara eksplisit serta belum dibentuk planning untuk mengurangi, mengatur & memonitor
5. Jadual yang ada tidak realistis & cacat
Untuk mengatasi problem tersebut maka diharapkan waktu pada awal proyek untuk membangun planning yang realistis guna memonitor planning proyek selama berjalan & pada keseluruhan proyek serta mengontrol kualitas serta perubahannya.
BAB V
PERENCANAAN PROYEK PERANGKAT LUNAK
Proses administrasi proyek perangkat lunak dimulai dengan kegiatan project planning (perencanaan proyek). Yang pertama dari aktifitas ini ialah 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 sanggup 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 memperlihatkan awalan yang lebih detail pada dikala 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 undangan kerja ini?
- Siapa yang akan menggunakan solusi ini?
- Apakah laba ekonomi dari solusi yang sukses?
- Adakah sumber daya lain bagi solusi ini?
* Pertanyaan yang memungkinkan analis memahami problem lebih baik dan
pelanggan menyuarakan persepsi perihal 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 informasi 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 perjuangan sanggup dilakukan dengan cara :
1. Menunda estimasi hingga simpulan proyek.
2. Berdasarkan estimasi pada proyek yg ibarat sebelumnya.
3. Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan perjuangan
proyek.
4. Menggunakan satu atau lebih model empiris bagi estimasi perjuangan 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 planning proyek mencerminkan kemampuan tim PL.
4. Stabilitas syarat produk serta lingkungan yg mendukung perjuangan pengembangan PL.
Putnam dan Myers mengusulkan 4 problem 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, acara interaktif).
· Change sizing
Digunakan jikalau PL yang ada harus dimodifikasi dengan banyak cara sebagai penggalan 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 perjuangan pengembangan PL (dan biaya) sbg fungsi dari ukuran acara yg diekspresikan dalam baris kode yg diestimasi (LOC).
2. Model COCOMO Intermediate
Menghitung perjuangan pengembangan PL sbg fungsi ukuran acara 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 efek 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 dibentuk atau dikembangkan lebih simpel dengan aplikasi kerja yg baik. Misal acara analisis termal yang dikembangkan untuk kelompok transfer panas.
2. Model Semi Detached
Ukuran proyek dan kekompleksan perangkat cukup besar dengan pengalaman kerja adonan (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 sanggup 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 sanggup dibeli (atau lisensi) off-the-self.
2. Komponen PL full-experience dan partial-experience, sanggup diperoleh dankemudian
dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.
3. PL sanggup dibentuk custom-built oleh kontraktor luar untuk memenuhi spesifikasi
pembeli.
Untuk produk PL yang mahal, langkah-langkah di bawah ini sanggup 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 sanggup membantu konstruksi aplikasi yg
diperlukan.
4. Kembnagkan sebuah matriks perbandingan untuk membandingkan calon PL.
5. Evaluasi masing-masing paket PL berdasarkan kualitas produk sebelumnya, pinjaman
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 sanggup 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 sanggup 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 berafiliasi dengan insiden 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 problem yang bahwasanya / penting.
Strategi proaktif dimulai sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas & efek proyek diperkirakan, dan diprioritaskan berdasarkan kepentingan, kemudian membangun suatu planning untuk administrasi resiko.
Sasaran utama ialah 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 sanggup diramalkan
· Resiko yang tidak diharapkan
@ Resiko proyek
Resiko proyek mengancam planning 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) - problem 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
- problem 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 bahwasanya tdk pernah diinginkan oleh setiap
orang (resiko pasar)
2. pembangunan sebuah produk yg tidak sesuai dgn keseluruhan seni administrasi bisnis bagi
perusahaan (resiko strategi)
3. Pembangunan sebuah produk dimana sebuah penggalan pemasaran tidak tahu bagaimana
harus menjualnya.
4. Kehilangan pinjaman administrasi senior sehubungan dg perubahan pd fokus atau
perubahan pd insan (resiko manajemen)
5. Kehilangan hal2 yg berafiliasi dgn biaya atau akad personal (resiko biaya).
@ Resiko yg sudah diketahui
adalah resiko yg dpt diungkap setelah dilakukan penilaian secara hati2 terhadap planning proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya. ibarat :
- tgl penyampaian yg tdk realitas
- kurangnya persyaratan yg terdokumentasi
- kurangnya ruag lingkup PL
- lingkungan pengembangan yg buruk
@ Resiko yg sanggup diramalkan
diekstrapolasi dari pengalaman proyek sebelumnya. Misalnya :
- pergantian staf
- komunikasi yg jelek dgn para pelanggan
- mengurangi perjuangan staff bila undangan pemeliharaan
sedang berlangsung dilayani
@ Resiko yg tidak diharapkan
resiko ini sanggup benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.
Identifikasi Resiko
Identifikasi resiko dalah perjuangan sistematis untuk memilih ancaman terhadap planning proyek. Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap dikala diperlukan.
Tipe resiko :
1. resiko generik merupakan ancaman potensial pd setiap proyek PL.
2. resiko produk spesifik hanya sanggup diidentifikasi dgn pemahaman khusus mengenai
teknologi, manusia, serta lingkungan yg spesifik terhadap proyek yg ada.
Metode untuk mengidentifikasi resiko ialah 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 berafiliasi dgn ukuran dan pengalaman staf
Bila persentasie deviasi besar atau deviasinya sama, tetapi hasil yg kemudian sangat kurang dari yg diharapkan, maka resikonya tinggi.
@ Resiko yg mempengaruhi bisnis
Resiko yg berafiliasi dengan batasan yg dibebankan oleh administrasi atau pasar.
Bagian pemasaran dikendalikan oleh pertimbangan bisnis, dan pertimbangan bisnis kadang mengalami konflik pribadi dengan kenyataan teknis.
@ Resiko yg dihubungkan dgn karakteristik pelanggan
Resiko yg berafiliasi dengan kepintaran pelanggan & kemampuan pengembang untuk berkomunikasi dgn pelanggan dgn cara yg cepat.
Karakteristik pelanggan :
- Pelanggan mempunyai impian yg berbeda.
- Pelanggan mempunyai kepribadian yg berbeda.
- Pelanggan mempunyai korelasi yg bervariasi dgn pemasok.
- Pelanggan juga adakala bertentangan.
Karakteristik pelanggan mempengaruhi kemampuan tim PL untuk menuntaskan 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 sanggup yg dilakukan, maka proyek tersebut beresiko.
Komponen Risiko dan Driver
Pedoman untuk mengidentifikasi risiko PL dan pengurangannya yaitu menghendaki biar manajer proyek mengidentifikasi risiko driver yg mempengaruhi komponen risiko PL – kinerja, biaya, pinjaman 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 pinjaman – tingkat ketidakpastian dimana PL akan gampang 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 melaksanakan proyeksi risiko :
1. Probabilitas di mana risiko ialah nyata
2. Konsekuensi problem yang berafiliasi dengan risiko
Perencanaan proyek bersama dengan manajer & staf teknik melaksanakan 4 aktifitas proyeksi risiko :
1. Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan
2. Menggambar konsekuensi risiko
3. Memperkirakan efek 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 jikalau suatu risiko
benar-benar terjadi :
1. Sifatnya ; risiko yang memperlihatkan problem yg muncul bila ia terjadi
2. Ruang lingkupnya; menggabungkan kepelikannya (seberapa seriusnya problem ini ? )
dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi atau berapa
banyak pelanggan terganggu ? )
3. Timingnya; mempertimbangkan kapan dan untuk berapa lama efek itu dirasakan.
PENGURANGAN, MONITORING dan MANAJEMEN RISIKO
Aktifitas analisis risiko mempunyai titik tunggal yg mempunyai tujuan untuk membantu tim proyek dalam mengembangkan seni administrasi 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 memilih penyebab keluar
2. Bertindaklah untuk mengurangi penyebab-penyebab yg ada di bawah kontrol
administrasi sebelum proyek dimulai
3. Bila proyek dimulai asumsikan turnover akan terjadi dan kembangkan teknik-teknik
untuk memastikan kontiunitas pada dikala orang keluar
4. Kumpulkan tim proyek sehingga informasi mengenai masing-masing kegiatan
pengembangan sanggup disebarluaskan
5. Tentukan standar dokumentasi dan buat mekanisme untuk memastikan bahwa
dokumen dikembangkan tepat waktu
6. Lakukan kajian antar sahabat 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 kegiatan pelindung yang diaplikasikan pada seluruh proses perangkat lunak.
l SQA meliputi :
¡ pendekatan administrasi 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 ialah bahwa semua produk kerja mempunyai spesifikasi yang telah ditentukan dan sanggup diukur dimana kita sanggup 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 ialah :
untuk memperlihatkan data yang diharapkan oleh administrasi untuk menginformasikan problem kualitas produk, sehingga sanggup memperlihatkan kepastian & konfidensi bahwa kulitas produk sanggup memenuhi sasaran.
BIAYA KUALITAS
l Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berafiliasi dengan aktivitas.
l Biaya kualitas sanggup 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 memutuskan 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 kegiatan SQA yang terpenting.
l Kajian perangkat lunak ialah suatu filter bagi proses rekayasa perangkat lunak, yaitu kajian yg diterapkan pd banyak sekali 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 sanggup dilihat, gres 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 sanggup 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 ialah “TIDAK”.
SASARAN PENGUJIAN
• Glen Myers tahun 79, menyatakan sejumlah aturan yang berfungsi sebagai target pengujian:
1. Pengujian ialah proses sanksi suatu acara dengan maksud menemukan kesalahan.
2. Test-case yang baik ialah test-case yang mempunyai probabilitas untuk menemukan kesalahan yang belum pernah ditemukan sebelumnya.
3. Pengujian yang sukses ialah 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 ialah adalah pengujian yang tidak ada kesalahan yang ditemukan.
• Sasaran kita ialah mendisain pengujian yang secara sistematis mengungkap kelas kesalahan yang berbeda dan melakukannya dengan jumlah waktu dan perjuangan minimum.
• Bila pengujian dilakukan secara sukses (sesuai dengan sasaran), maka akan ditemukan kesalahan di dalam perangkat lunak.
• Sebagai laba sekunder, pengujian memperlihatkan bahwa fungsi perangkat lunak bekerja sesuai dengan spesifikasi dan bahwa persyaratan kinerja telah dipenuhi.
• Sebagai tambahan, data yang dikumpulkan pada dikala pengujian dilakukan, memperlihatkan indikasi yang baik mengenai reliabilitas perangkat lunak dan beberapa memperlihatkan 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 disesuaikan untuk digunakan pada kuliah ini, yaitu:
Semua pengujian harus sanggup ditelusuri hingga kepersyaratan pelanggan.
• Sebagaimana telah diketahui, target pengujian PL ialah untuk mengungkap kesalahan.
• Hal ini memenuhi kriteria bahwa cacat yang paling fatal (dari titik pandang pelanggan) ialah cacat yang mengakibatkan acara gagal memenuhi persyaratannya.
Pengujian harus direncanakan lama sebelum pengujian itu mulai.
• Perencanaan pengujian sanggup mulai segera setelah model persyaratan dilengkapi.
• Definisi detil mengenai test-case sanggup dimulai segera setelah model disain diteguhkan. Dengan demikian semua pengujian sanggup direncanakan dan dirancang sebelum semua kode dibangkitkan.
Pengujian harus mulai dari yang kecil dan berkembang ke pengujian yang besar.
• Pengujian pertama yang direncanakan dan dihukum biasanya berfokus pada modul acara individual.
• Selagi pengujian berlangsung maju, pengujian mengubah fokus dalam perjuangan menemukan kesalahan pada cluster model yang terintegrasi, dan alhasil pada sistem secara keseluruhan.
Pengujian yang mendalam tidaklah mungkin.
• Jumlah jalur permutasi untuk acara yang berukuran menengahpun sangat besar. Karena itulah maka mustahil mengeksekusi setiap kombinasi jalur denah pengujian.
• Tetapi dimungkinkan untuk secara adekuat meliputi kebijaksanaan acara dan memastikan bahwa semua kondisi dalam disain prosedural telah diuji.
• Pengujian perangkat lunak merupakan
– proses sanksi suatu acara 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 sanggup 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"
Posting Komentar