cz 1a modelowanie i analiza systemow informatycznych

Modelowanie i
analiza systemów
informatycznych

INFORMATYKA – S2

Rok akad. 2011/2012 – semestr letni

Prowadzący: Dr hab. n.t. Bożena Śmiałkowska

ZAGADNIENIA

ORGANIZACYJNE

TREŚCI I EFEKTY

KSZTAŁCENIA

Zasady zaliczenia przedmiotu

Przedmiot za 5 punktów ECTS - egzamin

Formy zajęć: wykład + ćw. + lab.

Wagi obliczeniowe stosowane przy ocenie :

0,5 w+0.35 lab + 0,15 ćw

Egzamin pisemny: 5 pytań

Propozycja terminów egzaminu:

Rodzaj studiów

Termin

Kierunek Informatyka

Studia stacjonarne II stopnia

I termin podstawowy

22.06.2012 (piątek) godz. 10-12 sala 227 WI2

II termin podstawowy

25.06.2012 (poniedziałek) godz. 10-12 sala 126 WI2

I termin poprawkowy

29.06.2012 (piątek) godz. 10-12 sala 227 WI2

II termin poprawkowy

10.09.2012 (poniedziałek) godz. 10-12 sala 215

Konsultacje



konsultacje: środy godz. 12:15-13:45
pokój 123



e-mail:bsmialkowska@wi.zut.edu.pl

Treści kształcenia



Podstawowe definicje i rodzaje systemów

informatycznych



Ogólne zagadnienia związane z modelowaniem i

analizą systemów informatycznych



Przegląd modeli cykli życia systemu

informatycznego



Przegląd metod modelowania systemów

informatycznych (strukturalne, obiektowe,

swobodne, techno-centryczne, antypo-centryczne,

modelowanie komponentowe, dedykowane dla

grupy systemów)



Jakość, ryzyko, czas, koszt, wydajność i inne

artefakty związane z procesem analizy i

modelowania systemów informatycznych

Efekty kształcenia

Znajomość metod:



analizy

systemów informatycznych i

związanych z nimi artefaktów



modelowania

systemów

informatycznych

Umiejętność:



analizy cech

systemów informatycznych



konstruowania modeli

systemów

informatycznych



posługiwania się modelami

systemów

informatycznych i

metodami

ich

tworzenia

PODSTAWOWE

DEFINICJE

RODZAJE SYSTEMÓW

INFORMATYCZNYCH

System

informacyjny

Jest to celowe zestawienie ludzi, danych,

procesów, sposobów komunikacji, infrastruktury
sieciowej i urządzeń komputerowych, które to
elementy współdziałają

w celu zapewnienia

codziennego

funkcjonowania

organizacji

(transakcyjne

przetwarzanie

danych)

jak

również wspierający rozwiązywanie problemów i
podejmowanie decyzji przez kadrę kierowniczą
(systemy raportowania i wspomagania decyzji)

System informacyjny niekoniecznie musi

zawierać elementy infrastruktury IT

Składowe systemu informacyjnego

SIO – system informacyjny danej organizacji
P – zbiór podmiotów, które są użytkownikami systemu.
I – zbiór informacji o sferze realnej, czyli o jej stanie i

zachodzących a niej zmianach (tzw. zasoby
informacyjne).

T – zbiór narzędzi technicznych stosownych w procesie

pobierania, przesyłania, przetwarzania,
przechowywania i wydawania informacji.

O – zbiór rozwiązań rynkowych stosownych w danej

organizacji (stosowane formuła zarządzania).

M – zbiór meta-informacji, czyli opis systemu

informacyjnego i jego zasobów informacyjnych.

R – relację pomiędzy poszczególnymi zbiorami.

}

