SOFTWARE ENGINEERING

Ilmu yang mempelajari tehnik pembuatan software yang baik dengan pendekatan tehnik (Engineering approach)

Ada beberapa cara / fase

1. Fase Perencanaan

2. Fase Pengembangan

3. Fase Pemeliharaan

Tantangan ?

à mengembangkan hardware komputer yang dapat mengurangi biaya pengolahan dan penyimpanan data

à mengurangi biaya dan memperbaiki kualitas solusi berbasis komputer

Solusi ?

à Soft. merupakan faktor kunci dlm keberhasilan suatu usaha, soft. dpt membedakan satu perusahaan dari perusahan saingannya

Tahun-tahun awal :

- Batch orientation

- Limmited distribution

- Custummer software

Era ke-2 : Era ke-3 :

- Multi user - Distibuted system

- Real time - Embedded intellegence

- Database - Low cost hardware -

- Consumer infact

Era ke-4 :

- Expert system

- A I Machine

- Parallel architecture

Arti Software ?

Instruksi Atau program komputer yang ketika dieksekusi akan memberi fungsi dan hasil yang diinginkan.

Struktur data Yang memungkinkan program memanipulasi informasi Dokumen Yang menggambarkan operasi dan penggunaan program.

Sifat & Karakteristik Software ?

Software merupakan elemen sistem logik dan bukan elemen sistem fisik seperti hardware

Ø Elemen itu tidak aus, tetapi bisa rusak.

Ø Elemen software itu direkayasa atau dikembangkan dan bukan dibuat di pabrik seperti hardware

Ø Software itu tidak bisa dirakit.

Komponen Software ?

Ø Bentuk Bahasa

Ø Bentuk Translator

Ø Bentuk Mesin :

Sistem Software

Real Time Software

Perlu dicatat bahwa istilah real time berbeda dari istilah interactive atau time sharing. Sistem real time harus memberikan respons pada waktu yang ditentukan, sedangkan pada sistem interactive atau time sharing respons time biasanya melebihi batas waktu yang ditentukan tanpa merusak hasil.

Business Software

Ø Engineering and Sciencetific Sofware

Ø Emdebed Software

Ø PC Software

Ø Artificial Intelegent Software

Krisis Software ?

Masalah ?

Penyebab ?

Model Software Engineering

Fritz Badar (soft. yg ekonomis), terdiri dari 3 elemen :

1. Metode

2. Peralatan

3. Prosedur

Software engineering paradigma (ada 3) :

1. Classic Life Cycle Paradigma

2. Prototype Paradigma

Fourth Generation Technique Paradigma

Model Kombinasi

Sebuah Analogi

Gas Oksigen dapat dibuat oleh :

- Sebuah Laboratorium

- Industri Pabrik Gas

Perangkat lunak dapat dikembangkan oleh :

- Sekelompok programmer

- Sebuah organisasi yang mengembangkannya melalui rekayasa

Apa yang membedakan antara keduanya ?

Perbedaan SE & CS

Comp. Science terkait dgn teori-teori & dasar-dasar dari ilmu komputer, sedangkan software engineering terkait pada pengetahuan & penyerahan perangkat lunak yg berguna.

Teori-teori ilmu komputer biasanya tidak cukup digunakan sebagai pendukung yang lengkap dari software engineering.

Mengapa perlu Soft. Engineering

Masalahnya adalah kompleksitas, Banyak dibutuhkan sumber-sumber, tetapi kuncinya adalah ukuran (size) :

- UNIX berisi 4 juta lines of code

- Windows 2000 berisi 108 lines of code dikerjakan oleh Tim dengan 1400 orang

Soft. Engineering adalah bagaimana mengelola komplesitas tsb. dan dpt bekerja dalam satu Tim Work

Tahap-tahap Proses Pengembangan Soft

Bagaimana bekerja dalam suatu proyek skala besar, kompleks & melibatkan banyak orang ?

1. Spesifikasi Kebutuhan (requirement specification)

2. Analisis (anlysis)

3. Perancangan (design)

4. Implementasi & Pengujian (implementastion & testing)

5. Perawatan & Up-grade (maintenance & upgrade)

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

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

