Metoda białej skrzynki - logiczna struktura programów * Metoda szklanej skrzynki, testowanie strukturalne * Projektowanie testów na podstawie logicznej struktury algorytmu - Wszystkie niezależne ścieżki przepływu - Wszystkie możliwe kombinacje decyzji logicznych - Jedno i wielokrotne wykonanie pętli z uwzględnieniem warunków brzegowych Po co? - Literówki są rozmieszczone losowo - Liczba błędów logicznych i błędnych założeń jest odwrotnie proporcjonalna do częstości wykonywania danego fragmentu kodu - To, co w założeniu miało być rzadko, w rzeczywistości jest bardzo często wykonywane Gruntowne testowanie - Identyfikacja wszystkich ścieżek logicznych - Sprawdzenie działania każdej z nich - Ocena ich poprawności Analiza statyczna - inspekcje kodu (Praca z kodem źródłowym) - Specyfikacja wymagań -> prototyp - Projekt architektury systemu - Specyfikacja formalna - Projekt szczegółowy - Program Metody formalne - zwolennicy twierdzą, że mogą zrewolucjonizować tworzenie oprogramowania, przeciwnicy, że są zbyt skomplikowane do stosowania w praktyce. Większość wie o nich zbyt mało, żeby ocenić ich przydatność * Kompletne, spójne i jednoznaczne specyfikacje * Systemy opisywane za pomocą wymagań (faktów) * Fakty zapisane jednoznacznie w notacji opartej na logice i teorii zbiorów * Analiza specyfikacji – dowód poprawności, niesprzeczności Minusy "nieformalne": -- sprzeczność -- niejednoznaczność -- niejasność -- niezupełność -- różne poziomy abstrakcji Plusy matematyki: -- Zwięzły i dokładny opis zjawisk, obiektów i rezultatów -- Płynne przejścia pomiędzy etapami tworzenia oprogramowania -- Notacja jest: abstrakcyjna(modelowanie), precyzyjna, umowżliwia weryfikacje poprawności i niesprzeczności Throw-away prototyping * Ocena lub uzyskanie wymagań * Zaczynamy od najgorzej zrozumiałych wymagań * Stosowany by zmniejszyć ryzyko błędów związanych z wymaganiami * Prototyp jest: otworzony na podstawie pierwotnej specyfikacji, poddawany testom, i wyrzucany do kosza * Prototyp nie może być produktem finalnym: szczątkowy, jak utrzymać?, kiepsko wykonany AOD Aspect-Oriented Development Trudność ze współbieżnością * Większa częstotliwość i liczba wymian informacji pomiędzy fazami projektowymi

* Więcej zadań rozpoczyna się z niekompletnymi lub wstępnymi wymaganiami * Sekwencyjne zarządzanie zawodzi Dekompozycja problemu * Funkcjonalna - Obiekty, moduły, procedury, itd * Aspektowa - Dotyczą więcej niż jednego elementu funkcjonalnego, np. synchronizacja, komunikacja - Nie da się tego „czysto” zrobić stosując takie techniki jak OO Cel AOD * Dostarczenie metod i technik umożliwiających funkcjonalną i aspektową dekompozycję problemu * Aspekty „przecinają” komponenty funkcjonalne * Dostarczenie metod i technik umożliwiających złożenie komponentów funkcjonalnych i aspektów w spójną implementację systemu Oprogramowanie * Raczej byt logiczny niż fizyczny - Wytwarzany a nie fizycznie konstruowane - niewidoczny * Nie zużywa się tak, jak byt fizyczny * Ciągła zmiana wymagań (żyje!) * Złożoność (Zarówno produkt, jak i proces) * Składa się z: - programów wykonywanych na komputerach każdej wielkości i rodzaju - dokumentów elektronicznych i drukowanych - danych Model - pewne uproszczenie rzeczywistości Dlaczego modelujemy? - Lepiej zrozumieć system, który rozwijamy - Pokazanie zależności między elementami - Budujemy modele skomplikowanych systemów, ponieważ nie jesteśmy w stanie ogarnąć ich w całości Realizuje 4 cele: - Pomaga w wizualizacji - Pozwala wyspecyfikować strukturę i zachowanie systemu - Daje pewien wzorzec wyznaczający nam kolejne kroki budowy aplikacji - Dokumentuje podjęte przez nas decyzje Metodyka (proces IO) Definiuje KTO robi CO, KIEDY oraz JAK, żeby osiągnąć zamierzony cel - można mierzyć, kontrolować, poprawiać, zmieniać w miarę poznawania Cel wprowadzenienia procesu: - Efektywność, Pielęgnacja, Przewidywalność, Powtarzalność, Jakość, Doskonalenie, Śledzenie CMM Capability Maturity Model (model dojrzałości) * Pięciostopniowa miara dojrzałości organizacji do produkcji oprogramowania * Ocena zakłada, że zawsze stosujemy te same procedury * Brak procedury oceny CMM – jest subiektywna Standardy IO: IEEE, ISO, DoD Technika wodospadu * Opóźnia identyfikację ryzyka * Trudno ocenić rzeczywisty czas do ukończenia projektu

