Po pierwsze, uważam, że ważne jest, aby pamiętać, że rzeczywista odpowiedzialność prawna będzie się różnić w zależności od przypadku, nigdy nie jest tak prosta, jak: „To inżynier, to ich wina”. W sytuacjach, w których coś się dzieje i toczą się postępowania sądowe, prawdopodobnie będą wymieniać każdą powiązaną firmę i wszystkie kluczowe osoby w firmach odpowiedzialnych za projekt. Wydaje mi się jednak, że mogę przekazać ogólne informacje na podstawie moich doświadczeń i tego, co powiedziano mi podczas szkolenia w zakresie odpowiedzialności prawnej.
Osobiście większość winy w tej sytuacji spoczywa na właścicielu, który korzysta z planów, które mają lata, i nikt nie powinien ich sprawdzać ani aktualizować. Widziałem (małe) problemy z tym na moim stanowisku. Rysunki są wypełniane i wysyłane do innego działu w celu zatwierdzenia, i bez względu na przyczynę, siedzą na biurku inżyniera aplikacji przez miesiące, niekiedy w ciągu roku lub powyżej roku. Rysunki są następnie wysyłane w stanie, w jakim się znajdują, ale wewnętrzne zmiany w standardach rysunkowych od czasu ich pierwotnej aktualizacji nie są przestrzegane. Są to drobne problemy, ale łatwo zauważyć, że dzieje się to na większą skalę i ma poważniejsze konsekwencje.
Rysunki powinny być datowane. To dość powszechna praktyka i jest to jeden z dobrych powodów. Chcemy wiedzieć, kiedy powstały rysunki, aby określić, co zmieniło się od tego projektu, czy to będą standardy, kodeksy, prawa, czy po prostu części interfejsu. Jeśli rysunki są wykonane zgodnie z kodeksami i normami obowiązującymi w tym czasie, nie widzę, w jaki sposób inżynier może zostać pociągnięty do odpowiedzialności za ten projekt, chyba że można wykazać, że inżynier znał kod wymagający korekty ze względu na bezpieczeństwo zagadnienia. W takim przypadku dopasowanie wydruku do kodu nie jest wystarczająco dobre, ponieważ wiemy, że kod nie zapobiegnie niektórym problemom.
Naprawdę sprowadza się to do faktu, że w procesie projektowania należy wziąć pod uwagę wszelkie kwestie bezpieczeństwa, a tam, gdzie ryzyka nie można wyeliminować, należy wyjaśnić, jakie jest ryzyko i jak można je ograniczyć do końca. użytkownik.
W drugim punkcie brzmi to jak bardzo szara strefa i naprawdę nie mogłem omawiać żadnych aspektów prawnych. Ale powiem, że myślę, że jeśli inżynier wie, że projekt jest nieaktualny i może w jakiś sposób powodować problemy, ponoszą etyczną odpowiedzialność za kontakt z kimś nadal związanym z projektem i poinformowanie go o zaistniałej sytuacji . Może nie jest to ich odpowiedzialność prawna, ale myślę, że jest to słuszne.
Powinno być prawie oczywiste, że każdy inżynier nadal związany z projektem ma ten sam obowiązek, tylko silniejszy, stwierdzenia, że projekty muszą zostać zaktualizowane i nie można ich używać w ich obecnej formie.
Aby dać kontekst, główny produkt, który produkuje moja firma, może być wyjątkowo niebezpieczny w środowisku operacyjnym. Ochrona jest absolutnie wymagana, chyba że produkt jest całkowicie osłonięty przez inne części maszyny. Samo zabezpieczenie może się nieznacznie różnić w zależności od firmy, ale w dużej mierze jest takie samo, ponieważ podlega normie ISO. Jednak standard ten zmienił się na przestrzeni lat, a nawet organizacja, która tworzy standard podstawowy, uległa zmianie. Oznacza to, że mamy stare projekty, które zawierają stare zabezpieczenia, które są nadal aktywne w naszym systemie. Mamy jednego pracownika, który ma ogromną wiedzę na temat branży, w szczególności kodów bezpieczeństwa, a nawet zasiada w niektórych komitetach ds. Bezpieczeństwa. Dba o to, aby nowe projekty były zgodne ze standardami ochrony, a stare produkty były aktualizowane w razie potrzeby. Czasami oznacza to posunięcie się do tego, aby powiedzieć klientowi, że nie sprzedamy mu tego produktu, jeśli nie pozwoli nam zaktualizować zabezpieczenia (nowsze zabezpieczenia są w niektórych przypadkach droższe). Nie zawsze jest najpopularniejszą osobą, ale to jego praca i tak zarządzamy naszą zgodnością kodu w świecie, w którym kody i standardy nie są spójne.