Jakie metodologie tworzenia oprogramowania można uznać za podstawy

10

Piszę mały artykuł badawczy, który dotyczy metodologii tworzenia oprogramowania. Przeglądałem wszystkie dostępne metodologie i zastanawiałem się, czy na podstawie wszystkich metodologii istnieją podstawy, na których opierały się inne?

Na przykład, patrząc na następujące metodologie:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.

Czy możemy powiedzieć, że:
prototypowanie, iteracja, spirala i wodospad są „fundamentem” dla innych?

Czy też nie ma czegoś takiego jak „fundamenty” i czy każda metodologia ma swoją unikalną historię?

Oczywiście chciałbym opisać wszystkie metodologie w mojej pracy badawczej, ale po prostu nie mam na to czasu i dlatego chciałbym wiedzieć, które metodologie można uznać za przedstawicieli.

Bas
źródło

Odpowiedzi:

5

Nazwy na liście nie są metodologiami i są skalowane na różnych poziomach:

  • Iteratywna jest cechą wspólną dla kilku metod i technik. Scrum to iteracyjna metodologia, TDD to technika iteracyjna.
  • Widzę Agile jako nadzór metodologiczny, który pozostaje na poziomie konceptualnym / filozoficznym. W programowaniu obiektowym można to opisać jako abstrakcyjne - jest to zbiór wartości i zasad, których nie można utworzyć, a które trzeba wyprowadzić i zaimplementować. Tak właśnie robią Scrum i XP.
  • Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model są odpowiednimi metodologiami, tj. Procesami tworzenia oprogramowania (chociaż Scrum twierdzi, że jest lekkim „szkieletem” w przeciwieństwie do ciężkiego procesu)
  • Prototypowanie i TDD to techniki, działania. TDD to praktyka XP.

Wyróżnienie, które jest podstawą, jest trudną pracą. Oczywiście możesz narysować linię historyczną, ale metodologia rzadko opiera się bezpośrednio na innej. Raczej się pokrywają, pożyczają od siebie, czasem reagują na siebie ... Nie widzę jasno określonej klasyfikacji, choć prawdopodobnie można by zarysować kilka dużych rodzin.

Innym sposobem spojrzenia na to jest z perspektywy generacji. Jeśli chodzi o oprogramowanie dla przedsiębiorstw, powiedziałbym, że znamy 2 generacje metodologii. Pierwsze z nich, w tym Waterfall i V-Model, były w większości wcześniejszymi procesami z innych dziedzin inżynierii stosowanych w oprogramowaniu. Druga generacja (można ją nazwać Agile, ale rozpoczęła się na długo przed stworzeniem terminu Agile) została zainicjowana w reakcji na ciężkość procesów pierwszej generacji, kiedy ludzie zaczęli zdawać sobie sprawę, że oprogramowanie było zupełnie innym zwierzęciem i że kryteria, które spełniają oprogramowanie i kroki, które mogą zapewnić, że te kryteria były naprawdę konkretne i nadal wymagały zbadania.

Na koniec należy zauważyć, że w oprogramowaniu może nawet bardziej niż w innych dyscyplinach, metodologie nie są przepisami, które można po prostu zastosować, aby wszystko działało. Tworzenie oprogramowania ma tyle ludzkich aspektów, co aspekty techniczne, a zespół lub menedżer wymyślający srebrną kulę i listę kontrolną rzeczy, które ślepo stosować, mogą spodziewać się niespodzianek. Patrząc na badania dotyczące wskaźników powodzenia projektu oprogramowania, takie jak raport Chaos rok po roku, możesz stwierdzić, że historia metodologii oprogramowania ma więcej wspólnego z serią nieudanych prób niż reguła solidnych, naukowo potwierdzonych, powtarzalnych procesów.

guillaume31
źródło
Polecam ten artykuł akademicki, który porównuje 2 typy procesów oprogramowania podobnych do 2 generacji, o których wspominałem: paulralph.name/wp-content/uploads/2011/01/…
guillaume31
3

Są trzy:

  1. none (inaczej kodowanie kowboja)
  2. wodospad
  3. szybki rozwój aplikacji (RAD lub spiralny)

reszta to ich warianty i kombinacje

zauważ, że artefakty z wodospadu (początki, wymagania, specyfikacja funkcjonalna, specyfikacja projektu, specyfikacja testowania, specyfikacja kontroli jakości itp.) obejmują wszystkie rzeczy ważne dla projektu, z których większość, jeśli nie wszystkie, są objęte innymi metodami, ale w bardzo różne sposoby. Na przykład w TDD funkcje, historie użytkowników i opisy testów obejmują wymagania, specyfikację funkcjonalną i specyfikację testowania z wodospadu. W RUP dodaje się jeszcze więcej artefaktów, które odrywają fragment specyfikacji wodospadu (na przykład dokument Interesariuszy jest fragmentem dokumentu Incepcji), ale postępuje spiralnie

po zakończeniu opublikuj link do swoich wyników, brzmi to jak ciekawy artykuł!

Steven A. Lowe
źródło
@Bas: James Martinowi przypisuje się określenie „szybki rozwój aplikacji” w 1991 r. En.wikipedia.org/wiki/...
Steven A. Lowe
Dziękuję bardzo za tę odpowiedź! Zobaczę, czy mogę później opublikować wyniki, ponieważ jest to część zadania, które wykonuję dla firmy. Spróbuję więc sprawdzić, czy uda mi się uniezależnić go od zadania firmy :)
Bas
0

Może chcesz tylko wspomnieć o antycznych metodologiach (nie „metodologii”), takich jak:

  1. przetwarzanie wsadowe: prześlij talię kart i odzyskaj dane wyjściowe następnego dnia. Wady: zbyt dużo czasu między zgłoszeniami; w celu debugowania zapoznaj się ze zrzutem pamięci.

  2. metody cli - użyj vi lub emacs, a następnie skompiluj; wszystko z wiersza poleceń, podobnie jak dzieje się to w powłoce linux, nawet do dziś. Wady: trudne do debugowania (gdb? Żartujesz sobie ze mnie?), Niejasne 40-letnie polecenia powłoki.

Tylko myśl.

Pete Wilson
źródło
1
Tak naprawdę nie tego szukałem. Naprawdę chciałbym wiedzieć o metodologiach tworzenia oprogramowania, które są wykorzystywane w projektach rozwoju oprogramowania.
0

Możesz wymienić trzy podstawowe podejścia: prototypowanie, spirala i wodospad. Nie rozważałbym Lean, TDD ani Cleanroomu jako metodologii, ale raczej proces, który może być częścią metodologii.

Marcin Wosinek
źródło