Genie logiciel

L’objectif d’un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement logiciel, c’est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c’est-à-dire l’adéquation des méthodes sises en couvre. L’origine de ce découpage provient du constat que les erreurs ont un coût d’autant plus élevé qu’elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés.

Le cycle de vie du giclée comprend généralement les activités suivantes : ? Définition des objectifs, consistant à définir la finalité du projet et son inscription dans une stratégie globale. ? Analyse des besoins et faisabilité, c’est-à-dire l’expression, e recueil et la formalisation des besoins du demandeur (le client) et de l’ensemble des contraintes. ? Conception générale. Il s’agit de l’élaboration des spécifications de l’architecture générale du logiciel. ? Conception détaillée, consistant à définir précisément chaque sous-ensemble du giclée. ? Codage (implantation ou programmation), soit la traduction dans un langage de programmation des fonctionnaires définies lors de phases de conception. ? Tests unitaires, permettant de vérifie des fonctionnaires définies lors de phases de conception. Tests unitaires, permettant de vérifier individuellement que chaque sous-ensemble du logiciel est implicitement conformément aux spécifications. ? Intégration, dont l’objectif est de s’assurer de l’interface des différents éléments (modules) du logiciel. Elle fait l’objet de tests d’intégration consignés dans un document. ? Qualification (ou recette), c’est-à-dire la vérification de la conformité du logiciel aux spécifications initiales. ? Documentation, visant à produire les informations nécessaires pour l’utilisation du giclée et pour des développements ultérieurs. Mise en production, ? Maintenance, comprenant toutes les actions correctives (maintenance corrective) et évolutives (maintenance évolutive) sur le logiciel.

La séquence et la présence de chacune de ces activités dans le cycle de vie dépend du choix d’un modèle de cycle de vie entre le client et l’équipe de développement. 3- Modèles de cycles de vie Afin d’être en mesure d’avoir une méthodologie commune entre le client et la société de service réalisant le développement, des modèles de cycle de vie ont été mis au point définissant les étapes du développement ainsi que es documents à produire permettant de valider chacune des étapes avant de passer à la suivante. Modèle en cascade Le modèle de cycle de vie en cascade a été mis au point dès 1966, puis formalisé aux alentours de 1970.

AI définit des phases séquentielles à l’issue de chacune desquelles des documents sont produits pour en vérifier la conformité avant de passer à la suivante : vérifier la conformité avant de passer à la suivante : Modèle en V Le modèle de cycle de vie en V part du principe que es procédures de vérification de la conformité du logiciel aux opacification doivent être élaborées dès les phases de conception. AI est important de noter qu’une étape, telle que la conception, peut faire intervenir plusieurs activités, comme celles de la spécification globale, du maquette et de la validation. Inversement une activité comme la documentation peut se dérouler pendant plusieurs étapes. La continuité du cycle e de vie du logiciel implique qu’il faut respecter l’enchaînement des différentes phases.

Le processus de développement consiste à décomposer le problème en veillant à : ? à chaque niveau de décomposition, bien décrire le rebelle et sa décomposition en sous-problèmes ; ? bien préciser le procédé de recomposition (ou intégration) : l’assemblage des solutions des sous problèmes ne donne pas automatiquement la solution du problème ; concevoir (et utiliser) des solutions réutilisables Les différentes phases du processus logiciel Le tableau ci-dessous montrent la répartition des activités selon les phases ainsi que les documents en entrées et en sortie de chaque phase. Ces correspondances restent largement valables pour les (ou des partie des) modèles plus complexes .