Regulacja branży oprogramowania [zamknięty]

Co kilka lat ktoś proponuje ściślejsze regulacje dla branży oprogramowania.

Ten artykuł IEEE zyskał ostatnio trochę uwagi na ten temat.

Gdyby inżynierowie oprogramowania, którzy piszą programy dla systemów narażających społeczeństwo na ryzyko fizyczne lub finansowe, wiedzieli, że zostaną przetestowani pod kątem swoich kompetencji, myślimy, że ograniczy to wady i błędy w kodzie - a może uratuje życie kilku osobom podczas targowania się.

Jestem sceptycznie nastawiony do wartości i zalet tego. Moim zdaniem wygląda na to, że ci, którzy ją zaproponowali, przejmują ziemię.

Cytat, który mnie łączy, to:

Egzamin będzie sprawdzał podstawową wiedzę, a nie opanowanie przedmiotu

ponieważ duże awarie (np. THERAC-25 ) wydają się złożone, subtelne kwestie, którym „podstawowa wiedza” nigdy nie byłaby wystarczająca, aby zapobiec.

Ignorując wszelkie problemy lokalne (takie jak istniejące zabezpieczenia tytułu Inżynier w niektórych jurysdykcjach):

Cele są szlachetne - unikaj szarlatanów / szarlatanów ¹ i spraw, aby to rozróżnienie było bardziej oczywiste dla tych, którzy kupują swoje oprogramowanie. Czy ściślejsze regulacje branży oprogramowania mogą kiedykolwiek osiągnąć swój pierwotny cel?

¹ Dokładnie tak, jak miało to być uregulowanie zawodu lekarza.

Pogląd, że inżynierowie oprogramowania mogą być zaszufladkowani do tej samej klasyfikacji, co lekarze lub księgowi, jest nieświadomym poglądem na „problem”, który próbują rozwiązać. Zanim wydam opinię na ten temat, omówię niektóre argumenty pana Thorntona, który jest wiceprzewodniczącym organu regulacyjnego proponującego te przepisy.

„Tak jak praktykujący profesjonaliści, tacy jak lekarze, księgowi i pielęgniarki, mają licencję, podobnie inżynierowie oprogramowania” - mówi Thornton. „ Społeczeństwo musi móc polegać na jakimś poświadczeniu przy wyborze wykonawcy do pisania oprogramowania”.

- Mitch Thornton, wiceprzewodniczący IEEE Licensure and Registration

Na pozór brzmi to bardzo rozsądnie. W końcu istnieją inne branże, które można uznać za „skutecznie regulowane”. Przez skuteczne uregulowanie mam na myśli to, że jeśli spojrzysz na lekarza na żółtych stronach, możesz być całkiem pewny, że ukończył gruntowne wykształcenie na akredytowanym uniwersytecie i zdał szereg egzaminów i ukończył rezydencję. Oto niektóre „skutecznie regulowane” branże (pod względem profesjonalnego personelu).

• Prawnicy
• Lekarze
• Księgowi
• Inżynierowie nuklearni
• Fryzjerzy ( nie żartują )

W końcu nie chcesz, aby ktoś usunął ten guz z trzustki lub pracował nad wirówkami elektrowni jądrowej na obrzeżach miasta. Dlaczego inżynierowie oprogramowania nie powinni wprowadzać podobnych ograniczeń?

Tylko ci, których programy mogą „zagrozić zdrowiu publicznemu lub bezpieczeństwu, ochronie, mieniu lub gospodarce, będą musiały zostać przetestowane”

Jest to niejasne stwierdzenie, otwarte na liberalną interpretację i stosowanie. Mógłbym argumentować, że Apple Inc. lub Facebook są integralnymi częściami amerykańskiej gospodarki - czy potrzebuję specjalnej licencji od rządu, aby napisać dla nich teraz kod, ponieważ jeśli sprowadzę stronę z powodu mojej niekompetencji, mogę zaszkodzić amerykańskiej gospodarka? Podczas mojej ostatniej pracy przypadkowo wyłączyłem podnośnik ziarna z wadliwą pracą crona - prawdopodobnie zagrażając dostawom żywności.

Zdaję sobie sprawę, że unikam faktycznego zamiaru tej propozycji. Chodzi o to, aby osoba pisząca kod dla przeciwblokującego układu hamulcowego na nowej Jetcie była kompetentna i odpowiednio licencjonowana do pisania kodu dla przeciwblokującego układu hamulcowego. Na twojej Jetcie.

