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

Une approche systématique dans le temps considère l'enchaînement des étapes de création d'un logiciel à partir du moment de la formation d'un besoin non satisfait en logiciel jusqu'à son autorisation et soutien au fonctionnement des reçus produit logiciel.

Approche système dans "l'espace" prévoit la prise en compte du logiciel en cours de développement dans le cadre du système. Dans le même temps, sur la base de l'étude des besoins en informations du système, qui comprendra le logiciel développé, des objectifs et un ensemble de fonctions logicielles sont formulés, des prototypes sont analysés outils logiciels. Les exigences logicielles 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 successives du cycle de développement. Toutes ces étapes sont unies par le concept de cycle de vie logiciel et doivent être supportées par des outils logiciels et matériels appropriés.

Conformément à la norme internationale ISO/IEC 12207 " Informatique– Processus du cycle de vie du logiciel » le processus de développement logiciel contient les étapes suivantes du cycle de vie du logiciel :

1) analyse Configuration requise et portée ;

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

3) analyse des exigences logicielles (spécifications, interfaces externes,);

4) conception de l'architecture logicielle ;

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

6) codage logiciel (programmation)

7) test des unités logicielles ;

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

9) tests de qualification logicielle (tests intégrés) ;

10) les unités de structure logicielle d'intégration du système doivent être intégrées aux unités matérielles ;

11) tests de qualification du système ;

12) mise en place 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 du cycle de vie du logiciel, vient l'étape d'exploitation et de maintien en exploitation du logiciel. Parfois la liste des étapes du cycle de vie du logiciel est donnée avec quelques généralisations (agrégations) des 12 étapes. Par exemple, les étapes de conception du système et de définition des exigences logicielles, la conception de progiciels, la conception d'algorithmes logiciels, la programmation (codage), le débogage de logiciels hors ligne, le débogage de logiciels complexes, l'exploitation de logiciels.

Négligeant les étapes de la conception logicielle, la volonté de commencer immédiatement la programmation sans étude suffisante des algorithmes et les problèmes d'interaction des unités structurelles logicielles conduisent souvent à un processus de développement logiciel chaotique avec peu de chances de succès.

Modèle de cycle de vie logiciel en spirale. Technologies de développement de logiciels "lourds et légers" (rapides)

Le modèle de cycle de vie (LC) considéré appartient au 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 du logiciel.

Schéma d'un cycle de vie logiciel en spirale. Cependant, processus réel le développement de logiciels 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 une clarification ou une 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. Parallèlement, 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 lacunes inévitables avec un travail aussi hâtif sont éliminées à la prochaine itération ou restent pour toujours.

La tâche principale est de réaliser un logiciel exploitable dès que possible, activant ainsi le processus de clarification et de complément des exigences. C'est ce qu'on appelle le modèle de cycle de vie logiciel en spirale.

À chaque tournant de la spirale, une version du produit est créée, les exigences logicielles sont spécifiées et le travail du tour suivant est planifié. Le modèle de cycle de vie logiciel en spirale reflète le processus objectivement existant de développement logiciel itératif (Fig. 8.2).

On pense que le schéma en spirale du cycle de vie du logiciel n'est pas tant destiné aux développeurs hâtifs, mais aux logiciels dont les premières versions de mauvaise qualité sont acceptables pour l'objectif fonctionnel du logiciel.

Il existe une direction des "technologies rapides" de développement logiciel (Agile Software Development), qui donne une justification idéologique aux vues associées au modèle en spirale du cycle de vie. Ces technologies reposent sur quatre idées :

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

Un logiciel fonctionnel est plus important que d'avoir une documentation pour celui-ci,

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

Réponse rapide à changements externes plus important que de suivre strictement les plans.

Riz. 8.2 - Schéma du cycle de vie logiciel en spirale

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

La justesse 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édiés au développement de certains types de logiciels est difficile à contester. Cependant, les technologies Agiles et leurs idéologues reconnaissent que cela s'applique aux projets logiciels d'une certaine classe et échelle, tout comme le modèle de cycle de vie en spirale en général, à savoir, où les erreurs logicielles entraînent des inconvénients ou une perte de fonds récupérables.

