P

rojektowanie

S

ystemów

I

nformatycznych

Opracowanie zagadnień na egzamin

20

12

<rek

LAMA

>

</rek

LAMA

>

2

1.

Wyjaśnić różnicę między notacją, językiem a metodyką.

Metodyka jest zbiorem zasad dotyczących sposobów wykonywania jakiejś pracy lub trybu postępowania
prowadzącego do określonego celu wraz ze zbiorem narzędzi przeznaczonych do wykonania tej pracy
oraz wiedzą w jaki sposób posługiwać się tymi zasadami i narzędziami.
Notacja opisu metodyki oparta jest na dwóch podstawowych modelach języka UML: modelu klas oraz
modelu czynności. To umowny sposób zapisu symboli, liter, znaków, itp. Notacja umożliwia w sposób
formalny zapis treści wyrażeń reguł, wzorów, formuł, itd.
Składowe języka modelowania:

•składnia - określa jakie oznaczenia wolno stosować i w jaki sposób je ze sobą łączyć;
•semantyka - określa co należy rozumieć pod przyjętymi oznaczeniami;
•pragmatyki - określa w jaki sposób należy dopasować wzorzec notacyjny do konkretnej sytuacji i
problemu.

2.

Wyjaśnić różnicę między modelem a diagramem.

Model jest spójnym opisem systemu; stanowi jego kompletny obraz utworzony z określonej
perspektywy na pewnym poziomie szczegółowości, co oznacza, że niektóre elementy systemu są ukryte,
a inne wyeksponowane. Pojedynczy model zazwyczaj nie wystarcza ani do zrozumienia wszystkich
aspektów systemu jednocześnie, ani do jego implementacji. Zazwyczaj potrzebnych jest wiele modeli,
które muszą być wzajemnie spójne oraz redundantne.

Diagram służy do opisania modelu. Model może być opisywany przy pomocy wielu diagramów
opisujących dany model.

3.

Podać charakterystykę języka UML

UML to graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania elementów
systemów informatycznych. Umożliwia standaryzację sposobu opracowywania przekrojów systemu,
obejmujących obiekty pojęciowe, takie jak procesy przedsiębiorstwa i funkcje systemowe, a także
obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy baz danych i
komponenty programowe nadające się do ponownego użycia. UML wspomaga specyfikowanie
wszystkich ważnych decyzji analitycznych, projektowych i implementacyjnych, które muszą być
podejmowane w trakcie wytwarzania i wdrażania systemu informatycznego. Modele zapisane w języku
UML są jednakowo interpretowane przez wszystkie osoby zaangażowane w dany proces.

4.

Omówić modele i diagramy zdefiniowane w UML

Model jest uproszczeniem rzeczywistości. Modelowanie prowadzi do lepszego zrozumienia systemu.
Opanowanie złożonego systemu wymaga opracowania wielu wzajemnie powiązanych modeli.

Model obiektowy

Diagram klas

Diagram obiektów

Klasa, obiekt, asocjacja, generalizacja, zależność,
realizacja, interfejs

Model przypadków
użycia

Diagram przypadków
użycia

Aktor, przypadek użycia, inkluzja, ekstensja,
generalizacja

Model implementacji

Diagram komponentów

Diagram wdrożeniowy

Komponent, interfejs, zależność, realizacja

Węzeł, komponent, zależność, lokacja

Model dynamiczny

Diagram stanów

Diagram aktywności
Diagram interakcji

Stan, zdarzenie, przejście, akcja, aktywność

Stan, aktywność, fork, join, romb decyzyjny
Interakcja, współpraca, komunikat, aktywacja

Model zarządzania

Diagram pakietów

Pakiet, podsystem

Wszystkie modele

Wszystkie diagramy

Stereotyp, wartość etykietowana, ograniczenie

3

Diagram przypadków użycia

Identyfikacja kategorii użytkowników oraz sposobów używania przez
nich systemu

Diagram klas

Modelowanie klas obiektów i ich wzajemnych relacji

Diagram czynności

Modelowanie procesów biznesowych, scenariuszy przypadków użycia
lub algorytmów

Diagram stanów

Modelowanie historii życia obiektu – jego stanów i możliwych przejść
między stanami

Diagram komponentów

Modelowanie fizycznych składników oprogramowania, ich zależności i
interfejsów

Diagram rozmieszczenia
(diagram wdrożenia)

Modelowanie konfiguracji sprzętowych i programowych
komponentów systemu

Diagram sekwencji

Modelowanie czasowej sekwencji wymiany komunikatów podczas
współpracy obiektów, pakietów lub komponentów

Diagram interakcji

Modelowanie przepływu sterowania w procesie biznesowym lub
systemie

Diagram obiektów

Modelowanie chwilowej konfiguracji obiektów oprogramowania

5.

W jakim celu budujemy modele biznesowe. Podaj kilka przykładów modeli, które sam
zbudowałeś.

Zasadniczym celem budowy modelu biznesowego jest utworzenie takiego obrazu organizacji,

który będąc opisem rzeczywistości stanie się podstawą szkieletu aplikacji (opisem tego szkieletu).

Dzięki modelom biznesowym można odpowiedzieć na 6 kluczowych pytań dla każdej organizacji
biznesowej: co, jak, dlaczego, kto, gdzie i kiedy.

Jako przykłady modeli biznesowych wykorzystywanych przez przedsiębiorstwa internetowe w dużym
uproszczeniu wyróżnia się:

●

model pośrednika - firmy zarabiają na prowizjach od transakcji realizowanych za ich

pośrednictwem (np. serwisy aukcyjne, internetowe biura maklerskie);

●

model reklamowy - firmy zarabiają na opłatach pobieranych od reklamodawców

zamieszczających reklamy na prowadzonych przez nie stronach internetowych (np. wortale
tematyczne zarabiające na banerach reklamowych i wyskakujących okienkach);

●

model pośrednika informacyjnego - firmy zarabia ją na sprzedaży danych o konsumentach

zebranych w trakcie swojej działalności (która jest na tyle atrakcyjna, że przyciąga konsumentów
podających owe dane);

●

model kupca - firmy zarabiają na sprzedaży produktów za pomocą Internetu (handlu

internetowym), co może być prowadzone w połączeniu z tradycyjną działalnością handlową lub
wyłącznie w Internecie;

●

model producenta - firmy zarabiają na sprzedaży swoich produktów za pomocą Internetu, co

oznacza skrócenie kanału dystrybucji (ominięcie pośredników);

●

model sieci afiliowanej - firmy umieszczają na swoich stronach linki do stron innych

podmiotów oferujących produkty w Internecie i zarabiają na prowizjach uzyskiwanych od tych
podmiotów, o ile konsument zakupił jakiś produkt trafiając do handlowca dzięki temu linkowi;

