Omów przedmiot i zakres inżynierii oprogramowania.

Przedmiot: Inżynieria oprogramowania jest wiedzą techniczną dotycząca wszystkich faz cyklu życia oprogramowania. Traktuje oprogramowanie jako produkt, który ma spełniać potrzeby techniczne, ekonomiczne lub społeczne. Dobre oprogramowanie powinno być: zgodne z wymaganiami użytkownika, niezawodne, efektywne, łatwe w konserwacji, interoperacyjne (jeżeli nie jest autonomiczne), ergonomiczne. Inżynieria oprogramowania jest wiedzą empiryczną, syntezą doświadczenia tysięcy ośrodków zajmujących się budową oprogramowania.

Zakres: Sposoby prowadzenia przedsięwzięć informatycznych. Techniki planowania, szacowania kosztów, harmonogramowania i monitorowania przedsięwzięć informatycznych. Metody analizy i projektowania systemów. Techniki zwiększania niezawodności oprogramowania. Sposoby testowania systemów i szacowania niezawodności. Sposoby przygotowania dokumentacji technicznej i użytkowej. Procedury kontroli jakości. Metody redukcji kosztów konserwacji (usuwania błędów, modyfikacji i rozszerzeń) Techniki pracy zespołowej i czynniki psychologiczne wpływające na efektywność pracy.

Omów przykładowe źródła złożoności projektu informatycznego.

Dziedzina problemowa - obejmuje ogromną liczbę wzajemnie uzależnionych aspektów i problemów; Środki i technologie informatyczne - sprzęt, oprogramowanie, sieć, języki, narzędzia, udogodnienia; Zespół projektantów - podlega ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji; Potencjalni użytkownicy - czynniki psychologiczne, ergonomia, ograniczenia pamięci i percepcji, skłonność do błędów i nadużyć, tajność, prywatność;

Omów zagadnienie semiotyki języka programowania.

Język programowania jest środkiem umożliwiającym zapis algorytmów w postaci zrozumiałej dla człowieka, a równocześnie przetwarzanej do postaci zrozumiałej dla komputera (maszyny algorytmicznej). 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

Syntaktyka jest częścią ogólnej teorii znaków (semiotyki) i zajmuje się strukturą i formą wyrażeń, a także dopuszczalnymi zmianami ich formy, zwanymi „przekształceniami”. Wyróżnia się dwa rodzaje reguł składniowych: reguły formowania, określające zbiór wyrażeń poprawnie zbudowanych na określonym alfabecie języka; reguły przekształcania, określające zbiór możliwych przekształceń na bazie słów z zadanego zestawu słownika

W dziedzinie algorytmiki, jak również logiki matematycznej mają zastosowanie wyłącznie reguły inferencyjne, tzn. takie przekształcenia, które są prawdziwe w sensie logiki

Najczęściej przyjmuje się, że mamy do czynienia z dwoma podzbiorami dziedziny nazywanej syntaktyką:

syntaktyka formalna, która jest rozumiana jako ogólne badania formalne, dotyczące języków logiki i matematyki, jak również języków naturalnych, syntaktyka logiczna, która zajmuje się badaniem języków logiki i matematyki (np. rachunek predykatów, rachunek zdań)

Językami programowania, badaniem ich algorytmiczności zajmuje się syntaktyka języków programowania, która jest jednym z rodzajów syntaktyk formalnych

Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.

Podstawowym powodem kryzysu oprogramowania jest złożoność produktów informatyki i procesów ich wytwarzania. Zasadnicze problemy wytwórców oprogramowania: wzrost mocy sprzętu zwiększa zapotrzebowanie na nowe, bardziej złożone oprogramowanie; długi i kosztowny cykl wytwarzania oprogramowania; frustracje projektantów oprogramowania i programistów wynikające ze zbyt szybkiego postępu w zakresie języków, narzędzi i metod; uzależnienie organizacji od systemów komputerowych i przyjętych technologii przetwarzania informacji, które nie są stabilne w długim horyzoncie czasowym; brak kontaktów pomiędzy użytkownikiem i firmą; problemy współdziałania niezależnie zbudowanego oprogramowania, szczególnie istotne przy dzisiejszych tendencjach integracyjnych; niska kultura ponownego użycia wytworzonych komponentów projektów i oprogramowania; zbyt późne wykrywanie błędów i słabych punktów; brak koordynacji w pracy zespołów projektowych; ogromne koszty utrzymania oprogramowania; Skutki: 27% projektów powstaje w założonym czasie, budżecie i funkcjonalności, 33% projektów przekracza czas, budżet i ma mniejszą funkcjonalność, 40% projektów jest przerywanych, 53% projektów przekracza koszty o 51%, 68% projektów przekracza czas o 51% , 69% niepowodzeń to czynniki pozainformatyczne.

Omów następujący model cyklu życia oprogramowania:

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ół odpowiada wyłącznie za ocenę i testowanie systemu. testy odbywają sie od zadań, potem przechodzą do testowania podsystemów, a następnie testowany jest pełny system.

Omów sposoby opanowywania złożoności projektu informatycznego.

Zasada dekompozycji: rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie od całości. Zasada abstrakcji: eliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy. Zasada ponownego użycia: wykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd. Zasada sprzyjania naturalnym ludzkim własnościom: dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata.

Omów zagadnienie modelowania pojęciowego w projekcie informatycznym.

