REKAYASA PERANGKAT LUNAK (5). pdf

By HendraNet

P ERKENALAN D OSEN -M AHASISWA

Nama

: Hendra Jatnika

Tempat Tinggal : Garut – Bandung Pendidikan

1. D3 Informatika MIPA UNPAD Bandung 2. S1 STMIK-IM Bandung 3. S2 STMIK-LIKMI Bandung

Kegiatan : Dosen

1. Politeknik Piksi Ganesha 2. LP3i Bandung 3. A2K-Proklamasi

4. UNIBI By HendraNet

: Konsultan IT/Si

: hendra-jatnika.web.id

: [email protected] (Konsultasi ) : [email protected] ( tugas )

FB/Google

: hendra jatnika

Page 2 / 224

PERANGKAT LUNAK  Perangkat Lunak (Software) tidak sama

dengan program komputer. Perangkat lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan, yang diperlukan untuk membuat agar program beroperasi dengan

By HendraNet

benar.  Sistem Perangkat Lunak terdiri dari :

 Sejumlah program yg terpisah  File-file konfigurasi  Dokumentasi sistem  Dokumentasi User

 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)  Sistem yg dipesan

oleh pelanggan tertentu. Dikembangkan khusus bagi pelanggan oleh kontraktor perangkat lunak. Contoh : Sistem untuk mendukung proses bisnis tertentu dan

By HendraNet

sistem kontrol lalu lintas udara.

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

By HendraNet

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 istilah kunci disini :

 “disiplin rekayasa”  Perekayasa membuat suatu alat

bekerja. Menerapkan teori, metode, dan alat bantu yang sesuai, selain itu mereka menggunakannya dengan

selektif dan selalu mencoba mencari solusi terhadap By HendraNet

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.

P ERBEDAAN ANTARA RPL DENGAN C OMPUTER S CIENCE ?

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

By HendraNet

P ERBEDAAN RPL DENGAN R EKAYASA S ISTEM ?

 Rekayasa sistem berkaitan dengan semua aspek dalam pembangunan sistem berbasis komputer termasuk hardware, rekayasa PL dan proses. RPL adalah bagian dari rekayasa sistem yang

meliputi pembangunan PL, By HendraNet

infrasktruktur, kontrol, aplikasi dan database pada sistem.

P ROSES P ERANGKAT L UNAK

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

1. Spesifikikasi Perangkat Lunak  Fungsionalitas perangkat lunak dan batasan kemampuan operasinya

harus didefinisikan.

By HendraNet

2. Pengembangan Perangkat Lunak  Perangkat lunak yang memenuhi spesifikasi harus di produksi 3. Validasi Perangkat Lunak  Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan. 4. Evolusi Perangkat Lunak  Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan.

M ODEL P ROSES P ERANGKAT L UNAK

 Merupakan deskripsi yang disederhanakan dari proses perangkat lunak di presentasikan dengan sudut pandang tertentu.

 Bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat pada

By HendraNet

rekayasa perangkat lunak (Perekayasa PL).

C ONTOH J ENIS M ODEL P ROSES PL

1. Model aliran kerja (workflow)  menunjukkan kegiatan pada proses bersama dengan input,

output, dan ketergantungannya. Merepresentasikan pekerjaan manusia.

2. Model aliran data (data flow)  merepresentasikan proses sebagai suatu set

kegiatan yang melakukan transformasi data. By HendraNet

Menunjukkan bagaimana input ke proses, misalnya spesifikasi ditransformasi menjadi output, misalnya menjadi desain.

3. Model peran/aksi  merepresentasikan peran orang yang terlibat pada PL dan kegiatan yg

menjadi tanggung jawab mereka. Page 11 / 224

M ODEL ATAU PARADIGMA UMUM PADA PROSES PL

1. Model air terjun (waterfall)  Mengambil kegiatan dasar seperti spesifikasi,

pengembangan, validasi, dan evolusi dan merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.

2. Pengembangan evolusioner By HendraNet  Pendekatan

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.

3. Pengembangan Sistem Formal  Pendekatan ini menghasilkan suatu sistem matematis yang formal dan mentransformasikan spesifikasi ini, dengan menggunakan metode matematik menjadi sebuah program.

4. Pengembangan berdasarkan pemakaian ulang (Reusable)  Teknik ini menganggap bahwa bagian- bagian sistem sudah ada. Proses pengembangan sistem terfokus pada pengintegrasian bagian-bagian

sistem dan bukan pengembangannya dari awal. By HendraNet

B IAYA R EKAYASA P ERANGKAT L UNAK

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

By HendraNet

REKAYASA PERANGKAT LUNAK

By HendraNet PERANCANGAN ARSITEKTUR PERANGKAT LUNAK

• An abstract system specification consisting

primarily of functional components described in terms of their behaviors and interfaces and component-component interconnections . The interconnections define provide by which components interact.

By HendraNet

• How the system is decomposed and organized into components and must describe the

interfaces between these components.

• Gambaran bagaimana elemen/komponen

fungsional perangkat lunak disusun, diorganisasi dan distrukturkan sehingga:

 Hubungan antar elemen/komponen dapat dijelaskan.

 Interface yang menghubungkan elemen/komponen

By HendraNet

dapat didefinisikan.  Wujud dan penempatan elemen/komponen dalam

tempat penyimpanan sekunder secara fisik dapat ditetapkan.

Model Analisis (DFD level atomik)

id_mhs

Petugas

1.2.3 Cari Info

mahasiswa

info_mhs

Mahasiswa

Arsitektur Perangkat Lunak (Fisik) By HendraNet

call Script dan Procedure

query/select

Cari(NIM)

NIM :

Tabel Mahasiswa NIM Nama

