pray fo anapersis (rangkuman+kisi2)

5/11/2018 Pray Fo Anapersis (Rangkuman+Kisi2) - slidepdf.com

http://slidepdf.com/reader/full/pray-fo-anapersis-rangkumankisi2 1/31

The Requirements Discipline

Requirement Discipline membicarakan tentang pembuatan model dan lebih terpusat pada

fase elaborasi.

Requirement Discipline Lebih Detail

Dalam Requirement Discipline fokusnya pada detail internal system, dari apa objektif bisnis

menjadi bagaimana objektif dapat tercapai. Dalam Requirement Discipline, analis

mendefinisikan detail dari system informasi yang dibutuhkan untuk memberikan organisasi

keuntungan yang diharapkan. Berikut adalah prosesnya :

A. Mengumpulkan detil informasi

Sistem analis memperoleh informasi dari orang yang akan menggunakan system baik dari

interview atau memperhatikan mereka bekerja. Mereka dapat memperoleh informasi dengan

review dokumen perencanaan dan kebijakan. Analis harus berbicara dengan semuanya,

pengguna system dan penggunan system serupa. Analis juga harus mengoleksi infomasi

teknis seperti penggunaan computer, tempat kerja, interface system, dan software yang

digunakan.

B. Mendefinisikan Persyaratan

Setelah semua informasi dikumpulkan, penting untuk mencatatnya.Kebanyakan dari infomasi

menjelaskan persyaratan fungsional, beberapa menjelaskan persyaratan non-

fungsional.Permodelan berlanjut ketika informasi sedang dikumpulkan.Spesifik model

dibangun berdasarkan dari system yang dikembangkan.UP menyediakan beberapa

kemungkinan tipe model tapi analis tidak butuh menggunakan semuanya.Analis memilih

model yang cocok dengan projek dan skill nya.

C. Memprioritaskan Persyaratan



Setelah persyaratan telah dimengerti dan detail model dari persyaratan telah selesai, penting

untuk mengetahui persyaratan mana yang krusial untuk system. Kenapa harus diprioritaskan

fungsi yang diminta oleh user?Karena sumber daya selalu terbatas. Jika analis tidak berhati-

hati dalam evaluasi prioritas, kebutuhan system akan terus bertambah dengan adanya

pengguna yang meminta (scope creep) menyebabkan biaya lebih mahal dan keterlambatanimplementasi.

D. Mengembangkan Dialog User Interface

Dalam banyak kasus banyak pengguna yang cenderung tidak pasti dalam persyaratan

system. Dengan adanya dialog interface pengguna dapat melihat system dan merasakanya.

Dialog interface merupakan model yang memunculkan dan memvalidasi kebutuhan interface.

Dialog interface bisa berupa storyboard atau prototype.

E. Evaluasi Persyaratan dengan Pengguna

Analis biasanya menggunakan proses berulang dimana mereka memperoleh input pengguna,

bekerja sendiri untuk memodelkan persyaratan, kembali ke pengguna untuk ditambahkaninput atau validasi, kemudian bekerja sendiri lagi untuk menambahkan dan memperhalus

model. Banyak alternative yang ada untuk design terakhir dan implementasi system. Model

alternative terus dikembangkan dan diperbaiki terus menerus.

Persyaratan Sistem

Persyaratan system adalah spesifikasi yang mendefinisikan fungsi yang akan diberikan

system, menyangkut semua kemampuan dan kendala yang terjadi dalam system. Persyaratan

system dibagi menjadi 2 :

A. Persyaratan fungsional

Persyaratan system yang mendeskripsikan sebuah aktivitas atau proses dari kerja system.

Berhubungan langsung dengan use case dan disajikan dalam model grafis dan teks.



B. Persyaratan non-fungsional

Persyaratan system selain dari yang harus dijalankan, sebagai support. Banyak jenis dari

persyaratan non fungsional :

- Persayaratan teknis

- Persyaratan tampilan

- Persyaratan kegunaan

- Persyaratan andalan

- Persyaratan keamanan

Model dan Permodelan

Model adalah representasi dari beberapa aspek system yang sedang dibangun.Model adalah

komunikator yang baik untuk menyampaikan informasi serta mengurangi kerumitan.Model

dikonfigurasi dalam hirerarki. UML diagram aktivitas salah satu model.

A. Tujuan Model

Proses membuat model membantu analis tuntuk mengklarifikasi dan memperjelas

persyaratan dan detail design.Membuat model juga pentinåg karena disebabkan kompleksitas

dalam mendeskribsikan system informasi. Model membantu menyederhanakan kesalahan

analis dan focus pada beberapa aspek system. Model membantu mengingatkan analis detail

kerja sebelumnya yang sudah selesai.Model juga membantu komunikasi dengan pengguna

dan perkembangan dalam mengerti.

Berikut adalah beberapa alasan untuk membuat model :

1. Belajar dari proses permodelan

