maison › Multimédia › Approches du développement de logiciels. Une approche structurée du développement logiciel. Principes et signification du développement agile

Approches du développement de logiciels. Une approche structurée du développement logiciel. Principes et signification du développement agile

1.Codage

Au stade du développement du logiciel, les principales actions suivantes sont réalisées : codage ; essai; développement d'un système d'aide PP ; création de documentation utilisateur; création d'une version et installation du logiciel,

Le codage est le processus de conversion des résultats de conception de haut niveau et de bas niveau en un produit logiciel fini. Autrement dit, lors du codage, le modèle logiciel compilé est décrit à l'aide du langage de programmation choisi, qui peut être n'importe lequel des langages existants. Le choix de la langue s'effectue soit à la demande du client, soit en tenant compte du problème à résoudre et expérience personnelle développeurs.

Lors du codage, vous devez suivre la norme du langage sélectionné, par exemple, pour le langage C, c'est ANSI C, et pour C++, c'est ISO/IEC 14882 « Standard pour le langage de programmation C++ ».

En plus de la norme généralement acceptée pour un langage de programmation, une entreprise peut également développer ses propres exigences supplémentaires concernant les règles d'écriture de programmes. Elles concernent principalement les règles de formatage du texte du programme.

Suivre les règles standard et d'entreprise vous permet de créer un programme qui fonctionne correctement, qui est facile à lire et compréhensible pour les autres développeurs, contenant des informations sur le développeur, la date de création, le nom et le but, ainsi que les données nécessaires à la gestion de la configuration.

Au stade du codage, le programmeur écrit des programmes et les teste lui-même. Ce type de test est appelé test unitaire. Tous les problèmes liés aux tests logiciels sont abordés dans le chapitre. 10, la technologie de test utilisée au stade du développement logiciel est également décrite ici. Cette technologie est appelée test « boîte en verre » (boîte en verre) ; parfois on l'appelle aussi test "boîte blanche" (boîte blanche) par opposition au concept classique de « boîte noire ».

Dans les tests en boîte noire, un programme est traité comme un objet dont la structure interne est inconnue. Le testeur saisit les données et analyse le résultat, mais il ne sait pas exactement comment fonctionne le programme. Lors de la sélection des tests, un spécialiste recherche des données d'entrée et des conditions intéressantes de son point de vue, ce qui peut conduire à des résultats non standards. Il s'intéresse principalement aux représentants de chaque classe de données d'entrée dans lesquels des erreurs dans le programme testé sont les plus susceptibles de se produire.

Lorsqu’on teste une « boîte en verre », la situation est complètement différente. Le testeur (dans ce cas le programmeur lui-même) développe des tests basés sur la connaissance du code source auquel il a accès accès total. En conséquence, il bénéficie des avantages suivants.

1. Direction des tests. Le programmeur peut tester le programme par parties, développer des sous-programmes de test spéciaux qui appellent le module testé et lui transmettent les données qui intéressent le programmeur. Il est beaucoup plus facile de tester un module séparé comme une « boîte en verre ».

2. Couverture complète du code. Le programmeur peut toujours déterminer quels fragments de code fonctionnent dans chaque test. Il voit quelles autres branches du code restent non testées et peut sélectionner les conditions dans lesquelles elles seront testées. Nous décrivons ci-dessous comment suivre le degré de couverture du code des tests effectués.

3. Capacité à contrôler le flux des commandes. Le programmeur sait toujours quelle fonction doit être exécutée ensuite dans le programme et quel doit être son état actuel. Pour savoir si un programme fonctionne comme il le pense, un programmeur peut inclure des commandes de débogage qui affichent des informations sur son exécution, ou utiliser un programme spécial pour ce faire. logiciel appelé un débogueur. Le débogueur peut faire beaucoup de choses utiles : surveiller et modifier la séquence d'exécution des commandes du programme, afficher le contenu de ses variables et leurs adresses en mémoire, etc.

