Pengujian Object Oriented

Tinggalkan komentar

Pengujian Perangkat Lunak Berorientasi Objek

Pengujian adalah suatu proses pengeksekusian program yang bertujuan untuk menemukan kesalahan (Berard, 1994). Pengujian sebaiknya menemukan kesalahan yang tidak disengaja dan pengujian dinyatakan sukses jika berhasil memperbaiki kesalahan tersebut. Selain itu, pengujian juga bertujuan untuk menunjukkan kesesuaian fungsi-fungsi perangkat lunak dengan spesifikasinya.

Pengujian dapat dikategorikan atas :

  1. Pengujian terhadap proses pengembangan sistem dan dokumendokumen pendukung. Proses berarti sejumlah aktivitas yang didukung oleh dokumen yang  mendeskripsikan aktivitas-aktivitas.
  2. Pengujian terhadap analisis dan model perancangan. Dalam sistem berorientasi objek, pengujian model analisis dan perancangan adalah hal yang sangat penting.
  3. Pengujian secara statik dan dinamik untuk implementasi. Tujuannya adalah mencari kesalahan sedini mungkin dalam proses, tetapi kesalahan dalam kode untuk  sistem yang besar dan kompleks tidak dapat dihindarkan. Pengujian statik merupakan inspeksi kode untuk menemukan kesalahan logic. Pengujian dinamik  merupakan eksekusi dengan data uji untuk menemukan kesalahan dalam kode

Perangkat lunak berorientasi objek berbeda dari perangkat lunak procedural (konvensional) dalam hal analisis, perancangan, struktur dan teknik-teknik  pengembangannya. Bahasa pemrograman berorientasi objek mempunyai ciri-ciri adanya pembungkusan (encapsulation), keanekaragaman (polymorphism), dan pewarisan (inheritance) yang membutuhkan dukungan pengujian tertentu. Fokus pengujian perangkat lunak berorientasi objek dimulai pada hasil analisisnya, dilanjutkan pada hasil perancangannya, dan diakhir pada hasil pemrogramannya (Rochimah, 1997). Model yang dihasilkan pada analisis dan perancangan harus diperiksa terutama dalam hal :

  1. Semantic correctness, yaitu kesesuaian model dengan domain permasalahan di dunia nyata. Jika model merefleksikan dunia nyata secara akurat, berarti model tersebut benar secara semantik, dan
  2. Consistency, yaitu kesesuaian kelas dengan objek turunannya maupun kesesuaian asosiasi kelas dengan kelas lainnya.

Model Uji (Test Model)

Berbagai model pengujian perangkat lunak berorientasi objek diusulkan oleh para peneliti. Setiap model mempunyai konstruksi atau aturan yang menjadi dasar dalam langkah-langkah pengujian. Dalam pengujian class, Siegel (1996) mendefinisikan tiga model fungsional yang digambarkan dalam struktur objek model pengujian dalam gambar 1 berikut ini :

State-Transition Model

Transisi dalam pengujian method (operasi) suatu class menunjukkan konsep perilaku class. Setiap method dalam class mengekspresikan beberapa elemen dari keseluruhan perilaku class. Dalam beberapa metoda perancangan berorientasi objek menggunakan model State-Transition untuk merepresentasikan perilaku  class. State (Status) suatu objek adalah kombinasi dari semua nilai atribut. Pada saat tertentu, status bersifat statik. Untuk model dinamik objek, perlu   ditambahkan transisi dari satu status ke status lainnya dan terjadilah suatu aksi. Model ‘transisi-status’ digambarkan dengan grafik, dimana simpul menyatakan status dan busur menyatakan transisi.
Boris Beizer memberikan beberapa aturan untuk pengecekan model “Transisi-status”, yaitu :

  • Verifikasi bahwa status telah merepresentasikan himpunan satus dengan benar;
  • Cel model untuk semua kemungkinan event suatu class, yaitu transisi dari setiap status untuk setiap method dalam class dan cek spesifikasi perancangannya;
  • Cek terhadap ketetapan satu tansisi untuk setiap kombinasi “eventstate”. Lakukan pengecekan, misal dengan representasi matriks sebagai kombinasi kemungkinan status dan event;
  • Cek status yang tidak terjangkau dan status mati, dimana pada status tersebut tidak ada lintasan atau transisi;
  • Cek aksi yang tidak benar(invalid), termasuk method (operasi) yang tidak ada atau method yang tidak sesuai dengan kebutuhan selama transisi.

Model “transisi-status” dapat mencakup keseluruhan perilaku class, sehingga lebih produktif dibanding dengan model lainnya, namun mempunyai beberapa kelemahan yaitu :

  1. Karena model dibentuk dari spesifikasi kebutuhan, bukan dari kode, mudah menyebabkan kesalahan sehingga perlu menguji model seperti halnya menguji kode.
  2. Karena model mencakup seluruh perilaku class dan superclass-nya, maka model menjadi kompleks. Namun pemakaian “transisi-status” secara hirarki dapat mengurangi kompleksitas tersebut.
  3. Model perilaku dapat mengakibatkan hilangnya kendali dan data yang salah. Oleh karena itu perlu adanya asumsi yang sama tentang perilaku class yang didasarkan pada kebutuhan dengan asumsi yang dibuat oleh pemrogram.

Rencana Uji (Test Plan)

Perancangan pengujian dilakukan dengan menyiapkan standarstandar yang harus dipenuhi dalam proses pengujian. Jika tidak sesuai dengan standar, maka proses pengujian telah menemukan kesalahan. Standar-standar tersebut harus terdokumentasi dengan baik. Kasus uji terdiri atas sekumpulan masukan untuk pengujian, sekumpulan kondisi yang harus dieksekusi dan hasil yang diharapkan berdasarkan tujuan yang telah ditetapkan.

Metoda perancangan kasus uji untuk perangkat lunak berorientasi objek yang diusulkan Berrard (dalam Pressman, 1997) adalah :

  1. Setiap kasus uji harus diidentifikasi secara unik dan secara eksplisit diasosiasikan dengan class yang diuji
  2. Tujuan pengujian harus ditetapkan dengan jelas
  3. Langkah-langkah pengujian harus dikembangkan untuk setiap kasus uji dan berisi :

a. Daftar status tertentu untuk objek yang diuji;
b. Daftar pesan (message) dan operasi yang akan dieksekusi sebagai akibat pengujian;
c. Daftar exception yang mungkin terjadi karena objek yang diuji;

d. Daftar kondisi eksternal (misalnya mengubah lingkungan eksternal perangkat lunak);
e. Informasi tambahan yang membantu pemahaman dan implementasi pengujian.

Teknik Pengujian Berbasis Status (State-based testing / SBT)

Pengujian berbasis status adalah bentuk implementasi pengujian class. Hal utama dalam SBT adalah pengujian nilai yang disimpan dalam suatu objek pada suatu saat. Nilai tersebut merepresentasikan status dari suatu objek. SBT juga melakukan validasi interaksi yang terjadi antara transisi dan status suatu objek. StateChart dapat digunakan untuk membantu dalam SBT.

Suatu status dapat didefinisikan sebagai nilai vektor [McG-93] : V = <a1, a2, …. An> ; dimana setiap ai merupakan nilai current dari atribut suatu objek. Himpunan status S suatu objek adalah produk kartesian dari himpunan status setiap atribut. Jika suatu objek mempunyai dua atribut, A dan B, dimana A dalah Boolean dan B = {-1,0.1}, maka himpunan status objek adalah {(T,-1), (T,0), (T,1), (F,-1), (F,0), (F,1)}.

Perancangan status harus didasarkan pada observasi perilaku objek. Model objek merepresentasikan kemungkinan perilaku objek, atribut dan hubungan antar objek dalam suatu sistem. Status suatu objek adalah kombinasi dari seluruh nilai-nilai atribut yang terkandung dalam objek. Sekelompok nilai-nilai tersebut  mempengaruhi perilaku (behavior) suatu objek. Perubahan status dapat terjadi sebagai akibat dari antar objek saling mempengaruhi. Hal ini disebut kejadian (event). Transisi merupakan perubahan dari satu status ke status lainnya yang disebabkan oleh suatu event. Suatu aksi (action) dapat terjadi selama terjadi transisi dari satu status ke status lainnya. Transisi sebagai konsep perilaku class. Setiap method dari suatu class mengekspresikan beberapa elemen secara keseluruhan perilaku class.

Pengujian berbasis status terhadap suatu class dapat dilihat method yang mempengaruhi status dalam empat kemungkinan berikut ini :
1. mengubah status objek ke status baru yang sesuai;
2. berpindah dari status tersebut;
3. mengubah status objek ke status yang tak terdefinisi, berarti terjadi kesalahan;
4. mengubah status objek ke status yang tidak sesuai, berarti terjadi kesalahan.

State Table (Tabel Status) merupakan suatu model yang digunakan untuk menggambarkan perilaku sistem. Tabel status disebut juga tabel
transisi status, direpresentasikan dengan baris dan kolom sebagai berikut :
– setiap baris menyatakan status.
– setiap kolom menyatakan kondisi masukan/transisi.
– kotak yang merupakan interseksi antara baris dan kolom menentukan status selanjutnya dan keluaran, jika ada.

Implementasi Pengujian Berbasis Status

Implementasi sistem pengujian ini dimulai dengan membangun model objek yang memperlihatkan struktur data statik dari sistem dunia nyatanya (gambar 2).

Program Uji
Program uji sebagai file program sumber ditulis dalam bahasa Pascal Objek. Program yang akan diuji tersebut telah benar secara leksik dan sintaks, yang berisi satu definisi class lengkap dengan atribut dan operasinya (method). Aturan sintaks program uji adalah :

<id_class>               = class
<definisi atribut>
<definisi operasi>
end;
{Definisi class turunan}

<id_class>              = class<id_superclass>

<definisi atribut>
<definisi operasi>

Data Uji dan Kasus Uji

