1

1

P

P

rojektowanie

rojektowanie

systemów

systemów

informatycznych

informatycznych

2

2

Plan wykładu

Plan wykładu



Anatomia projektu informatycznego

Anatomia projektu informatycznego



Uszczegółowienie modelu

Uszczegółowienie modelu



Składowe systemów, które nie są związane

Składowe systemów, które nie są związane

z dziedziną problemu

z dziedziną problemu



Interakcja z użytkownikiem

Interakcja z użytkownikiem



Optymalizacja projektu

Optymalizacja projektu



Poprawność projektu

Poprawność projektu



Jakość modelu i projektu

Jakość modelu i projektu



Kluczowe czynniki sukcesu projektowania

Kluczowe czynniki sukcesu projektowania

3

3

Kontraktowanie

Procedury

Architektura

Konstrukcja

Wdrożenie

Jakość

Komunikacja

Równość stron
Precyzyjna specyfikacja

systemu

Rzetelna estymacja

kosztów

Rozsądny czas realizacji
Etapowanie

Zasady zarządzania
projektem
Dobrze zdefiniowany
proces
Standardy produktów
projektu
Procedury odbioru
produktów

Pełna specyfikacja
poziom systemu
informatycznego
poziom systemu
zarządzania
Spójność technologiczna
Zgodność z celami
projektu

Ponowne użycie
wzorce projektowe
komponenty
środowiska aplikacyjne
Standardy

Utrzymanie poziomu
satysfakcji
Kontrola zmian
Ocena projektu
wyniki
proces

Anatomia projektu informatycznego

Anatomia projektu informatycznego

4

4

Zadania wykonywane podczas

Zadania wykonywane podczas

projektowania

projektowania



Uszczegółowienie opracowanego

Uszczegółowienie opracowanego

modelu logicznego

modelu logicznego

; projekt musi być

; projekt musi być

wystarczająco szczegółowy, aby mógł być

wystarczająco szczegółowy, aby mógł być

podstawą implementacji, przy czym

podstawą implementacji, przy czym

stopień szczegółowości zależy od poziomu

stopień szczegółowości zależy od poziomu

zaawansowania programistów

zaawansowania programistów



Projektowanie składowych systemów, które

Projektowanie składowych systemów, które

nie są związane z dziedziną problemu

nie są związane z dziedziną problemu



Optymalizacja

Optymalizacja

systemu

systemu



Dostosowanie do ograniczeń

Dostosowanie do ograniczeń

i

i

możliwości środowiska implementacji

możliwości środowiska implementacji



Określenie

Określenie

fizycznej struktury systemu

fizycznej struktury systemu

5

5

Uszczegółowienie

Uszczegółowienie

modelu

modelu

6

6

Uszczegółowienie modelu

Uszczegółowienie modelu



Określenie poziomów

Określenie poziomów

widoczności

widoczności

atrybutów i dostępu

atrybutów i dostępu

do nich

do nich



Podanie

Podanie

reguł odwzorowania notacji

reguł odwzorowania notacji

w struktury konkretnego języka

w struktury konkretnego języka

programowania (np. polegające na

programowania (np. polegające na

dokładnym określeniu typów danych)

dokładnym określeniu typów danych)



Wybór sposobu implementacji

Wybór sposobu implementacji

konstrukcji

konstrukcji

, które mogą być

, które mogą być

zrealizowane na wiele sposobów (np.

zrealizowane na wiele sposobów (np.

zgodnie ze standardami przyjętymi w

zgodnie ze standardami przyjętymi w

firmie)

firmie)

7

7

Uszczegółowienie modelu

Uszczegółowienie modelu



Podanie

Podanie

nagłówków metod

nagłówków metod

oraz ich parametrów

oraz ich parametrów



Określenie,

Określenie,

które z metod będą realizowane

które z metod będą realizowane

jako funkcje wirtualne

jako funkcje wirtualne

a które jako zwyczajne

a które jako zwyczajne

funkcje

funkcje



Zastąpienie niektórych

Zastąpienie niektórych

prostych metod

prostych metod

bezpośrednim dostępem do atrybutów

bezpośrednim dostępem do atrybutów



Zastąpienie niektórych

Zastąpienie niektórych

atrybutów

atrybutów

redundantnych

redundantnych

przez odpowiednie metody, np.

przez odpowiednie metody, np.

Wiek = BieżącaData - DataUrodzenia;

Wiek = BieżącaData - DataUrodzenia;

8

8

Uszczegółowienie modelu