Team Leader (Pimpinan 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

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

Ø n orang mengerjakan tugas fungsional berbeda sebanyak m dengan sedikit kombinasi kerja & koordinasi tanggung jawab manajer proyek

Ø n orang mengerjakan tugas fungsional berbeda sebanyak m (m<n) , seorang pemimpin tim ad hoc dapat dipilih, koordinasi bertanggung jawab manajer PL

Ø n orang diatur di dalam tim , setiap orang mengerjakan >= 1 tugas fungsional, setiap tim mempunyai sebuah struktur spesifik yang ditentukan untuk semua tim yang bekerja pada sebuah proyek, koordinasi dikontrol oleh tim itu sendiri dan oleh manajer proyek PL (sistem ini paling produktif)

Mantei, mengusulkan 3 organisasi tim yaitu:

Ø Demokrasi terdesentralisasi (DD)

Ø Terkontrol terdesentralisasi (CD)

Ø Terkontrol tersentralisasi (CC)

7 faktor proyek yang harus dipertimbangkan dalam rencanakan :

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

2. Paradigma Random

3. PAradigma Terbuka

4. Paradigma Sinkron

Coordinatian & Communication Issue (masalah koordinasi & komunikasi)

Proyek PL mengalami kesulitan dikarenakan :

Ø Skala

Ø Ketidakpastiam

Ø Interoperabilitas

Ø Kraul & Streter menguji sekumpulan teknik koordinasi proyek yang dibagi atas :

· Pendekatan impersonal

· Prosedure interpersonal

· Komunikasi teknik

· Jaringan interpersonal

PRODUCT /PROBLEM : Software yang dikembangkan 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

Ø Tujuan Informasi

Ø Fungsi & Unjuk Kerja

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 : Suatu kerangka kerja dari suatu aktifitas dan kumpulan tugas untuk memgembangkan PL

Proses PL memberikan suatu kerangka kerja dimana rencana komprehensip bagi pengembangan PL yang dapat dibangun dengan

Sejumlah kumpulan tugas yang berbeda, kemampuan penyampaian & jaminan kualitas

Aktifitas pelindung, jaminan kualitas PL, manajemen konfigurasi PL & pengukuran

Model Proses :

Ø Sekunsial Linier

Ø Prototipe

Ø Rapid Aplication Development (RAD)

Ø Inkremental (Pertambahan)

Ø Spiral

Ø Rakitan Komponen

Ø Perkembangan Komponen

Ø Metode Formal

Ø Teknik Genersai Keempat

Ø Dekomposisi Proses

Bila batasan waktu yang ketat diberikan dan masalah dapat dipecah-pecah, model RAD mungkin pilihan yang paling tepat.

Tugas kerja yang actual bervariasi sehingga dekomposi proses dimulai pada saat bagaimana menyesesaikan kerja proses secara umum.

1,2 3 (konvensional) sisanya evolusioner

Harus ditentukan model paling banyak memawakili pelanggan, karakteristik produk & lingkungan proyek

Serangkaian aktifitas kerja PL :

1. Komunikasi pelanggan

2. Perencanaan

3. Analisa Resiko

4. Rekayasa

5. Konstruksi dan rilis

6. Evaluasi Pelanggan

PROJECT (tambahan) : Penggabungan semua kerja untuk membuat produk menjadi kenyataan

Profesional industri sering mengacu pada aturan 90-90 yaitu pada saat mendiskusikan proyek PL yang sukar maka 90 % dr siste yang pertama menyerap 90 % dari usaha & waktu yang diberikan. 10 %terakhir mengambil 90 % lain dari usaha & waktu yang diberikan.

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

Manajer Pengukuran yang Baik

Software Measurement

Tim A menemukan 342 error dalam pengembangan

Tim B menemukan 184 error dalam pengembangan

Tim mana yang memiliki kinerja terbaik ?

Jawabnya:

Kita tidak dapat membandingkan antara buah apel dengan jeruk.

Jika pengukuran tidak dinormalisasi, maka dapat dibuat software metric yang memungkinkan perbandingan pengoraganisasian yang lebih luas.

Metrics

Ø Berorientasi pada ukuran (Size-oriented)

Ø Mempertimbangkan “ukuran” dari proyek

Ø Berorientasi pada Fungsi (Function-oriented)

Size-Oriented Metrics

Contoh size-oriented metrics

Project	LOC	FP	Effort (P/M)	R(000)	Pp. doc	Errors	Defects	People
alpha	12100	189	24	168	365	134	29	3
beta	27200	388	62	440	1224	321	86	5
gamma	20200	631	43	314	1050	256	64	6

Normalized metrics

Ø Errors per KLOC (000 lines of code)

Ø Defects per KLOC

Ø $ per LOC

Ø Pages of documentation per KLOC

Juga:

Ø Errors/person-month

Ø LOC per person-month

Ø $/page of documentation

Masalah pada Size-Oriented Metrics

Ø Belum diterima secara universal di dunia

Ø LOC tergantung pada bahasa pemrograman

Ø Perancangan yang baik dengan baris program lebih pendek akan dirugikan.

Ø LOC butuh dikalkulasi sebelum perancangan.

Function-Oriented Metrics

Menggunakan fungsionalitas dari aplikasi sebagai nilai normalisasi

Bagaimana kita mengukur fungsionalitas ?

Function points [Albrecht]

Didasarkan pada pengukuran terukur (langsung) dari domain informasi perangkat lunak dan pengkajian dari kompleksitas perangkat lunak.

PENGUKURAN PERANGKAT LUNAK SECARA LANGSUNG

Ø Biaya dan Usaha (Cost Effort) .

Ø Ukuran Produk (Product Size).

Ø Keandalan Produk (Product Performance).

Ø Kadar Kesalahan (Defect Rate).

PENGUKURAN PERANGKAT LUNAK SECARA TIDAK LANGSUNG

Ø Fungsinya (Functionality) .

Ø Kualitasnya (Quality).

Ø Kerumitannya (Complexity).

Ø Reliabilitasnya (Reliability).

Ø Perawatannya (Maintainability).

SOFTWARE METRICS

Ø Banyaknya baris program (Lines of Code - LOC).

Tergantung pada jenis bahasa pemrograman.

Ø Titik-titik Fungsi (Function Points - FP).

Tidak tergantung pada bahasa pemrograman.

Ø Lamanya Proses Pengujian (Elapsed Time in Hours)

Jumlah “Defects” selama proses pengujian (Counting Defects).

Jam kerja programmer (Man Hours/Months).

LINES OF CODE (LOC)

Pengukuran langsung metrik perangkat lunak yang paling sederhana (metric size oriented).

Asumsi:

Line of code berisi kesalahan (error) per LOC dengan peluang konstan p

Contoh:

Pemeriksa percaya bahwa line of code mengandung peluang kesalahan 2% (fault/LOC).

Jika modul yang diuji panjangnya adalah 100 baris maka kesalahan yang terjadi adalah :

Faults = p x LOC = 0,02 x 100 = 2

FUNCTION POINTS (FP)

Metrik perangkat lunak berorientasi pada fungsi (function-oriented) yang menggunakan pengukuran tidak langsung yaitu fungsionalitas dari aplikasi.

Dihitung dengan menggunakan sebuah hubungan empiris domain informasi dan perkiraan kompleksitasnya.

Function Points - Notepad

Contoh Soal:

Hitunglah nilai Function Points untuk suatu aplikasi dengan karakteristik domain informasi sebagai berikut:

Jumlah input pemakai = 3

Jumlah ouput pemakai = 2

Jumlah inquery pemakai = 2

Jumlah file = 1

Jumlah interface eksternal = 4

Jika kita anggap faktor penyesuaian komplesitas adalah 46 (produk yang agak kompleks), maka tentukan function point dari aplikasi ini .

Jawab

Faktor Pembobotan

Estimasi Rata-rata jumlah baris yang diperlukan untuk membangun satu FP dalam berbagai Bahasa Pemrograman

Bahasa Pemrograman	LOC/FP Rata-rata
Bahasa Assembly	320
C	128
Cobol	105
Fortran	105
Pascal	90
Ada	70
Bahasa Berorietasi Obyek	30
Bahasa Generasi Ke-empat (4GLs)	20
Spreadsheets	6
Bahasa Visual/Grafis (icon)	4

Contoh Statistik

Constructive Cost Model (COCOMO)

Model Biaya Konstruktif (COCOMO) adalah menghitung usaha dan waktu pengembangan perangkat lunak sebagai fungsi dari ukuran program yang diestimasi.

Usaha (person-month):

E = a (KLOC)b

KLOC = Kilo of Lines of Code

a, b = konstanta.

Development Time (months):

D = c (E)d

E = Effort (person-months)

c, d = konstanta.

Contoh Soal

Jika konstanta a=2,4 , b=1,05 , c=2,5 dan d=0,35 . Berapa Effort dan Development Time yang dibutuhkan untuk mengembangkan perangkat lunak dengan ukuran 33,2 KLOC.

Jawab

Usaha yang diperlukan:

E = a (KLOC)b

E = 2,4 (33,2)1,05 = 95 orang-bulan

Development Time (months):

D = c (E)d

D = 2,5 (95)0,35 = 12,3 bulan

Jumlah orang yang disetujui:

P = E/D

P = 95/12,3 = 8 orang

Atau perencanca dapat memutuskan menggunakan 4 orang saja dengan durasi proyek lebih lama.

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:

Hardware yg mengeksekusi PL dan device yg dikontrol secara tidak langsung oleh PL

Software yg sudah ada dan harus dihubungkan dengan PL yg baru

Manusia yg menggunakan PL melalui keyboard atau perangkat I/O lain

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), menggabungkan PL dan Perangkat Keras.

