P
rojektowanie
S
ystemów
I
nformatycznych
Opracowanie zagadnień na egzamin
20
12
<rek
LAMA
>
</rek
LAMA
>
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