pheromone demo reel from Pheromone Lab on Vimeo.
Wednesday, March 30
Friday, March 25
Règles d'usage lors de la rédaction d'analyses fonctionnelles
Outre cette définition formelle, certaines règles d’usage sont à respecter :
- la forme passive est à éviter
- la forme négative est à éviter
- la formulation de la fonction doit être indépendante des solutions susceptibles de la réaliser
- la formulation doit être la plus concise et la plus claire possible
Plus de détail sur l'analyse fonctionnelle dans Wikipédia.
- la forme passive est à éviter
- la forme négative est à éviter
- la formulation de la fonction doit être indépendante des solutions susceptibles de la réaliser
- la formulation doit être la plus concise et la plus claire possible
Plus de détail sur l'analyse fonctionnelle dans Wikipédia.
Disques déparaillés!
Mon vélo est de retour de la shop... déparaillé! Le disque avant était S-shaped (croche), donc frottait sur les patins de frein. Remplacé avec la pièce Avid BB7 modèle 2011... très différent du modèle 2007!
2007:
2011:
Tuesday, March 22
Xtranormal, un ancien employeur, prend le 9e rang des 10 compagnies les plus innovantes en vidéo pour l'année 2011:
09 / Xtranormal
For letting anyone become a web video creator. Its simple web-based app converts a text script into an animated video where users can choose their characters, add expressions, and toy with camera angles.
Thursday, March 17
Summary of all the iPad development by VMware at VMworld in Copenhagen
Plusieurs applications iPad présentées par VMware à la conférence VMworld à Copenhague pour vous aider à gérer vos machines virtuelles.
Wednesday, March 16
Tuesday, March 15
Planifier pour poser les bonnes actions
Un minimum de planification est essentiel dans le but de non seulement faire les choses, mais faire les BONNES choses!
Planifier est simplement identifier le travail à venir, le prioriser et l'assigner aux membres de l'équipe durant la phase de développement.
Planifier est simplement identifier le travail à venir, le prioriser et l'assigner aux membres de l'équipe durant la phase de développement.
Monday, March 14
Votre entreprise est-elle de CMMI niveau 1?
CMMI (Capacity Maturity Model and Integration). Il s'agit d'un ensemble de bonnes pratiques pour améliorer les activités d'ingénérie, en développement de logiciel notamment.
Le premier niveau de maturité se décrit par ceci:
Il n'y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétenceset les ressources propres de cet individu sont la raison du succès ou de l'échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n'y a pas de description du niveau de maturité 1 dans le modèle.
Vous comprendrez que l'intérêt est de passer du niveau un au niveau deux, puis au niveau trois jusq'à atteindre le niveau 5 (dans un monde idéal).
Pour plus d'information, je vous invite à visiter le site du Software Engineering Institute pour en savoir plus sur le modèle CMMI.
Le premier niveau de maturité se décrit par ceci:
Il n'y a pas de grand pilier directionnel, aucune façon de faire ou standard ne sont établis (ou bien ils sont documentés mais ne sont pas utilisés), tout doit être fait. Il n'y a pas de surveillance (monitoring), aucune évaluation de performance et la communication est absente. Les faiblesses ne sont pas identifiées et les employés ne sont pas au courant de leurs responsabilités de façon définie et absolue. Les réactions aux incidents se font en mode urgence, sans identification claire des priorités. À ce niveau les solutions ainsi que les projets sont décidés, développés et instaurés par un individu. Les compétenceset les ressources propres de cet individu sont la raison du succès ou de l'échec du projet (par dérision, ce niveau est aussi nommé héroïque ou chaotique). Il n'y a pas de description du niveau de maturité 1 dans le modèle.
Vous comprendrez que l'intérêt est de passer du niveau un au niveau deux, puis au niveau trois jusq'à atteindre le niveau 5 (dans un monde idéal).
Pour plus d'information, je vous invite à visiter le site du Software Engineering Institute pour en savoir plus sur le modèle CMMI.
Friday, March 11
Deux types de besoins
L'évaluation de la qualité consiste à valider si les besoins sont rencontrés. Souvent, en entreprise, on se contente de tenter de rencontrer les besoins exprimés.
Par exemple, au restaurant, le client demande un steak saignant avec des patates. Si le restaurateur se contentait de s'assurer que le client reçoive son steak saignant et ses patates, il ferait fausse route.
Également - sinon encore plus important - le fournisseur, en plus de rencontrer les besoins exprimés du client, doit s'assurer de satisfaire les besoins implicites.
Par exemple, au restaurant, le client s'attend (sans l'exprimer clairement) à ce que l'ambiance soit bonne, le serveur soit poli, les ustensiles soient impeccables, ...
Donc, l'équation:
Qualité = Besoins exprimés + Besoins implicites
Maintenant, dans le monde du développement logiciel, si on transpose ce concept on arrive à l'équation:
Qualité = Bon produit + Bon processus
On s'attarde trop souvent sur l'état du produit final. Puis, une fois terminé, on se lance au développement du suivant. Si on se donnait la peine de faire de la rétroaction, on réaliserait que malgré la qualité du livrable, plusieurs améliorations au niveau du processus de développement sont possibles afin que le produit suivant soit encore mieux développé.
Tout ce billet pour en arriver à la phrase suivante:
La qualité du processus doit aussi être analysé en plus de la qualité du produit.
Par exemple, au restaurant, le client demande un steak saignant avec des patates. Si le restaurateur se contentait de s'assurer que le client reçoive son steak saignant et ses patates, il ferait fausse route.
Également - sinon encore plus important - le fournisseur, en plus de rencontrer les besoins exprimés du client, doit s'assurer de satisfaire les besoins implicites.
Par exemple, au restaurant, le client s'attend (sans l'exprimer clairement) à ce que l'ambiance soit bonne, le serveur soit poli, les ustensiles soient impeccables, ...
Donc, l'équation:
Qualité = Besoins exprimés + Besoins implicites
Maintenant, dans le monde du développement logiciel, si on transpose ce concept on arrive à l'équation:
Qualité = Bon produit + Bon processus
On s'attarde trop souvent sur l'état du produit final. Puis, une fois terminé, on se lance au développement du suivant. Si on se donnait la peine de faire de la rétroaction, on réaliserait que malgré la qualité du livrable, plusieurs améliorations au niveau du processus de développement sont possibles afin que le produit suivant soit encore mieux développé.
Tout ce billet pour en arriver à la phrase suivante:
La qualité du processus doit aussi être analysé en plus de la qualité du produit.
Subscribe to:
Posts (Atom)