Chapter 1 : Introduction to OOSAAD

System: Group of entities working together in an environment to achieve a specific goal.

Typical business systems:
- A grocery store
- A restaurant / food court
- A library
- A bank
- A hotel
We live in a world of objects. Object-oriented view is an abstraction that models the world in ways that help
us to better understand and navigate it. Object-oriented approach was first proposed in the late 1960s. As
time passes, object technologies are replacing classical software development approaches. Object
technologies lead to reuse. Object-oriented software is easier to maintain, to adapt, and to scale.
In the early and mid-1990s object-oriented programming developed as the dominant programming
paradigm (C++, Java, etc.). Despite the increasing popularity of object-oriented programming, the analysis
and design activities still employ the traditional approaches (DFD/ERD for modeling and
Waterfall/Prototyping methodologies). Developers started to think of using object-oriented paradigm not
only in programming, but also in analysis and design

Traditional Analysis & Design: Object-Oriented Analysis & Design:

Modeling Notation - Data Flow Diagram - Unified Modeling Language

- Entity Relationship Diagram

Methodologies - Waterfall - Agile Methods

- Prototyping - Unified Process
-
Chapter 2 : Unified Modelling Language
Severe Communication Problem:

Visual Modeling
- Penggunaan diagram dan representasi grafis untuk menggambarkan elemen-elemen yang
terlibat dalam proses analisis dan desain sistem berbasis objek.
- Why penting ? Visual modeling membantu dalam menyelaraskan pemahaman tentang
konsep-konsep penting dalam sistem, seperti kelas, objek, hubungan, dan perilaku. Hal ini
memungkinkan tim untuk memiliki pandangan yang jelas tentang struktur dan
fungsionalitas sistem yang akan dibangun.

Briefly explain what happened during the object-oriented method war in 1990s
Method War (1990s):
• Terjadi pada tahun 1989 – 1994
• Terdapat berbagai metodologi dalam mengembangkan software
• Tidak ada satu pun bahasa yang lengkap, sehingga para software developer tidak puas jika
hanya menggunakan satu bahasa pemrograman saja.

Three Amigos & Contributions to the Development of the UML

Pada tahun 1990an, ada 3 metodologi yang dirasa paling kuat, tapi tidak bisa dikatakan lengkap /
kuat jika berdiri sendiri, yaitu :
• Booch : (Grady Booch)
- Mengembangkan simbol grafik untuk menyajikan beberapa macam aspek model seperti
objek disajikan dengan awan, beberapa anak panah yang merepresentasikan hubungan
- Cukup baik dalam teknik berorientasi objek, tetapi notasi yang digunakan kurang baik
(banyak bentuk-bentuk seperti awan yang mendominasi modelnya).
• OMT (Object Modelling Technique) – DR. James Rumbaugh:
- baik digunakan untuk analisis dan sistem informasi data-intensif.
- Penggunaan grafik OMT lebih sederhana daripada Booch untuk menggambarkan sistem
• OOSE (Object Oriented Software Engineering) – Ivar Jacobson:
- dilengkapi dengan pemodelan yang dikenal dengan Use Case. Use case adalah teknik
yang baik untuk memahami behavior / perilaku keseluruhan sistem

- Notasi booch dan OMT ide sama tapi notasi berbeda kendala. Bagi developer dan
komunikasi menjadi sulit.
- 1994 - James Rumbaugh & Grady Booch bergabung bersama pada Rational diikuti ivar
jacobson pada 1995 Menggabungkan Notasi Booch dan OMT
- 1996 - OMG (Object Management Group) meminta standard notasi OO modeling Rational
(James Rumbaugh , Grady Booch & Ivar Jacobson) menawarkan final proposal OMG
menerima Unified Modeling Language (UML) sebagai bahasa standard pemodelan visual
pada Nopember 1997. diikuti developer dan pers. Lainnya.
- 2001 - anggota merevisi kekurangan dan feature yang kurang 2004 UML2.0 dikeluarkan

