Regulasi industri perangkat lunak [ditutup]


85

Setiap beberapa tahun seseorang mengusulkan regulasi yang lebih ketat untuk industri perangkat lunak.

Ini artikel IEEE telah mendapatkan perhatian akhir-akhir ini pada subjek.

Jika para insinyur perangkat lunak yang menulis program-program untuk sistem yang mengekspos risiko fisik atau finansial publik tahu bahwa mereka akan diuji berdasarkan kompetensinya, maka pemikiran itu akan mengurangi cacat dan kegagalan dalam kode — dan mungkin menyelamatkan beberapa nyawa dalam tawar-menawar.

Saya skeptis tentang nilai dan kelebihan ini. Menurut saya, itu seperti perampasan tanah oleh orang-orang yang mengusulkannya.

Kutipan yang menentukan bagi saya adalah:

Ujian akan menguji pengetahuan dasar, bukan penguasaan materi pelajaran

karena kegagalan besar (misalnya THERAC-25 ) tampaknya menjadi masalah yang rumit dan halus yang "pengetahuan dasar" tidak akan pernah cukup untuk mencegahnya.

Mengabaikan masalah lokal (seperti perlindungan yang ada dari Insinyur judul di beberapa yurisdiksi):

Tujuannya mulia - hindari dukun / dukun 1 dan buat perbedaan itu lebih jelas bagi mereka yang membeli perangkat lunak mereka. Dapatkah regulasi yang lebih ketat dari industri perangkat lunak dapat mencapai tujuan aslinya?

1 Persis seperti peraturan profesi medis dimaksudkan untuk dilakukan.


3
Saya harap Thomas Owens menanggapi ini karena saya tahu dia memiliki jawaban yang sempurna.
maple_shaft

3
Seperti halnya saya ingin mendengar apa yang orang katakan tentang topik ini, sepertinya pertanyaan diskusi bagi saya cocok untuk format Tanya Jawab Stack Exchange.
PersonalNexus

12
Terus terang, saya mendukung amandemen konstitusi yang menciptakan pemisahan teknologi dan negara mengingat betapa Pemerintah tidak tahu apa-apa ketika mengatur teknologi (lihat juga SOPA)
JohnFx

3
Bagaimana suatu industri dapat diatur ketika ia berubah setiap hari?
Jon Raynor

4
Tidak banyak situasi "cukup baik" yang kemudian menyebabkan bug sering kesalahan manajemen / pemasaran mengatakan: "KAPAL KAPAL KAPAL!"
Aren

Jawaban:


105

Pandangan bahwa insinyur perangkat lunak dapat dimasukkan ke dalam klasifikasi yang sama dengan profesional medis atau akuntan adalah pandangan bodoh tentang "masalah" yang mereka coba pecahkan. Sebelum saya memberikan pendapat saya tentang ini, mari kita uraikan beberapa argumen Mr. Thornton, yang adalah Wakil Ketua badan pengawas yang mengusulkan undang-undang ini.

"Sama seperti praktisi profesional seperti dokter, akuntan, dan perawat dilisensikan, demikian juga insinyur perangkat lunak," kata Thornton. " Publik harus dapat mengandalkan semacam kredensial ketika memilih kontraktor untuk menulis perangkat lunak."

- Mitch Thornton, Wakil Ketua Lisensi dan Registrasi IEEE

Ini terdengar sangat masuk akal di permukaan. Lagi pula, ada industri lain yang mungkin dianggap "berhasil diatur". Maksud saya, dengan berhasil mengatur, bahwa jika Anda mencari dokter di halaman kuning, Anda dapat yakin bahwa ia telah menjalani pendidikan menyeluruh di universitas terakreditasi dan telah lulus sejumlah ujian dan menyelesaikan residensi. Berikut adalah beberapa industri "berhasil diatur" (dalam hal tenaga profesional).

  • Pengacara
  • Dokter
  • Akuntan
  • Insinyur nuklir
  • Tukang cukur ( tidak bercanda )

Lagipula, Anda tidak ingin sembarang orang mengeluarkan tumor itu dari pankreas Anda atau mengerjakan sentrifugal dari pembangkit listrik tenaga nuklir di luar kota. Mengapa tidak ada pembatasan serupa untuk insinyur perangkat lunak?

Hanya mereka yang programnya dapat “membahayakan kesehatan atau keselamatan publik, keamanan, properti, atau ekonomi yang perlu diuji,”

Ini adalah pernyataan yang kabur dan terbuka untuk interpretasi dan penerapan liberal. Saya dapat mengajukan argumen bahwa Apple Inc. atau Facebook adalah bagian integral dari ekonomi Amerika - apakah saya memerlukan lisensi khusus dari pemerintah untuk menulis kode untuk mereka sekarang, karena jika saya menurunkan situs dengan ketidakmampuan saya, saya dapat merusak Amerika. ekonomi? Di pekerjaan terakhir saya, saya tidak sengaja mematikan lift biji-bijian dengan pekerjaan cron yang salah - mungkin membahayakan persediaan makanan.

Saya menyadari bahwa saya menghindari maksud sebenarnya dari proposal ini. Gagasan di baliknya adalah untuk memastikan bahwa orang yang menulis kode untuk Sistem Pengereman Anti-Lock pada Jetta baru Anda kompeten dan berlisensi dengan benar untuk menulis kode untuk Sistem Pengereman Anti-Lock. Di Jetta Anda.

Inilah masalahnya: rekayasa perangkat lunak di zaman sekarang mencakup segalanya dan Anda tidak mungkin menguji setiap disiplin ilmu. Aturan bisnis terlalu spesifik, dan terlalu beragam dari disiplin ke disiplin. Insinyur hipotetis kami yang menulis kode untuk sistem ABS pada Jetta mungkin menulis sesuatu yang sama sekali berbeda untuk sistem ABS pada Elantra. Apakah dia harus mendapatkan sertifikasi ulang?

Dan bagaimana jika Anda menguji semua disiplin turunan ini? Anggaplah sejenak bahwa setiap programmer yang bekerja di situs web e-commerce akan disertifikasi sebagai programmer yang mampu e-commerce. Begitu? Apakah ini tiba-tiba berarti bahwa programmer dan perusahaan ini akan benar - benar melakukan validasi yang diperlukan dan membangun kepatuhan PCI? Bahkan jika mereka melakukannya - gangguan masih akan terjadi.

Ujian akan menguji pengetahuan dasar, bukan penguasaan materi pelajaran, menurut Mitch Thornton, wakil ketua Komite Lisensi dan Registrasi IEEE.