Estimasi biaya dan usaha dapat dilakukan dengan cara :

Menunda estimasi sampai akhir proyek.

Berdasarkan estimasi pada proyek yg mirip sebelumnya.

Menggunakan 'teknik dekomposisi' yg relatif sederhana u/ estimasi biaya dan usaha proyek.

Menggunakan satu atau lebih model empiris bagi estimasi usaha dan biaya PL.

Akurasi estimasi proyek PL didasarkan pada :

Tingkat dimana perencana telah dengan tepat mengestimasi ukuran produk yg akan dibuat.

Kemampuan mengestimasi ukuran ke dalam kerja manusia, waktu kalender, dan dolar.

Tingkat dimana rencana proyek mencerminkan kemampuan tim PL.

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.

Data baris kode (LOC) dan titik fungsi (FP) pada estimasi proyek digunakan sbg :

variabel estimasi yg dipakai untuk mengukur masing-masing elemen PL.

metrik baseline yg dikumpulkan dari proyek yg lalu dan dipakai dengan variabel estimasi untuk mengembangakan proyeksi kerja dan biaya.

Expected Value untuk variabel estimasi :

EV = (Sopt + 4Sm + Spess) / 6

EV = Expected value

Sopt = Estimasi optimistik

Sm = Estimasi paling sering

