UNIVERSIDAD ESTATAL A DISTANCIA

ESCUELA DE CIENCIAS EXACTAS Y NATURALES

CÁTEDRA DE DESARROLLO DE SISTEMAS

CURSO:
00828- ANALISIS DE SISTEMA II

Proyecto
ETAPA 2

Estudiante: Eric Delgado Acevedo - 503000040

Fabio Vílchez Cortes - 503480037

Centro Universitario: San José

Grupo: 01

Fecha de Entrega: 27/04/2014

I CUATRIMESTRE 2014
Tabla de contenido

Introducción.............................................................................................................................................................3

Desarrollo................................................................................................................................................................. 4

Descripción General del Proyecto........................................................................................................................4

Lista Requerimientos............................................................................................................................................5

Procesos a Implementar.......................................................................................................................................5

Plan de Pruebas......................................................................................................................................................15

Características a evaluar.....................................................................................................................................15

Tipos de Pruebas................................................................................................................................................15

Proceso de Pruebas............................................................................................................................................17

Plan de Mantenimiento..........................................................................................................................................18

Tipos de Mantenimientos...................................................................................................................................18

Actividades en el proceso de mantenimiento....................................................................................................20

Plantilla de plan de mantenimiento....................................................................................................................24

Gestión de calidad..................................................................................................................................................25

Descripción de la metodología o técnica de gestión de calidad a implementar.................................................25

Plan de Calidad Del Proyecto..............................................................................................................................26

Plantilla de Calidad Del Proyecto........................................................................................................................27

Descripción del plan de gestión de administración de la configuración.................................................................28

Plantilla de administración de la configuración a utilizar....................................................................................32

Conclusión..............................................................................................................................................................35
Bibliografía.............................................................................................................................................................36

Introducción

En la actualidad la ingeniería de software se ha tomado muy en serio los procesos que

involucre aspecto de calidad del software, anteriormente estos procesos de hacían de una

forma empírica y poco metódica, prácticamente el programador era juez y parte del proceso,

dando resultados que en ocasiones eran poso favorables. En estos tiempos, estos procesos

de aseguramiento de calidad están implementados sobre normas y métodos ya probados y

normalizados, que nos llegan a contribuir a facilitarnos la planeación de estos procesos,

seleccionar patrones ya existentes y a tener una seguridad que los resultados que vamos a

obtener van a estar muy bien fundamentados.

Pero todos estos procesos no nos sirven de nada si en la práctica no los tomamos en cuenta

a la hora de implementar un desarrollo de un sistema.

Desarrollo

Descripción General del Proyecto

El proyecto consta del desarrollo de una aplicación para la administración de proyectos y otra

para la administración de riesgos de los proyectos. Esta necesidad nace a raíz del

requerimiento que solicita la empresa GM, especializada en el desarrollo de software, el cual

nos solicita desarrollar dichos módulos, debido a que ellos en este momento manejan ciertos

datos en Excel y otros del todo no tienen nada registrado.

Alcances del Proyecto

1. Mejorar la exactitud de los estimados de costo y tiempo.

2. Definir una línea de base para medición y control del proyecto.

3. Facilitar una clara asignación de roles y responsabilidades.

4. Determinar las posibles amenazas de un proyecto, para mitigar sus consecuencias.

Limitaciones

1. La aplicación registra solo eventos, de forma descriptiva, no se va a manejar eventos

en función de tiempos y avances, para esto existe herramientas como Microsoft Project.
Lista Requerimientos

 Registrar la información de los proyectos

 Registrar los riesgos asociados a cada uno de los proyectos para poder llevar un

control más efectivo.

 Interface sea web

 Administrar la siguiente información

o Información de clientes

o Actividades del EDT de los proyectos

o Acciones tomadas para los riesgos

o información de los proyectos

 actividades

 riesgos

o Usuarios

 Creación de un módulo de consultas para reportes

Procesos a Implementar

Casos de Uso
 Administración de Proyectos y
Control de Riesgos

Solicitar Servicio

«extends»

Registrar Cliente

Cliente Usuario

Registrar Proyecto «extends»

«uses»

«extends»
Registrar Tareas y
«extends»
responsables