Inilah kickernya. Kurangnya pengetahuan dasar tidak pernah menjadi masalah. Rem anti-lock saya tidak berhenti bekerja karena Chuck sedang berjuang dengan konsep struktur kontrol. Mereka gagal karena ada kesalahan di mana ABS dimatikan karena kekurangan listrik di lampu ekor dan daya tidak dialihkan dengan benar. Atau sesuatu.

Perangkat lunak pompa insulin yang saya tulis tidak berhenti bekerja karena saya tidak memiliki keterampilan dasar; itu berhenti karena ada bug dalam bagaimana saya mengukur pengeluaran insulin ketika rekan satu tim Eropa saya menggunakan sistem metrik dan saya tidak.

Itu adalah sesuatu yang dapat Anda perhitungkan dalam pengembangan, tetapi Anda tidak akan pernah bisa menguji dengan sertifikasi .

Inilah yang akan terjadi jika "sertifikasi" ini berlaku: jumlah insiden akan tetap sama persis. Mengapa? Karena itu tidak melakukan apa pun untuk menghilangkan masalah sebenarnya dari kegagalan ABS atau pompa insulin.


33
+1 jawaban bagus. Saya terutama suka: "Kurangnya pengetahuan dasar tidak pernah menjadi masalah."
Jonathan Henson

4
Jawaban yang bagus tetapi hanya memperhitungkan rekayasa perangkat lunak dari perspektif pemrogram. Rekayasa perangkat lunak yang sebenarnya pada kenyataannya merupakan upaya tim yang melibatkan banyak keahlian dan disiplin, analis bisnis, jaminan kualitas, manajemen proyek, dll ... Insiden kemungkinan besar merupakan hasil dari pemrograman yang buruk karena mereka kehilangan persyaratan, persyaratan yang disalahpahami, persyaratan yang disalahpahami, proyek yang dikelola dengan buruk dan pengujian yang tidak tepat. Apakah tes OP menyebutkan semua itu? Tentu saja bukan karena itu untuk programmer.
maple_shaft

3
Saya akan menambahkan bahwa saya pikir seluruh ide IEEE adalah sampah untuk memulai. Yang harus dilakukan pemerintah adalah tugasnya untuk memperbaiki masalah. Membuat setiap orang bertanggung jawab atas segala kerusakan yang mereka alami pada siapa pun. Ini saja akan mengatasi masalah
Jonathan Henson

16
Tidak setuju dengan "Kurangnya pengetahuan dasar tidak pernah menjadi masalah." Bahkan sering adalah masalah. Seberapa sering programmer baru (atau yang lebih tua) mengabaikan sanitasi input? Verifikasi kasus sudut? Untuk sistem fisik, saya mungkin membaca sensor. Itu bisa hidup atau mati. Bagaimana dengan yang rusak? Bagaimana perangkat lunak saya tahu? Lalu apa yang harus saya lakukan? Anggap itu hidup atau mati? Hal-hal "mendasar" semacam ini memang sering menjadi masalah.
sdg

3
@ JonathanHenson Kemudian lagi, saya menganggap sebagian besar contoh injeksi SQL persis seperti itu - tidak memiliki pengetahuan dasar ... tapi secara keseluruhan, posting yang bagus. +1.
Jeff Ferland

72

Betapa beruntungnya bahwa tidak ada yang meninggal karena peraturan medis, tidak ada yang terluka oleh penipuan berkat peraturan keuangan, tidak ada yang memiliki rumah mereka disita berkat peraturan perumahan, tidak ada yang pernah mendapat potongan rambut yang buruk berkat peraturan tukang cukur, dan tidak ada pesawat yang pernah jatuh. terima kasih untuk regulasi pesawat.

Jelas, kehadiran regulasi tidak menyiratkan tidak adanya cacat atau kegagalan. Sebaliknya, adanya kekurangan atau kegagalan tidak menyiratkan regulasi akan mencegah kelemahan atau kegagalan tersebut. Insinyur perangkat lunak sudah sangat diatur sebagai anggota dari masing-masing industri yang kritis terhadap keselamatan, dan di luar industri tersebut hanya ada sedikit kebutuhan.


10
+1 untuk "Insinyur perangkat lunak sudah sangat diatur sebagai anggota dari masing-masing industri yang kritis terhadap keselamatan, dan di luar industri tersebut hanya ada sedikit kebutuhan"
Trevor Boyd Smith

3
Saya tidak suka nada sinis dari jawaban ini. Apakah Anda mengatakan tidak perlu ada regulasi, karena regulasi tidak pernah menyelesaikan masalah?
Fred Foo

8
Saya katakan di luar titik tertentu, lebih banyak regulasi jarang memecahkan lebih banyak masalah. Mengamanatkan praktik pengujian perangkat lunak tertentu pada mesin yang mampu membunuh orang masuk akal. Menekan satu lagi ujian sertifikasi keterampilan dasar pada akhir program gelar hanya menambah birokrasi.
Karl Bielefeldt

2
@ Larsman Saya setuju dengan Karl, jika pemerintah berurusan dengan rudal atau sesuatu yang menurutnya standar tinggi harus diamanatkan, biarkan mereka menyewa programmer dan insinyur mereka sendiri sesuai dengan standar apa pun yang mereka pilih. Sektor swasta seharusnya tidak menghasilkan uang dari risiko publik - itu adalah fasisme. Industri swasta seharusnya tidak dibiarkan membahayakan publik. Orang yang tahu apa yang paling mereka butuhkan, adalah orang yang mengambil risiko. Biarkan mereka menangani urusan mereka sendiri. Dan ya, saya tahu Lockheed-Martin dan sejenisnya melakukan ini. Tapi mereka seharusnya tidak diizinkan.
Jonathan Henson

3
Mempertimbangkan jumlah perusahaan besar yang kehilangan rincian kartu kredit selama kurang lebih setahun terakhir, saya akan mengatakan bahwa tidak ada peraturan mandiri yang memuaskan. Anda bisa berargumen bahwa sistem ini tidak kritis terhadap kehidupan - tetapi efeknya pada kantong orang bisa sama sulitnya dengan insiden ini.
HorusKol

32

Saya percaya, sejarah telah menunjukkan, bahwa perbedaan antara pengrajin yang sangat baik dan yang biasa-biasa saja tidak dapat diuji dengan segala bentuk ukuran objektif. Pengetahuan dasar tidak menjadikan seorang programmer, hikmat, dan pengalaman yang hebat - yang tidak dapat benar-benar diajarkan atau diukur secara obyektif - tentang bagaimana menerapkan pengetahuan dasar itu.