4. Capacité à surveiller l’intégrité des données. Le programmeur sait quelle partie du programme doit modifier chaque élément de données. En surveillant l'état des données (à l'aide du même débogueur), il peut identifier des erreurs telles que des données modifiées par de mauvais modules, leur interprétation incorrecte ou une mauvaise organisation. Le programmeur peut automatiser les tests lui-même.

5.Vision des points limites internes. DANS code source les points limites du programme qui sont cachés à la vue extérieure sont visibles. Par exemple, plusieurs algorithmes complètement différents peuvent être utilisés pour effectuer une certaine action, et sans regarder le code, il est impossible de déterminer lequel a choisi le programmeur. Un autre exemple courant serait un problème de débordement dans un tampon utilisé pour stocker temporairement les données d'entrée. Le programmeur peut immédiatement savoir à partir de quelle quantité de données le tampon va déborder, et il n'a pas besoin d'effectuer des milliers de tests.

6. Possibilité de tests déterminés par l'algorithme sélectionné. Les tests de traitement de données utilisant des algorithmes de calcul très complexes peuvent nécessiter des technologies spéciales. Les exemples classiques incluent la transformation matricielle et le tri des données. Un testeur, contrairement à un programmeur, a besoin de savoir exactement quels algorithmes sont utilisés, il doit donc se tourner vers la littérature spécialisée.

Les tests en boîte de verre font partie du processus de programmation. Les programmeurs font ce travail tout le temps : ils testent chaque module après l'avoir écrit, puis à nouveau après l'avoir intégré dans le système.

Lorsque vous effectuez des tests unitaires, vous pouvez utiliser une technologie de tests structurels ou fonctionnels, ou les deux.

De construction le test est un type de test en boîte de verre. Son idée principale est le bon choix du chemin logiciel à tester. Contrairement à lui fonctionnel les tests entrent dans la catégorie des tests en boîte noire. Chaque fonction du programme est testée en saisissant ses données d'entrée et en analysant sa sortie. Parallèlement, la structure interne du programme est très rarement prise en compte.

Bien que les tests structurels soient beaucoup plus puissants base théorique, la plupart des testeurs préfèrent les tests fonctionnels. Les tests structurels se prêtent mieux à la modélisation mathématique, mais cela ne signifie pas qu’ils sont plus efficaces. Chaque technologie vous permet d'identifier les erreurs manquées lors de l'utilisation de l'autre. De ce point de vue, ils peuvent être qualifiés de tout aussi efficaces.

L'objet du test peut être non seulement chemin complet programme (la séquence de commandes qu'il exécute du début à la fin), mais aussi ses sections individuelles. Il est absolument irréaliste de tester toutes les manières possibles d'exécuter un programme. Par conséquent, les spécialistes des tests identifient, parmi tous les chemins possibles, les groupes qui doivent absolument être testés. Pour la sélection, ils utilisent des critères spéciaux appelés critères de couverture (coveragecritera), qui déterminent un nombre très réel (même s'il est assez important) de tests. Ces critères sont parfois appelés critères de couverture logique, ou critères d’exhaustivité.

3. Développement d'un système d'aide produit logiciel. Création de la documentation utilisateur

Il est conseillé de désigner l'un des employés du projet comme rédacteur technique de la documentation. Cet employé peut également effectuer d'autres travaux, mais sa tâche principale devrait être l'analyse de la documentation, même si d'autres employés l'élaborent également.

Il arrive souvent que plusieurs personnes travaillent à la création d'un logiciel, mais aucune d'entre elles n'assume l'entière responsabilité de sa qualité. En conséquence, non seulement le logiciel ne profite pas du fait qu'il est développé par un plus grand nombre de personnes, mais il perd également, puisque chacun transfère inconsciemment la responsabilité à l'autre et s'attend à ce que ses collègues fassent telle ou telle partie du travail. Ce problème est résolu en désignant un éditeur qui assume l'entière responsabilité de la qualité et de l'exactitude de la documentation technique.

Le système d'aide PP est constitué sur la base du matériel développé pour le manuel d'utilisation. Il est constitué et créé par la personne chargée d'effectuer ces travaux. Il peut s'agir soit d'un éditeur technique, soit d'un des développeurs en collaboration avec l'éditeur technique.

