www.iookkk.fora.pl

Krzysiek · Dołączył: 23 Mar 2008 Posty: 8 Przeczytał: 0 tematów Ostrzeżeń: 0/5

******opis pliku******
*******buc.pdf********

Biznesowe przypadki użycia serwisu „LÓZ”

Pierwszy rozdział tego dokumentu jest krótki, więc przytoczę go w całości:

##POCZĄTEK##
1 Wprowadzenie
Niniejszy dokument opisuje biznesowe przypadki uzycia systemu „LÓZ”.
1.1 Cel
Celem tego dokumentu jest opisanie działania systemu „LÓZ” w kontekscie procesów biznesowych
zachodzacych u odbiorcy systemu.
1.2 Zakres
Dokument obejmuje swoim zakresem jedynie kilka podstawowych przypadków biznesowego
uzycia systemu.
1.3 Definicje
• LÓZ – nazwa tworzonego serwisu internetowego,
• uzytkownik – docelowy uzytkownik systemu „LÓZ”,
• programista – uzytkownik systemu „LÓZ”, który posiada umiejetnosci i chec, by dostarczac nowe gry do systemu, oraz zaznaczył to w formularzu w trakcie tworzenia swojego
konta i podał numer rachunku bankowego,
• moderator – osoba wyznaczona przez operatora systemu „LÓZ” do nadzorowania działania
systemu; moderator jest z definicji uzytkownikiem,
• stronaWWW– dokument w formacie HTML lub XHTML przeznaczony do otwierania w
przegladarce internetowej,
• strona internetowa – stron WWW,
• witryna internetowa – zbiór powiazanych ze soba˛ stron internetowych opublikowanych w
internecie w ramach jednej domeny internetowej,
• serwis WWW – witryna internetowa,
• HTML – (HyperText Markup Language) jezyk słuzacy do pisania stron WWW,
• XHTML – (Extensible HyperText Markup Language) nastepca HTML,
1.4 Załaczniki
Przypadki uzycia serwisu „LÓZ” – dokument omawiajacy szczegółowo przypadki uzycia serwisu.
Niniejszy dokument odwołuje sie do niego w kwestiach przebiegu poszczególnych czynnosci wchodzacych w skład procesu biznesowego.
1.5 Omówienie reszty dokumentu
W dalszej czesci dokumentu kolejno omówione zostanie kilka najwazniejszych przypadków biznesowego uzycia.
##KONIEC##

Jak widać, to wprowadzenie właściwie nie zawiera żadnych użytecznych informacji (tak jak zresztą mówił wykładowca – jest to tylko wypełnienie szablonu). Wydaje mi się, że nie ma sensu pisać w naszych „wymaganiach funkcjonalnych” czegoś podobnego.

W dalszej części tego dokumentu zostały bardzo pobieżnie opisane tylko trzy przykładowe przypadki użycia (granie w grę, dodanie własnej gry, przeglądanie forum), na przykład:

##POCZĄTEK##
2 Granie w gre
2.1 Krótki opis
Ten przypadek uzycia opisuje podstawowy proces biznesowy serwisu „LÓZ”, czyli granie w gre
przez uzytkownika-internaute.
2.2 Cele
Jest to podstawowe zródło przychodów z serwisu „LÓZ”.
2.3 Wydajnosc
Problem wydajnosci został omówiony w załaczniku.
2.4 Warunki wstepne
- Uzytkownik posiada konto w systemie.
- Uzytkownik wykupił zetony i posiada ich wystarczajaca ilosc, by zagrac w gre.
2.5 Czynnosci
Czynnosci podstawowe
1. Uzytkownik loguje sie do systemu.
2. Uzytkownik wybiera gre, w która chce zagrac.
3. Z konta uzytkownika pobierane sa zetony – opłata za gre.
4. Uzytkownik gra w gre.
Czynnosci alternatywne
1. Punkty 1 i 2 jak w Czynnosciach podstawowych.
2. Uzytkownik nie posiada wystarczajacej ilosci zetonów, wiec zostaje rozpoczety proces
doładowania konta.
2.6 Błedy
- Uzytkownik nie posiada wystarczajacej ilosci zetonów.
- Uzytkownik nie ma konta w systemie.
2.7 Inne wymagania
Komputer, którym posługuje sie uzytkownik spełnia wymagania niezbedne do uruchomienia
wybranej gry. Poszczególne gry moga sie róznic wymaganiami systemowymi
##KONIEC##