Suatu kasus uji dapat dinotasikan dalam tiga tuple, yaitu (Tsai, 1997): <S1, t1 (..tn),S2> ; dimana S1 adalah current state (status awal) dan S2 adalah next state (status akhir) yang akan dicapai setelah mengeksekusitransisi t1 (atau urutan message, t1..tn). Dari kasus uji tersebut dapat
diidentifikasikan data uji.

Pada saat eksekusi pengujian dengan kasus uji, jika status hasil sama dengan status yang  seharusnya dicapai, berarti benar, sebaliknya terjadi kesalahan. Jika himpunan kasus uji dituliskan <status awal, transisi, ->, maka ini merupakan kasus khusus dan berarti data uji yang diberikan tidak valid.

Studi Kasus

Pada studi kasus pengujian berbasis status pada program berorientasi objek diberikan deskripsi singkat tentang struktur penyimpanan data dengan STACK berikut ini

Suatu class STACK (of array) untuk penyimpanan data dengan sifat operasi stack adalah first-in last-out. Kondisi-kondisi yang terjadi pada stack adalah kosong (empty), penuh (full) atau di antaranya (not full). Untuk mengakses data dalam stack, operasi-operasi yang ada adalah tambah data (PUSH/add) dan hapus data (POP/delete). Selain itu, untuk menyatakan bahwa stack penuh maka dapat dilihat dari ukuran stack yang diwakili oleh fungsi size yang bernilai Boolean.

Dari deskripsi tersebut dapat ditentukan status-status untuk class STACK, yaitu empty, notfull, dan full. Dengan keterangan ukuran STACK adalah :
– full ; jika ukuran stack = n (missal ditentukan n adalah ukuran stack maksimum)
– notfull ; jiks 0 < ukuran < n
– empty ; jika ukuran = n

Digunakan atribut tambahan count untuk menyatakan ukuran relatif data dalam stack.
Dari hasil rancangan class, dapat didefinisikan beberapa method, yaitu :

  • delete(integer) : untuk menghapus data dari stack
  • add(character,integer) : untuk menyatakan character apa yang ditambahkan pada stack dan berapa ukuran stack akibat penambahan data tersebut
  • initStack() : untuk menyatakan konstruksi objek stack
  • isEmpty() : untuk menyatakan apakah stack kosong atau tidak
  • size() : untuk mengecek ukuran stack

Dari deskripsi tersebut dapat dinyatakan dalam table contoh perubahan status berikut ini

Rencana Uji

1. Tujuan pengujian : menguji perilaku class STACK
2. Identifikasi Kasus Uji :

a. Daftar Status : Empty, NotFull, Full
b. Daftar Method : Add, delData, Sizes, isEmpty
c. Daftar Exception : <empty,delData,…>; <full,add,…>

Himpunan Kasus Uji

{<empty,sizes,empty>, <notfull,sizes,notfull>,<full,sizes,full>,<empty,isEmpty,empty>,<notfull,isEmpty,notfull>,<full,isEmpty,full>,<empty,delData,->,<notfull,delData,notfull>,
<notfull,delData,Empty>,<full,delData,notfull>,<empty,add,notfull>,<notfull,add,notfull>,<full,add,->}

Program Uji Stack

Unit programuji;
Const
Max = 10;
Type
TStack = class
Size : integer;
Tab_char : array[1..Max] of char;
Top : integer;
Procedure Constructor;
Procedure Add(x :string);
Procedure DelData(var x : string);
Function sizes : integer;
Function isEmpty : Boolean;

End;
Var
S : TStack;
Implementation
Procedure TStack.Constructor;
Begin
Size := max;
Top := 0;
End;
Procedure TStack.Add(x:string);
Begin
If top<size then
Begin
Top := top+1;
Tab_char[top]:=x;
End;
End;
Procedure TStack.DelData(var x:string);
Begin
If top>0 then
Begin
X := tab_char[top];
Top := top-1;
End;
End;
Function TStack.Sizes:integer;
Begin
Sizes := top;
End;
Function TStack.isEmpty : Boolean;
Begin
If top = 0 then
isEmpty := true
else
isEmpty := false;
end;
end.

Dari program uji tersebut terlihat bahwa :

  • nilai batas ukuran STACK adalah 10 (nilai batas inilah yang dijadikan atribut peubah status class)
  • instance yang diuji adalah S

Dari table hasil pengujian tersebut bahwa :

  1. jika pengujian benar, yaitu benar sintaks dan nilai atribut untuk uji (nilai status), maka hasil uji adalah OK;
  2. jika pengujian benar sintaks, namun salah nilai atribut, maka menghasilkan FAIL;
  3. jika terjadi kesalahan dalam pengisian data uji, maka proses pengujian gagal dan tidak menghasilkan tabel pengujian.

Kesalahan data uji tersebut meliputi

  • salah sintaks;
  • salah nama objek yang diuji;
  • salah nama method.

Penutup

Dari uraian di atas dapat dinyatakan bahwa pengujian berbasis status pada perangkat lunak berorientasi objek dilakukan dengan aturanaturan dalam representasi data uji yang didasarkan pada kasus uji. Perilaku status yang direpresentasikan dalam transisi status sangat membantu dalam mendeskripsikan perilaku class berdasarkan kondisi-kondisi dari nilai
instance-nya.

Pengujian berbasis status ini termasuk dalam pengujian unit dan semi statik-dinamik. Dinamik karena penguji dapat memberikan deskripsi transisi status sesuai dengan sistem yang akan diuji. Statik, karena implementasinya masih terbatas pada satu class program uji (yaitu STACK). Hal ini dikarenakan rumit dan kompleksnya interpretasi setiap method dengan nilai parameter yang akan diuji.

sumber :

Beizer, Boris. 1990, Software Testing Techniques, 2nd Edition, New York: Van Nostrand Reinhold

Berard, Edward V. 1994, Issues in the Testing of Object-Oriented Software, Berard Software Engineering Inc., article at http://www.toa.com.

Pacheco, Xavier. 1995, Borland Delphi Developer’s Guide, First Edition, New York: Sam Publishing

Pressman, Roger S. 1997, Software Engineering a Practitioner’s Approach, 4th edition, Singapore: Mc.Graw Hill Inc.

Robert V. Binder, 1995, Testing Object : State-based testing, The Approach for sistem testing, Chicago: Object Magazine, RSBC corp.

Rochimah, Siti. 1997, Penerapan Method Berarah Objek pada Kasus Penjadwalan, Bandung: Institut Teknologi Bandung

Rumbaugh, James, et al. 1991, Object Oriented Modelling and Design, New York:
Prentice-Hall International

Siegel, Shel. 1996, Object Oriented Software Testing an Hierarchical Approach, Canada: John Wiley & Sons Inc.

Tsai, et al. 1997, A Method for Automatic Class Testing (MACT) Object Oriented Program Using A State-based Testing Method, Fifth European Edinburg: Conf. Software Testing Analysis and  Review

http://www.paramadina.ac.id/downloads/Jurnal%20Universitas%20Paramadina/Jurnal%20UPM%20Vol-2%20No-2,%2001-2003/227-retno.pdf

google.com

macam-macam Jenis Pemeliharaan Sistem

Tinggalkan komentar

Definisi Pemeliharaan Sistem:

Suatu kombinasi dari berbagai tindakan yang dilakukan untuk menjaga suatu sistem dalam, atau memperbaikinya sampai, suatu kondisi yang bisa diterima. Pada bulan April 1970 didefinisikan sebuah istilah untuk Teknologi Pemeliharaan yang mencakup pengertian yang lebih luas dari pada pengertian Pemeliharaan diatas. Istilah ini adalah Teroteknologi.
Merupakan siklus terakhir dari SDLC yaitu dengan pemeriksaan periodik, audit dan permintaan pengguna akan menjadi source untuk melakukan perawatan system diseluruh masa hidup system.
Tujuan dari pemeliharaan system:
• Untuk memperpanjang usia kegunaan asset dari system tersebut. Hal ini terutama penting dinegara berkembang karena kurangnya sumber daya modal untuk penggantian. Dinegara-negara maju kadang-kadang lebih menguntungkan untuk ‘mengganti’ daripada ‘memelihara’.
• Untuk menjamin ketersediaan optimum peralatan
• Untuk menjamin kesiapan operasional dari seluruh peralatan yang diperlukan dalam keadaan darurat setiap waktu.
• Untuk menjamin keselamatan orang yang menggunakan sarana tersebut

Jenis Pemeliharaan

Pemeliharaan Korektif

Pemeliharaan korektif adalah bagian pemeliharaan sistem yang tidak begitu tinggi nilainya dan lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesahan yang ditemukan pada saat sistem berjalan.

Pemeliharaan Adaptif

Pemeliharaan adaptif dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau pemrosesan dan memenuhi persyaratan pemakai baru. Lingkungan tempat sistem beroperasi adalah dinamik, dengan demikian, sistem harus terus merespon perubahan persyaratan pemakai. Misalnya, Undang-Undang Perpajakan yang baru mungkin memerlukan suatu perubahan dalam kalkulasi pembayaran bersih. Umumnya pemeliharaan adatif ini baik dan tidak dapat dihindari.

Pemeliharaan Perfektif

Pemeliharaan penyempurnaan mempertinggi cara kerja atau maintainabilitas (kemampuan untuk dipelihara). Tindakan ini juga memungkinkan sistem untuk memenuhi persyaratan pemakai yang sebelumnya tidak dikenal.
Ketika membuat perubahan substansial modul apapun, petugas pemeliharaan juga menggunakan kesempatan untuk mengupgrade kode, mengganti cabang-cabang yang kadaluwarsa, memperbaiki kecerobohan, dan mengembangkan dokumentasi.
Sebagai contoh, kegiatan pemeliharaan ini dapat berbentuk perekayasaan ulang atau restrukturisasi perangkat lunak, penulisan ulang dokumentasi, pengubahan format dan isi laporan, penentuan logika pemrosesan yang lebih efisien, dan pengembangan efisiensi pengoperasian perangkat.

