OCL:

Reguła biznesowa jest stwierdzeniem, które definiuje lub ogranicza pewne elementy/aspekty biznesu. Opisuje operacje definicje i ograniczenia, które stosuje się do organizacji zapewniając osiągnięcie jej celów; jest abstrakcją polityki i praktyk stosowanych w organizacji.

Kategorie reguł:

• Definicja terminów biznesowych (np. obywatel polski, posiadający adres zam. w POLSCE…)

• Fakty pokazujące relacje między terminami (Czytelnik może wypozyczyć ksiązkę)

• Ograniczenia (określenie zachowania, wartość; mozna mieć wypozycz. max 5 ksiązek w jednym czasie.)

• Wnioskowania (wiedza z jednej postaci przekształcona w inną wiedzę- Czytelnik musi mieć PESEL)

stereotypy : Element klasyfikacyjny, używany do specjalizacji (uzupełnienia) semantyki elementu modelu już zdefiniowanego w języku np.: (<<nazwa>>)

wartosci znakowane : Bezpośredni opis właściwości elementu modelu w postaci pary nazwa – wartość (Name = Value ;Name)

Ograniczenia : Semantyczny warunek lub zawęzenie nałozone na element modelu/ restrykcja nałozona na jedną lub więcej wartości (części) modelu lub systemu obiektowego

Składnia : Zdefiniowana przez OCL - Object Constraint Language zapisywane w nawiasach klamrowych {ograniczenie}

Przykłady

{ subset } { x.a > 10 } { ordered }

Dzięki ograniczeniom uzyskuje się:

• poprawienie jakości dokumentacji

• zwiększenie precyzji diagramów

• polepszenie zrozumienia miedzy klientem a projektantami

Dowolne elementy modelu UML (klasy, atrybuty, operacje) mogą być opatrzone ograniczeniami, zapisywanymi w nawiasach {}.

Ograniczenia na model system mogą przyjąć postać:

1. niezmienników dla atrybutów klasy

2. niezmienników dla asocjacji klasy

3. określenia warunków początkowych i końcowych realizacji operacji

4. ograniczeń dla relacji generalizacji

5. precyzowania sposobu postępowania z kolekcjami

W UML są zdefiniowane 3 stereotypy odpowiadające pojęciom 1-3:

«invariant», «precondition» oraz «postcondition>>

Język OCL – podstawy

Charakterystyka języka OCL:

- język deklaratywny

- kontekstowy język wyrażeń

- silnie typizowany z rozbudowaną hierarchią typów

- bez tzw. efektów ubocznych (nie zmienia stanu modelu)

- prosty (zgodnie z deklaracją autorów)

Wyrazenia OCL są wykorzystywane m.in. do definicji:

1) inwariantów (niezmienników) klas,

2) warunków pre i post dla operacji

3) specyfikacji wyrażeń nawigacyjnych

Ograniczenie OCl jest wyrażeniem OCL typu Boolean.

Wyrazenie OCl to wyrazenie napisane zgodnie z regułami języka OCL.

Typy predefiniowane:

• typy podstawowe

• typy kolekcyjne

Predefiniowane typy podstawowe to:

Integer, Real, String i Boolean

• Boolean – true, false

• Integer -–…-1, 0, 1, …

• Real -– liczby rzeczywiste...

• String -– ‘ciąg znaków’

Uwaga:

UML dopuszcza stosowanie typu wyliczeniowego. Aby odwołać sie do wartości takiego typu w języku OCL należy poprzedzić go symbolem #.

Inwariant (niezmiennik) klasy – wyrazenie logiczne, które powinno być spełnione w kazdym momencie przez wszystkie obiekty danej klasy.

context [nazwa_obiektu:]nazwa_klasy

inv [nazwa_inwariantu]: warunek_logiczny -- inwariant 1

inv [nazwa_inwariantu]: warunek_logiczny -- inwariant 2

Przykład: Osoba ma co najmniej 18 lat

context Osoba inv:

self.wiek > 18

context Osoba inv:

wiek > 18 -- self opuszczony

context os: Osoba inv: -- os – jawna nazwa instancji klasy Osoba

self.wiek > 18

context Osoba inv wiek_osoby: -- inwariant ma nazwę

self.wiek > 18

Ograniczenia początkowe dla atrybutów – wartości początkowe atrybutu.

Przykład:

context Czytelnik Instytucjonalny::rzetelny:Wylicz

init: if self.nazwa==‘XXX’ then # wysoka else #niska

Definicja ograniczeń dla operacji

context NazwaKlasy::NazwaOperacji(par1 : Typ1, ... ) : TypWyniku

pre [nazwa_warunku]: par1 > 0 ... -- warunki wstępne

post [nazwa_warunku]: result = par1 + …

-- result słowo zastrzeżone

-- do definiowania wyniku operacji

context Dziennik::srednia_osoby(o : Osoba):Real

post: result = 5

-- to tylko przykład

-- brak pre oznacza brak ograniczeń; pre : true

W warunku post mozliwe jest takze odwoływanie się do poprzednich (początkowych) wartości parametrów wywołania operacji poprzez uzycie operatora @pre.

Przykład:

ob.imie@pre oznacza wartość poprzednią (przed wykonaniem operacji) atrybutu imie obiektu ob.

Ograniczenia: Nawigowanie po modelu

Szczególnymi własnościami klas są związki (asocjacji, agregacji) z innymi klasami. Opisując ograniczenia powiązań klasy za pomocą OCL można się odwoływać do obiektów na drugim końcu powiązania poprzez nazwę roli.

Odwołanie do obiektu powiązanego przez nawigację za pomocą notacji kropkowej. Drugi koniec jest identyfikowany przez nazwę roli lub, gdy jej brak, przez nazwę klasy (pisaną małą literą).

context Rezerwacja

inv: czytelnik.nazwa < > ‘’

-- czytelnik musi mieć nazwę;

Ograniczenia: Nawigowanie po modelu - kolekcje

Jeśli występuje powiązanie obiektu z wieloma obiektami klasy, to odwołania dotyczą kolekcji obiektów.

Do własności kolekcji odwołuje się poprzez notację „->”,

np. jeżeli X jest kolekcją, to X->size() jest wywołaniem funkcji zwracającej rozmiar kolekcji.

Przykład:

context Czytelnik inv:

self.rezerwacja->size() < 3

-- czytelnik ma najwyżej 3 rezerwacje

Typy języka OCL (cd)

Predefiniowane typy kolekcyjne Collection(T) to

• zbiory – Set(T)

• ciągi – Sequence(T)

• wielozbiory – Bag(T)

Typy specjalne