Juga, tes ini biasanya hanya berakhir menjadi beberapa kata buzz dan prosedur konkret dan gagal mengukur sesuatu yang substantif untuk memulai.

Jika industri perangkat lunak ingin mengembangkan semacam guild, itu akan menjadi cara yang jauh lebih baik untuk mendekati masalah ini. Namun, sentralisasi hanya memiliki kekuatan untuk menghancurkan keunggulan: bukan menciptakannya.

Selain itu, masalah yang berusaha dicegah oleh tindakan ini mungkin tidak akan tertangkap oleh tes. Ngomong-ngomong, saya juga akan senang melihat @ThomasOwens menjawab yang ini.

Apa yang akan menjadi peran pemerintah, paling tidak dari ideologi Amerika, adalah meminta perusahaan perangkat lunak bertanggung jawab atas kerusakan properti yang disebabkan oleh perangkat lunak mereka yang cacat atau tidak aman. Ini akan mendorong perusahaan untuk menegakkan standar mereka sendiri dan mengambil tanggung jawab pribadi untuk masalah ini. Ini selalu merupakan solusi yang lebih baik, dan tidak mengandung pemerintah yang terpusat melampaui batas-batasnya.

Memperbarui

Aku sedang memikirkan ini lebih dari tadi malam sambil minum bir atau sepuluh.

Semua yang mengatur bidang medis lakukan adalah untuk memusnahkan semua paradigma kecuali satu. Jika tujuan mereka adalah untuk menyingkirkan dokter-dokter homeopati dan naturopatik, yang oleh orang baik disebut sebagai "dukun" maka peraturan tersebut berhasil. Namun, saya tidak setuju bahwa hal seperti itu menguntungkan bagi siapa pun kecuali orang yang menulis undang-undang. Pikirkan tentang apa yang telah dilakukan ini. Ini telah menaikkan biaya perawatan kesehatan ke tingkat yang tidak berkelanjutan, sangat meningkatkan tingkat kewajiban bagi MDs, dan telah menghilangkan semua kekuatan pilihan konsumen dan penentuan nasib sendiri dari pasar. Tidak ada lagi pasar untuk ide-ide dalam komunitas medis, dan perawatan baru dan cara berpikir tentang obat sekarang ditekan. Selain itu, penghalang untuk masuk ke lapangan sangat tinggi dan akibatnya, kami memiliki kekurangan MD yang baik s. Selain itu, badan pengatur memiliki kekuatan untuk mengendalikan pasokan dokter sehingga mereka pada gilirannya dapat mengendalikan harga yang dibayar dokter.

Memang ada beberapa keuntungan yang kami terima dari peraturan medis, tetapi biayanya terlalu tinggi.

Hal yang sama ini akan terjadi pada insinyur perangkat lunak jika peraturan tersebut disahkan. Saya bisa melihatnya sekarang, badan pengatur akan memutuskan bahwa pemrograman berorientasi objek adalah satu-satunya standar desain dan programmer fungsional dan prosedural tidak akan diizinkan untuk berlatih. Kemudian mereka akan mulai memberi tahu kita bahwa kita tidak diizinkan mengelola ingatan kita sendiri karena itu tidak aman. Kemudian mereka akan menjejalkan JAVA dan C # ke bawah semua tenggorokan kita dan memberi tahu kita bahwa kita harus menggunakannya sementara Oracle dan Microsoft menjadi lebih gemuk dan lebih bahagia. Inovasi akan terhambat dan kreativitas akan dilarang. Microsoft dan Google akan menulis undang-undang tersebut, sehingga aturan pasar akan ditekuk menuju profitabilitas mereka sendiri dan terhadap kesejahteraan sosial.

Juga, izinkan saya mengingatkan semua orang bahwa komputer dimulai sebagai hobi dan upaya akademis. Selain perang Unix tahun 80-an dan awal 90-an kita memiliki sistem operasi gratis, kompiler gratis, program gratis, dan seterusnya ... Ini akan berakhir dengan cepat. Dunia yang oleh Richard Stallman, Linus Torvalds, dan Dennis Richtie diwariskan kepada kita secara bertahap akan memudar dari keberadaan.

Singkatnya, apakah saya bosan harus bersaing dengan "Saya akan mendesain situs CMS wordpress seharga $ 25 per jam" atau "aplikasi iPhone apa pun seharga $ 500" kawan? Tidak juga kenapa? Karena saya sangat pandai dalam apa yang saya lakukan dan pelanggan yang saya inginkan bersedia membayar untuk keunggulan. Ketika saya mengambil proyek secara mandiri atau di tempat kerja saya, saya mengambil risiko atas pekerjaan saya di atas kepala dan reputasi saya sendiri. Itu akan mengikuti saya ke mana pun saya pergi. Juga, kebanyakan orang tahu bahwa mereka mendapatkan apa yang mereka bayar. Seorang pelanggan yang hanya bersedia membayar saya dengan harga yang mereka bayar kepada orang halaman mereka akan menjadi mimpi buruk untuk berurusan dengan anyways. Jika pemerintah memperbaiki struktur hukum untuk memaksa penyedia layanan mengkompensasi kerusakan mereka, maka akan ada sangat sedikit programmer buruk yang masih memiliki pekerjaan di lapangan.

Ngomong-ngomong, kita masih memiliki dokter yang buruk, satu-satunya perbedaan adalah bahwa ada sangat sedikit kekuatan untuk mengeluarkan mereka dari pasar. Jika mereka harus mengambil tanggung jawab atas tindakan mereka sendiri, mereka akan keluar dari bisnis sebelum mereka memiliki kesempatan lain untuk mendatangkan malapetaka yang tidak kompeten pada pelanggan mereka.


8
Meskipun saya setuju dengan dorongan umum dari pernyataan Anda, saya menemukan bagian yang paling menarik dari itu adalah kalimat pertama. Anda mencirikan pengembangan perangkat lunak sebagai kerajinan , yang merupakan masalah sebenarnya . Seseorang tidak membuat jembatan gantung; satu insinyur jembatan gantung untuk memastikan kemanjuran dan keamanannya. Insinyur perangkat lunak masih bertindak lebih mirip perajin daripada insinyur, apa pun gelar yang Anda berikan kepada mereka.
Eric Lippert