2. Mengurangi kompleksitas

3. Mengingat semua detail



4. Komunikasi dengan member tim pengembangan lainnya

5. Komunikasi dengan berbagai pengguna

6. Dokumentasi yang telah dipakai oleh perawatan ke depannya

B. Tipe-tipe model

Analis menggunakan berbagai macam tipe model yang berbeda dalam mengembangkan

sistem.Tipe model yang digunakan bergantung daripada informasi yang diwakili. Ada 3 tipe

model :

- Model Matematis

Sebuah seri dari formula yang mendeskribsikan aspek teknis dari sistem.Dapat berupa

rumus atau catatan matematis seperti persamaan dan fungsi respon waktu.

- Model Deskriptif

Catatan naratif, laporan atau daftar yang mendeskribsikan aspek dari sistem. Analis

dapat interview beberapa pengguna untuk menulis proses sistem dalam bentuk

naratif. Banyak model sistem informasi mengandung daftar-daftar seperti fitur, input,

output, kejadian, dan pengguna.

- Model Grafis

Diagramdan representasiskematikbeberapa aspekdari suatu sistem. Mungkin

meupakan model yang paling berguna untuk analis.Model grafis mudah dimengerti

hubungan yang kompleks yang susah diungkapkan secara verbal. UML menyediakan

diagram standard untuk permodelan berorientasi objek.



UML Diagrams used for Modeling

Teknik Pengumpulan Informasi

A. Tema Pertanyaan

Pertanyaan seputar 3 dibawah ini :

1. Apa itu proses bisnis?



2. Bagaimana proses bisnis dilakukan?

3. Informasi apa saja yang dibutuhkan?

B. Review dari Laporan, Form, dan Deskripsi Prosedur

Ada 2 sumber informasi untuk prosedur dan form yang ada. Satu dari external organisasi

sedangkan satunya lagi dari laporan, form, dan prosedur dalam dokumen bisnis dan

prosedurdalam organisasi. Untuk memulai proses, analis meminta pengguna untuk

menyediakan salinan dari form dan laporan yang sedang digunakan. Mereka juga meminta

salinan dari prosedur manual dan deskripsi kerja.

C. Melakukan Interview dan Diskusi dengan Pengguna

Merupakan salah satu teknik paling efektif untuk mengerti fungsi dan aturan bisnis. Agar

interview berjalan efektif maka analis harus mengorganisasi 3 area : (1) Menyiapkan

interview, (2) Melakukan interview, dan (3) Follow Up interview.

D. Mengamati Dan Mendokumentasikan Proses Bisnis

Selain interview, metode yang tidak kalah efektif adalah observasi pengguna langsung dan

mendokumentasikan prosesnya. Caranya adalah : (1) Observasi dan (2) Dokumentasi dengan

diagram aktivitas, contoh

E. Membangun Prototipe



Prototipe adalah awal, model kerja dengan entitas lebih kompleks. Ada beberapa macam

prototype : throwaway prototype, discovery prototype, design prototype, dan evolving

prototype. Karakteristik dari prototype yang efektif adalah operative, cepat, dan fokus.

F. Mendistribusikan dan Mengoleksi Kuesioner

G. Melakukan Design Aplikasi Bersama

USE CASE

Events And Use Cases

Use case adalah sebuah aktivitas sistem, biasanya di respon dari permintaan dari pengguna.

Dalam fase inception suatu proyek, analis identifikasi banyak kunci use cases. Use case

adalah titik awal dalam proses permodelan.



Ada beberapa cara untuk mengidentifikasi use case. Yang pertama adalah mendaftar semua

pengguna dan berpikir apa yang mereka butuhkan dalam sistem untuk pekerjaan mereka.

Pendekatan lainnya adalah memulai dari sistem yang sudah ada dan mendaftar semua fungsi

sistem yang sedang berjalan kemudian menambah fungsi baru yang diminta pengguna.

Pendekatan ketiga adalah berbicara dengan semua pengguna untuk mendeskripsikan tujuanmereka dengan sistem itu

Dasar proses bisnis (EBPs) adalah tugas yang dijalankan oleh satu orang dalam satu tempat,

dalam respon kejadian bisnis, yang menambahkan ukuran nilai bisnis dan meninggalkan

sistem dan data dalam kondisi konsisten

Event Decomposition

Event adalah sebuah kejadian yang terjadi pada waktu dan tempat yang spesifik kemudian

dapat dijelaskan dan berharga untuk diingat.

Event decomposition adalah teknik yang digunakan analis untuk identifikasi use case dengan

fokus dahulu pada event sebuah sistem yang harus direspon dan melihat bagaimana sistem

itu merespon. Analis didelegasikan peristiwa tertentu untuk menguraikan. Hasil dari event

decomposition : daftar dari use case dipicu dari event bisnis dan use case yang benar.

Events Affecting a Charge Account Processing System that