What is UML?
The Unified Modeling Language (UML) is a general-purpose, developmental, modelling language in the
field of software engineering that is intended to provide a standard way to visualise the design of a system.
The creation of UML was originally motivated by the desire to standardise the disparate notational systems
and approaches to software design.
Structure diagrams represent the static aspects of the system. It emphasises the things that must be
present in the system being modelled. Since structure diagrams represent the structure, they are used
extensively in documenting the software architecture of software systems.
- Class Diagram
- Component Diagram
- Package Diagram
- Deployment Diagram
Behaviour diagrams represent the dynamic aspect of the system. It emphasises what must happen in the
system being modelled. Since behaviour diagrams illustrate the behaviour of a system, they are used
extensively to describe the functionality of software systems.
- Use Case Diagram
- Activity Diagram
- State Machine Diagram
Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the
things in the system being modeled.
- Sequence Diagram
- Communication Diagram

Chapter 3 : Unified Process

The Unified Process (UP) is an iterative and incremental software development process framework.
Characteristics:
- Iterative and Incremental
- Architecture-centric
- Risk-focused
Phases:
- Inception
- Elaboration
- Construction
- Transition

Inception:
- Develop an approximate vision of the system
- Define the scope
- Conduct a Feasibility Study
- Prepare a preliminary project schedule and cost estimate
- Buy or develop decision
- The Life Cycle Objective Milestone marks the end of the Inception Phase.
Elaboration:
- Define the majority of the system requirements
- Address known risk factor
- Validate the system architecture
- Create Use case diagrams and architectural diagrams (class diagram, package diagram)
- The final Elaboration phase deliverable is a plan for the construction phase.
Construction:
- Construction is the largest phase of the project.
- System features are implemented in a series of short, time-boxed iterations.
- Each iteration results in an executable release of the software.
- Create Activity, Sequence, and State Transition Diagrams.
- The final Construction Phase deliverable is software ready to be deployed in the Transition phase.
Transition:
- Transition is the final project phase.
- The system is deployed to the target users.
- Feedback received from releases may result in further refinements over several iterations.
- The transition phase also includes system conversions and user training.
Unified Process Variation:
- Agile Unified Process
- Basic Unified Process
 - Enterprise Unified Process
- Essential Unified Process
- Open Unified Process
- Rational Unified Process
- Oracle Unified Method
Chapter 4 : Use Case Diagram
Use Case Diagrams represent the functionality of the system from user’s point of view
A complete set of use cases = system requirements
To my knowledge, no other software engineering language construct as significant as use cases has been
adopted so quickly and so widely among practitioners. I believe this is because use cases play a role in so
many different aspects of software engineering (Ivar Jacobson, founding father of UML and creator of Use
Case Diagram)
A Use Case Diagram is a diagram or set of diagrams that together with some additional documentation
show what the proposed software system is designed to do. A Use Case Diagram consists of three main
components:
- Actors
- Use-cases, and their communications
- Some additional documentation such as use-case descriptions for elaborating use-cases and problem
statements that are initially used for identifying use cases
Actor – the people or system that provide or receive information from the system; they are among the
stakeholders of a system
Use Case – a description of a set of sequence of actions, including variants, that system performs that
yields an observable value to an actor
Stereotype (Include / Extend)
- Include’ specifies that the source use case explicitly incorporates the behaviour of another use case at a
location specified by the source
- Extend’ specifies that the target use case extends the behaviour of the source

