Jak zaprojektować / zaplanować tworzenie aplikacji internetowych?

Zależy od typu i wielkości aplikacji internetowej. Jeśli robisz małą witrynę e-commerce z koszykiem, prawdopodobnie poświęcisz więcej wysiłku na stronę projektowania, a mniej na funkcjonalność "aplikacji". I odwrotnie, jeśli budujesz dużą wewnętrzną stronę internetową z wieloma ekranami wprowadzania danych, większość czasu spędzisz na logice biznesowej i regułach danych.

Osobiście nie jestem zwolennikiem sztywnych formatów lub procesów. Dostosuję do projektu i klienta z myślą o jasnej komunikacji.

Zakładając, że wymagania są już udokumentowane, dwa typy dokumentów, które zawsze staram się stworzyć jako minimum dla aplikacji webowych opartych na przepływie pracy, to:

1. Diagramy przepływu pracy wysokiego poziomu wskazujące przepływ ekranu, zmiany stanu i główne działania. Uważam to za bardzo przydatne jako pierwszy krok w udoskonaleniu głównych ruchów w aplikacji. Przepływy pracy zwykle korelują z różnymi zastosowaniami sprawy.

2. Specyfikacje ekranu dla każdego ekranu wejściowego wyszczególniające format i zachowanie każdego pola. Zazwyczaj zawiera typ pola, wartość domyślną, wartości listy, walidacje danych,reguły widoczności i działania, które można wyzwalać itp. Zasadniczo duży stół upewniając się, że deweloperzy wiedzą, jak konstruować ekrany.

Użyłem również Balsamiq Mockups w ostatnim projekcie, aby połączyć ekrany aplikacji internetowych i makiety ekranu utworzyły istotną część specyfikacji projektu - bardzo szybka w produkcji i przekazują wiele informacji o tym, jak powinny działać ekrany, które są dość trudne do przekazania w dokumencie tekstowym.

Wreszcie, Seria Joela na temat specyfikacji funkcjonalnych jest przydatna lektura.

Zachowaj to tak proste, jak to tylko możliwe.

Dokument określający podstawowe wymagania funkcji jest pierwszym krokiem.

Osobiście, ponieważ aplikacje webowe są prawie zawsze oparte na bazie danych, zaczynam modelowanie bazy danych w oparciu o wymagania funkcjonalne. Encje na diagramie ERM mapują Zwykle 1-1 z klasami na diagramie UML i już pokazują podstawowe relacje.

Zakładając architekturę MVC i dobrze udokumentowany Kod, klasy modelu będą samodokumentować w miarę ich ewolucji (np. phpdocumenter oxygen ).

Uważam, że coś prostego jak wiki działa najlepiej do pisania dokumentów, a nie formalnych dokumentów, które mogą trwać dłużej niż odpowiedni kod, szczególnie w zwinnym środowisku.

1. Wymagania to jeden zestaw dokumentów, który może zawierać grafikę, dokumenty Word, wiadomości e-mail i inne sposoby nagrywania rzeczy. Lista tego, co znajduje się w środowisku deweloperskim(IDE, Kontrola źródeł, śledzenie błędów), styl kodowania i wytyczne to kolejny zestaw dokumentów, które mogą być przydatne w pomyślnym rozwoju zespołu aplikacji. Istnieje plan projektu, który jest dużym wykresem Gantta i uwagami do wydania, które są jeszcze kilkoma dokumentami, które tworzymy.
2. I haven ' t seen many Diagramy UML inne niż to, co Gang czterech ma na swojej stronie do wyjaśnienia niektórych wzorców projektowych.
3. mamy zaległości do uzupełnienia i oszacowania, jak skomplikowana jest każda historia. Może to być inne niż stosowane podejście. Dzięki naszemu Zwinnemu podejściu może nie być tak dużo projektu/planu, jak twoja sytuacja.
4. rzadko mamy diagramy klas, chociaż Visual Studio ma przeglądarkę obiektów, która jest przydatna do zobaczenia tego, co jest już zbudowane.

Gdzie praca zwykle pracujemy parami przy tworzeniu obiektów domeny i ich członków, metod i właściwości. Klasy są tworzone w zależności od potrzeb dla historii lub jeśli sprzątamy lub refaktoryzujemy zestaw klas.

Nie ma pełnej listy klas, ale istnieją pewne wzorce projektowe w użyciu, takie jak MVP i faith, że skoro para coś tworzy, kod będzie pasował do obecnego stylu i wytycznych. Wraz z rozwojem wymagań będą wprowadzane zmiany w klasach dość regularnie, ale to naturalny sposób na robienie rzeczy dla mnie.

Tło na temat środowiska, w którym jestem na wszelki wypadek, gdyby ktoś chciał wiedzieć:

W mojej pracy mamy 5 programistów, QA lead, analityka biznesowego, team lead, architekta i kierownika projektu jako głównych ludzi w projekcie w tej chwili. W naszej pracy wykorzystujemy Scrum, programowanie w parach i kilka pomysłów TDD.

Korzystamy z Visual Studio 2008, Subversion, HP Quality Center, ASP.Net 3.5, Sitecore 6.0 I MS-SQL Serwer 2005.

Wszystkie przypadki użycia muszą być dobrze szczegółowe, ciągła współpraca ze strony klienta zawsze będzie plusem, mimo to może wyrosnąć nieprzewidziane przypadki.

Jeśli rozwijasz interakcję między różnymi serwerami, które będą ankiety / push wiadomości w różnym czasie, będziesz potrzebować diagramy sekwencji na pewno.

Unikaj przesady, w diagramach klas niepotrzebne klasy mają tendencję do grzybkowania, wycinania ich, używania większej ilości metod, śledzenia tego, co environment każda klasa będzie naprawdę działać (niektóre będą uruchamiane po stronie serwera, niektóre po stronie klienta-javascript-niektóre będą zaplanowane zadania i będą uruchamiane na prawdziwym serwerze, niektóre będą CGI (lub moduł) encapsuled by he webserver i uruchamiane na żądanie, niektóre będą interfejsem z bazą danych.

Zdefiniuj granice, wyjaśnij je. Praca po stronie serwera/po stronie klienta / bazy danych jest różna i może zająć różne czasy i osoby.