MEXFAM

CONTROL DE INVENTARIO DE LA CLÍNICA MEXFAM
CARRERA
MATERIA
CATEDRÁTICO
ALUMNOS
SEMESTRE
TRABAJO:
GESTIÓN DE PROYECTOS DE SOFTWARE 1


INTRODUCCIÓN 6
1 DATOS DE LA EMPRESA 7
1.1 DESCRIPCIÓN DEL ÁREA 7
1.2 CROQUIS DE UBICACIÓN 8
1.3 ORGANIGRAMA 9
10
1.4 ÁREAS FUNCIONALES 10
2 DEFINICIÓN DEL PROBLEMA. 11
3 OBJETIVOS 12
3.1 OBJETIVO GENERAL 12
3.2 OBJETIVO ESPECÍFICO 12
4 JUSTIFICACIÓN 13
5 ALCANCES Y LIMITACIONES 14
6 ACTIVIDADES REALIZADAS 15
6.1 CRONOGRAMA 15
6.2 METODOLOGÍA DE DESARROLLO 17
20
6.3 ESTUDIO DE FACTIBILIDAD 20
6.4 REQUERIMIENTOS DEL SISTEMA 22
6.5 GESTIÓN DE RIESGOS 23
6.6 DICCIONARIO DE DATOS 28
7 RESULTADOS 29
7.1 CONCLUSIONES 29
7.2 RECOMENDACIONES 29
7.3 REFERENCIAS 29
30
31
Plan de SQA 31

Versión 1.0 31
Historia de revisiones 31
32
1. Propósito 32
2. Referencias 32
3. Gestión 32
3.1. Organización 32
3.2. Actividades 33
3.2.1. Ciclo de vida del software cubierto por el Plan 33
3.2.2. Actividades de calidad a realizarse 33
3.2.3. Revisar cada producto 34
3.2.4. Revisar el ajuste al proceso 34
3.2.5. Realizar Revisión Técnica Formal (RTF) 34
3.2.6. Asegurar que las desviaciones son documentadas 35
3.2.7. Relaciones entre las actividades de SQA y la planificación 35
3.3. Responsables 36
4. Documentación 36
4.1. Propósito 36
4.2. Documentación mínima requerida 36
4.2.1. Especificación de requerimientos del software 36
4.2.2. Descripción del diseño del software 38
4.2.3. Plan de Verificación & Validación 39
4.2.4. Reportes de Verificación & Validación 39
4.2.5. Documentación de usuario 39
4.2.6. Plan de Gestión de configuración 39
4.3. Otros documentos 39

5. Estándares, prácticas, convenciones y métricas 40
5.1. Estándar de documentación 40
5.1.1. Estándar de documentación técnica e implementación 40
5.1.2. Estándar de documentación de usuario 41
6. Revisiones y auditorías 41
6.1. Objetivo 41
6.2. Requerimientos mínimos 41
6.2.1. Revisión de requerimientos 41
6.2.2. Revisión de diseño preliminar 41
6.2.3. Revisión de diseño crítico 41
6.2.4. Revisión del Plan de Verificación & Validación 41
6.2.5. Auditoría funcional 41

6.2.6. Auditoría física 42

6.2.7. Auditorías internas al proceso 42
6.2.8. Revisiones de gestión 42
6.2.9. Revisión del Plan de gestión de configuración 42
6.2.10. Revisión Post Mortem 42
6.2.11. Agenda 42
6.3. Otras revisiones 43

6.3.1. Revisión de documentación de usuario 43
CONTRATO 44
HERRAMIENTAS PARA LA ADMINISTRACION Y ASEGURAMIENTO DEL
PROYECTO 49
50

INTRODUCCIÓN
La ingeniería en software es una ciencia encargada del desarrollo de productos de soporte lógico,
es decir, se ocupa de todas las actividades técnicas y de gestión necesaria para crear un producto
(programa informático).
Cada programa que se realiza se crea a través de un proceso de desarrollo de software y se divide
en cinco modelos principales, el primero es referente al modelo de requisitos, donde se delimita el
sistema y captura la funcionalidad que ofrecerá este al usuario; el segundo es el modelo de análisis,
cuyo objetivo es comprender y generar una arquitectura de objetos para el sistema que se desea
crear; el tercero es el modelo de diseño, que se basa en las especificaciones de todos los objetos,
incluyendo sus operaciones y atributos; el cuarto es el modelo de implementación, aquí ya se genera
el código final y por último tenemos al modelo de pruebas
}, que en él se garantiza que el producto de software funcione como se desea y se revisa a

profundidad todo el sistema.

1 DATOS DE LA EMPRESA
1.1 DESCRIPCIÓN DEL ÁREA
La clínica “Mexfam” se fundó en el año 1993 por el ciudadano Roberto Barrón Valencia.
Mexfam es una organización de la sociedad civil que promueve el desarrollo social y el bienestar de
las personas a través del ejercicio libre e informado de sus derechos, particularmente sexuales y
reproductivos, contribuyendo así a la disminución de las inequidades en los grupos vulnerables de
la sociedad.
Atiende las 24 horas y se está ubicada en calle Independencia entre Narciso Mendoza y María
Boettiger, Catemaco, Veracruz.

1.2 CROQUIS DE UBICACIÓN

1.3 ORGANIGRAMA
DIRECCIÓN GENERAL
Roberto Barrón Valencia
ÁREA MÉDICA ÁREA ADMINISTRATIVA

Carlos Lara Jerezano Roberto Barrón Torres
MÉDICOS
Epigmenio LABORATORIO CONTADOR PERSONAL DE
Enójoso Tania Mujica CAJA
Juan Torres
Cortes Hernández Durán Roberto Barrón
Patricio Torres
Chontal RECEPCIÓN
ÁNgelica Barrón
ENFERMERAS Torres MANTENIMIENTO
María Elena Quinto María Taxilaga
Torres Alejandra Coachin

1.4 ÁREAS FUNCIONALES

2 DEFINICIÓN DEL PROBLEMA.
El personal de la clínica particular MEXFAM ubicada en Catemaco, Veracruz, lleva a cabo el manejo
de control de ventas de días laborales en donde el personal tiene que escribir con números
consecutivos las ventas ingresada en el lapso del día.
Estas actividades metódicas y manuales producen el retraso en la entrega de los medicamentos a

los pacientes, así mismo existe una pérdida de tiempo en la inscripción de personas no afiliadas y/o
búsqueda de los pacientes ya asentados en los libros de registro.
Cabe mencionar que se necesita hacer un control de inventario con referencia a los medicamentos
que se adquieren y venden en dicha clínica. Es importante destacar que estos productos son básicos
en el mercado por subsecuente siempre hay en existencia en el inventario de la clínica.

3 OBJETIVOS
3.1 OBJETIVO GENERAL
Desarrollar un sistema de control de inventario de medicamentos en la clínica MEXFAM del

municipio de Catemaco, Veracruz
3.2 OBJETIVO ESPECÍFICO
 Realizar un análisis del proceso de control del manejo de inventario en la clínica

MEXFAM del municipio de Catemaco, Veracruz.
 Analizar los requisitos necesarios para el sistema, por medio de las técnicas de
recolección de información.
 Diseñar la estructura de base de datos.
 Desarrollar el sistema buscando cubrir todos los requisitos necesarios.
 Aplicar pruebas para corregir los errores que se pudieran presentar.
 Implementar el sistema para el uso requerido.
 Elaborar la documentación e informe de la aplicación.