Actors could be human beings, other systems, or hardware devices that stimulate the system and the
initiators of events (give input to the system) or receive stimuli (output) from the system. Actors should be
named as singular (i.e. student). No names should be used (i.e. John, Sam, etc.)
Identifying actors:
- Who/What will be interested in the system?
- Who/What will want to change the data in the system?
- Who/What will want to interface with the system?
- Who/What will want information from the system?
Use cases should ideally begin with a verb, i.e. generate report. Use cases should NOT be open ended, i.e.
register (instead should be named as ‘register new user’). Avoid showing communication between actors.
Do NOT show behaviour in a use case diagram; instead depict system functionality only. Use case diagram
does not show sequence.
The use of include and extend is discouraged simply because they add unnecessary complexity to a Use
Case diagram. Since the primary purpose of use cases is to show user-centred functionality, the
precedence of use cases takes little importance.
Generally, a use case should embody sufficient levels of granularity without which the use case may not be
rendered as useful
● include : merupakan hal yang wajib (gambar diatas user wajib login untuk apply course)
● Extends: Merupakan optional (gambar diatas user optional untuk melihat course)
Use Case Specification:
Use case specification is synonymous to use case description and use case definition and can be used
interchangeably. Use case specification defines information that pertains to a particular use case which is
important in understanding the purpose behind the use case. Use case specification is written for every use
case. Use case specification serves as a “bridge” between stakeholders of a system and the development
team. Use case specification has one or more flow of events or pathways associated with it.
Flow of Events:
A flow of events is a textual description embodying sequence of events with regards to the use case and is
part of the use case specification. Flow of events is understood by the customer. A detailed description is
necessary so that one can better understand the complexity that might be involved in realising the use
cases. Flow of events describes how and when the use case starts and ends, when the use case interacts
with the actors, and the information interchanged between an actor and the use case. But NOT describe
user interface details NOR technical specs. Flow of events is generally a text-based file included under its
use case in Visual Paradigm or other UML diagramming tools. Types of Events, including:
- Basic Flow of Events – is the most common pathway. It usually depicts a perfect situation, in which nothing
goes wrong
- Alternate Flow of Events – is a pathway that is still considered a good pathway; it is just not the most heavily
travelled one
- Exception Flow of Events – things don’t always go as planned. An exception is an error condition that is
important enough to the application to capture

Chapter 5 : Activity Diagram

Activity Diagram describes the workflow behaviour of a system. A typical business process which
synchronises several events can be represented by activity diagrams. Activity Diagrams are most useful for
understanding workflow analysis of synchronous behaviours across a process.
An Activity Diagram is a diagram that describes the state of activities by showing the sequence of activities
performed. They can show activities that are conditional or parallel. An Activity Diagram consists of three
main components:
 - Activity
- Event
- Decision
Activity – An activity is an ongoing, though interruptible, execution of a step in a workflow (such as an
operation or transaction). Text in the activity box should represent an activity( verb phrase in present tense).
Event – An event is triggered by an activity. It specifies a significant occurrence that has a location in time
and space. Label text for events should represent events but not the data involved.
Decision – A decision may be shown by labelling multiple output transitions of an activity with different
guard conditions.
How to Draw an Activity Diagram:
Diagrams are read from top to bottom and have branches and forks to describe conditions and parallel
activities.
- A fork is used when multiple activities are occurring at the same time.
- A branch describes what activities will take place based on a set of conditions.
- All branches at some point are followed by a merge to indicate the end of the conditional behaviour started by
that branch.
- After the merge all of the parallel activities must be combined by a join before transitioning into the final
activity state.
Forking & Joining:
Forking and Joining use a synchronisation bar to specify the forking and joining of parallel flows of control.
A synchronisation bar is rendered as a thin horizontal or vertical line. A fork may have one incoming event
and two or more outgoing events. The activities of each outgoing event are concurrent. A join may have two
or more incoming events and one outgoing event.

Swimlanes:
Activity Diagrams tell you what happens, but they do not tell you who does what. In programming, this
means that the diagram does not convey which class is responsible for each activity. A swimlane is a way
to group activities performed by the same actor on an activity diagram or to group activities in a single
thread. Each swimlane is divided from its neighbour by a vertical solid line.
A. Unified Modeling Language (UML)
1. Visual Modeling adalah penggunaan diagram-diagram visual untuk mempresentasikan konsep dan desain sistem
perangkat lunak. Visual Modeling penting karena membantu mengomunikasikan desain dengan lebih baik dan
meningkatkan pemahaman terhadap sistem.
2. Tiga orang yang berkontribusi pada pengembangan UML pada 1990-an adalah Grady Booch, Ivar Jacobson, dan
James Rumbaugh. Mereka mempopulerkan metodologi pemodelan visual yang kemudian menjadi standar UML.
3.

