projektowanie systemów informatycznych - lk -...

Projektowanie systemów Projektowanie systemów informatycznychinformatycznych

Mirosława LasekKatedra Informatyki Gospodarczeji Analiz EkonomicznychWydział Nauk EkonomicznychUniwersytet Warszawskiul. Długa 44/5000 - 241 Warszawae-mail: [email protected]

Materiały pomocnicze; nie zastępują uczestnictwa w wykładach ani podręczników !

Projektowanie systemów informatycznychProjektowanie systemów informatycznych

Literatura podstawowa:Stanisław Wrycza, Analiza i projektowanie systemów informatycznych zarządzania. Metodyki, techniki, narzędzia, PWN, Warszawa 1999.Stanisław Szejko (red.), Metody wytwarzania oprogramowania, Wydawnictwo MIKOM, Warszawa 2002.

Metodyka tworzenia systemu informatycznego Metodyka tworzenia systemu informatycznego -- elementyelementyDziedzina

przedmiotowaDziedzina

przedmiotowa

Wspomaganie

ModeleDP

ModeleDP

Narzędzia komputerowego

wspomagania

Narzędzia komputerowego

wspomagania

Metodyi technikiMetody

i techniki

Zadania

Para-metry Pakiety

Fazy

Dokumentacja

Pojęciaabstrakcyjne

Regułymodelowania

Systeminformatyczny

Systeminformatyczny

PROCESTWORZENIA

SYSTEMUINFORMATYCZNEGO

PROCESTWORZENIA

SYSTEMUINFORMATYCZNEGO

Zespółprojektujący

Zespółprojektujący

Kryteriaoceny

Kryteriaoceny

Korekty i modyfikacje

Prezentacjai eksperymentalnaeksploatacja

Akceptacja

Tworzeniesystemu

Kierowanie projektami

Wynikianaliz

Cele, problemy,potrzeby informatyczne

Źródło: S. Wrycza, Analiza i projektowanie systemów informatycznych zarządzania. Metodyki, techniki, narzędzia, PWN,Warszawa 1999.

Źródła złożoności procesu tworzenia SIŹródła złożoności procesu tworzenia SI

Zespół projektujący podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji

Zespół projektujący podlegający ograniczeniom pamięci, percepcji, wyrażania informacji i komunikacji

Dziedzina przedmiotowa, badany wycinek rzeczywistości, obejmujący ogromną liczbę wzajemnie uzależnionych aspektów i problemów

Dziedzina przedmiotowa, badany wycinek rzeczywistości, obejmujący ogromną liczbę wzajemnie uzależnionych aspektów i problemów Proces

tworzeniasystemu

informatycznego

System informatycznyprzekazany do oceny a następnie użytkowaniapotencjalnym użytkownikom

System informatycznyprzekazany do oceny a następnie użytkowaniapotencjalnym użytkownikom

Modele DP, metody i techniki,narzędzia wspomagania komputerowego – podstawowy warsztat analityka i projektanta systemów

Modele DP, metody i techniki,narzędzia wspomagania komputerowego – podstawowy warsztat analityka i projektanta systemów

Źródło: na podstawie K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002.

Jak minimalizować złożoność?Jak minimalizować złożoność?Zasada dekompozycji

rozdzielenie złożonego problemu na podproblemy, które można rozpatrywać i rozwiązywać niezależnie od siebie i niezależnie odcałości

Zasada abstrakcjieliminacja, ukrycie lub pominięcie mniej istotnych szczegółów rozważanego przedmiotu lub mniej istotnej informacji; wyodrębnianie cech wspólnych i niezmiennych dla pewnego zbioru bytów i wprowadzaniu pojęć lub symboli oznaczających takie cechy

Zasada ponownego użyciawykorzystanie wcześniej wytworzonych schematów, metod, wzorców, komponentów projektu, komponentów oprogramowania, itd.

Zasada sprzyjania naturalnym ludzkim własnościomdopasowanie modeli pojęciowych i modeli realizacyjnych systemów do wrodzonych ludzkich własności psychologicznych, instynktów oraz mentalnych mechanizmów percepcji i rozumienia świata

Źródło: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002.

Metodyka tworzenia systemu informatycznego Metodyka tworzenia systemu informatycznego --wymaganiawymagania

metodyka powinna objąć cały cykl życia systemu informatycznego,metodyka powinna obejmować różnorodne, dostosowane do specyfiki podejścia, metody, techniki i narzędzia komputerowe wspomagające proces tworzenia systemu i analizę,metodyka powinna ułatwiać porozumiewanie się pomiędzy różnymi grupami zawodowymi tworzącymi SI,metodyka powinna być stosunkowo łatwa w użytkowaniu, powinna móc ewoluować i podlegać modyfikacjom


Perspektywy w projektowaniuPerspektywy w projektowaniu„Trwałą tendencją w rozwoju metod i narzędzi projektowania oraz konstrukcji SI jest dążenie do minimalizacji luki pomiędzy myśleniem o rzeczywistym problemie a myśleniem o danych i procesach zachodzących na danych.”

Percepcja rzeczywistego

świata

Analitycznymodel

rzeczywistości

Model struktur danych

i procesów SI

... ... ...... ... ...... ... ...

... ... ...... ... ...... ... ...

odwzorowanie odwzorowanie

Źródło: K. Subieta, Wprowadzenie do inżynierii oprogramowania, Wydawnictwo PJWSTK, Warszawa 2002.

Klasyfikacja metodyk tworzenia SIKlasyfikacja metodyk tworzenia SIKryteria oceny metodyk:

podejście do procesu tworzenia SI (metodyki techniczne lub społeczne)definiowanie danych lub procesów w projekcie (podejście strukturalne)oddziaływanie SI na dziedzinę przedmiotową (organizacyjne odwzorowanie, organizacyjne sterowanie)kierunek tworzenia systemów informatycznych (top-down, buttom-up)

Podejścia metodologiczne do tworzenia SIstrukturalne obiektowe społeczne


Etapy tworzenia, wdrażania i stabilizacji SIEtapy tworzenia, wdrażania i stabilizacji SI

Monitoring, ocena i modyfikacje systemuUruchomienie (realizacja)

Instalacja i stworzenie dokumentacji systemu oraz testowanie systemu (w wypadku niepowodzenia powrót do etapu analizy lub projektowania)

Wdrożenie (zastosowanie, aplikacja)

Oprogramowanie modelu, konstrukcja programu przetwarzającego system

Oprogramowanie (kodowanie)

Stworzenie modelu obecnego lub przyszłego systemu, projekt techniczny systemu lub zmian

Projekt systemu

Identyfikacja otoczenia, łączności z otoczeniem, podsystemów, składowych systemu oraz obecnych i przyszłych warunków jego działania

Analiza informacyjna systemu

Identyfikacja celu, problemów, stanu obecnego i perspektyw rozwoju systemu lub jego zmian

Wstępne rozpoznanie systemu (identyfikacja, analiza możliwości, postawienie problemu)

ZadaniaEtapy

Cykl życia systemuCykl życia systemu

Cykl życia systemu to ciąg wyodrębnionych, wzajemnie spójnych etapów, pozwalających na pełne i skuteczne zaprojektowanie a następnie użytkowanie systemu informatycznego

Modele cyklu życia systemuliniowy (tradycyjny, kaskadowy, wodospadowy)spiralnyprototypowy


Tradycyjne cykle życia oprogramowaniaTradycyjne cykle życia oprogramowania

Cykl klasyczny (kaskadowy)Model V wytwarzania z zapewnianiem jakościPrototypowanie wymagańModel spiralnyModel przyrostowy

Źródło: S. Szejko (red.), Metody wytwarzania oprogramowania, Wyd. MIKOM, Warszawa 2002.

Klasyczny cykl życia systemu z iteracjamiKlasyczny cykl życia systemu z iteracjami

PLANOWANIE

WDROŻENIE

ANALIZA WYMAGAŃ

PROJEKTOWANIE

IMPLEMENTACJA

TESTOWANIE I INTEGRACJA

UTRZYMANIE

?


Schemat wytwarzania według modelu VSchemat wytwarzania według modelu V

WYMAGANIA

MODEL LOGICZNY

PROJEKT SYSTEMU

PROGRAMOWANIE

PROJEKT SZCZEGÓŁOWY TESTOWANIE JEDNOSTEK

TESTY SYSTEMOWEI INTEGRACYJNE

TESTY WALIDACYJNE

TESTY AKCEPTACYJNE

Q

Q

Q

Q Q

Q

Q

Q


Schemat prototypowaniaSchemat prototypowania

PLANOWANIE WSTĘPNE

ANALIZAWYMAGAŃ

PROJEKTOWANIE

IMPLEMENTACJA,TESTOWANIE

UTRZYMANIE,OPEROWANIE

ZGRUBNA ANALIZA WYMAGAŃ

PROJEKT I REALIZACJA PROTOTYPU

PROTOTYP

WYMAGANIA

MODYFIKACJA

OCENA


Cykl spiralny wytwarzania oprogramowaniaCykl spiralny wytwarzania oprogramowania

PLANOWANIE ANALIZA RYZYKA

KONSTRUKCJAOCENA UŻYTKOWA

WSTĘPNE WYMAGANIAI PLANOWANIE PROJEKTU

PLANOWANIE NA PODSTAWIE

OCEN UŻYTKOWNIKA

ANALIZA RYZYKA OPARTA NA WSTĘPNYCH WYMAGANIACH

ANALIZA RYZYKA OPARTA NA REAKCJI

UŻYTKOWNIKA

KOLEJNE PROTOTYPY –

KU WERSJI DOCELOWEJ

OCENY DOKONYWANE PRZEZ UŻYTKOWNIKA


Podejście przyrostowePodejście przyrostowe

USTALENIE KSZTAŁTU SYSTEMU

SPECYFIKACJA PRZYROSTU

KONSTRUKCJA PRZYROSTU WALIDACJA

KONIEC?KOLEJNY PRZYROST

UKOŃCZONY SYSTEM

N

T


Współczesne cykle wytwarzania oprogramowaniaWspółczesne cykle wytwarzania oprogramowania

Prototypowanie wytwórczeCykl wytwarzania obiektowegoProces wytwarzania z wykorzystaniem zasobów ponownego użyciaCykl życia systemu według metodyki SSM (Soft Systems Methodology)


Procesy prototypowania wytwórczegoProcesy prototypowania wytwórczego

PLANOWANIE WSTĘPNE

ANALIZA WYMAGAŃ

ZGRUBNA ANALIZA

IDENTYFIKACJA WYMAGAŃ

SPECYFIKACJA

OCENA

MODYFIKACJA

PROTOTYP WYMAGAŃ

PROTOTYP KONSTRUKCYJNY

SYSTEM DOCELOWY

OCENA

MODYFIKACJA

PROJEKT I REALIZACJA PROTOTYPU

PROTOTYPOWANIE KONSTRUKCJI

PROTOTYPOWANIE

WYMAGAŃ


Uproszczony cykl życia systemu realizowanego Uproszczony cykl życia systemu realizowanego w podejściu obiektowymw podejściu obiektowym

UTRZYMANIE

TESTOWANIE

IMPLEMENTACJA

PROJEKT

ANALIZA


Fontannowy model cyklu życia oprogramowania Fontannowy model cyklu życia oprogramowania w podejściu obiektowymw podejściu obiektowym

RZECZYWISTOŚĆ

Analiza wymagań

Definiowanie wymagań użytkownika

Definiowanie wymagań programowych

Projektowanie systemuProjektowanie programuKodowanieTestowanie modułów

Testowanie systemu

Użytkowanie

Dalszy rozwójUtrzymanie


Zasoby ponownego użyciaZasoby ponownego użycia

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)


Wzorce oprogramowaniaWzorce oprogramowania

wzorce analizy (analysis patterns)wzorce projektowe (design patterns)wzorce architektoniczne (architecture patterns)wzorce aplikacji (application frameworks)


Problemy utrzymania oprogramowaniaProblemy utrzymania oprogramowania

ewolucja oprogramowania (pielęgnacja, modernizacja, zastępowanie)zarządzanie zmianamiinżynieria odwrotnaponowna inżynieria oprogramowania


Technologie wytwarzania oprogramowaniaTechnologie wytwarzania oprogramowania

Technologia strukturalnaTechnologia obiektowa

Ogólne zasady (niezależnie od technologii):Ogólne zasady (niezależnie od technologii):

zasada dekompozycji

zasada modularyzacji


Podejścia technicznePodejścia techniczne(ang. (ang. hard approacheshard approaches))

Cykle życia i wytwarzania oprogramowania bazujące na następujących założeniach:istnieje dobrze identyfikowalny wycinek rzeczywistości, o pewnym stanie i uporządkowaniu, który może być przedmiotem informatyzacji,cele analizy i konstrukcji systemu są jasne i znane, a docelowy system jest dobrze określony,przejście od stanu aktualnego do systemu docelowego może być zrealizowane środkami technicznymi,możliwe jest porównanie systemu docelowego z istniejącym, przy użyciu miar technicznych,procesy analizy i konstrukcji wykonywane są przez ekspertów.

Do podejść technicznych należą m.in. cykl kaskadowy, model spiralny, prototypowanie wytwórcze, podejście przyrostowe, model fontannowy, ponowne wytwarzanie.


Podejścia społecznePodejścia społeczne(ang. (ang. soft approachessoft approaches))

zakładają 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).


Technologia strukturalna Technologia strukturalna –– ogólna charakterystykaogólna charakterystyka