Spess = Estimasi pesimistik

Apakah estimasi ini benar ? ' Kita tidak yakin!'

Bagaimanapun canggih teknik estimasi harus di-cross-check dengan pendekatan lain.

Contoh estimasi berbasis LOC

PL CAD akan menerima data geometri dua dan tiga demensi dari seorang perekayasa yang akan berinteraksi dan mengontrol sistem CAD melalui suatu interface pemakai. Kajian spesifikasi sistem menunjukkan bahwa PL akan mengeksekusi Workstation dan harus berinteraksi dengan berbagai periperal grafis komputer spt mouse, digitizer dan printer laser.

Diketahui :

Perhitungan LOC untuk fungsi analisis geometri 3D (3DGA) :

optimis : 4600

most likely : 6900

pesimistik : 8600

EV = (4600 + 4*6900 + 8600) / 6

= 6800 LOC

Jumlah tersebut dimasukkan ke dalam tabel, begitu juga untuk perhitungan yang lain. Sehingga diperoleh :

Tabel perkiraan (estimasi) untuk metode LOC

Fungsi	LOC terestimasi
interface pemakai & fasilitas kontrol (UICF)	2.300
analisis geometrik dua demensi (2DGA)	5.300
analisis geometrik tiga demensi (3DGA)	6.800
manajemen databse (DBM)	3.350
fasilitas display grafis komputer (CGDF)	4.950
kontrol periperal (PC)	2.100
modul analisis desain (DAM)	8.400
baris kode terestimasi	33.200

Jika :

Produktifitas rata-rata organisasional = 620 LOC/person-month

Upah karyawan = $8.000 per bulan

Biaya per baris kode = $13

Maka : Tingkat produktifitas = jumlah titik fungsi

jumlah orang-bulan

Jumlah karyawan = 33200 LOC = 53,5 » 54 orang

620 LOC/bln

Estimasi biaya proyek berdasar LOC

