BAB 9 UML (UNIFIED MODELLING LANGUAGE)

Pengertian UML : ” UML (Unified Modelling Language) merupakan bahasa pemodelan yang berorientasi obyek dan digunakan untuk memvisualisasikan rancangan perangkat lunak yang akan dibuat, UML saat ini banyak digunakan oleh perusahaan besar di bidang IT”
UML terdiri atas :
- Activity Diagram
- Sequential Diagram
- Class Diagram
- Use Case Diagram

Berikut contoh UML Sistem delivery makanan

• USE CASE

• CLASS DIAGRAM

•  SEQUENCE DIAGRAM

Pemesanan

Pengiriman

Pembayaran

•  ACTIVITY DIAGRAM

BAB 8 ERD (ENTITY RELATION DIAGRAM)

ERD atau Entity Relationship Diagram adalah Model Data yang menggambarkan hubungan antara entity satu dengan entity lain yang dihubungkan dengan relasi tertentu. Ada 3 simbol yang digunakan dalam ERD, yaitu :

- Entity : Dilambangkan dengan bentuk persegi panjang, entity ialah objek yang mewakili sesuatu yang nyata/stakeholder sistem yang kita buat.
- Relasi : Dilambangkan dengan bentuk layang-layang. Relasi merupakan hubungan antar entitas, dan biasanya diwakili dengan kata kerja.
- Atribut : Dilambangkan dengan bentuk elips. Atribut merupakan obyek yang menjadi isi/bagian dari sebuah entitas.

ERD SISTEM DELIVERY MAKANAN

BAB 7 DFD ( DATA FLOW DIAGARAM )

A.   PENGERTIAN DFD

      Data Flow Diagram (DFD) adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data sistem, yang penggunaannya sangat membantu untuk memahami sistem secara logika, tersruktur dan jelas.

        DFD merupakan alat bantu dalam menggambarkan atau menjelaskan sistem yang sedang berjalan logis. Dalam sumber lain dikatakan bahwa DFD ini merupakan salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. 

     DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.

B.  BENTUK DFD

1.    Physical Data Flow Diagram (PDFD)

PDFD lebih tepat digunakan untuk menggambarkan sistem yang ada (sistem yang lama). Penekanan dari PDFD adalah bagaimana proses-proses dari sistem diterapkan (dengan cara apa, oleh siapa dan dimana), termasuk proses-proses manual. Dengan menggunakan PDFD, bagaimana proses sistem yang ada akan lebih dapat digambarkan dan dikomunikasikan kepada pemakai sistem, sehingga analis system akan dapat memperoleh gambaran yang jelas bagaimana sistem tersebut bekerja. 

Untuk memperoleh gambaran bagaimana sistem yang ada diterapkan, PDFD harus memuat sebagai berikut :

• Proses-proses manual juga digambarkan

• Nama dari arus data harus menunjukkan fakta penerapannya semacam nomor formulir dan medianya (misalnya telpon atau surat). Nama arus data mungkin juga menerangkan tentang waktu mengalirnya (misalnya harian atau mingguan). Dengan kata lain, nama dari arus data harus memuat keterangan yang cukup terinci untuk menunjukkan bagaimana pemakai sistem memahami kerja dari sistem.

• Simpanan data dapat menunjukkan simpanan non komputer, misalnya kotak in/out yang berfngsi sebagai buffer dari proses serentak yang beroperasi dengan kecepatan berbeda, sehingga ada sebuah data yang harus menunggu di buffer.

• Nama dari simpanan data harus menunjukkan tipe penerapannya apakah secara manual atau komputerisasi. Secara manual misalnya dapat menunjukkan buku catatan, meja pekerja atau kotak in/out. Sedang secara komputerisasi misalnya menunjukkan file urut, file ISAM, file database dan lain sebagainya.

• Proses harus menunjukkan nama dari pemroses (processor), yaitu orang, departemen, sistem komputer atau nama program komputer yang mengeksekusi proses tersebut.

2.    Logical Data Flow Diagram (LDFD)

LDFD lebih tepat digunakan untuk menggambarkan sistem yang akan diusulkan (sistem yang baru). LDFD tidak menekankan pada bagaimana sistem diterapkan, tetapi penekanannya hanya pada logika dari kebutuhan-kebutuhan sistem, yaitu Pendekatan Perancangan Terstruktur dan Data Flow Diagram proses-proses apa secara logika yang dibutuhkan oleh sistem. 

