Jak często prototypowanie jest pierwszym etapem rozwoju?

10

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ć?

EpsilonVector
źródło
2
Z mojego czytania wynika, że ​​wydajesz się zbyt skoncentrowany na części dotyczącej tworzenia oprogramowania interfejsu użytkownika. Prototypy doskonale nadają się do opracowywania i udoskonalania interfejsów użytkownika, nie tyle do opracowywania podstawowej logiki (lub nawet do dokładnego zrozumienia, jaką logikę biznesową należy wdrożyć)
Anon.
1
Jeśli jest to użytkownik, zwykle jest to GUI. Jak powinien wyglądać GUI i jak powinien działać, wpłynie na projekt całego systemu.
Job

Odpowiedzi:

6

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).

Walter
źródło
+1 Prototyp mojej firmy dość często, ale tylko jako dowód słuszności koncepcji, głównie w GUI, ale także podczas badania nowego podejścia do problemu, także po stronie serwera.
Orbling
6

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.

Ciemna noc
źródło
1

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.

Matthew Read
źródło
0

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.

leed25d
źródło
+1 Bardzo prawda, prototyp jest postrzegany przez marketing, który zwykle ogłasza zakończenie projektu.
Orbling
1
Jest to argument za tym, aby twoje prototypy były jak najlepsze, biorąc pod uwagę czas, a nie za odmowę wykonania prototypów.
Inaimathi
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)

Steven A. Lowe
źródło
0

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.


źródło