1.Omów przedmiot i zakres inżynierii oprogramowania. Inżynieria oprogramowania to dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej. W inżynierii oprogramowania proces produkcji oprogramowania dzieli się na pewne fazy, typowy podział to: 1. specyfikacja - na tym etapie następuje określenie i ustalenie wymagań, które musi spełniać oprogramowanie 2. projektowanie - ustalenie ogólnej architektury systemu, wymagań dla poszczególnych jego składowych 3. implementacja - realizacja ustalonej architektury poprzez implementację składowych (modułów) i połączeń między nimi. 4. integracja - zintegrowanie poszczególnych składowych w jeden system, testowanie całego systemu 5. ewolucja - uruchomienie systemu, usuwanie wykrytych podczas jego używania błędów, rozszerzanie systemu 2.Omów zagadnienie języka programowania i semiotyki języka programowania. Semiotyka zajmuje się badaniem symboli, znaków. W jej skład wchodzą: – syntaktyka, zajmująca się określaniem

przynależności danego słowa do zestawu słownika określonego języka programowania

– semantyka, zajmująca się określeniem znaczenia programu, zapisanego w określonym języku programowania

Zapis algorytmu w języku programowania jest traktowany jako zapis formalny. Program komputerowy jest uznawany za jeden z rodzajów modeli matematycznych. Jest to algorytmiczny model zadania czy też rzeczywistości, którą modelujemy. 3.Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”. Kryzys oprogramowania (ang. software crisis) — zjawisko dostrzeżone już w latach 60. Polega na powiększającej się rozbieżności między mocą obliczeniową sprzętu komputerowego a efektywnością produkcji oprogramowania. Wysiłki informatyków zmierzają do optymalizacji procesu wytwarzania oprogramowania poprzez stosowanie odpowiednich metod i technik szczegółowych w tym zakresie. 4.Omów przykładowe źródła złożoności projektu informatycznego. Najczęstsze ryzyko związane z realizacją projektów IT wynika z braku kompetencji samych użytkowników, opóźnień w prowadzeniu przedsięwzięcia oraz źle zaplanowanego i przekroczonego budżetu. Istnieje również grupa ryzyk wiążących się z nagłą zmianą priorytetów, reorganizacją struktur i zasobów oraz rotacją ludzi w zespołach. W przypadku zarządzania ryzykiem szefowie IT stawiali przede wszystkim na własne siły. Jedynie nieliczni decydowali się na wybór zewnętrznego doradcy. Kolejna przeszkoda wynika z długiego procesu decyzyjnego oraz oporu kierownictwa wyższego szczebla. 5.Omów sposoby opanowywania złożoności projektu informatycznego. Aby wałczyć ze zjawiskiem złożoności projektu, stosuje się: ZASADE DEKOMPOZYCJI Czyli rozdzielenie złożonego problemu na podproblemy, ZASADE ABSTRAKCJI Czyli eliminacja mniej istotnych szczegółów rozważanego przedmiotu, wyodrębnianie cech wspólnych pewnego zbioru bytów i wprowadzaniu

pojęć oznaczających te cechy. ZASADE PONOWNEGO UZYCIA Czyli wykorzystanie wcześniej wytworzonych schematów, metod, ZASADE SPRZYJANIA NATURALNYM LUDZKIM WLASNOSCIOM Czyli dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich zdolności 6.Omów zagadnienie modelowania pojęciowego w projekcie informatycznym. Pojęcia modelu pojęciowego odnosi się do procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Jest wspomagane przez środki wzmacniające wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości 7. Co to jest metodyka prowadzenia projektu

formatycznego? in Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do projektowania pojęciowego, logicznego i/lub fizycznego. 8. Omów następujący model cyklu życia oprogramowania: … nazwa modelu Model kaskadowy: zawiera ciąg czynności wykonywanych sekwencyjnie przy tworzeniu oprogramowania: -określenie wymagań -analiza -projektowanie -implementacja -testowanie -konserwacja wady: Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac Wysoki koszt błędów popełnionych we wczesnych fazach Długa przerwa w kontaktach z klientem Wytwarzanie ewolucyjne polega na: opracowaniu wstępnej implementacji, pokazaniu jej użytkownikowi z prośbą o komentarze oraz udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu; wyróżnia się tworzenie badawcze (praca z klientem) oraz prototypowanie (praca z elementami systemu budzącymi wątpliwości) prototypowanie: Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe. fazy - ogólne określenie wymagań - budowa prototypu - weryfikacja prototypu przez klienta - pełne określenie wymagań - realizacja pełnego systemu zgodnie z modelem kaskadowym model V polega na wytwarzaniu równolegle oprogramowania i prowadzeniu testów akceptacji, poszczególne elementy systemu są badane od razu po wytworzeniu, praca polega na podziale systemu na podsystemy, a te na poszczególne zadania, co robi jeden z zespołów, a drugi zespól odpowiada wyłącznie za ocenę i testowanie systemu. testy odbywają się od zadań, potem przechodzą do testowania podsystemów, a następnie testowany jest pełny system. model spiralny opiera się na ewolucyjnym projekcie, który jest początkowo planowany, następnie wykonywana jest analiza ryzyka systemu, konstrukcja (często odbywa się zgodnie z modelem kaskadowym) a potem klient testuje system, informuje, co wymaga zmian i poprawek, i zgodnie z nimi cały cykl rozpoczyna się od początku, w kolejnym obrocie pętli do istniejącego systemu

