Wzorzec projektowy

• sposób rozwiązania problemu w określonym kontekście

• „WP opisuje problem, który się stale powtarza, określa zasadniczą część jego rozwiązania tak, aby można było je zastosować wiele razy za każdym razem w nieco inny sposób …”

Fasada

• „Dostrajanie jednolitego interfejsu do zbioru interfejsów podsystemu…”

• Intencja: uproszczony sposób korzystania z istniejącego systemu

• Problem: Potrzeba wykorzystania części możliwości istniejącego systemu

• Rozwiązanie: Nowy interfejs do istniejącego systemu

• Konsekwencje: Upraszcza korzystanie z systemu

• Implementacja:

  • nowa klasa o pożądanym interfejsie

  • wykorzystanie istniejących funkcji systemu

Adapter

• „Dostosowanie interfejsu klasy do interfejsu, którego oczekuje użytkownik.
  Umożliwia współpracę klas, która bez jego zastosowania nie byłaby możliwa ze względu na ich niezgodne interfejsy…”

• Intencja: dopasowanie istniejącego obiektu do określonego interfejsu

• Problem: obiekt zachowuje się tak jak trzeba, ale ma nieodpowiedni interfejs

• Rozwiązanie: obudowanie obiektu pożądanym interfejsem

• Uczestnicy: Adapter, Adaptowany, Cel, Użytkownik

• Konsekwencje: dopasowanie istniejących obiektów do tworzonych struktur i uniknąć ograniczeń

• Wzorzec mostu

• Wzorzec fabryki abstrakcyjnej

Zadania wykonywane w fazie projektowania

• Uszczegolownie wynikow analizy

  • Podanie naglowkowmetod

  • Okreslnie które z metod będą realizowane jako funckje wirtulane

  • Zastapienie nie których metod bezposrednim dostepem do atrybutow

  • Zastapenie atrybutow reduntantnych przez odpowiednie metody

• Optymalizacja systemu

  • Zmiana algorytmu przetwarzania

  • Zaprojektowanie waskich gardel w jezyku nizszego poziomu

  • Denormliazacja relacyjnej bazy danych

  • Stosowanie indeksow i innych struktur pomocniczych

  • Analiza mechanizmow buforowania danych

• Dostoswanie do ograniczen srodowiska implementacyjnego

  • Brak dziedziczenia wielokrotnego.

  • Brak dziedziczenia.

  • Brak metod wirtualnych (przesłaniania).

  • Brak złożonych atrybutów

  • Brak typów multimedialnych

• Okreslenie fizycznej struktury systemu

  • Okreslnie struktury kodu zrodlowego

  • Podzial systemu na poszczegolne aplikacje

  • Fizyczne rozmieszczenie danych i aplikacji na stacjach roboczych i serwerach

RAD – szybkie rozwaizywanie aplikacji

Sposoby wydania komend systemowi

• Wpisywanie z lini komend

• Wybor opcji z menu

• Wcisniecie skorotu

• Korzystanie z ikon

• Korzystanie z myszy

Zasady projektowania interfejsu uzytkownika

• Spojnosc

• Skorty kaliwszoww ( dla doswiadczonych )

• Potweirdzenie przyjecia zlecenia od uzytkownika

• Prost obsluga bledow

• Odowlywanie akcji

• Wrazenie kontroli nad systemem

• Grupowanie powiaznych operacji

Zalety baz danych

• Wyskoa efektywnosc i stablinosc

• Bezpieczenstwo

• Wielodostep

• Rozszerzalnosc

• Możliwe kaskadowe usuwanie powiazanych danych

Wady baz danych

• Konieczność przeprowadzenie nietrywialnych odwzorowań przy przejściu z modelu pojęciowego na strukturę relacyjną.

• Ustalony format krotki powodujący trudności przy polach zmiennej długości.

• Trudności reprezentacji dużych wartości

• W niektórych sytuacjach - duże narzuty na czas przetwarzania

• Brak możliwości rozszerzalności typów

• Brak systematycznego podejścia do informacji proceduralnej

DDP

DDP jest centralnym miejscem, w którym zgromadzone są wszystkie informacje odnośnie budowy i działania oprogramowania.

