Materi 1b Kuliah IT-505 PSBO

©Ayi Purbasari, S.T., M.T. @Unpas – 2010/2011

(Rational) Unified Process-(R)UP

04/19/23 -ap- 3

Unified Process

• Unified Process adalah proses pembangunan perangkat lunak. Proses pembangunan perangkat lunak, secara umum dapat dinyatakan sebagai proses untuk mengubah kebutuhan pengguna menjadi sebuah sistem perangkat lunak.

• Proses pembangunan perangkat lunak harus mendefinisikan Siapa harus mengerjakan Apa, Kapan dan Bagaimana dalam membangun produk perangkat lunak.

• Proses yang baik haruslah dapat menjamin dihasilkannya perangkat lunak yang berkualitas baik, yaitu perangkat lunak yang memenuhi kebutuhan penggunanya, yang dihasilkan pada jadwal yang telah ditetapkan, dan dengan biaya yang telah direncanakan.

04/19/23 -ap- 4

Unified Process

• Unified Process menerapkan enam prinsip pembangunan perangkat lunak yang didefinisikan berdasarkan pendekatan pembangunan perangkat lunak yang terbukti secara komersial, yang apabila diterapkan dapat memecahkan masalah yang umum muncul dalam pembangunanperangkat lunak (best practices), yaitu:– Membangun secara iteratif– Mengelola kebutuhan (requirements)– Menggunakan component architectures– Memodelkan perangkat lunak secara visual– Melakukan verifikasi kualitas– Mengendalikan perubahan.

• diformalkan ke dalam sekumpulan prosedur detil yang lengkap

04/19/23 -ap- 5

Gambaran RUP

Business Modeling

Requirements

Analysis & Design

Workflows Inception

Elaboration

PhasesConstruction Transitio

n

Implementation

Test

DeploymentConfiguration &

Change Management

Project Management

Environment

Iterations

Initial E # 1

E # 2

C # 1

C # 2

C # n

T #1

T #2

Co

nte

nt

04/19/23 -ap- 6

RUP vs Waterfall

Risk

Transition

Inception

Elaboration

Construction

PreliminaryIteration

Architect.Iteration

Architect.Iteration

Devel. Iteration

Devel. Iteration

Devel. Iteration

TransitionIteration

TransitionIteration

Post-deployment

Waterfall

Time

04/19/23 -ap- 7

Gambaran RUP

• Proses pengembangan pada RUP dinyatakan dalam dua dimensi, atau dua sumbu – sumbu horizontal (sumbu x) merepresentasi

waktu dan menunjukkan aspek dinamis dari proses, yaitu siklus, tahap, iterasi, dan milestone.

– sumbu vertikal (sumbu y) merepresentasikan aspek statis dari proses, yaitu aktivitas, artifak, pelaksana kerja (worker) dan aliran kerja (workflow).

04/19/23 -ap- 8

Aliran Kerja RUP

• Ada dua jenis aliran kerja (workflow) pada RUP, yaitu aliran kerja utama dan aliran kerja pendukung.

• Aliran Kerja Utama:– Pemodelan bisnis (business modeling)

• Mendeskripsikan struktur dan proses-proses bisnis organisasi.

– Kebutuhan (requirements)• Mendefinisikan kebutuhan perangkat lunak dengan

menggunakan metode use case.

04/19/23 -ap- 9

Aliran Kerja RUP

– Analisis dan perancangan (analysis and design)• Mendeskripsikan berbagai arsitektur perangkat lunak

dari berbagai sudut pandang.

– Implementasi (implementation)• Menulis kode-kode program, menguji, dan

mengintegrasikan unit-unit programnya.

– Pengujian (testing)• Mendeskripsikan kasus uji, prosedur, dan alat ukur

pengujian.

– Deployment• Menangani konfigurasi sistem yang akan diserahkan.

04/19/23 -ap- 10

Aliran Kerja RUP

• Aliran Kerja Pendukung:– Manajemen konfigurasi dan perubahan

(configuration and change management)• Mengendalikan perubahan dan memelihara artifak-

artifak proyek.

– Manajemen proyek (project management)• Mendeskripsikan berbagai strategi pekerjaan dengan

proses yang berulang.

– Lingkungan (environment)• Menangani infrastruktur yang dibutuhkan untuk

mengembangkan sistem.

04/19/23 -ap- 11

Fase pada R(UP)

• Unified Process terdiri dari empat fase, yaitu:– Fase Inception– Fase Elaboration– Fase Construction– Fase Transition