{

SIO 

Klasyfikacja systemów informacyjnych



Otwarte – zamknięte
Według uzależnienia od otoczenia.



Proste – złożone
według celu i struktury, znaczna ilość
relacji pomiędzy składowymi.



Deterministyczne – probabilistyczne
zależność zachowania systemu zależy od
dużej liczny przypadkowych czynników.

Klasyfikacja systemów informacyjnych



Statyczne – dynamiczne
zależy do szybkości zmiany stanów
systemu.



Naturalne – projektowane



Projektowane:



Projektowane systemy fizyczne (np.
elektrownie)



Projektowane systemy konceptualne.



Projektowane systemy działania ludzi.

System informatyczny (SI)



SI może być jedną z części składowych systemu
informacyjnego



Oba terminy System informacyjny oraz
informatyczny - używane są jako synonimy -

niesłusznie



System informatyczny to oparte na technologii
komputerowej rozwiązanie pojedynczego
problemu biznesowego. Może być to aplikacja,
rozwiązanie sprzętowe lub (najczęściej)
połączenie obu tych składników



System informacyjny może się składać z więcej
niż jednego systemu informatycznego

Złożoność, informacja, wiedza



Dane: surowe fakty o organizacji i jej
działaniach (np. transakcjach)



Informacje: celowo zorganizowane dane
posiadające określone znaczenie



Wiedza: informacje nadająca się do
wykorzystania

System informacyjny - przetwarza dane w

użyteczne informacje

System inteligentny - potrafi generować wiedzę

Piramida informacyjna

Sygnały

Dane

Informacje

Wiedza

Mądrość

Zajęte zasoby

Złożoność
semantyczna

Rodzaje systemów
informacyjnych



Transakcyjne on-line



Transakcyjne off-line



Proste systemy raportujące



Systemy informowania
kierownictwa



Systemy „inteligentne”

ło

Duża

Mała

Krótki

Długi

Istnieją oczywiście wyjątki – np. bankowe systemy kredytowe

1960

1970

1980

1990

2000

MRP

MRP II

ERP

DEM

(

Inventory Control

) - zarządzanie gospodarką magazynową

MRP

(

Material Requirments Planing

) - planowanie

potrzeb materiałowych

poprzez

wydawanie zleceń zakupu i produkcji dokładnie w takim momencie, aby żądany produkt

pojawił się w potrzebnej chwili i wymaganej ilości

MRP II

(

Manufacturing Resource Planing

) - planowanie

zasobów produkcyjnych

poszerzone o bilansowanie zasobów produkcyjnych i dystrybucję (główny składnik BIS)

ERP

(

Enterprice Resource Planing

) - (określana jako MRP III -

Money Resource

Planing

lub MRP II Plus) planowanie zasobów przedsiębiorstwa wraz z procedurami

finansowymi, w tym księgowość zarządcza, cash flow i rachunek kosztów działania

DEM

(

Dynamic Enterprice Modeler

) -

dynamiczne modelowanie przedsiębiorstwa

umożliwiające bezpośrednie przejście od modelu firmy do gotowej konfiguracji aplikacji

dla poszczególnych użytkowników

CRM

(

Customer Relationship Management

) -

zarządzanie kontaktami z klientem

Ewolucja systemów informatycznych
np..do zarządzania firmą

Standard MRP II Plus

to rozwinięcie koncepcji wariantu

rozwiniętego standardu MRP II. W związku z tym realizuje on

dodatkowo następujące funkcje:

• zarządzanie zmianami konstrukcyjnymi i technologicznymi,
• zarządzanie dokumentacją techniczną,
• integracja z systemami CAD/CAM/CAP,
• zarządzanie remontami i serwisem (zlecenia i umowy),
• zarządzanie jakością,
• dystrybucją (planowanie potrzeb, transportu i obsługa zleceń) i

rozwinięta obsługa sprzedaży,

• zarządzanie środkami trwałymi i wyposażeniem,
• zarządzanie kadrami i płacami i strumieniami środków

płatniczych,

• rachunkowość zarządcza,
• kontroling,
• generowanie raportów,
• integracja multimediów,
• przeglądarki baz danych, itp.

MRP II Plus (ERP)

Standard DEM to zintegrowane narzędzie umożliwiające zarówno

opracowanie nowych jak i udoskonalanie istniejących procesów
gospodarczych (

reinżynieria

Umożliwia on dynamiczne stworzenie modelu lokalnego (np. jeden

dział firmy) jak i obejmujący wszystkie działy korporacji w oparciu

o odpowiednie modele odniesienia.

GŁÓWNA BIBLIOTEKA WZORCÓW

(REPOZYTORIUM)

MODEL

ODNIESIENIA

BIBLIOTEKA

KOMPONENTÓW

FAZY

ZAKRES

PROJEKT MODELU

LOKALNEGO

Model ogólny

Model branżowy

Model

przedsiębiorstwa

DEM

Wprowadza się tu

optymalizację

, która pozwala na bieżąco

wprowadzać

zmiany w funkcjonowaniu firmy. Dzięki temu

przedsiębiorstwo wraz z systemem żyje i ewoluuje.

krytyczne

wskaźniki

sukcesu

wizja

Implementacja

(faza podstawowa)

optymalizacja... . . . . . . . . . . . . . . .

optymalizacja

dyskusje

symulacje

model

funkcjonalny

model

procesowy

dyskusje z

Zarządem

przegląd z

użytkownikami

kluczowymi

DEM

Strategia rozwoju firmy i informatyzacji

MISJA PRZEDSI

BIORSTWA

BADANIE OTOCZENIA

(szanse i zagrożenia)

BADANIE FIRMY

(mocne i słabe strony)

WIEDZA O RYNKU

TRENDY

TECHNOLOGICZNE

STRATEGIA ROZWOJU FIRMY

STRATEGIA INFORMATYZACJI

FIRMY

stacje robocze systemu

serwer

przedsiębiorstwa

serwer kontrahenta

serwer klienta

serwer dostawcy

sieć rozległa

sieć lokalna

ZSI a otoczenie przedsiębiorstwa –

możliwości systemów rozproszonych

ZSI

Systemy klasy MRP, ERP stanowi

rozwi

zania dedykowane wewn

trznemu

zarz

dzaniu przedsi

biorstwem.

Systemy CRM (

Customer Relationship Management

) pozwalaj

wnie

zarz

dza

kontaktami z klientem.

back office

(

)

(

)

CRM

MRP (ERP)

PRZEDSIĘBIORSTWO

front office

Systemy CRM

CRM

(Customer Relationship Management)

(Contact Management)

• proste

jednostanowiskowe

aplikacje,

• funkcje kalendarza i baza

danych pozwalają na analizę

danych dotyczących klienta i

historii kontaktów

SFA

(Sales Force Automation)

• udostępnianie klientowi

informacji

on-line,

• zarządzanie sprzedażą,

• obsługa klienta w ramach

jednego systemu

oraz:

CRS - Call Reporting Systems

TMS - Territory Management Systems

SMS - Sales Management Systems

STA - Sales Team Automation

Systemy CRM

WWW

E-mail

fax

...

telefon

Systemy wymiany informacji

OBSŁUGA KLIENTÓW

SERWIS

MARKETING

SPZREDAŻ

• zarządzania firmą
• zarządzania zasobami

ludzkimi

• zarządzania finansami

SYSTEMY INFORMATYCZNE

• HURTOWNIE DANYCH

• ZARZĄDZANIE WIEDZĄ

• ANALITYKA

KLIENCI

...



systemy obsługujące kanały komunikacji z klientem,



systemy front-office obejmujące m.in. marketing, sprzedaż,
wsparcie klienta,



systemy analityczne.

CRM:



sprzedaż:

• zarządzanie

kontaktami

(profile,

struktura,

historia

kontaktów sprzedaży),

• zarządzanie kontem (generowanie ofert, zamówienia,

transakcje),

• analizy w ramach cyklu sprzedaży,
• monitorowanie statusu klienta i potencjalnych kontaktów

handlowych;



zarządzanie terminarzem i korespondencją:

• kalendarz i baza danych użytkowników (grup),
• obsługa poczty tradycyjnej i elektronicznej (fax, e-mail);



marketing:

• zarządzanie kampanią,
• katalog produktów,
• konfigurator produktów,
• cenniki i oferty,
• analizy efektywności kampanii,
• dystrybucja informacji o kilentach zainteresowanych ofertą;

Funkcje (moduły) CRM:



telemarketing:

• układanie list telefonicznych wg definicji grup docelowych,
• automatyczne wybieranie numeru,
• generowanie list potencjalnych klientów,
• zbieranie zamówień;



serwis i wsparcie klienta po sprzedaży:

• przydzielenie, śledzenie i raportowanie zadań,
• zarządzanie problemem serwisowym,
• kontrola zamówień,
• obsługa gwarancyjna i pogwarancyjna;



integracja z systemami ERP:

• zarządzanie finansami, księgowość, produkcja, dystrybucja,
• zarządzanie zasobami ludzkimi;



synchronizacja danych

dotyczy

współdziałania

pomiędzy urządzeniami (np. laptopy) a centralną bazą danych

lub innymi bazami i serwerami aplikacji;



e-commers

- realizowanie handlu elektronicznego;



call center

- usługowe wsparcie klienta.

Funkcje (moduły) CRM:

systemy ewidencyjno-transakcyjne

STOPIEŃ

INTEGRACJI

CZAS

1960

1970

1980

1990

2000

systemy informacyjno-decyzyjne

systemy wspomagania decyzji

systemy eksperckie

systemy informowania kierownictwa

systemy sztucznej inteligencji

zintegrowane systemy

informatyczne

Ewolucja SIZ

systemy czasu rzeczywistego



system zarządzania zorganizowany (SIZ) modułowo



obsługujący

wszystkie

sfery

działalności

przedsiębiorstwa



wszystkie zasoby danych, procedury zarządzania,

sterowanie i regulacja procesów wytwórczych są

przetwarzane

przy

wsparciu

technologii

informatycznej

Mówiąc o ZSI należy mieć na uwadze:

Umożliwia etapowe wdrażanie tych składowych,

które są niezbędne z uwagi na specyfikę firmy.

Począwszy od marketingu i planowania oraz

zaopatrzenia, poprzez techniczne przygotowanie

produkcji i jej sterowanie, dystrybucję, sprzedaż,

gospodarkę remontową, aż do prac finansowo-

księgowych i kadrowych.

Ewolucja ZSI

Cechy ZSI

Zintegrowane systemy informatyczne stanowią

urzeczywistnienie idei

integracji kompleksowych systemów informatycznego wspomagania procesów
zarządzania w przedsiębiorstwie z kompleksowymi systemami komputerowego
wytwarzania.

Główne cechy ZSI:

• kompleksowość funkcjonalna - obejmuje wszystkie sfery firmy,

• integracja danych i procesów - dotyczy wymiany informacji wewnątrz

firmy jak i z jej otoczeniem,

• elastyczność strukturalna (skalowalność) i funkcjonalna - dynamiczne

dopasowanie przy zmiennych wymaganiach i potrzebach otoczenia,

• otwartość - możliwość rozbudowy systemu i tworzenie nowych połączeń

zewnętrznych,

• zaawansowanie merytoryczne

możliwość

pełnego informatycznego

wsparcia procesów informacyjno-decyzyjnych

• zaawansowanie technologiczne - zgodność ze standardami sprzętowo-

programowymi oraz możliwość przenoszenia na inne platformy

• zgodność z przepisami (np. ustawą o rachunkowości)

Ewolucja integracji w

przedsiębiorstwie

Integrowanie

polega na łączeniu w całość, zatem istotą

integracji jest utworzenie nowej jakościowo całości, której elementy są
połączone odpowiednimi relacjami i powiązane odpowiednim stopniem
zależności od całości.

Celem

jest

skoordynowanie

elementów

systemów

dla

zracjonalizowania jego funkcjonowania.

Przedmiotem integracji są funkcje użytkowe systemu, dane i

środki techniczne.

Typy integracji

•

projektowa (metodologiczna),

•

organizacyjna,

•

techniczna,

•

konstrukcyjno-technologiczna

Ewolucja integracji w firmie w

dziedzinie SI

Integracja procedur,

programów, przetwarzania

danych i interfejsu

Integracja transakcji, danych

wejściowych, wyjściowych i zbiorów

w bazie danych

Integracja modułów i jednostek

funkcjonalnych przetwarzania danych

Integracja techniczna środków informatyki i

łączności (spójność techniczna)

Integracja funkcji i celów poszczególnych warstw i

modułów systemu (spójność funkcjonalna)

Ujednolicenie pojęć, haseł, definicji, klasyfikacji, struktur pól,

dokumentów, określenie zasad interpretacji danych (spójność

syntaktyczna i semantyczna)

jno

ść

int

cyjnyc

Integracja

projektowa

(metodologiczna)

Integracja

organizacyjna

Integracja

techniczna

Integracja

konstrukcyjno-

technologiczna

Integracja może przebiegać w dwóch płaszczyznach:

• funkcjonalnej

- funkcje realizowane są w taki sposób , jak

gdyby wykonywane były w jednym systemie; oznacza to

możliwość korzystania przez użytkownika z dostępu do

wszystkich funkcji realizowanych w systemie poprzez jeden

spójny interfejs wraz z przełączaniem się pomiędzy

różnymi zadaniami,

• fizycznej

- kompleksowe połączenie elementów systemu na

płaszczyźnie

sprzętowo-programowej.

Podsystemy

dziedzinowe

(moduły)

Systemy

autonomiczne

Postępująca

integracja

Pełna integracja

Finansowo-księgowy
Majątek trwały
Kadry
Zaopatrzenie
Marketing
Zbyt
Sterowanie produkcji

.........

a b c ... n
a b c ... n
a b c ... n
a b c ... n
a b c ... n
a b c ... n
a b c ... n

a b c ... n

jednostki

organizacyjne

jednostki

organizacyjne

jednostki

organizacyjne

Ewolucja integracji w firmie

Faza II -

Opracowanie koncepcji informatyzacji przedsiębiorstwa

obejmuje:



selekcja i wybór gotowego ZSI



zestawienie oprogramowania aplikacyjnego według modelu prototypowania



modelowanie konfiguracji oprogramowania narzędziowego, systemowego,

sieciowego oraz opracowanie projektu infrastruktury technicznej

Faza III - Realizacja systemu obejmuje:



przeprowadzenie koniecznej restrukturyzacji przedsiębiorstwa



kompletacja i organizacja dostaw sprzętu i oprogramowania



instalowanie i uruchomienie systemu



działalność szkoleniowo-edukacyjna zorientowana na kadrę kierowniczą

przedsiębiorstwa



szkolenie użytkowników (podstawowe, systemowe, aplikacyjne)



wdrożenie i testowanie oprogramowania aplikacyjnego

Faza IV - Konserwacja i bieżący rozwój systemu obejmuje:



umowy na długoterminową współpracę w ramach nadzoru autorskiego

(wykonawczego)



konieczne modyfikacje ZSI, wynikające ze zmian obowiązujących przepisów



rozbudowa oprogramowania i sprzętu, wynikająca z rosnących wymagań

użytkowników



stały rozwój dostarczonych rozwiązań w miarę pojawienia się nowych

technologii

FAZA I: Analiza przedsiębiorstwa

FAZA II: Opracowanie koncepcji

informatyzacji przedsiębiorstwa

FAZA III: Realizacja systemu

FAZA IV: Konserwacja i bieżący rozwój

systemu

Faza I - Analiza przedsiębiorstwa obejmuje:



określenie celów strategicznych przedsiębiorstwa



zdefiniowanie problemów, wymagań i kryteriów wyboru ZSI



udokumentowanie istniejących procedur działania



opracowanie opisów procesów podstawowych i pomocniczych



przygotowanie koniecznej restrukturyzacji przedsiębiorstwa



ocena skali przedsięwzięcia, ryzyka, kosztów i terminów realizacji (studium

wykonalności)

Przykładowy sposoby integracji

Faza I - Analiza przedsiębiorstwa

obejmuje:



określenie celów strategicznych przedsiębiorstwa



zdefiniowanie problemów, wymagań i kryteriów wyboru ZSI



udokumentowanie istniejących procedur działania



opracowanie opisów procesów podstawowych i pomocniczych



przygotowanie koniecznej restrukturyzacji przedsiębiorstwa



ocena skali przedsięwzięcia, ryzyka, kosztów i terminów realizacji

(studium wykonalności)

Faza II - Opracowanie koncepcji informatyzacji przedsiębiorstwa

obejmuje:



selekcja i wybór gotowego ZSI



zestawienie oprogramowania aplikacyjnego według modelu

prototypowania



modelowanie

konfiguracji

oprogramowania

narzędziowego,

systemowego,

sieciowego

oraz

opracowanie

projektu

infrastruktury technicznej

Przykładowy sposoby integracji –
cd…

Faza III - Realizacja systemu

obejmuje:



przeprowadzenie koniecznej restrukturyzacji przedsiębiorstwa



kompletacja i organizacja dostaw sprzętu i oprogramowania



instalowanie i uruchomienie systemu



działalność

szkoleniowo-edukacyjna zorientowana na kadrę

kierowniczą przedsiębiorstwa



szkolenie użytkowników (podstawowe, systemowe, aplikacyjne)



wdrożenie i testowanie oprogramowania aplikacyjnego

Faza IV - Konserwacja i bieżący rozwój systemu

obejmuje:



umowy na długoterminową

współpracę w ramach nadzoru

autorskiego (wykonawczego)



konieczne modyfikacje ZSI, wynikające ze zmian obowiązujących

przepisów



rozbudowa oprogramowania i sprzętu, wynikająca z rosnących

wymagań użytkowników



stały rozwój dostarczonych rozwiązań w miarę pojawienia się

nowych technologii

Przykładowy sposoby integracji –
cd…

Obecne i postulowane

zastosowania ZSI



Większość zachodnich firm stworzyła infrastruktury

niezależne i reaktywne, a jedynie te przodujące firmy

mają infrastruktury współzależne.



W kraju najbardziej rozpowszechniony jest typ

niezależny.



Można uznać, iż stan zastosowań informatyki:

•

nie zmienił jednak istotnie organizacji pracy,

•

nie umożliwił integracji funkcji na wszystkich

poziomach zarządzania,

•

nie spowodował poważnych zmian w pozycji firm

na rynku, nie stworzył strategicznych szans dla
firmy, nie doprowadził do zmian w praktyce
zarządzania oraz strukturach organizacyjnych
firmy oraz strukturach organizacyjnych firmy.

• Pojedyncze systemy

dziedzinowe: sprzedaż,
kadry, płace, itp.

• Cząstkowość rozwiązań

• Wielu dostawców

komponentów systemu

• Niespójność funkcjonalna i

słaba integracja

• Zależność od jednej

platformy sprzętowej

• Słabe wspomaganie procesów

zarządzania

• Brak rachunkowości

zarządczej i kontrolingu

• Rosnące koszty utrzymania

• Ograniczone możliwości

rozwojowe

STAN OBECNY

• Kompleksowość funkcjonalna

• Integracja danych i procedur

• Jeden dostawca - integrator

rozwiązania

• Niezależność sprzętowo-

programowa

• Wykorzystanie możliwości Intra-,

ekstra- i Internetu oraz
multimediów w szerszym zakresie

• Pełne wspomaganie procesów

zarządzania w ramach orientacji
procesowej

• Realizacja rachunkowości

zarządczej i kontrolingu zgodnie z
systemem MRPII/ERP

• Uwzględnienie systemu jakości wg

przyjętych standardów

STAN POŻĄDANY

Charakterystyka obecnych i
postulowanych zastosowań SIZ

Informatyzacja firm a problemy

restrukturyzacyjne

(uwarunkowanie tworzenia ZSI)

Informatyzacja przedsiębiorstwa, mająca na celu wdrożenie ZSI,

wymaga poprzedzenia tego procesu

zmianami o charakterze

organizacyjnym.

REALIZACJ

A ZSI

strategia rozwoju

przedsiębiorstwa

oraz

strategia jego informatyzacji

restrukturyzacja

przedsiębiorstwa

techniczna

infrastruktura

informatyki

oprogramowanie aplikacyjne

oraz

transfer wiedzy

Restrukturyzacja jest przemyśleniem od podstaw i radykalnym

przeprojektowaniem procesów gospodarczych w celu osiągnięcia

zdecydowanego polepszenia bieżących, zasadniczych miar wydajności

(jakość, szybkość działania, poziom obsługi klientów).

Rodzaje restrukturyzacji:



podstawowa - orientacja ta podważa wszystkie założenia, na których
opiera się działalność gospodarcza, czyli dotychczasową strategię
przedsiębiorstwa oraz jego procedury operacyjne,



radykalna - w zależności od potrzeb tworzone (definiowane) są nowe
procesy, a nie usprawniane istniejące,



istotna - wzrost efektywności ma na celu znaczne podniesienie
sprawności funkcjonowania przedsiębiorstwa, a nie jedynie jej
marginalny przyrost, osiągany w wyniku technik ciągłego doskonalenia,



restrukturyzacja procesów - przełamuje się dotychczasowe podziały
funkcjonalne i likwiduje w ten sposób nieefektywność, będącą
skutkiem przekazywania pracy między wyspecjalizowanymi
jednostkami (działami) i pracownikami; działanie musi być
zorganizowane wokół procesów, a nie wokół indywidualnych zadań.

Informatyzacja przedsiębiorstwa a

problemy restrukturyzacyjne

W konsekwencji chodzi o stworzenie przedsiębiorstwa „

nowego

typu

” (zorientowanego procesowo).



określenie procesów w przedsiębiorstwie (początek-koniec,

właściciel, dostawcy-klienci, wspólne zależności czyli

podprocesy, powiązania z zasobami i zasileniami),



zmiany w zarządzaniu (wizja i misja przedsiębiorstwa,

kultura

wewnątrz-organizacyjna,

metody

kierowania,

rekrutacja i motywacja pracowników

Informatyzacja nie może wspierać nieefektywnych i

niewydajnych procesów

Działania

restrukturyzacyjne

powinny być nadrzędne

w stosunku do prac projektowo-

wdrożeniowych ZSI.

Informatyzacja przedsiębiorstwa:



faza pierwsza

- analiza i definicja procesów, celów, funkcji,

struktur danych, itp.,



faza druga

modelowanie procesów zgodnie z celami

przedsiębiorstwa, utworzenie struktury organizacyjnej firmy i

modelu systemu informatycznego,



faza trzecia

- tworzenie szczegółowych specyfikacji procesów i

tworzenie ZSI.

Informatyzacja przedsiębiorstwa a

problemy restrukturyzacyjne

Informatyzacja firmy a problemy

restrukturyzacji

Restrukturyzacja

przedsiębiorstwa

Przygotowanie infrastruktury

informatycznej

Budowa ZSI

Podejście

konwencjonalne

dzia

ania

szeregowe

ania

szeregowe

konieczno

modyfikacji

modelowania

proces

modelowania

proces

gospodarczych po drugim a

nawet trzecim etapie.

Restrukturyzacja

przedsiębiorstwa

Budowa ZSI

Uzyskanie kompletnej

infrastruktury informatycznej

Podejście

zalecane

dopuszcza si

wnoleg

ść

prac

restrukturyzacyjnych i wst

pnych

wdro

eniowych

liwo

iteracyjnego

uszczeg

iteracyjnego

uszczeg

owiania

dzia

wdro

eniowych

przygotowywania

docelowej

przygotowywania

docelowej

infrastruktury.

ANALIZA

MODELOWANIE

MODELOWANIE SI

BUDOWA MODELU

Co to jest analiza SI?

analiza procesów biznesowych;



identyfikacja procesów związanych z
planowanym systemem;



określenie grup obecnych i przyszłych
użytkowników;



analiza obecnych i przyszłych potrzeb
użytkowników;

określenie wymagań stawianych systemowi;
opracowanie funkcjonalnego modelu systemu i
ogólna specyfikacja systemu;
dokładne określenie nakładów i potrzebnych
zasobów oraz opracowanie harmonogramu.

W ramach analizy procesów biznesowych niezbędna może

okazać się poprawa jakości samych procesów, jeszcze przed

wdrożeniem systemu (restrukturyzacja w obiekcie

Analiza systemów informacyjnych (SI)

Jest to studium problemu w obrębie organizacji w

celu zarekomendowania rozwiązania
technicznego i stworzenia specyfikacji wymagań
„biznesowych”

Kto ją wykonuje?
Analityk (ang. Systems Analyst)

Analityk rozpoznaje problem wewnątrz organizacji, który może być rozwią-

zany za pomocą środków technicznych lub organizacyjnych

Jest pomostem między tymi, którzy potrzebują komputeryzacji, a tymi, którzy

znają technologię

Musi znać zarówno technologię, zasady zarządzania oraz posiadać podsta-

wową wiedzę dotyczącą charakteru analizowanych procesów biznesowych

Zadania analityka



Analityk zgłębia problemy i możliwości
organizacji



Przekształca wiedzę o potrzebach
informacyjnych na propozycję struktury
technicznej potrzebnej do ich zaspokojenia



Może być człowiekiem z zewnątrz. Dlaczego?



Konsultant zewnętrzny?



Pracownik?

Wiedza analityka: Podstawy teoretyczne z organizacji i zarządzania

technologie informacyjne i informatyczne

Może, ale nie musi posiadać wiedzy o przedmiocie działalności, ale musi
być w stanie ją przyswoić



Rodzaje analizy systemowej



Analiza potrzeb i celów



Strukturalna



Funkcjonalna



Analiza rozwojowa



Analiza efektywności



Analiza decyzyjna (analiza sytuacji
decyzyjnej, analiza wyboru warianty
działania)

Metody teorii zarządzania przydatne w

analizie systemów informacyjnych



Podejście systemowe



Analiza procesów biznesowych



Łańcuch wartości Portera



Inne analizy



SWOT



Stakeholders



cost/benefit

Podejście systemowe



Organizacja jako system (Bertalanffy, Wiener)



Wejście => Przetwarzanie => Wyjście



Sprzężenie zwrotne



Dekompozycja na podsystemy



Podsystemy jako „czarne skrzynki”

Analiza procesów biznesowych



Wykonywane czynności



Obieg dokumentów, materiałów



Powiązania pomiędzy nimi



Osoby wykonujące i odpowiedzialne

Co można skomputeryzować?

SWOT i inne analizy managerskie



S - strengths - silne strony



W - wekanesses - słabe strony



O - opportunities - szanse



T - threats - zagrożenia

czynniki pozytywne czynniki negatywne

Czynniki zewnętrzne (otoczenie)

szanse

zagrożenia

Czynniki wewnętrzne

(organizacja)

mocne strony

słabe strony

Co to jest modelowanie?

Modelowanie to wyszukiwanie w

systemie cech i związków
istotnych ze względu na dany
cel

Co to jest modelowanie SI?

Dla niektórych projektów, zwłaszcza przy tworzeniu
nowatorskiego oprogramowania w dziedzinach dotąd nie-
zinformatyzowanych,

modelowanie jest być

może

najważniejszym

elementem

rozwijania

oprogramowania,

którego

największym

stopniu

zależy

sukces

całego

przedsięwzięcia

informatycznego.

innych

projektach

zdarza

się

przechodzenie

bezpośrednio

fazy

wymagań

bardzo

konkretnego projektu kodu (można powiedzieć, że
faza modelowania jest tutaj niejawna, a model
systemu odbija się w architekturze kodu)

Co to jest modelowanie SI?



Modelowanie można określić jako próbę uchwycenia w

kategoriach informatycznych i wyrażenia za pomocą

specjalnej notacji graficznej najważniejszych cech

rozwijanego systemu oraz jego otoczenia



Efektem procesu modelowania jest „adekwatny” do

celu modelowania model SI



Powstały w efekcie model ma umożliwić łatwe

zaprojektowanie i implementację kodu



Na każdym etapie tworzenia oprogramowania

modelowanie ma dostarczać tylko tyle informacji ile

jest w danym momencie potrzebne (pomijając

nieistotne szczegóły – stąd modelowanie jest sztuką

abstrakcji)

Dwie ogólnie znane metody
stosowane w modelowaniu



Top-down (z góry w dół)



Bottom-up (z dołu do góry)

Ogólna procedura modelowania

Określenie celu modelowania systemu, analiza

rzeczywistości, identyfikacja obiektu modelowania i

opracowanie założeń do wyodrębnionej części

rzeczywistości, zdefiniowanie granic modelowanego

systemu, zdefiniowanie warunków i ograniczeń

realizacyjnych w procesie modelowania

Budowa (opracowanie) modelu

systemu, dekompozycja i agregacja –

opracowanie składowych modelowanego

systemu

Weryfikacja (testowanie) i adaptacja

modelu

Implementacja modelu w warunkach

rzeczywistych

Modelowanie a model SI

Efektem procesu modelowania jest

„adekwatny” do celu modelowania
model SI

Modelowanie to całokształt czynności
zmierzających do utworzenia konstrukcji
modelu i zweryfikowania modelu

Co to jest model?

Semantycznie spójna abstrakcja systemu
tworzona z pewnej perspektywy - kompletny
opis systemu z pewnej perspektywy.
Sformułowanie „kompletny opis” oznacza tu, że
żadna dodatkowa informacja nie jest potrzebna,
aby zrozumieć system z danej perspektywy.

Model nie jest rzeczywistością, stanowi jedynie opis rzeczywistości, jej
uproszczenie.
Pojedynczy model zwykle nie wystarcza do zrozumienia całości problemu i
znalezienia odpowiedniego rozwiązania, zazwyczaj potrzebujemy ich wiele.
Razem tworzą kompletny opis całości - muszą być wzajemnie spójne i nie
redundantne.

Tworzenie modeli wspomaga zapanowanie nad realizacją dużych, złożonych
systemów.

Co to jest model?

Model jest uproszczoną reprezentacją
systemu, w czasie i przestrzeni, stworzoną w
zamiarze zrozumienia zachowania systemu
rzeczywistego
Model stanowi kompletną reprezentację
adresującą pewne aspekty systemu
informatycznego

Rodzaje modeli

Modele mogą być:

fizyczne,

abstrakcyjne,

jakościowe:

•

opisowe – co jest jakie,

•

wyjaśniające – co od czego zależy

ilościowe (prognostyczne).

Modele ilościowe można podzielić na

deterministyczne, rozmyte,

probabilistyczne

i zależą od wiedzy jaką posiadamy o systemie

Rodzaje modeli – cd…

• Projektowy

• Statyczny,

• Dynamiczny,

• Czasu rzeczywistego

• Projektowy lub modele procesów systemów złożonych

• Implementacyjny

• Interakcji

• Wdrożeniowy

• Przypadków użycia

• Formalny

• Funkcjonalny

• Szczegółowy

• Ogólny…… i wiele innych

Rodzaje modeli- cd…



Statyczny model strukturalny obejmuje
komponenty lub podsystemy, które można
zbudować jako niezależne jednostki.



Model dynamiczny procesu, w którym
przedstawia się podział systemu na procesy czasu
wykonania.



Model interfejsów, w którym definiuje się usługi
oferowane przez każdy podsystem za
pośrednictwem jego interfejsu publicznego.



Model związków, który obejmuje związki, takie
jak przepływ danych między podsystemami.



…

Ważna jest znajomość modeli, ich zastosowań, wad oraz zalet.

Ludzie zaangażowani w procesie
modelowania SI

Analitycy

Projektanci

Użytkownicy

Eksperci

dziedzinowi

Testerzy

Realizatorzy projektu

Eksperci w zakresie

modelowania SI i doradcy

informatyczni

Integratorzy

Zespoły

wdrożeniowe

Rodzaje modelowania SI



Formalne



Pojęciowe – konceptualne



Zwinne



Przypadków użycia



Strukturalne



Komponentowe



Obiektowe



Algorytmiczne



i wiele innych zależnych od rodzaju

modelu dziedziny zastosowań, metody i

procedury modelowania ….

Modelowanie formalne

Definicja

wymagań

Specyfikacja

formalna

Przekształcenie

formalne

model SI

Weryfikacja

modelu

Modelowanie pojęciowe



Projektant i programista muszą dokładnie wyobrazić

sobie problem oraz metodę jego rozwiązania.

Zasadnicze procesy tworzenia oprogramowania

zachodzą w ludzkim umyśle i nie są związane z

jakimkolwiek językiem programowania.



Pojęcia modelowania pojęciowego (conceptual

modeling) oraz modelu pojęciowego (conceptual

model) odnoszą się procesów myślowych i wyobrażeń

towarzyszących pracy nad oprogramowaniem.



Modelowanie pojęciowe jest wspomagane przez

środki wzmacniające ludzką pamięć i wyobraźnię.

Służą one do przedstawienia rzeczywistości

opisywanej przez dane, przedstawienia procesów

zachodzących w rzeczywistości, struktur danych oraz

programów składających się na konstrukcję systemu.

Trwałą tendencją w rozwoju metod i narzędzi projektowania

oraz konstrukcji SI jest

dążenie do minimalizacji luki

pomiędzy

myśleniem

rzeczywistym

problemie

myśleniem o danych i procesach zachodzących na danych.

Percepcja rzeczywistego

świata

Analityczny model

rzeczywistości

Model struktur danych

i procesów w SI

... ...

...

... ...

...

... ...

...

... ...

...

... ...

...

... ...

...

odwzorowanie

Modelowanie pojęciowe cd…

Modelowania a identyfikacja



Identyfikacja w

teorii sterowania

oznacza

rozpoznawanie

(to jest sporządzenie opisu

matematycznego) właściwości statycznych i
dynamicznych elementów i

układów

automatyki



Identyfikacja oznacza znalezienie
zależności między wejściem a wyjściem

(dla elementu automatyki, obiektu, układu
regulacji) na podstawie danych
doświadczalnych.

Układ

automatyki

Modelowania a identyfikacja



Po poddaniu obiektu (procesu) szeregowi doświadczeń

dobiera się bowiem parametry modelu w taki sposób,

aby pasował on do danych doświadczalnych.

Identyfikacja odgrywa zasadniczą rolę w odniesieniu

do obiektów i procesów regulacji, gdyż umożliwia

poprawne nastrojenie układu regulacji automatycznej.

W czasie identyfikacji określane są bowiem wartości

parametrów modelu obiektu (procesu), które

wykorzystuje się następnie w doborze nastaw

regulatora

sterującego rzeczywistym obiektem

(procesem).

Układ

automatyki

Jakie parametry

modelu ???

Modelowania a identyfikacja



Po poddaniu obiektu (procesu) szeregowi doświadczeń

dobiera się bowiem parametry modelu w taki sposób,

aby pasował on do danych doświadczalnych.

Identyfikacja odgrywa zasadniczą rolę w odniesieniu

do obiektów i procesów regulacji, gdyż umożliwia

poprawne nastrojenie układu regulacji automatycznej.

W czasie identyfikacji określane są bowiem wartości

parametrów modelu obiektu (procesu), które

wykorzystuje się następnie w doborze nastaw

regulatora

sterującego rzeczywistym obiektem

(procesem).

Układ

automatyki

Jakie parametry

modelu ???

REGULATOR

Co to jest identyfikacja systemu?

Identyfikacja systemu - to wyznaczanie modelu

(matematycznego) systemu na podstawie
wiedzy o jego zachowaniu (wiedza eksperta,
wiedza eksperymentalna)

Wiedza eksperymentalna

• Wiedza

eksperymentalna

wiedza

obiekcie

(systemie)

uzyskana

podstawie

szeregu

przeprowadzonych obserwacji i pomiarów.

Identyfikacja (kreowanie) systemu w
ujęciu czarnej skrzynki



Kreowania systemu we-wy /przyczynowo-skutkowy/

poprzez ustalenie wielkości wejściowych mających
istotny wpływ na zdefiniowaną wielkość wyjściową

(satysfakcję, jakość)



Kreowanie podzielone na 7 zależnych, następujących po

sobie etapów

(zdefiniowane)

Etap pierwszy: Burza mózgów

Wypisanie wszystkich potencjalnych czynników
mających wpływ na zdefiniowaną wielkość wyjściową
Czynniki jako wielkości wejściowe:

u – wejścia sterowalne (decyzyjne)

w – wejścia obserwowalne (mierzalne)
z – wielkości losowe (zakłócenia)- możliwe do oszacowania

Wstępne określenie wielkości wejściowych systemu.

Etap drugi: lista kandydatów

Doprecyzowanie nazw czynników - mogą być

wieloznaczne

i mogą prowadzić do niespójności w kreowaniu

systemu – wiedza ekspercka może być źle
zinterpretowana

Opracowanie wstępnej listy czynników

Opracowanie ankiet dla ekspertów, ze szczególnym

uwzględnieniem jednolitego sposobu priorytetowania

(ocena ważności) przez ekspertów (wypełniających

ankietę)

Etap trzeci:
wstępny ranking ekspertów

Dobór ekspertów oceniających czynniki

i ewentualnie ustalenie „wag” ekspertów.
Eksperci wypełniają przygotowane ankiety
Możliwe zastosowanie różnych metod

rankingu ekspertów, np.

wybór 50% istotnych czynników
przyporządkowanie każdemu czynnikowi

wartości

1 (mało istotny), 2 (istotny), 3 (bardzo istotny)

Wyselekcjonowanie wielkości wejściowych, które mają

„odczuwalny” wpływ na działanie systemu.
Selekcja przeprowadzona na podstawie histogramu, na

którym każdemu czynnikowi przyporządkowano sumaryczną

liczbę punktów. Selekcja wg. jednej z metod:

arbitralnie ustalona ilość czynników najwyżej punktowanych,
wybór czynników, dla których suma punktów równa 70%

wszystkich punktów itp.,
wybór czynników o sumie punktów większej niż przyjęty próg

punktowy.

Etap czwarty:
Selekcja wielkości wejściowych

Etap piąty: ustalenie zakresów
wielkości wejściowych

Ustalenie zakresów ustalonych wielkości wejściowych i ewentualnie

dokładna ich definicja przy wielkościach nie będących liczbami

{bardzo dużo, dużo, średnio, mało, bardzo mało}
{wygodny, mało wygodny …}

Konsekwentnie dla wielkości nie liczbowych należy precyzyjnie

zdefiniować sposób ich kodowania oraz odpowiadający mu

znormalizowany zakres wartości liczbowych (np. {od 1 do 5})

lub od 0% do 100%

Etap szósty:
Ostateczny ranking ekspertów

Na podstawie informacji zebranych

w poprzednich etapach następuje ostateczny

wybór czynników i wielkości wejściowych

(x1,x2,…) systemu

Ustalenie wag poszczególnych czynników

(wielkości wejściowych) poprzez kolejną ocenę

ekspertów. Ekspert otrzymuje spis ustalonych

czynników i przyporządkowuje każdemu wagi

np. dla 7 czynników są to liczby od 1 do 7. Dla

najbardziej istotnego jego zdaniem będzie 7 a 1

dla najmniej istotnego. Waga danego czynnika

jest następnie wyliczana jako procentowy udział

sumy uzyskanych przez dany czynnik punktowy

w stosunku do sumarycznej liczby punktów dla

wszystkich czynników

Etap siódmy: sformułowanie
modelu matematycznego

Sformułowanie modelu

matematycznego
z wielkościami wejściowymi np.

NORM - współczynnik
normalizujący,
aby Y = <0,100>
(ew. bardziej skomplikowane
modele nie tylko liniowe)

...)

(

[%]

NORM









Etap siódmy: sformułowanie
modelu matematycznego

Przedstawienie schematu blokowego
modelu systemu wejściowo-wyjściowego,

przykładowo dla modelu liniowego:

Modele matematyczne mogą być
różne dla różnych podgrup ekspertów,
jeśli takie podgrupy wyróżniono

.
.
.
.
.

Dlaczego modelowanie i analiza SI
jest ważna?



Nieudane projekty to rzeczywistość



Ciągła potrzeba doskonalenia i
usprawniania procesów wytwarzania
systemów informatycznych



Nowe zastosowania systemów
informatycznych



Coraz większa złożoność systemów
informatycznych



Ogólny kryzys procesów wytwarzania
systemów informatycznych

Nieudany projekt informatyczny



Miarą niepowodzenia projektu
jest niedotrzymania jednego
lub więcej z następujących
parametrów:



Budżet



Czas realizacji



Funkcjonalność

Rzeczywistość „w statystyce”



w ponad

50%

przedsięwzięciach

informatycznych przekraczany jest
termin i

budżet,



ponad

25%

przedsięwzięć

informatycznych jest przerywanych.

Marsz ku klęsce!!!

Zdecydowana większość

dużych projektów

informatycznych

jest z góry

skazana na

niepowodzenie

Polskie przykłady



Informatyzacja PZU



Informatyzacja ZUS



System POJAZD



Informatyzacja urzędów
skarbowych

Raport The Standish Group

Amerykańska instytucja badawcza.
Działalność:

kompleksowa analiza

rynku amerykańskiego w zakresie
skuteczności realizacji projektów
informatycznych.

www.standishgroup.com

Dlaczego CHAOS?

O chaosie w projektowaniu SI decyduje
przeważająca liczba przedsięwzięć zakończonych :



niepowodzeniem w sensie ilościowym,
czyli:



przekroczeniem estymowanego

czasu

trwania działań projektowych;



przekroczeniem

budżetu

;



porzuceniem

z określonych powodów;



niepowodzeniem w sensie jakościowym,
kiedy gotowy system wykazuje dużą

niezgodność

z pierwotną

specyfikacją

wymagań użytkownika

Chaos – stan niezorganizowania, zamętu, nieładu

Kiedy projekt może się „udać”

Zakres

Czas

Koszty

Udany projekt

Produkt końcowy

Termin

Koszty realizacji

Wydatki na projekty SI

250

300

260

275

255

220

240

260

280

300

Wydatki w mld USD

Rok

2002
2000
1998
1996
1994

200 tys.

projektów

Realizacja projektów SI

20%

40%

60%

80%

100%

1994

1996

1998

2000

2002

Niepowodzenie częściowe
Niepowodzenie całkowite
Sukces

Realizacja projektów SI

100

1994

1996

1998

2000

2002

Sukces

Niepowodzenie całkowite

Niepowodzenie częściowe

Niepowodzenie razem

Jakość wytworzonych systemów SI

większy

jest tworzony system, tym

mniejsza

zgodność produktu końcowego

pierwotną

specyfikacją wymagań

funkcjonalnych

, a w związku z tym

mniejsze

zadowolenie klientów

1994

2000

2002

Zmiana:

2002 do

2000

Zmiana:

2002 do

1994

Zgodność
produktu ze
specyfikacją

61% 67% 51%

-16%

-10%

Czynniki sukcesu

Czynnik

1994

2000

Zaangażowanie użytkownika

16%

Wsparcie zarządu (kierownictwa, sponsora)

14%

18%

Jasne sformułowanie wymagań

13%

Właściwe planowanie

10%

Brak

Realne oczekiwania

Brak

Krótsze etapy projektowania

10%

Kompetentny zespół projektowy

Brak

Jasno określona własność projektu (odpowiedzialność)

Brak

Jasna wizja i cele

12%

Ciężko pracujący, skupiony na projekcie zespół

Brak

Doświadczony kierownik zespołu

Brak (ew. 7)

14%

Formalna metodyka

Brak

Zastosowanie standardów infrastruktury

Brak

Wiarygodne oszacowanie

Brak (ew. 4)

Inne

Wnioski z badań

Chaos w obszarze projektowania SI

spowodowany jest

błędami ludzkimi

, a nie

technologicznymi



Niewłaściwa interpretacja wymagań klienta



Częste i zbyt późne zgłaszanie zmian związanych z
oprogramowaniem



Nieprawidłowe oszacowanie czasu realizacji projektu
(opóźnienia czasowe)



Nieprawidłowe oszacowanie budżetu i zasobów



Problemy w komunikacji pomiędzy członkami zespołu
projektowego



Problemy w komunikacji pomiędzy zespołem projektowym a
klientem



Duża liczba małych błędów w oprogramowaniu, wynikająca z
nieprawidłowego testowania



Problemy wdrożeniowe i brak odpowiedniej pielęgnacji
oprogramowania

Podstawowe problemy

Złożoność oprogramowania

(wewnętrzna i wymagana komunikacją z innymi
systemami – patrz MS Windows/MS Office)



UNIX

– 4 000 000 linii kodu



Windows 2000

– 35 000 000 linii

kodu



Windows XP

– około 50 000 000

linii kodu

Rok

Liczba

użytkowników

Liczba linii

kodu

1991

100

10 000

1992

1000

40 000

1993

20 000

100 000

1994

100 000

170 000

1995

500 000

250 000

1996

1 500 000

400 000

1998

7 500 000

1 500 000

Rozwój systemu LINUX:

Złożoność oprogramowania

Windows

Zespół

programistów

Liczba testerów

NT 3.1

200 osób

140 osób

NT 3.5

300 osób

230 osób

NT 3.51

450 osób

325 osób

NT 4.0

800 osób

700 osób

Win 2000

1400 osób

1700 osób

Wielość współautorów oraz problemy związane z
błędami na etapie określania wymagań,
projektowania, wykonywania i testowania

Liczebność zespołów projektowych

Źródła złożoności systemów
informatycznych

Software

Złożoność

technologiczna

Złożoność
dziedzinowa

Złożoność
psychologiczna

Metody projektowania

Ciągle niedoskonałe

metody

narzędzia

tworzenia i weryfikacji systemów
informatycznych

UML

DFD

ERD

SADT

PSL/
PSA

RSL/
REVS

HELP!

Kryzys oprogramowania



Długi i kosztowny cykl tworzenia
oprogramowania



Długi i kosztowny cykl życia SI, wymagający
stałych zmian



Wysokie koszty utrzymania oprogramowania



Wysokie prawdopodobieństwo
niepowodzenia projektu programistycznego



Sprzeczność pomiędzy odpowiedzialnością
współczesnych systemów informatycznych, a
ich zawodnością



Problemy współdziałania niezależnie
zbudowanego oprogramowania, szczególnie
istotne przy dzisiejszych tendencjach
integracyjnych

Kryzys oprogramowania



Uzależnienie organizacji od systemów
komputerowych i przyjętych technologii przetwarzania
informacji (często niestabilnych w długim horyzoncie
czasowym)



Dążenie do przystosowania istniejących i działających
systemów do nowych wymagań i tendencji oraz platform
sprzętowo-programowych



Niski stopień powtarzalności poszczególnych
przedsięwzięć



Niska kultura ponownego użycia wytworzonych
komponentów projektów i oprogramowania



Szybki rozwój narzędzi informatycznych

Prawa Murphiego



„główne błędy powstają na
styku:

klient –

firma informatyczna

projektant

programista

komputer

”



„jeżeli gdziekolwiek może pojawić się błąd, tam

na pewno się pojawi

”



„nie ma programów bezbłędnych, są tylko
takie w których dotąd

nie znaleziono błędu

”

CYKL ŻYCIA SI

• Projektowanie
• Produkowanie
• Użytkowanie

• Obsługiwanie
• Likwidowanie

fazy wytwórcze

fazy eksploatacyjne

Generowanie ideowe

Generowanie materialne

Generowanie wtórne

Degenerowanie

Regenerowanie

pro

eksploatacja

uż

sł

lik

ido

SI jako obiekt techniczny

Każdy SI ma swój cykl życia

Model procesu wytwarzania SI to
inaczej model cyklu życia SI

Cykl życia SI - praktyka a teoria



Rozwój SI jest złożonym procesem

realizowanym etapowo w określonym czasie.



By zapewnić powtarzalną jakość realizowanych SI

definiuje się pojęcie cyklu życia SI dzieląc
całość na szereg tzw. faz życia SI.



Poszczególnym stadiom rozwoju SI

przyporządkowuje się odpowiednie zestawy
czynności, których celem jest uporządkowanie
przebiegu prac, umożliwienie planowania i
zarządzania dostępnymi zasobami.



Rodzaj oraz kolejność zdefiniowanych faz

składają się na tzw. model cyklu życia

oprogramowania.

Modele cyklu życia SI– c.d.

Literatura definiuje szereg modeli cyklu życia SI



Model kaskadowy

(ang. waterfall)



Metodologia V



Realizacja kierowana dokumentami

(ang. document driving)



Prototypowanie

(ang. prototyping)



Programowanie odkrywcze

(ang. Exploratory

programming)



Realizacja przyrostowa

(ang. Incremental

development)



Montaż z gotowych elementów

(ang.

composition of re-usable components)



Model spiralny

(ang. spiral)



Formalne transformacje



Inne modyfikacje i multimetody

Model kaskadowy

Planowanie

Analiza

Projektowanie

Implementacja

Testowanie

Konserwacja

Model kaskadowy (

ang. waterfall

)

jest jednym z najbardziej
rozpowszechnionych modeli cyklu
życia SI. Nazwa model kaskadowy
została po raz pierwszy użyta w
artykule Winstona W. Royce’a pt.:

"Managing the Development of

Large Software Systems„.

Model kaskadowy jest uznawany często za

dość

przestarzały i mało elastyczny

gdyż:



nie można przejść do kolejnej fazy przed
zakończeniem poprzedniej (sztywno narzucony
iteracyjny proces),



powtarzanie dowolnej iteracji (fazy) często

okazuje się kosztowne,



ścisła kolejność postępowania utrudnia

komunikację z klientem.



fazę określania wymagań, w której określane są cele oraz
szczegółowe wymagania wobec tworzonego systemu,



fazę projektowania, w której powstaje szczegółowy projekt
systemu spełniającego ustalone wcześniej wymagania,



fazę implementacji/kodowania oraz testowania modułów

, w

której projekt zostaje zaimplementowany w konkretnym
środowisku programistycznym oraz wykonywane są testy
poszczególnych modułów,



fazę

testowania

której

następuje

integracja

poszczególnych

modułów

połączona

testowaniem

poszczególnych podsystemów oraz całego oprogramowania,



fazę konserwacji

, w której system jest wykorzystywane

przez użytkownika(ów), a producent dokonuje konserwacji
oprogramowania — wykonuje modyfikacje polegające na
usuwaniu błędów, zmianach i rozszerzaniu funkcji systemu.

Model kaskadowy wprowadza następujące fazy podstawowe:

Model kaskadowy

(liniowy, wodospadowy)

Analiza

potrzeb

Specyfikowani

e systemu

Projektowanie

systemu

Programowanie

systemu

Testowanie

systemu

Integrowanie

systemu

Modyfikowanie

systemu

Eksploatowanie

systemu

Zaniechanie

eksploatacji

Model kaskadowy

(liniowy, wodospadowy)

W modelu kaskadowym często wyróżnia się pewne dodatkowe fazy,
które częściowo nakładają się na fazy wymienione powyżej. Są to fazy:



faza strategiczna wykonywana przed formalnym podjęciem
decyzji o realizacji przedsięwzięcia. W tej fazie podejmowane są
pewne strategiczne decyzje dotyczące dalszych etapów prac. Faza
ta wymaga oczywiście przynajmniej ogólnego określenia wymagań,



faza analizy

, w której budowany jest logiczny model systemu.



faza dokumentacji

, w której wytwarzana jest dokumentacja

użytkownika. Opracowywanie dokumentacji przebiega równolegle z
produkcją oprogramowania. Faza to może rozpocząć się już w
trakcie określania wymagań. Sugeruje się nawet, że podręcznik
użytkownika dla przyszłego systemu jest dobrym dokumentem
opisującym wymagania. Ostatnie zmiany w dokumentacji
dokonywane są w fazie instalacji.



faza instalacji

, w której następuje przekazanie systemu

użytkownikowi.

Model kaskadowy

(liniowy, wodospadowy)

OKREŚLENIE

WYMAGAŃ

PROJEKTOWANIE

IMPLEMENTACJA

TESTOWANIE

KONSERWACJA

FAZA

STRATEGICZNA

ANALIZA

INSTALACJA

DOKUMENTACJA

Fazy dodatkowe

Fazy zasadnicze

Model kaskadowy

(liniowy, wodospadowy)

Ocena modelu kaskadowego SI



Model kaskadowy jest przejrzysty, czytelny, ale nie
praktyczny!



Koncepcyjnie model ten jest bardzo ważny, wskazuje
etapy które musza wystąpić podczas projektowania
SI, jednak w praktyce zbyt późno się orientujemy, że
model nie spełnia naszych oczekiwań.



Kluczową sprawą jest właściwe zebranie danych na
etapie analizy. Napotyka to jednak na specyficzne
przeszkody. Czasem użytkownicy celowo
wprowadzają w błąd zespół projektowy.



Błąd w początkowym etapie trudno naprawić w
dalszych etapach



Wydłużony okres realizacji SI – nie widać efektów

Ocena cyklu życia SI

Szczeg

owa analiza zagadnie

czasoch

onno

ci i kosztoch

onno

ci realizacji systemu

informatycznego sta

a si

podstaw

krytyki tradycyjnych cykli

ycia systemu.

Nakład pracy w cyklu tworzenia systemu

Analiza potrzeb

Projektowanie

Kodowanie

Eksploatacja

67%

Testowanie

15%

Koszty poprawiania błędów

Projektowanie

13%

Inne

Kodowanie

Analiza potrzeb

82%

Metodologia V

Realizacja kierowana
dokumentami

•

Model

ten

jest

Model

ten

jest

cis

łą

realizacj

modelu

kaskadowego,

•

ada si

c z szeregu nast

puj

cych po sobie

faz.

•

Dodatkowo zak

ada si

e ka

da faza ko

czy si

opracowaniem szeregu dokument

w, w pe

opisuj

cych wyniki tej fazy.

•

Dokumenty

powinny

Dokumenty

powinny

wystarczaj

podstaw

do realizacji dalszych faz. Dokumenty

te s

udost

pniane klientowi.

•

Dopiero po zaakceptowaniu dokumentacji przez

klienta rozpoczynana jest kolejna faza.

Prototypowanie

wnym celem realizacji prototypu jest

lepsze

okre

lepsze

okre

lenie

wymaga

lenie

wymaga

wykrycie

nieporozumie

pomi

dzy

klientem

dzy

klientem

rcami systemu, wykrycie brakuj

cych

funkcji, wykrycie trudnych us

ug, wykrycie

brak

w w specyfikacji wymaga

Model ten

ada si

z nast

puj

cych faz

•

lne okre

lenie wymaga

•

budowa prototypu,

•

weryfikacja prototypu przez klienta,

•

ne okre

lenie wymaga

•

realizacja pe

nego systemu zgodnie z

modelem kaskadowym.

Prototypowanie



Wykonanie prototypu



Ocena prototypu



Projekt SI na bazie uwag do prototypu
systemu

Wady



Zwykle modyfikuje się prototyp zamiast
go zrealizować od nowa

Zalety:



Krótki czas od wymagań do widoczych
efektów

Procesy prototypowania
wytwórczego

Programowanie odkrywcze

Sporządź

ogólną

specyfikację

Zbuduj
system

Skorzystaj

z systemu

Dostarcz

system

klientowi

System spełnia

wymagania?

Nie

Tak

Problemy wynikające podczas programowania odkrywczego

(ang. exploratory

programming) to między innymi:

brak prawdziwej i pełnej specyfikacji co uniemożliwia kompletną weryfikację

systemu,

bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,

niespójna i dość chaotyczna struktura systemu

Realizacja przyrostowa



Ustala się ogólną koncepcję systemu



Wyróżnia się składowe funkcjonalności



Określa się kolejność realizacji

funkcjonalności (modułów)



Najpierw realizuje się określoną

funkcjonalność (kryterium:

merytoryczność funkcji, efekty

cząstkowe) od początku do końca np..

Zgodnie z modelem kaskadowym,



Wybiera się kolejną funkcjonalność do

realizacji

Realizacja SI z gotowych
komponentów

metody tworzenia SI są

wyodrębnione jako odrębna filozofia
tworzenia systemów nie koniecznie
od podstaw, nie koniecznie od zera
tylko jakby proces rozwijania na
bazie istniejących systemów,
systemu o ciekawszych, bogatszych
możliwościach.

Realizacja SI z gotowych
komponentów



Model montażu z gotowych elementów, zwany

też programowaniem z półki, kładzie

szczególny nacisk na możliwości redukcji

nakładów przez maksymalne wykorzystanie
podobieństw tworzonego oprogramowania do

wcześniej tworzonych systemów.



Gotowe elementy mogą być wykorzystywane

na różnych etapach realizacji przedsięwzięcia.

Najczęściej są one wykorzystywane na etapie

implementacji



Przykładem może być stosowanie:



bibliotek,



języków czwartej generacji, których złożone
instrukcje mogą być traktowane jako

odwołania do wbudowanych bibliotek,



pełnych aplikacji, np. wykorzystanie

przeglądarki plików pomocy w systemie MS

Windows.

Zasoby ponownego użycia
gotowych elementów



komponenty oprogramowania

(jednostki

montażowe oprogramowania, których interfejsy
są określone na drodze umów i których
kontekstowe zależności są jawne

)



wzorce oprogramowania

(formy

reprezentacji wiedzy i doświadczenia
projektantów w postaci opisów typowych
problemów występujących w tworzeniu
oprogramowania oraz ich rozwiązań, które mogą
być wielokrotnie wykorzystywane w różnych
okolicznościach)

Wybór systemu gotowego jako
metoda informatyzacji firmy

Nie należy zaczynać od projektowania nowego systemu - jeżeli jest

to tylko możliwe lepiej oprzeć się o gotowe rozwiązanie.

li nie ma

gotowego

systemu to

trzeba go

zaprojektowa

Wybór systemu gotowego cd..

Fazy procedury wyboru gotowego ZSI



Ocena aktualnej technologii



Definiowanie założeń przedsięwzięcia



Opracowanie zapytania ofertowego



Ocena ofert



Prezentacje i wizyty referencyjne



Negocjacje, wybór ZSI i podpisanie umowy

Procedura wyboru gotowego ZSI (SI)

faza 1

czas

1. ocenę aktualnej technologii przetwarzania danych w

informatyzowanym przedsiębiorstwie

faza 2

2. zdefiniowanie założeń przedsięwzięcia informatycznego

faza 3

3. opracowanie zapytania ofertowego, określenie postaci odpowiedzi

ofertowej wraz z procedurą jej oceny

faza 4

4. ocena odpowiedzi oferentów, ich klasyfikacja i utworzenie tzw.

krótkiej listy

faza 5

5. prezentacje i wizyty referencyjne

faza 6

6. negocjacje, wybór ZSI i podpisanie umów realizacyjnych

Fazy procedury wyboru gotowego ZSI

Model spiralny

Model spiralny został
zaproponowany w 1986
roku przez Barry’ego
Boehma w artykule

„

A spiral model of

software development
and enhancement”.

Zaproponowany cykl życia
oprogramowania łączył w
sobie elementy
projektowania /
konstruowania systemu
zgodnie z modelem
kaskadowym oraz z
elementami
prototypowania.

Model formalnych transformacji jest postulowany w ramach

tzw. formalnego nurtu w in

ynierii oprogramowania. Zak

ada

on,

wymagania

wobec systemu

specyfikowane są w

pewnym

formalnym języku

. Wymagania te s

nast

pnie

transformowane do pewnej postaci po

redniej bli

szej kodowi

w pewnym j

zyku programowania. Posta

ta podlega dalszym

automatycznym transformacjom do kolejnych form coraz

bli

szych kodowi. Jedna z kolejnych postaci formalnych jest

na tyle bliska kodowi,

e mo

e by

w automatyczny spos

prze

ona na kod w konkretnym j

zyku programowania.

Wszystkie te transformacje wykonywane s

bez udzia

u ludzi.

Model ten w chwili obecnej nale

y uzna

propozycj

teoretyczn

daleka

jest

zastosowa

daleka

jest

zastosowa

profesjonalnej produkcji oprogramowania. Pierwsze pr

zastosowania tego modelu wprowadzi

a firma Microsoft.

Formalne transformacje

Inne spojrzenie na tradycyjny (klasyczny) model cyklu życia systemu z

wyróżnieniem dwóch zasadniczych ścieżek:

Akceptacja

Eksploatacja

Ocena

Analiza potrzeb

Definiowanie założeń

Projektowanie

Wdrożenie

DZIEDZINA

PRZEDMIOTOWA

Analiza potrzeb

Definiowanie założeń

Projektowanie

Wdrożenie

•Ścieżka tworzenia

•Ścieżka eksploatacji

Inny zmodyfikowany cykl

ycia SI

Powstały nowe wzorce projektowania SI w oparciu o:



generatory

zastosowań

(definiowanie

transakcji,

prowadzenie dialogu, tworzenie bazy danych, aktualizacja

plików, generowanie zestawień, przetwarzanie zapytań) ,



pakiety zastosowań (zawiera oprogramowanie określonej

dziedziny zastosowań całkowicie lub częściowo gotowe do

wdrożenia),



prototypowanie (wiąże się

z tworzeniem prototypu

systemu).

Metodyczne

podejście do

systemu

Generatory

zastosowań

Pakiety

zastosowań

Prototypowanie

System

wynikowy

ograniczenie

programowania

zapewnienie bieżącego sprzężenia zwrotnego

skrócenie czasu tworzenia

Modyfikacje tradycyjnego cyklu

ycia SI

Ze wzgl

du na r

norodno

ść

modeli trudno okre

jednolity

standard.

Jednak mo

na (na bazie do

wiadcze

i analizy innych modeli)

kusi

o pewne uog

lnienia.

Przyk

ad:

1. Planowanie systemu

2. Analiza systemu

3. Projektowanie systemu

4. Wdra

anie systemu

5. U

ytkowanie, modyfikacja i adaptacja systemu

Inna propozycja og

lnego modelu

cyklu

ycia systemu

Modele cyklu życia SI - praktyka a

teoria – c.d.



Proponowane w literaturze modele cyklu życia SI są

przeważnie zbyt idealistyczną wizją rzeczywistości.



W praktyce rzadko się zdarza by możliwe było realizowanie

projektów ściśle według sztywno nakreślonych ram danego
modelu zaczerpniętego z literatury.



Rozpowszechnienie się systemów komputerowych oraz

rosnący popyt na SI wymusza od projektantów i
programistów odpowiedniego poziomu elastyczności.

Cykl życia SI jest determinowany poprzez:

rozmiar realizowanego przedsięwzięcia,
dziedzinę problemu, którego dotyczy nowo powstający SI,
rynek zbytu,

zmienne wymagania klienta

i skuteczność ich

zaspakajania

Inne metody … - podejście społeczne
(ang. soft approaches)



zakłada nierozłączność aspektów technicznych
systemów informatycznych od aspektów
pozatechnicznych – organizacji, zarządzania,
socjologii, psychologii itd.



jednym z najbardziej znanych podejść
społecznych jest

SSM

(Soft Systems

Methodology),



Inną metodą jest

ETHICS

(Effective Technical

and Human Implementation of Computer-
Based Systems),

Od techno- do antypo-centrycyzmu
w wytwarzaniu SI



Klasyczne podejście do projektowania SI było
techno-centryczne.



Opierało się ono na założeniu, że trzeba
włożyć wiele wysiłku w tworzenie i
optymalizowanie coraz doskonalszych
systemów komputerowych. Natomiast
użytkownicy systemów mieli się do nich
dostosować.

Od techno- do antypo-centrycyzmu
w wytwarzaniu SI – cd…



Takie podejście było iluzją, ponieważ celem
SI zwłaszcza SI do zarządzanie nie jest
przetwarzanie danych tylko wiedza, która
pozwoli nam podejmować rozmaite decyzje.
Natomiast ta wiedza rodzi się w umyśle
człowieka. Dlatego też człowiek jest punktem
wyjścia w projektowaniu nowoczesnych SI.

Od techno- do antypo-centrycyzmu
w wytwarzaniu SI – cd…



Nowe podejście to antypo-centryzm - nie
można doskonalić systemów zarządzania firmą
przy założeniu ,że

człowiek jest dodatkiem

Komputer nie zastępuje ludzi, ale wspomaga
twórcze myślenie z czego mogą się zrodzić
nowe koncepcje, nowe idee. I dopiero to
wszystko razem może zapewnić sukces
biznesowy. Przykładem tego kierunku jest
podejście społeczne (ang. soft approaches)

METODA,

METODOLOGIA,

METODYKA

MODELOWANIE

Metodyka wg Wikipedii…



Metodyka to ustandaryzowane dla
wybranego obszaru podejście do
rozwiązywania problemów.



Metodyka abstrahuje od
merytorycznego kontekstu danego
obszaru, a skupia się na metodach
realizacji zadań, szczególnie metodach
zarządzania.

Metodyka skupia się na metodach

Metody (w tym metody

rozwiązywania zadań) są
przedmiotem badań a w wyniku
tych badań powstają uogólnienia i
w ten sposób powstaje nowa
dziedzina wiedzy, której
przedmiotem są owe metody.

Metody

> badanie metod

>wiedza

>nauka

Metodologia



Nauka

o metodach badań naukowych, ich

skuteczności i wartości poznawczej to
metodologia.

Klasycznie wyróżnia się metodologie w:



naukach ścisłych



naukach przyrodniczych



naukach społecznych

Metody

> badanie metod

> metodologia

Metodyka a metodologia



metodologia

skupia się na odpowiedzi na

pytanie:

Co należy robić?,



metodyka

koncentruje się na

poszukiwaniu odpowiedzi na pytanie:

Jak to należy robić?



Metodyka

dąży ku

praktyce

wykonawczej, a

metodologia

teorii

zazwyczaj sprawnego działania.

Metodologia nauk technicznych (tworzenia
oprogramowania)



Wiele nauk posiada własne metodologie lub

korzysta z dorobku innych,



naukach technicznych

często dokonuje się

pomiaru za pomocą

mierników

z zachowaniem

właściwych warunków otoczenia a uzyskane

tak wyniki mogą być zbierane i porównywane

z wynikami uzyskanymi przez innych badaczy

przy zachowaniu tych samych

zmiennych

lub

nieznacznej ich modyfikacji.



Do opracowania stosuje się tu często opis

matematyczny.

Modelowanie

Modelowanie to złożony proces tworzenia

modelu (danych, funkcji, systemów, modułów,

podsystemów, przepływów, procesów, etc..)

Są różne metody, techniki, metodyki i

metodologie budowy modeli

Metody, techniki, metodyki i metodologie

ukierunkowane są na przedmiot (obiekt)

modelowania

MODELOWANIE

FUNKCJI

I DANYCH W SI

Modelowanie

funkcji

Modelowanie

funkcji

opisaniu

„

czym

zajmuje

czym

zajmuje

przedsi

biorstwo

”

Tworzenie modelu funkcji ma na celu opis potrzeb funkcjonalnych

przedsi

biorstwa jako podstawa modernizacji istniej

cych w

przedsi

biorstwie system

w lub tworzenia nowych.

Dzi

ki temu u

ytkownicy, analitycy i in

ynierowie systemowi mog

uzgodni

wymagania.



jakie dzia

ania wykonuje przedsi

biorstwo (

funkcje



co powoduje rozpocz

cie tych dzia

(

zdarzenie



na jakie znacz

ce rzeczy (

encje

) lub w

asno

ci tych

rzeczy (

atrybuty

) funkcje maj

yw.

Metody modelowania funkcji :

Modelowanie funkcji obejmuje okre

lenie:



hierarchia funkcji,



zale

ść

funkcji,



przep

yw danych,



czas rzeczywisty,



logika funkcji.

Modelowanie funkcji
realizowanych w firmie

Hierarchia funkcji

polega na opisie ka

dej funkcji za pomoc

prostego

wyra

enia, przy czym tworzone jest drzewo (jak drzewo genealogiczne),

rym funkcja

rodzic jest opisywana szczeg

owo przez funkcje

dzieci.

Przyk

ad:

„

naprawa pojazdu

”

Naprawa pojazdu

Lokalizacja pojazdu

Badanie pojazdu

Diagnozowanie usterki

Lokalizacja części

Rejestracja kosztów

Przygotowanie pojazdu do oddania

Naprawa pojazdu własnymi

zasobami

Zlecenie naprawy innej firmie

Modelowanie funkcji realizowanych w
firmie

Zale

ść

funkcji

y do obrazowania wzajemnych zale

ci mi

dzy

funkcjami i zdarzeniami powoduj

cymi wywo

anie ka

dej funkcji.

Przyk

ad:

„

naprawa pojazdu

”

Lokalizacja

pojazdu

Badanie

pojazdu

Diagnozowanie

usterki

Naprawa

pojazdu

własnymi

zasobami

Zlecenie
naprawy

innej firmie

Modelowanie funkcji realizowanych w
firmie

Modele

przep

ywu danych

żą

do obrazowania wzajemnych

zale

ci mi

dzy funkcjami (procesami) przez zdefiniowanie

rzeczywistego lub pozornego przep

ywu danych (informacji) mi

dzy

funkcjami.

Przyk

ad:

Encja

zewnętrzna

Magazyn

danych

Proces

Magazyn

danych

Magazyn

danych

Encja

zewnętrzna

strumień danych

strumień

danych

strumień

danych

strumień

danych

strumień

danych

strumień

danych

strumień

danych

Modelowanie funkcji cd…

Modelowanie

czasu rzeczywistego

umo

liwia dok

adne opisanie z

onych

wsp

zale

ci r

nych zdarze

i rzeczy w systemie i pokazuje (poprzez

diagram), jakie funkcje i procesy s

wykonywane w r

nych warunkach.

Metod

stosuje si

do przedstawiania dzia

zmieniaj

cych si

w spos

y na skutek wp

w zewn

trznych.

Diagram w takim modelu opiera si

o poj

cie

stanu

przej

cia

Przyk

ad:

„

łą

czanie i wy

łą

czanie (z zabezpieczeniem) zasilania telewizora

”

Zadziałanie głównego przełącznika

Rozgrzewanie

Zadziałanie głównego przełącznika

Wygaszanie

Przywrócenie zasilania

Restart

Awaria zasilania

Nałożenie ochrony obwodów

Zadziałanie głównego przełącznika

Usunięcie ochrony obwodów

WYŁĄ-

CZONY

WŁĄ-

CZONY

OCHRONA

Wybrany kanał

Dostrojenie

Wybrany

kanał

Modelowanie funkcji realizowanych w
firmie

Logik

funkcji

stosuje si

do szczeg

owego opisu czynno

wykonywanych przez funkcje. Okre

la ona krok po kroku stan procesu

i mo

e by

konstruowana poprzez specyfikacj

wymaganych

rezultat

w i warunk

w ich osi

gania.

co robi? co powinno robi

Wymagania dla

przedsi

biorstwa

jak wymagania

przedsi

biorstwa

mog

wspierane?

jak zrealizowa

system?

Metody

modelowania

Poziom

przedsi

biorstwa

Poziom

systemu

Poziom

programu

Hierarchia funkcji

Zale

ść

funkcji

Przep

yw danych

Czas rzeczywisty

Logika funkcji

Dzia

a jako zakres dla

wszystkich funkcji

Funkcje wsp

zale

Orientacja

przep

ywowa

Sterowanie zdarzeniami

Szczeg

y dla ka

dej z

powy

szych metod

podstawowa

podstawowa podstawowa

podstawowa

opcjonalna

Modelowanie funkcji cd…

Dziedzina

przedmiotowa (DP)

PROCES TWORZENIA

SYSTEMU

INFORMATYCZNEGO

Zespół

projektujący

System

informatyczny

Wyniki analiz

Cele problemy, potrzeby

informatyczne

Kryteria

oceny

Korekty i modyfikacje

Prezentacja i eksperymentalna

eksploatacja

tworzenie

kierowanie

Modele

Metody i

techniki

Narzędzia

komputeroweg

o wspomagania

Reguły

modelowania

parametry

pakiety

Zadania

wymagania

Fazy

dokumentacja

Pojęcia

abstrakcyjne

Elementy procesu tworzenia SI

Model tworzenia systemu
informacyjnego

Realizacja systemu

Elementy procesu tworzenia SI

Analiza

↓

Projektowanie

↓

Realizacja SI

Proces projektowania

Problem analizy i projektowania

opanowanie nadmiernej złożoności

Zespół ludzi

podlegający

ograniczeniom pamięci,
percepcji, psychologii,
wyrażania informacji i
wzajemnej komunikacji.

Zespół ludzi

podlegający

ograniczeniom pamięci,
percepcji, psychologii,
wyrażania informacji i
wzajemnej komunikacji.

Dziedzina problemowa,

najczęściej obejmująca
ogromną liczbę wzajemnie
uzależnionych aspektów,
procesów i problemów.

Dziedzina problemowa

najczęściej obejmująca
ogromną liczbę wzajemnie
uzależnionych aspektów,
procesów i problemów.

Środki informatyczne:

sprzęt, oprogramowanie, sieć,
języki, narzędzia, technologie.

Środki informatyczne

sprzęt, oprogramowanie, sieć,
języki, narzędzia, technologie.

Analiza,

projektowanie,

konstrukcja,

dokumentacja,

wdrożenie,

eksploatacja

Obiektowość:
nowa jakość
w opanowaniu
złożoności

Proces analizy i projektowania

Użytkownicy

Projektanci

Kierownictwo

Generowanie

wymagań

Generowanie

wymagań

Sformułowanie

problemu

Budowa
modeli

Wywiady z
użytkownikami

Wiedza dotycząca
dziedziny problemowej

Doświadczenie w
zakresie projektów

Modele: analityczny (logiczny),

funkcjonalny, dynamiczny
statyczny, danych, procesów…

Analiza

Projektowanie

Rodzaje modeli SI



Model funkcjonalny SI, służy do opisu funkcji

realizowanych przez system



Model

statyczny,

który

służy

opisu

statycznej struktury systemu w kategoriach klas

obiektów systemowych i ich związków (np..

Model analityczny - opisowy)



Modele dynamiczne, które służą

do opisu

dynamicznej struktury systemu. Widać z nich

interakcje między obiektami systemowymi.



Model analityczny

Rodzaje modeli SI - Model analityczny
(logiczny)

Ujęcie w modelu pewnych elementów dziedziny problemu nie będących
częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w
modelu systemów zewnętrznych, z którymi system ma współpracować.

Na etapie modelowania może nie być jasne, które elementy modelu będą
realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.

Dostępne środki mogą nie pozwolić na
realizację systemu w całości.
Celem analizy może być wykrycie tych
fragmentów dziedziny problemu, których
wspomaganie za pomocą
oprogramowania będzie szczególnie

przydatne.

Model analityczny wykracza
poza zakres odpowiedzialności
systemu

Zakres

odpowiedzialności

systemu

Model analityczny

Dziedzina problemu

Rodzaje modeli SI



Model funkcjonalny SI, służy do opisu funkcji

realizowanych przez system



Model

statyczny,

który

służy

opisu

statycznej struktury systemu w kategoriach klas

obiektów systemowych i ich związków (np..

Model analityczny - opisowy)



Modele dynamiczne, które służą

do opisu

dynamicznej struktury systemu. Widać z nich

interakcje między obiektami systemowymi.



Model analityczny

Cechy modelu analitycznego
(logicznego)

Uproszczony opis systemu;

Hierarchiczna dekompozycja funkcji systemu;

Model logiczny jest opisany przy pomocy notacji zgodnej z pewną konwencją;

Jest on zbudowany przy użyciu dobrze rozpoznanych metod i narzędzi;

Jest on używany do wnioskowania o przyszłym oprogramowaniu;

Model oprogramowania powinien być jego uproszonym opisem, opisującym
wszystkie istotne cechy oprogramowania na wysokim poziomie abstrakcji.

Model ten jednakże nie zastępuje doświadczenia i wnikliwości projektantów,
lecz pomaga projektantom w zastosowaniu tych walorów.

Logiczny model oprogramowania:

• pokazuje co system musi robić;
• jest zorganizowany hierarchicznie, wg poziomów abstrakcji
• unika terminologii implementacyjnej
• pozwala na wnioskowanie „od przyczyny do skutku” i odwrotnie.

Model dynamiczny

Opisuje te aspekty analizowanego systemu, które są związane z czasem i
kolejnością wykonywania operacji.

•

zdarzenia

, które wyznaczają zmiany

•

sekwencje zdarzeń

•

stany

, które definiują kontekst zdarzeń

•

organizację

zdarzeń i stanów

Model dynamiczny obejmuje

sterowanie

, tj. taki aspekt systemu, który

odzwierciedla następstwo operacji, bez wnikania co te operacje robią,
na czym one działają, i jak są zaimplementowane.

Model dynamiczny obejmuje

sterowanie

, tj. taki aspekt systemu, który

odzwierciedla następstwo operacji, bez wnikania co te operacje robią,
na czym one działają, i jak są zaimplementowane.

Model dynamiczny jest reprezentowany graficznie w postaci

diagramów stanów

Każdy diagram stanów opisuje kolejności stanów i zdarzeń dozwolonych w systemie
dla jednej klasy obiektów.

Model dynamiczny jest reprezentowany graficznie w postaci

diagramów stanów

Każdy diagram stanów opisuje kolejności stanów i zdarzeń dozwolonych w systemie
dla jednej klasy obiektów.

Model funkcjonalny

Dotyczy tych aspektów systemu, które zajmują się transformacją wartości -
tj. funkcjami, odwzorowaniami, ograniczeniami, zależnościami funkcyjnymi.

Model funkcjonalny przykrywa to,

system robi, bez wnikania

jak i kiedy

to robi.

Model funkcjonaly pokazuje statyczną zależność pomiędzy czynnościami
wykonywanymi przez system, bez określania następstwa czasowego tych czynności.

Model funkcjonalny jest reprezentowany przez

diagram przepływu danych

Pokazuje on zależności pomiędzy wartościami i obliczeniami wartości wyjściowych
z wartości i funkcji wejściowych, bez rozpatrywania kiedy i czy funkcje są wykonywane.

Model funkcjonalny jest reprezentowany przez

diagram przepływu danych

Pokazuje on zależności pomiędzy wartościami i obliczeniami wartości wyjściowych
z wartości i funkcji wejściowych, bez rozpatrywania kiedy i czy funkcje są wykonywane.

Niektórzy metodolodzy (Yourdon) uważają tę cechę OMT za niekonsekwentną.

Model a analiza SI



Aby powstał model SI (niezależnie
od formy tego modelu) niezbędna
jest analiza SI

Czynności w fazie analizy

Rozpoznanie,

wyjaśnianie,

modelowanie,

specyfikowanie

dokumentowanie rzeczywistości lub problemu będącego przedmiotem
projektu;

Ustalenie kontekstu projektu;

Ustalenie wymagań użytkowników;

Ustalenie wymagań organizacyjnych

Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w
zakresie

oprogramowania,

ograniczeń

finansowych,

ograniczeń

czasowych, itd.

W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez
wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej
celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby
mieć wpływ na postać, organizację lub wynik projektu.

Analiza

Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie
rzeczywistości lub problemu będącego przedmiotem projektu;

Ustalenie kontekstu projektu;

Ustalenie wymagań użytkowników;

Ustalenie wymagań organizacyjnych

Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie
oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd.

Włącza następujące czynności:

Analiza nie zajmuje się zmianą tej rzeczywistości poprzez wprowadzenie tam
nowych elementów np. w postaci systemu informatycznego; jej celem jest
dokładne rozpoznanie wszystkich tych aspektów danej rzeczywistości, które
mogłyby mieć wpływ na postać, organizację lub wynik projektu. Analiza nie
powinna odwoływać się do jakichkolwiek aspektów implementacyjnych.

Analiza nie zajmuje się zmianą tej rzeczywistości poprzez wprowadzenie tam
nowych elementów np. w postaci systemu informatycznego; jej

celem jest

dokładne rozpoznanie wszystkich tych aspektów danej rzeczywistości

, które

mogłyby mieć wpływ na postać, organizację lub wynik projektu. Analiza nie
powinna odwoływać się do jakichkolwiek aspektów implementacyjnych.

Podstawowe rezultaty fazy analizy

Poprawiony dokument opisujący wymagania

Słownik danych zawierający specyfikację modelu

Dokument opisujący stworzony model, zawierający:
•

diagram klas

• diagram przypadków użycia
• diagramy sekwencji komunikatów (dla wybranych sytuacji)
• diagramy stanów (dla wybranych sytuacji)
• raport zawierający definicje i opisy klas, atrybutów, związków,

metod, itd.

Harmonogram fazy projektowania

Wstępne przypisanie ludzi i zespołów do zadań

Złożoność problemów analizy i
projektowania

Podstawowy problem konstrukcji oprogramowania

to jego złożoność.

W przypadku gdy metody paradygmatu obiektowego nie wystarcza
do rozwiązania określonych problemów, zaleca się czasami
kombinację różnych rozwiązań. Takie podejście zwane jest

wytwarzaniem oprogramowania z wieloma paradygmatami

(ang. multiparadigm programing-project-analysis).

„…Problem , który można podzielić na dwa podproblemy, dające się
obsługiwać osobno, jest rozwiązany dzięki temu podziałowi więcej niż
w połowie…”

Bjarne Stroustrup

Prosta klasyfikacja nie jest łatwa

, gdyż:

• zagadnienia

związane

tworzeniem

są

nieustrukturyzowane

co oznacza, że nie istnieją oczywiste i

jednoznaczne definicje problemów ani sposobów ich
rozwiązywania,

• dziedziny

przedmiotowe

są

bardzo

specyficzne

(dynamicznie zmieniająca się

sytuacja w obszarze

zastosowania procesu informatyzacji),

• dynamika zmian

w sferze inżynierii oprogramowania,

• brak

teoretycznych

podstaw

wyrażania

potrzeb

informatycznych.

Klasyfikacja metodyk tworzenia SI

Najczęściej proponuje się klasyfikację wg następujących
kryteriów



ze względu na

podejście do procesu tworzenia

SI,



ze względu na

definiowanie danych

bądź

procesów

w projekcie,



ze względu na

relacje między dziedziną

przedmiotową a SI,



ze względu na

kierunek tworzenia

SI.

Klasyfikacja metodyk tworzenia SI

względu

podejście do procesu tworzenia

systemów informatycznych

można wyodrębnić metodyki:



techniczne

- analityk ma neutralny wpływ na organizację w

procesie tworzenia SI, gdyż występują sformalizowane modele

dziedziny przedmiotowej i ściśle określone sposoby rozwiązań,



społeczne

- rola analityka jest aktywna i od uwarunkowań

organizacyjno-kadrowych zależy sukces projektu; akcentowane są

przede wszystkim organizacyjne, psychologiczne i socjologiczne

problemy występujące w procesie tworzenia SI.

Klasyfikacja metodyk tworzenia SI

Ze względu na

definiowanie danych bądź procesów

w projekcie

można wyodrębnić metodyki:



zorientowane na dane

- koncentrują analizę i

projektowanie systemów wokół strukturyzacji danych

użytkowych w organizacji,



zorientowane na procesy

- dane elementarne

specyfikuje się w oparciu o analizę procesów w

organizacji (dziedzinie przedmiotowej) oraz potrzeb

użytkowników.

Klasyfikacja metodyk tworzenia SI

względu

zależność

między

dziedziną

przedmiotową a systemem informatycznym

można

wyodrębnić metodyki:



organizacyjnego odwzorowania

(pasywna) –

ponieważ decyzje i działania są podejmowane w
dziedzinie przedmiotowej to SI musi ściśle
odwzorowywać rzeczywistość; nie ma miejsca na
innowacyjne rozwiązania,



organizacyjnego sterowania

(aktywna) –

nacisk kładzie się na określenie potrzeb
informacyjnych, a nie na odzwierciedlenie
rzeczywistości, gdyż wyodrębnia się w dziedzinie
przedmiotowej system sterowania, w którym

podejmowane są decyzje wpływające na dziedzinę.

Klasyfikacja metodyk tworzenia SI

Ze względu na

kierunek tworzenia SI

można

wyodrębnić metodyki:



zstępujące (top-down)

- tworzenie systemu przez

stopniowe, hierarchiczne wyodrębnianie jego

składników, aż do podstawowego poziomu

szczegółowości (od ogółu do szczegółu),



wstępujące (bootom-up)

- polega na stopniowym

budowaniu syntezy systemu poprzez integrację jego

elementów, począwszy od poziomu podstawowego (od

szczegółu do ogółu).

Klasyfikacja metodyk tworzenia SI

Aktualnie dominuje klasyfikacja wynikająca z

połączenia

opisu dziedziny przedmiotowej i doświadczeń praktycznych

Wyróżnić można więc

trzy podejścia metodologiczne



strukturalne

(strukturalno-relacyjne) - polegające

tworzeniu

uporządkowanego

systemu

hierarchicznej

strukturze,

którego

składniki

stanowią moduły funkcji i danych oraz związki
między nimi; cechą charakterystyczną jest oddzielne
modelowanie danych i procesów, wykorzystujące
metody i techniki diagramowe i macierzowe,



obiektowe

- opiera się na wyodrębnieniu obiektu

(bytu, pojęcia, rzeczy) mającego odpowiednie
znaczenie w kontekście problemów danej dziedziny
przedmiotowej;

cechą

charakterystyczną

jest

możliwość

integralnego modelowania danych i

procesów,



społeczne

- akcentuje aspekty ludzkie i społeczne

(psychologiczne i socjologiczne) w tworzeniu SI.

dotyczą
całego cyklu
życia
systemu

dotyczy
głównie fazy
planowania

Klasyfikacja metodyk tworzenia SI

W praktyce każda metodyka jest odpowiednia dla różnych
faz cyklu życia systemu. Stąd na bazie wiedzy o metodykach
zespół projektowy może zaproponować własną metodykę. W
ten sposób powstaję

metodyki elastyczne

(kombinowane).

ELASTYCZNE

METODYKI

tworzenia SI

Cykl życia systemu

, n

zę

uły

acj

i kat

i i

ów

Klasyfikacja metodyk tworzenia SI

METODYKI

STRUKTURALNE

Metodyki strukturalne

Metodyki strukturalne - łączą statyczny opis danych oraz
statyczny opis procesów.

Do tej klasy należą:

• Metodyka

Yourdona

(DeMarco i Ward/Mellor);

• Structured System Analysis and Design
Methodology (

SSADM

);

• Structured Analysis and Design Technique
(

SADT

Metodyki strukturalne

Zgodnie z DeMarco, analiza strukturalna używa
następujących technik.

•

Diagramy Przepływu Danych

(Data Flow

Diagrams, DFD)

•

Słownik Danych

(Data Dictionary)

• Strukturalny Angielski (Structured English) ->

strukturalny polski

•

Tablice Decyzyjne

(Decision Tables)

•

Drzewa Decyzyjne

(Decision Trees)

Metodyki strukturalne

Uważa się, że wadą metodyk strukturalnych

są trudności w zintegrowaniu modeli.

Dodatkowo:

• Schemat Transformacyjny (Transformation
Schema)
• Diagram Przejść Stanów (State Transition Diagram
–

STD

)

• Lista Zdarzeń (Event List)
• Schemat Danych (Data Schema)
• Pre- i post- warunki (Pre- and Post-Conditions)
• Diagramy Encja-Związek (występują w SSADM)

odpowiednik diagramów

ERD

• Historie Życia Encji (występują w SSADM)

Metodyki strukturalne w
praktyce

DIAGRAMY ZWIĄZKU ENCJI - ERD
DIAGRAMY PRZEPŁYWU DANYCH – DFD
DIAGRAMY STANÓW- STD

Diagramy przepływu danych

(ang. DATA FLOW DIAGRAMS – DFD)

Pokazują przepływ danych między światem zewnętrznym a
modelowanym systemem, oraz przepływ danych między procesami w
systemie. Diagramy te są na tyle proste, że mogą być zrozumiałe dla osób
bez wykształcenia informatycznego. Modelowanie przepływu danych
pomaga odpowiedzieć na pytania:

•

Jakie funkcje powinien realizować system?

•

Jakie są zależności między nimi?

•

Jakich transformacji powinien dokonywać system?

•

Jakie dane są przekształcane na jakie wyniki?

•

Jakiego rodzaju pracę wykonuje system?

•

Skąd bierze informację potrzebną do pracy?

•

Gdzie dostarcza otrzymane wyniki?

SYMBOLE DIAGRAMÓW DFD.

•Obiekty zewnętrzne (terminatory, encje
zewn., external entities) - źródła lub miejsca
przeznaczenia informacji, zewnętrzne w
stosunku do systemu; reprezentują
zewnętrzne w stosunku do analizowanego
systemu źródła powstania i miejsca
przeznaczenia informacji (te, które
dostarczają i odbierają dane); KLIENT,
DOSTAWCA, BANK i inne – prostokąty.

Obiekt zewnętrzny
(external entity)

SYMBOLE DIAGRAMÓW DFD.

Proces

Procesy (funkcje, proceses) - czyli
transformacje danych; definiują sposób
wykonywania jednej lub więcej funkcji
(program, procedura, algorytm, operacja
ręczna czy zautomatyzowana (całkowicie
lub częściowo) - wszystkie czynności
wykonywane na danych) - okręgi, owale.

SYMBOLE DIAGRAMÓW DFD.

Zbiór danych
(data store)

Zbiory danych (magazyny, składnice,
data stores) - miejsca, gdzie dane są
przechowywane między procesami, które
na nich operują; reprezentują miejsca
przechowywania danych między
procesami (dostępne są tylko z
procesów). Zaistnienie składnicy w DFD
ma sens wtedy, kiedy przechowywane
tam dane służą realizacji co najmniej
dwóch procesów; wszelkiego rodzaju
KARTOTEKI - dwie poziomy linie.

SYMBOLE DIAGRAMÓW DFD.

Przepływ danych
(data flow)

Przepływy danych (strumienie, data
flows) - przedstawiają obieg danych w
systemie; powiązania pomiędzy procesami
a innymi elementami DFD - strzałki
skierowane (opisane!).

SYMBOLE DIAGRAMÓW DFD.

•

Kontekstowe,

•

Zerowe (systemowe),

•

Szczegółowe (procesów elementarnych).

1. Diagramy kontekstowe

Najmniejszy stopień szczegółowości - pokazuje powiązania

systemu z otoczeniem tj.:

•

zakres i granice systemu;

•

źródła i odbiorcy informacji;

•

główne wejścia i wyjścia systemu (tzn. informacje płynące
między światem zewn. a systemem).

Podział diagramów DFD ze względu
na stopień szczegółowości:

2. Diagramy zerowe (systemowe)

Przedstawiają ogólną strukturę systemu, obrazują:

•

główne procesy systemu,

•

obiekty zewnętrzne,

•

magazyny danych,

•

przepływy.

Podział diagramów DFD ze względu
na stopień szczegółowości:

3. Diagramy szczegółowe

Dokładny obraz procesów i podsystemów - dalsze
uszczegółowienie.
W trakcie dekompozycji diagramów obowiązuje zasada, iż tylko
przepływy danych, które pojawiły się na poziomie zerowym mogą
wystąpić na niższych poziomach hierarchii.

Podział diagramów DFD ze względu
na stopień szczegółowości:

Przeznaczenie diagramów:

• Diagramy kontekstowe i systemowe - dla projektantów, programistów i

użytkowników systemu.

• Diagramy szczegółowe - dla projektantów i programistów.

Przeznaczenie diagramów DFD

• Uporządkowanie diagramów w hierarchię: kontekstowe, zerowe,

szczegółowe,

• Uchwycenie głównych procesów i uszczegółowienie jest bardziej

odpowiednie niż uogólnianie procesów elementarnych,

• Przypisanie jednoznacznych nazw dla procesów, obiektów i

magazynów,

• Przestrzeganie, żeby żadne dane niewykorzystywane przez proces

nie wpływały do niego,

• Przestrzeganie, aby każdy proces miał wejście i wyjście,

• Zapewnienie, aby każdy przepływ miał początek i kończył się na

procesie,

Zasady tworzenia diagramów DFD:

• Przestrzeganie, aby wszystkie dane wprowadzane lub

wyprowadzane z obiektów zewnętrznych podlegały

przetwarzaniu w procesach i nie dopuszczać przepływów

między składnicami a obiektami zewnętrznymi,

• Konsekwentne używanie symboli,

• Oznaczenie w odpowiedni sposób powtarzających się elementów,

• Unikanie nadmiernie złożonych DFD (max 9 procesów na

jednym DFD),

• Weryfikowanie diagramów,

• Opisanie każdego elementu w słowniku danych

(data dictionary).

Zasady tworzenia diagramów DFD:

PRZYKŁAD DIAGRAMU DFD,
ZAWIERAJĄCEGO NAZWY SYMBOLI

Klient

Sprawdź listę

wyrobów i

potwierdź

zamówienie

Lista wyrobów

Potwierdzenie

zamówienia wyrobu

Zamówienie wyrobu

PROCES

OBIEKT
ZEWNĘTRZNY

ZBIÓR

DANYCH

PRZEPŁYW

DANYCH

ETYKIETOWANY

PRZEPŁYW DANYCH

Przykładowy diagram DFD.

LISTA REZERWACJI

Przykład Schematu Przepływu
Danych

Diagram nie odwzorowuje zależności czasowych

Semantyka jest wyrażana poprzez NAZWY OBIEKTÓW (Encji)

REZERWACJA

MIEJSC

W SAMOLOCIE

PASAŻER

Bilet z

rezerwacją

miejsca

Żądanie

rezerwacji

miejsca

Bilet do

odprawy

Karta

pokładowa

Sprawdzenie
rezerwacji

Zarezerwowane
miejsce

ODPRAWA

PASAŻERÓW

Zrealizowana

odprawa

Przykładowy diagram kontekstowy dla
systemu obsługującego hurtownię.

- oferta dostawcy;

- faktura za dostarczony
towar;

- zamówienie na towar
wysłane do dostawcy;

- dane dostawcy;

- oferta dla odbiorcy;

- faktura za zakupiony towar;

- dane odbiorcy;

- zamówienie na towar;

- informacja o płatnościach;

10.

- stawki VAT;

11.

- rejestr wystawionych faktur;

12.

- rejestr otrzymanych faktur;

13.

- wytyczne i zarządzenia;

14. - analizy i zestawienia.

Diagram DFD - 1 dla systemu obsługi hurtowni.

- oferta dostawcy;

- faktura za dostarczony towar;

- zamówienie na towar wysłane do dostawcy;

- dane dostawcy;

- oferta dla odbiorcy;

- faktura za zakupiony towar;

- dane odbiorcy;

- zamówienie na towar;

- informacja o płatnościach;

10.

- stawki VAT;

11.

- rejestr wystawionych faktur;

12.

- rejestr otrzymanych faktur;

13.

- wytyczne i zarządzenia;

14.

- analizy i zestawienia statystyczne.

15.

- zapis danych o towarach z oferty,

16.

- dane o towarach do dokumentów;

17.

- dane o towarach do faktur;

18.

- zapis danych o odbiorcy;

19.

- zapis danych o dostawcy;

20.

- dane o firmach do zestawień,

21.

- zapis faktury otrzymanej,

22.

- dane o fakturach do rejestru,

23.

- zapis faktury wytworzonej.

METODYKI

OBIEKTOWE

Metodyki obiektowe

Zakładają, że:

•

procesy informacyjne i struktura w której te procesy
zachodzą stanowią pewną całość,

•

w systemie wyodrębnia się łącznie dane i metod w

kategoriach tzw. klas,

•

Do tych klas trzeba budować odpowiednie metody danych,

odpowiednie struktury danych, które odpowiadają za
gromadzenie i przetwarzanie informacji a także projektować

specjalne mechanizmy komunikacji między obiektami,

•

system zbudowany w oparciu o metodologie obiektowa

pozostaje systemem - "obiektem spójnym", mimo że każdy z

obiektów ma daleko posunięta autonomie i może być
budowany przez odrębne zespoły programistów,

•

Ta metodologia pozwala budować duże i złożone systemy

informacyjne w zespołach wieloosobowych (praca grupowa).

Jednak systemy obiektowe są o wiele trudniejsze i bardziej

złożone od systemów strukturalnych.

(podstawa = Paradygmat obiektowy)

Metodyki obiektowe

Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania
pojęciowego oraz analizy i projektowania systemów informatycznych.

Podstawowym składnikiem jest diagram klas, będący zwykle wariantem
notacyjnym i pewnym rozszerzeniem diagramów encja-związek.

Diagram klas zawiera: klasy, w ramach klas specyfikacje atrybutów i metod,
związki generalizacji, związki asocjacji i agregacji, liczności tych związków,
różnorodne ograniczenia oraz inne oznaczenia.

Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające
stany i przejścia pomiędzy tymi stanami, diagramy interakcji ustalające
zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące
zwykle pewną mutacją diagramów przepływu danych), itd.

Koncepcja przypadków użycia (use cases) zakłada odwzorowanie struktury
systemu z punktu widzenia jego użytkownika.

Przykłady: Express, OODA(Booch), OMT(Rumbaugh), OOSA(Shlaer-Mellor),
Objectory(Jacobson), MOSES/OPEN, OOA/OOD(Coad/Yourdon), Notacja UML,
RUP.

Metodyka obiektowa

Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego
oraz analizy i projektowania systemów informatycznych.

Podstawowym składnikiem tych metodyk jest diagram obiektów, będący zwykle
wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek.

Diagram obiektów zawiera takie elementy jak: klasy, w ramach klas specyfikacje
atrybutów i metod, strukturę dziedziczenia pomiędzy klasami, związki asocjacji i
agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia.

Uzupełnieniem tego diagramu są inne, np. diagramy dynamiczne uwzględniające
stany poszczególnych procesów przetwarzania i przejścia pomiędzy tymi stanami,
diagramy zależności pomiędzy wywołaniami metod, np. diagram tropów komunikatów,
diagramy fukcjonalne (będące zwykle pewną mutacją diagramów przepływu danych).

Ostatnio popularność zdobyła także koncepcja przypadków użycia (use cases), której
podstawowym celem i walorem jest odwzorowanie struktury systemu z punktu
widzenia jego użytkownika.

Techniki obiektowe

1. Ukrywanie implementacji (enkapsulacja)

określone jednoznacznie i niezmiennie interfejsy

stosowanie instrukcji np.: „typedef” ukrywającej wykorzystywane
typy i wyrażenia

podział programu na mniejsze części (dynamicznie i statycznie
łączone biblioteki)

Techniki obiektowe

2. Wielokrotne wykorzystanie implementacji

podział programu na klasy

zamykanie kodu metod w obiekty o podobnej funkcjonalności

stosowanie wzorców projektowych np.: obiekt factory

wykorzystywanie klas i metod szablonowych

Techniki obiektowe

3. Dziedziczenie

zmniejszanie odpowiedzialności klas (obiektów)

określanie relacji „bycia czymś” i „bycia podobnym do czegoś”

zapewnienie mechanizmu wymienialności obiektów

wykorzystanie mechanizmów polimorfizmu

rozszerzanie odpowiedzialności (specjalizacja)

Techniki obiektowe

4. Kompozycja (agregacja)

określenie relacji zawierania w się w czymś (bycie częścią)

określenie relacji zawierania w sobie (bycie całością)

kontrola nad innymi obiektami

rola providera – usługodawcy

realizacja wzorców typu Adapter, Proxy

Podstawowe cechy języka
obiektowego

Pięć podstawowych cech języka obiektowego według Alana Kay:

1. Wszystko jest obiektem,

2. Program jest zbiorem obiektów, które przez wysyłanie

komunikatów mówią sobie nawzajem co robić,

3. Każdy obiekt posiada swą własną pamięć, na które składają się

inne obiekty,

4. Każdy obiekt posiada swój typ,

5. Wszystkie obiekty danego typu mogą otrzymywać te same

komunikaty,

Analiza obiektowa

1. Plan prac

„przystąpienie od razu do kodowania” -

jest możliwe tylko

w przypadku drobnych aplikacji i w sytuacjach gdy posiada się już
jakieś doświadczenie. Znane muszą być technologie i ich sposób
zastosowania.

„tworzenie czegoś z góry przeznaczonego do wyrzucenia”

metoda najlepsza w przypadku braku doświadczenia,
nieznajomości środowiska i możliwości bibliotek.

wyznaczanie tzw. kroków milowych

(ang. milestones) –

weryfikacja postępów prac, podział złożonego problemu na części

Analiza obiektowa

2. Definicje pojęć w projekcie - określenie co tworzymy?

analiza wymagań i specyfikacji systemu

– jako odpowiednik

z metod proceduralnych

„Kto będzie używał systemu?”

„Jaka jest funkcjonalność systemu?

„Jak inaczej mogłaby działać dana operacja?”

„Jakie mogą wystąpić wyjątki (problemy)?”

Projektowanie obiektowe

Etapy projektowania obiektowego:

•

Znajdowanie obiektów

Identyfikacja klas i obiektów

•

Składanie obiektów

Określanie agregacji i kompozycji

•

Konstrukcja systemu

Komunikacja, asocjacje pomiędzy obiektami

•

Rozbudowa systemu

Weryfikacja istniejącej struktury, dodanie nowych pomocnych
klas i obiektów

•

Wielokrotne wykorzystanie obiektów

UML - przykład notacji

UML (Unified Modeling Language)

powstał jako synteza trzech

metodyk/notacji:

OMT (Rumbaugh):

metodyka ta była dobra do modelowania dziedziny

przedmiotowej. Nie przykrywała jednak dostatecznie dokładnie zarówno aspektu
użytkowników systemu jak i aspektu implementacji/konstrukcji.

OOSE (Jacobson):

metodyka ta dobrze podchodziła do kwestii modelowania

użytkowników i cyklu życiowego systemu. Nie przykrywała jednak dokładnie
modelowania dziedziny przedmiotowej jak i aspektu implementacji/konstrukcji.

OOAD (Booch):

metodyka dobrze podchodziła do kwestii projektowania,

konstrukcji i związków ze środowiskiem implementacji. Nie przykrywała jednak
dostatecznie dobrze fazy analizy i rozpoznania wymagań użytkowników.

Istniało wiele aspektów systemów, które nie były właściwie przykryte przez żadne z
wyżej wymienionych podejść, np. włączenie prototypowania w cykl życiowy,
rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów, i inne.
Celem UML jest przykrycie również tych aspektów.

Diagramy definiowane w UML

Diagramy przypadków użycia (use
case)
Diagramy klas,

w tym diagramy pakietów

Diagramy zachowania się (behavior)

Diagramy implementacyjne

• Diagramy stanów
• Diagramy aktywności
• Diagramy sekwencji
• Diagramy współpracy (collaboration)

• Diagramy komponentów
• Diagramy wdrożeniowe (deployment)

Autorzy UML wychodzą z założenia, że żadna pojedyncza
perspektywa spojrzenia na projektowany system nie jest
wystarczająca. Stąd wiele środków:

Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju.

Analiza i projektowanie obiektowe

Kombinacja technik, notacji i wzorców postępowania posiadająca następujące
cechy:

Wyróżnianie w rzeczywistości będącej przedmiotem systemu informatycznego
bytów o określonych granicach, zwanych “obiektami”

Grupowanie obiektów w klasy

Ustalenie zależności pomiędzy klasami w postaci hierarchii dziedziczenia

Przypisanie do klas atrybutów obiektów i powiązań asocjacyjnych obiektów

Przypisanie do klas metod, tj. operacji, funkcji lub procedur działąjących na
obiektach tych klas

Techniki:

Modelowanie obiektów i klas, modelowanie zachowania,
modelowanie dynamiczne, modelowanie przepływu danych, ...

Notacje:

Konkretna składnia i semantyka służąca do zapisu modelu:
diagramy obiektów i klas, diagramy dynamiczne, diagramy
przepływu danych

Tematyka analizy i projektowania
obiektowego

• Analiza i modelowanie struktur obiektów
• Analiza i modelowanie procesów i sekwencji transakcji
• Analiza i modelowanie interakcji pomiędzy obiektami
• Analiza i modelowanie cyklu życiowego obiektów
• Kompleksowe modelowanie systemów
• Planowanie projektu
• Zarządzanie projektami dotyczącymi obiektowości
• Analiza wymagań dotyczących systemu
• Projektowanie logiczne
• Projektowanie fizyczne
• Rozwijanie obiektowych aplikacji
• Testowanie, akceptacja, wdrażanie, działanie

Tematy i techniki analizy obiektowej

Budowa statycznego modelu klas

Analiza funkcji i przypadków użycia

Weryfikacja klas i obiektów

Identyfikacja i definiowanie metod oraz komunikatów

Modelowanie stanów i przejść między stanami

Modelowanie procesów i przepływów danych

Modelowanie przepływu sterowania

Inne

Wiele tych technik było omówionych podczas prezentacji
metodyki opartej na UML.

Proces tworzenia modelu
obiektowego

Zadania:

Identyfikacja klas i obiektów

Identyfikacja związków pomiędzy klasami

Identyfikacja i definiowanie pól (atrybutów)

Identyfikacja i definiowanie metod i komunikatów

Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest
ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu.

Inny schemat realizacji procesu budowy modelu obiektowego polega na
rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie
następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji
systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model
przypadków użycia.

Identyfikacja klas i obiektów

Typowe klasy:

przedmioty namacalne (samochód, czujnik)

role pełnione przez osoby (pracownik, wykładowca, student)

zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie
zamówienia, dostawa),

interakcje pomiędzy osobami i/lub systemami o których system przechowuje
informacje (pożyczka, spotkanie, sesja),

lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów

grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części)

organizacje (firma, wydział, związek)

wydarzenia (posiedzenie sejmu, demonstracja uliczna)

koncepcje i pojęcia (zadanie, miara jakości)

dokumenty (faktura, prawo jazdy)

klasy będące interfejsami dla systemów zewnętrznych

klasy będące interfejsami dla urządzeń sprzętowych

Obiekty, zbiory obiektów i
metadane

W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego
rodzaju abstrakcją obiektu mamy do czynienia.

Np. klasa „samochód”. Może chodzić o:

• egzemplarz samochodu wyprodukowany przez pewną fabrykę
• model samochodu produkowany przez fabrykę
• pozycję w katalogu samochodów opisujący własności modelu
• historię stanów pewnego konkretnego samochodu

Podobnie z klasą „gazeta”. Może chodzić o:

• konkretny egzemplarz gazety kupiony przez czytelnika
• konkretne wydanie gazety (niezależne od ilości egzemplarzy)
• tytuł i wydawnictwo, niezależne od egzemplarzy i wydań
• partię egzemplarzy danej gazety dostarczaną codziennie do kiosku

Należy zwrócić uwagę na następujące aspekty:
• czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej?
• czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu?
• czy mamy do czynienia z opisem tego obiektu (dokument, metadane)?
• czy mamy do czynienia z pewnym zbiorem konkretnych obiektów?

Konstruowanie modelu obiektów

Konstruowanie modelu obiektów wymaga następujących kroków:

Identyfikacja obiektów i klas

Przygotowanie słownika danych

Zidentyfikowanie związków między obiektami

Zidentyfikowanie atrybutów obiektów

Zorganizowanie i uproszczenie klas obiektów z użyciem dziedziczenia

Analiza ścieżek dostępu dla prawdopodobnych zapytań

Iteracje i precyzowanie modelu

Grupowanie klas w moduły

Model obiektów

Model obiektów opisuje strukturę obiektów w systemie:

• tożsamość
• związki z innymi obiektami
• atrybuty
• operacje

Jest podstawą dla modeli dynamicznych i funkcjonalnych

Cel: wyłowienie tych pojęć z modelowanej rzeczywistości, które są istotne
dla danego zastosowania.

Graficzna reprezentacja modelu obiektów w postaci diagramów obiektowych
zawierających klasy obiektów.

Klasy są organizowane w hierarchie, i są połączone z innymi klasami związkami
asocjacyjnymi.

Budowa modelu obiektowego
przykład

W Systemie ROZGRYWEK LIGII PIŁKARSKIEJ zbierane są informacje o
drużynach występujących w lidze, rozgrywanych przez nie spotkaniach oraz
kibicach drużyn.

•W rozgrywkach Ligii Piłkarskiej uczestniczy wiele zespołów.

•Rozgrywają one między sobą mecze zgodnie z harmonogramem rozgrywek.

•Każdy mecz odbywa się w ustalonym dniu i godzinie oraz na wybranym stadionie.

•Każda drużyna prowadzona jest przez jednego szkoleniowca (trenera), który ustala
plan treningów zespołu.

•Treningi danej drużyny odbywają się na różnych stadionach, przy czym na tym
samym stadionie może trenować kilka drużyn.

•Prezes drużyny nadzoruje i koordynuje jej działalność oraz ma decydujący głos w
sprawie powoływania zawodników do zespołu.

•Po zakończeniu rozgrywek drużyny klasyfikowane są na podstawie sumy zdobytych
punktów oraz strzelonych i straconych bramek.

•Każda drużyna piłkarska posiada swoich fanów, którzy wspierają jej działalność oraz
kibicują jej w trakcie rozgrywanych meczy.

Przykładowy model obiektów

OSOBA

FAN

TRENER

ZAWODNIK

PREZES

wspomaga

prowadzi

gra dla

kieruje

DRUŻYNA

grają

przeciwko

sobie

MECZ

odbywa się

STADION

trenuje na

kibicuje

Rozgrywki
Ligii Piłkarskiej

Model dynamiczny

Opisuje te aspekty analizowanego systemu, które są związane z czasem i
kolejnością wykonywania operacji.

•

zdarzenia

, które wyznaczają zmiany

•

sekwencje zdarzeń

•

stany

, które definiują kontekst zdarzeń

•

organizację

zdarzeń i stanów

Model dynamiczny obejmuje

sterowanie

, tj. taki aspekt systemu, który

odzwierciedla następstwo operacji, bez wnikania co te operacje robią,
na czym one działają, i jak są zaimplementowane.

Model dynamiczny obejmuje

sterowanie

, tj. taki aspekt systemu, który

odzwierciedla następstwo operacji, bez wnikania co te operacje robią,
na czym one działają, i jak są zaimplementowane.

Model dynamiczny jest reprezentowany graficznie w postaci

diagramów stanów

Każdy diagram stanów opisuje kolejności stanów i zdarzeń dozwolonych w systemie
dla jednej klasy obiektów.

Model dynamiczny jest reprezentowany graficznie w postaci

diagramów stanów

Każdy diagram stanów opisuje kolejności stanów i zdarzeń dozwolonych w systemie
dla jednej klasy obiektów.

Zależności pomiędzy modelami

Każdy model opisuje specyficzny aspekt modelowanej rzeczywistości, ale
zawiera odniesienia do pozostałych modeli.

Model obiektów:
opisuje strukturę, na której działają model dynamiczny i model funkcjonalny.

Operacje w modelu obiektów odpowiadają zdarzeniom w modelu dynamicznym
lub funkcjom w modelu funkcjonalnym

Model obiektów:
opisuje strukturę, na której działają model dynamiczny i model funkcjonalny.

Operacje w modelu obiektów odpowiadają zdarzeniom w modelu dynamicznym
lub funkcjom w modelu funkcjonalnym

Model dynamiczny opisuje strukturę sterowania związaną z obiektami.

Model funkcjonalny opisuje
• funkcje wywoływane poprzez operacje w modelu obiektów,
• argumenty tych funkcji,
• akcje w modelu dynamicznym
• ograniczenia na wartości obiektów

Niejasności mogą być wyjaśniane w języku naturalnym lub poprzez specyficzną notację

Martin/Odell

BON (Business Object Notation), Nerson & Walden

OODA, Booch

Catalysis, D’Souza & Wills

EROOS (Entity-Relationship Object-Oriented Specification)

Fusion, HP Laboratories

MOSES (Methodology for Object-Oriented Software Engineering of System)

OORAM

OSA

OOSA, Shlaer-Mellor

Sintropy

OMT, Rumbaugh

UML (Unified Modelling Language), Booch, Jacobson, Rumbaugh

Objectory, Jacobson

OOA/OOD, Coad/Yourdon

DOOS, Wirfs-Brock

MainstreamObjects, Yourdon

Metodyki obiektowe

Express

Goldberg/Rubin

Jakie metodyki są używane?

Źródło: Gartner Group - 1995

OMT

32%

OOIE

17%

Fusion

Inne

17%

Booch

Shlaer-Mellor

13%

Coad/Yourdon

13%

Historia metod analizy i projektowania
obiektowego

Wprowadzenie do OMT



Co to jest OMT?



Trzy podstawowe modele OMT



Diagramy i techniki OMT



Obiekty, klasy



Atrybuty



Operacje, metody



Powiązania, asocjacje



Agregacje



Generalizacje, dziedziczenie

Co to jest OMT?

OMT = Object Modelling Technique, technika modelowania obiektów.

Książka:

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenson.
Object-Oriented Modelling and Design.
Englewood Cliffs, NJ, Prentice Hall 1991

Przyszłość:
Trzech czołowych obiektowych metodologów,
Grady Booch, Ivar Jacobson i James Rumbaugh,
połączyło swoje wysiki i metodyki w ramach firmy
Rational Software Corporation.
Rezutat (wrzesień 1996) określili jako

The Unified Modelling Language

Filozofia OMT

Główna różnica pomiędzy podejściem obiektowym w rozwoju oprogramowania, a
podejściem tradycyjnym:

Podejście obiektowe nie opiera się na funkcjonalnej dekompozycji procesów
zachodzących w świecie rzeczywistym, a na opisie obiektów rzeczywistych,
które grają określoną rolę w tym świecie.

Wg OMT obiektowość jest sposobem myślenia i organizacji oprogramowania
polegającym na wyodrębnianiu dyskretnych obiektów, które odwzorowują
zarówno statyczną strukturę świata i danych, jak i zachowanie (behaviour).

Charakterystyki obiektowości:

• tożsamość obiektów
• klasyfikacja (grupowanie obiektów w klasy)
• polimorfizm
• dziedziczenie

(te charakterystyki mogą być przedmiotem dyskusji)

Istotna jest identyfikacja i organizacja pojęć z dziedziny
aplikacyjnej, a nie pojęć z dziedziny implementacyjnej.

Wkład podejścia obiektowego

Większy nacisk na istotne własności obiektów zmusza analityka lub projektanta
do staranniejszego i głębszego myślenia o tym, czym jest obiekt i co on robi.

Główne zyski nie polegają na zredukowaniu czasu rozwoju, lecz na przyszłym
powtórnym użyciu klas i innych fragmentów projektu, zredukowaniu błędów
i pracochłonności utrzymania (maintenance).

Przesunięcie trudu rozwoju na fazę analizy

Wkład:

Większy nacisk na struktury danych,
a mniejszy na funkcje, co wspomaga stabilność

Bezszwowy proces rozwoju

Podejście iteracyjne raczej niż sekwencyjne.
Cechy projektu są dodawane i wyjaśniane w kolejnych iteracjach

OMT- 3 modele

Model obiektów

statyczna struktura obiektów i związków

przykrywa aspekt “danych”

Model dynamiczny

przykrywa zachowanie się obiektów w terminach “bodziec-odpowiedź”

przykrywa aspekt “sterowania”

Model funkcjonalny

przykrywa aspekt “funkcjonalny”

zależności funkcyjne pomiędzy wartościami

Projektowanie i implementacja polega na uszczegóławianiu i łączeniu tych modeli

Modelowanie dynamiczne w OMT

Zdarzenia i stany

Scenariusze

Trop zdarzeń

Diagramy stanów, operacje

Współbieżność

Diagramy i techniki OMT

Modeluje komunikację wewnątrz systemu
poprzez pokazanie interfejsów między obiektami.

Dekomponuje strukturę złożonych komunikatów.

Modeluje statyczną strukturę system poprzez sieć
klas i związków.

Modeluje strukturę sterowania systemu. Pokazuje
sekwencję działań między niektórymi stanami
systemu w terminach stanów i przejść.
Pokazuje sekwencję zdarzeń między różnymi
obiektami jako uporządkowaną listę.

Modeluje procesy systemu. Pokazuje przepływ
wartości danych od ich źródeł w obiektach poprzez
procesy, do ich przeznaczenia w innych obiektach.

Komunikacja klas
(class
communication)
(CADRE)

Asocjacja klas
(class association)
(OMT)
Dynamiczny
(OMT)

Fumkcjonalny
(OMT)

Diagram komunikacji klas
(Class Communication
Diagram, CCD)

Diagram generalizacji
komunikatów (Message
Generalization Diagram, MGD)

Diagram asocjacji klas (Class
Association Diagram, CAD)

Diagram zmian stanów (State
Transition Diagram, STD)

Diagram tropów zdarzeń
(Event Trace Diagram, ETD)

Diagram przepływu danych
(Data Flow Diagram, DFD)

Model

Modelowany poprzez

Cel

Fazy metodyki OMT

OMT zakłada iterację (powtarzanie) następujących faz:

Analiza: budowa modelu świata rzeczywistego

Projektowanie systemowe: zagadnienia architektoniczne, podsystemy, itd

Implementacja: zakodowanie projektu w języku programowania

Model obiektów

Model dynamiczny

Model funkcjonalny

Projektowanie systemu

Projektowanie obiektów

Analiza

Projektowanie

Projektowanie obiektowe: budowa modeli obiektowych opartych na
wynikach analizy.

Analiza obiektowa metodą

BOOCHA

Diagramy obiektowe

Diagramy klasowe

Diagramy interakcji

Diagramy przejść stanowych

Specyfikacje relacji między klasami

Specyfikacje klas i operacji

Diagramy modułowe

Diagramy procesowe

Diagram obiektowy - przykład

Diagram interakcji

uzupełniający sposób przedstawienia współpracy

między obiektami

nacisk położony jest na przesyłanie wiadomości
kolumny diagramu odpowiadają obiektom
kolejność pionowa na diagramie odpowiada

kolejności przesyłania wiadomości (można
zrezygnować z oznaczenia liczbowego)

Diagram interakcji

Diagramy przejść stanowych

ze stanami wiąże się zbiór akcji

wykonywanych w chwili wejścia do

stanu (poprzedzając akcję słowem entry)
lub w chwili wyjścia ze stanu (słowo exit)

przy przejściu obok zdarzenia i akcji

związanych z przejściem mogą być też
uwzględnione warunki warunkujące
przejście

Diagramy przejść stanowych

Przykład

Diagramy klasowe

Typy relacji między klasami

a) klasy stowarzyszone
b) klasa B dziedziczy po A
c)

klasa A zawiera B – relacja
agregacji

d) klasa A używa B – relacja