DDP powinien być zorganizowany w taki sam sposób, w jaki zorganizowane jest oprogramowanie.

DDP powinien być kompletny, odzwierciedlający wszystkie wymagania zawarte w DWO.

Materiał, który nie mieści się w podanej zawartości dokumentu, powinien być załączony jako dodatek.

Nie należy zmieniać numeracji punktów. Jeżeli jakiś punkt nie jest zapełniony, wówczas należy pozostawić jego tytuł, zaś poniżej zaznaczyć "Nie dotyczy."

Asercja = kod służący do alarmowania, gdy nie jest spełnione określone założenie

Planowanie zadan i metody ichobrazowania

• Zadanie - czynność, istotna z punktu widzenia projektu, która w określonym czasie musi zostać zakończona

• Planowanie zadań – ustalanie jakie zadania, przez kogo i w jakim terminie powinny zostać wykonane

Po co planowac ?

• Dzielenie problemu na mniejsze problemy, które łatwiej kontrolować

• Lepsza kontrola nad:

  • Czasem (opóźnienia)

  • Zasobami ludzkimi

  • Ryzykiem

  • Kosztami

  • Jakością

• Wiara w powodzenie projektu członków całego zespołu oraz klienta

Gdzie zaczyna się palnowanie

• Faza strategiczna (wysoki poziom abstrakcji)

• Dalsze uszczegółoweinie, kolejne fazy planowania

Hierarchia w palnowaniu

• Okreselnie zalozen projektowych

• Oszacowanie kosztow

• Identyfikacja obszarow ryszyka

• Utworzenie harmonogramu

WBS (Work Breakdown Structure)

• Definicja

Hierarchiczna struktura obrazująca dekompozycję produktów wykonywanych w ramach danego przedsięwzięcia. Może być przedstawiona np. w postaci drzewa, listy kilkupoziomowej, mapy pamięci

• Dzieli projekt na części

• Określa zawieranie się poszczególnych części projektu w sobie, czyli jaki zestaw części niższego poziomu tworzy daną część wyższego poziomu

• Projekt jest hierarchia elementów związanych z produktami wytworzonymi i w trakcie realizacji projektu

Tworzac diagram musimy pameitac o:

• Podział prac powinien następować według głównych produktów projektu

• Diagram powinien koniecznie uwzględniać wszystkie czynności ryzykowne, niosące zagrożenia projektu

• Poziom szczegółowości czynności: nie za duży, nie za mały - zwykle 2 lub 3 poziomy (przy większej szczegółowości diagram staje się nieczytelny)

Typy WBS

• Produktowy

• Fazowy

• Strukturalny

• Inne struktury podziału pracy

  • CWBS (Contractual WBS)

  • OBS (Oraganizational Breakdown Structure)

  • RBS (Resource Breakdown Structure)

  • Bill of Materials

  • PBS (Project Breakdown Structure)

Role postaci w RAM(responsible assiment matrix)

• Responsible – osoba wykonuje zadanie. Powinna występować tylko 1 taka osoba dla zadania, w przeciwnym wypadku zadanie powinno zostać przeniesione do niższego poziomu abstrakcji lub podzielone

• Accountable – osoba odpowiedzialna za to, że zadanie zostanie w ogóle wykonane

• Supportive – osoba posiada materiały do wykonania zadania lub pomaga w jakiś sposób przy wykonaniu

• Consulted – osoba ma informacje lub zdolności do zakończenia tego zadania

• Informed - osoba ma być informowana o postępach i wynikach prac

Diagram sieciowy

• Pochodzenie – teoria grafów

• Podział w diagramach sieciowych

  • Czynności - strzałki oznaczające wykonywane w czasie czynności

  • Zdarzenia –węzły oznaczające zakończenie i rozpoczęcie czynności

• Zależności między poszczególnymi działaniami w sieci

Tworzenie diagramu

• Ustalenie listy wszystkich czynności

• Ustalenie przewidywanego czasu zakończenia dla każdej z czynności

• Ustalenie zależności między zadaniami

• Wykreślenie grafu