• OclAny -- nadtyp wszystkich innych typów OCL, oclIsTypeOf(T: OclType):Boolean, oclIsKindOf(t: OclType): Boolean

• OclType, -- dowolny typ OCL,

Typy użytkownika modelowe:

Wszystkie klasy, interfejsy i inne typy utworzone przez użytkownika w modelu UML

Kolekcja

Definicje kolekcji – wyrażenia typu kolekcja

Set{1, 2, 4, 5}

-- elementy zbioru nie są uporządkowane

Sequence{1, 2, 3, 2, 3}

-- elementy ciągu są uporządkowane

Sequence{1.. 3, 2 .. 3}

-- elementy ciągu są uporządkowane

Bag{1, 2, 3, 2, 3}

-- elementy wielozbioru nie są uporządkowane

Elementami kolekcji mogą być również kolekcje.

W przypadku zbioru zbiorów następuje automatyczne spłaszczenie do jednego zbioru. Na przykład, podane zbiory są identyczne:

Set{Set{1,2},Set{3,4}} i Set{1..4}

Zgodność typów Typ t1 jest zgodny z typem t2 (jest podtypem typu t2), gdy w dowolnym miejscu, w którym oczekiwana jest instancja (wartość) typu t2, może ona zastąpiona przez instancję typu t1.

Każdy typ jest zgodny ze swoim nadtypem.

Relacja zgodności typów jest przechodnia.

Typ jest zgodny z Integer Real

Set(T) Collection(T)

Sequence(T) Collection(T)

Bag(T) Collection(T)

Collection(T1) Collection(T2), gdy T1 jest podtypem T2

Operacje kolekcji

Podstawowe operacje dla kolekcji

collection->isEmpty() : Boolean

– sprawdza czy kolekcja jest pusta,

collection->size() : Integer

– zwraca rozmiar kolekcji (ilość jej elementów),

collection->includes(object : OclAny) : Boolean

– sprawdza czy obiekt object jest w danej kolekcji

collection->sum() : T

– zwraca sumę wszystkich elementów kolekcji,

collection->exists(expr : OclExpression) : Boolean

collection->forAll (expr : OclExpression) : Boolean

operacje reprezentujące kwantyfikatory ogólne dla kolekcji – jeżeli dla każdego elementu kolekcji wyrażenie expr jest prawdziwe to operacja forAll zwraca True, jeżeli istnieje choć jeden element dla którego prawdziwe jest wyrażenie expr, to operacja exists zwraca True Operacja collect tworzy nową kolekcję na podstawie informacji z kolekcji pierwotnej, wstawiając do wynikowej kolekcji obliczone wyrażenia

collection->collect( expression )

collection->collect( v : Type | expression-with-v )

collection->collect( v : Type | expression-with-v )

Operacja select tworzy nową kolekcję będącą podkolekcją kolekcji, dla której wywołana została operacja.

collection->select( boolean-expression )

collection->select( v | boolean-expression-with-v )

collection->select( v : Type | boolean-expression-with-v)

Wynikiem tej operacji jest nowa kolekcja z tymi elementami z kolekcji źródłowej, dla których wyrażenie logiczne w operacji select było prawdziwe.

Przykład

Rezerwacja.pozycja->select(k: pozycja.Książka | k.autor = ”Pressman”)

Iteracja po elementach kolekcji

Operacja iterate – uniwersalna operacja dla kolekcji; za jej pomocą mozna zdefiniować inne operacje, np. collect, sum, average, itp. Ogólna postać operacji iterate:

collection->iterate( elem : Type; acc : Type = <expression> | expression-with-elem-and-acc )

• Operacja ta przebiega całą kolekcję z iteratorem elem.

• Acc jest akumulatorem, który może być na początku zainicjowany wartością początkową (expression).

• Dla każdej wartości iteratora, czyli dla wszystkich elementów kolekcji obliczane jest wyrażenie expression-with-elem-and-acc, a jego wynik jest podstawiany do akumulatora.

Przykład:

operacja sumowania wartości kolekcji (elementy typu Integer) zdefiniowana jako iteracja mogłaby wyglądać następująca:

collection->iterate(x : Integer; acc : Integer = 0; acc + x)

OCL - podsumowanie

Modele UML mogą być doprecyzowane przez formalnie wyrażone ograniczenia w OCL.

OCL jest językiem tekstowy, kontekstowym, silnie typizowanym. Istnieje wiele narzędzi, w tym generatory kodu (sprawdzające „w locie” ograniczenia) przeznaczone dla OCL.

Faza analizy:

Analiza Architektoniczna:

Cele:

- Definicja architektury kandydującej systemu w oparciu o doświadczenia w wytwarzaniu podobnych systemów

- Dostarczenie wejść dla procesów planowania

Kroki:

1. Definicja organizacji podsystemów (wysokiego poziomu) – zwykle wykorzystuje się model warstwowy

2. Wytworzenie modelu rozmieszczenia wysokiego poziomu (RUP)

3. Identyfikacja kluczowych abstrakcji

4. Identyfikacja mechanizmów analizy

Mechanizmy:

• Mechanizm analizy reprezentuje wzorzec, który stanowi rozwiązanie powszechnego problemu.

• Mechanizmy analizy są używane do reprezentacji umiejscowienia złożonej technologii w warstwach pośrednich (middleware) oraz oprogramowania systemowego.

• Zwykle są niezwiązane z dziedziną problemu. Przykładowe mechanizmy dotyczą trwałości danych, komunikacji pomiędzy procesami, obsługi błędów, powiadomień, zarządzania transakcjami, bezpieczeństwa itp.

Np. charakterystyk dotyczących opisu trwałości danych:

o Wielkość (Granularity) o Liczbę (Volume)

o Okres przechowywania (Duration)

o Mechanizm odtwarzania (Retrieval mechanism)

o Częstość modyfikacji (Update frequency)

o Pewność (Reliability)

ANALIZA przypadków uzycia

Cele:

- Identyfikacja klas analizy, które będą odpowiedzialne za realizację przypadku uzycia

- Odkrycie wymagań dodatkowych związanych z przypadkiem uzycia

Kroki:

1. Identyfikacja klas analizy

2. Opisanie interakcji obiektów analizy

3. Odkrywanie wymagań dodatkowych

ANALIZA klas

Cele:

- Identyfikacja zakresu odpowiedzialności klas analizy w oparciu o role, które pełnią one w przypadku użycia

- Identyfikacja atrybutów klas analizy

- Odkrycie wymagań dodatkowych związanych z klasą

Kroki:

1. Identyfikacja zakresów odpowiedzialności klas

