Customer Case – Integracja narzędzi w procesie wytwarzania

1.1.1. Informacja o firmie i sytuacja rynkowa

Firma jest jednym z producentów w sektorze motoryzacyjnym z siedzibą w Wielkiej Brytanii. Zajmuje się zarządzaniem produkcją trzech popularnych brytyjskich marek samochodów. Producent zatrudnia około 25 tysięcy pracowników i osiąga przychody na poziomie 13 miliardów funtów rocznie. Jednym z głównych celów firmy jest dostarczanie samochodów w sposób szybki, przy zachowaniu niskich kosztów produkcji oraz spełnieniu potrzeb rynkowych. Przy rosnącej produkcji oraz skomplikowaniu produktów, organizacja potrzebuje wypracować optymalny sposób, który pozwoli zarządzać produkcją oprogramowania dla pojazdów i jego różnymi wersjami. Aby sprostać tym wymaganiom, firma zdecydowała się w pierwszym kroku usprawnić proces rozwoju oprogramowania. Organizacja już wcześniej stosowała narzędzia wspierające procesy inżynierii wymagań, jednak bez rezultatów, co było spowodowane głównie brakiem integracji z innymi dyscyplinami cyklu życia, jak zarządzanie zmianami.

Oferuje członkom zespołów możliwe do dostosowania i dobrze zabezpieczone widoki projektu, które w czasie rzeczywistym przedstawiają informacje na temat nowych artefaktów, komentarzy i wymagań, na których członkowie zespołów powinni skoncen­trować swój wysiłek. Możliwość poglą­dowego spojrzenia na bieżący zbiór wymagań, a także wzięcia udziału w rozmowach na temat dodatkowych informacji, daje zespołom lepszy wgląd w sytuację oraz kontrolę nad nią.

1.1.2. Potrzeba

Firma wytwarza ponad 200 produktów w różnych konfiguracjach, co finalnie daje ponad 10 tysięcy różnych rozwiązań dostarczanych dla klientów. Przy tak dużej liczbie i różnorodności rozwiązań, firma potrzebuje kontrolować rozwój i zmiany wprowadzane w rodzinach produktowych, tak aby mieć wpływ i wgląd w to, jak zmiany wymagań dotyczących poszczególnych produktów mogą wpływać na inne wymagania z nimi powiązane. Typowym podejściem tego producenta jest tworzenie jednej bazowej wersji produktu, który następnie będzie ewoluował jako osobne projekty dostosowywane do wymagań różnych klientów. Kluczowa logika produktu zawsze pozostaje ta sama i stanowi cześć wspólną dla produktów z jednej rodziny. W momencie przygotowania kolejnej wersji produktu w danej rodzinie, musi on przejść pełen proces weryfikacji i walidacji bez znaczenia, czy wymagania dla rdzenia były już wcześniej weryfikowane. Z tego powodu – przedłużających się procesów związanych z opracowaniem kolejnych wersji – firma nie jest w stanie sprostać wymaganiom produkcji.

Dodatkowym wyzwaniem jest przygotowanie oszacowania kosztów produkcji dla każdego z produktów z osobna. Organizacja jest zmuszona do angażowanie dużej liczby osób w szacowanie potencjalnych kosztów produkcji. Wzrost liczby tworzonych produktów wymusza większą liczbę pracowników szacujących inicjatywy.

1.1.3. Rozwiązanie

Organizacja jednoznacznie stwierdziła, że powinna wewnętrznie opracować kompletne i zintegrowane środowisko narzędziowe, które będzie efektywnie wspierać wszystkie procesy. Brak integracji danych uniemożliwia obecnie zarządzać w sposób przewidywalny wytwarzaniem oprogramowania do produkowanych pojazdów. Wprowadzanie w organizacji różnych nowych narzędzi bez przemyślanej wcześniej strategii doboru, w krótkim czasie doprowadziło do duplikowania się informacji w wielu miejscach i braku możliwości zapanowania nad nimi. Firma zdecydowała się na wprowadzenie integracji już posiadanych systemów do zarządzania wytwarzaniem oprogramowania. Proces obejmował połączenie najbardziej kluczowych systemów z perspektywy producenta samochodów i obejmował:

  • Zarządzanie wymaganiami (wymagania, modele analityczne)
  • Zarządzanie testami (przypadki testowe, plany testów, defekty)
  • Zarządzanie zmianami (zadania)
  • Zarządzanie konfiguracją (repozytorium kodu, modeli, dokumentacji)

Na wczesnym etapie projektu organizacja zastanawiała się nad wymianą istniejących produktów na pakiet jednego dostawcy oprogramowania, nie było to jednak możliwe z powodu braku możliwości migracji danych zbieranych z wcześniejszych projektów. Podstawą do integracji było repozytorium wymagań, które przechowywało informacje na temat rozwijanych rodzin produktowych. Jako że w żadnej organizacji nie istnieje możliwość zatrzymania procesu produkcyjnego, modyfikacje zostały zaplanowane i zrealizowane etapowo. W kolejnych krokach projektu do repozytorium wymagań były dodawane kolejne systemy, które docelowo miały stworzyć w pełni zintegrowane środowisko pracy dla zespołów wytwarzania oprogramowania oparte o mechanizm śledzenia.

