Konfigurasi, Integrasi dan System Operasi Jaringan

A.  konfigurasi 

konfigurasi adalah pengaturan - atau proses pembuatan pengaturan - dari bagian-bagian yang membentuk keseluruhan.

Konfigurasi Jaringan menggambarkan berbagai kegiatan yang berhubungan dengan membangun dan mempertahankan jaringan data. Konfigurasi Jaringan mencakup isu-isu yang berkaitan dengan memungkinkan protokol dari perspektif perangkat lunak, dan isu-isu yang berkaitan dengan router,switch, dan firewall dari perspektif hardware.

B.  Integrasi

Integrasi merupakan penyatuan unsur-unsur  dari sesuatu yang berbeda atau beraneka ragam sehingga menjadi satu kesatuan dan pengendalian terhadap konflik atau penyimpangan dari penyatuan unsur-unsur tersebut.

Integrasi data merupakan suatu proses menggabungkan atau menyatukan data yang berasal dari sumber yang berbeda dalam rangka mendukung manajemen informasi dan mendukung pengguna untuk melihat kesatuan data.

C.  System Operasi Jaringan  Sistem operasi jaringan adalah sebuah jenis sistem operasi yang ditujukan untuk menangani jaringan. Umumnya, sistem operasi ini terdiri atas banyak layanan atau service yang ditujukan untuk melayani pengguna, seperti layanan berbagi berkas, layanan berbagi alat pencetak (printer), DNS Service, HTTP Service, dan lain sebagainya.

Konfigurasi integrasi system operasi jaringan adalah konfigurasi yang dilakukan agar antar sub sistem saling keterkaitan sehingga data dari satu sistem secara rutin dapat melintas, menuju atau diambil oleh satu atau lebih sistem yang lain.

1.     Fungsi Integrasi Sistem Operasi  dengan Jaringan

·           Menghubungkan sejumlah komputer dan perangkat lainnya ke sebuah jaringan

·           Mengelola sumber daya jaringan

·           Menyediakan layanan 

·           Menyediakan keamanan jaringan bagi multiple users

·           Mudah menambahkan client dan sumber daya lainnnya

·           Memonitor status dan fungsi elemen – elemen jaringan 

·           Distribusi program dan update software ke client 

·           Menggunakan kemampuan server secara efisien 

·           Menyediakan tolerasi kesalahan 

2.     Konfigurasi intergrasi sistem operasi dengan jaringan (Internet).

Ada beberapa metode yang dapat dipergunakan dalam membangun sistem terintegrasi, yaitu :

1)         Vertical Integration

merupakan proses mengintegrasikan sub-sub sistem berdasarkan fungsionalitas dengan menghubungkan sub-sub sistem yang sudah ada tersebut supaya bisa berinteraksi dengan sistem terpusat dengan tetap berpijak pada arsitektur sub sistem yang lama. Metode ini memiliki keuntungan yaitu dapat dilakukan dengan cepat dan hanya melibatkan beberapa entitas development yang terkait dalam proses pembuatan sistem lama. Kelemahannya, metode ini tidak memungkinkan untuk mengimplementasikan fungsi-fungsi baru atau proses bisnis baru ke dalam sub-sistem yang sudah ada – karena effortlebih tinggi ada di proses“mempelajari” arsitektur sistem lama dan menjadikannya acuan untuk membuat sistem terintegrasi. Untuk menghadirkan ekspansi fungsionalitas atau proses bisnis baru adalah harus membuat sub-sistem baru.

2)    Star Integration

atau lebih dikenal sebagai spaghetti integration, adalah proses mengintegrasikan sistem dengan cara menghubungkan satu sub sistem ke semua sub-sub sistem lainnya. Sebuah fungsi bisnis yang diimplementasikan dalam sebuah sub sistem akan di-broadcast ke semua sub-sub sistem lain yang dependen terhadap fungsi bisnis tersebut supaya dapat dipergunakan sebagaimana mestinya. Untuk integrasi sistem dengan ruang lingkup kecil atau menengah dan dengan pemisahan fungsi bisnis yang jelas dan spesifik, metode integrasi ini layak untuk dipertimbangkan. Namun jika fungsi bisnis banyak terlibat di beberapa sub sistem secara dependen, pada akhir proses integrasi sistem akan terlihat sedikit “kekacauan” dalam diagram – proses interkoneksi antar sub sistem akan tampak seperti spaghetti. Efeknya, biaya perawatan dan ekspansi sistem di masa yang akan datang akan memerlukan effort yang sangat berat untuk mempelajari skema integrasi sistem berikut dependency-nya.