= 33.200 LOC * $ 13

= $ 431.600

Estimasi biaya proyek berdasar upah

= 54 orang * $8.000

= $432.000

Estimasi berbasis FP (Function Point)

Dekomposisi untuk perhitungan berbasis FP berfokus pada harga domain info daripada fungsi PL. Perencana proyek memperkirakan input, output, inquiry, file dan interface eksternal. Untuk tujuan perkiraan tersebut faktor pembobotan kompleksitas diasumsikan menjadi rata-rata.

Setiap faktor pembobotan kompleksitas diestimasi dan faktor penyesuaian kompleksitas dihitung seperti dibawah ini :

Faktor Harga

Backup and recovery 4

Komunikasi data 2

Pemrosesan terdistribusi 0

Kinerja kritis 4

Lingkungan operasi yang ada 3

Entri data on-line 4

Transaksi input pada layar ganda 5

File master yang diperbarui on-line secara on-line 3

Nilai kompleks domain informasi 5

Pemrosesan internal yang kompleks 5

Kode yg didesain untuk dapat dipakai lagi 4

Konversi/instalasi dalam disain 3

Instalasi ganda 5

Aplikasi yg didesain bagi perubahan 5

Faktor penyesuaian kompleksitas 1.17

TOTAL 53.17

Perkiraan harga domain informasi :

Tabel perkiraan harga domain informasi

nilai domain informasi	opt	likely	pess	jumlah estimasi	bobot	jumlah FP
jumlah input	20	24	30	24	4	96
jumlah output	12	15	22	16	5	80
jumlah inquiry	16	22	28	22	4	88
jumlah file	4	4	5	4	10	40
jumlah interface eksternal	2	2	3	2	7	14
jumlah total						318

jumlah estimasi (lihat rumus EV)

bobot (lihat kembali bab 4)

jumlah FP = jumlah estimasi * bobot

Total faktor pembobotan = SFi = 53.17

Total FP = 318

FP terestimasi = jumlah total * ( 0.65 + 0.01 * SFi)

= 318 * ( 0.65 + 0.01 * 53.17 )

= 375

Diketahui :

Produktifitas = 6.5 LOC/pm (dari historis)

Upah = $ 8.000/m

Biaya FP = $ 8.000 = $ 1.230

65 LOC

Estimasi biaya proyek

= Biaya FP * FP terestimasi

= $ 1.230 * 375

= $ 461.250

Usaha terestimasi

= Total biaya = $ 461.250 = 58 p/m

upah/p $ 8.000

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.

Pesamaan COCOMO Dasar

E = ab (KLOC)

D = cb E

Dimana :

E = Effort (usaha yang diaplikasikan - pm)

D = waktu pengembangan (m)

KLOC = jumlah perkiraan baris kode (dalam ribuan)

ab, bb, cb, db = koefisien (lihat tabel)

Tabel Model COCOMO Dasar

Proyek PL	ab	bb	cb	db
organik	2.4	1.05	2.5	0.38
semi-detached	3.0	1.12	2.5	0.35
embedded	3.6	1.20	2.5	0.32

Model 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

Masing-masing dari 15 atribut di atas dirata-rata dlm sebuah skala 6 titik dg rentang dari 'sangat rendah' ke 'sangat tinggi' (dlm kepentingan atau harga).

Persamaan COCOMO Intermediate

E = ai (KLOC) * EAF

dimana :

EAF = Effort Adjusment Factor (faktor penyesuaian usaha)

yg mempunyai range antara 0.9 sampai 1.4

ai, bi = koefisien (lihat tabel)

Tabel Model COCOMO Intermediate

Proyek PL	ai	bi
organik	3.2	1.05
semi-detached	3.0	1.12
embedded	2.8	1.20

Contoh estimasi model COCOMO

Kita aplikasikan model dasar pada contoh PL CAD sebelumnya dengan koefisien seperti pada tabel

E = ab (KLOC)

E = 2.4 (KLOC)1.05

= 2.4 (33.2)1.05

= 95 pm

Harga ini jauh lebih tinggi dibanding estimasi sebelumnya karena model COCOMO mengasumsikan tingkat LOC/pm yang jauh lebih rendah.

Untuk menghitung durasi proyek :

D = cb E

D = 2.5 (E)0.38

