Co zaplanować przed rozpoczęciem opracowywania projektu? [Zamknięte]

Powiedzmy, że otrzymałem specyfikację projektu od klienta, a teraz czas zacząć go rozwijać. Zwykle zaczynam od pierwszego modułu (zwykle rejestracja użytkownika), a następnie przechodzę z jednego modułu do drugiego. Planuję tylko w głowie tuż przed rozpoczęciem pracy z modułem, jak to będzie działać, ale wcześniej nie planowałem.

Myślę jednak, że byłoby lepiej, gdybym przejrzał specyfikacje i zaplanowałem, jak system będzie działał, zanim go zakoduję, np. Jakie są główne komponenty, jak będą wchodzić w interakcje itp. Po prostu nie jestem pewien, co dokładnie powinienem zaplanować.

Aby lepiej zrozumieć, o co proszę, jak powinienem-

a) Podziel projekt na komponenty,

b) Zaplanuj ich interakcje, np. czy powinienem robić diagramy klas, pisać testy jednostkowe itp.?

Jakieś pomysły?

Kiedy masz przywilej rozpoczęcia nowego projektu, masz puste płótno - które jest jednocześnie ekscytujące i zniechęcające. Pracuję w iteracjach i tak dzielę pracę:

• Zacznij od celów projektu. Cele są z konieczności najbardziej niejasne, ale pomagają skupić się na tym, co klient lub użytkownik zamierza zrobić z oprogramowaniem. Na koniec dnia chcesz osiągnąć te cele - nawet jeśli oznacza to porzucenie naprawdę fajnych funkcji.
• Potem zaczynam rozkładać aplikację na subdomeny. Prawdopodobnie jest na to sto sposobów, dlatego zaczynamy od celów projektu. Chcemy podzielić aplikację na niektóre powiązane podsystemy, które wspierają te cele. Pomaga nam to skoncentrować się na kolejnym zadaniu.
• Określ, w jaki sposób i kiedy podsystemy muszą współdziałać. Nie zajmujemy się szczegółami, a jedynie informacjami na wysokim poziomie, aby upewnić się, że mamy zintegrowany system podsystemów. Potrzebujesz ogólnej wiedzy na ten temat, abyś mógł doprecyzować szczegóły, które wspierają ogólne cele projektu.
• Podaj tylko szczegóły podsystemu, nad którym obecnie pracuję (podobnie jak w Twojej obecnej strategii). Wiem już, w jaki sposób ten podsystem musi oddziaływać z innymi podsystemami, ale może być konieczne opracowanie kilku alternatyw, aby było to najbardziej sensowne. Każdy podsystem jest oddzielony interfejsem, dzięki czemu mogę dostosować implementację tak bardzo, jak to możliwe, bez uszkodzenia systemu jako całości.
• Sprawdź, jak rzeczy są zaimplementowane w moim bieżącym podsystemie w porównaniu z tym, jak są one implementowane w innych podsystemach. Każde niespójne podejście jest czymś, czego użytkownik musi się nauczyć. Jest OK, jeśli mówimy o zupełnie nowej koncepcji. Ze względu na użyteczność nie chcemy 5 różnych sposobów usuwania informacji, które są obecne tylko dlatego, że byliśmy leniwi. Ponowne użycie tych samych elementów interfejsu użytkownika jest najszybszym sposobem na uczynienie aplikacji bardziej intuicyjną. Nauka trzech pojęć jest znacznie łatwiejsza niż nauka 20.

Zasadniczo takie podejście polegające na stopniowym definiowaniu projektu od bardzo wysokiego poziomu do bardziej szczegółowego projektowania dobrze mi pomogło. Nawet interakcje między podsystemami są udoskonalane, gdy faktycznie próbujesz je wdrożyć. To dobra rzecz.

Myślę, że byłoby lepiej, gdybym przejrzał specyfikacje

Dobrze. Dobry pomysł.

zaplanowałem, jak system będzie działał, zanim go zakodowałem.

Dobry. Zrób więcej.

jakie są główne elementy,

Doskonały.

jak będą wchodzić w interakcje,

Poprawny.

Po prostu nie jestem pewien, co powinienem zaplanować.

Jak możesz nie mieć pewności, kiedy już wymieniłeś kilka rzeczy? Jeśli są to rzeczy, które Cię dotyczą, dlaczego nie skupić się na nich?

Czytaj dalej w widoku modelu 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Przeczytaj o frameworku Zachmana: http://en.wikipedia.org/wiki/Zachman_Framework

Właśnie to musisz zaplanować.

jak powinienem a) podzielić projekt na komponenty,

Użyj powszechnie przyjętych wzorców projektowych dla innych podobnych projektów.

W razie wątpliwości przeczytaj schematy J2EE, aby uzyskać pomysły.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

jak powinienem b) Planować interakcje, np. czy powinienem robić diagramy klas, pisać testy jednostkowe itp.?

Tak. Wszystkie dobre pomysły.

Najważniejsze do zrobienia: przejrzyj specyfikacje, wejdź w interakcję z klientem, aby uzyskać bardziej wyrafinowane specyfikacje.

Wymagania są niewątpliwie niekompletne, niejasne lub nieprawidłowe. Największą stratą czasu jest robienie złych rzeczy. Klienci nie są profesjonalnymi inżynierami oprogramowania i nie można oczekiwać, że będą dobrzy w opracowywaniu dobrego zestawu wymagań.

Powinieneś więc przejrzeć specyfikacje, przeprowadzić wywiad z klientem i dowiedzieć się, czy to jest to, czego on naprawdę potrzebuje i chce, na co Cię stać itp.

Opracuj przypadki testowe / użytkowania i opisz je z klientem. Jeśli wymaganie nie jest testowalne, wyrzuć je.

Opracuj projekt i upewnij się, że wszystkie elementy działają poprawnie, więc teoretycznie zrobi to, czego potrzebujesz.

Opracuj prototyp architektury, który testuje całą technologię do zastosowania w każdej warstwie, ale ignoruje funkcjonalność. Testujesz architekturę, a nie specyfikację funkcjonalną. Nieprawidłowa architektura oznacza, że ​​musisz przepisać wszystko, więc uzyskanie właściwej architektury jest ważne. Upewnij się, że może spełnić Twoje wymagania dotyczące szybkości, wydajności, bezpieczeństwa itp.

Na pewno chcesz mieć jakiś projekt, zanim zaczniesz kodować.

Kiedy już to zrobisz, zwykle wolę najpierw wykonać początkową fazę architektury, aby określić, jak warstwy aplikacji pasują do siebie. Obejmowałoby to takie elementy szkieletowe, jak bezpieczeństwo i logowanie.

Następnie buduję 1 funkcję od góry do dołu, abyś zaimplementował coś całkowicie.

Idź stamtąd.

Wszystko

Zaplanuj wszystko, łatwiej jest go zmienić na papierze, niż gdy część jest już zakodowana, masz doskonałą podstawę do dokumentacji i wiele innych korzyści.