Oto problem: inżynieria oprogramowania w dzisiejszych czasach obejmuje wszystko i nie można przetestować każdej dyscypliny. Reguły biznesowe są zbyt szczegółowe i zbyt zróżnicowane w zależności od dyscypliny. Nasz hipotetyczny inżynier piszący kod dla układu ABS na Jetcie może pisać coś zupełnie innego dla układu ABS na Elantrze. Czy on musi otrzymać ponownie certyfikat?

A co jeśli przetestujesz dla wszystkich tych pochodnych dyscyplin? Załóżmy na chwilę, że każdy programista pracujący na stronie e-commerce otrzymuje certyfikat programisty zdolnego do e-commerce. Więc? Czy to znaczy, że nagle te programiści i firmy będą faktycznie wykonać niezbędną weryfikację i zbudować do zgodności ze standardem PCI? Nawet jeśli to zrobią - usterki nadal będą występować.

Zdaniem Mitcha Thorntona, wiceprzewodniczącego Komisji ds. Licencji i Rejestracji IEEE, egzamin będzie sprawdzał podstawową wiedzę, a nie opanowanie przedmiotu.

Oto kicker. Brak podstawowej wiedzy nigdy nie stanowi problemu. Moje hamulce przeciwblokujące nie przestały działać, ponieważ Chuck walczył z koncepcjami struktury sterowania. Nie powiodły się, ponieważ wystąpiła usterka, w wyniku której ABS wyłączył się z powodu zwarcia elektrycznego w tylnych światłach, a zasilanie nie zostało odpowiednio przekierowane. Lub coś.

Oprogramowanie pompy insulinowej, które napisałem, nie przestało działać, ponieważ brakuje mi podstawowych umiejętności; zatrzymało się, ponieważ wystąpił błąd w sposobie pomiaru dozowania insuliny, gdy mój europejski kolega z zespołu używał systemu metrycznego, a ja nie.

To jest coś, co możesz wziąć pod uwagę w fazie rozwoju, ale nigdy nie możesz przetestować certyfikacji .

Oto, co się stanie, jeśli ta „certyfikacja” wejdzie w życie: liczba incydentów pozostanie dokładnie taka sama. Dlaczego? Ponieważ nie robi nic, aby wyeliminować rzeczywisty problem awarii ABS lub pompy insulinowej.

Całe szczęście, że nikt nie umiera dzięki przepisom medycznym, nikt nie jest narażony na oszustwa dzięki przepisom finansowym, nikt nie ma wykluczonego domu dzięki regulacjom mieszkaniowym, nikt nigdy nie dostaje złej fryzury dzięki regulacjom fryzjerskim i żaden samolot nigdy nie ulega awarii dzięki regulacji samolotu.

Oczywiście obecność regulacji nie oznacza braku wad lub awarii. I odwrotnie, obecność wad lub awarii nie oznacza, że ​​regulacja zapobiegałaby tym wadom lub awariom. Inżynierowie oprogramowania są już ściśle regulowani jako członkowie odpowiednich branż o kluczowym znaczeniu dla bezpieczeństwa, a poza tymi branżami istnieje niewielka potrzeba.

Historia pokazała, słusznie uważam, że różnicy między doskonałym rzemieślnikiem a miernym rzemieślnikiem nie można sprawdzić żadną formą obiektywnej miary. Podstawowa wiedza nie czyni wielkiego programisty, mądrości i doświadczenia - których tak naprawdę nie można nauczyć ani obiektywnie zmierzyć - jak stosować tę podstawową wiedzę.

Ponadto testy te zwykle kończą się na kilku głośnych słowach i konkretnych procedurach i nie mierzą niczego merytorycznego na początek.

Gdyby branża oprogramowania chciała stworzyć jakąś gildię, byłby to znacznie lepszy sposób na rozwiązanie tego problemu. Jednak centralizacja może tylko zniszczyć doskonałość: nie tworzyć jej.

Ponadto problemy, którym ten środek próbuje zapobiec, prawdopodobnie nie zostałyby złapane przez test. Tak czy inaczej, chciałbym również zobaczyć @ThomasOwens, który odpowiedział na to pytanie.

Rolą rządu, przynajmniej z amerykańskiej ideologii, byłoby pociągnięcie firm odpowiedzialnych za oprogramowanie za wszelkie szkody majątkowe spowodowane ich wadliwym lub niepewnym oprogramowaniem. Zachęci to firmy do egzekwowania własnych standardów i do wzięcia osobistej odpowiedzialności za sprawę. Jest to zawsze lepsze rozwiązanie i nie zawiera scentralizowanego rządu przekraczającego granice.