= 2.5 (95)0.38

= 12.3 bulan

Harga durasi proyek memungkinkan perencana untuk menentukan jumlah orang yang disetujui (N)

N = E/D

= 95/12.3

= 7,7 » 8 orang

Kenyataannya, perencana dapat memutuskan hanya menggunakan 4 orang saja dan pemperpanjang durasi proyek.

Catatan : Hubungan antara usaha dan waktu tidak linier.

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 :

PL dapat dibeli (atau lisensi) off-the-self.

Komponen PL full-experience dan partial-experience, dapat diperoleh dan kemudian dimodifikasi dan integrasi untuk memenuhi kebutuhan sendiri.

PL dapat dibuat custom-built oleh kontraktor luar untuk memenuhi spesifikasi pembeli.

Untuk produk PL yang mahal, langkah-langkah di bawah ini dapat dipetimbangkan:

Kembangkan spesifikasi untuk fungsi dan kinerja PL yg diperlukan.

Perkirakan biaya internal untuk pengembangan dan tanggal penyampaian.

3a. Pilih tiga atau empat calon aplikasi yang paling cocok dengan aplikasi anda.

3b. 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:

Ø Tanggal penyampaian

Ø Biaya yang diperlukan

Ø Dukungan

MEMBUAT POHON KEPUTUSAN

Rekayasa atau organisasi PL dapat menggunakan teknik statistik analisis pohon keputusan dengan pilihan :

membangun sistem X dari permulaan

menggunakan lagi komponen partial experience yang ada untuk membangun sistem

membeli sebuah produk perangkat lunak yang dapat diperoleh dan dimodifikasi untuk memenuhi kebutuhan lokal

mengkontrakkan pengembangan PL ke vendor luar

Bila sistem dibangun dari permulaan, hanya 70% probabilitasnya sehingga pekerjaan menjadi sulit. Perencana proyek dapat memproyeksikan usaha pengembangan yang sulit berbiaya $450.000, usaha yang sederhana diperkirakan berbiaya $380.000.

Expected value untuk biaya dihitung sepanjang cabang pohon keputusan, adalah :

Expected Cost = S (jalur probabilitas)i * (biaya jalur terestimasi)i

dimana i adalah garis edar pohon keputusan.

Contoh :

expected costbuild = 0.30 ($380 K) + 0.70 ($450 K) = $ 429 K

expected costreuse = 0.40 ($275 K) + 0.60 (0.20 ($310 K) + 0.80 ($490 K))

= $ 382 K

expected costbuy = 0.70 ($210 K) + 0.30 ($400 K) = $ 267 K

expected costcontract = 0.60 ($350 K) + 0.40 ($500 K) = $ 410 K

Berdasar biaya probabilitas dan proyeksi, expected cost yang paling rendah adalah pilihan buy

Catatan : Banyak kriteria yang harus dipertimbangakan, bukan hanya biaya, seperti pengalaman pengembang/ vendor/ kontraktor, penyesuaian kebutuhan,kecenderungan perubahan dapat mempengaruhi keputusan akhir!

MANAJEMEN RISIKO

Defenisi konseptual mengenai risiko : (Robert Charette)

Risiko berhubungan dengan kejadian di masa yg akan datang.

Risiko melibatkan perubahan (spt. perubahan pikiran, pendapat, aksi, atau tempat)

Risiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan.

STRATEGI 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 risiko :

Ø Ketidakpastian

Ø Kerugian

Ø Kategori risiko :

Ø Risiko proyek

Ø Risiko teknis

Ø Risiko bisnis

Kategori risiko oleh Robert Charette :

Ø Risiko yang sudah diketahui

Ø Risiko yang dapat diramalkan

Ø Risiko yang tidak diharapkan

RISIKO PROYEK

Risiko proyek mengancam rencana proyek.

Bila risiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami slip & biaya menjadi bertambah.

Risiko proyek mengidenifikasi :

- biaya - sumber daya

- jadwal - pelanggan

- personil (staffing & organisasi) - masalah persyaratan

RISIKO TEKNIS

Risiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan. Bila resiko teknis menjadi kenyataan maka implementasinya menjadi sangat sulit atau tidak mungkin.

Risiko teknis mengidentifikasi :

- desain potensial - ambiquitas

- implementasi - spesifikasi

- interfacing - ketidakpastian teknik