wprowadzane są poprawki dopóki klient nie zaakceptuje systemu. 9 Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym oprogramowania. Podstawowe zadania kierownictwa przedsięwzięcia informatycznego: - Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia - Kosztorysowanie przedsięwzięcia - Planowanie i harmonogramowanie przedsięwzięcia - Monitorowanie i kontrolowanie realizacji przedsięwzięcia - Dobór i ocena personelu - Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla 10 Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości twórców oprogramowania Czynniki te wynikają z faktu, że oprogramowanie jest używane i tworzone przez ludzi. Użytkowanie - implikuje zasady tworzenia interfejsu użytkownika i dokumentacji użytkowej, Tworzenie - zagadnienia psychologiczne odgrywające rolę w tworzeniu oprogramowania. Elementy ludzkiej inteligencji: Umiejętność całościowego (syntetycznego) spojrzenia na problem. Posługiwanie się wiedzą płynącą z doświadczenia, a więc stosowania nieścisłych zasad wnioskowania na bazie wcześniejszych doświadczeń. Istnieją ogromne różnice w predyspozycjach osób dotyczące ich efektywności w produkcji oprogramowania. Testy osobowości: metody określenia, czy dana osoba posiada cechy przydatne na danym stanowisku. Stosowanie testów osobowości wiąże się z następującymi trudnościami: Osobowość ludzka ma charakter dynamiczny (zmienia się). Wieloletnia praktyka zawodowa nie pozostaje bez wpływu na osobowość. Różne zadania mogą wymagać różnych cech osobowości. Inne powinien posiadać analityk (kontakt z klientem), inne zaś programista lub osoba testująca oprogramowanie. Ponadto, metody inżynierii oprogramowania ulegają zmianie, co pociąga za sobą inny stosunek pożądanych cech osobowości do aktualnych zadań. Osoby poddane testom będą starały się raczej odgadnąć pożądaną przez testujących odpowiedź niż odpowiadać zgodnie ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech osobowości osoby, lecz raczej to, jak ta osoba wyobraża sobie cele i kryteria testowania oraz cechy pożądane przez pracodawcę 11 Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę w cyklu wytwórczym oprogramowania. Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób. Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują.

Uśpienie, zajmowanie się jednym problemem w jednym środowisku przez lata jest w informatyce bardzo groźne! Wyróżnia się następujące typy psychologiczne: 1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne, lubiące współzawodnictwo, niezależne. 2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo, zazdrosne. 3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie autonomii i indywidualnych osiągnięć, pomocne, przyjazne. Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej intensywnej interakcji z klientem. 12 Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2 Projekt, to sposób prowadzenia przedsięwzięć gospodarczych zmierzający do wytworzenia produktu uzasadnionego biznesowo, w ramach określonego czasu, budżetu, z odpowiednią strukturą organizacyjną , rolami i zakresami odpowiedzialności. Wymiary zarządzania: produkt, Koszt, Harmonogram, Jakość. Poszczególne wymiary zarządzania projektem mają na siebie istotny wpływ. Powinny być one analizowane przez kierownika projektu łącznie (również ocena ryzyka) Przez produkty projektu rozumie się wszystkie jego elementy, które mogą powstać w wyniku jego realizacji Często spotykaną formą prezentacji harmonogramu są na przykład tabele lub arkusze kalkulacyjne, jak również wykresy Gantta. Budżet projektu stanowi zestawienie kosztów realizacji projektu. Wymiar jakości dotyczy: - oceny zarówno poszczególnych produktów projektowych: - dokumentacji, - oprogramowania, - platformy techniczno-systemowej itp. 13. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń Prince2. Sponsor Projektu-członek zarządu klienta lub jego bezpośredni przedstawiciel, odpowiedzialny za finansowanie całego przedsięwzięcia mają prawo do wglądu w projekt i podejmowanie decyzji na temat jego dalszego rozwoju Rada Projektu- zawiera w swoim ciele reprezentację wszystkich uczestników projektu, takich jak: Sponsor, użytkownicy, dostawcy, mianowanie Szefów Projektu, okresowa i etapowa ocena stanu projektu i zatwierdzanie planów dalszych prac, rozstrzyganie sporów występujących na szczeblu Szefów Projektu, zatwierdzanie Wniosków o Zmianę w zakresie funkcjonalnym i niefunkcjonalnym projektu, zatwierdzanie akceptacji kolejnych produktów projektu Szefowie projektu-prowadzą i gromadzą dokumentację projektu, zapewniają warunki pracy zespołów

realizacyjnych, realizują zatwierdzone zmiany, w zależności od potrzeb zajmują eskalacją odpowiednich problemów Szef Jakości współpracuje z Szefami Projektu i sprawdza jakość całego projektu ponieważ podlegają mu plany, dokumentacja projektu wraz z produktami i ich testami. Komitet Kontroli Zmian składa się z przedstawicieli zarówno dostawcy jak i klienta. Jego skład wyznacza Rada Projektu. Komitet Akceptacyjny składa się przeważnie z przedstawicieli obu stron, często jednak spotyka się w nim wyłącznie przedstawicieli klienta (przyjęcie lub odrzucenie produktu). Sekretariat/administracja biura projektu- prowadzi archiwum projektu (zawiera się w nim biblioteka projektu, zbiory raportów oraz zajmuje się rozliczeniami finansowymi). Zespoły Realizacyjne- (odwalaja cały ten syf) relaizują projekt, szefami sa przeważnie osoby doświadczone w zakresie tematu projektu 14. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według metodyki PMI. Zakres-projekt zawiera tylko to co potrzeba (inicjowanie faz projektu planowanie zakresu definiowanie zakresu weryfikacja zakresu kontrola zmian zakresu ) Koszt-obejmuje procesy wymagane do zapewnienia, że projekt zostanie ukończony w ramach zaakceptowanego budżetu Czas-projektu obejmuje procesy wymagane do zapewnienia przestrzegania przez zespół projektowy ustalonych granic czasowych dla poszczególnych czynności w projekcie Jakość-obejmuje procesy wymagane do zapewnienia zaspokojenia przez rezultaty projektu tych potrzeb, dla których został on powołany Komunikacja-obejmuje procesy służące zapewnieniu terminowego i właściwego tworzenia, gromadzenia, rozpowszechniania, przechowywania i usuwania informacji niezbędnej do efektywnego zarządzania projektem Integracja-obejmuje procesy wymagane do zapewnienia poprawnej koordynacji wszystkich elementów projektu Ryzyko-obejmuje procesy identyfikacji, analizowania i reakcji na zaistnienie czynników ryzyka w projekcie Ludzie-obejmuje procesy ułatwiające efektywne wykorzystanie ludzi w projekcie Zaopatrywanie-obejmuje zdobywanie dóbr i usług spoza organizacji wykonującej projekt 15. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń metodyki Chestra SBS. Silna pozycja Kierownika Projektu (Szefa Projektu), zakres projektu i zakres produktu jest określany przez Architekta Systemowego i Architekta Biznesowego, Menedżer Jakości podlega pod Szefa Projektu Menedżer Konfiguracji nie jest już składową administracji projektu wyróżniono obszary dokumentacji i testów 16. Porównaj zalecenia Prince2, PMI i Chestra SBS w zakresie obszarów zarządzania projektem informatycznym i organizacji biura projektu informatycznego. PRINCE2:

*dobre* -Stosowanie tej metodyki zapewnia wysoką standaryzację i powtarzalność projektów o wspólnym podejściu, terminologii i dokumentacji. Zapewnia to możliwość doskonalenia kompetencji. -Metodyka w sposób racjonalny opiera się na najlepszych praktykach w zarządzaniu projektami -Sprawuje kontrolę nad startem, realizacją i końcem projektu -Jej stosowanie nie wymaga opłat autorskich *złe* -zbyt pracochłonne w zastosowaniu do małych projektów -ciągła wymiana informacji powoduje pojawienie się bezproduktywnych spotkań zabierających czas niezbędny na rzeczywistą pracę 17.Omów zagadnienie zarządzania konfiguracją w przedsięwzięciu informatycznym na podstawie metodyki RUP. Zarządzania konfiguracją (configuration management) - jest odpowiedzialne za systematyczne strukturalizowanie produktów. Artefakty takie jak dokumenty i modele muszą być wersjonowane (version control) a zmiany muszą być widoczne. W skład zarządzania konfiguracją wchodzi także utrzymywanie rejestru zależności pomiędzy artefaktami, tak, aby wszystkie powiązane części były uaktualniane wraz ze zmianami. 18.Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania. W procesie inżynierii wymagań możemy wyróżnić cztery główne fazy: 1. Studium wykonalności, - Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu. - Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na kilka pytań: a. Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa? b. Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych? c. Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano? 2. Określenie i analiza wymagań, - W trakcie tej czynności techniczni budowniczowie oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd. 3. specyfikowanie wymagań, - to częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste, częściowo przynajmniej sformalizowane notacje. 4. zatwierdzanie wymagań; - Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik - Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać Poprawianie błędów w wymaganiach może kosztować sto razy mniej niż poprawianie błędów w implementacji. Inżynieria wymagań ma na celu ma na celu określenie, jakich usług wymaga się od systemu i jakim ograniczeniom podlega tworzenie i działanie oprogramowania; 19.Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań. Podstawowe metody rozpoznania wymagań: - Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone na odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na reprezentatywnej grupie użytkowników.

Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu. - Studia na istniejącym oprogramowaniem. Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić wszystkie dobre i złe strony starego oprogramowania. - Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu. - Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia. - Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi interfejsami. Cechy jakościowego dobrego opisu wymagań: Dobry opis wymagań powinien: - Być kompletny oraz niesprzeczny. - Opisywać zewnętrzne zachowanie się systemu a nie sposób jego realizacji. - Obejmować ograniczenia przy jakich musi pracować system. - Być łatwy w modyfikacji. - Brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu. - Opisywać zachowanie systemu w niepożądanych lub skrajnych sytuacjach 20.Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań. Wymagania funkcjonalne – Są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach. – W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić. – Mogą być również wykonywane przy użyciu systemów zewnętrznych. Przykład: a) Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór. b) System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu. Wymagania niefunkcjonalne – To ograniczenia usług i funkcji systemu. – Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Przykład: a) System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika. b) Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie. Wymagania dziedzinowe – Są wyrażone za pomocą języka specyficznego dla dziedziny zastosowania; – Pochodzą z dziedziny zastosowania systemu - odzwierciedlają jej charakterystykę. – Mogą być funkcjonalne lub niefunkcjonalne.. Przykład: wymagania stawiane systemowi biblioteki a) Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50. b) względu na ochronę praw autorskich niektóre dokumenty należy składać natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową. 21.Omów i podaj przykłady wymagań

nkcjonalnych dla systemu informatycznego. fu Wymagania funkcjonalne: Opisują funkcje (czynności, operacje) wykonywane przez system. Funkcje te mogą być również wykonywane przy użyciu systemów zewnętrznych. Określenie wymagań funkcjonalnych obejmuje następujące kwestie: Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu. Określenie wszystkich rodzajów użytkowników, którzy

są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja). Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu. Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu. Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio określają funkcje wykonywane przez planowany system. 22.Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego. Wymagania niefunkcjonalne: Opisują ograniczenia, przy których system ma realizować swoje funkcje. Wymagania dotyczące produktu. Np. musi istnieć możliwość operowania z systemem wyłącznie za pomocą klawiatury. Wymagania dotyczące procesu. Np. proces realizacji harmonogramowania zleceń musi być zgodny ze standardem opisanym w dokumencie XXXA/96. Wymagania zewnętrzne. Np. system harmonogramowania musi współpracować z bazą danych systemu komputerowego działu marketingu opisaną w dokumencie YYYB/95. Niedopuszczalne są jakiekolwiek zmiany w strukturze tej bazy. Są to np: wymagania jakościowe (określają szczegółowe oczekiwania co do wydajności), technologiczne, bezpieczeństwa Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu. Wymagania niefunkcjonalne wynikają z: potrzeb użytkownika, ograniczeń budżetowych, strategii firmy, konieczności współpracy z innymi systemami sprzętu lub oprogramowania, czynników zewnętrznych. 23.Omów metody specyfikacji wymagań dla systemów informatycznych. Metody specyfikacji wymagań: Język naturalny - najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności. Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów). Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach. Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi). Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania. Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem. Diagramy przypadków użycia: poglądowy sposób przedstawienia aktorów i funkcji systemu. 24.Omów przykładowy zakres treści dokumentu opisującego wymagania na system informatyczny. Streszczenie (maksymalnie 200 słów) Spis treści Status dokumentu (autorzy, firmy, daty, podpisy, itd.) Zmiany w stosunku do wersji poprzedniej 1. Wstęp 1.1. Cel 1.2. Zakres 1.3. Definicje, akronimy i skróty 1.4. Referencje, odsyłacze do innych dokumentów 1.5. Krótki przegląd

