SISTEM ANALISIS DAN DESIGN

Nama Anggota :
- ARCHADIUS CHRISTIAN ABIMANYU
12030121140255
- DINAR FENISIA
12030121140297
- FADILLAH MOHAMMAD RAFID
12030121140266
- LEANDER VICTORIO DEMARDIN
12030121140303

BAB I

PENGENALAN MENGENAI SISTEM ANALISIS DAN DESAIN

Apa itu Systems development life cycle ( SDLC ) ?

Systems development life cycle (SDLC ) atau siklus hidup pengembangan sistem adalah proses memahami
bagaimana sistem informasi (SI) yang dapat mendukung kebutuhan bisnis dengan merancang sistem,
membangunnya, dan menyampaikannya kepada pengguna.

SIKLUS HIDUP PENGEMBANGAN SISTEM

SDLC memiliki rangkaian empat fase mendasar yang serupa: perencanaan, analisis, desain, dan penerapan. Proyek
yang berbeda mungkin menekankan bagian yang berbeda dari SDLC atau mendekati Fase SDLC dengan cara yang
berbeda, tetapi semua proyek memiliki elemen dari empat fase ini. Setiap fase adalahitu sendiri terdiri dari
serangkaian langkah, yang mengandalkan teknik yang menghasilkan kiriman (spesifik dokumen dan file yang
memberikan pemahaman tentang proyek).
1. Perencanaan
Fase perencanaan adalah proses mendasar untuk memahami mengapa sistem informasi harus dibangun dan
menentukan bagaimana tim proyek akan membangunnya. Memilikii 2 langkah :

● Bagaimana itu akan menurunkan biaya atau meningkatkan pendapatan? Permintaan sistem
menyajikan ringkasan singkat tentang bisnis
kebutuhan, dan menjelaskan bagaimana sistem yang mendukung kebutuhan akan menciptakan
nilai bisnis. Departemen SI bekerja sama dengan orang atau departemen yang menghasilkan
meminta (disebut sponsor proyek) untuk melakukan analisis kelayakan.

● Setelah proyek disetujui, ia memasuki manajemen proyek. Selama manajemen proyek, manajer
proyek membuat rencana kerja,membentuk staf proyek, dan menerapkan teknik untuk membantu
tim proyek mengendalikan dan mengarahkan proyek melalui seluruh SDLC. Hasil untuk
manajemen proyek adalah rencana proyek, yang menjelaskan bagaimana tim proyek akan
mengembangkan sistem.

2. Analisis
Tahap analisis menjawab pertanyaan tentang siapa yang akan menggunakan sistem, sistem apa yang akan
digunakan lakukan, dan di mana dan kapan akan digunakan. Selama fase ini, tim proyek menyelidiki setiap
sistem saat ini, mengidentifikasi peluang untuk perbaikan, dan mengembangkan konsep untuk
sistem baru.
Fase ini memiliki tiga langkah:
● Strategi analisis dikembangkan untuk memandu upaya tim proyek. Strategi seperti itu biasanya mencakup
analisis sistem saat ini (disebut sistem apa adanya) dan
masalah dan kemudian cara merancang sistem baru (disebut sistem yang akan datang).
● Langkah selanjutnya adalah pengumpulan persyaratan (misalnya, melalui wawancara atau
kuesioner).Analisis informasi ini—bersama dengan masukan dari proyek sponsor dan banyak orang lain—
mengarah pada pengembangan konsep untuk yang baru sistem. Konsep sistem tersebut kemudian dijadikan
dasar untuk mengembangkan seperangkat bisnis model analisis, yang menggambarkan bagaimana bisnis
akan beroperasi jika sistem baru dikembangkan.

● Analisis, konsep sistem, dan model digabungkan menjadi sebuah dokumen yang disebut proposal sistem,
yang dipresentasikan kepada sponsor proyek dan pengambil keputusan utama lainnya (misalnya, anggota
komite persetujuan) yang memutuskan apakah proyek harus terus bergerak maju.
3. Rancangan
Tahap desain memutuskan bagaimana sistem akan beroperasi, dalam hal perangkat keras, perangkat
lunak,dan infrastruktur jaringan; antarmuka pengguna, formulir, dan laporan; dan program khusus,database,
dan file-file yang akan dibutuhkan. langkah-langkah dalam fase desain menentukan dengan tepat
bagaimana sistem akan beroperasi. Fase desain memiliki empat langkah:
● Strategi desain pertama kali dikembangkan. Ini menjelaskan apakah sistem akan dikembangkan
oleh pemrogram perusahaan sendiri, apakah sistem akan dialihdayakan ke perusahaan lain
(biasanya perusahaan konsultan), atau apakah perusahaan akan membeli paket perangkat lunak
yang sudah ada.
● menjelaskan perangkat keras, perangkat lunak, dan infrastruktur jaringan yang akan digunakan. Di
sebagian besar kasus, sistem akan menambah atau mengubah infrastruktur yang sudah ada di
organisasi. Desain antarmuka menentukan bagaimana pengguna akan bergerak melalui sistem
(misalnya, metode navigasi seperti menu dan tombol di layar) dan formulir
dan laporan yang akan digunakan sistem.
● Basis data dan spesifikasi file dikembangkan. Ini mendefinisikan dengan tepat data apa yang akan
disimpan dan dimana akan disimpan.
● Tim analis mengembangkan desain program, yang menentukan program yang perlu ditulis dan
persis apa yang akan dilakukan setiap program.

4. Penerapan
Fase terakhir dalam SDLC adalah fase implementasi, di mana sistem sebenarnya
dibangun (atau dibeli, dalam hal desain perangkat lunak yang dikemas). Ini adalah fase yang biasanya
mendapat perhatian paling besar, bagian dari proses pembangunan. Fase ini memiliki tiga langkah:

● Konstruksi sistem adalah langkah pertama. Sistem ini dibangun dan diuji untuk memastikan
bahwa melakukan seperti yang dirancang. Karena biaya bug bisa sangat besar, pengujian adalah
salah satunya langkah yang paling kritis dalam implementasi. Sebagian besar organisasi
memberikan lebih banyak waktu dan memperhatikan pengujian daripada menulis program di
tempat pertama.
● Sistem sudah terpasang. Instalasi adalah proses dimana sistem lama dihidupkan dimatikan dan
yang baru dihidupkan. Salah satu aspek terpenting dari konversi adalah pengembangan rencana
pelatihan untuk mengajari pengguna cara menggunakan sistem baru dan membantu mengelola
perubahan yang disebabkan oleh sistem baru.
● Tim analis menetapkan rencana dukungan untuk sistem. Ini rencana biasanya mencakup tinjauan
pasca-implementasi formal atau informal serta tinjauan sistematis cara untuk mengidentifikasi
perubahan besar dan kecil yang diperlukan untuk sistem.
 PERAN DAN KETERAMPILAN ANALIS SISTEM KHUSUS

