Kürzlich beschwerte sich ein Freund über die Dominanz des englischen Slang in einigen Fachgemeinschaften. Ich antwortete ihm, dass es schlecht, aber gezwungen war. So findet der natürliche Ausleihprozess statt, bei dem das Notwendige angepasst und das Unnötige weggefegt wird. Und in der englischen Sprache selbst gibt es viel mehr Lateinismen als in russischen Anglizismen. Immerhin kommunizierten einst diejenigen, die sich mit Wissenschaft beschäftigten, ausschließlich auf Latein.
In der russischen Sprache bleibt ein kleiner Bereich, in dem es erforderlich ist, ihn in die moderne Realität umzusetzen. Dies gilt für westliche Praktiken im Bereich der Verwaltung von Personen und Teams. Sie wurden von der sowjetischen Wissenschaft schlecht studiert, während in den 90er Jahren ihre beschleunigte Einführung von Menschen begann, die sie zuletzt als ideologisch inkorrekt betrachteten. So war es auch mit der Wirtschaft und in spezifischeren Bereichen, beispielsweise im Zusammenhang mit der Softwareproduktion.
Wir wussten immer, wie man exzellenten Programmcode schreibt. Das Softwaregeschäft ist jedoch umfassender als die einfache Programmierung - es handelt sich um Wissenshandel. Und wenn ja, dann sind Produktion und Organisation erforderlich. Hier spielen Anforderungssammlungsmanagementsysteme eine Schlüsselrolle, bei denen der Produktionsprozess auf der Grundlage westlicher Erfahrungen aufgebaut werden muss.
Weiter im Artikel werden typische Ausleihfehler anhand von Beispielen aus der Übersetzung von Karl I. Wigers 'Buch „Software Requirements Development“ analysiert. Am Ende wird das besprochene Material anhand des V-Modells des Lebenszyklus der Entwurfsanforderungen für Software zusammengefasst.
Zweifellos wird ein merkwürdiges Buch von Karl I. Wigers „Entwicklung von Softwareanforderungen“ (im Folgenden als RTkPO bezeichnet) zu einem bestimmten Standard in der russischen Informationsgemeinschaft. Die Verwendung der Bestimmungen aus diesem Buch (ausgeliehen, original, übersetzt) außerhalb des Konzepts des Autors wirft jedoch Fragen auf, die ich gerne verstehen würde.
Dies ist ein Beispiel für die Entwicklung der Anforderungen im Verlauf des Projekts von oben nach unten anhand von drei Dokumenten: „
Dokument zum Image und zu den Grenzen des Projekts “, „
Dokument zu Anwendungsfällen “, „
Spezifikation der Softwareanforderungen “. In der 3. Ausgabe werden die ersten beiden Dokumente als "
Dokument des Konzepts und der Grenzen " und "
Dokument der Benutzeranforderungen " dargestellt.
Um das richtige Dokument zu erstellen, müssen Sie zunächst dessen Kern verstehen. Es scheint, dass der Schlüssel darin besteht, das mysteriöse „
Image und die Grenzen des Projekts “ zu enträtseln: Es wurde gelöst, und Sie können vorgefertigte Übungen ohne Einschränkungen und mit großem Nutzen anwenden. Leider funktioniert dies nur mit einfachen Technologien, die von Dritten gekauft wurden. Aspekte
des Teammanagements stehen in direktem Zusammenhang mit den Merkmalen einer fremden Kultur, und dort ist nicht alles einfach. Kulturelle Unterschiede sind der sichtbare Teil des Eisbergs des gesamten Systems
unbewusster ethnischer Verhaltensstereotypen. Aber wir kontrollieren das Reich des Unbewussten überhaupt nicht oder nur teilweise.
Allerdings ist nicht alles so hoffnungslos. Wir müssen Assoziationen ihrer Terminologie mit unserer Praxis finden. Wir werden das „
Dokument über das Bild und die Grenzen des Projekts “ analysieren. Die Grenzen eines Projekts sind der
Projektumfang . Dies sollte als "
Arbeitslast " übersetzt werden. Nicht im Wörterbuch? Leider. Sie können sich das englische Handbuch ansehen:
Projektumfang - Teil der Projektplanung, einschließlich des Prozesses zur Bestimmung und anschließenden Dokumentation der spezifischen Ziele des Projekts, der Ergebnisse, Aufgaben, Kosten und Fristen . Es gibt ein bestimmtes Verfahren, warum nicht "
Projektgrenzen " nennen? In diesem Fall ergeben sich Probleme bei der Integration unserer eigenen Erfahrungen aus der Vergangenheit: Schließlich haben wir den Arbeitsumfang bereits geplant und insbesondere festgelegt.
Wenn die Wörterbuchübersetzung fehlschlägt, müssen Sie nach einem einfachen konzeptionellen Modell suchen, das die Verwendung des umstrittenen Begriffs in einem verwandten Themenbereich veranschaulicht. Die weitere Übertragung eines solch einfachen Modells der Offenlegung auf den heimischen Boden ermöglicht es uns, Sprachübereinstimmungen zu finden. Das Triple-Constraints-Modell ist eine Einführung in das Projektmanagement.
Dieses Modell zeigt die Beziehung zwischen den Begriffen „
Ausführungszeit “, „
Kosten “, „
Arbeitsaufwand “ (Zeit, Kosten, Umfang), die in Form eines gleichseitigen Dreiecks angeordnet sind, was bedeutet, dass das Ändern einer Seite dieses Dreiecks zu einer Änderung aller führt.
Project Vision wird manchmal nicht als "
Projektbild ", sondern als "
Projektkonzept " übersetzt, was jedoch keine Klarheit schafft.
Das Project Vision Statement im Handbuch ist definiert als "eine
idealistische Sicht auf die gewünschten Geschäftsergebnisse, die nach erfolgreichem Abschluss des Projekts erzielt werden ". Wir verwenden normalerweise den Begriff „
Projektziele “ und formulieren diese Aufgaben mit einem Anteil an innerstaatlichem Pessimismus. Wenn wir es „das
Bild des Projekts “ nennen, ist es unwahrscheinlich, dass dies dazu
beiträgt , westlichen Optimismus auf seinem eigenen Boden zu manifestieren. Insgesamt kann das erste Dokument als „
Projektziele und Arbeitsumfang “ bezeichnet werden. Und nichts Geheimnisvolles.
Es wird angenommen, dass solche Begriffe nicht übersetzt werden sollten, sondern die englische Sprache im Projekt verwenden sollten. Dies funktioniert nur teilweise und schränkt den Kreis der Experten stark ein. Grundlegende Sprachkenntnisse reichen nicht aus, wenn technologische Probleme mit ethnokulturellen Unterschieden zusammenhängen.
Hier ist ein typisches Beispiel von RTkPO: "
Anforderungen sollten nacheinander angegeben werden, zum Beispiel" das System wird ... "oder" der Benutzer wird ... ", dann das aktive Verb und dann das beobachtete Ergebnis ... Sie können" sollte "als Synonym für" wird "verwenden, aber Vermeiden Sie "sollte", "vielleicht", "könnte" und ähnliche Wörter, aus denen nicht klar ist, ob Maßnahmen erforderlich sind . "
Sie könnten denken, dass dies eine vorgefertigte Anleitung zum Handeln ist. Tatsächlich hilft diese Übersetzung nicht, es herauszufinden, aber sie verwirrt alles noch mehr. Darüber hinaus ist das englische Original nicht die ultimative Wahrheit, sondern Ausdruck einer bestimmten Sichtweise auf die Modalität der englischen Sprache. Die Ansicht ist im Standard RFC2119 ** verankert, der die Regeln für die Verwendung englischer Schlüsselwörter im Bereich des Anforderungsmanagements klarstellt (
z. B. muss, soll, sollte, darf ). In dieser Norm
muss beispielsweise bedeuten,
dass die Definition eine absolute Anforderung der Spezifikation ist . Der Autor traf jedoch auf Dokumentvorlagen mit einem direkten Verbot der Verwendung von
Most (eine Erklärung dieser Position finden Sie im Internet ***).
Die nächste Detailebene für Anforderungen ist das „
Anwendungsfalldokument “. Bei RTkPO wird angegeben, dass Anwendungsfälle, Szenarien und
Ereignisantworttabellen definiert werden. Die Übersetzung von „
Anwendungsfällen “ als „
Anwendungsfälle “ vereinfacht die Sicht der Dinge unnötig (daher hat sich der Anglizismus von Benutzerfällen in der Praxis fester etabliert). Moderne Software sollte Schutz vor Hacking und Schutz vor Narren haben, aber dies ist eine Option für die Verwendung - Gewalt gegen die russische Sprache. Für die Übersetzung werden „Interaktionsszenarien“ vorgeschlagen.
Tatsächlich
ist uns das
Ereignis-Antwort- Modell bekannt. In der High School wird es als "
Auswirkung - Fluktuation -> Reaktion " studiert. Unter den gleichen Einflüssen kann die Reaktion des Systems aufgrund zufälliger Schwankungen variieren. In der Anwendersoftware sind dies normalerweise verschiedene Fehlersituationen. Darüber hinaus sollten auf Konzeptebene Umwelteinflüsse von Benutzereffekten unterschieden werden. Ein mehr oder weniger geeigneter Name für diese Anforderungsstufe ist "
Systemanforderungen " oder bereits "
Softwareproduktanforderungen ", obwohl die Terminologie nicht festgelegt wurde und sehr unterschiedliche Optionen auftreten (beispielsweise wird in der neuesten Ausgabe der Name "
Benutzeranforderungsdokument " verwendet, der automatisch verwendet wird schließt eingebettete Systeme von der Prüfung aus).
Das Wesentliche bei der Entwicklung der Anforderungen dieser Ebene ist die Erstellung eines detaillierten spekulativen Softwaremodells, das in einer idealisierten Außenwelt funktioniert. Ein wichtiger Punkt ist daher das Setzen von Grenzen und das Treffen von Annahmen. „Die
Farbe des Autos kann beliebig sein, vorausgesetzt, es ist schwarz “ - so hat Henry Ford die Geschäftsanforderungen für die Farbe des Autos in eine Annahme umgestaltet. Ein anderes Mal stellte sich jedoch heraus, dass nicht planares, stromlinienförmiges Glas hergestellt werden musste, um die geschäftlichen Anforderungen an die Sauberkeit von Autos zu erfüllen. Ford-Ingenieure sagten, es sei technisch unmöglich. Ford fand die jungen Erfinder an der Seite.
Die untere Ebene wird durch die „
Spezifikation der
Softwareanforderungen “ dargestellt, die „
Einschränkungen “, „
externe Schnittstelle “, „
Qualitätsattribute “ und tatsächlich „
funktionale Anforderungen “ umfasst. Dies ist das letzte Dokument in der Abbildung. Leider werden die Fragen der nachfolgenden Tests nicht behandelt. Um die Definition zu formulieren, muss RTkPO daher das Konzept der Geschäftsanforderungen verwenden: „
Funktionale Anforderungen bestimmen die Softwarefunktionalität, die Entwickler erstellen müssen, damit Benutzer ihre Aufgaben im Rahmen der Geschäftsanforderungen ausführen können. “
Auf der Testseite ist die Definition einfacher zu erstellen: „
Funktionale Anforderungen sind Anforderungen, die getestet werden .“ Dies sollte als die Fähigkeit verstanden werden, jede funktionale Anforderung mit einem Test im klassischen Sinne zu testen (mit dem Urteil - bestanden oder nicht bestanden). Das Gegenteil ist streng genommen nicht der Fall: Einige Tests können für sich allein existieren. Das Vorhandensein solcher Tests ist jedoch ein Indikator für Auslassungen bei der Arbeit an Anforderungen. Schließlich prüft der Test jeden Codeabschnitt, der nicht von sich aus, sondern als Ergebnis der Ausführung einer bestimmten Funktionsanforderung angezeigt wurde.
Moderne ausgereifte Softwareentwicklungsprozesse versuchen, die Messkomponente in die frühen Stadien der Herstellung von Softwareprodukten zu bringen. Ohne auf Details einzugehen - zum größten Teil handelt es sich dabei um alle Arten von Abdeckungsmetriken. Einer der Indikatoren für die Qualität des zukünftigen Produkts ist der Prozentsatz der Abdeckung mit Tests der funktionalen Anforderungen, der anhand einer Tabelle (Matrix) der Abdeckung (Rückverfolgbarkeitsmatrix) berechnet wird. Es ist möglich, eine nicht funktionale Anforderung in die Matrix aufzunehmen, aber in zukünftigen Arbeiten wird sie als nicht testbar markiert, und vor allem werden Tester sie als nutzlos bewerten. Es scheint, dass eine vollständige "
Spezifikation der Softwareanforderungen " mit einer Liste nicht funktionaler Anforderungen für Programmierer sehr nützlich ist. Und das wäre vielleicht so, wenn sie nach der Zusammenstellung zumindest von Zeit zu Zeit dorthin schauen würden.
Die überwiegende Mehrheit der nicht funktionalen Anforderungen kann auf funktionale Weise geschrieben werden. Um es zu paraphrasieren: Fast jede nicht funktionale Anforderung für ein System oder Softwareprodukt kann zu einer oder mehreren funktionalen Anforderungen verarbeitet werden.
Qualitätsmerkmale in RTkPO fallen teilweise in funktionale Anforderungen, was absolut richtig ist. Die Einschränkungen und die externe Schnittstelle von RTkPO sind jedoch wie folgt definiert: „
Andere nicht funktionale Anforderungen beschreiben die externen Interaktionen zwischen dem System und der Außenwelt sowie Design- und Implementierungsbeschränkungen. Einschränkungen (Einschränkungen) beziehen sich auf die Wahl der Möglichkeit, das Aussehen und die Struktur des Produkts zu entwickeln . " Kommunikationssubsysteme mit der Außenwelt haben immer eine Schnittstelle, die funktionsfähig ist und getestet wird.
Können Einschränkungen funktionale Anforderungen sein? Auf jeden Fall ja, wenn Sie sie in umgekehrter Form als Opportunity schreiben. Zum Beispiel sollte das Produkt schneller sein als das der Wettbewerber (andernfalls wird es nicht benötigt - eine sehr strenge Einschränkung). Zunächst geht es um die Neuheit der getroffenen, dokumentierten Entscheidungen, auch in Form von Anforderungen. Es ist jedoch klar, dass das System über ein Modul verfügen sollte, mit dem die erkannten Parameter dieser Geschwindigkeit frühzeitig gemessen werden können.
Daher ist „
Funktionsspezifikationen “ ein etablierter Name für untergeordnete Spezifikationen in Form eines formatierten Dokuments oder als Datenbank unter der Kontrolle einer speziellen Software.
Was passiert als nächstes mit den Anforderungen? Neben Entwicklern (Programmierern) arbeiten auch Testingenieure und QS-Ingenieure (Quality Assurance) mit den Anforderungen. "Testen" kann als "Verifizieren" übersetzt werden, aber das "Testen" hat anscheinend stattgefunden. Für die erneute Übersetzung der Qualitätssicherung ist ein Offenlegungsmodell erforderlich - hier die Grundsätze. Erstens „
Fit for Purpose “ (das Produkt sollte für den beabsichtigten Zweck geeignet sein), zweitens „
Right First Time “ („The First Time“ - Fehler sollten beseitigt werden) und drittens Projektunabhängigkeit. Dies ist "
Akzeptanz ", die Prinzipien, die der bekannten militärischen Akzeptanz und der legendären staatlichen Akzeptanz zugrunde liegen.
Anforderungsspezifikationen bilden die Grundlage für weitere Konstruktionsdokumente. Die Anforderungen werden mindestens bei der Entwicklung der
Benutzerdokumentation verwendet . Es ist allgemein anerkannt, dass die Prüfung mit
einem Prüfplan beginnt und mit
einem Prüfbericht endet - Dokumente, die in direktem Zusammenhang mit den Spezifikationen stehen. Man kann die Abbildung in RTkPO anders betrachten - als verallgemeinertes Modell des Softwareentwicklungsprozesses (oder als Software-Lebenszyklusmodell). In diesem Modell sind die fertigen Dokumente die Ein- / Ausstiegspunkte zwischen den Phasen des Prozesses.
In chronologischer Reihenfolge werden die Dokumente wie folgt dargestellt: Geschäftsanforderungen (als Teil des Projektumfangs), Systemanforderungen (PO), Funktionsanforderungen, Testplan, Testbericht, Benutzerdokumentation. Die Linie zwischen den beiden Dokumenten ist die Prozessphase. Modelle werden oft in Form von sich wiederholenden Zyklen oder Spiralen gezeichnet, jedoch ist eine einfache chronologische Achse besser sichtbar. Dann werden die erste und letzte Phase des Prozesses nicht durch ein Segment, sondern durch einen Strahl angezeigt. In modernen Präsentationen wird die Zeitachse in der Mitte der Codierungsphase in Form des Buchstabens „
V “ gebogen, wodurch das sogenannte
V-Modell erhalten wird .
Die gestrichelten Linien zeigen Verbindungen, die die chronologische Achse umgehen, und zeigen die Möglichkeit, einige Arbeiten im Voraus zu beginnen. Zum Beispiel können Sie mit den formulierten Geschäftsanforderungen bereits etwas über die Benutzerdokumentation des Produkts sagen, und die formulierten Anforderungen für das System geben ein Modell für zukünftige Software, deren Qualität bereits bewertet werden kann.
Die Hauptfunktion dieser Linien besteht jedoch darin, die Skalierbarkeit (Vereinfachung) des V-Modells zu zeigen.
Die Unterstützung aller Phasen und Dokumente ist immer ein teures Vergnügen und ein sehr häufiger Grund, gegen mehr mobile Wettbewerber zu verlieren . Zum Beispiel funktioniert eine Person folgendermaßen: Geschäftsanforderungen -> Entwicklung (Codierung) -> Benutzerdokumentation. Dies ist die obere gestrichelte Linie des Schnitts. Outsourcing-Unternehmen überspringen in der Regel die unteren Phasen, ohne Geld für Funktionsspezifikationen auszugeben, und sind durch die eine oder andere Art von Systemanforderungen (z. B.
Interaktionsszenarien ) begrenzt. Für Produkte des gleichen Typs gibt es normalerweise einen Unternehmensstandard, und ab der Codierungsphase wird ein bestimmter Bericht über interne Tests von Entwicklern erstellt, um die QS- / Akzeptanzphase zu beginnen.
Das grundlegende V-Modell hilft bei der Klärung von Verantwortungsbereichen. Beispielsweise spielt ein Mitarbeiter je nach Phase, in der er arbeitet, die Rolle des Acceptance Engineer (QA) oder Test Engineer. Es spielt keine Rolle, ob er einem bestimmten Projekt oder einer bestimmten Abteilung zugeordnet ist. Gleiches gilt für den Analysten, Designer, Entwickler - die Fähigkeit, alle diese Rollen von einer Person zu erfüllen, widerlegt das V-Modell nicht. Für den Acceptance Engineer (QA) und den Analysten lautet die Basis „Systemanforderungen“. Sie arbeiten mit der entwickelten Software als Black Box. Für diejenigen, die an den Phasen beteiligt sind, ist Design, Entwicklung und Test eine White Box, wenn auch in unterschiedlichem Maße.
Zusammenfassend ist anzumerken, dass das V-Modell noch eine Präsentation ist (in diesem Fall zur Veranschaulichung der Designentwicklung der Anforderungen). Dies ist kein direkter Leitfaden für Maßnahmen, da echte Softwareentwicklungsprozesse komplizierter sind. Das aufschlussreiche Potenzial ist jedoch schwer zu unterschätzen.
* Karl I. Wigers "Entwicklung von Softwareanforderungen".
** Schlüsselwörter zur Verwendung in RFCs zur Angabe der Anforderungsstufe (https://tools.ietf.org/html/rfc2119)
*** Muss - Verwenden Sie kein Muss, da niemand definiert hat, wie sich das Muss vom Soll unterscheidet. Auch soll vor Gericht gehalten haben, muss nicht. Zugegeben, muss klingt stärker, oder? Ich meine, wenn Ihr Chef Ihnen sagt, dass Sie etwas tun müssen, dann werden Sie es tun. Aber wenn Sie Anforderungen schreiben, halten Sie die Dinge einfach und verwenden Sie sie einfach (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)