Wnioski z zarządzania wymaganiami: program okrętu podwodnego S-80

Program okrętów podwodnych S-80 pokazuje, dlaczego wymagania, ograniczenia, zmiany projektowe i kontrole weryfikacyjne muszą pozostawać ze sobą powiązane w projektach rozwoju produktów sprzętowych.

W rozwoju produktów sprzętowych zmiana projektu może rozwiązać bieżący problem, a jednocześnie wywołać nowe pytania w innych obszarach systemu. Dlatego zarządzanie wymaganiami nie polega wyłącznie na uchwyceniu tego, co produkt ma robić, ale także na utrzymaniu widoczności powiązanych ograniczeń, decyzji projektowych i kontroli weryfikacyjnych w miarę ewolucji projektu.

Hiszpański program okrętów podwodnych S-80 wyraźnie pokazuje ten schemat. W trakcie realizacji program napotkał poważny problem związany z masą i pływalnością. Przeprojektowanie pomogło rozwiązać ten problem, ale zaktualizowane wymiary jednostki wprowadziły nowy praktyczny kłopot: okręt podwodny był teraz zbyt długi dla portu, z którego miał korzystać.

To uniwersalna lekcja dla wszystkich zespołów rozwijających produkty sprzętowe — niezależnie od tego, czy budujecie okręt podwodny, czy urządzenie elektroniczne: gdy wymagania, ograniczenia, zmiany projektowe i kontrole weryfikacyjne są od siebie odłączone, zespołom trudno dostrzec, na co jeszcze dana zmiana może wpłynąć.

Najważniejsze wnioski

• Konflikty wymagań często ujawniają się wtedy, gdy krytyczne ograniczenia znajdują się poza przepływem pracy używanym do przeglądu zmian projektowych.
• Zespoły mogą ograniczyć to ryzyko, łącząc wymagania z ograniczeniami, decyzjami projektowymi i kontrolami weryfikacyjnymi, na które wpływają.
• Połączony przepływ pracy dotyczący wymagań ułatwia zobaczenie, co się zmieniło, na co to wpływa i co wymaga przeglądu, zanim poprawki staną się kosztowne.

Co wydarzyło się w programie S-80

Hiszpania uruchomiła program S-80, aby opracować nową klasę okrętów podwodnych. W trakcie prac program napotkał poważny problem związany z masą i pływalnością. Jednostka stała się cięższa, niż planowano, co wzbudziło obawy, czy po zanurzeniu będzie miała wystarczający zapas pływalności, aby niezawodnie wynurzać się na powierzchnię.

Projekt został zmieniony, aby rozwiązać ten problem. Jedną z kluczowych zmian było wydłużenie kadłuba, co pomogło przywrócić wymagany zapas pływalności. Ta modyfikacja zmieniła również fizyczne wymiary jednostki. Zaktualizowany okręt podwodny trzeba było następnie sprawdzić pod kątem infrastruktury, w której miał operować, a ten przegląd ujawnił praktyczny problem: nie mieścił się już w porcie.

Problem infrastrukturalny dodał kolejną warstwę pracy do programu, który i tak wymagał już poważnego przeprojektowania. Ostatecznie program stał się bardziej złożony, trwał dłużej i okazał się droższy, niż pierwotnie zakładano.

Ten przykład przypomina, że każde przeprojektowanie pozostawia jeszcze jedno pytanie: co jeszcze trzeba teraz sprawdzić?

Czego zespoły sprzętowe mogą nauczyć się z przypadku S-80

Większość zespołów sprzętowych działa w mniejszej skali niż program okrętów podwodnych, ale ten sam schemat może pojawiać się w codziennym rozwoju produktów: zmiana projektu może wpływać na wymiary, wymagania zgodności lub ograniczenia interfejsów wykraczające poza problem, który zespół właśnie próbuje rozwiązać.

Sama znajomość tych ograniczeń nie wystarczy. Właśnie tutaj zarządzanie wymaganiami ma znaczenie: pomaga zespołom utrzymywać je jako widoczne, powiązane i możliwe do przeglądu w miarę rozwoju projektu. W przypadku zespołów sprzętowych sprowadza się to do trzech praktycznych nawyków:

Utrzymuj widoczność krytycznych ograniczeń

Krytyczne ograniczenia nie powinny istnieć wyłącznie w notatkach ze spotkań, arkuszach kalkulacyjnych ani w czyjejś pamięci. Powinny być jasno zapisane i, tam gdzie to możliwe, sformułowane w mierzalny sposób, aby zespoły mogły je sprawdzać wraz ze zmianami projektu.

