Slide 1

Cykle życia oprogramowania

Główne etapy cyklu życia oprogramowania



Analiza,



Projektowanie,



Implementacja,



Testowanie,



Wdrożenie.

Model przyrostowy

Model przyrostowy określany również jako ewolucyjny, jest

pewnego rodzaju połączeniem dwóch poprzednich modeli.
W modelu tym analiza i ogólny projekt, mający na celu

wyodrębnić poszczególne składowe projektu, jest

wykonywany dla całego systemu przy zastosowaniu

modelu wodospadowego, natomiast kolejne etapy są

przeprowadzane przy użyciu modelu spirali.
Model ten przez swoją strukturę eliminuje wady zarówno

modelu wodospadowego, jak i spiralnego, przy

jednoczesnym zachowaniu zalet obu powyższych modeli.

Role i skład zespołu projektowego

Kierownik projektu

Kierownik projektu jest osobą, która czuwa nad całością projektu, a jej najważniejszym zdaniem
jest organizowanie i kontrolowanie pracy zespołu, kontaktowanie się z klientem oraz sprawdzanie
czy "wszystko idzie dobrze".

Analityk

Głównym zadaniem analityka jest zbudowanie modelu analitycznego (konceptualnego) systemu.
W tym celu musi on stale kontaktować się z klientem, dla którego budowane jest oprogramowanie
oraz dobrze zrozumieć jego potrzeby i orientować się w dziedzinie problemowej, której dotyczy
system.
Z całą pewnością nie jest to zadanie łatwe i oprócz rozległej wiedzy wymaga odpowiedniego
doświadczenia i umiejętności pracy z ludźmi. Dobrze wykonany model analityczny ma kluczowe
znaczenie dla powodzenia całego projektu. Błędy popełnione na tym etapie są później trudne do
usunięcia i zazwyczaj bardzo kosztowne.

Projektant

Zadaniem projektanta jest zbudowanie projektu systemu. Projekt systemu jest kolejnym modelem
systemu, ale na innym poziomie szczegółowości niż projekt wykonany przez analityka. Zawiera on
bowiem informacje o szczegółach implementacyjnych systemu. Projektant musi wobec tego mieć
odpowiednią wiedzę na temat systemu na którym będzie implementowana aplikacja i narzędzi,
które zostaną wykorzystane do jej budowy.

Role i skład zespołu projektowego

Programista

Zadaniem programisty jest zakodowanie projektu opracowanego przez projektanta.

Tester

Zadaniem testera jest przeprowadzenie różnorodnych testów aplikacji zanim trafi ona
do klienta.

Wdrożeniowiec

Wdrożeniowiec jest osobą, która przeprowadza uruchomienie (wdrożenie) aplikacji u
klienta. Powinien on również umieć przeszkolić użytkownika w użytkowaniu produktu,
a często jest też twórcą dokumentacji dla użytkownika.

W projekcie mogą też wystąpić inne role lub wymienione role mogą być łączone (np.

projektanta i programisty). Zależy to od konkretnych potrzeb, wielkości projektu i przyjętej

metody prowadzenia projektu. W naszym mini projekcie będziecie musieli przejść przez

wszystkie wymienione role z wyjątkiem roli wdrożeniowca.

Definiowanie wymagań dla systemu

Techniki badania wymagań użytkowników Techniki

badania wymagań użytkowników

Do najczęściej stosowanych metod badań wymagań użytkowników

należą:



analiza dokumentacji,



ankieta,



analiza dokumentów (dynamicznych),



obserwacja.



Przy niewielkich projektach można stosować jedną z powyższych
metod, natomiast przy dużych systemach konieczne jest stosowanie
kilku technik jednocześnie w celu wnikliwego poznania wymagań
użytkowników.

Definiowanie wymagań dla systemu

Analiza dokumentacji



Zapoznanie się z dokumentacją, która funkcjonuje w danym
przedsiębiorstwie, do której zalicza się:



schemat organizacyjny,



dokumentację administracyjna,



specyfikacje stanowisk pracy,



opis procedur wewnętrznych,



dokumentacje szkoleniowe,



