Evolusi Software

35
Evolusi Software 1 ST 2 ND 3 RD 4 TH 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.)

Transcript of Evolusi Software

Page 1: Evolusi Software

Evolusi Software1ST 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.

Page 2: Evolusi Software

- 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

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

TOOLSMETODE

PROCESS

A QUALITY FOCUS

Page 3: Evolusi Software

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.

Page 4: Evolusi Software

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

Page 5: Evolusi Software

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.

Page 6: Evolusi Software

Prototype paradigm.

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?

Listen to customer

Page 7: Evolusi Software

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

Page 8: Evolusi Software

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.

Page 9: Evolusi Software

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

Page 10: Evolusi Software

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

Page 11: Evolusi Software

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

Page 12: Evolusi Software

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

Page 13: Evolusi Software

ESTIMASI SUMBER DAYA

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

*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

PEOPLE

RELIABLE SOFTWARE COMPONENT

HARDWARE & SOFTWARE TOOLS

Page 14: Evolusi Software

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.

Page 15: Evolusi Software

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.

Page 16: Evolusi Software

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

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

Risk Engineering

Risk Analisys Risk Management

Risk

Staffing

Risk

Directingg

Risk

Monitoring

Risk

Control

Risk

Planning

Risk

Evaluation

Risk

Estimation

Risk

Identification

Page 17: Evolusi Software

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

Page 18: Evolusi Software

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

Page 19: Evolusi Software

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.

Page 20: Evolusi Software

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

Page 21: Evolusi Software

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.

Page 22: Evolusi 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

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.

TOOLSMETODE

PROCESS

A QUALITY FOCUS

Page 23: Evolusi Software

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

Page 24: Evolusi Software

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

Page 25: Evolusi Software

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

Page 26: Evolusi Software

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.

Page 27: Evolusi Software

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

Page 28: Evolusi Software

Kisi - Kisi1. 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!