Designlösungen: Halten Sie sich an Ihre Regeln

Es ist kein Geheimnis, dass je größer das Softwareprojekt ist, desto mehr hängt sein Erfolg von den Ergebnissen der Arbeit der Analysten ab, insbesondere von der Wahl der richtigen Strategie für die Erstellung und Vereinbarung von Entwurfsentscheidungen. Aber wie organisieren Sie die Arbeit dieser kreativen Mitarbeiter? Und wie können die Ergebnisse ihrer Aktivitäten sowohl den Kundenvertretern als auch den Programmierern gleichermaßen klar gemacht werden? Wie beurteilen Sie den möglichen Zeitrahmen und die Bedeutung dieser Arbeit für das Projekt? In diesem Artikel habe ich versucht, meine Rezepte zur Optimierung des Managements der analytischen Arbeit an Projekten zur Erstellung von Software für Regierungskunden zu formulieren. Jede Kritik wird geschätzt.



Eine Quelle

Forschungsrahmen

, .



.

Da es derzeit mehr als zwei Dutzend Arten von Stellenangeboten für „Analysten“ auf dem IT-Arbeitsmarkt gibt , werde ich sofort reservieren, dass ich über die analytische Arbeit an staatlichen Projekten zur Erstellung kundenspezifischer Software sprechen werde. Wie meine Erfahrung zeigt, kann ein Business Analyst, der die Mechanismen zur Automatisierung von Geschäftsprozessen nicht versteht, keine angemessene Erklärung des Problems erstellen. Ebenso kann ein Systemanalytiker, der die Geschäftsziele der Automatisierung nicht versteht, nicht angemessen sein. Aus meiner Sicht sollte ein Analyst, der an benutzerdefinierten Softwareprojekten arbeitet, daher die Kompetenzen eines Business Analyst, Systemanalysten und UX-Designers kombinieren. Darüber hinaus muss der leitende Analyst für ein solches Projekt in der Regel die Funktionen des Product Owner ausführen .(wenn der Kunde es Ihnen erlaubt). Es ist die Organisation der Aktivitäten solcher "Universalsoldaten", die weiter diskutiert wird.



Bei der Erstellung von Software im Interesse von Regierungsorganisationen ist die Haupttätigkeit von Analysten mit der Lösung von Problemen verbunden wie:

• Anforderungsmanagement;
• Bildung von Problemstellungen für Programmierer, Implementierungsplanung und Kontrolle über die Implementierung dieser Aufgaben;
• Vorbereitung der Projektdokumentation.

Die Details der Verwaltung der Anforderungen für benutzerdefinierte Software, das Verfahren für deren anfängliche Verfeinerung und die Schlüsselrolle des für deren Implementierung verantwortlichen Analysten wurden im vorherigen Artikel ausführlich erörtert .



Die Spezifität der Kundenwünsche ist jedoch keine Garantie dafür, dass ihm das Endergebnis gefällt. Im Verlauf meiner Projekte wurde das folgende Muster "aufgedeckt": Alle Funktionskommentare des Kunden, die während aller Arten von Tests aufgezeichnet wurden (nicht zu verwechseln mit den identifizierten Fehlern!), Bezogen auf Anforderungen, für die die Entwurfslösung nicht proaktiv mit dem Kunden vereinbart wurde. In dieser Hinsicht sind die Statistiken von Natalya Rukol indikativ.Bei der Analyse der Ergebnisse eines der Projekte stellte sich heraus, dass fast 70% der zum Zeitpunkt der Lieferung aufgedeckten "Fehler" auf ein mangelndes Verständnis der ursprünglichen Anforderungen der Entwickler zurückzuführen waren. 



Es scheint, dass nach Klärung der Anforderungen an das Softwareprodukt ein Paket mit Konstruktionsdokumentationen gemäß GOST RD 50-34.698 erstellt , mit dem Kunden koordiniert und anschließend die Software vollständig gemäß dem genehmigten Projekt entwickelt werden muss. Es geht oft um diese Abfolge von Aktionen, die man von den hervorragenden Schülern von gestern hört (Schüler der Klasse C wissen in der Regel überhaupt nichts über die Existenz solcher Dokumente) und von vielen "erfahrenen" Spitzenbeamten, die nie persönlich für das Endergebnis der Softwareentwicklung verantwortlich waren. 



Wie meine Erfahrung zeigt, ist die Erstellung der Projektdokumentation nur der letzte Teil der Arbeit des Analytikers. Als Analogie kann man eine Forschungsarbeit zitieren, aufgrund derer ein Bericht gemäß GOST 7.32 erstellt oder eine Dissertation verfasst werden sollte. Diese Dokumente sind jedoch nur eine Form der Formalisierung der erzielten wissenschaftlichen Ergebnisse. Durchführung fruchtloser Experimente, statistische Verarbeitung von "weißem Rauschen", Suche nach Körnern der erforderlichen Informationen in Tonnen pseudowissenschaftlichen Altpapiers - all diese integralen Bestandteile der wissenschaftlichen Arbeit bleiben immer hinter den Kulissen. Gleiches gilt für die Projektdokumentation. Auf der einen Seite ist es ein integraler Bestandteil des Software - Produkts... Andererseits enthält es nur die Endergebnisse der analytischen Arbeit.  





