Boglioli, Alan
Brest, Federico
Casas, Malena
Diaz, Pablo
Martinez, Matías
Noli, Hernán
Aplicación
Desarrollo Ágil (el equipo trabaja en conjunto y cara a cara con el cliente), Desarrollo orientado a objeto, UML, Modelo de CU, Diagrama de Estados, Diagrama de Actividades.
Ejecutores
El equipo de trabajo (analista, desarrollador, personal de calidad) Clientes.
Herramientas
Rational Requirements Composer, Rational Requirement Pro, Rational Requirement Doors.
Se puede realizar una medición basada en :
Falta de una definición de código universal (no es lo mismo una línea en JAVA que en C++)
Prototipos desechables: Son creados para demostrar las características de un proyecto de software (probar interfaces, facilidad de uso, algoritmos claves o secuencias de procesamiento complejas). Cuando cumplen su fin son descartados.
Se realizan rápidamente, sin especificaciones formales, se usan con los requerimientos que no se conocen bien y son de corta duración
Aplicaciones
Prototipos de cuadro de tiempo: Son a menudo réplicas parciales de aplicaciones completas y tienen por objetivo mostrar cómo interactúan los aspectos funcionales. Suelen ser desechables, construidos durante un tiempo específico.
El tamaño medio de prototipos cuadro de tiempo es de aproximadamente 15 a 25 por ciento de los rasgos eventuales.
Aplicaciones
Prototipos evolutivos: Es un intento por construir un producto completo mediante la elaboración de una serie de versiones parciales sucesivas y completas gracias a requerimientos más detallados.
Aplicaciones
Ejecutores
Analista (para complementar los requerimientos existentes) y desarrolladores involucrados en el proyecto.
Herramientas
Visual Basic y Realizador, o incluso herramientas de creación de prototipos especiales, como la herramienta de demostración Bricklin, es bastante común.
Impacto
VENTAJAS:
DESVENTAJAS:
Mediciones
Cantidad de PF necesarios para el sistema
Lenguaje utilizado
Horas de trabajo por persona
Cantidad de personas por grupo
Son una respuesta técnica a las necesidades de los usuarios, y sirven para describir la forma en que las necesidades de los usuarios se tratarán de forma automatizada mediante la aplicación de software que se está construyendo.
Aplicación
Existen muchos métodos de diseño implementados para Software de sistema, en nuestra carrera se ve mucho el Lenguaje Unificado de Modelado (UML)
Ejecutores
Principalmente, Analistas y Diseñadores en Sistemas.
Herramientas
Enterprise Architect y Rational Enterprise.
Genera distintas ventajas como:
Mediciones:
Se refiere a un procedimiento formal en el que un grupo de profesionales capacitados examinan un artefacto de software, como una especificación, página por página en una forma planificada.
Ejecutores
Se forma un grupo de inspección donde se designa:
Un moderador
Autor de los productos de trabajo
Un registrador, encargado de registrar los hallazgos
Un lector, que tiene a cargo la paráfrasis de cada sección
Revisores, que realizan la inspección.
Un coordinador, el cual programa las inspecciones y reserva lugar físico.
Herramientas
Mente humana
Impacto
Ha demostrado beneficio en los costos totales del proyecto y en acortar los plazos del mismo, disminuyendo esfuerzos en etapas de prueba, previniendo errores de codificación. Reduce
mucho el costo de los pasos siguientes en las fases de desarrollo y mantenimiento.
Preparación
Sesiones de inspección
Para cuantificar una inspección volvemos a utilizar métricas como:
Errores por PF
Las inspecciones de estimación utilizan a menudo métricas naturales, como páginas.
Mediciones:
La estimación de la programación es esencial por el tiempo que demanda crear una aplicación completa y funcional, tardando en general más de lo planeado.
Aplicación
Se puede aplicar a muchos sectores de la sociedad actualmente, y sigue creciendo de manera muy acelerada. Generalmente se desea utilizar para agilizar y automatizar muchos de los procesos básicos en la producción.
Ejecutores
Desarrolladores, Programadores encargados del proyecto.
Herramientas
Impacto
Ventajas:
Desventajas:
Tiempo extra no remunerador, si se encuentran fallas y el SF debe ser corregido y probado nuevamente, es tiempo perdido del programador.
El aumento de requisitos del proyecto puede llevar a que incorporar nuevas funcionalidades produzca que muchas partes del software deban ser modificados, tanto sencillas como profundas, provocando retrasos en el proyecto tanto en costo como en tiempo de entrega.
Estructura y complejidad del código, es decir, si la documentación del software no existe o es muy pobre, complica mucho la comprensión y/o modificación del software dado que primero se debe realizar un examen profundo para comprender realmente como está estructurado el software.
Mediciones:
Debido a que el software puede ser evaluado desde muchos aspectos (las aplicaciones suelen ser cada vez más grandes y complejas), se hace difícil establecer ciertos aspectos básicos que se apliquen a todos los software en general.
Los proyectos de software cambian rápidamente, por lo tanto una de los retos principales es gestionar el cambio tan eficientemente como sea posible.
Estimar la labor de gestión del cambio es importante, no sólo porque la gestión del cambio en sí mismo puede ser costoso, sino porque la tasa de variación de los entregables de software es un factor importante en la precisión de coste global de software y estimación horario.
Los cambios debido a los errores o informes de defectos.
Métrica de punto de función
Mediciones:
Consiste en estimar muestras de defectos de muy variada índole y/o muchos proyectos realizados con anterioridad para luego analizar las revisiones e inspecciones de los proyectos que actualmente están en desarrollo para que permita evaluar la eficiencia de eliminación de los defectos (evaluando para cada tarea de eliminación el esfuerzo, costo de preparación, ejecución y reparación) en cada una de las etapas del proceso de prueba de software.
Las pruebas de software se pueden realizar de diferentes formas
Pruebas Funcionales: Eliminar errores comunes, errores de condicionales, de loops, resultados incorrectos, etc.
Pruebas de subrutina
Pruebas de unidades
Pruebas de nuevas funciones, regresión, integración.
Pruebas de Usuario: Se destina a problemas de facilidad de uso y familiaridad con el sistema.
Pruebas de aceptación del cliente.
Pruebas de campo
Pruebas de facilidad de uso e interfaz gráfica
Pruebas Detalladas: Buscan tipos de errores específicos
Pruebas de protección contra virus
Pruebas de rendimiento, seguridad, plataforma, entre otros.
Ejecutores
Testers, Programadores, Clientes
Herramientas
Check Point Software Technologies Ltd y COCOMO (Modelo Constructivo de Costos).
Impacto:
Los factores principales que afectan a las estimaciones de prueba de software son:
El numero de errores/defectos/fallas en el software testeado.
La cantidad de fases que tenga establecida el proceso de pruebas de Software.
La estructura de la aplicación.
Los clientes finales
Tipo de software requerido, es decir, a que sector de la sociedad apunta
El tamaño del software
Los resultados obtenidos varían en función de los elementos que tomemos para realizar la prueba
Mediciones:
La documentación de software en todas sus manifestaciones es un elemento clave del coste del software. Casi todos los proyectos de software requieren documentación, pero muy pocos se documentan muy bien.
Se aplica para cualquier proyecto de software, en especial proyectos desarrollados a medida.
La realizará quien se encuentre en un rango alto designado a la gestión de proyectos junto a algún especialista en estimación de costos.
Impacto:
El control de configuración de herramientas no siempre apoyan los documentos importantes y, a menudo se concentran en el código fuente y no en las especificaciones y documentos de los usuarios.
Los costes y las horas para la creación de los documentos son mayores que el costo de escribir realmente el código fuente.
Herramientas:
Desde el punto de vista de la estimación, pocas herramientas comerciales de estimación de software incluye capacidades de predicción para los documentos en papel de software como SPQR/20 (1985), CHECKPOINT (1989), y KnowledgePlan (1997).
Otras herramientas de estimación, como COCOMO, COCOMO II, SLIM y similares, también han añadido soporte para la estimación de algunas formas de documentación de software, tales como conjuntos de especificación, pero no admitan manuales de usuario, material de capacitación, o algunas formas de documentos de planificación.
La mayoría se basan en puntos de función.
Ejemplo: podría ser la relación entre el número de documentos generados y el número de documentos que tuvieron que ser modificados por no cumplir con los estándares de calidad.
Dependiendo de la forma en la que estén hechos dichos documentos se gastará más o menos tiempo en modificarlos, reutilizar código o módulos en futuros desarrollo
Mediciones:
La función de gestión del proyecto contribuirá entre un 10 y un 20 por ciento el costo de los proyectos de software. Los gerentes de proyecto también ejercen una fuerte influencia sobre los horarios, la calidad y la moral del equipo.
La estimación del trabajo de los directores de proyectos de software es muy compleja, y es apoyada por muy poco en la forma de sólidos datos empíricos. De hecho, incluso las funciones y responsabilidades de los jefes de proyecto pueden variar de una compañía a otra, y de un proyecto a otro dentro de la misma empresa.
Aplicación
Aplicable a cualquier tipo de proyecto de software la cual requiere una experiencia que va más allá de las habilidades normales de gestión.
Ejecutores
La realizará quien se encuentre en un rango alto designado a la gestión de proyectos.
La gestión del proyecto utiliza herramientas que pueden producir los diagramas de Gantt y diagramas PERT, realizar análisis de la ruta crítica, y manejar la mecánica de la programación y la acumulación de costos.
Sin embargo, hay una serie de herramientas de software especializado de gestión de proyectos que están dirigidos específicamente a los proyectos de software como Microsoft Project, Timeline, Primavera, Artemisa, y similares.
Para los grandes proyectos de software, los fallos y desastres están más estrechamente correlacionados con la gestión deficiente de los proyectos. De hecho, la gestión deficiente de los proyectos puede hacer que en trabajos técnicos pobres escatimar en las inspecciones y actividades de control de calidad resulte la creación de coste excesivamente optimista.
Mediciones:
Es necesario separar las tareas de gestión de las tareas técnicas.
Mediciones:
En el supuesto de que el sistema es lo suficientemente grande como para tener diez directores de proyectos comprometidos, alrededor del 30 por ciento de tiempo mensual de gestión del proyecto se dedicará a reuniones con otros gerentes. Estas reuniones de coordinación pueden absorber más del 38 por ciento del esfuerzo de gestión, debido a que estos sistemas grandes suelen tener múltiples capas de gestión para que las reuniones de planificación.
En el mundo de hoy en día más del 50 por ciento de la población mundial de software se dedica a modificar las aplicaciones existentes en lugar de escribir nuevas aplicaciones. Esto implica que el mantenimiento y mejora de estimación es realmente el aspecto más crítico de software de estimación de costes.
Se aplica a todo tipo de proyectos a los cuales se quiera agregar o cambiar funciones en SW existentes en respuesta a solicitudes de usuarios explícitos.
La realizará quien se encuentre en un rango alto designado para estimar costos junto con algún experto en mantenimiento capacitado.
Una dificultad es el hecho de que las tareas de mantenimiento son a menudo asignados a personal de desarrollo quienes van intercalando tareas de desarrollo y mantenimiento según sea necesario. Esta práctica hace que sea difícil distinguir los costes de mantenimiento de los costes de desarrollo ya que los programadores son a menudo bastante descuidado en el registro del tiempo.
Mediciones:
Ámbitos de asignación,
Tasas de producción (tipos P) en términos de puntos de función (PF) por mes del personal
Horas por punto de función.
También se incluyen las líneas de código (LOC) mensuales al personal