requirements analysis ( proses )

24
Requirements Analysis (proses) Analisis, Arsitektur, Desain, dan Manajemen Jaringan Materi 3 Eko Prasetyo Teknik Informatika Universitas Muhammadiyah Gresik 2011

Upload: jeff

Post on 07-Jan-2016

49 views

Category:

Documents


0 download

DESCRIPTION

Requirements 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Requirements Analysis ( proses )

Requirements Analysis (proses)

Analisis, Arsitektur, Desain, dan Manajemen JaringanMateri 3

Eko PrasetyoTeknik Informatika

Universitas Muhammadiyah Gresik2011

Page 2: Requirements Analysis ( proses )

2

Menentukan kondisi awalTipe proyek jaringan

Jaringan baruModifikasi jaringan yang sudah

adaAnalisis masalah jaringanOutsourcingKonsolidasiUpgrade

Skop proek jaringanUkuran jaringanJumlah lokasiJarak 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

Page 3: Requirements Analysis ( proses )

3

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.

Page 4: Requirements Analysis ( proses )

4

Kerjasama dengan userDalam 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.

Page 5: Requirements Analysis ( proses )

5

Kerjasama dengan userWarning 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

Page 6: Requirements Analysis ( proses )

6

Taking Performance Measurements

Page 7: Requirements Analysis ( proses )

7

Tracking and Managing Requirements

Page 8: Requirements Analysis ( proses )

8

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

Page 9: Requirements Analysis ( proses )

9

Developing Service MetricsContoh 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 limitBurst toleranceDelayDowntime

Page 10: Requirements Analysis ( proses )

10

Page 11: Requirements Analysis ( proses )

11

Developing RMA RequirementsReliability 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.

Page 12: Requirements Analysis ( proses )

12

Developing RMA RequirementsAvailability (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) atauA = MTBF/(MTBF+MTTR)

Page 13: Requirements Analysis ( proses )

13

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.

Page 14: Requirements Analysis ( proses )

14

Uptime and Downtime

Page 15: Requirements Analysis ( proses )

15

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.

Page 16: Requirements Analysis ( proses )

16

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. 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.

Page 17: Requirements Analysis ( proses )

17

End-to-End and Round-Trip DelaysHRT, 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.

Page 18: Requirements Analysis ( proses )

18

Developing Capacity Requirements: Data Rates

Page 19: Requirements Analysis ( proses )

19

Developing the RequirementsSpecification

Page 20: Requirements Analysis ( proses )

20

Developing the RequirementsSpecification

Page 21: Requirements Analysis ( proses )

21

Developing the RequirementsSpecification

Page 22: Requirements Analysis ( proses )

22

Developing the RequirementsSpecification

Page 23: Requirements Analysis ( proses )

23

Developing the RequirementsSpecification

Page 24: Requirements Analysis ( proses )

24

ANY QUESTION ?To Be Continued …