Uwaga: Przy konstruowaniu tej prezentacji wykorzystano udostępnione w sieci elementy wykładu, którego autorami są:

Kazimierz Subieta

Instytut Podstaw Informatyki PAN,

Warszawa

Ewa Stemposz

Polsko-Japońska Wyższa Szkoła

Technik Komputerowych, Warszawa

Jedną ze strategii zwiększenia efektywności pracy zespołów projektujących systemy informacyjne jest wielokrotne używanie raz opracowanych fragmentów projektu lub modułów programowych. Ponowne użycie wcześniej opracowanego fragmentu projektu albo modułu programu ma wiele zalet, wśród których na plan pierwszy wysuwają się: obniżenie kosztów, przyspieszenie realizacji projektu oraz minimalizacja błędów.

Istotą ponownego użycia jest wykorzystanie efektu aktywności zespołu projektowego z procesu  konstrukcji jednego produktu (również pomysłów czy  doświadczenia w ogóle) do wytworzenia innego produktu. Ponowne użycie powinno być pojmowane w terminach całego cyklu życiowego produktu programistycznego. Kiedy ponownemu użyciu podlegają produkty skonstruowane we wczesnych fazach cyklu życiowego, to prawdopodobieństwo ponownego  wykorzystania produktów innych faz jest także wysokie. Nie tylko czynniki techniczne mają wpływ na osiąganie zysków z ponownego użycia. Ważna jest też organizacja.

Ponowne użycie nie zdarza się przypadkiem ani w sposób spontaniczny.

Wymaga świadomych inwestycji!

Wymaga więc także wiedzy o tym,  jak postępować, by te  inwestycje w  ponowne użycie zwróciły się.

Korzyści, jakie przynosi ponowne użycie:

• Z  reguły znacznemu skróceniu ulega czas  konstruowania oprogramowania.

• Koszt rozwoju i utrzymania oprogramowania   oraz całego systemu zostaje także zwykle    poważnie zmniejszony.

• Używane, a więc z reguły dobrze sprawdzone  (przetestowane), składniki oprogramowania   zawierają mniej błędów niż te, które są    konstruowane od podstaw, dzięki czemu   wzrasta niezawodność i poprawność   całości systemu.

• Wzrost efektywności poszczególnych    składników  oprogramowania, używanych   wielokrotnie, podnosi efektywność całego   systemu.

•  Przenaszalność poszczególnych fragmentów   oprogramowania (będąca warunkiem   koniecznym przy stosowaniu ponownego   użycia) zwiększa możliwość doprowadzenia   do przenaszalności całego systemu.

Potencjał ponownego użycia:

Potencjał ponownego użycia aktywu, czyli  prawdopodobieństwo jego wykorzystania w wielu produktach  jest wysokie, gdy aktyw  posiada pewne pożądane właściwości, które zbierzemy i omówimy na następnym slajdzie.

Potencjał ponownego użycia jest większy, gdy aktyw jest:

•generyczny, czyli dostatecznie uniwersalny o szerokim przeznaczeniu,

•hermetyczny, wyizolowany z otoczenia, maksymalnie niezależny od  kontekstu, z dobrze zdefiniowanym interfejsem,

•spójny i kompletny,

•niezawodny,

•odporny na błędy i wyjątki, a przez to bezpieczny,

•dobrze udokumentowany, łatwy do zrozumienia,

•łatwy do testowania,

•łatwy do konserwacji  poprzez  wbudowane możliwości adaptacji,  specjalizacji, modyfikacji,

•zestandaryzowany,

•przenaszalny na różne platformy sprzętowo/programowe (dotyczy to języków programowania, systemów operacyjnych,  sprzętu, wymagań niefunkcjonalnych,  itp.),

•legalizowany (to znaczy, że posiada różne certyfikaty).

Co może być aktywem podlegającym ponownemu użyciu?

Wzory dokumentacji

Wyniki analizy dziedziny problemu

Specyfikacje wymagań na systemy (powtórne użycie specyfikacji  wymagań na  pewien system w celu skonstruowania nowej wersji  tego systemu czy osadzenia go  na nowej platformie,  jak i wykorzystanie  tej specyfikacji  do konstrukcji innego,  podobnego systemu).

Architektura logiczna systemu

Wzorce projektowe, czyli powtarzające się struktury projektowe lub rozwiązania odnoszące się do analogicznych sytuacji.  Wzorce są szczególnie przydatne w sytuacjach, kiedy inne formy  ponownego użycia stają się bezużyteczne, np. z  powodu fundamentalnych różnic  w zakresie platformy sprzętowej,  systemu operacyjnego lub języka programowania.