blog-image
Architektura integracji systemów na chwilę obecną (AS-IS)
blog-image
Docelowa architektura zintegrowanych systemów (TO-BE)

1.1.4. Etap 1 – Integracja wymagań z procesem zarządzania testami

W pierwszym kroku organizacja oczekiwała rozwiązania największego wyzwania technologicznego, a zarazem potrzeby biznesowej, jaką było uzyskanie relacji śledzenia pomiędzy wymaganiami, a przypadkami testowymi oraz planami testów. We wcześniej realizowanych projektach powiązania były realizowane przez stosowanie odpowiednich etykiet wymagań i przypadków testowych. Nie był to jednak optymalny sposób, ponieważ uniemożliwiał nawet proste przeszukiwanie powiązań, a dodatkowo nie był w stanie w zautomatyzowany sposób oznaczać przypadków testowych, które mogą mieć wpływ zmieniające się wymagania.

Wypracowanie śledzenia pomiędzy repozytoriami wymagań i testów pozwoliło na wcześniejszy wgląd zespołu testowego w wymagania i planowanie testów na wcześniejszym etapie produkcji. W poprzednim modelu pracy wymagania były przekazywane do departamentu testów w momencie ich pełnej akceptacji w formie specyfikacji, która musiała zostać poddana analizie. Integracja systemów pozwoliła na szybsze opracowanie planu testów oraz analizę wymagań przez zespół zapewnienia jakości w zakresie przygotowania przypadków testowych.

blog-image
Integracja pomiędzy systemami w ramach etapu 1

Podczas realizacji integracji podjęto decyzję o stworzeniu relacji wiele-do-wielu o charakterze dwustronnym, co umożliwiło tworzenie i monitorowanie relacji z innymi artefaktami zarówno z poziomu wymagań, jak i przypadków testowych. Wypracowana koncepcja pozwoliła na odejście od dokumentowania projektów w obszarach testowania i wymagań w postaci dokumentów na rzecz danych trzymanych w repozytoriach z opcją generowania dokumentu specyfikacji zbiorczej dla wymagań i testów. Całość procesów związanych z analizą wymagań, ich akceptowaniem przez interesariuszy oraz weryfikowaniem, została w pełni przeniesiona do repozytoriów. Pozwoliło to na wdrożenie systemowego podejścia do zarządzania wymaganiami, które umożliwia wyjątkową efektywność w środowiskach pracy z różnymi wersjami jednego produktu.

blog-image
Połączenie relacjami wymagań oraz przypadków testowych

1.1.5. Etap 2 – Integracja wymagań z zarządzaniem konfiguracją

W kolejnym kroku repozytorium wymagań i testów zostało zintegrowane z systemem zarządzania konfiguracją. Pozwoliło to na wersjonowanie i tworzenie wersji bazowych dla każdego produktu w ramach jednej kategorii. Wersje bazowe obejmowały wymagania dla konkretnej wersji produktu oraz przypadki testowe pozwalające na ich weryfikację na różnych poziomach testów. Informacje te były przechowywane wspólnie jako paczki informacji, a następnie przypisywane do konkretnych wydań oprogramowania przeznaczonego do pojazdów.

blog-image
Realizacja integracji pomiędzy systemami w ramach etapu 2

Podejście to umożliwiło traktowanie kolejnych produktów jako zmodyfikowanej wersji podstawowej. Wprowadzenie wersji na poziomie pojedynczych wymagań (nie całej specyfikacji), pozwoliło na obserwację sposobu zmieniania się wymagań pomiędzy kolejnymi wersjami w różnych produktach. Dodatkowo pojawiła się możliwość odszukania wersji produktu o parametrach zbliżonych do bieżących wymagań klienta, a następnie wprowadzenie wymaganych modyfikacji dużo niższym kosztem. Zastosowanie koncepcji ponownego użycia pozwoliło na skrócenie czasu związanego z procesami analizy o uśrednioną wartość 15% względem wartości początkowej.

blog-image
Objęcie wymagań oraz artefaktów procesu testowania zarządzaniem konfiguracją

1.1.6. Etap 3– Integracja wymagań z zarządzaniem zmianami

Po realizacji projektów pilotażowych mających na celu przetestowanie wypracowanego rozwiązania w oparciu o połączone repozytorium wymagań, artefaktów testowych oraz system zarządzania konfiguracją, przystąpiono do uzupełnienia koncepcji nowego podejścia o zarządzanie zmianami.

blog-image
Realizacja integracji pomiędzy systemami w ramach etapu 2

