Zum Inhalt springen
L

Das Video kommt von YouTube: erst beim Abspielen verbindet sich die Seite mit YouTube (Google).

Software Engineering Tutorial Deutsch #3 - Das Wasserfallmodell

Programmieren Starten8:33 32.685 Aufrufe veröffentlicht Auf YouTube

Das Wichtigste aus dem Video

Tipp auf eine Zeit – das Video springt genau dorthin.

Transkriptautomatisch erstellt · 60 Zeilen
Herunterladen
  1. hallo und herzlich willkommen auf dem youtube-kanal von programmieren - staaten punkt.de mein name ist hendrik wir befinden uns im dritten teil des
  2. software engineering crash kursus und in diesem video möchten wir uns das erste vorgehensmodell ansehen und zwar das sogenannte wasserfall modell kommen wir
  3. erst mal darauf zu sprechen was wir in diesem video alles lernen werden zunächst werden wir uns mal ansehen was ist das wasserfall modell
  4. wir werden uns das also anhand einer skizze einmal bewusst machen und wenn wir verstanden haben wie dieses modell funktioniert und konzeptioniert ist
  5. werden wir uns die kritik am wasserfall modell ansehen denn da gibt es sehr viel kritik daran aber wie gesagt das verschieben wir auf später darauf kommen
  6. wir dann noch zu sprechen beginnen wir jetzt erstmal mit der frage was ist das wasserfall modell im video zuvor haben wir bereits den lebenszyklus einer
  7. software kennen gelernt und da haben wir gesehen es gibt insgesamt sechs phasen nämlich die anforderungsanalyse design und entwurf die implementierung test
  8. abnahme und einführung und auch noch die wartungsphase am ende und zusätzlich haben wir auch gelernt dass man diese sechs phasen bei der software
  9. entwicklung berücksichtigen muss so und das wasser vom modell ist jetzt eben ein vorgehensmodell wie man sich durch diese phasen hierdurch handeln kann
  10. und genau das möchten wir uns jetzt mal ansehen und hierfür habe ich jetzt diese grafik hier vorbereitet und du kannst schon sehen im prinzip sieht sie fast so
  11. aus wie die grafik aus dem letzten video nur dass wir jetzt hier eben zwischen den phasen diese stufen drin haben und diese grafik möchte ich dir jetzt mal
  12. kurz erklären und zwar ist das wasser vom modell nichts anderes als ein lineares modell das heißt die phasen folgen zeitlich aufeinander
  13. das bedeutet im umkehrschluss phasen können nicht parallel zueinander ablaufen das heißt wir können nicht gleichzeitig
  14. die anforderungsanalyse machen während wir in der testphase sind das funktioniert in diesem vorgehensmodell nicht und genau deshalb
  15. ist es eben ein lineares modell alle phasen folgen zeitlich aufeinander und in jeder phase werden jetzt zu beginn eben meilensteine definiert die es zu
  16. erreichen gilt und es gibt einen endpunkt die man erreichen möchte und sobald dieser endpunkt erreicht es sozusagen dann rutscht man eben in die
  17. nächste phase und genau aus diesem grund bezeichnet man dieses modell auch als wasserfall modell weil es eben von phase zur phase
  18. geht das ist quasi wie soja eine welle die nach unten geht wenn man sich das mal so ein bisschen bildhaft vorstellen kann
  19. und das bedeutet jetzt eben wir sind erst in der anforderungsanalyse hier wird alles geplant hier werden meilensteine für das ziel dieser phase
  20. letztendlich definiert und wenn die ziele erreicht sind und man quasi diese phase die anforderungsanalyse komplett durchgearbeitet hat dann kommt man zur
  21. design und entwurfsphase und da wird dann auch das ganze software design gemacht und erst wenn da alles abgehakt ist dann geht es in die
  22. implementierungsphase dann wird alles programmiert wenn das alles abgeschlossen ist ist schluss mit programmieren dann geht es in die
  23. testphase und so weiter also dann kommt die abnahmen und die einführungsphase und am ende auch noch die wartungsphase und das eben alles zeitlich
  24. hintereinander ab folgend also sequenziell nichts läuft parallel zueinander sondern alles schön nacheinander
  25. das bringt jetzt eben ein paar vorteile mit sich zum einen hat man jetzt eben hier diese klar voneinander abgegrenzten phasen und dadurch dass diese phasen
  26. klar voneinander abgegrenzt sind kann man eben für jede phase individuell ziele definieren und dadurch gibt es jetzt eben sehr viele meilensteine in
  27. einer phase und das ganze lässt sich sehr gut kontrollieren zudem hat man einen weiteren sehr großen vorteil denn die kosten des projekts und
  28. die voraussichtliche dauer des projekts sind von beginn an wenn einmal alles geplant wurde bekannt weil man definiert er für jede phase die ziele und die
  29. meilensteine und da kann man dann eben sehr gut abschätzen was kostet was weil man ja alles von anfang an beginnt sauber durch strukturiert und
  30. plant und alles zeitlich hintereinander abläuft aber jetzt kommt eben das große aber es gibt einige negative punkte die dieses
  31. modell mit sich bringt und deshalb schwenken wir jetzt mal um auf die nächste folie und da werden wir uns jetzt mal die kritik am wasserfall
  32. modell etwas näher ansehen der erste punkt den ich hier ansprechen möchte ist der dass man phasen in der regel nicht klar voneinander abgrenzen kann
  33. das bedeutet es ist im prinzip eigentlich fast unmöglich stell dir mal vor wir sind gerade in der testphase das heißt in der phase nach der
  34. implementierung und jetzt wird eben in der testphase festgestellt hoppla hier werden fehler gemacht da haben wir einen fehler gemacht das funktioniert noch
  35. nicht so gut da müssten wir das jetzt eigentlich verbessern aber wenn wir ganz strengen diesem modell folgen dann haben wir eigentlich
  36. die implementierungsphase schon abgehakt und wir können eigentlich nicht zurück springt das heißt programmiert wird jetzt nichts mehr wenn man ganz streng
  37. nach diesem modell geht und da sieht man schon dass es irgendwie nicht zu wirklich möglich die phasen so klar voneinander abzugrenzen das heißt in
  38. normalen software projekten muss man die verschiedenen phasen sowieso des öfteren durchlaufen damit man dann am ende zu einem guten ergebnis kommt und das
  39. widerspricht eben diesem modell ein weiterer punkt ist dass die notwendige flexibilität geraubt wird stell dir mal vor du willst ein system programmieren
  40. und von vornherein ist bekannt es gibt vielleicht zwei drei kritische stellen in diesem system da weiß man nicht so genau ob man das
  41. hinbekommt oder ob man das auf diese art und weise hinbekommt wie man sich das eben vorstellt und dann beginnt man in der regel immer
  42. mit den kritischen aspekten überhaupt denn wenn die nicht funktionieren dann braucht man sich die ganze andere arbeit auch nicht machen und dieses modell
  43. widerspricht eben diesem gedanken dass man sich die kritischen aspekte gleich mal ansieht denn man muss eben strengen diesen phasen folgen
  44. und ich hatte ja vorn bei den vorteilen sage ich jetzt mal auch angesprochen dass die kosten des projekts und die voraussichtliche dauer bereits von
  45. beginn an hansen das ist aber nur dann der fall wenn die anforderungen an das zu entwickelnde system auch während des
  46. ganzen prozesses stabil sind das heißt in der kompletten entwicklungszeit und projektdurchführung zeit ändert sich nichts an den
  47. anforderungen und auch danach ändert sich nichts mehr weil dann sind wir quasi in der phase der wartung und wir können nicht mehr zurück springen das
  48. heißt wenn sich hier eine anforderung ändern würde am ende zum beispiel weil es irgendwelche neuen technologien gibt oder es gibt ja neue geschäftsmodelle
  49. sind quasi erschaffen worden oder das alte geschäftsmodell wurde eben angegriffen von beispielsweise einem innovativen start up und man muss
  50. reagieren da muss man das ganze jahr anpassen und dazu muss man dann eben auch wieder rücksprünge eigentlich machen neue
  51. anforderungen aufstellen das system umbauen und so weiter und das heißt die anforderung die sind nie stabil und deshalb ist dieses ganze modell in
  52. software-projekten heutzutage die er komplexe auch eigentlich fast gar nicht mehr umsetzbar das heißt das wasser fallen modell das
  53. ist ein modell das man auf jeden fall mal gehört haben sollte das ist ein sehr grundlegendes modell aber in der software entwicklung heutzutage kommt es
  54. eigentlich fast gar nicht mehr zum einsatz da werden wir aber auch noch andere vorgehensmodelle kennenlernen
  55. die heutzutage sehr sehr stark im einsatz sind und sehr stark verbreitet sind aber wie gesagt jetzt war es erstmal das wasser von modell und ich
  56. hoffe du hast hier erstmal alles verstanden das war alles zu diesem video falls sie das video gefallen hat gebt uns gerne einen daumen nach oben
  57. lasst uns einen kommentar da das würde uns wahnsinnig freuen und falls du diesen kanal noch nicht abonniert haben solltest dann holt das jetzt unbedingt
  58. nach indem du unter dem video auf den abonnieren -button klickst denn dann wirst du in zukunft nichts mehr von uns verpassen und glaube uns wir werden noch
  59. sehr sehr viele videos raushauen die unglaublich viel content beinhalten werden bleibt also dabei wir sehen uns im
  60. nächsten video bis dahin

Zum Nachlesen