• Setiap fase dapat dilaksanakan dalam satu atau lebih iterasi yang jumlahnya mungkin berbeda untuk setiap fasenya.

• Setiap iterasi menghasilkan suatu release yang semakin lama akan semakin mendekati aplikasi final.

• Release internal digunakan untuk kepentingan internal, sedangkat release eksternal diberikan kepada pihak pemesan (pengguna).

04/19/23 -ap- 12

Fase pada (R)UP

• Permulaan (inception)– Tahap inception fokus pada penentuan

manfaat perangkat lunak yang harus dihasilkan, penetapan proses-proses bisnis (business case), dan perencanaan proyek.

• Pemerincian (elaboration)– Tahap untuk menentukan use case (set of

activities) dari perangkat lunak berikut rancangan arsitekturnya.

04/19/23 -ap- 13

Fase pada (R)UP

• Konstruksi (construction)– Membangun produk perangkat lunak secara

lengkap yang siap diserahkan kepada pemakai.

• Transisi (transition)– Menyerahkan perangkat lunak kepada

pemakai, mengujinya di tempat pemakai, dan memperbaiki masalah-masalah yang muncul saat dan setelah pengujian.

04/19/23 -ap- 14

Inception – Fase untuk mendefinisikan lingkup proyek

• Pada fase ini dilakukan penjajakan apakah proyek perangkat lunak dapat dilangsungkan atau tidak.

• Pertimbangan dapat didasarkan pada faktor ekonomi.

• Pada fase ini dihasilkan gambaran perangkat lunak yang akan dibangun, yang didefinisikan sebagai lingkup proyek, dengan melakukan identifikasi actor dan use case yang paling esensial (biasanya mencapai 20% dari model yang lengkap).

• Selain itu, dibuat perencanaan bisnis yang menentukan sumberdaya yang dibutuhkan untuk proyek ini.

04/19/23 -ap- 15

Inception – Fase untuk mendefinisikan lingkup proyek

• Artifak yang dihasilkan pada fase ini adalah:– Business model.– Business case.– Daftar fitur– Use case diagram dan use case scenario tahap

awal yang telah diberi prioritas.– Deskripsi arsitektur dokumen.– Prototipe user interface.– Risk list.

04/19/23 -ap- 16

Inception – Fase untuk mendefinisikan lingkup proyek

• Prototipe yang dihasilkan pada umumnya berupa throw-away prototype, sementara deskripsi arsitektur merupakan dasar untuk aktivitas selanjutnya.

• Beberapa kesalahan yang biasa timbul pada fase inception adalah:– Memakan waktu berminggu-minggu– Adanya usaha untuk mendefinisikan seluruh kebutuhan

perangkat lunak– Estimasi dan rencana yang ada diharapkan tidak akan

berubah hingga akhir proyek– Deskripsi arsitektur perangkat lunak yang lengkap– Tidak adanya business case.– Semua use case dituliskan secara detail.– Tidak ada use case yang dituliskan secara detail.

04/19/23 -ap- 17

Inception – Fase untuk mendefinisikan lingkup proyek

• Kriteria evaluasi pada fase ini meliputi: kesepakatan stakeholder atas lingkup proyek dan perkiraan biaya dan jadwal, kemudahan pemahaman spesifikasi kebutuhan dengan munculnya use case urtama pada model, perkiraan biaya/jadwal, prioritas, resiko, dan proses pembangunan perangkat lunak yang akan digunakan, kedalaman prototipe arsitektur yang dibuat, pengeluaran nyata vs rencana pengeluaran.

04/19/23 -ap- 18

Elaboration

• Fase untuk merencanakan proyek, membuat spesifikasi kemampuan utama, dan membuat baseline architecture

• Fokus dari fase ini adalah menentukan apakah pembangunan perangkat lunak sanggup dilakukan oleh pengembang.

• Hal ini didasarkan pada gambaran arsitektur perangkat lunak yang sudah lebih detail.

• Pada tahap ini dapat dilakukan tawar menawar mengenai jadwal, jumlah pegawai, dan biaya yang akan dikeluarkan.

• Tujuan akhir yang ingin dicapai pada fase ini adalah terciptanya suatu arsitektur perangkat lunak yang telah stabil.

04/19/23 -ap- 19

Elaboration

• Artifak yang dihasilkan pada fase ini adalah:– Business model yang telah direvisi.– Use case diagram dan use case scenario yang

lengkap.– Sequence diagram.– Class diagram.– Conding standard dan naming convention.– Detailed user interface.– Skeleton code.– Preliminary user manual.– Updated risk list.