Karena sistem yang diusulkan belum tentu diterima oleh pemakai sistem dan biasanya sistem yang diusulkan terdiri dari beberapa alternatif, maka penggambaran sistem secara logika terlebih dahulu tanpa berkepentingan dengan penerapannya secara fisik akan lebih mengena dan menghemat waktu penggambarannya dibandingkan dengan PDFD. Untuk sistem komputerisasi, penggambaran LDFD yang hanya menunjukkan kebutuhan proses dari sistem yang diusulkan secara logika, biasanya proses-proses yang digambarkan hanya merupakan proses-proses secara komputer saja.

http://fahmiinformatika.blogspot.com/2011/11/sistem-terstruktur-erd.html

http://jendral-dot-com.blogspot.com/2011/11/perbedaan-dfd-secara-fisik-dan-logikal.html

DFD SISTEM DELIVERY MAKANAN

DFD konteks

DFD Level 1

DFD Level 2

• Pemesanan

• Transaksi Pembayaran

BAB 6 SPESIFIKASI KEBUTUHAN

SPESIFIKASI KEBUTUHAN

Spesifikasi kebutuhan merupakan suatu proses memformalisasikan sekumpulan kebutuhan, baik fungsional maupun non-fungsional, dari suatu sistem yang hendak dibangun ke dalam suatu dokumen. Sejalan dengan proses rekayasa kebutuhan secara keseluruhan, elisitasi kebutuhan bertujuan untuk:

1. Menyediakan umpan balik kepada konsumen.

2. Memecah permasalahan ke dalam komponen yang lebih kecil.

3. Masukan untuk tahap spesifikasi rancangan.

4. Memudahkan pengecekan validasi produk.

MANFAAT SPESIFIKASI KEBUTUHAN

Menurut Standar IEEE 830(1998), manfaat dari dokumen spesifikasi yang baik adalah :

1. Dokumen spesifikasi dapat digunakan sebagai dasar persetujuan antara konsumen dan supplier tentang hal-hal apa saja yang dapat ditangani oleh perangkat lunak yang akan dibangun.

2. Dokumen spesifikasi dapat mengurangi usaha yang harus dikeluarkan dalam pembangunan perangkat lunak.

3. Dokumen spesifikasi dapat digunakan sebagai dasar untuk perkiraan biaya dan jadwal.

4. Dokumen spesifikasi dapat digunakan sebagai panduan untuk proses validasi dan verifikasi.

5. Dokumen spesifikasi dapat memfasilitasi pergantian/peralihan.

6. Dokumen spesifikasi dapat digunakan sebagai dasar untuk pengembangan lebih lanjut.

Sumber:

http://annisajumpers.blogspot.com/2013/01/spesifikasi-kebutuhan-dalam-rekayasa.html

A.   ALUR SISTEM DELIVERY MAKANAN :

1. Pelanggan memesan makanan dengan menelpon petugas melalui Call Delivery yang telah disediakan.
2. Pelanggan menginformasikan makanan yang dipesan, Nama dan Alamat sebagai data pelanggan.
3. Petugas mendapatkan informasi makanan yang dipesan (Fix), selanjutnya Petugas membuat / menyiapkan pesanan yang telah dipesan oleh pelanggan.
4. Petugas akan memberitahukan ke sistem bahwa makanan yang dipesan telah dibuat dan siap di antar.
5. Sistem akan memberitahukan ke pengantar makanan bahwa pesanan pelanggan siap dikirim.
6. Delivery Man akan menerima Nota tagihan pesanan dan mengantarkan pesanan sesuai alamat pelanggan.
7. Delivery Man akan menerima pembayaran oleh pelanggan dan pelanggan menerima pesanannya.

• Sub Kasus (Jika Bahan Makanan telah habis)

1. Petugas menginformasikan pesanan pelanggan ke sistem untuk verifikasi pemesanan. 
2. Sistem dapat memberitahukan petugas karena persediaan bahan makanan habis.

• Sub Kasus (Jika Makanan yang dipesan habis)

1. Petugas menginformasikan kepada pelanggan delivery jika makanan yang dipesan tidak dapat dipesan hari ini.
2. Petugas Memastikan setiap pelanggan sudah punya alternatif pesanan, jika makanan yang dipesan tidak ada. Ini penting untuk menghemat waktu pemesanan.