Lorsqu'un logiciel fonctionnant de manière incorrecte entraîne une menace pour la vie humaine ou des pertes matérielles importantes, des technologies complètes et bien pensées 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 le cycle de vie du logiciel en cascade augmente. Il faut ici de la documentation, car à tout moment la perte de n'importe lequel des développeurs est possible, il faut formaliser les communications 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 le développement logiciel. normes. Dans le même temps, il permet également de mettre en œuvre un processus de développement itératif grâce au phasage prévu de la conception des CTS et des logiciels correspondants.

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

Technologies de développement de logiciels "lourds et légers" . Les développeurs de nombreux types de logiciels considèrent que le modèle de cycle de vie en cascade est trop réglementé, trop documenté et lourd, et donc irrationnel. Il existe une direction des "technologies rapides" (technologies légères) du développement logiciel (Agile Software Development), qui donne une justification idéologique à ces vues. Ces technologies reposent sur quatre idées :

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

2. un logiciel fonctionnel est plus important que la disponibilité de sa documentation,

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

4. une réponse rapide aux changements externes est plus importante qu'un strict respect des plans.

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

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

Un exemple de technologies Agiles est l'Extreme Programming (XP). Les itérations sous XP sont très courtes et consistent en quatre opérations : coder, tester, écouter le client, concevoir. Les principes de XP - minimalisme, simplicité, participation des clients, temps de cycle courts, interaction étroite entre les développeurs - ils doivent s'asseoir dans la même pièce, les réunions opérationnelles quotidiennes avec le client semblent raisonnables et sont utilisées depuis longtemps non seulement dans les technologies rapides, mais dans XP, ils sont amenés à des valeurs extrêmes.

Une analyse de nombreux projets logiciels a montré que les technologies légères qui prêchent les principes d'auto-organisation, mettant l'accent sur l'utilisation des capacités individuelles des développeurs, les itérations de développement courtes dans un modèle en spirale, XP, SCRUM sont courantes et mènent souvent aussi au succès, ce qui rend la plupart des caractéristiques 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, bien pensées et prévisibles doivent être utilisées pour garantir la fiabilité du produit logiciel, même dans le cas de développeurs moyennement qualifiés. 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 qui compose le cycle de vie du 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 la gestion se pose.

Pour les très grands projets logiciels, les enjeux d'un développement ordonné et coordonné : structurer, intégrer, s'assurer que les programmes interagissent correctement, organiser les changements inévitables de manière correcte et coordonnée sont essentiels et affecter la possibilité même de leur création.

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

Les développeurs de logiciels qui ont des capacités moyennes, et ils sont majoritaires, et qui maintiennent une discipline technologique dans la bonne technologie, devraient développer des logiciels de la qualité requise. "Gardez l'ordre et il vous gardera."

Modèle en cascade Analyse des exigences Conception Implémentation Intégration Tests Rédaction des spécifications du produit Rédaction de l'architecture du produit Développement du code source Intégration des parties du code source Test et débogage

Le modèle de cas d'utilisation du processus de développement logiciel unifié (USDP) 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 connexions et les relations entre les classes et les objets dédiés, tandis que le modèle de déploiement décrit la répartition des logiciels sur les ordinateurs. Le modèle d'implémentation décrit l'organisation interne du code du programme. Le modèle de test comprend des composants de test, des procédures de test et diverses options essai

Composants d'architecture de produit logiciel typiques et exigences logicielles typiques Organisation du programme Classes de système de base 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 Données d'entrée-sortie Gestion des erreurs

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

Composants typiques de l'architecture du produit logiciel et exigences logicielles typiques Possibilités de mise en œuvre de l'architecture développée. Possibilités de mise en œuvre de l'architecture développée. fonctionnalité redondante. fonctionnalité redondante. Décider de l'achat de composants logiciels prêts à l'emploi. Décider de l'achat de 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 principales composantes du programme sont-elles correctement définies, leurs domaines de responsabilité et leur interaction avec d'autres composantes. Les principales composantes du programme sont-elles correctement définies, leurs domaines de responsabilité et leur interaction avec d'autres composantes. Si toutes les fonctions spécifiées dans la spécification des exigences sont mises en œuvre par un nombre raisonnable de composants du système. Si toutes les fonctions spécifiées dans la spécification des exigences sont mises en œuvre par un nombre raisonnable de composants du système. Les classes les plus importantes sont-elles décrites et justifiées. Les classes les plus importantes sont-elles décrites et justifiées. Si une description de l'organisation de la base de données est donnée. Si une description de l'organisation de la base de données est donnée. Toutes les règles métier sont-elles définies ? Toutes les règles métier sont-elles définies ? Leur impact sur le système est-il décrit ? Leur impact sur le système est-il décrit ? Une liste de contrôle de questions qui vous permet de tirer une conclusion sur la qualité de l'architecture :