Składniki oprogramowania, np.:  fragmenty kodu, biblioteki procedur,  klasy, moduły, podsystemy, szkielety aplikacji czy też całe aplikacje.

Przypadki testowe,  procedury testowe,  plany testów

Formularze kontroli jakości

Materiały i procedury szkoleniowe

Inne aktywa (Do tego zalicza się np. wykorzystanie nabytej  wiedzy i doświadczenia.)

Przy realizacji postulatu powtórnego użycia elementy podlegające temu powtórnemu użyciu mogą mieć różny charakter, co jest opisywane przez jeden z czterech modeli:

•Model czarnej skrzynki

•Model szklanej skrzynki

•Model białej (otwartej) skrzynki

•Model szarej skrzynki

•Modele te zostaną teraz kolejno omówione

Model czarnej skrzynki:

Przykładem czarnej skrzynki może być np. biblioteka procedur  w postaci skompilowanej czy też zamknięty pod względem formy formularz.

Model czarnej skrzynki uważa się za najbardziej pożądany stereotyp aktywu ponownego użycia.

Z drugiej strony, jest to model najtrudniejszy do opracowania, szczególnie w małych  organizacjach.

„Czarna skrzynka” może być użyta poprzez odsyłacz lub poprzez skopiowanie.

Częściej stosowane jest kopiowanie aktywu, które z kolei  może być nie wskazane, gdy aktyw jest na bieżąco utrzymywany (pielęgnowany) przez odpowiednią  komórkę.

W takim przypadku  kopiowanie  powoduje, że akcje usunięcia błędów i modyfikacje wprowadzane na bieżąco przez opiekunów aktywu nie będą automatycznie propagowane do kopii funkcjonujących w nowszych i pozornie doskonalszych systemach.

Model czarnej skrzynki  występuje często w postaci sparametryzowanej.

Zakłada to ponowne użycie transformacyjne: Projektant dostarcza specyfikację, a czarna skrzynka - generator aplikacji - generuje implementację. Rozwiązanie takie uważa się za bardziej uniwersalne.

Przykładem takiego rozwiązania są wszelkie parametryczne generatory oprogramowania (np. generatory programów tworzących raporty).

Wadą takiego rozwiązania jest konieczność precyzyjnego ustalenia semantyki parametrów w powiązaniu z sytuacjami, w których jest  używany dany aktyw. Zmniejsza to korzyści ponownego użycia.

Tendencja do nadmiernego zwiększania uniwersalności aktywu powoduje  często niepożądany rozrost liczby parametrów oraz stopnia ich złożoności, a także wzajemnej zależności pomiędzy nimi, co utrudnia korzystanie z zasady ponownego użycia, które powinno preferować prostotę.

Model szklanej skrzynki:

Przy tym modelu zarówno budowa aktywu, jak i jego cechy zewnętrzne są widoczne, chociaż nie można ich zmienić.

Znajomość budowy aktywu i zrozumienie zasad jego działania  sprzyjają właściwemu stosowaniu, ale niemożność dokonania jakichkolwiek zmian może być źródłem frustracji.

Model białej skrzynki:

Użytkownik widzi strukturę aktywu i w zasadzie może go dowolnie modyfikować.  Przykładem mogą tu być wszelkiego rodzaju wzorce projektowe, wzorce dokumentacji,  fragmenty tekstu programów, itp.

Model białej skrzynki jest najłatwiejszy do wdrożenia, gdyż zasadniczo polega na opisaniu pewnego wykonanego fragmentu dokumentacji lub oprogramowania.

Taki opis może być jednak trudno generalizowalny, zaś zmiany aktywu przez osoby inne niż konstruktor aktywu są ryzykowne i  mogą doprowadzić do naruszenia  założonych na początku własności.

Z drugiej strony, dokładny opis fragmentów,  które mogą podlegać zmianom oraz określenie dopuszczalnego zakresu  zmian może okazać się bardzo trudnym zadaniem.

Użycie białej skrzynki następuje  poprzez skopiowanie i zmodyfikowanie.

Niektórzy specjaliści postulują mianowicie wprowadzenie dodatkowego elementu  pośredniego między czarną a białą skrzynką,

tzw. szarą skrzynkę. W modelu szarej skrzynki konstruktor aktywu będzie mógł określić, które części aktywu i dla jakich użytkowników będą widoczne.