4 JUSTIFICACIÓN
La clínica MEXFAM quiere darle a su cliente un mejor servicio con calidad, precisión y confianza
buscando la automatización con las nuevas tecnologías del siglo XXI.
El sistema planteado busca crear una automatización del proceso de las ventas del día
proporcionando mayor confiabilidad, control y seguridad del manejo de datos de los clientes y las
ventas ingresadas, así como el control del historial de las ventas. Llevando así al paciente a una
experiencia de compra en la que podrá conocer la comodidad y calidez que ofrecen los servicios en
la clínica.
Este sistema beneficia tanto al personal de la clínica como a los pacientes: primero se tiene mayor
optimización del tiempo en las tareas que ejecuta el personal de la clínica en la exploración de los
registros de los pacientes y los inventarios de los medicamentos, en estos últimos se incrementaran
su eficiencia y eficacia para no halla perdidas de clientes al no haber productos en existencia lo que
ocasionaría a su vez que el paciente cambie de clínica; segundo, los pacientes con entrada de
urgencias van a recibir un trato ágil en la tramitología de su inscripción y en el tratamiento médico
correspondiente a su padecimiento.
Los beneficios para clínica son el reconocimiento por parte de los pacientes que obtendrán un
servicio de calidad y con ello aumenta el prestigio empresa proporcionando mayores ingresos.

5 ALCANCES Y LIMITACIONES
Alcances
 Se reducirá el tiempo en el proceso de control de medicamentos.
 Llevará un control de dicho proceso.
 El sistema verificará el stock de medicamentos.
 Registrará la solicitud de cobro y entrega de medicamentos.
Limitaciones
 La compra del hardware necesario para la implementación del sistema lo obtendrá la

empresa.
 El sistema se limitará a la clínica “Mexfam” ubicada en Catemaco, Veracruz.
 El sistema solo llevará a cabo el control de farmacia.
 No todo el personal podrá acceder a todos los módulos que contendrá el sistema, solo el personal de
caja encargado de dicho proceso tendrá todos los privilegios.

6 ACTIVIDADES REALIZADAS
6.1 CRONOGRAMA
A continuación, se detalla en la tabla cada una de las actividades programadas para llevar a cabo
el proyecto de software, asi como la dependencia y la duración de cada una de ellas.
DEPENDENCIA
ID ACTIVIDAD DURACIÓN
ANÁLISIS DEL PROBLEMA
01 Descripción de la necesidad 2 DIAS
02 Identificación de requerimientos 01 2 DIAS
03 Clasificación de requerimientos 02 2 DIAS
PLANEACIÓN
04 Estimación de costos 03 2 DIAS
05 Estimación de tiempo 03 2 DIAS
06 Estudio de factibilidad 04,05 2 DIAS
07 Estudio de riesgos 04,05,06 2 DIAS
MODELADO
08 Selección de la metodología 07 2 DIAS
09 Descripción de módulos 08 2 DIAS
10 Contenido 08, 09 2 DIAS
CONSTRUCCION DEL SISTEMA
11 Programación de módulos 10 5 DIAS
12 Integración de contenidos 11 3 DIAS
13 Diseño del sistema 11,12 8 DIAS
14 Integración de módulos 13 3 DIAS
Vinculación del sistema con la
15 14 2 DIAS
base de datos
PRUEBAS
16 Registro de pruebas 13, 14 2 DIAS
17 Resultado de pruebas 16 2 DIAS
18 Errores 17 1 DIA
19 Nuevas pruebas de errores 18 3 DIAS

RECURSOS
En la siguiente tabla se muestra los recursos a utilizar durante el desarrollo del proyecto.
ROL RECURSO PARTICIPACIÓN
 Jefe de proyecto Diana Sarahí Ramírez Vichi 01,
 Decodificadora 08,09,10,11,12,13,14,1516,17,18,19
 Diseño
 Pruebas
 Analista Cecilia Bautista Morales 01,02,03,04,05,06,07,08,09,10
 Jefe de información
ESTIMACIÓN DE TIEMPO
 DIAGRAMA DE GANTT

 DIAGRAMA DE PERT
Describe cada una de las actividades realizadas durante el proyecto.
6.2 METODOLOGÍA DE DESARROLLO
Para la construcción del sistema de control de inventario se toma de referencia el modelo del proceso
evolutivo en forma de espiral, debido a que dicha metodología se caracteriza por la manera en la
que permite desarrollar versiones cada vez mas completas del software, además de que este modelo
permite adaptarse para aplicarlo de la vida del software de computo.

DESCRIPCIÓN DE LAS ACTIVIDADES A REALIZAR
COMUNICACIÓN
En esta fase se llevará a cabo el análisis del negocio, en esta se define el contexto
de los posibles cambios que pueden surgir en el ambiente y se definirán los
requisitos del negocio.
También se identificarán las necesidades, se describirán los objetivos a desarrollar
y se realizara la recopilación de los requisitos que conducirán al desarrollo del
sistema.
PLANIFICACIÓN
Mediante esta fase se tomarán en cuenta los posibles riesgos y que puedan surgir
durante el desarrollo del sistema, además de las medidas control para evitar dichos
riesgos.
También se definirán las tareas que se realizarán durante el desarrollo del sistema
y los encargados de cada una de esas actividades.
Se realizará la estimación del tiempo proyectado para la construcción del sistemay
se construirá un calendario de actividades a realizar durante este periodo.
MODELADO
Se llevará acabo el modelo de análisis y el modelo de diseño.
 Modelo de análisis:
Se identifican actores y caso de uso del sistema a desarrollar y se construirá el
modelo de caso de usos. También se llevará acabo el análisis del contenido que
ofrecerá el sistema. Posteriormente se procederá a realizar el análisis de
funciones.
 Modelo de diseño:
Mediante este modelo se realizará el diseño de la interfaz, la descripción de los
módulos a desarrollar y el contenido que llevará el sistema-

CONSTRUCCIÓN DEL SISTEMA

En esta fase se realizará la codificación del sistema de control de inventario
considerando lo especificado en el modelo de diseño, también se realizara el diseño
de un plan de pruebas.
DESPLIEGUE
Esta última fase se conoce como fase de entrega y documentación, aquí se realizara
las pruebas de aceptación a partir del uso que el usuario de al sistema y a partir de
ello se hará la evaluación final del usuario.

6.3 ESTUDIO DE FACTIBILIDAD
A continuación, se presenta el estudio de factibilidad realizado para el sistema de control de

inventario de la clínica MEXFAM, el cual permitirá conocer y determinar cada una de sus
dimensiones.
 FACTIBILIDAD OPERACIONAL
El sistema será desarrollado de manera a que el operador acceda al sistema de manera
práctica y realice las consultas de forma rápida y segura.
 FACTIBILIDAD TÉCNICA
Actualmente el equipo de trabajo cuenta con dos equipos de cómputo, destinados al
desarrollo del sistema de control de inventario.
EQUIPO #1 EQUIPO #2
MARCA SAMSUNG HP
MODELO Mini laptop Samsung NC110 Notebook HP 15-AW003LA
A01MX
SISTEMA OPERATIVO Windows Starter 7 , 32 bits Windows 10, 64 bits
PROCESADOR Intel®Atom™ CPU N455 AMD A0.
@1.66GHz 1.67GHz
DISCO DURO 320 GB A 7200 rmp 1 TB
RAM 2 GB 12 GB
PANTALLA 10.1” LED 15.6” HD
SOFTWARE CARACTERISTICAS
Paquetería que permite crear, editar y modificar

