ISI Wykłady

Terminarz i zawarto wykadw sala 126 WI1 godz. 12:15-13:45

W1 26.02.2014 Od slajdu 1 do 45

W2 05.03.2014 Od s.46

W3 12.03.2014 Od s.94

W4 19.03.2014 Od s. 125

W5 26.03.2014 Od s.162

W6 03.04.2014 Od s. 218

W7 - 10.04.2014 Od s. 258

W8 - 24.04.2014 Od s. 351

W9 30.04.2014

W10 07.05.2014

W11- 14.05.2014

W12- 28.05.2014

W13-04.06.2014 s. 537

W14-11.06.2014

W15-16.06.2014 (poniedziaek)

INYNIERIA SYSTEMW INFORMATYCZNYCH I

Dr hab. n.t. Boena miakowska prof. ndzw. ZUT

Informacje podstawowe o przedmiocie

Wymiar przedmiotu 30 W+ 30 LWagi w ocenie kocowej za przedmiot:

(1W+0.6 L)/1.65 punktw ECTSPrzedmiot bdzie kontynuowany w semestrze III studiw jako INYNIERIA SYSTEMW INFORMATYCZNYCH II

ZAGADNIENIA ORGANIZACYJNE

TRECI I EFEKTY KSZTACENIA

Treci programowe przedmiotu

Podstawowe pojcia (system informacyjny, informatyczny, inynieria systemw informatycznych).Relacje miedzy systemem informacyjnym a system informatycznym, rola zasobw informacyjnych i procesy informacyjno - decyzyjne w organizacji. System informatyczny jako obiekt techniczny. Obecne i postulowane zastosowania systemw informatycznych. Struktura systemu informatycznego: funkcjonalna, informacyjna, organizacyjno-przestrzenna i techniczna.Pojcia podstawowe w modelowaniu i analizie systemw informatycznych, metody, techniki, metodyki, metodologie. Modele cyklu ycia systemu informatycznego.


Faza analizy i modelowania w cyklu ycia systemu informatycznego organizacji. Analiza systemu informatycznego: czynnoci, podstawowe rezultaty i zoono fazy analizy systemu informatycznego.Analiza potrzeb, precyzowanie zakresu, standardy tworzenia specyfikacji. Metody i narzdzia planowania i analizy systemu informacyjnego. Analiza potrzeb uytkownika. Kluczowe czynniki sukcesu fazy analizy i projektowania systemw informatycznych.Dokumentacja fazy analizy i modelowania systemu informatycznego.


Przegld metod projektowania systemw informatycznych. Metody strukturalne. Modelowanie danych i procesw: cele i metody

opisania potrzeb informacyjnych, diagram zwizkw encji - tworzenie i przykady, okrelenie zalenoci pomidzy procesami, diagramy przepywu danych - elementy, tworzenie i przykady, klasyfikacja (diagramy kontekstowe, zerowe i szczegowe) przykady.

Paradygmat obiektowy w projektowaniu systemu informatycznego. Metody analizy i projektowania obiektowego. UML.

Metody wytwarzania systemw informatycznych uwarunkowanych czasem.

Podejcie socjo - spoeczne do budowy systemw informatycznych. Swobodne metody wytwarzania oprogramowania. Metodyka Scrum,

FDD, programowanie ekstremalne, projektowanie adaptacyjne,

Projektowanie systemw informatycznych z uyciem wielokrotnym.


Szacowanie czasu realizacji systemw informatycznych, kosztw, efektw, zagroe i ryzyka w procesie wytwarzania systemu informatycznego. Jako systemw informatycznych i jako procesw jego budowy.Bezpieczestwo systemw informatycznychKorzyci z inwestycji informatycznych. Ryzyko przedsiwzi informatycznych

Wskanik zagroenia przedsiwzicia informatycznego

Metody testowania oprogramowania.Techniki wspomagajce procesy wytwarzania oprogramowaniaZaliczenie wykadu

Efekty ksztacenia w obszarze wiedzy

IC_1A_C/05/01_W01 student zna metody gromadzenia i przetwarzania danych w systemach informatycznychIC_1A_C/05/01_W02 student zna podstawowe techniki, metody i metodyki tworzenia systemw informatycznychIC_1A_C/05/01_W03 student zna metody strukturalne, obiektowe i elastyczne projektowania systemw informatycznychIC_1A_C/05/01_W04 - zna zastosowania systemw informatycznych

Efekty ksztacenia w obszarze umiejtnoci

IC_1A_C/05/01_U01 student potrafi przeprowadzi proces analizy systemu informatycznego z uyciem wybranej metodyIC_1A_C/05/01_U02 - potrafi przeprowadzi proces projektowania systemu informatycznego z uyciem wybranej metodologii oraz metodykiIC_1A_C/05/01_U03 - potrafi sporzdzi prototyp systemu informatycznegoIC_1A_C/05/01_U04 - potrafi opracowa odpowiedni do etapu cyklu ycia systemu informatycznego dokumentacje techniczna

Efekty ksztacenia w obszarze kompetencji spoecznych

IC_1A_C/05/01_K01 - rozumie potrzeb stosowania obowizujcych zasad prawnych i aspektw zwizanych z dziedzin przedmiotow w procesie wytwarzania systemw informatycznych

Zasady zaliczania przedmiotuZaliczenie pisemne (5 pyta-zada: pytania 1 weryfikacja IC_1A_C/05/01_W01; pytanie 2 -IC_1A_C/05/01_W02, itd. za zadanie weryfikuje umiejtnoci od IC_1A_C/05/01_U01 do IC_1A_C/05/01_U04 oraz IC_1A_C/05/01_K01)Wagi w ocenie kocowej za przedmiot:

(1W+0.6 L)/1.65 punktw ECTSTermin zaliczenia wykadw:

Rodzaj studiwTermin

Kierunek Inynieria Cyfryzacji studia stacjonarne I stopnia

Termin podstawowy 16.06.2014 r. sala 126 WI2

I termin poprawkowy 30.06.2014 r. Godz. 12-14 sala 215

II termin poprawkowy 10.09.2014 r. godz. 10-12 sala 215

13

Jeli wszystkie efekty osignito w terminie podstawowym (pozytywna ocena z kadego zadania) to:

Jeli nie osignito wszystkich efektw w terminie podstawowym to:

ocena kocowa za wykad = rednia z ocen uzyskanych za poszczeglne pytania

Zasady zaliczania przedmiotuZasady zaliczania przedmiotu

terminu podstawowego = ndst.

student ma prawo do dwch poprawek niezaliczonych efektw ksztacenia,

gdzie ip liczba poprawekjest podstaw do obliczenia pozytywnej oceny za wykad:

ocena kocowa za wykad = (rednia z pozytywnych ocen efektw + 2 *ip)/(ip+1)

14

Ocena za

efekt 1

Ocenaza

efekt 2

Ocenaza

efekt 3

Ocena za

efekt 4

Ocena za

efekt5-8

Ocena za

efekt 9

I poprawka II poprawka

Ocena kocowa za wykad

3 3 5 5 4 4 Nie dotyczy Nie dotyczy

dobry(podstawa: rednia z pozytywnych ocen za

efekty) 4,0 Ocena za

przedmiot

3 2 5 5 2 5

Zaliczono efekt 2 oraz efekty 5-8 na ocen

dst

Nie dotyczy

W terminie podstawowym ocena

ndstW terminie

poprawkowym dobry(podstawa: rednia z pozytywnych ocen za

efekty)3,0 Ocena za wykad

3 2 5 5 2 5

Zaliczono efekt 2

ocen dstefekty 5-8

niezaliczone (ndst)

Zaliczono efekt 5-8 na ocen dst

W terminie podstawowym terminie

pierwszej poprawkiocena ndst

W drugim terminiepoprawkowym dobry(podstawa: rednia z pozytywnych ocen za

efekty)2,67 Ocena za wykad

LiteraturaCadle J., Yeates D.: Zarzdzanie procesem tworzenia systemw informacyjnych ,WNT, Warszawa 2001. Dbrowski W., Stasiak A., Wolski M.: modelowanie systemw informatycznych w jzyku UML 2.1 w praktyce, PWN 2007Flasiski M.: Zarzdzanie projektami informatycznymi, PWN, Warszawa 2006.Graessie P. i inni: UML 2.0 w akcji, Przewodnik oparty na projektach, Helion 2008Beynon-Davies Paul:Inynieria systemw informatycznych Olejniczak W., Szyjewski Z.: Inynieria systemw informatycznych w e-gospodarce,

Literatura cd..Jaszkiewicz A.: Inynieria oprogramowania, Helion, Gliwice 1997.Leffingwell D. i inni: Zarzdzanie wymaganiami. Seria: Inynieria oprogramowania, WNT, Warszawa 2003Pritchard C.: Zarzdzanie ryzykiem w projektach, teoria i praktyka, WIG-PRESS, Warszawa 2002 miaek M.: Zrozumie UML 2.0 metody modelowania obiektowego, Helion, Gliwice 2005.Wrycza S. i inni: Jzyk UML 2.0 w modelowaniu systemw informatycznych, Helion, Gliwice 2005.

Konsultacjeroda godz. 14:00-15:30 pokj 113

Kontakt :[email protected]

PODSTAWOWE DEFINICJE

Systemy informacyjne (systematyka poj)zbir zasad, metod i procedur tworzenia, przesyania, magazynowania i przetwarzania informacjiformalny zesp rodkw kapitaowych oraz algorytmw, ktrych funkcjonowanie przejawia si w zbieraniu, kodowaniu, magazynowaniu, przetwarzaniu, dekodowaniu i uytkowaniu danych potrzebnych dla podejmowania decyzji i zarzdzaniausystematyzowana i uporzdkowana sie powiza midzy takimi elementami jak: czowiek, dane, metody oraz urzdzenia do zbierania, gromadzenia, przesyania i przetwarzania danych, majcych na celu zaspokojenie potrzeb informacyjnych zainteresowanych ogniw

Systemy informatyczny(systematyka poj)

celowe zestawienie ludzi, danych, procesw, sposobw komunikacji, infrastruktury sieciowej i urzdze komputerowych, ktre to elementy wspdziaaj w celu zapewnienia codziennego funkcjonowania organizacji jak rwnie wspieraj rozwizywanie problemw i podejmowanie decyzji przez kadr kierowniczspenia funkcj systemu informacyjnegookrelony, wyodrbniony obszar systemu informacyjnego dla danego obiektu obsugiwany za pomoc technicznych rodkw informatykioparte na technologii komputerowej rozwizanie pojedynczego problemu biznesowego. Moe by to aplikacja, rozwizanie sprztowe lub poczenie obu tych skadnikw

Systemy informacyjne (systematyka poj)system informatyczny moe by jedn z czci skadowych systemu informacyjnegosystem informacyjny moe si skada z wicej ni jednego systemu informatycznego system informacyjny niekoniecznie musi zawiera elementy infrastruktury ITzbir powizanych ze sob elementw, ktrego funkcj jest przetwarzanie danych przy uyciu techniki komputerowej, takich jak: Sprzt, Oprogramowanie, Zasoby osobowe (ludzie), elementy organizacyjne (czyli procedury korzystania z systemu informatycznego, instrukcje robocze itp.) oraz elementy informacyjne (np. bazy wiedzy - na przykad podrcznik ksigowania w wypadku systemu FK)

Porwnanie pojSystem informacyjny - to system, ktrego celem

dziaania jest dostarczanie odbiorcy informacji, uytecznej do jego dziaania.Przykady : system monitorowania bezpieczestwa

obiektu, telewizja itp.

System informatyczny (SI) - to system informacyjny lub informacyjno-decyzyjny w ktrym zastosowano komputery. Przykady: system rekrutacji na UWM, system finansowo-ksigowy itp.

Informatyka w kompleksowym zarzdzaniu organizacj (np.: gospodarcz)

PR

OD

UK

CJA

/ S

ER

WIS

RE

ALI

Z. Z

AM

W

IEN

IA

OB

SU

GA

PO

SP

RZE

D.

Procesgospodarczy

SP

RZE

DA

DY

STR

YB

UC

JA

ZAO

PATR

ZEN

IE

RO

ZW

J P

RO

DU

KT

WCele gospodarcze

STARTEGICZNE

OPERACYJNE

Organizacja

SPECJALISTA

KIEROWNIK

DYREKTOR

ZARZD

Rozwj SI

SYSTEMEKSPERCKI

SYSTEM WSPOMAGANIA

DECYZJI

SYSTEM INFORMOWANIA KIEROWNICTWA

SYSTEM INFORMATYCZNY