Jelas dari berbagai fase dan langkah yang dilakukan selama SDLC bahwa tim proyek membutuhkan berbagai
keterampilan. Memahami apa yang harus diubah dan bagaimana mengubahnya—dan meyakinkan orang lain tentang
kebutuhan akan perubahan—membutuhkan berbagai keterampilan. Keterampilan ini dapat dibagi menjadi enam
kategori utama: teknis, bisnis, analitis, interpersonal, manajemen, dan etika.. Analis adalah pemecah masalah
berkelanjutan baik di tingkat proyek maupun organisasi, dan mereka menguji kemampuan analitis mereka secara
teratur. Analis sering perlu berkomunikasi secara efektif dengan pengguna dan manajer bisnis (yang sering kurang
berpengalaman dengan teknologi) dan dengan programmer (yang sering memiliki keahlian teknis lebih dari analis).
Akhirnya, analis harus berurusan secara adil, jujur, dan etis dengan anggota tim proyek lainnya, manajer, dan
pengguna sistem.

Analis Bisnis
Seorang analis bisnis berfokus pada masalah bisnis di sekitar sistem. Isu-isu ini termasuk mengidentifikasi nilai
bisnis yang akan dibuat oleh sistem, mengembangkan ide dan saran tentang bagaimana proses bisnis dapat
ditingkatkan, dan merancang proses dan kebijakan baru yang berhubungan dengan analis sistem. Orang ini
kemungkinan memiliki pengalaman bisnis dan beberapa jenis pelatihan profesional.

Analis Sistem
Seorang analis sistem berfokus pada isu-isu IS seputar sistem. Orang ini mengembangkan ide dan saran tentang
bagaimana teknologi informasi dapat meningkatkan proses bisnis, merancang proses bisnis baru dengan bantuan
dari analis bisnis, merancang sistem informasi baru, dan memastikan bahwa semua standar IS dipertahankan.

Analis Infrastruktur
Seorang analis infrastruktur berfokus pada masalah teknis seputar bagaimana sistem akan
berinteraksi dengan infrastruktur teknis organisasi (misalnya, perangkat keras, perangkat lunak, jaringan,
dan basis data). Tugas seorang analis infrastruktur meliputi memastikan bahwa informasi baru tersebut
sistem sesuai dengan standar organisasi dan mengidentifikasi perubahan infrastruktur yang diperlukan untuk
mendukung sistem.

Analis Manajemen Perubahan

Seorang analis manajemen perubahan berfokus pada orang-orang dan masalah manajemen seputar instalasi sistem.
Peran orang ini termasuk memastikan bahwa dokumentasi dan dukungan yang memadai tersedia bagi pengguna,
memberikan pelatihan pengguna pada sistem baru, dan mengembangkan strategi untuk mengatasi perlawanan
terhadap perubahan. Dia mewakili kepentingan sponsor proyek dan pengguna untuk siapa sistem sedang dirancang.
Seorang analis manajemen perubahan bekerja paling aktif selama tahap implementasi tetapi mulai meletakkan dasar
untuk perubahan selama tahap analisis dan desain.

Manajer Proyek
Seorang manajer proyek bertanggung jawab untuk memastikan bahwa proyek selesai tepat waktu dan dalam
anggaran dan bahwa sistem memberikan semua keuntungan yang dimaksudkan oleh sponsor proyek. Peran manajer
proyek termasuk mengelola anggota tim, mengembangkan rencana proyek, menugaskan sumber daya, dan menjadi
titik kontak utama ketika orang-orang di luar tim memiliki pertanyaan tentang proyek. Individu ini kemungkinan
memiliki pengalaman yang signifikan dalam manajemen proyek dan mungkin telah bekerja selama bertahun-tahun
sebagai analis sistem sebelumnya.

KARAKTERISTIK DASAR SISTEM BERORIENTASI OBJEK

Sistem berorientasi objek berfokus pada menangkap struktur dan perilaku sistem informasi dalam modul-modul
kecil yang mencakup baik data maupun proses. Di bagian ini, kami menjelaskan karakteristik dasar sistem
berorientasi objek, yang mencakup kelas, objek, metode, pesan, enkapsulasi, persembunyian informasi, warisan,
polimorfisme, dan pengikatan dinamis.

Kelas dan Objek

Kelas adalah template umum yang kita gunakan untuk menentukan dan membuat contoh, atau objek tertentu. Setiap
objek terkait dengan kelas. Misalnya, semua objek yang menangkap informasi tentang pasien bisa jatuh ke dalam
kelas yang disebut Pasien, karena ada atribut (misalnya, nama, alamat, tanggal lahir, telepon, dan asuransi) dan
metode (misalnya, membuat janji, menghitung kunjungan terakhir, mengubah status, dan memberikan riwayat
medis) bahwa semua pasien berbagi objek adalah sebuah instrumen antisipasi kelas. Dengan kata lain, objek adalah
orang, tempat, atau hal yang ingin kita tangkap.

Setiap objek memiliki atribut yang menjelaskan informasi tentang objek, seperti pasien
nama, tanggal lahir, alamat, dan nomor telepon. Atribut juga digunakan untuk mewakili hubungan antar objek;
misalnya, mungkin ada atribut departemen dalam objek karyawan dengan nilai objek departemen yang menangkap
departemen di mana objek karyawan bekerja. Keadaan suatu objek ditentukan oleh nilai atribut dan hubungannya
dengan objek lain pada titik tertentu dalam waktu tertentu. Misalnya, seorang pasien mungkin memiliki keadaan
baru atau sekarang atau sebelumnya.Setiap objek juga memiliki perilaku. Perilaku menentukan apa yang dapat
dilakukan objek. Misalnya, objek pertemuan mungkin dapat menjadwalkan pertemuan baru, menghapus pertemuan,
dan menemukan pertemuan berikutnya yang tersedia. Dalam pemrograman berorientasi objek, perilaku
diimplementasikan sebagai metode (lihat bagian berikutnya). Salah satu aspek yang lebih membingungkan dari
pengembangan sistem berorientasi objek adalah fakta bahwa dalam sebagian besar bahasa pemrograman
berorientasi objek, baik kelas maupun contoh kelas dapat memiliki atribut dan metode. Atribut dan metode kelas
cenderung digunakan untuk model atribut (atau metode) yang menangani masalah yang berhubungan dengan semua
contoh kelas. Sebagai contoh, untuk membuat objek pasien baru, pesan dikirim ke kelas Pasien untuk membuat
instansi baru dari dirinya sendiri. Namun, dalam buku ini, kita terutama berfokus pada atribut dan metode objek dan
bukan kelas.

Metode dan Pesan