4
@ Jonathan Henson: Mereka tentu saja tidak, secara umum. Banyak toko yang mendapat skor nol pada Tes Joel. ( joelonsoftware.com/articles/fog0000000043.html ) Seperti apakah seharusnya tidak , itu keputusan bisnis, bukan keputusan moral. Semua hal itu membutuhkan uang: banyak dan banyak uang. Jika Anda membangun sistem kontrol pesawat terbang, itu menguntungkan dalam jangka panjang untuk mengambil biaya-biaya tersebut; jika Anda membuat game facebook, mungkin tidak.
Eric Lippert

1
Tidak, cap arsitek sama bagusnya dengan cap PE. Saya tentu akan mengatakan bahwa kita perlu memasukkan banyak hal yang saat ini disebut disiplin teknik, seperti halnya arsitek. Arsitektur masih dianggap sebagai lebih dari sebuah kerajinan sekalipun. Ngomong-ngomong, teknik mungkin juga kerajinan, jadi aku mungkin hanya memotong-motong kata-kata daripada tidak ada.
Jonathan Henson

1
@Andy, saya kira kita harus meminta pertukaran stack untuk mengubah judul situs ini menjadi softwareengineers.stackexchange.com :)
Jonathan Henson

1
@JonathanHenson Tersinggung? Tidak mungkin, jangan khawatir! :) Saya seharusnya membuatnya sedikit lebih jelas bahwa saya memposting tautan itu hanya karena anehnya kebetulan untuk komentar Anda.
yannis

23

Silicon Valley News - 31 Juni 2015

Horor: Programmer yang tidak bersertifikat membuat program dibatalkan

"Aku tidak akan pernah bisa berlari lagi", kata korban. Polisi sedang menyelidiki.

Pidana: Lisensi Dr H. Acker Jr. dicabut karena penggunaan pointer yang salah dan upaya untuk membaca dari file sistem

Advokat mengatakan akan ada banding ke Mahkamah Agung.

Pengumuman: Pemrogram Cobol yang tersertifikasi pada tahun 1975 harus melakukan sertifikasi ulang paling lambat tahun 2025

Sertifikasi dikonfirmasi IEEE tidak berubah sejak itu.

Iklan: Sertifikasi dijamin dengan Magic Knowledge Stuffers, Inc

Ajari diri Anda pemrograman dalam 21 hari.


Saya mencoba untuk memutuskan apakah ini jawaban penuh insite atau komentar lucu. (Keduanya mungkin?)
Lyndon White

@Oxinabox tanggal 31 Juni adalah lucu
nyamuk

"Ajari dirimu pemrograman dalam 10 hari!" hehe
BЈовић

20

Ada beberapa cara berbeda untuk menerapkan peraturan pada profesi apa pun - badan pengetahuan yang terdefinisi dengan baik, kode etik, akreditasi program pendidikan, sertifikasi dan perizinan, dan masyarakat profesional yang mendukung pengembangan profesional serta aspek-aspek lain dari suatu profesi. Rekayasa perangkat lunak memiliki sebagian besar karakteristik profesi.

Saya suka menganggapnya dimulai dengan Badan Rekayasa Perangkat Lunak (SWEBOK) dan Kode Etik dan Praktek Profesional Rekayasa Perangkat Lunak . Meskipun penerimaan umum terhadap ini masih sangat terbatas, saya pikir mereka berfungsi sebagai dasar yang baik untuk mengidentifikasi jenis hal yang seseorang mengidentifikasi diri mereka sebagai insinyur perangkat lunak harus memiliki pengetahuan tentang dan bagaimana orang tersebut harus bertindak dalam kapasitas profesional. Itu tidak berarti ini adalah aturan keras, tetapi dokumen-dokumen ini memandu insinyur perangkat lunak profesional tentang apa yang biasanya relevan dengan pekerjaan yang mungkin diminta untuk dilakukan. SWEBOK direvisi dari waktu ke waktu untuk memastikan bahwa SWEBOK tetap relevan.

Karakteristik berikutnya adalah akreditasi program pendidikan. Di AS, akreditasi program rekayasa perangkat lunak ditangani oleh ABET . Mereka juga mengakreditasi ilmu komputer, teknologi informasi, teknik komputer, dan profesi terkait komputasi lainnya. ABET memposting persyaratan program terakreditasi di situs web mereka - rekayasa perangkat lunak dianggap sebagai Program Rekayasa. Tujuan akreditasi adalah untuk memastikan konsistensi di antara lulusan program teknik yang berbeda, setidaknya dalam hal materi pelajaran yang diajarkan di kelas. Ia tidak mengatakan apa-apa tentang kualitas pendidikan.

Setelah lulus, sertifikasi dan perizinan digunakan untuk menilai pengetahuan yang dipelajari di kelas (dan, dalam beberapa kasus, di tempat kerja) terhadap standar badan pengetahuan. Meskipun sekolah-sekolah terakreditasi memiliki materi pengajaran yang pasti untuk diajarkan, tidak ada ukuran seberapa baik materi ini diajarkan dan seberapa banyak siswa belajar pada saat penyelesaian program. Sertifikasi dan lisensi memberikan metode untuk melakukan itu - semua orang mengambil ujian yang sama dan menunjukkan pengetahuan di berbagai badan pengetahuan yang berakar pada profesi tersebut. Dalam rekayasa perangkat lunak, IEEE menawarkan sertifikasi yang berakar pada SWEBOK - Pengembangan Perangkat Lunak Bersertifikat Mengasosiasikan untuk senior dan lulusan baru dan Profesional Pengembangan Perangkat Lunak Bersertifikatbagi mereka yang memiliki pengalaman industri. Agar ini menambah nilai, itu memerlukan penerimaan SWEBOK sebagai definisi yang baik tentang apa itu rekayasa perangkat lunak.

Akhirnya, masyarakat profesional memelihara dokumen panduan untuk profesi, memfasilitasi konferensi dan publikasi untuk pertukaran pengetahuan dan ide, menjembatani kesenjangan antara akademisi dan industri, dan sebagainya. Dua masyarakat terkemuka adalah Masyarakat Komputer IEEE dan ACM , tetapi ada masyarakat lain di seluruh dunia. Ini membungkus semuanya menjadi bundel kecil yang bagus dan membantu menyampaikan informasi kepada orang yang tepat.

Dari sini, ada pertanyaan lain untuk diajukan. Apakah pengembangan perangkat lunak disiplin ilmu? Apakah sertifikasi atau lisensi menambah nilai bagi insinyur perangkat lunak? Apakah sertifikasi bermanfaat?