● Grady Booch: Dia mengembangkan notasi Booch yang memberikan kontribusi pada aspek desain dan
implementasi dalam UML. Pendekatannya terhadap pemodelan objek dan perangkat lunak berorientasi objek
sangat mempengaruhi UML.
● James Rumbaugh: Dia adalah pencipta Object Modeling Technique (OMT), yang memberikan kontribusi pada
aspek analisis dan representasi data dalam UML. Metodologinya membantu dalam mengintegrasikan teknik
pemodelan objek ke dalam UML.
● Ivar Jacobson: Dia mengembangkan Object-Oriented Software Engineering (OOSE) yang memperkenalkan
konsep use case yang menjadi bagian penting dari UML. Use case membantu dalam menggambarkan
interaksi antara pengguna dan sistem.
Pada tahun 1994:

● James Rumbaugh bergabung dengan Grady Booch di Rational Corp untuk menggabungkan ide mereka.

● Pada tahun 1995, Ivar Jacobson juga bergabung, dan ketiganya dikenal sebagai “Three Amigos”.
● Mereka melahirkan Unified Method yang kemudian dikenal sebagai Unified Modelling Language (UML).

4.

Aktor adalah entitas eksternal yang berinteraksi dengan sistem.

Contoh: Dalam sistem perbankan, “Nasabah” adalah aktor yang berinteraksi dengan sistem untuk melakukan
transaksi seperti penarikan uang.

Use Case Diagram menggambarkan fungsionalitas sistem dari perspektif pengguna/mewakili apa
yang diinginkan oleh aktor untuk dilakukan oleh sistem.
Contoh: “Melakukan Pembayaran” adalah kasus penggunaan di mana nasabah melakukan
serangkaian langkah untuk membayar tagihan melalui sistem perbankan online.

Stereotip/Dependensi dalam UML adalah label yang memberikan makna

khusus pada elemen model
<<include>> include adalah sesuatu sistem yang harus dilakukan terlebih
dahulu sebelum melakukan sistem selanjutnya.
<<extend>>: perluasan sistem

Fork/Join -> memisahkan dan menggabungkan aliran.

Contoh: Dalam proses pemesanan, fork bisa terjadi ketika
pesanan diproses sementara pembayaran diverifikasi secara
paralel, dan join terjadi ketika kedua proses tersebut selesai
dan pesanan siap untuk dikirim.

●
Swimlanes -> pembagian visual dalam Diagram Aktivitas yang menunjukkan siapa yang bertanggung jawab atas
tindakan atau keputusan tertentu dalam proses.
Contoh: Dalam proses digambar, swimlane bisa digunakan untuk memisahkan aktivitas yang dilakukan oleh
“actor 1”, “sistem”, dan “actor 2”.

Branch/Merge digunakan untuk menggambarkan pilihan

kondisional.

● Branch/Merge: Branch adalah titik keputusan di mana

alur kontrol bisa mengambil salah satu dari beberapa
jalur berdasarkan kondisi tertentu. Merge adalah titik di
mana jalur-jalur yang terpisah dari branch bertemu
kembali. Contoh: Dalam sistem pendaftaran online,
branch terjadi ketika pengguna harus memilih antara
mendaftar sebagai “Mahasiswa” atau “Dosen”, dan
merge terjadi setelah kedua proses pendaftaran tersebut
selesai dan kembali ke alur utama.
Use case diagram
Activity diagram
1. Use Case Diagram adalah suatu diagram yang menggambarkan konteks sistem yang akan dibangun
dan fungsi yang disediakan oleh sistem tersebut. Use Case harus dapat mempresentasikan fungsi utama
dari sebuah sistem.

2. Keuntungan Use Case Diagram adalah:

- Use Case lebih ringkas, sederhana dan mudah dipahami oleh berbagai pihak.
- Use Case mengatur sejumlah aktivitas dalam proses.
- Pembuatan dan validasi model desain.
- Perencanaan iterasi.
- Pembuatan dokumentasi bagi pengguna.

3. Actor adalah entitas yang berinteraksi dengan sistem (dapat berupa orang atau sistem lain). Sebuah
Actor memiliki karakteristik sebagai berikut:
- Seseorang atau sesuatu diluar sistem yang berinteraksi dengan sistem.
- Tidak berkaitan dengan data.
- Hanya menunjukkan siapa/apa saja yang dapat mengakses sistem.
- Biasanya identik dengan operator komputer.
- Bisa juga berupa mesin atau sistem lain.

