Pourquoi exactement l'hôpital?

Pourquoi pas? Ceci est un bon exemple. Le projet est partout un projet: plus ou moins les mêmes étapes, le même schéma de gestion, la gestion documentaire, la gestion des risques, le contrôle qualité, etc. Partout, il y a des exigences en termes d'équipement, de locaux et de logiciels. Vous vous demandez quelles peuvent être les exigences pour les locaux du système d'information? C'est très simple: l'emplacement des postes de travail de l'opérateur, du serveur - les deux nécessitent la climatisation. Voici les exigences pour les locaux. Et presque personne ne doute maintenant que l'hôpital ait besoin d'un logiciel. Si vous voulez vous tenir au courant, vous devrez créer un établissement médical automatisé avec des dossiers médicaux électroniques, où les médecins feront un examen avec des tablettes et, par exemple, les infirmières marqueront les toilettes lavées non pas sur la feuille, mais au téléphone. Il y aura de nombreuses exigences logicielles dans ce cas. Et dès que le logiciel sera nécessaire, il faudra installer le serveur, mettre l'administrateur et les opérateurs quelque part. Tout est interconnecté.

Nous avons choisi un projet de construction car il est plus facile de lui montrer comment concevoir une IP. Le système d'information est caché quelque part à l'intérieur, nous ne le voyons pas, et les murs sont ici devant nous: incurvés et obliques, avec des couloirs sans issue, car le projet a été fait à genoux, et le client a changé ses exigences cent fois lors de la pièce.

Code de programme à l'intérieur (mais personne ne le voit)

Qu'est-ce qu'un hôpital doit en faire si nous développons un logiciel?

Et le voici, chers développeurs, cadres, analystes, testeurs.

Pas le logiciel que vous développez ... Prenez Android, c'est un logiciel. Et si, par exemple, vous avez un système de comptabilité, vous avez déjà affaire non seulement à un logiciel, mais à un SYSTÈME D'INFORMATION.

La différence est évidente. Si vous avez acheté un téléphone, tout est simple: allumez-le, un homme vert (Android) démarre, utilisez-le. Et si vous avez acheté un boîtier avec un logiciel de comptabilité, il est clair que vous avez maintenant besoin de serveurs, vous devez configurer le réseau, configurer les postes de travail, former les employés, intégrer le système avec d'autres adresses IP d'entreprise et piloter le système en mode test. Oui, et les comptables doivent être en quelque sorte persuadés de passer au nouveau logiciel, ils ne sont pas tous prêts à innover. En général, dans tout projet informatique, 10-20% est informatique, et tout le reste est des mesures organisationnelles et administratives, enfin, très dense, des bijoux, travaillez avec le personnel.

Système d'information (est-ce juste un logiciel?)

Et enfin, nous rappelons la définition d'un système des années 90 lointaines, que personne n'a annulé:

Système automatisé: un système composé de personnel et d'un ensemble d'outils d'automatisation pour ses activités qui met en œuvre la technologie de l'information pour effectuer des fonctions établies.

GOST 34.003-90. Technologie de l'information. Un ensemble de normes pour les systèmes automatisés. Systèmes automatisés. Termes et définitions.

Autrement dit, la propriété intellectuelle est en premier lieu les personnes, plus la technologie qui aide à automatiser leurs activités, et non l'inverse.

Comment concevoir un hôpital

Imaginez que vous êtes un organisme de construction, un client vient à vous et demande de construire un hôpital dans un tel endroit. Vous courez immédiatement pour poser des briques ou ...? Si vous regardez à quelle fréquence les systèmes d'information sont créés, alors c'est le cas: les interprètes commencent immédiatement à «interférer avec le béton et acheter des paquets de verre». Comme ça ne fonctionnera pas de cette façon - nous allons reconstruire! Nous reconstruirons jusqu'à ce que nous obtenions le résultat souhaité.

Cependant, si vous êtes une organisation sérieuse, offrez d'abord au client un DESIGN pour la construction. Êtes-vous d'accord? Et pourquoi est-ce mal avec le système d'information? Peut-être que ce n'est pas la différence entre la construction et le développement de logiciels, mais que dans le cas du même hôpital, ils pensent beaucoup, planifient, puis construisent, et ils développent d'abord et pensent ensuite les logiciels? N'est-ce pas la raison pour laquelle vous entendez beaucoup parler des programmeurs krivoruky, mais rien des mêmes travailleurs migrants sur un chantier de construction? Les constructeurs travaillent sur le projet, contrairement aux développeurs.

