Récemment, un de mes amis s'est plaint de la prédominance de l'argot anglais dans certaines communautés professionnelles. Je lui ai répondu que c'était mauvais, mais forcé. Tout comme cela, le processus d'emprunt naturel a lieu, où le nécessaire est adapté et l'inutile est balayé. Et dans la langue anglaise elle-même, il y a beaucoup plus de latinismes que dans les anglicismes russes. Après tout, une fois que ceux qui étaient engagés dans la science communiquaient exclusivement en latin.
Dans la langue russe, il reste une petite zone où il est nécessaire de l'amener aux réalités modernes. Cela s'applique aux pratiques occidentales dans le domaine de la gestion des personnes et des équipes. Ils ont été mal étudiés par la science soviétique, alors que dans les années 90, leur introduction accélérée a commencé par des personnes qui les considéraient récemment comme idéologiquement incorrectes. Il en était de même pour l'économie et dans des domaines plus spécifiques, tels que ceux liés à la production de logiciels.
Nous avons toujours su écrire un excellent code de programme. Mais l'activité logicielle est plus large que la simple programmation louée - c'est le commerce des connaissances. Et si c'est le cas, la production et son organisation sont nécessaires. Ici, un rôle clé est joué par les systèmes de gestion de la collecte des exigences, où le processus de production doit être construit sur la base de l'expérience occidentale.
Plus loin dans l'article, les erreurs d'emprunt typiques sont analysées à l'aide d'exemples tirés de la traduction du livre de Karl I. Wigers «Software Requirements Development». À la fin, le matériel discuté est résumé à l'aide du modèle en V du cycle de vie des exigences de conception des logiciels.
Sans aucun doute, un livre curieux de Karl I. Wigers «Développement des exigences logicielles» (ci-après dénommé RTkPO) est en train de devenir un certain standard dans la communauté de l'information russe. Mais l’utilisation des dispositions de ce livre (empruntées, originales, traduites) en dehors du concept de l’auteur soulève des questions que je voudrais comprendre.
Il s'agit d'une illustration de l'évolution des exigences au fur et à mesure que le projet progresse de haut en bas, à travers trois documents: «
Document sur l'image et les limites du projet », «
Document sur les cas d'utilisation », «
Spécification des exigences logicielles ». Dans la 3e édition, les deux premiers documents sont présentés comme «
Document de concept et limites » et «
Document d'exigences utilisateur »
Pour créer le bon document, vous devez d'abord comprendre son essence. Il semble que la clé est de démêler la mystérieuse «
image et limites du projet »: résolu, et vous pouvez utiliser une pratique prête à l'emploi sans aucune restriction et avec un grand avantage. Malheureusement, cela ne fonctionne qu'avec des technologies simples achetées à des tiers. Les aspects
de la gestion d'équipe sont directement liés aux caractéristiques d'une culture étrangère, et tout n'y est pas facile. Les différences culturelles sont la partie visible de l'iceberg de tout le système des stéréotypes ethniques
subconscients de comportement. Mais nous ne contrôlons pas du tout le domaine de l'inconscient, ou nous ne le contrôlons que partiellement.
Cependant, tout n'est pas si désespéré. Nous devons trouver des associations de leur terminologie avec notre pratique. Nous analyserons le «
Document sur l'image et les limites du projet ». Les limites d'un projet sont la
portée du projet . Cela devrait être traduit par «
charge de travail ». Pas dans le dictionnaire? Hélas. Vous pouvez consulter le manuel en anglais:
portée du projet - partie de la planification du projet, y compris le processus de détermination, puis la documentation des objectifs spécifiques du projet, les résultats, les tâches, les coûts et les délais . Il existe une procédure spécifique, pourquoi ne pas l'appeler «
limites du projet »? Dans ce cas, des problèmes surgiront avec l'intégration de notre propre expérience passée: après tout, nous avons planifié et, en particulier, déterminé l'étendue des travaux auparavant.
Lorsque la traduction du dictionnaire échoue, vous devez rechercher un modèle conceptuel simple qui illustre l'utilisation du terme controversé dans un domaine connexe. La poursuite du transfert d'un modèle de divulgation aussi simple vers le sol natal nous permet de trouver des correspondances linguistiques. Le modèle à triple contrainte est une introduction à la gestion de projet.
Ce modèle révèle la relation entre les termes «
temps d'exécution », «
coût », «
quantité de travail » (temps, coût, étendue), qui sont placés sous la forme d'un triangle équilatéral, ce qui implique que le changement d'un côté de ce triangle entraîne un changement en tout.
La vision du projet est parfois traduite non pas comme une "
image de projet ", mais comme un "
concept de projet ", mais cela n'ajoute pas de clarté.
L'énoncé de vision du projet dans le manuel est défini comme «une
vue idéaliste des résultats commerciaux souhaités qui seront obtenus une fois le projet terminé avec succès ». Nous utilisons généralement le terme «
objectifs du projet » et formulons ces tâches avec une part de pessimisme domestique. Si nous l'appelons «l'
image du projet », il est peu probable que cela contribue à manifester l'optimisme occidental sur son propre sol. Au total, le premier document peut être intitulé «
Objectifs du projet et portée des travaux ». Et rien de mystérieux.
On pense que ces termes ne devraient pas être traduits, mais utiliser la langue anglaise dans le projet. Cela ne fonctionne qu'en partie, limitant considérablement le cercle des personnes expertes en la matière. Les compétences linguistiques de base ne suffisent pas lorsque les problèmes technologiques sont liés aux différences ethnoculturelles.
Voici un exemple typique de RTkPO: «Les
exigences doivent être énoncées de manière séquentielle, par exemple,« le système sera ... »ou« l'utilisateur sera ... », puis le verbe actif, puis le résultat observé ... Vous pouvez utiliser« devrait »comme synonyme de« va », mais éviter "devrait", "peut-être", "pourrait" et les mots similaires, d'où il n'est pas clair si une action est nécessaire . "
Vous pourriez penser qu'il s'agit d'un guide d'action prêt à l'emploi. En fait, cette traduction n'aide pas à le comprendre, mais elle confond encore plus tout. De plus, l'original anglais n'est pas la vérité ultime, mais l'expression d'une certaine perspective sur la modalité de la langue anglaise. La vue est inscrite dans la norme RFC2119 **, qui clarifie les règles d'utilisation des mots clés anglais dans le domaine de la gestion des exigences (
par exemple, must, shall, should, may ). Par exemple, dans cette norme,
doit signifier «
que la définition est une exigence absolue de la spécification ». Cependant, l'auteur a rencontré des modèles de documents avec une interdiction directe sur l'utilisation du
moût (une explication de cette position est disponible sur Internet ***).
Le niveau de détail suivant pour les exigences est le «
document de cas d'utilisation ». Chez RTkPO, il est indiqué qu'il définit des cas d'utilisation, des scénarios et
des tables de
réponse aux événements . La traduction des «
cas d'utilisation » en «
cas d'utilisation » simplifie inutilement la vue des choses (par conséquent, dans la pratique, l'anglicisme des cas d'utilisation s'est solidement établi). Les logiciels modernes devraient avoir une protection contre le piratage et une protection contre les imbéciles, mais considérez cela comme une option d'utilisation - la violence contre la langue russe. Pour la traduction, des «scénarios d'interaction» sont proposés.
En fait, le modèle
événement-réponse nous
est connu. Au lycée, il est étudié comme «
impact - fluctuation -> réponse ». Sous les mêmes influences, la réponse du système peut varier en raison de fluctuations aléatoires. Dans les logiciels utilisateur, il s'agit généralement de diverses situations d'erreur. De plus, au niveau du concept, les effets environnementaux doivent être distingués des effets utilisateurs. Un nom plus ou moins approprié pour ce niveau d'exigences est «
Configuration requise » ou déjà «
Configuration logicielle requise », bien que la terminologie n'ait pas été établie et que des options très différentes soient rencontrées (par exemple, dans la dernière édition, le nom «
Document des exigences utilisateur » est utilisé, ce qui automatiquement exclut les systèmes embarqués de la considération).
L'essence du développement des exigences de ce niveau est la création d'un modèle spéculatif détaillé de logiciel qui fonctionne dans un monde extérieur idéalisé. Par conséquent, un point important est de fixer des limites et de faire des hypothèses. "La
couleur de la voiture peut être quelconque, à condition qu'elle soit noire ", - donc Henry Ford a repensé les exigences commerciales pour la couleur de la voiture en une hypothèse. Cependant, une autre fois, afin de répondre aux exigences commerciales de propreté des voitures, il s'est avéré nécessaire de fabriquer du verre profilé non plan. Les ingénieurs de Ford ont déclaré que c'était techniquement impossible. Ford a trouvé les jeunes inventeurs sur le côté.
Le niveau inférieur est représenté par la «
Spécification des exigences logicielles », qui comprend les «
restrictions », «
l'interface externe », les «
attributs de qualité » et en fait les «
exigences fonctionnelles ». Ceci est le dernier document de la figure, malheureusement, les questions des tests ultérieurs ne sont pas abordées. Par conséquent, pour formuler la définition, RTkPO est obligé d'utiliser le concept d'exigences métier: «
les exigences fonctionnelles déterminent la fonctionnalité logicielle que les développeurs doivent créer pour que les utilisateurs puissent accomplir leurs tâches dans le cadre des exigences métier »
Du côté des tests, la définition est plus simple à construire: "
Les exigences fonctionnelles sont des exigences qui sont testées ." Cela doit être compris comme la capacité de tester chaque exigence fonctionnelle avec un test au sens classique (avec le verdict - réussi ou échoué). L'inverse, à proprement parler, n'est pas vrai: certains tests peuvent exister par eux-mêmes. Mais la présence de tels tests est un indicateur d'omissions dans le travail sur les exigences. Après tout, le test vérifie toute section de code qui n'apparaissait pas d'elle-même, mais à la suite de l'exécution d'une certaine exigence fonctionnelle.
Les processus modernes de développement de logiciels matures tentent de faire entrer le composant de mesure dans les premières étapes de la fabrication de produits logiciels. Sans entrer dans les détails, ce sont pour la plupart toutes sortes de mesures de couverture. Un des indicateurs de la qualité du futur produit est le pourcentage de couverture avec des tests d'exigences fonctionnelles, qui est calculé à l'aide d'un tableau (matrice) de couverture (matrice de traçabilité). Il est possible d'inclure une exigence non fonctionnelle dans la matrice, mais dans les travaux futurs, elle sera marquée comme non testable et, plus important encore, les testeurs l'évalueront comme inutile. Il semble qu'une "
spécification complète
des exigences logicielles " avec une liste d'exigences non fonctionnelles soit très utile aux programmeurs. Et ce serait peut-être le cas si, après compilation, ils y regardaient, au moins de temps en temps.
La grande majorité des exigences non fonctionnelles peuvent être écrites de manière fonctionnelle. Pour paraphraser, presque toute exigence non fonctionnelle d'un système ou d'un produit logiciel peut être transformée en une ou plusieurs exigences fonctionnelles.
Les attributs de qualité dans RTkPO tombent en partie dans des exigences fonctionnelles, ce qui est absolument vrai. Cependant, les limites et l'interface externe de RTkPO sont définies comme suit: «d'
autres exigences non fonctionnelles décrivent les interactions externes entre le système et le monde extérieur, les restrictions de conception et de mise en œuvre. "Les contraintes (contraintes) concernent le choix de la possibilité de développer l'apparence et la structure du produit ." Les sous-systèmes de communication avec le monde extérieur ont toujours une interface fonctionnelle et soumise à des tests.
Les restrictions peuvent-elles être des exigences fonctionnelles? Certainement oui, si vous les écrivez sous forme inversée comme opportunités. Par exemple, le produit doit être plus rapide que celui de ses concurrents (sinon il n'est pas nécessaire - une restriction très sévère). Tout d'abord, nous parlons de la nouveauté des décisions prises, documentées, y compris sous forme d'exigences. Mais il est clair que le système devrait disposer d'un module de mesure des paramètres détectés de cette vitesse, et à un stade précoce.
Ainsi, «
Spécifications fonctionnelles » est un nom établi pour les spécifications de niveau inférieur sous la forme d'un document formaté ou d'une base de données sous le contrôle d'un logiciel spécialisé.
Qu'advient-il des exigences ensuite? Outre les développeurs (programmeurs), les ingénieurs de test et les ingénieurs d'assurance qualité (QA) travailleront avec les exigences. «Test» peut être traduit par «vérification», mais le «test» d'emprunt a apparemment eu lieu. Traduire à nouveau l'AQ nécessite un modèle de divulgation - ici, quels principes le sous-tendent. Premièrement, «
Fit for purpose » (le produit doit être adapté à l'usage prévu), deuxièmement, «
right first time » («la première fois» - les erreurs doivent être éliminées) et troisièmement, l'indépendance du projet. C'est «l'
acceptation », les principes sous-tendent l'acceptation militaire bien connue et l'acceptation légendaire de l'État.
Les spécifications des exigences formeront la base d'autres documents de conception. Au minimum, les exigences seront utilisées dans le développement de
la documentation utilisateur . Il est généralement admis que les tests commencent par
un plan de test et se terminent par un
rapport de test - des documents directement liés aux spécifications. On peut regarder la figure dans RTkPO différemment - comme un modèle généralisé du processus de développement logiciel (ou un modèle de cycle de vie logiciel). Dans ce modèle, les documents finis sont les points d'entrée / sortie entre les phases du processus.
Dans l'ordre chronologique, les documents seront présentés comme suit: exigences opérationnelles (dans le cadre de la portée du projet), exigences système (PO), exigences fonctionnelles, plan de test, rapport de test, documentation utilisateur. La ligne entre les deux documents est la phase de processus. Les modèles sont souvent dessinés sous forme de cycles répétitifs ou de spirales, cependant, un simple axe chronologique est plus visible. Ensuite, la première et la dernière phase du processus sont indiquées non pas par un segment, mais par un rayon. Dans les présentations modernes, l'axe du temps est plié au milieu de la phase de codage sous la forme de la lettre «
V », obtenant le soi-disant
modèle en V.
Les lignes en pointillés montrent les connexions contournant l'axe chronologique, montrant la possibilité de commencer certains travaux à l'avance. Par exemple, avec les exigences commerciales formulées, vous pouvez déjà dire quelque chose sur la documentation utilisateur du produit, et les exigences formées pour le système donneront un modèle de logiciel futur, dont la qualité peut déjà être évaluée.
Mais la fonction principale de ces lignes est de montrer l'évolutivité (simplification) du modèle V.
Prendre en charge toutes les phases et tous les documents est toujours un plaisir coûteux, et une raison très courante de perdre face à des concurrents plus mobiles . Par exemple, un individu fonctionne comme ceci: exigences métier -> développement (codage) -> documentation utilisateur. Il s'agit de la ligne brisée supérieure de la coupe. Les sociétés d'externalisation, en règle générale, sautent les phases inférieures sans dépenser d'argent pour les spécifications fonctionnelles et sont limitées par l'un ou l'autre type d'exigences du système (par exemple,
les scénarios d'interaction ). Pour les produits du même type, il existe généralement une norme d'entreprise et à partir de la phase de codage, un certain rapport de test interne des développeurs est émis afin de commencer la phase d'assurance qualité / acceptation.
Le modèle V fondamental aide à clarifier les domaines de responsabilité. Par exemple, un employé joue le rôle d'ingénieur d'acceptation (AQ) ou d'ingénieur de test, selon la phase dans laquelle il travaille. Peu importe qu'il soit affecté à un projet ou à un département spécifique. Il en va de même pour l'analyste, le concepteur, le développeur - la capacité de remplir tous ces rôles par une seule personne ne réfute pas le modèle V. Pour l'ingénieur d'acceptation (AQ) et l'analyste, la base est «Configuration requise», ils travaillent avec le logiciel développé sous forme de boîte noire. Pour ceux qui sont impliqués dans les phases, la conception, le développement et les tests sont une boîte blanche, bien que dans une mesure différente.
En conclusion, il convient de noter que le modèle V est toujours de présentation (dans ce cas, illustrant l'évolution de la conception des exigences). Ce n'est pas un guide direct pour l'action; les vrais processus de développement de logiciels sont plus compliqués. Mais son potentiel révélateur est difficile à sous-estimer.
* Karl I. Wigers "Développement des exigences logicielles".
** Mots clés à utiliser dans les RFC pour indiquer le niveau d'exigence (https://tools.ietf.org/html/rfc2119)
*** Must - N'utilisez pas must car personne n'a défini en quoi must doit être différent de must. Aussi, doit avoir résisté devant le tribunal, ne doit pas. Certes, le son doit-il être plus fort, non? Je veux dire, si votre patron vous dit que vous "devez" faire quelque chose, eh bien vous allez le faire. Mais, lors de la rédaction des exigences, gardez les choses simples et utilisez simplement doit (http://www.reqexperts.com/blog/2012/10/using-the-correct-terms-shall-will-should)