4. Jenis Actor adalah:

- Users: Termasuk semua orang yang berperan sebagai user seperti targeted end-users, administrators,
manager.
- Applications: Termasuk semua sistem dan program lain yang berinteraksi dengan sistem.
- Devices: Termasuk sensor dan actuator (peralatan mekanis untuk mengendalikan atau mengontrol
sebuah mekanisme atau sistem).
- External Events: Periodic triggers seperti jam.

5. Relationships between Actors adalah:

- Hubungan antar Actor disebut inheritance relationship (generalization).
- Pada contoh: Actor Y (sub-actor) adalah turunan dari Actor X (super-actor). Artinya, Y terlihat dengan
semua use cases yang berasosiasi dengan X.
- Dengan kata lain, generalization mengekspresikan hubungan "is a".
6. Actor - Generalization adalah beberapa actor terkadang memiliki peran yang sama terhadap sistem.
Contohnya, Student memiliki peran Full-Time Student dan Part-Time Student.

7. Contoh: Actor
- Generalization adalah:
- Setiap Research Associate dapat meng-execute usecase Query Student Data.
- Setiap processor yang dapat meng-execute use case Create Course.
- Setiap assistant yang dapat melakukan Publish Task.
- Untuk meng-execute use case Issue Certificate dibutuhkan Profesor, sedangkan actor Assistant dapat
terlibat secara optional(ditunjukkan dengan multiplicity 0..1).

8. Pada gambar di kedua actor harus berpartisipasi pada use case secara individually. Pada gambar B:
keyword "(instance)" menunjukkan bahwa tidak ada instance dari actor Research Associate. Masing-
masing aktor Profesor dan Assistant dapat berpartisipasi pada usecase secara individually.

9. 1-Actor, N-Peran adalah lihat perannya bukan orangnya. Contohnya, Charlie sebagai student dan
Charlie sebagai profesor memiliki peran yang berbeda terhadap aktor Student dan Profesor.

10. Menentukan Actor adalah beberapa pertanyaan untuk membantu menentukan Actor:
- Siapa yang akan mensuplay, menggunakan atau menghilangkan informasi?
- Siapa yang akan menggunakan sistem ini?
- Siapa yang berkepentingan dengan kebutuhan ini?
- Di manakah dalam organisasi, sistem ini akan digunakan?
- Siapa yang akan men-support dan me-maintain sistem?
- Ada resource dari luar yang akan diperlukan oleh sistem?
- Adakah sistem lain yang berhubungan dengan sistem?

11. Check Point Actor adalah beberapa pertanyaan untuk memastikan adakah Actor yang ditentukan sudah
tepat:
- Sudahkah semua actor teridentifikasi?
- Adakah masing-masing actor seharusnya terlibat dengan sebuah usecase?
- Adakah actor tersebut benar-benar berperan dalam sistem?
- Adakah actor yang masih di sebut atau di sebut?
- Adakah 2 actor atau lebih yang memiliki peran yang sama?
- Adakah setiap actor telah memiliki deskripsi yang jelas?
- Bisakah user memahami istilah atau penaman dari masing-masing actor?

12. Use Case adalah use case mewakili apa yang diinginkan oleh actor untuk dilakukan oleh sistem.
- Perwujudan dari fungsi-fungsi utama sebuah sistem.
- Harus merupakan alur aktivitas yang lengkap dari sudut pandang actor.
- Mengakup beberapa cara actor untuk mengakses sistem (fungsionalitas).

13. Menentukan Use Case adalah beberapa pertanyaan untuk membantu menentukan Use Case:
- Ada tugas yang dilakukan oleh masing-masing actor?
- Apakah aktir melakukan create, store, remove atau read informasi dari sistem?
- Apakah actor lain memberikan informasi mengenai perubahan informasi?
- Adakah actor membutuhkan informasi mengenai perubahan atau kejadian yang terjadi dalam sistem?

