Dimensionamiento en muchas métricas

[Alcaparras jones]

El tamaño sigue siendo difícil y ambiguo en el campo del software.

A partir de 2015 parece haber 23 métricas de tamaño comunes, con pocas reglas de conversión entre ellas.
Hasta donde yo sé, ninguna otra industria tiene tantas métricas por el mismo valor. El software también tiene 2,700 lenguajes de programación, también por razones desconocidas. Mi opinión es que todos estos lenguajes y métricas significan que ninguno es completamente satisfactorio o no tendríamos tantos.
A continuación se pegan las métricas que conozco.. Si alguien conoce a otros, hágamelo saber o publíquelo en este blog..

1. IFPUG 4.3
2. Basado en código automatizado
3. Basado en UML automatizado
4. Puntos de función contraproducentes
5. Puntos de función COSMIC
6. Puntos de función rápida
7. Puntos característicos
8. Puntos de función FiSMA
9. Puntos de función completa
10. Luz de puntos de función
11. Modelos IntegraNova
12. Puntos de función Mark II
13. Puntos de función de Nesma
14. Objetos de ARROZ
15. Puntos de función SCCQI
16. Puntos de función simple
17. Métricas no funcionales SNAP
18. Coincidencia de patrones SRM
19. Puntos de historia
20. Puntos de función no ajustados
21. Puntos de casos de uso
22. Declaraciones de código lógico
23. LOC físico (blanco, comentarios)

Gracias,
Alcaparras jones
Métricas de tamaño de SRM

[Ian Alyss]

Queridos alcaparras,

Buena lista! Bueno que distingas entre “Código automatizado”, “UML automatizado” y “Contrafuerte”, ya que son esencialmente diferentes. Hay varios gustos de “Rápido”, A cuál te refieres? Si no se refiere a los puntos de función rápida de Gartner, entonces deberías agregar FFPAi (que es la combinación de su FFPA tradicional, Puntos de configuración y puntos IBRA). Creo que los puntos de función completa ya no son válidos, ya que ha sido reemplazado por COSMIC. yo solo sé IntegraNova como entorno de desarrollo, pero no como medida de tamaño. En ese caso, también debe agregar Dimensionamiento de red ágil de OutSystems (AÑOS) y similares.

Saludos desde irlanda

[Frank Vogelezang]

Queridos alcaparras,

Definitivamente veo una mejora en la lista de una similar que publicaste en 2008. Ver mi blog personal “El precio de la TI” sobre eso. Solo mencionas Puntos de función de Nesma en una línea. Supongo que te refieres al Nesma ISO / IEC 24570 estándar para un recuento detallado de puntos de función. Pero, ¿se dio cuenta de que Nesma también tiene dos métodos para contar rápidamente?:

• Método indicativo de FPA para estimaciones ROM
• Recuento de alto nivel para un ayuno, pero sigue siendo un recuento muy preciso

Estos dos métodos, que también se describen en el estándar, son muy útiles cuando necesita una estimación de tamaño rápida. Ver esta página para una breve introducción.

Nesma también tiene una serie de métodos que están diseñados para entornos / propósitos específicos:

• FPA para mejora de software
• FPA aplicado al almacenamiento de datos
• Dimensionamiento funcional en un entorno basado en SOA (solo en holandés)

Tal vez pueda reservar algunas líneas adicionales para los métodos basados ​​en Nesma en la próxima versión de su lista.

Y, tal vez sea mi culpa que hayas incluido SCCQI, pero que yo sepa, solo hay una persona en el mundo que usa ese método.

Saludos, Franco

[Luigi Lavazza]

Queridos alcaparras,
su lista podría dividirse en dos listas: uno que contiene las diferentes medidas de tamaño, y el otro que contiene los procesos que se han propuesto para las medidas de la primera lista.
De echo, Los recuentos indicativos y de alto nivel mencionados por Frank no se propusieron para definir otra medida de tamaño., sino para simplificar el proceso de medición de métricas de tamaño ya existentes (a saber, puntos de función de nesma). Hay varias propuestas de este tipo, incluyendo temprano&puntos de función rápida, el método Tichenor, el método basado en las ponderaciones medias de ISBSG, etc. Personalmente, No las consideraría nuevas medidas., pero como nuevos procesos simplificados para lograr medidas de tamaño FPA más rápido y antes (p.ej., cuando las especificaciones funcionales del software a desarrollar aún no estén completamente disponibles, haciendo imposible la aplicación del proceso de medición estándar).
similar, Varias medidas basadas en UML son solo propuestas de procesos para derivar las medidas habituales. (IFPUG, CÓSMICO, etc.) a partir de especificaciones funcionales proporcionadas a través de diagramas UML.

