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)

You Might Also Like

0 comments

Popular Posts

Like us on Facebook

Most Popular