Uszczegółowienie modelu

Określenie sposobów

Określenie sposobów

implementacji

implementacji

związków

związków

(asocjacji), gdyż zwykle można

(asocjacji), gdyż zwykle można

je zaimplementować na wiele sposobów, z

je zaimplementować na wiele sposobów, z

reguły poprzez wprowadzenie

reguły poprzez wprowadzenie

dodatkowych atrybutów (pól):

dodatkowych atrybutów (pól):



obiekty powiązanej klasy

obiekty powiązanej klasy



wskaźniki

wskaźniki

(referencje) do obiektów

(referencje) do obiektów

powiązanej klasy

powiązanej klasy



identyfikatory obiektów

identyfikatory obiektów

powiązanej

powiązanej

klasy

klasy

9

9

Uszczegółowienie modelu

Uszczegółowienie modelu

W zależności od przyjętego sposobu

W zależności od przyjętego sposobu

oraz od

oraz od

liczności

liczności

związków (1:1, 1:n,

związków (1:1, 1:n,

n:1, m:n) możliwe są bardzo różne

n:1, m:n) możliwe są bardzo różne

deklaracje w przyjętym języku

deklaracje w przyjętym języku

programowania

programowania

:

:



tablica obiektów

tablica obiektów



lista wskaźników

lista wskaźników



tablica wskaźników

tablica wskaźników

10

10

Składowe systemów, które nie

Składowe systemów, które nie

są związane z dziedziną

są związane z dziedziną

problemu

problemu

11

11

Dodatkowe składowe systemu

Dodatkowe składowe systemu

(niezwiązane z dziedziną problemu)

(niezwiązane z dziedziną problemu)

Składowa zarządzania

Składowa zarządzania

pamięcią

pamięcią

operacyjną

operacyjną

(kompilator, syst.

operacyjny)

Składowa interfejsu

Składowa interfejsu

użytkownika

użytkownika

(do

niedawna nawet do 90%

nakładów; obecnie

realizowana zwykle

poprzez GUI)

Składowa zarządzania

Składowa zarządzania

zadaniami

zadaniami

(podział czasu procesora;

kompilator, syst.

operacyjny)

Składowa zarządzania

Składowa zarządzania

danymi

danymi

(przechowywanie

trwałych danych, SZBD)

Składowa

Składowa

dziedziny

dziedziny

problemu

problemu

Narzędzi

a typy

RAD

12

12

Interakcja z

Interakcja z

użytkownikiem

użytkownikiem

13

13

Interakcja z użytkownikiem

Interakcja z użytkownikiem

Za pomocą linii komend

Za pomocą linii komend

(w niektórych

(w niektórych

sytuacjach szybsza od interfejsu

sytuacjach szybsza od interfejsu

graficznego):

graficznego):



nieduże systemy lub prototypy

nieduże systemy lub prototypy



programy typowo obliczeniowe

programy typowo obliczeniowe



dla zaawansowanych użytkowników

dla zaawansowanych użytkowników

Za pomocą plików skryptowych:

Za pomocą plików skryptowych:



celem automatyzacji powtarzanych

celem automatyzacji powtarzanych

wielokrotnie tych samych działań

wielokrotnie tych samych działań

Przez graficzny interfejs okienkowy:

Przez graficzny interfejs okienkowy:



większe systemy

większe systemy



doceniane zwłaszcza przez początkujących i

doceniane zwłaszcza przez początkujących i

średnio zaawansowanych użytkowników

średnio zaawansowanych użytkowników

14

14

Interakcja z użytkownikiem

Interakcja z użytkownikiem

Typowe sposoby wydawania przez

Typowe sposoby wydawania przez

użytkownika poleceń:

użytkownika poleceń:



wpisywanie poleceń

wpisywanie poleceń

w postaci tekstowej

w postaci tekstowej

(np.

(np.

w linii komend)

w linii komend)



wybór

wybór

opcji z menu

opcji z menu

lub

lub

przycisku

przycisku

w dialogu

w dialogu



korzystanie z ikon

korzystanie z ikon

w paskach narzędziowych

w paskach narzędziowych

lub ze skrótów (kombinacje klawiszy)

lub ze skrótów (kombinacje klawiszy)



nawigacja przy użyciu urządzenia

nawigacja przy użyciu urządzenia

wskazującego np.

wskazującego np.

myszy

myszy

(kursor, przyciski, ...)

(kursor, przyciski, ...)



dotykanie aktywnego ekranu

dotykanie aktywnego ekranu



głosem

głosem

15