ZARZDZANIA

SYSTEM REJESTRACYJNY

RO

ZW

J SY

STE

MU

INFO

RM

ATY

CZN

EG

O

NAJWYSZY SZCZEBEL ZARZDZANIA

WYSZA I REDNIA KADRA KIEROWNICZA, ANALITYCY BIZNESOWI

REDNIA KADRA KIEROWNICZA, ANALITYCY BIZNESOWI

REDNIA KADRA KIEROWNICZA, PERSONEL ADMINISTRACYJNY

PERSONEL ADMINISTRACYJNY, OPERATORZY, AUTOMATY

uytkownik

SYSTEMEKSPERCKI

SYSTEM WSPOMAGANIA

DECYZJI



ZARZDZANIA


RO

ZW

J SY

STE

MU

INFO

RM

ATY

CZN

EG

O

DECYZJE BIZNESOWE

INFORMACJA ZARZDCZA

DANE ZAGREGOWANE

DANE ZINTEGROWANE

WYSPY INFORMACYJNE

produkt

Rozwj SI

SYSTEMEKSPERCKI

SYSTEM WSPOMAGANIA

DECYZJI



ZARZDZANIA


RO

ZW

J SY

STE

MU

INFO

RM

ATY

CZN

EG

O

CELE STRATEGICZNE

CELE OPERACYJNE

Rozwj SI

Restrukturyzacja organizacji

Zmiana struktury (czsto zmniejszenie ilociowe): zasobw organizacji (majtek, zatrudnienie) rde finansowania asortymentu produktw rynku zbytu

w celu utrzymania lub wzmocnienia pozycji rynkowej

Rynkowa: konkurencja krajowa, import, opacalno eksportu, nowe formy marketingu, jako produktu, potencja produkcyjny, sieci dystrybucji, rozeznanie rynkuProduktowa: oferta produktowa, jako produktw, nowoczesne maszyny, koszty jednostkowe produkcji,

Strategie restrukturyzacji przedsibiorstw w Polsce

Co to jest Business Process Reengineering (BPR)?

Metoda szybkiego i radykalnego przeprojektowania strategicznych, dodajcych warto z punktu widzenia klienta, procesw oraz powizanych z nimi systemw, procedur, struktury organizacyjnej, w celu optymalizacji toku pracy i produktywnoci organizacji

D. Morris, J. Brendon

BPR to fundamentalne przemylenie od nowa i radykalne przeprojektowanie procesw w firmie, prowadzce do dramatycznej (przeomowej) poprawy osiganych wynikw (takich jak koszty, jako, serwis i szybko)

M. Hammer, J. Champy

Co to jest Business Process Reengineering ?...

Przedmiot reinynierii

Definicja procesu:

Zbir czynnoci wymagajcy na wejciu zasobw i dajcy na wyjciu rezultat, majcy konkretn warto dla klienta

M. Hammer, J. Champy

iOrganizacja funkcjonalna a procesy (np.: gospodarcze)

ZLECENIE PRODUKCYJNE

REALIZACJA ZLECENIASPRZEDA

Cel reorganizacji procesw

Np.: OSIGNICIE PRZEWAGI KONKURENCYJNEJ

poprzez

Obnianie kosztw proceswPodnoszenie jakoci produktw

Skracanie czasu trwania proceswPodnoszenie satysfakcji klientw

Skala i zakres zmian w reinynierii

WSKI SZEROKI

WYGADZANIE

PRZEPROJEKTOWANIE

Analiza wariantw zmian

Skala zmian

Zakres zmian

Moliwe efektyUmiarkowana poprawa DziaalnociRyzyko:Due, due skomplikowanie

Moliwe efektyRadykalna poprawa caej dziaalnociRyzyko:Due, decyzja:wszystko albo nic

Moliwe efektyNiewielki wpyw na dziaalno firmyRyzyko:Mae

Moliwe efektyRadykalna poprawa wybranych proceswRyzyko:Ograniczone do wybranych procesw

Kontekst czasowy wdraania informatyki i reinynierii

Poprzedzenie reorganizacji procesw wdroeniem systemu informatycznego

Jednoczesne wdroenie systemu informatycznego i przeprowadzanie reorganizacji procesw

Przeprowadzenie reorganizacji procesw przed rozpoczciem procesu wdroenia systemu informatycznego

Najpierw system informatyczny, pniej reorganizacja

Zaleta: mniejsze ryzyko niepowodzenia, mniejsze obcienie zasobw ludzkich

Wada: konieczno rekonfiguracji systemu w celu uwzgldnienia zmian, dodatkowa pracochonno, odoenie korzyci w czasie, iteracyjne dochodzenie do rozwizania

Wdroenie SI:

Reorganizacja:

Jednoczenie system informatyczny i reorganizacja

Zaleta: krtki czas przeprowadzania zmian i uzyskania korzyci, dobrze dopracowane zmiany i narzdzia

Wada: due ryzyko niepowodzenia, due obcienie zasobw ludzkich

Wdroenie SI:

Reorganizacja:

Najpierw reorganizacja, pniej system informatyczny

Zaleta: brak

Wada: bardzo kosztowne stosowanie narzdzi zastpczych/starych, niebezpieczestwo zaniecha lub spycenia zmian, ktre wymagaj wsparcia informatycznego

Wdroenie SI:

Reorganizacja:

Informatyka jako czynnik umoliwiajcy przeprowadzenie reinynierii procesw

Robienie tego co ju robimy lepiej, szybciej i taniej (w nowy sposb)

Robienie zupenie nowych rzeczy dziki nowym moliwociom, jakie daje nam informatyka (pomysy na nowe dziaania)

Informatyka jako narzdzie wspomagajce przeprowadzenie restrukturyzacji

Pomiar efektywnoci istniejcych procesw, analiza procesw

Diagnoza i analiza istniejcych procesw

Projektowanie nowych procesw

Zarzdzanie procesem restrukturyzacji

Benchmarking procesw

Wzajemne oddziaywanie systemu informatycznego i reinynierii

Zmiany wymuszane przez system informatyczny

Zmiany wspomagane przez system informatyczny

Restrukturyzacja i reinynieria a SI

sia nowych technologii nie ley w nich samych

a w kreatywnych i innowacyjnych zastosowaniach

ZADANIA INYNIERII SYSTEMW

INFORMATYCZNYCH

Czym zajmuje si inynieria systemw informatycznych?

Inynieria umiejtno projektowania i realizacji projektw, np. budowli, systemw, urzdze itp.

Inynieria systemw informatycznych to dziedzina inynierii, ktra obejmuje wszystkie aspekty (nie tylko techniczne) procesu tworzenia systemw informatycznych (SI), we wszystkich fazach jego istnienia i wytwarzania

Dwa nurty inynieria systemw informatycznych

W inynierii SI wystpuj dwa nurty:formalny - postuluje stosowanie metod formalnych; praktyczny postuluje metody powstae na bazie wiedzy i dowiadcze zdobytych w procesie realizacji prac projektowych nad SI. Stosowane s tu specjalne notacje graficzne, nie w peni sformalizowane.

Tworzeniem, rozwojem i pielgnacj systemw informatycznych

zajmuje si

Inynieria systemw informatycznych

(zwana rwnie inynieri oprogramowania)

Czym zajmuje si inynieria systemw informatycznych?

Inynieri systemw informatycznych jest dziedzin praktyczn, a jednoczenie sztuk projektowania, utrzymywania i rozwoju aplikacji.

Dziaania te mog si zakoczy albo sukcesem, albo porak.

Inynieria systemw informatycznych odsania tajniki:

funkcjonowania systemw informatycznych, projektowania systemw informatycznych, implementacji systemw i tworzenia aplikacji, metod zarzdzania procesem tworzenia SI

Czym zajmuje si inynieria systemw informatycznych? Okrela:

Sposoby prowadzenia przedsiwzi informatycznych;

Techniki planowania, szacowania kosztw, harmonogramowania i monitorowania;

Metody analizy i projektowania systemw;

Techniki zwikszania niezawodnoci oprogramowania;

Czym zajmuje si inynieria systemw informatycznych? Okrela:

Sposoby testowania systemw;

Sposoby przygotowania dokumentacji technicznej i uytkowej;

Procedury kontroli jakoci;

Metody redukcji kosztw konserwacji;

Techniki pracy zespoowej

Dlaczego ta dziedzina jest wana?

Oglny kryzys procesw wytwarzania systemw informatycznych

Ciga potrzeba doskonalenia i usprawniania proceswwytwarzania systemw informatycznych

Nowe zastosowania systemw informatycznych

Dlaczego zdarzaj si nieudane projekt informatyczny ?

Miar niepowodzenia projektu jest niedotrzymania jednego lub wicej z nastpujcych parametrw:

Budet

Czas realizacji

Funkcjonalno

Rzeczywisto w statystyce

w ponad 50% przedsiwziciach informatycznych przekraczany jest termin i budet projektu,

ponad 25% przedsiwzi informatycznych jest przerywanych.

Rzeczywisto w statystyce Marsz ku klsce ???

Zdecydowana wikszo duych projektw informatycznych jest z gry skazana na niepowodzenie!

=

Polskie przykady

Informatyzacja PZUInformatyzacja ZUSSystem POJAZDInformatyzacja urzdw skarbowych

The Standish Group

Kolejne raporty: The CHAOS Chronicles od 1994 r. do 2013 r.

Amerykaska instytucja badawcza.Dziaalno: kompleksowa analiza rynku amerykaskiego w zakresie skutecznoci realizacji projektw informatycznych. www.standishgroup.com

Dlaczego CHAOS?

O chaosie w projektowaniu SI decyduje przewaajcaliczba przedsiwzi zakoczonych : niepowodzeniem w sensie ilociowym, czyli:przekroczeniem estymowanego czasu trwania

dziaa projektowych;przekroczeniem budetu;porzuceniem z okrelonych powodw;

niepowodzeniem w sensie jakociowym, kiedy gotowy system wykazuje du niezgodno z pierwotn specyfikacj wymaga uytkownika.

Chaos stan niezorganizowania, zamtu, nieadu

rdo: http://versionone.com/assets/img/files/ChaosManifesto2013.pdf

Udany projektZakres

Czas

Koszty

Produkt kocowy

TerminKoszty realizacji

Udany projekt

Realizacja projektw - statystykiRok

Jakie projekty

2004 2006 2008 2010 2012

Nieudane czciowo

53 % 44 % 44 % 42 % 43 %

Nieudane cakowicie

18 % 19% 24 % 21 % 18 %

Udane projekty

29 % 35 % 32 % 37 % 39 %


0%10%

20%

30%40%

50%60%

70%

80%90%

100%

2004 2006 2008 2010 2012

Udane projekty

Nieudane cakowicie

Nieudane czciowo

Realizacja projektw - statystyki

Rok

czynnik

2004 2006 2008 2010 2012

Czas 84 % 72 % 79 % 71 % 74 %

Koszt 56 % 47% 54 % 46 % 59 %

Zrealizowanafunkcjonalno zaprojektowana

64 % 68 % 67 % 74 % 69 %


0%

10%

20%

30%

40%

50%

60%

2004 2006 2008 2010 2012

Nieudane czciowo

Nieudane cakowicie

Udane projekty

Czynniki sukcesuCzynnik 1994 2000

Zaangaowanie uytkownika 16% 16%

Wsparcie zarzdu (kierownictwa, sponsora) 14% 18%

Jasne sformuowanie wymaga 13% 6%

Waciwe planowanie 10% Brak

Realne oczekiwania 8% Brak

Krtsze etapy projektowania 8% 10%

Kompetentny zesp projektowy 7% Brak

Jasno okrelona wasno projektu (odpowiedzialno)

5% Brak

Jasna wizja i cele 3% 12%

Ciko pracujcy, skupiony na projekcie zesp 2% Brak

Dowiadczony kierownik zespou Brak (ew. 7) 14%

Formalna metodyka Brak 6%

Zastosowanie standardw infrastruktury Brak 8%

Wiarygodne oszacowanie Brak (ew. 4) 5%

Inne 1% 5%

Realizacja maych projektw czynniki sukcesu

Czynniki sukcesu Liczba projektw

Wsparcie zarzdu (kierownictwa, sponsora) 20

Zaangaowanie uytkownika 15

Optymalizacja 15

Wiedza z dziedziny zarzdzania projektem 12

Zwinne procesy 10

Jasne sformuowanie wymaga 6

Dojrzaoci rodowiska 5

Realne oczekiwania - wykonalno 3

Narzdzia i infrastruktura 1

Wyniki badania 20 maych(do 1mln$) projektw