14. Check Point Use Case adalah beberapa pertanyaan untuk memastikan apakah Use Case yang dipilih
sudah tepat:
- Apakah setiap use case yang ada, terlibat setidaknya 1 actor?
- Apakah setiap use case independent dengan yang lain?
- Adakah ada use case yang memiliki deskripsi yang sangat mirip?
- Apakah use case memiliki nama yang unik, intuitif dan jelas sehingga mereka tidak dapat digabungkan
sampai pada tahap berikutnya?
- Apakah pengguna dapat memahami nama dan deskripsi dari use case?
15. Boundaries adalah batas antara sistem dan lingkungannya. Contohnya pada gambar, Bank System
adalah sistem boundary, sedangkan Customer, Bank Teller, dan ATM System berada di luar sistem
boundary.

1. Boundaries adalah batasan-batasan yang membatasi interaksi antara aktor dengan sistem.
- Goal Collect Items on Sales adalah tujuan untuk mengumpulkan item penjualan.
- Customer adalah aktor yang membeli barang.
- Goal Buy Items adalah tujuan untuk membeli barang.
- Goal Analyze sales and performance data adalah tujuan untuk menganalisis data penjualan dan kinerja.

2. Association/Relationship:
- Use Case adalah sebuah fungsi atau layanan yang disediakan oleh sistem.
- Actor sebagai Initiator adalah aktor yang memulai atau menggunakan Use Case.
- Actor sebagai Responder adalah aktor yang menanggapi atau terlibat dalam Use Case.

3. Relationship - Stereotype/Dependencies:
- Include adalah suatu sistem yang harus dilakukan terlebih dahulu sebelum melakukan sistem
selanjutnya.
- Extend adalah perluasan sistem.

4. Contoh Include/Extend:
- "Order goods" include "Check customer credit" adalah Use Case "Order goods" harus melakukan
"Check customer credit" terlebih dahulu sebelum melanjutkan.
- "Chase payment" extend "Issue warning letter" adalah Use Case "Chase payment" dapat diperluas
dengan "Issue warning letter".

5. Relationship - Generalization:
- Pembelian Tiket adalah konsep umum.
- Pembelian Tiket Konser, Pembelian Tiket Bioskop, dan Pembelian Tiket Kereta Seri adalah spesialisasi
atau jenis-jenis dari Pembelian Tiket.

6. Packages:
- Mekanisme pengelompokkan adalah untuk mengelompokkan elemen-elemen menjadi kelompok
semantik terkait.
- Biasanya digunakan untuk mencerminkan keterbatasan dalam sistem.
- Dikelompokkan berdasarkan baris pengguna atau baris operasi.

7. Use Case Diagram:

- Diagram ini menunjukkan interaksi antara aktor dengan sistem melalui Use Case.
- Contoh yang diberikan adalah Sistem Pendaftaran Kursus Universitas.

8. Flow of Event:
- Untuk menjelaskan langkah-langkah dan tahapan kondisi apa saja yang terjadi pada setiap sistem yang
ada.
- Berbentuk narasi.

9. Flow of Event memiliki:

- Normal Flow (basic flow) atau "Happy Path" adalah aliran utama yang diharapkan.
- Alternative Flow adalah aliran alternatif yang mungkin terjadi.
- Regular Variants adalah variasi yang masih dalam aliran utama.
- Odd Cases (situasi berulang) adalah situasi yang berulang namun masih dalam aliran utama.
- Exceptional Flows (menangani situasi error) adalah aliran untuk menangani situasi error atau
kesalahan.

10. Petunjuk Pembuatan Flow of Event:

- Definisikan bagaimana Use Case tersebut dimulai dan diakuiri, data apa saja yang terkait (tidak boleh
menceritakan detail interaksi).
- Jelaskan Flow of Event sehingga aktor terlibat dalam mendokumentasikan sistemnya.
- Deskripsikan event yang terjadi pada Use Case tersebut (yang tergambar pada Use Case).
 - Hindari deskripsi yang terlalu rinci, cukup sederhana saja contoh dll, dst, etc.
- Pertanyaan atau detail harus terjawab.
- Dilengkapi dengan Alternate Flow.
- Tidak boleh menggunakan kata "DATABASE", "TABEL" dalam basic flow.
- Harus konsisten dalam penggunaan istilah dan harus digunakan sesuai glossary (kamus) untuk
memfasilitasi istilah yang digunakan.