Projektant i programista muszą dokładnie wyobrazić sobie problem oraz metodę modelowania pojęciowego. Zasadnicze procesy tworzenia oprogramowania zachodzą w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania. Pojęcia modelowania pojęciowego (conceptual modeling ) oraz modelu pojęciowego (conceptual model ) odnoszą się procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Modelowanie pojęciowe jest wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości, struktur danych oraz programów składających się na konstrukcję systemu. Perspektywy w modelowaniu pojęciowym: Percepcja rzeczywistego świata<--dwzorowanie->Analityczny model rzeczywistości<-odwzorowanie->Model struktur danych i procesów SI

Co to jest metodyka prowadzenia projektu informatycznego?

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. Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu (pośrednich, końcowych), jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek komunikacji w zespołach oraz pomiędzy projektantami i klientem.

Metodyka ustala: fazy projektu, role uczestników projektu, modele tworzone w każdej z faz, scenariusze postępowania w każdej z faz, reguły przechodzenia od fazy do następnej fazy, notacje, których należy używać, dokumentację powstającą w każdej z faz.

Omów następujący model cyklu życia oprogramowania:

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.

Model ten składa się z następujących faz: ogólne określenie wymagań ; budowa prototypu; weryfikacja prototypu przez klienta; pełne określenie wymagań; realizacja pełnego systemu zgodnie z modelem kaskadowym. Głównym celem realizacji prototypu jest lepsze określenie wymagań, czyli: wykrycie nieporozumień pomiędzy klientem a twórcami systemu; wykrycie brakujących funkcji; wykrycie trudnych usług; wykrycie braków w specyfikacji wymagań/

Omów następujący model cyklu życia oprogramowania:

Model kaskadowy zwany tez modelem wodospadu lub liniowym, jest klasycznym modelem cyklu życia oprogramowania. Jest to model, który został zaproponowany poprzez analogię do sposobu prowadzenia przedsięwzięć w innych dziedzinach inżynierii, na przykład budownictwie. Model kaskadowy składa się czynności które podczas tworzenia oprogramowania są wykonywane sekwencyjnie: określenie wymagań , w której określane są cele oraz szczegółowe wymagania wobec tworzonego systemu; analiza; projektowanie, w której powstaje szczegółowy projekt systemu spełniającego ustalone wcześniej wymagania; implementacja, w której projekt zostaje zaimplementowany w konkretnym środowisku programistycznym oraz wykonane są testy poszczególnych modułów; testowanie, w której następuje integracja poszczególnych modułów połączonych z testowaniem poszczególnych podsystemów oraz całego oprogramowania; konserwacja, w której oprogramowanie jest wykorzystywane przez użytkowników,; a producent dokonuje konserwacji oprogramowania – wykonuje modyfikacje polegające na usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu.

Wady modelu kaskadowego: 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.

Model ten mimo swoich wad jest niezbędny dla planowania, harmonogramowania, monitorowania i rozliczeń finansowych. Występuje także zmodyfikowany model kaskadowy z iteracjami. Modyfikacja ta polega na tym, że z każdej fazy można się cofnąć do faz wcześniejszych.

Omów następujący model cyklu życia oprogramowania:

Model spiralny składa się z czterech głównych faz wykonywanych cyklicznie: analiza ryzyka; konstrukcji; atestowania; planowania.

W pierwszej fazie rozważane są ogólne opcje budowy nowej wersji systemu. Możliwości te są analizowane przy wzięciu pod uwagę ryzyka związanego z ich realizacją. Problematyka analizy opcji omawiana jest w kolejnym rozdziale dotyczącym fazy strategicznej realizacji przedsięwzięcia. Faza ta może obejmować także budowę prototypu. W kolejnej fazie konstruowana jest kolejna wersja systemu w sposób zgodny z modelem kaskadowym. W fazie atestowania kolejna wersja systemu jest oceniana przez klienta. Jeżeli ocena nie jest w pełni pozytywna rozpoczynany jest kolejny cykl. W fazie planowania ustalane są generalne cele produkcji kolejnej wersji systemu.

Model przyrostowy: Rozpoczyna się od określenia wymagań oraz wykonania wstępnego, ogólnego projektu całości systemu. Następnie wybierany jest pewien podzbiór funkcji systemu. Dalej, zgodnie z przebiegiem modelu kaskadowego, wykonywany jest szczegółowy projekt oraz implementacja części systemu realizującej te funkcje. Po przetestowaniu zrealizowany fragment pełnego systemu może zostać dostarczony klientowi. Zalety tego modelu to: skrócenie przerw w kontaktach z klientem; możliwość wczesnego wykorzystania przez klienta dostarczonych fragmentów systemu; możliwość elastycznego reagowania na powstałe opóźnienia. Jeżeli realizacja fragmentu systemu opóźni się, nie musi to oznaczać opóźnienia całego przedsięwzięcia. Istnieje wtedy możliwość przyspieszenia prac nad dalszymi częściami. Wadą tego modelu jest pewien dodatkowy koszt związany niezależną realizacją fragmentów systemu. Z reguły nie jest możliwe proste wycięcie podzbioru funkcji w pełni niezależnych od pozostałych. W związku z tym może zajść konieczność implementacji tzw. Szkieletów modułów, tj. modułów o interfejsie zgodnym z modułami, które znajdą się pełnym systemie lecz nie realizujących w pełni ich funkcji. Implementacja tych modułów to oczywiście pewien dodatkowy nakład pracy oraz zwiększone ryzyko nie wykrycia błędów w fazie testowania.

Model ewolucyjny: Wytwarzanie ewolucyjne polega na: opracowaniu wstępnej implementacji; pokazaniu jej użytkownikowi z prośbą o komentarze; udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu;

Rodzaje wytwarzania ewolucyjnego:

Tworzenie badawcze: celem procesu jest praca z klientem, polegająca na badaniu wymagań i dostarczeniu ostatecznego systemu; tworzenie rozpoczyna się od tych części systemu, które są dobrze rozpoznane; system ewoluuje przez dodawanie nowych cech, które proponuje klient;

Prototypowanie z porzuceniem: celem procesu tworzenia ewolucyjnego jest zrozumienie wymagań klienta i wypracowanie lepszej definicji wymagań stawianych systemowi; budowanie prototypu ma głównie na celu eksperymentowanie z tymi wymaganiami użytkownika, które są niejasne;

Wady modelu ewolucyjnego: nie jest proces widoczny; system ma złą strukturę; konieczne mogą być specjalne narzędzia i techniki;

Stosowanie: w wypadku systemów małych (mniej niż 100 000 wierszy kodu) lub średnich (do 500 000 wierszy kodu) z krótkim czasem życia podejście ewolucyjne jest dobre; wypadku dużych systemów o długim czasie życia wady tworzenia ewolucyjnego ujawniają się jednak z całą ostrością;

Omów następujący model cyklu życia oprogramowania:

Programowanie odkrywcze zalecane jest w sytuacjach gdy określenie wymagań klienta może być tak trudne, że nawet budowa pojedynczego prototypu nie wystarcza dla rozwiania wszelkich wątpliwości. Model ten rozpoczyna się od wstępnego, bardzo ogólnego określenia wymagań. Następnie bardzo szybko rozpoczyna jest realizacja systemu. Faza realizacji obejmuje z reguły wykonanie przynajmniej bardzo ogólnego projektu. System jest następnie weryfikowany przez klienta. Jeżeli zostanie on uznany za nieodpowiedni, budowana jest kolejna wersja systemu. Nie jest to przy tym budowa od podstaw lecz najczęściej modyfikacja poprzedniej wersji. Cykl kończy się jeżeli jedna z kolejnych wersji zadowala klienta, lub dojdzie on do wniosku, że nie jest możliwe osiągnięcie zadowalającego efektu. Zaletą tego modelu jest możliwość stosowania nawet w wypadkach dużych trudności z określeniem wymagań klienta. Wady tego modelu: praktycznie niemożliwe jest zachowanie sensownej struktury systemu, nawet jeżeli na wstępie wykonano ogólny projekt. Struktura zaproponowana na wstępie na pewno zaginie w kolejnych iteracjach wprowadzania zmian do systemu. Po kilku iteracjach okazuje się, że wprowadzanie kolejnych zmian i usuwanie kolejnych błędów, powoduje dodawanie nowych błędów. W efekcie praktycznie nie możliwe jest wykonanie w ten sposób większych systemów o zadowalającej niezawodności. ponieważ model ten nie obejmuje pełnego określenia wymagań, testowanie systemu może odbywać się prawie wyłącznie przy bezpośrednim udziale klienta. W wypadku innych modeli testowanie polega przede wszystkim na weryfikowaniu zgodności systemu z wcześniej sprecyzowanymi wymaganiami.

Omów następujący model cyklu życia oprogramowania:

Montaż z gotowych elementów kładzie szczególny nacisk na możliwości redukcji nakładów przez maksymalne wykorzystanie podobieństw tworzonego oprogramowania do wcześniej tworzonych systemów. Gotowe elementy mogą być wykorzystywane na różnych etapach realizacji przedsięwzięcia. Najczęściej są one wykorzystywane na etapie implementacji. Przykładem może być stosowanie: bibliotek; języków czwartej generacji, których złożone instrukcje mogą być traktowane jako odwołania do wybudowanych bibliotek; pełnych aplikacji np. wykorzystanie przeglądarki plików pomocy w systemie MS Windows Istnieją dwie metody pozyskiwania gotowych elementów: zakup od zewnętrznych dostawców; opracowanie wyników aktualnie realizowanych przedsięwzięć tak, aby mogłyby być wykorzystane w kolejnych przedsięwzięciach. Zalety stosowania gotowych elementów to: wysoka niezawodność; zmniejszenia ryzyka; efektywne wykorzystanie specjalistów; narzucanie standardów; Wadami tego modelu są: dodatkowy koszt przygotowania elementów do ponownego wykorzystania. ryzyko uzależnienia się od dostawcy elementów niedostatki narzędzi wspomagających ten rodzaj pracy.

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.

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ę.

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ą.

Czynniki psychologiczne mają zasadniczy wpływ na efektywność pracy zespołu. 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.

Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania.

Celem fazy określenia wymagań jest ustalenie wymagań klienta wobec tworzonego systemu. Dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie tych celów. Proces inżynierii wymagań to: wynajdowanie, analizowanie, specyfikowanie i dokumentowanie sprawdzania usług i ograniczeń

W zakresie inżynierii wymagań wyróżnia się: wymagania użytkownika, wymagania systemowe, wymagania funkcjonalne i niefunkcjonalne, dokumentacje wymagań stawianych oprogramowaniu.

Punktem wyjściowym w projektowaniu w pełni funkcjonalnej aplikacji są trzy podstawowe elementy związane z inżynierią wymagań, czyli:

• zebranie wymagań użytkowników,

• zarządzanie tymi wymaganiami, czyli zestawienie powstałej specyfikacji z oczekiwaniami klienta,

• weryfikowanie tych wymagań poprzez stałą komunikację całego zespołu, aby upewnić się, że powstaje odpowiednia aplikacja.

Projekt powinien odnosić się do trzech poziomów wymagań: 1.Wymagania biznesowe(potrzeby) 2. Wymagania użytkownika(cechy) 3.Wymagania systemowe(funkcjonalne, niefunkcjonalne).

Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań.

Dobry opis wymagań powinien być: kompletny; Niesprzeczny; Weryfikowalny; Realizowalny.