wykorzystania

e) klasa B jest klasą-wzorcem

dla klasy A – relacja
instancji

klasa A jest metaklasą dla
B

g) kategoria klas A używa B i

C, tj. klasy należące do A
dziedziczą, zawierają,
używają klas należących
do B lub C

Specyfikacje relacji

dostęp do:

 ||| - warstwy implementacji
 || - obszaru prywatnego
warstwy

zewnętrznej

 | - obszaru chronionego

warstwy zewnętrznej

specyficzne własności klas:

A – abstrakcyjna
S – zmienna klasy
F – zaprzyjaźniona
V – wirtualna (na rys.

zapobiega podwójnemu

dziedziczeniu po klasie A)

Przykład diagramu klasowego

Konstrukcja modelu logicznego w
fazie analizy

identyfikacja kluczowych
abstrakcji



diagramy obiektowe



ewentualnie diagramy
interakcji

konstrukcja scenariuszy



ewentualnie diagramy przejść
stanowych

definicja odpowiedzialności
klas

Identyfikacja kluczowych abstrakcji
w podejściu klasycznym



rzeczy – obiekty w percepcji zmysłów



zdarzenia/wydarzenia



role – odgrywane przez obiekty



koncepcje/idee



miejsca/lokalizacje – np. miejsca

wydarzeń



