Use case merupakan sebuah pekerjaan tertentu, misalnya : Melakukan login ke

sistem, Menambah data barang baru, Mencetak laporan penjualan, dan

sebagainya.

Seorang/sebuah actor adalah sebuah entitas manusia atau mesin yang

berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu.
Manfaat Use Case Diagram (1) • Menjelaskan requirements. • Memudahkan
komunikasi dengan client. • Client mudah memahami dan memberikan
masukan. • Mempermudah pembuatan test case pada tahap pengujian software.
Actor – Adalah seseorang atau apa saja yang berhubungan dengan sistem yang
sedang dibangun. – Sebaiknya diberi nama dengan kata benda. – Dalam UML
direpresentasikan dengan notasi berikut ini

Use case – Adalah bagian fungsionalitas tingkat tinggi yang disediakan oleh
sistem. – Menggambarkan bagaimana seseorang menggunakan sistem
(berinteraksi dengan sistem). – Nama use case selalu diawali dengan kata kerja
aktif. – Dalam UML direpresentasikan dengan notasi berikut ini
Relasi – Menghubungkan antara actor dan use case. – Ada 4 jenis relasi : •
Association • Generalization • Include • Extend
Materi ppt 1
Software (1) • Merupakan program komputer dan dokumentasinya, seperti :
requirement, design model, dan user manual. • Produk software dikembangkan
untuk customer tertentu atau untuk pangsa pasar tertentu. • Dapat berupa : –
Generik  Dikembangkan untuk dijual ke kelompok / pasar tertentu. Contoh :
Ms. Office. – Custom Dikembangkan untuk customer tunggal sesuai dengan
spesifikasi yang diminta.
Peran Software • Banyak aktivitas manusia saat ini tergantung pada software. •
Terutama untuk membantu kegiatan operasional sehari-hari. • Sehingga banyak
perusahaan menempatkan pembelanjaan software sebagai hal yang penting. •
Hal ini mempengaruhi GNP (Gross National Product) suatu negara.
Attributes of Good Software • Maintainability • Reliability • Security and safety
• Efficiency • Acceptability
Peran Software • Banyak aktivitas manusia saat ini tergantung pada software. •
Terutama untuk membantu kegiatan operasional sehari-hari. • Sehingga banyak
perusahaan menempatkan pembelanjaan software sebagai hal yang penting. •
Hal ini mempengaruhi GNP (Gross National Product) suatu negara.
Software Engineering • Merupakan suatu disiplin/ilmu rekayasa yang
berhubungan dengan seluruh aspek produksi software. • Software engineer
harus mengadaptasi sebuah pendekatan yang sistematis dan terorganisasi pada
pekerjaannya dan menggunakan tool dan teknik yang cukup berdasarkan : –
Masalah yang diatasi – Development constraints – Sumber daya yang tersedia
Pentingnya Software Engineering • Software harus reliable, aman, usable, dan
maintainable. • Secara eksplisit, terfokus pada menghasilkan software dengan
atribut di atas. • Penting bagi sistem yang digunakan oleh banyak orang dan
bisnis tertentu, dan yang digunakan selama bertahun-tahun.
Perbedaan Software Engineering dan Computer Science • CS berhubungan
dengan teori dan fundamental. SE berhubungan dengan prakek pengembangan
dan produksi software yang berguna. • Teori pada CS masih belum cukup untuk
digunakan sebagai bagian kelengkapan pada software engineering.
Tantangan Utama Software Engineering • Heterogenity – Membangun teknik
untuk membuat software dapat berjalan pada platform dan lingkungan eksekusi
yang heterogen. • Delivery – Membangun teknik untuk mengarahkan pada
software delivery yang lebih cepat. • Trust – Membangun teknik yang
mendemonstrasikan bahwa software dapat dipercaya oleh penggunanya.
2. SOFTWARE PROCESS
Software Process • Merupakan sekumpulan aktivitas yang bertujuan untuk
pengembangan dan evolusi software.
Software Process Activities • Software specification, di mana customer dan
engineer mendefinisikan software yang akan dihasilkan dan batasannya. •
Software development, di mana software dirancang dan diprogramkan. •
Software validation, di mana software dicek untuk menjamin kesesuaian dengan
yang dibutuhkan oleh user. • Software evolution, di mana software dimodifikasi
untuk mencerminkan perubahan kebutuhan customer dan pasar.
Software Process Model • Merupakan sebuah representasi sederhana dari
sebuah software process, yang dipresentasikan dari sebuah perspektif tertentu. •
Contoh process perspective : – Workflow perspective – urutan aktivitas. – Data
flow perspective – alur informasi. – Role/action perspective – siapa
mengerjakan apa
Generic Process Model • Waterfall • Iterative development • Component-based
software engineering
Software Engineering Method • Pendekatan terstruktur untuk pengembangan
software, termasuk system model, notasi, aturan, design advice, dan process
guidance. • Model description  Deskripsi dari model grafis yang harus dibuat. •
Rule  Batasan yang diimplementasikan pada system model. • Rekomendasi 
Masukan bagi good design practise. • Process guidance  Aktivitas apa yang
dilakukan.
4. CASE TOOLS CASE
(Computer-Aided Software Engineering) • Merapakan software yang ditujukan
untuk menyediakan dukungan terotomasi untuk software process activities. •
Upper-CASE  Tool untuk mendukung berbagai aktivitas proses awal dari
requirement dan perancangan. • Lower-CASE  Tool untuk mendukung
aktivitas berikutnya, seperti : pemrograman, debugging, dan pengujian.
Materi ppt 2
Materi 1
Proses Merupakan sekumpulan aktivitas, aksi, dan tugas yang dilakukan ketika
menciptakan sebuah produk.
• Setiap aktivitas, aksi, dan tugas yang dilakukan dalam sebuah kerangka kerja
atau model yang mendefinisikan hubungannya antara proses dengan yang
lainnya.