Ponadto: Opisywać zewnętrzne zachowania systemu z pominięciem sposobu jego realizacji; Obejmować ograniczenia, przy jakich musi pracować system; Łatwy w modyfikacji; Zapewniać możliwości zmiany wymagań w kolejnych etapach; Zawierać zachowania systemu w niepożądanych lub skrajnych sytuacjach (brzegowych);

Metody rozpoznawania 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.

Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań.

Funkcjonalne (jakie usługi oferuje, jak ma reagować, jakie dane przyjmować): system wymaga logowania użytkownika; możliwość sprawdzania postępów pracy w każdym momencie. Niefunkcjonalne (ograniczenia czasowe, standardy): system powinien odszukiwać dane każdego użytkownika poniżej 10 sekund; -system nie powinien zajmować więcej niż 10GB. Dziedzinowe (odzwierciedlają charakterystykę dziedziny systemu, mogą być funkcjonalne lub niefunkcjonalne): Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50

Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.

Wymagania funkcjonalne określają jakie usługi ma oferować system, jak ma reagować na otrzymywane dane wejściowe oraz w określonych sytuacjach. Określają one użytkowników korzystających z systemu oraz możliwości każdego z nich. Określają również wykorzystanie systemów zewnętrznych. Mogą one również określać czego system nie powinien robić. Wymagania funkcjonalne mogą być realizowane przez systemy zewnętrzne. Przykłady:
wprowadzenie nie pełnych danych system powinien komunikować błędem; system powinien przydzielać odpowiednie zlecenia pracownikom

Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.

Wymagania niefunkcjonalne są to ograniczenia systemu, które obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd. Wynikają one z potrzeb użytkownika, budżetu, potrzeby współpracy z innym systemem, strategii firmy i czynników zewnętrznych. Wymagania niefunkcjonalne można podzielić na trzy podklasy: Produktowe (określają zachowanie produktu): system powinien być łatwy w użyciu dla doświadczonych kontrolerów. Organizacyjne (wynikają ze strategii w firmie wytwórczej i firmie klienta) proces tworzenia systemu i końcowe dokumenty powinny być zgodne z procesem i produktami zdefiniowanymi w standardzie XYZCo-SP-STAN-95. Zewnętrzne system nie powinien ujawniać operatorom żadnych danych osobowych klientów oprócz nazwisk i numerów identyfikacyjnych.

Omów metody specyfikacji wymagań dla systemów informatycznych.

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 tablic, kojarzących różne aspekty. 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.

Omów przykładowy zakres treści dokumentu opisującego wymagania na system informatyczny.

Dokument opisujący wymagania na system informatyczny ma pewien schemat:
Informacje organizacyjne: Streszczenie (około 200 słów), Spis treści, statut dokumentu(autorzy, firmy, podpisy), Zmiany w stosunku do poprzedniej wersji.

Zasadnicza zawartość dokumentu: 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 3.2 Wymagania niefunkcjonalne).

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.

Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.

Celem fazy analizy jest ustalenie wszystkich tych czynników, 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.
Zakres fazy analizy:

--Wykracza poza zakres odpowiedzialności systemu -> kontekst użycia i współpracy; --Ujęcie w modelu pewnych elementów nie będących częścią systemu -> model jest bardziej zrozumiały; --Abstrakcja modelowania -> podczas modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie a które w sposób sprzętowy lub ręcznie; --Dostępne środki mogą nie pozwolić na realizację systemu w całości -> analiza może wykryć fragmenty, które mogą być szczególnie ważne;

Omów czynności procesu testowania oprogramowania.

Testowanie komponentów <-> Testowanie modułów <-> testowanie podsystemów <-> testowanie systemów <-> testowanie odbiorcze;

testowanie komponentów: 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: Podsystemy zintegrowano już w system. Ten proces testowania ma wykryć błędy wynikające z nie przewidzianych interakcji między podsystemami i problemów z interfejsami podsystemów.

testowanie odbiorcze: Jest to końcowa faza procesu testowania przed przyjęciem systemu do użytkowania.

Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy systemu informatycznego.

Cechy modelu analitycznego: --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. 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. Analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów, jej celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu.

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;

Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.

Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów. Do tej klasy należą: Metodyka Yourdona (DeMarco i Ward/Mellor); Structured System Analysis and Design Methodology (SSADM); Structured Analysis and Design Technique (SADT).

Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli oraz iż pomimo dojrzałości, mogą nie być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych. Przykład metodyki - CDM-Oracle-1996: stosowana do procesów biznesowych i funkcji, które nie mogą być obsłużone za pomocą dostępnych aplikacji „z półki”; CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które zostały określone przy założeniu, że w procesie wytwórczym stosowane są metody i narzędzia CASE; zakłada, że potrzeby biznesowe zostają wyraźnie zdefiniowane na samym początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas całego procesu wytwórczego; CDM wyróżnia następujące procesy: definicja potrzeb biznesowych (studium możliwości), analiza istniejących systemów, opracowanie architektury technicznej, projektowanie i budowa bazy danych, projektowanie i budowa modułów, konwersja danych, opracowanie dokumentacji technicznej, testowanie, szkolenie, przejście na nowy system, obsługa serwisowa.

Omów źródła kosztów nieprawidłowości oprogramowania.

1. Koszty jakości: 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łądy); 3. Straty jakości (skutki odchyleń od wymagań jakościowych): testowanie: 30%-40% całkowitej pracochłonności; testowanie systemów krytycznych: 70%-80% całkowitej pracochłonności.

Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.

