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?
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.
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
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.
Ich habe eine Frage zum V-Modell, weil ich es endlich
besser verstehen möchte..
Lobenswert. ABER:
Warum steht im Titel "Wasserfallmodell", wenn es NUR
um das V-Modell gehen soll?
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 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. "
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)
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.)
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.
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.
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)
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.
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 :)
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.
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.
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.
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.
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".
