Ich habe eine Frage zum V-Modell, weil ich es endlich besser verstehen möchte.. Also jeder Entwicklungsstufe steht eine Teststufe gegenüber. Und es wird trotzdem alles nacheinander ausgeführt. Das 'V' deutet also nur darauf hin, dass es trotz der Linearität vordefinierte Tests für die Schritte gibt. Gibt es denn irgendeine genormte Vorlage? Halten sich alle an dieses Modell, wenn sie es nutzen? Es kommt mir so vor als gäbe es nur unterschiedliche Darstellungen. Woher soll ein Unternehmen, welche Darstellung genutzt werden soll, wenn alle unterschiedlich sind? https://www.researchgate.net/publication/328955806_Die_geschichtliche_Entwicklung_des_V-Modells Das 1979 von Boehm eingeführte Konzept der V-förmigen Vorgehensmodelle ist zumindest im Bereich der funktionalen Sicherheit oder allgemeiner der technischen Systeme, vor allem eingebetteter Systeme, weiterhin verbreitet und wird auf Grund seiner Betonung von Verifikation und Validation auch in entsprechenden Standards häufig gefordert. Dieses Konzept der V-förmigen Vorgehensmodelle beschreibt eine einheitliche Phasenstruktur der Modelle, die sich aber in den konkreten Phasen innerhalb dieser Struktur, dem Detaillierungsgrad der Beschreibungen und ggf. den detaillierten Inhalten der Phasen unterscheiden. https://de.wikipedia.org/wiki/V-Modell Zum V-Modell im Allgemeinen werden in der Literatur die Anzahl der Phasen und auch deren Bezeichnungen unterschiedlich dargestellt, jedoch immer mit 1:1-Gegenüberstellung von Entwurfs- und Teststufen Danke !
Angehängte Dateien:
> Das 'V' deutet also nur darauf hin, dass es trotz der Linearität > vordefinierte Tests für die Schritte gibt. Das ist ein fundamentaler Aspekt: Anforderungen sind nur dann Anforderungen, wenn man sie auch testen kann. > Es kommt mir so vor als gäbe es nur unterschiedliche Darstellungen. > Woher soll ein Unternehmen, welche Darstellung genutzt werden soll, > wenn alle unterschiedlich sind? Es sollte ein V sein und der Test rechts sollte zum links passen. Wie soll eine Darstellung dem Schreiben eines Dreizeilers genauso gerecht werden wie die Entwicklung eines neuen Militärjets? > im Bereich der funktionalen Sicherheit ... > verbreitet und wird ... > häufig gefordert. letzteres ist auch Grund für die Verbreitung
Fronk schrieb: > Gibt es denn irgendeine genormte Vorlage? Ja, wenn du als Normungskomitee die Bundesrepublik Deutschland anerkennst. "V-Modell® ist eine geschützte Marke der Bundesrepublik Deutschland" https://www.iabg.de/news-termine/details/v-modellr-xt-der-neue-standard-fuer-it-vorhaben-der-oeffentlichen-hand-steht-kurz-vor-der-veroeffentl Siehe auch: https://www.heise.de/news/Extrem-massgeschneidert-289778.html
Fronk schrieb: > Ich habe eine Frage zum V-Modell, weil ich es endlich > besser verstehen möchte.. Lobenswert. ABER: 1. Warum steht im Titel "Wasserfallmodell", wenn es NUR um das V-Modell gehen soll? 2. Es gibt nicht DAS V-Modell. Warum das so ist, wird offenbar in dem von Dir verlinkten PDF aufgedröselt (ich habe nur einen Blick hineingeworfen, es aber nicht komplett gelesen). Hast Du es gelesen und verstanden? > Also jeder Entwicklungsstufe steht eine Teststufe > gegenüber. Hmmjaa.. > Und es wird trotzdem alles nacheinander ausgeführt. Nein. > Das 'V' deutet also nur darauf hin, dass es trotz > der Linearität vordefinierte Tests für die Schritte > gibt. Nein. Das Entscheidende am "V" ist, dass es zweidimensional ist, und eben nicht bloß linear. Es gibt ZWEI Sorten von Prüfungen, nämlich Dokumente gegen andere Dokumente, und das Produkt gegen Doku- ment(e). > Gibt es denn irgendeine genormte Vorlage? Lies das PDF.
Gibt es schon bei dem V-Modell das tailoring? Oder nur bei dem neuen XT? Ist damit das gemeint, dass man es anpassen kann? Aber Hauptsache es gibt zu jeder Anforderungen/ Umsetzung noch einen Test? "XT steht für „eXtreme Tailoring“ und soll je nach Projektart ein maßgeschneidertes Vorgehen erlauben, das durch vorgefertigte Dokumentvorlagen wie Plan- und Angebotsbausteine unterstützt wird. "
Grummler schrieb: > 1. Warum steht im Titel "Wasserfallmodell", wenn es NUR > um das V-Modell gehen soll? Weil das V-Modell (leider nur) eine Weiterentwicklung des Wasserfalls ist. Quasi Wasserfall links, und zurück bergauf rechts. So genial die rechte Seite ist (ernsthaft), die linke hat weiterhin das Problem, dass man am Anfang schon genau wissen muss, was raus kommt. Das geht bei: - bekannten Dingen (z.B. das 20te Einfamilienhaus) - bei Safety-Funktionen (weil da zu 100% am Anfang klar ist, was am Ende rauskommen soll) Es geht nicht bei innovativen Dingen. Für die sind Iterationen erforderlich (egal in welcher Art, aber mit jedem Release sieht man neu, was man wirklich braucht und woran man noch gar nicht gedacht hat)
Deine Frage geht am Problem vorbei. Validierung der Anforderungsdefinition beim Abnahmetest??? Da ist es doch viel zu spät. Da sind schon Millionen in den Sand gesetzt und Jahre vergangen. Die "modernen" Entwicklungsmethoden haben das umgekehrte Problem. Der Benutzer kann zwar nach jedem Prototyp die Anforderungsdefinition korrigieren, aber dafür versinken die Änderungswünsche im Chaos. Da das Modell nicht funktioniert, sind die Details nach denen du fragst, vollkommen irrelevant. (Na ja, ein Entwicklungsmodell funktioniert: Ein Genie wie Steve Jobs oder Linus Torvalds beurteilt Anforderungsliste/Entwurf/Programmcode... Aber solche Genies gibt es halt nicht genug.)
Noch ein Kommentar schrieb: > Na ja, ein Entwicklungsmodell funktioniert: Ein Genie wie Steve Jobs > oder Linus Torvalds beurteilt Anforderungsliste/Entwurf/Programmcode... > Aber solche Genies gibt es halt nicht genug.) Steve Jobs und Linus haben nix beurteilt die haben einfach geklaut und umverpackt, aehm bestehendes adaptiert und ge-re-used. Linus: Minix und Steve: GUI, Mouse von Xerox.
> einfach geklaut und umverpackt
Schau dir mal die Leute an, bei denen die geklaut haben, von Douglas
Engelbart bis Alan Kay. Und vergleiche diese Entwickler mal mit den
Programmieren, die du so in deiner Firma triffst.
Ist doch klar, damit das System funktioniert muss man die
Spontanerfindungen der Kodierer abblocken. Stattdessen die
funktionierenden Xerox Konzepte umsetzen lassen.
Grummler schrieb: > Warum steht im Titel "Wasserfallmodell", wenn es NUR > um das V-Modell gehen soll? Habe mich vertan. Grummler schrieb: > Hast Du es gelesen und verstanden? Ich habe es jetzt etwas besser verstanden. Je nach Projekt muss ein geeignetes V-Model gewählt werden. "Ein Vorgehensmodell stellt eine Schablone für ein generalisiertes Projekt dar, die auf jedes konkrete Projekt angepasst werden kann. Die Anpassung wird als Tailoring bezeichnet." (Methoden und Architekturen der Softwaretechnik) Grummler schrieb: > Nein. > Das Entscheidende am "V" ist, dass es zweidimensional > ist, und eben nicht bloß linear. Beginnen die Tests nicht erst nach der Implementierung? (https://mediaweb.saintleo.edu/Courses/COM430/M2Readings/WATEERFALLVs%20V-MODEL%20Vs%20AGILE%20A%20COMPARATIVE%20STUDY%20ON%20SDLC.pdf) was bedeuetet: "in v model developer and tester works parallel" und "Once coding is completed, unit, integration and system testing happens in the sequence" Also arbeiten die jetzt parallel oder nicht? Noch ein Kommentar schrieb: > Validierung der Anforderungsdefinition beim Abnahmetest??? Meinst du, dass das ältere V-Modell das so beschreibt? Welches Modell wird denn heutzutage am meisten genutzt im Software Bereich? Überhaupt kein V-Modell mehr? Wird hauptsächlich agile verwendet? Danke
Die zu jeder Stufe gehörenden Tests bzw. Testspezifikationen können schon zusammen mit der jeweiligen Stufe entwickelt werden. Der große Vorteil besteht darin, dass Spezifikationsunsauberkeiten oder -lücken viel früher auffallen und ggf. korrigiert werden können. V-artige Entwicklungsprozesse vertragen sich sehr gut mit TDD-artigen Entwicklungsprozessen.
A. S. schrieb: > bei Safety-Funktionen (weil da zu 100% am Anfang klar ist, was am Ende > rauskommen soll) Theoretisch zumindest, praktisch kanns dir selbst da passieren dass der Kunde mittendrin draufkommt dass sein Sicherheitskonzept fürs Gesamtsystem kacke ist und über den Haufen geworfen wird, so dass sich urplötzlich auch die Anforderungen an dein Teilsystem ändern - gehe zurück auf Start und Würfle nocheinmal :)
A. S. schrieb: > Das geht bei: > - bekannten Dingen (z.B. das 20te Einfamilienhaus) > - bei Safety-Funktionen (weil da zu 100% am Anfang klar ist, was am Ende > rauskommen soll) Das Problem ist, dass man bezüglich Safety-Funktionen dann etwas in Stein meißelt und per Definition als unveränderbar tituliert, obwohl sich ggf. im Laufe der Produktentwicklung zeigt, dass diese angeblich feste Funktionalität eigentlich doch ans Produkt angepasst werden müsste. Es kenne ich durchaus aus realen Projekten, dass kundenseitig irgendwelche nachweislich unzulänglichen Funktionalitäten nicht korrigiert wurden, sondern die Korrektheit per Dekret festgestellt wurde. Dieser Kunde (genauer: dessen völlig inkompetenter Spezifikationsschreiberling) war der Ansicht, dass man nur hinreichend komplexe bürokratische Prozesse einführen müsse, um damit Sicherheit (Safety und vor allem Security) zu gewährleisten. Die externen Auditoren ließen sich davon auch ordentlich beeindrucken, so dass sie nicht ansatzweise merkten, worin die eigentlichen Sicherheitslücken bestanden. > Es geht nicht bei innovativen Dingen. Für die sind Iterationen > erforderlich (egal in welcher Art, aber mit jedem Release sieht man neu, > was man wirklich braucht und woran man noch gar nicht gedacht hat) Am allerschlimmsten ist die Fehlannahme, dass man zu Beginn des Projektes genau wisse, worum es geht. Dann besteht die Gefahr, dass man eine neue Technik oder Architektur einführt und trotzdem die alten, jahrzehntelang bewährten Entwicklungsprozesse unverändert beibehalten will. Auch so etwas habe ich schon bei Kunden erlebt. Im Zweifelsfall bescheinigt man sich eben selbst, dass das neue Projekt/Produkt superinnovativ sei, natürlich ohne einen entsprechenden Abgleich mit dem tatsächlich aktuellen Stand der Technik.
> Dieser Kunde (genauer: dessen völlig inkompetenter > Spezifikationsschreiberling) war der Ansicht, dass man nur hinreichend > komplexe bürokratische Prozesse einführen müsse, um damit Sicherheit > (Safety und vor allem Security) zu gewährleisten Dieser Kunde hat offensichtlich erkannt dass ein Prozess ausreichend komplex und umfangreich sein muss damit man externe Auditoren mit Nebensächlichkeiten beschäftigt halten kann.
Andreas S. schrieb: > Das Problem ist, dass man bezüglich Safety-Funktionen dann etwas in > Stein meißelt und per Definition als unveränderbar tituliert, obwohl > sich ggf. im Laufe der Produktentwicklung zeigt, dass diese angeblich > feste Funktionalität eigentlich doch ans Produkt angepasst werden > müsste. Bei der 61508 ist es prinzipiell ja so, dass man Gefahren eines Produktes identifiziert, bewertet. Und dann zur Reduzierung Sicherheitsfunktionen in Hard- und Software einbaut, bei SW mit V-Modell. Wenn sich Anforderungen an die Sicherheitsfunktionen ändern, kann ich nur von vorne loslegen, da ja auch die Validierung sich ändern muss und evt. jede Anforderung/Verification dahinter. Klar kann ich dabei einiges "wiederverwenden". Im Unterschied zur eigentlichen Produktentwicklung habe ich aber keine geplanten Iterationen: a) alle Implementierungen müssen "einfach" und erprobt sein --> keine "Forschung"/"Ausprobieren". b) Alle Anforderungen müssen 100% erfüllt werden, kein "möglichst", "versuchen" oder "wenn das klappt". Wenn Sicherheitsfunktionen definiert werden, während das Produkt entwickelt wird, kann das nur vorläufig sein, da eine abschließende Bewertung der Gefahren nicht möglich ist. In der Praxis wird das ganze Thema als Schikane erachtet und mehr Gehirnschmalz in das Faken der Dokumente als in die Sicherheitsfunktionen gelegt. Und wie früher Nassi-Shneiderman-Diagramme ausnahmslos am Ende der Arbeiten. Der Tüv warnt beispielsweise eher vor zu viel Overhead in Dokumenten als zu wenig, solange Titel, Datum und Verfasser erkennbar sind.
A. S. schrieb: > Wenn sich Anforderungen an die Sicherheitsfunktionen ändern, kann ich > nur von vorne loslegen, da ja auch die Validierung sich ändern muss und > evt. jede Anforderung/Verification dahinter. Genau so sollte es ja auch erfolgen. In der Praxis findet man aber sogar in extrem regulierten und bezüglich der funktionalen Sicherheit hochgradig kritischen Bereichen unzählige Beispiele, in denen dementsprechend gepfuscht wird. Das beste Beispiel ist die Boeing 737 MAX 8. Einer meiner Kunden hatte mal für einen FMEA-Workshop alle Beteiligten an einer Produktentwicklung zusammengetrommelt. Hierbei sollte jeder Akteur realistische Abschätzungen bezüglich der Zuverlässigkeiten seiner Komponenten abgeben. Dabei wurde nicht einmal vorab überhaupt definiert, was mit diesem Begriff gemeint war. Trotzdem sollte jeder eine Zahl von 0% bis 100% nennen. Natürlich gab ich hier entsprechend niedrige Werte an, da der Kunde ja für die von uns gelieferten Komponenten auch keine ausgiebigen Tests beauftragt hatte, sondern diese selbst durchführen wollte. Daraufhin stellte der Vertreter eines anderen Zulieferers fest: "Fa. Schweigstill kann also keine zuverlässigen Produkte entwickeln! Das hatten wir doch gleich gesagt. Unsere Komponenten sind natürlich alle zu 99,99% zuverlässig." In der anschließenden Diskussion konnte er aber überhaupt nicht belegen, wie er zu dieser hohen Einschätzung überhaupt gekommen wäre. Der Projektleiter unseres gemeinsamen Kunden meinte zu mir, ich solle doch einfach ähnliche Werte nennen wie der andere Zulieferer. Dies tat ich auch widerwillig, aber der Kunde und der FMEA-Auditor waren glücklich. Das Fazit nach zwei Tagen FMEA-Workshop war, dass die FMEA-Matrix anfangs noch etliche kritische Punkte enthielt, aber zum Ende hin alles "grün" war. Damit konnte der Auditor dem Kunden gegenüber das erforderliche Zertifikat ausstellen. Das ganze war natürlich eine ziemlich lächerliche Farce, aber erfüllte wohl die formalen Prozesse. Super. Bei einem anderen Produkt gab es gewaltige Schwachstellen in der Netzwerksicherheitsarchitektur, auf die ich auch in aller Deutlichkeit hinwies. Insbesondere ein Dienst auf einem TCP-Port hätte mit Leichtigkeit angegriffen und das gesamte Gerät kompromittiert werden können. Der "Projektleiter" (bewusst in Anführungszeichen) ordnete darauhin an, dass im Produkthandbuch in der Rubrik für Sicherheitshinweise aufgeführt werden solle, dass es untersagt sei, Verbindungen zu TCP-Port 12345 aufzubauen. So einfach ist die Sache. Glücklicherweise flog ihm diese Anweisung ziemlich schnell um die Ohren, da ich die Thematik im Anschluss natürlich direkt mit dem Geschäftsführer des Kunden besprach. Die hauseigenen Minderleister (andere Bezeichnungen passen leider nicht) nickten jedoch immer alles ab, was der "Projektleiter" vorschlug. Zum einen waren sie selbst nicht qualifiziert genug, um fachliche Kritik zu üben, und zum anderen hatten sie schon lange keine Lust mehr, sich mit dem Typen herumzuschlagen. Dem Geschäftsführer war der Typ schon lange ein Dorn im Auge, und er erzählte mir auch, dass er schon seit geraumer Zeit überlege, ihn hochkant rauszuschmeißen. Da der Typ aber schon (inklusive unzähliger Vorgängerunternehmen) zig Jahre Betriebszugehörigkeit hatte und es bei jeder Restrukturierungsmaßnahme schaffte, sich wegzuducken, war er quasi unkündbar geworden. Und laut seinem uralten Arbeitsvertrag aus den 1980er Jahren wurde er als "Leitender Angestellter" beschäftigt und hatte daher auch einen Anspruch darauf, irgendwelche kleinen Leitungsfunktionen auszuüben. Und so mussten alle damit leben. Dieser Typ ist zwar ein Extrembeispiel, aber in ähnlicher Ausprägung gerade in großen, alteingesessenen Konzernen in großer Zahl auf irgendwelchen "Leitungspositionen" zu finden.
:
Bearbeitet durch User
Also ich habe mit DIN5012x im Bahnbereich zu tun, da ist V-Modell quasi Pflicht. Wer halt nicht ehrlich agiert bekommt halt ein „unehrliches“ Produkt. Im Schadensfall stehen dann die Ermittler vor dessen Tür, die verantwortlich war - auch wenn Druck vom AG dahinter stand und Du als Projektleiter nachgegeben hast… Im Übrigen geht es ja nicht nur um Formalismus, vielmehr auch um Bewusstsein.
Andreas S. schrieb: > Unsere Komponenten sind natürlich alle > zu 99,99% zuverlässig. 1 zu 100.000 waren beim Space-Shuttle so sehr Programm, dass die Leute es selber geglaubt haben. Feynman bezeichnete im Zuge seiner Untersuchungen zum Challenger-Unglück Leute, die solche Zahlen "erfinden" als "full of crap".
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.