rozdzial3.tex

\chapter{Przegląd potencjalnych technologii do realizacji projektu}
\label{cha:przegladTech}
W rozdziale opiszę technologie użyte do stworzenia prototypów i finalnej aplikacji.

%---------------------------------------------------------------------------

\section{Zdefiniowanie wymagań projektowych}
\label{sec:wymaganiaProjektowe}

Jednym z najważniejszych zadań podczas realizacji projektu jest zebranie i analiza wymagań projektowych. Wymagania projektowe to zbiór potrzeb danego produktu lub usługi, a także sposób ich działania. W inżynierii oprogramowania zbiór wymagań jest wykorzystywany w fazie projektowania nowego produktu. Wymagania pokazują, jakie elementy i funkcje są niezbędne w konkretnym przypadku. Istnieje bardzo dużo modeli opisujących ten proces. Większość z nich jest standaryzowana przez organizacje ISO oraz IEC pod numerem 12207 Systems and software engineering\cite{IsoIec2008}.

Przed zebraniem wymagań często wykonuje się jeszcze jeden etap - studium wykonalności, które składa się z analizy rynku, analizy ekonomicznej, analizy strategicznej oraz analizy technicznej. W zależności od rozmiaru projektu samo zbieranie wymagań, może zostać podzielone na etapy. Jest to bardzo częsta praktyka w projektach rządowych\cite{req}. Fazę wymagań dzielimy na:

\begin{enumerate}%[1)]
\item gromadzenie wymagań
\item analizowanie
\item specyfikowanie
\item zatwierdzenie
\end{enumerate}

Dobre wymagania projektowe charakteryzuje\cite{req}:
\begin{enumerate}%[1)]
\item Aktualność - wymaganie powinno pozostać aktualne z upływem czasu.
\item Jednoznaczność - wymaganie powinno być jasno sformułowane, bez subiektywnych opinii. Żargon techniczny i akronimy powinny być zdefiniowane w dokumencie. 
\item Kompletność - wymaganie powinno być zdefiniowane w jednym miejscu z kompletem niezbędnych informacji.
\item Obowiązkowość - każde niezbędny wymaganie musi zostać zdefiniowane. Brak wymagania oznacza wykluczenie z projektu.
\item Poprawność - wymaganie wypełnia wszystkie lub część potrzeb biznesowych, które są jasno określone.

\item Spójność - wymaganie odnosi się do jednej i tylko jednej sprawy.
\item Wykonalność - wymaganie musi być wykonalne w ramach ograniczeń projektowych.
\item Weryfikowalność - wymaganie powinno być weryfikowalne empirycznie lub poprzez analizę.
\item Zgodność - wymagania nie powinny być sprzeczne ze sobą.
\end{enumerate}

Istnieje wiele różnych cech, które charakteryzują dobre wymagania, ale są one specyficzne dla danej domeny technologicznej. Istnieje jeszcze jeden istotny podział wymagań. Podział na trzy kategorie:
\begin{enumerate}%[1)]
\item Wymagania funkcjonalne - definiują, co ma realizować system np. system powinien generować raporty.
\item Wymagania niefunkcjonalne - są to wymagania jakościowe. Opisują bezpieczeństwo, wydajność itp.
\item Wymagania ograniczeń - określają granice rozwiązania.
\end{enumerate}

Wszystkie wymagania powinny być weryfikowalne, poza wymaganiami ograniczeń typu ,,system nie powinien''.


\subsection{Model Kaskadowy}
\label{subsec:modelKaskadowy}

Pierwsze wzmianki o wymaganiach projektowych pochodzą z lat sześćdziesiątych ubiegłego wieku.\cite{appliedSoftware} IBM był pionierem badań dotyczących procesu tworzenia oprogramowania. W 1956 roku jeden z pracowników IBMu, Herbert D. Benington, podczas konferencji na temat zaawansowanych metod tworzenia oprogramowania, opisał model kaskadowy (inaczej zwany wodospadowym)\cite{advencedSoft}.