relacje – pomiędzy rzeczami, rolami,

zdarzeniami itp.



struktury/systemy/organizacje

Podejście klasyczne (classical approach)
identyfikuje obiekty w postaci:

Analiza zachowań abstrakcji

Analiza zachowań (behaviour analysis) polega

na grupowaniu podobnych z zewnątrz

abstrakcji klas i obiektów



analiza odpowiedzialności (responsibilities

analysis) identyfikuje ogólne zadania i usługi

składowych systemu oraz grupuje je pod

względem podobieństw



analiza funkcji systemu (system functions

analysis) polega na określeniu zbioru

wszystkich funkcji systemu i przypisaniu w

sposób zstępujący funkcji wraz z ich

zachowaniami kluczowym elementom

systemu, czyli obiektom



analiza elementarnych aktywności (function

point analysis) wyodrębnia podstawowe

zachowania się systemu w reakcji na

określone zdarzenia upatruje obiekty i klasy w

aktywnych składowych systemu

Analiza dziedziny problemowej

Analiza dziedziny problemowej (domain analysis) –
klasy i obiekty identyfikowane są przez ekspertów w
czterech etapach:



konstrukcji ogólnego abstrakcyjnego modelu
dziedziny problemowej



analizy podobnych istniejących systemów
informatycznych sprowadzenia tych modeli do danej
dziedziny problemowej



analizy modeli istniejących systemów ze
wskazaniem podobieństw i różnic pomiędzy nimi a
omawianym projektem



wyspecyfikowania abstrakcyjnego modelu
systemu tak by spełniał wymagania i był zgodny ze
standardami istniejących systemów

Konstrukcja scenariuszy i
odpowiedzialności klas

Konstrukcja scenariuszy

polega na opisaniu

zachowania się systemu za pomocą sekwencji
elementarnych wydarzeń tego zachowania



przypisanie ról obiektom biorącym udział w
elementarnych aktywnościach systemu (DO, DI)



jeżeli istnieją pewne istotne stany systemu, to
można opisać je diagramami przejść stanowych

Odpowiedzialności klas

dokonuje się przez

przypisanie jej obiektom zdolności odegrania swych
roli:



zbiór akcji, które obiekt ma prawo wykonywać



wiedza wpisana w obiekt o jego mechanizmach
reakcji na zaistniałe sytuacje

Projektowanie w metodzie
BOOCHA

Polega na określeniu modelu systemu w

dziedzinie rozwiązania problemu

(solution domain)



podmodele modelu logicznego:

1. model struktury klasowej (class structure)

– dekompozycja systemu po zastosowaniu
operacji uogólniającej

2. model struktury obiektowej (object

structure) – struktura po zastosowaniu

operacji abstrakcji kompozycyjnej

3. model architektury logicznej (logical

architecture) – klasy pogrupowane w
kategorie klas



model fizyczny

1. architektura warstwy oprogramowania
2. architektura warstwy sprzętowej

Specyfikacja klas i operacji

Nazwa

Nazwa klasy

Definicja: ogólna

Charakterystyka klasy

Odpowiedzialności Opis odpowiedzialności przypisanych klasie w

fazie analizy

Atrybuty

Pełna lista atrybutów

Operacje

Pełna lista operacji

Ograniczenia

Warunki, w których spełnienie gwarantuje, że
cały system znajduje się w stanie stacjonarny

Diagramy przejść
stanowych

Referencje do diagramu opisującego
dynamikę klasy

Prawa dostępu

[implementacja | prywatny | chroniony |
publiczny]

Moc

Liczba instacji jakie może mieć klasa

Parametry

Liczba parametrów formalnych/aktualnych

Trwałość

[tak | nie]

Współbieżność

[nie (sekwencyjność) | strzeżona
|synchroniczna | aktywna]

Złożoność
pamięciowa

Wielkość pamięci zajmowanej przez instancje

Specyfikacja klas i operacji

Nazwa

Nazwa operacji

Klasa powrotu

Referencja do klasy

Dostępność

[implementacja | prywatna chroniona |
publiczna]

Warunki wstępne

[opis | referencja do kodu źródłowego |
referencja do diagramu źródłowego]

Semantyka
operacji

--||--

Warunki końcowe

--||--

Sytuacje
szczególne

Lista operacji szczególnych

Współbieżność

[nie (sekwencyjność) | strzeżona
|synchroniczna | aktywna]

Złożoność
pamięciowa

wyrażenie określające wielkość pamięci
zajmowanej przez kod operacji

Złożoność
czasowa

wyrażenie określające ilość czasu
wymaganego do wykonania operacji

Diagramy modułowe

program główny (main
program), np. *.cpp
moduł zawierający
deklaracje klas i
obiektów (specification
modules), np. *.h
moduł zawierający
definicje (body
modules), np. *.cpp
moduł z deklaracjami i
definicjami
podsystem
relacja typu „zależy od”

Diagramy modułowe

program główny
zależy
od modułów:

zawiera

deklaracje i
służy modułom
jako źródło

wspólnych

typów,
stałych itp

Diagram modułowy reprezentujący
dekompozycję systemu

Diagramy procesowe

Diagram procesowy dla zintegrowanego
systemu zarządzania firmą

PORÓWNANIE

METODYK I

INNE UWAGI

Różnice pomiędzy metodykami

Podejścia

proponowane przez różnych autorów

różnią się częściowo

nie muszą

być jednak ze sobą

sprzeczne

Nie ma metodyk uniwersalnych

. Analitycy i projektanci wybierają

kombinację technik i notacji, która jest w danym momencie najbardziej
przydatna.

Poszczególne

metodyki

zawierają

elementy

rzadko

wykorzystywane w praktyce

(np. model przepływu danych w OMT).

Notacje

proponowane przez różnych autorów

nie są koniecznie

nierozerwalne z samą metodyką

. Np. notacji UML można użyć dla

metodyki Coad/Yourdon.

Narzędzia CASE nie narzucają metodyki

; raczej, określają one tylko

notację. Twierdzenia, że jakieś narzędzie CASE “jest oparte” na
konkretnej metodyce jest często wyłącznie hasłem reklamowym.

Nawet

najlepsze metodyki i narzędzia CASE nie są w stanie zapewnić jakości
projektów.

Kluczem do dobrego projektu jest zespół doświadczonych, zaangażowanych i
kompetentnych osób, dla których metodyki, notacje i narzędzia CASE służą jako
istotne wspomaganie.

Ryzyko stosowania metod IO



Luka formalna w dziedzinie poznania



