On l’a vu précédemment, bien souvent, la MOA bâtit une expression du besoin sous la forme d’un cahier des charges et la MOE établit une expression du besoin en utilisant un cadre de pensée plus précis tel que les cas d’utilisation et la modélisation objet. Toutefois, dans les deux cas, on s’intéresse à la description du besoin du système d’un point de vue externe.  Le cahier des charges n’étant pas assez précis, complet et cohérent, il est devenu une habitude que la MOE le complète d’une spécification du besoin plus formelle.

En dehors de l’avantage de permettre à la MOE de prendre connaissance du besoin, les inconvénients de cette approche sont les suivants :

• On se retrouve avec plusieurs documents d’expression du besoin ! Lequel fait foi et reste à jour ?
• On effectue parfois deux fois le travail d’expression du besoin ;
• la MOE s’accapare la maîtrise du besoin qui pourtant devrait rester dans le giron de la MOA ;
• Plus technique, il n’est pas rare que la spécification vue par la MOE noie le besoin avec des considérations de l’ordre de la solution technique.

En fait, concernant le besoin, UP prévoit pour la MOE une activité de transition vers la conception : l’analyse du besoin. Cette activité permet de prendre connaissance du besoin non pas en effectuant une nouvelle expression mais en analysant l’expression du besoin sous un angle de structuration logique du système suivant le paradigme retenu (objet, service, etc.).

L’avantage de cette activité est de ne pas être une redite plus précise du cahier des charges, de permettre une validation de l’expression fournie en entrée et de préparer la conception logicielle qui suit.

Le tableau suivant liste les principales différences entre expression et analyse :

La spécification du besoin s’intéresse aux échanges des acteurs avec le système d’un point de vue externe. Les cas d’utilisation pour les échanges mais aussi le modèle objet pour la modélisation d’informations sont les cadres de pensée de cette activité. L’expression est à un carrefour et représente le contrat avec l’usage attendu du système. L’expression doit donc être lisible de toutes les parties prenantes au développement et à l’usage du système.

Sur le plan technologique, l’expression comme l’analyse doivent en être le plus agnostiques afin de ne pas se noyer dans des éléments de solution. Du point de vue de l’expression, la technologie est cantonnée aux contraintes ce qui la délimite clairement et évite la confusion, ennemie principale de cette activité.

L’analyse s’intéresse à bâtir une architecture logique modulaire du système et à projeter les éléments de l’expression sur cette architecture afin de préparer la conception qui,  ajoutera l’aspect technologique.  Cet éclairage du besoin sous un angle différent permet de lever les incohérences, d’identifier les manques et les imprécisions. Bref, elle possède une plus-value plus importante qu’une simple réécriture même plus formelle et plus approfondie du cahier des charges.

En résumé, la MOA a pour charge d’effectuer l’expression du besoin à l’aide de cadre de pensée et de formalisme adéquat (cas d’utilisation, etc.) et la MOE a pour charge d’effectuer l’analyse afin de s’imprégner du besoin, de structurer logiquement le système cible et ce faisant de valider l’expression. Une synergie vertueuse s’installe alors permettant une meilleure maîtrise du développement.

Opérateur en modulation d’électricité (Demand Response), Energy Pool agrège les gros consommateurs d’énergie pour valoriser leur capacité à moduler leur consommation à des heures critiques pour le réseau électrique grâce à ses centrales de modulation. Société Française, Energy Pool pilote aujourd’hui une centrale de modulation de 1000 MW de capacité (1er opérateur européen) et se déploie actuellement à l’international.

Dans le cadre de ce développement, Energy Pool a souhaité mettre en place un SI unique et flexible capable d’intégrer des structures de marchés spécifiques à chaque pays (réglementaire…).

Un partenaire conseil pour le nouveau SI

Pour ce faire, Energy Pool a retenu un partenaire stratégique : « ANTEO-Consulting nous a aidé à modéliser nos processus métiers, reprendre toute la structure UML de notre SI, lancer des développements du cœur de notre SI et lancer un appel d’offre pour gérer la partie applicative orientée services (SOA). » explique Davy Marchand-Maillet, Directeur Etudes & Développement d’Energy Pool.

La mission d’assistance s’est concentrée au départ sur un audit et une refonte du modèle objet qui structure le SI, avant de se prolonger par une urbanisation globale du SI et une définition de l’architecture d’entreprise cible.

Accompagnement sur mesure

« ANTEO-Consulting a fait preuve d’une remarquable maîtrise des enjeux et des contraintes du projet par le suivi de la ligne directrice initiale. Outre la forte compréhension de notre métier et l’implication de ses équipes au projet, ANTEO-Consulting se différencie par sa flexibilité et sa capacité à impliquer dans le projet les compétences nécessaires au moment où l’on en a besoin, pour trouver des solutions rapidement », conclut Davy Marchand-Maillet.

