Analisis Perancangan Sistem Informasi

RMO Days (1-6)

Huda Alfiansyah - 21070117130070

David Immanuela K.P - 21070117130073
Anta Pratama Ginting - 21070117140072
Day 1
• RMO-Tradeshow System Overall
• Hari pertama pada dasarnya adalah hari perencanaan
• Tim proyek meninjau ulang system vision document yakni ruang lingkup
proyek agar lebih mengerti lagi masalah agar dapat merencanakan iterasi
untuk kedepannya
• Kegiatan inti SDLC kedua (rencanakan dan memantau proyek) yang
dilakukan pada hari pertama meliputi:
• Tentukan komponen utama (area fungsional) yang dibutuhkan
• Tentukan iterasi dan tetapkan masing-masing area fungsional ke iterasi
• Tentukan anggota tim dan tanggung jawab tiap anggota
Planning the Overall Project
and the Project Iterations
• Kapabilitas system dalam system vision
document dapat menentukan rencana proyek keseluruhan
• Langkah pertama adalah membagi system menjadi subsistem (ba
gian fungsional dari keseluruhan sistem informasi) maka tim pro
yek mengidentifikasi dua subsistem yaitu:
• Subsistem informasi pemasok: mengumpulkan dan mengel
ola informasi tentang produsen atau wholesales dan kontak or
ang-orang yang bekerja untuk mereka
• Subsistem informasi produk: menangkap informasi tentan
g berbagai produk yang ditawarkan oleh produsen atau wholes
ales, termasuk detail deskripsi dan foto
• Langkah selanjutnya adalah mengidentifikasi urutan subsistem yang akan
dikembangkan. Banyak masalah dipertimbangkan, seperti ketergantungan
antara berbagai tugas, pengembangan sequential versus paralel,
ketersediaan tim proyek, dan urgensi proyek.
• Dalam kasus di buku, tim memutuskan bahwa subsistem informasi pemasok
harus dijadwalkan untuk iterasi pertama dan subsistem informasi produk
harus dijadwalkan untuk iterasi kedua. Iterasi ketiga dan keempat akan
menyelesaikan implementasi, pengujian, dan penyebaran sistem
berdasarkan apa yang awalnya diimplementasikan dalam dua iterasi
pertama.
Planning the Rest of the First
Iteration: The Supplier
Subsystem
• Proses perencanaan untuk iterasi terdiri dari tiga langkah berikut:
• Identifikasi tugas yang diperlukan untuk iterasi.
• Atur dan susun tugas-tugas ini ke dalam jadwal.
• Identifikasi sumber daya yang diperlukan (terutama orang-orang),
dan tetapkan orang untuk tugas-tugas.
• Langkah pertama adalah mengidentifikasi —
atau berupaya mengidentifikasi —
semua tugas individu yang perlu dilakukan. Ketika tugas-
tugas ini diidentifikasi, mereka dikompilasi dan diorganisir. Terkadang,
daftar tugas yang terorganisir ini disebut work breakdown structure (WBS)
• Bagian dari upaya ini adalah mencoba memperkirakan berapa lama setia
p tugas akan berlangsung.
Karena iterasi ini memiliki ruang lingkup yang sangat terbatas (dan hany
a enam hari), semua perkiraan akan dalam hitungan jam. Perkiraan ini tid
ak termasuk waktu yang dikeluarkan oleh mereka yang tidak berada di ti
m.
• Langkah selanjutnya adalah mengatur tugas-
tugas ini ke dalam jadwal. Sekali lagi, kita bisa menjadi sang
at formal
dan menggunakan alat penjadwalan proyek yang canggih, ata
u kita bisa daftar tugas-
tugas dalam urutan yang kita pikir harus dilakukan. Membua
t tugas secara berurutan merupakan bagian penting dari me
mbangun jadwal karena mengidentifikasi setiap dependensi d
i antara tugas, meskipun banyak tugas dapat dilakukan secar
a paralel.
• Untuk iterasi ini, buku ini telah mengambil tugas dari WBS
dan menempatkannya pada urutan hari demi hari yang kita s
ebut jadwal iterasi. Manajer proyek dapat menggunakan diag
ram ini untuk menetapkan orang ke tugas dan untuk menem
patkan tugas pada bagan jadwal tertentu dengan tanggal kale
nder jika perlu.
Day 2
• Kalau hari pertama melibatkan perencanaan dan
pengorganisasian proyek, hari kedua melibatkan
penemuan dan pemahaman yang detail, yang merupakan
hal penting dalam analisis system.
• Tiga aktivitas proses meliputi:
• Melakukan pencarian fakta untuk memenuhi
persyaratan
• Mengembangkan daftar use case dan use case
diagram
• Mengembangkan daftar dari kelas dan diagram
kelas
Fact Finding and User Involvement
• Sebelum proyek dimulai, definisi persyaratan yang luas dikembangkan.
Sekarang saatnya untuk memeriksa persyaratan-persyaratan tersebut dan
menentukan dengan tepat apa yang dibutuhkan oleh sistem untuk dilakukan
oleh pengguna.
• Ada berbagai teknik untuk memastikan bahwa pencarian fakta lengkap dan
menyeluruh. Ini termasuk mewawancarai pengguna utama, mengamati
proses kerja yang ada, meninjau dokumentasi yang ada dan sistem yang ada,
dan bahkan meneliti perusahaan lain dan sistem lainnya.
• Langkah pertama adalah mengidentifikasi pengguna utama (key users) yang
akan mendefinisikan detail ini. Dalam skenario ini, manajer Departemen
Pembelian akan menjadi pengguna utamanya.
Identifying Use Cases
• Mengidentifikasi dan menggambarkan use case adalah cara untuk
mendokumentasikan apa yang harus dilakukan oleh pengguna dengan
sistem. Istilah use case memiliki arti kasus atau situasi dimana sistem
digunakan.
• Misalnya, agen pembelian pergi ke pameran dagang dan menemukan jaket
olahraga ringan baru yang akan bekerja dengan baik untuk penawaran
barang dagangan musim gugur RMO. Misalkan tugas pertama yang perlu
dilakukan agen pembelian adalah mencari tahu apakah pemasok ini pernah
bekerja dengan RMO sebelumnya. Dengan demikian, use case yang
diperlukan untuk Sistem Tradeshow mungkin adalah mencari pemasok.
• Gambar ini adalah daftar awal uses
cases untuk seluruh Sistem
Tradeshow. Ketika tim proyek bertemu dengan age
n pembelian dalam sesi brainstorming, mereka me
ngidentifikasi use cases bersama-
sama. Karena iterasi pertama hanya berfokus pad
a Subsistem Informasi Pemasok, tim proyek juga a
kan memusatkan perhatian hanya pada empat use
cases pertama dalam daftar.
Identifying Domain Classes
• Kelas domain mengidentifikasi hal-hal di dunia nyata yang perlu diketahui
dan diperhatikan sistem. Untuk menemukan kelas domain, perlu mencari
semua objek yang digunakan oleh sistem. Objek memiliki banyak jenis dan
variasi, dari benda berwujud hingga yang tidak dapat disentuh
• Kelas domain adalah kategori objek yang diidentifikasi. Kelas Produk
mewakili semua objek produk yang digunakan oleh sistem. Kelas domain
diidentifikasi selama diskusi dengan agen pembelian dengan mencari kata
benda yang menggambarkan kategori hal. Misalnya, agen akan sering
berbicara tentang pemasok, produk barang dagangan, atau barang
inventaris. Kata benda ini menjadi kelas domain, dan setiap kelas domain
memiliki atribut (seperti informasi kontak, produk, atau lokasi bisnis) yang
merinci informasi yang diperlukan untuk menyimpan tentang kelas domain.
• Gambar disamping menggambark
an kata benda mana
yang merupakan kelas domain un
tuk Sistem
Tradeshow. Atribut adalah potong
an informasi yang membantu men
entukan dan menjelaskan detail t
entang kelas domain.
• Gambar diatas menunjukkan diagram kelas domain untuk Sistem Tradeshow. Setiap kotak
adalah kelas dan dapat dianggap sebagai seperangkat objek tertentu yang penting bagi sistem.
Atribut dari setiap kelas juga termasuk untuk mewakili informasi rinci tentang setiap objek
yang akan dikelola oleh sistem. Beberapa kelas memiliki garis yang berhubungan untuk
mewakili asosiasi antara kelas yang perlu diingat oleh sistem. Misalnya, kontak adalah orang
yang bekerja untuk pemasok tertentu. Contoh spesifik mungkin bahwa Bill Williams adalah
penghubung untuk Perusahaan Pakaian Olahraga Pasifik Selatan. Dengan demikian, sistem
perlu mengasosiasikan Bill Williams dan South Pacific Sportswear Company.
Sistem Tradeshow sangat sederhana, dengan hanya empat kelas yang diidentifikasi — dua di
antaranya milik Subsistem Informasi Pemasok. Sebagian besar sistem kehidupan nyata jauh
lebih besar dan memiliki puluhan atau bahkan ratusan kelas domain.
Day 3 Activities
• Tujuan kegiatan di hari ketiga adalah untuk
menganalisa detail penggunaan kasus dan kelas
domain yang di jadwalkan untuk diimplementasikan
di iterasi pertama subsistem pemasok.
• 3 proses inti:
 Lakukan pencarian fakta yang mendalam untuk