Próby wprowadzania technologii ponownego użycia do firm często kończą się niepowodzeniem. Powodem tego bywają przeważnie nie czynniki  technologiczne,  ale  organizacyjne, a nawet socjologiczne czy  psychologiczne.

Źródła trudności:

•Powszechna niechęć do wprowadzania jakichkolwiek zmian. Ponowne użycie wymusza zmianę w sposobie myślenia
o całości  procesu  produkcji  oprogramowania,

•Przekonanie osób ze szczebli kierowniczych, że technologia ta obdarzona jest  wysokim stopniem ryzyka,

•Brak wypracowanych metod, jak należy w praktyce stosować tę technologię,

•Brak narzędzi wspierających,

•Brak bibliotek, katalogów aktywów,

•Brak mechanizmów nagradzania, systemu zachęt zarówno do produkowania nowych aktywów jak i do korzystania z już istniejących,

•Brak zaufania do obcych aktywów,

•Przekonanie, że ponowne użycie jest wrogiem kreatywności.

Promowanie technologii ponownego użycia:

• Ponowne użycie musi być umiejętnie   promowane, jeśli  ma być zakończone   sukcesem.

• Promocja musi być skierowana do osób z  różnych poziomów  w hierarchii firmy.

•Ponowne użycie stanowi  fundamentalną   zmianę w sposobie ich pracy i jak każda   zmiana będzie odpierane.

•uwidacznianie celów i zysków możliwych do osiągnięcia dzięki wprowadzeniu   tej technologii,

•nauczanie technik ponownego użycia,

•stworzenie systemu nagradzania, który to organizacyjnie wesprze.

Scenariusz produkcji i konsumpcji aktywów:

Wysoka jakość elementu ponownego użycia posiada w tej technologii  ogromne znaczenie. Konsument nie będzie korzystał z elementu  ponownego użycia, o ile napotka jakiekolwiek trudności,  pomijając fakt, że musi włożyć pewien wysiłek w wyszukanie gotowych elementów, które mógłby wykorzystać w procesie tworzenia konkretnego oprogramowania.

W większości firm ponowne użycie nie jest podtrzymywane organizacyjnie.

Oznacza to, że konstruktor oprogramowania zyska większe uznanie (w  bezpośredni sposób przekładające się na pieniądze)  wtedy,  gdy skonstruuje oprogramowanie od zera, niż gdy wykorzysta już istniejące elementy, tzw. syndrom “nie-wynaleziono-tutaj”  (NIH, Not-Invented-Here).

Jeśli technologia ponownego użycia ma się upowszechnić to konieczna jest zmiana systemu wynagradzania.

Nagrody finansowe, jak postuluje wielu autorów, stanowią co prawda silny element systemu zachęt, ale jedynie w pierwszym etapie wprowadzania technologii ponownego użycia.

Wiele badań wskazuje na to, że w dłuższym okresie czasu, mają one znacznie mniejsze znaczenie niż zadowolenie z pracy, uznanie współpracowników
i przełożonych oraz możliwość realizowania się w ciekawej, stawiającej wyzwania pracy.

Ustanawianie bibliotek aktywów ponownego użycia polega na zdefiniowaniu  mechanizmów,  umożliwiających przechowywanie, zarządzanie i udostępnianie aktywów.

Ustanowienie mechanizmów  umożliwiających przechowywanie, zarządzanie i udostępnianie aktywów gronu użytkowników zawsze stanowi ważny krok do przodu na drodze upowszechniania  technologii ponownego użycia. W praktyce, przedsiębiorstwa  wprowadzając technologię  ponownego użycia, wolą na początku poeksperymentować z  niewielką  liczbą aktywów. Zarządzanie nimi nie musi być wtedy zbyt wyrafinowane. Z upływem czasu  możliwe, a nawet wysoce prawdopodobne, są zarówno  modyfikacje przechowywanych aktywów,  jak i wzrost ich liczby. Utworzenie biblioteki  staje się wtedy krytyczne.

Biblioteka ponownego użycia może nie być konieczna, gdy:

•Przedsiębiorstwo posiada stabilny personel.  Jako przykład może tu  posłużyć fakt dużej skuteczności działania firm japońskich mimo stosowania stosunkowo prostych metod zarządzania zbiorem  aktywów przeznaczonych do wielokrotnego wykorzystywania.

