Projekty zespołowe. - biznesowy z analizą strategiczną - przedsięwzięcia: opis ogólny produktu. 2. Zakres

Transkrypt

1 Projekty zespołowe 1. Warunki wstępne 1. Studenci wykonują projekty w zespołach 5-7 os., każdy zespół ma inny temat 2. Każdy zespół pracuje zgodnie z wybraną/przydzieloną metodyką (np. Prince, Scrum, TenStep, PMB). 3. Zespoły wykorzystują ogólnodostępne narzędzia (np. Redmine, Project, RUP, VParadigm). 4. Obecność na zajęciach jest obowiązkowa dop. 3 nieobecności w tym 1 - nieusprawiedliwiona. 5. Składniki (pliki i nagłówki poczty) dot. projektu zespołowego proszę oznaczać 8-mio znakowym prefiksem (szczegóły na stronie internetowej przedmiotu) 6. Nazwę projektu indywidualnego proszę rozpoczynać opisem ZPI-nazwisko. 7. Wyniki kolejnych etapów należy wysyłać sukcesywnie (wstępnie wystarczy zaliczyć i wysłać szkice zdjęcia i/lub skany np ze spotkań zespołu) 2. Zawartość projektu (np wg przykładu w materiałach na serwerze Cw4 ) I. Dokument wstępny przedsięwzięcia - może być oparty na tzw. strukturze OSCAR, która zawiera: Objectives cele, Scope zakres, Constrains warunki, Authority uprawnienia, Resourses zasoby 1. Cele : 2. Zakres - biznesowy z analizą strategiczną - przedsięwzięcia: opis ogólny produktu Opis ogólny produktów 3. Warunki a) termin wykonania (zakończenia) czas realizacji projektu b) metody: planowania, zarządzania 4. Uprawnienia struktura organizacyjna 5. Zasoby ogólny stan sprzętowy, materiałowe, finansowe II. Plan szczegółowy (dla pkt 3 6 można wykorzystac MS Project) 1. Zasoby - szczegółowa skład osobowy, sprzętu i materiałów 2. Zrozumienie zależności: diagram sieciowy 3. Harmonogram: wykres Gantta 4 Przydział zadań. 5. Koszty realizacji przedsięwzięcia. 6. Widoki dot: Analizy kosztów, pracy i czasu dla zasobów. III. Projekt Produkty analizy (notatki, analiza i specyfikacja) Pełne wymagania funkcjonalne (spis oczekiwań klienta) określić aplikacje i systemy, z którymi musimy zintegrować system Wymagania technologiczne - konfiguracja zasobów i komunikacja, wymagania niefunkcjonalne (środowisko działania, system operacyjny, wymagania sieciowe) Przypadki użycia i diagramy (danych ER, BD, diagram Klas i inne) dla pełnej funkcjonalności Scenariusze szczegółowe mogą być 2 podstawowy i najciekawszy Plan testów w szczególności dot. wybranych scenariuszy. IV Implementacja Tymczasowa wersja dystrybucyjna - może być minimalna w szczególności dla uruchomionych i przetestowanych scenariuszy użycia. V Inna dokumentacja - z przebiegu procesu zarządzania projektem (np. skany z notatek, szkiców itp.) zależy od przyjętej metodyki zarządzania VI. Produkty jakościowe plan i opis zarządzania ryzykiem wg pkt 5.0 w Cw 4 - przykładowe fragmenty plan i wyniki testów wg pkt 6.0 w Cw 4 - przykładowe fragmenty VII. Dokumentacja techniczna lub projekt pkt III VIII Dokumentacja użytkownika np. opis obsługi, ekran wybranego scenariusza

