Les experts expliquent comment apprendre à déterminer correctement les délais d'exécution des travaux. Planification (informatique) - Planification (informatique) directeur technique du centre de technologies et solutions innovantes "Jet Infosystems"

Une version commutée de l’algorithme précédent est l’algorithme avec le temps d’exécution restant le plus court. Selon cet algorithme, le planificateur sélectionne à chaque fois le processus avec le temps d’exécution restant le plus court. Dans ce cas, il est également nécessaire de connaître à l’avance l’heure d’achèvement de la tâche. Lorsqu'une nouvelle tâche arrive, son temps d'exécution total est comparé au temps d'exécution restant de la tâche en cours. Si le temps d'exécution de la nouvelle tâche est plus court, le processus en cours est suspendu et le contrôle est transféré à la nouvelle tâche. Ce schéma vous permet de répondre rapidement aux demandes courtes.

Planification à trois niveaux

Les systèmes de traitement par lots permettent une planification à trois niveaux, comme le montre la figure. Lorsque de nouvelles tâches arrivent dans le système, elles sont d'abord placées dans une file d'attente stockée sur disque. Entrée planificateur d'accès sélectionne une tâche et la transfère au système. Les tâches restantes restent dans la file d'attente.

Dès qu'un travail entre dans le système, un processus correspondant est créé pour celui-ci et il peut immédiatement commencer à rivaliser pour l'accès au processeur. Cependant, il est possible qu'il y ait trop de processus et qu'ils ne tiennent pas tous en mémoire, certains d'entre eux seront alors paginés sur le disque. Le deuxième niveau de planification détermine quels processus peuvent être stockés en mémoire et lesquels peuvent être stockés sur disque. C'est ce qu'il fait planificateur de mémoire .

Le planificateur de mémoire examine périodiquement les processus sur le disque pour décider lesquels déplacer en mémoire. Parmi les critères utilisés par l'ordonnanceur figurent les suivants :

1. Depuis combien de temps le processus a-t-il été transféré sur le disque ou chargé à partir du disque ?

2. Depuis combien de temps le processus utilise-t-il le processeur ?