Model kaskadowy podzielony jest na 7 chronologicznych części:\cite{waterfallModel}

\begin{enumerate}%[1)]
\item Tworzenie wymagań projektowych
\item Projektowanie
\item Implementacja
\item Integracja
\item Testowanie i debugowanie
\item Wdrażanie
\item Utrzymanie i konserwacja
\end{enumerate}

Model kaskadowy jest sekwencyjny. Główną jego cechą jest podział na niezależne części, z których każda wykonywana jest po zakończeniu poprzedzającej. Zaletą takiego podejścia jest wykrywanie błędów we wczesnych etapach. 
Błąd wykryty podczas projektowania stanowi dużo mniejsze wyzwanie i jest łatwiejszy w naprawie, niż defekt, którego istnienie spostrzeżono dopiero w fazie wdrażania. Jednak takie rozwiązanie ma również swoje wady. Najistotniejszym problemem jest brak możliwości szybkiej zmiany na późnym etapie projektu. W realnych warunkach wymagania zmieniają się bardzo często, co dla nietrywialnych projektów może oznaczać ciągłe powroty do fazy projektowej. Bardziej fatalne w skutkach może okazać się złe określenie wymagań projektowych. Przykładowo:  podczas wdrażania klient stwierdzi, że oprogramowanie nie jest dostatecznie szybkie, co może być skutkiem ograniczeń technologicznych. W takim wypadku projekt jest zamykany. Kolejnym problemem jest słabe wykorzystanie zasobów ludzkich - testerzy muszą czekać na zakończenie pracy przez programistów. W 2001 roku przeprowadzono badanie 1027 projektów IT w Wielkiej Brytanii. Okazało się, że techniki zarządzania narzucające metodologię kaskadową były jednym z największych czynników, które wpłynęły na porażkę projektu \cite{sofscal}. Problemy te okazały się na tyle poważne, że dzisiaj nikt już nie korzysta z modelu kaskadowego. W genialny sposób Edward V. Berard podsumował kompleksowe specyfikacje modelu kaskadowego.
\begin{quote}
Walking on water and developing software from a specification are easy if both are frozen.
\end{quote}
%\quote{}

%\newpage

\begin{figure}[h!]
  \centering
	\includegraphics[scale=0.6]{waterfall}
	\caption{Schemat modelu kaskadowego.}
\end{figure}

\newpage

\subsection{Model spiralny}
\label{subsec:modelSpi}

Model spiralny jest to rodzaj procesu tworzenia oprogramowania. Kolejne etapy są podzielone na mniejsze części. Każda z tych części jest cyklicznie powtarzana w pętli, przez co plan jest przedstawiany w postaci spirali. Model spiralny, podobnie jak kaskadowy, posiada ścisłą kontrolę nad projektem. W początkowej fazie łączymy projektowanie z tworzeniem prototypów \cite{spiral}.

Pętle spirali są podzielone na sektory:  
\begin{enumerate}%[1)]
\item Definicja celów
\item Rozpoznanie i redukcja zagrożeń
\item Implementacja i zatwierdzanie
\item Ocena i planowanie
\end{enumerate} 

Wyraźną zaletą modelu spiralnego jest szczegółowa analiza zagrożeń. Model spiralny nie precyzuje, w jaki sposób maja być realizowane poszczególne pętle np. można użyć modelu kaskadowego. Podobnie jak w modelu kaskadowym, usuwanie błędów w końcowych etapach jest bardzo kosztowne.

\begin{center}
	\includegraphics[scale=0.6]{ModelSpiralny}
	\captionof{figure}{Schemat modelu spiralnego. Źródło:\cite{spiral}. }
\end{center}

\subsection{Model iteracyjny}
\label{subsec:modelIter}

