Tarea para ED01.

Detalles de la tarea de esta unidad.

Enunciado.

La empresa BK ha recibido un nuevo encargo de software.

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:

• Proporcionar facturas de las ventas.

• Llevar la cuenta de lo que vende cada trabajador.
• Controlar el stock de productos en almacén.
• Operar con lector de código de barras y tarjetas de crédito.
• Controlar los precios de los productos y ofrecer la posibilidad de operar con ellos.
• El tiempo de respuesta de la aplicación ha de ser lo menor posible.
• No se podrán procesar dos peticiones a la vez, aunque haya varios equipos funcionando simultáneamente.
• La empresa también quiere almacenar información de sus trabajadores: DNI, nombre, apellidos, número de
la Seguridad Social, fecha de nacimiento, teléfono y localidad. Asimismo, de los productos interesa
almacenar: código, marca, nombre comercial, precio, cantidad.

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.

Esencialmente, el proyecto se divide en los siguientes apartados:

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

a. Documento especificación de requisitos software

Análisis de requisitos:

Requisitos Funcionales: Requisitos No Funcionales:

Proporcionar facturas de las ventas. El tiempo de respuesta de la aplicación ha de ser lo
menor posible.
Llevar la cuenta de lo que vende cada trabajador. No se podrán procesar dos peticiones a la vez,
aunque haya varios equipos funcionando
simultáneamente.
Controlar el stock de productos en almacén.
Operar con lector de código de barras y tarjetas de crédito.
Controlar los precios de los productos y ofrecer la
posibilidad de operar con ellos.
La empresa también quiere almacenar información de sus
trabajadores: DNI, nombre, apellidos, número de la
Seguridad Social, fecha de nacimiento, teléfono y localidad.
Asimismo, de los productos interesa almacenar: código,
marca, nombre comercial, precio, cantidad.
 b. Documento de diseño de arquitectura

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

Documento de Diseño del Software:

Modelos Evolutivos: Modelos Agiles:

• Centrados en la satisfacción del cliente.

• Muestran gran flexibilidad a la aparición de nuevos requisitos, incluso durante el desarrollo de la aplicación.
• El desarrollo es incremental, peros incrementos son cortos y están abiertos al solapado de unas fases con
otras.
• La comunicación entre los integrantes del equipo de trabajo y de éstos con el cliente son constantes.

Ejemplo: Scrum

• Genera capacidad de reacción ante el mercado

• Impulsar la innovación y creatividad de sus equipos
• Mejorar su forma de trabajar y ser más productivos.

Beneficios del 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.

Lenguaje de programación: Java

Persona encargada de codificar: Programador

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.

Características del código:

a. Modularidad: que esté dividido en trozos más pequeños.

b. Corrección: que haga lo que se le pide realmente.
c. Fácil de leer: para facilitar su desarrollo y mantenimiento futuro.
d. Eficiencia: que haga un buen uso de los recursos.
e. Portabilidad: que se pueda implementar en cualquier equipo

Herramienta: NetBeans

Razón de utilizar 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.

d. Pruebas de funcionalidad: prueban las funcionalidades de la aplicación o módulo construidos desde el

punto de vista del usuario final, con sus diferentes roles, para validar que el software hace lo que debe
y, sobre todo, lo que se ha especificado.

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.

También se utilizan para, llevado el sistema al colapso o degradación, comprobar su funcionamiento

continuado por encima de su límite y, una vez liberado de la carga, evaluar su capacidad de resiliencia
volviendo a su estado óptimo de funcionamiento.

f. Prueba de rendimiento: determinan la capacidad de respuesta, el rendimiento, la confiabilidad y/o la

escalabilidad de un sistema bajo una carga de trabajo determinada.
 En aplicaciones web, las pruebas de rendimiento a menudo están estrechamente relacionadas con las
pruebas de estrés, la medición del retraso y la capacidad de respuesta bajo una carga pesada.

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.

Conclusión: Las pruebas no son opcionales.

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.

Una vez instalada, pasamos a la fase de configuración.

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:

• Perfectivos: Para mejorar la funcionalidad del software.

• Evolutivos: El cliente propone mejoras para el producto. Implica nuevos requisitos.
• Adaptativos: Modificaciones, actualizaciones... para adaptarse a las nuevas tendencias del mercado, a
nuevos componentes hardware, nuevas condiciones especificadas por organismos reguladores, etc.
• Correctivos: Resolver errores detectados. Sería utópico pensar que esto no vaya a suceder.

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:

• Enfocado al personal técnico informático:

o Contiene el diseño de la aplicación, la codificación de los programas y las pruebas realizadas.
o Objetivo: Facilitar un correcto desarrollo, realizar correcciones en los programas y permitir un
mantenimiento futuro.
• Enfocado a los usuarios:
o Contiene la descripción de la funcionalidad de la aplicación, la forma de comenzar a ejecutar la
aplicación, los ejemplos de uso del programa, los requerimientos software de la aplicación y la
solución de los posibles problemas que se pueden presentar.
o Objetivo: Dar a los usuarios finales toda la información necesaria para utilizar la aplicación
• Enfocado a los informáticos responsables de la instalación:
o Contiene la puesta en marcha, la explotación y seguridad del sistema.
o Objetivo: Dar toda la información necesaria para garantizar que la implantación de la aplicación se
realice de forma segura, confiable y precisa.

Conclusión: Se debe hacer documentación contante en cada fase o etapa del proyecto.

4. Indica el ciclo de vida que usarías.