Informatique, cybernétique et programmation

Processus de développement unifié Iteration N logiciel Le modèle de cas d'utilisation USDP décrit les cas dans lesquels l'application sera utilisée. Le modèle analytique décrit les classes de base de l'application. Le modèle de conception décrit les relations et les relations entre les classes et les objets alloués. Un modèle de déploiement décrit la distribution des logiciels sur les ordinateurs.

Leçon numéro 20
Principes généraux et approches du développement logiciel

Modèles de développement logiciel

1. Cascade
2. Modèle en cascade
3. Spirale
4. Programmation extrême
5. Incrémentale
6. Méthodologie MSF

Modèle de cascade

Modèle en spirale

Développement incrémental

Analyse des besoins

Conception

la mise en oeuvre

Composant

essai

L'intégration

Essai

un seul tout

Itération 1 Itération 2…. Itération N

Processus de développement logiciel unifié (USDP)

1. Un modèle de cas d'utilisation décrit les cas d'utilisation dans lesquels l'application sera utilisée.
2. Le modèle analytique décrit les classes de base de l'application.
3. Le modèle de conception décrit les relations et les relations entre les classes et les objets sélectionnés
4. Le modèle de déploiement décrit la distribution des logiciels sur les ordinateurs.
5. Le modèle de mise en œuvre décrit organisation interne code de programme.
6. Le modèle de test comprend des composants de test, des procédures de test et diverses options de test

Méthodologie MSF

Composants typiques d'une architecture de produit logiciel et exigences logicielles typiques

tolérance aux pannes- un ensemble de propriétés d'un système, qui augmente sa fiabilité en détectant les erreurs, en récupérant et en localisant les mauvaises conséquences pour le système. Lors de la conception d'un système réel pour garantir la tolérance aux pannes, il est nécessaire de prévoir toutes sortes de situations pouvant conduire à une défaillance du système et de développer des mécanismes de gestion des pannes.

Fiabilité - la capacité du système à résister à diverses pannes et pannes.

Renoncement Est la transition du système à la suite d'une erreur dans un état complètement inopérant.

crash - une erreur dans le fonctionnement du système, qui n'entraîne pas de panne du système.

Moins il y a de pannes et de pannes sur une certaine période de temps, plus le système est fiable.

Et aussi d'autres oeuvres qui pourraient vous intéresser
57355.		Variété de composés organiques, leur classification. Matière organique de la nature vivante	48,5 Ko
	La variété des composés organiques est déterminée par la capacité unique des atomes de carbone à se connecter les uns aux autres par des liaisons simples et multiples pour former des composés avec un nombre presque illimité d'atomes liés dans une chaîne de cycles bicyclettes tricycles polycyclettes cadres, etc.
57359.		Traitement des modèles d'information verbale	291 Ko
	Concepts de base: modèle; modèle d'information; modèle d'information verbale; annotation; abstrait. Résumé Synopsis de lat. Créez un plan pour 2. Enregistrez le document dans votre propre dossier sous le nom Plan.
57361.		Nombre et chiffre 3. Corrélation des nombres aux frontières 3. Écriture des chiffres 3. Corrélation du développement des objets	35,5 Kio
	Compétences de toutes les créatures Qui valent la première fois Qui valent la peine Qui sont au numéro 1 Qui sont au numéro 2 Nom susidiv їzhaka. Hto susid droitier bilochki Hto susid liv-main girafe Hto є nigh-hander Hto є inférieur Qui se tiennent au milieu des créatures Gras Show pas froissé.

Lors de l'examen de la technologie de développement logiciel, il est nécessaire d'utiliser une approche systématique, qui implique de ne pas considérer certains aspects individuels du problème de développement logiciel, mais le problème dans son ensemble. L'approche systématique est mise en œuvre dans l'espace et le temps.

Une approche systématique dans le temps considère la séquence des étapes du développement logiciel à partir du moment où le besoin non satisfait de logiciel est formé jusqu'à sa résolution et la maintenance en fonctionnement du produit logiciel résultant.

Approche systémique dans «l'espace» prévoit la prise en compte du logiciel développé comme faisant partie du système.De plus, sur la base de l'étude besoins d'information système, qui comprendra le logiciel en cours de développement, les objectifs et l'ensemble des fonctions du logiciel sont formulés, les prototypes sont analysés outils logiciels... Les exigences pour les logiciels sont formées et documentées.

Technologie moderne le développement logiciel considère la programmation comme l'une des étapes de développement dans la chaîne des étapes séquentielles du cycle de développement. Toutes ces étapes sont unies par le concept de cycle de vie logiciel et doivent être soutenues par des outils logiciels et matériels appropriés.

Conformément à la norme internationale ISO / CEI 12207 "Technologies de l'information - Processus cycle de la vie Le processus de développement logiciel du logiciel comprend les étapes suivantes du cycle de vie du logiciel:

1) analyse configuration requise et domaines d'application;

2) conception de l'architecture du système;

3) analyse des besoins logiciels (spécifications, interfaces externes,);

4) conception de l'architecture logicielle;

5) conception détaillée de chaque unité logicielle;

6) codage logiciel (programmation)

7) test des unités logicielles;

8) intégration (intégration logicielle) et test d'un ensemble d'unités logicielles;

9) tests de qualification de logiciels (tests complexes);

10) les unités d'intégration de système de la structure logicielle devraient être combinées avec des unités de matériel;

11) tests de qualification du système;

12) installation du logiciel.

Ainsi, le processus de développement logiciel commence à partir du système où ce logiciel sera utilisé et se termine à nouveau dans le système.

Après les étapes de développement dans le cycle de vie du logiciel, la phase d'exploitation et de maintenance du logiciel suit. Parfois, une liste des étapes du cycle de vie du logiciel est donnée avec quelques généralisations (agrandissements) des 12 étapes données. Par exemple, les étapes de la conception du système et de la détermination des exigences logicielles, la conception d'un progiciel, la conception d'algorithmes logiciels, la programmation (codage), le débogage logiciel hors ligne, le débogage logiciel intégré, l'exploitation logicielle.

Négliger les étapes de la conception logicielle, le désir de commencer immédiatement la programmation sans élaboration suffisante d'algorithmes et les problèmes d'interaction des unités structurelles du logiciel conduit souvent à un processus de développement logiciel chaotique avec peu de chances de succès.

Modèle en spirale du cycle de vie du logiciel. Technologies de développement de logiciels «lourdes et légères» (rapides)

Le modèle de cycle de vie considéré (LC) fait référence à un modèle de type cascade. Ce type de modèle de cycle de vie convient aux logiciels, pour lesquels, au tout début du développement, il est possible de formuler de manière complète et précise toutes les exigences logicielles.

