• Author / Uploaded
• FreddyMiiss

Citation preview

26.1. Suponga que usted es el gerente de proyecto de una compañía que construye software para robots caseros. Se le contrata a fin de construir el software para un robot que pode el césped para el propietario de una casa. Escriba un enunciado para el ámbito que describa el software. Asegúrese de que su enunciado de ámbito esté acotado. Si no está familiarizado con los robots, haga un poco de investigación antes de comenzar a escribirlo. Además, establezca sus suposiciones acerca del hardware que se requerirá. Alternativa: Sustituya el robot podador con otro problema que sea de su interés.

Diseñamos robots para que no vuelvas a trabajar en tu jardín. El cual cuentan con total autonomía por lo que operarán solos, bajo cualquier condición meteorológica y de forma silenciosa y haciendo ver su jardín como nunca antes visto. Sí, así es El modelo de Cortacésped son silenciosos, eficientes y operan con una batería, por lo que también son responsables con el medio ambiente. Además, están especializados en los terrenos más complejos, es decir, jardines con pasillos estrechos, pendientes de hasta un 45% y espacios llenos de obstáculos. Con el robot Cortacésped, ya no tendrás que volver a cortar la grama de tu jardín, solamente tendrás que encargarte de programar las horas y los días en los que quieres que trabaje. Para ellos utilizaremos interfaces de usuarios, análisis geométrico dimensional, gestiones en la base de datos, módulos de diseño, y por lo menos estimar cuantas líneas de código se van a utilizar. 26.2. La complejidad del proyecto de software se analiza brevemente en la sección 26.1. Elabore una lista de características de software (por ejemplo, operación concurrente, salida gráfica) que afecten la complejidad de un proyecto. Priorice la lista. Las tareas para realizar una prueba de este tipo serían las siguientes:     

     

Sistema de geolocalización Patrones de movimientos Instalar y configurar los simuladores de peticiones y controladores. Desarrollar un plan de alto nivel, incluyendo los requisitos, recursos, plazos e hitos. Configurar el entorno de prueba (lo ideal es que sea idéntico hardware a la plataforma de producción), configurar los router, aislar la red (no queremos alterar los resultados por parte de otros usuarios), desplegar la aplicación en el servidor, desarrollar la base de datos de prueba, etc. Compatibilidad con componentes electrónicos Tipo de lenguaje que se va a utilizar mejor si es a bajo nivel Reunir u obtener requisitos de rendimiento (especificaciones) de los usuarios y/o analistas. Elaborar un plan de pruebas de rendimiento detallado (incluyendo los escenarios detallados y casos de prueba, cargas de trabajo, información del entorno, etc). Elegir la/s herramienta/s de prueba. Especificar los datos de prueba necesarios y la distribución de ellos (a menudo pasado por alto, y a menudo el fracaso de una prueba de rendimiento válida).

   

Desarrollar scripts de prueba de concepto para cada aplicación/componente sometido a la prueba, utilizando la herramienta de prueba elegida y estrategias. Desarrollar un plan de prueba de rendimiento detallado, incluyendo todas las dependencias y los plazos. Decidir usar recursos internos o externos para ejecutar las pruebas, en función de la experiencia de la casa (o falta de ella). Analizar los resultados - ya sea de aceptando/rechazando, o investigando el camino crítico y recomendando medidas correctivas.

26.3. El rendimiento es una importante consideración durante la planificación. Analice cómo puede interpretarse de manera diferente el rendimiento, dependiendo del área de aplicación del software. El rendimiento del software lo podemos medir mediante los siguientes aspectos y procesos:       

Pruebas de Carga Pruebas de estrés Pruebas de estabilidad (soak testing) Pruebas de Picos (spike testing) Prerrequisitos de carga Estimaciones razonables de recursos Planificaciones temporales