Cari

Kelas

hasil query

display

Model Analisis (DFD level atomik)

1 Tambah

Bag ian

Data Barang

id_barang

Penjualan

Modul Pemanggil

rec _barang

id_s upplier

Barang rec _supplier

Arsitektur Perangkat Lunak

2 (Structure Chart)

rec _supplier

Tambah

Supplier

Data Supplier

Kelola Data

Induk

By HendraNet

Proses 2.0

Proses 1.0

Tambah Data

Barang

Supplier

id_barang

rec_barang

id_supplier

rec_supplier

supplier

Modul-modul atomik

(procedure, function)

Id_Barang

Barang

Id_Supplier

Supplier

• Diagram untuk menggambarkan arsitektur perangkat lunak secara keseluruhan

tanpa memperlihatkan proses pemilihan dan pengulangannya secara rinci.

• Menggambarkan arsitektur perangkat

By HendraNet

lunak seperti diagram organisasi sebuah perusahaan.

• Pemanggilan modul

• Data atau elemen kontrol yang dikirimkan

By HendraNet

atau diterima dari satu modul

• Pengulangan di dalam modul

• Penyeleksian kondisi di dalam modul

• Modul A memanggil modul

modul pemanggil

B dengan data x dan y

notasi untuk

parameter input

notasi untuk parameter

sebagai parameternya.

yang dikirimkan

x, y

p, q

output yang diberikan pada

kepada modul

modul pemanggil

• Modul B mengirimkan data

yang dipanggil

B modul yang dipanggil

p dan q sebagai return value ke modul A.

Procedure A; Var p, q : Real;

By HendraNet

Procedure B(x, y : Real);

Begin

p := ... { manipulasi nilai p }

Potongan kode program

q := ... { manipulasi nilai q }

dalam bahasa Pascal

End ;

Begin

B(x, y); { call procedure B } End ;

• Modul A akan memanggil

modul B jika kondisi dalam modul A dipenuhi.

• Modul A akan memanggil

modul C secara berulang .

Procedure C;

Begin

... By HendraNet End ;

Procedure B;

Potongan kode program

Begin

dalam bahasa Pascal ...

End ; Procedure A;

Begin

If True Then B; {call procedure B} While True Do C; {call procedure C}

End ;

FormInput.html

FormInput

... </html>

Rekam.php

Rekam

By HendraNet

// Rekam.php

function getId() { } function saveId(id) { }

getId

saveId

id = getId(); saveId(id) ?> id = getId(); saveId(id) ?>

unit main; ...

var

Form1: TForm1;

implementation

uses Rekam;

Main

procedure TForm1.Click(Sender: TObject);

begin

frmRekam.Show; end ;

By HendraNet

end.

Rekam

rekam.pas

unit Rekam; ...

var

frmRekam: TForm1;

implementation

... end.

• 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 modul untuk proses-proses pada DFD level-1 membutuhkan data atau event tertentu, tambahkan sebuah modul untuk

membaca data atau event tersebut. By HendraNet

• Ubah DFD level-2, 3, 4, dst. menjadi modul-modul lainnya sesuai dengan fungsinya dengan pendekatan

Transform Analysis dan atau Transaction Analysis.

Transform Analysis Transaction Analysis

By HendraNet

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.

 Pada umumnya suatu proyek adalah usaha satu waktu (one-time effort) . Maksudnya urutan kegiatan-kegiatan yang sama mungkin tidak terulang lagi di waktu yang

akan datang.

By HendraNet

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

Macam Perencanaan

 Perencanaan pembangunan nasional  Regional  Sektoral  Perncanaan personalia/tenaga kerja  Perencanaan peralatan

By HendraNet

 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. (2).Kegiatan-kegiatan yang harus dilakukan. (3).Urutan kegiatan.

By HendraNet

(4).Jangka waktu yang diperlukan oleh masing- masing. (5).Tersedianya alat ukuran/standar. (6).Memperhatikan contingency factor.

 CPM (Critical Path Method)  PERT (Project Evaluation and Review Technique)

Berguna untuk menyusun perencanaan, penjadwalan dan pengawasan/pengontrolan proyek

 PERT dan CPM pada dasarnya merupakan metode yang berorientasikan waktu, dalam arti bahwa keduanya

By HendraNet

akan berakhir dengan penentuan penjadwalan waktu (a time schedule) .

Perbedaan yang paling menonjol ialah perkiraan waktu yang diperlukan untuk melaksanakan kegiatan : deterministic dalam CPM , probabilistis dalam PERT

teknik penjadwalan proyek (project Shedulling technique)

By HendraNet

Shedulling technique)

Terdiri dari tiga tahapan yaitu : 1.Perencanaan,

2.Penjadwalan 3.Pengontrolan/pengawasan

By HendraNet

Tahapan perencanaan

 Dimulai dengan memecah/ menguraikan proyek menjadi kegiatan-kegiatan (activities).

 Perkiraan waktu, untuk kegiatan-kegiatan ini kemudian ditentukan dan diagram jaringan

kerja (network) yang dinyatakan dengan By HendraNet

gambar anak panah (arrow)

 Keseluruhan diagram anak panah memberikan suatu representasi grafis mengenai keterkaitan

antara berbagai kegiatan suatu proyek

Pembentukan diagram anak panah sebagai

tahapan perencanaan mempunyai tujuan : untuk mempelajari jenis pekerjaan yang berbeda secara rinci, mungkin dapat menimbulkan saran untuk perbaikan sebelum proyek dilaksanakan. Yang lebih penting lagi ialah kegunaannya untuk mengembangkan

By HendraNet

suatu jadwal untuk proyek (project schedulling ).

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 ) yang dapat dipergunakan ketika kegiatan tertunda atau kalau

