Der Artikel beschreibt die Methode der Verwendung von 1C DSS (Application Design System) zur Bewertung der Dauer und Kosten von Projekten mit der COCOMOII-Methode.
Wie können Sie den Kunden rechtfertigen, dass Ihre Einschätzung des Projektzeitpunkts objektiv ist?
Wie kann die Marge eines Projekts vor dem Start im Vorverkauf gemessen werden?
Wie bewertet man die Handelsspanne zum Projektpreis, um Verluste zu vermeiden?
Wie kann der Bedarf an einem Projekt für Teammitglieder objektiv berechnet werden, die keine Entwickler sind (Business Analysten, Methodologen, technische Redakteure usw.), und wie kann das Ergebnis ihrer Arbeit auf einfachste und kostengünstigste Weise formalisiert werden?Inhaltsverzeichnis
- Eintrag.
- Das Hauptproblem bei der Verwendung von 1C DSS zur Zeit.
- Warum COCOMOII?
- Warum 1C DSS?
- COCOMOII kürzester Kurs
- Übergang von der Arbeitsbewertung von Entwicklern zur Arbeitsbewertung von Analysten und Methodologen
- Pseudocode
- 1 DSS und Pseudocode.
- Zusammenfassung
Eintrag
1C Application Design System wurde vor 6 Jahren auf den Markt gebracht und im Juli 2019 auf Version 2 erweitert. Basierend auf SADT-Technologien und einem kaskadierenden Entwicklungsmodell. Sie können jedoch die Scrum / Agile-Entwicklung in einzelnen Phasen leiten.
Konzipiert für komplexe, langwierige Projekte, die von einem Mehrkomponententeam mit häufigem Personalaustausch ausgeführt werden. Es umfasst die Funktionalität des Projektmanagements, die Beschreibung von Geschäftsprozessen, das Entwerfen der Architektur und der Funktionalität von Informationssystemen, die Softwareentwicklung und -pflege von IP sowie Autotests auf Basis von Vanessa / Gherkin.
Erstens ist es nützlich für Systemintegratoren und Franchisenehmer, und zweitens für alle Organisationen, die ihre eigenen IPs unter Einbeziehung externer Interpreten eigenständig entwickeln und pflegen.
Das Hauptproblem bei der Verwendung von 1C DSS zur Zeit
Das Hauptproblem bei der Verwendung von 1C DSSR (derzeit wird hauptsächlich Version 1 verwendet) ist die extrem falsche Verwendung von 1C DSS als Technologie.
1C DSS wird am häufigsten auf der Ebene der Funktionalität verwendet, die für Entwickler, bestenfalls für Architekten, bestimmt ist. Ihre Rolle besteht häufig in der Beschreibung und Entwicklung der "Funktionen" des Systems und in der Bildung von Aufgaben für Programmierer. Dies ist der Fehler bei der Arbeit mit DSS.
Bestehende Systeme auf dem Markt (JIRA usw.) leisten hervorragende Arbeit bei der Festlegung von Aufgaben für Programmierer und bei der Verarbeitung von Benutzertickets. Mit dieser Verwendung verfügen DSS-Entwickler über ein weiteres zeitaufwändiges bürokratisches Add-In, das Zeit für "reine" Codierung benötigt.
Der Entwickler ist verpflichtet, die Funktionalität des implementierten / finalisierten Systems zu beschreiben, um die Aufgabenstellung für Programmierer mit Verknüpfungen zu Metadatenobjekten zu gewährleisten ("Common Language" im Sinne von Eric Evans in seiner Arbeit "Object-Oriented Design (DDD). Strukturierung komplexer Softwaresysteme").
Gleichzeitig werden die Aufgaben der anderen Hälfte des Projektteams - Projektmanager, Business Analysts, Methodologen - fast vollständig ignoriert. Leider können wir sagen, dass sogar 1C selbst in Version 2.0 des DSS die Funktionalität für diese Kategorie von Teilnehmern stark reduziert hat und das DSS-Modell gegenüber Version 1.0 in Richtung Entwickler und Tester erheblich verändert hat (zum Beispiel: Anforderungen und Datenobjekte wurden explizit entfernt).
Dennoch ist das Problem der vollständigen und vollwertigen Nutzung von DSS akut. In diesem Artikel werden wir insbesondere untersuchen, wie die Technologie zur Schätzung der Bedingungen und Kosten von Projekten mit der COCOMOII-Methode in 1C DSS verwendet werden kann.
Jeder möchte wissen, wie lange ein Projekt abgeschlossen werden kann, über die der Kunde selbst nicht sagen kann, was er letztendlich möchte und inwieweit es sinnvoll ist, mit dem Kunden zu verhandeln?
Und wie kann man den Kunden davon überzeugen, dass der vorgeschlagene Zeit- und Kostenaufwand gerechtfertigt ist? Letzteres ist jedoch nicht schädlich für uns zu wissen.
Und vor allem: Wie lässt sich der Bedarf an einem Projekt für Teammitglieder, die keine Entwickler sind (Business Analysten, Methodologen, technische Redakteure usw.), objektiv berechnen, und wie lässt sich das Ergebnis ihrer Arbeit auf einfachste und kostengünstigste Weise formalisieren?
Warum COCOMOII?
Kunden in jeder Branche bevorzugen eine objektive, vernünftige und allgemein anerkannte Einschätzung der Kosten und des Zeitplans des Projekts. Sie möchten die Verbindung ihres Projekts mit der Erfahrung eines Systemintegrators in früheren Projekten sehen. Gleichzeitig hat ein seltener Kunde eine klare Vorstellung vom Endergebnis des Projekts, bei Projekten mit der Entwicklung eines konzeptionellen Modells jedoch definitiv nicht. Und der Systemintegrator hat nicht.
Wie sind Zeit und Kosten im Vorverkauf zu bewerten, wenn keine Informationen vorliegen? Und im Laufe des Projekts unter Berücksichtigung von Veränderungen (die Geißel aller Projekte)?
Mit der COCOMOII-Methode können Sie eine solche Bewertung unter Berücksichtigung der gesammelten Erfahrung des Systemintegrators vornehmen und auf einfachste Weise zeitnah im Verlauf des Projekts Preis- / Zeitspezifikationen vornehmen und diese für eine Einigung mit dem Kunden rechtfertigen.
Warum 1C DSS?
Die Sache ist, dass 1C DSS auf SADT und den "Common Language" -Technologien basiert (dies wird in meinem separaten Artikel ausführlicher beschrieben). Es ist SADT, das den Modellierungsprozess in den Entwicklungsprozess auf der Grundlage der "gemeinsamen Sprache" integriert. Eine "gemeinsame Sprache" ermöglicht es Ihnen, eine Basis für die Berechnung geschätzter Indikatoren für Begriffe zu haben.
COCOMOII kürzester Kurs
Die COCOMO-Methodik entstand 1963 als Reaktion auf die Notwendigkeit einer schnellen und unkomplizierten Bewertung der Komplexität und des zeitlichen Ablaufs der Softwareentwicklung in zukünftigen Projekten. Die Basis des COCOMO-Modells und seiner nächsten Stufe, COCOMOII, ist die Anzahl der Programmcodezeilen (KSLOC besteht aus tausend Zeilen logischen Codes, d. H. Codezeilen, die eine Operation ausdrücken). Diese Basis ist das Ergebnis eines jeden Softwareentwicklungsprojekts, sie ist eine Art Quintessenz des Projekts.
(Wir werden bedenken, dass COCOMO sich von COCOMOII dadurch unterscheidet, dass die skalaren Parameter der COCOMO-Formel durch die COCOMOII-Parametertabelle ersetzt werden, das Wesen der Methode jedoch gleich bleibt.)
Mit dem gesammelten Projektgepäck kann jeder Entwickler eine grundlegende Einschätzung des Rahmens für jedes nächste Projekt vornehmen. Dies ist natürlich eine sehr grobe Schätzung, aber im Vorverkauf ist eine solche Schätzung besser als nichts. Zur Verdeutlichung wird die KSLOC-Basis nach einer bestimmten Formel an Verfeinerungskoeffizienten angepasst. Wir geben die Formel nicht an, sie ist einfach und im Internet verfügbar. Unter dem Strich kann jeder Entwickler die Koeffizienten dieser Formel auf der Grundlage von Statistiken aus früheren Projekten entwickeln und mit den kanonischen Parametern der Formel vergleichen oder ... nicht nur seine eigene Formel vergleichen und verwenden.
Das Vorhandensein einer Formel mit Parametern gibt an, dass alle Projekte des Systemintegrators (oder alle internen Projekte der Organisation) gemäß all diesen Parametern codiert und klassifiziert werden sollten. Je mehr Projekte im Gepäck der Entwickler sind, desto mehr Projekte des gleichen Typs für ein neues Projekt, die geöffnet werden können, können zur Bewertung ausgewählt werden (Nicht-Kern-Projekte filtern), desto genauer ist die Bewertung.
Wenn Sie die für ein abgeschlossenes Projekt aufgewendete Zeit pro KSLOC-Einheit (Codezeile) kennen, können Sie den potenziellen Arbeitsaufwand eines zukünftigen Projekts bewerten. Wenn in den Parametern Daten zu den Qualifikationen (Noten) der angestellten Mitarbeiter gespeichert sind, können Sie eine Projektkostenschätzung erhalten.
Die Detaillierung der Projektparameter kann nach Ihrem Ermessen und Ihren Möglichkeiten erfolgen. Je detaillierter, desto genauer werden der Zeitpunkt und die Kosten des zukünftigen Projekts geschätzt.
Welches KSLOG wird im Vorverkauf mit einer ungenauen Beschreibung des Ergebnisses eingestellt? Nur empirisch aus der Projektdatenbank des Integrators (Ausführenden). In diesem Fall kann ein Satz von Projektparametern verwendet werden. Wenn eine genaue Beschreibung des gewünschten Ergebnisses des Projekts (Softwareprodukts) vorliegt, kann ein erweiterter Satz von Projektparametern verwendet werden.
Das ist der springende Punkt der COCOMO-Methode.
Übergang von der Arbeitsbewertung von Entwicklern zur Arbeitsbewertung von Analysten und Methodologen
Aufmerksame und erfahrene Leser werden ausrufen:
"Okay! Mit allen Vor- und Nachteilen der COCOMO-Methode sollen Softwareprojekte evaluiert werden. Die Arbeit von Entwicklern, Programmierern kann in bedingtem KSLOC digitalisiert werden. Aber was ist mit Analysten und Methodologen, Projektmanagern und Managern? Und was hat 1C DSS damit zu tun? “
Richtig!
Die Aufgabe besteht also darin, eine ähnliche Basis für die aufgelisteten Teammitglieder auszuwählen, mit der Sie die COCOMOII-Technik anwenden können. Hier geht er auf die Bühne.
Pseudocode
Eine Art der Ausgabeergebnisse aller komplexen Projekte für den Entwurf, die Erstellung und die Entwicklung von Informationssystemen sind Projektdokumente. Dies sind technische Aufgaben, Konzeptdokumente, Beschreibungen, Anweisungen, Register von Datenobjekten, Analystenlisten usw. Das Inhaltsverzeichnis dieser Dokumente, Inhaltstexte, Tabellen, Abbildungen, gesammelten Anforderungen, Listen sind Pseudocode.
Und es ist dieser Pseudocode, der die Ergebnisse der Arbeit der „Nicht-Programmierer“ des Projektteams misst - Analysten, Methodologen, technische Redakteure, Projektmanager, Architekten, Designer und ähnliche Teilnehmer.
Wenn das Projekt gemäß den Anforderungen von GOST eingereicht wird, wird die Struktur der Projektdokumente durch diese Standards definiert, ansonsten erfolgt die Erstellung nach Ermessen des Auftragnehmers oder gemäß den Anforderungen des Vertrags mit dem Kunden.
Ein interessanter Punkt ist, wenn das Projektteam und der Kunde sich dazu entschließen, mit der Zeit zu gehen und die Projektergebnisse ausschließlich mit papierloser Technologie zu erstellen. Wie wird 1C DSS damit verbunden sein?
Die Antwort - auf direkteste Weise - DSS und der Inhalt seiner Verzeichnisse, die vom Projekt ausgefüllt werden, sind ein strukturiertes Datenobjekt und das Ergebnis der Arbeit. Welches ist sehr bequem an den Kunden zu übertragen. Alle Dokumente, die während des Projekts erstellt wurden, werden an die DSS-Konfigurationsobjekte angehängt.
Vereinfachte Ausgabeprojektdokumente werden in die folgenden Gruppen von Pseudocode unterteilt:
- Die Struktur (Inhaltsverzeichnis) des Dokuments;
- Dokumententest;
- Dokumententabellenzeile (Tabelle);
- Zeichnen (Grafikobjekt).
Im einfachsten Fall ist für die COCOMO-Basis die Struktur der Ausgabedokumente ausreichend. Die Komplexität (Anzahl der Verschachtelungsebenen) und die Anzahl der Inhaltsverzeichniszeilen können als Grundlage für die Anwendung der Formeln der Methode zur Schätzung der Bedingungen und Kosten eines Projekts anhand ähnlicher Statistiken aus früheren Projekten und der Struktur der Teilnehmer in Projektteams (keine Programmierer) dienen. Natürlich erhöht die Einbeziehung aller Arten von Pseudocodes in die Basis die Genauigkeit der Schätzung.
Somit wird das KSLOC-Analog im Standard-COCOMO hier zum Inhaltsverzeichnis des Ausgabeprojektdokuments und / oder zur Textzeile dieses Dokuments (jede Zeile jeder Tabelle in diesem Dokument, jedes Grafikobjekt). Die Grundlage sollte keine Gestaltungselemente und das Layout des Dokuments enthalten.
1 DSS und Pseudocode
Es stellt sich die Frage, wie ein Pseudocode in 1C DSS platziert werden kann.
Dies kann über das Verzeichnis "Data Objects" erfolgen. Eine separate Gruppe "AUSGABEDOKUMENTE" wird erstellt, in der Untergruppen für jeden Dokumenttyp, dann eine weitere Untergruppe für jedes separate Dokument und in diesen Untergruppen als Elemente eines Verzeichnisses des Inhaltsverzeichnisses des Projektdokuments.
Wenn eine Entscheidung getroffen wird, Textinhalte, Tabellen, Grafikobjekte der ausgegebenen Projektdokumente in die COCOMOII-Basis aufzunehmen, sollte das Inhaltsverzeichnis des Projektdokuments auch in den Gruppen des Verzeichnisses "Datenobjekte" erfolgen und darin die Namen von Tabellen, Grafikobjekten und Absätzen von Text platziert werden.
Der Text des Projektdokuments selbst kann in Absätzen als Textfeld des Verzeichniselements "Datenobjekte" eingegeben werden.
Worauf sollte man bei der Beschreibung der Struktur von Ausgabeprojektdokumenten im Nachschlagewerk „Data Objects“ achten?
Es muss darauf geachtet werden, dass jedes Element des Verzeichnisses „Data Objects“ eine Verknüpfung zu einem Metadatenobjekt und / oder zu einem Datenobjekt (aus anderen Gruppen des Verzeichnisses „Data Objects“, die keine anderen Strukturen der Ausgabedokumente beschreiben, sondern andere Typen, die auf erstellt wurden) aufweisen kann Datenprojekt, zum Beispiel: Analystenlisten).
Ein solches Design ermöglicht die automatische Erstellung von Ausgabeprojektdokumenten direkt aus 1C DSS. Dies wird dazu beitragen, den Zeitaufwand für die Teamarbeit am Projekt erheblich zu reduzieren, insbesondere bei sich ständig ändernden Kundenanforderungen, Änderungen des Informationssystems, einschließlich andere Teams und Darsteller, wenn es erforderlich ist, die Ausgabedokumente erneut zu erstellen, gleichzeitig aber die Kohärenz der Objekte und ihrer Beschreibungen aufrechtzuerhalten.
Wenn Sie jedes Element oder jede Gruppe des Verzeichnisses "Datenobjekte" mit Anforderungen verknüpfen (sowohl vom Kunden als auch von Mitgliedern des Projektteams formuliert, detailliert in Metadaten), erhalten Sie schließlich eine End-to-End-Verknüpfung Anforderungen - Metadatenobjekte - Projektdokumente ausgeben. In DSS 2.0 entsprechen „Ideen“ den „Anforderungen“.
Mit der Ansammlung von Erfahrung bei der Implementierung von Projekten in 1C DSS kristallisiert sich eine solche Verzeichnisstruktur heraus, die bei allen ähnlichen Projekten gleich ist. Daher reicht es für ein neues Projekt aus, es einfach zu kopieren. Und für Projekte, deren Ausgabeergebnisse identisch sind, können Sie den Text (Tabelle) kopieren.
Zusammenfassung
Integratoren und Organisationen mit einer gut entwickelten Datenbank von Projekten, die die Materialien früherer Projekte geprüft haben, können eine objektive Einschätzung des Zeitplans und der Kosten geplanter und laufender Projekte erhalten.
Dies sollte A) das Verhandeln mit dem Kunden erheblich erleichtern. B) die Einschätzung des erwarteten Gewinns.