Analiza i Projektowanie - metody obiektowe Wspólna zasada: zaczynamy od rozpoznania struktury obiektów. Najważniejsze jest, czym są obiekty, a nie co robią. Wspólne kroki wszystkich metod obiektowych: Identyfikacja klas i obiektów, ich atrybutów i metod; Ustalenie powiązań między obiektami; Ustalenie interfejsu każdego obiektu (protokołu); Ustalenie współpracy obiektów, przepływ informacji; Implementacja, tworzenie prototypu.

Przykład- Metoda Coad/Yourdon 5 głównych czynności: 1. znajdowanie klas i obiektów 2. identyfikacja struktur 3. identyfikacja tematów 4. definiowania atrybutów 5. definiowania usług

model analizy obiektowej zawiera 5 warstw: 1. warstwa tematów 2. warstwa klas i obiektów 3. warstwa struktury 4. warstwa atrybutów 5. warstwa usług

Przykłąd Analiza metoda OMT (metoda Rumbaugh) OMT - Object Modelling Technique 3 części składowe modelu, pokazujące różne jego aspekty: Model Obiektów (OMT Object Model) statyczny obraz struktury modelu: klasy; atrybuty; operacje; relacje między klasami i instancjami (powiązania - asocjacje, całość - część (agregacje), gen- spec). Model Dynamiczny (OMT Dynamic Model) współdziałanie obiektów (powiązania wyznaczone przez komunikaty). Tu mieszczą się różne diagramy pokazujące przepływ sterowania, także ograniczenia i warunki na wartości atrybutów. Model Funkcyjny (OMT Functional Model) specyfikacja operacji jako funkcji przekształacących wejście na wyjście, warunki poprawności (asercje).

Ogólnie w temacie o analizie obiektowej: 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.

Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.

System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy od złożoności architektury. Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów;

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

System informatyczny - jest to zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu techniki komputerowej. Na systemy informatyczne składają się obecnie takie elementy jak: sprzęt - obecnie głównie komputery, oraz

urządzenia służące do przechowywania danych; urządzenia służące do komunikacji między sprzętowymi elementami systemu; urządzenia służące do komunikacji między ludźmi a komputerami; urządzenia służące do odbierania danych ze świata zewnętrznego - nie od ludzi (na przykład czujniki elektroniczne, kamery, skanery); urządzenia służące do wpływania systemów informatycznych na świat zewnętrzny - elementy wykonawcze (na przykład silniki sterowane komputerowo, roboty przemysłowe, podłączony do komputera ekspres do kawy, sterowniki urządzeń mechanicznych); urządzenia służące do przetwarzania danych nie będące komputerami; oprogramowanie; zasoby osobowe – ludzie; elementy organizacyjne - czyli procedury (procedury organizacyjne - termin z zarządzania) korzystania z systemu informatycznego, instrukcje robocze itp.; elementy informacyjne; bazy wiedzy - ontologie dziedziny/dziedzin, w których używany jest system informatyczny - na przykład podręcznik księgowania w wypadku systemu finansowo-księgowego

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 - (Object Diagram)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 - (Component Diagram) (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. Elementami tymi są: Komponenty przedstawiane za pomocą dużego prostokąta, z dwoma mniejszymi z jego lewej strony oraz z etykietą w środku. Komponenty mogą być przedstawiane zarówno jako klasy jak i instancje. Klasa oznacza elementy systemu istniejące podczas jego działania (np. interfejs użytkownika czy dane). Konkretne instancje precyzują o jaki element chodzi (np. okno programu będące częścią interfejsu). Węzły są to zasoby sprzętowe dostępne podczas działania systemu. Obrazowane są za pomocą prostopadłościanów.

Diagram pakietów – (Package Diagram)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 conajmniej 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.

Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.

Diagram przypadków użycia ( Use Case Diagram) Diagramy przypadków użycia opisują, 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. (State Machine Diagram) 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 zdarzeń (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) Diagramy współpracy 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 ( : ).

Omów podstawowe diagramy w metodyce Oracle CASE Method.

Diagram zależności to narzedzie do przedstawiania złożonych zależnosci miedzy przyczynami i skutkami. Diagramy zależnosci pozwalajż odnalećź często trudną do wykrycia zależnosc problemu od pierwotnej przyczyny. Pomagaja zilustrowac łancuchy zaleznosci i wzajemnych zaleznosci, przez co ułatwiaja podjecie działania w odpowiednim miejscu. Pomagaja równiez w identyfikacji efektów ubocznych tych działan. Diagram dokumentujący zależności między elementami danych nazywa się diagramem zależności lub diagramem determinowania. ● Elementy danych rysowane są w postaci owali, kółek lub baniek. ● Zależność funkcyjna oznaczana jest przy pomocy strzałek łączących element determinujący z zależnym. Diagram zależności przedstawia kolejność wykonywania wcześniej ustalonych funkcji elementarnych. Dotyczy zależności informacyjnych. Jest to tzw. diagram następstw, uwzględniający zdarzenia inicjujące wykonanie funkcji oraz ich wyniki. Przedstawia wszystkie możliwe drogi postępowania, zatem wymaga użycia operatorów relacji OR, AND i XOR.

Diagram przepływu danych - DFD (ang. Data Flow Diagram) . diagramy przepływu danych pozwalają na modelowanie procesów w systemie informatycznym lub organizacji. Podstawowe elementy diagramów DFD to: · proces (ang. process), · przepływ (ang. flow), · magazyn inaczej skład/składnica danych (ang. datastore), · terminator (ang. terminator) inaczej jednostka zewnętrzna (ang external entity). Każdy z powyższych elementów ma odpowiedni symbol graficzny jednoznacznie wyróżniajacy go na diagramie. Niestety, różne metodyki używają różnej symboliki . zwykle jednak koncepcja i semantyka diagramów jest jednakowa.

-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.

Omów główne klasy błędów w systemach informatycznych.

błędy wymagań i analizy: złe sformułowanie problemu, zaniedbanie istotnych parametrów, niewłaściwy algorytm; błędy projektowania: błędna interpretacja wymagań, błędy logiczne; błędy opracowania (danych) szczegółowej struktury programu: zła interpretacja wymagań dla programu, niepełność struktury programu, nie uwzględnienie przypadków szczególnych, niedostateczne dopracowanie błędów, zlekceważenie warunków czasowych; błędy kodowania: syntaktyczne, zazwyczaj rozpoznawane przez kompilator, błędy merytoryczne (nieprawidłowe korzystanie z indeksów i wskaźników, zły przydział pamięci, pominięcie inicjalizacji zmiennych, pomieszanie parametrów funkcji, błąd w pętlach, zamiana wyników decyzji w instrukcjach warunkowych, błędy deklaracji typów i wymiarów danych, błędy zakresów wartości danych; błędy kompilacji i konsolidacji: błędy kompilatora, błędy w zakresach nazw itp.

Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1) podejście: encja-związek, 2) podejście obiektowe.