Metode menerapkan perilaku objek. Sebuah metode tidak lebih dari sebuah tindakan yang
objek dapat melakukan. Pesan adalah informasi yang dikirim ke objek untuk memicu metode. Sebuah pesan
pada dasarnya adalah panggilan fungsi atau prosedur dari satu objek ke objek lain. Sebagai contoh, jika
pasien baru ke kantor dokter, resepsionis mengirimkan pesan untuk membuat aplikasi.
Kelas pasien menerima pesan pembuatan dan mengeksekusi metode pembuatannya yang kemudian
membuat objek baru: Pasien

Enkapsulasi dan Informasi yang Disembunyikan

Ide enkapsulasi dan penyembunyian informasi saling terkait dalam sistem berorientasi objek.
Namun, kedua istilah tersebut tidak baru. Enkapsulasi hanyalah kombinasi dari proses
dan data menjadi satu entitas. Persembunyian informasi pertama kali dipromosikan dalam sistem terstruktur
Pengembangan. Prinsip penyembunyian informasi menunjukkan bahwa hanya informasi

Yang diperlukan untuk menggunakan modul perangkat lunak dipublikasikan kepada pengguna modul. Biasanya, ini
menyiratkan bahwa informasi yang dibutuhkan untuk dilewatkan ke modul dan informasi
dikembalikan dari modul diterbitkan. Persis bagaimana modul mengimplementasikan yang diperlukan
fungsionalitas tidak relevan. Kami benar-benar tidak peduli bagaimana objek menjalankan fungsinya,
selama fungsi terjadi. Dalam sistem berorientasi objek, menggabungkan enkapsulasi dengan
prinsip pengumpulan informasi mendukung memperlakukan objek sebagai kotak hitam.
Fakta bahwa kita dapat menggunakan objek dengan memanggil metode adalah kunci untuk reusability karena itu
melindungi cara kerja internal objek dari perubahan sistem luar, dan menjaga
sistem dari yang terpengaruh ketika perubahan dibuat ke objek. Pada Gambar 1-10, perhatikan
bagaimana pesan (create) dikirim ke objek, namun algoritma internal yang diperlukan untuk merespon
pesan tersembunyi dari bagian lain dari sistem. Satu-satunya informasi bahwa suatu objek
perlu diketahui adalah set operasi, atau metode, yang dapat dilakukan oleh objek lain dan apa
pesan perlu dikirim untuk memicu mereka.

Warisan
Inheritance, sebagai karakteristik pengembangan sistem informasi, diusulkan dalam data
Pemodelan pada akhir 1970-an dan awal 1980-an. Literatur pemodelan data menyarankan untuk menggunakan
pewarisan untuk mengidentifikasi kelas objek tingkat tinggi, atau lebih umum. Kumpulan umum dari
Atribut dan metode dapat diorganisasi ke dalam superkelas. Biasanya, kelas diatur dalam
hierarki dimana superkelas, atau kelas umum, berada di puncak dan subkelas, atau
kelas khusus, berada di bagian bawah. Pada Gambar 1-11, Orang adalah superclass untuk kelas Dokter
dan Pasien. Dokter, pada gilirannya, adalah kelas super untuk Praktisi Umum dan Spesialis. Perhatikan bagaimana
Kelas (misalnya, Dokter) dapat berfungsi sebagai kelas super dan subkelas secara bersamaan. Hubungan
antara kelas dan kelas supernya dikenal sebagai hubungan a-jenis. Sebagai contoh di
Gambar 1-11, seorang Dokter Umum adalah semacam Dokter, yang merupakan semacam orang.
Subkelas mewarisi atribut dan metode yang sesuai dari superkelas di atas
Mereka. Artinya, setiap subkelas berisi atribut dan metode dari superkelas induknya. Untuk
Contoh, Gambar 1-11 menunjukkan bahwa Dokter dan Pasien adalah subkelas Pribadi dan karenanya mewarisi
atribut dan metode dari kelas Pribadi. Warisan membuatnya lebih sederhana untuk
kelas define. Alih-alih mengulangi atribut dan metode di kelas Dokter dan Pasien
secara terpisah, atribut dan metode yang umum untuk keduanya ditempatkan di kelas Person
dan diwarisi oleh golongan-golongan yang ada di bawahnya. Perhatikan seberapa jauh lebih efektif hierarki warisan
kelas objek lebih dari objek yang sama tanpa hierarki warisan (lihat Gambar 1-12).
Sebagian besar kelas di seluruh hierarki mengarah ke contoh; setiap kelas yang memiliki contoh
disebut kelas konkret. Sebagai contoh, jika Mary Wilson dan Jim Maloney adalah contoh dari
kelas Pasien, Pasien akan dianggap kelas konkret (lihat Gambar 1-9). Beberapa
kelas tidak menghasilkan contoh karena mereka hanya digunakan sebagai template untuk yang lain,

kelas yang lebih spesifik (terutama kelas yang terletak tinggi dalam hirarki). Kelas-kelasnya adalah
disebut sebagai kelas abstrak. Orang adalah contoh dari kelas abstrak. Alih-alih membuat
objek dari Person, kita membuat contoh yang mewakili kelas Spesialis yang lebih spesifik
dan Pasien, kedua jenis Orang (lihat Gambar 1-11)

Polimorfisme dan Ikatan Dinamis

Polimorfisme berarti pesan yang sama dapat ditafsirkan secara berbeda dengan pesan yang berbeda
kelas objek. Misalnya, memasukkan pasien berarti sesuatu yang berbeda daripada memasukkan
janji temu. Oleh karena itu, potongan informasi yang berbeda perlu dikumpulkan dan disimpan.
Untungnya, kita tidak perlu khawatir tentang bagaimana sesuatu dilakukan ketika menggunakan objek.
Kita dapat dengan mudah mengirim pesan ke sebuah objek, dan objek itu akan bertanggung jawab untuk
menafsirkan pesan dengan tepat. Sebagai contoh, jika seorang seniman mengirim pesan Tarik diri ke
objek persegi, objek lingkaran, dan objek segitiga, hasilnya akan sangat berbeda, bahkan meskipun pesannya sama.
Perhatikan pada Gambar 1-13 bagaimana setiap objek merespon dengan tepat (dan berbeda) meskipun pesan
identik.Polimorfisme dimungkinkan melalui pengikatan dinamis. Ikatan dinamis, atau akhir, adalah teknik yang
menunda mengetik objek sampai waktu berjalan. Metode khusus yang sebenarnya disebut tidak dipilih oleh sistem
berorientasi objek sampai sistem berjalan. Ini adalah kontras dengan pengikatan statis. Dalam sistem yang terikat
secara statis, jenis objek ditentukan pada waktu kompilasi. Oleh karena itu, pengembang harus memilih metode
mana yang harus disebut daripada membiarkan sistem melakukannya. Inilah sebabnya mengapa kebanyakan bahasa
pemrograman tradisional memiliki logika keputusan yang rumit berdasarkan jenis objek yang berbeda dalam suatu
sistem. Sebagai contoh, dalam bahasa pemrograman tradisional, alih-alih mengirim pesan Gambar sendiri terhadap
berbagai jenis objek grafis pada Gambar 1-13, kita harus menulis logika keputusan menggunakan sebuah pernyataan
kasus atau sekumpulan pernyataan if untuk menentukan jenis apa objek grafis yang ingin kita gambar, dan kita harus
menamai setiap fungsi gambar secara berbeda (misalnya, menggambar persegi, menggambar lingkaran, atau
menggambar segitiga). Hal ini jelas membuat sistem jauh lebih rumit dan sulit untuk dimengerti.
OBJECT-ORIENTED SYSTEMS ANALYSIS AND DESIGN (OOSAD)