Techniki tworzenia diagramow sieiocwych

• CMP (Critical Path Method) – metoda ścieżki krytycznej

  • Zdefiniowanie oraz wybór ścieżki krytycznej.

  • Zadania krytyczne.

  • Opóźnienia na ścieżce krytycznej w kontekście projektu

• PERT (Program Evaluation and Review Technique) - technika oceny i kontroli programu działania

  • Identyfikacja elementów procesu i wyznaczenie odcinków czasu, które mają największy wpływ na realizację projektu

  • Czynności jako sieć wzajemnych zależności poszczególnych zdarzeń w czasie

  • Etapy budowy sieci powiązań między czynnościami

Zalety diagramow sieiocwych

• Skrócenie czasu realizacji projektu

• Zmniejszenie kosztów

• Racjonalne wykorzystanie rezerw czasowych

• Koncentracja uwagi na czynnościach krytycznych dla całego postępowania

• Ułatwienie planowania

• Stworzenie podstaw do kontroli przebiegu prac w każdym momencie ich prowadzenia

Harmonogram w projektach

• Definicja

• Składowe

  • Zadania

  • Zależności między zadaniami

  • Czas trwania

  • Alokacja zasobów do poszczególnych zadań

• Etapy

Diagram Gantta

• Wizualizacja planowania

• Przebiegu procesu w czasie

• Zmienność przebiegu wykonania zadań

• Przedstawienie układu zdarzeń na diagramie

Oprogramowanie wspomagajace

• Ms Project

• GanttProject

MS PROJECT 2003

• Definicja standardowa

Microsoft Project 2003

jest to pakiet programów mających na celu ułatwienie zarządzania projektami i zasobami oraz wspomagających współpracę podczas tworzenia projektu.

Zarzadzanie projektami

jest to niepowtarzalny zbiór czynności wykonywanych w celu osiągnięcia wyznaczonych celów głównych i pośrednich w skończonym czasie. Zawiera się w nim między innymi planowanie, harmonogramowanie, realizacja i kontrola zadań składających się realizację celów projektu.

Pakiet MS Project 2003 dzielimy na 4 produkty :

• Project Standard 2003

• EPM (Enterprise Project Management):

  • Project Professional 2003

  • Project Server 2003

  • Project Web Access

Funkcje i Zalety

W skrocie :

• Latwosc obslugi

• Atrakcyjne przekazy

• Zorganizowana Praca

• Efektywniejsze organizowanie pracy przy wykorzystaniu zaawansowanych możliwości planowania.

• Śledzenie i ocenianie wpływu zmian w harmonogramie i zasobach na ogólny plan projektu.

• Dostosowywanie planów pod kątem przechwytywania informacji dotyczących określonych projektów.

• Wyświetlanie żądanych informacji o projekcie.

• Koncentrowanie się na interesujących informacjach dzięki zastosowaniu filtrów i grup.

• Wzmocnienie oddziaływania przekazu dzięki wykorzystaniu funkcji Kopiuj obraz do Kreatora pakietu Office na potrzeby komunikowania i przedstawiania pomysłów i informacji opracowanych w programie Project Standard 2003 w ramach innych programów, takich jak Microsoft Office Word 2003, Microsoft Office PowerPoint® 2003 i Microsoft Office Visio® 2003.

• Zwiększenie jasności przekazu dzięki zastosowaniu nowych rozszerzeń w zakresie drukowania do sporządzania jednostronicowych wydruków z harmonogramami projektów.

• Udostępnianie członkom zespołu informacji dotyczących projektów poprzez zapisywanie plików programu Project (MPP) w witrynie programu Microsoft Windows® SharePoint™ Services (WSS). Program Windows SharePoint Services jest składnikiem systemu Microsoft Windows Server 2003 umożliwiającym tworzenie witryn sieci Web na potrzeby udostępniania informacji i pracy zespołowej nad dokumentami.

• Szybkie rozpoczynanie pracy przy użyciu narzędzi udostępniających metodologię zarządzania projektami, która zapewnia efektywniejsze opracowywanie harmonogramów i sprawniejsze zarządzanie zasobami.

