Czy utworzenie dokumentu projektu oprogramowania po opracowaniu może być uzasadnione?

11

Obecnie pracuję nad ukończeniem studiów na kierunku „Tworzenie oprogramowania”, w których muszę indywidualnie opracowywać złożone oprogramowanie w firmie zewnętrznej. Wszystko to należy wykonać w sposób ustrukturyzowany, tworząc wszystkie odpowiednie dokumenty.

W tym projekcie postanowiłem pracować ze standardowymi dokumentami IEEE: dokument wymagań oprogramowania (SRS), dokumenty architektury oprogramowania (SAD) i dokument projektu oprogramowania (SDD). Chociaż w szkole uczyłem inaczej, w tym projekcie postanowiłem utworzyć SDD po opracowaniu (zamiast wcześniej). Moje rozumowanie to:

Firma, w której odbywam staż, dała mi instrukcję tworzenia złożonego oprogramowania, spełniającego pewien zestaw wymagań, w sposób eksperymentalny. Z powodu ilości swobody, którą dali mi w definicji projektu, prawie nic wcześniej nie jest pewne i najlepiej można je spotkać podczas eksperymentowania w procesie rozwoju. Ponadto tworzę oprogramowanie w sposób indywidualny , nie byłoby dla nikogo w firmie korzyści, żebym mógł wcześniej wykonać ten projekt oprogramowania. Zrobienie tego wcześniej będzie kosztowało mnie dużo czasu, aby go później zmienić, ponieważ mogę być pewien, że z powodu niepewności w projekcie, projekt, który wykonuję wcześniej, będzie musiał zostać bardzo zmieniony . To wydaje mi się bezproduktywne.

Czy to dobre uzasadnienie, aby utworzyć SDD po ​​opracowaniu? Jeśli nie, czy byłoby na to jakieś uzasadnienie?

Edycja: Powodem do utworzenia SDD będą przyszłe programiści, którzy będą kontynuować projekt. Nie będę w stanie ukończyć całego projektu w okresie dyplomowym, więc inni programiści będą musieli kontynuować obecną bazę kodu.

Simon Baars
źródło
2
Jeśli musisz dużo zmienić SDD podczas / po opracowaniu, prawdopodobnie zawiera on zbyt wiele szczegółów.
freedomn-m
Jajko lub kurczak - na pierwszym miejscu jest coś, na co filozofowie wkładają wysiłek. SDD i kompletne (złożone) oprogramowanie powinny być takie same, ewoluują razem.
mattnz
Dla mnie dokumentowanie później nie działa. To jest dla mnie zbyt nudne. Muszę pisać podczas projektowania. Opracowanie SDD jest także rodzajem gumowego kaczki: musisz wyjaśnić projekt, który wcześnie odkryje problemy.
jos

Odpowiedzi:

17

W IEEE Std 1016 Sekcja 3.1 Projektowanie oprogramowania w kontekście można znaleźć ten akapit:

SDD można przygotować i stosować w różnych sytuacjach projektowych. Zazwyczaj SDD jest przygotowany do wspierania rozwoju oprogramowania w celu rozwiązania problemu, w przypadku gdy problem ten został wyrażony w postaci zestawu wymagań. Zawartość SDD można następnie prześledzić według tych wymagań. W innych przypadkach SDD jest przygotowany do zrozumienia istniejącego systemu bez dokumentacji projektowej. W takich przypadkach SDD jest przygotowywany w taki sposób, że interesujące informacje są rejestrowane, organizowane, prezentowane i rozpowszechniane wśród wszystkich zainteresowanych stron. Informacje te mogą być wykorzystane do planowania, analizy, wdrażania i ewolucji systemu oprogramowania poprzez identyfikację i rozwiązywanie istotnych problemów projektowych.

Autorzy IEEE Std 1016 uznają, że SDD nie może zostać utworzone z góry. Można go utworzyć po istnieniu systemu oprogramowania w celu przechwytywania informacji dla zainteresowanych stron.

Sekcja 1.1 Zakres zawiera również kilka interesujących informacji:

Ten standard nie określa konkretnych metod projektowania, zarządzania konfiguracją ani zapewniania jakości.

