REKAYASA PERANGKAT LUNAK

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

REKAYASA PERANGKAT LUNAK t e N

a r d

By

n e H

Page 1 / 224


PERKENALAN DOSEN- MAHASISWA Nama Tempat Tinggal Pendidikan

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

Kegiatan : Dosen

t e N Politeknik Piksi Ganesha a r LP3i Bandung d n e A2K-Proklamasi H UNIBI By

1. 2. 3. 4.

: Konsultan IT/Si Hp ( Mhs ) Profile Email

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

FB/Google

: [email protected] ( tugas ) : hendra jatnika Page 2 / 224


PERANGKAT LUNAK  Perangkat

Lunak (Software) tidak sama dengan program komputer. Perangkat lunak tidak hanya mencakup program, tetapi juga t semua dokumentasi dan konfigurasi data yang e N a r berhubungan, yang diperlukan untuk d n He beroperasi dengan membuat agar program y B benar.  Sistem Perangkat Lunak terdiri dari : Sejumlah program yg terpisah  File-file konfigurasi  Dokumentasi sistem  Dokumentasi User Page 3 / 224 




Dua tipe produk perangkat lunak : Produk Generik  Sistem stand-alone standar yg diproduksi oleh organisasi pengembang dan dijual ke pasar terbuka ke siapapun yg membelinya. Biasa disebut sebagai software shrink-wrapped. Contoh : pengolah kata (word processor).  Produk pesanan (yang disesuaikan) t  Sistem yg dipesan e N oleh pelanggan tertentu. Dikembangkan khusus bagi a r d pelanggan oleh kontraktornperangkat lunak. Contoh : e H proses bisnis tertentu dan Sistem untuk mendukung By sistem kontrol lalu lintas udara. 

Page 4 / 224




Perbedaan PENTING antara tipe2 perangkat lunak : Pada produk generik, organisasi yang mengembangkan perangkat lunak mengontrol spesifikasi perangkat lunak.  Pada produk pesanan, spesifikasi biasanya dikembangkan dan dikontrol oleh organisasi yang membeli perangkat lunak tersebut. 

t e N

a r d

By

n e H

Page 5 / 224


REKAYASA PERANGKAT LUNAK  RPL

atau Software Engineering (SE)  Disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan. Ada 2 istilaht kunci disini :

e

N membuat suatu alat “disiplin rekayasa”  Perekayasa a rmetode, dan alat bantu yang d bekerja. Menerapkan teori, n e H menggunakannya dengan sesuai, selain itu mereka Bymencoba mencari solusi terhadap selektif dan selalu permasalahan.  “semua aspek produksi perangkat lunak”  RPL tidak hanya berhubungan dengan proses teknis dari pengembangan perangkat lunak tetapi juga dengan kegiatan seperti Manajemen proyek PL dan pengembangan alat bantu, metode, dan teori untuk mendukung produksi PL. Page 6 / 224 

PERBEDAAN ANTARA RPL DENGAN COMPUTER SCIENCE ?




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

N a r

d n e

By

H

Page 7 / 224

PERBEDAAN RPL DENGAN REKAYASA SISTEM ?  Rekayasa


sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk thardware, e adalah N rekayasa PL dan proses.rRPL a d n bagian dari rekayasa sistem yang He By meliputi pembangunan PL, infrasktruktur, kontrol, aplikasi dan database pada sistem.

Page 8 / 224


PROSES PERANGKAT LUNAK 

Serangkaian kegiatan dan hasil-hasil relevannya yang menghasilkan perangkat lunak  sebagian besar dilakukan oleh perekayasa perangkat lunak. Ada 4 kegiatan/aktivitas pada proses t PL :

1.

2. 3.

4.

e

N  Fungsionalitas Spesifikikasi Perangkat Lunak a r kemampuan operasinya d perangkat lunak danebatasan n H harus didefinisikan. y B Pengembangan Perangkat Lunak  Perangkat lunak yang memenuhi spesifikasi harus di produksi Validasi Perangkat Lunak  Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan. Evolusi Perangkat Lunak  Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan. Page 9 / 224


MODEL PROSES PERANGKAT LUNAK Merupakan deskripsi yang disederhanakan dari proses perangkat lunak di presentasikan dengan sudut pandang tertentu. t e  Bisa mencakup kegiatan yang merupakan bagian N a r dari proses perangkat lunak, produk perangkat d n lunak, dan peran orangHe yang terlibat pada y B rekayasa perangkat lunak (Perekayasa PL). 

Page 10 / 224


CONTOH JENIS MODEL PROSES PL 1.

2.

3.

Model aliran kerja (workflow)  menunjukkan kegiatan pada proses bersama dengan input, output, dan ketergantungannya. Merepresentasikan pekerjaan manusia. t e N  Model aliran data (data flow) a r d n merepresentasikan proses sebagai suatu set e H y kegiatan yang Bmelakukan transformasi data. Menunjukkan bagaimana input ke proses, misalnya spesifikasi ditransformasi menjadi output, misalnya menjadi desain. Model peran/aksi  merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg 11 / 224 menjadi tanggung Page jawab mereka.

MODEL ATAU PARADIGMA UMUM PADA PROSES PL


1.

2.

Model air terjun (waterfall)  Mengambil kegiatan dasar seperti spesifikasi, pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase tspesifikasi proses yang berbeda seperti e N perangkat lunak, a persyaratan, perancangan r d n e implementasi, pengujian dan seterusnya. H Byevolusioner  Pendekatan Pengembangan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian di perbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan kebutuhan pelanggan. Page 12 / 224


3.

4.

Pengembangan Sistem Formal  Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program. Pengembangan berdasarkan pemakaian ulang t (Reusable)  Teknik ini menganggap bahwa bagiane N a bagian sistem sudah ada.dr Proses pengembangan en sistem terfokus padaHpengintegrasian bagian-bagian Bypengembangannya dari awal. sistem dan bukan

Page 13 / 224


BIAYA REKAYASA PERANGKAT LUNAK Umumnya sekitar 60% untuk biaya pengembangan (development) dan 40% biaya pengujian (testing).  Distribusi biaya yang tepat selama proses perangkat lunak bergantung pada proses yang digunakan dan jenis perangkat lunak yang dikembangkan. et 

N a r

d n e

By

H

Page 14 / 224


REKAYASA PERANGKAT LUNAK t e N

a r d

n e H

By PERANCANGAN ARSITEKTUR PERANGKAT LUNAK

Page 15 / 224

ARSITEKTUR PERANGKAT LUNAK


• An abstract system specification consisting primarily of functional components described in terms of their behaviors and interfaces and t component-component interconnections. The e N a r interconnections define provide by which d n He components interact. y

B

• How the system is decomposed and organized into components and must describe the interfaces between these components.

Page 16 / 224

2

ARSITEKTUR PERANGKAT LUNAK ( 2 )


• Gambaran bagaimana elemen/komponen fungsional perangkat lunak disusun, diorganisasi dan distrukturkan sehingga:   

t dapat Hubungan antar elemen/komponen e N a r dijelaskan. d n e H Interface yang menghubungkan elemen/komponen y B dapat didefinisikan. Wujud dan penempatan elemen/komponen dalam tempat penyimpanan sekunder secara fisik dapat ditetapkan. Page 17 / 224

3

CONTOH ARSITEKTUR PERANGKAT LUNAK ( 1 )


Model Analisis (DFD level atomik) id_mhs

Petugas

info_mhs

1.2.3 Cari Info Mahasiswa

By

mahasiswa

t e N

a r d

n e H

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

Search NIM : NIM

query/select

Cari Nama

Tabel Mahasiswa

Kelas

hasil query display Page 18 / 224

4

CONTOH ARSITEKTUR PERANGKAT LUNAK ( 2 )


Model Analisis (DFD level atomik) 1 Tambah Data Barang

Bag ian Penjualan

id_barang

Modul Pemanggil

rec _barang id_s upplier Barang

rec _supplier

rec _supplier Supplier

2 Tambah Data Supplier

By

Arsitektur Perangkat Lunak (Structure Chart)

t e N

a r d

n e H

Kelola Data Induk

Proses 2.0

Proses 1.0

Tambah Data Barang id_barang

Tambah Data Supplier rec_barang

id_supplier

rec_supplier

supplier

Modul-modul atomik (procedure, function)

Baca Id_Barang

Rekam Barang

Baca Id_Supplier

Rekam Supplier

Page 19 / 224

5

STRUCTURE CHART


• Diagram untuk menggambarkan arsitektur perangkat lunak secara keseluruhan tanpa memperlihatkan proses pemilihan t e N dan pengulangannya secara rinci. a r d n e

H • Menggambarkan arsitektur perangkat By lunak seperti diagram organisasi sebuah perusahaan.

Page 20 / 224

6

SIMBOL STRUCTURE CHART


Simbol

Arti • Modul

t e N

a • Pemanggilanrmodul d n e

Hatau elemen kontrol yang dikirimkan • Data y Batau diterima dari satu modul • Pengulangan di dalam modul

• Penyeleksian kondisi di dalam modul

Page 21 / 224

7

CONTOH STRUCTURE CHART : PASCAL ( 1 )


modul pemanggil

A notasi untuk parameter input yang dikirimkan kepada modul yang dipanggil

x, y

p, q

notasi untuk parameter output yang diberikan pada modul pemanggil

t e N

B

modul yang dipanggil

a r d

By

• Modul A memanggil modul B dengan data x dan y sebagai parameternya. • Modul B mengirimkan data p dan q sebagai return value ke modul A.

n e H

Procedure A; Var p, q : Real; Procedure B(x, y : Real); Begin p := ... { manipulasi nilai p } q := ... { manipulasi nilai q } End; Begin B(x, y); { call procedure B } End;

Potongan kode program dalam bahasa Pascal

Page 22 / 224

8

CONTOH STRUCTURE CHART : PASCAL ( 2 )


• Modul A akan memanggil modul B jika kondisi dalam modul A dipenuhi.

A

• Modul A akan memanggil modul C secara berulang.

B

C

t e N

a r d

By Potongan kode program dalam bahasa Pascal

Procedure C; Begin ... End; Procedure B; Begin ... End; Procedure A; Begin If True Then B; {call procedure B} While True Do C; {call procedure C} End;

n e H

Page 23 / 224

9

CONTOH STRUCTURE CHART : PHP


FormInput.html ...
...

t e N

a r d

Rekam.php

FormInput

By

n e H

Rekam id

id

getId

saveId

Page 24 / 224

10

CONTOH STRUCTURE CHART : DELPHI


main.pas unit main; ... var Form1: TForm1; implementation uses Rekam;

t e N

procedure TForm1.Click(Sender: TObject); begin frmRekam.Show; end;

a r d

end.

By

Main

n e H

Rekam rekam.pas unit Rekam; ... var frmRekam: TForm1; implementation ... end. Page 25 / 224

11

TRANSFORMASI DFD - STRUCTURE CHART ( 1 )


• Ubah diagram konteks menjadi modul utama (top module atau executive module) dari structure chart. • Ubah DFD level-1 menjadi modul-modul yang dipanggil oleh modul utama. Jika pemanggilan t modul untuk e N a proses-proses pada DFD level-1 r membutuhkan data atau d n sebuah modul untuk e event tertentu, tambahkan H membaca data atau Byevent tersebut. • Ubah DFD level-2, 3, 4, dst. menjadi modul-modul lainnya sesuai dengan fungsinya dengan pendekatan Transform Analysis dan atau Transaction Analysis.

Page 26 / 224

12

TRANSFORMASI DFD - STRUCTURE CHART ( 2 )


Transform Analysis

Transaction Analysis

t e N

a r d

By

n e H

Page 27 / 224

13

PENJADWALAN PROYEK DAN ANALISIS JARINGAN KERJA


Proyek

