Rabu, 15 Juni 2022

Template dokumentasi Software dengan Black Box

Diposting oleh Diani Widyaningrum di 03.24 0 komentar

Nama: Diani Widyaningrum
NPM: 21382004P
Kelas: IF GAB EX 1
Matakuliah: Pengujian Perangkat Lunak

Pengertian Black Box Testing



Pengertian Black Box Testing

Black box testing juga dikenal sebagai pengujian kotak hitam  adalah pengujian yang dilakukan untuk memantau input dan output  perangkat lunak tanpa mengetahui struktur kode  perangkat lunak. Tes ini dijalankan pada akhir pembuatan perangkat lunak untuk memastikan bahwa perangkat lunak  berfungsi dengan baik. Penguji tidak perlu dapat menulis kode program untuk menjalankan pengujian. Siapapun dapat mengikuti tes ini.

Pengujian ini didasarkan pada detail aplikasi seperti tampilan aplikasi, fungsi-fungsi yang ada pada aplikasi, dan kesesuaian alur fungsi dengan bisnis proses yang diinginkan oleh customer. Pengujian ini tidak melihat dan menguji souce code program.

Contoh Template pengujian Black Box

Pengujian Black Box Metode yang digunakan dalam pengujian alpha adalah metode black box yang fokus pada persyaratan fungsional dari perangkat lunak yang dibangun. Berdasarkan rencana pengujian, maka dapat dilakukan pengujian black box pada prototype aplikasi peta hama dan penyakit ikan yang dijelaskan pada tabel dibawah ini.


Hasil dari pengujian dengan black box ada beberapa hasil pengujian yang belum sesuai dengan realisasi yang diharapkan sehingga dilakukan beberapa perbaikan sesuai dengan masalah yang didapatkan, berikut perbaikan yang dilakukan :

  1. Perbaikan pertama dilakukan pengecekan warna peta yang ada kemunculan warna yang sama. Langkah yang dilakukan untuk memperbaiki bug tersebut dengan mengecek logika warna dan menambahkan field status warna pada tabel untuk memudahkan pemberian warna sehingga warna muncul sesuai yang diharapkan.
  2. Perbaikan kedua dilakukan pengecekan fungsi tampilan yang tidak sesuai dengan perbedaan pada akses device layar yang berbeda. Langkah yang dilakukan dengan menambahkan style menggunakan “Bootstrap”. Bootstrap merupakan framework untuk membangun desain web secara responsive. Artinya, tampilan web yang dibuat oleh bootstrap akan menyesuaikan ukuran layar dari browser yang kita gunakan baik di desktop, tablet ataupun mobile- device.

 Setelah perbaikan dilakukan maka dilakukan pengujian ulang dengan black box. Pengujian hanya dilakukan pada fungsi yang belum sesuai yang diharapkan. Pengujian ulang black box pada prototype aplikasi pemetaan hama dan penyakit ikan yang dijelaskan pada tabel dibawah ini.


Alamat web Program studi, Fakultas, Universitas 

 http://ti.ftik.teknokrat.ac.idhttp://ftik.teknokrat.ac.idwww.teknokrat.ac.id 

Jumat, 22 April 2022

Strategi Pengujian Perangkat Lunak

Diposting oleh Diani Widyaningrum di 01.35 0 komentar

 Nama: Diani Widyaningrun

NPM: 21382004P
Kelas: IF GAB EX 1

 

Dalam proses rekayasa perangkat lunak, para developer perangkat lunak pertama-tama mencoba membuat dan mengembangkan perangkat lunak dari tahap abstraksi hingga implementasi, diikuti dengan pengujian perangkat lunak. Dalam pengujian perangkat lunak, aktor membuat satu set kasus uji atau skenario  yang diuji pada perangkat lunak yang sudah jadi. Proses pengujian perangkat lunak  berfokus pada sisi destruktif daripada sisi konstruktif, karena tujuannya adalah untuk menemukan bug perangkat lunak.

Definisi Strategi Pengujian Perangkat Lunak

