Estimaciones de software

ESTIMACIONES DE SOFTWARE Rogelio Francisco Ramírez Ramírez [Email address] Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Contenido 1. Introducción ......................................................................................................................................................................... 2 2. Fundamentos ....................................................................................................................................................................... 3 2.1 Conceptos clave .............................................................................................................................................................. 3 2.2 Porque las palabras importan .......................................................................................................................................... 3 2.3 La crisis del software........................................................................................................................................................ 6 2.4 El software como negocio ................................................................................................................................................ 9 2.5 Bibliografía recomendada .............................................................................................................................................. 15 3. Estimaciones de software................................................................................................................................................. 16 3.1 Introducción ................................................................................................................................................................... 16 3.2 El tamaño del software................................................................................................................................................... 29 3.3 Clasificación de las estimaciones .................................................................................................................................. 32 3.4 Técnica de juicio de experto .......................................................................................................................................... 35 3.5 Técnica Delphi ............................................................................................................................................................... 36 3.6 Método de contar, calcular, juzgar ................................................................................................................................. 37 3.7 Método de análisis de puntos de función ....................................................................................................................... 38 3.8 Uso de información histórica para mejorar las estimaciones ......................................................................................... 47 4. Glosario .............................................................................................................................................................................. 52 5. Referencias ........................................................................................................................................................................ 58 1 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 1. Introducción En el entorno mexicano actual, el desarrollo de software se ha vuelto un motor importante para el crecimiento de la economía del país (Villalobos Hernández & Gutiérrez Tornés, 2001), (Secretaría de economía, 2012). El número de empresas que desarrollan software creció en un 54% del 2002 al 2011 (Secretaría de economía, 2012) y hoy México ocupa ya el cuarto lugar de importancia en desarrollo de software en el mundo (IVEX, 2007), (Secretaría de economía, 2012). Sin embargo, y a pesar de este crecimiento, la industria del software en el país aún se encuentra en una etapa de poca madurez y en desarrollo (IVEX, 2007). Aun cuando en nuestro país ya existen más de trescientas empresas que cuentan con una o más certificaciones en algún modelo de procesos (Secretaría de economía, 2012) la realidad es que en el día a día muchos de los proyectos de software fracasan (The Standish Group, 1995) o las empresas tienen que invertir grandes sumas económicas (The Standish Group, 1995) para mantener aplicaciones que no cumplen con los estándares de calidad necesarios. De acuerdo a un estudio realizado por la ANIEI-ILCE1 con el apoyo de la Secretaría de Economía, para determinar la cantidad y calidad de recursos humanos necesarios para el desarrollo de la industria del software en México (Secretaría de economía, 2012), se detectaron 2 problemáticas fundamentales:   La disparidad que existe entre los conocimientos adquiridos en las instituciones educativas y las competencias demandadas por la industria. El costoso y extenso período de transición adaptativa, esto es, el tiempo entre el egreso de las instituciones educativas y el momento en que son productivos. Por lo anterior, este curso fue diseñado con el objetivo de incrementar las habilidades profesionales de las personas que participan en los procesos de software, a través de la aplicación de la ingeniería. Si el objetivo anterior se cumple, se espera que la madurez de los procesos de software incremente en las empresas para que así, puedan tener mayor eficiencia, empleados y clientes más satisfechos, para que por consecuencia obtengan mayores ingresos. En la mayoría de las economías, cerca de una tercera parte del crecimiento del PIB real es atribuible a mejoras en la eficiencia con la que se utilizan los insumos o factores de la producción (Secretaría de economía, 2012). El presente trabajo representa una combinación de lecciones aprendidas y mejores prácticas ya implementadas y mejoradas por equipos de desarrollo de software en México, además de información recopilada de diversas fuentes de información respetadas y reconocidas en la industria del software en el mundo. 1 Asociación Nacional de Instituciones de Educación en Tecnologías de la Información, A.C. y el Instituto Latinoamericano de la Comunicación Educativa 2 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 2. Fundamentos Tal como se mostrará más delante en este mismo documento, es importante comprender y distinguir los siguientes: 2.1 Conceptos clave 2.1.1 Software Es el conjunto de programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación de un sistema computacional. (IEEE, 1990) 2.1.2 Programa de computadora Una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control. (IEEE, 1990) 2.1.3 Proyecto Es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos. (PMI, 2008) 2.1.4 Proceso Un conjunto definido de actividades o comportamientos llevados a cabo por humanos o máquinas para alcanzar uno o más objetivos. (ABPMP, 2009) Para mayor información acerca de estos conceptos ver el Glosario. 2.2 Porque las palabras importan En nuestra industria es muy común que se empleen términos o conceptos, que tienen significados diferentes, de forma indistinta, como si significaran lo mismo. Aparentemente podría no haber mayor problema con esto, pero conforme una empresa madura sus procesos de software el lenguaje técnico y el significado de las palabras se vuelven relevantes para mejorar la comunicación y, por lo tanto la efectividad y la eficiencia en la organización y sus proyectos. 2.2.1 Diferencia entre sistema, software, aplicación y programa Uno de los elementos que más comúnmente es llamado de diferentes formas, aunque los nombres con los que se le llama signifiquen cosas diferentes, es el software mismo. Para comprender las diferencias hay que comprender los significados de cada palabra, de ahí entonces que es importante comprender primero que: 3 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.   Un sistema es un conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto (RAE, 2012), es decir, muchas cosas pueden ser un sistema, entre ellas el software, pero no es lo único. Luego entonces, se puede decir que un sistema computacional es un sistema que contiene una o más computadoras y software asociado (IEEE, 1990), es decir, un sistema computacional no solamente está conformado por un  programa computacional. De lo anterior entonces es importante comprender que un programa computacional no necesariamente es igual a un programa, es decir, un programa puede significar varias cosas (RAE, 2012), la mayoría de ellas no relacionadas con la computación. Por otro lado, un programa computacional es una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control   (IEEE, 1990). Por otro lado, el software es un conjunto, que está conformado por programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación de un sistema computacional (IEEE, 1990). Y finalmente, pero no por eso menos importante, una aplicación o software de aplicación es un software diseñado para cumplir con necesidades específicas de un usuario, por ejemplo, software de nómina, recursos humanos o ventas (IEEE, 1990). 2.2.2 Diferencia entre programa computacional y proyecto Otra de las confusiones más comunes es la que se da cuando a un programa computacional se le llama proyecto. Aunque es muy común que en otros ámbitos se emplee la palabra proyecto como sinónimo del producto, servicio o resultado que se está generando, se considera que en la industria del software se vuelve relevante hacer la distinción para que el concepto de la administración de proyectos se adopte más rápido y de forma más efectiva y eficiente. De lo anterior entonces se puede decir que:  Un proyecto es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos (PMI, 2008), es decir, el proyecto, para el ámbito de este documento, es el conjunto de actividades que se realizan para crear un  programa computacional. Como ya se explicó antes, un programa computacional es una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control (IEEE, 1990). 2.2.3 Diferencia entre error, defecto y falla Cuando se comienzan a medir los resultados obtenidos en procesos relacionados con la calidad del software se vuelve relevante poder comprender la diferencia entre error, defecto y falla. De ahí que es importante que se comprenda que:  Un error es una acción desacertada o equivocada (RAE, 2012) o una acción humana que produce un resultado incorrecto (IEEE, 1990). Cuando un humano participa en el desarrollo de un producto y comete un error, puede insertar un defecto en el producto. 4 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.  Por lo tanto, se puede decir que un defecto es una imperfección o deficiencia en un componente de un proyecto en la cual dicho componente no cumple sus requerimientos o especificaciones y necesita ser corregido o reemplazado  (PMI, 2008). Finalmente, una falla es la acción y el efecto de que algo salga fallido, por ejemplo, el programa computacional. En resumen se puede decir que, el humano (programador(a) de software) puede insertar defectos en el programa computacional cuando comete errores. Posteriormente y debido a uno varios defectos, el programa computacional puede fallar. 2.2.4 Diferencia entre costo y precio Durante la administración de un proyecto es importante controlar los costos y, dependiendo de la organización que esté ejecutando el proyecto, podría estar manejándose el precio en lugar del costo, de ahí la importancia de distinguirlos. Por lo tanto:  El costo es la cantidad que se da o se paga por algo (RAE, 2012), es decir, desde el punto de vista del que compra o crea un proyecto o producto de forma interna, el costo es la cantidad pagada o invertida por dicho proyecto o producto, aunque desde el punto de vista de quien vende, el costo representa lo que le cuesta ejecutar el proyecto  aunque después le agregue una utilidad y el total se convierta en el precio. Visto de otra forma, desde el punto de vista de quien vende un proyecto o producto y lo ofrece como un servicio a un cliente, el precio representa lo que le cuesta ejecutar el proyecto más la ganancia que desea obtener por la venta de dicho servicio (proyecto o producto). En este caso, desde el punto de vista de quien compra, lo que le cuesta el proyecto representa un costo, como ya se mencionó anteriormente. En resumen, el precio es la suma del costo más la utilidad. El costo puede descomponerse en varias cosas, sin embargo, esa descomposición está fuera del alcance de este documento. En la administración de un proyecto debe controlarse el costo, no el precio, ya que si se controla el precio se corre el riesgo de tomar la utilidad como parte de la inversión disponible dentro del proyecto. 2.2.5 Diferencia entre duración y esfuerzo Es muy común que en los proyectos se mida el esfuerzo en función del tiempo, por ejemplo, en horas, días o semanas. Lo anterior puede provocar una confusión cuando existe comunicación relacionada con esfuerzo y duración, de tal forma que durante una conversación o mensaje, una de las partes puede estar expresando algún valor en función del esfuerzo y la otra parte podría interpretar dicho valor en función de la duración, por ejemplo: Juan le dice a María que realizar la actividad A le tomará 16 horas y María podría interpretar que Juan realizará dicha actividad en 2 días, puesto que calcula 8 horas laborales por día, sin embargo, quizá Juan contemplaba dedicar 4 horas diarias a dicha actividad, por lo que la duración en realidad sería de 4 días y no 2, como lo pensó María. Si no existe la comunicación adecuada entre Juan y María, podría haber una confusión importante posteriormente. La confusión anterior es muy común y de ahí que sea importante distinguir la diferencia entre ambos conceptos. Por lo tanto: 5 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.  El esfuerzo es el número de unidades de trabajo requeridas para completar una actividad programada o un componente de una estructura de desglose de trabajo. Usualmente expresado como horas/hombre, días/hombre o semanas/hombre (PMI, 2008). El esfuerzo es igual a la duración de una actividad multiplicada por el número de  personas que participan en ella. La duración es el número total de periodos de trabajo (sin incluir días festivos u otros periodos no laborables) requerido para completar una actividad programada o un componente de una estructura de desglose de trabajo. Usualmente expresada como días o semanas laborables (PMI, 2008). 2.3 La crisis del software 2.3.1 Hacer software no es lo mismo que programar Es muy común que quienes se gradúan de alguna carrera relacionada con las tecnologías de información y que eligen el camino del software comiencen programando. También es muy común que quienes inician nuevas empresas de software sean los mismos ingenieros o licenciados surgidos de las carreras de tecnologías de información y que alguna vez iniciaron programando. Lo anterior ha provocado que muchas empresas de software enfoquen sus esfuerzos a la programación del mismo, probablemente y, porque lo consideran necesario, también dediquen tiempo a la recopilación de los requerimientos del software que van a desarrollar o mantener. Es muy probable que muchas de esas empresas comiencen con ninguna o pocas prácticas de administración de proyectos, de arquitectura y diseño, de pruebas y qué pensar de prácticas de aseguramiento de la calidad. Por lo mencionado anteriormente es importante comprender que hacer software no es lo mismo que programar, es decir, hacer software implica llevar a cabo, preferentemente de una forma estandarizada, actividades de estimaciones, recopilación de requerimientos, arquitectura y diseño de software, pruebas de software, revisiones del código y la documentación generada, administración de la configuración del software, administración de proyectos, medición del desempeño, aseguramiento de la calidad entre otras, ah y por cierto, también de programación. 2.3.2 Reporte del caos En el año de 1986 Fred Brooks publicó un ensayo titulado “No Silver Bullet — Essence and Accidents of Software Engineering” en el cual argumentaba que: “no existe un solo desarrollo, en cualquier tecnología o técnica de administración, que por sí misma prometa una mejora en al menos un orden de magnitud dentro de una década en productividad, confiabilidad o simplicidad”. Y pareciera que Brooks tenía razón, pero su predicción pareciera aplicar no solamente para la siguiente década después de que publicó su ensayo, sino que aparentemente sigue siendo válida hasta nuestros días. En 1985 fue formado The Standish Group, con la visión de recolectar información de casos de la vida real de fallas y ambientes de tecnologías de información. En 1995 este grupo publicó el reporte del caos en el cual, entre otros hallazgos, encontraron que:  El 31% de los proyectos sería cancelado antes de ser terminado. (The Standish Group, 1995) 6 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.    El 52.7% de los proyectos costarían 189% más que en sus estimaciones originales. (The Standish Group, 1995) La falla para producir software confiable para manejar las maletas en el aeropuerto de Denver le estaba costando a la ciudad $1.1 millones de dólares por día. (The Standish Group, 1995) Las compañías estadounidenses y las agencias de gobierno gastarían $81 billones de dólares por proyectos de software cancelados. Estas mismas compañías pagarían $59 billones de dólares adicionales por proyectos de  software que serán terminados pero excederán sus estimaciones originales de duración. (The Standish Group, 1995) El promedio de proyectos de software que fueron terminados a tiempo y dentro de su presupuesto fue de 16.2%, sin embargo, en compañías grandes el número de proyectos terminados a tiempo y dentro de su presupuesto  representaba solamente el 9% del total. (The Standish Group, 1995) Los proyectos terminados por grandes compañías estadounidenses contenían solamente el 42% de las funciones y características que fueron propuestas originalmente. Sin embargo, en compañías pequeñas este porcentaje era diferente, un total de 78.4% de sus proyectos de software fueron entregados con al menos el 74.2% de sus funciones y características originales. (The Standish Group, 1995) En años recientes, el reporte del caos muestra que la ejecución de proyectos ha mejorado, pero no por mucho: Tabla 1 Indicadores de proyectos de software de acuerdo al reporte del caos del Standish Group. Proyectos 1994 1996 1998 2000 2002 2004 2006 2009 Exitosos 16% 27% 26% 28% 34% 29% 35% 32% Desafiados 53% 33% 46% 49% 51% 53% 46% 44% Fallidos 31% 40% 28% 23% 15% 18% 19% 24% Fuente: (Domínguez, 2012) Exitosos: terminaron a tiempo, dentro del presupuesto planeado y cumplieron los requerimientos de sus usuarios. Desafiados: excedieron sus presupuestos, su duración planeada o no cumplieron completamente con las necesidades de sus usuarios. Fallidos: fueron cancelados y no terminaron. Jim Johnson, presidente del Standish Group mencionó en el 2007 (Rubinstein, 2007) que la mejoría con respecto a años anteriores principalmente se debió a:    Mejor administración de proyectos Desarrollo iterativo Emergente infraestructura Web 7 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 2.3.3 Casos de estudio 2.3.3.1 Software de manejo de equipaje del aeropuerto de Denver Originalmente facturado como el sistema más avanzado del mundo, el sistema de manejo de equipaje del nuevo aeropuerto internacional de Denver se convirtió en uno de los más notorios ejemplos de proyectos fallidos. Originalmente fue planeado para automatizar el manejo de equipaje a través del aeropuerto entero, el sistema probó ser más complejo que lo que algunos creyeron originalmente. Los problemas para construir el sistema resultaron en una espera en la apertura del nuevo aeropuerto de 16 meses mientras los ingenieros trabajaban para hacer que el sistema funcionara. El retraso agregó aproximadamente $560 millones de dólares al costo del aeropuerto. Al final del día, el sistema que fue finalmente implementado fue una sombra de lo que estaba originalmente planeado. En lugar de integrar las tres salas en un sólo sistema, el sistema soportaba vuelos de salida solamente en una de las salas. Todo el equipaje adicional era manejado por un remolcador manual y un sistema de carretillas que fue construido a la carrera cuando se hizo claro que el sistema automatizado nunca cumpliría sus metas. Inclusive la porción del sistema que fue implementada nunca funcionó apropiadamente y en agosto de 2005 el sistema fue desechado por completo. El costo de un millón de dólares mensuales empleados para mantener el sistema fue contrarrestando el valor que ofrecían las partes restantes del sistema además de que el uso de un sistema manual realmente ayudó a reducir costos. Los factores reportados a la prensa y que contribuyeron al fracaso fueron: subestimación de la complejidad, una arquitectura compleja, cambios en los requerimientos, subestimación de la duración y el presupuesto, despido del consejo de expertos, entre otros. (Calleam Consulting Ltd, 2012) 2.3.3.2 El colapso de la red de AT&T En 1990, 75 millones de llamadas de teléfono en todo Estados Unidos no fueron respondidas después de que un simple switch en uno de los 114 centros de AT&T sufrió un problema mecánico menor, el cuál apagó todo el centro. Cuando el centro volvió a funcionar, envió un mensaje a otros centros, lo cual provocó que se apagaran y resetearan. El culpable resultó ser un error en una sola línea de código, nada de hackers como se especuló en aquel entonces, que había sido agregada durante una actualización altamente compleja del software. American Airlines estimó que este pequeño error le costó $200,000 dólares en reservaciones. (Barker, 2007) 8 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 2.3.3.3 La explosión de Ariane 5 En 1996, el cohete de lanzamiento de satélites más nuevo y no tripulado, el Ariane 5, fue intencionalmente explotado apenas algunos segundos después de haber despegado en su vuelo inaugural en Kouru, en la Guyana francesa. La agencia espacial europea estimó que el desarrollo total de Ariane 5 costó más de 8 billones de dólares. A bordo había cuatro satélites científicos con un costo de $500 millones de dólares creados para estudiar cómo el campo magnético de la tierra interactúa con los vientos solares. De acuerdo a una pieza en la revista New York Times, la autodestrucción fue disparada por el software que intentaba llenar un espacio de 16 bits con un número de 64 bits. "Este apagón ocurrió 36.7 segundos después del lanzamiento, cuando la computadora del sistema de navegación intentó convertir un dato, el de la velocidad lateral del cohete, de un formato de 64 bits a un formato de 16 bits. El número era demasiado grande y resultó en un error de sobre flujo (overflow). Cuando el sistema de navegación se apagó, pasó el control a una unidad idéntica, redundante, la cual estaba ahí para proveer respaldo en caso de que hubiera alguna falla. Pero la segunda unidad había fallado de forma idéntica unos milisegundos antes. ¿Y por qué no? estaba ejecutando el mismo software." mencionó el artículo. (Barker, 2007) 2.4 El software como negocio 2.4.1 Programar vs hacer dinero Uno de los principales conflictos que existen en la industria del software es el que tiene que ver con la visión que tiene un programador de software promedio y la que tiene un empresario, de software o de cualquier industria que emplee software. Es muy común que una persona que recién egresa de una carrera relacionada con el software decida comenzar su carrera profesional programando software y que inicialmente busque crecimiento profesional adquiriendo la mayor cantidad de conocimiento técnico posible, por otro lado, el empresario promedio enfocará sus esfuerzos en la obtención de mayores ingresos económicos. Aunque estas dos visiones no necesariamente son mutuamente excluyentes, al final de cuentas si representan visiones diferentes que si no son alineadas pueden provocar insatisfacción a ambas partes. Para explicar de una manera más detallada lo anterior se presentan algunos de los intereses comunes de cada parte. Es importante aclarar que las siguientes listas no son estáticas y los intereses mostrados no son los únicos que existen e inclusive es probable que ni siquiera representen los intereses más importantes de cada una de las partes: Intereses de un programador de software:     Adquisición de nuevo conocimiento técnico. Mayores ingresos económicos. Reconocimiento por su trabajo. Flexibilidad y libertad laboral. 9 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. o Entiéndase flexibilidad y libertad como la posibilidad de tener un horario flexible de trabajo, respeto por sus estimaciones, comprensión de sus jefes del hecho de que como humanos no pueden estar sentados ocho horas diarias programando y como la posibilidad de realizar otras actividades de esparcimiento en horas   laborales, entre otras. Trabajar en proyectos con nueva tecnología. Otros. Intereses de un empresario:         Incrementar ingresos. Reducir costos. Reducir riesgos de negocio. Satisfacer a clientes. Satisfacer a empleados. Mejorar procesos (optimizarlos). Mayor efectividad y eficiencia del negocio. Otros. Como puede observarse, algunos de estos intereses pueden estar en conflicto, por ejemplo, mientras un programador de software busca mayor flexibilidad y libertad en el trabajo, el empresario está ocupado por obtener mayor eficiencia, que implica entre otras cosas, la posibilidad de optimizar al máximo los recursos disponibles, entre ellos las horas productivas de un programador de software. Otro ejemplo es el que tiene que ver con el hecho de que los programadores buscan trabajar en proyectos que involucren nueva tecnología, sin embargo, hacer esto incrementa los riesgos del negocio desde el momento que la nueva tecnología puede no tener la madurez necesaria para ser empleada en nuevas aplicaciones de software. En resumen y para finalizar esta sección, en la medida que los programadores de software comprendan que los programas computacionales que generan tienen un impacto económico (positivo o negativo) importante en las empresas que los utilizan y en la medida que el empresario que desarrolla o emplea software comprenda que el software es hecho por personas y no por máquinas, la madurez de la industria del software incrementará y podrán tenerse programadores y empresarios más satisfechos. 2.4.2 Desperdicio relacionado al software En la industria de la manufactura es muy común escuchar de la implementación de prácticas de mejora continua, tales como la administración de la calidad total, y esfuerzos de optimización de la producción asociados a conceptos como la manufactura esbelta, reducción de defectos, administración de la capacidad de la producción entre otros. Muchos de estos conceptos o filosofías han sido adoptados y adaptados de empresas japonesas de manufactura. Aunque como ya se mencionó, dichas prácticas o filosofías han sido adoptadas ampliamente en empresas de manufactura, no es muy común que dichas prácticas sean empleadas en empresas de servicios o productos de software. Efectivamente dichas prácticas pueden ser adoptadas a empresas de servicios y específicamente empresas de software, un ejemplo de ello 10 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. es la emergente disciplina conocida como Lean IT, en la que el principal objetivo es la eliminación del desperdicio, desperdicio entendido como el trabajo que no agrega valor a un producto o servicio (Wikipedia, 2012). Lean IT promete identificar y erradicar el desperdicio que contribuye a un pobre servicio al cliente, pérdida de negocio, costos de negocio más altos de lo necesario y pérdida de productividad de los empleados. Para estos fines, Lean IT se enfoca en ocho elementos de la operación de TI que no agregan valor al producto, servicio terminado o a la organización que los genera: Tabla 2 Objetivos de desperdicio en Lean IT Desperdicio Ejemplo En qué se traduce en el negocio Defectos No cumplimiento de un requerimiento Insatisfacción del cliente Cálculo mal realizado por un programa computacional Costos adicionales de corrección Sobreproducción (sobre Generación de características (funciones) adicionales Incremento en los costos de producción aprovisionamiento) no solicitadas por el cliente. Espera Tiempo que un equipo de desarrollo de software debe Costos no planeados (asociados al esperar para instalar una aplicación cuando el servidor tiempo de espera, tiempo no (hardware) requerido para hacerlo no está disponible. productivo) No aprovechamiento de los recursos en otros proyectos en los que pueden ser productivos. Procesamiento que no Recopilación manual de información para obtención de Incremento de costos para la agrega valor indicadores de desempeño de un proyecto organización No aprovechamiento de los recursos en otras actividades que generen valor. Transportación Tiempo de traslado empleado para visitar las oficinas No aprovechamiento de recursos en de un cliente para recopilar requerimientos. actividades que generen valor Posible incremento de costos (por gastos de transportación) Inventario Programadores de software que no están asignados a Costos devengados por la empresa algún proyecto productivo. mientras no exista un cliente que pague, a través de un proyecto, por las horas disponibles de dichos programadores. Movimiento Asistencia a reuniones para llegar a acuerdos. Pérdida de productividad 11 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Desplazamientos necesarios (para ir al baño, para fumar, para conversar, etc.) para el esparcimiento durante horas laborales. Conocimiento no No existencia de una base de conocimiento Baja satisfacción con el trabajo empleado Procesos no documentados Incremento en los costos de Comisión de los mismos errores de forma recurrente mantenimiento y soporte Fuente: (Wikipedia, 2012) 2.4.3 Costo y precio Para empresas que ofrecen servicios relacionados con productos de software y que lo hacen a través de la ejecución de proyectos es muy importante distinguir la diferencia entre costo y precio al momento de planear, monitorear y controlar sus proyectos. Quizá lo anterior no sea tan relevante para empresas cuyos proyectos de software se ejecutan de manera interna, es decir, no venden servicios relacionados con la ejecución de dichos proyectos.  El costo es la cantidad que se da o se paga por algo (RAE, 2012). La definición anterior se establece desde el punto de vista de quien compra, pero desde el punto de vista de quien vende se puede decir que el costo es lo que cuesta  ejecutar un proyecto. El precio representa lo que cuesta (el costo) ejecutar un proyecto más la ganancia que desea obtener por la venta de dicho proyecto. Al igual que la premisa que se emplea en México para el IVA (Impuesto al valor agregado) cuando se dice que el IVA solamente se traslada y no le pertenece a quien lo cobra, podría pensarse del precio, es decir, la utilidad no le pertenece a un proyecto, por lo tanto, cuando un proyecto que fue vendido se planea, monitorea y controla, solamente debe considerar el costo como su presupuesto y no el precio, ya que este último incluye la utilidad. Para mayor información de las diferencias entre el precio y el costo ver la sección Diferencia entre costo y precio en este mismo documento. 2.4.4 Reducción de costos mediante la prevención El siguiente texto fue tomado del libro Software Project Survival Guide. (McConnell, Software Project Survival Guide, 1998) “Upstream, Downstream Los buenos procesos de software están diseñados para resolver problemas de forma temprana en un proyecto. Este concepto es lo suficientemente importante para discutirlo con algo de detalle. 12 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Algunas veces habrás escuchado a los desarrolladores experimentados hablar acerca de las partes "upstream" (ir contra la corriente) y "downstream" (ir en el sentido que va la corriente) de un proyecto. La palabra "upstream" simplemente se refiere a las partes tempranas de un proyecto tales como el desarrollo de requerimientos y la arquitectura, mientras que "downstream" se refiere a las últimas partes tales como construcción y pruebas del sistema. He encontrado que esta distinción entre "upstream" y "downstream" es una forma fundamentalmente útil de pensar acerca de un proyecto de software. El trabajo que los desarrolladores hacen en las etapas tempranas del proyecto es colocado en un flujo y tiene que ser "pescado" más delante en el proyecto. Si el trabajo que se hizo al inicio es bien hecho, el trabajo que es "pescado" más tarde es saludable y contribuye al éxito del proyecto. Si el trabajo que se hizo al inicio es hecho pobremente, el trabajo que es "pescado" más tarde puede perjudicar severamente al proyecto. En circunstancias extremas, inclusive puede evitar que el proyecto sea terminado. Investigadores han encontrado que un defecto insertado en el flujo del proyecto de forma temprana, por ejemplo, un defecto en la especificación de requerimientos o arquitectura, tiende a costar de 50 a 200 veces más para ser corregido hacía el final del proyecto que si hubiera sido corregido lo más cercano al punto en el que fue originalmente colocado en el flujo. La siguiente figura ilustra dicho efecto: Ilustración 1 Costo de corrección de un defecto de acuerdo a la fase en que es corregido Una sentencia en una especificación de requerimientos puede fácilmente convertirse en varios diagramas de diseño. Más tarde en el proyecto, esos diagramas pueden convertirse en cientos de líneas de código fuente, docenas de casos de pruebas, muchas páginas de documentación de usuario, pantallas de ayudas, instrucciones para el personal de soporte técnico, entre otras. 13 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Si el equipo del proyecto tiene una oportunidad de corregir una equivocación en la etapa en la que se están recolectando los requerimientos, cuando el único trabajo que ha sido hecho es la creación de una sentencia de requerimientos, hace sentido que el equipo corrija dicha sentencia en lugar de corregir todas las diferentes manifestaciones de dicha sentencia inadecuada hacía el final del proyecto. Esta idea algunas veces es llamada "contención de fase" y se refiere a la detección y corrección de los defectos en la misma fase en la cual los defectos fueron introducidos. Puesto que ningún código fuente es generado mientras las actividades "upstream" son ejecutadas, dichas actividades pueden hacer parecer que están retrasando "el verdadero trabajo" del proyecto. En realidad, están haciendo exactamente lo contrario. Están estableciendo las bases para el éxito del proyecto. Equivocarse del lado de demasiado proceso marginalmente incrementará la sobrecarga del proyecto, pero equivocarse del lado de demasiado poco permite que los defectos se deslicen y entonces deberán ser corregidos con un costo de 50 a 200 veces mayor que el costo de corrección más eficiente. Por esta razón, el "dinero inteligente" reside del lado de demasiado proceso en lugar del lado de muy poco.” 2.4.5 Costeo del software Es muy común, al menos en la industria del software mexicana, que los costos de una aplicación de software sean establecidos de acuerdo al número de horas invertidas en el desarrollo de dicha aplicación. Esta forma de costear las aplicaciones no necesariamente es inadecuada, sin embargo, existe un método que permite estandarizar y comparar los costos de varias aplicaciones y que es independiente de la complejidad de cada aplicación, a diferencia del costeo por horas que no necesariamente es efectivo cuando se trata de hacer comparaciones, ya que la complejidad entre las diferentes aplicaciones que se están comparando varía. Dicho método está relacionado con la medición del tamaño del software. Es muy común también que cuando se realizan estimaciones en un proyecto de software se estime la duración, el esfuerzo 2 y el costo de dicho proyecto con base en el esfuerzo que debe realizarse en cada actividad del proyecto, sin embargo, pocas veces se estima el tamaño del software. Estimar el tamaño del software permite estimar también la duración, el esfuerzo y el costo de un proyecto y se pueden calcular con base en la duración, esfuerzo y costo que deben invertirse para generar una unidad de software. Una unidad de software es la unidad de medida del tamaño de software, las unidades de medida del tamaño del software más comunes son los puntos de función y las líneas de código. Entonces, para poder costear el software con base en su tamaño se requiere primero estimar el tamaño del software y posteriormente establecer la duración, esfuerzo y costo unitario de cada unidad de tamaño. Existen diferentes métodos para medir el tamaño del software, uno de los más aceptados y reconocido como estándar a nivel mundial es el análisis de puntos de función (IFPUG, 2012). Para comprender mejor el concepto del tamaño del software vea la sección Tamaño del software en este mismo documento. 2 Entiéndase esfuerzo como el número de horas, días, meses o años que se requieren para realizar una actividad, multiplicados por el número de personas que participan en dicha actividad. 14 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 2.5 Bibliografía recomendada Ver Referencias. 15 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3. Estimaciones de software 3.1 Introducción “Es muy difícil defender una estimación de forma vigorosa, plausible y arriesgando el trabajo cuando ésta fue derivada por un método no cuantitativo, soportada con muy pocos datos y certificada principalmente por las corazonadas de los gerentes”. -Fred Brooks 3.1.1 ¿Qué es una estimación? Existen diferentes definiciones de estimación, a continuación se presentan algunas: 1. Una evaluación tentativa o cálculo bruto (McConnell, Software Estimation (Demystifying the Black Art), 2006). 2. Un cálculo preliminar del costo de un proyecto (McConnell, Software Estimation (Demystifying the Black Art), 2006). 3. Aprecio y valor que se da y en que se tasa y considera algo (RAE, 2012). 4. Una evaluación cuantitativa de la probable cantidad o salida. Usualmente aplicada a los costos del proyecto, recursos, esfuerzo y duraciones. Siempre debe incluir alguna indicación de precisión (ej. +- x por ciento) (PMI, 2008). Es muy importante recalcar que una estimación siempre será una aproximación, no un dato exacto. 3.1.2 Empleo y utilidad de una estimación Las estimaciones pueden emplearse y ser útiles para diferentes actividades durante un proyecto y en una organización:   En proyectos: o Para determinar el tamaño del software que se va a construir o modificar. o Para determinar la duración del proyecto. o Para determinar el esfuerzo que requieren las actividades del proyecto. o Para determinar el costo del proyecto. o Para determinar la cantidad de recursos, humanos y materiales, necesarios para el proyecto. o Para determinar el avance de la aplicación, en términos de cuánto software se ha construido. o Para determinar parte del tamaño del proyecto. o Para determinar parte del avance del proyecto, en función del avance de la aplicación. o Para determinar la cantidad de defectos que se han encontrado o que pueden llegar a encontrarse en la aplicación. En una organización: o Para poder comparar aplicaciones. o Para poder comparar proyectos. o Para determinar la productividad de los desarrolladores del software. o Para establecer precios de venta del software. 16 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. o Para comparar las cotizaciones de proyectos de desarrollo de software de diferentes proveedores. 3.1.3 Diferencia entre estimar y planear Es muy común que en la industria del software se confunda el concepto de estimación por el de programación (de actividades), es decir, cuando se solicita una estimación algunas personas elaboran un cronograma de las actividades que se van a realizar. Aunque elaborar un cronograma de actividades para posteriormente asignar esfuerzo, costo o duración es una forma de estimar, la programación de actividades es más una actividad de planeación y no es la única forma de estimar. Por lo anterior, es importante distinguir claramente las principales diferencias entre una planeación y una estimación:   Planeación o Prever el futuro, o Escritura en que sumariamente se precisan los detalles para realizar una obra. Estimación o Aproximación, o Evaluación tentativa, o Cálculo bruto, o Cálculo preliminar, o Evaluación cuantitativa. La estimación y la planeación son tópicos relacionados, pero estimar no es planear y planear no es estimar. La estimación debe ser tratada como un proceso imparcial y analítico; la planeación debe ser tratada como un proceso parcial que busca alcanzar objetivos. Con la estimación, es peligroso querer que el estimado salga ante cualquier respuesta particular. La meta es la precisión; la meta no es buscar un resultado particular. Pero la meta de la planeación es buscar un resultado particular. Deliberada y apropiadamente parcializamos nuestros planes para conseguir salidas específicas. Planeamos significados específicos para alcanzar un fin específico. Los estimados forman la base para los planes, pero los planes no tienen que ser los mismos que los estimados. Si los estimados son dramáticamente diferentes de los objetivos, los planes del proyecto necesitan reconocer esas diferencias y atenderlas con un alto nivel de riesgo. Si los estimados son cercanos a los objetivos, entonces los planes pueden asumir menos riesgo. En conclusión, estimar puede ser una actividad de planeación, estimar es calcular algún valor necesario para la planeación o para la toma de alguna decisión, valor tal como el esfuerzo, costo, duración o tamaño (del software). Mientras que planear consiste en establecer las estrategias, actividades, objetivos, recursos, procesos, etc. de forma anticipada con la intención de actuar a futuro acorde a lo definido. 17 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.1.3.1 La relación entre las estimaciones y la planeación Planeación de proyectos 1.1 Establezca el alcance de la aplicación 1.2 Estime el tamaño de la aplicación 1.3 Defina los procesos que seguirá 1.4 Seleccione un ciclo de vida 1.5 Estime el esfuerzo requerido 1.6 Identifique los recursos necesarios 1.7 Identifique capacitación requerida, entregables, hitos, involucrados, responsabilidades, restricciones y riesgos 1.8 Estime la duración del proyecto 1.9 Establezca el costo de la aplicación 18 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.1.4 Diferencia entre estimación, objetivo, compromiso Estrictamente hablando, la definición del diccionario de estimación es correcta: una estimación es una predicción de cuánto durará un proyecto o cuánto costará. Pero la estimación en los proyectos de software interactúa con objetivos de negocio, compromisos y el control. Un objetivo es un enunciado de un objetivo de negocio deseable. Las empresas tienen razones importantes para establecer objetivos independientemente de las estimaciones de software. Pero el hecho de que un objetivo es deseable o incluso aún, obligatorio, esto no necesariamente significa que es alcanzable. Mientras que un objetivo es una descripción de un objetivo de negocio deseable, un compromiso es una promesa para entregar una funcionalidad deseada con un nivel específico de calidad en una cierta fecha. Un compromiso puede ser lo mismo que un estimado, o puede ser más agresivo o más conservador que el estimado. En otras palabras, no supongas que el compromiso tiene que ser lo mismo que el estimado; no lo es. 3.1.5 El cono de la incertidumbre El desarrollo de software consiste en realizar literalmente cientos de decisiones acerca de todos los temas relacionados con las características del mismo. La incertidumbre en una estimación de software resulta de la incertidumbre de cómo se resolverán las decisiones tomadas. Conforme se toman un gran porcentaje de dichas decisiones, se reduce la incertidumbre de la estimación. Como un resultado de este proceso de resolución de decisiones, los investigadores han encontrado que las estimaciones de proyecto están sujetos a cantidades predecibles de incertidumbre en varias etapas. El cono de la incertidumbre muestra como las estimaciones se vuelven más precisas conforme el proyecto avanza. 19 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Ilustración 2 - El cono de la incertidumbre basado en hitos comunes de proyecto. El eje horizontal contiene hitos comunes de proyecto, tales como el concepto inicial, la definición aprobada del producto, los requerimientos completos, entre otros. Debido a sus orígenes, esta terminología suena de alguna forma orientada a productos. La “definición de producto” se refiere simplemente a la visión acordada del software, o el concepto de software, y aplica igualmente a servicios web, sistemas de negocio internos y la mayoría de tipos de proyectos de software. El eje vertical contiene el grado de error que ha sido encontrado en estimaciones creadas por estimadores habilidosos en varios puntos del proyecto. Las estimaciones podrían ser por cuánto costará una característica particular y cuánto esfuerzo será requerido para entregar el conjunto de características, o podría ser por cuántas características pueden ser entregadas para una cantidad particular de esfuerzo o tiempo. Como se puede observar en la gráfica, las estimaciones creadas muy temprano en el proyecto están sujetas a un alto grado de error. Las estimaciones creadas en el tiempo del concepto inicial pueden ser imprecisas por un factor de 4x en el extremo más alto o 4x en el extremo más bajo (también expresada como 0.25x, que es simplemente 1 dividido entre 4). El rango total de estimación del extremo alto al bajo es 4x dividido entre 0.25x, o 16X. Una pregunta que los gerentes y los clientes se hacen es: "¿Si te doy otra semana de trabajo en tu estimación, puedes refinarla para que contenga menos incertidumbre?” Esa es una pregunta razonable, pero desafortunadamente no es posible cumplir esa petición. Investigaciones realizadas por Luiz Laranjeira sugieren que la precisión de la estimación de software depende del nivel de refinamiento de la definición del software (Laranjeira, 1990). Entre más refinada sea la definición, más precisa será la estimación, La razón por la que una estimación contiene variabilidad es que el proyecto de software en sí mismo contiene variabilidad. La única forma de reducir la variabilidad en la estimación es reducir la variabilidad en el proyecto. 20 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Una implicación engañosa de esta representación común del cono de la incertidumbre es que parece que tomará para siempre que el cono adelgace – como si no se pudiera tener una muy buena precisión en la estimación hasta que el proyecto esté casi terminado. Afortunadamente, esa impresión es creada porque los hitos en el eje horizontal están igualmente espaciado y naturalmente suponemos que el eje horizontal es tiempo de calendario. En realidad, los hitos enlistados tienden a estar cargados al frente en el cronograma del proyecto. Cuando el cono es redibujado sobre una base de tiempo calendario, se parece a la siguiente figura: Ilustración 3 - El cono de la incertidumbre basado en tiempo calendario. El cono se adelgaza mucho más rápido que en la representación previa mostrada. Como se puede observar en esta versión del cono, la precisión de la estimación mejora rápidamente para el primer 30% del proyecto, mejorando de +-4x a +-1.25x. Un concepto importante, y difícil, es que el cono de la incertidumbre representa la mejor precisión que es posible tener en estimaciones de software en diferentes puntos del proyecto. El cono representa el error en estimaciones creadas por estimadores habilidosos. Es fácilmente posible estimar de peor forma. No es posible ser más preciso; solamente es posible tener más suerte. 3.1.5.1 El cono no adelgaza por sí mismo Otra forma en la cual el cono de la incertidumbre representa el mejor caso en una estimación es que si el proyecto no está bien controlado, o si los estimadores no son muy hábiles, las estimaciones no podrán mejorar. La siguiente figura muestra lo que pasa cuando el proyecto no se enfoca en reducir la variabilidad – la incertidumbre no es un cono, sino una nube que persiste hasta el final del proyecto. El problema no es realmente que las estimaciones no converjan; el problema es que el proyecto en sí mismo no converge – esto es, no expulsa suficiente variabilidad para soportar más estimaciones precisas. 21 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Ilustración 4 - Si un proyecto no es bien controlado o bien estimado, se puede terminar con una nube de incertidumbre que contiene aún más error de estimación que el representado por el cono. El cono adelgaza solo si se toman las decisiones que eliminan la variabilidad. Como lo muestra la figura siguiente, definir la visión del producto (incluyendo el compromiso de lo que no se hará) reduce la variabilidad. Definir los requerimientos – nuevamente, incluyendo lo que no se va a hacer – elimina la variabilidad posterior. Diseñar la interfaz de usuario ayuda a reducir el riesgo de creciente variabilidad por requerimientos mal comprendidos. Por supuesto, si el producto no está realmente definido, o si la definición del producto se redefine más adelante, el cono se hará más ancho y la precisión de la estimación será más pobre. Ilustración 5 - El cono de la incertidumbre no adelgaza por sí mismo. Se adelgaza tomando decisiones que remuevan las fuentes de variabilidad del proyecto. 22 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.1.5.2 Consideraciones para el cono de incertidumbre en las estimaciones de software Estudios de estimaciones de software han encontrado que los estimadores que inician con estimaciones de un solo punto y crean rangos basados en sus números originales de un solo punto usualmente no ajustan sus valores mínimos y máximos lo suficiente como para contabilizar la incertidumbre en sus estimaciones, especialmente en circunstancias que contienen alta incertidumbre. Esta tendencia a usar rangos que son muy angostos puede ser atendida de dos maneras. La primera es comenzar con una estimación de “lo más probable” y luego computar los rangos usando multiplicadores predefinidos, tal como se muestra en la siguiente tabla: Tabla 3 - Error de estimación por actividad de desarrollo de software Error de alcance Error posible en el Error posible en el Rango de estimaciones Fase lado inferior lado superior Concepto inicial 0.25x (-75%) 4x (+300%) 16x Definición del producto aprobada 0.50x (-50%) 2x (+100%) 4x Requerimientos completos 0.67x (-33%) 1.5x (+50%) 2.25x Diseño de interfaz de usuario completo 0.80x (-20%) 1.25x (+25%) 1.6x 0.90x (-10%) 1.10x (+10%) 1.2x Diseño detallado completo (para proyectos secuenciales) inferiores y superiores Fuente: Adaptado de Software Estimation with Cocomo II (Boehm, 2000). Si se usan los valores de esta tabla, debe reconocerse que en el punto en el que se crea la estimación se desconoce si la salida actual del proyecto caerá en el límite superior o en el límite inferior del rango. Una segunda estrategia está basada en el hallazgo de que la habilidad para “saber cuánto” y la habilidad para “saber qué tan incierto” son dos habilidades diferentes. Se puede tener una persona que estime el mejor y peor caso del rango y una segunda persona que estime la probabilidad de que el resultado actual caiga en dicho rango. 3.1.5.3 Relación entre el cono de incertidumbre y el compromiso Las organizaciones de software rutinariamente sabotean sus propios proyectos haciendo compromisos demasiado pronto en el cono de incertidumbre. Si se realiza un compromiso en las fases del concepto inicial o la definición del producto, se tendrá un factor de error de 2x a 4x en las estimaciones. Un administrador de proyectos habilidoso puede navegar el proyecto hasta terminarlo si la estimación está dentro del 20% de la realidad del proyecto. Pero ningún administrador puede llevar a buen puerto un proyecto cuando las estimaciones son erróneas por un porcentaje de cientos. 23 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. No es posible realizar compromisos significativos en la parte temprana y ancha del cono. Las organizaciones efectivas retrasan sus compromisos hasta que han realizado el trabajo necesario para forzar que el cono se haga más angosto. Los compromisos significativos en la parte media del proyecto (cerca del 30% del camino recorrido) son posibles y apropiados. 3.1.5.4 El cono de la incertidumbre y el desarrollo iterativo El cono de incertidumbre está más relacionado con proyectos iterativos que lo que puede estar con proyectos secuenciales. Si se está trabajando en un proyecto que realiza un ciclo completo de desarrollo en cada iteración se tendrá un cono “miniatura” en cada iteración. Antes de que se realice el trabajo de requerimientos para la iteración, se estará en el punto de la definición del producto aprobada en el cono, sujeto a una variabilidad de 4x en las estimaciones del extremo bajo al alto del cono. Con iteraciones cortas (menos de un mes), se puede mover de la definición del producto aprobada a los requerimientos completos y diseño terminado de interfaz de usuarios en unos pocos días, reduciendo la variabilidad de 4x a 1.6x. Si el cronograma es inmovible, la variabilidad de 1.6x aplicará para las características que se pueden entregar en el tiempo disponible, en lugar del esfuerzo o duración. Lo que se sacrifica con estrategias que dejan los requerimientos sin definir hasta el inicio de cada iteración es la certeza y precisión acerca de la combinación de costo, duración y características que se entregarán en las iteraciones que están por delante. La alternativa a iteración total no es no tener iteraciones. Se ha encontrado que es casi universalmente inefectiva. Las alternativas son menos iteraciones o diferentes iteraciones. Muchos equipos de desarrollo han encontrado un término medio en el cual la mayoría de los requerimientos son definidos al inicio del proyecto, pero el diseño, la construcción, pruebas y liberación son llevados a cabo en cortas iteraciones. En otras palabras, el proyecto se mueve secuencialmente a través del hito de diseño terminado de interfaz de usuario (cerca del 30% del tiempo del calendario del proyecto) y luego se cambian a una estrategia iterativa desde ese punto en delante. Esto reduce la variabilidad existente en el cono cerca de +-25%, lo que permite controlar el proyecto lo suficiente para conseguir el objetivo mientras se obtienen beneficios del desarrollo iterativo. Los equipos de proyecto pueden dejar alguna cantidad de tiempo planeado para requerimientos por definir al final del proyecto. Lo anterior introduce algo de variabilidad relacionada con el conjunto de funciones, lo cual, en este caso, es positivo porque se empleará solamente si se identifican funciones deseables para implementar. Este término medio soporta un amplio rango de predictibilidad de costo y duración así como una cantidad moderada de flexibilidad en requerimientos. 3.1.6 Las estimaciones y el control de proyectos Algunas veces cuando la gente discute la estimación de software se trata a la estimación como una actividad puramente predictiva. La gente se comporta como si el estimado fuera hecho por un estimador imparcial, sentado en algún lugar en el espacio exterior, desconectado de la planeación del proyecto y la priorización de actividades. 24 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. En realidad, hay muy poco de pureza en una estimación de software. Si alguna vez ha querido un ejemplo del principio de incertidumbre de Heisenberg aplicado a software, sería la estimación. El principio de incertidumbre de Heisenberg es la idea de que el mero acto de observar una cosa la cambia, de tal forma que nunca se estará seguro de cómo se hubiera comportado esa cosa si no se le hubiere estado observando). Una vez que hacemos una estimación y, sobre las bases de dicho estimado, hacemos un compromiso para entregar funcionalidad y calidad en una fecha determinada, entonces controlamos el proyecto para alcanzar el objetivo. Las actividades típicas de control del proyecto incluyen la remoción de requerimientos no críticos, la redefinición de requerimientos, el reemplazo de personal menos experimentado con personal más experimentado, entre otras. La siguiente figura ilustra dicha dinámica: Además de las actividades de control del proyecto, los proyectos a menudo son afectados por eventos externos imprevistos. El equipo del proyecto podría necesitar crear una liberación intermedia para soportar u cliente clave. El personal podría ser distraído para soportar una aplicación antigua, entre otras cosas. Los eventos que ocurren durante un proyecto casi siempre invalidan las suposiciones que fueron empleadas para estimar el proyecto. Las suposiciones de funcionalidad cambian, las suposiciones de personal cambian y las prioridades cambian. Se vuelve imposible realizar una evaluación analítica clara de si el proyecto fue estimado de forma precisa, puesto que el proyecto de software que ha sido entregado no es el proyecto que fue originalmente estimado. En la práctica, si se entrega un proyecto con el nivel de funcionalidad esperado, usando el nivel de recursos planeado, dentro del tiempo establecido, entonces típicamente se dice que el proyecto “cumple sus estimados”, a pesar de todas las impurezas analíticas implícitas en dicho enunciado. 3.1.7 Factores a considerar al realizar estimaciones Al igual que los ciclos de vida del software, los modelos de procesos y metodologías, la elaboración de una estimación siempre dependerá del contexto, por lo tanto, siempre será recomendable adaptar cualquier proceso, técnica o método de estimación 25 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. a la situación particular en la que se empleará. Lo anterior significa que es importante tener claro cuál es el propósito de la estimación, en qué etapa se está realizando, quien o quienes la están elaborando, con qué información se cuenta y qué otros procesos dependen de la información que se generará. Algunos proyectos determinan sus características y luego se enfocan en estimar la duración y el esfuerzo requeridos para entregar dichas características. Otros proyectos determinan sus presupuestos y tiempo de desarrollo y luego se enfocan en cuántas características pueden entregar. Muchas técnicas de estimación son aplicables independientemente de lo que se está estimando; algunas pocas técnicas funcionan mejor para estimar cuánto esfuerzo requerirá un proyecto, cuánto durará un proyecto o cuántas características pueden ser entregadas. Al seleccionar un proceso, técnica o método de estimación deben considerarse los siguientes factores: 3.1.7.1 El tamaño del proyecto El tamaño del proyecto es un factor importante a considerar al elegir una técnica o método de estimación. Debido a que el dimensionamiento de un proyecto puede variar dependiendo de cada compañía, grupo o persona, en este documento no se establecen nombres o definiciones puntuales de tamaño, sin embargo, los siguientes son algunos de los criterios que pueden considerarse para establecer el tamaño de un proyecto y que finalmente tendrán influencia en la decisión de la mejor técnica o método de estimación:     Duración del proyecto Número de personas que conformarán el equipo del proyecto Tamaño del software que se va a construir o modificar. Propósito del proyecto, es decir, crear un nuevo programa computacional o modificar uno existente. 3.1.7.2 La forma de medir el tamaño de la aplicación La forma en que se mida el tamaño de la aplicación tendrá influencia importante en la decisión de qué método o técnica debe emplearse para estimar, lo anterior debido a que diferentes métodos y técnicas aplican para diferentes unidades de medida del tamaño, por ejemplo, el método de análisis de puntos de función se emplea para medir las funciones que realizará la aplicación y no puede ser empleado para contar o estimar el número de líneas de código de la misma. 3.1.7.3 El ciclo de vida Es muy común que en los proyectos de software se realicen estimaciones al inicio del proyecto, o previo al inicio del proyecto, sin embargo es importante que durante el proyecto se realicen estimaciones que permitan ir incrementando la certidumbre de la duración, costos, esfuerzo y tamaño originalmente estimados. Por lo anterior, es importante que, dependiendo del ciclo de vida seleccionado se determine cuántas estimaciones se realizarán y qué métodos o técnicas se emplearán en cada etapa. 26 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.1.7.4 El propósito del proyecto El propósito del proyecto es uno de los factores más importantes a considerar al estimar, para términos de este documento se identifican los siguientes propósitos genéricos para un proyecto de software:      Desarrollar una nueva aplicación (nuevo desarrollo) Modificar una aplicación existente (mantenimiento) Implementación de una aplicación (instalación y configuración de la aplicación) Migración de una aplicación (movimiento de la aplicación de un ambiente a otro) Actualización de una aplicación (actualización de la aplicación de una versión a otra más nueva) En cada uno de los casos anteriores el método o técnica de estimación puede, y debe, variar. Por ejemplo, muy probablemente una estimación de proyecto en los dos primeros casos esté basada en el tamaño de lo que se va a construir, sin embargo, en los tres últimos casos (implementación, migración y actualización) la estimación tenga que estar basada en los entregables del proyecto y las actividades que deben realizarse para instalarlos, diseñarlos, construirlos, configurarlos o probarlos. 3.1.7.5 La tecnología empleada La tecnología empleada siempre será un factor importante a considerar sobre todo si se toma en cuenta que la selección de ésta puede facilitar o hacer más complejo el diseño, la construcción, las pruebas o la liberación de la aplicación. Las decisiones arquitectónicas relacionadas con la tecnología siempre afectarán a la aplicación y al proyecto mismo, ya sea generando más problemas que deben resolverse o reduciéndolos. 3.1.8 El proceso de estimar Es importante comprender que cuando se realiza una estimación, las actividades asociadas a ésta se realizan como parte de procesos o funciones de negocio que integran varios procesos. Siendo así, elaborar una estimación requerirá elementos de entrada (insumos) y generará productos (salidas) que probablemente sean requeridos para otros procesos. En dicho contexto se presenta el siguiente: 3.1.8.1 Proceso de estimación A continuación se presenta un proceso de estimación propuesto, este proceso puede, y muy seguramente debe, ser adaptado a las necesidades particulares de cada organización: Insumos (entradas) Actividades Productos - Alcance de la aplicación 1. Identificar el propósito de la estimación Estimación: 2. Identificar el propósito del proyecto Identificar el tamaño del proyecto - Tamaño 3. 27 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. - Requerimientos de la 4. Identificar el ciclo de vida - Duración aplicación 5. Identificar la tecnología - Restricciones de la Seleccionar una o varias técnicas o métodos de estimación - Esfuerzo 6. aplicación y/o del proyecto 7. Adaptar la(s) técnica(s) o método(s) de estimación (en caso de ser 8. - Costo necesario) seleccionado(s) - Precio Aplicar la(s) técnica(s) o método(s) de estimación seleccionado(s) y - Recursos adaptado(s) 9. Validar la estimación Herramientas - Técnicas de estimación - Métodos de estimación - Información histórica - Software de estimación Roles Estimador El siguiente diagrama presenta algunos de los componentes del proceso de estimación. Ilustración 6 – Algunos de los componentes del proceso de estimación 28 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.2 El tamaño del software 3.2.1 Introducción En la industria de software mexicana es muy común hablar de la duración de un proyecto o de una actividad, inclusive se han generalizado los conceptos de esfuerzo y costo, sin embargo, aunque estos parámetros son válidos y están relacionados con las estimaciones de proyectos, podrían no ser muy útiles en proyectos de software si se estiman y emplean de forma aislada sin considerar el tamaño del software que se va a construir. ¿Pero a qué se refiere entonces el tamaño de software y qué relación tiene con las estimaciones? El tamaño de software es el atributo que permite determinar cuánto mide éste. Dicho atributo está estrechamente ligado con las estimaciones puesto que representa la entrada principal requerida para determinar el esfuerzo, duración y costo de diseñarlo, construirlo, probarlo y liberarlo. Dado que el software es un bien intangible, puede llegar a ser complicado determinar cuál es su tamaño. Las dos unidades de medida más comunes, generalmente empleadas y aceptadas para medir el tamaño del software son:   Las líneas de código Los puntos de función, que no se refiere a otra cosa más que a las funciones del software. Identificar el tamaño del software a través de cada una de estas unidades de medida tiene sus ventajas y desventajas, sin embargo, si una organización logra estandarizar el método y la unidad de medida empleada para determinar el tamaño del software a través de sus proyectos, la unidad de medida en sí misma será menos relevante que la información que podrá obtenerse y que podrá ser de gran utilidad para estimar proyectos futuros, aplicaciones futuras, aplicaciones compradas, productividad de los desarrolladores de software, entre otras cosas. El tamaño del producto es el más grande contribuyente en el cronograma de un desarrollo. Los productos más grandes toman más tiempo. Los productos más pequeños toman menos tiempo. Características adicionales requieren especificación, diseño, construcción, pruebas e integración adicionales. Requieren coordinación adicional con otras características y requieren que se coordinen otras características con ellas. Puesto que el esfuerzo requerido para construir software se incrementa desproporcionadamente más rápido que el tamaño del software, una reducción en tamaño mejorará la velocidad de desarrollo desproporcionadamente. Reducir el tamaño de un programa de tamaño medio a la mitad típicamente reducirá el esfuerzo requerido en casi dos tercios. Se puede reducir el tamaño del producto dejando para desarrollo solamente las características esenciales o se puede reducir temporalmente desarrollando un producto en etapas. También se puede reducir desarrollando en un lenguaje o herramienta de alto nivel de tal forma que cada característica requiera menos código. 29 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.2.2 Los componentes del software Ya se habló del tamaño del software y cómo puede medirse, sin embargo, es muy importante comprender que no siempre los métodos o modelos empleados por la mayoría funcionan para todo y para todos. Por lo anterior, es muy importante tener muy claro cuáles son los componentes del software para que, en caso de ser necesario, puedan establecerse nuevos métodos de medición del tamaño que funcionen para las necesidades de cada organización. Dicho lo anterior, podríamos decir que los siguientes son algunos de los componentes más comunes e importante del software, entendiendo software como un sistema compuesto por una aplicación y su documentación. El siguiente modelo, aunque es extenso, no es limitativo: Software Aplicación Pantallas Controles Etiquetas Documentación Componentes Base de datos Clases Tablas Archivos De requerimientos De datos De arquitectura De configuración De diseño Métodos Campos Atributos Registros De pruebas Variables Índices De liberación Constantes Interfaces Procedimientos almancenados De usuario Vistas De instalación Funciones De configuración Reglas Disparadores 30 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Otros factores que deben considerarse y que están asociados con la aplicación son los siguientes:           Complejidad Funcionalidad Reglas de negocio Algoritmos Diseño (gráfico) Atributos de calidad o Precisión o Escalabilidad o Extensibilidad o Seguridad o Usabilidad o Desempeño o Otros Documentación (del código fuente) Estándares de nomenclatura Patrones de arquitectura y diseño empleados Interfaces con otras aplicaciones En conclusión, es muy importante conocer cómo está conformado un programa computacional y el software en general, para poder determinar cómo puede medirse su tamaño. 3.2.3 Utilidad de la medición del tamaño del software Medir el tamaño del software tiene muchas utilidades tales como:       Establecer nuevas estimaciones - Comparando la estimación del tamaño de una aplicación con el tamaño de aplicaciones construidas previamente para determinar la duración, esfuerzo y costo de diseñarla y construirla. Medir la densidad de defectos - Estableciendo la cantidad de defectos contenidos por unidad de medida del tamaño. Medir la productividad - Determinando la cantidad de producto (la aplicación) que puede generar un desarrollador por unidad de tiempo (horas, por ejemplo). Determinar el avance de construcción de la aplicación – Identificando el tamaño de producto (aplicación) que ya se ha construido. Seleccionar proveedores – Entregando el tamaño del software a construir, se pueden solicitar cotizaciones a diferentes proveedores para seleccionar uno. Establecer el precio del software – Se puede definir un precio por unidad de medida y con base en el tamaño determinar el precio total de la aplicación. 31 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.3 Clasificación de las estimaciones 3.3.1 Introducción Con la finalidad de comprender mejor las estimaciones, se presenta la siguiente clasificación: Ilustración 7 - Clasificación de las estimaciones 3.3.2 Enfoques de estimación Ilustración 8 – Clasificación de enfoques de estimación Las estimaciones pueden clasificarse por su enfoque en:   De lo general a lo particular (Top-down) De lo particular a lo general (Bottom-up) 3.3.1.1 Enfoque de lo general a lo particular (Top-down) El enfoque de lo general a lo particular, también conocido como el modelo macro, se basa en dividir el alcance del proyecto y el uso de promedios (ya sea específicos a la organización o a la industria) para estimar el costo y la complejidad asociados con la implementación de las partes y sus interconexiones. La característica distintiva del enfoque de lo general a lo particular es que se centra en las propiedades generales del sistema, tales como la integración, gestión del cambio, y la entrega gradual, combinada con su relativa facilidad de aplicación. Sin 32 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. embargo, como se mencionó anteriormente, por su naturaleza, este enfoque no es tan bueno como el enfoque de lo particular a lo general en la captura de los factores de menor nivel, como las cuestiones específicas de cada proyecto, las características de diseño de aplicaciones, y detalles específicos de la implementación, que tienden a acumularse rápidamente y puede afectar en gran medida la estimación. 3.3.1.2 Enfoque de lo particular a lo general (Bottom-up) En los primeros días de la programación informática, la mayoría de las estimaciones de software se producían de forma ascendente. Se contaban las líneas de código fuente escritas manualmente, que actuaban como una variable clave en las estimaciones, para calcular el tamaño total del proyecto. La otra variable clave, que era igual de fácil de cuantificar, era la productividad del desarrollador. La situación empezó a cambiar con la introducción de los diversos lenguajes de programación (C, Pascal, Ada, Lisp, etc.), los paradigmas de programación (orientado a objetos, basado en plantillas, etc.), las arquitecturas de hardware, plataformas y la capacidad de generación de código. El enfoque de lo particular a lo general es generalmente considerado como más intuitivo y menos propenso a errores que el enfoque de lo general a lo particular. En el caso de componentes bien aislados puede producir estimaciones muy precisas. Sin embargo, usar solamente el enfoque de lo particular a lo general puede provocar que se pasen por alto limitaciones y costos significativos a nivel sistema, especialmente cuando se emplea este enfoque en ausencia de suficientes datos de requerimientos. 3.3.3 Técnicas de estimación Ilustración 9 - Clasificación de técnicas de estimación Las técnicas de estimación pueden categorizarse en:   Basadas en experiencia Orientadas al aprendizaje 3.3.3.1 Técnicas de estimación basadas en experiencia Las técnicas basadas en la experiencia o conocimiento se fundamentan en el juicio subjetivo de un experto, o grupo de expertos, en la materia. 33 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. A diferencia de modelos paramétricos más estrictos, estas técnicas se basan principalmente en la experiencia y conocimiento de los seres humanos, lo cual constituye su principal debilidad. Esta debilidad puede ser mitigada mediante la expansión del tamaño del grupo de los estimadores. 3.3.3.2 Técnicas de estimación orientadas al aprendizaje Diversos estudios indican que más de tres cuartas partes de las estimaciones de software se construyen utilizando algún tipo de analogía o comparación con las soluciones previamente completadas, es decir, utilizan técnicas conocidas como orientadas al aprendizaje. Aunque intuitivamente similares a las técnicas basadas en la experiencia, las técnicas orientadas al aprendizaje toman un ángulo diferente. Su objetivo es encontrar un sistema similar producido en otros lugares y, a través de determinar cómo las propiedades del nuevo sistema pueden variar con respecto al existente, extrapolar la estimación. La ventaja más evidente de las técnicas de aprendizaje orientado es que la estimación se basa en las características probadas y no sólo la evidencia empírica, como en el caso de la estimación basada en la experiencia. Una limitación de esta técnica es la necesidad de determinar las variables más importantes que se utilizan para describir la solución, incluidas las que la distinguen de la línea de base. Estos objetivos pueden ser difíciles o pueden consumir mucho tiempo para lograrse. 3.3.4 Métodos de estimación Ilustración 10 - Clasificación de métodos de estimación Las estimaciones pueden clasificarse por sus métodos en:  Algorítmicos o Matemáticos o Estadísticos 3.3.4.1 Métodos de estimación algorítmicos Los métodos algorítmicos emplean modelos matemáticos (dirigidos por fórmulas). Toman métricas históricas, calculadas o estadísticas, tales como líneas de código y el número de funciones, así como factores ambientales conocidos, tales como la plataforma de programación, el marco de trabajo, la plataforma de hardware y la metodología de diseño, como sus insumos 34 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. para producir una estimación con un grado o rango conocido de precisión. Por su capacidad de aceptar diferentes métricas estos métodos son también llamados a veces basados en métricas. A diferencia de las técnicas no algorítmicas, los métodos algorítmicos pueden producir estimaciones repetibles, y son relativamente fáciles de ajustar. Estos métodos, sin embargo, son también más sensibles a los datos de entrada inexactos y pueden llegar a producir estimaciones muy pobres si no se calibran y validan correctamente. Además, estos métodos no pueden abordar eficazmente circunstancias excepcionales, tales como personal altamente creativo o perezoso, o trabajo en equipo excepcionalmente fuerte o pobre. 3.4 Técnica de juicio de experto 3.4.1 Introducción La elaboración de estimaciones mediante el juicio de experto es una de las técnicas más empleadas en nuestra industria, principalmente cuando se emplean enfoques que van de lo particular a lo general. En este documento se propone el uso del juicio de experto en combinación con algunas técnicas de descomposición del alcance que permiten identificar los elementos que van a ser estimados. 3.4.2 Descripción de la técnica Técnica de estimación Nombre: Juicio de experto Propósito: Estimar empleando la experiencia de quien estima. Enfoque: De lo particular a lo general (Bottom-Up) Qué estima: Tamaño, duración, esfuerzo, costo, recursos Procedimiento: 1. Identificar qué se está solicitando o buscando (cumplir un objetivo, establecer un compromiso o estimar) 2. Identificar, de forma general, cuál es el entregable y/o actividades que se realizarán (descomponer en caso de ser necesario) 3. Identificar el propósito de la estimación (planear, re-planear, cotizar, otro) 4. Identificar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o recursos) 5. Solicitar información adicional en caso de ser necesario 6. Resolver dudas en caso de ser necesario 7. Revisar registros de estimaciones previas (para seleccionar alguna en caso de que pueda ser comparable con la actual) 8. Estimar 9. Registrar y almacenar valores estimados 35 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 10. Registrar y almacenar suposiciones y razonamientos hechos al estimar 11. Validar estimación 12. Presentar estimación (preferentemente como un rango) 3.5 Técnica Delphi 3.5.1 Introducción En la técnica Delphi, a un grupo de expertos en la materia se le pide que haga la evaluación de un problema. Durante la ronda inicial de estimación, cada experto ofrece su evaluación individual y sin consultar a los demás. Después de los resultados de la ronda inicial se recogen y se clasifican, los participantes se involucran en una segunda ronda de análisis, esta vez con la información sobre las evaluaciones realizadas por otros participantes. Durante esta ronda se espera reducir la amplitud de los números, mientras que algunos elementos son considerados para obtener mayor detalle, otros son descartados. Después de unas cuantas rondas, el equipo llega a una estimación mutuamente acordada. 3.5.2 Descripción de la técnica Técnica de estimación Nombre: Delphi Propósito: Estimar empleando la experiencia varios estimadores. Enfoque: De lo particular a lo general (Bottom-Up) Qué estima: Tamaño, duración, esfuerzo, costo, recursos Procedimiento: 1. Reunir a los estimadores 2. Establecer / comunicar el propósito de la estimación (planear, re-planear, cotizar, otro) 3. Establecer / comunicar el entregable o actividades que se estimarán 4. Establecer / comunicar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o recursos) 5. Proporcionar a los estimadores cualquier información que sea relevante 6. Resolver dudas de los estimadores 7. Estimar (cada estimador es responsable de hacerlo) 8. Solicitar a cada estimador su estimación, sin mostrarla a los demás 36 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 9. Clasificar las estimaciones 10. Entregar la información recolectada y clasificada 11. Detallar información que sea necesaria y descartar la que no 12. Repetir los pasos del 7 al 11 hasta llegar a una estimación mutuamente acordada 13. Registrar y almacenar valores estimados 14. Registrar y almacenar suposiciones y razonamientos hechos al estimar 3.6 Método de contar, calcular, juzgar 3.6.1 Introducción Este método consiste en encontrar algún elemento que se pueda contar y que esté altamente relacionado con el tamaño de la aplicación que se está estimando. Una vez que se hayan contado los elementos de la aplicación multiplíquelos por una medida de tiempo unitaria. En caso de que no se puedan contar elementos entonces emplee el juicio de experto. 3.6.2 Descripción del método Método de estimación Nombre: Contar, calcular, juzgar Propósito: Estimar descomponiendo el objeto que se va a estimar Enfoque: De lo particular a lo general (Bottom-Up) Qué estima: Tamaño, duración, esfuerzo, costo, recursos Procedimiento: 1. Identificar qué se está solicitando o buscando (cumplir un objetivo, establecer un compromiso o estimar) 2. Identificar, de forma general, cuál es el entregable y/o actividades que se realizarán (descomponer en caso de ser necesario) 3. Identificar el propósito de la estimación (planear, re-planear, cotizar, otro) 4. Identificar qué se está solicitando estimar (tamaño, duración, esfuerzo, costo o recursos) 5. Solicitar información adicional en caso de ser necesario 6. Resolver dudas en caso de ser necesario 7. Revisar registros de estimaciones previas (para seleccionar alguna en caso de que pueda ser comparable con la actual) 8. Identificar y contar los elementos que van a generarse (pantallas, reportes, tablas, etc.) 37 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 9. Establecer un valor unitario para cada elemento con base en información histórica (duración, esfuerzo, costo, recursos) (emplear juicio de experto como último recurso) 10. Calcular los valores totales para cada elemento 11. Registrar y almacenar valores estimados 12. Registrar y almacenar suposiciones y razonamientos hechos al estimar 13. Validar estimación 14. Presentar estimación (preferentemente como un rango) 3.7 Método de análisis de puntos de función 3.7.1 Introducción Un punto de función es una medida sintética del tamaño de un programa computacional que es a menudo usada en las etapas tempranas de un proyecto. Los puntos de función son más fáciles de determinar de una especificación de requerimientos que las líneas de código y proveen una medida más exacta del tamaño de un programa. Existen diferentes métodos para contar puntos de función. El análisis de puntos de función es un método estándar para medir el desarrollo de software desde el punto de vista del usuario. Mide el software cuantificando la funcionalidad que provee al usuario con base en el diseño lógico. El número de puntos de función en un programa está basado en el número y complejidad de cada uno de los siguientes elementos:  Entradas – Pantallas, formas, cajas de dialogo, controles o mensajes a través de los cuales un usuario final u otro programa agrega, elimina o cambia datos del programa. Esto incluye cualquier entrada que tiene un formato único o  una lógica de procesamiento única. Salidas – Pantallas, reportes, gráficas o mensajes que el programa genera para ser usado por un usuario final u otro programa. Esto incluye cualquier salida que tenga un formato diferente o requiera una lógica de procesamiento  diferente que otros tipos de salidas. Consultas – Combinaciones de entrada / salida en las cuales una entrada resulta en una salida simple e inmediata. El término se originó en el mundo de bases de datos y se refiere a la búsqueda directa de datos específicos, usualmente empleando una llave única. En las aplicaciones modernas con interfaces gráficas de usuario (GUI – Graphic User Interface por sus siglas en inglés), la línea entre las consultas y las salidas es borrosa; generalmente, sin embargo, las consultas regresan datos directamente de una base de datos y proveen formato rudimentario, mientras que las salidas pueden procesar, combinar o resumir datos complejos y pueden ser altamente formateadas. 38 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.  Archivos lógicos internos – Grupos lógicos más importantes de datos de usuario final o información de control que está completamente controlada por el programa. Un archivo lógico puede estar compuesto de un archivo plano o una  tabla de una base de datos relacional. Archivos lógicos externos – Archivos controlados por otros programas con los cuales el programa que está siendo contado interactúa. Esto incluye cada grupo lógico importante de datos o información de control que entra o deja el programa. La terminología empleada en el análisis de puntos de función está muy orientada a las bases de datos. El método básico funciona bien para todos los tipos de software, pero se tendrá que adaptar a cada ambiente si es que no se están construyendo sistemas con uso intensivo de base de datos. El procedimiento para contar el tamaño de un programa mediante el análisis de puntos de función se muestra a continuación. 3.7.2 Procedimiento 1. Determinar el tipo de conteo. 2. Identificar el alcance, propósito y límites de la aplicación. 2.1. Identificar el alcance (pantallas, descripciones, necesidades de negocio, casos de uso de negocio, requerimientos de negocio, etc.). 2.2. Identificar el propósito del conteo (opcional. Ayuda a enfocar y entender el objetivo del conteo) 2.3. Identificar los límites (identificar y diferenciar otras aplicaciones, actores). 3. Contar las funciones de datos. 3.1. Identificar y contar los almacenamientos lógicos (ILF o EIF). ILF si es mantenido por la aplicación, EIF si no es mantenido por la aplicación. (no incluir tablas temporales, índices o catálogos que solo tienen un identificador y una descripción). 3.1.1. Determinar la complejidad de cada almacenamiento lógico contando los elementos de datos (DETs y RETs). 3.2. Determinar la contribución de cada almacenamiento lógico, medida en puntos de función con base en la tabla 1 y tabla 2 (usar ambas tablas solo para nuevos desarrollos). 4. Contar las funciones transaccionales. 4.1. Identificar y contar los procesos elementales clasificándolos en funciones transaccionales (EI, EQ, EO). 4.1.1. Determinar la complejidad de cada función transaccional contando los elementos de datos (DETs FTRs). 4.1.2. Determinar la contribución de cada función transaccional, medida en puntos de función con base en la tabla 3, tabla 4 y tabla 5 (usar las 3 tablas solo para nuevos desarrollos). Ver los criterios de conteo en la definición de DETs para funciones transaccionales. 5. Determinar los puntos de función no ajustados. 5.1. Sumar los puntos de función de las funciones de datos y funciones transaccionales. 6. Determinar el valor del factor de ajuste. Ver también la tabla 6. 39 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 7. Determinar los puntos de función ajustados. (Puntos de función ajustados = Puntos de función no ajustados x valor del factor de ajuste). El siguiente diagrama presenta algunos de los componentes del método: Ilustración 11 - Algunos de los componentes del método de análisis de puntos de función 3.7.3 Tablas 3.6.3.1 Tabla 1 - Complejidad de funciones de datos Tabla para determinar la complejidad de las funciones de datos. RET\DET 1-19 20-50 50+ 1 Baja Baja Media 2-5 Baja Media Alta 6+ Media Alta Alta 3.6.3.2 Tabla 2 – Puntos de función para datos Puntos de función correspondientes a funciones de datos de acuerdo a su complejidad. Función de Baja Media Alta datos 40 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. ILF 7 10 15 EIF 5 7 10 3.6.3.3 Tabla 3 – Complejidad de entradas externas Tabla para determinar complejidad de External Input (EI). FTR\DET 1-4 5-15 16+ 0-1 Baja Baja Media 2 Baja Media Alta Media Alta Alta 3+ 3.6.3.4 Tabla 4 – Complejidad de consultas y salidas externas Tabla para determinar complejidad de External Inquiry (EQ) y External Output (EO). FTR\DET 1-4 5-15 16+ 0-1 Baja Baja Media 2-3 Baja Media Alta 4+ Media Alta Alta 3.6.3.5 Tabla 5 – Puntos de función para transacciones Puntos de función correspondientes a funciones transaccionales. Función Baja Media Alta transaccional EI 3 4 6 EQ 3 4 6 EO 4 5 7 3.6.3.6 Tabla 6 – Características generales del sistema Cada característica tiene descripciones asociadas que ayudan a determinar los grados de influencia de dichas características. Los grados de influencia varían en una escala de cero a cinco, desde "ninguna influencia" hasta "fuerte influencia". Característica general del sistema 1 Comunicaciones de datos Descripción ¿Qué tanta infraestructura de comunicación existe para ayudar en la transferencia o intercambio de información con la aplicación o sistema? 41 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 2 Procesamiento de datos distribuido ¿Cómo son manejados los datos y funciones de procesamiento distribuidos? 3 Desempeño ¿Algún valor de tiempo de respuesta o desempeño del procesamiento fue requerido por el usuario? 4 Configuración intensa de uso ¿Qué tan intensamente es usada la plataforma de hardware actual en dónde será ejecutada la aplicación? 5 Promedio de transacciones ¿Qué tan frecuentemente son ejecutadas las transacciones? (diariamente, semanalmente, diariamente, etc.) 6 Entrada de datos en línea ¿Qué porcentaje de la información es introducida en línea? 7 Eficiencia del usuario final La aplicación fue diseñada para tener eficiencia del usuario final? 8 Actualización en línea ¿Qué tantos ILFs son actualizados por transacciones en línea? 9 Procesamiento complejo ¿La aplicación tiene procesamiento lógico y matemático intensivo? Reusabilidad ¿La aplicación fue desarrollada para cumplir una o más necesidades 10 de usuario? 11 Facilidad de instalación ¿Qué tan difícil es la instalación? 12 Facilidad de operación ¿Qué tan efectivos y/o automatizados son los procedimientos de arranque, respaldo y recuperación? 13 Sitios múltiples ¿La aplicación fue diseñada, desarrollada y soportada para ser instalada en múltiples sitios para múltiples organizaciones? 14 Facilidad de cambio ¿La aplicación fue diseñada, desarrollada y soportada para facilitar los cambios? 42 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.7.4 Diagramas de UML 3.7.4.1 Diagrama 1 – Elementos considerados para el conteo 43 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.7.5 Catálogos 37.5.1 Tipo de conteo  Nuevo desarrollo y mejoras.  Implementación y adquisición de paquetes de software (productos comerciales ya hechos).  Mantenimientos. 3.7.5.2 Propósitos del conteo  Estimar (esfuerzo, duración, tamaño, costo, etc.).  Controlar el crecimiento del tamaño durante el desarrollo del producto.  Evaluar productividad.  Controlar la cantidad de producto que es fabricado a lo largo del proyecto. 3.7.5.3 Almacenamientos lógicos (funciones de datos)   ILF – Internal Logical File. EIF – External Interface File. 3.7.5.4 Elementos de datos   DET – Data Element Type RET – Record Element Type 3.7.5.5 Funciones transaccionales    EI (External Input) EQ (External Inquiry) EO (External Output) 44 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.7.6 Términos asociados con el método 3.7.6.1 Almacenamientos lógicos (funciones de datos) Se clasifican en ILF (Internal Logical File) y EIF (External Interface File). También conocidos como entidades de información, deben identificarse en cuanto a que sean totalmente independientes y que tengan un significado para el usuario. Por ejemplo, índices, tablas temporales son considerados almacenamientos técnicos creados con propósitos de implementación y no contribuyen al tamaño funcional de la aplicación. Así mismo, catálogos que contienen sólo un ID y una descripción, son almacenamientos considerados como “Code Table” y tampoco tendrán una contribución en el tamaño funcional. El punto clave para agrupar los almacenamientos lógicos, es verificando la dependencia entre ellos. Una pregunta clave, es respondernos si dicho almacenamiento puede existir de manera aislada, o si para tener significado debe formar parte de otro almacenamiento. Por ejemplo: Si se define la tabla de empleado, y la tabla telefonos_empleado, ambas son consideradas como un solo almacenamiento lógico, ya que telefonos_empleado no tiene significado por sí sola. Otra forma de ver esta independencia, por ejemplo, es reflexionando lo siguiente, si desaparece un registro de la tabla de empleado ¿tiene sentido para el negocio conservar el registro asociado en telefonos_empleado?. Si la respuesta es positiva, entonces se considera que cada entidad puede existir de manera independiente y por lo tanto serán dos almacenamientos lógicos. Por el contrario, si la respuesta es negativa, los almacenamientos no existen de manera independiente, y por lo tanto son un solo almacenamiento lógico. 3.7.6.2 ILF – Internal Logical File. Es un tipo de almacenamiento lógico. Será ILF si dicho almacenamiento es mantenido por al menos una función transaccional dentro de la aplicación se está contando. 3.7.6.3 EIF – External Interface File. Es un tipo de almacenamiento lógico. Será un EIF si dicho almacenamiento es UNICAMENTE referenciado y no mantenido por la aplicación que se está contando. 3.7.6.4 DETs (Data Element Types) (para funciones de datos) Esta definición aplica para las funciones de datos. Son los campos de datos únicos e identificables por el usuario. Ayudan a identificar la complejidad de un almacenamiento lógico. 3.7.6.5 DETs (Data Element Types) (para funciones transaccionales) Esta definición aplica para las funciones transaccionales. Son los campos únicos de información que son identificables por el usuario y que entran o salen de la función transaccional. Ayudan a identificar la complejidad de una función transaccional. A continuación se presentan algunos criterios para contar los DETs en funciones transaccionales: 45 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite.    Para ser contado, el DET debe entrar o salir de la aplicación, es decir, un campo que sea utilizado internamente y que no entre o salga de la aplicación no es contado como DET. Las etiquetas, nombres de campo, nombres de columna y variables de sistema como (fecha de sistema, número de página, número de columna, etc.) no son contados. En aplicaciones on-line, se cuenta 1 DET para la capacidad de ejecución sin importar de cuantas formas distintas se pueda ejecutar el proceso elemental. Por ejemplo, si se puede ejecutar la función de “Insertar empleado” presionando el botón “Guardar” o presionando Ctrl-G o dando clic en una opción de menú, sólo se cuenta un DET por la capacidad  para ejecutar dicha función. En aplicaciones on-line, se cuenta 1 DET para la capacidad de envío de mensajes, sin importar cuantos mensajes sean enviados dentro de la misma función transaccional. Por ejemplo, en la función “Insertar empleado”, por ejemplo, podrían hacerse diversas validaciones sobre cada uno de los datos capturados (longitud del campo, formato de la fecha, etc.), sin importar cuantas validaciones sean realizadas, sólo se contará un DET por la capacidad de generar  mensajes en dicha función transaccional. Contar los drop-downs (combo boxes) como procesos elementales. Contar 1 DET por la capacidad de ejecución (cuando se presiona la flechita y se despliega el combo box) y un DET por dato mostrado en el combo (se cuentan los campos, no los registros. Normalmente será un DET – campo por combo box). 3.7.6.6 RETs (Record Element Types) Son los subgrupos de datos en el mismo almacenamiento y que son identificables por el usuario, cuando en el almacenamiento no hay subgrupos de datos, se considera que el almacenamiento tiene un solo RET. Ayudan a identificar la complejidad de un almacenamiento lógico. 3.7.6.7 FTRs (File Type Referenced) Son las funciones de datos que son mantenidas y/o referenciadas por una función transaccional. 3.7.6.8 Proceso elemental Es la unidad mínima de actividad significativa al usuario, que deja al negocio en un estado consistente y es autocontenido. 3.7.6.9 Función transaccional Es un tipo particular de proceso elemental que se define con base en las responsabilidades que le son asignadas. La complejidad de las funciones transaccionales depende del número de DETs y FTRs. 3.7.6.10 EI (External Input) Es un tipo de función transaccional. Si el propósito principal de la función es recibir información para administrar (crear, modificar, eliminar) un almacenamiento, el tipo de función será EI. 46 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.7.6.11 EQ (External Inquiry) Es un tipo de función transaccional. Si el propósito principal fuera sólo presentar información y no realizar algún procesamiento adicional, la función es clasificada como EQ. 3.7.6.12 EO (External Output) Es un tipo de función transaccional. Si el propósito principal es presentar información y además realizar algún procesamiento adicional (como cálculos matemáticos, derivación de datos, etc.) entonces la función se clasifica como un EO. 3.7.6.13 Factor de ajuste El factor de ajuste (VAF - value adjustment factor) puede aumentar o disminuir el valor de los puntos de función en un +/- 35%. Las características evaluadas para determinar el valor de ajuste se refieren a requerimientos o restricciones no funcionales, como: comunicaciones de datos, actualización online, complejidad de procesamiento, facilidad de instalación, etc. Si la calificación de estos factores ambientales es el mínimo, el valor de ajuste será 0.65. Por el contrario, si los factores ambientales son los más complicados, el valor de ajuste será 1.35. El valor del factor de ajuste está basado en 14 características generales del sistema (GSCs - General System Characteristics) que califican la funcionalidad general de la aplicación que se está contando. Cada característica tiene descripciones asociadas que ayudan a determinar los grados de influencia de dichas características. Los grados de influencia varían en una escala de cero a 5, desde "ninguna influencia" hasta "fuerte influencia". 3.8 Uso de información histórica para mejorar las estimaciones 3.8.1 Introducción Un elemento clave para mejorar las estimaciones siempre será la información histórica real que represente el desempeño de un proyecto. Para poder emplear información histórica y mejorar las estimaciones se vuelve imperante recolectar la información necesaria durante un proyecto. Dicha información no solamente servirá como entrada al proceso de estimaciones, sino que muy seguramente representará información útil para medir el desempeño de un proyecto durante sus procesos de monitoreo y control. Aunque un objetivo inicial pudiera ser mejorar las estimaciones a nivel individual, en algún momento será necesario contar con información a nivel proyecto, e inclusive a nivel de cartera de proyectos con el objetivo de monitorear y controlar los costos (duración y esfuerzo) de dichos proyectos. Es aquí cuando la estandarización, de procesos y herramientas, se vuelve relevante y otro elemento clave en la ecuación. Esta sección presenta un modelo ya probado que permite la recolección y almacenamiento de información en proyectos para que pueda ser empleada como entrada para nuevas estimaciones. 47 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 3.8.2 Un modelo para obtener información histórica en proyectos de software 3.8.2.1 Introducción Como ya se mencionó anteriormente, el uso de información histórica es clave para mejorar las estimaciones de proyectos de software. En esta sección se presenta un modelo probado que permite la recolección y uso de información de tamaño, duración, esfuerzo y costo de aplicaciones y proyectos para que, además de ser usada como información histórica, permita incrementar el conocimiento de la organización, principalmente en el desempeño de sus proyectos. 3.8.2.2 Modelo A continuación se presenta el modelo propuesto para recolectar, almacenar y emplear información histórica de proyectos: Ilustración 12 - Modelo de recolección, almacenamiento y uso de información histórica para estimaciones A continuación se describen algunos de los elementos clave del modelo:  Estimación o Representa la información de tamaño, duración, esfuerzo y costo aproximados de un nuevo proyecto o aplicación. o  Emplea, para fines comparativos o de generación de nueva información, la información histórica almacenada en el repositorio organizacional de métricas. Proyecto 48 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. o Durante éste se recolecta la información necesaria real acerca de su duración, esfuerzo y costo, así como del tamaño de la aplicación. o  esfuerzo y costo, comparado con lo originalmente estimado. Registro de métricas del proyecto o  Este registro contiene la información consolidada, y probablemente detallada, de la duración, esfuerzo y costo del proyecto, así como del tamaño de la aplicación. Repositorio organizacional de métricas o  Durante el proyecto también se genera la planeación, que permite tener mayor detalle acerca de la duración, Contiene la información consolidada de duración, esfuerzo y costo de todos los proyectos de la organización, así como el tamaño de todas las aplicaciones generadas o modificadas. Herramienta de registro de horas (timesheet) o Permite el registro de las horas dedicadas a alguna actividad, que a su vez, una vez que se sumen, representarán las horas dedicadas a un entregable y, estas a su vez, representarán las horas dedicadas a una fase; así entonces, la suma de las horas dedicadas a una fase representarán las horas dedicadas al  proyecto. Para comprender mejor lo anteriormente mencionado, vea la siguiente figura. Cronograma (y su estructura jerárquica) o Además de que contiene la programación de actividades del proyecto, al final del mismo contendrá la información real de avance, duración y probablemente esfuerzo y costo de todo el proyecto (siempre y cuando se haya mantenido actualizado). o Para poder asegurar el uso de la información de duración, esfuerzo y costo en futuras estimaciones, se sugiere que se estandarice la estructura jerárquica (WBS – Work Breakdown Structure) de los cronogramas,  tal y como se muestra en la siguiente ilustración. Aplicación o La aplicación construida o modificada aportará el tamaño real de la misma al finalizar el proyecto. Para poder conocer el tamaño de la aplicación habrá que emplear algún método como por ejemplo el análisis de  puntos de función. Sistema de costos estándar o El sistema de costos estándar, contablemente hablando, es el sistema empleado por la organización para determinar los costos originados por la producción (desarrollo) del software o de cualquier otro producto o servicio que ofrezca la empresa. El siguiente diagrama representa la estructura jerárquica propuesta para estandarizar los cronogramas, así como la herramienta de registro de actividades (timesheet). Es importante que ambas herramientas (cronograma y timesheet) estén construidos bajo la misma estructura para asegurar la integridad y homogeneidad de la información a lo largo del ciclo de vida de los proyectos y la organización en sí. 49 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Ilustración 13 - Estructura jerárquica propuesta para estandarización de cronogramas y timesheet 3.8.2.3 Proceso de implementación del modelo A continuación se presenta un proceso que permite implementar un modelo que facilita la recolección, almacenamiento y uso de información del desempeño de proyectos y aplicaciones. Insumos (entradas) Actividades - Procesos de desarrollo de 1. Estandarizar 3 los procesos relacionados con el desarrollo de software Información de software de la empresa 2. Estandarizar la herramienta para recolección de horas en proyectos tamaño, (timesheet) duración, 3. Estandarizar la estructura jerárquica de los cronogramas esfuerzo y costo 4. Elaborar cronogramas con base en la estructura jerárquica del proyecto - Estructura jerárquica de cronogramas Productos estandarizada 5. Recolectar información de horas en la herramienta estandarizada de recolección de horas (timesheet) Para efectos de este proceso, estandarizar significa definir e implementar, a nivel organización, y luego usar, a nivel proyecto, el elemento mencionado. 3 50 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 6. Registrar, durante o al finalizar cada proyecto, la información consolidada real de tamaño (de la aplicación), duración (del proyecto), esfuerzo y costo. 7. Almacenar la información consolidada real de tamaño, duración, esfuerzo y costo. 8. Analizar y emplear la información consolidada real de proyectos. Herramientas - Herramienta de registro de horas (timesheet) Roles Responsables de procesos Administradores de proyectos Miembros de equipos de proyectos Gerente de desarrollo u oficina de proyectos 51 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. 4. Glosario Actividad (1) Serie de pasos llevados a cabo para ejecutar un proceso. (ABPMP, 2009) (2) Un componente de trabajo llevado a cabo durante el curso de un proyecto. (PMI, 2008) (3) Trabajo que una compañía u organización lleva a cabo usando procesos de negocio. Una actividad puede ser atómica o no atómica (compuesta). Los tipos de actividades que son parte de un modelo de procesos son: procesos, subprocesos y tareas. (OMG, 2011) (4) Unidad tangible de trabajo realizada por un trabajador en un flujo de trabajo, de forma que implica una responsabilidad bien definida para el trabajador, produce un resultado bien definido (un conjunto de artefactos) basado en una entrada bien definida (otro conjunto de artefactos), y representa una unidad de trabajo con límites bien definidos a la que, probablemente se refiera el plan de proyecto al asignar tareas a los individuos. También puede verse como la ejecución de una operación por un trabajador. (Jacobson, Booch, & Rumbaugh, 2000) Aplicación Ver Software de aplicación. Ciclo de vida (de proyecto) (1) Una colección de fases de proyecto, generalmente secuenciales, cuyo nombre y número son determinados por las necesidades de control de la organización u organizaciones involucradas en el proyecto. Un ciclo de vida puede ser documentado con una metodología. (PMI, 2008) (2) Una partición de la vida de un producto, servicio, proyecto, grupo de trabajo o conjunto de actividades de trabajo en fases. (SEI, 2010) Ciclo de vida (del software) (1) El periodo que comienza cuando un producto de software es concebido y concluye cuando el software ya no está disponible para su uso. El ciclo de vida del software típicamente incluye las siguientes fases: concepto, requerimientos, diseño, implementación, pruebas, instalación, operación y mantenimiento, en algunas ocasiones se incluye una fase de descontinuación. Estas fases pueden traslaparse o ser ejecutadas iterativamente. (IEEE, 1990) (2) Ciclo que cubre cuatro fases en el siguiente orden: inicio, elaboración, construcción y transición. (Jacobson, Booch, & Rumbaugh, 2000) Cliente (1) Persona que utiliza con asiduidad los servicios de un profesional o empresa. (RAE, 2012) (2) La parte responsable de aceptar el producto o autorizar un pago. El cliente es externo al proyecto o grupo de trabajo pero no necesariamente externo a la organización. El cliente puede ser un proyecto o grupo de trabajo de más alto nivel. Los clientes son un subconjunto del grupo de interesados en el proyecto. (SEI, 2010) 52 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. (3) Persona, organización o grupo de personas que encarga la construcción de un sistema, ya sea empezando desde cero, o mediante el refinamiento de versiones sucesivas. (Jacobson, Booch, & Rumbaugh, 2000) Componente Una parte física y reemplazable de un sistema que se ajusta a, y proporciona la realización de, un conjunto de interfaces. (Jacobson, Booch, & Rumbaugh, 2000) Costo El costo es la cantidad que se da o se paga por algo. (RAE, 2012) Defecto (1) Imperfección en algo o en alguien. (RAE, 2012) (2) Carencia de alguna cualidad propia de algo. (RAE, 2012) (3) Una imperfección o deficiencia en un componente de un proyecto en la cual dicho componente no cumple sus requerimientos o especificaciones y necesita ser corregido o reemplazado. (PMI, 2008) (4) Anomalía del sistema, por ejemplo un síntoma de un error en el software descubierto durante las pruebas, o un problema descubierto durante una reunión de revisión. (Jacobson, Booch, & Rumbaugh, 2000) Duración El número total de periodos de trabajo (sin incluir días festivos u otros periodos no laborables) requerido para completar una actividad programada o un componente de una estructura de desglose de trabajo. Usualmente expresada como días o semanas laborables. (PMI, 2008) Entrada Cualquier elemento, interno o externo al proyecto que es requerido por un proceso antes de que el proceso proceda. Puede ser una salida de un proceso predecesor. (PMI, 2008) Ver también: Insumo. Entregable Cualquier producto único y verificable, resultado o capacidad para llevar a cabo un servicio que debe ser producido para completar un proceso, fase o proyecto. A menudo usado más estrechamente en referencia a un entregable externo, que es un entregable que está sujeto a aprobación del patrocinador o cliente del proyecto. (PMI, 2008) Un elemento que será provisto a un adquiriente u cualquier otro recipiente designado tal como fue especificado en un acuerdo. El elemento puede ser un documento, elemento de hardware, elemento de software, servicio o cualquier tipo de producto de trabajo. (SEI, 2010) 53 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Error (1) Acción desacertada o equivocada. (RAE, 2012) (2) Una acción humana que produce un resultado incorrecto. (IEEE, 1990) (3) La diferencia entre un valor o condición computado, observado o medido y la condición o valor verdadero, especificado o teóricamente correcto. Por ejemplo, una diferencia de 30 metros entre un resultado computado y el resultado correcto. (IEEE, 1990) (4) Un resultado incorrecto. Por ejemplo, un resultado computado de 12 cuando el resultado correcto es 10. (IEEE, 1990) Esfuerzo El número de unidades de trabajo requeridas para completar una actividad programada o un componente de una estructura de desglose de trabajo. Usualmente expresado como horas/hombre, días/hombre o semanas/hombre. (PMI, 2008) Fase (de proyecto) (1) Una colección de actividades de un proyecto relacionadas lógicamente, usualmente culminando en la conclusión de un entregable importante. Las fases de un proyecto son concluidas principalmente de forma secuencial, pero pueden empalmarse en algunas situaciones del proyecto. Una fase de proyecto es un componente del ciclo de vida del proyecto. (PMI, 2008) (2) Periodo de tiempo entre dos hitos principales de un proceso de desarrollo. (Jacobson, Booch, & Rumbaugh, 2000) Hito (1) Un punto o evento significativo en el proyecto. (PMI, 2008) (2) Punto en el que han de tomarse importantes decisiones de negocio. Punto de sincronización en el que coinciden una serie de objetivos bien definidos, se completan artefactos, se toman decisiones de pasar o no a la fase siguiente, y en el que las esferas técnica y de gestión entran en conjunción. (Jacobson, Booch, & Rumbaugh, 2000) Indicador Un dispositivo o variable que puede ser configurada con un estado prescrito con base en los resultados de un proceso o la ocurrencia de una condición especificada. Por ejemplo, una bandera o semáforo. (IEEE, 1990) Instrumento o herramienta Producto que facilita el trabajo durante la ejecución de un proceso. Insumo Producto requerido para ejecutar un proceso. Ver también: Entrada. 54 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Interfaz (1) Un límite compartido a través del cual la información es pasada. (IEEE, 1990) (2) Un componente de hardware o software que conecta dos o más componentes con el propósito de pasar información de uno a otro. (IEEE, 1990) (3) Conectar dos o más componentes con el propósito de pasar información de uno a otro. (IEEE, 1990) (4) Servir como un componente conectado o para conectar tal como se especifica en (2). (IEEE, 1990) Iteración (1) El proceso de llevar a cabo una secuencia de pasos repetidamente. (IEEE, 1990) (2) Una sola ejecución de la secuencia de pasos en (1). (IEEE, 1990) (3) Conjunto de actividades llevadas a cabo de acuerdo a un plan (de iteración) y unos criterios de evaluación, que lleva a producir una versión, ya sea interna o externa. (Jacobson, Booch, & Rumbaugh, 2000) Medición Acción y efecto de medir. (RAE, 2012) Un conjunto de operaciones para determinar el valor de una medida. (SEI, 2010) Medida Expresión del resultado de una medición. (RAE, 2012) Variable a la cual se le asigna un valor como resultado de una medición. (SEI, 2010) Métrica (1) Una medida cuantitativa del grado en el cuál un sistema, componente o proceso posee un determinado atributo. (IEEE, 1990) (2) Perteneciente o relativo al metro. (RAE, 2012) Modelo (1) Arquetipo o punto de referencia para imitarlo o reproducirlo. (RAE, 2012) (2) Representación en pequeño de alguna cosa. (RAE, 2012) (3) Esquema teórico, generalmente en forma matemática, de un sistema o de una realidad compleja, como la evolución económica de un país, que se elabora para facilitar su comprensión y el estudio de su comportamiento. (RAE, 2012) (3) Una abstracción de un sistema cerrada semánticamente. (Jacobson, Booch, & Rumbaugh, 2000) 55 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Patrón Solución a un problema común de un determinado contexto. (Jacobson, Booch, & Rumbaugh, 2000) Proceso (1) Un conjunto definido de actividades o comportamientos llevados a cabo por humanos o máquinas para alcanzar uno o más objetivos. (ABPMP, 2009) (2) Una secuencia de pasos llevados a cabo para un propósito dado. (IEEE, 1990) (3) Una secuencia o flujo de actividades en una organización con el objetivo de llevar a cabo trabajo. (OMG, 2011) (4) Un conjunto de actividades interrelacionadas, las cuales transforman salidas en entradas, para cumplir un propósito dado. (SEI, 2010) (5) Un flujo de control pesado que puede ejecutarse concurrentemente con otros procesos. Proceso de negocio (1) Trabajo llevado a cabo de principio a fin que entrega valor a los clientes. (ABPMP, 2009) (2) Un conjunto definido de actividades de negocio que representa los pasos requeridos para alcanzar un objetivo de negocio. Incluye el flujo, uso de información y recursos. (OMG, 2011) (3) Conjunto total de actividades necesarias para producir un resultado de valor percibido y medible para un cliente individual de un negocio. (Jacobson, Booch, & Rumbaugh, 2000) Producto (1) Cosa producida. (RAE, 2012) (2) Un artefacto que es producido, es cuantificable y puede ser un elemento final o un componente. (PMI, 2008) Ver también: Salida. Programa de computadora Una combinación de instrucciones de computadora y definiciones de datos que permiten al hardware de computadora llevar a cabo funciones computacionales o de control. (IEEE, 1990) Proyecto (1) Es un esfuerzo temporal realizado para crear un producto, servicio o resultado únicos. (PMI, 2008) (2) Esfuerzo de desarrollo para llevar un sistema a lo largo de un ciclo de vida. (Jacobson, Booch, & Rumbaugh, 2000) La naturaleza temporal de los proyectos indica un inicio y un fin definidos. El fin es alcanzado cuando los objetivos del proyecto han sido alcanzados o cuando el proyecto es terminado puesto que sus objetivos no pueden o no podrán ser cumplidos, o cuando la necesidad de continuar el proyecto ya no exista. (PMI, 2008) 56 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Riesgo Variable de un proyecto que pone en peligro o impide su éxito. (Jacobson, Booch, & Rumbaugh, 2000) Rol (1) Una función definida para ser llevada a cabo por el miembro de un equipo de proyecto, tal como prueba, inspección, codificación. (PMI, 2008) (2) El comportamiento específico de una entidad que participa en un contexto particular. Salida Un producto, resultado o servicio generado por un proceso. Puede ser una entrada para un proceso sucesor. (PMI, 2008) Ver también: Producto. Servicio Un producto que es intangible y no almacenable. (SEI, 2010) Los servicios son entregados a través del uso de sistemas de servicios que han sido diseñados para satisfacer requerimientos de servicio. (SEI, 2010) Muchos proveedores de servicios entregan combinaciones de servicios y bienes. Un sistema de servicios puede entregar ambos tipos de productos. (SEI, 2010) Los servicios pueden ser entregados a través de combinaciones de procesos manuales y automatizados. (SEI, 2010) Sistema (1) Conjunto de cosas que relacionadas entre sí ordenadamente contribuyen a determinado objeto. (RAE, 2012) (2) Una colección de subsistemas organizados para llevar a cabo un propósito específico y descritos por un conjunto de modelos, posiblemente desde distintos puntos de vista. Sistema computacional Un sistema que contiene una o más computadoras y software asociado. (IEEE, 1990) Software Es el conjunto de programas de computadora, procedimientos, datos y documentación asociada pertenecientes a la operación de un sistema computacional. (IEEE, 1990) 57 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. Software de aplicación (1) Software diseñado para cumplir con necesidades específicas de un usuario, por ejemplo, software de nómina, recursos humanos o ventas. (IEEE, 1990) (2) Sistema que ofrece a un usuario final un conjunto coherente de casos de uso. (Jacobson, Booch, & Rumbaugh, 2000) También conocido como LOB, Line of Business Application. Subproceso Un proceso que está incluido dentro de otro proceso. (OMG, 2011) Tarea (1) Actividad con inicio y fin definidos. (2) Una actividad atómica que está incluida dentro de un proceso. Una tarea es usada cuando el trabajo en el proceso no es descompuesto para obtener un nivel más fino de detalle en el modelado del proceso. Generalmente, un usuario final, una aplicación o ambos llevarán a cabo la tarea. (OMG, 2011) Patrocinador La persona o grupo que provee los recursos financieros, en efectivo o especie, para el proyecto. (PMI, 2008) Usuario (final) (1) Una de las partes que emplea un producto entregado o que recibe el beneficio de un servicio entregado. Los usuarios finales también pueden, o no, ser clientes. (SEI, 2010) (2) Humano que interactúa con un sistema. (Jacobson, Booch, & Rumbaugh, 2000) 5. Referencias ABPMP. (2009). Guide to the Business Process Management Common Body of Knowledge (BPM CBOK) Version 2.0. Chicago: Association of Business Process Management Professionals. Barker, C. (2007, 11 22). The top 10 IT disasters of all time. Retrieved from ZDNet: http://www.zdnet.com/the-top-10-itdisasters-of-all-time-3039290976/ Booch, G., Rumbaugh, J., & Jacobson, I. (2006). El lenguaje unificado de modelado. Pearson Education. Calleam Consulting Ltd. (2012, 11 20). Denver Airport Baggage System Case Study. Retrieved from Why Projects Fail: http://calleam.com/WTPF/?page_id=2086 Domínguez, J. (2012, 11 16). The Curious Case of the CHAOS Report 2009. Retrieved from ProjectSmart.co.uk: http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html Gary, K. P. (2003). Fundamentos de Marketing, Sexta Edición. Prentice Hall. 58 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. IBM. (2013, 04 16). RUP: Best practices for design, implementation and effective project management. Retrieved from IBM Web Site: http://www-01.ibm.com/software/rational/rup/ IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology. New York: The Institute of Electrical and Electronics Ehgineers. IFPUG. (2012, 11 22). About Function Point Analysis. Retrieved from International Function Point Users Group: http://www.ifpug.org/?page_id=10 IVEX. (2007). El mercado del software en México. Ciudad de México: Instituto Valenciano de la exportación. Jacobson, I., Booch, G., & Rumbaugh, J. (2000). El proceso unificado de desarrollo de software. Madrid, España: Addison Wesley. Karl T. Ulrich, S. D. (2009). Diseño y desarrollo de productos, cuarta edición. Mc Graw Hill. KUALI-KAANS. (2013, 04 04). KUALI-BEH. Retrieved from KUALI-KAANS: http://www.kuali-kaans.mx/proyectos/kuali-beh Lamb Charles, H. J. (2002). Marketing, Sexta Edición. International Thomson Editores S.A. McConnell, S. (1996). Chapter 2: Rapid-Development Strategy. In S. McConnell, Rapid Development (Taming Wild Software Schedules) (p. 22). Redmond, Washington: Microsoft Press. McConnell, S. (1996). Rapid Development (Taming Wild Software Schedules). Redmond, Washington: Microsoft Press. McConnell, S. (1998). Software Project Survival Guide. Redmond, Washington: Microsoft Press. McConnell, S. (2006). Software Estimation (Demystifying the Black Art). Redmond, Washington: Microsoft Press. Oktaba, H. (2010, 03 07). Historia estándar ISO/IEC 29110. Retrieved from ISO/IEC 29110: http://iso29110.kualikaans.mx/iso29110/index.php?option=com_content&view=section&layout=blog&id=3&Itemid=8&lang=es OMG. (2011). A Foundation for the Agile Creation and Enactment of Software Engineering Methods. Needham, MA: OMG. OMG. (2011). Business Process Model and Notation (BPMN). Needham, MA: Object Management Group. Pareja Quinaluisa, J. F. (2012, 02 08). Evaluación de procesos de software utilizando EvalProSoft aplicado a un caso de estudio. Retrieved from Escuela Politécnica Nacional: http://bibdigital.epn.edu.ec/handle/15000/4491 PMI. (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition. Pennsylvania: Project Management Institute, Inc. RAE. (2012, 11 08). Diccionario de la lengua española. Retrieved from Real Academia Española: http://www.rae.es Richard, S. L. (2002). Mercadotecnia, Primera Edición. Compañía Editorial Continental. Rubinstein, D. (2007, 3 1). Standish Group Report: There's Less Development Chaos Today. Retrieved from SD Times: http://www.sdtimes.com/content/article.aspx?ArticleID=30247 Secretaría de economía. (2012, 11 13). Capital humano - estimación del capital humano de las personas. Retrieved from Sistema nacional de indicadores de la industria de tecnologías de información: http://www.edigital.economia.gob.mx/capital%20humano.htm Secretaría de economía. (2012). Ejercicio de Rendición de Cuentas a la Sociedad PROSOFT 2012. Ciudad de México: Secretaría de economía. Secretaría de economía. (2012, 11 13). Mercado nacional. Retrieved from Sistema nacional de indicadores de la industria de tecnologías de información: http://www.edigital.economia.gob.mx/MNACIONAL.htm 59 Este material es propiedad de Rogelio Francisco Ramírez Ramírez y no puede ser distribuido, reproducido o comercializado sin el consentimiento expreso de su autor. Registro de obra en trámite. SEI - Software Engineering Institute. (2013, 04 16). Team Software Process - A Performance Framework for Software Development. Retrieved from SEI Web Site: http://www.sei.cmu.edu/library/upload/TSPoverview.pdf SEI - Software Engineering Institute. (2013, 04 16). The Personal Software Process (PSP). Retrieved from SEI Web Site: http://www.sei.cmu.edu/library/abstracts/reports/00tr022.cfm SEI. (2010). CMMI for Acquisition, Version 1.3 (CMU/SEI-2010-TR-032). Hanscom AFB, MA: Software Engineering Institute. SEI. (2010). CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033). Hanscom AFB, MA: Software Engineering Institute. SEI. (2010). CMMI for Services, Version 1.3 (CMU/SEI-2010-TR-034). Hanscom AFB, MA: Software Engineering Institute. Stanton William, E. M. (2004). Fundamentos de Marketing, 13va. Edición. Mc Graw Hill. The Standish Group. (1995). Chaos Report. The Standish Group. Villalobos Hernández, M., & Gutiérrez Tornés, A. (2001). Investigación sobre las prácticas de ingeniería de software. Ciudad de México: CIC-IPN. Wikipedia. (2012, 10 24). Lean IT. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Lean_IT 60