Evolusi Software

1ST 2ND 3RD 4TH

1950 1960 1970 1980 1990 2000

1. Tahun I

- Batch Orientation

Orientasi dimana sistem computer akan terlebih dahulu mengumpulkan data

yang akan diproses dalam satuan waktu tertentu.

- Limited Distribution’

Distribusi software hanya terbatas utk bbrp perusahaan saja

- Custom Software

Dikembangkan utk perusahaan perusahaan yang memintanya

2. Era Kedua

- Multi user

Dapat digunakan oleh beberapa user secara bersamaan / dalam satu waktu

- Real Time

Suatu system yang dapat mengumpulkan, menganalisa & mentransformasikan

data dari berbagai sumber, mengatur proses, dan menghasilkan output dalam
mili second (mili detik)

- Database

Kumpulan dari beberapa data yang disusun secara sistematis.

Dengan perkembangan media penyimpanan yang sangat pesat yang bersifat

online menyebabkan munculnya generasi pertama DBMS (Database
Management System).Product Sofware

Software mulai dikembangkan untuk memenuhi kebutuhan masyarakat.)

3. Era Ketiga

- Distributed System (Host Computer

 Suatu system yang tidak hanya dipusatkan pada computer induk saja (Host
Computer), daerah atau bidang lainnya yang juga memiliki computer yang
ukurannya lebih kecil dari computer induk.

- Embedded Inteleqence

Suatu produk yang diberi tambahan intelejen / kecerdasan yang membuat

seakan-akan computer kita bisa seperti otak manusia.

- Low Cost Hardware

Semakin rendahnya harga dari hardware memungkinkan munculnya software.

- Consumen Impact

Adanya hardware yang murah menyebabkan banyaknya software yang

dikembangkan, software ini memberikan dampak yang sangat besar terhadap
masyarakat. Maka muncullah yang namanya personal computer

*Ini merupakan tahap dari munculnya RPL (Rekayasa Perangkat Lunak)

4. Era Keempat

- Expert System

Merupakan suatu penerapan aktivisial intelijial, dimana suatu alat bisa

digunakan untuk mengerjakan suatu bidang.

- A.I Machine

Suatu mesin yang dapat meniru kerja otak manusia

- Pararel Architecture

Merupakan pararel arsitektur yang memungkinkan proses kerja local area

network pararel yang memungkinkan adanya prosesor berbeda dalam satu
computer.

PROCESS

Rekayasa perangkat lunak merupakan teknologi layer

1. Proses, metode & peralatan

TOOLS

METODE
PROCESS
A QUALITY FOCUS
 a. Proses merupakan pondasi dalam rekayasa perangkat lunak dengan proses,
memungkinkan untuk mengabungkan teknologi peralatan dan metode untuk
menyelesaikan rekayasa perangkat lunak.

b. Metode merupakan teknik yang digunakan untuk proses rekayasa perangkat

lunak.

Yang termasuk metode adalah :

- Analisa

- Desain

- Pembuatan program

- Testing & implementasi

- Maintenance

c. Tools/peralatan merupakan media yang digunakan untuk melaksanakan proses

rekayasa perangkat lunak.

Dengan adanya ketiga lapisan dalam RPL, hal ini dimaksudkan untuk mencapai
kualitas software yang baik.

Dalam pengembangan perangkat lunak terdapat beberapa pertanyaan yang

harus diperhatikan diantaranya:

- Problem apa yang akan dicarikan solusinya?

- Fungsi fungsi apa yang harus diimplementasikan dalam entitas (perangkat

lunak yg diinginkan)?

- Seberapa besar ruang lingkup dari masalah?

- Pendekatan apa yang dilakukan pada tahap desain agar sesuai dengan
keiinginan oleh user?

Secara umum ada 3 fase dalam RPL tanpa memandang besarnya masalah, kompleksitas
& ruang lingkup masalahnya ketiga fase tsb adalah:

- Identification phase : untuk mengidentifikasi seluruh masalah / mendefinisikan

bentuk2 desain yang akan dibuat algoritmanya.

- Development phase : mentranslasikan algoritma sebelumnya kebahasa

pemograman atau kode program

- Maintenance phase : melakukan testing dan implementasi serta perawatan

pada perangkat lunak.

Logika merupakan masa anak-anak dari matematika, sedangkan matematika

merupakan masa dewasa dari logika.
Logika tidak lepas dari filosolfi dan menghsilkan konsep yang dituangkan
dimatematika.

Komputer tersusun dari aritmatika dan logika sehingga computer tidak pernah
luput dari matematika.
 MODEL PROSES SOFTWARE

1. Linear Sequensial Model (Classic Life Cycle)

Merupakan model dengan pendekatan pengembangan software dimulai pada level

system dan prosesnya melalui :

a. Analisis

b. Design

c. Coding

d. Testing

e. Maintenance

Yang aktivitasnya :

1. Rekayasa dan pemodelan system / informasi

Pekerjaan dimulai dengan mengumpulkan semua kebutuhan elemen system.

Hal ini penting terutama pada saat system melakukan antar muka dengan
elemen lain seperti hardware, orang, dan database.

2. Analisa kebutuhan software

Untuk memahami program yang harus dibuat analis harus mengetahui domain
informasi untuk software tersebut seperti:

a. Fungsi (fungsi dari software itu sendiri)

b. Tingkah laku (tingkah laku dari software)

c. Kinerja (berhubungan dengan tingkat akuratsi)

d. Antar muka

3. Design

Design software ini sebenarnya merupakan proses beberapa tahap yang

difokuskan pada 4 atribut yang berbeda dari sebuah program yaitu :

a. Struktur data

b. Arsitektur software

c. Tampilan antar muka

d. Algoritma (prosedur) misalnya pseucode, flow chart, diagram konteks,

dll

4. Pembuatan program
 Merupakan proses translasi yang didasarkan pada design yang ada kebentuk
yang bisa dibaca oleh mesin,

5. Pengujian

Difokuskan pada :

a. Logika internal software (apkh sdh sesuai dgn prosedur yg dibuat, apakah
sudah baik?)

b. Fungsi eksternal test (diimplementasikan dgn beda mesin)

Untuk menguji jikalau terjadi kesalahan

6. Perawatan

Perubahan mesin mungkin terjadi setelah software diserahkan kecustomer.

Perubahan tersebut antara lain:

a. Terjadi error

b. Terjadi perubahan lingkungan eksternal

c. Kebutuhan peningkatan fungsional

d. Peningkatan kinerja.

Kelemahan pada linear sequensial :

1. Sukar bagi customer untuk secara detail mengemukakan semua kebutuhannya

(karena analis kebutuhan system).

2. Customer harus sabar

3. Developer sering menunda pekerjaan. Anggota team harus menunggu anggota

lainnya menyelesaikan tugasnya.

2. PROTOTYPE MODEL 1

Pada prototype model customer sering menjabarkan obejektif umum mengenai

software yang diminta, tetapi tidak bisa mendefinisikan input, proses, output yang
diminta secara detail.

Disisi lian developer menjadi tidak yakin terhadap efisiensi algoritma, kemampuan
adaptasi terhadap system oprerasi, atau bentuk interaksi mesin dengan orang.
Untuk mengatasi hal tersebut, bisa digunakan pendekatan.
 Prototype paradigm.

Listen to
customer

1.prototype paradigm dimulai dengan mengumpulkan kebutuhan-2 customer.

Developer dan customer bertemu dan mendefinisikan objektif software secara
menyeluruh, mengidentifikasi kebutuhan2 yang diketahui dari area pekerjaan.

2. setelah itu dibuat “Quick Design”. Quick design ditujukan pada representasi
aspek software yang bisa dilihat customer/user

3. pembuatan prototype dievaluasi customer/user dan digunakan untuk

menyempurnakan kebutuhan software yang akan dikembangkan.

Kelemahan :

1. Customer melihat prototype tersebut sebagai versi dari software

2. Development membuat implementasi yang kompromitas dengan tujuan untuk

memperoleh prototype pekerjaan secara cepat.

3. RAD (RAPID APPLICATION DEVELOPMENT)I

Merupakan model proses pengembangan software yang linear sequential yang

menggunakan siklus pengembangan yang singkat. Proses RAD memungkinkan
untuk membuat “Fully Functional System” dalam waktu yang sangat singkat (60-90)
hari.

Pendekatan model RAD dilakukan melalui beberapa fase al:

- Business Modeling

a. Informasi apa yang dibutuhkan proses bisnis tersebut?

b. Informasi apa saja yang dihasilkan?

c. Siapa yang membuat informasi tersebut?

d. Informasi itu dibutuhkan utk siapa saja?

 e. Siapa yang memproses informasi tersebut?

- Data Modelling

Aliran data yang telah didefinisikan disempurnakan lagi menjadi kumpulan

yobjek data yg dibutuhkan utk mendukung system tersebut / pembuatan
struktur data.

- Process Modeling

Objek data yang telah didefinisikan ditransformasii utk mendapatkan aliran

informasi yang mungkin mengimplementasikan fungsi bisnis / pembuatan
algoritma

Proses database : Menambah, menghapus, memodifikasi, mencari.

- Application Generation

Pekerjaan proses RAD dilakukan dengan menggunakan kembali

elemen2/komponen2 yang sudah ada sebelumnya.

- Testing & Turnover

Karena proses menggunakan RAD menggunakan kembali komponen yang

sudah ada maka beberapa komponen program telah teruji, hal akan
mengurangi waktu pengujian secara keseluruhan.

Kelemahan dari RAD:

1. Karena menggunakan waktu yang sangat singkat maka diperlukan SDM

yang banyak.

2. Development dan customer harus kompak

3. Model RAD tidak cocok pada saat resiko teknis tinggi

Konsep Manajemen Proyek
Dalam manajemen proyek software yang efektif difokuskan pada 3P, yaitu :

- People : pengerak atau orang yang menjalankan manajemen

- Problem

- Process : metode yang digunakan untuk pemecahan masalah

1. People (Sumber Daya Manusia / SDM)

Pada konsep manajemen RPL, SDM dikelompokkan atas 5 kelompokl:

a. Senior managers / analis system

Merupakan orang-orang yang mendefinisikan isu bisnis yang sangat

berpengaruh pada proyek.

Bisnis adalah kegiatan / aktivitas proyek yang sedang dibuat.

b. Project (Technical) manajers/ system programmer

Merupakan orang yang merencanakan, memodifikasi, mengorganisasi, dan

mengontrol.

Para praktisi yang menjalankan pekerjaan proyek software.

c. Practioners / programmer

Orang memiliki keahlian teknis yang dibutuhkan untuk merekayasa sebuah

produk atau aplikasi.

d. Customer

Merupakan orang yang menyatakan kebutuhan akan rekayasa software

e. End User

Merupakan orang yang berorentasi dengan software setelah software

diproduksi

2. Model Kepemimpinan

Dalam manajemen proyek RPL terdapat 3 model kepemimpinan yaitu :

a. Motivation

Merupakan model kepemimpinan dimana seorang pemimpin mampu untuk

membangkitkan kemampuan teknis anggota tim untuk menghasilkan yang
terbaik.
 b. Organization

Yaitu kemampuan seorang pemimpin untuk mengelola sumber daya yang ada
( atau menemukan sebuah yang baru ) untuk menerjemahkan suatu konsep
menjadi hasil akhir.

c. Ideal atau Innovation

Kemampuan untuk membangkitkan kreasi anggota

3. Karakteristik manajer proyek

Karakteristik manajer proyek yang efektif antara lain :

- Problem Solving  mampu menyelesaikan masalah

- Manajerial Identity  mampu mengidentifikasikan seluruh kebutuhan dalam

rekayasa perangkat lunak

- Achievement  kemampuan / bagaimana manajer proyek mencapai target

- Influence & Team Building  mampu membangun sebuah team yang

kompak

4. Organisasi team software

Secara umum ada 3 macam organisasi team software :

- Democratic Decentralized

Team software ini tidak memiliki pemimpin yang permanen atgau tetap.
Koordinasi ditunjuk untuk jangka pendek & kemudian diganti dengan yang
lainnya, yang mampu mengkoordinasi tugas yang berbeda.

Pengambilan keputusan dilakukan melalui consensus kelompok. Komunikasi

antar anggota team dilakukan secara horizontal.

- Control Decentralized

Team rekayasa software menunjuk seorang leader yang mengkoordinir tugas-

tugas tertentu dan secondary leader yang bertanggung jawab atas sub-sub
pekerjaan. Pemecahan solusi permasalahan dilakukan secara kelompok akan
tetapi implementasi solusi dibagi ke sub-sub kelompok oleh team leader.

Komunikasi antara sub kelompok atau individu dilakukan secara horizontal dan
juga vertical sesuai dengan interaksi kendali.

- Control Centralized
 Solusi permasalahan dan kombinasi team internal diatur oleh team leader

Komunikasi antara leader dan anggota team dilakukan secara vertical

Ada tujuh factor yang perlu dipertimbangkan pada soal merencanakan

struktur team rekayasa software.

1. Tingkat kesulitan problem yang harus diselesaikan

2. Ukuran program (line of code)

3. Tingkat problem yang bisa dimodulkan

4. Waktu team bisa bekerja bersama – sama

5. Kualitas sistem yang akan dibuat

6. Tanggal penyerahan software yang akan ketat

7. Tingkat komunikasi yang diperlukan untuk proyek

Tabel pengaruh karakteristik proyek pada struktur team.

Line of Code

Tipe Tim DD CD CC

• Difficult High x

Low x x

• Size Large x

Small x x

• Modularity High x x

Low x

• Life Time Long x x

Short x

• Qualitiy High x x

Low x

• Delivery date Strict x

 Lan x x

• Sociability High x

Low x x

Aktivitas manajemen proyek yang pertama adalah menentukan batasan software.

Batasan tersebut dapat diperoleh dengan menjawab pertanyaan sbb:

1. Konteks, bagaimana software dibuat untuk memenuhi system yang lebih besar,
produk atau bisnis konteks. Dan kendala yang ditimbulkan akibat konteks
tersebut.

2. Information objective, apa saja objek data yang customer visible dihasilkan
sebagai output dari software , apa saja objek data yang diperlukan untuk input
(data primer dan data sekunder).

Data primer berasal dari sumber, data sekunder berasal dari media.

3. Function & performance, fungsi apa saja yang harus dilakukan software untuk
mentrasformasikan data input menjadi output, apakah terdapat performance
karakter khusus yang diminta customer. Misalnya ketika pembuatan suatu
program disuruh dilengkapi dengan kalkulator.

Batasan proyek software harus jelas dan mudah dipahami pada level manajemen dan
teknik. Yang harus dijelaskan pada batasan tersebut antara lain :

1. Kuantitatif data, misalnya jumlah user yang bekerja, ukuran mailing list,
maksimum waktu respon yang diperbolehkan . misalnya pemakaian multi user
(semakin byk user, semakin mahal), kapasitas dari yahoo mail, dan system
pengamanan data.

2. Konstrain dan atau keterbatasan misalnya biaya produksi membatasi ukuran

memori

3. Factor mitigasi (algoritma yang mudah dipahami)

Yaitu proses dimana mentransformasi semua proses2 kedalam algoritma sehingga

lebih mudah dipahami.

 bhn akhir uts.

PERENCANAAN PROYEK SOFTWARE

Proses manajemen proyek software dimulai dengan sekumpulan aktivitas yang
disebut “PROJECT PLANNING” (Perencanaan Proyek).
Pada perencanaan proyek aktivitas pertama yang dilakukan adalah “ESTIMATION”.
(Estimasi)

Estimasi = perkiraan / pengumpulan ( bisa terhadap sumber daya, biaya, dan

jadwal)

1. Observasi terhadap estimasi

Kegiatan-kegiatan yang dilakukan pada tahap observasi terhadap estmasi

diantaranya adalah :

a. Estimasi sumber daya, biaya, dan jadwal pengembangan software yang

memerlukan : pengalaman, akses historis yng baik, serta keberanian untuk
konsisten terhadap pengukuran kuantitatif pada saat data kuantitatif tsb
ada.

b. “Project complexity”= tingkat kesulitan dari sebuah program, mempunyai

pengaruh yang kuat terhadap ketidak pastian perencanaan.

c. “Project Size”= ukuran dari sebuah proyek. Merupakan factor penting

lainnya yang dapat mempengaruhi ketepatan estimasi

d. “Problem Decomposition” = masalah yang akan dipecahkan. Merupakan

pendekatan yang penting untuk estimasi

e. Tingkatan “Structural Uncertainly” juga berpengaruh terhadap resiko

estimasi. Struktur dalam hal ini adalah tingkatan kebutuhan, kemudahan
fungsi yang akan dihasilkan dan informasi yang harus diproses.

f. Informasi historis juga berpengaruh terhadap resiko estimasi. Dengan

mengetahui data-data yang lalu kita dapat mengoptimalkan pekerjaan dan
menghindarkan hal-hal yang menimbulkan persoalan.

g. Resiko diukur berdasarkan tingkatan ketidakpastian estimasi terhadap

estimasi sumber , daya, biaya, dan jadwal. Jika batasan tidak jelas dan
kebutuhan proyek senantiasa berubah, maka hal ini bisa menimbulkan
dampak yang membahayakan.

2. Ruang LIngkup Software

Selain estimasi terhadap sumber daya, biaya, dan jadwal, hal lain yang akan
dilakukan dalam perencanaan adalah menentukan ruang lingkup / batasan
software. Diantaranya :

a. Function

Menjelaskan ruang lingkup yang dievaluasi. Estimasi sumber daya biaya dan
jadwal berorientasi fungsionl.

b. Performance
 Mempertimbangkan proses yang harus dilakukan dan waktu respon yang
diperlukan.

c. Constraint

Mengidentifikasi keterbatasan software terhadap perangkat keras eksternal,

memori maupun terhadeap sistem lainnya yang sudah ada

d. Interfaces

e. Reliability

ESTIMASI SUMBER DAYA

Tugas kedua perencanaan software adalah estimasi sumber daya yang diperlukan untuk
pengembangan software

PEOPLE

RELIABLE SOFTWARE COMPONENT

HARDWARE & SOFTWARE TOOLS

*Reusable Software Component merupakan software yang sudah ada sebelumnya yang
mendukung software yang akan kita kembangkan.

1. HUMAN RESOURCE

Perencanaan mulai evaluasi scope dan memilih keahlian yang dibutuhkan untuk
pengembangan. Perencanaan harus menentukan posisi organisasional dan
speciality.

Untuk proyek yang relative kecil (6 person-month/<6) seseorang bisa melaksanakan

semua tahapan rekayasa software, konsultasi dengan spesialis pada saat
dibutuhkan.

Jumlah orang yang dibutuhkan untuk sebuah proyek software bisa ditentukan setelah
adanya estimasi usaha dan pengembangan.

2. REUSABLE SOFTWARE RESOURCE

Ada 3 kategori software resource yang bisa dipertimbangkan pada perncanaan :

a. Off The Self Component

 Existing software yang telah dibuat untuk pihak ktiga atua yang telah
dkembangkan secara internal pada proyek sebelum yang mirip dengan software
yang akan dibuat.

Modifikasi yang diperlukan pada full experienced component beresiko relative

rendah.

b. Partial Experience Component

Spesifikasi, desain, kode atau data test yang telah dikembangkan pada proyek
sebelumnya berkaitan dengan software yang akan dikembangkan, akan tetapi
memerlukan modifikasi. Substansinya, anggota tim softwarenya mempunyai
pengalaman yang terbatasw pada area aplikasi tersebut. Maka modifikasi pada
partial experience component beresiko.

c. New Component

Komponen software yang harus dibuat oleh tim sesuai denga kebutuhan proyek

3. ENVIRONMENT REUSEABLE PROJECT

Lingkungan yang mendukung software disebut software Envi Engineering (SEE) baik
hardware maupun software. Perencanaan proyek software harus memperhatikan
batasan waktu yang dibutuhkan hardware & software dan memverifikasi resource-
resource yang bisa dimanfaatkan.

MANAJEMEN RESIKO

1. PENDAHULUAN

Pada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi
berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau
pengeluaran biaya pengembangan yang melebihi anggaran. Hal ini dikarenakan
kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi
untuk itu perlu diidentifikasikan tindakan yang harus dilakukan untuk mencegah
ataupun meminimalisasikan resiko.

Beberapa resiko lebih penting dibandingkan resiko lainnya. Baik penting maupun
tidak sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya
pada aktifitas tertentu dan kekritisan aktifitas tersebut. Aktifitas beresiko tinggi pada
jalur kritis pengembangan biasanya merupakan penyebabnya.

Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan
resiko atau paling tidak mendistribusikannya selama pengembangan tersebut dan
baiknya resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis.
Resiko dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada
siapa yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi
resiko dan alokasi staf dan sumber daya lainnya erat kaitannya.

2. Tipe Resiko

Untuk keperluan identifikasi dan mengelola resiko yang bisa menyebabkan sebuah
pengembangan melampui batas waktu dan biaya yang sudah dialokasikan maka
perlu diidentifikasi tiga tipe resiko yang ada.

a. Resiko yang disebabkan karena kesulitan melakukan estimasi (kesalah estimasi).

Beberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan

lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau
lainnya disebabkan karena jenis pekerjaan tersebut. Pembuatan user manual bukti
bahwa kit pernah mengerjakan tugas yang serupa sebelumnya. Dengan pengalaman
itu seharusnya kita mampu melakukan estimasi dengan lebih tepat mengenai
sumber daya, biaya dan jadwal.

Selain itu waktu yang dibutuhkan untuk melakukan pengujian dan penulusuran
program dapat menjadi susuatu hal yang sulit diprediksi dengan tingkat keakuratan
yang serupa walaupun kita pernah membuat program yang serupa.

Estiminasi dapat ditingkatkan melalui analisa data histories untuk aktifitas yang
serupa dan untuk sistem yang serupa dengan menyimpan perbandingan antara
estimasi awal dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit
diestimasi secara tepat.

b. Resiko yang disebabkan karena asumsi yang dibuat selama proses perencanaan
(Asumsi Perencanaan)

pada setiap tahapan perencanaan , asumsi perlu dibuat jika tidak benar maka
dapat mengakibatkan resiko tersebut. Beresiko misal lpada jaringan aktifitas,
aktifitas dibangun berdasarkan pada asumsi menggunakan metodologi desain
tertentu dimana memungkinkan urutan aktifitas, aktifitas dibangun berdasarkan
pada asumsi menggunakan metodologi desain tertentu dimana memungkinkan
urutan aktifitas berubah.

Pada setiap tahapan perencanaan sangat penting untuk memperinci secara

eksplisit semua asumsi yang dibuat dan mengidentifikasi apa pengaruhnya jika
ternyata dalam pelaksanaannya tidak sesuai dengan yanag sudah direncanakan.

Cth : utk pembuatan program, sesudah coding qta membuat modul, sebelum
modul digabungkan setiap modul mesti diuji (maka saat pengujian mungkin ada
yg akan diubah dan tidak sesuai dengan jalur)
c. Resiko yang disebabkan adanya even yang tidak terlilhat (kemungkinan).

Beberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat
menyakinkan diri kita bahwa ada sesuatu yang tidak dapat dibayangkan kadang-
kadang dapat terjadi. Beberapa kejadian semacam ini dapat terjadi sewaktu-
waktu walau kemungkinan relative kecil. Akan tetapi kejadian tersebut perlu
dipertimbangkan dan direncanakan.

Cth : biaya yang muncul secara tidak terduga atau tidak terbayangkan
sebelumnya. Lea.der yang sakit

Nb: Resiko ada kejadian yang tidak direncanakan.

TEKNIK MEGELOLA RESIKO

Objektif manajemen resiko adalah mencegah atau meminimalisasi pengaruh yang

tidak baik akibat kejadian yang tak terduga melalui menghindari resiko atau
mempersiapkan rencana yang berkaitan dengan resiko tersebut.

Model manajemen resiko dibedakan menjadi dua komponen utama yakni

identifikasi resiko dan manajemen resiko. Pada gambar 2 dibawah ini
memperlihatkan sebuah struktur yang memerinci aktifitas yang disebut oleh Barry
Boehm dengan rekayasa resiko.

0.Memilih pengembangan

1.Identifikasi ruang lingkup dan 2.Identifikasi Infrastruktur

objektif pengembangan pengembangan

3.Analisa karakteristik pengembangan

4.Identifikasi Produk dan Aktifitas

5.Estimasi Sumber Daya & Aktifitas

6.Identifikasi Resiko

7.Alokasi Sumber Daya

8.Mengevaluasi / mempublikasikan Perencanaan

9.Eksekusi Rencana

10.Perencanaan yang lebih Detail

Gambar 1. Struktur Aktivitas RPL

 Risk
Engineering

Risk Analisys Risk Management

Risk Risk Risk Risk Risk Risk Risk Risk

Identification
EstimationEvaluation Planning Control Monitoring Directingg Staffing

1. Risk identification, menjelaskan daftar semua resiko yang dapat

mempengaruhi keberhasilan pelaksanaan pengembangan

2. Risk Estimation, menjelaskan semua kemungkinan dan pengaruh yang akan

terjadi pada masing-masing resiko.

3. Risk Evaluation, menjelaskan tingkat resiko dan menentukan strategi

menghindari resiko

4. Risk Planning, menjelaskan rencana dan dimana rencana tersebut yang paling
tepat dipergunakan, menambahkan rencana tersebut pada struktur aktivitas
pengembangan tersebut.

5. Risk Control, berhubungan dengan fungsi utama manajer resiko untuk

meminimalisasikan dan mengambil tindakan jika terjadi persoalan selama
pengembangan

6. Risk Monitoring, harus menjadi sebuah aktifitas yang dijalankan karena jika
terjadi resiko dapat mengubah aktifitas pengembangan

7. Risk Direct & Staffing, berkaitan dengan manajemen resiko sehari-hari strategi
mencegah resiko dan menyelesaikan masalah sering melibatkan staf untuk itu
harus direncanakan dan diarahkan.

IDENTIFIKASI RESIKO

Tahapan pertama dalam melakukan analisis adalah mengidentifikasikan bahaya

yang dapat mempengaruhi waktu dan sumber daya pembiayaan pengembangan
tersebut. Yng dimaksud bahaya adalah suatu keadaan yang dapat dan akan
terjadi dan jika keadaan muncul dapat menciptakan masalah terhadap
keberhasilan penyelesaian pengembangan.

Sebuah cara umum untuk mengidentifikasikan bahaya adalah dengan

mempergunakan daftar checklist yang berisi semua kemungkinan. Bahaya yang
bisa terjadi dan factor yang mempengaruhinya.
Beberapa bahaya tersebut merupakan generic risk yang berarti bahwa bahaya
tersebut relevan untuk semua pengembangan perangkat lunak dan standar
checklist dapat dipergunakan berdasar hasil analisis pengembangan sebelumnya.
Dan checklist tersebut juga berisikan spesifik risk yang relevan untuk
pengembangan tertentu. Beberapa factor yang perlu dipertimbangkan untuk
mengidentifikasi resiko adalah :

1. Application factors  sesuatu yang alami dari aplikasi / spesifikasi software

2. Staff factors  teliti dalam pengkategorian & pemilihan staff (mis :

pengalaman)

3. Projec factors  keseluruhan project diberitahukan kpd slrh team

4. Project methods  seluruh estimasi direncanakan dengan manajemen yg scr

terstruktur

5. Hardware / software factors  penentuan hardware & software (memberikan

pengaruh yang lebih signifikan)

6. Changeover factors  pengembangan perangkat lunak atas aplikasi yang

sudah ada dengan perubahan secara keseluruhan atas aplikasi yg sudah
dipergunakan sebelumnya

7. Supplier factors  organisasi eksternal yg tidak dapat dikendalikan. Misalny

pengiriman pemesanan yg telat.

8. Environment factors Permasalahan perbedaan gaji antar wilayah dll

9. Health & safety factors kesehatan & keselamatan kerja. Mis : sipil

ANALISIS RESIKO

Setelah resiko teridentifikasi maka diperlukan cara untuk menentukan tingkat

kepentingan dari masing-masing resiko. Beberapa resiko secara relative tidak
terlalu fatal sedangkan beberapa resiko lainnya berdampak besar. Beberapa
resiko sering terjadi sementara resiko lainnya jarang.

Probabilitas terjadinya resiko disebut dengan likelihood, sedangkan dampak yang

akan terjadi akibat resiko tersebut disebut risk impact, dan tingkat kepentingan
resiko disebut dengan risk value atau risk exposure. Risk value dapat dihitung
dengan formula :

Risk exposure = risk likelihood x risk impact

 Idealnya risk impact diestimasi dalam batas moneter (biaya) dan likelihood
sebagai sebuah probabilitas. Dalam hal ini risk exposure akan menyatakan
besarnya biaya yang dperlukan berdasarkan perhitungasn analisis biaya manfaat .

Beberapa manajer resiko mempergunakan sebuah metode penilaian yang

sederhana untuk menghasilkan ukuran yang kuantitatif pada saat mengevaluasi
masing-masing resiko. Beberapa manajer memberikan kategori high medium dan
low pada likelihood dan impact. Akan tetapi ini tidak memungkinkan untuk
menghitung risk exposure. Sebuah pendekatan yang lebih baik dan popular
adalah memberikan skor pada likelihood dan impact dengan skala 1-10. Jika suatu
resiko kemungkinan besar akan terjadi diberi skor 10 dan sebaliknya.

Hasil pengukuran impact dapat diukur dengan skor yang sama, harus dimasukkan
pada perhitungan total risk dari proyek tersebut. Untuk itu harus melibatkan
beberapa biaya potensial :

1. Biaya yang diakibatkan keterlambatan penyerahan atas jadwal yang sudah

ditentukan

2. Biaya yang berlebihan dikarenakan harus menambah sumber daya atau

mempergunakan sumber daya yang lebih mahal.

3. Biaya yang tidak terlihat pada beberapa komponen kualitas atau fungsionalitas
sistem

Berikut ini memperlihatkan contoh tabel hasil evaluasi niali resiko

Resiko Uraian L I R

R1. Perubahan spesifikasi kebutuhan selama coding 1 8 8

R2. Spesifikasi perlu lebih lama dibandingkan yang diperlukan 3 7 21

R3. Staf sakit yang berpengaruh pada aktivitas yang kritis 5 7 35

R4. Staf sakit yang berpengaruh pada aktivitas yang tidak kritis 10 3 30

R5. Pengkodean modul lebih lama dibandingkan dengan yang diharapkan 4 5

20

R6. Pengujian modul memperlihatkan kesalahan atau ketidak efisien dalalm desain
1 10 10

Nb : L= Likelihood

I = Impact
 R= risk Exposure

PRIORITAS RESIKO

Risk exposure = risk likelihood x risk impact

Pengelolaan resiko melibatkan penggunaan 2 strategi :

1. Risk Exposure dapat dikurangi dengan mengurangi risk likelihood dan risk impact

2. Pembuatan rencana berkaitan dengan kemungkinan resiko yang akan terjadi.

Estimasi nilai likelihood dan impact dari masing-masing usaha akan menentukan
nilai risk exposure. Setelah risk exposure dapat dihitung maka resiko dapat
diberi prioritas high, medium dan low sesuai dengan besar kecilnya nilai risk
exposure.

Dalam kenyataan, secara umum ada beberapa factor lain, selain nilai risk
exposure, yang harus dperhitungkan pada saat menentukan prioritas resiko :

1. Kepercayaan terhadap penilaian resiko  sikap terhadap resiko yg sdh

diperhitungkan

2. Penggabungan resiko  kemungkinan keseluruhan resiko

3. Jumlah resiko  kemungkinan keseluruhan resiko utk dibatasi

4. Biaya tindakan  biaya yg dikeluarkan utk memperbaiki sbh resiko

5. Apa yang dimaksud dengan rekayasa perangkat lunak? dan jelaskan sejarah
rekayasa perangkat lunak!

Rekayasa perangkat lunak (RPL, atau dalam bahasa Inggris: Software Engineering
atau SE) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak
termasuk pembuatan, pemeliharaan, manajemen organisasi pengembanganan perangkat lunak
dan sebagainya

1945 - 1965: Awal

Istilah software engineering digunakan pertama kali pada akhir 1950-an dan awal 1960-an.

Pada tahun 1968 dan 1969, komite sains NATO mensponsori dua konferensi tentang rekayasa perangkat lunak,
Dua konferensi inilah yang menandai awal resmi profesi rekayasa perangkat lunak.

1965 - 1985: krisis perangkat lunak

Pada tahun 1960-an hingga 1980-an, banyak masalah yang ditemukan para praktisi pengembangan perangkat
lunak. Banyak projek yang gagal, hingga masa ini disebut sebagai krisis perangkat lunak.. Salah satu kasus yang
terkenal antara lain meledaknya roket Ariane akibat kegagalan perangkat lunak.

1985 - kini: tidak ada senjata pamungkas

Selama bertahun-tahun, para peneliti memfokuskan usahanya untuk menemukan teknik jitu untuk memecahkan
masalah krisis perangkat lunak.

Berbagai teknik, metode, alat, proses diciptakan dan diklaim sebagai senjata pamungkas untuk memecahkan
kasus ini.

Sebagian berpendapat, no silver bullet berarti profesi rekayasa perangkat lunak dianggap telah gagal. Namun
sebagian yang lain justru beranggapan, hal ini Penandaan bahwa bidang profesi rekayasa perangkat lunak telah
cukup matang, karena dalam bidang profesi lainnya pun, tidak ada teknik pamungkas yang dapat digunakan
dalam berbagai kondisi.

1. Jelaskan karakteristik software dan sebutkan contoh produk software!

Tidak aus, tetapi bisa rusak

Tidak bisa dirakit

TIdak bisa dipabrikasi

Tidak dapat stand alone

Cth : operasi sistem, program language, program utilitas, command program.

2. Jelaskan evolusi sosftware!

1ST 2ND 3RD 4TH

1950 1960 1970 1980 1990 2000

a. Tahun I

- Batch Orientation
 Orientasi dimana sistem computer akan terlebih dahulu mengumpulkan data
yang akan diproses dalam satuan waktu tertentu.

- Limited Distribution’

Distribusi software hanya terbatas utk bbrp perusahaan saja

- Custom Software

Dikembangkan utk perusahaan perusahaan yang memintanya

b. Era Kedua

- Multi user

Dapat digunakan oleh beberapa user secara bersamaan / dalam satu waktu

- Real Time

Suatu system yang dapat mengumpulkan, menganalisa & mentransformasikan

data dari berbagai sumber, mengatur proses, dan menghasilkan output dalam
mili second (mili detik)

- Database

Kumpulan dari beberapa data yang disusun secara sistematis.

Dengan perkembangan media penyimpanan yang sangat pesat yang bersifat

online menyebabkan munculnya generasi pertama DBMS (Database
Management System).

- Product Sofware

Software mulai dikembangkan untuk memenuhi kebutuhan masyarakat.

c. Era Ketiga

- Distributed System (Host Computer

Suatu system yang tidak hanya dipusatkan pada computer induk saja (Host
Computer), daerah atau bidang lainnya yang juga memiliki computer yang
ukurannya lebih kecil dari computer induk.

- Embedded Inteleqence

Suatu produk yang diberi tambahan intelejen / kecerdasan yang membuat

seakan-akan computer kita bisa seperti otak manusia.

- Low Cost Hardware

Semakin rendahnya harga dari hardware memungkinkan munculnya software.

- Consumen Impact
 Adanya hardware yang murah menyebabkan banyaknya software yang
dikembangkan, software ini memberikan dampak yang sangat besar terhadap
masyarakat. Maka muncullah yang namanya personal computer

*Ini merupakan tahap dari munculnya RPL (Rekayasa Perangkat Lunak)

d. Era Keempat

- Expert System

Merupakan suatu penerapan aktivisial intelijial, dimana suatu alat bisa

digunakan untuk mengerjakan suatu bidang.

- A.I Machine

Suatu mesin yang dapat meniru kerja otak manusia

- Pararel Architecture

Merupakan pararel arsitektur yang memungkinkan proses kerja local area

network pararel yang memungkinkan adanya prosesor berbeda dalam satu
computer.

3. Bagaimana rekayasa perangkat lunak dikatakan sebagai teknologi layer dan

jelaskan layer dalama RPL !

Rekayasa perangkat lunak merupakan teknologi layer

Proses, metode & peralatan

TOOLS

METODE
PROCESS
A QUALITY FOCUS

a. Proses merupakan pondasi dalam rekayasa perangkat lunak dengan proses,

memungkinkan untuk mengabungkan teknologi peralatan dan metode untuk
menyelesaikan rekayasa perangkat lunak.
 b. Metode merupakan teknik yang digunakan untuk proses rekayasa perangkat
lunak.

Yang termasuk metode adalah :

- Analisa

- Desain

- Pembuatan program

- Testing & implementasi

- Maintenance

c. Tools/peralatan merupakan media yang digunakan untuk melaksanakan proses

rekayasa perangkat lunak.

Dengan adanya ketiga lapisan dalam RPL, hal ini dimaksudkan untuk mencapai
kualitas software yang baik.

4. Yang termasuk metode dalam rekayasa perangkat lunak adalah analisa, design,
pembuatan program, pengujian dan perawatan, jelaskan!

a. Analisa kebutuhan software

Untuk memahami program yang harus dibuat analis harus mengetahui domain
informasi untuk software tersebut seperti:

e. Fungsi (fungsi dari software itu sendiri)

f. Tingkah laku (tingkah laku dari software)

g. Kinerja (berhubungan dengan tingkat akuratsi)

h. Antar muka

b. Design

Design software ini sebenarnya merupakan proses beberapa tahap yang

difokuskan pada 4 atribut yang berbeda dari sebuah program yaitu :

e. Struktur data

f. Arsitektur software

g. Tampilan antar muka

h. Algoritma (prosedur) misalnya pseucode, flow chart, diagram konteks,

dll
 c. Pembuatan program

Merupakan proses translasi yang didasarkan pada design yang ada kebentuk
yang bisa dibaca oleh mesin,

d. Pengujian

Difokuskan pada :

c. Logika internal software (apkh sdh sesuai dgn prosedur yg dibuat, apakah
sudah baik?)

d. Fungsi eksternal test (diimplementasikan dgn beda mesin)

Untuk menguji jikalau terjadi kesalahan

e. Perawatan

Perubahan mesin mungkin terjadi setelah software diserahkan kecustomer.

Perubahan tersebut antara lain:

e. Terjadi error

f. Terjadi perubahan lingkungan eksternal

g. Kebutuhan peningkatan fungsional

Peningkatan kinerja

5. Jelaskan 3 fase pada proses software!

Secara umum ada 3 fase dalam RPL tanpa memandang besarnya masalah,
kompleksitas & masalahnya ketiga fase tsb adalah:

- Identification phase : untuk mengidentifikasi seluruh masalah / mendefinisikan

bentuk2 desain yang akan dibuat algoritmanya.

- Development phase : mentranslasikan algoritma sebelumnya kebahasa

pemograman atau kode program

- Maintenance phase : melakukan testing dan implementasi serta perawatan

pada perangkat lunak.
6. Jelaskan aktivitas pada LSM (Linear Sequensial Model)!

1. Rekayasa dan pemodelan system / informasi

Pekerjaan dimulai dengan mengumpulkan semua kebutuhan elemen system.

Hal ini penting terutama pada saat system melakukan antar muka dengan
elemen lain seperti hardware, orang, dan database.

2. Analisa kebutuhan software

Untuk memahami program yang harus dibuat analis harus mengetahui domain
informasi untuk software tersebut seperti:

i. Fungsi (fungsi dari software itu sendiri)

j. Tingkah laku (tingkah laku dari software)

k. Kinerja (berhubungan dengan tingkat akuratsi)

l. Antar muka

3. Design

Design software ini sebenarnya merupakan proses beberapa tahap yang

difokuskan pada 4 atribut yang berbeda dari sebuah program yaitu :

i. Struktur data

j. Arsitektur software

k. Tampilan antar muka

l. Algoritma (prosedur) misalnya pseucode, flow chart, diagram konteks,

dll

4. Pembuatan program

Merupakan proses translasi yang didasarkan pada design yang ada kebentuk
yang bisa dibaca oleh mesin,

5. Pengujian

Difokuskan pada :

e. Logika internal software (apkh sdh sesuai dgn prosedur yg dibuat, apakah
sudah baik?)

f. Fungsi eksternal test (diimplementasikan dgn beda mesin)

Untuk menguji jikalau terjadi kesalahan

 6. Perawatan

Perubahan mesin mungkin terjadi setelah software diserahkan kecustomer.

Perubahan tersebut antara lain:

h. Terjadi error

i. Terjadi perubahan lingkungan eksternal

j. Kebutuhan peningkatan fungsional

k. Peningkatan kinerja.

7. Uraikan perbedaan LSM dengan Prototype model!

8. Apa yang dimaksud dengan people problem dan process pada konsep manajement
proyek?

- People : pengerak atau orang yang menjalankan manajemen

- Problem

- Process : metode yang digunakan untuk pemecahan masalah

9. Jelaskan organisasi team software secara umum dan sebutkan 7 faktor yang
mempengaruhi pemilihan organisasi team software!asa

Secara umum ada 3 macam organisasi team software :

- Democratic Decentralized

Team software ini tidak memiliki pemimpin yang permanen atgau tetap.
Koordinasi ditunjuk untuk jangka pendek & kemudian diganti dengan yang
lainnya, yang mampu mengkoordinasi tugas yang berbeda.

Pengambilan keputusan dilakukan melalui consensus kelompok. Komunikasi

antar anggota team dilakukan secara horizontal.

- Control Decentralized

Team rekayasa software menunjuk seorang leader yang mengkoordinir tugas-

tugas tertentu dan secondary leader yang bertanggung jawab atas sub-sub
 pekerjaan. Pemecahan solusi permasalahan dilakukan secara kelompok akan
tetapi implementasi solusi dibagi ke sub-sub kelompok oleh team leader.

Komunikasi antara sub kelompok atau individu dilakukan secara horizontal dan
juga vertical sesuai dengan interaksi kendali.

- Control Centralized

Solusi permasalahan dan kombinasi team internal diatur oleh team leader

Komunikasi antara leader dan anggota team dilakukan secara vertical

1. Tingkat kesulitan problem yang harus diselesaikan

2. Ukuran program (line of code)

3. Tingkat problem yang bisa dimodulkan

4. Waktu team bisa bekerja bersama – sama

5. Kualitas sistem yang akan dibuat

6. Tanggal penyerahan software yang akan ketat

7. Tingkat komunikasi yang diperlukan untuk proyek

QUIS 2
1. Jelaskan paling sedikit 3 kegiatan yasng dilakukan pada tahap observasi
terhadap estimasi

2. Apa yang dimaksud dengan

- Human Resources

- Reusable Software Resources

- Environment Reusable Project

3. Jelaskan 3 jenis resiko yang perlu diidentifikasi

4. Jelaskan struktur aktifitas rekayasa resiko menurut Barry Bosehm

5. Jelaskan tata cara menentukan Prioritas Resiko

 Kisi - Kisi
1. Jelaskan karakteristik manajer proyek yang efektif !

2. Tuliskan 7 faktor yang perlu dipertimbangkan pada saat merencanakan tim

rekayasa software !

3. Apa yang dimaksud dengan ruang lingkup (batasan) software?

4. Berikan contoh ruang lingkup software!

5. Apa yang dimaksud dengan :

- Human resource

- Reusable software resource

- Environment reusable proyek

6. Jelaskan kegiatan-kegiataan yang dilakukan pada tahap observasi terhadap

estimasi

7. Pada tahap identifikasi terdapat 3 jenis resiko yang perlu diidentifikasi,

jelaskan !

8. Jelaskan tata cara menentukan prioritas resiko  analisa resiko!

9. Jelaskan struktur aktivitas risk engineering versi Barly Boehm!

10. Jelaskan beberapa factor yang perlu dipertimbangkan dalam identifikasi

resikol!