Devops for Growth
107.5K views | +8 today
Follow
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...

Popular Tags

Current selected tag: 'points de fonction - ISO 19761'. Clear
Scooped by Mickael Ruau
Scoop.it!

IWSM2014 COSMIC masterclass part 3 - Automatic measurement of UML s…

COSMIC masterclass part 3 at IWSM2014
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

IWSM2014 COSMIC masterclass part 1 - What's new in version 4.0 (Cha…

COSMIC masterclass part 1 at IWSM2014
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Using the COSMIC Method to Estimate Agile User Stories

This presentation presents an estimation process based on the COSMIC FSM method jointly with a qualitative driver (quality of documentation)
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Les points de fonction

Les points de fonction | Devops for Growth | Scoop.it
Des points de fonctions : pour quoi faire ?

L’utilisation des points de fonction est multiple. L’IFPUG propose trois principales utilisations :

La valorisation fonctionnelle des applications. Compte la valeur du parc applicatif et compare la valeur fonctionnelle de diverses applications. Ce type de comptage offre également un moyen de comparaison entre les fonctions utilisées et celles qui sont offertes par une application. Elle met en regard les fonctions livrées et les fonctions commandées à un prestataire.
La valorisation projet mesure l’ensemble des composants fonctionnels à réaliser dans le cadre d’un nouveau projet. Cette valorisation est un point essentiel d’entrée pour l’estimation de charges, car le facteur le plus influent de l’effort est la taille du développement demandé. Cette estimation de charges peut se faire selon le standard IFPUG (non normalisé ISO) ou via d’autres méthodes d’estimation de charges qui acceptent les points de fonction en entrée comme COCOMO II.
La valorisation d’évolution. Cette dernière part d’une nomenclature fonctionnelle où la nature de l’évolution de chaque composant est marquée (Modification, Suppression, Création). Comme pour la valorisation d’un projet, celle de l’évolution est un point d’entrée pour l’estimation de charges.

Les points de fonction s’utilisent au-delà de ce que propose l’IFPUG. Dans de nombreux cas, les points de fonction apportent un moyen de mesure riche et fiable.
Mickael Ruau's insight:
Le principe des points de fonction

 

Les points de fonction sont un standard depuis la fin des années 70. Au milieu des années 90, une normalisation expérimentale est entreprise par l’AFNOR. En 2003, l’ISO normalise la partie mesure du standard de l’IFPUG (International Function Points User Group).
Les points de fonction ont pour objectif de mesurer la « valeur fonctionnelle » d’une application ou d’un projet. La mesure fonctionnelle est représentative de l’importance des services d’une application existante, des besoins des utilisateurs ou de l’ampleur des développements à réaliser. Et cette mesure est réalisée selon le point de vue fonctionnel des utilisateurs.
Elle s’effectue en mesurant les données et les fonctions selon plusieurs catégories (2 pour les données et 3 pour les fonctions) et suivant 3 niveaux de complexité (faible, moyen et élevé).

Les catégories des données :

  • Les données internes appelées GDI en français et identifiées sous le terme ILF (Internal Logical Files) dans le standard IFPUG et la norme ISO.
  • Les données externes appelées GDE en français et identifiées sous le terme EIF (External Logical Files) dans le standard IFPUG et la norme ISO.

Les catégories des fonctions :

  • Les Entrées appelées ENT en français et identifiées sous le terme EI (Externals Inputs) dans le standard et la norme.
  • Les Sorties appelées SOR en français et identifiées sous le terme EO (Externals Outputs) dans le standard et la norme.
  • Les interrogations appelées INT et identifiées sous le terme EQ (External Inquiry) dans le standard et la norme.

Le principe de la méthode consiste à compter l’ensemble des composants perçus par les différents utilisateurs d’une solution. La façon dont sont mis en oeuvre les composants (données ou fonctions) n’est pas prise en compte. Les aspects d’implémentation ou de réalisation technique ne sont pas étudiés dans la partie normalisée de la méthode, car cette dernière se focalise uniquement sur les aspects fonctionnels.

 

