Regulasi industri perangkat lunak [ditutup]

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 ¹ 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?

¹ Persis seperti peraturan profesi medis dimaksudkan untuk dilakukan.

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.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

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)

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.

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 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.

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.