Plus d’information : communiqué de presse officiel.

Le succès de Java est certainement pour grande partie du au fait qu’il paraît « gratuit » face aux langages équivalents chez Microsoft. Et l’essor de l’open source dans les entreprises correspond aussi à l’essor de Java comme langage de développement.

A ses débuts pourtant, Java n’était pas open source. Sun espérait en tirer profit pour mieux vendre ses machines serveurs et son OS Solaris, a essayé de développer des produits payants exploitant Java mieux que la concurrence (NetBeans) etc. Mais ça n’a pas marché et Sun a annoncé en 2006 que Java allait devenir open source. C’est plus vite dit que fait puisque mettre un logiciel en open source est… Compliqué ! Quelle(s) licence(s) ? Quels composants ? Quels versions de sources ? Quel processus de gouvernance ? etc…

Comme souvent dans ces cas là, de nombreux projets open source pour héberger le langage Java sont apparus ! Notamment au sein de  la fondation Apache et à la FSF. Les choses ne se sont éclaircies qu’en… 2011 (5 ans après !!) Puisque IBM a finalement laissé tomber Apache et son projet Harmony pour rejoindre Oracle sur OpenJDK.

Est-ce que la situation est plus claire maintenant ? Heu… Comme indiqué ici : http://openjdk.java.net/faq/ il existe un Java open source (OpenJDK) mais aussi un Java non open source, celui d’Oracle ! En fait il existe encore plein d’autres Java open source, et également plein de JVM open source et propriétaires.

Au point que pour certains, l’avenir de Java réside peut-être dans d’autres langages qui fonctionnent sur une JVM. Ça peut paraître curieux. Pourquoi utiliser la JVM mais pas Java ? Une raison importante est que la JVM, nécessaire à l’exécution de programmes Java, est présente dans beaucoup de « stacks » d’exécution en entreprise (socles d’infrastructure logicielle). Et  l’offre en JVM étant très fournie (cf. ci-dessus), il paraît peu risqué de poursuivre sur ce type de technologie. Pourquoi alors envisager des alternatives à Java ? Parce que l’offre est plus limitée, que l’aspect open source paraît fragile et surtout complètement verrouillé par Oracle et IBM, deux sociétés pas vraiment philantropiques . Du coup, les sociétés dont la stratégie repose essentiellement sur les technologies IT cherchent à ne pas risquer se retrouver pieds et points liés avec des politiques commerciales (celles d’Oracle et IBM) sur lesquelles elles ont peu de prise.

Au fait, est-ce que tout ça concerne notre activité chez Sodifrance ? Heureusement non ! Pas directement en tout cas. Java en tant que langage, technologie, écosystème est maintenant durablement installé dans les entreprises, notamment celles du secteur banque/assurance. Autant installé que… COBOL ! Et ce n’est pas demain que ça changera. Mais j’espère que cet éclairage est quand même profitable pour aider à comprendre ce qu’on entend parfois sur le sujet…

Il semble que les dates donnent toujours du fil à retordre aux développeurs et aux infrastructures. En cette année bissextile 2012, le ciel Azure de Microsoft s’est brusquement assombrie en cette fin de mois de février.

L’information, largement reprise dans la presse, rappelle les inconvénients de la concentration des données, et ce malgré des services à haute disponibilité.

Les ingrédients mis-à-jour sont:

• JSF/Mojarra 2.1.6
• Grizzly 1.9.46
• Metro 2.2
• Jersey 1.11
• Shoal 1.6.17
• EclipseLink 2.3.2
• Message Queue 4.5U2
• OSGi Core 4.3.0
• Update Center 2.3.5
• Hibernate Validator 4.2.0-FCS
• JavaDB 10.8.1.2
• Weld 1.1.4.Final

Je profite de cette news pour vous pousser la maps des instances Glassfish.

On sépare communément la maîtrise d’ouvrage (MOA) responsable de l’expression du besoin d’un système et la maîtrise d’œuvre (MOE) responsable de la réalisation de ce système. Bien que les rôles semblent bien définis, il n’en va pas vraiment de même dans la réalité. Un lieu commun est de trouver un cahier des charges produit par la MOA suivi d’une spécification du besoin réalisée par la MOE ; chaque document traitant à sa manière du besoin.

Pourtant si on respectait la délimitation des rôles, la MOE n’aurait pas à produire un document d’expression du besoin !  Quelles sont les raisons avancées pour justifier cet état de fait :