2 Zarządzanie ryzykiem: wykonać opis wybranego ryzyka, planowania i kontroli 1. Nazwa ryzyka.. 2. Zakres ryzyka Opis jakościowy zdarzeń (skali, rodzaju i liczby, a także zdarzeń pochodnych) 3. Charakter ryzyka Np. strategiczne, operacyjne, finansowe, związane z zarządzaniem wiedzą lub zgodnością z przepisami 4. Grupy nacisku Grupy nacisku i ich oczekiwania 5. Opis ilościowy ryzyka Znaczenie i prawdopodobieństwo ryzyka 6. Tolerancja w zakresie ryzyka (poziom akceptowanego ryzyka) Potencjalna wielkość strat i skutki finansowe realizacji ryzyka. Zagrożone aktywa. Prawdopodobieństwo i wielkość potencjalnych szkód/korzyści Cele w zakresie kontrolowania ryzyka i optymalne wyniki 7. Działania względem ryzyka i mechanizmy kontroli Podstawowe środki stosowane obecnie do zarządzania danym ryzykiem. Poziom pewności przy obecnych mechanizmach kontroli. Istniejące procedury monitorowania i analizy systemu 8. Potencjalne możliwości poprawy sytuacji Zalecenia służące zmniejszeniu ryzyka 9. Opracowanie strategii i planów krótkookresowych Określenie osób odpowiedzialnych za opracowanie strategii i planów krótkookresowych Zarządzanie Jakością Plan Testów Plan testów jest podstawowym dokumentem w procesie testowym. Poniżej prezentujemy wzór formularza dla planu testów dla metodyki tworzenia oprogramowania zgodnej z modelem V lub metodyką wodospadową. Może on znaleźć zastosowanie również w metodach iteracyjnych. Wzór planu testów Wzór planu zawiera klasyfikację defektów pod kontem ich ważności. Nazwa produktu Plan testów Imię i nazwisko autora.. Wersja I. Wstęp 1.Tworzenie nazw plików :Standard nazywania plików. 2.Wprowadzenie :Wprowadzenie do projektu. 3. Cele :Co chcemy osiągnąć mówiąc o parametrach: jakość, plan i koszty. 4. Podejście :Strategia testów mająca doprowadzić do osiągnięcia pożądanych celów.

3 II. Opis testów 1. Testowany obiekt :Produkt lub aplikacja będąca celem testów Obiekt :Aplikacja Główny plik wykonalny, Instalacja/deinstalacja, Funkcje/Narzędzia, Pomoc online 1.2. Obiekt : Dodatki Czcionka, Clip Art., Powiązane multimedia, Przykład/ tutorial, Czytajto, Inne 1.3. Obiekt : Dokumentacja Przewodnik, CD, Opakowanie, Marketing/Informacje o produkcie, Pakiet reklam 2. Funkcjonalność do przetestowania Lista rzeczy do przetestowania. Może zawierać opis środowiska testowego. 3. Funkcjonalność nietestowana Lista rzeczy niepodlegająca testowaniu, lub nieuwzględnionych w tym planie testów. 4. Wymagania systemowe Wymagania konfiguracyjne dla oprogramowania i sprzętu. Wymagania dla środowiska klienta. 5. Wejście/Wyjście dla procesu tworzenia produktu Opis kamieni milowych lub/i kryteriów akceptacyjnych dla aplikacji. 7. Dostawy testowe Lista materiałów przygotowanych przez grupę testową podczas cyklu testowego dostarczanych do projektu. 7.1 Plan testów Wstępny plan testów (zaaprobowany) Kompletny dokument zawierający potwierdzenie ważności Dokumenty dodatkowe do planu wykonanych testów Tablice przypadków testowych, matryce oraz inne materiały powiązane z testami z określonymi potwierdzeniami weryfikacji i ukończeniem testów Finalny plan testów(zaaprobowany) Końcowy plan testów jest pomniejszą wersją planu testów programistycznych. Plan ten jest wyprodukowany i używany w końcowych cyklach testów. Musi zawierać potwierdzenia zgodności Dokumenty dodatkowe do planu finalnych testów Tablice przypadków testowych, matryce oraz inne materiały powiązane z testami z określonymi potwierdzeniami weryfikacji i ukończeniem testów System śledzenia defektów Raporty defektów - Lista podsumowująca znalezione defekty - Pełny opis defektów Baza danych defektów Baza defektów znalezionych podczas cyklu testowego służąca zazwyczaj do wymiany informacji tester - programista. 7.3 Końcowy raport wydania Raport, który powinien być wydany przed zakończeniem projektu. Raport ten jest dokumentem oceniającym, jakość będącą w zakresie testowania projektu, kompletności testowania, rezultatów dla najważniejszych obszarów oraz rekomendacja lub jej brak do wydania produktu (klientowi lub na rynek). III. Zarządzanie projektem testowym 1. Zespół projektowy. Lista wraz z rolami. - osoby odpowiedzialne i zarządzające i inne 2. Zadania testowe - Stworzenie planów testów wraz z przypadkami testowymi, matrycami i planami etc. - Poddanie planu testów procesowi przeglądu wraz z zatwierzeniem - Uzyskanie wymagań dla sprzętu, oprogramowania i narzędzi - Stworzenie bazy danych defektów.