• Uzyskiwanie dostępu do pomocy i szkoleń online, zapewniających aktualne informacje i wsparcie.

• Tworzenie projektu w oparciu o szablon pobrany z Galerii szablonów, a nie od podstaw.

• Używanie przyjaznych narzędzi do wykonywania złożonych i atrakcyjnych projektów bez konieczności zaawansowanych szkoleń.

• Oszczędzanie czasu dzięki łatwemu przenoszeniu informacji o projekcie między programem Project 2003 i innymi programami pakietu Office, na przykład do programu Microsoft Office Excel 2003.

• Szybkie nauczenie się obsługi programu Project Standard 2003 i nawigacji po nim dzięki zaktualizowanemu interfejsowi, wyglądającemu podobnie we wszystkich programach pakietu Microsoft Office 2003.

Testowanie

• Dwa główne cele testowania:

  • Wykrycie i usunięcie błędów w systemie

  • Ocena niezawodności systemu

Fazy testowania

• Weryfikacja(verification) - testowanie zgodności systemu z wymaganiami zdefiniowanymi w fazie określenia wymagań.

• Atestowanie(validation) - ocena systemu lub komponentu podczas lub na końcu procesu jego rozwoju na zgodności z wyspecyfikowanymi wymaganiami. Atestowanie jest więc weryfikacją końcową.

Typy Przeglądów Oprogramowania

Przegląd techniczny – ocena zgodności elementów oprogoramowania z przyjętym planem

Przejścia(walkthrough) – wczesna ocena dokumentów, modeli, projektów i kodu

Audyt – przeglądy potwierdzające zgodność oprogramowania z wymaganiami, specyfikacjami, zaleceniami, standardami, procedurami, instrukcjami, kontraktami i licencjami

Ogolem

Przegląd jest procesem lub spotkaniem, podczas którego produkt roboczy lub pewien zbiór produktów roboczych jest prezentowany dla personelu projektu, kierownictwa, użytkowników, klientów lub innych zainteresowanych stron celem uzyskania komentarzy, opinii i akceptacji.

Skład zespołu oceniającego oprogramowanie

• Kierownik

• Sekretarz

• Członkowie:

  • użytkownicy

  • kierownik projektu oprogramowania

  • inżynierowie oprogramowania

  • bibliotekarz oprogramowania

  • personel zespołu zapewniania jakości

  • niezależny personel weryfikacji i atestowania

  • niezależni eksperci nie związani z rozwojem projektu

Ogółem

Zadania kierownika: nominacje na członków zespołu, organizacja przebiegu oceny i spotkań zespołu, rozpowszechnienie dokumentów oceny pomiędzy członków zespołu, organizacja pracy, przewodniczenie posiedzeniom, wydanie końcowego raportu, i być może inne zadania.

Audyt

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

• Przykłady Analiza stanu projektu Analiza celowości Analiza procesu wytwórczego

• Relacje odbiorca dostawca audyt wewnętrzny audyt zewnętrzny

• Etapy planowanie i przygotowanie wykonywanie raportowanie zamknięcie

• Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie całego projektu

INSPEKCJE

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

• cechySesje są zaplanowane i przygotowane

• Wykonywana przez techników dla techników (bez udziału kierownictwa) Dane nie są wykorzystywane do oceny pracowników

• KorzysciZasoby na inspekcje są gwarantowane Wzrost produktywności od 30% do 100% Skrócenie czasu projektu od 10% do 30%

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

• Zwiększenie motywacji świadomość, że produkt będzie oceniany (wybór pomiędzy byciem zażenowanym a dumnym) nauka przez znajdowanie błędów Mniejsze koszty marketingu („przykrywanie” braku jakości)

• ZagrozeniaOcena osób na podstawie zebranych metryk Złe prowadzenie inspekcji - mała efektywność i skuteczność

• Słabi kontrolerzy Kontrola indywidualna niewystarczająca (jakość i ilość) Skłonność autora do lekceważenia defektów na etapie opracowywania dokumentów (“inspekcja wskaże błędy...”) Dyskusje o rozwiązaniach podczas spotkania kontrolnegobbaw2q1‘ qazwsedrftgyhujik]/