Pendekatan berorientasi objek untuk mengembangkan sistem informasi, secara teknis, dapat menggunakan salah
satu metodologi tradisional. Namun, pendekatan berorientasi objek yang paling terkait dengan pengembangan
bertahap RAD atau metodologi tangkas. Perbedaan utama antara pendekatan tradisional seperti desain terstruktur
dan pendekatan berorientasi objek adalah bagaimana masalah terurai. Dalam pendekatan tradisional, proses
dekomposisi masalah adalah proses-sentris atau data-sentris. Namun, proses dan data sangat erat kaitannya sehingga
sulit untuk memilih satu atau yang lain sebagai fokus utama. Berdasarkan ketidaksesuaian ini dengan kenyataan
dunia, berorientasi objek baru metodologi telah muncul yang menggunakan urutan berbasis RAD. Menurut pencipta
Unified Modeling Language (UML), Grady Booch, Ivar Jacobson, dan James Rumbaugh, Grady Booch, Ivar
Jacobson, dan James Rumbaugh, Panduan Pengguna Bahasa Pemodelan Bersatu (Membaca, MA: Addison-Wesley,
1999), pendekatan berorientasi objek modern apa pun untuk mengembangkan informasi sistem harus didorong oleh
kasus penggunaan, arsitektur-sentris, dan iteratif dan inkremental.

Use-Case Driven

Use-case driven berarti bahwa use case adalah alat pemodelan utama yang mendefinisikan perilaku sistem. Sebuah
use case menjelaskan bagaimana pengguna berinteraksi dengan sistem untuk melakukan beberapa aktivitas, seperti
melakukan pemesanan, membuat reservasi, atau mencari informasi. Kasus penggunaan digunakan untuk
mengidentifikasi dan mengkomunikasikan kebutuhan sistem kepada pemrogram yang harus menulis sistem. Use
case secara inheren sederhana karena mereka hanya fokus pada satu proses bisnis pada suatu waktu. Sebaliknya,
diagram model proses yang digunakan oleh struktur tradisional dan metodologi RAD jauh lebih kompleks karena
memerlukan analis system dan pengguna untuk mengembangkan model dari keseluruhan sistem. Dengan
metodologi tradisional, setiap system adalah didekomposisi menjadi satu set subsistem, yang, pada gilirannya,
didekomposisi menjadi subsistem lebih lanjut,dan seterusnya. Itu berlangsung sampai tidak ada proses dekomposisi
lebih lanjut yang masuk akal, dan sering kali membutuhkan lusinan halaman diagram yang saling terkait.
Sebaliknya, use case hanya berfokus pada satu proses bisnis pada satu waktu, sehingga mengembangkan model jauh
lebih sederhana.

Arsitektur-Centric

Setiap pendekatan modern untuk analisis dan desain sistem harus berpusat pada arsitektur. Arsitektur-sentris berarti
bahwa arsitektur perangkat lunak yang mendasari sistem yang berkembang spesifikasi mendorong spesifikasi,
konstruksi, dan dokumentasi sistem. Modern analisis sistem berorientasi objek dan pendekatan desain harus
mendukung setidaknya tiga pendekatan terpisah: tetapi pandangan arsitektur yang saling terkait dari suatu sistem:
fungsional, statis, dan dinamis. fungsional, atau eksternal, view menggambarkan perilaku sistem dari perspektif
pengguna. Ini struktural, atau statis, tampilan menggambarkan sistem dalam hal atribut, metode, kelas, dan
hubungan. Pandangan perilaku, atau dinamis, menggambarkan perilaku sistem dalam istilah pesan yang dikirimkan
di antara objek dan perubahan status di dalam objek.

Iteratif dan Inkremental

Analisis dan pendekatan desain sistem berorientasi objek modern menekankan iteratif dan pengembangan
inkremental yang mengalami pengujian dan penyempurnaan terus-menerus di seluruh kehidupan proyek. Ini
menyiratkan bahwa analis sistem mengembangkan pemahaman mereka tentang masalah pengguna dengan
membangun tiga tampilan arsitektur sedikit demi sedikit. Analis system melakukan ini dengan bekerja dengan
pengguna untuk membuat representasi fungsional dari sistem di bawah belajar. Selanjutnya, analis mencoba
membangun representasi struktural dari sistem yang berkembang. Menggunakan representasi struktural dari sistem,
analis mendistribusikan fungsionalitas dari sistem di atas struktur yang berkembang untuk menciptakan representasi
perilaku dari yang berkembang sistem. Sebagai seorang analis bekerja dengan pengguna dalam mengembangkan
tiga pandangan arsitektural dari: sistem yang berkembang, analis mengulangi setiap dan di antara pandangan. Yaitu,
sebagai analis lebih memahami pandangan struktural dan perilaku, analis mengungkap persyaratan yang hilang atau
misrepresentasi dalam tampilan fungsional, gilirannya dapat menyebabkan perubahan mengalir kembali melalui
pandangan struktural dan perilaku. Ketiga pemandangan arsitektural sistem tersebut saling terkait dan bergantung
satu sama lain. Karena setiap kenaikan dan iterasi selesai, representasi yang lebih lengkap dari fungsi nyata
pengguna persyaratan terungkap.

Manfaat Analisis dan Desain Sistem Berorientasi Objek

Konsep dalam pendekatan berorientasi objek memungkinkan analis untuk memecahkan sistem yang kompleks
menjadi modul yang lebih kecil dan lebih mudah dikelola, kerjakan modul satu per satu, dan potong dengan mudah
modul kembali bersama-sama untuk membentuk sistem informasi. Modularitas membuat pengembangan system
lebih mudah dipahami, lebih mudah dibagikan di antara anggota tim proyek, dan lebih mudah dikomunikasikan
kepada pengguna, yang diperlukan untuk memberikan persyaratan dan konfirmasi seberapa baik system memenuhi
persyaratan di seluruh proses pengembangan sistem. Dengan memodulasi system perkembangan, tim proyek
sebenarnya membuat bagian yang dapat digunakan kembali yang dapat dicolokkan lainnya upaya sistem atau
digunakan sebagai titik awal untuk proyek lain. Pada akhirnya, ini dapat menghemat waktu karena proyek baru tidak
harus dimulai sepenuhnya dari awal.