3)    Horizontal Integration

atau ada yang mengistilahkan dengan Enterprise Service Bus (ESB), merupakan sebuah metode yang mengintegrasikan sistem dengan cara membuat suatu layer khusus yang berfungsi sebagaiinterpreter, dimana semua sub-sub sistem yang sudah ada akan berkomunikasi ke layer tersebut. Model ini lebih menawarkan fleksibilitas dan menghemat biaya integrasi, karena yang perlu difokuskan dalam implementasi proses pengintegrasian hanya layer interpreter tersebut.  Untuk menangani ekspansi proses bisnis juga hanya perlu diimplementasikan dilayer interpreter itu juga, dan sub sistem baru yang akan menanganiinterface dari proses bisnis ekstensi tersebut akan berkomunikasi langsung ke layer dan layer akan menyediakan keperluan-keperluan data/interface untuk sub sistem lain yang memerlukannya.

3.     Menguji hasil integrasi sistem operasi dengan jaringan (internet). 

Definisi Uji integrasi

·          Menurut wikipedia, adalah aktivitas pengujian software dalam mana modul-modul software dikombinasikan dan diuji sebagai satu kesatuan.

·          Menurut Roger S. Pressman adalah teknik sistematis untuk membangun arsitektur software sambil pada saat yang sama menjalankan pengujian untuk menemukan error terkait dengan interfacing, komunikasi antar modul. Uji integrasi setelah uji unit sebelum uji sistem. 

Tujuan Uji Integrasi 

pemeriksaan fungsional, kinerja dan kehandalan dari struktur program yang telah dirancang. Kelompok-kelompok modul, data bersama, komunikasi antar proses diperiksa melalui antarmukanya menggunakan uji black box. Sukses atau gagal disimulasikan melalui uji parameter dan masukan data. Kasus-kasus pengujian dibangun untuk menguji interaksi di antara seluruh komponen dalam kumpulan modul, melalui pemanggilan prosedur atau aktivasi proses. 

Pendekatan Big bang Ada kecenderungan orang untuk melakukan uji integrasi ini dengan cara tidak bertahap, pendekatan “big bang”. Seluruh komponen dikombinasikan bertahap. Keseluruhan program diuji sebagai satu kesatuan. Dan biasanya dihasilkan chaos. Sekumpulan error ditemukan. Koreksi sulit dilakukan karena sulitnya mengisolasi penyebab kesalahan. Satu kesalahan dapat diatasi, kesalahan yang lain muncul dan proses berlanjut seolah tanpa henti. Salah satu tipe pendekatan “big bang” adalah pengujian model penggunaan, usage model testing. Pengujian dilakukan dengan mengambil kasus-kasus beban kerja mirip pengguna dalam lingkungan kerja akhir yang terintegrasi. Lingkungan diuji, komponen individu diuji secara tidak langsung melalui Uji Integrasi penggunaan mereka. Beban kerja mirip pengguna perlu didefinisikan dengan hati-hati untuk membuat skenario yang realistis dalam memeriksa lingkungan.
 Pendekatan Incremental Berlawanan dengan pendekatan “big bang”, program dibangun dan diuji bertahap sedikit demi sedikit. Kesalahan akan mudah diisolasi dan diperbaiki, antarmuka dapat diuji lengkap, dan pendekatan pengujian sistematis dapat diterapkan. Pengujian dilakukan mungkin secara top down, bottom up, regression testing atau smoke testing. Dalam metode ini, modul-modul diintegrasikan dengan perjalanan turun melalui hirarki kendali, mulai dari modul utama kemudian ke modul-modul subordinat. Modul-modul subordinat dapat digabungkan ke dalam struktur program dengan pola depth-first atau breadth-first.
 Pola depth-first, modul diintegrasikan satu demi satu melalui struktur kendali utama program. pola breadth-first, seluruh komponen subordinat langsung di setiap level, menelusuri struktur secara horisontal.

 Integrasi Bottom up Dalam metode ini komponen level paling bawah diuji pertama kali. Pengujian ini tidak memerlukan modul stub. Proses diulang sampai komponen puncak hirarki diuji. Pendekatan ini sangat membantu ketika seluruh atau kebanyakan modul dari level pengeembangan yang sama sudah siap. Metode ini juga membantu menentukan level pengembangan software yang memudahkan pelaporan kemajuan pembuatan software dalam bentuk persentase. 