merupakan kombinasi dari kegiatan-kegiatan (activities) yang saling berkaitan dan harus dilaksanakan dengan mengikuti suatu urutan tertentu sebelum seluruh tugas dapat diselesaikan sacara tuntas. t usaha satu waktu Pada umumnya suatu proyek adalah e N a (one-time effort). Maksudnyadr urutan kegiatan-kegiatan n e yang sama mungkin tidak terulang lagi di waktu yang H akan datang. By Perencanaan adalah penentuan mengenai apa yang harus dicapai, kapan dan bagaimana hal tersebut itu dilaksanakan. Perencanaan (planning) merupakan salah satu fungsi manajemen dan bertujuan untuk memecahkan persoalan. Page 28 / 224


Macam Perencanaan

 Perencanaan pembangunan nasional  Regional  Sektoral t e N a r  Perncanaan personalia/tenaga kerja d n e H  Perencanaan Bperalatan y  Perencanaan keuangan  Perencanaan produksi  Perencanaan pemasaran/penjualan Page 29 / 224


Pokok-pokok perencanaan adalah sebagai berikut : (1).Menentukan target, tanpa adanya target sukar untuk membuat evaluasi. t e N a (2).Kegiatan-kegiatan yang rharus dilakukan. d n e (3).Urutan kegiatan.y H B (4).Jangka waktu yang diperlukan oleh masingmasing. (5).Tersedianya alat ukuran/standar. (6).Memperhatikan contingency factor. Page 30 / 224

TEKNIK PERENCANAAN  




CPM (Critical Path Method) PERT (Project Evaluation and Review Technique) Berguna untuk menyusun perencanaan, penjadwalan dan pengawasan/pengontrolan proyek t e N a merupakan metode PERT dan CPM pada dasarnya r d n He dalam arti bahwa keduanya yang berorientasikan waktu, y B akan berakhir dengan penentuan penjadwalan waktu (a time schedule).

Page 31 / 224


Perbedaan yang paling menonjol ialah perkiraan waktu yang diperlukan untuk melaksanakan kegiatan : deterministic dalam CPM , probabilistis dalam PERT t(project teknik penjadwalan proyek e N a r Shedulling technique) d n By

He

Page 32 / 224


Teknik penjadwalan proyek (project Shedulling technique) Terdiri dari tiga tahapan yaitu : 1.Perencanaan, t e 2.Penjadwalan N a r d n 3.Pengontrolan/pengawasan e H By

Page 33 / 224


Tahapan perencanaan  Dimulai dengan memecah/ menguraikan proyek menjadi kegiatan-kegiatan (activities). t e N  Perkiraan waktu, untuk kegiatan-kegiatan ini a r d n dan diagram jaringan kemudian ditentukan e H kerja (network) Byyang dinyatakan dengan gambar anak panah (arrow)  Keseluruhan diagram anak panah memberikan suatu representasi grafis mengenai keterkaitan antara berbagai kegiatan suatu proyek Page 34 / 224


Pembentukan diagram anak panah sebagai tahapan perencanaan mempunyai tujuan : untuk mempelajari jenis pekerjaan yang berbeda secara rinci, mungkin dapat menimbulkan saran untuk perbaikan sebelum t e N a r lebih penting lagi proyek dilaksanakan. Yang d n e H ialah kegunaannya untuk mengembangkan By suatu jadwal untuk proyek (project schedulling).

Page 35 / 224


TAHAPAN PENJADWALAN 





Jadwal harus mampu menunjukkan kegiatan-kegiatan yang kritis dilihat dari segi waktu yang memerlukan perhatian khusus kalau proyek harus selesai tepat pada waktunya. Jadwal harus menunjukkan banyaknya waktu yang mengambang (slack/fload time) N yang et dapat a r dipergunakan ketika kegiatan tertunda atau kalau d ndipergunakan secara efektif e sumberdaya yang terbatas H (mencapai sasaran/tujuan yang dikehendaki). By Tujuan akhir dari tahap penjadwalan ialah membentuk a time chart yang dapat menunjukkan waktu mulai dan selesainya setiap kegiatan serta hubungannya satu sama lain dalam proyek.

Page 36 / 224


Tahapan Pengawasan Meliputi penggunaan diagram anak panah dan grafik waktu (time chart) t untuk membuat laporan kemajuan e N a r kerja secara periodik. Jaringan d n e H (network) perluBdiperbarui dan y dianalisis dan kalau perlu suatu jadwal baru ditentukan untuk sisa bagian proyek yang belum selesai. Page 37 / 224




Tiga tahapan proyek dimulai dengan

pembentukan diagram anak panah, t grafik cara penyajian data untuk e N a r waktu dan cara mengalokasikan d n e H sumber yangByterbatas berbagai kegiatan/ aktifitas.

Page 38 / 224


PEMBENTUKAN DIAGRAM ANAK PANAH  

 

Diagram anak panah (arrow diagram) menggambarkan keterkaitan antara kegiatan atau aktivitas proyek. Suatu anak panah (arrow) biasanya dipergunakan untuk mewakili suatu kegiatan dengan ujungnya menunjukkan t e arah kemajuan dalam proyek.raN d n Hubungan suatu kegiatan dengan kegiatan yang terjadi He sebelumnya ditunjukkan By oleh adanya kejadian (event). Yang dimaksud dengan kejadian ialah saat yang menggambarkan permulaan atau pengakhiran suatu kegiatan (activity),

Page 39 / 224


Setiap kegiatan digambarkan sebagai anak panah, pangkal anak panah sebagai awal dan ujungnya sebagai akhir suatu kejadian. Anak panah menggambarkan apa yang dikerjakan mendahului, sebelum t e N aSetiap anak panah kegiatan itu dikerjakan. r d n He di ujung dan pangkalnya diberi tanda y B kejadian yang diberi nomor, seperti :

Page 40 / 224


atau



Kegiatan mulai dari kejadian 15 atau i dan berakhir dengan kejadian 16 atau j. untuk selanjutnya kejadian A ditulisekegiatan A (15,16) t N a r dimulai pada titik i atau kegiatan A(i,j), artinya d n e H j. selanjutnya i disebut dan berakhir pada titik By pangkal dan j ujung.

Page 41 / 224


Contoh lain : Kegiatan B baru bisa dikerjakan kalau A sudah selesai. Jadi A harus dikerjakan terlebih dahulu sebelum B. Tanda lingkaran 1, 2, dan 3 merupakan event.

t e N

a r d

By

n e H

Kegiatan B baru bisa dikerjakan kalau A dan B sudah selesai. Jadi A dan B harus diselesaikan dahulu, kemudian baru C dimulai.

B dan C baru bisa dimulai kalau A sudah selesai.

Page 42 / 224






Kejadian (event) tidak memerlukan waktu, digambarkan sebagai lingkaran pada pangkal anak panah (saat dimulainya kegiatan) dan pada ujung anak panah (saat akhir/selesainya kegiatan). et N a rkejadian harus Pemberian nomor pada d n e H memenuhi persyaratan yaitu nomor awal y B (pangkal) harus lebih kecil dari pada nomor akhir (ujung).

Page 43 / 224


Untuk selanjutnya perhatikan aturan-aturan berikut : 1.

2.

Setiap kegiatan hanya boleh diwakili oleh satu anak panah saja didalam jaringan kerja, (kecuali kalau satu kegiatan dipecah t kecil). e menjadi kegiatan yang alebih N r d n kegiatan diwakili oleh Tidak boleh ada dua e H By pangkal dan ujung anak panah yang sama. Dalam hal ini harus dipergunakan anak panah boneka (dummy arrow). Perhatikan ilustrasi berikut. Pangkal (1) dan ujung (2), A dan B sama. Page 44 / 224


A (1,2) B juga (1,2), ini tidak boleh dan harus diatasi dengan menggunakan anak panah boneka seperti berikut ini. D = Dummy, dengan garis putus-putus.

t e N

a r d

By

n e H

Page 45 / 224


Suatu anak panah boneka (dummy) untuk menggambarkan kegiatan yang tidak memakan waktu (kegiatan boneka sering juga disebut semu atau buatan, bukan sesungguhnya). Alasan penggunaan kegiatan boneka (dummy activity) adalah : 1. Menghindarkan keragu-raguan tdalam indikasi, e aN B (1,2), seperti gambar di atas A r (1,2), d n keduanya mempunyai indikasi yang sama, He membingungkan. ByLihat gambar a), b), c) dan d) untuk mengatasinya, di mana : 

– – – –

A(1,2), A(2,3), A(1,3), A(1,3),

B(1,3) D(2,3) B(1,3) D(1,2) B(2,3) D(1,2) B(1,2) D(2,3)

Page 46 / 224


2. Memberikan gambaran urutan logik yang benar. Contoh : Air limbah yang akan dibuang dari saluran pembuangan 1 (Outlet 1) ke sungai dialirkan menuju IPAL I (3), saluran outlet 2 sebelum ke sungai juga akan melewati IPAL I (3), karena beban pengolahan pada IPAL I terbatas, maka kapasitas limbah yang tidak terolah disalurkan ke IPAL II (4), sedangkan yang sudah terolah langsung dapat dibuang ke sungai (5) Kegiatan A :Saluran Outlet 1 menuju IPAL I (3) Kegiatan B :Saluran Outlet 2 menuju IPAL I (3) Kegiatan C :Saluran IPAL I (3) ke IPAL II (4) Kegiatan D :Saluran IPAL I (3) ke sungai (5) 224

t e N

a r d

By

n e H

Page 47 /




 1.

2.

3. 4. 5. 6. 7.

8. 9.

Pada gambar di atas terlihat bahwa kegiatan C belum dapat berlangsung sebelum kegiatan B, yang berarti bahwa kegiatan C dapat beroperasi apabila kegiatan B sudah berjalan, sedangakan D dapat berjalan setelah kegiatan A atau B apabila berjalan tidak bersamaan.

Contoh pembuatan diagram anak panah 1 Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan L sedemikian rupa sehinga hubungan t e berikut ini terpenuhi. N a r proyek yang bisa dimulai A, B, dan C kegiatan dalam suatu d n secara serentak (simultan). e H A dan B mendahului D. y B B mendahului E, F dan H. F dan C mendahului G. E dan A mendahului I dan J C, D, F dan J mendahului K. K mendahului L. I, G dan L merupakan aktifitas terminal di proyek. Page 48 / 224


Jawab.

t e N

a r d

By

n e H

Page 49 / 224




Contoh pembuatan diagram anak panah 2

11.

Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan M sedemikian rupa sehinga hubungan berikut ini terpenuhi. A dan B dapat dimulai secara serentak. C dan D dapat dimulai kalau A sudah selesai. E dapat dimulai kalau C sudah selesai. t G dapat dimulai kalau E sudah selesai. e N a r F dapat dimulai kalau D sudah selesai. d n e H dapat dimulai kalau C, D, E, HF dan G sudah selesai. By B sudah selesai. I dan J dapat dimulai kalau K dapat dimulai kalau J sudah selesai. L dapat dimulai kalau I, J, dan K sudah selesai. M dapat dimulai kalau H dan L sudah selesai.

12.

M kegiatan terminal.

1.

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

Page 50 / 224


t e N

a r d

By

n e H

Page 51 / 224




Contoh pembuatan diagram anak panah 3

1.

Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan J sedemikian rupa sehinga hubungan berikut ini terpenuhi. Proyek dimulai dari kegiatan A, Kegiatan B dan C baru bisa dimulai kalau A sudah selesai. t e Kegiatan D dan E baru bisa r dimulai aN kalau C sudah d selesai. n e H Kegiatan F dan G baru bisa dimulai kalau B sudah y B selesai. Kegiatan H baru bisa dimulai kalau E sudah selesai. Kegiatan I baru bisa dimulai kalau D sudah selesai. Kegiatan J baru bisa dimulai kalau G dan H sudah selesai. Kegiatan I dan J merupakan kegiatan terminal.

2. 3. 4.

5. 6. 7. 8. 9.

Page 52 / 224