ukoczonych w 2012 r.


Mae a due projekty rnice w osigniciu sukcesu

Projekty mae (do 1 mln $) Projekty due (powyej 10 mln $)

Nieudane czciowo

Nieudane cakowicie

Udane projekty

Nieudane czciowo

nieudane ckowicie

udane projekty

Dane z 2012 roku


Wnioski z badaChaos w obszarze projektowania SI spowodowany jest bdami ludzkimi, a nie czynnikami technologicznymiSI maj coraz wiksz zoono (np.: Windows 2000 35 mln linii kodu a Windows XP okoo 50 mln linii kodu)Liczba osb zaangaowanych w tworzenie zoonych SI wzrasta (np.: przy tworzeniu Windows NT 3.1 brao udzia 200 programistw i 140 testerw za w Windows 2000 - 1400 programistw i 1700 testerw)Wzrasta liczba uytkownikw zoonych SI (np.: liczba uzytkownikw Linuxa w roku 1992 wynosia 1000 a w 1998 7,5 mln osb ).

Niewaciwa interpretacja wymaga klienta

Czste i zbyt pne zgaszanie zmian zwizanych z oprogramowaniem

Nieprawidowe oszacowanie czasu realizacji projektu (opnienia czasowe)

Nieprawidowe oszacowanie budetu i zasobw

Problemy w komunikacji pomidzy czonkami zespou projektowego

Podstawowe problemy w tworzeniu SI

Dua liczba maych bdw w oprogramowaniu, wynikajca z nieprawidowego testowania

Problemy wdroeniowe i brak odpowiedniej pielgnacji oprogramowania

Podstawowe problemy w tworzeniu SI

rda zoonoci systemw informatycznych

Software

Zoono technologiczna

Zoono dziedzinowa

Zoono psychologiczna

Metody projektowaniaCigle niedoskonae metody i narzdzia tworzenia i weryfikacji systemw informatycznych

UML

DFDERD

XP

SADT

PSL/PSA

RSL/REVS

HELP!

Kryzys oprogramowaniaDugi i kosztowny cykl tworzenia oprogramowania

Dugi i kosztowny cykl ycia SI, wymagajcy staych zmian

Wysokie koszty utrzymania oprogramowania

Wysokie prawdopodobiestwo niepowodzenia projektu programistycznego

Sprzeczno pomidzy odpowiedzialnoci wspczesnych systemw informatycznych, a ich zawodnoci

Problemy wspdziaania niezalenie zbudowanego oprogramowania, szczeglnie istotne przy dzisiejszych tendencjach integracyjnych

Kryzys oprogramowania

Uzalenienie organizacji od systemw komputerowych i przyjtych technologii przetwarzania informacji (czsto niestabilnych w dugim horyzoncie czasowym)

Denie do przystosowania istniejcych i dziaajcych systemw do nowych wymaga i tendencji oraz platform sprztowo-programowych

Niski stopie powtarzalnoci poszczeglnych przedsiwzi

Niska kultura ponownego uycia wytworzonych komponentw projektw i oprogramowania

Szybki rozwj narzdzi informatycznych

Prawa Murphiego

gwne bdy powstaj na styku: klient firma informatyczna, projektant-programista, programista-komputer

jeeli gdziekolwiek moe pojawi si bd, tam na pewno si pojawinie ma programw bezbdnych, s tylko takie w ktrych dotd nie znaleziono bdu

Obecne i postulowane zastosowania SI - rodzaje SI

Transakcyjne on-lineTransakcyjne off-lineProste systemy raportujceSystemy informowania kierownictwaSystemy inteligentne

Zoono

Cza

s re

akcj

i

Dua

Maa

Krtki

Dugi

Istniej oczywicie wyjtki np. bankowe systemy kredytowe

1960 1970 1980 1990 2000

IC

MRP

MRP II

ERP

DEM

IC (Inventory Control) - zarzdzanie gospodark magazynow

MRP (Material Requirments Planing) - planowanie potrzeb materiaowych poprzez wydawanie zlece zakupu i produkcji dokadnie w takim momencie, aby dany produkt pojawi si w potrzebnej chwili i wymaganej ilociMRP II (Manufacturing Resource Planing) - planowanie zasobw produkcyjnychposzerzone o bilansowanie zasobw produkcyjnych i dystrybucj (gwny skadnik BIS)

ERP (Enterprice Resource Planing) - (okrelana jako MRP III - Money Resource Planing lub MRP II Plus) planowanie zasobw przedsibiorstwa wraz z procedurami finansowymi, w tym ksigowo zarzdcza, cash flow i rachunek kosztw dziaania

DEM (Dynamic Enterprice Modeler) - dynamiczne modelowanie przedsibiorstwa, umoliwiajce bezporednie przejcie od modelu firmy do gotowej konfiguracji aplikacji dla poszczeglnych uytkownikw

CRM

CRM (Customer Relationship Management) - zarzdzanie kontaktami z klientem

Ewolucja SI do zarzdzania firm

Standard MRP II Plus to rozwinicie koncepcji wariantu rozwinitego standarduMRP II. W zwizku z tym realizuje on dodatkowo nastpujce funkcje:

zarzdzanie zmianami konstrukcyjnymi i technologicznymi, zarzdzanie dokumentacj techniczn, integracja z systemami CAD/CAM/CAP, zarzdzanie remontami i serwisem (zlecenia i umowy), zarzdzanie jakoci, dystrybucj (planowanie potrzeb, transportu i obsuga zlece) i rozwinita

obsuga sprzeday, zarzdzanie rodkami trwaymi i wyposaeniem, zarzdzanie kadrami i pacami i strumieniami rodkw patniczych, rachunkowo zarzdcza, kontroling, generowanie raportw, integracja multimediw, przegldarki baz danych, itp.

MRP II Plus (ERP)

Standard DEM to zintegrowane narzdzie umoliwiajce zarwno opracowanienowych jak i udoskonalanie istniejcych procesw gospodarczych (reinynieria).Umoliwia on dynamiczne stworzenie modelu lokalnego (np. jeden dzia firmy)jak i obejmujcy wszystkie dziay korporacji w oparciu o odpowiednie modeleodniesienia.

GWNA BIBLIOTEKA WZORCW (REPOZYTORIUM)

MODEL ODNIESIENIA

BIBLIOTEKA KOMPONENTW

FAZY ZAKRES

PROJEKT MODELU PROJEKT MODELU

LOKALNEGO

Model oglny

Model branowy

Model przedsibiorstwa

DEM

Wprowadza si tu optymalizacj, ktra pozwala na bieco wprowadzazmiany w funkcjonowaniu firmy. Dziki temu przedsibiorstwo wraz zsystemem yje i ewoluuje.

krytyczne wskaniki sukcesu

wizjaImplementacja

(faza podstawowa)optymalizacja. . . . . . . . . . . . . . . . . .

optymalizacja

dyskusje symulacje

model funkcjonalny

model procesowy

dyskusje z Zarzdem

przegld z uytkownikami kluczowymi

DEM

Strategia rozwoju organizacji i informatyzacji

MISJA ORGANIZACJIMISJA ORGANIZACJI

BADANIE OTOCZENIA(szanse i zagroenia)

BADANIE ORGANIZACJI

(mocne i sabe strony)

WIEDZA O RYNKUTRENDY

TECHNOLOGICZNE

STRATEGIA ROZWOJU ORGANIZACJI

STRATEGIA INFORMATYZACJI ORGANIZACJI

stacje robocze systemuserwer przedsibiorstwa

serwer kontrahenta serwer klienta serwer dostawcy

sie rozlega

sie lokalna

ZSI a otoczenie organizacji moliwoci systemw rozproszonych

ZSI

SystemySystemy klasyklasy MRP,MRP, ERPERP stanowistanowi rozwizaniarozwizania dedykowanededykowane wewntrznemuwewntrznemuzarzdzaniuzarzdzaniu przedsibiorstwemprzedsibiorstwem..SystemySystemy CRMCRM ((CustomerCustomer RelationshipRelationship ManagementManagement)) pozwalajpozwalaj rwnierwniezarzdzazarzdza kontaktamikontaktami zz klientemklientem..

back office

KLI

EN

T (K

ON

TRA

HE

NT)

KLI

EN

T (K

ON

TRA

HE

NT)

CRMCRMMRP (ERP)

PRZEDSIBIORSTWO - ORANIZACJA

front office

Systemy CRM

CRM(Customer Relationship Management)

CM (Contact Management)

proste jednostanowiskoweaplikacje,

funkcje kalendarza i bazadanych pozwalaj na analizdanych dotyczcych klienta ihistorii kontaktw

SFA(Sales Force Automation)

udostpnianie klientowi informacji on-line,

zarzdzanie sprzeda, obsuga klienta w ramach

jednego systemuoraz:oraz:

CRS - Call Reporting SystemsTMS - Territory Management SystemsSMS - Sales Management SystemsSTA - Sales Team Automation

Systemy CRM

WWW E-mail fax ... telefonSystemy wymiany informacji

OBSUGA KLIENTW

SERWISMARKETING SPZREDA

zarzdzania firm zarzdzania zasobami

ludzkimi zarzdzania finansami

SYSTEMY INFORMATYCZNE HURTOWNIE DANYCH

ZARZDZANIE WIEDZ

ANALITYKA

FRO

NT

OFF

ICE

BA

CK

OFF

ICE

KLIENCI

...

systemy obsugujce kanay komunikacji z klientem,systemy front-office obejmujce m.in. marketing, sprzeda,wsparcie klienta,

systemy analityczne.CRM:

sprzeda: zarzdzanie kontaktami (profile, struktura, historiakontaktw sprzeday),

zarzdzanie kontem (generowanie ofert, zamwienia,transakcje),

analizy w ramach cyklu sprzeday, monitorowanie statusu klienta i potencjalnych kontaktwhandlowych;

zarzdzanie terminarzem i korespondencj: kalendarz i baza danych uytkownikw (grup), obsuga poczty tradycyjnej i elektronicznej (fax, e-mail);

marketing: zarzdzanie kampani, katalog produktw, konfigurator produktw, cenniki i oferty, analizy efektywnoci kampanii, dystrybucja informacji o kilentach zainteresowanych ofert;

Funkcje (moduy) CRM:

telemarketing: ukadanie list telefonicznych wg definicji grup docelowych, automatyczne wybieranie numeru, generowanie list potencjalnych klientw, zbieranie zamwie;

serwis i wsparcie klienta po sprzeday: przydzielenie, ledzenie i raportowanie zada, zarzdzanie problemem serwisowym, kontrola zamwie, obsuga gwarancyjna i pogwarancyjna;

integracja z systemami ERP: zarzdzanie finansami, ksigowo, produkcja, dystrybucja, zarzdzanie zasobami ludzkimi;

synchronizacja danych - dotyczy wspdziaania pomidzyurzdzeniami (np. laptopy) a centraln baz danych lub innymibazami i serwerami aplikacji;

e-commers - realizowanie handlu elektronicznego; call center - usugowe wsparcie klienta.

Funkcje (moduy) CRM:

systemy ewidencyjno-transakcyjne

STOPIE INTEGRACJI

CZASCZAS

1960 1970 1980 1990 2000

systemy informacyjno-decyzyjne

systemy wspomagania decyzjisystemy eksperckie

systemy informowania kierownictwa

systemy sztucznej inteligencji

zintegrowane systemy informatyczne

Ewolucja SIZ

systemy czasu rzeczywistego

system zarzdzania zorganizowany (SIZ) moduowo

obsugujcy wszystkie sfery dziaalnociprzedsibiorstwa

wszystkie zasoby danych, procedury zarzdzania,sterowanie i regulacja procesw wytwrczych sprzetwarzane przy wsparciu technologiiinformatycznej

Mwic o ZSI naley mie na uwadze:

Umoliwia etapowe wdraanie tych skadowych,ktre s niezbdne z uwagi na specyfik firmy.

Poczwszy od marketingu i planowania orazzaopatrzenia, poprzez techniczne przygotowanieprodukcji i jej sterowanie, dystrybucj, sprzeda,gospodark remontow, a do prac finansowo-ksigowych i kadrowych.

Ewolucja ZSI

Cechy ZSIZintegrowane systemy informatyczne stanowi urzeczywistnienie idei integracjikompleksowych systemw informatycznego wspomagania procesw zarzdzania wprzedsibiorstwie z kompleksowymi systemami komputerowego wytwarzania.

Gwne cechy ZSI:

kompleksowo funkcjonalna - obejmuje wszystkie sfery firmy,