Process Patterns
• Setiap software team pasti akan menemukan masalah ketika menjalankan
software process.
• Akan sangat berguna jika sudah ada solusi yang telah terbukti.
• Process patterns merupakan sebuah proses (yang berhubungan dengan
masalah) yang dilakukan selama dijalankannya software engineering,
mendefinisikan lingkungan dimana masalah ditemukan, dan merekomendasikan
solusi.
• Aktvitas awal yang penting dilakukan adalah menjalin komunikasi dengan
stakeholder. – Kontak/bicara dengan stakeholder via telepon. – Diskusikan
requirements dan buat catatan. – Masukkan catatan tersebut ke pernyataan
untuk requirement secara resmi. – Kirimkan email ke stakeholder untuk ditinjau
dan disetujui.
For Big/Complex Software Project … • Definisikan requirement dari
stakeholder yang beragam. • Jalin komunikasi dengan 6 Langkah : – Inception –
Elicitation – Elaboration – Negotiation – Specification – Validation
3. IDENTIFYING A TASK SET
A Task Set • Merupakan pekerjaan yang harus dilakukan untuk mencapai tujuan
dalam software engineering. • Tujuan dari requirements gathering adalah untuk
memahami apa yang diinginkan oleh stakeholder pada software yang akan
dibangun.
For Small Software Project … • Buatkan daftar stakeholder dari proyek. •
Undang seluruh stakeholder ke dalam sebuah informal meeting. • Meminta
setiap stakeholder untuk menuliskan fitur-fitur dan fungsi yang dibutuhkan. •
Diskusikan requirement dan buatkan final list. • Buatkan prioritas untuk
requirement tersebut. • Catat beberapa poin uncertainty (ketidakpastian). 18
4. PENILAIAN DAN PERBAIKAN PROSES
Pengantar • Keberadaan suatu software tidak menjamin bahwa software akan
diselesaikan tepat waktu, memenuhi kebutuhan customer, atau berkualitas. •
Beberapa pendekatan yang digunakan : – Standard CMMI Assessment Method
for Process Improvement (SCAMPI) – CMM-Based Appraisal for Internal
Process Improvement (CBA IPI) – SPICE (ISO/IEC15504) – ISO 9001:2000
for Software
Prescriptive Process Models • Sering disamakan dengan traditional process
models. • Prescriptive Process Models digunakan untuk mengurutkan
kekacauan pada pengembangan software. • Tidak ada jawaban pasti bagaimana
melakukannya karena penyebabnya banyak sekali.
5. PRESCRIPTIVE PROCESS MODELS
Sering disamakan dengan traditional process models. • Prescriptive Process
Models digunakan untuk mengurutkan kekacauan pada pengembangan
software. • Tidak ada jawaban pasti bagaimana melakukannya karena
penyebabnya banyak sekali.
8. PERSONAL AND TEAM PROCESS MODELS
Software Process • Software Process terbaik adalah yang terdekat dengan orang-
orang yang akan mengerjakannya  Yang lebih mudah dan dipahami/dikenali. •
Jika belum paham, perlu dipelajari supaya paham. • Sehingga memerlukan
adaptasi yang sangat unik.
Personal Software Process (PSP) • Setiap pengembang menggunakan beberapa
proses untuk membuat software. • Proses dapat dilakukan dengan banyak cara,
walau belum tentu efektif. • PSP model -> – Planning – High-level design –
High-level design review – Development – Postmortem.
Team Software Process (TSP) • Membangun sebuah tim yang merencanakan
dan melacak pekerjaan, membuat tujuan, memiliki proses dan rencana. •
Menunjuk seorang manager yang dapat melatih dan memotivasi tim supaya
kinerjanya baik. • Mempercepat software process improvement dengan
menjalankan CMM level 5. • Menyediakan petunjuk untuk high-maturity
organization. • Memfasilitasi pengajaran ke universitas tentang industrial-grade
team skills.
9. PROCESS TECHNOLOGY
Process Technology Tools • Process technology tools dibangun untuk berbagai
organisasi software untuk: – Menganalisa proses saat ini. – Mengatur work task.
– Mengontrol dan memonitor kemajuan. – Mengatur kualitas teknis.
10. COST ESTIMATION