W kontekście tych pytań kluczowymi słowami są „zarządzanie konfiguracją”. Zarządzanie konfiguracją dotyczy nie tylko tworzonego systemu oprogramowania, ale wszelkiej powiązanej dokumentacji.

W twojej osobistej sytuacji iw wielu sytuacjach tworzenie SDD z góry jest marnotrawstwem. Odpowiedź Davida Arno jest bliska tego, co uważam za właściwą. Prawdziwym projektem twojego oprogramowania jest kod. Jednak „utworzysz SDD przed” lub „utworzysz SDD po” to nie jedyne opcje. Masz trzecią opcję - rozwinąć SDD wraz z systemem oprogramowania.

Jeśli przestrzegasz standardu, takiego jak IEEE Std 1016, masz wymagania dotyczące SDD. W szczególności sekcja 4 tego standardu określa treść, którą posiadasz. Podczas pracy nad decyzjami projektowymi zacznij tworzyć różne punkty widzenia, widoki i nakładki. Podejmując decyzje, uchodź za uzasadnienie ich projektu.

Umożliwi to zainteresowanym stronom śledzenie ewolucji projektu oprogramowania bez konieczności zagłębiania się w kod. Oczywiście ludzie mogą mieć komentarze lub sugestie. Jeśli aktualizujesz SDD, mogą śledzić twoje postępy i dawać informacje zwrotne na temat podejścia wcześniej, które możesz następnie włączyć do produktu, a także SDD. Po wyjściu z projektu, jeśli kod oprogramowania i SDD są zsynchronizowane, ktoś powinien mieć możliwość łatwego włączenia na pokład i podjęcia pracy.

Thomas Owens
źródło
Rzeczywiście pomyliłem ISO i IEEE, tak naprawdę powinno być IEEE. Dzięki za zacytowanie komentarzy od samych autorów IEEE Std. Ta „trzecia” opcja jest rzeczywiście najlepsza. Szkoda, że ​​nigdy nie uczono nas tego w ten sposób.
Simon Baars
@SimonBaars Nie jestem zaskoczony. Jeśli nauczysz się standardów takich jak IEEE i ISO, prawie zawsze jest to związane z planem / wodospadem. Kiedy dowiadujesz się o iteracyjnym i przyrostowym podejściu do rozwoju, zwykle nie uczysz się tych standardów. Jednak nowsze wersje standardów IEEE zwykle uwzględniają metody iteracyjne i przyrostowe (zwinne) i często można je stosować nawet w tych środowiskach.
Thomas Owens
8

Jeśli wszystko, czego szukasz z SDD, to komunikowanie projektu z innymi, to tak, możesz go stworzyć po opracowaniu. Chodzi tylko o to, że nazywa się to dokumentacją.

Chciałbym jednak zaznaczyć, że SDD może służyć również innemu celowi. Może także pomóc ci w przemyśleniu projektu i upewnieniu się, że „szybko zawiedziesz”. Jest to dobra rzecz, zwłaszcza jeśli wiele rzeczy jest wcześniej niepewnych, ponieważ można odrzucić podejścia, które nie zadziałałyby wcześniej przez całą implementację. Może również uniemożliwić skupienie się na szczegółach technicznych, ponieważ nie kodujesz niczego, dopóki nie opracujesz projektu.

Radzę przynajmniej spróbować wcześniej SDD. Jeśli natkniesz się na rzeczy, w których nie masz pewności, jak to by działało, możesz zrobić małe prototypy problemów, które próbujesz rozwiązać. To da ci doświadczenie w rozwiązywaniu konkretnych problemów dla twojego projektu, które na dłuższą metę poprawią jakość kompletnego rozwiązania.

Jonathan van de Veen
źródło
Jak nazywałby się SDD, gdyby został wcześniej utworzony i utrzymany podczas projektu?
Simon Baars
Tylko SDD :)
Jonathan van de Veen
Czy sugerowałbyś zmianę jego nazwy, aby uniknąć nieporozumień ze strony przełożonych?
Simon Baars
Jakiego rodzaju nieporozumienia oczekujesz?
Jonathan van de Veen
8
@SimonBaars: czy naprawdę taka wielka różnica między „Software Design Document” lub „Software Design Document acji ”?
Doc Brown
2

