Software Solution Project Planning

project_phasesThis article is an extract of the Software R&D Best Practices training, it presents how the project manager should handle a software solution project planning and rollout.

Project planning

The project planning preparation is divided in 3 sub-projects.

  • Plan the pre-study phase.
  • Plan the project from study to delivery
  • Plan the maintenance phase

The pre-study phase must be planned itself in an autonomous way because the project may finish if there’s no agreement on the scope, duration, cost and quality are found between the provider and the customer.

The maintenance phase is planned after the customer accepetance meeting (ie the final payment but eventually the warranty). It’s a recurrent activity phase with mini-projects to be planned on a continuous flow basis up to the maintenance phase end that depends on product life time (or contract guarantee) duration and scope

The remaining project phases, from study to delivery will be planned during the pre-study and finalized at it’s end because without a completed and validated solution requirements document, the project manager does not have enough stable information to produce a realistic project plan.

Project planning steps

The project planning can be done with following steps:

  1. Define project work breakdown
  2. Estimate project tasks workload
  3. Assign resources to tasks : check/ask for resources availability
  4. Identify project risks
  5. Determine project risks & events buffer
  6. Determine project milestones
  7. Iterate on scope, milestones, cost and quality with customer, manager, team and quality assurance officer

These steps should be done in the proposed order in a Gantt chart like this one:

project_wbsProject workload estimation

The project workload estimation (cost and duration) should be based on implementation workload (development, integration, unit tests and software documentation writing) done in the build phase.

The study workload, test workload (including test preparation, test runs and issues fixes), delivery workload and project management workloads are deduced from the implementation workload.

The implementation workload is deduced from solution requirements document (contains use cases, logical architecture, integration flows, business rules, software documentation to be delivered and other non business requirements)

The development workload can be estimated with an in-house method or standard method like Functional Points or COCOMO.

An estimation table about how to spread the total workload from the implementation workload in the build phase is provided in the Software R&D Best Practices training.

Tag & branches policies

I like to dig in github for libraries and other useful components to add in a project I’m working on. I’m much more experienced on Subversion than Git, the trending version control system. Git success is claimed by it’s strong branches features and it’s distributed repositories with push and pull, specially usefull on open source project but, when looking on most open source repositories in github i didn’t see a meaning full use of tag and branches. That’s why I decided to create this article.

I propose here what is, IMHO, a good way to use tag and branches, on a software project context with build/delivery, and maintenances of several release in a software R&D project.

A version control system repository must used for each software product or solution. Several release or maintenance project on the same software should share the same central repository.

The root directory containing all the delivery content is tagged.

At least each delivery to customer or other external teams are tagged. The tag name follows a tag rule name like Apache versioning or Semver (for me, the first digit should be trigger by marketing needs).

Each maintained software release must have a branch created just after it’s offical delivery.

This figure shows an example of branches and tags on a software products built and delivered in several iterations (or Scrum sprints) and then maintained in several version, like when several customer are using differents differents version as operating systems.