3. Quelle est la taille du processus (les petits processus n'interfèrent pas) ?

4. Quelle est l’importance du processus ?

Le troisième niveau de planification est chargé de permettre aux processus à l'état prêt d'accéder au processeur. Lorsque nous parlons de « planificateur », nous entendons généralement Planificateur de processeur . Ce planificateur utilise n'importe quel algorithme adapté à la situation, avec et sans interruption. Nous avons déjà examiné certains de ces algorithmes, et nous en connaîtrons d'autres plus tard.

Planification dans des systèmes interactifs.

Planification cyclique.

L’algorithme de planification cyclique est l’un des plus anciens, des plus simples, des plus justes et des plus fréquemment utilisés. Chaque processus se voit attribuer une certaine quantité de temps processeur, ce que l'on appelle la tranche de temps. Si le processus est toujours en cours à la fin de la tranche de temps, il est terminé et le contrôle est transféré à un autre processus. Bien entendu, si le processus se bloque ou se termine prématurément, une transition de contrôle se produit à ce stade. La mise en œuvre de la planification round-robin est simple. Le planificateur n'a besoin que de maintenir une liste de processus dans un état prêt. Lorsqu'un processus a atteint sa limite de temps, il est envoyé en fin de liste.

Le seul aspect intéressant de cet algorithme est la longueur du quantum. Passer d'un processus à un autre prend un certain temps - il est nécessaire de sauvegarder et de charger des registres et des cartes mémoire, de mettre à jour des tables et des listes, de sauvegarder et de recharger le cache mémoire, etc. La conclusion peut être formulée comme suit : un quantum trop petit conduira à des changements fréquents de processus et à une faible efficacité, mais un quantum trop grand peut entraîner une réponse lente aux requêtes interactives courtes. Une valeur quantique d'environ 2 0 à 5 0 ms constitue souvent un compromis raisonnable.

Planification des priorités.

La planification à tour de rôle repose sur l’hypothèse importante que tous les processus sont égaux. Dans le cas d’un ordinateur comptant un grand nombre d’utilisateurs, cela peut ne pas être le cas. Par exemple, dans une université, les doyens devraient être servis en premier, puis les professeurs, les secrétaires, les nettoyeurs et ensuite seulement les étudiants. La nécessité de prendre en compte ces facteurs externes conduit à une planification des priorités. L'idée de base est simple : chaque processus se voit attribuer une priorité et le contrôle est transféré au processus prêt ayant la priorité la plus élevée.

Plusieurs files d'attente.

L'un des premiers planificateurs prioritaires a été implémenté dans le système CTSS (système compatible à temps partagé). Le principal problème du système CTSS était que la commutation de processus était trop lente, puisque l'ordinateur IBM 7094 ne pouvait contenir qu'un seul processus en mémoire. Chaque changement signifiait décharger le processus en cours sur le disque

et lire le nouveau processus à partir du disque. Les développeurs de CTSS ont rapidement compris que l'efficacité serait plus grande si les processus limités par le processeur bénéficiaient d'une tranche de temps plus longue que s'ils recevaient de petites tranches de temps, mais souvent. D'une part, cela réduira le nombre de transferts de la mémoire vers le disque, et d'autre part, cela entraînera une détérioration du temps de réponse, comme nous l'avons déjà vu.

En conséquence, une solution avec des classes prioritaires a été développée. Les processus de la classe de priorité la plus élevée se sont vu attribuer un quantum, les processus de la classe suivante se sont vu attribuer deux quantiques, les processus de la classe suivante se sont vu attribuer quatre quantums, etc. Lorsqu'un processus avait utilisé tout le temps qui lui était imparti, il était déplacé vers une classe inférieure. classe.

À titre d'exemple, considérons un processus qui doit calculer plus de 100 quanta. Tout d’abord, il recevra un quantum, puis il sera pompé sur le disque. La prochaine fois, il obtient 2 quanta, puis 4, 8,16, 32, 64, même si sur 64 il n'en utilise que 37. Dans ce cas, seuls 7 transferts (chargement initial compris) seront nécessaires au lieu des 100 qui seraient nécessaires. nécessaires à l’aide de l’algorithme round-robin. De plus, à mesure qu'il s'enfonce dans la file d'attente des priorités, le processus démarrera de moins en moins souvent, ce qui donnera au processeur des processus plus courts.

« Le processus le plus court est le suivant »

Étant donné que l’algorithme Shortest Task First minimise le temps d’exécution moyen dans les systèmes de traitement par lots, on souhaiterait également l’utiliser dans les systèmes interactifs. Dans une certaine mesure, cela est possible. Les processus interactifs suivent le plus souvent le modèle « attendre une commande, exécuter une commande, attendre une commande, exécuter une commande... » Si vous traitez l'exécution de chaque commande comme une tâche distincte, vous pouvez minimiser la réponse moyenne globale. temps en exécutant d'abord la tâche la plus courte. Le seul problème est

est de comprendre lequel des processus d’attente est le plus court.

Une méthode est basée sur l’estimation de la longueur du processus en fonction du comportement précédent du processus. Dans ce cas, le processus ayant le temps estimé le plus court est lancé. Supposons que le temps d'exécution attendu de la commande soit T 0 et que le temps d'exécution attendu suivant soit T 1 . Il est possible d'améliorer l'estimation du temps en prenant la somme pondérée de ces temps aT 0 + (1 - a)T 1 . En choisissant la valeur appropriée pour a, nous pouvons faire en sorte que l'algorithme d'estimation oublie rapidement les exécutions précédentes ou, inversement, s'en souvienne pendant longtemps. En prenant a = 1/2, on obtient une série d'estimations :

T 0, T 0/2 + T 1/2, T 0/4 + T 1/4 + T 2/2, T 0/8 + T 1/8 + T 2/4 + T 3/2.

Après trois exécutions, le poids de T 0 dans l'estimation diminuera à 1/8.

La méthode d'estimation de la valeur suivante d'une série au moyen d'une moyenne pondérée de la valeur précédente et de l'estimation précédente est souvent appelée vieillissement. Cette méthode est applicable dans de nombreuses situations où une estimation à partir des valeurs précédentes est nécessaire. La manière la plus simple de mettre en œuvre le vieillissement est à a = 1/2. A chaque étape, tu as juste besoin

ajoutez une nouvelle valeur à l'estimation actuelle et divisez la somme en deux (en décalant vers la droite de 1 bit).

Planification garantie.

Une approche fondamentalement différente de la planification consiste à faire de véritables promesses aux utilisateurs, puis à les tenir. Voici une promesse facile à dire et facile à tenir : si vous partagez un processeur avec n utilisateurs, vous recevrez 1/n de la puissance du processeur.

Et dans un système avec un utilisateur et n processeurs en cours d’exécution, chacun obtiendra 1/n cycles de processeur.

Pour tenir cette promesse, le système doit suivre l'allocation du processeur entre les processus à partir du moment où chaque processus est créé. Le système calcule ensuite la quantité de ressources CPU à laquelle le processus a droit, comme le temps écoulé depuis la création divisé par n. On peut désormais calculer le rapport entre le temps accordé au processus et le temps auquel il a droit. La valeur résultante de 0,5 signifie que le processus n'a reçu que la moitié du montant qui lui est alloué, et 2,0 signifie que le processus a reçu deux fois plus qu'il était censé le faire. Ensuite, le processus avec le plus petit rapport est démarré, jusqu'à ce que

il ne deviendra pas plus grand que celui de son voisin le plus proche.

Planification de loterie.

L'algorithme est basé sur la distribution de billets de loterie aux processus d'accès à diverses ressources, dont le processeur. Lorsque le planificateur doit prendre une décision, un billet de loterie est sélectionné au hasard et son propriétaire a accès à la ressource. En termes d'accès au processeur, la « loterie » peut avoir lieu 50 fois par seconde, le gagnant obtenant 20 ms de temps CPU.

Les processus plus importants peuvent recevoir des tickets supplémentaires pour augmenter les chances de gagner. S'il n'y a que 100 tickets et que 20 d'entre eux sont en cours de traitement, cela obtiendra 20 % du temps de traitement. Contrairement au planificateur de priorités, dans lequel il est très difficile d'évaluer ce que signifie, disons, la priorité 40, dans la planification de loterie, tout est évident. Chaque processus recevra un pourcentage de ressources approximativement égal au pourcentage de tickets dont il dispose.

La planification de loterie présente plusieurs propriétés intéressantes. Par exemple, si lors de la création un processus reçoit plusieurs tickets, alors lors de la prochaine loterie, ses chances de gagner sont proportionnelles au nombre de tickets.

Les processus communicants peuvent échanger des billets si nécessaire. Ainsi, si un processus client envoie un message à un processus serveur puis se bloque, il peut transmettre tous ses tickets au processus serveur pour augmenter les chances de démarrage du serveur. Une fois le processus du serveur terminé, il peut renvoyer tous les tickets.

Planification équitable.

Jusqu’à présent, nous avons supposé que chaque processus est contrôlé indépendamment de l’identité de son propriétaire. Par conséquent, si l'utilisateur 1 crée 9 processus et l'utilisateur 2 - 1 processus, alors en utilisant la planification à tour de rôle ou en cas de priorités égales, l'utilisateur 1 obtiendra 90 % du processeur et l'utilisateur 2 seulement 10.

Pour éviter de telles situations, certains systèmes prêtent attention au propriétaire du processus avant de planifier. Dans ce modèle, chaque utilisateur obtient une certaine part du processeur et le planificateur sélectionne un processus en fonction de ce fait. Si dans notre exemple chaque utilisateur avait

promis 50 % du processeur, alors ils obtiendront 50 % du processeur, quel que soit le nombre de processus.

Planification dans des systèmes en temps réel.

Dans les systèmes temps réel, le temps joue un rôle essentiel. Le plus souvent, un ou plusieurs périphériques physiques externes génèrent des signaux d'entrée et l'ordinateur doit y répondre de manière adéquate dans un laps de temps donné.

Les systèmes en temps réel sont divisés en systèmes temps réel durs , ce qui signifie la présence de délais stricts pour chaque tâche (ils doivent être respectés), et systèmes flexibles en temps réel , dans lequel les violations du calendrier sont indésirables, mais acceptables. Dans les deux cas, le programme est divisé en plusieurs processus dont chacun est prévisible. Ces processus sont le plus souvent courts et terminent leur travail en une seconde. Lorsqu'un signal externe apparaît, c'est le planificateur qui doit s'assurer du maintien de l'horaire.

Les événements externes auxquels le système doit répondre peuvent être divisés en périodique(se produisant à intervalles réguliers) et non périodique(se produisant de manière imprévisible). Il peut y avoir plusieurs flux périodiques d'événements que le système doit traiter. Selon le temps nécessaire au traitement de chaque événement, le système peut ne pas être en mesure de traiter tous les événements en temps opportun.

Informations connexes.

Souvent, les développeurs, en particulier ceux inexpérimentés, sont confus lorsqu'on leur demande de fixer des délais pour accomplir les tâches. Cependant, la capacité de planifier est une compétence très utile et nécessaire qui aide non seulement au travail, mais aussi dans la vie. Nous avons décidé de demander à des experts comment apprendre à planifier correctement et à livrer des projets à temps.

De brèves conclusions peuvent être trouvées à la fin de l’article.

Un développeur doit généralement prendre en compte plusieurs paramètres à la fois pour estimer le temps nécessaire pour réaliser une tâche :

1. Expérience dans l’exécution de telles tâches et dans l’utilisation de cette pile technologique. Si vous devez faire quelque chose de fondamentalement nouveau, vous devez être particulièrement prudent dans votre évaluation.
2. Expérience de travail avec ce client. Connaissant le client, vous pouvez prévoir approximativement certaines exigences supplémentaires et l'ampleur des modifications.
3. La qualité du code avec lequel vous travaillerez. C'est le facteur le plus influent, à cause duquel tout peut prendre beaucoup de temps et ne se déroule généralement pas comme prévu. Si le projet a des tests, qu'il n'y a que des dépendances explicites partout et que les fonctionnalités sont bien isolées, tout n'est pas si effrayant. C'est bien pire si vous avez affaire à du code existant sans tests ou à du code surchargé de dépendances implicites. Des choses comme les « fonctions magiques » (quand il est difficile de voir la pile d'appels finale à partir du code) et la duplication de code (quand vous devez modifier plusieurs sections indépendantes pour modifier certaines fonctionnalités) peuvent également compliquer les choses.

Pour apprendre à estimer adéquatement les délais de travail, vous devez constamment vous entraîner. Au début de mon travail, j'ai fait exactement ceci : j'ai estimé le temps nécessaire pour accomplir toute tâche entrante, même si personne ne l'avait demandé, puis j'ai regardé avec quelle précision j'avais réussi à entrer dans mon estimation. Tout en accomplissant la tâche, il a noté quelles actions prenaient plus de temps. Si quelque chose augmentait considérablement la période, je me souvenais de ce moment et j'en tenais compte dans les évaluations suivantes.