Strategi pengujian perangkat lunak dapat diilustrasikan pada gambar berikut. Perangkat lunak dimulai dengan penentuan kebutuhan perangkat lunak, proses selanjutnya berupa perancangan, dan terakhir pengkodean. Strategi pengujian serupa, dimulai dengan pengujian unit  di tengah spiral di mana setiap modul / unit perangkat lunak yang diimplementasikan dalam kode sumber diuji. Kemudian jalankan tes integrasi. Fokus pengujian adalah pada desain dan konstruksi arsitektur perangkat lunak. Selain itu, tes validasi dilakukan dengan tujuan menguji kepatuhan dengan persyaratan perangkat lunak yang  ditentukan sebelumnya. Akhirnya, lingkaran luar spiral mencapai pengujian sistem, pengujian perangkat lunak dan seluruh sistem.

Tujuan Strategi Pengujian Perangkat Lunak

Pengujian perangkat lunak dilakukan dengan sasaran sebagai berikut ini :

1.      Pengujian adalah proses mengeksekusi program dengan tujuam untuk menemukan kerusakan maupun kesalahan pada program.

2.      Kasus atau skenario uji yang baik adalah yang mempunyai tingkat kemungkinan tinggi untuk menemukan kerusakan yang belum ditemukan.

3.      Pengujian dapat dikatakan berhasil apabila berhasil menemukan kerusakan yang belum ditemukan sebelumnya.

Dari sasaran diatas mengimplikasikan adanya perubahan cara pandang dimana pengujian yang berhasil adalah pengujian yang tidak menemukan kesalahan maupun kerusakan. Apabila pengujian telah selesai dilakukan, maka diharapkan ditemukan adanya kesalahan dalam perangkat lunak. Sekaligus sebagai benefit tambahan, pengujian dalam hal ini menunjukkan bahwa fungsi perangkat lunak bekerja dan berjalan sesuai dengan spesifikasi bahwa persyaratan kinerja telah terpenuhi.

Ketika melakukan pengujian, data perlu dikumpulkan supaya memberikan indikasi yang baik terhadap realibilitas perangkat lunak dan beberapa indikasi dari kualitas keseluruhan perangkat lunak. Namun, pengujian tidak dapat memperlihatkan ataupun memastikan bahwa perangkat lunak yang diuji tersebut tidak memiliki cacat sama sekali.

 

Langkah-Langkah Strategi Pengujian Perangkat Lunak

 

 

Apabila perangkat lunak dibuat untuk pelanggan makadapat dilakukan aceeptance test sehingga memungkinkan pelanggan untukmemvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yg lebih rinci danmembiasakan pelanggan memahami perangkat lunak yg telah dibuat.

1.      Pengujian Alpha

Dilakukan pada sisi pengembang oleh seorang pelanggan.Perangkat Lunak digunakan pada setting yg natural dgn pengembang “yg memandang”melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian

2.      Pengujian Beta

Dilakukan pada satu atau lebih pelanggan oleh pemakaiakhir perangkat lunak dalam lingkungan yg sebenarnya, pengembang biasanya tidakada pada pengujian ini. Pelanggan merekan semua masalah (real atau imajiner) ygditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.


Alamat web Program studi, Fakultas, Universitas 
 http://ti.ftik.teknokrat.ac.idhttp://ftik.teknokrat.ac.idwww.teknokrat.ac.id 


Selasa, 15 Maret 2022

Perancangan Pengujian

Diposting oleh Diani Widyaningrum di 05.35 0 komentar

 

Nama: Diani Widyaningrum
NPM: 21382004P
Kelas IF GAB EX 1

Pengertian Perancangan Pengujian

Perancangan pengujian adalah dokumen yang berisi definisi tujuan  pengujian, item untuk diuji, pendekatan untuk dilakukan, sumber daya yang diperlukan, dan poin yang harus dicapai dalam iterasi (atau proyek). Dengan kata lain, rencana pengujian dapat digambarkan sebagai rencana atau skenario untuk menjalankan pengujian, yang  dilakukan  oleh ahli atau pengguna biasa. Perancangan pengujian yang dibuat untuk menguji perangkat lunak yang sedang dikembangkan sangat penting. Perencanaan tersebut juga membantu memandu alur kerja tim dan mengelola jumlah  tanggung jawab yang dimiliki setiap individu dalam  tim pengembangan perangkat lunak. Setiap tim juga memiliki format strategi tes dan rencana penempatan yang berbeda. Perbedaan ini mungkin terkait dengan tujuan aplikasi, sumber daya yang terbatas, proses pembuatan, serta alat dan alat uji yang digunakan.

 

Tujuan Perancangan Pengujian