Pemeliharaan Preventif

Pemeliharaan Preventif terdiri atas inspeksi periodik dan pemeriksaan sistem untuk mengungkap dan mengantisipasi permasalahan.
Karena personil pemeliharaan sistem bekerja dalam sistem ini, mereka seringkali menemukan cacat-cacat (bukan kesalahan yang sebenarnya) yang menandakan permasalahan potensial. Sementara tidak memerlukan tindakan segera, cacat ini bila tidak dikoreksi di tingkat awal, jelas sekali akan mempengaruhi baik fungsi sistem maupun kemampuan untuk memeliharanya dalam waktu dekat.

Siklus Hidup Pemeliharaan Sistem (SMLC)

• Permintaan Perubahan
• Mengubah permohonan pemeliharaan menjadi suatu perubahan
• Menspesifikasi perubahan Membangun pengganti
• Menguji pengganti
• Melatih pengguna dan melakukan tes penerimaan
• Pengkonversian dan pelepasan ke operasi
• Mengupdate dokumentasi
• Melakukan pemeriksaan pascaimplementasi

Prosedur Pemeliharaan Sistem

SDLC dan SWDLC
Aplikasi yang professional dalam SDLC dan SWDLC dan teknik maupun perangkat modeling yang mendukungnya adalah hal-hal keseluruhan yang terbaik yang dapat seseorang lakukan untuk meningkatkan maintainabilitas system.

Definisi data standar
Trend ke arah sistem manajemen database relasional mendasari dorongan ke normalisasi data dan definisi data standart.

Bahasa pemrograman standar
Penggunaan bahasa pemrograman standart,misalnya C atau COBOL,akan mempermudah pekerjaan pemeliharaan.

Rancangan Moduler
Programer pemeliharaan dapat mengganti modul program jauh lebih mudah daripada jika ia berurusan dengan kedeluruhan program.

Modul yang dapat digunakan kembali
Modul biasa dari kode yang dapat digunakan kembali,dapat diakses oleh semua aplikasi yang memerlukannya.

Dokumentasi standar
Diperlukan system,pemakai,perangkat lunak dan dokumentasi operasiyang standart sehingga semua informasi yang diperlukan untuk beroperasi dan pemeliharaan aplikasi khusus akan tersedia.

Kontrol sentral
Semua program,dokumentasi dan data test seharusnya diinstal dalam penyimpanan pusat dari system CASE (Computer-Aided Softtware Engineering atau computer Assisted Software Enginering.

Mengelola Pemeliharaan Sistem
Tantangan mengelola pemeliharaan sistem adalah sama dengan tantangan mengelola usaha-usaha lain . Yaitu tantangan untuk mengelola manusia.

Prioritas untuk mengarahkan pemeliharaan sistem adalah mengumpulkan sekelompok pemelihara yang berkompeten dan termotivasi,serta menyuplai mereka dengan perngkat dan sumber-sumber untuk melakukan pemeliaraan sistem yang terjadwal maupun yang tidak terjadwal.

Pemeliharaan sistem terjadwal dapat dibuat menurut kalender atau diagram gantt.Pemeliharaan tidak terjadwal biasanya dilakukan atas inisiatif pemakai dan operator. Bagaimanapun juga pihak manajemen seharusnya menetapkan suatu cara untuk mengawali,merekam,dan mengevaluasi aktivitas pemeliharaan. Dengan melalui evaluasi kegiatan pemeliharaan,seorang manager akhirnya dapat mengoptimalkan program pemeliharaan sistem secara keseluruhan.

Cara pemeliharaan sistem

Pemeliharaan sistem

Semua informasi sewaktu-waktu berubah. Pemeliharaan sistem adalah kegiatan yang membuat perubahan ini.

A. Keperluan pemeliharaan sistem
Sistem perlu dipelihara karena beberapa hal, yaitu:
1. System memiliki kesalahan yang dulunya belum terdeteksi, seingga kesalahan-kesalahan system perlu diperbaiki
2. System mengalami perubahan-perubahan karena permintaan baru dari pemakai system
3. Sistem mengalami perubahan karena perubahan lingkungan luar (perubahan bisnis)
4. System perlu ditingkatkan

B. Jenis pemeliharaan system
Pemeliharaan system dapat digolongkan menjadi empat jenis:
1) Pemeliharaan korektif
Adalah bagian pemeliharaan system yang tidak begitu tinggi nilainya dan lebih membebani, karena pemeliharaan ini mengkoreksi kesalahan-kesalahan yang ditemukan pada saat system berjalan

2) Pemeliharaan adaptif
Dilakukan untuk menyesuaikan perubahan dalam lingkungan data atau pemrosesan dan memenuhi pesyaratan pemakai baru

3) Pemeliharaan perfektif
Mempertinggi cara kerja atau maintainabilitas (kemampuan untuk dipelihara). Tindakan ini juga memungkinkan system untuk memenuhi persyaratan pemakai yang sebelumnya tidak dikenal

4) Pemeliharaan preventif
Pemeliharaan preventif terdiri atas inspeksi periodik dan pemeriksaan system untuk mengungkap dan mengantisipasi permasalahan.

C. Prosedur untuk memeliharan system
System maintainability (kemampuan pemeliharaan system) adalah kapasitas personil pemeliharaan untuk melakukan pemeliharaan korektif, adaptif, prefektif, dan preventif.

Maintainabilitas (maintainability) system bertambah jika sistemnya dirancang agar mudah diubah. Aspek ini meliputi prosedur-prosedur berikut;
• SDLC (system development life cycle) dan SWDLC (software development life cycle)
• Definisi data standar
• Bahasa pemrograman standar
• Rancangan moduler
• Modul yang dapat digunakan kembali
• Dokumentasi standar
• Control sentral

Macam-macam Metode Penelitian Implementasi Sistem

Tinggalkan komentar

White Box Testing
Pengujian white box (glass box) adalah pengujian yang didasarkan pada pengecekan terhadap detil perancangan, menggunakan struktur kontrol dari desain program secara procedural untuk membagi pengujian ke dalam beberapa kasus pengujian. Penentuan kasus uji disesuaikan dengan struktur system, pengetahuan mengenai program digunakan untuk mengidentifikasikan kasus uji tambahan. Tujuan penggunaan white box untuk menguji semua statement program.

Penggunaan metode pengujian white box dilakukan untuk :
{1} memberikan jaminan bahwa semua jalur independen suatu modul digunakan minimal satu kali,
(2) menggunakan semua keputusan logis untuk semua kondisi true atau false,
(3) mengeksekusi semua perulangan pada batasan nilai dan operasional pada setiap kondisi., dan
(4) menggunakan struktur data internal untuk menjamin validitas
jalur keputusan.

Black Box Testing
Pengujian black box merupakan pendekatan komplementer dari teknik white box, karena pengujian black box diharapkan mampu mengungkap kelas kesalahan yang lebih luas dibandingkan teknik white box. Pengujian black box berfokus pada pengujian persyaratan fungsional perangkat lunak, untuk mendapatkan serangkaian kondisi input yang sesuai dengan persyaratan fungsional suatu program.

Yang Bertanggung Jawab

Teknisi dan System Administrator adalah seseorang yang harus memelihara (maintain) sistem komputer yang berbeda pengoperasian dan penanganannya beserta sarana pendukungnya.
Supervisor / direct personal adalah jabatan yang sangat strategis dalam suatu organisasi. Ia memiliki peran ganda. Di satu sisi ia adalah pemimpin yang harus membimbing, memotivasi dan mengendalikan karyawan. Di sisi lain, ia adalah wakil manajemen yang harus mempertanggungjawabkan semua tugas yang diberikan pada bagiannya. Karena itulah, seorang supervisor dituntut bukan hanya menguasai keterampilan teknis, tetapi juga keterampilan hubungan antar manusia. Training ini akan memberikan pengetahuan dan pedoman para supervisor dalam melaksanakan tugasnya.
General Manager atau Manajer umum adalah manajer yang memiliki tanggung jawab seluruh bagian / fungsional pada suatu perusahaan atau organisasi. Manajer umum memimpin beberapa unit bidang fungsi pekerjaan yang mengepalai beberapa atau seluruh manajer fungsional. Pada perusahaan yang berskala kecil mungkin cukup diperlukan satu orang manajer umum, sedangkan pada perusahaan atau organisasi yang berkaliber besar biasanya memiliki beberapa orang manajer umum yang bertanggung-jawab pada area tugas yang berbeda-beda.

User training plan
User training plan adalah pelatihan seluruh tenaga kerja untuk memenuhi kebutuhanya dalam melakukan sesuatu yang akan dikerjakan meliputi :
• Kelas
• Tutorial

Modul Pelatihan
Modul pelatihan ini akan membantu dalam mempelajari cara menggunakan sebuah perangkat lunak perencanaan/pemodelan meliputi :
• Materi Pelatihan
• Bantuan Pelatihan Computer-based

Topik untuk pelatihan

• Penggunaan System
• Konsep Umum Komputer
• Konsep Sistem Informasi
• Konsep Pengorganisasian
• Manajemen Sistem
• Instalasi Sistem

Metode Pelatihan
Metode pelatihan adalah proses untuk melatih pengguna dalam penggunaan proses bisnis baru dan fitur serta fungsi sistem baru dengan tujuan pengembangan kompetensi untuk menjamin keberhasilan operasional sistem baru. alur atau tata cara untuk menjelaskan mengapa metode pelatihan harus dipilih dengan hati-hati agar sesuai dengan tujuan dari satu sesi dan sesuai dengan profil pelatihan. Metoda pelatihan ini meliputi beberapa bagian seperti :

Resident expert adalah sebuah pelatihan yang membutuhkan tenaga ahli pada suatu bidang.

Computer-aided instruction adalah suatu tehnik pelatihan yang menggunakan instruksi-instruksi terprogram untuk melakukan suatu pelatihan perancangan dan perekaan dengan dibantu oleh computer dengan sistem yang terkomputansi.

