Disiplin Ilmu dan Kurikulum

Pengakuan disiplin ilmu biasanya diwujudkan dalam pembentukan

jurusan atau fakultas pada universitas.
Software engineering termasuk nama jurusan atau fakultas yang diakui
menurut IEEE Computing Curricula
IEEE Computer Society membentuk tim khusus untuk menyusun pohon
ilmu software engineering (Software Engineering Body of Knowledge)

IEEE Computing Curricula 2005

1. Computer Engineering (CE, Teknik Komputer)

2. Computer Science (CS, Ilmu Komputer)
3. Information System (IS, Sistem Informasi)
4. Information Technology (IT, Teknologi Informasi)
5. Software Engineering (SE, Rekayasa Perangkat Lunak)

Adaptasi ke Kurikulum Indonesia

Computer Science = jurusan Teknik Informatika atau Ilmu Komputer

Computer Engineering = Sistem Komputer atau Teknik Komputer
Information System = Sistem Informasi atau Manajemen Informatika
Software Engineering dan Information Technology, di Indonesia
dimasukkan ke salah satu bagian dari jurusan Teknik Informatika atau
Ilmu Komputer

Arah Kurikulum

Computer Engineering menghasilkan lulusan yang mampu mendesain

dan mengimplementasikan system yang terintegrasi baik software
maupun hardware
Computer Scinece menghasilkan lulusan dengan kemampuan yang
cuku luas dimulai dari penguasaan teori (konsep) dan pengembangan
software.
Information System, menghasilkan lulusan yang mampu menganalisa
kebutuhan (requirement) dan proses bisnis (business process), sereta
mendesain system berdasarkan tujuan dari organisasi
Information Technology menghasilkan lulusa yang mampu bekerja
secara efektif dalam merencakan, mengimplementasikan,
mengkonfigurasi dan memaintain infrastruktur teknologi informasi
dalam organisasi.
 Software engineering menghasilkan lulusan yang mampu mengelola
aktifitas pengembangan software berskala besar dalam tiap
tahapannya (software development life cycle).

SWEBOK

SWEBOK (Engineering Body of Knowledge) dalam situsnya

http://www.sebok.org menuliskan:
SWEBOK menggambarkan pengetahuan secara umum tentang
rekayasa perangkat lunak yang dibagi ke dalam 10 area
pengetahuan (knowledge Areas) atau disebut KAS.
SWEBOK merupakan project yang dibuat oleh IEEE, SWEBOK
sendiri mempunyai panduan yang disebut Guide of SWEBOK.

SWEBOK 2004 mempunyai 10 Knowledge Areas yaitu:

1. Software requirements
2. Software design
3. Software construction
4. Software testing
5. Software maintenance
6. Software configuration management
7. Software engineering management
8. Software engineering process
9. Software engineering tools and methods
10. Software quality

Proses, Metode, Tool SE

Proses SE adalah perangkat yang menahan lapisan teknologi secara

bersama dan pembangunan software menjadi rasional dan tepat
waktu.
Metode SE menyediakan cara bagaimana membangun software
Tool-tool SE menyediakan dukungan otomatisasi atau semiotomatisasi
untuk proses dan metode software engineering.

Model Proses

Model Air Terjun

Tahapan rekayasa perangkat lunak dipandang sebagai sesuatu yang
terpisah.
Model Evolusioner
Tahapan rekayasa perangkat lunak berhimpit, cepat diimplementasikan
dan diperbaiki sesuai feedback.
 Model Metode Formal
Clearnroom, CSP, B, Z = untuk system kritis
Model Pemakaian Ulang
- Framework, komponen
- COTS
Model Inkramental

Model Pembangunan Evolusioner

Exploratory development
Tujuannya adalah bekerja dengan pelanggan dan menyusun system
final dari garis besar spesifikasi awal. Harus dimulai dengan
pemahaman yang baik terhadap requirement dan menambahkan fitur
baru yang diinginkan pelanggan.
Throw-away prototyping
Tujuannya untuk memahami requirements system. Dimulai dari
pemahaman yang kurang terhadap requirement untuk menjelaskan
apa yang betul-betul diperlukan.

SE Berbasis Komponen

Didasarkan pada systematic reuse dimana system terintegrasi dari

komponen yang sudah ada atau system COTS (Commercial-off-the-
shelf)
Tingkatan Proses
- Analisis Komponen
- Modifikasi requirement
- Desain system dengan reuse
Development and integration
Hi approach is becoming increasingly used as
Component standards have emerged

Metode Rekayasa Perangkat Lunak

Metode Berorientasi Fungsi (Terstruktur)

Structured Analysis Fungsi (De Marco, 1978)

Jackson System Development (Jackson, 1983)

Metode Berorientasi Objek

Metode Berorientasi Objek (Boock & Rumbaugh)

Pendekatan Gabungan dengan UML (Unified Modeling Language)
PERTEMUAN 4

Software Requirement

(Kebutuhan Perangkat Lunak)

Pendahuluan

Requirements engineering adalah fase terdepan dari proses rekayasa