Quelle



Meiner Meinung nach ist dieser Aspekt einer von mehreren Gründen, warum „dumme“ Kunden gemäß den Anforderungen von Regierungsaufträgen für Softwareprojekte planen, sich in der Phase der Vorprüfung auf die Konstruktionsdokumentation zu einigen, d. H. zum Zeitpunkt des tatsächlichen Abschlusses der Softwareentwicklung.



Aus diesem Grund werden in unseren Softwareprojekten in JIRA zwei verschiedene Arten von Aufgaben gebildet, mit denen wir die analytische Arbeit direkt von der Aktivität zur Erstellung der Projektdokumentation trennen können. Und was erfreulich ist, ich bin nicht der einzige, der zu solchen Schlussfolgerungen gekommen ist... Was genau sollten Analysten bei einem Softwareprojekt tun, nachdem sie die Anforderungen festgelegt und die Projektdokumentation fertiggestellt haben?

Designlösungen VS Designdokumentation?

Wie schön es auf dem Papier ist,

wie einfach es ist, Worten zu folgen.

Wie einfach es ist, dich unfehlbar zu machen.



B. Grebenshchikov

Trotz der Tatsache, dass die Definition des Konzepts "Entwurfslösung" in GOST 34.003-90 enthalten ist , wurde in meinem Fall die Bedeutung dieses Konzepts im Verlauf schmerzhafter und erfolgloser Versuche "entdeckt", mit den Kundenvertretern mehrerer miteinander verbundener, aber nicht eindeutiger Anforderungen übereinzustimmen, als die Kunden den Vorschlag einfach ignorierten Wir beschreiben die Festlegung von Zielen ( TMP ), die in strikter Übereinstimmung mit RD 50-34.698-90 gebildet werden. Nachdem festgestellt wurde, dass die Entscheidung des Kunden erst zu Beginn des Tests getroffen werden würde, wurde das folgende Manöver durchgeführt: Unsere Konstruktionslösung wurde an den Kunden gesendet (d. H. Eine Lösung, auf die er sich formal nicht einigen musste). 



Die rituellen Attribute wurden in der Entwurfslösung beibehalten, es wurden jedoch erhebliche Anpassungen an diesem Dokument im Vergleich zum gehosteten HMO vorgenommen. Die Entwurfslösung wurde durch ein Diagramm eines automatisierten Geschäftsprozesses mit einer kurzen Beschreibung, Layouts der Benutzeroberfläche, Formen empfangener Berichte zum Drucken, Vorschlägen für die Verteilung des Zugriffs sowie einem kurzen Szenario für die Bereitstellung dieser Entwurfslösung ergänzt. In Bezug auf mehrdeutige und widersprüchliche Anforderungen wurde eine eindeutige und detaillierte Beschreibung vorgenommen. Der Rest des Textes wurde jedoch auf jede mögliche Weise minimiert. Triviale Algorithmen wurden überhaupt nicht beschrieben, ebenso wie Felder von Bildschirmformularen nicht beschrieben wurden, deren Zweck und Validierungsregeln aus den gegebenen UI-Layouts ersichtlich waren.  



Der resultierende Cocktail hatte gleichzeitig eine ähnliche Form wie ein Dokument, das gemäß den Anforderungen von RD 50-34.698-90 erstellt wurde, entsprach jedoch keinem der in diesem GOST angegebenen Formate. Gleichzeitig wurde das, was darin geschrieben stand, von einem gewöhnlichen, unvorbereiteten Vertreter des Kunden verstanden. Die in diesem Dokument angegebenen Anforderungen waren sowohl für den Kunden als auch für den Auftragnehmer völlig klar. Die Grenzen der Anforderungen, der erforderliche Umfang der geplanten Arbeiten und die Art und Weise, wie diese Arbeiten hätten abgeschlossen werden sollen, wurden festgelegt.



Das Anschreiben enthielt ungefähr Folgendes:



„Wir präsentieren eine Variante einer Designlösung, um die aufgeführten Anforderungen zu erfüllen. Wir informieren Sie über den Beginn der Arbeiten zur Umsetzung der vorgestellten Option. Wenn Sie mit der vorgeschlagenen Designlösung nicht einverstanden sind, informieren Sie uns bitte darüber. "



Im Falle einer weiteren Erörterung der Anforderungen wurde das Fehlen einer Antwort auf ein solches Schreiben als formelle Vereinbarung des Kunden mit der vorgeschlagenen Entwurfslösung interpretiert. Wenn der Kunde Einwände erhob, wurde er in diesem Fall darüber informiert, dass die Arbeiten zur Implementierung dieser Entwurfslösung ausgesetzt wurden und erst nach deren Genehmigung fortgesetzt werden konnten. In diesem Fall war die weitere Genehmigung in der Regel viel schneller.