Formal courses adalah pelatihan yang dilakukan dengan cara formal yang mencakup muatan proses pembelajaran yang bersifat teori dan diskusi yang dilaksanakan didalam sebuah pelatihan secara formal untuk beberapa orang sekaligus.

Software help components adalah sebuah perangkat lunak yang membantu mengeksekusi instruksi dalam sebuah program kemudian membantu mengambil bentuk instruksi dalam sebuah komponen. Komponen terpadu dalam sistem yang dirancang untuk pelatihan dan troubleshooting sistem.

Tutorials adalah layanan bantuan dalam sebuah pembelajaran untuk membantu kelancaran proses dalam sebuah pelatihan. berisi petunjuk dan latihan untuk pengajaran dan pengembangan kompetensi pengguna dalam penggunaan sistem. Petunjuk latihan dan tutorial ini dapat dilengkapi oleh basis data yang menggunakan data riil.

Interactive training manuals adalah bentuk kombinasi antara pelatihan tutorials dan Computer-aided instruction.

External sources, such as vendors adalah vendor penyedia jasa pelatihan kursus dan bentuk pelatihan lain.

Metodologi Umum Pelaksanaan Proyek Sistem Informasi
Pengembangan sebuah sistem informasi dalam sebuah perusahaan dilakukan dengan pendekatan manajemen proyek (project management). Lepas dari berbagai variasi proyek-proyek teknologi informasi yang ada – seperti pembuatan aplikasi, penerapan perangkat lunak, konstruksi infrastruktur jaringan, dan lain sebagainya – metodologi yang dipergunakan secara umum adalah sama. Setidak-tidaknya ada enam buah tahapan yang harus dilalui: perencanaan, analisa, desain, konstruksi, implementasi, dan pasca implementasi. Masing-masing konsultan atau para praktisi teknologi informasi biasanya memiliki variasinya masing-masing yang secara prinsip tidak lepas dari keenam langkah metodologi di atas.

Visi, Misi & Tujuan Hidup

Tinggalkan komentar

“Veni Vidi Vici” Pepatah yang sering diguakan dalam kepramukaan ketika saya masuk dalam jajaran anggota khusus pramuka dan bahasa ini berasal dari Julius Caesar, jendral dan konsul Romawi pada tahun 47 SM. Julius Caesar menggunakan kalimat ini dalam pesannya kepada senat Romawi menggambarkan kemenangannya atas Pharnaces II dari Pontus dalam  pertemuan Zela. Kalimat yang berarti “Saya datang, saya melihat, saya menang/menaklukkan mengandung arti kemenangan mudah dan mutlak.

tidak jauh berbeda dalam pandangan hidup saya “TIDAK ADA KATA GAGAL YANG ADA HANYA SUKSES ATAU BELAJAR” terkadang jika salah moto biasanya kita seringkali salah juga dalam mengartikan apa yang terjadi pada diri kita, misal : dalam moto kita “TAKE & GIVE” dalam moto tersebut kita diajarkan atau dipaksa bisa sebut saja begitu  untuk mengambil terlebih dahulu baru memberi, padahal secara logis apa yang ingin kita ambil jika kita tidak memiliki apapun, ini akan membuat anda selalu menyalahi aturan orang lain karena tidak sesuai dengan harapan anda. dari sini terbukti salah padahal jika kita membalik makna dari moto tersebut menjadi ” GIVE & TAKE” akan menjadi lebih indah memberi apapun yang kita miliki senantiasa akan menerima yang takan pernah terbayangkan dalam kehidupan itulah RAHASIA dari memberi maka kita akan bisa mengambil.

Tujuan hidup saya mudah menjadi orang baik yang bisa memberi untuk dapat menciptakan lebih banyak senyum yang terpancar dari sekeliling kita berbagi bersama dalam segala hal, ini tidaklah mudah karena dibutuhkan ketulusan jiwa untuk dapat menjalankannya. saya ingin anda berhapan baik untuk dapat membangunkan raksasa dalam diri saya dengan senyuman anda ketika membaca ini. terimakasih saya mengasimu ( Ho’oponopono)

saya tutup dengan sebuah motto

“Senang Jika Orang Lain Senang & Susah Jika Orang Lain Susah”

bukan sebaliknya ?????

ACM & IEEE

Tinggalkan komentar

Rekayasa Perangkat Lunak Kode Etik dan Profesional Praktek (Versi 5.2) seperti yang direkomendasikan oleh ACM / IEEE-CS Joint Task Force on Software Engineering Etika dan Profesional Praktek dan bersama-sama disetujui oleh ACM dan IEEE-CS sebagai standar untuk mengajar dan berlatih perangkat lunak rekayasa.

Versi kode singkat merangkum aspirasi pada tingkat tinggi abstraksi tersebut; klausa yang disertakan dalam versi lengkap memberikan contoh-contoh dan rincian tentang bagaimana aspirasi ini mengubah cara kita bertindak sebagai profesional rekayasa perangkat lunak. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code. Tanpa aspirasi, rincian bisa menjadi legalistik dan membosankan; tanpa rincian, aspirasi dapat menjadi tinggi terdengar tapi kosong; bersama-sama, aspirasi dan rincian bentuk kode kohesif.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. insinyur Perangkat Lunak harus berkomitmen untuk membuat analisis, spesifikasi, desain, pengembangan, pengujian dan pemeliharaan perangkat lunak dan dihormati profesi menguntungkan. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles: Sesuai dengan komitmen mereka untuk kesehatan, keselamatan dan kesejahteraan masyarakat, insinyur perangkat lunak harus mematuhi Delapan Prinsip berikut:

1. 1. PUBLIC – Software engineers shall act consistently with the public interest. UMUM – Software insinyur harus bertindak secara konsisten dengan kepentingan publik.

2. 2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest. KLIEN dan majikan – Software insinyur harus bertindak dengan cara yang adalah kepentingan terbaik klien mereka dan majikan yang konsisten dengan kepentingan publik.

3. 3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. PRODUK – Software insinyur harus memastikan bahwa produk dan modifikasi yang terkait dengan memenuhi standar profesional tertinggi mungkin.

4. 4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment. PENGHAKIMAN – Software insinyur harus mempertahankan integritas dan kemandirian dalam penilaian profesional mereka.

5. 5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance. MANAJEMEN – Rekayasa Perangkat Lunak manajer dan pemimpin harus berlangganan dan mempromosikan pendekatan etis kepada manajemen pengembangan perangkat lunak dan pemeliharaan.

6. 6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. PROFESI – Software insinyur harus memajukan integritas dan reputasi profesi yang konsisten dengan kepentingan publik.

7. 7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues. Kolega – Software engineer harus bersikap adil dan mendukung rekan-rekan mereka.

8. 8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. DIRI – Software insinyur harus berpartisipasi dalam belajar seumur hidup tentang praktek profesi mereka dan akan mempromosikan pendekatan etis untuk praktek profesi.

Software Engineering Code of Ethics and Professional Practice (Full Version) Rekayasa Perangkat Lunak Kode Etik dan Praktek Profesional (Full Version)

PREAMBLE MUKADIMAH

Computers have a central and growing role in commerce, industry, government, medicine, education, entertainment and society at large. Komputer memiliki peran sentral dan berkembang dalam perdagangan, industri, pemerintah, kedokteran, pendidikan, hiburan dan masyarakat pada umumnya. Software engineers are those who contribute by direct participation or by teaching, to the analysis, specification, design, development, certification, maintenance and testing of software systems. insinyur Perangkat Lunak adalah mereka yang berkontribusi dengan partisipasi langsung atau dengan mengajar, untuk analisis, spesifikasi, desain, pengembangan, sertifikasi, pemeliharaan dan pengujian sistem perangkat lunak. Because of their roles in developing software systems, software engineers have significant opportunities to do good or cause harm, to enable others to do good or cause harm, or to influence others to do good or cause harm. Karena peran mereka dalam mengembangkan sistem perangkat lunak, perangkat lunak insinyur memiliki kesempatan signifikan untuk melakukan atau menyebabkan kerugian yang baik, untuk memungkinkan orang lain untuk berbuat baik atau merugikan menyebabkan, atau untuk mempengaruhi orang lain untuk berbuat baik atau menyebabkan kerusakan. To ensure, as much as possible, that their efforts will be used for good, software engineers must commit themselves to making software engineering a beneficial and respected profession. Untuk memastikan, sebanyak mungkin, bahwa upaya mereka akan digunakan untuk kebaikan, insinyur perangkat lunak harus komitmen untuk membuat rekayasa perangkat lunak dan dihormati profesi menguntungkan. In accordance with that commitment, software engineers shall adhere to the following Code of Ethics and Professional Practice. Sesuai dengan komitmen itu, insinyur perangkat lunak harus mematuhi berikut Kode Etik dan Praktek Profesional.

The Code contains eight Principles related to the behavior of and decisions made by professional software engineers, including practitioners, educators, managers, supervisors and policy makers, as well as trainees and students of the profession. Kode berisi delapan Prinsip-prinsip yang berkaitan dengan perilaku dan keputusan dibuat oleh para insinyur perangkat lunak profesional, termasuk praktisi, pendidik, manajer, supervisor dan pembuat kebijakan, serta trainee dan mahasiswa profesi. The Principles identify the ethically responsible relationships in which individuals, groups, and organizations participate and the primary obligations within these relationships. Prinsip bertanggung jawab mengidentifikasi hubungan etis di mana individu-individu, kelompok, dan organisasi berpartisipasi dan kewajiban utama dalam hubungan ini. The Clauses of each Principle are illustrations of some of the obligations included in these relationships. The Klausul setiap Prinsip adalah ilustrasi dari beberapa kewajiban yang tercantum dalam hubungan ini. These obligations are founded in the software engineer’s humanity, in special care owed to people affected by the work of software engineers, and the unique elements of the practice of software engineering. Kewajiban ini didirikan pada perangkat lunak insinyur kemanusiaan, dalam perawatan khusus berutang kepada orang-orang dipengaruhi oleh karya insinyur perangkat lunak, dan unsur-unsur yang unik dari praktek rekayasa perangkat lunak. The Code prescribes these as obligations of anyone claiming to be or aspiring to be a software engineer. Kode mengatur kewajiban ini sebagai orang yang mengaku atau bercita-cita menjadi insinyur perangkat lunak.