wytwarzanie oprogramowania według reguł cyklu klasycznegoutworzenie logicznego modelu systemu poprzedza modelowanie fizycznedominuje w latach 80-tych i na początku lat 90-tychtwórcy i metodyki: DeMarco, Yourdon, Constantine, Structured Analysis/Structured Design (S.A./SD) Yourdona, S.A./SD/RT Warda i Mellora (dot. systemów czasu rzeczywistego), SSADM (połączenie podejścia strukturalnego z ukierunkowaniem na organizację danych)notacje graficzne: diagramy przepływu danych, diagramy przejść stanów, diagramy związków encji, diagramy struktury


Metody strukturalneMetody strukturalne

Podstawowe metody strukturalne analizy i projektowania systemów informacyjnych:

Modele związków encji (diagramy związków encji, diagramy relacyjne danych, Entity Relationship Diagrams, Entity Relationship Models)Diagramy przepływu danych (diagram bąbli, DataFlow Diagram)Słownik/Skorowidz danych (Data Dictionary)Specyfikacje procesów (Process Specification)Diagramy sieci przejść (State Transition Diagram)Grafy podejścia ISAC (Information Systems Work and Analysis of Changes)Techniki decyzyjne (tablice, drzewa decyzyjne)Diagramy struktury (Structure Charts)

Modele związków Modele związków encjiencjiEntity Relationship Models (ERM)/Chen, The Entity-Relationship Model: Toward a Unified View of Data, CISR, Working Paper, Cambridge Massachusetts Institute of Technology, 1977, nr 30/

Modelowanie danych – podstawowe pojęciaencja, typ encji,relacja, typ relacji (związek, typ związku),atrybut, atrybut kluczowy,reinterpretowana relacja, typ relacji,notacje relacji, związków

Modelowanie danych Modelowanie danych –– podstawowe pojęciapodstawowe pojęciaTY

PY E

NC

JI /

REL

AC

JIEN

CJE

/R

ELA

CJE

ATR

YBU

TYD

ZIED

ZIN

YW

AR

TOŚC

I

MAGAZYNNR 56 38,5 KOWALSKI JAN GDAŃSK

DŁUGA 11 28 960ARTYKUŁYSKÓRZANE 125 m.2 7SOPOT

SĘPIA 12

Nazw

a

Adr

es

SpecjalizacjaPowierzchnia użytkowa

Liczba pomieszczeń Śred

ni c

zas

prac

y

tygo

dnio

wo

Nazwisk

o

Imię

Adre

s

Wie

k

Średnia płaca

MAGAZYN PRACOWNIK

MAGAZYNNR 56 ZATRUDNIA KOWALSKI


Przykład modelu danych (ARIS Przykład modelu danych (ARIS –– ERM)ERM)typy encji: klient, produkttyp relacji: kupujeatrybuty kluczowe: Nr klienta, Nr produktu, ...atrybuty: Nazwisko klienta, Nazwa produktu, Cena, ...

klient produktkupuje

NrKlientaNrKlienta,

NrProduktuNrProduktu

Nazwiskoklienta

Adresklienta

Nazwaproduktu

Cenajednostkowa

Typy relacji między zbiorami (stopnie związków)Typy relacji między zbiorami (stopnie związków)

***

***

***

*

*

***

*

*

***

***

W relacji 1:1 każdy element pierwszego zbioru jest przyporządkowany dokładnie jednemu elementowi drugiego zbioru i odwrotnie.

W relacji 1:n każdy element pierwszego zbioru jest przyporządkowany n elementom drugiego zbioru, a każdy element drugiego zbioru jest przyporządkowany tylko jednemu elementowi pierwszego zbioru.

W relacji n:1 każdy element pierwszego zbioru jest przyporządkowany tylko jednemu elementowi drugiego zbioru, a każdy element drugiego zbioru jest przyporządkowany n elementom pierwszego zbioru.

W relacji n:m każdy element pierwszego zbioru jest przyporządkowany wielu elementom drugiego zbioru i odwrotnie.

relacja 1:1

relacja 1:n

relacja n:1

relacja n:m

Przykład związku 1:m wiążącego klientaPrzykład związku 1:m wiążącego klientai dokonywane przez niego zakupy produktówi dokonywane przez niego zakupy produktów

1 m

KLIENT ZAKUP PRODUKT

Id_klienta Dane_k Data_ zakupu Czas_trwania_ transakcji Id_prod Dane_p


SKLEP

TOWARsprzedaje

jestsprzedawany

Każdy SKLEP sprzedajejeden lub więcej TOWARÓW

Każdy TOWAR jest sprzedawanyw jednym lub więcej SKLEPACH

c)


WYDZIAŁ

PRACOWNIKzatrudnia

jestzatrudniony

Każdy WYDZIAŁ zatrudniajednego lub więcej PRACOWNIKÓW

Każdy PRACOWNIK jest zatrudnionytylko na jednym WYDZIALE

b)

D I A G R A M

KLIENT

KONTO

należydo

ma

Każde KONTO należy tylko do jednego KLIENTA

Każdy KLIENT ma tylko jedno KONTO

a)

Typy relacji Typy relacji –– przykład konwencji graficznejprzykład konwencji graficznej

Pełny diagram związków Pełny diagram związków encjiencji

DOSTAWCADOSTAWCAZAPASZAPASTOWARTOWARKLIENTKLIENT

ZAMÓWIENIEZAMÓWIENIEMAGAZYNMAGAZYN

zaopatruje

składa

jestprzekazywany

przekazuje

zaopatruje sięw

dotyczy jest składane

jest dostarczonyprzezma postać

jest zamawiany

zaopatrujew


DPD DPD -- podstawowe pojęciapodstawowe pojęcia

Źródło lub przeznaczenie danych – zewnętrzne obiekty, z którymi system komunikuje się, tj. osoby, działy, jednostki organizacyjne, inny system informatyczny

4. TERMINATOR(OBIEKT

ZEWNĘTRZNY)

Kolekcja danych, które muszą być przechowywane w systemie przez określony czas, służy do modelowania danych w bezruchu

3. SKŁADNICA DANYCH

(MAGAZYN)

Powiązanie między procesami i innymi kategoriami DPD, służy do opisania przenoszenia jednostek lub pakietów informacji z jednego fragmentu systemu do innego, przedstawia dane w ruchu

2. PRZEPŁYW DANYCH

Funkcja - działalność gospodarcza realizowana w systemie, przekształcająca dane wejściowe w wynikowe

1. PROCES

ZnaczenieZnaczeniePojęciePojęcie


Diagramy przepływu danych Diagramy przepływu danych -- symbole graficznesymbole graficzneGANE-

-SARSONYOURDON--DEMARCO

Proces

Przepływ

Składnica

Terminator


Rozszerzenia Rozszerzenia WardaWarda--MelloraMellora

Ciągły przepływ danych (ang. continuous data flow) – stanowi „ciągłe” połączenie między procesami.Ciągły przepływ

danych

Transformacja sterująca (ang. control process) – dokonuje przekształceń sterowania (akceptuje i generuje przepływ sterowania, akceptuje też dane ze składnic).

Magazyn danych sterujących (ang. control store) – reprezentuje zbiór sygnałów sterujących pamiętanych przez system.

Transformacje

Magazyn danych sterujących

Przepływ sterowania (ang. control flow) – reprezentuje przepływ sygnałów sterujących lub zdarzeń. Rozróżnia się trzy klasy możliwych zdarzeń: zdarzenia przychodzące do systemu z zewnątrz (z terminatorów), zdarzenia związane z upływem czasu oraz zdarzenia powstające w systemie na skutek wykonywanych transformacji (np. przyczyną zdarzenia może być spadek poziomu zapasów magazynowych poniżej wymaganego poziomu).

Przepływsterowania

Transformacja sterująca

Transformacje (ang. processes) – reprezentują wielokrotne wystąpienia tego samego procesu.


Rozszerzenia Rozszerzenia HatleyaHatleya--PirbhaiaPirbhaia

Przepływsterowania

Przepływ sterowania (ang. control flow) – reprezentuje przepływ danych sterujących tj. sygnałów, przerwań lub zdarzeń.

Reguły decyzji (ang. vertical bar) – odnośnik do specyfikacji sterowania opisującej zachowanie systemu i definiującej uruchamianie lub zatrzymywanie procesów jako konsekwencję zdarzeń.Reguły decyzji


Zależności pomiędzy podstawowymi kategoriami DPDZależności pomiędzy podstawowymi kategoriami DPD

Obiektzewnętrzny(terminator)

Obiektzewnętrzny(terminator)

Składnicadanych

Przepływdanych

Składnicadanych

ProcesProcesPrzepływdanych


Przykład DPD: Klient pyta o stan zamówieniaPrzykład DPD: Klient pyta o stan zamówienia

KLIENCI

ID-klienta + zapytanie-o-stan-

zamówienia

MAGAZYNYMAGAZYNY

odpowiedź-ze-stanem-zamówienia

ID-magazynu + numer-faktury +

kod-stanu

numer-faktury + odpowiedź-o-stanie

KLIENCI

5.ODPOWIEDZ

NA ZAPYTANIEO STAN

ZAMÓWIENIA

5.ODPOWIEDZ

NA ZAPYTANIEO STAN

ZAMÓWIENIA

ZAMÓWIENIA POZYCJE ZAMÓWIEŃ

Słownik danychSłownik danychSłownik danych to uporządkowany wykaz wszystkich elementów Słownik danych to uporządkowany wykaz wszystkich elementów danych mających związek z systemem, wraz z ich precyzyjnym danych mających związek z systemem, wraz z ich precyzyjnym określeniem, aby użytkownik i analityk jednakowo rozumieli określeniem, aby użytkownik i analityk jednakowo rozumieli wszystkie wejścia, wyjścia, składniki magazynów (składnic danychwszystkie wejścia, wyjścia, składniki magazynów (składnic danych))

Słownik danych definiuje elementy danych w następujący sposób:Słownik danych definiuje elementy danych w następujący sposób:opisując znaczenie przepływów i magazynów pokazanych na diagramach przepływu danych,opisując budowę złożonych pakietów danych transmitowanych wzdłuż przepływów, tzn. pakietów (takich jak adres klienta), które można rozbić na bardziej elementarne jednostki (takie jak miasto, kod pocztowy, ulica),opisując budowę pakietów danych w magazynach,określając właściwe wartości i jednostki elementarnych porcji informacji dla przepływów i magazynów danych.

Notacja słownika danychNotacja słownika danych

Specyfikacje procesówSpecyfikacje procesówSpecyfikacje procesów określają co się dzieje wewnątrz każdego elementarnego procesu na najniższym poziomie przepływu danychSpecyfikacje procesów stanowią szczegółowy opis reguł działania podanych przez użytkownika, które realizuje procesDo stworzenia specyfikacji procesów można użyć narzędzi:

technik decyzyjnychstrukturalnego języka polskiego (angielskiego)warunków początkowych i końcowychdiagramów przepływu sterowaniadiagramów Nassi-Schneidermana

Specyfikacja procesu musi mieć taką postać, by była możliwa jej weryfikacja przez użytkownika i analitykaSpecyfikacja procesu musi być wyrażona w postaci pozwalającej na efektywną komunikację z różnymi kręgami słuchaczy

Strukturalny język polskiStrukturalny język polskiInne nazwy określające strukturalny język polski:

PDL (Program Design Language – język projektowania programów)PSL (Problem Statement Language lub Problem Specification Language – język specyfikacji problemów)

Strukturalny język polski ma zapewniać osiągnięcie rozsądnego kompromisu między precyzją formalnego języka programowania a swobodą i czytelnością języka polskiegoZdanie w strukturalnym języku polskim może być równaniem algebraicznym lub prostym zdaniem rozkazującym, składającym się z czasownika i dopełnienia, np.

OBLICZ X=(Y*Z)/(Q+14)POMNÓŻ CENA-JEDNOSTKOWA PRZEZ ILOŚĆ

Obiekty powinny składać się z elementów danych zdefiniowanych w słowniku danychKonstrukcje i metody łączenia zdań zaczerpnięto ze znanych języków programowania

IF-THEN-ELSE, CASE, DO-WHILE, REPEAT-UNTILZalecenia dla analityka:

ogranicz strukturalne specyfikacje procesów w języku polskim do pojedynczej strony tekstunie stosuj więcej niż trzech poziomów zagnieżdżenia strukturstosuj wcięcia dla uniknięcia pomyłek w interpretacji zagnieżdżenia

Warunki początkowe i końcoweWarunki początkowe i końcowe

Tablice decyzyjneTablice decyzyjne

Przykład tablicy decyzyjnejPrzykład tablicy decyzyjnej

1 2 3 4 5 6 7 8Wiek > 21 T T T T N N N NPłeć M M K K M M K KWaga < 150 T N T N T N T NLekarstwo 1 X X XLekarstwo 2 X XLekarstwo 3 X X XBez lekarstwa X X

Drzewa decyzyjneDrzewa decyzyjneDrzewo decyzyjne przyznawania kredytu bankowegoDrzewo decyzyjne przyznawania kredytu bankowego

D

<1

>=1

Wn <18 – pełny kredytWn <18 – pełny kredyt

Wn >=18 – pełny kredyt z podwyższonym oprocentowaniem

Wn >=18 – pełny kredyt z podwyższonym oprocentowaniem

Wn <18 – kredyt w ograniczonej wysokościWn <18 – kredyt w ograniczonej wysokości

