RESUME

Video Analisis dan Desain Software berbasis UML

Dosen pengampu :
Dr. Eng. Mardiana, S.T.,M.T.

Disusun oleh :

Nama : Khalid Surya Gusti

NPM : 2015061045

Kelas : B

PRODI TEKNIK INFORMATIKA

FAKULTAS TEKNIK
UNIVERSITAS LAMPUNG
2020/2021
Siklus Pengembangan Software

Planing (System proposal) :

1. Use/Product owner ,membawa permintaan kebutuhan (perubahan) Software (system

request),system request ke system analyst. Pihak yang membutuhkan software
(requirement), yang menganalisis bahwa ada business value (benefit) apabila suatu proses
bisnis diautomasi menggunakan software.
2. System Analyst membuat kelayakan (Feasibility Analysis) dari Sistem request tersebut.
Orang yang menganalisis kebutuhan bisnis, mengidentifikasi peluang untuk perbaikan,
mendesain software (sistem) untuk mengimplementasikan idenya.

Analysis and Design (System Specification) :

1. Setelah dinyatakan layak,System analyst melakukan analisis dan design dan hasilnya
adalah specification.
a. Business Analyst ,membantu system analaisis memahami proses bisnis yang akan
dibangun dan membantu user/product owner di masalah domain dan bidang
(business) dari software.

Implementation (Software) :

1. Sistem spesifikasi diserahkan oleh system analisis ke programmer untuk dilakukan

kontruksi (coding)
2. Hasil kontruksi berupa kode program diserahkan ke software tesrer untuk dilakukan
pengujian
3. Instalasi (delivery) software dan manajemen perubahan

Maintence (Update Software) :

1. Siklus kembali ke 1 (planning) apabila ada permintaan perubahaan (permintaan

perubahan software)

Metodologi pengembangan Software (Model Process)

Pendekatan formal untuk menerapkan Software Development Life Cycle (SDLC) dan
Representasi yang disederhanakan dari proses perangkat lunak atau juga Serangkaian aktivitas,
tindakan, tugas, pencapaian, dan produk kerja yang dibutuhkan untuk merekayasa kualitas tinggi
perangkat lunak
Metodologi pengembangan Software :

1. Struktur design (Prescriptive)

Tahapan SDLC bergerak secara metodis dan sistematis Setelah satu tahap selesai baru
menuju ke tahap berikutnya ,Digunakan pada era 1967 -1985 ,contohnya Waterfall
method dan parallel development.

2. Rapid Application Development (Iterative)

Digunakan pada era 1985-1995,contohnya Contoh RAD: 1. Phased development: alur
seri dari versi 2. Prototyping: system prototyping 3. Throw-away prototyping: design
prototyping.

3. Agile Development (Adaptive)

Menggunakan beberapa aturan yang mudah dipahami dan diikuti , Mempercepat proses
SDLC , Mengurangi pemodelan dan dokumentasi dan Mengembangakan software
dengan simple dan iterative Digunakan pada era 1995 ke atas ,contohnya Extreme
Programming (XP) dan Scrum.
Sprint Planning

Sprint Planning adalah proses perencanaan pekerjaan yang akan dikerjakan dalam satu Sprint
,Perencanaan ini dilakukan secara kolaboratif oleh seluruh anggota Scrum Team.

Sprint Execution

Sprint Execution adalah pekerjaan yang dilakukan Scrum Team untuk mencapai Sprint
Goal,Prinsip Scrum Execution adalah Task Planning, Daily Scrums, Task Performance,
Communicating, dan Flow Management.Sprint Execution dapat diasumsikan sebagai mini
project yang bertujuan untuk menghasilkan potentially shippable product increment.

Sprint Review

Sprint Review adalah Sprint yang dilakukan untuk memeriksa dan menyesuaikan progres
pekerjaan.Sprint Review terjadi di dekat akhir sprint setelah Sprint Execution dan sebelum (atau
kadang setelah) Sprint Retrospective.

Sprint Retrospective

Sprint Retrospective adalah sebuah kesempatan bagi Scrum Team untuk menginspeksi dirinya
sendiri dan membuat perencanaan mengenai peningkatan yang akan dilakukan di Sprint
berikutnya,Sprint Retrospective Dilakukan setelah Sprint Review dan sebelum Sprint Planning
berikutnya.
Sistem Request

Kapan Project Software Diinisiasi?