It is not intended that the individual parts of the Code be used in isolation to justify errors of omission or commission. Hal ini tidak dimaksudkan bahwa bagian-bagian individual dari Kode digunakan dalam isolasi untuk membenarkan kesalahan dari kelalaian atau komisi. The list of Principles and Clauses is not exhaustive. Daftar Prinsip dan Klausa tidak lengkap. The Clauses should not be read as separating the acceptable from the unacceptable in professional conduct in all practical situations. The Klausul tidak harus dibaca sebagai memisahkan diterima dari diterima dalam perilaku profesional dalam semua situasi praktis. The Code is not a simple ethical algorithm that generates ethical decisions. Kode tidak etis algoritma sederhana yang menghasilkan keputusan yang etis. In some situations standards may be in tension with each other or with standards from other sources. Dalam beberapa situasi mungkin standar dalam ketegangan satu sama lain atau dengan standar dari sumber lain. These situations require the software engineer to use ethical judgment to act in a manner which is most consistent with the spirit of the Code of Ethics and Professional Practice, given the circumstances. Situasi-situasi ini memerlukan perangkat lunak insinyur menggunakan penilaian etika untuk bertindak dengan cara yang paling konsisten dengan semangat Kode Etik dan Praktek Profesional, mengingat keadaan.

Ethical tensions can best be addressed by thoughtful consideration of fundamental principles, rather than blind reliance on detailed regulations. ketegangan Etis terbaik dapat diatasi dengan pertimbangan bijaksana dari prinsip dasar, daripada ketergantungan buta pada peraturan rinci. These Principles should influence software engineers to consider broadly who is affected by their work; to examine if they and their colleagues are treating other human beings with due respect; to consider how the public, if reasonably well informed, would view their decisions; to analyze how the least empowered will be affected by their decisions; and to consider whether their acts would be judged worthy of the ideal professional working as a software engineer. Prinsip ini harus mempengaruhi insinyur perangkat lunak untuk mempertimbangkan luas yang dipengaruhi oleh pekerjaan mereka; untuk menguji apakah mereka dan rekan mereka memperlakukan manusia lain dengan hormat; untuk mempertimbangkan bagaimana masyarakat, jika informasi yang cukup baik, akan melihat keputusan mereka; untuk menganalisis bagaimana paling tidak diberdayakan akan dipengaruhi oleh keputusan mereka, dan untuk mempertimbangkan apakah tindakan mereka akan dinilai layak untuk bekerja profesional yang ideal sebagai insinyur perangkat lunak. In all these judgments concern for the health, safety and welfare of the public is primary; that is, the “Public Interest” is central to this Code. Dalam perhatian semua penilaian untuk kesehatan, keselamatan dan kesejahteraan masyarakat adalah utama, yaitu yang “Kepentingan Umum” adalah pusat dari Kode Etik ini.

The dynamic and demanding context of software engineering requires a code that is adaptable and relevant to new situations as they occur. Dinamika dan menuntut konteks rekayasa perangkat lunak memerlukan kode yang adaptif dan relevan dengan situasi baru yang terjadi. However, even in this generality, the Code provides support for software engineers and managers of software engineers who need to take positive action in a specific case by documenting the ethical stance of the profession. Namun, bahkan di umum ini, Kode menyediakan dukungan untuk perangkat lunak insinyur dan manajer dari insinyur perangkat lunak yang perlu mengambil tindakan positif dalam kasus tertentu dengan mendokumentasikan sikap etika profesi. The Code provides an ethical foundation to which individuals within teams and the team as a whole can appeal. Kode memberikan landasan etika yang individu dalam tim dan tim secara keseluruhan dapat naik banding. The Code helps to define those actions that are ethically improper to request of a software engineer or teams of software engineers. Kode membantu untuk menentukan tindakan-tindakan yang etis tidak layak untuk meminta seorang insinyur perangkat lunak atau tim insinyur perangkat lunak.

The Code is not simply for adjudicating the nature of questionable acts; it also has an important educational function. Kode ini tidak hanya untuk mengadili sifat tindakan dipertanyakan, tetapi juga memiliki fungsi pendidikan penting. As this Code expresses the consensus of the profession on ethical issues, it is a means to educate both the public and aspiring professionals about the ethical obligations of all software engineers. Karena ini mengungkapkan Kode konsensus para profesi pada isu-isu etis, itu adalah sarana untuk mendidik publik dan calon profesional tentang kewajiban etis dari semua insinyur perangkat lunak.
PRINCIPLES PRINSIP

Principle 1: PUBLIC Prinsip 1: UMUM

Software engineers shall act consistently with the public interest. insinyur Perangkat Lunak harus bertindak secara konsisten dengan kepentingan publik. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

1.01. 1,01. Accept full responsibility for their own work. Menerima tanggung jawab penuh atas pekerjaan mereka sendiri.

1.02. 1,02. Moderate the interests of the software engineer, the employer, the client and the users with the public good. Moderat kepentingan insinyur perangkat lunak, majikan, klien dan pengguna dengan barang publik.

1.03. 1,03. Approve software only if they have a well-founded belief that it is safe, meets specifications, passes appropriate tests, and does not diminish quality of life, diminish privacy or harm the environment. Menyetujui perangkat lunak hanya jika mereka memiliki keyakinan juga mendirikan bahwa itu aman, memenuhi spesifikasi, melewati tes yang sesuai, dan tidak mengurangi kualitas hidup, mengurangi privasi atau merugikan lingkungan. The ultimate effect of the work should be to the public good. Pengaruh utama dari pekerjaan sebaiknya pada kepentingan publik.

1.04. 1.04. Disclose to appropriate persons or authorities any actual or potential danger to the user, the public, or the environment, that they reasonably believe to be associated with software or related documents. Mengungkapkan kepada orang yang tepat atau otoritas apapun atau potensi bahaya yang sebenarnya bagi pengguna, masyarakat, atau lingkungan, bahwa mereka cukup yakin untuk dihubungkan dengan perangkat lunak atau dokumen terkait.

1.05. 1,05. Cooperate in efforts to address matters of grave public concern caused by software, its installation, maintenance, support or documentation. Bekerja sama dalam upaya untuk mengatasi masalah-masalah yang menjadi perhatian publik kubur disebabkan oleh perangkat lunak, instalasi, pemeliharaan, dukungan atau dokumentasi.

1.06. 1,06. Be fair and avoid deception in all statements, particularly public ones, concerning software or related documents, methods and tools. Adil dan menghindari penipuan dalam semua laporan, masyarakat yang terutama, tentang software atau dokumen-dokumen terkait, metode dan alat.

1.07. 1,07. Consider issues of physical disabilities, allocation of resources, economic disadvantage and other factors that can diminish access to the benefits of software. Pertimbangkan masalah cacat fisik, alokasi sumber daya, merugikan ekonomi dan faktor-faktor lain yang dapat mengurangi akses ke manfaat dari perangkat lunak.

1.08. 1,08. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline. Didorong untuk relawan keterampilan profesional untuk tujuan yang baik dan memberikan kontribusi untuk pendidikan masyarakat tentang disiplin.

Principle 2: CLIENT AND EMPLOYER Prinsip 2: CLIENT dan majikan

Software engineers shall act in a manner that is in the best interests of their client and employer, consistent with the public interest. insinyur Perangkat Lunak harus bertindak dengan cara yang adalah kepentingan terbaik klien mereka dan majikan, konsisten dengan kepentingan publik. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

2.01. 2,01. Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education. Menyediakan layanan di daerah mereka kompetensi, bersikap jujur dan terus terang mengenai keterbatasan pengalaman dan pendidikan.

2.02. 2,02. Not knowingly use software that is obtained or retained either illegally or unethically. Tidak sengaja menggunakan perangkat lunak yang diperoleh atau ditahan secara ilegal atau tidak etis baik.

2.03. 2,03. Use the property of a client or employer only in ways properly authorized, and with the client’s or employer’s knowledge and consent. Gunakan milik klien atau majikan hanya dengan cara yang benar resmi, dan dengan itu klien atau majikan pengetahuan dan persetujuan.

2.04. 2,04. Ensure that any document upon which they rely has been approved, when required, by someone authorized to approve it. Pastikan bahwa setiap dokumen yang di atasnya mereka bergantung telah disetujui, jika diperlukan, oleh seseorang yang berwenang untuk menyetujuinya.

2.05. 2,05. Keep private any confidential information gained in their professional work, where such confidentiality is consistent with the public interest and consistent with the law. Rahasiakan informasi rahasia yang diperoleh dalam pekerjaan profesional mereka, di mana kerahasiaan tersebut konsisten dengan kepentingan umum dan konsisten dengan hukum.

2.06. 2,06. Identify, document, collect evidence and report to the client or the employer promptly if, in their opinion, a project is likely to fail, to prove too expensive, to violate intellectual property law, or otherwise to be problematic. Mengidentifikasi, dokumen, mengumpulkan bukti dan melaporkan kepada klien atau majikan segera jika, menurut mereka, sebuah proyek akan gagal, untuk membuktikan terlalu mahal, untuk melanggar hukum kekayaan intelektual, atau menjadi problematis.

2.07. 2,07. Identify, document, and report significant issues of social concern, of which they are aware, in software or related documents, to the employer or the client. Mengidentifikasi, dokumen, dan laporan yang signifikan masalah-masalah sosial, dimana mereka sadar, dalam perangkat lunak atau dokumen terkait, dengan majikan atau klien.