●

model

wirtualnej wspólnoty - firma zarabia dzięki silnej lojalności internautów wobec

wirtualnej wspólnoty (model ten zdefiniowano przed Web 2.0 na przykładzie Red Hat Linux,
obecnie można by tu pewnie wyróżnić całą masę podmodeli);

●

model abonencki - firma zarabia na pobieraniu opłat za dostęp do treści umieszczanych na

stronach internetowych, często wyróżniając darmowe treści "dla wszystkich" i płatne "dla
subskrybentów";

●

model taryfowy - firma nalicza opłaty za faktyczne użytkowanie usług internetowych

4

6.

Dlaczego właściwe określenie celów biznesowych jest podstawą poprawnego modelu
biznesowego?

Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy i
projektowania systemów informatycznych. Wiele metodyk przypisuje temu zagadnieniu wysoki
priorytet.

7.

Jakie korzyści lub straty odniesie organizacja z modelu biznesowego?

Korzyści:

1.

Pozwoli lepiej zrozumieć przepływ informacji w organizacji.

2.

Pozwoli na szybszą identyfikację procesów

3.

Możliwość przeprowadzenia ewentualnej optymalizacji

4.

Model procesów biznesowych opisuje wszystkie procesy, których celem jest utrwalenie informacji w

postaci danych i dokumentów oraz pokazuje dynamikę każdego dokumentu w organizacji.

5.

Ułatwia przeprowadzenie oceny rentowności projektu.

6.

Daje pewność, że opisana strategia rynkowa jest rozumiana poprawnie i ułatwia poprawne

zidentyfikowanie projektu IT.

Ogólnie mówiąc są to te czynności, działania organizacji, które niosą korzyści dla jej otoczenia (aktorów
biznesowych).

8.

Przedstaw istotę systemu informacyjnego

System informacyjny – to posiadająca wiele poziomów struktura pozwalająca użytkownikowi na

przetwarzanie, za pomocą procedur i modeli, informacji wejściowych w wyjściowe. Komputeryzacja
systemów informacyjnych jest coraz powszechniejszym sposobem zwiększenia sprawności działania
systemu zarządzania, ponieważ mimo początkowych wydatków na szkolenia, oprogramowanie i
wdrożenie, system informatyczny umożliwia formalizację struktury organizacyjnej, zwiększenie
rozpiętości kierowania, automatyzowanie zadań, dostarcza niezwłocznie żądanych informacji, ułatwia
pracę grupową w przedsiębiorstwach posiadających wiele oddziałów.

System informacyjny jest specyficznym systemem społeczno-gospodarczym, który obok procesów

informacyjnych zawsze współtworzą także zasoby oraz informacja.

Cele wdrażania systemu informacyjnego w przedsiębiorstwie :

●

ułatwianie gromadzenia informacji niezbędnych do funkcjonowania danego procesu,

●

usprawnianie analizy zebranych danych i informacji,

●

możliwość przekształcenia nieustrukturalizowanego procesu w rutynowo przebiegającą

transakcję,

●

ułatwienie wprowadzania zmian w kolejności przebiegu procesu,

●

umożliwienie łatwego dostępu do zasobów wiedzy i ekspertyz oraz ich swobodnego transferu,

●

umożliwienie eliminacji zbędnych pośredników z procesu,

●

umożliwienie łatwego monitorowania przebiegu zarówno całego procesu, jak i jego

poszczególnych elementów,

●

możliwość zastępowania czynnika ludzkiego w procesie lub też zmniejszanie jego udziału.

5

9.

Przedstaw klasyfikację systemów

Kryterium podziału

Grupy systemów

Zakres merytoryczny systemu informatycznego

- dziedzinowe

- cząstkowe

- kompleksowe

Zakres spełnianych funkcji

- ewidencyjno – sprawozdawcze

- informujące

- wspomagania decyzji

- automatyzacji biura

Złożoność funkcjonalna i techniczno-programowa

- systemy proste

- systemy złożone

-systemy szczególnie złożone

10.

Organizacja gospodarcza jako system i jej elementy składowe

Organizacja gospodarcza i jej otoczenie należą do systemów, które charakteryzują się ogólnymi
właściwościami. Są to systemy: rzeczywiste, sztuczne, złożone z ludzi oraz zasobów materialnych i
niematerialnych o niemożliwych do jednoznacznego ustalenia rzeczywistych regułach zachowania się,
otwarte i dynamiczne. Są zarówno informowane, jak i informujące.

Warunkiem koniecznym skutecznego funkcjonowania każdej organizacji gospodarczej jest
zorganizowanie sprawnego przepływu informacji. Należy stworzyć system informacyjny, który będzie
stanowił jej integralną część.

Składowe:
-Procesy (zasoby, zadania)
-Technologie (produkcyjne, informacyjne)
-Organizacja (struktury, procedury)
-Ludzie (kwalifikacje, motywacje)

11.

Cel i zakres analizy strategicznej

W sensie czynnościowym analiza strategiczna jest zbiorem działań diagnozujących organizację i jej

otoczenie, umożliwiających zbudowanie planu strategicznego i jego realizację.

W sensie narzędziowym analiza strategiczna jest zestawem metod analizy, które pozwalają na

zbadanie ocenę i przewidywanie przyszłych stanów wybranych elementów przedsiębiorstwa i jego
otoczenia z punktu widzenia możliwości przetrwania i rozwoju. Analiza strategiczna określa
pozycję strategiczną firmy obecną oraz w przyszłości.

Odnośnie aktualnej pozycji strategicznej określa:

- pozycję konkurencyjną firmy na tle sektora,
- podstawowe czynniki kształtujące obecna pozycję strategiczną firmy.

Odnośnie pozycji strategicznej w przyszłości analiza strategiczna określa:

- jakie zmiany nastąpią w otoczeniu,
- jakie zmiany będą miały wpływ na działalność firmy, przy założeniu obecnej struktury działalności i
zasobów firmy.

6

Z celów analizy strategicznej wynika jej zakres. Obejmuje on następujące obszary:

1.

cele i oczekiwania ludzi oraz grup związanych z organizacją (obecne i ewentualne zmiany).

2.

zasoby organizacji (posiadane oraz dostępne),

3.

otoczenie dalsze i bliższe organizacji (obecne oraz przyszłe).

Zakres i metody analizy strategicznej zależą w znacznej mierze od:

1.

wizji strategii rozwoju firmy,

2.

sytuacji przedsiębiorstwa,

3.

cech przedsiębiorstwa (np. zdywersyfikowane, wyspecjalizowane, duże, małe),

4.

modelu otoczenia,

5.

zakresu zmian otoczenia

12.

Jaką rolę w organizacjach odgrywa system informacyjny?