A une évaluation objective du temps nécessaire au pur travail, il convient d'ajouter une petite marge pour couvrir les situations de force majeure. Il est souvent évalué en pourcentage de l'achèvement de la tâche principale, mais il est différent pour chacun : certains ajoutent 20 % du temps, certains - 10 % et certains - 50 %.

Il est également utile d’analyser les raisons du non-respect des délais après chaque non-respect grave des délais. Si vous manquez de qualifications, vous devez travailler sur vos points faibles. Si le problème était organisationnel, comprenez ce qui l’a empêché de fonctionner normalement.

Promouvoir Rétrograder

, directeur technique du centre de technologies et solutions innovantes "Jet Infosystems"

Un grand nombre d'articles sont consacrés aux méthodes d'évaluation de l'intensité de travail d'un projet, y compris la durée du travail et les tâches individuelles. Cependant, cela provoque toujours des conflits tant au sein de l'équipe de projet que lors de la communication avec le client.

Le principal assistant en évaluation est l’expérience. Essayez de comparer d'une manière ou d'une autre la nouvelle tâche avec celles déjà effectuées. Si vous rédigez un rapport, regardez combien de temps un rapport similaire a pris dans le passé. Si vous faites quelque chose de nouveau, essayez de le décomposer en parties connues et de les évaluer. Si la tâche est complètement nouvelle, prévoyez du temps pour étudier (mieux encore, coordonnez ce temps avec la personne qui définit la tâche).

Faites attention aux étapes qui l'accompagnent - si vous devez développer un service, l'évaluation doit également inclure des tests unitaires (et peut-être pas seulement des tests unitaires), la préparation des données de test prendra un certain temps. Vous devriez envisager l'intégration avec d'autres services, etc. Prévoyez du temps pour corriger les défauts que vous constatez vous-même ou avec l'aide de testeurs. Beaucoup de temps peut être perdu sur des tâches « invisibles ». Par exemple, il existe une évaluation pour le développement et une évaluation pour les tests, mais le transfert d'un artefact à des fins de test peut impliquer le déploiement de supports. Il est donc important de visualiser mentalement l’ensemble du processus afin de ne rien manquer.

Après avoir déterminé la complexité, il est nécessaire d'inclure de nouveaux travaux dans le calendrier, sans oublier les autres tâches et activités parallèles.

Et n’oubliez pas que les plans sont inutiles, mais que la planification n’a pas de prix. Apprenez à ajuster vos plans en temps opportun, à tenir toutes les personnes impliquées informées et à réagir rapidement afin que les délais non respectés ne surprennent personne.

Promouvoir Rétrograder

Une question à laquelle on ne peut répondre sous une forme courte. Si c’était simple, le problème du non-respect des délais n’existerait pas.

Pour rendre les délais de développement plus prévisibles, nous devons d’abord comprendre les raisons pour lesquelles les programmeurs font constamment des erreurs.

La première raison est que la plupart des tâches effectuées par un programmeur sont uniques à un degré ou à un autre. Autrement dit, le programmeur effectuera très probablement une tâche similaire pour la première fois. Il n’a pas une bonne idée de la durée que prendront ces travaux. S'il s'agit d'un programmeur possédant une solide expérience et qu'il a dû effectuer une tâche similaire, son évaluation sera plus proche de la réalité.

Utilisons une analogie simple : si vous n'avez jamais creusé de fossés, vous ne pouvez pas dire exactement combien de temps il vous faudra pour creuser une tranchée de 30 cm de large, 60 cm de profondeur et 20 mètres de long. Si vous avez déjà creusé, votre estimation du temps de travail sera beaucoup plus proche de la durée réelle des travaux.

La deuxième raison est que les programmeurs sont optimistes par nature. Autrement dit, lorsqu'il envisage une tâche, sélectionne une option de mise en œuvre pour celle-ci et évalue les améliorations, le développeur s'attend à ce que tout fonctionne comme il l'attend. Et il ne pense pas aux problèmes qu’il rencontrera en cours de route. Souvent, il ne peut pas les prévoir. Par exemple, il existe une tâche qu'un programmeur peut implémenter à l'aide d'une bibliothèque de logiciels open source tierce. Au stade de l'évaluation, il l'a trouvé sur Internet, a lu sa description, cela lui convient. Et il a même correctement estimé la quantité de travail qu'il lui faudrait fournir pour intégrer l'utilisation de cette bibliothèque. Mais il n'avait pas du tout prévu qu'une erreur surviendrait dans cette bibliothèque dans l'environnement de son logiciel.