2.08. 2,08. Accept no outside work detrimental to the work they perform for their primary employer. Terima tidak bekerja di luar merugikan pekerjaan yang mereka lakukan untuk majikan utama mereka.

2.09. 2,09. Promote no interest adverse to their employer or client, unless a higher ethical concern is being compromised; in that case, inform the employer or another appropriate authority of the ethical concern. Promosikan bunga tidak merugikan dengan majikan mereka atau klien, kecuali perhatian etis yang lebih tinggi berkompromi, dalam hal itu, menginformasikan majikan atau otoritas lain yang sesuai dari keprihatinan etis.

Principle 3: PRODUCT Prinsip 3: PRODUK

Software engineers shall ensure that their products and related modifications meet the highest professional standards possible. insinyur Perangkat Lunak harus memastikan bahwa produk dan modifikasi yang terkait dengan memenuhi standar profesional tertinggi mungkin. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

3.01. 3.01. Strive for high quality, acceptable cost and a reasonable schedule, ensuring significant tradeoffs are clear to and accepted by the employer and the client, and are available for consideration by the user and the public. Upaya untuk kualitas tinggi, biaya diterima dan jadwal yang masuk akal, memastikan timbal balik yang signifikan jelas dan diterima oleh majikan dan klien, dan tersedia untuk dipertimbangkan oleh pengguna dan masyarakat.

3.02. 3,02. Ensure proper and achievable goals and objectives for any project on which they work or propose. Pastikan yang tepat dan dapat dicapai tujuan dan sasaran untuk setiap proyek di mana mereka bekerja atau mengusulkan.

3.03. 3,03. Identify, define and address ethical, economic, cultural, legal and environmental issues related to work projects. Mengidentifikasi, menentukan dan alamat etis,, budaya, hukum dan lingkungan masalah ekonomi terkait dengan pekerjaan proyek.

3.04. 3,04. Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience. Pastikan bahwa mereka memenuhi syarat untuk setiap proyek di mana mereka bekerja atau mengusulkan untuk bekerja dengan kombinasi pendidikan dan pelatihan, dan pengalaman.

3.05. 3,05. Ensure an appropriate method is used for any project on which they work or propose to work. Pastikan metode yang tepat digunakan untuk setiap proyek di mana mereka bekerja atau mengusulkan untuk bekerja.

3.06. 3,06. Work to follow professional standards, when available, that are most appropriate for the task at hand, departing from these only when ethically or technically justified. Pekerjaan untuk mengikuti standar profesional, bila tersedia, yang paling sesuai untuk tugas di tangan, berangkat dari hanya bila etis atau dibenarkan secara teknis.

3.07. 3,07. Strive to fully understand the specifications for software on which they work. Upaya untuk memahami spesifikasi untuk perangkat lunak pada tempat mereka bekerja.

3.08. 3,08. Ensure that specifications for software on which they work have been well documented, satisfy the users’ requirements and have the appropriate approvals. Pastikan bahwa spesifikasi untuk perangkat lunak pada tempat mereka bekerja telah didokumentasikan dengan baik, pengguna memenuhi persyaratan dan memiliki persetujuan yang sesuai.

3.09. 3,09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates. Memastikan perkiraan realistis kuantitatif biaya, penjadwalan, personil, kualitas dan hasil pada setiap proyek di mana mereka bekerja atau mengusulkan untuk bekerja dan memberikan penilaian ketidakpastian dari perkiraan.

3.10. 3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work. Pastikan pengujian yang memadai, debugging, dan review perangkat lunak dan dokumen yang terkait dengan tempat mereka bekerja.

3.11. 3.11. Ensure adequate documentation, including significant problems discovered and solutions adopted, for any project on which they work. Pastikan dokumentasi yang memadai, termasuk masalah-masalah yang signifikan ditemukan dan solusi yang diadopsi, untuk setiap proyek di mana mereka bekerja.

3.12. 3.12. Work to develop software and related documents that respect the privacy of those who will be affected by that software. Bekerja untuk mengembangkan perangkat lunak dan dokumen-dokumen terkait yang menghormati privasi mereka yang akan terpengaruh oleh perangkat lunak tersebut.

3.13. 3,13. Be careful to use only accurate data derived by ethical and lawful means, and use it only in ways properly authorized. Hati-hati untuk hanya menggunakan data yang akurat yang diperoleh dan halal berarti etis, dan menggunakannya hanya dengan cara diotorisasi.

3.14. 3,14. Maintain the integrity of data, being sensitive to outdated or flawed occurrences. Menjaga integritas data, yang sensitif terhadap kejadian usang atau cacat.

3.15 Treat all forms of software maintenance with the same professionalism as new development. 3,15 Perlakukan semua bentuk perawatan perangkat lunak dengan profesionalisme yang sama dengan perkembangan baru.

Principle 4: JUDGMENT Prinsip 4: PENGHAKIMAN

Software engineers shall maintain integrity and independence in their professional judgment. insinyur Perangkat Lunak harus mempertahankan integritas dan kemandirian dalam penilaian profesional mereka. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

4.01. 4.01. Temper all technical judgments by the need to support and maintain human values. Marah semua teknis penilaian oleh kebutuhan untuk mendukung dan menjaga nilai-nilai kemanusiaan.

4.02 Only endorse documents either prepared under their supervision or within their areas of competence and with which they are in agreement. Hanya 4,02 mendukung dokumen baik disiapkan di bawah pengawasan atau dalam wilayah kompetensi mereka dan dengan yang mereka setuju.

4.03. 4,03. Maintain professional objectivity with respect to any software or related documents they are asked to evaluate. Menjaga objektivitas profesional sehubungan dengan perangkat lunak atau dokumen yang terkait mereka diminta untuk mengevaluasi.

4.04. 4,04. Not engage in deceptive financial practices such as bribery, double billing, or other improper financial practices. Tidak terlibat dalam praktik penipuan keuangan seperti penyuapan, penagihan ganda, atau praktik keuangan yang tidak benar.

4.05. 4,05. Disclose to all concerned parties those conflicts of interest that cannot reasonably be avoided or escaped. Mengungkapkan kepada semua pihak yang konflik kepentingan yang tidak dapat dihindari wajar atau melarikan diri.

4.06. 4,06. Refuse to participate, as members or advisors, in a private, governmental or professional body concerned with software related issues, in which they, their employers or their clients have undisclosed potential conflicts of interest. Menolak untuk berpartisipasi, sebagai anggota atau penasehat, dalam pemerintah, atau badan swasta profesional yang bersangkutan dengan masalah perangkat lunak terkait, di mana mereka, majikan mereka atau klien mereka memiliki potensi konflik kepentingan yang dirahasiakan.

Principle 5: MANAGEMENT Prinsip 5: MANAJEMEN

Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance . Rekayasa Perangkat Lunak manajer dan pemimpin harus berlangganan dan mempromosikan pendekatan etis kepada manajemen pengembangan perangkat lunak dan pemeliharaan. In particular, those managing or leading software engineers shall, as appropriate: Secara khusus, mereka yang mengelola atau insinyur perangkat lunak terkemuka, bila tepat:

5.01 Ensure good management for any project on which they work, including effective procedures for promotion of quality and reduction of risk. 5,01 Pastikan baik manajemen untuk setiap proyek di mana mereka bekerja, termasuk prosedur yang efektif untuk promosi kualitas dan pengurangan risiko.

5.02. 5,02. Ensure that software engineers are informed of standards before being held to them. Pastikan bahwa perangkat lunak insinyur informasi standar sebelum diadakan untuk mereka.

5.03. 5,03. Ensure that software engineers know the employer’s policies and procedures for protecting passwords, files and information that is confidential to the employer or confidential to others. Pastikan bahwa perangkat lunak insinyur tahu majikan kebijakan dan prosedur untuk melindungi password, file dan informasi yang bersifat rahasia kepada majikan atau rahasia kepada orang lain.

5.04. 5,04. Assign work only after taking into account appropriate contributions of education and experience tempered with a desire to further that education and experience. Menetapkan bekerja hanya setelah mempertimbangkan kontribusi yang sesuai pendidikan dan pengalaman temper dengan keinginan untuk lebih lanjut bahwa pendidikan dan pengalaman.

5.05. 5,05. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work, and provide an uncertainty assessment of these estimates. Memastikan perkiraan realistis kuantitatif biaya, penjadwalan, personil, kualitas dan hasil pada setiap proyek di mana mereka bekerja atau mengusulkan untuk bekerja, dan memberikan penilaian ketidakpastian dari perkiraan.

5.06. 5,06. Attract potential software engineers only by full and accurate description of the conditions of employment. Menarik insinyur perangkat lunak potensial hanya dengan deskripsi lengkap dan akurat tentang kondisi kerja.

5.07. 5,07. Offer fair and just remuneration. Penawaran adil remunerasi.

5.08. 5,08. Not unjustly prevent someone from taking a position for which that person is suitably qualified. Tidak adil mencegah seseorang dari mengambil posisi yang orang tersebut adalah kualifikasi yang sesuai.

5.09. 5,09. Ensure that there is a fair agreement concerning ownership of any software, processes, research, writing, or other intellectual property to which a software engineer has contributed. Pastikan bahwa ada kesepakatan yang adil mengenai kepemilikan perangkat lunak, proses, penelitian, menulis, atau kekayaan intelektual lain yang seorang insinyur perangkat lunak telah memberikan kontribusi.

5.10. 5.10. Provide for due process in hearing charges of violation of an employer’s policy or of this Code. Menyediakan untuk proses karena mendengar tuduhan pelanggaran kebijakan majikan atau dari Kode Etik ini.

5.11. 5.11. Not ask a software engineer to do anything inconsistent with this Code. Tidak meminta seorang insinyur perangkat lunak untuk melakukan sesuatu yang tidak sesuai dengan Kode Etik ini.

5.12. 5.12. Not punish anyone for expressing ethical concerns about a project. Tidak menghukum siapa saja untuk menyatakan keprihatinan etis tentang proyek.