2. Ogólny opis 2.1. Walory użytkowe i przydatność projektowanego systemu 2.2. Ogólne możliwości projektowanego systemu 2.3. Ogólne ograniczenia 2.4. Charakterystyka użytkowników 2.5. Środowisko operacyjne 2.6. Założenia i zależności 3. Specyficzne wymagania 3.1. Wymagania funkcjonalne (funkcje systemu) 3.2. Wymagania niefunkcjonalne (ograniczenia). Dodatki Kolejność i numeracja punktów w przedstawionym spisie treści powinna być zachowana. W przypadku gdy pewien punkt nie zawiera żadnej informacji należy wyraźnie to zasygnalizować przez umieszczenie napisu „Nie dotyczy”. Dla każdego wymagania powinien być podany powód jego wprowadzenia: cele przedsięwzięcia, których osiągnięcie jest uwarunkowane danym wymaganiem. Wszelki materiał nie mieszczący się w podanych punktach należy umieszczać w dodatkach. Często spotykane dodatki: Wymagania sprzętowe. Wymagania dotyczące bazy danych. Model (architektura) systemu. Słownik terminów (użyte terminy, akronimy i skróty z wyjaśnieniem) Indeks pomocny w wyszukiwaniu w dokumencie konkretnych informacji (dla dokumentów dłuższych niż 80 stron) 25.Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych. Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych. Czynności wykonywane w tej fazie: Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu; Ustalenie kontekstu projektu; Ustalenie wymagań użytkowników; Ustalenie wymagań organizacyjnych Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd. 26.Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy systemu informatycznego. Cechy modelu analitycznego (logicznego): -Uproszczony opis systemu; -Hierarchiczna dekompozycja funkcji systemu; -Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją; -Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi; -Jest on używany do wnioskowania o przyszłym oprogramowaniu; -Model oprogramowania powinien być jego uproszonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji. -Model ten jednakże nie zastępuje doświadczenia i wnikliwości projektantów, lecz pomaga projektantom w zastosowaniu tych walorów. Logiczny model oprogramowania: • pokazuje co system musi robić; • jest zorganizowany hierarchicznie, wg poziomów abstrakcji • unika terminologii implementacyjnej • pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie.

Czynności w fazie analizy: -Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu; -Ustalenie kontekstu projektu; -Ustalenie wymagań użytkowników; -Ustalenie wymagań organizacyjnych -Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd. 27. Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych. Analiza: Głównym celem analizy jest wprowadzenie strukturalnej specyfikacji opisu projektu za pomocą narzędzi modelowania: – diagramów przepływu danych — DFD, – diagramów obiekt-relacja-atrybut — ERD, – diagramów przejść stanów — STD; Wynikiem analizy jest zbudowanie następujących modeli: – model otoczenia, – model zachowania systemu; Modele są opisem formalnym systemu, niezależnym od technologii, jakiej użyje się do implementacji nowego systemu; Na końcu etapu analizy określa się dokładniej niż w poprzednim etapie budżet projektu oraz kalkulację kosztów i zysków; Projektowanie: Polega na: – wyodrębnienie tych części modelu zachowania systemu, które będą implementowane w systemie informatycznym; – przydzielenie poszczególnych części specyfikacji do odpowiednich procesorów lub serwerów (przetwarzanie rozproszone); fragmenty DFD (te, które będą implementowane) są mapowane na zadania; – zaprojektowanie struktury hierarchii modułów wewnątrz danego zadania; – transformacja diagramów ERD na relacyjną bazę danych (projektowanie logiczne danych); Implementacja: W fazie implementacji: – realizowane jest kodowanie i integracja modułów; – stosuje się techniki programowania strukturalnego oraz implementacji top-down; 28.Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych. Analiza obiektowa – opracowanie modelu obiektowego dziedziny zastosowania; – rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem; Projektowanie obiektowe – opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań; – obiekty projektu obiektowego są związane z rozwiązaniem problemu; Zadania w etapach fazy projektowania: – uściślenie istniejących definicji klas, np. metod, – dziedziczenie klas i operacji, – szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów, – wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów, – decyzje o trwałości obiektów, – modularyzacja i ukrywanie informacji, – optymalizacja modelu, – dokumentacja projektu; Programowanie obiektowe – realizacja projektu oprogramowania za pomocą języka programowania obiektowego; – języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów; 29. Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości. System informatyczny to złożony program

komputerowy lub zespół współdziałających ze sobą programów, przeznaczonych do wykonywania określonych funkcji: np. system operacyjny, system zarządzania bazami danych . Najczęściej o systemie informatycznym mówi się wtedy, gdy do zbierania, gromadzenia, przesyłania i przetwarzania danych zastosowane są techniczne środki informatyki, a przynajmniej komputer do przetwarzania. Zestaw technicznych środków informatyki jest przeznaczony do realizacji zadań określonych przez system informacyjny . Podsumowując – system informatyczny to określony obszar systemu informacyjnego danego obiektu, obsługiwany za pomocą technicznych środków dostępnych w informatyce. Wyznaczniki jakości systemu informatycznego: zgodny z wymaganiami użytkownika -niezawodny -efektywny -łatwy w konserwacji -interoperacyjny (jeżeli nie jest autonomiczny) -ergonomiczny 30. Omów podstawowe diagramy statyczne w języku IBM/Rational UML. Diagram klas – to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez ilustrację struktury klas i zależności między nimi. Elementami występującymi w diagramie klas są: -klasy -interfejsy -grupy współdziałania Pomiędzy elementami występującymi na diagramie klas występują związki: -zależności -generalizacji -asocjacji -agregacji Diagram klas jest najczęściej wykorzystywanym diagramem w notacji UML. Diagram obiektów - zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi.Każdy prostokąt na diagramie obiektów odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu pozostaje jasny. Diagram komponentów - (zwany także diagramem implementacji) to diagram przedstawiający jeden z aspektów modelu zgodnego z UML. Przedstawia fizyczne elementy wchodzące w skład systemu i połączenia między nimi. Diagram pakietów – to diagram służący do porządkowania struktury systemu. Stosowane, aby uprościć skomplikowane diagramy klas, klasy grupujemy w pakiety. Pakiet to zbiór logicznie powiązanych elementów UML. Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym. Diagram wdrożenia - (Deployment Diagram) obrazuje konfigurację węzłów działających w czasie wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera co najmniej jeden komponent. Diagramy wdrożenia zawierają na ogół węzły i powiązania między nimi. Są przydatne do modelowania systemów rozproszonych i typu klient-serwer. 31. Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML. Diagram przypadków użycia - opisuje, co robi system z punktu widzenia zewnętrznego obserwatora. Eksponują to, co robi system, a nie jak to robi. Diagramy przypadków użycia pozostają w bliskim związku ze scenariuszami.

