plik


ÿþPodstawy In|ynierii Oprogramowania WykBad 10 Jako[ w procesie wytwarzania oprogramowania 1. Podstawowe pojcia i definicje zwizane z jako[ci 2. Testowanie dynamiczne i statyczne 3. Miary jako[ci oprogramowania 4. Zarzdzanie konfiguracj i zmianami 5. Pielgnacja oprogramowania Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 1 Podstawy In|ynierii Oprogramowania Jako[ oprogramowania ogóB wBa[ciwo[ci produktu wi|cych si z jego zdolno[ci do zaspokojenia potrzeb stwierdzonych i oczekiwanych [wg ISO 9126] Wyró|nia si: " jako[ zewntrzn (punkt widzenia klienta: wBasno[ci dotyczce oprogramowania lub jego oferty), " jako[ wewntrzn (punkt widzenia dostawcy oprogramowania: metody narzdzia, reguBy, procedury, Jako[ wewntrzna standardy, normy). /zewntrzn a charakterystyki jako[ci funkcjonalno[ niezawodno[ u|yteczno[ wydajno[ pielgnacja przeno[no[ Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 2 Podstawy In|ynierii Oprogramowania Proces formuBowania wymagaD na jako[ Potrzeby Wymagania Produkt Miary jako[ci u|ytkowej Wymagania na Jako[ Specyfikacja Ocena u|ytkowa jako[ u|ytkow walidacja Miary jako[ci zewntrznej okre[laj wskazuje Wymagania na Jako[ Specyfikacja Ocena zewntrzna jako[ zewntrzn Miary jako[ci Weryfikacja i okre[laj wewntrznej wskazuje walidacja Wymagania na Jako[ Specyfikacja Ocena wewntrzna jako[ wewntrzn weryfikacja zródBo: ISO/IEC 25010 Implementacja Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 3 Podstawy In|ynierii Oprogramowania Zapewnienie jako[ci - komponenty Nadzorowanie Testowanie jako[ci Standardy Zarzdzanie Procedury zmianami i konfiguracj Przewodniki Wymagania Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 4 Podstawy In|ynierii Oprogramowania Koszt usuwania bBdów 1000 1000 800 600 400 200 200 50 10 1 0 Specyfikacja Projekt Kodowanie Test Wdro|enie Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 5 Podstawy In|ynierii Oprogramowania Polityki jako[ci w wytwarzaniu oprogramowania Kontrola Sterowanie Zapewnienie Zarzdzanie Jako[ci Jako[ci Jako[ci Jako[ci Okres 60-... 70-... 80-... 90-... Ewaluacja i Regularno[ Zapewnienie sterowania jako[ci Ustawiczne doskonalenie Cel uzyskanie uzyskiwania jako[ci Zapewnienie zaufania jako[ci jako[ci na koDcu BaDcucha Test Zdefiniowany, Zdefiniowany, Zdefiniowany, dokumentowa- Stosowane ·ðStatyczny udokumentowany i udokumentowany ny i opomiarowany i dosko- [rodki ·ðDynamiczny opomiarowany proces i zweryfikowany system jako[ci nalony system jako[ci ·ðPrzyczynowa analiza bBdów ·ðProces Audyty ·ðNadzór tech- nologiczny standardowy ·ðZapisy jako[ci ·ðUwzgldnia- nie potrzeb ·ðCykle |ycia klientów, kierownictwa, ·ðMetody, narzdzia, pracowników zasady i procedury ·ðBazy danych procesu Jako[ produktu Tak(oprogram ·ðTak Tak (+usBugi) Tak ·ðPo opraco waniu owanie) ·ðTak (terminy i ·ðTak ·ðTak ·ðW trakcie koszty) ·ðTak (gwarancja) ·ðTak (je|eli stosowane jest ·ðPrzed opracowa- zapewnienie jako[ci) niem ·ðTak ·ðUstawiczna Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 6 Podstawy In|ynierii Oprogramowania Procesy badania jako[ci - definicje TESTOWANIE to wykonywanie programu w celu i z intencj znalezienia bBdu (na podstawie bBdnego wykonywania si programu - ang. fault) WERYFIKACJA - wykazanie w warunkach  sztucznych zgodno[ci wytworzonego programu/systemu ze specyfikacj. WALIDACJA (zatwierdzanie) - wykazanie w warunkach  naturalnych (np. w [rodowisku klienta) zgodno[ci wytworzonego programu/systemu ze specyfikacj. CERTYFIKACJA - autorytatywne potwierdzenie zgodno[ci wytworzonego programu/systemu ze specyfikacj, która jest znormalizowana (np. w postaci normy ISO, ANSI, IEC). Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 7 Podstawy In|ynierii Oprogramowania Testowanie - definicje 1. Testowanie - proces potwierdzajcy poprawno[ programu, polegajcy za wykazaniu, |e nie ma on bBdów 2. Testowanie - proces nabywania zaufania, |e system wykonuje to, czego si od niego oczekuje. (Hetzel 1973) 3. Testowanie - proces wykonywania programu z intencj znalezienia bBdu. (Myers 1979) 4. Testowanie - jakakolwiek dziaBalno[ majca na celu ocen (obliczenie, oszacowanie) atrybutów lub mo|liwo[ci systemu i okre[lenie, czy s one zgodne z oczekiwanymi wynikami. (Hetzel 1983) 5. Testowanie - mierzenie jako[ci oprogramowania. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 8 Podstawy In|ynierii Oprogramowania Testowanie  definicje poj BADY s wrodzon wBasno[ci programów BBd oprogramowania (ang. fault) - nie s speBnione sensowne oczekiwania u|ytkownika/klienta; stan rzeczy odbiega od przyjtych zaBo|eD/zasad. Awaria (ang. failure)  efekt  wykonania bBdu Przypadek testowy  para <dane wej[ciowe, oczekiwane wyniki> specyfikacja sposobu testowania systemu, Bcznie z okre[leniem co testowa, pod jakim warunkiem mo|na testowa. Przypadek testowy musi weryfikowa co najmniej jeden scenariusz przypadku u|ycia. Procedura testowa  kroki opisujce kolejno[ wykonywania przypadku testowego Skrypt testowy  zautomatyzowana procedura testowa Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 9 Podstawy In|ynierii Oprogramowania TESTOWANIE  klasyfikacja bBdów Klasyfikacja bBdów w systemach informatycznych: -wg przyczyny: uszkodzenie sprztu, bBd danych, nieadekwatno[ oprogramowania - wg czasu trwania: trwaBy, chwilowy - wg skutków dla u|ytkownika: krytyczny, niekrytyczny - wg miejsca powstania : wewntrzny, zewntrzny Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 10 Podstawy In|ynierii Oprogramowania TESTOWANIE - przepByw prac Plan Projektowanie Ocena testowania testowania testów In|ynier testowania Wykonanie testowania Tester integracji integracyjnego Wykonanie testowania Tester systemu systemu In|ynier Implementacja komponentów testu Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 11 Podstawy In|ynierii Oprogramowania TESTOWANIE - kategorie wg kryterium: faza cyklu |ycia oprogramowania: " testowanie jednostki (procedury,moduBu, programu) " testowanie integracyjne " testowanie systemowe " testowanie akceptacyjne - wg kryterium  wymagania niefunkcjonalne : " testowanie instalacyjne " testowanie wydajno[ciowe " testowanie niezawodno[ci - wg kryterium : technika testowania: " testowanie statyczne (dotyczy artefaktów  niewykonywalnych ; inspekcja kodu/projektu) " testowanie dynamiczne (wykonywanie programu dla danych testowych) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 12 Podstawy In|ynierii Oprogramowania TESTOWANIE a fazy wytwarzania (1) (model V) Potrzeba systemu Sprawdzony system Specyfikacja Testowanie wymagaD akceptacyjne u|ytkownika Analiza wymagaD Testowanie na oprogramowanie systemu Testowanie Projektowanie integracji Kodowanie Testowanie jednostkowe Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 13 Podstawy In|ynierii Oprogramowania TESTOWANIE a fazy wytwarzania (2) Model Rodzaj testowania Technika testowania Model specyfikacji Testowanie akceptacyjne Testowanie funkcjonalne weryfikacja wymagaD i systemowe Pomiar osigów weryfikacja Model projektowy Testowanie integracyjne Testowanie strukturalne Testowanie funkcjonalne Model implementacyjny weryfikacja Testowanie jednostkowe Testowanie strukturalne Testowanie funkcjonalne Testowanie jednostkowe ·ð black-box ·ð white-box Testowanie integracyjne - zasady Bczenia jednostek ·ð przyrostowa zstpujca - wymaga namiastek (stubs) wstpujca - wymaga sterowników ·ð skokowa Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 14 Podstawy In|ynierii Oprogramowania TESTOWANIE a fazy wytwarzania (3) Testy integracyjne dotycz Bczenia moduBow/podsystemów (powstawanie kolejnych  build ów). Testy systemowe - testowanie powstaBej edycji ( release ) oprogramowania; wykorzystuje si scenariusze z przypadków u|ycia (realizacja projektowa) - weryfikacja wymagaD co do systemu. Testy akceptacyjne dotycz zainstalowanego produktu i s generowane na podstawie przypadków u|ycia. Poprawne wykonanie ka|dego z tych testów - rozumiane jako speBnienie warunku (-ów) post przypadku u|ycia - oznacza osignicie celu tego przypadku i jest walidacj wymagania u|ytkownika. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 15 Podstawy In|ynierii Oprogramowania TESTOWANIE  rodzaje testów systemowych Testowanie systemowe - zalecane typy testów systemowych Test Czynno[ Najcz[ciej stosuje si do systemów u|yteczno[ci sprawdzenie funkcji systemu systemy o rozbudowanej funkcjonaln. wydajno[ci pomiar parametrów, wyznaczenie systemy o narzuconych wymaganiach charakterystyk wydajno[ciowych obci|enia praca systemu w ekstremalnych systemy sieciowe, wielodostpne warunkach (du|o danych, wielu u|ytkowników) pamici pomiary zapotrzebowania na pami konfiguracji próba pracy w ró|nych konfiguracjach instalacji testowanie procedur systemy o skomplikowanej instalacji instalacyjnych poufno[ci próba wBamania systemy z poufnymi danymi Testowanie akceptacyjne ·ð akceptacja fazowa - prototypy, kolejne wersje produktu ·ð akceptacja ostateczna Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 16 Podstawy In|ynierii Oprogramowania TESTOWANIE jednostkowe - rodzaje WEJZCIA WYNIKI okre[lone wyj[cie przez porównywane z wymagania wymaganym wynikiem wymagania jak dla i kluczowe  black i elementy  white projektowe potwierdzone elementy oczekiwane projektowe zachowanie Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 17 Podstawy In|ynierii Oprogramowania TESTOWANIE jednostkowe Dostpne narzdzia wspomagajce testowanie jednostkowe  seria xUnit " JUnit (Kent Beck i Erich " SchemeUnit, Gamma), " VbUnit, " CPPUnit, " HttpUnit, " SUnit (Kent Beck), " NUnit, " PHPUnit, " EiffelUnit, " PerlUnit, " PowerBuilderUnit. " DbUnit,, " PlSqlUnit, " PythonUnit, Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 18 Podstawy In|ynierii Oprogramowania TESTOWANIE jednostkowe - wymagania Wymagania pojawiajce si podczas implementacji testów jednostkowych: " Niepowodzenie jednego testu nie powinno przerywa procesu testowania (assert() z jzyka C koDczy program) " Raporty z wykonania testów powinny by generowane automatycznie " Asercje powinny dawa mo|liwo[ porównywania obiektów ró|nych typów " Konieczna mo|liwo[ organizacji testów w zbiory Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 19 Podstawy In|ynierii Oprogramowania TESTOWANIE jednostkowe - idea Ogólna zasada dziaBania JUnit a " Dla klasy testowanej Przypadek testowy Przypadek testowy tworzymy  TestCase " Dodajemy metody testowe rozpoczynajce si fraz  test " W miar potrzeby nadpisujemy metody setUp() i tearDown() Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 20 Podstawy In|ynierii Oprogramowania TESTOWANIE jednostkowe  przykBad testu using System; using System.Collections.Generic; using System.Text; using System.Data; namespace BazaDanych.LogikaBiznesowa.Testy { using NUnit.Framework; [TestFixture] public class ZarzadcaRaportowTest { private FasadaBD fasada = new FasadaBD(); private string rola; [SetUp] protected void SetUp() { rola = "User"; } /// <summary> /// Pusty okres raportowania  wynikiem s wszystkie rekordy /// </summary> [Test] public void Raport2_Test1() { int typRaportu = 2; int liczbaRekordow = 9; string okres = ""; DataTable tabela = fasada.pobierzRaport(rola, typRaportu, okres); Assert.AreEqual(tabela.Rows.Count, liczbaRekordow); } } Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 21 Podstawy In|ynierii Oprogramowania TESTOWANIE - przykBady testów Testowanie White-Box - klasa CniefiskalnaBazaDanych (zrealizowana jako obiekt COM) Cel: Przetestowanie metody DodajDaneKlienta(imi, imi2, nazwisko, NIP, PESEL) Pre: W bazie jest rekord: Nazwa pola Warto[ Imi Jan Imi2 Jakub Nazwisko Kowalski NIP 8811233210 PESEL 72010110103 Przypadki Testowe: Lp. Parametry wej[ciowe metody Oczekiwane wyniki 1  Jan ,  Jakub ,  Kowalski , Wyjtek - klient ju| istnieje i nie zostaB dodany 8811233210, 72010110103 do bazy danych 2  Edmund ,  Jan , Kalafior , Klient zostaB dodany do bazy danych 8821248281, 73020220119 3  Jan , Andrzej , Rokita Klient nie dodany do bazy, komunikat o bBdnych parametrach metody Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 22 Podstawy In|ynierii Oprogramowania TESTOWANIE - przykBady testów Testowanie Black-Box Cel: Przetestowanie przypadku u|ycia Dodanie nowego klienta Pre: W bazie nie ma rekordów odpowiednio klienta indywidualnego Nazwa pola Warto[ Imi Jan Imi2 Jakub Nazwisko Kowalski NIP 8811233210 PESEL 72010110103 Test: Lp. WypeBnione pola na formularzu XXX Oczekiwane wyniki 1 Imi: Jan, Drugie imi: Jakub, Klient jest dodany do bazy Nazwisko: Kowalski, NIP: 8811233210 PESEL: 72010110103 2 J/w Komunikat o bBdzie - klient ju| istnieje w bazie danych; klient nie jest dodany do bazy 3 Imi: Jan, Nazwisko: Kowalski Komunikat o bBdzie - nie podane parametry; klient nie jest dodany do bazy Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 23 Podstawy In|ynierii Oprogramowania TESTOWANIE - ZAOTE MYZLI " trudno jest stwierdzi, kiedy skoDczy testowanie " nie mo|na testowa wBasnego programu, " testowanie powinno by powtarzalne, " dane testowe obejmuj zarówno dane poprawne jak i niepoprawne, " nale|y bada dokBadnie wyniki testowania, " wzrost liczby wykrytych jest symptomem istnienia pozostaBych " testowalno[ jest kluczowym zaBo|eniem projektu Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 24 Podstawy In|ynierii Oprogramowania Przegldy Przegld jest procesem lub spotkaniem, podczas którego produkt roboczy/artefakt (lub zbiór produktów roboczych) jest prezentowany personelowi projektu, kierownictwu, u|ytkownikom, klientom lub innych zainteresowanych stron celem uzyskania komentarzy, opinii i akceptacji. Przegldy mog by formalne i nieformalne. Przej[cie (walkthrough). Wczesna, nieformalna ocena dokumentów, modeli, projektów i kodu. Celem jest zidentyfikowanie defektów i rozwa|enie mo|liwych rozwizaD. Wtórnym celem jest szkolenie i rozwizanie problemów stylistycznych (np. z form kodu, dokumentacji, interfejsów u|ytkownika). Formalne przegldy mog by inspekcj bdz audytem Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 25 Podstawy In|ynierii Oprogramowania Inspekcja formalna technika oceny, w której wymagania na oprogramowanie, projekt lub kod s szczegóBowo badane przez osob lub grup osób nie bdcych autorami, w celu identyfikacji bBdów, naruszenia standardów i innych problemów [IEEE Std. 729:1983] Korzy[ci z inspekcji: 1. Wzrost produktywno[ci od 30% do 100% 2. Skrócenie czasu projektu od 10% do 30% 3. Skrócenie kosztu i czasu wykonywania testów od 5 do 10 razy (mniej bBdów, mniej testów regresyjnych) 4. 10 razy mniejsze koszty pielgnacji (naprawczej) 5. Poprawa procesu programowego Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 26 Podstawy In|ynierii Oprogramowania Wymagania na WYMAGANIA :) Wymaganie powinno : Øð by jasno i jednoznacznie sformuBowane Øð by wyra|one w sposób mierzalny (wa|ne zwBaszcza dla wymagaD niefunkcjonalnych) Øð mie nadany priorytet Øð mie oszacowany koszt realizacji Øð by dostarczone do etapu projektu Øð by rozpoznawalne w kodzie Øð by weryfikowalne: stowarzyszone z testem, testowalne w izolacji oraz Bcznie z innymi wymaganiami Øð by walidowalne po zbudowaniu systemu Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 27 Podstawy In|ynierii Oprogramowania Inspekcja jako[ci wymagaD - przykBad Lista kontrolna jako[ci wymagaD 1. Czy |adne wymaganie nie jest w konflikcie z innym ? 2. Czy wymaganie unika specyfikowania projektu? 3. Czy wymagania s wyra|one na spójnym, odpowiednim stopniu szczegóBowo[ci? Czy którekolwiek wymaganie powinno by podane bardziej bdz mniej szczegóBowo? 4. Czy wymagania s wystarczajco jasne, by przekaza je niezale|nej grupie do implementacji i bd cigle zrozumiaBe? 5. Czy ka|dy element jest odpowiedni do problemu i jego rozwizania? 6. Czy ka|dy element mo|e by [ledzony ze swoim oryginaBem w [rodowisku problemu? Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 28 Podstawy In|ynierii Oprogramowania Audyt niezale|ny przegld i ocena jako[ci oprogramowania, która zapewnia, ze osignito zgodno[ z wymaganiami na oprogramowanie, a tak|e ze specyfikacj, generalnymi zaBo|eniami, standardami, procedurami, instrukcjami, kodami oraz kontraktowymi i licencyjnymi wymaganiami. Celem audytu projektu informatycznego jest dostarczenie odbiorcy i dostawcy obiektywnych, aktualnych i syntetycznych informacji o stanie caBego projektu lub produktu koDcowego. Przedmioty audytu: stan projektu, proces wytwórczy lub jego dowolny podproces system jako[ci, produkt koDcowego Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 29 Podstawy In|ynierii Oprogramowania Pomiar artefaktu Jednostki przydzielane atrybutom artefaktu podczas procesu pomiarowego s nazywane miar danego atrybutu. Miara  charakteryzuje w terminach numerycznych pewien prosty atrybut elementu (e.g. liczba linii kodu programu) Miara: mierzalny atrybut bytu (encji) np. nakBad czasowy projektu jest miar jego rozmiaru; by to zmierzy nale|y zsumowa wszystkie sprawozdania czasowe projektu. Miara mo|e by zbudowana w oparciu o jedn lub wicej innych miar -> powinno si definiowa podstawowe miary i procedury ich zbierania. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 30 Podstawy In|ynierii Oprogramowania Miara stabilno[ci oprogramowania Indeks dojrzaBo[ci oprogramowania: Ocenia stabilno[ oprogramowania MT -ð (Fa +ð FC +ð Fd ) SMI =ð MT gdzie: MT - liczba funkcji (moduBów) w obecnej wersji oprogramowania Fa - liczba funkcji dodanych Fc - liczba funkcji zmienionych Fd - liczba funkcji usunitych Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 31 Podstawy In|ynierii Oprogramowania Miary zBo|ono[ci produktu programowego ZBo|ono[ na poziomie kodu: 1. liczba McCabe a, 2. miary Halsteada, 3. miara McClure (liczba zmiennych sterujcych +liczba porównaD) Liczba McCabe a Je[li G jest schematem blokowym programu P i G posiada e krawdzi i n wzBów to liczba niezale|nych [cie|ek w G (zBo|ono[ cyklomatyczna) wyra|a si wzorem: v(P) = e  n + 2 lub pro[ciej je|eli d jest liczb wzBów decyzyjnych G, wtedy: v(P) = d+1 Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 32 Podstawy In|ynierii Oprogramowania Miary zBo|ono[ci produktu programowego 2. Miary Halsteada Metoda ta nie mierzy samego programu, lecz skupia si na pomiarze jego jednostek syntaktycznych: W programie P wyró|nione s operatory i operandy: n1  liczba unikalnych operatorów n2  liczba unikalnych operandów N1  caBkowita liczba wystpieD operatorów w programie P N2  caBkowita liczba wystpieD operandów w programie P SBownik P zawiera n = n1 + n2 elementów DBugo[ programu wynosi N = N1 + N2 WedBug Elshoffa, który opracowaB modyfikacj tej metody, dBugo[ programu lepiej jest szacowa ze wzoru: N = n1 log n1 + n2 log n2 Dodatkowo mo|na okre[li zwizBo[ implementacji V: V= N log n Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 33 Podstawy In|ynierii Oprogramowania Miara niezawodno[ci produktu Indeks defektów (ocena poprawy jako[ci oprogramowania w kolejnych etapach wytwarzania) Indeks defektów w i-tej fazie (stosuje si do faz w których wykryto defekty tzn. Di <> 0): Si Mi Ti PIi =ðW1 +ðW2 +ðW3 Di Di Di gdzie: Di - liczba defektów wykrytych w i-tej fazie Si - liczba powa|nych defektów wykrytych w i-tej fazie Mi - liczba defektów o umiarkowanej wadze wykrytych w i-tej fazie Ti - liczba defektów trywialnych wykrytych w i-tej fazie W1 - waga powa|nych defektów (np. 10) W2 - waga defektów umiarkowanych (np. 3) W3 - waga defektów trywialnych (np. 1) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 34 Podstawy In|ynierii Oprogramowania Miary zBo|ono[ci projektu Dla podej[cia strukturalnego dwie miary: moc moduBu  miara zBo|ono[ci wewntrz moduBowej: przypadkowa, klasyczna, logiczna, komunikacyjna, funkcjonalna, informacyjna wiz moduBu - miara zBo|ono[ci komunikacji midzymoduBowej: tre[ciowa, sterowania, wspólna, zewntrzna, cechy, danych Dla podej[cia obiektowego miary dla klasy  zestaw miar Chidamber/Kemerer (1994) dla projektu - MOOD (Abreu,Goualo,Esteves 1995) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 35 Podstawy In|ynierii Oprogramowania Miary zBo|ono[ci dla klasy (Chidamber/Kemerer 1994) ZBo|ono[ klasy (WMC)- to, je[li zBo|ono[ ka|dej metody klasy jest traktowana jako jeden, to WMC=n, gdzie n jest liczb metod w klasie ZBo|ono[ metody jest obliczana w postaci wariantu zBo|ono[ci cyklomatycznej liczby McCabe a; poniewa| ta miara jest addytywna, to mo|na policzy zBo|ono[ klasy. GBboko[ drzewa dziedziczenia (DIT)  zlicza poziomy, od  korzenia drzewa Liczba potomków (NOC)  zlicza klasy pochodne na ssiednim poziomie Wiz midzyobiektowa (CBO)  zlicza komunikacje nie-dziedziczone {danie wygenerowane przez klas (RFC)  zlicza wszystkie metody stosowane przez klas. Brak spójno[ci w metodach (LCOM)  identyfikuje metody, które stosuj ró|ne atrybuty. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 36 Podstawy In|ynierii Oprogramowania Jako[ kodu - zapachy Zapachy kodu - pewne cechy kodu zródBowego mówice o zBym sposobie implementacji i bdce sygnaBem do refaktoryzacji Pi kategorii [Mika Mäntylä] : " ang. The Bloaters - co[ co rozrosBo si do tak du|ych rozmiarów, i| nie mo|e by poprawnie obsBu|one: du|a klasa, dBuga metoda, obsesja typów podstawowych, dBuga lista parametrów, zbitki danych. " ang. The Object-Orientation Abusers: - rozwizania które nie wykorzystuj w peBni mo|liwo[ci programowania obiektowego: instrukcje switch, pole tymczasowe, odrzucony spadek, ró|ne klasy z identycznym interfejsem. " ang. The Change Preventers - utrudniaj zmiany lub rozwój oprogramowania: poszatkowanie, równolegBe hierarchie dziedziczenia, rozbie|na zmiana. " ang. The Dispensables - zawieraj co[, co powinno by usunite z kodu zródBowego: leniwa klasa, klasa danych, powtórzony kod, martwy kod, spekulatywna ogólno[. " ang. The Couplers - zapachy zwizane z powizaniem kodu: zazdro[ o kod, zbytnia intymno[, po[rednik, BaDcuchy wywoBaD. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 37 Podstawy In|ynierii Oprogramowania Jako[ kodu  zapachy (2) PrzykBady: " DBuga metoda (ang. Large method) - istniej bardzo dBugie metody. " Du|a klasa (ang. Large class) - istniej klasy posiadajce zbyt wiele odpowiedzialno[ci -nale|y przeorganizowa struktur klas w projekcie. " Zazdro[ o kod (ang. Feature envy) - istniej metody intensywnie korzystajce z danych innej klasy; metoda taka powinna by przeniesiona do klasy, z której danych korzysta. " Zbytnia intymno[ (ang. Inappropriate intimacy) - istniej klasy, których dziaBanie jest zale|ne od implementacji innych klas- sprzeczne z ide hermetyzacji, gdzie nie nale|y zna szczegóBów implementacyjnych innych klas, a jedynie ich interfejs. " . Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 38 Podstawy In|ynierii Oprogramowania Jako[ kodu  zapachy (3) " Odrzucony spadek (ang. Refused bequest) - istniej klasy pochodne, które przeci|aj metod z nadklasy tak i| naruszaj jej kontrakt. Jest to naruszenie zasady podstawienia Liskov (Funkcje, które u|ywaj wskazników lub referencji do klas bazowych, musz by w stanie u|ywa równie| obiektów klas dziedziczcych po klasach bazowych, bez dokBadnej znajomo[ci tych obiektów.) " Leniwa klasa (ang. Lazy class) - istniej klasy posiadajce bardzo maBy zakres odpowiedzialno[ci. " Powielony kod (ang. Duplicated code) - ten sam fragment kodu powtarza si w kilku miejscach; utrudnia to wprowadzanie zmian (musz zosta odnalezione wszystkie miejsca w kodzie, które realizuj to samo zadanie)[2]. " Contrived Complexity - u|yte zostaBy skomplikowane wzorce projektowe - zastosowanie znacznie prostszych byBoby wystarczajce. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 39 Podstawy In|ynierii Oprogramowania Zarzdzanie Konfiguracj  definicje Postpowanie sBu|ce zarzdzaniu i kontroli rozwoju oraz ewolucji projektu Dyscyplina okre[lania elementów nieustannie rozwijajcego si systemu programowego w celu kontrolowania zmian w tych elementach i pielgnowania spójno[ci oraz udogodnienia [ledzenia zmian w cigu caBego cyklu |ycia systemu - BS 8488:1984 Zbiór czynno[ci sBu|cych zarzdzaniu zmian poprzez: " identyfikacj artefaktów ulegajcych zmianie, " ustalenie relacji midzy nimi, " okre[lenie mechanizmów zarzdzania wersjami, " kontrol zmian, " audyt, " raportowanie. R. Pressman Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 40 Podstawy In|ynierii Oprogramowania Zarzdzanie konfiguracj - podstawowe pojcia Konfiguracja  zmienny w czasie zestaw ustalonych artefaktów projektu i innych informacji, które s istotne do sprawnej jego realizacji. Jej elementy to: Dokumentacja produktu programowego Dokumentacja projektowa Standardy, procedury, instrukcje Kod programu Linia bazowa konfiguracji Zestaw artefaktów, który zostaB poddany przegldowi i zatwierdzony. Jest podstaw do dalszego rozwoju. Mo|e by zmieniony tylko poprzez formalne procedury. IEEE Std. 610.12-1990 Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 41 Podstawy In|ynierii Oprogramowania Konfiguracja  podstawowe pojcia Jednostka (element) konfiguracji (ang. SCI) - artefakt powstaBy w trakcie procesu wytwarzania oprogramowania [R. Pressman] Identyfikowanie jednostki " Nazwa " Opis (typ SCI, identyf. projektu, wersja, informacja o zmianach) " Zasoby wymagane przez SCI (np. zmienne globalne wymagane do kompilacji) " Realizacja (np. odwoBanie do pliku tekstowego z kodem) Typy elementów konfiguracji: " oprogramowanie (kod zródBowy lub binarny) " dokumenty (w tym podrczniki) " dane (np. przypadki testowe) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 42 Podstawy In|ynierii Oprogramowania Zarzdzanie konfiguracj  bBdy " nie ma pewno[ci, która wersja elementu jest wersj bie|c (strata czasu, dodatkowy nakBad pracy) " niezgodno[ci midzy poszczególnymi elementami konfiguracji (np. specyfikacja programu, kod i specyfikacja testów s niezgodne) "  wydawanie produktów nie jest kontrolowane " niekontrolowane zmiany w [rodowisku oprogramowania lub sprztu  bez analizy ich skutków " w przypadku  katastrofy - nie do odtworzenia bie|cy stan przedsiwzicia Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 43 Podstawy In|ynierii Oprogramowania Zarzdzanie zmianami Zarzdzanie zmianami (ZZ) obejmuje proces modyfikacji elementów linii bazowej w jednolity, spójny sposób. {danie zmian mo|e dotyczy ró|norodnych elementów np. zmian wymagaD, dokumentowania defektów, zmiany czasu przej[cia midzy iteracjami. ZZ dotyczy struktury procesu. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 44 Podstawy In|ynierii Oprogramowania Zarzdzanie zmianami - proces Realizatorzy projektu ZespóB Nadzorownia Zmian ZespóB analiz Potrzeba zmiany Rejestracja zmiany Formularz zmiany Formularz zmiany [nowa] [rejestrowana] Analiza Ocena wyników analizy [Potrzeba wprowadzenia?] Analiza Analiza kosztów Tak harmonogramu Wprowadzanie Ustalenie zmiany WpByw na priorytetu inne artefakty zmiany Nie Formularz zmiany [przydzielona] Formularz zmiany [oszacowna] Testowanie zmiany Archiwizowanie zmiany Formularz zmiany [zakoDczona] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, Computer Science Department, Faculty of Computer Science and Management 2012/2013 45 Podstawy In|ynierii Oprogramowania Zarzdzanie zmianami  przykBad procesu (BRE BANK SA.) Mapa przebiegu realizacji Procesu Kontroli Zmian Inicjator zmiany Tak Tak 5.1 Rejestracja Zmiana Koordynator Zmiana i standardo pilna zmiany klasyfikacja wa Nie zmiany Nie Kierownik Procesu Kontroli 5.8 Zmian Implemnt. 5.7 zmiany 5.6 Przegld pilnej 5.2 5.4 Implementacja 5.9 5.10 5.3 poimpleme Ocena Definicja 5.5 Budowa zmiany WBa[ciciel Implementacja Powrót do Zatwierdze ntacyjny ryzyka harmonogr. i test zmiany stranu nie zmiany i implement. zmiany standardowej pierwotnego zmiany wpBywu zmiany Komitet Tak konsultacyjny d/s zmian Poprawna Nie Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 46 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami Dotyczy: elementu linii bazowej konfiguracji Cele: " Kontrolowanie zmian " Zarzdzanie baz wersji " Kontrolowanie i przechowywanie historii zmian Wersja  instancja artefaktu, która ró|ni si od innych instancji oferowanymi funkcjami Wydanie  wersja dostarczona u|ytkownikowi Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 47 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami - oznaczenia v.1 v.2 v.3 v.4 v.5 v.2.1 v.2.2 v.2.3 v.2.2.1 v.1.1 v.1.2 Schemat trzycyfrowy <wersja> = <nazwa_SCI>.<major>.<minor>.<revision> <major> - Wydanie (dla klienta) <minor> - Wersja w ramach wydania (dla programisty) <revision> - Poprawki w ramach wersji wydania (dla programisty) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 48 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami - narzdzia " Perforce Repozytorium  Zledzenie dziaBaD programistów " IBM Rational ClearCase " CVS (Concurrent Versions System) " SubVersion nastpca CVS; najbardziej popularny " Dokumencik Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 49 Podstawy In|ynierii Oprogramowania Funkcje narzdzi wersjonowania " Zarzdzanie repozytorium komponentów  Zarzdzanie wersjami " Historia " Przechowywanie delt " Zarzdzanie wielodostpem  Zarzdzanie relacjami midzy obiektami " Zawieranie " Zale|no[ " Wsparcie in|ynieryjne Kompilowanie i budowa projektu Wsparcie [rodowiska pracy Wsparcie pracy kooperacyjnej " Wsparcie procesu projektowania Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 50 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami  rozwizanie konfiktu " Blokada " Aczenie plików (merging) " Porównaj lini po linii dokument pocztkowy z wersjami zmienionymi " Je[li linia wystpiBa tylko w nowej wersji musi by dodana " Je[li linia wystpiBa tylko w pierwotnej wersji musi by usunita Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 51 Podstawy In|ynierii Oprogramowania Funkcje narzdzi wersjonowania (cd) " Cofanie dowolnej liczby zmian " Dokonywanie przegldów  sprawdzanie kompletno[ci i spójno[ci komponentów " Ustalenie odpowiedzialno[ci pracowników  kto dopisaB t lini kodu, która powoduje bBd? " Raportowanie:  historii zmian  ró|nic midzy wersjami  aktywno[ci pracowników  statusu caBego projektu i jego komponentów " Oszczdno[ zasobów (czasu, pracy& ), bezpieczeDstwo Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 52 Podstawy In|ynierii Oprogramowania Narzdzia wersjonowania  pojcia podstawowe " Repository ( repozytorium) - miejsce, gdzie przechowywane s pliki " Check-Out - pobranie pliku z repozytorium " Update ( aktualizacja) - kopiuje zmiany dokonane w repozytorium do katalogu, w którym pracujemy " Change ( zmiana)  reprezentuje modyfikacj do dokumentu znajdujcego si pod kontrol wersji. " Commit (równie|: install, submit, check-in) - wgranie zmian do repozytorium " Change List (lista zmian)  zespóB zmian dokonanych podczas jednej operacji commit " Merge ( Bczenie)  Bczy konkurencyjne zmiany do jednej zunifikowanej wersji " Conflict ( konflikt)  pojawia si, kiedy algorytm Bczenia nie jest w stanie wygenerowa poprawnej wersji zawierajcej zmiany wprowadzone do Bczonych plików " Resolve ( rozwizanie konfliktu)  akt interwencji u|ytkownika w celu wsparcia algorytmu do nanoszenia ró|nych zmian tego samego do kumentu Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 53 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami  podstawowe operacje w CVS Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 54 Podstawy In|ynierii Oprogramowania PrzykBad struktury repozytorium (Subversion) Dla ka|dego pliku w katalogu roboczym Subversion przechowuje nastpujce informacje: " Na którym wydaniu oparty jest plik roboczy, " Znacznik czasowy, który przechowuje informacje o czasie ostaniej aktualizacji kopii lokalnej z repozytorium. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 55 Podstawy In|ynierii Oprogramowania Zarzdzanie wersjami  schemat konfiktu we wprowadzaniu zmian Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 56 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania Typy konserwacji/pielgnacji: " korekcyjna usuwanie bBdów niewykrytych podczas testowania " adaptacyjna modyfikacja systemu dopasowujca go do zmian w [rodowisku " perfekcyjna rozszerzenie systemu do rozwizywania nowych problemów lub uzyskania korzy[ci z nowych okoliczno[ci " prewencyjna zabezpieczenie systemu przed przyszBymi problemami Konserwacja oprogramowania obejmuje 4 aktywno[ci: " otrzymanie wymagaD konserwacyjnych " transformacje wymagaD w zmiany " zaprojektowanie zmian " zaimplementowanie zmian Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania - koszty [B.Walter, Uczelniaonline] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 58 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania . Powód prowadzenia modyfikacji (przykBady) 1. adaptacyjnej (dostosowujcej): " zmiany wymagaD u|ytkowników " zmiany przepisów prawnych, " zmiany organizacyjne w firmie klienta " zmiany sprztu/oprogramowania systemowego 2. perfekcyjnej (ulepszajcej): " poprawa wydajno[ci pewnych funkcji " poprawa ergonomii interfejsu " poprawa przejrzysto[ci raportów Przyczynami prowadzenia modyfikacji s na ogóB |dania u|ytkowników Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania Elementy kosztów konserwacji/pielgnacji: " defekty liczba nieznanych defektów po zainstalowaniu systemu " klienci liczba ró|nych klientów, których grupa konserwantów musi obsBu|y " dokumentacja aktualna, kompletna, dla ró|nych wersji systemu " personel zabezpieczenie systemu przed przyszBymi problemami " narzdzia niezawodne, dobrze rozpoznane, nowoczesne " struktura oprogramowania rozszerzenie systemu do rozwizywania nowych problemów lub uzyskania korzy[ci z nowych sytuacji " KOSZTY KONSERWACJI MOG BY DU{E (mog przewy|sza koszty wytwarzania oprogramowania) Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania Obiektywne czynniki kosztów konserwacji/pielgnacji: " stabilno[ [rodowiska pracy systemu " stabilno[ platformy sprztowej i oprogramowania systemowego " czas u|ytkowania systemu Redukcja kosztów dziki: " znajomo[ci dziedziny problemu " wysokiej jako[ci modelu i projektu " wysokiej jako[ci dokumentacji technicznej (mo|liwo[ stosowania in|ynierii odwrotnej) " stabilno[ personelu " [rodowisko implementacji " niezawodno[ oprogramowania Instytut Informatyki, WydziaB Informatyki i Zarzdzania, " zarzdzanie wersjami 2012/2013 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania  kategorie programów Lehmana [B.Walter, Uczelniaonline] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 62 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania  prawa Lehmana [B.Walter, Uczelniaonline] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 63 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania - wnioski [B.Walter, Uczelniaonline] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 64 Podstawy In|ynierii Oprogramowania Konserwacja oprogramowania - modele [B.Walter, Uczelniaonline] Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 65 Podstawy In|ynierii Oprogramowania Konserwacja-podsumowanie " Istniej cztery zasadnicze rodzaje pielgnacji oprogramowania: korekcyjna, adaptacyjna, ulepszajca, prewencyjna. " Dla du|ych systemów mo|na sformuBowa zale|no[ci ( prawa Lehmana), które charakteryzuj ewolucj systemu programowego. Zdefiniowano je na podstawie obserwacji i s wskazówkami dotyczcymi sposobów zarzdzania procesem pielgnacji. " Koszt pielgnacji (w tym zmiany) oprogramowania zwykle przekracza koszt jego budowy. Firmy utrzymuj coraz wiksza liczb systemów odziedziczonych, i ponosz coraz wiksze koszty na pielgnacj systemów odziedziczonych. " Wysokie koszty pielgnacji wynikaj z braku stabilno[ci personelu; ze sposobu wytwarzania, które nie zachcaj do tworzenia kodu zdatnego do pielgnacji; z niedostatecznych umiejtno[ci niezbdnych do pielgnowania systemu. Instytut Informatyki, WydziaB Informatyki i Zarzdzania, 2012/2013 66

Wyszukiwarka

Podobne podstrony:
Fizyka wykład 3 13 10 2009
wykPIO 13 1
dictionary 13 10
0214 13 10 2009, wykład nr 14 , Układ pokarmowy, cześć II Paul Esz
AE 2012 04 13 10 44 41
13 (10)
Podstawy Programowania 13 10 2014
13 10 Roboty wiertnicze i cementacyjne
Ćwiczenia 2 13 10
wykPIO 13 6i7
133 13 (10)

więcej podobnych podstron