• Przedsiębiorstwo  praktykuje technologię ponownego użycia w oparciu o techniki generacyjne, a nie techniki kompozycyjne.

Zalecane jest, by  proces konstrukcji  biblioteki ponownego użycia  rozpoczynał się od określenia:

rodzajów przechowywanych aktywów,

fizycznej i logicznej organizacji  biblioteki,

schematu klasyfikacyjnego,

mechanizmów  regulujących członkostwo aktywów  w zasobach   bibliotecznych,

źródeł i sposobów  nabywania aktywów,

wytycznych ułatwiających konstruowanie nowych i przekształcanie   istniejących aktywów w elementy biblioteki,

narzędzi wspierających operowanie na zawartości biblioteki: narzędzi    katalogujących, narzędzi  konfigurujących, przeglądarek,   wyszukiwarek  i  repozytoriów,

personelu,  który zajmowałby się obsługą biblioteki.

Ustalenie rodzajów przechowywanych aktywów  niezbędne jest  nie tylko do określenia wymagań na zawartość i organizację biblioteki, ale także do ustanowienia wytycznych ułatwiających konstruowanie elementów spełniających odpowiednie wymagania.

Przesłanka: Aktywa duże, złożone,  na wyższym poziomie abstrakcji i pochodzące z wcześniejszych etapów  konstrukcji produktu programistycznego posiadają większy potencjał ponownego użycia i tym samym są lepszymi  kandydatami  na elementy  składowe przyszłej biblioteki.

Biblioteka scentralizowana jest zaplanowana z myślą o tym, że będzie dostępna wszystkim chętnym.

Zalety: Konstrukcja i konserwacja biblioteki jest
z reguły przeprowadzana w bardziej formalny sposób, tzn. przestrzegane są obowiązujące w danym przedsiębiorstwie  standardy,  np. na programowanie,  nazewnictwo, kryteria weryfikacji, itp. Ponadto, zostaje ustanowiony personel odpowiedzialny za działalność biblioteki

Wady: Rosnąca liczba aktywów - nieuniknione zjawisko na przestrzeni czasu - pociąga za sobą konieczność zwiększania nakładów nie tylko na konserwację biblioteki, ale i na dostęp do aktywów.

Praktyka wykazuje, że kilka bibliotek lokalnych w miejsce jednej scentralizowanej, zawierających maksymalnie  do kilkuset aktywów  ponownego użycia (rzadko powyżej trzystu)  w pełni zaspakaja wymagania tej grupy czy dziedziny zastosowań, na potrzeby których zostały  skonstruowane,  przynosząc przy tym znaczące korzyści.

Wady: Poszczególne lokalne biblioteki mogą zawierać bardzo podobne aktywa, a nawet wręcz duplikaty. Ponadto, niektóre grupy osób czy dziedziny zastosowań mogą potrzebować aktywów  powiązanych koncepcyjnie z inną lokalną biblioteką.

Podejście łączące obie koncepcje:

W pierwszym kroku,  aktywa ponownego użycia byłyby umieszczane w lokalnych bibliotekach.

Po analizie i  weryfikacji  ich przydatności dla różnych grup czy dziedzin zastosowań,  mogłyby być przesuwane do biblioteki centralnej.

Każda z grup użytkowników miałaby zapewniony dostęp do biblioteki centralnej i swojej lokalnej.

Logiczna organizacja biblioteki:

Warstwa 1  Aktywa tu umieszczane nie podlegały żadnej  weryfikacji jakości czy przydatności dla potrzeb ponownego użycia.

Warstwa 2  Aktywa były wykorzystane przynajmniej w jednej aplikacji i zachowują przyjęte w danej firmie standardy na jakość i  dokumentację. Nie były przygotowywane do wielokrotnego wykorzystywania. Również ich dokumentacja nie została sporządzona zgodnie z zasadami przyjętymi dla aktywów ponownego użycia.

Warstwa 3  Aktywa zostały skonstruowane zgodnie z zasadami przyjętymi dla elementów ponownego użycia,  ale nie poddano ich żadnemu procesowi weryfikacji; innymi słowy nie posiadają certyfikatów przydatności dla ponownego użycia.

Warstwa 4  Aktywa spełniają wszystkie wymagania, jakie są stawiane elementom ponownego użycia.

Ustanawianie schematu klasyfikacyjnego dla biblioteki aktywów do ponownego użycia

W  literaturze spotykane są trzy modele schematów klasyfikacyjnych:

oparte o metody wykorzystywane w bibliotekarstwie, wykorzystujące metody sztucznej inteligencji, stosujące systemy  hipertekstowe.

•  z ograniczoną liczbą terminów używanych do klasyfikacji i/lub  precyzyjnie  określonymi  zasadami łączenia tych terminów,   np.: schematów opartych o wyliczanie,  z  wykorzystaniem  wektora cech czy też par „cecha-wartość”,

•  bez jakichkolwiek ograniczeń na liczbę terminów, a czasami  i  na zasady ich łączenia, np. rozwiązania pełnotekstowe.

Zalety: Schematy klasyfikacyjne oparte o wyliczanie są przejrzyste, łatwe do   zrozumienia i wykorzystania.

Wady: Schematy takie są trudne do   modyfikacji. Kolejny problem - co zrobić z aktywami, które mogłyby zająć miejsca   w więcej niż jednym węźle hierarchii?

Nie udowodniono wyraźnej przewagi jednych, z opisanych powyżej  schematów, nad innymi.

Metryki wykorzystywane do porównywania efektywności schematów klasyfikacyjnych opartych o metody stosowane w bibliotekarstwie:

•  stosunek ilości zwróconych,  relewantnych dla   sformułowanego  zapytania aktywów, do całkowitej ilości    relewantnych aktywów pozostających w zasobach   testowanej biblioteki,

•  precyzja, czyli stosunek ilości zwróconych, relewantnych dla    sformułowanego zapytania aktywów, do całkowitej ilości   zwróconych  aktywów,

•  szybkość wyszukiwania,

•  łatwość użycia,

•  pomoc w zrozumieniu istoty aktywu.

Źródła i sposobów nabywania aktywów:
Proces wybierania kandydatów do biblioteki ponownego użycia powinien bazować na systematycznym uczestniczeniu w pracach nad projektami prowadzonymi w firmie oraz przeglądaniu ofert pojawiających się na rynku.
Elementy, na które należy zwracać uwagę szacując potencjał ponownego użycia aktywu:
Jak wiele razy aktyw może być wykorzystany w jednym i tym samym produkcie? W
różnych produktach, bieżących lub przyszłych?
Jaki jest koszt przygotowania/utworzenia/nabycia aktywu?
Jaka jest strategiczna waga projektów, w których aktyw mógłby być zastosowany?
Jaka jest długość przewidywanego czasu życia aktywu, szczególnie w porównaniu do
czasu potrzebnego do jego przygotowania/utworzenia/nabycia?

Jakie koszty będą musiały być ponoszone na konserwację aktywu, czyli korektę błędów,

modyfikacje czy rozszerzenia?

Jakie koszty będą musiały być ponoszone na zarządzanie aktywem: obsługę wersji czy
wariantów?
Ile razy powinien być aktyw wykorzystany, aby zwrócić koszty
przygotowania/utworzenia/ nabycia łącznie z kosztami konserwacji i zarządzania?
Jakie korzyści przynosiłoby każdorazowe wykorzystanie aktywu, np. zmniejszanie
prawdopodobieństwa niepowodzenia projektu, oszczędności w nakładach pracy czy
poprawa jakości produktu?

Wniosek: W pierwszej kolejności powinny być rozważane aktywa o najwyższej przewidywanej liczbie zastosowań, w projektach o strategicznym znaczeniu dla przedsiębiorstwa, dla których poniesione koszty zwrócą się możliwie jak najszybciej, a ponadto są niezbędne.

Podsumowanie:

Ponowne użycie jest w większości przypadków nieuniknione. Trudno dziś wyobrazić sobie firmę komputerową, która nie dopracowałaby się żadnej technologii ponownego wykorzystania fragmentów jednych projektów, oprogramowania czy dokumentacji w  innych, aby nie wykorzystywała doświadczenia nabytego w pracach nad kolejnymi produktami.

Zadanie inżynierii oprogramowania polega na tym, aby nie było to działanie ad hoc, lecz by ponowne użycie wprowadzić jako w pełni  sformalizowaną, systematyczną zasadę i objąć nią w możliwie największym stopniu cały cykl życiowy produktu programistycznego, poczynając od specyfikacji wymagań, analizy,  projektu poprzez implementację oprogramowania, do planu testów, dokumentacji użytkowej, metod szkolenia, itd.

Ponowne użycie nie zdarza się. Wymaga świadomych inwestycji. Wymaga wiedzy o tym,  jak postępować, by  inwestycje w  ponowne użycie zwróciły się.