Lead to Use Cases

Tipe-tipe Event

Ada 3 macam tipe event :

1. External Events : Sebuah event yang terjadi di luar sistem, biasanya dilakukan oleh

external agen atau actor.

Yang termasuk external event :

- Agen luar ingin sebuah hasil dalam sebuah transaksi

- Agen luar ingin beberapa informasi



- Pertukaran data harus diubah

- Manajemen butuh informasi

2. Temporal event : Event yang terjadi dalam suatu waktu yang telah ditentukan.

Yang termasuk temporal event :

- Output internal dibutuhkan.Contoh : Laporan manajemen, Laporan operasional,

Pernyataan internal dan dokumen.

- External output dibutuhkan. Contoh : Pernyataan, Laporan status, Bills, Pengingat

3. State event : Event yang terjadi ketika sesuatu terjadi didalam sistem yang memicu

kebutuhan untuk memproses.

Identifying Events

1. Event Versus Kondisi Sebelumnya dan Respon

Membedakan event dari kondisi

2. Urutan Dari Event : Membuat Siklus Hidup Transaksi

Melacak urutan kejadian diprakarsai oleh agen eksternalMengisolasi peristiwa yang benar-benar menyentuh sistem

3. Kontrol Event dan Sistem yang Bergantung Pada Teknologi

Melihat Setiap Event Dan Menghasilkan Usecase

- Masukkan use case dalam event table- Event table ada baris dan kolom

o Setiap baris adalah catatan menghubungkan ke sebuah use caseo Kolom merepresentasikan informasi kunci

- Tabel acara RMO anatomizes sistem dukungan pelanggan



Information about each Event and the Resulting Use Case in an Event Table

Use Cases dan Aktor

Source :

Orang atau benda yang melakukan business event dan harus berada diluar sistem.

Actor :

Orang atau benda yang bersentuhan dengan sistem dan berada diluar batas automatisasi.

Mengidentifikasi aktor pada level detail yang benar:

- Asumsi aktor memiliki tangan.

- Use case adalah goal yang ingin dicapai oleh actor.

Diagram Use Case

Notasi untuk use case diagram: figur simple tongkat mewakili sebuah actor, tangan-tangan

actor langsung indikasi akses sistem, use case disimbolkan dengan sebuah oval,menghubungkan garis yang cocok antara actors dan use cases.



Ikatan Otomatis dan Organisasi

- Memperluas use case diagrams dengan actor lain dan use case.

- Garis penghubung: menghubungkan tiap aktor untuk berinteraksi dengan tiap use

case.

- Automatisasi batas

o Garis digambar disekitar set use case.

o Mendefinisikan interfaces antara actors dan sistem komputer.



Figure - A Use Case Diagram of the Order-Entry Subsystem for RMO, Showing a

System Boundary

Deskripsi Detail Use Case

1. Brief Description.Ringkasan yang digabungkan dengan activity diagram.

2. Intermediate Description.

Memperluas brief description dengan aliran aktivitas-aktivitas internal.

3. Fully Develop Ddescription.

Memperluas intermediate description untuk tampilan yang lebih kaya.

Identifikasi Perilaku Objek – Diagram Statechart

Pengenalan

Kadang dalam sistem computer penting untuk menjaga informasi tentang status dari

domain objek.Status kondisi dapat dijelaskan dalam statchart sebagai keadaan yang

berbeda-beda dalam sebuah objek.Statechart dapat dibuat untuk kelas domain yang

bermasalah yang mempunyai behavior kompleks atau status kondisi yang harus dicari.

Sebuah statechart diagram terbuat dari oval yang menggambarkan status dari objekdan

panah yang menggambarkan transisi.

Contoh statechart :

- Pseudostate = Titik hitam sebagai tanda

permulaan statechart.



- State = Kondisi ketika sebuah objek memenuhi sebuah criteria, melakukan aksi,

menunggu sebuah event.

- Transisi = Pergerakan objek dari satu state ke state lainnya.

- Destination State = State dimana objek bergerak menuju ketika transisi.

- Origin State = State asal dari sebuah objek.

- Message event = Pemicu transisi yang menyebabkan sebuah objek meninggalkan state

aslinya.

- Guard condition = Sebuah tes benar/salah agar transisi dapat berjalan.

- Action expression = Sebuah deskripsi aktivitas untuk dijalankan.

Nested States Dan Konkurensi

Kondisi untuk berada lebih dari satu state pada satu waktu disebut konkurensi atau

keadaan konkurensi. Satu cara intik menunjukan ini adalah dengan menggunakan

synchronization bar dan konkuren path, seperti pada diagram aktivitas. Path adalah set

yang berurutan dari state dan transisi yang berhubungan. Cara lain unutk menunjukan

state konkuren adalah dengan menggunakan nested state didalam lainnya, state lebih

tinggi. State yang levelnya lebih tinggi disebut composite state. Contoh :