Definir Riesgos
del Proyecto Admin Proyecto

Toma de decisiones «uses»

Bitacora de
sobre riesgos
eventos y Riesgos

Reportes Lider Tecnico

Registro de
Usuarios

Usuario Admin
Registro de
Perfiles de Usuario

Detalle de los casos de uso

Caso de Uso Solicitar Servicios

Precondiciones
Postcondiciones

Actores Cliente

Excepciones

Descripción Solicitar un servicio de desarrollo de una solución

1. Cliente llega y hace una solicitud de un desarrollo de un

Pasos sistema.
2. Llena formulario de solicitud de servicios

Caso de Uso Registrar Cliente

Precondiciones El cliente solicito un servicio

Postcondiciones El cliente queda registrado

Actores Usuario

Excepciones Si el cliente existe no se realiza este proceso

Descripción Registro del cliente c, con los datos personales suficientes

para poderlo contactar

1. Usuario verifica si el cliente existe en el sistema.

Pasos 2. Si no existe, registra el cliente en el sistema, con los
datos requeridos para contactarlo
Caso de Uso Recolectar Requerimientos

Precondiciones El cliente solicito un servicio

Postcondiciones Queda registrado un documento de los requerimientos del

desarrollo

Actores Admin. de Proyecto – Cliente

Excepciones

Descripción Creación de un documento con los requerimientos del

proyecto

1. Administrador de Proyecto Entrevista al cliente

Pasos 2. Se determina los requerimientos del sistema que se
desea desarrollar.
3. Se crea un documento con los requerimientos del
sistema

Caso de Uso Análisis de Requerimientos

Precondiciones Se realizó la recolección de requerimientos

Postcondiciones Se confecciona el documento con los diagramas y flujos que

va a llevar el sistema, con base a los requerimientos dados por
el cliente
Actores Admin. de Proyecto

Excepciones

Descripción Confección del documento del análisis del sistema

1. Se analiza el documento de requerimientos

Pasos: 2. Se confecciona los diagramas UML necesarios
3. Se confecciona el diccionario de datos
4. Se diseña la base de datos con el modelo ER

Caso de Uso Registrar Proyecto

Precondiciones El cliente solicito un servicio

Postcondiciones Queda Debidamente registrado un nuevo proyecto

Actores Admin. de Proyecto

Excepciones

Descripción Registro de un proyecto de desarrollo, con los parámetros

necesarios para poder llevar el control del mismo.

1. Ingreso al sistema
Pasos: 2. Ingreso a la pantalla de registro de Proyectos
3. Registrar el nuevo proyecto, con los datos requeridos
4. Adjuntar al proyecto los documentos de recolección de
 requerimientos y los documentos del análisis del
sistema.

Caso de Uso Registrar Tareas y responsables

Precondiciones Registro de un proyecto

Postcondiciones El itinerario del proyecto se completa

Actores Admin de Proyectos

Excepciones

Descripción Registro de todas las tareas o actividades que se van a

realizar en el proyecto.

Asignación de los responsables de realizar cada tarea

1. De acuerdo al análisis realizado se confecciona las

Pasos tareas que se van a realizar en el proyecto.
2. Se ingresa al sistema.
3. Se ingresa a la pantalla de registro de actividades.
4. Se registra las actividades del proyecto.
5. Definir los tiempos aproximados de cada actividad
6. Para cada actividad se registra los responsables de esa
actividad.

Caso de Uso Definir Riesgos del Proyecto

Precondiciones Registro de un proyecto

Postcondiciones

Actores Admin de Proyectos

Excepciones

Descripción Registro de los posibles riesgos de un proyecto, sus

consecuencias y las posibles actividades de mitigación.

1. Definir los posibles riesgos que se puedan presentar en

Pasos el proyecto.
2. Ingresar a la aplicación.
3. Ingresar a la pantalla de registro de Riesgos
4. Registrar riesgos y actividades de mitigación

Caso de Uso Bitácora de eventos y Riesgos

Precondiciones Iniciar el proyecto

Postcondiciones

Actores Líder Técnico

Excepciones

Descripción Registro de bitácora de eventos, relacionados con el día a día

 de un proyecto.