Wn >=18 – nie przyznawać kredytuWn >=18 – nie przyznawać kredytu

Wskaźnik D Wskaźnik Wn


Diagramy sieci przejść (diagramy przejść stanówDiagramy sieci przejść (diagramy przejść stanów))Przykład: „Automat sprzedający”Przykład: „Automat sprzedający”

Otwarto drzwi

Gotowe

Wrzucono monetęWyświetl sumę

Wybór OKAkceptacja monet

Wydaj resztę

Produkt zwolnionyInicjuj kom1

Inicjuj kom2

Wrzucono monetęWyświetl sumę

Żądanie zwrotuZeruj

Wyświetl sumę

WOLNY – OCZEKIWANIENA MONETĘ

OCZEKIWANIENA WYBÓR

ZWOLNIENIE PRODUKTUI WYDANIE RESZTY

OCZEKIWANIENA POBRANIE PRODUKTU

Nieakceptowalna moneta


Diagramy strukturyDiagramy strukturyPrzykład dla zadania z projektu Przykład dla zadania z projektu „Automat sprzedający”„Automat sprzedający”

Ilość

Wybór OKWybrany produkt

Czy inicjować kom3/kom4

CenaSuma wpłat

Wybór produktu

Ilość

Wybrany produkt

Suma wpłat

Wybór produktu

Ilość

Cena

Suma wpłat

OK

IlośćWybrany produkt

Wybór OK

Wybrany produktCzy wydać

resztęSuma wpłat

Wybrany produkt

Wielkość resztyWielkość

resztySuma wpłat

Wybrany produkt

Przepływ danychPrzepływ danych sterujących

MODUŁ STERUJĄCY JEDNOSTKI SPRAWDZENIA I ZWOLNIENIA

SPRAWDZENIE ZWALNIANIEI OBLICZANIE RESZTY

14.1SPRAWDŹ

DOSTĘPNOŚĆ PRODUKTU

14.2SPRAWDŹ

SUMĘWPŁAT

ZARZĄDZANIE RESZTĄ

ZWOLNIENIE PRODUKTU

OBLICZENIE RESZTY

WYSŁANIEDO 4b (Pr. 3)


Kryteria oceny struktury oprogramowaniaKryteria oceny struktury oprogramowaniaspójność modułów; dotyczy wewnętrznego powiązania i ukrycia informacji wewnątrz poszczególnych modułów (cohesion)stopień wzajemnych powiązań (zależności) pomiędzy modułami (coupling)widzialność konstrukcji na różnych poziomach abstrakcji (visibility)podatność na zmiany (adaptability)modularność; jakość dekompozycji na części składowe (factoring)stopień równowagi pomiędzy modularnością a złożonością funkcji wmodułach (restricitivity/generality)klarowność powiązania między konstrukcjami rozpoznawania sytuacji wyjątkowych i błędów a konstrukcjami ich obsługiunikanie takiej konstrukcji modułów, że ich zachowanie zależy od historii ich działaniakażdy moduł powinien mieć możliwie wiele wywołujących jego funkcje poprzedników oraz niewiele następników


Podejście strukturalne Podejście strukturalne –– zalety i wadyzalety i wadyZalety:

uwzględnienie wszystkich podstawowych faz cyklu życia oprogramowania, z podziałem na fazy analizy i projektowaniaintuicyjność spojrzenia na system poprzez funkcje, procesy i przepływy danychpołożenie nacisku na modelowanie na poziomie logicznym, i skupienie uwagi dopiero w dalszej kolejności na szczegółach implementacyjnychwprowadzenie „standardów” w zakresie modeli i notacji graficznychwykorzystywanie narzędzi CASE

Wady:wysoka pracochłonnośćtrudności w iteracyjnym modyfikowaniu projektustosowanie odmiennych modeli w fazie analizy i w fazie projektowania


Technologia obiektowa Technologia obiektowa –– ogólna charakterystykaogólna charakterystyka

Geneza Geneza obiektowościobiektowościobiektowość jest nową ideologią w dziedzinach programowania, baz danych oraz analizy i projektowania systemów informatycznych,stara się o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a myśleniem o danych i procesach, które zachodzą na danych,podejście zorientowane obiektowo (object-oriented) wywodzi się z obiektowych języków programowania (Smalltalk, Simula, Ada),

Metodologie w nurcie obiektowymMetodologie w nurcie obiektowymwykształciło się wiele różniących się pomiędzy sobą metodologii:podejściem, językiem graficznych odwzorowań oraz procedurą postępowania, np.:

metodyka Boocha (OOD) 1991metodyka OMT (Object Modelling Technique) Rumbaugha 1991metodyka Coada-Yourdona (OOA/OOD) 1991metodyka Fusion (HP)

unifikacja metod modelowania została zapoczątkowana przez Boocha’a i Rumbaugh, 1994, firma RationalUML UML –– Unified Modeling LanguageUnified Modeling Language – pierwsza wersja 1995podstawowe pojęcia i założenia ideologii pozostają wspólne dla różnych podejść

Technologia obiektowa Technologia obiektowa –– zachęcam do studiowaniazachęcam do studiowaniaAlhir S.S., UML. Wprowadzenie, Wydawnictwo Helion, Gliwice 2004.Avison D., Fitzgerald G., Information Systems Development: Methodologies, Techniques, and Tools, McGraw-Hill, 2003.Bennett S., McRobb S., Farmer R., Object-Oriented Systems Analysis and Design using UML, McGraw-Hill, 2002.Bernus P., Mertins K., Schmidt G. (eds.), Handbook on Architectures of Information Systems, Springer, Berlin Heidelberg 1998.Bluemke I., Inżynieria oprogramowania, Wyższa Szkoła Informatyki Stosowanej i Zarządzania, Warszawa 2001.Booch G., Rumbaugh J., Jacobson I., UML przewodnik użytkownika, Wydawnictwa Naukowo-Techniczne WN-T, Warszawa 2002.Chabik J., Obiektowość – technologia, technika, praktyka, Jesienna Szkoła PTI, Mrągowo 1999.Fowler M., Scott K., UML w kropelce, Oficyna Wydawnicza LTP, Warszawa 2002.Fowler M., with contributions from D. Rice, M. Foemmel, E. Hieatt, R. Mee, R. Stafford, Patterns of Enterprise Application Architecture, Addison-Wesley, Pearson Education 2003.Kim Ch.-H., Weston R.H., Hodgson A., Lee K.-H., The complementary use of IDEF and UML modelling approaches, Computers in Industry 50(2003), 35-56.Lethbridge T.C., Laganière R., Object-Oriented Software Engineering. Practical software development using UML and Java, McGraw-Hill 2001.Mellor S.J., Balcer M.J., Executable UML. A Foundation for Model-Driven Architecture, Addison-Wesley 2002.Pilone D., UML. Leksykon kieszonkowy, Wydawnictwo Helion, Gliwice 2003.towanie systemów informatycznych, Wydawnictwo PJWSTK, Warszawa 2003.tycznych, Wydawnictwo PJWSTK, Warszawa 2003.ional Rose, dokumentacja programu, Rational Software Corporation 2001 (b).).owym, Wydawnictwo Helion, Gliwice 2003.J.R., Projektowanie zorientowane obiektowo. Wzorce projektowe, Wydawnictwo Helion, Gliwice 2002.ion, Gliwice 2002.Addison-Wesley, 2000.minów z zakresu obiektowości, Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999 (a).o obiektowych metodyk projektowania i notacji UML (Unified Modeling Language), Jedenasta Górska Szkoła PTI, ktowych metodyk projektowania i notacji UML (Unified Modeling Language), Jedenasta Górska Szkoła PTI, Szczyrk yrk 1999 (b).cis P., Wykorzystanie notacji UML do prowadzenia prac związanych z modelowaniem procesów biznesowych, mat. . Konferencji „Modelowanie procesów biznesowych, organizator Software Konferencje, Warszawa 19-20 listopada 2003., organizator Software Konferencje, Warszawa 19-20 listopada 2003.

ObiektowośćObiektowość -- podstawowe pojęcia podstawowe pojęcia

Obiekt Obiekt Tożsamość obiektuTożsamość obiektu, identyfikator, identyfikatorAtrybuty i metody obiektówAtrybuty i metody obiektówPolimorfizmPolimorfizmPrzesyłanie komunikatówPrzesyłanie komunikatówKlasy obiektów, hierarchie klasKlasy obiektów, hierarchie klasDziedziczenieDziedziczenieEnkapsulacja Enkapsulacja (hermetyzacja)(hermetyzacja)Unified Modeling Language Unified Modeling Language

ObiektObiektObiekt Obiekt to byt (rzecz lub pojęcie) obserwowalny w to byt (rzecz lub pojęcie) obserwowalny w dziedzinie przedmiotowej, czyli w tym fragmencie świata dziedzinie przedmiotowej, czyli w tym fragmencie świata rzeczywistego, którego dotyczy dany system rzeczywistego, którego dotyczy dany system informacyjny, odróżnialny od innych bytów, posiadający informacyjny, odróżnialny od innych bytów, posiadający dobrze określone granice oraz nazwędobrze określone granice oraz nazwę

Obiekt może być złożony, tj. może składać się z innych obiektówObiekt traktujemy jako całość i opisujemy go pewnymi cechami –atrybutami (zmiennymi) i zachowaniami - metodamiObiektem może być Klient, Pracownik, Jan Kowalski, Bilans, Konto, Magazyn-odzieżowyPojęcie obiektu sprzyja lepszemu rozumieniu modelowanego świata rzeczywistego

Model obiektów świata rzeczywistegoModel obiektów świata rzeczywistego –– abstrakcja abstrakcja jakiegoś bytu (rzeczywistego lub mentalnego) zdolna do jakiegoś bytu (rzeczywistego lub mentalnego) zdolna do przechowywania pewnych informacji oraz zdolna do przechowywania pewnych informacji oraz zdolna do wykonywania określonych operacji na tych wykonywania określonych operacji na tych informacjach, a także współdziałania z innymi obiektamiinformacjach, a także współdziałania z innymi obiektami

Tożsamość obiektuTożsamość obiektuObiekt jest wyróżnialny w otaczającym nas świecie poprzez swoje istnienie

Może się zdarzyć, że z punktu widzenia naszych obserwacji (tj. stanu obiektu) dwa obiekty są nieodróżnialne. Niemniej jednak są to dwa różneobiektyKażdemu obiektowi przypisuje się unikalny identyfikatoridentyfikatorIdentyfikator przyporządkowany jest automatycznie przez obiektowo zorientowany język programowania lub system obiektowej bazy danych. Mechanizm identyfikatorów pozwala na rozróżnianie obiektów, identyfikator jest atrybutem „wewnętrznym” obiektu

Atrybuty i metody obiektówAtrybuty i metody obiektówKażdy obiekt zawiera dane (atrybuty i wartości) i procesy (metody)Każdy obiekt posiada jeden lub więcej atrybutów oraz jedną lub więcej metodAtrybutAtrybut to określony, pojedynczy składnik danych w obiekcie

Wszystko, co wiadomo o obiekcie zawarte jest w jego atrybutachWartości atrybutów obiektu zmieniają się w czasie i stanie obiektu. Stan obiektuStan obiektu w danym momencie jest określony przez aktualne wartości jego atrybutów i powiązań z innymi obiektami

Wszystkie interakcje obiektu – zachowania wyrażone są w metodachmetodach.

Metody, to wbudowane w obiekt procesy, które operują na wartościach atrybutówMetody zapewniają współdziałanie obiektów w modelu obiektowymWyróżniamy:

Metody zewnętrzne (public)Metody wewnętrzne (private)

Przykład: obiekt ZAMÓWIENIEPrzykład: obiekt ZAMÓWIENIE

Obliczaj

ModyfikujAnuluj

DrukujSkładaj Nazwa klienta ........Adres......................Data........................Wartość zam...........

AtrybutyAtrybuty

MetodaMetoda


Przykład: obiekt KONTOPrzykład: obiekt KONTO

Zlikwidujkonto

UpoważnijPorównaj

podpis

Wpłać

Naliczprocent

Podaj daneosoby

upoważnionej

WypłaćSprawdźstan

Numer: 123-4321Stan konta: 34567 PLNWłaściciel: Jan KowalskiUpoważniony: ...Podpis: …....

PolimorfizmPolimorfizmPolimorfizmPolimorfizm oznacza, że ta sama nazwa może odnosić się do różnych metod w różnych obiektach. Podobnie metody o różnych nazwach mogą realizować identyczne procedury – może istnieć wiele metod implementujących daną operacjęPolimorfizm oznacza „wiele form”, „wiele postaci” jednego bytuPrzykład:

metoda „Wybierz numer” zdefiniowana w klasie „Telefon” będzie inaczej realizowana w obiekcie klasy „Telefon stacjonarny” a inaczej w obiekcie klasy „Telefon komórkowy”. Użytkownik obiektów (program) nie musi ich odróżniać: otrzymany obiekt potraktuje jako obiekt klasy „Telefon” i użyje metody „Wybierz numer”. System obiektowy wybierze odpowiednią implementację

KomunikatyKomunikatyObiekty w systemie kontaktują się między sobą poprzez przesyłane komunikaty komunikaty (messages)

Komunikaty stanowią żądanie jednego obiektu w stosunku do drugiego, aby zrealizować jedną z jego metodObiekt-odbiorca odpowiada na komunikat uaktywnieniem wskazanej przez komunikat obiektu-nadawcy metodyKomunikaty powodują zmiany stanu obiektów Każdy komunikat wysyłany przez obiekt-nadawcę składa się z trzech części:

identyfikatora obiektu-odbiorcymetody, którą obiekt-odbiorca powinien wykonaćdodatkowych parametrów, niezbędnych obiektowi-odbiorcy dla wykonania wskazanej metody

Klasy obiektówKlasy obiektówObiekty w systemie (programie) pogrupowane są w klasyKlasa Klasa to zbiór obiektów podobnych do siebie, o tej samej strukturze danych - mających te same zestawy atrybutów i metod

Obiekty jednej klasy reprezentują ten sam rodzaj bytów im odpowiadającychKlasa obiektu jest uogólnieniem (ang. template) danego rodzaju obiektuKażdy obiekt staje się wystąpieniem danej klasy obiektówPrzykład: obiekty opisujące klientów magazynu są egzemplarzami klasy „Klient”

Graficznie modele obiektowe opisywane są między innymi wdiagramach klas obiektów diagramach klas obiektów

kategoria klasy przedstawiana jest jako prostokąt składający się z trzech części:

nazwy klasyzestawu atrybutów zestawu metod

Przykład: oznaczenia klas obiektówPrzykład: oznaczenia klas obiektów

SKLEP

NazwaAdresBranżaPowierzchniaLiczba-zatrudnionych

UruchomienieDostawaZatrudnienie-pracownikaInwentaryzacjaPrzeprowadzenie-przeceny

PRACOWNIK

NazwiskoData-urodzeniaStażWykształcenieAdresGrupa-zaszeregowania

PrzyjęcieZmiana-adresuUbezpieczenieZmiana-grupy-zaszeregowaniaZwolnieniePrzejście-na-emeryturę


DziedziczenieDziedziczenieDziedziczenieDziedziczenie oznacza przyporządkowanie atrybutów i metod klasom obiektów na podstawie hierarchicznej zależności między nimiStruktura hierarchiczna klas obiektów uporządkowana jest z uwzględnieniem wzrastającej specjalizacji ich funkcji w dziedzinie przedmiotowej

uogólniona nadrzędna klasa obiektów w hierarchii nazywa się superklasąsuperklasąklasa podrzędna to subklasasubklasa (podklasa)subklasa jest wystąpieniem klasy, klasa jest wystąpieniem superklasygeneralizacja/specjalizacjageneralizacja/specjalizacja oznacza związki między klasami

Podklasa dziedziczy atrybuty i metody superklasy obiektu w danej hierarchii

każda klasa obiektów w hierarchii dziedziczy wszystkie atrybuty i metody superklasy i może mieć dodatkowe atrybuty i metodyatrybuty odnoszące się do wszystkich obiektów danej klasy są atrybutami klasy, natomiast odnoszące się do wystąpienia obiektu –atrybutami wystąpienia

Przykład: klasy obiektów Przykład: klasy obiektów –– dziedziczenie atrybutówdziedziczenie atrybutów

Nr-identyfikacyjnyNazwiskoImięData-urodzenia

Nr-identyfikacyjnyNazwiskoImięData-urodzenia

Data-obronyTemat-pracyPromotor

Data-obronyTemat-pracyPromotor

Rok-ukończenia-studiówSpecjalność-naukowaWydziałKatedra

Rok-ukończenia-studiówSpecjalność-naukowaWydziałKatedra

PRACOWNIKPRACOWNIK

ADIUNKTADIUNKT

PRACOWNIKPRACOWNIK--NAUKOWYNAUKOWY


EnkapsulacjaEnkapsulacjaKażdy obiekt stanowi oddzielny moduł –kapsułę oraz zawiera dane i procesy, umożliwiające odegranie określonej roli w systemieEnkapsulacjaEnkapsulacja oznacza wzajemną niezależność danych przechowywanych w różnych modułachEnkapsulacja to ukrywanie niektórych atrybutów lub metod (hermetyzacja)(hermetyzacja)

Dzięki enkapsulacji obiekty mogą być traktowane jako „czarne skrzynki”, udostępniające tylko potrzebne elementy i ukrywające pozostałeEnkapsulacja daje większą odporność na błędy Dokonując zmian obiektu (klasy) nie trzeba dzięki enkapsulacji zmieniać innych obiektów

Unified Modeling Language (UML)http://www.rational.com/uml(dokumentacja on line)RATIONAL SOFTWARE CORPORATION

UML 0.8-0.9, styczeń 1995 - wrzesień 1996UML 1.0, styczeń 1997, przesłany do OMGUML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMGUML 1.3, kwiecień 1999

Połączone siły trzech znanych metodologów oprogramowania:

Grady Booch Ivar Jacobson James Rumbaugh

K. Subieta, mat. PJWSTK udostępniane w Internecie

Model a diagramModel a diagram. M. Modeleodele w UMLw UML

Model - pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy,na określonym poziomie szczegółowości.

Diagram - środek służący do opisu modelu. Dany model może być opisany przy pomocywielu diagramów. Dany element modelu może pojawiać się na wielu diagramach jednego modelu.

Dwa najważniejsze modele w UML:

model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia),

model obiektowy przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty.

Głównym zadaniem pomocniczego modelu dynamicznego (zachowań) jest wypełnienie diagramu klas metodami wynikłymi z analizy zachowania systemu w trakcie wykonywania zadań, gdzie zadaniem może być np. realizacja przypadku użycia czy też jednego konkretnego scenariusza danego przypadku użycia.


Diagramy definiowane w UMLDiagramy definiowane w UML

Diagramy przypadków użycia (use case)

Diagramy klas

Diagramy dynamiczne (behavior):Diagramy stanówDiagramy aktywnościDiagramy interakcji:

Diagramy sekwencjiDiagramy współpracy (collaboration)

Diagramy implementacyjne:

Diagramy komponentówDiagramy wdrożeniowe (deployment)

Diagramy pakietów

Diagramy umozliwiają spojrzenie na system z różnych perspektyw


PrzykPrzykłłady diagramady diagramóów modelowania obiektowego w modelowania obiektowego utworzone za utworzone za

pomocą pomocą programu programu Rational Rose Enterprise EditionRational Rose Enterprise Edition

PrzykPrzykłłady diagramady diagramóów modelowania obiektowego programu ARISw modelowania obiektowego programu ARIS

PrzykPrzykłłady diagramady diagramóów modelowania obiektowego programuw modelowania obiektowego programu iGrafx ProcessiGrafx Process 2003 2003

forfor SixSix SigmaSigma

Notacja jNotacja jęęzyka UML na potrzeby tworzenia diagramzyka UML na potrzeby tworzenia diagramóów przypadkw przypadkóów uw użżyciaycia

Przypadek użycia C

Aktor Przypadek użycia B

Przypadek użycia A

Przypadek użycia

<<include>>

<<extend>>

uogólnienie

Diagram przypadków użyciaDiagram przypadków użycia„dla samoobsługowej stacji benzynowej”„dla samoobsługowej stacji benzynowej”

Dystrybutor

Kasjer

Klient

TANKOWANIE

PŁACENIE


Diagram przypadków użyciaDiagram przypadków użycia„dla stacji obsługi samochodów” (bez aktorów)„dla stacji obsługi samochodów” (bez aktorów)

«uses»

«extends»

REJESTRACJA POJAZDU

PRZEGLĄD TECHNICZNY

MYCIE


Diagram przypadków użycia „dla hotelu”Diagram przypadków użycia „dla hotelu”

Recepcjonista

Pokojowa

Gość

«uses»

ZAMELDOWANIE

WYMELDOWANIE

PŁACENIE

SPRZĄTNIĘCIE POKOJU


Notacja jNotacja jęęzyka UML na potrzeby zyka UML na potrzeby tworzenia diagramtworzenia diagramóów klasw klas (1)(1)

Nazwa klasyatrybut: Typ=wartośćPoczątkowa

operacja(lista argumentów):typ wyniku()

AAssooccjjaaccjjaa

Klasa A Klasa B+rola B

+rola A

UUooggóóllnniieenniiee ((ggeenneerraalliizzaaccjjaa))

Klasa bazowa (nadklasa)

Klasa specjalizacja 1 Klasa specjalizacja 2

NNaawwiiggoowwaallnnoośśćć ((aassooccjjaaccjjaa uukkiieerruunnkkoowwaannaa))

Źródło Celnazwa roli

ZZaalleeżżnnoośśćć

Klasa BKlasa A

Nazwa klasyatrybut1atrybut2atrybut3atrybut4

OOggrraanniicczzeenniiee SStteerreeoottyypp {opis ograniczenia} <<nazwa stereotypu>> AAssooccjjaaccjjaa kkwwaalliiffiikkoowwaannaa

Klasa

kwalifikatorkwalifikator

NNoottaattkkaa

tekst notatki

OObbiieekktt

nazwa obiektu : nazwa klasy

Nazwa klasy

opracja1()operacja2()operacja3()operacja4()

KKrroottnnoośśćć ((lliicczznnoośśćć)) aassooccjjaaccjjii

Klasa

11 ddookkłłaaddnniiee jjeeddeenn

Klasa** wwiieellee ((zzeerroo lluubb wwiięęcceejj))

Klasa

0..10..1 zzeerroo lluubb jjeeddeenn

Klasann ddookkłłaaddnniiee nn

Klasa

1..n1..n oodd jjeeddeenn ddoo nn

...

RRooddzzaajj aassooccjjaaccjjii

Klasa

agregacja

Klasa