Composite state dapat menunjukkan abstraksi level lebih tinggi dan dapat memuat

nested state dan transisi. Sebagai contoh, dalam state printer kita ingin

mengidentifikasi state on. Tapi ketika printer menyala, bisa idle atau bekerja. Untuk

menunjukkan 2 state itu, kita menggambarkan statechart level rendah didalam state



On. Persegi untuk state on dibagi menjadi dua. Bagian atas mengandung nama dan

bagian bawah mengandung nested states dan transition paths.

Contoh concurrent path untuk state on:

Dalam contoh ini ada dua

concurrent paths dalam

composite state.Bagian atas

menunjukkan bagian paper tray dari printer. Dua path berdiri sendiri saling lepas dan

printer berjalan melalui state dan transisi dalam setiap path sendiri. Ketika tombol off

ditekanm maka printer meninggalkan state on.

Aturan Untuk Membuat Statechart

Membuat statechart mengikuti beberapa aturan. Berikut adalah langkah yang akan

membantu dalam mebuat statechart :

1. Pilihkelas yangakan membutuhkanstatecharts

Biasanya kita hanya memasukan berbagai status kondisi yang penting dalam

sistem.Kemudian mulai dengan kelas yang paling simple.

2. Daftarsemua kondisistatusuntuk setiap kelompok

Dalam point ini, mudahnya melakukan brainstorm. Jika bekerja dengan kelompok,

lakukan brainstorm dengan semua anggota tim.

3. Menentukantransisiyang menyebabkanobjekuntuk meninggalkanstatediidentifikasi

Contoh, jika sebuah order dalam state siap di kirim, lalu ada transisi seperti

memulai pengiriman akan menyebabkan order untuk meninggalkan state.



4. Urutkanstatetransisikombinasi dalamurutan yang benar

Kemudian agregasi kombinasi mereka dalam fragmen lebih besar.

5. Identifikasiconcurrent paths

Ketika item dapat berada dalam dua state bersamaan, ada dua kemungkinan.Dua

kemungkinan dapat berdiri sendiri, spergi dalam printer bekerja dan penuh.

6. Mencaritransisitambahan

Sering dalam iterasi pertama, beberapa kombinasi dari state-transisi-state hilang.

Satu method untuk identifikasi mereka adalah mengambil setiap kombinasi dari

state dan menanyakan apakah ada transisi yang valid antar state/

7. Perbanyaksetiap transisiyang sesuai

Masukkan setiap state action expression.Banyak dari inimungkin telahdilakukan

sebagaifragmenStatechart yangsedangdibangun

8. Review danpengujianStatechartmasing-masing

Review setiap statechart dengan melakukan hal sbb :

1. Pastikan state benar-benar state dari objek di kelas.

2. Ikuti siklus hidup objek dari datang keberadaan sampai dihapus dari sistem.

3. Pastikan diagram mengcover semua kondisi pengecualian serta alur normal dari

behavior.

4. Lihat lagi tentang kejadian bersama dan kemungkinan nested paths.

Membuat Statechart RMO

Langkah pertamaa adalah mereview domain class diagram dan memilih kelas yang

mempunyai kondisi status yang harus dilacak. Dalam kasus ini kita memilih Order dan

detail order. Kandidat kelas lainnya adalah InventoryItem, Shipment, Customer.



Membuat Statechart Detail Order

Mengidentifikasikondisi statusyang mungkin :

"Siap untuk dikirim”

"Pada urutan belakang"

"Dikirimkan"

Terus mengembangkanStatechartsesuai dengandelapan aturan

Membuat Statechart Order

States mencerminkan siklus hidup dari order.

Penerapanaturanmengarah kekompleksitas yang lebih besar: States bersama dan

Transisi baru.

ManfaatmengembangkanStatechartuntuk suatu benda :

- Menangkap danmemperjelasaturan bisnis

- Keuntunganpemahaman yang benar tentangpersyaratan sistem



Masalah Domain Kelas

Tipe-tipe Things

Things mempunyai representasi data dalam sistem. Things adalah objek yang

berinteraksi dengan sistem. Analis dapat menanyakan beberapa tipe things untuk

mengidentifikasi mereka.Banyak things yang terlihat lebih mudah diidentifikasi tapi

beberapa tidak terlihat, harus dipisahkan. Tipe things yang beda penting untuk

pengguna yang beda juga, jadi penting untuk mengambil inormasi dari semuapengguna.

Analis mengidentifikasikan tipe-tipe things ini dengan memikirkan setiap kejadian

dalam tabel kejadian dan menanyakan pertanyaan.

Prosedur Untuk Menemukan Daftar Awal Things



Analis dapat menggunakan banyak sumber informasi untuk menemukan daftar awal

things yang sistem butuhkan untuk menyimpan informasi.Prosedurnya adalah dimulai

dengan mencatat semua benda yang pengguna sebutkan ketika berbicara tentang