B.  KEBUTUHAN FUNGSIONAL

• Petugas dapat berrkomunikasi dengan  pelanggan --- (Pilihan)
• Petugas mampu penginputan daftar jenis pesanan makanan --- (Pilihan)
• Mencetak nota / bon pemesanan --- (Harus ada)
• Menghasilkan Laporan pesanan baik hardcopy maupun softcopy. --- (Harus ada)
• Petugas dapat melihat data pelanggan dan data jenis makanan serta pemesan delivery --- (Pilihan)
• Pemberitahuan bahan makanan habis --- (Harus ada)

C.  KEBUTUHAN NON FUNGSIONAL

• Daftar jenis makanan yang dipesan maksimal 15 jenis makanan.
• Pelanggan Memesan Makanan maksimal 3 jenis makanan.
• Pelanggan yang memesan melalui delivery dibatasi maksimal 750 orang. 
• Waktu respon antara user menginputkan data dan tampilan yang dihasilkan berdasar input data.
• Kebutuhan keamanan (Safety). 

BAB 5 ELISITASI KEBUTUHAN

ELISITASI KEBUTUHAN
Elisitasi kebutuhan adalah sekumpulan aktivitas yang ditunjukkan untuk menemukan kebutuhan suatu sistem melalui komunikasi dengan pelanggan, pengguna sistem dan pihak lain yang memiliki kepentingan dalam pengembangan sistem (Sommerville and Sawyer 1997). Sejalan dengan proses rekayasa kebutuhan secara keseluruhan, elisitasi kebutuhan bertujuan untuk (Leffingwel, 2000) :
1. Mengetahui masalah apa saja yang perlu dipecahkan dan mengenali batasan-batasan sistem.
2. Mengenali siapa saja para pemangku kepentingan.
3. Mengenali tujuan dari sistem yaitu sasaran-sasaran yang harus sistem.

AKTIVITAS 

1. Penemuan kebutuhan – proses interaksi dengan stakeholder untuk mengumpulkan kebutuhan mereka
2. Pengelompokan dan pengorganisasian kebutuhan – mengkoleksi kebutuhan, mengelompokkan kebutuhan, mengorganisasikan ke dalam kelompok yang koheren.
3. Prioritasi dan negoisasi kebutuhan – prioritas kebutuhan dan menemukan serta memecahkan konflik kebutuhan melalui proses negoisasi
4. Dokumentasi kebutuhan – kebutuhan didokumentasikan dan menjadi masukan untuk siklus spriral selanjutnya

LANGKAH ELISITASI

1. Indetifikasi orang yang akan membantu menemukan kebutuhan dan memahami organisasi mereka. Menilai kelayakan bisnis dan teknis untuk sistem yang diusulkan
2. Menentukan lingkungan teknis ke mana sistem atau produk akan ditempatkan
3. Identifikasi ranah permasalahan, yaitu karakteristik lingkungan bisnis yang spesifik ke ranah aplikasi.
4. Menentukan satu atau lebih metode elisitasi kebutuhan, misalnya wawancara, kelompok fokus, pertemuan tim
5. Meminta partisipasi dari banyak orang sehingga dapat mereduksi dampak dari kebutuhan yang bias dapat teridentifikasi
6. Mengidentifikasi kebutuhan yang ambigu dan menyelesaikannya
7. Membuat skenario penggunaan untuk memantuk stakeholder mengidentifikasi kebutuhan utama

TEKNIK ELISITASI

• Tradisional

        1. Wawancara

        2. Kuisioner

        3. Observasi

        4. Pengamatan dokumen

• Elisitasi Berkelompok

        1. Brainstorming

        2. Joint Application Design (JAD)

        3. Prototyping 

• Model Driven

        1. Goal Based Method

        2. Scenario Based Method

VIEWPOINT

1. Sudut pandang
2. Pihak-pihak yang meminta atau menggunakan layanan yang diberkan atau disediakan oleh sistem
3. Digunakan untuk mengelompokkan stakeholder dan sumber-sumber kebutuhan lain
4. Interactor viewpoint – orang atau sistem lain yang bernteraksi secara langsung dengan sistem (nasabah bank)
5. Indirect viewpoint – stakeholder yang tidak menggunakan sistem tetapi mempengaruhi jalannya sistem (manajemen bank, karyawan keamanan)
6. Domain viewpoint – karakteristik ranah dan batasan yang mempengaruhi kebutuhan sistem.