Unified Process

Unified Process adalah metodologi spesifik yang memetakan kapan dan bagaimana menggunakan berbagai teknik
Unified Modeling Language (UML) untuk analisis berorientasi objek. Kontributor utama adalah Grady Booch, Ivar
Jacobsen, dan James Rumbaugh. Sedangkan UML memberikan dukungan struktural untuk mengembangkan struktur
dan perilaku sistem informasi, Proses Terpadu menyediakan dukungan perilaku. Kursus, didorong oleh kasus
penggunaan, arsitektur-sentris, dan iteratif dan inkremental. Selanjutnya, Proses Terpadu adalah proses
pengembangan sistem dua dimensi yang dijelaskan oleh serangkaian fase dan alur kerja. Fase-fase tersebut adalah
inception, elaboration, construction, dan transition. Alur kerja termasuk pemodelan bisnis, persyaratan, analisis,
desain, implementasi, pengujian, penyebaran, konfigurasi dan manajemen perubahan, manajemen proyek, dan
lingkungan.
Fase

Fase-fase Proses Terpadu mendukung seorang analis dalam mengembangkan sistem informasi secara iteratif dan
bertahap. Fase menggambarkan bagaimana sistem informasi berkembang melalui waktu. Bergantung pada fase
pengembangan mana sistem yang sedang berkembang saat ini, tingkat aktivitas bervariasi di sepanjang alur kerja.
Kurva pada Gambar diatas yang terkait dengan setiap alur kerja mendekati jumlah aktivitas yang terjadi selama fase
tertentu. Misalnya, fase awal terutama melibatkan pemodelan bisnis dan alur kerja persyaratan, sementara secara
praktis mengabaikan alur kerja pengujian dan penerapan. Setiap fase mengandung satu set iterasi, dan setiap iterasi
menggunakan berbagai alur kerja untuk membuat versi tambahan dari sistem yang berkembang. Ketika sistem
berkembang melalui fase, itu meningkat dan menjadi lebih lengkap. Setiap fase memiliki tujuan, fokus aktivitas di
atas alur kerja, dan hasil tambahan. Masing-masing fase dijelaskan selanjutnya. Awal Dalam banyak hal, fase awal
sangat mirip dengan fase perencanaan pendekatan SDLC tradisional.

Elaborasi

Ketika kita biasanya berpikir tentang analisis dan desain sistem berorientasi objek, aktivitas yang terkait dengan fase
elaborasi dari Proses Terpadu adalah yang paling relevan. Alur kerja analisis dan desain adalah fokus utama selama
fase ini. Tahap elaborasi berlanjut dengan mengembangkan dokumen visi, termasuk menyelesaikan kasus bisnis,
merevisi penilaian risiko, dan menyelesaikan rencana proyek secara cukup rinci untuk memungkinkan para
pemangku kepentingan untuk dapat setuju dengan membangun sistem akhir yang sebenarnya. Ini berhubungan
dengan mengumpulkan persyaratan, membangun model struktural dan perilaku UML dari domain masalah, dan
merinci bagaimana model domain masalah cocok dengan arsitektur sistem yang berkembang. Pengembang terlibat
dengan semua kecuali alur kerja rekayasa penerapan dalam fase ini. Saat pengembang mengulangi alur kerja,
pentingnya menangani konfigurasi dan manajemen perubahan menjadi jelas. Juga, alat pengembangan yang
diperoleh selama fase awal menjadi penting untuk keberhasilan proyek selama fase ini. Hasil utama dari fase ini
termasuk struktur UML dan diagram perilaku dan versi dasar dari sistem informasi yang berkembang. Versi dasar
berfungsi sebagai dasar untuk semua iterasi selanjutnya. Dengan memberikan landasan yang kokoh pada titik ini,
para pengembang memiliki dasar untuk menyelesaikan sistem dalam fase konstruksi dan transisi.
Konstruksi

Fase konstruksi sangat berfokus pada pemrograman sistem informasi yang berkembang. Fase ini terutama berkaitan
dengan alur kerja implementasi. Namun, alur kerja persyaratan dan alur kerja analisis dan desain juga terlibat dalam
fase ini. Selama fase inilah kebutuhan yang hilang diidentifikasi dan model analisis dan desain cocok akhirnya
selesai. Biasanya, ada iterasi alur kerja selama fase ini, dan selama iterasi terakhir, alur kerja penerapan berjalan
dengan kecepatan tinggi. Alur kerja konfigurasi dan manajemen perubahan, dengan aktivitas kontrol versinya,
menjadi sangat penting selama fase konstruksi. Terkadang, sebuah iterasi harus digulung kembali. Tanpa kontrol
versi yang baik, memutar kembali ke versi sebelumnya (implementasi inkremental) dari sistem hampir tidak
mungkin. Hasil utama dari fase ini adalah implementasi sistem yang dapat dirilis untuk pengujian beta dan
penerimaan.

Transisi

Seperti fase konstruksi, fase transisi membahas aspek-aspek yang biasanya terkait dengan fase implementasi
pendekatan SDLC tradisional. Fokus utamanya adalah pada alur kerja pengujian dan penerapan. Pada dasarnya,
pemodelan bisnis, persyaratan, dan alur kerja analisis harus diselesaikan dalam iterasi awal dari sistem informasi
yang berkembang. Selanjutnya, alur kerja pengujian akan menjadi dieksekusi selama fase awal dari sistem yang
berkembang. Bergantung pada hasil dari alur kerja pengujian, beberapa aktivitas desain ulang dan pemrograman
pada alur kerja desain dan implementasi mungkin diperlukan, tetapi mereka harus minimal pada saat ini. Dari
perspektif manajerial, manajemen proyek, konfigurasi dan manajemen perubahan, dan lingkungan terlibat. Beberapa
aktivitas yang dilakukan adalah pengujian beta dan penerimaan, penyesuaian desain dan implementasi, pelatihan
pengguna, dan peluncuran produk akhir ke platform produksi. Jelas, hasil utama adalah sistem informasi yang dapat
dieksekusi yang sebenarnya. Hasil lainnya termasuk manual pengguna, rencana untuk mendukung pengguna, dan
rencana untuk meningkatkan sistem informasi di masa depan.

Alur Kerja

Alur kerja menggambarkan tugas atau aktivitas yang dilakukan pengembang untuk mengembangkan sistem
informasi dari waktu ke waktu. Alur kerja dari Proses Terpadu dikelompokkan ke dalam dua kategori besar:
rekayasa dan pendukung.

