POLITECHNIKA OPOLSKA

Wykonali:

Adam Czech

Marek Cywiński

1. Opis sprawozdania

Opis funkcji analityka i projektanta w systemach informatycznych.

Analiza systemu odziedziczonego, wypisanie błędów systemu.

1. Analityk systemowy

Nie ulega wątpliwości, że dobrze napisane wymagania przyczyniają się do sukcesu projektu. Naszym zdaniem w ogromnym stopniu wpływają na jakość jaką dostarczamy klientowi.
Najprościej ujmując, wymaganie funkcjonalne określa co ma robić system. Definiuje jak ma się on zachowywać w danych sytuacjach przy określonych danych wejściowych. Mimo że sama definicja jest dość prosta, to sformułowanie dobrych wymagań funkcjonalnych jest już czynnością trudną i złożoną. Autor dokumentacji zawierającej wymagania funkcjonalne musi bowiem przewidzieć wszystko czym zajmować ma się system. Dodatkowo musi opisać to na tyle dokładnie by programista mógł zaimplementować wymagania, a jednocześnie na tyle ogólnie by dać programiście możliwość technicznej swobody przy projektowaniu. 
Analityk w swojej pracy formułuje wymagania w postaci tekstu. Stara się używać zdań prostych i zwięzłych, które mają być interpretowane tylko w jeden sposób. Jest zwolennikiem podejścia, że dokumentacja musi być maksymalnie prosta i zrozumiała. Jest bowiem czytana nie tylko przez autora, ale później także przez developerów, testerów oraz klienta. Każdy musi tak samo zrozumieć zapisany tekst.
 

1. Projektant systemowy

Praca projektanta wiąże się z zadaniami związanymi wprost z Inżynierią Oprogramowania. Wymienia się tu obszary, takie jak: projektowanie architektury systemów, projektowanie interfejsów użytkownika, projektowanie modułów i procedur. Natomiast na efektywność tej pracy, mogą mieć wpływ różne zjawiska występujące w pracy zespołowej. Dlatego też, projektant systemów informatycznych, ze względu na pełnioną rolę i obowiązki powinien być świadomy takich zagrożeń, jak: syndrom grupowego myślenia, ogłupienie grupowe, polaryzacja grupowa, próżniactwo społeczne, konformizm grupowy.

Przegląd podstawowych pojęć Inżynierii Oprogramowania stosowanych przez projektanta.

Abstrakcja

Abstrakcja jest metodą, której zastosowanie pozwala rozważać problemy na wybranym poziomie szczegółowości, bez wnikania w nieistotne szczegóły. Wyróżnia się następujące kategorie abstrakcji: proceduralne, danych, przepływu sterowania.

Uściślanie

Uściślanie jest metodą polegającą na stopniowym zmniejszaniu poziomu abstrakcji opisu projektowanego rozwiązania.

A więc, metoda ta pozwala na praktyczne wykorzystanie metody abstrakcji. Kolejne kroki uściślania, pozwalają projektantowi rozbudowywać wcześniejszy opis o coraz więcej szczegółów.

Modularność

Modularność zapewnia możliwość wyodrębniane składników systemu. Takie podejście do projektowania, pozwala na niezależne zarządzanie modułami systemu. Co też ułatwia opanowanie zwykle dużej złożoności projektowanego rozwiązania. Wyróżnia się kryteria oceny, które umożliwiają na zastosowanie poprawnej metody modularności: dekompozycję modularną, kompozycję modularną, zrozumiałość modułów, ciągłość modularną, ochronę modularną.

Architektura oprogramowania

Architektura oprogramowania stanowi strukturę oprogramowania i sposób powiązania składników w integralny system. Wyróżnia się cechy oprogramowania, które powinny występować w projekcie architektury: cechy strukturalne, cechy poza funkcjonalne, rodziny podobnych systemów. W projektowaniu architektury, można stosować różne modele: strukturalne, wzorców, dynamiczne, procesów oraz funkcji.

Hierarchia sterowania

Hierarchia sterowania stanowi taki opis zorganizowania modułów oprogramowania, z której wynika hierarchiczna struktura przepływu sterowania. Istnieją różne metody pozwalające na zobrazowanie takiej hierarchii, przy czym diagramy z rodziny drzewiastych przewarzają w powszechnym użyciu.

Dzielenie programów na części

Postać hierarchiczna projektowanego rozwiązania, pozwala w dalszej części na podział poziomy lub pionowy. Uogólniając, podział poziomy pozwala na rozróżnienie fragmentów oprogramowania odpowiedzialnych za wykonywanie róznych funkcji. Natomiast podział pionowy, polega na oddzieleniu tych fragmentów oprogramowania, które wykonują zadania techniczne od tych które sterują działaniem systemu.

Struktury danych

Struktura danych stanowi opis związków logicznych między pewnymi elementami danych. Taka struktura zapewnia sposób zorganizowania, metody dostępu, powiązania oraz sposoby przetwarzania elementów danych. Wśród różnych metod pracy, można wyróżnić kroki związane z opracowaniem kolejno struktur: koncepcyjnych, logicznych, fizycznych.

Procedury

Projektowanie procedur skupione jest na sposobie przetworzenia informacji, tj. kolejności wykonywania zadań, miejsca podejmowania decyzji, wielokrotnego powtarzania tych samych czynności oraz używanych struktur danych. Struktura procedur jest ściśle związana z architekturą programu.

Ukrywanie informacji

Dobre praktyki związane z ukrywaniem informacji, wskazują na takie projektowanie modułów, by procedury i dane w nim zawarte były widoczne dla innych modułów tylko wtedy, kiedy jest to naprawdę potrzebne. Zasada ta, przekłada się na łatwiejsze zarządzanie i wprowadzanie zmian w oprogramowaniu. W praktycznym użyciu, mają zastosowanie różne mechanizmy ukrywania informacji.

1. Analiza systemu odziedziczonego „Firma Kurierska”

Odziedziczony system posiada błędy i braki, po przeanalizowaniu systemu znaleźliśmy następujące usterki:

• Brak spisu treści – jest on potrzebny do płynnego znalezienia potrzebnych informacji

• Zły diagram przypadków użycia

• Bardzo ubogi diagram klas

• Zły diagram sekwencji

• Brak diagramu stanu