t e N

a r d

By

n e H

Page 53 / 224


ARTI DAN KEGUNAAN JARINGAN KERJA ATAU NETWORK  1.

2. 3.

Kebaikan langsung yang dapat dipetik dari pemakaian analisis Network adalah sebagai berikut : Dapat mengenali (identifity) jalur kritis (critical t path)dalam hal ini adalah a jalur Ne elemen-elemen r skala waktu penyelesaian kegiatan yang kritis dalam d n e proyek sebagai keseluruhan. H By Mempunyai kemampuan mengadakan perubahanperubahan semberdaya dan memperhitungkan efek terhadap waktu selesainya proyek. Mempunyai kemampuan memperkirakan efek-efek dari hasil yang dicapai suatu kegiatan terhadap keseluruhan rencana apabila diimplementasikan / dilaksanakan. Page 54 / 224

Keuntungan tidak langsung dari pemakaian network adalah sebagai berikut :


1.

2.

3.

sebelum menyusun suatu network seorang analis harus mengkajirencana secara keseluruhan, merinci dan mengurangi menjadi t yang terpisahe komponen-komponen kegiatan N a r d pisah. n e H y Seorang analis Bharus memikirkan interelasi dari kegiatan-kegiatan. Seorang analis harus memperhitungkan batas waktu untuk mesing-masing unsur kegiatan, sebab setiap kegiatan memerlukan sejumlah waktu tertentu untuk penyelesaiannya. Page 55 / 224


1

SOFTWARE PROJECT MANAGEMENT

Page 56 / 224

17-Oct-10

MANAJEMEN PROYEK PERANGKAT LUNAK t e N a r d n e H By


MANAJEMEN ?

Page 57 / 224

2

By

H

17-Oct-10

Kumpulan orang-orang dalam organisasi ( profesional/non profesioanal )  Bersifat Kekuasaan, mengatur dan memerintah t e  Pengambilan keputusan dan deadline N a r d  Bersifat Strategis, Taktis endan teknis 


APAKAH PROYEK ITU ?

N a r

d n e

By

H

Page 58 / 224

3

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

17-Oct-10




APAKAH PROYEK ITU ?

4

Page 59 / 224

17-Oct-10

Karakteristik – karateristik Proyek  Tugas non rutin  Perlu perencanaan tatau produk e  Tujuan spesifik yang akan dicapai N a spesisfik yang akan dibuat dr n e H jangka waktu  Proyek harus ditentukan y B  Pekerjaan dikerjakan untuk seseorang bukan untuk diri kita  Pekerjaan melibatkan beberapa spesialis  Sumber daya proyek yang tersedia dibatasi  Proyek itu pekerjaan besar / komplek


MASALAH PROYEK PERANGKAT LUNAK

a r d

By

n e H

Page 60 / 224

5

t e N

17-Oct-10

Masalah-masalah yang diidentifikasi oleh mahasiswa sistem komputer dan informasi yang telah menyelesaikan penempatan industri :  Spesifikasi pekerjaan yang kurang  Manajemen mengabaikan IT  Pengetahuan area aplikasi yang kurang  Standard yang kurang  Update dokumentasi yang kurang  Aktifitas sebelumnya yang tidak lengkap pada waktunya – termasuk pengiriman perangkat yang terlambat  Komunikasi antara teknisi dan user yang kurang  Komunikasi yang kurang menyebabkan duplikasi pekerjaan  Komitmen yang kurang – khusunya ketika proyek terikat pada satu orang kemudian keluar  Kemampuan Keahlian teknikal yang kurang  Perubahan kebutuhan hukum  Perubahan lingkungan perangkat lunak  Tekanan deadline  Pengendalian kualitas yang kurang  Management jarak jauh  Pelatihan yang kurang


PROYEK PERANGKAT LUNAK VS TIPE PROYEK LAIN

Page 61 / 224

6

B

17-Oct-10

Banyak teknik manajemen proyek umum yang dapat diaplikasikan dengan MPLL, tapi menurut Fred Brooks memberi catatan bahwa produk proyek perangkat lunak mempunyai t e N karakteristik tertentu. a r d n  Satu cara untuk melihateMPLL adalah sebagai H dari invisible proses membuat visible y 


PROYEK PERANGKAT LUNAK VS TIPE PROYEK LAIN

17-Oct-10

By

7

Karakteristik MPPL 1. Tidak nampak 2. Komplek 3. Flexible

t e N

a r d

n e H

Page 62 / 224


FOKUS MPPL (MANAJEMEN PROYEK PERANGKAT LUNAK ) 17-Oct-10 8

t e N

a r d

By

n e H

Page 63 / 224


MANAJEMEN PERSONEL, PRODUK DAN PROSES proyek perangkat lunak mengatur 4 hal penting :

 Empat

y

B hal ini berurutan mulai dari yang paling penting.  Personel mendapat tempat paling penting karena tanpa personel yang baik dan tepat maka 3 hal lain tidak bisa berjalan dengan baik. Page 64 / 224

9

Personel t Produk  Masalah (problem)  berkaitan dengan e N a  proses dan r d nsangat penting) e  Proyek  tambahan (tapi H 

17-Oct-10

 Manajemen


PARADIGMA REKAYASA PERANGKAT LUNAK

t e N

a r d

By

n e H

Page 65 / 224


ARTI PARADIGMA Berasal dari bahasa Yunani yang berarti suatu model, teladan, arketif dan ideal.  Paradigma adalah suatu model dalam teori ilmu t e pengetahuan atau kerangka berpikir. N 

a r d

By

n e H

Page 66 / 224

ARTI REKAYASA PERANGKAT LUNAK 


Adalah Manipulasi,membuat atau menciptakan sesuatu yang sifatnya khayalan logic yang di wujudkan dalam urutan-urutan perintah t (Coding) beserta data-datanya sehingga menjadi e N a suatu aplikasi yang dapat digunakan . dr

By

n e H

Page 67 / 224

MODEL WATERFALL


SEBAGAI MODEL RAKAYASA PERANGKAT LUNAK

Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan t dari setiap tahap e aliran sistem yang linier. Output N a r d merupakan input bagi tahap en berikutnya.

By

H

Model ini melibatkan tim SQA (Software Quantity Assurance) dengan 5 tahapan, dimana setiap tahapan selalu dilakukan verifikasi atau testing. Tahapan model waterfall meliputi : Page 68 / 224


Gambar model waterfall Requirements definition System and software design

By

t e N

a r d

n e H

Implementation and unit testing

Integr ation and system testing Operation and maintenance

Page 69 / 224


1.

2.

3.

Requirment adalah tahap dilakukan analisa kebutuhan, kemudian diverfikasi klien dan tim SQA (Software Quantity Assurance). Specification adalah dokumentasi spesifikasi. Design adalah tahap membagi kebutuhankebutuhan menjadi sistem perangkat lunak, dalam tahap ini menghasilkan t sebuah arsitektur e N keseluruhan perangkat lunak. a r d n Implementation adalah He tahap dimana kode-kode y di testing atau di uji. program yang diBbuat

Page 70 / 224


4.

5.

Intergration adalah tahap dimana suatu perangkat lunak yang di buat diuji dan yakin menjadi suatu sistem yang lengkap dan memenuhi persyaratan perangkat lunak. Operaton mode & Retirement, ini adalah tahap terpanjang. Sistem dipasang dan digunakan. t kesalahan yang e Pemeliharaan termasuk pembetulan N a r sebelumnya. d tidak ditemukan pada langkah n

By

He

Page 71 / 224


MODEL SPIRAL DALAM REKAYASA PERANGKAT LUNAK

Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara explisit menjelaskan bahwa t e N a r resiko yang disadari nmungkin membentuk d e H dasar model proses umum. y B Model yang di usulkan Boehm berbentuk spiral. Page 72 / 224


t e N

a r d

By

n e H

Page 73 / 224


SETIAP LOOP DALAM

MODEL INI MEWAKILI SEBUAH TAHAP DARI PROSES PERANGKAT LUNAK. TIDAK ADA TAHAP YANG TETAP DALAM MODEL INI. MANAJEMEN HARUS MEMUTUSKAN BAGAIMANA MEMBENTUK PROYEK et KE DALAM TAHAP-TAHAP. PN ERUSAHAAN BIASANYA aMODEL UMUM DENGAN r BEKERJA DENGAN BEBERAPA d n HePROYEK KHUSUS ATAU KETIKA TAHAP TAMBAHAN UNTUK y B MASALAH-MASALAH DITEMUKAN SELAMA PEMBUATAN PROYEK.

Page 74 / 224


SETIAP LOP DIBAGI DALAM 4 SEKTOR SEBAGAI BERIKUT Determine objectives (Menentukan Permasalahan)  Risk Analysis (Analisis Resiko)  Engineering / develop (Melakukan proses rekayasa perangkat lunak) t  Plan next phase (Penentuan rencana-rencana untuk e N a tahap selanjutnya) dr 

By

n e H

Page 75 / 224


PADA

IMPLEMENTASINYA,

MODEL

SPIRAL

INI

JUGA BANYAK DIGUNAKAN, TETAPI BIASANYA

DIKOMBINASIKAN LAIN.

DENGAN

PERMODELAN

YANG

WATERFALL t , YANG SANGAT

e N a MILLESTONES DAN BAGUS DALAM MENENTUKAN r d n PERMODELAN SPIRAL He, YANG SANGAT BAGUS By DENGAN MENGGUNAKAN PROTOTYPING, MERUPAKAN KOMBINASI YANG SERING DIPAKAI DI

DALAM

KONTRAK-KONTRAK

UNTUK

LUNAK.

PERANGKAT

Page 76 / 224


BILA TAHAPAN RISK ANALYSIS TIDAK DAPAT DILEWATI, MAKA PROSES DIHENTIKAN, TIDAK MENGIJINKAN PROSES KEMBALI KE TAHAPAN SEBELUMNYA. RISK ANALYSIS YANG DILAKUKAN ADALAH : •

•

•

Project risk, mempengaruhi rencana proyek, contoh t kekurangan sumber daya e N a r tahap aktual, contoh : d Technical risk, mempengaruhi n e Hdi tahap tersebut personil tidak terlatih By Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software, contoh : software tidak diperlukan

Page 77 / 224

PRIORITAS RESIKO DAPAT DIKATEGORIKAN SEBAGAI BERIKUT :


Catastropik (luar biasa), contoh : penurunan kualitas yang luar biasa, biaya yang tidak terkontrol  Critical (kritis), contoh : tidak tepat waktu, biaya di t luar perkiraan e N a r  Marginal (ringan), contoh :d penjadwalan yang n He terlambat y B  Negligible (tidak berarti), contoh : penggunaan waktu proyek tidak optimal 

Page 78 / 224

PERBEDAAN

MENDASAR

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

SPRILAL DENGAN MODEL LAINNYA ADALAH BAHWA

MODEL

SPIRAL

DENGAN

EKSPLISIT

MENYADARI RESIKO-RESIKO YANG ADA.

RESIKO

ADALAH KONSEP YANG SULIT DIDEFINISIKAN SECARA

TEPAT.

ADALAH

SECARA

INFORMAL

YANG

t SEDERHANA e N

SESUATU

DAPAT

KESALAHAN.

a r d

en

H CBONTOHNYA , y

RESIKO YANG

MENYEBABKAN

JIKA BERTUJUAN

MENGGUNAKAN PEMROGRAMAN BAHASA BARU

(NEW

PROGRAMMING LANGUGE), RESIKO YANG

MUNGKIN

ADALAH

DIGUNAKAN

TIDAK

ALAT

PENGUMPUL

RELIABLE

DAN

YANG TIDAK

MENGHASILKAN CODE OBYEK YANG EFISIEN. Page 79 / 224


UNTUK

MENGGUNAKAN MODEL SPIRAL,

BOEHM

MENYARANKAN SEBUAH BENTUK UMUM YANG

DIPENUHI SPIRAL.

DALAM

BENTUK

SETIAP

DAERAH

INI MUNGKIN DILENGKAPI t

e N a ATAU PERKIRAAN PADA SEBUAH LEVEL ABSTRAK r d n He YANG IMBANG DARI PENGEMBANGAN PRODUK. By

Page 80 / 224

MODEL INCREMENTAL DALAM REKAYASA PERANGKAT LUNAK


Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang t e N lengkap. Proses membangun berhenti jika produk a r d n telah mencapai seluruhHfungsi yang diharapkan. e

By

Pada awal tahapan dilakukan penentuan kebutuhan dan spesifikasi. Kemudian dilakukan perancangan arsitektur software yang terbuka, agar dapat diterapkan pembangunan per-bagian pada tahapan selanjutnya. Page 81 / 224

Tahapan Incremental Model adalah :  Requirement  Specification  Architecture Design


TAHAPAN-TAHAPAN TERSEBUT DILAKUKAN t SECARA BERURUTAN. SETIAPNe BAGIAN YANG a r d TESTING, DIKIRIM SUDAH SELESAI DILAKUKAN n e H KE PEMAKAI UNTUK By LANGSUNG DAPAT DIGUNAKAN. PADA INCREMENTAL MODEL, TIGA TAHAPAN AWAL HARUS DISELESAIKAN TERLEBIH DAHULU SEBELUM TAHAP MEMBANGUN TIAP MODAL. Page 82 / 224


t e N

a r d

By

n e H

Page 83 / 224


UNTUK MENGANTISIPASI KONDISI YANG TERJADI PADA MODEL INCREMENTAL, DIPERKENALKAN MODEL MORE RISKY INCREMENTAL MODEL. MODEL INI MENERAPKAN SISTEM KERJA YANG PARALEL. SETELAH DAFTAR KEBUTUHAN DIDAPATKAN t e SPESIFIKASI UNTUK N DARI PEMAKAI, TIM SPESIFIKASI MEMBUAT a r d MODUL PERTAMA. SETELAH SPESIFIKASI PERTAMA SELESAI, TIM n e H. TIM SPESIFIKASI SEBELUMNYA DESAIN MENINDAK LANJUTI y B JUGA LANGSUNG MEMBUAT SPESIFIKASI UNTUK MODEL KEDUA, DAN SETERUSNYA.

Page 84 / 224

MODEL METODOLOGI RAD (RAPID APPLICATION DEVELOPMENT)

t e N

a r d

By

n e H

Page 85 / 224



Model RAD merupakan model inkremental dari proses pengembangan perangkat lunak yang menekankan pada sedikitnya siklus pengembangan. Model ini memecah suatu proyek menjadi bagian-bagian kecil yang mana tiap bagiannya dibangun dengan model yang mirip dengan Waterfall. Tujuan utama model ini adalah menyelesaikan suatu proyek per bagian, sehingga proses perencanaannya pun per bagian (walaupun pada awalnya melakukan perencanaan secara global)

t e N

a r d

n e H

 RAD adalah model proses pembangunan PL yang incremental.  RAD menekankan pada siklus pembangunan yang pendek/singkat.  RAD mengadopsi model waterfall dan pembangunan dalam waktu singkat dicapai dengan menerapkan component based construction.  Waktu yang singkat adalah batasan yang penting untuk model ini.  Jika kebutuhan lengkap dan jelas maka waktu yang dibutuhkan untuk menyelesaikan secara komplit software yang dibuat adalah misalnya 60 sampai 90 hari.

By

Page 86 / 224


• Fase-fase di atas menggambarkan proses dalam model RAD. • Sistem dibagi-bagi menjadi beberapa modul dan dikerjakan dalam waktu yang hampir bersamaan dalam batasan waktu yang sudah ditentukan.

– Business modelling : menjawab pertanyaan-pertanyaan: informasi apa yang mengendalikan proses bisnis? Informasi apa yang dihasilkan? Siapa yang menghasilkan informasi? Kemana informasi itu diberikan? Siapa yang mengolah informasi?  kebutuhan dari sistem – Data modelling: aliran informasi yang sudah didefinisikan, disusun menjadi sekumpulan objek data. Ditentukan karakteristik/atribut dan hubungan antar objek-objek tersebut  analisis kebutuhan dan data – Process Modelling : objek data yang sudah didefinisikan diubah menjadi aliran informasi yang diperlukan untukmenjalankan fungsi-fungsi bisnis. – Application Generation: RAD menggunakan component program yang sudah ada atau membuat component yang bisa digunakan lagi, selama diperlukan. – Testing and Turnover: karena menggunakan component yang sudah ada, maka kebanyakan component sudah melalui uji atau testing. Namun component baru dan harus tetap diuji. Pageinterface 87 / 224

t e N

a r d

By

n e H


Model Build and Fixed Model rekayasa perangkat lunak (RPL) ini adalah model RPL paling sederhana, sangat cocok untuk proyek-proyek kecil yang terbatas komplesitasnya karena dibangun dengan persyaratan minimal, dan umumnya tidak ada spesifikasi usaha maupun desain, dan bahkan pengujiannya sering kali diabaikan

t e N

a r d

By

n e H

Page 88 / 224

1. CLASSIC LIFE CYCLE PARADIGMA




SISTEM ENGINEERING



ANALYS



DESIGN

By

t e N

a r d

n e CODE H



A. Analisis B. Perancangan C. Pengkodean D. Pengujian E. Maintenance

TESTING MAINTENANCE

Page 89 / 224


2. BERORIENTASI OBJEK 

Paradigma pembangunan perangkat lunak berbasis objek adalah bagaimana merepresentasikan dunia nyata ke dalam sebuah tmasalah tidak sistem sehingga pemecahan suatu e N a dilihat dari cara menyelesaikan masalah r d n e tersebut tetapi dititikberatkan pada objek-objek H apa sajakah yangBy dapat memecahkan masalah tersebut.

Page 90 / 224


3. PROTOTYPE PARADIGMA  Prototyping

paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari t e N software, mengidentifikasi segala a r d n kebutuhan yang diketahui, dan area garis e H besar diman By definisi lebih jauh merupakan keharusan kemudian dilakukan “perancangan kilat”. Perancangan kilat berfokus pada penyajian dari aspek – aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output). Page 91 / 224