W odpowiedzi na wady modelu kaskadowego powstały modele iteracyjne. Pierwszy system wykonany w oparciu o model iteracyjny datuje się na rok 1960. Powstał on w ramach projektu Mercury, który był sponsorowany przez NASA\cite{iterBrief}. Podstawowym pomysłem, który definiuje model iteracyjny, jest budowanie systemu poprzez powtarzalne cykle (iteracje). Podejście to pozwala deweloperom wyciągnąć wnioski z dotychczasowej pracy, zwiększa elastyczność wymagań w późniejszym okresie oraz pozwala lepiej wykorzystać zasoby firmy. Model iteracyjny jest często stosowany w wypadku, gdy pełna funkcjonalność systemu nie jest wymagana. Klient może otrzymać częściowo działający system, aby lepiej ocenić jego funkcjonalność.

\begin{figure}[h!]
  \centering
	\includegraphics[scale=1.0]{itermodel}
	\caption{Schemat modelu iteracyjnego.}
\end{figure}

Oczywiście model iteracyjny posiada również wady, takie jak dodatkowy koszt każdego cyklu czy trudność w podziale na iteracje. Pomimo tego, wszystkie współczesne metody tworzenia oprogramowania bazują na idei iteracji.

Przykładem modelu iteracyjnego jest RUP (Rational Unified Process)\cite{rup}, który składa się z sześciu praktyk:

\begin{enumerate}%[1)]
\item Buduj iteracyjnie z ryzykiem jako najważniejszym czynnikiem
\item Zarządzaj wymaganiami
\item Wprowadź architekturę opartą na komponentach

\item Wprowadź modele wizualne oprogramowania
\item Ciągle sprawdzaj jakość
\item Kontroluj zmiany
\end{enumerate} 

Pod koniec lat dziewięćdziesiątych RUP dominował jako model budowania systemów, zwłaszcza w środowiskach korporacyjnych i rządowych. Wadą tego rozwiązania jest spora ilość dokumentacji - często wymagana np. przez regulatora - która wydłuża i usztywnia proces tworzenia systemu.

\subsection{Agile Manifesto}
\label{subsec:agileMan}

Jako reakcja na poziom komplikacji i koszty metod, takich jak kaskadowa, powstało wiele tzw. ,,lekkich'' metod. Oto niektóre z nich:\cite{agileAndIter}

\begin{enumerate}%[1)]
\item Scrum (1995)
\item XP (Extreme Programming) (1996)
\item Crystal Clear

\item Feature Driven Development
\item Dynamic Systems Development Method (1995)
\end{enumerate} 

W 2001 roku fundacja non-profit Agile Alliance opublikowała ,,Agile Manifesto''. Manifest ten zawiera najważniejsze zasady nowo powstałych metodologii. Składa się on z 4 podpunktów:\cite{agileManifesto}

\begin{enumerate}%[1)]
\item Ludzie i interakcje ponad procesy i narzędzia
\item Działające oprogramowanie ponad wyczerpującą dokumentację

\item Współpraca klienta ponad negocjację umowy
\item Reakcja na zmiany ponad wykonanie planu
\end{enumerate}

Metodologie Agile posiadają bardzo ścisły opis procesu, dlatego zarządzanie projektem wymaga dyscypliny. Inspekcje wymagań są bardzo częste, przez co szybko tworzone jest oprogramowanie wysokiej jakości. Agile kierowany jest głównie do małych i średnich zespołów, dlatego dokumentacja jest ograniczona do minimum. Zespoły programistów Agile są zazwyczaj wielofunkcyjne i samozarządzalne, z bardzo płaską hierarchią. Bardzo duży nacisk kładzie się na komunikację bezpośrednią, dlatego bardzo popularne są codzienne kilkunastominutowe spotkania.

