Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

PRZEMYSŁOWE SYSTEMY INFORMATYCZNE Cz. 6. Projektowanie systemu komputerowego.

Podobne prezentacje


Prezentacja na temat: "PRZEMYSŁOWE SYSTEMY INFORMATYCZNE Cz. 6. Projektowanie systemu komputerowego."— Zapis prezentacji:

1 PRZEMYSŁOWE SYSTEMY INFORMATYCZNE Cz. 6. Projektowanie systemu komputerowego

2 1. Wstępne założenia systemu 2. Etapy opracowywania systemu 3. Etapy opracowywania oprogramowania 4. Specyfikacja wymagań 5. Opis oprogramowania 6. Konserwacja oprogramowania

3 1. Wstępne założenia systemu Inżynieria oprogramowania zajmuje się metodami opracowania dużych systemów programów, przeznaczonych do długotrwałej eksploatacji. Programy takie odznaczają się dwiema istotnymi cechami: opracowywane są przez duże zespoły, konserwowane są i modyfikowane przez zmieniające się zespoły. Systemy takie są coraz częściej spotykane w przemyśle w związku ze wzrastającą automatyzacją linii produkcyjnych lub całych fabryk oraz w związku ze wzrostem złożoności i precyzji stosowanych procesów technologicznych. Znajomość metod inżynierii oprogramowania ułatwia także rozwiązywanie problemów prostszych, do których mogą należeć automatyzacja gniazd produkcyjnych lub pomiarów testowych materiałów i półproduktów. Ponadto należy zwrócić uwagę na to, że wspomniane prostsze systemy mogą być w przyszłości wykorzystywane jako elementy większych systemów.

4 Projektowanie systemu przemysłowego wymaga na wstępie rozważenia szeregu problemów, przy czym do należy określenie: Co należy zbudować? Jak to zrobić? W celu przygotowania odpowiedzi na te podstawowe pytania projektant powinien zapoznać się ogólnie: z istniejącymi urządzeniami i instalacjami, z przebiegiem procesu produkcyjnego,

5 Zazwyczaj wstępne wymagania formułują w imieniu zamawiającego technolodzy. Należy jednak zwrócić uwagę na to, że są oni głównie specjalistami w swoich wąskich dziedzinach i niekoniecznie znają i rozumieją problemy budowy, oprogramowania i eksploatacji systemów komputerowych. Powoduje to często to, że : Sposób opisu zagadnienia jest często bardzo daleki od opisów stosowanych przez realizatorów systemów komputerowych, przez co szybkie sformułowanie ostatecznych założeń dla systemu komputerowego może początkowo stwarzać trudności. Pomijane są zagadnienia, które dla specjalistów danej branży są oczywiste, a niekoniecznie są one oczywiste dla projektanta systemu komputerowego. Propozycje rozwiązań wynikają z dotychczasowej praktyki produkcyjnej i przyzwyczajeń obsługi, podczas gdy lepiej byłoby zastąpić je nowymi rozwiązaniami, wynikającymi ze specyfiki i możliwości systemów komputerowych. Propozycje budowy systemu bazują na stanie obecnym i nie uwzględniają dalszego rozwoju komputeryzacji danej fabryki. Niektóre propozycje są nieracjonalne, co wynika z niewiedzy stawiających je lub, po prostu, z braku czasu na gruntowne przemyślenia.

6 Z kolei projektanci systemów komputerowych często początkowo nie uświadamiają sobie wagi poszczególnych problemów czy sposobów bezpiecznej, wygodnej i skutecznej obsługi urządzeń. Są też często obciążeni rozwiązaniami, zastosowanymi w innej branży, a które niekoniecznie pasują do rozwiązania nowego problemu.