- verivikasi - keusangan teknik

- masalah pemeliharaan

- teknologi yg leading edge

RISIKO BISNIS

Risiko bisnis mengancam viabilitas PL yg akan dibangun.

Risiko bisnis membahayakan proyek atau produk.

5 RISIKO BISNIS UTAMA

Ø Risiko Pasar

Ø Risiko Strategi

Ø Risiko Pemasaran

Ø Risiko Manajemen

Ø Risiko Biaya

RISIKO YG SUDAH DIKETAHUI

adalah risiko 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

RISIKO 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

RISIKO YG TIDAK DIHARAPKAN

risiko ini dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.

IDENTIFIKASI RISIKO

Identifikasi resiko dalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek.

Tujuan identifikasi risiko :

untuk menghindari resiko bilamana mungkin, serta menghindarinya setiap saat diperlukan.

Tipe risiko :

Ø risiko generik

merupakan ancaman potensial pd setiap proyek PL.

Ø risiko 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 risiko.

Kategori checklist item risiko :

Ø risiko ukuran produk

Ø risiko yg mempengaruhi bisnis

Ø risiko yg dihubungkan dgn karakteristik pelanggan

risiko definisi proses

Ø risiko teknologi yang akan dibangun

Ø risiko lingkungan pengembangan

Ø risiko yg berhubungan dgn ukuran dan pengalaman staf

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 :

Ø Probabilitas di mana risiko adalah nyata

Ø Konsekuensi masalah yang berhubungan dengan risiko

Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko :

Ø Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan

Ø Menggambar konsekuensi risiko

Ø Memperkirakan pengaruh risiko pada proyek dan produk

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

Sifatnya ; risiko yang menunjukkan masalah yg muncul bila ia terjadi

Ruang lingkupnya; menggabungkan kepelikannya (seberapa seriusnya masalah ini ? ) dengan keseluruhan distribusi ( berapa banyak proyek yg akan dipengaruhi atau berapa banyak pelanggan terganggu ? )

Timingnya; mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.

JAMINAN KUALITAS PERANGKAT LUNAK
(SOFTWARE QUALITY ASSURANCE)

JAMINAN KUALITAS PL

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

l Kelompok SQA berfungsi sebagai perwakilan in-house pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan.

¡Apakah perangkat lunak cukup memenuhi faktor kualitas

¡Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya?

¡Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA?

AKTIVITAS SQA

l Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda :

¡perekayasa perangkat lunak yang mengerjakan kerja teknis

¡kelompok SQA yang bertanggung jawab terhadap perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan.

l Tugas Kelompok SQA ? (ada 7)

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.

KAJIAN TEKNIK FORMAL
(Formal Technic Review – FTR)

l FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak.

l Kajian teknik formal atau walktrough adalah pertemuan kajian yang disesuaikan dengan kebutuhan yang terbukti sangat efektif untuk menemukan kesalahan.

l Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak.

Formal Technic Review – FTR (cont.)

l Tujuan FTR adalah

¡Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL;

¡Membuktikan bahwa perangkat lunak di bawah kajian memenuhi syarat;

¡Memastikan bahwa PL disajikan sesuai dgn standar yg sudah ditentukan sebelumnya;

¡Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam;

¡Membuat proyek lebih dapat dikelola.

l FTR berfungsi

àdasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang berbeda terhadap analisis perangkat lunak, desain, dan implementasi.

àmengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya.

PERTEMUAN KAJIAN

l Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus mematuhi batasan-batasan berikut ini :

¡Antara 3 & 5 orang (khususnya) harus dilibatkan dalam kajian;

¡Persiapan awal harus dilakukan, tetapi waktu yang dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap person

¡Durasi pertemuan kajian harus kurang dari 2 jam

l Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan ....(ada 3) à kemudian ambil keputusan

l Setelah pertemuan kajian akan dilakukan

¡ Pelaporan Kajian & Penyimpanan Rekaman

l Apa yang dikaji ?

l Siapa yang melakukan?

l penemuan apa yang dihasilkan dan apa kesimpulannya?

¡ Adanya Pedoman Kajian

PENDEKATAN FORMAL TERHADAP SQA

l Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean, dan pengujian yang baik serta aplikasi standar pengembangan perangkat lunak yang diterima.

Jumat, 28 April 2017