Aktualizacja

Myślałem o tym jeszcze trochę ostatniej nocy przy piwie lub dziesięciu.

Wszystko, co regulowało dziedzinę medycyny, polegało na eksterminacji wszystkich paradygmatów oprócz jednego. Jeśli ich celem było wyeliminowanie lekarzy homeopatycznych i naturopatycznych, których operatorzy uprzejmie nazywali „szarlatanami”, wówczas taka regulacja się powiodła. Nie zgadzam się jednak z tym, że taka rzecz jest opłacalna dla każdego oprócz osób piszących przepisy. Pomyśl o tym, co to zrobiło. Zwiększyło to koszty opieki zdrowotnej do niezrównoważonych poziomów, znacznie zwiększyło poziom odpowiedzialności za MD i usunęło z rynku całą moc wyboru i samostanowienia konsumenta. Społeczność medyczna nie ma już rynku pomysłów, a nowe terapie i sposoby myślenia o medycynie są teraz tłumione. Co więcej, bariera wejścia na pole jest niewiarygodnie wysoka, w wyniku czego brakuje nam dobrego MD s. Ponadto agencje regulacyjne są uprawnione do kontrolowania podaży lekarzy, aby z kolei mogli kontrolować cenę płaconą lekarzom.

Rzeczywiście pewne korzyści uzyskaliśmy dzięki przepisom medycznym, ale koszty są całkowicie zbyt wysokie.

To samo stanie się z inżynierami oprogramowania, jeśli takie przepisy zostaną przyjęte. Widzę to teraz, agencje regulujące będą decydować, że programowanie obiektowe jest jedynym standardem projektowania, a programiści funkcjonalni i proceduralni nie będą mogli ćwiczyć. Wtedy zaczną nam mówić, że nie wolno nam zarządzać własną pamięcią, ponieważ nie jest to bezpieczne. Następnie wcisną JAVA i C # wszystkie nasze gardła i powiedzą nam, że musimy go używać, podczas gdy Oracle i Microsoft stają się grubsze i szczęśliwsze. Innowacje zostaną stłumione, a kreatywność zostanie zakazana. Microsoft i Google napiszą przepisy, więc zasady rynku będą nastawione na własną rentowność i na dobrobyt społeczny.

Chciałbym też przypomnieć wszystkim, że komputery zaczynały jako hobby i akademickie przedsięwzięcie. Poza wojnami uniksowymi lat 80. i wczesnych 90. mieliśmy darmowe systemy operacyjne, bezpłatne kompilatory, darmowe programy i tak dalej ... To by się szybko skończyło. Świat, który przekazali nam Richard Stallman, Linus Torvalds i Dennis Richtie, stopniowo zniknie z istnienia.

Podsumowując, czy mam już dość konkurowania z „Zaprojektuję witrynę Wordpress CMS za 25 USD za godzinę” lub „jakąkolwiek aplikację na iPhone'a za 500 USD”? Nie bardzo, dlaczego? Ponieważ jestem cholernie dobry w tym, co robię, a klienci, których chcę, są gotowi zapłacić za doskonałość. Kiedy podejmuję się projektu samodzielnie lub w miejscu pracy, ryzykuję swoje awarie na własną odpowiedzialność i reputację. To pójdzie za mną, gdziekolwiek pójdę. Ponadto większość ludzi wie, że dostają za co płacą. Klient, który jest gotów zapłacić mi tylko cenę, którą płacą swojemu facetowi z trawnika, będzie koszmarem, z którym i tak trzeba sobie poradzić. Gdyby rząd ustalił strukturę prawną, aby zmusić dostawców usług do zrekompensowania ich szkód, wówczas bardzo niewielu złych programistów nadal miałoby zatrudnienie w tej dziedzinie.

Nawiasem mówiąc, nadal mamy złych lekarzy, jedyną różnicą jest to, że istnieje bardzo niewiele sił, aby usunąć ich z rynku. Gdyby musieli wziąć na siebie odpowiedzialność za swoje działania, straciliby interes, zanim mieliby kolejną szansę siać spustoszenie w swoich klientach.

Aktualności z Doliny Krzemowej - 31 czerwca 2015 r

Horror: Niecertyfikowany programista przerwał program

„Nigdy więcej nie będę mógł biec”, wysyła ofiarę. Policja prowadzi dochodzenie.