Le développeur devra non seulement intégrer l'utilisation de la bibliothèque dans son code, mais également corriger un bug dans la bibliothèque elle-même. Et souvent, le développeur ne laisse pas le temps de corriger ses erreurs. Les statistiques montrent que les tests et la correction des erreurs peuvent prendre environ 50 % du temps consacré au codage. Ce chiffre dépend des qualifications du développeur, de l'environnement et des pratiques de développement utilisées (par exemple, les tests unitaires réduisent considérablement ce temps et la durée finale/l'intensité de travail de la tâche de développement est moindre).

Si l'on revient à l'analogie avec le creuseur, le creuseur ne s'attendait pas à ce que sa pelle se brise et il devrait passer deux heures à chercher une nouvelle coupe.

La troisième raison concerne les exigences imprévues. Dans aucun autre domaine de la production matérielle, avec lequel les clients aiment tant comparer le développement de logiciels, il n'y a un tel flux de nouvelles exigences. Imaginez le passage d'un creuseur qui a creusé 19 mètres sur 20 et a entendu du client le souhait que le fossé ne soit pas en ligne droite, mais en serpent d'une longueur de bras de 97 centimètres.

Comment faire face à tout cela et comment vivre dans des conditions d’une telle incertitude ? Réduire l’incertitude et constituer des réserves de temps.

Le moyen le plus simple de rapprocher vos attentes de la réalité est d’utiliser la règle empirique ludique de Pi. Après avoir reçu une estimation du développeur (en termes de temps ou d'intensité de travail), vous devez la multiplier par Pi (= 3,14159). Plus le développeur est expérimenté dans l’évaluation, plus ce ratio peut être faible.

La pratique consistant à décomposer le problème initial en petites tâches d’une durée maximale de 4 heures est obligatoire. Plus la décomposition est détaillée, plus il y a de chances que l'estimation soit proche de la complexité/durée réelle.
Si l'on revient à l'allocation de réserve, ce temps devrait être alloué en fin de projet. C'est une mauvaise pratique de faire une réserve et de l'inclure pour chaque tâche. La loi de Parkinson « Le travail occupe tout le temps qui lui est imparti » est strictement respectée.

En résumé, afin de déterminer correctement les délais de réalisation des travaux, les actions suivantes seront utiles :

• effectuer une décomposition du travail, en décomposant la tâche en étapes aussi détaillées que possible ;
• réaliser du prototypage ;
• limiter la mise en œuvre d’exigences auparavant imprévues. Cela ne veut pas dire qu'elles ne doivent pas être réalisées, mais il est conseillé de mettre en évidence ces exigences et de convenir avec le client des modifications du calendrier et du coût de leur mise en œuvre ;
• prendre en compte le temps nécessaire à la stabilisation de la solution ;
• utiliser des pratiques pour améliorer la qualité du code, telles que l'écriture de tests unitaires ;
• constituer une réserve générale.

Eh bien, rappelez-vous que si un fait dépasse votre estimation de 30 %, alors c'est un très bon résultat.

Promouvoir Rétrograder

Pour l'évaluation la plus précise, vous avez besoin d'une expérience en développement réel, et plus particulièrement dans un domaine spécifique. Mais il existe également des règles générales qui vous aideront à éviter les erreurs de planification et les problèmes lors de la livraison du travail au client. Je décrirais ces règles comme ceci.

Tout d’abord, vous devez comprendre le problème. Cela semble évident et n’a pas de lien direct avec les estimations temporelles, mais il s’agit en fait d’un point clé. Même dans les grands projets sérieux, l’un des principaux facteurs d’échec et de retard est le problème de définition des exigences. Pour les développeurs débutants, c'est malheureusement un problème sérieux - ils ne lisent pas les spécifications techniques ou lisent et comprennent de manière très sélective (sur dix points, ils se sont souvenus et en ont complété cinq, et se sont souvenus du reste lors de la soumission du résultat). Il est clair qu’une tâche mal comprise ne peut pas être mise en œuvre correctement à temps.

Il s’agit ensuite d’estimer le temps de développement lui-même. La particularité de la programmation est qu'il n'y a pas de tâches absolument identiques. Cela rend notre travail plus intéressant, mais l’estimation des délais est plus difficile. La décomposition fonctionne bien ici, c'est-à-dire diviser un problème complexe et unique en une séquence de petites sous-tâches familières. Et chacun d’eux peut déjà être évalué de manière tout à fait adéquate en heures. Additionnons les estimations des sous-tâches et obtenons une estimation pour l'ensemble de la tâche.

En règle générale, une telle estimation ne comprend que les coûts liés au codage lui-même. C’est bien sûr la partie la plus importante du développement, mais loin d’être la seule (et souvent pas la plus volumineuse). La réalisation complète de la tâche comprend également la lecture et la clarification du cahier des charges, les rencontres avec les collègues ou le client, le débogage et les tests, la rédaction de la documentation, la livraison du résultat (démonstration au client et modifications éventuelles en fonction de ses commentaires). Seule l'expérience vous dira exactement combien de temps il vous faudra pour réaliser ces actions. Dans un premier temps, il est important, au minimum, de ne pas oublier de les prendre en compte dans les calculs, et vous pouvez demander une estimation approximative du temps à des collègues plus expérimentés.

Ainsi, nous prenons une estimation des coûts de main-d'œuvre pour le codage, ajoutons une estimation des coûts de travail supplémentaire - et nous obtenons l'estimation requise du temps pour terminer la tâche. Mais ce n'est pas tout! Vous devez indiquer la date d'achèvement prévue de la tâche. Ce serait une erreur de simplement diviser les coûts de main d'œuvre (en heures) par 8 heures et de les ajouter à la date du jour. Dans la pratique réelle, un développeur ne travaille jamais (d’accord, presque jamais) à 100 % du temps sur une tâche spécifique. Vous consacrerez certainement du temps à d'autres travaux - importants, mais pas directement liés au principal. Par exemple, aider des collègues, se former, rédiger des rapports, etc. En règle générale, lors de la planification, on estime que 60 à 70 % du temps de travail est consacré directement au projet en cours. De plus, vous devez prendre en compte les éventuels retards qui vous empêcheront de travailler continuellement sur la tâche. Par exemple, si pour cela vous avez besoin d'interagir avec d'autres personnes (collègues, clients), alors tenez compte de leur disponibilité, de leur horaire de travail, etc.

Voici les règles de base qui, à mon avis, aideront le développeur à éviter les problèmes d'estimation et de respect des délais. De plus, l’essentiel est d’accumuler votre propre expérience tant dans la mise en œuvre des tâches que dans l’évaluation. Par exemple, il est très utile, après avoir terminé une tâche, de comparer votre estimation initiale avec les délais réels et de tirer des conclusions pour l'avenir. Et bien sûr, cela vaut la peine d’étudier les expériences des autres. Je recommanderais les livres sur le sujet de S. McConnell « Combien coûte un projet logiciel » et de S. Arkhipenkov « Conférences sur la gestion de projet logiciel ».

Promouvoir Rétrograder

Lors de l’estimation et de la planification des délais, vous devez :

1. Décomposez la tâche en petits éléments fonctionnels de manière à ce que l'on comprenne clairement combien de temps il faudra pour développer chacun de ces éléments.
2. Parallèlement à la décomposition, des questions supplémentaires se poseront certainement concernant des fonctionnalités qui n'ont pas été décrites dans l'énoncé du problème. Il est nécessaire d'obtenir des réponses à ces questions, car elles sont directement liées à l'étendue des travaux et, par conséquent, au calendrier.
3. Ajoutez un certain pourcentage de risques à l’évaluation finale. Ceci est déterminé empiriquement. Vous pouvez par exemple commencer avec des risques de 10 à 15 %.
4. Comprenez combien d'heures par jour un programmeur est prêt à consacrer à l'accomplissement d'une tâche.
5. Nous divisons l'estimation finale par le nombre d'heures que nous allouons par jour et obtenons le nombre de jours nécessaires à la mise en œuvre.
6. Nous nous concentrons sur le calendrier et le nombre de jours requis pour terminer. Nous prenons en compte les week-ends et autres jours où le programmeur ne pourra pas travailler sur la tâche, ainsi que la date de début du travail (le développeur n'est pas toujours prêt à assumer la tâche le même jour). Ainsi, nous obtenons la date de début et de fin des travaux.

Promouvoir Rétrograder

Dans notre entreprise, la planification des tâches passe toujours par plusieurs étapes. Côté business, nous formulons 5 à 6 objectifs stratégiques pour l'année. Ce sont des tâches de haut niveau, par exemple augmenter un paramètre d'un certain pourcentage. Ensuite, différentes divisions de l'entreprise formulent des tâches commerciales pour toutes les équipes informatiques. Les délais pour ces tâches font l'objet d'une première estimation approximative, qui est souvent établie par tous les membres de l'équipe - manager, analyste, développeur et testeur. Une fois que l'entreprise reçoit cette évaluation, elle priorise les tâches en fonction des objectifs stratégiques de l'entreprise. Les objectifs stratégiques transversaux y contribuent ; avec eux, il devient évident que nous travaillons tous pour une cause commune ; une telle situation n'existe pas lorsque quelqu'un ne fait que tirer dans sa propre direction. Nous collectons les sprints de tâches estimées avec précision en termes de délais. Pour certaines équipes, ils sont trimestriels, pour d’autres, ils sont mensuels. Pour plusieurs tâches qui, selon les estimations préliminaires, entreront dans le prochain sprint, les équipes donnent une estimation précise. Les tâches importantes sont divisées en tâches de niveau inférieur, pour chacune desquelles un interprète spécifique est responsable, et c'est lui qui donne une évaluation précise.

A ce stade, il ne faut pas oublier de prévoir une réserve de temps pour corriger les bugs, car seuls ceux qui ne font rien ne commettent pas d'erreurs. Les Product Owners et les clients professionnels le comprennent très bien. En même temps, le temps requis doit être adéquat : personne ne comprendra un développeur qui fixe un délai trop long pour une tâche simple ; il lui sera demandé de justifier sa décision. Le plus difficile est d’expliquer à l’entreprise pourquoi il faut du temps pour refactoriser. Nous sommes reconnaissants à notre entreprise pour le fait que nous y parvenons de temps en temps, car en fin de compte, le refactoring conduit à une simplification de l'infrastructure et à la mise en ordre du code, ce qui augmente la stabilité du système et peut accélérer considérablement le développement. de nouvelles fonctions.

Parfois, des erreurs d’évaluation se produisent encore. À mon avis, il est impossible pour le service de développement des grandes entreprises disposant d'une infrastructure développée d'éviter complètement cela. Dans ce cas, il est important que le développeur informe rapidement son responsable de ce qui se passe, et celui-ci, à son tour, parvient à avertir l'entreprise et à « rejouer » quelque chose dans les plans généraux de l'entreprise. Travailler dans ce mode est bien plus correct que d'essayer frénétiquement de faire en 3 jours ce qui en prend 5, puis de se noyer dans un grand nombre d'erreurs survenues en raison d'une telle précipitation.

Promouvoir Rétrograder

La bonne réponse aux deux parties de la question [comment apprendre à planifier correctement et à livrer un projet à temps - Rouge.] - expérience. Il n’existe pas d’autres moyens de « connaître le Zen ». Selon la théorie de la décision, des conclusions précises ne peuvent être tirées que sur la base de l’analyse d’un certain nombre de données déjà disponibles. Et plus il y a de données, plus la prévision et l’évaluation finales sont précises.

Selon les mots d'Herbert Shaw : « L'expérience est l'école dans laquelle un homme apprend à quel point il était idiot auparavant. » Cela conduit à une conclusion assez simple : si un programmeur a déjà une expérience en corrélation avec la tâche à accomplir, il peut s'appuyer sur elle ; sinon, il peut s'appuyer sur l'expérience de ses « collègues ».

Ensuite, vous devez comprendre que la planification directe des délais est une tâche que les gens gèrent très, très mal, en particulier dans le domaine du développement. Lors de l’estimation des dates d’échéance, il est considéré comme une bonne pratique d’introduire des « facteurs d’ajustement » à l’estimation initiale. Cette métrique peut aller de 1,5 à 3, en fonction de l'expérience du développeur et de l'ensemble des degrés d'incertitude des tâches résolues dans le cadre du projet.

Promouvoir Rétrograder

Il est important de prendre en compte de nombreux facteurs lors de la détermination des délais.

Par exemple, une expérience de travail. Dans quelle mesure comprenez-vous clairement l’ampleur du travail à venir ? Avez-vous déjà fait quelque chose comme ça ? Il est clair que plus il y a d'expérience, plus le travail sera terminé rapidement.

Une spécification technique bien rédigée joue un rôle important dans la détermination des délais. Les choses sont très difficiles dans notre région. Souvent, le client lui-même ne sait pas ce qu'il veut, je conseille donc de passer un jour ou deux de plus, mais de lui donner une idée claire du résultat souhaité. Il est important que cette compréhension soit mutuelle. Et seulement après cela, vous pourrez commencer à négocier le montant et les conditions.

Aussi, incluez toujours les risques. Pour les débutants, je recommande de multiplier le temps de réalisation estimé par deux. Après tout, il vaut mieux livrer un projet plus tôt que prévu et grandir en tant que spécialiste aux yeux du client, plutôt que de le livrer plus tard et de ruiner votre réputation.

Promouvoir Rétrograder

Une recommandation générale est que le développeur doit apprendre à décomposer correctement les tâches, toujours rechercher les pièges possibles, s'appuyer sur sa propre expérience et ne pas oublier d'avertir les clients et les collègues en temps opportun si la tâche ne peut pas être résolue dans le délai imparti. cadre.

Construire un plan clair est beaucoup plus difficile que de déterminer le délai pour accomplir une seule tâche. Dans le même temps, il est important non seulement de livrer le projet à temps, mais également de garantir que le système que vous développez résout correctement les problèmes de l'entreprise. Ici, les équipes informatiques sont aidées par diverses méthodologies de développement logiciel : de RUP et MSF à SCRUM et autres formats Agile. Le choix d'outils est très étendu et nombre de nos clients souhaitent comprendre à l'avance comment nous allons travailler avec eux dans le projet, à quels principes nous adhérons.

D'ailleurs, le thème de l'Agile devient aujourd'hui proche aussi bien des entreprises que des projets individuels du secteur public, puisque les principes de cette méthodologie permettent de mettre en œuvre des projets très rapidement, en gérant les attentes des clients à chaque itération. Par exemple, dans une équipe Agile, il n'y a pratiquement pas de discussions prolongées avec le client. Oubliez les dizaines de pages décrivant des détails techniques inutiles, comme la rapidité avec laquelle une liste déroulante apparaît. Donnez au client la possibilité d'essayer une version intermédiaire du système, il deviendra alors beaucoup plus facile pour vous de vous comprendre.

L'équipe Agile planifie tout ensemble et détermine le niveau de travail optimal qui sera nécessaire pour résoudre un problème particulier. Par exemple, l'une des techniques est appelée « Poker Planning », où chaque participant donne de manière anonyme son évaluation des coûts de main-d'œuvre requis pour une tâche spécifique. Après cela, l'équipe détermine le poids moyen de la tâche en story points ou en heures-homme et répartit les tâches selon le principe « qui aime quoi ». Parallèlement, chaque jour, l'équipe se réunit pour une réunion de 15 minutes, au cours de laquelle chacun discute en quelques minutes de l'état de ses tâches en cours, notamment en signalant les difficultés survenues. L’équipe résout rapidement le problème détecté, afin que le client examine le plus rapidement possible la prochaine étape du travail du programmeur. Les développeurs ne retardent pas l'achèvement des tâches en raison de leur réticence à déranger à nouveau l'équipe ou de vaines tentatives de les résoudre par eux-mêmes, ce qui leur fait perdre un temps précieux. À propos, dans de tels mini-statuts, les développeurs souhaitent montrer leur meilleur côté, montrer que vous abordez votre travail de manière responsable. Cela motive vraiment et s’autodiscipline.

(le temps de travail est inclus jusqu'à ce qu'il soit terminé dans le cas d'une activité périodique, ou jusqu'à ce que le système réponde et donne la première sortie utilisateur dans le cas d'une activité interactive) ; ou maximisation justice(une quantité égale de temps CPU pour chaque processus, ou plus généralement des temps correspondants en fonction de la priorité et de la charge de travail de chaque processus). En pratique, ces objectifs sont souvent en conflit (par exemple, débit par rapport à la latence), de sorte que l'ordonnanceur fera un compromis approprié. La préférence est mesurée par l'un des problèmes mentionnés ci-dessus, en fonction des besoins et des objectifs de l'utilisateur.

OS/360 et successeurs

AIX

Dans AIX version 4, il existe trois paramètres possibles pour la stratégie de planification des threads :

• Premier, premier sorti : une fois qu'un thread avec cette politique est planifié, il s'exécute jusqu'à son terme, à moins qu'il ne soit bloqué, qu'il abandonne volontairement le contrôle du processeur ou qu'un thread de priorité plus élevée devienne distribuable. Seuls les threads à priorité fixe peuvent avoir une politique de planification FIFO.
• Round Robin : ceci est similaire au planificateur de circuit AIX version 3 qui effectue un cycle basé sur des tranches de temps de 10 ms. Lorsqu'un thread PP prend le contrôle à la fin d'un créneau horaire, il se déplace vers la queue de la file d'attente des threads avec la même priorité. Seuls les threads à priorité fixe peuvent avoir une politique de planification Round Robin.
• AUTRE : Cette stratégie est définie par l'implémentation par POSIX1003.4a. Dans AIX version 4, cette stratégie est définie comme équivalente à RR, sauf qu'elle s'applique aux threads à priorité non fixe. Le recalcul de la valeur de priorité d'un thread en cours d'exécution pour chaque interruption signifie qu'un thread peut perdre le contrôle car sa valeur de priorité a augmenté au-dessus de celle d'un autre thread. Il s'agit du comportement d'AIX version 3.

Les threads intéressent principalement les applications qui consistent actuellement en plusieurs processus asynchrones. Ces applications peuvent imposer une légère charge au système si elles sont converties en une structure multithread.

AIX 5 implémente les stratégies de planification suivantes : FIFO, round-robin et fair round-robin. La politique FIFO se compose de trois implémentations différentes : FIFO, FIFO2 et FIFO3. La politique de tourniquet du tournoi s'appelle SCHED_RR dans AIX et la politique de tourniquet équitable s'appelle SCHED_OTHER.

Linux

Linux2.4

Brain Fuck Scheduler (BFS), également créé par Kolivas, est une alternative au CFS.

GratuitBSD

FreeBSD utilise une file d'attente de commentaires à plusieurs niveaux avec des priorités comprises entre 0 et 255. 0 à 63 sont réservés aux interruptions, 64 à 127 à la moitié supérieure du noyau, 128 à 159 aux threads utilisateur en temps réel, 160 à 223 aux threads utilisateur en temps partagé et 224 à 255 aux threads utilisateur inactifs. De plus, comme Linux, il utilise une configuration de file d'attente active, mais il dispose également d'une file d'attente inactive.

Introduction

Le but de l'atelier sur l'organisation de la production est d'élargir et d'approfondir les connaissances théoriques, d'inculquer les compétences nécessaires pour résoudre les problèmes les plus fréquemment rencontrés dans la pratique concernant l'organisation et la planification de la production.

L'atelier comprend des tâches pour les sections principales du cours. Au début de chaque sujet, de brèves instructions méthodologiques et des informations théoriques, des problèmes typiques avec solutions et des problèmes pour une solution indépendante sont présentés.

La présence d'instructions méthodologiques et de brèves informations théoriques dans chaque sujet vous permettent d'utiliser cet atelier pour l'enseignement à distance.

Calcul de la durée du cycle de production

La durée du cycle de production sert d'indicateur de l'efficacité du processus de production.

Cycle de production– la période de séjour des objets de travail dans le processus de production depuis le lancement des matières premières jusqu'au moment de la sortie des produits finis.

Le cycle de production comprend heures d'ouverture, pendant laquelle le travail est dépensé, et pauses. Les pauses, selon les raisons qui les ont provoquées, peuvent être divisées en :

1) sur naturel ou technologiques - ils sont déterminés par la nature du produit ;

2) organisationnel(pauses entre les quarts de travail).

La durée du cycle de production comprend les éléments suivants :

Cycle T = t ceux + t mange + t tr + t k.k. + t m.o. + t m.ts.

Où t ceux– le temps des opérations technologiques ;

je ne mange pas - temps des processus naturels (séchage, refroidissement, etc.) ;

ttr – temps de transport des objets de travail;

t k.k. – temps de contrôle qualité ;

t m.o – temps de soins interopératoires ;

t m.c. – durée de stockage dans les entrepôts inter-magasins ;

(t trois t k.k. peut être combiné avec t m.o).

Le calcul du temps de cycle de production dépend du type de production. Dans la production de masse, la durée du cycle de production est déterminée par le temps pendant lequel le produit est en production, c'est-à-dire

Cycle T = t dans M,

Où t V– relâcher la course ;

M- nombre de postes de travail.

Sous coup de relâchement il est nécessaire de comprendre l'intervalle de temps entre la sortie d'un produit manufacturé et le produit suivant.

La course de libération est déterminée par la formule

t in = Teff /V,

Où Tef– fonds effectif du temps du travailleur pour la période de facturation (équipe, jour, année) ;

DANS– volume de production pour la même période (en unités naturelles).

Exemple : T cm = 8 heures = 480 min ; T par = 30 min ; → Teff = 480 – – 30 = 450 min.

B = 225 pièces ; → t po = 450/225 = 2 min.

Dans la production en série, où le traitement est effectué par lots, la durée du cycle technologique n'est pas déterminée par unité de produit, mais pour l'ensemble du lot. De plus, selon le mode de lancement d'un lot en production, on obtient des temps de cycle différents. Il existe trois manières de déplacer les produits en production : séquentielle, parallèle et mixte (série-parallèle).

je. À séquentiel Lors du déplacement de pièces, chaque opération suivante ne commence qu'une fois la précédente terminée. La durée du cycle de mouvement séquentiel des pièces sera égale à :

Où n – nombre de parties du lot en cours de traitement ;

t piècesje- le tarif aux pièces pour une opération ;

C je– nombre d'emplois par je l'opération ;

m– le nombre d'opérations du processus technologique.

Un lot de produits composé de 5 pièces est remis. Le lot passe successivement par 4 opérations ; la durée de la première opération est de 10 minutes, la seconde de 20 minutes, la troisième de 10 minutes, la quatrième de 30 minutes (Fig. 1).

Image 1

T cycles = T dernier = 5·(10+20+10+30) = 350 min.

La méthode séquentielle de pièces mobiles présente l'avantage de garantir le fonctionnement de l'équipement sans temps d'arrêt. Mais son inconvénient est que la durée du cycle de production est dans ce cas la plus longue. De plus, des stocks importants de pièces sont créés sur les chantiers, ce qui nécessite un espace de production supplémentaire.

II. À parallèle Pendant le mouvement du lot, les pièces individuelles ne sont pas retenues aux postes de travail, mais sont immédiatement transférées individuellement à l'opération suivante, sans attendre la fin du traitement de l'ensemble du lot. Ainsi, avec le mouvement parallèle d'un lot de pièces, sur chaque poste de travail diverses opérations sont effectuées simultanément sur différentes pièces d'un même lot.

Le temps de traitement d'un lot avec mouvement parallèle des produits est fortement réduit :

dl .

Où nn– nombre de pièces dans lot de transfert(lot de transport), c'est-à-dire le nombre de produits transférés simultanément d'une opération à une autre ;

Longueur – le cycle de fonctionnement le plus long.

Lors du lancement d'un lot de produits en parallèle, les parties du lot entier sont traitées en continu uniquement sur les lieux de travail où les opérations longues succèdent aux opérations courtes. Dans les cas où des opérations courtes suivent des opérations longues, c'est-à-dire plus longtemps (dans notre exemple, la troisième opération), ces opérations sont effectuées de manière discontinue, c'est-à-dire l'équipement est inactif. Ici, un lot de pièces ne peut pas être traité immédiatement, sans délais, puisque l'opération (longue) précédente ne le permet pas.

Dans notre exemple : n= 5, t 1 = 10; t 2 = 20; t 3 = 10; t 4 = 30; Avec= 1.

T vapeur = 1·(10+20+10+30)+(5-1)·30=70+120 = 190 min.

Considérons le schéma de mouvement parallèle des pièces (Fig. 2) :

Figure 2

III. Pour éliminer les interruptions dans le traitement des parties individuelles d'un lot dans toutes les opérations, utilisez parallèle-série ou mixte une méthode de lancement dans laquelle les pièces (après transformation) sont transférées à l'opération suivante une par une, ou sous forme de lots de « transport » (plusieurs pièces) de telle sorte que l'exécution des opérations ne soit interrompue sur aucun lieu de travail. Dans la méthode mixte, la continuité du traitement est issue de la méthode séquentielle et la transition de la pièce d'une opération à l'autre immédiatement après son traitement est issue de la méthode parallèle. Avec un mode mixte de mise en production, la durée du cycle est déterminée par la formule

cœur .

où est le cor. – le cycle de fonctionnement le plus court (de chaque paire d'opérations adjacentes) ;

m-1 – nombre de combinaisons.

Si l'opération suivante est plus longue que la précédente ou égale en temps, alors cette opération est lancée individuellement, immédiatement après le traitement de la première partie de l'opération précédente. Si, au contraire, l'opération suivante est plus courte que la précédente, des interruptions se produisent ici lors du transfert des pièces. Pour les éviter, il est nécessaire d'accumuler une réserve de transport d'un volume suffisant pour assurer le travail lors de l'opération ultérieure. Pour retrouver pratiquement ce point sur le graphique, il faut transférer la dernière partie du lot et déplacer la durée de son exécution vers la droite. Le temps de traitement de toutes les autres pièces du lot est tracé à gauche sur le graphique. Le début du traitement de la première partie indique le moment où le retard de transport de l'opération précédente doit être transféré vers cette opération.

Si les opérations adjacentes sont de même durée, alors une seule d'entre elles est considérée comme courte ou longue (Fig. 3).

figure 3

T dernières paires = 5·(10+20+10+30)-(5-1)·(10+10+10) = 350-120 = 230 min.

Les principaux moyens de réduire le temps de cycle de production sont :

1) Réduire l’intensité de main-d’œuvre liée à la fabrication des produits en améliorant la fabricabilité de la conception fabriquée, en utilisant des ordinateurs et en introduisant des processus technologiques avancés.

2) Organisation rationnelle des processus de travail, aménagement et entretien des postes de travail basés sur la spécialisation et la coopération, mécanisation poussée et automatisation de la production.

3) Réduction des diverses pauses de travail planifiées et non planifiées sur la base de l'utilisation rationnelle des principes d'organisation scientifique du processus de production.