sumberdaya yang terbatas dipergunakan secara efektif

(mencapai sasaran/tujuan yang dikehendaki). By HendraNet

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

Tahapan Pengawasan Meliputi penggunaan diagram anak

panah dan grafik waktu (time chart) untuk membuat laporan kemajuan secara periodik. Jaringan kerja (network) perlu diperbarui dan

By HendraNet

dianalisis dan kalau perlu suatu jadwal baru ditentukan untuk sisa bagian proyek yang belum selesai.

 Tiga tahapan proyek dimulai dengan

pembentukan diagram anak panah, cara penyajian data untuk grafik waktu dan cara mengalokasikan sumber yang terbatas berbagai

By HendraNet

kegiatan/ aktifitas .

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 arah kemajuan dalam proyek.

 Hubungan suatu kegiatan dengan kegiatan yang terjadi

sebelumnya ditunjukkan oleh adanya kejadian ( event ).

By HendraNet

 Yang dimaksud dengan kejadian ialah saat yang menggambarkan permulaan atau pengakhiran suatu kegiatan ( activity ),

 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 kegiatan itu dikerjakan. Setiap anak panah di ujung dan pangkalnya diberi tanda

By HendraNet

kejadian yang diberi nomor, seperti : kejadian yang diberi nomor, seperti :

 Kegiatan mulai dari kejadian 15 atau i dan berakhir dengan kejadian 16 atau j. untuk

selanjutnya kejadian A ditulis kegiatan A (15,16) atau kegiatan A(i,j), artinya dimulai pada titik i dan berakhir pada titik j. selanjutnya i disebut

By HendraNet

pangkal dan j ujung.

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.

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

By HendraNet

B dan C baru bisa dimulai kalau A sudah selesai.

 Kejadian (event) tidak memerlukan waktu, digambarkan sebagai lingkaran pada pangkal

anak panah (saat dimulainya kegiatan) dan pada ujung anak panah (saat akhir/selesainya kegiatan).

 Pemberian nomor pada kejadian harus memenuhi persyaratan yaitu nomor awal

By HendraNet

(pangkal) harus lebih kecil dari pada nomor akhir (ujung).

Untuk selanjutnya perhatikan aturan-aturan berikut :

1. Setiap kegiatan hanya boleh diwakili oleh satu anak panah saja didalam jaringan

kerja, (kecuali kalau satu kegiatan dipecah menjadi kegiatan yang lebih kecil).

2. Tidak boleh ada dua kegiatan diwakili oleh

pangkal dan ujung anak panah yang sama. By HendraNet

Dalam hal ini harus dipergunakan anak panah boneka (dummy arrow). Perhatikan ilustrasi berikut. Pangkal (1) dan ujung (2),

A dan B sama.

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.

By HendraNet

 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 dalam indikasi, seperti gambar di atas A (1,2), B (1,2), keduanya mempunyai indikasi yang sama, membingungkan. Lihat gambar a), b), c) dan d)

By HendraNet

untuk mengatasinya, di mana :

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

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

By HendraNet 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)

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

1. Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan L sedemikian rupa sehinga hubungan

berikut ini terpenuhi. 2. A, B, dan C kegiatan dalam suatu proyek yang bisa dimulai

secara serentak (simultan). 3. A dan B mendahului D.

By HendraNet

4. B mendahului E, F dan H. 5. F dan C mendahului G. 6. E dan A mendahului I dan J

7. C, D, F dan J mendahului K. 8. K mendahului L. 9. I, G dan L merupakan aktifitas terminal di proyek.

Jawab.

By HendraNet

 Contoh pembuatan diagram anak panah 2

1. Gambarkan diagram anak panah yang mencakup kegiatan A, B, C, ….., dan M sedemikian rupa sehinga hubungan berikut ini terpenuhi.

2. A dan B dapat dimulai secara serentak. 3. C dan D dapat dimulai kalau A sudah selesai. 4. E dapat dimulai kalau C sudah selesai. 5. G dapat dimulai kalau E sudah selesai. 6. F dapat dimulai kalau D sudah selesai. 7. H dapat dimulai kalau C, D, E, F dan G sudah selesai.

8. I dan J dapat dimulai kalau B sudah selesai. By HendraNet

9. K dapat dimulai kalau J sudah selesai. 10. L dapat dimulai kalau I, J, dan K sudah selesai. 11. M dapat dimulai kalau H dan L sudah selesai.

12. M kegiatan terminal .

By HendraNet

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

2. Proyek dimulai dari kegiatan A,

3. Kegiatan B dan C baru bisa dimulai kalau A sudah selesai.

4. Kegiatan D dan E baru bisa dimulai kalau C sudah selesai.

5. Kegiatan F dan G baru bisa dimulai kalau B sudah

By HendraNet

selesai.

6. Kegiatan H baru bisa dimulai kalau E sudah selesai.

7. Kegiatan I baru bisa dimulai kalau D sudah selesai.

8. Kegiatan J baru bisa dimulai kalau G dan H sudah selesai.

9. Kegiatan I dan J merupakan kegiatan terminal.

By HendraNet

ARTI DAN KEGUNAAN JARINGAN KERJA

ATAU NETWORK

 Kebaikan langsung yang dapat dipetik dari

pemakaian analisis Network adalah sebagai berikut :

1. Dapat mengenali (identifity) jalur kritis (critical path)dalam hal ini adalah jalur elemen-elemen kegiatan yang kritis dalam skala waktu penyelesaian proyek sebagai keseluruhan.

2. Mempunyai kemampuan mengadakan perubahan- By HendraNet

perubahan semberdaya dan memperhitungkan efek terhadap waktu selesainya proyek.