sistem.Kemudia tambahkan benda tambahan ke dalam daftar yang muncul dalam

informasi tentang sistem yang ada atau yang muncul ketika berbicara dengan

stakeholder.

Langkah pertama.Identifikasi semua benda dari tabel kejadian dan informasi dari

setiap kejadian.

Langkah kedua. Menggunakan informasi lain dari sistem yang ada, prosedur sekarang,

dan laporan atau form sekarang tambahkakan benda atau informasi yang dibutuhkan.

Langkah ketiga.Memperhalus daftar dan mencatat asumsi atau isu untuk menjelajah.

Asosiasi Antara Things

Setelah mencatat dan memperhalus daftar things, analis meneliti dan mencatat

informasi tambahan.Banyak hubungan penting antara things penting untuk

sistem.Asosiasi adalah relasi yang terjadi antara things secara spesifik.Contoh :

“ditempatkan pada” dan “bekerja di.” Asosiasi berlaku pada 2 arah.Contoh :

“Pelanggan menempatkan pesanan” dan “Pesanan ditempatkan oleh pelanggan.”

Jumlah dari asosiasi yang terjadi disebut multiplicity. Multiplicity dibuat untuk setiap

arah dari asosiasi. Asosiasi dilakukan dengan beberapa things dibedakan menjadi

beberapa : Unary (antara things yang sejenis), binary (antara 2 things yang berbeda),

ternary (3 things yang berbeda), dan n-ary (antara n (jumlah things) yang berbeda).

Atribut Dari Things

Kebanyakan dari informasi sistem menyimpan dan menggunakan potongan spesifik

dari setiap informasi dari setiap things.Potongan spesifik informasi disebut

atribut.Analis harus mengidentifikasi atribut dari things. Atribut yang secara unik

mengidentifikasi things disebut indentifier (key) sedangkan atribut yang mengandung

beberapa koleksi berhubungan dengan atribut yang sama disebut compound atribut.

Analis mungkin memulai mendeskripsikan atribut yang paling penting tapi nanti pada

akhirnya semua ditambahkan ke daftar.



Kelas dan Objek

Object adalah suatu entitas yang memiliki identitas, state, dan behavior sedangkan

Class adalah kumpulan dari object yang mempunyai structure, behavioral pattern, dan

attributes yang bersamaan. Model domain kelas diagram adalah UML kelas diagram

yang menunjukan things yang penting dalam pekerjaan pengguna, masalah domain

kelas, asosiasi dan atribut mereka.

Things dalam pekerjaan pengguna juga harus direpresentasikan dalam sistem, jadi

yang harus dipikirkan adalah things sebagai software yang berinteraksi dengan

sistem.Objek dalam pekerjaan pengguna seringkali mirip dengan objek

software.Perbedaan utamanya adalah objek software bekerja dalam sistem, mereka

tidak hanya menyimpan informasi. Dengan kata lain objek software juga mempunyai

kelakuan begitu juga dengan atribut. Objek meng enkapsulasi atribut dan

kelakuannya.

Kelas Diagram

Domain Model Notasi Kelas Diagram

Dalam kelas diagram, persegi panjang melambangkan kelas, dan garis yang

menghubungkan persegi panjang menunjukkan asosiasi antara kelas. Persegi panjang

dibagi menjadi 3 bagian, masing-masing merupakan nama, atribut, dan fungsi kelas.

Fungsi tidak terdapat domain model kelas diagram.



Sebagai contoh dari gambar diatas kita dapat melihat 3 model domain kelas yang

saling berhubungan. Dalam notasi diagram antara customer dengan order, kita dapat

mlihat customer dapat membuat banyak oder sedangkan setiap order hanya bisa

dibuat oleh satu customer. Multiplicitynya adalah one to many dan one to one di arah

lainnya.

Kemudian di paling kanan terdapat Order item (detail order), setiap pemesanan

mempunyai minimum 1 barang yang dipesan dan maksimum banyak barang.

Hierarki dalam Notasi Kelas Diagram

Hierarki Generalisasi dan Spesialisasi

Generalisasi/spesialisasi berdasarkan kesamaan dan perbedaan orang mengklasifikasi

benda.Generalisasi adalah menentukan grup dari things yang sejenis, contohnya

banyak macam kendaraan bermotor seperti mobil, motor, truk dll.Maka dari itu

kendaraan bermotor adalah kelas general.Spesialisasi adalah penilaian yang membeda-

bedakan tipe dari things.Contoh : mobil balap, sedan, adalah spesialisasi dari kelas

mobil.

Generalisasi/spesialisasi digunakan untuk struktur atau peringkat things dari umum ke

lebih special.Kelas yang lebih umum disebut superclass, sedangkan kelas yang lebih

spesial disebut subclass.



UML kelas diagram untuk superclass dan subclass adalah segitiga kecil pada garus