Metody Agile dzielą zadania na małe procesy iteracyjne, które nie zawierają planowania długoterminowego. Iteracje są krótkie. Trwają zazwyczaj od 1 do 4 tygodni. Każda iteracja zawiera pełen proces: planowanie, analiza wymagań, projektowanie, implementacja i testowanie. Na końcu działający produkt jest przedstawiany klientom. Minimalizuje to ryzyko drastycznych zmian w wymaganiach projektu. Bardzo często, aby zminimalizować komunikację, przedstawiciel klientów jest członkiem zespołu.\cite{agileManifesto}.

\subsection{The Lean Startup}
\label{subsec:lean}

Bardzo ciekawe podejście opisuje Eric Ries w swojej książce ,,The Lean Startup''. Opisuje on sytuacje, w których często nie można stworzyć specyfikacji, ponieważ klient nie wie dokładnie, jakiego produktu oczekuje lub jest to produkt innowacyjny. Filozofia ,,The Lean Startup'' opiera się na procesie produkcji Lean Manufacturing. Jest to proces opracowany w japońskich fabrykach samochodów, który minimalizuje straty poprzez redukcję kosztów, które nie tworzą wartości dla klienta. W szczególności system koncentruje się na odpowiednim umieszczeniu małych zapasów niezbędnych materiałów(zwanych Kanban) na całej linii produkcyjnej, zamiast przechowywania zapasów w magazynie centralnym. Zmniejsza to straty i zwiększa produktywność, z drugiej strony trudniejsze staje się zarządzanie zasobami(głównie surowcami i półproduktami) \cite{lean}.

Z filozofią Lean Startup wiąże się pięć kluczowych pojęć:
\begin{enumerate}%[1)]
\item Minimum viable product - jest to produkt, który pozwala nam na zebranie jak największej liczby potwierdzonych faktów o klientach, przy jak najmniejszym koszcie. Pozwala rozpocząć proces badania potrzeb klientów jak najwcześniej.
\item Continuous deployment - jest to proces, w którym każdy nowy kod jest natychmiast wdrażany.
\item Split testing (inaczej zwany A/B test) - jest to rodzaj testu, w którym tej samej grupie klientów pokazujemy dwie lub więcej wersji danego produktu. Dzięki temu możemy wybrać wersję, która odpowiada klientom bardziej oraz określić kierunek rozwoju.
\item Vanity metrics - jest to rodzaj metryki, w jaki sposób firmy próbują określić wzrost biznesu, tak aby był on jak najlepszy. Często daje to fałszywy obraz.
\item Pivot - jest to kontrolowana, gruntowna zmiana produktu lub strategii.
\end{enumerate}

Filozofia Lean Startup jest nie tylko z powodzeniem stosowana do produktów IT - korzystają z niej również inne branże.

\section{Specyfikacja programu do wizualizacji CMA}
\label{subsec:specCMA}
Gdy zaczynałem budować program do wizualizacji stopów międzymetalicznych, postanowiłem zebrać wymagania według danego planu:

\begin{enumerate}%[1)]
\item Wymagania powinny być podzielone na podpunkty
\item Każdy podpunkt powinien zawierać, co jest wymagane - bez określenia, jak to zostanie zrobione
\item Każdy podpunkt powinien być ,,atomowy''. Na przykład: ,,Program powinien wyświetlić 1000 obiektów oraz tworzyć animacje 1000 obiektów'' należy rozbić na 2 podpunkty: ,,Program powinien wyświetlić 1000 obiektów'' oraz ,,Program powinien tworzyć animacje 1000 obiektów''
\item Powinien być jasno określony cel, wymagania projektowe oraz specyfikacja funkcjonalna
\item Należy określić wymagania bezpieczeństwa

\item Wymagania niefunkcjonalne powinny określać wydajność i dostępność
\item Należy określić, co nie jest wymagane, tak aby odróżnić elementy przypadkowo pominięte
\item Należy określić sposób komunikacji z innymi komponentami lub systemami
\end{enumerate} 