• La spécification du besoin rédigée par la MOE est plus détaillée et plus formalisée ;
• En rédigeant cette spécification, la MOE s’approprie le besoin ;
• Le  cahier des charges propose une vue d’ensemble du besoin mais manque de précision ;
• Et  sous le couvert, la MOE  indique qu’avec seulement le cahier des charges, elle serait bien en peine  d’avoir une vision du besoin suffisamment claire et précise pour bâtir une solution.
• Certaines MOA avouent aussi que la formalisation complète du besoin à l’aide des langages de modélisation (UML, E/A, BPMN, etc.) n’est pas de leur ressort.

Le problème ici est psychologique. La MOA perçoit la formalisation à l’aide de cadres de pensée et de formalismes clairement définis et standards comme étant trop technique. C’est dommage car l’expression du besoin est, nous l’avons dit, essentielle et se doit d’être abordée avec les meilleures armes possibles et cela pour deux raisons :

• Réaliser une bonne expression du besoin cohérente, complète et sans ambiguïté est l’activité la plus difficile du développement logiciel. Exprimer le besoin,  c’est le modéliser et le faire sans l’aide de techniques et de bonnes pratiques est une gageure.
• L’expression du besoin est à la base du développement logiciel. Si celle-ci est bancale  alors le projet sera pénible à vivre et le résultat sera lui aussi bancal. En 2002, le Standish Group a publié une statistique très intéressante  issue de l’étude de plusieurs milliers de projets aux Etats-Unis : 45% des fonctions développées sont inutiles !!

Quels sont les cadres de pensées qui peuvent aider à une bonne expression du besoin ?

Dans le contexte des systèmes d’information, il suffit de s’en remettre aux fondamentaux : le système informatique à réaliser doit permettre des échanges d’informations avec ses utilisateurs. On doit donc s’intéresser

• Aux  informations échangées, leur structuration et leur sémantique;
• Aux échanges qui traduisent une dynamique entre le système et ses utilisateurs lors des tâches qu’ils réalisent.

Ces deux domaines doivent chacun être modélisés à l’aide d’un cadre de pensée et un formalisme adapté. Pour les informations, on peut prendre le cadre de pensée objet sans sa dimension comportementale et pour les échanges, on peut prendre le cadre de pensée des processus pour une vision globale multi-utilisateurs et le cadre de pensée des cas d’utilisation pour se centrer sur une application et ses utilisateurs.

Mettre en œuvre de telles pratiques et de telles techniques nécessite toutefois une formation car la simple rédaction d’une expression du besoin en titrant certains chapitres processus ou cas d’utilisation n’en garantit pas la bonne maîtrise et la qualité. UML n’est rien sans méthodologie pour le mettre en pratique et ne l’oublions pas, exprimer le besoin est une activité difficile qui prend du temps à bien maîtriser.

Oracle apporte quelques retouches (tests plus complets, nouveau composant d’agrégation, amélioration des performances, etc) à son couteau suisse SOA avant l’arrivée de la 12c. Les previews ODI et USM dessinent déjà les contextes de cette prochaine version.

Pour cette 11.1.1.6.0, les modifications portent sur :

Bus de Services OSB

• Amélioration des codes d’erreurs REST
• Correctif lors des imports de projets
• Assertions OWSM pour les proxy locaux (proxy-to-proxy)

Adapters

• User Messaging Service en preview (Ne pas mettre en prod !)
• Chargement retardé pour améliorer le démarrage du serveur

BPEL

• Gestion fine des réentrances et des transactions
• Amélioration des impacts liés à la déshydratation des instances
• Ajouts BPEL 2.0 dont l’aggregation (cf eaipatterns)
• Test au niveau des composants SCA

B2B

• Mapping EDI Any-to-any
• Compléments de l’intégration HealtCare (détails)

RULES

• Amélioration des tables de décisions
• Suite de tests des règles

BAM

• Amélioration des performances sous forts volumes
• Intégration ODI 11g en préview
• Recherche sur expiration configurable
• Vue administrateur de toutes les alertes

CEP

• Support JavaBean
• Parallélisme

Enterprise Manager OEM

• Amélioration du contenu des alertes BPEL remontée
• l’analyse et le rejeu des instances

Infrastructure WL

• Réduction des traces mémoires
• GridLink (coherence) pour le RAC
• Amélioration de la purge
• WebLogic Diagnostic Framework

Liste complète des nouveautés sur OTN: New Features In SOASuite 11gR1PS5

En effet, je constate souvent chez nos clients qu’il n’est utilisé qu’à des fins de contrôleur de code source et de serveur d’intégration continue.

L’intégration de Microsoft® Project Server 2010 et Microsoft® Team Foundation Server 2010 permet une meilleure gestion du cycle de vie d’une application informatique (Application Lifecycle Management).

De nombreux outils peuvent se connecter, interagir, informer la tour de contrôle Microsoft® Team Foundation Server :