integracja danych i procesw - dotyczy wymiany informacji wewntrz firmy jak iz jej otoczeniem,

elastyczno strukturalna (skalowalno) i funkcjonalna - dynamicznedopasowanie przy zmiennych wymaganiach i potrzebach otoczenia,

otwarto - moliwo rozbudowy systemu i tworzenie nowych poczezewntrznych,

zaawansowanie merytoryczne - moliwo penego informatycznego wsparciaprocesw informacyjno-decyzyjnych

zaawansowanie technologiczne - zgodno ze standardami sprztowo-programowymi oraz moliwo przenoszenia na inne platformy

zgodno z przepisami (np. ustaw o rachunkowoci)

Faza I - Analiza przedsibiorstwa obejmuje:okrelenie celw strategicznych przedsibiorstwazdefiniowanie problemw, wymaga i kryteriw wyboru ZSIudokumentowanie istniejcych procedur dziaaniaopracowanie opisw procesw podstawowych i pomocniczychprzygotowanie koniecznej restrukturyzacji przedsibiorstwaocena skali przedsiwzicia, ryzyka, kosztw i terminw realizacji

(studium wykonalnoci)

Faza II - Opracowanie koncepcji informatyzacji przedsibiorstwaobejmuje:

selekcja i wybr gotowego ZSIzestawienie oprogramowania aplikacyjnego wedug modelu

prototypowaniamodelowanie konfiguracji oprogramowania narzdziowego,

systemowego, sieciowego oraz opracowanie projektuinfrastruktury technicznej

Przykadowy sposoby integracji cd

Informatyzacja organizacji a problemy jej restrukturyzacji

(uwarunkowanie tworzenia ZSI)

Informatyzacja organizacji, majca na celu wdroenie ZSI, wymagapoprzedzenia tego procesu zmianami o charakterze organizacyjnym.

REALIZACJA ZSI

strategia rozwoju organizacji oraz

strategia jej informatyzacji

restrukturyzacja organizacji

techniczna infrastruktura

informatyki

oprogramowanie aplikacyjne oraz

transfer wiedzy

Restrukturyzacja jest przemyleniem od podstaw i radykalnymprzeprojektowaniem procesw gospodarczych w celu osigniciazdecydowanego polepszenia biecych, zasadniczych miar wydajnoci(jako, szybko dziaania, poziom obsugi klientw).

Rodzaje restrukturyzacji:podstawowa - orientacja ta podwaa wszystkie zaoenia, na ktrych

opiera si dziaalno gospodarcza, czyli dotychczasow strategiprzedsibiorstwa oraz jego procedury operacyjne,

radykalna - w zalenoci od potrzeb tworzone (definiowane) s noweprocesy, a nie usprawniane istniejce,

istotna - wzrost efektywnoci ma na celu znaczne podniesieniesprawnoci funkcjonowania przedsibiorstwa, a nie jedynie jejmarginalny przyrost, osigany w wyniku technik cigego doskonalenia,

restrukturyzacja procesw - przeamuje si dotychczasowe podziay funkcjonalne i likwiduje w ten sposb nieefektywno, bdc skutkiem przekazywania pracy midzy wyspecjalizowanymi jednostkami (dziaami) i pracownikami; dziaanie musi by zorganizowane wok procesw, a nie wok indywidualnych zada.


W konsekwencji chodzi o stworzenie przedsibiorstwa nowego typu(zorientowanego procesowo).

okrelenie procesw w przedsibiorstwie (pocztek-koniec,waciciel, dostawcy-klienci, wsplne zalenoci czyli podprocesy,powizania z zasobami i zasileniami),