Przypadek użycia to podsumowanie scenariuszy pojedynczego zadania lub celu. Aktor to ktoś albo coś, co inicjuje zdarzenia związane z tym zadaniem. Aktor po prostu określa rolę, którą odgrywa człowiek lub obiekt. Jeden przypadek użycia może mieć wielu aktorów. Diagramy przypadków użycia mają trzy zastosowania: -Określanie funkcji (wymagań). Nowe przypadki użycia często generują nowe wymagania, kiedy system jest analizowany i projekt przybiera coraz wyraźniejszy kształt. -Komunikacja z klientami. Prostota notacji sprawia, że diagramy przypadków użycia są dobrym sposobem porozumiewania się programistów z klientami. -Generowanie przypadków testowych. Zbiór scenariuszy danego przypadku użycia może zasugerować sposoby testowania tych scenariuszy. Diagram stanów -Obiekty cechują się zachowaniami i stanem. Stan obiektu zależy od jego bieżącej aktywności lub warunków. Diagram stanów pokazuje możliwe stany obiektu oraz przejścia, które powodują zmianę stanu. Stany to zaokrąglone prostokąty. Przejścia to strzałki wiodące od jednego stanu do drugiego. Zdarzenia lub warunki wyzwalające przejścia są zapisane obok strzałek. Diagram czynności (Activity Diagram) - to szczególny przypadek diagramu stanów, który obrazuje strumień kolejno wykonywanych czynności. Diagram czynności obrazuje przepływ sterowania (jest właściwie schematem blokowym). Przedstawia sekwencyjne (ew. współbieżne) kroki procesu obliczeniowego. Diagram czynności zawiera na ogół stany (akcji i czynności), przejścia oraz obiekty. Wykonywane obliczenia nazywamy stanami (akcji lub czynności). Stany akcji i czynności są szczególnymi przypadkami stanów maszyny stanowej. Diagram czynności jest rodzajem maszyny stanowej. Tory wskazują umiejscowienie czynności. Występując na diagramie czynności są pooddzielane pionowymi, ciągłymi liniami. Każdy tor ma unikatową nazwę. Diagram sekwencji (przebiegów) - opisują one, jak obiekty ze sobą współpracują. Diagram sekwencji to diagram interakcji, który szczegółowo pokazuje, w jaki sposób są wykonywane operacje - jakie komunikaty są wysyłane i kiedy. Czas upływa w miarę poruszania się w dół strony. Obiekty zaangażowane w operację są wymienione od lewej do prawej według tego, kiedy biorą udział w sekwencji komunikatów. Diagram współpracy (kooperacji) - to diagramy interakcji. Dostarczają tych samych informacji co diagramy sekwencyjne, ale skupiają się na rolach obiektów, a nie na czasach przesyłania komunikatów. Na diagramie sekwencyjnym role obiektów są wierzchołkami, a komunikaty - liniami łączącymi wierzchołki. Prostokąty opisujące rolę obiektu są oznaczone nazwami klas lub obiektów (albo obiema nazwami). Nazwy klas są poprzedzone dwukropkiem ( : ). 32. Omów podstawowe diagramy w metodyce Oracle CASE Method. Diagram zależności - to narzędzie do przedstawiania złożonych zależności miedzy przyczynami i skutkami. Diagramy zależności pozwalają odnaleźć często trudną do wykrycia zależność problemu od pierwotnej przyczyny. Pomagają zilustrować łańcuchy zależności i wzajemnych zależności, przez co ułatwiają podjęcie działania w odpowiednim miejscu. Pomagają również w identyfikacji efektów ubocznych tych działań. Diagram przepływu danych - (DFD – Data Flow Diagram) jest graficzną prezentacją przepływu danych w procesie. Na proces składają się następujące elementy: -Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej.

-Magazyny danych — trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji. -Terminatory — obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji. Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..). Diagram przepływu danych obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi. 33.Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1) podejście: encja-związek, 2) podejście obiektowe. Model encja-związek reprezentuje dane i związki pomiędzy nimi. Podejście to pozwala na odwzorowanie w systemie danych i powiązań pomiędzy nimi. Pozwala na analizę rodzajów danych, ich przepływu w procesach przetwarzania, oraz na odpowiednie zaprojektowanie przechowywania danych. Jest to podejście dobre dla systemów, których głównym zadaniem jest przetwarzanie danych i ich przedstawianie, a także przechowywanie. Korzystne dla systemów bazodanowych. Model obiektowy skupia się bardziej nad tym jak dane są przetwarzane, jaki jest do nich dostęp, jaka jest wymiana danych pomiędzy obiektami. W modelu obiektowym na drugi plan przesunięte jest jak dane są przechowywane, a także jak są reprezentowane. Znacznie istotniejsze jest kto ma do nich dostęp, jakie obiekty biorą udział w ich przetwarzaniu i jakie metody operują na danych. Podejście to jest korzystne dla wszystkich systemów, gdzie konieczna jest odpowiednia kontrola dostępu do danych, poprawności danych, oraz kontrola sposobu przetwarzania. 34.Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych. Audytem nazywany jest niezależny przegląd i ocenę jakości oprogramowania, która zapewnia zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami. Aby zapewnić obiektywność, audyt powinien być przeprowadzony przez osoby niezależne od zespołu projektowego. Audyt powinien być przeprowadzany przez odpowiednią organizację audytu (która aktualnie formuje się w Polsce, Polskie Stowarzyszenie Audytu) lub przez osoby posiadające uprawnienia/licencję audytorów. Reguły i zasady audytu są określone w normie: ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”. Celem Audytu jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie projektu. Zebrane informacje służą jako podstawa do podejmowania strategicznych decyzji w projekcie Przedmioty: - procesy projektu informatycznego - ma to na celu sprawdzenie, czy wykonane prace oraz sposób ich wykonania są prawidłowe - produkty projektu informatycznego - ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom. Perspektywy: - technologia - ma na celu sprawdzenie, czy użyte techniki oraz opracowane rozwiązania są prawidłowe i prawidłowo stosowane - zarządzanie - ma to na celu sprawdzenie, czy sposób zarządzania projektem umożliwia jego sukces 35.Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów informatycznych.

Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane przez osobę lub grupę osób nie będących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów [IEEE Std. 729-1983] - Inspekcje stosowane są dla "elitarnych" systemów, czyli takich, które spełniać mają bardzo ważne zadania. - nie jest prosta analiza kosztów inspekcji, - nie ma gotowych narzędzi programowych - wymagane jest doświadczenie ludzi. Korzyści z inspekcji: - wzrost produktywności - skrócenie czasu projektu - zmniejszenie kosztu i skrócenie czasu wykonania testów (mniej testów regresyjnych) - 10x mniejsze koszty pielęgnacji - poprawa procesu programowego - większy komfort pracy - mniejsze koszty marketingu Inspekcje przeprowadzane są przez specjalistów dla specjalistów bez udziału kierownictwa. Przykładowo inspekcje modułów są przeprowadzane przez pracujące równolegle podgrupy projektowe. 36.Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego. badanie prognostyczne - zanim powstanie kod źródłowy, czyli w fazach: określenia wymagań i projektowania Zalety: - Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów, - Stosunkowo niskie koszty testowania, - Możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji Wady: - Bazowanie na modelu oprogramowania, co może zmniejszyc dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi badania diagnostyczne: Typy: - Analiza dynamiczna - analiza statyczna - inspekcje - audyty 37. Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu

ormatycznego. inf Na podstawie art. 21 ust. 6 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne (Dz. U. Nr 64, poz. 565) zarządza się, co następuje: § 1. Rozporządzenie określa: 1) metodykę , warunki i tryb sporządzania testów akceptacyjnych; 2) sposób postępowania w zakresie badania, o którym mowa w art. 21 ust. 1 ustawy z dnia 17 lutego 2005 r. o informatyzacji działalności podmiotów realizujących zadania publiczne, zwanego dalej „badaniem”, w tym sposób dokumentowania wyników badania oraz weryfikacji badania; § 3. 1. Podmiot publiczny sporządza testy akceptacyjne z zachowaniem metodyki prowadzenia projektów informatycznych o publicznym zastosowaniu odpowiadającej specyfice systemu teleinformatycznego używanego do realizacji zadań publicznych, w zakresie obejmującym wyłącznie funkcjonalność oprogramowania testowanego. 2. Sporządzenie testu akceptacyjnego obejmuje przygotowanie: 1) specyfikacji przypadku testowego, zgodnie z wzorem określonym w załączniku nr 1 do rozporządzenia; 2) specyfikacji scenariusza testowego, zgodnie z wzorem określonym w załączniku nr 2 do rozporządzenia, jeżeli jej sporządzenie jest niezbędne do przeprowadzenia badania z uwagi na funkcjonalność oprogramowania testowanego. § 4. 1. Podmiot publiczny, mając na uwadze, aby badanie obejmowało w pełni funkcjonalność oprogramowania testowanego:

1) sporządza opis badania składający się z: a) specyfikacji poszczególnych przypadków testowych, b) specyfikacji poszczególnych scenariuszy testowych w przypadku, o którym mowa w § 3 ust. 2 pkt 2; 2) zapewnia, nieodpłatnie dla podmiotów uprawnionych, dostęp do oprogramowania testowego albo, zgodnie z § 5 ust. 2, do oprogramowania komunikacyjnego; 3) publikuje, w Biuletynie Informacji Publicznej, opis badania, o którym mowa w pkt 1, oraz informacje niezbędne dla uzyskania skutecznego dostępu przez podmioty uprawnione do oprogramowania, o którym mowa w pkt 2. 38. Omów istotę testowania metodą black box i white box. White box Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania programu. Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku. Często niezbędne staje się wcześniejsze przygotowanie danych testowych lub specjalnych programów usprawniających testowanie (np. programu wywołującego testowaną procedurę z różnymi parametrami). Dane testowe powinny być dobrane w taki sposób, aby każda ścieżka w programie była co najmniej raz przetestowana. Ograniczeniem testowania na zasadzie białej skrzynki jest niemożliwość pokazania brakujących funkcji w programie. Wadę tę usuwa testowanie n/z czarnej skrzynki. Black box Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne. Testowanie n/z czarnej skrzynki powinno obejmować cały zakres danych wejściowych. Testujący powinni podzielić dane wejściowe w „klasy równoważności”, co do których istnieje duże przypuszczenie, że będą produkować te same błędy. Np. jeżeli testujemy wartość „Malinowski”, to prawdopodobnie w tej samej klasie równoważności jest wartość „Kowalski”. Celem jest uniknięcie efektu „eksplozji danych testowych”. „Klasy równoważności” mogą być również zależne od wyników zwracanych przez testowane funkcje. Np. jeżeli wejściem jest wiek pracownika i istnieje funkcja zwracająca wartości „młodociany”, „normalny” „wiek emerytalny”, wówczas implikuje to odpowiednie klasy równoważności dla danych wejściowych. Wiele wejść dla danych (wiele parametrów funkcji) może wymagać zastosowania pewnych systematycznych metod określania ich kombinacji, np. tablic decyzyjnych lub grafów przyczyna-skutek. 39. Omów zagadnienie architektury systemów informatycznych. - Architektura globalna: koordynacja i komunikacja pomiędzy organizacjami; - Architektura korporacyjna (enterprise): koordynacja i komunikacja w obrębie organizacji; - Architektura systemu: koordynacja i komunikacja pomiędzy aplikacjami; - Architektura aplikacji (Subsystem): dostarczanie funkcjonalności; - Makro-architektura (Frameworks): powtarzające się aplikacje; - Mikro-architektura: wzorce projektowe; - Obiekty: specyficzne konstrukcje w językach programowania; 40. Omów zagadnienie projektowania

rchitektonicznego systemów informatycznych. a Wzorce architektoniczne 1.Konstrukcyjne:

- Służą do pozyskiwania obiektów; - Opisują szczegółowo, jak obiekt może zostać stworzony, - Czynią kod niezależnym od typów tworzonych obiektów; - Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych; - Przykłady: + Singleton, + Fabryka, + Metoda Fabrykująca, + Fabryka Abstrakcyjna, + Budowniczy, + Prototyp; 2.Strukturalne: - Stosowany do łączenia obiektów w większe struktury; - Zastosowanie np. w implementacji złożonego interfejsu użytkownika; - Przykłady: + Fasada, + Adapter, + Most, + Kompozyt, + Dekorator, + Waga Piórkowa, + Proxy; 3.Operacyjne: - W celu definiowania komunikacji pomiędzy obiektami; - Pomagają kontrolować przepływ danych w złożonym programie; - Przykłady: + Iterator, + Łańcuch Odpowiedzialności, + Stan, + Mediator, + Obserwator, + Strategia; 41. Omów istotę koncepcji wzorców projektowych w