2. Identyfikacja atrybutów

3. Identyfikacja asocjacji i agregacji

4. Identyfikacja generalizacji

5. Odkrywanie wymagań dodatkowych

PROJEKTOWANIE

PROJEKT - Projektowanie architektury

Celem projektowania architektury jest podanie modeli: projektowego i rozmieszczenia, oraz ich architektury.

Można to uzyskać dzięki identyfikacji:

Architektury fizycznej

Węzłów i ich sieciowej konfiguracji,

Architektury logicznej

Podsystemów i ich interfejsów,

Architektonicznie znaczących klas projektowych np. klas aktywnych,

Generycznego mechanizmu projektowego, który obsłuzy wspólne wymagania np. specjalne wymagania na trwałość, rozproszenie, wydajność i inne, określone w fazie analizy klas i przypadków użycia z modelu analizy(-> wymagania niefunkcjonalne!!)

Projekty architektury – projekt logiczny

Wykorzystuje się diagram rozmieszczenia. Przedstawia konfigurację węzłów (przetwarzających) oraz umieszczonych w nich komponentów; odzwierciedla statyczny aspekt perspektywy instalacyjnej

Elementy: węzły; komponenty; połączenia pomiędzy węzłami

PROJEKT - Projektowanie podsystemu

Celem projektowania podsystemu jest zapewnienie:

• tak dużej jak jest to możliwe niezależności podsystemu od innych podsystemów i/lub interfejsów,

• dostarczania przez podsystem poprawnego interfejsu własnego,

• zapewnienie wypełniania przez podsystem jego celów w tym sensie, ze oferuje on poprawną realizację operacji, tak jak jest ona zdefiniowana w interfejsie, który on dostarcza.

• dla kazdego interfejsu oferowanego przez podsystem muszą istnieć klasy projektowe lub inne podsystemy, które dostarczą ten interfejs,

• w celu wyjaśnienia jak wewnętrzny projekt realizuje dowolny swój interfejs lub przypadek użycia, należy podać kolaborację zawierającą elementy podsystemu;

PROJEKT - Projektowanie przypadku użycia

Celem projektowania PU jest:

• identyfikacja klas/podsystemów, które uczestniczą w PU

• rozdzielenie zachowania między klasy/podsystemy

• zdefiniowanie wymagań dotyczących operacji klas/podsystemów

• rozpoznanie wymagań implementacyjnych dla PU

Etapy:

- identyfikacja klas projektowych (z analizy uzupełnione o klasy dla wymagań niefunkcjonalnych);

- opis interakcji obiektów (diagram sekwencji poszerzony o nowe klasy; nazwa wiadomości staje się nazwą operacji);

- rozważenie ścieżek alternatywnych: timeouty, błędy we, błedy systemów spadkowych.

PROJEKT - Projektowanie klasy

Celem projektowania klasy jest określenie:

Operacji , atrybutów, relacji, metod, stanów i zależności od mechanizmów generycznych, a także interfejsów, które klasa realizuje. Dla klasy projektowej stosować śladowanie <<trace>> do klasy analizy.

Nalezy zidentyfikować:

- klasy ‘boundary’ - zalezą od zastosowanej technologii interfejsu (nowe stereotypy <<form>>, <<dialog>>, <<view>>)

- klasy ‘entity’ - dla modelu relacyjnego: model danych, projekt bazuy danych

- klasy sterujące - trudne, decyzje powinny uwzględniać rozproszenie aplikacji, wymagania wydajnościowe (enkapsulacja do klas interfejsu), obsługę transakcji.

PROJEKT - wzorce projektowe

Cel: tworzenie projektu wielokrotnego uzytku

Wzorzec projektowy - opisanie istoty rozwiązania problemu (spotykanego często w otoczeniu) w sposób, który umożliwia wielokrotne wykorzystywanie tego rozwiązania - niekoniecznie w ten sam sposób.

Na Wzorzec projektowy składają się cztery elementy:

• nazwa wzorca,

• problem,

• sposób rozwiązania,

• konsekwencje stosowania wzorca.

Wzorce projektowe dotyczą pewnego poziomu abstrakcji problemu tzn. nie są wzorcami budowy list, drzew itp.; nie są też wzorcami budowy całych aplikacji podsystemów(np. bankowego, sterowania procesem itp.)

Wzorce projektowe - definicje

Wzorzec projektowy identyfikuje i specyfikuje abstrakcję ‘wyższą’ niż klasa, instancja czy nawet komponent (Gamma, 1993)

Wzorce projektowe są opisem komunikujących się obiektów i klas dostosowanych do rozwiązania problemu projektowego w konkretnym kontekście (Gamma 1995)

Wzorce projektowe stanowią zbiór reguł określających jak osiągnąć konkretne cele w dziedzinie wytwarzania oprogramowania (Pree, 1994)

Wzorzec stanowi rozwiązanie powtarzających się problemów projektowych (Bushmann, 1996)

Wzorzec ~ przepis na upieczenie ciasta

Wzorce projektowe - klasyfikacja

• Kreujące – przejmują na siebie tworzenie nowych instancji obiektów, ukrywając rodzaj obiektów (singleton, proxy, fabryka abstrakcyjna)

• Strukturalne – wspomagają organizowanie obiektów w duże struktury, np. UI czy operacje na danych (fasada, adapter, most, dekorator, kompozycja)

• Behawioralne – wspomagają definiowanie komunikacji i przepływu zdarzeń pomiędzy obiektami (łańcuch odpowiedzialności, mediator, iterator)

Wzorce kreujące (Creational Patterns) – związane z tworzeniem nowych obiektów; ukrywają szczegóły dotyczące tworzenia obiektów; kod klienta ma pozostać niezmieniony w przypadku dodania nowego typu;

Przykłady: singleton, proxy, metoda fabrykująca (factory method), abstrakcyjna fabryka (abstract factory).

Wzorzec Singleton – wzorzec projektowy, który daje pewność że istnieje tylko jedna instancja danej klasy.

Wzorzec Proxy – umożliwia dostęp do obiektu klasy rzeczywistej, poprzez obiekt klasy pośredniczącej (obiekt proxy).

Wzorce strukturalne (Structural Patterns) – wzorce, które pomagają grupować obiekty w większe struktury; obiekty pozostają w pewnych połączeniach; wzorce te mają ukrywać sposób powiązania obiektów i uniezależniać klienta od tych zmian; przykłady: fasada, adapter, dekorator, most (bridge), kompozycja (composition)

Wzorzec Decorator – „opakowanie” zbioru klas posiadających wspólny interfejs.

