204019 Fase4 Cristian Camilo Villada pg54

ANALISIS DE REQUISITOS 204019A_363

UNIDAD 3: FASE 3 – DIAGNÓSTICO

PAOLA ANDREA MARMOLEJO

CRISTIAN CAMILO VILLADA ZAPATA 1017167655

UNIVERSIDAD NACIONAL ABIERTA A DISTANCIA MEDELLÍN - ANTIOQUIA 2017

Introducción El presente documento tiene como propósito definir las especificaciones funcionales, no funcionales y del sistema para la implementación de una aplicación WEB que permitirá istrar y consultar la información de cuentas empleadas por los comensales s de nuestro restaurante en (Restaurante Colombia Deli) Antioquia Medellín, utilizada por istración, meseros, chefs y público en general.

El presente documento tiene como objetivo brindar una descripción detallada de los requerimientos del sistema para el sistema de gestión de requisitos y casos de pruebas que se desarrollará para la empresa Restaurante Colombiana Deli, obtenidos en el relevamiento realizado por parte del equipo de analistas en conjunto con el cliente. El sistema que se pretende construir tomará las funciones provistas por un sistema actual llamado Programm Restaurant, agregando nuevas funcionalidades y mejorando las ya existentes.

Igualmente se realiza este documento donde se encuentra la especificación de los requerimientos completos de la aplicación Restaurante Colombia Deli, partiendo de la definición de un requerimiento como aquella característica que debe tener el sistema o una restricción que debe satisfacer para que sea aceptado por el cliente. La especificación de los requerimientos y de las restricciones está escrita en términos que el cliente los pueda entender con la finalidad de que la comunicación entre el equipo de desarrollo y el cliente sea clara y constante

Problema Ser reconocida, donde presta sus servicios, como la empresa más confiable de Alimentación masiva. Misión, Nuestro propósito es la continua identificación y satisfacción de las necesidades de nuestros clientes y s, suministrando alimentos seguros con una excelente actitud de servicio, además de contribuir al bienestar

de

nuestros

colaboradores,

la

comunidad

y

los

accionistas.

Valores, Restaurante Antioqueño se identifica por una alta vocación de servicio, por tal motivo se inculcan los valores de respeto: para todos nuestros clientes internos y externos. El respeto en el trato, en sus creencias y costumbres debe ser una característica que se refleje en nuestro sitio de trabajo y en nuestros hogares. Cumplimiento de las normas: nuestros actos deben ceñirse al cumplimiento y respeto por las normas legales, las establecidas por la organización y por nuestros clientes. Honestidad: valor que representa cada uno de nuestros colaboradores donde se encuentren en su desempeño diario en sus actos y en las relaciones con los clientes. Transparencia: apertura y flujo de información de la organización a todos los públicos de interés, permitiendo su revisión y análisis. Donde la empresa ha crecido de una manera increíble de la manera donde tenemos que mostrar a nuestros s que estamos acordes con la tecnología, donde implantamos esta nueva aplicación para crecer en todos los sentidos y hacerla cada vez más grande y mejor.

¿Tendrá algún problema en la conexión de internet y alojamiento a cualquier dispositivo móvil? En la investigación que se realizó para esta aplicación se encontró que en la actualidad el crecimiento de internet ha impactado directamente en la que puede ser la seguridad de la información manejada cotidianamente en los propietarios de cada aplicación realizada por los developer, analistas, diseñadores todas las personas implicadas en el proyecto. En nuestro sitio se debe manejar una seguridad extensa ya que sitios comercios electrónicos, servicios monetarios,

servicios de istración de base de datos personales, bancos e incluso redes sociales contienen información sensible que en la mayoría de los casos resulta ser muy importante. Se puede decir que uno de los puntos más críticos para una aplicación o website puede ser desde la seguridad en Internet ya que son las herramientas que interactúan de forma directa con los s, en este caso los servidores web. En los años de experiencia en esta rama de la ingeniería de sistemas es común escuchar o leer sobre fallas en los sistemas de protección de los servidores donde alojamos nuestra información en estos casos aplicaciones o website etcétera pero más frecuentemente utilizados por nosotros los s, hago un claro ejemplo de Apache, NGINX, IIS o en los lenguajes de programación que se llegan a utilizar en que son inscritas las aplicaciones. Sin embargo, la mayoría de los problemas se han llegado a detectar en servicios web no son provocados por fallas de ninguna de estas partes, si no problemas se generan por malas prácticas de parte de los programadores que por ahorrar código o explicaciones de educadores o tutoriales realizamos. Se debe entender que programar aplicaciones web seguras no es una tarea fácil, ya que requiere por parte del developer, no sólo cumplir con el objetivo funcional básico de la aplicación, sino una concepción general de los riesgos que puede correr la información procesada por el sistema, igualmente hay developer hobbit los que llamamos HACKER, son personas con unos conocimientos extremadamente envidiables por mi persona donde hay unos que sus conocimientos los generan para buenas causas lastimosamente hay muchos que lo expresan para propósitos malignos .

