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
Esperado
Interface gráfica 2300
Rutinas matemáticas 6,300
Reportes 900
TOTAL 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 Cantidad Story Points

Autentificación y Autorización
Pantalla de Login Página Web Sencilla 1 8
Servicio de Autentificación Servicio Web Sencillo 1 4
Servicio de Autorización Servicio Web Medio 1 8
Redirección de usuario Servicio Web Sencillo 1 4
Registro de Usuarios
Formulario de Registro Formulario 1 4
Recuperar Contraseña Página Web Sencilla 1 8
Confirmar Registro Página Web Sencilla 1 8
Enviar E-mail de Confirmación Servicio Web Medio 1 8
Auditoría de Logins Servicio Web Medio 1 8
Bloquear Ataques Servicio Web Complejo 1 32
Analíticas
Google Analytics Librería JavaScript Sencilla 1 8
Optimizely Librería JavaScript Sencilla 1 8
Catálogo
Escaparate Principal
Ofertas destacadas Página Web Compleja 1 40
Recomendaciones Página Web Compleja 1 40
Navegación por categorías Página Web Media 1 16
Busquedas por nombre o referencia Página Web Compleja 1 40
Detalle de Producto Página Web Sencilla 1 8
Carrito
Agregar al carro Página Web Media 1 16
Guardar Carro Servicio Web Medio 1 8
Mostrar carro Página Web Media 1 16
Resumen de pre-checkout Página Web Sencilla 1 8
Pago
Pago de usuario registrado Página Web Media 1 16
Pago de usuario no registrado Página Web Media 1 16
Pasarela Bancaria Servicio Web Complejo 1 32
Confirmar Pago Página Web Sencilla 1 8
Contacto
Formulario de Contacto Formulario 1 4
Registro de Contactos Servicio Web Medio 1 8
Ayuda y Contenidos
Aviso Legal Página Web Sencilla 1 8
Preguntas Frecuentes Página Web Sencilla 1 8
Modelos de Datos
Tablas Añadir una Tabla 10 40
Exportación Contable ETL Media 1 20
Pruebas
Pasarela de Pago Prueba de Integración Media 1 8

Resultado 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.