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

2 Omów zagadnienie języka programowania i 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

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

Dziedzina problemowa,

obejmująca 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: podlegający 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ść.

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

5-9. Omów następujący model cyklu życia oprogramowania: … nazwa modelu

1. Model kaskadowy:

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.

2. Model spiralny, przyrostowy

Model spiralny składa się z czterech głównych faz wykonywanych cyklicznie:

- planowania

- analiza ryzyka

- konstrukcji

- atestowania

W fazie planowania ustalane są generalne cele produkcji kolejnej wersji systemu.

W fazie analizy 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ą.

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.

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.

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

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

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

Główne klasy wymagań to Funkcjonalne, Niefunkcjonalne i Dziedzinowe

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

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

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

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

15 Omów zakres i istotę etapu projektowania w cyklu wytwórczym SI

Celem projektowania jest opracowanie szczegółowego opisu implementacji systemu.

W odróżnieniu od analizy, w projektowaniu dużą rolę odgrywa środowisko implementacji.

Dwa etapy fazy projektowania:

• projekt strategiczny, projekt systemu (strategic, system design):

  • podział na podsystemy,

  • współbieżność,

  • przechowywanie danych,

  • sterowanie.

• projekt szczegółowy (detailed design):

  • uściślanie definicji klas,

  • dziedziczenie,

  • optymalizacja modelu,

  • modularyzacja,

  • ukrywanie informacji;

+ to samo co w obiektowym na koncu

16 Omów zakres i istotę etapu implementacji w cyklu wytwórczym systemów informatycznych

…

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

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

# 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;

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

20.Porównaj następujące podejścia do analizy i projektowania systemów informatycznych:

1) podejście: encja-związek, 2) podejście obiektowe(zamiast tego asocjacji klas ale można to chyba wyprowadzić z PO).

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

encje. Graficznym odpowiednikiem jest diagram ERD (ang. Entity Relationshi

Diagram), którego węzły reprezentują encje natomiast łuki odzwierciedlają relacje

pomiędzy encjami. 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.

21. 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ąstkowe) projektu informatycznego. Ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom.

22.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łędach.

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.

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

Testy jednostkowe (komponentów):

-Testują oprogramowanie na najniższym poziomie, czyli na poziomie małych modułów, klas, metod;

-Mogą być zrobione w oddzieleniu od reszty systemu;

-Wymagają dostępu do kodu źródłowego i wsparcia narzędziowego (np. debugger’ów);

-Wykorzystują zaślepki (ang. „stub”), symulatory,…;

-Mogą obejmować testowanie:

• funkcjonalności,

• niefunkcjonalnych charakterystyk, takich jak zasoby (np. wycieki pamięci),

• odporności na atak,

• testowanie strukturalne (np. pokrycie gałęzi);

Testy integracyjne:

-Sprawdzają interfejsy pomiędzy komponentami i współpracę różnych części systemu, np. systemu operacyjnego, systemu plików, oprzyrządowania;

-Strategie integracji bazują na:

• architekturze systemu (np. z góry na dół, z dołu do góry),

• funkcjonalności,

• sekwencjach wymiany danych;

-Integracja powinna raczej być wykonywana stopniowo, a nie metodą wszystko na raz (tzw. „big bang”);

Testy systemowe:

-Dotyczą sprawdzenie zachowania całości systemu w porównaniu z założeniami wstępnymi projektu;

-Środowisko testowe powinno być zbliżone do docelowego, w jakim system będzie pracował;

-Wykonywane są zazwyczaj przez niezależny zespół testowy;

-Testy obejmują wymagania funkcjonalne i różnego rodzaju wymagania niefunkcjonalne (szybkość, bezpieczeństwo, niezawodność, …);

Testy akceptacyjne:

-Pozwalają sprawdzić, na ile oprogramowanie działa zgodnie z wymaganiami klienta;

-Leżą w gestii klienta lub użytkownika systemu oraz również współudziałowcy;

-Szukanie defektów nie jest głównym celem tego testowania;

-Dzielą się na testy:

• użytkownika - weryfikuje dopasowanie systemu do potrzeb użytkowników;

• operacyjne - akceptacja systemu przez administratorów systemu zawierające: sprawdzenie kopii zapasowej i zdolności do przywrócenia funkcjonalności po wystąpieniu problemów, zarządzanie użytkownikami, zadania serwisowe, cykliczne sprawdzenie bezpieczeństwa;

• kontraktowe i regulacyjne - testowanie kryteriów wytworzenia oprogramowania specyfikowanego dla klienta (np. są wykonywane w zgodzie z rządowymi lub legislacyjnymi uregulowaniami);

• alfa / beta – dla systemów: na zamówienie / „z półki”;

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

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;

25 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;

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

26-34 wzorce projektowe

*Fasada — jeden z wzorców projektowych należący do grupy wzorców strukturalnych. Służy do ujednolicenia dostępu do złożonego systemu poprzez wystawienie uproszczonego, uporządkowanego interfejsu programistycznego, który ułatwia jego użycie.

Wzorzec wyróżnia następujące elementy:

• złożony system — Chcemy uprościć dostęp do niego(np. kilka różnych warstw systemu),

• fasada — klasa posiadająca referencje do elementów systemu z metodami do wykonywania najczęściej potrzebnych zadań(jeden obiekt łączący najpotrzebniejsze elementy systemu),

• klient — dowolny kod zainteresowany wykorzystaniem złożonego systemu.

Klient komunikuje się z systemem poprzez fasadę, która w jego imieniu wykonuje niezbędne operacje na złożonym systemie. To, czy klient posiada także bezpośredni dostęp do systemu, leży w gestii programisty implementującego wzorzec, ponieważ możliwe jest wykorzystanie go do podziału systemu na warstwy, gdzie fasady służą do uproszczenia i ujednolicenia komunikacji.

