Jak często prototypowanie jest pierwszym etapem rozwoju?

W ciągu ostatnich kilku semestrów brałem udział w kursach projektowania oprogramowania i choć widzę wiele korzyści z formalizmu, wydaje mi się, że nie mówi mi to nic o samym programie:

• Nie można określić, jak program będzie działał na podstawie specyfikacji Przypadku użycia, nawet jeśli omawia on możliwości programu.
• Nie można powiedzieć nic o doświadczeniu użytkownika z dokumentu wymagań, nawet jeśli może on zawierać wymagania dotyczące jakości.
• Diagramy sekwencji są dobrym opisem działania oprogramowania jako stosu wywołań, ale są bardzo ograniczone i dają bardzo częściowy obraz całego systemu.
• Diagramy klas doskonale nadają się do opisania budowy systemu, ale są całkowicie bezużyteczne, pomagając ustalić, jakie oprogramowanie powinno być.

Gdzie w całym tym formalizmie jest sedno: jak wygląda program, jak działa i jakie daje doświadczenie? Czy nie ma większego sensu projektowanie tego? Czy nie lepiej jest dowiedzieć się, jak program powinien działać za pomocą prototypu i starać się go wdrożyć naprawdę?

Wiem, że prawdopodobnie cierpię na naukę inżynierii przez teoretyków, ale muszę zapytać, czy robią to w branży? Jak ludzie rozumieją, czym właściwie jest program, a nie czym powinien być zgodny? Czy ludzie dużo prototypują, czy najczęściej używają formalnych narzędzi, takich jak UML, a ja po prostu nie miałem ochoty ich używać?

Jeśli budujemy aplikację GUI, prawie ZAWSZE tworzymy prototyp lub POC (proof-of-concept). Ustalimy, jakie będzie słownictwo wizualne aplikacji. Zazwyczaj angażujemy naszego klienta częściowo przez POC i upewniamy się, że rozumie on cel i na czym powinien się skupić. Nigdy nie było mi przykro, że wyprodukowałem prototyp. Tylko upewnij się, że nie próbujesz przekształcić kodu prototypowego w kod produkcyjny, uruchom kod produkcyjny od zera na podstawie tego, czego nauczyłeś się z prototypu.

Mimo to prawie nigdy nie prototypujemy aplikacji po stronie serwera (usługi, oprogramowanie pośrednie itp.). Tak naprawdę nie widzę zwrotu z inwestycji (chyba że wprowadzasz jakieś nowe technologie i musisz udowodnić różne koncepcje).

W świecie biznesu ma to ogromne znaczenie

Ja też tak myślę, dopóki nie trafisz do świata biznesu. To nie jest już wystarczająco proste, aby po prostu wziąć wymagania i iść dalej i budować.

W biznesie schematy „przepływu” użytkownika i prototypy lo-fi naprawdę mają sens.

Sposób działania „programu” jest prawdopodobnie łatwą częścią. W aplikacjach LOB (Line Of Business) większość z nich to po prostu CRUD. Wyzwanie polega na logice biznesowej i zasad . To tutaj diagramy przepływu użytkowników i przepływy procesów biznesowych stają się niezwykle ważne w celu skutecznego zrozumienia i planowania.

Co rozumiesz przez to, jak program „działa”? Wygląda na to, że szukasz dokładnych szczegółów implementacji w czymś innym niż konkretna implementacja końcowa, co nie ma sensu. Elementy wyższego poziomu powinny kierować implementacją, a nie ją określać.

Z mojego doświadczenia wynika, że ​​prototypowanie jest dość rzadkie. Na pewno zostałem nauczony w połączeniu ze specyfikacją, wymaganiami, architekturą itp. I może być bardzo przydatny.

Jeśli chodzi o „jakie oprogramowanie musi być”, to JEST to wymagania. Wygląda na to, że brakuje ci całego punktu.

Interfejsy są często naszkicowane wcześniej, a przypadki użycia można wykorzystać do „przepływu” interfejsu. W ogóle nie brakuje wrażeń użytkownika. Jeśli uważasz, że brakuje jakiegoś elementu, zrób coś innego, o czym nie wspomnieli twoi profesorowie. Projekt nie składa się z jasnego zestawu zasad przekazanych z nieba.

Moją osobistą spostrzeżeniem jest to, że prototypowanie ma wiele warg, ale nazbyt często prototyp, gdy wykazuje oznaki życia, jest po prostu przemianowany na „Beta” lub, co gorsza, v1.0.

istnieją dwa rodzaje prototypowania - właściwie trzy:

1. budujemy prototypy w celu udoskonalenia projektu i zmniejszenia ryzyka przed rozpoczęciem „prawdziwego” kodowania (inżynieria)

2. budujemy projekt jako serię wyrafinowanych prototypów (Agile)

3. budujemy prototyp i wysyłamy go, gdy tylko zadziała (Cowboy)

To, czego szukasz, nazywa się specyfikacją - możesz przeczytać opis tego tutaj w jednym z artykułów Joela

http://www.joelonsoftware.com/articles/fog0000000035.html

Prototyp można również uznać za „iterację 0” tego, co należy zrobić. Spełnia kilka rzeczy:

• Dowodzi to, że koncepcja może zostać wykonana. Może to być twój szef lub klient płacący.
• Pozwala zidentyfikować rzeczy, które mogą być trudne do uzyskania siły produkcyjnej, i daje ogólne wyobrażenie o ilości potrzebnej pracy.
• Masz kod, który coś robi . To niezmiernie ważne!

Podsumowując, prototyp powinien z dużym prawdopodobieństwem być przydatny do budowy produktu końcowego, chyba że okaże się, że konieczne jest zupełnie inne podejście.