* Odsuwa w czasie integrację i agreguje testowanie * Wyklucza wczesne wdrażanie * Częste niezaplanowane iteracje Technika iteracyjna cykl: Analiza -> Implenetacja->Testowanie->Wdrażanie->Ewaluacja->Wstepne planowanie->Planowanie->Wymagania * W wyniku każdej iteracji powstaje WYKONYWALNY MODUŁ Zalety: - Rozwiązanie ryzykownych kwestii zanim będą duże inwestycje - Umożliwia wczesną ocenę przez klienta - Ciągłe integrowanie i testowanie - Realizacja zadania w małych, krótkoterminowych krokach - Umożliwia częściowe wdrażanie produktu Architektura - Zbiór zasad, decyzji, reguł lub wzorców dla dowolnego systemu, który zapobiega niepotrzebnej radosnej twórczości projektantów * Architektura oprogramowania określa najważniejsze elementy organizacji systemu: * Wybór elementów strukturalnych oraz ich interfejsów * Określenie zachowania systemu jako interakcji pomiędzy tymi elementami * Kompozycja elementów strukturalnych i behawioralnych w podsystemy * Ogólna budowa pewnego rozwiązania informatycznego, którego elementem jest zarówno oprogramowanie, jak i pewna infrastruktura techniczna, sprzęt * Łączy własności strukturalne (komponenty fizyczne) oraz funkcjonalne (zewnętrzne i wewnętrzne funkcje systemu) * Opisuje składowe, powiązania między nimi oraz sposoby i kierunki przepływu danych Architektura logiczna - Podział na logiczne fragmenty (moduły, pakiety, komponenty), które powinny współpracować w celu realizacji wymagań - UML – komponent + interfejsy Architektura fizyczna - Określenie fizycznych jednostek (maszyn) oraz metod komunikacji - UML –węzeł Architektura -> Projekt -> Implementacje Modułowa architektura: - Ponowne użycie i modyfikacja modułów - Wybór z komercyjnie dostępnych komponentów - Inkrementacyjny rozwój oprogramowania Moduł - komponent - Nietrywialna, prawie niezależna i wymienna część systemu, która realizuje zdefiniowaną funkcjonalność. * Umożliwia: ponowne wykorzystanie Komponentów, Architektury * Kontrola: Zarządzanie złożonym systemem, Integracja Po co wizualizacja * Uchwycenie struktury i zachowania * Pokazanie zależności między elementami * Utrzymanie spójnego projektu i implementacji * Ukrywanie oraz wyróżnianie szczegółów kiedy trzeba * Promuje jeden wspólny język wymiany informacji -UML: jeden język dla wszystkich osób związanych z tworzeniem projektu UML Unified Modeling Language

* Język do specyfikowania, wizualizowania, konstruowania i dokumentowania tworów oprogramowania i modelowania biznesu * Reprezentuje zbiór najlepszych praktyk inżynierskich które dowiodły przydatności przy modelowaniu dużych i skomplikowanych systemów Dlaczego UML? - Gotowy wizualny język modelowania do budowy i wymiany modeli - Niezależny od języków programowania i procesów tworzenia - Udostępnia podstawy formalne do zrozumienia języka modelowania - Zachęca do wzrostu rynku narzędzi OO - Wspomaga wysoko-poziomowe rozwiązania - Integruje najlepsze praktyki Kompletne testowanie * Funkcjonalność * Wydajność * Niezawodność Wymaganie - w inżynierii jest pojedynczą, udokumentowaną potrzebą określonego produktu czy usługi, albo sposobu ich działania. Jest to stwierdzenie identyfikujące potrzebne cechy, możliwości, charakterystyki lub jakość systemu, aby był on wartościowy i pożyteczny dla użytkownika. * Funkcjonalne * Pozafunkcjonalne * Ograniczenia SRS Software RequirementsSpecification * Specyfikacja konkretnego produktu oprogramowania realizującego zadaną funkcjonalność w określonym środowisku * SRS może być napisana przez jedną lub wiele osób reprezentujących dostawcę albo/i klienta 1.Zdefiniuj standardową strukturę dokumentu 2.Wyjaśnij, jak korzystać z dokumentu 3.Dołącz streszczenie wymagań 4.Opracuj uzasadnienie biznesowe dla systemu 5.Zdefiniuj terminy specjalistyczne 6.Wybierz czytelny szablon dokumentu 7.Pomóż czytelnikom znaleźć informację 8.Uczyń dokument łatwym do zmiany PU Przypadki użycia * Używają interdyscyplinarnego języka * Opisują co system będzie robił (zachowanie systemu wzgledem uslugi) * Zapisują podejmowane decyzje * Pozwalają weryfikować kompletność * Dostarczają kontekstu dla wymagań * Obojętność technologiczna Zalety: - Zapisująwymagania funkcjonalne w łatwej do zrozumienia formie - Stanowią szkielet dlazapisu wymagań pozafunkcjonalnychoraz dla harmonogramu Wady: - Zapisują wyłączniewymagania funkcjonalne - Projektowanienie ogranicza się do samych PU Poziomy przypadów: biznesowy, użytkownika, podfunkcji

Zespół: Mały 2-3 osoby (duży system –kilka zespołów), Więcej recenzentów Zrównoważony: Zróżnicowany (analityk + klient), Synergia (uzupełnianie się) * Opisująproces jako sekwencję kroków * Poziom szczegółowości pozwala na rozważanie ich pojedynczo * Diagram przypadków użycia opisuje wymagania funkcjonalne Zwinna specyfikacja wymagań: * Karty wymagań (UserStories) - Opowiadania/Scenariusze użytkownika - Historyjki użytkownika ? * Szkice ekranów * Testy akceptacyjne Karta wymagań * Informują jedynie o pewnejfunkcjonalności * By je jednoznacznie zinterpretować należy dołączyć do nich testy akceptacyjne Technologia obiektowa * Abstrakcja - Istotna charakterystyka jednostki odróżniająca ją od wszystkich jednostek innego typu - Definiuje pewien ograniczony obszar zależny od perspektywy - Nie jest konkretnym przykładem, a jedynie oznacza istotę czegoś * Hermetyzacja - Ukrywanie przed klientem implementacji(Klient korzysta tylko z interfejsu) - Polimorfizm - Możliwość umieszczeniawielu różnych implementacji za jednym interfejsem * Modularność - Podział całości na łatwe do zarządzania części - Pomaga ogarnąć i zrozumieć skomplikowane systemy * Hierarchia Obiekt - Reprezentuje pewną jednostkę albo fizyczną, albo koncepcyjną, albo oprogramowania. Obiekt jest jednostką o dobrze zdefiniowanym zakresie, charakteryzującą się pewnym STANEM I ZACHOWANIEM * Stan jest reprezentowany przez: atrybuty i relacje * Zachowanie jest reprezentowane przez: operacje, metody i automaty stanów Każdy obiekt jest unikalną jednostką nawet, jeżeli jest w takim samym stanie jak inny obiekt. Klasa jest opisem zbioru obiektów posiadających ten sam zbiór atrybutów, operacji, relacji oraz semantykęKlasa jest abstrakcją, a więc: - Podkreśla pewną charakterystykę - Ukrywa inne cechy Diagram klas przedstawia klasy i ich relacje Zachowanie systemu * Określa jak system się zachowuje i jak reaguje * Jest widoczne na zewnątrz i możliwe do przetestowania * Jest opisane przez PRZYPADKI UŻYCIA (Use-Cases) * Przypadki użycia opisują system, jego środowisko i relacje pomiędzy systemem i środowiskiem Wzorzec (pattern) * Znane rozwiązanie znanego problemu w określonym kontekście * Fragment rozwiązania, element układanki