3. Mempunyai kemampuan memperkirakan efek-efek dari hasil yang dicapai suatu kegiatan terhadap keseluruhan rencana apabila diimplementasikan / dilaksanakan.

Keuntungan tidak langsung dari pemakaian network adalah sebagai berikut :

1. sebelum menyusun suatu network seorang analis harus mengkajirencana secara

keseluruhan, merinci dan mengurangi menjadi komponen-komponen kegiatan yang terpisah- pisah.

2. Seorang analis harus memikirkan interelasi dari

By HendraNet

kegiatan-kegiatan.

3. Seorang analis harus memperhitungkan batas waktu untuk mesing-masing unsur kegiatan,

sebab setiap kegiatan memerlukan sejumlah waktu tertentu untuk penyelesaiannya.

17 -Oct

MANAJEMEN PROYEK PERANGKAT -10 LUNAK

By HendraNet

1 SOFTWARE PROJECT MANAGEMENT

M ANAJEMEN ?

17 -O

 ct Kumpulan orang-orang dalam organisasi (

profesional/non profesioanal )

 Bersifat Kekuasaan, mengatur dan memerintah  Pengambilan keputusan dan deadline  Bersifat Strategis, Taktis dan teknis

By HendraNet

A PAKAH P ROYEK ITU ?

17 -O

 ct Definisi kamus bahwa Proyek adalah

perencanaan / perancangan yang spesifik atau

pekerjaan terencana atau pekerjaan yang besar (Longman Concise English Dictionary, 1982)

By HendraNet

A PAKAH PROYEK ITU ?

17 -O

– karateristik Proyek

Karakteristik ct

 Tugas non rutin

 Perlu perencanaan  Tujuan spesifik yang akan dicapai atau produk

spesisfik yang akan dibuat  Proyek harus ditentukan jangka waktu

By HendraNet

 Pekerjaan dikerjakan untuk seseorang bukan untuk diri kita

 Pekerjaan melibatkan beberapa spesialis  Sumber daya proyek yang tersedia dibatasi  Proyek itu pekerjaan besar / komplek

M ASALAH PROYEK PERANGKAT LUNAK

Masalah-masalah yang diidentifikasi oleh mahasiswa sistem komputer dan informasi yang telah menyelesaikan penempatan industri :

17 -O

 Spesifikasi pekerjaan yang kurang

ct -10

 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 By HendraNet

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

P ROYEK P ERANGKAT L UNAK V S T IPE P ROYEK L AIN

17 -O

Banyak teknik manajemen proyek umum yang ct

dapat diaplikasikan dengan MPLL, tapi menurut

Fred Brooks memberi catatan bahwa produk proyek perangkat lunak mempunyai

karakteristik tertentu.  Satu cara untuk melihat MPLL adalah sebagai

proses membuat visible dari invisible

By HendraNet

P ROYEK P ERANGKAT L UNAK V S T IPE P ROYEK L AIN

17 -O

Karakteristik MPPL ct

1. Tidak nampak

2. Komplek

3. Flexible

By HendraNet

F OKUS MPPL (MANAJEMEN PROYEK PERANGKAT LUNAK )

17 -O

ct -10

By HendraNet

M ANAJEMEN P ERSONEL ,P RODUK DAN P ROSES

17 -O

 ct Manajemen proyek perangkat lunak

mengatur 4 hal penting :

 Personel  Masalah (problem)  berkaitan dengan Produk  proses dan  Proyek  tambahan (tapi sangat penting)

By HendraNet

 Empat 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.

P ARADIGMA R EKAYASA P ERANGKAT L UNAK

By HendraNet

A RTI P ARADIGMA

 Berasal dari bahasa Yunani yang berarti suatu model, teladan, arketif dan ideal.

 Paradigma adalah suatu model dalam teori ilmu pengetahuan atau kerangka berpikir.

By HendraNet

A RTI R EKAYASA P ERANGKAT L UNAK

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

By HendraNet

SEBAGAI MODEL RAKAYASA PERANGKAT LUNAK

Waterfall model pertama kali diperkenalkan oleh Winston Royce tahun 1970. Waterfall Model merupakan model klasik yang sederhana dengan aliran sistem yang linier. Output dari setiap tahap merupakan input bagi tahap berikutnya.

By HendraNet

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

Gambar model waterfall

Requirements definition

System and software design

Implementation and unit testing

By HendraNet

Integr ation and system testing

Operation and maintenance

1. Requirment adalah tahap dilakukan analisa kebutuhan, kemudian diverfikasi klien dan tim SQA (Software Quantity Assurance). Specification adalah dokumentasi spesifikasi.

2. Design adalah tahap membagi kebutuhan- kebutuhan menjadi sistem perangkat lunak, dalam

tahap ini menghasilkan sebuah arsitektur keseluruhan perangkat lunak.

3. Implementation adalah tahap dimana kode-kode

program yang di buat di testing atau di uji. By HendraNet

4. Intergration adalah tahap dimana suatu perangkat lunak yang di buat diuji dan yakin menjadi suatu sistem yang lengkap dan memenuhi persyaratan perangkat lunak.

5. Operaton mode & Retirement, ini adalah tahap terpanjang. Sistem dipasang dan digunakan.

Pemeliharaan termasuk pembetulan kesalahan yang tidak ditemukan pada langkah sebelumnya.

By HendraNet

M ODEL S PIRAL DALAM REKAYASA PERANGKAT LUNAK

Pendekatan alternatif diusulkan oleh Boehm (1988). Boehm mengusulkan sebuah model yang secara explisit menjelaskan bahwa resiko yang disadari mungkin membentuk dasar model proses umum.

By HendraNet

Model yang di usulkan Boehm berbentuk spiral.