Schéma logiciel du cycle de vie en spirale. Cependant, le véritable processus de développement logiciel ne s'inscrit pas toujours dans un schéma aussi rigide, et il est souvent nécessaire de revenir aux étapes précédentes avec clarification ou révision des décisions prises.

Pour les logiciels, ainsi que pour d'autres systèmes complexes, dont les exigences initiales ne sont pas suffisamment complètes, un processus de développement itératif est caractéristique. Cependant, pour certains types de logiciels, il est même souhaitable de passer à l'étape suivante le plus rapidement possible. Dans le même temps, les inconvénients inévitables avec un travail aussi hâtif sont éliminés à l'itération suivante ou restent à jamais.

La tâche principale est de réaliser un logiciel exploitable aussi rapidement que possible, activant ainsi le processus de spécification et de complément des exigences. Il s'agit du modèle dit en spirale du cycle de vie d'un logiciel.

A chaque tour de la spirale, une version du produit est créée, les exigences logicielles sont précisées et le travail de la prochaine manche est planifié. Le modèle en spirale du cycle de vie du logiciel reflète le processus objectivement existant de développement de logiciel itératif (Figure 8.2).

On pense que le schéma en spirale du cycle de vie des logiciels n'est pas tant destiné aux développeurs pressés, mais aux logiciels dont les premières versions de mauvaise qualité sont acceptables en termes de fonctionnalités logicielles.

Il y a le développement logiciel agile, qui fournit une base idéologique pour les vues associées au modèle de cycle de vie en spirale. Ces technologies reposent sur quatre idées:

L'interaction interactive des individus est plus importante que les procédures et outils formels,

Un logiciel de travail est plus important que d'avoir de la documentation pour cela,

La coopération avec le client est plus importante que les contrats formels,

Une réponse rapide aux changements externes est plus importante que le strict respect des plans.

Figure: 8.2 - Schéma du logiciel du cycle de vie en spirale

En d'autres termes, les technologies rapides visent à remplacer les procédures documentées formelles et chronophages d'interaction pendant le développement par des procédures interactives, ce qui est possible avec une petite taille de projet, des qualités sélectionnées des employés, en plaçant les développeurs et les clients «dans la même pièce» et pour le développement de logiciels pour des systèmes non critiques.

L'exactitude de ces principes dans une certaine mesure, lorsque le développement de logiciels est réalisé par un petit nombre de «fans» qualifiés et dévoués) pour le développement de certains types de logiciels est difficile à contester. Cependant, les technologies Agiles, et cela est reconnu par leurs idéologues, sont applicables dans des projets logiciels d'une certaine classe et échelle, tout comme le modèle de cycle de vie en spirale en général, à savoir lorsque des erreurs logicielles entraînent des inconvénients ou une perte de fonds remboursables.

Lorsqu'un logiciel fonctionnant de manière incorrecte conduit à une menace pour la vie humaine ou à des pertes matérielles importantes, des technologies réfléchies à part entière doivent être utilisées pour garantir la fiabilité du produit logiciel.

Avec une augmentation de l'échelle d'un projet logiciel, une augmentation du nombre de personnes qui y participent, le besoin d'une technologie de développement rigide qui constitue un cycle de vie logiciel en cascade augmente. Cela nécessite de la documentation, car à tout moment la perte de l'un des développeurs est possible, la formalisation des liens interprogrammes, la gestion des changements logiciels, etc. Ce n'est pas pour rien que le modèle de cycle de vie en cascade a été introduit dans les standards de développement logiciel. En même temps, il vous permet également de mettre en œuvre un processus de développement itératif en raison des étapes envisagées dans la conception des CTS et des logiciels pour eux.

Pour les très grands projets logiciels (une équipe de plus de 100 développeurs), la technologie de développement est un facteur clé qui affecte non seulement la qualité du logiciel, mais aussi la possibilité même de sa création.

Technologies de développement de logiciels «lourdes et légères» . Les développeurs de nombreux types de logiciels trouvent le modèle en cascade du cycle de vie trop réglementé, trop documenté et encombrant, et donc irrationnel. Il existe une tendance au développement logiciel agile qui fournit une base idéologique à ces points de vue. Ces technologies reposent sur quatre idées:

1. l'interaction interactive des individus est plus importante que les procédures et outils formels,

2.Le logiciel de travail est plus important que d'avoir de la documentation,

3. la coopération avec le client est plus importante que les contrats formels avec lui,

4. Une réponse rapide aux changements externes est plus importante que le strict respect des plans décrits.