Microsoft office 2016
archivos de textos y tablas.
Google Chrome, Internet
Navegadores
Explorer
Adobe acrobat reader Visualizador de archivos PDF
Lenguaje de programación destinado para desarrollo
NetBeans IDE 8.0.2
, diseño y edición de programas.

REQUERIMIENTOS MINIMOS
SISTEMA OPERATIVO Windows XP
PROCESADOR Intel Pentium
DISCO DURO 5 GB
RAM 2 GB
REQUERIMIENTOS RECOMENDADOS
SISTEMA OPERATIVO Windows 10

PROCESADOR AMD A9
DISCO DURO 1 TB
RAM 4 GB
 FACTIBILIDAD FINACIERA
Se determina costos de los materiales y recursos utilizados para la creación

del sistema.
CANTIDAD DESCRIPCIÓN COSTO

1 Renta $ 1500
1 Pago de luz eléctrica $ 350
1 Papelería $ 500
2 Depreciación del equipo $ 400
2 Biáticos $ 960
2 Pago al personal $ 8500
TOTAL ($ 12,210)

6.4 REQUERIMIENTOS DEL SISTEMA
REQUERIMIENTOS FUNCIONALES
 El sistema debe permitir el control de venta.
 El sistema debe de actualizar la base de datos de las ventas, clientes, medicamentos,
inventario y detectar errores en el sistema.
 El sistema realizara consultas de información.
 Es sistema será capaz de imprimir la información adquirida.

REQUERIMIENTOS DEL PRODUCTO NO FUNCIONALES.
 El sistema será programado
 El sistema debe de visualizarse y funcionar correctamente con el tipo de sistema operativo
que se vaya a utilizar.
 El mantenimiento constante del sistema.
 La extensibilidad en la base de datos
 Solo tendrá acceso el encargado de manejar estas actividades de la empresa.
 Copia de seguridad.

6.5 GESTIÓN DE RIESGOS
El Plan de Riesgos establece las posibles situaciones en las que el proyecto podría verse afectado.
Para ello, se realiza un Análisis de Riesgos, a través de la cual se establecerán las acciones a tomar
en caso que se concreten dichas situaciones. Básicamente, el Plan de Riesgos debe contemplar la:
definición de los riesgos, la posibilidad de que se concrete cada uno de los riesgos detectados, definir
que tan grande sería el impacto de cada riesgo identificado en el proyecto, definir e indicar cuales
son los eventos indicadores de que el riesgo se ha concretado, y definir el plan de contingencia para
cada uno de ellos
ROLES Y RESPONSABILIDADES
ROL RESPONSABILIADES
Asignar actividades.
JEFE DE PROYECTO Liderar y supervisar la fase del desarrollo del proyecto.
Evaluar y controlar el equipo del proyecto.
Dirigir y coordinar todos los recursos empleados.
Etapa de análisis y formulación.

JEFE DE INFORMACIÓN Aplicar los requerimientos del proyecto.
Modelado de negocio.
Plan de pruebas.
JEFE DE PRUEBAS Informe de pruebas.
Informar errores del sistema.
Análisis de requerimientos.
Identificar módulos a implementar en el sistema.
ANALISTA Estimación.
Estudio de factibilidad.
Riesgos del proyecto.
Diseñar y estructurar el contenido del sistema

ENCARGADO DE DISEÑO
Estructurar los módulos
CODIFICADOR Codificar el sistema

TIPOS DE RIESGOS
RIESGO DESCRIPCIÓN PROBLEMA
Presupuesto
Amenazan el plan del Planeación temporal
proyecto, si se presenta Recursos
DEL PROYECTO
retrasa la planeación y Clientes
aumenta los costos. Requisitos
Diseño
Amenaza la calidad y Implementación
TÉCNICOS planeación temporal, la Interface
implementación puede ser Verificación
difícil si este riesgo se presenta Mantenimiento
Producto que nadie

quiera y no encaje en
la estrategia
Amenaza la viabilidad del
comercial.
software a construir. Pone en
DEL NEGOCIO Producto poco
peligro el proyecto y el
amigable.
producto.
Perdida de
presupuesto personal
asignado.

ID
RIESGO DESCRIPCIÓN TIPO DE RIESGO
RIESGO
Rotación de Personal con experiencia abandona Proyecto, producto y
R-01
personal el proyecto antes de que finalice negocio
El proyecto es demasiado grande
Personal
R-02 para la cantidad de personas que Proyecto
insuficiente
están a cargo de su desarrollo
Ausencia del personal por
Ausencia del enfermedad, accidente, muerte o
R-03 Proyecto y negocio
personal simplemente deciden retirarse del
proyecto.
Los procesos que se siguen para el
Seguimiento desarrollo del sistema no se llevan a
R-04 inadecuado de los cabo de manera adecuada debido a Proyecto y técnico
procesos la falla de compromiso o experiencia
del personal a cargo
No se hace la detección y corrección
Manejo inapropiado de errores en la programación
R-05 Proyecto y técnico
de errores documentación del sistema de
manera oportuna.
Toda la información elaborada
Perdida de
R-06 durante el proyecto se estravia , borra Proyecto
documentación
o pierde.
Equipo de cómputo
R-07 El equipo sufre daños graves Proyecto
dañado
Accidente en el Corto eléctrico de las instalaciones o
R-08 Negocio
área de trabajo algún desastre natural.
Se proponen nuevos cambios en los
Cambio de
R-09 requerimientos y se debe hacer Técnico
requerimientos
cambios en el diseño y contenido.
Recursos Los costos de producción son
R-10 económicos demasiado elevados y sobrepasan el Proyecto
insuficientes presupuesto estimado.
El equipo responsable no cuenta con
Inexperiencia con
R-11 conocimientos tecnológicos o el Técnico
la tecnología
proyecto es demasiado complejo.
Incompatibilidad de El sistema no es compatible con el
R-12 Técnico
operaciones equipo.
Inestabilidad del El sistema tiene problemas de
R-13 Técnico y negocio
producto final rendimiento y mantenibilidad
El sistema no
El sistema no satisface las
R-14 cumple con las Negocio
necesidades prevista.
expectativas
Mala comunicación
R-15 No se llega a un buen acuerdo Negocio
con el cliente

ID RESPONSABL
RIESGO CONSECUENCIA EFECTO
RIESGO E
Miembros del equipo no
Rotación de disponibles en momentos Retraso en las
R-01 jefe de proyecto
personal críticos actividades
Personal con experiencia

Personal Jefe de abandona el proyecto Mayor duración
R-02
insuficiente proyecto antes de que finalice del proyecto
La ausencia del personal Retraso con la

Ausencia del Jefe de
R-03 retrasa las actividades del fecha de entrega
personal proyecto
proyecto. del proyecto
Las actividades del
Seguimiento
Jefe de proceso de desarrollo no No se cumple los
R-04 inadecuado de
proyecto se realizan objetivos
los procesos
adecuadamente

Manejo No se detectan y corrigen El sistema no