04/19/23 -ap- 20

Elaboration

• Pada tahap ini deskripsi arsitektur dititikberatkan pada paket analisis, yang belum spesifik terhadap bahasa pemrograman.

• Tetapi di sisi lain, paket desain (sudah spesifik terhadap bahasa pemrograman) juga sudah didefinisikan untuk keperluan pembangunan skeleton code awal.

04/19/23 -ap- 21

Elaboration

• Beberapa kesalahan yang mungkin timbul pada fase elaboration adalah:

1. Memakan waktu lebih dari beberapa bulan.2. Hanya terdapat satu kali iterasi3. Hampir seluruh spesifikasi kebutuhan

didefinisikan sebelum elaboration.4. Elemen dengan resiko tinggi tidak

ditangani.5. Tidak ada kode program yang dihasilkan.

04/19/23 -ap- 22

Elaboration

6. Adanya usaha untuk melakukan seluruh desain sebelum programming. Seharusnya dilakukan secara iteratif.

7. Tidak adanya keterlibatan user.8. Deskripsi arsitektur telah dianggap selesai

sebelum programming.9. Programming dilakukan hanya untuk

membuktikan bahwa hasil perancangan dapat diimplementasikan. Seharusnya kode program yang dihasilkan berupa kode program yang secara terus menerus dikembangkan hingga dihasilkan produk jadi.

04/19/23 -ap- 23

Elaboration

• Kriteria evaluasi pada fase ini meliputi:stabilitas model produk dan arsitektur, resolusi untuk resiko utama, keberterimaan (acceptance) stakeholder terhadap model produk dan rencana proyek, level pengeluaran.

04/19/23 -ap- 24

Construction

• Fase untuk membangun produk• Pada fase ini dilakukan implementasi kode

program sesuai hasil perancangan sebelumnya.

• Milestones yang terdapat pada fase ini berupa kode program yang sudah dapat menjalankan fungsi-fungsi tertentu.

• Produk perangkat lunak dibangun secara incremental dalam beberapa iterasi hingga dihasilkan beta release.

04/19/23 -ap- 25

Construction

• Artifak yang dihasilkan pada fase ini adalah:– Kode program.– Updated use case diagram and use case

scenario.– Updated class diagram.– Updated sequence diagram.– User manual untuk versi beta.

• Kriteria evaluasi pada fase ini meliputi: stabilitas dan kematangan release produk, kesiapan stakeholders untuk fase keempat, dan level pengeluaran.

04/19/23 -ap- 26

Transition

• Fase untuk masa transisi pada saat penerapan produk di lingkungan pengguna

• Pada fase ini, secara keseluruhan pembangunan perangkat lunak telah selesai.

• Fase ini diawali dengan beta release. • Pada fase ini, produk perangkat lunak akan

diserahkan kepada pengguna untuk mulai digunakan.

• Untuk mendukung operasional perangkat lunak, dapat dilakukan pelatihan untuk pengguna.

04/19/23 -ap- 27

Transition

• Artifak yang dihasilkan pada fase ini adalah:– Kode program yang telah dapat

diimplementasikan pada lingkungan pengguna.– Use case diagram, use case scenario,

sequence diagram, dan class diagram yang sesuai dengan kode program versi akhir.

– Installation wizard.– User manual.– Training material.

04/19/23 -ap- 28

Transition

• Di akhir fase ini, dibuat keputusan apakah produk akan di-release atau tidak berdasarkan level kepuasan pengguna pada fase keempat ini.

• Apabila ada kekurangan, dapat diinisiasi siklus berikutnya untuk meningkatkan kemampuan produk.

04/19/23 -ap- 29

Pelaksanaan Aktivitas Unified Process

• Bobot pekerjaan di setiap fase berbeda-beda. Berikut adalah perkiraan kasar mengenai bobot pekerjaan di setiap fase:– Fase insepsi(15%)– Fase elaborasi(35%)– Fase konstruksi(35%)– Fase Transisi(15%)

UML

04/19/23 -ap- 31

Tujuan

• Mengetahui sejarah UML• Mengetahui diagram UML dan notasi

dasarnya • Dapat menjelaskan arti dari elemen UML • Dapat menjelaskan arti dari sebuah diagram

UML• Mengetahui kapan memilih dan

menggunakan diagram UML• Dapat mengaplikasikan diagram UML pada

proyek perangkat lunak

04/19/23 -ap- 32

UML .. (1)

• Oktober 1994, ketika James Rumbaugh - OMT (Object Modeling Technique) bergabung dengan Grady Booch - the Booch Unified Method.