Registro de realización de las tareas asignadas al proyecto.

Registro de eventos de riegos

1. Ingresar la pantalla de registro de bitácora.

Pasos 2. Seleccionar si se bitacorea una tarea o una actividad de
riesgo
3. Registrar el evento y actividad realizada

Caso de Uso Toma de decisiones sobre riesgos

Precondiciones Registro de eventos de riegos

Postcondiciones Riesgo mitigados

Actores Líder Técnico

Excepciones No ocurre a menos que existan riesgos en el proyecto

Descripción Al registrar un riesgo, se toma la decisión de las acciones a

realizar para mitigar el evento y no poner en peligro el
proyecto.

1. Seleccionar el tipo riesgo surgido.

Pasos 2. Registrar la actividad realizada de mitigación.
Caso de Uso Reportes

Precondiciones Registro de Proyectos y Bitácora de actividades

Postcondiciones

Actores Admin de Proyectos

Excepciones

Descripción Consulta de reportes de diversa índole, para la toma de

decisiones

Caso de Uso Registro de Usuarios

Precondiciones Solicitud de un usuario nuevo

Postcondiciones Usuarios registrados

Actores Usuario Admin.

Excepciones

Descripción Registro de usuarios de los sistemas

 1. Ingresar al sistema como administrador
Pasos 2. Ingresar a pantalla de usuarios
3. Registrar usuario y definir su rol

Caso de Uso Registro de perfiles de usuario

Precondiciones

Postcondiciones

Actores Usuario Admin.

Excepciones

Descripción Registro de los perfiles de accesos que se van a manejar en

los sistemas y asignar a los usuarios.

1. Ingresar al sistema como administrador

Pasos 2. Ingresar a pantalla de Roles
3. Registrar registrar los roles
4. Asignar los roles al usuario si fuera el caso.
Plan de Pruebas

Las pruebas de software es una etapa más del proceso de desarrollo de software, tiene como meta asegurar que

el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener.

Características a evaluar

Característica Descripción Módulo de sistema

Requerimientos Se evaluará el sistema en función al Lógica de Negocio

Funcionales documento de casos de uso y del casos en Objetos de acceso a datos
que el sistema cumple o cuando el sistema
presenta fallos.

Requerimientos No Se evaluará el nivel de aceptación de No aplica.

Funcionales acuerdo a los que esté definido en el
documento del requerimiento para su
cumplimiento.
Tipos de Pruebas

Pruebas de Unidad

Pruebas que se van a realizar a un conjunto de clases y objetos estratégicos para el buen funcionamiento del

sistema. Estas pruebas se van a ir realizando conforme se va implementado los diferentes módulos que lleven

Lógica de negocios y se van a aplicar en objetos o rutinas estratégicas que afecten el funcionamiento integral del

sistema.

NOMBRE Pruebas Unitarias

RESPONSABLE Responsable de realiza la prueba

Clase u Objeto Nombre de clase u objeto a ser evaluado

Tiempo Proyectado Tiempo definido para la clase

Herramienta Herramienta de desarrollo

Entregables Lista de chequeo sobre el cumplimiento los resultados obtenido en la

ejecución de los procesos evaluados en la clase u objeto

Pruebas de Limites

Pruebas frontera, son las que toman en cuenta valores límite, para verificar el comportamiento de la herramienta

en esos casos.

NOMBRE Pruebas de Frontera

RESPONSABLE Responsable de realiza la prueba

ACTIVIDADES Se realizaran las distintas pruebas con los valores límites y mínimos que
debe recibir el programa.

TIEMPO ESTIMADO 15 minutos por prueba

MÉTODOS Netbeans
En cuanto a los entregables de esta prueba se llenara la siguiente tabla:

Nombre

Valor máximo Valor mínimo

Resultado esperado

Resultados obtenidos

Estado Funciona: No funciona:

Comentarios

Pruebas basadas en requerimientos

Las pruebas de integración, como su nombre lo indica, son pruebas hechas a un conjunto de requerimientos, en

este caso se distribuyen en los tipos de requerimientos que se definieron en el documento.

NOMBRE Requerimiento