Was lustig ist, zuerst in Antwortschreiben, wenn der Kunde nicht die notwendigen Klarstellungen gesendet hat, haben wir den Ausdruck "Arbeit ist ausgesetzt" verwendet. Nach mehreren derartigen Schreiben begann einer der Vertreter des Kunden einen Skandal im Zusammenhang mit der Tatsache, dass „gemäß dem unterzeichneten Vertrag die Arbeit nicht ausgesetzt werden kann und die mangelnde Klärung der Anforderungen kein Grund für die Beendigung der Entwicklung ist“. Er hatte jedoch keine Einwände gegen den Wortlaut, dass „die Arbeit nicht fortgesetzt werden könne“. 



Wie sich später herausstellte, erleichterte der vorgeschlagene Ansatz trotz der Tatsache, dass die gebildete Struktur der Entwurfslösung nicht den Anforderungen von GOST entsprach, die rituellen Körperbewegungen für die Erstellung und Genehmigung der Entwurfsdokumentation erheblich. Der Inhalt der Konstruktionsdokumentation, der für die Lieferung des Projekts erforderlich war, wurde durch selektives Kopieren der relevanten Abschnitte der Konstruktionslösungen gebildet. Gleichzeitig wurden in Bezug auf die Abschnitte der Dokumentation, die auf der Grundlage präventiv "vereinbarter" Entwurfsentscheidungen erstellt wurden, vom Kunden während der Abnahme keine Kommentare abgegeben.

 Beschreibung des Elefanten nicht nach GOST

Die Wahrheit ist, dass Kunden nicht wissen, was sie wollen. Normalerweise wissen sie nicht, welche Fragen beantwortet werden müssen, und haben fast nie so ausführlich über das Problem nachgedacht, wie es in der Spezifikation angegeben werden sollte. 



Frederick Brooks

Meiner Meinung nach ist das Hauptkriterium für eine gute Beschreibung der Problemstellung (Entwurfslösung) nicht die Erfüllung der formalen Anforderungen von GOST, sondern eine eindeutige Beschreibung der Bedingungen für den erfolgreichen Abschluss der Arbeiten zur Erfüllung der Kundenanforderungen. Unter diesem Gesichtspunkt ist die Beschreibung von Testobjekten zur Überprüfung der Anforderungen tatsächlich ein wesentlicher Bestandteil jeder Entwurfslösung.





Es sollte beachtet werden, dass bei der Arbeit mit einem Regierungskunden alle Unklarheiten und Unklarheiten in Ihren Entwurfsentscheidungen immer zugunsten der Regierung interpretiert werden. Um solche blinden Flecken durch Versuch und Irrtum bei den Protokollierungsanforderungen zu vermeiden, wurde eine Checkliste zur Bewertung der Entwurfsqualität entwickelt, in der die Hauptabschnitte aufgeführt sind, die bei Bedarf in der Entwurfslösung berücksichtigt werden sollten . Daher sollte jede Entwurfslösung von den folgenden Positionen aus überprüft werden.

1. Liste der Kundenanforderungen (die als Teil der Entwurfslösung implementiert werden).
2. Liste der Definitionen und Abkürzungen.
3. Die Liste der normativen Dokumente, die den automatisierten Prozess regeln.
4. (use case), :
   
   
   
   
   • ( , BPMN – , : , ) ;
   • ;
   • ( ) — ;
   • ( , ).
5. :
   
   
   
   
   • , ;
   • (UI) ( , , ); 
   • () .
6. :
   
   
   
   
   • API;
   • () «» ( );
   • () «» .
   
   
   , « » ( 2011 ., 1). - , ().
7. :
   
   
   
   
   • , () , ;
   • , () .
8. () , , . ( ) . ( ), , () , . «» .

Ich wiederhole - dies ist keine feste Struktur für eine Entwurfslösung, sondern eine formale Liste von Fragen ( Checkliste)), deren Antworten gegebenenfalls in der Entwurfslösung in der einen oder anderen Form wiedergegeben werden sollten. Wie die Praxis zeigt, ist es besser, wenn Sie dies in der Entwurfslösung explizit angeben, wenn keine Entwicklung in Bezug auf eines der oben beschriebenen Elemente erwartet wird. Oder fast explizit (erschrecken Sie den Kunden nicht). Das Hauptkriterium ist eine eindeutige Interpretation. Es ist wichtig, es nicht zu übertreiben, damit anstelle der Lösung der angegebenen Anforderung nicht fünf neue aufgrund ihrer Genehmigung geboren werden. Beispielsweise bedeutet der Ausdruck "Referenz von Objekttypen sollte nur tatsächliche Werte enthalten" und der Ausdruck "Die Referenz von Typen bietet keine Möglichkeit, den Änderungsverlauf zu speichern" dasselbe, aber der zweite Ausdruck führt höchstwahrscheinlich dazu, dass Sie Versionsmechanismen beschreiben und implementieren müssen genau dieses Handbuch.Bei der Gestaltung von Entwurfsentscheidungen ist es wichtig zu verstehen, dass der Zweck darin besteht, die Regeln festzulegen, nach denen Sie garantiert die mit diesen Entscheidungen verbundenen Anforderungen übergeben.