Saya tidak berpikir bahwa semua pengembangan perangkat lunak membutuhkan ketelitian dari disiplin teknik. Itu bukan untuk mengatakan bahwa studi empiris, ilmiah dari sains dan rekayasa perangkat lunak bangunan tidak membantu semua orang - memang demikian. Namun, ada perbedaan besar antara mengembangkan video game terbaru, mengembangkan perangkat lunak tertanam untuk alat pacu jantung, atau membangun pesawat ruang angkasa berikutnya. Penekanannya berbeda pada mereka semua - dua dari tiga layak mendapat perhatian seorang insinyur yang terampil. Yang lain dapat belajar dari praktik teknik, tetapi tidak perlu bergantung pada mereka untuk berhasil menyelesaikan proyek.

Sertifikasi dan perizinan membutuhkan pengetahuan yang diterima. SWEBOK adalah dokumen bagus yang memberikan dasar yang kuat, tetapi tidak diterima secara luas. Kecuali jika Anda dapat mendasarkan program akademik dan ujian sertifikasi / lisensi pada sesuatu yang konkret yang akan diterima oleh para praktisi, maka tidak ada gunanya. Jika SWEBOK atau dokumen alternatif diterima secara luas (setidaknya dalam bidang-bidang yang membutuhkan ketelitian teknik), maka ujian sertifikasi atau lisensi dapat digunakan untuk mengukur pemahaman pengetahuan yang diperlukan.

Namun, ada satu masalah mencolok dengan sertifikasi - ini adalah tes pada buku. Beberapa orang pandai membaca, belajar, menghafal, dan mengikuti ujian. Namun, itu tidak berarti mereka adalah insinyur yang baik. Orang-orang melewati celah-celah sepanjang waktu. Sertifikasi atau lisensi hanya satu langkah. Di tempat kerja, pelatihan dan bimbingan oleh para insinyur berpengalaman lainnya wajib untuk merawat seorang praktisi yang baik. Selain itu, kemampuan untuk mencegah orang dari berlatih di lingkungan yang kritis juga dapat membantu mengurangi risiko terhadap masyarakat dan bisnis.

Buku bagus dengan diskusi yang cukup mendalam tentang hal ini adalah Pengembangan Perangkat Lunak Profesional Steve McConnell : Jadwal Lebih Pendek, Produk Berkualitas Tinggi, Proyek yang Lebih Berhasil, dan Peningkatan Karir .


Saya sedikit di bawah cuaca, jadi jika saya melewatkan sesuatu atau sesuatu tidak masuk akal, tusuk saya dan saya akan memperbaikinya. Terima kasih kawan
Thomas Owens

"dua dari tiga layak mendapat perhatian seorang insinyur yang terampil" Anda benar, pesawat ruang angkasa tidak terlalu sulit untuk dibuat
zzzzBov

+1 terima kasih telah menambahkan masukan Anda tentang masalah ini. Saya harap Anda merasa lebih baik.
Jonathan Henson

12

Jika peraturan pemerintah disahkan, industri perangkat lunak di AS akan berkontraksi secara signifikan, karena biaya yang terkait dengan memenuhi peraturan tersebut akan lebih tinggi daripada yang dapat dilakukan oleh pemula dan usaha kecil.

Kelangkaan dan biaya yang terkait dengan gelar Sarjana Hukum atau Doktor Kedokteran akan menjadi lebih atau kurang terlihat di industri kita. Tidak baik ketika alternatifnya adalah bahwa setiap joe berpotensi membangun Facebook berikutnya.

Orang membuat kesalahan, dan tidak ada jumlah peraturan yang akan mencegah bencana terjadi. Pertimbangkan NASA, yang sejauh ini memiliki persyaratan paling ketat untuk pengembangan perangkat lunak yang dikenal manusia. Apakah mereka masih memiliki bug perangkat lunak? (Ya, ya, dan berkali-kali, ya!)

Pasar memilah masalah-masalah ini jauh lebih baik daripada regulasi. Perusahaan yang membuat perangkat lunak yang menyebabkan masalah dianggap bertanggung jawab oleh orang-orang yang mereka lukai. Kita semua tidak perlu membayar kesalahan mereka.


8
Tambahan fantastis untuk jawaban ini adalah daftar perusahaan perangkat lunak yang ada yang mungkin tidak akan dimulai jika peraturan ini berlaku. Microsoft dan Facebook adalah awal yang baik, karena sertifikasi kemungkinan akan membutuhkan gelar (hampir setiap profesi yang dimulai dengan pengujian menambah persyaratan gelar jika mereka tidak memulai dengan satu).
psr

1
@maple_shaft, IMO yang membandingkan dokter / pengacara dengan rekayasa perangkat lunak tidak valid. Kolom terlalu berbeda untuk dibandingkan (lihat jawaban Jarrod Nettles untuk melihat mengapa Anda tidak dapat membandingkan rekayasa perangkat lunak dengan dokter / pengacara).
Trevor Boyd Smith

1
@maple_shaft - Anda menyiratkan bahwa sertifikasi akan meningkatkan kualitas rekayasa. Saya cukup skeptis akan hasilnya. Saya pikir waktu yang dihabiskan belajar untuk sebagian besar tes adalah waktu yang tidak dihabiskan untuk belajar teknik yang lebih baik.
psr

4
Saya percaya semua orang membuat asumsi yang tidak terbukti bahwa dokter dan pengacara berlisensi benar-benar meningkatkan kualitas dokter dan pengacara. Saya sangat skeptis dengan asumsi itu. Semua lisensi memastikan bahwa dokter dan pengacara dapat membebankan biaya keterlaluan dan tidak ada yang bisa dilakukan siapa pun tentang hal itu. Dalam hal itu, saya semua untuk insinyur perangkat lunak lisensi. Itu tidak akan meningkatkan kualitas perangkat lunak sedikitpun, tetapi itu pasti akan membuat banyak dari kita pengembang perangkat lunak kaya. Haha ketika pemerintah menangkap bocah sekolah menengah atas karena mempraktikkan perangkat lunak tanpa lisensi.
Dunk

1
@maple_shaft yang sepenuhnya tergantung pada sifat kegagalan - Facebook tidak merespons tidak penting (di luar memengaruhi kantong investor) - Facebook membuat semua detail pribadi dan pesan pribadi Anda tersedia untuk setiap pengguna internet adalah masalah yang berbeda. Lebih lanjut - aplikasi / game yang mengambil detail kartu kredit (seperti di Facebook) tanpa sengaja melepaskan detail kartu kredit akan memiliki dampak serius.
HorusKol

