REKAYASA KEBUTUHAN

KELOMPOK I

BUDI KISTIANTO 1511010038

IRFAN SANUSI 1611010101
RITA SARI 1611010015

INSTITUT INFORMATIKA & BISNIS DARMAJAYA

FAKULTAS ILMU KOMPUTER

JURUSAN TEKNIK INFORMATIKA

2018
Pemodelan Analisis Dalam Rekayasa Perangkat Lunak
Analisis Kebutuhan
Pemodelan Analisis | Rekayasa Perangkat Lunak - Need Assessment (analisis kebutuhan)
merupakan suatu cara / metode untuk dapat mengetahui perbedaan antara kondisi yang
diinginkan ataupun seharusnya atau diharapkan dengan kondisi yang ada (what is). Kondisi yang
diinginkan seringkali disebut dengan sebutan kondisi ideal, sedangkan kondisi yang ada,
seringkali disebut dengan sebuthan kondisi riil atau kondisi nyata.
Terdapat beberapa hal yang melekat pada pengertian pemodelan analisis (need assessment)
ini. 1.  need assessment ialah suatu proses yang artinya terdapat rangkaian kegiatan di dalam
pelaksanaan need assessment. Need assessement ini bukanlah suatu hasil, namun tetapi
merupakan aktivitas tertentu di dalam upaya mengambil suatu keputusan tertentu. 2. ;kebutuhan
itu sendiri pada hakikatnya merupakan kesenjangan dianatara harapan dan kenyataan. Dengan
hal demikian maka , need assessment adalah suatu kegiatan dalam mengumpulkan informasi
mengenai kesenjangan yang seharusnya dimilikidengan apa yang telah dimiliki.
Rekayasa dimulai dengan suaru rangkaian tugas pemodelan yang membawa keopada suatu
spesifikasi lengkap dari persyaratan represntasi dan representasi desain yang komprehensif bagi
perangkat lunak yang dibangun. Model Analisis yang sebenarnya merupakan serangkaian
model , merupakan serangkaian teknis yang pertama dari sistem. Saat ini terdapat 2 yang
mendominasi landskap pemodelan analisis 1. Analisis terstruktur => merupakan metode
pemodelan klasik , analisis terstruktur ini merupakan aktivitas pembangunan model2. Analisis
berorientasi Objek .

Class diagram
adalah model statis yang menggambarkan struktur dan deskripsi class serta hubungannya antara
class.  Class diagram mirip ER-Diagram pada perancangan database, bedanya pada ER-diagram
tdk terdapat operasi/methode tapi hanya atribut. Class  terdiri dari nama kelas, atribut dan
operasi/methode.
Atribut dan operation (metoda) dapat memiliki salah satu sifat berikut :

1. Private, hanya bisa dipanggil dari dlm kelas itu sendiri.  methode/atribut diawali “-“.
2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan  class turunannya.
methode diawali dg tanda “#”.
3. Public, dapat dipanggil  dari semua objek. methode/atribut diawali tanda “+”

Tabel berikut ini penjelasan symbol relationships antar class yg digunakan pada diagram class 
Relasi  Generalisasi  digunakan dalam hubungan antara kelas induk dengan kelas turunan
( inherited) .
Relasi agregasi digunakan ketika satu kelas dibentuk (terdiri dari ) dari kelas kelas lain.
Relationship Multiplicity
Mutiplicity atau multiplisitas menunjukkan jumlah suatu objek yang bisa berhubungan dengan
objek lain.

Contoh Class Diagram

Diagram Status (Diagram State)

Diagram status atau state diagram atau statechart diagram menunjukkan kondisi yang dapat
dialami atau terjadi pada sebuah objek sehingga setiap objek memiliki sebuah diagram status.
Diagram status diadopsi dari penggambaran kondisi mesin status (state machine) yang
menggambarkan status apa saja yang dialami oleh mesin, misalnya mesin pembelian kopi
dengan uang koin.

Diagram Status mengambarkan seluruh state/status yang memungkinkan obyek-obyek dalam

class dapat dimiliki dan kejadian-kejadian yang menyebabkan satus berubah. Perubahan dalam
suatu state disebut juga transisi (transition). Suatu transisi juga dapat memiliki sebuah aksi yang
dihubungkan pada status, lebih spesifik apa yang harus dilakukan dalam hubungannya dengan
transisi status. Pada diagram ini, perilaku sistem ditunjukkan. Sebuah status adalah kondisi
selama hidup objek atau interaksi selama memenuhi suatu kondisi, melaksanakan suatu aksi, atau
menunggu suatu kejadaian.

