0% encontró este documento útil (0 votos)
277 vistas6 páginas

ED01 Tarea

El documento describe los primeros pasos en el desarrollo de software para una tienda minorista. Incluye un análisis de requisitos funcionales y no funcionales, un diseño inicial dividiendo el sistema en módulos de gestión de empleados, productos y ventas, y un plan para las próximas fases del ciclo de vida de desarrollo.

Cargado por

beademig
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
277 vistas6 páginas

ED01 Tarea

El documento describe los primeros pasos en el desarrollo de software para una tienda minorista. Incluye un análisis de requisitos funcionales y no funcionales, un diseño inicial dividiendo el sistema en módulos de gestión de empleados, productos y ventas, y un plan para las próximas fases del ciclo de vida de desarrollo.

Cargado por

beademig
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

8-10-2023 Entornos de

desarrollo
Tarea 1

1º CFGS DAM
ED01

APARTADO 1

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
En esta primera etapa del desarrollo del software, el producto resultantes es el ERS (Especificación
de Requisitos del Software) pero como el ejercicio pide que sintetice y no disponemos de mas
información que el enunciado, hay que que especificar y analizar los requisitos funcionales y no
funcionales del sistema, que sí vienen incluidos en el mismo.

REQUISITOS FUNCIONALES
Describe la “funcionalidad” de la aplicación, “lo que debe hacer” o la respuesta que dará la
aplicación. Del enunciado de la tarea se pueden especificar los siguientes requisitos funcionales:

 El sistema debe proporcionar facturas de ventas.


 El sistema debe llevar la cuenta de lo que vende cada trabajador.
 El sistema debe controlar el stock de productos en almacén.
 El sistema debe operar con lector de código de barras y tarjetas de crédito.
 El sistema debe 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.

REQUISITOS NO FUNCIONALES
Los requisitos no funcionales indicados en el enunciado son:

 El tiempo de respuesta de la aplicación ha de ser el menor posible.


 No se podrán procesar dos peticiones a la vez, aunque haya varios equipos funcionando
simultáneamente.
 El sistema requiere de un sistema gestor de base de datos para la persistencia de los datos
de sus trabajajadores y de los productos.
El enunciado no indica otros posibles requisitos no funcionales como por ejemplo, sistemas
operativos sobres los que debe funcionar la aplicación, como podría ser la interfaz de usuario,
hardware sobre el que debe funcionar, etc.

DISEÑO
En esta fase, se debe dividir el sistema en partes y tomar una serie de decisiones, como entidades
y relaciones de bases de datos, selección del lenguaje de programación que se va a utilizar y
selección del sistema gestor de bases de datos, entre otras.

08/10/2023 1
ED01

Una posible división del sistema en partes sería:

SISTEMA

Gestión de trabajadores Gestión de productos

Gestión de ventas

En esta fase se toman las siguientes decisiones:

 Entidades: trabajador, producto, venta (no habla nada de clientes pero una venta debería
tener la entidad cliente).
 Relaciones: una venta se relaciona con trabajadores (no especifica si uno o varios) y con
productos (no se cita a los posibles clientes pero deberían estar relacionados también con
la venta).
 Se decide que el sistema gestor de bases de datos es MySQL por ser de código abierto,
trabaja con bases de datos relacionales, y es ampliamente conocido por los
programadores web que van a desarrollar la aplicación.

MODELO DE CICLO DE VIDA


El modelo de ciclo de vida más idóneo para el desarrollo de esta aplicación, considero que es el
modelo en cascada con realimentación, ya que entiendo que los requisitos están claros desde el inicio
de las fases del proyecto. Es un modelo ampliamente usado, en el que nuestro equipo de
desarrollo está experimentado y lo veo el más correcto cuando desde el principio, los requisitos
están perfectamente definidos desde el principio (algo que no está tan claro leyendo el
enunciado).
También podría optar, en el caso de que los requisitos no estuvieran claros desde el inicio y el
proyecto no fuera rígido en ese sentido, por implementar una metodología ágil, ya que está muy
centrada en la satisfacción del cliente, es flexible si aparecieran nuevos requisitos más tardíos o
cambios en los mismos, y se trata de crear incrementos en el tiempo donde las fases se solapan.
Modelo muy actual donde se necesita una comunicación constante con el cliente y eso suele
gustar (el cliente ve esos prototipos o incrementos y sabe del desarrollo del mismo de una manera

08/10/2023 2
ED01

“palpable”, no como en el anterior modelo, que sólo en fases tardías los clientes podrían ver una
versión de su producto).

