1.Przedmiot badań inżynierii oprogramowania.

Inżynieria oprogramowania to dziedzina inżynierii systemów zajmująca się wszelkimi aspektami produkcji oprogramowania: od analizy i określenia wymagań, przez projektowanie i wdrożenie, aż do ewolucji gotowego oprogramowania. Podczas gdy informatyka zajmuje się teoretycznymi aspektami produkcji oprogramowania, inżynieria oprogramowania koncentruje się na stronie praktycznej.

Inżynieria oprogramowania” (ang. Software Engineering): Przedmiot obejmuje następujące jednostki wiedzy z zakresu inżynierii oprogramowania tj.: projektowanie oprogramowania; procesy wytwarzania oprogramowania; wymagania i ich specyfikacja; walidacja i testowanie oprogramowania; ewolucja oprogramowania; zarządzanie przedsięwzięciem programistycznym.

Inżynieria oprogramowania jest to zastosowanie systematycznego, zdyscyplinowanego, ilościowego podejścia do rozwoju, eksploatacji i utrzymania oprogramowania.

2. Definiowanie i zarządzanie wymaganiami (w postaci use case'ów).

Wymagania funkcjonalne - funkcje wspomagane przez ograniczenia- przypadki użycia (use cases)

(?) Zarządzanie wymaganiami: -zarządzanie zmianami (błędy nieporozumienia zmiany w otoczeniu); -zarządzanie powiązań pomiędzy wymaganiami; -zarządzanie powiązań pomiędzy wymaganiami a innymi artefaktami przedsięwzięcia (zapewnienie realizacji wymagań, ocena kosztów proponowanych zmian)

(?)Zasady zarządzania wymaganiami:

-cele zarządzania wymaganiami, standardy i procedury postępowania, część systemu zapewniania jakości firmy; - zasady mówią co należy zrobić, standardy i procedury mówią jak to zrobić w konkretnych sytuacjach

(?) Elementy zasad zarządzania wymaganiami:

-cele i ich uzasadnienie; -niezbędne raporty i standardy; -zasady zarządzania zmianami i kontroli realizacji wymagań, -zasady przeglądów; - zasady sledzenia powiązań, - warunki w których te zasady mogą zostać zaniechane.

Tworzenie przypadków użycia (ang. use case) to technika stosowana w inżynierii oprogramowania w celu opisania wymagań tworzonego systemu informatycznego. Przypadek użycia przedstawia interakcję pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem jako sekwencję prostych kroków.

Przypadek użycia powinien: opisywać w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu; być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika; opisywać system na właściwym poziomie szczegółowości.

Poziom szczegółowości: wyróżnia się 3 poziomy szczegółowości przypadków użycia: 1.nieformalny opis - kilka luźnych zdań ogólnie opisujących przypadek; 2.formalny opis - kilka paragrafów, podsumowanie. 3. pełen opis - formalny dokument

Nazewnictwo: Zaleca się, aby przypadki użycia posiadały nazwy odpowiadające czynnościom, które opisują. Często zaleca się stosowanie wyrażeń rozpoczynających się od czasownika w formie trybu rozkazującego. Przykładowe nazwy to: "Zarejestruj użytkownika", "Sprawdź stan konta".

Use case to przypadki użycia. Przypadek użycia jest opisem interakcji pomiędzy użytkownikiem, a systemem informatycznym. Mogą one występować w różnych formach. Najprostsza to akapit tekstu pisany językiem naturalnym. Bardziej powszechna jest jednak postać strukturalna. Każdy przypadek użycia w tej formie składa się z następujących elementów: Nazwa - wyraża cel przypadku użycia (np. wystawianie faktury, zamówienie książki, dodanie wpisu na forum)

identyfikator - unikalny w obrębie danej specyfikacji wymagań, przydaje się podczas dyskusji na temat wymagań - do odwoływania się do poszczególnych elementów.

Główny scenariusz - sekwencja kroków, która musi zostać wykonana do osiągnięcia celu przypadku użycia (wyrażonego w nazwie). Opisuje najczęstszy przebieg interakcji pomiędzy głównym aktorem, a systemem.

Dodatkowo, do każdego wymagania możemy dołączyć listę atrybutów, np. nazwę głównego aktora - użytkownika, który gra główną rolę w danym przypadku użycia; priorytet tego wymagania z punktu widzenia klienta; źródło wymagania - osoba, od której pochodzi konkretne wymaganie - taka informacja przydaje się później, kiedy programiści będą mieli jakieś wątpliwości i dodatkowe pytania ,będą w stanie trafić bezpośrednio do osoby najlepiej poinformowanej.

Diagram przypadków użycia w języku UML, to diagram służący do modelowania funkcjonalności systemu. Tworzony jest zazwyczaj w początkowych fazach modelowania. Diagram ten stanowi tylko przegląd możliwych działań w systemie, szczegóły ich przebiegu są modelowane za pomocą innych technik (np. diagramów stanu lub aktywności).

3.Modelowanie w UML.

UML jest wykorzystywany m.in. przy projektowaniu systemów informatycznych. Jest też wiele narzędzi komercyjnych i darmowych wspomagających tworzenie modeli w języku UML (wśród narzędzi komercyjnych dużą popularnością cieszy się Rational Rose, a jednym z bardziej popularnych darmowych narzędzi jest ArgoUML).

Diagramy w UML: Język UML obejmuje wiele różnego typu diagramów, które pozwalają w sposób graficzny modelować różne aspekty systemów informatycznych (i nie tylko informatycznych). Tytułem wprowadzenia do języka UML przedstawione zostaną bardzo proste przykłady diagramu stanów, diagramu przypadków użycia i diagramu sekwencji. Zarówno te wymienione diagramy, jak i pozostałe zostaną bardziej szczegółowo omówione w trakcie wykładu poświęconego językowi UML.

(!!!!! - dok)

4. Projektowanie oprogramowania, wzorce projektowe.

(!!!!! - dok)

5.Zasady tworzenia testów, testy jednostkowe.

Plan testów oprogramowania: 1. proces testowania. 2. śledzenie wymagań 3. Testowane elementy 4.Harmnogram testów 5. Procedury nagrywania testów 6. Wymagania odnośnie sprzętu i oprogramowania 7. Ogranicznia.

Dokument planu testów powinien zawierać opis procesu testowania, czyli w jaki sposób będzie przeprowadzany, oraz kto będzie za niego odpowiedzialny. Plan testów oprogramowania powinien być tak skonstruowany by móc umożliwić śledzenie wymagań. W przypadku gdy dane wymaganie ulegnie zmianie, będzie można zaktualizować także plan co zmniejszy szansę pomyłki podczas weryfikacji i walidacji systemu. Wszystkie testy powinny być powiązane z wymaganiami użytkownika. Nie warto testować cech systemu, o których nie ma żadnej informacji w jego specyfikacji. Oczywiście plan nie może obyć się bez harmonogramu. Powinno być w nim zawarte co i kiedy jest testowane oraz kto ma to przeprowadzić. W planie testów powinno być też opisane środowisko testowe, na jakim sprzęcie wykonane zostanie uruchomienie systemu, oraz z jakiego systemu operacyjnego i innego oprogramowania system ma korzystać.

Metody tworzenia testów: 1. Metoda białej skrzynki (ang. white-box testing) - sprawdza wewnętrzną strukturę programu, - testy jednostkowe, - testy integracyjne. 2. Metoda białej skrzynki (ang. black box testing) - nie bierze pod uwagę wewnętrznej struktury programu, wszystkie rodzaje testowania.

Przy przygotowywaniu wariantów testu stosowane są generalnie dwie techniki: metoda białej skrzynki oraz metoda czarnej skrzynki. Metoda białej skrzynki opiera się na analizie kodu, który ma być testowany. Sprawdzana jest jego wewnętrzna struktura. Na podstawie tych informacji konstruowane są przypadki testowe. Niestety wykorzystując tylko tą metodę łatwo jest pominąć pewne przypadki testowe, gdyż analiza samego kodu nie poda nie zaimplementowanych wariantów zachowania systemu. Ta metoda nadaje się do testów jednostkowych, oraz integracyjnych, dla których znajomość kodu źródłowego jest konieczna.

Testowanie metodą czarnej skrzynki nazywane też inaczej testowaniem funkcjonalnym opiera się na analizie powinności testowanego systemu np. na podstawie specyfikacji wymagań. W ten sposób nie pominie się testowania istotnych zachowań systemu. Ta metoda nadaje się do wszystkich rodzajów testowania, jednak nie wyklucza stosowania metody białej skrzynki. Ze względu na duży koszt związany z testowaniem metodą czarnej skrzynki stosuje się obie metody. Testowanie metodą białej skrzynki wykorzystywane jest wszędzie tam gdzie testy wykonane metodą czarnej skrzynki są zbyt kosztowne. W pozostałych przypadkach testy tworzone są w oparciu o powinności systemu.

Testowanie oprogramowania jest wykonaniem kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów. Celem testów jest wykrycie błędów. Testy projektuje się, analizując testowany system i rozstrzygając, do jakiego stopnia jest on obciążony ryzykiem błędów. Zaprojektowane testy następnie wykonuje się ręcznie lub poddaje automatyzacji, czyli napisaniu oprogramowania, które wypróbowuje inny system oprogramowania w celu znalezienia błędu. Uzyskane wyniki analizuje się i określa czy test wykrył błąd, czy też było to prawidłowe zachowanie systemu. Test uznaje się za udany jeśli wykryje nie znaleziony jeszcze błąd. Mówi się, że test jest efektywny jeśli znajduje błędy z maksymalnym prawdopodobieństwem.

Testowanie polega na wykonaniu kodu dla kombinacji danych wejściowych i stanów w celu wykrycia błędów, jest to technika dynamiczna - wymaga uruchomienia systemu (lub jego fragmentu), a jej cel to wykazanie, że system zawiera błędy.

W ramach projektowania testu wyodrębnia się i analizuje powinności testowanego systemu. Następnie projektuje się warianty testu. Na wariant testu zwany inaczej przypadkiem testowym składają się następujące elementy: -stan wstępny, czyli stan testowanego systemu bądź jego fragmentu jaki występuje tuż przed testem ; -dane wejściowe lub warunki testu ; -oczekiwane wyniki. Wynik oczekiwany określa, co testowana implementacja powinna wyprodukować z danych testowych. Natomiast rzeczywiste wyjście, czyli wynik wykonania testu na testowanej implementacji (systemie lub jego fragmencie) nazywany jest zaobserwowanym wyjściem.

Rodzaje testów: 1.jednostkowe; 2. integracyjne; 3. systemowe; 4. akceptacyjne. (Testy można podzielić ze względu na przedmiot testowania. Standard IEEE 610.12 z roku 1990 definiuje testy jednostkowe, integracyjne oraz systemowe.)

Testy jednostkowe - wykonuje programista w środowisku laboratoryjnym. Celem tych testów jest sprawdzenie pojedynczej jednostki oprogramowania jaką jest klasa, metoda, czy też zbiór współpracujących ze sobą klas (tzw. klaster klas).

Testy integracyjne-podczas integracji przeprowadzane są testy integracyjne. Ich zadaniem jest sprawdzenie łączonych fragmentów kodu. Weryfikowana jest współpraca integrowanych jednostek między sobą. Celem jest określenie czy po zintegrowaniu otrzymany podsystem nadaje się do dalszego testowania.

Testy systemowe - wykonywane są po pomyślnej integracji jednostek wchodzących w skład systemu będącego przedmiotem testowania. Wykonywane są przez programistów lub niezależny zespół w kontrolowanym środowisku laboratoryjnym. Sprawdzają one czy system jako całość spełnia wymagania funkcjonalne i jakościowe postawione przez klienta.

Testy akceptacyjne - Przetestowany system trafia następnie do użytkowników końcowych (klienta), gdzie następnie poddawany jest kolejnym testom. Tym razem to użytkownik lub reprezentant klienta sprawdza system. Testy przeprowadzane są w środowisku docelowym lub jak najbardziej zbliżonym do niego. Sprawdzane jest czy system spełnia oczekiwania klienta.

6. Dokumentowanie oprogramowania.

W fazie tej tworzona jest dokumentacja użytkownika, którą należy traktować jako integralną składową końcowego produktu. To co sprawia, że tworzenie dokumentacji jest trudne, to fakt istnienia różnych klas odbiorców. Dokumentacja musi być skierowana do wszystkich klas odbiorców, a każda z tych klas ma nieco inne wymagania.

Odbiorcy dokumentacji: osoby oceniające oprogramowanie; użytkownicy końcowi ;

początkujący ; zaawansowani ; sporadyczni ; administratorzy systemu.

Składowe dokumentacji użytkowej: -Opis funkcjonalny (w miarę krótki opis przeznaczenia systemu, do kogo jest kierowany, realny opis możliwości oprogramowania) ;

-Podręcznik użytkownika, zawierający podstawowe wiadomości o: sposobach uruchamiania oraz kończenia pracy z systemem, sposobach realizacji najczęściej wykorzystywanych funkcji systemu, metodach obsługi błędów, np. o sposobach odwoływania błędnych operacji wykonanych przez użytkownika, sposobach korzystania z systemu pomocy.

Podręcznik użytkownika nie musi opisywać wszystkiego, powinien koncentrować się na rzeczach podstawowych oraz przedstawiać prosty przykład(y) korzystania z systemu: • Kompletny opis: szczegółowy opis wszystkich funkcji systemu,; informacje o wszystkich sposobach wywoływania tych funkcji ; opisy formatów danych ; opisy wszystkich błędów, które mogą się pojawiać podczas pracy z systemem ; informacje o wszelkich ograniczeniach dotyczących np. zakresów danych. ; Opis instalacji (instalacja, konfiguracja) ; Podręcznik administratora systemu (zarządzanie i pielęgnacja) ; Dwie ostatnie pozycje dokumentacji są przeznaczone raczej dla administratorów systemu. Dodatkowo: słownik używanych terminów i indeks (ułatwiający wyszukiwanie potrzebnej informacji).

Dokumentacja użytkowa obejmuje także opisy systemu dostępne w formie elektronicznej w trakcie korzystania z systemu: - kompletny opis ; programy przewodniki (bardziej przypominające podręcznik użytkownika). Dokumentacja musi być dobrej jakości - kompletna i czytelna.

Jakość dokumentacji: Struktura ; zachowanie standardów ; sposób pisania

Sposób pisania: Stosowanie formy aktywnej oraz zwracanie się bezpośrednio do czytelnika ;

Poprawność gramatyczna i ortograficzna ; Krótkie zdania ; Krótkie akapity; Oszczędność słów ; Precyzyjna definicja używanych terminów ; Powtarzanie trudnego opisu ; Stosowanie tytułów i podtytułów sekcji, wyliczeń i wyróżnień ; Zrozumiałe odwołania do inny rozdziałów (tytułami a nie tylko numerami) ; Wyróżnianie fragmentów o różnym poziomie trudności .

Podsumowanie fazy dokumentacjiKluczowe czynniki sukcesu:

• wysoka jakość definicji wymagań, modelu i projektu,

• uwzględnienie różnego stopnia zaawansowania użytkowników.

Podstawowe rezultaty fazy dokumentacji : Wynikiem fazy dokumentacji jest dokumentacja użytkowa w formie drukowanej i elektronicznej. W trakcie prac nad dokumentacją użytkową często wykrywane są też błędy i nieścisłości w definicji wymagań, modelu i projekcie.

7.Zarządanie konfiguracją (CVS, SVN)

CVS: działa w architekturze klient-serwer. Centralne repozytorium projektu znajduje się na serwerze, a wszyscy członkowie zespołu rozprowadzają swoje zmiany jedynie poprzez repozytorium. Nie ma zatem potrzeby przenoszenia artefaktów pomiędzy osobami w postaci dyskietek, płyt, emaili, itp.

Operacje typu CVS: - pobieranie artefaktów, - wysyłanie zmian, -aktualizacja, - nadawanie etykiet, -rozgałęzianie/łączenie gałęzi.

CVS (ang. Concurrent Versions System)-to popularny system kontroli wersji udostępniany na licencji GPL. Został stworzony do pracy grupowej nad kodem programów lub innych projektów realizowanych w zapisie elektronicznym. CVS zbudowany jest w architekturze klient/serwer.Od początku lat 90. XX wieku CVS jest wykorzystywany jako narzędzie pracy grupowej w wielu projektach programistycznych, których współpraca opiera się na wykorzystaniu Internetu - m.in. całe systemy operacyjne jak FreeBSD czy NetBSD, oraz wielu mniejszych przedsięwzięciach.

O CVS:  podczas rozproszonej pracy wielu osób nad projektem informatycznym pojawia się wiele problemów związanych z zarządzaniem konfiguracją: problemy z rozprowadzeniem zmian, ze scaleniem zmian z różnych miejsc w jedno, z jednoczesną pracą wielu osób nad jednym plikiem.  można je rozwiązać stosując odpowiednie narzędzia zarządzania konfiguracją oprogramowania (np. repozytoria CVS)  użytkownik narzędzia musi znać podstawowe komendy systemu, umożliwiające współpracę z repozytorium (checkout, update, commit, branch, merge), oraz pewne procedury pozwalające na zapanowanie nad dużą liczbą zmian/wersji w projektach informatycznych. Są to wzorce zarządzania konfiguracją, z których część została przedstawiona w trakcie tego wykładu

SVN (Subversion) - to system kontroli wersji, który powstał w celu zastąpienia CVS. Funkcjonalnie jest z nim zgodny w większości przypadków, z kompatybilności zrezygnowano tylko tam, gdzie było to niezbędne. Zmiany w stosunku do CVS-Brak historii wprowadzanych zmian nazw katalogów był jedną z najczęściej krytykowanych wad CVS. Subversion zapisuje nie tylko zawartość pliku oraz informacje czy dany plik istnieje, ale także położenie pliku w katalogach, jego kopie, zmiany nazw. Pozwala również zapamiętywać właściwości danego pliku lub katalogu np. flagi wykonywalności itp. Subversion umożliwia dostęp do repozytorium przez dedykowany serwer, niezależny od serwera http. Jest on uruchamiany jako usługa inetd, lub oddzielny demon. Oferuje on podstawowe uwierzytelnianie i autoryzację użytkowników. Umożliwia także utworzenia połączeń szyfrowanych. W odróżnieniu do CVS gdzie dodawanie gałęzi (branches) i znaczników (tags) z powodu organizacji mogło być czasochłonne, w SVN operacje te bazują na szybkim kopiowaniu - kopie zajmują małą, stałą przestrzeń. Subversion zaprojektowano w architekturze klient-serwer. W celu ominięcia niektórych problemów CVS kod został podzielony na moduły. Aplikacje zewnętrzne mogą się z nimi komunikować za pomocą dobrze opisanych interfejsów. Pozostałe funkcje: Własny protokół klient/serwer; Protokół umożliwia przesyłanie różnic w plikach od klienta do serwera i odwrotnie; rozmiar przesyłanych danych przy zmianie pliku jest proporcjonalny do rozmiaru zmian, a nie pliku;Efektywna obsługa plików binarnych; Licencja Open Source typu Apache; Repozytorium przechowywane w bazie danych lub w systemie plików.

8. Zarządzanie projektem: szacowanie czasu i złożoności oprogramowania

(COCOMO II, punkty funkcyjne, Wideband-Delphi)

COCOMO II -Model algorytmiczny: (ang. Constructive Cost Model) - Model szacowania liczby osobogodzin w procesie tworzenia oprogramowania. Został opracowany przez Barry'ego Boehm'a na podstawie ok. 60 projektów informatycznych o róznej złożoności (od 2KLOC do 100KLOC) i napisanych w różnych językach programowania. KLOC (thousands of lines of code) - tysiące linii kodu (zwykle mierzony jako źródłowy). Jednostka miary rozmiaru programu komputerowego, może też określać ile czasu, lub ilu ludzi potrzeba , by ten program napisać. PM_NS = 2.94 Ⴔ Size^E Size w KSLOC gdzie E = 0.91 + 0.01 Ⴔ ქ_i=1⁵ SF_i

Czynniki skali: Typowość, Elastyczność, Zarz. Ryzykiem, Spójność zespołu, Dojrzałość proc. COCOMO I-ulepszono w 1981 przez Boehm'a, bazowała na niewielkiej liczbie przedsięwzięć; COCOMOII pojawiło się w 1998

Punkty funkcyjne: -miara rozmiaru oprogramowania i złożoności, niezależna od języka programowania (im wyższego poziomu jest język tym mniej linii kodu odpowiada punktowi funkcyjnemu) ; - obliczanie na podstawie specyfikacji wymagań. Metoda powstała z punktu programowania przetwarzania oprogramowania.

Wideband-Delphi- (Metoda delficka) jest jedną z heurystycznych metod podejmowania decyzji, opartą na skojarzeniach wymuszonych. Stosuje się ją do przewidywania przyszłości, określenia prawdopodobieństwa zaistnienia zdarzeń oraz wyznaczenia szacunkowych wartości niektórych wielkości. Sprowadza się do przeprowadzania ankiet wśród grupy ekspertów danej dziedziny, w których odpowiadają oni na pytania dotyczące przyszłości, podają też uzasadnienie dla swoich odpowiedzi. W następnej fazie, przy zachowaniu anonimowości autorstwa, są one wzajemnie konfrontowane tak, by eksperci wypracowali względnie zgodne stanowisko. Jednocześnie wzrasta szczegółowość zadawanych pytań.    Podstawą metody jest stworzenie elastycznych ram służących grupowemu procesowi komunikacji. Struktura taka, angażująca moderatora, opowiadającego za przebieg dyskusji, oraz recenzentów, obejmuje kolejno kroki:Rozpoznanie i zdefiniowanie problemu; Identyfikację i opracowanie celów, które mają zostać osiągnięte poprzez rozwiązanie danego zagadnienia; Określenie strategii tworzenia możliwych rozwiązań; Wybór strategii; Stworzenie kryterium oceny znalezionych rozwiązań; Ocenę kryterium; Wypracowanie rozwiązań; Ocenę rozwiązań. Ocena wypracowanych rozwiązań jest realizowana w sposób anonimowy, podczas gdy pozostałe etapy mają charakter jawny. Do pozostałych cech charakterystycznych metody delfickiej należą: brak bezpośredniej presji oraz uwzględnianie wielu aspektów danego problemu. Wymienione zalety metody delfickiej sprawiają, iż doskonale nadaje się ona jako dopełnienie procesu planowania.

9. Metody zapewniania jakości: przeglądy

Zgodnie ze standardem IEEE 1028 przegląd (po angielsku „review”) jest to proces lub spotkanie, w trakcie którego artefakt związany z oprogramowaniem (np. kod) jest prezentowany różnym osobom w celu skomentowania lub uzyskania jego zatwierdzenia. Inaczej mówiąc, przegląd jest to ocena artefaktu (np. kodu lub specyfikacji) realizowana przez grupę osób.

Inspekcja (po angielsku „inspection”) jest to wizualne sprawdzenie artefaktu celem wykrycia lub zidentyfikowania anomalii dotyczących oprogramowania. Inspekcje są przeprowadzane przez osoby z tego samego szczebla zarzadzania (szefowie nie biorą w nich udziału), a prowadza je specjalnie przeszkoleni (niezależni) moderatorzy (po angielsku „facilitators” lub „Inspection leaders”).

Przeglądy i inspekcje spełniają dwie funkcje: z jednej strony służą zapewnieniu jakości, a z drugiej są sposobem przekazywania informacji o tworzonym oprogramowaniu. Jeśli nawet ktoś nie tworzył danego modułu, ale brał udział w jego inspekcji, to na pewno będzie więcej wiedział na temat tego modułu niż ktoś, kto w ogóle nie miał styczności z tym modułem. Podobnie jest z inspekcją specyfikacji. Ponadto, jeśli programista w trakcie inspekcji specyfikacji nie wykrył jakiegoś błędu, to później z większym zrozumieniem odniesie się do tego błędu, gdy go wykryje na etapie np. kodowania.

(?)Zapewnianie jakości w przypadku metodyk tradycyjnych: po pierwsze - XP stawia na prostotę rozwiązań (optymalizować kod należy tylko wtedy, gdy jest to konieczne) ; po drugie - przed rozpoczęciem kodowania należy przygotować przypadki testowe (ang. test-first-coding) ; tak przygotowane testy są następnie jak najczęściej wykonywane automatycznie - dzięki czemu na bieżąco wychwytywane są błędy ; do poprawy czytelności kodu stosuje się refaktoryzację . [refaktoryzacja to sposób na systematyczną poprawę jakości kodu i ewolucję architektury produktu.]

Kilka kolejnych zasad związanych z zapewnieniem jakości: Zanim udostępni się zmiany dla innych programistów należy dokładnie przetestować go za pomocą testów jednostkowych ; Jeżeli wykryjemy jakiś błąd na przetestowanym kodzie, oznacza to, że sito złożone z testów jednostkowych w pewnym miejscu jest „nieszczelne”. W takiej sytuacji należy je „uszczelnić” dodając nowe przypadki testowe zapobiegające przedostaniu się tego błędu w przyszłości ; Należy również jak najczęściej uruchamiać testy integracyjne i akceptacyjne .

10. Modele CMMI, metodologia RUP, metodyki zwinne (ang. agile)

CMMI: sposobem na ocenę procesów wytwarzania oprogramowania w przedsiębiorstwie jest model dojrzałości CMM (Capability Maturity Model) opracowany przez Software Engineering Institute z Carnegie-Mellon University. Model był rozwijany w latach 1987-1997. Od 1997 roku zaczęto pracować nad nowszą wersją nazwaną CMMI, która była pozbawiona wielu wad modelu CMM. Model CMM dzieli firmy na 5 poziomów, w zależności od ich potencjalnych możliwości wyprodukowania oprogramowania wysokiej jakości. Z każdym poziomem związany jest zbiór standardów (procedur), które muszą być przestrzegane w firmie. Poziom pierwszy - nie nakłada żadnych wymagań. Każda firma wytwarzająca oprogramowanie znajduje się początkowo na tym poziomie. CMMI: grudzień, 2000.

Metodyki zwinne (ang.agile)- Podstawowym założeniem metody „agile” jest zastosowanie metody małych kroków. W klasycznym podejściu najpierw tworzy się dokumentację opisującą produkt, a następnie do pracy zabiera się dział programistów. Słabością tej metody jest moment, w którym klient zmienia zdanie na temat oczekiwanego efektu końcowego, a więc duża część pracy może zostać stracona, a terminy niedotrzymane, co zarazem powoduje podniesienie kosztów. Można zmienić dokumentację, co wiąże się z ponownym przekalkulowaniem kosztów i jest słabością tej metody. Metoda „agile” jest jej wolna od ponoszenia kosztów zmian, ponieważ klient na bieżąco śledzi zmiany w projekcie i może reagować zmieniając ostateczny kształt produktu przy zdecydowanie niższych kosztach.

RUP (Rational Unified Process) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation. (obecnie dostępnego w IBM). Produkt ten zawiera hipertekstową bazę wiedzy z przykładowymi artefaktami oraz szczegółowymi opisami wielu typów czynności. Process RUP definiowany jest także w produkcie Rational Method Composer (RMC), który pozwala na tworzenie spersonalizowanych wersji RUP.

Proces RUP został opracowany z użyciem tych samych technik, których zespół Rational używał do modelowania systemów - języka UML. Język UML powstawał równolegle z RUP (również jako połączenie doświadczenia w modelowaniu firm Objectory i Rational).

RUP bazuje na zbiorze zasad inżynierii programowania oraz najlepszych praktykach, np.:Iteracyjnym wytwarzaniu oprogramowania (Iterative Development); Zarządzaniu wymaganiami (Requirement Management); Używaniu architektury bazującej na komponentach (Component-based architecture); Graficznym projektowaniu oprogramowania; Kontroli jakości oprogramowania (Quality Assurance); Procesu kontroli zmian w oprogramowaniu (Change Management).

Cykl życia projektu w RUP: Cykl życia w RUP bazuje na modelu spiralnym. RUP jest dostępny jako struktura prowadzenia projektu, która może być personalizowana w celu 6rzystosowania do specyficznych potrzeb projektowych. Cykl życia w RUP układa zadania w fazy i iteracje.Projekt został podzielony na cztery fazy: Faza podjęcia (Inception phase); Faza opracowywania (Elaboration phase); Faza konstrukcji (Construction phase); Faza przekazania systemu (Transition phase).

1

---