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

Podobne dokumenty
<Nazwa firmy> <Nazwa projektu> Specyfikacja wymagań projektu. Wersja <1.0>

Zdalne monitorowanie i zarządzanie urządzeniami sieciowymi

IO - Plan wdrożenia. M.Jałmużna T.Jurkiewicz P.Kasprzyk M.Robak. 5 czerwca 2006

Dokument Detaliczny Projektu

SPECYFIKACJA WYMAGAŃ

Projekt i implementacja filtra dzeń Pocket PC

Web frameworks do budowy aplikacji zgodnych z J2EE

Kwestionariusz dotyczący działania systemów teleinformatycznych wykorzystywanych do realizacji zadań zleconych z zakresu administracji rządowej

Usługa: Testowanie wydajności oprogramowania

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

ZAŁĄCZNIK NR 3 OPIS PRZEDMIOTU ZAMÓWIENIA DOTYCZĄCY WDROŻENIA PLATFORMY ZAKUPOWEJ

Praca dyplomowa. Program do monitorowania i diagnostyki działania sieci CAN. Temat pracy: Temat Gdańsk Autor: Łukasz Olejarz

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Specyfikacja wymagań systemowych (może podlegać edytowaniu na kolejnych etapach)

Zasady organizacji projektów informatycznych

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Inżynieria Programowania Zarządzanie projektem

Inżynieria Programowania Zarządzanie projektem. Plan wykładu. Motto. Motto 2. Notatki. Notatki. Notatki. Notatki.

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

Aplikacja serwerowa Platformy Prezentacyjnej Opis produktu

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

Plan Testów Systemu SOS

Wykład 7. Projektowanie kodu oprogramowania

WPROWADZENIE DO UML-a

ECDL Podstawy programowania Sylabus - wersja 1.0

EFEKTY KSZTAŁCENIA DLA KIERUNKU STUDIÓW

nr ref. PI01/31/2016 Załącznik nr 1 do Umowy DEFINICJE

PRZEWODNIK PO PRZEDMIOCIE

Warszawa, Kategorie analizy frameworków GUI

PROCEDURA ADMINISTROWANIA ORAZ USUWANIA AWARII I BŁĘDÓW W CSIZS

OGŁOSZENIE DODATKOWYCH INFORMACJI, INFORMACJE O NIEKOMPLETNEJ PROCEDURZE LUB SPROSTOWANIE

Tom 6 Opis oprogramowania

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

1. Definicja pojęć Celem opisania warunków świadczenia usług gwarancji jakości Systemu i Asysty Powdrożeniowej definiuje się następujące pojęcia:

Uniwersytet Mikołaja Kopernika. Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej

KARTA PRZEDMIOTU. 1. Informacje ogólne. 2. Ogólna charakterystyka przedmiotu. Inżynieria oprogramowania, C12

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

Dlaczego testowanie jest ważne?

Programowanie sterowników przemysłowych / Jerzy Kasprzyk. wyd. 2 1 dodr. (PWN). Warszawa, Spis treści

Dokument Detaliczny Projektu

Tom 6 Opis oprogramowania Część 8 Narzędzie do kontroli danych elementarnych, danych wynikowych oraz kontroli obmiaru do celów fakturowania

Biorąc udział w projekcie, możesz wybrać jedną z 8 bezpłatnych ścieżek egzaminacyjnych:

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

Programowanie Komponentowe WebAPI

Forum Client - Spring in Swing

Systemy wbudowane. Paweł Pełczyński

Język programowania. Andrzej Bobyk

Opracował: Jan Front

Dziennik Urzędowy Unii Europejskiej L 274/9

Uniwersytet Mikołaja Kopernika w Toruniu Wydział Matematyki i Informatyki Wydział Fizyki, Astronomii i Informatyki Stosowanej Instytut Fizyki

Opis Przedmiotu Zamówienia

Poziomy wymagań Konieczny K Podstawowy- P Rozszerzający- R Dopełniający- D Uczeń: - zna rodzaje sieci - zna topologie sieciowe sieci

Zaawansowane programowanie w języku C++