L'exactitude de ces principes, à l'exception du troisième dans une certaine mesure (le développement logiciel est mené par un petit nombre de programmeurs qualifiés - «fans» qui n'ont pas besoin de contrôle et de motivation supplémentaire) pour le développement logiciel est difficile à contester. Cependant, les technologies Agile et cela est reconnu par leurs idéologues sont applicables dans les projets logiciels d'une certaine classe et échelle, ainsi que dans le modèle de cycle de vie en spirale en général, à savoir lorsque les erreurs logicielles entraînent des inconvénients ou une perte de fonds remboursables et où les exigences logicielles changent constamment. , car ils ont été mal définis à l'avance, et une adaptation rapide à ces changements est nécessaire.

Technologies rapides -tente de parvenir à un compromis entre une discipline de développement stricte et son absence totale au nom de la réduction du flux de papiers accompagnant le développement.Les technologies rapides ne peuvent pas fournir une haute fiabilité d'un produit logiciel précisément en raison de la minimisation des papiers qui confirment légalement la responsabilité du développeur.

Un exemple de technologie Agile est Extreme Programming (XP). Les itérations XP sont très courtes et consistent en quatre opérations: codage, test, écoute du client, conception. Principes XP - minimalisme, simplicité, implication du client, cycle court, interaction étroite des développeurs - ils devraient s'asseoir dans la même pièce, les réunions opérationnelles quotidiennes avec le client semblent raisonnables et ont longtemps été utilisées non seulement dans les technologies rapides, mais sous XP, elles sont portées à des valeurs extrêmes.

L'analyse de nombreux projets logiciels a montré que les technologies légères prônant les principes de l'auto-organisation, mettant l'accent sur l'utilisation des capacités individuelles des développeurs, de courtes itérations de développement dans le modèle en spirale, XP, SCRUM sont courantes et conduisent souvent également au succès, en tirant le meilleur parti des particularités du travail en petites équipes.

Lorsqu'un logiciel fonctionnant de manière incorrecte entraîne une menace pour la vie humaine ou des pertes matérielles importantes, des technologies "lourdes" formalisées, ordonnées, bien pensées et prévisibles devraient être utilisées pour garantir la fiabilité du produit logiciel, même dans le cas des développeurs de niveau intermédiaire. Avec une augmentation de l'échelle d'un projet logiciel, une augmentation du nombre de participants le besoin d'une technologie de développement rigide et formelle, qui fixe la responsabilité de chaque participant au développement, constituant un cycle de vie logiciel en cascade, augmente. Ce n'est pas pour rien que le modèle de cycle de vie en cascade a été introduit dans les normes de développement logiciel.

Dans les grandes équipes de développement, le problème de gestion vient au premier plan.

Pour les très grands projets logiciels, les enjeux d'un développement coordonné ordonné: structuration, intégration, assurer la bonne interaction des programmes, organiser la mise en œuvre correcte et coordonnée des changements inévitables sont essentiels. et affectent la possibilité même de leur création.

Dans les petits projets logiciels, la sophistication algorithmique et l'influence d'individus talentueux jouent un rôle décisif, tandis que dans les grands projets, ces facteurs sont nivelés et n'ont pas une influence décisive sur le processus de développement.

Les développeurs de logiciels avec des capacités moyennes, et la plupart d'entre eux, et adhérant à la discipline technologique dans le cadre de la bonne technologie, doivent développer des logiciels de la qualité requise. "Maintenez l'ordre et il vous soutiendra."

Il existe des modèles de développement logiciel. Et il existe des méthodologies. Il y a beaucoup d'informations contradictoires sur Internet sur ce qui est quoi et comment les distinguer. Cela peut être difficile pour un débutant de comprendre cela. Dans cet article, nous mettrons en point les i.

Étapes du cycle de vie du logiciel

Tout logiciel a un cycle de vie - les étapes par lesquelles il passe du début de la création à la fin du développement et de la mise en œuvre. Le plus souvent, il s'agit de préparation, de conception, de création et de support. Les étapes peuvent être nommées différemment et peuvent être décomposées en étapes plus petites.

Considérons ces étapes à l'aide de l'exemple du cycle de vie d'une boutique en ligne.

Formation. Ivan a décidé de lancer une librairie en ligne et a commencé à analyser les sites similaires déjà disponibles sur le réseau. Collecte d'informations sur leur trafic, leurs fonctionnalités.

Conception. Ivan a choisi une entreprise sous-traitante et a discuté avec ses spécialistes de l'architecture et du design de la future boutique en ligne.

Créature. Ivan a signé un contrat avec les développeurs. Ils ont commencé à écrire du code, à dessiner des conceptions et à rédiger de la documentation.

Soutien. Ivan a signé le certificat d'acceptation et l'entrepreneur a placé la boutique en ligne sur les serveurs «combat». Les utilisateurs ont commencé à le visiter et à signaler les bogues au support, et les programmeurs ont commencé à tout corriger rapidement.

Modèlele développement logiciel décrit les étapes du cycle de vie qu'il traverse et ce qui se passe à chacune d'elles.

ET méthodologie comprend un ensemble de méthodes de gestion du développement: ce sont des règles, des techniques et des principes qui le rendent plus efficace.

Modèles de développement logiciel de base

• Code et correction - modèle de codage et de correction des erreurs;
• Modèle de cascade - modèle de cascade, ou «cascade»;
• V-model - V-model, développement piloté par les tests;
• Modèle incrémental - modèle incrémental;
• Modèle itératif - un modèle itératif (ou itératif);
• Modèle en spirale - modèle en spirale;
• Modèle du chaos - modèle du chaos;
• Prototype Model est un modèle prototype.

Parmi ceux-ci, les cinq principaux sont les plus populaires: cascade, en forme de V, incrémental, itératif et en spirale. Analysons-les plus en détail.

Cascade (modèle en cascade ou "cascade")

Dans ce modèle, le développement est effectué par étapes: chaque étape suivante ne commence qu'après la fin de la précédente. Si cela est fait correctement, la "cascade" sera le modèle le plus rapide et le plus simple. Il est utilisé depuis près d'un demi-siècle, depuis les années 1970.

Avantages de la "cascade"

• Le développement est facile à contrôler. Le client sait toujours ce que font les programmeurs maintenant, il peut gérer les conditions et les coûts.
• Le coût du projet est déterminé au stade initial. Toutes les étapes sont déjà planifiées au stade de l'accord d'accord, le logiciel est écrit en continu «de et vers».
• Vous n'avez pas besoin d'embaucher des testeurs ayant une solide expérience technique. Les testeurs pourront s'appuyer sur une documentation technique détaillée.

Inconvénients du modèle de cascade

• Les tests commencent dans les dernières étapes du développement. Si une erreur a été commise dans les exigences du produit, il sera coûteux de la réparer. Les testeurs le trouveront lorsque le développeur aura déjà écrit le code et que les rédacteurs techniques auront déjà écrit la documentation.
• Le client voit le produit fini à la fin du développement et ce n'est qu'alors qu'il peut donner son avis.Il y a de fortes chances que le résultat ne lui convienne pas.
• Les développeurs écrivent beaucoup de documentation technique, ce qui retarde le travail. Plus la documentation du projet est étendue, plus il y a de changements à apporter et plus il faut de temps pour les coordonner.

"Waterfall" convient au développement de projets en industrie médicale et spatiale, où une vaste base de données de documents a déjà été constituée(SNiP et spécifications), sur la base desquels vous pouvez rédiger les exigences pour un nouveau logiciel.

Lorsque vous travaillez avec un modèle en cascade, la tâche principale consiste à rédiger des exigences de développement détaillées. Pendant la phase de test, il ne devrait pas être révélé qu'ils ont un bogue qui affecte l'ensemble du produit.

V-pattern (développement piloté par les tests)

Il s'agit d'un modèle de cascade avancé, dans lequel le client et l'équipe de programmeurs créent simultanément des exigences pour le système et décrivent comment ils vont le tester à chaque étape. L'histoire de ce modèle commence dans les années 1980.

Avantages du modèle en forme de V

Le nombre d'erreurs dans l'architecture logicielle est minimisé.

Inconvénients du modèle en forme de V

Si une erreur a été commise lors du développement de l'architecture, alors il sera coûteux de la retourner et de la réparer, comme dans la «cascade».

Le modèle en V s'adapte pour les projets dans lesquels la fiabilité est importante et le coût d'une erreur est très élevé. Par exemple, lors du développement de coussins gonflables pour voitures ou de systèmes de surveillance des patients dans les cliniques.

Modèle incrémental

Il s'agit d'un modèle de développement au coup par coup (incrément) qui remonte aux années 1930. Considérons-le sur l'exemple de la création d'un réseau social.

1. Le client a décidé qu'il souhaitait lancer le réseau social et a rédigé une tâche technique détaillée. Les programmeurs ont proposé de mettre en œuvre les principales fonctions - une page avec des informations personnelles et un chat. Et puis testez-le sur les utilisateurs, "décollera ou non".
2. L'équipe de développement montre le produit au client et le commercialise. Si le client et les utilisateurs réseau social Je l'aime, le travail continue, mais par parties.
3. En parallèle, les programmeurs créent des fonctionnalités pour télécharger des photos, partager des documents, écouter de la musique et d'autres actions convenues avec le client. Incrément en incrément, ils améliorent le produit, se rapprochant de celui décrit dans les termes de référence.

Avantages du modèle incrémental

• Vous n'avez pas besoin d'investir beaucoup d'argent au départ. Le client paie pour la création des fonctions de base, reçoit le produit, le «déploie» sur le marché - et, sur la base des commentaires, décide s'il souhaite poursuivre le développement.
• Vous pouvez rapidement obtenir des commentaires des utilisateurs et mettre à jour rapidement les termes de référence. Cela réduit le risque de créer un produit dont personne n'a besoin.
• L'erreur est moins chère.Si une erreur a été commise lors du développement de l'architecture, il ne sera pas aussi coûteux de la réparer que dans le modèle "cascade" ou en forme de V.

Inconvénients du modèle incrémental

• Chaque équipe de programmeurs développe ses propres fonctionnalités et peut implémenter l'interface produit à sa manière. Pour éviter que cela ne se produise, il est important, au stade de la discussion des termes de référence, d'expliquer ce que ce sera pour que tous les participants au projet aient une compréhension commune.
• Les développeurs vont reporter la finalisation de la fonctionnalité principale et "vu de petites choses". Pour éviter que cela ne se produise, le chef de projet doit contrôler ce que fait chaque équipe.

Le modèle incrémental convient pour projets dans lesquels les termes de référence exacts sont déjà définis dès le départ et le produit devrait rapidement entrer sur le marché.

Modèle itératif

Il s'agit d'un modèle dans lequel le client n'est pas obligé de comprendre quel produit il souhaite obtenir au final, et ne peut pas immédiatement prescrire un cahier des charges détaillé.

Regardons l'exemple de création d'un messager comment ce modèle fonctionne.

1. Le client a décidé qu'il voulait créer un messager. Les développeurs ont créé une application dans laquelle vous pouvez ajouter un ami et démarrer une discussion à deux.
2. Le messager a été "déployé" dans la boutique d'applications, les utilisateurs ont commencé à le télécharger et à l'utiliser activement. Le client s'est rendu compte que le produit était populaire et a décidé de le raffiner.
3. Les programmeurs ont ajouté à la messagerie la possibilité de regarder des vidéos, de télécharger des photos, d'enregistrer des messages audio. Ils améliorent progressivement la fonctionnalité de l'application, en l'adaptant aux exigences du marché.

Avantages du modèle itératif

• Sortie rapide d'un produit minimalpermet de recevoir rapidement le feedback du client et des utilisateurs. Cela signifie se concentrer sur les fonctions logicielles les plus importantes et les améliorer conformément aux exigences du marché et aux souhaits des clients.
• Tests constants par les utilisateurs vous permet de détecter et de corriger rapidement les erreurs.

Inconvénients du modèle itératif

• Première utilisation des bases de données ou des serveurs- les premiers sont difficiles à mettre à l'échelle et les seconds ne peuvent pas supporter la charge. Vous devrez peut-être réécrire la majeure partie de l'application.
• Manque de budget et de délais fixes. Le client ne sait pas à quoi ressemble l'objectif final et quand le développement prendra fin.

Un modèle itératif convient pour travailler sur grands projets avec des exigences non définies, ou pour des problèmes avec approche innovative,lorsque le client n'est pas sûr du résultat.

Modèle en spirale

À l'aide de ce modèle, le client et l'équipe de développement analysent sérieusement les risques du projet et l'exécutent par itérations. L'étape suivante s'appuie sur la précédente, et à la fin de chaque itération - un cycle d'itérations - une décision est prise de poursuivre le projet. Ce modèle a commencé à être utilisé en 1988.

Considérons le fonctionnement de ce modèle, en prenant l'exemple du développement du système «Smart Home».

1. Le client a décidé qu'il souhaitait créer un tel système et a ordonné aux programmeurs de mettre en œuvre le contrôle de la bouilloire à partir du téléphone. Ils ont commencé à agir selon le modèle de la «cascade»: ils ont écouté l'idée, analysé les propositions sur le marché, discuté de l'architecture du système avec le client, décidé de la manière de l'implémenter, développé, testé et «déployé» le produit final.
2. Le client a évalué le résultat et les risques: combien les utilisateurs ont besoin de la prochaine version du produit - déjà avec une commande TV. Termes calculés, budget et développement ordonné. Les programmeurs ont suivi un modèle en cascade et ont présenté au client un produit plus complexe basé sur le premier.
3. Le client a pensé qu'il était temps de créer une fonctionnalité pour contrôler le réfrigérateur à partir du téléphone. Mais en analysant les risques, je me suis rendu compte qu'il était difficile d'intégrer un module Wi-Fi dans le réfrigérateur, et les fabricants ne sont pas intéressés par une coopération sur cette question. Par conséquent, les risques l'emportent sur les avantages potentiels. Sur la base des données reçues, le client a décidé d'arrêter de développer et d'améliorer les fonctionnalités existantes afin de comprendre à terme comment développer le système Smart Home.

Le modèle en spirale est similaire au modèle incrémental, mais on consacre beaucoup plus de temps à l'évaluation des risques. À chaque nouveau tour de spirale, le processus se complique. Ce modèle est souvent utilisé dans projets de recherche et où les risques sont élevés.

Avantages du modèle en spirale

Une grande attention est accordée à l'étude des risques.

Inconvénients du modèle en spirale

• Il y a un risque de se coincer au stade initial- améliorer sans cesse la première version du produit et ne pas passer à la suivante.
• Le développement prend du temps et coûte cher.

Agile a été créé à partir du modèle itératif - pas un modèle ou une méthodologie, mais plutôt une approche du développement.

Qu'est-ce que Agile?

Agile («agile») est traduit de l'anglais par «flexible». Comprend des pratiques, des approches et des méthodologies qui aident à créer un produit plus efficacement:

• programmation extrême (Extreme Programming, XP);
• développement de logiciels lean (Lean);
• cadre de gestion de projet Scrum;
• développement basé sur les fonctionnalités (FDD)
• développement par tests (développement piloté par les tests, TDD);
• méthodologie du génie logiciel des salles blanches;
• méthode de développement itératif-incrémental (OpenUP);
• méthodologie de développement Microsoft Solutions Framework (MSF);
• méthode de développement de systèmes dynamiques (DSDM);
• méthode de gestion du développement Kanban.

Nous avons résumé dans le tableau les différences entre Agile et l'approche traditionnelle du développement:

Tout sur la liste n'est pas une méthodologie. Par exemple, Scrum est plus souvent désigné non pas comme une méthodologie, mais comme un cadre. Quelle est la différence? Un cadre est une méthodologie plus mature avec des règles strictes. Dans Scrum, tous les rôles et processus sont clairement définis. Outre Scrum, Kanban est souvent utilisé.

Kanban

C'est l'une des méthodologies de développement logiciel les plus populaires aujourd'hui. L'équipe effectue le travail à l'aide d'un tableau virtuel, qui est divisé en étapes de projet. Chaque participant voit quelles tâches sont en cours, lesquelles sont bloquées à l'une des étapes et lesquelles ont déjà atteint sa colonne et nécessitent une attention particulière.

Contrairement à Scrum, dans Kanban, vous pouvez prendre des tâches urgentes en développement tout de suite, sans attendre le début du prochain sprint. Kanban est pratique à utiliser non seulement au travail, mais aussi à des fins personnelles - pour distribuer vos propres plans ou tâches familiales pour le week-end, pour suivre visuellement les progrès.

Nous en organiserons très bientôt une de trois jours. Sur celui-ci, vous apprendrez à utiliser tous les avantages de cette approche, à gérer des projets de développement et de publication de toute complexité. Dans votre attente!

1. Objectif de la technologie de programmation. L'histoire du développement de la technologie de programmation. Types de projets logiciels. Composants de la technologie de programmation. Projet, produit, processus et personnes

2. Le cycle de vie du programme. La nature cyclique du développement. Concepts de base de la technologie de programmation. Processus et modèles. Phases et virages. Jalons et artefacts. Parties prenantes et employés.

3. Identification et analyse des besoins. Logiciels requis. Schéma de développement des exigences. Gestion des exigences.

4. Conception architecturale et détaillée. Implémentation et codage. Test et vérification. Processus de contrôle qualité. Méthodes boîte blanche et boîte noire. Inspection et revues. Objectifs du test. Vérification, validation et test du système... Maintenance et développement continu.

5. Modèles du processus de développement. Modèles de cascade et de convoyeur. Modèles en spirale et incrémentaux. Modèles flexibles du processus de développement.

6. Construction d'un modèle de processus. Identifier les exigences du processus. Phases, jalons et artefacts utilisés. Choix de l'architecture des processus. La procédure pour un projet typique. Procédures documentées.

7. Modèles de l'équipe de développement. La nature collective du développement. Taille optimale de l'équipe. Subordination des participants au projet. Développement d'équipe et développement du personnel. Spécialisation, coopération et interaction.

8. Modèles de l'équipe de développement. Modèle d'équipe hiérarchique. Méthode d'équipe chirurgicale. Modèle d'équipe de pairs.

9. La nature de la programmation. La science de la programmation. L'art de la programmation. Le métier de la programmation. Paradigmes de programmation. Programmation structurée... Programmation logique. Programmation orientée objet.

10. Architecture logicielle. Gestion d'événements. Architecture client / serveur. Un service. Architecture à trois couches. Conception du programme. Design conceptuel. Conception logique. Conception détaillée.

1. Approches Novikov du développement de logiciels "http: // window. /window_catalog/files/r60368/itmo307.pdf.

2. Programmation extrême. - SPb.: Peter, 2002.

3. Technologie de développement de logiciels. - SPb. : Peter, 2004.

4. Brooks Jr. les systèmes logiciels sont conçus et créés. Moscou: Nauka, 1975; nouvelle édition de la traduction: The Mythical Man-Month. SPb.: SYMBOLE +, 1999.

5. Algorithmes + structures de données \u003d programmes. M., Mir, 1978.

6. Programmation systématique. Introduction. Moscou: Mir, 1977.

7. Programmation structurée. Moscou: Mir, 1975.

8. Discipline de la programmation. M .: Mir, 1978.

9. Technologies de développement de logiciels. - SPb.: Peter, 2002.

10. Programmation Terekhov. M.: BINOM, 2006.

11. Rambeau J. Processus de développement logiciel unifié. SPb: Peter, 2002.

Théorie économique pour les managers

Théories microéconomiques de base. Exemples d'application dans l'analyse des processus économiques. Théories macroéconomiques de base. Exemples d'application dans l'analyse des processus économiques. Principes et méthodes de gestion des processus économiques. Boîte à outils pour évaluer le niveau de développement des processus économiques Problèmes de reproduction élargie. Facteurs de croissance économique de l'économie russe. Critères et indicateurs de développement durable. Lissage des fluctuations cycliques. Le rôle du multiplicateur et de l'accélérateur dans l'évaluation du rythme du développement économique. Fonctions de production dans l'économie. Exemples d'application dans l'analyse des processus économiques. Profit. Calcul d'indicateurs affectant le profit, image graphique seuil de rentabilité. Méthodologie de mise en œuvre de la politique d'investissement.

Le cours de théorie économique: manuel pour les universités / Ed. ... –Kirov: "ASA", 2004. Kolemaev - modélisation mathématique. Modélisation des processus et systèmes macroéconomiques: manuel. M .: UNITY-DANA, 2005. Cybernétique Bazhin. Kharkov: Consul, 2004. Atelier de Leushin sur les méthodes de modélisation mathématique: un tutoriel. État de Nizhny Novgorod technologie. univ.- N. Novorod, 2007. Aux politiciens sur l'économie: conférences de lauréats du prix Nobel d'économie. M.: Économie et droit modernes, 2005. Cheremnykh. Niveau avancé: Manuel.-M .: INFRA-M, 2008. Evolution des institutions de mini-économie. Institut d'économie, URO RAS, - Moscou: Nauka, 2007.

Technologies pour l'élaboration et l'adoption de décisions de gestion [N]

Prise de décision comme base de l'activité d'un manager. Une introduction à la théorie de la décision. Concepts de base de la théorie de la prise de décision. Modèles de gestion d'entreprise et leur impact sur la prise de décision. Différentes manières classification des décisions. Classifications: par le degré de formalité, par le degré de routine, par fréquence, par urgence, par le degré de réalisation des objectifs, par la méthode de choix d'une alternative. Méthodes de base de la prise de décision. Méthodes de prise de décision résolues. Objectifs de prise de décision. Il est temps de chercher des solutions. Erreurs de base Méthodes mathématiques de prise de décision. Aspects mathématiques de la théorie de la décision. Recherche opérationnelle. Approche mathématique de la prise de décision. Arbre de décision. Modèles de développement et de prise de décision. La théorie des jeux. Méthodes mathématiques de prise de décision. Aspects mathématiques de la théorie de la décision. Modèles de théorie des files d'attente. Modèles de gestion des stocks. Modèle de programmation linéaire. Tâches de transport. Modélisation de simulation. Analyse de réseau. Analyse économique. Les limites des modèles rationnels. Caractéristiques de développement et de prise de décision dans le groupe. Une méthode pour déterminer la cohésion de groupe basée sur le degré de connexité des ensembles. Techniques de prise de décision collective. Méthode du consensus. Méthodes de vote. Méthodes de prise de décision créatives. Idée de génie. Conférence d'idées. Conseil du navire. La méthode Mind Hats de De Bono. Théorie de la résolution inventive de problèmes (TRIZ). La solution finale parfaite. Exemples de tâches et leur solution avec TRIZ. Application des méthodes TRIZ pour prendre des décisions uniques et créatives. Méthodes pour développer des idées de solutions et leur adaptation à la situation. Modèle d'arbre d'objectifs. Une stratégie d'alignement des intérêts. Formation de décisions pour harmoniser les intérêts. Méthodes de détermination des intérêts des contreparties. Systèmes d'aide à la décision (systèmes experts). L'histoire de la création des systèmes décisionnels. Classification des systèmes décisionnels. Structure typique d'un système expert. Façons de représenter la connaissance. Méthodes d'inférence logique. Application systèmes experts sur la pratique.

I. Théorie de la décision: manuel. - M .: Examen, 2006 .-- 573 p. I. Prendre des décisions. Théorie et méthodes d'élaboration des décisions de gestion. Didacticiel. - M .: Mars 2005. - 496 p. Développement de solutions de gestion - M.: Delo Publishing House, 2004 - 392 p. G. Expertises et prise de décision - M.: Brevet, 1996. - 271 p. Taha // Introduction à la recherche opérationnelle \u003d Recherche opérationnelle: une introduction. - 7e éd. - M.: "Williams", 2007. - S. 549-594. G. Queue. Prévisions économiques et prise de décision. M.: "Progrès" 1970. KD Lewis. Méthodes de prévision des indicateurs économiques. Moscou: "Finances et statistiques" 1986. G. S. Kildishev, A. A. Frenkel. Analyse et prévision de séries chronologiques. M.: «Statistics» 1973. O. Kim, C. W. Mueller, W. R. Klecka et al. Analyse factorielle, discriminante et en grappes. M.: "Finance and Statistics" 1989. Un gestionnaire efficace. Livre 3. Prise de décision. - MIM LINK, 1999 Turevsky et direction d'une société de transport automobile. - M.: Ecole supérieure, 2005.,; ed. ... Analyse des systèmes en gestion: un tutoriel. - M.: Finances et statistiques, 2006., Tinkov: un tutoriel. - M.: KNORUS, 2006.

Modélisation des processus métier dans des systèmes de gestion intégrés

Quels sont les principes pour distinguer les processus métier? Quel est le problème d'une description holistique des processus métier. Qu'est-ce qu'un système, quelles sont ses propriétés? Le rôle de l'analyse des systèmes dans la modélisation des processus métier? Processus comme objet de contrôle. Environnement de processus. Les principaux éléments du processus métier. Avantages et inconvénients de la gestion fonctionnelle et des processus. Cycle de gestion PDCA. Étapes du cycle de gestion des processus. Cycle PDCA et mise en œuvre des exigences ISO 9001: 2008. Méthodologie SADT (Structured Analysis and Design Technique - méthode d'analyse structurale et de conception). Essence. Dispositions de base. Comment le modèle fonctionnel d'activité est-il représenté dans la méthodologie IDEF0? Que signifient les activités dans les diagrammes de modèles fonctionnels, comment sont-elles affichées selon la méthodologie IDEF0? À quoi servent les flèches dans les diagrammes de modèles fonctionnels, quels sont leurs types et types? Méthodologie DFD. Essence. Les principaux composants des graphiques DFD. Quelles sont les caractéristiques des diagrammes DFD, que sont-elles décrites? Quelles sont les fonctionnalités des objets DFD? Que représentent les flèches sur le graphique DFD? Méthodologie IDEF3. Essence. Outils de documentation et de modélisation. Quelles sont les caractéristiques des diagrammes IDEF3, que décrivent-ils? Quelles sont les fonctionnalités des objets de diagramme IDEF3? Et le tireur? Classification des processus. Processus commerciaux typiques. Reengineering et sa technologie. Quand est-il conseillé d'utiliser la réingénierie dans la gestion d'entreprise? Processus de surveillance et de mesure. Indicateurs de processus d'organisation. Évaluations numériques et de notation des processus.

"Modélisation des processus métiers avec AllFusion Process Modeler (BPwin 4.1) Dialogue-MEPhI" 2003 "Création de systèmes d'information avec AllFusion Modeling Suite" ed. Pratique "Dialogue-MEPhI" 2003 " modélisation fonctionnelle avec AllFusion Process Modeler 4.1. (BPwin) Où? Pourquoi? Comment? "Ed." Dialogue-MEPhI "2004 Modélisation de Dubeykovsky avec AllFusion Process Modeler (BPwin). Ed." Dialogue-MEPhI "2007 D. Mark, K. McGowan" Méthodologie d'analyse structurelle et de conception SADT "1993 travail classique sur Méthodologie SADT Analyse des systèmes Cheremnykh: technologies IDEF, modélisation et analyse des systèmes. Technologies IDEF. Travaux pratiques M.: Finances et statistiques, 2001., "Modèles d'affaires structurels: technologies DFD" http: // www. / Level4. asp? ItemId \u003d 5810 "Théorie et pratique de la réorganisation des processus métier" 2003 / P50.1 .. Méthodologie de la modélisation fonctionnelle. M.: Gosstandart of Russia, 2000. http: // www. IDEF0, IDEF3, DFD http: // www. Modélisation des processus métiers avec BPwin http: // www. / Department / se / devis / 7 / IDEF0 dans la modélisation des processus métiers de gestion http: /// content / view / 21/27 / http: // www. / Dir / cat32 / subj45 / file1411 / view1411.html http: // www. http: // www.

Évaluation de l'efficacité des produits logiciels

1. Architecture informatique

2. Domaines des processus de gestion.

3. Liste de planification et d'organisation des processus de domaine

4. Liste des processus de domaine Acquisition et mise en œuvre

5. Liste des processus de domaine Exploitation et maintenance

6. Liste des processus du domaine Suivi et évaluation

7. Caractéristiques des niveaux du modèle de maturité des processus

9. KPI et KGI, leur relation et leur objectif

1. 10. Contrôles informatiques généraux et contrôles applicatifs. Domaines de responsabilité et responsabilités de l'entreprise et de l'informatique.

Cobit 4.1 édition russe.

Réglementation juridique de la création et de l'utilisation de la propriété intellectuelle

1. Énumérez les droits intellectuels sur les résultats de l'activité intellectuelle et révélez leur contenu.

2. Énumérez les types de contrats de cession de droits exclusifs. Décrivez chacun de ces contrats de droits exclusifs.

4. Décrivez les principales dispositions de la protection juridique d'un programme d'ordinateur en tant qu'objet du droit d'auteur.

5. Comparez les principales dispositions de la protection juridique de la base de données en tant qu'objet du droit d'auteur et en tant qu'objet de droits voisins.

6. Décrivez les conditions de brevetabilité des objets des droits de brevet: inventions; modèles d'utilité; dessins industriels.

7. Élargir le contenu des critères de brevetabilité d'une invention: nouveauté; Étape inventive; applicabilité industrielle.

8. Décrivez les conditions et la procédure d'obtention d'un brevet pour une invention, un modèle d'utilité ou un dessin ou modèle industriel, ainsi que les conditions qui garantissent la validité des brevets et leur durée.

9. Donner une définition du "savoir-faire" et énumérer les conditions dans lesquelles la protection juridique des secrets d'affaires naît et est exercée.

10. Énumérer les moyens d'individualisation protégés et donner leurs caractéristiques comparatives.

1., Droits de propriété intellectuelle sur Fédération Russe, manuel // M, Prospect, 2007

2., Droit de la propriété intellectuelle, guide d'étude // M, RIOR, 2009

Gestion de projet et développement de logiciels [Et]

Qu'est-ce qu'une méthodologie, pourquoi est-elle nécessaire. Structure générale méthodologie, les principaux éléments de la méthodologie. Principes pour concevoir votre propre méthodologie. Exemples de divers artefacts, rôles, compétences, conditions aux limites. Structure de la méthodologie Coberne, métriques de la méthodologie. Critères Cowberne pour le projet. Critères de sélection de la méthodologie, matrice de Couberne. Cycle de vie d'un projet. Modèles de cascade et de cycle de vie itératif. Limites d'application pour les modèles de cascade et d'itération. RUP comme exemple de méthodologie itérative. Concepts de base du RUP, limites d'applicabilité. Rôle humain dans le développement de logiciels. Méthodologies agiles, principes de base des méthodologies agiles. La raison de l'émergence des méthodologies agiles. Scrum comme exemple de méthodologie agile. Rôles, artefacts, activités dans Scrum. Portée Scrum. Extreme Programming (XP) Idées, valeurs, pratiques de base, limites d'applicabilité. Similitudes et différences entre Scrum et XP. Collecte et gestion des besoins. Pratiques de base, termes, principes. Approches de la documentation projet et produit, principaux types de documents. Exemples de pratiques de gestion des exigences à partir des méthodologies abordées dans le cours. Planification du développement de logiciels. Types de plans, gestion des risques, risques populaires. Exemples de pratiques de planification du développement à partir des méthodologies discutées dans le cours. Test de développement logiciel. Le concept d'assemblage (build) d'un produit logiciel. Méthodes de test de base, termes. Exemples de pratiques de test à partir des méthodologies discutées dans le cours. Le concept d'assembly (build), les moyens de stocker le code, les outils. Deux principes d'organisation du travail avec un système de contrôle de version. Caractéristiques du processus de publication / d'affichage des produits pour différentes catégories de produits, exemples de pratiques. Concepts modernes d'architecture logicielle, architectures en couches, critères d'architecture. liste décisions nécessaires lors de la conception d'un logiciel, des approches pour choisir un système de stockage de données.

Kent Beck - Programmation extrême Frederick Brooks - Le mois de l'homme mythique ou comment les systèmes logiciels sont fabriqués. Tom de Marco - Date limite. Un roman sur la gestion de projet. Tom de Marco, Timothy Lister - Valse avec les ours. Tom de Marco, Timothy Lister - Le facteur humain_ projets et équipes réussis. Alistair Couburn - Chaque projet a sa propre méthodologie. Alistair Couburn - Les gens en tant que composants non linéaires et les plus importants du développement logiciel. Andriy Orlov - Notes d'un automate. Aveu professionnel. Philip Crachten - Introduction au processus rationnel unifié. Henrik Kniberg - Scrum et XP: Notes de la première ligne. Présentations de cours

Modèle en cascade Analyse des exigences Conception Mise en œuvre Intégration Test La spécification du produit est en cours d'élaboration L'architecture du produit est en cours d'élaboration Développement du code source Intégration de parties distinctes du code source Test et élimination des défauts

Processus de développement logiciel unifié (USDP) Modèle de cas d'utilisation qui décrit les cas dans lesquels une application sera utilisée. Le modèle analytique décrit les classes de base de l'application. Le modèle de conception décrit les relations et les relations entre les classes et les objets alloués. Un modèle de déploiement décrit la distribution des logiciels sur les ordinateurs. Le modèle d'implémentation décrit l'organisation interne du code programme. Le modèle de test comprend des composants de test, des procédures de test et diverses options de test

Composants typiques d'une architecture de produit logiciel et exigences logicielles typiques Organisation du programme Classes principales du système Organisation des données Règles métier Interface utilisateur Gestion des ressources Sécurité Performance Évolutivité Interaction avec d'autres systèmes (intégration) Internationalisation, localisation E / S de données Traitement des erreurs

Composants typiques d'une architecture de produit logiciel et exigences logicielles typiques La tolérance aux pannes est un ensemble de propriétés d'un système qui augmente sa fiabilité en détectant les erreurs, en récupérant et en isolant les mauvaises conséquences pour le système. Lors de la conception d'un système réel pour garantir la tolérance aux pannes, il est nécessaire de prévoir toutes sortes de situations pouvant conduire à une défaillance du système et de développer des mécanismes de gestion des pannes. La fiabilité est la capacité d'un système à résister à diverses pannes et pannes. L'échec est la transition du système à la suite d'une erreur vers un état complètement inopérant. Un échec est une erreur de fonctionnement du système qui n'entraîne pas de panne du système. Moins il y a de pannes et de pannes sur une certaine période de temps, plus le système est fiable.

Composants typiques d'une architecture de produit logiciel et exigences logicielles typiques Capacités d'implémentation de l'architecture développée. Possibilités de mise en œuvre de l'architecture développée. Fonctionnalité redondante. Fonctionnalité redondante. Prendre la décision d'acheter des composants logiciels prêts à l'emploi. Prendre la décision d'acheter des composants logiciels prêts à l'emploi. Changer de stratégie. Changer de stratégie.

L'organisation générale du programme est-elle clairement décrite; Si la spécification comprend un aperçu de l'architecture et de sa justification. L'organisation générale du programme est-elle clairement décrite; Si la spécification comprend un aperçu de l'architecture et de sa justification. Les principaux éléments du programme, leurs domaines de responsabilité et leur interaction avec les autres éléments sont-ils correctement définis? Les principaux éléments du programme, leurs domaines de responsabilité et leur interaction avec les autres éléments sont-ils correctement définis? Toutes les fonctions spécifiées dans la spécification des exigences sont-elles mises en œuvre par un nombre raisonnable de composants du système? Toutes les fonctions spécifiées dans la spécification des exigences sont-elles mises en œuvre par un nombre raisonnable de composants du système? Existe-t-il une description des classes les plus importantes et de leur justification? Existe-t-il une description des classes les plus importantes et leur justification? Existe-t-il une description de l'organisation de la base de données. Existe-t-il une description de l'organisation de la base de données. Toutes les règles métier sont-elles définies? Toutes les règles métier sont-elles définies? Si leur impact sur le système a été décrit. Si leur impact sur le système a été décrit. Liste de contrôle questions qui permettent de conclure sur la qualité de l'architecture:

Une liste de questions pour tirer des conclusions sur la qualité de l'architecture: une stratégie de conception d'interface utilisateur est-elle décrite? Une stratégie de conception d'interface utilisateur est-elle décrite. L'interface utilisateur a-t-elle été rendue modulaire afin que les modifications n'affectent pas le reste du système? L'interface utilisateur a-t-elle été rendue modulaire afin que les modifications n'affectent pas le reste du système? Existe-t-il une description de la stratégie d'entrée / sortie des données. Existe-t-il une description de la stratégie d'entrée / sortie des données. Une analyse des performances du système qui sera implémenté en utilisant cette architecture a-t-elle été réalisée? Une analyse des performances du système qui sera implémenté en utilisant cette architecture a-t-elle été réalisée? L'analyse de fiabilité du système conçu a-t-elle été effectuée? L'analyse de fiabilité du système conçu a-t-elle été effectuée? L'analyse des problèmes d'évolutivité et d'extensibilité du système a-t-elle été réalisée? Le système a-t-il été analysé pour l'évolutivité et l'extensibilité?

Refactoring du logiciel Le code est répété; l'implémentation de la méthode est trop importante; trop d'imbrication de boucles, ou la boucle elle-même est très grande; la classe a une mauvaise cohésion (les propriétés et méthodes d'une classe ne doivent décrire qu'un seul objet); l'interface de classe ne forme pas une abstraction cohérente; la méthode prend trop de paramètres. Des efforts devraient être faits pour maintenir le nombre de paramètres raisonnablement minimal; certaines parties de la classe changent indépendamment des autres parties de la classe; La refactorisation implique l'adaptation du logiciel au nouveau matériel et aux nouveaux systèmes d'exploitation, aux nouveaux outils de développement, aux nouvelles exigences, ainsi qu'à l'architecture et aux fonctionnalités logicielles. Il s'agit d'un changement dans la structure interne du logiciel sans changer son comportement externe, conçu pour fournir une modification logicielle. Raisons raisonnables de refactoring:

Refactoriser le logiciel lors du changement de programme nécessite un changement parallèle de plusieurs classes. Si une telle situation se présente, il est nécessaire de réorganiser les classes afin de minimiser les lieux d'éventuels changements dans le futur; doivent changer plusieurs hiérarchies d'héritage en parallèle; vous devez changer plusieurs blocs de cas. Il est nécessaire de modifier le programme de manière à effectuer la mise en œuvre du bloc de cas, et de l'appeler dans le nombre de fois requis dans le programme; Les éléments de données frères utilisés ensemble ne sont pas organisés en classes. Si vous utilisez à plusieurs reprises le même ensemble d'éléments de données, il est conseillé d'envisager de combiner ces données et de placer les opérations effectuées sur elles dans une classe distincte;

La méthode de refactoring du logiciel utilise plus d'éléments d'une autre classe que la sienne. Cela signifie que la méthode doit être déplacée vers une autre classe et appelée à partir de l'ancienne; le type de données primitif est surchargé. Il est préférable d'utiliser une classe pour décrire une entité dans le monde réel que de surcharger tout type de données existant; la classe a des fonctionnalités trop limitées. Il vaut mieux se débarrasser de cette classe en transférant ses fonctionnalités dans une autre classe; les données itinérantes sont transmises le long de la chaîne de méthodes. Les données qui sont transmises à une méthode uniquement pour être transmises à une autre méthode sont appelées «parasites». Lorsque ces situations surviennent, essayez de repenser vos classes et méthodes pour vous en débarrasser.

Refactoriser un objet de médiation logiciel ne fait rien. Si le rôle d'une classe est réduit à rediriger les appels de méthode vers d'autres classes, alors il est préférable d'éliminer un tel objet intermédiaire et d'effectuer directement des appels vers d'autres classes; une classe en sait trop sur une autre classe. Dans cette situation, il est nécessaire de rendre l'encapsulation plus stricte afin d'assurer la connaissance minimale de l'héritier de son parent; la méthode a un nom malheureux; ces membres sont publics. Cela brouille la ligne entre l'interface et l'implémentation, rompt inévitablement l'encapsulation et limite la flexibilité du programme; publier des commentaires dans code source;

Refactoring de logiciel Une sous-classe n'utilise qu'une petite fraction des méthodes de ses ancêtres. Cette situation se produit lorsque nouvelle classe est créé uniquement pour hériter de plusieurs méthodes de la classe de base, et non pour décrire une nouvelle entité. Pour éviter cela, il est nécessaire de transformer la classe de base de telle sorte qu'elle ne donne accès à la nouvelle classe qu'aux méthodes dont elle a besoin; le code contient des variables globales. Seules les variables qui sont réellement utilisées par l'ensemble du programme doivent être globales. Toutes les autres variables doivent être locales ou devenir des propriétés de certains objets; le programme contient du code dont vous pourriez avoir besoin un jour. Lors du développement du système, il est conseillé de prévoir des emplacements où le code source pourra être ajouté ultérieurement.