Transcript MJK2011 – AADM -3- Requirement Analysis (proses)

Analisis, Arsitektur, Desain, dan Manajemen Jaringan
Materi 3
Eko Prasetyo
Teknik Informatika
Universitas Muhammadiyah Gresik
2011
Menentukan kondisi awal
 Tipe proyek jaringan
 Jaringan baru
 Modifikasi jaringan yang sudah ada
 Analisis masalah jaringan
 Outsourcing
 Konsolidasi
 Upgrade
 Skop proek jaringan
 Ukuran jaringan
 Jumlah lokasi
 Jarak antar lokasi
 Awal tujuan
Arsitektur/desain
 Upgrade
teknologi/vendor
 Meningkatkan kinerja
sebagian atau semua
bagian jaringan
 Mendukung user,
aplikasi, atau perangkat
yang baru
 Menyelesaikan masalah
yang dialami sistem
 Meningkatkan security
 Mendukung
kemampuan baru
dalam sistem
2
Determining Initial Conditions
 Penentuan target pekerjaan: multi-tier performance atau single-tier performance (Figure
3.2).
 Multi-tier performance networks
 Biasanya mempunyai satu atau beberapa aplikasi, user/group, dan/atau perangkat baru
yang membutuhkan kinerja yang signifikan lebih besar daripada kebutuhan kinerja yang
lain pada jaringan.
 Sebagai hasilnya, ada threshold diantara kebutuhan kinerja low dan high untuk jeis
jaringan ini.
 Biasanya, sejumlah kebutuhan kinerja yang tinggi ini mengendalikan bagaimana dan
dimana kinerja diarsitekkan kedalam jaringan.
 Single-tier performance networks
 Tidak mempunyai sejumlah aplikasi, user, atau host yang berbeda yang secara sinifikan
membutuhkan kinerja yang tinggi bagi jaringan.
 Sehingga, tidak ada threshold diantara kinerja low-high bagi tipe jaringan ini.
3
Kerjasama dengan user
 Dalam bekerja dengan user, kecenderungan pertama kita adalah “ini
hanya membuang banyak waktu”, “mereka tidak kooperatif”, “mereka
tidak mengerti yang mereka inginkan”, dsb, tapi hal ini penting,
kadang menyakitkan, sebagai bagian proses.
 Awalannya, luangkan waktu dengan user, kita akan lebih baik dalam
memahami pola perilaku dan lingkungan mereka.
 Ada beberapa cara yang akhirnya sukses yang dapat kita gunakan:
 Membuat sebuah survey dengan email, FAX, atau surat ke user.
 Menindaklanjuti survey dengan telpon one-to-one atau conference
calls.
 Menindaklanjuti telpon dengan pertemuan face-to-face dengan
individu atau kelompok terpilih.
 Whiteboard sessions untuk memunculkan ide dari user.
 Meluangkan waktu dengan user sementara mereka bekerja untuk
memahami dengan lebih baik mengenai apa yang mereka kerjakan dan
bagaimana mereka melakukannya.
4
Kerjasama dengan user
 Warning signals, disebut juga “red flags.”
 Misal, warning signal terjadi ketika ada ketiadaan
ketepatan atau kejelasan kebutuhan:
 Salah penggunaan istilah “real time”
 Availability semata-mata persentase (99.99%)
 Sangat bervariasi, kebutuhan tidak konsisten.
 Kebutuhan yang tidak realistik dari pelanggan
5
Taking Performance Measurements
6
Tracking and Managing
Requirements
7
Developing Service Metrics
 Service metrics untuk RMA termasuk:
 Reliability, dengan istilah mean time between failures (MTBF) dan mean time
between mission-critical failures (MTBCF)
 Maintainability, dengan istilah mean time to repair (MTTR)
 Availability, dengan istilah MTBF, MTBCF, MTTR
 Pilihannya, uptime dan downtime (prosentase total waktu), laju error dan
kehilangan pada level yang bermacam-macam, seperti packet error rate, bit
error rate (BER), cell loss ratio (CLR), cell misinsertion ratio (CMR), frame and
packet loss rates
 Service metrics untuk capacity termasuk:
 Data rate, dalam peak data rate (PDR), sustained data rate (SDR), dan minimum
data rate (MDR)
 Data sizes, termasuk burst sizes dan durations
 Service metrics untuk delay termasuk:
 End-to-end atau round-trip delay
 Latency
 Delay variation
8
Developing Service Metrics
 Contoh variables yang digunakan sebagai service
metrics termasuk:
 Bytes in/out (per interface)
 IP packets in/out (per interface)
 Dropped Internet control message protocol (ICMP)
messages/unit time (per interface)
 Service-level agreement (SLA) metrics (per user)
 Capacity limit
 Burst tolerance
 Delay
 Downtime
9
10
Developing RMA Requirements
 Reliability adalah indikator statistik frekuensi kegagalan jaringan dan
komponennya dan merepresentasikan matinya layanan yang tidak
terjadwal.
 Satu ukuran reliability adalah mean time between mission-critical
failure (MTBCF), biasanya dalam satuan jam.
 Ukuran yang berhubungan adalah mean time between failure (MTBF),