Como mitos en el rendimiento de Software tenemos: Las pruebas de rendimiento se hacen para romper el sistema: Las pruebas de estrés se hacen para observar el punto de ruptura del sistema. Por el contrario, las pruebas normales de carga se hacen generalmente para ver el comportamiento de la aplicación bajo una carga de usuarios esperada, y dependen de otros requisitos, tales como el aumento de carga esperado, la carga continuada por un periodo prolongado de tiempo mientras la demanda aumenta, la resistencia a las caídas o las pruebas de estrés. Las pruebas de rendimiento sólo deben hacerse después de las pruebas de integración del sistema: Aunque esta es la norma común en la industria, las pruebas de rendimiento también pueden realizarse mientras se realiza el desarrollo inicial de la aplicación. Este tipo de enfoque se conoce como pruebas de rendimiento tempranas. Este enfoque garantizaría un desarrollo holístico de la aplicación manteniendo los parámetros de rendimiento en mente. Por lo tanto, la búsqueda de un problema en el rendimiento justo antes de la terminación de la aplicación y el coste de corregir el error, se reduce en gran medida. El probar el rendimiento sólo implica la creación de scripts y cualquier cambio en la aplicación solo puede causar una simple refactorización de dichos scripts: Las pruebas de rendimiento son en sí mismas una ciencia evolucionada de la industria del software. En sí mismos, los scripts, aunque importantes, son sólo uno de los componentes de las pruebas de rendimiento. El principal desafío para cualquier persona que pruebe el rendimiento es determinar el tipo de pruebas necesarias y analizar los distintos medidores de rendimiento para determinar el cuello de botella de rendimiento.

26.4. Haga una descomposición funcional del software de robot que describió en el problema 26.1. Estime el tamaño de cada función en LOC. Si supone que su organización produce 450 LOC/pm con una tarifa de mano de obra sobrecargada de US$7 000 por persona-mes, estime el esfuerzo y el costo requeridos para construir el software, usando la técnica de estimación basada en LOC descrita en este capítulo.

Módulo Interface gráfica Rutinas matemáticas Reportes TOTAL

Esperado 2300 6,300 900 9,500

Si en base a los datos históricos sabemos que tenemos una productividad media de 450 LOC/hombre-mes, podemos calcular que el esfuerzo de desarrollar el sistema será de (9500 / 500) = 19 hombres- Y si cada hombre-mes cuesta $7,000 (entre sueldos y gastos extras), entonces el costo del sistema será de $133,000.

26.5. Use el modelo COCOMO II para estimar el esfuerzo requerido para construir software para un simple ATM que produce 12 pantallas, 10 reportes y que requerirá aproximadamente 80 componentes de software. Suponga complejidad promedio y madurez desarrollador/entorno promedio. Use el modelo de composición de aplicación con puntos de objeto. Donde:    

PM: Esfuerzo estimado en personas/mes NAP: total de puntos aplicación en el sistema a desarrollar %Reutilización: es una estimación de la cantidad de código reutilizado en el desarrollo PROD: Productividad en puntos aplicación/mes

11*1(-16%/100)/60=0.29 La productividad será e 0.29