Wzorce behawioralne (Behavioral Patterns) – wzorce, które są związane z projektowaniem obiektów, które mają wykonywać specyficzne akcje w programie; wzorce dotyczące sposobów komunikowania się obiektów; ich działanie jest oparte o dziedziczenie, dzięki któremu klasy zachowują się podobnie przykłady: obserwator, łańcuch odpowiedzialności (chain of responsibility), polecenie (command), interpreter, iterator, mediator, stan (state), strategia (strategy)

Wzorzec obserwator (observer) definiuje zależność pomiędzy obiektami w ten sposób, że gdy jeden z nich zmienia stan, reszta jest o tym powiada-miana i uaktualniana automatycznie

Wzorzec Łańcuch odpowiedzialności (Chain of Responsibility) umożliwia różnym obiektom, połączonym w listę, na podjęcie próby obsłużenia pewnego żądania, podczas gdy żaden z nich nic nie wie o możliwościach innych.

Wzorce projektowe - podsumowanie

• Wzorce projektowe ułatwiają proces modelowania aplikacji obiektowych

• Pozwalają na wykorzystanie gotowych przepisów na rozwiązanie trudnych problemów

• Kluczem do ich stosowania jest znajomość przynajmniej specyfiki problemów, z jakimi poszczególne wzorce sobie radzą

• Proces przechodzenia z modelu analizy do modelu projektowego powinien następować z uwzględnieniem użytecznych wzorców projektowych

Podstawy Inżynierii Oprogramowania

Asocjacja (n do m) jest odwzorowywana na tabelę

Asocjacja (1 do n) jest odwzorowywana:

• na tabelę lub

• jest reprezentowana przez klucz obcy w tabeli reprezentującej klasę z licznością n

Asocjacja (1 do 1) oraz (1 do n) może być odwzorowana na jedną klasę (jeżeli asocjacje nie tworzą cyklu) reprezentującą zarówno oba końce (klasy) asocjacji, jak i asocjację

Asocjacja n-arna jest odwzorowywana na tabelę

Asocjacja kwalifikowana jest odwzorowywana na tabelę z przynajmniej trzema atrybutami: 2 klucze główne dla każdego końca asocjacji oraz kwalifikator

Agregacja jest odwzorowywana tak, jak asocjacja

Zasady odwzorowania dla generalizacji prostej:

• każda klasa (nadklasa oraz podklasy) są odwzorowywane na tabele lub

• nie ma tabeli dla nadklasy; atrybuty nadklasy są replikowane w każdej tabeli podklasy lub

• nie ma tabeli dla podklasy; wszystkie atrybuty podklas są przeniesione do tabeli nadklasy

Zasady odwzorowania dla generalizacji wielokrotnej:

• dla klas rozłącznych - każda klasa (nadklasy oraz podklasy) są odwzorowywane na tabele lub

• dla klas nierozłącznych - każda klasa (nadklasy oraz podklasy) są odwzorowywane na tabele oraz generalizacja jest odwzorowywana na tabelę

Model projektowy obejmuje:

• architekturę logiczną tzn. podsystemy projektowe, podsystemy usługowe (service) wraz z ich interfejsami, zawartością oraz związkami zachodzącymi pomiędzy nimi; widok architektoniczny uwzględnia mechanizmy architektoniczne, w tym wzorce projektowe

• architekturę fizyczną opisującą węzły i ich sieciową konfigurację (wyrażoną modelem rozmieszczenia)

• realizację projektowych przypadków użycia, wykorzystującą klasy projektowe z uwzględnieniem klas aktywnych; realizacja obejmuje wątki alternatywne wynikające z ograniczonych zasobów oraz błędów interfejsu

Implementacja

Przyrost (ang. build) - wykonywalna wersja systemu lub jego części; efekt iteracji

PLAN INTEGRACJI Przyrostu opisuje sekwencję przyrostów kodu, które mają być zbudowane w kolejnych iteracjach

PLAN INTEGRACJI Przyrostu zawiera dla każdego przyrostu:

- funkcjonalność, która ma zostać zaimplementowana w przyroście (lista przypadków użycia lub ich części, lub/i scenariuszy; lista może dotyczyć wymagań dodatkowych)

- wskazanie części modeli implementacyjnych (podsystemów, artefaktów, komponentów) składających się na przyrost

STRATEGIA DEKOMPOZYCJI NA Przyrosty:

- kolejny przyrost powinien dodawać funkcjonalność w stosunku do poprzednich buildów

- nie należy wprowadzać zbyt wielu nowych elementów do przyrostu (trudności w integracji i testowaniu)

- początkowe przyrosty implementują niższe warstwy aplikacji, późniejsze - warstw bliższych warstwie aplikacji

Ogół właściwości produktu wiążących się z jego zdolnością do zaspokojenia potrzeb stwierdzonych i oczekiwanych

• jakość zewnętrzna (punkt widzenia klienta: własności dotyczące oprogramowania lub jego oferty),

• jakość wewnętrzna (punkt widzenia dostawcy oprogramowania: metody narzędzia, reguły, procedury, standardy, normy).

TESTOWANIE to wykonywanie programu w celu i z intencją znalezienia błędu (na podstawie błędnego wykonywania się programu - ang. fault)

WERYFIKACJA - wykazanie w warunkach „sztucznych” zgodności wytworzonego programu/systemu ze specyfikacją.

WALIDACJA (zatwierdzanie) - wykazanie w warunkach „naturalnych”(np. w środowisku klienta) zgodności wytworzonego programu/systemu ze specyfikacją.

CERTYFIKACJA - autorytatywne potwierdzenie zgodności wytworzonego programu/systemu ze specyfikacją, która jest znormalizowana (np. w postaci normy ISO, ANSI, IEC).

Błąd oprogramowania ( ang. fault) - nie są spełnione sensowne oczekiwania użytkownika/klienta; stan rzeczy odbiega od przyjętych założeń/zasad.

Awaria (ang. failure) – efekt ‘wykonania’ błędu

Przypadek testowy – para <dane wejściowe, oczekiwane wyniki> specyfikacja sposobu testowania systemu, łącznie z określeniem, co testować, pod jakim warunkiem można testować. Przypadek testowy musi weryfikować, co najmniej jeden scenariusz przypadku użycia.

Procedura testowa – kroki opisujące kolejność wykonywania przypadku testowego

Skrypt testowy – zautomatyzowana procedura testowa

Klasyfikacja błędów w systemach informatycznych:

- wg przyczyny: uszkodzenie sprzętu, błąd danych, nieadekwatność oprogramowania

- wg czasu trwania: trwały, chwilowy