Po kilku drobnych zmianach ostateczna wersja specyfikacji składała się z 13 podpunktów dla wymagań projektowych i 11 podpunktów specyfikacji funkcjonalnej:

\textbf{Cel:}

Celem projektu jest stworzenie aplikacji do wizualizacji procesów dyfuzji i porządkowania w stopach międzymetalicznych. Aplikacja powinna korzystać z graficznego interfejsu, tak aby narzędzie do analizy było wygodne w użyciu.

\textbf{Wymagania projektowe:}
\begin{enumerate}%[1)]
\item Program działa pod systemem Windows (zalecany jest Windows 7 lub wyższy, możliwe jest wspieranie innych systemów)
\item Program działa pod kontrolą środowiska .Net
\item Program powinien obsłużyć kilka tysięcy modeli 3D jednocześnie, działając płynnie dla operacji, takich jak obrót
\item Program powinien obsługiwać różne rozdzielczości ekranów
\item Program powinien informować użytkownika o postępie zadań trwających więcej niż 5 sekund

\item Program powinien obsługiwać pliki w formacie .chmc
\item Parametry modeli takie jak kolor, przezroczystość muszą w sposób płynny i adekwatny odwzorowywać się na  odpowiednie wartości wyników symulacji (prawdopodobieństwa, typy obsadzeń)
\item Program powinien tworzyć jednolite wizualizacje modeli dla całej grupy plików (np. z różnych temperatur)
\item Dla każdej klatki animacji muszą zostać uwzględnione parametry początkowe ustawione przez użytkownika
\item Program powinien zużywać mniej niż 1GB ramu dla liczby obiektów poniżej 3000

\item Dostępność programu jest wyłącznie zależna od komputera, na którym aplikacja się znajduje
\item Program nie powinien łączyć się z usługami internetowymi lub sieciowymi
\item Program nie powinien łączyć się z innymi komponentami
\end{enumerate}

\newpage

\textbf{Specyfikacja funkcjonalna:}
\begin{enumerate}%[1)]
\item Użytkownik może otworzyć plik, aby wczytać model
\item Użytkownik ma możliwość filtrowania modeli poprzez ustawienie maski
\item Użytkownik może przetwarzać grupę plików do stworzenia animacji
\item Użytkownik może obracać modelem 3D 
\item Użytkownik może powiększyć model
\item Użytkownik może precyzyjnie wybrać skale modelu
\item Użytkownik może wrócić do parametrów początkowych

\item Użytkownik może zmienić parametry kamery
\item Użytkownik może skalować modele
\item Użytkownik może zapisać zrzut ekranu, na którym znajduje się model
\item Użytkownik ma możliwość filtrowania elementów/składników modeli poprzez odpowiednie ustawianie maski

\item Użytkownik może zmienić wartość kanału alfa modeli
\end{enumerate}  
Zaletą tak zwięzłej specyfikacji jest łatwość ewentualnych zmian oraz krótki czas nauki dla dewelopera.

%---------------------------------------------------------------------------

\section{Prototypy różnych technologii}
\label{sec:prototypy}

Po zebraniu wszystkich wymagań projektowych mogłem przystąpić do budowy kilku prototypów różnych technologii, by sprawdzić, która najlepiej spełnia wymagania. Prototypownie jest o tyle istotne, że daje nam empiryczny dowód możliwości danej technologii. Jako potencjalnych kandydatów wytypowałem cztery technologie, które posiadają wsparcie dla grafiki 3D: 

\begin{enumerate}%[1)]
\item OpenGL
\item XNA
\item WPF
\item DirectX
\end{enumerate}  

OpenGL (ang. Open Graphics Library) - jest otwartym standardem API, służącym do generowania grafiki. Biblioteka umożliwia prace na najniższym poziomie, w związku z tym bardzo często korzysta się z rozszerzeń, silników lub frameworków. Filozofia działania OpenGL opiera się na maszynie stanowej \cite{openGLspec}. Biblioteka ma dwa główne cele. Stworzyć jednolity interfejs niezależny od sprzętu oraz wpierać standard w pełni, nawet w przypadku braku funkcjonalności w sprzęcie (emulacja oprogramowaniem). OpenGL jest bezpośrednim konkurentem DirectX.