yang menunjuk pada superclass. Inheritance (penurunan sifat) membuat subclass

mendapat karakteristik superclass.

Hierarki Semua - Sebagian

Whole – part menangkap semua hubungan yang diidentifikasikan ketika orangmencoba membuat asosiasi antara objek dan komponennya. Whole adalah jumlah

(kumpulan) dari bagian-bagian. Ada 2 tipe dalam hierarki whole-part: agregasi dan

komposisi. Agregasi adalah asosiasi antara objek dengan bagian yang dapat

dipisahkan, contoh : keyboard adalah bagian dari computer. Komposisi adalah

hubungan bagian yang tidak dapat dipisahkan dari objek.Contoh : CRT dan monitor.

Mencari Pola Untuk Pattern

Pola memberikan sumber inspirasi dan patokan untuk bagaimana memodel situasi

Pola umum :

– Role pattern: object dengan multiple roles

– Relation pattern: relationship dengan attributes

– Hierarchy pattern:

– Item-descriptor pattern:



Kisi-kisi :

1. Jelaskan tahapan unified process!

2. Jelaskan 3 macam model yang dapat digunakan untuk menganalisis sistem informasi!

3. Apa perbedaan source dan actor?

4. Jelaskan notasi yang digunakan dalam membuat class dan class diagram.

5. Apakah perbedaan antara class dan object?

6. Berikan contoh penggunaan include dan extends dalam usecase diagram!

7. Apakah kegunaan dari usecase diagram?

8. Jelaskan mengenai compound attribute dalam class.

9. Bagaimana cara membuat statechart?

10. Apa saja aktivitas yang dilakukan sistem analis selama dalam requirement analys?



11. Jelaskan teknik yang dapat digunakan untuk mengumpulkan informasi kebutuhan user /

identifikasi user requirement!

12. Sebutkan cara-cara untuk menentukan sebuah class

13. Jelaskan notasi yang digunakan dalam membuat statechart diagram.

14. Jelaskan 4 macam explore pattern yang digunakan dalam domain model class diagram!

15. Jelaskan notasi yang digunakan dalam membuat activity diagram.

16. Jelaskan yang ada ketahui tentang FACTOR dalam menentukan system definition!

17. Jelaskan Struktur Relationship yang dapat digunakan dalam membuat domain model class

diagram

18. Jelaskan 3 macam usecase description menurut Satzinger beserta contoh!

19. Jelaskan apakah yang anda ketahui tentang event table.

20. Jelaskan macam-macam event description menurut Satzinger beserta contoh!

Kasus :

Customer yang datang akan didata dan dilayani oleh customer service BBCare Center .

Setelah customer terdaftar, customer dapat langsung mengutarakan keluhannya seputar

kerusakan smartphone tersebut.Customer service BB Care Center akan langsung mengecek

kondisi smartphone . Setelah dicek, customer service akan mencatat setiap keluhan tersebut

dalam nota perbaikan. Berdasarkan keluhan tersebut, pihak customer service dapat

memberikan estimasi biaya yang dibutuhkan untuk melakukan service tersebut.Customer akan

diberikan garansi pasca service selama tiga bulan. Setelah customer menyetujui untuk

melakukan service ,maka customer service BB Care Center akan mencetak nota perbaikansebanyak 3 (tiga) rangkap, di mana rangkap 1 (satu) akan diberikan kepada customer ,

rangkap 2 (dua) akan diberikan kepada kepala teknisi, dan rangkap 3 (tiga) akan diarsip.

Berdasarkan nota perbaikan tersebut, kepala teknisi akan membuatkan Surat Perintah Kerja.

Pada Surat Perintah Kerja ini akan dicatat perintah perbaikan smartphone , beserta kode

teknisi yang diperintahkan untuk memperbaiki smartphone tersebut. Setelah Surat Perintah

Kerja ini selesai dibuat, maka pihak teknisi BB Care Center akan langsung memperbaiki

smartphone tersebut berdasarkan Surat Perintah Kerja. Setelah perbaikan selesai dilakukan,



maka pihak teknisi akan membuat surat pengerjaan service . Pada surat pengerjaan service ini

akan dicatat sparepart apa saja yang dibutuhkan untuk memperbaiki smartphone tersebut.

Setelah smartphone selesai diperbaiki, maka pihak customer service BB Care Center akan

menghubungi customer . Customer membayar biaya service kepada kasir berdasarkan surat

pengerjaan service yang telah dilakukan tersebut, kemudian akan dicetak bukti pembayaran

service .

1. Please explain what are the activities in Unified Process ! What‟s the benefit of Unified

Process

2. What are three types of models according to Satzinger ?

3. List and describe information-gathering techniques for identifying user requirements !

4. There are three types of use case description. Fully developed use case description is one

of them. Please explain each point on fully developed use case description !

5. What is the purpose of an activity diagram ?

6. What is the <<includes>> and <<extends>> relationship used for? Give example!

