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

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.

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.

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.

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.

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.

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.

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.