XNA - jest to framework do tworzenia gier w ramach platformy .Net. Początkowo powstał on dla konsoli Xbox, ale został rozszerzony na cały ekosystem Microsoftu. Działa on na relatywnie niskim poziomie. Posiada wiele cech wspólnych z technologią DirectX, takich jak wsparcie dla grafiki 3D, jednak kod jest w pełni zarządzany. Dostępna jest również opensourcowa implementacja Mono.XNA, która działa na innych systemach, takich jak Mac OS X czy Linux. Pomimo iż XNA powstało jako framework do gier, z powodzeniem jest stosowany do innych zadań. Przykładowo XNA Math służy do obliczeń matematycznych na jednostce graficznej\cite{xnaUrl}.

WPF (ang. Windows Presentation Foundation) - jest częścią platformy .Net, służącą do tworzenia aplikacji graficznych. Do definicji obiektów używany jest XAML (pochodna XMLa), który zwiększa możliwości budowania bogatych interfejsów bez ingerencji programisty. Grafik, tworząc interfejs graficzny, tworzył tylko szablon dla programisty, który implementował wszystkie elementy. Korzystając z XAML i narzędzi, takich jak Blend, grafik jest w stanie stworzyć w pełni funkcjonalne GUI bez pomocy programisty. Pośrednio korzysta z DirectX, wyłącznie poprzez interfejs z kodu zarządzanego.\cite{wpf}.

DirectX jest kolekcją API do tworzenia grafiki 2D i 3D. Głównie wykorzystywana w grach i aplikacjach multimedialnych. DirectX jest technologią Microsoftu, która wspiera również efekty dźwiękowe do gier, obsługę urządzeń peryferyjnych itp. DirectX, poza wsparciem dla multimediów, oferuje również DirectCompute. Technologia umożliwia wykorzystanie DirectX do obsługi obliczeń GPGPU. Aby korzystać bezpośrednio z DriectX, należy aplikację napisać w języku C lub C++\cite{directX}.

OpenGL i DirectX z pewnością poradziłby sobie z programem do wizualizacji w sensie wydajnościowym. Problemem staje się tworzenie przycisków, suwaków i innych kontrolek. Obie technologie pracują na bardzo niskim poziomie, dlatego wymagają sporych nakładów pracy. W przypadku XNA i WPF nie miałem doświadczenia, które potwierdzałoby spełnienie wymagań projektowych, dlatego stworzyłem 2 prototypy.

\newpage

Pierwszy prototyp bazował na XNA. Po załadowaniu testowych plików prototyp spełnił wszystkie wymagania stawiane w specyfikacji.

\begin{figure}[h!]
  \centering
	\includegraphics[scale=0.7]{xna1}
	\caption{Zrzut ekranu pierwszego prototypu (XNA).}
\end{figure}

Kolejny prototyp powstał w WPF. Po załadowaniu modeli działał on wyraźnie wolniej od pierwszego, jednak na tyle dobrze, że spełnił wszystkie wymagania projektowe.


\begin{figure}[h!]
  \centering
	\includegraphics[scale=0.7]{wpf1}
	\caption{Zrzut ekranu drugiego prototypu (WPF).}
\end{figure}

Reasumując, każda z wyszczególnionych technologii spełniła wszelkie kryteria, postanowiłem jednak wybrać WPF. Jest to technologia najbardziej optymalna pod względem poświęconego czasu inżynieryjnego. Posiada wbudowany układ współrzędnych w trzech wymiarach, kamerę, predefiniowane tekstury i wiele innych. Integracja z graficznym interfejsem nie wymaga żadnej dodatkowej pracy w odróżnieniu od XNA.