By.

Sri Rezeki Candra Nursari

3 sks

Rekayasa Perangkat Lunak

Materi

Pengantar Rekayasa Perangkat Lunak

Pemodelan Data dan Proses

Manajemen Proyek

Konsep Perancangan

Konsep Testing
 Referensi
• Rekayasa Perangkat Lunak – Pendekatan
Praktisi, Roger S. Pressman, Ph.D, Andi
Jogyakarta, 2012 – Buku 1
• Rekayasa Perangkat Lunak – Pendekatan
Praktisi, Roger S. Pressman, Ph.D, Andi
Jogyakarta, 2012 – Buku 2
• Rekayasa Perangkat Lunak – Analisa
Kebutuhan Dalam, Daniel Siahaan, Andi
Jogyakarta, 2012
MODEL PROSES GENERIK
• Proses rekayasa perangkat lunak merupakan
sejumlah aktifitas-aktifitas kerja, tindakan-
tindakan, serta pekerjaan-pekerjaan yang harus
dilaksanakan saat produk kerja dibuat
• Masing-masing aktifitas berada dalam kerangka
kerja / model yang mendefinisikan hubungan
antara suatu proses dengan proses lainnya
• Masing-masing tindakan perangkat lunak
didefinisikan menggunakan himpunan pekerjaan
/kerangka kerja
KERANGKA KERJA PROSES PERANGKAT LUNAK
Proses Perangkat Lunak
Proses Kerangka Kerja
Aktifitas-Aktifitas Penyangga
Aktifitas Kerangka Kerja #1
Tindakan-tindakan Rekayasa Perangkat Lunak # 1.1.

Pekerjaan, produk-produk kerja titik

Satuan pekerjaan jaminan kualitas proyek

Tindakan-tindakan Rekayasa Perangkat Lunak # 1.t.

Pekerjaan, produk-produk kerja titik

Satuan pekerjaan jaminan kualitas proyek

Aktifitas Kerangka Kerja #n

Tindakan-tindakan Rekayasa Perangkat Lunak # n.1.

Satuan pekerjaan

Tindakan-tindakan Rekayasa Perangkat Lunak # n.s.

Pekerjaan, produk-produk kerja titik

Satuan pekerjaan jaminan kualitas proyek
MACAM-MACAM ALIRAN PROSES
REKAYASA PERANGKAT LUNAK

1. Aliran proses linier

2. Aliran proses iteratif
3. Aliran proses evolusioner
4. Aliran proses paralel
1. ALIRAN PROSES LINIER

KOMUNIKASI PERENCANAAN PEMODELAN

PENYERAHAN KE
PELANGGAN / KONSTRUKSI
PENGGUNA
2. ALIRAN PROSES ITERATIF

KOMUNIKASI PERENCANAAN PEMODELAN

PENYERAHAN KE
PELANGGAN / KONSTRUKSI
PENGGUNA
3. ALIRAN PROSES EVOLUSIONER
PERENCANAAN

PEMODELAN

KOMUNIKASI

PENYERAHAN KE
PELANGGAN / KONSTRUKSI
PENGGUNA
4. ALIRAN PROSES PARALEL
KOMUNIKASI PERENCANAAN

PEMODELAN

PENYERAHAN KE
KONSTRUKSI PELANGGAN /
PENGGUNA
 TIPE POLA-POLA MENURUT AMBER PROSES
REKAYASA PERANGKAT LUNAK (RPL)
1. Pola Tahapan
– Mendifinisikan suatu permasalahan yang berhubungan
dengan aktifitas kerangka kerja tertentu untuk suatu proses
2. Pola Pekerjaan
– Mendifinisikan suatu permasalahan yang berhubungan
dengan suatu aksi RPL atau tugas-tugas kerja dan relevan
dengan RPL
3. Pola Fase
– Mendifinisikan urutan kerangka kerja yang terjadi di dalam
suatu proses, meskipun saat aliran aktifitas secara
keseluruhan secara alamiah bersifat iteratif. Mungkin berupa
model spiral / pembentukan prototype
 PENDEKATAN PENILAIAN PROSES RPL DAN
