Download
1 / 24
240 likes | 382 Views
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
E N D
Requirements Analysis (proses) Analisis, Arsitektur, Desain, danManajemenJaringan Materi 3 Eko Prasetyo TeknikInformatika UniversitasMuhammadiyah Gresik 2011
Menentukankondisiawal • Tipeproyekjaringan • Jaringanbaru • Modifikasijaringan yang sudahada • Analisismasalahjaringan • Outsourcing • Konsolidasi • Upgrade • Skopproekjaringan • Ukuranjaringan • Jumlahlokasi • Jarakantarlokasi • AwaltujuanArsitektur/desain • Upgrade teknologi/vendor • Meningkatkankinerjasebagianatausemuabagianjaringan • Mendukung user, aplikasi, atauperangkat yang baru • Menyelesaikanmasalah yang dialamisistem • Meningkatkan security • Mendukungkemampuanbarudalamsistem
Determining Initial Conditions • Penentuan target pekerjaan: multi-tier performance atausingle-tier performance (Figure 3.2). • Multi-tier performance networks • Biasanyamempunyaisatuataubeberapaaplikasi, user/group, dan/atauperangkatbaru yang membutuhkankinerja yang signifikanlebihbesardaripadakebutuhankinerja yang lain padajaringan. • Sebagaihasilnya, ada threshold diantarakebutuhankinerja low dan high untukjeisjaringanini. • Biasanya, sejumlahkebutuhankinerja yang tinggiinimengendalikanbagaimanadandimanakinerjadiarsitekkankedalamjaringan. • Single-tier performance networks • Tidakmempunyaisejumlahaplikasi, user, atau host yang berbeda yang secarasinifikanmembutuhkankinerja yang tinggibagijaringan. • Sehingga, tidakada threshold diantarakinerja low-high bagitipejaringanini.
Kerjasamadengan user • Dalambekerjadengan user, kecenderunganpertamakitaadalah “inihanyamembuangbanyakwaktu”, “merekatidakkooperatif”, “merekatidakmengerti yang merekainginkan”, dsb, tapihalinipenting, kadangmenyakitkan, sebagaibagianproses. • Awalannya, luangkanwaktudengan user, kitaakanlebihbaikdalammemahamipolaperilakudanlingkunganmereka. • Adabeberapacara yang akhirnyasukses yang dapatkitagunakan: • Membuatsebuah survey dengan email, FAX, atausuratke user. • Menindaklanjuti survey dengantelpon one-to-one atau conference calls. • Menindaklanjutitelpondenganpertemuan face-to-face denganindividuataukelompokterpilih. • Whiteboard sessions untukmemunculkanidedari user. • Meluangkanwaktudengan user sementaramerekabekerjauntukmemahamidenganlebihbaikmengenaiapa yang merekakerjakandanbagaimanamerekamelakukannya.
Kerjasamadengan user • Warning signals, disebutjuga“red flags.” • Misal, warning signal terjadiketikaadaketiadaanketepatanataukejelasankebutuhan: • Salahpenggunaanistilah “real time” • Availability semata-matapersentase (99.99%) • Sangatbervariasi, kebutuhantidakkonsisten. • Kebutuhan yang tidakrealistikdaripelanggan
Developing Service Metrics • Service metrics untukRMA termasuk: • Reliability, denganistilah mean time between failures (MTBF) dan mean time between mission-critical failures (MTBCF) • Maintainability, denganistilah mean time to repair (MTTR) • Availability, denganistilahMTBF, MTBCF, MTTR • Pilihannya, uptime dan downtime (prosentase total waktu), laju error dankehilanganpada level yang bermacam-macam, sepertipacket 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, dalampeak data rate (PDR), sustained data rate (SDR), danminimum data rate (MDR) • Data sizes, termasuk burst sizes dandurations • Service metrics untuk delay termasuk: • End-to-end atauround-trip delay • Latency • Delay variation
Developing Service Metrics • Contohvariables yang digunakansebagaiservice metrics termasuk: • Bytes in/out (per interface) • IP packets in/out (per interface) • Dropped Internet control message protocol (ICMP) messages/unit time (perinterface) • Service-level agreement (SLA) metrics (per user) • Capacity limit • Burst tolerance • Delay • Downtime
Developing RMA Requirements • Reliability adalahindikatorstatistikfrekuensikegagalanjaringandankomponennyadanmerepresentasikanmatinyalayanan yang tidakterjadwal. • Satuukuran reliability adalah mean time between mission-critical failure (MTBCF), biasanyadalamsatuan jam. • Ukuran yang berhubunganadalah mean time between failure (MTBF), yang memandangsemuakegagalan, tanpamelihatwaktukegagalan yang signifikan, danperkiraankonservatif, bergunadalamsistemsederhana. • Maintainability adalahukuranstatistikwaktuuntukmemulihkansistenpada status operasionalpenuh, ketikasatu kali mengalamaikegagalan. Umumnyadiekspresikansebagaimean time to repair (MTTR). • Perbaikansistem yang gagalterdiridaribeberapalangkah: deteksi, mengisolasikegagalanpaakomponen yang dapatdiganti, waktu yang dibutuhkanuntukmenerimakanbagian yang diperlukanpadalokasikomponen yang gagal (logistic time), danwaktu yang sebenarnyauntukmenggantikomponen, menguji, danmemulihkanlayanansepenuhnya.
Developing RMA Requirements • Availability (disebutjugaoperational availability) adalahhubunganantarafrekuensikegagalandari mission-critical failure dan the time to restore service. • Hal inididefinisikansebagai mean time between mission-critical failures (atau mean time between failures) dibagiolehjumlah 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)
Uptime and Downtime • Ukuran yang umumuntuk availability diekspresikandalamistilahprosentase uptime or downtime. • Misal, kebutuhan proposal (RFP) daripelangganberpotensimenyatakankebutuhan uptime 99.999% (umumnyadisebut “five nines”), tapiapasesungguhnya yang dimaksud ? What do the terms uptime and downtime really mean? • Ketika availability direpresentasikansebagaiprosentasedariuptime ataudowntime, diukurperminggu, perbulan, atupertahun, berdasarkan total jumlahwaktuselamasebuahperiode. • Uptime adalahketikasistem (aplikasi, perangkat, jaringan) adalah available pada user (dalamhalini, user bisasajaadalahaplikasiatauperangkat) • Downtime dapatdijangkaudariketidakmampuanuntukterhubungnyadalamjaringan, mempunyaikonektivitastetapi loss rates cukuptinggi (ataukapasitascukuprendah) dimanaaplikasitidakberfungsidenganbaik.
Thresholds and Limits • Contoh threshold yang umumuntuk RMS adalah uptime. • User biasanyamembutuhkansistemmemungkinkandapatberoperasimendekati 100% dariwaktu • Uptime dapatmendekati 100%, dalampuluhan, ratusan, ataukadangribuanpersen, tetapidengan trade-off sistemdalamhalkompleksitasdanbiaya. • Umumnya, kebutuhan uptime yang lebihbesaratausamadengan 99.99% dipandangsebagai high performance, sedangkandibawah 99.99% adalah low performance. • Tambahan, threshold umumdiperkirakan 99.5% dapatdigunakanuntukmembedakankebutuhan low-performance dari prototype dantestbed.
Developing Delay Requirements • Untukaplikasi yang mempunyai delay requirement, kitagunakanistilahend-to-end delay, round-trip delay, dandelay variation sebagaiukurandelay dalamjaringan • Interaction delay (INTD) adalahperkiraanberapa lama user akanmenunggurespondarisistemselamasesiinteraktif. • Interaction delay dapatmenjangkaudari 100 ms sampai 1 menitataulebih. • Umumnya, range yang digunakan 10 sampai 30 ms. • Human response time (HRT) adalahperkiraan threshold waktudimana user memulaiuntukmelihat delay sistem. • Diperkirakan100 ms. • Network propagation delay adalahperkiraanberapa lama waktu yang dibutukansinyaluntukmelintasi media fisikatau link. • Memberikanbatas yang lebihrendahpada end-to-end dan round-trip network dan system delays. • Propagation delay tergantungjarakdanteknologi.
End-to-End and Round-Trip Delays • HRT, INTD, dannetwork propagation delay sebagai threshold danbatasuntukmembedakanantara level performance untuk delay requirements. • Didasarkanpadakombinasi: • Batas fisikdarijaringan, misal: ukuranjaringandanjarak. • Kinerjaperangkat hardware dan software. • Kinerjaprotokoljaringan. • Perilakuaplikasipada delay threshold tertentu. • Interaksi user dengansistempada delay threshold tertentu. • Misal, jikaaplikasimembutuhkan round-trip delay 80 ms dengantujuanuntukmendukunglingkungan virtual reality (VR), dansesiaplikasididistribusikandiantara Los Angeles dan Tokyo, round-trip delay jaringan (diperkirakan 120 ms) akanmelewatibataskebutuhan application delay, tanpamemandangarsitekturdandesainjaringan.
ANY QUESTION ? To Be Continued …