Secara umum tujuan dibuatnya Perancangan Pengujian adalah untuk memudahkan developer menjalankan test sehingga test yang mereka jalankan lebih jelas dan hasilnya lebih bermanfaat dan efisien. Tujuan lainnya adalah langkah-langkah yang harus diikuti, sumber daya yang dibutuhkan, dan item yang harus dibuat. Tujuan membuat rencana pengujian adalah untuk memudahkan pengembang menjalankan dan memperjelas pengujian yang sedang berjalan untuk hasil yang lebih berguna dan efisien. Pembuatan test case bertujuan untuk memastikan bahwa suatu sistem dapat dijalankan dengan baik sesuai dengan kebutuhan awal serta mampu memberikan respon ketika terdapat suatu masukan yang tidak valid. Test Case memiliki beberapa komponen seperti test case id, test case description, precondition, test step, expected result,actual result, serta status. Test Case bertindak sebagai titik awal dalam pelaksanaan pengujian sebuah sistem. Dari test case ini biasanya diketahui apakah fitur sistem berjalan normal atau tidak. 

Langkah-Langkah Melakukan Perancangan Pengujian Beserta Contoh test Case

Langkah-Langkah Melakukan Perancangan Pengujian dapat dibuat dengan mengikuti template pembuatan test plan, namun tidak  harus mengacu kepada template yang ada, walaupun pada garis besar inti bagian dari setiap test plan adalah sama. Berikut adalah penjelasan mengenai template Test Plan yang dikeluarkan oleh IEEE 829 (Institute of Electrical and Electronics Engineers) 

1. Test Plan Identifier

Test Plan Identifier adalah bagian untuk menjelaskan secara singkat mengenai objek yang akan di test. Bisa berupa penjelasan narasi atau berbentuk tabel dengan kategori kategori tertentu. Informasi yang dijelaskan dapat berupa sekilas mengenai subjek testing, nama orang yang bertanggung jawab terhadap testing, penyusun test plan , tanggal dibuat test plan dan tanggal revisi,dll.

 2.  Introduction

Pada bagian introduction dibuat untuk menjelaskan secara narasi, mengenai testing yang akan dilakukan terhadap suatu objek testing. Bagian Introduction dapat dibuat lebih rinci dengan menambahkan sub bab apabila perlu untuk dibuat. Contoh subbab yang dapat dibuat antara lain :

·         Purpose          :untuk menjelaskan tujuan testing secara spesifik.

·         Background   :latar belakang mengapa testing dilakukan.

·         Scope              :Sejauh mana testing dilakukan.

·         Definition and Acronyms : penjelasan mengenai singkatan dan isitlah yang ada di dalam dokumen test plan.

 

3.       3. Test Items

Bagian test item menjelaskan mengenai daftar komponen komponen dalam objek testing yang akan di test satu per satu. Contohnya :

Kemudian


4.      4. Features to be tested

Penjelasan dan daftar daftar fitur yang akan ditest di pada saat pelaksanaan testing dimulai. Dapat berupa Tabel Contohnya adalah :

 


5.      5. Features Not to be Tested

Menjelaskan mengenai fitur fitur apa saja yang ada di dalam objek testing namun, fitur tersebut tidak akan di test pada saat pelaksanaan testing dan disertakan penjelasan singkat mengapa fitur tersebut tidak di test pada saat testing. Contoh:



 

6.      6. Approach / Test Strategy

Bagian Approach adalah bagian yang digunakan untuk memberi deskirpsi mengenai Cara/approach yang dilakukan untuk melaksanakan testing dan disertakan dengan penjelasan mengenai approach yang digunakan.

Contohnya : Unit Testing menggunakan Black Box Testing dan atau White box testing beserta dengan penjelasan mengenai approach/ pendekatan yang dipakai.

 7.      Item Pass / Fail Criteria

Berisi tentang Kriteria- kriteria yang harus dipenuhi sebelum berlanjut ke fase berikutnya. Dan Kriteria Testing disebut gagal/fail. Contoh :

·         Jika suatu item di test sebanyak 10 kali dan 9 kali diantaranya berhasil namun ada 1 dimana benar benar gagal maka item tersebut dinyatakan sebagai gagal/ fail.

·         Jika hasil dari suatu item sama dengan hasil yang diharapkan maka item tersebut dinyatakan berhasil/pass.

·         System Crash akan dinyatakan sebagai fail,dsb.

8.      8. Suspension Criteria