Principle 6: PROFESSION Prinsip 6: PROFESI

Software engineers shall advance the integrity and reputation of the profession consistent with the public interest. insinyur Perangkat Lunak memajukan integritas dan reputasi profesi yang konsisten dengan kepentingan publik. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

6.01. 6,01. Help develop an organizational environment favorable to acting ethically. Membantu mengembangkan lingkungan organisasi yang kondusif untuk bertindak secara etis.

6.02. 6,02. Promote public knowledge of software engineering. Promosikan umum pengetahuan rekayasa perangkat lunak.

6.03. 6,03. Extend software engineering knowledge by appropriate participation in professional organizations, meetings and publications. Memperpanjang rekayasa perangkat lunak pengetahuan dengan partisipasi yang sesuai dalam organisasi profesional, pertemuan dan publikasi.

6.04. 6,04. Support, as members of a profession, other software engineers striving to follow this Code. Dukungan, sebagai anggota profesi, insinyur perangkat lunak lain berusaha untuk mematuhi Kode Etik ini.

6.05. 6,05. Not promote their own interest at the expense of the profession, client or employer. Tidak mempromosikan kepentingan mereka sendiri dengan mengorbankan profesi, klien atau majikan.

6.06. 6,06. Obey all laws governing their work, unless, in exceptional circumstances, such compliance is inconsistent with the public interest. Patuhi semua peraturan hukum yang mengatur pekerjaan mereka, kecuali, dalam keadaan luar biasa, kepatuhan tersebut tidak konsisten dengan kepentingan publik.

6.07. 6,07. Be accurate in stating the characteristics of software on which they work, avoiding not only false claims but also claims that might reasonably be supposed to be speculative, vacuous, deceptive, misleading, or doubtful. Jadilah akurat dalam menyatakan karakteristik software pada tempat mereka bekerja, menghindari klaim palsu tidak hanya tetapi juga menyatakan bahwa cukup mungkin seharusnya spekulatif, hampa, menipu, menyesatkan, atau ragu-ragu.

6.08. 6,08. Take responsibility for detecting, correcting, and reporting errors in software and associated documents on which they work. Ambil tanggung jawab untuk mendeteksi, memperbaiki, dan pelaporan kesalahan dalam perangkat lunak dan dokumen yang terkait pada tempat mereka bekerja.

6.09. 6,09. Ensure that clients, employers, and supervisors know of the software engineer’s commitment to this Code of ethics, and the subsequent ramifications of such commitment. Pastikan bahwa klien, majikan, dan supervisor mengetahui perangkat lunak insinyur komitmen untuk ini Kode etik, dan konsekuensi berikutnya dari komitmen tersebut.

6.10. 6,10. Avoid associations with businesses and organizations which are in conflict with this code. Hindari hubungan dengan bisnis dan organisasi yang bertentangan dengan kode ini.

6.11. 6,11. Recognize that violations of this Code are inconsistent with being a professional software engineer. Mengakui bahwa pelanggaran terhadap Kode Etik ini tidak konsisten dengan menjadi insinyur perangkat lunak profesional.

6.12. 6,12. Express concerns to the people involved when significant violations of this Code are detected unless this is impossible, counter-productive, or dangerous. Mengekspresikan keprihatinan kepada orang-orang yang terlibat ketika pelanggaran signifikan terhadap Kode Etik ini terdeteksi kecuali hal ini tidak mungkin, kontra-produktif, atau berbahaya.

6.13. 6,13. Report significant violations of this Code to appropriate authorities when it is clear that consultation with people involved in these significant violations is impossible, counter-productive or dangerous. signifikan Laporkan pelanggaran terhadap Kode Etik ini ke pihak yang berwenang ketika jelas bahwa konsultasi dengan orang-orang yang terlibat dalam pelanggaran yang signifikan adalah mustahil, kontra-produktif atau berbahaya.

Principle 7: COLLEAGUES Prinsip 7: Kolega

Software engineers shall be fair to and supportive of their colleagues. Software engineer harus bersikap adil dan mendukung rekan-rekan mereka. In particular, software engineers shall, as appropriate: Secara khusus, perangkat lunak insinyur harus, bila sesuai:

7.01. 7,01. Encourage colleagues to adhere to this Code. Mendorong rekan untuk mematuhi Kode Etik ini.

7.02. 7,02. Assist colleagues in professional development. Membantu rekan-rekan dalam pengembangan profesional.

7.03. 7,03. Credit fully the work of others and refrain from taking undue credit. Kredit sepenuhnya pekerjaan orang lain dan menahan diri dari mengambil kredit yang tidak semestinya.

7.04. 7,04. Review the work of others in an objective, candid, and properly-documented way. Meninjau pekerjaan orang lain dalam, jujur, dan benar-didokumentasikan secara obyektif.

7.05. 7,05. Give a fair hearing to the opinions, concerns, or complaints of a colleague. Berikan sidang adil bagi pendapat, keprihatinan, atau keluhan dari rekan kerja.

7.06. 7,06. Assist colleagues in being fully aware of current standard work practices including policies and procedures for protecting passwords, files and other confidential information, and security measures in general. Membantu rekan di sepenuhnya menyadari saat praktek kerja standar, termasuk kebijakan dan prosedur untuk melindungi password, file dan informasi rahasia lainnya, dan keamanan secara umum.

7.07. 7,07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague. Tidak adil campur tangan dalam karir kolega apapun, namun perhatian terhadap majikan, klien atau kepentingan umum dapat memaksa insinyur perangkat lunak, dengan itikad baik, mempertanyakan kompetensi kolega.

7.08. 7,08. In situations outside of their own areas of competence, call upon the opinions of other professionals who have competence in that area. Dalam situasi di luar wilayah kompetensi mereka sendiri, panggilan atas pendapat profesional lain yang memiliki kompetensi di bidang itu.

Principle 8: SELF Prinsip 8: DIRI

Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession. insinyur Perangkat Lunak akan berpartisipasi dalam belajar seumur hidup tentang praktek profesi mereka dan akan mempromosikan pendekatan etis untuk praktek profesi. In particular, software engineers shall continually endeavor to: Secara khusus, perangkat lunak insinyur harus terus berusaha untuk:

8.01. 8,01. Further their knowledge of developments in the analysis, specification, design, development, maintenance and testing of software and related documents, together with the management of the development process. Lebih lanjut pengetahuan mereka tentang perkembangan di analisis, spesifikasi, desain, pengembangan, pemeliharaan dan pengujian perangkat lunak dan dokumen yang berkaitan, bersama dengan pengelolaan proses pembangunan.

8.02. 8,02. Improve their ability to create safe, reliable, and useful quality software at reasonable cost and within a reasonable time. Meningkatkan kemampuan mereka untuk menciptakan, handal, dan berguna kualitas perangkat lunak yang aman dengan biaya murah dan dalam waktu yang wajar.

8.03. 8,03. Improve their ability to produce accurate, informative, and well-written documentation. Meningkatkan kemampuan mereka untuk memproduksi, informatif, dan juga ditulis dokumentasi yang akurat.

8.04. 8,04. Improve their understanding of the software and related documents on which they work and of the environment in which they will be used. Meningkatkan pemahaman mereka terhadap perangkat lunak dan dokumen yang terkait pada tempat mereka bekerja dan lingkungan di mana mereka akan digunakan.

8.05. 8,05. Improve their knowledge of relevant standards and the law governing the software and related documents on which they work. Meningkatkan pengetahuan mereka tentang standar dan hukum yang mengatur perangkat lunak dan dokumen yang terkait pada tempat mereka bekerja.

8.06 Improve their knowledge of this Code, its interpretation, and its application to their work. 8,06 Meningkatkan pengetahuan mereka tentang Pedoman ini, interpretasi, dan aplikasi untuk pekerjaan mereka.

8.07 Not give unfair treatment to anyone because of any irrelevant prejudices. 8,07 Tidak memberikan perlakuan tidak adil kepada siapapun karena prasangka apapun tidak relevan.

8.08. 8,08. Not influence others to undertake any action that involves a breach of this Code. Tidak mempengaruhi orang lain untuk melakukan tindakan yang melibatkan pelanggaran terhadap Kode Etik ini.

8.09. 8,09. Recognize that personal violations of this Code are inconsistent with being a professional software engineer. Mengakui bahwa pelanggaran pribadi standar ini konsisten dengan menjadi insinyur perangkat lunak profesional.

This Code was developed by the ACM/IEEE-CS joint task force on Software Engineering Ethics and Professional Practices (SEEPP): Kode ini dikembangkan oleh ACM / joint task force CS-IEEE pada Rekayasa Perangkat Lunak Etika dan Profesional Praktek (SEEPP):

Executive Committee: Donald Gotterbarn (Chair), Keith Miller and Simon Rogerson; Komite Eksekutif: Gotterbarn Donald (Ketua), Miller Keith dan Rogerson Simon;

Members: Steve Barber, Peter Barnes, Ilene Burnstein, Michael Davis, Amr El-Kadi, N. Ben Fairweather, Milton Fulghum, N. Jayaram, Tom Jewett, Mark Kanko, Ernie Kallman, Duncan Langford, Joyce Currie Little, Ed Mechler, Manuel J. Norman, Douglas Phillips, Peter Ron Prinzivalli, Patrick Sullivan, John Weckert, Vivian Weil, S. Weisband and Laurie Honour Werth. Anggota: Barber Steve, Barnes Peter, Burnstein Ilene, Michael Davis, Amr El-Kadi, N. Fairweather Ben, Fulghum Milton, N. Jayaram, Jewett Tom, Kankō Mark, Kallman Ernie, Langford Duncan, Currie Joyce Little, Mechler Ed, Manuel J. Norman, Douglas Phillips, Ron Prinzivalli Peter, Sullivan Patrick, Weckert John, Weil Vivian, S. Weisband dan Laurie Werth Mulia.