TUGAS........
Contoh Kasus

1.   TOPIK :

Sistem Pemesan Makanan

2.   GAMBARAN UMUM

       Menghadapi persaingan pasar yang semakin ketat, banyak pelaku usaha yang mulai aktif memutar strategi untuk mendapatkan perhatian dari konsumennya. Sekarang pelaku bisnis lebih aktif untuk memanjakan para konsumennya yaitu salah satu strategi dengan memberikan layanan pesan antar guna memenuhi kebutuhan pelanggan.
      Melalui layanan pesan antar, konsumen tidak perlu repot-repot keluar rumah untuk mendapatkan produk atau jasa yang mereka butuhkan. Tidaklah heran bila sekarang ini layanan pesan antar menjadi salah satu strategi jitu yang diambil pelaku usaha untuk meningkatkan omset penjualannya. 
     Strategi ini terbilang cukup efektif, karena para pelaku bisnis bisa mendekatkan perusahaannya dengan para konsumen dan memberikan kemudahan bagi para pelanggan untuk memenuhi kebutuhannya. 

3.  VIEW POINT

4.  TEKNIK ELISITASI

• Joint Application Design (JAD)

Teknik untuk mengembangkan kerja sama, pemahaman, dan kerja tim antara pembeli, pengguna, dan pengembang. Ada empat prinsip JAD:

1.       Kelompok dinamis

2.       Penggunaan visual aid untuk meningkatkan komunikasi dan pemahaman

3.       Melakukan perawatan yang terstruktur, proses yang rasional

4.       Filosofi dokumen “what you see is what yau get”

JAD memiliki dua tahap yang disebut  JAD/Plan dan JAD/Design. Masing-masing tahap terdiri dari tiga fase yaitu penyesuaian, diskusi, dan penutup. JAD dapat mengatasi masalah artikulasi, komunikasi, dan tindakan manusia selama proses elisitasi.

• Hasil Diskusi :

1. Pelanggan memesan makanan dengan menelpon petugas call delivery.
2. Petugas menginformasikan rincian biaya kepada Pelanggan.
3. Petugas  membuatkan pesanan pelanggan.
4. Delivery Man mengantar pesanan dan nota tagihan yang harus di bayar.
5. Pelanggan menerima pesenannya dan melunasi tagihan pemesanan. 

5.  SUMBER REFERENSI

• Referensi I

          http://thesis.binus.ac.id/doc/Bab3/2007-2-00006-AKSI-Bab%203.pdf

• Referensi II

          http://dhwie85.blogspot.com/2013/10/analisis-kinerja-sistem-pemesanan.html

• Referensi III

http://elib.unikom.ac.id/files/disk1/577/jbptunikompp-gdl-muhammadri-28824-16-unikom_m-.pptx

• Referensi IV

          http://annisajumpers.blogspot.com/2013/01/teknik-elisitasi.html

BAB 4 REKAYASAN KEBUTUHAN

1. DEFINISI REKAYASA KEBUTUHAN

Merupakan proses menetapkan layanan yang dibutuhkan konsumen terhadap sistem dan batasan operasi dan pengembangan, kebutuhan sendiri adalah diskripsi layanan sistem dan batasan yang dibangkitkan selama proses rekayasa kebutuhan.

Kegagalan pengembangan software disebabkan karena adaya ketidakkonsistenan (inconsistent), ketidaklengkapan (incomplete), maupun ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan) 
Beberapa hukum requirement enginnering diantaranya

• Hukum Glass (Robert Glass)

Menentukan kebutuhan yang tepat merupakan masalah berat. Kekurangan kebutuhan (requirement deficiences) adalah sumber utama dari kegagalan proyek. Kekurangan kebutuhan menimbulkan masalah di banyak proyek.

• Hukum Boehm Pertama

Kesalahan yang paling sering selama menentukan kebutuhan (requirements) adalah kegiatan desain yang lebih mahal. Studi ini berkaitan dengan analisis kesalahan yang dibuat oleh pengembang. 

• Hukum Boehm kedua

Prototyping (secara signifikan) mengurangi kebutuhan dan kesalahan desain, terutama untuk user interface. Hukum ini menempatkan penekanan pada pengurangan kesalahan. Pengurangan kesalahan membawa penurunan biaya juga.

• Hukum Davis