Zajrzałem do podobnego dokumentu „uc.pdf” i tam ten sam przypadek użycia ma trochę dłuższy opis (dodatkowo zamiast opisywać czynności, dzieląc je na podstawowe i alternatywne, został narysowany diagram UML). Wydaje mi się więc, że powinniśmy wzorować się właśnie na pliku „uc.pdf” w opisie naszych „wymagań funkcjonalnych”.

WNIOSEK
Dokument „buc.pdf” jest jakąś wstępną wersją dokumentu „uc.pdf”. Biorąc pod uwagę fakt, że „checkpoint” będzie dopiero na siódmych zajęciach, ten plik nie będzie nam w ogóle potrzebny (jako zbyt krótki).

******opis pliku******
*******ap.pdf*********

Plan akceptacji systemu „LÓZ”

Jak sama nazwa wskazuje, teraz nie będziemy tego robić. Ustaliliśmy jednak na ćwiczeniach, aby podać opis wszystkich plików (przyda się nam później), więc poniżej przedstawiam co ten plik zawiera:

Celem tego dokumentu jest określenie sposobu przekazania systemu „LÓZ” firmie, która zleciła jego wykonanie.

Rozdział 2 określa zakres odpowiedzialności Zespołu oraz Zleceniodawcy w czasie przekazywania Systemu LÓZ Zleceniodawcy (bardzo krótki – tylko 6 zdań określających tę odpowiedzialność).
Rozdział 3 określa kroki odbioru projektu:
z czego składa się dokumentacja, w jakich okolicznościach firma ją akceptuje
z czego składa się oprogramowanie, w jakich okolicznościach firma je akceptuje, w jaki sposób będzie się je testować (szczegółowy opis harmonogramu różnego rodzaju testów).
Rozdział 4 określa sprzęt używany podczas testów (ile i jakie komputery), oprogramowanie zainstalowane na tym sprzęcie (jaki będzie system operacyjny i przeglądarka internetowa na komputerach, które nie są serwerami), kto będzie reprezentował Zleceniodawcę podczas testów, jakie będą dane testowe dla programu (np. 10000 przykładowych loginów).
Rozdział 5 omawia rozpoznawanie problemów i reakcje na problemy, czyli co się dzieje, gdy podczas testów wykryjemy błąd (kiedy przerywamy testy, kiedy Zleceniodawca uznaje błąd za poważną usterkę).
Rozdział 6 omawia środowisko odbioru produktu, jest nim na przykład opis postaci:
- Wszystkie komputery znajdują sie w siedzibie Zleceniodawcy.
- Komputery spełniają wymagania sprzętowe i dotyczące oprogramowania opisane w punktach 4.1 i 4.2.
- Komputery są podłączone do Internetu.
Rozdział 7 omawia wymagane kroki kontroli – tabelka określająca w jaki sposób będą przeprowadzane testy, będzie ona miała kolumny:
testowany komponent (np. serwer WWW, aplikacja użytkownika), sprawdzana funkcjonalność (np. logujemy 10000 użytkowników), sposób przeprowadzenia testu (przez skrypt czy ręcznie), cel przeprowadzenia testu (np. sprawdzenie wydajności).

Konrad K · Gość