15

Złote

Złote

zasady projektowania interfejsu

zasady projektowania interfejsu

użytkownika (1)

użytkownika (1)



Spójność - wygląd oraz obsługa interfejsu powinny

Spójność - wygląd oraz obsługa interfejsu powinny

być podobne podczas korzystania z różnych funkcji

być podobne podczas korzystania z różnych funkcji

;

;

poszczególne programy tworzące system powinny mieć

poszczególne programy tworzące system powinny mieć

zbliżony interfejs

zbliżony interfejs

,

,

podobnie powinna wyglądać praca z

podobnie powinna wyglądać praca z

rozmaitymi

rozmaitymi

dialogami

dialogami

, podobnie powinny być

, podobnie powinny być

interpretowane operacje wykonywane przy pomocy myszy;

interpretowane operacje wykonywane przy pomocy myszy;

przykładowe reguły

przykładowe reguły

:

:

•

umieszczanie etykiet

umieszczanie etykiet

zawsze nad lub obok pól

zawsze nad lub obok pól

edycyjnych,

edycyjnych,

•

umieszczanie przycisków

umieszczanie przycisków

zawsze od dołu lub od

zawsze od dołu lub od

prawej,

prawej,

•

spójne tłumaczenie

spójne tłumaczenie

nazw angielskich, spójne

nazw angielskich, spójne

oznaczenia pól

oznaczenia pól

16

16

Złote zasady projektowania interfejsu

Złote zasady projektowania interfejsu

użytkownika (2)

użytkownika (2)



Skróty dla doświadczonych użytkowników

Skróty dla doświadczonych użytkowników

- możliwość zastąpienia komend menu przez

- możliwość zastąpienia komend menu przez

kombinację klawiszy

kombinację klawiszy



Potwierdzenie przyjęcia polecenia

Potwierdzenie przyjęcia polecenia

użytkownika

użytkownika

- realizacja niektórych operacji

- realizacja niektórych operacji

może trwać stosunkowo długo; w takich

może trwać stosunkowo długo; w takich

sytuacjach, aby użytkownik nie był

sytuacjach, aby użytkownik nie był

zdezorientowany, należy potwierdzić przyjęcie

zdezorientowany, należy potwierdzić przyjęcie

polecenia, oraz informować o przebiegu

polecenia, oraz informować o przebiegu

operacji (np. jakiś wskaźnik lub najlepiej czas

operacji (np. jakiś wskaźnik lub najlepiej czas

do zakończenia)

do zakończenia)

17

17

Złote zasady projektowania interfejsu

Złote zasady projektowania interfejsu

użytkownika (3)

użytkownika (3)



Zrozumiała terminologia komunikacji

Zrozumiała terminologia komunikacji

-

-

nawet (zwłaszcza) w sytuacjach krytycznych

nawet (zwłaszcza) w sytuacjach krytycznych

oprogramowanie powinno posługiwać się

oprogramowanie powinno posługiwać się

terminologią zrozumiałą dla użytkownika

terminologią zrozumiałą dla użytkownika



Eliminacja prostych błędów edycji

Eliminacja prostych błędów edycji

-

-

oprogramowanie

oprogramowanie

nie powinno dopuszczać do

nie powinno dopuszczać do

wprowadzenia niepoprawnych danych

wprowadzenia niepoprawnych danych

; jeżeli

; jeżeli

użytkownik wprowadzi dane, które dopiero po

użytkownik wprowadzi dane, które dopiero po

zweryfikowaniu można zakwalifikować jako

zweryfikowaniu można zakwalifikować jako

błędne, wówczas należy zasygnalizować rodzaj

błędne, wówczas należy zasygnalizować rodzaj

błędu oraz umożliwić poprawienia

błędu oraz umożliwić poprawienia

wprowadzonych wartości lub umożliwić

wprowadzonych wartości lub umożliwić

powrótu do wartości startowych (poprzednich)

powrótu do wartości startowych (poprzednich)

18

18

Złote zasady projektowania interfejsu

Złote zasady projektowania interfejsu

użytkownika (4)

użytkownika (4)



Odwoływanie poprzednio wykonanych

Odwoływanie poprzednio wykonanych

operacji

operacji

- możliwość cofnięcia ostatnio

- możliwość cofnięcia ostatnio

wykonanej operacji lub cofnięcie się „dowolnie”

wykonanej operacji lub cofnięcie się „dowolnie”

daleko (w granicach rozsądku)

daleko (w granicach rozsądku)



Wrażenie kontroli nad systemem