, , , .

Ein Großteil (wenn nicht der gesamte) des Projekts hängt davon ab, wie sich die Vertreter des Kunden das Endergebnis vorstellen. Daher ist das Entwerfen von Benutzeroberflächenlayouts bereits in der Anfangsphase der Schlüssel zum Erfolg des Projekts. Klären und spezifizieren Sie die Anforderungen des Kunden anhand einer externen Beschreibung des Softwareprodukts, das er versteht. Der Dialog mit den Vertretern des Kunden, der auf der Erörterung der Bildschirmlayouts beruhte, erwies sich als viel effektiver als der Dialog über die Erörterung der Eingabe- und Ausgabedatenformate und ihrer Transformationsalgorithmen (die Hauptabschnitte des IPR, die gemäß GOST erstellt wurden).



Das Ausarbeiten aller Elemente der Benutzeroberfläche im Rahmen von Entwurfszuweisungen bietet neben der Transparenz des Verständnisses der Implementierungsgrenzen auch eine Lösung für eine Reihe von Problemen:

1. . , , UI, , .
   
   
   
   
   
   : . . ISBN: 978-5-91180-090-1
2. UX- . , , ( ).
3. «» . UI , , – , ( « » ).
4. , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».

Quelle



Ich möchte ein paar Worte zu den Prinzipien des Entwurfs von Benutzeroberflächen für automatisierte Steuerungssysteme sagen. Trotz des Lawinenwachstums bei der Verwendung mobiler Geräte stehen Desktop-Computer und Laptops weiterhin nicht im Wettbewerb um automatisierte Steuerungssysteme, die in Regierungsbehörden eingesetzt werden (sowie zur Lösung von Programmier- und Systemverwaltungsproblemen). Derzeit sind verschiedene Tools für das Prototyping von Schnittstellen erschienen . Wenn Sie jedoch die Besonderheiten der Verwendung von Figma oder Axure im Interesse mobiler Geräte erläutern , verlieren Sie 10% der primitiven Möglichkeiten, mit denen Sie 90% der Benutzeroberflächen entwerfen können.ACS .



Nach meiner Erfahrung müssen Sie beim Entwerfen von Benutzeroberflächen einige einfache Regeln befolgen, um Softwareentwicklungsprobleme erheblich zu reduzieren.



Zunächst müssen Sie sich für ein allgemeines Navigationsschema entscheiden, an das Sie wie bei einem Weihnachtsbaum immer mehr neue Oberflächenelemente problemlos hängen können. In dieser Hinsicht hat sich für automatisierte Steuerungssysteme in meiner Praxis das effektivste Schema gezeigt, das in verschiedenen IDEs weit verbreitet ist . 



Ich werde hier kein Beispiel für die IntelliJ IDEA- oder PhpStorm- Schnittstelle gebenIch werde jedoch versuchen, die Hauptkomponenten einer solchen Benutzeroberfläche aus Sicht eines Analytikers eines automatisierten Steuerungssystems in Bestandteile zu zerlegen.



Die nach diesem Schema erstellte Schnittstelle enthält links ein zusammenklappbares vertikales Bedienfeld, das die Navigation im gesamten System ermöglicht. Das Vorhandensein eines vertikalen Bedienfelds mit Abschnitten, die hierarchische Menüs enthalten, stellt die Implementierung der Regel „ Drei Klicks “ sicher .





Jede der Menüoptionen der Hauptnavigationsleiste bietet Zugriff auf Formularlisten von Objekten. Listen von Objekten (Katalogen) und Formularen (Karten), in denen diese Objekte angezeigt werden, machen den Löwenanteil der Benutzeroberfläche aus. Die Vereinheitlichung dieser beiden Arten von Formularen im Rahmen des Projekts und die Bildung einer Navigationsstruktur auf ihrer Grundlage kann die Anzahl der Benutzeranforderungen, die mit Mängeln in der Benutzerdokumentation verbunden sind, erheblich reduzieren.



Im Rahmen der Beschreibung eines Listenformulars muss das Design Folgendes bestimmen:

• Liste der angezeigten Attributfelder;
• Anforderungen für Listenansichtsmodi (Standardanzeige, Gruppierung, Sortierung);
• Anforderungen an das dem Listenelement zugeordnete Unterformular (Schnellansichtskarte (Tabelle));
• Anforderungen an das Filterfeld (Auswahl von Datensätzen gemäß einer bestimmten Liste von Attributen);
• Beschreibung von Gruppenoperationen (gleichzeitige Aktionen für mehrere Listenelemente, z. B. Vergleichen von Listenelementen, Ändern von Attributen für mehrere Listenelemente, Ändern von Zugriffsrechten für mehrere Listenelemente);
• Beschreibung der Formulare (Panels) der statistischen Betriebsberichte (Überwachung) auf der Grundlage der Ergebnisse der Listenauswahl;
• eine Beschreibung der Anforderungen an Druckberichte und einen Algorithmus für deren Erstellung;
• Anforderungen zur Benachrichtigung von Benutzern (externen Systemen), wenn sich Objekte ändern.

Beim Entwerfen von Listenformularen haben die folgenden Regeln gut funktioniert:

1. — , «» , .   (ribbon). 
2. , , :
   
   
   • — , CRUD: , , , ;
   • ( , );
   • ;
   • ( , , ).
   
   
   
3. ( .. ) . , . .

  :

•   ;
•   , (CRUD, , ..) ;
• /;
• Liste möglicher Informationsmeldungen;
• Möglichkeiten zum Anzeigen des Verlaufs von Objektänderungen.

Ein paar Worte zum Toolkit. Aufgrund von Versuch und Irrtum bei der Durchführung verschiedener Projekte im Rahmen der Regierungsverordnung haben sich die folgenden drei Ansätze für das Schnittstellendesign als am effektivsten erwiesen.

1. Falls während der Entwicklung Änderungen an vorhandenen Schnittstellen erforderlich sind, sollten Sie das Rad nicht neu erfinden. Hier zeigte sich Paint.NET am besten (mit dessen Hilfe übrigens Bilder für diesen Artikel erstellt wurden). Es ist nicht sinnvoll, die Formulare erneut zu zeichnen. Es ist einfacher, den fertigen Screenshot zu ändern.
2. , — « »,   MS Visio . , , , , MS Visio, , , Windows. 
3. , -  , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».

Immer wieder gab ich fortgeschrittenen Entwicklern all diese Argumente, weit entfernt von den Problemen des Kunden. Ich sah ihre verblassenden Augen und hörte ihrer fachmännischen Einschätzung der Elend und Überlastung der vorgeschlagenen Benutzeroberfläche zu. Nach der Analyse der Erfahrungen mehrerer Projekte stellte ich jedoch im Laufe der Zeit ein erstaunliches Muster fest: Wenn ein Programmierer die Rückständigkeit und Komplexität der entwickelten Benutzeroberflächen eifrig kritisiert, ist dies ein sicheres Zeichen dafür, dass der Kunde eine solche Oberfläche mit einem Knall akzeptiert.

Gerüste und Schalungen

Normalerweise denken die Leute viel. Das Problem ist jedoch, dass sie über Probleme nachdenken und nicht über Lösungen für diese Probleme.



David Allen

Beim Bau von Häusern werden viele Hilfsstrukturen verwendet, die nach Abschluss des Baus völlig unnötig sind. Dies sind Gerüste und Schalungen . Bemerkenswerterweise versuchen auch Laien nicht, die Notwendigkeit des Kaufs und der Aufrechterhaltung dieser Strukturen zu bestreiten. In der IT-Branche hingegen sieht man häufig einen "erfahrenen" Analysten, der Schwierigkeiten hat, sofort eine Projektdokumentation zu erstellen, die alle Anforderungen erfüllt.



Meiner Meinung nach ist die erstellte Konstruktionsdokumentation jedoch ohne vorbeugende Registrierung und Genehmigung von Konstruktionslösungen nur für den formellen Vertragsschluss geeignet und schadet dem Betrieb in Zukunft mehr als es hilft. Die oben beschriebenen Entwurfslösungen und Prototypen sind jedoch nicht die einzigen "Hilfsstrukturen" in der analytischen Arbeit.



Quelle



Auf den ersten Blick scheint alles von der Erfahrung des Analytikers abzuhängen, und es ist unmöglich, die Verwendung dieser Hilfswerke zu regulieren. Wie kann man beispielsweise die Arbeit eines Analysten berücksichtigen und regulieren, der den ganzen Tag einen Kunden besucht und am nächsten Tag drei Gigabyte aller Arten von Dokumenten mitgebracht hat? Oder dass der Analyst eine Woche damit verbracht hat, diese Dokumente zu studieren? Ist das gut oder schlecht? Und Sie können diese Frage wirklich nicht beantworten, wenn Sie die Ergebnisse nicht kennen, die angesichts der Projektumsetzung sinnvoll sind.



Aus diesem Grund wurde im Rahmen unseres Projekts eine Klassifizierung der durchgeführten analytischen Arbeiten anhand der erzielten Ergebnisse durchgeführt. Neben der DesignlösungBei den meisten Softwareprojekten, an denen ich teilnehmen musste, musste der Analyst Analysematerialien der folgenden Typen entwickeln.