Nilai dari sebuah model tergantung pada pandangan diambil, tetapi tidak ada yang terbaik untuk semua tujuan. Sebuah model dari realitas membantu untuk menjelaskan pemahaman. 

2. KEGIATAN REKAYASA KEBUTUHAN

•  Studi Kelayakan atau analisis risiko

Studi kelayakan perlu dilakukan sebelum kebutuhan secara resmi diterima. Dalam proses ini, mendapatkan jawaban atas memenuhi kebutuhan sesuai pengetahuan dan teknologi, mempertanyakan biaya yang memadai dari pengembangan kebutuhan. 

• Pengungkapan Kebutuhan dan Prioritas (Requirements elicitation and prioritization)

Kebutuhan harus dikumpulkan dari sumber yang dapat berkontribusi. Kontribusi terutama dari calon pelanggan dan pengguna. Selain itu, pihak ketiga ahli hukum yang berwenang, dan badan standar mungkin memiliki masukan. Namun, Kebutuhan yang diharapkan pengguna harus mendapatkan prioritas utama. Oleh karena itu, harus dipahami siapa pengguna, dan apa keterampilan mereka, motivasi dan lingkungan kerja.

Proses ini tidak mudah karena: batasan sistem sering tidak jelas, klien tidak cukup paham apa yang dibutuhkan dan kebutuhan sering berubah.

• Spesifikasi kebutuhan

a. Kebutuhan fungsional : Menyatakan prilaku yang harus ada pada sistem. 
Ex. pembelian mobil utuk pengiriman barang ke gudang, maka kebutuhan fungsional dari mobil tersebut adalah mobil harus dapat membawa barang ke gudang.

b. Kebutuhan non fungsional : Batasan yang harus ada pada sistem dan bagaimana dalam membentuk sistem tersebut.

Batasan dapat dibagi menjadi dua sub katagori yakni:

1. Performance constraint, batasan ini menunjukan spesifikasi bagaimana sistem bekerja ketika kebutuhan funsional telah bekerja. Ex. pada mobil yang mengangkut barang diatas adalah batasan bahwa minimal daya angkut pada mobil harus lebih dari satu ton.
2. Development constraint, batasan ini menunjukan sebagai pelengkap dari performance constraint. Batasan ini lebih cenderung pada batasan pada level manajemen proyek . Contoh rincian dari waktu , resource, quality.

• Penerimaan, Validasi dan Persetujuan Kebutuhan

Cara terbaik untuk mencapai ini adalah melalui partisipasi pengguna, selalu dimulai dengan definisi kebutuhan. User harus menerima kebutuhan, yakni mempertimbangkan kebutuhan sebagai milik mereka.

Setelah didapat suatu kebutuhan yang teranalisa maka memvalidasi kembali dan meperbaiki apa yang menjadi kekurangan. Meliputi proses identifikasi, menyakin kan kembali, menanggapi dan memperbaiki masalah dari requirements, dan menyatakan bahwa requirement telah dapat diterima.

BAB 3 REKAYASA SISTEM (SYSTEM ENGINEERING)

1.  DEFINISI, TUJUAN, KARAKTERISTIK, ELEMEN DARI SISTEM
Sistem ialah Kumpulan terdiri dari komponen / subsistem yang saling berkaitani dan berinteraksi untuk mencapai tujuan tertentu.
Menurut Bahasa, Sistem berasal dari bahasa latin (systema) dan bahasa yunani (sustema) adalah suatu kesatuan yang terdiri dari komponen atau elemen yang dihubungkan bersama untuk memudahkan aliran informasi, materi atau energi

Susunan sistem

Tujuan Sistem
Untuk Mengorganisasikan sistem informasi yang baru agar dapat mengatasi berbagai masalah yang terjadi pada suatu organisasi, serta memberikan pengertian mengenai suatu bentuk sistem yang ada pada suatu organisasi.
Susunan Sistem

Karakteristik Sistem

• Elemen – elemen (elements)
• Batasan Sistem (boundary)
• Lingkungan Sistem (environments)
• Penghubung (interface)
• Masukan (input)
• Pengolahan (process)
• Keluaran (output)
• Tujuan (goals)