4) Accélération des réactions suite à l'augmentation de la pression, des températures, du passage à un processus continu, etc.

5) Améliorer les processus de transport, de stockage et de contrôle et les combiner dans le temps avec le processus de transformation et d'assemblage.

Réduire la durée du cycle de production est l'une des tâches sérieuses de l'organisation de la production, car affecte la rotation du fonds de roulement, réduisant les coûts de main-d'œuvre, réduisant l'espace de stockage, le besoin de transport, etc.

Tâches

1 Déterminer la durée du cycle de traitement de 50 pièces avec des types de mouvement séquentiel, parallèle et série-parallèle dans le processus de production. Le processus de traitement des pièces comprend cinq opérations dont la durée est respectivement de min : t 1 =2; t 2 =3; t 3 =4; t 4 =1; t 5 =3. La deuxième opération est réalisée sur deux machines, et chacune des autres sur une seule. La taille du lot de transfert est de 4 pièces.

2 Déterminer la durée du cycle de traitement de 50 pièces avec des types de mouvement séquentiel, parallèle et série-parallèle dans le processus de production. Le processus de traitement des pièces comprend quatre opérations dont la durée est respectivement de min : t 1 =1; t 2 =4; t 3 =2; t 4 =6. La quatrième opération est réalisée sur deux machines, et chacune des autres sur une seule. La taille du lot de transfert est de 5 pièces.

