SMC-S-012 Rozwój oprogramowania

Celem normy „SMC-S-012 Software Development”, opublikowanej przez Centrum Systemów Kosmicznych i Rakietowych (SMC) Dowództwa Kosmicznego Sił Powietrznych Stanów Zjednoczonych, jest określenie jednolitych wymagań dotyczących rozwoju oprogramowania dla systemów o znaczeniu krytycznym. Norma ta jest oparta na normie „MIL-STD-498 Military Standard: Software Development and Documentation” opracowanej przez Departament Obrony Stanów Zjednoczonych.

Niniejsza norma dotyczy opracowywania systemów o znaczeniu krytycznym, obejmujących oprogramowanie (takie jak systemy sprzętowo-programowe), systemy wyłącznie programowe i samodzielne produkty programowe. Normę tę można stosować w stosunku do wykonawców zajmujących się tworzeniem oprogramowania lub do wewnętrznych agencji dokonujących zakupów. Normę tę można dostosować do każdej kategorii oprogramowania, do której ma zastosowanie.

Niniejsza norma jest niezależna od jakiejkolwiek konkretnej metody lub narzędzia tworzenia oprogramowania. Żaden z wymogów niniejszej normy nie nakazuje stosowania jakiejkolwiek konkretnej metody lub narzędzia.

Model cyklu życia oprogramowania służy do organizacji głównych działań w procesie tworzenia oprogramowania.

• Programista musi wybrać model lub modele cyklu życia oprogramowania odpowiednie dla tworzonego oprogramowania. Projekt oprogramowania może mieć wiele modeli cyklu życia oprogramowania dla różnych kategorii tworzonego oprogramowania.
• Programista musi zapisać wybrany model lub modele cyklu życia oprogramowania w załączonym szablonie „Planu rozwoju oprogramowania”.
• W planie rozwoju oprogramowania programista musi umieścić opis każdego modelu cyklu życia oprogramowania, który będzie stosowany w projekcie.
• W przypadku każdego modelu cyklu życia oprogramowania, który ma zostać zastosowany, deweloper musi zdefiniować w planie rozwoju oprogramowania:
  • Na jakim etapie cyklu życia systemu zostanie on wykorzystany?
  • W jakich warunkach będzie używany?
  • Jakich elementów oprogramowania użyć
• Programista musi opracować proces tworzenia oprogramowania zgodny z wymaganiami umowy.
• Proces tworzenia oprogramowania powinien obejmować następujące główne działania i zintegrowane procesy:
  • Planowanie i kontrola projektu
  • Tworzenie środowiska programistycznego
  • Analiza wymagań systemowych
  • Projekt architektury systemu
  • Analiza wymagań oprogramowania
  • Architektura i projektowanie oprogramowania
  • Wdrażanie oprogramowania i testowanie jednostkowe
  • Integracja i testowanie jednostek
  • Testowanie kwalifikacyjne elementów oprogramowania
  • Integracja i testowanie elementów oprogramowania i sprzętu
  • Testowanie kwalifikacyjne systemu
  • Przygotowanie oprogramowania do przejścia do eksploatacji
  • Przygotowanie oprogramowania do przejścia na konserwację
  • Procesy zintegrowane:
    • Zarządzanie konfiguracją oprogramowania
    • Recenzje oprogramowania i oceny produktów
    • Zapewnienie jakości oprogramowania
    • Działanie korygujące
    • Wspólne przeglądy techniczne i zarządcze
    • Zarządzanie ryzykiem oprogramowania
    • Pomiar oprogramowania
    • Bezpieczeństwo i prywatność
    • Zarządzanie członkami zespołu programistycznego
    • Interfejs z agentami IV&V oprogramowania
    • Koordynacja z partnerami-programistami
    • Ulepszanie procesów projektowych

Te ważne działania mogą się pokrywać, być wdrażane iteracyjnie lub w różny sposób. Dotyczy różnych elementów oprogramowania i nie musi być wykonywana w kolejności podanej powyżej.

• Procesy rozwoju oprogramowania przez dewelopera powinny zostać opisane w planie rozwoju oprogramowania.