La falta de visión de los empresarios sobre la tecnologías móviles parece injustificable, pero lo cierto es que la falta demasiada visión puede convertirse en un obstáculo para las empresas que buscan aprovechar los beneficios de las aplicaciones móviles, pues tiene efectos tanto estratégicos como a nivel de procesos concretos. Con frecuencia, a pesar del enorme esfuerzo que muchas empresas llevan a cabo en el desarrollo de aplicaciones móviles, los líderes dentro

de las mismas olvidan por completo la forma en que dichos desarrollos afectan su modelo de negocio, sus operaciones del día a día y el rol de muchos de sus empleados.

Objetivo

Justificación El objetivo principal del documento planteado es plasmar de forma clara, concisa y correcta las grandes necesidades que puede tener el cliente en términos del software que se debe realizar, llegar la meta establecida desde los principios de la formulación de análisis con las fechas pautadas para el cliente y empresa. La documentación de esos será guía para validar e inspeccionar la construcción del software en cada una de sus etapas que se realizaran con entregas estipuladas en una fecha donde se hay inconvenientes se establecerán en el documento o vía correo, es decir este documento será utilizado como herramienta para la trazabilidad de requerimientos y respaldo para cada uno de los lados del cliente y . Como se acaba de informar anteriormente el documento se encuentra dirigido al cliente y al equipo de desarrollo, equipo analítico, equipo de pruebas. Adicionalmente también puede ser usado por los s que utilizarán el software donde abran cambios y que necesiten definir nuevos requerimientos.

Para dar información genérica primordial el principal objetivo que se planteó en este proyecto fue el de desarrollar una herramienta software que permita la recepción y transferencia de información digital (Entre el chef, los meseros, comensales) desde y hacia navíos que se hallen en poco tiempo una respuesta inmediata, donde la única vía de comunicación posible para este tipo de información sea la comunicación vía vga.

Descripción del proyecto Somos una organización líder, asesorando a nuestros clientes por más de 29 años de experiencia en servicios de alimentación masiva. Soportados por una sólida estructura istrativa y tecnológica, con profesionales especializados en calidad, nutrición, gestión humana, operaciones, normatividad alimentaria y diseño de servicios de alimentación. Operamos en diferentes sectores: industrial, clínico, educativo y campamentos. Por nuestra calidad, respuesta oportuna a los requerimientos del cliente, excelente servicio y alta tecnología, nos reconocen como una de las más importantes empresas de alimentación masiva del país. Nos constituimos en 1985 en la ciudad de Medellín, para atender mediante el sistema de concesión, el área de alimentos y bebidas del Hotel Nutibara. Al inicio en la empresa contábamos con alrededor de 24 colaboradores. Actualmente este número ha aumentado a 1300 empleados, entre directos e indirectos. Quienes son para Salamanca junto con el cliente externo lo más importante. Por tal motivo en la empresa le ofrecemos a nuestros colaboradores diferentes actividades y beneficios que generan calidad de vida, compromiso organizacional y sentido de pertenencia. En 1986 iniciamos la prestación de servicios a sector industrial, en 1988 se nos otorga el primer contrato en campamentos para prestar los servicios de alimentación, aseo, alojamiento, lavandería y proveeduría. Ese mismo año incrementamos la actividad de alimentación masiva con la adjudicación de nuevas empresas, en 1992 nos dedicamos exclusivamente al sector de alimentación industrial, incorporando a nuestro portafolio de clientes grandes empresas de la ciudad de Medellín. El sistema funcionará en un ambiente web, por lo que deberá ser capaz de funcionar en cualquier plataforma con un navegador web instalado, siempre y cuando disponga de conexión al servidor en que va a estar corriendo la aplicación, ya sea por Internet o alguna red privada.