Elemen Pembentuk Sistem
1. Tujuan : Sistem harus memiliki tujuan (Goal).
2. Masukan : Sesuatu yang masuk ke dalam sistem dan menjadi bahan yang diproses.
3. Proses : Melakukan perubahan dari input menjadi output yang berguna dan bernilai.
4. Keluaran : Hasil dari pemrosesan
5. Batas : Pemisah antara sistem dan daerah diluar sistem lingkungan
6. Mekanisme Pengendalian dan Umpan Balik
7. Lingkungan : Segala sesuatu yang berada diluar sistem.

2. REKAYASA SISTEM
Rekayasa Sistem atau System Engineering adalah Aktivitas untuk menetapkan kebutuhan – kebutuhan pada tingkat sistem, kemudian mengalokasikan beberapa bagian dari kebutuhan – kebutuhan tersebut ke satu atau beberapa komponen rekayasa.

Cakupan Rekayasa Sistem meliputi :
1.  Rekayasa Informasi yaitu Rekayasa Sistem yang konteks pekerjaan rekayasanya berfokus pada perusahaan bisnis, meliputi pengumpulan kebutuhan – kebutuhan untuk tingkat bisnis strategis dan tingkat area bisnis

*** Tujuan dari Rekayasa Informasi (Information Engineering)

Mendefinisikan Suatu arsitektur yang memungkinkan bisnis menggunakan informasi secara efektif.

*** Cara untuk mengimplementasikan arsitektur yaitu

• Arsitektur Data adalah Kerangka kerja untuk informasi yang dibutuhkan bisnis/fungsi bisnis.
• Arsitektur Aplikasi adalah Elemen sistem yang mentransformasikan objek pada arsitektur data untuk berbagai keperluan bisnis.
• Infrastruktur Teknologi adalah Fondasi untuk arsitektur data dan aplikasi, mencakup perangkat keras dan lunak yang digunakan untuk mendukung data dan aplikasi.

2.  Rekayasa Produk yaitu Aktivitas pemecahan masalah. Data, fungsi, dan perilaku produk yang diinginkan dicari, dianalisis, dibuat   model kebutuhannya, kemudian dialokasikan ke komponen rekayasa.

Aktivitas dalam Rekayasa Produk : Analisis Sistem, Identifikasi Kebutuhan, Studi Feasibilitas yang meliputi:

• Kelayakan Ekonomis (Evaluasi biaya pengembangan).
• Kelayakan Teknis (Studi mengenai fungsi, sasaran, dan kinerja).
• Kelayakan Legal (Pertimbangan kontrak, pelanggaran).
• Alternatif (Evaluasi pendekatan alternatif).

3. PEMODELAN ARSITEKTUR SISTEM

Template yang digunakan untuk memodelkan arsitektur sistem yaitu

• Antarmuka Pemakai
• Input
• Fungsi dan Kontrol InputSistem
• Output
• Pemeliharaan dan Self-testPemodelan Sistem dan Simulasi

4. PEMODELAN SISTEM DAN SIMULASI

Metode ini banyak penganutnya diantara pengembangan perangkat lunak yang harus membangun perangkat lunak yang kritis untuk keselamatan. Ex : perangkat medis.

5. SPESIFIKASI SISTEM

Dokumen yang menggambarkan fungsi dan kinerja sistem berbasis komputer yang akan dikembangkan, membatasi elemen sistem yang telah dialokasikan, serta memberikan indikasi mengenai perangkat lunak dan konteks sistem keseluruhan dan informasi data dan kontrol yang dimasukkan dan dikeluarkan oleh sistem yang telah digambarkan dalam diagram aliran arsitektur.

BAB 2 MODEL PROSES PERANGKAT LUNAK

Proses Perangkat Lunak memiliki tujuan untuk pengembangan perangkat lunak, dimana setiap aktifitas bersifat saling terkait (koheren) untuk menspesifikasikan, merancang, mengimplemetasikan dan pengujian sistem perangkat lunak. Aktifitas proses perangkat lunak diantaranya initial, repetable ,defined, managed, dan optimizing

1. MODEL PROSES PERANGKAT LUNAK

Model Proses Perangkat Lunak merupakan suatu representasi proses perangkat lunak yang disederhanakan, dipresentasikan dan perspektif khusus. Contoh perspektif proses:

    1. Perspektif Alur-kerja (workflow) -  barisan kegiatan

    2. Perspektif Alur Data (Data flow) – alur informasi

    3. Perspektif Peran/Aksi – siapa melakukan apa.

Menurut Ian Somerville, Model proses secara umum terdiri dari:

• Pendekatan Model Proses : Memisahkan dan membedakan antara spesifikasi dan pengembangan.
• Pengembangan yang berevolusi : Melanjutkan Aktifitas satu dan yang lainnya dari Spesifikasi dan pengembangan serta  validasi secara cepat.
• Pengembangan sistem Formal : Model sistem matematika yang ditransformasikan ke implementasi.
• Pengembangan Sstem berbasis Re-use (penggunaan ulang) komponen.

2. MODEL SEKUENSIAL LINIER (Waterfall)

Pendekatan perkembangan perangkat lunak yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem.
Aktifitas Model Sekuensial Linier meliputi :

Keuntungan : Sederhana, Langkah terurut, fokus dan Mudah diikuti.

Kerugian

• Mebutuhkan waktu yang lama sehingga terlambat (program implementasi)

• Tidak Fleksibe (jarang ikut aliran terurut)

• Sulit menghadapi kebutuhan customer yang eksplisit.

3. MODEL PROTOTIPE

Aktifitas yang dimulai pengumpulan kebutuhan. Pengembang dan pelanggan bertemu dan mendefinisikan obyektif keseluruhan dari perangkat lunak, dan mengidentifikasikan segala kebutuhan.

Keuntungan

• Mudah dan cepat identifikasi kebutuhan customer.

• Customer mengecek protipe di awal tingkatan.

Kerugian

• Bergantung  pada Customer/pelanggan.

• Developer biasa ikut membuat produk didasarkan prototipe.

4. MODEL RAD

RAD (Rapid Application Development) adalah model proses perkembangan perangkat lunak sekuensial linier yang menekankan siklus perkembangan yang sangat pendek.

Pendekatan RAD melingkupi fase :

Keuntungan : Waktu pembuatan pendek, Pengurangan biaya.

Kerugian :

• Butuh sumber cukup bila proyek yang berskala.

• Kualitasnya tergantung pada kualitas dari komponen yang ada.

• Pembuatan Software adalah spesifik proyek, dan tidak boleh dimodulkan secara baik.

6. MODEL PROSES PERANGKAT LUNAK EVOLUSIONER

a. Incremental Model

Model ini mengkombinasikan antara linear sequential model dengan filosofi iteratif pada prototyping.  Pada masing-masing sekuen linear menghasilkan perangkat lunak yang semakin meningkat kompleksitasnya.

Kelemahan incremental model

• Hanya akan berhasil jika tidak ada staffing, penerapan secara menyeluruh

• Penambahan staf dilakukan jika hasil incremental akan dikembangkan lebih lanjut

b. Spiral Model

Model ini menggabungkan antara sifat alami iterasi dari prototyping dengan aspek sistematik dan terkendali daari linear sequential model. Model ini memberi peluang untuk pengembangan cepat.

Kelemahan spiral model:

• Sulit untuk meyakinkan pemakai bahwa penggunaan pendekatan ini akan dapat dikendalikan..

• Memerlukan tenaga ahli untuk memperkirakan resiko.

• Belum terbukti apakah metode ini cukup efisien.

c. Model Rakitan Komponen

Model ini menggabungkan beberapa karakter model spiral. Model ini bersifat evolusioner, sehingga membutuhkan pendekatan interaktif untk menciptakan perangkat lunak. Aktivitas nodel ini sebagai berikut:

Mengidentifikasi calon-calon komponen, Melihat komponen-komponen dalam pustaka, Mengekstrak komponen jika ada, Membangun komponen jika tidak ada,  Menyimpan komponen baru pada pustaka, Mengkontruksi iterasi ke-n dari sistem

d. Model Perkembangan Konkuren (Rekayasa Konkuren)

Model proses yang konkuren dapat disajikan secara skematis sebagai sederetan aktivitas teknik mayor, tugas – tugas, dan keadaan yang lainnya.

e. Model Formal

Metode yang mencakup sekumpulan aktivitas yang membawa kepada spesifikasi metematis perangkat lunak computer

Kelemahan :

• Pengembangan model format banyak memakan waktu dan mahal.

• Perlu latihan yang ekstensif.

7. TEKNIK GENERASI KEEMPAT

Menggunakan perangkat bantu yang akan membuat kode sumber secara otomatis berdasarkan spesifikasi dari pengembang perangkat lunak. Hanya digunakan untuk mengembangkan perangkat lunak yang menggunakan bentuk bahasa khusus / notasi grafik yang diselesaikan dengan syarat yang dimengerti pemakai.