7 Dla przykładu różnego spojrzenia na ten sam proces przez różnych specjalistów może być proces dyfuzji domieszek w płytkach półprzewodnikowych. Technolog z branży półprzewodnikowej często określa problem dyfuzji przez opis koncentracji domieszek w powierzchniowej warstwie półprzewodników. Z punktu widzenia automatyka najistotniejsze jest to, że proces dyfuzji jest kontrolowany przez sterowanie polem temperatury w funkcji czasu. Z kolei dla projektanta systemu informatycznego najbardziej istotne jest to, że należy rejestrować i przekazywać do bazy danych: identyfikator danej partii płytek, identyfikator operatora, parametry programu procesu danej partii, syntetyczne parametry przebiegu procesu, informacje o stanach alarmowych, dokładny przebieg procesu w przypadku odchyleń od normy, przeprowadzany dla celów diagnostyki procesu i sprawności urządzenia produkcyjnego.

8 Przykładem nieporozumień, które są związane z pozorną oczywistością niektórych wymagań jest przypadek założeń do oprogramowania komputerowego urządzenia do kalibracji czujników termometrycznych. Urządzenie to jest wyposażone w piec, który zawiera blok izotermiczny z kalibrowanymi czujnikami. Urządzenie ma możliwość zaprogramowania temperaturowych punktów kalibracji, po czym automatycznie realizuje ten program. W trakcie procesu kalibracji urządzenie: podnosi temperaturę do kolejnego zaprogramowanego poziomu, wykrywa stan cieplnie ustalony, mierzy wskazania temperatury wszystkich badanych czujników, porównuje je ze wskazaniami czujnika wzorcowego, określa klasę czujników, wypełnia odpowiedni formularz wyników badań, archiwizuje wyniki pomiarów.

9 Programista, który opracowywał oprogramowanie monitorowania na ekranie przycisków operatorskich oraz wyników kalibracji, wypełnił wszystkie sformułowane przez pomiarowców wymagania. Przy prezentacji wyniku pracy okazało się, że większą część na ekranu operatorskiego urządzenia zajmuje tabela, w której są zapisywane wyniki końcowe klasyfikacji czujników. Brak jest natomiast miejsca na monitorowanie wyników bieżących pomiarów czujnika wzorcowego i czujników, z nim porównywanych,. Monitorowanie to jest istotne dla oceny poprawności procesu kalibracji, który może być skutecznie zakłócony np. przez niewłaściwe kontaktowanie któregoś z czujników. Po sprawdzeniu założeń okazało, że konieczność monitorowania bieżących pomiarów przez urządzenie pomiarowe była dla pomiarowców tak oczywista, że zapomnieli wpisać je do wstępnych założeń.

10 Z grupy propozycji założeń, które wynikają z dotychczasowej praktyki produkcyjnej i przyzwyczajeń obsługi można np. wymienić wymaganie każdorazowego dokumentowania przebiegu procesów w formie drukowanych wykresów, które po pewnym czasie są kłopotliwe do odszukania w celu przeprowadzenia analizy. Na dodatek analiza ta musi być dokonywana ręcznie. Często racjonalniejszym rozwiązaniem jest bieżące dokumentowanie procesów przez wydruk jedynie syntetycznych wskaźników oceny ich przebiegu. Drukowanie wykresów może dotyczyć jedynie koniecznych wykresów na podstawie ich wyboru w bazie danych. Ponadto cyfrowa postać danych pozwala na przeprowadzanie automatycznej analizy wyników. Wybór odpowiedniego rozwiązania rzutuje oczywiście na sposób opracowania archiwizacji danych.

11 Z przedstawionych wymagań wynika, że przed przystąpieniem do projektowania przemysłowego systemu informatycznego należy przeprowadzić szereg cierpliwych i dociekliwych dyskusji z przyszłymi użytkownikami systemu. W wielu przypadkach okazuje się, że wskazane jest uwzględnić lokalne normy i dotychczasową praktykę mimo, iż powszechnie stosuje się inne rozwiązania.