Ogólne wymagania dotyczące tworzenia oprogramowania obejmują ogólne wymagania dla deweloperów mające na celu spełnienie szczegółowych wymagań określonych w niniejszej normie. Bardziej szczegółowe wymagania zawarto w załączniku do normy (załącznik H.1).

• Metody tworzenia oprogramowania: Deweloper musi stosować systematyczne i udokumentowane metody we wszystkich działaniach związanych z tworzeniem oprogramowania. Te systematyczne metody rozwoju oprogramowania powinny zostać określone w planie rozwoju oprogramowania.
• Normy dla produktów programistycznych: Deweloper opracowuje normy przedstawiające wymagania, architekturę, projekt, kod, przypadki testowe, procedury testowe i wyniki testów. Standardy reprezentacji produktu są określone w planie rozwoju oprogramowania. Programista stosuje standardy określone w planie rozwoju oprogramowania w celu przedstawienia wymagań, architektury, projektu, kodu, przypadków testowych, procedur testowych i wyników testów.
• Śledzenie: Śledzenie zapewnia relację pomiędzy zawartością dwóch powiązanych produktów, na przykład relację pomiędzy każdym wymaganiem programowym a komponentami projektu oprogramowania, które spełniają to wymaganie. Dwukierunkowa identyfikowalność zapewnia dwukierunkową relację pomiędzy zawartością dwóch powiązanych produktów. Przykładem takiej dwukierunkowej relacji jest możliwość prześledzenia powiązań między każdym wymaganiem programowym a komponentami projektu oprogramowania, które spełniają to wymaganie, a także możliwość prześledzenia powiązań między każdym komponentem projektowym a wymaganiami programowymi spełnianymi przez komponent projektowy. Celem wymagań dotyczących dwukierunkowej identyfikowalności w tej sekcji jest śledzenie zarówno w górę, jak i w dół, aby zapewnić, że:
  • Wykaż, że wszystkie wymagania zostały przypisane do komponentów, wdrożone i przetestowane.
  • Wykaż, że nie mają zastosowania żadne dodatkowe wymagania
  • Dostarczanie informacji o wpływie proponowanych zmian
  • Podaj informacje o wpływie wykrytych problemów
  • Dostarczanie informacji na potrzeby konserwacji oprogramowania.
• Produkty oprogramowania nadające się do ponownego użycia: Deweloper musi wskazać produkty oprogramowania nadające się do ponownego użycia, które zostaną wykorzystane w celu spełnienia wymagań umowy. Zakres poszukiwań oprogramowania nadającego się do ponownego wykorzystania powinien zostać określony w planie rozwoju oprogramowania. Programista musi dokonać oceny produktów oprogramowania wielokrotnego użytku, które zostaną wykorzystane w celu spełnienia wymagań umowy. Kryteria, które będą stosowane przy ocenie oprogramowania nadającego się do ponownego wykorzystania, powinny być takie, jakie określono w planie rozwoju oprogramowania. Aby wybrać produkty programistyczne nadające się do ponownego wykorzystania, twórca musi zastosować co najmniej kryteria oceny zawarte w załączniku do normy (załącznik B). Kryteria oceny mogą mieć różną wagę w zależności od kategorii oprogramowania i różnych wymagań krytycznych. Wybrane produkty oprogramowania nadające się do ponownego wykorzystania muszą spełniać wymagania dotyczące praw do danych zawarte w umowie. Oprogramowanie nadające się do ponownego wykorzystania może być używane w takiej formie, w jakiej jest, lub może zostać zmodyfikowane i wykorzystane w celu spełnienia całości lub części wymagań.

Nasza organizacja, która od lat stara się wspierać przedsiębiorstwa z każdej branży, realizując szeroką gamę badań testowych, pomiarowych, analitycznych i ewaluacyjnych, dysponuje silną kadrą, która uważnie śledzi rozwój nauki i techniki na świecie oraz nieustannie się doskonali. W tym kontekście usługi testowania są również świadczone przedsiębiorstwom zgodnie ze standardem „SMC-S-012 Rozwój oprogramowania”.