Evidencia: Documento con especificación de requerimientos/ GA1-220501092-AA4-EV02 APRENDIZ Yuver Harbey Martínez Parra Ficha 2977409 TECNOLÓGO ANÁLISIS Y DESARROLLO DE SOFTWARE 8 DE AGOSTO DE 2024 Introducción: En el presente documento se busca llevar a cabo un análisis y especificación de requerimientos y requisitos previamente establecidos para desarrollar el software en cuestión. Se planea hacer una breve introducción al software que se quiere lograr, seguido de algunas especificaciones en su desarrollo para proseguir con un listado de requisitos tanto funcionales como no funcionales que se estima que el programa pueda solucionar. A partir de la lista de requisitos el presente documento busca poder describir cada requisito empleando el estándar IEEE830, el cuál consiste en una manera efectiva de garantizar la calidad y la eficacia de un software, desde sus etapas de planeación hasta la finalización de su desarrollo. Descripción de los requisitos/Estándar IEEE830 En este documento mencionaremos de qué tratará el software a desarrollar, el listado completo de requisitos y el apartado que divide requisitos funcionales y No funcionales, además de otras especificaciones del programa. Por ende, a continuación, presentaremos éste mismo planteamiento de requisitos con el estándar de definición de requisitos IEEE830. ¿Qué es el Estándar IEEE830? El estándar IEEE830 es una técnica de definición y organización de requisitos que se utiliza en el ámbito del desarrollo informático para poder definir correctamente requisitos en el desarrollo de un programa. Este estándar en el desarrollo de software permite realizar acuerdos entre las necesidades del cliente y el desempeño del equipo desarrollador. A continuación, se presenta una tabla de contenido para darle inicio al desarrollo del documento con el estándar IEEE380. 1. Introducción del documento. a. Propósito del documento ERS. b. Alcance. c. Ámbito del sistema. d. Referencias. e. Visión general del documento. 2. Descripción general. a. Perspectiva del producto. b. Funciones del producto. c. Características de los usuarios. d. Restricciones. e. Suposiciones y dependencias. f. Requisitos futuros. 3. Requisitos específicos. a. Listado completo de requisitos del software. b. Requisitos funcionales. i. Listado de requisitos funcionales. 1. Perspectiva de un posible empleado. 2. Perspectiva del administrador de la empresa 3. Historias de usuario c. Requisitos no funcionales. i. Listado de requisitos no funcionales. 1. Perspectiva de un posible empleado. 2. Perspectiva de un administrador de la empresa. ii. Seguridad. iii. Fiabilidad. iv. Disponibilidad. v. Mantenibilidad. vi. Portabilidad. 3. Historias de usuario d. Interfaces externas. e. Funciones. f. Requisitos de rendimiento. g. Restricciones de diseño. 4. Apéndices. 5. Índice. Introducción del documento: Propósito del documento ERS: En el presente documento se busca emplear la estructura de documentos establecida por el estándar IEEE380-1998 para establecer los requisitos que el software en cuestión debe cumplir. Así, pues, se detallarán otros aspectos de éste documento para el desarrollo del estándar IEEE830, además de que éste documento contará con una descripción general del software en cuestión, un apartado con el listado de requisitos de éste, un apéndice para los requisitos específicos y otros apartados de redacción. Alcance: Se estima que el alcance del software sea de Libre uso, que se pueda usar tanto de manera individual como un usuario común y corriente a través de accesos de registro e inicio de sesión, así como de manera empresarial en la que la empresa podrá aprovechar éste software de manera más administrativa. Ámbito del sistema: Teniendo en cuenta la situación en la que una empresa se encuentra, en la que tiene problemas y defectos con su área de contratación, dicha empresa busca una mejor alternativa para poder realizar contrataciones virtuales a través de una plataforma (con la cuál no cuenta por ahora). La idea de éste software es crear una herramienta de contratación empresarial, una manera en la que la empresa pueda mejorar su área de contratación. Referencias: Aquí se almacenarán todas las referencias utilizadas al momento de redactar el presente documento. https://estandaresti.wordpress.com/2016/12/17/estandar-ieee-830-1998/ https://es.slideshare.net/slideshow/estndar-ieee-8301998-especificacn-de-requisitos-desoftware/71569420 https://zajuna.sena.edu.co/zajuna/pluginfile.php/2170492/mod_page/content/6/Guia_aprend izaje_01.pdf https://historiadelaempresa.com/lenguajes-de-bases-de-datos https://www.configuroweb.com/lenguajes-programacion-mas-usados-2024/ https://www.lifeder.com/programacion-orientada-a-eventos/ https://apx.school/blog/programacion-orientada-a-objetos https://lovtechnology.com/que-es-la-programacion-multiparadigma-como-funciona-y-paraque-sirve/ https://rootstack.com/es/blog/desarrollo-software-lenguajes https://www.atlassian.com/es/agile/project-management/user-stories https://historiadelaempresa.com/caso-de-uso Visión general del documento: A continuación, en el documento veremos una descripción general del producto de software, sus funciones, características de sus usuarios, restricciones, suposiciones y dependencias, entre otros aspectos del software a desarrollar. Descripción general: Perspectiva del producto: Para la perspectiva del producto vamos a describir todos aquellos factores que afectan al producto y sus requisitos desde una perspectiva más externa. No vamos a recalcar los requisitos, sino el contexto en el que actúan. Funciones del producto: Como se mencionó en el caso de la empresa que necesita mejorar su contratación, la idea que va a rondar el desarrollo del software es poder crear una herramienta virtual que le sea de utilidad a empresas que quieran mejorar su contratación a través de dicha herramienta. La herramienta debe ser clara, intuitiva y sencilla de usar, contar con un apartado exclusivo para una comunidad de soporte y de ayuda mutua y tener ésta herramienta debe contar principalmente con 2 apartados dentro de sí o, en su defecto, 2 formas de misma aplicación, pero de diferente forma, para dividir los apartados a los que el software va dedicado. Características de los usuarios: Como se mencionó anteriormente, se planea que el software tenga 2 modos distintos o 2 tipos de perfiles para diferentes tipos de usuario. Éstas 2 modalidades deben ser: 1. Un apartado de la aplicación dedicado a usuarios comunes y corrientes, es decir, un usuario promedio y casual que pueda acceder normalmente con su usuario y contraseña. 2. Un apartado de la aplicación dedicado a administradores de tipo empresarial, es decir, un perfil que tome decisiones a través de la plataforma en nombre de la empresa en la que trabaja, para que sea el vocero de las decisiones de dicha empresa dentro de la plataforma. Así, pues, lo que se estima es un software que sea capaz de tener 2 tipos distintos de perfiles, y que el perfil de tipo administrativo represente las decisiones que la empresa decida emplear frente a los diferentes perfiles de tipo casual que vayan llegando. Restricciones: En cuanto a restricciones, los principales aspectos que se tienen en cuenta son: - Acuerdos de licencia: la licencia de uso debe contener un contrato de términos de usuario final en el que se evidencie cómo será el tratamiento de datos, cookies y rastreos de red que se le realizarán al usuario. - Documentación legal: la aplicación debe contar con un apartado de utilidades legislativas en la que se evidenciará que cualquier actividad de un usuario A y un usuario B o un grupo de usuarios BCD… es totalmente ajena a la aplicación, y que cualquier mal uso o incumplimiento de normativas legales que se realicen con el software no es responsabilidad del equipo desarrollador de éste, ya que, como software, solo es un intermediario para cumplir un propósito (mejorar la contratación empresarial). - Reporte de errores(opcional): Para el usuario final, existe la posibilidad de que se presenten errores y fallas lógicas al momento de la ejecución del programa. En estos casos, el usuario es libre de reportar la situación con el equipo desarrollador para que éste error pueda ser solucionado gracias a la colaboración del usuario final. Así pues, esta colaboración será totalmente opcional, y ningún usuario se verá en obligación de reportar errores. Suposiciones y dependencias: En éste apartado es importante recalcar qué aspectos deberá tener en cuenta el usuario final para utilizar el software, como por ejemplo requisitos que el sistema (el equipo del usuario) debe contar, refiriéndonos a Hardware y componentes (memoria RAM, procesador, almacenamiento). Así, pues, dividiremos las Suposiciones y Dependencias como se muestra a continuación: - SUPOSICIONES: El usuario debe contar con un equipo informático capaz de soportar los requerimientos del software (los cuales se especulan no serán demasiado demandantes). Además, el equipo deberá contar con un sistema operativo que le permita funcionar al 100% de capacidad sobre el software. El usuario debe contar con internet al momento de iniciar sesión, navegar por la aplicación y revisar postulaciones de empleo de diversas empresas, así como las empresas deberán contar con soporte y revisión de sus solicitudes antes de ser aceptadas en la plataforma. Como última suposición (por el momento) todos los perfiles deberán ser constantemente supervisados por moderadores de la plataforma para encontrar y eliminar situaciones que no cumplan con normativas de uso del software (como lo sería lenguaje obsceno, estafas, fraude, perfiles falsos o reportes hechos por los mismos usuarios y sus detalles). - DEPENDENCIAS: La plataforma seguirá un sistema de envío de peticiones en las que la aplicación (A) enviará, almacenará y recibirá peticiones (paquetes de datos que pueden ser solicitudes de empleo, datos de hojas de vida y nuevas postulaciones entrantes) a partir de una respuesta con un servidor funcional (B) para mantener una conexión funcional (A-B). Además, el software contará con un servicio de respaldo (C) que servirá como soporte de último recurso en caso de que el servidor principal (B) tenga defectos o no esté funcional (relación A-C). El software también contará con librerías y documentos de soporte donde se documentarán los diferentes errores que vayan saliendo a flote conforme el software se va desarrollando hasta que esté funcional y en adelante, es decir, un reporte de errores y crasheos de aplicación (soporte X). También, se contará constantemente con diferentes equipos que mantendrán estables los servicios y la aplicación, ya sean desarrolladores principales, arquitectos de software, pentesters (tanto de equipo rojo como de equipo azul), expertos en conexiones con servidores y demás equipos que hagan el software funcional. Requisitos futuros: A requisitos futuros nos referimos al concepto de probables requisitos que, luego de que se haya terminado y publicado satisfactoriamente el software, pudieran surgir nuevos desafíos que el software deba cumplir para que sea más completo, agradable, eficiente o nuevos cambios que se vayan presentando. Un posible requisito futuro sería una mejora en la interfaz gráfica del usuario. Al - desarrollarse una primera versión, puede que el software presente un apartado visual un tanto ambiguo y hasta incluso obsoleto, por lo que añadir contenido dinámico y opciones interactivas en los diferentes menús sería una gran opción. Requisitos específicos: Listado de requisitos generales: Ya que revisamos el funcionamiento teórico del software, a continuación, procederemos a retratar los requisitos generales que nuestro software deberá solucionar. Además, cada requisito viene con un formato de caso de uso en el que podremos apreciar de forma más práctica la utilidad de cada requisito: - El software debe tener un soporte constante 24 horas los 7 días a la semana (para una captura exacta de fallos que vayan surgiendo para posteriores actualizaciones). Identificador: VRF01-2024 Título: “Verificación del soporte del software”. Descripción: Se procede a verificar que el software mantenga un soporte constante de 24 horas los 7 días a la semana para que se puedan capturar fallos y errores presentes en el sistema al momento de su ejecución. Actor primario: El software (estando activo) Condiciones previas: El software debe haber arrancado correctamente para proceder con su monitoreo. Además, debe estar con todos sus servicios en línea y funcionales. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 7. Escenario de éxito principal: El software puede mantener un monitoreo constante y dicho monitoreo permite atrapar errores y fallas en la ejecución del programa. Flujos alternativos del programa: a) El software presenta problemas con su monitoreo y no puede mantener una revisión constante. Frecuencia de uso: Éste requisito se estará usando cada vez que el software se inicie en un computador, monitoreando todo el tiempo de actividad. Criterios de aceptación: El requisito será aceptado cuando se evidencie que el programa puede mantener un registro constante de todo el tiempo de actividad del software para capturar y especificar errores. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: Éste requisito debe ser de los primeros en ser implementados. El poder revisar cada error que vaya saliendo de forma entrante hará que el desarrollo del software conste de mejor revisión y de mejor calidad de uso. - El software debe ser capaz de enviar solicitudes (peticiones de empleo) desde los posibles empleados a los administradores de la empresa de manera fluida. Identificador: VRF02-2024 Título: “Envío de solicitudes de empleo por medio de la plataforma.” Se procede a verificar que el software sea capaz de enviar, desde la perspectiva de un usuario común, solicitudes de empleo a una postulación de empleo Descripción: que haya sido, desde la perspectiva de un administrador, publicada previamente por la empresa. Actores primarios: Usuario común. Usuario administrativo. Condiciones previas: El usuario común debe haber iniciado el programa, iniciado sesión y haber localizado dentro de la plataforma una publicación de esfuerzo vigente para poder hacer una petición de empleo. El usuario administrativo debe haber iniciado el programa, iniciado sesión y tener acceso al repositorio de solicitudes de empleo para gestionar la solicitud que el usuario común envió en la postulación. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 5. Escenario de éxito principal: El usuario común pudo enviar satisfactoriamente su solicitud de empleo mediante la postulación de empleo. El usuario administrativo pudo gestionar correctamente la solicitud de empleo enviada por el usuario común. Flujos alternativos del programa: - El usuario común tuvo problemas para acceder a la postulación de empleo. - El usuario común no pudo adjuntar su solicitud en la postulación de empleo. - El usuario común no pudo presionar el botón correcto para el envío de su solicitud por problemas de la interfaz gráfica. - El usuario administrativo no tuvo acceso al repositorio de las solicitudes de empleo de la empresa. - El usuario administrativo no pudo gestionar correctamente la solicitud del empleado por falta de claridad e información en ésta. - El usuario administrativo no pudo encontrar la solicitud del empleado por problemas con el repositorio. Frecuencia de uso: Éste requisito se estará usando cada vez que un usuario común quiera intentar postularse a un empleo y cada que un administrador deba gestionar una o varias solicitudes de empleo de dicha postulación. Criterios de aceptación: El requisito será aceptado cuando se evidencie que cualquier usuario común puede enviar su solicitud de empleo sin problemas a una postulación y cuando un usuario administrativo pueda gestionar dicha solicitud y darle una respuesta a dicho usuario común. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: El usuario común, aunque envíe su solicitud de empleo, no tendrá seguridad de que será Sí o Sí el seleccionado para el empleo: al ser una postulación, la empresa está en derecho de escoger al perfil más apto, capacitado o recomendado para el empleo, por lo que siempre que se envíe una solicitud de empleo se debe estar mentalizado que se puede llegar a recibir un “No”. - El software debe ser capaz de Administrar dichas solicitudes. Además, debe contar con un conjunto de herramientas (tales como filtros, referencias bibliográficas y espacios de almacenamiento) para operar con estas solicitudes. Identificador: VRF03-2024 Título: “Verificación de las herramientas de gestión de solicitudes del software administrativo” Descripción: Se procede a verificar que el software, desde la perspectiva de un administrador de la empresa, cuente con un conjunto de herramientas adecuadas para la gestión y administración de las solicitudes de empleo que lleguen desde una postulación de empleo. Actor primario: Usuario administrativo de parte de la empresa. Condiciones previas: El usuario administrativo debe haber iniciado sesión en el sistema y debe tener previamente permitido el acceso al repositorio donde se almacenan y gestionan las solicitudes de empleo de la empresa para poder gestionar dichas solicitudes. Así pues, la empresa debe saber todo movimiento que el administrador haga en el repositorio de las solicitudes para evidenciar qué sale y qué entra. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 7. Escenario de éxito principal: El administrador pudo gestionar las solicitudes de empleo entrantes de manera satisfactoria, filtrando la cantidad total de solicitudes gracias a las herramientas de la plataforma y encontrando la solicitud más apta para el empleo. Flujos alternativos del programa: - El administrador no pudo encontrar ninguna solicitud conveniente para el empleo. - El administrador no pudo diligenciar ninguna respuesta al perfil alternativo por problemas de la plataforma o de conectividad. - La respuesta que el administrador le envió al perfil más apto no fue recibida por éste, por problemas de conectividad de la empresa. Frecuencia de uso: Éste requisito será empleado con una frecuencia media, con cierta regularidad, ya que puede que no todos los días una solicitud tenga nuevos postulados, así como puede que en un día se deban administrar varias solicitudes de empleo. Criterios de aceptación: El requisito será aceptado cuando se evidencie que el usuario administrativo puede gestionar satisfactoriamente solicitudes de empleo que residan en el repositorio de la empresa que guarde todas éstas solicitudes. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: El usuario administrativo debe saber perfectamente lo que hace, ya que al tener acceso al repositorio de solicitudes de empleo debe ser consciente de todo cambio que realice dentro de éste para que no se ocasionen problemas futuros y fallos dentro del repositorio. Se debe tener una seguridad y compromiso total con éste repositorio. - El software debe ser capaz de crear y mantener activo un perfil por persona, ya sea un posible empleado o administrador. Identificador: VRF04-2024 Título: “Verificación del tiempo de vigencia de la sesión de los usuarios activos” Descripción: Se procede a verificar cuánto tiempo puede permanecer activa la sesión de un usuario en la plataforma antes de que se cierre por programación interna del software. Actor primario: Usuario de la plataforma ya sea común o administrativo. Condiciones previas: El usuario debe tener muy en claro sus datos de inicio de sesión, ya que la plataforma no tendrá atajos de acceso fácil, por lo que no se deben perder los datos de inicio de sesión. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 3 Escenario de éxito principal: El requisito será desarrollado satisfactoriamente cuando se evidencie que éste puede mantener una sesión activa durante un periodo de 10 minutos: al llegar los primeros 5 minutos de inactividad en la aplicación, aparecerá un anuncio en la pantalla que diga “Su sesión está por expirar. ¿Desea extenderla?” seguido de un botón confirmando la opción. De ser así, la sesión podrá durar otros 5 minutos extendida en un periodo de inactividad. Cuando acaben estos 5 minutos, la sesión se cerrará por inactividad. El software no podrá contabilizar el - Flujos alternativos del programa: tiempo en línea de un usuario por fallas en la programación. El botón para extender la sesión en los - primeros 5 minutos no funcionará por fallas en la programación y la sesión expirará igualmente. La sesión no durará 10 minutos, sino 5 - por problemas dentro del programa. Frecuencia de uso: Al contabilizar el tiempo dentro del software, la frecuencia con la que se empleará este requisito será bastante alta. Criterios de aceptación: El requisito será aceptado cuando se evidencie que las sesiones de los usuarios pueden durar 5 minutos sin extensión manual o 10 con extensión manual. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: El tiempo de funcionamiento requerimiento se busca que de se éste reinicie automáticamente cada que el usuario haga algún movimiento o interacción con el sistema: si el cursor se mueve, si se oprime una tecla, si se cambia de pestaña, cualquier interacción manual con el sistema será un reinicio para el contador interno del programa. - El software, al ser desarrollado, debe contar con licencias de uso, las cuales la empresa posteriormente al desarrollo y uso de este software decidirá si se va a volver una licencia comercial apta para todo público. Identificador: VRF05-2024 Título: “Revisión de licencias legales de uso del software.” Descripción: Se procede a validar el aspecto de la permisividad y licencias de uso que el software en cuestión debe contener para su uso seguro y correcto según los marcos de las leyes cibernéticas. Actor primario: Equipo especializado en la revisión de licencias de uso, términos y condiciones y seguridad en internet. Condiciones previas: - El software debe ya tener un prototipo del acuerdo a qué permisos y términos se le van a ofrecer a los usuarios para usar el software. - El equipo que se encargará de revisar las licencias de usuario debe actuar bajo un conjunto de parámetros que establece qué condiciones se pueden añadirle al software y qué no, además de información sobre el equipo desarrollador (número de contacto, correo electrónico, redes sociales, página oficial, entre otros elementos). Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 8. Escenario de éxito principal: Cuando el equipo de revisión especializado haya podido hacerle las revisiones adecuadas al prototipo del acuerdo de licencia de usuario, dicho equipo será el encargado de confirmar que todos los aspectos del acuerdo de licencia estén bien establecidos, tengan criterios justos, que todo el contrato de licencia tenga una perspectiva válida para todos los usuarios. Flujos alternativos del programa: - Si el prototipo del acuerdo de licencia presenta fallas en su desarrollo o no es un prototipo útil para la ocasión, se deberá replantear de manera satisfactoria la idea del contrato de términos y hacer un nuevo prototipo para su posterior ejecución. - Si el prototipo de software no termina siendo aprobado por el equipo, dicho prototipo será posteriormente modificado y repensado para llegar a unos mejores términos. Frecuencia de uso: Ya que éste requisito se verá aplicado cada vez que un usuario nuevo entre y se registre en la plataforma, por lo que su frecuencia y relevancia será muy alta para cumplir con las demandas del tratamiento de datos de los usuarios. Criterios de aceptación: El requisito será aceptado cuando se evidencie que el software cuenta con un contrato de licencia y términos de uso decentes, aceptables por el usuario y que especifiquen qué se hará con los datos proporcionados por el usuario y también qué cosas acepta el usuario en dicho contrato. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: Éste contrato de licencia debe ser completamente específico respecto a cómo se comercializarán los datos del usuario, además de tomar en consideración si dentro del software se mostrarán anuncios. De ser así, el sistema deberá poder recopilar los datos de los usuarios, entender sus gustos y búsquedas más frecuentes y poder recomendarles anuncios a partir de lo que el sistema detecte como intereses potenciales y necesidades del usuario. - El software debe ser ensamblado de tal forma que su tiempo de respuesta, bases de datos y conexiones con servidores tengan un tiempo de respuesta lo más corto posible, para evitar contratiempos y esperas innecesarias por ineficiencias de factores externos al software. Identificador: VRF06-2024 Título: “Identificación y verificación de la eficiencia de los tiempos de respuesta de servicios ajenos al software.” Descripción: Se procede a verificar que todos los servicios de terceros relacionados con el software en cuestión sean fiables, ágiles y dinámicos al momento de la ejecución del sistema. Además, se procede a darle un espacio de análisis y compilación a dichos resultados de análisis para una posterior retroalimentación. Actor primario: Condiciones previas: El software en cuestión. - El sistema ya debe tener afianzadas las conexiones con los servicios de terceros, además debe haberse tenido un desarrollo previo de dichas conexiones con el software. - Los servicios de terceros deben tener conexiones seguras y verificadas, y al ser conexiones para un servicio empresarial deben tener aspectos de seguridad verificados constantemente. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 7. Escenario de éxito principal: Cuando las conexiones con los servicios de terceros sean verificadas y estén afianzadas, se podrá analizar el tiempo que le toma al software interactuar con cada servicio para, posteriormente, poder reconocer qué elementos intervienen con la velocidad de respuesta. Esto para poder mejorarlos y hacerlos más eficientes a través de una codificación más exhaustiva. Flujos alternativos del programa: - Los servicios de terceros o algunos de éstos no momento estarán disponibles al del análisis de comunicaciones, por lo que se deberá pausar la etapa del chequeo de tiempo de respuesta hasta que los servicios se puedan activar y monitorear. - Si los servicios de terceros están activos, pero demuestran errores de conectividad ajenos al software, el equipo especializado se comunicará con los propietarios de dichos servicios para comentarles el problema y que los servicios puedan volver a serle de utilidad al software. Frecuencia de uso: La frecuencia de uso de éste requisito constará de importancia total. El software necesitará estar con la mejor conectividad posible para poder recibir y enviar datos entre servicios de terceros con total eficacia, ya que todos los días (en promedio) se estará utilizando el software. Criterios de aceptación: El requisito será aceptado cuando se demuestre cómo actúan las conexiones con servicios de terceros, qué tanto es su tiempo de respuesta y qué aspectos son retroalimentables y mejorables partiendo desde la primera hacia las consiguientes etapas de desarrollo del software. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: Éste requisito en específico necesita una atención especial por parte del equipo de desarrolladores. Al ser las conexiones entre servicios un elemento clave para poder hacer del software una herramienta fluida y completa para el usuario final, se debe Bajo cualquier circunstancia, asegurar que los servicios que el software utilice estén siempre funcionales o, en el peor de los casos, la mayor cantidad de tiempo posible. - El software debe contar con su propia documentación desde los instantes previos a su creación hasta las versiones que vayan saliendo con el pasar del tiempo. Esto ya que se debe tener un registro exacto de toda modificación y cambio que se le realiza a éste. Identificador: VRF07-2024 Título: “Creación e implementación de la documentación del producto final.” Descriptción: Se procede a asegurar que, en los momentos del desarrollo del software, éste tenga el registro de todo lo que se vaya realizando conforme salgan nuevas versiones de desarrollo del software, elementos tales como arreglos, adiciones, cambios internos y externos y funcionalidades del software. Actor primario: El software en cuestión (en sus etapas de desarrollo). Condiciones previas: - El software ya debe tener una versión previa a la oficial tal como una “Alpha” o una “Beta” en la que se revisará lo más elemental y característico del software. - Se debe tener destinado un documento o archivo para destinarlo al encuentro de errores, arreglos de éstos y demás cambios que vayan surgiendo con el pasar del tiempo. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 4. Escenario de éxito principal: Cuando el software tenga sus primeras versiones de desarrollo ya listas y funcionales, se podrá hacer el registro de todos los errores, fallas, inconvenientes y problemas que fueron surgiendo, además de características de dichos problemas (cómo y qué los producía, con cuánta frecuencia aparecían, cuánto daño le hacía a la ejecución del programa) y cómo se llegó a una solución para cada error. En el caso principal de éxito de éste requisito quedará evidenciado que se pudo crear una documentación de errores y fallos para futuras retroalimentaciones en el desarrollo. Flujos alternativos del programa: - Si, sea por la razón que sea, no se llega a una documentación con el suficiente nivel de requerimiento complejidad, éste no ser podrá completado, por lo que se deberá tener una nueva etapa para crear este registro de errores. - Si dado el caso se llega a perder la documentación exhaustiva, se deberá rehacer dicho documento con la adición de respaldarlo con copias de seguridad para evitar futuras pérdidas. Frecuencia de uso: Al ser un registro que no afecta directamente el flujo de ejecución del programa ni la forma en la que éste actúa, su frecuencia de uso será baja, casi inusual, ya que solo se empleará cuando un desarrollador deba hacerles una revisión a los errores presentes. Criterios de aceptación: El requisito será aceptado cuando se pueda evidenciar que existe una documentación sobre todo fallo existente ya solucionado dentro del software, además de cambios y ajustes que le fue conveniente añadir a éste. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: Al ser un recurso de documentación se debe tener en cuenta que no se tratará como un requisito de funcionalidades del programa, sino como brújula que dirigirá al equipo de desarrolladores hacia un software estable y capaz de responder a todo tipo de problemas. La documentación debe abarcar la mayor cantidad de errores posibles, ya que será gracias a éstos errores que el software funcione de manera estable y dinámica. - El software debe contar con un manual de usuario, redactado de tal manera que cualquier persona pueda entenderlo, aprenderlo y dominarlo. Identificador: VRF08-2024 Título: “Verificación del manual de instrucciones de uso del software” Descriptción: Se procede a validar que exista un manual de instrucciones acerca del software en el que se le especifique al usuario (ya sea del tipo común o administrativo) las funcionalidades y opciones de personalización del software. Éste manual también debe contener información sobre cómo se desarrolló el software, qué herramientas se emplearon, cuál es la finalidad del software (qué innovación busca implementar al mercado) y qué comentarios se le buscan dejar al usuario de parte de los desarrolladores. Actor primario: Equipo de desarrollo (encargado del desarrollo del software y, por ende, del manual de usuario). Condiciones previas: - El equipo de trabajo debe tener ya pensadas o establecidas un conjunto de normas y pautas que el usuario debe seguir para poder plasmarlas y ampliarlas. - Se debe tener seleccionada una metodología para redactar el manual de usuario. Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un Escenario de éxito principal: Luego de que el equipo de desarrollo tenga una idea de qué quiere lograrse con el software, éste redactará el manual de usuario en su totalidad, pudiendo crear un documento donde se le especifique al usuario qué debe hacer con el software, como hacerlo y definirle para qué sirve cada opción de éste. Flujos alternativos del programa: - El equipo de desarrollo no tiene una idea clara de qué instrucciones se le quieren dar al usuario, por lo que deberán pensar desde cero en normas e instrucciones para plasmar en el manual de usuario. Frecuencia de uso: El manual de usuario deberá ser como una recopilación de todas las funcionalidades del software, es decir, deberá tener información sobre cada opción presente al momento de usar el software, por lo que se deberá especificar muy claramente qué opciones de uso tiene cada apartado del software. Criterios de aceptación: El requisito será aceptado cuando se evidencie que existe un documento en el que se especifique (desde la perspectiva de cualquier usuario) qué opciones de uso tiene el software y cómo actúa cada opción de éste. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: El manual de usuario debe ser fácilmente localizable, desde los ajustes propios de la aplicación, además de que su estructura debe ser la de un documento común (debe constar de portada, introducción, índice, tabla de contenido y contenidos, además de bibliografías y recursos externos). - El software No necesariamente debe ser de código abierto. Si fuera un software de código cerrado, sería una privatización de los derechos de desarrollo de éste, por lo que, si se llegan a considerar futuras ganancias monetarias, dichas ganancias irían dedicadas exclusivamente al equipo que se encargó de desarrollar el software y semejantes. - En caso de que el software se decida publicar como código abierto, otros agentes externos al equipo de trabajo (tales como desarrolladores de plataformas como LinkedIn, StackOverflow y GitHub) tendrían acceso a su código fuente. Si esto llega a suceder, se podría propulsar un desarrollo libre para el software, pudiendo llegar a más desarrolladores y equipos para su constante evolución. Adicional a lo anterior, El software debe contar con un apartado de declaraciones de derechos de autor, bibliografías y referencias en una extensión de la documentación final del producto. Identificador: VRF9-2024 Título: “Verificación de la legitimidad legal de los derechos de desarrollo del software” Descriptción: Se procede a validar qué legalidad tiene el equipo de desarrollo del software sobre éste, es decir qué aspectos legales tocará el software acerca de Uso de licencias, desarrollo por otros equipos independientes o monetización del producto. Actor primario: Condiciones previas: El equipo de desarrollo del software. - El software ya debe estar terminado. - El equipo de trabajo debe haber considerado la posibilidad de que el software sea tanto de código cerrado como de código abierto (los pros y contras de ambas opciones.) Calificación de esfuerzo En la escala del 1 al 10, éste requisito tiene una calificación respecto a su dificultad de desarrollo de un 3. Escenario de éxito principal: Dependiendo los intereses y la finalidad de las herramientas del desarrollo del software, el equipo de desarrollo podrá tomar una decisión final en cuanto a la legitimidad que se le quiere dejar al software: - Si el software se decide publicar como código abierto, puede que no tenga una monetización demasiado grande, pero permitirá que diferentes equipos y desarrolladores Freelancer’s (trabajadores independientes) puedan modificar y documentar sus propias versiones del software. - Si el software se decide publicar como código cerrado, su uso empresarial puede que sea más considerado desde la perspectiva empresarial, pudiendo llegar a una monetización superior gracias a anuncios y tráfico de datos a terceros para publicitar éstos además de que el proyecto pueda ser financiado o remunerado por una empresa/entidad concreta. A final de cuentas, ambas opciones de publicación tienen sus características, por lo que el caso de éxito principal será aquel en el que los desarrolladores lleguen a una decisión concreta sin complicaciones mayores. - Flujos alternativos del programa: El equipo de desarrollo no llega a una conclusión concreta cuando se termina el desarrollo del software, por lo que el equipo pospondrá la publicación del software hasta que se acuerde una decisión fija. Frecuencia de uso: La legitimidad y los derechos del software son un aspecto que puede influenciar de muchas maneras la forma en la que el usuario final pueda calificar el producto, por lo que desarrollar satisfactoriamente éste requisito será de vital importancia, teniendo una frecuencia de uso constante. Criterios de aceptación: El requisito será aceptado cuando se publique satisfactoriamente el software bajo un modelo de publicación, ya sea de código abierto como código cerrado. Estado de su desarrollo: EN PROCESO DE DESARROLLO Observaciones: Éste requisito no es funcional, pero será gracias a él que se decidirá el futuro del software. Luego del desarrollo y la publicación, se le debe crear atracción al usuario para que use el producto constantemente, por lo que se debe tomar una sabia decisión en cuanto a la legitimidad de su desarrollo, ya sea desde el aspecto documentativo como financiero. Requisitos funcionales: A continuación, en este apartado, retrataremos el conjunto de requisitos funcionales que complementarán los requisitos más básicos del software primero desde la perspectiva de un potencial empleado que quiere mandar una solicitud de empleo a la empresa y luego desde la perspectiva de un administrador de la empresa que se encarga de gestionar este tipo de solicitudes: Perspectiva el potencial empleado: - Registro de usuario: el potencial empleado debe ser capaz de registrarse e iniciar sesión en la plataforma, con su nombre, usuario o correo y con su respectiva contraseña la cuál involucrará caracteres ASCII. También se puede hacer un registro y un inicio de sesión con Facebook o Google. - Acceso al menú: el potencial empleado debe ser capaz de desplazarse por el menú de la plataforma: navegar entre opciones, ver postulaciones disponibles, gestionar su perfil, etc. - Búsqueda de postulaciones de empleo: El potencial empleado debe ser capaz de buscar, filtrar y encontrar diferentes solicitudes de empleo abiertas por diferentes empresas. A su vez, este motor de búsqueda puede ser mediante palabras clave, nombre de la empresa, fecha de postulación, cargo o salario, entre otros filtros de búsqueda más. - Presentación de solicitudes: El potencial empleado debe ser capaz de seleccionar una postulación de trabajo acorde a su hoja de vida. Esto debe incluir un apartado de comunicación entre la empresa y el potencial empleado, unos términos a aceptar y un apartado para que el potencial empleado adjunte sus documentos para enviarlos en la postulación de empleo. La postulación debe contar con información de la empresa, el cargo, los equipos de trabajo y requisitos para llevar a cabo dicho cargo dentro de la empresa, entre otros datos acerca del trabajo. - Información sobre el estado de la solicitud: Luego de que el potencial empleado presentara su solicitud a una postulación de empleo de una empresa, esta solicitud deberá ser procesada por un equipo interno de la empresa. Dicho equipo será el encargado de aceptar, rechazar y justificar la elección acerca de la solicitud de empleo del posible empleado. - Apartado de respuesta: El sistema debe ser capaz de notificarle eficazmente al posible empleado de la empresa que su solicitud de empleo fue O aceptada o bien rechazada por X o Y motivo. El software debe ser capaz de desempeñar ésta tarea con eficacia y manteniendo una línea de comunicación sólida entre la empresa y el posible empleado. - Opciones en caso de rechazo: Si la solicitud previamente enviada a la empresa llegase a ser rechazada, entonces el posible empleado debe ser consciente de los motivos que la empresa tuvo de esa decisión. Así, pues, el posible empleado podrá volver a juntar información suya y podrá postularse a más solicitudes de empleo. - Opciones en caso de aceptación: Si la solicitud redimida por el posible empleado llegase a ser aceptada, entonces la empresa le haría saber la decisión al posible empleado, haciendo que éste se convierta en un empleado oficial de la empresa. Lo siguiente sería que acuerden un contrato y se charlen mediante el chat de la plataforma los horarios, salarios, prestaciones y otros temas legales en cuanto al empleo. Perspectiva del administrador de la empresa: - Registro del administrador: El administrador de la plataforma por parte de la empresa debe ser capaz de registrar y tener activa su cuenta empresarial. Éste campo requerirá correo electrónico, contraseña, correo o número de recuperación y clave dinámica para un acceso más seguro y eficiente. - Acceso al menú: el administrador debe contar con una interfaz intuitiva y sencilla que le permita actuar de acuerdo con sus responsabilidades. Entre sus responsabilidades se encuentra el Gestionar solicitudes de empleo. - Administrar postulaciones de empleo: Desde la perspectiva del administrador, la plataforma debe ser capaz de contar con un apartado donde lleguen de manera remota todas las solicitudes de empleo de potenciales empleados, algo así como una bandeja de entrada. En ésta bandeja aparecerán de manera ordenada los perfiles, descripciones y currículums de diferentes posibles empleados. - Revisión de solicitudes de empleo: El administrador en la plataforma debe contar con un apartado para filtrar las solicitudes de empleo entrantes. Ya sea por búsqueda específica, filtro por edad, por experiencia laboral, por orden alfabético u otras formas de búsqueda, el sistema debe contar con una forma de filtrar eficazmente solicitudes de empleo. - Selección de solicitudes: El administrador del sistema debe contar con una lista de requisitos que los diferentes postulados. Si las solicitudes, en su mayoría, cumplen con ésta lista de requisitos de ingreso, entonces el administrador deberá tomar una decisión de carácter colectivo: se verá en la obligación de escoger al empleado mejor capacitado para ejercer el puesto de trabajo, ya sea mediante años de experiencia, recomendación, trabajos previos o alguna otra manera de seleccionar al candidato más apto. Si pocos empleados cumplieran la lista de requisitos, entonces los criterios de selección entre los más aptos serían más pequeños y limitados, facilitando así el trabajo del administrador. - Entrada y salida de comunicación: Cuando se escoja al candidato más apto para el empleo, el software deberá contar con un apartado de chat en el que dicho seleccionado y el administrador entablarán una conversación. En dicha conversación se detallarán temas como horarios laborales, salario, ambiente laboral, prestaciones y otros términos del empleo. Si todo sale bien, el posible empleado estará determinado a empezar a laborar, y el administrador le presentará una fecha en la que se ajustará una cita para que el Ya empleado asista a una sede física de la empresa, para firmar contrato y terminar de cerrar acuerdos con ésta. Así pues. Así pues, desde ambas perspectivas, el software en cuestión cumplió satisfactoriamente los objetivos básicos que se le asignaron, es decir, cumplió satisfactoriamente con su propósito. A continuación, se especificarán los requisitos no funcionales que serán tomados en cuenta al momento de desarrollar lógicamente el software. Historias de usuario: Para el listado de requisitos específicos tanto desde la perspectiva de un posible empleado como desde la de un administrador por parte de la empresa se propusieron diagramas de casos de uso para cada requisito anteriormente mencionado para ver cómo se aplican dichos requisitos de forma más descriptiva y práctica. 1. Perspectiva de un posible empleado: Número de Nombre de la Descripción de Observacione Puntos Criterios de la historia historia la historia de s acerca de la estimado aceptación usuario historia s de (priorizada ) esfuerzo 1 Iniciar sesión como usuario común. Como usuario no administrativo de la aplicación, quiero poder iniciar sesión en el software a través de mi correo electrónico y contraseña para acceder a mi página de inicio. Esta historia debería ser la más sencilla de programar, con tal de un correo (usuario) y una contraseña ya debería ser posible el acceso fácil. 2 2 Desplazamient o a través del menú principal Como usuario común, quiero poder desplazarme sencillamente a través del menú El usuario debe poder acceder al menú principal sin complicacione 3 La historia será aceptada cuando se evidencie que es posible para el rol de usuario común acceder a la plataforma a través de correo y contraseña. La historia será aceptada cuando se evidencie que el usuario, luego de iniciar principal del software, el cual se presentará justo luego del inicio de sesión. s ni tiempos de espera innecesarios. Los filtros de búsqueda deben contener opciones como búsqueda manual y filtros por letras, palabras, números, fecha de publicación, salario y empresa que publicó la postulación Las postulaciones deben ser redactadas correctamente por el usuario a una solicitud, y a su vez las solicitudes deben contener una buena información de parte de la empresa. 3 Búsqueda y localización de postulaciones de empleo. Como usuario, quiero poder utilizar la barra de búsqueda del software (ubicada en el menú principal) para poder buscar solicitudes de empleo a través de palabras clave y demás opciones de búsqueda. 4 Envío de postulaciones de empleo Como usuario, quiero poder enviar postulaciones de empleos emergentes en el software. Dichas postulaciones deberán poder ser redactadas en una pantalla aparte del menú principal y deben contener una hoja de vida, descripción del perfil y unas palabras de introducción propia del usuario que envíe la solicitud. A su vez, la 4 4 sesión, es redirigido al menú principal sin complicaciones . La historia será aceptada cuando se evidencie que el menú principal tiene una barra de búsqueda para filtrar y encontrar solicitudes y empresas. La historia será aceptada cuando se evidencie que el usuario puede enviar su solicitud de empleo a través de la plataforma, en el aparado de Enviar solicitud dentro de una postulación de empleo. 5 Información sobre el estado de la solicitud enviada. 6 Respuesta de la solicitud previamente enviada por el usuario (positivamente) 7 Respuesta de la postulación debe tener, en la descripción del empleo, información del cargo y de la empresa. Como usuario, quiero poder revisar el estado de las solicitudes que envié previamente en una solicitud de empleo. El estado de las solicitudes será visualizado en un cuadro horizontal, similar a una línea de tiempo en, el que se verá desde el primer paso (la adjunción de documentos) hasta la etapa presente de la solicitud. 5 Como usuario, Cuando el quiero poder ser apartado que informado por la indique la aplicación, a aceptación de través de un la solicitud cuadro en el aparezca, dicho menú principal, cuadro debe que la solicitud contener un que envié a una botón postulación de dinámico que empleo fue permita ir aceptada directo a un satisfactoriamente chat con la . empresa para acordar cómo se firmará el contrato de empleo y bajo qué términos. Como usuario, Al contrario 7 4 La historia será aceptada cuando se evidencie que existe una forma de revisar el estado de la solicitud del empleado. Dicha forma se estima sea un cuadro similar a una línea de tiempo con datos sobre la solicitud. La historia será aceptada cuando se evidencie que el sistema le puede notificar al usuario que su solicitud fue analizada de manera exitosa y que dicha notificación pueda dirigir al usuario a un chat con la empresa. La historia será solicitud previamente enviada por el usuario (negativamente ) quiero poder ser informado por la aplicación, a través de un cuadro en el menú principal, que la solicitud que envié a una postulación de empleo fue rechazada, además de que dicho cuadro cuente con detalles del porqué se rechazó y un mensaje de agradecimiento de la empresa por el interés hacia el empleo que en el caso de éxito, la plataforma deberá mostrar una pequeña notificación en un apartado de la plataforma informando que la solicitud se rechazó. Dicha notificación se podrá ampliar y se podrá leer a detalle a qué se debe este rechazo aceptada cuando se evidencie que el software es capaz de enviar una notificación ampliable acerca del rechazo de la solicitud de empleo de un usuario hacia una postulación. 2. Perspectiva de un administrador de la empresa: Número de Nombre de la Descripción Observaciones Puntos Criterios de la historia historia de la historia acerca de la estimados aceptación de usuario historia de (priorizada) esfuerzo 1 6 La historia será Inicio de Como usuario Esta historia sesión del administrativo, debe ser aceptada administrador. quiero poder sencilla de cuando se registrarme e programar, evidencie que iniciar sesión en debe ser capaz el software es el software de acceder con capaz de haciendo uso de un usuario permitirle el mi correo (correo acceso a un (usuario) empresarial) y usuario empresarial y una contraseña, administrativo mi contraseña, además de que usando su además de que cada vez que se correo y dicho inicio de inicie sesión el contraseña y sesión debería sistema emplee también contar con la una gracias a la autenticación de autenticación autenticación 2 pasos de 2 pasos, tal de 2 pasos. como un mensaje a un celular o al correo electrónico del usuario. 2 3 La historia será Acceso al Como usuario Esta historia menú administrativo, debería ser la aceptada administrativo. quiero que justo más sencilla de cuando luego de haber hacer realidad iniciado sesión ya que será pueda acceder sencillo al menú programar que, principal del luego del inicio software donde de sesión y la luego podré autenticación realizar de 2 pasos, el diferentes usuario sea acciones. redirigido al menú principal. 3 Administración Como usuario El software, de solicitudes administrativo, para poder aceptada de empleo quiero pode cumplir con cuando se entrantes. administrar este requisito evidencie que solicitudes de deberá contar un usuario de 6 La historia será una vacante de con conexiones tipo empleo gracias con servicios administrativo a las de terceros está en herramientas (como bases de capacidad de que me brinda datos y administrar, el software. servidores) para modificar y almacenar el verificar la total de integridad y solicitudes de disponibilidad una vacante, y de las a su vez, el solicitudes de sistema deberá empleo de la poder modificar vacante de su dicho empresa. repositorio: leerlo, cambiar el orden, añadir y quitar solicitudes 4 5 La historia será Chequeo de las Como usuario El software solicitudes de administrativo, debe contener aceptada empleo. quiero poder un botón, como cuando se hacer una un acceso evidencie que prueba sencilla directo de cada el sistema tiene (como un solicitud para un protocolo reconocimiento) verificar si está en caso de de la integridad disponible en el fallas en una de determinada sistema. Si no solicitud de solicitud para llega a estar empleo. Dicho ver si sigue disponible, el protocolo disponible en la sistema dará un deberá poder plataforma y si mensaje enviar un se puede hacer diciendo que el mensaje acerca comunicación documento no de lo que con el usuario está disponible sucede y que la envió y se debe pedir también deberá un reenvió por redirigir el parte el usuario sistema a un que la adjuntó. chat con el usuario para pedirle un reenvío. 5 Selección y Como usuario El usuario filtrado de administrativo, administrativo aceptada solicitudes quiero poder debe ser cuando se adecuadas. utilizar consciente de evidencie que herramientas qué busca de un el software es propias del empleado para capaz de filtrar software para la postulación: y organizar las filtrar todas las qué actitudes, solicitudes de solicitudes de aptitudes y empleo para empleo expectativas se que el entrantes y le estima a un administrador seleccionar la empleado para de la empresa más adecuada que sea pueda para el trabajo considerado un seleccionar el dependiendo los posible perfil más apto criterios de mi empleado. para el empleo. 4 La historia será empresa. 6 Comunicación Como usuario Para cumplir con el usuario administrativo, con este aceptada de la solicitud quiero poder requerimiento cuando se más apta para entablar una se debe evidencie que el empleo. conversación desarrollar un el software con el candidato sistema de tiene su propio más apto para el mensajería servicio de empleo dentro del mensajería de 7 La historia será previamente software que texto para que seleccionado de sea capaz de diferentes forma eficiente enviar y recibir usuarios tanto y dinámica a mensajes de un comunes como través del usuario a otro, administrativos servicio de además de puedan mensajería del adjuntar entablar software. documentos, conversaciones videos e privadas imágenes. acerca del empleo. Requisitos no funcionales: a. Listado de requisitos no funcionales: Como se mencionó anteriormente, un objetivo también de este documento es analizar requisitos tanto funcionales como no funcionales. Por ende, se procede a enlistar los requisitos No funcionales del software, también desde la perspectiva tanto de un potencial empleado como la de un administrador de solicitudes de empleo por parte de la empresa. Perspectiva de un posible empleado: - Ingreso a la plataforma: El ingreso al sistema no debe tardar más de 15 segundos, de lo contrario los campos llenados se blanquearán automáticamente. - Ingreso al menú de usuario: Desde la perspectiva del usuario, el acceso al menú debe ser claro, sencillo e intuitivo con un apartado a la izquierda de la pantalla que despliegue una tabla con las opciones que tendrá el usuario: Perfil, postulaciones del usuario, noticias, novedades, configuración y demás apartados. - Redacción de solicitudes: Al momento de redactar una solicitud de empleo, el software no debe ser solamente capaz de adjuntar documentos de formato PDF, también debe ser capaz de adjuntar archivos Word y tablas de cálculo Excel, además de presentaciones PowerPoint, archivos de texto plano y otros formatos como Java, Python, C/C++ y otros lenguajes. Adicional a esto, también debe contar con su propio apartado de escritura con diferentes fuentes, tamaños, títulos y subtítulos, colores, negrilla y subrayado y otras cuantas opciones de personalización. - Envío de solicitudes: la plataforma debe ser capaz de avisarle al empleado cada revisión que la empresa le realice a su solicitud: desde que la solicitud es recibida hasta cuando es revisada, comentada y se le da un veredicto a la solicitud. - Comunicación con la empresa: el chat con la empresa debe ser visualmente atractiva, dinámica y con atajos de chat para una mayor personalización y, por ende, un mayor gusto de utilizar la plataforma. Además, de manera opcional, se pueden personalizar aspectos como los sonidos de notificación del software y programar mensajes para enviarse en determinada hora del día, entre otras funciones. - Funciones de perfil de usuario: El perfil del usuario debe ser capaz de personalizarse de tal forma que cuente con un apartado para sincronizar con redes sociales del usuario, una pequeña biografía, una foto de portada de perfil y una foto de perfil propia del usuario, entre otras opciones de personalización. - Funciones de notificación: las notificaciones deben ser claras y sencillas, debe saltar un anuncio en la esquina de la pantalla incluso cuando la aplicación esté cerrada, además de un sonido característico del software. Perspectiva del administrador de la empresa: - Ingreso a la plataforma: A diferencia del ingreso a la plataforma de un usuario común, el administrador contará con menos tiempo de inicio de sesión para un inicio de sesión más estricto, más exactamente 10 segundos. - Gestión de perfil: El perfil del administrador debe tener vinculado en todos los aspectos de redes sociales las cuentas oficiales de la empresa, además de contar con una pequeña insignia de la plataforma que le permita ver que dicho administrador es parte de la empresa en cuestión. - Administración de solicitudes: El administrador de solicitudes de la empresa debe contar con un apartado del menú para gestionar las solicitudes de empleo. Esto quiere decir que el apartado de las solicitudes debe contar con filtro y organización mediante letras, fecha de subida, última actualización, entre otros filtros. - Administración de equipos de trabajo: El administrador de la empresa, al ser parte de un equipo de contratación, deberá contar con una vía de mensajería especialmente diseñada para comunicarse con otros miembros de su equipo, para que las diferentes líneas de gestión mantengan una constante comunicación. - Distribución de las solicitudes: la cantidad de solicitudes que le lleguen a la empresa puede sobrepasar las cantidades promedio que un solo administrador pueda gestionar, por lo que distribuir la tarea entre varios administradores sería una alternativa viable para la empresa. Así, pues, dependiendo la cantidad de solicitudes que lleguen, se destinarán diferentes equipos de trabajo a la tarea de gestionar solicitudes de empleo gracias al software. b. Requisitos de Seguridad: En este apartado retrataremos algunos otros requisitos acerca de la seguridad del programa: - El software debe contar con un equipo de pentesters (encargados del área de la ciberseguridad y la auditoría) que se encargarán de monitorear el software buscando vulnerabilidades y fallas de código. También sería posible contratar un equipo externo al equipo para desempeñar la tarea. - En caso de que se encuentren vulnerabilidades al software, cada vulnerabilidad será comentada de inmediato a un equipo desarrollador para que corrija dicha vulnerabilidad en futuras actualizaciones o parches. c. Requisitos de Fiabilidad: En este apartado retrataremos algunos requisitos acerca de qué tantas fallas o errores tolerará el programa: - En cuanto a errores, se dispone que el software, frente a cualquier error fatal que involucre la ejecución del programa, se reinicie y vuelva a funcionar desde cero, tomando nota de qué componente interno del software fue el encargado del fallo. Esto con el fin de analizar su posterior ejecución y arreglar el error en cuestión. - Si se trata de un error dinámico de la interfaz gráfica, el software deberá ser capaz de soportarlo hasta que se vaya a otra pestaña y la pestaña con el error pueda recargarse y volver a funcionar. Si no se arregla, el software debe ser capaz de anotar qué sucedió para su posterior reparación. - Cuando se presenten inconvenientes entre el software almacenado localmente en el equipo de un usuario y los servidores que hacen que éste funcione, dichos errores serán catalogados mezclando números y letras para dar así códigos especiales de error que retratarán posteriormente en qué situación está el servidor (por ejemplo, código de error bbbAc11). Éste requisito también puede ser aplicado para otros tipos de errores dentro del programa, tanto de manera local como de red, representándose los diferentes errores que vayan surgiendo con distintos códigos. - Éstos casos de errores serán almacenados en un documento de texto dentro de una carpeta en los archivos internos del software donde se especificará qué tipo de error fue (error ligero/error fatal) además de la fecha, hora, datos básicos del usuario y una descripción de qué archivo, conexión o dependencia ocasionó el error. d. Requisitos de Disponibilidad: Aquí retrataremos algunos requisitos más acerca de qué porcentaje (respecto a los factores de disponibilidad finales del pc del usuario) tiene el software respecto a los factores de dicho equipo. - El software deberá no contar principalmente con un amplio consumo de memoria RAM, ya que al planearse una aplicación dinámica se debe consumir mucha memoria momentánea del sistema parra animaciones e interacciones que el sistema deberá tener con el software. - El software no debe consumir demasiados recursos del procesador, ya que, al ser un software de contratación, no tendrá demasiada información para procesar momentáneamente (a diferencia de otras aplicaciones ajenas al software que consumen recursos del procesador, como entornos de diseño gráfico demandantes o de producción musical donde se deben procesar muchos objetos simultáneamente). Así pues, el software deberá ser lo más optimizado en cuanto a productividad y consumo. - El software deberá contar con una pequeña partición del disco duro del equipo del usuario para tareas como almacenamiento de datos locales, intercambio de información que deje registros de manera local o simplemente para darle más disponibilidad de espacio al software. - El software no contará con un apartado gráfico demasiado exigente como animaciones o videos digitales, por lo que no deberá contar con el requisito físico de una tarjeta integrada, y será mas que suficiente que las acciones dinámicas sean tarea de los gráficos integrados del procesador en cuestión. - El software deberá poder tener atajos de teclado y ser manipulado mediante teclado como una alternativa al Mouse y más que nada para que tenga una conexión más directa con las disponibilidades del teclado, para poder aprovechar el uso de las teclas ALT, CTRL y ALT GR. e. Requisitos de Mantenibilidad: En éste tipo de requisitos se retratará quién y cómo le hará mantenimiento al software. - En cuanto a mantenimiento, el equipo encargado de ésta tarea deberá conformarse por los siguientes elementos: una parte que sepa acerca de bases de datos, otra de conexiones de red, otra de archivos locales y una última parte capaz de asegurarse que todo el anterior mantenimiento sea capaz de funcionar correctamente. - Los periodos de mantenimiento deberán ser definidos a partir de qué tantos errores se presenten en el uso del software final, es decir, mientras más fallos vaya presentando el producto final más mantenimiento y más constantemente se le deberá realizar. f. Requisitos de Portabilidad: En estos requisitos se verán plasmadas algunas alternativas para que el entorno desarrollado de software pueda ser importado o exportado a otros entornos o plataformas: - El software, luego de sus versiones oficiales para el sistema operativo dedicado (el cuál será Windows 10/11) deberá poder ser exportado a otros sistemas operativos, tales como MacOS y Linux. Para poder publicar el software satisfactoriamente en éste último se deberá hacer un repositorio de GitHub con los archivos y ejecutables necesarios para que el software funcione bien tanto en distribuciones de Debian, Ubuntu y Arch-Linux y todos sus derivados. - El software NO contará con una versión portable (almacenable y ejecutable totalmente desde un dispositivo USB y no un Disco duro externo), por lo que todo el software se almacenará de manera local. - Dependiendo de las circunstancias de su desarrollo, se buscará una manera de que archivos y partes del programa puedan ser respaldados gracias a servicios en la nube y de respaldo de archivos. Interfaces externas: En este apartado del documento veremos algunas funciones y requisitos que intervendrán con funcionalidades del entorno físico del usuario final, es decir, todo aquello con lo que el usuario pueda interactuar dinámicamente en el software: - El usuario debe ser capaz de copiar, pegar, cortar y arrastrar desde otras pestañas de Windows. Además, se podrán adjuntar documentos, imágenes y algunos otros tipos de archivos utilizando éstos métodos. - El software debe contar con atajos para poder enviar, almacenar y recibir archivos a partir de diferentes servicios de almacenamiento en la nube, tales como Google Drive, Mega, UptoBox, TeraBox y demás servicios. - El software deberá poder adjuntar y crear hipervínculos que redirijan el usuario al navegador predeterminado especificado por el sistema operativo (eje. Firefox o Microsoft Edge.) - El software tendrá la opción de permanecer cerrado, pero con una pequeña ventana en segundo plano que permitirá que, en caso de que llegue una notificación, el sistema notifique instantáneamente ésta notificación entrante al usuario, tal cual funcionan las alertas de un antivirus o las notificaciones instantáneas de Outlook. Funciones: Aquí veremos qué funciones el sistema deberá llevar a cabo. Esto será representado de forma en la que las funciones del software se escriban “el sistema deberá……” - El sistema deberá ser capaz de permitir que una persona encuentre empleo. - El sistema deberá ser capaz de permitir que una empresa publique una vacante de empleo, además de sus datos y especificaciones. - El sistema deberá ser capaz de que los datos de todos los usuarios estén seguros. - El software deberá ser capaz de asegurar que todos los documentos se envíen correctamente. Requisitos de rendimiento: Aquí incluiremos aquellos requisitos relacionados con la carga que se espera que deba soportar el sistema (números de usuario simultáneos, número de entradas y salidas, numero de terminales), además de otras funcionalidades que el rendimiento del software deba cumplir (tales como cantidad de registros en X base de datos o la frecuencia con la que un usuario X ingrese a la plataforma.) - El sistema podrá soportar un total de 200 usuarios conectados y aproximadamente la mitad de la cantidad de solicitudes enviadas y recibidas simultáneamente (como máximo antes de un cuello de botella. Éste problema puede solucionarse teniendo en cuenta más espacio de almacenamiento en los servidores y mejores conexiones, tema el cuál se debe planificar aparte al desarrollo del software, ya que las conexiones con servidores externos no forman parte del desarrollo del software en sí, sino de una pieza externa, un relacionado.) - Desde la perspectiva del equipo desarrollador y administrador de bases de datos y servidores, se podrá evidenciar cuántos usuarios activos hay, cuántas solicitudes se mandaron el día presente, cuantas se recibieron y otros datos acerca del desempeño que el software ha tenido, como velocidad de red con servidores y bases de datos. Apéndices: En este apartado vamos a incluir cualquier tipo de información que involucre el software pero que no esté directamente relacionada con éste, como podría ser resultados de un estimado de costes, especificaciones del lenguaje de programación empleado, etc.: - Los resultados de costes se van a especificar luego de haber terminado toda la fase de planeación del software, ya que adicional al software como tal, se debe costear el mantenimiento, servidores, bases de datos y otros externos. - El software se planea desarrollar en Python ya que se estima que es un lenguaje amplio y documentado, además que, en profundidad del lenguaje, éste tiene amplias opciones para configurar la seguridad, bases de datos y terceros; también se considera el uso de Java, C/C++, C#, Kotlin, Rúst. y otros cuantos lenguajes. Aunque, desde la perspectiva del equipo desarrollador, se podría optar por lenguajes más ambiguos y pequeños, como Ruby o Pearl para un entendimiento más accesible del lenguaje. De forma más interna, se debate si la mejor opción para el desarrollo es emplear un lenguaje Orientado a Objetos, Orientado a Eventos o mejor un lenguaje Multiparadigma. El equipo, antes de entrar en la fase de codificación y creación del software, considerará diversas opciones para la codificación para determinar qué lenguaje, dependencias y librerías es más conveniente de utilizar. - En cuanto a bases de datos, se estima que sean empleadas de manera externa al programa. La aplicación para éstas podría ser Microsoft Acces o, desde una perspectiva más programativa, algún proyecto en SQL, XQuery, LINQ o SQL/XML, entre otros lenguajes para bases de datos. Índices: Para finalizar, se presentará éste índice que contendrá un acceso rápido (dentro de futuras actualizaciones y revisiones del software final) a la documentación del software: versiones, errores arreglados, mejoras, etc. - Planificación V1.13.08 - Planificación V2.24.08 - Planificación V3.01.09 (actual)