Szkielet (framework) * Określa ogólne podejście do rozwiązania problemu * Szkielet rozwiązania, którego elementami mogą być np. wzorce projektowe Atrybut jest nazwaną własnością klasy, który opisuje zakres wartości jakie może przyjmować instancja własności * Klasa może mieć dowolną liczbę atrybutów lub nie mieć ich wcale !! Operacja - Jest implementacją pewnej usługi, której wykonania można oczekiwać od każdego obiektu danej klasy * Klasa może mieć dowolną liczbę operacji lub wcale !! Asocjacja - Semantyczna relacja pomiędzy dwoma lub wieloma klasyfikatorami, która reprezentuje zależność między ich instancjami Agregacja - asocjacja modelująca relację całość-część * Część może należeć do kilku całości * Całość nie zarządza czasem istnienia części Kompozycja - asocjacja modelująca relację całość-część * Część może należeć do co najwyżej jednej całości * Całość zarządza czasem istnienia części Niestrukturalna relacja - klasa jestparametremlub zmienną lokalną metody innej klasy Generalizacja - definiuje hierarchię od klas ogólnych do wyspecjalizowanych Model spiralny * Wariant kaskadowego cyklu życia * Sterowany ryzykiem * Cykliczny (iteracje) * Punkty milowe Metody formalne - zwolennicy twierdzą,że mogą zrewolucjonizować tworzenie oprogramowania, przeciwnicy, że są zbyt skomplikowane do stosowania w praktyce. Większość wie o nich zbyt mało, żeby ocenić ich przydatność * Kompletne, spójne i jednoznaczne specyfikacje * Systemy opisywane za pomocą wymagań (faktów) * Fakty zapisane jednoznacznie w notacji opartej na logice i teorii zbiorów * Analiza specyfikacji – dowód poprawności, niesprzeczności Minusy "nieformalne": -- sprzeczność -- niejednoznaczność -- niejasność -- niezupełność -- różne poziomy abstrakcji Plusy matematyki: -- Zwięzły i dokładny opis zjawisk, obiektów i rezultatów -- Płynne przejścia pomiędzy etapami tworzenia oprogramowania -- Notacja jest: abstrakcyjna(modelowanie), precyzyjna, umowżliwia weryfikacje poprawności i niesprzeczności Prototypowanie * Demonstracja i ustalenie wymagań * Prototyp może być wykorzystany do szkolenia użytkowników * Testowanie Zalety: -- Wyjaśnienie nieporozumień na linii klient-programista

-- Ustalenie brakujących wymagań -- „Działający” system na wczesnym etapie prac -- Prototyp może być punktem wyjścia do stworzenia specyfikacji systemu Model: Przygotowanie/Poprawa prototypu -> Weryfikacja prototypu przez klienta -> Uzyskanie informacji od klienta -> .. Evolutionary prototyping * Dostarczenie klientowi „działającego” systemu * Rozpoczynamy od najlepiej zrozumiałych wymagań * Nie mamy zadanej pełnej specyfikacji * Stosujemy techniki pozwalające na szybkie iteracje * Ciągłe zmiany często skutkują poważną przebudową systemu –drogie utrzymanie * Potrzebni specjaliści * Taki system nie będzie „żył” długo Throw-away prototyping * Ocena lub uzyskanie wymagań * Zaczynamy od najgorzej zrozumiałych wymagań * Stosowany by zmniejszyć ryzyko błędów związanych z wymaganiami * Prototyp jest: otworzony na podstawie pierwotnej specyfikacji, poddawany testom, i wyrzucany do kosza * Prototyp nie może być produktem finalnym: szczątkowy, jak utrzymać?, kiepsko wykonany RAD Rapid Application Development * Pozwala zbudować system w bardzo krótkim czasie (60-90 dni), często idąc na pewne kompromisy * Zakres projektu: Wąski, precyzyjnie określony, jasne wymagania * Dane: Istnieją lub są zadane częściowo, Projekt dotyczy analizy danych i raportowania * Decyzje: Mała grupa dyspozycyjnych osób * Zespół: Mały, najlepiej liczący do 6 osób * Architektura systemu: Zdefiniowana i jasna, Kluczowe komponenty technologiczne są dostępne i przetestowane * Wymagania techniczne: czas reakcji, wydajność, rozmiar bazy, etc. , Sensowne i adekwatne do architektury(Mniej niż 70% oficjalnie dla technologii) * Struktura procesu stawia na szybkość (listy zadań) * Techniki zarządzania: Prototypowanie, Iteracje, Timeboxing RAD z sukcesem * Niezależna aplikacja * Zbudowana z istniejących komponentów * Wydajność nie jest krytyczna * Wąska dystrybucja (domowa?, verticalmarket) * Niezawodnośćnie jest krytyczna * Używana technologia co najmniej rok istnieje na rynku CBD Component-Based Development - Tworzenie oprogramowania z gotowych komponentów * z różnych źródeł * napisanych w dowolnym języku * działających na różnych platformach * technologia OO Zalety: * Mniejsze koszty * Im częściej używany komponent, tym jest on cenniejszy