Wszystko spoko tylko mogłeś napisać o co chodzi z tym LÓZ. Wydaje mi się że nazwaliśmy już nasz projekt SGI, więc troche to było mylące ( no chyba że to nie o nasz serwis chodzi? ).
Jeśli to jednak chodzi o ten nasz serwis to mam drobną uwage odnośnie definicji w BUC:
przy definiowaniu moderatora piszesz o operatorze którego wcześniej, ani później nie definiujesz;
jeszcze jedna rzecz:
wydaje mi się że programista to nie jest ktoś kto korzysta z systemu. to jest ktoś, kto na zlecenie lub w inny sposób rozwija grę a to moderator/administrator/operator (czy jak kolwiek by go nazwać) będzie je dodawał. Nas nie obchodzi czy napisze to on czy programista...
Moim zdaniem powinniśmy zrobić tak, że są dwa rodzaje urzytkowników: zwykły user i administrator i tyle... po co więcej ?

Konrad K · Gość

Ogólnie chyba łątwo się domyśleć że chodzi o Wizje. Nie będe opisywał dokładnie tych punktów tylko może podam ich liste ( w nie oczywistych przypadkach dodatkowo też najważniejsze podpunkty ) ale też napisze "myśl przewodnią" tego dokumentu:
Dokument ten ma na celu zebranie, zanalizowanie i zdefiniowanie "high-level" zapotrzebowań i funkcji systemu. Skupia się na "capabilities needed by the stakeholders"? i na docelowych urzytkownikach, i dla czego zapotrzebowanie istnieje. Dokładnieszy opis o tym jak nasz system wypełnia te podrzeby powinien się znaleźć w use-case i w dodatkowych, załączanych specyfikacjach

Główne podpunkty:
1 Wprowadzenie
2 Kontekst produktu ( Korzyści, Postawienie problemu, Kontekst produktu )
3 Osoby mające wpływ na wymagania i projekt
4 Omówienie produktu ( Umiejscowienie produktu, Podsumowanie możiwości, Założenia i zależności, Koszta, Licencjonowanie i instalacja )
5 Własności produktu
6 Ograniczenia
7 Założenia jakościowe
8 Priorytety
9 Inne wymagania ( Standardy, Wymagania systemowe/wydajnościowe/środowiskowe )
10 Wymagania dokumentacyjne ( Podręcznik użytkownika, Pomoc on-line, Instalacja i konfiguracja, Oznaczenia markowe)
A Dodatek/Adnotacja 1 - Atrybuty funkcji/możliwości ? ( Feature Attributes )
B Historia zmian

Konrad K · Gość

use_case-template.tex

Use Case - Przypadki użycia
Dokument ten zawiera tekstowe własności przypadków użycia. Korzysta się z tego dokumentu wraz z narzędziem do zarządzania wymaganiami ( requirements managment tool , np Rational RequisitePro ), aby wyspecyfikować i zaznaczyć wymagania spośród "use case properties"

Diagramy przypadków użycia mogą być rozwijane przy pomocy narzędzi wizualnych ( np Rational Rose ). Dokument use-case może być wygenerowany za pomocą Rational SoDA. Więcej informacji jest jakoś powiązane z Rational Unified Process

Główne podpunkty:
1 <<Nazwa projektu>> Use Case
2 Czynności ( Czynności podstawowe, Czynności alternatywne )
3 Inne wymagania ( First Special Requirement )
4 Warunki wstępne ( wypunktowane )
5 Warunki końcowe ( wypunktowane )
6 Extension Points ( punkty to nazwy Extension Pointów )
7 Historia zmian

Te use case rozpoczyna się gdy aktor zaczyna coś robić. Aktor zawsze inicjuje przypadek użycia. Use case powinien opisywać co aktor robi i jak system odpowiada. Powinno to być przedstawione w formie dialogu pomiędzy aktorem a systemem.

Use case powinno opisywać CO dzieje się wewnątrz systemu, ale nie JAK ani CZEMU. Jeśli następuje wymiana informacji to należy dokładnie określić jakie informacje wchodzą do systemu, a jakie wychodzą.