APARTADO 2

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
Se trata de una aplicación web, y va a ser desarrollada en PHP como lenguaje de servidor y
JavaScript, HTML y CSS, como lenguajes en la parte de frontend. PHP es un lenguaje
imperativo, orientado a objetos e interpretado (no necesita compilación ni paso a código objeto
ni ejecutable). Como IDE se va a usar Netbeans ya que permite la codificación en PHP y en
JavaScript. Se elige estas herramientas por ser software libre, ya que se pide en el enunciado, y
por tener experiencia previa en el desarrollo de productos web.
PHP es un lenguaje interpretado, y por tanto, el proceso de traducción del código fuente se
realiza línea a línea y se ejecuta simultáneamente. No existe código objeto intermedio. El
software que realiza la traducción se llama intérprete. El proceso de traducción es más lento que
la compilación (en el caso de los lenguajes compilados) y eso se nota cuando ejecutamos
software interpretado con respecto al software compilado.

APARTADO 3

3 PLANIFICA LAS RESTANTES FASES DEL CICLO DE VIDA,


INDICANDO EN CADA UNA EL OBJETIVO QUE
PERSIGUES Y CÓMO LO HARÍAS
Después de la fase de codificación, vendrían las siguientes fases:

 Pruebas: una vez terminada la codificación del software, hay que probarlo.
Normalmente se realiza sobre un conjunto de datos de prueba. En nuestro caso,
probaríamos con un conjunto de empleados y productos, y realizando pruebas de ventas.
El objetivo de esta fase es verificar y validar el software. La verificación se realiza con
un conjunto de pruebas encaminadas a determinar la calidad del software (es decir, que
esté libre de fallos). Ver la definición en el temario online porque está repetida. La
validación es comprobar si el software hace lo que el cliente deseaba, mediante pruebas
en esta fase.
Deberemos realizar pruebas de estos tipos:
o Pruebas unitarias: probar las diferentes partes del software por separado, de
manera independiente. Se puede usar PHPUnit.

08/10/2023 3
ED01

o Pruebas de integración: una vez pasadas las pruebas unitarias, probamos que las
diferentes partes del programa interactúan de forma correcta.
o Estas pruebas se pueden hacer en las instalaciones del cliente si se desea, y hacer
partícipes a los futuros usuarios de las últimas pruebas.
 Documentación: es importante destacar que la documentación se realiza durantes todas
las fases del proyecto, ya que todas ellas, deben quedar perfectamente documentadas. Así
que en cada fase, tendremos que realizar documentación asociada a la misma. Además,
debemos realizar otro tipo de documentación, ya que
documentar un proyecto se hace necesario para dar toda la información a los usuarios
del software y para poder realizar el futuro mantenimiento del mismo.
Debemos realizar la entrega de documentación de al menos, estos tipos de documentos
(dependen del destinatario de la información):
o Guía técnica: dirigidos al personal técnico en informática (analistas y
programadores). El objetivo es facilitar un correcto desarrollo y permitir un
mantenimiento futuro.
o Guía de uso: dirigida a los usuarios que van a usar la aplicación. En estas guías se
da toda la información necesaria para utilizar la aplicación (forma de comenzar
la aplicación, funcionalidades, ejemplos de uso, requerimientos, etc).
o Guía de instalación: dirigidas a los instaladores de la aplicación. En esta guñía se
detalla la puesta en marcha, la explotación y aspectos de seguridad del sistema.
 Explotación: una vez acabadas las pruebas, comienza la fase de la explotación en la que
los usuarios finales conocen la aplicación y comienzan a utilizarla. En esta fase le
instalamos el software en el cliente, se lo configuramos y se lo dejamos preparado para
que empiecen a utilizarlo. La aplicación pasa a manos de los usuarios finales y se da
comienzo a la explotación del software o paso a producción del mismo.
 Mantenimiento: comienza la fase más larga donde el software debe ir adaptándose de
forma paralela a la explotación o uso del mismo. Pueden existir mejoras en el hardware,
cambios en los sistemas operativos, funcionalidades nuevas, etc.
En esta fase se controla, mejora y se optimiza el software.
Existen diferentes tipos de mantenimiento del software:
o Mantenimiento perfectivo: orientado a mejorar la funcionalidad del sotware, por
ejemplo, optimización del software.
o Mantenimiento evolutivo: el cliente propone mejoras o nuevos requisitos.
o Mantenimiento adaptativo: son modificaciones, actualizaciones que adaptan el
software a nuevos componentes hardware, nuevas leyes, etc.
o Mantenimiento correctivo: orientado a resolver errores no detectados en fases
anteriores.

08/10/2023 4
ED01

APARTADO 4

4 INDICA EL CICLO DE VIDA QUE USARÍAS


He indicado anteriormente que usaría el modelo en cascada con realimentación (suponiendo el caso
en que los requisitos no varían y se tuvieran claros desde el principio).

Es uno de los modelos más utilizados y supuestamente, tendríamos mucha experiencia ya en él.
Se produce una realimentación entre etapas, de forma que podemos corregir volviendo atrás en
cualquier momento. Solo se elige este modelo si no se prevén muchos cambios (entiendo que
una gestión de ventas es bastante clara en cuanto a definición de requisitos al principio del
proyecto). Si no fuera el caso, mejor optar por un ciclo de vida ágil.

08/10/2023 5

También podría gustarte