Documento de requisitos formalmente elaborado Requisitos específicos A continuación se detallan los requisitos funcionales que el sistema deberá implementar. Todos los requerimientos especificados a continuación están pendientes de aprobación.

RF-01 - Autenticación y autorización de s: El sistema deberá permitir a los s iniciar sesión en el mismo (En este caso serán los meseros quienes tomen las órdenes). Esto incluye brindar un sistema de soporte a la autenticación y autorización de s, así como de gestión de los mismos. También deberá permitirles cerrar una sesión iniciada previamente. Se deberán soportar los siguientes roles: analista funcional, desarrollador, tester y cliente. También existirá un del sistema y otro para cada proyecto. Cada uno de estos s tendrá diferentes permisos y visibilidad de recursos del sistema dependiendo del rol que cumplan.

RF-02 - Gestión de proyectos - El sistema deberá permitir gestionar la información correspondiente a un proyecto de software (esto es, realizar el ingreso, consulta y modificación de los mismos). El proyecto es una entidad que agrupa requisitos y casos de prueba, así como s con distintos roles que actúan sobre estos. Los proyectos están asociados a una organización, que también debe representarse en el sistema. Las organizaciones tienen asociadas áreas de negocio, y también procesos de negocio.

Requisitos comunes de los interfaces Descripción detallada de todas las entradas y salidas del sistema de software.

Interfaces de El sistema deberá permitir el ingreso de requisitos por parte de los s. Los requisitos a ingresar podrán ser tanto funcionales como no funcionales, así como también transicionales.

El sistema deberá permitir la actualización de cualquier atributo de un requisito previamente ingresado, ya sea por un analista funcional o por el cliente mismo. Esto incluye permitir cambiar el estado de un requisito, y su prioridad. Luego de realizar cualquier cambio, el sistema deberá crear una nueva versión del requisito, manteniendo el historial de todas las versiones anteriores.

Interfaces de hardware El sistema permitirá el ingreso de casos de prueba junto con sus datos asociados. Los casos de prueba podrán ser de regresión o no, además de manuales o automáticos.

Interfaces de software El sistema deberá permitir realizar el modelado de un requisito mediante una herramienta de modelado de procesos de negocio. Para esto, se deberá realizar una integración con la misma.

Interfaces de comunicación El sistema deberá permitir cambiar el estado asociado a los requisitos. Los estados válidos para un requisito son: - Borrador - En espera de aprobación - Aprobado - Rechazado

Para cada cambio de estado se deben registrar tanto la fecha como al responsable del mismo. El sistema deberá registrar también el histórico de los

estados por los que ha pasado un requisito. Para el caso de un cambio a estado Aprobado o Rechazado, todos los que se encuentran registrados como interesados por el requisito, además del solicitante, deben realizar el cambio de estado en forma unánime. Solo es posible realizar cambios de estado desde Borrador a En espera de aprobación, de allí a Aprobado o Rechazado, y luego de cualquiera de estos dos a Borrador.

Requisitos funcionales A continuación se detallan los requisitos funcionales que el sistema deberá implementar. Todos los requerimientos especificados a continuación están pendientes de aprobación

Requisitos no funcionales Requisitos de rendimiento

RF-1 - Asignación de casos de prueba a Tester El sistema permitirá asignar un caso de prueba (o un conjunto de casos de prueba) a un Tester para su ejecución. ● RF-2 - Ejecución de casos de prueba El sistema permitirá realizar la ejecución de casos de prueba (o planes de prueba), tanto en forma automática como manual. En el caso de la ejecución automática, se realizará una integración con la herramienta (Búsqueda herramienta internet) para este propósito. Los resultados de las pruebas deberán ser obtenidos y registrados para su posterior evaluación. En el caso de la ejecución manual, el Tester deberá completar los resultados de la ejecución de los casos de prueba. Los datos a completar son los mismos que en la herramienta (Búsqueda herramienta internet). ● RF-3 - Estimaciones sobre casos de prueba El sistema permitirá ingresar estimaciones a nivel de casos de prueba. Las estimaciones harán referencia al tiempo que se estima que llevará determinada tarea relacionada con los casos de prueba. Las estimaciones se pueden hacer sobre el tiempo que lleva el diseño de

