Une source
Cadre de recherche
, .
.
Puisqu'à l'heure actuelle, il existe plus de deux douzaines de types de postes «d'analystes» sur le marché du travail informatique , je ferai immédiatement une réservation que je parlerai de travail analytique sur des projets d'état pour créer des logiciels personnalisés. Comme le montre mon expérience, un analyste métier qui ne comprend pas les mécanismes d'automatisation des processus métier ne peut pas préparer un énoncé adéquat du problème. Tout comme un analyste de systèmes qui ne comprend pas les objectifs commerciaux de l'automatisation ne peut pas être adéquat. Par conséquent, de mon point de vue, un analyste travaillant sur des projets logiciels personnalisés doit combiner les compétences d'un analyste d'affaires, d'un analyste de systèmes et d'un concepteur UX. De plus, en règle générale, l'analyste principal d'un tel projet doit remplir les fonctions de Product Owner.(si le client vous le permet). Il s'agit de l'organisation des activités de ces «soldats universels» qui sera discutée plus loin.
Lors de la création de logiciels dans l'intérêt des organisations gouvernementales, l'activité principale des analystes est liée à la résolution de problèmes tels que:
- gestion des exigences;
- la formation d'énoncés de tâches pour les programmeurs, la planification de la mise en œuvre et le contrôle de la mise en œuvre de ces tâches;
- préparation de la documentation du projet.
Les détails de la gestion des exigences des logiciels personnalisés, la procédure pour leur amélioration initiale et le rôle clé de l'analyste responsable de leur mise en œuvre ont été discutés en détail dans l' article précédent .
Cependant, la spécificité des souhaits du client ne garantit pas qu'il aimera le résultat final. Au cours de mes projets , le schéma suivant a été "identifié": tous les commentaires fonctionnels du client, enregistrés lors de tous types de tests (à ne pas confondre avec les erreurs identifiées!), Liés à des exigences pour lesquelles la solution de conception n'a pas été convenue de manière proactive avec le client. A cet égard, les statistiques fournies par Natalya Rukol sont indicatives.lorsque, lors de l'analyse des résultats de l'un des projets, il s'est avéré que près de 70% des «erreurs» révélées au stade de la livraison étaient dues à une méconnaissance des exigences initiales de la part des développeurs.
Il semblerait qu'après que les exigences pour le produit logiciel aient été clarifiées, il est nécessaire de former un ensemble de documentation de conception conformément à GOST RD 50-34.698 , de le coordonner avec le client, puis de développer un logiciel en pleine conformité avec le projet approuvé. C'est souvent à propos de cette séquence d'actions que l'on entend les excellents élèves d'hier (les élèves de niveau C, en règle générale, ne savent pas du tout l'existence de tels documents) et de nombreux hauts fonctionnaires «expérimentés» qui n'ont jamais été personnellement responsables du résultat final du développement de logiciels.
Comme mon expérience le suggère, la formation de la documentation du projet n'est que la dernière partie du travail de l'analyste. Par analogie, on peut citer un travail de recherche, à la suite duquel un rapport doit être généré conformément à GOST 7.32 ou une thèse doit être rédigée. Cependant, ces documents ne sont qu'une forme de formalisation des résultats scientifiques obtenus. Réalisation d'expériences infructueuses, traitement statistique du «bruit blanc», recherche de grains de l'information requise dans des tonnes de vieux papiers pseudoscientifiques - toutes ces parties intégrantes du travail scientifique restent toujours dans les coulisses. Il en va de même pour la documentation de projet. D'une part, il fait partie intégrante du produit logiciel... En revanche, il ne contient que les résultats finaux du travail analytique.
Source
À mon avis, cet aspect est l'une des nombreuses raisons pour lesquelles, selon les exigences des contrats gouvernementaux pour les projets logiciels, les clients «stupides» prévoient de s'entendre sur la documentation de conception au stade des tests préliminaires, c'est-à -dire au moment de l'achèvement effectif du développement logiciel.
C'est pourquoi, dans nos projets logiciels dans JIRA, deux types de tâches différents sont formés, ce qui nous permet de séparer le travail analytique directement de l'activité de préparation de la documentation du projet. Et ce qui est gratifiant, je n'étais pas le seul à arriver à de telles conclusions... Alors, que doivent faire exactement les analystes sur un projet logiciel après avoir spécifié les exigences et avant de rédiger la documentation du projet?
Solutions de conception VS documentation de conception?
Comme c'est beau sur le papier,
comme il est facile de suivre les mots.
Comme il est facile de vous rendre infaillible.
B. Grebenshchikov
Malgré le fait que la définition du concept de «solution de conception» soit donnée dans GOST 34.003-90 , dans mon cas, le sens de ce concept a été «découvert» au cours de tentatives douloureuses et infructueuses pour se mettre d'accord avec les représentants des clients sur plusieurs exigences interdépendantes mais ambiguës, lorsque les clients ont simplement ignoré la proposition nous décrivons la fixation des objectifs ( TMP ), formée en stricte conformité avec RD 50-34.698-90. Après s'être rendu compte que la décision du client ne serait prise qu'au début des tests, la manœuvre suivante a été entreprise: notre solution de conception a été envoyée au client (c'est-à -dire une solution sur laquelle il n'était pas formellement obligé de se mettre d'accord).
Les attributs rituels ont été conservés dans la solution de conception, mais des ajustements significatifs ont été apportés à ce document par rapport au HMO hébergé. La solution de conception a été complétée par un schéma d'un processus métier automatisé avec une brève description, des dispositions d'interface utilisateur, des formulaires de rapports reçus pour l'impression, des propositions pour la distribution des accès, ainsi qu'un bref scénario pour la livraison de cette solution de conception. En termes d'exigences ambiguës et contradictoires, une description claire et détaillée a été faite. Cependant, le reste du texte a été minimisé de toutes les manières possibles. Les algorithmes triviaux n'ont pas du tout été décrits, tout comme les champs des formulaires d'écran n'ont pas été décrits, dont le but et les règles de validation étaient clairs dans les dispositions d'interface utilisateur données.
Le cocktail qui en résultait était en même temps de forme similaire à un document rédigé conformément aux exigences de la RD 50-34.698-90, mais en fait il ne correspondait à aucun des formats donnés dans ce GOST. En même temps, ce qui y était écrit a été compris par un représentant ordinaire et non préparé du client. Les exigences spécifiées dans ce document étaient parfaitement claires pour le client et l'entrepreneur. Les limites des exigences, la quantité requise de travaux planifiés et la manière dont ces travaux auraient dû être achevés ont été déterminées.
La lettre d'accompagnement contenait quelque chose comme ceci:
«Nous présentons une variante d'une solution de conception pour répondre aux exigences énumérées. Nous vous informons du début des travaux sur la mise en œuvre de l'option présentée. Si vous n'êtes pas d'accord avec la solution de conception proposée, veuillez nous en informer. "
En cas de discussion plus approfondie des exigences, l'absence de réponse à une telle lettre était interprétée comme un accord formel du client avec la solution de conception proposée. Si le client émettait des objections, dans ce cas, il était informé que les travaux de mise en œuvre de cette solution de conception étaient
Ce qui est drôle, dans un premier temps dans les lettres de réponse si le client n'a pas envoyé les éclaircissements nécessaires, nous avons utilisé la phrase «le travail est suspendu». Après plusieurs lettres de ce type, l'un des représentants du client a créé un scandale en rapport avec le fait que «selon le contrat signé, nous ne pouvons pas suspendre les travaux et l'absence de clarification sur les exigences n'est pas un motif de résiliation du développement». Cependant, il n’a pas d’objection au libellé selon lequel «les travaux ne peuvent pas être poursuivis».
Comme il s'est avéré plus tard, malgré le fait que la structure formée de la solution de conception ne répondait pas aux exigences de GOST, l'approche proposée a grandement facilité les mouvements corporels rituels pour la formation et l'approbation de la documentation de conception. Le contenu de la documentation de conception, qui était nécessaire pour la livraison du projet, a été formé par copie sélective des sections pertinentes des solutions de conception. Dans le même temps, en ce qui concerne les sections de la documentation qui ont été formées sur la base de décisions de conception préventivement «convenues», aucun commentaire n'a été fait par le client lors de la réception.
Description de l'éléphant non conforme à GOST
La vérité est que les clients ne savent pas ce qu'ils veulent. Habituellement, ils ne savent pas à quelles questions il faut répondre et n'ont presque jamais pensé au problème avec autant de détails qu'il devrait être indiqué dans la spécification.
Frederick Brooks
À mon avis, le critère principal pour une bonne description de l'énoncé du problème (solution de conception) n'est pas le respect des exigences formelles de GOST, mais une description sans ambiguïté des conditions de la réussite des travaux pour répondre aux exigences du client. De ce point de vue, la description des éléments de test pour vérifier les exigences fait en fait partie intégrante de toute solution de conception.
Il convient de noter que lorsque vous travaillez avec un client du gouvernement, toutes les ambiguïtés et ambiguïtés dans vos décisions de conception seront toujours interprétées en faveur du gouvernement. Pour éviter de tels angles morts, par essais et erreurs dans les exigences de journalisation, une liste de contrôle pour l'évaluation de la qualité de la conception a été élaborée, qui énumère les principales sections qui doivent être reflétées dans la solution de conception selon les besoins . Ainsi, toute solution de conception doit être vérifiée à partir des positions suivantes.
- Liste des exigences du client (qui seront implémentées dans le cadre de la solution de conception).
- Liste des définitions et abréviations.
- La liste des documents normatifs régissant le processus automatisé.
- (use case), :
- ( , BPMN – , : , ) ;
- ;
- ( ) — ;
- ( , ).
- :
- , ;
- (UI) ( , , );
- () .
- :
- API;
- () «» ( );
- () «» .
, « » ( 2011 ., 1). - , (). - :
- , () , ;
- , () .
- () , , . ( ) . ( ), , () , . «» .
Je le répète - ce n'est pas une structure fixe pour une solution de conception, c'est une liste formelle de questions ( liste de contrôle), dont les réponses devraient, si nécessaire, être reflétées sous une forme ou une autre dans la solution de conception. Comme le montre la pratique, si le développement par rapport à l'un des éléments décrits ci-dessus n'est pas attendu, il sera préférable de l'indiquer explicitement dans la solution de conception. Ou presque explicitement (ne faites pas peur au client). Le critère principal est une interprétation sans ambiguïté. Il est important de ne pas en faire trop pour qu'au lieu de résoudre l'exigence énoncée, cinq nouveaux ne naissent pas à la suite de son approbation. Par exemple, la phrase "La référence des types d'objets ne doit contenir que des valeurs réelles" et la phrase "La référence des types ne permet pas de stocker l'historique des modifications" signifient la même chose, mais la deuxième phrase conduira très probablement au fait que vous devez décrire et implémenter des mécanismes de contrôle de version ce manuel même.Lors de la prise de décisions de conception, il est important de comprendre que son objectif est de fixer les règles par lesquelles vous êtes assuré de transmettre les exigences associées à ces décisions.
, , , .
Une grande partie (sinon la totalité) du projet dépend de la façon dont les représentants du client imaginent le résultat final. Par conséquent, dès les premiers stades, la conception des dispositions d'interface utilisateur est la clé du succès du projet. Clarifier et préciser les exigences du client en termes de description externe du produit logiciel qu'il comprend. Le dialogue avec les représentants des clients, basé sur la discussion des dispositions d'écran, s'est avéré beaucoup plus efficace que le dialogue sur la discussion des formats de données d'entrée et de sortie et de leurs algorithmes de transformation (les principales sections de l'IPR, créées conformément à GOST).
L'élaboration dans le cadre des missions de conception de tous les éléments de l'interface utilisateur, en plus de la transparence de la compréhension des limites d'implémentation, apporte également une solution à un certain nombre de problèmes:
- . , , UI, , .
: . . ISBN: 978-5-91180-090-1
- UX- . , , ( ).
- «» . UI , , – , ( « » ).
- , «» . UX- . , 80% . , . ( ) : « ?». , , ( ) , , . , « ». «» . , , « ».
Je voudrais dire quelques mots sur les principes de conception des interfaces utilisateur pour les systèmes de contrôle automatisés. Malgré la croissance de l'utilisation des appareils mobiles, semblable à une avalanche, pour les systèmes de contrôle automatisés utilisés dans les agences gouvernementales, les ordinateurs de bureau et les ordinateurs portables restent hors de la concurrence (ainsi que pour résoudre les problèmes de programmation et d'administration système). Actuellement, divers outils sont apparus pour le prototypage d'interfaces . Cependant, expliquer les spécificités de l'utilisation de Figma ou Axure dans l'intérêt des appareils mobiles perd 10% des moyens primitifs qui vous permettent de concevoir 90% des interfaces utilisateur.ACS .
D'après mon expérience, pour réduire considérablement les problèmes de développement logiciel, vous devez suivre quelques règles simples lors de la conception des interfaces utilisateur.
Tout d'abord, vous devez décider d'un schéma de navigation général sur lequel, comme un arbre de Noël, vous pouvez accrocher sans douleur de plus en plus de nouveaux éléments d'interface. À cet égard, pour les systèmes de contrôle automatisés dans ma pratique, le schéma le plus efficace s'est montré, qui est largement utilisé dans divers IDE .
Je ne donnerai pas d'exemple d'interface IntelliJ IDEA ou PhpStorm icicependant, j'essaierai de disséquer les principaux composants d'une telle interface utilisateur en composants, du point de vue d'un analyste d'un système de contrôle automatisé.
L'interface construite selon ce schéma contient un panneau vertical pliable sur la gauche, qui permet de naviguer dans tout le système. La présence d'un panneau vertical avec des sections contenant des menus hiérarchiques assure en effet la mise en œuvre de la règle des « trois clics ».
Chacune des options de menu de la barre de navigation principale permet d'accéder aux formulaires-listes d'objets. Les listes d'objets (catalogues) et formulaires (cartes) affichant ces objets constituent la part du lion de l'interface utilisateur. L'unification de ces deux types de formulaires dans le cadre du projet et la formation d'une structure de navigation sur leur base peuvent réduire considérablement le nombre de demandes des utilisateurs associées à des lacunes dans la documentation utilisateur.
Dans le cadre de la description de tout formulaire de liste, la conception doit déterminer:
- liste des champs d'attributs affichés;
- Exigences pour les modes d'affichage de liste (affichage par défaut, regroupement, tri);
- les exigences du sous-formulaire associé à l'élément de liste (fiche de vue rapide (tableau))
- exigences pour le panneau de filtrage (sélection des enregistrements selon une liste donnée d'attributs);
- description des opérations de groupe (actions simultanées sur plusieurs éléments de liste, par exemple: comparaison d'éléments de liste, modification des attributs de plusieurs éléments de liste, modification des droits d'accès pour plusieurs éléments de liste);
- description des formulaires (panels) de rapports statistiques opérationnels (suivi) sur la base des résultats de la sélection de la liste;
- une description des exigences relatives aux rapports à imprimer et un algorithme pour leur génération;
- exigences pour notifier les utilisateurs (systèmes externes) lorsque les objets changent.
Lors de la conception de formulaires de liste, les règles suivantes ont bien fonctionné:
:
- ;
- , (CRUD, , ..) ;
- /;
- liste des messages d'information possibles;
- façons d'afficher l'historique des modifications d'objets.
Quelques mots sur la boîte à outils. À la suite d'essais et d'erreurs lors de la mise en œuvre de divers projets gouvernementaux, les trois approches suivantes de la conception d'interfaces se sont avérées les plus efficaces.
- Si, au cours du processus de développement, des modifications des interfaces existantes sont nécessaires, vous ne devez pas réinventer la roue. Ici, Paint.NET s'est montré le meilleur de tous (avec l'aide duquel, d'ailleurs, des images pour cet article ont été préparées). Cela n'a pas de sens de redessiner les formulaires, il est plus facile de changer la capture d'écran terminée.
- , — « », MS Visio . , , , , MS Visio, , , Windows.
- , - , . , , . DHTMLX. XML-, , . (view), , . , , MS Visio. , , , « ».
À plusieurs reprises, donnant tous ces arguments aux développeurs avancés, loin des problèmes du client, j'ai vu leurs yeux se faner et écouté leur évaluation experte de la misère et de la surcharge de l'interface utilisateur proposée. Cependant, au fil du temps, après avoir analysé l'expérience de plusieurs projets, j'ai remarqué un schéma étonnant: si un programmeur critique avec zèle le retard et la complexité des interfaces utilisateur développées, c'est un signe certain que le client acceptera une telle interface avec un bang.
Échafaudages et coffrages
Habituellement, les gens pensent beaucoup. Mais le problème, c'est qu'ils pensent aux problèmes, pas aux solutions à ces problèmes.
David Allen
Lors de la construction de maisons, de nombreuses structures auxiliaires sont utilisées, ce qui, une fois la construction terminée, sont totalement inutiles. Ce sont des échafaudages et des coffrages . Fait remarquable, même les non-professionnels n'essaient pas de contester la nécessité d'acheter et de maintenir ces structures. Dans le secteur informatique, en revanche, vous voyez souvent un analyste «expérimenté» lutter pour créer immédiatement une documentation de projet qui répond à toutes les exigences.
Cependant, à mon avis, sans enregistrement préventif et approbation des solutions de conception, la documentation de conception créée ne convient que pour la clôture formelle du contrat et, à l'avenir, nuit à l'exploitation plus qu'elle n'aide. Cependant, les solutions de conception et les prototypes décrits ci-dessus ne sont pas les seules «structures auxiliaires» du travail analytique.
À première vue, il semble que tout dépend de l'expérience de l'analyste, et il est impossible de réglementer l'utilisation de ces travaux auxiliaires. Par exemple, comment prendre en compte et réguler le travail d'un analyste qui a passé toute la journée à rendre visite à un client et le lendemain apporté trois gigaoctets de toutes sortes de documents? Ou que l'analyste a passé une semaine à étudier ces documents? Est-ce bon ou mauvais? Et vous ne pouvez vraiment pas répondre à cette question si vous ne connaissez pas les résultats qui ont du sens à la lumière de la mise en œuvre du projet.
C'est pourquoi, dans le cadre de notre projet, une classification des travaux analytiques réalisés au regard des résultats obtenus a été réalisée. En plus de la solution de conception,La plupart des projets logiciels auxquels j'ai dû participer ont obligé l'analyste à développer des matériaux analytiques des types suivants.
- Analyse de documents - un rapport basé sur les résultats de l'analyse des documents réglementaires du client ou de la documentation du projet.
- Examen analytique - un rapport sur les résultats de l'analyse des solutions au problème qui s'est posé (en règle générale, une analyse comparative des nouvelles technologies ou des tendances du marché).
- Enquête d'information - un rapport sur les résultats d'une étude des processus commerciaux existants du client (formation du modèle tel quel - « tel quel »).
- — , (use case). legacy-.
- — , ( ).
- — , .
La deuxième étape vers une conception prévisible consistait à définir des exigences spécifiques pour le travail analytique prévu. Sur la base de ces exigences, un modèle de description de problème JIRA a été défini pour chaque type de matériel analytique en cours de développement.
| Modèles de description de tâches d'analyse | |
|---|---|
| Type de materiau | Description typique de la définition d'un problème dans JIRA (résultats requis du travail analytique) |
| 1. Analyse des documents | 1.1. Identifier la liste des modifications par rapport à la version précédente du document |
| 1.2. Révéler les termes que le document introduit | |
| 1.3. Identifier et décrire les classificateurs de domaine normatifs et informels qui sont identifiés dans ce document | |
| 1.4. Identifier les sections de documents qui réglementent les processus automatisés | |
| 1.5. Identifier les ambiguïtés et les contradictions | |
| 1.6. | |
| 1.7. | |
| 2. | 2.1.
|
| 2.2. (, , , ) | |
| 2.3. | |
| 2.4. | |
| 3. | 3.1. , .
|
| 3.2. () , | |
| 3.3. ( ) | |
| 3.4. ( , , ) | |
| 3.5. | |
| 3.6. ( ) | |
| 3.7. ( ) | |
| 4. | 4.1. |
| 4.2. . | |
| 4.3. | |
| 4.4. | |
| 4.5. | |
| 4.6. | |
| 4.7. | |
| 4.8. | |
| 4.9. | |
| 4.10. | |
| 4.11. | |
| 4.12. | |
| 4.13. | |
| 5. | 5.1. () |
| 5.2. () | |
| 5.3. () | |
| 5.4. ( ) | |
| 5.5. ( ) | |
| 5.6. | |
| 6. | 6.1. , ( , ) |
| 6.2. ( , ) | |
| 6.3. ( , , , — data mining) | |
| 6.4. | |
| 7. | 7.1. |
| 7.2. DĂ©velopper un programme de travail | |
| 7.3. Préparez une présentation | |
| 7.4. Préparer une liste de concepts de base et leurs définitions | |
| 7.5. Préparer une liste de contrôle (tâche de test pour déterminer le niveau de formation) | |
| 7.6. Préparez un enregistrement vidéo de la leçon | |
L'énoncé de la tâche pour le développement de matériaux analytiques implique une brève description des résultats requis et non une description des processus d'analyse. Ainsi, par exemple, il est recommandé d'éviter des expressions telles que «effectuer une analyse de domaine…» ou «étudier le document».
Un plan pour le maestro
Tout doit être énoncé le plus simplement possible, mais pas plus simplement.
Albert Einstein
Souvent, lorsqu'il s'agit de planifier le travail d'analyse et de programmation, il y a beaucoup de controverse sur la façon d'estimer le calendrier des résultats dans ce cas. Cependant, l'analyse ci-dessus de cette activité créative nous permet de faire l'hypothèse qu'elle est encore possible dans le cadre d'un projet logiciel. La première étape dans ce sens consiste à décomposer le travail de conception du système en parties qui peuvent être vérifiées à une fréquence d'au moins une fois par semaine. Il est nécessaire de veiller à ce que les coûts de main-d'œuvre de l'analyste pour la formation d'une solution de conception ne dépassent pas 5 jours ouvrables (en termes de volume, une telle solution de conception devrait comprendre environ 20-30 pages - selon GOST R ISO / IEC 15910-2002). En conséquence, selon les mêmes normes, un programmeur devrait prendre un maximum de 3 heures pour examiner la même solution de conception.
Il est important de comprendre qu'il n'est pas nécessaire de réaliser un projet technique à partir d'une solution de conception . La solution de conception ne doit couvrir qu'un petit groupe d'exigences interdépendantes, dont le résultat peut être présenté au client.
Il est également important d'éviter de tomber dans le piège que Mary et Tom Poppendieck mettent en garde lors de l'élaboration d'une décision de conception., à savoir ne pas devenir l'otage du mythe selon lequel une spécification détaillée créée à l'avance est garantie pour réduire les pertes. En règle générale, lorsqu'il s'accorde sur une solution de conception, le client essaie de mettre tout ce dont il se souvient dans ce document. Par conséquent, lors de l'accord sur celui-ci, il est important de garantir le minimum requis qui garantira le succès des tests préliminaires. Dans le même temps, la clé du succès n'est pas seulement une combinaison de qualité, de calendrier et de coût, mais aussi la satisfaction des participants au projet avec ses résultats.
En règle générale, pour obtenir les délais d'exécution des tâches d'analyse, une expertise du contractant lui-même suffit, mais en cas de litige, une approche pragmatique peut être appliquée.... Pour augmenter l'objectivité de l'évaluation de l'intensité de travail des tâches d'analyse, un calculateur en ligne peut être utilisé , ce qui vous permet de planifier et d'estimer les coûts de main-d'œuvre pour effectuer un travail analytique. À l'aide de cet outil, vous pouvez créer une liste des travaux prévus, clarifier leur formulation, en fonction des spécificités du projet. Pour chacun des travaux prévus, l'estimation minimale, maximale et la plus probable des coûts de main-d'œuvre est prise en compte. À la suite du calcul, la complexité attendue de la tâche est formée et la réserve de temps optimale est calculée, qui doit être laissée à l'assurance. La description générée de la définition du problème pour l'analyse peut être copiée directement dans le champ de description du problème JIRA.
En plus des attributs généraux décrits dans l'article " JIRA: limites du projet", Pour chaque problème de type" analyse "dans JIRA, l'ensemble suivant d'attributs supplémentaires (personnalisés) a été déterminé empiriquement.
| Attributs supplémentaires de la tâche "analyse" | |
|---|---|
| Nom d'attribut | La description |
| informations générales | |
| Type de materiau | Type de matériaux analytiques:
|
| RĂ©sultat de la solution | |
| Version actuelle | Le numéro de la version actuelle du matériel analytique est modifié manuellement par l'analyste responsable chaque fois que le matériel analytique correspondant est chargé dans le référentiel de documentation. Le numéro se compose de deux parties séparées par un point: [A]. [B].
|
| , | |
| () | |
Compte tenu de ce qui précède, clarifions la séquence d'actions précédemment donnée de l'analyste sur la mise en œuvre de tâches de type «analyse» dans l'intérêt du développement logiciel.
1. Si nécessaire, l'analyste responsable doit planifier des tâches dans JIRA pour mener des enquêtes d'information avec les représentants des clients (ces tâches sont liées aux exigences pertinentes).
Il est conseillé, avant la rencontre, en première approximation, de former des maquettes de l'interface utilisateur , qui pourront être discutées avec le client. Lors d'une enquête d'information, il est nécessaire de discuter avec le client du processus métier principal de son point de vue (user story - user story), des manières alternatives dont le client voit le résultat final.
J'ai souvent rencontré l'opinion que la base d'une enquête d'information est d'interroger un employé compétent qui vous expliquera en détail les caractéristiques du processus automatisé. Cependant, ce qui est bon pour le développement dans l'intérêt d'un client commercial peut avoir les conséquences les plus inattendues pour un gouvernement. J'ai rencontré à plusieurs reprises une situation où il s'est avéré que la description du processus, formée sur la base des histoires d'anciens combattants aux cheveux gris, contredit les principales exigences des documents réglementaires actuels. Et cela ne s'expliquait pas par le fait que l'analyste avait mal compris quelque chose, mais par le fait que le vétéran «a fait cela toute sa vie».
Par conséquent, avant de rencontrer des experts en la matière, il est nécessaire d'analyser les documents réglementaires du point de vue de la régulation du processus censé être automatisé. Il est important de comprendre que les documents réglementaires ne sont pas non plus la vérité ultime. Souvent, dans une analyse impartiale, les documents réglementaires contiennent toujours des ambiguïtés et des contradictions (l'exception, en règle générale, sont les documents «écrits dans le sang»). Voici quelques-uns des désaccords les plus courants auxquels vous devriez prêter attention:
- violation des principes de base de la classification , par exemple, lorsque différents signes sont mélangés au sein d'un même groupe (rouge, vert, chaud);
- construction de documents de reporting basés sur des attributs, qui ne sont pas prévus;
- ;
- - ;
- — - , .
La résolution de ces conflits réglementaires est l'un des principaux problèmes lors des rencontres avec les représentants des clients. Afin de fixer cette décision, à la suite de l'enquête d'information, un protocole doit être établi avec une indication des participants, du lieu et de l'heure. Le protocole est présenté au client pour clarification (un e-mail est joint à la tâche correspondante). Après cela, la tâche de l'enquête d'information peut être transférée au statut «terminé». Cette tâche JIRA est transférée à l'état «fermé» après réception de la confirmation du client concernant l'approbation du protocole.
2. Sur la base des exigences spécifiées et des résultats des enquêtes d'information, une solution de conception est formée. L'analyste responsable doit le coordonner avec le chef de projet et les programmeurs (pour chacun d'eux, des sous-tâches appropriées sont créées). Si la solution de conception n'a pas passé l'approbation interne pendant la journée de travail, la tâche est transférée au statut «en attente» (un signal au chef de projet). Après avoir passé l'approbation interne, la solution de conception est envoyée au client pour examen (si nécessaire, approbation). Tous les détails de la soumission sont enregistrés dans les commentaires de la tâche. Alors que la solution de conception est du côté du client, la tâche est transférée au statut «en attente».
3.Si la solution de conception est acceptée (ou s'il est clair que l'approbation est retardée et que les délais sont épuisés), l'analyste responsable formule sur sa base des tâches de développement, de test et de documentation. Dans ce cas, il est nécessaire de procéder à une évaluation préliminaire des coûts de main-d'œuvre pour la mise en œuvre de la solution de conception (en tant que somme des coûts de main-d'œuvre des tâches de développement associées à cette solution de conception). Sur la base de cette évaluation, il est nécessaire de clarifier le calendrier de mise en œuvre des exigences associées.
4. Après accord avec le client (une lettre confirmant ce fait est enregistrée dans JIRA), la tâche de préparation d'une solution de conception peut être transférée au statut «terminé».
Ă€ suivre
Actuellement, la conception de logiciels pour les clients gouvernementaux est le plus souvent organisée conformément aux exigences de la série GOST 34. Dans le même temps, prônant la conformité exacte de la documentation de conception finale avec ce GOST, la plupart des représentants du client «oublient» souvent qu'en plus de la documentation fournie pour tester le logiciel développé, le client doit approuver les solutions de conception dans le cadre de l'approbation du projet et des conceptions techniques. Et même dans le cas où le projet et les conceptions techniques sont convenus, il n'est pas rare que le contenu soit ignoré au nom de délais irréalistes en pleine conformité avec le formulaire. Cela est particulièrement vrai pour la conception de systèmes qui ne sont pas directement liés à la sécurité des personnes. Donc, sur l'un des projets, un administrateur général a «enseigné la vie»parler de la façon dont il a construit un projet technique de 500 pages en utilisant Wikipedia en une nuit. En règle générale, des personnes complètement différentes doivent démêler les résultats de telles «décisions de conception».
Dans ces conditions difficiles, les approches décrites ici permettent d'organiser une accumulation itérative de fonctionnalités logicielles tout en conservant la cohérence des solutions implémentées, ce qui correspond aux principes du développement logiciel lean . D'autre part, les paramètres cibles des solutions de conception décrites permettent de compiler des documents sur leur base qui répondent aux exigences «procrustes» du client à un coût minimal.
La division du travail analytique en actions élémentaires a également permis de coordonner les actions de plusieurs collaborateurs avec différents niveaux de formation et, de ce fait, de constituer naturellement une matrice de compétences pour les analystes de notre projet en LANIT , que je compte évoquer dans le prochain article.
PSCet article fait partie d'une série d'articles intitulée « Règles pour la préparation en temps opportun de délicieux logiciels » que j'utilise comme règlement d'équipe informel sur des projets logiciels personnalisés dans l'intérêt des organisations gouvernementales. Cette série comprend les articles suivants:
- « JIRA comme remède contre l'insomnie et les dépressions nerveuses » - l'idée principale pour organiser un travail sur un projet utilisant JIRA;
- « JIRA: limites du projet » - dispositions de base pour l'unification du projet et exigences générales pour tous les types de tâches JIRA;
- « JIRA: gestion des exigences » - les principales caractéristiques de l'enregistrement, de la clarification et du contrôle de la mise en œuvre des exigences des clients dans le modèle proposé;
- "Concevoir des solutions: jouer selon vos règles »- les principaux aspects de la gestion du travail analytique et la formation d'énoncés de problèmes pour les développeurs;
Dans le cadre de ce cycle, sont en cours d'Ă©laboration pour publication:
- « Matrice des compétences des analystes » - critères d'appréciation du niveau de maturité des analystes sur des projets logiciels personnalisés;
- « Là où les troubles se cachent sur le projet » - les critères (métriques) de l'évaluation opérationnelle de l'état actuel du projet logiciel.
L'étiquette principale de cette série d'articles est d'apporter une amélioration évolutive de la qualité des projets logiciels basée sur une meilleure efficacité de gestion. En d'autres termes, pour former des méthodes de croissance appliquées aux niveaux du modèle CMMI .
Si vous avez compris comment utiliser JIRA plus efficacement sur votre projet logiciel, partagez vos idées. Seulement en décrivant ces idées, évitez les expressions «en quelque sorte» et «en quelque sorte». J'invite tout le monde à discuter. J'attends des commentaires / suggestions / doutes / souhaits dans les commentaires.