26.6. Use la ecuación de software para estimar el software del robot podadora. Suponga que la ecuación 26.4 es aplicable y que P = 8 000 T min= 8.14(450/8000^0.43) t min = 76.82 E = ((LOC *(B^0.333) / P) * (1/t^4) E = ((450* 1)/8000) = 0.05625 * (1/ 114^4) = 0.333

26.7. Compare las estimaciones de esfuerzo inferidas en los problemas 26.4 y 26.6. ¿Cuál es la desviación estándar y cómo afecta esto a su grado de certidumbre acerca de la estimación? La desviación estándar es de 56.835 meses, esto hace muy complejo el desarrollo, se requiere reducir el número de líneas de código estimadas en el punto 26.4 26.8. Usando los resultados obtenidos en el problema 26.7, determine si es razonable esperar que el software pueda construirse dentro de los siguientes seis meses y cuántas personas tendrían que emplearse para realizar el trabajo. Se determinó que para el desarrollo de proyecto se calculó en tiempo calendario de 12.6 con un total de 58 personas, esto cumple dentro de los parámetros estándares dentro del cálculo de la ecuación, se estima que para 6 meses se debe doblegar la cantidad de personar para desarrollar el proyecto en tiempo sé que se estima lo cual implicaría costos más elevados para el desarrollo del proyecto lo cual no se ve razonable dentro del ámbito económico.

26.9. Desarrolle un modelo de hoja de cálculo que implemente una o más de las técnicas de estimación descritas en este capítulo. De manera alternativa, adquiera uno o más modelos en línea para estimación de fuentes en la web

Plantilla para estimar el coste de un desarrollo de software "Mi Tienda Web" Pieza Autentificación y Autorización Pantalla de Login Servicio de Autentificación Servicio de Autorización Redirección de usuario Registro de Usuarios Formulario de Registro Recuperar Contraseña Confirmar Registro Enviar E-mail de Confirmación Auditoría de Logins Bloquear Ataques Analíticas Google Analytics Optimizely Catálogo Escaparate Principal Ofertas destacadas Recomendaciones Navegación por categorías Busquedas por nombre o referencia Detalle de Producto Carrito Agregar al carro Guardar Carro Mostrar carro Resumen de pre-checkout Pago Pago de usuario registrado Pago de usuario no registrado Pasarela Bancaria Confirmar Pago Contacto Formulario de Contacto Registro de Contactos Ayuda y Contenidos Aviso Legal Preguntas Frecuentes Modelos de Datos Tablas Exportación Contable Pruebas Pasarela de Pago

Resultado

Cantidad Story Points

Página Web Sencilla Servicio Web Sencillo Servicio Web Medio Servicio Web Sencillo

1 1 1 1

8 4 8 4

Formulario Página Web Sencilla Página Web Sencilla Servicio Web Medio Servicio Web Medio Servicio Web Complejo

1 1 1 1 1 1

4 8 8 8 8 32

Librería JavaScript Sencilla Librería JavaScript Sencilla

1 1

8 8

Página Web Compleja Página Web Compleja Página Web Media Página Web Compleja Página Web Sencilla

1 1 1 1 1

40 40 16 40 8

Página Web Media Servicio Web Medio Página Web Media Página Web Sencilla

1 1 1 1

16 8 16 8

Página Web Media Página Web Media Servicio Web Complejo Página Web Sencilla

1 1 1 1

16 16 32 8

Formulario Servicio Web Medio

1 1

4 8

Página Web Sencilla Página Web Sencilla

1 1

8 8

10 1

40 20

1

8

Añadir una Tabla ETL Media Prueba de Integración Media

936 horas

26.11 Parece extraño que las estimaciones de costo y calendario se desarrollen durante la planificación del proyecto de software, antes del análisis detallado de los requisitos de software o de realizar el diseño. ¿Por qué cree que se haga esto? ¿Existen circunstancias para no hacerlo? Se trata el tema de organización para la ejecución; se discuten posibles estructuras para la administración del proyecto y modalidades para la inserción institucional del equipo del proyecto En la actualidad existen un conjunto de métricas que no se utilizan, y que pueden ser aplicables a cualquier tipo de proyecto de software para calcular el costo de estos. métricas, costos, desarrollo de software, metodologías de software.

26.12 Vuelva a calcular los valores esperados que se anotaron para el árbol de decisión en la figura 26.8 y suponga que cada rama tiene una probabilidad 50-50. ¿Esto cambiaría su decisión final? Según el análisis de los cálculos cambiados con la suposición de 50-50 no cambia la decisión que se platea dentro de los parámetros del proyecto ya que no afecta la ejecución en cálculos y se estima menor tiempo de ejecución con este esquema aumentado considerablemente la eficiencia del personal adquirido con menor tiempo estimado aumentado el retorno de inversión del proyecto menos de lo estimado.