• Dokumentenanalyse - Ein Bericht, der auf den Ergebnissen der Analyse der behördlichen Dokumente oder der Projektdokumentation des Kunden basiert.
• Analytische Überprüfung - Ein Bericht über die Ergebnisse der Analyse von Lösungen für das aufgetretene Problem (in der Regel eine vergleichende Analyse neuer Technologien oder Markttrends).
• Informationsumfrage - ein Bericht über die Ergebnisse einer Studie über die bestehenden Geschäftsprozesse des Kunden (Bildung des Ist-Modells - " Wie es ist ").
• — ,   (use case).  legacy-.  
• — , ( ).  
• — , .

Der zweite Schritt in Richtung eines vorhersehbaren Entwurfs bestand darin, spezifische Anforderungen für die beabsichtigte analytische Arbeit zu definieren. Basierend auf diesen Anforderungen wurde für jede Art von zu entwickelndem Analysematerial eine JIRA-Problembeschreibungsvorlage definiert.





Die Aufgabenstellung für die Entwicklung von Analysematerialien beinhaltet eine kurze Beschreibung der erforderlichen Ergebnisse und keine Beschreibung der Analyseprozesse. So wird beispielsweise empfohlen, Ausdrücke wie "Domainanalyse durchführen ..." oder "Dokument studieren" zu vermeiden.

Ein Plan für den Maestro 

Alles sollte so einfach wie möglich angegeben werden, aber nicht einfacher.



Albert Einstein

Wenn es um die Planung von Analyse- und Programmierarbeiten geht, wird häufig kontrovers darüber diskutiert, wie der Zeitpunkt der Ergebnisse in diesem Fall geschätzt werden kann. Die obige Analyse dieser kreativen Aktivität lässt jedoch die Annahme zu, dass dies im Rahmen eines Softwareprojekts noch möglich ist. Der erste Schritt dazu besteht darin, die Systemkonstruktionsarbeiten in Teile zu zerlegen, die mindestens einmal pro Woche überprüft werden können. Es muss versucht werden, sicherzustellen, dass die Arbeitskosten des Analytikers für die Bildung einer Entwurfslösung 5 Arbeitstage nicht überschreiten (in Bezug auf das Volumen sollte eine solche Entwurfslösung ungefähr 20 bis 30 Seiten umfassen - gemäß GOST R ISO / IEC 15910-2002). Dementsprechend sollte ein Programmierer nach denselben Standards maximal 3 Stunden benötigen, um dieselbe Entwurfslösung zu überprüfen. 



Es ist wichtig zu verstehen, dass es nicht erforderlich ist, ein technisches Projekt aus einer Entwurfslösung zu erstellen . Die Entwurfslösung sollte nur eine kleine Gruppe miteinander verbundener Anforderungen abdecken, deren Ergebnis dem Kunden präsentiert werden kann.



Es ist auch wichtig zu vermeiden, in die Falle zu tappen, vor der Mary und Tom Poppendieck bei der Gestaltung einer Entwurfsentscheidung warnen., nämlich nicht als Geisel des Mythos zu werden, dass eine im Voraus erstellte detaillierte Spezifikation garantiert Verluste reduziert. In der Regel versucht der Kunde bei der Vereinbarung einer Entwurfslösung, alles, woran er sich erinnern kann, in dieses Dokument zu packen. Wenn Sie sich darauf einigen, ist es daher wichtig, das erforderliche Minimum sicherzustellen, um den erfolgreichen Abschluss der Vorversuche zu gewährleisten. Gleichzeitig ist der Schlüssel zum Erfolg nicht nur eine Kombination aus Qualität, Timing und Kosten, sondern auch die Zufriedenheit der Projektteilnehmer mit den Ergebnissen.



Um die Fristen für die Erledigung der zu analysierenden Aufgaben zu erhalten, reicht in der Regel eine Expertenbewertung des Auftragnehmers selbst aus. Bei Streitigkeiten kann jedoch ein pragmatischer Ansatz angewendet werden.... Um die Objektivität der Bewertung der Komplexität der zu analysierenden Aufgaben zu erhöhen, kann ein Online-Rechner verwendet werden , mit dem Sie die Arbeitskosten für die Durchführung von Analysearbeiten planen und schätzen können. Mit diesem Tool können Sie eine Liste der geplanten Arbeiten erstellen und deren Wortlaut abhängig von den Besonderheiten des Projekts präzisieren. Für jede der geplanten Arbeiten wird die minimale, maximale und wahrscheinlichste Schätzung der Arbeitskosten berücksichtigt. Als Ergebnis der Berechnung wird die erwartete Komplexität der Aufgabe gebildet und die optimale Zeitreserve berechnet, die für die Versicherung übrig bleiben muss. Die generierte Beschreibung zum Einstellen des Problems für die Analyse kann direkt in das Feld JIRA-Problembeschreibung kopiert werden.



Zusätzlich zu den allgemeinen Attributen, die im Artikel " JIRA: Projektgrenzen" beschrieben sind", Für jedes Problem vom Typ" Analyse "in JIRA wurde der folgende Satz zusätzlicher (benutzerdefinierter) Attribute empirisch bestimmt.