yang memandang semua kegagalan, tanpa melihat waktu kegagalan
yang signifikan, dan perkiraan konservatif, berguna dalam sistem
sederhana.
 Maintainability adalah ukuran statistik waktu untuk memulihkan
sisten pada status operasional penuh, ketika satu kali mengalamai
kegagalan. Umumnya diekspresikan sebagai mean time to repair
(MTTR).
 Perbaikan sistem yang gagal terdiri dari beberapa langkah: deteksi,
mengisolasi kegagalan paa komponen yang dapat diganti, waktu yang
dibutuhkan untuk menerimakan bagian yang diperlukan pada lokasi
komponen yang gagal (logistic time), dan waktu yang sebenarnya
untuk mengganti komponen, menguji, dan memulihkan layanan
sepenuhnya.
11
Developing RMA Requirements
 Availability (disebut juga operational availability)
adalah hubungan antara frekuensi kegagalan dari
mission-critical failure dan the time to restore service.
 Hal ini didefinisikan sebagai mean time between
mission-critical failures (atau mean time between
failures) dibagi oleh jumlah mean time to repair dan
mean time between mission-critical failures atau
mean time between failures.
 Formulanya:
 A = MTBCF/(MTBCF+MTTR) atau
 A = MTBF/(MTBF+MTTR)
12
Uptime and Downtime
 Ukuran yang umum untuk availability diekspresikan dalam istilah prosentase uptime or
downtime.
 Misal, kebutuhan proposal (RFP) dari pelanggan berpotensi menyatakan kebutuhan
uptime 99.999% (umumnya disebut “five nines”), tapi apa sesungguhnya yang dimaksud ?
What do the terms uptime and downtime really mean?
 Ketika availability direpresentasikan sebagai prosentase dari uptime atau downtime,
diukur perminggu, perbulan, atu pertahun, berdasarkan total jumlah waktu selama
sebuah periode.
 Uptime adalah ketika sistem (aplikasi, perangkat, jaringan) adalah available pada user
(dalam hal ini, user bisa saja adalah aplikasi atau perangkat)
 Downtime dapat dijangkau dari ketidak mampuan untuk terhubungnya dalam jaringan,
mempunyai konektivitas tetapi loss rates cukup tinggi (atau kapasitas cukup rendah)
dimana aplikasi tidak berfungsi dengan baik.
13
Uptime and Downtime
14
Thresholds and Limits
 Contoh threshold yang umum untuk RMS adalah uptime.
 User biasanya membutuhkan sistem memungkinkan dapat beroperasi
mendekati 100% dari waktu
 Uptime dapat mendekati 100%, dalam puluhan, ratusan, atau kadang ribuan
persen, tetapi dengan trade-off sistem dalam hal kompleksitas dan biaya.
 Umumnya, kebutuhan uptime yang lebih besar atau sama dengan 99.99%
dipandang sebagai high performance, sedangkan dibawah 99.99% adalah low
performance.
 Tambahan, threshold umum diperkirakan 99.5% dapat digunakan untuk
membedakan kebutuhan low-performance dari prototype dan testbed.
15
Developing Delay Requirements


Untuk aplikasi yang mempunyai delay requirement, kita gunakan istilah end-to-end delay, round-trip
delay, dan delay variation sebagai ukuran delay dalam jaringan
Interaction delay (INTD) adalah perkiraan berapa lama user akan menunggu respon dari sistem
selama sesi interaktif.



Human response time (HRT) adalah perkiraan threshold waktu dimana user memulai untuk melihat
delay sistem.


Interaction delay dapat menjangkau dari 100 ms sampai 1 menit atau lebih.
Umumnya, range yang digunakan 10 sampai 30 ms.
Diperkirakan 100 ms.
Network propagation delay adalah perkiraan berapa lama waktu yang dibutukan sinyal untuk
melintasi media fisik atau link.


Memberikan batas yang lebih rendah pada end-to-end dan round-trip network dan system delays.
Propagation delay tergantung jarak dan teknologi.
16
End-to-End and Round-Trip Delays
 HRT, INTD, dan network propagation delay sebagai threshold dan
batas untuk membedakan antara level performance untuk delay
requirements.
 Didasarkan pada kombinasi:





Batas fisik dari jaringan, misal: ukuran jaringan dan jarak.
Kinerja perangkat hardware dan software.
Kinerja protokol jaringan.
Perilaku aplikasi pada delay threshold tertentu.
Interaksi user dengan sistem pada delay threshold tertentu.
 Misal, jika aplikasi membutuhkan round-trip delay 80 ms dengan
tujuan untuk mendukung lingkungan virtual reality (VR), dan sesi
aplikasi didistribusikan diantara Los Angeles dan Tokyo, round-trip
delay jaringan (diperkirakan 120 ms) akan melewati batas kebutuhan
application delay, tanpa memandang arsitektur dan desain jaringan.
17
Developing Capacity
Requirements: Data Rates
18
Developing the Requirements
Specification
19
Developing the Requirements
Specification
20
Developing the Requirements
Specification
21
Developing the Requirements
Specification
22
Developing the Requirements
Specification
23
To Be Continued …
24