RESPONSABLE Responsable de realiza la prueba

ACTIVIDADES

TIEMPO ESTIMADO

HERRAMIENTAS Netbeans

ENTREGABLES Informe donde se indica si se cumple con el requerimiento o no

Resultado de las pruebas de Integración

ID GRUPO DE RESULTADOS DE LA PRUEBA

REQUERIMIENTOS

Requerimiento Resultado de la prueba.

Pruebas de Sistema

Las pruebas de sistema son pruebas realizadas a la herramienta como un conjunto, que casos de uso cumple a

cabalidad, con rutas de éxito y fallo, que han sido definidas en el documento de Casos de Uso.

NOMBRE Pruebas sistemas IDENTIFICADOR ST01

RESPONSABLE Responsable de realiza la prueba

ACTIVIDADES Se realizaran pruebas funcionales y No funcionales

TIEMPO ESTIMADO

MÉTODOS Netbeans

ENTREGABLES Informe generado por el responsable de esta prueba el cual

informara si se tiene un correcto funcionamiento o no.

Resultado de las pruebas de sistema

ID CASO DE USO RESULTADOS DE LA PRUEBA

Nombre del Caso de Uso Resultado de la prueba.

Proceso de Pruebas

En esta sección se presentan los casos de pruebas generales. Cada cuadro está asociado a un caso de Uso,

desde ahí se desglosa en los diferentes módulos involucrados para el funcionamiento y se evalúa el resultado

obtenido. En las siguientes tablas, se muestran los casos de pruebas a realizar:

NOMBRE

PROPÓSITO Describir el propósito de la prueba, que se va a evaluar

PRERREQUISITOS Definir lo prerrequisitos que se deben de tener para ejecutar la

prueba

UBICACIÓN Base de datos y Pantalla o módulo

ENTRADA Datos de entrada

RESULTADO Resultado de la ejecución

PASOS Pasos a seguir en la prueba

Plan de Mantenimiento

Tipos de Mantenimientos

Mantenimiento Correctivo

A pesar de las pruebas y verificaciones que aparecen en etapas anteriores del ciclo de vida del software, los

programas pueden tener defectos. El mantenimiento correctivo tiene por objetivo localizar y eliminar los posibles

defectos de los programas. Un defecto en un sistema es una característica del sistema con el potencial de causar

un fallo. Un fallo ocurre cuando el comportamiento de un sistema es diferente del establecido en la

especificación. Entre otros, los fallos en el software pueden ser de:

 Procesamiento: por ejemplo, salidas incorrectas de un programa.

 Rendimiento: por ejemplo, tiempo de respuesta demasiado alto en una búsqueda de información.
  Programación, por ejemplo, inconsistencias en el diseño de un programa.

 Documentación, por ejemplo, inconsistencias entre la funcionalidad de un programa y el manual de

usuario.

Mantenimiento Adaptativo

Este tipo de mantenimiento consiste en la modificación de un programa debido a cambios en el entorno

(hardware o software) en el cual se ejecuta. Estos cambios pueden afectar al sistema operativo (cambio a uno

más moderno), a la arquitectura física del sistema informático (paso de una arquitectura de red de área local a

Internet/Intranet) o al entorno de desarrollo del software (incorporación de nuevos elementos o herramientas

como ODBC).

La envergadura del cambio necesario puede ser muy diferente: desde un pequeño retoque en la estructura de un

módulo hasta tener que reescribir prácticamente todo el programa para su ejecución en un ambiente distribuido

en una red.

Los cambios en el entorno software pueden ser de dos clases:

 En el entorno de los datos, por ejemplo, al dejar de trabajar con un sistema de ficheros clásico y

sustituirlo por un sistema de gestión de bases de datos.

 En el entorno de los procesos, por ejemplo, migrando a una nueva plataforma de desarrollo con

componentes distribuidos, Java, ActiveX, etc.

El mantenimiento adaptativo es cada vez más usual debido principalmente al cambio, cada vez más rápido, en

los diversos aspectos de la informática: nuevas generaciones de hardware, nuevos sistemas operativos y

mejoras en los periféricos o en otros elementos del sistema.