Berisi tentang Spesifikasi Kriteria- kriteria yang dapat digunakan untuk menghentikan sementara kegiatan testing dan testing tersebut dapat dilanjutkan di waktu lain. Contoh:

Beberapa individual test cases dapat di suspend, di skip atau dikurangi jika test yang diperlukan(prerequisite test)  untuk individual test cases tersebut fail dan memerlukan perbaikan, apabila test cases individual tetap dilakukan meskipun prerequisite test yang diperlukan fail maka hanya akan membuang sumber daya /resources saja.

 9.      Test Deliverables

Menjelaskan Kegiatan testing beserta dengan pihak yang akan melaksanakan kegiatan/task tersebut. Contoh:

 10.  Testing Task

Menjelaskan Kegiatan testing beserta dengan pihak yang akan melaksanakan kegiatan/task tersebut. Contohnya:


11.  Enviromental Needs

Spesifikasi dan Perincian segala sesuatu yang dibutuhkan dan digunakan selama proses testing berjalan, bisa berupa hardware yaitu spesifikasi komputer atau hal lain selain hardware, misalnya izin akses seperti :

·         Membutuhkan akses ke dalam database untuk melaksanakan testing.

·         Membutuhkan akses ke dalam official website. 

1112. Responsibilities

Rincian Pihak pihak yang akan bertanggung jawab terhadap suatu kegiatan task di dalam serangkaian kegiatan testing yang akan dilaksanakan.

13.  Staffing and Training Needs

Secara garis besar menjelaskan bagaimana melakukan pendekatan untuk menentukan peran para staff di dalam proyek. Dan melakukan training apabila diperlukan untuk testing. Contoh :

Project Manager : Bertanggung jawab untuk mengatur implementasi total dari website.

Test Manager : Bertanggung jawab untuk mengembangkan master test plan , review test deliverables, manage test cycle dan melaporkan status kepada test manager.

Test Engineer : Bertanggung jawab untuk merancang desain dari test, membuat prosedur testing, membuat test data dan menjalankan test.

 14.  Schedule

Ada beberapa tujuan dalam membuat schedule di dalam test plan, antara lain :

1)      Merincikan Tolak ukur waktu pengerjaan Testing.

2)      Merincikan event transmittal item.

3)      Estimasi waktu yang dibutuhkan untuk setiap task.

4)      Menjadwalkan Testing task dan Test Milestone.

5)      Merincikan periode pemakaian Testing resources.

 15.  Risk and Contingencies

Digunakan untuk memastikan agar hasil testing tetap berkualitas dengan memeriksa beberapa bagian yang tidak termasuk di dalam control pengerjaan software, namun bagian tersebut dapat berdampak langsung terhadap proses. Contoh :

Sekuritas Layanan Ketika masuk di dalam software masih belum diperhatikan, ketika software sedang dijalankan, belum ada proteksi keamanan oleh software ini sendiri sehingga akan sangat mudah apabila diinjeksi oleh pihak yang tidak bertanggung jawab.

 16.  Approvals

Lembar persetujuan sebagai tanda bahwa seluruh tim/pimpinan telah menyetujui Test Plan yang telah dibuat.

 

 

Alamat web Program studi, Fakultas, Universitas 
 http://ti.ftik.teknokrat.ac.idhttp://ftik.teknokrat.ac.idwww.teknokrat.ac.id 

Selasa, 01 Maret 2022

SDLC DENGAN METODE WATERFALL

Diposting oleh Diani Widyaningrum di 04.34 0 komentar

Nama            : Diani Widyaningrum
NPM             : 21382004P
Kelas             : IF GAB EX        
Mata Kuliah  : Pengujian Perangkat Lunak

SDLC (System Development Life Cycle) atau Siklus Hidup Sistem adalah proses membuat dan memodifikasi sistem serta model dan metode yang digunakan untuk mengembangkan sistem ini dalam rekayasa sistem dan rekayasa perangkat lunak. Konsep ini umumnya mengacu pada komputer atau sistem informasi. SDLC juga merupakan pola  untuk mengembangkan sistem perangkat lunak dan terdiri dari fase perencanaan, analisis, desain, implementasi, pengujian, dan pemeliharaan. Dalam pengembangan perangkat lunak Angsyat, konsep SDLC mendasari banyak jenis metodologi pengembangan perangkat lunak. Metode ini menyediakan kerangka kerja untuk pembuatan sistem informasi, yaitu merencanakan dan mengendalikan proses pengembangan perangkat lunak.