Lassen Sie uns unter Berücksichtigung des oben Gesagten die zuvor angegebene Abfolge von Aktionen des Analysten zur Implementierung von Aufgaben vom Typ "Analyse" im Interesse der Softwareentwicklung klären .



1. Falls erforderlich, sollte der verantwortliche Analyst Aufgaben in JIRA für die Durchführung von Informationsumfragen mit Kundenvertretern planen (diese Aufgaben sind mit den entsprechenden Anforderungen verknüpft).



Es ist ratsam, vor dem Meeting in erster Näherung Modelle der Benutzeroberfläche zu erstellen , die mit dem Kunden besprochen werden können. Bei der Durchführung einer Informationsumfrage ist es notwendig, den Hauptgeschäftsprozess aus seiner Sicht (User Story - User Story) mit dem Kunden zu besprechen), alternative Wege, auf denen der Kunde das Endergebnis sieht. 



Ich war oft der Meinung, dass die Grundlage einer Informationsumfrage die Befragung eines kompetenten Mitarbeiters ist, der ausführlich über die Merkmale des automatisierten Prozesses informiert. Was für die Entwicklung im Interesse eines gewerblichen Kunden gut ist, kann jedoch die unerwartetsten Konsequenzen für eine Regierung haben. Ich bin wiederholt auf eine Situation gestoßen, in der sich herausstellte, dass die Beschreibung des Prozesses, die auf der Grundlage der Geschichten von grauhaarigen Veteranen erstellt wurde, den wichtigsten Anforderungen der aktuellen Regulierungsdokumente widerspricht. Und dies wurde nicht durch die Tatsache erklärt, dass der Analytiker etwas missverstanden hatte, sondern durch die Tatsache, dass der Veteran "dies sein ganzes Leben lang getan hat".



Vor dem Treffen mit Fachexperten ist es daher erforderlich, die Regulierungsdokumente unter dem Gesichtspunkt der Regulierung des Prozesses zu analysieren, dessen Automatisierung erwartet wird. Gleichzeitig ist es wichtig zu verstehen, dass Regulierungsdokumente auch nicht die ultimative Wahrheit sind. In einer unparteiischen Analyse enthalten Regulierungsdokumente häufig immer Unklarheiten und Widersprüche (die Ausnahme sind in der Regel Dokumente, die „in Blut geschrieben“ sind). Hier sind einige der häufigsten Meinungsverschiedenheiten, auf die Sie achten sollten:

• Verletzung der Grundprinzipien der Klassifizierung , beispielsweise wenn verschiedene Zeichen innerhalb derselben Gruppe gemischt werden (rot, grün, warm);
• Erstellung von Berichtsdokumenten auf der Grundlage von Attributen, die nicht vorgesehen sind;
• ;
• - ;
• — - , .

Die Lösung dieser regulatorischen Konflikte ist eines der Hauptprobleme beim Treffen mit Kundenvertretern. Um diese Entscheidung als Ergebnis der Informationsumfrage aufzuzeichnen, muss ein Protokoll mit Angabe der Teilnehmer, des Ortes und der Zeit erstellt werden. Das Protokoll wird dem Kunden zur Klärung vorgelegt (E-Mail ist der entsprechenden Aufgabe beigefügt). Danach kann die Aufgabe für die Informationsumfrage in den Status "erledigt" versetzt werden. Diese JIRA-Aufgabe wird in den Status "geschlossen" versetzt, nachdem der Kunde eine Bestätigung über die Protokollgenehmigung erhalten hat.



2.  Basierend auf den festgelegten Anforderungen und den Ergebnissen von Informationsumfragen wird eine Entwurfslösung gebildet. Der verantwortliche Analyst muss dies mit dem Projektmanager und den Programmierern koordinieren (für jede von ihnen werden entsprechende Unteraufgaben erstellt). Wenn die Entwurfslösung während des Arbeitstages keine interne Genehmigung bestanden hat, wird die Aufgabe in den Status "Ausstehend" versetzt (ein Signal an den Projektmanager). Nach bestandener interner Genehmigung wird die Entwurfslösung zur Überprüfung an den Kunden gesendet (ggf. Genehmigung). Alle Einreichungsdetails werden in den Kommentaren zur Aufgabe aufgezeichnet. Während sich die Entwurfslösung auf Kundenseite befindet, wird die Aufgabe in den Status "Ausstehend" versetzt.



3.Wenn die Entwurfslösung vereinbart ist (oder wenn klar ist, dass sich die Genehmigung verzögert und die Fristen ablaufen), formuliert der verantwortliche Analyst auf seiner Grundlage Aufgaben für Entwicklung, Test und Dokumentation. In diesem Fall ist eine vorläufige Bewertung der Arbeitskosten für die Implementierung der Entwurfslösung erforderlich (als Summe der Arbeitskosten der mit dieser Entwurfslösung verbundenen Entwicklungsaufgaben). Basierend auf dieser Einschätzung ist es notwendig, den Zeitpunkt der Umsetzung der damit verbundenen Anforderungen zu klären.