Jefe de pruebas
R-05 inapropiado de los errores de funciona
y codificador
errores codificación. correctamente
Inapropiada protección de Afecta
Perdida de Jefe de
R-06 la información y los drásticamente al
documentación proyecto
respaldos existentes. proyecto
Mal manejo y descuido de Retraso y
Equipo de
Jefe de las herramientas de elevación de
R-07 cómputo
proyecto trabajo por parte del costos del
dañado
personal proyecto
No se contemplan los
cambios climatológicos,
Daño a las
Accidente en el desastres naturales u otro
R-08 herramientas de
área de trabajo accidentes que pudiesen
trabajo
afectar el entorno donde
se desarrolla el problema.
No se realiza un análisis Mayor tiempo en
Cambio de
R-09 Analista detallado contemplando la realización dl
requerimientos
la información. proyecto
Recursos No disponer de recurso
Jefe de Retraso en el
R-10 económicos para el desarrollo del
proyecto proyecto
insuficientes sistema
La fecha de
Inexperiencia Diseñador, entrega se
El proyecto es complejo y
R-11 con la Analista y retrasa debido a
difícil de entender
tecnología Codificador la complejidad
del proyecto
La plataforma no es
Incompatibilidad Codificador,Jefe Reestructuración
R-12 compatible con el equipo
de operaciones de pruebas del sistema
que se cuenta
Inestabilidad del No se toman en cuenta Reestructuración
R-13 Jefe de pruebas
producto final las pruebas necesarias del sistema
El sistema no Jefe de
Cliente inconforme con lo
R-14 cumple con las información y Mala aceptación
que se desarrollo
expectativas analista
Mala No se toman llega a un
Jefe de
R-15 comunicación acuerdo de lo que Mala aceptación
proyecto
con el cliente requieren

6.6 DICCIONARIO DE DATOS
Para lograr un mejor entendimiento de los términos técnicos que se utilizan en el Plan de SQA, se
mencionan a continuación los significados de los siguientes términos:
 Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar a la

administración una visibilidad adecuada del proceso utilizado y los productos construidos
mediante acciones planificadas y sistemáticas que aseguren la calidad de dichos procesos y
productos.
 Auditoría  Evaluación independiente de los productos de trabajo y de un conjunto de procesos
de software para asegurar la adherencia con las especificaciones, los estándares,
procedimientos y otros acuerdos.
 Gestión de la Configuración del Software (SCM) El propósito de SCM es establecer y
mantener la integridad de los productos a través de todo el ciclo de vida del software, para así
proveer un adecuado control de los cambios en los diversos ítems de configuración.
 Revisión  Metodología definida, estructurada y disciplinada para la detección e identificación
de defectos en los productos de trabajo durante el ciclo de vida del software.
 Prueba (Testing)  Actividad que evalúa los atributos y la capacidad de un programa o sistema
para determinar si se cumple con los resultados definidos.

7 RESULTADOS
7.1 CONCLUSIONES
7.2 RECOMENDACIONES
7.3 REFERENCIAS


Plan de SQA
Versión 1.0
Historia de revisiones
Fecha Versión Descripción Autor

1.0  Diana Sarahí
Ramírez Vichi
 Cecilia Bautista
Morales

1. Propósito
El propósito de Plan de Calidad consiste en especificar las pautas a seguir
durante el proceso de desarrollo para poder asegurar la calidad del mismo y
del producto a construir, detallando todo lo referente a la planificación del
seguimiento de la calidad en el proyecto, indicando para cada actividad, los
atributos de calidad relevantes, los métodos de evaluación de calidad, en que
momento se realizarán dichos métodos y los responsables, centrándose en el
producto mas allá del proceso.
2. Referencias
ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance
Plans.
S. Pressman, R. (2010) Ingeniería Del Software Un Enfoque Practico, 7ª.
Edición.
3. Gestión
La organización de las actividades y los responsables asociados (para la
primera fase), se encuentran en el correspondiente documento de “Plan de la
iteración”. Allí se detallan todas las responsabilidades de cada integrante del
staff.
3.1. Organización
El encargado de SQA es el responsable de asegurar la calidad sobre los
productos, pero es de importancia que cada integrante del grupo adopte un
comportamiento responsable, y consiente acerca de decisiones tomadas que
puedan en un futuro estropear la calidad del producto.
ROL RESPONSABILIADES
Asignar actividades.
JEFE DE PROYECTO Liderar y supervisar la fase del desarrollo del proyecto.
Etapa de análisis y formulación.

JEFE DE INFORMACIÓN Aplicar los requerimientos del proyecto.
Plan de pruebas.
JEFE DE PRUEBAS Informe de pruebas.
ANALISTA Análisis de requerimientos.


Estimación.
Diseñar y estructurar el contenido del sistema

ENCARGADO DE DISEÑO
Estructurar la tabla de referencia entre los elementos que integran la organización
ROL RECURSO
 Jefe de proyecto Diana Sarahí Ramírez Vichi
 Decodificadora
 Diseño
 Pruebas
 Analista Cecilia Bautista Morales
 Jefe de información
3.2. Actividades
3.2.1. Ciclo de vida del software cubierto por el Plan
El plan cubre el ciclo de vida del software, las fases de evaluación, elaboración,
construcción y transición. Las tareas a ser llevadas a cabo deberán reflejar las
evaluaciones a realizar, los estándares a seguir, los productos a revisar, los
procedimientos a seguir en la elaboración de los distintos productos y los
procedimientos para informar de los defectos detectados a sus responsables
y realizar el seguimiento de los mismos hasta su corrección.
3.2.2. Actividades de calidad a realizarse

Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar,
los estándares a seguir, los productos a revisar, los procedimientos a seguir
en la elaboración de los distintos productos y los procedimientos para informar
de los defectos detectados a sus responsables y realizar el seguimiento de los
mismos hasta su corrección.
Las actividades que se realizarán son:

 Revisar cada producto
 Revisar el ajuste al proceso
 Realizar Revisión Técnica Formal
 Asegurar que las desviaciones son documentadas.

3.2.3. Revisar cada producto

En esta actividad se revisan los productos que se definieron como claves para
verificar en el Plan de calidad.
Se debe verificar que no queden correcciones sin resolver en los informes de
revisión previos, si se encuentra alguna no resuelta, debe ser incluida en la
siguiente revisión. Se revisan los productos contra los estándares, utilizando
la checklist definida para el producto.
Se debe identificar, documentar y seguir la pista a las desviaciones
encontradas y verificar que se hayan realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, este informe debe ser
distribuido a los responsables del producto y se debe asegurar de que son
conscientes de desviaciones o discrepancias encontradas.
3.2.4. Revisar el ajuste al proceso
En esta actividad se revisan los productos que se definieron como claves para
verificar el cumplimiento de las actividades definidas en el proceso. Con el fin
de asegurar la calidad en el producto final del desarrollo, se deben llevar a
cabo revisiones sobre los productos durante todo el ciclo de vida del software.
Se debe recoger la información necesaria de cada producto, buscando hacia
atrás los productos previos que deberían haberse generado, para poder
establecer los criterios de revisión y evaluar si el producto cumple con las
especificaciones.
Esta información se obtiene de los siguientes documentos:
Plan del Proyecto, Plan de la iteración, Plan de Verificación.
Antes de comenzar, se debe verificar en los informes de revisión previos que
todas las desviaciones fueron corregidas, si no es así, las faltantes se incluyen
para ser evaluadas.
Como salida se obtiene el Informe de revisión de SQA correspondiente a la
evaluación de ajuste al Proceso, este informe debe ser distribuido a los
responsables de las actividades y se debe asegurar de que son conscientes
de desviaciones o discrepancias encontradas.
3.2.5. Realizar Revisión Técnica Formal (RTF)
El objetivo de la RTF es descubrir errores en la función, la lógica ó la
implementación de cualquier producto del software, verificar que satisface sus
especificaciones, que se ajusta a los estándares establecidos, señalando las
posibles desviaciones detectadas. Es un proceso de revisión riguroso, su
objetivo es llegar a detectar lo antes posible, los posibles defectos o
desviaciones en los productos que se van generando a lo largo del desarrollo.
Por esta característica se adopta esta práctica para productos que son de
especial importancia.
En la reunión participan el responsable de SQA e integrantes del equipo de
desarrollo.