Ketika ada seseorang yang melihat peluang menciptakan business value dengan menggunakan
software dan teknologi informasi ,Seseorang itu kemudian membuat System Request ,System
Request kemudian dianalisis kelayakannya (Feasibility Analysis) untuk menentukan apakah akan
diteruskan projectnya atau tidak, Di dalam analisis kelayakan, dilakukan juga penghitungan
usaha pengembangan software (butuh berapa bulan dan berapa orang) ,sehingga analisis
kelayakan ekonomi bisa dibangun .dengan akurat

Business Need

Merupakan Alasan terkait bisnis untuk memulai proyek pengembangan perangkat lunak dan
Alasan mendorong proyek, dan mengapa proyek harus didanai .Contohnya Meningkatkan
penjualan ,Mengurangi biaya operasional ,Meningkatkan produktifitas pegawai , Meningkatkan
kualitas layanan ,Mengurangi kebocoran/kecurangan, Mengurangi cacat produksi ,Meningkatkan
efisiensi kerja.

Business Value

Merupakan Manfaat yang akan diciptakan perangkat lunak bagi organisasi • Nilai berwujud
(nilai yang dapat diukur) dan nilai tidak berwujud (kepercayaan intuitif).
Contohnya • Peningkatan penjualan 3% • Pengurangan biaya operasional 10% • Peningkatan
produktifitas pegawai 10% (dihitung rasio pekerjaan dan gaji) • Pengurangan cacat produksi
20% • Peningkatan efisiensi kerja 20% .

Business Requirements

Kemampuan bisnis yang akan disediakan oleh perangkat lunak dan Dapat diganti dengan
Diagram Kasus Penggunaan .
Contohnya Fitur registrasi, login, dan logout , Fitur pengelolaan data pengguna , Fitur
pengiriman notifikasi otomatis ,Fitur cetak laporan bulanan dan tahunan.
Kualitas perangkat lunak (IEEE, 1991):
1. Sejauh mana sistem, komponen, atau proses memenuhi ditentukan Persyaratan
2. Sejauh mana sistem, komponen, atau proses bertemu pelanggan.
Kapan Project Software Diinisiasi?

Ketika ada seseorang yang melihat peluang menciptakan business value dengan menggunakan
software dan teknologi informasi • Seseorang itu kemudian membuat System Request • System
Request kemudian dianalisis kelayakannya (Feasibility Analysis) untuk menentukan apakah akan
diteruskan projectnya atau tidak • Di dalam analisis kelayakan, dilakukan juga penghitungan
usaha pengembangan software (butuh berapa bulan dan berapa orang) • sehingga analisis
kelayakan ekonomi bisa dibangun dengan akurat.

Exercise: Membuat System Request

1. Lihat contoh System Request untuk Sistem Penjualan Musik Online

2. Pikirkan suatu sistem* yang saat ini dibutuhkan oleh perusahaan atau organisasi anda
3. Buat System Request dari sistem tersebut.

What is a Requirements
Persyaratan Bisnis
• Pernyataan tentang apa yang harus dilakukan sistem
• Fokus pada apa yang harus dilakukan sistem, bukan bagaimana melakukannya .

Ada 2 macam persyaratan

1. Persyaratan Fungsional
Kebutuhan tentang fungsi perangkat lunak secara menyeluruh, Pemodelan dengan UML, ataupun
penjelasan fiturfitur dalam bentuk problem statements, adalah termasuk dalam Functional
Requirement.
2. Persyaratan Nonfungsional
Operasional - Lingkungan fisik / teknis, Kinerja - Kecepatan dan keandalan, Keamanan - Siapa
yang dapat menggunakan sistem, Budaya & Politik - Kebijakan perusahaan, masalah hukum.

Metode Requirement Gathering.

1. Analisis Dokumen
Memberikan petunjuk tentang "formal" sistem As-Is yang ada , Dokumen khas , Formulir ,
Laporan ,Panduan kebijakan ,Cari penambahan pengguna ke formulir ,Cari elemen formulir yang
tidak digunakan dan Lakukan analisis dokumen sebelum wawancara.

2. Wawancara
Teknik yang paling umum digunakan dan sangat natural , Jika Anda perlu mengetahui sesuatu,
Anda bertanya seseorang ada Lima langkah dasar: 1. Memilih narasumber 2. Merancang
pertanyaan wawancara 3. Mempersiapkan wawancara 4. Melakukan wawancara 5. Tindak lanjut
pasca-wawancara.

3. Desain Aplikasi Bersama (JAD)

Memungkinkan manajer proyek, pengguna, dan pengembang untuk bekerja sama , Dapat
mengurangi cakupan creep hingga 50% ,Menghindari persyaratan yang terlalu spesifik atau
terlalu kabur ,Sertakan 10 hingga 20 pengguna ,Cenderung bertahan 5 sampai 10 hari selama tiga
minggu Titik.