12 Ogólnie należy stwierdzić, że aby sformułować właściwe założenia koordynator całości projektu systemu lub projektu istotnego fragmentu tego powinien posiąść pewien niezbędny poziom wiedzy interdyscyplinarnej, związanej zarówno z systemami komputerowymi jak i komputeryzowanymi obiektami i stosowaną technologią. W czasie opracowywania wymagań należy znaleźć odpowiedzi na pytania: co jest najważniejsze dla prawidłowości przebiegu, bezpieczeństwa i wydajności danego procesu produkcyjnego? czy spełnienie wszystkich postawionych przez technologów wymagań jest konieczne? czy pożądane byłoby spełnienie funkcji systemu, które są możliwe do realizacji, a które nie występowały we wstępnie zgłoszonych wymaganiach? jakie są perspektywy rozwoju danego systemu?

13 2. Etapy opracowywania systemu Przemysłowy system składa się ze składników sprzętowych i programowych. Dla uzyskania prawidłowych rezultatów przy budowie systemu należy przeprowadzić szereg systematycznych działań. Proces projektowy wymaga wyróżnienia następujących działań: określenie potrzeb, znalezienie rozwiązania, realizację, ocenę rezultatów. Wyróżnienie tych działań i określenie kolejności ich wykonania pozwala na podzielenie procesu projektowego na etapy. Na ogół sprzętowe składniki systemu można skonfigurować ze standardowych bloków lub urządzeń W niektórych przypadkach zachodzi konieczność indywidualnego projektowania, lub indywidualny projekt, zwłaszcza powielany, może przynieść znacząca obniżkę ceny systemu. Należy przy tym zwrócić uwagę na profesjonalizm projektu i wykonania, gdyż niepewnie lub wadliwie działający blok systemu może istotnie obniżyć jakość całego skomplikowanego i drogiego systemu.

14 Opracowanie systemu wysokiej jakości i pewności działania wymaga dużej dyscypliny prowadzenia projektu. Należy bardzo silnie podkreślić konieczność prowadzenia odpowiedniej dokumentacji projektu. Jest to bardzo często niedoceniane, przez co powstają liczne kłopoty, wzrost kosztów i pracy, ze względu na konieczność powtarzania pewnych faz pracy dla odtworzenia zapomnianych szczegółów. Przy odejściu członka zespołu brak pełnej dokumentacji może doprowadzić do konieczności ponownego wykonania jakiejś pracy. Opracowywanie systemu, przy udziale dużego zespołu, z przeznaczeniem do długotrwałej eksploatacji, składa się następujących podstawowych etapów: 1. Analiza wymagań 2. Projektowanie systemu 3. Opracowanie sprzętu i oprogramowania 4. Integracja systemu i testowanie 5. Ocena i akceptacja

15 Analiza wymagań We wstępnym etapie należy opracować ogólne dla wymagania systemu, dotyczące jego celów, lecz nie definiujące jeszcze techniki realizacyjnej. Do wymagań tych można między innymi zaliczyć: funkcje systemu, wymagane parametry, spodziewane efekty wdrożenia, prognozowane koszty opracowania i wdrożenia, Po opracowaniu tych wymagań należy poddać je przeglądowi ekspertów z dziedziny, której system będzie służył. Aby było to możliwe wymagania powinny posługiwać się terminologią danej dziedziny. Eksperci powinni dokonać oceny poprawności i kompletności założeń oraz planu dalszych działań. Efektem przeglądu powinno być zatwierdzenie założeń.

16 Projektowanie systemu W etapie projektu opracowuje się dokument, który określa architekturę systemu. Uwzględnia on podział na bloki funkcjonalne i sprzężenie między nimi. Ponadto powinny powstać dokumenty, które określają: wymagania dla poszczególnych bloków, oraz sposób ich testowania, harmonogram, uwzględniający podział pracy pomiędzy uczestników projektu Również te dokumenty powinny być ocenione przez ekspertów i zatwierdzone.

17 Opracowanie bloków systemu Następnym etapem jest opracowanie bloków sprzętowych i programowych systemu. Prace te przeprowadza się współbieżnie i niezależnie od siebie. Bloki te powstają na podstawie opracowanych uprzednio wymagań i powinny być zaopatrzone dokumentacją, zawierającą między innymi opis i wyniki testów. Końcowa ocena powinna uwzględniać: zgodność z wymaganiami, dotyczącymi założonych funkcji i parametrów, ocenę kompletności dokumentacji.

