Ein Produkt ändert sich im Laufe seiner Lebensdauer immer wieder. Es gibt Änderungen und es gibt Derivate. Wie managt man die Anforderungen und wie die dazu nötigen Tests? Ich möchte das Problem an einem Beispiel darstellen was sich im Laufe der Lebensdauer eines Produktes und deren Derivaten mehr und mehr komplex darstellt. Wie schaffe ich es für so etwas den Überblick zu behalten? Wie schaffe ich es die Anforderungen zu managen, sodass ich bei P3 oder folgenden Varianten sehen kann, welche der Anforderungen bereits geprüft wurden, welche nicht nötig sind und welche ich noch machen muss? Ideal wäre es ja, wenn automatisch eine Übersicht generiert werden könnte, anhand der ich sehe was nötig ist, was nicht nötig ist, welche Tests bereits ausreichend sind und welche nicht. Und wie schaffe ich es, dass ich z.B. bei A1.3a (Entfall des Schalters) keine anderen Punkte übersehe, die dadurch beeinflusst werden könnten? Da könnte ja z.B. die Dichtheit darunter leiden, die aber ja in einem ganz anderen Test geprüft wurde und ggf. nochmals neu angesehen werden müsste. Ebenso ist es bei P3 denkbar, dass ich nicht nur die Änderungen als Solche betrachten muss, sondern auch deren Einflüsse auf völlig andere Punkte. Zunächst gibt es ein Produkt P1 mit verschiedenen Anforderungen, z.B. A1 Elektrische Werte A1.1 Stromaufnahme, 5 A A1.2 Versorgungsspannung, 5 V A1.3 Hauptschalter verfügbar A2, Gehäuse A2.1 Gewicht, 1 kg A2.2 Material, Alu A2.3 Farbe blau A3 Umgebungsbedingungen A3.1 rel. Feuchte, bis 60% A3.2 Umgebungstemperatur, -40...+50°C A3.3 Dichtheit, IP67 Dazu werden Tests gemacht und jeweils ein Bericht dazu geschrieben: T1 Elektrische Werte T1.1 Strom messen T1.2 Spannung bei diversen Tests einstellen und messen T1.3 Hauptschalter testen T2 Gehäuse T2.1 Gehäuse wiegen T2.2 Material prüfen T2.3 Farbe prüfen T3 Umgebungsbedingungen T3.1 Betrieb 100 Stunden bei 60% Feuchte betreiben, währenddessen Werte mitschreiben und danach prüfen T3.2 Betrieb bei verschiedenen Temperaturen prüfen T3.3 Dichtheit prüfen Im Laufe des Produktlebens gibt es Änderungen und wird zu P1.1: A1.2a 12 V dazu gibt es T1.2a Im Laufe des Produktlebens gibt es Änderungen und wird zu P1.2: A1.3 entfällt dazu gibt es T1.3a welche Auswirkungen hat der Entfall? Als nächstes ist eine neue Variante P2 gewünscht, die soll identisch mit P1.2 sein, aber folgende Änderungen haben: A1.4 zusätzlicher Schaltausgang T1.4 Ausgang in Tests prüfen Dann kommt eine weitere neue Variante P3. Diese soll alle Funktionen von P1.2 und P2 haben, außerdem folgende Änderungen haben. A2.2b Material Kunststoff A2.3b Farbe rot mit T2.2b T2.3b P1.2 soll gleichzeitig weiter verkauft werden, aber auch A2.2b erfüllen. In der Praxis sind das natürlich nicht nur ein paar Punkte, sondern hunderte. Ich habe hier nur versucht anhand einiger Beispiele möglichst einfach aufzuzeigen wo die Probleme liegen
Dazu betreibt man Requirement Engineering. Dafür gibt es dann spezielle Software um das verwaltbar zu machen (z.B. Caliber, HP Quality Center (welches auch für Tests verwendet wird), ...). Ich persönlich empfinde es als eine sehr dröge Aufgabe, aber es gibt auch bürokratisch angehauchte Kollegen, die da wirklich Spaß dran haben. Wenn ein System eine gewisse Komplexität hat kommt man auch kaum daran vorbei Requirement Engineering zu betreiben.
Ich empfinde das auch als sehr lästig und langweilig. Aber die Erfahrung zeigt mir, dass es bei manchen Projekten die nach und nach wachsen, völlig unmöglich wird noch eine Übersicht und Verfolgbarkeit zu haben wenn man nicht mal eine Systematik rein bringt. Mir scheint aber, dass das nur funktioniern kann, wenn eine Firma dies von Anfang bis Ende durchzieht. Ich vermute das muss schon bei der Lastenhefterstellung oder spätestens bei der Pflichtenhefterstellung schon umgesetzt werden, dann während der Entwicklung konsequent eingehalten und ggf. erweitert werden und in der Testphase weiterhin gepflegt und test cases angehängt werden. Mal sehen, ob ich da einen Einstieg finden kann. Ich befürchte nur, dass nicht alle Beteiligten mitziehen wollen oder aus zeitlichen Gründen nicht können und deshalb doch nichts erreicht wird :-/
Reinhard H. schrieb: > Mir scheint aber, dass das nur funktioniern kann, wenn eine Firma dies > von Anfang bis Ende durchzieht. Ich vermute das muss schon bei der > Lastenhefterstellung oder spätestens bei der Pflichtenhefterstellung > schon umgesetzt werden, dann während der Entwicklung konsequent > eingehalten und ggf. erweitert werden und in der Testphase weiterhin > gepflegt und test cases angehängt werden. > > Mal sehen, ob ich da einen Einstieg finden kann. Ich befürchte nur, dass > nicht alle Beteiligten mitziehen wollen oder aus zeitlichen Gründen > nicht können und deshalb doch nichts erreicht wird :-/ Ja es bringt ordentlich zeitlichen Overhead. Sehe ich hier ja tagtäglich beim Kunden und merke ich selber wenn ich mal wieder Caliber oder HPQC anfassen muss schauder
D. I. schrieb: > schauder https://de.wikipedia.org/wiki/DOORS ist noch so ein Tool... Macht man, weil man muss... (Kundenanforderung) oder weil die Schmerzen schon groß sind. (In welcher EXcel-Tabelle war DASS jetzt :> )
Requirement Engineering wird immer wichtiger, ich bin auch nach der Suche eines System, wenn's irgendwie geht, OpenSource und nicht Web-basierend. Es gibt und gab immer wieder Ansätze, aber das meiste ist wieder schnell eingeschlafen. Alternativ wäre auch eine (bezahlbare) kommerzielle Lösung denkbar, darf aber nicht so unglaublich fett und überladen sein. Irgendwer eine Idee?
In meinem Fall sind es die Schmerzen... Und die Einsicht, dass es ohne einfach nicht mehr geht. Man hat ab einem bestimmten Grad keine Chance mehr zu finden wo was gemacht wurde, in welchem der vielen Anforderungs- und Änderungsdokumenten die nötige Anforderung steht und was nun gültig ist und was nicht. Wenn man auditiert wird, hat man kaum eine Chance dem Kunden auf all seine Fragen eindeutig nachvollziehbare Antworten zu geben. In dem Moment wird einem noch klarer wo man noch Lücken hat und wie viele das tatsächlich sind. Polarion scheint auch so eine Software zu sein mit der man so etwas aufziehen kann. Aber bei anfänglichen Versuchen kam für mich heraus, dass nur ein Teil der Mechanismen die wir bräuchten darin abgedeckt ist. Dazu kommt noch die Problematik, dass interne Strukturen und Workflows einfach nicht zu diesem neuen System passen würden. Die komplette Firma müsste angepasst werden. An meinem Punkt (Test) scheint nicht der richtige Punkt zu sein dort einzusteigen. Aber schön dass ich nicht allein mit dem Problem bin :-)
Henrik V. schrieb: > https://de.wikipedia.org/wiki/DOORS > > ist noch so ein Tool... DOORS ist kein Tool sondern ein Folterinstrument aus dem tiefsten Mittelalter (frühe 90er... so fühlt sich die Technik vom Aussehen und der Geschwindigkeit her an). Es vergeht kein Tag an dem ich mir nicht wünsche, dass jemand endlich mal das Rechenzentrum mit den Servern und allen Backups abfackelt. .___.
Lu R. schrieb: > Henrik V. schrieb: >> https://de.wikipedia.org/wiki/DOORS >> >> ist noch so ein Tool... > > DOORS ist kein Tool sondern ein Folterinstrument aus dem tiefsten > Mittelalter (frühe 90er... so fühlt sich die Technik vom Aussehen und > der Geschwindigkeit her an). Es vergeht kein Tag an dem ich mir nicht > wünsche, dass jemand endlich mal das Rechenzentrum mit den Servern und > allen Backups abfackelt. .___. DOORS: uuaaaahh Vor kurzem habe ich mit Codebeamer gearbeitet (http://intland.com/codebeamer/product-overview/). Das ist ähnlich gestrickt wie DOORS bietet aber mehr Möglichkeiten. Nichtsdestotrotz ist das ganze Requirement-engineering öde und lästig, aber notwendig.
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.