3 Un lot de pièces de 200 pièces est traité avec un mouvement parallèle-séquentiel pendant le processus de production. Le processus de traitement des pièces comprend six opérations dont la durée est respectivement de min : t 1 =8; t 2 =3; t 3 =27; t 4 =6; t 5 =4; t 6 =20. La troisième opération est effectuée sur trois machines, la sixième sur deux et chacune des opérations restantes sur une machine. Déterminez comment la durée du cycle de traitement d'un lot de pièces changera si la version parallèle-séquentielle du mouvement en production est remplacée par une version parallèle. La taille du lot de transfert est de 20 pièces.

4 Un lot de pièces de 300 pièces est traité avec un mouvement parallèle-séquentiel pendant le processus de production. Le processus de traitement des pièces comprend sept opérations dont la durée est respectivement de min : t 1 =4; t 2 =5; t 3 =7; t 4 =3; t 5 =4; t 6 =5; t 7 =6. Chaque opération est effectuée sur une seule machine. Lot de transfert – 30 pièces. Grâce à l'amélioration de la technologie de production, la durée de la troisième opération a été réduite de 3 minutes, la septième de 2 minutes. Déterminez comment le cycle de traitement d'un lot de pièces change.

5 Un lot de flans composé de 5 pièces est donné. Le lot passe par 4 opérations : la durée de la première est de 10 minutes, la seconde est de 20 minutes, la troisième est de 10 minutes, la quatrième est de 30 minutes. Déterminez la durée du cycle par des méthodes analytiques et graphiques avec mouvement séquentiel.