memahami detail dari setiap kasus.
 Memahami dan mendokumentasikan aliran kerja
secara detail
 menentukan pengalaman pengguna dengan sketsa
layar dan laporkan yang dibutuhkan untuk setiap
kasus.
• Setelah bekerja dengan purchasing agent, pengembang
menentukan kasus yang berkaitan dengan subsistem
informasi pemasok:
 Mencari pemasok
 Memasukkan / memperbarui informasi pemasok
 Mencari informasi kontak
 Memasukkan / memperbarui informasi kontak
• Dari list di atas, pengembang membuat diagram kasus
• Diagram kasus digunakan untuk menggambarkan
secara grafis kasus dan pengguna yang terlibat dalam
subsistem
 Developing Use Case Descriptions and
Workflow Diagrams
• Metode use case description dan
activity diagram tujuannya untuk
mendokumentasikan interaksi
antara pengguna dan sistem.
• Gambar1-15 adalah activity
diagram yang mengilustrasikan
kegiatan mencari pemasok
 Defining Screen Layout
• Desainantarmuka (user
interface) membuat bagaimana
tampilan system dan bagaimana
pengguna berinteraksi.
• Desain
antarmuka yang didesain
dengan baik (intuitif dan mudah)
dapat meningkatkan utilitas
sistem dengan pesat.
Day 4 Activities
• Fokus hari keempat adalah mendesain berbagai
komponen dalam sistem solusi – design system
components
• Kita mendesain sistem berdasarkan keperluan pengguna
kemudian diberikan kepada tenaga programming.
• Proses inti hari keempat:
 Mendesain struktur database (skema): elemennya seperti desain tabel,