Alur Kerja Rekayasa

Alur kerja rekayasa mencakup pemodelan bisnis, persyaratan, analisis, desain, implementasi, pengujian, dan alur
kerja penerapan. Alur kerja rekayasa berhubungan dengan aktivitas yang menghasilkan produk teknis (yaitu, sistem
informasi). Alur Kerja Pemodelan Bisnis Alur kerja pemodelan bisnis mengungkap masalah dan mengidentifikasi
proyek potensial dalam organisasi pengguna. Alur kerja ini membantu manajemen dalam memahami ruang lingkup
proyek yang dapat meningkatkan efisiensi dan efektivitas organisasi pengguna. Tujuan utama dari pemodelan bisnis
adalah untuk memastikan bahwa pengembang dan organisasi pengguna memahami di mana dan bagaimana sistem
informasi yang akan dikembangkan. cocok dengan proses bisnis organisasi pengguna. Alur kerja ini terutama
dijalankan selama fase awal untuk memastikan bahwa kami mengembangkan sistem informasi yang masuk akal
secara bisnis. Kegiatan yang terjadi pada alur kerja ini paling erat kaitannya dengan fase perencanaan SDLC
tradisional; namun, pengumpulan persyaratan, dan teknik pemodelan kasus penggunaan dan proses bisnis juga
membantu kita memahami situasi bisnis.

Alur Kerja Persyaratan

Dalam Proses Terpadu alur kerja persyaratan mencakup memunculkan persyaratan fungsional dan nonfungsional.
Biasanya, persyaratan dikumpulkan dari pemangku kepentingan proyek, seperti pengguna akhir, manajer dalam
organisasi pengguna akhir, dan bahkan pelanggan. Alur kerja persyaratan paling banyak digunakan selama awal dan
elaborasi fase. Persyaratan yang diidentifikasi sangat membantu untuk mengembangkan dokumen visi dan kasus
penggunaan yang digunakan selama proses pengembangan. Persyaratan tambahan cenderung ditemukan selama
proses pengembangan. Faktanya, hanya fase transisi cenderung memiliki sedikit, jika ada, persyaratan tambahan
yang diidentifikasi.

Alur Kerja Analisis

Alur kerja analisis terutama membahas pembuatan model analisis domain masalah. Dalam Proses Terpadu, analis
mulai merancang arsitektur yang terkait dengan domain masalah; menggunakan UML, analis membuat diagram
struktural dan perilaku yang menggambarkan deskripsi kelas domain masalah dan interaksinya. Tujuan utama dari
alur kerja analisis adalah untuk memastikan bahwa pengembang dan organisasi pengguna memahami masalah yang
mendasari dan domainnya tanpa menganalisis secara berlebihan . Jika mereka tidak hati-hati, analis dapat membuat
kelumpuhan analisis, yang terjadi ketika proyek menjadi sangat macet dengan analisis sehingga sistem tidak pernah
benar-benar dirancang atau diimplementasikan. Tujuan kedua dari alur kerja analisis adalah untuk mengidentifikasi
kelas berguna yang dapat digunakan kembali untuk perpustakaan kelas. Dengan menggunakan kembali kelas yang
telah ditentukan, analis dapat menghindari reinventing roda

Alur Kerja Desain

Alur kerja desain mentransisikan model analisis ke dalam bentuk yang dapat digunakan untuk
mengimplementasikan sistem: model desain. Sedangkan alur kerja analisis terkonsentrasi tentang memahami
domain masalah, alur kerja desain berfokus pada pengembangan solusi yang akan dieksekusi secara spesifik
lingkungan. Pada dasarnya, alur kerja desain hanya meningkatkan deskripsi sistem yang berkembang dengan
menambahkan kelas yang membahas lingkungan sistem ke model analisis yang berkembang. Alur kerja desain
menggunakan aktivitas seperti desain kelas domain masalah terperinci, optimalisasi sistem informasi yang
berkembang, desain database, desain antarmuka pengguna, dan desain arsitektur fisik. Alur kerja desain dikaitkan
terutama dengan fase elaborasi dan konstruksi dari Proses Terpadu.

Alur Kerja Implementasi

Tujuan utama dari alur kerja implementasi adalah untuk membuat solusi yang dapat dieksekusi berdasarkan model
desain (yaitu, pemrograman). Ini termasuk tidak hanya menulis kelas baru tetapi juga menggabungkan kelas yang
dapat digunakan kembali dari perpustakaan kelas yang dapat dieksekusi ke dalam solusi yang berkembang. Seperti
halnya aktivitas pemrograman, kelas baru dan interaksinya dengan kelas yang dapat digunakan kembali harus diuji.
Akhirnya, dalam kasus beberapa kelompok melakukan implementasi sistem informasi, pelaksana juga harus
mengintegrasikan modul terpisah yang diuji secara individual untuk membuat versi yang dapat dieksekusi dari
sistem. Alur kerja implementasi dikaitkan terutama dengan fase elaborasi dan konstruksi.
Alur Kerja Pengujian

Tujuan utama dari alur kerja pengujian adalah untuk meningkatkan kualitas dari sistem yang berkembang. Pengujian
melampaui pengujian unit sederhana yang terkait dengan alur kerja implementasi. Dalam hal ini, pengujian juga
mencakup pengujian integrasi semua modul yang digunakan untuk mengimplementasikan sistem, pengujian
penerimaan pengguna, dan pengujian alpha yang sebenarnya. dari perangkat lunak. Secara praktis, pengujian harus
dilakukan selama pengembangan sistem; pengujian model analisis dan desain terjadi selama fase elaborasi dan
konstruksi, sedangkan pengujian implementasi dilakukan terutama selama konstruksi dan, sampai tingkat tertentu,
fase transisi. Pada dasarnya, pada akhir setiap iterasi selama pengembangan sistem informasi, beberapa jenis
pengujian harus dilakukan.

Alur Kerja Penerapan

Alur kerja penerapan paling terkait dengan transisi fase Proses Terpadu. Alur kerja penerapan mencakup aktivitas
seperti pengemasan perangkat lunak, distribusi, pemasangan, dan pengujian beta. Saat benar-benar menerapkan
sistem baru menjadi organisasi pengguna, pengembang mungkin harus mengubah data saat ini, menghubungkan
perangkat lunak baru dengan perangkat lunak yang ada, dan melatih pengguna akhir untuk menggunakan sistem
baru.

Alur Kerja Pendukung

Alur kerja pendukung mencakup manajemen proyek, manajemen konfigurasi dan perubahan, dan alur kerja
lingkungan. Alur kerja pendukung fokus pada aspek manajerial pengembangan sistem informasi.

Alur Kerja Manajemen Proyek

