D. Zarządzanie danymi informacyjnymi, bazy danych, systemy informatyczne i zarządzanie projektami

1. Metody organizacji dokumentów tekstowych.

2. Metody wyszukiwania dokumentów tekstowych.

3. Systemy zarządzania bazami danych (SZBD): Pojęcie, architektura, przykłady.

4. Podstawowe modele danych. Encje i powiązania między encjami; diagramy ERD.

5. Relacyjny model danych. Języki zapytań relacyjnych. Podstawowe instrukcje języka SQL w zakresie manipulowania danymi (nazwa, przeznaczenie).

6. Elementy zarządzania relacyjnymi bazami danych.

7. Zastosowania BD: Przeznaczenie baz danych; cykl życia aplikacji opartych o bazę danych.

8. System informacyjny: System informatyczny (SI) a system informacyjny. Geneza i zależności pomiędzy nieformalnym, formalnym i technicznym systemem informacyjnym.

9. Cykl życia systemu informatycznego: Modele cyklu życia systemu informatycznego i ich cechy wspólne.

10. Zastosowania SI: Klasyfikacja zastosowań systemów informatycznych. Pojęcie systemów ERP, CRM, HRM, CAD, CAM (objaśnienie skrótów i właściwości klas systemów).

11. Bezpieczeństwo SI: Bezpieczeństwo bierne i czynne systemów informatycznych. Źródła zagrożeń bezpieczeństwa systemów informatycznych; przykłady zagrożeń i sposoby ograniczania ich wpływu. Polityka bezpieczeństwa systemu informatycznego; składowe, podstawy i konstruowanie. Zasady tworzenia haseł i postępowania z hasłami.

12. Zarządzanie projektami informatycznymi. Czynniki krytyczne sukcesu. Rola i zadania kierownika projektu. Struktura organizacyjna projektu. Struktura prac w projekcie. Harmonogramowanie. Technika Gantta. Techniki sieciowe. Estymacja parametrów projektu - przykłady technik. Metoda punktów funkcyjnych. Zarządzanie ryzykiem. Zarządzanie projektami z wykorzystaniem wskaźników ekonomicznych. Oprogramowanie wspierające zarządzanie projektami.

_______________________________________________________________

3. Systemy zarządzania bazami danych (SZBD): Pojęcie, architektura, przykłady.

Pojęcie SZBD

System zarządzania bazą danych (SZBD) jest to zestaw programów umożliwiających tworzenie i eksploatację bazy danych. System zarządzania bazą danych jest oprogramowaniem ogólnego przeznaczenia. System bazy danych składa się z bazy danych, systemu zarządzania bazą danych i ewentualnie z zestawu aplikacji wspomagających pracę poszczególnych grup użytkowników.

ARCHITEKTURA SZBD

Współczesne SZBD składa się z 3 części:

• jądra,

• interfejsu

• zestawu narzędzi

Funkcje jądra określają kategorie działań:

• organizacja plików

• mechanizmy dostępu

• zarządzanie transakcjami

• zarządzanie słownikami

• zarządzanie zapytaniami

• sporządzanie kopii zapasowych

Zadania realizowane przez jądro SZBD można sklasyfikować w sposób następujący:

1. Zarządzanie zbiorami danych

• tworzenie nowych zbiorów (jednostek logicznej struktury DBMS, tj. baz danych, tabel, ...)

• usuwanie zbiorów

• modyfikowanie struktury zbiorów

• wstawianie, aktualizowanie i usuwanie danych

Wyszukiwanie informacji
w odpowiedzi na zapytania otrzymane od programów klienckich, jądro bazy danych zwraca dane będące wynikiem odpowiedniego przeszukania bazy danych, a programy klienckie zajmują się ich prezentacją użytkownikowi po ewentualnej dalszej obróbce;

Zarządzanie bazą danych jako całością

• tworzenie kont użytkowników

• definiowanie uprawnień dostępu

• monitorowanie działania bazy danych

Przykłady

Ważniejsze systemy zarządzania bazą danych 

1. Systemy profesjonalne (stosowane przez agendy rządowe, banki, biblioteki i  duże firmy)

• Oracle Corporation - http://www.oracle.com  (wg. wielkości obrotów) około 50%, Informix i Ingres około 15%

• Oracle to druga co do wielkości po Microsofcie firma zajmująca się oprogramowaniem.

• Oracle DBMS - na około 90 platformach sprzętowych, Personal Oracle na PC, Oracle Media Server, Oracle Video Server, obsługa hurtowni danych.