• Akhir 1995 Ivar Jacobson, OOSE (Object-Oriented Software Engineering)

• Draft metoda UML versi 0.8, Oktober 1995.• Juli 1996 muncul versi 0.9, versi 0.91 pada

bulan Oktober. • Juli 1997, Object Management Group

(OMG) merepresentasikan UML versi 1.0

04/19/23 -ap- 33

UML .. (2)

04/19/23 -ap- 34

UML .. (3)

04/19/23 -ap- 35

UML .. (4)

• UML: Unified Modeling Language bahasa atau alat bantu untuk menentukan, visualisasi, kontruksi dan mendokumentasikan artifacts[1] dari sistem software.

• UML:notasi diagramatik untuk pemodelan sistem yang menggunakan konsep pendekatan berorientasi objek [1] Artifact adalah sepotong informasi yang digunakan untuk dihasilkan dalam suatu proses rekayasa software. Artifact dapat berupa model, deskripsi atau software.

04/19/23 -ap- 36

UML .. (5)

• UML:bahasa standard untuk pengembangan sebuah software bagaimana membuat dan membentuk model-model, tetapi tidak menyampaikan apa dan kapan model yang seharusnya dibuat

• Bahasa model adalah sebuah bahasa yang mempunyai kosakata dan konsep tatanan/aturan penulisan serta secara fisik mempresentasikan dari sebuah sistem.

04/19/23 -ap- 37

Bahasa Pemodelan UML .. (1)

• Use Case Modeling teknik analisis kebutuhan untuk mendefinisikan aturan-aturan dan proses-proses bisnis, serta bagaimana bentuk dukungan sistem aplikasi untuk proses-proses tersebut.

• Class and Object Modeling teknik untuk memodelkan kelas-kelas dan objek-objek dari aplikasi serta arsitektur aplikasi

04/19/23 -ap- 38

Bahasa Pemodelan UML .. (2)

• Component Modeling teknik pemodelan unit-unit fisik dari kode sumber dan executable units menjadi sebuah aplikasi

• Distribution and Deployment Modeling teknik pemodelan bagaimana aplikasi dipetakan ke jaringan penyebaran terdistribusi (distributed deployment network)

04/19/23 -ap- 39

Model Konseptual UML .. (1)

• Adalah model yang mengabstraksikan komponen-komponen yang menyusun UML:

• Blok pembangun (building blocks), merupakan kosakata yang menjelaskan bagaimana semantik dan sintaks dari setiap bagian-bagian model UML. Terdapat tiga kategori, yaitu:– Benda/things adalah abstraksi yang pertama

dalam sebuah model, mencakup structural things, behavioral things, grouping things dan notational things

04/19/23 -ap- 40

Model Konseptual UML .. (2)

– Hubungan/relationship ialah sebagai alat komunikasi dari benda-benda, mencakup ketergantungan (dependency), asosiasi (association), generalisasi (generalization) dan realisasi (realization).

– Diagram sebagai kumpulan/group dari benda-benda/things, yang menggambarkan permasalahan maupun solusi dari permasalahan suatu model. Secara umum, UML mempunyai tujuh diagram, yaitu use-case, class, object, state, sequence, collaboration, component dan deployment diagram

04/19/23 -ap- 41

Model Konseptual UML .. (3)

• Aturan (rules), menunjukkan bagaimana building block dirangkai/diletakkan bersama-sama untuk membangun model. UML mempunyai aturan-aturan semantik untuk:– Nama, aturan penamaan untuk things,

hubungan antar abstraksi dan diagram– Ruang lingkup, konteks yang memberikan

arti spesifik dari sebuah nama.

04/19/23 -ap- 42

Model Konseptual UML .. (4)

– Visibility, aturan yang dapat menunjukan bagaimana nama dapat dilihat dan digunakan oleh elemen lain.

– Integritas, aturan yang menunjukkan bagaimana hubungan antar elemen yang konsisten dan tepat.

– Eksekusi, aturan yang menunjukkan apa artinya untuk menjalankan atau mensimulasikan model dinamis

04/19/23 -ap- 43

Model Konseptual UML .. (5)

• Mekanisme umum (common mechanism), mencakup:– Spesifikasi, penjelasan rinci dari suatu model atau

elemen model– Dandanan (adornment), notasi yang menyediakan

representasi visual dari aspek-aspek penting lainnya.

– Pembagian secara umum (common division), pembagian antara kelas dan objek serta pemisahan antara antarmuka dan implementasi.