Tahap-tahap untuk melakukan integrasi bottom up adalah sebagai berikut:

1.      Komponen-komponen level bawah dikombinasikan ke dalam cluster yang  menjalankan subfungsi software khusus.

2.      Driver ditulis untuk mengkoordinasikan kasus pengujian masukan dan keluaran. 

3.      Cluster diuji.

4.      Driver dihapus dan cluster dikombinasikan ke atas menelusuri struktur program.

Oleh karena integrasi dilakukan dalam arah ke atas, kebutuhan test driver yang berbeda muncul. Dalam praktek, jika dua level puncak struktur program diintegrasikan top down, jumlah driver dapat dikurangi, integrasi cluster dapat disederhanakan. Menggabungkan pengujian bottom up dengan top down ini sebagian orang menyebutnya pengujian sandwich.

Pengujian Regressi adalah menjalankan kembali beberapa subset pengujian yang telah dilakukan untuk meyakinkan bahwa perubahan tidak punya efek samping yang tidak diharapkan. Perlu dilakukan mengingat setiap kali modul baru diintegrasikan, software berubah. Ada aliran data yang baru, atau I/O baru, atau logika kendali yang baru. Perubahan ini boleh jadi punya efek samping yang tidak diharapkan. Kesalahan harus diperbaiki. Ketika dikoreksi, data atau program atau dokumentasi berubah. Dengan pengujian regressi diharapkan perubahan ini tidak menimbulkan kesalahan lain. Menguji kembali setiap modul pada setiap kali modul baru ditambahkan adalah tidak praktis dan tidak efisien. Seiring berlangsungnya uji integrasi, jumlah uji regresi dapat meningkat dalam jumlah besar. Sekumpulan uji yang perlu diulang perlu dirancang untuk menyertakan hanya modul berikut :

·         sampel uji representatif yang memeriksa seluruh fungsi software. 

·         uji tambahan yang fokus pada fungsi-fungsi software yang kemungkinan besar dipengaruhi perubahan.

·         pengujian yang fokus pada komponen-komponen software yang telah berubah. 

Modul kritis, critical module adalah modul yang memiliki karakterisitik: 

·         memenuhi beberapa kebutuhan software 

·         memiliki level kendali yang tinggi 

·         kompleks atau mudah salah 

·       memiliki kebutuhan kinerja yang definitif
 Modul kritis sebaiknya diuji seawal mungkin. Uji regresi sebaiknya fokus pada fungsi modul kritis. Pengujian regresi dapat dijalankan secara manual atau menggunakan tool capture/playback otomatis. Tool ini memungkinkan capture kasus-kasus pengujian dan urutan hasil-hasil playback sebagai bahan perbandingan. Pengujian Smoke McConnel mendefinisikan smoke test, uji asap, sebagai pemeriksaan keseluruhan sistem dari status terakhir ke status terakhir berikutnya. Tidak perlu uji menyeluruh, tetapi sanggup menunjukkan masalah penting. Uji menyeluruh harus cukup menyeluruh sedemikian hingga jika suatu modul sudah jadi, ia cukup stabil untuk uji-uji berikutnya. Software perlu diuji setiap hari. Untuk ini, aktivitas berikut perlu dilakukan : 