4.  Nach Vereinbarung mit dem Kunden (ein Schreiben, das diese Tatsache bestätigt, wird in JIRA gespeichert) kann die Aufgabe der Vorbereitung einer Entwurfslösung in den Status "abgeschlossen" versetzt werden.

Fortsetzung folgt 

Derzeit wird das Software-Design für Regierungskunden am häufigsten gemäß den Anforderungen der GOST 34-Serie organisiert. Gleichzeitig „vergessen“ die meisten Kundenvertreter häufig, dass der Kunde zusätzlich zu der Dokumentation, die zum Testen der entwickelten Software bereitgestellt wird, im Rahmen der Genehmigung des Entwurfs und der technischen Projekte Konstruktionslösungen genehmigen muss, um die genaue Übereinstimmung der endgültigen Konstruktionsdokumentation mit diesem GOST zu befürworten. Und selbst wenn der Entwurf und die technischen Entwürfe vereinbart werden, ist es nicht ungewöhnlich, dass der Inhalt aus Gründen unrealistischer Fristen in voller Übereinstimmung mit dem Formular ignoriert wird. Dies gilt insbesondere für den Entwurf von Systemen, die nicht in direktem Zusammenhang mit der Lebenssicherheit stehen. Bei einem der Projekte "lehrte" ein stellvertretender Leiter das Leben.Er sprach darüber, wie er mit Wikipedia in einer Nacht ein 500-seitiges technisches Projekt erstellt hat. Ganz andere Menschen müssen in der Regel die Ergebnisse solcher „Designentscheidungen“ entwirren.



Unter diesen schwierigen Bedingungen können Sie mit den hier beschriebenen Ansätzen einen iterativen Aufbau der Softwarefunktionalität organisieren und gleichzeitig die Konsistenz der implementierten Lösungen beibehalten, die den Prinzipien der schlanken Softwareentwicklung entspricht . Zum anderen ermöglichen die Zieleinstellungen der beschriebenen Konstruktionslösungen die Erstellung von Dokumenten auf deren Basis, die den "Procrustean" -Anforderungen des Kunden entsprechen, zu minimalen Kosten.



Die Aufteilung der analytischen Arbeit in elementare Aktionen ermöglichte es auch, die Aktionen mehrerer Mitarbeiter mit unterschiedlichen Ausbildungsstufen zu koordinieren und so natürlich eine Kompetenzmatrix für Analysten unseres Projekts in LANIT zu bilden , die ich im nächsten Artikel erörtern möchte .



PSDieser Artikel ist Teil einer Reihe von Artikeln mit dem Titel " Regeln für die rechtzeitige Zubereitung köstlicher Software ", die ich als informelle Teamregelung für kundenspezifische Softwareprojekte im Interesse von Regierungsorganisationen verwende. Diese Reihe enthält die folgenden Artikel:

- " JIRA als Mittel gegen Schlaflosigkeit und Nervenzusammenbrüche " - die Hauptidee für die Organisation der Arbeit an einem Projekt mit JIRA;

- " JIRA: Projektgrenzen " - Grundbestimmungen für die Vereinheitlichung von Projekten und allgemeine Anforderungen für alle Arten von JIRA-Aufgaben;

- " JIRA: Anforderungsmanagement " - die Hauptmerkmale der Registrierung, Klärung und Kontrolle der Umsetzung der Kundenanforderungen innerhalb des vorgeschlagenen Modells;

- "Designlösungen: Befolgen Sie Ihre Regeln “- die Hauptaspekte des analytischen Arbeitsmanagements und der Bildung von Problemstellungen für Entwickler;

Im Rahmen dieses Zyklus wird Folgendes zur Veröffentlichung vorbereitet:

- " Matrix der Analystenkompetenzen " - Kriterien zur Bewertung des Reifegrades von Analysten für kundenspezifische Softwareprojekte;

- " Wo sich die Probleme im Projekt verstecken " - die Kriterien (Metriken) der betrieblichen Bewertung des aktuellen Status des Softwareprojekts.



Das Hauptlabel dieser Artikelserie ist die evolutionäre Verbesserung der Qualität von Softwareprojekten auf der Grundlage einer verbesserten Managementeffizienz. Mit anderen Worten, um angewandte Wachstumsmethoden auf den Ebenen des CMMI- Modells zu bilden.

Wenn Sie herausgefunden haben, wie Sie JIRA in Ihrem Softwareprojekt effizienter einsetzen können, teilen Sie Ihre Ideen mit. Vermeiden Sie nur bei der Beschreibung dieser Ideen die Ausdrücke "irgendwie" und "irgendwie". Ich lade alle zum Diskutieren ein. Ich warte auf Kommentare / Vorschläge / Zweifel / Wünsche in den Kommentaren.