Mantenimiento Perfectivo

Cambios en la especificación, normalmente debidos a cambios en los requisitos de un producto software,

implican un nuevo tipo de mantenimiento llamado perfectivo. Desde algo tan simple como cambiar el formato de

impresión de un informe, hasta la incorporación de un nuevo módulo aplicativo.

Podemos definir el mantenimiento perfectivo como el conjunto de actividades para mejorar o añadir nuevas

funcionalidades requeridas por el usuario. Algunos autores dividen este tipo de mantenimiento en dos:
  Mantenimiento de Ampliación: orientado a la incorporación de nuevas funcionalidades.

 Mantenimiento de Eficiencia: que busca la mejora de la eficiencia de ejecución.

Este tipo de mantenimiento aumenta cuando un producto software tiene éxito comercial y es utilizado por muchos

usuarios, ya que cuanto más se utiliza un software, más peticiones de los usuarios se reciben demandando

nuevas funcionalidades o mejoras en las existentes.

Mantenimiento Preventivo

Este último tipo de mantenimiento consiste en la modificación del software para mejorar sus propiedades (por

ejemplo, aumentando su calidad o su mantenibilidad) sin alterar sus especificaciones funcionales.

Por ejemplo: se pueden incluir sentencias que comprueben la validez de los datos de entrada, reestructurar los

programas para mejorar su legibilidad, o incluir nuevos comentarios que faciliten la posterior Comprensión del

programa. Este tipo de mantenimiento es el que más partido saca de las técnicas de ingeniería inversa y

reingeniería. Errores potenciales

Actividades en el proceso de mantenimiento

Proceso de Modificaciones de Solicitadas por el Usuario

Flujo del proceso cuando un usuario del sistema requiere que se proceda con una modificación, a un módulo o

pantalla. En ocasiones y cuando son modificaciones que el usuario quiere para mejorar o cumplir con algún

requerimiento nuevo, puede que se incurra en un costo adicional, el cual debe de ser cancelado por parte dl

cliente, este costo van en función a la complejidad y cantidad de recursos necesarios para pódelo desarrollar.
Proceso de Mantenimiento y Mejoras por parte de TI

TI siempre está haciendo revisiones y modificaciones a los sistemas con el fin de mejorar el modulo o corregir

algún problema ha detectado.

En algunos casos, estos procesos pueden dar como resultados versiones o actualizaciones considerables de la

solución, la cual requiere para poderlas adquirir de pagar un importe por las mismas, este costo va en función a

la complejidad y cantidad de recursos necesarios para desarrollarlo.

Etapas del Plan de Mantenimiento

A. Solicitud de Modificación: el usuario realiza una solicitud de modificación por medio de un formulario

donde expone el problema surgido o la modificación que requiere.

B. Análisis del Problema o Modificación:

 Analiza el informe del problema o requerimiento de modificación para determinar su impacto en

el sistema y en las interfaces

 Replica o verifica el problema

 Define varias opciones para implementar la modificación

 Documenta el informe del problema o requerimiento de modificación, los resultados y opciones

de implementación

 Obtiene la aprobación para la opción de modificación seleccionada.

C. Clasificación de Tipo de Mantenimiento: esta paso es importante para llevar identificar en la bitácora

del sistema los tipos d modificaciones que se han realizado con el tiempo.

D. Realización de la Modificación:

 Realiza un análisis para determinar los "elementos software" que deben ser modificados

 Invoca al proceso de desarrollo del software para realizar la modificación (incluyendo las

pruebas).

o Plan de desarrollo

o Asignación de recursos

o Calculo de costos

o Desarrollo de la aplicación

E. Revisión y Pruebas: se hace una revisión y prueba de la modificación por parte de personal de TI

F. Pruebas por parte del Usuario: El usuario hacer las pruebas necesarias para determinar si la

modificación cumple con lo requerido.

G. Aceptación de la Modificación: Obtiene la aprobación de la modificación mediante los mecanismos

determinados previamente (en un contrato o similar).

H. Implementación de la Modificación: se procede a implementar el nuevo sistema modificado en

producción.

I. Revisión y análisis de módulos del sistema: cíclicamente de hacer análisis y revisiones a ciertos