By HendraNet

S ETIAP LOOP DALAM MODEL INI MEWAKILI SEBUAH TAHAP DARI PROSES PERANGKAT LUNAK . T IDAK ADA TAHAP YANG TETAP DALAM MODEL INI . M ANAJEMEN HARUS MEMUTUSKAN BAGAIMANA MEMBENTUK PROYEK KE DALAM TAHAP - TAHAP . P ERUSAHAAN BIASANYA BEKERJA DENGAN BEBERAPA MODEL UMUM DENGAN TAHAP TAMBAHAN UNTUK PROYEK KHUSUS ATAU KETIKA

By HendraNet MASALAH - MASALAH DITEMUKAN SELAMA PEMBUATAN PROYEK .

S ETIAP L OP DIBAGI DALAM 4 SEKTOR SEBAGAI BERIKUT  Determine objectives (Menentukan Permasalahan)

 Risk Analysis (Analisis Resiko)  Engineering / develop (Melakukan proses rekayasa

perangkat lunak)  Plan next phase (Penentuan rencana-rencana untuk

tahap selanjutnya)

By HendraNet

P ADA IMPLEMENTASINYA , MODEL SPIRAL INI JUGA BANYAK DIGUNAKAN , TETAPI BIASANYA DIKOMBINASIKAN DENGAN YANG LAIN . P ERMODELAN WATERFALL , YANG SANGAT BAGUS DALAM MENENTUKAN MILLESTONES DAN PERMODELAN SPIRAL , YANG SANGAT BAGUS

By HendraNet DENGAN MENGGUNAKAN PROTOTYPING , MERUPAKAN KOMBINASI YANG SERING DIPAKAI DI DALAM KONTRAK - KONTRAK UNTUK PERANGKAT LUNAK .

B ILA TAHAPAN RISK ANALYSIS TIDAK DAPAT DILEWATI , MAKA PROSES DIHENTIKAN , TIDAK MENGIJINKAN PROSES KEMBALI KE TAHAPAN SEBELUMNYA . R ISK A NALYSIS YANG DILAKUKAN ADALAH :

• Project risk, mempengaruhi rencana proyek, contoh kekurangan sumber daya

• Technical risk, mempengaruhi tahap aktual, contoh : personil tidak terlatih di tahap tersebut

By HendraNet

• Bussines risk, mempengaruhi keinginan perusahaan untuk membuat software, contoh : software tidak diperlukan

P RIORITAS 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 luar perkiraan

 Marginal (ringan), contoh : penjadwalan yang terlambat

By HendraNet

 Negligible (tidak berarti), contoh : penggunaan waktu proyek tidak optimal

P ERBEDAAN MENDASAR ANTARA MODEL SPRILAL DENGAN MODEL LAINNYA ADALAH BAHWA MODEL SPIRAL DENGAN EKSPLISIT MENYADARI RESIKO - RESIKO YANG ADA . R ESIKO ADALAH KONSEP YANG SULIT DIDEFINISIKAN SECARA TEPAT . S ECARA INFORMAL RESIKO ADALAH SESUATU YANG SEDERHANA YANG DAPAT MENYEBABKAN KESALAHAN . C ONTOHNYA , JIKA BERTUJUAN

By HendraNet

MENGGUNAKAN PEMROGRAMAN BAHASA BARU ( NEW PROGRAMMING LANGUGE ), RESIKO YANG MUNGKIN ADALAH ALAT PENGUMPUL YANG DIGUNAKAN TIDAK RELIABLE DAN TIDAK MENGHASILKAN CODE OBYEK YANG EFISIEN .

U NTUK MENGGUNAKAN MODEL SPIRAL , B OEHM MENYARANKAN SEBUAH BENTUK UMUM YANG DIPENUHI DALAM SETIAP DAERAH SPIRAL . B ENTUK INI MUNGKIN DILENGKAPI PADA SEBUAH LEVEL ABSTRAK ATAU PERKIRAAN YANG IMBANG DARI PENGEMBANGAN PRODUK .

By HendraNet

DALAM R EKAYASA P ERANGKAT L UNAK

Model Incremental dalam rekayasa perangkat lunak, menerapkan rekayasa perangkat lunak perbagian, hingga menghasilkan perangkat lunak yang lengkap. Proses membangun berhenti jika produk telah mencapai seluruh fungsi yang diharapkan.

By HendraNet

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

 Requirement  Specification  Architecture Design

T AHAPAN - TAHAPAN TERSEBUT DILAKUKAN SECARA BERURUTAN . S ETIAP BAGIAN YANG SUDAH SELESAI DILAKUKAN TESTING , DIKIRIM KE PEMAKAI UNTUK LANGSUNG DAPAT

By HendraNet DIGUNAKAN . P ADA INCREMENTAL MODEL , TIGA TAHAPAN AWAL HARUS DISELESAIKAN TERLEBIH DAHULU SEBELUM TAHAP MEMBANGUN TIAP MODAL .

By HendraNet

U NTUK MENGANTISIPASI KONDISI YANG TERJADI PADA MODEL INCREMENTAL , DIPERKENALKAN MODEL M ORE R ISKY I NCREMENTAL M ODEL .M ODEL INI MENERAPKAN SISTEM KERJA YANG PARALEL . S ETELAH DAFTAR KEBUTUHAN DIDAPATKAN DARI PEMAKAI , TIM SPESIFIKASI MEMBUAT SPESIFIKASI UNTUK MODUL PERTAMA . S ETELAH SPESIFIKASI PERTAMA SELESAI , TIM

DESAIN MENINDAK LANJUTI . T IM SPESIFIKASI SEBELUMNYA

By HendraNet