W analize i projektowaniu systemów inf. rozróżniamy dwa podejścia – strukturalne i obiektowe. Podejście encja-związek jest strukturalne – diagramy encja-związek występuja w strukturalnej metodyce SSADM. Model taki opisuje statyczna strukturę systemu, grupując dane w kolekcje zwane obiektami (encje). Graficznym odpowiednikiem jest diagram ERD (ang. Entity Relationshi Diagram), którego węzły reprezentują obiekty natomiast łuki odzwierciedlają relacje pomiędzy obiektami. Przy podejściu bazodanowym, gdy występuje spora ilość danych, korzystne jest rozróżnianie rodzajów danych oraz prześledzenie ich przepływu. Obecnie najbardziej rozpowszechnione jest podejście obiektowe. Cechuje się ono przejrzystością oraz wygodą tworzenia modelów. Intuicyjnie dokonywane jest powiązywanie metod z danymi, na których one operują. Pomiędzy obiektami można w prostszy sposób zamodelować interakcję. 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.

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 projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie całego projektu Pod kątem procesu wytwórczego systemów informatycznych audytowi podlegają produkty (cząśtkowe) projektu informatycznego. Ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom.

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] Dla procesów wytwórczego może ona mieć "zbawienny" wpływ gdyż poprawia ona proces programowy. Czas wytworzenia systemu dzięki inspekcji skraca się, gdyż wcześniej dowiadujemy się o błedach. Zwiększa ona także motywację pracowników poprzez obudzenie w nich świadomości, że produkt będzie oceniany. Może mieć ona z kolei zgubny wpływ na etapie opracowywania dokumentów, gdyż pracownikowi "rodzi się" w głowie myśl: "inspekcja wskaże błędy". Po inspekcji, kontrolach indywidualnych i poprawie produktu następuje burza mózgów mająca na celu identyfikację przyczyn błędów (max 10 najpoważniejszych) i propozycji poprawy procesu programowego, by błędy te nie powtórzyły się w przyszłości. Idee są notowane bez ich głębokiej oceny.

Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego.

Strategia procesu testowania zależy w dużej mierze od przyjętego modelu cyklu życia oprogramowania, rodzaju oprogramowania, dojrzałości zespołu testerów, posiadanych narzędzi do testowania.

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 zmniejszyć dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi

Badania diagnostyczne: Typy: Analiza dynamiczna -eksperymentowanie z działającym kodem programu; Analiza statyczna - praca z kodem źródłowym w celu: (rozpoznania funkcjonalności testowanego kodu; zaprojektowania odpowiednich testów;) inspekcje ; audyty.

Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu informatycznego.

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.

Omów istotę testowania metodą black box i white box.

Testowanie strategią 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. Przykładowy graf strumieni podprogramu wyszukującego binarnie: Testowanie strategią czarnej skrzynki - 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.

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; Zadaniem testera jest taki wybór danych wejściowych, aby z dużym p-stwem były elementami zbioru „Wejście-b”; Dane wejściowe mogą być dzielone na klasy równoważności (dziedziny) o wspólnych cechach (np. liczby dodatnie); Zakłada się, że programy działają zwykle w porównywalny sposób dla wszystkich elementów jednej klasy; Przypadki testowe projektuje się tak, aby dane wejściowe i wyjściowe leżały wewnątrz tych klas;

Omów zagadnienie projektowania architektonicznego systemów informatycznych.

Proces projektowania architektonicznego polega na ustaleniu podstawowego zrębu systemu. Podział architektoniczny jest niezbędny do strukturalizacji i porządkowania specyfikacji. Model architektoniczny jest zwykle punktem początkowym do specyfikowania rozmaitych części systemu. Obejmuje identyfikację najważniejszych komponentów systemu i komunikacji między nimi. Wyróżnia się składowe procesy projektowania architektonicznego: Strukturalizacja systemu - System jest dzielony na kilka podstawowych podsystemów, przy czym podsystem jest niezależną jednostką oprogramowania; Identyfikuje się tu komunikację między podsystemami. Modelowanie sterowania - Określa się ogólny model związków sterowania między częściami systemu. Podział na moduły- Każdy zidentyfikowany podsystem jest dzielony na moduły; Architekt musi wskazywać typy modułów i ich połączenia.Wynikiem projektowania architektonicznego są dokumentacja zawierająca modele graficzne i opisy tekstowe oraz modele przedstawiające rozmaite perspektywy architektury.

Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania.