rojektowaniu systemów informatycznych. p Wzorce projektowe stanowią powtarzalne rozwiązanie zagadnień projektowych, z którymi się wciąż spotykamy; - Wzorce dostarczają sprawdzonych rozwiązań dla powtarzających się problemów; - Możliwe do zastosowania w wielu rzeczywistych kontekstach; - Wpływają na sposób modelowania; - Zapobiegają „wymyślaniu koła od nowa”; - Usprawniają komunikację - Ułatwiają tworzenie dokumentacji 42. Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu). - konstrukcyjne --- służą do pozyskiwania obiektów; --- opisują szczegółowo, jak obiekt może zostać stworzony, --- czynią kod niezależnym od typów tworzonych obiektów; --- wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych; - strukturalne --- stosowany do łączenia obiektów w większe struktury; --- zastosowanie np. w implementacji złożonego interfejsu użytkownika - operacyjne (czynnościowe) --- definiowanie komunikacji pomiędzy obiektami; --- kontrolowanie przepływów danych w złożonych algorytmach (programach); --- przydział zobowiązań obiektom; 43. Omów model niezawodności oprogramowania

dług Jelińskiego-Morandy (1972). we - Wykrywanie błędów jest niezależne; - Usuwanie wykrytych błędów nie generuje nowych; - Intensywność wykrywania błędów - proporcjonalna do liczby błędów pozostających w oprogramowaniu: (nie dałem rady przenieść tego wzoru) 44.Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki kosztów. Wyniki badań przeprowadzonych przez Boehma w latach osiemdziesiątych jak i obecnie prowadzone

badania potwierdzają, że koszt poprawy błędu rośnie wykładniczo w zależności od etapu wytwarzania oprogramowania. Najmniej kosztuje poprawa na etapie analizy, najwięcej po wdrożeniu systemu do produkcji. Jeśliby błąd związany z rokiem 2000 usunąć na etapie implementacji to koszt z tym związany byłby tysiąckrotnie niższy w stosunku do kosztu związanego z jego poprawą po wdrożeniu systemu. W większości procesów wytwarzania testowanie systemu jest wykonywane na samym końcu. Oznacza to, że jest ono szczególnie narażone na przekroczenie kosztów i harmonogramu, co oznacza po prostu, że czas potrzebny na testowanie jest obcinany, ponieważ wcześniejsze fazy przekroczyły termin i budżet. Szacunki kosztów wg Roger’a Pressman’a (1997): --- Testowanie: ~ 30 % - 40 % całkowitej pracochłonności; --- Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!); Dodatkowo należy brać pod uwagę tzw. koszty utraconych korzyści 45.Omów źródła kosztów nieprawidłowości oprogramowania. Oprogramowanie zawierające błędy, może być źróbłem kosztów. Koszt wykrycia i naprawienia błędu często przekrocza koszt napisania fragmentu kodu od nowa. Do kosztów oprogramowania złej jakości zaliczamy: 1) Koszty jakości w skład których wchodzą: -koszty błędów (traktowane jako straty), -koszty oceny (traktowane jako nakłady), -koszty zapobiegania (traktowane jako nakłady). 2) Koszty procesu: -koszty niezgodności (traktowane jako straty), -koszty zgodności (traktowane jako nakłady). 3) Straty jakości (skutki odchyleń od wymagań jakościowych) Program złej jakości może mieć również potencjalnie duże koszty błędnych wykonań co może narazić na wysokie straty finansowe instytucji korzystającej z błędnie działającego oprogramowania. Oprogramowanie dobrej jakości to mniejsze koszty pielęgnacji (naprawczej) oraz mniejsze koszty marketingu który ma na celu ukrywanie braku jakości 46.Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady. Testowanie oprogramowania - proces związany z wytwarzaniem oprogramowania. Jest jednym z procesów kontroli jakości oprogramowania. Testowanie oprogramowania jest jednym z kluczowych etapów procesu zapewnienia jego jakości. Celem testowania oprogramowania jest sprawdzanie jak dobry jest docelowy produkt oraz sprawdzenie czy oprogramowanie spełni swoje zadanie. Wśród testów wyróżniamy testy dynamiczne, które polegają na wykonywaniu (fragmentów) programu albo modeli symulacyjnych i porównywaniu uzyskanych wyników z wynikami poprawnym oraz testy statyczne, oparte na analizie kodu albo modeli analitycznych lub projektowych .Testowaniu oprogramowania podlega: wsydajność systemu, interfejsy systemu, własności operacyjne systemu, testy zużycia zasobów oraz zabezpieczenie systemu Weryfikacja - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań. Proces weryfikacji oprogramowania można określić jako poszukiwanie i usuwanie błędów na podstawie obserwacji błędnych wykonań oraz innych testów. Weryfikacja uwzględnia następujące czynności: przeglądy techniczne oraz inspekcje oprogramowania; sprawdzanie czy wymagania na oprogramowanie są zgodne z wymaganiami użytkownika; sprawdzanie czy komponenty projektu są zgodne z wymaganiami na oprogramowanie; testowanie jednostek oprogramowania (modułów); testowanie integracji oprogramowania, testowanie systemu; testowanie akceptacji systemu przez użytkowników Walidacja (atestowanie)- ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową. Walidacja sprawdza, czy