JUGA LANGSUNG MEMBUAT SPESIFIKASI UNTUK MODEL KEDUA , DAN SETERUSNYA .

M ODEL M ETODOLOGI RAD

(R APID A PPLICATION D EVELOPMENT )

By HendraNet

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)

 RAD adalah model proses pembangunan PL yang incremental.  RAD menekankan pada siklus pembangunan yang pendek/singkat.

 RAD mengadopsi model waterfall dan pembangunan dalam waktu By HendraNet

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.

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 By HendraNet  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 interface harus tetap diuji. Page 87 / 224

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

By HendraNet

1. C LASSIC L IFE C YCLE P ARADIGMA

SISTEM ENGINEERING

A. Analisis

B. Perancangan

ANALYS

C. Pengkodean

DESIGN

D. Pengujian

E. Maintenance

CODE

By HendraNet

TESTING MAINTENANCE

2. B ERORIENTASI O BJEK

 Paradigma pembangunan perangkat lunak berbasis

bagaimana merepresentasikan dunia nyata ke dalam sebuah sistem sehingga pemecahan suatu masalah tidak dilihat dari cara menyelesaikan masalah tersebut tetapi dititikberatkan pada objek-objek

objek

adalah

apa sajakah yang dapat memecahkan masalah By HendraNet

tersebut.

3. P ROTOTYPE P ARADIGMA

 Prototyping paradigma dimulai dengan pengumpulan kebutuhan. Pengembang dan

dan mendefinisikan obyektif keseluruhan dari software,

pelanggan

bertemu

segala kebutuhan yang diketahui, dan area garis besar diman definisi lebih jauh

mengidentifikasi

By HendraNet

merupakan

kemudian dilakukan

keharusan

kilat”. Perancangan kilat berfokus pada

“perancangan

penyajian dari aspek – aspek software tersebut yang akan nampak bagi pelanggan atau pemakai (contohnya pendekatan input dan format output).

3. P ROTOTYPE P ARADIGMA

REQUIMENTS GATHERING

"QUICK DESIGN" BUILD PROTOTYPE

EVALUATED AND REFINEMENTS

By HendraNet

ENGINEER PRODUCT

4. T HE 4 TH G ENERATION T ECHNIQUE P ARADIGMA

 Istilah Fourth Generation Technique (4GT) meliputi seperangkat peralatan software yang memungkinkan seorang developer software menerapkan beberapa karakteristik software pada tingkat yang tinggi, yang kemudian menghasilkan source code dan object code secara otomatis sesuai By HendraNet dengan spesifikasi yang ditentukan developer.

4. T HE 4 TH G ENERATION T ECHNIQUE REQUIMENTS GATHERING P ARADIGMA

"DESIGN STRATEGICS" IMPLEMENTATION USING 4GT PRODUCT

By HendraNet

T UGAS !!

Buat Perbandingan tiap Model, dan penerpan kasus

By HendraNet

5. Build and Fixed

Perencanaan Proyek

Perencanaan PL & Manajemen Resiko

By HendraNet

Perencanaan Proyek Perangkat Lunak

 Tujuan : membuat kerangka kerja yang memungkinkan manajer membuat estimasi yang

dapat

mengenai sumberdaya, biaya & jadwal.Estimasi dibuat dengan kerangka waktu yang terbatas pada awal sebuah proyek PL & diperbaharui secara teratur selama

dipertanggungjawabkan

proyek berjalan. By HendraNet

 Why?

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

 Langkah Perencanaan PL:

 Scoping — memahami permasalahan dan apa yang harus dikerjakan

 Estimation —estimasi waktu? Estimasi SDM?estimasi PL/PK?  Risk — apa saja yang mungkin terjadi? Bagaimana

mengatasinya? Apa yang harus dilakukan untuk mengatasi resiko yang terjadi?

By HendraNet

 Schedule — bagimana mengalokasikan semua sumber daya sesuai dengan waktu yang telah ditentukan?

 Control strategy — bagaimana kualitas kontrol ?bagaimana mengkontrol segala sesuatu jika

terjadi perubahan?

 Bagaimana memahami lingkup PL/scope?

 Memahami kebutuhan customer  Memahami konteks bisnis yang ada  Memahami permasalahan proyek  Memahami motivasi customer terhadap PL yang

By HendraNet

akan dikerjakan  Memahami setiap bagian jika terjadi perubahan

 Sumber Daya Proyek

Manusia

By HendraNet

Komponen PL PK & PL

 Sumber Daya Manusia

 Dimulai dengan mengevaluasi lingkup serta memilih kecakapan

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

By HendraNet

 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, kode, desain atau

pengujian data yang sudah ada yang dikembangkan pada proyek yang lalu & serupa dengan proyek saat ini. Dimana setiap anggota tim memiliki pengalaman penuh pada bidang aplikasi

By HendraNet

sehingga modifikasi komponen resikonya relatif rendah

 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

 Komponen Baru : komponen PL yang harus dibangun oleh Tim

proyek untuk kebutuhan saat ini & berisiko tinggi

By HendraNet

 PL & PK

 PK menyediakan sebuah platform yang mendukung PL yang dibutuhkan untuk menghasilkan produk kerja yang merupakan

keluaran dari RPL yang baik

By HendraNet

Estimasi Proyek PL (Biaya & Usaha )

Estimasi sampai akhir proyek

Estimasi pada proyek-proyek yang mirip & sudah

dilakukan sebelumnya

By HendraNet

Estimasi dengan menggunakan teknik dekomposisi

Estimasi dengan menggunakan model empiris

 TeknikDekomposisi

 Dekomposisi Masalah  Dekomposisi Proses

functional decomposition

Statement

By HendraNet

of Scope

performa