zzaawwiieerraanniiee ((kkoommppoozzyyccjjaa;; aaggrreeggaaccjjaa ccaałłkkoowwiittaa)

Klasa *{uporządkowany} *

rroollaa uuppoorrzząąddkkoowwaannaa

KKllaassaa ppaarraammeettrryyzzoowwaannaa kkllaassaa wwzzoorrccoowwaa

Zbiór

KKllaassaa aassooccjjaaccyyjjnnaa ((kkllaassaa zzwwiiąązzaannaa,, kkllaassaa aassooccjjaaccjjii))

Klasa A Klasa B

Klasa asocjacyjna

IInntteerrffeejjssyy

T

Klasa implementująca

Nazwa interfejsu

Klasa-klientzależność

Notacja jNotacja jęęzyka UML na zyka UML na potrzeby tworzenia potrzeby tworzenia diagramdiagramóów klasw klas (2)(2)

Prosty diagram klas: samochody i ich właścicieleProsty diagram klas: samochody i ich właściciele

OSOBA

PeselNazwisko

AdresLiczebność

Podaj_opis()Podaj_liczeność

SAMOCHÓD

Numer_rejRok_prod

MarkaLiczebność

Podaj_opis()Podaj_liczebność

Podaj_średni_wiek()

Jest_właścicielem

*


Związek jako klasaZwiązek jako klasa

OSOBA

Nazwisko

FIRMA

Nazwa

Pracuje_w Zatrudnia

ZATRUDNIENIE

StanowiskoOkres_umowy

Płaca

Zawrzyj_umowę()Awansuj()

Rozwiąż_umowę()

1..* 1..*


Relacja agregacji (przykład: komputer i jego części Relacja agregacji (przykład: komputer i jego części składowe)składowe)

KOMPUTER

KONSOLA PROCESOR MODUŁ PAMIĘCI DYSK

1..* 1..*


Przykład hierarchii klas: a. Przykład hierarchii klas: a. –– bez redefinicji właściwości; bez redefinicji właściwości; b. b. –– z redefinicją właściwościz redefinicją właściwości

a.

OSOBA

NazwiskoAdres

Pokaż_dane()Zmień_adres()

STUDENT

Nr_albumuRok_studiów

PRACOWNIK

Nr_ewidTyp_zatrud

OSOBA

NazwiskoAdres


STUDENTNr_albumu

Rok_studiówAdres


PRACOWNIK

Nr_ewidTyp_zatrud

Pokaż_dane()

b.


Przykład hierarchii klas z Przykład hierarchii klas z wielodziedziczeniemwielodziedziczeniem

POJAZD

Producent

Środowisko{ overlapping }{ incomplete }

POJAZD LĄDOWY

Liczba_kółPrędkość_ląd

POJAZD WODNY

WypornośćPrędkość_wod

AMFIBIA


Diagram klas dla systemu obsługi hoteluDiagram klas dla systemu obsługi hotelu

OSOBANazwisko

Adres

GOŚĆData_odData_do

Zamelduj()Wymelduj()

HOTELNazwaAdres

PRACOWNIK

Typ_zatrud

RECEPCJONISTA

Posprzątaj()

POKOJOWA

Funkcja

POKÓJNumerStan

Zajmij()Zwolnij()Gotowy()

SPRZĄTANIEKiedy

Zatrudnia

Zajmuje

*

* *

1..*

1..*


Notacja jNotacja jęęzyka UML na potrzeby tworzenia diagramzyka UML na potrzeby tworzenia diagramóów stanw stanóóww

Nazwa stanu A

entry/ czynność 1do/ czynność 2exit/ czynność 3event zaszło zdarzenie/ czynność 4

Nazwa stanu Bzdarzenie[ warunek ] / akcja

Diagram stanów obiektu klasy FakturaDiagram stanów obiektu klasy Faktura

Utwórz fakturę

Zniszcz fakturęWpłata

NIEZAPŁACONA ZAPŁACONA


Elementy syntaktyczne do zapisu zdarzeń i stanówElementy syntaktyczne do zapisu zdarzeń i stanów

NAZWA

Zmienna1, …

Entry / Akcja entryExit / Akcja exitDo / Czynność

Zdarzenie(dane) / akcja

[ strażnik ]


Diagram stanów obiektu Diagram stanów obiektu WindaWinda

W górę (piętro)

W górę (piętro)

[ nie na ostatnim ]

PrzyjazdPrzyjazd

Przyjazd[ parter ]

Przyjazd[ nie parter ]

W dół (piętro)

[ zegar = limit_czasu ]

OCZEKIWANIE

Zegar = 0

Entry / BeepDo / Inkrementuj zegar

NA PARTERZE

Entry / Beep

JAZDA W GÓRĘ

Do / Jazda do piętra

JAZDANA PARTER

JAZDA W DÓŁ

Do / Jazda do piętra


Stan Stan LogowanieLogowanie i współbieżne stany w nim zagnieżdżonei współbieżne stany w nim zagnieżdżone

OK / login(ident, hasło)

LOGOWANIE

OKPODAJ IDENT

Login / display ”login”

PODAJ HASŁO

OKPomoc WYŚWIETL POMOC


Notacja jNotacja jęęzyka UML na potrzeby tworzenia diagramzyka UML na potrzeby tworzenia diagramóóww aktywności aktywności

(diagramów czynności)(diagramów czynności)początek

Czynność

Dynamiczna czynność współbieżna

Czynność A Czynność B

rozgałęzienie

koniec

scalenie

rozwidlenie

złączenie

[ jeżeli spełniony warunek ] [ w przeciwnym wypadku ]

Diagram czynności dla „przypadku użycia Diagram czynności dla „przypadku użycia Wymeldowanie”Wymeldowanie”

Gość Recepcjonista

ZGŁOSZENIE CHĘCI WYJAZDU

PŁACENIE I ZWROT KLUCZA

OPUSZCZENIE HOTELU

POLECENIEDLA POKOJOWEJ


Notacja jNotacja jęęzyka UML na potrzeby tworzenia diagramzyka UML na potrzeby tworzenia diagramóów sekwencjiw sekwencji

Obiekt

Nowy obiekt1. utwórz

2. komunikat2.1. samowywołanie

3. powrót

4. usuń

Typy komunikatów na diagramach Typy komunikatów na diagramach

Komunikat prosty

Komunikat synchroniczny

Komunikat synchronicznyz natychmiastowym powrotem

Komunikat asynchroniczny


Wykorzystywanie podstawowych elementów na Wykorzystywanie podstawowych elementów na diagramach sekwencji diagramach sekwencji -- przykładprzykład

Drukuj(plik)

[ kolejka pusta ]

:Program :Serwer wydruków :Drukarka

Drukuj(plik)

WydrukowanyWydrukowany


Diagram sekwencji dla „przypadków użycia Diagram sekwencji dla „przypadków użycia WymeldowanieWymeldowanie i i Sprzątnięcie pokoju”Sprzątnięcie pokoju”

GOŚĆ RECEPCJONISTA POKOJÓWKASYSTEM KOMPUTEROWY

Wyjeżdżam!Pokaż dane

Oto daneOto rachunek

Oto pieniądze

Bon voyage!

Wszystko OK

Posprzątaj pokój!

Pokój OK

Pokój OK


Diagram sekwencji z ograniczeniami czasowymi oraz Diagram sekwencji z ograniczeniami czasowymi oraz tworzeniem i usuwaniem obiektutworzeniem i usuwaniem obiektu

:Obiekt A

Komunikat

{ b-a < 1 s }

{ c-b < 5 s }

a

b

c

Utwórz(dane)

:Obiekt B

Utworzony


Diagram sekwencji dla „przypadku użycia Diagram sekwencji dla „przypadku użycia Sprzątnięcie Sprzątnięcie pokoju”pokoju” –– wersja szczegółowawersja szczegółowa

:Recepcjonista:Pokój

:Pokojowa

Zwolnij

Utwórz(pokój, kto):Sprzątanie

Sprzątnij(pokój)

SprzątniętyCzysty


Notacja jNotacja jęęzyka UML na potrzeby tworzenia diagramzyka UML na potrzeby tworzenia diagramóów wspw wspóółłpracypracy

: klasa

nazwa obiektu : klasa

1. komunikat 1

nazwa obiektu2. komunikat 2

nazwa obiektu : Klasa A

3. komunikat asynchroniczny

Diagram współpracy odpowiadający diagramowi Diagram współpracy odpowiadający diagramowi sekwencji sekwencji Sprzątnięcie pokojuSprzątnięcie pokoju

:Pokojowa:Recepcjonista

1 : zwolnij 5 : czysty

2 : utwórz(pokój, kto) 3 : sprzątnij(pokój)

4 : sprzątnięty

:Sprzątanie

:Pokój


Modele implementacyjne Modele implementacyjne –– projektowanie klasprojektowanie klas

integracja modelu statycznego z modelem dynamicznymmodularyzacja klassystematyzacja dziedziczeniadefiniowanie atrybutów wyliczanychdefiniowanie związków wyliczanychprojektowanie związkówosadzanie obiektów


Modele implementacyjne Modele implementacyjne –– projektowanie systemuprojektowanie systemu

podzielenie dużego systemu na podsystemyopracowanie architektury fizycznej systemu, z przydzieleniem podsystemów do poszczególnych węzłów tej architekturywybranie sposobu zarządzania danymi, stosownie do wymagań dotyczących pojemności, efektywności, bezpieczeństwa itd.wybranie środowiska implementacyjnego, w tym systemu operacyjnego i środowiska programistycznegorozważenie sposobu implementacji współbieżności tkwiącej w systemiezaprojektowanie obsługi sytuacji przejściowych (jak start i zamknięcie systemu) i sytuacji awaryjnych


Diagramy fizyczneDiagramy fizyczne(zwane implementacyjnymi)(zwane implementacyjnymi)

diagramy komponentów (Component Diagrams)diagramy wdrożeniowe – inna nazwa: diagramy rozprzestrzeniania (Deployment Diagrams)

Diagram komponentów (Diagram komponentów (component component diagramdiagram))

pokazuje strukturę komponentów oprogramowania, ich związki i przepływ komunikatów oraz interfejsy ze światem zewnętrznym

jest to graf, w którym węzłami są komponenty; strzałki prowadzą od klienta pewnej informacji do jej dostawcy

rodzaj zależności jest związany z typem języka programowania

diagram może także pokazywać interfejsy poszczególnych komponentów

Przykładowy diagram komponentów w UMLPrzykładowy diagram komponentów w UML

Program do harmonogramów

Program planujący

Interfejs graficzny

rezerwacje

aktualizacje

Diagram wdrożeniowy (Diagram wdrożeniowy (deploymentdeployment diagramdiagram), synonimy: diagram wdrożenia, ), synonimy: diagram wdrożenia, diagram rozprzestrzenianiadiagram rozprzestrzeniania

pokazuje konfigurację elementów czasu wykonania: komponentów sprzętowych, komponentów oprogramowania, procesów oraz związanych z nimi obiektów

komponenty, które nie istnieją w trakcie czasu wykonania, nie pojawiają się na tych diagramach

jest to graf, gdzie węzłami są elementy czasu wykonania połączone przez linie odwzorowujące ich połączenia komunikacyjne

komponenty są połączone strzałkami wskazującymi komponent wykorzystywany przez dany komponent

Przykładowy diagram rozprzestrzeniania w UMLPrzykładowy diagram rozprzestrzeniania w UML

Program do harmonogramów Program planujący

<<baza danych>>spotkaniaBD

AdminServer:KomputerHost

KomputerJacka:PC

Przykład pakietu zawierającego klasy ściśle ze sobą powiązanePrzykład pakietu zawierającego klasy ściśle ze sobą powiązane

OKNO

OKNO ZWYKŁE OKNO MENU

PASEK MENU POZYCJA MENU

*

ZawieraMENU

KOMPONENT MENU

INTERFEJS


Zależności pomiędzy pakietamiZależności pomiędzy pakietami

A B

C D


Generyczny diagram rozmieszczaniaGeneryczny diagram rozmieszczania

NetDrv

KlientAplik

Windows

KlientAdmin

Połączona z

Tworzy_kopie_na

1..* 1..

2 Serwer

Stacja kopii

Stacja kliencka

Administracyjna stacja kliencka


Diagram ilustrujący architekturę fizyczną systemuDiagram ilustrujący architekturę fizyczną systemu

Stacja1: Stacjakliencka

Stacja2: Stacjakliencka

Stacja3: Administracyjna stacja kliencka

Serwer A: Serwer

Serwer B: Serwer

Stacja4: Stacja kopii

TCP/IP

TCP/IP

TCP/IP

TCP/IP

DecNet


Zalety podejścia obiektowegoZalety podejścia obiektowegopodejście obiektowe odzwierciedla naturalne procesy poznawcze człowiekapozwala zachować jednolitość koncepcyjną i notacyjną poprzez wszystkie fazy wytwarzania oprogramowaniadzięki zastosowaniu koncepcji obiektów, reprezentujących elementy rzeczywistości nie pozwala utracić z pola widzenia dziedziny problemowej we wszystkich fazach tworzenia oprogramowaniaułatwia komunikowanie się osób uczestniczących w projekciedaje komponenty, które mogą być wielokrotnie wykorzystywane, np. w innych projektachułatwia zarządzanie projektami, m.in. dzięki jednolitym standardom projektowym i łatwości podziału prac między różne zespoły


Metodyki społeczneMetodyki społeczne

ETHICS (Effective Technical and Human Implementation of Computer-Based Systems),autor: E. Mumford

metodykę ETHICS wyróżniają aspekty:psychologicznysocjologicznyznaczenia zmiany

SSM (Soft Systems Methodology),autor: P. Checkland

metodyka SSM jest reprezentatywną metodyką społecznej szkoły tworzenia systemów informatycznych


Metodyka SSMMetodyka SSM

Podstawowe założenia metodyki SSMmetodyka społeczna rozumiana jako proces zarządzaniaróżnorodność ocen sytuacji problemowej użyteczność pojęć systemowychkoncepcja systemu działań ludzkichmetodyka jako systemu zapytań


Koncepcja zarządzania w ujęciu SSMKoncepcja zarządzania w ujęciu SSM

Ciągłe zmiany wzajemnie oddziałujących zdarzeń i pomysłów

Postrzeganie i ocena (części)

ciągłych zmian

Postrzeganie i Postrzeganie i ocena (części) ocena (części)

ciągłych zmianciągłych zmian

Decyzjeo

działaniu

DecyzjeDecyzjeoo

działaniudziałaniu

postrzeganiepostrzeganie

pomysłypomysły

czas

działaniedziałanie

prowadzi do


Cykl uczenia się w metodyce SSMCykl uczenia się w metodyce SSM

Sytuacja problemowa

w świecierzeczywistym

Sytuacja Sytuacja problemowa problemowa

w świeciew świecierzeczywistymrzeczywistym

Modele celowej

działalności

Porównanie modeli z postrzeganą

rzeczywistością

Działania dla poprawy sytuacji

problemowej

Uporządkowana dyskusja o zmianach i środkach dla umożliwienia przeprowadzenia tych zmian


Proces stosowania metodyki SSMProces stosowania metodyki SSM11

Wprowadzenie do Wprowadzenie do sytuacji problemowejsytuacji problemowej

77

Podejmowanie działań Podejmowanie działań dla udoskonalenia dla udoskonalenia

sytuacji problemowejsytuacji problemowej

55

Porównanie modeli z Porównanie modeli z działaniami w świecie działaniami w świecie

rzeczywistymrzeczywistym

22

Rozpoznanie Rozpoznanie sytuacji problemowejsytuacji problemowej

33

Sformułowanie Sformułowanie podstawowych definicji podstawowych definicji

dla odpowiednich dla odpowiednich systemów celowej systemów celowej

działalnościdziałalności

44

Opracowanie modeli Opracowanie modeli konceptualnych systemów konceptualnych systemów opisanych przez definicje opisanych przez definicje

podstawowepodstawowe

66

Określenie Określenie pożądanych i pożądanych i

wykonalnych zmianwykonalnych zmian

Świat rzeczywisty

Myślenie systemowe o świecie rzeczywistym


Wzbogacony wizerunek gospodarki towarowej Wzbogacony wizerunek gospodarki towarowej supermarketusupermarketu

Dział informatyki przesyła nieaktualne

informacje

ocena niezawodności

dostawców

stan bieżący zapasów

towary

oferty

Supermarket

Dział informatyki

Dział zamówień

Dyrekcja

obsługa informatyczna

Bank

ocena zdolności finansowej

ocena jakości i ceny towarów

Klienci

popyt

decyzje

straty z tytułu nieracjonalnej

gospodarki towarowej

Dział Finansowy

propozycje kredytowe

Zbyt długie kolejki do kas w

supermarkecie

Definicje podstawowe Definicje podstawowe -- CATWOECATWOECC – customers

AA – actors

T T – transormation

WW – Weltanschauung

O O – owner

EE – environmentalŹródło: S. Wrycza, Analiza i projektowanie systemów informatycznych zarządzania. Metodyki, techniki, narzędzia, PWN,Warszawa 1999.

klienci tracący lub zyskujący w wyniku celowej działalności

wykonawcy celowej działalności

przedstawienie celowej działalności jako procesu: wejście – transformacja – wyjście

punkt widzenia, który nadaje sens definicji podstawowej w danym kontekście

osoby mogące wstrzymywać proces transformacji (właściciel)

założenia i ograniczenia otoczenia przyjmowane przez system jako dane (ograniczenia środowiska)

Przykład: definicja podstawowa CATWOEPrzykład: definicja podstawowa CATWOEDefinicja podstawowa:

Użytkowany przez supermarket system sterowania zapasami towarowymi, zapewniający aktualną informację, pozwalający podejmować racjonalne decyzje dla zadowalającego zaspokojenia popytu konsumentów, przez sprawną organizację dostaw towarowych i minimalizację strat z tytułu braków towarowych czy zapasów nadmiernych

CC klienci, dostawcy

AA Dział zamówień, Dział informatyki

TT Niesprawna obsługa Racjonalne sterowaniegospodarki towarami gospodarką towarami

WW Sterowanie zapasami towarowymi przy wykorzystaniu metod informatycznych prognostycznych i badań operacyjnych może być źródłem znacznej poprawy zaspokajania popytu klientów i podniesienia zysku supermarketu

OO Dyrekcja supermarketu

EE Dostawy towarów i technologii informatycznej, reklama, nowe produkty, popyt na rynku, koniunktura gospodarcza


Od projektu do programu Od projektu do programu -- modele zachowań programumodele zachowań programu

Model przepływu sterowania

Model przepływu danych

Model tranzycji stanu

Model składniowy

Model decyzyjny


Dialog pytanie Dialog pytanie –– odpowiedź odpowiedź Wprowadź dane o kliencieWybierz jedną z poniższych opcji:

1. Wprowadź nazwisko2. Wprowadź imię3. Wprowadź numer telefonu

Wprowadź numer opcjiZarejestruj dane

Wprowadź dane o kliencieWybierz jedną z poniższych opcji:

1. Wprowadź nazwisko2. Wprowadź imię3. Wprowadź numer telefonu

Wprowadź numer opcjiZarejestruj dane

a) metoda wyboru opcji