Badanie diagnostyczne: badanie gdy istnieje kod źródłowy; Składa się z:-Analiza dynamiczna: eksperymentowanie z działającym kodem programu; -Analiza statyczna: praca z kodem źródłowym w celu rozpoznania funkcjonalności testowanego kodu i zaprojektowania odpowiednich testów; -wykrywanie anomalii: defekt: nieprawidłowe działanie człowieka w procesie wytwarzania, np. złe sformułowanie wymagań, zła decyzja projektowa, pomyłka w implementacji; –Błąd: każde zdarzenie, w wyniku którego kod produkuje nieoczekiwany rezultat; –Awaria: stan, w którym program nie jest zdolny wykonać prawidłowo co najmniej jednej ze swoich funkcji;

Omów istotę koncepcji wzorców projektowych w projektowaniu systemów informatycznych.

Wzorzec projektowy jest to uniwersalne, sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych problemów projektowych. Wzorce projektowe zwiększają elastyczność, wielokrotne wykorzystanie oraz czytelność projektu, dostarczają sprawdzonych rozwiązań dla powtarzających się problemów, wpływają na sposób modelowania, usprawniają komunikację oraz tworzenie dokumentacji.Podział wzorców 1: Analityczne – ułatwiają modelowanie dziedziny. Projektowe – opisują pewne techniki projektowe. Architektury – standardowe rozwiązania architektury. Organizacyjne – opisują organizację pracy zespołu. Podział wzorców 2:Konstrukcyjne - wykorzystywane do pozyskiwania obiektów zamiast ich bezpośredniego tworzenia. Strukturalne - stosowane do łączenia obiektów w większe struktury. Operacyjne - definiowanie komunikacji pomiędzy obiektami; kontrolowanie przypływu danych w złożonych algorytmach (programach); przydział zobowiązań obiektom. Podział wzorców 3: Warstwy prezentacji; Warstwy logiki; Warstwy integracji.

Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania.

Badanie prognostyczne: badanie

gdy nie ma jeszcze kodu. Zanim powstanie implementacja oprogramowania, jego przyszłe działanie jest badane na podstawie założeń analitycznych/ projektowych.

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 zmniejszyć dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi).

Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady.

Testowanie: sprawdzanie, czy system działa tak, jak założono w specyfikacji. Przykłady: Testowanie komponentów: 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;

Weryfikacja: testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań. 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ą.

Przykłady: -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 -Audyt.

Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości.

Drugi poziom to: ADEKWATNOŚĆ

: -Kompletność

-Racjonalność funkcjonalna

-Racjonalność komunikacyjna

-Zwartość funkcjonalna

-Zwartość komunikacyjna

Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca konstrukcyjnego.

- służą do pozyskiwania obiektów; - szczegółowo opisują jaki obiekt może zostać stworzony; - uniezależniają kod od typów tworzonych obiektów (zależne jest to tylko od parametrów konfiguracyjnych);

Przykłady: -Singelton -Zapewnia powołanie tylko jednej instancji obiektu w całej aplikacji i kontrolowany dostęp; -Obiekt powołany wg tego wzorca jest globalnym punktem dostępu do instancji danej klasy ; -Wzorzec może być zmodyfikowany do tworzenia określonej liczby instancji danej klasy (>1); -Funkcje wzorca: utworzenie obiektu, inicjalizacja obiektu, punkt dostępu, modyfikacja obiektu; -Prostszym rozwiązaniem jest: globalnie dostępna zmienna statyczną przechowująca referencję do obiektu; -metoda fabrykująca; Fabryka nie może przewidzieć, jakie obiekty i w jaki sposób tworzyć; Klient zna tylko interfejs klasy abstrakcyjnej; Informacje o sposobie i odpowiedzialność za tworzenie obiektu znajdują się w implementacjach „metody tworzącej” klas pochodnych; Można tworzyć domyślny produkt, ale też dać użytkownikowi możliwość podstawienia swojej wyspecjalizowanej wersji; -fabryka abstrakcyjna; -fabryka; -Fabryka nowych obiektów w zdefiniowanych klasach wzorcowych; Wszystkie klasy wzorcowe mają metody o tej samej nazwie, ale o innych realizacjach; Zaleta – możliwość modyfikowania klas wzorcowych (tworzących) w jednym miejscu projektu; Popularne wersje Fabryki: Metoda Fabrykująca, Fabryka Abstrakcji, Budowniczy, Prototyp; -budowniczy; -prototyp.

Podsumowanie: Singleton – pojedyncza instancja obiektu; Metoda Fabrykująca – tworzenie obiektów w klasach pochodnych; Fabryka Abstrakcyjna – tworzenie rodzin obiektów bez wydzielonych klas fabryk; Budowniczy – ukrycie szczegółów tworzenia za interfejsem zarządcy; Prototyp – tworzenie kopii na podstawie w pełni zainicjalizowanej instancji;

Co to jest przypadek testowy, scenariusz testów? Podaj przykłady.

