{"id":11867,"date":"2018-04-04T16:22:46","date_gmt":"2018-04-04T20:22:46","guid":{"rendered":"http:\/\/www.analystik.ca\/blogue\/?p=11867"},"modified":"2019-04-18T15:31:33","modified_gmt":"2019-04-18T19:31:33","slug":"meilleures-pratiques-documentation-projet-ti-objet-de-documentation","status":"publish","type":"post","link":"https:\/\/analystik.ca\/blogue\/language\/fr\/meilleures-pratiques-documentation-projet-ti-objet-de-documentation\/","title":{"rendered":"Meilleures pratiques de Documentation d&rsquo;un Projet TI; l&rsquo;objet de la documentation"},"content":{"rendered":"<p><span style=\"font-weight: 400;\">Les meilleures pratiques de Documentation d&rsquo;un Projet TI ne sont pas simples car l&rsquo;objet de la documentation n&rsquo;est pas toujours \u00e9vident. <\/span><span style=\"font-weight: 400;\">D\u2019abord,<\/span><span style=\"font-weight: 400;\"> dans un projet TI, on peut retrouver un grand nombre de documentations diff\u00e9rentes; le fameux manuel de l\u2019usager, <\/span><span style=\"font-weight: 400;\">la documentation des requis destin\u00e9e \u00e0 l\u2019exploitant du logiciel, la documentation d\u2019architecture et de design destin\u00e9e aux analystes, designers et d\u00e9veloppeurs et finalement, la documentation technique ou documentation logicielle destin\u00e9e aux programmeurs en sont les principaux exemples<\/span><span style=\"font-weight: 400;\">.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">Bref, la documentation d&rsquo;un Projet de D\u00e9veloppement <\/span><span style=\"font-weight: 400;\">logiciel<\/span><span style=\"font-weight: 400;\">, c\u2019est comme les assurances, \u00e7a en prend mais il faut trouver le bon \u00e9quilibre.<\/span><\/p>\n<p><span style=\"font-weight: 400;\">En ce qui nous concerne, nous parlerons de la documentation d\u2019architecture et de conception et de la documentation technique d\u2019un projet de d\u00e9veloppement TI. Ainsi, que doit-on documenter ?<\/span><\/p>\n<p>Dans cette s\u00e9rie de billets, nous allons aborder\u00a0les points suivants :<\/p>\n<ul>\n<li>Que doit-on documenter dans un projet TI ?<\/li>\n<li>Comment doit-on documenter ?<\/li>\n<li>O\u00f9 doit-on rendre disponible ces documents aux diff\u00e9rents lecteurs ?<\/li>\n<\/ul>\n<p><!--more--><\/p>\n<h2>Qu&rsquo;est-ce qui devrait \u00eatre objet de Documentation d&rsquo;un projet TI ?<\/h2>\n<p>&nbsp;<\/p>\n<p>Pour d\u00e9terminer ce qui doit \u00eatre document\u00e9, il faut tenir compte de\u00a0:<\/p>\n<ul>\n<li>de ce qui doit \u00eatre livr\u00e9; l\u2019application<\/li>\n<li>des diff\u00e9rents intervenants<\/li>\n<li>de l\u2019environnement<\/li>\n<\/ul>\n<p>Les \u00e9tapes d\u2019un projet de d\u00e9veloppement logiciel sont g\u00e9n\u00e9ralement les m\u00eames, peu importe le projet\u00a0:<\/p>\n<ul>\n<li>Requis<\/li>\n<li>Planification (Versions et Sprints)<\/li>\n<li>Design<\/li>\n<li>D\u00e9veloppement<\/li>\n<li>Tests<\/li>\n<li>D\u00e9ploiement<\/li>\n<\/ul>\n<p>Selon ces \u00e9tapes, les documents potentiels \u00e0 livrer sont les suivants\u00a0:<\/p>\n<img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11872\" src=\"http:\/\/www.analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/sch\u00e9ma-docu-projet-fr-1024x446.jpg\" alt=\"sch\u00e9ma documentation\" width=\"640\" height=\"279\" srcset=\"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/sch\u00e9ma-docu-projet-fr-1024x446.jpg 1024w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/sch\u00e9ma-docu-projet-fr-300x131.jpg 300w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/sch\u00e9ma-docu-projet-fr-768x335.jpg 768w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/sch\u00e9ma-docu-projet-fr.jpg 1280w\" sizes=\"(max-width: 640px) 100vw, 640px\" \/>\n<p>D\u2019abord, avant de commencer un projet TI, normalement l\u2019entreprise poss\u00e9dera plusieurs documents\u00a0:<\/p>\n<ul>\n<li>Les standards de l\u2019organisation\n<ul>\n<li>La nomenclature<\/li>\n<li>La fa\u00e7on de nommer les objets<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Les standards de conception et de r\u00e9alisation (codage) de l\u2019organisation\n<ul>\n<li>Les normes de documentation<\/li>\n<li>L\u2019architecture de d\u00e9veloppement<\/li>\n<li>D\u00e9finition des \u00ab\u00a0couches\u00a0\u00bb, des classes, des m\u00e9thodes etc.<\/li>\n<li>La fa\u00e7on de nommer les objets<\/li>\n<li>Les normes de test<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<ul>\n<li>Pour le projet lui-m\u00eame, nous avons une panoplie de documents potentiels \u00e0 produire. Nous allons associ\u00e9s ceux-ci aux diff\u00e9rentes \u00e9tapes du processus de d\u00e9veloppement logiciel\u00a0:<\/li>\n<\/ul>\n<h3>REQUIS<\/h3>\n<ul>\n<li>Nous incluons dans cette phase les diff\u00e9rentes rencontres n\u00e9cessaires pour comprendre la demande du client. Un compte-rendu de r\u00e9union doit n\u00e9cessairement \u00eatre produit apr\u00e8s chaque rencontre.\u00a0 Celui-ci devrait contenir les \u00e9l\u00e9ments suivants\u00a0:\n<ol>\n<li>Le ou les sujet(s) de la rencontre<\/li>\n<li>Responsable(s) par sujet<\/li>\n<li>Objectif(s) du sujet : Information, \u00c9changes, Consultation, G\u00e9n\u00e9ration d&rsquo;id\u00e9es, D\u00e9cision<\/li>\n<li>Dur\u00e9e maximale :<\/li>\n<li>Compte-rendu : Compte-rendu et d\u00e9cision(s) sur le sujet<\/li>\n<\/ol>\n<\/li>\n<\/ul>\n<p><strong><em>N.B.<\/em><\/strong><em>\u00a0 Le traitement des \u00ab\u00a0To Do\u00a0\u00bb de ces r\u00e9unions sera discut\u00e9 dans un autre billet<\/em><\/p>\n<ul>\n<li>Le document des sp\u00e9cifications fonctionnelles est d\u00e9finitivement un des documents les plus importants. Il traduit les besoins d\u2019affaires du client en requis pour les d\u00e9veloppeurs. Selon la taille du livrable, il pourra \u00eatre tr\u00e8s court ou tr\u00e8s long, mais il est toujours obligatoire.Chez Analystik, le document est d\u2019autant plus utilis\u00e9 que nous l\u2019alimentons tout au long des d\u00e9veloppements car nous y ajoutons les sp\u00e9cifications techniques.<\/li>\n<\/ul>\n<p>Chez Analystik, le document des sp\u00e9cifications fonctionnelles couvre les \u00e9l\u00e9ments suivants\u00a0:<\/p>\n<p><strong>Exigences d&rsquo;affaires<\/strong> (Business Requirements \u2013 BR)<\/p>\n<ul>\n<li>Objectif du projet<\/li>\n<li>Exigences d&rsquo;affaires<\/li>\n<li>Hypoth\u00e8ses<\/li>\n<li>Exigences d&rsquo;affaires exclues de la port\u00e9e du projet<\/li>\n<li>Annexes<\/li>\n<li>Planification<\/li>\n<li>Approbation<\/li>\n<\/ul>\n<p><strong>Exigences fonctionnelles<\/strong> (Functional Requirements &#8211; FR)<\/p>\n<ul>\n<li>Objectifs du livrable<\/li>\n<li>Sp\u00e9cifications fonctionnelles<\/li>\n<li>Hypoth\u00e8ses<\/li>\n<li>Exigences fonctionnelles exclues de la port\u00e9e du projet<\/li>\n<li>Annexes<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<h3>PLANIFICATION<\/h3>\n<ul>\n<li>Chez Analystik, la planification s\u2019ex\u00e9cute \u00e0 l\u2019aide de l\u2019outil Microsoft TFS (Team Foundation Server) Cloud. Toute la documentation produite se retrouve dans l\u2019outil.\u00a0 On y retrouvera, les Epics, les Features, les User Stories et les Tasks.\u00a0 La beaut\u00e9 de la version Cloud de cet outil est que tous les intervenants du projet y ont acc\u00e8s, les clients compris.<\/li>\n<\/ul>\n<h3>DESIGN<\/h3>\n<ul>\n<li>Une bonne pratique consiste \u00e0 obliger les d\u00e9veloppeurs \u00e0 prendre le temps n\u00e9cessaire pour designer la fonctionnalit\u00e9 qu\u2019ils ont \u00e0 livrer avant de commencer \u00e0 coder. Souvent chez Analystik, ceci prend la forme de sch\u00e9mas UML comme celui-ci\u00a0:<\/li>\n<\/ul>\n<img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11869\" src=\"http:\/\/www.analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Sch\u00e9ma-UML-1024x332.jpg\" alt=\"UML schematics\" width=\"640\" height=\"207\" srcset=\"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Sch\u00e9ma-UML-1024x332.jpg 1024w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Sch\u00e9ma-UML-300x97.jpg 300w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Sch\u00e9ma-UML-768x249.jpg 768w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Sch\u00e9ma-UML.jpg 1268w\" sizes=\"(max-width: 640px) 100vw, 640px\" \/>\n<h3>D\u00c9VELOPPEMENT<\/h3>\n<ul>\n<li>Pour le d\u00e9veloppement, dans le meilleur des mondes, le premier document \u00e0 produire serait le Plan de Tests de la fonctionnalit\u00e9 \u00e0 produire. Par contre, soyons honn\u00eate, tant que la culture du Test Driven Development ne sera pas parfaitement mise en place, le Plan de Tests est souvent produit plus tard dans le processus.<\/li>\n<li>L\u2019autre documentation \u00e0 produire n\u2019est pas un document mais bien une documentation incluse dans le code. Oui, oui, on parle bien des COMMENTAIRES !<\/li>\n<\/ul>\n<p>Malheureusement ici, on peut difficilement parler de bonne pratique d\u2019entreprise car la quantit\u00e9 et la qualit\u00e9 des commentaires ont toujours \u00e9t\u00e9 et seront toujours fonction de la personnalit\u00e9 du d\u00e9veloppeur\u2026\u00a0 malgr\u00e9 les revues de code et autres m\u00e9canismes de validation.<\/p>\n<h3>TEST FONCTIONNEL<\/h3>\n<p>Pour chaque fonctionnalit\u00e9, il faut d\u00e9finir l\u2019objectif du test, les \u00e9tapes ainsi que les r\u00e9sultats attendus. Notre grille de plan de test ressemble \u00e0 ceci\u00a0:<\/p>\n<img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-11870\" src=\"http:\/\/www.analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Test-Plan-eng-1024x346.jpg\" alt=\"Test Plan\" width=\"640\" height=\"216\" srcset=\"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Test-Plan-eng-1024x346.jpg 1024w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Test-Plan-eng-300x101.jpg 300w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Test-Plan-eng-768x259.jpg 768w, https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/Test-Plan-eng.jpg 1280w\" sizes=\"(max-width: 640px) 100vw, 640px\" \/>\n<h3>D\u00c9PLOIEMENT<\/h3>\n<ul>\n<li>Encore une fois pour le d\u00e9ploiement, la documentation peut \u00eatre minimaliste, tel un site Web simple chez un fournisseur, ou tr\u00e8s complexe; par exemple une application Windows critique d\u00e9ploy\u00e9e sur des centaines de postes et des environnements h\u00e9t\u00e9roclites.<\/li>\n<\/ul>\n<p>Dans ce dernier cas, on aura plusieurs phases de tests, diff\u00e9rents environnements de \u00ab\u00a0\u00c9valuation de Qualit\u00e9 \u00bb et des outils de suivi seront utilis\u00e9s pour compiler et suivre les tests, des outils comme Team Foundation Server Cloud, JIRA\u2026<\/p>\n<p>&nbsp;<\/p>\n<h3><strong>Conclusion<\/strong><\/h3>\n<p>\u00c9videmment, selon l\u2019application \u00e0 livrer les diff\u00e9rents intervenants, et l\u2019environnement dans lequel l\u2019application roulera, une panoplie d\u2019autres documents peuvent \u00eatre exig\u00e9s.\u00a0 En voici quelques exemples\u00a0:<\/p>\n<ul>\n<li>Devis<\/li>\n<li>Plan de projet<\/li>\n<li>Daily Scrum &#8211; Suivi des obstacles<\/li>\n<li>Liste des actions \u00e0 suivre<\/li>\n<li>Suivi des heures et des montants<\/li>\n<li>Liste des livrables<\/li>\n<li>Suivi de l&rsquo;assurance qualit\u00e9 des livrables<\/li>\n<li>Comptes rendus<\/li>\n<\/ul>\n<p>Il est donc important de trouver un juste \u00e9quilibre dans la documentation car, malheureusement, celle-ci n\u2019est pas gratuite et son co\u00fbt peut varier de 10% \u00e0 plus de 100% des co\u00fbts de d\u00e9veloppement<\/p>\n<p>Il faut retenir les b\u00e9n\u00e9fices suivants de la documentation\u00a0<span style=\"font-weight: 400;\">d\u2019un projet de d\u00e9veloppement TI<\/span> :<\/p>\n<ul>\n<li>P\u00e9rennise l\u2019application livr\u00e9e en facilitant son \u00e9volution (mise \u00e0 niveau)<\/li>\n<li>Facilite le support (troubleshooting)<\/li>\n<li>Minimise le risque de l\u2019entreprise \u00e0 plusieurs niveaux en lui donnant une certaine autonomie en regard de son \u00e9quipe de d\u00e9veloppement TI ou de ses fournisseurs TI<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n<p>D\u2019un autre c\u00f4t\u00e9, la documentation d&rsquo;un projet TI allonge les temps et les co\u00fbts de d\u00e9veloppement.<\/p>\n<p>&nbsp;<\/p>\n<p>Bon projet de d\u00e9veloppement,<\/p>\n<p>&nbsp;<\/p>\n<p><strong>Denis Paul &amp; Michel<\/strong><\/p>\n<!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p>Les meilleures pratiques de Documentation d&rsquo;un Projet TI ne sont pas simples car l&rsquo;objet de la documentation n&rsquo;est pas toujours \u00e9vident. D\u2019abord, dans un projet TI, on peut retrouver un grand nombre de documentations diff\u00e9rentes; le fameux manuel de l\u2019usager, la documentation des requis destin\u00e9e \u00e0 l\u2019exploitant du logiciel, la documentation d\u2019architecture et de design&#8230;  <a class=\"excerpt-read-more\" href=\"https:\/\/analystik.ca\/blogue\/language\/fr\/meilleures-pratiques-documentation-projet-ti-objet-de-documentation\/\" title=\"Read Meilleures pratiques de Documentation d&rsquo;un Projet TI; l&rsquo;objet de la documentation\">Read more &raquo;<\/a><!-- AddThis Advanced Settings generic via filter on wp_trim_excerpt --><!-- AddThis Share Buttons generic via filter on wp_trim_excerpt --><\/p>\n","protected":false},"author":3,"featured_media":11903,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Meilleures pratiques de Documentation d'un Projet TI, objet de la documentation","_seopress_titles_desc":"Les meilleures pratiques de Documentation d'un Projet TI ne sont pas simples car l'objet de la documentation n'est pas toujours \u00e9vident; nous parlerons ici de la documentation d\u2019architecture et de conception et de la documentation technique d\u2019un projet de d\u00e9veloppement TI.","_seopress_robots_index":"","content-type":"","footnotes":""},"categories":[3565,3377],"tags":[4418,4416,4412,4414],"better_featured_image":{"id":11903,"alt_text":"","caption":"","description":"","media_type":"image","media_details":{"width":2880,"height":1851,"file":"2018\/04\/lostindoc.jpg","sizes":{"thumbnail":{"file":"lostindoc-63x63.jpg","width":63,"height":63,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-63x63.jpg"},"medium":{"file":"lostindoc-300x193.jpg","width":300,"height":193,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-300x193.jpg"},"medium_large":{"file":"lostindoc-768x494.jpg","width":768,"height":494,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-768x494.jpg"},"large":{"file":"lostindoc-1024x658.jpg","width":1024,"height":658,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-1024x658.jpg"},"bones-thumb-2880":{"file":"lostindoc-2880x1851.jpg","width":2880,"height":1851,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-2880x1851.jpg"},"bones-thumb-1920":{"file":"lostindoc-1920x1271.jpg","width":1920,"height":1271,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-1920x1271.jpg"},"bones-thumb-1536":{"file":"lostindoc-1536x1016.jpg","width":1536,"height":1016,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-1536x1016.jpg"},"bones-thumb-960":{"file":"lostindoc-960x635.jpg","width":960,"height":635,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-960x635.jpg"},"bones-thumb-600":{"file":"lostindoc-600x397.jpg","width":600,"height":397,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-600x397.jpg"},"bones-thumb-300":{"file":"lostindoc-300x199.jpg","width":300,"height":199,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-300x199.jpg"},"post-thumbnail":{"file":"lostindoc-125x125.jpg","width":125,"height":125,"mime-type":"image\/jpeg","source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc-125x125.jpg"}},"image_meta":{"aperture":"0","credit":"","camera":"","caption":"","created_timestamp":"0","copyright":"","focal_length":"0","iso":"0","shutter_speed":"0","title":"","orientation":"0","keywords":[]}},"post":11867,"source_url":"https:\/\/analystik.ca\/blogue\/wp-content\/uploads\/2018\/04\/lostindoc.jpg"},"_links":{"self":[{"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/posts\/11867"}],"collection":[{"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/comments?post=11867"}],"version-history":[{"count":14,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/posts\/11867\/revisions"}],"predecessor-version":[{"id":11911,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/posts\/11867\/revisions\/11911"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/media\/11903"}],"wp:attachment":[{"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/media?parent=11867"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/categories?post=11867"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/analystik.ca\/blogue\/wp-json\/wp\/v2\/tags?post=11867"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}