C'est toujours comme ça sans projet, même s'il n'est pas visible

Nous examinons maintenant plus en détail le processus de conception. Il comporte plusieurs étapes. Pourquoi devons-nous passer par plusieurs étapes, pourquoi ne pas le faire en même temps? Pour plus de clarté, je vais donner un exemple d'école ... Combien d'années à l'école étudient l'opération de multiplication? Vous dites un ou deux mois et vous aurez fondamentalement tort. Oui, comment multiplier 5 par 6, passer en une semaine. Un certain temps est enseigné à la table de multiplication. Et la multiplication des fractions, des nombres avec un degré, des logarithmes, des expressions entre parenthèses, des nombres complexes, augmentant à un degré combien de personnes étudient? Presque toutes les années scolaires! Il s'avère que nous étudions chaque année la même multiplication sous différents angles.

Et pourquoi cela n'est-il pas étudié en première année?

Ainsi, tout processus d'apprentissage et de conception est cyclique. Tout d'abord, nous avons obtenu des concepts généraux sur les nombres, puis nous avons appris à effectuer des actions simples avec eux, puis nous avons appris sur les fractions et appris à travailler avec eux, etc.

Tout d'abord, nous avons réalisé quel problème devait être résolu avec l'aide du système d'information. Ensuite, nous avons déterminé le cercle des tâches à résoudre, compris ce que le système devait faire, quelles actions le personnel devait effectuer. Ils ont ensuite réfléchi à COMMENT le système devrait accomplir les tâches définies précédemment. Vous pouvez ignorer ces étapes, il vous suffit de revenir en arrière et de tout refaire: mesurez sept fois et coupez une fois beaucoup plus rapidement que l'inverse, et moins de matière restera.

Nous donnons un autre exemple. Vous êtes au sommet de la montagne avec des jumelles solides et essayez de faire un itinéraire de descente détaillé. Dans les oculaires, vous pouvez voir chaque caillou sur le chemin, chaque flaque d'eau. Mais voici ce chemin et s'il mène au sommet avec des jumelles n'est pas visible: il n'y a pas de plan général. Un grimpeur raisonnable décrira d'abord les chemins de descente à l'œil nu, puis ils seront examinés sous un fort grossissement. Dès que vous plongez dans les détails, vous perdez votre vision générale du projet. En prenant la lunette immédiatement, vous décrivez idéalement 10 fonctions, tout en oubliant les 40 autres, et ne les mentionnez généralement pas.

On le voit bien, mais seulement une petite partie

La complexité de la conception par phases est qu'au début du processus, vous devez utiliser des concepts abstraits. Je veux donc «sentir» quelque chose de prêt, et ne pas parler de certaines exigences, fonctions, tâches, processus. Dessiner une interface utilisateur immédiatement est plus simple, mais il est également plus facile de manquer au moins la moitié des exigences. Si, dans un premier temps, nous dressons une liste détaillée des opérations que l'utilisateur doit effectuer lorsqu'il travaille avec l'un ou l'autre formulaire d'écran, le concepteur n'aura qu'à dessiner, et non à fantasmer, comme c'est souvent le cas.

Passons enfin aux étapes de conception.

1. Élaboration des exigences générales

Disons que vous êtes designer. Un client vient à vous, «envoyé» par des constructeurs responsables. Le client vous demande naturellement de développer un projet hospitalier. Vous courez au Kuhlmann et ... Eh bien, c'est de l'antiquité - lancez ArchiCAD et dessinez.