• XEDzwsQAScdhnjmk,łjh8,L;./’0;9

• Poczucie zagrożenia u autora - nieuzasadniona obrona własnych rozwiązań Krytyczne nastawienie do autora

Rodzaje testów

Wykrywanie błędów, czyli testy, których głównym celem jest wykrycie jak największej liczby błędów w programie

Testy statystyczne, których celem jest wykrycie przyczyn najczęstszych błędnych wykonań oraz ocena niezawodności systemu.

Testy dynamiczne, które polegają na wykonywaniu (fragmentów) programu i porównywaniu uzyskanych wyników z wynikami poprawnymi.

Testy statyczne, oparte na analizie kodu

Fazy testowania systemu

Testy modułów: Są one wykonywane już w fazie implementacji bezpośrednio po zakończeniu realizacji poszczególnych modułów

Testy systemu: W tej fazie integrowane są poszczególne moduły i testowane są poszczególne podsystemy oraz system jako całość

Testy akceptacji (acceptance testing): W przypadku oprogramowania realizowanego na zamówienie system przekazywany jest do przetestowania przyszłemu użytkownikowi. Testy takie nazywa się wtedy testami alfa. W przypadku oprogramowania sprzedawanego rynkowo testy takie polegają na nieodpłatnym przekazaniu pewnej liczby kopii systemu grupie użytkowników. Testy takie nazywa się testami beta.

Elementy podlegające testowaniu

• Wydajność systemu

• Interfejsy systemu

• Własności operacyjne systemu

• Testy zużycia zasobów

• Zabezpieczenie systemu

• Przenaszalność oprogramowania

• Niezawodność oprogramowania

• Odtwarzalność oprogramowania (maintainability)

• Bezpieczeństwo oprogramowania

• Kompletność i jakość złożonych funkcji systemu

• Nie przekraczanie ograniczeń

• Modyfikowalność oprogramowania

• Obciążalność oprogramowania

• Skalowalność systemu

• Akceptowalność systemu

• Jakość dokumentacji

Testowanie na zasadzie białej skrzynki

• Idea

• Cechuje się:

  • sprawdzanie wewnętrznej logiki oprogramowania

  • dane testowe muszą uwzględniać każdą ścieżkę w programie

  • kryteria doboru danych testowych

    • kryterium pokrycia wszystkich instrukcji

    • kryterium pokrycia instrukcji warunkowych

• 1.Testowanie n/z białej skrzynki pozwala sprawdzić wewnętrzną logikę programów poprzez odpowiedni dobór danych wejściowych, dzięki czemu można prześledzić wszystkie ścieżki przebiegu sterowania programu.

• 2.Tradycyjnie programiści wstawiają kod diagnostyczny do programu aby śledzić wewnętrzne przetwarzanie. Debuggery pozwalają programistom obserwować wykonanie programu krok po kroku.

Testowanie na zasadzie czarnej skrzynki

• Idea

• Cechuje się:

  • nie wnikaniem w kod programu

  • testyjemy specyfikacje, której „nie ma”

  • sprawdzanie dokumentu pod względem błędów i przeoczeń

  • badanie standardowe

  • szczegółowe testowanie

Tak określa się sprawdzanie funkcji oprogramowania bez zaglądania do środka programu. Testujący traktuje sprawdzany moduł jak „czarną skrzynkę”, której wnętrze jest niewidoczne.

Test Driven development

• Idea

• Cechuje się:

- jest oparte o testy jednostkowe

- testy pisane są przed implementacją metod właściwych

- metodę tą wykorzystuje się w MSF v.3 i MSF v.4

Testy jednostkowe – jeden test na jedna metody

1. Podpunkt – implementujemy testy, potem implementujemy metfody które spelniaja te testy

2. Ta metoda zostala doecniona w MSF v4.

Podsumowanie

• Stosowanie testowania oprogramowania może znacznie obniżyć koszty projektu, dzięki wczesnemu wykryciu błędów

• Wskazuje błędy w działaniu oprogramowania, błędne linie kodu

• Sprawdza stabilność systemu