parse "

 Dekomposisi Masalah

 Estimasi berdasarkan baris kode (LOC) & titik fungsi (FP).  Data LOC & FP digunakan dalam 2 cara :

 Sebagai variabel estimasi yang dipakai untuk mengukur masing-masing

elemen PL

 Sebagai Metrik Baseline yang dikumpulkan dari proyek yang lalu & By HendraNet

dipakai dalam hubungnya dengan variabel estimasi untuk mengembangkan proyeksi usaha & biaya

 Estimasi berbasis LOC

 Dimana fungsi PL diidentifikasi sbb:

 Interface pemakai & fasilitas kontrol (UICF)  Analisis geometri 2 dimensi (2DGA)  Analisis geometri 3 dimensi (3DGA)

 Manajemen database (DBM) By HendraNet

 Fasilitas tampilan grafiskomputer(CGDF)  Kontrol periperal (PC)  Modul analisis desain (DAM)

 Dekomposisi Proses

 Dengan perkiraan proses yang akan digunakan yaitu proses yang didekomposisi ke dalam serangkain aktivitas.tugas yang relatif

sangat kecil & usaha yang dibutuhkan untuk menyelesaikan masing-masing tugas yang diperkirakan.

By HendraNet

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.

By HendraNet

 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 program yang diekpresikan dalam baris kode yang diestimasi.

Proyek PL

By HendraNet a b b b c b d b

Organik

Semi-detached

Embedded

 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)  Mode Embedded : proyek PL yang harus dikembangkan ke dalam serangkaian PK

By HendraNet

 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

By HendraNet

Proyek PL

a i bi

Organik

Semi-detached

Embedded

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

By HendraNet

 Outsourcing

 Karena banyaknya area aplikasi PL, biaya dll, manajer PL dihadapkan pada keputusan make buy/outsourcing yaitu:

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

serta diintegrasikan sesuai dengan kebutuhan

 Custom built = PL dapat dibuat oleh pihak lain untuk memenuhi spesifikasi By HendraNet

pembeli

 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

penyampaian  Pilih 3 atau 4 calon aplikasi yang paling cocok dengan aplikasi anda

 Pilih komponen yang reusable yang dapat membantu konstruksi By HendraNet

aplikasi yang diperlukan

 Kembangkan sebuah matrik perbandingan yang menyajikan perbandingan dari fungsi-fungsi pokok & lakukan pengujian

untuk membandingkan calon PL  Evaluasi masing-masing paket PL/komponen berdasarkan kualitas produk sebelumnya, dukungan penjual, arah proyek, reputasi dll

By HendraNet

 Hubungi pemakai PL lain & mintalah pendapat mereka

 Analisa terakhir untuk memutuskan outsourcing sbb:

 Apakah tanggal penyampaian produk PL akan lebih cepat daripada PL yang dikembangkan internal?  Apakah biaya akuisisi ditambah biaya pemesanan akan lebih

kecil daripada biaya pengembangan PL internal?

By HendraNet

Apakah biaya dukungan luar (kontrak pemeliharaan) lebih rendah daripada biaya dukungan internal?

Manajemen Resiko

What can go wrong? What is the likelihood?

What will the damage be? What can we do about it?

By HendraNet

 Risk Management Paradigm

control track

RISK

By HendraNet

identify

plan analyze

 Macam Resiko :

 Risiko Proyek mengancam rencana proyek, berhub. Dengan

biaya, jadwal, SDM, pelanggan & masalah persyaratan PL  Risiko Teknik mengancam kualitas & ketepatan waktu PL yg dihasilkan, berhub. Dengan spesifikasi, keusangan

teknik, dll By HendraNet

 Risiko yang sudah diketahui , yaitu risiko yang dapat

diketahui setelah dilakukan evaluasi terhadap rencana proyek, bisnis, dl

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

 Pembangunan produk & sistem yang baik sekali yg tidak diinginkan

oleh pelanggan.  Pembangunan produk yang tidak sesuai dengan strategi bisnis

perusahaan  Pembangunan produk dimana bag. Pemasaran tidak tahu bagaimana

harus menjualnya.

By HendraNet

Kehilangan dukungan dari manajemen senior sehub. Dgn perubahan manusia

 Kehilangan hal-hal yg berhub. Dgn biaya

 Risiko yang dapat diramalkan dimana risiko ini diekstrapolasi dari pengalaman proyek sebelumnya

By HendraNet

Metode yang digunakan untuk mengidentifikasi Risiko adalah dengan checklist item risiko yang dibagi menjadi:

 Ukuran produk

 Ukuran database ?  Jumlah program, file, transaksi ?  Jumlah PL yang dipakai ?

 Pengaruh bisnis By HendraNet

 Pengaruh produk terhadap perusahaan ?  Penyelesaian produk?  Jumlah produk/sistem yang berhub. Dengan PL

yang dibangun? yang dibangun?

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

definisi Proses

 apakah dibutuhkan PL untuk membangun prototype PL?

 apakah metode spesifikasi yang digunakan? By HendraNet

Lingkungan pengembang

 Apakah pengujian dapat diperoleh & sesuai dengan produk yang

akan dibangun?  Apakah semua peranti saling terintegrasikan?

Teknologi pengembang & yang akan dibangun :

 Apakah diperlukan interface khusus untuk persyaratan produk?

 Apakah teknologi yang dipakai adalag teknologi baru? By HendraNet

Ukuran & pengalaman staf

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

By HendraNet

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.

o Menentukan backup staf, dll

Monitoring risiko

 Memonitor factor-faktor yang dapat memberikan indikasi terhadap

suatu risiko : hub. Interpersonal diantara tim, sikap umum tim By HendraNet