Alur kerja lain yang terkait dengan Proses Terpadu secara teknis aktif selama keempat fase, alur kerja manajemen
proyek adalah satu-satunya aliran kerja lintas fase yang sesungguhnya. Proses pengembangan mendukung
pengembangan inkremental dan iteratif, sehingga sistem informasi cenderung tumbuh atau berkembang dari waktu
ke waktu. Di akhir setiap iterasi, versi inkremental baru dari sistem siap ditayangkan. Alur kerja manajemen proyek
cukup penting karena kompleksitas dua dimensi model pengembangan Proses Terpadu (alur kerja dan fase). Ini
adalah aktivitas alur kerja termasuk mengidentifikasi dan mengelola risiko, mengelola ruang lingkup,
memperkirakan waktu untuk menyelesaikan setiap iterasi dan seluruh proyek, memperkirakan biaya iterasi individu
dan seluruh proyek, dan melacak kemajuan yang dibuat menuju versi akhir dari pengembangan sistem Informasi.

Alur Kerja Konfigurasi dan Manajemen Perubahan

Tujuan utama alur kerja manajemen perubahan dan konfigurasi adalah untuk melacak keadaan sistem yang
berkembang. Singkatnya, sistem informasi yang berkembang terdiri dari seperangkat artefak (misalnya, diagram,
kode sumber, dan executable). Selama proses pengembangan, artefak ini dimodifikasi. Sejumlah besar pekerjaan —
dan, karenanya, uang — terlibat dalam pengembangan artefak. Artefak itu sendiri harus ditangani seperti halnya aset
mahal apa pun akan ditangani — kontrol akses harus diterapkan untuk melindungi artefak agar tidak dicuri atau
dihancurkan. Lebih-lebih lagi, karena artefak dimodifikasi secara teratur, jika tidak berkelanjutan, mekanisme
kontrol versi yang baik harus dibuat. Akhirnya, banyak informasi manajemen proyek perlu ditangkap (misalnya,
penulis, waktu, dan lokasi setiap modifikasi). Alur kerja konfigurasi dan manajemen perubahan sebagian besar
terkait dengan fase konstruksi dan transisi.

Alur Kerja Lingkungan

Selama pengembangan sistem informasi, tim pengembangan perlu menggunakan alat dan proses. Alur kerja
lingkungan membahas ini kebutuhan. Misalnya, alat CASE yang mendukung pengembangan sistem informasi
berorientasi objek melalui UML mungkin diperlukan. Alat lain yang diperlukan termasuk lingkungan pemrograman,
alat manajemen proyek, dan alat manajemen konfigurasi. Alur kerja lingkungan melibatkan perolehan dan
pemasangan alat ini. Meskipun alur kerja ini dapat aktif selama semua fase Proses Terpadu, itu harus terlibat
terutama dengan fase awal.

Ekstensi ke Proses Terpadu

Sebesar dan serumit Proses Terpadu, banyak penulis telah menunjukkan serangkaian kelemahan kritis. Pertama,
Proses Terpadu tidak membahas kepegawaian, penganggaran, atau kontrak masalah manajemen. Kegiatan-kegiatan
ini secara eksplisit tidak termasuk dalam Proses Terpadu. Kedua, Proses Terpadu tidak membahas masalah yang
berkaitan dengan pemeliharaan, operasi, atau dukungan produk setelah dikirimkan. Jadi, ini bukan proses perangkat
lunak yang lengkap; itu hanya proses pembangunan. Ketiga, Proses Terpadu tidak membahas masalah lintas atau
antar proyek. Mempertimbangkan pentingnya penggunaan kembali dalam pengembangan sistem berorientasi objek
dan fakta bahwa di banyak organisasi karyawan bekerja pada banyak proyek yang berbeda pada saat yang sama,
mengabaikan masalah antar proyek adalah kelalaian besar. Untuk mengatasi kelalaian ini, Ambler dan Constantine
menyarankan untuk menambahkan fase produksi dan dua alur kerja: alur kerja operasi dan dukungan dan
manajemen infrastruktur. alur kerja Selain alur kerja baru ini, alur kerja pengujian, penerapan, dan lingkungan
dimodifikasi, dan alur kerja manajemen proyek serta konfigurasi dan manajemen perubahan diperluas ke fase
produksi.

Fase Produksi

Fase produksi terutama berkaitan dengan isu-isu yang berkaitan dengan produk perangkat lunak setelah berhasil
disebarkan. Fase ini berfokus pada isu-isu yang terkait dengan pembaruan, pemeliharaan, dan pengoperasian
perangkat lunak. Tidak seperti fase sebelumnya, tidak ada iterasi atau pengiriman tambahan. Jika rilis baru dari
perangkat lunak akan dikembangkan, maka pengembang harus memulai proses baru melalui empat fase pertama.
Berdasarkan aktivitas yang terjadi selama fase ini, tidak ada alur kerja rekayasa yang relevan. Alur kerja
pendukungyang aktif selama fase ini meliputi konfigurasi dan alur kerja manajemen perubahan, alur kerja
manajemen proyek, operasi baru dan alur kerja dukungan, dan alur kerja manajemen infrastruktur.

Alur Kerja Operasi dan Dukungan

Operasi dan alur kerja dukungan, seperti yang Anda duga, membahas masalah yang terkait dengan mendukung versi
perangkat lunak saat ini dan mengoperasikan perangkat lunak setiap hari. Kegiatan termasuk membuat rencana
untuk operasi dan dukungan produk perangkat lunak setelah digunakan, membuat pelatihan dan dokumentasi
pengguna, menerapkan prosedur pencadangan yang diperlukan, memantau dan mengoptimalkan kinerja perangkat
lunak. perangkat lunak, dan melakukan pemeliharaan korektif pada perangkat lunak. Alur kerja ini menjadi aktif
selama fase konstruksi; tingkat aktivitasnya meningkat sepanjang transisi dan, akhirnya, fase produksi. Alur kerja
akhirnya berhenti ketika versi perangkat lunak saat ini diganti dengan versi baru. Banyak pengembang mendapat
kesan yang salah bahwa setelah perangkat lunak dikirimkan ke pelanggan, pekerjaan mereka selesai. Dalam
kebanyakan kasus, pekerjaan mendukung produk perangkat lunak jauh lebih mahal dan memakan waktu daripada
pengembangan aslinya. Pada saat itu, pekerjaan pengembang mungkin baru saja dimulai.

Alur Kerja Manajemen Infrastruktur