·         komponen-komponen software diintegrasikan ke dalam “build”

·         pengujian beruntun dirancang untuk menemukan kesalahan yang dapat membuat deliveri software terlambat. 

·         Modul jadi diintegrasikan dengan modul jadi lain

·         keseluruhan produk diuji asap setiap hari. 

 Mungkin ada batas waktu pembuatan software yang ketat, yang kritis. Pengujian setiap hari akan menunjukkan perkembangan uji integrasi pada manajer dan praktisi dengan seksama. Pengujian ini menguntungkan dari sisi : 

-          resiko integrasi diminimalkan : kesalahan ditemukan sejak dini, perbaikan dapat segera dilakukan, deliveri software dapat tepat waktu. 

-          kualitas produk akhir diperbaiki : kesalahan coding, design, analsysis dapat segera ditemukan, perbaikan rancangan dapat segera dilakukan, kualitas produk akhir dapat lebih baik. 

-          diagnosa kesalahan dan perbaikan disederhanakan : biasanya kesalahan integrasi ditemukan pada saat modul baru diintegrasikan, perbaikan kesalahan dapat fokus pada modul baru tersebut dan modul lain yang terkait. 

-          kemajuan lebih mudah diperiksa : setiap hari ada modul baru diintegrasikan dan sudah diuji bekerja. Ini dapat meningkatkan moral tim dan memberi indikasi bagus pada manajer bahwa kemajuan sudah dibuat. 

 Dokumentasi Tes Integrasi Seluruh rencana integrasi software dan gambaran uji khusus didokumentasi dalam Test Specification, spesifikasi pengujian. Dokumen ini berisi rencana dan prosedur pengujian. Ia merupakan produk kerja proses software, dan menjadi bagian konfigurasi software. Rencana pengujian berisi satu atau beberapa hal berikut: 

·         kapan dan bagaimana pengujian akan dilakukan 

·         daftar hal-hal yang akan diuji 

·         siapa yang menguji dan apa tanggung jawabnya 

·         apa yang diperlukan untuk pengujian - lingkungan pengujian 

·         asumsi-asumsi - apa yang perlu dilakukan ketika kesalahan ditemukan 

·         apa yang perlu dilakukan ketika kesalahan tidak ditemukan 

·         daftar istilah. 

Kriteria berikut diterapkan di setiap tahap pengujian: 

·           Interface integrity : integritas antarmuka setiap modul diuji, internal (pemanggilan prosedur anak) atau eksternal (pemanggilan prosedur lain). 

·           Functional validity : apakah modul dan integrasinya telah memberikan hasil yang valid 

·           Information content : apakah data lokal, global, file, basis data tetap konsisten akibat eksekusi modul atau integrasinya.

·           Performance : apakah kinerja software sesuai dengan yang direncanakan. Rencana pengujian perlu disiapkan untuk masing-masing kriteria. 

Faktor-faktor yang sering berpengaruh dalam tes integrasi adalah: 

·         manajemen konfigurasi software: gunakan versi komponen yang benar untuk pengujian. 

·         otomatiskan proses kompilasi jika diperlukan 

·         dokumentasi: membantu tidak kehilangan error yang harus diatasi. 

·         pelacakan kesalahan : uji integrasi akan kehilangan maknanya jika kesalahan tidak dilacak dengan benar. 