3. PROTOTYPE PARADIGMA REQUIMENTS GATHERING "QUICK DESIGN"

t e N BUILD PROTOTYPE a r d n e EVALUATED AND REFINEMENTS H By

ENGINEER PRODUCT

Page 92 / 224

4. THE 4TH GENERATION TECHNIQUE PARADIGMA 


Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software t menerapkan beberapa karakteristik software e N a pada tingkat yang tinggi, r yang kemudian d n dan object code secara e menghasilkan source code H otomatis sesuai Bydengan spesifikasi yang ditentukan developer.

Page 93 / 224

4. THE 4TH GENERATION REQUIMENTS P GATHERING TECHNIQUE ARADIGMA "DESIGN STRATEGICS" IMPLEMENTATION USING 4GT PRODUCT

t e N

a r d

By

n e H

Page 94 / 224



TUGAS !! Buat Perbandingan tiap Model, dan penerpan kasus 1. Waterfall t e 2. Spiral N a r d n 3. Incerementa e H 4. Rad By 5. Build and Fixed

Page 95 / 224


Perencanaan Proyek t e N

a r d Perencanaan PL & Manajemen Resiko n e H By

1

RPL 5-6

Page 96 / 224


Perencanaan Proyek Perangkat Lunak  Tujuan

: membuat kerangka kerja yang memungkinkan manajer membuat estimasi yang dapat dipertanggungjawabkan mengenai t e N sumberdaya, biaya & jadwal.Estimasi dibuat dengan a r d kerangka waktu yang terbatas pada awal sebuah n e H proyek PL & diperbaharui secara teratur selama y proyek berjalan.B

 Why?  So the end result gets done on time, with quality!

2

RPL 5-6

Page 97 / 224


 Langkah Perencanaan PL:  Scoping — memahami permasalahan dan apa

yang harus dikerjakan  Estimation—estimasi waktu?tEstimasi SDM?estimasi PL/PK? aNe r  Risk— apa saja yang mungkin terjadi? Bagaimana d n mengatasinya? Apa Heyang harus dilakukan untuk mengatasi resiko By yang terjadi?  Schedule— bagimana mengalokasikan semua sumber daya sesuai dengan waktu yang telah ditentukan?  Control strategy — bagaimana kualitas kontrol ?bagaimana mengkontrol segala sesuatu jika terjadi perubahan?

3

RPL 5-6

Page 98 / 224


 Bagaimana memahami lingkup PL/scope?  Memahami kebutuhan customer t ada  Memahami konteks bisnis yang e N a r proyek  Memahami permasalahan d n e H customer terhadap PL yang  Memahami motivasi y B akan dikerjakan  Memahami setiap bagian jika terjadi perubahan

Page RPL 5-6

99 / 224

4


 Sumber Daya Proyek

t e N

By

a r d Manusia n He

Komponen PL PK & PL 5

RPL 5-6

Page 100 / 224


 Sumber Daya Manusia  Dimulai dengan mengevaluasi lingkup serta memilih kecakapan