Wrażenie kontroli nad systemem

- nikt nie

- nikt nie

lubi, kiedy system sam zaczyna robić coś, czego

lubi, kiedy system sam zaczyna robić coś, czego

użytkownik nie zainicjował, lub kiedy akcja

użytkownik nie zainicjował, lub kiedy akcja

systemu nie daje się przerwać; system nie

systemu nie daje się przerwać; system nie

powinien inicjować długich akcji (np.

powinien inicjować długich akcji (np.

składowania) nie informując użytkownika co w

składowania) nie informując użytkownika co w

tej chwili robi oraz powinien możliwie szybko

tej chwili robi oraz powinien możliwie szybko

reagować na sygnały przerwania akcji (Esc,

reagować na sygnały przerwania akcji (Esc,

Ctrl+C, Break,...)

Ctrl+C, Break,...)

19

19

Złote zasady projektowania interfejsu

Złote zasady projektowania interfejsu

użytkownika (5)

użytkownika (5)



Dostępność powiązanych informacji

Dostępność powiązanych informacji

- w

- w

momencie wypełniania konkretnej informacji,

momencie wypełniania konkretnej informacji,

użytkownik powinien zawsze mieć możliwość

użytkownik powinien zawsze mieć możliwość

podejrzenia (lub wyboru z listy)

podejrzenia (lub wyboru z listy)



Nieobciążanie pamięci krótkotrwałej

Nieobciążanie pamięci krótkotrwałej

użytkownika

użytkownika

- użytkownik może zapomnieć o

- użytkownik może zapomnieć o

tym po co i z jakimi danymi uruchomił dialog;

tym po co i z jakimi danymi uruchomił dialog;

system powinien w miarę możliwości

system powinien w miarę możliwości

wyświetlać stale te informacje, które są

wyświetlać stale te informacje, które są

niezbędne do tego, aby użytkownik wiedział, co

niezbędne do tego, aby użytkownik wiedział, co

aktualnie dzieje się, i w którym miejscu

aktualnie dzieje się, i w którym miejscu

interfejsu znajduje się.

interfejsu znajduje się.

Reguła Millera 7(±2)

Reguła Millera 7(±2) - reguła psychologiczna określająca

liczbę obiektów nad którymi człowiek może jednocześnie

pracować w sposób efektywny

20

20

Złote zasady projektowania interfejsu

Złote zasady projektowania interfejsu

użytkownika (6)

użytkownika (6)



Grupowanie powiązanych operacji

Grupowanie powiązanych operacji

-jeżeli zadanie nie da się zamknąć w

-jeżeli zadanie nie da się zamknąć w

prostym dialogu lub oknie, wówczas trzeba

prostym dialogu lub oknie, wówczas trzeba

je rozbić na szereg powiązanych dialogów;

je rozbić na szereg powiązanych dialogów;

użytkownik powinien być prowadzony przez

użytkownik powinien być prowadzony przez

ten szereg, z możliwością łatwego powrotu

ten szereg, z możliwością łatwego powrotu

do wcześniej wprowadzanych informacji

do wcześniej wprowadzanych informacji



Ograniczenie powyższe można

Ograniczenie powyższe można

przełamywać poprzez grupowanie

przełamywać poprzez grupowanie

powiązanych ze sobą elementów w

powiązanych ze sobą elementów w

wyraźnie wydzielone zespoły

wyraźnie wydzielone zespoły

21

21

Określenie fizycznej struktury systemu

Określenie fizycznej struktury systemu

Obejmuje:

Obejmuje:



określenie struktury kodu źródłowego

określenie struktury kodu źródłowego

, tj.

, tj.

wyróżnienie plików źródłowych, zależności

wyróżnienie plików źródłowych, zależności

pomiędzy nimi oraz rozmieszczenie

pomiędzy nimi oraz rozmieszczenie

składowych projektu w plikach źródłowych

składowych projektu w plikach źródłowych



podział systemu

podział systemu

na poszczególne aplikacje

na poszczególne aplikacje



fizyczne rozmieszczenie danych i

fizyczne rozmieszczenie danych i

aplikacji

aplikacji

na stacjach roboczych i serwerach

na stacjach roboczych i serwerach

Pomocne mogą być

Pomocne mogą być

diagramy

diagramy

:

:



komponentów

komponentów



wdrożenia

wdrożenia

22

22

Optymalizacja projektu

Optymalizacja projektu

23

23

Optymalizacja (rozumiana jako

Optymalizacja (rozumiana jako

poprawa efektywności) może być

poprawa efektywności) może być