- wg skutków dla użytkownika: krytyczny, niekrytyczny

- wg miejsca powstania : wewnętrzny, zewnętrzny

- wg kryterium: faza cyklu zycia oprogramowania:

• testowanie jednostki (procedury,modułu, programu)

• testowanie integracyjne

• testowanie systemowe

• testowanie akceptacyjne

- wg kryterium ‘wymagania niefunkcjonalne’:

• testowanie instalacyjne

• testowanie wydajnościowe

• testowanie niezawodności

- wg kryterium : technika testowania:

• testowanie statyczne (dotyczy artefaktów ‘niewykonywalnych’; inspekcja kodu/projektu)

• testowanie dynamiczne (wykonywanie programu dla danych testowych)

Testy integracyjne dotyczą łączenia modułow/podsystemów (powstawanie kolejnych „build”ów).

Testy systemowe - testowanie powstałej edycji („release”) oprogramowania; wykorzystuje się scenariusze z przypadków użycia (realizacja projektowa) - weryfikacja wymagań co do systemu.

Testy akceptacyjne dotyczą zainstalowanego produktu i są generowane na podstawie przypadków użycia. Poprawne wykonanie każdego z tych testów – rozumiane jako spełnienie warunku (-ów) post przypadku użycia – oznacza osiągnięcie celu tego przypadku i jest walidacją wymagania użytkownika.

Podstawy Inzynierii Oprogramowania

TESTOWANIE - zakres

Model Rodzaj testowania Technika testowania

Model specyfikacji Testowanie akceptacyjne, Testowanie funkcjonalne wymagań i systemowe, Pomiar osiągów

Model projektowy Testowanie integracyjne, Testowanie strukturalne, Testowanie funkcjonalne

Model implementacyjny Testowanie jednostkowe, Testowanie strukturalne, Testowanie funkcjonalne, weryfikacja

Testowanie jednostkowe

black-box

white-box

Testowanie integracyjne - zasady łączenia jednostek

przyrostowa

zstępująca - wymaga namiastek (stubs)

wstępująca - wymaga sterowników

skokowa

Testowanie systemowe - zalecane typy testów systemowych

Test Czynność Najczęściej stosuje się do systemów użyteczności sprawdzenie funkcji systemu systemy o rozbudowanej funkcjonaln. Wydajności pomiar parametrów, wyznaczenie systemy o narzuconych wymaganiach charakterystyk wydajnościowych obciążenia praca systemu w ekstremalnych systemy sieciowe, wielodostępne warunkach (dużo danych, wielu użytkowników) pamięci pomiary zapotrzebowania na pamięć konfiguracji próba pracy w różnych konfiguracjach instalacji testowanie procedur systemy o skomplikowanej instalacji instalacyjnych poufności próba włamania systemy z poufnymi danymi

Testowanie akceptacyjne

akceptacja fazowa - prototypy, kolejne wersje produktu

akceptacja ostateczna

Wymagania pojawiające się podczas implementacji testów jednostkowych:

• Niepowodzenie jednego testu nie powinno przerywać procesu testowania (assert() z języka C kończy program)

• Raporty z wykonania testów powinny być generowane automatycznie

• Asercje powinny dawać możliwość porównywania obiektów różnych typów

• Konieczna możliwość organizacji testów w zbiory

Ogólna zasada działania JUnit’a

• Dla klasy testowanej tworzymy „TestCase”

• Dodajemy metody testowe rozpoczynające się frazą „test”

• W miarę potrzeby nadpisujemy metody setUp() i tearDown()

• trudno jest stwierdzić, kiedy skończyć testowanie

• nie można testować własnego programu,

• testowanie powinno być powtarzalne,

• dane testowe obejmują zarówno dane poprawne jak i niepoprawne,

• należy badać dokładnie wyniki testowania,

• wzrost liczby wykrytych jest symptomem istnienia pozostałych,

• testowalność jest kluczowym założeniem projektu

Przegląd jest procesem lub spotkaniem, podczas którego produkt roboczy/artefakt (lub zbiór produktów roboczych) jest prezentowany personelowi projektu, kierownictwu, użytkownikom, klientom lub innych zainteresowanych stron celem uzyskania komentarzy, opinii i akceptacji.

Przeglądy mogą być formalne i nieformalne.

Przejście (walkthrough). Wczesna, nieformalna ocena dokumentów, modeli, projektów i kodu. Celem jest zidentyfikowanie defektów i rozważenie możliwych rozwiązań. Wtórnym celem jest szkolenie i rozwiązanie problemów stylistycznych (np. z formą kodu, dokumentacji, interfejsów użytkownika).

Formalne przeglądy mogą być inspekcją bądź audytem

Inspekcja - formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod są szczegółowo badane przez osobę lub grupę osób niebędących autorami, w celu identyfikacji błędów, naruszenia standardów i innych problemów

Korzyści z inspekcji:

1. Wzrost produktywności od 30% do 100%

2. Skrócenie czasu projektu od 10% do 30%

3. Skrócenie kosztu i czasu wykonywania testów od 5 do 10 razy (mniej błędów, mniej testów regresyjnych)

4. 10 razy mniejsze koszty pielęgnacji (naprawczej)

5. Poprawa procesu programowego

Wymaganie powinno :

- być jasno i jednoznacznie sformułowane

- być wyrazone w sposób mierzalny (wazne zwłaszcza dla wymagań niefunkcjonalnych)

- mieć nadany priorytet

- mieć oszacowany koszt realizacji

- być dostarczone do etapu projektu

- być rozpoznawalne w kodzie

- być weryfikowalne: stowarzyszone z testem,

- testowalne w izolacji oraz łącznie z innymi wymaganiami

- być walidowalne po zbudowaniu systemu

Audyt

niezależny przegląd i ocena jakości oprogramowania, która zapewnia, ze osiągnięto zgodność z wymaganiami na oprogramowanie, a także ze specyfikacją, generalnymi założeniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami.

Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie całego projektu lub produktu końcowego.

Przedmioty audytu:

stan projektu, proces wytwórczy lub jego dowolny podproces, system jakości, produkt końcowy

Ogół właściwości produktu wiążących się z jego zdolnością do zaspokojenia potrzeb stwierdzonych i oczekiwanych

Wyróżnia się:

• jakość zewnętrzną (punkt widzenia klienta: własności dotyczące oprogramowania lub jego oferty),