Un PP bien documenté présente les avantages suivants.

1. Facilité d'utilisation. Si le logiciel est bien documenté, il est alors beaucoup plus facile à appliquer. Les utilisateurs apprennent plus rapidement, commettent moins d’erreurs et effectuent ainsi leur travail plus rapidement et plus efficacement.

2. Coût inférieur soutien technique. Lorsque l'utilisateur ne sait pas comment effectuer les actions dont il a besoin, il appelle le service d'assistance technique du fabricant de PCB. Gérer un tel service coûte très cher. Un bon manuel aide les utilisateurs à résoudre les problèmes par eux-mêmes et réduit le besoin de contacter l’équipe d’assistance technique.

3. Haute fiabilité. Une documentation incompréhensible ou bâclée rend le logiciel moins fiable, car ses utilisateurs sont plus susceptibles de commettre des erreurs et ont du mal à comprendre ce qui les a provoquées et comment gérer leurs conséquences.

Facilité d'entretien. Une énorme quantité d’argent et de temps est consacrée à l’analyse des problèmes causés par les erreurs des utilisateurs. Les modifications apportées aux nouvelles versions logicielles sont souvent simplement des modifications apportées à l'interface des anciennes fonctions. Ils sont présentés pour que les utilisateurs comprennent enfin comment utiliser le logiciel et cessent d'appeler le support technique. Bonne gestion dans une large mesure

Informatique, cybernétique et programmation

Processus de développement unifié itération 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 connexions et les relations entre les classes et les objets dédiés. Le modèle de déploiement décrit la distribution des logiciels sur les ordinateurs.

Leçon n°20
Principes généraux et approches du développement de logiciels

Modèles de développement de logiciels

Vodopadnaïa
Modèle en cascade
Spirale
Programmation extrême
Incrémentale
Méthodologie MSF

Modèle cascade

Modèle en spirale

Développement incrémental

Analyse des besoins

Conception

Mise en œuvre

Composant

essai

L'intégration

Essai

un tout

Itération 1 Itération 2…. 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 sélectionnés
Le 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 du programme.
Un modèle de test se compose de composants de test, de procédures de test et de divers scénarios de test.

Méthodologie MSF

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

tolérance aux pannesun ensemble de propriétés du système qui augmente sa fiabilité en détectant les erreurs, en restaurant et en localisant les mauvaises conséquences pour le système. Lors de la conception d'un système réel visant à garantir la tolérance aux pannes, il est nécessaire de prévoir toutes les situations possibles 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.

Refus c'est une transition de systèmeà la suite de l'erreur dans un état totalement inutilisable.

Accident 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 considéré comme fiable.

Ainsi que d'autres ouvrages qui pourraient vous intéresser
57355.		Variété de composés organiques, leur classification. Substances organiques de la nature vivante	48,5 Ko
	La diversité 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 reliés en chaînes : cycles, vélos, tricycles, polycycles, charpentes, 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 une note pour 2. Enregistrez le document dans son propre dossier sous le nom Note.
57361.		Nombre et figure 3. Aligner les nombres aux limites 3. Écrire des nombres 3. Aligner le nombre d'objets	35,5 Ko
	Combien y a-t-il de créatures Qui se classe en premier Qui se classe en dernier Qui se classe au numéro 1 Qui se classe au numéro 2 Nommez les voisins du hérisson. Qui est l'écureuil droitier Qui est la girafe gauchère Qui est le plus grand Qui est le plus petit Qui se tient au milieu des créatures Gra Montre-moi, n'aie pas pitié.

Aujourd'hui, en génie logiciel, il existe deux approches principales pour le développement de logiciels EIS, dont la différence fondamentale est due à différentes façons décomposition des systèmes. La première approche est dite fonctionnelle-modulaire ou structurelle. Il repose sur le principe de décomposition fonctionnelle, dans lequel la structure du système est décrite en termes de hiérarchie de ses fonctions et de transfert d'informations entre les individus. éléments fonctionnels. La deuxième approche, orientée objet, utilise la décomposition d'objets. Dans ce cas, la structure du système est décrite en termes d'objets et de connexions entre eux, et le comportement du système est décrit en termes d'échange de messages entre objets.