* Szybka i niekosztowna personalizacjaaplikacji * Mniej błędów Komponent - Fizyczna i zastępowalna część systemu, która realizuje zestaw interfejsów - Czarna skrzynka posiadająca zewnętrzną specyfikację, która jest niezależna od wewnętrznych mechanizmów Charakterystyka komponentu: * Wewnątrz * Na zewnątrz –usługi, towary * Relacje –in/out (specyfikacja, implementacja, hermetyzacja) * Kontekst Concurrent Developmnet * Szybciej, szybciej, szybciej * Przejście z modelu sekwencyjnego do współbieżnego * Redukcja czasu kosztem zwiększenia złożoności procesu (stąd częste porażki) AOD Aspect-Oriented Development Trudność ze współbieżnością * Większa częstotliwość i liczba wymian informacji pomiędzy fazami projektowymi * Więcej zadań rozpoczyna się z niekompletnymi lub wstępnymi wymaganiami * Sekwencyjne zarządzanie zawodzi Dekompozycja problemu * Funkcjonalna - Obiekty, moduły, procedury, itd * Aspektowa - Dotyczą więcej niż jednego elementu funkcjonalnego, np. synchronizacja, komunikacja - Nie da się tego „czysto” zrobić stosując takie techniki jak OO Cel AOD * Dostarczenie metod i technik umożliwiających funkcjonalną i aspektową dekompozycję problemu * Aspekty „przecinają” komponenty funkcjonalne * Dostarczenie metod i technik umożliwiających złożenie komponentów funkcjonalnych i aspektów w spójną implementację systemu RUP Rational Unified Process * Od początku i na bieżąco rozwiązuj najbardziej ryzykowne kwestie * Koncentruj się na działającym oprogramowaniu -- Plany i projektowanie jest dobre –działające oprogramowanie jest lepsze -- Realizuj tylko niezbędne artefakty * Koncentruj się na potrzebach klienta -- Iteracje -- Przypadki użycia -- Dokumentowanie wymagań jest dobre –realizacja lepsza * Szybko uwzględniaj zmiany * Zacznij od architektury * Buduj z komponentów * Stwórz zespół - Nie buduj zespołów wokół pojedynczych funkcji * Zapewnienie jakości determinuje realizację - Testowanie od początku realizacji Podstawy RUP * Najlepsze praktyki (Best Practices)

* Etapy (Phases) * Dyscypliny (Disciplines) Co daje RUP? * Pomaga w budowie wysokiej jakości oprogramowania * Dostarczonego na czas i w budżecie * Wymaga więcej niż poświęcenie jednostek * Spójna praca zespołu i wspólna wizja zadań (optymalizacja) * Zapewnia przewidywalność i powtarzalność implementacji * Pomaga skoncentrować się na działającym oprogramowaniu * Pozwala na udźwignięcie oraz efektywne adaptowanie nowych technik i narzędzi Agile - Zwinny, zręczny, zwrotny, ruchliwy * Filozofia tworzenia oprogramowania * Najważniejsza satysfakcja klienta, Witamy zmieniające się wymagania, Częste dostarczanie działającego oprogramowania, Menadżerowie i deweloperzy pracują codziennie razem w trakcie całego projektu * Wiele metod: ExtremeProgramming, Scrum, Lean Development, … * Metodologie sterowane planem - Należy rozdzielić projektowanie od wytwarzania/budowy oprogramowania - Płynne przejście od projektu do budowy –UML * Oprogramowanie - Budowa tak tania, że praktycznie darmowa - Cały wysiłek to projektowanie i dlatego wymaga kreatywnych i utalentowanych ludzi * Procesy kreatywne nie dają się zaplanować, a więc nie mogą być przewidywalne * gdy Metody tradycyjnej inżynierii zawodzą przy wytwarzaniu oprogramowania * Cały proces tworzenia oprogramowania bazuje na wymaganiach Metodyki zwinne : XP, SCRUM, Crystal, Lean Development, ASD, DSDM, FDD XP extreme programming: Prostota, Komunikacja, Informacja zwrotna, Gotowość do zmian Whole Team: - Każdy uczestniczący w projekcie jest członkiem zespołu - Zespół tworzony wokół Klienta Planning Game, Small Releases, Customer Tests: - Proste planowanie i śledzenie projektu - Wartość biznesowa przede wszystkim - Małe w pełni zintegrowane wdrażanie - oprogramowania, które przeszło testy Klienta Simple Design, Pair Programming, Test-Driven Development, Refactoring - Praca grupowa i w parach - Prosty projekt - Obsesyjne testowanie - Ciągłe udoskonalanie projektu by spełniał bieżące wymagania Continuous Integration, Collective Code Ownership, Coding Standard - Stale działający i zintegrowany system - Kodowanie w parach - Ciągła współpraca - Ustandaryzowane kodowanie –czytelny kod, można udoskonalać Metaphor, SustainablePace - Wspólny prosty obraz systemu - Każdy pracuje ze stałą nigdy nie słabnącą wydajnością (szybkością)