Mais bien sûr, cela ne vous concerne pas. Vous êtes un professionnel et commencez à poser un tas de questions «stupides». Et le plus important d'entre eux - pourquoi avez-vous besoin de construire un hôpital? Quel est le but de la construction? Si l'objectif n'est pas clair, vous ne pourrez pas répondre à la question, que ce soit un grand hôpital ou un petit, de quel profil, qu'équipé. Malheureusement, les clients disent souvent beaucoup de choses intéressantes, à l'exception de l'essentiel - quel est leur but. Ici, il est nécessaire de les "retirer" en premier lieu. Et vous devriez poser une question. Le client lui-même n'est pas un spécialiste, il a une idée, et sur ce point, il voit son rôle rempli. Il ne comprend pas le chemin qu'il faut pour réaliser son idée. En règle générale, le client attend un bon vieux miracle: venir au bord de la mer, jeter un filet (payer de l'argent), attraper un poisson, et elle satisfera son désir ... Mais cela se passe comme dans une blague sur un homme riche qui, ayant attrapé un poisson rouge, a demandé de réaliser un désir: " Je veux que tout soit avec moi! » "Pas de problème," répondit le poisson, "vous aviez tout ..."

Pour comprendre l'objectif du projet, il ne suffit pas de faire quelques phrases avec un ensemble de phrases standard. L'objectif d'un projet est généralement déterminé sur la base de l'opposition: ils décrivent le modèle d'information existant (par exemple, les gens sont assis dans les archives et trient les documents), puis ses lacunes (en raison du manque d'automatisation, 10 personnes sont impliquées dans les archives, ce qui est clairement redondant, d'autres départements ne peuvent pas recevoir pendant des semaines à partir des archives les informations dont ils ont besoin, etc.) et proposer une solution (pour introduire un logiciel qui permettra d'effectuer un certain nombre d'opérations en mode automatisé, les opérations doivent être répertoriées). Si un type de service complètement nouveau est introduit sur le marché, il faut alors étudier le marché existant et «critiquer» les outils qui s'y trouvent, puis proposer une solution.

De plus, à ce stade, il est nécessaire de déterminer quelles exigences législatives doivent être prises en compte, comment exécuter légalement certaines opérations, comment le nouveau service sera monétisé, comment il est prévu d'entrer sur le marché, comment intéresser les participants externes au nouveau système.

En d'autres termes, un modèle économique doit être élaboré. D'une part, ce n'est pas la tâche des développeurs, mais, d'autre part, sans une définition claire de l'objectif et comment le mettre en œuvre, il n'est pas clair quelles tâches le système doit résoudre. Et si le client lui-même n'a pas encore clairement formulé ce dont il a besoin, il est peu probable qu'il soit satisfait d'au moins un certain résultat.

2. Choisir un concept de système

À ce stade, il est nécessaire de choisir des solutions techniques générales avec lesquelles les exigences formulées à l'étape précédente peuvent être satisfaites. Qu'il s'agisse d'une application web ou d'un client natif, lourd ou d'une base de données fine et centralisée ou d'un SGBD relationnel distribué ou noSQL, monolith ou microservices, Java ou Python. Souvent, ces problèmes sont oubliés pour être discutés à temps, puis il s'avère que l'un des programmeurs a choisi indépendamment un certain outil, et au final cette solution ne permet pas d'atteindre l'objectif.

3. Élaboration du mandat

Composé des exigences générales de l'hôpital, a choisi le concept. "Eh bien", dira le client, "maintenant tout est clair, vous pouvez dessiner." Est-ce possible? Les exigences sont générales, elles doivent être détaillées. Par exemple, dans la première étape, vous avez déterminé qu'il devrait y avoir un laboratoire d'analyses sanguines. Mais quel type d'équipement y aura-t-il, combien consomme-t-il de l'électricité, de l'air comprimé (et si?), Avez-vous besoin de lampes à quartz pour la désinfection, de tables de laboratoire, de ventilation? Sans cela, il sera difficile de concevoir. Ceci est le premier. Et deuxièmement, il est nécessaire de prescrire un plan de construction d'un hôpital, de préparation et de mise en service.

Pour le Système d'Information, le développement des TOR ( Termes de Référence ) est la partie centrale du projet. Le mandat décrit:

1. CE QUE le système devrait faire.
2. Quelle devrait être la structure globale du système.
3. Comment créer un système.

Autrement dit, le mandat contient des exigences fonctionnelles et non fonctionnelles, ainsi que des exigences pour les étapes de développement, la livraison, l'acceptation, la documentation. Dans les TdR, il convient également de décrire brièvement les processus que nous automatisons réellement.

Lorsque vous décrivez les fonctions du système (et c'est la partie centrale du mandat), il convient de le comprendre - nous donnons des exigences pour ce que le système doit faire, et non COMMENT. Pour vous, l'étendue de la couverture doit être plus importante que la profondeur. Par exemple, lors de la première étape (préparation des exigences générales), nous avons identifié la nécessité d'une fonction de blocage de la connexion utilisateur. L'énoncé de travail indique que le compte est bloqué s'il n'est pas utilisé pendant 90 jours ou après 6 tentatives de connexion infructueuses, l'accès peut être limité par l'administrateur pendant une certaine période de temps, lorsque vous essayez d'entrer un utilisateur bloqué, un message doit être affiché, etc. Et dans le projet technique (prenons de l'avance sur nous-mêmes), nous allons dessiner une maquette de la carte de l'utilisateur avec le drapeau de verrouillage et la date de déverrouillage, écrire un script pour se connecter au système, qui vérifiera le blocage, déverrouillera automatiquement après une période définie, blocage en cas de tentatives de connexion infructueuses; déterminons ce qui est fait côté client et ce qui est fait côté serveur.

Je voudrais démystifier plusieurs mythes liés au développement de spécifications techniques .

Mythe un: les savoirs traditionnels ne contiennent des exigences que pour l'entrepreneur.

Non, les savoirs traditionnels sont de savoir comment créer un système, et il y a des sections dans les termes de référence dans lesquelles la répartition des responsabilités peut être décrite.

Mythe deux: Dans le mandat, il y a souvent beaucoup «d'eau».

En effet, les savoirs traditionnels contiennent souvent des informations générales sur le système, mais elles sont nécessaires. Par exemple, nous avons discuté et discuté des exigences du système, par conséquent, une équipe s'est rendu compte qu'il était nécessaire de développer une application pour Windows et l'autre pour un navigateur. L'un pensait que le système s'appelait ainsi et l'autre un nom différent. Cela semble être des choses évidentes, mais elles devraient être comprises également par tous les membres de l'équipe et tous les spécialistes impliqués.

Troisième mythe: les exigences relatives au personnel, aux serveurs, aux canaux de communication et aux modes de fonctionnement des administrateurs sont superflues, car elles relèvent de la responsabilité du client.

Premièrement, comme nous l'avons déjà considéré, TK est écrit pour tout le monde à la fois, et deuxièmement, TK décrit comment faire fonctionner le système, et pas seulement le logiciel est écrit. Sinon, il y aura une autre boîte posée sur une étagère avec un disque et des instructions épaisses. Ainsi, la partie organisationnelle des savoirs traditionnels, les exigences non fonctionnelles, n'est pas moins importante que les exigences fonctionnelles.

Nous considérons la préparation des savoirs traditionnels plus en détail dans un article séparé L' élaboration du mandat conformément à GOST 34 est simple et facile .

4. Développement d'un projet technique

Alors, continuez. Voici devant vous (nous avons admis que vous êtes un designer) Termes de référence pour la construction d'un hôpital avec une énorme liste d'exigences. Vous vous asseyez, regardez tristement 100 pages de savoirs traditionnels et ne savez pas par où commencer. Ensuite, l'image commence progressivement à s'éclaircir. Vous pensez: oui, nous avons besoin de tant de mètres sous les salles, tellement sous la cuisine, tant sur l'aire de repos, le laboratoire, les salles de soins infirmiers et ainsi de suite. Ensuite, de nombreux croquis, croquis, options naissent, vous refaites, échangez des pièces, bref, à la recherche du meilleur ratio. Ensuite, allez dans les détails - dessins, dessins, plans: murs, portes, fenêtres, canaux de câbles, câblage, tuyaux, ventilation, sols, matériaux de mur, finitions ... et ainsi de suite, etc. En général, aussi détaillé que possible, décrivez l'apparence et le fonctionnement de l'hôpital une fois la construction terminée.

Lors de l'élaboration d'un projet technique du système d'information, des documents contenant les éléments suivants sont requis: des scénarios détaillés décrivant le fonctionnement et l'interaction du système développé, des utilisateurs et des systèmes connexes; dispositions détaillées de l'interface utilisateur contenant une description du type de données et du comportement de chaque élément d'interface (valeur par défaut, conditions dans lesquelles vous pouvez modifier la valeur du champ, visibilité, actions effectuées par le système lorsque l'élément change, etc.); description des protocoles d'intégration avec les systèmes et équipements associés, formulaires de rapport et description de l'algorithme pour leur formation, la structure des serveurs et des bases de données, s'il y en a plusieurs.

Habituellement, c'est plus que suffisant pour pouvoir donner des documents aux développeurs et obtenir un résultat sain. Des maquettes et des scripts détaillés fournissent suffisamment d'informations sur le comportement du système et de l'interface, ainsi que sur la structure des données. Les développeurs seront placés dans un cadre serré dans lequel vous pouvez fantasmer, mais ne sortiront pas.

J'espère que dans les articles suivants, nous examinerons plus en détail comment effectuer une conception technique de haute qualité, comment développer des maquettes, des scénarios et quels documents doivent être élaborés.

5. Développement de la documentation de travail

La question logique est quelle est la documentation de travail de l'hôpital? Vraiment les instructions pour nettoyer le couloir?! Blague comme une blague, avez-vous besoin de maintenir un système d'incendie? C'est nécessaire. Et les ascenseurs? Et les réseaux informatiques? Et l'approvisionnement en eau? "Eh bien, cela ne s'applique pas au projet de l'hôpital!" - dites-vous. Oui, c'est en partie vrai. Cependant, l'hôpital est livré au client dans son ensemble et tous les systèmes doivent avoir une documentation opérationnelle appropriée. Et pour que le changement soit rapide et réussi, vous dresserez une liste d'exigences, en face de laquelle vous pourrez vérifier si tout est en ordre.

La présence de guides d'utilisateur et d'administrateur pour IP est un standard, avec cela tout est clair. Mais le client pense souvent au dernier moment au processus d'acceptation du système. Et en vain. Pour cela, il existe un excellent document, «Méthodologie de programme et de test», également généralement lié aux documents de travail. Il s'agit d'une sorte de liste de contrôle contenant une description des procédures de vérification. Si ce document est préparé à l'avance (et que le script, comme base, peut être emprunté au projet technique), alors les développeurs auront un critère clair pour accepter leur travail. Vous n'avez pas besoin de vos propres programmeurs ou de sous-traitants pour prouver leur cas - il y a un scénario, il doit être élaboré. Et il n'y aura aucun problème avec le client - le fantasme est déjà limité par le document.

Et où est la place pour Agile?

Certaines personnes à deux mains derrière Agile (ou d'autres méthodes de développement "flexibles"), d'autres s'y opposent fortement. L'auteur de l'article a sa propre opinion: Agile est très bon, mais au point. Et ils l'utilisent généralement à d'autres fins.

, Agile, , , , ? Non? , , ? , Agile? , Agile , . . — (, , , ).

Le client pense: et combien vont-ils me conduire autour du nez?

Deuxièmement, Agile est bon en innovation, où le type de résultat que vous souhaitez obtenir n'est pas clair, ou la manière de l'atteindre n'est pas claire. C'est ce qu'on appelle OCD, développement expérimental. Ou même R&D - recherche et développement. Dans toute usine, il y a un atelier expérimental où les prototypes sont obtenus avec un fichier, remodelant plusieurs fois. Imaginez que vous devez redévelopper l'écran tactile, tous les gestes et comportements. Ici, vous devez vraiment essayer et essayer, vous ne pouvez pas décrire le comportement à l'avance. Mais êtes-vous souvent confronté à des tâches de ce type? Une distinction doit être faite entre l'ingénierie et la recherche. Fondamentalement, nous sommes des ingénieurs en conception de systèmes d'information.

Troisièmement, dans un grand projet, il peut y avoir des étapes où le TOC est requis, puis Agile pour aider. Personne ne prend la peine d'utiliser des sprints au niveau de la planification opérationnelle. Au contraire, c'est une technologie très pratique: prévoyez une semaine ou deux et surveillez constamment le résultat. Au niveau stratégique, la planification en cascade, au niveau tactique, itérative. Et pas de contradictions!

, , «» Agile, ( , ). : . , . () , - , , . .

?

Il existe de nombreux livres sur ce sujet. Épais et pas si. Mais un livre est toujours une expérience extraterrestre. Et vous avez un caractère différent, une situation formidable et un projet. Il existe un tel système TRIZ - la théorie de la résolution de problèmes inventifs. Son auteur, Altshuller, essaie d'expliquer les étapes à suivre pour inventer quelque chose. Il s'avère? Généralement non. , , . -, , . , , () , . .

, 34- . , . ( ) . .

, . .

: .

:

• 34 .
• .
• .