Przestępca: Licencja dr H. Ackera Jr. odwołana z powodu nieprawidłowego użycia wskaźnika i próby odczytu z pliku systemowego

Adwokat mówi, że będzie apelacja do Sądu Najwyższego.

Ogłoszenia: programiści Cobol certyfikowani w 1975 r. Powinni recertyfikować nie później niż w 2025 r

Potwierdzony przez IEEE certyfikat nie zmienił się od tego czasu.

Reklamy: Certyfikacja gwarantowana przez Magic Knowledge Stuffers, Inc

Naucz się programowania w 21 dni.

Istnieje kilka różnych sposobów zastosowania regulacji w każdym zawodzie - dobrze zdefiniowany zasób wiedzy, kodeks etyczny, akredytacja programów edukacyjnych, certyfikacja i licencje oraz stowarzyszenia zawodowe wspierające rozwój zawodowy, a także inne aspekty zawód. Inżynieria oprogramowania ma większość cech zawodu.

Lubię myśleć o tym, zaczynając od Software Knowledge Body of Knowledge (SWEBOK) i Software Engineering Code of Ethics and Professional Practice . Chociaż ich powszechna akceptacja jest wciąż dość ograniczona, uważam, że stanowią one dobrą bazę do zidentyfikowania rodzajów rzeczy, o których osoba identyfikująca się jako inżynier oprogramowania powinna wiedzieć i jak taka osoba powinna zachowywać się profesjonalnie. Nie oznacza to, że są to twarde reguły, ale raczej te dokumenty prowadzą profesjonalnych inżynierów oprogramowania do tego, co zwykle jest istotne dla pracy, do której wykonania mogą zostać poproszeni. SWEBOK jest okresowo zmieniany, aby upewnić się, że pozostaje aktualny.

Kolejną cechą jest akredytacja programów edukacyjnych. W USA akredytacją programów inżynierii oprogramowania zajmuje się ABET . Akredytują także informatykę, informatykę, inżynierię komputerową i inne zawody związane z informatyką. ABET publikuje swoje wymagania dotyczące akredytowanych programów na swojej stronie internetowej - inżynieria oprogramowania jest uważana za program inżynierski. Celem akredytacji jest zapewnienie spójności między absolwentami różnych programów inżynierskich, przynajmniej w zakresie przedmiotu nauczanego w klasie. Nie mówi nic o jakości edukacji.

Po ukończeniu studiów certyfikacja i licencje są wykorzystywane do oceny wiedzy zdobytej w klasie (aw niektórych przypadkach w pracy) na podstawie standardowych zasobów wiedzy. Chociaż akredytowane szkoły mają określony materiał do nauczenia, nie ma pewności, jak dobrze nauczany jest ten materiał i ile uczniowie uczą się po zakończeniu programu. Certyfikacja i licencje dostarczają metod, aby to zrobić - każdy przystępuje do tych samych egzaminów i wykazuje wiedzę w różnych zasobach wiedzy, w której zawód jest zakorzeniony. W inżynierii oprogramowania IEEE oferuje certyfikaty oparte na SWEBOK - Certified Software Development Współpracownik seniorów i absolwentów oraz Certified Software Development Professionaldla osób z doświadczeniem branżowym. Aby mogły one wnieść wartość dodaną, należy zaakceptować SWEBOK jako dobrą definicję inżynierii oprogramowania.

Wreszcie, stowarzyszenia zawodowe przechowują wytyczne dotyczące zawodu, ułatwiają konferencje i publikacje w celu wymiany wiedzy i pomysłów, wypełniają luki między środowiskiem akademickim a przemysłem itd. Dwa wiodące społeczeństwa to IEEE Computer Society i ACM , ale istnieją inne społeczeństwa na całym świecie. Zawierają wszystko w ładny mały pakiet i pomagają dostarczać informacje właściwym osobom.

Stąd są inne pytania. Czy rozwój oprogramowania jest dyscypliną inżynieryjną? Czy certyfikacja lub licencjonowanie wnoszą jakąkolwiek wartość dla inżynierów oprogramowania? Czy certyfikacja jest przydatna?

Nie sądzę, aby całe tworzenie oprogramowania wymagało dyscypliny inżynierskiej. Nie oznacza to, że empiryczne, naukowe badanie nauki i inżynierii oprogramowania budowlanego nie wszystkim pomaga - robi to. Istnieje jednak duża różnica między opracowaniem najnowszej gry wideo, opracowaniem oprogramowania wbudowanego dla rozrusznika serca lub zbudowaniem następnego statku kosmicznego. Nacisk na wszystkie z nich jest inny - dwa z trzech zasługują na uwagę wykwalifikowanego inżyniera. Drugi może uczyć się na praktykach inżynierskich, ale nie musi na nich polegać, aby pomyślnie ukończyć projekt.

