Capability Maturity Model Integration Un article de Wikipédia, l'encyclopédie libre. CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités des entreprises d'ingénierie. CMMI a été développé par le Software Engineering Institute de l'université Carnegie-Mellon, initialement pour appréhender et mesurer la qualité des services rendus par les fournisseurs de logiciels informatiques du département de la Défense des États-Unis(DoD). Il est maintenant largement employé par les entreprises d'ingénierie informatique, les directeurs des systèmes informatiques et les industriels pour évaluer et améliorer leurs propres développements de produits[1]. Le modèle CMMI[modifier | modifier le code] CMMI est un cadre générique de processus qui se décline en trois modèles (appelés constellations) : Maturité[modifier | modifier le code] Historique[modifier | modifier le code] « Initial » (niveau de maturité 1)
La techhnologie : un obstacle dans l'entreprise ? Pour cet article de rentrée, je voulais depuis déjà quelques temps aborder la question fondamentale de la place de la technologie dans les entreprises françaises. Au sein de The Persuaders, notre philosophie est de voir la technologie comme transformatrice dans les entreprises et donc acteur de changement dans la culture, les organisations et les processus. Comme l'écrivait Fred Cavazza dans Toutes les disciplines du web forment un grand ensemble, tous les pans de l'activité Internet sont liés et se sont complexifiés. Nous sommes passés des années 2000 où Internet était vu seulement comme le 6ème média et un canal de distribution additionnel à une ère de la digitalisation des activités où Internet prend plus de place, au travers de nouveaux usages, de nouveaux outils et de nouveaux terminaux (tablettes numériques, télévision connectée...) 1/ Le fossé générationnel dans l'usage des nouvelles technologies Le web est ainsi devenu "Personal Media" (Du Social Media au Personal Media).
Web Services Décembre 2017 Avec l'interconnexion des ordinateurs en réseau et en particulier à travers internet, il devient possible de faire fonctionner des applications sur des machines distantes. L'intérêt d'une application fonctionnant à distance peut à première vue sembler inutile dans la mesure où les applications fonctionnent fort bien en local (sur le poste de l'utilisateur), néanmoins une application distante peut répondre aux problématiques suivantes : Les données peuvent être présentes uniquement sur le serveur distant (par exemple un catalogue produit, un classement en temps réel, etc.) ; Le serveur distant peut disposer d'une puissance de calcul ou de capacités de stockage dont l'utilisateur local ne dispose pas ; L'application distante peut être utilisée simultanément par un grand nombre d'utilisateurs et sa mise à journ'intervient qu'à un seul endroit. Pour toutes ses raisons, une interaction entre des programmes distants peut être utile. Web Service Couches Standards Invocation Découverte
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. 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. Amplify learning[edit] Software development is a continuous learning process with the additional challenge of development teams and end product sizes. Decide as late as possible[edit]
Entreprise 2.0 : valeur ajoutée et processus métiers Comme promis la semaine dernière voici la suite du billet issu du keynote de Rawn Shah pour l’entreprise 2.0 summit de Paris de février. Après avoir vu la valeur ajoutée du collaboratif pour l’entreprise, il s’agit de voir maintenant comment aligner le collaboratif avec les différents processus métiers. Rawn Shah a pris 3 exemples pour illustrer sa démonstration : les produits et la R&D, le service client, les fonctions support Commençons par les objectifs du service produit et innovation. Innovation produit, nouvelle approche marché et évolution du modèle d’innovation Innovation par l’intelligence collective Innovation à travers les partenariats Mise en place de réseau d’experts et de communautés Pour illustrer cela prenons le cas des partenariats, challenge sur laquelle les européens et plus encore les français sont frileux. La captation des informations non-structurées comme les conversations vont permettre de faire surgir de nouvelles idées Améliorer la relation client
Representational State Transfer Un article de Wikipédia, l'encyclopédie libre. REST (representational state transfer) est un style d’architecture pour les systèmes hypermédia distribués, créé par Roy Fielding en 2000 dans le chapitre 5 de sa thèse de doctorat[1]. REST n’est pas un protocole (tel que HTTP) ou un format. Ce style d'architecture est particulièrement bien adapté au World Wide Web mais n'en est pas dépendant. Contraintes d'une architecture REST[modifier | modifier le code] Les contraintes sont les suivantes : Client-serveur : les responsabilités sont séparées entre le client et le serveur. Description de REST[modifier | modifier le code] Confusion entre REST et protocoles[modifier | modifier le code] Ce style architectural s'applique tout autant à la réalisation d’applications pour un utilisateur humain qu'à la réalisation d’architectures orientées services destinées à la communication entre machines. RPC ainsi que SOAP ne sont pas des styles d'architecture mais des protocoles. ↑ (fr) Thèse de Roy T.
Agile software development Agile software development is a set of principles for software development in which requirements and solutions evolve through collaboration between self-organizing,[1] cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change.[2] Agile itself has never defined any specific methods to achieve this, but many have grown up as a result and have been recognized as being 'Agile'. The Manifesto for Agile Software Development,[3] also known as the Agile Manifesto, was first proclaimed in 2001, after "agile methodology" was originally introduced in the late 1980s and early 1990s. The manifesto came out of the DSDM Consortium in 1994, although its roots go back to the mid 1980s at DuPont and texts by James Martin[4] and James Kerr et al.[5] History[edit] Incremental software development methods trace back to 1957.[6] In 1974, E. The Agile Manifesto[edit] Agile principles[edit]
Pourquoi votre centre d'appel devrait gérer vos médias sociaux Pendant que les entreprises réfléchissent sérieusement aux moyens de maximiser les avantages des médias sociaux, on doit aborder la question : Qui, dans l’entreprise doit être responsable des médias sociaux? Qui doit prendre les décisions concernant les technologies, les effectifs, ou encore les politiques concernant les médias sociaux et les interactions dans les médias sociaux? Qui dirige le spectacle? Le centre d’appel, selon plusieurs, serait la terre d’accueil idéale pour la gestion des médias sociaux dans une entreprise. Alors que les organisations gèrent actuellement les médias sociaux à partir des départements des ventes, du marketing ou des services de gestion de marque, le centre d’appel dispose de l’expérience, de la technologie et des métriques pour gérer avec succès et même tirer profit des médias sociaux. La question de savoir si une interaction sociale avec les médias doit remplacer un appel téléphonique n’est pas la question.
Introduction aux Web Services Un article de ODcWiki. On parle beaucoup des Web Services et de toute la galaxie de standards et de technologies qui gravitent autour. On oublie souvent au passage quelques questions essentielles : Pourquoi adopter les Web Services dans une application ? Pourquoi adopter les Web Services ? Au-delà de l’effet de mode, les Web Services apportent une réelle solution technique à un problème récurrent de l’informatique : faciliter l’interconnexion des applications. Au fil du temps, 4 cas d’utilisation distincts et plus ou moins ambitieux sont apparus : Interconnecter des plates-formes hétérogènes ; Intégrer des applications existantes ; Client / serveur sur Internet ; Fournir des services à forte valeur ajoutée métier. Interconnecter des plates-formes incompatibles Initialement, les Web Services ont été utilisés pour interconnecter simplement des plates-formes qui auparavant communiquaient mal. L’interopérabilité s’appuie ici sur l’utilisation des standards techniques définis par le W3C :
Unified Process The Unified Software Development Process or Unified Process is a popular iterative and incremental software development process framework. The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP). Other examples are OpenUP and Agile Unified Process. Profile of a typical project showing the relative sizes of the four phases of the Unified Process. Overview[edit] The Unified Process is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects. The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. In 2012 the Disciplined Agile Delivery framework was released, a hybrid framework that adopts and extends strategies from Unified Process, Scrum, XP, and other methods. Unified Process Characteristics[edit] Iterative and Incremental[edit] Risk Focused[edit]
ITGI Web services et bibliothèques Les Web services sont des technologies basées sur les standards du Web qui permettent à des applications de dialoguer entre elles. Il fournissent un cadre pour trouver, décrire et exécuter ces applications. Les caractéristiques des Web services. Web based : les Web services sont basés sur les protocoles et les langages du Web, en particulier HTTP et XML (tout comme le Web lui-même s’appuie sur les protocoles d’Internet en particulier TCP/IP : c’est une « couche » supplémentaire). Self-described, self-contained : le cadre des Web services contient en lui-même toutes les informations nécessaires à l’utilisation des applications, sous la forme de trois fonctions : trouver, décrire et exécuter. Modular : les Web services fonctionnent de manière modulaire et non pas intégrée. Les perspectives La longévité et la fiabilité d’un système qui vise à fonctionner de manière distribuée se mesurent à l’ampleur de l’implémentation qui est faite du système par l’industrie. Exemple d’application
Model driven architecture Un article de Wikipédia, l'encyclopédie libre. L’architecture dirigée par les modèles ou MDA (pour l'anglais Model Driven Architecture) est une démarche de réalisation de logiciels, proposée et soutenue par l'OMG. C'est une variante particulière de l'ingénierie dirigée par les modèles (IDM, ou MDE pour l'anglais Model Driven Engineering). D'autres variantes de l'IDM ont été développées, par exemple par Microsoft (DSL Tools). Introduction[modifier | modifier le code] L'OMG fournit des spécifications des standards plutôt que des implémentations, le plus souvent après avoir reçu une demande de proposition (Request for Proposals). Les standards liés au MDA[modifier | modifier le code] L'approche MDA est liée à de nombreux standards tels que : CWM (Common Warehouse Metamodel)EDOC (Enterprise Distributed Object Computing)MOF (Meta-Object Facility)MOFM2T (MOF Model-to-Text language)QVTSPEM (Software Process Engineering Metamodel)UML (Unified Modeling Language)XMI (XML Metadata Interchange)etc.