Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Aguiar Perez Olivia ED01 Tarea
Aguiar Perez Olivia ED01 Tarea
Enunciado.
Se trata de diseñar una aplicación para una tienda especializada en vender productos estéticos.
La tienda desea trabajar con software libre. Además, desea explícitamente que la aplicación sea capaz de cumplir las
siguientes tareas:
Tendrás que diseñar una planificación del proyecto de desarrollo de ese software que cumpla con las premisas
estudiadas en la presente unidad de trabajo.
1. Sintetiza el análisis de requerimientos del sistema para nuestro cliente. Plantea el diseño y determina el
modelo de ciclo de vida más idóneo para esta aplicación.
Fases
Análisis de requisitos:
Tendrán lugar x cantidad de reuniones para trabajar en función de las expectativas del cliente. Determinar los objetivos
de prioridad y sus tiempos de cumplimiento. Establecer mecanismos de actuación ante contingencias.
Diseño
Ejemplo: Scrum
• Entrega mensual (o quincenal) de resultados (los requisitos más prioritarios en ese momento, ya
completados) lo cual proporciona las siguientes ventajas:
o Gestión regular de las expectativas del cliente y basada en resultados tangibles.
o Resultados anticipados (time to market).
o Flexibilidad y adaptación respecto a las necesidades del cliente, cambios en el mercado, etc.
o Gestión sistemática del Retorno de Inversión (ROI).
o Mitigación sistemática de los riesgos del proyecto.
• Productividad y calidad.
• Alineamiento entre el cliente y el equipo de desarrollo.
• Equipo motivado.
2. Planifica la codificación, indicando el lenguaje de programación y las herramientas que usarías para la
obtención del código fuente, objeto y ejecutable, explicando por qué eliges esas herramientas.
Objetivo: cumplir exhaustivamente con todos los datos impuestos en el análisis y en el diseño de la aplicación.
Se codificará toda la información anterior (es decir, indicar paso a paso usando un lenguaje de programación, las tareas
que debe realizar el ordenador). Al realizar esto se obtiene lo que se llama código fuente.
Herramienta: NetBeans
Con el entorno de desarrollo NetBeans, al ser un entorno completo, cubriremos las tres partes de la codificación:
a. Código Fuente: Será tarea de los programadores desarrollar este código en el entorno de desarrollo NetBeans
utilizando el editor de código.
b. Código Objeto: Utilizando el compilador de NetBeans obtendremos el código binario resultante de compilar
el código fuente.
c. Código ejecutable: Este código es el resultado de enlazar los archivos objeto, consta de un único archivo que
puede ser ejecutado por el sistema operativo directamente. Este paso también lo realizaremos con la
aplicación NetBeans.
3. Planifica las restantes fases del ciclo de vida, indicando en cada una el objetivo que persigues y cómo lo
harías.
Compilación: El proceso de traducción se realiza sobre todo el código fuente, en un solo paso. Se crea código objeto
que habrá que enlazar. El software responsable se llama compilador (NetBeans).
Plan de pruebas
Principal objetivo: Para asegurarse que lo que queremos que haga nuestro programa, lo haga, y lo haga sin errores.
a. Prueba Unitarias: las pruebas unitarias son pruebas automatizadas que verifican la funcionalidad en el
componente, clase, método o nivel de propiedad.
El objetivo principal de las pruebas unitarias es tomar la pieza más pequeña de software comprobable en
la aplicación, aislarla del resto del código y determinar si se comporta exactamente como esperamos. Cada
unidad se prueba por separado antes de integrarlas en los componentes para probar las interfaces entre las
unidades.
b. Pruebas de integración: Las pruebas de integración – o de componentes - identifican problemas que
ocurren cuando las unidades se combinan. Los nuevos errores que surgen probablemente estén
relacionados con la interfaz entre las unidades en lugar de dentro de las propias unidades; simplificando
la tarea de encontrar y corregir los defectos.
c. Pruebas de regresión: cada vez que se realizan cambios en un proyecto, es posible que el código
existente ya no funcione correctamente o que se presenten errores no descubiertos previamente. Este
tipo de error se llama regresión.
Para detectar estos defectos, todo el proyecto debe someterse a una regresión: una nueva prueba completa
de un programa modificado, en lugar de una prueba de solo las unidades modificadas, para garantizar que
no se hayan introducido errores con las modificaciones.
Como se puede deducir, este tipo de pruebas debe ser automatizado porque puede estar compuesto por
decenas o miles de pruebas unitarias, de integración o más.
Una versión menos costosa, podría ser construir pruebas que repliquen las acciones que provocaron la
regresión, y comprueben que han sido corregidos al no volver a sucederse los errores; además de añadir
los test unitarios que aseguren que el código que ha corregido la regresión funciona correctamente.
El objetivo de las pruebas funcionales automáticas es comprobar que no haya regresiones. Las pruebas
obligan a hacer un código desacoplado y promueven la calidad
En el caso de las manuales, las ejecuta un tester como si fuese un usuario, pero siguiendo una serie
de pasos establecidos en el plan de pruebas, diseñado en el análisis de los requisitos para garantizar
que hace lo que debe (casos positivos), que no falla (casos negativos) y que es lo que se ha
solicitado.
El tester realizará las acciones indicadas en cada paso del caso de prueba comprobando que se cumple el
resultado esperado. Si el resultado es distinto, se reportará un defecto con todo detalle: descripción, datos
utilizados, capturas de pantalla, etc., para facilitar la solución.
El mayor problema con el que se enfrentan las pruebas funcionales para ser automatizadas es su fragilidad.
Cada prueba testea miles de líneas de código, centenares de integraciones en todos los tiers, y una interfaz
de usuario cambiante. Llegando a no ser sostenible el conjunto de pruebas en relación con su definición,
coste y mantenimiento.
e. Prueba de estrés: las pruebas a pequeña escala, como un usuario único que ejecuta una aplicación web
o una base de datos con solo un puñado de registros, pueden no revelar problemas que suceden cuando
la aplicación se usa en condiciones "reales".
La prueba de estrés empuja los límites funcionales de un sistema. Se realiza sometiendo el sistema a
condiciones extremas, como volúmenes de datos máximos o una gran cantidad de usuarios simultáneos.
En otras aplicaciones (escritorio y aplicaciones móviles, por ejemplo), las pruebas de rendimiento miden
la velocidad y la utilización de recursos, como el espacio en disco y la memoria.
Si almacenamos todos los resultados de las pruebas de rendimiento durante un plazo de tiempo, podemos
conocer el estado de salud de la aplicación, pudiendo obtener tendencias y previsiones de funcionamiento;
y optimizando cada despliegue según el rendimiento necesario en cada caso.
g. Pruebas de seguridad: validan los servicios de seguridad de una aplicación e identifican posibles fallos
y debilidades.
Muchos proyectos utilizan un enfoque de caja negra para las pruebas de seguridad, lo que permite a los
expertos, sin conocimiento del software, probar la aplicación en busca de agujeros, fallos, exploit y
debilidades.
Explotación: En este momento, se suelen llevan a cabo las Beta Test, que son las últimas pruebas que se realizan en
los propios equipos del cliente y bajo cargas normales de trabajo.
En ella, asignamos los parámetros de funcionamiento normal de la empresa y probamos que la aplicación es operativa.
También puede ocurrir que la configuración la realicen los propios usuarios finales, siempre y cuando les hayamos
dado previamente la guía de instalación. Y también, si la aplicación es más sencilla, podemos programar la
configuración de manera que se realice automáticamente tras instalarla. (Si el software es "a medida", lo más
aconsejable es que la hagan aquellos que la han fabricado).
Una vez se ha configurado, el siguiente y último paso es la fase de producción normal. La aplicación pasa a manos de
los usuarios finales y se da comienzo a la explotación del software.
Mantenimiento: El mantenimiento se define como el proceso de control, mejora y optimización del software.
Su duración es la mayor en todo el ciclo de vida del software, ya que también comprende las actualizaciones y
evoluciones futuras del mismo.
Los tipos de cambios que hacen necesario el mantenimiento del software son los siguientes:
Documentación: En realidad, la documentación no debe ser considerada como una etapa más en el desarrollo del
proyecto, la elaboración de documentos es constante durante todo su ciclo de vida.
Una correcta documentación permitirá pasar de una etapa a otra de forma clara y definida. También se hace
imprescindible para la reutilización de parte de los programas en otras aplicaciones, siempre y cuando se desarrollen
con diseño modular.
Tipos de documentos:
Conclusión: Se debe hacer documentación contante en cada fase o etapa del proyecto.