Pierwotnie system zarządzania zmianą był używany w firmie głównie do zgłaszania zadań i rozliczania czasu pracy poświęcanego na ich wykonanie. Przy integracji z istniejącym repozytorium wymagań organizacja zdecydowała się na wprowadzenie dodatkowych typów obsługiwanych obiektów związanych z zgłaszaniem zmian oraz defektów.

Wprowadzenie artefaktu, jakim był defekt miało na celu przeniesienie danych z systemu zarządzania jakością. Wizją klienta było traktowanie defektów jak typowych modyfikacji do wprowadzenia w istniejących systemach oraz łatwiejsze wiązanie z zadaniami do wykonania i wymaganiami. Prawdziwa rewolucja związana była z wprowadzeniem żądania zmiany (ang. change request) oraz modyfikacją sposobu procesowania zmian w istniejących produktach, tak by opierał się na otwieranie zgłoszeń i formalny proces realizowany w narzędziu. Integracja z istniejącym repozytorium wymagań wzbogaconym o możliwość wersjonowania, pozwoliła na łączenie żądań zmian przy budowanie nowych wersji oraz porównywanie różnych produktów ze sobą. Tworzenie takich zestawień ukazało różnice produktowe na poziomie pracochłonności w postaci zadań, które musiałyby zostać wykonane, aby daną zmianę zrealizować.

blog-image
Rysunek Objęcie artefaktów repozytorium wymagań oraz procesu testowania mechanizmem zarządzania zmianami

1.1.7. Zyski

Wprowadzenie integracji pomiędzy systemami było wieloetapowym projektem wymagającym od firmy podjęcia zmian organizacyjnych oraz poniesienia pewnych kosztów związanych z wypracowaniem integracji pomiędzy wcześniej wdrożonymi komercyjnymi produktami. Wprowadzenie integracji pomiędzy elementami cyklu życia umożliwiło obsługę kłopotliwego zarządzania różnymi wersjami oprogramowania oraz raportowanie informacji z całego procesu w czasie rzeczywistym. Organizacja wprowadzała m.in raporty dotyczące:

  • Czasu realizacji kluczowych działań - Czas poświęcony na realizację kluczowych zadań w odniesieniu do poszczególnych etapów/iteracji projektu.
  • Skuteczności wykrywania błędów - Liczba zgłaszanych błędów w zależności od fazy cyklu życia oprogramowania (testy wewnętrzne, testy akceptacyjne, eksploatacja itp.)
  • Średniego czas realizacji błędu/zmiany - Czas, jaki upłynął od momentu zgłoszenia błędu, żądania zmian itp. do chwili jego udostępnienia w produkcyjnym wydaniu oprogramowania.
  • Wieku niezamkniętych zmian - Czas, jaki upłynął od utworzenia zmiany w podziale na ich typy (zadania, zmiany, defekty)
  • Czasu realizacji zmiany - Czas, jaki upłynął od momentu zgłoszenia błędu, żądania zmian itp. do chwili jego udostępnienia w produkcyjnym wydaniu oprogramowania
  • Przewidywalności planowania pracy - Faktyczny czas realizacji elementu pracy w odniesieniu do szacowanego
  • Poziomu stosowania mechanizmu śledzenia (ang. traceability) - Liczba ustanowionych relacji pomiędzy elementami, np. pomiędzy wymaganiem a scenariuszem testowym
  • Dostarczonej korzyści biznesowa - Wymierna wartość biznesowa zrealizowana do tej pory w projekcie

Do korzyści niezwiązanych bezpośrednio z aspektem oszczędności (czas i finanse) można zaliczyć:

  • Możliwość śledzenie wymagań i testów pomiędzy różnymi produktami, dzięki zintegrowanemu repozytorium wymagań i testów.
  • Możliwe do śledzenia i audytu proces wytwarzania zgodny z wymaganymi regulacjami prawnymi
  • Wprowadzone procesy raportowania w projektach w oparciu o dane rzeczywiste, znajdujące się w strukturach zintegrowanych repozytoriów
  • Możliwość porównywania wersji tworzonych produktów pod względem implementowanych wymagań i przypadków testowych do realizacji
  • Szybsze planowanie wydań nowych wersji produktów, przez adaptację już istniejących wersji najbardziej zbliżonych do oczekiwanej przez klienta
  • Możliwość śledzenia zmian wprowadzanych pomiędzy wersjami produktów na poziomie zadań, defektów, zadań zmian oraz wymagań i artefaktów testowych

Wprowadzenie modyfikacji i usprawnień w ramach integracji danych pozwoliło organizacji na uzyskanie zgodności ze standardem technicznym ISO/IEC 15504 - SPICE for Automotive oraz normą ISO 26262 związaną z bezpieczeństwem funkcjonalnym pojazdów drogowych. Obie regulacje wymagały od procesu wytwarzania pełnej audytowalności oraz mechanizmów śledzenia, zrealizowano dzięki zintegrowaniu danych.