Au sommaire :
La plupart (pour le pas dire toutes) des processus de conception et de réalisation définies en génie-logiciel se basent sur l'une des deux approches :
Cette approche fait l'objet de cet article. En effet, les différents processus en génie-logiciel proposent des solutions pour les différents problèmes rencontrés au niveau des entreprises.
Les premiers processus itératifs proposées visaient à répondre à la problématique du changement des besoins fonctionnels du système à construire. L'environnement dynamique de l'entreprise ainsi que les changements nécessaires à sa survie rendent les besoins fonctionnels temporaire (en quelque sorte) : changements des procédures, adaptation à des nouvelles lois, apparition des besoins d'interopérabilité, ainsi que des dizaines de possibilités qui poussent les concepteurs à revoir leur conception et par la suite la partie à modifier du logiciel.
Les processus en prototypage visent à régler un autre type de problème : réduire au maximum le temps de livraison. Un système qui garantit plusieurs fonctionnalités peut être lourd à implémenter, ainsi, pourquoi en pas livrer une partie du système à la fois, par conséquent, les équipes de conception et de réalisation peuvent se concentrer sur cette partie ("petite" par rapport à la taille du système finale). Le processus est répété selon le nombre des fonctionnalités à implémenter et chaque itération donne naissance à une nouvelle partie du système et qui sera directement intégrée à l'application qui est déjà en cours d'utilisation.
Le processus en Y, partiellement itératif (ou semi-itératif) vise à régler un autre type de problème : la prise en compte de la dimension technique. Les premiers processus en génie-logiciel passaient par les quatre niveaux d'abstraction (vues extérieures, niveau conceptuel, niveau logique et niveau physique) du niveau le plus abstrait vers le niveau physique, ainsi, les choix techniques étaient généralement pris après la fin de la conception (ce qui permettait, d'ailleurs, de choisir les meilleures technologies pour la conception effectuée). Cette approche est encore possible lorsqu'il s'agit d'une première automatisation du système d'information, mais, elle devient lourde si le système (ou l'application) à construire doit respecter un ensemble de choix techniques déjà pris par les premiers systèmes développés dans l'organisation. Ainsi, pour une prise en compte explicite de ces besoins dits techniques nous devons faire recours au processus de développement en Y.
La question que nous devons poser à la fin de cette première partie est la suivante :
Qu'elle est le meilleure processus (ou approche) à utiliser pour développer une application dans le cadre d'un sujet de recherche ?
(Pour plus d'informations sur l'auteur et le blog, c'est par ici)
- Introduction ; les différentes approches
- Entre les approches pour entreprise et les projets de recherche
- L'approche la plus adéquate pour les projets de recherche
- Un peu plus loin : un peu de biologie
- Exemple et conclusion
La plupart (pour le pas dire toutes) des processus de conception et de réalisation définies en génie-logiciel se basent sur l'une des deux approches :
1. L'approche ascendante (ou l'approche bottom-up) :
En optant pour cette approche, vous procédez à construire votre système en partant de plusieurs parties plus petite. Cette approche peut être retrouvée, à titre exemple, dans :- La conception d'une base des données en se basant sur les dépendances fonctionnelles : dans ce cas, une dépendance fonctionnelle est vue comme une partie, le schéma global de la base des données est constuit en combinant, nettoyant et regroupant les différentes dépendances fonctionnelles. Le processus principal est l'algorithme de la couverture minimale (qui utilise, à son tour, l'algorithme de la fermeture transitive).
- La programmation orientée composants : dans ce cas, un composant est vu comme une partie du système, l'application finale est le résultat d'une combinaison (couplage) entre les différents composants. Les composants sont, généralement, disponible dans un entrepôt des composants et il est possible de choisir un parmi les différents processus proposés pour procéder à la sélection des composants adéquats aux besoins visés par l'application.
2. L'approche descendante (ou approche top-down) :
C'est la proche la plus utilsiée vu qu'il n'est pas possible (pour des raisons d'existance, d'incompatibilité, du coût ou pour autres raisons) d'obtenir les composants de base pour construire un système. Cette approche part de l'ensemble des besoins (fonctionnels et techniques) et tente de découper le système à des sous-systèmes qui seront à leur tour décupés à des sous-sous-sytème pour arriver, enfin, à un niveau où la réalisation est faisable. Cette approche était l'approche intuitive et logique au début de l'informatique et le premier processus proposé (le processus en cascade) n'est qu'une formalisation directe de cette approche. le processus en cascade commence par la définition des besoins, ensuite, chaque besoin est analysé pour donné lieu à une conception abstraite puis une conception détaillée (le nom dit tout !). Cette approche est très visible dans le cas des approches proposées aujourd'hui, surtout celles basées sur le langage UML (UP, XP, Y) : le diagramme des cas d'utilisation prémordial et utilisé par toutes ces approches n'est qu'un premier découpage du système à un ensemble de "processus ou modes d'utilisation".Cette approche fait l'objet de cet article. En effet, les différents processus en génie-logiciel proposent des solutions pour les différents problèmes rencontrés au niveau des entreprises.
Les premiers processus itératifs proposées visaient à répondre à la problématique du changement des besoins fonctionnels du système à construire. L'environnement dynamique de l'entreprise ainsi que les changements nécessaires à sa survie rendent les besoins fonctionnels temporaire (en quelque sorte) : changements des procédures, adaptation à des nouvelles lois, apparition des besoins d'interopérabilité, ainsi que des dizaines de possibilités qui poussent les concepteurs à revoir leur conception et par la suite la partie à modifier du logiciel.
Les processus en prototypage visent à régler un autre type de problème : réduire au maximum le temps de livraison. Un système qui garantit plusieurs fonctionnalités peut être lourd à implémenter, ainsi, pourquoi en pas livrer une partie du système à la fois, par conséquent, les équipes de conception et de réalisation peuvent se concentrer sur cette partie ("petite" par rapport à la taille du système finale). Le processus est répété selon le nombre des fonctionnalités à implémenter et chaque itération donne naissance à une nouvelle partie du système et qui sera directement intégrée à l'application qui est déjà en cours d'utilisation.
Le processus en Y, partiellement itératif (ou semi-itératif) vise à régler un autre type de problème : la prise en compte de la dimension technique. Les premiers processus en génie-logiciel passaient par les quatre niveaux d'abstraction (vues extérieures, niveau conceptuel, niveau logique et niveau physique) du niveau le plus abstrait vers le niveau physique, ainsi, les choix techniques étaient généralement pris après la fin de la conception (ce qui permettait, d'ailleurs, de choisir les meilleures technologies pour la conception effectuée). Cette approche est encore possible lorsqu'il s'agit d'une première automatisation du système d'information, mais, elle devient lourde si le système (ou l'application) à construire doit respecter un ensemble de choix techniques déjà pris par les premiers systèmes développés dans l'organisation. Ainsi, pour une prise en compte explicite de ces besoins dits techniques nous devons faire recours au processus de développement en Y.
La question que nous devons poser à la fin de cette première partie est la suivante :
Qu'elle est le meilleure processus (ou approche) à utiliser pour développer une application dans le cadre d'un sujet de recherche ?
(Pour plus d'informations sur l'auteur et le blog, c'est par ici)
Aucun commentaire:
Enregistrer un commentaire