Kontrola jakości artefaktów

Podobne dokumenty
Projektowanie oprogramowania. Wykład Weryfikacja i Zatwierdzanie Inżynieria Oprogramowania Kazimierz Michalik

Testowanie oprogramowania. Testowanie oprogramowania 1/34

Maciej Oleksy Zenon Matuszyk

Jakość w procesie wytwarzania oprogramowania

Wykład 8. Testowanie w JEE 5.0 (1) Autor: Zofia Kruczkiewicz. Zofia Kruczkiewicz

Testowanie oprogramowania. Piotr Ciskowski

Szkoła programisty PLC : sterowniki przemysłowe / Gilewski Tomasz. Gliwice, cop Spis treści

Kontrola jakoci artefaktów

Systemy zabezpieczeń

Kod doskonały : jak tworzyć oprogramowanie pozbawione błędów / Steve McConnell. Gliwice, cop Spis treści. Wstęp 15.

Zasady organizacji projektów informatycznych

Usługa: Audyt kodu źródłowego

UPEDU: Implementacja (ang. Implementation discipline)

Metodyka projektowania komputerowych systemów sterowania

Bezpieczeństwo aplikacji i urządzeń mobilnych w kontekście wymagań normy ISO/IEC oraz BS doświadczenia audytora

Metody wytwarzania oprogramowania. Metody wytwarzania oprogramowania 1/31

Dlaczego testowanie jest ważne?

Usługa: Testowanie wydajności oprogramowania

Testowanie i walidacja oprogramowania

Porównanie metod i technik testowania oprogramowania. Damian Ryś Maja Wojnarowska

XPrince dla architektów 1

Szczegółowy opis przedmiotu zamówienia:

Wytwórstwo oprogramowania. michał możdżonek

Główne założenia XP. Prostota (Simplicity) Komunikacja (Communication) Sprzężenie zwrotne (Feedback) Odwaga (Agressiveness)

PROJEKTOWANIE. kodowanie implementacja. PROJEKT most pomiędzy specyfikowaniem a kodowaniem

Procedura Odbioru. 1. Niniejsza Procedura odbioru obejmuje:

Konwerter Plan testów. Jakub Rauch Tomasz Gołębiowski Adam Busch Bartosz Franaszek 1 czerwca 2008

Zarządzanie Autonomiczne Ogólna Kontrola. Szkolenie Zespołu - Krok 4

Jakość oprogramowania część 2 Zapewnianie jakości oprogramowania

Jarosław Kuchta Dokumentacja i Jakość Oprogramowania. Wymagania jakości w Agile Programming

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz

Etapy życia oprogramowania

Najwyżej ocenione raporty dla Mr Buggy 4

Szablon Planu Testów Akceptacyjnych

Szybkie prototypowanie w projektowaniu mechatronicznym

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

<Nazwa firmy> <Nazwa projektu> Specyfikacja dodatkowa. Wersja <1.0>

1 Moduł Centrali PPoż 3

Szczegółowy plan szkolenia

właściwego zarządzania

Jarosław Kuchta Jakość Systemów Informatycznych Jakość Oprogramowania. Pomiary w inżynierii oprogramowania

Brief na wykonanie usługi informatycznej

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE INTEGRACYJNE

Technika bezpieczeństwa

IO - Plan testów. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

Testowanie w procesie Scrum

PRZEWODNIK PO PRZEDMIOCIE

Metodyka wdrożenia. Bartosz Szczęch. Starszy Konsultant MS Dynamics NAV

Czym jest jpalio? jpalio jpalio jpalio jpalio jpalio jpalio jpalio jpalio

Lokalizacja Oprogramowania

Tematy seminariów wg Roger S. Pressman, Praktyczne podejście do oprogramowania, WNT, Zofia Kruczkiewicz

Rozdział 5: Zarządzanie testowaniem. Pytanie 1

Załącznik nr 19 do Umowy nr... z dnia... Plan Testów Systemu. Projekt ZEFIR 2

INŻYNIERIA OPROGRAMOWANIA TESTOWANIE SYSTEMOWE

Microsoft Test Manager

Sukces vs porażka. Sukces. Porażka

Wprowadzenie do systemów informacyjnych

Luki w bezpieczeństwie aplikacji istotnym zagrożeniem dla infrastruktury krytycznej