7. Please explain three types of events according to Satzinger!

8. What is the difference between „source‟ and „actor‟?-



9. You have set up an interview with Jason Nadold in the shipping department . Your

objective is to determine how shipping works and what the information requirements for the

new system will be. Make a list of questions, open-ended and close-ended, that you would

use!

10.Develop an activity diagram based on the following system definition. If you need to make

assumptions, also note them!The shipping department receives all shipments on outstanding

purchase orders. When the clerk in the shipping department receives a shipment, he finds the

outstanding purchase order for those items. The clerk then sends multiple copies of the

shipment packing slip. One copy goes to purchasing and the department updates its records

to indicate that the purchase order has been fulfilled. Another copy goes to accounting so

that a payment can be made. A third copy goes to the requesting in-house customer so that

he can receive the shipment. Once payment is made, the accounting department sends a

notification to purchasing. Once the customer receives and accepts the goods, he or she

sends notification to purchasing. When purchasing receives these other verifications, it closes

the purchase order as fulfilled and paid.

11. Make an event table and draw use case diagram from auction house information

system below! Choose 1 (one) usecase from your usecase diagram and make „fully

developed use case description‟ from that usecase ! You may make any assumptions andplease write it on your answer sheet!

The auction house has selling customers, who want to put up an item for sale, and

buying customers, who buy an item at an auction. Selling customers ask the auction house to

sell an item on their behalf. The auction house decides whether to accept the request and

maintains a record for all accepted requests. Buying customers register with the auction

house and participate in auctions. Auctions are conducted by giving buying customers

information about an item, then taking bids. The auction determines a buying customer for

each item put up for sale. The sale is completed when the buying customer pays for the item.

The auction house sends a portion of the sale income to the selling customer who put up the

item for sale in the first place. Of course, the auction house keeps track of all auctions (which

are conducted every few weeks) and all sales at each auction.

Answer :



1. Unified Process dirancang untuk digunakan pada pengembangan system informasi

yang kompleks dan luas serta untuk menangani masalah pada UML.

Keuntungannya adalah :

Menyediakan petunjuk untuk pengefisien pengembangan dari kualitas software

Mengontrol semua proses dalam setiap tahapan

Menghasilkan software yang berkualitas

Mengurangi resiko

2. 3. Berikut adalah teknik untuk mengumpulkan informasi :

A. Tema Pertanyaan

Pertanyaan seputar 3 dibawah ini :

1. Apa itu proses bisnis?

2. Bagaimana proses bisnis dilakukan?

3. Informasi apa saja yang dibutuhkan?

B. Review dari Laporan, Form, dan Deskripsi Prosedur

Ada 2 sumber informasi untuk prosedur dan form yang ada. Satu dari external

organisasi sedangkan satunya lagi dari laporan, form, dan prosedur dalam dokumen

bisnis dan prosedurdalam organisasi. Untuk memulai proses, analis meminta

pengguna untuk menyediakan salinan dari form dan laporan yang sedang digunakan.

Mereka juga meminta salinan dari prosedur manual dan deskripsi kerja.

C. Melakukan Interview dan Diskusi dengan Pengguna

Merupakan salah satu teknik paling efektif untuk mengerti fungsi dan aturan bisnis.

Agar interview berjalan efektif maka analis harus mengorganisasi 3 area : (1)

Menyiapkan interview, (2) Melakukan interview, dan (3) Follow Up interview.

D. Mengamati Dan Mendokumentasikan Proses Bisnis



Selain interview, metode yang tidak kalah efektif adalah observasi pengguna langsung

dan mendokumentasikan prosesnya. Caranya adalah : (1) Observasi dan (2)

Dokumentasi dengan diagram aktivitas, contoh

E. Membangun Prototipe

Prototipe adalah awal, model kerja dengan entitas lebih kompleks. Ada beberapa

macam prototype : throwaway prototype, discovery prototype, design prototype, dan

evolving prototype. Karakteristik dari prototype yang efektif adalah operative, cepat,

dan fokus.

F. Mendistribusikan dan Mengoleksi Kuesioner

Walau kuesioneer mempunyai kegunaan terbatas dalam Keuntungan menggunakan

kuesioner adalah dapat mengumpulkan informasi dari sejumlah besar pengguna.

G. Melakukan Design Aplikasi Bersama

4. Fully developed adalah metode paling formal untuk mendokumentasikan sebuah use

case. Contohnya sebagai berikut :



Bagian pertama (Use Case Name) dan kedua (Scenario) digunakan untuk

mengidentifikasi nama use case dan scenario di dalam use case.

Bagian ketiga (Triggering Event) mengidentifikasi pemicu yang menjalankan use case

sama seperti yang terdapat dalam event table.

Bagian keempat (Brief Description) menjelaskan deskripsi secara general tentang

jalannya sistem.