Sobre la primera lista, posiblemente podrías agregar puntos de clase, aunque fueron propuestos por el investigador pero –por lo que sé– nunca aplicado en la práctica.

Saludos cordiales
Luigi

[Alcaparras jones]

Luigi,

Gracias por tus comentarios. Pido disculpas por la demora – Estoy de viaje y no tuve conexión debido a un viaje..

Tengo un método de tamaño pendiente de patente basado en la coincidencia de patrones. Se puede utilizar antes de los requisitos y solo se necesitan unos minutos para dimensionar cualquier aplicación.. Lo hemos utilizado para proyectos que van desde aproximadamente 1 punto de función a 300,000..

Comenzamos colocando el proyecto en nuestra taxonomía formal.. Luego seleccionamos proyectos con el mismo patrón de taxonomía de nuestra base de conocimiento de aproximadamente 25,000 proyectos. Da la casualidad de que los proyectos con el mismo patrón de taxonomía tienen aproximadamente el mismo tamaño en puntos de función pero no en líneas de código. Pero también podemos manejar líneas de código para 79 idiomas más combinaciones como Java y SQL.

El mismo método de coincidencia de patrones es utilizado por otras industrias como Zillow y Trulia para comparar bienes raíces y el Libro azul de Kelley para comparar los costos de los automóviles usados.

Nuestro método es una característica estándar de nuestro Maestro de riesgos de software (SRM) herramienta, que también predice el tamaño en 23 métricas al mismo tiempo. Proporcionamos calidad de tamaño y estimaciones de costos como un servicio para clientes en muchos países.: China, Canadá, Perú, Israel, Japón, etc.

No puedo agregar puntos de clase porque ninguno de mis clientes usa la métrica y no tengo datos.

Saludos,
Alcaparras jones

[Alcaparras jones]

Luigi,

Nuestro método de dimensionamiento se basa en una taxonomía formal.. También es una característica estándar de nuestro Software Risk Master. (SRM) herramienta de estimación.

Colocamos los proyectos para que se dimensionen en nuestra taxonomía patentada y luego extraemos proyectos similares de nuestra base de conocimientos y agregamos su tamaño. Da la casualidad de que los proyectos con los mismos patrones de taxonomía son de tamaños similares.

Nuestro método no requiere acceso a requisitos o información interna.

Como resultado, podemos dimensionar cualquier proyecto de software, y hazlo muy rápido.

Aquí están 150 muestras que reuní solo para ilustrar que cualquier proyecto de software se puede dimensionar utilizando nuestro método pendiente de patente.
>> 150 Ejemplos

Por supuesto, el tamaño por sí solo es solo una parte de lo que necesitan los clientes.. También se adjuntan resultados de proyectos de muestra utilizando poderes de 10 desde 10 a 100,000 puntos de función. Las muestras no son estimaciones completas de SRM, sino solo extractos interesantes.
>> Poderes de 10

Saludos,
Alcaparras jones

[Wim Visser]

Queridos alcaparras,

Estoy de acuerdo con Luigi en que su primera lista contiene varios elementos que no son métricas diferentes, sino las mismas métricas con solo diferentes procedimientos de conteo / medición.. Lamentablemente no respondes a los comentarios de Frank y Luigi. En mi opinión, su lista contiene menos de 23 métricas y estoy muy ansioso por conocer tu opinión sobre sus comentarios.

Atentamente

Wim Visser

[Marten Eisma]

Queridos alcaparras,

Veo que hay muchos métodos para (producto) dimensionamiento. Utilizo el tamaño del producto principalmente para estimar el propósito (nuevos proyectos y nuevos lanzamientos para fines de mantenimiento de aplicaciones). El tamaño estimado del producto se encuentra principalmente entre 300 FP y 5.000 FP con mucha incertidumbre.

La estimación del tamaño del producto se utiliza principalmente para estimaciones de esfuerzo. / tamaño del equipo), duración y defectos.

Las estimaciones del proyecto se basan principalmente en los requisitos comerciales., por lo que también el tamaño del producto también se estima como una probabilidad (con una gama).

Mi pregunta seria:
¿También hay un modelo? / método de evaluación para seleccionar el método más relevante para el dimensionamiento del producto al inicio de un proyecto / lanzamiento, sabiendo que una precisión de +/- 10% es aceptable.

Marten Eisma

[Autor]

Publicaciones