Une liste de contrôle de questions qui vous permet de tirer une conclusion sur la qualité de l'architecture : La stratégie de conception de l'interface utilisateur est-elle décrite. Si la stratégie de conception de l'interface utilisateur est décrite. Si l'interface utilisateur est rendue modulaire afin que les modifications qui y sont apportées n'affectent pas le reste du système. Si l'interface utilisateur est rendue modulaire afin que les modifications qui y sont apportées n'affectent pas le reste du système. Si une description de la stratégie d'E/S a été fournie. Si une description de la stratégie d'E/S a été fournie. Si une analyse des performances du système qui sera mis en œuvre à l'aide de cette architecture a été effectuée. Si une analyse des performances du système qui sera mis en œuvre à l'aide de cette architecture a été effectué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 ? Une analyse de l'évolutivité et de l'extensibilité du système a-t-elle été effectuée ? Une analyse de l'évolutivité et de l'extensibilité du système a-t-elle été effectuée ?

Le code de refactorisation logicielle est répété ; la mise en œuvre 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 connectivité (les propriétés et les méthodes de la classe ne doivent décrire qu'un seul objet) ; une interface de classe ne forme pas une abstraction cohérente ; la méthode prend trop de paramètres. Vous devriez essayer de garder le nombre de paramètres à un minimum raisonnable ; les parties individuelles de la classe changent indépendamment des autres parties de la classe ; Le refactoring consiste à adapter un logiciel à un nouveau Matériel et aux nouveaux systèmes d'exploitation, aux nouveaux outils de développement, aux nouvelles exigences, à l'architecture et aux fonctionnalités logicielles. Il s'agit d'un changement de la structure interne du logiciel sans modifier son comportement externe, destiné à assurer la modification du logiciel. Raisons raisonnables de refactoriser :

La refactorisation logicielle 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 ; devoir modifier plusieurs hiérarchies d'héritage en parallèle ; vous devez modifier plusieurs blocs de cas. Il est nécessaire de modifier le programme de manière à rendre l'implémentation du cas bloc, et de l'appeler le nombre de fois requis dans le programme ; les membres de données associés 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 celles-ci dans une classe distincte ;

Une méthode de refactorisation logicielle 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 depuis l'ancienne ; le type de données élémentaire est surchargé. Pour décrire l'essence du monde réel, il est préférable d'utiliser une classe plutôt que de surcharger n'importe quel 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 "errantes" sont transmises le long de la chaîne de méthodes. Les données transmises à une méthode uniquement pour être transmises à une autre méthode sont appelées données parasites. Lorsque de telles situations se présentent, essayez de modifier l'architecture des classes et des méthodes pour vous en débarrasser.

Refactoriser l'objet média ne fait rien. Si le rôle d'une classe est de rediriger les appels de méthode vers d'autres classes, il est préférable d'éliminer ce proxy et d'appeler directement les autres classes ; une classe en sait trop sur une autre classe. Dans cette situation, il est nécessaire de rendre l'encapsulation plus stricte pour s'assurer que l'héritier a une connaissance minimale de son parent ; la méthode porte un nom malheureux ; les données membres sont publiques. Cela brouille la frontière entre l'interface et l'implémentation, rompt inévitablement l'encapsulation et limite la flexibilité du programme ; placer des commentaires dans le code source ;

Une sous-classe de refactorisation logicielle n'utilise qu'une petite partie des méthodes de ses ancêtres. Cette situation se produit lorsqu'une nouvelle classe est créée uniquement pour hériter de quelques 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 manière à ce 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 réellement utilisées par l'ensemble du programme doivent être globales. Toutes les autres variables doivent soit être locales, soit devenir des propriétés d'un objet ; le programme contient du code qui pourrait un jour être nécessaire. Lors du développement d'un système, il est conseillé de prévoir des endroits où le code source peut être ajouté à l'avenir.

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. 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. Intervenants 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 de la boîte blanche et de la boîte noire. Inspection et revues. Objectifs de test. Vérification, validation et test du système. Maintenance et développement continu.

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

6. Conception d'un modèle de processus. Identification des exigences du processus. Phases, jalons et artefacts utilisés. Choix de l'architecture du processus. La procédure de réalisation d'un projet type. procédures documentées.

7. Modèles de l'équipe de développement. Le caractère collectif du développement. Taille d'équipe optimale. Subordination des participants au projet. Développement de l'é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. La méthode de l'équipe chirurgicale. Modèle d'une équipe d'égal à égal.

9. La nature de la programmation. Sciences de la programmation. L'art de programmer. L'art 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. Prestations de service. architecture à trois couches. Conception du programme. Concept de design. Conception logique. Conception détaillée.

1. Approches Novikov du développement logiciel » http://window. /window_catalog/files/r60368/itmo307.pdf.

2. Programmation extrême. - Saint-Pétersbourg : Peter, 2002.

3. Technologie de développement logiciel. - Saint-Pétersbourg. : Pierre, 2004.

4. Brooks Jr. des systèmes logiciels sont conçus et créés. Moscou : Nauka, 1975 ; nouvelle édition de traduction : mois-homme mythique. Saint-Pétersbourg : SYMBOL+, 1999.

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

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

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

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

9. Technologies de développement de logiciels. - Saint-Pétersbourg : Peter, 2002.

10. Programmation Térékhov. M. : BINOM, 2006.

11. Rambo J. Processus de développement logiciel unifié. Saint-Pétersbourg : 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. Outils d'évaluation du 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. Les fonctions de production dans l'économie. Exemples d'application dans l'analyse des processus économiques. Profit. Calcul d'indicateurs affectant le résultat, représentation graphique du seuil de rentabilité. Méthodologie pour la mise en œuvre de la politique d'investissement.

Un cours de théorie économique : un manuel pour les universités / Éd. . -Kirov: "ACA", 2004. Kolemaev - modélisation mathématique. Modélisation des processus et systèmes macroéconomiques : manuel. M.: UNITY-DANA, 2005. Cybernétique Bazhin. Kharkiv : Consul, 2004. Atelier Leushin sur les méthodes de modélisation mathématique : manuel. État de Nijni Novgorod technologie. Université - N. Novorod, 2007. Politiciens à propos de l'économie : conférences de lauréats du prix Nobel d'économie. Moscou : Économie et droit modernes, 2005. Cheremnykh. Niveau avancé : Manuel.-M.:INFRA-M, 2008. L'évolution des institutions de la mini-économie. Institut d'économie de la branche de l'Oural de l'Académie russe des sciences, - M.: Nauka, 2007.

Technologies pour le développement et l'adoption de décisions managériales [N]

La prise de décision est la base de l'activité d'un manager. Introduction à la théorie de la décision. Concepts de base de la théorie de la décision. Les modèles de gestion d'entreprise et leur impact sur la prise de décision. Différentes manières classement des solutions. Classifications : selon le degré de formalité, selon le degré de routine, selon la fréquence, selon l'urgence, selon le degré de réalisation des objectifs, selon la méthode de choix d'une alternative. Méthodes de base de prise de décision. Méthodes volitionnelles de prise de décision. Objectifs décisionnels. Il est temps de trouver des solutions. Erreurs de base Méthodes mathématiques de prise de décision. Aspects mathématiques de la théorie de la prise de 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 prise de décision. Modèles de la théorie des files d'attente. Modèles de gestion des stocks. Modèle de programmation linéaire. tâches de transport. Modélisation par simulation. Analyse de réseau. Analyse économique. Limites des modèles rationnels. Caractéristiques du développement et de la prise de décision dans un groupe. L'invention concerne un procédé de détermination de la cohésion d'un groupe basé sur le degré de connexité d'ensembles. Modes de prise de décision collective. méthode consensuelle. modalités de vote. Méthodes créatives de prise de décision. Idée de génie. Conférence d'idées. Conseil des navires. La méthode des chapeaux mentaux par de Bono. Théorie de la résolution de problèmes inventifs (TRIZ). La solution finale idéale. Exemples de problèmes 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 les adapter à la situation. Modèle d'arbre cible. La stratégie de coordination des intérêts. Formation des décisions sur la coordination des 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 de prise de décision. Structure typique d'un système expert. Modes de représentation des connaissances. Méthodes d'inférence logique. Application des systèmes experts dans la pratique.

I. Théorie de la prise de décision: manuel. - M. : Examen, 2006. - 573 p. I. Prise de décision. Théorie et méthodes d'élaboration des décisions de gestion. Didacticiel. - M. : mars 2005. - 496 p.Élaboration d'une décision de gestion - M. : Maison d'édition Delo, 2004 - 392 p. G. Expertises et prise de décision - M. : Brevet, 1996. - 271 p. Taha // Introduction à la recherche opérationnelle = Recherche opérationnelle : une introduction. - 7e éd. - M. : "Williams", 2007. - S. 549-594. G.Theil. Prévisions économiques et prise de décision. M. : Progress, 1970. K. D. Lewis. Méthodes de prévision des indicateurs économiques. M.: "Finances et statistiques" 1986. G. S. Kildishev, A. A. Frenkel. Analyse et prévision de séries chronologiques. M.: "Statistiques" 1973. O. Kim, C. W. Muller, W. R. Klekka et al Analyse factorielle, discriminante et par grappes. M. : "Finances et statistiques" 1989. Gestionnaire efficace. Livre 3. Prise de décision. - MIM LINK, 1999 Turevsky et la direction d'une entreprise de transport automobile. - M. : lycée, 2005. , ; éd. . Analyse système en gestion : Didacticiel. - M.: Finances et statistiques, 2006. , Tinkov: manuel. – M. : KNORUS, 2006.

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

Quels sont les principes des processus métier ? Quel est le problème d'une description holistique des processus d'affaires. Qu'est-ce qu'un système, quelles propriétés possède-t-il ? Le rôle de l'analyse des systèmes dans la modélisation des processus métier ? Le processus comme objet de contrôle. Environnement de processus. Eléments de base d'un 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 place des exigences ISO 9001:2008. Méthodologie SADT (Structured Analysis and Design Technique - une méthode d'analyse et de conception structurelles). Essence. Dispositions de base. Comment se présente le modèle fonctionnel d'activité dans la méthodologie IDEF0 ? Que signifient les travaux dans les schémas du modèle fonctionnel, comment sont-ils affichés selon la méthodologie IDEF0 ? A quoi servent les flèches dans les schémas de modèles fonctionnels, quels sont leurs types et leurs types ? Méthodologie DDF. Essence. Composants de base des cartes DFD. Quelles sont les caractéristiques des diagrammes DFD, qu'est-ce qui y est décrit ? Quelles sont les caractéristiques des objets de diagramme DFD ? Que représentent les flèches sur le diagramme DFD ? Méthodologie IDEF3. Essence. Moyens de documentation et de modélisation. Quelles sont les fonctionnalités des diagrammes IDEF3, que décrivent-ils ? Quelles sont les fonctionnalités des objets de diagramme IDEF3 ? Et le tireur ? Classement des processus. Processus commerciaux typiques. La réingénierie et sa technologie. Quand est-il opportun d'utiliser la réingénierie dans la gestion d'une entreprise ? Surveillance et mesure des processus. Indicateurs des processus de l'organisation. Évaluation numérique et nominale des processus.

"Modélisation des processus métiers avec AllFusion Process Modeler (BPwin 4.1) Dialog-MEPhI" 2003 "Création de systèmes d'information avec AllFusion Modeling Suite" éd. "Dialogue-MEPhI" 2003 "La pratique de la modélisation fonctionnelle avec AllFusion Process Modeler 4.1. (BPwin) Où ? Pourquoi ? Comment ?" éd. "Dialogue-MEPhI" 2004 Modélisation Dubeikovsky avec AllFusion Process Modeler (BPwin). éd. "Dialogue-MEPhI" 2007 D. Mark, K. McGowan "Méthodologie d'analyse structurelle et de conception SADT" 1993 ouvrage classique sur la méthodologie SADT. Analyse Cheremnykh des systèmes : IDEF-technologies, Modélisation et analyse des systèmes. Technologies IDEF. Atelier. M. : Finances et statistiques, 2001. , « Modèles d'affaires structurels : DFD-technologies » http://www. /Niveau4.asp? ItemId=5810 "Théorie et pratique de la réorganisation des processus métier"2003/ P50.1.. Méthodologie de la modélisation fonctionnelle. Moscou : Gosstandart de Russie, 2000. http://www. IDEF0, IDEF3, DFDhttp://www. Modélisation des processus métier au moyen de BPwin http://www. /department/se/devis/7/ IDEF0 dans la gestion de la modélisation des processus métier 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 des processus du domaine Planification et Organisation

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

5. Liste des processus du domaine Exploitation et Maintenance

6. Liste des processus du domaine Suivi et Evaluation

7. Caractérisation 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 des affaires 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érer les droits de propriété intellectuelle sur les résultats de l'activité intellectuelle et divulguer leur contenu.

2. Énumérez les types de contrats pour la cession du droit exclusif. Décrivez chacun de ces contrats sur la cession du droit exclusif.

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

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

6. Décrire les conditions de brevetabilité des objets du droit de brevet : inventions ; modèles utiles; échantillons industriels.

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

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

9. Donner une définition du "savoir-faire" et énumérer les conditions dans lesquelles naît et s'exerce la protection juridique des secrets de production.

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

1., Droit de la propriété intellectuelle dans la Fédération de Russie, manuel // M, Prospekt, 2007

2., Droit de la propriété intellectuelle, manuel // M, RIOR, 2009

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

Qu'est-ce qu'une méthodologie, pourquoi est-elle nécessaire. La structure générale de la méthodologie, les principaux éléments de la méthodologie. Principes de conception de sa propre méthodologie. Exemples de divers artefacts, rôles, compétences, conditions aux limites. Structure de la méthodologie Cowburn, métriques de la méthodologie. Critères du projet Cowburn. Critères de sélection de la méthodologie, matrice de Cowburn. Cycle de vie d'un projet. Modèles de cycle de vie en cascade et itératifs. Limites d'applicabilité pour les modèles en cascade et itératifs. RUP comme exemple de méthodologie itérative. Concepts RUP de base, limites d'applicabilité. Rôle humain dans le développement logiciel. Méthodologies agiles, principes de base des méthodologies agiles. L'origine des méthodologies agiles. Scrum comme exemple de méthodologie agile. Rôles, artefacts, activités dans Scrum. Les limites d'applicabilité de 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 pour documenter le projet et le produit, les principaux types de documents. Exemples de pratiques de gestion des exigences à partir des méthodologies abordées dans le cours. Planification du développement logiciel. Types de plans, gestion des risques, risques populaires. Exemples de pratiques de planification du développement à partir des méthodologies abordées dans le cours. Tests en développement logiciel. Le concept d'assemblage (construction) d'un produit logiciel. Méthodes de test de base, termes. Exemples de pratiques de test à partir des méthodologies abordées dans le cours. Le concept d'assemblage (build), les modes de stockage du code, les outils. Deux principes pour organiser le travail avec un système de contrôle de version. Caractéristiques du processus de lancement/mise en page du produit pour différentes catégories de produits, exemples de pratiques. Concepts modernes d'architecture logicielle, architectures multiniveaux, critères d'architecture. Liste des décisions nécessaires lors de la conception d'un logiciel, approches pour choisir un système de stockage de données.

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

Informatique, cybernétique et programmation

Itération N Processus de développement logiciel unifié USDP Le modèle de cas d'utilisation 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 connexions et les relations entre les classes et les objets dédiés, tandis que le modèle de déploiement décrit la répartition des logiciels sur les ordinateurs.

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

Modèles de développement logiciel

1. Vodopadnaïa
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

Concevoir

Mise en œuvre

Composant

essai

L'intégration

Essai

ensemble

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

Processus de développement logiciel unifié (USDP)

1. Le modèle de cas d'utilisation décrit les cas 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 connexions 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 d'implémentation décrit l'organisation interne du code du programme.
6. Le modèle de test se compose de composants de test, de procédures de test et de différents cas de test.

Méthodologie MSF

Composants typiques de l'architecture du produit logiciel et exigences logicielles typiques

tolérance aux pannesun ensemble de propriétés du système qui augmentent sa fiabilité en détectant les erreurs, en restaurant et en localisant les mauvaises conséquences pour le système. Lors de la conception de tout système réel pour assurer la tolérance aux pannes, il est nécessaire d'anticiper toutes les situations possibles pouvant conduire à une défaillance du système et de développer des mécanismes de gestion des défaillances.

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

Refus est la transition du systèmeà la suite de l'erreur à un état complètement inutilisable.

crash une erreur dans le fonctionnement du système qui n'entraîne pas la défaillance du système.

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

Ainsi que d'autres travaux qui pourraient vous intéresser
57355.		Variété de composés organiques, leur classification. Substances organiques de la nature	48.5Ko
	La variété des composés organiques est déterminée par la capacité unique des atomes de carbone à se combiner entre eux par des liaisons simples et multiples pour former des composés avec un nombre presque illimité d'atomes liés en chaînes, cycles, bicyclettes, tricycles, polycycles, 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. Synopsis Synopsis de lat. Créez un plan pour 2. Enregistrez le document dans votre propre dossier sous le nom Résumé.
57361.		Chiffre et nombre 3. Appariement des nombres aux frontières 3. Chiffres écrits 3. Appariement des objets anciens	35,5 Ko
	Nombre de toutes les créatures Qui devrait être le premier Qui devrait être le dernier Qui devrait être sous le numéro 1 Qui devrait être sous le numéro 2 Qui est le susid écureuil droitier Qui est la susid girafe gaucher

Il existe des modèles de développement logiciel. Et il y a des méthodologies. Il y a beaucoup d'informations contradictoires sur Internet sur ce qui est quoi et comment les distinguer. Il peut être difficile pour un débutant de comprendre cela. Dans cet article, nous mettrons les points sur 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. Il s'agit le plus souvent de préparation, de conception, de création et d'accompagnement. Les étapes peuvent être appelées différemment et peuvent être divisées en étapes plus petites.

Considérez ces étapes sur l'exemple du cycle de vie d'une boutique en ligne.

Entraînement. Ivan a décidé de lancer une librairie en ligne et a commencé à analyser les sites similaires déjà présents sur le réseau. Informations collectées sur leur trafic, leurs fonctionnalités.

Concevoir. Ivan a choisi un entrepreneur et a discuté avec ses spécialistes de l'architecture et du design de la future boutique en ligne.

Création. Ivan a signé un accord avec les développeurs. Ils ont commencé à écrire du code, à dessiner des conceptions, à écrire de la documentation.

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

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

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

Modèles de développement logiciel de base

• Code and fix - un modèle pour coder et corriger les erreurs ;
• Modèle en cascade - modèle en cascade ou "cascade" ;
• Modèle en V - Modèle en forme de V, développement piloté par les tests ;
• Modèle incrémental - modèle incrémental ;
• Modèle itératif - modèle itératif (ou itératif) ;
• Modèle en spirale - modèle en spirale ;
• modèle du chaos - modèle du chaos ;
• Modèle prototype - modèle prototype.

Parmi ces modèles, les cinq principaux sont les plus populaires : en cascade, en 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 s'effectue par étapes : chaque étape suivante ne commence qu'après la fin de la précédente. Bien faite, 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 les programmeurs font maintenant, peut gérer le calendrier et les coûts.
• Le coût du projet est déterminé au stade initial. Toutes les étapes sont déjà prévues au stade de la conclusion du contrat, le logiciel est écrit en continu "de et vers".
• Pas besoin d'embaucher des testeurs avec une solide formation technique. Les testeurs pourront s'appuyer sur une documentation technique détaillée.

Inconvénients du modèle en 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 découvriront lorsque le développeur aura déjà écrit le code, et les rédacteurs techniques - la documentation.
• Le client voit le produit fini à la fin du développement et ce n'est qu'alors qu'il peut donner retour d'information. Il est fort probable 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 complète, plus les changements doivent être apportés et plus ils doivent être approuvés.

"Waterfall" convient au développement de projets dans l'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 des exigences pour de nouveaux logiciels.

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 doit pas être clair qu'ils ont un bogue qui affecte l'ensemble du produit.

Modèle en forme de V (développement piloté par les tests)

Il s'agit d'un modèle en cascade avancé dans lequel le client et l'équipe de programmation écrivent simultanément les exigences du système et décrivent comment il sera testé à chaque étape. L'histoire de ce modèle commence dans les années 1980.

Avantages du modèle en V

Le nombre d'erreurs dans l'architecture logicielle est réduit au minimum.

Inconvénients du modèle en V

Si une erreur a été commise dans la conception de l'architecture, il sera alors coûteux de revenir en arrière 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 d'airbags pour les voitures ou de systèmes de surveillance pour les patients dans les cliniques.

Modèle incrémental (modèle incrémental)

Ce modèle de développement par parties (incrément en traduction de l'anglais - incrément) trouve ses racines dans les années 1930. Considérez-le sur l'exemple de la création d'un réseau social.

1. Le client a décidé qu'il souhaitait lancer un réseau social et a rédigé un cahier des charges détaillé. Les programmeurs ont proposé d'implémenter les fonctions principales - une page avec renseignements personnels et discuter. Et puis tester sur les utilisateurs, "décoller ou pas".
2. L'équipe de développement montre le produit au client et le met sur le marché. Si le client et les utilisateurs réseau social Je l'aime bien, le travail continue, mais par parties.
3. Les programmeurs créent simultanément des fonctionnalités pour télécharger des photos, échanger des documents, écouter de la musique et d'autres actions convenues avec le client. Incrément par 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

• Pas besoin d'investir beaucoup d'argent au stade initial. Le client paie pour la création des fonctions principales, reçoit le produit, le "déploie" sur le marché - et, sur la base des résultats du retour d'information, décide de poursuivre ou non le développement.
• Vous pouvez obtenir rapidement les 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 coûte moins cher. Si une erreur a été commise lors du développement de l'architecture, sa réparation ne coûtera pas autant que dans le modèle «cascade» ou en forme de V.

Inconvénients du modèle incrémental

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

Modèle incrémental adapté à des projets dans lesquels les termes de référence exacts sont déjà écrits au départ, et le produit doit entrer rapidement sur le marché.

Modèle itératif (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 recevoir en conséquence et ne peut pas prescrire immédiatement une tâche technique détaillée.

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

1. Le client a décidé qu'il voulait créer un messager. Les développeurs ont créé une application où vous pouvez ajouter un ami et démarrer une conversation à deux.
2. Le messager a été "déployé" sur l'App Store, 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 l'améliorer.
3. Les programmeurs ont ajouté la possibilité de regarder des vidéos, de télécharger des photos, d'enregistrer des messages audio sur le messager. Ils améliorent progressivement les fonctionnalités de l'application, l'adaptent aux exigences du marché.

Avantages du modèle itératif

• Libération rapide du produit minimum vous permet de recevoir rapidement les commentaires 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 du client.
• Tests utilisateurs continus vous permet de détecter et de corriger rapidement les erreurs.

Inconvénients du modèle itératif

• Première utilisation de bases de données ou de serveurs- les premiers sont difficiles à escalader et les seconds ne supportent pas la charge. Vous devrez peut-être réécrire la majeure partie de l'application.
• Absence de budget fixe et de délais. Le client ne sait pas à quoi ressemble l'objectif final et quand le développement se terminera.

Le modèle itératif est adapté pour travailler sur grands projets avec des exigences incertaines, ou pour les tâches avec approche innovative lorsque le client n'est pas sûr du résultat.

Modèle en spirale (modèle en spirale)

En utilisant 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 cycle d'itération, une décision est prise de poursuivre ou non le projet. Ce modèle a commencé à être utilisé en 1988.

Considérons comment ce modèle fonctionne, en prenant l'exemple du développement du système "Smart Home".

1. Le client a décidé qu'il voulait 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é comment ils allaient l'implémenter, développé, testé et « déployé » le produit final.
2. Le client a évalué le résultat et les risques : dans quelle mesure les utilisateurs ont-ils besoin de la prochaine version du produit - déjà avec contrôle TV. Calculer les termes, le budget et ordonner le développement. Les programmeurs ont agi selon le modèle en cascade et ont présenté au client un produit plus complexe développé sur la base du 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, j'ai réalisé qu'il est 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 éventuellement comment développer le système Smart Home.

Le modèle en spirale est similaire au modèle incrémental, mais beaucoup plus de temps est consacré à l'évaluation des risques. A 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 rester bloqué 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.

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

Qu'est-ce qu'Agilité ?

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 allégés (Lean);
• cadre de gestion de projet Scrum ;
• développement piloté par les fonctionnalités (FDD) ;
• le développement par les tests (Test Driven Development, TDD) ;
• méthodologie de la « salle blanche » (Cleanroom Software Engineering) ;
• méthode de développement itératif-incrémental (OpenUP);
• méthodologie Développement Microsoft Cadre de solutions (MSF);
• méthode de développement de systèmes dynamiques (DSDM);
• Méthode de gestion du développement Kanban.

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

Tout sur la liste n'est pas de la méthodologie. Par exemple, Scrum est 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. En plus de Scrum, Kanban est souvent utilisé.

Kanban

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

Contrairement à Scrum, dans Kanban, vous pouvez prendre des tâches urgentes en développement immédiatement, 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.

Très prochainement, nous organiserons un événement de trois jours. Vous y apprendrez à utiliser tous les avantages de cette approche, à gérer des projets de développement et de publication de toute complexité. Dans votre attente!