O sobie

gkukawski@mimuw.edu.pl

• Codziennie daję wartość biznesową klientom, pracując w projektach informatycznych w rolach:
• Architekta
• Analityka
• Kierownika projektu
• Programisty
• Dzielę się wiedzą i doświadczeniem ze studentami na Wydziale Matematyki, Informatyki i Mechaniki, Uniwersytetu Warszawskiego.

Kilka pomocnych odnośników:

• Odnośnik do Visual Paradigma - gdyby ktoś chciał miec go w domu
• Darmowy kurs UML - przyda się ta wiedza, bo będziecie modelować w UML

2010/2011 - Inżynieria oprogramowania

Punktacja

Produkt\Projekt	RPE	Głosowania	Stary-Góry	PaperM	Rezerwacje
Wizja	10/10	10/10	10/10	10/10	7/10
Procesy biznesowe	10/10	10/10	10/10	10/10	10/10
Przypadki użycia	10/10	10/10	10/10	9/10	10/10
Model dzidziny	10/10	10/10	10/10	10/10	10/10
Architektura	10/10	10/10	10/10	10/10	10/10
Przypadki testowe	10/10	10/10	9/10	10/10	9/10
Prototyp	10/10	9/10	10/10	10/10	9/10
Plan projektu	10/10	10/10	10/10	10/10	9/10
	80/80	79/80	79/80	79/80	74/80

* szczegóły i uzasadnienie punktacji u KP

* poprawki na zajęciach 31 maja

Zo zrobienia

• na 12.04 - Działająca architektura systemu
• na 19.04 - Przypadki testowe (opis poniżej)

05 kwietnia 2011 - testy

Przypadek testowy

• Zbiór wejść, warunków początkowych oraz oczekiwanych wyników i warunków końcowych utworzony, aby wykonać określoną ścieżkę w aplikacji lub zweryfikować zgodność z określonym wymaganiem (IEEE 610).

Co powinien zawierać przypadek testowy

• Unikalny identyfikator
• Opis - co sprawdza PT
• Warunki wstępne - co musi być spełnione, aby wykonać dany PT
• Lista kroków (pojedynczych czynności) do wykonania w ramach PT
• Spodziewane rezultaty wykonanej czynności
• Miejsce na opis aktualnego rezultatu czynności
• Status

Cechy dobrego przypadku testowego

• Znajduje maksymalną mozliwą liczbę defektów
• Weryfikuje zgodność systemu/aplikacji z wymaganiami
• Minimalizuje koszty wsparcia i utrzymania
• Zapewnia jakość systemu

26 lutego 2010 - Procesy biznesowe

TODOS:

• Na wtorek 1 marca przynieść poprawione wizje
• Na wtorek 1 marca przynieść conajmniej 3 diagramy aktywności odzwierciedlające główne procesy biznesowe
• KP na wtorek 1 marca załatwiają sprawę svn

Definicja procesu - słownikowa

• Przebieg regularnie po sobie następujących zjawisk, pozostających między sobą w związku przyczynowym.

Przykładowe inne definicje procesów biznesowych

• ałość złożona z sukcesywnie wykonywanych operacji zmierzających do osiągnięcia wcześniej określonych rezultatów. W procesie wykorzystywane są zasoby wejściowe , które ulegają przetworzeniu i są przekazywane do następnych procesów lub klienta. (J. Brilman)
• Reprezentuje przepływ pracy i informacji w biznesie. Działa na określonych bytach i sprawia, że biznes funkcjonuje. (Object Management Group)
• Jest wiązką aktywności posiadającym jedno lub więcej wejść i tworzącym wyrób o pożądanej przez klienta wartości. (M. Hammer)
• Proces to zestaw powiązanych i wzajemnie oddziałujących działań, które przekształcają wejścia w wyjścia. (PN-EN ISO 9000:2001)

Cechy procesów biznesowych

• Definiowalność: proces musi mieć jasno zdefiniowane granice, wejście i wyjście
• Porządek: proces musi składać się z działań uporządkowanych według ich usytuowania w czasie
• Klient: musi być odbiorca rezultatów procesu
• Zwiększanie wartości: transformacja w trakcie procesu musi dawać odbiorcy dodatkową wartość
• Wielofunkcyjność: proces może, ale niekoniecznie musi, obejmować wiele funkcji

Przykłady procesób biznesowych

• Złożenie zamówienia w salonie samochodowym
• Złożenie wniosku kredytowego
• Rejestracja konta bankowego
• Zakup towaru na allegro

Skrót notacyjny diagramu aktywności

17 lutego 2010 - Zakres i forma Wizji

TODOS:

• KP zakładają projekty w SVN (Musicie je jakoś chwytliwie nazwać ;) )
• na wtorek 22 lutego - przynieść wizję Systemu

Obiecany ogólny zakres wizji:

• Krótki opis systemu
• Korzyści i możliwości powstałe w wyniku zbudowania systemu
• Problem lub problemy, rozwiązywane przez system
• Dla kogo robimy ten system – kim są przyszli użytkownicy, udziałowcy
• Do czego będzie służył nasz produkt – bardzo ogólnie właściwości wysokiego poziomu lub przedstawić w postaci kilku kluczowych przypadków użycia
• Niektóre najważniejsze wymagania poza funkcjonalne, np.
• System operacyjny
• Baza danych
• Wymagana niezawodność
• Skalowalność
• Zasady licencjonowania i ustalania ceny (np. płacimy za usługę, za wersje systemu, za utrzymanie i aktualizację).
• Zasady licencjonowania i ustalania ceny (np. płacimy za usługę, za wersje systemu, za utrzymanie i aktualizację).
• Przewidywany zwrot z inwestycji (ile system będzie kosztował i za ile czasu się zwróci)

Oraz kilka słów o formie wizji:

• Nie wodolejemy ;)
• Konkretna i zwięzła
• Ma poruszać najistotniejsze rzeczy
• Ma być cały czas aktualna
• Ma być zrozumiała dla wszystkich (biznes, it, użytkownicy, sponsorzy itp.)