mindmap du contenu teknibiz dans ayoa

Cet article est aussi disponible en: English (Anglais)

Les changements apportés aux systèmes sont dictés par l’évolution des conditions, ce qui exige que la documentation du système soit maintenue conformément à la stratégie. Mais être capable d’adapter les systèmes à l’environnement changeant, c’est aussi documenter l’expérience de gestion.

Le Processus de Spécification

Les changements de système commencent par l’entreprise. L’enjeu principal du développement de systèmes est la traduction des exigences métiers en spécifications techniques. Les gens d’affaires ne peuvent pas être experts en matière technique et les techniciens ne peuvent pas être des experts en gestion d’entreprise. C’est pourquoi nous analysons les exigences fonctionnelles.

L’utilisation d’outils de spécification graphique tels que UML dans l’analyse des systèmes est le meilleur moyen de surmonter le problème de langage. UML est une notation qui peut décrire à la fois le résumé et le détail des fonctionnalités requises. Nous utilisons Enterprise Architect de Sparx Systems. Nous utilisons Enterprise Architect de Sparx Systems.

La nécessité d’une documentation système

Les projets réunissent des experts de la mise en œuvre et des personnes connaissant parfaitement les exigences. Et la qualité du système dépend de leur compréhension mutuelle. Pour faciliter cette compréhension, nous documentons en UML. Il s’agit d’un langage graphique compréhensible par toutes les parties.

La documentation système est important pour créer un référentiel.

Gestion de Projet

Les méthodes de gestion de projet telles que PRINCE (PRojects In Controlled Environments) et Kepner Tregoe démontrent que la gestion de projet nécessite un contrôle.

Le risque de gaspillage de ressources, de temps et le nombre de projets échoués justifient cela. Certaines méthodes de gestion de projet elles-mêmes sont trop compliquées.

Dans le développement de logiciels, il existe également diverses approches telles que la méthode de la cascade (itérations), la modélisation des tests.

Gestion de la Qualité

Le processus de développement centrale (codage, gestion des infrastructures, choix techniques) lui-même est impliqué.

Il y a plusieurs niveaux de contrôle, qui augmentent les coûts et la complexité globale du système. Il y a sûrement quelque chose qui manque si nous avons besoin d’autant de contrôle.

Les méthodes Agiles visent à résoudre ce problème de trop documentation en rapprochant des clients entreprises et les développeurs. Le processus de spécification donc inclus plus de discussions. Les schémas sont alors utiles pour documenter la compréhension mutuelle des modèles de systèmes.

La Stratégie d’Entreprise

La turbulences des marchés, des économies, des systèmes politiques conduisent à une approche à court terme. Celles-ci à leur tour rendent la réflexion stratégique plus difficile et conduit à une gestion réactive.

Autrefois, on établissait un plan quinquennal, mais celui-ci a été réduit à trois ans ces derniers temps. Voir encore plus court terme face à l’incertitude. Parfois, une stratégie commerciale consiste simplement à voir clairement l’avenir sur l’échelle d’un an. Qu’est-il arrivé à la réflexion stratégique?

Comment les entreprises peuvent-elles investir dans un climat d’incertitude? J’appelle à un retour à des conditions stables et confiantes, mais avec cette innovation qui conduit au changement géré.

Documenter l’expérience de gestion

Une partie du matériel ici consiste à documenter l’expérience de gestion, à fournir des lignes directrices et des conseils, des techniques et des recommandations pour l’utilisation de logiciels de gestion d’entreprise.

L’objectif est de partager sur les nombreuses utilisations du mindmapping, de l’analyse des systèmes et de la modélisation visuelle.

Ayant passé de nombreuses années dans les technologies de l’information, j’ai une vision du monde comme un ensemble de systèmes.

J’ai initialement publié une partie de mon expérience en tant que professionnel de l’informatique dans le développement de systèmes sur un pbwiki que j’ai appelé docbase.

Evernote pour alimenter le site