zmiany w zarzdzaniu (wizja i misja przedsibiorstwa, kulturawewntrz-organizacyjna, metody kierowania, rekrutacja imotywacja pracownikw

Informatyzacja nie moe wspiera nieefektywnych i niewydajnychprocesw. Dziaania restrukturyzacyjne powinny by nadrzdne wstosunku do prac projektowo-wdroeniowych ZSI.

Informatyzacja przedsibiorstwa: faza pierwsza - analiza i definicja procesw, celw, funkcji, struktur

danych, itp., faza druga - modelowanie procesw zgodnie z celami przedsibiorstwa,

utworzenie struktury organizacyjnej firmy i modelu systemuinformatycznego,

faza trzecia - tworzenie szczegowych specyfikacji procesw itworzenie ZSI.



Restrukturyzacja przedsibiorstwa

Przygotowanie infrastruktury informatycznej

Budowa ZSI

Podejcie konwencjonalne --dziaaniadziaania szeregoweszeregowe zzkoniecznocikoniecznoci modyfikacjimodyfikacjimodelowaniamodelowania proceswproceswgospodarczychgospodarczych popo drugimdrugim aanawetnawet trzecimtrzecim etapieetapie..

Restrukturyzacja przedsibiorstwa

Budowa ZSI

Uzyskanie kompletnej infrastruktury informatycznej

Podejcie zalecane -- dopuszczadopuszczasisi rwnolegorwnolego pracpracrestrukturyzacyjnychrestrukturyzacyjnych ii wstpnychwstpnychwdroeniowychwdroeniowych zz moliwocimoliwociiteracyjnegoiteracyjnego uszczegowianiauszczegowianiadziaadziaa wdroeniowychwdroeniowych iiprzygotowywaniaprzygotowywania docelowejdocelowejinfrastrukturyinfrastruktury..

Struktura SIFunkcjonalna (struktura funkcji - jakie funkcje realizuje SI? jaki jest ich podzia i zwizki midzy sob?)Informacyjna (struktura informacji w SI, co jest danymi wejciowymi i wynikowymi SI?), Organizacyjno-przestrzenna (jak system jest podzielony? gdzie realizowane s przestrzennie jego funkcje?)Techniczna (struktura infrastruktury technicznej SI wyrnienie serwerw, procesorw, stacji roboczych, czy, itp.)

Pojcia podstawowe w modelowaniu i analizie systemw informatycznych

Analiza SI proces budowy koncepcji - logicznego model systemu,Modelowanie SI obejmuje proces uszczegawiania modelu logicznego do opracowania oprogramowania systemu,Metodyka to ustandaryzowane dla wybranego obszaru podejcie do rozwizywania problemw. Metodyka abstrahuje od merytorycznego kontekstu danego obszaru, a skupia si na metodach realizacji zada, szczeglnie metodach zarzdzania

Wykad 3 13.III.2014

Metodyka skupia si na metodach

Metody (w tym metody rozwizywania zada) s przedmiotem bada a w wyniku tych bada powstaj uoglnienia i w ten sposb powstaje nowa dziedzina wiedzy, ktrej przedmiotem s owe metody.

Metody Metody --> badanie metod > badanie metod -->wiedza >wiedza -->nauka>nauka

Metodologia

Nauka o metodach bada naukowych, ich skutecznoci i wartoci poznawczej to metodologia.

Klasycznie wyrnia si metodologie w:naukach cisychnaukach przyrodniczychnaukach spoecznych

Metody Metody --> badanie metod > badanie metod --> metodologia> metodologia

Metodyka a metodologia

metodologia skupia si na odpowiedzi na pytanie:

metodyka koncentruje si na poszukiwaniu odpowiedzi na pytanie:

Metodyka dy ku praktyce wykonawczej, a metodologia ku teorii zazwyczaj sprawnego dziaania.

Co naley robi?,

Jak to naley robi?

Metodologia nauk technicznych (tworzenia oprogramowania)

Wiele nauk posiada wasne metodologie lub korzysta z dorobku innych, W naukach technicznych czsto dokonuje si pomiaru za pomoc miernikw z zachowaniem waciwych warunkw otoczenia a uzyskane tak wyniki mog by zbierane i porwnywane z wynikami uzyskanymi przez innych badaczy przy zachowaniu tych samych zmiennych lub nieznacznej ich modyfikacji. Do opracowania stosuje si tu czsto opis matematyczny.

CYKL YCIA SYSTEMU INFORMATYCZNEGO

Co to jest cykl ycia SI (ang. software life cycle) ?

Rozwj oprogramowania jest zoonym procesemrealizowanym etapowo w okrelonym czasie.W celu zapewnienia powtarzalnej jakoci realizowanegoprojektu definiuje si pojcie cyklu yciaoprogramowania dzielc cao przedsiwzicia naszereg tzw. faz ycia oprogramowania.Poszczeglnym stadiom rozwoju aplikacji

przyporzdkowuje si odpowiednie zestawy czynnoci,ktrych celem jest uporzdkowanie przebiegu prac,umoliwienie planowania i zarzdzania dostpnymizasobami.Rodzaj oraz kolejno zdefiniowanych faz skadaj sina tzw. model cyklu ycia oprogramowania.

Cykl ycia SI

Proces zoony z cigu wzajemnie spjnych etapw pozwalajcych na pene i skuteczne stworzenie, a nastpnie uytkowanie systemw informatycznych

Oglny cykl ycia systemu

Analiza Wymaga

Projektowanie

Procesy

Interfejs uytkownika

Dane Wdraanie

EKSPLOATACJA

Planowanie strategiczne

ProjektProjekt - ograniczony w czasie zesp powizanych ze sob dziaa prowadzcych do wytworzenia unikalnego wyrobu lub usugi.Mimo rnic w skali i w istocie wszystkie projekty posiadaj nastpujce elementy: okrelony cel, dat rozpoczcia i zakoczenia, okrelony koszt, absorbuj okrelone zasoby, wykonywane s przez ludzi.

Zakres projektw informatycznych:

tworzenia nowych systemw informatycznych;wdroenia standardowych aplikacji;modyfikacji standardowych systemw.

Cykl projektowy pozwalazdefiniowa czynnoci w procesie budowy systemu,wprowadzi i utrzyma spjno miedzy wieloma projektami w tej samej organizacji,wprowadzi punkty kontrolne w zarzdzaniu projektem na rnych etapach jego rozwoju

Udziaowcy projektu SI

Kluczowymi udziaowcami projektu s:klient - odbiorca wyniku przedsiwzicia,konsument - uytkownik wyniku projektu,waciciel - organizacja realizujca projekt,zarzdzajcy projektem- odpowiedzialny za realizacj celu,uczestnik - czonek zespou realizujcego projekt,sponsor - osoba lub organizacja finansujca projekt lub udostpniajca zasoby,podwykonawcy.

Dziedziny zwizane z procesem projektowania SI:

Zarzdzanie projektami;

Praca grupowa;

Procedury wyboru oprogramowania;

Metody szacowania kosztw oprogramowania;

Wspomaganie podejmowania decyzji;

Analiza systemowa i metodyki projektowania;

Komunikacja interpersonalna.

Szczegowy wykaz faz cyklu ycia systemu informatycznego

faza strategiczna,aza strategiczna,okrelenie wymaga,okrelenie wymaga,analiza analiza modelowanie,modelowanie,projektowanie,projektowanie,implementacja oprogramowania,implementacja oprogramowania,integracja i testowanie SI,integracja i testowanie SI,wdroenie,wdroenie,utrzymanie,utrzymanie,likwidacja.likwidacja.

Okrelenie wymaga Projektowanie Implementacja Testowanie Utrzymanie

Faza strategiczna Analiza Wdroenie

Dokumentacja Likwidacja

W cyklu ycia SI wyrnia si W cyklu ycia SI wyrnia si fazy podstawowe:fazy podstawowe:

Okrelanie wymaga - okrelane s tu cele oraz szczegowe wymagania wobec tworzonego systemu,Projektowanie tu powstaje szczegowy projekt SI speniajcego ustalone wczeniej wymagania,Implementacja/kodowanie oraz testowanie moduw -projekt zostaje zaimplementowany w konkretnym rodowisku programistycznym oraz wykonywane s testy poszczeglnych moduw,testowanie - nastpuje tu integracja poszczeglnych moduw poczona z testowaniem czci i caego SI, Konserwacja - oprogramowanie jest wykorzystywane przez oprogramowanie jest wykorzystywane przez uytkownika, producent dokonuje konserwacji SI, wykonuje si uytkownika, producent dokonuje konserwacji SI, wykonuje si modyfikacje, zmiany i rozszerzania funkcji SI oraz usuwa modyfikacje, zmiany i rozszerzania funkcji SI oraz usuwa ewentualne bdy ewentualne bdy yy

Fazy dodatkowe w cyklu ycia Fazy dodatkowe w cyklu ycia SISI

Strategiczna - wykonywana przed formalnym podjciem decyzji o realizacji przedsiwzicia tu podejmowane s decyzje strategiczne o podejmowanym przedsiwziciu ustala si : zakres, koszt, czasu realizacji itp.Analiza - budowany jest logiczny model systemu,Dokumentacja - wytwarzana jest dokumentacja uytkownika -opracowywanie dokumentacji przebiega rwnolegle z produkcj oprogramowania faza praktycznie rozpoczyna si ju w trakcie okrelania wymaga - sugeruje si nawet, e podrcznik uytkownika dla przyszego systemu jest dobrym dokumentem opisujcym wymagania - ostatnie uaktualnienia w dokumentacji dokonywane s w fazie instalacji SI.Instalacja - nastpuje przekazanie systemu uytkownikowi,Likwidacja - czynnoci zwizane z wycofaniem SI.

Cykl ycia SI

Definiowanie Analiza Projektowanie Implementacja Zainstalowanie, testowanie,

usuwanie bdw Szkolenie i przekazanie

systemu uytkownikowi Utrzymanie i rozwj systemu Re-inynieria systemu / zastpienie systemu innym /

zamknicie systemu

Proces projektowania systemu

Wdroenie systemu

Cykl ycia SI -inaczejAnaliza

Projektowanie

Konstrukcja

Testowanie

Sprawdzenie osigniciacelw

Sprawdzenie zgodnoci ze specyfikacj

WDRAANIEWDRAANIE

Etapy cyklu ycia SI a dokumentacja

1. Okrelenie wymaga2. Projektowanie3. Implementacja4. Testowanie5. Rozwj & pielgnacja

Dokumentacja I

Zrozumienie problemu

Dokumentacja II

MODELE CYKLU YCIA SYSTEMU

INFORMATYCZNEGO

Rodzaje modeli cyklu ycia SI Model kaskadowy (ang. waterfall) Realizacja kierowana dokumentami (ang. document

driving) Prototypowanie (ang. prototyping) Programowanie odkrywcze (ang. exploratory

programming) Realizacja przyrostowa (ang. incremental

development) Monta z gotowych elementw (ang. composition of

re-usable components) Model spiralny (ang. spiral) Elastyczne metody wytwarzania systemw informatycznych

(ewolucyjne metody)

Model kaskadowy

PlanowaniePlanowanie

AnalizaAnaliza

ProjektowanieProjektowanie

ImplementacjaImplementacja

TestowanieTestowanie

KonserwacjaKonserwacja

Model kaskadowy (ang. waterfall) jest jednym z najbardziej rozpowszechnionych modeli cyklu ycia oprogramowania. Nazwa model kaskadowy zostaa po raz pierwszy uyta w artykule Winstona W. Roycea pt.: "Managing the Development of Large Software Systems.

Model kaskadowy jest uznawany czsto za doprzestarzay i mao elastyczny gdy:

nie mona przej do kolejnej fazy przed zakoczeniem poprzedniej (sztywno narzucony iteracyjny proces),powtarzanie dowolnej iteracji (fazy) czsto okazuje si kosztowne,cisa kolejno postpowania utrudnia komunikacj z klientem.

Programowanie odkrywcze

Sporzd Sporzd ogln ogln

specyfikacjspecyfikacj

Zbuduj Zbuduj systemsystem

Skorzystaj z Skorzystaj z systemusystemu

Dostarcz system

klientowi

System spenia System spenia wymagania?wymagania?

NieNieTakTak

Problemy wynikajce podczas programowania odkrywczego Problemy wynikajce podczas programowania odkrywczego (ang. (ang. exploratoryexploratoryprogrammingprogramming) ) to midzy innymi:to midzy innymi:

brak prawdziwej i penej specyfikacji co uniemoliwia kompletn weryfikacj systemu, brak prawdziwej i penej specyfikacji co uniemoliwia kompletn weryfikacj systemu,

bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,bardzo kosztowna i trudna konserwacja tak zbudowanego systemu,

niespjna i do chaotyczna struktura systemuniespjna i do chaotyczna struktura systemu

Model spiralny

Definiowanie

Analiza

Projektowanie

Implementacja

Model spiralny

Model spiralny zostazaproponowany w 1986 roku przez Barryego 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.

Procedura ewolucyjna (strukturalna)

System dzielimy na elementarne czci, a dopiero na kocu dziaa projektowych przystpujemy do integracji caego systemu i wykonania testw.Jej cech charakterystyczn jest projektowanie nadne, tzn. e cay czas jestemy nastawieni na zmieniajcy si cel. Poniewa wraz z upywem czasu cel, ktry zosta okrelony wczeniej ulega zmianie, musimy przez cay czas analizowa i kontrolowa proces projektowania. W ten sposb staramy si zminimalizowa straty, spowodowane wadliwym dziaaniem systemu. Kosztem etapowej modyfikacji systemu, uzyskujemy efekt aktualnoci systemu.

Procedura ewolucyjna

Procedura przyrostowa (strukturalna)Pozwala projektowa system etapami w przypadku, gdy nie ma innych rodkw, aby projektowa od razu cay system.Zesp projektujcy, przy dobrej organizacji pracy, jest stale, rwnomiernie zajty realizacj projektu. Prace nad projektem odbywaj si metod cig, bez zbdnej akcyjnoci.Organizacj prac nad SI mona porwna do tworzenia osiedla domw gdzie poszczeglne brygady pracuj przy budowie jednego domu, a nastpnie przenosz si na budow nastpnego domu. Na ich miejsce przychodzi nowa brygada, ktra kontynuuje prac pierwszej brygady.Klamr spinajc poszczeglne etapy projektowania s pierwsze i ostatnie etapy (Wymagania, analiza i koncepcja, testowanie, instalacja i eksploatacja) przeprowadza si dla caego SI. W tych ostatnich - dba si o spjno caego SI.

Procedura przyrostowa

WAGA ETAPW CYKLU YCIA SI

Koszty naprawy bdw a etapy cyklu ycia SI

Okrelanie wymaga

Projektowanie

Implementacja

Testowanie

Pielgnacja

56%56%26 %

7%

Koszty usuwania bdw na etapie Pielgnacji oprogramowania s 200 razy wiksze ni na etapie Okrelania wymaga na

Etap

Ilo bdw

0.1

0.5

1

5

20

Od techno- do antypo-centry-cyzmu w projektowaniu SI

Klasyczne podejcie do projektowania systemw informatycznych dla zarzdzania byo techno-centryczne. Opierao si ono na zaoeniu, e trzeba woy wiele wysiku w tworzenie i optymalizowanie coraz doskonalszych systemw komputerowych. Natomiast uytkownicy systemw mieli si do nich dostosowa.Takie podejcie byo iluzj, poniewa celem systemu nie jest przetwarzanie danych tylko wiedza, ktra pozwoli nam podejmowa rozmaite decyzje. Natomiast ta wiedza rodzi si w umyle czowieka. Dlatego te czowiek jest punktem wyjcia w projektowaniu nowoczesnych skomputeryzowanych systemw zarzdzania.

Od techno- do antypo-centry-cyzmu w projektowaniu SI

Nowe podejcie to antypo-centryzm - nie mona doskonali systemw zarzdzania firm przy zaoeniu ,e czowiek jest dodatkiem. Komputer nie zastpuje ludzi, ale wspomaga twrcze mylenie z czego mog si zrodzi nowe koncepcje, nowe idee. I dopiero to wszystko razem moe zapewni sukces biznesowy. Przykadem tego kierunku jest podejcie spoeczne (ang. soft approaches)

Dziedzina Dziedzina przedmiotowa (DP)przedmiotowa (DP)

PROCES TWORZENIA PROCES TWORZENIA SYSTEMU SYSTEMU

INFORMATYCZNEGOINFORMATYCZNEGOZesp Zesp

projektujcyprojektujcy

SISI

Wyniki analizWyniki analiz Cele problemy, potrzeby Cele problemy, potrzeby informatyczneinformatyczne

KryteriaKryteria

ocenyoceny

Korekty i modyfikacjeKorekty i modyfikacje

Prezentacjai eksperymentalna

eksploatacja

tworzenietworzenie

kierowaniekierowanie

ModeleModele

DPDP

Metody i Metody i technikitechniki

Narzdzia Narzdzia komputerowegkomputerowego wspomaganiao wspomagania

Reguy Reguy modelowaniamodelowania

parametryparametry pakietypakiety

ZadaniaZadania

wymaganiawymagania

FazyFazy

dokumentacjadokumentacja

Pojcia Pojcia abstrakcyjneabstrakcyjne

rodowisko metodyki tworzenia SI

Oglne wymagania do metodyki tworzenia SI

metodyka powinna obj cay cykl ycia systemu informatycznego,metodyka powinna obejmowa rnorodne, dostosowane do specyfiki podejcia, metody, techniki i narzdzia komputerowe wspomagajce proces tworzenia systemu i analiz,metodyka powinna uatwia porozumiewanie si pomidzy rnymi grupami zawodowymi tworzcymi SI,metodyka powinna by stosunkowo atwa w uytkowaniu, powinna mc ewoluowa i podlega modyfikacjom

Model tworzenia systemu informacyjnego

Realizacja systemu

Metodyka projektowania systemu informatycznego

Stosowana metodyka projektowania systemu informacyjnego zaley od wielu czynnikw, takich jak:

infrastruktura zarzdzania, dysponowane zasoby, kwalifikacje kadry uytkownika i projektantw, organizacja i specyfika jej otoczenia.

Metodyka projektowania systemu informatycznego

Podejcia do metodyki projektowania uwzgldniajce aspekt czasu:

projektowanie diagnostyczne, w ktrym za punkt wyjcia przyjmuje si obecny stan organizacji, a projektant pragnie j usprawni;

projektowanie prognostyczne, gdzie za punkt wyjcia bierzemy nasz wizj organizacji w przyszoci, a nie interesuje nas stan obecny.

Podejcie diagnostyczne

Podejcie prognostyczne

czasStan obecny

Podejcie diagnostyczne

Podejcie diagnostyczne, najbardziej popularne, nazywane jest czste podejciem tradycyjnym. W podejciu tym projektuje si system lepszy od istniejcego.

W podejciu diagnostycznym znamy obiekt i jego niedomagania oraz istniejce moliwoci poprawy. Naszym zadaniem jest poprawa tego stanu.

Formuujemy kryterium oceniajce oraz istniejce warunki ograniczajce. Celem jest zaprojektowanie systemu lepszego ni obecnie funkcjonujcy.

Podejcie prognostyczne

W podejciu prognostycznym w zasadzie nie interesuje nas obecna sytuacja.

Pierwszym zadaniem jest okrelenie horyzontu czasu, a cilej, punktu w przyszoci na jaki projektujemy system.

Przyjmujemy zasad, e nasz system powinien by przez dugi czas nowoczesny. Oczywicie decydenci pragn, aby ich system by jak najduej nowoczesny. Jednak, aby ten postulat zrealizowa, naley zdawa sobie spraw z faktu, e horyzont czasu jest duszy, tym nasza wiedza o przyszych warunkach funkcjonowania obiektu jest mniejsza. I nie jest to tylko zwizane z naszymi pragnieniami, ale w przewaajcej mierze z tym, e projektujc system metod prognostyczn zwiksza si ryzyko podjcia nietrafionych decyzji.

Dlatego te decyzja przyjcia diagnostycznego czy prognostycznego podejcia do projektowania jest decyzj strategiczn.

FAZA STRATEGICZNA

Faza strategiczna (studium osigalnoci)

Okrelenie wymaga Projektowanie Implementacja Testowanie Konserwacja

Faza strategiczna Analiza InstalacjaDokumentacja

strategy phase, feasibility study

Faza strategiczna jest wykonywana zanim podejmowana jest decyzja o realizacji przedsiwzicia.

Nazywana take strategicznym planem rozwoju informatyzacji(SPRI) lub studium osigalnoci.

Czynnoci w fazie strategicznej

Dokonanie serii rozmw (wywiadw) z przedstawicielami klienta

Okrelenie celw przedsiwzicia z punktu widzenia klienta

Okrelenie zakresu oraz kontekstu przedsiwzicia

Oglne okrelenie wymaga, wykonanie zgrubnej analizy i projektu systemu

Propozycja kilku moliwych rozwiza (sposobw realizacji systemu)

Oszacowanie kosztw oprogramowania

Analiza rozwiza

Prezentacja wynikw fazy strategicznej przedstawicielom klienta oraz korekta wynikw

Okrelenie wstpnego harmonogramu przedsiwzicia oraz struktury zespou realizatorw

Okrelenie standardw, zgodnie z ktrymi realizowane bdzie przedsiwzicie

Faza strategiczna - wsppraca z klientem

Wykonawca

Zleceniodawca Przyszy uytkownik

Po stronie klienta warto wyrni zleceniodawc i przyszych uytkownikw.Stara si uwzgldni kryteria obydwu stron, ale naley pamita, e system bdzie gwnie oceniany przez przyszych uytkownikw.

Wanym elementem fazy strategicznej jest jasne okrelenie celwprzedsiwzicia z punktu widzenia klienta. Nie zawsze s one oczywiste, co czsto powoduje nieporozumienia pomidzy klientem i wykonawc.

Rwnie wane jest okrelenie ogranicze klienta (np. finansowych, infrastruktury, zasobw ludzkich, czasu wdroenia, itd.)

Klient

Przykad: system harmonogramowania zlece

Przedsibiorstwo farmaceutyczne zlecio wykonanie analizy krytycznych procesw funkcjonowania jednego z wydziaw. Jednym z nich jest harmonogramowanie zlece, ktre wydzia otrzymuje z dziau marketingu. Zlecenie oznacza wyprodukowanie pewnej iloci konkretnego produktu, przy czym moliwe s dodatkowe wymagania, np. ograniczenie terminu wykonania.

Cele przedsiwzicia z punktu widzenia klienta: zwikszenie wydajnoci pracy wydziau poprzez szybsz i efektywniejsz

realizacj zlece, zmniejszenie opnie w realizowaniu zlece uwzgldnienie wszelkich ogranicze, zapewniajce praktyczn wykonalno

proponowanych harmonogramw zapewnienie moliwoci rcznego modyfikowania harmonogramu opracowanie harmonogramu w formie atwej do wykorzystania przez kadr

kierownicz wydziau oraz automatyzacja przygotowania zamwie dla magazynu na pprodukty.

Zakres i kontekst przedsiwzicia

System harmonogramowania zlece

Zakresem przedsiwzicia jest funkcjonowanie komrki wydziau obejmujcego przygotowanie harmonogramu wykonywania zlece. Nie jest okrelone, czy harmonogramy maj by drukowane automatycznie, czy system ma tylko dostarcza odpowiednich informacji. Systemami zewntrznymi s: system komputerowy dziau marketingu, osoba definiujca technologiczne moliwoci wydziau, kadra kierownicza.

Zakres przedsiwzicia: okrelenie fragmentu procesw informacyjnych zachodzcych w organizacji, ktre bd objte przedsiwziciem. Na tym etapie moe nie by jasne, ktre funkcje bd wykonywane przez oprogramowanie, a ktre przez personel, inne systemy lub standardowe wyposaenie sprztu.

Kontekst systemu: systemy, organizacje, uytkownicy zewntrzni, z ktrymi tworzony system ma wsppracowa.

Decyzje strategiczneWybr modelu, zgodnie z ktrym bdzie realizowane przedsiwzicieWybr technik stosowanych w fazach analizy i projektowaniaWybr rodowiska (rodowisk) implementacjiWybr narzdzia CASE Okrelenie stopnia wykorzystania gotowych komponentw Podjcie decyzji o wsppracy z innymi producentami lub zatrudnieniu ekspertw

OgraniczeniaMaksymalne nakady, jakie mona ponie na realizacj przedsiwzicia Dostpny personel Dostpne narzdzia Ograniczenia czasowe

Po prezentacji wynikw dla klienta kocowym wynikiem moe by przyjcie lub odrzucenie oferty twrcy oprogramowania. Faza strategiczna jest nieodczn czci cyklu produkcji oprogramowania, wobec czego nie powinna by wykonywana na koszt i ryzyko producenta oprogramowania

Harmonogram przedsiwziciaUstalenie planu czasowego dla poszczeglnych faz i zada.

Diagram Gantta

GrudNazwa zadania

Wstpne zbieranie wymaga

Budowa prototypu

Ocena prototypu

Opracowanie wymaga

Analiza

Projekt dziedziny problemu

Projekt interfejsu uytkown.

Projekt bazy danych

ListoPadWrzeSierpLipCzerStycz Luty Marz Kwie Maj

Ocena rozwiza

W fazie strategicznej czsto rozwaa si kilka rozwiza, z powodw wieloci celw przedsiwzicia (czyli kryteriw oceny) lub niepewnoci (niemoliwoci precyzyjnej oceny spodziewanych rezultatw).

Czste kryteria oceny: koszt czas realizacji niezawodno moliwo ponownego uycia przenono na inne platformy wydajno (szybko)

Prezentacja i porwnanie poszczeglnych rozwizaw postaci tabelarycznej

RozwizanieKoszt (tys. z)Czas (miesice)Niezawodno (bdy/tydzie)Ponowne uycie (%)Przenono (%)Wydajno(transakcje/sek)

A120

335

4090

0.35

B8030

94075

0.75

C175

36133030

1

Oszacowanie wartoci podanych w tabeli moe by trudnym problemem.

Niepewno i ryzyko

Niepewno jest czynnikiem utrudniajcym wybr najlepszego rozwizania.

Optymistyczne i pesymistyczne oszacowania:

RozwizaniePesymistyczny koszt [tys z]Optymistyczny koszt [tys z]

A100

40

B8065

Mona wybra jedno z dwch rozwiza, A lub B, w zalenoci od tego, czy przyjmujemy optymistyczny, czy te pesymistyczny punkt widzenia.

Prawdopodobiestwo subiektywne

RozwizaniePrawdopodobiestwo pesymistycznego rozwizaniaPrawdopodobiestwo optymistycznego rozwizania

A0.50.5

B0.20.8

Poprzez pomnoenie kosztw przez prawdopodobiestwa uzyskujemy spodziewany koszt: A: 100 * 0.5 + 40 * 0.5 = 50 + 20 = 70B: 80 * 0.2 + 65 * 0.8 = 16 + 52 = 68 : rozwizanie B jest lepszeZe wzgldu na subiektywno oszacowa naley jednak rozway wiele wariantw.

Drzewa ryzykaWierzchoki drzewa odpowiadaj sytuacjom, w ktrych mog zaj pewne zdarzenia.Krawdzie oznaczaj przejcia do nowych sytuacji.Krawdziom s przypisane prawdopodobiestwa.Kady scenariusz zdarze (li w drzewie) jest zwizany z kosztem.

PrzykadFirma chce przystpi do przetargu. Przygotowanie oferty przetargowej jest kosztowne. Firma moe przetarg wygra lub przegra. Zatrudnienie dodatkowego eksperta zwiksza szans firmy. Co robi?

Zatrudnienieeksperta

Przetarg Przetarg

Zatrudnionoeksperta0.8

Nie znalezionoeksperta

0.2

Sukces0.9

Sukces0.5

Poraka0.1

Poraka0.5

Zysk +45 - 20 +55 -10

Oczekiwany zysk 45*0.8*0.9 + (-20)*0.8*0.1 + 55*0.2*0.5 + (-10)*0.2*0.5 = 35.3

Szacowanie kosztu oprogramowania

Szacowanie kosztw przeprowadza si dla kadego z alternatywnych rozwiza.

Na koszt oprogramowania skadaj si nastpujce gwne czynniki:

koszt sprztu bdcego czci tworzonego systemu koszt wyjazdw i szkole koszt zakupu narzdzi nakad pracy

Trzy pierwsze czynniki s do atwe do oszacowania.Oszacowanie kosztw oprogramowania jest praktycznie utosamiane z oszacowaniem nakadu pracy.

Techniki oszacowania nakadw pracy

Modele algorytmiczne. Wymagaj opisu przedsiwzicia przez wiele atrybutw liczbowych i/lub opisowych. Odpowiedni algorytm lub formua matematyczna daje wynik.

Ocena przez eksperta. Dowiadczone osoby z du precyzj potrafi oszacowa koszt realizacji nowego systemu.

Ocena przez analogi (historyczna). Wymaga dostpu do informacji o poprzednio realizowanych przedsiwziciach. Metoda podlega na wyszukaniu przedsiwzicia o najbardziej zblionych charakterystykach do aktualnie rozwaanego i znanym koszcie i nastpnie, oszacowanie ewentualnych rnic.

Wycena dla wygranej. Koszt oprogramowania jest oszacowany na podstawie kosztu oczekiwanego przez klienta i na podstawie kosztw podawanych przez konkurencj.

Szacowanie wstpujce. Przedsiwzicie dzieli si na mniejsze zadania, nastpnie sumuje si koszt poszczeglnych zada.

Algorytmiczne modele szacowania kosztw

Historycznie, podstaw oszacowania jest rozmiar systemu liczony w liniach kodurdowego. Metody takie s niedokadne, zawodne, sprzyjajce patologiom, np.sztucznemu pomnaaniu iloci linii, ignorowaniu komentarzy, itp.Obecnie stosuje si wiele miar o lepszych charakterystykach (z ktrych bdomwione punkty funkcyjne). Miary te, jakkolwiek niedokadne i oparte naszacunkach, s jednak konieczne. Niemoliwe jest jakiekolwiek planowania bezoszacowania kosztw. Miary dotycz take innych cech projektu i oprogramowania,np. czasu wykonania, jakoci, niezawodnoci, itd.Jest bardzo istotne uwolnienie si od religijnego stosunku do miar, tj. traktowanie ichjako obiektywnych wartoci policzonych przez komputer. Podstaw wszystkichmiar s szacunki, ktre mog by obarczone znacznym bdem, nierzadko o rzdwielkoci. Miary naley traktowa jako latarni morsk we mgle - moe ona nasnaprowadzi na dobry kierunek, moe ostrzec przed niebezpieczestwem.Obowizuje zasada patrzenia na ten sam problem z wielu punktw widzenia (wielernych miar) i zdrowy rozsdek.

Metoda szacowania kosztw COCOMO

COnstructive COst MOdel

COCOMO jest oparte na kilku formuach pozwalajcych oszacowa cakowity koszt przedsiwzicia na podstawie oszacowanej liczby linii kodu. Jest to gwna sabo tej metody, gdy:

liczba ta staje si przewidywalna dopiero wtedy, gdy koczy si faza projektowania architektury systemu; jest to za pno;

pojcie linii kodu zaley od jzyka programowania i przyjtych konwencji;

pojcie linii kodu nie ma zastosowania do nowoczesnych technik programistycznych, np. programowania wizyjnego.

COCOMO oferuje kilka metod okrelanych jako podstawowa, porednia i detaliczna.

Metoda podstawowa: prosta formua dla oceny osobo-miesicy oraz czasu potrzebnego na cao projektu.

Metoda porednia: modyfikuje wyniki osignite przez metod podstawow poprzez odpowiednie czynniki, ktre zale od aspektw zoonoci.

Metoda detaliczna: bardziej skomplikowana, ale jak si okazao, nie dostarcza lepszych wynikw ni metoda porednia.

Metoda punktw funkcyjnych

Function Point Analysis, FPA

Metoda punktw funkcyjnych oszacowuje koszt projektu na podstawie funkcji uytkowych, ktre system ma realizowa. Std wynika, ze metoda ta moe by stosowana dopiero wtedy, gdy funkcje te s z grubsza znane.

Metoda jest oparta na zliczaniu iloci wej i wyj systemu, miejsc przechowywania danych i innych kryteriw. Te dane s nastpnie mnoone przez zadane z gry wagi i sumowane. Rezultatem jest liczba punktw funkcyjnych.

Punkty funkcyjne mog by nastpnie modyfikowane zalenie od dodatkowych czynnikw zoonoci oprogramowania.

Istniej przeliczniki punktw funkcyjnych na liczb linii kodu, co moe by podstaw dla metody COCOMO.

Metoda jest szeroko stosowana i posiada stosunkowo mao wad. Niemniej, istnieje wiele innych, mniej popularnych metod, posiadajcych swoich zwolennikw.

Metoda DelphiMetoda Delphi zakada uycie kilku niezalenych ekspertw, ktrzy nie mog si ze sob w tej sprawie komunikowa i naradza. Kady z nich szacuje koszty i nakady na podstawie wasnych dowiadcze i metod. Eksperci s anonimowi. Kady z nich uzasadnia przedstawione wyniki.

Koordynator metody zbiera wyniki od ekspertw. Jeeli znacznie si rni, wwczas tworzy pewne sumaryczne zestawienie (np. redni) i wysya do ekspertw dla ponownego oszacowania. Cykl jest powtarzany a do uzyskania pewnej zgody pomidzy ekspertami.

Inne metody

Metoda analizy podziau aktywnoci (activity distribution analysis): Projekt dzieli si na aktywnoci, ktre s znane z poprzednich projektw.Nastpnie dla kadej z planowanych aktywno ustala si, na ile bdzie ona bardziej (lub mniej) pracochonna od aktywnoci ju wykonanej, ktrej koszt/nakad jest znany. Daje to szacunek dla kadej planowanej aktywnoci. Szacunki sumuje si dla uzyskania caociowego oszacowania.

Metody oszacowania pracochonnoci testowania systemuMetody oszacowania pracochonnoci dokumentacjiMetody oszacowania obcienia sieci....

Podsumowanie: kluczowe czynniki sukcesu

Szybko pracy. Szczeglnie w przypadku firm realizujcych oprogramowanie na zamwienie, opnienia w przeprowadzeniu fazy strategicznej mog zaprzepaci szans na wygranie przetargu lub na nastpne zamwienie. Faza ta wymaga wic stosunkowo nieduej liczby osb, ktre potrafi wykona prac w krtkim czasie.

Zaangaowanie kluczowych osb ze strony klienta. Brak akceptacji dla sposobu realizacji przedsiwzicia ze strony kluczowych osb po stronie klienta moe uniemoliwi jego przyszy sukces.

Uchwycenie (oglne) caoci systemu. Podstawowym bdem popenianym w fazie strategicznej jest zbytnie przywizanie i koncentracja na pewnych fragmentach systemu. Niemoliwe jest w tej sytuacji oszacowanie kosztw wykonania caoci. atwo jest te przeoczy szczeglnie trudne fragmenty systemu.

Podstawowe rezultaty fazy strategicznej

Udostpniamy klientowi raport, ktry obejmuje:

definicj celw przedsiwzicia opis zakresu przedsiwzicia opis systemw zewntrznych, z ktrymi system bdzie

wsppracowa oglny opis wymaga oglny model systemu opis proponowanego rozwizania oszacowanie kosztw wstpny harmonogram prac

Podstawowe rezultaty fazy strategicznej cd..

Raport oceny rozwiza, zawierajcy informacj o rozwaanych rozwizaniach oraz przyczynach wyboru jednego z nich.

Opis wymaganych zasobw - pracownicy, oprogramowanie, sprzt, lokale, ...

Definicje standardw.

Harmonogram fazy analizy

FAZA OKRELANIA WYMAGA DLA

SYSTEMU INFORMATYCZNEGO

Okrelenie wymaga


Faza strategiczna Analiza Instalacja

Dokumentacja

Celem fazy okrelenia wymaga jest ustalenie wymaga klienta wobec tworzonego systemu. Dokonywana jest zamiana celw klienta na konkretne wymagania zapewniajce osignicie tych celw.

Klient rzadko wie, jakie wymagania zapewni osigniecie jego celw.

Ta faza nie jest wic prostym zbieraniem wymaga, lecz procesem, w ktrym klient wsplnie z przedstawicielem producenta konstruuje zbir wymaga zgodnie z postawionymi celami.

W przypadku systemu na zamwienie analitycy maj bezporedni kontakt z przedstawicielami klienta. Faza ta wymaga duego zaangaowania ze strony klienta, ze strony przyszych uytkownikw systemu i ekspertw w dziedzinie.

Trudno okrelenia wymagaKlient z reguy nie wie dokadnie w jaki sposb osign zaoone cele. Cele klienta mog by osignite na wiele sposobw.

Due systemy s wykorzystywane przez wielu uytkownikw. Ich cele s czsto sprzeczne. Rni uytkownicy mog posugiwa si inn terminologi mwic o tych samych problemach.

Zleceniodawcy i uytkownicy to czsto inne osoby. Gos zleceniodawcw moe by w tej fazie decydujcy, chocia nie zawsze potrafi oni waciwie przewidzie potrzeby przyszych uytkownikw.

Poziomy oglnoci opisu wymaga

Definicja wymaga, to oglny opis w jzyku naturalnym. Opis taki jest rezultatem wstpnych rozmw z klientem.

Specyfikacja wymaga, to czciowo ustrukturalizowany zapis wykorzystujcy zarwno jzyk naturalny, jak i proste, czciowo przynajmniej sformalizowane notacje.

Specyfikacja oprogramowania, to formalny opis wymaga.

Formalna specyfikacja oznacza bardzo dokadne zdekomponowanie wymaga (najlepiej w pewnym formularzu) na krtkie punkty, ktrych interpretacja nie powinna nastrcza trudnoci lub prowadzi do niejednoznacznoci. Formalna specyfikacja powinna stanowi podstaw dla fazy testowania.

Jako opisu wymagaDobry opis wymaga powinien:

By kompletny oraz niesprzeczny.

Opisywa zewntrzne zachowanie si systemu a nie sposb jego realizacji.

Obejmowa ograniczenia przy jakich musi pracowa system.

By atwy w modyfikacji.

Bra pod uwag przysze moliwe zmiany wymaga wobec systemu.

Opisywa zachowanie systemu w niepodanych lub skrajnych sytuacjach.

Wykad 5 - 27.03.2014 r.

Cd fazy okrelania wymaga do SI


Faza strategiczna Analiza Instalacja

Dokumentacja

Zalecenia dla fazy definicji wymaga

Wymagania uytkownikw powinny by wyjaniane poprzez krytyk iporwnania z istniejcym oprogramowaniem i prototypami.

Powinien by uzyskany stan porozumienia pomidzy projektantami iuytkownikami dotyczcy projektowanego systemu.

Wiedza i dowiadczenia potencjalnej organizacji podejmujcej si rozwojusystemu powinny wspomc studia nad osigalnoci systemu.

W wielu przypadkach duym wspomaganiem jest budowa prototypw.

Wymagania uytkownikw powinny by: jasne, jednoznaczne, weryfikowalne, kompletne, dokadne, realistyczne, osigalne.

Metody rozpoznania wymagaWywiady i przegldy. Wywiady powinny by przygotowane (pytania) i podzielone na odrbne zagadnienia. Podzia powinien przykrywa cao tematu i powinny by przeprowadzone na reprezentatywnej grupie uytkownikw. Wywiady powinny doprowadzi do szerokiej zgody i akceptacji projektu.

Studia na istniejcym oprogramowaniem. Do czsto nowe oprogramowanie zastpuje stare. Studia powinny ustali wszystkie dobre i ze strony starego oprogramowania.

Studia wymaga systemowych. Dotyczy sytuacji, kiedy nowy system ma by czci wikszego systemu.

Studia osigalnoci. Okrelenie realistycznych celw systemu i metod ich osignicia.

Prototypowanie. Zbudowanie prototypu systemu dziaajcego w zmniejszonej skali, z uproszczonymi interfejsami.

Rodzaje wymaga do SI

Wymagania funkcjonalne

Wymagania niefunkcjonalne

Wymagania funkcjonalneOpisuj funkcje (czynnoci, operacje) wykonywane przez system.Funkcje te mog by rwnie wykonywane przy uyciu systemw zewntrznych.Mog by wyspecyfikowane w jzyku naturalnym lub w pewnej notacji.

Jzyk naturalny jest najczciej stosowanym sposobem opisu wymaga.Ma on jednak wady:

Niejednoznaczno jzyka naturalnego, ktra utrudnia precyzyjny opis wymaga. Moe take prowadzi do niejednoznacznoci w interpretacji tego samego tekstu przez rne osoby.

Elastyczno jzyka naturalnego, ktra pozwala wyrazi te same treci na wiele sposobw. Utrudnia to wykrycie powizanych wymaga i moe prowadzi do trudnoci w wykryciu sprzecznoci.

Uwaa si, e dobrym sposobem specyfikacji wymaga funkcjonalnych s diagramy przypadkw uycia.

Inne metody specyfikacji wymagaFormalizm matematyczny. Stosuje si rzadko, dla dobrze zdefiniowanychproblemw raczej o maej skali.

Jzyk naturalny strukturalny. Jzyk naturalny z ograniczonym sownictwemi skadni. Poszczeglne tematy i zagadnienia wyspecyfikowane w punktach ipodpunktach.

Tablice, formularze. Wyspecyfikowanie wymaga w postaci (zwykledwuwymiarowych) tablic, kojarzcych rne aspekty (np. tablica ustalajcazaleno pomidzy typem uytkownika i rodzajem usugi).

Diagramy blokowe: tradycyjna forma graficzna pokazujca wymagany cyklprzetwarzania.

Diagramy kontekstowe: ukazuj system w postaci jednego bloku oraz jegopowizania z otoczeniem, wejciem i wyjciem.

Formularz wymaga funkcjonalnychW formularzach zapis jest podzielony na konkretne pola, co pozwala na atwe stwierdzenie kompletnoci opisu oraz na jednoznaczn interpretacj.

Nazwa funkcjiOpis

Dane wejciowe

rdo danychwejciowychWynikWarunekwstpny

WarunekkocowyEfekty ubocznePowd

Edycja dochodw pracownikaFunkcja pozwala edytowa czne dochody podatnika uzyskane w danym roku.

Informacje o dochodach pracownikw uzyskane uzyskanych z rnych rde: kwoty przychodw, koszty uzyskania przychodw oraz zapaconych zaliczek na poczet podatku dochodowego. Informacje o dokumentach opisujcych dochody z poszczeglnych rde.Dokumenty oraz informacje dostarczone przez podatnika.

Dane wpisywane przez pracownika firmy podatkowej.Kwota dochodu = kwota przychodu - kwota kosztw (zarwno dla konkretnych dochodw, jak i dla cznych dochodw podatnika). czne kwoty przychodw, kosztw uzyskania dochodw oraz zapaconych zaliczek s sumami tych kwot dla dochodw z poszczeglnych rde.Jak wyej.

Uaktualnienie podstawy opodatkowania.Funkcja pomaga przypieszy obsug klientw oraz zmniejszy ryzyko popenienia bdw.

Przykad jednej zapenionej tabeli wg przyjtego formularza:

Porzdkowanie wymagaHierarchia wymaga funkcjonalnych:Z reguy funkcje mona rozbi na podfunkcje.

Format tekstowy:

Funkcja nadrzdna f1funkcja f1.1funkcja f1.2funkcja f1.3

funkcja f1.3.1funkcja f1.3.2funkcja f1.3.3

funkcja f1.4funkcja f1.4.1funkcja f1.4.2funkcja f1.4.3

Notacje graficzne:

funkcja f1

funkcja f1.4.3

funkcja f1.4.2

funkcja f1.4.1

funkcja f1.4

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3

funkcja f1.1

funkcja f1.2

funkcja f1.3.1

funkcja f1

funkcja f1.3funkcja f1.1 funkcja f1.2

funkcja f1.3.2

funkcja f1.3.3

funkcja f1.3.1

Na kadym poziomie ten sampoziom szczegowoci.

Kolejno funkcji nie ma znaczenia.

Niektre funkcje mog by wykonywane wielokrotnie.

Wyszczeglnia tylko funkcje widoczne dla uytkownikw.

Przykad: Funkcje systemu harmonogramowania zlece

Zarzdzanie zleceniami (oglna funkcja systemu)

Ewidencja zlece Edycja technologicznego opisu wydziau Harmonogramowanie zlece

Wczytywanie informacji o zleceniach

Wydruk informacji o zleceniach

Wywietlanie informacji o zleceniach

Edycja opisu maszyn

Sprawdzanie kompletnoci opisu

Wydruk informacji technologicznych

Edycja opisu operacji

Edycja opisu wyrobw

Ustalanie harmonogramu

Edycja harmonogramu

Graficzna prezentacja harmonogramu

Wydruk harmonogramu

Przygotowanie kart zadaPrzygotowanie zamwie na pprodukty

Wymagania niefunkcjonalneOpisuj ograniczenia, przy ktrych system ma realizowa swoje funkcje.

Wymagania dotyczce produktu.

Np. musi istnie moliwo operowania z systemem wycznie za pomoc klawiatury.

Wymagania dotyczce procesu.

Np. proces realizacji harmonogramowania zlece musi by zgodny ze standardem opisanym w dokumencie XXXA/96.

Wymagania zewntrzne.

Np. system harmonogramowania musi wsppracowa z baz danych systemu komputerowego dziau marketingu opisan w dokumencie YYYB/95. Niedopuszczalne s jakiekolwiek zmiany w strukturze tej bazy.

Weryfikacja wymaga niefunkcjonalnych

CechaWydajno

Rozmiar

atwouytkowaniaNiezawodno

Przenaszalno

Weryfikowalne miaryLiczba transakcji obsuonych w cigu sekundyCzas odpowiedziSzybko odwieania ekranuWymagana pami RAMWymagana pami dyskowaCzas niezbdny dla przeszkolenia uytkownikwLiczba stron dokumentacjiPrawdopodobiestwo bdu podczas realizacji transakcjiredni czas pomidzy bdnymi wykonaniamiDostpno (procent czasu w ktrym system jest dostpny)Czas restartu po awarii systemuPrawdopodobiestwo zniszczenia danych w przypadku awariiProcent kodu zalenego od platformy docelowejLiczba platform docelowychKoszt przeniesienia na now platform

Wymagania niefunkcjonalne powinny by weryfikowalne, tj. powinna istnie moliwo sprawdzenia czy system je rzeczywicie spenia. Np. wymaganie system ma by atwy w obsudze nie jest weryfikowalne.

Istotne czynniki definiowania wymaga niefunkcjonalnych

Moliwoci systemu: Zestaw funkcji, ktre ma wykonywa system, uporzdkowany hierarchicznie.

Objto: Ilu uytkownikw bdzie pracowa jednoczenie? Ile terminali ma by podczone do systemu? Ile czujnikw bdzie kontrolowanych jednoczenie? Ile danych bdzie przechowywane?

Szybko: Jak dugo moe trwa operacja lub sekwencja operacji? Liczba operacji na jednostk czasu. redni czas niezbdny dla jednej operacji.

Dokadno: Okrelenie stopnia precyzji pomiarw lub przetwarzania. Okrelenie wymaganej dokadnoci wynikw. Zastpienie wynikw ilociowych jakociowymi lub odwrotnie.

Ograniczenia: ograniczenia na interfejsy, jako, skal czasow, sprzt, oprogramowanie, skalowalno, itd.


Interfejsy komunikacyjne: sie, protokoy, wydajno sieci, poziom abstrakcji protokow komunikacyjnych, itd.

Interfejsy sprztowe: specyfikacja wszystkich elementw sprztowych, ktre bd skaday si na system, fizyczne ograniczenia (rozmiar, waga), wydajno (szybko, RAM, dysk, inne pamici), wymagania co do powierzchni lokalowych, wilgotnoci, temperatury i cinienia, itd.

Interfejsy oprogramowania: Okrelenie zgodnoci z innym oprogramowaniem, okrelenie systemw operacyjnych, jzykw programowania, kompilatorw, edytorw, systemw zarzdzania baz danych, itd.

Interakcja czowiek-maszyna: Wszystkie aspekty interfejsu uytkownika, rodzaj jzyka interakcji, rodzaj sprztu (monitor, mysz, klawiatura), okrelenie formatw (ukadu raportw i ich zawartoci), okrelenie komunikatw dla uytkownikw (jzyk, forma), pomocy, komunikatw o bdach, itd.


Adaptowalno: Okrelenie w jaki sposb bdzie organizowana reakcja na zmiany wymaga: dodanie nowej komendy, dodanie nowego okna interakcji, itd.

Bezpieczestwo: zaoenia co do poufnoci, prywatnoci, integralnoci, odpornoci na hakerw, wirusy, wandalizm, sabota, itd.

Odporno na awarie: konsekwencje bdw w oprogramowaniu, przerwy w zasilaniu, kopii zabezpieczajcych, czstotliwoci skadowania, dziennika zmian, itd.

Standardy: Okrelenie dokumentw standardyzacyjnych, ktre maj zastosowanie do systemu: formaty plikw, normy czcionek, polonizacja, standardy procesw i produktw, itd.

Zasoby: Okrelenie ogranicze finansowych, ludzkich i materiaowych.

Skala czasowa: ograniczenia na czas wykonania systemu, czas szkolenia, wdraania, itd.

Dokument wymaga

Wymagania powinny by zebrane w dokumencie - opisie wymaga.

Dokument ten powinien by podstaw do szczegowego kontraktu midzy klientem a producentem oprogramowania.

Powinien take pozwala na weryfikacj stwierdzajc, czy wykonany system rzeczywicie spenia postawione wymagania.

Powinien to by dokument zrozumiay dla obydwu stron.

Czsto producenci nie s zainteresowaniu w precyzyjnym formuowaniu wymaga, ktre pozwolioby na rzeczywist weryfikacj powstaego systemu.

Zasady tworzenia dokumentu wymagaWymagania funkcjonalne powinny by oddzielone od wymaga niefunkcjonalnych.

Naley rozdziela opisy poszczeglnych wymaga (w punktach lub akapitach).

Dla kadego wymagania powinien by podany powd jego wprowadzenia: cele przedsiwzicia, ktrych osignicie jest uwarunkowane danym wymaganiem.

Konieczne jest prowadzenie sownikaOpis wymaga moe zawiera terminy niezrozumiae dla jednej ze stron. Mog to by terminy informatyczne (niezrozumiae dla klienta) lub terminy dotyczce dziedziny zastosowa (niezrozumiae dla przedstawicieli producenta).

Wszystkie specyficzne terminy powinny by umieszczone w sowniku, wraz z wyjanieniem. Sownik powinien precyzowa terminy niejednoznaczne i okrela ich znaczenie w kontekcie tego dokument (by moe nieco wsze).

Jako dokumentu wymaga

StylJasno: jednoznaczne sformuowania, zrozumiay dla uytkownikw i projektantw. Strukturalna organizacja dokumentu.Spjno: brak konfliktw w wymaganiach.Modyfikowalno: wszystkie wymagania s sformuowane w jasnych punktach, ktre mog by wyizolowane z kontekstu i zastpione przez inne.

Ewolucja

Moliwo dodawania nowych wymaga, moliwo ich modyfikacji

OdpowiedzialnoOkrelenie kto jest odpowiedzialny za sformuowanie danego wymagania, istotne w przypadku modyfikacji.

Medium

Dokument papierowy lub elektroniczny.Staranne kontrolowanie wersji dokumentu.

Zawarto dokumentu

Przykadowyspis

treci

StreszczenieSpis treciStatus dokumentu (roboczy, 1-sza faza, zatwierdzony, ...)Zmiany w stosunku do wersji poprzedniej

Informacjeorganizacyjne

1. Wstp1.1. Cel1.2. Zakres1.3. Definicje, akronimy i skrty1.4. Referencje, odsyacze do innych dokumentw1.5. Krtki przegld

2. Oglny opis2.1. Walory uytkowe i przydatno projektowanego systemu2.2. Oglne moliwoci projektowanego systemu2.3. Oglne ograniczenia 2.4. Charakterystyka uytkownikw2.5. rodowisko operacyjne2.6. Zaoenia i zalenoci

3. Specyficzne wymagania3.1. Wymagania co do moliwoci systemu3.2. Przyjte lub narzucone ograniczenia.

Kluczowe czynniki sukcesu

Zaangaowanie waciwych osb ze strony klienta

Pene rozpoznanie wymaga, wykrycie przypadkw i dziedzin szczeglnych i nietypowych. Bd popeniany w tej fazie polega na koncentrowaniu si na sytuacjach typowych.

Sprawdzenie kompletnoci i spjnoci wymaga. Przed przystpieniem do dalszych prac, wymagania powinny by przejrzane pod ktem ich kompletnoci i spjnoci.

Okrelenie wymaga niefunkcjonalnych w sposb umoliwiajcy ich weryfikacj.

FAZA ANALIZY

Faza analizy

Celem fazy okrelenia wymaga jest udzielenie odpowiedzi na pytanie: Co i przy jakich ograniczeniach system ma robi?Wynikiem tej fazy jest zbir wymaga na system.

W odrnieniu, celem fazy projektowania jest udzielenie odpowiedzi na pytanie: Jak system ma by zaimplementowany?Wynikiem jest projekt oprogramowania, czyli opis sposobu implementacji.

Celem fazy analizy jest udzielenie odpowiedzi na pytanie: Jak system ma dziaa?Wynikiem jest logiczny model systemu, opisujcy sposb realizacji przez system postawionych wymaga, lecz abstrahujcych od szczegw implementacyjnych.


Faza strategiczna Analiza InstalacjaDokumentacja

Analiza

Analiza

Rozpoznanie, wyjanianie, modelowanie, specyfikowanie i dokumentowanierzeczywistoci lub problemu bdcego przedmiotem projektu;

Ustalenie kontekstu projektu;

Ustalenie wymaga uytkownikw;

Ustalenie wymaga organizacyjnych

Inne ustalenia, np. dotyczce preferencji sprztowych, preferencji w zakresieoprogramowania, ogranicze finansowych, ogranicze czasowych, itd.

Analiza wcza nastpujce czynnoci:

Analiza nie zajmuje si zmian rzeczywistoci poprzez wprowadzenie tam nowych elementw np. w postaci systemu komputerowego. Jej celem jest dokadne rozpoznanie wszystkich tych aspektw rzeczywistoci, ktre mogyby mie wpyw na posta, organizacj lub wynik projektu.

Model analitycznyZ reguy wykracza poza zakres odpowiedzialnoci systemu. Przyczyny:

Ujcie w modelu pewnych elementw dziedziny problemu nie bdcych czci systemu czyni model bardziej zrozumiaym. Przykadem jest ujcie w modelu systemw zewntrznych, z ktrymi system ma wsppracowa.

Na etapie modelowania moe nie by jasne, ktre elementy modelu bd realizowane przez oprogramowanie, a ktre w sposb sprztowy lub rcznie.

Dostpne rodki mog nie pozwoli na realizacj systemu w caoci. Celem analizy moe by wykrycie tych fragmentw dziedziny problemu, ktrych wspomaganie za pomoc oprogramowania bdzie szczeglnie przydatne. Zakres

odpowiedzialnocisystemu

Model analityczny

Dziedzina problemu

Notacje w fazie analizieRodzaje notacji

Jzyk naturalnyNotacje graficzneSpecyfikacje - ustrukturalizowany zapis tekstowy i numeryczny

Szczeglne znaczenie maja notacje graficzne. Inynieria oprogramowania wzoruje si na innych dziedzinach techniki, takich jak elektronika i mechanika. Zalety notacji graficznych potwierdzaj badania psychologiczne.

Funkcje notacji

Narzdzie pracy analityka i projektanta, zapis i analiza pomyswWsppraca z uytkownikiemKomunikacja z innymi czonkami zespouPodstawa implementacji oprogramowaniaZapis dokumentacji technicznej

Notacje powinny by przejrzyste, proste, precyzyjne, atwo zrozumiae,umoliwiajce modelowanie zoonych zalenoci.

Metodyki strukturalne i obiektowe

Metodyki strukturalne - metody tradycyjne rozwijane od lat 60-tych.cz statyczny opis danych oraz statyczny opis procesw. Analizastrukturalna rozpoczyna si od budowy dwch rnych modelisystemu: modelu danych oraz modelu funkcji. Te dwa modele sintegrowane. Wynikiem jest model przepywu danych. Wadpodejcia s trudnoci w zintegrowaniu modeli.

Metodyki obiektowe - rozwijane od lat 80-tych, oparte nawyrnianiu obiektw cznie z operacjami. Ostatnio coraz bardziejpopularne.

Metodyki strukturalne

DIAGRAMY ZWIZKU ENCJI - ERDDIAGRAMY PRZEPYWU DANYCH DFDDIAGRAMY STANW- STD

Diagramy zwizkw encji (ang. entity relationship diagram)E/R lub ERD diagramy

To metoda graficzna modelowania schematu logicznego bazy danych, diagramy ERD skadaj si z trzech gwnych elementw (zbioru encji, atrybutw i zwizkw)

189

Model (diagramy) E/R

Model zaproponowany w publikacji P.P.Chen: The Entity-relationship Data Model: toward a unified view of data, ACM Transactions on Database Systes, Vol. 1, 1976

Jest to model danych dla poziomu konceptualnego, okrelony jako:Model jednostka-zwiazekModel zwizku encjiModel obiektowo-zwizkowy

Entities and relationspips are a natural way to organize physical things as well as information (Peter Chen)

190

Model zwizku encji Podstaw spostrzegania wiata s encje (obiekty)

i zwizki zachodzce midzy tymi encjami (obiektami).

Encje (ang. entity) s wystpieniami obiektw, ktre istniej.

Z kad encj zwizany jest zbir atrybutw opisujcych te encje.

Midzy encjami zachodz pewne zwizki np.: encje klient oraz konto s w zwizku posiada poniewa klient banku posiada konto bankowe.

Encje i ich zwizki zwyko si opisywa przy pomocy diagramw ERD (ang. Entity Relationship Diagram)

191

Definicje skadowych diagramu ERD (lub ER lub E/R)

Zbir encja (entity sets) analogia klasy, encje jako elementy zbioru encji s odpowiednikami obiektw, bdcyc

Documents

ISI Wykłady