Se debe convocar a la reunión formalmente a los involucrados, informar del

material que ellos deben preparar por adelantado, llevar una lista de preguntas
y dudas que surgen del estudio del producto a ser revisado.
La duración de la reunión no debe ser mayor a dos horas.
Como salida se obtiene el Informe de RTF.
3.2.6. Asegurar que las desviaciones son documentadas
Las desviaciones encontradas en las actividades y en los productos deben ser
documentadas y ser manejadas de acuerdo a un procedimiento establecido.
Se debe chequear que los responsables de cada plan los modifiquen cada vez
que sea necesario, basados en las desviaciones encontradas.
3.2.7. Relaciones entre las actividades de SQA y la planificación
Esta planificación es estimada, y se ajustará posteriormente en los posteriores

planes de cada iteración.
ID ACTIVIDAD DURACIÓN
01 Descripción de la necesidad 2 DIAS
02 Identificación de requerimientos 2 DIAS
03 Clasificación de requerimientos 2 DIAS
04 Estimación de costos 2 DIAS
05 Estimación de tiempo 2 DIAS
06 Estudio de factibilidad 2 DIAS
07 Estudio de riesgos 2 DIAS
08 Selección de la metodología 2 DIAS
09 Descripción de módulos 2 DIAS
10 Contenido 2 DIAS
11 Programación de módulos 5 DIAS
12 Integración de contenidos 3 DIAS
13 Diseño del sistema 8 DIAS
14 Integración de módulos 3 DIAS
Vinculación del sistema con la
15 2 DIAS
base de datos
16 Registro de pruebas 2 DIAS
17 Resultado de pruebas 2 DIAS
18 Errores 1 DIA
19 Nuevas pruebas de errores 3 DIAS

3.3. Responsables
ROL
RESPONSABILIADES
JEFE DE PROYECTO Asignar actividades.
Liderar y supervisar la fase del desarrollo del proyecto.

JEFE DE INFORMACIÓN Etapa de análisis y formulación.

Aplicar los requerimientos del proyecto.
JEFE DE PRUEBAS Plan de pruebas.

Informe de pruebas.
ANALISTA Análisis de requerimientos.

Estimación.
ENCARGADO DE DISEÑO Diseñar y estructurar el contenido del sistema

4. Documentación
4.1. Propósito
Identificación de la documentación relativa a desarrollo, Verificación y
Validación, uso y mantenimiento del software.
Establecer como los documentos van a ser revisados para chequear
consistencia: se confirman criterio e identificación de las revisiones.
4.2. Documentación mínima requerida
La documentación mínima es la requerida para asegurar que la
implementación logrará satisfacer los requerimientos.
4.2.1. Especificación de requerimientos del software
El documento de especificación de requerimientos deberá describir, de forma
clara y precisa, cada uno de los requerimientos esenciales del software
además de las interfaces externas.

El cliente deberá obtener como resultado del proyecto una especificación

adecuada a sus necesidades en el área de alcance del proyecto, de acuerdo
al compromiso inicial del trabajo y a los cambios que este haya sufrido a lo
largo del proyecto, que cubra aquellos aspectos que se haya acordado detallar
con el cliente.
La especificación debe:
 Ser completa :
a. Externa, respecto al alcance acordado.
b. Internamente, no deben existir elementos sin especificar.
 Ser consistente, no pueden haber elementos contradictorios.
 Ser no ambigua, todo término referido al área de aplicación debe
estar definido en un glosario.
 Ser verificable, debe ser posible verificar siguiendo un método
definido, si el producto final cumple o no con cada requerimiento.
 Estar acompañada de un detalle de los procedimientos adecuados
para verificar si el producto cumple o no con los requerimientos.
 Incluir requerimientos de calidad del producto a construir.
Los requerimientos de calidad del producto a construir son considerados

dentro de atributos específicos del software que tienen incidencia sobre la
calidad en el uso’ y se detallan a continuación:
Funcionalidad
a. adecuación a las necesidades
b. precisión de los resultados
c. interoperabilidad
d. seguridad de los datos
Confiabilidad
a. madurez
b. tolerancia a faltas
c. recuperabilidad
Usabilidad
a. comprensible
b. aprendible
c. operable
d. atractivo

Eficiencia
a. comportamiento respecto al tiempo (Ver si aplica)
b. utilización de recursos
Mantenibilidad
a. analizable
b. modificable
c. estable, no se producen efectos inesperados luego de modificaciones
d. verificable
Portabilidad
a. adaptable (Ver si aplica)
b. instalable
c. co-existencia
d. reemplazante (Ver si aplica)
Cada uno de estos atributos debe cumplir con las normas y regulaciones
aplicables a cada uno.
4.2.2. Descripción del diseño del software
El documento de diseño especifica como el software será construido para
satisfacer los requerimientos.
Deberá describir los componentes y subcomponentes del diseño del software,
incluyendo interfaces internas. Este documento deberá ser elaborado primero
como Preliminar y luego será gradualmente extendido hasta llegar a obtener
el Detallado.
El cliente deberá obtener como resultado del proyecto el diseño de un producto

de software que cubra aquellos aspectos que se haya acordado con el cliente
incorporar al diseño, en función de la importancia que estos presenten y de
sus conexiones lógicas.
El diseño debe:
 Corresponder a los requerimientos a incorporar:
a. Todo elemento del diseño debe contribuir a algún requerimiento
b. La implementación de todo requerimiento a incorporar debe estar
contemplada en por lo menos un elemento del diseño.
 Ser consistente con la calidad del producto

4.2.3. Plan de Verificación & Validación

El Plan de V & V deberá identificar y describir los métodos a ser utilizados en:
 La verificación de que:
a. los requerimientos descritos en el documento de requerimientos
han sido aprobados por una autoridad apropiada. En este caso
sería que cumplan con el acuerdo logrado entre el cliente y el
equipo.
b. los requerimientos descritos en el documento de requerimientos
son implementados en el diseño expresado en el documento de
diseño.
c. el diseño expresado en el documento de diseño esta
implementado en código.
 Validar que el código, cuando es ejecutado, se adecua a los
requerimientos expresados en el documento de requerimientos.
4.2.4. Reportes de Verificación & Validación
Estos documentos deben especificar los resultados de la ejecución de los
procesos descritos en el Plan de V & V.
4.2.5. Documentación de usuario
La documentación de usuario debe especificar y describir los datos y entradas
de control requeridos, así como la secuencia de entradas, opciones,
limitaciones de programa y otros elementos necesarios para la ejecución
exitosa del software.
Todos los errores deben ser identificados y las acciones correctivas descritas.
Como resultado del proyecto el cliente obtendrá una documentación para el
usuario de acuerdo a los requerimientos específicos del proyecto.
4.2.6. Plan de Gestión de configuración
El Plan de gestión de configuración debe contener métodos para identificar
componentes de software, control e implementación de cambios, y registro y
reporte del estado de los cambios implementados.
4.3. Otros documentos
El plan de proyecto debe contener la planificación de las actividades a
realizarse durante el proceso de desarrollo. Debe estimar el esfuerzo
necesario para la realización del producto de forma de asegurar el nivel de
calidad esperado. Debe especificar las responsabilidades de los integrantes
del equipo de desarrollo así como el tiempo de dedicación requerido en cada
una de las actividades asignadas. Se debe definir en este documento el
alcance del proyecto y las limitaciones del mismo, especificando que tareas se