Inżynieria Programowania Weryfikacja i zatwierdzanie. Plan wykładu. Motto. Wstęp. Notatki. Notatki. Notatki. Notatki.

Etapy życia oprogramowania. Modele cyklu życia projektu. Etapy życia oprogramowania. Etapy życia oprogramowania

Wykład VII. Programowanie III - semestr III Kierunek Informatyka. dr inż. Janusz Słupik. Wydział Matematyki Stosowanej Politechniki Śląskiej

1 Moduł Konfigurowanie Modułu

Oprogramowanie antywirusowe musi spełniać następujące wymagania minimalne:

Zarządzanie jakością

Inżynieria oprogramowania

Monitorowanie Bezpieczeństwa Sieci Technologicznej

Zarządzanie konfiguracją produktu w całym cyklu Ŝycia. Aleksandra Grzywak-Gawryś Warsztaty Rola IRIS w branŝy kolejowej

Praca z kodem legacy : strategie, naprawa błędów, refaktoryzacja oraz

Plan testów do Internetowego Serwisu Oferowania i Wyszukiwania Usług Transportowych

Autor: Artur Lewandowski. Promotor: dr inż. Krzysztof Różanowski

Testujemy dedykowanymi zasobami (ang. agile testers)

I. Wymagania dotyczące świadczenia usług wsparcia

Stabilis Smart Factory

Usprawnienie procesu zarządzania konfiguracją. Marcin Piebiak Solution Architect Linux Polska Sp. z o.o.

Zespół: Agata Chrobak Kornel Jakubczyk Tomek Klukowski Przemek Kosiak. Projekt SZOP Plan testów

INŻYNIERIA OPROGRAMOWANIA Wykład 6 Organizacja pracy w dziale wytwarzania oprogramowania - przykład studialny

Plan. Zapewnienie jakości produktu informatycznego. Zarządzanie jakością i metryki oprogramowania. Podstawowe parametry mierzalne

Walidacja systemu ewms / cwms. Sopot

Przewodnik użytkownika (instrukcja) AutoMagicTest

RAION BASIC MES SYSTEM ANDON & OEE

Cele przedsięwzięcia

OFERTA Audyt i usługi doradcze związane z wdrożeniem systemu zarządzania bezpieczeństwem informacji dla jednostek administracji publicznej

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

Optymalizacja Automatycznych Testów Regresywnych

Praktyka testowania dla początkujących testerów

Studia podyplomowe PROGRAM NAUCZANIA PLAN STUDIÓW

Spis treści. 1 Moduł RFID (APA) 3

System Kontroli Bazy Danych Topograficznych (SKBDT) zawód kartografa?

Cyfrowy magazyn. Jantar MUZEO

Zapewnienie bezpieczeństwa w całym cyklu życia aplikacji (czyli dlaczego lepiej zapobiegać chorobom, niż leczyć je w zaawansowanym stadium)

Wymagania edukacyjne EKSPLOATACJA URZĄDZEŃ TECHNIKI KOMPUTEROWEJ. Montaż komputera osobistego i serwera

Rubik s Manager - Plan testów

System INFIDIO. Bezprzewodowy system sterowania oświetleniem przemysłowym

PYTANIA PRÓBNE DO EGZAMINU NA CERTYFIKAT ZAAWANSOWANY REQB KLUCZ ODPOWIEDZI. Część DODATEK

Jak efektywnie wykrywać podatności bezpieczeństwa w aplikacjach? OWASP The OWASP Foundation

Budowa aplikacji webowej w oparciu o Maven2 oraz przykłady testów jednostkowych. Wykonał Marcin Gadamer

Goal Question Metrics. Jarosław Kuchta Jakość Systemów Informatycznych

DiaSter - system zaawansowanej diagnostyki aparatury technologicznej, urządzeń pomiarowych i wykonawczych. Politechnika Warszawska

Wykład 7. Projektowanie kodu oprogramowania

Bezpieczeństwo IT Audyty bezpieczeństwa i testy penetracyjne

Transkrypt:

Kontrola jakości artefaktów Artefakty produkty, wytwory rąk ludzkich: Dokumenty Specyfikacje Kod Jakość zgodność z wymaganiami (jawnymi i ukrytymi, z których istnienia klient nie zdaje sobie sprawy) Philip Crosby