Można tutaj załączać zdjęcia, obrazki, diagramy itp jeśli tylko poprawiają one czytelność i ułatwiają zrozumienie. Ważne aby dostosować pojęcia i zawiłość terminologii do poziomu osób które będą czytały ten dokument ( pewnie klient, a u nas to chyba będzie ktoś mało obeznany )

Konrad K · Gość

Apropo use case : w wikipedi angielskiej pod hasłem Use case są też opisane podpunkty

Krzysiek · Wysłany: Pon 16:52, 24 Mar 2008 Temat postu:

Projekt „LÓZ” był realizowany przez pewnych studentów na IO dwa lata temu.
Link do jego dokumentacji

(students.mimuw.edu.pl/~mn219541/IIrok/Inzynieria%20oprogramowania/dokumentacja/pdf/ )
podałem już wcześniej na forum.
Ponieważ jego tematyka jest podobna do naszego SGI, to warto zobaczyć jak zostały w nim zrealizowane szablony dokumentacji, które to z kolei można zobaczyć pod adresem:
mimuw.edu.pl/~kulisty/download/templates/.
Dzięki możliwości wglądu do tego podobnego projektu (tzn. LÓZ), można na nasze potrzeby ocenić na przykład jak obszerne mają być poszczególne części naszej dokumentacji, itp.
Dlatego też w moim opisie ZACYTOWAŁEM pewne fragmenty dokumentacji systemu „LÓZ”.
Nieporozumienie polega na tym, że nie zrozumiałeś właściwie tekstu, który poprzednio napisałem. Nie było w nim bowiem w ogóle mowy o zmianie nazwy naszego projektu. Myślałem, że będziesz pamiętał o tym, że na ostatnich ćwiczeniach podawałem link do „bliźniaczego” projektu „LÓZ”, z którego jedynie warto wyciągnąć pewne wnioski (jak razem wtedy przecież ustaliliśmy). Tak więc ani przez moment nie przyszło mi do głowy zmieniać nazwy naszego projektu. Zostajemy oczywiście przy nazwie SGI i dalej pracujemy nad jego realizacją.

Jak wspomniałem w poprzednim poście, szablony „biznesowe przypadki użycia” oraz „plan akceptacji systemu” nie będą nam teraz (tzn. w ciągu najbliższego czasu) raczej potrzebne.
Myślę więc, że powinniśmy zacząć od opisania „przypadków użycia” naszego systemu (czyli wymagań funkcjonalnych) zgodnie z szablonem ze strony:
mimuw.edu.pl/~kulisty/download/templates/use_case-template.tex.
A jak to zrobili w projekcie „LÓZ” można zobaczyć tutaj: students.mimuw.edu.pl/~mn219541/IIrok/Inzynieria%20oprogramowania/dokumentacja/pdf/uc.pdf .

Proponuję, aby opisać następujące przypadki użycia :
1. Rejestracja użytkownika
2. Ustawianie profilu użytkownika
3. Odzyskiwanie zapomnianego hasła
4. Zalogowanie użytkownika do systemu
5. Tworzenie stołu do gry
6. Zapraszanie do gry i rozpoczęcie partii
7. Przeglądanie listy obecnych zawodników
8. Gra przy pomocy programu komputerowego
9. Gra w turnieju
10. Ustawianie preferencji użytkownika do danej gry
11. Przypadki użycia podczas rozgrywania partii:
a) Rozmowa z przeciwnikiem (czat lub mikrofon)
b) Kontrola czasu (wyświetlanie zegarów rejestrujących czas gry, automatyczna przegrana zawodnika przekraczającego czas, jeśli oczywiście jego przeciwnik ma wystarczający materiał do wygrania partii)
c) Proponowanie remisu
d) Poddawanie partii
e) Wykonywanie ruchu
12. Przeglądanie forum
13. Pisanie na forum
14. Dodawanie nowych gier do systemu (przez administratora)
15. Usuwanie gier z systemu (przez administratora)
16. Organizacja turniejów (przez administratora)