4. Kuesioner
Memilih peserta , Menggunakan sampel populasi,Merancang kuesioner ( Lebih penting dari
pertanyaan wawancara) , Prioritaskan pertanyaan untuk menarik perhatian ,Membedakan antara:
a. Pertanyaan berorientasi fakta (jawaban spesifik)
b. Pertanyaan opini (skala setuju - tidak setuju) , Mengelola kuesioner , Jelaskan pentingnya &
bagaimana itu akan digunakan , Berikan tanggal tanggapan yang diharapkan ,Menindaklanjuti
pengembalian yang terlambat dan meminta supervisor menindaklanjuti ,Berjanji untuk
melaporkan hasil , Kuisioner tindak lanjut ,Mengirim hasil ke peserta.

5. Pengamatan
Pengguna / pengelola sering kali tidak ingat semua yang mereka lakukan • Memvalidasi info
yang dikumpulkan dengan cara lain • Perilaku berubah ketika orang-orang diawasi • Tetap low
profile, jangan ubah prosesnya • Berhati-hatilah untuk tidak mengabaikan aktivitas berkala

Tantangan di Requirement Gathering

1. Sindrom "Ya, Tapi" Berasal dari sifat manusia dan ketidakmampuan pengguna untuk
mengalami perangkat lunak karena mereka mungkin perangkat fisik.
2. "Reruntuhan yang Belum Ditemukan" Menelusuri persyaratan seperti menelusuri "Reruntuhan
yang Belum Ditemukan“ Semakin banyak Anda menemukan, semakin banyak yang Anda
ketahui Sindrom
3. "Pengguna dan Pengembang" Mencerminkan perbedaan mendasar antara keduanya, membuat
komunikasi menjadi sulit

Paradigma Analysis dan Design

1. UML

UML atau Unified Modeling Language ,UML dapat digunakan untuk memodelkan semua proses
dalam siklus hidup pengembangan dan lintas teknologi implementasi yang berbeda (tidak
bergantung pada teknologi dan bahasa) UML adalah bahasa standar untuk memvisualisasikan,
menentukan, membangun, dan mendokumentasikan artefak dari sistem intensif perangkat lunak
UML adalah alat komunikasi - untuk tim, dan pemangku kepentingan lainnya
a. Alat UML yang Tercanggih
• Rational Rose
• Visual Paradigm
• Sparx Systems
Enterprise Architect
• Microsoft Visio
• Star UML
b. Masalah UML
1. UML adalah notasi pemodelan, ini bukan proses pengembangan atau metodologi
,Proses pengembangan yang didorong UML?
2. UML terlalu kompleks, sulit dipahami dengan cepat Diagram
,UML mana yang harus kita gunakan?
c. Analisis dan Desain Perangkat Lunak berbasis UML
1. Menampilkan batasan sistem dan fungsi utamanya menggunakan use case dan actor
2. Buat model proses bisnis organisasi dengan diagram aktivitas
3. Gambarkan realisasi kasus penggunaan dengan diagram urutan
4. Mewakili struktur statis dari suatu sistem menggunakan diagram kelas
5. Ungkap arsitektur implementasi fisik dengan diagram penerapan

2. Identifikasi Proses Bisnis dengan Use Case Diagram

a. Usecase diagram
Use case diagram merupakan diagram yang menggambarkan hubungan antara aktor
dengan sistem. Use case diagram bisa mendeskripsikan sebuah interaksi antara satu atau
lebih aktor dengan sistem yang akan dibuat. Use case diagram juga bisa digunakan untuk
mengetahui fungsi apa saja yang ada di dalam sebuah sistem dan  bisa juga
mempresentasikan sebuah interaksi aktor dengan sistem. Komponen tersebut kemudian
menjelaskan komunikasi antara aktor,  dengan sistem yang ada.
Use case diagram mempunyai 3 komponen ,yaitu :

1. Sistem
Menyatakan batasan sistem dalam relasi dengan aktor-aktor yang menggunakannya
(di luar sistem) dan fitur-fitur yang harus disediakan (dalam sistem).
2. Aktor
Aktor adalah segala hal diluar sistem yang akan menggunakan sistem tersebut untuk
melakukan sesuatu. Bisa merupakan manusia, sistem, atau device yang memiliki
peranan dalam keberhasilan operasi dari sistem.
3. UseCase
Use Case sendiri adalah gambaran fungsional dari sebuah sistem. Dengan demikian,
 antara konsumen dan juga pengguna pada sistem tersebut, akan mengerti atau paham