This Code may be published without permission as long as it is not changed in any way and it carries the copyright notice. Kode ini dapat diterbitkan tanpa izin sepanjang tidak diubah dengan cara apapun dan ia membawa pemberitahuan hak cipta. Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc. Copyright (c) 1999 oleh Asosiasi untuk Mesin Komputasi, Inc dan Institut untuk dan Listrik Engineers, Inc

Komite Standar IEEE 802 Selama 30 Tahun

Tinggalkan komentar

Bulan Maret ini, IEEE merayakan 30 tahun Komite Standar LAN/MAN 802. 30 tahun yang lalu, perusahaan seperti DEC, HP, IBM, Intel, dan Xerox mulai mengkristalkan gagasan membentuk sebuah komite komunikasi data di IEEE. Panitia resmi dibentuk pada Maret 1980 dengan Maris Graube dari Tektronix sebagai ketua. Jangkauan kerjanya meluas dalam tiga dekade, dari Kafe sampai Stasiun Luar Angkasa Internasional.

Graube beranjak dari standar lama untuk GPIB: IEEE 488. Ia mempertanyakan ketiadaan standar untuk komunikasi pada jarak yang lebih jauh. Maka komite-komite mulai bekerja. Standar pertama yang ditelurkan adalah Ethernet, yang lucunya waktu itu belum didukung Bob Metcalfe sebagai penemu Ethernet :) . Deretan standar lain untuk komunikasi data kemudian diluncurkan juga.

Dunia wireless menyusul. WiFi dan Bluetooth pun distandarkan sebagai bagian dari 802. Tapi tak semua selesai dengan baik dan cepat. Mengutip Nikolich — yang diangkat menjadi sejarawan komite, WiFi, atau standar Wireless Local Area Network 802.11 disusun dalam kerja keras sekitar 8 tahun sebelum dapat mengeluarkan standar dasar. Yang lebih parah barangkali UWB (ultra wideband) dari kelompok Wireless Personal Area Networks 802.15, yang melibatkan dua kubu yang bersaing — mereka gagal mencapai konsensus dan akhirnya menarik proyek mereka. Contoh lain yang tak pernah mencapai standardisasi adalah Manajemen Network.

IEEE 802 juga merupakan pengarah tren industri. Contohnya adalah standar WiFi Gigabit 802.11AD yang mendorong kalangan industri untuk menyiapkannya mulai mulai tahun 2013 dengan versi 6 GHz dan 60 GHz. Versi 6 GHz akan digunakan untuk aplikasi bisnis dan industri, karena sinyalnya kuat kuat, namun berbiaya lebih tinggi untuk pengkodean, penanganan gangguan, antena MIMO, dan modulasi multilevel. Sebaliknya, versi 60 GHz akan ideal digunakan konsumen dan kantor kecil karena mudah dibangun, namun sinyalnya terganggu oleh penyerapan oksigen — secara harfiah.

Aplikasi skala industri yang didorong oleh standar 802 juga meliputi 802.15 yang mendukung RFID dan smart grid, serta 802.16 yang menjadi standar WiMAX, WiMAX mobile, hingga WiMAX 4G. Yang juga menarik adalah 802.15.6 (Body Area Networks) dan 802.15.7 (Visible Light Communications). Yang pertama dapat digunakan untuk transceiver skala nano yang bisa ditelan pasien dalam bentuk pil; dan yang kedua untuk jaringan data tingkat tinggi dengan modulasi gelombang cahaya sebagai lapisan fisik yang akan beroperasi dalam rentang terahertz tanpa izin dan kebal terhadap gangguan listrik..

Dalam rangka Peringatan 30 Tahun Komite Standar IEEE 802, IEEE juga memberikan kesempatan terbatas bagi siapa pun untuk mengambil standar-standar dari keluarga IEEE 802 secara gratis. Silakan klik pada standar-standar di bawah untuk melakukan download gratis.

Standar-standar ini hanya dapat diunduh gratis selama masa Peringatan Ulang Tahun Komite Standar IEEE 802; dan keputusan ini dapat diubah setiap saat tanpa pemberitahuan. Silakan disebarkan demi makin majunya pengembangan sistem komunikasi dan informasi demi kemanusiaan. Selamat Ulang Tahun, Komite Standar IEEE 802!

sumber :

http://komunikasi.org/2010/03/30-tahun-komite-standar-ieee-802/

Pasal 27 Ayat 3 UU ITE :Dilarang Mengkritik (Curhat) Di Internet kecuali Orang Kaya?

Tinggalkan komentar

Sejak  Undang-Undang Tentang Informasi dan Tranksaksi Elektronik (UU-ITE) ditetapkan pada April 2008, saya merasa sedikit takut untuk menulis dan mengekspresikan apapun di blog ini. Apa yang dialami Ibu Prita Mulyasari bisa saja menimpa saya dan mungkin blogger yang lain. Saya pribadi mendukung gerakan untuk membela Ibu Prita atas nama kemanusiaan dan juga atas nama kebebasan berekspresi secara bertanggung jawab di internet.


Poster diambil dari blogombal.org.

Maklumlah terkadang saya suka mengeluh dan mengkritik suatu sistem atau hal yang terkesan tidak adil dan diskriminatif dalam blog saya. Maksudnya bukan untuk menghina, tetapi sekedar mengekspresikan pikiran dan perasaan saya semata agar orang lain tahu apa yang saya pikirkan dan rasakan. Bagus lagi jika terjadi diskusi sehingga masing-masing memiliki bahan evaluasi dan ide-ide untuk memperbaiki diri.

Namun apa yang dipikir pembaca tulisan saya, mungkin akan jauh berbeda dengan apa yang saya pikirkan. Apalagi karakter setiap orang berbeda-beda, ada yang mudah tersinggung, tapi ada juga yang pemaaf. Ada yang bisa menerima kritik, tapi ada juga yang anti kritik.

Tujuan ideal UU-ITE sebenarnya sangat baik yaitu  untuk mewujudkan suatu kondisi perilaku masyarakat yang santun, tertib dan teratur dalam menggunakan media elektronik, seperti internet. Namun jika UU-ITE ini justru membuat situasi dan kondisi masyarakat internet menjadi resah dan tidak nyaman. Bisa jadi ini merupakan satu indikator bahwa ada yang salah dari UU-ITE ini.

Kira-kira sebulan yang lalu, ada pengalaman dalam suatu milis yang saya ikuti. Seorang anggota milis menyebarkan berita tentang pencabutan IMB suatu tempat ibadah. Menurut saya sih, email ini masih wajar-wajar saja karena si pengirim mengeluhkan diskriminasi penguasa.

Namun beberapa anggota milis langsung menanggapi dengan ketus dan menganggapnya sebagai penistaan suatu agama dan pencemaran nama baik. Ujung-ujungnya si pengirim terancam dituntut melalui pasal 27 ayat 3 UU no 11 Tahun 2008 tentang  Informasi dan Transaksi Elektronik.

Bunyi Pasal 27 ayat 3  adalah sebagai berikut :

Setiap Orang dengan sengaja dan tanpa hak mendistribusikan dan/atau mentransmisikan dan/atau membuat dapat diaksesnya Informasi Elektronik dan/atau Dokumen Elektronik yang memiliki muatan penghinaan dan/atau pencemaran nama baik.

Sanksi pelanggaran pasal  disebutkan pada Pasal 45 ayat 1 adalah :

Setiap Orang yang memenuhi unsur sebagaimana dimaksud dalam Pasal 27 ayat (1), ayat (2), ayat (3), atau ayat (4) dipidana dengan pidana penjara paling lama 6 (enam) tahun dan/atau denda paling banyak Rp1.000.000.000,00 (satu miliar rupiah).

Menurut saya, seperti halnya porno dan tidak porno, maka merasa terhina atau tidak terhina juga berada dalam domain yang sama yaitu subjektifitas. Tiap orang tentunya akan berbeda-beda merasakannya. Tergantung apakah orang tersebut pendendam atau pemaaf, dan penerima kritik atau antikritik.

Pasal penghinaan atau pencemaran nama baik bisa dikatakan pasal karet, pasal yang dapat ditarik-tarik seenaknya. Orang hukum mungkin mengatakannya sebagai hal yang tidak memiliki kepastian hukum. Belum lagi pasal ini ternyata juga sudah dibahas dalam undang-undang yang lain yaitu KUHP Pasal 311.

Saling tindih suatu aturan yang sama membuat UU menjadi tidak efisien. Semoga saja ini bukan karena para pembuatnya memiliki OCD (Obsessive Compulsive Disorder). Lalu masalah hukuman yang begitu berat yaitu 1 milyar rupiah. Apa dasarnya? Mungkin bagi orang kaya, 1 M itu bisa dibayar. Tapi buat 15,42 % (Data BPS, Maret 2008) orang miskin di Indonesia, belum lagi ditambah orang tingkat ekonomi menengah kebawah. Uang 1 milyar itu sangatlah tidak terjangkau.

Apa mungkin pesan implisit  dari Pasal 27 ayat 3 UU-ITE ini adalah orang miskin dilarang menghina dan mengkritik di internet?

Baiklah, Saya masih miskin saat ini. Saya tidak punya uang 1 milyar untuk menebus harga diri seseorang/sesuatu yang merasa dicemarkan dalam tulisan-tulisan saya. Saya juga tidak cukup punya waktu untuk kehilangan 6 tahun dipenjara karena unfinished tasks saya sudah sangat banyak.

Namun apa mau dikata, UU-ITE telah ditetapkan bahkan Majelis Hakim Mahkamah Konstitusi menolak pengujian pasal 27 ayat 3 UU ITE. Sekali lagi orang miskin (yang tak punya 1 milyar) mungkin tinggal menunggu belas kasihan sistem keadilan yang berpihak pada para penguasa uang.

sumber :

http://blog.kenz.or.id/2009/06/05/pasal-27-ayat-3-uu-ite-orang-miskin-dilarang-mengkritik-di-internet.html

Older Entries