realizaran y cuales no. Debe brindar una descripción general del proceso de
desarrollo y como serán implementadas las etapas del mismo.
Incluirá una estimación inicial de la agenda y una explicación del procedimiento
a seguir para ajustarla. El Plan debe especificar los entregables requeridos en
cada etapa y la prioridad de los mismos, de forma de asignar más esfuerzo a
hitos más importantes para la calidad del producto.
Debe especificarse en el mismo las pautas a seguir en la actividad de ajuste
del Plan, que variables serán analizadas y en que medida se cuantificara cada
una. Es responsabilidad de los integrantes del equipo de SQA brindar apoyo
en las cuantificaciones de calidad y esfuerzo.
5. Estándares, prácticas, convenciones y métricas
5.1. Estándar de documentación

Como estándares de documentación se definirán dos documentos:
 Estándar de documentación técnica y
 Estándar de documentación de usuario.
La documentación técnica del producto debe:

 Ser adecuada para que un grupo independiente del de desarrollo
pueda encarar el mantenimiento del producto.
 Incluir fuentes, Modelos de Casos de Uso, Objetos
Para la escritura de documentos se han definido plantillas para ser utilizadas

en la elaboración de entregables.
En estas plantillas se definen:
 encabezado y pie de página.
 fuente y tamaño de fuente para estilo normal
 fuente y tamaño de fuente para los títulos a utilizar
 datos mínimos que se deben incluir: fecha, versión y responsables.
La responsabilidad de apegarse a los estándares definidos es del encargado

del entregable, definido en el plan de iteración, el cual es resultado en primera
instancia por la reunión quincenal del grupo, ajustado luego de la reunión de
responsables por área, y finalmente definida por el administrador del equipo.
El equipo de SQA revisará el cumplimento de éstos estándares y reportará
eventuales defectos a los correspondientes responsables, auditando y
formando el ciclo de defectos a definido en la sección 9.
5.1.1. Estándar de documentación técnica e implementación
La misma debe:

 Ser adecuada para que un grupo independiente del de desarrollo

pueda encarar el mantenimiento del producto. Esto es importantísimo
del punto de vista del actual cliente.
 Incluir fuentes, Modelos de Casos de Uso, Objetos
Referirse al documento “Estándar de Doc. Técnica e Implementación”

5.1.2. Estándar de documentación de usuario
Existe un documento para éste propósito, referirse a IPEDUGXvY.doc.
Se utilizan las prácticas definidas en el Plan de Verificación y Validación.
Como estándar se utiliza el documento de:
Std 1012-1986 IEEE Standard for Software Verification and Validation Plans.
.
6. Revisiones y auditorías
6.1. Objetivo
Definición de las revisiones y auditorías técnicas y de gestión que se
realizarán.
Especificación de cómo serán llevadas a cabo dichas revisiones y auditorías.
6.2. Requerimientos mínimos

6.2.1. Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los requerimientos
especificados por el Cliente.
6.2.2. Revisión de diseño preliminar
Esta revisión se realiza para asegurar la consistencia y suficiencia técnica del
diseño preliminar del software.
6.2.3. Revisión de diseño crítico
Esta revisión se realiza para asegurar la consistencia del diseño detallado con
la especificación de requerimientos.
6.2.4. Revisión del Plan de Verificación & Validación
Esta revisión se realiza para asegurar la consistencia y completitud de los
métodos especificados en el Plan de V & V.
6.2.5. Auditoría funcional
Esta auditoría se realiza previa a la liberación del software, para verificar que
todos los requerimientos especificados en el documento de requerimientos
fueron cumplidos.

6.2.6. Auditoría física

Esta revisión se realiza para verificar que el software y la documentación son
consistentes y están aptos para la liberación.
6.2.7. Auditorías internas al proceso
Estas auditorías son para verificar la consistencia: del código versus el
documento de diseño, especificaciones de interface, implementaciones de
diseño versus requerimientos funcionales, requerimientos funcionales versus
descripciones de testeo.
6.2.8. Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de
todas las actividades identificadas en este Plan. Deben realizarse por una
persona ajena al grupo de trabajo (en caso de que sea posible).
6.2.9. Revisión del Plan de gestión de configuración
Esta revisión se realiza para asegurar la consistencia y completitud de los
métodos especificados en el Plan de gestión de configuración.
6.2.10. Revisión Post Mortem
Esta revisión se realiza al concluir el proyecto para especificar las actividades
de desarrollo implementadas durante el proyecto y para proveer
recomendaciones.
6.2.11. Agenda
Se estima la semana en la cual se realizarán las revisiones, luego estas se
ajustaran de acuerdo a la disponibilidad de los recursos humanos y las
prioridades del grupo en el plan de iteración correspondiente.
Semanas en las que se

Revisión
realizan.
Revisión de Requerimientos 03 al 08/Octubre/2016
Revisión de Diseño preliminar 03 al 08/Octubre/2016
Revisión de Diseño Crítico 10 al 15/Octubre/2016
Revisión de Plan de V&V 10 al 15/Octubre/2016
Auditoria funcional 10 al 15/Octubre/2016
Auditoria física 17 al 22/Octubre/2016
Auditorías internas al proceso 17 al 22/Octubre/2016
Revisión de gestión 24 al 29/Octubre/2016
Revisión del plan de gestión 24 al 29/Octubre/2016
Revisión Post Mortem 24 al 29/Octubre/2016

6.3. Otras revisiones

6.3.1. Revisión de documentación de usuario
Se revisa la completitud, claridad, correctitud y aplicación de uso.

CONTRATO
REUNIDOS
En San Andrés Tuxtla, a 28 de octubre de 2016
DE UNA PARTE:
Diana Sarahí Ramírez Vichi, director y jefe de investigación y desarrollo de proyectos de software e
innovación , con domicilio en calle Francisco Villa s/n, colonia el Dagamal, CP 95830, ciudad
Santiago Tuxtla.
Y DE OTRA:
La fundación Mexicana para la planeación familiar MEXFAM con domicilio en calle Independencia
entre Narciso Mendoza y María Boettiger, Catemaco, Veracruz.
Los contratantes se reconocen recíprocamente, en el carácter en que intervienen, plena capacidad

jurídica para contratar y en el caso de representar a terceros, cada uno de los intervinientes
asegura que, el poder con el que actúa no ha sido revocado ni limitado, y que es bastante para
obligar a sus representados en virtud de este CONTRATO DE DESARROLLO DE UN SISTEMA
DE SOFTWARE y a tal objeto:
EXPONEN:
I. Que Diana Sarahí Ramírez Vichi se dedica a la prestación de servicios informáticos, y entre
éstos realiza desarrollo de software.
II. Que MEXFAM está interesada en contratar la elaboración por Diana Sarahí Ramírez Vichi de un
sistema de software con los requisitos y estipulaciones acordadas en este contrato.
III. Que en base a lo anterior, ambas partes acuerdan la suscripción del presente contrato que se
regirá de acuerdo con los siguientes
PACTOS Y ESTIPULACIONES:
PRIMERA.- OBJETO
El objeto del presente contrato es el desarrollo [instalación, puesta en servicio y formación de

usuarios] por parte de Diana Sarahí Ramírez Vichi para MEXFAM del sistema de software
denominado: FARCOM
La descripción de los requisitos técnicos, funcionales y de calidad del sistema de software objeto

