1.Omów przedmiot i zakres inżynierii oprogramowania.
Inżynieria oprogramowania to dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej.
W inżynierii oprogramowania proces produkcji oprogramowania dzieli się na pewne fazy, typowy podział to:
1. specyfikacja - na tym etapie następuje określenie i ustalenie wymagań, które musi spełniać oprogramowanie
2. projektowanie - ustalenie ogólnej architektury systemu, wymagań dla poszczególnych jego składowych
3. implementacja - realizacja ustalonej architektury poprzez implementację składowych (modułów) i połączeń między nimi.
4. integracja - zintegrowanie poszczególnych składowych w jeden system, testowanie całego systemu
5. ewolucja - uruchomienie systemu, usuwanie wykrytych podczas jego używania błędów, rozszerzanie systemu
2.Omów zagadnienie języka programowania i semiotyki języka programowania.
Semiotyka - jeden z trzech głównych (obok logiki formalnej i metodologii nauk) działów logiki, sam dzielący się na semantykę, pragmatykę i syntaktykę. Podział semiotyki na trzy główne działy pochodzi od Charlesa W. Morrisa. Semiotyka logiczna stanowi ogólną teorię znaków, zwłaszcza znaków językowych - wyrażeń.
Semantyka bada relacje semantyczne, tj. związki między znakami, a rzeczywistością, tym, do czego odnoszą się znaki. Syntaktyka bada relacje syntaktyczne, tj. relacje zachodzące między samymi znakami. Nie są to jednak wszystkie relacje zachodzące wewnątrz języka, ale jedynie te, które mają charakter formalny - a więc niezależne od
znaczenia wyrażeń, między którymi zachodzą. Pragmatyka, która bada relacje pragmatyczne, zachodzące między znakiem a jego użytkownikami (nadawcami i odbiorcami), ma częściowo nieuregulowany status - istnieje wiele prób uczynienia z niej nauki formalnej na wzór semantyki i syntaktyki, może ona jednak być uprawiana również jako nauka empiryczna mówiąca o ludzkim zachowaniu i łącząca w sobie elementy psychologii, socjologii i wiedzy o kulturze.
3.Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.
Kryzys oprogramowania (ang. software crisis) — zjawisko dostrzeżone już w latach 60. Polega na powiększającej się rozbieżności między mocą obliczeniową sprzętu komputerowego a efektywnością produkcji oprogramowania. Wysiłki informatyków zmierzają do optymalizacji procesu wytwarzania oprogramowania poprzez stosowanie odpowiednich metod i technik szczegółowych w tym zakresie.
4.Omów przykładowe źródła złożoności projektu informatycznego.
Najczęstsze ryzyko związane z realizacją projektów IT wynika z braku kompetencji samych użytkowników, opóźnień w prowadzeniu przedsięwzięcia oraz źle zaplanowanego i przekroczonego budżetu. Istnieje również grupa ryzyk wiążących się z nagłą zmianą priorytetów, reorganizacją struktur i zasobów oraz rotacją ludzi w zespołach.
W przypadku zarządzania ryzykiem szefowie IT stawiali przede wszystkim na własne siły. Jedynie nieliczni decydowali się na wybór zewnętrznego doradcy.Kolejna przeszkoda wynika z długiego procesu decyzyjnego oraz oporu kierownictwa wyższego szczebla.
5.Omów sposoby opanowywania złożoności projektu informatycznego.
Aby walczyc ze zjawiskiem zlozonosci projektu, stosuje sie:
ZASADE DEKOMPOZYCJI
Czyli rozdzielenie złożonego problemu na podproblemy,
ZASADE ABSTRAKCJI
Czyli eliminacja,mniej istotnych szczegółów rozważanego przedmiotuwyodrębnianie cech wspólnych pewnego zbioru bytów i wprowadzaniu pojęć oznaczających te cechy.
ZASADE PONOWNEGO UZYCIA
Czyli wykorzystanie wcześniej wytworzonych schematów, metod,
ZASADE SPRZYJANIA NATURALNYM LUDZKIM WLASNOSCIOM
Czyli dopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich zdolnosci
6.Omów zagadnienie modelowania pojęciowego w projekcie informatycznym.
Pojęcia modelu pojęciowego odnosi się do procesów myślowych i wyobrażeń towarzyszących pracy nad oprogramowaniem. Jest wspomagane przez środki wzmacniające wyobraźnię. Służą one do przedstawienia rzeczywistości opisywanej przez dane, procesów zachodzących w rzeczywistości
7. Co to jest metodyka prowadzenia projektu 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.
8. Omów następujący model cyklu życia oprogramowania: … nazwa modelu
Model kaskadowy: zawiera ciag czynnosci wykonywanych sekwencyjnie przy tworzeniu oprogramowania:
-okreslenie wymagan
-analiza
-projektowanie
-implementacja
-testowanie
-konserwacja
wady: Narzucenie twórcom oprogramowania ścisłej kolejności wykonywania prac
Wysoki koszt błędów popełnionych we wczesnych fazach
Długa przerwa w kontaktach z klientem
Wytwarzanie ewolucyjne
polega na:
opracowaniu wstępnej implementacji,
pokazaniu jej użytkownikowi z prośbą o komentarze
oraz udoskonalaniu jej w wielu wersjach aż do powstania odpowiedniego systemu;
wyroznia sie tworzenie badawcze (praca z klientem) oraz prototypowanie (praca z elementami systemu budzacymi watpliwosci)
prototypowanie:
Sposób na uniknięcie zbyt wysokich kosztów błędów popełnionych w fazie określania wymagań. Zalecany w przypadku, gdy określenie początkowych wymagań jest stosunkowo łatwe.
fazy:
-ogólne określenie wymagań
-budowa prototypu
-weryfikacja prototypu przez klienta
-pełne określenie wymagań
-realizacja pełnego systemu zgodnie z modelem kaskadowym
model V
polega na wytwrzaniu rownlolegle oprogramowania i prowadzeniu testow akceptacji, poszczegolne elementy systemu sa badane od razu po wytworzeniu, praca polega na podziale systemu na podsystemy, a te na poszczegolne zadania, co robi jeden z zespolow, a drugi zespol odpowiada wylacznie za ocene i testowanie systemu. testy odbywaja sie od zadan, potem przechodza do testowania podsystemow, a nastepnie testowany jest pelny system.
model spiralny
opiera sie na ewolucyjym projekcie, ktory jest poczatkowo planowany, nastepnie nastepuje analiza ryzyka systemu, konstrukcja (czesto odbywa sie zgodnie z modelem kaskadowym) a potem klient testuje system, informuje, co wymaga zmian i poprawek, i zgodnie z nimi caly cykl rozpoczyna sie od poczatku, w kolejnym obrocie petli do istniejacego systemu wprowadzane sa poprawki dopoki klient nie zaakceptuje systemu.
9 Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym oprogramowania.
Podstawowe zadania kierownictwa przedsięwzięcia informatycznego:
- Opracowanie propozycji dotyczących sposobu prowadzenia przedsięwzięcia
- Kosztorysowanie przedsięwzięcia
- Planowanie i harmonogramowanie przedsięwzięcia
- Monitorowanie i kontrolowanie realizacji przedsięwzięcia
- Dobór i ocena personelu
- Opracowanie i prezentowanie sprawozdań dla kierownictwa wyższego szczebla
10 Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości twórców oprogramowania
Czynniki te wynikają z faktu, że oprogramowanie jest używane i tworzone przez ludzi.
Użytkowanie - implikuje zasady tworzenia interfejsu użytkownika i dokumentacji użytkowej,
Tworzenie - zagadnienia psychologiczne odgrywające rolę w tworzeniu oprogramowania.
Elementy ludzkiej inteligencji:
Umiejętność całościowego (syntetycznego) spojrzenia na problem.
Posługiwanie się wiedzą płynącą z doświadczenia, a więc stosowania nieścisłych zasad wnioskowania na bazie wcześniejszych doświadczeń.
Istnieją ogromne różnice w predyspozycjach osób dotyczące ich efektywności w produkcji oprogramowania.
Testy osobowości:
metody określenia, czy dana osoba posiada cechy przydatne na danym stanowisku.
Stosowanie testów osobowości wiąże się z następującymi trudnościami:
Osobowość ludzka ma charakter dynamiczny (zmienia się). Wieloletnia praktyka zawodowa nie pozostaje bez wpływu na osobowość.
Różne zadania mogą wymagać różnych cech osobowości. Inne powinien posiadać analityk (kontakt z klientem), inne zaś programista lub osoba testująca oprogramowanie. Ponadto, metody inżynierii oprogramowania ulegają zmianie, co pociąga za sobą inny stosunek pożądanych cech osobowości do aktualnych zadań.
Osoby poddane testom będą starały się raczej odgadnąć pożądaną przez testujących odpowiedź niż odpowiadać zgodnie ze stanem faktycznym. Test nie będzie więc odzwierciedlał cech osobowości osoby, lecz raczej to, jak ta osoba wyobraża sobie cele i kryteria testowania oraz cechy pożądane przez pracodawcę
11 Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę w cyklu wytwórczym oprogramowania.
Umiejętność pracy w stresie. W pracy często zdarzają się okresy wymagające szybkiego wykonania złożonych zadań. Dla większości osób niewielki stres działa mobilizująco. Po przekroczeniu jednak pewnego progu następuje spadek możliwości danej osoby. Próg ten jest różny dla różnych osób.
Zdolności adaptacyjne. Informatyka jest jedną z najszybciej zmieniających się dziedzin. Ocenia się, że 7-9 miesięcy przynosi w informatyce zmiany, które w innych dziedzinach zajmują 5-7 lat. Oznacza to konieczność stałego kształcenia dla wszystkich inżynierów oprogramowania - stałe poznawanie nowych narzędzi, sprzętu, oprogramowania, technologii, metod, sposobów pracy. Niestety, nie wszyscy to tempo wytrzymują.
Uśpienie, zajmowanie się jednym problemem w jednym środowisku przez lata jest w informatyce bardzo groźne!
Wyróżnia się następujące typy psychologiczne:
1. Zorientowani na zadania (task-oriented). Osoby samowystarczalne, zdolne, zamknięte, agresywne, lubiące współzawodnictwo, niezależne.
2. Zorientowani na siebie (self-oriented). Osoby niezgodne, dogmatyczne, agresywne, zamknięte, lubiące współzawodnictwo, zazdrosne.
3. Zorientowani na interakcję (interaction-oriented). Osoby nieagresywne, o niewielkiej potrzebie autonomii i indywidualnych osiągnięć, pomocne, przyjazne.
Osoby typu 1 są efektywne, o ile pracują w pojedynkę. Zespół złożony z takich osób może być jednak nieefektywny. Lepsze wyniki dają zespoły złożone z typów 3. Typ 1 i 2 może być także efektywny w zespole, o ile jest odpowiednio motywowany przez kierownictwo. Typy 3 są konieczne w fazie wstępnej wymagającej intensywnej interakcji z klientem.
12 Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2
Projekt, to sposób prowadzenia przedsięwzięć gospodarczych zmierzający do wytworzenia produktu uzasadnionego biznesowo, w ramach określonego czasu, budżetu, z odpowiednią strukturą organizacyjną , rolami i zakresami odpowiedzialności.
Wymiary zarządzania: produkt, Koszt Hormonogram Jakość.
Poszczególne wymiary zarządzania projektem mają na siebie istotny wpływ. Powinny być one analizowane przez kierownika projektu łącznie (również ocena ryzyka)
Przez produkty projektu rozumie się wszystkie jego elementy, które mogą powstać w wyniku jego realizacji
Często spotykaną formą prezentacji harmonogramu są na przykład tabele lub arkusze kalkulacyjne, jak również wykresy Gantta
Budżet projektu stanowi zestawienie kosztów realizacji projektu.
Wymiar jakości dotyczy:
- oceny zarówno poszczególnych produktów projektowych:
- dokumentacji,
- oprogramowania,
- platformy techniczno-systemowej itp.
13. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń Prince2.
Sponsor Projektu-członek zarządu klienta lub jego bezpośredni przedstawiciel,odpowiedzialny za finansowanie całego przedsięwzięcia mają prawo do wglądu w projekt i podejamowania decyzji na temat jego dalszego rozwoju
Rada Projektu- zawiera w swoim ciele reprezentację wszystkich uczestników projektu, takich jak: Sponsor, użytkownicy, dostawcy,mianowanie Szefów Projektu,okresowa i etapowa ocena stanu projektu i zatwierdzanie planów dalszych prac,rozstrzyganie sporów występujących na szczeblu Szefów Projektu,zatwierdzanie Wniosków o Zmianę w zakresie funkcjonalnym i niefunkcjonalnym projektu,zatwierdzanie akceptacji kolejnych produktów projektu
Szefowie projektu-prowadzą i gromadzą dokumentację
projektu,zapewniają warunki pracy zespołów realizacyjnych,realizują
zatwierdzone zmiany,w zależności od potrzeb zajmują eskalacją odpowiednich problemów
Szef Jakości jest współpracuje z Szefami Projektu i sprawdza jakość całego projektu poniewarz podlegają plany i dokumentacja projektu wraz z produkatami i ich testami.
Komitet Kontroli Zmian składa się z przedstawicieli zarówno dostawcy jak i klienta. Jego skład wyznacza Rada Projektu Komitet Akceptacyjny składa się przeważnie z przedstawicieli obu stron, często jednak spotyka się w nim wyłącznie przedstawicieli klienta (przyjęcie lub odrzucenie produktu)
Sekretariat/administracja biura projektu- prowadzi archiwum projektu (zawiera się w nim biblioteka projektu, zbiory raportów oraz zajmuje się rozliczeniami finansowymi)
Zespoły Realizacyjne- (odwalaja cały ten syf) relaizują projekt, szefami sa przeważnie osoby doświadczone w zakresie tematu projektu
14. Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według metodyki PMI.
Zakres-projekt zawiera tylko to co potrzeba (inicjowanie faz
projektu
planowanie zakresu
definiowanie zakresu
weryfikacja zakresu
kontrola zmian zakresu )
Koszt-obejmuje procesy wymagane do zapewnienia, że projekt zostanie
ukończony w ramach zaakceptowanego budżetu
Czas-projektu obejmuje procesy wymagane do zapewnienia
przestrzegania przez zespół projektowy ustalonych granic czasowych
dla poszczególnych czynności w projekcie
Jakość-obejmuje procesy wymagane do zapewnienia zaspokojenia przez
rezultaty projektu tych potrzeb, dla których został on powołany
Komunikacja-obejmuje procesy służące zapewnieniu terminowego i właściwego tworzenia, gromadzenia, rozpowszechniania, przechowywania i usuwania informacji niezbędnej do efektywnego zarządzania
projektem
Integracja-obejmuje procesy wymagane do zapewnienia poprawnej koordynacji wszystkich elementów projektu
Ryzyko-obejmuje procesy identyfikacji, analizowania i reakcji na zaistnienie czynników ryzyka w projekcie
Ludzie-obejmuje procesy ułatwiające efektywne wykorzystanie ludzi w projekcie
Zaopatrywanie-obejmuje zdobywanie dóbr i usług spoza organizacji wykonującej projekt
15. Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń metodyki Chestra SBS.
Silna pozycja Kierownika Projektu (Szefa Projektu),
zakres projektu i zakres produktu jest określany przez Architekta
Systemowego i Architekta Biznesowego,
Menedżer Jakości podlega pod Szefa Projektu
Menedżer Konfiguracji nie jest już składową administracji projektu
wyróżniono obszary dokumentacji i testów
16. Porównaj zalecenia Prince2, PMI i Chestra SBS w zakresie obszarów zarządzania projektem informatycznym i organizacji biura projektu informatycznego.
PRINCE2:
*dobre*
-Stosowanie tej metodyki zapewnia wysoką standaryzację i powtarzalność projektów o wspólnym podejściu, terminologii i dokumentacji. Zapewnia to możliwość doskonalenia kompetencji.
-Metodyka w sposób racjonalny opiera się na najlepszych praktykach w
zarządzaniu projektami
-Sprawuje kontrolę nad startem, realizacją i końcem projektu
-Jej stosowanie nie wymaga opłat autorskich
*złe*
-zbyt pracochłonne w zastosowaniu do małych projektów
-ciągła wymiana informacji powoduje pojawienie się bezproduktywnych spotkań zabierających czas niezbędny na rzeczywistą pracę
17.Omów zagadnienie zarządzania konfiguracją w przedsięwzięciu informatycznym na podstawie metodyki RUP.
Zarządzania konfiguracją (configuration management) - jest odpowiedzialne za systematyczne strukturalizowanie produktów. Artefakty takie jak dokumenty i modele muszą być wersjonowane (version control) a zmiany muszą być widoczne. W skład zarządzania konfiguracją wchodzi także utrzymywanie rejestru zależności pomiędzy artefaktami, tak, aby wszystkie powiązane części były uaktualniane wraz ze zmianami.
18.Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania.
W procesie inżynierii wymagań możemy wyróżnić cztery główne fazy:
1. Studium wykonalności,
- Wynikiem tego studium powinien być raport, który zaleca albo nie zaleca kontynuacji procesu inżynierii wymagań i tworzenia systemu.
- Studium wykonalności to krótkie, skumulowane opracowanie, w którym staramy się odpowiedzieć na kilka pytań:
a. Czy system przyczyni się do realizacji ogólnych celów przedsiębiorstwa?
b. Czy system może być zaimplementowany z użyciem dostępnych technologii, w ramach ustalonego budżetu i ograniczeń czasowych?
c. Czy system może być zintegrowany z istniejącymi systemami, które już zainstalowano?
2. Określenie i analiza wymagań,
- W trakcie tej czynności techniczni budowniczowie oprogramowania pracują z klientem i użytkownikami systemu nad badaniem dziedziny zastosowania i usług, które system ma oferować, pożądanej efektywności, ograniczeniach sprzętowych itd.
3. specyfikowanie wymagań,
- to częściowo ustrukturalizowany zapis wykorzystujący zarówno język naturalny, jak i proste, częściowo przynajmniej sformalizowane notacje.
4. zatwierdzanie wymagań;
- Polega na wykazaniu, że wymagania naprawdę definiują system, którego chce użytkownik
- Błędy w wymaganiach kosztują tak dużo, że warto te wymagania zatwierdzać
Poprawianie błędów w wymaganiach może kosztować sto razy więcej niż poprawianie błędów w implementacji
Inżynieria wymagań ma na celu ma na celu określenie, jakich usług wymaga się od systemu i jakim ograniczeniom podlega tworzenie i działanie oprogramowania;
19.Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań.
Podstawowe metody rozpoznania wymagań:
- Wywiady i przeglądy. Wywiady powinny być przygotowane (w postaci listy pytań) i podzielone na odrębne zagadnienia. Podział powinien przykrywać całość tematu i powinny być przeprowadzone na reprezentatywnej grupie użytkowników. Wywiady powinny doprowadzić do szerokiej zgody i akceptacji projektu.
- Studia na istniejącym oprogramowaniem. Dość często nowe oprogramowanie zastępuje stare. Studia powinny ustalić wszystkie dobre i złe strony starego oprogramowania.
- Studia wymagań systemowych. Dotyczy sytuacji, kiedy nowy system ma być częścią większego systemu.
- Studia osiągalności. Określenie realistycznych celów systemu i metod ich osiągnięcia.
- Prototypowanie. Zbudowanie prototypu systemu działającego w zmniejszonej skali, z uproszczonymi interfejsami.
Cechy jakościowego dobrego opisu wymagań:
Dobry opis wymagań powinien:
- Być kompletny oraz niesprzeczny.
- Opisywać zewnętrzne zachowanie się systemu a nie sposób jego realizacji.
- Obejmować ograniczenia przy jakich musi pracować system.
- Być łatwy w modyfikacji.
- Brać pod uwagę przyszłe możliwe zmiany wymagań wobec systemu.
- Opisywać zachowanie systemu w niepożądanych lub skrajnych sytuacjach
20.Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań.
Wymagania funkcjonalne
- Są stwierdzeniami, jakie usługi ma oferować system, jak ma reagować na określone dane wejściowe oraz jak ma się zachowywać w określonych sytuacjach.
- W niektórych wypadkach wymagania funkcjonalne określają, czego system nie powinien robić.
- Mogą być również wykonywane przy użyciu systemów zewnętrznych.
Przykład:
a) Użytkownik będzie mógł przeszukać zbiór wszystkich baz danych lub wybrać tylko ich podzbiór.
b) System udostępni odpowiednie narzędzia do oglądania, aby użytkownik mógł czytać dokumenty z magazynu.
Wymagania niefunkcjonalne
- To ograniczenia usług i funkcji systemu.
- Obejmują ograniczenia czasowe, ograniczenia dotyczące procesu tworzenia, standardy itd.
Przykład:
a) System powinien być łatwy w użyciu dla doświadczonych kontrolerów, a sposób jego organizacji powinien zmniejszać liczbę błędów użytkownika.
b) Doświadczeni kontrolerzy powinni móc używać wszystkich funkcji systemu po szkoleniu trwającym dwie godziny. Po tym szkoleniu średnia liczba błędów robionych przez doświadczonych użytkowników nie powinna przekroczyć dwóch dziennie.
Wymagania dziedzinowe
- Są wyrażone za pomocą języka specyficznego dla dziedziny zastosowania;
- Pochodzą z dziedziny zastosowania systemu - odzwierciedlają jej charakterystykę.
- Mogą być funkcjonalne lub niefunkcjonalne..
Przykład: wymagania stawiane systemowi biblioteki
a) Wszystkie bazy danych powinny być dostępne przez jednolity interfejs użytkownika, którego podstawą jest standard Z39.50.
b) względu na ochronę praw autorskich niektóre dokumenty należy składać natychmiast po ich otrzymaniu. Zależnie od wymagań użytkownika, dokumenty te będą drukowane lokalnie na serwerze systemowym i przekazywane do rąk czytelnika albo wysyłane na drukarkę sieciową.
21.Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.
Wymagania funkcjonalne:
Opisują funkcje (czynności, operacje) wykonywane przez system.
Funkcje te mogą być również wykonywane przy użyciu systemów zewnętrznych.
Określenie wymagań funkcjonalnych obejmuje następujące kwestie:
-Określenie wszystkich rodzajów użytkowników, którzy będą korzystać z systemu.
-Określenie wszystkich rodzajów użytkowników, którzy są niezbędni do działania systemu (obsługa, wprowadzanie danych, administracja).
-Dla każdego rodzaju użytkownika określenie funkcji systemu oraz sposobów korzystania z planowanego systemu.
-Określenie systemów zewnętrznych (obcych baz danych, sieci, Internetu), które będą wykorzystywane podczas działania systemu.
-Ustalenie struktur organizacyjnych, przepisów prawnych, statutów, zarządzeń, instrukcji, itd., które pośrednio lub bezpośrednio
określają funkcje wykonywane przez planowany system.
22.Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.
Wymagania niefunkcjonalne:
Opisują ograniczenia, przy których system ma realizować swoje funkcje.
Wymagania dotyczące produktu.
Np. musi istnieć możliwość operowania z systemem wyłącznie za pomocą klawiatury.
Wymagania dotyczące procesu.
Np. proces realizacji harmonogramowania zleceń musi być zgodny ze standardem opisanym w dokumencie XXXA/96.
Wymagania zewnętrzne.
Np. system harmonogramowania musi współpracować z bazą danych systemu komputerowego działu marketingu opisaną w dokumencie YYYB/95.
Niedopuszczalne są jakiekolwiek zmiany w strukturze tej bazy.
Są to np: wymagania jakościowe (określają szczegółowe oczekiwania co do wydajności), technologiczne, bezpieczeństwa
Mogą definiować ograniczenia systemu, takie jak możliwości urządzeń wejścia-wyjścia i reprezentacje danych używane przez interfejsy systemu.
Wymagania niefunkcjonalne wynikają z:
-potrzeb użytkownika,
-ograniczeń budżetowych,
-strategii firmy,
-konieczności współpracy z innymi systemami sprzętu lub oprogramowania,
-czynników zewnętrznych.
23.Omów metody specyfikacji wymagań dla systemów informatycznych.
Metody specyfikacji wymagań:
Język naturalny - najczęściej stosowany. Wady: niejednoznaczność powodująca różne rozumienie tego samego tekstu; elastyczność, powodująca wyrazić te same treści na wiele sposobów. Utrudnia to wykrycie powiązanych wymagań i powoduje trudności w wykryciu sprzeczności.
Formalizm matematyczny. Stosuje się rzadko (dla specyficznych celów).
Język naturalny strukturalny. Język naturalny z ograniczonym słownictwem i składnią. Tematy i zagadnienia wyspecyfikowane w punktach i podpunktach.
Tablice, formularze. Wyspecyfikowanie wymagań w postaci (zwykle dwuwymiarowych) tablic, kojarzących różne aspekty (np. tablica ustalająca zależność pomiędzy typem użytkownika i rodzajem usługi).
Diagramy blokowe: forma graficzna pokazująca cykl przetwarzania.
Diagramy kontekstowe: ukazują system w postaci jednego bloku oraz jego powiązania z otoczeniem, wejściem i wyjściem.
Diagramy przypadków użycia: poglądowy sposób przedstawienia aktorów i funkcji systemu.
24.Omów przykładowy zakres treści dokumentu opisującego wymagania na system
informatyczny.
Streszczenie (maksymalnie 200 słów)
Spis treści
Status dokumentu (autorzy, firmy, daty, podpisy, itd.)
Zmiany w stosunku do wersji poprzedniej
1. Wstęp
1.1. Cel
1.2. Zakres
1.3. Definicje, akronimy i skróty
1.4. Referencje, odsyłacze do innych dokumentów
1.5. Krótki przegląd
2. Ogólny opis
2.1. Walory użytkowe i przydatność projektowanego systemu
2.2. Ogólne możliwości projektowanego systemu
2.3. Ogólne ograniczenia
2.4. Charakterystyka użytkowników
2.5. Środowisko operacyjne
2.6. Założenia i zależności
3. Specyficzne wymagania
3.1. Wymagania funkcjonalne (funkcje systemu)
3.2. Wymagania niefunkcjonalne (ograniczenia).
Dodatki
Kolejność i numeracja punktów w przedstawionym spisie treści powinna być zachowana. W przypadku gdy pewien punkt nie zawiera żadnej informacji należy wyraźnie to zasygnalizować przez umieszczenie napisu „Nie dotyczy”.
Dla każdego wymagania powinien być podany powód jego wprowadzenia: cele przedsięwzięcia, których osiągnięcie jest uwarunkowane danym wymaganiem.
Wszelki materiał nie mieszczący się w podanych punktach należy umieszczać w dodatkach.
Często spotykane dodatki:
Wymagania sprzętowe.
Wymagania dotyczące bazy danych.
Model (architektura) systemu.
Słownik terminów (użyte terminy, akronimy i skróty z wyjaśnieniem)
Indeks pomocny w wyszukiwaniu w dokumencie konkretnych informacji (dla dokumentów dłuższych niż 80 stron)
25.Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.
Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań.
Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych.
Czynności wykonywane w tej fazie:
Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu;
Ustalenie kontekstu projektu;
Ustalenie wymagań użytkowników;
Ustalenie wymagań organizacyjnych
Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.
26.Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy systemu informatycznego.
Cechy modelu analitycznego (logicznego):
-Uproszczony opis systemu;
-Hierarchiczna dekompozycja funkcji systemu;
-Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją;
-Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi;
-Jest on używany do wnioskowania o przyszłym oprogramowaniu;
-Model oprogramowania powinien być jego uproszonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji.
-Model ten jednakże nie zastępuje doświadczenia i wnikliwości projektantów, lecz pomaga projektantom w zastosowaniu tych walorów.
Logiczny model oprogramowania:
• pokazuje co system musi robić;
• jest zorganizowany hierarchicznie, wg poziomów abstrakcji
• unika terminologii implementacyjnej
• pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie.
Czynności w fazie analizy:
-Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu;
-Ustalenie kontekstu projektu;
-Ustalenie wymagań użytkowników;
-Ustalenie wymagań organizacyjnych
-Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.
27. Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
Analiza:
Głównym celem analizy jest wprowadzenie strukturalnej specyfikacji opisu projektu za pomocą narzędzi modelowania:
- diagramów przepływu danych — DFD,
- diagramów obiekt-relacja-atrybut — ERD,
- diagramów przejść stanów — STD;
Wynikiem analizy jest zbudowanie następujących modeli:
- model otoczenia,
- model zachowania systemu;
Modele są opisem formalnym systemu, niezależnym od technologii, jakiej użyje się do implementacji nowego systemu;
Na końcu etapu analizy określa się dokładniej niż w poprzednim etapie budżet projektu oraz kalkulację kosztów i zysków;
Projektowanie:
Polega na:
- wyodrębnienie tych części modelu zachowania systemu, które będą implementowane w systemie informatycznym;
- przydzielenie poszczególnych części specyfikacji do odpowiednich procesorów lub serwerów (przetwarzanie rozproszone); fragmenty DFD (te, które będą implementowane) są mapowane na zadania;
- zaprojektowanie struktury hierarchii modułów wewnątrz danego zadania;
- transformacja diagramów ERD na relacyjną bazę danych (projektowanie logiczne danych);
Implementacja:
W fazie implementacji:
- realizowane jest kodowanie i integracja modułów;
- stosuje się techniki programowania strukturalnego oraz implementacji top-down;
28.Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
Analiza obiektowa
- opracowanie modelu obiektowego dziedziny zastosowania;
- rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem;
Projektowanie obiektowe
- opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań;
- obiekty projektu obiektowego są związane z rozwiązaniem problemu;
Zadania w etapach fazy projektowania:
- uściślenie istniejących definicji klas, np. metod,
- dziedziczenie klas i operacji,
- szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów,
- wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów,
- decyzje o trwałości obiektów,
- modularyzacja i ukrywanie informacji,
- optymalizacja modelu,
- dokumentacja projektu;
Programowanie obiektowe
- realizacja projektu oprogramowania za pomocą języka programowania obiektowego;
- języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów;
29. Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.
System informatyczny to złożony program komputerowy lub zespół współdziałających ze sobą programów, przeznaczonych do wykonywania określonych funkcji: np. system operacyjny, system zarządzania bazami danych .
Najczęściej o systemie informatycznym mówi się wtedy, gdy do zbierania, gromadzenia, przesyłania i przetwarzania danych zastosowane są techniczne środki informatyki, a przynajmniej komputer do przetwarzania. Zestaw technicznych środków informatyki jest przeznaczony do realizacji zadań określonych przez system informacyjny .
Podsumowując - system informatyczny to określony obszar systemu informacyjnego danego obiektu, obsługiwany za pomocą technicznych środków dostępnych w informatyce.
Wyznaczniki jakości systemu informatycznego:
zgodny z wymaganiami użytkownika
-niezawodny
-efektywny
-łatwy w konserwacji
-interoperacyjny (jeżeli nie jest autonomiczny)
-ergonomiczny
30. Omów podstawowe diagramy statyczne w języku IBM/Rational UML.
Diagram klas - to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez ilustrację struktury klas i zależności między nimi. Elementami występującymi w diagramie klas są:
-klasy
-interfejsy
-grupy współdziałania
Pomiędzy elementami występującymi na diagramie klas występują związki:
-zależności
-generalizacji
-asocjacji
-agregacji
Diagram klas jest najczęściej wykorzystywanym diagramem w notacji UML.
Diagram obiektów - zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi.Każdy prostokąt na diagramie obiektów odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu pozostaje jasny.
Diagram komponentów - (zwany także diagramem implementacji) to diagram przedstawiający jeden z aspektów modelu zgodnego z UML. Przedstawia fizyczne elementy wchodzące w skład systemu i połączenia między nimi.
Diagram pakietów - to diagram służący do porządkowania struktury systemu. Stosowane, aby uprościć skomplikowane diagramy klas, klasy grupujemy w pakiety. Pakiet to zbiór logicznie powiązanych elementów UML.
Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym.
Diagram wdrożenia - (Deployment Diagram) obrazuje konfigurację węzłów działających w czasie wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera 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.
31. Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.
Diagram przypadków użycia
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.
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.
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 ( : ).
32. Omów podstawowe diagramy w metodyce Oracle CASE Method.
Diagram zależności
Diagram zależnosci 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 przepływu danych - (DFD - Data Flow Diagram) jest graficzną prezentacją przepływu danych w procesie. Na proces składają się następujące elementy:
-Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej.
-Magazyny danych — trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji.
-Terminatory — obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji.
Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..).
Diagram przepływu danych obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi.
33.Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1) podejście: encja-związek, 2) podejście obiektowe.
Model encja - związek reprezentuje dane i związki pomiędzy nimi. Podejście to pozwala na odwzorowanie w systemie danych i powiązań pomiędzy nimi. Pozwala na analizę rodzajów danych, ich przepływu w procesach przetwarzania, oraz na odpowiednie zaprojektowanie przechowywania danych. Jest to podejście dobre dla systemów, których głównym zadaniem jest przetwarzanie danych i ich przedstawianie, a także przechowywanie. Korzystne dla systemów bazodanowych.
Model obiektowy skupia się bardziej nad tym jak dane są przetwarzane, jaki jest do nich dostęp, jaka jest wymiana danych pomiędzy obiektami. W modelu obiektowym na drugi plan przesunięte jest jak dane są przechowywane, a także jak są reprezentowane. Znacznie istotniejsze jest kto ma do nich dostęp, jakie obiekty biorą udział w ich przetwarzaniu i jakie metody operują na danych. Podejście to jest korzystne dla wszystkich systemów, gdzie konieczna jest odpowiednia kontrola dostępu do danych, poprawności danych, oraz kontrola sposobu przetwarzania.
34.Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych.
Audytem nazywany jest niezależny przegląd i ocenę jakości oprogramowania, która zapewnia zgodność z wymaganiami na
oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami.
Aby zapewnić obiektywność, audyt powinien być przeprowadzony przez osoby niezależne od zespołu projektowego.
Audyt powinien być przeprowadzany przez odpowiednią organizację audytu (która aktualnie formuje się w Polsce,
Polskie Stowarzyszenie Audytu) lub przez osoby posiadające uprawnienia/licencję audytorów.
Reguły i zasady audytu są określone w normie:
ANSI/IEEE Std 1028-1988 „IEEE Standard for Reviews and Audits”.
Celem Audytu jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie projektu.
Zebrane informacje służą jako podstawa do podejmowania strategicznych decyzji w projekcie
Przedmioty:
- procesy projektu informatycznego - ma to na celu sprawdzenie, czy wykonane prace oraz sposób ich wykonania są prawidłowe
- produkty projektu informatycznego - ma to na celu sprawdzenie czy rezultaty poszczególnych prac odpowiadają zakładanym wymaganiom.
Perspektywy:
- technologia - ma na celu sprawdzenie, czy uzyte techniki oraz opracowane rozwiazania sa prawidlowe i prawidlowo stosowane
- zarzadzanie - ma to na celu sprawdzenie, czy sposób zarządzania projektem umożliwia jego sukces
35.Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów informatycznych.
Inspekcja to formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane
przez osobę lub grupę osób nie będących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów [IEEE Std. 729-1983]
- Inspekcje stosowane są dla "elitarnych" systemów, czyli takich, które spełniać mają bardzo ważne zadania.
- nie jest prosta analiza kosztów inspekcji,
- nie ma gotowych narzędzi programowych - wymagane jest doświadczenie ludzi.
Korzyści z inspekcji:
- wzrost produktywności
- skrócenie czasu projektu
- zmniejszenie kosztu i skrócenie czasu wykonania testów (mniej testów regresyjnych)
- 10x mniejsze koszty pielęgnacji
- poprawa procesu programowego
- większy komfort pracy
- mniejsze koszty marketingu
Inspekcje przeprowadzane są przez specjalistów dla specjalistów bez udziału kierownictwa. Przykładowo inspekcje modułów są przeprowadzane przez pracujące równolegle podgrupy projektowe.
36.Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego.
- badanie prognostyczne - zanim powstanie kod źródłowy, czyli w fazach: określenia wymagań i projektowania
Zalety:
- Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów,
- Stosunkowo niskie koszty testowania,
- Możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji
Wady:
- Bazowanie na modelu oprogramowania, co może zmniejszyc dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi
- badania diagnostyczne:
Typy:
- Analiza dynamiczna
- analiza statyczna
- inspekcje
- audyty
37. Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu 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.
38. Omów istotę testowania metodą black box i white box.
White box
Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania programu.
Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku.
Często niezbędne staje się wcześniejsze przygotowanie danych testowych lub specjalnych programów usprawniających testowanie (np. programu wywołującego testowaną procedurę z różnymi parametrami).
Dane testowe powinny być dobrane w taki sposób, aby każda ścieżka w programie była co najmniej raz przetestowana.
Ograniczeniem testowania na zasadzie białej skrzynki jest niemożliwość pokazania brakujących funkcji w programie. Wadę tę usuwa testowanie n/z czarnej skrzynki.
Black box
Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne.
Testowanie n/z czarnej skrzynki powinno obejmować cały zakres danych wejściowych.
Testujący powinni podzielić dane wejściowe w „klasy równoważności”, co do których istnieje duże przypuszczenie, że będą produkować te same błędy. Np. jeżeli testujemy wartość „Malinowski”, to prawdopodobnie w tej samej klasie równoważności jest wartość „Kowalski”. Celem jest uniknięcie efektu „eksplozji danych testowych”.
„Klasy równoważności” mogą być również zależne od wyników zwracanych przez testowane funkcje. Np. jeżeli wejściem jest wiek pracownika i istnieje funkcja zwracająca wartości „młodociany”, „normalny” „wiek emerytalny”, wówczas implikuje to odpowiednie klasy równoważności dla danych wejściowych.
Wiele wejść dla danych (wiele parametrów funkcji) może wymagać zastosowania pewnych systematycznych metod określania ich kombinacji, np. tablic decyzyjnych lub grafów przyczyna-skutek.
39. Omów zagadnienie architektury systemów informatycznych.
- Architektura globalna: koordynacja i komunikacja pomiędzy organizacjami;
- Architektura korporacyjna (enterprise): koordynacja i komunikacja w obrębie organizacji;
- Architektura systemu: koordynacja i komunikacja pomiędzy aplikacjami;
- Architektura aplikacji (Subsystem): dostarczanie funkcjonalności;
- Makro-architektura (Frameworks): powtarzające się aplikacje;
- Mikro-architektura: wzorce projektowe;
- Obiekty: specyficzne konstrukcje w językach programowania;
40. Omów zagadnienie projektowania architektonicznego systemów informatycznych.
Wzorce architektoniczne
1.Konstrukcyjne:
- Służą do pozyskiwania obiektów;
- Opisują szczegółowo, jak obiekt może zostać stworzony,
- Czynią kod niezależnym od typów tworzonych obiektów;
- Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
- Przykłady:
+ Singleton,
+ Fabryka,
+ Metoda Fabrykująca,
+ Fabryka Abstrakcyjna,
+ Budowniczy,
+ Prototyp;
2.Strukturalne:
- Stosowany do łączenia obiektów w większe struktury;
- Zastosowanie np. w implementacji złożonego interfejsu użytkownika;
- Przykłady:
+ Fasada,
+ Adapter,
+ Most,
+ Kompozyt,
+ Dekorator,
+ Waga Piórkowa,
+ Proxy;
3.Operacyjne:
- W celu definiowania komunikacji pomiędzy obiektami;
- Pomagają kontrolować przepływ danych w złożonym programie;
- Przykłady:
+ Iterator,
+ Łańcuch Odpowiedzialności,
+ Stan,
+ Mediator,
+ Obserwator,
+ Strategia;
41. Omów istotę koncepcji wzorców projektowych w projektowaniu systemów informatycznych.
Wzorce projektowe stanowią powtarzalne rozwiązanie zagadnień projektowych, z którymi się wciąż spotykamy;
- Wzorce dostarczają sprawdzonych rozwiązań dla powtarzających się problemów;
- Możliwe do zastosowania w wielu rzeczywistych kontekstach;
- Wpływają na sposób modelowania;
- Zapobiegają „wymyślaniu koła od nowa”;
- Usprawniają komunikację
- Ułatwiają tworzenie dokumentacji
42. Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu).
- konstrukcyjne
--- służą do pozyskiwania obiektów;
--- opisują szczegółowo, jak obiekt może zostać stworzony,
--- czynią kod niezależnym od typów tworzonych obiektów;
--- wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
- strukturalne
--- stosowany do łączenia obiektów w większe struktury;
--- zastosowanie np. w implementacji złożonego interfejsu użytkownika
- operacyjne (czynnościowe)
--- definiowanie komunikacji pomiędzy obiektami;
--- kontrolowanie przepływów danych w złożonych algorytmach (programach);
--- przydział zobowiązań obiektom;
43. Omów model niezawodności oprogramowania według Jelińskiego-Morandy (1972).
- Wykrywanie błędów jest niezależne;
- Usuwanie wykrytych błędów nie generuje nowych;
- Intensywność wykrywania błędów - proporcjonalna do liczby błędów pozostających w oprogramowaniu: (nie dałem rady przenieść tego wzoru)
44.Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki kosztów.
Wyniki badań przeprowadzonych przez Boehma w latach osiemdziesiątych jak i obecnie prowadzone badania potwierdzają, że koszt poprawy błędu rośnie wykładniczo w zależności od etapu wytwarzania oprogramowania. Najmniej kosztuje poprawa na etapie analizy, najwięcej po wdrożeniu systemu do produkcji.
Jeśliby błąd związany z rokiem 2000 usunąć na etapie implementacji to koszt z tym związany byłby tysiąckrotnie niższy w stosunku do kosztu związanego z jego poprawą po wdrożeniu systemu.
W większości procesów wytwarzania testowanie systemu jest wykonywane na samym końcu. Oznacza to, że jest ono szczególnie narażone na przekroczenie kosztów i harmonogramu, co oznacza po prostu, że czas potrzebny na testowanie jest obcinany, ponieważ wcześniejsze fazy przekroczyły termin i budżet.
Szacunki kosztów wg Roger'a Pressman'a (1997):
--- Testowanie: ~ 30 % - 40 % całkowitej pracochłonności;
--- Testowanie systemów krytycznych: 70% - 80% całkowitej pracochłonności (!);
Dodatkowo należy brać pod uwagę tzw. koszty utraconych korzyści
45.Omów źródła kosztów nieprawidłowości oprogramowania.
Oprogramowanie zawierające błędy, może być źróbłem kosztów. Koszt wykrycia i naprawienia błędu często przekrocza koszt napisania fragmentu kodu od nowa. Do kosztów oprogramowania złej jakości zaliczamy:
1) Koszty jakości w skład których wchodzą:
-koszty błędów (traktowane jako straty),
-koszty oceny (traktowane jako nakłady),
-koszty zapobiegania (traktowane jako nakłady).
2) Koszty procesu:
-koszty niezgodności (traktowane jako straty),
-koszty zgodności (traktowane jako nakłady).
3) Straty jakości (skutki odchyleń od wymagań jakościowych)
Program złej jakości może mieć również potencjalnie duże koszty błędnych wykonań co może narazić na wysokie straty finansowe instytucji korzystającej z błędnie działającego oprogramowania. Oprogramowanie dobrej jakości to mniejsze koszty pielęgnacji (naprawczej) oraz mniejsze koszty marketingu który ma na celu ukrywanie braku jakości
46.Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady.
Testowanie oprogramowania proces związany z wytwarzaniem oprogramowania. Jest jednym z procesów kontroli jakości oprogramowania. Testowanie oprogramowania jest jednym z kluczowych etapów procesu zapewnienia jego jakości. Celem testowania oprogramowania jest sprawdzanie jak dobry jest docelowy produkt oraz sprawdzenie czy oprogramowanie spełni swoje zadanie. Wsód testów wyróżniamy testy dynamiczne, które polegają na wykonywaniu (fragmentów) programu albo modeli symulacyjnych i porównywaniu uzyskanych wyników z wynikami poprawnym oraz testy statyczne, oparte na analizie kodu albo modeli analitycznych lub projektowych .Testowaniu oprogramowania podlega:Wydajność systemu, interfejsy systemu, własności operacyjne systemu, testy zużycia zasobów oraz zabezpieczenie systemu
Weryfikacja - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań. Proces weryfikacji oprogramowania można określić jako poszukiwanie i usuwanie błędów na podstawie obserwacji błędnych wykonań oraz innych testów. Weryfikacja uwzględnia następujące czynności: przeglądy techniczne oraz inspekcje oprogramowania; sprawdzanie czy wymagania na oprogramowanie są zgodne z wymaganiami użytkownika; sprawdzanie czy komponenty projektu są zgodne z wymaganiami na oprogramowanie; testowanie jednostek oprogramowania (modułów); testowanie integracji oprogramowania, testowanie systemu; testowanie akceptacji systemu przez użytkowników
Walidacja (atestowanie)- ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową. Walidacja sprawdza, czy oprogramowanie jest zgodne z oczekiwaniami użytkownika.
47.Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania.
Badanie prognostyczne przeprowadzane są wtedy gdy nie ma kodu źródłowego.
Głównymi zaletami podejścia prognostycznego jest: Zwiększenie prawdopodobieństwa uniknięcia lub zmniejszenia oddziaływania zjawiska propagacji błędów; stosunkowo niskie koszty testowania oraz możliwość przebadania wielu różnych projektów oprogramowania w celu wyboru najlepszego do implementacji. Wadą podejścia prognostycznego jest bazowanie na modelu oprogramowania, co może zmniejszyc dokładność badania (potencjalna rozbieżność z właściwościami implemetacyjnymi). Metody prognostyczne bazują na: metodach specyfikacji formalnej programów; badaniu logiki sterowania programów oraz na metrykach projektu oprogramowania. Wyróżniamy dwa komplementarne podejścia: badanie właściwości statycznych oraz badanie właściwości dynamicznych
48.Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania.
Badanie diagnostyczne przeprowadzane są gdy istnieje kod źródłowy. W skład diagnostycznego badania oprogramowania wchodzi analiza dynamiczna czyli eksperymentowanie z działającym kodem programu oraz analiza statyczna czyli praca z kodem źródłowym w celu rozpoznania funkcjonalności testowanego kodu oraz zaprojektowania odpowiednich testów. Do Testów diagnostycznych zalicza się testy strukturalne (testy białej skrzynki), które opracowuje się na podstawie wiedzy i implementacji oprogramowania. Stosuje się je do stosunkowo niewielkich jednostek programów, takich jak podprogramy i operacje związane z obiektem. Podczas testów strukturalnych tester może analizować kod i korzystać z wiedzy o strukturze komponentu przy opracowywaniu danych testowych. Drugim rodzajem testów diagnostycznych jest Testowanie strategią czarnej skrzynki. Polega ono na sprawdzaniu funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne. Testowanie metodą czarnej skrzynki powinno obejmować cały zakres danych wejściowych. Tester zadaje dane wejściowe i analizuje dane wyjściowe. Jeżeli dane wyjściowe (wyniki) nie są zgodne z założeniami, to test pozytywnie wykrył defekt oprogramowania.
49. Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości.
Użyteczność - dostępność oczekiwanych usług
Niezawodność - np. prawdopodobieństwo błędu w czasie realizacji transakcji, średni czas pomiędzy błędnymi wykonaniami, dostępność (procent czasu, w którym system jest dostępny), czas restartu po awarii systemu, prawdopodobieństwo zniszczenia danych w przypadku awarii.
Efektywność
Wielokrotne użycie - ponowne wykorzystanie gotowych elementów
Pielęgnacyjność - podatność na pielęgnowanie, łatwość wprowadzania zmian
Przenośność - np. procent kodu zależnego od platformy docelowej, liczba platform docelowych, koszt przeniesienia na nową platformę.
Testowalność - podatność na testowanie
50. Omów główne klasy błędów w systemach informatycznych
Klasyfikacja błędów:
- funkcjonalne - funkcja źle wykonana bądź źle funkcjonująca
- systemowe - nieprawidłowe zarządzanie zasobami, mylne interfejsy, zła komunikacja z bazą danych bądź jej brak
- przetwarzania - niewłaściwe przetwarzanie danych w poszczególnych modułach
- danych - źle wprowadzone dane, ich brak, błędna specyfikacja
- graficzne - interfejs graficzny niezgodny z założeniami
- kodowania - niewłaściwe użycie języka programowania
- dokumentacji - niepełna lub błędna dokumentacja
- inne - niezidentyfikowana przyczyna wystąpienia
51. Omów czynności procesu testowania oprogramowania.
Fazy procesu testowania:
- testowanie komponentów (jednostek) - testuje się poszczególne komponenty, aby zapewnić, że działają poprawnie,
- testowanie modułów - moduł jest kolekcją niezależnych komponentów takich jak klasy obiektów, abstrakcyjne typy danych, albo bardziej luźną kolekcją procedur i funkcji,
- testowanie podsystemów - ta faza obejmuje testowanie kolekcji modułów, które zintegrowano w podsystemie,
- testowanie systemu - ten proces testowania ma wykryć błędy wynikające z nieprzewidzianych interakcji między zintegrowanymi podsystemami i problemów z interfejsami podsystemów,
- testowanie odbiorcze - jest to końcowa faza procesu testowania przed przyjęciem systemu do użytkowania.
52. Co to jest przypadek testowy, scenariusz testów? Podaj przykłady.
Scenariusz testów:
- dokument opisujący procedury i przypadki testowe dla określonego produktu
- jest podstawą pracy testera z danym produktem
- obejmuje:
--- listę testowanych produktów
--- odwołania do wymagań
--- przypadki testowe
--- kryteria poprawności
--- listę agentów testowych
--- szczegółowe procedury testowania dla produktów
Przypadek testowy:
- ściśle określona ścieżka przejścia przez testowany produkt lub charakterystyczna klasa danych wejściowych
- określa szczegółowy zakres w testowanym produkcie, pozwalający rozłożyć skomplikowany problem testowy na elementarne części
53.Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.
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”;
54.Omów podstawowe schematy testów integracyjnych. Podaj przykłady.
-Skokowe - grupują wybrane (lub wszystkie) jednostki w celu ich równoczesnego przetestowania
-Przyrostowe - zakładają dołączenie do tworzonej całości za każdym razem tylko jednej uprzednio przetestowanej jednostki:
- zstępujące (odgórne) - integruje się i testuje się komponenty wysokiego poziomu przed ukończeniem ich projektu i implementacji; np.: (Namiastka (stub):
- imituje jednostki niższego poziomu
- zastępuje moduły wywoływane przez
testowany moduł )
- wstępujące (oddolne) - testuje się i integruje komponenty niskiego poziomu przed ukończeniem budowy komponentów wyższego poziomu;np.:( Sterownik (driver):
- dostarcza jednostkom niższego poziomu dane
- zastępuje moduł wywołujący testowane moduły)
55.Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca konstrukcyjnego.
-Służą do pozyskiwania obiektów;
-Opisują szczegółowo, jak obiekt może zostać stworzony,
-Czynią kod niezależnym od typów tworzonych obiektów;
-Wybór konkretnej klasy uzależniany jest np. od parametrów konfiguracyjnych;
-Przykłady:
-Singleton,
-Fabryka,
-Metoda Fabrykująca,
-Fabryka Abstrakcyjna,
-Budowniczy,
-Prototyp;
56.Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca strukturalnego.
Strukturalne wzorce projektowe
- Zastosowanie np. w implementacji złożonego interfejsu użytkownika;
- Stosowane do łączenia obiektów w większe struktury
Jednym z przykładów jest Fasada:
- Ujednolicony i prostszy interfejs do struktury złożonych podsystemów;
- Separacja klienta od złożonych podsystemów;
- Wybór odpowiedniej struktury dla żądania klienta;
- Możliwości zmian w ukrywanych podsystemach;
Np.
- w bibliotekach Javy: klasy pakietu java.sql (Statement, ResultSet);
- wejście usług w Service Oriented Architecture (SOA);
57.Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca czynnościowego.
Wzorce czynnościowe inaczej zwane operacyjnymi, służą do:
- definiowanie komunikacji pomiędzy obiektami;
- kontrolowanie przepływów danych w złożonych algorytmach (programach);
- przydział zobowiązań obiektom;
Jednym z przykładów może być iterator:
- Upraszcza przemieszczanie po kolekcji danych (np. liście), z wykorzystaniem standardowego interfejsu;
- Nie wymaga znajomości wewnętrznej struktury kolekcji danych;
- Umożliwia równoczesne przeglądanie kilku kolekcji;
Np.
- W bibliotekach Javy: iterator w kolekcjach z pakietu java.util;
1.Omów przedmiot i zakres inżynierii oprogramowania.
2.Omów zagadnienie języka programowania i semiotyki języka programowania.
3.Omów zagadnienie i skutki tzw. „kryzysu oprogramowania”.
4.Omów przykładowe źródła złożoności projektu informatycznego.
5.Omów sposoby opanowywania złożoności projektu informatycznego.
6.Omów zagadnienie modelowania pojęciowego w projekcie informatycznym.
7.Co to jest metodyka prowadzenia projektu informatycznego?
8.Omów następujący model cyklu życia oprogramowania: … nazwa modelu
9.Omów zadania kierownictwa przedsięwzięcia informatycznego w cyklu wytwórczym oprogramowania.
10.Omów podstawowe czynniki psychologiczne w procesie wytwórczym i rodzaje osobowości twórców oprogramowania.
11.Omów cechy dobrego inżyniera oprogramowania i sposoby zorientowania na pracę w cyklu wytwórczym oprogramowania.
12.Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według Prince2.
13.Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń Prince2.
14.Omów podstawowe obszary zarządzania przedsięwzięciem informatycznym według metodyki PMI.
15.Omów przykład struktury biura projektu informatycznego, zbudowanego według zaleceń metodyki Chestra SBS.
16.Porównaj zalecenia Prince2, PMI i Chestra SBS w zakresie obszarów zarządzania projektem informatycznym i organizacji biura projektu informatycznego.
17.Omów zagadnienie zarządzania konfiguracją w przedsięwzięciu informatycznym na podstawie metodyki RUP.
18.Omów zakres działania tzw. „inżynierii wymagań” w procesie wytwórczym oprogramowania.
19.Omów podstawowe metody rozpoznawania wymagań i cechy jakościowego dobrego opisu wymagań.
20.Omów główne klasy wymagań na system informatyczny. Podaj przykłady takich wymagań.
21.Omów i podaj przykłady wymagań funkcjonalnych dla systemu informatycznego.
22.Omów i podaj przykłady wymagań niefunkcjonalnych dla systemu informatycznego.
23.Omów metody specyfikacji wymagań dla systemów informatycznych.
24.Omów przykładowy zakres treści dokumentu opisującego wymagania na system informatyczny.
25.Omów zakres fazy analizy w cyklu wytwórczym systemów informatycznych.
26.Omów główne cechy modelu analitycznego i podstawowe czynności w fazie analizy systemu informatycznego.
27.Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
28.Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
29.Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.
30.Omów podstawowe diagramy statyczne w języku IBM/Rational UML.
31.Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.
32.Omów podstawowe diagramy w metodyce Oracle CASE Method.
33.Porównaj następujące podejścia do analizy i projektowania systemów informatycznych: 1) podejście: encja-związek, 2) podejście obiektowe.
34.Omów zagadnienie audytu w procesie wytwórczym systemów informatycznych.
35.Omów zagadnienie inspekcji oprogramowania w procesie wytwórczym systemów informatycznych.
36.Omów rodzaje testów oprogramowania w odniesieniu do cyklu życia systemu informatycznego.
37.Omów uwarunkowania prawne i inżynierskie procesu testów akceptacyjnych systemu informatycznego.
38.Omów istotę testowania metodą black box i white box.
39.Omów zagadnienie architektury systemów informatycznych.
40.Omów zagadnienie projektowania architektonicznego systemów informatycznych.
41.Omów istotę koncepcji wzorców projektowych w projektowaniu systemów informatycznych.
42.Omów wzorzec projektowy …… (nazwa jednego z wzorców z wykładu).
43.Omów model niezawodności oprogramowania według Jelińskiego-Morandy.
44.Omów zjawisko propagacji kosztów błędu oprogramowania i podaj przykładowe szacunki kosztów.
45.Omów źródła kosztów nieprawidłowości oprogramowania.
46.Co to jest testowanie, weryfikacja i walidacja oprogramowania? Podaj przykłady.
47.Omów istotę i przykłady metod prognostycznego badania jakości oprogramowania.
48.Omów istotę i przykłady metod diagnostycznego badania jakości oprogramowania.
49.Wymień i omów składowe jakości oprogramowania na drugim poziomie drzewa jakości.
50.Omów główne klasy błędów w systemach informatycznych.
51.Omów czynności procesu testowania oprogramowania.
52.Co to jest przypadek testowy, scenariusz testów? Podaj przykłady.
53.Co to jest macierz przykrycia testów akceptacyjnych? Podaj przykłady.
54.Omów podstawowe schematy testów integracyjnych. Podaj przykłady.
55.Jaka jest istota konstrukcyjnych wzorców projektowych? Przedstaw przykład wzorca konstrukcyjnego.
56.Jaka jest istota strukturalnych wzorców projektowych? Przedstaw przykład wzorca strukturalnego.
57.Jaka jest istota czynnościowych wzorców projektowych? Przedstaw przykład wzorca czynnościowego.
6