Salah satu contohnya adalah metode Waterfall.

 Metode waterfall merupakan salah satu metode pengembangan perangkat lunak yang paling umum karena dianggap mudah untuk diimplementasikan. Keakraban dengan metode ini akan membantu Anda menerapkannya.

Definisi Waterfall


Secara harfiah, metode ini adalah proses top-down satu arah, yang berarti air terjun. Metode ini pertama kali dipresentasikan pada simposium Juni 1956 tentang metode pemrograman tingkat lanjut untuk komputer digital di Washington, DC. Hasil  simposium tersebut kemudian dicatat oleh US Maritime Research Center. Herbert D. Bennington adalah nama yang paling sering dikaitkan dengan pencipta teknik pemrograman ini, berdasarkan presentasinya pada simposium tahun 1956. Namun baru-baru ini, nama seorang ilmuwan komputer AS bernama Winston Walker-Royce juga muncul. Dia menulis disertasinya yang terkenal, "Mengelola Pengembangan Sistem Perangkat Lunak Skala Besar," pada tahun 1970, dan dia sendiri dianggap sebagai karya perintis dalam Waterfall Act. Nama "air terjun" tidak digunakan dalam karyanya. Pada tahun 1983, giliran Bennington untuk menerbitkan ulang makalahnya tahun 1956. Esai berjudul "Membuat Program Komputer Besar" mengulangi tahap pemrosesan menggunakan komposisi tugas komputasi. Namun, menurut Bennington, karakteristik top-down dari metode Waterfall bergantung pada penggunaan prototipe dan tidak diterapkan secara ketat pada saat itu.

Metode waterfall adalah salah satu pengembangan perangkat lunak yang berfokus pada aliran logis dari siklus hidup pengembangan perangkat lunak (SDLC). Metode ini telah menjadi metode tradisional dalam beberapa tahun terakhir, karena  beberapa metode yang lebih cepat telah muncul, baik dari segi jenis logika komputer maupun urutan proses. Namun, dalam beberapa dekade terakhir, proses ini telah menjadi desain proses yang umum di industri.

 

TAHAPAN METODE WATERFALL

1.      Requirements Definition

Pada tahap ini, pengembang perlu mengetahui semua informasi yang terkait dengan kebutuhan perangkat lunak, seperti Penggunaan perangkat lunak yang diinginkan oleh pengguna dan pembatasan perangkat lunak.  Informasi ini biasanya diperoleh dari wawancara, survei, atau diskusi. Informasi tersebut kemudian dianalisis untuk mendapatkan data yang lengkap tentang kebutuhan pengguna terhadap perangkat lunak yang sedang dikembangkan.

 

2.      System and Software Design

Level selanjutnya adalah desain. Perancangan dilakukan sebelum proses coding dimulai. Tujuannya adalah untuk mendapatkan gambaran lengkap tentang apa yang perlu dilakukan dan seperti apa sistem yang akan dibuat nantinya.  Ini juga mendefinisikan arsitektur sistem yang dibangun secara keseluruhan untuk membantu menentukan persyaratan perangkat keras dan sistem.

 

3.      Implementation and unit testing

Proses penulisan kode ada pada tahap ini. Pengembangan perangkat lunak dibagi menjadi modul-modul yang lebih kecil yang akan disatukan pada langkah berikutnya. Pada fase ini, modul yang dibuat juga diperiksa untuk menentukan apakah modul tersebut melakukan fungsi yang dimaksudkan.

 

4.      Integration and unit testing

Pada tahap keempat ini, modul yang telah dibuat sebelumnya digabungkan. Selanjutnya, pengujian dijalankan untuk menentukan apakah perangkat lunak tersebut kompatibel dengan desain yang diinginkan dan apakah masih terdapat kesalahan.

 

5.      Operation and Maintenance

Operasi dan pemeliharaan adalah tahap akhir dari metode pengembangan air terjun. Perangkat lunak yang telah selesai sekarang dijalankan atau dimanipulasi oleh pengguna.

               

Kelebihan dari Metode Waterfall

Berikut ini merupakan beberapa kelebihan yang dimiliki oleh metode waterfall, antara lain:

1.       Workflow yang jelas

Dengan menggunakan model SDLC jenis ini, mempunyai rangkaian alur kerja sistem yang jelas dan terukur. Masing – masing tim, memiliki tugas dan tanggung jawab sesuai dengan bidang keahliannya. Serta dapat menyelesaikan pekerjaan sesuai dengan alokasi waktu yang telah ditentukan sebelumnya.