Łącz wymagania z decyzjami projektowymi

Wymaganie jest bardziej użyteczne, gdy jest powiązane z obszarem systemu, blokiem, obiektem projektowym lub działaniem inżynierskim, na które wpływa. Taki związek pomaga inżynierom zrozumieć, dlaczego dana decyzja projektowa ma znaczenie, które wymagania wspiera i na co jeszcze może wpłynąć, gdy projekt się zmienia.

Wykorzystuj identyfikowalność do przeglądu wpływu zmian

Identyfikowalność pomaga zespołom odpowiedzieć na praktyczne pytanie: na co jeszcze wpływa ta zmiana? Gdy wymagania pozostają powiązane z decyzjami projektowymi, ograniczeniami, kontrolami weryfikacyjnymi i dowodami, zespoły mogą zobaczyć, co się zmieniło, co nadal jest objęte zakresem i co wymaga przeglądu, zanim poprawki staną się kosztowne.

Jak pomaga połączony przepływ pracy dotyczący wymagań

Zespoły sprzętowe potrzebują czegoś więcej niż tylko miejsca do przechowywania treści wymagań. Dokumenty i arkusze kalkulacyjne mogą rejestrować wymagania, ale stają się trudniejsze w zarządzaniu wraz ze wzrostem złożoności projektu i koniecznością utrzymania powiązań każdego wymagania w całym łańcuchu inżynierskim.

Altium Requirements Portal został zaprojektowany, aby wspierać ten przepływ pracy poprzez zarządzanie wymaganiami, identyfikowalnością, odpowiedzialnością i weryfikacją w jednym współdzielonym środowisku. Zamiast traktować wymagania jako odizolowany tekst, zespoły mogą zobaczyć, co się zmieniło, na co to wpływa, kto odpowiada za kolejny krok i jak dane wymaganie zostanie sprawdzone.

Co jest „okrętem podwodnym” w Twoim projekcie?

Każdy projekt rozwoju sprzętu ma ograniczenia, które łatwo przeoczyć, gdy projekt posuwa się naprzód w szybkim tempie. Mogą mieć charakter mechaniczny, elektryczny, regulacyjny, operacyjny lub procesowy. Ryzyko nie polega na tym, że zespołom brakuje wiedzy, lecz na tym, że ważna wiedza nie zawsze jest rejestrowana, łączona i przeglądana, gdy projekt się zmienia.

To właśnie sprawia, że przypadek S-80 jest użyteczny niezależnie od swojej skali. Ten sam schemat może pojawić się w codziennym rozwoju produktów, gdy intencje inżynierskie, decyzje projektowe i dowody nie są z czasem utrzymywane jako wzajemnie powiązane.

Ułatw śledzenie wpływu zmian dzięki narzędziu do zarządzania wymaganiami, do którego ma dostęp cały Twój zespół.

Rozpocznij pracę z Requirements Portal →

Najczęstsze pytania

Co powoduje problemy z zarządzaniem wymaganiami w projektach sprzętowych?

Problemy z zarządzaniem wymaganiami często pojawiają się wtedy, gdy wymagania nie są powiązane z pracami projektowymi, ograniczeniami i kontrolami weryfikacyjnymi, na które wpływają. Wymaganie może istnieć, ale jeśli zespół nie widzi, z czym jest połączone, ważne skutki zmian mogą zostać przeoczone, gdy projekt się zmienia.

Dlaczego arkusze kalkulacyjne stają się trudne w zarządzaniu wymaganiami?

Arkusze kalkulacyjne mogą zawierać treść wymagań, ale wraz ze wzrostem złożoności projektu stają się trudniejsze w zarządzaniu. Zespoły potrzebują sposobu na utrzymanie powiązań wymagań z pracami projektowymi, historią zmian, statusem weryfikacji i dowodami w całym łańcuchu inżynierskim.

Jak identyfikowalność pomaga ograniczyć kosztowne poprawki na późnym etapie?

Identyfikowalność pomaga zespołom odpowiedzieć na praktyczne pytanie: na co jeszcze wpływa ta zmiana? Łącząc wymagania z decyzjami projektowymi, ograniczeniami, kontrolami weryfikacyjnymi i dowodami, zespoły mogą zobaczyć, co wymaga przeglądu, zanim poprawki staną się kosztowne.