Jedynym prawdziwym szczegółowym dokumentem projektowym, który utworzysz, jest kod. Dokładnie informuje kompilator, jak zbudować aplikację. W związku z tym projekt nie może zostać ukończony, dopóki nie zostanie ukończona ostatnia wersja przed wysyłką.

Wszelkie inne tworzone dokumenty projektowe, takie jak SDD, będą wymagać aktualizacji po zakończeniu projektowania (kodu). Dlatego jest ważny powód, aby zapisać SDD później: musisz to zrobić tylko raz.

Oczywistym przeciwieństwem jest to, „jak często naprawdę piszesz SDD po wydarzeniu”? Aplikacja jest dostarczana, więc prawdopodobnie nie będziesz chciał spędzać czasu na dokumentowaniu na tym etapie. Ale dotyczy to w równym stopniu aktualizacji istniejącej. Co gorsza, brak SDD lub SDD, który jest nieprawidłowy i nie można mu ufać?

Są jednak dwa powody, aby napisać to wcześniej. Po pierwsze, może to być obowiązkowy wymóg (nie jest to miłe, ale się zdarza). Po drugie, utworzenie takiego dokumentu może pomóc w sformułowaniu ogólnej strategii dotyczącej projektu. Ale można to zrobić równie dobrze, rysując obrazki, zapisując notatki itp. W nieformalny sposób. A ponieważ będzie wymagać późniejszego przepisywania, „szybkie i brudne” podejście do tego wstępnego procesu projektowania makr ma wiele zalet.

David Arno
źródło
The app is shipped, so you aren't likely to want to spend time documenting at that stage. W takim przypadku aplikacja nie zostanie sfinalizowana w ciągu mojego okresu ukończenia studiów, więc potrzebujemy dokumentacji, aby inni programiści mogli kontynuować rozwój produktu.
Simon Baars
0

Dla mnie nie byłaby to dobra argumentacja.

W razie potrzeby kłóciłbym się z opracowaniem prototypu, aby lepiej zrozumieć nieznaną dziedzinę problemów. Jednak nawet w tych przypadkach niektóre elementy projektu byłyby przydatne wcześniej.

Walter Kuhn
źródło
0

W każdym razie należy zrobić to z góry . Ponieważ robisz to, aby dowiedzieć się o pisaniu takich dokumentów. Pominięcie tej pracy, ponieważ może nie być w 100% potrzebne, oznacza pominięcie nauki.

Kompromisem może być napisanie go podczas implementacji. Przed każdym komponentem / modułem / ekranem lub innym podziałem programu, musisz pomyśleć o tym, jak to zrobisz. Następnie dodajesz swoje decyzje do dokumentu projektowego, a następnie je wdrażasz.

Jeśli później coś się zmieni, zaktualizujesz dokument.

Ma to kilka zalet w porównaniu do pisania po fakcie:

  • Dowiesz się, jak aktualizować dokumenty projektowe, gdy zmienią się wymagania, co jest pożytecznym nawykiem

  • Nauczysz się myśleć o projektowaniu przed wdrożeniem

  • Nie jest to tak nudne, jak pisanie dokumentów projektowych po fakcie

  • Jeśli zabraknie Ci czasu, będziesz mieć dokument projektowy opisujący to, co masz do tej pory, aby inni mogli kontynuować Twoją pracę

  • W ten sposób nie trzeba wiele dodatkowej pracy

  • W trakcie realizacji projektu możesz nie mieć pewności, dlaczego sam zrobiłeś coś w ten sposób dwa miesiące temu, i będziesz miał swoje notatki do opowiedzenia.

RemcoGerlich
źródło
-2

Dokument projektu systemu, zapis podstawowych wymagań oraz aktualizacje (nowe funkcje) wraz z postępem projektu dzięki nowym atrybutom projektu i rozwiązania. Utrzymywany do czasu dostarczenia projektu / rozwiązania. Przydatne, komunikuje się z wszystkimi zainteresowanymi.

Le Thur
źródło