Certyfikacja i licencje wymagają zaakceptowanej wiedzy. SWEBOK to dobry dokument, który zapewnia solidne podstawy, ale nie jest powszechnie akceptowany. O ile nie możesz oprzeć swoich programów akademickich i egzaminów certyfikacyjnych / licencyjnych na czymś konkretnym, co byłoby akceptowane przez praktyków, to naprawdę nie ma sensu. Jeśli SWEBOK lub dokument alternatywny zostanie powszechnie zaakceptowany (przynajmniej w tych dziedzinach, które wymagają rygorystycznej inżynierii), wówczas można zastosować egzaminy certyfikacyjne lub licencyjne w celu oceny zrozumienia wymaganej wiedzy.

Jest jednak jeden rażący problem z certyfikacją - jest to test na książkę. Niektóre osoby potrafią czytać, uczyć się, zapamiętywać i przystępować do testu. Nie oznacza to jednak, że są dobrym inżynierem. Ludzie cały czas prześlizgują się przez szczeliny. Certyfikacja lub licencja to tylko jeden krok. W trakcie szkolenia i mentoringu przez innych doświadczonych inżynierów obowiązkowe jest przygotowanie dobrego praktyka. Ponadto umiejętność zapobiegania ćwiczeniom przez ludzi w środowiskach krytycznych może również pomóc w zmniejszeniu ryzyka dla społeczeństwa i przedsiębiorstw.

Dobra książka z dość dogłębną dyskusją na ten temat to profesjonalne opracowywanie oprogramowania przez Steve'a McConnella : krótsze harmonogramy, produkty o wyższej jakości, bardziej udane projekty i ulepszone kariery .

Jeśli przepisy rządowe zostaną przyjęte, przemysł oprogramowania w USA znacznie się skurczy, ponieważ koszty związane z przestrzeganiem tych przepisów będą wyższe niż na startupy i małe firmy.

Niedobór i koszty związane z uzyskaniem stopnia naukowego lub doktora medycyny staną się mniej lub bardziej widoczne w naszej branży. Nie jest dobrze, gdy alternatywą jest to, że każdy Joe może potencjalnie zbudować następnego Facebooka.

Ludzie popełniają błędy, a żadna regulacja nie zapobiegnie katastrofom. Zastanów się nad NASA, która ma jak dotąd najbardziej rygorystyczne wymagania dotyczące rozwoju oprogramowania znane człowiekowi. Czy nadal mają błędy oprogramowania? (Tak, tak i wiele razy tak!)

Rynek rozwiązuje te problemy o wiele lepiej niż przepisy. Firmy, które tworzą oprogramowanie powodujące problemy, ponoszą odpowiedzialność za osoby, które odniosły obrażenia. Reszta z nas nie musi płacić za swoje błędy.

W 1999 r. ACM wydało oświadczenie w sprawie licencjonowania, gdy w dużej mierze wycofało się z prac IEEE SWEBOK. Po przejrzeniu publicznie dostępnych dokumentów SWEBOK i oświadczenia ACM popieram opinię ACM.

Spoglądając na artykuł, osoba z 4-6-letnim doświadczeniem jest zobowiązana do przystąpienia do egzaminu, który sprawdza podstawową wiedzę. To jest absurdalne i należy się z niego śmiać przez drzwi.

Komponenty oprogramowania urządzenia są szczegółami implementacyjnymi. Na przykład w branży systemów sterowania wszystkie urządzenia bezpieczeństwa były podłączone na stałe, a ludzie nie ufali oprogramowaniu. Jednak obecnie widzimy oparte na oprogramowaniu urządzenia zabezpieczające, takie jak przekaźniki bezpieczeństwa i sterowniki bezpieczeństwa PLC. Są one dopuszczalne, ponieważ nadal muszą spełniać branżowe przepisy dotyczące urządzeń bezpieczeństwa (w zależności od kategorii bezpieczeństwa). Dlatego w niektórych przypadkach urządzenia potrzebują redundantnych procesorów i redundantnego kodu napisanego przez dwa różne zespoły itp.

