Narzędzia i standardy dotyczące technicznego projektu dokumentu

Question

Chciałbym wiedzieć, jakich narzędzi i standardów używają moi koledzy do sporządzania dokumentów technicznych w dzisiejszych czasach.

W przeszłości, gdy w mojej firmie dostarczaliśmy tylko aplikacje win-klient-serwer, mieliśmy szablony słów do naszych dokumentów projektowych. Nasze szablony zawsze zaczynały się od diagramu bazy danych, makiet interfejsu użytkownika, odwzorowań pól, opisu funkcjonalności itp. W Word i Visio mieliśmy dość. Ale ostatnio łączymy Wikis, diagramy UML, narzędzia do prototypowania itp. Bez naprawdę silnej polityki dla standardów i narzędzi. Czy uważasz, że dobrze jest dać architektom swobodę wyboru zestawu narzędzi i standardów, które uznają za stosowne w danej chwili w danym projekcie, czy też firma powinna je egzekwować i standaryzować?

Answer 1

Powodem każdej dokumentacji projektowej jest wyraźna komunikacja z wszystkimi zaangażowanymi osobami. Z tego punktu widzenia, niezależnie od tego, jakich narzędzi wybierzesz jako architekt, gotowy produkt musi zostać odczytany zarówno teraz przez wszystkich zaangażowanych, a później przez opiekunów. Dlatego sensowne jest wybranie przynajmniej kilku dość standardowych narzędzi, które będą dostępne za kilka lat.

To powiedziawszy, dokumenty projektowe są zwykle używane do uruchomienia projektu lub systemu. Następnie dobrze udokumentowany kod i pewna podstawowa dokumentacja powinna wystarczyć. Prawdopodobnie poświęciłbym więcej uwagi organizacji twojej dokumentacji, aby ludzie mogli łatwo znaleźć to, czego szukają w przyszłości. Może pomóc w egzekwowaniu jakiejś standardowej struktury/systemu repozytoriów do przechowywania dokumentacji, ale niekoniecznie domaga się wszelkiego rodzaju szablonów do dokumentacji. Skup się na treści, a nie na narzędziach.

Answer 2

Jeśli twoje projekty nie są wycinarkami do ciastek, warto zastosować najlepszą kombinację narzędzi do pracy. To powiedziawszy, pewne luźne (surowe wytyczne) lub wąskie (stosowane w określonych okolicznościach) standardy są prawdopodobnie uzasadnione.

Answer 3

Dokładna dyskusja pomiędzy głównymi programistami lub członkami zespołu (ewentualnie zarejestrowana na później) jest znacznie bardziej wartościowa niż jakikolwiek dokument, moim zdaniem. Dajcie im pełną swobodę wyboru narzędzi i poproście ich, aby napisali na początku krótkie podsumowanie decyzji technicznych na wysokim szczeblu. Może to być podstawą dokumentacji późniejszej w projekcie. Dokument techniczny przestaje działać zbyt wcześnie i zajmuje zbyt dużo czasu na pisanie.

Answer 4

Myślę, że powinien istnieć jeden zestaw narzędzi i standardów, które są określone w czasie architektury, opisujące sposób dokumentowania projektu. Naprawdę ważne jest posiadanie standardu do dokumentowania tych rzeczy; w przeciwnym razie mają tendencję do upadku z drogi; a jeśli dokumentacja projektowa jest heterogeniczna, istnieje niebezpieczeństwo, że ludzie, którzy naprawdę muszą wiedzieć najwięcej o projekcie, mogą nie być w stanie znaleźć informacji o projekcie, których naprawdę potrzebują, kiedy naprawdę ich potrzebują.

Powiedział, że wybór narzędzi i standardów zależy wyłącznie od każdej organizacji; wszystko, co działa dla organizacji, jest dla nich odpowiednie. Dopóki istnieje zgodność w standardach (i narzędziach do pewnego stopnia), cokolwiek zostanie wybrane dla danej organizacji, jest dla nich odpowiednie. To musi być po prostu postanowione i egzekwowane.