PERBAIKAN USULAN, MENGGUNAKAN
1. SCAMPI (Standard CMMI Assesment Method for Process
Improvement)
– Menyediakan model penilaian dengan proses lima (5) langkah, yaitu :
pemberian nilai-nilai awal (initiating)  melakukan diagnosa
(diagnosing)  penetapan (establishing)  bertindak (acting)  belajar
(learning)
2. CBA API (CMM-Based Appraisal for Internal Process
Improvement)
– Menyediakan teknik diagnosa untuk melakukan penilaian
3. SPICE (ISO/IEC15504)
– Suatu standar yang mendefinisikan sejumlah spesifikasi kebutuhan
untuk penilaian proses perangkat lunak
4. ISO 9001:2000 for Software
– Suatu standar generik yang diterapkan untuk setiap organisasi
 MODEL PROSES RPL
1. Model Air Terjun (Waterfall)
2. Model Proses Inkremental
3. Model Prototipe (Prototyping)
4. Model Proses Evolusioner
5. Model Spiral
6. Model RAD (Rapid Application
Development)
7. Model-Model Konkuren
8. Model Metode Formal
 1. Metode Air Terjun / Waterfall
• Model Sekuensial Linier sering disebut Model
Air Terjun merupakan paradigma rekayasa
perangkat lunak yang paling tua dan paling
banyak dipakai.
• Model ini mengusulkan sebuah pendekatan
perkembangan perangkat lunak yang
sistematik dan sekuensial.
• Variasi dari model waterfall/air terjun
dinamkan sebagai Model V (V-Model)
 1. Metode Air Terjun / Waterfall
• Inti dari metode waterfall adalah pengerjaan
dari suatu sistem dilakukan secara berurutan
atau secara linear.
• Jadi jika langkah satu belum dikerjakan maka
tidak akan bisa melakukan pengerjaan langkah
2, 3 dan seterusnya.
• Secara otomatis tahapan ke-3 akan bisa
dilakukan jika tahap ke-1 dan ke-2 sudah
dilakukan
 1. MODEL WATERFALL
KOMUNIKASI PERENCANAAN
PEMODELAN
Permulaan proyek Membuat perkiraan-
Teknik untuk men- perkiraan , penjadwalan Analisis perancangan
dapatkan spesifikasi dan pelacakan
kebutuhan pengguna

PENYERAHAN KE
PELANGGAN /
KONSTRUKSI
PENGGUNA
Penulisan kode-kode
Pengiriman program
Dukungan terhadap Pengujian
pengguna
Umpan balik
 1. MODEL V
Teknik untuk men-
dapatkan spesifikasi Pengujian oleh para
kebutuhan pengguna pengguna/pelanggan

Perancangan Pengujian secara

arsitektur sistem keseluruhan

Pengujian setelah
Perancangan
unit-unit
komponen
diintegrasikan

Penulisan kode-kode Pengujian unit

program

Perangkat Lunak Yang Dapat Digunakan Oleh Pelanggan/Pengguna

 1. Kelebihan Waterfall
• Kelebihan :
– Kualitas dari sistem yang dihasilkan akan baik.
– Document pengembangan sistem sangat
terorganisir, karena setiap fase harus
terselesaikan dengan lengkap sebelum
melangkah ke fase berikutnya.
– Mudah diaplikasikan.
 1. Kekurangan Waterfall
• Kekurangan :
– Diperlukan majemen yang baik, karena proses
pengembangan tidak dapat dilakukan secara
berulang sebelum terjadinya suatu produk.
– Kesalahan kecil akan menjadi masalah besar jika
tidak diketahui sejak awal pengembangan.
– Pengguna sulit menyatakan kebutuhan secara
eksplisit sehingga tidak dapat mengakomodasi
ketidakpastian pada saat awal pengembangan.
2. Model Proses Inkremental
• Spesifikasi kebutuhan perangkat lunak saat
awal sudah terdefinisi dengan baik, tetapi
lingkup keseluruhan usaha pengembangan
perangkat lunak tidak dapat dilakukan secara
linier.
• Usaha pengembangannya dengan melakukan
penambahan sedikit demi sedikit (ikremental)
• Merupakan model yang menggabungkan
elemen aliran-aliran proses linier dan paralel
• Contoh : perangkat lunak “word processing”,
dimana pengolahan berkas sedikit demi sedikit
bertambah fungsinya
 2. Model Proses Inkremental

Fungsional itas & Fitur PL

Rekayasa Sistem Informasi Versi Perangkat Lunak #n

Pemodelan Konstruksi Penyerahan

Perencanaan (Analisis, (Penulisan Sistem/Perangkat Lunak Ke
Komunikasi Perancangan) Kode-Kode Para Pelanggan / Pengguna
Program, (Pengiriman, Umpan Balik)
Pengujian)

Versi Perangkat Lunak #3