• jakość wewnętrzną (punkt widzenia dostawcy oprogramowania: metody narzędzia, reguły, procedury,

Pomiary w projekcie

Mierzonymi elementami przedsięwzięcia informatycznego mogą być:

proces - sekwencja aktywności wywołanych w celu wyprodukowania

produktu software’owego ( i innych artefaktów)

produkt - artefakty procesu włączając w to oprogramowanie, dokumenty i modele

przedsięwzięcie - całkowite zasoby, aktywności i artefakty

zasoby - ludzie, metody i narzędzia, czas, nakład, budżet dostępne dla projektu

Podstawowy zbiór miar (zalecany przez SEI) reprezentuje minimalny zbiór miar niezbędny z punktu widzenia zarządzania projektem:

- rozmiar

- koszt

- czas trwania

- defekty.

Pomiar artefaktu - Jednostki przydzielane atrybutom artefaktu podczas procesu pomiarowego są nazywane miarą danego atrybutu.

Miara – charakteryzuje w terminach numerycznych pewien prosty atrybut elementu (e.g. liczba linii kodu programu)

Miara: mierzalny atrybut bytu (encji) np. nakład czasowy projektu jest miarą jego rozmiaru; by to zmierzyć należy zsumować wszystkie sprawozdania czasowe projektu. Miara może być zbudowana w oparciu o jedną lub więcej innych miar -> powinno się definiować podstawowe miary i procedury ich zbierania.

Kategorie miar przedsięwzięcia

ze względu na różne aspekty przedsięwzięcia miary dotyczą:

• postępu (w terminach rozmiaru i złożoności),

• stabilności (w terminach szybkości zmian wymagań

lub implementacji, rozmiaru lub złożoności),

• modularności (w terminach zakresu zmian),

• jakości (w terminach liczby i typów błędów),

• dojrzałości (w terminach częstości błędów),

• zasobów (w terminach stosunku wydatków projektu do planowanych wydatków).

Ważne są trendy zmiany wartości miar, i ważne ich monitorowanie, a nie absolutna wartość miary w danym momencie

Miary złożoności projektu

Dla podejścia strukturalnego dwie miary:

moc modułu – miara złożoności wewnątrz modułowej: przypadkowa, klasyczna, logiczna, komunikacyjna, funkcjonalna, informacyjna,

więź modułu - miara złożoności komunikacji międzymodułowej: treściowa, sterowania, wspólna, zewnętrzna

Dla podejścia obiektowego miary

dla klasy – zestaw miar Chidamber/Kemerer (1994)

dla projektu - MOOD (Abreu,Goualo,Esteves 1995

(Chidamber/Kemerer 1994)

Złożoność klasy (WMC)- to, jeśli złożoność każdej metody klasy jest traktowana jako jeden, to WMC=n, gdzie n jest liczbą metod w klasie

Złożoność metody jest obliczana w postaci wariantu złożoności cyklomatycznej liczby McCabe’a; ponieważ ta miara jest addytywna, to można policzyć złożoność klasy.

Głębokość drzewa dziedziczenia (DIT) – zlicza poziomy, od ’korzenia’ drzewa

Liczba potomków (NOC) – zlicza klasy pochodne na sąsiednim poziomie

Więź międzyobiektowa (CBO) – zlicza komunikacje nie-dziedziczone

Żądanie wygenerowane przez klasę (RFC) – zlicza wszystkie metody stosowane przez klasę.

Brak spójności w metodach (LCOM) – identyfikuje metody, które stosują różne atrybuty.

Postępowanie służące zarządzaniu i kontroli rozwoju oraz ewolucji projektu

Dyscyplina określania elementów nieustannie rozwijającego się systemu programowego w celu kontrolowania zmian w tych elementach i pielęgnowania spójności oraz udogodnienia śledzenia zmian w ciągu całego cyklu zycia systemu

Zbiór czynności słuzących zarządzaniu zmianą poprzez:

• identyfikację artefaktów ulegających zmianie,

• ustalenie relacji między nimi,

• określenie mechanizmów zarządzania wersjami,

• kontrolę zmian,

• audyt,

• raportowanie.

Zarządzanie konfiguracją - podstawowe pojęcia

Konfiguracja – zmienny w czasie zestaw ustalonych artefaktów projektu i innych informacji, które są istotne do sprawnej jego realizacji.

Jej elementy to:

- Dokumentacja produktu programowego

- Dokumentacja projektowa

- Standardy, procedury, instrukcje

- Kod programu

Linia bazowa konfiguracji

Zestaw artefaktów, który został poddany przeglądowi i zatwierdzony. Jest podstawą do dalszego rozwoju. Może być zmieniony tylko poprzez formalne procedury.

Konfiguracja – podstawowe pojęcia

Jednostka (element) konfiguracji (ang. SCI)

- artefakt powstały w trakcie procesu wytwarzania oprogramowania

Identyfikowanie jednostki

• Nazwa

• Opis (typ SCI, identyf. projektu, wersja, informacja o zmianach)

• Zasoby wymagane przez SCI (np. zmienne globalne wymagane do kompilacji)

• Realizacja (np. odwołanie do pliku tekstowego z kodem)

Typy elementów konfiguracji:

• oprogramowanie (kod źródłowy lub binarny)

• dokumenty (w tym podręczniki)

• dane (np. przypadki testowe)

Zarządzanie konfiguracją – błędy

• nie ma pewności, która wersja elementu jest wersją bieżącą (strata czasu, dodatkowy nakład pracy)

• niezgodności między poszczególnymi elementami konfiguracji (np. specyfikacja programu, kod i specyfikacja testów są niezgodne)

• „wydawanie” produktów nie jest kontrolowane

• niekontrolowane zmiany w środowisku oprogramowania lub sprzętu –bez analizy ich skutków

• w przypadku „katastrofy” - nie do odtworzenia bieżący stan przedsięwzięcia

Zarządzanie zmianami (ZZ) obejmuje proces modyfikacji elementów linii bazowej w jednolity, spójny sposób. Żądanie zmian może dotyczyć różnorodnych elementów np. zmian wymagań, dokumentowania defektów, zmiany czasu przejścia między iteracjami. ZZ dotyczy struktury procesu

Zarządzanie wersjami

Dotyczy: elementu linii bazowej konfiguracji

Cele:

• Kontrolowanie zmian

• Zarządzanie bazą wersji

• Kontrolowanie i przechowywanie historii zmian

Wersja – instancja artefaktu, która różni się od innych instancji oferowanymi funkcjami

Wydanie – wersja dostarczona użytkownikowi

Zarządzanie wersjami - narzędzia

• Perforce

Repozytorium – Śledzenie działań programistów

• IBM Rational ClearCase

• CVS (Concurrent Versions System)

• SubVersion następca CVS; najbardziej popularny

• Dokumencik

Funkcje narzędzi wersjonowania

• Zarządzanie repozytorium komponentów

– Zarządzanie wersjami

• Historia

• Przechowywanie delt

• Zarządzanie wielodostępem

– Zarządzanie relacjami między obiektami

• Zawieranie

• Zależność

• Wsparcie inżynieryjne

- Kompilowanie i budowa projektu

- Wsparcie środowiska pracy

- Wsparcie pracy kooperacyjnej

• Wsparcie procesu projektowania

• Cofanie dowolnej liczby zmian

• Dokonywanie przeglądów – sprawdzanie kompletności i spójności komponentów

• Ustalenie odpowiedzialności pracowników – kto dopisał tę linię kodu, która powoduje błąd?

• Raportowanie:

– historii zmian

– różnic między wersjami

– aktywności pracowników

– statusu całego projektu i jego komponentów

• Oszczędność zasobów (czasu, pracy…), bezpieczeństwo

• Repository ( repozytorium) - miejsce, gdzie przechowywane są pliki

• Check-Out - pobranie pliku z repozytorium

• Update ( aktualizacja) - kopiuje zmiany dokonane w repozytorium do katalogu, w którym pracujemy

• Change ( zmiana) – reprezentuje modyfikację do dokumentu znajdującego się pod kontrolą wersji.

• Commit (również: install, submit, check-in) - wgranie zmian do repozytorium

• Change List (lista zmian) – zespół zmian dokonanych podczas jednej operacji commit

• Merge ( łączenie) – łączy konkurencyjne zmiany do jednej zunifikowanej wersji

• Conflict ( konflikt) – pojawia się, kiedy algorytm łączenia nie jest w stanie wygenerować poprawnej wersji zawierającej zmiany wprowadzone do łączonych plików

• Resolve ( rozwiązanie konfliktu) – akt interwencji użytkownika w celu wsparcia algorytmu do nanoszenia różnych zmian tego samego do kumentu

• Blokada

• Łączenie plików (merging)

• Porównaj linię po linii dokument początkowy z wersjami zmienionymi

• Jeśli linia wystąpiła tylko w nowej wersji musi być dodana

• Jeśli linia wystąpiła tylko w pierwotnej wersji musi być usunięta

Pielęgnacja oprogramowania

Typy konserwacji/pielęgnacji:

- korekcyjna usuwanie błędów niewykrytych podczas testowania

- adaptacyjna modyfikacja systemu dopasowująca go do zmian w środowisku

- perfekcyjna rozszerzenie systemu do rozwiązywania nowych problemów lub uzyskania korzyści z nowych okoliczności

- prewencyjna zabezpieczenie systemu przed przyszłymi problemami

Konserwacja oprogramowania obejmuje 4 aktywności:

• otrzymanie wymagań konserwacyjnych

• transformacje wymagań w zmiany

• zaprojektowanie zmian

• zaimplementowanie zmian

Pielęgnacja oprogramowania

Powód prowadzenia modyfikacji (przykłady)

1. adaptacyjnej (dostosowującej):

- zmiany wymagań użytkowników

- zmiany przepisów prawnych,

- zmiany organizacyjne w firmie klienta

- zmiany sprzętu/oprogramowania systemowego

2. perfekcyjnej (ulepszającej):

- poprawa wydajności pewnych funkcji

- poprawa ergonomii interfejsu

- poprawa przejrzystości raportów

Przyczynami prowadzenia modyfikacji są na ogół żądania użytkowników

Pielęgnacja oprogramowania

Obiektywne czynniki kosztów konserwacji/pielęgnacji:

• stabilność środowiska pracy systemu

• stabilność platformy sprzętowej i oprogramowania systemowego

• czas użytkowania systemu

Redukcja kosztów dzięki:

• znajomości dziedziny problemu

• wysokiej jakości modelu i projektu

• wysokiej jakości dokumentacji technicznej (możliwość stosowania inżynierii odwrotnej)

• stabilność personelu

• środowisko implementacji

• niezawodność oprogramowania

• zarządzanie wersjami

Zarzadzanie przedsięwzięciem:

Zarządzanie przedsięwzięciem (syn. projekt)

- planowanie

- szacowanie kosztów

- komunikacja i nadzorowanie

- zespół wytwórczy

Przedsięwzięcie (projekt): każda działalność podjęta w celu osiągnięcia wyspecyfikowanych zamierzeń

Własności projektu:

• złożony i nierutynowy zestaw działań,

• wymaga powierzenia ludzi, zasobów, kapitału i czasu,

• obejmuje różnych ludzi, funkcje i organizacje,

• wymaga ścisłej koordynacji i nadzorowania prowadzonych działań.

ZARZĄDZANIE obejmuje działania:

• planowanie (decydowanie, co będzie wykonywane)

• organizację (aranżowanie prac)

• kierowanie (dawanie instrukcji)

• monitorowanie (kontrola postępu)

• nadzorowanie/sterowanie (podejmowanie akcji naprawczych)

• dobór personelu (wybór odpowiednich ludzi)

• innowacje (proponowanie nowych rozwiązań)

• prezentowanie (sesje z użytkownikami..)

• ..... I WSZYSTKO INNE

Przedsięwzięcie kończy się sukcesem, gdy jest wykonane w terminie zgodnie ze specyfikacją, mieści się w przyznanym budżecie, a efekt jego zamierzeń posiada wymaganą jakość.

Aktywności podczas inicjowania projektu

1. Aktywności i działania podejmowane w fazie inicjowania/opracowywania projektu

2. Ustalenie daty początku / końca projektu (sterowany czasem czy nakładem).

3. Wybór metodyki projektowej i/lub cyklu życia oprogramowania.

4. Ustalenie zakresu projektu ze względu na fazy wybranej metodyki; wybór struktury organizacyjnej.

5. Identyfikacja lub wybór metod oceny projektu.

6. Identyfikacja terminów krytycznych dla projektu (tymczasowe kamienie milowe).

7. Identyfikacja i podanie listy zadań w poszczególnych fazach w kolejności terminów ich zakończenia

8. Oszacowanie personelu potrzebnego do realizacji każdego z zadań.

9. Prezentacja personelu potrzebnego do realizacji każdego zadania. i określenie wymaganych umiejętności do realizacji podanych zadań.

10. Określenie zależności między zadaniami (zadania równoległe, warunki rozpoczęcia poszczególnych zadań itp.).

11. Wskazanie punktów kontrolnych projektu.

12. Dokonanie oszacowania kosztów projektu oraz analiza zysku.

Plan Wytwarzania Oprogramowania (PWO) obejmuje:

• wykaz produktów,

• wybór środowiska wytwarzania

• szacunek rozmiaru i nakładu wymaganego do uzyskania produktów

• wybór modelu cyklu życia oprogramowania

• diagram WBS

• harmonogram

• specyfikację wymaganego personelu i jego organizację

• budżet czasowy

• zbierane miary projektu oraz opis strategii zbierania informacji

Szacowanie kosztów - służy ilościowej ocenie przybliżonych kosztów zasobów wymaganych do zakończenia zaplanowanych aktywności projektu.

ZASÓB – każdy element lub człowiek potrzebny do zrealizowania projektu

Kategorie zasobów:

• praca

• wyposażenie

• materiały

• środowisko pracy

• usługi

• czas

• pieniądze

Szacunek kosztu jest prowadzony podczas:

- studium wykonalności (-> wykonalność ekonomiczna : analiza koszt-korzyści)

Cel: podjęcie decyzji o kontynuowaniu (lub nie) projektu

- na poziomie planowania zadań (->harmonogram kosztów)

Cel: ocena finansowej realizowalności projektu

Szacunek kosztów zleceniobiorcy może być oparty o następujące rodzaje metod:

• osąd eksperta

• analogia

• z dołu do góry

• z góry do dołu

• „cena do wygrania”

• algorytmiczne wykorzystujace modele parametryczne

W celu oszacowania kosztów szacuje się:

1. rozmiar oprogramowania (linie kodu, punkty funkcyjne, liczbe modułów, liczba klas)

2. nakład (pracochłonność) ( liczba osób/czas w miesiącach - MM)

3. czas trwania: liczba miesięcy wymagana do dostarczenia produktu

4. produktywność: rozmiar/nakład

5. koszt wytworzenia: koszt pracy zawarty w nakładzie

METODY SZACOWANIA NA ETAPIE ANALIZY:

• analogia ( na poziomie systemu)

• analogia ( na poziomie pakietów) --> szacowanie metodą PERT

• modele parametryczne

Model COCOMO (Constructive Cost Model – B.Boehm 1981)

Formuła szacowania nakładu pracy niezbędnej do wytworzenia produktu:

Nakład = A (rozmiar) ^p

rozmiar - rozmiar projektu w KLOC,

A - określa wpływ parametrów systemu na wkład pracy,

p - współczynnik dobierany w zależności od skali projektu.

Metoda punktów funkcyjnych (Albrecht 1987)

Analiza punktów funkcyjnych rozpatruje możliwości systemu z punktu widzenia użytkownika.

Złożoność funkcjonalna F (niska, średnia , duża) podawana w postaci punktów funkcyjnych FP; złożoność jest określana w oparciu o kombinację grupowania danych i elementów danych konkretnych typów.

FPznor= UFP*(0.65+0.01*suma(TCFi))

UFP – nieskorygowana liczba punktów funkcyjnych

TCF – współczynnik złożoności technicznej

Monitorowanie (długookresowa obserwacja zjawisk lub przedmiotów w celu poznania ich reakcji na działanie określonych czynników) ‘zachowania się’ projektu:

obserwacja rzeczywistych terminów rozpoczęcia i zakończenia zadań oraz porównywanie ich z zaplanowanymi (baseline),

obserwacja zużycia zasobów

Monitorowanie zabiera czas i zużywa zasoby;

W zależności od ryzyka projektu (i zadań) można ograniczać monitorowanie do:

- Zadań ścieżki krytycznej jakiekolwiek opóźnienie w tych zadaniach oznacza opóźnienie całego projektu;

- Zadań bez możliwości manewru czasowego opóźnienie w nich spowoduje jednocześnie opóźnienie w części innych zadań, co z kolei może spowodować problemy w harmonogramie zasobów;

- Zadań z niewielkim manewrem czasowym problemy jak poprzednio;

- Zadań o wysokim ryzyku duże prawdopodobieństwo, że przekroczą one wyznaczony termin lub budżet;

- Zadań wykorzystujące krytyczne zasoby ważne ze względu na dostępność ich w określonym czasie lub ilości.

RAPORTOWANIE STANU PROJEKTU

Cel: dostarczenie inwestorom informacji, jak są wykorzystane zasoby projektu w celu osiągnięcia zamierzeń projektowych; Informacje zawarte w raporcie dotyczą: zakresu, harmonogramu, kosztów, jakości, ryzyka (opcja) zakupów (opcja). Raportowanie obejmuje:

Raportowanie statusu projektu

Raportowanie postępu projektu

Przewidywanego przebiegu projektu.

Kategorie raportów:

- Werbalny formalny regularny np. cotygodniowe spotkania

- Werbalny formalny ad-hoc np. podsumowanie jakiegoś okresu

- Pisemny formalny regularny np. raporty postępu

- Pisemny formalny ad-hoc np. raporty ‘na żądanie, informowanie o zmianach

- Werbalny informacyjny ad-hoc okazyjne dyskusje,

Zespół - grupa ludzi wspólnie pracujących w pewnej dziedzinie w celu osiągnięcia ustalonego celu.

Optymalna liczność zespołu to 7 – 11 osób

• Powyżej 17-20 osób komunikacja staje się niemożliwa

• Zalecenie, by zespół programistyczny był nie większy niż 8 osób

ALE

• Profesjonalne oprogramowanie tworzone przez grupy 200 do kilkuset osób, więc konieczny

• Podział wielkiego zespołu na podzespoły (analogicznie do systemu na podsystemy)

• Sieciowa członkowie zespołu komunikują się i wspłpracują każdy z każdym

• Gwieździsta jedyną osobą wspłpracująca i komunikująca się z grupą jest szef zespołu

Osobowości w zespole:Cechy

- Urojony przywódca Wydaje mu się, że dziś kieruje projektem, a jutro zacznie rządzić całą firmą.

- Mysz Boi się jakichkolwiek samodzielnych działań, nic nie zrobi bez bezpośredniego polecenia. Ze strachu przed katastrofalną pomyłką wymaga od ciągłego nadzoru.

- Ulubiony wujek (ciocia). Biurowy dowcipniś. Wygłupia się, opowiada kawały i zabawne historyjki, robi innym psikusy. Jest zabawny, ale marnuje strasznie dużo czasu.

- Eksperymentator Uwielbia emocje. Jest szczęśliwy mogąc sprawdzić co się stanie, jeśli zrobi coś nietypowego. Może mieć duże doświadczenie, ale jest zbyt pewny siebie, a jego wyczyny nie zawsze są przemyślane.

- Maruda Ponurak. Nie obchodzi go projekt, uważa, że technologia jest do niczego. Robi sobie 20 min. przerwy na kawę.