Práctica de Estimaciones (Ingeniería II)
Sección I – De ojos y buenos cuberos
1.
¿Cuántos círculos como el señalado abajo entran en cada una de las figuras? ¿Aplicó alguna técnica para llegar a las respuestas? (a) (b) (c)
(a) 16 (b) 28 (c) 38
2.
Estime el área que suman de las siguientes figuras.
Consejo: estime primero el área de las figuras más regulares y más pequeñas. Luego proyecte esas estimaciones sobre las figuras más complejas. Finalmente sume todas las estimaciones.
Las figuras componen un cuadrado de 25x25 ⇒ el área total es de 625 unidades.
Sección II – Conceptos generales
1.
¿Para qué sirve estimar un proyecto de desarrollo de software? ¿Qué información se obtiene?
Estimar un proyecto sirve para tener una idea inicial de cuanto nos va a costar en cuanto a esfuerzo, dinero, tiempo, etc. Ademas con la estimacion se mide productividad, cambios , etc.
2.
¿Qué tareas involucradas en el desarrollo de software debería incluir la estimación?
La estimacion por si sola es una tarea que es parte del proyecto. Se debe estimar todo el ciclo de vida del projecto, esto incluye desde el proceso de elicitacion de requerimientos hasta la parte final de instalacion. En RUP por ejemplo se estima la duracion de cada iteracion, y dentro de cada una se estima el costo de las distintas diciplinas (workflows) que se realizan.
3.
¿En qué consiste una estimación top-down o por analogías? ¿En qué contextos es útil?
La estimación Top-Down es una técnica de estimación que calcula el programa entero, costo y esfuerzo usando parámetros amplios. Los parámetros amplios y las comparaciones están basados en datos históricos usando técnicas estimativas de Analogía. El Consejo de Expertos se obtiene de expertos con experiencia en proyectos similares o experiencia en el uso de puntos función. Util en contextos en donde se dispone de proyectos anteriores de similares características.
4.
¿En qué consiste una estimación bottom-up o por descomposición? ¿En qué contextos es útil?
Descomposición.
(1) Descomponer, (2) Estimar cada parte, (3) Sumar, ajustar y contar el costo de las uniones. En resumen, descomoponer en cosas mas sencillas, estimar las partes mas sencillas y luego hacer merge de las estimaciones (divide & conquer)
5.
Describa similitudes y diferencias entre los métodos de Clark y Wideband Delphi.
Método de Clark:
- Descomposicion. Dividir al sistema en módulos. Estimar para cada modulo valor optimista, pesimista y medio. Merge de estimaciones.
WidebandDelphi:
- Analogia. (Basado en experiencia de los involucrados).
- Se junta a los involucrados, se les introduce la tecnica. Luego se van juntando las distintas mediciones hasta de los distintos expertos hasta lograr un punto medio. (Todo anonimo)
Similitudes: Ambos intentan lograr un punto medio entre estimaciones “optimistas” y “pesimistas”.
Diferencias: Clark es top-down y Wideband Delphi es bottom-up.
6.
¿Qué ventajas y desventajas tienen los métodos algorítmicos?
Métodos Algorítmicos. Usar un algoritmo que toma datos del sistema(e.g. funcionalidades, pantallas, inputs...) y factores de ajuste por complejidad y devuelve un número.
Tienen la ventaja de ser mas rapidos, mecanicos y automatizados para hacer estimaciones. A la vez pueden ir cambiando automaticamente (acorde a lo estimado inicialmente) las estimaciones a medida que hay cambios en el proyecto de manera automatica.
Las desventaja principal es que se basan en cuestiones estaticas como cantidad de funcionalidades, inputs, etc. y hay veces que hay otros factores que son difíciles para que sean tenido en cuenta en estas estimaciones como puede ser que se quiera usar una tecnologia con licencias pero estas licencias tardan mucho tiempo en ser entregadas, y casos de esa indole. Tambien es difícil estimar de manera generica una complejidad para una funcionalidad, o solo tener en cuenta la cantidad de inputs. Cada proyecto puede tener suficientes particularidades como para no poder ser evaluado genericamente como estas tecnicas pretenden.
7.
Enumere algunos factores no funcionales (no asociados a los casos de uso) que puedan afectar el resultado una estimación.
Atributos de calidad, tecnologias a utilizar, restricciones, stakeholders, experiancia de los arquitectos, referencia de projectos similares, experiencia de expertos en el dominio.
8.
Explique el ciclo dorado de la estimación.
Estimo -> Mido -> Registro -> Comparo -> Analizo -> Calibro -> Estimo…
Estimar, medir cuanto tardo realmente, comparar la realidad con lo estimado, analizar las cosas que se estimaron mal (que errores hubo), calibrar el metodo de estimacion para volver a estimar, y volver a hacer una proxima estimacion que se espera mas precisa.
9.
¿Qué métodos de estimación le parecen adecuados en cada uno de los siguientes contextos?
- a. Una organización que nunca registró ningún tipo de métricas ni hizo estimaciones.
- b. Una organización que siempre se manejó con estimaciones empíricas.
- c. Una organización que siempre se manejó con estimaciones empíricas pero que está en expansión (el número de integrantes está creciendo así como la cantidad de proyectos en carpeta).
- d. Una organización que tiene métricas de tiempos y costos de los proyectos que ejecutó durante los últimos cinco años.
Metodos algoritmicos.
- Bottom-up. Seguir haciendo analogias.
- Top-down. Intentar descomponer las distintas tareas, y luego usar estimaciones empiricas sobre esas porciones mas pequeñas.
- Usar analogias con los datos y las metricas que ya se tienen.
Sección III – Ejercicios prácticos
1.
Busca-minas a. Estime, usando el método que le parezca más adecuado, el tiempo que le llevaría a usted desarrollar la aplicación “Busca-minas” (*) con exactamente las mismas funcionalidades y características que el original. b. Ahora estime el tiempo necesario para desarrollar la misma aplicación, con las mismas funcionalidades, pero para correr desde un navegador.
(*) Minesweeper es uno de los clásicos juegos que incluye Windows.
2.
Sistema de inscripciones Se necesita realizar una modificación en el sistema de inscripciones de la facultad. Informalmente, los requerimientos de cambio son: - Agregar la información de la cantidad de horas semanales de las materias en la grilla de inscripciones - Modificar la dirección de correo mediante la que se realizan las inscripciones a finales - Generar y enviar un mail a la cuenta del alumno que se está inscribiendo con los datos de la inscripción a cada una de las materias (turnos, estado en que se encuentra el alumno, cuatrimestre, año, etc.). - Cambiar el look&feel general de la aplicación (agregar imágenes, mejorar los estilos de la página, etc.).
a. Realice una estimación usando el método de “ojo de buen cubero” de los cambios. b. Realice una estimación con el método de Clark. c. Realice una estimación usando el método Wideband Delphi con sus compañeros de grupo de TP. d. ¿Encontró diferencias entre las distintas estimaciones? ¿A qué se deben?
3.
Sistema de seguimiento de incidentes Una compañía de ingeniería de software está analizando la posibilidad de desarrollar su propio sistema Web de seguimiento de incidentes, cuyo diagrama de clases se esboza a continuación.
Las principales funcionalidades serían:
o ABM de proyectos, recursos, componentes y versiones.
o Asignaciones de recursos a proyectos.
o Creación de incidentes.
o Asignación de un incidente a los recursos responsables de
solucionarlo.
o Cambiar el estado de un incidente. Las siguientes transiciones son
posibles:
iniciado → en proceso (lo toma al menos un responsable)
iniciado → cerrado (se desestima el incidente)
en proceso → resuelto (se termina la tarea de desarrollo)
resuelto → verificado (el test es satisfactorio)
resuelto → iniciado (el test no es satisfactorio)
verificado → cerrado (se completa el trabajo)
o Envío de mails a los responsables de cada incidente ante cada cambio de estado. o Consultas de incidentes, filtrando por proyecto, componente, versión, recurso, estado y prioridad.
a. Considerando que se desea tener disponible una versión del producto completamente productiva (sin defectos graves) en a lo sumo un mes, dimensione el equipo de desarrollo y los recursos necesarios. Especifique todas las suposiciones que sean relevantes. b. Para una segunda etapa, se desea agregar la posibilidad de registrar una estimación de esfuerzo asociada a cada incidente y luego imputar el esfuerzo real que le dedicó cada recurso, para luego generar un gráfico de evolución. Estime el tiempo que llevará realizar el cambio en el sistema, considerando el mismo equipo que trabajó en la primera versión del producto.
4.
Sistema para la AFIP El departamento de Control de Evasión de la AFIP desea construir una herramienta que le permita a un analista visualizar fácilmente el flujo de dinero entre distintas cuentas bancarias e investigar así una gran variedad de casos de fraude impositivo. Se espera que un analista pueda ingresar en esta herramienta una lista de cuentas bancarias consideradas sospechosas y presuntamente vinculadas entre sí para que el sistema muestre en un grafo las relaciones directas e indirectas que existen entre ellas. En este grafo, los nodos representan cuentas y los arcos (dirigidos) representan transferencias de dinero entre las cuentas. Los analistas saben que en muchos casos las transferencias no se realizan directamente entre las partes involucradas, sino que el dinero pasa por una serie de cuentas intermedias, para dificultar las eventuales investigaciones. Resolver estas dificultades constituye el principal beneficio de la herramienta. Además, sabiendo que la cantidad de cuentas relacionadas podría ser demasiado grande, se desea que el grafo muestre únicamente aquellas cuentas que forman parte de un camino entre las cuentas sospechosas originales. Como fuente principal de información, la AFIP recibe diariamente, de un grupo de bancos adheridos al Programa de Control de Evasión, el detalle de todas las transacciones realizadas en el día. Estos bancos concentran el 85% de las transacciones en el país. El formato, estandarizado para todas las entidades bancarias, consta de un archivo de texto plano en el que cada registro representa una transacción bancaria realizada por una cuenta. Incluye los siguientes campos: CBU (identificación unívoca de la cuenta). Tipo de cuenta (caja de ahorro / cuenta corriente). Fecha y hora de la transacción. Tipo de transacción. (*) Moneda (pesos o dólares). Ingreso. (**) Egreso. (**) Saldo de la cuenta al concretarse la transacción. CBU adicional. (***) (*) Si bien existen muchos tipos de transacción, estos se han agrupado en tres categorías: Ingreso. Cualquier operación que implique ingresar dinero en efectivo al sistema bancario. Extracción. Cualquier operación que implique extraer dinero en efectivo del sistema bancario. Transferencia. Cualquier operación mediante la cual se pasa dinero de una cuenta a otra (depósitos de cheques, pagos electrónicos, transferencias electrónicas, etc.).
(**) En todo registro, al menos uno de los campos ingreso o egreso tiene el valor 0.- (***) El CBU adicional es válido sólo cuando se trata de una transferencia. En estos casos debería haber también otro registro (quizás en otro archivo) que corresponda a la misma transacción, pero donde se invierten los roles de las cuentas adicional y principal. Este otro registro ciertamente puede no existir si la cuenta adicional no pertenece a ninguno de los bancos adheridos. Además de este archivo, cada banco provee un Web Service con el que AFIP puede obtener, a partir de un CBU, información general de la cuenta: tipo de cuenta, saldo, nombre y apellido del titular, CUIT/CUIL, DNI, dirección y teléfono de contacto. Asimismo, el BCRA provee otro Web Service con el que se puede obtener, a partir de un DNI, CUIT o CUIL, la lista todas las cuentas relacionadas detallando el banco, el tipo de cuenta, el CBU y el titular.
Algunos datos de magnitud (estos datos son provistos para el desarrollo del ejercicio; no necesariamente coinciden con la realidad): La cantidad de individuos bancarizados en Argentina es cercana a 10 millones. La cantidad de empresas que operan con bancos es cercana a 250 mil. La cantidad total de cuentas activas en toda la red bancaria se estima en 17 millones. Un individuo (contando todas sus cuentas) realiza en promedio 9 transacciones al mes, de las cuales 4 son transferencias. Una empresa (contando todas sus cuentas) realiza en promedio 100 transacciones al mes, de las cuales 80 son transferencias. El 20% de las empresas e individuos realizan el 80% de las transacciones. La mitad de las transacciones se realizan la primer semana de cada mes.
A continuación se esboza la operatoria esperada.
1) Al comenzar una investigación con la herramienta, el usuario establece un rango de fechas que determina el período dentro del cual se hacen las búsquedas. Este período no excede los 90 días y está dentro de los últimos dos años. 2) El usuario ingresa un conjunto de hasta 10 cuentas semilla. (buscándolas a partir del CBU, CUIT / CUIL o DNI). 3) El sistema busca los vínculos de primer y segundo orden de cada cuenta semilla (****). 4) Con todos los vínculos obtenidos, el sistema arma un grafo dirigido y le muestra al usuario sólo los nodos que forman parte de un camino. Este proceso no debería demorar más de 30 segundos. 5) El usuario puede seleccionar en el grafo cualquier cuenta y solicitar a) información adicional de la cuenta. b) un detalle de los movimientos registrados en el período. 6) El grafo debería considerar las siguientes particularidades: La distribución de los nodos debe ser estéticamente agradable (consultar http://en.wikipedia.org/wiki/Force-based_algorithms). El usuario debe poder distinguir visualmente las cuentas con mayor saldo. El usuario debe poder distinguir visualmente las transferencias de mayor monto.
(****) Dos cuentas están vinculadas en un período si entre ellas hay al menos una transferencia. Son vínculos de primer orden de una cuenta c todas aquellas cuentas que realizaron alguna transferencia con c (en cualquier sentido). Son vínculos de segundo orden de una cuenta c todas aquellas cuentas que, sin ser vínculos de primer orden de c, realizaron alguna transferencia (en cualquier sentido) con algún vínculo de primer orden de c.
Considerando todas las especificaciones anteriores, se pide:
a. Identifique los principales casos de uso. b. Estime el tamaño y esfuerzo de este sistema con Puntos de Casos de Uso (asuma una productividad de 20 horas por punto de caso de uso). No estime el esfuerzo de los Web Services provistos por los bancos adheridos y el BCRA. c. Determine cómo debería componerse un equipo de trabajo para construir una primera versión de la solución lo antes posible. ¿Qué funcionalidades resolvería primero? ¿cuáles dejaría para versiones posteriores? d. Confeccione un cronograma que muestre cuándo de desarrollará cada una de las tareas identificadas para la primera versión (teniendo en cuenta el equipo detallado en el punto c).
Respuestas para la Sección I
1.
(a) 16 (b) 28 (c) 38 2. Las figuras componen un cuadrado de 25x25 ⇒ el área total es de 625 unidades.