Pemodelan Konstruksi Penyerahan

Perencanaan (Analisis, (Penulisan Sistem/Perangkat Lunak Ke
Komunikasi Perancangan) Kode-Kode Para Pelanggan / Pengguna
Program, (Pengiriman, Umpan Balik)
Pengujian)

Versi Perangkat Lunak #2

Pemodelan Konstruksi Penyerahan
Perencanaan (Analisis, (Penulisan Sistem/Perangkat Lunak Ke
Komunikasi Perancangan) Kode-Kode Para Pelanggan / Pengguna
Program, (Pengiriman, Umpan Balik)
Pengujian)

Versi Perangkat Lunak #1

Pemodelan Konstruksi Penyerahan
Perencanaan (Analisis, (Penulisan Sistem/Perangkat Lunak Ke
Komunikasi Perancangan) Kode-Kode Para Pelanggan / Pengguna
Program, (Pengiriman, Umpan Balik)
Pengujian)

Waktu kalender
 3. Model Prototipe

• Metode ini sering digunakan pada dunia

riil. Karena metode ini secara keseluruhan
akan mengacu kepada kepuasan user.
• Bisa dikatakan bahwa metode ini
merupakan metode waterfall yang
dilakukan secara berulang-ulang.
 Langkah-langkah Prototyping