mengenai fungsi sistem yang tengah dibangun.

Realisasi Proses Bisnis dengan Sequence Diagram

a. Sequence Diagram
Sequence diagram menggambarkan interaksi antar object (class) dalam sofware pada
suatu sekuensial waktu
a.Interaksi object (class) berdasarkan alur proses bekerjanya software, dimana interaksi
tersebut menggambarkan pesan yang dikirimkan secara sekuensial antara object
(class)
b. Garis vertikal (lifeline) menunjukkan object (class), garis horizontal menunjukkan
pesan yang mengalir antara object (class) tersebut.

Sequence diagram adalah alat komunikasi System Analyst dengan Programmer,

menggambarkan alur proses bekerjanya software sekaligus dengan komposisi software
akan seperti apa
Sequence Diagram dibuat untuk setiap Use Case yang dibuat dimulai dari menarik Actor
yang ada di Use Case Diagram, dilanjutkan dengan membuat sequence detail dari alur
proses berjalannya Use Case dengan message yang mengalir didalamnya.
Catatan: Objek dari Lifeline di Sequence Diagram akan menjadi kandidat Class, karena
itulah harus mengikuti arsitektur Boundary – Control – Class

Konsep Dasar Paradigma Berorientasi Objek

Pemrograman berorientasi objek (Object oriented programming yang disingkat OOP) merupakan
paradigma pemrograman berdasarkan konsep objek yang dapat berisi data, dalam bentuk field
atau dikenal juga sebagai atribut serta kode, dalam bentuk fungsi/prosedur atau dikenal juga
sebagai method.

Perbedaan Class dan Object :

Class adalah konsep dan deskripsi dari sesuatu,Class mendeklarasikan method yang dapat
digunakan (dipanggil) oleh object Sedangkan Object merupakaninstance dari class, bentuk
(contoh) nyata dari class,Object memiliki sifat independen dan dapat digunakan untuk
memanggil method.

Contoh Class dan Object:

Class: mobil,Object: mobilnya pak Joko, mobilku, mobil berwarna merah

 Karakteristik Pemrograman Berorientasi Objek
Cara kita melihat suatu sistem dalam bentuk yang lebih sederhana, yaitu sebagai suatu kumpulan
subsistem (object) yang saling berinteraksi.contohnya Mobil adalah kumpulan sistem pengapian,
sistem kemudi, sistem pengereman.
Alat meng-abstraksikan sesuatu adalah class,Object bersifat modularity. Object dapat ditulis dan
dimaintain terpisah (independen) dari object lain

a. Encapsulation
Mekanisme menyembunyikan suatu proses dan data dalam sistem untuk menghindari
interferensi, dan menyederhanakan penggunaan proses itu sendiri

b. Tongkat transmisi (gigi) pada mobil

c. Tombol on/off/pengaturan suhu pada AC

Class access level (public, protected, privat) adalah implementasi dari konsep encapsulation
Enkapsulasi data dapat dilakukan dengan cara:
d. mendeklarasikan instance variable sebagai private
e. mendeklarasikan method yang sifatnya public untuk mengakses variable tersebut

Enkapsulasi data juga dapat dilakukan dengan cara:

1. mendeklarasikan instance variable sebagai private
2. mendeklarasikan method yang sifatnya public untuk mengakses variable tersebut.
b. Inheritance (Pewarisan)
1. Suatu class dapat mewariskan atribut dan method kepada class lain (subclass), serta
membentuk class hierarchy
2. Penting untuk Reusability
3. Java Keyword: extends.
c. Polymorphism

Kemampuan untuk memperlakukan object yang memiliki perilaku (bentuk) yang

berbeda,Implementasi konsep polymorphism:

a. Overloading: Kemampuan untuk menggunakan nama yang sama untuk beberapa method
yang berbeda parameter (tipe dan atau jumlah)

b. Overriding: Kemampuan subclass untuk menimpa method dari superclass, yaitu dengan
cara menggunakan nama dan parameter yang sama pada method.

User Interface Concepts

a. Philosophy and Principles

 Desain antarmuka adalah seni Keseimbangan antara Membuat antarmuka berguna dan
Menyajikan terlalu banyak informasi
Prinsip Desain Antarmuka Pengguna:
1. Tata letak: Penggunaan area layar secara konsisten
2. Kesadaran konten: Pengguna tahu di mana mereka berada
3. Estetika: Ruang putih vs. fungsionalitas
4. Pengalaman pengguna: Kemudahan penggunaan vs. kurva pembelajaran
5. Konsistensi: Pengguna dapat memprediksi apa yang akan terjadi untuk setiap tindakan
6. Upaya pengguna minimal: Mudah digunakan, aturan tiga klik.