11

Pada tahun 1999, ACM mengeluarkan pernyataan tentang perizinan ketika sebagian besar ditarik dari pekerjaan IEEE SWEBOK. Setelah meninjau dokumen SWEBOK yang tersedia untuk umum dan pernyataan ACM, saya mendukung pendapat ACM.

Melirik artikel itu, seseorang dengan pengalaman 4-6 tahun diharuskan mengikuti ujian, yang menguji pengetahuan dasar. Itu tidak masuk akal, dan harus ditertawakan keluar.


10

Komponen perangkat lunak suatu perangkat adalah detail implementasi. Misalnya, dalam industri sistem kontrol, semua perangkat keselamatan digunakan untuk kabel, dan orang-orang tidak mempercayai perangkat lunak. Namun, kami sekarang melihat perangkat keamanan berbasis perangkat lunak seperti Safety Relays dan Safety PLCs. Ini diperbolehkan karena masih harus memenuhi peraturan industri untuk perangkat keselamatan (tergantung pada kategori keamanan). Oleh karena itu, dalam beberapa kasus perangkat memerlukan prosesor yang berlebihan, dan kode berlebihan yang ditulis oleh dua tim yang berbeda, dll.

Ini adalah produk yang harus memenuhi pedoman keselamatan jika harus dijual dan dikonsumsi oleh publik. Aturan-aturan itu tidak berubah karena produk mengandung perangkat lunak. Adalah tugas Engineer untuk memastikan bahwa produk tersebut memenuhi semua kriteria peraturan, dan jika mengandung perangkat lunak, maka mereka harus meninjau perangkat lunak dan kompeten di bidang itu . Jika tidak, mereka (atau perusahaan mereka) bertanggung jawab jika mereka menyetujui desain dan ternyata salah.

Anda tidak benar-benar perlu mengatur semua pemrogram hanya karena beberapa produk perlu memenuhi persyaratan yang lebih ketat. Dalam kasus di mana produk tersebut melibatkan perangkat lunak, Anda memerlukan disiplin teknik yang dikembangkan dengan baik yang dapat menentukan bahwa komponen perangkat lunak memenuhi persyaratan. Jika ada, itulah yang dimaksud IEEE: bidang Rekayasa Perangkat Lunak yang relatif muda perlu dikembangkan ke tingkat keandalan dan kepercayaan disiplin ilmu teknik lainnya.

Ini benar-benar tidak ada hubungannya dengan "pemrograman" dan semuanya ada hubungannya dengan "rekayasa".

Ini, tentu saja, membawa kita kembali ke masalah perdebatan tentang perbedaan antara pengembang dan insinyur. Ini umumnya dua peran berbeda yang tumpang tindih secara teratur. Bagian pengembang berarti Anda membuat perangkat lunak. Bagian rekayasa peran berarti jika Anda mencap desain, Anda bertanggung jawab atas keselamatan publik. Anda bisa menjadi satu tanpa yang lain.


5
+1 IMHO, yang benar-benar Anda isyaratkan adalah bahwa regulasi harus ada pada produk, bukan pada insinyur. Misalnya, peraturan (persetujuan) yang diperlukan untuk sistem Alarm Kebakaran dan Intrusi memastikan perangkat lunak berfungsi, bukan kemampuan insinyur yang menulisnya. (Banyak peraturan terlihat sama seperti ketika sistem dibuat seluruhnya dari sirkuit elektronik.)
jwernerny

8

Perangkat lunak sudah diatur dengan ketat dalam industri pesawat terbang. Lihat DO-178B .

Saya yakin himpunan bagian lain dari industri memiliki norma mereka.

"Perangkat lunak" mencakup banyak hal akhir-akhir ini. Saya pikir tidak masuk akal untuk memiliki peraturan yang mencakup semua hal wajib.


4

Regulasi industri perangkat lunak paling baik dilakukan melalui regulasi proses Jaminan Kualitas.

Ini sudah dilakukan - perusahaan perangkat lunak besar memiliki banyak penguji, manajer QA, suite pengujian otomatis, proses peninjauan kode, proses pengujian, dan seterusnya. Ada perusahaan yang seluruh tujuannya melakukan audit kualitas perangkat lunak pada perusahaan lain. Organisasi standar memiliki pedoman untuk QA dan untuk Audit QA.

Di dalam perusahaan, seorang insinyur perangkat lunak bertanggung jawab atas kualitas pekerjaan mereka. Namun, checks and balances mereka, berada dalam proses kualitas perusahaan.


2
Inilah pendapat saya. Industri penerbangan memiliki aturan ketat untuk memprogram kontrol dan pengujian kualitas. Perusahaan perlu mengaudit aset informasi mereka dan menerapkan lebih banyak pengujian dan peninjauan. Saya pikir ini adalah hari-hari yang kelam dari perangkat lunak, karena masih banyak yang mengambil jalan pintas dengan tidak melakukan apa yang mereka tahu sebagai hal yang benar untuk dilakukan, dan para pengembang sendiri tidak cukup untuk mengubah industri.
Tjaart

Poin bagus - perangkat lunak yang menjalankan perangkat adalah tanggung jawab perusahaan untuk rekayasa yang baik dan aman seperti halnya dengan teknik industri.
Jarrod Nettles

3

Ini sama dengan upaya paling modern seperti memecahkan "masalah terkait perangkat lunak". Mereka yang mencoba membuat undang-undang memiliki sedikit pengetahuan tentang jalannya masalah. Jika mengikuti proses yang ditentukan (dan maksudnya tentu saja) ketika mengembangkan perangkat lunak penting keselamatan, baik itu untuk pesawat terbang, pembangkit nuklir peralatan medis, satu bug tidak akan pernah cukup untuk menyebabkan kegagalan. Seluruh algoritma dapat diimplementasikan secara tidak benar tanpa ada yang dirugikan.

FDA dan FTA keduanya memerlukan analisis risiko dan berdasarkan pada itu strategi mitigasi. Yang belakangan biasanya merupakan strategi keju swiss di mana orang menerima bahwa setiap mitigasi cacat, sehingga diterapkan beberapa mitigasi untuk risiko yang sama (satu mitigasi juga dapat diterapkan pada beberapa risiko) setiap mitigasi adalah seperti sepotong keju swiss yang dapat Anda periksa. satu, mungkin dua irisan disatukan tapi cukup masukkan irisan dan itu tidak mungkin lagi. Bahkan ketika mitigasi dilaksanakan dengan sempurna yang tidak menghasilkan peralatan yang 100% aman. Jika analisis risiko salah, akan ada risiko yang tidak dipikirkan (Y2K).