Jakie jest nazwisko klienta?Jan KowalskiJaki jest adres Jana Kowalskiego?Warszawa, ul. Chmielna 120Jaki jest numer telefonu Jana Kowalskiego?

Jakie jest nazwisko klienta?Jan KowalskiJaki jest adres Jana Kowalskiego?Warszawa, ul. Chmielna 120Jaki jest numer telefonu Jana Kowalskiego?

Wprowadź dane o kliencieNazwisko:Adres:Nr telefonu:Czy wprowadzone dane są poprawne (T/N)?

Wprowadź dane o kliencieNazwisko:Adres:

b) metoda zapytań

c) metoda formatekNr telefonu:Czy wprowadzone dane są poprawne (T/N)?


Architektura systemu bazy danychArchitektura systemu bazy danych

SCHEMATZEWNĘTRZNY

1

SCHEMATZEWNĘTRZNY

1

SCHEMATZEWNĘTRZNY

N

POZIOM KONCEPTUALNY

SCHEMAT WEWNĘTRZNY

SCHEMATZEWNĘTRZNY

N

BAZA DANYCHŹródło: S. Wrycza, Analiza i projektowanie systemów informatycznych zarządzania. Metodyki, techniki, narzędzia, PWN,Warszawa 1999.

Definiowanie klasDefiniowanie klasW języku C++ deklaracja klasy może wyglądać

następująco:

class Point{

public:Point( int anX, int anY ) ;~Point( ) ;void move( int dx, int dy ) ;

private:int x;int y;

} ;


Widoczność składników klasy w języku C++Widoczność składników klasy w języku C++

Widoczność składników klasy zapewniamy przez zadeklarowanie ich jako prywatnych (private), publicznych (public) lub chronionych (protected). Wykorzystanie atrybutów widoczności związane jest z projektowaniem dostępności interfejsu i odpowiednio zawęża możliwości jego użycia:prywatny – składowa może być użyta przez inne składowe lub przez funkcje zaprzyjaźnione (ang. friend) klasy, w której dana składowa została zadeklarowana;publiczny – składowa może być używana przez wszystkich;chroniony – składowa może być użyta przez inne składowe lub przez funkcje zaprzyjaźnione klasy, w której dana składowa została zadeklarowana, uprawnienie do dostępu do składowej jest dziedziczone przez klasy potomne.


Definiowanie klasDefiniowanie klasTę samą klasę można przedstawić w języku Java:

public class Point{

public Point( int anX, int anY) { /* .. */ }public finalize( ) { /* .. */ }public void move( int dx, int dy) {

/* .. */ }protected int x;protected int y;

} ;


Definiowanie dostępu do klasy w języku Definiowanie dostępu do klasy w języku JavaJava

W języku Java pojawiła się możliwość definiowania dostępu do samej klasy na poziomie pakietów. Wprowadzono dodatkowe poziomy dostępu składowych w ramach klasy:prywatny – składowa może być użyta przez inne składowe tej klasy;chroniony – składowa może być użyta przez inne składowe tej klasy lub innych klas wchodzących w skład pakietu, uprawnienie dostępu do składowej jest dziedziczone również przez klasę potomną klasy, w której zdefiniowano chronioną składową;publiczny – składowa może być używana przez wszystkich;pakiet – składowa może być użyta przez inne składowe tej klasy lub innych klas wchodzących w skład pakietu.


Przykład wykorzystania polimorfizmuPrzykład wykorzystania polimorfizmu

// f jest typu Figura// powołanie do życia obiektu typu Koło// wywołanie metody pole(), przez późne// wiązanie zostanie wywołana operacja// definiowana przez metodę w klasie Koło// powołanie do życia obiektu typu Kwadrat// wywołanie metody pole(), przez późne// wiązanie zostanie wywołana operacja// definiowana przez metodę w klasie Kwadrat

Pole()

Figura

Pole()

Koło

Pole()

Kwadrat

Figura *f;F = new Koło;f->pole ( );

F = new Kwadrat;f->pole ( );


Metodologia projektowania programów równoległych (1)Metodologia projektowania programów równoległych (1)

Ian Foster zaproponował metodologię dzielącą proces projektowania na cztery etapy wykonywane iteracyjnie:Dekompozycja – zadanie jest dzielone na mniejsze zadania, które mogą być następnie realizowane niezależnie na różnych komputerach, podziału dokonuje się poprzez podział danych lub obliczeń.Komunikacja – pracujące na różnych komputerach współpracujące części zadania wymagają odpowiedniej struktury komunikacyjnej dla przesyłania wyników częściowych. Niewłaściwa struktura komunikacyjna może znacznie zmniejszyć możliwe do osiągnięcia przyspieszenie, możliwy jest również brak przyspieszenia. Na tym etapie ocenia się koszt komunikacji.


Metodologia projektowania programów równoległych (2)Metodologia projektowania programów równoległych (2)

Aglomeracja – w zależności od liczby dostępnych procesorów oraz otrzymanej struktury komunikacyjnej, wymagane jest ograniczenie narzutu komunikacyjnego oraz dostosowanie się do specyficznej architektury komputera poprzez połączenie zadań wydzielonych w pierwszym etapie, może to wymagać replikacji danych i obliczeń.Przydział zadań do procesorów – sposób rozproszenia otrzymanych w poprzednich krokach podzadań pomiędzy dostępne procesory ma duży wpływ na końcowy rezultat, celem etapu jest maksymalizacja wykorzystania procesorów, minimalizacja kosztu komunikacji i czasu bezczynności procesorów.


Generatory zastosowańGeneratory zastosowań

Generatory zestawieńwspomagają wyszukiwanie danych i edycję raportów

Języki zapytańumożliwiają wyszukiwanie danych z baz danych

Właściwe generatory zastosowań służą do: definiowania transakcji wejściowychprowadzenia dialogutworzenia bazy danychaktualizacji plikówgenerowania zestawieńprzetwarzania zapytań


Pakiety zastosowań Pakiety zastosowań Potrzeby informatyczne a cechy pakietu zastosowań

OtoczenieorganizacjiOtoczenieorganizacji

Potrzeby, problemyi oczekiwania użytkownika

Potrzeby, problemyi oczekiwania użytkownika

Potrzeby informatyczne(infoplan)

Potrzeby informatyczne(infoplan)

SprzecznościSprzeczności

Zmianyw organizacji

Zmianyw organizacji

Zmiany w procesiewdrażania pakietu

Zmiany w procesiewdrażania pakietu

Plan wdrażaniaPlan wdrażania

Pakietzastosowań

Pakietzastosowań


Zasady budowania złożonego systemu oprogramowaniaZasady budowania złożonego systemu oprogramowaniaw zespołach projektowychw zespołach projektowychNależy przestrzegać następujących zasad:

powstrzymywać się przed przedwczesnym programowaniem, zanim nie zostanie przeprowadzony pełny wstępny cykl wytwórczy pozwalającyuchwycić skalę i kluczowe wymagania systemu,metody i ich realizacja muszą być czytelne i zrozumiałe dla innych członków zespołu,stosowane nazwy powinny być identyczne jak w modelu systemu lub powinny być stosowane jednolite reguły ich tworzenia,wszystkie nazwy powinny być starannie dobierane pod kątem właściwego znaczenia w użytym kontekście, można stosować skróty,ale według reguł (np. wykorzystania słownika skrótów),wykorzystanie uzgodnionych i wspólnych reguł kodowania,rozmieszczanie klas w pakietach (łączenie kodu w moduły),systematyczne dokumentowanie klas i metod,publikowanie specyfikacji i utrzymywanie wspólnych, zarządzanychbaz danych projektów.


Środowiska wspierająceŚrodowiska wspierające(narzędzia CASE)(narzędzia CASE)

Oczekiwania wobec narzędzi CASEOczekiwania wobec narzędzi CASE

pokrycie cyklu życia systemustosowane metodologiewspieranie nowoczesnych cykli i metodologiizapewnianie wysokiej jakościintegracja ze środowiskiem wytwarzaniałatwa asymilacja w przedsiębiorstwiebezawaryjna praca


Ogólna architektura narzędzi CASEOgólna architektura narzędzi CASE

Poprawność modeliReguły sprawdzające

poprawność syntaktyczną

Analiza modeluSprawdzanie poprawności

semantycznej

Generator raportów

i dokumentacji

Kontrola dostępu

Zarządzanie wersjami

Zarządzanie konfiguracją

REPOZYTORIUM

META-MODELGeneratory kodu źródłowego

Generatory modeliz kodu źródłowego Współdziałanie

z innymi narzędziami

ImportEksport

Interfejs użytkownika


Kategorie narzędzi CASE (1)Kategorie narzędzi CASE (1)zintegrowane środowiska projektowe (ang. Integrated Project Support Environments – IPSE)zintegrowane środowiska wytwórcze/programistyczne (ang. Integrated Development Environments – IDE)środowiska wspomagające generowanie aplikacjinarzędzia wspomagające weryfikację, walidację i testowanie (VVT, CAST)narzędzia wspomagające ulepszanie już istniejących aplikacji w procesie inżynierii ponownej, mającej na celu restrukturyzację oprogramowania, odtworzenie lub dostosowanie do nowych wymagańnarzędzia wspomagające zarządzanie projektemnarzędzia wspomagające zarządzanie konfiguracją oprogramowania


Kategorie narzędzi CASE (2)Kategorie narzędzi CASE (2)

narzędzia wspomagające zarządzanie procesem wytwarzania oprogramowanianarzędzia meta-CASEnarzędzia specyficzne dla danej dziedziny zastosowańnarzędzia wspomagające użycie metod formalnychnarzędzia wspomagające wytwarzanie oprogramowania równoległegonarzędzia wspomagające projektowanie i prototypowanie dialogu człowieka z komputerem


Rozwój narzędzi wspomagającychRozwój narzędzi wspomagających

powiązanie metod obiektowych i specyfikacji formalnychprototypowanie wytwórczemetody ponownej inżynieriiwielokrotne wykorzystanie komponentów i wzorców oprogramowania


Narzędzia CASE w cyklu życia oprogramowania (1)Narzędzia CASE w cyklu życia oprogramowania (1)specyfikacja wymagań, najczęściej za pomocą notacji graficznychwalidacja dokonanej specyfikacji (modelu logicznego), ocena jej spójności i kompletnościprojektowanie i realizacja testówprzekształcenie utworzonego modelu w projektweryfikacja zgodności projektu z wymaganiami i jego logiczna walidacja, często poprzez prototypowanie lub symulację działania przyjętej konstrukcjiszkieletowa lub pełniejsza generacja kodutestowanie, animacja i pomiary utworzonej aplikacjimonitorowanie i ocena wydajności tworzonego oprogramowania, w szczególności dotyczy to aplikacji rozproszonych i równoległych


Narzędzia CASE w cyklu życia oprogramowania (2)Narzędzia CASE w cyklu życia oprogramowania (2)tworzenie dokumentacji, na różnych poziomach i w różnych przekrojachzarządzanie projektem, od planowania i harmonogramowania po kontrolę jego realizacjianaliza zamierzonych zmian i wspomaganie ich dokonaniawspomaganie ponownej inżynierii systemów, przeniesienie aplikacji do nowego środowiska lub zarządzanie konfiguracjąwspomaganie inżynierii odwrotnej, czyli pozyskiwanie specyfikacji projektowej oraz analitycznej na podstawie istniejącego kodu i wiedzy konstruktora, synchronizacja kodu i projektu (ang. round-trip engineering)ponowne wykorzystanie wcześniejszych rozwiązań w konstrukcji nowych projektówsynteza układów cyfrowych przez wyspecjalizowane środowiska narzędziowe