6 Un lot de flans composé de quatre pièces est donné. Le lot passe par 4 opérations : la durée de la première est de 5 minutes, la seconde est de 10 minutes, la troisième est de 5 minutes, la quatrième est de 15 minutes. Déterminez la durée du cycle par des méthodes analytiques et graphiques avec mouvement parallèle.

7 Un lot de flans composé de 5 pièces est donné. Le lot passe par 4 opérations : la durée de la première est de 10 minutes, la seconde est de 20 minutes, la troisième est de 10 minutes, la quatrième est de 30 minutes. Déterminez la durée du cycle par des méthodes analytiques et graphiques pour le mouvement série-parallèle.

8 Déterminer la durée du cycle technologique de traitement d'un lot de produits de 180 pièces. avec des variantes parallèles et séquentielles de son mouvement. Créez des graphiques de processus de traitement. La taille du lot de transfert est de 30 pièces. Les normes de temps et le nombre d’emplois dans les opérations sont les suivants.

Tout ce qui a été décrit dans les sections précédentes était davantage orienté vers des recherches plus approfondies sur le problème du temps propre du processus et, dans une bien moindre mesure, sur les applications pratiques. Pour combler cette lacune, nous présenterons l'une des manières de calculer le temps propre d'un processus sur la base de données statistiques sur son évolution.

Considérons un processus unidimensionnel dont l'état est caractérisé par une variable réelle x. Supposons que les observations de la dynamique du processus soient effectuées en un temps astronomique t, de sorte que t = t k et x = x k, k =1, ..., n sont des moments d'observation fixes et les valeurs correspondantes de le processus indique. Il existe de nombreuses méthodes mathématiques différentes qui permettent de construire des courbes passant par les points (t k, Xk) ou de « meilleure approche » de ceux-ci. Les fonctions x = x(t) ainsi obtenues donnent l'impression dans notre esprit que le processus considéré dépend du mouvement mécanique des corps célestes et, par conséquent, son état s'exprime à travers le temps astronomique t. Cette conclusion pourrait être prise en compte ; si des difficultés constantes ne surgissaient pas en essayant de prédire le déroulement ultérieur du processus. Pour un grand nombre de processus différents qui ne sont pas directement liés aux mouvements mécaniques des corps célestes, les prédictions théoriques obtenues à l'aide de la fonction x = x(t) en dehors de l'intervalle d'observation commencent à s'écarter considérablement des données expérimentales ultérieures. Ils essaient généralement d'expliquer la raison de l'écart entre la théorie et l'expérience par une méthode de traitement sélectionnée sans succès, mais ce n'est peut-être pas l'essence du problème.