Riwayat hasil uji aktual, masalah atau keanehan yang muncul disampaikan dalam Test Report, Laporan pengujian. Laporan ini ditambahkan dalam Spesifikasi Test. Informasi di laporan pengujian ini penting untuk perawatan software. Nasehat Cem Kner dan kawan-kawan perlu direnungkan, ”Penguji terbaik bukan siapa yang menemukan bug terbanyak...., penguji terbaik adalah siapa yang mendapatkan sebanyak-banyaknya bug diatasi.” 

 Uji integrasi dalam Konteks OO Software berorientasi objek tidak memiliki struktur kendali hirarki, sehingga integrasi top-down atau bottom-up kurang berarti. Integrasi boleh jadi dalam dua bentuk yaitu thread-based testing dan use-based testing. Dalam thread-based testing, integrasi dilakukan terhadap sekumpulan class yang dibutuhkan untuk menjawab satu input atau event untuk sistem. Setiap thread diintegrasikan dan diuji individual. Uji regresi dilakukan untuk meyakinkan bahwa tidak terjadi efek samping. Dalam use-based testing, konstruksi sistem dimulai dengan menguji class-class yang menggunakan class server paling sedikit. Class ini disebut class independent. Setelah class independent diuji, class yang menggunakannya (class dependent) diuji. Pengujian class dependent dilakukan berturut-turut, lapis demi lapis, hingga keseluruhan sistem dibangun. Driver dapat digunakan untuk menguji operasi-operasi di level terendah dan untuk menguji sekumpulan class. Driver juga dapat digunakan untuk mengganti antarmuka untuk menguji fungsionalitas sistem. Stub diperlukan untuk mengganti class yang belum jadi ketika dibutuhkan kolaborasi antar class. Ada yang menyebut class-class yang berkolaborasi dengan istilah cluster. Cluster testing, pengujian cluster, memeriksa kolaborasi antar class dengan beragam kasus. 

Uji Arsitektur Client/Server Arsitektur client/server menantang para penguji software. Sifat tersebarnya, isu kinerjanya terkait dengan pemrosesan transaksi, kemungkinan penggunaan sejumlah hardware yang berbeda, kompleksitas komunikasi jaringan, kebutuhan melayani banyak client dari basis data terpusat atau tersebar, koordinasi ragam aplikasi di server membuat pengujian arsitektur client/server lebih sulit daripada aplikasi standalone. Pada umumnya pengujian software client/server terjadi dalam tiga level yang berbeda : 

·      aplikasi client individual diuji dalam mode “disconnected” dengan server, operasi server dan jaringan belum diperhatikan, 

·      software client dan aplikasi server yang terkait diuji, tetapi operasi jaringan belum diperhatikan,

·      arsitektur client/server yang lengkap, termasuk operasi jaringan dan kinerjanya diuji. Pendekatan pengujian berikut umum dilakukan pada aplikasi client/server: 

-          application function tests : fungsionalitas aplikasi client diuji dalam tampilan standalone. 

-          server tests : koordinasi dan fungsi manajemen data dari server diuji. Kinerja server juga diperiksa. 

-          database tests : keakuratan dan integritas data yang disimpan di server diuji. Transaksi yang dikirim aplikasi client diteliti untuk meyakinkan bahwa data disimpan, dicari, diupdate dengan benar. Pengarsipan data kadaluwarsa juga perlu diperiksa. 

-          transaction tests : uji beruntun dibuat untuk meyakinkan bahwa setiap jenis transaksi diproses sesuai kebutuhan. Uji berfokus pada kebenaran pemrosesan dan isu kinerja (waktu pemrosesan dan volume transaksi). 

-          network communication tests : uji ini memeriksa komunikasi di antara node-node jaringan : pengiriman pesan, transaksi, dan lalu lintas jaringan terkait tidak terjadi kesalahan. Keamanan jaringan menjadi bagian dari uji ini. Mungkin operational profile bermanfaat untuk merancang prioritas pengujian, siapa melakukan apa dan seberapa sering. 

Uji Navigasi, uji integrasi untuk aplikasi Web Pengguna Web menelusuri aplikasi Web dalam cara yang sangat mirip dengan pengunjung toko atau museum. Banyak alternatif lintasan dapat diambil pengunjung, banyak perhentian dapat dibuat, banyak benda diamati dan dipelajari, aktivitas pendaftaran anggota dimulai, atau ragam keputusan dibuat di tengah jalan. Proses navigasi dapat diprediksi, dalam arti setiap kategori pengunjung biasanya memiliki sejumlah tujuan tertentu. Proses navigasi dapat juga tak dapat diprediksi, dalam arti pengunjung dapat melakukan hal tak terduga terkait dengan tujuan semula setelah melihat dan mempelajari apa yang ia lihat. 