Ainsi, l'essence de l'approche structurelle du développement de logiciels EIS réside dans sa décomposition (décomposition) en fonctions automatisées : le système est divisé en sous-systèmes fonctionnels, qui, à leur tour, sont divisés en sous-fonctions, ceux en tâches, et ainsi de suite jusqu'à procédures spécifiques. Dans le même temps, le système automatisé conserve une vision globale dans laquelle tous les composants sont interconnectés. Lors du développement d'un système « ascendant », des tâches individuelles à l'ensemble du système, l'intégrité est perdue, des problèmes surviennent lors de la description interaction informationnelle composants individuels.

Toutes les méthodes les plus courantes de l’approche structurelle reposent sur un certain nombre de principes généraux. Les principes de base sont :

le principe « diviser pour régner » (voir sous-section 2.1.1) ;

le principe de l'ordre hiérarchique est le principe d'organisation des composants d'un système en structures arborescentes hiérarchiques avec l'ajout de nouveaux détails à chaque niveau.

Mettre en évidence deux principes de base ne signifie pas que les autres principes sont secondaires, car ignorer l'un d'entre eux peut entraîner des conséquences imprévisibles (y compris l'échec de l'ensemble du projet). Les principaux de ces principes sont :

le principe d'abstraction - mettre en évidence les aspects essentiels du système et faire abstraction de ce qui n'est pas important ;

principe de cohérence - validité et cohérence des éléments du système ;

principe de structuration des données - les données doivent être structurées et organisées hiérarchiquement.

L'approche structurelle utilise principalement deux groupes d'outils qui décrivent la structure fonctionnelle du système et les relations entre les données. Chaque groupe d'outils correspond à certains types de modèles (schémas), dont les plus courants sont :

DFD (Data Flow Diagrams) - diagrammes de flux de données ;