de desarrollo se encuentran definidos en los Anexos I y II al presente contrato.

Dichos anexos forman parte de este contrato, su contenido tiene carácter contractual y es
aceptado y firmado por las partes.
El Anexo I describe los requisitos del sistema (ISO/IEC 12207 1998 5.1), empleando el formato y
las directrices del estándar técnico IEEE 1362.
El Anexo II describe los requisitos del software, empleando el formato y las directrices
recomendadas por el estándar técnico IEEE 830.
SEGUNDA.- MODIFICACIONES DE REQUISITOS
Para gestionar las posibles modificaciones de los requisitos durante el periodo de desarrollo, cada
parte determina un interlocutor válido autorizado a proponer o autorizar posibles modificaciones a
los requisitos de los Anexos I y II.
Los nombres de estos interlocutores se especifican en la cláusula novena.
Solamente se considerarán válidas las modificaciones de requisitos aceptadas de común acuerdo
por ambos interlocutores, y cuya descripción y acuerdo quede documentalmente reflejada en una
revisión de los anexos de requisitos (Anexos I y II). numerada y firmada por ambos interlocutores.
Cuando las modificaciones de los requisitos impliquen la modificación del coste o tiempo previsto
en este contrato para el desarrollo del sistema, su aprobación supondrá necesariamente una
revisión del presente contrato con los nuevos costes o fechas acordados.
TERCERA.- ENTREGA DEL SISTEMA
Diana Sarahí Ramírez Vichi entregará a la empresa MEXFAM el sistema de software en fecha
anterior al 31 de diciembre de 2016.
El sistema objeto de la entrega incluye: [para seleccionar y modificar o ampliar las opciones
adecuadas]
- Todo el código ejecutable necesario para el correcto funcionamiento del sistema grabado en
soporte [CD-ROM, DVD, ...]
- Todo el código ejecutable necesario para el correcto funcionamiento del sistema grabado en
soporte [CD-ROM, DVD,...] y adecuadamente instalado para su funcionamiento en los equipos de
hardware de operación del sistema.
- Los siguientes productos y sub-productos de desarrollo: [el código fuente desarrollado, la
documentación de diseño y análisis, la documentación de usuario, los documentos de pruebas].
Empresa MEXFAM procederá a la verificación de los productos y sub-productos entregados y a la

validación del correcto funcionamiento del sistema tomando como referencia para la misma las
especificaciones de requisitos de los Anexos I y II de este contrato.
La verificación y validación la realizará en un periodo de tiempo inferior a 30 días naturales
contados a partir de la entrega del sistema.
Si pasada esta fecha Empresa MEXFAM no manifiesta por escrito reparos a Diana Sarahí Ramírez
Vichi, se entenderá que el sistema es conforme a los requisitos.
CUARTA.- PENALIZACIONES
Cualquier retraso de Diana Sarahí Ramírez Vichi en la fecha de entrega del sistema acordada
dará derecho a la exigencia de una penalización económica a pagar por Diana Sarahí Ramírez
Vichi a la empresa MEXFAM de $500 por día, que deberá abonarse del siguiente modo: ................

Estas penalizaciones no se aplicarán en los casos en los que se demuestre que el retraso es
debido a la empresa MEXFAM.
QUINTA.- PROPIEDAD INTELECTUAL
Corresponderán a la empresa MEXFAM cualesquiera derechos de explotación derivados de la Ley

de Propiedad Intelectual, tanto del sistema de software desarrollado, como de los subsistemas que
lo integran y que igualmente hayan sido desarrollados por Diana Sarahí Ramírez Vichi , así como
de todos los sub-productos del desarrollo: documentación técnica de análisis y diseño,
documentación de planificación y pruebas, documentación de usuario, etc.
Diana Sarahí Ramírez Vichi garantiza que los trabajos y servicios prestados a la empresa
MEXFAM por el objeto de este contrato no infringen ni vulneran los derechos de propiedad
intelectual o industrial o cualesquiera otros derechos legales o contractuales de terceros.
SEXTA.- CONDICIONES ECONÓMICAS
El precio del desarrollo del sistema de software objeto del presente contrato es de $135,000 que
serán abonados tras la emisión de la(s) correspondiente(s) factura(s) según el calendario de pago
siguiente:
SÉPTIMA.- GARANTÍA
Una vez validada por parte de la empresa MEXFAM la entrega del sistema de software, se iniciará
un periodo de garantía del correcto funcionamiento del sistema de 12 meses
La garantía del sistema cubrirá un servicio de mantenimiento correctivo por parte de Diana Sarahí
Ramírez Vichi, con un tiempo de respuesta a las notificaciones de incidencias inferior a 12 horas
laborables desde la notificación, y un tiempo de reparación acorde al esfuerzo técnico necesario
para su reparación.
Por mantenimiento correctivo se entiende el definido en el estándar técnico de mantenimiento de
software IEEE 1219-1998: "Modificaciones realizadas a un producto de software después de su
entrega para corregir fallos descubiertos", no siendo extensiva la garantía para operaciones de
mantenimiento adaptativo ni perfectivo.
OCTAVA.- RESOLUCIÓN DEL CONTRATO
El presente contrato quedará resuelto al producirse alguna de las siguientes causas:

- Cumplimiento de las prestaciones de cada parte en las fechas y formas acordadas.
- Incumplimiento de las obligaciones correspondientes a cada parte. La resolución por esta causa
podrá dar lugar a indemnización por daños y perjuicios causados por el incumplimiento.
- Por hallarse cualquiera de las partes en un supuesto de caso fortuito o fuerza mayor.
Si el contrato fuera resuelto anticipadamente sin producir la entrega del sistema de software en su
totalidad o en la forma dispuesta en este contrato, ambas partes colaborarán de buena fe y en
especial Diana Sarahí Ramírez Vichi para facilitar, bien la contratación de una nueva entidad que
dé continuidad a los trabajos, o bien para que la empresa MEXFAM pueda continuar con los
trabajos, y en cualquiera de los casos facilitar la transferencia del conocimiento y sub-productos
generados.

NOVENA.- GENERAL
Personal: cada parte asume, a título exclusivo el carácter de patrono o empresario respecto de su
personal empleado para la ejecución del presente contrato.
Interlocutores válidos: Para llevar a cabo las comunicaciones necesarias durante la ejecución del
contrato, y para validar las posibles modificaciones de requisitos se nombran como interlocutores
válidos.
Por la EMPRESA CLIENTE

D. : Roberto Barrón Valencia
Dirección : Calle Independencia entre Narciso Mendoza y María Boettiger, Catemaco, Veracruz.
Por la EMPRESA SUMINISTRADORA