tags_and_branches

  • 1.0.0 to 1.0.4 where delivered to the customer as iteration deliveries, 1.0.3 was not delivered because of a NOGO after customer acceptance review
  • 1.1 release is maintained in a new maintenance branch for a customer guarantee since 1.1.4, while 1.2 released are done on the same branch as 1.1 and 1.0
    • On 1.1 maintenance, after 1.1.5 maintenance release delivery, 3 patches where delivered. 1.1.6 maintenance release includes those patches making them deprecated for 1.1.6 and next 1.1 maintenance release
    • Issues fixed in 1.1 maintenance branches should be merge in 1.x and maybe 1.3.x branches
  • 1.3.x started on a new branch because significant design changes where done (1.x branch can now be used for maintenance for 1.2 maintenance
  • 2.0 start release starts from scratch (avoiding commits and tags on master is an usual practice)

The « dev/ » at the bottom left corner stands for the directory where all the delivery content source files are stored : source code, configuration files, samples,  delivered documentation… You Should have another directory at same level, lets call it « doc/ », where all undelivered elements are stored  : project documents, internal technotes…

I will describe deeper what these directory content in another article. If you can’t wait, you can have the full picture, with much more information like project milestoner, or server environments in the Software R&D Best Practices training.

Augmenter la valeur du système d’information

Je vous conseille la lecture du document Augmenter la valeur du système d’information qui décris ce que doit être la MOA du SI.

Voici un résumé de chapitres qui traitent du choix entre make / buy / run et la prise en compte des coûts d’acquisition (CAPEX) et de fonctionnement (OPEX) dans le choix d’une solution informatique.

On parle en gestion de projet d’analyse de décision MAKE-BUY. En fait, lorsqu’il s’agit d’informatiser des processus métier de l’entreprise, il y a désormais une troisième option à prendre en considération la location :

  • FAIRE (MAKE) : Développer en interne
  • ACHETER (BUY) : Intégrer des logiciels tiers
  • LOUER (RENT) : Souscrire à une offre en mode SaaS

Les raisons initiales de l’investissement informatique sont un facteur déterminant de la stratégie d’achat. Par exemple :

  • le développement métier, lorsque l’activité de l’entreprise doit croitre ou être redéployée sur d’autres marchés
  • la gestion de l’obsolescence, lorsque les outils actuels ne sont plus adaptés, qu’ils coutent de plus en plus cher à maintenir et à utiliser
  • les contraintes réglementaires, lorsque que le cadre légal de l’entreprise change et qu’il nécessite des adaptations

Le schéma ci-dessous donne un aperçu des stratégies d’achat recommandées en fonction du besoin initial :
faire_acheter_louer

Ce que nous dit ce schéma c’est que pour développer son activité commerciale, il est préférable d’acquérir durablement un outil informatique. L’achat d’un logiciel ne facilitera pas la distinction de son offre c’est pour cela que le MAKE est préférable… à condition d’avoir le savoir faire (maitrise d’œuvre) ou à minima le savoir faire faire (maitrise d’ouvrage).

Le schéma ci-dessous informe sur les conséquences de chaque stratégie d’acquisition :
strategie_consommationEt enfin un dernier schéma sur la répartition des coûts d’acquisition et d’exploitation d’une solution logicielle dans le cas d’une acquisition de type MAKE.

build_run

La maintenance d’une application constitue environ 60 % du coût de sa vie. Dans ces 60%, 40 % concerne de la maintenance évolutive, la maintenance corrective étant aux alentours de 17 %. Dans le cas de l’intégration de logiciels tiers (BUY), la part du build, tout comme la phase d’étude est généralement moins élevée. Ce bénéfice n’est toutefois pas toujours compensé par le coût des licences. Ainsi, en considérant les licences, c’est à dire le coût d’usage de l’application, comme ceux de fonctionnement en exploitation (RUN), on reste sensiblement dans les mêmes tendances : Ce qui coûte cher, c’est l’usage. Dans le cas d’une location de logiciel (RENT / SaaS) presque tout les coûts sont remplacés par l’abonnement. C’est séduisant mais en plus des inévitables coûts d’intégration de la solution SaaS au SI, il faut avoir conscience des conséquences de ce type de solution comme le révèlent les courbes du 2nd schéma.

Un projet réussi doit satisfaire les critères de périmètre fonctionnel, coût, délai et qualité de la solution. Cette qualité s’exprime d’abord sur le coût qu’impose la solution logicielle sur le récurrent (fonctionnement en exploitation ou RUN) et la rigidité qu’il lui amène (évolutions, corrections).

Alors comment améliorer la valeur de son système d’information ? Quelques pistes en lisant Augmenter la valeur du système d’information de Franck Rinaudo.

L’importance de la modélisation dans les entreprises

ceisarLe CEISAR à fait paraitre un article sur l’importance de la modélisation et de la place des objets metier dans la transformation du SI d’une entreprise à l’occasion d’un partenariat avec Praxemehttp://www.ceisar.fr/actualites-et-evenements/detail-de-l-actualite/back/1/article/ceisar-praxeme.html
J’ai adhéré à l’association Praxeme Institute début 2013 suite à une formation en Business Architecture & Transformation mais lorsque je parle de Praxème peu de collègues connaissent :  TOGAF et Urba-EA sont des méthodologies plus connues. Alors voici un petit résumé de ce que je considère de plus novateur dans Praxème.
praxeme
Praxeme sépare la partie métier (ou Business Architecture TOGAF) en 3 « aspects » :
      • l’aspect sémantique où sera défini le modèle métier  : modèle de donnée orienté objet
      • l’aspect pragmatique  ou sont définis les processus métier, organisation, jargon, habitude
      • l’aspect géographique : pour les différences juridiques, culturelles, les distance inter-sites et autres décalages horaires qui méritent d’être pris en compte.

 

L’aspect sémantique défini le modèle métier, plus pompeusement le « coeur de métier » ou « le savoir métier » :
  • les objets métier mais pas les processus métier ni l’organisation qui porte dessus
  • les règles métier indépendamment de la façon dont l’activité métier est pratiquée dans une organisation
  • les différents états des objets et les transitions autorisées (cycle de vie, règles de gestion)
C’est une documentation unique et partageable avec plusieurs organisations de l’entreprise (ex: filiales étrangères).
Souvent après ces explications ce n’est pas encore assez  clair pour le néophyte alors voici un exemple que j’ai consolidé à partir de plusieurs messages d’une discussion entre adhérents de l’association Praxeme :
2042Lorsque l’on travail avec des organisations (quelles soient gouvernementales ou privées) on est aussi confronté à la volonté de ces organisations à résister à tout changement et à légitimer leur existence dans leur forme actuelle. Donc, inconsciemment, a leur volonté de modéliser des objets pragmatique en au lieu des objet sémantiques. Prenons la feuille de déclaration de revenus (c’est l’époque…) le piège consisterait à modéliser l’objet métier « déclaration 2042 »  plûtot que les objets métier « revenu », « contribuable », etc. : un modèle uniquement pragmatique (avec l’objet métier 2042) ne sera applicable qu’en France, et rendra difficile la transformation de la gestion des impôts (comme par exemple la mise en place de prélèvement à la source) alors qu’un modèle sémantique (avec des objets métier moins lié à l’organisation actuelle mais plus à la « réalité » : revenu, contribuable, etc.) est indépendant de l’organisation existante et potentiellement applicable dans d’autres pays.
Pour le reste de la méthode (les aspects logique, logistique et physique) c’est plus « classique » ont retrouve les couches logique/fonctionnelle, applicative, infrastructure/technologique d’Urba-EA ou TOGAF. L’Organum par exemple, reprend les idées de l’Architecture Repository TOGAF.
Un regret personnel : le latin est utilisé pour nommer différents éléments de la méthode et cela a été volontairement choisi par soucis d’universalité mais je trouve que cela apporte de la confusion à beaucoup de personne peu habitué à cette langue.
Pour plus d’information sur l’aspect sémantique voir http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf

 

TOGAF, la belle à marier


Les frameworks d’architecture d’entreprise français tels que Urba-EA et Praxème sont peu connus à l’international et parfois opposés à tort aux frameworks anglo-saxons comme le célèbre TOGAF auquel je viens d’être formé.
TOGAF est orienté activités de l’architecte : il est fort sur ce sujet avec des check lists de quoi faire à chaque étape d’un projet par exemple.  Certains trouverons aussi des « manques » sur les méthodes et le formalisme a appliquer à chaque phase d’un cycle projet TOGAF, mais ces manques sont volontaires pour laisser la place au « comment faire » de ces phases à d’autres méthodes. Ces méthodes doivent d’ailleurs être choisies en phase préliminaire et référencées dans la « reference library » de l’ « architecture repository », .
Par exemple PMBOK peut être utilisé dans les phases F et G du cycle de transformation du SI de l’ADM (la rosace ci-contre).
L’un des objectifs de la phase préliminaire de l’ADM est d’adapter l’ADM au contexte d’une entreprise mais aussi à d’autres frameworks, outils et formalisme.

Lors de phase préliminaire de l’ADM il est conseillé d’adapter la démarche, et globalement tous les éléments du framework, au contexte de l’entreprise.

 

C’est donc en phase préliminaire que l’on peut décider d’appliquer Urba-EA ou Praxème à TOGAF.
Christophe Longépé aborde ce sujet au chapitre 11.3.3 de l’ouvrage « Le projet d’urbanisation du SI » 4eme edition (ISBN 978-2-10-052883-7) je n’en parlerais donc pas ici…
Je viens du développement et de la modélisation orienté objet, et, mon plus grand regret est que dans TOGAF  l’approche « objet métier » est réduite à une « Data Entity » sans la dimension « objet » : sans opération, ni cycle de vie.
Cette DataEntity est élaborée dans un 2nd temps après les processus métier. Contrairement à Praxème qui préconise d’élaborer des objets métiers (analyse de l’aspect sémantique, qui exprime la connaissance du métier, indépendamment de la façon de mener l’activité.) avant ou à minima avec les processus métier.
Je viens de suivre une formation TOGAF, et j’en ai profité pour apporter le support et les notes que j’ai prises lors d’une formation  Praxeme « Business Architecture & Transformation » suivie en début d’année.
Voici mes réflexions sur le mariage de ces deux framework d’entreprise :
Le méta-modèle de TOGAF (part. IV) peut converger avec Praxeme si l’on fait les modifications suivantes :
  • déplacer la « Data Entity » dans le domaine de la « Business Architecture » du « Metamodel Reference with Relationship »
  • renommer la « Data Entity » en « Business Object » et que l’on y prend en compte le cycle de vie et des opérations.
  • utiliser UML pour les objets métier et BPMN pour les processus métier
La part. III de l’ADM, nommée « guide lines & techniques », peut ensuite être complétée avec les guides de Praxeme : le guide de l’aspect intentionnel dans peut compléter la phase A, les guides des aspects sémantique (http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf), pragmatique, géographique  peuvent compléter la phase B (analyse du métier) et l’aspect logique la phase C (analyse du système d’information) de l’ADM.
Je considère Praxeme comme un complément essentiel à TOGAF et il donc opportun que certaines entreprises choisissent de marier Praxeme et TOGAF.

CodevTT pour suivre l’avancement d’un projet

Louis travaille depuis 2010 sur un projet open source qui mérite d’être plus connu.

CodevTT  est un outil open source de gestion de projet, permettant un suivi détaillé de l’avancement des projets et des d’activités d’une équipe.

Il propose une interface web pour la saisie des comptes rendus d’activité, CodevTT collecte le consommé et le reste à faire sur les tâches. A partir de ces informations CodevTT génère rapports et indicateurs de productivité permettant de connaître en temps réel le niveau d’avancements des tâches et des demandes.

codevtt

CodevTT est basé sur MantisBT, une solution open source de suivi d’anomalies écrite en PHP, dont il étend le périmètre fonctionnelle à la gestion du temps de travail.

Pour plus d’informations voir codevtt.org

Bilan de la journée OpenData de janvier 2013 à Aix en Provence

j’ai participé à la journée OpenData citoyen  et au Carrefour des possibles
qui se déroulait le 30 janvier à la Méjane à Aix.
Je n’ai pas pu suivre les conférences du matin, taf oblige, mais j’ai pu participer à un
atelier de l’après-midi avec des débats sur l’Open Data autour des questions sur
  • à quoi ça sert ?
  • qui organise l’OpenData ?
  • un intérêt pour l’économie ou uniquement pour la transparence des collectivités publiques ?
Si vous ne savez pas ce qu’est l’OpenData regarder cette prez, et aussi cet article.
Ensuite j’ai pu suivre une présentation du concept d’intelligence collective pour l’innovation dans les entreprises
avec la mise en place d’organisation hiérarchique très « plate » (peu de niveaux) et une rotation du leadership
un peu comme dans une équipe de foot qui joue : le leader est celui qui possède le ballon.
J’ai découvert les EPN (Espace Publique Numérique) auparavant des cybercafés/médiathèques
financées par les collectivités qui aujourd’hui évoluent vers d’autres activités geeks en fonction
des initiatives de leur animateurs.
À partir de 18h, il y a avait une autre manifestation : le carrefours des possibles
qui sélectionne et accompagne des porteurs de projet. 10 projets étaient présentés, j’ai surtout
retenus ceux-ci :
  • Draftquest : un site web qui aide des écrivains en herbe à écrire un roman en 90 jours (10 minutes par jours en s’appuyant sur des résultats de recherche sur la créativité par la contrainte. Le site sera n’est pas encore en ligne, un article en parle plus ici.
  • Hub-cité : un projet à Lomé (Togo) qui utilise les méthodes de travail et d’animation de l’open-source tels que les bar-camps (événement sur 1j à 3 semaines quelque part), fablab (lieu permanent dédié à une activité, ouvert au public) pour motiver les populations à démarrer eux-mêmes des projets, d’abord dans la construction de maison en terre, puis d’autres activités : la réparations d’appareils éléctriques ou de moteurs, de l’informatique, etc. Sur chaque thème des volontaires (étudiants le plus souvent) apportent leur savoir faire pour animer un bar-camp. Plus d’infos ici.
  • Kinoulink : un projet démarrer lors du dernier startup week-end de décembre dernier à Marseille : il s’agit d’envoyer des photos de la famille à un cadre photo numérique pré-configuré pour que Mamie puisse avoir régulièrement et simplement des photos de toutes la famille, avec un plus: Sur les photos on peu visualisé si quelqu’un est en ligne, alors Mamie touche un visage et ça appel la personne concernée (téléphone ou vidéo skype) si elle est dispo. Ils sont 7 sur le coup. Je leur ai présenté CatchU et m’on dit que par exemple la plateforme de collaboration les aurait biens aidés au départ pour s’organiser, et qu’ils auraient peut-être besoins de quelques dispositifs de l’association prochainement.

 

OpenStreetMap ou GoogleMaps pour mon service sur internet ?

De nombreux articles sur le web comparent GoogleMaps et OpenStreetMap, comme par exemple cet article d’Inaglobal, la présente note est focalisée sur les éléments de choix entre ces deux solutions dans le cadre de la réalisation d’un service sur internet nécessitant des données géographiques.

Pour choisir entre ces deux solutions, les critères suivants sont retenus :

  1. la simplicité d’utilisation de la solution par l’utilisateur final
  2. le coût de mise en place de la solution
  3. le coût d’exploitation de la solution
  4. la pérennité de la solution
  5. le degré de liberté d’utilisation de la solution

Le tableau suivant résume  les comparaisons faites dans cette note : OSM vs GoogleMaps pour développer des services sur internet :

  • un point est attribué pour la solution qui a le meilleur bilan pour chaque critère évalué
  • lorsque les solutions n’ont pas été départagées aucun point n’est donné
Critère OpenStreetMap GoogleMaps
la simplicité d’usage par l’utilisateur final 1 1
Coût de mise en place 1 0
Coût d’exploitation 1 0
Pérennité de la solution 0 0
Liberté d’utilisation de la solution 1 0
Total 4 1

Un créateur de service sur Internet qui souhaite rajouter des informations sur une carte et les exploiter dans une application devrait donc préférer OpenStreetMap.

Celui qui souhaite une autonomie complète devra installer son propre serveur de carte. OpenStreetMap s’inscrit dans la mouvance OpenData, ce sont d’abord les données brutes plus qu’un service qui sont fournies.

D’après des membres de la communauté OpenStreetMap, les principales raisons invoquées pour passer de GoogleMaps vers OpenStreetMap, sont :

  • la licence: OpenStreetMap permet de réutiliser librement (y compris pour l’usage commercial) ses données sur n’importe quel support, ce que ne permet pas Google, même à titre personnel.
  • l’aspect financier: si la mise en place d’un système de tuiles OpenStreetMap complet n’est pas gratuit, les coûts sont beaucoup plus maîtrisables qu’une licence Google
  • la possibilité de développer ses propres styles de rendu, ainsi que de faire des cartes thématiques
  • la réactivité des mises à jour, ce dernier point est à pondérer depuis le lancement de GoogleMaps Maker
  • l’indépendance vis-à-vis de Google