18 Integracja i testowanie systemu Po etapie opracowania sprzętu i oprogramowania następuje integracja wszystkich bloków. W trakcie łączenia bloków dokonuje się testów, które zostały przewidziane podczas projektowania systemu. Podczas testowania są zazwyczaj wykrywane błędy systemu, które należy usunąć i jednocześnie uaktualnić dokumentację systemu. Dokumentacja systemu wraz z raportem testowania powinny być ocenione przez recenzentów. Recenzenci oceniają kompletność dokumentacji i odpowiedniość przeprowadzonych testów. Po pozytywnej ocenie recenzentów system jest kierowany do ostatecznej oceny.

19 Ocena i akceptacja Końcowa ocena powinna być przeprowadzana przez zespół, niezależny od zespołu opracowującego i jego kierownictwa. Ocena dotyczy sprawdzenia wszystkich wymagań, wymienionych w specyfikacji systemu. Ocena może obejmować próbną eksploatację w warunkach produkcyjnych. Dodatkowe informacje na temat metod stosowanych przy projektowaniu systemów komputerowych można uzyskać w książce: Krzysztof Sacha, Projektowanie programowania systemów sterujących, Oficyna Wydawnicza Politechniki Warszawskiej, Warszawa, 1996 Książka ta dotyczy także etapów prac nad oprogramowaniem, które będą omówione w dalszej kolejności.

20 Należy podkreślić wagę, która jest przywiązywana do poprawności i kompletności dokumentacji. Warto też zwrócić uwagę na potrzebę przygotowywania dokumentacji, przeznaczonej na własne potrzeby projektanta. Jest ona konieczna chociażby ze względu na ulotność pamięci, nieoczekiwane przerwy w pracy lub równoległą pracę nad kilkoma zagadnieniami, często niezależnymi. Ponadto nieomal nie zdarza się, aby pierwsza wersja programu nie wymagała poprawek, które mogą być wnoszone np. podczas próbnej eksploatacji, prowadzonej wiele miesięcy po napisaniu tego programu. Dlatego też warto opatrywać program komentarzami, opisem zmiennych i opisem wprowadzonych poprawek. Poprawki powinny być ponadto opatrzone datą, która ułatwia w zrozumieniu powodu wniesienia poprawki lub w zorientowaniu się, która z kolejnych nowych lub ostatecznych wersji jest świeższa.

21 3. Etapy opracowywania oprogramowania Dla uporządkowania prowadzenia i weryfikacji procesów programowania w USA dla potrzeb wojskowych opracowano w 1998 r. Normę DOD Std 2167, Defence system software development Przedmiotem tej normy jest przede wszystkim określenie: czynności, wykonywanych podczas projektowania, zakresu dokumentowania decyzji, podejmowanych podczas projektu, weryfikacji poprawności projektu.

22 Prace programowe prowadzi się wraz z projektowaniem całego systemu, dlatego też etapy prac są analogiczne. Według normy DOD Std 2167 w pracach programowych wyróżnia się: wstępną specyfikację wymagań dla oprogramowania, plan rozwoju oprogramowania, analizę wymagań, projekt wstępny, projekt szczegółowy, programowanie i testowanie jednostek programowych, integrację i testowanie fragmentów oprogramowania, instalację i ocenę końcową, opis oprogramowania, konserwację oprogramowania.

23 Rygorystyczne spełnienie wymagań dokumentacyjnych stawianych przez instytucje wojskowe, zarówno amerykańskie jak i rodzime, powoduje często niezbyt racjonalny wzrost kosztów i czasu opracowywania projektu. Dlatego też w przypadku systemów cywilnych, które są niezbyt duże, nie stwarzają zagrożeń, przeznaczone są do eksploatacji w ograniczonym czasie, stosuje się dokumentację częściowo uproszczoną. Inne bowiem wymagania stawia się dla oprogramowania systemu rakietowej obrony kraju a inne dla oprogramowania linii produkcyjnej okolicznościowego gadżetu, który produkcja musi ruszyć jak najszybciej i skończy się np. wraz z końcem olimpiady. Nawet jednak w takich przypadkach, jak przypadek ostatni, pożądana jest znajomość pełnych wymagań projektowych, gdyż może to usprawnić organizację projektu także w warunkach bardzo ograniczonego czasu. Ponadto świadomość wszystkich możliwych wymagań zabezpiecza przed pominięciem czynności lub dokumentów, istotnych dla danego projektu.