Tout processus qui nous intéresse se produit dans l'Univers. Il « ressent » certainement l'influence du mouvement des corps célestes. Cependant, cette influence peut s’avérer « non rigide », non déterminante. Ceci, en particulier, peut se manifester par le fait qu'à certains intervalles de temps astronomique, l'état du processus reste inchangé. À cet égard, rappelons l’exemple précédent d’une pièce vide et fermée, isolée du monde extérieur. Laissons un seul être vivant entrer dans la pièce. Au cours de plusieurs jours, l'évolution de l'état du système « room-fly » dépendra des mouvements du fly, car on ne peut pas s'attendre à des changements dans l'état de la pièce. En même temps, il est difficile d'imaginer que le comportement d'une mouche soit strictement lié au cours du temps astronomique.

Après avoir fait une si longue digression, passons à la description de l’algorithme de calcul du temps propre du processus.

Dans cet algorithme, l'unité de calcul des maxima locaux est choisie comme mesure naturelle du temps. De plus, les sections possibles de l'état stationnaire du processus sont prises en compte, auxquelles, comme indiqué précédemment, le temps approprié s'arrête. Étant donné que l'identité de deux états ne peut être affirmée que dans les limites de la précision des mesures, dans ce qui suit, un certain nombre positif e est utilisé - l'erreur de mesure tolérée.

Ainsi, les données d'entrée de l'algorithme sont l'entier naturel n, le nombre positif 8, les tableaux (tk) et (x k), k = 1, ..., n. Pour faciliter la programmation, l'algorithme est présenté sous la forme de quatre modules exécutés séquentiellement.

Module 1, en utilisant les données p, e, t k), (x k), dans le cas général, forme de nouveaux tableaux 7 = (7+ X = (X t) et un tableau d'accompagnement très spécifique P = (?), où 1 = 1, ..., t et t<Сп. Основное назначение этого модуля -- выявление в массиве x k) последовательностей идентичных состояний процесса, сохранение первых элементов в таких последовательностях и удаление всех остальных и, наконец, уменьшение по определенному, правилу исходного интервала наблюдения от t до на сумму тех промежутков времени, в которых процесс протекает стационарно.

Le module 1 comprend les procédures suivantes :

p : = 1, t : = 0, k : = 1.

Aux pp. 1, 2 compteurs avec des valeurs initiales spécifiques sont introduits :

Aux pp. 3, 4 les valeurs des compteurs augmentent de 1.

Vérifiez l'état k^n. S'il est terminé, passez à l'étape 6, sinon passez à l'étape 11.

Vérifiez l'inégalité x k --x k = e. Si elle est vérifiée, passez à l'étape 7, sinon passez à l'étape 9.

7. tii = ti - (tkl - tk), i = k1, ..., p.

Cette procédure signifie que si les valeurs de Xk et Xk 1 sont indiscernables dans l'erreur, alors tous les points temporels à partir de tk sont réduits du montant tki-tk.

r = r. Revenons au point 4.

Tv = t k ; Xv:=xk ; p = p v = v+l., c'est-à-dire les éléments des tableaux T, X, P sont formés et la valeur suivante v est attribuée.

• 10. Prenez (t k, ..., t n AND (Xk, - X n) comme tableaux initiaux de dimension n--k 1 + 1, puis revenez à l'étape 2.
• 11. Imprimez m, (T), (X,) et (P,), où i = l, ..., t. Fin.

Expliquons la signification des éléments du tableau d'accompagnement P. Du texte précédent, il s'ensuit que la valeur de pk est égale au nombre de ces éléments du tableau (xk) qui suivent directement et diffèrent de x pi+... +, + de moins de e. On note également que pi+ ... +p m = n.

Exemple 1. Étant donné : n = 20, (/*) = (2, 4, 7, 10, 12, 13, 15, 17, 20, 22, 24, 25,

• 27, 30, 32, 33, 34, 35, 36) et (x,)= (4, 4, 6, 6, 6, 3, 2, 4, 3, 3, 3, 2, 2, 4, 5 , 5,
• 5, 4, 3), voir fig. 9, a.

À la suite de l'exécution du module 1, m = 11 est obtenu,

(G) = (2, 3, 4, 6, 8, 11, 1-2, 15, 17, 18, 19); (X,) = (4, 6, 3, 2, 4, 3, 2, 4,5,4,3)

je(d.) = (2, 4, 1, 1, 1,3, 2, 1,3, 1, 1), voir fig. 9, b.

Module 2. Les données d'entrée sont un nombre naturel m, ainsi que des tableaux (7+ (X L), = 1, ..., m. Ce module dans le tableau (TJ identifie les moments du temps [TM a], 1 = 1 m (ml

Exemple 2. Les valeurs m, (Ть) et (X,] sont empruntées à l'exemple précédent. Après avoir terminé le module 2, on obtient ml = 3, m2 = 8, (Ш,) = (3, 8, 17 ), (Т*) = (3, 4, 6, 8, 11, 12, 15, 17), voir aussi Fig. 9, b.

Module 3. Données d'entrée ml, m2, (TM n), 1 = 1, ..., ml, (G*), /2 = 1, ..., gn2.

Ce module est conçu pour construire un tableau (t(-r) en utilisant la formule

Où est TV 6 [TMp, TMn+i]

La variable t est le temps propre généré par le changement de la variable x. Sa mesure naturelle est l'unité de calcul des maxima locaux.

Exemple 3. Les données initiales pour T 2) sont les mêmes que les valeurs de ml, m2 ITM, et dans l'exemple 2. . Après les calculs appropriés, on obtient Н = (0 ; 0,2 ; 0,6 ; 1; 1,33; 1,78; 2).

Module 4. Génère la sortie des résultats en établissant une correspondance entre les valeurs de m et les éléments x du tableau (xk).

Exemple 4. Sur la base des données des exemples 2 et 3, le résultat suivant est produit, voir fig. 9, dans :

t : 0 ; 0,2 ; 0,6 ; 1; 1,33 ; 1,44 ;

x : 6 ; 3 ; 2 ; 4 ; 3T 0 2 ;

Ainsi, l’algorithme considéré nous permet de développer le concept du temps propre du processus sur la base des informations sur les changements de l’état du processus enregistrés sur l’échelle de temps astronomique. Il est bien clair que l'on peut utiliser d'autres algorithmes, basés par exemple sur le calcul d'une séquence de minima locaux ou d'une séquence mixte constituée de maxima et de minima locaux. Lors du traitement des données expérimentales, diverses options devraient probablement être testées. Si, pour une raison quelconque, l'expérimentateur choisit l'un des moments appropriés spécifiques et reçoit des tableaux (t4 et (xk), alors à l'étape suivante, il devra utiliser des méthodes mathématiques pour approximer les points expérimentaux (t*, x) d'une ligne mondiale approximative de le processus x = x(t). En extrapolant cette ligne au-delà de la période d'observation initiale, il peut faire des prédictions sur le déroulement ultérieur du processus.

Il est intéressant de mentionner une expérience informatique destinée à évaluer les perspectives d'utilisation de l'algorithme proposé. Les données sur les débits annuels des rivières ont été choisies comme matériel expérimental. Vakhsh (Tadjikistan) depuis 40 ans. Au cours de la même période, des informations ont été recueillies sur la dynamique du nombre de Wolf, l'indice intégral de l'activité solaire le plus couramment utilisé. Ce dernier était la base pour développer le moment approprié du processus d'activité solaire. À l’époque moderne, les informations sur les dépenses fluviales ont été transformées. Vakhsh puis, pendant la période d'observation, une dépendance théorique du débit d'eau a été donnée en fonction du temps propre de l'activité solaire. Un trait caractéristique du graphique résultant est le comportement presque périodique des dépenses maximales et minimales. Les coûts ne restent cependant pas constants.