Anda dapat menguji para insinyur semua yang Anda inginkan, Anda bahkan dapat menguji pada materi pelajaran dan membutuhkan tingkat yang sangat tinggi tetapi akan sangat berarti. Sebagian besar kesalahan kritis keselamatan adalah kesalahan integrasi. Mereka bukan kesalahan dalam satu kode mans tetapi timbul karena ketidaksejajaran antara perangkat lunak dan perangkat keras dari dua sistem perangkat lunak atau karena partikel alfa mengetuk penghitung program dari lokasi yang tepat.

Saya telah menggunakan beberapa sistem kritis keselamatan dengan pengembang yang sangat berpengalaman dan mampu, yang akan lulus tes masuk akal di bidangnya. Saya belum pernah berada di proyek di mana kami tidak memiliki kesalahan kritis keselamatan. (Untungnya saya tidak pernah berada di tempat di mana sistem pernah melukai siapa pun)


1
+1 - Untuk: "Sebagian besar kesalahan kritis keselamatan adalah kesalahan integrasi." Bahkan, dengan semua proses yang kita lalui hampir tidak pernah ada kesalahan pengkodean. 99,98% dari waktu itu adalah masalah pemahaman antara berbagai modul dan perangkat tentang bagaimana mereka seharusnya bekerja.
Dunk

@Dunk, terima kasih itu sebenarnya qoute dari Levison. Fakta yang saya maksudkan untuk dimasukkan ke dalam teks tetapi sepertinya saya lupa :)
Rune FS

2

Seseorang tidak pernah bisa menghilangkan para penipu dan dukun sepenuhnya karena mereka ada di hampir setiap profesi, bahkan profesi medis meskipun praktik dan tradisi yang sudah lama mapan.

Pada pernyataan ini sebagai perampasan tanah, saya tidak yakin apa yang mengerikan menakutkan tuan semua hal IT jahat merencanakan kontrol dan regulasi pengembangan perangkat lunak yang tidak terkekang. Jika Anda sebenarnya berbicara tentang IEEE mereka tentu memiliki aspek regulasi tetapi kepatuhan dengan standar IEEE kurang lebih sesuai keinginan, dan tidak dengan todongan senjata. Mereka berusaha mengembangkan standar industri universal sehingga kita semua berbicara dalam bahasa yang sama dan meningkatkan efisiensi secara menyeluruh.

Lebih jauh lagi, standar yang mereka buat membantu melegitimasi praktik umum dan meletakkan dasar untuk pengembangan perangkat lunak yang pada akhirnya menjadi bidang teknik yang lebih disiplin, tidak seperti teknik mesin, atau teknik kimia. Sementara perangkat lunak semakin mendekati tujuan itu, kemungkinan tidak akan pernah sepenuhnya diterima secara universal sebagai disiplin ilmu teknik.

Masalah utamanya adalah pengembang perangkat lunak dapat melakukan apa saja, mulai dari menulis widget desktop yang cantik, hingga menerapkan sistem panduan missle. Dalam satu keparahan dan konsekuensi kesalahan jauh lebih tinggi dari yang lain, dan dengan demikian menuntut disiplin teknik yang diatur secara ketat untuk mendekati secara wajar, aman, dan efisien. Ini sangat mirip dengan tingkat keparahan kesalahan pada suatu jembatan yang dirancang secara tidak benar dan akibatnya jembatan itu runtuh. Desainer jembatan harus mematuhi standar teknik saya untuk memastikan kualitas.


4
Biasanya peraturan tersebut akhirnya menjadi persyaratan hukum juga. Misalnya, teknik sipil yang membutuhkan PE
Paul Nathan

@PaulNathan Poin bagus, itulah sebabnya perkembangan alami ke disiplin yang diterima secara universal dimulai dari pengaturan diri (mis. MPAA) dan akhirnya mengarah pada pengaturan oleh hukum (Dewan Negara, FCC, dll ...)
maple_shaft

7
Saya tidak percaya pengembangan perangkat lunak siap untuk pengaturan sendiri, atau bahkan dekat dengannya. Terus terang, gagasan bahwa "insinyur nyata" memiliki "kualitas nyata" adalah semacam lelucon bagi saya. Angkasa luar angkasa meledak, roket menyala, jembatan runtuh, bangunan runtuh ... dll. Akan lebih baik jika mencoba memaksakan kualitas dari atas, tetapi, haha.
Paul Nathan

1
Membandingkan teknik mesin dengan rekayasa perangkat lunak membuat saya bertanya-tanya seperti apa analog teknik dunia nyata dengan sistem operasi modern.
FrustratedWithFormsDesigner

1
@maple_shaft - masalah intinya adalah Anda tidak bisa menggunakan Linux / BSD / grep / vi / Firefox dll karena mereka tidak ditulis oleh SE resmi. Sementara seseorang dengan sertifikat MSCE di VB akan baik-baik saja.
Martin Beckett

1

Saya tidak akan menyebutnya sebagai peraturan yang lebih ketat, melainkan hambatan untuk masuk. Dalam hal itu saya pikir ada pahala. Untuk peningkatan kualitas, itu sangat bisa diperdebatkan.

Saat ini setiap John / Jane Doe dapat menulis sebuah program. Tidak ada penghalang untuk masuk. Ambil beberapa buku tentang scripting dan teknologi web dan mulailah meretas, atau lebih buruknya, mulailah Googling untuk bagaimana "melakukannya".

Ketika kita secara keseluruhan memutuskan mungkin saatnya untuk meningkatkan hambatan untuk masuk, untuk mempertahankan industri ke standar yang lebih tinggi, untuk berevolusi dari peretas / pengrajin menjadi insinyur, peraturan semacam itu yang saya ikuti.

Ada terlalu banyak orang yang tidak memenuhi syarat pemrograman hari ini. Apakah mereka bekerja pada sistem kritis atau tidak, mereka masih memproduksi kode, masih memproduksi Bola-Bola Besar Lumpur .

Dalam hal itu, pengaturan diri atau lebih tepatnya menciptakan hambatan untuk masuk adalah hal yang baik. Karena kami katakan, hei Anda tidak bisa datang begitu saja dan menyebut diri Anda seorang Insinyur Perangkat Lunak. Anda benar-benar harus menurunkan tingkat keterampilan.