2.       Hasil dokumentasi yang baik

Waterfall merupakan pendekatan yang sangat metodis, dimana setiap informasi akan tercatat dengan baik dan terdistribusi kepada setiap anggota tim secara cepat dan akurat. Dengan adanya dokumen, maka pekerjaan dari setiap tim akan menjadi lebih mudah, serta mengikuti setiap arahan dari dokumen tersebut.

3.       Dapat menghemat biaya

Kelebihan yang selanjutnya tentu saja dari segi resource dan biaya yang dikeluarkan oleh suatu perusahaan dengan menggunakan model ini. Jadi, dalam hal ini klien tidak dapat mencampuri urusan dari tim pengembang aplikasi. Sehingga pengeluaran biaya menjadi lebih sedikit. Berbeda dengan metode Agile, yang mana klien dapat memberikan masukan dan feedback kepada tim developer terkait dengan perubahan atau penambahan beberapa fitur. Sehingga perusahaan akan mengeluarkan biaya yang lebih besar daripada Waterfall.

4.       Digunakan untuk pengembangan software berskala besar

Metode ini dinilai sangat cocok untuk menjalankan pembuatan aplikasi berskala besar yang melibatkan banyak sumber daya manusia dan prosedur kerja yang kompleks. Akan tetapi, Model ini juga dapat digunakan untuk proyek berskala kecil dan menengah. Tentu saja disesuaikan dengan kondisi dan kebutuhan proyek yang diambil.

 

Kekurangan dari Metode Waterfall

Berikut ini terdapat beberapa kelemahan dari metode waterfall, diantaranya adalah sebagai berikut:

 

1.       Membutuhkan tim yang solid

Untuk menggunakan model SDLC ini, tentu saja membutuhkan dukungan dari setiap stakeholders yang ada. Setiap tim harus mempunyai kerja sama dan koordinasi yang baik. Dikarenakan, apabila salah satu tim tidak dapat menjalankan tugas dengan semestinya, maka akan sangat berpengaruh terhadap alur kerja tim yang lain.

2.       Masih kurangnya fleksibilitas

Semua tim dituntut untuk bekerja sesuai dengan arahan dan petunjuk yang telah ditetapkan di awal. Sehingga, klien tidak dapat mengeluarkan pendapat dan feedback kepada tim pengembang. Klien hanya dapat memberikan masukan pada tahap awal perancangan sistem perangkat lunak saja.

3.       Tidak dapat melihat gambaran sistem dengan jelas

Dengan model waterfall, customer tidak dapat melihat gambaran sistem secara jelas. Berbeda dengan model agile yang dapat terlihat dengan baik meskipun masih dalam proses pengembangan.

4.       Membutuhkan waktu yang lebih lama

Proses pengerjaan dengan menggunakan waterfall terbilang cukup lama jika dibandingkan dengan model SDLC yang lain. Karena, tahapan pengerjaan aplikasi yang dilakukan satu per satu membuat waktu yang dibutuhkan menjadi lebih lama. Sebagai contoh, tim developer tidak akan bisa melakukan proses coding jika tim designer belum menampilkan tampilan desain dari aplikasi.

 

Alamat web Program studi, Fakultas, Universitas 
 http://ti.ftik.teknokrat.ac.idhttp://ftik.teknokrat.ac.idwww.teknokrat.ac.id 

Sabtu, 15 Januari 2022

PERBEDAAN PROSES DAN THREAD

Diposting oleh Diani Widyaningrum di 03.08 0 komentar

 Nama            : Diani Widyaningrum
NPM             : 21382004P
Kelas             : IF 21 Dx        
Mata Kuliah  : Organisasi dan Arsitektur Komputer

Proses dan Thread memberikan layanan terbaik bagi komputer untuk melakukan banyak aktivitas sekaligus, tetapi perilakunya berbeda. Setiap program yang berjalan di komputer menggunakan setidaknya satu proses atau Thread. Proses dan Thread memungkinkan prosesor untuk beralih dengan lancar di antara banyak tugas sambil berbagi sumber daya komputer.  Oleh karena itu, tugas programmer adalah membangun prosesor berkinerja tinggi menggunakan Thread dan proses secara efisien. Eksekusi Thread dan proses tergantung pada sistem operasi yang tersedia.

 

PROSES