Zwinna specyfikacja wymagań: * Karty wymagań (UserStories) : Opowiadania użytkownika, oHistoryjki użytkownika * Szkice ekranów * Testy akceptacyjne Karta wymagań * Bardzo ogólne do oszacowania czasu implementacji * Każdy scenariusz jest szacowany przez dewelopera na 1, 2 albo 3 tygodnie „idealnego programowania” - Dłużej niż 3 tygodnie -> trzeba rozbić scenariusz - Mniej niż tydzień -> zbyt niski poziom szczegółowości * 80 +- 20 US= idealna liczba by stworzyć ReleasePlan Spike Solution * Tworzone by rozwiązać problemy techniczne bądź projektowe * Jest to bardzo prosty program do zbadania potencjalnych rozwiązań * Tworzone by: - zredukować ryzyko rozwiązań technicznych - zwiększyć wiarygodność oszacowania UserStory * Throw-away prototyping SCRUM * AGRESYWNE usuwanie przeciwności! * Metodyka zarządzania projektem ( Często stosowana z XP) * Scrumjest wzorcem!!! * Małe zespoły (< 10 people) * Serie sprintów * Rozwój inkrementacyjny * Time-boxing * Koncentracja na zarządzaniu projektem * Mały nacisk na praktyki (Łączenie z praktykami XP) Proces tworzenia: - Zbiór luźno powiązanych czynności łączących znane i działające techniki oraz narzędzia, pozwalający zbudować system - Dwie fazy: -- Planowanie -- Sprint --- Iteracja (2-4 tygodni) --- Częste, krótkie spotkania (Scrum Meetings) --- Zadania przypisane członkom zespołu --- Koncentracja na celu --- Każdy zespół dostarcza widocznego, działającego elementu --- Kolejne iteracje są inkrementacyjne --- Jasno zdefiniowane obowiązki oraz wyniki iteracji WSZYSTKO może zostać zmienione, zakres prac, priorytety Crystal Family * Rozmowy twarzą w twarz zamiast dokumentów * Im częściej dostarczane są małe, działające części systemu, tym pewniejsza pomyślna realizacja systemu * Różne projekty mają różne potrzeby CrystalClear: 2-6 osób ?CrystalYellow: 6-20 osób ?CrystalOrange: 20-40 osób

?CrystalRed: 40-100 osób ?CrystalMagenta, CrystalBlue, etc. ?Przesunięcie wzdłuż osi Y ?przejście z wersji „light” w kierunku „hard” Krytyczne dla zarządzania projektem jest zrozumienie i informowanie o współzależnościach CrystalLightwygląda ciężko przy XP (xp - dyscyplina) Lean Development * Podejście strategiczne, sterowane zasadami - Większość zwinnych jest taktyczna, zorientowana na zespół 1.Najwyższym priorytetem jest satysfakcja klienta 2.Zawsze dostarczaj najlepszą jakość za rozsądną cenę 3.Sukces zależy od aktywnego udziału klienta 4.Dewelopmentto praca zespołowa 5.Wszystko jest zmienne 6.Ogólne, nie specjalistyczne oprogramowanie 7.Buduj z komponentów 8.80% rozwiązania dziś zamiast 100% jutro 9.Kluczowy jest minimalizm 10.Potrzeby definiują technologię 11.Rozwój produktu to rozwój funkcjonalności, nie rozmiaru 12.Nie stosuj LD tam, gdzie można użyć innych metod z większym zyskiem nieformalna 13. 75% sukcesu to czynnik ludzki ?potrzeba zaangażowanych i zadowolonych pracowników ASD Adaptive Software Development * Adaptacja - Szybka odpowiedź na zmiany * the Adaptive Leadership-Collaboration model strategia: - Koncentracja na produkcie, nie na procesie - Duża skala: dostarczenie narzędzi i technik umożliwiających samoorganizację wirtualnym zespołom 1.Koncentracja na misji 2.Nastawienie na rezultat (nie zadanie) 3.Iteracje 4.Time-boxing 5.Sterowanie ryzykiem 6.Adaptacja zmian DSDM Dynamic Systems Development Method * Framework nie metoda - Szkielet procesu i opisy artefaktów - Trzeba dostosować do projektu czy organizacji * Niezbędne jest zaangażowanie klienta/użytkownika * Zespół musi być upoważniony do podejmowania decyzji * Nastawienie na częste krokowe wdrażanie * Podstawą akceptacji rozwiązania jest wartość biznesowa * Iteracyjny i inkrementacyjny rozwój projektu * Wszystkie zmiany w trakcie iteracji są odwracalne * Kluczowe wymagania są stałe * Zintegrowane testowanie * Kluczowa jest współpraca wszystkich członków zespołu

FDD Feature Driven Development * Dobry dla większych zespołów (do 500) * Nacisk na tworzenie oprogramowania dobrej jakości * Częste dostarczanie działających elementów * Włożenie na początku odpowiedniego wysiłku przed rozpoczęciem iteracji * Jasny i oczywisty postęp oraz status projektu * Proces nigdy nie zastąpi dobrych ludzi * Featureslist: Funkcjonalne, Małe, Wartościowe dla klienta * Planowanie zorientowane na wymagania * Dobre dla stabilnych systemów o przewidywalnym kierunku ewolucji Spaghetti code * Określenie pejoratywne * Kod trudny do zrozumienia, utrzymania i poprawy * Kod zawiera wiele instrukcji typu GOTO, wyjątki lub inne „nieustrukturyzowane” instrukcje rozgałęziające wątek kontroli Refaktoryzacja - zmiana organizacji struktury kodu programu nie zmieniająca jego działania * Ulepsza projekt oprogramowania - Często prowizorycznie zmieniamy kod * Łatwiej zrozumieć oprogramowanie - Czytelniejszy kod * Pomaga lokalizować błędy - Czyni strukturę czytelniejszą odkrywając błędy * Pomaga szybciej programować - Co wynika z poprzednich punktów Kiedy refaktoryzować: - Przed dodaniem funkcjonalności - Kiedy trzeba poprawić błędy - W trakcie inspekcji kodu - Jeśli robisz to samo po raz trzeci - Kiedy trafiasz na badsmell Badsmell * Powtarzający się kod * Długa lista parametrów * Instrukcje switch * I mnóstwo innych Jak refaktoryzować: - Rozpoczynasię od zaprojektowania dużej liczby testów dla kodu, który ma być poddany analizie - Identyfikacja problemów – badsmells - Refaktoryzacjai testowanie - Program nie przejdzie testów ?zaczynamy od nowa! Zaczynamy od elementów najbardziej ryzykownych!! Zastosuj Extract Method kiedy istniejące metody są zbyt długie lub istnieją w kodzie powtórzenia - Fragment kodu, który może zostać wydzielony. Uczyń z tego kodu metodę i odpowiednio ją nazwij. * Refaktoryzacjęmożna traktować jak wzorzec * Większość jest odwracalna * Projekt może być ulepszony przez refaktoryzacjęwprowadzającą wzorzec projektowy Pomiar - Czynność, dzięki której można poznać wielkość Miara - Ilościowe wskazanie czy i w jakim stopniu dany produkt lub proces wykazuje analizowaną cechę - Liczba, wymiar, pojemność, rozmiar cechy - Liczba błędów