Simbol-simbol yang ada pada diagram status adalah sebagai berikut:

Status, Event, dan Transisi
Objek pada sistem mengubah statusnya untuk merespon event/kejadian dan waktu. Secara
umum, pendeteksian sebuah kejadian dapat menyebabkan sebuah objek bergerak dari satu status
ke status yang lain. Keadaaan ini disebut transisi.
Di bawah ini contoh diagram status untuk objek Order. Sistem diawali pada status pemeriksaan
yang akan melakukan kegiatan "periksa item barang." Setelah itu memeriksa apakah item
tersedia atau tidak tersedia. Jika item tersedia, maka ke status pengiriman kemudian ke status
penerimaan. Jika tidak tersedia maka ke status Batal.

Composite State
Jika diagram status akan digunakan untuk sistem yang kompleks, maka perlu penyederhanaan.
Salah satu penggunaannya adalah sub status. Sub status dikelompokkan bersama-sama dalam
status berdekatan karena penggunaan properties tertentu secara bersama-sama menjadi sebuah
„super state‟. Composite state didekomposisi menjadi dua atau lebih sub status bersamaan atau
menjadi sub status yang terpisah.

Pola Tahapan-Tahapan Rekayasa Perangkat Lunak

Seperti telah disebutkan, meskipun dalam pendekatan berbeda-beda, namun model-model di atas
memiliki kesamaan, yaitu menggunakan pola tahapan analysis – design – coding(construction) –
testing – maintenance.

1. Analisis
Analisis sistem adalah sebuah teknik pemecahan masalah yang menguraikan sebuah sistem
menjadi komponen-komponennya dengan tujuan mempelajari seberapa bagus komponen-
komponen tersebut bekerja dan berinteraksi untuk meraih tujuan mereka.
Analisis mungkin adalah bagian terpenting dari proses rekayasa perangkat lunak. Karena semua
proses lanjutan akan sangat bergantung pada baik tidaknya hasil analisis. Ada satu bagian
penting yang biasanya dilakukan dalam tahapan analisis yaitu pemodelan proses bisnis. 

Model proses adalah model yang memfokuskan pada seluruh proses di dalam sistem yang
mentransformasikan data menjadi informasi (Harris, 2003). Model proses juga menunjukkan
aliran data yang masuk dan keluar pada suatu proses. Biasanya model ini digambarkan dalam
bentu Diagram Arus Data (Data Flow Diagram / DFD). DFD meyajikan gambaran apa yang
manusia, proses dan prosedur lakukan untuk mentransformasi data menjadi informasi.

External Entity melambangkan sumber data (dari mana data berasal) atau penerima informasi
(tujuan akhir dari data). Contoh external entity antara lain konsumen yang memesan suatu
produk, manajer yang mengevaluasi laporan penjualan mingguan, dan lain-lain.

2. Disain
Disain perangkat lunak adalah tugas, tahapan atau aktivitas yang difokuskan pada spesifikasi
detil dari solusi berbasis computer (Whitten et al, 2004). Disain perangkat lunak sering juga
disebut sebagai physical design. Jika tahapan analisis sistem menekankan pada masalah bisnis
(business rule), maka sebaliknya disain perangkat lunak fokus pada sisi teknis dan implementasi
sebuah perangkat lunak (Whitten et al, 2004).

Output utama dari tahapan disain perangkat lunak adalah spesifikasi disain. Spesifikasi ini
meliputi spesifikasi disain umum yang akan disampaikan kepada stakeholder sistem dan
spesifikasi disain rinci yang akan digunakan pada tahap implementasi. Spesifikasi disain umum
hanya berisi gambaran umum agar stakeholder sistem mengerti akan seperti apa perangkat lunak
yang akan dibangun.

3. Konstruksi
Konstruksi adalah tahapan menerjemahkan hasil disain logis dan fisik ke dalam kode-kode
program computer. Buku ini sebagian besar berisi tentang bagian ini.
4. Pengujian
Pengujian sistem melibatkan semua kelompok pengguna yang telah direncanakan pada tahap
sebelumnya. Pengujian tingkat penerimaan terhadap perangkat lunak akan berakhir ketika dirasa
semua kelompok pengguna menyatakan bisa menerima perangkat lunak tersebut berdasarkan
kriteria-kriteria yang telah ditetapkan.

5. Perawatan dan Konfigurasi