dokonana na poziomie:

dokonana na poziomie:

•

•

projektu

projektu

•

•

implementacji

implementacji

24

24

Kluczowe zagadnienia na etapie

Kluczowe zagadnienia na etapie

projektowania

projektowania

:

:



Zmiana algorytmu przetwarzania

Zmiana algorytmu przetwarzania

- np. zmiana

- np. zmiana

algorytmu sortującego poprzez wprowadzenie

algorytmu sortującego poprzez wprowadzenie

pośredniego pliku zawierającego tylko klucze i

pośredniego pliku zawierającego tylko klucze i

wskaźniki do sortowanych obiektów może

wskaźniki do sortowanych obiektów może

przynieść

przynieść

nawet 100-krotny zysk

nawet 100-krotny zysk

.

.



Wykrycie potencjalnych “

Wykrycie potencjalnych “

wąskich gardeł

wąskich gardeł

” w

” w

przetwarzaniu i staranne ich zaprojektowanie;

przetwarzaniu i staranne ich zaprojektowanie;

stosuje się tutaj twierdzenie, że

stosuje się tutaj twierdzenie, że

20% kodu jest

20% kodu jest

wykonywane przez 80% czasu

wykonywane przez 80% czasu

; możliwe jest

; możliwe jest

również rozwiązanie polegające

również rozwiązanie polegające

na zleceniu

na zleceniu

implementacji kluczowego

implementacji kluczowego

przetwarzania na

przetwarzania na

niższym poziomie

niższym poziomie

25

25

Kluczowe zagadnienia na etapie

Kluczowe zagadnienia na etapie

projekowania:

projekowania:



Świadoma denormalizacja relacyjnej bazy

Świadoma denormalizacja relacyjnej bazy

danych

danych

- wprowadzenie nadmiarowości danych w

- wprowadzenie nadmiarowości danych w

celu zwiększenia efektywności (np. łączenie

celu zwiększenia efektywności (np. łączenie

dwóch lub więcej tablic w jedną)

dwóch lub więcej tablic w jedną)



Stosowanie struktur pomocniczych

Stosowanie struktur pomocniczych

- indeksów,

- indeksów,

tablic wskaźników, ...

tablic wskaźników, ...



Analiza mechanizmów buforowania danych

Analiza mechanizmów buforowania danych

w

w

pamięci operacyjnej i ewentualna zmiana tego

pamięci operacyjnej i ewentualna zmiana tego

mechanizmu (np. zmniejszenie liczby poziomów)

mechanizmu (np. zmniejszenie liczby poziomów)

26

26

Poprawność

Poprawność

projektu

projektu

27

27

Poprawność projektu

Poprawność projektu

Poprawność oznacza jedynie, że

Poprawność oznacza jedynie, że

opis

opis

projektu jest zgodny z notacją

projektu jest zgodny z notacją

;

;

nie

nie

gwarantuje

gwarantuje

, że projekt jest zgodny

, że projekt jest zgodny

z

z

wymaganiami użytkownika

wymaganiami użytkownika

Poprawny projekt musi być:

Poprawny projekt musi być:



kompletny

kompletny



niesprzeczny

niesprzeczny



spójny

spójny



zgodny z przyjętą notacją

zgodny z przyjętą notacją

28

28

Poprawność projektu

Poprawność projektu

Kompletność

Kompletność

-

-

zdefiniowane są wszystkie

zdefiniowane są wszystkie

klasy

klasy

, pola, metody oraz dane złożone i

, pola, metody oraz dane złożone i

elementarne, a także

elementarne, a także

opisany jest sposób

opisany jest sposób

realizacji wszystkich wymagań funkcjonalnych

realizacji wszystkich wymagań funkcjonalnych

Spójność

Spójność

- semantyczna zgodność informacji

- semantyczna zgodność informacji

zawartych na diagramach i w specyfikacji

zawartych na diagramach i w specyfikacji

29

29

Jakość modelu i

Jakość modelu i

projektu

projektu

30

30

Jakość modelu i projektu

Jakość modelu i projektu

Kryteria jakości:

Kryteria jakości:



spójność

spójność

- określa, na ile poszczególne elementy

- określa, na ile poszczególne elementy

składowe „

składowe „

pasują” do siebie

pasują” do siebie

; jeżeli

; jeżeli

poszczególne składowe większych całości będą

poszczególne składowe większych całości będą

ze sobą spójne to wtedy potencjalne zmiany