System informacyjny w organizacji pełni kilka zasadniczych ról :

a.

stanowi główne źródło informacji, które umożliwiają wykonanie działań kształtujących bieżącą

sytuację przedsiębiorstwa i jego dalszy rozwój,

b.

zapewnia interakcje między systemem zarządzania, a systemem wykonawczym (produktów i

usług),

c.

wpływa na poziom kosztów ponoszonych na podjętą przedsiębiorczość przez sprzężenia

zwrotne, które umożliwiają podejmowanie działań korygujących zadania decyzyjne bądź
komunikowanie się między nadawcami i odbiorcami informacji,

d.

przyczynia się do rozwoju konkurencyjnych produktów i usług, które mogą zapewnić

przedsiębiorstwu strategiczną przewagę na światowym rynku,

e.

jest cennym „bogactwem” każdego przedsiębiorstwa, przyczynia się bowiem do znalezienia

nowych, dotąd nieznanych zasobów materialnych.

13.

Co składa się na sprawnie funkcjonujący system informacyjny?

Dobrze zorganizowany system informacyjny powinien spełniać następujące warunki:

●

musi być dostosowany do potrzeb i obejmować wszystkie dziedziny działalności przedsiębiorstwa,
wszystkie szczeble kierownicze i poziomy decyzyjne;

●

musi dostarczać informacji kompleksowych i aktualnych pozwalających firmie na szybką reakcję
na zmianę warunków wewnętrznych i zewnętrznych;

●

musi dostarczać decydentom informacji nadającej się bezpośrednio do użytku i najdogodniejszej
dla podjęcia ostatecznej decyzji;

●

droga przepływu informacji powinna być zgodna z strukturą organizacyjną i możliwie najkrótsza;

●

koszty pozyskiwania i przetwarzania informacji powinny być niewysokie, metody ich zbierania,
przechowywania i przepływu powinny uwzględniać możliwości komputeryzacji systemu
informacyjnego, a forma prezentacji powinna być czytelna i przystępna dla zainteresowanych;

●

system ten powinien być odpowiednio zabezpieczony oraz ciągle doskonalony.

14.

Jakie są relacje pomiędzy systemem informacyjnym a systemem informatycznym?

System informatyczny jest składnikiem (czasem ważniejszym, a czasem mniej ważnym) systemu

informacyjnego. Jednak system informacyjny może istnieć (i zwykle wcześniej istnieje) bez techniki
informatycznej, natomiast nawet najlepsza informatyka bez dobrze zorganizowanego systemu
informacyjnego – nic nie daje.

7

15.

Struktury systemu informatycznego

Struktura funkcjonalna:

- Podział systemu na moduły
- Określenie procesów podstawowych i
pomocniczych

Struktura informacyjna:

- Określenie logicznych struktur danych
- Określenie zasad kodowania danych

Struktura techniczno-technologiczna:

- Typy sprzętu komputerowego
- Technologia przetwarzania
- Oprogramowanie systemowe

Struktura przestrzenna:

- Topologia punktów przetwarzania
- Topologia sieci komputerowej
- Oprogramowanie sieciowe

16.

Luka informacyjna i jej znaczenie

Powstaje pomiędzy ilością informacji pożądanych a dostępnych. Oznaczają informacje pożądane,
aczkolwiek niedostępne. Luka powiększa się wraz ze wzrostem złożoności problemu i ilości informacji,
determinuje potrzebę podjęcia działań mających na celu pozyskanie odpowiednich danych.
Luka informacyjna może oznaczać zapotrzebowanie na informacje bardziej aktualne czy bardziej
szczegółowe niż te, którymi dysponuje się w danej chwili, lub na informacje, których w ogóle do tej pory
nie gromadzono.

17.

Jakie są składniki metodyki TSI i zależności między nimi?

●

modele opisu rzeczywistości, czyli dziedziny przedmiotowej, jej statyki i dynamiki, zwane modelami

konceptualnymi

●

strukturyzacja procesu TSI w postaci sekwencji etapów, podetapów i poszczególnych zadań (w

postaci cyklu życia systemu)

●

szczegółowe metody i techniki TSI, czyli jego dokumentowanie wraz z odpowiednią symboliką

●

narzędzia wspomaganego komputerowo TSI, określane mianem CASE

●

specyfikacja wymagań merytorycznych wobec zespołów projektowo-wykonawczych

●

kryteria oceny jakości projektu i systemu wraz z mechanizmami jej kontroli

8

18.

Czym różnią się metodyki strukturalne, obiektowe, społeczne i adaptacyjne?

Metodyka strukturalna

Metodykę tę cechuje rozdzielność procesów i danych. Przy jej zastosowaniu występują trudności w
utrzymaniu modeli w trakcie życia systemu (problemy z inżynierią odwrotną np. w przypadku
konieczności naprawy wykrytego błędu) oraz czasochłonne tworzenie wielopoziomowych DFD.

Jest stosowana dla systemów informacyjnych organizacji, lub dla dobrze widocznej dziedziny
problemowej. W odróżnieniu od obiektowej jest prostsza do zrozumienia. Cechuje ją rozdzielność
procesów i danych.

Metodyka obiektowa

charakteryzuje się łatwym przejściem z etapu projektowania do kodowania, brakiem problemów z
inżynierią odwrotną i dużą złożonością oraz trudnością w opanowaniu oraz posługiwaniu się (w
porównaniu do metodyki strukturalnej).

Metodyka strukturalna

Metodyka obiektowa

1. Określenie wymagań

1. Określenie wymagań

2. Specyfikacja (analiza) ( scenariusz /
diagramy)

->co system ma robić

2. Analiza obiektowa

-> co system ma robić; wyodrębnienie
obiektów

3. Projektowanie strukturalne

->Projekt architektury systemu (podział na
moduły). Szczegółowy projekt modułów.

3. Projektowanie obiektowe

-> Szczegółowy projekt obiektów.

4. Implementacja (programowanie)
-> Wybrany język projektowania

4. Programowanie obiektowe

-> Obiektowy język projektowania

5. Scalanie

5. Scalanie

6. Konserwacja

6. Konserwacja

Wytłuszczone wiersz ukazują różnice między metodykami.

Metodyka społeczna

Akcentuje aspekty humanitarne i społeczne – psychologiczne i socjologiczne – w tworzeniu
systemów informatycznych. Podejście to jest użyteczne w fazie planowania systemów
informatycznych.

Metodyka adaptacyjna

Podejście adaptacyjne zakłada zasadniczą trudność w zrozumieniu i identyfikacji potrzeb
informatycznych i założeń systemu, a w konsekwencji możliwość i akceptację ich zmian, modyfikacji
oraz adaptacji w procesie tworzenia systemu. W odróżnieniu od innych metodyk, które wdrażają
system w końcowych fazach cyklu, tutaj jest on wdrażany przyrostowo, sekwencyjnie w procesie TSI.