oprogramowanie jest zgodne z oczekiwaniami użytkownika. 47.Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania. Badanie prognostyczne przeprowadzane są wtedy gdy nie ma kodu źródłowego. Głównymi zaletami podejścia prognostycznego jest: Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów; stosunkowo niskie koszty testowania oraz możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji. Wadą podejścia prognostycznego jest bazowanie na modelu oprogramowania, co może zmniejszyć dokładność badania (potencjalna rozbieżność z właściwościami implementacyjnymi). Metody prognostyczne bazują na: metodach specyfikacji formalnej programów; badaniu logiki sterowania programów oraz na metrykach projektu oprogramowania. Wyróżniamy dwa komplementarne podejścia: badanie właściwości statycznych oraz badanie właściwości dynamicznych 48.Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania. Badanie diagnostyczne przeprowadzane są gdy istnieje kod źródłowy. W skład diagnostycznego badania oprogramowania wchodzi analiza dynamiczna czyli eksperymentowanie z działającym kodem programu oraz analiza statyczna czyli praca z kodem źródłowym w celu rozpoznania funkcjonalności testowanego kodu oraz zaprojektowania odpowiednich testów. Do Testów diagnostycznych zalicza się testy strukturalne (testy białej skrzynki), które opracowuje się na podstawie wiedzy i implementacji oprogramowania. Stosuje się je do stosunkowo niewielkich jednostek programów, takich jak podprogramy i operacje związane z obiektem. Podczas testów strukturalnych tester może analizować kod i korzystać z wiedzy o strukturze komponentu przy opracowywaniu danych testowych. Drugim rodzajem testów diagnostycznych jest Testowanie strategią czarnej skrzynki. Polega ono na sprawdzaniu funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne. Testowanie metodą czarnej skrzynki powinno obejmować cały zakres danych wejściowych. Tester zadaje dane wejściowe i analizuje dane wyjściowe. Jeżeli dane wyjściowe (wyniki) nie są zgodne z założeniami, to test pozytywnie wykrył defekt oprogramowania. 49. Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości. Użyteczność - dostępność oczekiwanych usług Niezawodność – np. prawdopodobieństwo błędu w czasie realizacji transakcji, średni czas pomiędzy błędnymi wykonaniami, dostępność (procent czasu, w którym system jest dostępny), czas restartu po awarii systemu, prawdopodobieństwo zniszczenia danych w przypadku awarii. Efektywność Wielokrotne użycie – ponowne wykorzystanie gotowych elementów Pielęgnacyjność – podatność na pielęgnowanie, łatwość wprowadzania zmian Przenośność – np. procent kodu zależnego od platformy docelowej, liczba platform docelowych, koszt przeniesienia na nową platformę. Testowalność – podatność na testowanie 50. Omów główne klasy błędów w systemach informatycznych Klasyfikacja błędów: - funkcjonalne - funkcja źle wykonana bądź źle funkcjonująca - systemowe - nieprawidłowe zarządzanie zasobami, mylne interfejsy, zła komunikacja z bazą danych bądź jej brak

- przetwarzania - niewłaściwe przetwarzanie danych w poszczególnych modułach - danych - źle wprowadzone dane, ich brak, błędna specyfikacja - graficzne - interfejs graficzny niezgodny z założeniami - kodowania - niewłaściwe użycie języka programowania - dokumentacji - niepełna lub błędna dokumentacja - inne - niezidentyfikowana przyczyna wystąpienia 51. Omów czynności procesu testowania oprogramowania. Fazy procesu testowania: - testowanie komponentów (jednostek) - testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie, - testowanie modułów - moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów, abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji, - testowanie podsystemów - ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w podsystemie, - testowanie systemu - ten proces testowania ma wykryć błędy wynikające z nieprzewidzianych interakcji między zintegrowanymi podsystemami i problemów z interfejsami podsystemów, - testowanie odbiorcze - jest to końcowa faza procesu testowania przed przyjęciem systemu do użytkowania. 52. Co to jest przypadek testowy, scenariusz testów? Podaj przykłady. Scenariusz testów: - dokument opisujący procedury i przypadki testowe dla określonego produktu - jest podstawą pracy testera z danym produktem - obejmuje: --- listę testowanych produktów --- odwołania do wymagań --- przypadki testowe --- kryteria poprawności --- listę agentów testowych --- szczegółowe procedury testowania dla produktów Przypadek testowy: - ściśle określona ścieżka przejścia przez testowany produkt lub charakterystyczna klasa danych wejściowych - określa szczegółowy zakres w testowanym produkcie, pozwalający rozłożyć skomplikowany problem testowy na elementarne części 53.Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady. Macierz przykrycia testów akceptacyjnych to sposób przedstawienia powiązania przypadków testowych z funkcjami systemu. Na jednej osi macierzy rozpisane są wszystkie elementy systemu wymagające testowania. Mogą być to funkcjonalności, przypadki użycia, moduły, bądź inne jednostki składowe systemu. Na drugiej osi rozpisane zostają przypadki testowe. Na przecięciu osi zaznacza się jeśli przypadek testowy bada dany element systemu. Dzięki macierzy przykrycia testów możliwe jest szybkie wykrycie nadmiarowych przypadków testowych, albo elementów, które nie są testowane. 54.Omów podstawowe schematy testów integracyjnych. Podaj przykłady. -Skokowe - grupują wybrane (lub wszystkie) jednostki w celu ich równoczesnego przetestowania -Przyrostowe - zakładają dołączenie do tworzonej całości za każdym razem tylko jednej uprzednio przetestowanej jednostki: – zstępujące (odgórne) - integruje się i testuje się komponenty wysokiego poziomu przed ukończeniem ich projektu i implementacji; np.: (Namiastka (stub): - imituje jednostki niższego poziomu - zastępuje moduły wywoływane przez testowany moduł ) – wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu przed ukończeniem budowy komponentów wyższego poziomu;np.:(

Sterownik (driver): - dostarcza jednostkom niższego poziomu dane - zastępuje moduł wywołujący testowane moduły) 55.Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca konstrukcyjnego. -Służą do pozyskiwania obiektów; -Opisują szczegółowo, jak obiekt może zostać stworzony, -Czynią kod niezależnym od typów tworzonych obiektów; -Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych; -Przykłady: -Singleton, -Fabryka, -Metoda Fabrykująca, -Fabryka Abstrakcyjna, -Budowniczy, -Prototyp; 56.Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca strukturalnego. Strukturalne wzorce projektowe - Zastosowanie np. w implementacji złożonego interfejsu użytkownika; - Stosowane do łączenia obiektów w większe struktury Jednym z przykładów jest Fasada: - Ujednolicony i prostszy interfejs do struktury złożonych podsystemów; - Separacja klienta od złożonych podsystemów; - Wybór odpowiedniej struktury dla żądania klienta; - Możliwości zmian w ukrywanych podsystemach; Np. - w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet); - wejście usług w Service Oriented Architecture (SOA); 57.Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca czynnościowego. Wzorce czynnościowe inaczej zwane operacyjnymi, służą do: - definiowanie komunikacji pomiędzy obiektami; - kontrolowanie przepływów danych w złożonych algorytmach (programach); - przydział zobowiązań obiektom; Jednym z przykładów może być iterator: - Upraszcza przemieszczanie po kolekcji danych (np. liście), z wykorzystaniem standardowego interfejsu; - Nie wymaga znajomości wewnętrznej struktury kolekcji danych; - Umożliwia równoczesne przeglądanie kilku kolekcji; Np. - W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;