Sebuah proses biasanya merupakan serangkaian  tindakan untuk mencapai hasil tertentu. Namun, di dunia komputer, proses adalah  contoh menjalankan program komputer. Dengan kata lain, ini adalah konsep  kejadian tunggal dari program komputer yang sedang berjalan. Proses yang berjalan dalam biner berisi satu atau lebih Thread. Ada dua jenis proses, tergantung pada jumlah Thread yang terdapat dalam proses. Mereka adalah proses single-threaded dan proses multi-threaded. Sesuai dengan namanya, proses single-threaded adalah proses dengan hanya  satu thread. Oleh karena itu, utas ini adalah proses dan hanya  satu aktivitas yang dieksekusi. Proses multithreaded memiliki banyak utas dan beberapa aktivitas berjalan.

 Dua atau lebih proses dapat berkomunikasi satu sama lain melalui komunikasi antarproses. Namun, ini sangat sulit dan membutuhkan lebih banyak sumber daya. Saat membuat proses baru, programmer harus melakukan dua hal. Ini adalah replikasi dari proses induk dan alokasi memori dan sumber daya ke proses baru. Jadi itu benar-benar mahal.

 

THREAD

Dalam dunia IT, thread adalah eksekusi minimum dari instruksi dalam program komputer yang dapat dikelola secara mandiri sesuai  jadwal. Thread adalah jalur sederhana yang berjalan dalam suatu proses. Thread  adalah  proses yang kuat karena mereka dapat melakukan semua yang dapat dilakukan oleh suatu proses. Utas adalah proses yang sederhana dan membutuhkan lebih sedikit sumber daya. Utas dapat mulai  membaca dan menulis  variabel yang sama dan struktur data variabel yang sama. Utas dapat dengan mudah berkomunikasi antar utas.

 Hari ini, multithreading telah menjadi pendekatan alami untuk banyak masalah. Pekerjaan besar dibagi menjadi beberapa bagian, masing-masing terkait dengan unit eksekusi yang disebut utas. Ini hanya multithreading. Ini memerlukan perhatian pemrograman karena utas berbagi struktur data yang dimodifikasi oleh utas lain pada saat yang sama, dan utas berbagi ruang alamat yang sama. Satu keuntungan dibandingkan utas adalah  menyediakan cara yang efisien dan efektif untuk mencapai paralelisme. Utas adalah entitas yang tidak bergantung pada penjadwal, sehingga memungkinkan beberapa utas untuk berjalan pada beberapa prosesor  dapat meningkatkan throughput sistem.

PERBEDAAN PROSES DAN THREAD

  • ·         Proses sulit untuk membuat karena membutuhkan duplikasi proses induk dan alokasi memori sedangkan thread lebih mudah untuk membuat karena mereka tidak memerlukan ruang alamat yang terpisah.
  • ·         Thread digunakan untuk tugas-tugas sederhana, sementara proses yang digunakan untuk tugas-tugas yang berat-berat seperti pelaksanaan aplikasi.
  • ·         Proses tidak berbagi ruang alamat yang sama, namun thread dalam berbagi proses yang sama ruang alamat yang sama.
  • ·         Proses yang independen satu sama lain, tetapi thread saling bergantung karena mereka berbagi ruang alamat yang sama.
  • ·         Sebuah proses dapat terdiri dari beberapa thread.
  • ·         Karena thread berbagi ruang alamat yang sama, virtual memori hanya terkait dengan proses tapi tidak dengan thread. Tapi prosesor virtual yang berbeda dikaitkan dengan setiap thread.
  • ·         Setiap proses memiliki kode dan data sendiri sedangkan proses thread berbagi kode yang sama dan data.
  • ·         Setiap proses dimulai dengan thread utama, tapi dapat membuat thread tambahan jika diperlukan.
  • ·         Konteks beralih antara proses jauh lebih lambat dibandingkan konteks beralih antara thread dari proses yang sama.
  • ·         Thread dapat memiliki akses langsung ke segmen data, tetapi proses memiliki salinan sendiri segmen data mereka.
  • ·         roses memiliki overhead tapi tidak thread.

 Alamat web Program studi, Fakultas, Universitas 

 http://ti.ftik.teknokrat.ac.idhttp://ftik.teknokrat.ac.idwww.teknokrat.ac.id  

 

 

 

 

azul Copyright © 2010 Design by Ipietoon Blogger Template Graphic from Enakei