yang dibutuhkan untuk menyelesaikan proyek, baik posisi organisasi(manajer, perekayasa PL senior dll) maupun t ejaringan dll) ditentukan. N specialist(telekomunikasi, database, ra

d n e

By

6

RPL 5-6

H

Page 101 / 224


 Komponen PL  Komponen Off-the-self : PL yang ada dapat diperoleh dari bagian proyek sebelumnya yang siap untuk digunakan pada proyek saat ini & telah divalidasi seluruhnya.  Komponen Full-Experience : spesifikasi,tkode, desain atau Ne pengujian data yang sudah ada yangadikembangkan pada proyek rsaat ini. Dimana setiap d yang lalu & serupa dengan proyek n e H anggota tim memilikiypengalaman penuh pada bidang aplikasi sehingga modifikasiBkomponen resikonya relatif rendah

7

RPL 5-6

Page 102 / 224


 Komponen Partial-Experience : aplikasi, kode, desain atau data

pengujian yang ada pada proyek yang lalu yang dihubungkan dengan proyek PL saat ini tetapi membutuhkan modifikasi substansial & berisiko sedang t e N harus dibangun oleh Tim  Komponen Baru : komponen PLayang r d n ini & berisiko tinggi proyek untuk kebutuhanesaat

By

8

RPL 5-6

H

Page 103 / 224


 PL & PK  PK menyediakan sebuah platform yang mendukung PL yang

dibutuhkan untuk menghasilkan produk kerja yang merupakan keluaran dari RPL yang baik t

e N a

r d n

By

9

RPL 5-6

He

Page 104 / 224


Estimasi Proyek PL (Biaya & Usaha )

Estimasi sampai akhir proyek

t e N

a yang mirip & sudah r Estimasi pada proyek-proyek d n He dilakukan sebelumnya By

Estimasi dengan menggunakan teknik dekomposisi Estimasi dengan menggunakan model empiris

10

RPL 5-6

Page 105 / 224


 TeknikDekomposisi  Dekomposisi Masalah  Dekomposisi Proses

Statement of Scope

t e N functional a r

ddecomposition n e

y

H

B performa parse"

RPL Page 5-6

106 / 224

11


 Dekomposisi Masalah  Estimasi berdasarkan baris kode (LOC) & titik fungsi (FP).  Data LOC & FP digunakan dalam 2 cara t: e N mengukur masing-masing a  Sebagai variabel estimasi yang dipakai untuk r d n elemen PL e H  Sebagai Metrik Baseline By yang dikumpulkan dari proyek yang lalu & dipakai dalam hubungnya dengan variabel estimasi untuk mengembangkan proyeksi usaha & biaya

12

RPL 5-6

Page 107 / 224


 Estimasi berbasis LOC  Dimana fungsi PL diidentifikasi sbb:  Interface pemakai & fasilitas kontrol (UICF) t e N  Analisis geometri 2 dimensi (2DGA) a r d n  Analisis geometri 3 dimensi (3DGA) He y  Manajemen databaseB(DBM)  Fasilitas tampilan grafiskomputer(CGDF)  Kontrol periperal (PC)  Modul analisis desain (DAM)

13

RPL 5-6

Page 108 / 224


 Dekomposisi Proses  Dengan perkiraan proses yang akan digunakan yaitu proses yang

didekomposisi ke dalam serangkain aktivitas.tugas yang relatif sangat kecil & usaha yang dibutuhkan t untuk menyelesaikan e N masing-masing tugas yang diperkirakan. ra

d n e

By

14

RPL 5-6

H

Page 109 / 224


Model Perkiraan Empiris  Menggunakan rumusan yang ditarik secara empiris untuk

memprediksi usaha sebagai fungsi LOC & FP dimana harga LOC & FP diperkirakan dengan menggunakan tabel yang telah ditentukan. et

N a r

d n e

By

15

RPL 5-6

H

Page 110 / 224


 Model COCOMO(COnstructive COst MOdel), menurut Barry Boehm, hirarki modelnya dibagi sbb:  Model 1 – Model COCOMO Dasar, dimana menghitung usaha pengembangan PL (&Biaya) sebagai fungsi dari ukuran tkode yang diestimasi. e program yang diekpresikan dalamabaris N

Proyek PL

16

Bayb

r d n

He

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

RPL 5-6

Page 111 / 224


 Model COCOMO dibagi menjadi 3 kelas Proyek PL :  Mode Organik : proyek PL yang sederhana & relatif kecil  Mode Semi-detached : proyek PL menengah (dalam ukuran &

kompleksitas) t e Nharus dikembangkan ke  Mode Embedded : proyek PL yang a dalam serangkaian PK ndr

By

17

RPL 5-6

He

Page 112 / 224


 Model 2 – Model COCOMO Intermediate  Menghitung usaha pengembangan PL sebagai fungsi ukuran program & serangkain “pengendali biaya” yang menyangkut penilaian yang subyektif terhadap produk, PK & atribut proyek Net

a r d

By

18

RPL 5-6

n e H

Proyek PL

ai

bi

Organik

2,4

1,05

Semi-detached

3,0

1,12

Embedded

3,6

1,20

Page 113 / 224


 Model 3 – Model COCOMO Advance  Menghubungkan semua karakteristik versi intermediate dengan penilaian terhadap pengaruh pengedali biaya pada setiap langkah (analisis, perancangan, dll) dari proses RPL.

t e N

a r d

By

19

RPL 5-6

n e H

Page 114 / 224


 Outsourcing  Karena banyaknya area aplikasi PL, biaya dll, manajer PL

dihadapkan pada keputusan make buy/outsourcing yaitu:

t e N

 Off-the-self = Perangkat PL dapat dibeli atau lisensi  Full/ pastial experience = komponen PL dapat diperoleh & dimodifikasi

a r d

n

e kebutuhan serta diintegrasikan sesuai H dengan y dibuat oleh pihak lain untuk memenuhi spesifikasi  Custom built = PL B dapat pembeli

20

RPL 5-6

Page 115 / 224


 Untuk produk PL yang mahal, dapat dilakukan sbb :  Kembangkan spesifikasi untuk fungsi & kinerja PL yang dilakukan. Tentukan karakteristik yang dapat diukur kapan saja dibutuhkan.  Perkirakan biaya internal untuk mengembangkan & tanggal t penyampaian e N a r paling cocok dengan aplikasi  Pilih 3 atau 4 calon aplikasidyang n e anda H y  Pilih komponenByang reusable yang dapat membantu konstruksi aplikasi yang diperlukan

21

RPL 5-6

Page 116 / 224


 Kembangkan sebuah matrik perbandingan yang menyajikan

perbandingan dari fungsi-fungsi pokok & lakukan pengujian untuk membandingkan calon PL t e N  Evaluasi masing-masing paket PL/komponen berdasarkan a r d n kualitas produk sebelumnya, dukungan penjual, arah proyek, e H reputasi dll By  Hubungi pemakai PL lain & mintalah pendapat mereka

22

RPL 5-6

Page 117 / 224


 Analisa terakhir untuk memutuskan outsourcing sbb:  Apakah tanggal penyampaian produk PL akan lebih cepat daripada PL yang dikembangkan internal? t e N pemesanan akan lebih a  Apakah biaya akuisisi ditambah biaya r d n e kecil daripada biaya pengembangan PL internal? H By  Apakah biaya dukungan luar (kontrak pemeliharaan) lebih rendah daripada biaya dukungan internal?

23

RPL 5-6

Page 118 / 224


Manajemen Resiko What can go wrong? What is the likelihood? t e What will the damage be?aN r What can we do about it? d n

By

24

RPL 5-6

He

Page 119 / 224


 Risk Management Paradigm

control t

e N a

r d n

track

He

RISK

By plan

analyze 25

RPL 5-6

Page 120 / 224

identify


Macam Resiko :

  



26

RPL 5-6

Risiko Proyek mengancam rencana proyek, berhub. Dengan biaya, jadwal, SDM, pelanggan & masalah t persyaratan PL e N & ketepatan waktu PL a Risiko Teknik mengancam d kualitas r n spesifikasi, keusangan e yg dihasilkan, berhub. Dengan H By teknik, dll Risiko yang sudah diketahui, yaitu risiko yang dapat diketahui setelah dilakukan evaluasi terhadap rencana proyek, bisnis, dl

Page 121 / 224




Risiko Bisnis mengancam viabilitas PL yang akan dibangun, berhub. Dengan :     

27

RPL 5-6

Pembangunan produk & sistem yang baik sekali yg tidak diinginkan oleh pelanggan. Pembangunan produk yang tidak sesuai t dengan strategi bisnis e N perusahaan a r bag. Pemasaran tidak tahu bagaimana d Pembangunan produk dimana n e harus menjualnya.H y KehilanganB dukungan dari manajemen senior sehub. Dgn perubahan manusia Kehilangan hal-hal yg berhub. Dgn biaya

Page 122 / 224


 Risiko yang dapat diramalkan dimana risiko ini diekstrapolasi

dari pengalaman proyek sebelumnya

t e N

a r d

By

n e H

RPL Page 5-6

123 / 224

28




29

Metode yang digunakan untuk mengidentifikasi Risiko adalah dengan checklist item risiko yang dibagi menjadi:  Ukuran produk  Ukuran database ? t e N ?  Jumlah program, file, transaksi a r d n ?  Jumlah PL yangedipakai H  Pengaruh bisnisBy  Pengaruh produk terhadap perusahaan ?  Penyelesaian produk?  Jumlah produk/sistem yang berhub. Dengan PL yang dibangun? RPL 5-6

Page 124 / 224




karakteristik pelanggan 

 



definisi Proses 



30

pelanggan yang mau berpartisipasi dalam penyusunan PL? pelanggan yang memahami proses PL? pelanggan yang memiliki pemahaman akan apa yang diperlukan?

RPL 5-6

t e N

a r d

nuntuk membangun prototype PL? apakah dibutuhkan PL e H yang digunakan? apakah metode spesifikasi By

Page 125 / 224




Lingkungan pengembang  



31

Apakah pengujian dapat diperoleh & sesuai dengan produk yang akan dibangun? Apakah semua peranti saling terintegrasikan? et

N a Teknologi pengembang & yangdr akan dibangun : n khusus untuk persyaratan produk? e  Apakah diperlukan interface H  Apakah teknologi By yang dipakai adalag teknologi baru?

RPL 5-6

Page 126 / 224




Ukuran & pengalaman staf 



Apakah orang-orang yang terbaik didapatkan? Jumlah orang yang bekerja paruh waktu / tidak?

t e N

a r d

By

32

RPL 5-6

n e H

Page 127 / 224




Pengurangan, Monitoring & manajemen Risiko :  Menghindari risiko o Bagaimana mengurangi turnover staf o Menentukan standart dokumentasi & mekanismenya o Melakukan kajian terhadap semua pekerjaan sehingga lebih dari 1 orang yang terbiasa dgn pekerjaan tersebut. t e N dll o Menentukan backupastaf, r d  Monitoring risiko n 

33

RPL 5-6

Memonitor factor-faktor Heyang dapat memberikan indikasi terhadap suatu risiko : hub. yInterpersonal diantara tim, sikap umum tim B terhadap tekanan proyek, dll

Page 128 / 224




34

Manajemen risiko  Jika usaha pencegahan sudah diupayakan ( backup ada, informasi terdokumentasi & pengetahuan telah disebarkan ke seluruh Tim) & ternyata gagal,tmaka diperlukan : e N a yang akan pergi untuk o Untuk anggotartim d n mentransfer He pengetahuan pada anggota tim pengganti By

RPL 5-6

Page 129 / 224


MATERI 1. Manajemen Resiko 2. Kualitas Perangkat Lunak t e 3. SQA aN r d n

By

7/8/2010

He

Page 130 / 224

1


Manajemen Resiko Perangkat Lunak t e N

a r d

By

7/8/2010

n e H

Page 131 / 224

2

Defenisi konseptual mengenai resiko : (Robert Charette)


1. Resiko berhubungan dengan kejadian di masa yg akan datang. 2.Resiko melibatkan perubahan (spt. perubahan t pikiran,pendapat, aksi, atau tempat) e N a dr 3.Resiko melibatkanenpilihan & ketidakpastian H dilakukan. bahwa pilihanBitu akan y

7/8/2010

Page 132 / 224

3


Strategi Resiko Reaktif vs Proaktif Strategi Reaktif Memonitor proyek yg berjalan terhadap t e kemungkinan resiko. N a r d Strategi Proaktif Hen By Dimulai sebelum kerja teknis diawali, dan diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.

7/8/2010

Page 133 / 224

4


Kategori resiko oleh Robert Charette 1. Resiko yang sudah diketahui ( pasti ) 2. Resiko yang dapat diestimasi t 3. Resiko yang tidak diharapkan e N a r d n e

By

7/8/2010

H

Page 134 / 224

5


Resiko Perangkat Lunak Karakteristik resiko : 1. Ketidakpastian 2. Kerugian t e N a Kategori resiko : r d n e H( Mou) 1. Resiko proyek By 2. Resiko teknis 3. Resiko bisnis ( Market)

7/8/2010

Page 135 / 224

6


Resiko proyek Resiko proyek mengancam rencana proyek. Bila resiko proyek menjadi kenyataan maka ada kemungkinan jadwal proyek akan mengalami perubahan & biaya menjadi bertambah. Resiko proyek mengidenifikasi : et N a 1. Biaya r d n e 2. Sumber daya H By 3. Jadwal 4. Pelanggan 5. Personil (staffing & organisasi) 6. Masalah persyaratan

7/8/2010

Page 136 / 224

7

Resiko Teknis


Resiko teknis mengancam kualitas & ketepatan waktu PL yg akan dihasilkan. Bila resiko teknis menjadi kenyataan maka Implementasinya menjadi sangat sulit atau t tidak mungkin e N a terlaksana. r d n e Resiko teknis mengidentifikasi : H By 1. Desain-Perancangan 2. Coding 3. Spesifikasi 4. Interfacing

7/8/2010

Page 137 / 224

8


5. 6. 7. 8. 9.

7/8/2010

Ketidakpastian teknik Verivikasi Keusangan teknik Net a r Masalah pemeliharaan d n e H Teknologi By

Page 138 / 224

9


Resiko bisnis Resiko bisnis mengancam PL yg akan dibangun secara keseluruhan. Resiko bisnis membahayakan proyek atau produk dan nama baik. 5 resiko bisnis utama : 1.Pembangunan produk atau sistem t yg baik sebenarnya tdk e N (resiko pasar) pernah diinginkan oleh setiapaorang r d 2.Pembangunan sebuah produk yg tidak sesuai dgn n e H bagi perusahaan (resiko strategi) keseluruhan strategi bisnis y 3.Pembangunan Bsebuah 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). 7/8/2010