*Singleton jest to jeden z kreacyjnych wzorców projektowych (obiektowy), którego celem jest ograniczenie możliwości tworzenia obiektów danej klasy do jednej instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu. Niekiedy wzorzec uogólnia się do przypadku wprowadzenia pewnej maksymalnej liczby obiektów, jakie mogą istnieć w systemie. Niektórzy programiści uznają go za antywzorzec, ponieważ łamie zasady projektowania obiektowego, często bywa nadużywany lub sprowadza się do stworzenia obiektowego zamiennika dla zmiennej globalnej.

Singleton implementuje się przez stworzenie klasy, która posiada statyczną metodę, która najpierw sprawdza, czy istnieje już instancja tej klasy, w razie potrzeby tworząc ją. Następnie instancja zwracana jest przez referencję. Instancję przechowuje się w prywatnym lub chronionym, statycznym polu, do którego dostęp ma tylko opisana wyżej metoda, która jest jedyną drogą pozyskania instancji obiektu singletonu – aby uniemożliwić tworzenie dodatkowych instancji, konstruktor klasy deklaruje się jako prywatny lub chroniony.

*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;

• Metoda Fabrykująca (factory method)

  • 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;

• Fabryka Abstrakcji (abstract factory)

  • Tworzenie rodzin powiązanych ze sobą obiektów bez konieczności posługiwania się ich konkretnymi klasami;

  • Wprowadzenie wielu metod zwracających obiekty, spełniające określone interfejsy;

  • Klient nie musi znać szczegółów budowania rodzin obiektów;

• Prototyp (prototype)

  • tworzenie obiektów przez klonowanie prototypu;

  • obiekty klonowane muszą umożliwiać zmianę swoich właściwości;

  • stosowane, gdy tworzenie obiektów zabiera dużą ilość czasu, np. obiekt utworzono na podstawie odpowiedzi z zapytania do bazy danych;

*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;

*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

• Podstawowe zachowanie klasy musi być czasami rozszerzone o dodatkowe operacje lub cechy

• Funkcjonalność uzupełniająca umieszczana jest w osobnych klasach Decorator;

• Stosowany zamiast dziedziczenia, które mogłoby stworzyć zbyt wiele mało elastycznych klas;

• Dekorator agreguje w sobie dekorowane obiekty i dziedziczy z tej samej nadklasy, co te obiekty;

• Dynamiczna zmiana klasy nadrzędnej;

  • Utworzenie klasy poprzez dodanie nowego zachowania;

  • Przekazanie klasy rozszerzonej do konstruktora Dekoratora;

• Przykład:

  • w bibliotekach Javy: klasy strumieni (BufferedInputStream, …);

*Proxy(pośrednk)

• Punkt kontroli dostępu do rzeczywistego obiektu -ogranicza (ukrywa) dostęp do obiektu (podobnie jak Dekorator);

• Odsunięcie w czasie tworzenia rzeczywistego obiektu;

• Działania wykonywane są na Pośredniku, który działa na właściwej klasie o tym samym interfejsie;

• Stosowany, gdy obiekt docelowy jest złożony i np. potrzebuje wiele czasu na wczytanie (patrz sieć);

• Przykład:

  • W bibliotekach Javy: ziarna "enterprise" (Enterprise JavaBeans) i komunikacja z bazą danych;

*ł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;

35 Podaj określenie pojęcia interoperacyjność systemów informatycznych. Porównaj je z pojęciem integracja systemów informatycznych.

Interoperacyjność oznacza zdolność dwóch lub większej liczby systemów informatycznych lub ich komponentów do wymiany informacji i do jej użycia.

Interoperacyjność oznacza zdolność różnych elementów funkcjonalnych systemów informatycznych do komunikacji, uruchamiania programów lub przesyłania danych pomiędzy nimi w sposób nie wymagający od ich od użytkownika żadnej wiedzy lub wymagający od niego wiedzy minimalnej na temat unikalnych właściwości tych elementów.

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

Interoperacyjność organizacyjna dotyczy definicji celów biznesowych, modelowania procesów biznesowych i umożliwienia wymiany informacji pomiędzy administracjami o różnych wewnętrznych strukturach i procesach. Wymiar organizacyjny interoperacyjności jest ponadto zaadresowany do wymagań społeczności użytkowników końcowych, co wyraża się w realizowaniu dostępnych i osiągalnych serwisów, łatwo rozpoznawalnych i zorientowanych na użytkownika.

Interoperacyjność semantyczna dotyczy zapewnienia precyzyjnego rozumienia znaczenia wymienianej informacji za pomocą różnorodnego oprogramowania, które nie było specjalnie w tym celu zaprojektowane. Umożliwia to włączenie różnych systemów do pełnego przetwarzania informacji uzyskiwanej z wielu różnych źródeł. Zapewnienie interoperacyjności semantycznej jest warunkiem wstępnym dla właściwej obsługi użytkownika końcowego oprogramowania w aspekcie różnorodności językowej krajów Unii Europejskiej

Interoperacyjności techniczna dotyczy technicznych zagadnień związanych z uzyskiwaniem połączeń pomiędzy systemami komputerowymi i serwisami. Obejmuje ona kluczowe aspekty otwartości interfejsów systemów, interkonnekcyjności serwisów, integracji danych i warstwy middleware oprogramowania, prezentacji i wymiany danych, dostępności i bezpieczeństwa serwisów.

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

<-OpenGroup

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

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

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

42 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;

43 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;

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;

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

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