Pertemuan 4 Proses Analisis Kebutuhan
November 27, 2022- Menetukan Kondisi Awal
Penentuan target pekerjaan terdiri dari:
1) Multi-tier performance network
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.
2) Single-tier performance network
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.
- Mengambil Pengukuran Kinerja
→ Pengukuran aplikasi puncak dan kinerja perangkat dapat digunakan
untuk menentukan seberapa besar penurunan kinerja yang dialami
pada jaringan yang ada.
→ Pengukuran tersebut menjadi validasi masalah kinerja pada
jaringan yang ada
- Persyaratan Pelacakan dan Pengelolaan
→Daftar persyaratan harus terus diperbarui, di lokasi di
mana setiap orang yang terlibat dalam proses
memiliki akses ke sana.
→Web merupakan alat untuk memposting, melacak,
dan mengelola persyaratan.
→Ada sejumlah metode yang bisa digunakan untuk
melacak dan mengelola persyaratan.
Diantaranya :
1. Bentuk paragraph
Example : persyaratan untuk upgrade ke peralatan jaringan ditampilkan di
bawah
NR - 1,0-102. Semua (teknologi A 3/7/2007) peralatan jaringan harus mampu
perangkat lunak (atau firmware 4/1/2000) (dihapus 4/17/2007) berbasis
upgrade untuk memungkinkan untuk mendukung perubahan kecepatan tinggi
(setiap 5/20 /2007) fitur dan fungsi layanan data.
→Perubahan dilakukan pada berbagai waktu, yang mencerminkan evolusi
persyaratan saat berbicara dengan pengguna, manajemen, dan staf
2. Bentuk form tabel.
Metode ini dimana persyaratan disimpan dalam bentuk aslinya, dan semua
perubahan ditambahkan ke dalam tabel.
- 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 sices, termasuk burst sizes dan durations
→ Service metrics untuk delay termasuk:
❖ End-to-end atau round-trip delay
❖ Latency
❖ Delay variation
→ 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) message/unit time (per
interface)
→ Service-level agreement (SLA) metrics (per user) : satu dari dua perjanjian dasar
yang dimiliki penyedia layanan dengan pelanggan mereka.
❖ Capacity limit
❖ Burst tolerance
❖ Delay
❖ downtime
- Alat Pengukuran
Alat pengukuran yang biasa digunakan yaitu:
1) Ping utilitas (tersedia dalam rilis TCP/IP) :
mengukur penundaan bolak-balik antara
sumber dan tujuan yang dipilih dalam
jaringan.
2) Pathchar (tersedia dari ee.lbl.gov) : yang
menggabungkan penundaan bolak-balik
dan pengukuran kapasitas per tautan
dengan jejak jalur, seperti halnya traceroute
utilitas populer lainnya.
3) TCPdump : untuk menganalisis lalu lintas
TCP
- Developing RMA Requiremen
→ 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.
→ Availability (disebut juga ketersediaan operasional) adalah hubungan antara
frekuensi kegagalan dari mission-critical failure dan waktu untuk memulihkan
layanan.
→ Hal ini didefinisikan sebagai waktu rata-rata antara kegagalan mission-critical
(atau waktu rata-rata antara kegagalan) dibagi dengan jumlah waktu rata-rata
untuk memperbaiki dan waktu rata-rata antara kegagalan mission-critical atau
waktu rata-rata antara kegagalan.
→ Formulanya:
❖ A = MTBCF/(MTBCF+MTTR) atau
❖ A = MTBF/(MTBF+MTTR)
→ Availability (disebut juga ketersediaan operasional) adalah hubungan antara
frekuensi kegagalan dari mission-critical failure dan waktu untuk memulihkan
layanan.
→ Hal ini didefinisikan sebagai waktu rata-rata antara kegagalan mission-critical
(atau waktu rata-rata antara kegagalan) dibagi dengan jumlah waktu rata-rata
untuk memperbaiki dan waktu rata-rata antara kegagalan mission-critical atau
waktu rata-rata antara kegagalan.
→ Formulanya:
❖ A = MTBCF/(MTBCF+MTTR) atau
❖ A = MTBF/(MTBF+MTTR)
- Uptime dan Downtime
→ Ukuran yang umum untuk availability diekspresikan dalam
istilah persentase 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 persentase 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.
- Mengukur Uptime
Persyaratan untuk uptime mungkin terlihat seperti ini:
Waktu Aktif Jaringan (lihat Gambar 3.11 dan 3.12):
1) Waktu aktif 99,99%, diukur setiap minggu, diukur
pada setiap antarmuka router dan perangkat
pengguna dalam jaringan.
2) Waktu aktif 99,999%, diukur setiap minggu, untuk
akses ke jaringan server farm, diukur pada
antarmuka router di server farm, di NIC server. Ping
aplikasi juga akan digunakan untuk menguji
konektivitas antara setiap LAN pengguna dan LAN
server.
3) Perhatikan bahwa persyaratan ini tidak berlaku
untuk periode waktu henti terjadwal untuk
pemeliharaan
- Theresold 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
- Developing Delay Requiremens
→ Untuk aplikasi yang mempunyai delay requirement, kita gunakan istilah end-toend 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.
❖ Interaction delay dapat menjangkau dari 100 ms sampai 1 menit atau lebih.
❖ Umumnya, range yang digunakan 10 sampai 30 ms.
→ Human response time (HRT) adalah perkiraan threshold waktu dimana user
memulai untuk melihat delay sistem.
❖ 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.
- Developing Capacity
Requirements : Data Rates
- Developing The
Requirements Spesification
→ Spesifikasi kebutuhan dan peta
kebutuhan merupakan hasil dari
proses analisis. → Bagian pertama proses ini yaitu
Menentukan Kondisi awal untuk
proyek.
→ Mencakup jenis proyek jaringan,
ruang lingkup proyekm tujuan
proyek, administratif, dan
keuangan yang bekerja pada
proyek.
→ Bagian dari kondisi awal proyek
mungkin menentukan apakah
jaringan membutuhkan kinerja
single-tier or multi-tier
performance
→ Bagian kedua dari spesifikasi
persyaratan terdiri dari
persyaratan yang dikumpulkan
dan diturunkan untuk jaringan
→ Seperti contoh gambar 3.29
beberpa persyaratab dipelajari
dalam diskusi awal dengan
pelanggan (manajemen dan staff)
0 comments