1-. Análisis de requisitos:
Funcionales: -
Proporcionar facturas de venta Llevar la cuenta de lo que ha vendido cada empleado. Controlar el stock de productos en el almacén. Operar con lector de códigos de barra y tarjetas de crédito. Controlar precios y poder operar con ellos. Almacenaje de datos de los empleados, así como de los productos.
No funcionales: -
Menor tiempo de respuesta posible. No se pueden procesar varias peticiones simultáneamente aunque haya varios equipos operando.
Diseño:
Dividiría en problema en dos partes par tes tales que: 1-. Proporcionar facturas de venta+operar con códigos de barra/tarjetas+control de precios. 2-. Control de ventas por cada empleado+stock en almacén+datos de empleados y productos. Así, la primera se ocuparía de obtener y tratar los datos del producto mediante código de barras, así como los del cliente (con lector de tarjetas si se usa ese método), controlar el precio si hubiera variación, y juntar todos esos datos para generar la factura. La segunda parte se ocuparía más de la gestión de inventario y control sobre empleados. Ambas partes se relacionarían entre sí mediante el control de productos. Los códigos de barras de la función 1 sería algo que aparecería también en los datos de productos de la función 2, así como el precio. Con respecto al ciclo de vida del producto, dependerá del tiempo disponible y las expectativas del cliente de cara a una mejora y actualización de los servicios que quiere que ofrezca el programa. En un principio yo utilizaría un modelo en cascada con retroalimentación, ya que los requisitos parecen estar lo suficientemente claros. De ser estos más c ambiantes se haría según el modelo iterativo incremental, y si fuera necesario añadir nuevas funciones o una actualización constante debido a un entorno cambiante, el modelo en espiral. No obstante, dados los requisitos planteados, no creo que sea el caso y el modelo en cascada con retroalimentación sería el más indicado. 2-.
Se utilizaría el lenguaje de programación orientado a objetos objetos Java. Esta elección se justifica por la reusabilidad del código, y la posibilidad de dividir el problema en partes más pequeñas,
que facilita la depuración (es decir, nos ofrece cierta modularidad). También, gracias a la máquina virtual, nos ofrece portabilidad. Podría utilizarse un framework como Spring, ya que ofrece importantes ventajas como el diseño uniforme del software, aunque no me convenza demasiado la dependencia del código respecto al framework utilizado. Lo que sí sería de obligado uso serían herramientas CASE para agilizar el proyecto, mejorar el mantenimiento y el proceso de desarrollo.
3-.
Después del análisis de requisitos, diseño y codificación, vendría la fase de pruebas. Ésta es imprescindible para asegurar la validación y verificación del software construido. Se dividen en pruebas unitarias (que consisten en probar, una a una, las diferentes partes de software y comprobar su funcionamiento), y pruebas de integración (que se realizan una vez completadas las pruebas unitarias y consisten en comprobar el funcionamiento del sistema completo: con todas sus partes interrelacionadas). Después de estas pruebas, se realiza el normalmente llamado beta-test, en el que el software es probado en el entorno de producción donde va a ser utilizado por el cliente. La documentación no es una fase que ocupe un lugar concreto, sino que puede (y, en mi opinión es recomendable) ir paralela al desarrollo del resto de fases de desarrollo. La correcta documentación de las etapas en el desarrollo permite dar toda la información a los usuarios de nuestro software, así como arremeter diferentes revisiones del proyecto. Como he dicho en el párrafo anterior, es una fase que iría desarrollando paralelamente al resto de fases, para no obviar ningún detalle y que cada paso quede bien reflejado. Así, teniendo todo bien documentado y explicado, podríamos describir correcta y fácilmente la aplicación al usuario final, además de tener la posibilidad retomarla más tarde de cara a mejoras, o reutilizar partes del código para otros proyectos, al poder interpretar fácilmente qué se quería hacer con cada módulo desarrollado. Tras esto, vendría la fase de explotación, en la que es muy importante tenerlo todo bien preparado. En esta parte, la aplicación pasa a manos de los usuarios finales, pero primero se instalará y pondrá a punto la aplicación final. Personalmente, la haría estando presente el cliente, pues así podría explicársele sobre la marcha los pasos dados, y solucionar posibles dudas o inquietudes que pueda tener durante el proceso. Después de esto daría el comienzo a los beta-test para asegurar que todo va según lo previsto y especificado por el cliente. Finalizados con éxito estas pruebas, empezaría la explotación propiamente dicha, explicada en el anterior párrafo. Por último, está el mantenimiento . Esta es la etapa más larga, pues comprende toda la vida útil que nuestro software vaya a tener, y es, en síntesis, el proceso de control, mejora y optimización del software.
En este caso, los procedimientos a seguir serían mayormente perfectivos, y correctivos. Adaptativos dudo que sean de utilidad en este tipo de software de gestión, pese a que algún cambio de este tipo deberá ser realizado, pero no tan asiduamente como los dos primeros. También están los cambios evolutivos, pero estos serán más marcados por el cliente, en caso de que adquiera nuevas necesidades y que haya que implementar nuevas funciones, o, al contrario, borrarlas en caso de que no sean útiles y, por tanto, un lastre.