Bagian kelima (Actors) mengidentifikasi setiap aktor, pengguna sistem tersebut.

Bagian keenam (Related Use Case) mengidentifikasikan use case lain yang

berhubungan serta hubungan mereka.

Bagian ketujuh (Stakeholders) mengidentifikasi kumpulan yang berhubungan tidak

langsung dengan sistem (diluar aktor).

Delapan dan Sembilan (Precondition dan Postcondition) menyajikan informasi penting

tentang keadaan sistem sebelum dan sesudah use case berjalan. Postcondition adalah

keadaan bersyarat yang harus dipenuhi untuk menjalankan use case. Precondition

adalah keadaan yang harus terjadi setelah use case dijalankan.



Kesepuluh (Flow of Events) menceritakan alur aktivitas dalam use case. Dibagi menjadi

2 kolom, kerja yang dilakukan aktor dan respon dilakukan sistem.

Yang terakhir adalah Exception Condition menuliskan kondisi yang terjadi terjadi

pengecualian dalam aktivitasnya.

5. Activity Diagram adalah sebuah diagram alur kerja yang sederhana yang menjelaskan

bermacam kegiatan dari user atau system, seseorang yang menjalankan beberapa

aktivitas, dan alur kegiatan secara berurutan. Activity Diagram berguna untuk

mendokumentasikan informasi proses kerja suatu sistem. Keuntungannya menggunakan

activity diagram adalah kita dapat visualisasi lebih baik dan kita dapat mereview dengan

pengguna untuk memastikan prosesnya sudah benar selain itu mudah dimengerti.

6. <<includes>> adalah penggunaan relationship antar use case jika salah satu use case

digunakan lebih dari satu kali. Sebagai contoh, 2 subsistem memasukan order adalah

“membuat order” dan “mengupdate order.” Masing-masinguse case memerlukan untuk

memvalidasi akun pelanggan. Maka dari itu use case “validasi akun pelanggan” yang

digunakan bersama dihubungkan dengan dengan tanda panah dan diberi <<includes>>

sebagai indikasi dimana use case tersebut adalah bagian dari use case yang besar

(major). Sebaliknya <<uses>> adalah penggunaan hubungan antar use case dimana ada

satu use case parent yang berhubungan dengan satu atau banyak use case lainnya yang

bersifat sebagai anaknya. Contoh : ketika ada barang dibeli dan pelanggan membayar

maka dengan sendirinya stok akan terupdate. Use case “update stok” merupakan

<<uses>> dari use case “menerima pembayaran.”

7.

3 macam event menurut Satzinger : External Events = Event yang terjadi diluar sistem, biasanya dilakukan oleh

agen eksternal atau aktor. Agen eksternal adalah orang atau unit organisasi

yang memberikan atau menerima data dari sistem. Contoh : Customer

mengupdate informasi.

Temporal Events = Event yang terjadi sebagai hasil dari mencapai batas waktu

yang ditentukan. Dalam event ini tidak ada agen eksternal yang meminta, tapi



sistem mengeluarkan informasi dibutuhkan atau output lainnya ketika

dibutuhkan.

Contoh : Mencetak laporan penjualan tiap akhir bulan.

State Events = Event yang terjadi ketika sesuatu terjadi dalam sistem yang

memicu proses. Contoh : Titik memesan kembali barang yang sudah habis.

8. Source adalah sumber atau external agent yang menyuplai data ke sistem

sedangkan actor adalah orang yang berinteraksi langsung dengan system.

11. Event table dan Use Case



Event Trigger Source Use Case Response Destination

Selling

Customer

mendaftarkan

barang lelang

Adanya

permintaan

pelelangan

Selling

Customer

Menerima dan

mencatat

permintaan

lelang

Surat

mengikuti

pelelangan

Selling

Customer

Buying

Customer

mendaftar

lelang

Adanya

pendaftaran

Buying

Customer

Mendaftarkan

buying

customer

-Record

Customer

baru

-Kartu tanda

peserta

lelang

Buying

Customer

Buying

Customer

mengikuti

lelang

Adanya

permintaan

dan

penawaran

Buying

Customer

- Memberikan

informasi brg

-

Memasangkn

tawaran

- Informasi

barang

lelang

- Harga

terupdate

Buying

Customer

House Auction

mengumumkan

pemenang

lelang

Adanya

kesepakatan

House

Auction

Memasangkan

buying

customer

dengan

barang

Customer

membayar

Lelang

berakhir

Customer Menerima

pembayaran

Bukti bayar Customer

House Auction

memberikan

bagian dari

hasil penjualan

Hasil

penjualan

bagian dari

Selling

Customer

House

Auction

Memberikan

hasil

penjualan

Bukti

transfer

Selling

Customer

Mencatat hasil

pelelangan

Setiap

beberapa

minggu

Mencatat

hasil

pelelangan

Catatan

pelelangan

pray fo anapersis (rangkuman+kisi2)

Documents