B. Unified Process
1a. Aktivitas Software Development
1. Business Modeling adalah mengidentifikasi kemampuan sistem yang akan dibuat dan keinginan
user. (proses pemodelan sistem)
2. Requirements adalah sebuah narasi tujuan bersama tentang kebutuhan fungsional dan non-
fungsional. (proses cari kebutuhan/requirement sistem)
3. Analysis and Design adalah gambaran tentang bagaimana sistem akan dibuat pada tahap
implementasi. (pahami requirement sistem yg udh dicari & design)
4. Implementation adalah proses coding dengan hasil berupa file eksekutable (.exe). (implementasi ke
code)
5. Test adalah verifikasi sistem secara menyeluruh. (testing code)
6. Deployment adalah meliputi pemasangan sistem dan training user.
1b. Fase Software Deployment
a. Inception: menetapkan visi atau tujuan project
b. Elaboration:
- merencanakan aktivitas dan resource yang dibutuhkan
- menentukan fitur-fitur dan desain arsitektur
- mulai iterasi
c. Construction:
- mulai membangun software
- mengelola sumber daya, mengendalikan kegiatan untuk mengoptimalkan biaya, jadwal, dan kualitas
d. Transition:
- mensupply produk software yang telah dibuat kepada komunitas user (pemasaran, pengemasan,
menginstal, mengkonfigurasikan, training, dll)
2. System decomposition (partitioning) adalah memecah sistem menjadi beberapa bagian untuk
pengelolaan yang lebih baik. Contohnya adalah memisahkan fungsionalitas utama menjadi beberapa
subsistem atau komponen.
3. Keuntungan Unified Process dibandingkan Waterfall adalah pengembangan iteratif, beradaptasi dengan
perubahan, penyampaian lebih cepat, dan integrasi yang lebih baik antara disiplin pengembangan.
4. Testing dapat dimulai dari fase Inception dengan mengidentifikasi kebutuhan dan skenario pengujian
sejak awal.
5. Aktivitas dalam fase Inception meliputi mendefinisikan lingkup proyek, membangun bisnis kasus,
tentukan strategi resiko, dan perencanaan arsitektur awal.

II. Fokus
 1. Business Modeling dalam mengembangkan suatu aplikasi adalah pemodelan objek sangatlah
penting. Ketika terlibat dalam analisis bisnis skala besar atau rekayasa ulang proses bisnis,
termasuk pemodelan yang dinamis di seluruh perusahaan.
2. Requirements adalah mengidentifikasi kebutuhan baik fungsional maupun non-fungsional.
3. Analysis and Design adalah mencakup semua aspek desain, termasuk seluruh arsitektur, objek,
database, jaringan, DLL (Dynamic Link Library).
III. Pengertian Business Modeling
1. Business Modeling adalah teknik pemodelan yang digunakan untuk menggambarkan model sebuah
bisnis.
2. Business Modeling dapat digunakan untuk meninjau, meningkatkan, dan membuat sebuah bisnis.
IV. Tujuan Business Modeling
1. Memahami struktur dan dinamika organisasi.
2. Memahami masalah-masalah dalam mencapai target organisasi dan menemukan potensi untuk
kemajuan organisasi.
3. Yakin bahwa para customer, end user dan developer mempunyai sebuah pemahaman yang benar
mengenai organisasi.
4. Dapat menurunkan/mendapatkan requirement software aplikasi yang akan dibuat dan diperlukan
untuk mendukung pencapaian target organisasi.
V. Jenis Business Modeling
1. Use-case bisnis (business use case model) adalah menggambarkan proses dalam suatu bisnis dan
interaksi-interaksi dengan pihak luar seperti pada customer dan partner.
2. Model objek bisnis (business object model) adalah menggambarkan realisasi dari business use-
case.

Fase dalam Software Deployment (iterative) (LENGKAP)