Jest to produkt, który musi spełniać wytyczne bezpieczeństwa, jeśli ma być sprzedawany i spożywany przez społeczeństwo. Reguły te nie ulegają zmianie, ponieważ produkt zawiera oprogramowanie. Zadaniem Inżyniera jest upewnienie się, że produkt spełnia wszystkie kryteria regulacyjne, a jeśli zawiera oprogramowanie, musi on sprawdzić oprogramowanie i być kompetentnym w tej dziedzinie . Jeśli nie, to oni (lub ich firma) ponoszą odpowiedzialność, jeśli zatwierdzą projekt i okaże się, że jest wadliwy.

Tak naprawdę nie musisz regulować wszystkich programistów tylko dlatego, że niektóre produkty muszą spełniać bardziej rygorystyczne wymagania. W przypadkach, gdy takie produkty obejmują oprogramowanie, potrzebujesz dobrze rozwiniętej dyscypliny inżynierskiej, która może wiarygodnie ustalić, czy komponent oprogramowania spełnia wymagania. W ogóle to właśnie oznacza IEEE: stosunkowo młoda dziedzina inżynierii oprogramowania musi zostać rozwinięta do poziomu niezawodności i zaufania innych dyscyplin inżynieryjnych.

Naprawdę nie ma to nic wspólnego z „programowaniem” i wszystko z „inżynierią”.

To oczywiście przywraca nas do spornej kwestii różnicy między deweloperem a inżynierem. Są to zasadniczo dwie różne role, które regularnie się pokrywają. Część dla programistów oznacza, że ​​tworzysz oprogramowanie. Część inżynierska tej roli oznacza, że ​​jeśli stemplujesz projekt, bierzesz odpowiedzialność za bezpieczeństwo publiczne. Państwo może być jedno bez drugiego.

Oprogramowanie jest już ściśle regulowane w branży lotniczej. Zobacz DO-178B .

Jestem pewien, że inne podzbiory branży mają swoje normy.

„Oprogramowanie” obejmuje obecnie tak wiele. Myślę, że absurdem byłoby mieć jakiekolwiek obowiązkowe wszechstronne rozporządzenie.

Regulacji branży oprogramowania najlepiej dokonać poprzez regulację procesów zapewniania jakości.

To już zostało zrobione - duże firmy produkujące oprogramowanie mają mnóstwo testerów, menedżerów ds. Kontroli jakości, zautomatyzowane pakiety testowe, procesy przeglądu kodu, procesy testowania i tak dalej. Są firmy, których całym celem jest przeprowadzanie kontroli jakości oprogramowania w innych firmach. Organizacje normalizacyjne mają wytyczne dotyczące kontroli jakości i kontroli jakości.

Inżynier oprogramowania wewnątrz firmy odpowiada za jakość swojej pracy. Ich kontrole i salda są jednak w procesach jakości firmy.

Jest to to samo, co większość współczesnych prób rozwiązywania problemów związanych z oprogramowaniem. Ci, którzy próbują stanowić prawo, mają niewielką wiedzę na temat pierwotnego przebiegu problemu. Jeśli postępując zgodnie z zalecanym procesem (i intencją oczywiście) podczas opracowywania oprogramowania o kluczowym znaczeniu dla bezpieczeństwa, w przypadku samolotów, elektrowni jądrowych sprzętu medycznego pojedynczy błąd nigdy nie wystarczy do spowodowania awarii. Cały algorytm może zostać zaimplementowany niepoprawnie, bez szkody dla jakiegokolwiek.

Zarówno FDA, jak i FTA wymagają analizy ryzyka i opartej na niej strategii łagodzenia skutków. Później jest zwykle strategia szwajcarskiego sera, w której przyjmuje się, że jakiekolwiek ograniczenie jest wadliwe, dlatego stosuje się wiele ograniczeń dla tego samego ryzyka (jedno ograniczenie można również zastosować do kilku rodzajów ryzyka). Każde ograniczenie jest jak kawałek szwajcarskiego sera, przez który można przeglądać jeden, może dwa plasterki razem, ale zbierz wystarczającą liczbę plasterków i to już nie jest możliwe. Nawet jeśli ograniczenia zostały wdrożone perfekcyjnie, nie skutkuje to w 100% bezpiecznym sprzętem. Jeśli analiza ryzyka jest nieprawidłowa, nie będzie ryzyka, o którym nikt nie pomyślał (Y2K).

Możesz przetestować inżynierów wszystko, co chcesz, a nawet przetestować na dany temat i wymagać bardzo wysokiego poziomu, ale miałoby to duże znaczenie. Większość błędów krytycznych dla bezpieczeństwa to błędy integracji. Nie są to błędy w kodzie jednego człowieka, lecz powstają z powodu przesunięć między oprogramowaniem a sprzętem dwóch systemów oprogramowania lub dlatego, że cząstka alfa wybiła licznik programu z jego właściwej lokalizacji.