W tych opisach możemy się oczywiście posłużyć fragmentami pliku:
students.mimuw.edu.pl/~kk236048/IO/funkcjonalnosc.pdf

Oczywiście, proponowane przypadki użycia pewnie nie są jeszcze ostateczne i wyczerpujące. Może uda Wam się jeszcze coś zauważyć/poprawić/dorzucić. Ja też będę jeszcze nad tym myślał.

Looknijcie też na proponowany wstępnie diagram związków encji: students.mimuw.edu.pl/~kk236048/IO/sgi2.png
Co jeszcze ewentualnie poprawić/dorysować ?

Konrad K · Gość

srs-template.tex

Software Requirements Specification
www microtoolsinc com/Howsrs.php
www techwr-l com/techwhirl/magazine/writing/softwarerequirementspecs.html
+ wikipedia

Ogólnie to wyczytałem że tutaj pisze się wymagania funkcjonalne i niefunkcjonalne chyba też... ale coś nie do końca idzie tego rozszyfrować.. jeszcze przez te długie strony nie przebrnąłem...

Template zawiera takie główne podpunkty:
1 Wstęp
2 Opis ogólny
3 Specyfikacja funkcjonalna
4 Specyfikacja uzupełniająca
5 Historia zmian

Olga · Gość

Software Architecture Document

1. Wprowadzenie

1.1Cel
{- w jakim celu powstał niniejszy dokument; np. w celu przedstawienia architektury systemu; - krótkie przedstawienie struktury dokumentu;
- sprecyzowanie adresatów dokumentu i jak mają z niego korzystać}

1.2 Zakres
{co jest omówione w dokumencie, krótko, np. w punktach}

1.3 Definicje
{zdefiniowanie używanych pojęć, skrótów, odnośników itp.}

1.4 Załączniki
{pełna lista wszystkich dokumentów do których znajdują się odwołania w tekście “sad”; podać: tytuł; jeśli jest to: numer referencyjny, data, wydawnictwo}

1.5 Omówienie reszty dokumentu
{informacja, co zawiera pozostała część “sad” i jaka jest jej struktura}

2.Prezentacja architektury systemu
{Jaka architektura jest zastosowana i jak została zaimplementowana {np. obiektowość - java, relacyjna baza danych-sql, architektura klient-server i informacja jak to działa}}

3.Założenia i zależności
{W punktach: wymagania softwerowe, które mają wpływ na architekturę systemu; np. darmowe narzędzia, model klient-serwer, graficzny interfejs, niezawodność, bezpieczeństwo itp.}

4.Przegląd przypadków użycia

4.1 Diagramy przypadków użycia
{np. rysunki}

4.2 Realizacje przypadków użycia
{omówienie na przykładzie kilku przypadków użycia jak działa model, można to zrobić w formie rysunków}

5.Dekompozycja logiczna systemu
{Przedstawienie istotnych architektonicznie części modelu: pakietów, klas;
ich atrybuty, metody, zadania, powiązania z innymi klasami; }

5.1 Omówienie
{Opis hierarchii pakietów i warstw;}

5.2 Najważniejsze komponenty
{- dla każdego istotnego pakietu: nazwa, krótki opis, diagram z nazwami istotnych klas, pakiety wewnątrz danego pakietu
- dla każdej istotnej klasy wewnątrz pakietu: nazwa, krótki opis, opcjonalnie: opis głównych zadań, metod i atrybutów}

6.Dekompozycja na procesy
{Dekompozycja systemu do postaci procesów, wymienionych w punktach i opisanych; uwzględnić jak procesy komunikują się między sobą, randki, przerwania, przekazywanie informacji; }

7.Instalacja systemu
{Model (np. rysunek) hardwaru do obsługi software; musi co najmniej zawierać: komputer/CPU, połączenia (np. bus, LAN, point-to-point itp.) i informacja jak procesy są wykonywane na fizycznych elementach modelu }