L’idée était d’utiliser Evernote pour alimenter un référentiel en ligne de connaissances métiers. J’ai initialement choisi un format wiki sur pkwiki.

Documentant l’expérience en gestion dans une base de données en ligne
Documentant l’expérience en gestion dans une base de données en ligne

Une partie de l’expérience consistait à déterminer en quoi les wikis diffèrent des blogs, en tant que média. Les blogs sont en grande partie basés sur des articles, une fois que les articles en place, ceux-ci n’évoluent guère. Un wiki, cependant, est une invitation à améliorer continuellement le contenu.

J’étais intéressé de voir dans quelle mesure les mises à jour incrémentielles et l’historique des mises à jour du wiki étaient utiles.

Les systèmes wiki sont maintenant répandus. Notion est un bon exemple d’un système qui fonctionne comme un wiki en mode collaboratif. Il permet plusieurs utilisateurs, commentaires et résolution de commentaires.

J’ai utilisé Ayoa pour organiser et hiérarchiser le contenu stocké dans Evernote. J’ai essayé une approche similaire avec Kanbanote pour filtrer et trier les Evernotes . En fin de compte, c’est peut-être Microsoft Access qui fait le travail d’organisation des thèmes.

J’ai documenté plusieurs études de cas d’analyse de systèmes, dont une sur le système de sécurité sociale Français.

Projet de documentation docbase

J’ai initialement mis en place ce site sur un wiki pbworks pour documenter l’expérience des professionnels de l’informatique dans les projets de développement de systèmes, la gestion de la qualité et des services. J’avais également l’intention de fournir des critiques et des conseils techniques sur les logiciels préférés, les sites intéressants et les conseils et résultats informatiques généraux.

Utilisé à l’origine comme un wiki suite à une recherche d’un espace de travail collaboratif en ligne tel que Huddle.

Une partie de l’expérience consistait à déterminer comment, en tant que média, le wiki diffère des blogs, l’hypothèse étant que si les blogs sont en grande partie basés sur des articles, les articles une fois en place n’évoluent pas. Dans un wiki, l’approche est d’améliorer le contenu en permanence.

Nous espérons documenter des leçons apprises pendant des années d’expérience pour un public éducatif ou pour référence dans Evernote.

Evernote et Enterprise Architect

J’ai voulu créer un référentiel technique, en commençant par quelques directives de gestion, qualité et problèmes techniques que j’ai rencontrées au fil des ans.

Par exemple, j’étais intéressé de voir la mise à jour incrémentielle du wiki par opposition au format de base de données linéaire.

L’idée de documenter l’expérience de gestion a commencé avec Evernote. L’idée qu’un système pourrait capturer l’expérience et la rassembler et pour gagner du temps la prochaine fois qu’un problème similaire se pose.

Cependant, alors qu’Evernote produisait un grand nombre de notes, il était difficile de les agréger. J’ai également essayé d’agréger des notes avec moh.io, avec kanbanote et #Ayoa avec plus ou moins de succès. #Obsidian est maintenant l’outil de choix pour cette agrégation.

L’objectif final était de rassembler l’expérience et d’en tirer des lignes directrices et des conseils, des techniques et des recommandations pour l’utilisation de logiciels de gestion. En fin de compte, le voyage a consisté à essayer un bon nombre de logiciels différents dans différentes configurations.

Obsidian semble maintenant fournir la fonctionnalité recherchée dans tant d’autres outils. Voir un [critique of Evernote] qui discute plus en détail des limites d’Evernote et du chemin de développement tortueux emprunté par l’entreprise Evernote qui, je crois, conduira à sa disparition.

J’ai commencé le projet #Docbase sur PBworks, mais je l’ai intégré à d’autres sites et à Evernote. Ici, je suis tenté d’essayer à nouveau. J’espère être plus prolifique et pourtant rester raisonnablement structuré.


By marklewis

Mark Lewis est un ancien développeur Access, analyste commercial devenu traducteur technique, bilingue en français et anglais

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.