terhadap tekanan proyek, dll

Manajemen risiko  Jika usaha pencegahan sudah diupayakan ( backup ada, informasi terdokumentasi & pengetahuan telah disebarkan ke seluruh Tim) & ternyata gagal, maka diperlukan :

o Untuk anggota tim yang akan pergi untuk mentransfer pengetahuan pada anggota tim

pengganti By HendraNet

MATERI

1. Manajemen Resiko

2. Kualitas Perangkat Lunak

3. SQA

By HendraNet

Manajemen Resiko Perangkat Lunak

By HendraNet

Charette)

1. Resiko berhubungan dengan kejadian di masa yg akan datang.

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

3.Resiko melibatkan pilihan & ketidakpastian bahwa pilihan itu akan dilakukan.

By HendraNet

Strategi Resiko Reaktif vs Proaktif

Strategi Reaktif

Memonitor proyek yg berjalan terhadap kemungkinan resiko.

Strategi Proaktif

Dimulai sebelum kerja teknis diawali, dan By HendraNet

diprioritaskan menurut kepentingan, kemudian membangun suatu rencana untuk manajemen resiko. Sasaran utama adalah menghindari resiko.

Kategori resiko oleh Robert Charette

1. Resiko yang sudah diketahui ( pasti )

2. Resiko yang dapat diestimasi

3. Resiko yang tidak diharapkan

By HendraNet

Resiko Perangkat Lunak

Karakteristik resiko :

1. Ketidakpastian

2. Kerugian

Kategori resiko :

1. Resiko proyek ( Mou)

By HendraNet

2. Resiko teknis

3. Resiko bisnis ( Market)

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 :

1. Biaya

2. Sumber daya

By HendraNet

3. Jadwal

4. Pelanggan

5. Personil (staffing & organisasi)

6. Masalah persyaratan

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

Resiko teknis mengidentifikasi :

1. Desain-Perancangan By HendraNet

2. Coding

3. Spesifikasi

4. Interfacing

5. Ketidakpastian teknik

6. Verivikasi

7. Keusangan teknik

8. Masalah pemeliharaan

9. Teknologi

By HendraNet

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 yg baik sebenarnya tdk pernah diinginkan oleh setiap orang (resiko pasar)

2.Pembangunan sebuah produk yg tidak sesuai dgn keseluruhan strategi bisnis bagi perusahaan (resiko strategi)

3.Pembangunan sebuah produk dimana sebuah bagian By HendraNet

pemasaran tidak tahu bagaimana harus menjualnya. 4.Kehilangan dukungan manajemen senior sehubungan dg

perubahan pd fokus atau perubahan pd manusia (resiko

manajemen)

5.Kehilangan hal2 yg berhubungan dgn biaya atau komitmen personal (resiko biaya).

Resiko yg sudah diketahui

Adalah resiko yg dpt diungkap setelah dilakukan evaluasi secara hati2 terhadap rencana proyek, bisnis, & lingkungan teknik dimana proyek sedang dikembangkan, dan sumber informasi reliable lainnya.

seperti :

1. Tgl penyampaian yg tdk realitas

2. Kurangnya persyaratan yg terdokumentasi By HendraNet

3. Kurangnya ruag lingkup PL

4. Lingkungan pengembangan yg buruk

Resiko yg dapat diramalkan / Estimasi

Dazari pengalaman proyek sebelumnya. Misalnya :

1. Pergantian staf

2. Penggantian Resouce

By HendraNet

Identifikasi Resiko

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

Tujuan identifikasi resiko : untuk menghindari resiko bilamana mungkin,

serta menghindarinya setiap saat diperlukan.

By HendraNet By HendraNet

1. Resiko yg berhubungan dengan batasan yg dibebankan oleh manajemen atau pasar.

2. Bagian pemasaran dikendalikan oleh pertimbangan

bisnis, dan pertimbangan bisnis kadang mengalami konflik langsung dengan kenyataan teknis.

By HendraNet By HendraNet

Karakteristik pelanggan :

1. Pelanggan mempunyai keinginan yg berbeda.

2. Pelanggan memiliki kepribadian yg berbeda.

3. Pelanggan memiliki hubungan bisnis

By HendraNet

4. Pelanggan juga kadang-kadang bertentangan.

Komponen Resiko

1. Resiko kinerja – tingkat ketidakpastian dimana produk akan memenuhi persyaratannya dan cocok dgn penggunaannya.

2. Resiko biaya – tingkat ketidakpastian dimana biaya proyek akan dijaga

3. Resiko dukungan – tingkat ketidakpastian dimana PL akan mudah dikoreksi, disesuaikan dan ditingkatkan.

By HendraNet

4. Resiko jadwal – tingkat ketidakpastian dimana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.

Proyeksi / estimasi resiko

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

1 Membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan

2 Menggambar konsekuensi risiko

3 Memperkirakan pengaruh risiko pada proyek dan produk By HendraNet

4 Memcatat keseluruhan akurasi proyeksi proyek risiko sehingga akan tidak ada kesalahpahaman

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

2. Ruang lingkupnya - menggabungkan kepelikannya (seberapa seriusnya masalah ini ? ) dengan keseluruhan

By HendraNet

distribusi( berapa banyak proyek yg akan dipengaruhi atau berapa besa pelanggan terganggu ? )

3. Timingnya - mempertimbangkan kapan dan untuk berapa lama pengaruh itu dirasakan.

Faktor Yang Mempengaruhi

Kualitas Produk

By HendraNet

Penggunaan Waktu Seorang Programmer

Tabel aktivitas programmer (Bell Lab. Study, sampel : 70 programmer)

% WAKTU

AKTIVITAS

Penulisan program 13 Waktu Efektif