dokumentacje istniejących systemów.

Definiowanie wymagań dla systemu

Wywiad



Jest to najpopularniejsza metoda, w której analitycy
mogą zebrać i zweryfikować informacje o systemie,
zaakceptować rozwiązania, budowane jest zaufanie
użytkownika do systemu.



Najczęściej występujące problemy:



wywiad jest przeprowadzony z niekompetentnymi użytkownikami,



zadawane są złe pytania, a uzyskiwane odpowiedzi są

niepoprawne,



między analitykami a użytkownikami są niewłaściwe stosunki

(brak zaufania).

Definiowanie wymagań dla systemu

Ankieta



Przeprowadzana jest po wywiadzie (dla potwierdzenia
informacji).



Najczęściej występujące problemy przy ankiecie:



różna interpretacja pytań - niejednoznaczność odpowiedzi,



podczas ankiety odpowiedzi uzyskujemy tylko od niewielkiej

liczby ankietowanych,



nie wyjaśnia wszystkich wątpliwości.

Definiowanie wymagań dla systemu

Analiza dokumentów (ciągle powstających)



Analiza tych dokumentów, które są tworzone w firmie (raporty, zestawienia).

Taka analiza ma dać odpowiedź na następujące pytania:



Kto tworzy dokumentacje? - źródło.



Jak jest przygotowywany?



Jakie dane z dokumentacji są wykorzystywane?



Kto używa dokumentacji?



Kto wprowadza dane lub z nich korzysta?



Do jakich celów jest używany?



Jak jest przechowywany?



Jak długo jest przechowywany?



Informacja o obiegu istniejących dokumentów w firmie pozwala wyeliminować
niejasności i powtarzające się dokumenty

Pojęcie encji



Encja jest to coś co istnieje, co odróżnia się od innych, o czym
trzeba mieć informację.



Zbiory encji reprezentują zbiór elementów występujących
w rzeczywistym świecie i każdy element tego zbioru musi posiadać
następujące cechy:



każdy element musi być unikalny, jednoznacznie określony, w celu

odróżnienia go od pozostałych,



każdy element musi odgrywać jakąś rolę w projektowanym systemie, nie

może zdarzyć się sytuacji, w której system może działać bez dostępu do
danego elementu,



każdy element powinien być opisany przez odpowiednią liczbę

atrybutów.



W diagramach ERD obiekt, encja jest reprezentowany przez
prostokąt, a jego nazwa powinna być rzeczownikiem.

Pojęcie atrybutu

Atrybut jest pewną własnością encji, o której chcemy przechowywać

informację.
Atrybut jest reprezentowany przez pewną wartość.
Na przykład encja Student może mieć atrybut Nazwisko reprezentowany

przez wartość Kowalski.
Wśród atrybutów encji wyróżniamy atrybut lub zbiór atrybutów, którego

wartość w sposób jednoznaczny identyfikuje instancję (egzemplarz)

encji.
Taki atrybut lub zbiór atrybutów nazywamy kluczem głównym encji.
Klucz główny oznacza się często na wykresach symbolem PK (ang.

Primary Key) umieszczanym obok nazwy atrybutu.
Drugim kluczem stosowanym w bazach relacyjnych jest klucz obcy.

Kluczem obcym nazywamy atrybut encji, który wskazuje na klucz

główny innej encji. Klucz obcy oznacza się często na wykresach

symbolem FK (ang. Foreign Key) umieszczanym obok nazwy atrybutu.

Związek

Bardzo ważnym elementem w modelu danych są związki pomiędzy encjami i warunki określające te

związku - elementy łączące encje między sobą.
Zdecydowana większość związków to powiązania stopnia drugiego - związki binarne, charakteryzujące

się tym, że w związku bierze udział dwóch uczestników (dwie encje).
Mogą występować także związki unarne (encja powiązana z samą sobą), jak również związki ternarne

(z trzema uczestnikami).
W zależności od tego, jakiego typu jest uczestnictwo encji w danym związku, możemy podzielić encje na

słabe lub regularne.
Encje słabe charakteryzują się całkowitym uczestnictwem w powiązaniu, to oznacza, że encja nie może