Par utilisateur, on désigne les utilisateurs finaux, les administrateurs fonctionnels, la MOA, mais aussi les applications tierces qui échangent des résultats. Les données référencées et qui sont modifiées par une application tierce doivent être comptabilisées car elles correspondent à des données externes.
Les services offerts aux applications tierces sont comptés de la même façon que les fonctions offertes aux utilisateurs humains sous la forme d’Entrées, de Sorties ou d’Interrogations. Le terme « Nomenclature fonctionnelle » désigne l’arborescence des fonctionnalités qui identifie précisément le contenu métier du système mesuré.
Seuls les composants visibles depuis l’extérieur de l’application sont comptés. Les autres composants sont ignorés, car dépendant des choix d’implémentation ou liés aux solutions technologiques mises en oeuvre. A partir de cette liste, pour chaque composant, à partir de l’association entre leur catégorie et leur complexité, les règles de la norme IFPUG fournissent un poids fonctionnel.

 

La valeur fonctionnelle de la solution est obtenue par l’addition du poids fonctionnel de tous les composants. Il s’agit donc d’une approche additive.
La valeur fonctionnelle, en points de fonction, s’établit selon trois principales façons de compter :

  • La mesure détaillée (detailled) détaille l’ensemble des composants et leurs caractéristiques (catégorie et complexité) de chaque composant. Cette mesure est très précise, mais très chronophage.
  • La mesure moyenne (light) obtient une bonne précision sans être excessivement chronophage. Pour un grand nombre de composant, cette mesure présuppose de la convergence des complexités vers une valeur moyenne. Elle détaille l’ensemble des composants et leur catégorie. La complexité n’est pas précisée, tous les composants sont comptés avec une complexité moyenne. Cette mesure est nettement plus rapide que la mesure détaillée pour une faible diminution de la précision.
  • La mesure rapide (fast) estime rapidement l’ordre de grandeur du nombre de points de fonction. Elle ne détaille pas l’ensemble des composants de la nomenclature fonctionnelle. Diverses techniques permettent aux experts d’approcher le nombre de points de fonction. La plus connue consiste à établir un ratio représentatif entre poids des données et poids des traitements et à ne compter que les données.
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

IWSM2014 COSMIC masterclass part 4 - Estimating with COSMIC (Alain Ab…

COSMIC Masterclass at IWSM2014 - part 4
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

IWSM2014 COSMIC masterclass part 2 - Dealing with NFR (Chris Woodwa…

COSMIC masterclass part 2 at IWSM2014
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Using cosmic in agile projects

Survey of experience of using COSMIC in Agile projects - interim findings Presented at UK COSMIC Special Interest Group 10th April 2014 Charles Symons
No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Introduction to the method of measuring software

Introduction to the  method of measuring software | Devops for Growth | Scoop.it

 The COSMIC method is an internationally standardized method (ISO/IEC 19761) for measuring a size of the functional requirements of most software domains, including business application (or ‘management information system’) software, real-time software, infrastructure software and some types of scientific/engineering software.

 

Mickael Ruau's insight:

The method is now very widely used around the world, in all the domains for which it was designed, for purposes such as the measurement of sizes in software contracts, and is successfully applied for project performance measurement, benchmarking and estimating.

Do you want an introduction to the ‘Why’ and ‘How’ of software size measurement and why COSMIC was developed? Read chapters 1, 2 and 3.

Do you want a two-page overview of the COSMIC method? Read chapter 4.

Do you want a more detailed introduction to the COSMIC method, but not the full details of the Measurement Manual? Read chapters 5, 6 and 7.

Do you want to know about the advantages and benefits of using the COSMIC method? Read chapter 8.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Software Hyper-productivity and Function Points

Software Hyper-productivity and Function Points | Devops for Growth | Scoop.it


Jeff Sutherland uses Function Points to compare different projects, and determine productivity differences. I think that hyper-productivity is real; but using Function Points to demonstrate it is not an appropriate way to demonstrate it.

In my opinion, Function Points are a cargo cult, on the border of superstition. Function Points have the same credibility as numerology, astrology, biorhythms, anthropometry and other pseudosciences that try to gain a semblance of respectability by resorting to numbers in a manipulative and distorting manner.
No comment yet.