1. Pengumpulan Kebutuhan/Komunikasi &
Perencanaan
– Pelanggan dan pengembang bersama-sama
mendefinisikan format seluruh perangkat lunak,
mengidentifikasikan semua kebutuhan, dan garis
besar sistem yang akan dibuat.
2. Membangun Prototyping/Analisis, Perancangan
– Membangun prototyping dengan membuat
perancangan sementara yang berfokus pada
penyajian kepada pelanggan (misalnya dengan
membuat input dan format serta output
 Langkah-langkah Prototyping
3. Pengkodean dan Pengujian Sistem / Konstruksi
– Dalam tahap ini prototyping yang sudah di sepakati
diterjemahkan ke dalam bahasa pemrograman yang sesuai.
– Setelah sistem sudah menjadi suatu perangkat lunak yang
siap pakai, harus dites dahulu sebelum digunakan
4. Evaluasi Prototyping / Konstruksi
– Evaluasi ini dilakukan oleh pelanggan apakah prototyping
yang sudah dibangun sudah sesuai dengan keinginann
pelanggan.
– Jika sudah sesuai maka langkah ini (langkah 4) akan diambil.
– Jika tidak prototyping direvisi dengan mengulang langkah
demi langkah (langkah 1, 2 dan 3)
Langkah-langkah Prototyping
5. Mengevaluasi Sistem / Konstruksi
– Pelanggan mengevaluasi apakah sistem yang
sudah jadi sudah sesuai dengan yang diharapkan .
Jika ya, langkah 7 dilakukan; jika tidak, ulangi
langkah 4 dan 5.
6. Menggunakan Sistem / Penyerahan Sistem, Umpan
Balik
– Perangkat lunak yang telah diuji dan diterima
pelanggan siap untuk digunakan .
7. Pemeliharaan / Penyerahan Sistem, Umpan Balik
 PRARADIGMA PEMBUATAN PROTIPE

PERENCANAAN
secara cepat

PEMODELAN
KOMUNIKASI Perancangan secara
cepat

Penyerahan Sistem/
perangkat lunak ke para
pelanggan/pengguna
Pengiriman & Umpan Balik KONSTRUKSI
Pembentukan prototipe
 Jenis-jenis Prototyping
• Feasibility prototyping.
– Digunakan untuk menguji kelayakan dari teknologi
yang akan digunakan untuk system informasi yang
akan disusun.
• Requirement prototyping.
– Digunakan untuk mengetahui kebutuhan aktivitas
bisnis user. Misalnya dalam sebuah perusahaan
terdapat user direktur, manajer, dan karyawan.
Maka penggunaan sistem dapat dibedakan
berdasarkan user tersebut sesuai dengan
kebutuhannya.
 Jenis-jenis Prototyping

• Desain Prototyping.
– Digunakan untuk mendorong perancangan
system informasi yang akan digunakan.
• Implementation prototyping.
– Merupakan lanjutan dari rancangan protipe,
prototype ini langsung disusun sebagai suatu
system informasi yang akan digunakan.
 Kelebihan Prototyping
• Adanya komunikasi baik antara pengembang
dengan pelanggan.
• Pengembang dapat bekerja lebih baik untuk
memenuhi kebutuhan pelanggan.
• Pelanggan berperan aktif dalam pengembangan
sistem.
• Menghemat waktu dalam pengembangannya.
• Penerapan lebih mudah karena pemakai akan
mengetahui apa yang diharapkan.
 Kekurangan Prototyping

• Kualitas sistem kurang baik karena hanya

mengedepankan aspek kenyamanan user.
• Pengembang kadang-kadang menggunakan
implementasi yang sembarangan.
• Tidak mencerminkan proses perancangan yang
baik.
 Kondisi agar prototyping berhasil
• Prototyping akan bekerja dengan baik bila diterapkan dalam kondisi :
– Resiko tinggi yaitu untuk masalah-masalah yang tidak terstruktur
dengan baik, ada perubahan yang besar dari waktu ke waktu, dan
adanya persyaratan data yang tidak menentu.
– Interaksi pemakai sangat penting.
– Sistem harus menyediakan dialog on-line antara pelanggan dan
komputer.
– Perlunya penyelesaian yang cepat
– Perilaku pemakai yang sulit ditebak
– Sitem yang inovatif. Sistem tersebut membutuhkan cara
penyelesaian masalah dan penggunaan perangkat keras yang
mutakhir
– Perkiraan tahap penggunaan sistem yang pendek
4. Model Proses Evolusioner
• Metode/Model ini bersifat iteratif dan
bersifat penambahan sedikit demi sedikit
(Inkremental).
• Cirinya memungkinkan kita
mengembangkan perangkat lunak yang
semakin kompleks pada versi-versi
berikutnya
• Dirancang untuk mengakomodasi suatu
produk yang akan berubah secara perlahan
(berevolusi) sepanjang waktu
Pertimbangan menggunakan Model
Proses Evolusioner
1. Dalam pembentukan prototipe memiliki masalah
dalam hal perencanaan proyek sebab didalamnya
ada sejumlah siklus yang tidak pasti dan diperlukan
untuk mengkonstruksi produk
2. Tidak menetapkan kecepatan maksimum pada
evolusi
3. Harus berfokus pada fleksibilitas dan perluasaan
dan pada kualitas yang tinggi
 5. Model Spiral
• Ditemukan oleh Barry Boehm dalam
artikelnya “A Spiral Model of Software
Development and Enhancement ” 1988.
• Boehm mengusulkan sebuah model yang
secara explisit menjelaskan bahwa resiko
yang disadari mungkin membentuk dasar
model proses umum
 5. Model Spiral
• Model yang diusulkan Boehm berbentuk
spiral dan merupakan kombinasi dari
Prototyping Model dengan Waterfall
Model.
• Setiap tahapan model ini selalu dilakukan
Risk Analisys dan verifikasi atau testing.
 5. Model Spiral
• Setiap loop dalam model ini mewakili sebuah
tahap dari proses perangkat lunak.
• Tidak ada tahap yang tetap dalam model
ini. Manajemen harus memutuskan
bagaimana membentuk proyek ke dalam
tahap-tahap.
• Perusahaan biasanya bekerja dengan beberapa
model umum dengan tahap tambahan untuk
proyek khusus atau ketika masalah-masalah
ditemukan selama pembuatan proyek.
 Setiap loop dibagi dalam 4 sektor
sebagai berikut :
1. Determine objectives
– Menentukan permasalahan, menentukan alternatif
dan obyek yang mendesak.
– Tujuan, hambatan dalam proses ataupun produk
serta resiko-resiko proyek harus ditentukan.
– Rencana rinci manajemen harus ditulis lengkap.
– Pembuatan strategi-strategi alternatif direncanakan
sesuai dengan resiko yang ada.
 Setiap loop dibagi dalam 4 sektor
sebagai berikut :
2. Risk Analysis
– Analisis resiko, evaluasi, dan mencari solusi.
– Jika resiko tidak dapat ditemukan solusinya, maka
proses berhenti.
– Untuk setiap resiko yang telah diidentifikasi, akan
dibuat analisis rincinya. Kemudian diambil langkah-
langkah untuk mengurangi resiko tersebut.
– Contohnya, jika ada resiko bahwa persyaratan-
persyaratan tidak tepat, maka sebuah model contoh
mungkin dapat dikembangkan.
Setiap loop dibagi dalam 4 sektor
sebagai berikut :
3. Engineering / develop
 Melakukan proses rekayasa perangkat lunak.
 Setelah evaluasi resiko, sebuah model pengembangan
untuk sistem harus dipilih.
 Misalnya, jika resiko interface pengguna yang dominan
maka model pengembangan yang tepat mungkin
pengembangan evalusioner dengan menggunakan
model contoh (prototipe).
 Jika resiko keselamatan yang diutamakan, model
pengembangan yang sesuai adalah transformasi formal
dan seterusnya.
 Model waterfall mungkin tepat digunakan jika resiko
yang diutamakan adalah integrasi sistem
 Setiap loop dibagi dalam 4 sektor
sebagai berikut :
4. Plan next phase
– Penentuan rencana-rencana untuk tahap
selanjutnya.
– Jika diputuskan untuk melanjutkan pada loop
spiral berikutnya maka proyek dibicarakan kembali
dan rencana dibuat untuk tahap selanjutnya
 5. Model Spiral
• Pada implementasinya, model spiral ini juga
banyak digunakan, tetapi biasanya dikombinasi-
kan dengan yang lain.
• Pemodelan waterfall, yang sangat bagus dalam
menentukan sejumlah titik dalam waktu
pengembangan perangkat lunak (milestones) dan
pemodelan spiral, yang sangat bagus dengan
menggunakan prototyping, merupakan kombinasi
yang sering dipakai di dalam kontrak-kontrak untuk
perangkat lunak dewasa ini.
 PERENCANAAN
Pembuatan prakiraan-prakiraan
penjadwalan analisis terhadap resioko-
resiko perangkat lunak

KOMUNIKASI PEMODELAN
Analisis perancangan

Penyerahan sistem/perangkat luar ke

para pelanggan/pengguna KONSTRUKSI
Pengiriman, umpan balik Penulisan kode-kode program pengujian
 Risk Analysis
• Risk Analysis yang dilakukan pada metode spiral adalah :
– Project risk, mempengaruhi rencana proyek, contoh
kekurangan sumber daya
– Technical risk, mempengaruhi tahap aktual, contoh :
personil tidak terlatih di tahap tersebut
– Bussines risk, mempengaruhi keinginan perusahaan
untuk membuat software, contoh : software tidak
diperlukan
 Prioritas resiko

• 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
• Negligible (tidak berarti), contoh : penggunaan waktu
proyek tidak optimal
 Kelebihan Metode Spiral
 Penekanan pada alternatif dan kendala
mendukung penggunaan kembali solusi yang
ada.
 Target pengujian dengan memperlakukannya
sebagai risiko, yang harus ditangani.
 Perkiraan (anggaran dan jadwal) lebih realistis
sejalan pekerjaan berlangsung, karena isu-isu
penting yang ditemukan sebelumnya.
 Hal ini lebih mampu mengatasi dengan (hampir
tak terelakkan) perubahan pengembangan
perangkat lunak yang umum dan berarti.
 Pengembang, dapat mulai bekerja pada proyek
dengan lebih cepat.
 Kekurangan Metode Spiral
• Hanya ditujukan untuk proyek internal (di dalam perusahaan),
karena risiko dinilai saat proyek dikembangkan.
• Hampir tidak cocok untuk pengembangan perangkat lunak yang
bersifat kontrak.
• Dalam hal pengembangan perangkat lunak kontrak, semua
analisis risiko harus dilakukan dengan baik oleh klien dan
pengembang sebelum kontrak ditandatangani dan tidak seperti
dalam model spiral.
• Model spiral lebih berfokus pada resiko. Oleh karena itu
membutuhkan staf yang berpengetahuan.
• Hanya cocok untuk pengembangan perangkat lunak skala besar.
 6. Model RAD
(Rapid Application Development
• Rapid Aplication Development (RAD)
adalah sebuah proses perkembangan
perangkat lunak sekuensial linier yang
menekankan siklus perkembangan dalam
waktu yang singkat (60 sampai 90 hari)
dengan pendekatan konstruksi berbasis
komponen.
 Langkah-langkah RAD
1. Business Modelling
2. Data Modelling
3. Process Modelling
4. Application Generation
5. Testing and Turnover
 Langkah-langkah RAD
1. Business Modelling
– Fase ini untuk mencari aliran informasi yang
dapat menjawab pertanyaan berikut:
• Informasi apa saja yang dapat mengendalikan
proses bisnis?
• Informasi apa yang diinginkan/muncul?
• Di mana informasi tersebut digunakan ?
• Siapa yang akan memprosesnya ?
 Langkah-langkah RAD

2. Data Modelling
– Fase ini menjelaskanobjek data yang
dibutuhkan dalam proyek.
– Karakteristik (atribut) masing-masing data
diidentifikasikan dan hubungan antar objek
didefinisikan.
 Langkah-langkah RAD
3. Process Modelling
– Aliran informasi pada fase data modelling
ditransformasikan untuk mendapatkan aliran
informasi yang diperlukan pada implementasi
fungsi bisnis.
– Pemrosesan diciptakan untuk menambah,
memodifikasi, menghapus, atau untuk
mendapatkan kembali objek data tertentu.
 Langkah-langkah RAD
4. Application Generation
– Selain menggunakan bahasa pemrograman
generasi ketiga, RAD juga memakai komponen
program yang telah ada atau menciptakan
komponen yang bisa digunakan kembali.
– Ala-alat bantu bisa dipakai untuk memfasilitasi
konstruksi perangkat lunak.
 Langkah-langkah RAD

5. Testing and Turnover

– Karena menggunakan kembali komponen
yang telah ada, maka akan mengurangi
waktu pengujian.
– Tetapi komponen baru harus diuji dan
semua interface harus diuji coba secara
penuh.
 Kelebihan RAD
• Setiap fungsi inti dapat dimodulkan dalam waktu
tertentu kurang dari 3 bulan dan dapat dibicarakan
oleh tim RAD yang terpisah dan kemudian
diintegrasikan sehinnga waktunya lebih efesien.
• RAD mengikuti tahapan pengembangan sistem
sepeti umumnya, tetapi mempunyai kemampuan
untuk menggunakan kembali komponen yang ada
(reusable object) sehingga pengembang tidak perlu
membuat dari awal lagi dan waktunya lebih singkat
.
 Kekurangan RAD
• Proyek yang besar dan berskala, RAD
memerlukan sumber daya manusia yang
memadai untuk menciptakan tim yang baik.
• RAD menuntut pengembang dan pelanggan
nya untuk memiliki komitmen dalam aktivitas
yang diperlukan untuk melengkapi sebuah
sistem dalam waktu yang singkat.
• Jika komitmen tersebut tidak ada maka proyek
RAD akan gagal.
 7. Model Konkuren
• Menggunakan unsur-unsur yang bersifat
berulang (iteratif) dan konkuren (berjalan
bersamaan) dalam setiap model proses
• Aktifitas pemodelan konkuren
memungkinkan ada dalam salah satu
keadaan pada suatu waktu tertentu
 7. Model Konkuren
• Komunikasi atau Konstruksi berada pada
keadaan yang sama
• Mendefinisikan sejumlah event
berurutan yang akan memicu transisi dari
suatu keadaan (state) ke keadaan yang
lainnya pada masing-masing aktifitas,
tindakan atau pekerjaan rekayasa
perangkat lunak (RPL)
 7. Model Konkuren
• Dapat diterapkan pada smua hal yang
berkaitan dengan pengambangan perangkat
lunak (PL) dan menyediakan gambaran yang
akurat tentang keadaan proyel saat ini
• Digambarkan dalam bentuk jaringan proses.
Artinya masing-masing aktifitas, tindakan atau
pekerjaan dalam jejaring hadir secara
bersamaan dengan aktifitas-aktifitas,
tindakan-tindakan atau pekerjaan-pekerjaan
yang lainnya
 8. Model Metode Formal
• Menggunakan sejumlah aktifitas yang sesuai
dengan spesifikasi formal matematis dari suatu
perangkat lunak komputer
• Dimungkinkan untuk melakukan spesifikasi,
pengembangan dan verifikasi suatu sistem
berbasis komputer dengan menerapka notasi-
noasi matematika
• Untuk pengembangan perangkat lunak yang
sangat kritis dalam kaitannya dengan keamanan
(misalnya pengembangan PL untuk pengendalian
pesawat udaraatau yang bekerja pada sarana-
sarana kesehatan)
 8. Model Metode Formal
• Menawarkan perangkat lunak (PL) yang bebas cacat (defect-
free-software)
• Alasan mengapa metode ini jarang digunakan karena :
1. Pengembangan metode formal memerlukan waktu yang
sangat banyak dan sangat mahal
2. Karena hanya sedikit pengembangan PL yang memiliki latar
belakang yang cukup untuk menerapkan metode-metode
formal, maka dibutuhkan pelatihan-pelatihan yang ekstensif
3. Meruapakan hal yang sulit untuk menggunakan model
formal ini sebagai mekanisme komunikasi para pelanggan
yang secara teknis tidak canggih