1. Inception - Aktivitas
- Merumuskan ruang lingkup proyek
- Kebutuhan setiap stakeholder, ruang lingkup, kondisi batas, dan kriteria penerimaan ditetapkan
- Rencanakan dan menyiapkan kasus bisnis
- Tentukan strategi resiko, kembangkan rencana proyek awal dan identifikasikan biaya, jadwal, dan segala
probabilitas yang diketahui
- Menyiapkan arsitektur kandidat dengan mengambil dari berbagai arsitektur yang potensial
- Inception bukan fase requirement, melainkan fase feasibility yang melakukan investigasi awal untuk
menentukan apakah proyek dilanjutkan atau tidak

2. Inception - Output
- Memiliki perumusan yang jelas dari visi produk, persyaratan utama (dalam hal fungsionalitasnya, ruang
lingkup, kinerja, kapasitas, dan basis teknologinya)
- Kriteria keberhasilan (proyeksi pendapatan)
- Penilaian resiko awal
- Perkiraan sumber daya yang diperlukan untuk menyelesaikan fase elaboration

3. Elaboration - Input
- Output dari fase sebelumnya
- Revisi visi/tujuan
- Rencana yang telah disetujui oleh manajemen proyek, dan otoritas pendanaan, dan sumber daya yang
diperlukan untuk tahap elaboration telah dialokasikan
- Identifikasi sebagian besar kebutuhan dan ruang lingkup

4. Elaboration - Aktivitas
- Tentukan arsitekturnya, rencana proyek didefinisikan, proses, infrastruktur dan lingkungan
pengembangan dijelaskan secara iterative
- Keputusan yang High Risk
- Validasi arsitektur dengan estimasi yang lebih realistik
- Baseline arsitektur untuk memberikan dasar yang stabil untuk sebagian besar desain dan upaya
implementasi dalam tahap konstruksi

5. Elaboration - Output
- Rencana pengembangan software terpenting dengan penilaian resiko terbaru, rencana manajemen,
rencana kepegawaian, rencana tahap yang menunjukkan jumlah dan isi dari iterasi, rencana iterasi dan
rencana pengujian
- Lingkungan pengembangan dan tools yang digunakan
- Visi dasar dalam bentuk seperangkat kriteria evaluasi untuk produk akhir
- Model analisis domain, dapat menggunakan arsitektur yang sudah lengkap atau sesuai
- Arsitektur dasar sudah dapat dieksekusi

6. Construction - Input
- Output dari fase sebelumnya
- Rencana iterasi harus menyatakan tujuan spesifik iterasi
- Resiko dikurangi selama iterasi ini (lower risk)
- Cacat atau error diperbaiki selama iterasi

7. Construction - Aktivitas
- Kembangkan dan uji komponennya, komponen yang diperlukan harus sesuai dengan usecase, skenario
dan interoperabilitas yang ditentukan, test unit dan integrasi dilakukan pada komponen
- Mengelola sumber daya dan proses control dengan persiapan untuk deployment
- Menilai iterasi dengan keputusan tujuan iterasi ditentukan

8. Construction - Output
- Produk dan kenyataan harus sama, diperdebatui, ditambah
- Mendokumentasikan hasil dari iterasi
- Uji kasus dan hasil test dilakukan pada produk
- Rencana iterasi dan meringkat iterasi selanjutnya
- Kriteria evaluasi yang terukur secara objektif untuk menilai hasil iterasi berikutnya

9. Transition - Input
- Output dari fase sebelumnya
- Khusus pada software yang cukup matang untuk dimasukkan ke tangan pengguna/user

10. Transition - Aktivitas

- Uji produk yang dihasilkan di tempat user/perusahaan user (Beta Testing)
- Sempurnakan produk berdasarkan feedback/umpan balik pengguna
- Kirimkan produk akhir pada customer (Deployment)
- Menyelesaikan materi pendukung (termasuk dokumentasi) untuk customer

11. Transition - Output

- Pembaruan dari beberapa dokumen sebelumnya (termasuk kriteria yang asli dan yang revisi)
- Inventaris singkat aset baru organisasi sebagai hasil dari siklus ini

Jadi, secara garis besar adalah tahapan dalam metode waterfall meliputi inception (permulaan), elaboration
(perluasan), construction (konstruksi), dan transition (transisi) yang masing-masing memiliki aktivitas dan
output tertentu sebagai bagian dari siklus hidup pengembangan perangkat lunak.