8.Implementacja systemu
{ Opis podziału modelu na warstwy i podsystemy. }

8.1 Omówienie
{Dla każdej warstwy: nazwa, definicja, zawartość, zasady przynależności do danej warstwy, granice między warstwami; diagram pokazujący relacje między warstwami;}
8.2 Warstwy
{Wy punktach- warstwy; dla każdej warstwy: nazwa, podsystemy, diagram komponentów; }

9. Przechowywane dane – opcjonalne!
{Zamieścić jeśli przewiduje się trwałe przechowywanie danych; nie zamieszczać tego paragrafu jeśli nie przewiduje się przechowywania trwałych danych lub jeśli przejście od modelu projektowego do modelu danych jest trywialne; (można przedstawić np. diagram encji) }

10. Wydajność systemu
{Napisać od czego zależy wydajność systemu np. od przepustowości łącza itp. }

11.Jakość
{Opisać jak architektura systemu wpływa na jego właściwości niefunkcjonalne takie jak np.: rozszerzalność, niezawodność, przenośność, łatwość obsługi, bezpieczeństwo danych;}

12. Historia zmian

O · Wysłany: Sob 3:36, 29 Mar 2008 Temat postu: Software Development Plan

Software Development Plan

1.Wprowadzenie
1.1 Cel
{Napisać, że celem tego dokumentu jest opisanie procesu powstawania systemu.}
1.2 Zakres
{Co zawiera dokument, w praktyce: wymienić tytuły punktów 1-7 }
1.3 Definicje
{Wyjaśnienie znaczenia definicji i skrótów. }
1.4 Załączniki
{Lista wszystkich dokumentów, do których jest odniesienie w SDP; podać: tytuł, numer ewidencyjny (jeśli taki jest), datę, wydawnictwo, źródło skąd można uzyskać dany dokument ; podana jest lista wymaganych załączników, ale w kilku punktach nie wiem o co chodzi ?????}
1.5 Omówienie reszty dokumentu
{Informacja co zawiera i jak jest zorganizowana pozostała część dokumentu.}

2.Omówienie projektu
2.1 Cel, zakres i 'objectives' projektu
{Czemu służy projekt czyli jaki jest cel powstania systemu i do czego ma być on wykorzystywany.}
2.2 Założenia i zależności
{W punktach omówić: liczba osób pracujących nad projektem, budżet (i jakie narzędzia w związku z tym są wykorzystywane w pracy nad projektem), termin ukończenia }
2.3 Produkty projektu
{w punktach: jakie produkty dostarczy projekt i terminy ich ukończenia}
2.4 Procedura zmian w planie projektu
{tabelka z z proponowanymi wersjami projektu i kryteria wprowadzania nieplanowanych zmian np. że wymagają aprobaty leadera projektu }

3.Organizacja projektu
3.1 Struktura organizacyjna
{w punktach: kto pracuje nad projektem i za co dana osoba odpowiada}
3.2 Kontakty zewnętrzne
{jakie zewnętrzne grupy współpracują przy powstawaniu projektu;
dla każdej takiej grupy dane osoby kontaktowej z tej grupy i osoby z wewnętrznej grupy odpowiedzialnej za kontakt z daną grupą zewnętrzną }
3.3 Role i zadania
{w punktach: nazwa roli i zakres zadań np. programista, tester oprogramowania, koordynator grupy itp.}