Pracowałem na kilku systemach o krytycznym znaczeniu dla bezpieczeństwa z wysoce doświadczonymi i zdolnymi programistami, którzy przeszliby każdy rozsądny test w swojej dziedzinie. Nigdy nie brałem udziału w projekcie, w którym nie wystąpił błąd krytyczny dla bezpieczeństwa. (Na szczęście nigdy nie byłem na takim, w którym system kiedykolwiek kogoś skrzywdził)

Nigdy nie można całkowicie wyeliminować szarlatanów i szarlatanów, ponieważ istnieją oni w prawie każdym zawodzie, nawet w zawodach medycznych, pomimo wieloletnich praktyk i tradycji.

Biorąc pod uwagę to, że jest to grabież ziemi, nie jestem pewien, jaki mroczny, przerażający władca wszystkich rzeczy, które IT diabelnie planuje jego nieograniczoną kontrolę i regulację rozwoju oprogramowania. Jeśli faktycznie mówisz o IEEE, to z pewnością mają one aspekt regulacyjny, ale zgodność ze standardami IEEE jest mniej więcej taka, jak zechcesz, a nie z celownika. Próbują opracować uniwersalne standardy branżowe, abyśmy wszyscy mówili tym samym językiem i zwiększali efektywność we wszystkich obszarach.

Ponadto normy, które ustalają, pomagają legitymizować wspólne praktyki i kładą podwaliny pod rozwój oprogramowania, aby ostatecznie stać się bardziej zdyscyplinowaną dziedziną inżynierii, podobnie jak inżynieria mechaniczna lub inżynieria chemiczna. Podczas gdy oprogramowanie zbliża się do tego celu, prawdopodobnie nigdy nie będzie to powszechnie akceptowana dyscyplina inżynierska.

Podstawowym problemem jest to, że twórca oprogramowania może robić wszystko, od napisania ładnego widgetu na pulpicie, po wdrożenie systemów prowadzenia pocisków. W jednym z nich dotkliwość i konsekwencje błędów są znacznie wyższe niż w innych, a zatem wymaga ściśle regulowanej dyscypliny inżynierskiej, aby podejść rozsądnie, bezpiecznie i skutecznie. Jest to bardzo podobne do wagi błędu w niepoprawnie zaprojektowanym pomoście i jego zwinięciu. Projektanci mostu muszą przestrzegać moich standardów technicznych, aby zapewnić jakość.

Nie nazwałbym tego bardziej rygorystycznymi przepisami, ale zamiast tego barierami wejścia. W tym względzie uważam, że jest jakaś zasługa. W celu zwiększenia jakości jest to bardzo dyskusyjne.

Obecnie każdy John / Jane Doe może napisać program. Nie ma bariery wejścia. Weź kilka książek o skryptach i technologii internetowej i zacznij hakować, a co gorsza, po prostu zacznij Googling, aby dowiedzieć się, jak to zrobić.

Kiedy jako zbiorowa całość zdecydujemy, że może czas zwiększyć bariery wejścia, utrzymać branżę na wyższym poziomie, ewoluować od hakera / rzemieślnika do inżyniera, tego rodzaju regulacje, na których jestem cały.

Obecnie programuje się zbyt wiele osób niewykwalifikowanych. Niezależnie od tego, czy pracują w systemach krytycznych, wciąż produkują kod, wciąż produkując Big Balls of Mud .

W związku z tym dobrą regulacją jest samoregulacja lub bardziej trafne tworzenie barier wejścia. Ponieważ mówimy: hej, nie możesz tak po prostu wyjść z ulicy i nazwać się inżynierem oprogramowania. Musisz zdemaskować poziom umiejętności.

Umiejętność demonstrowania jest czymś więcej niż tylko testem lub zdobyciem „odznaki honoru”. Test jest tylko potwierdzeniem. Prawdziwa walidacja to szkoła, staż, praktyka, mentoring u seniorów, praktyka - wszystko to jest jej częścią.

Widzę, co IEEE stara się osiągnąć, ale w tym momencie jest to bezowocne ćwiczenie. Branża zmienia się szybko, zbyt duże zapotrzebowanie na wypchnięcie produktu za drzwi, nastawienie „hakerów” itp. Przepisy muszą pochodzić z wewnątrz, jeśli w ogóle.