• SharePoint (collaboration, portail, partage),
• Expression (design web),
• Office (documents),
• IDE de Visual Studio (développement),
• Team Explorer (explorateur de projet),
• Web Access (frontal web),
• Les extensions.

Ainsi, le gestionnaire de version de Microsoft® Team Foundation Server 2010 s’intègre de la manière suivante :

Schématiquement, l’architecture mise en œuvre est la suivante :

La gestion de projets s’effectue via Microsoft® Project Server 2010, l’ingénierie des développements via Microsoft® Team Foundation Server 2010. Le tout étant interconnecté à un Microsoft® Sharepoint 2010 (lui-même stockant ses données sur Microsoft® SQL Server 2008).

 Ainsi, on dispose de puissants nouveaux moyens de publication :

1 : Il est possible de publier des tâches et de voir le consommé d’un projet stocké dans Microsoft® Project Server 2010.
2 : Il est possible de planifier des éléments à réaliser et de voir ceux déjà faits.

Et de puissants nouveaux moyens de collaboration :

Les utilisateurs peuvent ainsi utiliser soit les clients lourds (Microsoft® Project 2010 et Microsoft® Visual Studio 2010) soit les clients légers tels que Microsoft® Project Web Access 2010 et Microsoft® Team Web Access 2010.

Afin de mieux comprendre le fonctionnement de ces outils, je vous invite à utiliser la plateforme Hyper-V de démonstration préparé par l’équipe de Microsoft®.  (CTP de décembre 2011 disponible ici.)

Les sujets abordés ont été:

• JEE 6
• Maven et Hudson
• Outillage Eclipse et Netbeans (si si, pas de JDeveloper ! Il devrait sortir d’ici quelques semaines toutefois)
• REST
• Coherence

Au delà du discours marketing, Oracle propose un serveur dans le prolongement de Glassfish. Maintenant full JEE 6, WebLogic est dans cette version une plateforme d’exécution plus légère, s’intégrant aux pratiques d’intégration continue et fournie avec un service de Data Grid, Coherence, afin assurer la scalabilité et la performance des plate-formes sous fortes charges.

Oracle continue  d’améliorer son plugin pour manipuler WLS lors de builds maven. On y retrouve les start, stop, deploy, etc. sur un serveur définit à la racine du projet (à côté du pom). Ceci permet un controle totale du serveur  lors d’un usage sous Hudson.

Au final, cette nouvelle version 12c sera, sans aucun doute, plus appréciée des développeurs Java EE.

Pour les curieux, vous trouverez plus d’infos sur OTN.

Voici les faits : il s’agit d’un comportement pour le moins curieux observé lors de la sérialisation de beans Flex vers Java, en l’occurrence des objets de transfert de valeurs de type Date, et ce pour une date de naissance positionnée au 24/10/1960.

• En AS3, on crée un DTO Date dont la valeur interne (objet Date standard) contient 24/10/1960 00:00:00. Flex envoie au serveur Java la date sous la forme d’un nombre de millisecondes depuis le 01/01/1970.
• En Java, on récupère cette valeur et on crée un objet java.util.Date. Le problème survient à ce moment : en Java, cet objet vaut 23/10/1960 23:00:00 …

Lors de l’utilisation de ce DTO Date, on a perdu un jour, ce qui pause bien évidemment un sérieux souci.

Il semble apparemment que Flex et Java ne soient pas d’accord sur le calcul des heures d’été / heures d’hiver pour des dates anciennes. Cet article décrit exactement le même constat.

Des questions viennent immédiatement à l’esprit :

•  Y a-t-il une configuration particulière à faire côté Flex ou Java ?
•  Y a-t-il un problème avec la locale ?

Dans les deux cas, Java et Flex, on utilise la locale système par défaut sans moyen de la paramétrer ; l’article suggère plutôt une différence sur les algorithmes de calcul du Daytime Saving (Heure d’été / Heure d’hiver) pour les dates anciennes.
Un deuxième test avec une date récente au 24/10/2011 ne fait plus apparaître ce problème. En examinant la question, on constate que Flex crée la date du 24/10/1960 dans le fuseau GMT+2 et GMT+2 correspond en France à l’heure d’été et GMT+1 à l’heure d’hiver.

Le problème, c’est que l’heure d’été n’a été instaurée en France qu’en 1976 après le choc pétrolier !

Il semble donc qu’il y ait bien une différence d’algorithme de calcul du DST (Daylight Saving Time) entre Flex et Java comme suggéré dans l’article. Après une enquête plus approfondie, ce problème avec les dates entre Flex et Java existe bien, sachant qu’AMF ne tient pas compte de la timezone. Il a été évoqué avec le support d’Adobe en 2009, sans qu’il ait visiblement donné lieu à un correctif dans BlazeDS/LCDS.

Encore un bel exemple après l’an 2000 où l’informatique malmène l’Histoire …