módulos y componentes del sistema con el objetivo de buscar mejoras al mismo, estas mejoras

pueden ir desde la parte estética, hasta la lógica de negocios y el proceso de accesos a datos.

J. Propuesto de Modificación: se realiza un documento donde se plantea los procesos de modificación,

definiendo en él los módulos afectados, el nivel a afectación, consecuencias de no hacer dicha

modificación.
Plantilla de plan de mantenimiento

DATOS DEL SOLICITANTE

SISTEMA Nombre del sistema

SOLICITANTE Solicitante de la modificación

MODULO Nombre de pantalla, reporte, proceso donde se requiere la modificación

DESCRIPSION Detalle de lo que se requiere hacer

IMPLICACIONES AL NO Describe las implicaciones que se tienen si esta modificación no se realiza

HACERSE

NIVEL DE ALERTA Opcional : si es para mejorar, pero no es obligatoria la modificación

Requerimiento Obligatorio: es requerido hacerlo

APRUEBA EL CAMBIO Autorizado a solicitar el cambio, en la organización

DATOS DE DEPARTAMENTO DE IT

NOMBRE DE ANALISTA Quien analizará el requerimiento

TIPO DE MANTENIMIENTO Correctivo

Preventivo
Adaptativo
Perfectivo

SE RECOMIENDA LA Si No
MODIFICACION
JUSTIFICACION

LISTA DE DOCUMENTOS Lista de documentos resultantes del análisis y realización de la

DE ANALISIS modificación.

COSTO TOTAL DE LA Costo total que se debe de invertir para el desarrollo de la modificación
MODIFICACIÓN

PERSONA IT QUE Persona con autoridad para aprobar la modificación

AUTORIZA EL CAMBIO
 DATOS DE DESARROLLO DE LA MODIFICACION

VISTO BUENO DEL COSTO Persona de la organización o cliente, que aprueba el costo del cambio, si
este tuviera un costo adicional.

FECHA DE ENTREGA Fecha donde se proyectó la entrega de la modificación

VISTO BUENO PRUEBAS Visto bueno por parte de IT sobre las pruebas y revisiones de la
DE IT modificación

VISTO BUENO PRUEBAS Visto bueno sobre la aceptación por parte del usuario de la modificación
DE ACEPTACION DE
USUARIO

Gestión de calidad

Descripción de la metodología o técnica de gestión de calidad a implementar

Para definir la metodología o técnicas de gestión de calidad del proyecto primero se

conocerán a fondo las características de calidad del proyecto de La empresa GM

Soluciones S.A.

Entre las características más sobresalientes del están:

A. Es un Sistema de información de los clientes de la empresa.

B. El proyecto es administrador de otros proyectos de la empresa GM Soluciones.

C. Es Manejador de riesgos globales.

D. Ayuda a la toma de decisiones para manejo de riesgos

E. Está asociado a diferentes actividades de la organización.

F. Podrán ser usado por usuarios y funcionarios de la empresa.

G. Todos los usuarios podrán accesar mediante un perfil de usuario.

H. Posee un módulo de consultas al sistema de bases de datos de la empresa.

Además el proyecto tendrá las siguientes características de calidad del proyecto.

1. Confiable

2. Fácil de Usar.

3. Disponible cuando se necesita

4. Seguro

5. Bien documentado

6. Encaja con las necesidades del usuario

7. Flexible a futuras necesidades

8. Es amigable con los usuarios.

Plan de Calidad Del Proyecto

1) Introducción del producto: Es proyecto administrador por medio de un sitio web se podrá

ingresar mediante un perfil de usuario en el cual se podrán realizar acciones como: Consultar,

modificar, Eliminar, insertar y Buscar proyectos de la empresa GM Soluciones S.A. Es una

herramienta que facilitara el manejo de riesgos de proyectos de la organización.

2) Planes del Producto: Las fechas de entrega del proyecto están estipuladas entre dos a

tres meses. Las responsabilidades para el producto final son la realización de todas las tareas

solicitadas por GM soluciones. En este tipo de proyecto no se requiere planes de distribución