Cakupan aktivitas 4GT:

1. Pengumpulan kebutuhan.
2. Translasi kebutuhan menjadi prototype operasional / langsung melakukan implementasi.
3. Dibutuhkan strategi perancangan sistem jika aplikasi cukup besar.
4. Pengujian.
5. Membuat dokumentasi.
6. Melaksanakan seluruh aktivitas untuk mengintegrasikan solusi pada paradigma rekayasa perangkat lunak lainnya.

BAB 1 PENGERTIAN RPL (REKAYASA PERANGKAT LUNAK)

Latar belakang munculnya Rekayasa Perangkat Lunak, adanya kebutuhan dari manusia dengan tuntutan adanya perkembangan hardware dan software yang semakin meningkat. Ada beberapa kegiatan Rekayasa Perangkat Lunak  yang senantiasa pada model proses apapun yaitu identifikasi kebutuhan, desain, pengkodean, penerapan, dan pemeliharaan.

1. PENGERTIAN RPL (Rekayasa Perangkat Lunak)

    Perangkat Lunak berasal dari 2 kata yaitu

• Perangkat Lunak (Software) adalah source code pada suatu program atau sistem.
• Engineering (Rekayasa) adalah aplikasi terhadap pendekatan sistematis yang berdasarkan ilmu pengetahuan dan matematis serta tentang produksi terhadap struktur, mesin, produk, proses, atau sistem.

RPL (Rekayasa Perangkat Lunak) merupakan pendekatan sistematis dan matematis untuk membangun, memelihara, dan mengenyahkan perangkat lunak menjadi yang handal/bermutu, tepat waktu, dan biaya optimal.

2. KARAKTERISTIK DARI PERANGKAT LUNAK

    Karakteristik dari Perangkat Lunak sebagai berikut :

• Maintability (Dapat dirawat dan dipelihara), memenuhi perubahan kebutuhan.
• Dependability, dapat dipercaya.
• Efisiensi, harus Efisien.
• Usability, dapat digunakan sesuai yang direncanakan.

3. JENIS PERANGKAT LUNAK

• Menurut cara pembuatannya, Perangkat lunak dapat dikelompokkan menjadi 2  kategori yaitu:

1. Perangkat Lunak Generik (Generic Software): perangkat lunak berdiri sendiri dengan menggunakan standar tertentu yang diproduksi oleh vendor dan dijual bebas. Ex : Aplikasi Perkantoran, Programming Aplication.
2. Perangkat Lunak Pesanan (Order Software): perangkat lunak yang dipesan oleh pelanggan tertentu kepada vendor. Ex : System Control (Pengaturan lalu lintas, Bandara).

• Menurut penggunaannya, Perangkat lunak dapat dikelompokkan menjadi 8 kategori yaitu:

1. System Software :  memiliki fungsi dasar sistem operasi.
2. Real-time Software : menganalisa peristiwa secara langsung.
3. Business Software : dapat digunakan untuk kegiatan Bisnis.
4. Engineering and Scientific Software : disusun secara mengikut sertakan berbagai rumus pada ilmu pengetahuan. 
5. Embedded Software : dirancang untuk piranti modern cerdas.
6. Personal Software : membantu menyelesaikan pekerjaan manusia secara individual.
7. Web base Software : dipergunakan menjalankan perintah pada jejaring internet.
8. Artificial Intelligence Software : menyelesaikan pekerjaan rumit dan non numerical algorithma.

4. MUTU PERANGKAT LUNAK

   Perangkat Lunak dipengaruhi oleh 3 pihak yang  berperan aktif terhadap perkembangan    perangkat lunak yaitu

• Sponsor : Seseorang/organisasi membiayai  pengembangan perangkat lunak.
• User : Seseorang yang secara langsung berinteraksi (nenggunakan/menikmati) terhadap eksekusi perangkat lunak.
• Developer : Seseorang/Organisasi yang memberikan modifikasi, pemeliharaan, dan pengembangan sistem software.

5. MITOS PERANGKAT LUNAK

• Mitos  Manajemen (Manajer bertanggung jawab terhadap masalah perangkat lunak).
• Mitos Pelanggan (Pelanggan mempercayai atas pertanggung jawaban terhadap masalah perangkat lunak).
• Mitos para Praktisi (Pemrograman dilihat sebagai karya seni).