Etapy życia oprogramowania

1. Wyjaśnienia/Zmiana treści specyfikacji istotnych warunków zamówienia/przedłużenie terminu składania ofert

ZAPYTANIE OFERTOWE. Zamawiający. Przedmiot zapytania ofertowego. Wrocław, dnia r.

Od uczestników szkolenia wymagana jest umiejętność programowania w języku C oraz podstawowa znajomość obsługi systemu Linux.

Zarządzanie infrastrukturą sieciową Modele funkcjonowania sieci

Dział Dopuszczający Dostateczny Dobry Bardzo dobry Celujący

Kurs wybieralny: Zastosowanie technik informatycznych i metod numerycznych w elektronice

Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej.

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

Wykład 2. Temat: (Nie)zawodność sprzętu komputerowego. Politechnika Gdańska, Inżynieria Biomedyczna. Przedmiot:

PRZEWODNIK PO PRZEDMIOCIE

Metodyka projektowania komputerowych systemów sterowania

Studium przypadku budowania skalowalnych stron www. Tomasz Paszkowski

Opis przedmiotu zamówienia

CZĘŚĆ III.3.1 DOKUMENTACJA PROJEKTOWA

Opis metodyki i procesu produkcji oprogramowania

PROJEKT INTERFEJSU UśYTKOWNIKA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU>

Generated by Foxit PDF Creator Foxit Software For evaluation only. System Szablonów

Niniejszy załącznik reguluje sposób monitorowania, raportowania i rozliczenia poziomu świadczenia zakontraktowanych Usług.

Procedura Walidacyjna Interfejs

Ełk, dn r. DOMSET Marcin Brochacki. ul. Wojska Polskiego 43 lok. 3, Ełk. Nip ZAPYTANIE OFERTOWE

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

Overlord - Plan testów

Warstwy systemu Windows 2000

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Tester oprogramowania 2014/15 Tematy prac dyplomowych

Podstawy Techniki Komputerowej. Temat: BIOS

Plan testów. Robert Dyczkowski, Piotr Findeisen, Filip Grzdkowski. 4 czerwca 2006

Komputery przemysłowe i systemy wbudowane

Zał nr 4 do ZW. Dla grupy kursów zaznaczyć kurs końcowy. Liczba punktów ECTS charakterze praktycznym (P)

Wykład 1 Inżynieria Oprogramowania

Zarządzanie i realizacja projektów systemu Microsoft SharePoint 2010

Systemy operacyjne III

Co to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?

Tworzenie oprogramowania

Przygotowanie do nowoczesnego programowania po stronie przeglądarki. (HTML5, CSS3, JS, wzorce, architektura, narzędzia)

Galileo - encyklopedia internetowa Plan testów

dr inŝ. Michał Tomaszewski Wydział Elektrotechniki, Automatyki i Informatyki Politechnika Opolska

Architektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.

Wykłady z przedmiotu Sieci komputerowe podstawy Wykład 12

SLA ORAZ ZASADY ŚWIADCZENIA WSPARCIA I HELPDESK. Wykonawca zobowiązuje się do świadczenia Usług Wsparcia i Helpdesk w odniesieniu do Systemu.

JTW SP. Z OO. Zapytanie ofertowe. Zewnętrzny audyt jakościowy projektu technicznego dedykowanego systemu B2B Platforma Integracji Serwisowej

Jak opisać wymagania zamawiającego wybrane elementy

WARUNKI GWARANCJI I SERWISU GWARANCYJNEGO

Strona znajduje się w archiwum.

PROGRAM PRAKTYKI ZAWODOWEJ. Technikum Zawód: technik informatyk

Transkrypt:

<Nazwa firmy> <Nazwa projektu> Wersja <1.0> [Uwaga: Niniejszy wzór dostarczony jest w celu użytkowania z Unified Process for EDUcation. Tekst zawarty w nawiasach kwadratowych i napisany błękitną kursywą (styl=infoblue) to wskazówki dla autora dokumentacji, które powinny zostać usunięte przed publikacją dokumentu.]