• PROGRESS Application Development Environment (http://www.progress.com/progress/index.htm) - jeden z najbardziej popularnych w Polsce.

• DB/2 (IBM http://www.ibm.com/us/) lub DRDA (Distributed Relational DataBase Architecture), Rozproszona Relacyjna Architektura Baz Danych.

• Informix Software Polska, w Polsce od 1994 roku - http://www.informix.com.pl/ 

• Ingres (Computer Associates, CA), w Polsce Rodan Systems Sp. z.o.o - http://www.rodan.pl/

• Sybase PL - http://www.sybase.com.pl/ 

• Adabas C, Siemens Nixdorf Polska - http://www.sni.pl/ 

• Gupta SQLBase (Centura Corporation - http://www.guptaworldwide.com/) 

• Microsoft SQL Server for Windows NT/2000/XP - http://msdn.microsoft.com/library/default.asp?url=/nhp/default.asp?contentid=28000409 

2.  DBMS dla mniejszych firm (małe systemy na komputery osobiste i stacje robocze)

• Microsoft Access (Windows - http://www.eu.microsoft.com/poland) - łatwy, SQL, język Access Basic

• FoxPro (Microsoft - http://www.microsoft.com) pod DOS, Windows, Mac, Unix, wersja polska.

• Paradox (Borland) - Query by Example, pytania przez analogie. - http://www.prestwood.com/forums/paradox/files/ 

• dBase (Borland - http://www.borland.com), od 1981 roku (dBase II pod CP/M), wersja polska ISIS wzorowany na dBase, darmowy.

• MySQL - http://www.mysql.com/ 

_____________________________________________________________________

4. Podstawowe modele danych. Encje i powiązania między encjami; diagramy ERD.

Podstawowe modele danych

Model danych (a w odniesieniu do konkretnej realizacji mówi się często o architekturze systemu baz danych) można rozumieć jako zbiór ogólnych zasad posługiwania się danymi.

Zbiór ten obejmuje trzy główne części:

1. Definicja danych: zbiór reguł określających strukturę danych, tj. to co wcześniej określałem jako logiczną strukturę bazy danych (w odróżnieniu od niższego poziomu organizacji zapisu stosowanego wewnętrznie przez jądro bazy danych);

2. Operowanie danymi: zbiór reguł dotyczących procesu dostępu do danych i ich modyfikacji;

3. Integralność danych: zbiór reguł określających, które stany bazy danych są poprawne (a więc zarazem jakie operacje prowadzące do modyfikacji danych są dozwolone).

Rozróżnia się trzy główne typy (lub generacje) modeli danych:

1. Proste modele danych. Dane zorganizowane są w strukturę rekordów zgrupowanych w plikach. Głównymi dostępnymi operacjami są operacje na rekordach (ewentualnie na ich poszczególnych polach). Z tego rodzaju modelem danych mieliśmy do czynienia dotąd na ćwiczeniach.

2. Klasyczne modele danych. Należą do nich modele hierarchiczne, sieciowe i relacyjne. Modele relacyjne stanowią najbardziej popularną obecnie podstawę architektur systemów baz danych.

3. Semantyczne modele danych. Semantyka to inaczej znaczenie. Klasyczne modele danych nie dostarczają łatwego sposobu odczytania informacji o semantyce danych, stąd podejmuje się próby stworzenia innych modeli, uzupełniających ten brak. Przykładem częściowej realizacji tego programu są obiektowe modele danych.

Hierarchiczny model danych

Hierarchiczny model danych jest pewnym rozszerzeniem modelu prostego, opartego na rekordach składających się z pól i zgrupowanych w plikach. W schemacie hierarchicznym wprowadza się typy rekordów i związki nadrzędny-podrzędny pomiędzy nimi.

Definicja danych

Typ rekordu to nazwana struktura danych, złożona ze zbioru nazwanych pól; każde pole służy do zapisu pojedynczego atrybutu obiektu opisywanego przez rekord, i charakteryzuje się określonym typem danych, np. liczba całkowita, napis, data, itp. Na ogół jedno z pól danego typu rekordu wyróżnia się jako klucz, tj. unikalny identyfikator rekordu wśród rekordów danego typu (często przydzielany dość arbitralnie, podobnie jak np. nr albumu studenta lub nr PESEL w ewidencji ludności) oraz zakłada się uporządkowanie rekordów wg. wartości jednego z pól (zwykle klucza, choć niekoniecznie).
Relacja nadrzędny-podrzędny: typy rekordów tworzą strukturę drzewa, tj. każdy typ rekordu (z wyjątkiem najwyższego w hierarchii, tzw. korzenia -- root) związany jest z dokładnie jednym typem nadrzędnym. Zarazem każdy określony rekord typu podrzędnego jest związany z określonym rekordem właściwego typu nadrzędnego.

Operowanie danymi

Typowe operacje na danych w tym modelu to wyszukiwanie rekordów określonego typu, podrzędnych względem danego rekordu, i spełniających warunki dotyczące zawartości określonych pól; usuwanie lub dodawanie rekordów i edycja ich pól. Realizowane są poprzez funkcje lub procedury pisane w językach programowania o charakterze zazwyczaj proceduralnym, np. C.

Integralność danych

Podstawowe warunki integralności wynikają z samej definicji struktury danych modelu:

• Każdy rekord (z wyjątkiem korzenia) musi być powiązany z rekordem nadrzędnym właściwego typu; a więc np. usunięcie rekordu nadrzędnego wiąże się z usunięciem wszystkich względem niego podrzędnych. Nie można wstawić rekordu bez powiązania go z rekordem nadrzędnym.

• Zawartość każdego pola rekordu musi odpowiadać typowi danych z definicji danego typu rekordu.

Itp.

Widać, że model hierarchiczny ma wiele wspólnego ze strukturą systemu plików.





Dane z określonego poziomu mają odniesienie do jednego zbioru nadrzędnego. Mogą natomiast generować odniesienia do wielu zbiorów niższego rzędu. Przykładem takiej struktury jest lokalizacja plików w pamięci komputera, czyli jedną z ważnych funkcji systemu operacyjnego jest zarządzanie hierarchicznym modelem bazy danych, w którym danymi są zasoby komputera

Sieciowy model danych

Sieciowy model danych w ogólnym zarysie niewiele odbiega od hierarchicznego. W miejsce związku nadrzędny-podrzędny pomiędzy rekordami wprowadza się w nim tzw. typ kolekcji (set), który jest złożonym typem danych pola zawierającym odniesienia do innych rekordów określonego typu. Tzn. określenie typu kolekcji polega na podaniu typu rekordu-,,właściciela'' i typu rekordów-elementów kolekcji (oraz ew. klucza porządkowania elementów). Operowanie danymi ma też charakter proceduralny: typowe operacje to wyszukiwanie rekordu na podstawie zawartości pól i/lub przynależności do danego wystąpienia typu kolekcji, i dokonywanie modyfikacji bieżącego rekordu.

Warunki integralności danych, poza oczywistymi już więzami dotyczącymi zgodności zawartości pól rekordu z określeniem typu rekordu i unikalności pól kluczowych, mogą być formułowane w terminach wymogu przynależności rekordu do jakiegoś wystąpienia określonego typu kolekcji.





Zachowanie hierarchicznych zależności jest bardzo trudne, ponieważ rzeczywistość z reguły jest bardziej skomplikowana. Jeśli zbudujemy choćby jedno dodatkowe połączenie, które zakłóca strukturę hierarchiczną, otrzymujesz model sieciowy

Relacyjny model danych

Definicja danych

Model relacyjny oparty jest na tylko jednej podstawowej strukturze danych -- relacji. Pojęcie relacji można uważać za pewną abstrakcję intuicyjnego pojęcia tabeli, zbudowanej z wierszy i kolumn, w której na przecięciu każdej kolumny z każdym wierszem występuje określona wartość.

Baza danych jest zbiorem relacji, o następujących własnościach:

• Każda relacja w bazie danych jest jednoznacznie określona przez swoją nazwę.

• Każda kolumna w relacji ma jednoznaczną nazwę (w ramach tej relacji).

• Kolumny relacji tworzą zbiór nieuporządkowany. Kolumny nazywane bywają również atrybutami.

• Wszystkie wartości w danej kolumnie muszą być tego samego typu. Zbiór możliwych wartości elementów danej kolumny nazywany bywa też jej dziedziną.

• Również wiersze relacji tworzą nieuporządkowany zbiór; w szczególności, nie ma powtarzających się wierszy. Wiersze relacji nazywa się też encjami.

• Każde pole (przecięcie wiersza z kolumną) zawiera wartość atomową z dziedziny określonej przez kolumnę. Brakowi wartosci odpowiada wartość specjalna NULL, zgodna z każdym typem kolumny (chyba, że została jawnie wykluczona przez definicję typu kolumny).

• Każda relacja zawiera klucz główny -- kolumnę (lub kolumny), której wartości jednoznacznie identyfikują wiersz (a więc w szczególności nie powtarzają się). Wartością klucza głównego nie może być NULL.

Do wiązania ze sobą danych przechowywanych w różnych tabelach używa się kluczy obcych. Klucz obcy to kolumna lub grupa kolumn tabeli, o wartościach z tej samej dziedziny co klucz główny tabeli z nią powiązanej.

Np. baza danych instytucji składającej się z wielu zakładów może zawierać tabele zakłady i pracownicy: tabela zakłady zawiera m. in. kolumny kod_zakladu (klucz główny), nazwa, adres, kierownik,...; a tabela pracownicy: kolumny nr_prac (klucz główny), nazwisko, zakład, pokój, telefon, email,...; kolumna zakłady.kierownik może być kluczem obcym odnoszącym się do kolumny pracownicy.nr_prac; zaś kolumna pracownicy.zakład - kluczem obcym odnoszącym się do zakłady.kod_zakładu, etc. Unika się w ten sposób powielania tych samych danych w różnych tabelach, co m. in. ułatwia utrzymanie zgodności pomiędzy zawartością bazy danych a stanem faktycznym.

Operacje na danych

W teoretycznym opisie modelu relacyjnego operacje na danych definiuje się w terminach tzw. algebry relacyjnej. Operatory algebry relacyjnej mają za argumenty jedną lub więcej relacji, a wynikiem ich działania zawsze jest też relacja.

Selekcja. Selekcja jest operacją jednoargumentową, określoną przez warunek dotyczący wartości kolumn danej relacji. Wynikiem jej jest relacja zawierające te wszystkie encje (wiersze) wyjściowej relacji, których atrybuty spełniają dany warunek.
Rzut. Rzut to operacja jednoargumentowa określona przez podzbiór zbioru kolumn danej relacji, dająca w wyniku tabelę składającą się z tychże kolumn wyjściowej relacji.
Iloczyn kartezjański. Argumentami są dwie relacje, wynikiem -- relacja, ktorej wiersze są zbudowane ze wszystkich par wierszy relacji wyjściowych. Operacja o znaczeniu raczej teoretycznym.
Równozłączenie. Argumentami są dwie relacje, posiadające kolumny o tych samych dziedzinach np. klucz główny jednej z nich i klucz obcy drugiej. Wynikiem jest tabela otrzymana z iloczynu kartezjańskiego relacji wyjściowych poprzez selekcję za pomocą warunku równości tych ,,wspólnych'' atrybutów.
Złączenie naturalne. Powstaje z równozłączenia dwóch tabel poprzez rzutowanie usuwające powtarzające się kolumny złączenia. Rzeczywiście jest to operacja bardziej ,,naturalna'' aniżeli równozłączenie.
Złączenia zewnętrzne. Tu sprawa się komplikuje. Złączenia zewnętrzne tworzone są podobnie jak złączenie naturalne, lecz z pozostawieniem w tabeli wynikowej także wierszy, dla których nie zachodzi równość atrybutów złączenia: w przypadku złączenia lewostronnego złączenie naturalne uzupełnia się o wiersze z pierwszego argumentu nie posiadające odpowiednika (wierszu o równym atrybucie złączenia) w drugim argumencie; ,,brakujące'' atrybuty przyjmują wartość NULL. W złączeniu prawostronnym robi się to samo, ale względem drugiego argumentu. Wreszcie złączenie obustronne obejmuje obydwie tabele wyjściowe tą samą operacją.
Suma. Suma jest operatorem działającym na dwóch zgodnych relacjach (to jest o tych samych kolumnach), produkującym relację której wiersze są sumą teoriomnogościową wierszy z relacji wyjściowych.
Przecięcie. Przecięcie znowu wymaga dwóch zgodnych tabel, wynikiem jest tabela zawierająca wiersze wspólne dla obu argumentów.
Różnica. Różnica jest określona dla dwóch zgodnych relacji i odpowiada dokładnie różnicy teoriomnogościowej zbiorów wierszy tabel wyjściowych.

Algebra relacyjna może być uważana za proceduralny język zapytań modelu relacyjnego. To znaczy, że dowolna informacja jaka jest do uzyskania z relacyjnej bazy danych może być wydobyta za pomocą ciągu operacji algebry relacyjnej.

W praktyce w programowaniu aplikacji opartych na relacyjnych bazach danych nie korzysta się na ogół z języka proceduralnego, lecz z deklaratywnego języka opartego na tzw. rachunku relacyjnym (na ogół jest to SQL). Różnica polega na tym, że w języku proceduralnym formułuje się sekwencję kroków prowadzących do pożądanego wyniku, natomiast język deklaratywny służy do sformułowania tego, jaki wynik chcemy otrzymać. Oczywiście zapytanie sformułowane w języku deklaratywnym musi zostać przełożone na pewną procedurę aby mogło być wykonane -- jest to zadaniem implementacji DBMS. Bez znajomości żargonu algebry relacyjnej trudno jest jednak chociażby zrozumieć dokumentację systemów zarządzania baz danych (czy nawet opisy składni SQL).

Integralność danych

Model relacyjny dostarcza dodatkowych, specyficznych dla siebie postaci reguł integralności:

• Integralność encji: każda tabela musi posiadać klucz główny, a wartości klucza głównego muszą być w ramach tabeli unikalne i nie równe NULL. W szczególności, zapobiega to wystąpieniu w tabeli powtórzeń wierszy.

• Integralność referencyjna: każda wartość klucza obcego może być albo równa jakiejś wartości klucza głównego występującej w tabeli powiązanej, lub (ewentualnie) NULL. Pociąga to za sobą konieczność określenia reguły postępowania w wypadku usuwania wiersza z tabeli powiązanej, co mogłoby unieważnić niektóre wartości kluczy obcych w tabelach do niej się odnoszących. W grę wchodzą trzy postacie takiej reguły:

• Restricted: usunięcie wiersza jest zabronione, dopóki nie zostaną usunięte lub odpowiednio zmodyfikowane wiersze z innych tabel, których wartości kluczy obcych stałyby się wskutek tej operacji nieważne;

• Cascades: usunięcie wiersza powoduje automatyczne usunięcie z innych tabel wszystkich wierszy, dla których wartości kluczy obcych stały się nieważne;

• Nullifies: nieważne wartości kluczy obcych ulegają zastąpieniu przez NULL.

W praktyce zazwyczaj jest pożądane stosowanie dalszych warunków integralności (integralność dodatkowa). Na ogół istnieją w DBMS mechanizmy narzucenia takich warunków, sformułowanych w języku algebry relacyjnej lub zbliżonym.

Encje

Encja - oznacza interesując nas obiekt, coś co istnieje i jest rozróżnialne od innych obiektów tego samego typu (np.: samochód). Przyjmuje się, że encja jest dalej nierozbieralna.

Przykłady zbiorów encji:

• osoby,

• samochody,

• części zamienne,

Obiekt w zależności od poziomu abstrakcji traktujemy jako encję lub zbiór encji. Encje mogą istnieć rzeczywiście, bądź są wprowadzane jako obiekty abstrakcyjne.

ERD zajmuje się modelowaniem związków pomiędzy zbiorami encji.

2.2 Metody definiowania zbiorów encji:

• ekstencjonalnie – wyliczenie elementów np.: {męski, żeński, nijaki}, {Pn, Wt, Śr, Czw, Pt, So, Ni}, {a, b, c,...,x,y, z}, {0, 1,..., 9},

• intencjonalnie – specyfikacja własności np.: 
  ,

• operacje algebry zbiorów,

• operacje logiczne,

• nie sprecyzoowane np.: nazwisko,

2.3 Atrybuty encji:

Informacja o encji jest wyrażana przez zbiór par (atrybut, wartość), np.:

• kolor =“blue”,

• waga = 45,

• cena = 120,

• ilość = 3

 

Dany zbiór atrybutów może być traktowany jako typ encji. Zwykle w tabelach umieszcza się zbiory encji tego samego typu.

2.4 Klucz

Pojedynczy atrybut lub ich zestaw pozwalający jednoznacznie zidentyfikować encję. W danym zbiorze może być wiele kluczy.

Powiązania między encjami (zb. Encji) /relacje.

Założenia:

• encje są rozróżnialne,

• musi istnieć klucz,

• istnienie klucza wśród atrybutów zależy od interpretacji i zasięgu bazy danych,

• jeżeli zbiór atrybutów jest “nieodpowiedni” to przy określaniu klucza mogą być wykorzystane atrybuty innych encji wchodzących w skład związku, np.:




Rys. Przykład klucza złożonego

2.5 Zalety diagramów związków encji

• niezależność od systemu,

• przejrzystość,

• łatwość interpretacji

Diagramy ERD

ERD (ang. Entity Relationship Diagrams) - Diagramy związków Encji.

Diagramy związków encji przekształcają rzeczywisty świat na zbiory entek oraz relacji zachodzących między nimi. Znajdują one szerokie zastosowanie w projektowaniu baz danych, zwłaszcza przy analizie zależności funkcyjnych, usuwaniu problemów związanych z redundancją danych oraz przy organizacji struktury bazy.

Technikę tą wykorzystuje się również przy projektowaniu i specyfikacji oprogramowania nie tylko na etapie dotyczącym projektu baz danych, ale i przy projekcie i analizie poszczególnych modułów oprogramowania.

Celem tego opracowania jest pokazanie do czego i w jaki sposób wykorzystywane są diagramy związków encji oraz zapoznanie projektanta z technikami i notacjami ERD, oraz schematami postępowania przy usuwaniu typowych problemów mających miejsce przy projektowaniu baz danych.

_______________________________________________________________

5.Relacyjny model danych. Języki zapytań relacyjnych. Podstawowe instrukcje języka SQL w zakresie manipulowania danymi (nazwa, przeznaczenie).

Dane w relacyjnych bazach danych grupowane są w tablicach. Każda tablica składa się z wierszy i kolumn. Wiersze danej tablicy reprezentują konkretne wystąpienie rekordu, natomiast jej kolumny to pola tych rekordów. Terminologia stosowana w teorii baz danych jest następująca:

• tablice to relacje

• wiersze relacji to krotki

• kolumny relacji nazywane są atrybutami

Kolejnym pojęciem z teorii relacji jest dziedzina, która jest zbiorem wartości, do którego należą aktualne wartości w danej kolumnie. Dziedzinę należy określić w schemacie pojęciowym bazy i nadać jej odpowiednią nazwę. Kolumny z nią związane mogą mieć lecz nie muszą mieć tej samej nazwy.

Oto przykładowe relacje:

autorzy:

ID_Autora	Imię	Nazwisko
1	Agnieszka	Lesicka
2	Krzysztof	Barteczko
4	Andrzej	Marciniak
7	Craig	Hunt


Książki:

Sygnatura	Tytuł	Wydaw	Rok wyd.
100	TCP/IP	ReadMe	1996
200	Ogólne struktury danych	NAKOM	1995
300	Turbo Pascal	NAKOM	1994
500	Turbo Vision	NAKOM	1994
500	Programowanie obiektowe w c++	LUPUS	1994


Autor-Książka:

Sygnatura	Id_Autora
200	1
300	4
400	4
500	2
100	7



Podstawową własnością relacyjnej struktury jest to, że związki między krotkami są reprezentowane tylko przez wartości danych w kolumnach, pochodzących ze wspólnej dziedziny. Cechą charakterystyczną podejścia relacyjnego jest to, że cała informacja w bazie danych, czyli faktyczne dane jak i związki między nimi, jest przedstawiona w sposób jednolity właśnie za pomocą tablic. Licznością relacji nazywamy liczbę krotek; liczność relacji "Autorzy" wynosi zatem 4, a relacji "Książki" 5.

Definicja Relacji
Niech będą zbiory D1, D2,..., Dn niekoniecznie różne. R jest relacją na tych zbiorach jeśli jest to zbiór uporządkowanych n-krotek , takich, że d1 c D1, d2 c D2, ..., dn c Dn.ZbioryD1, ...,  Dn nazywamy dziedzinami relacji R, n zaś nazywamy liczbą członów relacji. Relacje jednoczłonowe nazywamy unarnymi, relacje dwuczłonowe nazywamy binarnymi a relacje n-członowe nazywamy n-arnymi.

Inna,równoważna definicja relacji mówi, że relacją R na zbiorach D1, D2, ..., Dn jest dowolny podzbiór iloczynu kartezjańskiego D1xD2x...xDn.

Krotki relacji nie muszą być uporządkowane w żaden sposób, gdyż relacja jest zbiorem, a w zbiorach uporządkowania się nie wymaga. W związku z tym w dowolnej relacji można w sposób dowolny zmienić kolejność krotek a uzyskana w ten sposób relacja nie ulegnie zmianie. Jednak często zdarzają się sytuacje, w których występuje jakieś uporządkowanie krotek relacji według wartości jednego lub kilku pól (wartości atrybutu). Ma to na celu na przykład ułatwienie i przyspieszenie procesu wyszukiwania informacji. Jeśli chodzi o uporządkowanie dziedzin (kolumn) relacji to z matematycznego punktu widzenia ich przestawienie powoduje zmianę relacji. Jednak, ponieważ użytkownicy odwołują się do kolumn za pomocą ich nazwy a nie położenia w tablicy w większości systemów baz danych ograniczenie to pomija się i przyjmujemy, że uporządkowanie kolumn jest nie znaczące.

Często zdarza się, że wartości pewnego atrybutu danej relacji jednoznacznie identyfikują krotki tej relacji. Przykładem może być relacja "Książki" gdzie takim atrybutem jest "Sygnatura". Każda krotka tej relacji ma inną wartość tego atrybutu. Można zatem użyć tego atrybutu do jednoznacznego odróżnienia krotek tej relacji. Taki atrybut nazywamy kluczem głównym relacji. Nie jest regułą, że klucz główny składa się z jednego atrybutu; jest to przypadek szczególny. W każdej jednak relacji istnieje pewna kombinacja atrybutów mająca zdolność jednoznacznej identyfikacji krotek. Na przykład w relacji "Autor - Książka" taką kombinacją jest para atrybutów (Sygnatura, ID_Autora). Taka kombinacja istnieje dla każdej relacji dlatego, że relacja jest zbiorem. Ponieważ zbiory nie zawierają identycznych elementów, więc każda krotka danej relacji jest różnaod innych, więc co najmniej kombinacja wszystkich atrybutów ma własność identyfikacji. W praktyce zazwyczaj nie korzysta się jednak ze wszystkich atrybutów. Istnieją takie relacje, dla których wiele atrybutów ma własność identyfikacji; mówimy wtedy, że relacje te mają więcej niż jeden klucz kandydujący. Dodatkowym pojęciem jest klucz obcy. Atrybut relacji R1 jest jej kluczem obcym, jeśli nie jest onkluczem głównym tej relacji ale jego wartości są wartościami klucza głównego innej relacji R2.Zaznaczmy, że dostęp do elementów relacji za pomocą relacyjnego subjęzyka danych nie musi być realizowany za pomocą klucza głównego. Na przykład operacje wyszukiwania nie muszą odbywać się po wartościach atrybutów kluczowych, lecz mogą dotyczyć dowolnego pola relacji.

Normalizacja
Jedynymi relacjami dozwolonymi w modelu relacyjnym są relacje spełniające następujący warunek:

Każda wartość w relacji, tj. każda wartość atrybutu w każdej krotce, jest wartością atomową (wartością nie rozkładalną).

Chodzi o to aby każdemu elementowi tablicy znajdującemu się na przecięciu dowolnego wiersza i dowolnej kolumny odpowiadała pojedyncza wartość, a nie zbiór wartości. Relacja, która spełnia ten warunek nazywana jest relacją znormalzowaną.

Relacja przed normalizacją:

D#	LC
		C#	ILOŚĆ
	D1	C1	300
		C2	200
		C3	400
		C4	200
		C5	100
		C6	100
	D2	C1	300
		C2	400
D3	C2	200
D4	C2	200
		C4	300
		C5	400



relecja po normalizacji:

D#	C#	ILOŚĆ
D1	C1	300
D1	C2	200
D1	C3	400
D1	C4	200
D1	C5	100
D1	C6	100
D2	C1	300
D2	C2	400
D3	C2	200
D4	C2	200
D4	C4	300
D4	C5	400


Rysunki powyżej przedstawiają przykład procesu normalizacji.

Relację "przed normalizacją" zdefiniowano na dwóch dziedzinach: D#, i LC. Jednak elementami dziedziny LC są również relacje (zdefiniowane na dziedzinach C# i ILOŚĆ. W związku z tym relacja ta jest relacją nie znormalizowaną. Relacja "po normalizacji" , która jest równoważna poprzedniej ale już znormalizowana. Pierwsza relacja jest z punktu widzenia definicji relacją dwuczłonową, ale nie wszystkie jej dziedziny są proste (dziedzina prosta to taka, której wszystkie elementy są atomowe). Relacja druga jest relacją trójczłonową, której wszystkie dziedziny są proste, jest więc znormalizowana. W podejściu relacyjnym bierze się pod uwagę tylko relacje znormalizowane. Powodem tego jest uproszczenie struktury danych, które z kolei powoduje uproszczenie operatorów w subjęzyku da- nych. Uproszczenia te nie ograniczają w niczym możliwości reprezentowania objektów.

Aby dokładniej omówić zagadnienie normalizacji wprowadźmy pojęcie zależności funkcjonalnej. Atrybut Y relacji R jest zależny funkcjonalnie od atrybutu X wtedy i tylko wtedy, gdy każdej wartości atrybutu X odpowiada dokładnie jedna wartość atrybutu Y. Wynika z tego, że jeśli dana wartość atrybutu Y występuje w wielu krotkach relacji R to jeśli atrybut X jest zależny od Y to w tych krotkach musi wystąpić ta sama wartość X. Przykładem może być relacja "Książka" gdzie atrybutem funkcjonalnie zależnym od atrybutu sygnatura jest atrybut autor, tytuł, itd. Pojęcie zależności funkcjonalnej można rozszerzyć do przypadku gdy atrybuty X lub Y są atrybutami złożonymi. Ma to miejsce w przypadku gdy dopiero jakaś kombinacja (np. para) atrybutów jednoznacznie określa nam obiekt i ma wyżej wymienione właściwości. Kolejnym pojęciem, które należy wprowadzić jest pełna zależność funkcjonalna. Mówimy, że atrybut Y jest w pełni funkcjonalnie zależny od atrybutu X, jeśli jest funkcjonalnie zależny od niego ale nie jest funkcjonalnie zależny od żadnego podzbioru atrybutu X (atrybut X jest atrybutem złożonym). W dotychczas przytoczonych przykładach wszystkie atrybuty relacji były funkcjonalnie zależne od ich kluczy. W takim przypadku mówimy, że relacja jest w co najmniej trzeciej postaci normalnej.



Pierwsza, druga, trzecia i czwarta postać normalna.

Na wstępie wprowadźmy ogólną definicję czwartej postaci normalnej.

Relacja R jest w czwartej postaci normalnej wtedy i tylko wtedy, gdy w dowolnej chwili każda jej krotka składa się z wartości klucza głównego identyfikującej pewną jednostkę oraz zbioru wzajemnie niezależnych wartości atrybutów opisujących ją. Dwa atrybuty są funkcjonalnie niezależne jeśli żaden nie jest funkcjonalnie zależny od drugiego.

Relacja jest w pierwszej postaci normalnej wtedy i tylko wtedy gdy wszystkie dziedziny podstawowe zawierają jedynie wartości atomowe. Czyli relacja jest w pierwszej postaci normalnej jeśli jest znormalizowana.

Relacja jest w drugiej postaci normalnej jeśli jest w pierwszej postaci normalnej i każdy jej atrybut niekluczowy jest w pełni funkcjonalnie zależny od klucza głównego.

Relacja jest w trzeciej postaci normalnej jeśli każdy jej wyznacznik jest kluczem kandydującym

Relacja R jest w czwartej postaci normalnej wtedy i tylko wtedy, gdy w każdym przypadku zależności wielowartościowej w R, np. atrybutu B od atrybutu A, wszystkie atrybuty tej relacji są również funkcjonalnie zależne od atrybutu A. WHERE pracownicy.id_działu= (SELECT działy.id_działu from działy where działy.nazwa_działu="ACCOUNTING");




1. System informacyjny: System informatyczny (SI) a system informacyjny. Geneza i zależności pomiędzy nieformalnym, formalnym i technicznym systemem informacyjnym.


System informacyjny - Układ odpowiednich elementów, którego zadaniem jest przetwarzanie danych.

System informatyczny - Wyodrębniona część systemu informacyjnego, w którym do przetwarzania danych zastosowano środki i metody informatyczne, a zwłaszcza sprzęt i oprogramowanie komputerów.

_____________________

9. Cykl życia systemu informatycznego: Modele cyklu życia systemu informatycznego i ich cechy wspólne.

Cykl życia SI (Software Life Cycle) - proces złożony z ciągu wzajemnie spójnych etapów pozwalający na pełne i skuteczne stworzenie, a następnie użytkowanie SI, obejmuje okres od momentu uświadomienia potrzeby istnienia systemu do momentu jego wycofania z eksploatacji.


Fazy cyklu życia systemu informatycznego:
1. Faza strategiczna 2. Określenie wymagań
3. Analiza systemowa
4. Projektowanie (modelowanie)
5. Implementacja
6. Dokumentacja
7. Testowanie
8. Instalacja
9. Konserwacja, rozwój

Modele cyklu życia SI:
- Kaskadowy (liniowy, waterfall)
- Przyrostowy - Ewolucyjny
- Model Fry'ego (model systemów baz danych)
- Model z prototypem                                                                                                                    - Spiralny


Model liniowy

- poszczególne fazy występują jedna po drugiej

- rozpoznane są wszystkie potrzeby - tworzenie, a potrzeby się zmieniają

- interpretacja ścisła - traktuje wszystkie fazy jako okresy, które nie nakładają się na siebie i są wykonywane w ściśle sekwencyjnym porządku

- interpretacja ogólna - poszczególne fazy maja raczej charakter koncepcyjny i mogą występować w tym samym czasie

Założenia

1. Na początku każdego projektu istnieje stabilny zestaw potrzeb.

2. Potrzeby nie zmieniają się w trakcie życia systemu.

3. Proces budowy systemu odbywa się stopniowo.

4. Każdy kolejny etap oznacza uszczegółowienie i przybliżenie do rzeczywistości.

5. Powoduje to powrót do poprzednich etapów w momencie, gdy nie mamy wszystkich elementów procesu projektowego.

Model ewolucyjny

1. Cały system podzielony jest na moduły.

2. Każdy z nich odbywa przejście przez kolejne fazy cyklu budowy systemu.

3. Na końcu działań projektowych przystępuje się do specjalnego etapu polegającego na integracji całego systemu i przeprowadzeniu testów.

4. W systemie podzielonym na części, których realizacja przesunięta jest w czasie, łatwiej nadążyć ze zmieniającym się celem działania.

5. Ponieważ każdy moduł stanowi początkowo organicznie odrębną część, należy zwrócić uwagę na niebezpieczeństwo związane z koniecznością integracji modułów w całość.

Model przyrostowy

1. Analiza dla całości systemu, powstaje koncepcja wstępna systemu.

2. System dzielony na moduły, a następnie projektowany, programowany i testowany dla każdego z nich osobno.

3. Spójność zapewniają - wspólne końcowe etapy - integracja systemu.

Model Fry'ego (model systemów baz danych)

Etapy

1. Sformułowanie zagadnienia i Analiza potrzeb - zabranie potrzeb informacyjnych użytkowników.

2. Modelowanie logiczne (konceptualne) - opis modelu danych i przyszłych procesów w systemie.

3. Projektowanie fizyczne - projekt struktury zbiorów, wzorców dokumentów, technologii przetwarzania, specyfikacji wewn.

4. Programowanie i Wdrożenie - stworzenie bazy danych i oprogramowanie zastosowań.

5. Eksploatacja i kontrola.

6. Modyfikacja i adaptacja - udoskonalenie funkcjonowania w wyniku pojawiających się nowych potrzeb.

Model z prototypem

1. Ogólne określenie wymagań.

2. Budowa prototypu.

3. Weryfikacja prototypu przez użytkownika.

4. Modyfikacja prototypu.

5. Realizacja zgodnie z modelem kaskadowym.

6. Eksploatacja i modyfikacja systemu.

Metody wykorzystywane do tworzenia prototypów

1. Niepełna realizacja - ?.

2. Języki wysokiego poziomu.

3. Wykorzystywanie gotowych procedur i bibliotek.

4. Generatory interfejsu użytkownika.

5. Szybkie programowanie (quick and dirty ?).

6. Paper ? - rozrysowanie interfejsu systemu.

Wady

• wysoki koszt tworzenia systemu

• wymaganie posiadanie odpowiednich narzędzi

• użytkownik dość długo oczekuje na gotowy system (a prototyp jest szybko)

Zalety

• wszystkie nieporozumienia są szybko wykrywane (użytkownik a projektant)

• szybkie wykrycie błędów i braków

• zaangażowanie użytkownika

• szybkie wykonanie prototypu

• ...

Model spiralny

Fazy

1. Rozpoczyna się ustalenia wstępnych wymagań i analizy ryzyka ich realizacji.

2. Na tej podstawie buduje się pierwszy prototyp i tworzy konceptualny plan całości.

3. Po kolejnej analizie ryzyka buduje się następny prototyp i tworzy się wymagania dotyczące oprogramowania.

4. Powstaje plan tworzenia i odbywa się kolejny etap zakończony projektem oprogramowania.

5. Kolejny obieg przynosi projekt szczegółowy, oprogramowanie, testy i wdrożenie.

1. Zastosowania SI: Klasyfikacja zastosowań systemów informatycznych. Pojęcie systemów ERP, CRM, HRM, CAD, CAM (objaśnienie skrótów i właściwości klas systemów).

Systemy ERP (Enterprise Resource Planning) (Planowanie Zasobów na potrzeby Przedsięwzięć) wywodzą się historycznie z opracowanego w latach 70. standardu zarządzania gospodarką materiałową MRP (Material Requirements Planning). Kolejna generacja tego standardu - MRP II - została rozbudowana o elementy związane z procesem sprzedaży i wspierające podejmowanie decyzji na szczeblach strategicznego zarządzania produkcją. W modelu MRP II bierze się pod uwagę wszystkie sfery zarządzania przedsiębiorstwem: przygotowanie produkcji, planowanie i kontrolę produkcji oraz sprzedaż i dystrybucję wyprodukowanych dóbr. Nowy model zarządzania - wprowadzany pod nazwą ERP lub MRP III - ma za pomocą bardziej wszechstronnych analiz i integracji informacji umożliwiać szybkie planowanie i korekcję działalności gospodarczej przedsiębiorstw. W Polsce często mamy do czynienia z aplikacjami typu ERP, a nie z wdrożeniem typu ERP. Wśród fachowców nie ma zgody, czy system nie obejmujący sfery produkcji zasługuje na miano ERP.

ERP - Enterprise Resource Planning (Planowanie Zasobów na potrzeby Przedsięwzięć)

- jest systemem obejmującym całość procesów produkcji i dystrybucji; 

- integruje różne obszary działania przedsiębiorstwa; 

- usprawnia przepływ krytycznych dla jego funkcjonowania informacji; 

- pozwala błyskawicznie odpowiadać na zmiany popytu. 

Obszary działań systemów klasy ERP: 

- obsługa klientów - baza danych o klientach, przetwarzanie zamówień, obsługa specyficznych zamówień (produkty na żądanie: assembly-to-order, make-to-order), elektroniczny transfer dokumentów (EDI); 

- produkcja - obsługa magazynu, wyznaczanie kosztów produkcji, zakupy surowców i materiałów, ustalanie terminarza produkcji, zarządzanie zmianami produktów (np. wprowadzanie usprawnień), MRP I/II, prognozowanie zdolności produkcyjnych, wyznaczanie krytycznego poziomu zasobów/zapasów, kontrola procesu produkcji (m.in. śledzenie drogi produktu w zakładach produkcyjnych) itd. 

- finanse - prowadzenie księgowości, kontrola przepływu dokumentów księgowych, pozwala przygotowywać raporty finansowe zgodnie z oczekiwaniami poszczególnych grup odbiorców (np. podział na centralę i oddziały); 

- integracja w ramach łańcucha logistycznego - cecha,  wyznaczająca przyszłe kierunki systemów ERP, powodując ich wyjście poza przedsiębiorstwo. 

CRM - Customer Relationship Management (Zarządzanie Relacjami z Klientami) - to kompleksowa strategia biznesowa dotycząca obszarów organizacji, technologii i kapitału ludzkiego, której celem jest podnoszenie wartości firmy poprzez budowanie wartościowych relacji z klientami.

   Pozwala na zbieranie i wymianę informacji o klientach, rynkach i produktach oraz na ich wymianę między handlowcami i pracownikami marketingu.

   Oprogramowanie tego typu może funkcjonować samodzielnie lub być dołączone do systemu ERP.

   CRM to zintegrowany system, który obsługuje marketing, sprzedaż, serwis i wsparcie techniczne. W jednym miejscu, wysiłkiem kilku działów przedsiębiorstwa, są gromadzone dane o kliencie.  

HRM - Human Resources Management (Zarządzanie Zasobami Ludzkimi)

jest to strategiczne dysponowanie zasobami ludzkimi, czyli pracownikami. Najbardziej ogólnie rzecz definiując w zakres HRM wchodzą:

1. strategie i plany naboru pracowników i etapów przygotowawczych do naboru (w tym: prognozowanie potrzeb w zakresie personelu, rekrutacja, selekcja, zatrudnienie) ,

2. strategie motywowania i utrzymywania pracowników (w tym: planowanie kariery, szkolenie, systemy wynagrodzeń, nagród, dodatków i świadczeń),

3. strategie rozstawania się z pracownikami (w tym: plany zwolnień, systemy wcześniejszych emerytur, systemy zwolnień monitorowanych, rozwiązywanie umów przez pracowników).

Strategiczna, jednorodna i spójna metoda kierowania najcenniejszym z kapitałów każdej organizacji - ludźmi, którzy osobistym i zbiorowym wysiłkiem przyczyniają się do realizacji wszystkich założonych przez organizację celów, a tym samym umacniają jej przewagę konkurencyjną.

CAD - Computer Aided Design (projektowanie wspomagane komputerowo)

Służyło tylko do graficznego przedstawienia pomysłu inżyniera w postaci płaskiej dokumentacji technicznej. Obecnie coraz częściej przy użyciu systemów CAD powstają wirtualne modele bryłowe projektowanych produktów.

Komputerowo wspomagane projektowanie. Oznacza skomputeryzowany proces projektowania części produktów lub proces dokonywania zmian w wyrobach już istniejących. Centralnym elementem CAD'u jest komputer z dobrym oprogramowaniem graficznym pozwalającym projektantowi na manipulowanie geometrycznymi obrazami projektowanych wyrobów. Taki system wykonuje prace kreślarskie (w przeszłości ręczne) - projektant tworzy wzory, a CAD rysuje np. rzuty. Komputer może symulować reakcje części i materiałów w różnych sytuacjach i przeprowadzać różne testy. Oszczędza to wiele czasu potrzebnego niegdyś na wykonanie projektu. Używając danych zgromadzonych w pamięci komputera użytkownik może szybko uzyskiwać potrzebne plany i specyfikacje dowolnego produktu w dowolnym czasie. Użytkownik może wykorzystywać CAD do gromadzenia, wyciągania, klasyfikowania danych dotyczących różnych produktów m. in. do automatycznego generowania produktów, które stanowią podstawę do technologii niskokosztowej. CAD jest bardzo użyteczny przy tworzeniu, zapobiega marnotrawstwu czasu projektantów przy przemodelowaniu różnych standardowych elementów maszyn.

Zastosowanie komputera do projektowania: architektury, układów elektr., części maszyn, mebli, ubrań i in.; systemy CAD wymagają komputerów o stosunkowo dużej mocy obliczeniowej i dobrej grafice, a także wyposażenia ich w urządzenia (wejścia i wyjścia) pozwalające na otrzymanie obrazów odpowiedniej jakości; popularnym przykładem takiego systemu jest AUTOCAD dla komputerów IBM PC.

CAM - Computer aided manufacturing (wytwarzanie wspomagane komputerowo) Dzięki programom na specjalnych obrabiarkach wytwarzane są ich prototypy.

Systemy CAD/CAM oferują następujące możliwości:

- tworzenie parametrycznego modelu bryłowego: generowanie rysunków czy prezentacji, zapisanie wielu wariantów w bazach danych;

- przeprowadzenie symulacji kinematycznych;

- przeprowadzenie analizy wytrzymałościowej metodami MES;

- wygenerowanie kodów sterujących obrabiarkami CNC (frezarki, tokarki, drążarki elektroerozyjne, wiertarki);

- szybkie wytwarzanie modeli i narzędzi;

- wykonywanie operacji kontrolno-pomiarowych

- zarządzanie dokumentacją techniczną.

Programy typu CAM mogą być programami samodzielnymi i wówczas przeważnie wyposażone są w moduł do projektowania CAD. Mogą one również być nakładkami współpracującymi z aplikacjami CAD.

12. Zarządzanie projektami

Oprogramowanie wspierające zarządzanie projektami.

Czynniki krytyczne sukcesu

Projekt - przedsięwzięcie, w którym mamy cel, koszty i okres realizacji

Sukces projektu - nie przekroczony czas, długotrwałe zadowolenie klienta

Atrybuty sukcesu projektu:




• Wewnętrzny punkt widzenia (kierownika)

- Zgodność ze specyfiką

- Terminowość

- Zaplanowane koszty

• Zewnętrzny punkt widzenia (klienta)

- Rezultat rzeczywiście wykorzystywany

- Dla właściwego użytkownika

- Oczekiwana jakość

- Satysfakcja klienta




Sukces projektu - uwarunkowania:

• Techniczne możliwości realizacji

• Możliwości organizacyjne

• Efektywność rezultatu

Przyczyny niepowodzeń:




• Wymagania/cele:

- niejasne, słabo zdefiniowane, zmienne, dwuznaczne, mętne, nieścisłe

• Oceny/szacunki:

- nieprecyzyjne, brak doświadczenia, brak danych historycznych

• Pracownicy:

- zbyt późno zatrudnieni lub w niepełnym wymiarze czasu, nieodpowiednie kwalifikacje, „krzywa uczenia”

• Finanse:

- brak celów i śledzenia wydatków, brak oceny kosztów, zmian w projekcie

• Narzędzia:

- niewłaściwie dobrane lub używane, wymagające dużych dodatkowych nakładów (czasu, kosztów), mało efektywne (krzywa uczenia się)

• Planowanie/kontrola:

- brak udokumentowania planów, brak formalnego systemu zarządzania projektami, niezdefiniowany sposób kontaktowania się z użytkowaniem, nieprecyzyjny system śledzenia postępu prac.

• Technologia:

- zły wybór, zbyt skomplikowana, niedojrzała, nierozwijalna, niekonserwowana

• Złożoność projektu:

- wielkość przewyższająca możliwości kontroli, wielkość zespołu, liczność kontaktów, lokalizacji, duża liczba zmian w projekcie

_____________________________

Rola i zadania kierownika projektu

Kierownik projektu - zadania

• Planowanie, recenzowanie, dostosowanie, poprawianie

• Realizacja: terminów, kosztów, celów

• Spełnienie potrzeb i oczekiwań klientów

• Szkolenie, kierowanie, motywowanie zespołu

• Dokumentowanie

• Kontakty z kierownictwem, klientami, kierownikami etapów (podprojektów), dostawcami

• Projektowanie, rozwój

• Scalanie systemu, testowanie

• Wdrażanie, funkcjonowanie

• ...

Co robi kierownik?

• Bezpośrednio zarządza pracą zespołu projektowego

• Ocenia, steruje kosztami, terminami i zakresami

• Kontaktuje się: z komitetem sterującym, członkami zarządu, użytkownikami końcowymi, kontrolą jakości, dostawcami usług i towarów, pracownikami mającymi wpływ na projekt, zespołem projektowym, przedsiębiorstwem (finanse, prawnik, kadry, administracja)




_____________________

Struktura organizacyjna projektu.

Struktura prac w projekcie

Proces planowania




Plan

• Zbiór dokumentów ustalających, w jaki sposób (zadania, kolejność realizacji, czas, zasoby) mają być wykonane wszystkie prace w projekcie

• Plan może zawierać:

• Schematy realizacji prac

• Opis sposobu wykonywania prac

• Haromonogram, kalkulacje

• Listę założeń, przy których opracowano plan

Punkt węzłowy

• Zdarzenie kluczowe lub mini cel (cel pośredni) w planie identyfikowane w sposób jednoznaczny przez rezultaty cząstkowe

• Ciąg punktów węzłowych rozpoczyna się na początku projektu i kończy się wraz z jego ukończeniem, wyznaczając tym samym ciąg prac doprowadzających do realizacji

Czym powinien być punkt węzłowy?

• Pomocą do zrozumienia celów projektów

• Podstawą do planowania i zarządzania projektem

• Elementem łączącym podprojekt w projekt

• Wspomaganiem sprawozdawczości

• Potwierdzeniem osiągania rezultatów projektu

• Czynnikiem psychologicznym

• Podstawą do śledzenia i wykazywania postępów projektu

Struktura prac - definiowanie zadań

• Hierarchiczny podział (dekompozycja) projektu na elementy składowe (zadania, wyraźnie oddzielone od siebie i jednoznacznie identyfikowane poprzez ich rezultat końcowy)

• Struktura drzewiasta składająca się z:

• Podprojektów, projektów cząstkowych

• Pakietów prac

• Grup zadań

• Zadań

Struktura prac - drzewo




Struktura prac - zasady opisu

• Każdy węzeł w strukturze powinien być związany z konkretnym rezultatem końcowym

• Każdy węzeł (i jego rezultat) powinien być przypisany do konkretnej osoby, zespołu, firmy - odpowiedzialność

• Ukończenie prac przypisanych do węzła powinno być weryfikowane, tj. poddające się kontroli

• Każdy węzeł powinien składać się z nie mniejszej i nie większej liczby podzadań niż wykazano w strukturze prac (hierarchiczność)

Struktura prac - przeznaczenie

• Planowanie prac (struktura, zakres)

• Szacowanie kosztów

• Harmonogramowanie

• Definiowanie rezultatów prac i ich koordynacja

• Śledzenie i kontrola procesu

• Określenie rezultatów końcowych

• Definiowanie zakresów odpowiedzialności

• Identyfikacja ryzyka

__________________________

Harmonogramowanie.

Projekt planów zarządzania:

• Niektóre plany wiążą się z zarządzaniem pracą:

• Plan zadań (harmonogram pracy, zadania i zdarzenia w czasie)

• Plan punktów węzłowych

• Plan zasobów

• Plan dostaw

• Plan eksploatacji

• Inne z zarządzaniem jakością, np.:

• Plan testowania

• Plan akceptacji

• Plan szkolenia

• Plan rewizji i przeglądów

• Plan finansowy

• Plan ryzyka

Techniki planowania realizacji projektu

• Wykres Gantta

• Wykresy punktów węzłowych

• Metody analizy sieciowej (CPM, PERT)

Terminologia

• Harmonogram - podział pracy w czasie

• Sieć (logiczna) - wyrażająca następstwo, tj. kolejność wykonywania (reprezentacja zadań do wykonania)

• Zadanie / Czynność / Operacja - działanie, którego wynikiem jest osiągnięcie konkretnego celu (musi być związane z konkretnym wynikiem końcowym). Każde zadanie ma zdefiniowany punkt początkowy oraz końcowy (Start / Koniec) oraz zużywa czas i inne zasoby. Zadania mają swoje poprzedniki i następniki.

• Zdarzenie:

• Moment rozpoczęcia lub zakończenia zadania

• Punkt węzłowy

• Zdarzenia nie zużywają czasu ani środków

• Ścieżka krytyczna - nieprzerwany ciąg zadań, od początku do końca siatki zależności o najdłuższym czasie realizacji.

Ścieżka krytyczna determinuje czas trwania projektu.

_________________________

Metoda Gantta

• Harmonogram realizacji zadań

• Harmonogram szczególnych zdarzeń

• Określenie terminów rozpoczęcia i zakończenia zadań

Stosowanie wykresów punktów węzłowych ma:




Zalety:

• Doskonałe do prezentacji wizualnych

• Zrozumiałe i akceptowalne

• Wykonywalne przez kierownika projektu lub podprojektu

________________________________

Wady:

• Niezbyt jasno zaznaczone zależności, które mogą być przyczyną błędów planowania

• Trudne do zmiany

• Trudne w użyciu do harmonogramów analitycznych




Metody sieciowe (CPM, PERT)

CPM - Critical Path Method

PERT - Program Evaluation and Review Technique

• Ustalenie programu działania (pełnej listy zadań)

• Ustalenie wzajemnych zależności między nimi (poprzedniki, następniki, „puste”)

Dla każdego zadania niezbędne są:

• Opis zadania

• Odpowiedzialność personalna

• Określenie pracochłonności

• Planowany czas realizacji

• Termin rozpoczęcia zadania (możliwy najwcześniejszy / dopuszczalny najpóźniejszy)

• Termin zakończenia j.w.

Dla każdego zadania wyróżniamy cztery terminy:

• Dla początku zadania:

• NWP - najwcześniejszy możliwy

• NPP - najpóźniejszy dopuszczalny

• Dla końca zadania:

• NWK - najwcześniejszy możliwy

• NPK - najpóźniejszy dopuszczalny

Reprezentacja zadań w metodzie sieciowej





Reprezentacja

Ścieżka krytyczna:

• Jeżeli dla danego zadania NWP=NPP i NWK=NPK to zadanie ma charakter krytyczny

• Wszystkie zadania krytyczne tworzą ścieżkę krytyczną, biegnącą od zdarzenia początkowego do końcowego

• W każdej sieci istnieje zwykle jedna ścieżka krytyczna, ale może wystąpić ich więcej

• Każde przedłużenie czasu realizacji zadania leżącego na ścieżce krytycznej musi spowodować opóźnienie terminu ukończenia projektu, jeżeli nie zajdą żadne inne zmiany

• Każde skrócenie czasu realizacji zadania leżącego na ścieżce krytycznej może (ale nie musi) spowodować przyspieszenie terminu ukończenia projektu, jeżeli nie zajdą żadne inne zmiany.

Ścieżka krytyczna - budowa




1. Opracowanie struktury sieci i czasu trwania zadania

2. Wyznaczenie terminów najwcześniejszych od początku do końca

3. Wyznaczenie terminów najpóźniejszych (od końca)

4. Odszukanie ścieżki krytycznej

Metody sieciowe są:

• Narzędziem zarządzania pomagającym określić, co ma być zrobione, aby terminowo osiągnąć cel przedsięwzięcia

• Techniką dostarczającą kierownictwu informacji ilościowych niezbędnych do podejmowania decyzji

• Techniką skupiającą uwagę kierownika na czynnikach czasu, środkach pracy mogących podnieść efektywność wykonania przedsięwzięcia

___________________________

Techniki estymacji

Agenda

• Definicja estymacji

• Czynniki wpływające na poprawność estymacji

• Różnica pomiędzy oszacowaniem czasu a terminem realizacji

• Techniki szacowania parametru projektu

Problemy w określeniu parametrów projektu

Projekty są zróżnicowane ze względu na istniejące doświadczenia oraz uwarunkowania realizacji:

• Bardzo dobrze określone - standardowe

• Dość dobrze określone

• Nowatorskie

Estymacja służy do określenia zasobów potrzebnych do realizacji projektu.

Estymacja - jest oszacowaniem, oceną ilościową nieznanych wartości projektu.

Estymator - (oszacowanie) jest wielkością probabilistyczną a nie deterministyczną (np. najlepszy przypadek, najgorszy, najbardziej prawdopodobny, średni) o pewnym poziomie zaufania i uzyskaną przy pewnych założeniach (np. czas podróży, dostępność sprzętu).

Co należy szacować w projekcie?




• Pracochłonność

• Kwalifikacje i umiejętności pracowników

• Założenia i ograniczenia

• Urządzenia i materiały, ich wykorzystanie

• Opłaty, koszty pośrednie

• Czas pracy urządzeń

• Poziom obsługi serwisowej, naprawy

• Parametry dostaw

• Podróże

• Czas nieprodukcyjny

• Wynagrodzenia

• Nagrody




Klasy dokładności estymacji

Klasa	Typ kosztów	Dokładność
I	Główne	± 5%
II	Wysokie	± 10-15%
III	Poboczne (wysokie)	± 15-30%
IV	Poboczne	± 20-25%
V	Widoczne	± 25-35%
VI	Mało ważne, niewielkie	± 35%

Założenia estymacji:

• Przed przystąpieniem do estymacji parametrów projektu należy przygotować listę założeń, przy których ocena będzie dokonywana, z podziałem na:

• Założenia oczywiste

• Przypuszczenia

• Np. czas podróży w zależności od miejsca i pory, wydajność pracowników w zależności od kwalifikacji

Straty czasu związane z projektem:

- podróże

- spotkania,

- bezwładność,

- współużytkowanie zasobów,

- brak motywacji

Straty czasu niezwiązane z projektem

- urlopy, dni wolne, święta

- spotkania niezwiązane z projektem

- dokształcenie

- choroby, macierzyństwo

- udział w innych projektach

- telefony

- sprawy osobiste

Inne straty czasu:

- powtarzanie lub dublowanie prac

- wielkość zespołu

- wielkość projektu

- pomoc innym

Techniki szacowania zasobów (1)

• Analogia - przypuszczenie poparte doświadczeniem (reguła „kciuka” lub „sufitu”) - wymaga posiadania dużego doświadczenia w analogicznych (podobnych) projektach.

• Ekstrapolacja - parametryzacja - opracowanie formuł lub procedur na podstawie istniejących doświadczeń i przeniesienie ich na nowe projekty - wykorzystanie mierzalnych parametrów projektu, np. liczba modułów

• Inżynierska - bazująca na strukturze prac - budowa struktury prac, ocena każdego zadania i sumowanie ocen cząstkowych - wg schematu: dekompozycja - estymacja

• Inne - metoda delficka „burza mózgów”

Parametryzacja - metoda linii kodu


,gdzie:


- ilość osobom miesięcy (pracownik pisze 170 linii kodu oszacowania systemowego/miesiąc)


- ilość linii kodu


- współczynnik trudności (K=1,2,...3)

Metoda linii kodu - współczynnik trudności

a = (0....0,5) - doświadczenie zespołu

b = (0....0,7) - zmienność wymagań

c = (0....0,3) - ograniczenia sprzętowe

d = (0....0,2) - wymagania realizacji zadań

e = (0....0,4) - ograniczenia zewnętrzne

K = 1 + a + b +c + d + e

Metoda linii kodu - szacowanie liczebności zespołu i czasu


, gdzie:


- liczebność zespołu [osoby]




T - czas realizacji zadań [m-c]

__________________________________________

Metoda punktów funkcjonalnych - atrybut produktywności

• Wydzielenie atrybutów produktywności zespołów w projektach informatycznych

• Wyznaczenie na podstawie szacowanych wartości atrybutów produktywności ilości punktów funkcyjnych jako miary produktywności zespołu w projekcie

• Estymacja zużycia zasobów na realizację projektu

Atrybuty produktywności dla nieistniejących systemów - parametry funkcji użytkownika systemu (elementy przetwarzania informacji w systemie):

- wejście

- wyjście

- zbiory danych wejścia

- zbiory danych wyjścia

- zapytania

Metoda punktów funkcyjnych - cele

- możliwość porównania dwóch systemów pod kątem zużycia zasobów

- pomiar i analiza produktywności różnych zespołów

- szacunek zasobów niezbędnych do realizacji

- uświadomienie użytkownikowi wielkości systmu

Metoda punktów funkcyjnych - nieskorygowane punkty (NPF)




NPF - nieskorygowane punkty funkcyjne

Wij - wartość współczynnika wagi

Nij - ilość elementów w projekcie

i - numer elementu przetwarzania danych

j - numer poziomu złożoności danych

Metoda punktów funkcyjnych - czynniki korygujące

1. Występowanie urządzeń komunikacyjnych

2. Rozproszenie przetwarzania

3. Wymagania szybkości działania

4. Skomplikowana logika przetwarzań

5. Stopień obciążenia (ilość transakcji)

6. Wprowadzenie danych w trybie bezpośrednim

7. Wydajność użytkownika końcowego

8. Rozproszenie terytorialne (użytkownicy z różnych działów)

9. Aktualizacja danych w trybie bezpośrednim

10. Złożoność przetwarzania danych

11. Przenośność

12. Łatwość instalacji

13. Łatwość obsługi

14. Łatwość wprowadzenia zmian - pielęgnowanie systemu

Metoda inżynierska - bazująca na strukturze prac

- podział pracy na zadania (struktura prac)

- estymacja potrzebnych zasobów dla każdego drobnego zadania

- sumowanie ocen

- dekompozycja estymacja synteza

Metoda punktów funkcyjnych PF




Kkov - kompleksowy współczynnik korygujący

Kj - wartość oceny czynnika korygującego

Metoda Delficka

- pozyskiwanie wiedzy od grupy ekspertów i uzyskanie rzetelnej jednomyślnej grupy

- wielokrotna (4 rundy) estymacja parametrów przez grupę w trybie:

ocena powiadomienie o rezultacie uzasadnienie starych ocen

korekta (porównanie ocen)

- oceny i uzasadnienie są przekazywane całej grupie (bez podawania konkretnych ekspertów)

_________________________________________________

Zarządzanie ryzykiem

„...nie ma nic trudniejszego do zorganizowania, bardziej niebezpiecznego do przeprowadzenia i o bardziej wątpliwym pomyślnym zakończeniu aniżeli wdrożenie nowego systemu...”

Co to jest ryzyko?

• Sytuacja, która się jeszcze nie zdarzyła

• Możliwe i niepożądane zdarzenie, które może spowodować jeden lub wiele celów projektu nie zostanie osiągnięty

• Narażenie działań na niepożądane konsekwencje

• Coś, co może się zdarzyć i spowodować fiasko projektu w jakimś lub wszystkich aspektach.

Źródła ryzyka:

• SE - otoczenie socjoekonomiczne

• TE - otoczenie technologiczne

• OR - organizacja

• TS - twórcy systemu

• PR - projekt

Źródła ryzyka - obszary:

• Biznes - konkurencja, niepewność, finanse

• Użytkownik - klient - wymagania, nastawienie

• Technika i technologia - złożoność, nowatorstwo, definiowanie i harmonogram dostawcy

• Realizacja - profesjonalizm zespołu, klienta

• Otoczenie

• Zarządzanie projektem

Źródła ryzyka:

• Wewnętrzne - spowodowane samą naturą procesu: projekt = zmiana

• Narzucone - obowiązujące warunki, np. czas ukończenia, które mogą uczynić cele projektu nieosiągalne

• Wprowadzone

Czynniki ryzyka:

• Wystokie wymagania, co do efektywności i / lub niezawodność produktu

• Czynniki obiektywne

• Duża zmienność definicji, wymagań, organizacji, planów

• Systemy heterogeniczne

• Brak kultury zarządzania projektem w organizacji

Czynniki ryzyka - etap analizy wymagań:

• Nieokreślony zakres projektu

• Płynne terminy i plany

• Źle zrozumiane wymagania użytkownika

• Brakujące wymagania

• Niedoszacowanie

• Dwuznaczność, niesprawdzalność, niespójność

• Brak analizy wymagań pochodnych

• Brak formalizacji wymagań sprawnościowych

• Brak kryteriów akceptacji

Czynniki ryzyka - zagrożenia spoza projektu:

• Niewypełniane zobowiązań przez klienta

• Opóźnienie dostaw

• Zła jakość dostaw

• Nieformalność zobowiązań

• Zła jakość prac podzleceniodawców

• Działanie siły wyższej

Etap zarządzanie projektem:

• Nieudokumentowany lub niezrozumiały system realizacji projektu

• Nieformalny system zarządzania zmianami

• Dopuszczanie problemów nieudokumentowanych, nieprzypisanych do osób

• Brak przeglądów prac lub ich nieefektywność

• Niejasny sposób rozliczania z realizacji zadań

• Brak lub źle wytyczone obszary odpowiedzialności

• Niedostateczne zobowiązania kontaktowe

Dwa podejścia do ryzyka






Wyprzedzające (aktywne)

wczesna identyfikacja zagrożeń i ich unikanie.

• Kierownik Projektu

• Zabezpieczenia na etapie propozycji

Przeciwdziałające (reaktywne) wykrywanie i naprawianie szkód.

• Specjalne przeglądy i rewizje

• Zewnętrzny nadzór

• Zabezpieczanie na etapie realizacji




Zarządzanie ryzykiem - potrzeba

Bez ryzyka nie ma korzyści

Jeżeli nie analizujemy ryzyka, to automatycznie trafimy na kłopoty

Zarządzanie ryzykiem - proces

• Realizowany przez specjalistów i kierowników

• Zwiększający szanse osiągnięcia sukcesu do wystarczającego poziomu pewności

• Wykorzystany we wszystkich fazach projektu

Zarządzanie ryzykiem - struktura procesu




Identyfikacja i dokumentacja potencjalnych źródeł ryzyka

Ryzyko a koszty i korzyści

• Ryzyko - jeżeli się wydarzy ma wpływ na projekt ze względu na:

• Dodatkowy koszt

• Późniejsze zakończenie prac

• Obniżenie funkcjonalności, zakresu, lub jakości produktów

Działania zapobiegawcze

Czynniki ryzyka Działania zapobiegawcze

1) Ludzkie słabości 1) Właściwy dobór zespołu i rozdział zasobów




2) Nierealny budżet i harmonogram 2) Szczególne szacowanie kosztów,

uwzględnienie niesprzyjających

okoliczności

Sterowanie ryzykiem

• Monitorowanie, śledzenie ryzyka

• Eliminowanie, unikanie ryzyka poprzez: protytowanie, wybór danych rozwiązań, projektowanie równoległe

• Minimalizacja, redukcja ryzyka: właściwe planowanie (rezerwa), przenoszenie ryzyka na innych (dostawców, zleceniodawców, klienta)

Kiedy należy identyfikować ryzyko?

• Przed rozpoczęciem projektu

• Podczas definiowania projektu

• W punktach węzłowych projektu

• Podczas rewizji i przeglądów prac i ich jakości

• Na końcu każde4j fazy projektu

• Ilekroć jest to wymagane

• Wielokrotnie przez cały cykl życia projektu

Jak identyfikować obszary ryzyka?

1. Metody

• Zdrowy rozsądek

• Doświadczenie osobiste

• Doświadczenie innych

• Dane historyczne

• Wykorzystanie niezależnych ekspertów

• Narzędzia i pomoce np. systemy ekspertowe

1. Techniki

• Listy kontrolne

• Spotkania definiujące projekt

• Przeglądy i rewizje projektu

• Konsultacje

• Specjalne spotkania identyfikujące ryzyko

Najważniejsze przyczyny porażek

• Źle zrozumiałe wymagania

• Niedoszacowanie czasy i koszty

• Nieefektywny system zarządzania

• Brak specjalistów, kiedy potrzebni

• Opóźnienie prac przez podwykonawców

• Opóźnienie własnych prac

• Niska jakość dostarczanych produktów

• Wymagana sprawność nie do osiągnięcia

_____________________________________________________

Zarządzanie projektami z wykorzystaniem wskaźników ekonomicznych.

Ocena efektywności PI

• W ocenie projektów internetowych najczęściej używaną metodą oceny efektywności przedsięwzięcia jest wskaźnik ROI (Return On Investment) - metoda oceny zwrotu a inwestycji.

• Pomimo tego, że jest to wskaźnik statyczny i nie uwzględnia zmian wartości pieniądza w czasie, to jest prosty w interpretacji i chętnie stosowany we wszelkich obliczeniach wstępnych, a także na potrzeby prezentacji wstępnie szacowanych korzyści wdrożenia projektu

• Wskaźnik ROI definiuje się jako stosunek zysków przyniesionych przez inwestycję do początkowych nakładów inwestycyjnych

• Jest to prosty wskaźnik wyliczany w nieskomplikowany sposób i choć dosyć zgubny, to obok wskaźnika TCO jest szeroko wykorzystywany w wielu dziedzinach

• Stosowanie metody ROI nie wyklucza innych metod (np. uwzględniających zmianę wartości pieniądza w czasie).

18

Zarządzanie projektami

Wykład V - 22.11.2004

22

Zarządzanie projektami

Wykład IV - 8.11.2004

24

Zarządzanie projektami

Wykład VII - 06.12.2004

29

1

32

POZIOM 4

POZIOM 3

POZIOM 2

POZIOM 1

POZIOM 0

Połączenie z hostem

LAN 1

System B

System A

Sieć

Terminale

Oprogramowanie

Sprzęt

Integracja

Podprojekt 2

Podprojekt 1

Projekt

Dokumentacja

Zdefiniowania zadań

Ocena zasobów (ludzie, koszty, sprzęt, materiały) zadań

Kto i czym?

Ocena czasu realizacji zadań

Jak długo?

Za ile?

Scalenie planu

Opracowanie

harmonogramu

Co i kiedy?

Szeregowanie

zadań

W jakiej kolejności?

Co?

Cele i organiczenia

Rezultaty, czas, koszty, zasoby

Nr zadania

Opis zadania

Najpóźniejszy termin rozpoczęcia

Najpóźniejszy termin zakończenia

Najwcześniejszy termin rozpoczęcia

Najwcześniejszy termin zakończenia

Czas realizacji

Identyfikacja

Ocena

Zapobieganie

Monitorowanie

Poziom 3

Poziom 2

Poziom 1

P3.1

P3.2

P3.3

P2.1

P2.2

P1

P3.1

P3.2

P3.3

P2.1

P2.2

P1

---