Przypadek testowy (ang. test case) - specyfikacja: -stan początkowy, czyli stan testowanego systemu (lub jego fragmentu) przed testem, -dane wejściowe, -warunki testu, -dane wyjściowe (oczekiwane wyniki);-Jakość przypadku testowego : prawdopodobieństwo znalezienia jeszcze nie wykrytego błędu; Test zakończony powodzeniem: WYKRYWA dotychczas nie wykryty błąd; [G. Myers, The Art. Of Software Testing, 1979] Określone w rozporządzeniu ministra nauki i informatyzacji z 19 października 2005: przypadek testowy — test akceptacyjny obejmujący pojedynczy zestaw danych wejściowych wprowadzanych do oprogramowania testowanego; scenariusz testowy — zestaw co najmniej dwóch przypadków testowych powiązanych ze sobą w taki sposób, że danymi wejściowymi do każdego kolejnego przypadku testowego są niezmienione dane wyjściowe z poprzedzającego go przypadku testowego;

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; wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu przed ukończeniem budowy komponentów wyższego poziomu; -Testowanie interfejsu jest wykonywane po zintegrowaniu modułów lub podsystemów w większe systemy. -Każdy moduł i podsystem ma zdefiniowany interfejs, który jest wywoływany przez inne komponenty programu, np.: Interfejsy parametryczne, Interfejs w pamięci dzielonej, Interfejsy proceduralne, Interfejsy z przekazywaniem komunikatów; -Celem testowania interfejsu jest wykrycie usterek, które pojawiły się w systemie z powodu błędów w interfejsach lub nieprawdziwych założeniach o interfejsach.

Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca strukturalnego.

Stosowany do łączenia obiektów w większe struktury; Zastosowanie np. w implementacji złożonego interfejsu użytkownika; Przykłady: (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; Przykłady: (w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet); wejście usług w Service Oriented Architecture (SOA);) Adapter, (Konwertuje (dopasowuje) interfejsy jednej klasy do interfejsu innej klasy; Umożliwia klasom o różnych interfejsach współpracę w jednym programie; Niewielka elastyczność – adaptacji podlega tylko jedna klasa (Adaptee), bez jej podklas; Zmiana zachowania klasy Adapter może zmienić zachowanie klasy dostosowywanej Adaptee; Dwa sposoby realizacji: (dziedziczenie, kompozycja;) )Most, Kompozyt, (System złożony z podsystemów o strukturze drzewiastej ( reprezentacja związku „całość-część”); Wspólny interfejs dla klas węzłów i liści – ujednolicone widzenie kontenerów i obiektów składowanych; Łatwo rozszerzalny o nowe podsystemy implementujące (określony interfejs); Przykłady: (Przykład w bibliotekach Javy: kontenery (Panel, JComponent, …);)) Dekorator, Waga Piórkowa, (Zastąpienie wielu obiektów jednym współdzielonym z opisem stanu zubożonym w porównaniu z pierwotnym obiektem; Zamiast przechowywać wewnątrz atrybuty stanu, obiekty dostają wartości z zewnątrz jako parametry wywołania metod; Zalety: (Ograniczenie liczby tworzonych instancji obiektów; Przesunięcie części danych z obiektu do przekazywanych parametrów metod;) Wady: (Zwiększony koszt wywoływania metod obiektów; Uzyskuje się przyspieszenie programów operujących na wielu niezbyt złożonych obiektach; ) Przykład: zbiory obiektów „znaków literowych”; ) )Proxy;

Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca czynnościowego.

W celu definiowania komunikacji pomiędzy obiektami; Pomagają kontrolować przepływ danych w złożonym programie;

Przykłady: 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; Przykład: (W bibliotekach Javy: iterator w kolekcjach z pakietu java.util; ) ) Łańcuch Odpowiedzialności, ( Zestaw klas obsługuje żądanie w określonej kolejności; Żądanie jest przekazywane pomiędzy klasami w określonym łańcuchu; Czasami ostatni obiekt łańcucha obsługuje wszystkie żądania; Przykład: (Realizacja w Javie: Frame -> Panel -> Component; ) ) Stan, ( Tworzy obiekty pochodne z bazowej klasy State dla każdego stanu, w którym może znaleźć się aplikacja; Przełączanie pomiędzy obiektami stanu, gdy zmieni się stan aplikacji; Wraz ze zmianą stanu i tym samym obiektu może zmienić się zachowanie obiektu (inne implementacje metod); Eliminuje złożone instrukcje warunkowe (np. switch) w metodach obiektu; Wada: powstaje wiele małych klas; Zaleta: upraszcza program; ) Mediator, (Mediatora stanowi „zarządcę obiektów”; Wprowadza luźniejsze powiązania pomiędzy klasami – obiekty znają Mediatora a nie koniecznie inne obiekty; Zmiany stanu obiektów są za jego pośrednictwem (odpowiednich metod) propagowane do zainteresowanych obiektów; Często jest specjalizowany dla jednego projektu; ) Obserwator, Strategia; (Potrzeba kilku wariantów algorytmu; Wybór określonego wariantu poprzez powołanie obiektu pochodnego do zdefiniowanego interfejsu bazowego lub klasy abstrakcyjnej; Każda wersja algorytmu jest implementowana w osobnej klasie; Zalety: (algorytm może używać danych, których klient nie zna; hermetyzacja algorytmów w oddzielnych klasach pozwala na ich modyfikację niezależnie od kontekstu; to rozwiązanie zastępuje instrukcje wyboru lub warunkowe; ) )

Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.

Macierz przykrycia testów akceptacyjnych jest to macierz opisująca wszystkie funkcjonalności oprogramowania oraz powiązane z nimi przypadki testowe. Pozwala na wykrycie nietestowanych funkcjonalności oraz nadmiarowych testów (nie testujących żadnej funkcjonalności).

1. Omów różne określenia pojęcia interoperacyjność systemów informatycznych.

2. Podaj i omów warunki interoperacyjności systemów informacyjnych.

3. Podaj i omów warunki interoperacyjności systemów informatycznych.

4. Porównaj modele warstwowe interoperacyjności według OpenGroup i według Europejskich Ram Interoperacyjności w wersji 2.0.

5. Wymień i krótko omów podstawowe regulacje prawne interoperacyjności w Polsce.

6. Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki kosztów.