Nie przeczytałem tego artykułu, ale jeśli pytanie dotyczy tego, czy regulacja branży oprogramowania może przynieść korzyści ludzkości, myślę, że zależy to od okoliczności:

1. Cała branża obejmuje wiele różnych dziedzin, z których niektóre mają kluczowe znaczenie dla życia (np. Kontrolują dawkę promieniowania w urządzeniu medycznym), a niektóre nie są (aplikacja Facebook „Jaki Muppet Czy jesteś?”). Nie widzę żadnego argumentu za regulacją dla aplikacji, w których stawki są niskie.

2. Nie należy zaczynać od regulacji prawnych. Zamiast tego należy zacząć od programu certyfikacji dla programistów. Tylko wtedy, gdy program certyfikacji przynosi wymierne korzyści, powinna istnieć kwestia regulacji prawnej.

3. Nawet jeśli program certyfikacji daje wymierne wyniki, prawdopodobne jest, że przemysł ustandaryzuje wymaganie tego certyfikatu ze względów ściśle biznesowych i nie potrzebowalibyśmy regulacji prawnych. (Właśnie dlatego istnieją delegacje takie jak MCSE - firmy wolą wynająć MCSE dla domen, w których MCSE są szkolone.)

4. To powiedziawszy, nadal istnieją dziedziny, w których uzasadnienie biznesowe jest powodowanie szkód (często są to negatywne efekty zewnętrzne , czasem są wynikiem siły rynkowej niektórych instytucji). Na przykład w obszarze może znajdować się jeden lokalny szpital; w tym przypadku jakość oprogramowania zaplecza może mieć ogromny wpływ na poziom opieki, jaką otrzymuje pacjent, ale nie robi dużej różnicy w wyborze szpitala. Szpital niekoniecznie ma więc wiele uzasadnienia biznesowego do inwestowania w deweloperów wyższej jakości. W takim przypadku może istnieć sprawa zdrowia publicznego regulująca programistów, których szpital może zatrudnić.

MOIM ZDANIEM.

Muszę odpowiedzieć na to ...

Zaczynając od tego, co powiedział @JathanathanHenson i wpis @gnat, co mówię jest w porządku, ludzie, którzy mają pieniądze, mogą płacić za certyfikowane rzeczy, ludzie lub kraje, które nie mają pieniędzy, nie mogą płacić za licencje (tyle za certyfikowane rzeczy ), więc nadal będą występować renegaci, jeśli to wejdzie w życie. Nawet jeśli tradycyjne (i nie tak tradycyjne) metody dostarczania są zamknięte, ludzie nadal znajdą sposoby dostarczania oprogramowania zainteresowanym użytkownikom. Nawet jeśli oznacza to opracowanie innego protokołu HTTP lub nawet alternatywnego stosu całej sieci, koncentruje się tylko na uczynieniu połączeń niewykrywalnymi (patrz ostatni akapit, dla kogoś, kto może to zrobić).

Również pomysł zapłaty za coś jest zagrożony, ponieważ świat staje się coraz biedniejszy, więc coraz więcej ludzi będzie miało coraz mniej pieniędzy, aby zapłacić za rzeczy, są nawet kraje, które używają oprogramowania FOSS, bez żadnego certyfikacja (Brazylia i Indie przychodzą na myśl, ale są pewne inne), a niektóre z tych krajów stają się duże, naprawdę duże. Używają niecertyfikowanego oprogramowania nieznanych programistów, których umiejętności są nieznane.

Ponadto, nawet jeśli istnieje jakiś rodzaj certyfikacji, certyfikacja będzie tylko poświadczać wiedzę, a nie etykę, po prostu myśl, że niektórzy lekarze używają narządów, które są usuwane w nieautoryzowany sposób od ludzi, więc byliby też certyfikowani programiści, którzy nie kieruj się etyką i pisz niechlujny kod celowo lub nieumyślnie. Podczas gdy w większości projektów FOSS, większość potencjalnie niewykwalifikowanych programistów również przegląda kod od innych i próbuje znaleźć błędy, w taki sposób, że programowanie parami jest czymś małym.

Wreszcie, co powiesz o grupach hakerskich (nie grupach hakerów w czarnych kapeluszach, ale grupach w białych lub szarych kapeluszach), które wiedzą znacznie więcej na temat bezpieczeństwa i rozwijają oprogramowanie zabezpieczające w sposób, który pasuje tylko do najbardziej wyspecjalizowanych programistów z niektórych departamentów rządowych.