Metryka - Ilościowa miara stopnia w jakim system, komponent lub proces posiada dany atrybut - Liczba błędów znaleziona przez osobę w ciągu godziny Rodzaje Metryk: -- Miary bezpośrednie -- Koszt i liczba pracowników w projekcie -- Liczba wierszy kodu źródłowego (LOC) -- Miary pośrednie -- Defect density = liczba błędów / rozmiar -- Prognozowanie -- Prognoza wielkości systemu na podstawie pomiaru funkcjonalności –punkty funkcyjne -- nominalne, porzadkowe, przedziałowe, względne, bezwzględne Metryki procesu * Analiza paradygmatów, zadań, punktów milowych * Prowadzi do udoskonalania procesu –udoskonalanie długoterminowe Metryki produktu * Ocena stanu produktu * Uchwycenie potencjalnego ryzyka * Identyfikacja problemów * Dostosowanie "workflowu" oraz/lub zadań * Ocena umiejętności zespołu by zapewnić odpowiednią jakość produktu Linią kodu - nazywamy każdą linię tekstu napisanego programu, która nie jest ani komentarzem ani linią pustą, bezwzględu na liczbę instrukcji w linii. W szczególności są to linie zawierające nagłówki, deklaracje, wykonywalne i niewykonywalne instrukcje programu. Zalety: - Łatwa do obliczenia - Dobrze znana i opisana (przed 1979) - Opiera się na niej wiele modeli prognostycznych Wady: - Zależy od języka programowania - Nie promuje krótkich, dobrze zaprojektowanych programów - Trudno użyć do prognozy –szacowanie LOC przed analizą i projektowaniem PF Punkt funkcyjny - Oblicza się na podstawie ważonej sumy wejść, wyjść, zapytań, modyfikacji tabel oraz interfejsów 1. Liczba wejść użytkownika 2. Liczba wyjść użytkownika 3. Liczba zapytań użytkownika 4. Liczba plików 5. Liczba interfejsów zewnętrznych Współczynnik złożoności Fi, i?{1,…,14} -Ustalany na podstawie odpowiedzi na serię pytań -Każda odpowiedź jest liczbą od 0 (nieistotne/nie dotyczy) do 5 (absolutnie kluczowe) Wykorzystanie PF: - Ocena złożoności realizacji systemów - Audyt projektów - Wybór systemów informatycznych funkcjonujących w przedsiębiorstwie do reinżynierii (wg. koszt utrzymania/FPs) - Szacowanie liczby testów - Ocena jakości pracy i wydajności zespołów ludzkich

- Ocena stopnia zmian, wprowadzanych przez użytkownika na poszczególnych etapach budowy systemu informatycznego - Prognozowanie kosztów pielęgnacji i rozwoju systemów - Porównanie i ocena różnych ofert dostawców oprogramowania pod kątem merytorycznym i kosztowym Pomiary złożoności produktu : Nauka o programach Halsteada, Liczba cyklomatyczna McCabe’a Metryka Halsteada * Bazuje na elementach składniowych programu (operandach i operatorach) Zalety: - Nie wymaga wnikliwej analizy kodu - Prognozuje stopień trudności utrzymania - Pomaga w planowaniu harmonogramu i raportowaniu - Mierzy ogólną jakość programu - Prosta do wyliczenia - Może być użyta dla dowolnego języka programowania - Doświadczalnie wykazano jej przydatność w predykcji wysiłku (programming effort) i oczekiwanej liczby błędów programistycznych Wady: - Zależy od finalnej postaci kodu - Nie nadaje się do wykorzystania na etapie projektowania (modelu) Liczba cyklomatyczna McCabe’a * Oparta na schemacie blokowym programu i liczbie niezależnych przebiegów * Przebiegi reprezentowane są za pomocą diagramu sterującego (grafu) - Węzły reprezentują sekwencyjne bloki kodu - Krawędzie reprezentują możliwe ścieżki, zależne od decyzji * V(G) jest liczbą regionów wyznaczonych przez graf planarny (V(G) nie powinna przekraczać 10) Zalety: - Do mierzenia stopnia trudności pielęgnacji - Miara jakości –porównanie różnych projektów - Może być wcześniej obliczona niż miaraHalsteada - Prosta do wyliczenia Wady: - Mierzy złożoność wątków kontroli, a nie złożoność danych - Pętle zagnieżdżone mają tą samą miarę, co nie zagnieżdżone -- oZagnieżdżone struktury warunkowe są trudniejsze do zrozumienia - Może dawać mylne wyobrażenia dotyczące prostych porównań i struktur warunkowych Przyczyny różnic pomiędzy metrykami OIO, a IO: - Lokalizacja - Enkapsulacja - Ukrywanie informacji - Dziedziczenie - Obiektowe techniki abstrakcyjne GQM Goal Question Metric * Generate a set of goals * Derive a set of questions * Develop a set of metrics