Cocomo Cost Modeling (2) • Pemodelan dapat dibagi menjadi kategori : Low-
Medium-High atau Very Low-LowMedium-High-Very High untuk setiap
kegiatan/tahapan pengembangan software. • Dan nantinya ditentukan jumlah
man-hour. • Kemudian didefinisikan nominal honor/gaji untuk tiap posisi dalam
tim : project managersystem analyst-DB analyst-programmertester-technical
writer
11. PRODUK DAN PROSES
Produk dan Proses • Jika proses yang dijalankan kurang baik, maka produk
yang dihasilkan akan terkena dampaknya. • Sama halnya seperti software. •
Sehingga produk dan proses merupakan dua elemen penting dalam software
engineering.

Materi ppt 3
Requirements Engineering • Proses membangun layanan yang diinginkan
customer dari sebuah sistem dan batasan yang dapat dioperasikan dan
dikembangkan. • Kebutuhan perangkat lunak merupakan deskripsi dari layanan
dan batasan sistem yang terbentuk selama proses rekayasa kebutuhan perangkat
lunak.
What Is A Requirement ? • Merupakan turunan dari high-level abstract
statement dari sebuah layanan dan system boundary menjadi spesifikasi fungsi.
• Merupakan spesifikasi dari apa yang dibutuhkan oleh customer terhadap
perangkat lunak yang akan dikembangkan.
Definisi dan Spesifikasi • Requirements definition  – Software harus
menyediakan sebuah makna untuk representasi dan pengaksesan external files
yang dibuat oleh tool lainnya. • Requirements specification  – User harus
disediakan dengan fasilitas untuk mendefinisikan jenis external file. – Tiap
external file harus memiliki tool yang dapat diterapkan.
Requirements Completeness and Consistency • Complete – Harus memasukan
deskripsi dari seluruh kebutuhan sistem. • Consistent – Tidak boleh ada konflik
atau kontradiksi dalam deskripsi apa yang disediakan oleh sistem.
2. THE SOFTWARE REQUIREMENTS DOCUMENTS Guidelines For
Writing Requirements • Temukan sebuah format yang standar dan gunakan
untuk semua requirement. • Gunakan bahasa secara konsisten. • Gunakan text
highlight untuk mengidentifikasi bagian penting dari requirement. • Hindari
penggunaan jargon computer.
Software Requirements Documents • Disebut sebagai SRS (Software
Requirements Specification). • Merupakan sebuah pernyataan resmi dari apa
yang system developer harus lakukan, termasuk user requirements untuk sistem
dan spesifikasi dari system requirement. • Terkadang user requirements dan
system requirement dijadikan dalam satu deskri
3. REQUIREMENTS SPECIFICATION
Requirements Specification • Merupakan proses penulisan user and system
requirements ke dalam requirements document. • User and system requirements
harus didefinisikan dengan jelas, tidak ambigu, mudah dimengerti, lengkap, dan
konsisten. • Dalam praktek, sangat sulit dilakukan. Tetapi wajib dilakukan.
Jenis Requirement • User requirements – Pernyataan dalam natural language
dan diagram layanan yang disediakan oleh sistem beserta batasan
operasionalnya. • System requirements – Sebuah dokumen terstruktur yang
berisikan deskripsi detail dari layanan suatu sistem. Tertulis sebagai sebuah
kontrak antara client-contractor. • Software specification – Sebuah deskripsi
perangkat lunak yang mendetail yang digunakan sebagai landasan untuk desain
atau implementasi. Ditulis untuk para developer.
User Requirements • User requirements untuk sistem harus mendeskripsikan
functional and nonfunctional requirements, sehingga mudah dimengerti oleh
pengguna yang tidak memiliki latar belakang teknis/TI. • Dokumen requirement
tidak mencantumkan detail arsitektur atau desain dari sistem. • Harus
menggunakan natural language, yang disertai table, form, diagram.
System Requirements • Merupakan turunan dari user requirements yang
digunakan oleh software engineer sebagai acuan untuk desain software. • Perlu
ditambahkan detail dan penjelasan bagaimana user requirements harus
disediakan oleh sistem. • Harus mendeskripsikan juga external behavior dari
sistem dan batasan operational-nya.
Functional Requirements • Mendeskripsikan fungsionalitas / kegunaan dari
suatu sistem. • Tergantung dari jenis software, user, dan jenis sistem di mana
software tersebut digunakan. • Functional user requirements dapat berupa high-
level statement dari apa yang perlu sistem lakukan. • Functional system
requirements harus mendeskripsikan layanan sistem secara detail.
Non-functional Requirements • Mendeskripsikan keterangan dan batasan sistem
 reliability, response time, storage requirements. Batasan berupa I/O device