Layout Concepts

Layar sering dibagi menjadi tiga kotak Area navigasi (atas), Area status (bawah) ,Area
kerja (tengah) ,Informasi dapat disajikan di berbagai area, seperti area yang harus
dikelompokkan bersama Area dan informasi harus meminimalkan pergerakan pengguna
dari satu ke yang lain Idealnya, area akan tetap konsisten di: Ukuran, Bentuk,
Penempatan untuk memasukkan data, Laporan yang menyajikan data yang diambil
Masalah Terbesar: Terlalu banyak informasi untuk diproses Berikan struktur yang logis
Kronologis Paling sering digunakan hingga yang paling jarang digunakan Umum hingga
khusus

Content Awareness

Buat pengguna mengetahui konten tanpa menyadarinya Semua ,antarmuka harus

memiliki judul Menu harus ditampilkan dimana kamu berada dari mana Anda berasal
untuk sampai ke sana

Estetika

Antarmuka harus fungsional dan menarik untuk digunakan, Enak dipandang ,Hindari
meremas terlalu banyak ,Khususnya untuk pengguna pemula .Pengguna berpengalaman
dapat menangani lebih banyak info Rancang teks dengan hati-hati Perhatikan font dan
ukurannya Hindari menggunakan semua huruf kapital Warna dan pola harus digunakan
dengan hati-hati .Uji kualitas warna Coba antarmuka pada monitor monokrom Gunakan
warna untuk memisahkan atau mengkategorikan item Jangan hanya mengandalkan warna
untuk menyampaikan makna

Proses Perancangan Antarmuka Pengguna

Merancang antarmuka merupakan bagian yang paling penting dari merancang sistem.
Biasanya hal tersebut juga merupakan bagian yang paling sulit, karena dalam
merancang antarmuka harus memenuhi tiga persyaratan: sebuah antarmuka harus
sederhana, sebuah antarmuka harus lengkap, dan sebuah antarmuka harus memilki
kinerja yang cepat.

Alasan utama mengapa antarmuka sulit untuk dirancang adalah karena setiap
antarmuka adalah sebuah bahasa pemrograman yang kecil: antarmuka menjelaskan
sekumpulan objek-objek dan operasi-operasi yang bisa digunakan untuk
memanipulasi objek.

Dalam proses pengembangan antarmuka, kita bisa atau mungkin saja tidak bisa
memisahkannya dari seluruh proses pengembangan sebuah produk. Walaupun begitu,
fokus dari dua proses tersebut sangatlah berbeda. Dalam proses pengembangan
antarmuka, fokus haruslah terletak pada elemen-elemen antarmuka dan objek-objek
yang pengguna lihat dan gunakan, dibandingkan dengan kemampuan sebuah program.

Elemen-Elemen dalam perancangan antarmuka adalah

1. Mendefinisikan konsep. Mengumpulkan kebutuhan-kebutuhan pengguna dan

mendefinisikan desain secara konseptual.

2. Memvalidasi konsep. Mengevaluasi konseptual desain tersebut.

3. Merancang. Mengevaluasi prototype. Menandai dan memperbaiki masalah-

masalah yang ditemukan.

4. Pengembangan. Melakukan pengujian secara berkala terhadap desain yang

lebih dahulu dibuat dan desain yang paling terakhir dibuat. Menandai dan
memperbaiki masalah-masalah yang ditemukan.

Pemodelan data

Pemodelan data adalah proses yang digunakan untuk mendefinisikan dan menganalisis

kebutuhan data yang diperlukan untuk mendukung proses bisnis dalam
lingkup sistem informasi yang sesuai dalam organisasi. Oleh karena itu, proses pemodelan
data melibatkan pemodel data profesional bekerja sama dengan pemangku kepentingan bisnis,
serta pengguna potensial dari sistem informasi. Ada tiga jenis model data yang dihasilkan
ketika maju dari persyaratan untuk database sebenarnya yang akan digunakan untuk sistem
informas.

Systems Implementation
1. Konstruksi: Pengembangan semua bagian perangkat lunak itu sendiri, dokumentasi, dan
prosedur operasi baru
2. Pengujian: Suatu bentuk asuransi. Lebih murah untuk memperbaiki bug lebih awal,
daripada nanti
3. Dokumentasi: Memberikan informasi untuk membuat sistem lebih mudah digunakan dan
dipelihara
4. Instalasi: Aspek teknis (konversi) dan aspek organisasi (manajemen perubahan).