L'article traite de la méthode d'utilisation de 1C DSS (Application Design System) pour évaluer la durée et le coût des projets utilisant la méthode COCOMOII.
Comment justifier au client que votre appréciation du timing du projet est objective?
Comment mesurer la marge d'un projet avant son démarrage, au stade de la prévente?
Comment évaluer la fourchette de négociation au prix du projet afin d'éviter une perte?
Comment calculer objectivement le besoin d'un projet pour des membres de l'équipe qui ne sont pas développeurs (analystes commerciaux, méthodologues, rédacteurs techniques, etc.), comment formaliser le résultat de leur travail de la manière la plus simple et la plus abordable?Table des matières
- Entrée.
- Le principal problème de l'utilisation de 1C DSS à l'heure actuelle.
- Pourquoi COCOMOII?
- Pourquoi 1C DSS?
- Cours le plus court COCOMOII
- Transition de l'évaluation du travail des développeurs à l'évaluation du travail des analystes et méthodologistes
- Pseudocode
- 1 DSS et pseudo-code.
- Résumé
Entrée
1C Application Design System a été lancé sur le marché il y a 6 ans et en juillet 2019, il est passé à la version 2. Basé sur les technologies SADT et un modèle de développement en cascade. Cependant, il vous permet de diriger le développement Scrum / Agile à des étapes individuelles.
Conçu pour les projets complexes et longs exécutés par une équipe multi-composants avec un remplacement fréquent du personnel. Il comprend la fonctionnalité de gestion de projet, la description des processus commerciaux, la conception de l'architecture et de la fonctionnalité des systèmes d'information, le développement de logiciels et la maintenance de l'IP, ainsi que les tests automatiques basés sur Vanessa / Gherkin.
Premièrement, il est utile pour les intégrateurs de systèmes et les franchisés, et deuxièmement pour toutes les organisations qui réalisent le développement et la maintenance indépendants de leurs propres IP avec la participation d'intervenants externes.
Le principal problème de l'utilisation de 1C DSS à l'heure actuelle
Le principal problème de l'utilisation de 1C DSSR à l'heure actuelle (la version 1 est principalement utilisée) est l'utilisation extrêmement incorrecte de 1C DSS comme technologie.
1C DSS est le plus souvent utilisé au niveau des fonctionnalités destinées aux développeurs, au mieux aux architectes. Son rôle se résume souvent à la description et au développement des "Fonctions" du système et à la formation de tâches pour les programmeurs. C'est l'erreur de l'approche de travailler avec DSS.
Les systèmes existants sur le marché (JIRA, etc.) font un excellent travail de définition des tâches pour les programmeurs et de traitement des tickets utilisateur. Avec cette utilisation, les développeurs DSS ont encore un autre complément bureaucratique qui prend du temps, qui prend du temps à partir du codage "pur".
Le développeur devient obligé de décrire la fonctionnalité du système implémenté / finalisé afin d'assurer la définition de tâches pour les programmeurs avec des liens vers des objets de métadonnées («langage commun» en termes d'Eric Evans dans son travail «Object-Oriented Design (DDD). Structuration de systèmes logiciels complexes»).
Dans le même temps, les tâches de l'autre moitié de l'équipe de projet - chefs de projet, analystes commerciaux, méthodologistes sont presque complètement ignorées. Malheureusement, nous pouvons dire que même 1C lui-même dans la version 2.0 du DSS a considérablement réduit les fonctionnalités de cette catégorie de participants, modifiant considérablement le modèle DSS par rapport à la version 1.0 vers les développeurs et les testeurs (par exemple: les exigences et les objets de données ont été explicitement supprimés).
Néanmoins, la question de l'utilisation complète et à part entière du SSD est aiguë. Dans cet article, en particulier, nous examinerons comment la technologie d'estimation des termes et du coût des projets utilisant la méthode COCOMOII peut être utilisée dans le DSS 1C.
Tout le monde veut savoir combien de temps un projet peut être achevé, à propos duquel le client lui-même ne peut pas dire ce qu'il veut finalement, et dans quelle mesure est-il raisonnable de négocier avec le client?
Et comment convaincre le client que le temps et le coût proposés sont justifiés? Cependant, ce dernier n'est pas nuisible à connaître par nous-mêmes.
Et surtout, comment calculer objectivement le besoin d'un projet pour les membres de l'équipe qui ne sont pas développeurs (analystes commerciaux, méthodologistes, rédacteurs techniques, etc.), comment formaliser le résultat de leur travail de la manière la plus simple et la plus abordable?
Pourquoi COCOMOII?
Les clients de toute industrie préfèrent avoir une évaluation objective, raisonnable et généralement acceptée du coût et du calendrier du projet. Ils aimeraient voir le lien entre leur projet et l'expérience d'un intégrateur de systèmes dans des projets précédents. Dans le même temps, un client rare a une idée claire du résultat final du projet, mais dans les projets avec le développement d'un modèle conceptuel, ce n'est certainement pas le cas. Et l'intégrateur de système n'a pas.
Comment évaluer le temps et les coûts au stade de la prévente en l'absence d'informations? Et au cours du projet, en tenant compte des changements (le fléau de tous les projets)?
La méthode COCOMOII vous permet de faire une telle évaluation, en tenant compte de l'expérience accumulée de l'intégrateur de système, et de la manière la plus simple, tout en rapidement, au cours du projet, de faire des spécifications de prix / calendrier et de les justifier pour l'accord avec le client.
Pourquoi 1C DSS?
Le fait est que 1C DSS est basé sur SADT et les technologies de "langage commun" (cela est décrit plus en détail dans mon article séparé). C'est SADT qui intègre le processus de modélisation au processus de développement basé sur le «langage commun». Un «langage commun» vous permet d'avoir une base pour calculer des indicateurs de termes estimés.
Cours le plus court COCOMOII
La méthodologie COCOMO a vu le jour en 1963 en réponse à la nécessité d'une évaluation rapide et simple de la complexité et du calendrier de développement des logiciels dans les projets à venir. La base du modèle COCOMO et de sa prochaine étape, COCOMOII, est le nombre de lignes de code de programme (KSLOC est un millier de lignes de code logique, c'est-à-dire des lignes de code exprimant une opération). Cette base est le résultat de tout projet de développement logiciel, c'est une sorte de quintessence du projet.
(Nous garderons à l'esprit que COCOMO diffère de COCOMOII en ce que les paramètres scalaires de la formule COCOMO sont remplacés par la table des paramètres COCOMOII, mais l'essence de la méthode reste la même).
Ainsi, ayant le bagage accumulé des projets, tout développeur peut avoir une évaluation de base du cadre de chaque projet suivant. Bien sûr, il s'agit d'une estimation très approximative, mais au stade de la prévente, une telle estimation est meilleure que rien. Pour le clarifier, la base KSLOC est ajustée selon une certaine formule pour affiner les coefficients. Nous ne donnerons pas la formule, elle est simple et disponible sur Internet. L'essentiel est que chaque développeur puisse développer les coefficients de cette formule sur la base des statistiques des projets précédents et les comparer avec les paramètres canoniques de la formule, ou ... ne pas comparer et utiliser uniquement sa propre formule.
La présence d'une formule avec paramètres indique que tous les projets de l'intégrateur de système (ou tous les projets internes de l'organisation) doivent être codés et classés selon tous ces paramètres. Plus il y a de projets dans les bagages des développeurs, plus il est possible de sélectionner des projets du même type pour un nouveau projet pouvant être ouverts (filtrer les projets non essentiels), plus l'évaluation est précise.
Connaissant le temps passé sur un projet terminé par unité KSLOC (ligne de code), vous pouvez évaluer la pénibilité potentielle d'un futur projet. Si les paramètres stockent des données sur les qualifications (grades) des employés, vous pouvez obtenir une estimation des coûts du projet.
Le détail des paramètres du projet peut être fait à votre discrétion et selon vos capacités. Plus il y a de détails, plus le calendrier et le coût du futur projet sont estimés avec précision.
Quel KSLOG est réglé au stade de la prévente avec une description inexacte du résultat? Uniquement empirique à partir de la base de données des projets de l'intégrateur (exécuteur). Dans ce cas, un ensemble de paramètres de projet peut être utilisé. S'il existe une description précise du résultat souhaité du projet (produit logiciel), un ensemble étendu de paramètres de projet peut être utilisé.
C'est tout l'intérêt de la méthode COCOMO.
Transition de l'évaluation du travail des développeurs à l'évaluation du travail des analystes et méthodologistes
Les lecteurs attentifs et expérimentés s'exclameront:
«Eh bien! Avec tous les avantages et les inconvénients de la méthode COCOMO, elle est conçue pour évaluer des projets logiciels. Le travail des développeurs, des programmeurs peut être numérisé en KSLOC conditionnel. Mais qu'en est-il des analystes et des méthodologistes, des chefs de projet et des gestionnaires? Et qu'est-ce que 1C DSS a à voir avec ça? "
Ok!
Ainsi, la tâche consiste à sélectionner une base similaire pour les membres de l'équipe répertoriés qui vous permettra d'utiliser la technique COCOMOII. Ici, il monte sur scène.
Pseudo code
Un des types de résultats de sortie de tous les projets complexes pour la conception, la création et le développement de systèmes d'information sont les documents de projet. Ce sont des tâches techniques, des documents conceptuels, des descriptions, des instructions, des registres d'objets de données, des listes d'analystes, etc. La table des matières de ces documents, les textes de contenu, les tableaux, les figures, les exigences collectées, les listes sont des pseudocodes.
Et c'est ce pseudo-code qui est une mesure des résultats du travail des membres "non programmeurs" de l'équipe de projet - analystes, méthodologues, rédacteurs techniques, gestion de projet, architecte, concepteurs et participants similaires.
Si le projet est soumis conformément aux exigences GOST, la structure des documents de projet est définie par ces normes, sinon, il est créé à la discrétion de l'entrepreneur ou selon les exigences du contrat avec le client.
Un point intéressant est que si l'équipe de projet et le client décident de suivre le temps et établissent les résultats du projet exclusivement en utilisant la technologie sans papier, comment 1C DSS sera-t-il connecté à cela?
La réponse - de la manière la plus directe - DSS et le contenu de ses répertoires renseignés par le projet seront un objet de données structuré et le résultat du travail. Ce qui est très pratique à transférer au client. Tous les documents créés pendant le projet seront des documents joints aux objets de configuration DSS.
Les documents de projet de sortie simplifiés sont divisés en groupes de pseudo-code suivants:
- La structure (table des matières) du document;
- Test de document;
- Document table row (table);
- Dessin (objet graphique).
Dans les cas les plus simples, pour la base COCOMO, la structure des documents de sortie est suffisante. Sa complexité (le nombre de niveaux d'imbrication), le nombre de lignes de table des matières peuvent servir de base pour appliquer les formules de la méthode d'estimation des termes et du coût d'un projet à travers des statistiques similaires de projets précédents et la structure des participants dans les équipes de projet (pas les programmeurs). Bien sûr, l'inclusion de tous les types de pseudo-code dans la base augmentera la précision de l'estimation.
Ainsi, l'analogue KSLOC dans le COCOMO standard devient ici la table des matières du document de projet de sortie et / ou la ligne de texte de ce document (chaque ligne de chaque table de ce document, chaque objet graphique). La base ne doit pas inclure les éléments de conception et la mise en page du document.
1 DSS et pseudo-code
La question se pose de savoir comment placer un pseudo-code dans 1C DSS.
Cela peut être fait via le répertoire "Data Objects". Un groupe distinct «DOCUMENTS DE SORTIE» est créé, contenant des sous-groupes pour chaque type de document, puis un autre sous-groupe pour chaque document distinct, et à l'intérieur de ces sous-groupes en tant qu'éléments d'un répertoire de la table des matières du document de projet.
Si la décision est prise d'inclure du contenu textuel, des tableaux, des objets graphiques des documents de projet en sortie dans la base COCOMOII, la table des matières du document de projet doit également être effectuée dans les groupes du répertoire "Data Objects", et à l'intérieur de ceux-ci doivent être placés les noms des tableaux, des objets graphiques et des paragraphes de texte.
Le texte du document de projet lui-même peut être saisi dans les paragraphes comme champ de texte de l'élément de répertoire "Data Objects".
Que faut-il s'efforcer de décrire la structure des documents de projet de sortie dans le livre de référence «Data Objects»?
Il est nécessaire de veiller à ce que chaque élément du répertoire «Data Objects» puisse avoir un lien vers un objet de métadonnées et / ou vers un objet de données (provenant d'autres groupes du répertoire «Data Objects» qui ne décrivent pas d'autres structures des documents de sortie, mais d'autres types créés sur projet de données, par exemple: listes d'analystes).
Une telle conception permettra de créer automatiquement des documents de projet de sortie, directement à partir de 1C DSS. Cela contribuera à réduire considérablement le temps consacré au travail d'équipe sur le projet, en particulier dans des conditions d'exigences client en constante évolution, de modifications du système d'information, notamment d'autres équipes et interprètes lorsqu'il est nécessaire de recréer à nouveau les documents de sortie, mais en même temps de maintenir la cohérence des objets et de leurs descriptions.
Lorsque vous liez chaque élément ou groupe du répertoire «Data Objects» aux exigences (formulées à la fois par le client et les membres de l'équipe de projet, détaillées aux métadonnées), vous pouvez enfin obtenir un lien de bout en bout Exigences - Objets de métadonnées - Documents de projet de sortie. Dans DSS 2.0, les «idées» sont l'équivalent des «exigences».
Avec l'accumulation d'expérience dans la mise en œuvre de projets dans 1C DSS, une telle structure de répertoires se cristallisera et sera la même sur tous les projets similaires. Par conséquent, pour un nouveau projet, il suffit de le copier simplement. Et pour des projets identiques dans les résultats de sortie, vous pouvez copier le texte (tableau).
Résumé
Les intégrateurs et les organisations disposant d'une base de données de projets bien développée, ayant audité le matériel des projets précédents, peuvent obtenir à leur disposition une évaluation objective du calendrier et du coût des projets planifiés et en cours.
Cela devrait grandement faciliter A) la négociation avec le client B) l'évaluation des bénéfices attendus.