9

19.

Co to jest cykl życia systemu?

Cykl życia systemu jest to strukturalne podejście do zadania opracowania systemu dla
przedsiębiorstwa.
Tradycyjny model cyklu życia systemu
Analiza potrzeb

→ Specyfikacja systemu

→ Projektowanie

→ Programowanie

→ Testowanie

→ Integracja

→ Adaptacja i modyfikacja

→ Eksploatacja

→ Dezaktualizacja

Poszczególne etapy następują po sobie w określonej, zstępującej sekwencji.
Każdy etap powinien być zakończony przed rozpoczęciem następnego.

20.

Wymień i opisz rodzaje cykli życia systemu.

Model kaskadowy

Specyfikacja wymagań

→

→

Projektowanie

Implementacja

→

→

Testowanie

Wdrożenie

Zalety:
-

ułatwia

organizację:

planowanie,

harmonogramowanie,

monitorowanie

przedsięwzięcia- zmusza do zdyscyplinowanego
podejścia
- wymusza kończenie dokumentacji po każdej fazie
- wymusza sprawdzenie każdej fazy przez SQA

Wady:
- narzuca twórcom oprogramowania ścisłą
kolejność wykonywania prac
- występują trudności w sformułowaniu wymagań
od samego początku
- powoduje wysokie koszty błędów popełnionych
we wczesnych fazach,
- powoduje długie przerwy w kontaktach z
klientem.
- brak jest weryfikacji i elastyczności
- możliwa jest niezgodność z faktycznymi
potrzebami klienta
- niedopasowanie - rzeczywiste przedsięwzięcia
rzadko są sekwencyjne
– realizatorzy kolejnych faz muszą czekać na
zakończenie wcześniejszych

Model spiralny

Zalety:
- Do dużych systemów - szybka reakcja na
pojawiające się czynniki ryzyka
- Połączenie iteracji z klasycznym modelem
kaskadowym

Wady:
- Trudno do niego przekonać klienta
- Konieczność umiejętności szacowania ryzyka
– Problemy, gdy źle oszacujemy ryzyko

Model Ewolucyjny

Zalety:
– dobry dla małych projektów, szybki start
projektu
– tolerancja dla słabo zdefiniowanych
wymagań– niski koszt błędów (krótki czas życia
błędów)

Wady:
– trudność z harmonogramowaniem
– koszty prototypowania, błądzenia
– systemy często o złej strukturze

10

21.

Podstawowe fazy liniowego cyklu życia systemu, ich kolejność i istota

Fazy:

●

Określenia wymagań – określane są cele oraz szczegółowe wymagania dotyczące

tworzonego systemu.

●

Projektowanie – powstaje szczegółowy projekt systemu spełniający ustalone wcześniej

wymagania.

●

Implementacja oprogramowania – projekt zostaje zaimplementowany w konkretnym

środowisku programistycznym oraz wykonywane są testy poszczególnych modułów

●

Integracja i testowanie SI – integrowanie poszczególnych modułów połączone z

testowaniem poszczególnych podsystemów oraz całego SI.

●

Utrzymanie(Konserwacja) – oprogramowanie wykorzystywane jest przez użytkowników, a

producent dokonuje konserwacji SI – wykonuje ulepszenia i usuwa błędy

22.

Liniowy a spiralny cykl życia systemu

Model liniowy(kaskadowy)
Cykl życia składa się z następujących faz :

- fazę określenia wymagań;
- fazę projektowania;
- fazę implementacji/kodowania;
- fazę testowania;
- fazę eksploatacji i konserwacji.