Alur kerja manajemen infrastruktur tujuan utama adalah untuk mendukung pengembangan infrastruktur yang
diperlukan untuk mengembangkan objek-sistem yang berorientasi. Kegiatan seperti pengembangan dan modifikasi
perpustakaan, standar, dan model perusahaan sangat penting. Ketika pengembangan dan pemeliharaan model
arsitektur domain masalah melampaui lingkup proyek tunggal dan penggunaan kembali akan terjadi, alur kerja
manajemen infrastruktur sangat penting. Serangkaian kegiatan lintas proyek yang sangat penting lainnya adalah
peningkatan proses pengembangan perangkat lunak. Karena aktivitas pada alur kerja ini cenderung mempengaruhi
banyak proyek dan Proses Terpadu hanya berfokus pada proyek tertentu, Proses Terpadu cenderung mengabaikan
aktivitas tersebut.

Modifikasi dan Ekstensi Alur Kerja yang Ada

Selain alur kerja yang ditambahkan untuk mengatasi kekurangan yang terkandung dalam Proses Terpadu, alur kerja
yang ada harus dimodifikasi dan/atau diperluas ke fase produksi. Alur kerja ini mencakup pengujian, penerapan,
lingkungan, manajemen proyek, dan alur kerja konfigurasi dan manajemen perubahan. Alur Kerja Pengujian Untuk
sistem informasi berkualitas tinggi yang akan dikembangkan, pengujian harus: dilakukan pada setiap kiriman,
termasuk yang dibuat selama fase awal. Jika tidak, kurang dari sistem berkualitas tinggi akan dikirimkan ke
pelanggan.

Deployment Workflow

Sistem lama ada di sebagian besar perusahaan hari ini, dan sistem ini memiliki database yang terkait dengannya
yang harus diubah untuk berinteraksi dengan sistem baru. Karena kerumitan penerapan sistem baru, konversi
memerlukan perencanaan yang signifikan. Oleh karena itu, aktivitas pada alur kerja penyebaran perlu dimulai pada
fase awal daripada menunggu sampai akhir fase konstruksi, seperti yang disarankan oleh Proses Terpadu.

Alur Kerja Lingkungan

Alur kerja lingkungan perlu dimodifikasi untuk memasukkan kegiatan terkait dengan pengaturan operasi dan
lingkungan produksi. Pekerjaan aktual yang dilakukan mirip dengan pekerjaan yang terkait dengan pengaturan
lingkungan pengembangan yang dilakukan selama fase awal. Dalam hal ini, pekerjaan tambahan dilakukan selama
fase transisi.

Alur Kerja Manajemen Proyek

Meskipun alur kerja manajemen proyek tidak termasuk staf proyek, mengelola kontrak antara pelanggan dan
vendor, dan mengelola anggaran proyek, kegiatan ini sangat penting untuk keberhasilan setiap proyek
pengembangan perangkat lunak. Kami menyarankan untuk memperluas manajemen proyek untuk memasukkan
kegiatan ini. Alur kerja ini juga harus terjadi pada fase produksi untuk mengatasi masalah seperti: pelatihan,
manajemen staf, dan manajemen hubungan klien

Alur Kerja Konfigurasi dan Manajemen Perubahan

Konfigurasi dan manajemen perubahan alur kerja diperpanjang ke fase produksi baru. Kegiatan yang dilakukan
selama fase produksi termasuk mengidentifikasi potensi perbaikan pada sistem operasional dan menilai dampak
potensial dari perubahan yang diusulkan. Setelah pengembang mengidentifikasi perubahan ini dan memahami
dampaknya, mereka dapat menjadwalkan perubahan yang akan dibuat dan diterapkan dengan rilis mendatang.

Gambar diatas menunjukkan bab-bab yang mencakup fase dan alur kerja Proses Terpadu yang Disempurnakan.
Mengingat outsourcing lepas pantai dan otomatisasi teknologi informasi, dalam buku teks ini, kami fokus terutama
pada fase elaborasi dan pemodelan bisnis, persyaratan, analisis, desain, dan alur kerja manajemen proyek dari Proses
Terpadu yang Disempurnakan. Namun, seperti yang ditunjukkan Gambar diatas, fase dan alur kerja lainnya
adalahtertutupi. Di banyak lingkungan pengembangan sistem berorientasi objek saat ini, pembuatan kode didukung.
Kami, dari perspektif bisnis, kami percaya kegiatan yang terkaitdengan alur kerja ini adalah yang paling penting.

Unified Modelling Language

UML (Unified Modelling Language) adalah suatu metode dalam pemodelan secara visual yang digunakan sebagai
sarana perancangan sistem berorientasi objek.
UML juga dapat didefinisikan sebagai suatu bahasa standar visualisasi, perancangan, dan pendokumentasian sistem,
atau dikenal juga sebagai bahasa standar penulisan blueprint sebuah software. UML diharapkan mampu
mempermudah pengembangan piranti lunak (RPL) serta memenuhi semua kebutuhan pengguna dengan efektif,
lengkap, dan tepat. Hal itu termasuk faktor-faktor scalability, robustness, security, dan sebagainya.

Adapun tujuan dan fungsi perlu adanya UML yaitu sebagai berikut:
 1. Dapat memberikan bahasa pemodelan visual atau gambar kepada para pengguna dari berbagai macam
pemrograman maupun proses umum rekayasa.
2. Menyatukan informasi-informasi terbaik yang ada dalam pemodelan.
3. Memberikan suatu gambaran model atau sebagai bahasa pemodelan visual yang ekspresif dalam
pengembangan sistem.
4. Tidak hanya menggambarkan model sistem software saja, namun dapat memodelkan sistem berorientasi
objek.
5. Mempermudah pengguna untuk membaca suatu sistem.
6. Berguna sebagai blueprint, jelas ini nantinya menjelaskan informasi yang lebih detail dalam perancangan
berupa coding suatu program.

MENERAPKAN KONSEP DI PATTERSON SUPERSTORE

Kursus ini akan memperkenalkan banyak konsep baru tentang analisis dan desain berorientasi objek. Untuk
membuat konsep ini lebih relevan dan dapat dipahami, kami akan menerapkan konsep, yang diperkenalkan di setiap
bab, ke perusahaan fiktif bernama Patterson Superstore. Saat ini, Patterson menggunakan aplikasi seluler untuk
memfasilitasi pemesanan resep, pemberitahuan, dan layanan isi ulang otomatis. Layanan ini digunakan secara luas
oleh basis klien Patterson, dan Patterson telah memanfaatkan aplikasi seluler ini untuk mendapatkan keunggulan
dibandingkan pesaing yang kurang maju secara teknis.

Klien sekarang ingin menggunakan teknologi ini untuk mengakses layanan klinik kesehatan. Vice President of
Pharmacy Services, Max Ross, ingin menggunakan kesempatan ini untuk memposisikan Patterson sebagai
pemimpin dalam penggunaan penggunaan teknologi untuk akses klinik. Sistem yang ia bayangkan akan
memungkinkan komunikasi real-time dengan tenaga medis (audio, video, dan teks), penjadwalan janji temu keliling,
penilaian telehealth, dan diagnosis masalah kecil melalui panggilan rumah video