24 Przy pracach programowych należy wziąć ponadto pod uwagę inne dokumenty normalizacyjne, dotyczące oprogramowania. Należą do nich: IEEE Guide to Software Requirements Specifications, IEEE Std 1233, 1998, który dotyczy specyfikacji wymagań dla oprogramowania, IEEE Recommended Practice for Software Design Description, IEEE Std 1016, 1998, który przedstawia zalecany sposób opisu projektów oprogramowania.

25 Wstępna specyfikacja wymagań dla oprogramowania Specyfikacja ta jest punktem wyjścia dla dalszych prac. Powstaje w etapie projektu całego systemu sprzętowo-programowego, omówionego uprzednio. Plan rozwoju oprogramowania Na etapie projektowania systemu powstaje również plan rozwoju oprogramowania, który obejmuje: podział na etapy pracy, kończone odpowiednimi dokumentami, wymagane przeglądy i oceny zewnętrzne, standardy, metody i narzędzia stosowane w poszczególnych etapach, zasady przechowywania dokumentów i programów, sposoby kontroli spójności wersji, metody oceny i kontroli czynników ryzyka w różnych fazach pracy.

26 Analiza wymagań W etapie tym, na podstawie sformułowanych uprzednio wstępnych wymagań i potrzeb użytkownika, ustala się metody sprawdzenia, czy zostały one spełnione. Ponadto w etapie tym należy określić wszystkie zewnętrzne ograniczenia, narzucone na projekt. Do ograniczeń tych mogą np. należeć: typ komputera, system operacyjny, język oprogramowania, protokoły komunikacyjne. W wyniku prac tego etapu powinny powstać dokumenty: specyfikacja wymagań dla oprogramowania, która określa funkcje, dokładność, szybkość i wydajność operacji komputerowych i sieciowych itp. specyfikacja wymagań dla sprzężenia projektowanego systemu z otoczeniem, np.: sprzężenia z urządzeniami i liniami produkcyjnymi, z systemami w fabryce, zawierających. bazy danych, ze stacjami monitorowania procesu produkcji itp. Zakres i forma specyfikacji wymagań, wg. przewodnika ANSI/IEEE Std 830 będą omówione później.

27 Projekt szczegółowy W etapie tym dokonuje się dalszego podziału oprogramowania, w wyniku czego określa się jednostki programowe i ustala się ostateczną strukturę programu. Dla każdej jednostki określa się algorytmy i komunikację z innymi jednostkami. Dla przykładu w systemie sterowania gniazdem pieca do dyfuzji półprzewodników można wyróżnić cztery bloki programowe, które realizują następujące zadania: 1. Programowanie procesu technologicznego, 2. Sterowanie procesem technologicznym, 3. Rejestracja i analiza przebiegu procesu, 4. Komunikacja z systemem sterującym linią produkcyjną.

28 Wyszczególnione bloki programowe można podzielić na jednostki programowe. Podział może być następujący: 1. Programowanie procesu technologicznego 1.1. Programowanie przeprowadzane z klawiatury 1.2. Odbiór programów przesyłanych z systemu sterowania linią produkcyjną 2. Sterowanie procesem technologicznym 2.1. Obsługa pulpitu operatorskiego 2.2. Sterowanie funkcjami stanowiska na podstawie programu czasowo- zdarzeniowego 2.3. Wielopętlowa programowa regulacja temperatury 2.4. Programowe sterowanie przepływem gazów technologicznych 2.5. Sterowanie załadunkiem i wyładunkiem wsadu 2.6. Diagnostyka stanów alarmowych 2.7. Blokady i sterowanie awaryjne

