ENIS

Vous souhaitez réagir à ce message ? Créez un compte en quelques clics ou connectez-vous pour continuer.

Forum de formation dans divers domaines informatique

Le Deal du moment :
TCL C74 Series 55C743 – TV 55” 4K QLED 144 ...
Voir le deal
499 €

    La conception de logiciel

    Admin
    Admin
    Admin


    Messages : 87
    Date d'inscription : 01/02/2010
    Age : 36
    Localisation : Souissi Haythem

    La conception de logiciel Empty La conception de logiciel

    Message  Admin Mar 4 Mai - 0:23

    La conception de logiciel

    Resume
    Dans cet article, le lecteur pourra avoir une meilleur compréhension des phases préparatoires et executives d'un logiciel, ainsi que la partie de recettage.
    Sommaire
    •Introduction

    •1 La vie d’un logiciel
    o 1.1 L’expression du besoin
    o 1.2 L’appel d’offre
    o 1.3 L’élaboration du logiciel
    o 1.4 La création du logiciel
    o 1.5 La Phase de Tests
    o 1.6 La maintenance

    •2 Préparation du projet
    o 2.1 Représentation du fonctionnement
    o 2.2 Représentation des classes
    o 2.3 Diagramme de paquetage
    o 2.4 Diagramme de séquence
    o 2.5 Diagramme de Gantt
    o 2.6 La base de données

    •3 Les cycles de développement
    o 3.1 Le cycle en Cascade
    o 3.2 Le cycle en V
    o 3.3 Le cycle en Spirale ou Modèle par Incrément
    o 3.4 L’extreme Programming (XP)

    •4 Le Cycle en V
    o 4.1 Les tests Unitaires
    o 4.2 Les tests d’intégration

    •5 La phase de tests
    o 5.1 Les tests systèmes
    o 5.2 Les tests d’intégration systèmes
    o 5.3 Les tests de performances
    o 5.4 Les tests de régressions

    •6 La documentation

    •7 La Formation aux utilisateurs

    •8 La phase de recette

    •Conclusion


    Introduction
    Durant notre scolarité, nous étudions surtout la partie élaboration d’un logiciel aussi bien le cahier des charges que le découpage, l’organisation et le développement du projet. Nous voyons rarement la partie finale du projet qui consiste à faire des tests unitaires et fonctionnels.
    En effet, l’étape qui consiste à tester le logiciel est une partie déterminante de la vie du logiciel. Nous verrons dans un premier temps toutes les étapes de la vie d’un logiciel, puis nous verrons les différents types de tests que l’on peut réaliser sur un logiciel, enfin nous verrons quels moyens nous pouvons mettre en œuvre pour faciliter la systématisation des tests.

    1 La vie d’un logiciel

    1.1 L’expression du besoin
    Il est de plus en plus rare qu’un logiciel soit créé de façon spontanée. Un logiciel est souvent une réponse à un besoin exprimé par une entreprise ou un certain nombre de clients. Lorsque le logiciel est censé apporter une réponse à une demande faite par un client, il faut d’abord pouvoir cibler précisément les attentes du demandeur. C’est pour cela que l’on commence par créer un cahier des charges, qui regroupera alors toutes les spécificités techniques et fonctionnelles que l’on attend de la future application.
    La demande de création de logiciel étant rarement destinée à servir les besoins d’ un seul utilisateur, il faut donc faire un tour de tables des collaborateurs pour voir quelles sont leurs attentes et déterminer si l’application pourra y répondre ou non.

    1.2 L’appel d’offre
    A partir du moment où le client a réussi à définir son besoin dans un cahier des charges, il fait un appel d’offre afin que plusieurs sociétés répondent et apportent des solutions à son besoin. Chaque société doit alors faire valoir les compétences de ses équipes et montrer quelle est la meilleure solution pour répondre aux besoins qui ont été exprimés par le client. Après l’appel d’offre, le client doit choisir la société exécutrice, se mettre d’ accord sur les modifications à apporter, éventuellement préciser encore certains points.

    1.3 L’élaboration du logiciel
    La société qui remporte l’appel d’offre (bien souvent une SSII) doit alors faire une maquette du logiciel afin de montrer au client que le projet a bien été compris dans son ensemble. Cela permettra à la fois au client et aux prestataires de se retrouver dans l’évolution du projet. C’est dans cette phase qu’il faudra définir le langage de programmation du logiciel, il faudra également définir la méthode de vérification du programme (cf. les cycles d’un programme) afin de savoir à quel moment les tests devront être défini et effectué.

    1.4 La création du logiciel
    Lorsque le client et le prestataire se sont entendus sur la problématique du projet et sur tous les points à traiter, il faut alors commencer à concevoir le projet. C’est la partie implémentation.

    1.5 La Phase de Tests
    Une fois le logiciel terminé il faut alors tester son bon fonctionnement, vérifier qu’il remplit bien les conditions posées par le client. C’est durant cette phase que le client peut être amené à demander un certain nombre de modifications car il prend conscience de la puissance du logiciel ou alors que ce qu’il a demandé n’est pas réalisable. C’est également durant cette phase que le client va accepter ou non le produit ainsi que prendre la décision de payer tout ou partie à la société.

    1.6 La maintenance
    Enfin, après acceptation du logiciel par la société cliente, le logiciel doit être maintenu pour suivre l’évolution de la société et de son environnement. Par exemple, si le système d’exploitation doit être patché, il faut s’assurer que le logiciel continuera à bien fonctionner après la mise à jour.
    Maintenant que nous avons vu plus en détail chaque phase de la conception d’un logiciel, nous allons pouvoir étudier la préparation d’un projet avant sa conception.

    2 Préparation du projet
    Cette phase est très importante pour la bonne compréhension du demandeur et du prestataire. Pendant cette étape, l’exécuteur s’efforcera de découper au maximum le projet afin de permettre au client de pouvoir se situer à n’importe quelle phase de l’avancement du projet.

    2.1 Représentation du fonctionnement
    Les prestataires commenceront par faire un diagramme de Cas, ce qui permettra d’envisager un maximum de cas d’utilisation de l’application, mais c’est également la représentation la plus compréhensible par le client qui ne connaît rien en code.

    2.2 Représentation des classes
    Après réalisation du diagramme de cas, il est intéressant de faire un diagramme des classes afin que toutes les équipes de développement puissent connaître leur environnement de travail. En effet si tout le projet est bien déterminé à l’avance avec les noms des variables et des classes, même si un module n’est pas encore développé, l’implémentation de la communication avec celui-ci ne posera pas de problème puisqu’il aura été prototypé par avance.

    2.3 Diagramme de paquetage
    Afin de pouvoir montrer un schéma moins complexe au client, il faut réaliser un diagramme de paquetage. Ainsi le découpage des tâches sera plus compréhebsible. Ce découpage permet de mettre plus de monde sur un projet et ainsi de le faire avancer plus rapidement. En effet, si le programme devait être réalisé de façon linéaire, il serait alors plus long et fastidieux à développer, mais également très difficile à corriger et maintenir.

    2.4 Diagramme de séquence
    Le Diagramme de séquence permettra de voir dans quel ordre les modules doivent être utilisés.
    De cette façon, on peut alors réaliser en priorité les premiers modules afin de pouvoir tester plus rapidement l’application. En effet, si on commence par les modules les plus conséquents et qu’ils n’interviennent qu’en fin d’application, il faudra alors attendre la fin du logiciel pour commencer à faire les premiers tests d’intégration. Une seconde méthode consiste à implémenter en premier lieu le cœur de l’application puis tous les modules qui viennent s’y greffer.
    Si la mission de développement est un « grand projet » il est alors intéressant de mettre une équipe sur chaque couche de l’application.

    2.5 Diagramme de Gantt
    Le diagramme de Gantt est une étape importante dans la vie d’un projet. C’est ce diagramme qui va déterminer si les délais demandés à l’origine pourront être tenus ou non.
    C’est également grâce à ce diagramme que l’on pourra gérer le nombre de personnes par équipe afin de pouvoir rentrer au maximum dans les délais exigés par le client.

    2.6 La base de données
    Si le logiciel doit contenir une base de données non existante, il faudra également faire un schéma de la base afin de définir sa structure. Il faudra donc déterminer le nom et le contenu des tables, ainsi que les différentes clés primaires. Tous les utilisateurs du logiciel n’ayant pas le même pouvoir, il faudra également définir les différents groupes d’utilisateurs ainsi que leur droit. Enfin, il faudra déterminer les différentes vues à créer.
    Il ressemble au diagramme de classe de l’UML.

    3 Les cycles de développement

    3.1 Le cycle en Cascade
    Le cycle en cascade est le cycle le plus basique qui puisse exister. On passe d’une étape à l’autre uniquement lorsque la phase précédente est achevée.


    3.2 Le cycle en V
    Il existe un cycle de vérification qui s’appelle cycle en V ou cycle V&V (vérification et Validation)


    3.3 Le cycle en Spirale ou Modèle par Incrément

    Ce modèle est le plus lourd mais pourtant le plus efficace. Un besoin est exprimé, on étudie alors la faisabilité du besoin, puis on essaye alors de répondre à ce besoin en proposant des solutions puis en réalisant la solution qui est choisie par le client. Des tests sont alors réalisés, si de nouveaux besoins s’expriment alors on recommence la procédure.

    3.4 L’extreme Programming (XP)
    Cette méthode est très récente (octobre 2000) C’est une méthode agile qui permet de s’adapter facilement aux modifications demandées par le client.
    Des le début de la conception, les tests de recettes sont déjà pris en compte. Il s’agit plus ou moins d’une version revue et corrigée du modèle Itératif, mais qui demande moins de contrainte et moins de courrier. Ici si quelque chose ne va pas, le problème est signalé aux développeurs qui vont rectifier le tir. Dans le modèle en spirale, il fallait refaire une évaluation du besoin.

    4 Le Cycle en V
    Comme il a été vu plus haut, le Cycle en V consiste à vérifier pour chaque phase des spécifications que l’application correspond bien à la demande.
    Ainsi les spécifications seront testées par des tests de validation, les spécifications de l’architecture seront testées par des tests d’intégration, enfin, les spécifications détaillées seront contrôlées par des tests unitaires.

    4.1 Les tests Unitaires
    4.1.1 Définition
    Voici la définition donnée par WIKIPEDIA : « Il s'agit pour le programmeur de tester un seul module logiciel, indépendamment du reste du programme, afin de s'assurer qu'il répond aux spécifications fonctionnelles et qu'il fonctionne correctement en toutes circonstances » .
    C’est donc une phase importante des tests qui a lieu à la fin de la réalisation de chaque module. En effet, si un module n’a pas le comportement qu’on attend de lui, il est inutile de l’intégrer au reste des modules de la couche.
    Les tests unitaires ne sont pas limités à chaque module d’une couche, ils seront également faits au niveau de chaque couche. Cette phase de tests est très importante pour l’application car en cas d’erreur à un niveau supérieur, le test unitaire permet de valider le bon fonctionnement de l’application. Cela permet ainsi de mettre en évidence une erreur au niveau de l’intégration.
    4.1.2 Méthode de réalisation
    Pour réaliser ce genre de tests, le plus souvent le programmeur va écrire une fonction qui va rentrer des données aux différentes fonctions des modules et contrôler le bon résultat à la sortie. En cas de détection d’erreur (dépassement de mémoire par exemple), il faudra écrire une fonction qui permettra de reproduire l’erreur. Après chaque modification, il faudra repasser cette fonction pour vérifier que l’erreur ne se reproduit plus.

    4.2 Les tests d’intégration
    4.2.1 Définition
    Les tests d’intégration interviennent après les tests unitaires. Le test d’intégration va permettre de tester la bonne communication entre les différentes couches de l’application. Le lecteur pourra alors remarque ici l’importance du test unitaire qui aura été réalisé précédemment. En effet, si seuls des tests d’intégration étaient réalisés, en cas d’erreur dans le résultat attendu, le développeur ne serait pas à même de savoir si le problème vient d’un des modules ou bien de la communication entre les différentes couches.

    Et dans ce cas, il faudrait tester module par module et voir les corrections à apporter aux différentes couches et continuer les tests sans savoir si la modification effectuée va provoquer ou non des effets de bord. Ainsi, Les tests unitaires sont une première étape de validation du bon comportement de l’application.
    4.2.2 Méthode de réalisation
    Pour tester le bon fonctionnement entre deux modules, soit une personne qui ne développe pas teste le logiciel en suivant un scénario élaboré pour vérifier la communication entre les modules à tester. Une autre solution consiste à demander un développeur de concevoir un script permettant de tester la communication entre les différents modules.

    La seconde solution est la plus rapide, mais lorsque la communication entre plusieurs modules passe par une interface graphique, il est difficile de passer par l’utilisation d’un batch.

    5 La phase de tests
    La phase de tests est une des phases les plus importantes après le développement. Cette partie permettra aux développeurs de trouver les différentes erreurs qui auraient pu se glisser lors de la phase d’implémentation.
    Les utilisateurs quant à eux vont pouvoir vérifier que le logiciel a le comportement désiré, même en cas d’insertion de données erronées.

    5.1 Les tests systèmes
    Les tests systèmes consistent à tester l’application avec différents systèmes d’exploitation afin de savoir s’ils sont compatibles ou non avec tel ou tel OS.
    Pour vérifier qu’une application fonctionne sur différents systèmes d’exploitation, il faut dérouler les mêmes scénarios de tests sur plusieurs systèmes d’exploitation différents. Afin de ne pas fausser les tests, il faut effectuer les tests systèmes sur des machines possédant la même configuration matérielle et logicielle.
    La même configuration matérielle permet ainsi d’être sûr qu’un dysfonctionnement n’est pas du à une incompatibilité matérielle. Mais en ce qui concerne les jeux en 3 dimensions, la carte graphique peut alors provoquer une erreur dans l’application car l’affichage ne correspond pas à ce qui a été implémenté. Il peut être également intéressant de pouvoir avoir une configuration minimale et une configuration recommandée.

    5.2 Les tests d’intégration systèmes
    Dans le paragraphe précédent, il a été signalé qu’il fallait faire le test sur des machines similaires tant au niveau matériel que logiciel. En effet, certains logiciels peuvent créer des dysfonctionnements dus à des conflits qui peuvent être assez variés.
    Exemples :
    EasyPHP et Skype : Le port utilisé par Skype pour fonctionner est le même port que celui utilisé par le module d’interprétation du PHP de Easy PHP.
    Un certain logiciel pour les kiné et Norton antivirus.
    Le premier logiciel s’installe parfaitement sans que l’antivirus ne dise quoi que ce soit, mais une fois que l’on lance le logiciel et que l’on veut accéder aux dossiers des patients un message apparaît signalant une erreur .
    Lorsque le logiciel est créé dans une SSII, il est alors très important de vérifier que les clients pourront utiliser l’application dans de bonnes conditions et sans avoir à se passer d’un des logiciels qu’ils utilisent.
    Lorsqu’il s’agit d’une société qui crée ses propres logiciels, les tests d’intégration sont utilisés pour fidéliser la clientèle. En effet, si la société met en vente un logiciel qui connaît des incompatibilités avec d’autres logiciels très utilisés, il vaut mieux que l’incompatibilité soit signalée car les clients qui achèteraient le logiciel sans que le problème soit connu, hésiteront plus à acheter d’autres logiciels appartenant à cette société.

    5.3 Les tests de performances
    Le test de performance consiste à éprouver la rapidité d’une application. C’est entre autres par le biais de ce test que l’on peut déterminer la configuration minimale et la configuration recommandée pour les logiciels à utiliser.
    Ce test permet également de déterminer s’il faut simplifier ou non les algorithmes. En effet, une trop grosse complexité d’une boucle ou d’une fonction peut considérablement ralentir un programme.
    Il faut savoir que les ordinateurs utilisés par les développeurs sont en général beaucoup plus performants que ceux qui sont utilisés par les utilisateurs de logiciels. Donc si les tests effectués sur un ordinateur de développement paraissent satisfaisants, il faut tout de même vérifier la rapidité d’exécution sur un ordinateur dédié aux utilisateurs.
    Ainsi si les tests de performance sont jugé insuffisants sur une machine de développement, il faudrait obligatoirement revoir le code de l’application pour obtenir plus de performances.

    5.4 Les tests de régressions
    Lors de correctifs pour les logiciels en développement, il faut toujours vérifier que la version corrigée ne comporte pas de régression.
    Une régression peut arriver lorsque l’on fait un correctif de l’application. Par exemple la version précédente avait un bug corrigé d’une version antérieure (V-1), et la nouvelle version livrée (V+1) présente le bug qui était pourtant corrigé dans la version précédente (V).
    Pour vérifier la non régression, il faut avoir une batterie de scénario de tests et les dérouler à chaque livraison de version pour être sûr que tout fonctionne.
    Les résultats du déroulement de ces scénarios doivent être reportés dans une feuille Excel ou équivalent afin de repérer les régressions d’une version à l’autre.

    6 La documentation
    Afin d’avoir un logiciel qui soit facile d’utilisation pour le client, il faut créer une documentation qui permettra à l’acheteur de pouvoir manipuler son produit sans pour autant le connaître.
    Pour aider l’utilisateur dans ses découvertes du logiciel, le document commence par le guide d’installation de l’application. Ce petit guide est souvent agrémenté de captures d’écran qui permettront à l’utilisateur d’avancer pas à pas dans l’installation grâce à un repère visuel.
    Ensuite, afin d’aider l’utilisateur dans sa prise en main du logiciel, il faut alors expliquer les principales manœuvres réalisables après installation de l’ordinateur. On parlera alors des options de navigation.
    À présent que l’utilisateur navigue dans l’application, on peut alors expliquer écran par écran le fonctionnement du logiciel. Après les options de navigation, la description varie en fonction des créateurs des logiciels. Certains expliqueront comment implémenter soi-même des options.
    Il peut être utile pour l’utilisateur d’avoir par exemple un livre d’apprentissage par exercice. Bien que cela dépende de la volonté du client, il n’est pas rare de voir des utilisateurs acheter des livres permettant d’apprendre l’utilisation d’un logiciel par des exercices.
    Lorsqu’un logiciel est complexe, Il est recommandé de faire une documentation par type d’utilisateur, ce qui rendra la lecture moins complexe pour la personne qui découvre l’application et qui ne sait pas encore ce qu’elle a le droit de faire ou non dessus.

    7 La Formation aux utilisateurs
    Lorsqu’un logiciel est réalisé par une SSII, cela sous-entend qu’un client a fait la demande de création du logiciel, donc pour éviter de sortir autant de notices qu’il y a d’utilisateurs, une formation est alors dispensée.
    De cette façon si un logiciel est assez complexe et qu’il peut être utilisé par plusieurs domaines de compétences comme pour un ERP par exemple ou bien un logiciel d’assistance Helpdesk. Dans ce dernier exemple, la documentation du logiciel devra contenir toutes les facettes de l’utilisation du logiciel alors que la personne qui est chargée de prendre les messages ne verra qu’une partie spécifique de l’interface.
    La formation permettra alors un gain de temps puisque chaque personne sera alors formée pour la partie spécifique de son utilisation de l’application.
    Il peut tout de même être intéressant de créer une documentation complémentaire à la formation, voir qui reprend les principaux éléments de la formation.

    8 La phase de recette
    Lorsque le logiciel est créé par une société prestataire de service, une fois le logiciel achevé, on entre dans une phase de recette.
    Les clients et la SSII doivent alors vérifier que le logiciel est conforme au cahier des charges.
    Pour cela, les clients vont devoir concevoir un certain nombre de scénarios afin de vérifier le bon comportement du logiciel. Les tests devront effectuer des actions que les utilisateurs feront de façon quotidienne, mais également des tâches qui seront moins courantes.
    Par exemple : Le logiciel est un ERP, les utilisateurs rempliront fréquemment leur carnet d’adresses et leurs calendriers. Mais l’administrateur ne supprimera pas souvent un utilisateur, mais il faut tout de même tester cette action.
    Il faudra également vérifier le bon comportement du logiciel face à une erreur. En effet, lorsque l’on implémente une calculatrice, il faut tester la division par 0. Est ce qu’elle montre effectivement que ce n’est pas possible, ou alors est ce que le programme va s’arrêter par une erreur.
    Toujours dans le même, contexte, l’erreur ne doit pas être bloquante, il faut permettre à l’utilisateur de modifier son erreur.
    Exemple : dans un logiciel de compte, si l’utilisateur s’est trompé sur la somme à rentrer, il faut lui permettre de modifier la somme plutôt que de le forcer à rajouter une opération pour corriger l’erreur.
    Il faut donc créer des tests permettant de vérifier la rectification des erreurs, tout en respectant le cahier des charges.

    Conclusion
    De façon générale, pour réaliser un logiciel le plus facilement possible, il faut bien préparer les étapes avant la réalisation du logiciel. Lors de la conception du logiciel, il faut déjà préparer les étapes en aval (tests, documentation, formation).

    Le lecteur pourra constater que l’article ici traite en particulier la conception d’un logiciel, mais que de façon générale tout projet peut être réalisé de la même façon, qu’il s’agisse d’une installation réseau, la mise en place d’une nouvelle équipe dans une société, etc…

      La date/heure actuelle est Ven 29 Mar - 3:08