Tugas uji navigasi adalah : 

·      untuk meyakinkan bahwa mekanisme penelusuran Web untuk setiap kategori pengguna Web seluruhnya berfungsi dengan baik, 

·      untuk memvalidasi bahwa setiap navigation semantic unit (NSU) dapat dicapai oleh setiap kategori pengguna. navigasi diuji untuk meyakinkan bahwa masing-masing menjalankan fungsi yang diharapkan. 

Splaine dan Jaskiel menyarankan mekanisme navigasi berikut diuji: 

·         Navigation links : link internal, eksternal atau bagian halaman diuji. 

·         Redirects : boleh jadi resource yang diminta pengguna tidak ada, dihapus, atau namanya diubah, sehingga permintaan dialihkan ke halaman lain. Apakah redirect sudah berfungsi?

·         Bookmarks : ketika bookmark dibuat, apakah judul halaman dapat diambil. 

·         Frame and framesets : setiap frame berisi halaman Web khusus, framesets berisi banyak frame yang dapat muncul dalam saat yang sama. Hal itu yang perlu diuji, apakah benar isinya, benar layout dan ukurannya, bagaimana kinerja downloadnya, dan kompatibilitas browsernya. 

·         Site maps : link-link yang dipilih oleh pengguna apakah isi dan fungsinya sudah sesuai dengan yang diharapkan. 

·         internal search engines : bila ada ratusan dan ribuan halaman Web, apakah fasilitas pencarian internal sudah berfungsi. 

Beberapa jenis pengujian dapat dilakukan secara otomatis sementara yang lain harus dirancang dan dijalankan manual. Pengujian dilakukan untuk memastikan tidak ada kesalahan dalam mekanisme navigasi sebelum aplikasi Web online. 

Uji Semantik Navigasi Cachero mendefinisikan Navigation Semantic Unit (NSU) sebagai sekumpulan informasi dan struktur navigasi terkait yang bekerja sama memenuhi sejumlah kebutuhan pengguna terkait. Setiap NSU didefinisikan dengan sejumlah lintasan navigasi yang menghubungkan node-node navigasi (e.g., halaman- halaman Web, objek-objek isi, atau fungsionalitas). Setiap NSU mengijinkan seorang pengguna mencapai kebutuhan mereka yang didefinisikan dalam satu atau lebih use-case untuk setiap kategori pengguna. Uji Navigasi memeriksa setiap NSU untuk meyakinkan bahwa kebutuhan-kebutuhan ini dapat dicapai. 

Tim rekayasa Web perlu menjawab pertanyaan-pertanyaan berikut terkait dengan setiap NSU: 

-          apakah NSU dapat dicapai keseluruhan tanpa kesalahan? 

-          apakah setiap node dalam NSU dapat dicapai? 

-          jika ada banyak lintasan, apakah setiap lintasan berfungsi? apakah petunjuk navigasi benar? - adakah mekanisme ke halaman sebelumnya atau homepage? 

-          jika node navigasi sangat besar, apakah semua berfungsi? 

-          jika sebuah node menjalankan suatu fungsi, namun pengguna tidak memberi masukan yang lengkap, atau ada kesalahan lain apakah NSU yang tersisa dapat dilengkapi? 

-          jika navigasi ditengah jalan, pengguna memilih NSU lain, apakah pengguna dapat kembali ke tempat perhentian tadi dan memulai dari sana? 

-          apakah setiap node dapat dicapai dari site map, apakah nama-nama node dapat dipahami pengguna? 

-          jika sebuah node dapat diakses dari luar, apakah pengguna luar dapat ke halaman sebelum atau sesudahnya? 

-          apakah pengguna tahu sekarang ada di posisi mana? Uji navigasi sebaiknya dilakukan oleh sebanyak mungkin peserta yang berbeda.

Di tahap awal pengujian dilakukan oleh perekayasa Web, tahap berikutnya dilakukan oleh project stakeholder, dan tim penguji independent, dan terakhir pengguna nonteknik. Setiap orang perlu memeriksa navigasi aplikasi Web.