Projektowanie
Systemów
Informatycznych
Opracowanie zagadnień na egzamin
2012


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 Klasa, obiekt, asocjacja, generalizacja, zależność,
Diagram obiektów realizacja, interfejs
Model przypadków Diagram przypadków Aktor, przypadek użycia, inkluzja, ekstensja,
użycia użycia generalizacja
Model implementacji Diagram komponentów Komponent, interfejs, zależność, realizacja
Diagram wdrożeniowy Węzeł, komponent, zależność, lokacja
Model dynamiczny Diagram stanów Stan, zdarzenie, przejście, akcja, aktywność
Diagram aktywności Stan, aktywność, fork, join, romb decyzyjny
Diagram interakcji Interakcja, współpraca, komunikat, aktywacja
Model zarządzania Diagram pakietów Pakiet, podsystem
Wszystkie modele Wszystkie diagramy Stereotyp, wartość etykietowana, ograniczenie
2
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 Modelowanie konfiguracji sprzętowych i programowych
(diagram wdrożenia) 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
3
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.
4
9. Przedstaw klasyfikację systemów
Kryterium podziału Grupy systemów
- dziedzinowe
Zakres merytoryczny systemu informatycznego - czÄ…stkowe
- kompleksowe
- ewidencyjno  sprawozdawcze
- informujÄ…ce
Zakres spełnianych funkcji
- wspomagania decyzji
- automatyzacji biura
- systemy proste
Złożoność funkcjonalna i techniczno-programowa - 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.
5
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 z
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ądz

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.
6
15. Struktury systemu informatycznego
Struktura funkcjonalna: Struktura techniczno-technologiczna:
- Podział systemu na moduły - Typy sprzętu komputerowego
- Określenie procesów podstawowych i - Technologia przetwarzania
pomocniczych - Oprogramowanie systemowe
Struktura informacyjna: Struktura przestrzenna:
- Określenie logicznych struktur danych - Topologia punktów przetwarzania
- Określenie zasad kodowania danych - 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
7
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 / 2. Analiza obiektowa
diagramy) -> co system ma robić; wyodrębnienie
->co system ma robić obiektów
3. Projektowanie strukturalne 3. Projektowanie obiektowe
->Projekt architektury systemu (podział na -> Szczegółowy projekt obiektów.
moduły). Szczegółowy projekt modułów.
4. Implementacja (programowanie) 4. Programowanie obiektowe
-> Wybrany język projektowania -> 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.
8
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: Wady:
- ułatwia organizację: planowanie, - narzuca twórcom oprogramowania ścisłą
harmonogramowanie, monitorowanie kolejność wykonywania prac
przedsięwzięcia- zmusza do zdyscyplinowanego - występują trudności w sformułowaniu wymagań
podejścia od samego początku
- wymusza kończenie dokumentacji po każdej fazie - powoduje wysokie koszty błędów popełnionych
- wymusza sprawdzenie każdej fazy przez SQA 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: Wady:
- Do dużych systemów - szybka reakcja na - Trudno do niego przekonać klienta
pojawiające się czynniki ryzyka - Konieczność umiejętności szacowania ryzyka
- Połączenie iteracji z klasycznym modelem  Problemy, gdy z
le oszacujemy ryzyko
kaskadowym
Model Ewolucyjny
Zalety: Wady:
 dobry dla małych projektów, szybki start  trudność z harmonogramowaniem
projektu  koszty prototypowania, błądzenia
 tolerancja dla słabo zdefiniowanych  systemy często o złej strukturze
wymagań niski koszt błędów (krótki czas życia
błędów)
9
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
z
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.
10
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%
11
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ądz
z
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
12
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
13
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
14
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 z
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.
15
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.
16
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ęz
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ęść.
17
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.
18
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 -Scalenie zawartości pakietu
-Przejmowanie zawartości pakietu
-Zagnieżdżanie pakietów
-Zależność
-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.
19
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.
20
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
21