Zagadnienia zaliczające się do luki poznawczej, nie
są w trakcie analizy dostrzegane i nie zostaną
wyczerpująco opracowane, można więc określać je
mianem ryzykownych punktów projektu.



Od ogółu do szczegółu



Na tym poziomie pojawiające się problemy
umykają z powodu natłoku szczegółów w
projekcie



Od szczegółu do ogółu



Problemy stają się zbyt ogólne dla zespołów
zajmujących się zagadnieniami podstawowymi

Nowe kierunki rozwoju
metod projektowania

Najważniejsze kierunki innowacji:



Integracja systemów

danych i procesów



Unifikacja funkcji

cząstkowych systemów



Zwiększanie

dostępności do bazy danych

dla wszystkich komórek organizacyjnych



Upowszechnienie

nowoczesnych

sposobów prezentacji danych

(

wizualizacji

) dla celów wspomagania ich

analizy



Doskonalenie procesów podejmowania

decyzji

i ich przekazywania



Zmierzanie do

budowy modułowej i

otwartości

całego systemu (projektowanie

komponentowe, COTS)

Dalsze innowacje ...



Zapewnienie

kompleksowego

charakteru

funkcjonowania całego systemu

(dostępność, skuteczności decyzji w

całości)



Stałe podnoszenie

zaawansowania

merytorycznego i technologicznego

(metody zarządzania + sam system)



Zmierzanie do osiągnięcia

elastyczności

funkcjonalnej i strukturalnej



Zapewnienie stałej

zgodności ze

zmieniającymi się elementami otoczenia

zwłaszcza stanem prawnym ewoluującym

zgodnie z przyjętymi procedurami

legislacyjnymi



Bezpieczeństwo, poufność, integralność,

hierarchia haseł i przywileje dostępu

Metodologie tworzenia i
projektowania SI

Są

różne

nurty (podejścia):



Strukturalne,



Obiektowe,



Przyrostowe,



Komponentowe,



Aspektowe,



Podejścia do wytwarzania
oprogramowania określonej klasy (np..
systemów czasu rzeczywistego,
ekspertowych, zintegrowanych, etc),



Zależne od przyjętego modelu cyklu życia
systemu

Idee metodyk



Tradycyjne metody prowadzenia projektu mają

w zamyśle sprzedać produkt – gotowe

oprogramowanie



Realizacja produktu dla klienta



Sukces – dobrze wynegocjowany kontrakt



Bardzo sformalizowany cykl życia produktu



Nowe techniki zarządzania projektem

ukierunkowane są na usługę.



Realizacja produktu dla i przy pomocy
klienta



Człowiek – użytkownik, jako czynnik

sukcesu.



Elastyczne traktowanie planu realizacji.

Inne metody projektowania SI
związane z modelem cyklu
życia

Metoda Spiralna

- zmodyfikowanie tradycyjnej spirali o

występowanie przeskoków, dzięki temu możemy wracać do

dowolnego punktu jak i przeskoczyć niektóre etapy.

Teoria Win-Win

, która głosi, iż najlepszy jest proces w którym

wszyscy wygrywają. Należy:



Zidentyfikować wszystkich



Określić warunki sukcesu



Negocjować podczas tworzenia prototypów

Metody Zwinne

(agile software development methods) -

bardziej swobodne od tradycyjnych metody – tu ludzie są

ważniejsi od sztywnych procedur - Zmniejszenie nacisku na

dokumentację i formalizację - Z użytkownikiem powinno

się współpracować a nie negocjować. Ważniejsza jest

umiejętność reagowania niż szczegółowy i sztywny plan -

Metody te można stosować do niewielkich systemów



powinna

objąć cały cykl życia systemu

przy zapewnieniu

płynnych przejść pomiędzy fazami,



winna obejmować

różnorodne, dostosowane do specyfiki

podejścia, metody, techniki i narzędzia



powinna ułatwić porozumiewanie się pomiędzy różnymi
grupami tworzącymi SI



powinna być stosunkowo łatwa do opanowania

i dostosowania

do szerokiej klasy problemów oraz

zawierać mechanizmy

ewolucyjności i modyfikalności

Dotychczasowe rozważania pozwalają

na określenie

ogólnych wymagań na racjonalną metodykę tworzenia SI

Podsumowanie - ogólne
wymagania dla metodyk

SWOBODNE

METODYKI

PROJEKTOWANIA SI

„agile software development methods”
- charakterystyka, przegląd, zasadność użycia

Specyfika swobodnych
metodyk



Techniki zakładają ścisłą współpracę z
użytkownikiem czy odbiorcą. Właściwie
postuluje się włączenie użytkownika w
proces projektowania oprogramowania.



Sprzedawana jest usługa tworzenia
oprogramowania a nie gotowy produkt -
oprogramowanie, tak więc użytkownik jest
tym, kto podejmuje decyzje co i w jakiej
kolejności będzie w projekcie wykonywane.

Specyfika swobodnych
metodyk



Istotną wagę przywiązuje się do
poprawnego szacowania kosztów prac,
tak by inwestor/użytkownik mógł
świadomie planować swe wydatki na rozwój
oprogramowania.



Zobowiązuje się wytwórcę
oprogramowania do tego, że każdym
swym działaniem powinien udowadniać
inwestorowi efektywne wykorzystanie
czasu i powierzonych mu środków.

Specyfika swobodnych

metodyk cd.



Sprzedając usługę programowania rezygnuje
się z zysków z ponownego użycia kodu, bo
prace odniesione są do niepowtarzalnego projektu.
Przy takim założeniu rozległa dokumentacja
projektowa

staje

się

zbędnym

kosztem

obciążającym użytkownika i unika się jej.



Uproszczenia

dokumentacyjne

wymuszają

specyficzny sposób porozumiewania się z
użytkownikiem.

trakcie

tworzenia

oprogramowania często (na bieżąco) zadaje się
mu pytania i prośby o potwierdzenie dotyczące
niewielkiego

zakresu

funkcjonalności.

Stąd

wynikają

inkrementalny

sposób

dostarczania

oprogramowania

oraz

krótkie

iteracje

implementacyjne.

Specyfika swobodnych
metodyk cd...



Nie specyfikuje się formalnych punktów

kontrolnych w projekcie - nie są one

potrzebne, gdyż zakończenie każdej iteracji

jest punktem kontrolnym samym w sobie. Z

drugiej

strony

wprowadzenie

sformalizowanych punktów kontrolnych nie

we wszystkich technikach jest możliwe.



Sekwencyjna

realizacja

wymagań

użytkownika powoduje częste zmiany w

architekturze systemu i konieczność

przebudowy

kodu.

W nowych metodykach zadanie przebudowy

kodu postrzega się nie jako wyjątek, lecz

jako regułę.

Manifest swobodnych metodyk



ludzie, ich kontakty, zdolność do rozwiązywania
problemów są ważniejsze niż sztywne
procedury i narzędzia zarządzania,



wynikiem projektu jest pracujące
oprogramowanie a nie dokumentacja,



z użytkownikiem się współpracuje a nie
negocjuje kontrakt,



ważniejsza jest umiejętność reagowania
na zmieniające się warunki otoczenia niż
podążanie za opracowanym na wstępie planem.

METODOLOGIE

ZWINNE

Metodyki zwinne



Metodyka

Crystal

(Crystal family),



Projektowanie zorientowane na właściwości