Kryteria doboru narzędzi CASEKryteria doboru narzędzi CASEogólne kryteria oceny oprogramowaniawsparcie dostarczane przez producentazakres podtrzymania procesu wytwarzaniaorientacja narzędziawsparcie elementów cyklu wytwarzaniapielęgnacja, adaptacjeużytkowośćgenerowanie koducechy związane z zarządzaniem projektem i nadzorem jakościopinia użytkowników


Wzbogacony wizerunekWzbogacony wizerunekWytwarzania oprogramowaniaWytwarzania oprogramowania

WYTWÓRCY

DOSTAWCY

KIEROWNICTWO

Pomocy!Pomocy!

Czy to dobre dla firmy?

Czy to dobre dla firmy?

Któremu projektowi przydzielić zasoby?

Któremu projektowi przydzielić zasoby?

Nic nie rozumiem

Nic nie rozumiem

Narzędzia wykorzystywaneprzez użytkowników końcowych

Żądane pieniądze

Dostarczony system

Punkt widzenia użytkownika

vs. punkt widzenia wytwórcy

Narzędzia

Prawa własności

Plany

Raporty

Dialog

Polityka

Polityka

Sytuacje wyjątkowe

Aspekty techniczne

vs. biznesowe

Priorytetem jest sprzedaż

Priorytetem jest sprzedaż

UŻYTKOWNICY

Potrzebuję więcej ludzi

Potrzebuję więcej ludzi

ZESPÓŁ


Agile ModelingAgile Modeling

Agile ModelingAgile Modeling -- metoda modelowania systemów informatycznychmetoda modelowania systemów informatycznych

Ludzie i interakcje są ważniejsze niż procesy i narzędziaDziałające oprogramowanie jest ważniejsze od kompletnej dokumentacjiWspółpraca z klientem jest ważniejsza od negocjacji kontraktówPodążanie za zmianą jest ważniejsze od trzymania się planów

Agile Modeling Agile Modeling (AM)(AM)

Aby dobrze stosować AM, potrzeba wiele doświadczenia nabytego w ... tradycyjnym modelowaniu:

„Tak jak pianista, który musi perfekcyjnie opanować gamy i etiudy, zanim zacznie nowatorskie interpretacje klasyków, tak i informatyk powinien najpierw solidnie poznać formalne metody inżynierii oprogramowania i zdobyć doświadczenie, a dopiero potem iść na skróty”

Agile ModelingAgile Modeling (AM)(AM)

Elementy AM:wartości, zasady i praktyki, dotyczące:

inżynierii wymagań, analizy, architektury i projektu

AM AM -- wartościwartości

komunikacjaprostotainformacja zwrotna odwaga (zmian dokonywać ze śmiałością)pokora (każdy informatyk powinien z

pokorą zakładać, że jest omylny, jego wiedza jest niekompletna i popełnia błędy)

AM AM -- zasady (zasady (principlesprinciples))

zakłada tworzenie wielu rozwiązań dla jednego problemu

gotowość do zmiancelem modelowania jest działające

oprogramowanie (nie modelować tak, że język oprogramowania nie daje wsparcia)

AM AM -- praktykipraktyki

rysuj proste modeleużywaj kartek i tablicy przed narzędziami

CASEbuduj model przyrostowosprawdź, czy model da się przedstawić za

pomocą kodu w wybranym języku programowania

AMAM

nie proponuje własnej notacji (dużo uwagi poświęca Unified Modeling Language (UML) - za wadę uznaje się oderwanie UML od języka programowania)nie zawiera wskazań dotyczących zarządzania

projektem, wdrażaniapodczas programowania używać Extreme

Programming (wartości EP: prostota, komunikacja, testowania, śmiałość; praca zespołowa; współpraca z użytkownikami; zmiany)

AM AM -- wątpliwościwątpliwości

„luźne” podejście do formalizmów (jak połączyć z uznaniem ważności komunikacji; formalizmy są podstawą każdej dziedziny inżynierii)

ExtremeExtremePROGRAMMINGPROGRAMMING

Powstanie Powstanie Extreme ProgrammingExtreme Programming

idea narodziła się na początku lat 90-tych; pierwsza realizacja 1996 r.

twórcy: Kent Beck i Ward Cunningham

Literatura: Kent Beck, Wydajne programowanie.Extreme Programming, Wydawnictwo Mikom 2001.

Zasady Zasady Extreme ProgrammingExtreme Programming

maksymalne uproszczenie projektu i „gra w planowanie”ścisły kontakt z odbiorcą oprogramowaniaprogramowanie paramiciągłe testowanie i integracja aplikacjiściśle określone standardy pracy


Zalety Zalety Extreme ProgrammingExtreme Programming

doskonała do stosowania w niewielkich grupach programistówprojekty prowadzone zgodnie z regułami Extreme Programmming dobrze sprawdzają się w przypadku napiętych terminów zleceńdobry kontakt między programistami, którzy mogą zastępować się lub wymieniać pracązmniejszenie ilości generowanej dokumentacji

Wady Wady Extreme ProgrammingExtreme Programming

trudno stosować w dużych zespołachtrudno stosować, gdy projekty są prowadzone w sposób rozproszonybariery psychologiczne (np. praca w parach)

Zarządzanie projektami informatycznymi

ProjektProjekt

Nierutynowy procesrealizacji określonych celóww określonym czasieza pomocą określonych środków

Na podstawie:mat. Z. Szyjewski, M. Miłosz, ...Z. Szyjewski, Zarządzanie projektami informatycznymi, Wyd. Placet, 2000.Z. Szyjewski, Metodyki zarządzania projektami informatycznymi, Wydawnictwo PLACET, Warszawa 2004.mat. W. Kosieradzki, Centrum Rozwiązań Menedżerskich S.A., XIV Górska Szkoła PTI

Szczyrk, 24-28 czerwca 2002.mat ICL

Z projektami informatycznymi związane jest duże ryzyko i problem pojawiających się zmian (potrzeba zarządzania ryzykiem i zmianami)

Kluczowe parametry projektu

zakres projektukoszt użytych zasobówczas realizacji projektu Zakres

PROJEKT

Koszt Czas

Parametry nie są niezależne Parametry nie są niezależne --dowolne dwa określają trzecidowolne dwa określają trzeci

Błędy inicjacji projektu

zakres

koszt czas?zbyt szeroki zakresniekompletny zakres pracoptymizm szacunkówzapominanie o problemach eksploatacjibrak dbałości o utrzymanie długotrwałego zadowolenia klientawybór kierownika projektu

Schemat organizacyjny projektu

Zespół zapewniania jakości

Zespół 1

Kierownikpodprojektu 1

SPONSOR

Zespół 2

Kierownikpodprojektu 2

Reprezentantklienta

..........

.........

Doradca techniczny

Zespół n

Kierownikpodprojektu n

Komitet sterujący

...

KIEROWNIK -LIDER PROJEKTU

Związki zewnętrzne

Biuro projektu

Składniki zarządzania projektem wg Komitetu Składniki zarządzania projektem wg Komitetu Standaryzacyjnego PMI (Standaryzacyjnego PMI (Project Management InstituteProject Management Institute))

Obok koordynowania prac projektu i zarządzania czasem jako składniki zarządzania projektem wymienia się:zarządzanie zakresem projektuzarządzanie kosztamizarządzanie jakościązarządzanie zasobami ludzkimi zarządzanie komunikacją między ludźmizarządzanie ryzykiemzarządzanie pozyskiwaniem (rzeczy i usług spoza organizacji)


Proces wytwórczy z operacyjnego punktu widzenia Proces wytwórczy z operacyjnego punktu widzenia ––zarządzanie złożonościązarządzanie złożonością

metody związane z decyzjami i procesami wysokiego poziomu, jak model CMM dojrzałości procesów stosowanych w organizacji czy seria standardów ISO 9000

metody, które wspomagają kierowników projektów i członków zespołów projektowych w ich codziennej pracy, jak na przykład metoda PRINCE (akronim anglojęzycznej nazwy PRoject control IN Computer Environments) zarządzania projektami czy metody parametryczne szacowania projektów COCOMO (COnstructive COstMOdel) i FPA (Function Point Analysis)


Standardy procesu wytwarzania oprogramowania Standardy procesu wytwarzania oprogramowania ––twórcy standardówtwórcy standardów

organizacje standaryzacyjne, takie jak International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), International Telecommunication Union (ITU), na przykład Standard 12207 Software Life Cycle Processes, PN-ISO 9000-3 Normy dotyczące zarządzania jakością i zapewnienia jakościstowarzyszenia inżynierskie, jak The Software Engineering Standard Committee of the IEEE Computer Society (SECS)instytuty, jak Software Engineering Institute (modele CMM-SEI), agencje związane z daną dziedziną przemysłową (European Space Agency – ESA Software Engineering Standards), wojsko (MIL DOD-STD-2167A-inżynieria oprogramowania, DOD-STD-2168-standardy oceny)konsorcja przemysłowe firm, jak Object Management Group (OMG – np. UML), Electronic Industries Alliance (EIA) firmy, jak Rational (Rational Unified Process – RUP), Microsoft (Microsoft Solution Framework – MSF), definiujące własny standard procesu programowego itd.grupy projektantów i programistów (open source, „szkoły”, zrzeszenia), na przykład określające zasady programowania ekstremalnego (ang. extreme programming, XP)


Iteracyjny i przyrostowy proces wytwarzania Iteracyjny i przyrostowy proces wytwarzania Rational Unified ProcessRational Unified Process (RUP)(RUP)

Rozpatrywane są:etapy - okresy między kolejnymi punktami milowymi procesu, w których zostały osiągnięte pewne ściśle ustalone cele, przedstawiono ukończone produkty pracy i podjęto decyzje o przejściu do następnego etapu.Wyróżnia się cztery etapy: rozpoczęcia (ang. inception), opracowania (ang. elaboration), konstrukcji (ang. construction) i przekazania (ang. transition);procesy (przepływy czynności – ang. workflows), obejmujące zbiór czynności i produktów (artefaktów).Wyróżnia się dziewięć procesów: modelowanie przedsiębiorstwa (ang. business modelling), rozpoznanie wymagań (ang. requirements), analiza i projektowanie (ang. analysis and design), implementacja (ang. implementation), testowanie (ang. test), wdrożenie (ang. deployment), zarządzanie konfiguracją (ang. configuration management), zarządzanie przedsięwzięciem (ang. project management) oraz zarządzanie środowiskiem (ang. environment).


Iteracyjny i przyrostowy proces wytwarzania RUPIteracyjny i przyrostowy proces wytwarzania RUP

Organizacja w czasieO

rgan

izac

ja w

edłu

g za

war

tośc

i

Etap inżynierski Etap produkcji

Zadania procesowe

Zadania wspomagające

Modelowanie przedsiębiorstwaWymagania

Analiza i projektowanieImplementacja

TestowanieWdrożenie

Zarządzanie konfiguracją i zmianamiZarządzanie przedsięwzięciem

Środowisko

FazyRozpoczęcie Opracowanie Konstruowanie Przekazanie

Iteracja wstępna

Iteracja #1

Iteracja #2

Iteracja #k

Iteracja #k+2

Iteracja #m

Iteracja #m+1

Iteracje

Iteracja #k+1

Wizja Architektura Beta Produkt

Jedna iteracja


Oracle Custom Development Method Oracle Custom Development Method (CDM) (CDM) -- metodologia prowadzenia metodologia prowadzenia projektów informatycznychprojektów informatycznych

Etapy prowadzenia projektu

definiowanie potrzeb biznesowych (określenie zakresu projektu)analiza (formułowanie szczegółowych wymagań)projektowanie (szczegółowy projekt techniczny systemu)tworzenie oprogramowania (np. rozwój przyrostowy - w kolejnych iteracjach aplikacja otrzymuje dodatkową funkcjonalność lub tradycyjne „kodowanie”; tworzenie dokumentacji)wdrażanie (prezentacja użytkownikom i szkolenia)produkcja (wsparcie techniczne i dyskusje nad rozszerzeniami funkcjonalnymi)

CDM Fast CDM Fast TrackTrack -- modyfikacja CDMmodyfikacja CDM

cel: maksymalne przyspieszenie procesu wdrażania aplikacji, tak by użytkownik jak najszybciej mógł dostrzec efektyproces produkcji obejmuje projektowanie i wytwarzanie aplikacji - „prototypowanie z dokładnym określeniem czasu”zakłada się ścisłą współpracę z użytkownikiem (zamiast „dla użytkownika” praca „z użytkownikiem”, który jest członkiem zespołu)

CDM Fast CDM Fast Track Track -- technika ustanawiania technika ustanawiania priorytetówpriorytetów

Lista: Lista: Must haveMust have, , Should haveShould have, , Could Could havehave, , Won’t haveWon’t haveKażdemu elementowi systemu jest przypisywany -w porozumieniu z użytkownikiem - odpowiedni priorytet:1) czy musi on być zrealizowany,2) czy być może powinien być wykonany,3) czy mógłby być zrobiony, ale wówczas gdy wystarczy czasu,4) czy może warto zrezygnować z danego elementu i przejść od razu do kolejnego zadania.

CDM Fast CDM Fast Track Track -- prototypowanieprototypowanie

proces iteracyjny: kolejno są przedstawiane coraz nowsze wersje aplikacji, realizujące kolejne funkcjenie ma formalnego, wyodrębnionego etapu instalacji - użytkownicy na bieżąco otrzymują nowe wersje i w momencie, gdy żądana funkcjonalność jest zrealizowana, przystępują do korzystania z systemu