istnieć bez tego powiązania (np. encja Zamówienia nie może istnieć bez powiązania z encją Klienci).
Natomiast uczestnictwo encji regularnych w związku jest tylko częściowe, czyli encja może istnieć

samodzielnie bez powiązania (np. encja Klienci może istnieć bez powiązania z encją Zamówienia).

Bardzo istotnym czynnikiem określanym przy związkach jest moc powiązania, która definiuje się jako

maksymalną liczbę instancji jednej encji (wystąpień w danej encji), które mogą być powiązane z instancją

innej encji. Ze względu na wartość mocy możemy wyróżnić trzy typy powiązań:



jeden-do-jeden,



jeden-do-wiele,



wiele-do-wiele.

Związek jeden-do-wiele (jedno-wieloznaczny)

Najbardziej typowym rodzajem powiązania jest powiązanie jeden-do-

wiele, w którym pojedyncza instancja jednej encji może być połączona z

jedną lub wieloma instancjami drugiej encji.
Ze względu na swoją uniwersalność i małą kłopotliwość, ten typ

powiązania jest najczęściej stosowany .
Opcjonalnie przy powiązaniu jeden lub wiele może występować również

opcja żadne, oznaczana graficznie w postaci okręgu.

Związek wiele-do-wiele (wielo-wieloznaczny)

Powiązania tego typu występują równie często jak powiązania jeden do wielu,

jednak nie dają się bezpośrednio implementować w relacyjnych bazach danych.

Są one realizowane przy pomocy encji pośrednich (w modelu relacyjnym są to

tabele sprzęgające) powiązanych z encjami pierwotnymi przy pomocy powiązań

jeden do wielu.
W powiązaniu wiele-do-wiele encjami głównymi są encje pierwotne, natomiast

encją obcą jest relacja sprzęgająca, która zwiera klucze główne relacji

oryginalnej. Dlatego w powiązaniu jeden-do-wiele pomiędzy relacjami

pierwotnymi, a relacją obcą, po stronie relacji oryginalnej znajduje się strona

"jeden" powiązania jeden-do-wiele a po stronie relacji obcej znajduje się strona.

Związki unarne

Powiązania tego typu mają tylko jednego uczestnika, czyli relację, która jest

powiązana sama ze sobą. Powiązania są realizowane jest w podobny

sposób jak powiązania binarne, z tym że odnosi się to do jednej encji. Klucz

główny tej encji jest dodawany do tejże encji.
Powiązania unarne tak jak powiązania binarne mogą być różnej mocy. To

znaczy mogą występować powiązania jeden do wielu, które mogą być

opcjonalne po stronie "jeden". Ten typ powiązania jest stosowany przy

odwzorowywaniu struktur hierarchicznych.
Powiązania unarne mogą być również realizowane jako powiązania wiele do

wielu. Wtedy, podobnie jak przy powiązaniach binarnych, muszą być

modelowane przy użyciu tabeli sprzęgającej.

Notacje związków

W praktyce spotkasz się z różnymi sposobami reprezentacji graficznej

związków (dla przykładu: w programach służących m.in. do projektowania

diagramów ERD takich jak Visio lub Rational Rose możliwe jest użycie kilku

różnych notacji).
Bodaj najpopularniejsza jest notacja czysto graficzna. Poniżej

zaprezentowano sposób, w jaki za pomocą notacji graficznej można

oznaczyć typ powiązania.

Metody przekształcania związków

Przekształcanie związków wielo-wieloznacznych
Przekształcanie związków ternarnych

Związki binarne wiele-do-wiele oraz związki ternarne nie są

implementowane w relacyjnych bazach danych. Dlatego

wymagają one pewnych przekształceń.

Relacje i terminologia związana z modelem relacyjnym

W klasycznym modelu relacyjnym pod pojęciem relacji rozumie się dwuwymiarową tablicę.

Relacja zdefiniowana jest poprzez tak zwany schemat relacji. Schemat relacji stanowi coś na kształt definicji tabeli.
Składa się on z nazwy relacji oraz zbioru atrybutów relacji.