capability, representasi sistem, dll. • Kebutuhan proses dapat diterjemahkan
melalui sistem CASE tertentu, bahasa pemrograman, atau metode
pengembangan tertentu. • Dapat lebih penting daripada functional requirements.
4. REQUIREMENTS ENGINEERING PROCESS Requirements Engineering
Processes
• Proses yang digunakan untuk menemukan, menganalisa, dan memvalidasi
kebutuhan sistem.
5. REQUIREMENTS ELICITATION AND ANALYSIS Elicitation and
Analysis
• Terkadang disebut requirements elicitation atau requirements discovery. •
Melibatkan staf teknis yang bekerja dengan customer untuk mencari tahu
tentang domain aplikasi, sistem yang harus dikembangkan, dan batasannya. •
Dapat melibatkan end-user, manajer, engineer yang terlibat dalam maintenance,
domain expert, dll sehingga disebut sebagai stakeholder.
6. REQUIREMENTS VALIDATION Requirements Validation • Merupakan
proses pengecekan requirement apakah telah mendefinisikan sistem dengan
keinginan customer dengan tepat atau tidak. • Sangat penting karena error yang
terjadi pada requirements document akan menyebabkan extensive rework cost. •
Sehingga diperlukan kehati-hatian yang ekstra.
Latar Belakang • Requirements untuk software yang besar selalu berubah. •
Ketika sistem sudah selesai dan diimplementasikan, maka bisa saja timbul
requirement baru atau perubahan pada requirement sebelumnya.
Alasan Perubahan Requirements • Lingkungan bisnis dan teknis pada sistem
selalu berubah setelah instalasi  hardware, regulasi baru, dll. • Orang yang
membayar sistem dan penggunanya belum tentu orang yang sama, sehingga
akan ada konflik kepentingan. • Sistem yang besar kelompok user yang beragam
dengan user requirement yang beragam.
Requirements Change Management • Perubahan pada sistem dilakukan jika
sudah ada persetujuan dari atasan pihak pengembang dan client. • Mencakup
perubahan pada requirements.
Materi ppt 4
1. REQUIREMENTS ANALYSIS 3 Requirements Analysis •
Hasil requirements analysis menandakan interface perangkat lunak dengan
elemen sistem lainnya, dan membangun batasan yang harus diselesaikan oleh
software. • Requirements analysis memungkinkan kita untuk mengelaborasi
basic requirement yang ada
Requirements Modelling (1) Requirements modelling dihasilkan berdasarkan
jenis model yang ada : • Scenario-based models  memodelkan requirement dari
berbagai sudut pandang actor yang berbeda-beda. • Data models  memetakan
domain informasi untuk permasalahan yang ada. • Class-oriented models 
merepresentasikan object-oriented class dan lainnya sehingga memenuhi system
requirement.
Requirements Modelling (2) • Flow-oriented models  merepresentasikan
elemen fungsional dan bagaimana mengubah data yang ada pada sistem
tersebut. • Behavioral models  memetakan bagaimana software bekerja sebagai
konsekuensi dari external event.
Structured Analysis • Merupakan salah satu requirements modeling yang
menggunakan data dan proses, yang menjadi data ke dalam entitas terpisah. •
Data object dimodelkan sehingga dapat mendefinisikan atribut dan
hubungannya. • Proses yang memanipulasi data object yang memodelkan
bagaimana data diubah dalam alur data (data flow) melalui sistem.
Object-oriented Analysis • Pendekatan lain yang terfokus pada pendefinisian
class dan apa saja yang berkolaborasi dengan apapun terkait customer
requirement. • Dengan menggunakan UML (Unified Modeling Language) dan
Unified Process.
2. SCENARIO-BASED MODELING 12 Creating A Preliminary Use Case
• Melibatkan actor  siapa yang menggunakan sistem. • Sebuah use case
menangkap interaksi yang terjadi antara pelaku dan penerima informasi serta
sistem tersebut. • Sebuah use case mendeskripsikan scenario aksi dari sisi
aktornya.
Refining A Preliminary Use Case • Membuat sebuah deskripsi / detail use case
sehingga mudah dipahami secara jelas dan lengkap. • Mencakup apa saja yang
dilakukan oleh sebuah fitur.
Writing A Formal Use Case • Mencatat use case ke dalam sebuah dokumen.
• Agar dapat diberikan kepada developer.
3. UML 19 UML (1)
• Unified Modelling Language (UML) merupakan sebuah graphical language
untuk memvisualisasi, mengspesifikasi, membangun, dan mendokumentasikan
berbagai artifak ke dalam software. • UML memberikan standar untuk membuat
system blueprint, yang mencakup conceptual item (proses bisnis dan fungsi
sistem) yang ditulis ke dalam satu bahasa yang standar.
UML (2) • Merupakan common language yang mengekspresikan ke dalam
banyak model. • Contoh model : – Use case diagram – Activity diagram –
Decomposition diagram – Class diagram – Sequence diagram – Component
diagram – (dll...)
4. CLASS BASED MODELLING
Class-Based Modelling • Merepresentasikan : – Objek di mana sistem
dimanipulasi. – Operasional / fungsi yang akan dijalankan oleh objek. –
Hubungan antar objek. • Model yang dapat digunakan : – Class-responsibility-
collaborator (CRC) model (Class diagram) – Collaboration diagrams
5. FUNCTIONAL MODELING
Functional Model • Merujuk pada 2 elemen pemrosesan aplikasi : – User-
observable functionality, yang akan dikirimkan oleh aplikasi ke end user. –
Operation, yang berisikan class yang dianalisa dan behaviour terkait class. •
Biasanya digambarkan dengan Activity Diagram dan Sequence Diagram.
 6. BEHAVIOURAL MODELING
Use Case Diagram • Menggambarkan fitur apa saja yang terdapat pada sebuah
software. • Disertai dengan use case description / detail untuk setiap use case.

UML Model Yang Mendukung Use Case • Diperlukan Activity Diagram. • 1

(satu) use case pada Use Case Diagram diturunkan/didetailkan ke dalam 1 (satu)
Activity Diagram. • Terdapat “swimlane” yang menandakan actor yang terlibat
dalam Activity Diagram. • Memiliki tanda “start” dan “end”.
7. KONSEP DATA MODELING
Konsep Data Modelling • Jika berhubungan dengan database, maka penting
untuk membuat data model sebagai bagian dari pemodelan sistem. •
Menggunakan entity-relationship diagram (ERD). • ERD merepresentasikan
seluruh data object yang dimasukkan, disimpan, diubah, dan dihasilkan dalam
sebuah aplikasi.
Data Objects • Merupakan sebuah representasi dari informasi yang harus
dipahami oleh software. • Sebuah data object dapat berupa entitas eksternal,
seperti : sesuatu, sebuah benda, sebuah peristiwa, sebuah proses, sebuah tempat,
sebuah unit organisasi, dll. • Sebagai contoh : data object  Car