29 3. Rejestracja i analiza przebiegu procesu 3.1. Rejestracja przebiegu procesu 3.2. Rejestracja stanów awaryjnych 3.3. Obliczanie syntetycznych wskaźników oceny przebiegu procesu 3.4. Zarządzanie wynikami rejestracji (archiwizacja i kasowanie wyników) 4. Komunikacja z systemem sterującym linią produkcyjną 4.1. Oprogramowanie protokołów komunikacyjnych 4.2. Przyjmowanie rozkazów z systemu sterowania linia produkcyjną 4.3. Wysyłanie komunikatów do systemu sterowania linią produkcyjną 3.4. Przesyłanie wyników rejestracji i analizy do systemu sterowania linią produkcyjną

30 Rezultatem etapu projektu szczegółowego oprogramowania powinny być następujące dokumenty: specyfikacja projektu, która opisuje podział bloków programowych na jednostki, podstawowe struktury danych oraz funkcje i algorytmy działania jednostek, definicje i opis testów kwalifikacyjnych, określone w aktegoriach danych wejściowych, oczekiwanych rezultatów i kryteriów oceny dla: jednostek programowych, bloków programowych, całości oprogramowania.

31 Programowanie i testowanie jednostek programowych Celem etapu jest napisanie i uruchomienie jednostek programowych oraz programów testujących dla tych jednostek. w wyniku powinny powstać dokumenty: kod źródłowy wraz z listingiem (wydrukiem) programu, procedury testowe wraz ze szczegółowymi instrukcjami ich wykonania i oceny wyników.

32 Integracja i testowanie fragmentów oprogramowania Podczas łączenia jednostek programowych i ich testowania wykorzystuje się instrukcje testowania, opracowane w poprzednim etapie. W czasie tego etapu poprawia się wykryte błędy oprogramowania. W wyniku integracji powstają stopniowo coraz większe grupy jednostek programowych współdziałające na coraz wyższym poziomie programu. Etap kończy się połączeniem całego programowania. W wyniku etapu powinny powstać następujące dokumenty: uaktualniona specyfikacja projektu i kod źródłowy programu, raporty testowania bloków, instrukcja testowania kwalifikacyjnego.

33 Instalacja i ocena końcowa Instalacja oprogramowania w docelowym środowisku wykonawczym jest ostatnim etapem cyklu programowania. Końcowe testowanie kwalifikacyjne powinno być przeprowadzane według instrukcji testowania. Ocena powinna być wykonana przez odrębny zespół, niezależny od zespołu opracowującego. Wynikiem powinny być następujące dokumenty: uaktualniona specyfikacja projektu i źródłowy kod programu raporty testowania oprogramowania. Równocześnie opracowuje się dokumentację użytkową, dostarczana wraz z oprogramowaniem, tzn.: specyfikację funkcjonalną produktu, podręczniki obsługi instalacji i konfiguracji oprogramowania.

34 Ostateczna ocena i akceptacja produktu obejmuje: ocenę cyklu rozwoju, spełnienie wymagań oraz kompletność dokumentacji, ocenę fizyczną, która sprawdza kompletność oprogramowania i jego zgodność z dokumentacją.

35 4. Specyfikacja wymagań Specyfikacja wymagań jest podstawowym dokumentem rozpoczynającym cykl oprogramowania. Określa ona funkcje projektowanego systemu. Nie powinna natomiast zawczasu narzucać sposobu realizacji, aby nie krępować projektantów, gdyż mogą oni zaproponować lepsze rozwiązania. Specyfikację opracowuje zespół, który bada potrzeby przyszłych użytkowników i możliwości ich zaspokojenia. Specyfikacja musi być opracowana szczególnie starannie, gdyż staje się częścią umowy między zleceniodawcą a wykonawcami i zawarte w niej błędy powodują później liczne komplikacje.

36 Zakres i formę specyfikacji określa standard ANSI/IEEE Std 830. Zgodnie z tym standardem specyfikacja powinna mieć następujące cechy: jednoznaczność, kompletność, weryfikowalność, spójność, modyfikowalność, powiązanie.