Historia zmian Data Wersja Opis Autor <dd/mm/rrrr> <x.x> <opis zmian> <imię i nazwisko> Poufne <Nazwa firmy>, 2009 Strona 2

Spis treści 1. Wprowadzenie 4 1.1 Cel 4 1.2 Zakres 4 1.3 Pojęcia 4 1.4 Odniesienia 4 1.5 Streszczenie 4 2. Założenia i zależności 4 3. Używalność 4 3.1 <Pierwsze wymaganie używalności> 4 4. Niezawodność 4 4.1 <Pierwsze wymaganie niezawodności> 5 5. Wydajność 5 5.1 <Pierwsze wymaganie wydajności> 5 6. Kompatybilność 5 6.1 <Pierwsze wymaganie kompatybilności> 5 7. Ograniczenia projektowe 5 7.1 <Pierwsze ograniczenie projektowe> 5 8. Bezpieczeństwo 5 9. Wymagania dotyczące instrukcji użytkownika i pomocy 6 10. Interfejsy 6 10.1 Interfejsy użytkownika 10.2 Interfejsy sprzętowe 6 6 10.3 Interfejsy programowe 6 10.4 Interfejsy komunikacyjne 6 11. Zastosowane standardy 6 Poufne <Nazwa firmy>, 2009 Strona 3

