Scribd Logo
Cargar

¡Te damos la bienvenida a Scribd!

  • 15 vistas

    ED - Desarrollo Software - 2 PDF

    Cargado por

    y
    El documento presenta el análisis de requisitos, diseño y modelo de ciclo de vida para el desarrollo de un programa para una tienda de estética. Se detallan los requisitos funcionales y no funcionales, y se propone implementar un modelo en cascada retroalimentada. El diseño incluirá una base de datos relacional básica y el uso de C++ para la codificación. Se realizarán pruebas unitarias y de integración, así como pruebas beta una vez instalado. El programa se instalará en los ordenadores de la ti

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd

    ED - Desarrollo Software - 2 PDF

    Cargado por

    y
    15 vistas4 páginas
    El documento presenta el análisis de requisitos, diseño y modelo de ciclo de vida para el desarrollo de un programa para una tienda de estética. Se detallan los requisitos funcionales y no funcionales, y se propone implementar un modelo en cascada retroalimentada. El diseño incluirá una base de datos relacional básica y el uso de C++ para la codificación. Se realizarán pruebas unitarias y de integración, así como pruebas beta una vez instalado. El programa se instalará en los ordenadores de la ti

    Descripción original:

    Título original

    ED_Desarrollo software_2.pdf

    Derechos de autor

    © © All Rights Reserved

    Formatos disponibles

    PDF, TXT o lea en línea desde Scribd

    ¿Le pareció útil este documento?

    ¿Este contenido es inapropiado?

    El documento presenta el análisis de requisitos, diseño y modelo de ciclo de vida para el desarrollo de un programa para una tienda de estética. Se detallan los requisitos funcionales y no funcionales, y se propone implementar un modelo en cascada retroalimentada. El diseño incluirá una base de datos relacional básica y el uso de C++ para la codificación. Se realizarán pruebas unitarias y de integración, así como pruebas beta una vez instalado. El programa se instalará en los ordenadores de la ti

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    15 vistas4 páginas

    ED - Desarrollo Software - 2 PDF

    Cargado por

    y
    El documento presenta el análisis de requisitos, diseño y modelo de ciclo de vida para el desarrollo de un programa para una tienda de estética. Se detallan los requisitos funcionales y no funcionales, y se propone implementar un modelo en cascada retroalimentada. El diseño incluirá una base de datos relacional básica y el uso de C++ para la codificación. Se realizarán pruebas unitarias y de integración, así como pruebas beta una vez instalado. El programa se instalará en los ordenadores de la ti

    Copyright:

    © All Rights Reserved
    Descargue como PDF, TXT o lea en línea desde Scribd
    Descargar como pdf o txt
    de 4

    Desarrollo de programa para

    Tienda de estética

    Análisis de requisitos, diseño y modelo de ciclo de vida

    Requisitos
    Funcionales No funcionales
    Crear facturas Software libre
    Ventas de trabajador Tiempos de respuesta breves
    Gestión de stock Imposibilitar 2 peticiones a la vez
    Lectura pistola barras
    Salida a TPV Pantalla táctil
    Ver/editar precios productos Copia seguridad
    Datos trabajadores
    Datos productos

    Puesto que uno de los requisitos es de no permitir 2 peticiones a la vez, se sobreentiende que
    habrá más de un equipo (Pcs). Por lo tanto, habrá un servidor que estará unido en red de área
    local.
    A opción del cliente, cada X tiempo se hará una copia de la base de datos a un servidor externo
    (pudiendo ser el nuestro).
    Se plantea de la siguiente forma:
    Un ordenador hará de servidor* (con Apache). Luego, otros dos o más ordenadores tendrán el
    programa que se conectará al servidor, donde estarán todos los datos. Todos usarán Windows.
    * O bien usará un servidor nuestro en remoto, pagando un mantenimiento. De ser así,
    el cliente ha de tener acceso a internet.

    Modelo
    Puesto que parece que el cliente tiene los requisitos bastante claros, que la aplicación no es
    excesivamente compleja, y que no se requieren cambios posteriores (el producto final no va a
    actualizarse), implementaremos un modelo en cascada retroalimentada (previa firma de los
    requisitos por parte del cliente).
    Diseño
    Estructura básica

    Base de datos relacional (muy básica).


    Faltan añadir datos explícitos como “Seg. Social, DNI, ...”
    Codificación
    Podríamos usar un lenguaje
    estructurado, pero teniendo en
    cuenta que hay un equipo de
    programadores y que habrá
    cierta retroalimentación de
    modelo, mejor uno orientado a
    objetos.
    Aunque a mi elección sería Java
    o Python (puede ser POO), en
    su lugar usaremos C++, ya que
    uno de los requisitos es que el
    programa sea rápido. Java y
    Python son rápidos
    (seguramente basta y sobra para
    la aplicación en cuestión), pero lo es aún más un lenguaje compilado. Y uno de los requisitos
    explícitos es la velocidad.
    Para el desarrollo usaremos el IDE CodeBlocks (por ser gratuito, libre) y MinGW (por ser
    referente) como compilador (Windows) para el código objeto y ejecutable (.exe).
    Como base de datos y gestor de DB, usaremos MySQL y PHP, por ser gratuito y referente.
    Usará Apache como software de servidor. El PC usado como servidor, usará el propio Apache
    y configurará para crear copias de seguridad en otro servidor de forma automática en horas
    nocturnas.

    Pruebas
    Se harán pruebas por módulos (unitarios) durante la codificación del proyecto, usando el
    método de caja blanca. Comprobando que no hay problemas, especialmente en cuanto a la
    conexión con la base de datos se refiere y sus tipos de datos. Y pruebas conjuntas al finalizar
    cada módulo. Se harán pequeños reajustes de diseño si fuera necesario.
    Finalmente se harán pruebas del programa en conjunto antes de la entrega del producto final.
    Y, por supuesto, unas pruebas Beta una vez instalado todo, tanto en el servidor como en los
    ordenadores de usuario. Probando que hay perfecta conexión a la base de datos desde los
    terminales cliente, así como que no pueden hacerse peticiones simultáneas.
    Todas las pruebas de programa conjunto una vez instalado se harán con el modelo de caja gris.
    Probando que los datos recibidos sean los esperados. Y especialmente probando que no haya
    errores con la base de datos en cuanto a claves y duplicados se refiere.

    Explotación y mantenimiento
    El único mantenimiento como tal, será correctivo, en caso de algún fallo imprevisto. No habrá,
    en un principio, ni perfectivos, ni evolutivos ni adaptativos. Pues no debería requerirlo.
    Se instalará el programa en las terminales y la base de datos en el servidor de área local (o
    remoto si procede), y se conexionarán para que todo funcione correctamente. Si el servidor está
    en local, se implementará un SAI por posibles cortes eléctricos, para garantizar sus datos
    estables.
    Se hará una formación al usuario sobre su funcionamiento.
    Se le programará una copia de seguridad a un servidor externo de su elección, pudiendo usar el
    nuestro (con un coste). En caso de usar nuestro servidor tanto para la base de datos como para
    su copia de seguridad, se usarán terminales distintos.
    Durante dos años de garantía, podrá solucionar dudas telefónicas de forma gratuita. Las visitas
    por nuevas instalaciones de equipos etc. se pagarán a parte. Las visitas por error del cliente se
    pagarán a parte (salvo la primera anual).
    Transcurrido ese tiempo, finalizará la relación con el cliente, salvo que mantenga las copias de
    seguridad y/o la base de datos en nuestro servidor.

    Documentación
    Durante todas las fases se llevará a cabo la documentación de errores y cambios producidos,
    para que pueda ser consultado por los diseñadores / programadores en caso de necesitarlo por
    algún error imprevisto.
    A parte, se creará documentación de funcionamiento del programa cliente para los usuarios, así
    como un apartado de solución a problemas.
    No se creará, sin embargo, documentación del uso del servidor para los usuarios, pues tanto si
    es un servidor local como remoto, el cliente no necesita tocarlo en ningún momento.

    José L. Cifre

    También podría gustarte