Page 139 / 224

10


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. t e seperti : N a r d 1. Tgl penyampaian ygetdk realitas n H 2. Kurangnya persyaratan yg terdokumentasi By 3. Kurangnya ruag lingkup PL 4. Lingkungan pengembangan yg buruk

7/8/2010

Page 140 / 224

11


Resiko yg dapat diramalkan / Estimasi Dazari pengalaman proyek sebelumnya. Misalnya : 1. Pergantian staf t e 2. Penggantian Resouce aN

r d n

By

7/8/2010

He

Page 141 / 224

12


Identifikasi Resiko Identifikasi resiko dalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek. Tujuan identifikasi resiko : t e N a r untuk menghindari resiko bilamana mungkin, d n e H serta menghindarinya setiap saat diperlukan. y

B

7/8/2010

Page 142 / 224

13


Resiko yg mempengaruhi bisnis

1. Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar. 2. Bagian pemasaran dikendalikantoleh pertimbangan e N a kadang mengalami bisnis, dan pertimbangandrbisnis n kenyataan teknis. e konflik langsung dengan H

By

7/8/2010

Page 143 / 224

14


Resiko yg dihubungkan dgn karakteristik pelanggan

Karakteristik pelanggan : 1. Pelanggan mempunyai keinginan yg berbeda. t e N a 2. Pelanggan memiliki kepribadian yg berbeda. r d n He hubungan bisnis 3. Pelanggan memiliki By 4. Pelanggan juga kadang-kadang bertentangan.

7/8/2010

Page 144 / 224

15


Komponen Resiko 1. Resiko kinerja – tingkat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya. 2. Resiko biaya – tingkat ketidakpastian dimana biaya proyek t akan dijaga e N a r ketidakpastian dimana PL akan d 3. Resiko dukungan – tingkat n e H mudah dikoreksi,ydisesuaikan dan ditingkatkan. B 4. Resiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.

7/8/2010

Page 145 / 224

16


Proyeksi / estimasi resiko Perencanaan proyek bersama dengan manajer & staf teknik melakukan 4 aktifitas proyeksi risiko : 1 Membangun suatu skala yang merefleksikan t e kemungkinan risiko yang dirasakan N a r d n risiko 2 Menggambar konsekuensi e H 3 Memperkirakan Bypengaruh risiko pada proyek dan produk 4 Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman

7/8/2010

Page 146 / 224

17