37 Jednoznaczność. Zapis każdego wymagania powinien mieć tylko jedną interpretację. Należy unikać synonimów, a w przypadku nazw wieloznacznych należy zamieścić ich definicję. Zaleca się użycie narzędzi sformalizowanych takich jak grafy przepływu sygnałów. Kompletność. Specyfikacja powinna wymieniać wszystkie wymagania istotne dla projektowanego systemu. Powinna definiować reakcję systemu na wszystkie możliwe wartość danych wejściowych – zarówno poprawnych jaki i niepoprawnych. Tabele i rysunki powinny mieć odnośniki w tekście. Weryfikowalność. Opisy wszystkich wymagań powinny być tak sformułowane, aby było możliwe jednoznaczne rozstrzygniecie czy produkt finalny spełnia wymagania czy nie. Np. sformułowanie zawierające nieostre stwierdzenia, np. czas odpowiedzi powinien zazwyczaj nie przekraczać 1 s nie jest weryfikowalne.

38 Spójność. Różne wymagania, opisane w specyfikacji, nie mogą być wewnętrznie sprzeczne. We wszystkich opisach należy używać tej samej terminologii. Modyfikowalność. Łatwość modyfikowania zależy między innymi od sposobu opisania zagadnienia. Przejrzystość zapewnia podział na rozdziały, paragrafy i punkty, uzupełniony spisem treści i indeksem. Odnośniki powinny być jawne. Opis nie powinien być nadmiarowy, to znaczy każde wymaganie powinno być opisane tylko w jednym miejscu. Powiązanie. Każde wymaganie powinno być uzasadnione przez wskazanie przyczyny jego wprowadzenia. Przyczyną może być np. konieczność spełnienia numeru paragrafu normy. W celu ułatwienia powiązania specyfikacji z innymi dokumentami wszystkie punkty specyfikacji powinny być ponumerowane.

39 Wzorcowy układ specyfikacji obejmuje następujące rozdziały: 1. Wstęp, ułatwiający korzystanie z pozostałej części dokumentu. Zawiera: cel sporządzenia specyfikacji i spodziewany krąg czytelników, zakres specyfikacji, określony przez listę nazw i funkcji programów, spodziewany obszar zastosowania i przewidywane korzyści, definicje i skróty nazw używanych w treści specyfikacji, dokumenty związane, do których odwołuje się specyfikacja, wraz ze wskazaniem dostępu do tych dokumentów, streszczenie, wyjaśniające zawartość i strukturę dokumentu.

40 2. Opis ogólny, który zawiera intuicyjny opis wymagań i ograniczeń, charakteryzujących projektowane oprogramowanie. Zawiera: informacje o otoczeniu oprogramowania, tzn. związki z innymi systemai, sprzęgi komunikacyjne i metody współpracy, funkcje oprogramowania, charakterystykę użytkowników, określającą ich cele i zadania, zakładany poziom wykształcenia i doświadczenia, ograniczenia projektowe, wynikające między innymi z wymogów prawa, przyjętych norm, stosowanego sprzętu lub protokołów komunikacyjnych, założenia, przyjęte przy opracowywaniu specyfikacji, np. określony sprzęt dostępny podczas implementacji.

41 3. Wymagania szczegółowe, które są najobszerniejszym i najważniejszym rozdziałem specyfikacji. Wylicza on wszystkie wymagania, które musi spełnić produkt końcowy. Poszczególne wymagania powinny stanowić oddzielne, numerowane paragrafy. Treść rozdziału zawiera: wymagania funkcjonalne, które opisują dane wejściowe i wyjściowe oraz sposób przekształcania danych wejściowych w wyjściowe we wszystkich możliwych przypadkach, wymagania, dotyczące wydajności przetwarzania, opisujące statyczne i dynamiczne parametry oprogramowania, np. liczbę terminali, liczbę jednocześnie przetwarzanych plików, dokładność obliczania wyników, czas reakcji w różnych sytuacjach, wymagania, dotyczące sprzęgów zewnętrznych, które określają sposób współpracy z użytkownikiem, komunikację programów ze sprzętem i sposób współpracy z innymi elementami oprogramowania, ograniczenia projektowe, cechy szczególne, takie jak: organizacja bazy danych, środki zabezpieczające przed utratą danych, wymagania pracy w warunkach awarii, ograniczenia z korzystania pewnych funkcji, notowanie śladu kontaktów z użytkownikiem, spodziewane kierunki modyfikacji.