(Feature Driven Development -

FDD



Modelowanie zwinne (

Agile

Modeling),



Programowanie ekstremalne

(Extreme

Programming),



Adaptacyjny rozwój oprogramowania

(Adaptive Software Development),



Metodyka

scrum

(Scrum development),



Prototypowanie

(Prototyping methodology),



Szybkie programowanie internetowe

(Internet Speed Development),



Pragmatyczne programowanie

(Pragmatic

Programming).

METODOLOGIE

ZWINNE

FDD - FUTURE DRIVEN DEVELOPMENT

FDD (zwinne metodologie) -
charakterystyka



metodyka tworzenia oprogramowania,
wspomagająca zarządzanie fazami analiz,
projektowania i konstrukcji oprogramowania



jest projektowaniem zorientowanym na
właściwości



prace rozpoczynają się od określenia „ogólnego
modelu systemu”.

FDD (zwinne metodologie) -
charakterystyka



określana jest domena projektu i
iteracyjnie dzielona na coraz to mniejsze
znaczeniowo obszary.



każdy niepodzielny obszar znaczeniowy
jest opracowywany przez przypisaną do
niego grupę projektantów, w wyniku
czego powstaje model szczegółowy, będący
składnikiem całościowego modelu systemu.



zespół projektantów korzysta z
opracowanych wcześniej wymagań
systemowych i przypadków użycia.

FDD – dobre praktyki IOP



oparcie procesu o wymagania
klienta



architektura systemu



krótkie iteracje



indywidualna odpowiedzialność za
kod



inspekcje

FDD – role w zespole



Menadżer projektu



Eksperci dziedzinowi



Główny architekt



Menadżer programistów



Główni programiści



Właściciele klas

FDD – pojęcie cechy



Zasadniczym elementem procesu FDD jest cecha
(feature) produktu.



Cechą jest mały fragment funkcjonalności produktu.



Cecha w SI dostarcza klientowi interesujące go
wyniki.



Opisuje wymagania funkcjonalne wg schematu:

<action>the<result><by|of|to|from|for>a(n)<objec



Grupuje się w zbiory cech wg schematu:

<action>-ing<buisness

deliverable><by|of|to|from|for>a(n)<object>

FDD (Feature Driven
Development)

... został utworzony pomiędzy rokiem 1997 a 1999 w United
Overseas Bank w Singapurze przez zespół, któremu
przewodził Jeff De Luca. Zespół ten w swojej pracy bazował
na materiałach Petera Coad’a, również członka zespołu, który
wprowadził idee Feature definition i Feature list

[1]

[1]

David J. Anderson, Eli Schragenheim: Agile Management for Software

Engineering

FDD ...

... opiera się na następujących

założeniach:



system służący budowaniu innych

systemów powinien być skalowalny,



proste procesy są najlepsze,



dobre procesy pozwalają zespołowi
na skupienie się na wynikach,



krótkie, ukierunkowane na cechy
produktu i iteracyjne cykle są
najlepsze.

Feature Driven Development

... definiuje pięć procesów wysokiego poziomu

[1]



opracowanie ogólnego modelu (modelowanie
kształtu),



zbudowanie listy cech,



plan projektu na podstawie cech,



projektowanie,



wytworzenie.

[1]

Stephen Palmer: Feature Driven Development and

Extreme Programming

FDD jest uważany za dobrą
mieszankę zasad i elastyczności,
która stanowi prosty w
wykorzystaniu szkielet dla
projektu.

FDD – realizacja metody



założeniem jest

inkrementacyjne opracowywanie

poszczególnych funkcjonalności systemu



projekt w myśl FDD składa się z

pięciu

sekwencyjnie

następujących po sobie

etapów.

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

FDD – faza I



stworzenia zespołu projektowego pod kierownictwem Głównego
Architekta,



przeprowadzenia przeglądu dziedziny problemu,



studiowanie dokumentów z wymaganiami i z dziedziny problemu,



przygotowanie alternatywnych modeli w oddzielnych małych
grupach projektowych,



wypracowanie wspólnego modelu,



Zatwierdzenie ogólnego modelu,



Zdokumentowanie istotnych założeń dotyczących
projektu i alternatywnych rozwiązań.

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

Opracowanie ogólnego modelu



Krok ten dotyczy zdefiniowania wstępnego
kształtu projektu. Członkowie zespołu
tworzącego oprogramowanie i udziałowcy
systemu definiują wspólnie wstępny,
prowizoryczny model tego, co powinno
zostać wytworzone.



Końcowym efektem tego etapu powinien
być model klas zdefiniowany w języku
UML

FDD – faza II



na podstawie specyfikacji wymagań systemowych oraz
opracowanego modelu/modeli opracowywanie są list
funkcjonalności



Listy mają charakter hierarchiczny i zawierają funkcjonalności
główne



Rozdrabnianie funkcjonalności na coraz niższe poziomy



Przeglądanie list przez użytkowników i inwestorów w celu kontroli
poprawności i kompletności

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

Zbudowanie listy cech



Wykorzystując wiedzę zebraną w
poprzednim etapie, członkowie
zespołu i udziałowcy opracowują
możliwie szczegółową listę
pożądanych cech systemu.
W procesie tym mogą zostać
wykorzystane już istniejące
dokumenty, na przykład
specyfikacje przypadków użycia.

FDD – faza III



sformowania zespołu planującego



określenia kolejności implementacji



przypisania zbioru cech głównym programistom



przypisania klas do programistów

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

FDD – faza IV



sformowania zespołu programistów pod kierunkiem
Głównego Programisty.



opcjonalnego przeglądu dziedziny problemu i studiowania
dokumentów referencyjnych



stworzenia diagramów sekwencji



uszczegółowienia modelu obiektowego



zapisania nagłówków klas i metod



inspekcji projektu

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

FDD - faza V



implementacja kodu klas



przeprowadzenia inspekcji kodu



testowania jednostkowego



integracji nowego kodu z produktem

Planowanie

podstawie

funkcjonal-

ności

Określenie

listy

funkcjonal-

ności

Opracowanie

ogólnego

modelu

Wykonywanie

oparciu o

funkcjonal-

ności

Projektowanie

podstawie

funkcjonal-

ności

Projektowanie i wytwarzanie

Szef programistów wybiera małą grupę cech, które

powinny zostać wytworzone w przeciągu następnych dwóch,
trzech tygodni, a następnie identyfikuje klasy związane z
tymi cechami oraz osoby, które będą nad tymi klasami
pracowały.

Zespół, przydzielony do zrealizowania wybranych cech,

określa szczegółowe diagramy sekwencji dla każdej cechy.
Następnie osoby odpowiedzialne za dane klasy tworzą je i
opisują ich metody.

Zanim nastąpi ostatni etap – wytwarzanie, zespół

dokonuje inspekcji projektu. W fazie wytwarzania osoba
odpowiedzialna za klasę tworzy jej kod, opracowuje testy
pakietów i integruje klasę z pozostałymi elementami
systemu. Kierownik zespołu podejmuje decyzję, czy można
dane cechy dodać do głównej wersji aplikacji.

METODOLOGIE

ZWINNE

SCRUM - Taktyka Młyna

Źródło:

•

Ken Shwaber „Sprawne zarządzanie projektami metodą SCRUM”

Tytuł oryginału:

„Agile Project Management with SCRUM”

•

http://www.agilealliance.org

Trochę historii

…początek lat 90-tych



Twórcy: Ken Schwaber i Jeff Southerland



Cel: pomoc organizacjom zmagającym się ze

skomplikowanymi projektami

programistycznymi

...

ukierunkowuje organizację na tworzenie

produktów, które mają szansę odnieść sukces na

rynku. Bez poważnych zmian, często w przeciągu

trzydziestu dni, zespoły są w stanie stworzyć

użyteczny i gotów do zademonstrowania fragment

produktu. SCRUM może zostać zaimplementowany

na początku projektu lub nawet już w trakcie jego

realizacji.

SCRUM

„Najbardziej wprowadzający w

zakłopotanie i paradoksalny
proces do zarządzania
skomplikowanymi projektami”

Ken Shwaber

SCRUM jest ...

... zbiorem wzajemnie powiązanych praktyk i zasad, które
optymalizują środowisko produkcyjne, redukują nadmierną
biurokrację w organizacji i synchronizują wymagania rynku z
iteracyjnymi prototypami.

Bazując na nowoczesnych teoriach związanych z kontrolą
procesów, SCRUM sprawia, że oprogramowanie może zostać
skonstruowane w oparciu o dostępne zasoby, mieć
akceptowalną jakość, a projekt nie przekroczy terminu dostawy.

Co trzydzieści dni, nawet jeśli wykorzystywana jest nie
do końca opanowana technologia, klientowi jest
dostarczana jakaś funkcjonalność, która jest dla niego
użyteczna (

What is SCRUM: http://www.controlchaos.com/

)

Kiedy stosować ?



Skomplikowane projekty – kiedy
nie można przewidzieć wszystkiego
co może się przydarzyć lub nawet
nie można ich szczegółowo opisać w
momencie powstawania



Klienci nie do końca wiedzą
czego potrzebują



Często zmieniające się
wymagania

Co oferuje ?



Oferuje szkielet oraz zestaw zachowań,
które utrzymują wszystko na widoku



Wszystko odbywa się na zdrowym
rozsądku – brak nakazów typu: „teraz
zrób to”



Oparty na iteracyjnej, przyrostowej
strukturze procesu -> wybierana jest
część, która stanowi przyrost
funkcjonalności



Prowadzenie i monitorowanie
projektów w taki sposób aby dostarczyć
najlepsze rezultaty

Udogodnienia dla klienta



Nabywca (klient) dostaje po
kawałku (zamkniętą
funkcjonalność) swój produkt –
wczesne wdrażanie poszczególnych
kawałków



Nabywca może powiedzieć co
chce aby było zrobione w
pierwszej kolejności

SCRUM - charakterystyka



Istotą metody Scrum jest adaptacyjny,
samoorganizujący się proces wytwarzania
oprogramowania.



Zakłada ewolucyjny styl tworzenia oprogramowania.



Koncentrując się na zadaniach zarządzania pozostawia
wolny wybór w wyborze technik prowadzenia prac
programistycznych.



Ewolucyjny styl to generalnie iteracja, a pojedynczy
cykl to w istocie podprojekt kaskadowy składający się z
opracowania wymagań, analizy, projektowania, kodowania
i wdrożenia trwający nie dłużej niż 30 dni.

SCRUM - zarządzanie



Rozpoczęcie prac związane jest ze
Spotkaniem Planowania Cyklu (Sprint
planning meeting),



Zakończenie prac z nieformalnym
Spotkaniem Przeglądowym (Scrum
Review meeting).



Są również Codzienne Spotkania Zespołu
projektantów i programistów (Daily
Scrum meeting).

SCRUM - kontrola



Scrum przewiduje częste działania zarządcze
skupiające się na identyfikowaniu problemów i
przeszkód w pracach inżynieryjnych



Bieżąca samokontrola całego zespołu,
codzienne spotkania, (Daily scrum meeting) 15
minut,

Co robiłem wczoraj?

Co będę robił dzisiaj?

Co mi przeszkadza w pracy?



W trakcie spotkania omawiane są problemy oraz
planowane są posunięcia z nich wynikające.

SCRUM – planowanie cyklu



Spotkanie poprzedzające rozpoczęcie
cyklu – organizacja działań.



Zdejmowanie cech z rejestru zadań.



Stworzenie rejestru zadań przebiegu.



Obejmuje wszystkich członków zespołu
(prosiaki i kurczaki).



Chicken określają cel przebiegu.



Pig uściślają rejestr zgodnie z określonym
celem.

SCRUM - dokumentacja



Rejestr zadań

(Product backlog)



Historyjki klienta (User stories)



Must be



Should be



Nice to have



Rejestr zadań przebiegu

(Sprint

product backlog)



Wykres spalania

(Burn down) – wykres

pracochłonności

SCRUM – tworzenie
rejestru przebiegu



rozbicie życzeń klienta, na elementarne czynności
techniczne, konieczne do realizacji analizowanego celu



oszacowanie każdej czynności technicznej na koszt roboto-
godziny potrzebnej do zrealizowania funkcjonalności



przyporządkowanie odpowiednich czynności do realizacji
osobom najbardziej kompetentnym do jej wykonania, co
ustala sam zespół, nie kierownik,



zsumowanie wszystkich roboto-godzin z wszystkich
wybranych czynności i sprawdzeniu czy łączna ich liczba
przekracza, czy nie zapełnia godzin jednego pełnego
cyklu,



dopełnienie lub ujecie wybranych czynności, aby możliwie
jak najdokładniej zmieścić się czasowo w przebiegu
jednego cyklu, czyli 30 dni.

SCRUM –

(Rejestr zadań

przebiegu) pregame



obejmuje czynności planowania i opracowania zarysu
architektury systemu.



W trakcie tej fazy wszystkie znane wymagania są
spisywane i opracowywana jest lista wymagań (Product
backlog).



Źródłem wymagań są przede wszystkim użytkownicy, ale
również dział marketingu i sprzedaży, dział obsługi klienta
oraz sam zespół projektantów-programistów.



Wymaganiom zestawionym na liście przypisywane są
priorytety.



Na podstawie listy opracowywana jest architektura
systemu.



Finalnie, w ramach oddzielnego spotkania, tworzony jest
podzbiór listy wymagań.



Ustalany jest cel przebiegu.

SCRUM – faza produkcji



(Product backlog). Lista ta jest otwarta, a zadania do
realizacji dopisywane są do niej w trakcie całego
procesu tworzenia oprogramowania.



(sprint backlog list). Zawarte tam wymagania są
realizowane w ramach aktualnej iteracji



Rozpatrywane są zmiany w architekturze systemu
wynikłe z wprowadzenia nowych wymagań.



Kontrola procesu wytwórczego estymacją wykresu
pracochłonności

SCRUM - pracochłonność



Proces estymacji pracochłonności
polega na gromadzeniu informacji
statystycznych
o przebiegu projektu i
wyznaczaniu kosztu prac na ich
podstawie.



Każdego dnia aktualizowana jest
pozostała do realizacji liczba
robotogodzin



Aproksymacja pokazuje
przybliżony termin zakończenia
przebiegu w odniesieniu do
osiągniętego tempa prac



Na jego podstawie aktualizuje się
rejestr przebiegu.

Role uczestników projektu



ScrumMaster



Właściciel produktu



Zespół



Users



Klient



Managers

Rola Chicken określają cel przebiegu.



Rola Pig uściślają rejestr zgodnie z

określonym celem

Inne osoby

ScrumMaster



ScrumMaster – jest liderem, a nie

kierownikiem



Odpowiedzialny za:



Przywództwo



Prowadzenie



Dostarczanie wskazówek



Uczy zespół metodyki SCRUM



Pomoc właścicielowi produktu w wyborze

najbardziej wartościowych zaległości

produktowych

SPRAWIA ŻEBY SCRUM DZIAŁAŁO

ScrumMaster cd.



Usuwanie barier pomiędzy projektantami, a
właścicielem produktu tak aby właściciel produktu
bezpośrednio kierował rozwojem projektu



Uczenie właściciela produktu maksymalizacji zwrotów
kosztów i spełniania swoich celów przy pomocy SCRUM



Poprawa życia zespołu projektującego poprzez
ułatwienie mu pracy twórczej



Poprawa wydajności zespołu projektowego na
wszelkie możliwe sposoby



Poprawa praktyk inżynierskich oraz narzędzi tak, by
każdy przyrost funkcjonalności był możliwy do wydania



Udostępnianie zaktualizowanych informacji o
postępach zespołu wszystkim stronom

Product Owner



Gwarant prac we właściwym
kierunku



Zajmuje się:



Tworzeniem wymagań użytownika
(User stories)



Nadawaniem priorytetów dla
wymagań



Budowaniem rejestru wymagań
(Product Backlog)

Właściciel produktu



Reprezentuje interesy każdej z
zainteresowanych stron



Odpowiedzialny za:



Zebranie początkowych (ogólnych)
wymagań



Przypisywanie priorytetów zadaniom
funkcjonalnym i niefunkcjonalnym



Wybór najbardziej wartościowej
funkcjonalności (na początku), a
następnie nadbudowywanie jej

Zespół



Sam organizuje swoją pracę



Zbiorowa odpowiedzialność



Może wybierać zadania do zrealizowania



Może się podzielić na mniejsze zespoły



Najbardziej optymalny to 7 osób

BRAK INTEGRACJI Z ZEWNĄTRZ

Proces Scrum podzielony jest na trzy
główne etapy:



rozpoczęcie gry (pregame),



faza produkcji (development
phase),



gra na zakończenie
(postgame).

obejmuje czynności planowania i opracowania
zarysu architektury systemu
(Architecture high level design).

W trakcie tej fazy wszystkie znane wymagania
są spisywane i opracowywana jest lista
wymagań (Product backlog list).

Lista ta jest otwarta, a zadania do realizacji
dopisywane są do niej w trakcie całego procesu
tworzenia oprogramowania.

Faza rozpoczęcia

Źródłem wymagań są przede wszystkim
użytkownicy, ale również dział marketingu i
sprzedaży, dział obsługi klienta oraz sam
zespół projektantów-programistów.

Wymaganiom zestawionym na liście
przypisywane są priorytety.

Na podstawie listy opracowywana jest

architektura systemu.

Faza rozpoczęcia

Każdorazowo, gdy do listy dopisywane są
nowe wymagania, są one rozpatrywane w
ramach specjalnego spotkania
(Design Review Meeting).

Rozpatrywane są również zmiany w
architekturze systemu wynikłe
z wprowadzenia nowych wymagań.

Faza produkcji

Finalnie, w ramach oddzielnego spotkania,
tworzony jest podzbiór listy wymagań.

Zawarte tam wymagania przeznaczone są
do realizacji
w ramach aktualnej iteracji
(sprint backlog list).

Faza zakończenia

Faza zakończenia projektu

rozpoczyna się wraz z ustaleniem pomiędzy
użytkownikiem a projektantami,
że wymagania są zrealizowane
(lista wymagań jest pusta).

System jest przygotowany do instalacji.

W tej fazie wykonywana jest ostateczna integracja
modułów i testowanie, a także przygotowuje się
dokumentację.

SCRUM – postgame



rozpoczyna się wraz z ustaleniem pomiędzy
użytkownikiem a projektantami, że wymagania są
zrealizowane (lista wymagań jest pusta).



System jest przygotowany do instalacji.



W tej fazie wykonywana jest ostateczna integracja
modułów i testowanie, a także przygotowuje się
dokumentację.



Spotkanie podsumowujące (Scrum Review Meeting)



Omawiane są na nim postępy prac oraz
formułowane są wnioski, nowe wpisy do listy
wymagań lub postulowane są generalne zmiany w
architekturze systemu.

Scrum wprowadza interesujące narzędzie zarządcze jest
nim omawiana już lista wymagań (produkt backlog list).

Opisuje ona wszystko to, co powinno się znaleźć w
ostatecznej wersji oprogramowania (wedle aktualnej
wiedzy).

W ten sposób lista wymagań opisuje wszystko, co należy
zrobić w projekcie.

Lista zwykle zawiera właściwości, funkcje, usterki,
defekty, żądania rozszerzeń i żądania uaktualnień
technologicznych.

Do zarządzania listą przeznaczony jest
pracownik - Zarządca Projektu.

On trzyma pieczę nad dodawaniem nowych

pozycji do listy, jak
i usuwaniem pozycji gdy są zrealizowane.

W pragmatyce rozwoju oprogramowania „open
source” taka lista nosi nazwę „to do list”.

Na diagramie przebiegu projektu nie
przedstawiono jednego istotnego procesu
biegnącego niezależnie od procesów
wytwórczych.

Jest nim estymacja pracochłonności.

W trakcie całego projektu równolegle
z pracami projektowymi
i implementacyjnymi trwa proces oceny
pracochłonności postulatów zawartych w liście
wymagań.

W początkowych fazach projektu oceny te są zgrubne, lecz
w miarę gromadzenia informacji z postępu prac
implementacyjnych stają się coraz bardziej dokładne.

Proces estymacji pracochłonności polega na gromadzeniu
informacji statystycznych
o przebiegu projektu i wyznaczaniu kosztu prac na ich
podstawie.

Estymacja pracochłonności nie bierze pod uwagę dużych
zmian w architekturze systemu lub użytkowanej
technologii.

W przypadku projektu prowadzonego metodą Scrum od początku
zaleca się by użytkownik wraz z zespołem projektantów spędził
kilkanaście dni nad opracowaniem listy wymagań.

Muszą się w niej znaleźć zapisy dotyczące zarówno wymagań
biznesowych jak
i technologicznych.

Celem nadrzędnym pierwszej iteracji produkcyjnej jest pokazanie
użytkownikowi jakiegoś fragmentu funkcjonalności systemu
zaimplementowanego
w ramach wybranej technologii.

Należy przewidzieć dużą ilość pracy przy pierwszej
iteracji, bo dochodzą tu prace nad opracowaniem
szkieletu systemu, do którego będą dodawane
funkcjonalności
w ramach kolejnych iteracji.

Pierwsza iteracja produkcyjna różni się od kolejnych
również z tego powodu, że na jej listę wymagań
wpisane są takie zadania jak: zapoznanie się z
technikami Scrum, organizacje zespołów Scrum,
rozdział ról
w projekcie.

Dalsze iteracje są prostsze i szybsze.

Każdy cykl to w istocie podprojekt
kaskadowy składający się
z opracowania wymagań, analizy,
projektowania, kodowania
i wdrożenia trwający nie dłużej niż 30 dni.

SCRUM - przebieg

Czynności zarządcze w fazie
produkcji zasadzają się na
spotkaniach organizacyjnych.



Rozpoczęcie prac

związane jest ze

Spotkaniem Planowania Cyklu (Sprint
planning meeting),



Zakończenie

prac z nieformalnym

Spotkaniem Przeglądowym (Scrum
Review meeting).



Są również

Codzienne Spotkania

Zespołu

projektantów i programistów (Daily
Scrum meeting).

Sprinty i spotkania



Rodzaje:



Spotkanie planujące sprint ->
początek sprintu



Sprint



Codzienny SCRUM



Przegląd sprintu



Retrospektywne spotkanie sprintu

Spotkanie Planowania Cyklu

(Sprint planning

meeting) organizowane jest przez zarządcę procesu
dwukrotnie.

W pierwszym spotkaniu biorą udział użytkownicy, nabywcy, zarząd i
zespół projektantów. Ustala się cele i priorytety właśnie
rozpoczynającej się iteracji. Wymagania wpisuje się we wspomnianą
wyżej listę (Sprint product backlog).

W drugim spotkaniu biorą udział jedynie wykonawcy i Zarządca Scrum,
którzy ustalają sposób przeprowadzenia prac przy implementacji
wymagań.

Codzienne Spotkania Scrum

(Daily Scrum

meeting) są krótkie, najwyżej 15 minut, mają na
celu motywowanie personelu oraz śledzenie
postępów prac.

W trakcie spotkania omawiane są problemy oraz
planowane są posunięcia z nich wynikające.

W spotkaniach uczestniczy zespół projektantów i
programistów oraz zarządca Scrum.

Spotkanie podsumowujące

(Scrum

Review Meeting) odbywa się
w ostatni dzień trwania iteracji produkcyjnej
(iteracja nie trwa więcej niż 30 dni).

Omawiane są na nim postępy prac oraz
formułowane są wnioski, nowe wpisy do listy
wymagań lub postulowane są generalne
zmiany
w architekturze systemu.

Spotkanie planujące sprint
(max. 8 godzin)



W spotkaniu uczestniczą:



ScrumMaster



Właściciel produktu



Zespół



Dwa etapy:



PIERWSZY

(max. 4 godziny)



Wybór co zostanie zrealizowane podczas
sprintu



DRUGI

(max. 4 godziny)



Rozplanowanie szczegółów zadania

Sprint (30 dni)



Początek: spotkanie planujące sprint



Codzienny SCRUM (max. 15 minut)
Cel: synchronizacja prac zespołu

W spotkaniu uczestniczą:

- ScrumMaster
- Zespół

Odpowiedzi na pytania:



Co zrobiłeś w projekcie od ostatniego spotkania ?



Co planujesz zrobić w projekcie między obecną chwilą, a

kolejnym spotkaniem ?



Jakie przeszkody stoją na drodze realizacji założeń danego

sprintu oraz tego projektu ?



Koniec: przegląd sprintu

Zaległości sprintu



Zaległości sprintu zmienia zespół



Zadania – przydzielony czas
wykonania od 4 do 16 godzin

Zadania, które wykraczają poza
ten czas traktowane są jako
nieodpowiednio zdefiniowane.

Zaległości produktowe



Lista wymagań projektowych o
ustalonych priorytetach wraz szacowanym
czasem zamiany każdego jej elementu na
ukończoną funkcjonalność produktu.



Szacunki wyraża się w dniach i są tym
precyzyjniejsze, im wyżej na liście
priorytetów znajduje się dany element
zaległości produktowych.



Lista ta ewoluuje w kierunku zmian
warunków biznesowych i technologii.

Zaległości produktowe



Na liście znajdują się:



Wymagania funkcjonalne



Wymagania niefunkcjonalne

…wraz z określeniem priorytetów
(ustalane według ważności dla
klienta oraz zależności)

Przegląd sprintu
(max. 4 godziny)



W spotkaniu uczestniczą:



Zespół



ScrumMaster



Właściciel produktu



Ewentualnie udziałowcy



Prezentowanie wykonanych zadań
oraz zastanowienie się co powinno
być następnie zrealizowane.

Retrospekcja sprintu
(max. 3 godziny)



W spotkaniu uczestniczą:



ScrumMaster



Zespół



Skorygowanie prac zespołu tak
by kolejny sprint był bardziej
efektywny i przyjemny

Przebieg SCRUM

Kilka zespołów:
Projekt skalowalny.



Pierwszy zespół robi fundament –
przygotowuje infrastrukturę do
pracy etapowej

Kilka zespołów



Przed przystąpieniem do prac
nowych zespołów muszą być
ustalone m.in.



Zaległości funkcjonalne i
niefunkcjonalne



Zasady komunikacji



Zasady przechowywania kodu



itd.

Zespoły w projekcie
skalowalnym.



Pojedyncze osoby z pierwszego
zespołu dołączane są do zespołów
jako eksperci

Projekty skalowalne –
Scrum Scrumów



Dodatkowe spotkanie



W spotkaniu uczestniczą:



ScrumMaster



Pojedyncze osoby z zespołów

Przebieg taki sam jak przy codziennym

SCRUM

Dokumenty w SCRUM



Zaległości produktowe



Zaległości sprintu



Wykres wypalania

POZIOMO:

-Pozostałe dni

PIONOWO:

- Ile pozostało do wykonania

Używany przy:

- Zaległości sprintu

- Zaległości produktowe

Problemy przy wdrażaniu



Mało informacji np. dla zarządu na

temat przebiegu aktualnego SCRUM

– Co gdy zarząd wymusza dodatkowe

raporty

Przykład dodatkowego raportu

Jako typowe źródła
marnotrawstwa wskazuje:



nieukończoną pracę

Nieukończone oprogramowanie szybko się

dezaktualizuje i z każdym dniem maleje
prawdopodobieństwo, że kiedykolwiek wejdzie
ono do przemysłowej eksploatacji. Do czasu
gdy takie oprogramowanie zostanie
zintegrowane z resztą systemu, pochłania ono
zasoby i stwarza ryzyko finansowe.
Minimalizowanie ilości niedokończonego
oprogramowania, które z jakichś względów nie
zostało uruchomione jest zarówno
ograniczaniem ryzyka jak i redukcją
marnotrawstwa.

... źródła marnotrawstwa:



dodatkowe procesy

Typowym procesem, który nie stanowi wartości dla projektu

jest tworzenie dokumentacji. Zasadnicze pytania w tym
przypadku brzmią – czy klient naprawdę uważa
dokumentację za przydatną i wartościową? Czy jest ona
nam do czegoś potrzebna? A jeśli odpowiedź na któreś z
nich jest twierdząca należy pamiętać o tym aby
generowane dokumenty były krótkie i możliwie ogólne.

Dokumentację na pewno warto tworzyć gdy jest ktoś kto na

nią czeka, na przykład programiści, którzy oczekują od
analityka zdefiniowania przypadków użycia. Ale nawet
wtedy trzeba szukać innych efektywniejszych dróg
przekazywania informacji – na przykład tworzyć testy
akceptacyjne zamiast spisywać wymagania. Należy
również pamiętać o tym aby dokumentować szczegóły
danej cechy dopiero gdy rozpoczyna się iteracja, w której
ma być ona implementowana.

... źródła marnotrawstwa:



dodatkowe cechy

Bardzo często wydaje się, że dodanie kilku nowych cech do

systemu będzie z jakichś względów korzystne.
Programiści mają tendencje do poszerzania systemu o
nowe funkcje choćby po to by sprawdzić jak działają.

Niestety takie działanie musi być uznane za

marnotrawstwo. Każdy fragment kodu w programie musi
przecież zostać napisany, zintegrowany, przetestowany,
a potem musi być utrzymywany. Każdy kawałek kodu
podnosi złożoność systemu i stanowi potencjalne miejsce
wystąpienia błędu.

Z tego punktu widzenia jeśli kod nie jest potrzebny na teraz

to jego tworzenie jest trwonieniem zasobów.

... źródła marnotrawstwa:



przełączanie zadań

Obciążanie ludzi pracą nad kilkoma projektami

jednocześnie jest marnotrawstwem. Za
każdym razem gdy programista przełącza się
między zadaniami w różnych projektach traci
pewną ilość czasu na przemyślenie sobie tego
to co ma do zrobienia i na wejście w rytm
pracy nad nowym zadaniem.

Najszybszą drogą do ukończenia dwóch

projektów jest zrealizowanie najpierw
jednego projektu, a potem drugiego.
Równoległa praca skutkuje częstym
przełączaniem się między zadaniami, a tym
samym powoduje zmarnowanie dużej liczby
czasu.

... źródła marnotrawstwa:



oczekiwanie

Jednym z głównych źródeł marnotrawienia

czasu jest oczekiwanie na to aż coś się
wydarzy. Przykładem są tu opóźnienia w
rozpoczęciu projektu, w tworzeniu
wymagań czy też w testowaniu.
Opóźnienia zmniejszają wartość systemu
dla klienta, a do tego redukują szybkość z
jaką można zareagować na jego potrzeby.

... źródła marnotrawstwa:



przemieszczanie

Pierwszym problemem jest przemieszczanie się ludzi. Chodzi

tu o sytuację, w której programista poszukuje odpowiedzi
na pytanie lub potrzebuje pomocy przy jakimś
technicznym problemie. Jeśli nie jest w stanie uzyskać
jej na miejscu wówczas zmuszony jest do tracenia czasu
na przemieszczanie się w poszukiwaniu osób które będą w
stanie mu pomóc – na przykład przedstawicieli klienta. Do
tego programista traci koncentrację i wybija się z rytmu
pracy. Jest to poważne źródło marnotrawstwa.

Drugi problem to przemieszczanie rozmaitych artefaktów –

na przykład dokumentacji. Każde jej przekazanie od
analityka do projektanta, od projektanta do programisty i
od programisty do testera jest potencjalnym źródłem strat
- dokumentacja z reguły nie zawiera pełnej wiedzy osoby,
która ją przekazuje.

... źródła marnotrawstwa:



defekty

Ilość strat powodowanych przez defekty jest

złożeniem wpływu defektu na system i czasu
przez jaki defekt pozostawał nie wykryty.
Sposobem na redukcję strat powodowanych
przez defekty jest jak najszybsze
ich wykrywanie. Rozwiązaniem są tu praktyki
takie jak testowanie utworzonego kodu,
częste integrowanie i wczesne przekazywanie
kolejnych wydań systemu do eksploatacji.

METODYKA ZWINNA

ASD (Adaptive Software

Development)

Adaptive software development



... bazuje na teorii złożonych systemów adaptujących
się (complex adaptive systems – CAS), która została
wykorzystana przez Briana Arthura i jego kolegów w
instytucie Santa Fe Institute w celu zrewolucjonizowania
sposobu rozumienia fizyki, biologii, ewolucji i ekonomii.



ASD został utworzony przez Jima Highsmitha, który
zauważył że, pomimo iż proces wytwarzania
oprogramowania nie jest liniowy, a więc nie ma
bezpośredniego powiązania pomiędzy przyczyną a
efektem, to jednak są skomplikowane projekty
informatyczne, które odnoszą sukces.



Highsmith stwierdził, że proces tworzenia
oprogramowania można potraktować zgodnie z
teorią CAS, a wspomniane powiązanie przyczyna-
efekt można z powodzeniem zastąpić pojęciem
„wyłaniania się” (ang. emergence).

Adaptive software development



Nie powinno się planować procesu wytwarzania
oprogramowania, ale powinien on się „

wyłaniać

”

na podstawie podejmowanych w ostatniej chwili decyzji
mówiących, co robić dalej. Podejście to jest zgodne z
zasadami zawartymi w Agile Manifesto, które mówią,
że najlepsze architektury, wymagania i projekty powstają
(wyłaniają się) w samoorganizujących się zespołach.
Samoorganizacja pociąga za sobą właśnie wspomniane
„wyłanianie się”.



Adaptive life-cycle, czyli adaptujący się cykl życia, wiąże się
ze zmianami w stylu zarządzania, na przykład, kiedy zachodzą
jakieś przemiany w środowisku danego projektu, osoba
używająca tradycyjnego, deterministycznego procesu będzie
szukała nowego zbioru zasad pozwalających na zdefiniowanie
zależności pomiędzy przyczyną a efektem. W przypadku ASD
osoba taka będzie wiedziała, że zasad takich nie ma.

Fazy w cyklu życia projektu

Adaptive Software

Devleopment
wyróżnia
następujące fazy
w cyklu życia
projektu:



Speculate
(spekulacja)



Collaborate
(współpraca)



Learn (nauka)

Speculate
(przemyślenie, spekulacja)

Planowanie w złożonym środowisku to paradoks. Rezultaty

są w takiej sytuacji nieprzewidywalne.



Spekulowanie, podobnie jak planowanie, dotyczy
definiowania celów, wizji i nakreślenia wymagań dla
produktu.



W procesie spekulowania otwarcie przyznajemy, że
możemy się mylić przy określaniu nawet istotnych
fragmentów projektu. Kiedy dojdzie do niezrozumienia
potrzeb użytkownika, gdy zmieni się technologia lub
konkurencja nas wyprzedzi, prawdopodobieństwo
popełnienia błędu jest bardzo duże.



ASD postuluje nakreślenie tylko ogólnej wizji tego, do
czego powinien zmierzać projekt i umożliwienie
wykorzystywanym mechanizmom dostosowywania się w
trakcie trwania projektu do zachodzących zmian.

Collaborate (współpraca)



ASD nie przewiduje tworzenia planu – nie ma możliwości
kontrolowania projektu w tradycyjny sposób. Znaczący
zbiór obecnie stosowanych praktyk zarządczych staje się
bezużyteczny lub – jest użyteczny tylko dla tych
fragmentów procesu wytwarzania oprogramowania, które
są przewidywalne. Pojęcie współpracy oznacza utrzymanie
równowagi pomiędzy zarządzaniem pracą a tworzeniem
oraz utrzymywaniem środowiska pozwalającego na
współpracę, które jest konieczne dla „wyłaniania się”.



Im bardziej skomplikowany staje się projekt, tym bardziej
szala przechyla się w stronę tego drugiego elementu. Dla
osoby zarządzającej projektem, która utrzymuje
wspomnianą równowagę, istotne są dwie rzeczy.



konieczne jest zdecydowanie, które części projektu są
przewidywalne,



zapewnienie dla nieprzewidywalnych elementów
odpowiedniego środowiska, które umożliwi „wyłanianie się
idei”.

Learn (nauka)



Nauka,

zgodnie

definicją

słownikową

osiąganie doskonałości poprzez doświadczenie. W
środowisku

adaptującym się

nauka dotyczy

zarówno zespołu tworzącego produkt, jak i
klientów. Po zakończeniu każdego cyklu powinni
oni zweryfikować pierwotne założenia projektowe
i wykorzystać

to, co zostało w tym cyklu

wytworzone do wyznaczenia kierunku, w jakim
należy dążyć podczas cyklu następnego. Cykle
powinny być krótkie, tak by zespoły mogły uczyć
się

raczej na małych, niż na dużych błędach, a

ponadto

powinny

również

być

podwójnie

zapętlone, aby umożliwić

naukę

zarówno o

zmianach samego produktu, jak i o zmianach
założeń

METODYKA ZWINNA

eXtreme Programming

METODOLOGIE

ZWINNE

XP - Extreme Programming

Programowanie ekstremalne (e

treme

rogramming) powstało jako próba

zaradzenia problemom związanym z
długimi cyklami dostarczania
oprogramowania
i spadkiem zainteresowania inwestora
zadaniem.

XP charakteryzują:
ewolucyjne podejście do projektowania i
programowania oraz ekstremalnie ścisła
współpraca z odbiorcą.

Zasadą są ekstremalnie krótkie iteracje w
dostarczaniu kolejnych wersji
oprogramowania prowadzące do szybkich
odpowiedzi użytkownika.

Charakterystyka XP

Przy wytwarzaniu oprogramowania
stosuje się programowanie
w parach, ustawiczną przebudowę
(refactoring) kodu źródłowego,
ustawiczną integrację i testowanie
połączonych modułów.

Hasła towarzyszące
projektowaniu XP



gra w planowanie (planning game),



szybkie iteracje,



porozumienie pomiędzy użytkownikiem i
programistami za pomocą metafor,



prostota kodu (brzytwa Ockhama),



ustawiczne testowanie i integracja modułów,



programowanie w parach,



kolektywne posiadanie kodu,



unikanie nadgodzin,



komunikacja pomiędzy programistami poprzez kod
źródłowy



konstrukcja kodu źródłowego wedle zasad
akceptowanych i przestrzeganych w całym zespole.

Jedna z zasad XP głosi, że nie ma
uniwersalnej metody prowadzenia
projektu informatycznego.

Wobec tego praktyki XP powinny być
przystosowywane do aktualnych
potrzeb
i specyfiki projektu.

W cyklu życia projektu XP wyróżnia się fazy:



eksploracji,



planowania,



iteracji wykonawczych,



przygotowania do produkcji,



utrzymania w ruchu,



zakończenia projektu.

Cykl życia w XP

Projektowanie

(oraz programowanie)

ekstremalne

Faza
eksplorac ji

Faza
planowania

Iter acje produkcyjne

ygo

tow

roż

aza

serw

Programowanie w parac h

Regularne
uaktualnienia

Testy

Plany
testo wania

Pro jek-
towanie

Analiza

Testo-
wan ie

Informac ja
z wrotna

Cią gła integ racja
modułów

Uaktualnienia
produkcyjne

Uakt ualnienie
system u

Finalna
wersja
systemu

“

śc

i”

“

śc

i”

ite

Baza kodów
systemu

ło

śc

Ciągły
przegląd

W fazie eksploracji

zespół projektowy zapoznaje się z tematem prac
i pozyskuje podstawowe informacje od użytkownika.

Użytkownik przedstawia sposób użytkowania systemu poprzez
opowiadania („story”), na podstawie których budowany jest
zarys architektury systemu oraz budowana jest lista
funkcjonalności.

W tym czasie projektanci testują wybraną technologię tworząc
niezbędne prototypy oraz zapoznają się z używanymi
narzędziami.

Faza planowania.

Opowiadania przedstawione przez użytkownika
są analizowane
i nadawane są im priorytety.

W porozumieniu z użytkownikiem zestawiana
jest lista funkcjonalności, które mają być
opracowane.

Programiści oceniają czas realizacji zadań i
ustalany jest harmonogram prac i termin
zakończenia prac.

Składa się z jedno lub kilkutygodniowych mini cykli
implementujących kolejne właściwości systemu.

Wykonywane są działania analityczne, projektowe,
kodowanie i testowanie.

Na końcu każdego mini cyklu wykonywane są testy
oprogramowania zaplanowane przez użytkownika.

Faza iteracji wykonawczych

W tej fazie system zawierający uzgodnioną porcję
funkcjonalności jest przygotowywany do wdrożenia.

Pojawiające się uwagi użytkownika są
implementowane lub przeznaczane do implementacji
w następnej wersji oprogramowania.

Wykonywane są dodatkowe gruntowne testy.

Faza przygotowania produkcji

Użytkownik jest wyposażony w działającą wersję
oprogramowania, która wymaga opieki i nadzoru.

Zespół projektowy w tym samym czasie wykonuje
kolejną wersję oprogramowania.

W trakcie pracy z oprogramowaniem odbiorca

formułuje kolejne postulaty dla zespołu projektowego.

Faza konserwacji

Wejście fazę produkcji często pociąga za
sobą zmiany
w zespołach projektantów i wzrost
zatrudnienia.

Wysiłek poświęcany na utrzymanie w
ruchu wersji produkcyjnej wpływa na
zmniejszenie prędkości opracowywania
nowej wersji oprogramowania.

Gdy użytkownik nie jest już zainteresowany dodawaniem
funkcjonalności do oprogramowania, tempo współpracy z
użytkownikiem spada, formułowane wnioski o rozszerzenie
funkcjonalności mają charakter drugorzędny
i często nie są wdrażane z powodów ekonomicznych.

W tej fazie zespół projektowy podejmuje decyzję
o zakończeniu projektu, blokuje zmiany
w architekturze systemu i kodzie źródłowym, opracowuje
dokumentację systemu i projektu, ostateczne wersje instrukcji
użytkownika oraz instrukcje konserwacji.

Zakończenie projektu

XP - charakterystyka



Ewolucyjne podejście do projektowania i
programowania



Praktyka bardzo krótkich cyklów wytwarzania
oprogramowania zmuszająca do szybkich
odpowiedzi klienta



Ciągłe zainteresowanie pracami klienta



Ekstremalnie ścisła współpraca z klientem



nie ma uniwersalnej metody prowadzenia projektu
informatycznego.



praktyki XP powinny być przystosowywane do
aktualnych potrzeb i specyfiki projektu.

eXtreme Programming



Jest to bardzo kontrowersyjny,
zorientowany

obiektowo

model

procesu tworzenia oprogramowania.
„Lekki”, interaktywny i przyrostowy
proces oparty jest na czterech
podstawach:

komunikacji,

prostocie, sprzężeniu zwrotnym i
odwadze.

Extreme Programming

... popiera następujące zwyczaje:



zespół projektowy określa czas, ryzyko i
porządek realizacji prac; zamawiający określa
zakres, datę uruchomienia i priorytety,



projektowanie jest minimalne, gwarantujące
przejście testów,



programowanie w parach – cały kod jest
pisany przez pary programistów pracujących
na jednej stacji roboczej,



testowanie modułów i testy akceptacyjne –
testy są pisane przed kodowaniem,

Zwyczaje Extreme Programming



współdzielenie kodu,



ciągła integracja,



zamawiający jest członkiem zespołu,
odpowiedzialnym za dostarczenie wiedzy z
dziedziny obejmowanej przez oprogramowanie i
testy akceptacyjne,



40-godzinny tydzień pracy, który gwarantuje, że
zespół jest zawsze czujny i sprawny,



niewielkie poprawki, zawierające użyteczną
funkcjonalność,



standardy kodowania, opracowane i stosowane
przez zespół.

Podstawowe zasady

Współpraca z klientami

User stories (historie użytkowników).

Krótkie cykle.

Plan iteracji

Plan dostawy

Testy akceptacyjne.

Programowanie w parach.

Programowanie oparte na testach - TDD (Test
Driven Development).

Wspólna własność (kolektywne kontrolowanie
kodu).

Podstawowe zasady c.d.

Ciągła integracja.

Czterdziestogodzinny tydzień pracy
(stała prędkość).

10.

Otwarta przestrzeń robocza.

11.

Plan gry.

12.

Prosty projekt.

13.

Refaktoryzacja

14.

Metafora

XP - praktyki



Programowanie parami



Ciagłe testowanie



Ciągłe planowanie



Ciągłe integrowanie



Refactoring kodu



Utrzymywanie standardu kodowania



Zbiorowa własność kodu



Prostota rozwiązań

XP – etapy powstania wersji

Podsumowanie



Z punktu widzenia kosztów najważniejsze
elementy XP to –



test driven development,



programowanie w parach i



szybkie wdrażanie fragmentów działającego kodu.



Główne zalety XP mówią, że:



Para programistów pracuje z większą szybkością niż
pojedynczy programista.



Ciągłe sprawdzanie kodu zwiększa jego jakość



Kod wytworzony przez parę programistów ma
zmniejszoną ilość błędów.

METODYKA

ZWINNA Cristal

Jedna ze „zwinnych” metodologii, nazywana Crystal

Dokumentacja

wymagań

systemowych

Planowanie nowej

wersji

systemu

Harmonogra-

mowanie

Polityka jakości,

Standardy,

Role,

Narzędzia,

Działania

Iteracje

Co 1-4

miesiące

Użytkowa

wersja systemu

Równoległość i

przepływ

Monitorowanie

postępów

(punkty

kontrolne i

wersje stabilne)

Opracowanie

i kontrola

rezultatów

Planowanie nowego

cyklu

Metodyka Cristal ma odmiany w zależności od stopnia

krytyczno

projektu (kategoryzowanego poprzez litery

C, D, E, L

– objaśnione dalej) i w zależności od jego

rozmiaru

, mierzonego liczbą projektantów

zaangażowanych w tworzenie projektu.

Kategorie krytyczności projektowanego
systemu:



- Komfortowe (Comfort),



- Zarządzające Finansami

(Discretionary Money),



- Finansowo istotne (Essential Money)



- Krytyczne dla Życia (Life Critical)

Na tej podstawie proponowana jest cała
rodzina metod typu Cristal.
Ich mapa podana jest niżej.

L20

E20

D20

C20

L40

E40

D40

C40

L80

E80

D80

C80

Czysta

Żółta

Pomarań-

czowa

Czerwona

Rozmiar
projektu

Krytyczność

systemu

METODYKA RUP

Rational Unified Process

1998 – pierwsza wersja RUP

Agenda



RUP wprowadzenie



Metodyka RUP’a



Przedstawienie etapów metodyki
RUP



Przedstawienie procesów metodyki
RUP

RUP wprowadzenie



Rational Unified Process jest :



Iteracyjną i przyrostowa metodyka



W pełni konfigurowalną platformą do
obsługi procesu tworzenia
oprogramowania

Metodyka RUP



Jest oparta na doświadczeniach
największych firm w branży
informatycznej



Opiera się na zestawie praktyk:



iteracyjny rozwój, zarządzanie wymaganiami,
architektura komponentowa, modelowanie
wizualne, weryfikacja jakości, zarządzanie zmianami

Cykle



Wytwarzanie oprogramowania
następuje w cyklach:



Cykl początkowy



Cykle ewolucyjne



Cykl życia oprogramowania :



Rozpoczęcie (Inception)



Opracowanie (Elaboration)



Konstruowanie (Construction)



Przekazanie (Transition)

Faza Rozpoczęcia (Inception)



Ustalenie zakresu projektu i
warunków granicznych :



Zakres Projektu



Kryteria sukcesu



Ocenę ryzyka i zasobów (znaną także
jako studium osiągalności - flexibility
study)



Określenie kamieni milowych i dat

Faza Rozpoczęcia c.d.



Wynikiem tej fazy są :



Dokument wizji (Vision)



Model przypadków użycia (10%-20%)



Początkowy zestaw definicji



Przypadek Biznesowy



Dokument podsumowujący studium osiągalności



Plan projektowy (fazy i iteracje)



Model Biznesowy (o ile wymagany)



Prototyp (-typy)

Faza Opracowania



Szczegółowa analiza problemu



Rozwinięcie planu projektowego



Minimalizacja ryzyka



Budowa Prototypów

Faza Opracowania c.d.



Wynikiem tej fazy są :



Kompletny model przypadków użycia (min. 80-
90%)



Dodatkowe wymagania



Opis architektury



Prototyp



Końcowy plan projektu



Specyfikacja procesów



Wstępna wersja podręcznika użytkownika
(opcja)

Faza Konstruowania



Budowa



Rozwój



Integracja



Testowanie

Faza Konstruowania c.d.



Wynikiem tej fazy są :



Produkt zintegrowany z platformą
docelową



Podręcznik użytkownika



Opis bieżącego wydania

Faza Wdrażania



Przekazanie produktu do
użytkownika
(-ów) końcowego (-ych) :



Korekta błędów



Wynikiem tej fazy jest działający
system

Etapy RUP



specyfikacja wymagań (ang.
requirements capture),



analiza wymagań (ang.
requirements analysis),



projektowanie (ang. design),



implementacja (ang.
implementation)



testowanie (ang. test),



konserwacja (ang. deployment).

Fazy



Modelowanie biznesowe



Wymagania



Analiza i projektowanie



Implementacja



Testowanie



Wdrażanie



Konfiguracja i zarządzanie zmianami



Zarządzanie projektem



Określenie środowiska

Modelowanie biznesowe



Analiza struktury i dynamiki
organizacji



Identyfikacja problemów



Identyfikacja procesów biznesowych

Wymagania



Specyfikują wizję systemu, czyli :



Przypadki użycia



Granice systemu



Koszty i Czas wytworzenia



Interfejs użytkownika

Analiza i Projektowanie



Zamiana wymagań w specyfikację
implementacji systemu :



Ustanowienie stabilnej architektury



Przystosowanie projektu do środowiska
implementacji



Uwzględnienie własności systemu

Analiza



Transformacja wymagań do postaci
zbiorów klas i podsystemów w oparciu o:



Przypadki użycia



Wymagania funkcjonalne



Wynikiem jest „idealny” system bez
uwzględnienia ograniczeń środowiska
implementacji i wymagań
niefunkcjonalnych

Projektowanie



Przystosowanie wyników analizy do
wymagań niefunkcjonalnych i
ograniczeń środowiska
implementacji



Optymalizacja systemu



Pełne uwzględnienie funkcjonalności

Artefakty



Główne artefakty fazy Analizy i
Projektowania :



Model Projektowy



Model Analityczny



Interfejsy

Implementacja



Wytworzenie działającej aplikacji na
podstawie modelu z fazy
projektowania.

Testy



Sprawdzenie zgodności z
wymaganiami



Sprawdzenie stabilności działania
aplikacji



„Wyłapanie” błędów

Wdrożenie



Wytworzenie i dostarczenie
oprogramowania do użytkowników
końcowych

Konfiguracja i zarządzanie zmianami



Opis procesu kontroli artefaktów
wytworzonych przez zespół
projektowy



Występujące problemy :



Symultaniczne uaktualnienia



Limitowane zawiadomienia



Duża ilość wersji

Zarządzanie projektem



Główne cele :



Dostarczenie wskazówek
wspomagających planowanie prac



Organizowanie zespołów



Dostarczenie szablonów



W RUP nie ma pełnego przykrycia
procesu zarządzania

Określenie środowiska



Wybór i dostarczenie narzędzi



Określenie środowiska
systemowego

Nowoczesne

metodyki prowadzenia

projektu informatycznego różnią się od
tradycyjnych metod generalną ideą.

Podczas gry tradycyjne metody prowadzenia
projektu w zamyśle sprzedają produkt -
oprogramowanie, nowe techniki zarządzania
sprzedają usługę – opracowanie
oprogramowania.

Posumowanie metodyk
zwinnych

Generalne własności:



Wszystkie opisywane techniki zakładają ścisłą
współpracę z użytkownikiem czy odbiorcą. Właściwie
postuluje się włączenie użytkownika w proces
projektowania oprogramowania (eXtreme Programming).



Sprzedawana jest usługa tworzenia oprogramowania
a nie gotowy produkt -oprogramowanie, tak więc
użytkownik jest tym, kto podejmuje decyzje co i w jakiej
kolejności będzie w projekcie wykonywane.



Istotną wagę przywiązuje się do poprawnego szacowania
kosztów prac, tak by inwestor/użytkownik mógł
świadomie planować swe wydatki na rozwój
oprogramowania.

Własności – ciąg dalszy



Zobowiązuje się wytwórcę oprogramowania do tego, że

każdym swym działaniem powinien udowadniać

inwestorowi efektywne wykorzystanie czasu

i powierzonych mu środków.



Sprzedając usługę programowania rezygnuje się

z zysków z ponownego użycia kodu i modeli

analitycznych, bo prace odniesione są do

niepowtarzalnego projektu. Przy takim założeniu rozległa

dokumentacja projektowa staje się zbędnym kosztem

obciążającym użytkownika i unika się jej.



Uproszczenia dokumentacyjne wymuszają specyficzny

sposób porozumiewania się z użytkownikiem. W trakcie

tworzenia oprogramowania często (na bieżąco) zadaje

się mu pytania i prośby o potwierdzenie dotyczące

niewielkiego zakresu funkcjonalności. Stąd wynikają

inkrementalny sposób dostarczania oprogramowania

oraz krótkie iteracje implementacyjne (XP, Scrum).

Własności - koniec



Nie specyfikuje się formalnych punktów

kontrolnych w projekcie - nie są one potrzebne,

gdyż zakończenie każdej iteracji jest punktem

kontrolnym samym w sobie. Z drugiej strony

wprowadzenie sformalizowanych punktów

kontrolnych nie we wszystkich technikach jest

możliwe.



Sekwencyjna realizacja wymagań użytkownika

powoduje częste zmiany w architekturze

systemu i konieczność przebudowy kodu.

W nowych metodykach zadanie przebudowy

kodu postrzega się nie jako wyjątek, lecz jako

regułę.

Rozwój metodyki
projektowania SI w kierunku
metod „zwinnych”

Process Scrum
(Schwaber, 1995,

Schwaber i
Beedle, 2001)

Metodologia projektowania
systemów zmiennych w
czasie
(DSDM, 1995)

Metodologie Crystal
Cockburn, 1998;2001)

Programowanie ekstremalne
(XP) (Beck, 1999)

Szybkie programowanie Internetowe
(Cusumano and Yoffie, 1999;
Baskerville et al., 2001;
Baskerville and Pries-Heje, 2001)

Programowanie
Pragmatyczne (PP)
(Hunt and Thomas,
2000)

Adaptacyjny rozwój
oprogramowania (ASD)
(Highsmith, 2000)

Projektowanie zorientowane
na właściwości (FDD)
(Palmer and Felsing. 2002)

Modelowanie Agile (AM)
(Ambler, 2002)

Ametodologiczny rozwój
oprogramowania
(Baskerville, 1992;
Truex and al., 2001)

Ruch Open
Source (OSS)

Projektowanie systemów
informacyjnych
w nowo powstajacych
organizacjach
(Truex et al., 1999)

Podejście “Synch-and-stabilize”
(Microsoft)
(Cusumano and Selby, 1995;
1997)

Technologie
internetowe

Model spiralny
(Boehm, 1986)

Gra w opracowanie
nowego produktu
(Takeuchi and Noraka, 1986

Proces RUP
(Rational Unified Process)
Kruchten, 2000)