Menilai pengaruh risiko Tiga faktor yg mempengaruhi konsekuensi jika suatu resiko benar-benar terjadi : 1. Sifatnya - resiko yang menunjukkan masalah yg muncul bila ia terjadi t e N a 2. Ruang lingkupnya n-drmenggabungkan kepelikannya Hemasalah ini ? ) dengan keseluruhan (seberapa seriusnya y B distribusi( berapa banyak proyek yg akan dipengaruhi atau berapa besa pelanggan terganggu ? ) 3. Timingnya - mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.

7/8/2010

Page 147 / 224

18


Faktor Yang Mempengaruhi Kualitas Produk t e N

a r d

By

7/8/2010

n e H

Page 148 / 224

19


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

AKTIVITAS Penulisan program

13

t e N

Membaca program dan membuat manual

ra

d n e

Mengkomunikasi pekerjaan

By

H

16

32

Kegiatan pribadi (libur, sakit, dsb)

13

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

15

Pelatihan

6

Surat menyurat

5

7/8/2010

Page 149 / 224

Waktu Efektif upaya perbaikan atas kegagalan (48%)

Waktu overhead (39%)

20


Diagram distribusi aktivitas programer untuk dua buah proyek perangkat lunak.

t e N

a r d

By

7/8/2010

n e H

Page 150 / 224

21


Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (1) Kemampuan pribadi : -

dua aspek dasar kemampuan : kecakapan umum dan terbiasa dengan aplikasi tertentu.

-

seorang yang cakap dalam pemrograman t belum tentu cakap pula e dalam aplikasi sains, atau sebaliknya. aN

r d n

-

He ketidakakraban dengan lapangan aplikasi akan menghasilkan produktivitas rendah Bydan kualitas yang buruk.

-

yang dimaksud dengan kecakapan umum adalah kemampuan dasar dalam menulis program komputer dengan benar sedangkan ukuran produktivitas seorang programmer adalah banyak baris yang dihasilkan oleh programmer tersebut per hari.

7/8/2010

Page 151 / 224

22


Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (2)

Komunikasi team -

meningkatnya ukuran produk yang dihasilkan akan menurunkan produktivitas programmer akibat meningkatnya kerumitan antara komponen-komponen program dan akibat meningkatnya komunikasi yang perlu dilakukan antara programmer, manajer, dan pelanggan. t

e N a

r

-

d programmer yang terjadi jumlah lintasan komunikasinantar dalam sebuah proyek adalah He n(n-1)/2, dimana n adalah jumlah y programmer yangBterlibat dalam proyek tersebut.

-

penambahan lebih banyak programmer dalam sebuah proyek yang sedang ber-jalan akan menurunkan produktivitas, kecuali jika para programmer baru tersebut mempunyai tugas yang tidak bergantung kepada hasil kerja programmer lama.

-

Hukum Brooks : Adding more programmers to a late project may make it later.

7/8/2010

Page 152 / 224

23


Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (3) Kerumitan produk

- tiga level kerumitan produk : program aplikasi, program utility, program level sistem.

t e N

a r d

By

7/8/2010

n e H

Page 153 / 224

24



Notasi yang tepat •

bahasa pemrograman menetapkan notasi (baca : t token, reserve word) baku, terutama untuk hal-hal e N a yang berkaitan dengan matematika. dr

n e H

•

7/8/2010

Byantar programer (baca : perancang penetapan notasi produk) harus dilakukan sehingga dapat dimengerti dengan jelas.

Page 154 / 224

25



Pendekatan sistematis • •

7/8/2010

sistem menetapkan teknik dan prosedur baku.

t e N

a r d

n pembakuan dalam pengembangan dan pemeliharaan e H y perangkat lunakBmasih belum mantap.

Page 155 / 224

26



Kendali perubahan •

kelenturan sebuah produk perangkat lunak merupakan sebuah kekuatan, tetapi di pihak lain juga t e proses merupakan sumber kesulitanaN dalam r perancangannya. d n

y

He

•

B produk harus tetap meminta perubahan terhadap persetujuan manajer sebagai penanggung jawab proyek.

•

dampak perubahan harus dapat ditelusuri, diuji, dan didokumentasikan.

7/8/2010

Page 156 / 224

27



Tingkat teknologi •

peran penggunaan teknologi dalam proyek perangkat t pemrograman, lunak misalnya menyangkut bahasa e N teknik a lingkungan mesin yang digunakan, r d n pemrograman, dan penggunaan tools tertentu. e H

By

•

bahasa pemrograman modern menyediakan fasilitas penyesuaian pendefinisisan dan penggunaan data, konstruksi aliran kendali, fasilitas modular, dan

concurent programming

7/8/2010

Page 157 / 224

28



Tingkat keandalan • •

setiap produk harus mempunyai keandalan standar.

t e N

a peningkatan keandalan dihasilkan melalui perhatian r d n yang sangat besar pada tahap analisa. e By

H

•

peningkatan keandalan akan menurunkan produktivitas.

•

Boehm : rasio produktivitas antara dua produk dengan keandalan terendah dengan yang tertinggi adalah 2:1.

7/8/2010

Page 158 / 224

29


Faktor Yang Mempengaruhi Kualitas Produk dan Produktivitas Programmer (9) Pemahaman permasalahan -pelanggan adalah penyumbang utama terhadap kegagalan dalam memahami masalah 1. 2. 3.

t e N

a

r perusahaannya tidak memahami permasalahan d n e tidak mengerti kemampuan H dan keterbatasan komputer, y tidak mempunyaiBpengetahuan dasar tentang logika dan algoritma.

-software engineer tidak memahami lapangan aplikasi, gagal mendapatkan informasi kebutuhan pelanggan karena pelanggan bukan seorang end user.

7/8/2010

Page 159 / 224

30



Ketersediaan waktu •

•

penetapan lama proyek dan jumlah programmer terlibat harus mempertimbangkan kemampuan pribadi setiap programmer serta kemapuan komunikasi antar mereka.

t e N

a akan meningkatkan jumlah programmer yang makin r banyak dkeperluan komunikasi. n overhead di antaranya akibat e H

• •

7/8/2010

y B jumlah programmer yang makin sedikit berarti memperbanyak beban kerja kepada setiap programmer.

proyek 1 bulan dengan 6 programmer bisa saja diganti dengan proyek 6 bulan dengan 1 programmer atau proyek 3 bulan dengan 3 programmer.

Page 160 / 224

31



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

t

epelanggan untuk keterampilan berkomunikasi dengan N asejelas-jelasnya, memastikan keinginannya dengan r d masalah dan perancangan, n kemampuan dalam pendefinisian e H kemampuan implementasi y dengan penulisan program yang benar, B kemampuan debugging secara deduktif dengan kerangka “what if ”, dokumentasi, kemampuan bekerja dengan pelanggan.

Semua keterampilan tersebut harus senantiasa dilatih. 7/8/2010

Page 161 / 224

32



Fasilitas dan sumber daya

•

t e N perlu diperhatikan Fasilitas non teknis yang tetap a r d yang berkaitan denganen motivasi programmer H baik, serta tempat yang misalnya : mesinByang y tenang, atau ruang kerjanya dapat ditata secara pribadi.

7/8/2010

Page 162 / 224

33



Pelatihan yang cukup

•

t e N dalam bidangBanyak programmer yang dilatih a r d nteknik elektro, akuntansi, bidang : ilmu komputer, e H matematika, tetapi jarang yang mendapat pelatihan By dalam bidang teknik perangkat lunak.

7/8/2010

Page 163 / 224

34



Kemampuan manajemen •

seringkali manajer proyek tidak mempunyai, atau tbelakang teknik hanya sedikit mengetahui, latar e N a perangkat lunak. dr

n e H

•

7/8/2010

Bypromosi jabatan menjadi manajer di sisi lain terjadi dimana yang berpromosi tidak atau kurang mempunyai kemampuan manajemen.

Page 164 / 224

35



Sasaran yang tepat

•

7/8/2010

t e N Sasaran utama dari teknik perangkat lunak adalah a r d n pengembangan produk-produk perangkat lunak yang e H tepat untuk digunakan. By

Page 165 / 224

36



Peningkatan kualitas Dua aspek yang menimbulkan keinginan untuk meningkatkan kualitas produk adalah et :

N a r

d n e

1.

H keandalan, dan kemampuan seberapa banyak fungsi, y dapat diberikan Bmelalui sejumlah pengembangan

2.

masalah mendasar dari keterbatasan teknologi perangkat lunak.

7/8/2010

Page 166 / 224

37



Faktor lain •

Faktor lain di antaranya adalah : keakraban, akses, t e dan stabilitas terhadap sistem komputer dalam N a r d mengembangkan atau memodifikasi perangkat lunak. n

By

7/8/2010

He

Page 167 / 224

38

Masalah Manajerial


Sejumlah masalah yang seringkali muncul : 1. 2. 3. 4. 5. 6. 7. 8.

9. 10.

7/8/2010

Buruknya perencanaan proyek Buruknya prosedur dan teknik pemilihan manajer proyek Tidak diketahui dengan tepat siapa penanggung jawab buruknya hasil proyek Buruknya kemampuan untuk menetapkan sumber daya yang t e dibutuhkan proyek N a tepat r Kriteria keberhasilan proyek tidak d n Buruknya struktur organisasi He proyek y Pemilihan teknik B menajemen yang tidak tepat Tidak diterapkan prosedur, metoda, dan teknik dalam perancangan sistem kendali yang memungkinkan manajer dapat mengontrol proyeknya dengan baik Tidak digunakannya prosedur, teknik, dan strategi yang dapat menyediakan kejelasan perkembangan proyek Standar dan teknik untuk mengukur kualitas kerja dan produktivitas programmer dan analis pengolahan data tidak dijalankan Page 168 / 224

39


Beberapa solusi yang dapat dilakukan : 1. lakukan pendidikan dan pelatihan terhadap manajemen puncak dan manajer proyek 2. laksanakan penggunaaan standar, prosedur, dan pendokumentasian 3. lakukan analisa data dari proyek sebelumnya untuk menentukan metode yang efektif t e N 4. tetapkan tujuan dengan menyatakan kualitas yang diinginkan a r dstandar peluncuran produk 5. tetapkan kualitas dengan acuan n He proyek 6. tetapkan kriteria keberhasilan By 7. siapkan rencana darurat 8. kembangkan kejujuran, akurasi biaya, dan perkiraan jadwal proyek yang dapat diterima manajemen dan pelanggan 9. pilih manajer proyek berdasarkan kemampuannya memimpin proyek, bukan berdasarkan kemampuan teknik atau (apalagi) memang tidak ada orang lain lagi 10.buat penetapan kerja yang spesifik untuk setiap pelaksana dan tetapkan standar kerja. 7/8/2010

Page 169 / 224

40

JAMINAN KUALITAS PERANGKAT LUNAK (SOFTWARE QUALITY ASSURANCE)


t e N

a r d

By

7/8/2010

n e H

Page 170 / 224

41


JAMINAN KUALITAS PL • Jaminan kualitas perangkat lunak adalah aktivitas pelindung yang diaplikasikan pada seluruh proses perangkat lunak. • SQA meliputi : – pendekatan manajemen kualitas et efektif (metode dan – teknologi rekayasa perangkat lunakNyang a peranti) r d n – kajian teknik formal yangHe diaplikasikan pada keseluruhan proses perangkat lunak By – strategi pengujian multitiered (deret bertingkat) – kontrol dokumentasi perangkat lunak dan perubahan – prosedur untuk menjamin kesesuaian dengan standar pengembangan perangkat lunak – mekanisme pengukuran dan pelaporan.

7/8/2010

Page 171 / 224

42


KONTROL KUALITAS • Kontrol kualitas merupakan serangkaian pemeriksaan, kajian, dan pengujian yang digunakan pada keseluruhan siklus t bahwa setiap pengembangan untuk memastikan e N yang ditetapkan. a produk memenuhi persyaratan r d n e Hkontrol adalah bahwa semua • Konsep kunci kualitas By spesifikasi yang telah produk kerja memiliki ditentukan dan dapat diukur dimana kita dapat membandingkan output dari setiap proses. • Kalang (loop) menjadi penting untuk meminimalkan cacat yang dihasilkan. 7/8/2010

Page 172 / 224

43


JAMINAN KUALAITAS • Jaminan kualitas terdiri atas fungsi auditing dan pelaporan manajemen. t : • Tujuan jaminan kualitas adalah e N a r d untuk memberikan Hdata en yang diperlukan oleh manajemen Byuntuk menginformasikan masalah kualitas produk, sehingga dapat memberikan kepastian & konfidensi bahwa kulitas produk dapat memenuhi sasaran. 7/8/2010

Page 173 / 224

44


BIAYA KUALITAS • Biaya kualitas menyangkut semua biaya yang diadakan untuk mengejar kualitas atau untuk menampilkan kualitas yang berhubungan dengan t e aktivitas. N a r d • Biaya kualitas dapatHdibagi ke dalam biayaen biaya yang dihubungkan dengan : By – pencegahan – penilaian – kegagalan. 7/8/2010

Page 174 / 224

45


DEFINISI KUALITAS PL • Kualitas perangkat lunak didefinisikan sebagai: t fungsional dan e Konformansi terhadap kebutuhan N a rsecara eksplisit, standar d kinerja yang dinyatakan n e H perkembanganByyang didokumentasikan secara eksplisit, dan karakteristik implisit yang diharapkan bagi semua perangkat lunak dikembangkan secara profesional.

7/8/2010

Page 175 / 224

46


DEFINISI KUALITAS PL (cont.) • Definisi tersebut berfungsi untuk menekankan tiga hal penting, yaitu: – Kebutuhan perangkat lunak merupakan fondasi t e yang melaluinya kualitas diukur. N a r d n – Standar yang telah ditentukan menetapkan e H pengembangan yang serangkaian kriteria By menuntun cara perangkat lunak direkayasa. – Ada serangkaian kebutuhan implisit yang sering dicantumkan (misalnya kebutuhan akan kemampuan pemeliharaan yang baik). 7/8/2010

Page 176 / 224

47


DEFINISI KUALITAS PL (cont.) • Kelompok SQA berfungsi sebagai perwakilan inhouse pelanggan, yaitu orang yang akan melakukan SQA harus memperhatikan perangkat lunak dari sudut pandang pelanggan. Net

a r dcukup memenuhi faktor – Apakah perangkat lunak n He kualitas By

– Sudahkah pengembangan perangkat lunak dilakukan sesuai dengan standar yang telah ditetapkan sebelumnya? – Sudahkah disiplin teknik dengan tepat memainkan perannya sebagi bagian dari aktivitas SQA? 7/8/2010

Page 177 / 224

48


AKTIVITAS SQA • Jaminan kualitas perangkat lunak terdiri dari berbagai tugas yang berhubungan dengan dua konstituen yang berbeda :

t e N

ayang mengerjakan kerja – perekayasa perangkat lunak r d n teknis He By bertanggung jawab terhadap – kelompok SQA yang perencanaan jaminan kualitas, kesalahan, penyimpanan rekaman, analisis, dan pelaporan.

7/8/2010

Page 178 / 224

49


KAJIAN PERANGKAT LUNAK • Kajian perangkat lunak merupakan salah satu aktivitas SQA yang terpenting. • Kajian perangkat lunak adalah suatu filter bagi t yaitu kajian yg proses rekayasa perangkat lunak, e N a diterapkan pd berbagai d titik r selama en pengembangan PL & Hberfungsi untuk mencari By kesalahan yg kemudian akan dihilangkan. • Kajian perangkat lunak berfungsi untuk “memurnikan” produk kerja perangkat lunak yang terjadi sebagai hasil dari analisis, desain, dan pengkodean. 7/8/2010

Page 179 / 224

50


KAJIAN TEKNIK FORMAL (Formal Technic Review – FTR)

• FTR adalah aktivitas jaminan kualitas perangkat lunak yang dilakukan oleh perekayasa perangkat lunak. t adalah • Kajian teknik formal atau walktrough e N a pertemuan kajian yang disesuaikan dengan r d nsangat efektif untuk e kebutuhan yang terbukti H By menemukan kesalahan. • Keuntungan utama kajian teknis formal adalah penemuan kesalahan sejak awal sehingga tidak berlanjut ke langkah selanjutnya dalam proses perangkat lunak. 7/8/2010

Page 180 / 224

51


Formal Technic Review – FTR (cont.) • Tujuan FTR adalah – Menemukan kesalahan dlm fungsi, logika, / implementasinya dlm berbagai representasi PL; t e N a – Membuktikan bahwa perangkat lunak di bawah r d n kajian memenuhi syarat; He By PL disajikan sesuai dgn – Memastikan bahwa standar yg sudah ditentukan sebelumnya; – Mencapai perangkat lunak yg dikembangkan dengan cara yang seragam; – Membuat proyek lebih dapat dikelola. 7/8/2010

Page 181 / 224

52


Formal Technic Review – FTR (cont.) • FTR berfungsi dasar pelatihan yang memungkinkan perekayasa yunior mengamati berbagai pendekatan yang t e N aperangkat lunak, berbeda terhadap analisis r d n desain, dan implementasi. He y B mengembangkan backup dan kontinuitas karena sejumlah orang mengenal baik bagian-bagian perangkat lunak yang tidak mereka ketahui sebelumnya. 7/8/2010

Page 182 / 224

53


PERTEMUAN KAJIAN • Tanpa memperhatikan format FTR yang dipilih, setiap pertemuan kajian harus mematuhi batasan-batasan berikut ini : t harus dilibatkan e – Antara 3 & 5 orang (khususnya) N a r d dalam kajian; n e H y – Persiapan awalBharus dilakukan, tetapi waktu yang dibutuhkan harus tidak lebih dari 2 jam dari kerja bagi setiap person – Durasi pertemuan kajian harus kurang dari 2 jam

7/8/2010

Page 183 / 224

54


PERTEMUAN KAJIAN (cont.) •

Pada akhir kajian, semua peserta FTR yang hadir harus memutuskan apakah akan ....(ada 3)  kemudian ambil keputusan t e N • Setelah pertemuan kajian akan dilakukan a r d n – Pelaporan KajianHe& Penyimpanan Rekaman By ? • Apa yang dikaji • •

Siapa yang melakukan? penemuan apa yang dihasilkan dan apa kesimpulannya?

– Adanya Pedoman Kajian 7/8/2010

Page 184 / 224

55


PENDEKATAN FORMAL TERHADAP SQA • Kualitas perangat lunak merupakan tugas setiap orang & kualitas dapat dicapai melalui analisis, desain, pengkodean,etdan pengujian N a rstandar yang baik serta aplikasi d n e H pengembanganBperangkat lunak yang y diterima.

7/8/2010

Page 185 / 224

56

Sistem Management Kualitas Berdasarkan ISO 9001:2008


System ISO 9001:2008 focus pada effectifitas proses continual improvement dengan pilar utama pola berpikir dimana dalam setiap process senantiasa melakukan perencanaan yang matang, implementasi yang terukur dengan jelas, dilakukan evaluasi danNanalisis et data yang akurat a sesuai dan monitoring serta tindakan perbaikan yang r d bisa menuntaskan masalah n pelaksanaannya agar benar-benar He yang terjadi di organisasi. By Pilar berikutnya yang digunakan demi menyukseskan proses implementasi ISO 9001 ini, maka ditetapkanlah Delapan prinsip manajemen mutu yang bertujuan untuk mengimprovisasi kinerja system agar proses yang berlangsung sesuai dengan focus utama yaitu effectivitas continual improvement, 8 prinsip manajemen yang dimaksud adalah 7/8/2010

Page 186 / 224

57



1. Customer Focus : Semua aktifitas perencanaan dan implementasi system semataa untuk memuaskan customer. 2. Leadership : Top Management berfungsi sebagai Leader dalam mengawal implementasi System bahwa semua gerak organisasi selalu terkontrol dalam satu t komando dengan e N yang synergy pada setiap a commitment yang sama dandgerak r n e elemen organisasi H Byorang : Semua element dalam organisasi 3. Keterlibatan semua terlibat dan concern dalam implementasi system management mutu sesuai fungsi kerjanya masingmasing, bahkan hingga office boy sekalipun hendaknya senantiasa melakukan yang terbaik dan membuktikan kinerjanya layak serta berqualitas, pada fungsinya sebagai office boy. 7/8/2010

Page 187 / 224

58



4.

5.

6.

Pendekatan Proses : Aktifitas implementasi system selalu mengikuti alur proses yang terjadi dalam organisasi. Pendekatan pengelolaan proses dipetakan melalui business process. Dengan demikian, pemborosan karena proses yang tidak perlu bisa dihindari atau sebaliknya, ada proses yang tidak terlaksana karena pelaksanaan yang tidak sesuai dengan flow process itu sendiri yang berdampak padaNhilangnya kepercayaan et a pelanggan r d n Pendekatan System ke Management He : Implementasi system mengedepankan pendekatan By pada cara pengelolaan (management) proses bukan sekedar menghilangkan masalah yang terjadi. Karena itu konsep kaizen, continual improvement sangat ditekankan. Pola pengelolaannya bertujuan memperbaiki cara dalam menghilangkan akar (penyebab) masalah dan melakukan improvement untuk menghilangkan potensi masalah. Perbaikan berkelanjutan : Improvement, adalah roh implementasi ISO 9001:2008

7/8/2010

Page 188 / 224

59


Sistem Management Kualitas Berdasarkan ISO 9001:2008 7. Pendekatan Fakta sebagai Dasar Pengambilan Keputusan : Setiap keputusan dalam implementasi system selalu didasarkan pada fakta dan data. Tidak ada data (bukti t implementasi) sama dengan tidak dilaksanakannya system e N a ISO 9001:2008 r d n e H 8. Kerjasama yang saling menguntungkan dengan pemasok : By Supplier bukanlah Pembantu, tetapi mitra usaha, business partner karena itu harus terjadi pola hubungan saling menguntungkan.

7/8/2010

Page 189 / 224

60


TUGAS INDIVIDU !! Pelajari 3 bahasan diatas dikarenakan bersifat pemahaman dan wawasan, sebagai evaluasi dosen pertemuan selanjutnya Quiz. t e N

a r d

n e H Materi Selanjutnyay bersifat teknis : B

1. Paradigma Perangkat lunak 2. Konsep, Tools dan Prinsip Design Perangkat lunak 3. Strategi, teknik dan Pengujian

7/8/2010

Page 190 / 224

61


VALIDASINeSOFTWARE t a r d

By

n e H

Page 191 / 224

Verifikasi vs. Validasi


 Verifikasi: “Are we building the product right “  Software seharusnya sesuai dengan spesifikasinya t e N a r d  Validasion:"Are weHbuilding the right product”. en By  Software seharusnya melakukan apa yang benar-benar disyaratkan oleh user.

RPL

Page 192 / 224

2

Proses Verifikasi & Validasi


 Adalahkeseluruhan proses daur hidup V & V harus diterapkan pada setiap tahapan dalam proses software t  Mempunyai dua obyektifaprinsipal e N r d n - Menemukan kekurangan dalam sebuah e H By sistem; - Memperkirakan apakah sistem berguna dan dapat digunakan atau tidak dalam situasi operasional RPL

Page 193 / 224

3

Tujuan Verifikasi & Validasi


 Verifikasi dan validasi harus memberikan kepastian bahwa software sesuai dengan tujuannya. t e N a r d  Hal ini bukan berarti ebenar-benar bebas dari n H By kekurangan  Harus cukup baik untuk tujuan penggunaannya dan tipe dari penggunaan akan menentukan derajat kepastian yang dibutuhkan RPL

Page 194 / 224

4


Kepastian Verifikasi & Validasi

 Tergantung pada tujuan sistem, harapan user dan lingkungan pemasaran – Fungsi Software • Tingkatkepastian tergantung pada bagaimana kritikal software terhadapa sebuah organisasiet N a – Harapan User r d n e • User mungkin mempunyai H harapan yang rendah By ada terhadap software yang – Lingkungan pemasaran • Lebih awal melempar sebuah produk ke pasar lebih penting daripada menemukan kekurangan dalam program

RPL

Page 195 / 224

5

Verifikasi Statik & Dinamik


 Software inspection. Berhubungan dengan analisis representasi sistemstatik untuk menemukan masalah (verifikasi statik) – Dapat menjadi tambahan dari t tool-based e N a r document dan code analysis d n e H  Software testing. Berhubungan dengan By pelaksanaan dan memperhatikan perilaku produk (dinamik verifikasi) – Sistem dijalankan dengan data tes dan perilaku operasionalnya diperhatikan RPL

Page 196 / 224

6


Verifikasi Statik & Dinamik (cont.)

t e N

a r d

By

RPL

n e H

Page 197 / 224

7


Pengujian Program  Dapat mengungkapkan keberadaan kesalahan bukan ketidakberadaannya  Hanya teknik validasi untuk persyaratan nont e N asoftware dapat r functional sebagai sebuah d n e H dijalankan untuk melihat bagaimana perilakunya By  Harusnya digunakan dalam hubungannya dengan verifikasi statik untuk menyediakan penanganan Verifikasi &Validasi yang menyeluruh RPL

Page 198 / 224

8


Tipe Pengujian  Pengujian Kekurangan – Test dirancang untuk menemukan kekurangan sistem – Uji kekurangan yang berhasil salah satunya adalah t menunjukkan keberadaan kekurangan dalam sebuah e N a r sistem d n e  Pengujian Validasi By H – Ditujukan untuk memperlihatkan bahwa software sesuai dengan persyaratannya – Tes yang berhasil adalah salahsatu yang menunjukkan bahwa persyaratan telah diterapkan secara tepat RPL

Page 199 / 224

9


Pengembangan Model Verifikasi

t e N

a r d

By

RPL

n e H

Page 200 / 224

10


Proses Testing  System Testing – Pengujian terhadap integrasi sub-system, yaitu keterhubungan antar sub-system t  Acceptance Testing e N a rsistem dipakai oleh user. d – Pengujian terakhir sebelum n e H By dengan data dari pengguna – Melibatkan pengujian sistem. – Biasa dikenal sebagai “alpha test” (“beta test” untuk software komersial, dimana pengujian dilakukan oleh potensial customer) RPL

Page 201 / 224

11


Proses Testing (cont.)

t e N

a r d

By

RPL

n e H

Page 202 / 224

12


Proses Testing (cont.)  Component testing - Pengujian komponen- komponen program - Biasanya dilakukan oleh component developer (kecuali untuk system kritis) Net a r  Integration testing end H - Pengujian kelompok By komponen-komponen yang terintegrasi untuk membentuk sub-system ataupun system - Dilakukan oleh tim penguji yang independent - Pengujian berdasarkan spesifikasi sistem RPL

Page 203 / 224

13


Rencana Pengujian  Proses testing - Deskripsi fase-fase utama dalam pengujian  Pelacakan Kebutuhan - Semua kebutuhan user diuji secara t individu e N a r  Item yg diuji d n e H sistem yang diuji - Menspesifikasi komponen By  Jadual testing  Prosedur Pencatatan Hasil dan Prosedur  Kebutuhan akan Hardware dan Software  Kendala-kendala - Mis: kekurangan staff, alat, waktu dll. RPL

Page 204 / 224

14


Failures & Faults  Failure: output yang tidak benar/tidak sesuai ketika sistem dijalankan  Fault: kesalahan dalam source code yang mungkin t e menimbulkan failure ketika rcode aN yg fault tsb d n dijalankan He y B

RPL

Page 205 / 224

15


Contoh Faults, Errors & Failures  Suppose node 6 should be X:= C*(A+2*B) • Failure-less fault: » executing path (1,2,4,5,7,8) will not reveal this t e N fault because 6 is not executed a r d » nor will executing path n e H (1,2,3,5,6,8) because C = 0 y B  Need to make sure proper test cases are selected • the definitions of C at nodes 3 and 4 both affect the use of C at node 6 »executing path (1,2,4,5,6,8) will reveal the failure,but only if B /= 0

RPL

Page 206 / 224

16


Prioritas Testing  Hanya test yang lengkap yg dapat meyakinkan sistem terbebas dari kesalahan, tetap hal ini sangat sulitd ilakukan. t e N a r d  Prioritas dilakukan terhadap pengujian n He kemampuans istem, By bukan masing-masing komponennya.  Pengujian untuk situasi yg tipikal lebih penting dibandingkan pengujian terhadap nilai batas. RPL

Page 207 / 224

17


Test Data & Test Kasus  Test data:Input yang yang direncankan digunakan oleh sistem.  Test cases:Input yang digunakan untuk t e N a r d menguji sistem dan Hmemprediksi output dari en By input jika sistem beroperasi sesuai dengan spesifikasi.

RPL

Page 208 / 224

18


Proses Defect Testing

t e N

a r d

By

RPL

n e H

Page 209 / 224

19


Struktural Testing Disebut juga white-box testing Penentuan test case disesuaikan dengan t e N struktur sistem. Knowledge program a r d n He digunakan untukBymengidentifikasi test case tambahan. Tujuannya untuk menguji semua statement program (debug). RPL

Page 210 / 224

20


White Box Testing

t e N

a r d

By

RPL

n e H

Page 211 / 224

21


Path Testing  Tujuannya meyakinkan bahwa himpunan test case akan menguji setiap path pada suatu program paling sedikit satu kali. t e N a r adalah suatu d  Titik awal untuk path testing n e H program flow graph Byyang menunjukkan node-node yang menyatakan program decisions (mis.: if-thenelse condition) dan busur menyatakan alur kontrol  Statements dengan conditions adalah node-node dalam flow graf. RPL

Page 212 / 224

22


Program Flow Graph Menggambarkan alur kontrol.Setiap cabang ditunjukkan oleh path yg terpisah dan loop ditunjukkan oleh arrows looping kembali ke t loop kondisi node. e N a r d Digunakan sebagai Hbasis untuk menghitung en By cyclomatic complexity.  Cyclomatic complexity = Jumlah edges – Jumlah Node + 2.  Cyclomatic complexity menyatakan jumlah test untuk menguji control statements RPL

Page 213 / 224

23


Program Flow Graph (cont.)

t e N

a r d

By

RPL

n e H

Page 214 / 224

24


Independent Path  1, 2, 3, 8, 9  1, 2, 3, 4, 6, 7, 2 t e  1, 2, 3, 4, 5, 7, 2 N a r d n e  1, 2, 3, 4, 6, 7, 2, y8,H9 B  Test cases harus ditentukan sehingga semua path tsb tereksekusi.

RPL

Page 215 / 224

25


Black Box Testing  Pendekatan pengujian dimana program dianggap sebagai suatu„black-box‟ („kotak hitam‟) t e N a r d  Program test case berbasiskan spesifikasi n e H By  Test planning dapat dimulai sejak awal proses pengembangan sistem

RPL

Page 216 / 224

26


Black Box Testing (cont.)

t e N

a r d

By

RPL

n e H

Page 217 / 224

27


Black Box Testing (cont.)  Pengujian black box berusaha menemukan kesalahan dalam kategori: – Fungsi-fungsi yang tidak benar atau hilang t e N a – Kesalahan interfaceendr H By struktur data atau akses – Kesalahan dalam database eksternal – Kesalahan kinerja – Inisialisasi dan kesalahan terminasi RPL

Page 218 / 224

28


Partisi Ekivalensi  Input data dan output hasil terdapat diklas yang berbeda yang sesuai dengan klas inputnya t e N a r d  Masing-masing klas equivalensi partition n He diprosres dimana program akan memproses By anggota klas-klas tersebut secara equivale.  Test cases dipilih dari masing-masing partisi RPL

Page 219 / 224

29


PENGUJIAN BERORIENTASI OBJEK t e N a r

d n e

By

H

Page 220 / 224


Object Oriented Testing  Komponen yang diuji adalah classobject.  Lebih besar dibandingkan pengujian t e N a  suatu function sehingga pendekatan r d n e H white-box testingByperlu diperluas.  Tidak jelasnya ‘top’ suatu system untuk top-down integration dan testing. RPL

Page 221 / 224

31


Testing Levels  Testing operations pada objects  Testing object classes t e N a  Testing clusters cooperating objects r d n He  Testing OO system By secara lengkap

RPL

Page 222 / 224

32


Pengujian Class

By

RPL

 Menguji terhadap semua operation yg tdan perubahan ada e N a r d n atribut-atributnya. e H

Page 223 / 224

33


Cluster Testing

t e N

a r d

By

n e H

Cluster testing digunakan untuk test integrasi terhadap kooperatif object. Identifikasi clusters menggunakan knowledge operation objects dan system features yang diimplementasikan oleh cluster tersebut. RPL

Page 224 / 224

34

REKAYASA PERANGKAT LUNAK

Recommend Documents