– Mekanisme pengembangan (extensibility mechanism), mekanisme untuk mengembangkan model yang ada

04/19/23 -ap- 44

Diagram UML

• Diagram adalah representasi grafis dari sekumpulan elemen. Secara umum, beberapa diagram yang digunakan oleh UML adalah:

• Diagram kelas (class diagram), mengambarkan keberadaan dari kelas-kelas dan hubungannya dengan logical view dari sebuah sistem

04/19/23 -ap- 45

Class Diagram

Kelas/ObjekAtribut

Operasi/Metode()Kelas/Objek

Atribut

Operasi/Metode()Kelas/Objek

Atribut

Operasi/Metode()

04/19/23 -ap- 46

Use Case Diagram .. (1)

• Diagram use case (use case diagram), menggambarkan use case dari sistem dan aktor-aktor[1] yang terlibat [1] Aktor adalah seseorang atau sesuatu yang berorientasi dengan sistem atau yang menggunakan sistem tersebut.

• Berinteraksi dengan sistem artinya bahwa aktor mengirimkan atau menerima pesan ke atau dari sistem, atau bertukar informasi dengan sistem.

04/19/23 -ap- 47

Use Case Diagram .. (2)

• Dapat dikatakan bahwa aktor mempunyai use case, sedangkan use case menyatakan fungsi lengkap yang dimiliki oleh aktor.

• Sebuah use case harus menyampaikan sesuatu nilai ke aktor yang diinginkan dari sistem

• Diagram use case terdiri dari kumpulan graf aktor, himpunan use case yang berada di dalam batas sistem. Komunikasi antar aktor dengan use case dan generalisasi antar use case

04/19/23 -ap- 48

Use Case Diagram .. (3)

UseCase 1

(from Use Case View )

Aktor

Use Case 2

04/19/23 -ap- 49

Use Case Diagram .. (4)

Nama Elemen Notasi

Use Case

Aktor

Relasi Include<<Include>>

Relasi Extend<<Extend>>

NamaUse Case

04/19/23 -ap- 50

Collaboration Diagram .. (1)

• Diagram kolaborasi (collaboration diagram), digunakan untuk menyatakan skenario yang memperlihatkan pesan yang mengalir di dalam diagram objek. Pesan yang mengalir tersebut mungkin merupakan pemanggilan prosedur atau asynchronous link

04/19/23 -ap- 51

Collaboration Diagram .. (2)

: Aktor

Objek 1 Objek 2

Objek 3 :kelas

1: event 2: operasi ke-1

3: operasi ke-2 (parameter list)

4: operasi ke-3 (parameter list) 5: operasi ke-4 (parameter list)

04/19/23 -ap- 52

Sequence Diagram .. (1)

• Diagram sekuen (Sequence diagram), menunjukkan kerja sama yang dinamis antar objek, aspek terpenting dalam diagram ini adalah untuk menunjukan deretan pesan yang dikirimkan diantara objek ha1 ini juga menunjukan interaksi antar objek

04/19/23 -ap- 53

Sequence Diagram .. (2)

: Aktor

Objek 1 Objek 2 Objek 3

proses ke-1

proses ke-2

proses ke-3

04/19/23 -ap- 54

Statechart Diagram .. (1)

• Diagram statechart ( Statechart diagram), menggambarkan state space dari konteks yang diberikan, kejadian yang menyebabkan transisi dari state satu ke lainnya, dan aksi yang dihasilkan

04/19/23 -ap- 55

Statechart Diagram .. (2)

NewStateState 1 State 2

State 3stop

04/19/23 -ap- 56

Component Diagram .. (1)

• Diagram komponen (component diagram), menunjukan kode dalam hubungannya dengan komponen kode. – Sebuah komponen dapat menjadi sumber kode

komponen, dapat berupa komponen binary ataupun komponen executable.

– Sebuah komponen mengandung informasi tentang logical class yag diimplementasikan.

– Jadi diagram komponen adalah pemetaan dari logical view ke component view, ketergantungan antara komponen dapat ditunjukan, sehingga akan membuat lebih mudah untuk menganalisa dalam sebuah komponen

04/19/23 -ap- 57

Component Diagram .. (2)

komponen 1

komponen 2

04/19/23 -ap- 58

Deployment Diagram .. (1)

• Deployment diagram, menunjukan arsitektur dari perangkat keras dan perangkat lunak dalam sistem serta deployment view yang menggambarkan arsitektur fisik aktual dari sebuah sistem.

04/19/23 -ap- 59

Deployment Diagram .. (2)

node 1 node 2

link name