Manifest agile
(Beck et. Al., 2001

Język UML

Opracowywanie oprogramowania
metodą “RADical” (Bayer
and Highsmith, 1994)

Metody RAD
(Rapid application
development )
(e.g., Martic, 1991)

Podejścia obiektowe

Ewolucyjne cykle życia
(Gilb, 1988)

Prototypowanie
(e.g. Lantz, 1986)

2000

1999

Skala dojrzałości modeli
tworzenia SI pokazuje, że
metody „zwinne” można
stosować głównie dla niezbyt
dużych systemów

Działania

ad-hoc

(bez planu)

Modele z

punktami

kontrolnymi

sterowane

ryzykiem

Sztywne

działania

kontraktowe

Adaptacyjny

rozwój

oprogramowania

Metody agile

Standard modelu dojrzałości procesu tworzenia

oprogramowania (Standard CMM)

Modele z

punktami

kontrolnymi

sterowane

planem

PROJEKTOWANIE Z

UŻYCIEM

WIELOKROTNYM

Spostrzeżenia…



większości

dyscyplin

inżynieryjnych

proces projektowania jest oparty na użyciu

wielokrotnym komponentów.



Podstawą projektów są komponenty, które

wypróbowano i przetestowano w innych

systemach.



Obecnie powszechnie uważa się, że w

wypadku

tworzenia

oprogramowania

potrzebne

jest

podobne

podejście.

Oprogramowanie powinno być uważane za

składnik majątku. Użycie wielokrotne tego

składnika

majątku

jest

zasadniczym

warunkiem zwiększenia stopy zwrotu z

inwestycji w jego tworzenie.

Projektowanie z użyciem
wielokrotnym - problem

Jak w procesie
projektowania systemu
oprogramowania można
ponownie wykorzystać
istniejące
oprogramowanie?

Cele



Znać

korzyści

wynikające

użycia

wielokrotnego komponentów programowych

oraz związane z nim kłopoty, które możesz

napotkać;



Znać

różne rodzaje komponentów, które

można użyć

wielokrotnie, oraz procesy

projektowania z użyciem wielokrotnym;



Rozumieć

pojęcie

rodziny

programów

użytkowych

wiedzieć,

dlaczego

takie

rodziny są

efektywnym sposobem użycia

wielokrotnego oprogramowania;



Wiedzieć, dlaczego wzorce są abstrakcjami

wysokiego poziomu, które sprzyjają użyciu

wielokrotnemu

projektów

tworzeniu

obiektowym.

Projektowanie z użyciem wielokrotnym
polega na:



Tworzeniu i stosowaniu komponentów



Użyciu rodziny programów użytkowych



Stosowaniu wzorców projektowych

Używane wielokrotnie elementy
oprogramowania



Użycie wielokrotne systemów programów użytkowych.



Można ponownie użyć

cały system programów

użytkowych przez włączenie go w niezmienionej
postaci do innych systemów albo budowę rodziny
programów użytkowych działających na różnych
platformach

lub

dostosowanych

potrzeb

konkretnych użytkowników.



Użycie wielokrotne komponentów.



Można wielokrotnie używać komponentów programu
użytkowego

mających

różne

rozmiary,

podsystemów do pojedynczych obiektów.



Użycie wielokrotne funkcji.



Można wielokrotnie użyć komponenty programowe,
takie jak pojedyncze funkcje matematyczne.

Wymagania stawiane projektowaniu i
budowaniu oprogramowania z użyciem
wielokrotnym



Musi

istnieć

możliwość

znalezienia

odpowiedniego

komponentu

użycia

wielokrotnego.



Osoba ponownie używająca komponent musi być
przekonana, że będzie on działał zgodnie ze
specyfikacją i będzie niezawodny.



Komponenty muszą mieć dokumentację, która
pomoże osobie pragnącej je wykorzystać

zrozumieniu ich i zaadaptowaniu do nowych
zastosowań.

Praktyka



Użycie

wielokrotne

systemów

programów

użytkowych praktykuje się już od wielu lat –
firmy budujące oprogramowanie implementują
swoje

systemy

wielu

maszynach

dostosowują je do rozmaitych środowisk.



Użycie wielokrotne funkcji

również jest uznane i

występuje w postaci standardowych bibliotek
funkcji użycia wielokrotnego, takich jak biblioteki
matematyczne i graficzne.

Zalety użycia wielokrotnego



Zwiększona niezawodność



Zmniejszone zagrożenie procesu



Efektywne wykorzystanie
specjalistów



Zgodność ze standardami



Przyspieszone tworzenie aplikacji

Koszty i kłopoty



Zwiększone koszty pielęgnacji



Brak wspomagania narzędziowego



Syndrom „nie wymyślono tutaj”



Prowadzenie biblioteki
komponentów



Znajdowanie i adaptowanie
komponentów użycia wielokrotnego

Formy projektowania z użyciem
wielokrotnym



Generatory komponentów



Zręby programów użytkowych -
użycie wielokrotne produktów
COTS-rodziny programów
użytkowych



Wzorce projektowe

Generowanie programów z użyciem
wielokrotnym



Polega

ono

umieszczaniu

wielokrotnie

używanej

wiedzy

systemie

generowania

programów, który może posługiwać się językiem
specyficznym dla dziedziny zastosowania.



W opisie programu użytkowego w abstrakcyjny
sposób określa się, które komponenty użycia
wielokrotnego maja być wykorzystane, jak maja
być połączone i jakie maja mieć parametry.



Na podstawie tej informacji można wygenerować
działający system oprogramowania.

Użycie wielokrotne oparte na
generatorze

Generator programów

Wygenerowany program

Wiedza o dziedzinie

zastosowania

Wiedza o dziedzinie

zastosowania

Baza danych

Opis programu

użytkowego

Typy generatorów programów



Generatory programów użytkowych do
przetwarzania danych gospodarczych.



Generatory analizatorów składniowych
do przetwarzania języków.



Generatory kodu w narzędziach CASE.

Tworzenie komponentowe



Tworzenie komponentowe albo komponentowa inżynieria
oprogramowania pojawiła się

we wczesnych latach

dziewięćdziesiątych XX wieku w postaci podejścia do
budowania

systemów

oprogramowania

użyciem

wielokrotnym.



Przyczyną

jej powstania był

zawód, że tworzenie

obiektowe nie doprowadziło do szerokiego stosowania
użycia wielokrotnego, jak się wcześniej spodziewano.



Poszczególne klasy obiektów były zbyt szczegółowe i
specyficzne.



Musiały być dowiązane do programu użytkowego w czasie
kompilacji lub konsolidacji systemu.

Tworzenie komponentowe



Do ich wykorzystania była potrzebna szczegółowa wiedza,
co zwykle oznaczało konieczność udostępnienia kodu
źródłowego.



Powodowało

trudne

problemy

sprzedażą

komponentów na rynku.



Wbrew

wczesnym

optymistycznym

przewidywaniom

nigdy nie powstał znaczący rynek pojedynczych obiektów.

Komponenty



Postrzeganie komponentu jako dostawcy usług
dotyczy

dwóch

istotnych

charakterystyk

komponentu użycia wielokrotnego:



Komponent jest niezależnym wykonywalnym
bytem. Kod źródłowy nie jest dostępny, a
zatem komponentu nie kompiluje się z innymi
komponentami systemu.



Komponenty

publikują

swój

interfejs.

Wszystkie interakcje odbywają się przez ten
interfejs.

Interfejs

komponentu

jest

zapisywany

kategoriach

parametryzowanych

operacji.

Jego

wewnętrzny stan nigdy nie jest ujawniany.

Interfejsy komponentu

Komponent

Interfejs wymagany Interfejs oferowany

Interfejsy komponentów



Interfejs oferowany



Definiuje się

usługi oferowane

przez ten komponent.



Interfejs wymagany



Określa się, jakie usługi muszą
być

dostępne

systemie

używającym tego komponentu.
Jeśli nie są one oferowane, to
komponent nie będzie działał.

Komponent usług drukarskich

Komponent usług

drukarskich

PodajPlikOpisu

Interfejsdrukarki

Drukuj

PodajStanKolejki

Usuń

Przekaż

Rejestruj

Wyrejestruj

Interfejs wymagany Interfejs oferowany

Poziomy abstrakcji komponentów



Abstrakcja funkcyjna.



Komponent jest implementacją jednej funkcji, np.
matematycznej.



Przypadkowe grupowanie.



Komponent jest grupą luźno powiązanych bytów.



Abstrakcja danych



Komponent jest abstrakcją danych lub klasą obiektowego
języka programowania.



Abstrakcja grupowa.



Komponent jest grupą powiązanych klas, które działają
razem.



Abstrakcja systemowa.



Komponent jest całym samodzielnym systemem.

Tworzenie komponentowe



Tworzenie komponentowe można zintegrować z
procesem budowania systemu przez dodanie
specyficznych czynności związanych z użyciem
wielokrotnym.



Projektant systemu buduje projekt na wysokim
poziomie

abstrakcji

specyfikuje

jego

komponenty.



specyfikacje

służą

poszukiwania

komponentów użycia wielokrotnego.



Czynność

tę

można

dodać

poziomie

architektonicznym lub na poziomie bardziej
szczegółowym.

Przykładowy proces ponownego
użycia komponentów

Wyspecyfikuj

komponenty

Wyspecyfikuj

komponenty

Zaprojektuj

architekturę

systemu

Zaprojektuj

architekturę

systemu

Poszukaj

komponentów

użycia

wielokrotnego

Poszukaj

komponentów

użycia

wielokrotnego

Przyłącz

znalezione

komponenty

Przyłącz

znalezione

komponenty

Przykładowy proces ponownego
użycia komponentów

Projektowanie

architektoniczne

Projektowanie

architektoniczne

Poszukaj

komponentów użycia

wielokrotnego

Poszukaj

komponentów użycia

wielokrotnego

Zaprojektuj system

korzystając

z komponentów

użycia wielokrotnego

Zaprojektuj system

korzystając

z komponentów

użycia wielokrotnego

Naszkicuj

wymagania

systemowe

Naszkicuj

wymagania

systemowe

Poszukaj

komponentów użycia

wielokrotnego

Poszukaj

komponentów użycia

wielokrotnego

Na podstawie wyników

poszukiwań zmień

wymagania

Na podstawie wyników

poszukiwań zmień

wymagania

Trudności przy tworzeniu
komponentowym



Kwestia pielęgnacji i ewolucji. Kod źródłowy
komponentów jest zwykle dostępny. W takiej
sytuacji,

gdy

program

użytkowy

wymaga

modyfikacji,

nie

możliwości

zmiany

komponentu mającej na celu odzwierciedlenie
tych wymagań.



W tej fazie zmiana wymagań tak, by pasowały do
istniejących

komponentów,

nie

jest

zwykle

możliwa, gdyż

program użytkowy już

jest

wykorzystywany.



Trzeba więc dodatkowej pracy nad ponownym
użyciem komponentów i w miarę upływu czasu
powoduje to zwiększenie kosztów pielęgnacji.



Tworzenie

komponentowe

umożliwia

jednak

szybsze dostarczanie oprogramowania, firmy
mogą więc zaakceptować te wyższe koszty w
odległej przyszłości.

Zręby programów użytkowych



Zręby (lub zręby programów użytkowych) są
projektami podsystemów składających się

kolekcji klas abstrakcyjnych i klas konkretnych
oraz interfejsu między nimi.



Poszczególne

części

systemu

programów

użytkowych implementuje się

przez dodanie

komponentów

opracowanie

konkretnych

implementacji klas abstrakcyjnych zrębu.



Zręby rzadko są programami użytkowymi.

Klasy zrębów



Zręby infrastruktury systemów.



Wspomagają

tworzenie

infrastruktury

systemów, takiej jak komunikacja, interfejsy
użytkownika i kompilatory.



Zręby integracji śródprogramów.



Składają

się

zbioru

standardów

związanych z nimi klas obiektów, które
wspomagają

komunikację

komponentów i

wymianę informacji.



Zręby zastosowań przemysłowych.



Dotyczą specyficznych dziedzin zastosowań,
takich jak telekomunikacja lub finanse.

Rozszerzanie zrębów



Rozszerzenie zrębu może polegać
na dodaniu konkretnych klas, które
dziedziczą

operacje

klasach

abstrakcyjnych zrębu.



Dodatkowo

można

zdefiniować

funkcje wywołane zwrotnie.



Są to metody, które wywołuje się w
odpowiedzi

zdarzenia

rozpoznane przez zrąb.

Zrąb Model-Widok-Koordynator



Po raz pierwszy przedstawiono go w latach
osiemdziesiątych XX wieku jako podejście do
projektowania

GUI,

który

obejmuje

wiele

przedstawień obiektów i różne style interakcji z
każdym z tych przedstawień.



Zrąb MVC pomaga w prezentacji danych na różne
sposoby i odrębne oddziaływanie z każdą z nich.



Gdy

dane

są

modyfikowane

przez

jedna

prezentację, wszystkie inne są aktualizowane.

Zrąb Model-Widok-Koordynator

Stan widoku

Metody widoku

Stan modelu

Metody modelu

Stan koordynatora

Metody koordynatora

Zapytania

i aktualizacje

modelu

Modyfikacje

modelu

Komunikaty o modyfikacji

widoku

Użycie wielokrotne produktów
COTS („komercyjne z półki”)



Podejście produktów COTS (Commercial-Off-The-Shelf
– komercyjne z półki) może być zastosowane do
każdego komponentu oferowanego przez zewnętrznego
dostawcę.



Zwykle używa się

go jednak tylko w wypadku

produktów będących systemami oprogramowania.



Od wielu lat wielokrotnie używano niektórych rodzajów
systemów COTS. Systemy baz danych są

chyba

najlepszym tego przykładem.

Problemy z integracją systemów COTS



Brak kontroli nad sterowaniem i efektywnością.



Chociaż

z opublikowanych interfejsów produktu może

wynikać, że ma on wymagane udogodnienia, mogą być one
niewłaściwie zaimplementowane lub mogą działać wolno.



Kłopoty ze współdziałaniem systemów COTS.



Skłonienie produktów COTS do współpracy jest czasem
trudne, ponieważ każdy z nich przyjmuje inne założenia o
tym, jak należy go używać.



Brak panowania nad ewolucją systemu.



Dostawcy produktów COTS podejmują własne decyzje o
zmianach systemu w odpowiedzi na żądania rynku.

Problemy z integracją systemów COTS



Wspomaganie przez dostawców COTS.



Zakres wspomagania oferowany przez dostawców COTS
może być

rozmaity. Są

to systemy z półki, więc

wspomaganie

dostawcy

jest

szczególnie

ważne,

gdy

pojawiają

się

kłopoty, ponieważ

programiści nie mają

dostępu do kodu źródłowego i szczegółowej dokumentacji
systemu.

Tworzenie komponentów użycia
wielokrotnego



Komponenty użycia wielokrotnego są specjalnie
budowane z istniejących komponentów, które
ponownie wykorzystano w przypadkowy sposób.



Różne cechy komponentu świadczą o jego zdatności do
użycia wielokrotnego:



komponent powinien odzwierciedlać stabilną
abstrakcję dziedzinową



komponent musi ukrywać sposób reprezentacji
swoich danych i oferować operacje umożliwiające
odczyt i aktualizację jego stanu



komponent powinien być tak niezależny, jak to
tylko jest możliwe



wszystkie wyjątki powinny być częścią interfejsu
komponentu.

Problemy



W wielu obecnie dostępnych systemach istnieją duże
fragmenty

kodu,

które

implementują

abstrakcje

dziedzinowe, ale nie mogą być wykorzystane jako
komponenty.



Przyczyna leży w tym, że nie opakowano ich zgodnie z
modelem z jasno określonymi interfejsami wymaganym
i oferowanym.



Uczynienie z nich komponentów użycia wielokrotnego
zwykle wymaga zbudowania osłony.



Osłona ukrywa złożoność schowanego kodu i oferuje
zewnętrzne usługi.

Uzdatnianie komponentów



Między zdatnością do użycia wielokrotnego a użytecznością
komponentu występuje nieuchronny konflikt.



Uzdatnienie komponentu do użycia wielokrotnego pociąga
za sobą

zaoferowanie bardzo ogólnego interfejsu z

operacjami obsługującymi rozmaite sposoby użycia tego
komponentu.



Budowa użytecznego komponentu obejmuje zaoferowanie
prostego, minimalnego interfejsu, który jest łatwy do
zrozumienia.



Zdatność do użycia wielokrotnego zwiększa złożoność, a
zatem zmniejsza zrozumiałość komponentu.



Inżynierom jest więc trudno zdecydować, kiedy i jak
wielokrotnie używać komponentu.



Projektanci komponentów użycia wielokrotnego muszą
zatem wypracować

kompromis między ogólnością

zrozumiałością.

Proces uzdatniania komponentów

Inicjowanie
komponentu

Generalizacja

nazw

Generalizacja

operacji

Generalizacja

wyjątków

Certyfikacja

komponentów

Komponent

uzdatniony

Rodziny programów użytkowych



Rodzina programów użytkowych albo linia produktów
jest zbiorem powiązanych programów użytkowych,
które mają wspólną architekturę charakterystyczną dla
dziedziny.



Poszczególne programy użytkowe są jednak na swój
sposób wyspecjalizowane.



Wspólny rdzeń rodziny programów użytkowych jest za
każdym razem ponownie używany, gdy jest potrzebny
nowy program użytkowy.



Tworzenie nowego programu może polegać

napisaniu dodatkowych komponentów i adaptacji
niektórych komponentów programu użytkowego tak,
aby sprostać nowym oczekiwaniom.

Rodzaje specjalizacji rodziny
programów użytkowych



Specjalizacja platformowa.



Polega na opracowaniu innych wersji programu
użytkowego na różne platformy. Różne wersje
programu mogą działać na przykład na platformy
Windows NT, Solaris i Linux.



Specjalizacja konfiguracyjna.



Polega na opracowaniu innych wersji programu
użytkowego do obsługi różnych urządzeń
zewnętrznych.



Specjalizacja funkcjonalna.



Polega na opracowaniu innych wersji programu
użytkowego dla klientów z różnymi wymaganiami.

Uniwersalny system inwentaryzacji
zasobów

User

ccess

Pr g

access

Baza danych o zasobach

Dostęp użytkownika

Usuwanie

Dodawanie

Dostęp programowy

Specyfikacje raportów

Specyfikacje ekranów

Opisy zasobów

Raporty

Administracja

Przeglądanie

Poszukiwanie

Systemy inwentaryzacyjne



Takie systemy muszą

oferować

podstawowe

udogodnienia, takie jak dodawanie zasobu do
spisu, usunięcie zasobu ze spisu, przeglądanie i
wyszukiwanie w spisie oraz tworzenie raportów.



Można więc tak zaprojektować

architekturę

systemy inwentaryzacyjnego, aby stał się rodziną
programów użytkowych, której każdy członek
służy do obsługi innych rodzajów zasobów.

Architektura



Osiągnięcie

znaczącej

zdatności

użycia

wielokrotnego

wymaga

zaprojektowania

architektury, w której zasadnicze udogodnienia
systemowe będą

oddzielone od szczegółowej

informacji

zasobach,

które

mają

być

inwentaryzowane i od dostępu użytkownika do
tych informacji.



Architektura może spełniać te wymagania dzięki
zastosowaniu architektury warstwowej, w której
warstwa szczegółów zawiera opisy zasobów,
wyświetlane ekrany i tworzone raporty.



Wyższe warstwy systemu korzystają

z tych

opisów i nie obejmują wpisanej na sztywno
informacji

zasobach.

Różne

systemy

inwentaryzacyjne powstają przez modyfikację tej
warstwy opisowej.

System biblioteczny

Baza danych o zasobach

Dostęp użytkownika do biblioteki

Przeglądanie

Poszukiwanie

Usuwanie

Dodawanie

Wypożyczenie

Raporty

Administracja

Zwrot

Użytkownicy

Specyfikacje raportów

Specyfikacje ekranów

Opisy zasobów

System biblioteczny



Można również

dodawać

do systemu nową

funkcjonalność

przez

wprowadzanie

nowych

modułów do warstw systemu.



Dodano nowe udogodnienia do pożyczania i
zwracania

zasobów

oraz

umożliwiania

rejestracji użytkowników systemu.



W tym wypadku nie jest potrzebny dostęp
programowy, a najwyższa warstwa systemu musi
obsługiwać jedynie dostęp do użytkownika.

Tworzenie członka rodziny

Wydobądź

wymagania

uczestników

Wydobądź

wymagania

uczestników

Wybierz najbardziej

odpowiedniego

członka rodziny

Wybierz najbardziej

odpowiedniego

członka rodziny

Zaadaptuj

istniejący system

Zaadaptuj

istniejący system

Dostarcz nowego

członka rodziny

Dostarcz nowego

członka rodziny

Renegocjuj
wymagania

Tworzenie członka rodziny



Określ wymagania uczestników



Wybierz najbardziej odpowiedniego
członka rodziny



Renegocjuj wymagania



Zaadoptuj istniejący system



Dostarcz nowego członka rodziny

WZORCE

PROJEKTOWE

Wzorce projektowe



Starając

się

ponownie

użyć

komponent

wykonywalny,

nie

uchronimy

się

przed

ograniczeniami wynikającymi ze szczegółowych
decyzji projektowych, podjętych przez osoby
implementujące ten komponent.



Jeśli te decyzje projektowe nie są zgodne z
przyjętymi

przez

nas

szczegółowymi

wymaganiami, to ponowne użycie komponentu
jest niemożliwe albo prowadzi do istotnego
zmniejszenia efektywności systemu.



Jednym ze sposobów radzenia sobie z ta kwestią
jest użycie wielokrotne bardziej abstrakcyjnych
projektów,

które

nie

obejmują

szczegółów

implementacyjnych.



Obecnie to podejście do użycia wielokrotnego
przybrało postać wzorców projektowych.

Elementy wzorca projektowego



Nazwa Spełniająca funkcję znaczącego odsyłacza
do wzorca.



Opis rodzaju problemu, w którym opisuje się
części rozwiązania projektowego, ich związki i
zobowiązania.



Wyjaśnienie konsekwencji zastosowania wzorca,
tzn. wyników końcowych i niezbędnych
kompromisów.

Wiele widoków

A B C D

Obserwator 1

Obserwator 2

Przedmiot

A : 40

B : 25
C : 15

D : 20

Przedmiot

A : 40

B : 25
C : 15

D : 20

Przykład wzorca Obserwator



Nazwa.



Oddziela wyświetlanie stanu obiektu od samego
obiektu.



Opis problemu.



W wielu przypadkach należy udostępnić wiele
prezentacji pewnej informacji o stanie, np.
prezentacji tabelarycznej i graficznej.

Przykład wzorca Obserwator



Opis rozwiązania.



Strukturę wzorca pokazano na rysunku. Są tam dwa
obiekty abstrakcyjne: Przedmiot i Obserwator oraz
dwa obiekty konkretne: PrzedmiotKonkretny i
ObserwatorKonkretny, które dziedziczą atrybuty
swoich obiektów abstrakcyjnych.



Konsekwencje.



Przedmiot zna jedynie abstrakcyjnego Obserwatora,
ale nie zna szczegółów klasy konkretnej. Wzajemne
uzależnienie tych obiektów jest więc minimalne.

Wzorzec Obserwator

Przedmiot

Podłącz (Obserwator)
Odłącz (Obserwator)
Informuj ()

Obserwator

Aktualizuj ()

for all o in obserwatorzy

o -> Aktualizuj ()

for all o in obserwatorzy

o -> Aktualizuj ()

stanObserwatora=

przedmiot -> PodajStan ()

ObserwatorKonkretny

Aktualizuj ()

stanObserwatora

Przedmiot konkretny

PodajStan ()

stanPrzedmiotu



Projektowanie z użyciem wielokrotnym polega na
projektowaniu

oprogramowania

zgodnie

istniejącymi

przykładami

dobrych

projektów

wykorzystaniu komponentów programowych tam,
gdzie są potrzebne.



Korzyści z użycia wielokrotnego to niższe koszty,
szybsze

tworzenie

oprogramowania

mniej

zagrożeń. Przez wykorzystanie wiedzy specjalistów
do budowania komponentów użycia zwiększa się
niezawodność systemu, a specjaliści są wydajniejsi.

Główne tezy



Tworząc

komponentowo,

polegamy

komponentach

„czarnych

skrzynkach”

jasno

określonymi interfejsami wymaganym i oferowanym.
Rodzaje

komponentów,

które

można

użyć

wielokrotnie, obejmują funkcje, abstrakcje danych,
zręby i całe systemy programów użytkowych.



Użycie wielokrotne produktów COTS polega na
wykorzystaniu wielkich systemów z półki. Takie
systemy maja mnóstwo funkcjonalności. Ich użycie
wielokrotnie może znacząco zmniejszyć koszty i czas
tworzenia.

Główne tezy



Komponenty programowe, które zaprojektowano z
myślą

użyciu

wielokrotnym,

powinny

być

niezależne,

odzwierciedlać

stabilne

abstrakcje

dziedzinowe i oferować dostęp do swego stanu przez
operacje interfejsu oraz nie obsługiwać samemu
swoich wyjątków.



Rodziny

programów

użytkowych

zawierają

powiązane programy użytkowe, które zbudowano na
podstawie co najmniej jednego programu bazowego.
Uniwersalny

system

jest

adoptowany

specjalizowany

tak,

aby

spełnił

konkretne

wymagania dotyczące funkcjonalności, docelowej
platformy lub konfiguracji działania.

Główne tezy



Wzorce

projektowe

abstrakcje

wysokiego

poziomu, będące dokumentacją udanych rozwiązań
projektowych. Są podstawowym sposobem użycia
wielokrotnego projektów w tworzeniu obiektowym.
Opis wzorca powinien obejmować nazwę wzorca,
opis problemu i rozwiązania oraz wyjaśnienie
wyników

kompromisów

związanych

stosowaniem wzorca.

Czym są wzorce projektowe?

„Wzorzec projektowy pozwala uczyć się na sukcesach innych

zamiast nauki na własnych błędach”

(Mark Johnson)



Sprawdzone rozwiązania



efektywność



Najlepsze projekty



jakość



Dobre praktyki



skalowalność

Czym są wzorce projektowe?



„Opisem komunikujących się obiektów i klas, które są
specjalnie wykonane, aby rozwiązać ogólny problem przy
dokładnie określonym kontekście”

(GangOfFour, 1994)



„Powracającym rozwiązaniem zagadnień projektowych, z
którymi wciąż się spotykamy”

(Alpert, 1994)



„Zbiorem reguł opisujących, w jaki sposób osiągnąć
pewne cele w dziedzinie programowania”

(Pree, 1994)

Czym są wzorce projektowe?

„Każdy wzorzec opisuje problem, który ciągle na nowo

pojawia się w naszym otoczeniu i opisuje rdzeń jego
rozwiązania w taki sposób, że można go używać milion
razy i nigdy w ten sam sposób.”

(Christopher Alexander)

Elementy wzorca



Nazwa wzorca



Odzwierciedla problem, rozwiązanie i konsekwencje
danego wzorca



Problem



Opisuje zagadnienie i kontekst wystąpienia wzorca



Rozwiązanie



Opisuje elementy tworzące projekt, ich relacje,
odpowiedzialności oraz współpracę



Konsekwencje



Rezultaty zastosowania wzorca – korzyści i straty

Po co nam wzorce?



Zapobiegają ponownemu wymyślaniu kodu
zaprojektowanemu już przez kogoś innego



Zmniejszają liczbę popełnionych błędów



Zapewniają kod łatwo rozszerzalny



Ułatwiają zrozumienie kodu



Ułatwiają komunikację w zespole



Nazwa identyfikuje wzorzec

Podział wzorców



Konstrukcyjne



wykorzystuje się je do pozyskania obiektów zamiast bezpośredniego
tworzenia instancji klasy



programy zyskuj

na elastyczności, gdyż można decydować, jaki typ

obiektu ma zostać utworzony w danym przypadku



Strukturalne



pomagają łączyć obiekty w większe struktury



Behawioralne



charakteryzują sposób, w jaki klasy lub obiekty oddziaływują i
dzielą odpowiedzialności



pomagają definiować przepływ danych w złożonym programie

Katalog wzorców

Przeznaczenie

Konstrukcyjne

Strukturalne

Behawioralne

Zakres

Klasa

Metoda wytwórcza

Adapter

Interpreter
Metoda szablonowa

Obiekt

Budowniczy
Fabryka abstrakcyjna
Prototyp
Singleton

Adapter
Most
Kompozyt
Dekorator
Fasada
Pełnomocnik
Pyłek

Łańcuch zobowiązań
Polecenie
Iterator
Mediator
Pamiątka
Obserwator
Stan
Strategie
Odwiedzający

Sposób omawiania



Nazwa



Przeznaczenie



Co robi? Jakich zagadnień projektowych dotyczy?



Uzasadnienie stosowania



Problem projektowy wraz z rozwiązaniem



Stosowalność



Kiedy wybrać dany wzorzec projektowy?



Struktura (uczestnicy, współpraca)



Omówienie uczestników oraz ich współpracy przy pomocy
diagramów



Konsekwencje



Co zyskujemy, a co tracimy wybierając dany wzorzec?



Przykłady zastosowania

Dekorator

Przeznaczenie



dynamicznie dołącza do obiektów dodatkowe
zobowiązania



zapewnia elastyczną alternatywę dla tworzenia podklas
w celu rozszerzania funkcjonalności

Dekorator

Uzasadnienie stosowania



Czasem chcemy dołączyć pewne zobowiązania do
pojedynczego obiektu (nie do całej klasy)



Pakiet narzędziowy do tworzenia interfejsów użytkownika
powinien np. umożliwiać dodanie do każdego składnika
takich elementów jak ramki, czy paski przewijania



Rozwiązania:



dziedziczenie ramki, dziedziczenie przewijania (statyczne)



zagnieżdżenie obiektów – otoczka = dekorator

Dekorator

Zagnieżdżenie to może być rekurencyjne:

Dekorator

Aby to osiągnąć musimy zbudować strukturę klas:

Dekorator

Stosowalność



aby dynamicznie i w przezroczysty sposób dodawać
zobowiązania do pojedynczych obiektów



w wypadku zobowiązań które mogą być cofnięte



Gdy rozszerzanie przez definiowanie podklas jest
niepraktyczne (dużo niezależnych rozszerzeń które przy
próbie uwzględnienia każdej ich kombinacji prowadzą do
ogromnej liczby podklas)

Dekorator

Struktura

Dekorator



Uczestnicy



Komponent (KomponentWizualny)



Definiuje interfejs obiektów, do których można dynamicznie
dołączać zobowiązania



KomponentKonkretny (WidokTekstowy)



Definiuje obiekt, do którego można dołączać zobowiązania



Dekorator



Zarządza odwołaniem do obiektu Komponent i definiuje
interfejs dopasowany do interfejsu Komponentu



DekoratorKonkretny (DekoratorZRamkami,
DekoratorZSuwakiem)



Dodaje zobowiązania do komponentu

Dekorator



Współpraca



Dekorator przesyła żądania do swojego obiektu
Komponent



Może wykonywać dodatkowe operacje przed lub po
przesłaniu żądania

Dekorator

Konsekwencje



większa elastyczność niż przy stosowaniu statycznego
dziedziczenia

(dodawanie, usuwanie dekoratorów, podwójna ramka)



unikanie przeładowanych właściwościami klas na szczycie
hierarchii



„płać za to, czego potrzebujesz”, zamiast uwzględniać wszystkie
przewidywane własności przy projektowanie klasy zasadniczej



łatwiejsza rozszerzalność (dodanie dekoratora)



Dekorator i jego komponent nie są identyczne (nie można
polegać na sprawdzaniu identyczności obiektów)



Projekt zawiera wiele małych obiektów różniących się nie
zachowaniem, a sposobem połączenia



może być trudne w zrozumieniu

Dekorator

Przykłady



Pakiety narzędziowe do tworzenie interfejsów
użytkownika



Strumienie

Strumień *strumień = new StrumieńKompresujący(

new ASCII7Strumień(
new StrumieńPlikowy(„nazwaPliku”)));

Fasada

Przeznaczenie



zapewnia jednolity interfejs dla podsystemu o wielu
interfejsach



interfejs wyższego poziomu

Fasada

Uzasadnienie stosowania



Typowym zadaniem projektowym jest sprowadzenie do
minimum zależności i komunikacji między modułami



Możemy to osiągnąć m.in. przez wprowadzenie fasady,
która zapewnia interfejs bardziej ogólny zapewniający
interfejs całego podsystemu

Fasada



Mamy np. środowisko z podsystemem będącym
kompilatorem. Mamy Parser, Analizator, WęzełProgramu,
…



Dla klienta, który pragnie jedynie skompilować kawałek
programu, nie jest to istotne. Potrzebuje on interfejsu klasy
Kompilator, będącego fasadą dla podsystemu

Fasada

Stosowalność



zapewnienie prostego interfejsu do złożonego systemu



stosowanie wzorców rozbija systemy na bardzo wiele małych
klas, co powoduje się bardziej nadają się one do wielokrotnego
użytku oraz są prostsze w rozbudowie



rozrastanie się systemu powoduje natomiast, że klientowi
trudniej jest go wykorzystać



fasada zapewnia prosty, funkcjonalny interfejs, wystarczająco
dobry dla większości klientów, który może pozostać stały nawet
jeśli podsystem wewnątrz uległ zmianie



zwiększa przenośność i niezależność podsystemu



umożliwia układanie systemów warstwami (fasada
definiuje punkty wejścia do podsystemu)

Fasada

Struktura

Fasada



Uczestnicy



Fasada (Kompilator)



Wie jakie klasy podsystemu są odpowiedzialne, za spełnienie
żądania



Przekazuje żądania do odpowiednich obiektów systemu



Klasa podsystemu (Parser, Analizator, …)



Implementuje funkcjonalność systemu



Wykonuje pracę przydzieloną przez fasadę



Nie wie nic o fasadzie

Fasada



Współpraca



Klienci komunikują się z podsystemem, wysyłając żądania
do Fasady, która przekazuje żądania do podsystemu

(może być zmuszona przetłumaczyć swój interfejs na
interfejsy podsystemu)



Klienci korzystający z fasady nie muszą mieć
bezpośredniego dostępu do obiektów jej podsystemu

Fasada

Konsekwencje



Mniejsza liczba obiektów, z którymi klient ma do
czynienia

(łatwość użycia)



Mogą eliminować złożone lub cykliczne zależności między
obiektami systemu



Większa przenośność na inne platformy

(przy jej użyciu jest mniejsze prawdopodobieństwo, że zmiana w
jednym podsystemie spowoduje konieczność przebudowy
pozostałych

Pełnomocnik

Przeznaczenie



zapewnia reprezentanta innego obiektu w celu
sterowania dostępem do obiektu oryginalnego

Pełnomocnik

Uzasadnienie stosowania



Jednym z powodów sterowania dostępem do obiektu jest
np. chęć odłożenia na później tworzenia/inicjowania tego
obiektu



np. wielkie obrazy rastowe w dokumencie



Otwieranie dokumentu powinno być szybkie i dopiero
kiedy obiekty stają się widoczne powinniśmy je
budować…



Powinno być to przezroczyste dla obiektu dokumentu



Dlatego w miejsce rysunku tworzymy Pełnomocnika, który
dopiero buduje obraz na żądanie wyświetlenia go

Pełnomocnik



Pełnomocnik przechowując dodatkowo np. rozmiary
obrazka może spełniać żądania programu formatującego
bez potrzeby sięgania do egzemplarza rysunku



Aby korzystać z tych udogodnień wystarczy do istniejącej
struktury klas dodać pełnomocnika:

Pełnomocnik

Stosowalność



zawsze, gdy potrzeba uniwersalnego sposobu odwołania do
obiektu

(bardziej wyrafinowanego niż zwykły wskaźnik)



np.



Pełnomocnik zdalny



lokalny reprezentant obiektu z innej przestrzeni adresowej



Pełnomocnik wirtualny



tworzy kosztowne obiekty na żądanie (np.
PełnomocnikRysunku)



Pełnomocnik ochraniający



kontroluje dostęp do obiektu



zapewnia różne prawa dla różnych obiektów

Pełnomocnik



Sprytny wskaźnik



zastępuje zwykły wskaźnik, wykonując dodatkowe akcje
przy dostępie do obiektu, jak:



zliczanie liczby odwołań do obiektu (usuwanie przy braku
odwołań)



Ładowanie trwałych obiektów do pamięci przy pierwszym
odwołaniu

Pełnomocnik

Struktura

Pełnomocnik



Uczestnicy



Pełnomocnik (PełnomocnikRysunku)



Przechowuje odwołanie, umożliwiające mu dostęp do
prawdziwego obiektu



Zapewnia identyczny interfejs z oryginalnym obiektem (może
wystąpić wszędzie tam, gdzie oryginał)



Kontroluje dostęp do obiektu



… (cokolwiek)



Przedmiot (ObiektGraficzny)



Definiuje wspólny interfejs dla PrawdziwegoPrzedmiotu i
Pełnomocnika



PrawdziwyPrzedmiot (Rysunek)



Definiuje dowolny przedmiot

Pełnomocnik



Współpraca



Pełnomocnik jeśli trzeba przekazuje żądania do
PrawdziwegoPrzedmiotu (w zależności od rodzaju
pełnomocnika)

Pełnomocnik

Konsekwencje



dodatkowy poziom pośredniości dostępu do obiektu, może:



ukryć fakt, że obiekt jest zdalny



wykonywać optymalizacje jak tworzenie obiektu na
żądanie



dodatkowe czynności porządkowe



ukrywanie np. kopiowania-przy-zapisywaniu



odłożenie na później kopiowania obiektu – będzie on
rzeczywiście skopiowany tylko jeśli użytkownika zażąda
operacji modyfikującej kopię

Pyłek

Przeznaczenie



wykorzystuje współdzielenie obiektów, w celu
efektywnej obsługi wielkiej liczby drobnych obiektów

Pyłek

Uzasadnienie stosowania



Większość edytorów używa obiektów do przechowywania
takich elementów jak tabele, rysunki



Na ogół jednak powstrzymują się od stosowania obiektów
do reprezentacji poszczególnych znaków w dokumencie,
mimo że przyczyniłoby to się do zwiększenia elastyczności
(nowe zestawy znaków, jednakowe traktowanie znaków i
innych obiektów pod względem formatowania i
wypisywania



Przyczyną tego jest koszt pamięciowy takiego rozwiązania!



Tutaj pojawia się Pyłek

Pyłek



Jest on współdzielonym obiektem, który może być
używany jednocześnie w wielu kontekstach



Działa on jako obiekt niezależny w każdym kontekście

(nie może niczego zakładać o kontekście działania)



Jest nieodróżnialny od egzemplarza obiektu, który nie jest
współdzielony



Edytor może utworzyć Pyłek dla każdej litery alfabetu



Każdy Pyłek przechowuje wtedy tylko kod znaku, jego
miejsce i styl typograficzny natomiast są mu dostarczane
przez algorytmy rozmieszczania i formatowania tekstu

Pyłek



Logiczny punkt widzenia:

1 znak = 1 obiekt



Fizycznie istnieje jednak jeden współdzielony obiekt dla
każdej litery:

Pyłek



Struktura klas takich obiektów wygląda tak:



Stan zewnętrzny musi być przekazywany jako parametr do
niektórych operacji (dotyczących wystąpień znaków w
dokumencie)

Pyłek



Przechowywanie stanu zewnętrznego jest zadaniem
Klienta, może być ono zaimplementowany w postaci
BDrzewa:



Węzły wewnętrzne = zakresy indeksów glifów



Liście = style

Pyłek

Stosowalność



System używa wielkiej liczby obiektów



Koszty pamięciowe są wysokie ze względu na samą tylko
liczbę obiektów



Większość stanu obiektów może być przeniesiona na
zewnątrz



Po usunięciu stanu zewnętrznego wiele grup obiektów
można zastąpić stosunkowo niewielką liczbą
współdzielonych obiektów



Tożsamość obiektów nie jest istotna w systemie

Pyłek

Struktura

Pyłek



Uczestnicy



Pyłek (Glif)



Deklaruje interfejs, przez który pyłki mogą otrzymywać stan
zewnętrzny i działać zgodnie z nim



PyłekKonkretny (Znak)



Implementuje interfejs pyłku i dodaje pamięć do
przechowywania stanu wewnętrznego



Musi dawać się współdzielić (niezależność od kontekstu w jakim
występuje)



FabrykaPyłków



Tworzy obiekty klasy Pyłek i zarządza nimi



Zapewnia właściwe współdzielenie pyłków



Klient



Utrzymuje odwołania do pyłków



Przechowuje stan zewnętrzny pyłków

Pyłek



Współpraca



Stan którego pyłek potrzebuje do działania musi być
scharakteryzowany albo jako wewnętrzny albo zewnętrzny.
Stan zewnętrzny jest dostarczany przez klienta



Klienci nie powinni bezpośrednio tworzyć egzemplarzy
klasy PyłekKonkretny (otrzymują je z FabrykiPyłków)

Pyłek

Konsekwencje



Zwiększenie czasu wykonywania w związku z
przesyłaniem lub wyliczaniem stanu zewnętrznego



Oszczędność pamięci



Zmniejszenie łącznej liczby egzemplarzy (współdzielenie)



Wielkość stanu wewnętrznego obiektu



Wyliczanie/przechowywanie stanu zewnętrznego



Często łączony z wzorcem Kompozyt w celu przedstawienia
struktury hierarchicznej ze współdzielonymi węzłami/liśćmi

(problem = stan wewnętrzny nie może zawierać wskaźnika do
rodzica; rozwiązanie = rodzic przekazywany jako część stanu
zewnętrznego)

Stan

Przeznaczenie



Umożliwia obiektowi zmianę zachowania, gdy
zmienia się jego stan wewnętrzny



Obiekt wydaje się zmieniać wówczas swoją klasę

Stan

Uzasadnienie stosowania



Rozważmy klasę PołączenieTCP, reprezentującą
połączenie sieciowe:



Ilekroć połączenie zmienia stan, obiekt PołącznieTCP
zmienia swój obiekt-stan => zmienia przez to swoje
zachowanie

Stan

Stosowalność



Zachowanie obiektu zależy od jego stanu, a obiekt musi
zmieniać swoje zachowanie w czasie wykonywania
programu



Operacje zawierają duże, skomplikowane instrukcje
warunkowe, zależne od stanu obiektu



Stan przenosi każde rozgałęzienie warunkowe do
oddzielnej klasy

Stan

Struktura

Stan



Uczestnicy



Kontekst (PołączenieTCP)



Definiuje interfejs dla Klientów



Utrzymuje egzemplarz podklasy StanuKonkretnego, definiujący
bieżący stan



Stan (StanTCP)



Definiuje interfejs do kapsułkowania zachowania związanego ze
stanem Kontekstu



Podklasa StanuKonkretnego (TCPNawiazane)



Każda implementuje zachowanie związane ze stanem Kontekstu

Stan



Współpraca



Kontekst przekazuje żądania specyficzne dla stanu do
obiektu StanKonkretny

(być może przekazuje również siebie jako parametr)



Klient konfiguruje Kontekst początkowym stanem, a
następnie nie musi zajmować się bezpośrednio obiektami
Stan



O wyborze kolejnego stanu decyduje albo Kontekst, albo
podklasy StanuKonkretnego

Stan

Konsekwencje



Całe zachowanie dotyczące stanu w jednym obiekcie



Dużo większa liczba klas



Zachowanie mniej zwarte – korzystne gdy wiele stanów
(inaczej duże instrukcje warunkowe)



Jawność przejść między stanami

(coś więcej niż tylko przypisanie kilku zmiennych)



Atomowe przejścia między stanami (zmiana 1 zmiennej)



Możliwość współdzielenia obiektów Stan

Stan



Kto definiuje przejścia? (tego nie ustala wzorzec)



bardziej elastyczne wydaje się umożliwienie podklasom Stanu
samodzielnego ustalenia ich następników



wprowadza to niestety zależności implementacyjne (Stany
muszą o sobie wiedzieć), co może prowadzić do problemów w
dużych systemach z wieloma stanami

Stan

Przykłady



Wiele programów do rysowania zapewnia różnorodne
„narzędzia”:



narzędzie do rysowania



narzędzie do zaznaczania



W zależności od tego, które narzędzie jest aktywne
operacje myszką wywołują inne efekty



Można tu zastosować wzorzec Stanu do reprezentacji
wybranego narzędzia

Stan

METODY

SPIRALNE

Planowanie

Projektowanie

Implementacja

Walidacja rozwiązań

Wstępna wersja

specyfikacji

SWS

Pełna specyfikacja

funkcjonalności

Implementacja funkcjonalności
wymaganych lub ich podzbioru

Implementacja kolejnych

funkcjonalności

Uzupełnienie listy funkcjonalności

wynikami walidacji

Produkt gotowy ?

Zarzucenie

wyników prac

implementacyjnych

Implementacja kolejnych

funkcjonalności

Uzupełnienie listy funkcjonalności

wynikami walidacji

Testowanie

in situ

Testowanie

na modelu

Praktyczna realizacja
metodologii spiralnej

Rozwinięcie modelu spiralnego
w oparciu o tzw. teorię Win-
Win.

Teoria W-W podpowiada, że należy zidentyfikować
wszystkich tych, którzy mają wpływ na przebieg
i wynik projektu. Mogą to być użytkownicy, inwestorzy,
agendy rządowe i ich regulacje prawne, firmy
programistyczne itp.

Należy określić warunki sukcesu każdego uczestnika
procesu (win condition).

Należy doprowadzić do negocjacji pomiędzy
uczestnikami podczas oceny prototypów, jeśli ich warunki
sukcesu wykluczają się.

Spiralny model Win-Win

JAKO

ŚĆ

SPECYFIKACJI

WYMAGA

I ANALIZY

Obecnie najczęściej wykorzystywane systemy
informacyjne w dziedzinie ekonomii i zarządzania
ukierunkowane są głównie
na usprawnianie zarządzania w celu lepszego
zaspokajania potrzeb wszystkich uczestników
procesów gospodarczych.

Obiekt ekonomiczny

Gromadzenie

danych

aliz

Interpretacja

wskaźników

ien

Podejmowanie

decyzji

Strategia ekonomiczna

Proste

kierowanie

nakazowe

ied

trz

rzą

ia t

tyczn

Najważniejsze kierunki
innowacji wprowadzanych
w SI oparte są na:



integracji

systemów, danych i procesów,



unifikacji

funkcji cząstkowych systemów,



zwiększania

dostępności

do bazy danych

dla wszystkich komórek organizacyjnych,



upowszechniania nowoczesnych sposobów

prezentacji

danych (wizualizacji) dla celów

wspomagania ich analizy,



doskonalenia procesów podejmowania

decyzji

i ich przekazywania,



zmierzania do budowy

modułowej

otwartości całego systemu,

Dalsze wymagania dotyczące
projektowanego systemu



zapewnienia

kompleksowego

charakteru

funkcjonalnego całego systemu,



stałego podnoszenia

zaawansowania

merytorycznego i technologicznego,



zmierzania do

elastyczności

funkcjonalnej

i strukturalnej,



zapewnienia stałej

zgodności

zmieniającymi się elementami otoczenia
systemowego, a zwłaszcza z aktualnym
stanem prawnym, ewoluującym zgodnie z
przyjętymi procedurami legislacyjnymi.

Ekonomiczne systemy informacyjne są projektowane i
realizowane w taki sposób, aby dane przetwarzane
przez ów system były bezpieczne i na każdym jego
etapie chronione.

Dlatego też w jak największym stopniu musi być
zapewniona poufność i integralność wszelkich danych
posiadanych przez system, a dostępność do danych
zawartych w systemie powinna być zgodna z przyjętą
hierarchią haseł i przywilejów dostępu.

Najnowsze prace odwołujące się do
inżynierii oprogramowania przewidują
występowanie aż

faz procesu projektowego.

1.Inicjalizacja systemu i wstępne

planowanie:

Znalezienie potencjalnego obszaru

zastosowania systemu informatycznego, który
wspomoże lub zastąpi dotychczasowe metody
przetwarzania informacji.

2.Analiza wymagań i specyfikacja

wymagań:

Identyfikacja problemów, które nowy system
informacyjny ma rozwiązać. Zarysowanie
właściwości operacyjnych systemu, wydajności
i zasobów sprzętowych niezbędnych do
użytkowania i konserwowania systemu.

3. Specyfikacja funkcjonalna

i prototypowanie:

Identyfikacja i formalizacja obiektów obliczeń,
ich atrybutów i zależności. Specyfikacja
transformacji, którym obiekty będą podlegać.

4. Dekompozycja problemu:

Podział systemu na logiczne podsystemy na

podstawie wymagań i specyfikacji. Analiza
logicznych podsystemów pod kątem użycia już
istniejących komponentów informatycznych.
Selekcja rozwiązań: wykonać samodzielnie,
kupić, wykorzystać już istniejące.

5. Projekt architekturalny i specyfikacja
konfiguracji:

Określenie zależności pomiędzy podsystemami,
komponentami i modułami w sposób
uwzględniający szczegóły ich budowy i
wymagania wobec nich.

6. Szczegółowe projektowanie i specyfikacja

komponentów:

Opracowanie i kodyfikowanie metod
przetwarzania informacji w komponentach.

7. Implementacja komponentów i usuwanie
błędów:

Wytwarzanie kodu źródłowego komponentów na
podstawie uprzednich specyfikacji. Testowanie
podstawowych funkcji komponentów.

8. Asemblacja systemu i testowanie:

Weryfikacja komponentów pod kątem
kompletności
i zgodności ze specyfikacją. Asemblacja produktu
z komponentów, weryfikacja wydajności
podsystemów systemu jako całości.

9. Przegląd dokumentacji i dostarczenie

systemu:

Opracowywanie i systematyzowanie
dokumentacji powstałej w trakcie
prowadzenia projektu pod kątem raportów
dla odbiorcy.

10. Opracowanie procedur
instalacyjnych

i instalacja:

Opracowanie dokumentacji instalacyjnej
opisującej sposób instalacji systemu.

11. Szkolenie dla użytkowników:

Zapoznanie użytkowników z systemem.
Zapoznanie ich z możliwościami i
ograniczeniami systemu.

12. Użytkowanie i konserwacja

oprogramowania:

Użytkowanie, usuwanie błędów
dostrzeżonych
w trakcie użytkowania, rozbudowywanie
systemu o nowe właściwości, poprawa
wydajności systemu.

Jednak nawet najlepsza metodologia nie zabezpiecza przed
błędami, bo istnieje

luka poznawcza

w projektach

informatycznych

Procesy

makro

Procesy

mikro

Luka

poznawcza

Sposób wnioskowania

Od ogółu

do szczegółu

ogółu

szczegółu

gó

ło

śc

Eksperyment lub

symulacja

lub ?

Prace analityczne

i projektowe

Dedukcyjne prace

analityczne i projektowe

o dużym stopniu ogólności

Indukcyjne prace

analityczne i projektowe

dotyczące problemów

szczegółowych

Na tym poziomie problemy stają się
zbyt ogólne dla zespołów projektowych
zajmujących się zagadnieniami podstawowymi

Problemy na tym poziomie umykają
zespołom analitycznym i projektowym
na skutek natłoku szczegółów

Zagadnienia zaliczające się do luki
poznawczej, nie są w trakcie analizy
dostrzegane i nie zostaną wyczerpująco
opracowane, można więc określać je
mianem ryzykownych punktów projektu.

Wokół tych zagadnień Boehm zbudował
spiralny model tworzenia
oprogramowania

Jakość specyfikacji wymagań i analizy

Jako

ść

specyfikacji wymaga

i analizy

Jest rezultatem:



sformułowania wymagań jakościowych przedłożonych przez użytkownika

(właściciela biznesowego),



wyboru metodyki (sposobu) realizacji fazy analizy i definicji,



posiadanych kwalifikacji przez zespół analityków,



posiadanych narzędzi wykorzystywanych na etapie specyfikacji

wymagań i analizy.

WSKA

NIKI

JAKO

CIOWE

WYMAGANIA

TECHNIKI

OPROGRAMOWANIE

NARZ

DZIOWE

ISTNIEJ

SYSTEMY

PODOBNE

WYMAGANIA

JAKO

CIOWE

OGRANICZENIA

WIEDZA

ZESPO

REALIZACJA

PROCESU

DEFINICJI

ROZWI

ZANIE

KSZTA

TOWANIE

JAKO

ŚĆ

SPECYFIKACJI

WYMAGA

I ANALIZY

JAKO

ŚĆ

PROJEKTOWA

Jakość projektowa

Jako

ść

projektowa

Jest rezultatem:



sformułowania wymagań jakościowych zawartych w wymaganiach (w

specyfikacji wymagań),



wyboru sposobu realizacji procesu projektowania,



posiadanych kwalifikacji przez zespół projektowego,



posiadanych narzędzi wykorzystywanych w etapie projektowania.

WSKA

NIKI

JAKO

CIOWE

WYMAGANIA

KONSTRUKCYJNE

TECHNOLOGIA

PROCESU

PROJEKTOWANIA

OPROGRAMOWANIE

NARZ

DZIOWE

ISTNIEJ

SYSTEMY

PODOBNE

WYMAGANIA

JAKO

CIOWE

OGRANICZENIA

WIEDZA

ZESPO

PROJEKTANT

REALIZACJA

PROCESU

DEFINICJI

ROZWI

ZANIE

FUNKCJONALNO

KONSTRUKCYJNE

KSZTA

TOWANIE

JAKO

PROJEKTOWEJ

JAKO

ŚĆ

PROJEKTOWA

JAKO

ŚĆ

SPECYFIKACJI

WYMAGA

ANALIZY

TECHNOLOGIE

PRZETWARZANIA

JAKO

ŚĆ

POTENCJALNA

Jakość potencjalna

Jako

ść

potencjalna

Jest rezultatem:



zmian w rozwiązaniach konstrukcyjnych zachodzących w procesie
produkcji oprogramowania i testowania,



jakości zastosowanych elementów programowych i materiałowych,



wyboru technologii produkcji oprogramowania.

ROZWI

ZANIA

PROJEKTOWE

OPROGRAMOWANIE

NARZ

DZIOWE

TECHNOLOGIA

PROGRAMOWANIA

JAKO

PROJEKTOWA

REALIZACJA

PROCESU

PRODUKCYJNEGO

KSZTA

TOWANIE

JAKO

POTENCJALNEJ

JAKO

ŚĆ

POTENCJALNA

JAKO

ŚĆ

EKSPLOATACYJNA

Jakość eksploatacyjna

Jako

ść

eksploatacyjna

Jest rezultatem:



wyboru procesu eksploatacji,



poziomu jakości potencjalnej,



wyboru warunków eksploatacji,



postawionych wymagań eksploatacyjnych.

WYMAGANIA

WARUNKI

EKSPLOATACJI

JAKO

POTENCJALNA

PROCES

EKSPLOATACJI

KSZTA

TOWANIE

JAKO

EKSPLOATACYJNEJ

JAKO

ŚĆ

EKSPLOATACYJNA

KORZY

CI Z INWESTYCJI

INFORMATYCZNYCH

Czy

inwestycje

informatyczne

zmieniają

zasadniczy sposób pozycję ekonomiczno-finansową
firmy?

Korzyści z inwestycji ekonomicznych

Korzy

ci z inwestycji ekonomicznych

Nie

Tak - w sposób

zasadniczy

Klasyfikacja (przykładowa) efektów informatyzacji

Klasyfikacja

(przyk

adowa)

efekt

w informatyzacji

Klasyfikacja efekt

w informatyzacji mo

e by

bardzo r

na:

• globalne



techniczne - wzrost szybkości, dokładności, szczegółowości i poufności

przetwarzania danych



ekonomiczne - wspomaganie wzrostu efektu ekonomicznego np. przez

bieżący nadzór nad firmą



organizacyjne - usprawnienie struktury organizacyjnej (np. obiegu

dokumentów)



socjo-psychologiczne - integracja pracowników przez lepsze poznanie

ichpotrzeb

• cząstkowe

• jednorazowe - w momencie wdrażania systemu (np. spadek zatrudnienia)
• ciągłe - w całym okresie eksploatacji (np. poprawa wykorzystania aparatu

produkcyjnego)

• bezpośrednie - np. obniżka kosztów przetwarzania danych
• pośrednie - np. poprawa zaopatrzenia materiałowego

• pierwotne - zmniejszenie np. zmniejszenie amortyzacji po wycofaniu zbędnych

urządzeń

• wtórne - np. obniżka kosztów własnych (podobnie jak efekty pośrednie)

g M

. N

g M

. N

. Ki

lni

. Ki

lni

• czy strategia informatyzacji firmy została opracowana na podstawie

strategii biznesowej

• czy szczegółowy projekt został sprecyzowany
• czy projekt jest w pełnej fazie rozwoju
• czy projekt został zatwierdzony
• czy projekt wprowadzono w życie
• czy projekt działa od pewnego czasu
• czy projekt jest bliski końca

Sposób (przykładowy) oceny przedsięwzięć IT

Spos

(przyk

adowy)

oceny przedsi

wzi

ęć

Organizacja ocenia, mierzy, szacuje i uzasadnia koszty na ka

dym etapie

przygotowania i realizacji przedsi

wzi

cia

Sposób (przykładowy) oceny przedsięwzięć IT

Spos

(przyk

adowy)

oceny przedsi

wzi

ęć

Niekt

re metody oceny:

•

„

Zwrot z inwestycji

”

” (ROI -

Return-On-Investment) wiąże się z oceną

aktualnej wartości kosztów i przyszłych wpływów i polega na ocenie czasu i

wartości zwrotu poniesionych kosztów. Najczęściej stosowana do

porównania różnych alternatywnych projektów pod katem zwrotu kosztów.

•

„

Analiza koszt

w i korzy

”

” (CBA -

Cost - benefit analysis) wiąże się z

próbą oszacowania kosztów każdego elementu projektu i wartości korzyści

ekonomicznej z rozwoju projektu.

•

„

Metody wielu cel

w i wielu kryteri

”

” (

MOMC - Multi-objective, Multi-

criteria methods) zakłada istnienie innych wartości niż ekonomiczne, stąd

polega na uszeregowaniu określonych preferencji wg przyznanych im wag.

Ponieważ wagi mogą być oceną subiektywną tworzone są alternatywne

scenariusze uwzględniające różne cele.

•

„

Warto

ci graniczne

”

” (

Boundary values) dostarcza surowego porównania

całkowitych wydatków z innymi połączonymi wartościami np. całkowity koszt

IT a całkowity dochód lub łączny koszt na jednego pracownika lub całkowite

wydatki na IT a zysk netto.

•

„

Zwrot z zarz

dzania

”

” (

ROM - Return on Management) wiąże się z

szacowaniem korzyści w zarządzaniu, czyli określa zysk wynikający z

poprawy zarządzania firmą przez porównanie oszacowania zysku z

zastosowaniem IT i bez.

•

„

Kluczowe czynniki sukcesu

”

(

Critical succes factors) polega na

wyspecyfikowaniu tych czynników, które są

gwarantem sukcesu

informatyzacji oraz ocenia jaka jest rola IT w osiąganiu powodzenia.

•

Metody do

wiadczalne

wiadczalne pozwalają dokonać oceny na drodze budowy

prototypu (

prototyping), symulacji komputerowej (simulation) lub

inscenizacji (

gameplaying).

•

Inne

Inne (

patrz Materiały Konferencji

Efektywność zastosowań SI Szczyrk 2001 - Nowak J.S

„Przegląd metod oceny inwestycji informatycznych”str.61 (T.II)

)

RYZYKO

W PRZEDSIĘWZIĘCIACH

INFORMATYCZNYCH

RYZYKO

W PRZEDSI

WZI

CIACH

INFORMATYCZNYCH

•

Model zarz

dzania ryzykiem

•

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

Istnieje wiele określeń dotyczących pojęcia ryzyka ale we
wszystkich

można

spotkać

opinię,

iż

ryzyko

jest

ryzyko

jest

charakteryzowane przez dwa podstawowe elementy

charakteryzowane przez dwa podstawowe elementy:



niepewno

ść

–

zdarzenie,

które

powoduje

urzeczywistnienie ryzyka, (jeśli urzeczywistnienie jest
pewne powinno być klasyfikowane jako ograniczenie
realizacji przedsięwzięcia informatycznego)



skutki

–

urzeczywistnienie się

ryzyka powoduje

wystąpienie negatywnych konsekwencji lub strat.

Ryzyko jest nieodłącznym elementem realizacji każdego
przedsięwzięcia informatycznego.

Profesjonalne podejście do przedsięwzięć informatycznych
wymaga stosowania przez kierownika projektu skutecznej
metody zarządzania ryzykiem.

Określenie ryzyka

Okre

lenie ryzyka

Model Software Engineering Institute (SEI)

zarządzania ryzykiem

Model

Model Software Engineering Institute (SEI)

zarz

dzania ryzykiem

KOMUNIKACJA

LEDZENIE

STEROWANIE

IDENTYFIKACJA

ANALIZA

PLANOWANIE

wymiana informacji o ryzyku na
różnych

poziomach

organizacji,

istotnych z punktu widzenia całości
przedsięwzięcia

“inwentaryzacją” potencjalnych zagrożeń -
tworzenie listy specyficznych dla danego
przedsięwzięcia elementów ryzyka

ocena p-stwa (dla każdego
ryzyka) wystąpienia ryzyka i
rozmiar potencjalnych start.
Określa się

również

skutki

wystąpienia kilku elementów
ryzyka.

wykorzystanie informacji o
ryzykach

różnych

decyzjach

działaniach

mających

celu

złagodzenie

skutków

urzeczywistnienia się ryzyk

monitorowanie statusu ryzyk
oraz działań rozpoczętych w
celu łagodzenia lub unikania
ryzyka

korygowanie odchyleń
od

przewidywanych

rezultatów

działań

podjętych

celu

łagodzenia lub unikania
ryzyka

WSKA

NIK ZAGRO

ENIA

PRZEDSI

WZI

CIA

INFORMATYCZNEGO

Wskaźnik zagrożenia przedsięwzięcia informatycznego

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

cia informatycznego to ilościowe

określenie (miara) szansy powodzenia realizowanego przedsięwzięcia

Wskaźnik ten powinien być reprezentowany przez dwie składowe

(odnoszone do układu wykonawca-zleceniodawca):



stan motywacji

stan motywacji do pomyślnego zakończenia przedsięwzięcia,



stan mo

liwo

ci wykonawczych pomyślnego zakończenia

przedsięwzięcia informatycznego.

WSKAŹNIK ZAGROŻENIA

MOTYWACJE

MOŻLIWOŚCI

Bardzo mocno korzystny dla przedsięwzięcia

Mocno korzystny dla przedsięwzięcia

Dostatecznie korzystny dla przedsięwzięcia

Zauważalnie korzystny dla przedsięwzięcia

Nieznacznie korzystny dla przedsięwzięcia

Obojętny dla przedsięwzięcia

Nieznacznie niekorzystny dla przedsięwzięcia

-2

Zauważalnie niekorzystny dla przedsięwzięcia

-4

Dostatecznie niekorzystny dla przedsięwzięcia

-6

Mocno niekorzystny dla przedsięwzięcia

-8

Bardzo mocno niekorzystny dla przedsięwzięcia -10

UWAGA!

aden wska

nik nie zast

pi zdrowego rozs

dku!!!

Wskaźnik zagrożenia przedsięwzięcia informatycznego

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

Wartość składowych wskaźnika zagrożenia (motywacja i możliwości)

może być wyznaczona na podstawie wartości tzw.

sprawczych

sprawczych i

wykonawczych

czynników

zagrożenia

przedsięwzięcia

informatycznego

Czynniki sprawcze

zagrożenia przedsięwzięcia informatycznego

opisują te elementy oraz te właściwości (cechy) działalności układu

zleceniodawca-wykonawca, które generują przyczyny upadku (lub

powodzenia) przedsięwzięcia informatycznego.

Czynniki wykonawcze

Czynniki wykonawcze zagrożenia przedsięwzięcia informatycznego

opisują te elementy oraz te właściwości (cechy) działalności układu

zleceniodawca-wykonawca, które określają fizyczną realizowalność

przedsięwzięcia informatycznego.

Zbiór wartości czynników sprawczych zagrożenia przedsięwzięcia

informatycznego określa wartość stanu motywacji

Zbiór wartości czynników wykonawczych zagrożenia przedsięwzięcia

informatycznego określa wartość stanu możliwości

Wskaźnik zagrożenia przedsięwzięcia informatycznego

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

Wartości czynników sprawczych i wykonawczych mogą

być

wyznaczone na podstawie listy zidentyfikowanych ryzyk.

Ryzyka te określa się

czynnikami pierwotnymi

zagrożenia

przedsięwzięcia informatycznego

W tym celu dla każdego zidentyfikowanego ryzyka czynnika

pierwotnego należy określić:



czy dany czynnik pierwotny (ryzyko) wpływa na określony

czynnik sprawczy czy wykonawczy?



liczbę określającą bieżący stopień urzeczywistnienia się

danego ryzyka,



jak dany czynnik pierwotny (ryzyko) wpływa na określony

czynnik sprawczy lub wykonawczy: czy powoduje jego wzrost

czy spadek?

Czynniki pierwotne zagrożenia przedsięwzięcia informatycznego

mogą być określone na podstawie kwestionariuszy identyfikacji

ryzyka. Kwestionariusz taki zawiera listę potencjalnych źródeł

ryzyk dla konkretnego przedsięwzięcia, do której należy dołączyć

listę pytań (przynajmniej jedno pytanie do źródła) umożliwiających

identyfikację tych ryzyk.

Wskaźnik zagrożenia przedsięwzięcia informatycznego

Wska

nik zagro

enia przedsi

wzi

cia informatycznego

Algorytm określania wskaźnika zagrożenia przedsięwzięcia informatycznego



zdefiniowanie zbioru czynników pierwotnych zagrożenia (ryzyk)

R = (r

, r

, ..., r

);



skonstruowanie (dla każdego czynnika ryzyka) kwestionariusza oceny wartości

danego czynnika, umożliwiającego ustalenie jego bieżącej wartości;



zdefiniowanie zbioru czynników sprawczych zagrożenia

S = (s

, s

, ..., s

);



dla każdego czynnika sprawczego zdefiniowanie formuły przedstawiającej

zależność między wybranymi czynnikami pierwotnymi zagrożenia (ryzykami) a

danym czynnikiem sprawczym;



zdefiniowanie zbioru czynników wykonawczych zagrożenia

W = (w

, w

, ...,w

);



dla każdego czynnika wykonawczego zdefiniowanie formuły przedstawiającej

zależność między wybranymi czynnikami pierwotnymi zagrożenia (ryzykami) a

danym czynnikiem wykonawczym;





















...

waga i-tego czynnika sprawczego



określenie stanu motywacji (M) jako “wypadkowej” czynników sprawczych

przedsięwzięcia informatycznego:





















...

waga i-tego czynnika wykonawczego



określenie stanu możliwości (P) jako “wypadkowej” czynników wykonawczych

zagrożenia przedsięwzięcia informatycznego:



określenie wskaźnika zagrożenia przedsięwzięcia informatycznego

WZI = (M,P)