debido a que es solo para una compañía como tal, es un servicio directo. Sin embargo si se
requiere darle un buen servicio de mantenimiento y seguimiento al sistema; se realizaran

semanalmente en el primer mes de uso, después se harán quincenalmente.

3) Descripciones de Procesos: dentro de los procesos de desarrollo se hará mediante un

equipo de desarrollo en donde cada miembro del equipo desarrollara una tarea específica

para concluir con un total. Los procesos del Sistema son: Solicitar Servicio, Registrar Cliente,

Registrar Proyecto, Definir Riesgos de los Proyectos, Etc.

4) Metas de Calidad: dentro de las metas de calidad tenemos varios atributos tales como:

Seguridad, Adaptabilidad, Eficiencia, modularidad y usabilidad, principalmente.

Plantilla de Calidad Del Proyecto

Historial de Revisión
<Grupo Responsable>
<Nombre Proyecto>
Fecha Introducción Planes Descripción de Metas de Riesgos y
Calidad Gestión
Procesos
<> <> <> <> <> <>
Descripción del plan de gestión de administración de la configuración

En lo que respecta al plan de gestión de administración de la configuración del proyecto

para GM soluciones S.A se usaran las cuatro actividades necesarias para llevar a cabo

estas tareas propias del desarrollo de sistemas únicos. Esto con el fin de evitar que una

persona olvide ciertos cambios que se le hagan al sistema en algún momento

determinado o que se de la perdida de datos ya sea por algún riesgo relacionado con el

proyecto o por perdida de algún miembro del equipo.

Las Actividades de Administración de la configuración se detallan a continuación:

1- Administración del cambio: se empleara esta actividad debido a que la mayoría de

los sistemas de software principalmente los grandes con el paso del tiempo cambian

algunos requerimientos del sistema. Entonces hay que adaptar el sistema al entorno.

Se manejara de la siguiente manera: El cliente va a enviar la solicitud o un reporte de los

cambios que necesita, se reciben los la información enviada, esta es analizada por el

equipo que brinde soporte a los clientes, ellos son los encargados de hacer una

comprobación y de tomar la decisión se realizaran o se descartaran. Si hay que realizar

los cambios solicitados, estos pasan al equipo de Desarrollo de sistemas, empezando con

un análisis de la implementación posible para llenar las necesidades del cliente en este

caso es GM soluciones S.A. Después se realizaría un análisis de costo-beneficio para

nuestra empresa, así como el efecto de realizar dicho cambio, se valora mediante el tipo

de solicitud de cambio y se procede a seleccionar los posibles cambios al sistema.

Después de decidir de hacer los cambios, el grupo de Desarrollo realizara la modificación

del software, ya finalizado la modificación, se inician la etapa de pruebas del software,

para conocer a fondo si los cambios dieron errores o si en realidad produjeron los

resultados esperados por el cliente.

Para toda esta actividad hay un grupo de administración del cambio que es el encargado

realizar lo necesario para dicha administración.

2- Gestión de Versiones: Esta actividad para el proyecto de GM soluciones contara con

tres características esenciales, para hacer el seguimiento de las diferentes versiones de

los componentes del software del sistema.

a) Gestión de Almacenamiento: para reducir espacio de almacenamiento de versiones

nuestra empresa utiliza el sistema una lista con nombres de diferentes versiones de la

más reciente a la otra, esto tiene la funcionalidad de una lista enlazada.

b) Registro del historial de cambios: todos los cambios realizados son registrados y

enumerados. Esto con la finalidad de que algún momento nos ayude a seleccionar una

versión del sistema en particular. Esto se logra dándole palabras claves que describen los

cambios realizados.

c) Soporte del Proyecto: para más fácil del manejo del proyecto y una mejor

administración de las versiones, en casi todas las versiones van a compartir

componentes del sistema como tal. Entonces es posible emplear ciertos métodos de

salida e ingreso de versiones.

3- Construcción del sistema: con lo que respecta la construcción del sistema en este

proyecto se crearan varios ejecutables y compilados varias veces para evitar errores en

los componentes del sistema, librerías, archivos, base de Datos, configuraciones,

hardware, etc.