un caso de prueba, el tiempo de preparación del mismo y el tiempo de ejecución que llevará. ● RF-4 - Priorización de los casos de prueba dentro de un plan de prueba El sistema permitirá asignar prioridades a los casos de prueba dentro de un plan de ejecución. Se almacenarán los cambios de prioridad realizados (tanto fecha como responsable). ● RF-5 - Creación de planes de pruebas El sistema permitirá la creación de planes de pruebas. Se podrán agrupar distintos casos de prueba en un único plan de pruebas. Los planes de prueba se entienden como un conjunto de casos de pruebas planificados para su ejecución. Los planes de prueba tendrán registrado al responsable del mismo, y podrán ser ejecutados, como en RF-2. Seguridad El sistema deberá permitir la actualización de cualquier atributo de un requisito previamente ingresado, ya sea por un analista funcional o por el cliente mismo. Esto incluye permitir cambiar el estado de un requisito, y su prioridad. Luego de realizar cualquier cambio, el sistema deberá crear una nueva versión del requisito, manteniendo el historial de todas las versiones anteriores.

Fiabilidad El sistema deberá proveer una interfaz amigable al , que sea fácil de aprender y de usar. Se pretende que la navegación entre las distintas funcionalidades del sistema sea realizada en forma sencilla y en pocos pasos. La interfaz deberá ofrecer funcionalidades para realizar tareas repetitivas en forma automática.

Disponibilidad Especificación de los factores de disponibilidad final exigidos al sistema. Normalmente expresados en % de tiempo en los que el software tiene que mostrar disponibilidad.

Mantenibilidad El sistema deberá permitir la actualización de cualquier atributo de un requisito previamente ingresado, ya sea por un analista funcional o por el cliente mismo. Esto incluye permitir cambiar el estado de un requisito, y su prioridad. Luego de realizar cualquier cambio, el sistema deberá crear una nueva versión del requisito, manteniendo el historial de todas las versiones anteriores.

Portabilidad El estado del arte de las aplicaciones de hoy proporciona un aspecto consistente que comienza con el paquete del producto y se manifiesta a través de los menús de la instalación, las pantallas del sistema, los sistemas de ayuda, los diálogos con el , etc. Esta sección define las necesidades y tipos de etiquetas a para ser incorporado en el código, por ejemplo, derechos de propiedad literaria y avisos patentes, logotipos corporativos, iconos estandarizados y otros elementos gráficos, etc.

Otros requisitos Guías de instalación, configuración y archivo Léame, En esta sección especifique si el sistema de software contendrá instrucciones para instalación y configuración. Además si se incluirá el típico archivo Léame, que puede incluir las Novedades de la versión, discusión de compatibilidad con versiones anteriores, documentación de errores conocidos y soluciones alternativas.

Reflexiones sobre el aprendizaje A través de los años se ha podido constatar que los requerimientos o requisitos son una pieza fundamental en un proyecto de desarrollo de software, ya que marcan el punto de partida para actividades como la planeación, básicamente en los que se refiere a las estimaciones de tiempos y costos, así uno de los principales mecanismo de control con lo que se contará durante la etapa de desarrollo. Además la especificación de requerimiento es la base que permite verificar si se alcanzaron o no los objetivos establecidos en el proyecto ya que estos son un reflejo detallado de las necesidades de los clientes o s del sistema y es contra lo que se va estar verificando si están cumpliendo las metas trazadas.

Conclusiones Por debajo de la saludable e impresionante diversidad de temas que conforman los contenidos de las tesis doctorales y trabajos de final de máster, hay una estructura reconocible que nosotros denominamos modelo canónico. Reconocer tal modelo nos puede ayudar a afrontar con mayor garantía de éxito el trabajo de largo aliento que suelen requerir los títulos de ciclo superior de la universidad. Y dentro de este modelo, identificar los componentes de la Introducción y las Conclusiones es esencial para poder entregar un trabajo redondo.

Referencias bibliográficas 

https://es.wikipedia.org/wiki/Especificación_de_requisitos_de_software



http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:pis:ejemplo_de_ especificacion_de_requerimientos_-_para_sesion_9.pdf



http://pegasus.javeriana.edu.co/~CIS0910IS03/archivos/SRS_1.0.pdf



https://www.procuraduria.gov.co/infosim/media/file/VERSIONES_EN_PDF/ Etapa4-ReqFunc.pdf



http://repositorio.uch.edu.pe/bitstream/handle/uch/82/Osorio_Alvarez_Neil_ Angelo.pdf?sequence=1&isAllowed=y