Merise (informatique) Un article de Wikipédia, l'encyclopédie libre.
Cet article concerne une méthode en informatique. Pour le fruit, voir Merise. Merise (prononcer « Meurise » et non « Mérise ») est une méthode d'analyse, de conception et de gestion de projet informatique. Issue de l'analyse systémique, la méthode Merise est le résultat des travaux menés par Hubert Tardieu dans les années 1970 et qui s'inséraient dans le cadre d'une réflexion internationale, autour notamment du modèle relationnel d'Edgar Frank Codd.
Elle est devenue un projet opérationnel au début des années 1980 à la demande du ministère de l'industrie, et a surtout été utilisée en France, par les SSII de ses membres fondateurs (Sema-Metra, ainsi que par la CGI Informatique) et principalement pour les projets d'envergure, notamment des grandes administrations publiques ou privées. On pourra aussi consulter un historique de Merise sur le site Web Developpez.com. La méthode est essentiellement française. Sa mise en œuvre peut paraître lourde. Lean software development. Lean software development (LSD) is a translation of lean manufacturing and lean IT principles and practices to the software development domain.
Adapted from the Toyota Production System,[1] a pro-lean subculture is emerging from within the Agile community. Lean is most popular with startups that want to penetrate the market, or test their idea and see if it would make a viable business. [citation needed] Origin[edit] The term lean software development originated in a book by the same name, written by Mary Poppendieck and Tom Poppendieck.[2] The book presents the traditional lean principles in a modified form, as well as a set of 22 tools and compares the tools to agile practices. Lean principles[edit] Lean development can be summarized by seven principles, very close in concept to lean manufacturing principles: Eliminate waste[edit] In order to eliminate waste, one should be able to recognize it. A value stream mapping technique is used to identify waste. Cycle de développement (logiciel) Il existe différents types de cycles de développement entrant dans la réalisation d'un logiciel.
Ces cycles prennent en compte toutes les étapes de la conception d'un logiciel. Ce cycle de développement est aussi utilisé dans l'industrie aéronautique et spatiale pour définir des systèmes, ou des sous systèmes embarqués ou au sol qu'ils incluent ou pas de l'informatique. Évolution des cycles basiques Le modèle en cascade[1] est hérité de l'industrie du BTP. Ce modèle repose sur les hypothèses suivantes : on ne peut pas construire la toiture avant les fondations ;les conséquences d'une modification en amont du cycle ont un impact majeur sur les coûts en aval (on peut imaginer la fabrication d'un moule dans l'industrie du plastique). Les phases traditionnelles de développement sont effectuées simplement les unes après les autres, avec un retour sur les précédentes, voire au tout début du cycle. Intégration continue. L'intégration continue est un ensemble de pratiques utilisées en génie logiciel consistant à vérifier à chaque modification de code source que le résultat des modifications ne produit pas de régression dans l'application développée.
Le concept a pour la première fois été mentionné par Grady Booch[1] et se réfère généralement à la pratique de l'extreme programming. Le principal but de cette pratique est de détecter les problèmes d'intégration au plus tôt lors du développement. De plus, elle permet d'automatiser l'exécution des suites de tests et de voir l'évolution du développement du logiciel.
L'intégration continue est de plus en plus utilisée en entreprise afin d'améliorer la qualité du code et du produit final[2]. Intérêt[modifier | modifier le code] Pour appliquer cette technique, il faut d'abord que : Integration continue - Agile-Swiss. Un article de Agile-Swiss. Contexte Avant de commencer avec l'intégration continue, il faut comprendre l'architecture "idéale" de développement d'une application.
Elle se compose de cinq environnements : les postes des développeurs (dits "locaux"), avec les différents outils traditionnels (IDE, outils de modèlisation de base de données, éditeurs XML, ...) Cycle de développement (logiciel) Modèle en spirale.
Unified Process. Un article de Wikipédia, l'encyclopédie libre.
PU vient compléter la systémique des modèles UML. Elle est le résultat final d’une évolution de l’approche d’Ericsson qui est au fondement d’une des premières méthodes de développement pour applications orientées objets, la méthode Objectory Process (1987). Objectory Process (version 1 à 3.8 en 1995) a elle-même servi de base à la société Rational pour la création de Rational Objectory Process (1997) (version 4.1), parente direct de RUP en 1998.
Abréviations utilisées[modifier | modifier le code] RUP[modifier | modifier le code] Aspects RUP : les aspects dynamiques sont à l'horizontale, les statiques affichés verticalement. Le Rational Unified Process (RUP) est l’une des plus célèbres implémentations de la méthode PU, livrée clés en main, permettant de donner un cadre au développement logiciel, répondant aux exigences fondamentales préconisées par les créateurs d’UML :