Ketika sebuah perangkat lunak telah dianggap layak untuk dijalankan, maka tahapan baru
menjadi muncul yaitu perawatan perangkat lunak. 

Ada beberapa tipe perawatan yang biasa dikenal dalam dunia perangkat lunak seperti terlihat
pada diagram di Gambar 3.12.

a) Tipe perawatan corrective dilakukan jika terjadi kesalahan atau biasa dikenal sebagai bugs.
Perawatan bisa dilakukan dengan memperbaiki kode program, menambah bagian yang
dirasa perlu atau malah menghilangkan bagian-bagian tertentu.
b) Tipe perawatan routine biasa juga disebut preventive maintenance dilakukan secara rutin
untuk melihat kinerja perangkat lunak ada atau tidak ada kesalahan.
c) Tipe perawatan sistem upgrade dilakukan jika ada perubahan dari komponen-komponen
yang terlibat dalam perangkat lunak tersebut. Sebagai contoh perubahan platform sistem
operasi dari versi lama ke versi baru menyebabkan perangkat lunak harus diupgrade.

Negosiasi Kebutuhan Menyelesaikan masalah yang sehubungan dengan kebutuhan yang menjadi
konflik antara dua pihak yang membutuhkan fitur yang saling bertentangan, antara kebutuhan
dan sumber daya, atau antara kebutuhan fungsional dan non fungsional.
Verifikasi Dan Validasi Perangkat Lunak
Verifikasi adalah proses pemeriksaan apakah logika operasional model (program komputer)
sesuai dengan logika diagram alur. Kalimat sederhananya, apakah ada kesalahan dalam
program? (Hoover dan Perry, 1989); verifikasi adalah pemeriksaan apakah program komputer
simulasi berjalan sesuai dengan yang diinginkan, dengan pemeriksaan program komputer.
Verifikasi memeriksa penerjemahan model simulasi konseptual (diagram alur dan asumsi) ke
dalam bahasa pemrograman secara benar (Law dan Kelton, 1991) .
Validasi adalah proses penentuan apakah model, sebagai konseptualisasi atau abstraksi,
merupakan representasi berarti dan akurat dari sistem nyata? (Hoover dan Perry, 1989); validasi
adalah penentuan apakah mode konseptual simulasi (sebagai tandingan program komputer)
adalah representasi akurat dari sistem nyata yang sedang dimodelkan (Law dan Kelton, 1991).
Perangkat Lunak Merupakan program-program komputer dan dokumentasi yang berkaitan.
Produk perangkat lunak dibuat untuk pelanggan tertentu ataupun untuk pasar umum Produk
perangkat lunak mengadopsi pendekatan yang sistematis dan terorganisir terhadap pekerjaannya
dan menggunakan tool yang sesuai serta teknik yang ditentukan berdasarkan masalah yang akan
dipecahkan, kendala pengembangan dan sumber daya yang tersedia.

Ketika membangun model simulasi sistem nyata, kita harus melewati beberapa tahapan atau
level pemodelan. Seperti yang dapat dilihat pada Gambar diatas, pertama kita harus membangun
model konseptual yang memuat elemen sistem nyata. Dari model konseptual ini kita membangun
model logika yang memuat relasi logis antara elemen sistem juga variabel
eksogenus yang mempengaruhi sistem. Model kedua ini sering disebut sebagai model diagram
alur. Menggunakan model diagram alur ini, lalu dikembangkan program komputer, yang disebut
juga sebagai model simulasi, yang akan mengeksekusi model diagram alur. Pengembangan
model simulasi merupakan proses iteratif dengan beberapa perubahan kecil pada setiap tahap.
Dasar iterasi antara model yang berbeda adalah kesuksesan atau kegagalan ketika verifikasi dan
validasi setiap model. Ketika validasi model dilakukan, kita mengembangkan representasi
kredibel sistem nyata, ketika verifikasi dilakukan kita memeriksa apakah logika model
diimplementasikan dengan benar atau tidak. Karena verifikasi dan validasi berbeda, teknik yang
digunakan untuk yang satu tidak selalu bermanfaat untuk yang lain.
Baik untuk verifikasi atau validasi model, kita harus membangun sekumpulan kriteria untuk
menilai apakah diagram alur model dan logika internal adalah benar dan apakah model
konseptual representasi valid dari sistem nyata. Bersamaan dengan kriteria evaluasi model, kita
harus spesifikasikan siapa yang akan mengaplikasikan kriteria dan menilai seberapa dekat
kriteria itu memenuhi apa yang sebenarnya.