www.iookkk.fora.pl
Inżynieria Oprogramowania
FAQ
Szukaj
Użytkownicy
Grupy
Galerie
Rejestracja
Profil
Zaloguj się, by sprawdzić wiadomości
Zaloguj
Forum www.iookkk.fora.pl Strona Główna
->
IO
Napisz odpowiedź
Użytkownik
Temat
Treść wiadomości
Emotikony
Więcej Ikon
Kolor:
Domyślny
Ciemnoczerwony
Czerwony
Pomarańćzowy
Brązowy
Żółty
Zielony
Oliwkowy
Błękitny
Niebieski
Ciemnoniebieski
Purpurowy
Fioletowy
Biały
Czarny
Rozmiar:
Minimalny
Mały
Normalny
Duży
Ogromny
Zamknij Tagi
Opcje
HTML:
NIE
BBCode
:
TAK
Uśmieszki:
TAK
Wyłącz BBCode w tym poście
Wyłącz Uśmieszki w tym poście
Kod potwierdzający: *
Wszystkie czasy w strefie EET (Europa)
Skocz do:
Wybierz forum
IO
----------------
IO
Sugestie
Nie IO
----------------
Hyde-park
Przegląd tematu
<table border="0" cellpadding="3" cellspacing="1" width="100%" class="forumline"> <tr> <th class="thCornerL" width="22%" height="26">Autor</th> <th class="thCornerR">Wiadomość</th> </tr> <tr> <td width="22%" align="left" valign="top" class="row1"><span class="name"><a name=""></a><b>O</b></span></td> <td class="row1" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Sob 3:36, 29 Mar 2008<span class="gen"> </span> Temat postu: Software Development Plan</span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">Software Development Plan <br /> <br />1.Wprowadzenie <br />1.1 Cel <br />{Napisać, że celem tego dokumentu jest opisanie procesu powstawania systemu.} <br />1.2 Zakres <br />{Co zawiera dokument, w praktyce: wymienić tytuły punktów 1-7 } <br />1.3 Definicje <br />{Wyjaśnienie znaczenia definicji i skrótów. } <br />1.4 Załączniki <br />{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 ?????} <br />1.5 Omówienie reszty dokumentu <br />{Informacja co zawiera i jak jest zorganizowana pozostała część dokumentu.} <br /> <br />2.Omówienie projektu <br />2.1 Cel, zakres i 'objectives' projektu <br />{Czemu służy projekt czyli jaki jest cel powstania systemu i do czego ma być on wykorzystywany.} <br />2.2 Założenia i zależności <br />{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 } <br />2.3 Produkty projektu <br />{w punktach: jakie produkty dostarczy projekt i terminy ich ukończenia} <br />2.4 Procedura zmian w planie projektu <br />{tabelka z z proponowanymi wersjami projektu i kryteria wprowadzania nieplanowanych zmian np. że wymagają aprobaty leadera projektu } <br /> <br />3.Organizacja projektu <br />3.1 Struktura organizacyjna <br />{w punktach: kto pracuje nad projektem i za co dana osoba odpowiada} <br />3.2 Kontakty zewnętrzne <br />{jakie zewnętrzne grupy współpracują przy powstawaniu projektu; <br />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ą } <br />3.3 Role i zadania <br />{w punktach: nazwa roli i zakres zadań np. programista, tester oprogramowania, koordynator grupy itp.} <br /> <br />4.Zarządzanie projektem <br />4.1 Oszacowania <br />{koszt; w tabelce: etapy powstawania projektu, opis etapu, daty początku i końca etapu, np. etap powstawania dokumentacji, etap implementacji, etap akceptacji produktu} <br />4.2 Plan projektu <br />4.2.1 Plan faz projektu <br />{czyli punkt 4.1} <br />4.2.2 Cele poszczególnych iteracji <br />{wypisać co powinno powstać w trakcie każdej z faz z punktu 4.1, ew. rozbić fazy na podfazy } <br />4.2.3 Wydania <br />{W punktach: numery planowanych wersji (release), terminy powstania, zmiany wprowadzone w danych wersjach} <br />4.2.4 Harmonogram projektu <br />{w zasadzie to terminy z 4.1 lub z 4.2.2} <br />4.2.5 Zasoby <br />4.2.5.a Plan zatrudnienia <br />{ile i jakich specjalności pracowników potrzeba do projektu} <br />4.2.5.b Plan zatrudniania pracowników <br />{w jaki sposób zostaną znalezieni i kwalifikowani pracownicy do projektu} <br />4.2.5.c Plan szkoleń <br />{lista projektów szkoleniowych dla członków zespołu i terminy ich przeprowadzenia } <br />4.2.6 Budżet <br />{koszty w rozbiciu na fazy z 4.2.1} <br />4.3 Plany iteracji <br />{odwołać sie do punktu 4.2.2} <br /> <br /> <br />4.4 Nadzór i kontrola projektu <br />4.4.1 Plan zarządzania wymaganiami <br />{odwołać się do dokumentów: Wizji, Business Use Case, Use Case} <br />4.4.2 Plan zarządzania harmonogramem <br />{informacja jak będzie monitorowana terminowa realizacja planu i jakie działania zostaną podjęte w razie problemów } <br />4.4.3 Plan kontroli budżetu <br />{informacja jak będą monitorowane wydatki budżetowe i jakie działania zostaną podjęte w razie problemów } <br />4.4.4 Plan kontroli jakości <br />{terminy i metody kontroli jakości produktów projektu i jakie działania zostaną podjęte w razie problemów} <br />4.4.5 Plan raportów <br />{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} <br />4.4.6 Plan pomiarów <br />{odwołać sie do odpowiedniego punktu w dokumencie Acceptance Plan} <br />4.5 Plan zarządzania ryzykiem <br />{odwołać się do nie wiem o co chodzi ?????} <br />4.6 Plan zamknięcia projektu <br />{jakie dokumenty będą gotowe i komu dostarczone oraz informacja o finalnej prezentacji produktu} <br /> <br />5.Plany procesów technicznych <br />5.1 Programowanie <br />{odwołać się do 4.2.2} <br />5.2 Metody, narzędzia i stosowane technologie <br />{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} <br />5.3 Plan infrastruktury <br />{odwołać się do miejsc gdzie jest kod i repozytoria } <br />5.4 Plan akceptacji produktu <br />{odwołać się do dokumentu Acceptance Plan } <br /> <br /> <br />6.Plany pomocnicze <br />6.1 Plan zarządzania zmianami <br />{odwołać się do: nie wiem czego????????} <br />6.2 Plan oceny <br />{dodatek do Test Plan; plany oceny produktu, m.in. kryteria, metody testowania, podsumowania; można odwołać się do dokumentu Acceptance Plan} <br />6.3 Plan dokumentacji <br />{odwołać sie do następujących dokumentów: Wizji, Use Case, Business Use Case, Acceptance Plan, Software Development Plan} <br />6.4 Plan zapewnienia jakości <br />{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.} <br />6.5 Plan rozwiązywania problemów <br /> {odwołać się do nie wiem czego ???? lub wypisać w punktach plan rozpracowywania ewentualnych problemów} <br />6.6 Plan zarządzania podwykonawcami <br />{odwołać się do nie wiem czego ????} <br />6.7 Plan ulepszania procedur <br />{odwołać się do nie wiem czego ???? lub wypisać w punktach proces podejmowania decyzji w sprawie ulepszania procedur} <br /> <br />7.Inne plany <br /> {informacja o dodatkowych planach jeśli są wymagane przez kontrakt} <br /> <br />8.Aneksy <br />{dodatkowe materiały przydatne czytelnikowi “SDP”} <br /> <br />9.Indeks <br /> <br />10.Historia zmian</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row2"><span class="name"><a name=""></a><b>Olga</b></span></td> <td class="row2" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Śro 22:42, 26 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">Software Architecture Document <br /> <br />1. Wprowadzenie <br /> <br />1.1Cel <br />{- w jakim celu powstał niniejszy dokument; np. w celu przedstawienia architektury systemu; - krótkie przedstawienie struktury dokumentu; <br />- sprecyzowanie adresatów dokumentu i jak mają z niego korzystać} <br /> <br />1.2 Zakres <br />{co jest omówione w dokumencie, krótko, np. w punktach} <br /> <br />1.3 Definicje <br />{zdefiniowanie używanych pojęć, skrótów, odnośników itp.} <br /> <br />1.4 Załączniki <br />{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} <br /> <br />1.5 Omówienie reszty dokumentu <br />{informacja, co zawiera pozostała część “sad” i jaka jest jej struktura} <br /> <br />2.Prezentacja architektury systemu <br />{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}} <br /> <br />3.Założenia i zależności <br /> {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.} <br /> <br />4.Przegląd przypadków użycia <br /> <br />4.1 Diagramy przypadków użycia <br />{np. rysunki} <br /> <br />4.2 Realizacje przypadków użycia <br />{omówienie na przykładzie kilku przypadków użycia jak działa model, można to zrobić w formie rysunków} <br /> <br />5.Dekompozycja logiczna systemu <br /> {Przedstawienie istotnych architektonicznie części modelu: pakietów, klas; <br /> ich atrybuty, metody, zadania, powiązania z innymi klasami; } <br /> <br />5.1 Omówienie <br /> {Opis hierarchii pakietów i warstw;} <br /> <br />5.2 Najważniejsze komponenty <br />{- dla każdego istotnego pakietu: nazwa, krótki opis, diagram z nazwami istotnych klas, pakiety wewnątrz danego pakietu <br />- dla każdej istotnej klasy wewnątrz pakietu: nazwa, krótki opis, opcjonalnie: opis głównych zadań, metod i atrybutów} <br /> <br /> <br />6.Dekompozycja na procesy <br /> {Dekompozycja systemu do postaci procesów, wymienionych w punktach i opisanych; uwzględnić jak procesy komunikują się między sobą, randki, przerwania, przekazywanie informacji; } <br /> <br />7.Instalacja systemu <br /> {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 } <br /> <br />8.Implementacja systemu <br /> { Opis podziału modelu na warstwy i podsystemy. } <br /> <br />8.1 Omówienie <br />{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;} <br />8.2 Warstwy <br />{Wy punktach- warstwy; dla każdej warstwy: nazwa, podsystemy, diagram komponentów; } <br /> <br />9. Przechowywane dane – opcjonalne! <br />{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) } <br /> <br />10. Wydajność systemu <br /> {Napisać od czego zależy wydajność systemu np. od przepustowości łącza itp. } <br /> <br />11.Jakość <br /> {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;} <br /> <br />12. Historia zmian</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row1"><span class="name"><a name=""></a><b>Konrad K</b></span></td> <td class="row1" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 19:58, 24 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">srs-template.tex <br /> <br />Software Requirements Specification <br />www microtoolsinc com/Howsrs.php <br />www techwr-l com/techwhirl/magazine/writing/softwarerequirementspecs.html <br />+ wikipedia <br /> <br />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... <br /> <br />Template zawiera takie główne podpunkty: <br />1 Wstęp <br />2 Opis ogólny <br />3 Specyfikacja funkcjonalna <br />4 Specyfikacja uzupełniająca <br />5 Historia zmian</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row2"><span class="name"><a name=""></a><b>Krzysiek</b></span></td> <td class="row2" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 16:52, 24 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">Projekt „LÓZ” był realizowany przez pewnych studentów na IO dwa lata temu. <br /> Link do jego dokumentacji <br /> <br />(students.mimuw.edu.pl/~mn219541/IIrok/Inzynieria%20oprogramowania/dokumentacja/pdf/ ) <br />podałem już wcześniej na forum. <br />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: <br />mimuw.edu.pl/~kulisty/download/templates/. <br />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. <br />Dlatego też w moim opisie ZACYTOWAŁEM pewne fragmenty dokumentacji systemu „LÓZ”. <br />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ą. <br /> <br /> <br />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. <br />Myślę więc, że powinniśmy zacząć od opisania „przypadków użycia” naszego systemu (czyli wymagań funkcjonalnych) zgodnie z szablonem ze strony: <br />mimuw.edu.pl/~kulisty/download/templates/use_case-template.tex. <br />A jak to zrobili w projekcie „LÓZ” można zobaczyć tutaj: students.mimuw.edu.pl/~mn219541/IIrok/Inzynieria%20oprogramowania/dokumentacja/pdf/uc.pdf . <br /> <br /> <br />Proponuję, aby opisać następujące przypadki użycia : <br />1. Rejestracja użytkownika <br />2. Ustawianie profilu użytkownika <br />3. Odzyskiwanie zapomnianego hasła <br />4. Zalogowanie użytkownika do systemu <br />5. Tworzenie stołu do gry <br />6. Zapraszanie do gry i rozpoczęcie partii <br />7. Przeglądanie listy obecnych zawodników <br />8. Gra przy pomocy programu komputerowego <br />9. Gra w turnieju <br />10. Ustawianie preferencji użytkownika do danej gry <br />11. Przypadki użycia podczas rozgrywania partii: <br />a) Rozmowa z przeciwnikiem (czat lub mikrofon) <br />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) <br />c) Proponowanie remisu <br />d) Poddawanie partii <br />e) Wykonywanie ruchu <br />12. Przeglądanie forum <br />13. Pisanie na forum <br />14. Dodawanie nowych gier do systemu (przez administratora) <br />15. Usuwanie gier z systemu (przez administratora) <br />16. Organizacja turniejów (przez administratora) <br /> <br />W tych opisach możemy się oczywiście posłużyć fragmentami pliku: <br />students.mimuw.edu.pl/~kk236048/IO/funkcjonalnosc.pdf <br /> <br />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ł. <br /> <br />Looknijcie też na proponowany wstępnie diagram związków encji: students.mimuw.edu.pl/~kk236048/IO/sgi2.png <br />Co jeszcze ewentualnie poprawić/dorysować ?</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row1"><span class="name"><a name=""></a><b>Konrad K</b></span></td> <td class="row1" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 16:15, 24 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">Apropo use case : w wikipedi angielskiej pod hasłem Use case są też opisane podpunkty</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row2"><span class="name"><a name=""></a><b>Konrad K</b></span></td> <td class="row2" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 16:08, 24 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">use_case-template.tex <br /> <br />Use Case - Przypadki użycia <br />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" <br /> <br />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 <br /> <br />Główne podpunkty: <br />1 <<Nazwa projektu>> Use Case <br />2 Czynności ( Czynności podstawowe, Czynności alternatywne ) <br />3 Inne wymagania ( First Special Requirement ) <br />4 Warunki wstępne ( wypunktowane ) <br />5 Warunki końcowe ( wypunktowane ) <br />6 Extension Points ( punkty to nazwy Extension Pointów ) <br />7 Historia zmian <br /> <br /> <br /> 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. <br /> <br />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ą. <br /> <br />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 )</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row1"><span class="name"><a name=""></a><b>Konrad K</b></span></td> <td class="row1" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 14:20, 24 Mar 2008<span class="gen"> </span> Temat postu: vision-template</span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">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: <br />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 <br /> <br />Główne podpunkty: <br />1 Wprowadzenie <br />2 Kontekst produktu ( Korzyści, Postawienie problemu, Kontekst produktu ) <br />3 Osoby mające wpływ na wymagania i projekt <br />4 Omówienie produktu ( Umiejscowienie produktu, Podsumowanie możiwości, Założenia i zależności, Koszta, Licencjonowanie i instalacja ) <br />5 Własności produktu <br />6 Ograniczenia <br />7 Założenia jakościowe <br />8 Priorytety <br />9 Inne wymagania ( Standardy, Wymagania systemowe/wydajnościowe/środowiskowe ) <br />10 Wymagania dokumentacyjne ( Podręcznik użytkownika, Pomoc on-line, Instalacja i konfiguracja, Oznaczenia markowe) <br />A Dodatek/Adnotacja 1 - Atrybuty funkcji/możliwości ? ( Feature Attributes ) <br />B Historia zmian</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row2"><span class="name"><a name=""></a><b>Konrad K</b></span></td> <td class="row2" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Pon 13:44, 24 Mar 2008<span class="gen"> </span> Temat postu: </span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">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? ). <br />Jeśli to jednak chodzi o ten nasz serwis to mam drobną uwage odnośnie definicji w BUC: <br />przy definiowaniu moderatora piszesz o operatorze którego wcześniej, ani później nie definiujesz; <br />jeszcze jedna rzecz: <br />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... <br />Moim zdaniem powinniśmy zrobić tak, że są dwa rodzaje urzytkowników: zwykły user i administrator i tyle... po co więcej ?</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> <tr> <td width="22%" align="left" valign="top" class="row1"><span class="name"><a name=""></a><b>Krzysiek</b></span></td> <td class="row1" height="28" valign="top"><table width="100%" border="0" cellspacing="0" cellpadding="0"> <tr> <td width="100%"><img src="http://picsrv.fora.pl/subSilver/images/icon_minipost.gif" width="12" height="9" alt="Post" title="Post" border="0" /><span class="postdetails">Wysłany: Nie 22:32, 23 Mar 2008<span class="gen"> </span> Temat postu: Uwagi dotyczące dokumentacji podobnego programu</span></td> </tr> <tr> <td colspan="2"><hr /></td> </tr> <tr> <td colspan="2"><span class="postbody">******opis pliku****** <br />*******buc.pdf******** <br /> <br />Biznesowe przypadki użycia serwisu „LÓZ” <br /> <br />Pierwszy rozdział tego dokumentu jest krótki, więc przytoczę go w całości: <br /> <br />##POCZĄTEK## <br />1 Wprowadzenie <br />Niniejszy dokument opisuje biznesowe przypadki uzycia systemu „LÓZ”. <br />1.1 Cel <br />Celem tego dokumentu jest opisanie działania systemu „LÓZ” w kontekscie procesów biznesowych <br />zachodzacych u odbiorcy systemu. <br />1.2 Zakres <br />Dokument obejmuje swoim zakresem jedynie kilka podstawowych przypadków biznesowego <br />uzycia systemu. <br />1.3 Definicje <br />• LÓZ – nazwa tworzonego serwisu internetowego, <br />• uzytkownik – docelowy uzytkownik systemu „LÓZ”, <br />• 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 <br />konta i podał numer rachunku bankowego, <br />• moderator – osoba wyznaczona przez operatora systemu „LÓZ” do nadzorowania działania <br />systemu; moderator jest z definicji uzytkownikiem, <br />• stronaWWW– dokument w formacie HTML lub XHTML przeznaczony do otwierania w <br />przegladarce internetowej, <br />• strona internetowa – stron WWW, <br />• witryna internetowa – zbiór powiazanych ze soba˛ stron internetowych opublikowanych w <br />internecie w ramach jednej domeny internetowej, <br />• serwis WWW – witryna internetowa, <br />• HTML – (HyperText Markup Language) jezyk słuzacy do pisania stron WWW, <br />• XHTML – (Extensible HyperText Markup Language) nastepca HTML, <br />1.4 Załaczniki <br />Przypadki uzycia serwisu „LÓZ” – dokument omawiajacy szczegółowo przypadki uzycia serwisu. <br />Niniejszy dokument odwołuje sie do niego w kwestiach przebiegu poszczególnych czynnosci wchodzacych w skład procesu biznesowego. <br />1.5 Omówienie reszty dokumentu <br />W dalszej czesci dokumentu kolejno omówione zostanie kilka najwazniejszych przypadków biznesowego uzycia. <br />##KONIEC## <br /> <br />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. <br /> <br />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: <br /> <br />##POCZĄTEK## <br />2 Granie w gre <br />2.1 Krótki opis <br />Ten przypadek uzycia opisuje podstawowy proces biznesowy serwisu „LÓZ”, czyli granie w gre <br />przez uzytkownika-internaute. <br />2.2 Cele <br />Jest to podstawowe zródło przychodów z serwisu „LÓZ”. <br />2.3 Wydajnosc <br />Problem wydajnosci został omówiony w załaczniku. <br />2.4 Warunki wstepne <br />- Uzytkownik posiada konto w systemie. <br />- Uzytkownik wykupił zetony i posiada ich wystarczajaca ilosc, by zagrac w gre. <br />2.5 Czynnosci <br />Czynnosci podstawowe <br />1. Uzytkownik loguje sie do systemu. <br />2. Uzytkownik wybiera gre, w która chce zagrac. <br />3. Z konta uzytkownika pobierane sa zetony – opłata za gre. <br />4. Uzytkownik gra w gre. <br />Czynnosci alternatywne <br />1. Punkty 1 i 2 jak w Czynnosciach podstawowych. <br />2. Uzytkownik nie posiada wystarczajacej ilosci zetonów, wiec zostaje rozpoczety proces <br />doładowania konta. <br />2.6 Błedy <br />- Uzytkownik nie posiada wystarczajacej ilosci zetonów. <br />- Uzytkownik nie ma konta w systemie. <br />2.7 Inne wymagania <br />Komputer, którym posługuje sie uzytkownik spełnia wymagania niezbedne do uruchomienia <br />wybranej gry. Poszczególne gry moga sie róznic wymaganiami systemowymi <br />##KONIEC## <br /> <br />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”. <br /> <br />WNIOSEK <br />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). <br /> <br /> <br />******opis pliku****** <br />*******ap.pdf********* <br /> <br />Plan akceptacji systemu „LÓZ” <br /> <br />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: <br /> <br />Celem tego dokumentu jest określenie sposobu przekazania systemu „LÓZ” firmie, która zleciła jego wykonanie. <br /> <br />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ść). <br />Rozdział 3 określa kroki odbioru projektu: <br />z czego składa się dokumentacja, w jakich okolicznościach firma ją akceptuje <br />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). <br />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). <br />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ę). <br />Rozdział 6 omawia środowisko odbioru produktu, jest nim na przykład opis postaci: <br />- Wszystkie komputery znajdują sie w siedzibie Zleceniodawcy. <br />- Komputery spełniają wymagania sprzętowe i dotyczące oprogramowania opisane w punktach 4.1 i 4.2. <br />- Komputery są podłączone do Internetu. <br />Rozdział 7 omawia wymagane kroki kontroli – tabelka określająca w jaki sposób będą przeprowadzane testy, będzie ona miała kolumny: <br />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).</span></td> </tr> </table></td> </tr> <tr> <td colspan="2" height="1" class="spaceRow"><img src="http://picsrv.fora.pl/subSilver/images/spacer.gif" alt="" width="1" height="1" /></td> </tr> </table>
fora.pl
- załóż własne forum dyskusyjne za darmo
Powered by
phpBB
© 2001, 2005 phpBB Group
Regulamin
FAQ
Szukaj
Użytkownicy
Grupy
Galerie
Rejestracja
Zaloguj się, by sprawdzić wiadomości
Zaloguj