Przeglądy Średni czas identyfikacji błędu (według IBM): W trakcie przeglądu projektu: 1 W trakcie inspekcji kodu: 20 W trakcie testów maszynowych: 82 Jakość: Projektu Wykonania

8 wymiarów jakości (David A. Garvin) Wydajność (szybkość, itp.) Niezawodność (MTBF, częstotliwość błędów) Wytrzymałość (działanie bez modyfikacji) Łatwość naprawy Estetyka Cechy funkcjonalne Reputacja Zgodność ze standardami i wymaganiami

4 filary jakości Zarządzanie konfiguracją Testowanie Przeglądy (dokument lub kod) Refaktoryzacja (ewolucja)

Cele testowania wg Glena Myersa (1979) Testowanie wykonanie programu celem znalezienia błędu. Udany test taki, który wykrywa jeszcze nie wykryty błąd. Jakość przypadku testowego prawdopodobieństwo znalezienia jeszcze nie wykrytego błędu.

Pracochłonność testowania Według Rogera Pressmana testowanie pochłania 30-40% ogólnej pracochłonności amerykańskiego projektu informatycznego. W przypadku systemów krytycznych (sterowania samolotem, praca elektrowni jądrowej) 70-80%

Testy Dane: Przygotowane ręcznie (XP) Przygotowane automatyczne Wykonanie: Ręczne Automatyczne Anomalia (IEEE 1028) sytuacja różna od oczekiwanej; oczekiwanie opiera się na specyfikacjach, standardach lub czyimś doświadczeniu

IEEE 1028 (1997) Przegląd (review) ocena artefaktu realizowana przez grupę osób Inspekcja (inspection) ocena artefaktu przeprowadzana przez współpracowników (szefowie nie biorą w nich udziału) i kierowana przez moderatora

Inspekcja Prezenter Autor (przygotowanie, wstępne omówienie) Inspektor Moderator (zaplanowanie i przeprowadzenie inspekcji) Sekretarz (często ta sama osoba co moderator)

Etapy inspekcji 1. Omówienie (cały zespół) 2. Przygotowanie (indywidualnie) 3. Inspekcja (cały zespół) 1. Artefakt w pełni zaakceptowany 2. Artefakt zaakceptowany warunkowo 3. Powtórna inspekcja 4. Naprawa 5. Sprawdzenie

Inspekcje Fagana Projekt Specyfikacje zewnętrzne (specyfikacja wymagań) Specyfikacje wewnętrzne (moduły kodu) Specyfikacje logiki przetwarzania Inspekcja projektu (I1) Kod Kodowanie Inspekcja kodu (I2) Testowanie jednostkowe (unit test) Inspekcja oprogramowania (I3) Testy

Oszczędności [godz/kilo Lines Of Code]: I1: 94 I2: 51 I3: -20

Lista kontrolna inspekcji projektu według Fagana Missing Czy wszystkie stałe są zdefiniowane? Czy w trakcie manipulacji kolejką może wystąpić przerwanie? Czy liczniki są zainicjowane (0 lub 1)? Czy rejestry są odtwarzane przy wyjściu? Wrong Czy są literały numeryczne, które powinny być zastąpione stałymi symbolicznymi? Extra Czy wszystkie bloki na schemacie są potrzebne?

Szacowanie liczby defektów Wstrzykiwanie defektów: Dodajemy n defektów do artefaktu Przekazujemy do kontroli jakości Otrzymujemy raport, wykryto m+k defektów: k defektów przez nas dodanych m defektów nowych Liczba defektów to około m*n/k Dla k=0 inspekcje koniecznie powtórzyć

Szacowanie liczby defektów 2-krotne łowienie (capture-recapture) Metoda opracowana w latach 50-tych przez biologów. Ile ryb jest w stawie? Łowimy próbkę ryb o wielkości n Oznaczamy je i wypuszczamy Łowimy drugą próbkę, o wielkości m z tego k oznakowanych n*m/k ryb jest w stawie

Szacowanie liczby defektów 2-krotne łowienie (capture-recapture) W kontroli jakości: n to ilość błędów znalezionych przez jednego recenzenta, m to ilość błędów znalezionych przez drugiego recenzenta, k to wielkość części wspólnej (błędy znalezione przez obu recenzentów) Dla więcej niż 2 recenzentów wybieramy recenzenta, który znalazł najwięcej unikatowych błędów (n) i całą resztę traktujemy jako drugiego recenzenta (m)