Esto porque la construcción del sistema implica ensamblar gran cantidad de información y

datos acerca del proyecto, es necesario usar herramientas de construcción para ayudar a

evitar errores de creación.

a) Generación de rutinas de Construcción: para este sistema de GM Soluciones S.A, si es

necesario ya que identicando los componentes se pueden generar estas rutinas

automáticamente tales como archivos de configuración. Ya estando analizado el programa

en construcción se identifican componentes de administración y gestión de datos que se

pueden repetir en varias partes del sistema.

b) Creación de sistema ejecutable: para este sistema es necesario crear varios archivos

ejecutables dentro del código fuente ya que hay varias acciones dentro del, que es

necesaria la creación para ir descartando errores en los archivos específicos que se

ejecutan en ese momento.

c) Informes: en la construcción del sistema es un requisito presentar informes diarios

sobre el éxito o fracaso en las labores realizadas, son obligatorias por parte de todos los

miembros del equipo de desarrollo.

d) Generación de documentación: la documentación de cada línea de código es

obligatoria en el construcción del sistema esto para mejor entendimiento de futuros

desarrolladores, para un cambio solicitado por el cliente en un futuro o por los motivos

propios de los riesgos del proyecto.

4- Gestión de Entregas: para la entrega del sistema de GM soluciones S.A se entregara

directamente a la empresa de manera gratuita, además se entregara debidamente

documentado para garantizarles que se puede recrear con exactitud en el futuro, ya que este

es un sistema de larga duración.

La Entrega Incluye:

a) Archivos de Configuración para instalaciones.

b) Archivos de datos para la operación.

c) Programa de instalación y características del hardware necesario.

d) Documentación digital y escrita del sistema.

Para efectos de este sistema no es necesario contratar empresas de distribución masiva,

pagar publicad, conocimiento sobre las leyes del mercado, etc. Ya que este sistema es solo

para la empresa GM soluciones, no es para varios clientes sino solo uno y directo.
Plantilla de administración de la configuración a utilizar

Petición del Cambio Gestión de Versión Construcción del Sistema Gestión de

Entregas

Proyecto:____________________ 1.Gestión de Generación de rutinas de La Entrega Incluye:

___________________________ Almacenamiento: Construcción:
a)

Solicitante
cambio:_____________________
____________________________

Cambio
Solicitado:___________________
__________________________

Analizador del Cambio:

__________
b)

Facha de Análisis ____________

Creación de sistema
ejecutable:

2. Registro del historial C)

de cambios:

Componentes afectados: _____

D)
Componentes Asociados: ____ Informes:

____________________________ E)

Prioridad del Cambio: _________

____________________________
3. Soporte del Proyecto: Generación de
documentación:

F)
Implementación del cambio:

___________________________

Esfuerzo Estimado: ___________

Fecha de Envió. ______________

Fecha de Cambio ___________

Decisión:___________________

___________________________

Implementador del Cambio:

___________________________
Conclusión

Al concluir el presente trabajo, se queda en evidencias las siguientes concreciones, que van

muy relacionadas al aseguramiento de una entrega de un programa de calidad y a tener

documentado los métodos que se van a utilizar a futuro, para procesos de modificación

posteriores:

 El proceso de pruebas se debe de planear en función a los requerimientos y al tipo de

sistema que se va a entregar, ya que no es lo mismo hacer pruebas para un sistema de

registro de planillas, como hacer pruebas para un sistema de información georeferenciada,

quizás en algunos aspecto converjan, pero en su mayoría su funcionamiento va a variar.

Bibliografía

Sommerville, Ian.E.Ingeniería de Software. Pearson Educación, México, 2011.

Mora Araya, María. Análisis de Sistemas II Guía de estudio.EUNED, Costa Rica 2012

EASY Software & Innovation. Gestión Solicitudes Banco de Los Alpes Plan de Pruebas. EASY
Software & Innovation 2014

Ore B. Alexander. Plan de Pruebas de Software.

http://www.slideshare.net/edgardohrojas/plan-de-pruebas-de-software (14/04/2014)

Loaiza C Vanesa, Zorro J Laura. Plan de Pruebas de Software. Pontificia Universidad

Javeriana.