Sistema para la Gestión de la Configuración del Software Sistema de Control de la Gestión de la Configuración del Software Acta de Constitución Comunicaciones Integrales Sistema para la Gestión de la Configuración del Software 1. INFORMACIÓN DEL PROYECTO 1.1. OBJETIVO GENERAL Desarrollar mediante el uso de herramientas tecnológicas, un Sistema que permita controlar de manera óptima la gestión de configuración de software. 1.2. ALCANCE El sistema en propuesta brindará una herramienta a gerentes de TI para gestionar elementos de configuración de software y también las versiones que se produzcan durante el desarrollo del sistema. Respetando las fechas establecidas en el cronograma, con el fin de culminar el proyecto de manera exitosa según el acuerdo realizado. 2. JUSTIFICACIÓN DEL PROYECTO La necesidad del cliente de contar con una herramienta tecnológica que permita gestionar elementos de configuración durante el proceso de desarrollo del software, el cual también permitirá optimizar los recursos. 3. METODOLOGÍA La Metodología que se empleará para la ejecución del desarrollo del sistema será la metodología de Desarrollo RUP (por sus siglas en inglés de Rational Unified Process). 3.1. CARACTERISITCAS DEL RUP - Puede describir la organización, documentación funcionalidad y restricciones. - Nos permite documentar, agilizar, mejorar los requerimientos obtenidos para la ejecución del desarrollo del Software. - Nos ofrece formas de diseño, implementación, ejecución, entre otras del Software antes de que sea implementado. Sistema para la Gestión de la Configuración del Software 3.2. FASES DEL RUP FASE Inicio DESCRIPCIÓN En esta fase, se revisan y confirma nuestro entendimiento sobre los objetivos centrales. La fase de inicio establece la viabilidad del producto y delimita el alcance del proyecto. Durante la fase de elaboración, la mayoría de Elaboración los casos de uso son especificados en detalle y la arquitectura del sistema es diseñada. El sistema pasa de la arquitectura de base a Construcción un sistema lo suficientemente completo como para llevarlo al usuario. En la fase de transición el objetivo es Transición garantizar que los requisitos se han cumplido, con la satisfacción de las partes interesadas. 4. ELEMENTOS DE CONFIGURACIÓN Y ENTREGABLES ETAPA ENTREGABLE Acta de Constitución Plan del Proyecto Plan de Gestión de Configuración Plan de Gestión de Riesgos INICIO Documento Visión Glosario de Términos Sistema para la Gestión de la Configuración del Software Actas de reunión Especificación de Requerimientos Especificación de Casos de Uso Especificación de Diagramas de Secuencia ELABORACIÓN Diagrama de Clases Diagrama Entidad Relación Diagrama de Componentes Diseño del Prototipo Código Fuente del Sistema CONSTRUCCIÓN Plan de Pruebas Resultados de Pruebas TRANSICIÓN Capacitación de Usuario 5. ESTANDAR DE PROGRAMACIÓN Se empleará el estándar “CamelCase” que es un estilo de escritura que se aplica a frases o palabras compuestas. El nombre se debe a que las mayúsculas a lo largo de una palabra en CamelCase se asemejan a las jorobas de un camello. Emplearemos el estándar CamelCase del tipo: LowerCamelCase, la primera letra es minúscula. Ejemplo: ejemploDeLowerCamelCase. Se utilizará el patrón de arquitectura de software MVC (Modelo, Vista, Controlador) para el desarrollo del sistema, se empleará también la metodología KANBAN para la gestión del proyecto en sí mismo. Sistema para la Gestión de la Configuración del Software 6. CRONOGRAMA Referencia: SGCS-Cronograma V1.2 Sistema para la Gestión de la Configuración del Software 7. GERENCIA DEL PROYECTO 7.1. Stakeholder del Proyecto El Stakeholder reconocido en este proyecto será: APELLLIDOS Y NOMBRE Ing. Ricardo Valcárcel Alvarado ROL Stakeholder 7.2. Roles y responsabilidades APELLIDOS Y NOMBRES Renzo Moreno Cáceres ROL Jefe de Proyecto Sigfredo Aponte Roldán Analista Yerson Coaquira Calizaya Desarrollador Flor de María Condori Gutierrez Desarrollador Sistema para la Gestión de la Configuración del Software 8. APROBACIÓN En la presente Acta de Constitución del Proyecto se declara formalmente el inicio del proyecto “SISTEMA DE CONTROL DE LA GESTIÓN DE LA CONFIGURACIÓN DEL SOFTWARE” Entregado por: Aceptado por: ----------------------------------Renzo A. Moreno Cáceres Líder del Proyecto ----------------------------------Ing. Ricardo Valcárcel Alvarado Stakeholder del proyecto Equipo: _______________________ hhSigfredo Aponte Roldán __________________________ Yerson Coaquira Calizaya __________________________ Flor de María Condori Gutiérrez Observaciones:___________________________________________________________ _______________________________________________________________________ _______________________________________________________________________ 21/08/2019 Tacna - Perú Sistema para la Gestión de la Configuración del Software Sistema para la Gestión de la Configuración del Software Plan de Gestión de Configuración Comunicaciones Integrales Sistema para la Gestión de la Configuración del Software CONTROL DE VERSIONES Versión Realizado por Revisado por 1.1 YC, SA RM Aprobado por Fecha 22-09-2019 Motivo Elaboración de Plan de Configuración Sistema para la Gestión de la Configuración del Software 1. INTRODUCCIÓN 1.1. Objetivo y Alcance Objetivo El sistema SGCS (Sistema de Gestión de Configuración de Software) que se desarrollará tiene como objetivo poder brindar una herramienta para la gestión documentaria para el proceso de desarrollo de proyectos de software. Alcance El sistema SGCS (Sistema de Gestión de Configuración de Software) que se desarrollará, se encargará de identificar los ECS y de los cambios que se necesitarán realizar en los proyectos de desarrollo de SW, además de visualizar los informes de estado además de los avances por fase de cada metodología empleada. 1.2. Terminología Se emplearán las siguientes terminologías: - SGCS = Sistema para la Gestión de la Configuración de SW - SC = Solicitud de Cambios - SR = Solicitud de Revisión - CC = Control de Cambios - CV = Control de Versiones - IE = Informe de Estado - IAC = Informe de Auditoria de la Configuración - IEC = Identificaron de Elementos de la Configuración Sistema para la Gestión de la Configuración del Software 1.3. Referencias Consideramos las siguientes referencias a los documentos, mostradas en la siguiente tabla: Titulo Sistema para la Gestión de la Configuración de SW Identificador del Documento SGCS Solicitud de Cambios SC Solicitud de Revisión SR Control de Cambios CC Informe de Estado IE Informe de Auditoria de la Configuración IAC Identificaron de Elementos de la Configuración IEC 2. GESTIÓN DE CONFIGURACIÓN DEL SISTEMA 2.1. Ambiente de Computación y Herramientas MEGA: Jefe de Proyecto creará el repositorio para almacenar el avance de la documentación generada por los entregables y el avance de los antes mencionados, esto permitirá a los integrantes de equipo tener al alcance los documentos que se irán generando y a la vez concluyendo, para permitirnos estar informados de los avances del proyecto y a la vez permitir a los miembros de le equipo subir sus tareas asignadas. GITHUB: Esta plataforma de desarrollo colectivo será una opción para almacenar en un repositorio el sistema y el avance paulatino pudiendo compartir de este modo en tiempo real las modificaciones realizadas al proyecto. Sistema para la Gestión de la Configuración del Software 2.2. Organización y Responsabilidades EL equipo de trabajo fue formado en el presente para el curso de Gestión de la Configuración del Software, se eligió como responsable a un alumno que realizará el papel de jefe de grupo, quien se encargará de la realización de las actividades descritas en las actividades de SGC (Ítem 3). 3. ACTIVIDADES DE SGC 3.1. Identificación de la Configuración Consiste en la identificación de la configuración, se diligencia el registro con la nomenclatura SGCS_IEC (Identificación de elementos de Configuración). 3.2. Control de Cambio y de Configuración En esta sección se detallan las actividades de solicitud, evaluación, aprobación e implementación de cambios a los elementos de la línea base. Se actualiza el registro SGCS_CC Control de Cambios. 3.2.1. Procesamiento y Aceptación de un Cambio Los cambios normalmente se realizarán para la corrección o el mejoramiento del proyecto. El procedimiento que se describe a continuación es el que se utilizará cada vez que se precise introducir un cambio al sistema. Se entiende por cambio al sistema, las modificadoras que afecten a la línea base del sistema, como pueden ser: - Cambios en los requerimientos. - Cambios en el diseño. - Cambios en la arquitectura. - Cambios en las herramientas de desarrollo. - Cambios en la documentación del proyecto (agregar nuevos documentos o modificar la estructura de los existentes). Sistema para la Gestión de la Configuración del Software 3.2.2. Miembros y procedimientos En la presente propuesta consideramos el mecanismo sugerido para realizar el control de cambios: - El nivel de cambios informal se aplicará de acuerdo con lo establecido en la Gestión de Configuración tradicional. Dichos modificadores se gestionarán de la forma habitual, mediante herramientas de registro, de incidentes y versionado de software. - Este tipo de cambios se realizarán sobre los ECS que aún no formen parte de una línea base preestablecida, por ejemplo, el código fuente antes de que forme parte de la línea base de producto. - El nivel de cambios semi-formal. Representando en nuestro esquema por los hitos mencionados en el apartado anterior, implicará un registro de las solicitudes en un documento específico, debiendo ser los mismos evaluados y eventualmente aprobados. - Los cambios semi-formales se efectuarán sobre los ECS que ya pasaran por una revisión técnica formal y forman parte de una línea base. - Para realizar una solicitud de cambio, el jefe de proyecto evaluará el cambio para saber si es “Leve” o “Alto”, de ser leve será asignado a un miembro del equipo de desarrollo para su realización, pero, si el cambio es Alto entonces será asignada a un comité evaluador elegido por el Jefe de Proyecto. Esta solicitud debe contener obligatoriamente el motivo del cambio (qué es lo que debe cambiarse, quien lo solicita y una descripción clara del problema). - Cualquiera de los miembros evaluadores del comité decide si aceptar o rechazar la solicitud la opinión será independiente. Sistema para la Gestión de la Configuración del Software - Las respuestas de aceptación o rechazo serán enviadas a la evaluación final donde se apreciarán todo tipo de comentarios, así como recomendaciones que hayan hecho los miembros evaluadores. - El Jefe de Proyecto será el que, decidirá si se acepta o rechaza en una estancia final. De ser aceptada la solicitud pasara inmediatamente a la programación de la misma para su próxima ejecución por parte del Equipo de desarrollo, donde se indique el nombre del cambio que fue propuesto en la solicitud, además de especificar fechas de inicio y de finalización. - Una vez el equipo reciba la orden de cambio, el equipo mismo seleccionará a los miembros que realicen el cambio, por lo cual elegirán el reposito del proyecto al cual se le hará el cambio. El cambio será ejecutado y se generará una última versión del repositorio involucrado. - Una vez hecha la nueva versión, el equipo redactara el documento acerca del cambio y le enviara al jefe para que confirme los cambios realizados. - El jefe enviara un correo al solicitante donde indique que tanto su solicitud y el cambio fueron efectuados. El Comité y el equipo de desarrollo son parte del proyecto, el Jefe de Proyecto se encargará de elegir a los miembros del comité. Sistema para la Gestión de la Configuración del Software 3.2.3. Solicitud de Cambios Cuando se realiza la solicitud de un cambio, se actualiza el registro SGCS_SC “Solicitud de cambio”. Se debe ingresar toda la información necesaria, detallada en el documento y se referencia en el plan de configuración punto 1.3 (Referencia). 3.2.4. Evaluación de Cambios y Análisis de Impacto La evaluación del cambio involucra determinar qué es necesario hacer para implementar el cambio y la estimación de sus costos y plazos. Se realiza en 2 pasos: 3.2.4.1. Planificación de la evaluación del cambio que involucra: - Revisar la solicitud de cambio para entender su alcance. (Si es necesario se discute con el originador para aclarar el alcance de lo propuesto y los motivos de la solicitud. - Determinar las personas del proyecto que deben realizar el análisis de evaluación del cambio e involucrarlas. - Si el cambio involucra al Cliente, obtener el acuerdo de éste con el Plan. 3.2.4.2. Evaluar el cambio: Dependiendo de las características del cambio, la evaluación del cambio puede ser realizado por el Administrador o ser delegado a otras personas del proyecto. Se debe determinar el impacto en: - Los Planes de proyecto. - Los acuerdos con el Cliente. - Los Riesgos del proyecto. Sistema para la Gestión de la Configuración del Software Proceso de Cambio 3.2.5. Aprobación o Desaprobación de Cambios Se debe formar el “Comité de Control de Configuración” y determinar su autoridad para la aprobación de cambios. La composición de este comité puede variar según el tipo de cambio y las líneas de trabajo involucradas en él. Se diligencia el formato SGCES_ADC “Aprobación de cambios” y se referencia en el plan de configuración. 3.2.6. Implementación de Cambios Una vez realizada la evaluación del cambio, se decide en qué momento implementarlo. Esta etapa involucra los procesos necesarios para implementar la solicitud y monitorear el progreso del trabajo. Además, se especificará el momento de liberación del cambio; así como también los responsables de las actividades que involucra el cambio. Sistema para la Gestión de la Configuración del Software 4. CALENDARIO Las entregas están definidas en el cronograma del modelo de proceso, realizándose luego de finalizar cada iteración. El control de cambios se realizará durante cada iteración, en función de las solicitudes recibidas. Luego de realizada la verificación y entrega de los productos de una iteración, durante los dos días siguientes a la entrega, se hará una revisión y auditoria de la línea base. Esto es verificar que estén todos los entregables correspondientes a la iteración, fijar y respaldar la línea base. 5. RECURSOS Y ADIESTRAMIENTO Personas: - Jefe de Proyecto - Encargado de Cambio - Responsable GCS Herramientas: - Google Drive - Github 6. PUNTOS DE CONTROL El artefacto Plan de Gestión de configuración será actualizado en los siguientes escenarios: - Cuando el Proceso de Control de Cambios ha sido modificado. - Cuando los Elementos de Configuración aumentan o disminuyen. - Cuando los medios de almacenamiento y/o las herramientas usados inicialmente son cambiadas. Sistema para la Gestión de la Configuración del Software Sistema para la Gestión de la Configuración del Software Plan de Gestión de Riesgos Comunicaciones Integrales Sistema para la Gestión de la Configuración del Software CONTROL DE VERSIONES Versión Realizado por Revisado por Aprobado por Fecha Motivo 1.0 YC RM RM 01-10-2019 Elaboración de plan de Gestión de Riesgos Sistema para la Gestión de la Configuración del Software PLAN DE GESTION DE RIESGOS 1. DESCRIPCIÓN DEL PROCESO El presente plan tiene como finalidad especificar como se enfocarán, planificarán y ejecutarán las actividades de Gestión de Riesgos para el proyecto de Sistema para la Gestión de la Configuración de Software. 2. METODOLOGÍA Si bien el registro de un riesgo puede ser realizado por cualquier integrante del equipo también es responsabilidad de todos los integrantes del equipo efectuar la administración de los riesgos que pueden llegar a amenazar al proyecto. 2.1. IDENTIFICAR El riesgo es identificado por cualquiera de los actores del proyecto, ya sea el Patrocinador, Equipo Consultor, etc. 2.2. DECLARAR RIESGOS La declaración de riesgos se realizará tiendo en cuenta el correcto enunciado del riesgo en donde debe estar descrito una condición y la consecuencia del riesgo. 2.3. ANALIZAR El análisis se realiza en base a tres indicadores como son: - La probabilidad de ocurrencia del riesgo. - El impacto y el nivel de exposición de éste (se obtiene de la multiplicación de la probabilidad por el impacto). Para cuantificar la probabilidad y el impacto se debe de utilizar una escala numérica. Se ha definido una escala numérica del 0.1 al 1 para la probabilidad y del 1 al 10 para el impacto. En las siguientes tablas se mostrarán los valores mínimos según la escala según cada tipo de probabilidad e impacto: Sistema para la Gestión de la Configuración del Software Escalas para la probabilidad Escalas para el impacto Probabilidad Valores Impacto Valores Muy alto 0.9 Muy alto 9 Alto 0.7 Alto 7 Medio 0.5 Medio 5 Bajo 0.3 Bajo 3 Muy bajo 0.1 Muy bajo 1 El riesgo del proyecto se calculará a través de esta formulada planteada: n Riesgo del Proyecto = ∑ Pi x Ii i=1 n Pi= Probabilidad de riesgo i li= Impacto del riesgo i Los riesgos, dependiendo de su impacto y probabilidad, podrán ser clasificados como: Alto, Medio y Bajo de acuerdo con los siguientes criterios: Probabilidad Amenazas / Oportunidades 0.9 0.9 2.7 4.5 6.3 8.1 0.7 0.7 2.1 3.5 4.9 6.3 0.5 0.5 1.5 2.5 3.5 4.5 0.3 0.3 0.9 1.5 2.1 2.7 0.1 0.1 0.3 0.5 0.7 0.9 Impacto 1 3 5 7 9 Riesgo Alto Riesgo Medio Riesgo Bajo Sistema para la Gestión de la Configuración del Software 2.4. PLANIFICAR La planificación del riesgo ve la definición de acciones para enfrentar a los riesgos en función al análisis que se obtiene de ellos. Las acciones contempladas pueden ser de Mitigación (antes que ocurra) y de contingencia (luego de que el riesgo ocurrió). Para cada tipo de acción se asigna un responsable de su realización. 2.5. SEGUIR Esto consiste en la periodicidad constante de la evaluación de riesgos para poder actualizar los indicadores de probabilidad e impacto. La modificación de algunas características de un riesgo puede ser la consecuencia de la ejecución de las actividades identificadas para combatirlo o también puede que dependa de alguna otra variación en el entorno. 2.6. CONTROLAR Se realiza en medio de las reuniones de seguimiento y control del proyecto activo, en ellas se evaluará la ejecución de acciones ya definidas para mitigar el riesgo o para actuar en caso sea de contingencia. La ejecución de acciones ya definidas puede generar que los riesgos sean sacados de la lista de riesgo a gestionar. 3. ROLES Y RESPONSABILIDADES Rol Responsabilidades - Jefe del Proyecto - Equipo del Proyecto - Escribirá el Informe de Seguimiento de Riesgos e identificar riesgos apropiados para el proyecto. Informar sobre todas las decisiones tomadas. Observar y seguir el progreso y las acciones de mitigación asignadas. Reconocer el riesgo y formalmente a través de una carta u otro medio comunicarlo al Jefe del Proyecto. Asignar acciones para mitigar el riesgo. Quitar los riesgos que no muestran acciones pendientes y no presentan probablemente más impacto al proyecto. 4. PERIODICIDAD El registro de riesgos se deberá actualizar en cada reunión junto al avance que se vaya realizando y presentado. Sistema para la Gestión de la Configuración del Software Sistema para la Gestión de la Configuración del Software Documento Visión V1.1 Comunicaciones Integrales Sistema para la Gestión de la Configuración del Software CONTROL DE VERSIONES Versión Realizado por Revisado por 1.1 FC RM Aprobado por Fecha 22-08-2019 Motivo Creación del documento Sistema para la Gestión de la Configuración del Software CONTENIDO 1. INTRODUCCION ........................................................................................................... 4 1.1. PROPÓSITO ................................................................................................................. 4 1.2. OBJETIVOS................................................................................................................... 5 1.2.1. OBJETIVOS GENERALES ...................................................................................... 5 1.2.2. OBJETIVOS ESPECÍFICOS ................................................................................... 5 1.3. ALCANCE ...................................................................................................................... 5 1.4. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS ...................................................... 6 1.5. REFERENCIAS ............................................................................................................. 6 1.6. DECLARACIÓN DEL PROBLEMA................................................................................. 6 2. SENTENCIA QUE DEFINE EL POSICIONAMIENTO …………………………………………. 7 3. RESUMEN DE STAKEHOLDERS……………………………………………………………….…8 4. DESCRIPCION DEL PRODUCTO………………………………………………………………....8 4.1. RESUMEN DE CAPACIDADES……………………………………………………………….8 4.2. RESTRICCIONES DEL SISTEMA ................................................................................. 9 5. REQUERIMIENTOS DE DOCUMENTACION…………………………………………………..10 5.1 MANUAL DE USUARIO……………………………………………………………………….10 5.2 GUIA DE INSTALACION Y CONFIGURACION……………………………………………10 5.3 ETIQUETADO Y EMPAQUETADO………………………………………………………….10 Sistema para la Gestión de la Configuración del Software DOCUMENTO VISIÓN 1. INTRODUCCION El presente documento tiene por función proveer una visión general de la arquitectura del Sistema Gestión de Cambios de Software (SGCS) usando diferentes vistas para apreciar los diferentes aspectos del sistema, utilizando el Rational Rose Enterprise Edition. El presente documento tiene por función describir detalladamente la arquitectura del Sistema Gestión de Cambios de Software (SGCS), plasmar mediante diagramas y modelos utilizando el Rational Rose, bosquejar los requerimientos funcionales del programa, definir los casos de uso, diagramas de secuencia y diagrama de clases. Los detalles de cómo el sistema se realizará y cubrirá los requerimientos se pueden observar en la especificación de los casos de uso y otros documentos adicionales que avalan el planeamiento y desarrollo. 1.1. PROPÓSITO En cuanto al propósito principal de este sistema es automatizar y optimizar los procesos de gestión de usuario, gestión de proyecto, generación de las solicitudes de cambio y gestionar las solicitudes de revisión. De esta manera se pueda llevar un control más rápido de las diferentes actividades de cada miembro de un proyecto. Sistema para la Gestión de la Configuración del Software 1.2. OBJETIVOS 1.2.1. OBJETIVOS GENERALES El Sistema Gestión de Cambios de Software (SGCS) tiene como objetivo principal automatizar la Gestión de la configuración de un proyecto de software automatizando y reduciendo tiempos, de esta manera agilizar los procesos de los proyectos. 1.2.2. OBJETIVOS ESPECÍFICOS - Crear un software que permita la gestión de documentos y las versiones de éste. - Crear un software que permita la gestión de Usuarios. - Crear un software que permita mostrar los proyectos y ver su estado. - Crear un software que permita la generación de solicitud de revisión. - Crear un software que permita la generación de solicitud de cambio. 1.3. ALCANCE En este documento se describen y detallan la arquitectura propuesta del sistema, diagramas de diseño y modelo de datos necesarios para comprender el comportamiento de los componentes del Sistema Gestión de Cambios de Software. El sistema permitirá tener un mejor control de versiones y cambios realizados para la mejor y rápida obtención de información disponible y actualizada. Sistema para la Gestión de la Configuración del Software 1.4. DEFINICIONES, ACRÓNIMOS Y ABREVIATURAS Las definiciones, acrónimos y abreviaturas están detalladas en el Glosario de Términos del sistema, donde se especificará de manera clara y concisa de las definiciones, acrónimos y abreviaturas que se usaran para el desarrollo del sistema, a fin de tener una comunicación entendible. - SGCS_GlosarioTerminos 1.5. REFERENCIAS Los documentos que se van a utilizar como referencia son: - Diagrama de casos de uso. - SGCS_GlosarioTerminos 1.6. DECLARACIÓN DEL PROBLEMA El problema Actualmente no se cuenta con un sistema que pueda ser de: capaz de ver las versiones y los nuevos cambios lo cual causa deficiencia en los diferentes procesos. Afecta: A los miembros de la Empresa Briken y también a los clientes. El impacto Demora en el proceso de revisar los cambios y nuevas de esto es: versiones realizados por los miembros del proyecto. Una solución Automatizar el proceso de gestión de proyectos que sea exitosa sería: capaz de llevar un control apropiado de los mismos y actualice los resultados de avance. Sistema para la Gestión de la Configuración del Software 2. SENTENCIA QUE DEFINE EL POSICIONAMIENTO Para: Curso Gestión de la Configuración Quienes: Control de versiones de un proyecto Control de cambios de un proyecto Sistema SGCS: Sistema de Gestión de Cambios de Software Qué: Optimiza la gestión de proyectos, lo cual permitirá la agilización en la culminación de los proyectos. También se visualizará los cambios realizados por los miembros del proyecto. Se diferencia: Del sistema actual no automatizado. Nuestro producto: Permite gestionar los distintos proyectos mediante una interfaz gráfica sencilla y amigable. Además, proporciona un acceso rápido y actualizado a la información desde cualquier punto que tenga acceso a la base de datos. Sistema para la Gestión de la Configuración del Software 3. DESCRIPCION DE STAKEHOLDERS INTERESADOS DESCRIPCIÓN PODER RELATIVO Será el principal responsable para que la ALTA ejecución del proyecto se lleve a cabo. JEFE DE PROYECTO Será además quien responda por el proyecto. Asimismo, será el que determine las tareas de cada uno de los integrantes que desarrollan el sistema. COMITÉ DE CAMBIO Se encarga de aprobar o rechazar las ALTA solicitudes de cambio solicitadas por los miembros de equipo. Cada miembro de equipo se encarga de ALTA realizar las tareas brindadas por el Jefe de MIEMBROS DE EQUIPO Proyecto y solicitar la revisión. Asimismo, podrá agregar una nueva versión en caso de que tenga alguna observación la tarea enviada. Es el encargado de crear proyectos y ADMINISTRADOR ALTA gestionar usuarios. 4. DESCRIPCIÓN DEL PRODUCTO. 4.1. RESUMEN DE CAPACIDADES BENEFICIOS PARA EL CLIENTE CARACTERÍSTICAS QUE LOS SOPORTAN Generación de los proyectos de Automatización de la carga de manera rápida y automatizada. proyectos. Sistema para la Gestión de la Configuración del Software Gestión automatizada del proyecto El sistema contará con un módulo y la disponibilidad del mismo. de visualizar estado de proyectos. Se podrá visualizar los cambios Genera reportes de la solicitud de solicitados. cambios. Se podrá solicitar revisión de las Genera reportes de solicitud de tareas por parte de los miembros revisión. del proyecto Seguridad en la información que Respaldos de la BD y de la posee. información de los documentos generados con sus respectivas versiones y revisiones. 4.2. RESTRICCIONES DEL SISTEMA El Proyecto no incluye: - Aplicación móvil. 4.3. SUPOSICIONES - Se cuenta con los permisos adecuados para la implementación y el despliegue de la aplicación a lo largo del proyecto. - El buen uso del sistema a implementar va a depender mucho del nivel de conocimiento de los involucrados. 4.4. DEPENDENCIAS El proyecto no cuenta con algún otro sistema por ende este será la base para la creación de nuevos proyectos y debido a esto este sistema no tiene ninguna dependencia de algún subsistema. Sistema para la Gestión de la Configuración del Software 4.5. LICENCIAMIENTO E INSTALACIÓN El software utilizado para el sistema no presenta ningún problema de licenciamiento debido a que los programas utilizados para su desarrollo son libres. 5. REQUERIMIENTOS DE DOCUMENTACIÓN 5.1. MANUAL DE USUARIO El documento del manual de usuario del proyecto de Sistema de Gestión de Cambios de Software contendrá la información necesaria, de fácil entendimiento y con un lenguaje simple. Este documento incluirá, una descripción general del sistema. 5.2. GUÍA DE INSTALACIÓN Y CONFIGURACIÓN Este anexo del manual de usuario contendrá las instrucciones para la implantación del sistema. La guía de instalación del sistema incluirá los requerimientos mínimos de software para que el sistema funcione correctamente. Esta guía se compone de dos partes: - Base de datos: Contendrá las instrucciones para ingresar toda la data necesaria para que el producto funcione correctamente. - Servidor de aplicaciones: Contendrá las instrucciones para instalar los archivos y configuraciones necesarias en el servidor de aplicaciones. 5.3. ETIQUETADO Y EMPAQUETAMIENTO El entregable final incluirá un CD-ROM de instalación, Manual de Usuario y Guía de Instalación, además de un breve resumen de las características del sistema. Sistema para la Gestión de la Configuración del Software Sistema para la Gestión de la Configuración del Software Glosario de Términos Comunicaciones Integrales Sistema para la Gestión de la Configuración del Software CONTROL DE VERSIONES Versión Realizado por Revisado por Aprobado por 1.1 FC RM RM Fecha 28-08-2019 Motivo Creación del documento Sistema para la Gestión de la Configuración del Software GLOSARIO DE TÉRMINOS 1. INTRODUCCÓN Este documento dará a conocer los términos a utilizarse en el Sistema de Gestión de Cambios de Software. En este se pondrá a disposición un conjunto de definiciones breves y sintéticas de conceptos que, aunque bien conocidos, a veces se han descrito de formas muy diferentes. 1.1. PROPÓSITO El propósito de este documento es clarificar los términos usados en la documentación del sistema Gestión de cambios de software, ya que el correcto entendimiento de estos es fundamental para el mejor desarrollo del proyecto. 1.2. ALCANCE En este documento se definen todos los términos utilizados en el sistema. Sistema para la Gestión de la Configuración del Software 2. GLOSARIO A-Z A ACTA DE CONSTITUTION DE PROYECTO Documento en el que se define el alcance, los objetivos y los participantes del proyecto, así como las personas involucradas en ella (stakeholders). ADMINISTRADOR Tipo de usuario que tiene acceso a todas las funciones del sistema, excepto donde se indique. ANÁLISIS Examen detallado de una cosa para conocer sus características o cualidades, o su estado. ACTORES Se le llama actor a la persona que interactúa con el sistema. APLICACIÓN Tipo de programa informático diseñado como herramienta para permitir a un usuario realizar su trabajo. Sistema para la Gestión de la Configuración del Software B BASE DE DATOS Es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. BETA (VERSIÓN BETA) Es una versión de software que ha pasado la etapa de prueba interna, llamada "Alfa" y ha sido lanzada a los usuarios para pruebas públicas. C CALIDAD La calidad puede definirse como la conformidad relativa con las especificaciones, a lo que al grado en que un producto cumple las especificaciones del diseño, entre otras cosas, mejora su calidad o también es común encontrar la satisfacción en un producto cumpliendo todas las expectativas que busca algún cliente. CLIENTE Persona u organización a la que se le prestan servicios o se le venden determinados bienes. Sistema para la Gestión de la Configuración del Software CASOS DE USOS Es una técnica para la captura de requisitos potenciales de un nuevo Sistema o una actualización de Software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. D DISEÑO Proceso de prefiguración mental, es decir, de planificación creativa, en el que se persigue la solución para algún problema concreto, especialmente en el contexto de la ingeniería, la industria, la arquitectura, la comunicación y otras disciplinas afines. E EDT La Estructura Desglosada de Trabajo (EDT), es una técnica muy conocida y de vital importancia para la gestión de proyectos medianos y grandes ya que nos ayuda a identificar los paquetes de trabajo, responsables, presupuestos y recursos necesarios para llevar a cabo la ejecución de cualquier proyecto. EMPRESA Unidad económico-social, integrada por elementos humanos, materiales y técnicos, que tiene el objetivo de obtener utilidades a través de su participación en el mercado de bienes y servicios. Sistema para la Gestión de la Configuración del Software F FRAMEWORK Es un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia, para enfrentar y resolver nuevos problemas de índole similar. I INTERFAZ Mecanismo o herramienta que posibilita esta comunicación mediante la representación de un conjunto de objetos, iconos y elementos gráficos que vienen a funcionar como metáforas o símbolos de las acciones o tareas que el usuario puede realizar en la computadora. K KICK OFF Es la reunión que determina el inicio de un proyecto, la primera toma de contacto entre los clientes y los empleados. Podemos definir esta reunión como un encuentro entre los responsables de la empresa ejecutora del proyecto y el cliente para hablar de todo lo que tenga que ver con el nuevo proyecto y dónde se establece, formalmente, su arranque. Sistema para la Gestión de la Configuración del Software L LARAVEL Es uno de los frameworks de código abierto más fáciles de asimilar para PHP. Es simple, muy potente y tiene una interfaz elegante y divertida de usar. Fue creado en 2011 y tiene una gran influencia de frameworks como Ruby on Rails. M MISIÓN Depende de la actividad que la organización realice, así como del entorno en el que se encuentra y de los recursos de los que dispone. N NAVEGADOR Software o programa que permite navegar por internet u otra red informática de comunicaciones. P PHP Lenguaje de programación web. Es el más popular y usado comúnmente. Sistema para la Gestión de la Configuración del Software PROTOTIPO Modelo del comportamiento del sistema que puede ser usado para entenderlo completamente o ciertos aspectos de él y así clarificar los requerimientos... Un prototipo es una representación de un sistema, aunque no es un sistema completo, posee las características del sistema final o parte de ellas. PLAN DE GESTIÓN Documento que especifica las acciones que se realizarán para mantener la calidad en todo el proceso de desarrollo del producto PLAN DE GESTIÓN DE RIESGOS Documento que especifica los riesgos encontrados y cómo actuar frente a ellos. PLAN DE GESTIÓN DE CAMBIOS Documento que especifica los cambios realizados por un miembro del proyecto. R RELEASE Liberación del programa. Para un mejor entendimiento, es cuando el sistema ha terminado de codificarse cumpliendo con toda la funcionalidad especificada y es mostrada al usuario para las pruebas correspondientes. RIESGO Vulnerabilidad ante un potencial perjuicio o daño para el proyecto. REQUERIMIENTO Atributo necesario dentro de un sistema, que puede representar una capacidad, una característica o un factor de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios finales. Sistema para la Gestión de la Configuración del Software S SERVIDOR Equipo de cómputo que provee de servicios a otros equipos o hosts. En este caso, es el que proveerá de una base de datos y se albergará en la nube en un host gratuito como prueba. SOFTWARE LIBRE Es el software que respeta la libertad de los usuarios y la comunidad. A grandes rasgos, significa que los usuarios tienen la libertad de ejecutar, copiar, distribuir, estudiar, modificar y mejorar el software. Es decir, el software libre es una cuestión de libertad, no de precio. STAKEHOLDER Se refiere a todas aquellas personas u organizaciones afectadas por las actividades y las decisiones de una empresa. SRS Es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software el cual tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas. T TECNOLOGÍA Constituye un conjunto de conocimientos científicamente ordenados, que permiten diseñar y crear bienes o servicios que facilitan la adaptación al medio ambiente y la satisfacción de las necesidades esenciales Sistema para la Gestión de la Configuración del Software U USUARIO Se entiende por usuario a un conjunto de permisos y de recursos asignados a un operador como parte de una red informática, y que bien puede ser una persona, un programa informático o un computador. V VISIÓN Exposición clara que indica hacia dónde se dirige el sistema a largo plazo y en qué se deberá convertir, tomando en cuenta el impacto de las nuevas necesidades y expectativas cambiantes de los clientes.