Dña. : Diana Sarahí Ramírez Vichi
Dirección: Francisco Villa s/n
Teléfono: 2941333603
E-mail: leo_diana13894@hotmail.com
Efecto: El presente contrato surtirá efecto a partir de la fecha de su firma.
Cesión del contrato: Las partes no pueden ceder, transferir ni delegar el presente contrato o alguna
de sus obligaciones, ni subrogar a terceros en cualquier forma válida en derecho, ni gravar o
hipotecar alguno de los derechos contemplados en el contrato, sin la previa conformidad escrita de
la otra parte.
Contrato completo: El presente contrato, incluido los Anexos I y II que forman parte integrante del
mismo, constituyen el total del contrato entre las partes sobre el objeto del mismo y sustituye,
deroga y deja sin efecto cualquier otro acuerdo referido al mismo objeto a que hubieren llegado las
partes con anterioridad a la fecha de la firma.
Nulidad o anulabilidad: La declaración de cualquiera de estas estipulaciones como nula, inválida o

ineficaz no afectará a la validez o eficacia de las restantes, que continuarán vinculando a las
partes.
La renuncia de una parte a exigir en un momento determinado el cumplimiento de uno de los
pactos aquí acordados no implica una renuncia con carácter general ni puede crear un derecho
adquirido para la otra parte.
Modificaciones: Cuando proceda que las partes deseen incorporar de mutuo acuerdo
modificaciones de requisitos del sistema de software, serán aceptadas reflejándolas con una
versión nueva, numerada, fechada y firmada por ambas partes de los requisitos del sistema o de
los requisitos del software (anexos I y II), y si la modificación implicara cambios en los costes,
fechas de pago o de entrega, también se hará constar como modificación del presente contrato,
generando un nuevo anexo escrito, fechado y firmado por ambas partes.
Exención de responsabilidad: ninguna de las partes será responsable por incumplimiento o retraso

de sus obligaciones si la falta de ejecución o retraso fuera consecuencia de caso fortuito o fuerza
mayor.
DÉCIMA.- SUMISIÓN
Las partes contratantes, con renuncia expresa de su propio fuero o del que pudiera
corresponderles, en cuantas cuestiones o litigios se susciten del motivo de la interpretación ,
aplicación o cumplimiento del presente acuerdo, se someten a la Jurisdicción y Competencia de los
Juzgados y sus Tribunales superiores. La ley aplicable será la española.
Y en prueba de conformidad ambas partes firman el presente, por duplicado ejemplar y a un sólo
efecto en la fecha y lugar indicado.

HERRAMIENTAS PARA LA ADMINISTRACION Y ASEGURAMIENTO DEL

PROYECTO
MICROSOFT OFFICE 2016

o WORD 2016: Esta herramienta se empleó en la generación de documentos del
desarrollo del proyecto.
GANTT PROJECT
Esta aplicación sirvió para la organización y planificación del proyecto. Además describió a
detalle las actividades que se llevan a cabo
JAVA JRE1.8.0_111
NETBEANS IDE 8.0.2

Entorno para desarrollar, diseñar y editar programas en la plataforma java.


INSTALACIÓN
Ingreso al sistema:
El Sistema FARCOM es una aplicación a la cual puede ser accedida con el sistema instalado
desde cualquier equipo de cómputo. Para ingresar al sistema primero debe buscar en el escritorio
es el icono con el nombre FARCOM.

Este icono Lo llevara al inicio de sección aquí se deben dar click en el botón denominado
“CONTINUAR”.
Posteriormente se mostrara la siguiente ventana donde debe ingresare el

nombre de usuario y contraseña que se le proporcionó.

MEXFAM

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MEXFAM

Transféré par

Droits d'auteur :

Formats disponibles

CONTROL DE INVENTARIO DE LA CLÍNICA MEXFAM

GESTIÓN DE PROYECTOS DE SOFTWARE 1

GESTIÓN DE PROYECTOS DE SOFTWARE 2

GESTIÓN DE PROYECTOS DE SOFTWARE 3

4.3. Otros documentos 39

GESTIÓN DE PROYECTOS DE SOFTWARE 4

6.2.6. Auditoría física 42

6.3. Otras revisiones 43

GESTIÓN DE PROYECTOS DE SOFTWARE 5

}, que en él se garantiza que el producto de software funcione como se desea y se revisa a

GESTIÓN DE PROYECTOS DE SOFTWARE 6

1.1 DESCRIPCIÓN DEL ÁREA

GESTIÓN DE PROYECTOS DE SOFTWARE 7

1.2 CROQUIS DE UBICACIÓN

GESTIÓN DE PROYECTOS DE SOFTWARE 8

ÁREA MÉDICA ÁREA ADMINISTRATIVA

GESTIÓN DE PROYECTOS DE SOFTWARE 9

1.4 ÁREAS FUNCIONALES

GESTIÓN DE PROYECTOS DE SOFTWARE 10

2 DEFINICIÓN DEL PROBLEMA.

Estas actividades metódicas y manuales producen el retraso en la entrega de los medicamentos a

GESTIÓN DE PROYECTOS DE SOFTWARE 11

3.1 OBJETIVO GENERAL

Desarrollar un sistema de control de inventario de medicamentos en la clínica MEXFAM del

3.2 OBJETIVO ESPECÍFICO

 Realizar un análisis del proceso de control del manejo de inventario en la clínica

GESTIÓN DE PROYECTOS DE SOFTWARE 12

GESTIÓN DE PROYECTOS DE SOFTWARE 13

 La compra del hardware necesario para la implementación del sistema lo obtendrá la

GESTIÓN DE PROYECTOS DE SOFTWARE 14

GESTIÓN DE PROYECTOS DE SOFTWARE 15

GESTIÓN DE PROYECTOS DE SOFTWARE 16

6.2 METODOLOGÍA DE DESARROLLO

GESTIÓN DE PROYECTOS DE SOFTWARE 17

DESCRIPCIÓN DE LAS ACTIVIDADES A REALIZAR

GESTIÓN DE PROYECTOS DE SOFTWARE 18

CONSTRUCCIÓN DEL SISTEMA

GESTIÓN DE PROYECTOS DE SOFTWARE 19

6.3 ESTUDIO DE FACTIBILIDAD

A continuación, se presenta el estudio de factibilidad realizado para el sistema de control de

Paquetería que permite crear, editar y modificar

GESTIÓN DE PROYECTOS DE SOFTWARE 20

SISTEMA OPERATIVO Windows 10

Se determina costos de los materiales y recursos utilizados para la creación

CANTIDAD DESCRIPCIÓN COSTO

GESTIÓN DE PROYECTOS DE SOFTWARE 21

6.4 REQUERIMIENTOS DEL SISTEMA

GESTIÓN DE PROYECTOS DE SOFTWARE 22

6.5 GESTIÓN DE RIESGOS

Etapa de análisis y formulación.

Diseñar y estructurar el contenido del sistema

CODIFICADOR Codificar el sistema

GESTIÓN DE PROYECTOS DE SOFTWARE 23

RIESGO DESCRIPCIÓN PROBLEMA

Producto que nadie

GESTIÓN DE PROYECTOS DE SOFTWARE 24

GESTIÓN DE PROYECTOS DE SOFTWARE 25

Personal con experiencia

La ausencia del personal Retraso con la

GESTIÓN DE PROYECTOS DE SOFTWARE 26

Manejo No se detectan y corrigen El sistema no

GESTIÓN DE PROYECTOS DE SOFTWARE 27

6.6 DICCIONARIO DE DATOS

 Aseguramiento de la Calidad del Software (SQA)  El propósito de SQA es entregar a la