42 4. Indeks, który zawiera listę ważniejszych nazw i terminów używanych w specyfikacji, wraz ze wskazaniem wszystkich punktów dokumentu, w których zostały użyte.

43 5. Opis oprogramowania Opis projektu jest podstawowym dokumentem, który musi być opracowany przed rozpoczęciem implementacji systemu. Powinien dokładnie określać jak system spełnia wszystkie wymagania specyfikacji. Opis projektu określa strukturę oprogramowania, tzn. podział na jednostki projektowe, np. pliki i struktury danych, funkcje jednostek projektowych i ich sposób współpracy z otoczeniem. Zakres i formę opisu określa standard ANSI/IEEE Std Zgodnie z tym standardem opis powinien określać następujące atrybuty: nazwę, typ, cel, funkcję, strukturę wewnętrzną, zależności, sprzęgi, zasoby, algorytmy, dane.

44 Nazwa musi być różna od nazw innych jednostek i w miarę możliwości charakteryzować dana jednostkę. Typ powinien precyzyjnie opisywać rodzaj jednostki, np. program, stanowiący zadanie, podprogram, funkcja, plik danych. Cel wskazuje na wymagania, które są spełnione dzięki zastosowaniu danej jednostki. Funkcja zawiera opis przekształcania danych wejściowych w dane wyjściowe. Struktura wewnętrzna opisuje z jakich jednostek niższego rzędu dana jednostka jest złożona. Zależności stanowią listę wszystkich innych jednostek projektowych, których obecność jest niezbędna dla działania danej jednostki, przedstawiają charakter tych zależności i sposób współpracy. Zależności wygodnie można przedstawiać w formie diagramu struktury lub grafu przepływu danych.

45 Sprzęgi opisują dokładnie sposób współpracy jednostki projektowe z innymi jednostkami. Zawiera np. sposób wywołania i przekazania danych przez parametry i obszary wspólne. W przypadku pliku opis powinien przedstawiać sposób dostępu, format, zakres zmienności danych, sposób analizowania sytuacji błędnych. Zasoby stanowią wszystkie elementy zewnętrzne, które nie stanowią elementów projektu a są wykorzystywane przez dana jednostkę projektową. Są to elementy zewnętrzne, zasoby komputera, takie jak czas i sposób wykorzystania zasobów. Algorytmy opisują sposób działania jednostki projektowej z uwzględnieniem sytuacji wyjątkowych. Mogą być przedstawiane w postaci sieci działań. Dane są opisem struktur wewnętrznych danej jednostki projektowej.

46 6. Konserwacja oprogramowania Po zakończeniu projektu systemu następuje rozpoczęcie jego eksploatacji oraz konserwacji. Typowe koszty przyszłej konserwacji systemów, opracowanych przez duże zespoły, stanowią od połowy do dwukrotności kosztów opracowania projektu. Podstawowa część kosztów konserwacji nie jest związana z błędami lecz ze zmianami funkcji oprogramowania. Wynika to z zmianami wymagań użytkownika oraz zmianą środowiska wykonawczego. Duży udział w kosztach konserwacji ma błędne lub niedokładne określenie potrzeb użytkownika. Warto zwrócić uwagę na to, że konserwacja trwa wiele lat i ze względu na fluktuację personelu dokumentacja stanowi często jedyną informację o systemie. Duże koszty wynikają także z potrzeby dokładnego testowania systemu po wprowadzeniu zmian.


Pobierz ppt "PRZEMYSŁOWE SYSTEMY INFORMATYCZNE Cz. 6. Projektowanie systemu komputerowego."

Podobne prezentacje


Reklamy Google