1. Wprowadzenie 1.1 Cel 1.2 Zakres [Sekcja wprowadzająca zawiera opis całego dokumentu SD. Zawiera wszelkie niezbędne informacje potrzebne do zrozumienia dokumentu przez użytkownika. Celem stworzenia dokumentu SD jest opisanie wymagań nie uwzględnionych w diagramie przypadków użycia, takich jak regulacje prawne odnośnie projektu, środowisko działania (system operacyjny, etc.) czy parametry jakościowe (niezawodność, wydajność, etc.).] [Niniejsza sekcja określa cel tworzenia SD..] [Sekcja ta pokrótce opisuje jakiego projektu SD dotyczy, co wpływa na kształt SD i na co sama SD ma wpływ.] 1.3 Pojęcia [Sekcja ta zawiera definicje pojęć czy skrótów niezbędnych do zrozumienia SD. Może być po prostu odniesieniem do Słownika.] 1.4 Odniesienia [Niniejsza sekcja zawiera informacje na temat wszelkich źródeł zewnętrznych, do których odniesienia znajdują się w SD. Opis źródła powinien zawierać jeśli to możliwe informacje o jego tytule, autorze, wersji, dacie publikacji oraz wydawnictwie.] 1.5 Streszczenie [Niniejsza sekcja opisuje resztę zawartości SD oraz sposób, w jaki jest ona zorganizowana.] 2. Założenia i zależności [Sekcja ta zawiera opis wszystkich projektów, technologii, podsystemów i komponentów na których bazuje lub od których zależny jest system..] 3. Używalność [Sekcja ta zawiera opis wszystkiego co wpływa na używalność projektu. Są to przede wszystkim: czas treningu użytkowników, czasy typowych zadań projektowych oraz wymagania, jakie stoją przed systemem, aby spełnił założone standardy, na przykład IBM s CUA czy Microsoft s GUI.] 3.1 <Pierwsze wymaganie używalności> 4. Niezawodność [Niniejsza sekcja zawiera opis warunków jakie system powinien spełniać pod względem niezawodności i potencjalnej awaryjności. Określa się tu przede wszystkim: Dostępność procent czasu, w którym system pracuje poprawnie i jest dostępny, typowe godziny użytkowania, zakres obsługi serwisowej, etc.. Poufne <Nazwa firmy>, 2009 Strona 4

Średni czas pomiędzy awariami zakładany średni czas jaki upływa pomiędzy krytycznymi awariami system mierzony w godzinach, dniach, miesiącach. Średni czas awarii ile czasu średnio potrzebne jest od wystąpienia awarii do naprawy systemu. Dokładność określenie dokładności na wyjściu systemu na podstawie obowiązujących standardów. Maksymalna ilość błędów określa się ją w ilości błędów na tysiąc linii kodu lub ilości błędów na funkcjonalność. Błędy nieznaczące, znaczące i krytyczne. Należy przede wszystkim określić co uznawane jest za błędy krytyczne.] 4.1 <Pierwsze wymaganie niezawodności> 5. Wydajność [Sekcja ta definiuje specyfikację wydajnościową systemu. Mile widziane są tu odniesienia do konkretnych przypadków użycia. Zdefiniowane są tu między innymi: Czas odpowiedzi systemu na zdarzenia średni i maksymalny. Przepustowość z reguły w transakcjach na sekundę. Pojemność maksymalna ilość klientów i transakcji, które system jest w stanie obsłużyć na raz. Tryby awaryjne w jaki sposób powinien zachowywać się system w razie uszkodzenia. Zużywane zasoby pamięć RAM, pojemność dysku twardego, karty sieciowe, etc. 5.1 <Pierwsze wymaganie wydajności> 6. Kompatybilność [Ta sekcja opisuje wszelkie wymagania wobec obowiązujących standardów jakie system musi spełniać. Są to na przykład konwencje nazewnictwa zmiennych i funkcji, użyte biblioteki, dostęp serwisowy, narzędzia serwisowe, standardy tworzenia kodu] 6.1 <Pierwsze wymaganie kompatybilności> 7. Ograniczenia projektowe [Sekcja ta opisuje wszelkie ograniczenia nałożone na projekt, których muszą trzymać się jego twórcy. Dotyczy ona przede wszystkim wybranych języków programowania, narzędzi programistycznych, architektury system, komponentów i bibliotek klas.] 7.1 <Pierwsze ograniczenie projektowe> 8. Bezpieczeństwo [Sekcja ta obejmuje opis zagrożeń systemu, przede wszystkim zagrożeń danych. Sprecyzowane w niej jest jakie dane mogą być zagrożone oraz co lub kto może spowodować zagrożenie danych,, a przede wszystkim podjęte środki ostrożności i obrony przed zagrożeniami (ograniczenia dostępu do systemu, kodowanie danych, etc.). Definiowane tu są również obiekty, które wymagają sprzętowej lub programowej ochrony.] Poufne <Nazwa firmy>, 2009 Strona 5

9. Wymagania dotyczące instrukcji użytkownika i pomocy [Sekcja ta zawiera opis wymagań stawianych przed dokumentacją dostępną dla użytkownika systemu, taką jak instrukcja obsługi, internetowa instrukcja obsługi, centrum pomocy, etc. ] 10. Interfejsy [Sekcja ta definiuje interfejsy, które mają być wspierane przez projekt. Definicja interfejsu powinna określać jego dokładną specyfikację, wliczając w nią protokoły, adresy, porty. Etc, tak, aby w fasie testów można było bez problemu zweryfikować zgodność. Generalnie są to interfejsy, których nie obejmuje zakres projektowy, ale które muszą być obsługiwane przez system.] 10.1 Interfejsy użytkownika [Sekcja ta pokrótce opisuje konieczne do implementacji interfejsy użytkownika i posiada odniesienie do dokumentu Projekt interfejsu.] 10.2 Interfejsy sprzętowe [Ta sekcja opisuje interfejsy sprzętowe, jakie system musi wspierać. W skład opisu wchodzi struktura, adres fizyczny, oczekiwane działanie, etc.] 10.3 Interfejsy programowe [Sekcja ta definiuje interfejsy programistyczne służące do połączeń z innymi częściami systemu. Mogą to być moduły pochodzące z innych aplikacji, gotowe moduły komercyjne.] 10.4 Interfejsy komunikacyjne [Sekcja ta zawiera opis interfejsów, za pomocą których system komunikować się będzie z innymi urządzeniami lub systemami. Są to na przykład połączenia zdalne, sieć lokalna, etc.] 11. Zastosowane standardy [Sekcja ta zawiera opis i odniesienia do standardów stosowanych przy tworzeniu projektu, dotyczy to standardów prawnych, przemysłowych, etc.] Poufne <Nazwa firmy>, 2009 Strona 6