ze sobą spójne to wtedy potencjalne zmiany

zamkną się w ramach ściśle określonych części

zamkną się w ramach ściśle określonych części

systemu

systemu



stopień powiązania składowych

stopień powiązania składowych

- należy dążyć

- należy dążyć

do tego, aby stopień powiązania pomiędzy

do tego, aby stopień powiązania pomiędzy

składowymi był

składowymi był

minimalny

minimalny

(można go mierzyć),

(można go mierzyć),

dotyczy:

dotyczy:

•

przepływu komunikatów

przepływu komunikatów

•

dziedziczenia

dziedziczenia

•

związków klas

związków klas

31

31

Jakość modelu i projektu

Jakość modelu i projektu



przejrzystość

przejrzystość

(czytelność, łatwość zrozumienia):

(czytelność, łatwość zrozumienia):

•

odzwierciedlenie rzeczywistości

odzwierciedlenie rzeczywistości

•

spójność oraz stopień powiązania składowych

spójność oraz stopień powiązania składowych

•

zrozumiałe nazewnictwo

zrozumiałe nazewnictwo

•

czytelna i pełna specyfikacja

czytelna i pełna specyfikacja

•

odpowiednia złożoność składowych na danym

odpowiednia złożoność składowych na danym

poziomie abstrakcji

poziomie abstrakcji



Istotne jest

Istotne jest

spełnienie kryteriów formalnych

spełnienie kryteriów formalnych

jakości, które w dużym stopniu

jakości, które w dużym stopniu

rzutują na efektywną

rzutują na efektywną

jakość, chociaż w żadnym stopniu

jakość, chociaż w żadnym stopniu

jej nie gwarantują

jej nie gwarantują

32

32

Kluczowe czynniki sukcesu

Kluczowe czynniki sukcesu

projektowania

projektowania

33

33

Kluczowe czynniki sukcesu

Kluczowe czynniki sukcesu

projektowania

projektowania



Wysoka

Wysoka

jakość modelu

jakość modelu

projektowego

projektowego



Dobra

Dobra

znajomość środowiska

znajomość środowiska

implementacji

implementacji



Zachowanie przyjętych

Zachowanie przyjętych

standardów

standardów

(konsekwentne stosowanie notacji i

(konsekwentne stosowanie notacji i

formularzy)

formularzy)



Sprawdzenie poprawności projektu

Sprawdzenie poprawności projektu

w ramach zespołu projektowego

w ramach zespołu projektowego

34

34

Kluczowe czynniki sukcesu

Kluczowe czynniki sukcesu

projektowania

projektowania



Optymalizacja projektu we

Optymalizacja projektu we

właściwym zakresie

właściwym zakresie

(powinna być

(powinna być

ograniczona do istotnych,

ograniczona do istotnych,

krytycznych miejsc, gdzie

krytycznych miejsc, gdzie

rzeczywiście jest potrzebna)

rzeczywiście jest potrzebna)



Poddanie projektu ocenie przez

Poddanie projektu ocenie przez

niezależne ciało

niezależne ciało

oceniające jego

oceniające jego

jakość pod względem formalnym i

jakość pod względem formalnym i

merytorycznym

merytorycznym

35

35

O czym był wykład ?

O czym był wykład ?



Anatomia projektu informatycznego

Anatomia projektu informatycznego



Uszczegółowienie modelu

Uszczegółowienie modelu



Składowe systemów, które nie są związane

Składowe systemów, które nie są związane

z dziedziną problemu

z dziedziną problemu



Interakcja z użytkownikiem

Interakcja z użytkownikiem



Optymalizacja projektu

Optymalizacja projektu



Poprawność projektu

Poprawność projektu



Jakość modelu i projektu

Jakość modelu i projektu



Kluczowe czynniki sukcesu projektowania

Kluczowe czynniki sukcesu projektowania

36

36

Literatura:

1. Z. Szyjewski, Metodyki

1. Z. Szyjewski, Metodyki

zarządzania projektami

zarządzania projektami

informatycznymi

informatycznymi

,

Wydawnictwo

Placet,

,

Wydawnictwo

Placet,

Warszawa 2004

Warszawa 2004

2. Booch G., Raumbaugh J., Jacobson I.,

2. Booch G., Raumbaugh J., Jacobson I.,

UML:

UML:

Przewodnik

użytkownika,

Przewodnik

użytkownika,

Wydawnictwa

Wydawnictwa

Naukowo- Techniczne

Naukowo- Techniczne

,

,

Warszawa 2001

Warszawa 2001