Keterampilan merosot lebih dari sekadar mengikuti tes atau mendapatkan "lencana kehormatan". Tes hanyalah validasi. Validasi sebenarnya adalah Sekolah, magang, magang, bimbingan di bawah senior, berlatih, semua adalah bagian dari itu.

Saya dapat melihat apa yang sedang dicoba dicapai oleh IEEE, tetapi pada titik ini merupakan latihan yang sia-sia. Industri berubah dengan cepat, terlalu banyak permintaan untuk mendorong keluar produk, pola pikir "peretas", dll. Peraturan harus berasal dari dalam jika sama sekali.


Saya memberi +1 karena harus ada beberapa cara untuk mencegah riff-raff dari jenis sistem tertentu. Namun, saya memberi -1 karena sebagian besar perangkat lunak saat ini dapat dikembangkan secara memadai oleh peretas dan untuk menghentikan mereka agar tidak dapat menyediakan layanan itu untuk menekan biaya yang bertentangan dengan kepentingan umum. Demikian juga dengan pengacara dan dokter. 90% dari apa yang mereka lakukan dapat ditangani dengan biaya yang cukup efektif dan sama kompetennya dengan orang-orang dengan kualifikasi lebih rendah. Namun, dengan undang-undang saat ini mereka bebas untuk mencungkil publik sesuka hati.
Dunk

Bukankah keterampilan harus dinilai selama proses perekrutan. Oh, tunggu, SDM merekrut orang berdasarkan kredensial kertas (yang tidak menunjukkan pengetahuan yang berlaku dalam pengembangan perangkat lunak) dan SDM tidak tahu apa-apa tentang kebutuhan / persyaratan untuk mengembangkan perangkat lunak. Gagal ganda ...
Evan Plaice

0

Saya belum membaca artikel itu, tetapi jika pertanyaannya adalah apakah regulasi industri perangkat lunak dapat bermanfaat bagi umat manusia, saya pikir itu tergantung pada keadaan:

  1. Industri ini secara keseluruhan mencakup berbagai domain, beberapa di antaranya sangat penting bagi kehidupan (misalnya mengendalikan dosis radiasi dalam perangkat medis), dan beberapa di antaranya tidak (aplikasi Facebook "Yang Muppet Are You?") Facebook. Saya tidak bisa melihat argumen untuk regulasi untuk aplikasi di mana taruhannya rendah.

  2. Seseorang seharusnya tidak memulai dengan peraturan hukum. Sebaliknya, seseorang harus memulai dengan program sertifikasi untuk pengembang. Hanya jika program sertifikasi menghasilkan beberapa manfaat terukur seandainya ada pertanyaan tentang peraturan hukum.

  3. Bahkan jika program sertifikasi menghasilkan hasil yang terukur, kemungkinan industri akan melakukan standarisasi untuk mensyaratkan sertifikasi ini hanya untuk alasan bisnis, dan kita tidak akan memerlukan peraturan hukum. (Inilah sebabnya mengapa ada delegasi seperti MCSE - perusahaan lebih suka menyewa MCSE untuk domain tempat MCSE dilatih.)

  4. Meskipun demikian, masih ada domain di mana masuk akal bisnis untuk menyebabkan kerugian (seringkali ini adalah eksternalitas negatif , kadang-kadang mereka adalah hasil dari kekuatan pasar untuk beberapa institusi). Sebagai contoh, suatu daerah mungkin memiliki satu rumah sakit lokal; dalam hal ini, kualitas perangkat lunak back-end dapat membuat perbedaan besar pada tingkat perawatan yang diterima pasien, tetapi tidak membuat banyak perbedaan di mana rumah sakit yang dipilih pasien. Rumah sakit kemudian tidak perlu memiliki banyak kasus bisnis untuk berinvestasi di pengembang berkualitas tinggi. Dalam hal ini, mungkin ada kasus kesehatan masyarakat untuk mengatur pengembang yang diizinkan untuk disewa rumah sakit.

MENURUT OPINI SAYA.


0

Saya harus menjawab yang ini ...

Dimulai dengan apa yang dikatakan @JonathanHenson dan masuknya @gnat, apa yang saya katakan ok, orang-orang yang punya uang bisa membayar untuk barang-barang bersertifikat, orang-orang atau negara-negara yang tidak punya uang tidak bisa membayar lisensi (begitu banyak untuk barang-barang bersertifikat ), jadi masih akan ada pemberontak jika itu dipraktikkan. Bahkan jika metode pengiriman tradisional (dan tidak terlalu tradisional) ditutup, orang masih akan menemukan cara untuk mengirimkan perangkat lunak kepada pengguna yang tertarik. Bahkan jika itu berarti mengembangkan protokol HTTP lain atau bahkan seluruh tumpukan jaringan alternatif, hanya fokus dalam membuat koneksi tidak terdeteksi (lihat paragraf terakhir, untuk seseorang yang mungkin dapat melakukan ini).

Juga, ide untuk membayar sesuatu, beresiko, karena dunia semakin miskin dan semakin miskin, sehingga semakin banyak orang akan semakin sedikit uang untuk membayar sesuatu, bahkan ada negara yang hanya menggunakan perangkat lunak FOSS, tanpa sertifikasi (Brasil dan India muncul di benak, tetapi ada yang lain yakin), dan beberapa negara itu menjadi besar, sangat besar. Dan mereka menggunakan perangkat lunak tidak bersertifikat yang dibuat oleh programmer yang tidak dikenal, yang keahliannya tidak diketahui.

Juga, bahkan jika ada beberapa jenis sertifikasi, sertifikasi hanya akan mengesahkan pengetahuan, bukan etika, hanya berpikir bahwa beberapa dokter memang menggunakan organ yang diambil secara tidak sah dari orang, sehingga akan ada juga programmer bersertifikat yang akan tidak memiliki etika dan menulis kode ceroboh baik sengaja atau tidak sengaja. Sementara di sebagian besar proyek FOSS, sebagian besar programmer yang berpotensi tidak terampil juga meninjau kode dari orang lain dan mencoba untuk menemukan kesalahan, dengan cara yang membuat pemrograman pasangan, sesuatu yang kecil.

Akhirnya, apa yang Anda katakan tentang kelompok peretasan (bukan kelompok peretas topi hitam, tetapi kelompok topi putih atau abu-abu), yang tahu lebih banyak tentang keamanan dan mengembangkan perangkat lunak keamanan dengan cara yang hanya cocok dengan programmer paling khusus dari departemen pemerintah tertentu.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.