4 - Przeprowadzenie testów - Zaraportowanie błędów - Przeprowadzenie spotkania dotyczącego defektów - Stworzenie cotygodniowego raportu - Stworzenie końcowego raportu 4. Plan oraz harmonogram testów Co będzie dostawą testów? Kiedy poszczególne dostawy będą realizowane? 5. Definicje, opisy oraz mierzalne kryteria wejścia i wyjścia dla punktów kontrolnych projektu 6. Harmonogram planu testów: lista grup zadań testowych wraz z opisem, przypisanie zadań do osób, ocena ilości osób potrzebnych do ukończenie projektu. 7. Potrzeby treningowe: zidentyfikowane potrzeby dokształcenia osób w projekcie. 8. Potrzeby środowiskowe- komponenty i narzędzia testowe Sprzęt oraz oprogramowanie potrzebne do ukończenia projektu: dostępność strategia w ich pozyskiwaniu - do kupienia na zewnątrz, wewnętrzne lub które należy stworzyć budynki, sprzęt, serwisy w laboratorium, w firmie konieczność zatrudnienia firmy zewnętrznej (zmiana planu) 9. Plan integracji: czy jest zgodny ze strategią testów? 10. Zawieszenie i ponowne rozpoczęcie testów (kiedy) 11. Kryterium zakończenie testów 12. Proces śledzenia defektów: 12.1 Opis procesu, narzędzie śledzenia defektów (baza danych) i jego opis Definiowanie ważności defektów - ocena ważności błędu - subiektywna metoda, raportuje stopień ważności wg wytycznych. Krytyczne Defekt krytyczny (ang. show-stopper - blokujący wydanie) występuje, gdy brakuje podstawowej funkcjonalności, użyteczności lub wydajności produktu podczas normalnych operacji; nie ma możliwości stworzenia "obejścia" (ang. workaround). Błąd danych podstawowych - zaliczamy do tej kategorii również defekty niezwiązane z funkcjonalnością, ale będące jasnymi pomyłkami w np. w nazwie firmy, złym klipem video na ekranie początkowym, błędna instrukcja obsługi etc Wyłączenie lub uszkodzenie aplikacji/sprzętu Utrata danych lub ich uszkodzenie Brak sukcesu przy wykonywaniu podstawowych funkcji Muszą zostać naprawione w cyklu tworzenia oprogramowania. Poważne Defekt poważny - najważniejsze funkcjonalności nie działają prawidłowo w określonych warunkach, funkcjonalności drugiego rzędu nie działają w ogóle, słaba jakość funkcjonalności lub wydajności podczas normalnych operacji, trudności z użyciem podstawowych funkcjonalności. Zasadniczo lub czasami w ostatecznej fazie testowej mogą zostać zaakceptowane. Niekrytyczne Niekrytyczne defekty wprowadzają czasami pewne problemy w obsłudze. np problemy w wyświetlaniu, błędy językowe i inne mniej istotne. Powinny być naprawione kiedy czas na to pozwoli z minimalnym nakładem sił. Wiele małych błędów może się przełożyć na ogólną niską ocenę jakości produktu. 13. Śledzenie statusu testów i raportowanie W jakiej formie będą prezentowane raporty? Z jaką częstotliwością będą pojawiać się raporty? Jakie formacje zostaną zaraportowane? 14. Incydenty i możliwe przypadki zmiany planu testów. 15. Proces potwierdzania zgodności - planu testów - jak przygotowuje się plan testów i kto za niego odpowiada? - testu końcowego wydanego produktu - jak wygląda proces potwierdzania wydania produktu?

5 Literatura Dariusz Rafał Augustyn, Łukasz Wyciślik, Łukasz Warchał System monitorowania zgłoszeń, rozszerzeń i defektów aplikacji WWW, bazujący na mechanizmie przepływu zadań Microsoft Workflow Foundation, Konferencja TenStep. TenStep Project Management Process: Syntetyczny opis głównych procesów zarządczych. [dostęp ]. TenStep Project Management Process - prosty sposób na sukces. [dostęp ]. Prince Oficjalna strona PRINCE2 Oficjalna informacja o PRINCE2 na stronach OGC PRINCE2 Wiki MPBok Oficjalna strona PMI