SADT (Structured Analysis and Design Technique - méthode d'analyse et de conception structurelle) - modèles et schémas fonctionnels correspondants ;

ERD (Entity-Relationship Diagrams) - diagrammes entité-relation.

Les diagrammes de flux de données et les diagrammes entité-relation sont les types de modèles les plus couramment utilisés dans les outils CASE.

Vue spécifique des diagrammes répertoriés et l’interprétation de leurs conceptions dépendent de l’étape du cycle de vie du logiciel.

Au stade de la formation des exigences logicielles, les modèles SADT et DFD sont utilisés pour construire le modèle « AS-IS » et le modèle « TO-BE », reflétant ainsi la structure existante et proposée des processus métier de l'organisation et l'interaction entre eux ( l'utilisation des modèles SADT, en règle générale, est limitée à cette étape, car ils n'étaient pas initialement destinés à la conception de logiciels). Avec l'aide d'ERD, une description des données utilisées dans l'organisation est réalisée à un niveau conceptuel, indépendant des outils de mise en œuvre de bases de données (SGBD).

Au stade de la conception, les DFD sont utilisés pour décrire la structure du système logiciel conçu, et ils peuvent être affinés, étendus et complétés par de nouvelles conceptions. De même, les ERD sont affinés et complétés par de nouvelles constructions qui décrivent la représentation des données à un niveau logique adapté à la génération ultérieure d'un schéma de base de données. Ces modèles peuvent être complétés par des diagrammes reflétant l'architecture du système logiciel, des schémas fonctionnels de programme, la hiérarchie formulaires d'écran et menu, etc.

Les modèles répertoriés fournissent ensemble une description complète du logiciel EIS, que le système soit existant ou nouvellement développé. La composition des schémas dans chaque cas spécifique dépend de la complexité du système et de l'exhaustivité requise de sa description.

Le domaine de la plupart des exemples de diagrammes donnés dans ce chapitre est le système fiscal de la Fédération de Russie, dont la description la plus complète est contenue dans le Code des impôts de la Fédération de Russie. Informatique, utilisés dans le système fiscal de la Fédération de Russie, présentent certaines caractéristiques.

Ainsi, l'essence de l'approche structurelle du développement de logiciels EIS réside dans sa décomposition (décomposition) en fonctions automatisées : le système est divisé en sous-systèmes fonctionnels, qui, à leur tour, sont divisés en sous-fonctions, ceux en tâches, et ainsi de suite jusqu'à procédures spécifiques. Dans le même temps, le système conserve une vision globale dans laquelle tous les composants sont interconnectés. Lors du développement d'un système « ascendant », des tâches individuelles à l'ensemble du système, l'intégrité est perdue et des problèmes surviennent lors de la description de l'interaction informationnelle des composants individuels.

Toutes les méthodes les plus courantes de l'approche structurelle reposent sur un certain nombre de principes généraux :

1. Le principe « diviser pour mieux régner » ;

2. Le principe de l'ordre hiérarchique est le principe d'organisation des composants d'un système en structures arborescentes hiérarchiques avec l'ajout de nouveaux détails à chaque niveau.

Isoler deux principes fondamentaux ne signifie pas que les principes restants sont secondaires, car ignorer l'un d'entre eux peut entraîner des conséquences imprévisibles (y compris l'échec de l'ensemble du projet"). Les principaux de ces principes sont :

1. Le principe d'abstraction - mettre en évidence les aspects essentiels du système et faire abstraction de ce qui n'est pas important.

2. Le principe de cohérence, de validité et de cohérence des éléments du système.

3. Principe structurant données - données doit être structuré et hiérarchisé.

Dans l’approche structurelle, il existe principalement deux groupes d’outils qui décrivent la structure fonctionnelle du système et les relations entre les données. Chaque groupe d'outils correspond à certains types de modèles (schémas), les plus courants d'entre eux sont :

· DFD (Data Flow Diagrams) - diagrammes de flux de données ;

· SADT (Structured Analysis and Design Technique - méthodologie d'analyse et de conception structurelle) - modèles et schémas fonctionnels correspondants : notations IDEF0 (modélisation fonctionnelle des systèmes), IDEF1х (modélisation conceptuelle de bases de données), IDEF3х (construction de systèmes d'évaluation de la qualité des le travail d'un objet ; description graphique flux de processus, interaction des processus et des objets modifiés par ces processus) ;

· ERD (Diagrammes Entité - Relation) - diagrammes entité-relation.

Presque toutes les méthodes de l'approche structurelle (analyse structurelle) au stade de la formation des exigences logicielles utilisent deux groupes d'outils de modélisation :

1. Diagrammes illustrant les fonctions que le système doit remplir et les relations entre ces fonctions - DFD ou SADT (IDEF0).

2. Diagrammes qui modélisent les données et leurs relations (ERD).

La forme spécifique des diagrammes répertoriés et l'interprétation de leurs conceptions dépendent de l'étape du cycle de vie du logiciel.

Au stade de la formation des exigences logicielles, les modèles SADT et DFD sont utilisés pour construire le modèle « AS-IS » et le modèle « TO-BE », reflétant ainsi la structure existante et proposée des processus métier de l'organisation et l'interaction entre eux ( l'utilisation des modèles SADT qui sont généralement limités à cette étape uniquement, car ils n'étaient pas initialement destinés à la conception de logiciels). Avec l'aide d'ERD, une description des données utilisées dans l'organisation est réalisée au niveau conceptuel, quels que soient les outils de mise en œuvre de bases de données (SGBD).

1. Objectif de la technologie de programmation. 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 tours. Jalons et artefacts. Parties prenantes et salariés.

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

4. Conception architecturale et détaillée. Implémentation et codage. Tests et vérification. Processus de contrôle qualité. Méthodes boîte blanche et boîte noire. Inspections et examens. Objectifs des tests. Vérification, validation et tests 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 de processus de développement flexibles.

6. Construction d'un modèle de processus. Identifiez les exigences du processus. Phases, jalons et artefacts utilisés. Choisir une architecture de processus. Procédure de réalisation d'un projet standard. Procédures documentées.

7. Modèles d'équipe de développement. Caractère collectif du développement. Taille d'équipe optimale. Subordination des participants au projet. Développement d’équipe et développement du personnel. Spécialisation, coopération et interaction.

8. Modèles d'équipe de développement. Modèle d'équipe hiérarchique. Méthode de l'é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. Prestations de service. Architecture à trois couches. Conception du programme. Design conceptuel. 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 de logiciels. – Saint-Pétersbourg. : Pierre, 2004.

4. Brooks Jr. sont conçus et créés systèmes logiciels. M. : Nauka, 1975 ; nouvelle édition de la traduction : Le Mois-Homme Mythique. SPb. : SYMBOLE+, 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 Terekhov. 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. Lisser les 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 en économie. Exemples d'application dans l'analyse des processus économiques. Profit. Calcul des indicateurs affectant le résultat, image graphique seuil de rentabilité. Méthodologie de mise en œuvre de la politique d'investissement.

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 Leushin sur les méthodes de modélisation mathématique : manuel. État de Nijni Novgorod technologie. univ. - N. Novorod, 2007. Les hommes politiques sur l'économie : Conférences des 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 la mini-économie. Institut d'économie, branche Oural de l'Académie des sciences de Russie, - M. : Nauka, 2007.

Technologies pour le développement et la prise de décision en matière de gestion [N]

La prise de décision comme 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. 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é d'atteinte des objectifs, selon la méthode de choix d'une alternative. Méthodes de base de prise de décision. Méthodes volontaires de prise de décision. Objectifs de la prise de décision. Temps de recherche de solutions. Erreurs fondamentales 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 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 en groupe. Une méthode pour déterminer la cohésion de groupe basée sur le degré de connectivité des ensembles. Méthodes de prise de décisions collectives. Méthode consensuelle. Méthodes de vote. Méthodes créatives de prise de décision. Idée de génie. Conférence d'idées. Conseil du navire. La méthode « Thinking Hats » de De Bono. Théorie de la résolution inventive de problèmes (TRIZ). La solution finale parfaite. Exemples de problèmes et leurs solutions avec TRIZ. Application des méthodes TRIZ lors de la prise de 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 d'objectifs. Stratégie de coordination des intérêts. Formation de décisions pour coordonner 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). Histoire de la création des systèmes de prise de décision. Classification des systèmes de prise de décision. Structure typique système expert. Méthodes de pré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. : MarT, 2005. - 496 pp. Évolution des décisions de gestion - M. : Maison d'édition "Delo", 2004 - 392 pp. 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. - P. 549-594. G. Theil. Prévisions économiques et prise de décision. M. : « Progrès » 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, U. R. Klekka et autres. Analyse factorielle, discriminante et groupée. M. : « Finances et Statistiques » 1989. Gestionnaire efficace. Livre 3. Prise de décision. – MIM LINK, 1999 Turevsky et gestion d'une entreprise de transport automobile. - M. : Ecole Supérieure, 2005. , ; édité par . Analyse du système en gestion : Didacticiel. – M. : Finances et Statistiques, 2006. , Tinkov : manuel. – M. : KNORUS, 2006.

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

Par quels principes les processus métier se distinguent-ils ? 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étiers ? Le processus comme objet de contrôle. Environnement de processus. Éléments de base d'un processus métier. Avantages et inconvénients de la gestion fonctionnelle et des processus. Cycle de gestion du 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 et de conception structurelle). 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 du modèle fonctionnel, comment sont-elles affichées selon la méthodologie IDEF0 ? A quoi servent les flèches dans les diagrammes de modèles fonctionnels, quels sont leurs types et types ? Méthodologie DFD. Essence. Composants de base des diagrammes DFD. Quelles sont les caractéristiques des diagrammes DFD et qu'est-ce qui y est décrit ? Quelles sont les caractéristiques des objets de diagramme DFD ? Que signifient les flèches sur un diagramme DFD ? Méthodologie IDEF3. Essence. Outils de documentation et de modélisation. Quelles sont les caractéristiques des diagrammes IDEF3 et qu'est-ce qui y est décrit ? Quelles sont les fonctionnalités des objets diagramme IDEF3 ? Et le tireur ? Classification des processus. Processus commerciaux typiques. La réingénierie et sa technologie. Quand est-il conseillé de recourir à la réingénierie dans la gestion d’une entreprise ? Processus de surveillance et de mesure. Indicateurs des processus organisationnels. Évaluations numériques et notées 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" ed. "Dialog-MEPhI" 2003 "Pratique de la modélisation fonctionnelle avec AllFusion Process Modeler 4.1. (BPwin) Où ? Pourquoi ? Comment ?" éd. "Dialogue-MEPhI" 2004 Modélisation Dubeykovsky 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 : technologies IDEF, Modélisation et analyse des systèmes. Technologies IDEF. Atelier. M. : Finances et Statistiques, 2001. « Modèles d'affaires structurels : technologies DFD » http://www. /Niveau4.asp ? ItemId=5810 "Théorie et pratique de la réorganisation des processus métiers" 2003/ P50.1.. Méthodologie de modélisation fonctionnelle. M. : Gosstandart de Russie, 2000. http://www. IDEF0, IDEF3, DFD http://www. Modélisation des processus métiers à l'aide de BPwin http://www. /department/se/devis/7/ IDEF0 dans la modélisation des processus de gestion d'entreprise http:///content/view/21/27/ http://www. /dir/cat32/subj45/file1411/view1411.html http://www. http://www.

Évaluer 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 dans le domaine du suivi et de l'é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 des applications. 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. Répertoriez les droits intellectuels sur les résultats de l'activité intellectuelle et divulguez leur contenu.

2. Énumérez les types d'accords pour la cession de droits exclusifs. Décrivez chacun de ces accords sur la cession de droits exclusifs.

4. Décrire les principales dispositions de protection juridique d'un programme informatique en tant qu'objet de droit d'auteur.

5. Comparez les principales dispositions de 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 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écrire les conditions et la procédure d'obtention d'un brevet pour une invention, un modèle d'utilité ou un dessin industriel, ainsi que les conditions assurant la validité des brevets et leurs durées de validité.

9. Définir le « savoir-faire » et énumérer les conditions au cours de la création desquelles 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. Droits de propriété intellectuelle dans Fédération Russe, manuel // M, Perspectives, 2007

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

Gestion de projets et de développement de logiciels [I]

Qu'est-ce que la méthodologie, pourquoi est-elle nécessaire. Structure générale de la méthodologie, 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. La structure de la méthodologie selon Cowburn, les métriques méthodologiques. Critères de conception de Cowburn. Critères de choix d'une 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 de base du RUP, limites d'applicabilité. Le rôle de l'humain dans le développement de logiciels. Méthodologies agiles, principes de base des méthodologies agiles. La raison de l'émergence de méthodologies flexibles. Scrum comme exemple de méthodologie flexible. Rôles, artefacts, activités dans Scrum. 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 de documentation d'un projet et d'un produit, principaux types de documents. Exemples de pratiques de gestion des exigences tirées 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 tirées des méthodologies abordées dans le cours. Tests dans le développement de logiciels. Le concept d'assemblage (build) d'un produit logiciel. Méthodes de test de base, termes. Exemples de pratiques de test tirées des méthodologies abordées dans le cours. Le concept d'assembly (build), les méthodes 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 sortie/affichage des produits pour différentes catégories de produits, exemples de pratiques. Concepts modernes d'architecture logicielle, architectures multi-niveaux, critères d'architecture. Liste des décisions nécessaires lors de la conception de logiciels, approches pour choisir un système de stockage de données.

Kent Beck - Extreme Programming Frederick Brooks - Le mois-homme mythique ou comment les systèmes logiciels sont créés. Tom DeMarco – Date limite. Un roman sur la gestion de projet. Tom De Marco, Timothy Lister - Valser avec les ours. Tom de Marco, Timothy Lister - 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 dans la création de logiciels. Andriy Orlov - Notes d'un ingénieur en automation. Confession professionnelle. Philipp Kratchen - Introduction au processus rationnel unifié. Henrik Kniberg - Scrum et XP : notes des premières lignes. Présentations des cours magistraux du cours

Populaire dans la catégorie :