4.Zarządzanie projektem
4.1 Oszacowania
{koszt; w tabelce: etapy powstawania projektu, opis etapu, daty początku i końca etapu, np. etap powstawania dokumentacji, etap implementacji, etap akceptacji produktu}
4.2 Plan projektu
4.2.1 Plan faz projektu
{czyli punkt 4.1}
4.2.2 Cele poszczególnych iteracji
{wypisać co powinno powstać w trakcie każdej z faz z punktu 4.1, ew. rozbić fazy na podfazy }
4.2.3 Wydania
{W punktach: numery planowanych wersji (release), terminy powstania, zmiany wprowadzone w danych wersjach}
4.2.4 Harmonogram projektu
{w zasadzie to terminy z 4.1 lub z 4.2.2}
4.2.5 Zasoby
4.2.5.a Plan zatrudnienia
{ile i jakich specjalności pracowników potrzeba do projektu}
4.2.5.b Plan zatrudniania pracowników
{w jaki sposób zostaną znalezieni i kwalifikowani pracownicy do projektu}
4.2.5.c Plan szkoleń
{lista projektów szkoleniowych dla członków zespołu i terminy ich przeprowadzenia }
4.2.6 Budżet
{koszty w rozbiciu na fazy z 4.2.1}
4.3 Plany iteracji
{odwołać sie do punktu 4.2.2}

4.4 Nadzór i kontrola projektu
4.4.1 Plan zarządzania wymaganiami
{odwołać się do dokumentów: Wizji, Business Use Case, Use Case}
4.4.2 Plan zarządzania harmonogramem
{informacja jak będzie monitorowana terminowa realizacja planu i jakie działania zostaną podjęte w razie problemów }
4.4.3 Plan kontroli budżetu
{informacja jak będą monitorowane wydatki budżetowe i jakie działania zostaną podjęte w razie problemów }
4.4.4 Plan kontroli jakości
{terminy i metody kontroli jakości produktów projektu i jakie działania zostaną podjęte w razie problemów}
4.4.5 Plan raportów
{jakie raporty wewnętrzne i zewnętrzne powstaną, z jaką częstotliwością będą generowane, w jaki sposób i do kogo dostarczone np. informacja na temat SVN}
4.4.6 Plan pomiarów
{odwołać sie do odpowiedniego punktu w dokumencie Acceptance Plan}
4.5 Plan zarządzania ryzykiem
{odwołać się do nie wiem o co chodzi ?????}
4.6 Plan zamknięcia projektu
{jakie dokumenty będą gotowe i komu dostarczone oraz informacja o finalnej prezentacji produktu}

5.Plany procesów technicznych
5.1 Programowanie
{odwołać się do 4.2.2}
5.2 Metody, narzędzia i stosowane technologie
{odwołać się do następujących dokumentów: Business Modeling Guidelines, User Interfaces Guidelines, Use-Case-Modeling Guidelines, Design Guidelines, Programming Guidelines, Test Guidelines, Manual Style guide}
5.3 Plan infrastruktury
{odwołać się do miejsc gdzie jest kod i repozytoria }
5.4 Plan akceptacji produktu
{odwołać się do dokumentu Acceptance Plan }

6.Plany pomocnicze
6.1 Plan zarządzania zmianami
{odwołać się do: nie wiem czego????????}
6.2 Plan oceny
{dodatek do Test Plan; plany oceny produktu, m.in. kryteria, metody testowania, podsumowania; można odwołać się do dokumentu Acceptance Plan}
6.3 Plan dokumentacji
{odwołać sie do następujących dokumentów: Wizji, Use Case, Business Use Case, Acceptance Plan, Software Development Plan}
6.4 Plan zapewnienia jakości
{odwołać się do nie wiem czego ???? lub wypisać w punktach sposób wprowadzania kolejnych funkcjonalności z uwzględnieniem testowania kodu, metod poprawy błędów itp.}
6.5 Plan rozwiązywania problemów
{odwołać się do nie wiem czego ???? lub wypisać w punktach plan rozpracowywania ewentualnych problemów}
6.6 Plan zarządzania podwykonawcami
{odwołać się do nie wiem czego ????}
6.7 Plan ulepszania procedur
{odwołać się do nie wiem czego ???? lub wypisać w punktach proces podejmowania decyzji w sprawie ulepszania procedur}

7.Inne plany
{informacja o dodatkowych planach jeśli są wymagane przez kontrakt}

8.Aneksy
{dodatkowe materiały przydatne czytelnikowi “SDP”}

9.Indeks

10.Historia zmian