identifikasi key dan index, tipe atribut.
 Mendesain struktur sistem tingkat tinggi: mengidentifikasi subsistem dan
koneksi dengan sistem lain, antar subsistem dibuat keputusan modul program
seperti user interface, business logic, dan database access.
 Designing the Database
• Mendesain database membutuhkan
informasi yang disediakan domain
class diagram untuk menentukan
tabel, kolom, dan komponen lain.
• Pada gambar 1-17 ditampilkan dua
relational database table yang
menghasilkan atribut yang datang
bersama tipe data dan properti lain.
 A General Approach to Design
• 3 set informasi yang menjawab bagaimana dan dimana untuk memulai software
design:
 Use cases, with activity diagrams
 Domain classes, with accompanying diagrams
 Pages and reports, with program and display logic specifications
• Diskusikan dahulu tujuan system design dan output yang diharapkan.
• Desain dimulai dari level paling tinggi dan turun terus hingga ke level dasar,
sampai kita dapat menjelaskan semua fungsi antar kelas.
• Untuk memprogram kita perlu tahu kelas apa saja, logika apa yang ada di tiap
kelas (the functions) dan kelas mana yang garus berinteraksi.
 Designing the Software Components
• Keputusan sudah dibuat dalan aplikasi yang didesain
browser-based system design agar dapat digunakan pada
hp dan tablet.

• Browser-based system dibentuk berbeda dari application

system yang berjalan pada hp dan tablet.

• Browser-based system tidak menyediakan kecepatan

konektifitas dan kontrol, tapi dapat dengan mudah
diterapkan pada berbagai equipment (laptop dan tablet)
tanpa modifikasi.
 Defining the Preliminary Design Class
Diagram
• The Tradeshow System dibuat menggunakan teknik
object-oriented programming (OOP), dimulai dengan
mengembangkan set kelas perangkat lunak dan
metode yang akan digunakan pada sistem.

• The design classes pada gambar 1-19 berisi atribut

yang dibutuhkan pada kelas, nama metode, dan
panah yang menunjukkan akses kelas kepada metode
kelas lain.
 Designing Subsystem Software Architecture
• Setelah kita dapat struktur secara umum dan pendekatan
untuk menerapkan sistem baru, kita mulai turun ke desain
perangkat lunak untuk subsistem.

• Subsistem ini lebih lanjut dibagi dalam layers: a view layer

dan a domain layer.

• Keuntungannya adalah lebih mudah dibuat dan

mempertahankan dengan jenis struktur ini.

• The view layer termasuk tampilan SupplierView dan

ContactView dengan beberapa fungsi JavaScript.

• The Domain layer termasuk dua kelas (Supplier dan

Contact) berinteraksi satu sama lain dan dengan database
 Managing the Project
• Desain adalah kegiatan kompleks antar beberapa perspektif - mulai dari struktur tingkat
tinggi sampai desain program detail tingkat bawah

• Pada projek kita sudah dipisah tugas untuk mendesin sistem secara umum dengan desain
program secara detail.

• Desain perangkat lunak tingkat tinggi ditentukan pertama kemudian desain tingkat
menengah dan bawah sering diselesaikan bersamaan dengan programming.

• Project manager dapat menentukan untuk meluaskan proyek atau menambah programmers
untuk menulis code.

• Dalam projek kita, sudah ditentukan untuk menambah setengah waktu luang untuk membawa
dua tambahan programmer dan melatih mereka.

• Kita dapat terus bergerak dan memulai kegiatan hari kelima untuk memastikan kita tetap
dalam jadwal projek.
Day 5 Activities
 Day 5 Activities

Program the
Create sub
detail subsystem
design components

Saat programmer membuat coding, mereka juga melakukan test pada kelas
dan fungsi dari program yang mereka buat.
Day 6 Activities
 Functional
testing

FINAL TESTING
a step that is required before the
system is ready to be deployed
User
acceptance
tests
Diagram alur pengujian system baru