perangkat lunak, dimana software requirements (kebutuhan) dari user
(pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan
ditetapkan.
Para pakar software engineering sepakat bahwa requirements
engineering adalah suatu pekerjaan yang sangat penting.
Fakta membuktikan bahwa kebanyakan kegagalan pengembangan
software disebabkan karena adanya:
- Ketidakkonsistenan
- Ketidaklengkapan
- Ketidakbenaran

Dari requirements specification (spesifikasi kebutuhan).

The Standish Group mencatat bahwa presentase akumulatif kegagalan

sebauh project pengembangan software sebagian benar disebabkan
masalah requirements specification.
The Rock Problem pada pengembangan software

Rekayasa Persyaratan

Proses proses dalam menentukan layanan system yang dibutuhkan

oleh pelanggan dan batasan-batasan dalam operasional dan
pengembangannya.
Requirements sendiri adalah gambaran dari layanan system dan
batasan yang muncul selama proses requiremen engineering.

Apa itu requirement?

Bisa berarti kebutukan atau prasyarat (Ian Summerville)

Deskripsi layanan dan batasan software/system.
Pernyataan tingkat tinggi dan abstrak mengenai layanan yang harus
diberikan system atau mengenai batasan system
Proses menemukan, menganalisis, mendokumentasikan dan
memeriksa layanan dan batasan ini disebut sebagai requirement
engineering.
 Dasar atau acuan yang dianggap sebai requirement, adalah:
- Penawaran kontrak yang harus terbuka dan jelas interpretasinya.
- Kontrak itu sendiri yang harus didefinisikan secara detil.

Tipe-Tipe Requirement

Use Requirements, merupakan pernyataan, dalam bahasa natural

ditambah diagram, mengena apa yang kita harapkan disediakan oleh
sistemdan batasan operasinya.
System Requirements, menentukan layanan dan batasan system
secara rinci. Dokumen persyaratan system, yang kadangkala disebut
spesifikasi fungsional harus tepat. Dokumen ini bias berlaku sebagai
kontrak antara pembeli system dan pengmbang perangkat lunak.

Requirement Elication

Adalah proses mengumpulkan dan memahami requirements dari user.

Kadang masalah yang muncul berakar dari gap masalah knowledge
domain (perbedaan disiplin ilmu yang dimiliki).
Customer adalah expert pada domain yang softwarenya ingin
dikembangkan (domain specialist), di lain pihak sang pengembang
(requirements analyst) adakalanya semua sekali buta terhadap
knowledge domain tersebut, meskipun tentu memahami dengan benar
bagaimana sebuah software harus dikembangkan.
Gap knowledge domain tersebut yang diharapkan bias diatasi dengan
adanya interaksi terus menerima dan berulang (literasi) antara
pengembang dan customer.
Proses interaksi tersebut kemudian dimodelkan menjadi beberapa
teknik dan metodologi diantaranya adalah interviewing brainstorming,
prototyping, use case, dsb.

Metode Requirements Elication

Observation
Interviewng
Brainstorming
Prototyping
Storyboarding
Use Case Analysis

Requirements Specification
 Setelah masalah berhasil dipahami, pengembang mendeskripsikannya
dalam bentuk dokumen spesifikasi dokumen.
Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh
customer, dan sama sekali tidak membahas bagaimana metode
pengambangannya.
IEEE mengeluarkan standard untuk dokumen spesifikasi requirements
yang terkenal dengan nama IEEE Recommended Prctice for Software
Requirements Specification (IEEE-830).
Dokumen spesifikasi requirements bias berisi functional requirements,
performance requirements, external interface requirements, design
constraints, maupun quality requirements.

Requirements Validation & Verification

Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua

usaha
- Validation (validasi), yaitu proses untuk memastikan bahwa
requirements yang benar sudah ditulis.
- Verification (verifikasi), yaitu proses untuk memastikan bahwa
requirements sudah ditulis dengan benar.
Proses validasi dan verifikasi ini melibatkan customer (user) sebagai
pihak yang menilai dan member feedback berhubungan dengan
requirements.

Jenis-Jenis Requirement

1. Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi
system terhadap input dan apa yang harus dilakukan system pada
situasi khusus (kebutuhan system dilihat dari kacamata pengguna).
2. Kebutuhan Non-Fungsional
Kendala pada pelayanan atau fungsi system seperti kendala waktu,
kendala proses pengembangan, standard, dll. Contoh kehandalan,
waktu respond an kebutuhan storage. Contoh kendala seperti
keterbatasan kemampuan peralatan I/O, representasi system dll.

Jenis Fungsional Requirement

Misalnya pada SIAKA Online UIN Alauddin.

- Mahasiswa melakukan pembayaran SPP ke Bank BNI.
- Sistem akan mendeteksi mahasiswa yang membayar dengan
membuka menu KRS nya, jika tidak bayar menu KRS tidak dapat
dibuka.
 - System akan membuat penjadwalan Kuliah serta Absensi Kuliah.
- Sistem akan memantau persentase kehadiran Mahasiswa dan
Dosen.

Dokumen Software Requirement

Requirement Elication akan menghasilkan dokumen Model Sistem.

Requirement Specification akan menghasilkan dokumen User &
System Requirement.
Requirement Verification & Validation akan menghasilkan dokumen
Document Requirement.

Standar Requirement Document

1. Pendahuluan
1.1. Tujuan Dokumen Persyaratan
1.2. Cakupan Produk
1.3. Defenisi, Akronim dan Singkatan
2. Deskripsi Umum
2.1. Perspektif Produk
2.2. Fungsi Produk
2.3. Karakteristik User
2.4. Batasan-Batasan Umum
2.5. Asumsi dan Ketergantungan

Standar Requirement Document

1. Persyaratan Khusus, yang mencakup persyaratan fungsional, non-

fungsional dan interface. Ini jelas bagian dokumen paling penting
tetapi karena beragamnya praktek organisasi, tidaklah tepat untuk
mendefinisikan struktur standar bagian ini.
2. Lampiran
3. Indeks