Uwagi do metryk: * Stosowanie tylko jednej metryki jest mało przydatne * Najlepszy zestaw metryk nie musi być od razu znany * Docelowo najlepiej korzystać z 3 -5 dobrze przemyślanych metryk * Metryki są prawie zawsze ze sobą powiązane * Metryki powinny być stosowane w sposób regularny, w miarę możliwości automatyczny * Wykorzystywane metryki NIEmogą wpływać na mierzony element * Warto liczyć średnią wartość metryki dla całego elementu i badać lokalne odchylenia * Metryki mogą być SZKODLIWE... tylko wtedy gdy je ŹLE STOSUJEMY Analiza statyczna - inspekcje kodu (Praca z kodem źródłowym) - Specyfikacja wymagań -> prototyp - Projekt architektury systemu - Specyfikacja formalna - Projekt szczegółowy - Program Analiza dynamiczna – testowanie oprogramowania (Eksperymentowanie z działającym kodem programu) - Prototyp - Program Całkowita (pełna) weryfikacja i walidacja - Testowanie - Statyczna weryfikacja Testowanie to jedyna technika walidacji wymagań niefunkcjonalnych Testowanie polega na uruchamianiu programu w celu wykrycia błędów Testowanie jednostkowe - Pojedynczych funkcji lub innych fragmentów kodu w oderwaniu od reszty systemu * FUNKCJONALNE, WYDAJNOŚCIOWE Testowanie integracyjne - Przetestowane jednostki kodu są stopniowo łączone w większą całość, a następnie ponownie testowane już jako grupa jednostek, proces łączenia i testowania jest powtarzany aż do powstania całego systemu * FUNKCJONALNE, WYDAJNOŚCIOWE, REGRESYWNE Testowanie systemowe - Czy system jako całość spełnia wymagania funkcjonalne i jakościowe postawione przez klienta * FUNKCJONALNE, WYDAJNOŚCIOWE, REGRESYWNE, BEZPIECZEŃSTWA, INSTALACYJNE, ITERFEJSU Testy akceptacyjne - Testy w środowisku docelowym * FUNKCJONALNE, WYDAJNOŚCIOWE, BEZPIECZEŃSTWA Typy testów: - funkcjonalne (co robi?) - niefunkcjonalne (jak działa?) - strukturalne (jaka jest architektura?)

- regresywne (czy nadal działa ?) Metoda białej skrzynki - logiczna struktura programów * Metoda szklanej skrzynki, testowanie strukturalne * Projektowanie testów na podstawie logicznej struktury algorytmu - Wszystkie niezależne ścieżki przepływu - Wszystkie możliwe kombinacje decyzji logicznych - Jedno i wielokrotne wykonanie pętli z uwzględnieniem warunków brzegowych Po co? - Literówki są rozmieszczone losowo - Liczba błędów logicznych i błędnych założeń jest odwrotnie proporcjonalna do częstości wykonywania danego fragmentu kodu - To, co w założeniu miało być rzadko, w rzeczywistości jest bardzo często wykonywane Gruntowne testowanie - Identyfikacja wszystkich ścieżek logicznych - Sprawdzenie działania każdej z nich - Ocena ich poprawności Pokrycie kody - Pokrycie instrukcji (ang. statement coverage) - Każda instrukcja jest sprawdzana - Pokrycie gałęzi (ang. branch coverage) - Każda gałąź była odwiedzona - Instrukcja warunkowa musi być przynajmniej raz prawdziwa i przynajmniej raz fałszywa 100% NIE ZAWSZE JEST MOŻLIWE Metoda czarnej skrzynki - Badanie interfejsów, funkcjonalności * Testowanie zachowania (behawioralne), funkcjonalne * Badanie interfejsów * Nie zwracamy uwagi na wewnętrzną strukturę logiczną * Stosuje się pod koniec testowania * Pomija się strukturę sterowania * Koncentracja na dziedzinie informacyjnej * Umożliwia przygotowanie testów, które: - Zmniejszają (>1) liczbę dodatkowych testów koniecznych do przetestowania programu - Mogą wykryć lub wykluczyć całe grupy błędów jednocześnie Testowanie ma na celu wykrycie błędów Debugowanie ma na celu lokalizację i poprawę błędów TDD Test-driven development - technika tworzenia oprogramowania, zaliczana do metodyk zwinnych. Polega na wielokrotnym powtarzaniu kilku kroków 1. Najpierw programista pisze automatyczny test sprawdzający dodawaną funkcjonalność. Test w tym momencie nie powinien się udać. 2. Później następuje implementacja funkcjonalności. W tym momencie wcześniej napisany test powinien się udać. 3. W ostatnim kroku programista dokonuje refaktoryzacji napisanego kodu, żeby spełniał on oczekiwane standardy. Zalety: - Natychmiastowa informacja zwrotna