Zalety (ułatwia organizację: planowanie, harmonogramowanie, monitorowanie przedsięwzięcia;
zmusza do zdyscyplinowanego podejścia; wymusza kończenie dokumentacji po każdej fazie)
Wady (narzuca twórcom oprogramowania ścisłą kolejność wykonywania prac; występują trudności w
sformułowaniu wymagań od samego początku; powoduje wysokie koszty błędów popełnionych we
wczesnych fazach; powoduje długie przerwy w kontaktach z klientem; realizatorzy kolejnych faz muszą
czekać zakończenie wcześniejszych.

Model spiralny; iteracyjny w zakresie kompleksowych właściwości
Projekt ten zawiera niespotykaną w innych modelach - analizę ryzyka. Cykl spiralny rozpoczyna się od
planowania, a następnie wchodzi w fazę analizy ryzyka. W tej fazie najpierw analizuje się wstępne
wymagania. W trzeciej fazie w pierwszym przebiegu spirali buduje się początkowy prototyp systemu i
przekazuje go użytkownikowi do fazy czwartej. Po weryfikacji systemu (prototyp + uwagi) wraca do fazy
pierwszej i rozpoczyna się następny przebieg spirali. Po kolejnych kilku przebiegach system powinien
przyjąć oczekiwaną postać.
Zalety (do dużych systemów-szybka reakcja na pojawiające się czynniki ryzyka; połączenie iteracji z
klasycznym modelem kaskadowym)
Wady (trudno do niego przekonać klienta; konieczność umiejętności szacowania ryzyka; problemy, gdy
źle oszacujemy ryzyko).

W modelu liniowym wytwórca oprogramowania stara się przedstawić produkt finalny po wcześniejszej
długotrwałej zgodnej z harmonogramem pracy.

Model spiralny z racji ogólnego charakteru stosuje się przy dużych projektach. W modelu spiralnym nie
ma takich faz jak specyfikowanie albo projektowanie. Jeden cykl spirali może przebiegać w oparciu o
model kaskadowy procesu tworzenia oprogramowania, w innym można użyć prototypowania lub
przekształceń formalnych, jest bardziej elastyczny względem modelu liniowego.

11

23.

Na czym polega analiza ryzyka w spiralnym modelu cyklu życia systemu.

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ą na podstawie wymagań wstępnych i reakcji użytkownika.

24.

Interpretacja iteracyjno-przyrostowego cyklu życia systemu. Fazy i dyscypliny.

Iteracyjno - przyrostowy cykl życia systemu jest elementem metodyki RUP
Ma postać dwuwymiarową. Istota cyklu iteracyjno-przyrostowego opiera się na zależnościach pomiędzy
dyscyplinami a fazami.
Dyscyplina jest kolekcją powiązanych czynności, artefaktów, ról oraz przypływów pracy.

Dyscypliny stanowią rdzeń tworzenia systemu. Należą do nich:

●

Modelowanie biznesowe

●

Specyfikacja wymagań

●

Analiza i projektowanie

●

Programowanie

●

Testowanie

●

Wdrożenie

Faza to okres miedzy kolejnymi punktami przeglądu cyklu iteracyjno-przyrostowego
Rozróżnia się fazy:

●

Rozpoczęcie 10% czasu

●

Opracowanie 30 %

●

Budowa 50%

●

Przekazanie 10%

12

25.

Podstawowe kategorie pojęciowe i graficzne diagramów przepływu danych

●

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

26.

Opracuj diagram przepływu danych obsługi sesji egzaminacyjnej

13

27.

Modelowanie systemów przy użyciu diagramów przypadków użycia

Diagram przypadków to graficzne przedstawienie przypadków użycia, aktorów oraz związków
między nimi, występujących w danej dziedzinie przedmiotowej.

Diagram przypadków użycia w języku UML służy do modelowania funkcjonalności systemu. Tworzony
jest zazwyczaj w początkowych fazach modelowania. Diagram ten stanowi tylko przegląd możliwych
działań w systemie, szczegóły ich przebiegu są modelowane za pomocą innych technik.

Diagram przypadków użycia przedstawia usługi, które system świadczy aktorom, lecz bez wskazywania
konkretnych rozwiązań technicznych.

Cele stosowania diagramów przypadków użycia:

- identyfikacja oraz dokumentacja wymagań,
- umożliwiają analizę obszaru zastosowań, dziedziny przedmiotowej,
- pozwalają na opracowanie projektu przyszłego systemu,
- stanowią przystępną i zrozumiałą platformę współpracy i komunikacji twórców systemu,
inwestorów i właścicieli,
- są rodzajem umowy, kontraktu pomiędzy udziałowcami co do zakresu i funkcjonalności przyszłego
systemu,
- stanowią podstawę testowania funkcji systemu na dalszych etapach jego cyklu życia.

28.

Opracuj diagram przypadków użycia dla obsługi sesji egzaminacyjnej

14

29.

Opracuj diagram przypadków użycia dla obsługi międzynarodowej konferencji naukowej

30.

Opracuj diagram przypadków użycia dla obsługi serwisu linii lotni

15

31.

W jaki sposób tworzone są scenariusze i jaką odgrywają one rolę

Scenariusz to dokumentacja przypadku użycia, przedstawiająca wiele istotnych informacji, które są
niezbędne w realizacji dalszych faz cyklu życia systemu.
Dla danego przypadku użycia zawsze należy wyróżnić scenariusz główny (możliwe są również
scenariusze alternatywne).
Oba te scenariusze (główny i alternatywny) precyzyjnie opisują pełną funkcjonalność danego przypadku
użycia.
Prowadzenie konsekwentnej dokumentacji przypadków użycia prowadzi do odnajdywania nieścisłości i
przeoczeń powstałych podczas tworzenia wstępnej wersji diagramu przypadków użycia.

Przy tworzeniu scenariusza przypadku użycia trzeba podać:

Nazwa – pełna nazwa przypadku użycia.
Numer – numer identyfikacyjny przypadku użycia.
Twórca – dane twórcy przypadku użycia, np. imię, nazwisko, stanowisko.
Typ przypadku użycia – określenie typu z punktu widzenia jego złożoności (np.

ogólny/szczegółowy)

oraz

ważności

dla

zaspokojenia

potrzeb

użytkownika(np.

niezbędny/istotny/przeciętnie istotny/mało istotny).

Aktorzy – lista aktorów będących w związku z przypadkiem użycia.
Krótki opis – krótka, ogólna charakterystyka przypadku użycia.
Warunki wstępne – Charakterystyka koniecznych warunków inicjujących przypadek.
Warunki końcowe – charakterystyka stanu systemu po realizacji przypadku użycia.
Główny przepływ zdarzeń – wypunktowana i scharakteryzowana lista przepływów zdarzeń

zachodzących podczas realizacji przypadku użycia; scenariusz główny.

Alternatywne przepływy zdarzeń - wypunktowana i scharakteryzowana lista możliwych,

alternatywnych przepływów zdarzeń przypadku użycia.

Specjalne

wymagania

-

wypunktowana

i

scharakteryzowana

lista

dodatkowych

zidentyfikowanych wymagań niefunkcjonalnych, które mogą być istotne przykładowo podczas
projektowania czy kodowania.

Notatki i kwestie – lista wszelkich komentarzy dotyczących przypadku użycia i lista pozostałych

otwartych kwestii, które powinny zostać rozwiązane wraz z propozycjami osób, które mogłyby je
rozwiązać.

32.

Składniki pakietu CASE

Słowniki danych (repozytoria) – bazy wszelkich danych o tworzonym systemie wraz z narzędziami

edytującymi, zarządzającymi i wyszukującymi te dane.

Edytor Notacji Graficznych – program graficzny, umożliwiający tworzenie i edycję diagramów dla

faz określania wymagań systemu, analizy i projektowania. Powinien też umożliwiać powiązania
między symbolami w modelu a innymi, zdekomponowanymi modelami, oraz wydruk tych
diagramów.

Moduł Kontroli Poprawności – narzędzie do wykrywania i poprawiania błędów w diagramach i

repozytoriach. Bardzo często działa w czasie rzeczywistym, co znacząco wpływa na komfort pracy.

Moduł Kontroli Jakości – narzędzie do oceny pewnych ustalonych miar jakości projektu – np.

stopnia złożoności lub powiązań składowych modelu.

Generator Raportów – narzędzie tworzące dowolny raport na podstawie danych z repozytorium.
Generator Kodu – narzędzie transformujące projekt na szkielet kodu w wybranym języku

programowania. Usprawnia pracę programistów, pozwala na zautomatyzowanie pewnych
fragmentów kodu, a także na uzupełnienie kodu o dodatkowe informacje ze słownika danych.

Generator Dokumentacji Technicznej – generator ustandaryzowanych dokumentów,

zawierających specyfikację, opisy faz projektu, diagramy oraz wybrane raporty.

Moduł Projektowania Interfejsu Użytkownika – narzędzie do projektowania menu, okien

dialogowych oraz innych elementów interfejsu użytkownika.

Moduł Inżynierii Odwrotnej – narzędzie pozwalające odtworzyć słownik danych oraz diagramy, na

podstawie kodu źródłowego lub struktury bazy danych.

Moduł Importu/Eksportu Danych – narzędzie służące do wymiany danych z innymi CASE'ami czy

też innymi programami.

Moduł Zarządzania Pracą Grupową – narzędzie umożliwiające współpracę grupy osób podczas

pracy nad projektem.

16

33.

Rodzaje pakietów CASE

Systemy CASE można podzielić według faz cyklu życia systemu na: Upper-CASE i Lower-CASE

(czasami również Middle-CASE i Integrated CASE).

Upper-CASE:

o Wspomaganie wczesnych faz prac nad oprogramowaniem: analizę organizacyjną, funkcjonalną i
procesową, modelowanie funkcji, procesów, obiektów, modelowanie struktur(potrzeby analityków i
projektantów), tworzenie wszelkich diagramów
o Przeznaczone bardziej do opisu i modelowania rzeczywistości i struktury systemu, bez wszelkich
faz implementacji
o Narzędzia te nie są związane z konkretnym środowiskiem implementacyjnym

Lower-CASE:

o Wspomaganie faz projektowania i implementacji(potrzeby programistów)
o Wspomaga modelowanie bazy danych, generowanie kodu i testy
o Narzędzia te są z reguły ściśle związane z konkretnym środowiskiem implementacji
o Opierają się na obserwacji, że notacje graficzne są bardziej naturalnym sposobem prezentacji
dużych programów, niż tradycyjny zapis tekstowy
o Dzięki temu nie jest konieczne zapisywanie w całości kodu programu ręcznie
o Programista posługuje się symbolami graficznymi, które odpowiadają konkretnym, łatwo
wyróżnialnym, konstrukcjom programistycznym
o Dodatkowo dostępne są funkcje dialogowej edycji atrybutów konstrukcji

Integrated CASE (I-CASE) - Pakiety łączące w sobie możliwości narzędzi Upper i Lower CASE

Middle-CASE – pozwalają określić samą strukturę systemu informatycznego

34.

Jak jest definiowane pojęcie obiektu? Proszę podać przykłady obiektów występujących w
dziedzinie problemowej „uczelni wyższej”

Obiektem jest każdy byt - pojęcie lub rzecz - mający znaczenie w kontekście rozwiązywania problemu

w danej dziedzinie przedmiotowej. Dwa obiekty są - tak jak w rzeczywistości - dwoma unikalnymi,
oddzielnymi obiektami (bytami), nawet jeśli posiadają dokładnie takie same cechy,. Obiekty są
odróżnialne poprzez swoje istnienie, a nie cechy opisowe. Każdy obiekt stanowi oddzielny moduł czy
kapsułę i zawiera dane i procesy, umożliwiające odgrywanie określonej roli w rzeczywistym systemie.
Obiekt różni się więc od encji pojęciem dynamicznych aspektów systemu. Wszystko co wiadomo o
obiekcie, zawarte jest w jego atrybutach (zwanych też zmiennymi), a wszystkie interakcje wyrażone
są w metodach. Dzięki temu można modyfikować zakres atrybutów i metod danego obiektu bez
skutku dla innych obiektów w systemie.

Przykłady: BILANS, PRACOWNIK, SALA, STUDENT, ZAJĘCIA, EGZAMIN itp.

35.

Jaka jest różnica pomiędzy obiektem a klasą?

Klasa obiektu jest uogólnieniem danego rodzaju obiektu.
Obiekty o tej samej strukturze danych tj. takich samych atrybutach oraz takim samym zachowaniu tj.

takich samych metodach, zgrupowane są w klasę obiektów. Opisuje ona wspólne cechy określonego
zbioru poszczególnych obiektów. Każdy obiekt staje się wystąpieniem danej klasy obiektów. Klasy
definiują te aspekty obiektu, które są identyczne dla wszystkich wystąpień tej klasy.

36.

Krótko scharakteryzuj koncepcję związku generalizacji-specjalizacji.

Generalizacja oznacza budowanie pojęć bardziej ogólnych na podstawie pojęć bardziej

szczegółowych.

Specjalizacja jest budowaniem pojęć bardziej szczegółowych wywodzących się z pojąć bardziej

ogólnych.

Pojęcia te odnoszą się do diagramów: klas, obiektów oraz przypadków użycia.

17

37.

Co to jest metoda abstrakcyjna i w jaki celu jest wykorzystywana?

Metoda abstrakcyjna nie posiada implementacji - jest jedynie zapowiedzią realizacji w klasach

potomnych. Klasa zawierająca minimum jedną metodę abstrakcyjną nazywana jest klasą
abstrakcyjną. Używamy jej w celu wymuszenia istnienia danej metody w klasach pochodnych.

38.

Czy klasa abstrakcyjna może być liściem w hierarchii dziedziczenia klas?

Klasa abstrakcyjna nie może być liściem w hierarchii dziedziczenia klas. Posiada ona bowiem

(minimum jedną) metodę abstrakcyjną, nie posiadającą implementacji i z założenia nie jest możliwe
tworzenie obiektów takiej klasy. Klasa abstrakcyjna może występować jedynie jako klasa nadrzędna
tzn. być tylko i wyłącznie węzłem (nie liściem) w hierarchi dziedziczenia klas.

39.

Jaka jest różnica pomiędzy powiązaniem a asocjacją?

Powiązanie - Relacja zachodząca między obiektami, odwzorowująca fizyczny lub pojęciowy związek

istniejący między odpowiednimi bytami w analizowanej dziedzinie problemowej.

Asocjacja - Opis grupy powiązań posiadających wspólną semantykę i strukturę. Powiązanie jest

wystąpieniem asocjacji.

Asocjacje mogą też łączyć więcej niż dwie klasy (asocjacje n-arne).

40.

Rodzaje asocjacji, przykłady

Jeden do jednego – instancja może mieć tylko jedną

więź w danym związku

Jeden do wielu – instancja może mieć wiele
więzi w danym związku.
Jednak ta instancja, która jest z nią
powiązana już nie może mieć więzi
więcej niż jedną
Wiele do wielu – zarówno instancja
jak i instancje z nią powiązane mogą mieć
wiele więzi w danym związku.

Specjalne typy asocjacji:

Agregacja – relacja typu całość – część. Jest to relacja antysymetryczna. Oznacza to że element całości

zawiera elementy części, lecz element części nie mogą zawierać elementów całości.

Kompozycja – silniejsza forma – w agregacji elementy mogą być wykorzystane przez inne elementy a

w kompozycji żaden element – część nie może być dzielony, dlatego z chwilą zniszczenia elementu
całości ulega zniszczeniu element – część.

18

41.

Krótko omów podstawowe rodzaje stanów: prosty, złożony, początkowy, końcowy

Prosty- stan nie posiadający podstanów (czyli innych stanów wchodzących w jego skład)
Złożony sekwencyjny- stan złożony z jednego lub więcej podstanów; tylko jeden z podstanów jest

aktywny wówczas, gdy jako całość aktywny jest stan złożony

Złożony współbieżny- stan podzielony na dwa lub więcej współbieżnych podstanów; wszystkie

podstany są jednocześnie aktywne wówczas, gdy jako całość aktywny jest stan złożony

Początkowy- pseudostan (tzn. stan pełniący tylko funkcje pomocnicze) służący do oznaczenia punktu

startowego (początku istnienia obiektu w systemie)

Końcowy- pseudostan służący do oznaczenia punktu finalnego (końca istnienia obiektu w systemie)

42.

Krótko omów zasadniczy cel konstruowania diagramów aktywności, diagramów
integracji, diagramów implementacyjnych

Najbardziej podstawowym z powyższych diagramów jest diagram aktywności. Określa on w jaki
sposób system będzie osiągał wyznaczone przypadkami użycia cele. [Jakie akcje? Jak są ze sobą
połączone?] Stosuje się je w modelowaniu, np. scenariuszy przypadków użycia. Pokazują aktywności
bez pokazywania bytów, realizujących daną aktywność i dlatego z reguły używane są jako
punkt startowy dla procesu modelowania zachowań. Kolejnym etapem opisywania dynamiki systemu
jest wprowadzenie diagramów interakcji. Opisują one sposób w jaki obiekty współpracują ze
sobą w celu zrealizowania konkretnej funkcji systemu (przypadku użycia lub scenariusza danego
przypadku użycia). Pozwalają na lepsze zrozumienie zdarzeń zachodzących pomiędzy nimi. Stanowią
precyzyjny opis pojedynczego przypadku użycia. Ostatnim z diagramów jest diagram
implementacyjny. Stanowi on podstawę opracowania specyfikacji programistycznej.
Jest to diagram bardzo precyzyjny opisujący wszystkie możliwe przepływy scenariusza
przypadku użycia.
Krócej mówiąc celem diagramów aktywności, interakcji i implementacyjnych jest opisanie dynamiki
systemu od przypadku biznesowego [najbardziej ogólnego] do opisu istotnego dla programisty
[szczegółowego].

43.

Wymień i omów rodzaje diagramów implementacyjnych

UML definiuje dwa rodzaje diagramów implementacyjnych:

●

Diagramy komponentów - ilustrują strukturę kodu projektowanego systemu poprzez

specyfikowanie implementacji elementów projektu (np. klas czy podsystemów) za pomocą
komponentów i ich interfejsów, oraz wskazanie zależności występujących pomiędzy
komponentami. Celem identyfikacji komponentów jest budowa systemów o odpowiednio
wysokiej jakości, wypełniających pożądane potrzeby biznesowe i budowanych szybko.

●

Diagramy wdrożeniowe - pokazują konfigurację systemu czasu wykonania, czyli

rozmieszczenie komponentów i obiektów na węzłach. Węzły modelują obliczeniowe zasoby czasu
wykonania. Taka konfiguracja może być zarówno statyczna, jak i dynamiczna: komponenty i
obiekty mogą migrować między węzłami w czasie wykonania.

19

44.

Kiedy i w jakich sytuacjach i w jakim celu wykorzystywane są diagramy pakietów? Jakie
rodzaje związków mogą występować między pakietami?

Diagramy pakietów służą do modelowania fizycznego i logicznego podziału systemu. Diagram
pakietów ułatwia zarządzanie, służy do tego, by uporządkować strukturę zależności w systemie, który
ma bardzo wiele klas, przypadków użycia, interfejsów itp. Zwiększa to czytelność systemu.

Diagramy pakietów połączone są licznymi związkami:

-Pakiet

-Zależność

-Scalenie zawartości pakietu

-Przejmowanie zawartości pakietu

-Zagnieżdżanie pakietów

-Uogólnienie

45.

Objaśnij pojęcia: aktor biznesowy, biznesowy przypadek użycia, pracownik biznesowy,
encja biznesowa

Aktor biznesowy - Rola pełniona przez użytkownika działającego w otoczeniu organizacji; Rola kogoś

lub czegoś, jaka występuje w interakcji z organizacją.

Pracownik biznesowy - Pracownik lub system funkcjonujący w ramach organizacji, pełniący

określoną rolę lub zestaw ról wewnątrz procesu biznesowego. Współpracuje z innymi pracownikami
biznesowymi i wykonuje działania oparte na obiektach biznesowych klas przechowujących.

Biznesowy przypadek użycia - Proces biznesowy, dostarczający wyników istotnych z punktu

widzenia aktora biznesowego.

Encja biznesowa - reprezentuje materialny lub finansowy zasób czy też cokolwiek innego, czym

organizacja zarządza lub co wytwarza.

46.

Objaśnij różnicę między modelami przypadków użycia w modelowaniu biznesowym i w
modelowaniu systemowym

Modelowanie systemowe jest ukierunkowane na tworzenie SI, jego oprogramowania oraz

infrastruktury sprzętowej natomiast modelowanie biznesowe to zdefiniowane w dyscyplinie
modelowania biznesowego procesy biznesowe, które są w naturalny sposób wspomagane przez SI, a
ich część na pewnym etapie tworzenia systemów informatycznych ulega transformacji w procesy
systemowe

Modelowanie biznesowe to praktyka stosowana z powodzeniem przez wiele współczesnych

przedsiębiorstw. Służy do opisu wszystkiego, co składa się na daną organizację .

W procesie wytwarzania oprogramowania jest pierwszym etapem z jakim spotykają się twórcy
oprogramowania, gdyż model biznesowy to opis rzeczywistej firmy lub instytucji.

Modelowanie biznesowe pozwoli zrozumieć czym zajmuje się dane przedsiębiorstwo. Zasadniczym
celem budowy modelu biznesowego jest utworzenie takiego obrazu organizacji, który będąc opisem
rzeczywistości stanie się podstawą szkieletu aplikacji (opisem tego szkieletu).

Modelowanie biznesowe jest sposobem odwzorowywania i dokumentowania procesów biznesowych.
Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy i
projektowania systemów informatycznych.

20

47.

Jakie są podstawowe różnice pomiędzy fazami analizy i projektowania

Faza analizy to logiczny model systemu, opisujący sposób realizacji przez system postawionych
wymagań, lecz abstrahujących od szczegółów implementacyjnych. Model oprogramowania powinien
być jego uproszonym opisem, opisującym wszystkie istotne cechy oprogramowania na wysokim
poziomie abstrakcji.
Natomiast faza projektowania to proces transformacji wymagań na postać wykonywalną. Celem fazy
projektowania jest udzielenie odpowiedzi na pytanie: Jak system ma być zaimplementowany?
Wynikiem fazy projektowania jest opis sposobu implementacji.

48.

Podstawowe zasady obiektowości

Obiektowość, orientacja obiektowa – sposób definiowania programów za pomocą obiektów oraz
klas. Podejście obiektowe jest zbliżone do procesu ludzkiego myślenia stąd upraszcza ono proces
projektowania, tworzenia oraz wprowadzania zmian w systemie [programowanie obiektowe].
Obiektowość można także wykorzystać podczas analizy [analiza obiektowa].

●

Obiektowość powstała z potrzeby łatwiejszego sposobu symulowania systemów – nie tylko

symulowania systemów informatycznych, lecz dowolnych rodzajów systemów.

●

Obiektowość dostarcza metodę do tworzenia dowolnych systemów – niezależnie od tego, jak te

systemy będą implementowane. Ponadto tej samej obiektowej specyfikacji można użyć w wielu
innych dziedzinach, niezależnie od tego czy dotyczą one ludzi, maszyn lub komputerów.

Podstawowe koncepcje obiektowości

● abstrakcja – odfiltrowanie atrybutów i operacji nieistotnych
● enkapsulacja – ukrycie nadmiernego poziomu szczegółowości
● dziedziczenie – generalizacja

⊲ relacja hierarchiczna
⊲ oszczędność nakładów modelowania

● polimorfizm – wielość form operacji dla dziedziczonych klas

⊲ wirtualny mechanizm wywoływania funkcji
⊲ naturalny system wyrażania czynności
⊲ zmniejszenie nakładów programowania.

49.

Architektura oprogramowania i jej rola. Istota architektury trójpoziomowej i
czteropoziomowej

Architektura oprogramowania –podstawowa organizacja systemu. Zawiera m.in. jego

komponenty i wzajemne powiązania. Pozwala na porozumiewanie się wszystkich osób
zaangażowanych w projekt.

Architektura trójwarstwowa - Twórcy SI starają się tak zaprojektować architekturę, aby

odseparować silnie zależne od technologii i narzędzi programistycznych interfejs użytkownika i bazę
danych od logicznych i pojęciowych, odnoszących się bezpośrednio do rozwiązywanego problemu,
zagadnień. Architektura trójwarstwowa, której standard został wprowadzony w 1978 przez komitet
ANSI/SPARC, proponuje podział systemu na trzy poziomy: jego fizyczną implementację (tzw.
„schemat

wewnętrzny”),

abstrakcyjny

model

wycinka

rzeczywistości

(biznesu,

firmy)

odzwierciedlanej przez system (tzw. „schemat pojęciowy”) oraz poziom zewnętrzny, reprezentujący
sposoby, w jakie system jest postrzegany z zewnątrz (tzw. „schematy zewnętrzne”).

Architektura czterowarstwowa - Warstwy na diagramie są od siebie zależne – komunikują się ze

sobą. Zasadą jest, że komunikacja następuje tylko między warstwami sąsiadującymi. Bardzo ważny w
szkielecie jest również kierunek komunikacji. Warstwa logiki środowiska nie jest np. zależna i nie
uruchamia komunikacji z warstwą logiki aplikacji, natomiast istnieje zależność odwrotna. Wynika to
z tego, że czynności na poziomie logiki środowiska nie wymagają uruchamiania jakiejś
funkcjonalności na poziomie aplikacji. Warstwa logiki aplikacji musi się natomiast komunikować
zarówno z logiką środowiska, jak i ze stykiem z użytkownikiem.

21

50.

Zasady projektowania interfejsu użytkownika

Reguła 1: umieszczać etykiety zawsze nad lub obok pól edycyjnych.
Reguła 2: umieszczać typowe pola takie jak np. OK i Anuluj zawsze od dołu lub od prawej.
Reguła 3: starać się zachować spójność tłumaczeń nazw angielskich, spójność oznaczania pól.
Reguła 4: okna dialogowe powinny obrazować przepływ danych pomiędzy użytkownikiem a systemem

i odzwierciedlać metody oraz procesy, które zgodnie ze specyfikacją służą do edycji obiektów, encji
lub zbiorników danych.

Reguła 5: dla typowych i często stosowanych poleceń należy projektować dostęp za pomocą skrótów

klawiaturowych.

Reguła 6: pamiętać o potwierdzeniach przyjęcia zlecenia użytkownika. Realizacja niektórych zleceń

może trwać długo. W takich sytuacjach należy potwierdzić przyjęcie zlecenia, aby użytkownik nie był
zdezorientowany odnośnie tego, co się dzieje. Dla długich czynności konieczne jest wykonywanie
sporadycznych akcji na ekranie.

Reguła 7: zapewnić prostą obsługę błędów. Jeżeli użytkownik wprowadzi błędne dane, to po sygnale

błędu system powinien automatycznie przejść do kontynuowania przez niego pracy z poprzednimi
poprawnymi wartościami.

Reguła 8: zapewnić możliwość odwoływania akcji. W najprostszym przypadku jest to możliwość

cofnięcia ostatnio wykonanej operacji.

Reguła 9: dążyć do zapewnienia użytkownikowi wrażenia kontroli nad systemem. Użytkownicy nie

lubią, kiedy system sam robi coś, czego użytkownik nie zainicjował, lub kiedy akcja systemu nie daje
się przerwać.

Reguła 10: tak organizować interfejs, aby nie obciążać pamięci krótkotrwałej użytkownika.
Reguła 11: grupować powiązane operacje. Jeżeli zadanie nie da się zamknąć w prostym dialogu,

wówczas trzeba je rozbić na szereg powiązanych dialogów.

Reguła 12: stosować regułę Millera 7 +/-2. (człowiek może się jednocześnie wydajnie skupić na 5-9

elementach)

51.

Rodzaje zagrożeń w projekcie informatycznym

Zagrożenia projektowe mogą spowodować przekroczenie terminów lub budżetu, które mogą mieć
negatywny wpływ na postęp prac. Także wielkość i złożoność systemu stanowią o wielkości ryzyka
projektowego.
Zagrożenia techniczne wpływają na jakość produktów i ich terminowość. Pod czas tego zagrożenia
stworzenie oprogramowania okaże się trudne lub niemożliwe. Problemy te mogą być trudniejsze do
rozwiązania niż to się wcześniej wydawało.
Zagrożenia ekonomiczne mogą utrudnić osiągnięcie rynkowego sukcesu oprogramowania.

Pięć najważniejszych takich zagrożeń to:

● powstanie doskonałego produktu, którego nikt nie potrzebuje
● powstanie produktu, który nie odpowiada ludziom
● powstanie produktu, którego firma nie będzie umiała sprzedać,
● utrata zainteresowania kierownictwa
● zmniejszenie budżetu lub liczby pracowników

Zagrożenia znane to te, które można wykryć na podstawie dokładnej analizy środowiska, w którym
będzie powstawał produkt. Przykładami takich zagrożeń są:

- nierealistyczny termin ukończenia prac
- niedoskonałe środowisko tworzenia aplikacji

Zagrożenia przewidywalne można odgadnąć, analizując przebieg poprzednich przedsięwzięć.
Przykładami takich zagrożeń są:

- rotacja personelu
- nieskuteczna komunikacja z klientem