CDM CDM RuleFrame RuleFrame -- reguły biznesowereguły biznesowe

mechanizm elastycznego definiowania reguł biznesowychreguły biznesowe określają sposób działania aplikacji - co oznacza „poprawna” transakcja, jakie warunki muszą być spełnione, by operację można było wykonać itd.transakcja biznesowa jest obiektem na wyższym poziomie abstrakcji niż atomowa (pojedyncza) transakcja w bazie danych

CDM CDM -- oprogramowanieoprogramowanie

Oracle Designer: automatycznie generuje tzw. standardowe reguły zawarte np. w projekcie UML lub tzw. dobrych praktykach sformułowanych w dokumentach CDM lub Fast Track - powstaje gotowa warstwa logiki biznesowej, która może być od razu uruchomionareguły biznesowe mogą tworzyć kod w różnych postaciach, np. triggerów bazodanowych

CDM CDM -- przydatnośćprzydatnośćprzy opracowywaniu rozwiązań dostosowanych do potrzeb konkretnego przedsiębiorstwapowstała wersja CDM przeznaczona dla małych projektów, których celem jest np. opracowanie zaawansowanego prototypu aplikacji

CDM CDM -- przykład zastosowaniaprzykład zastosowania

Krajowy System Informacyjny PolicjiiCDM - Oracle CDM for Internetzarządzanie ryzykiem: rozwiązywanie problemów pojawiających się w trakcie przedsięwzięcia, o charakterze technicznym, jak i interpersonalnympunkt odniesienia i źródło wiedzy o zadaniach niezbędnych do wykonania (efekt - zmniejszenie pracochłonności i obniżenie kosztów)

Rozwój oprogramowania Rozwój oprogramowania open sourceopen source

nie opracowuje się formalnych projektównie przeprowadza wyrafinowanych analizaplikacja jest wykorzystywana w fazie alpha lub beta - są zgłaszane usterki i sugestie poprawekróżnica modelu open source w porównaniu do CDM Fast Track: w modelu open sourcenie ma narzuconych ram czasowych

Siedem grzechów głównych popełnianych podczas realizacji projektów informatycznych

1. Nie wiadomo kto rządzi 2. Bez celu nie ma projektu3. Projekt bez organizacji4. Plan = lista marzeń5. Myślenie że „koszt α k.czas” (+ erozja marży)6. Zlekceważenie prac administracyjnych7. Problem punktualności

Źródło: mat. firmy ICL (konferencja PTI)

Metody oceny inwestycji w ITMetody oceny inwestycji w IT

Rachunek zdyskontowanych przepływów finansowychRachunek zdyskontowanych przepływów finansowych

wartość bieżąca netto, wewnętrzna stopa zwrotu, okres zwrotu z inwestycji

kalkulacja finansowych strumieni przychodów i kosztów inwestycji w wartościach bieżących, której efektem jest planowany zysk (wykazanie straty) z inwestycji, wyrażany w jednostkach pieniężnych, odsetkach od zainwestowanego kapitału, okresie zwrotu zainwestowanego kapitału

Ekonomiczna wartość dodana (EVA Ekonomiczna wartość dodana (EVA -- Economic Value AddedEconomic Value Added ))

zysk operacyjny netto minus cena kapitału (np. oprocentowanie kredytu)

zysk operacyjny uwzględnia zarówno początkowe koszty inwestycji, jak i koszty szkoleń, utrzymania i rozwoju, przeciwstawione strumieniowi przychodów lub oszczędności. Cena kapitału uwzględnia porównanie opłacalności danej inwestycji z inwestycjami alternatywnymi, do których ten kapitał może zostać zaangażowany. Im bardziej opłacalne inwestycje alternatywne, tym wyższa cena kapitału przyjmowana w rachunku.

Całkowity koszt posiadania (TCO Całkowity koszt posiadania (TCO -- Total Cost of Total Cost of OwnershipOwnership ))

metoda analizy wyłącznie kosztowej strony rachunku inwestycyjnego

w rachunku uwzględniane są zarówno koszty jawne (np. koszt zakupu serwera), jak i koszty ukryte (np. koszt nieformalnej nauki czy samoobsługi użytkowników) lub też odłożone w czasie (np. koszty utrzymania, upgrade’u, rozwoju infrastuktury w dłuższym czasie)porównywanie ofert alternatywnych oraz porównanie kosztów ponoszonych przez organizację z przeciętnymi kosztami podobnych organizacji (benchmarking ) w celu optymalizacji kosztów

Zrównoważona Karta Wyników (Zrównoważona Karta Wyników (Balanced ScorecardBalanced Scorecard))

uwzględnia, obok tradycyjnej perspektywy finansowej wykorzystującej metody ilościowe, perspektywy: satysfakcji klientów, procesów wewnętrznych oraz wiedzy i rozwojucel: uzyskanie możliwie szerokiego spojrzenia na wszystkie aspekty inwestycji/działalności przedsiębiorstwabadane wskaźniki (np. czas realizacji zamówienia, roczny koszt utrzymania PC) zależą od decyzji przedsiębiorstwa

Wycena opcji realnych (ROV Wycena opcji realnych (ROV -- Real Options ValuationReal Options Valuation ))

uwzględnia nie tylko wartość inwestycji, wynikającą z rachunku kosztów i przychodów,ale również wartość wynikającą z możliwości późniejszej realizacji kolejnych inwestycji oraz wartość związaną z elastycznością, możliwością zmiany scenariusza rozwoju inwestycji w jej trakcie

„nie ma związku między poziomem „nie ma związku między poziomem wydatków na informatyzację a zyskami wydatków na informatyzację a zyskami

przedsiębiorstw”przedsiębiorstw”

Paul StrassmanPaul Strassman

Efekty inwestycji ITEfekty inwestycji IT

poprawa morale pracownikówbezpośredni dostęp do informacji i klientówzwiększenie lojalności i poprawa satysfakcji klientówzwiększenie świadomości markiprzyspieszenie czasu wejścia na rynek z nowymi produktami (time to market )utrzymanie przewagi konkurencyjnejpoprawa jakości serwisu

Metody oceny inwestycji w ITMetody oceny inwestycji w IT

Projekty informatyczne niosąProjekty informatyczne niosą

„wartość strategiczną”„wartość strategiczną”

i „wartość dodaną dla przedsiębiorstwa”i „wartość dodaną dla przedsiębiorstwa”

Inne wymieniane efekty ...Inne wymieniane efekty ...

ujednolicenie standardów zarządzaniawspieranie komunikacji w przedsiębiorstwiewspieranie procesu konsolidacji, redukcji poziomu błędów i odsetka powtórnie wprowadzanych informacji trafniejsze prognozowanie i przyspieszanie cyklu produkcyjnego

Inwestycje w IT Inwestycje w IT -- wątpliwości ...wątpliwości ...dyrektor finansowy lub szef działu IT po kilku latach „strategicznych projektów informatycznych” przyznaje: „przeinwestowaliśmy”czy integracja jest wartościowa sama w sobie ?czy naprawdę trzeba integrować wszystko ze wszystkim ?czy bardziej usatysfakcjonowani klienci wydają więcej pieniędzy ?

Źródło: dyskusje publikowane w prasie informatycznej

Ilościowe metody oceny inwestycji IT Ilościowe metody oceny inwestycji IT -- wątpliwości ...wątpliwości ...

nadają się do oceny całości działań podejmowanych przez dział IT w zestawieniu ze strategią przedsiębiorstwa, ale nie sprawdzają się jako narzędzia podejmowania jednostkowych decyzji np. o zakupie sprzętunie odpowiadają na pytanie, czy koszty w IT w ogóle powinny być ponoszonepowiązanie wydatków na IT z konkretnym strumieniem przychodów jest często niemożliwe

Metody oceny inwestycji w ITMetody oceny inwestycji w IT-- przyczyny trudności pomiaruprzyczyny trudności pomiaru

„informatyka wyszła poza dział IT” (np. część przychodów z kontraktów pozyskanych przez handlowca należałoby wpisać w przychody z IT, ale jaką część ?)trudno oddzielić sprzęt i oprogramowanie od kultury informatycznej i organizacyjnej firmy czy jakości procesu wprowadzania zmian przy okazji wdrażania systemu oprogramowania


problem przesunięcia w czasie i oddzielenia „strumienia przychodów” lub „redukcji kosztów” związanych z inwestowaniem w IT (od wpływu innych czynników na sytuację firmy)np. jeśli firma po wdrożeniu ERP odnotowała wzrost zysków, czy wynika to z nowej technologii, czy wycofania się z rynku jednego z ważnych konkurentów, wprowadzenia nowej linii produktów, wymianie zespołu handlowców, lepszej koniunkturze, osłabieniu złotówki ?


problem prawidłowego oszacowania kosztów: koszty często przekraczają planowane wdrożenie się wydłużanie są brane pod uwagę w odpowiednim stopniu koszty utrzymania i rozwoju systemu oraz koszty związane z jego uruchomieniem np. okres obniżonej produktywności pracowników przyzwyczajających się do nowych metod i narzędzi pracy

Planowanie systemów informatycznychPlanowanie systemów informatycznych

studium misji gospodarczejanaliza istotnych czynników powodzeniaanaliza konkurencji firmyanaliza zwiększenia wartości wyrobu lub usługi

określenie architektury systemuformułowanie strategii informatyzacji – infoplanu

identyfikacja i ocena obszarów zastosowańprocesy biznesowe i powiązania między nimibazy danychsieci komputerowesprzęt i oprogramowanie


Portfel zarządzania technologiąPortfel zarządzania technologią

krótki

długi

okres

dużemałe

Aplikacje odużym

potencjale

Aplikacjestrategiczne

Aplikacjewspierające

Zasadniczeaplikacje

operacyjne

znaczenie dla firmy

Źródło: Edwards C., Ward J., Bytheway A., The Essence of Information Systems

Formułowanie strategii informatyzacjiFormułowanie strategii informatyzacji

Cele i planygospodarczeCele i plany

gospodarcze

Plan informatyzacji(INFOPLAN)

Plan informatyzacji(INFOPLAN)

Użytkowanesystemy

Użytkowanesystemy

Możliwościtechnologii

informatycznej

Możliwościtechnologii

informatycznej

Analityczny

Pracazespołowa

Metodologia

Oceniający

Użytkownicyi specjaliści

Badania i oceny

Twórczy

Otoczenie

Techniki,procesy


Informatyzacja a strategia gospodarcza firmyInformatyzacja a strategia gospodarcza firmy

STRATEGICZNE PLANOWANIEGOSPODARCZE


INFOPLANINFOPLANPLANOWANIE STRATEGIIINFORMATYZACJI

PLANOWANIE STRATEGIIINFORMATYZACJI

BIZNESPLANBIZNESPLAN


Strategia gospodarcza a informatycznaStrategia gospodarcza a informatyczna

Jak?



Co?

Efektywna alokacja

Środkówtrwałych

Materiałówi energii

Zasobówpracy

KapitałuInformacjiCele

gospodarczeCele

gospodarcze

Jak?Co?

INFOPLAN

Siećkomputerowa

Sprzęt,oprogramowanie

Architekturaprojektowanego

systemu,zasobydanych

Ocenabieżącegosystemu

Strukturaorganizacyjna

kadryinformatycznej

Celeinformatyzacji,

kryteriajakości,przyszłesystemy

Celeinformatyzacji,

kryteriajakości,przyszłesystemy


Metody i techniki analizy sytuacyjnejMetody i techniki analizy sytuacyjnejMetody identyfikowania tych obszarów działalności firmy, których informatyzacja może sprzyjać rozwojowi firmy, skutecznemu wdrażaniu jej strategii rynkowej oraz podnoszeniu konkurencyjności:

sesja MetaPlanu (ang. MetaPlan Session)sesja SWOT (słabe strony, mocne strony, szanse, zagrożenia)analiza Istotnych Czynników Powodzenia (ang. Critical Success Factors)metoda BSP (ang. Business Systems Planning)


Tablica oceny systemówTablica oceny systemówZaawansowanie technologii

(informatycy)

Użytkowaniei doskonalenieModyfikacja

Zaprzestanieużytkowania

Ponownaocena

Znac

zeni

e go

spod

arcz

e(uży

tkow

nicy

)NISKIE

NISKIE WYSOKIE

WYSOKIE


Etapy wzrostu poziomu informatyki w przedsiębiorstwieEtapy wzrostu poziomu informatyki w przedsiębiorstwie

System informatyczny odzwierciedleniem organizacji. Wspomaganie strategicznego zarządzania.

6. Nasycenie

Kontrola użytkownika nad zasobami informatycznymi. Systemy informowania kierownictwa. Organizacyjna integracja przez informatykę.

5. Ukierunkowanie (orientacja) na dane

Zastosowanie baz danych. Struktury danych. Tworzenie systemów.

4. Integracja

Planowanie informatyzacji firmy. Wprowadzenie metod planowania i kontroli. Standaryzacja technologii.

3. Sterowanie (kontrola)

Większa liczba zastosowań w przedsiębiorstwie. Ograniczony udział użytkowników. Brak planowania informatyzacji.

2. Popularyzacja

Pojedyncze zastosowania. Wdrożenie przez twórców zewnętrznych bez udziału użytkowników.

1. Inicjacja

CharakterystykaCharakterystykaEtapEtap

projektowanie systemów informatycznych - lk -...

Documents