- Lepsza dekompozycja realizacji projektu - Aktualne testy –określony poziom jakości kodu - Lepsza dekompozycja problemu - Wyższa jakość i produktywność Wady: - Tylko dla doświadczonych programistów - Pisanie testów do nieistniejącej implementacji - Wymaga dużej samodyscypliny - Najpierw test potem funkcjonalność - Wydłuża proces tworzenia oprogramowania - Dużo czasu na testy CI Continous Integration * Testowanie każdej zmiany w systemie * Dedykowane narzędzia zintegrowane z: Repozytorium kodu źródłowego, Systemem raportowym * Natychmiastowe wykrycie błędów Praktyki CI - Jedno repozytorium kodu - Automatyzacja budowy - Testowanie jako część automatycznej budowy (samo-testowanie się) - Wszyscy codziennie aktualizują źródła - Zmiana w repozytorium kodu wyzwala proces integracji - Szybka budowa aplikacji (~10min XP) - Środowisko testowe sklonowanym środowiskiem produkcyjnym - Wszyscy widzą co się dzieje Zalety CI: - Zmniejszenie ryzyka - Nie odsuwa w czasie integracji i nie agreguje testowanie - Ułatwia znalezienie i usunięcie błędów - Umożliwia szybkie wdrażanie Maven Koncepcji Obiektowego Modelu Projektu, Automatyzacja budowy oprogramowania SRC Selenium Remote Control * Testy funkcjonalne oprogramowania, którego interfejs dostępowy stanowi przeglądarka internetowa * Testowanie systemu w sposób dynamiczny - Symulacja klikającego użytkownika Hudson - Serwer ciągłej integracji Openfire server - Serwer natychmiastowej komunikacji Programowanie proceduralne * Paradygmat programowania zalecający dzielenie kodu na procedury, czyli fragmenty wykonujące ściśle określone operacje * Procedury nie powinny korzystać ze zmiennych globalnych (w miarę możliwości), lecz pobierać i przekazywać wszystkie dane (czy też wskaźniki do nich) jako parametry wywołania Programowanie Strukturalne * Paradygmat programowania zalecający hierarchiczne dzielenie kodu na moduły, które komunikują się jedynie poprzez dobrze określone interfejsy * Rozszerzenie koncepcji programowania proceduralnego * Pewna poddyscyplinaprogramowania proceduralnego * Algorytmy są reprezentowane przy pomocy ograniczonego zestawu konstrukcji logicznych

* Jego istotą jest umożliwienie projektantom tworzenia mniej złożonych algorytmów, które łatwiej: czytać, testować, pielęgnować - SEKWENCJA - WARUNEK - POWTÓRZENIE Dlaczego ograniczenia ? - By ograniczyć swobodę projektowania procedur do niewielkiej liczby przewidywalnych operacji - Programy tak napisane są mniej złożone - Łatwiej czytać, testować, pielęgnować - Każdy program można zapisać przy pomocy wyłącznie tych instrukcji! Ścisłe przestrzeganie reguł prowadzi do niedoskonałych rozwiązań - Co zrobić ? -> Zmienić algorytm -> W kontrolowany sposób złamać zasadę konstrukcji strukturalnych i zaprojektować przepływ sterowania z wnętrza pętli na zewnątrz Diagramy ramkowe * Nie można nimi opisać programów łamiących zasady programowania strukturalnego * Diagramy ramkowe (Boxdiagrams): Schematy Nassiego-Shneidermana, Schematy N-S, Diagramy Chapina * Dobrze określona i widoczna dziedzina funkcjonalna * Nie da się opisać dowolnego rodzaju przepływu sterowania * Łatwo określić zasięg widoczności lokalnych i globalnych danych * Łatwo opisać rekurencję Tablicowa notacja projetkowa * Dodatkowy opis projektowanych procedur * Służą do opisywania kombinacji warunków i czynności, które na ich podstawie należy wykonać Analiza strukturalna * Zestaw metod do modelowania oprogramowania * Tworzenie modeli - danych, funkcji, zachowań systemu * Słownik danych - oOpisy wszystkich obiektów danych pobieranych i tworzonych przez modelowany system * Diagram encja-związek (diagram związków encji) - Entity-Relationshi Diagram (ERD) - Zależności między obiektami danych * Diagram przepływu danych - Data FlowDiagram (DFD) - Opisuje sposób przetwarzania danych - Przedstawia procedury przetwarzające dane * Diagram przejść - State TransitionDiagram (STD) - Opisuje zachowanie systemu w zależności od zachodzących zdarzeń Struktura modelu analitycznego - Słownik danych - opis obiektu danych ERD - specyfikacja przeływu danych sterowania STD - specyfikacja procedury DFD

Modelowanie danych * Opisuje związane ze sobą informacje: Obiekty danych (encje), atrybuty, związki Encja - pojęcie bazowe (niedefiniowalne); podstawową cechą encji jest to, że jest rozróżnialna od innych encji Obiekt danych - Złożony element informacji - ma kilka atrybutów np rozmiar, długość * Wyłącznie dane bez opisu operacji przetwarzania tych danych * Obiekt danych można opisać w postaci tabeli ERD Entity-Relationshi Diagram , relacyjne bazy danych * Przedstawia obiekty danych oraz związk i pomiędzy nimi * Ujęcie statyczne DFD Data Flow Diagrams diagramy przepływu danych * Rozszerzenia DFD dla systemów czasu rzeczywistego * Przez wielu twórców systemów są one traktowane jako synonim podejścia strukturalnego * Graficzna prezentacja przepływu danych w procesie * Na proces składają się następujące elementy: - Funkcje (procesy) - Realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej - Magazyny danych - Trwałe lub tymczasowe składnice danych, argumenty dla funkcji - Terminatory - Obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji; elementy zewnętrzne - Przepływy - Elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..) * Opisują system na dowolnym poziomie szczegółowości * Ciągłość przepływu informacji - Dane wchodzące i wychodzące z każdego procesu nie mogą się zmienić po rozbiciu na podprocesy (zasada równoważenia) * Stopień złożoności systemu - Prosty: od 2 do 3 poziomów - Średnio złożony: od 3 do 5 poziomów - System złożony: powyżej 5 poziomów * Nie wystarczają do opisu wymagań - Brak np. informacji o zawartości i strukturze przekazywanych informacji * DFD należy uzupełnić tekstowym opisem elementów (Mówi co, ale nie mówi jak!) - Specyfikacje procesów * Nie odwzorowuje zależności czasowych * Zawiera zarówno ręczne, jak i zautomatyzowane procesy * Rozszerzenia dla systemów czasu rzeczywistego - Ciągły i dyskretny przepływ - Przepływ sterowania i procesy sterujące - Wątki Modelowanie zachowań - diagramy stanów * Jest to skierowany graf stanów (węzły) połączonych tranzycjami(skierowane krawędzie)