Ieee T Espel 0002

ESCUELA POLITECNICA DEL EJRCITO
SEDE LATACUNGA
FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA
ESTUDIO
APLICACIN
DE
ESTANDARES
IEEE
(INSTITUTO
DE
INGENIEROS ELECTRICOS Y ELECTRONICOS) DE CALIDAD EN EL

DESARROLLO DEL PRODUCTO SOFTWARE, CASO PRCTICO:SISTEMA
DE INVENTARIO.
PROYECTO PREVIO A LA OBTENCIN DEL TITULO DE INGENIERO EN

SISTEMAS E INFORMATICA
GLADYS PIEDAD AGUAGALLO LEMA

PAULINA DE LOS ANGELES CAIZARES CUEVA
Latacunga, -Ecuador
2005
- 27 -
DEDICATORIA
Es deber de los padres preparar a sus

hijos para el camino, y no preparar el
camino a sus hijos.
(Schiller)
El presenta trabajo lo dedico a mis padres quienes con esfuerzo, trabajo y amor supieron
encaminar los pasos de mi vida por el sendero del bien para poder alcanzar los sueos e
ideales sin dejar de lado la superacin personal e intelectual.
- 28 -
AGRADECIMIENTO
Quiero comenzar agradeciendo a DIOS por darme la vida , a mis padres por apoyarme y
comprenderme en todas las etapas de la vida y ser el pilar fundamental para alcanzar un
triunfo ms en mi vida, tambin a mis compaeros y amigos que siempre me apoyaron
en los estudios, a todos mis profesores por compartir los conocimientos en todos estos
aos de estudio en las aulas.
A la ESPE sede Latacunga institucin educativa que me acogi y formo para
desarrollarme tanto en el mbito profesional y humano.
No quiero terminar sin agradecer al director y codirector de la tesis que me guiaron en el
desarrollo de la misma y al personal del comisariato de la Cooperativa San Antonio por
tener paciencia y facilitarnos toda la informacin necesaria para desarrollar la tesis.
- 29 -
INDICE GENERAL
Pg.
CAPITULO I.- ANTECEDENTES DE LA INGENIERIA

DE SOFTWARE, CALIDAD Y METRICA VERSIN 3
1.1 DEFINICIN DEL SOFTWARE..........................................................1
1.2 PRODUCTO SOFTWARE ..............................................................................2
1.3 METODOLOGIAS Y HERRAMIENTAS....3
1.4 MODELOS DE PROCESOS SOFTWARE ..4
1.5 VISION GENERICA DE LA INGENIERIA DE SOFTWARE ...6
1.6 ALGUNOS ANTECEDENTES AL CONCEPTO DE CALIDAD ..7
1.7 CALIDAD DEL SOFTWARE ........11
1.8 METRICA VERSIN 3 ..12
1.8.1 INTRODUCCIN......12
1.8.2 APORTACIONES DE METRICA VERSION 3 ...13
1.9 ESTRUCTURA PRINCIPAL .....14
1.9.1 PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI) .14
1.9.2 DESARROLLO DE SISTEMAS DE INFORMACIN ...15
1.9.3 MANTENIMIENTO DE SISTEMAS DE INFORMACIN (MSI).....21
1.10
INTERFACES 22
1.10.1 GESTIN DE PROYECTOS (GP)..22
1.10.2 SEGURIDAD (SEG) ...............23
1.10.3 GESTIN DE LA CONFIGURACIN (GC) 23
1.10.4 ASEGURAMIENTO DE LA CALIDAD (CAL)............24
1.11
TECNICAS Y PRACTICAS .....25
1.12
PARTICIPANTES ..25
CAPITULO II.- ESTANDARES IEEE DE CALIDAD

2.1 IMPORTANCIA DE LOS ESTANTADRES IEEE27
- 30 -
2.2 CONCEPTO DE IEEE 28

2.3 TIPOS DE ESTANDARES IEEE PARA INGENIERIA DE SOFTWARE...28
2.3.1 DESCRIPCION DE ESTANDARES IEEE ..33
2.4 PORQUE ES IMPORTANTE IMPLEMENTAR ESTANDARES
DE CALIDAD EN SOFTWARE . ..56
CAPITULO III.- PROBLEMTICA DEL COMISARIATO

DE LA COOPERATIVA SAN ANTONIO
3.1.-
ANTECEDENTES DEL COMISARIATO DE LA COOPERATIVA .58
3.2.-
ESTUDIO DE LA SITUACIN ACTUAL DE LA COOPERATIVA.59
3.3.-
IMPORTANCIA DE LA AUTOMATIZACIN DEL INVENTARIO ...60
CAPITULO IV.- APLICACION DE LOS ESTANDARES IEEE DE

CALIDAD EN EL DESARROLLO DEL SOFTWARE
4.1.-
PLANIFICACION DE SISTEMAS DE INFORMACIN (PSI).......62

4.1.1.- INICIO DEL PLAN DE INFORMACIN 62
4.1.2.- DEFINICION Y ORGANIZACIN DEL PSI ..............65
4.1.3.- ESTUDIO DE LA INFORMACIN RELEVANTE .68
4.1.4.- IDENTIFICACIN DE REQUISITOS .69
4.1.5.- ESTUDIO DE LOS SISTEMAS DE INFORMACIN
ACTUALES72
4.1.6.- DISEO DEL MODELO DE SISTEMAS DE INFORMACIN 72
4.1.7.- DEFINICIN DE LA ARQUITECTURA TECNOLOGICA ...76
4.1.8.- DEFINICION DEL PLAN DE ACCIN... ...76
4.2.-
ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS) ..77

4.2.1.- ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA 77
4.2.2.- IDENTIFICACIN DEL ALCANCE DEL SISTEMA .....77
4.2.3.- ESPECIFICACIN DEL ALCANCE DEL EVS ...78
- 31 -
4.2.4.- ESTUDIO DE LA SITUACIN ACTUAL ...78

4.2.5.- DEFINICIN DE REQUISITOS DEL SISTEMA 78
4.2.6.- ESTUDIO DE ALTERNATIVAS DE SOLUCIN ...82
4.2.7.- VALORACIN DE ALTERNATIVAS .83
4.2.8.- SELECCIN DE LA SOLUCIN 84
4.3.-
ANALISIS DEL SISTEMA DE INFORMACIN (ASI) ..84

4.3.1.- DEFINICIN DEL SISTEMA....84
4.3.2.- ESTABLECIMIENTO DE REQUISITOS 87
4.3.3.- IDENTIFICACIN DE SUBSISTEMAS DE ANALISIS.99
4.3.4.- ANALISIS DE CASOS DE USO......100
4.3.5.- ANALISIS DE CLASES104
4.3.6.- ELABORACIN DEL MODELO DE DATOS106
4.3.7.- ELABORACIN DEL MODELOS DE PROCESOS..109
4.3.8.- DEFINICIN DE INTERFACES DE USUARIO.109
4.3.9.- ANALISIS DE CONSISTENCIA Y ESPECIFICACIN DE
REQUISITOS ...110
4.3.10.- ESPECIFICACIN DEL PLAN DE PRUEBAS ..112
4.3.11.- APROBACIN DEL ANALISIS DEL SISTEMA DE
INFORMACIN.112
4.4.-
DISEO DEL SISTEMA DE INFORMACIN (DSI).. .113

4.4.1.- DEFINICION DE LA ARQUITECTURA DEL
SISTEMA..113
4.4.2.- DISEO DE LA AQUITECTURA DE SOPORTE 117
4.4.3.- DISEO DE CASOS DE USOS REALES ......117
4.4.4.- DISEO DE CLASES .124
4.4.5.- DISEO DE LA ARQUITECTURA DE MODULOS DEL
SISTEMA .....125
4.4.6.- DISEO FISICO DE DATOS . ...125
4.4.7.- VERIFICACION Y ACEPTACIN DE LA ARQUITECTURA
DEL SISTEMA...125
- 32 -
4.4.8.- GENERACIN DE ESPECIFICACIONES DE

CONSTRUCCIN...126
4.4.9.- DISEO DE LA MIGRACIN DE CARGA
INICIAL DE DATOS.127
4.4.10.- ESPECIFICACIN TECNICA DEL PLAN DE PRUEBAS.127
4.4.11.- ESTABLECIMIENTO DE REQUISTOS
DE IMPLANTACIN127
4.4.12.- APROBACIN DEL DISEO DEL SISTEMA
DE INFORMACIN.128
4.5.-
CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)128

4.5.1.- PREPARACIN DEL ENTORNO DE GENERACIN
Y CONSTRUCCIN128
4.5.2.- GENERACIN DEL CODIGO DE LOS COMPONETES
Y PROCEDIMIENTOS...129
4.5.3.- EJECUCIN DE LAS PRUEBAS UNITARIAS.130
4.5.4.- EJECUCIN DE LAS PRUEBAS DE INTEGRACIN..130
4.5.5.- EJECUCIN DE LAS PRUEBAS DEL SISTEMA....130
4.5.6.- ELABORACIN DE LOS MANUALES USUARIOS...131
4.5.7.- DEFINICIN DE LA FORMACIN DE USUARIOS
FINALES..131
4.5.8.- CONSTRUCCIN DE LOS COMPONENTES Y
PROCREDIMIENTOS DE MIGRACIN Y CARGA
INICIAL DE DATOS132
4.5.9.- APROBACIN DEL SISITEMA DE INFORMACIN.....132
4.6.-
IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS)..132
4.7.-
MATENIMIENTO DEL SISTEMA DE INFORMACIN (MSI)...133
4.8.-
ASEGURAMIENTO DE LA CALIDAD.133
4.8.1.- ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS).133
- 33 -
4.8.2.- ANALISIS DEL SISTEMA DE INFORMACIN (ASI)134

4.8.3.- DISEO DEL SISTEMA DE INFORMACIN (DSI)137
4.8.4.- CONSTRUCCIN DEL SISTEMA DE INFORMACIN
(CSI)..139
4.8.5.- IMPLANTACIN Y ACEPTACIN DEL SISTEMA140
4.8.6.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN140
4.9.-
INTERFAZ DE SEGURIDAD.141
4.9.1.- PLANIFICACIN DEL SISTEMA DE INFORMACIN.141
4.9.2.- ESTUDIO DE VIABILIDAD DEL SISTEMA...145
4.9.3.- ANALISIS DEL SISTEMA DE INFORMACIN.146
4.9.4.- DISEO DEL SISTEMA DE INFORMACIN......148
4.9.5.- CONSTRUCCIN DEL SISTEMA DE INFORMACIN......150
4.9.6.- IMPLANTACIN Y ACEPTACIN DEL SISTEMA 151
4.9.7.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN...151
4.10.- GESTION DE LA CONFIGURACIN152

4.10.1.- ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)...145
4.10.2.- ANALISIS, DISEO, CONSTRUCCIN E IMPLANTACIN
DEL SISTEMA DE INFORMACIN.......152
4.10.3.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN...153
4.11.- GESTIN DE PROYECTOS154
4.11.1.- ACTIVIDADES DE INICIO DEL PROYECTO..154
4.11.2.- ACTIVIDADES DE SEGUIMIENTO Y CONTROL...169
CAPITULO V.- CONCLUSIONES Y RECOMENDACIONES

5.1.- CONCLUSIONES .....182
5.2.- RECOMENDACIONES.183
- 34 -
INDICE DE FIGURAS
Pg.
Fig. 1.1.- Estructura del Software ......2
Fig. 1.2.- Estructura Principal de Mtrica Versin 3.....14
Fig. 4.1.- Estructura Orgnica y funcional de la Cooperativa
San Antonio....64
Fig. 4.2.- Sistema de Inventario (Jerarqua) .74
Fig. 4.3.- Modelo Conceptual (CASE STUDIO 2 Versin 2.19)................107
Fig. 4.4.- Modelo Fisico (CASE STUDIO 2 Versin 2.19)........................................108
Fig. 4.5.- Niveles de Arquitectura....113
Fig. 4.5.- Oranigrama del Proyecto SICOIN ..168
INDICE DE TABLAS
Tabla. 4.1 Prioridades de 1 a 3 ..72
- 35 -
INDICE DE ANEXOS
ANEXO1.1 HERRAMIENTAS CASE
ANEXO 1.2 VISIN GENERAL DE LA INGENIERA DE SOFTWARE
ANEXO 2.1 INFORMACIN DE ESTNDARES
ANEXO 4.1 MEMORANDO DE ACEPTACIN DEL PLAN DE TRABAJO
ANEXO 4.2 ENCUESTA
ANEXO 4.3 REVISIN Y APROBACIN DEL PSI
ANEXO 4.4 SELECCIN DE LA SOLUCIN
ANEXO 4.5 IDEF1X Y CASE STUDIO 2 VERSIN 2.19
ANEXO 4.6 ESTANDAR IEEE 830 1998
ANEXO 4.7 ESTANDAR IEEE 1008 1997 R 2003
ANEXO 4.8 REVISION Y APROBACIN DEL ASI
ANEXO 4.10 (CD) ESTANDAR IEEE 1063 2001 (VER CD)
ANEXO 4.11 (CD) REVISIN Y APROBACIN DEL DSI
ANEXO 4.12 CODIGO FUENTE (VER CD)
ANEXO 4.13 REVISIN Y APROBACIN DEL CSI
- 36 -
WEBGRAFIA
http://www.isi.unanleon.edu.ni/gbai/Ing_Soft_PI/Capitulo_1.htm
[1] http://cosaslibres.com/software.html
[2] http://coqui.Ice.org/cedu6320/ssegarra/soft.html
[3] http://www.isi.unanleon.edu.ni/gbai/Ing_Soft_PI/Capitulo_1.htm
Libro
IAN SOMMERVILLE
INGENIERIA DE SOFTWARE
SEXTA EDICIN AO 2002
PEARSON EDUCATION LIMITED 1989-2001
http://dis.um.es/~jnicolas/09BK_FIS.html
http://www.isi.unanleon.edu.ni/gbai/Ing_Soft_PI/Capitulo_1.htm
[Ref 1.6]
http://www.gestiopolis.com/recursos2/documentos/fulldocs/ger/caltotalmem
o.htm
[1] http://www.infomed.sld.cu/revistas/aci/vol3_3_95/aci05395.htm
http://www.dc.uba.ar/people/materias/isoft2/clases/calidad.pdf
http:/dmi.uib.es/ bbuades/calidad/sld014.htm
FUENTE CD
IEEE Software Engineering Standards Collection: 2003
INFORMACIN RECOPILADA DE LA COOPERATIVA SAN

ANTONIO
- 37 -
CAPITULO I
I.- ANTECEDENTES DE LA INGENIERIA DE SOFTWARE,
CALIDAD Y METRICA VERSION 3
1.1.- DEFINICION DE SOFTWARE

Actualmente, el software ha superado al hardware como la clave del xito
de muchos sistemas basados en computadoras. Tanto que se utiliza la
computadora para llevar un negocio, controlar un producto o capacitar un sistema,
el software es el factor que marca la diferencia. Lo que diferencia a una compaa
de la competencia es la suficiencia y la oportunidad de la informacin dada por el
software. El software es el mecanismo que nos facilita utilizar y explotar las
enormes capacidades de procesamiento y almacenamiento del hardware
moderno.
A continuacin se citara algunas definiciones:
El software es un conjunto de instrucciones detalladas que controlan la

operacin de un sistema computacional. [1]
El software es simplemente el conjunto de instrucciones individuales que se

le proporciona al microprocesador para que pueda procesar los datos y
generar los resultados esperados.[2]
El software es un conjunto de : INSTRUCCIONES que cuando se ejecutan

proporcionan la funcin y el rendimiento deseados; ESTRUCTURA DE
DATOS que permiten a los programas manipular adecuadamente la
informacin y DOCUMENTOS que describen las operaciones y el uso de
programas[ 3]
- 38 -
INSTRUCCIONES
SOFTWARE
ESTRUCTURA DE DATOS
DOCUMENTACION
Fig. 1.1 Estructura del Software
En sntesis el software se puede definir como un conjunto de instrucciones

lgicas asociadas con la operacin de un sistema, distinguindose de los
componentes fsicos llamados hardware.
1.2.- PRODUCTO SOFTWARE
Un producto software se puede definir como una expresin de un conjunto

de instrucciones mediante palabras, cdigos, planes o en cualquier otra forma,
que al ser automatizada, es capaz de hacer que un computador ejecute una tarea
u obtenga un resultado, esto involucra tambin conocer algunos aspectos que
incluye
la
calidad
como
es:
funcionalidad,
mantenimiento.
- 39 -
eficiencia
capacidad
de
1.3.- METODOLOGIAS Y HERRAMIENTAS
Metodologa
Estas son algunas definiciones de metodologa:
La metodologa estudia al conjunto de mtodos integrados para alcanzar

una meta comn, definen la secuencia en la que se aplican los mtodos,
productos o documentos requeridos, controles de calidad.
La metodologa es una versin amplia y detallada de un ciclo de vida

completo de desarrollo de sistemas que incluye:
Reglas, procedimientos, mtodos, herramientas
Funciones individuales y en grupos por cada tarea
Productos resultantes
Normas de calidad
[Whitten, Bentley, Barlow]

Es un conjunto de filosofas, fases, procedimientos, reglas, tcnicas,
herramientas,
documentacin
aspectos
de
formacin
para
los
desarrolladores de sistemas de informacin.[MADDISON-83]
En conclusin metodologa es el conjunto de mtodos que se aplican en

el desarrollo de un sistema que incluye fases, tcnicas, procedimientos, reglas,
herramientas, documentacin y normas de calidad.
Mtodo
Los mtodos indican como construir el software, los mtodos abarcan una
gran gama de tareas que incluyen planificacin y estimacin de proyectos,
- 40 -
anlisis de los requisitos, diseo de estructura de datos, arquitectura de

programas, procedimientos algortmicos, codificacin, prueba y mantenimiento.[8]
Herramientas
Aqu algunas definiciones de herramientas:
Las herramientas son los ambientes de apoyo necesario para automatizar

las practicas de ingeniera de software.
Las herramientas suministran un soporte automtico para los mtodos,

existen herramientas para soportar cada uno de los mtodos integran
diferentes herramientas que se denominan sistemas CASE (Ingeniera de
Software asistida por ordenador) (Ver Anexo 1.1)
Las herramientas son ayudas automatizadas que soportan el control del

volumen de la informacin,
pruebas para asegurar la consistencia y
pruebas para la totalidad.
1.4.- MODELOS DE PROCESOS SOFTWARE

Proceso software
Un proceso software es un conjunto de actividades y resultados asociados

que producen un producto de software. Es uno de los componentes de un mtodo
de desarrollo de software. [Sommerville 2002]
Existen 4 actividades fundamentales, comunes para todos los procesos de

software:
1) Especificacin del software.- La funcionalidad del software y las

restricciones sobre su operacin deben quedar definidas.
- 41 -
2) Desarrollo del software.- Debe producirse software que cumpla con la

especificacin.
3) Validacin del software.- El software debe validarse para asegurar

qu es lo que el cliente requiere
4) Evolucin del software.- El software debe evolucionar para cumplir

con los cambios requeridos por el cliente.
Distintos procesos de software organizan las actividades de diferentes

formas, y las describen con diferente nivel de detalle. El tiempo de cada actividad
vara, as como los resultados. Organizaciones diferentes usan procesos
diferentes para producir el mismo producto. Sin embargo, para algunos tipos de
aplicacin, algunos procesos son ms convenientes que otros.
Modelo de Procesos del Software
Un modelo de procesos del software es una descripcin de un proceso de

software que se presenta desde una perspectiva particular. Es una abstraccin de
un proceso real. Incluye actividades (que son parte de los procesos del software),
los productos software, y el papel de las personas interesadas en el desarrollo
(stakeholders). [Sommerville 2002]
Estos modelos, pueden ser:
1) Modelo de Flujo de Trabajo (workflow).- Muestra secuencia de

actividades en el proceso de entrada, salida y dependencias, son
acciones humanas.
- 42 -
2) Modelo de Flujo de datos.- Representa un conjunto de actividades las

cuales llevan la transformacin en los datos, por ejemplo una
especificacin se transforma en una salida como un diseo. Son
acciones llevadas acabo por humanos o por la computadora.
3) Modelo de accin.- Representa los roles de la gente involucrada en el

proceso del software y las actividades de las que son responsables.
Dentro del Modelo de Proceso del Software existe una gran variedad de
modelos diferentes para desarrollar el software.
1.5.- VISION GENERICA DE LA INGENIERIA DE SOFTWARE

La Ingeniera del Software es la ingeniera que trata de construir software
de alta calidad, se estable y usa los principios de ingeniera robustos, orientados a
garantizar la obtencin de software econmico, fiable y eficiente sobre mquinas
reales, especialmente optimizando tiempo, costos y recursos.
La ingeniera de software surge de la ingeniera de sistemas y de hardware.

Abarca un conjunto de tres elementos claves que son: mtodos, herramientas y
procedimientos, que facilitan al gestor controlar el proceso de desarrollo del
software para construir software de alta calidad. El proceso de desarrollo del
software contiene tres fases genricas, independientemente del paradigma de
ingeniera elegido estas son:
1) Definicin (Anlisis del sistema del software)
2) Desarrollo (Diseo, codificacin y pruebas)
3) Mantenimiento (Se encuentra en todos los desarrollos de software)
- 43 -
El desarrollo de un sistema informtico no es totalmente secuencial, sino

que en cada una de las fases que se ha visto que se pueden detectar problemas
que obliguen a modificar algo que se hizo en una fase anterior. (Ver Anexo 1.2)
1.6.- ALGUNOS ANTECEDENTES AL CONCEPTO DE CALIDAD

Antecedentes
La historia de la humanidad est directamente ligada con la calidad desde

los tiempos ms remotos, el hombre al construir sus armas, elaborar sus
alimentos y fabricar su vestido observa las caractersticas del producto y
enseguida procura mejorarlo. La prctica de la verificacin de la calidad se
remonta a pocas anteriores al nacimiento de Cristo. En el ao 2150 Antes de
Cristo, la calidad en la construccin de casas estaba regida por el Cdigo de
Hammurabi, cuya regla numero 229 estableca que "Si un constructor construye
una casa y no lo hace con buena resistencia y la casa se derrumba y mata a los
ocupantes, el constructor debe ser ejecutado". Los fenicios tambin utilizaban un
programa de accin correctiva para asegurar la calidad, con el objeto de eliminar
la repeticin de errores. Los inspectores simplemente cortaban la mano de la
persona responsable de la calidad insatisfactoria. En los vestigios de las antiguas
culturas tambin se hace presente la calidad, ejemplo de ello son las pirmides
Egipcias, los frisos de los templos griegos, etc.
Durante la edad media surgen mercados con base en el prestigio de la

calidad de los productos, se populariz la costumbre de ponerles marca y con
esta prctica se desarroll el inters de mantener una buena reputacin (las
sedas de damasco, la porcelana china, etc.) Dado lo artesanal del proceso, la
inspeccin del producto terminado es responsabilidad del productor que es el
mismo artesano. Con el advenimiento de la era industrial esta situacin cambi, el
taller cedi su lugar a la fbrica de produccin masiva, bien fuera de artculos
terminados o bien de piezas que iban a ser ensambladas en una etapa posterior
- 44 -
de produccin. La era de la revolucin industrial, trajo consigo el sistema de

fbricas para el trabajo en serie y la especializacin del trabajo.
Como consecuencia de la alta demanda aparejada con el espritu de

mejorar la calidad de los procesos, la funcin de inspeccin llega a formar parte
vital del proceso productivo y es realizada por el mismo operario (el objeto de la
inspeccin simplemente sealaba los productos que no se ajustaban a los
estndares deseados.)
A fines del siglo XIX y durante las tres primeras dcadas del siglo XX el
objetivo es produccin. Con las aportaciones de Taylor, la funcin de inspeccin
se separa de la produccin; los productos se caracterizan por sus partes o
componentes intercambiables, el mercado se vuelve ms exigente y todo
converge a producir. El cambio en el proceso de produccin trajo consigo cambios
en la organizacin de la empresa. Como ya no era el caso de un operario que se
dedicara a la elaboracin de un artculo, fue necesario introducir en las fbricas
procedimientos especficos para atender la calidad de los productos fabricados en
forma masiva. Durante la primera guerra mundial, los sistemas de fabricacin
fueron ms complicados, implicando el control de gran nmero de trabajadores
por uno de los capataces de produccin; como resultado, aparecieron los
primeros inspectores de tiempo completo la cual se denomin como control de
calidad por inspeccin.
Las necesidades de la enorme produccin en masa requeridas por la

segunda guerra mundial originaron el control estadstico de calidad, esta fue una
fase de extensin de la inspeccin y el logro de una mayor eficiencia en las
organizaciones de inspeccin. A los inspectores se les dio herramientas con
implementos estadsticos, tales como muestreo y grficas de control. Esto fue la
contribucin ms significativa, sin embargo este trabajo permaneci restringido a
las reas de produccin y su crecimiento fue relativamente lento. Las
recomendaciones resultantes de las tcnicas estadsticas, con frecuencia no
- 45 -
podan ser manejadas en las estructuras de toma de decisiones y no abarcaban

problemas de calidad verdaderamente grandes como se les prestaban a la
gerencia del negocio.
Esta necesidad llev al control total de la calidad. Solo cuando las
empresas empezaron a establecer una estructura operativa y de toma de
decisiones para la calidad del producto que fuera lo suficientemente eficaz como
para tomar acciones adecuadas en los descubrimientos del control de calidad,
pudieron obtener resultados tangibles como mejor calidad y en menores costos.
Este marco de calidad total hizo posible revisar las decisiones

regularmente, en lugar de ocasionalmente, analizar resultados durante el proceso
y tomar la accin de control en la fuente de manufactura o de abastecimientos, y,
finalmente, detener la produccin cuando fuera necesario. Adems, proporcion
la estructura en la que las primeras herramientas del control (estadsticas de
calidad) pudieron ser reunidas con las otras muchas tcnicas adicionales como
medicin, confiabilidad, equipo de informacin de la calidad, motivacin para la
calidad, y otras numerosas tcnicas relacionadas ahora con el campo del control
moderno de calidad y con el marco general funcional de calidad de un negocio.
Evolucin del concepto de calidad

TABLA 1.1 EVOLUCIN DEL CONCEPTO DE CALIDAD
ETAPA
Artesanal
Revolucin
Industrial
Segunda
Guerra
Mundial
Posguerra
(Japn)
CONCEPTO
FINALIDAD
Hacer
las
cosas
bien Satisfacer al cliente.
independientemente del costo o Satisfacer al artesano, por el
esfuerzo necesario para ello.
trabajo bien hecho.
Crear un producto nico.
Hacer muchas cosas no importando Satisfacer una gran demanda
que
sean
de
calidad de bienes.
(Se identifica Produccin con Obtener beneficios.
Calidad).
Asegurar la eficacia del armamento Garantizar la disponibilidad
sin importar el costo, con la mayor y de un armamento eficaz en la
ms rpida produccin (Eficacia + cantidad y el momento
Plazo = Calidad)
preciso.
Hacer las cosas bien a la primera
Minimizar costos mediante la
Calidad
- 46 -
Satisfacer al cliente
Ser competitivo
Postguerra
Producir, cuanto ms mejor
Satisfacer la gran demanda
(Resto del
de bienes causada por la
mundo)
guerra
Control de
Tcnicas
de
inspeccin
en Satisfacer las necesidades
Calidad
Produccin para evitar la salida de tcnicas del producto.
bienes defectuosos.
Aseguramiento Sistemas y Procedimientos de la Satisfacer al cliente.
De la Calidad
organizacin para evitar que se Prevenir errores.
produzcan bienes defectuosos.
Reducir costos.
Ser competitivo.
Calidad Total
Teora
de
la
administracin Satisfacer tanto al cliente
empresarial
centrada
en
la externo como interno.
permanente satisfaccin de las Ser altamente competitivo.
expectativas del cliente.
Mejora Continua
Esta evolucin nos ayuda a comprender de dnde proviene la necesidad

de ofrecer una mayor calidad del producto o servicio que se proporciona al cliente
y, en definitiva, a la sociedad, y cmo poco a poco se ha ido involucrando toda la
organizacin en la consecucin de este fin. La calidad no se ha convertido
nicamente en uno de los requisitos esenciales del producto sino que en la
actualidad es un factor estratgico clave del que dependen la mayor parte de las
organizaciones, no slo para mantener su posicin en el mercado sino incluso
para asegurar su supervivencia.
La calidad del software es difcil de medir pero tenemos algunas pautas o
indicadores que nos ayudaran a diferenciar los producto de calidad como son: El
acercamiento a cero defectos, El cumplimiento de los requisitos intrnsecos y
principalmente la Satisfaccin del cliente.
Sobre todo la satisfaccin del cliente. Ya se sabe que un proveedor puede
engaar a todos alguna vez o a alguno muchas veces, pero no puede engaar a
muchos durante largo tiempo. El cliente casi siempre tiene razn y para eso
estn las encuestas de satisfaccin. El software de calidad es el que resulta en
los primeros puestos de la tabla por aclamacin de los usuarios.
[Ref 1.6]
- 47 -
1.7.- CALIDAD DEL SOFTWARE

La calidad del software es el conjunto de cualidades que lo caracterizan
y que determinan su utilidad y existencia. La calidad es sinnimo de
eficiencia,
flexibilidad,
correccin,
confiabilidad,
mantenibilidad,
portabilidad, usabilidad seguridad e integridad.[1]
La calidad del software es puede medir y varia de un sistema a otro o

de un programa a otro, se puede medir despus de elaborado el
producto. Pero esto puede resultar muy costoso si se detectan
problemas derivados de imperfecciones en el diseo, por lo que es
imprescindible tener en cuenta tanto la obtencin de la calidad como su
control durante todas las etapas del ciclo de vida del software.[1]
La calidad del software puede estar involucrado en aspectos como, la

ausencia de defectos, actitud para el uso, seguridad, confiabilidad y
reunin de especificaciones, sin embargo, hay algo importante que se
debe tener presente: La calidad del software debe ser constituida desde
el comienzo, no es algo que puede ser aadido despus.
La calidad del software es el grado con el que un sistema, componente
o proceso cumple los requerimientos especificadas y las necesidades o
expectativas del cliente o usuario. (IEEE, Std. 610-1990).
En sntesis la calidad del software es el conjunto de cualidades que se

pueden medir durante las diferentes etapas del ciclo de vida del software, la
calidad se debe construir desde el comienzo y no aadirla despus.
- 48 -
1.8.- METRICA VERSION 3

1.8.1.- INTRODUCCIN
El proyecto Mtrica Versin 3 ha tenido como objeto, obtener una nueva

versin de la metodologa Mtrica que contemple el desarrollo de Sistemas de
Informacin para las distintas tecnologas y los aspectos de gestin que aseguren
que un proyecto cumpla sus objetivos en trminos de calidad y costo.
El punto de partida del proyecto fue la anterior versin de Mtrica versin 2

y se estableci como uno de los requisitos prioritarios que se conservaran como
es: la adaptabilidad, flexibilidad y sencillez de la mtrica versin 2.1. Estudiando
los puntos fuertes y dbiles a travs de la experiencia de los actuales usuarios, de
forma que se reforzaran los primeros y se solventaran los problemas o
deficiencias detectados en la aplicacin de la anterior versin.
Mtrica versin 3
llev a cabo el anlisis de mtodos, los ltimos
estndares de calidad e ingeniera del software, el desarrollo para distintas

tecnologas, se estableci grupos de trabajo expertos en cada rea, para que
realizaran un estudio de las nuevas tendencias tecnolgicas y metodolgicas
relacionadas con desarrollos cliente/ servidor, la orientacin a objetos y base de
datos.
1.8.2.- APORTACIONES DE MTRICA VERSIN 3
Mtrica VERSIN 3 aporta con las siguientes ventajas que son: Un modo
de trabajo estndar, aumento de la calidad de los sistemas, facilita el
mantenimiento y satisfaccin de los requisitos.
Mtrica VERSIN 3 tambin integra:

- 49 -
Integran modelos estructurados y Orientados a Objetos (OO)
La planificacin estratgica
Incorporan el mantenimiento
Trata con interfaces de:
Seguridad
Aseguramiento de la calidad
Gestin de configuracin
Gestin de proyectos
1.9 ESTRUCTURA PRINCIPAL
INTERFAZ
GESTION DE
CONFIGURACION
Desarrollo
EVS
Planificacin de
Sistemas de
Informacin
PSI
Mantenimiento de
Sistemas de
Informacin
ASI
DSI
MSI
CSI
IAS
INTERFAZ
INTERFAZ
INTERFAZ
GESTION DE
PROYECTOS
ASEGURAMIENTO
DE CALIDAD
SEGURIDA
D
Fig. 1.2.- Estructura Principal de Mtrica Versin 3
- 50 -
1.9.1 PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI)
Un plan de sistemas de informacin busca obtener un marco de referencia

para el desarrollo de Sistemas de Informacin que responda a los objetivos
estratgicos de la organizacin
Descripcin crtica de la situacin actual
Arquitectura de la informacin de alto nivel
Propuesta de proyecto (con prioridades)
Propuesta de calendario y estimacin de recursos
Se estudian las necesidades de informacin de los procesos de la

organizacin, definen los requisitos generales, se obtienen modelos conceptuales
de informacin y de Sistemas de Informacin se evalan las opciones
tecnolgicas y se propone un entorno. Se elabora un calendario de proyecto que
planifican detalles de los proyecto ms prximos y se mantiene actualizando el
PSI
1.9.2 DESARROLLO DE SISTEMAS DE INFORMACIN
El proceso de desarrollo de sistemas de informacin de mtrica versin 3

contiene todas las actividades y tareas que se deben llevar a cabo para
desarrollar un sistema, cubriendo desde el anlisis de requisitos hasta la
instalacin del software.
El desarrollo de sistemas de informacin de mtrica versin 3 lo

constituyen los siguientes procesos:
1.9.2.1 ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)
- 51 -
El propsito del estudio de viabilidad del sistema es
analizar las
necesidades y proponer una solucin a corto plazo, basada en criterios

econmicos, tcnicos, legales y operativos.
La solucin consiste en definir uno o varios proyecto que afectan a uno o

varios Sistemas de Informacin ya existentes o nuevos.
Se identifican los requisitos.
Se estudian los requisitos que se han de satisfacer y
si procede la
situacin actual. Se plantean alternativas de solucin: soluciones a medida son

soluciones basadas en productos software del mercado (COTS: Commercial Off
The Shelf: Productos software listos para su uso).
Soluciones
mixtas
para
cada
alternativa:
valorar
impacto
en
la
organizacin, inversin a realizar, riesgos asociados, evaluar las distintas

alternativas y seleccionar la solucin ms adecuada definirla con ms detalle,
establecer su planificacin. Si la justificacin econmica es obvia, el riesgo tcnico
bajo, se esperan pocos problemas legales y existe una alternativa clara, este
proceso se orienta a la especificacin de requisitos, descripcin del nuevo sistema
y planificacin. El estudio de la situacin actual debe ajustarse a los beneficios
que se puedan obtener de l.
1.9.2.2 ANALISIS DEL SISTEMA DE INFORMACIN (ASI)
El propsito del anlisis del sistema de informacin es obtener una

especificacin detallada del Sistema de Informacin y de sus interfaces con otros
sistemas, que satisfaga las necesidades de informacin de los usuarios y servir
de base para el diseo. Integra las actividades de anlisis estructurado y
Orientado a objetos.
- 52 -
Los productos resultantes del Anlisis del Sistema de Informacin,

dependen del tipo de desarrollo, a continuacin detallaremos:
Descripcin general del entorno tecnolgico.

Glosario de trminos
Catlogo de normas
Catlogo de requisitos
Especificacin de interfaz de usuario.
Anlisis Estructurado: Plan de migracin y carga inicial de datos,

Contexto del sistema, Matriz de procesos/ localizacin geogrfica,
Descripcin de interfaz con otros sistemas, Modelo de procesos,
Modelo lgico de datos normalizado.
Anlisis Orientado a Objetos: Descripcin de subsistemas de

anlisis, Descripcin de interfaces entre subsistemas, Modelo de
clases de anlisis, Comportamiento de clases de anlisis, Anlisis
de la realizacin de los casos de uso.
En este proceso es muy importante la participacin de los usuarios, a

travs de tcnicas interactivas como diseo de dilogos y prototipos, que permiten
al usuario familiarizarse con el nuevo sistema y colaborar en la construccin y
perfeccionamiento del mismo.
1.9.2.3 DISEO DEL SISTEMA DE INFORMACIN (DSI)
El propsito del diseo del sistema de informacin es obtener la definicin

de la arquitectura del sistema y del entorno tecnolgico que le va ha dar soporte,
junto con la especificacin
detallada de los componentes del sistema de
informacin.
- 53 -
Este proceso consta de un primer bloque de actividades que se realizan en

paralelo, y cuyo objetivo es obtener el diseo de detalle del sistema de
informacin que comprende la particin fsica del sistema de informacin,
independiente
de
un
entorno tecnolgico
concreto, la
organizacin
en
subsistemas de diseo, la especificacin del entorno tecnolgico sobre el que se

despliegan dichos subsistemas y la definicin de los requisitos de operacin,
administracin del sistema, seguridad y control de acceso.
En el caso de diseo orientado a objetos, conviene sealar que se ha

contemplado que el diseo de la persistencia se lleva a cabo sobre bases de
datos relacionales.
Primer bloque de actividades se obtienen los siguientes productos:
Catlogo de requisitos.
Catlogo de excepciones.
Catlogo de normas para el diseo y construccin.
Diseo de la arquitectura del sistema.
Entorno tecnolgico del sistema.
Procedimientos de operacin y administracin del sistema.
Procedimientos de seguridad y control de acceso.
Diseo detallado de los subsistemas de soporte.
Modelo fsico de datos optimizado.
Asignacin de esquemas fsicos de datos a nodos.
Diseo Estructurado: Diseo de la arquitectura modular, Diseo de

interfaz de usuario.
Diseo Orientado a Objetos: Diseo de la realizacin de casos de

uso, Modelo de clases de diseo,
diseo, Diseo de interfaz de usuario.
- 54 -
Comportamiento de clases de
Al igual que en el proceso de Anlisis del Sistema de Informacin( ASI),

antes de proceder a la especificacin de los componentes, se realiza una
verificacin y validacin, con objeto de analizar la consistencia entre los distintos
modelos y formalizar la aceptacin del diseo de la arquitectura del sistema por
parte de los usuarios de Explotacin y Sistemas.
Segundo bloque de actividades complementa el diseo del sistema de

informacin para la construccin:
Las especificaciones de construccin de los componentes del sistema

(mdulos o clases, segn el caso) y de las estructuras de datos.
Los procedimientos de migracin y sus componentes asociados.
La definicin y revisin del plan de pruebas, y el diseo de las

verificaciones de los niveles de prueba establecidos.
El catlogo de excepciones que permite establecer un conjunto de

verificaciones relacionadas con el propio diseo o con la arquitectura del
sistema.
La especificacin de los requisitos de implantacin.
1.9.2.4 CONSTRUCCIN DEL SISTEMA DE INFORMCACIN (CSI)
El propsito de la construccin del sistema de informacin tiene como

objetivo la construccin y prueba los distintos componentes del Sistemas de
Informacin, y se escriben los manuales de usuario y de explotacin. Se realizan
las pruebas unitarias, de integracin y de sistema.
Se levantan los procedimientos de migracin y carga inicial de datos. si

procede, se prepara el entorno de construccin se implanta la Base de datos,
Crear tabla, herramientas, bibliotecas, puestos de trabajo, etc. Se codifican los
componentes, se realizan las pruebas unitarias, se verifica si los componentes
interactan correctamente a travs de sus interfaces, cubre la funcionalidad
- 55 -
establecida y los requisitos no funcionales (pruebas de integracin), se verifica la

integracin del sistema globalmente, como resultado de dicho proceso se obtiene:
Resultado de las pruebas unitarias.

Evaluacin del resultado de las pruebas de integracin.
Evaluacin del resultado de las pruebas del sistema.
Producto software:
Cdigo fuente de los componentes.

Procedimientos de operacin y administracin del sistema
Procedimientos de seguridad y control de acceso.
Manuales de usuario.
Especificacin de la formacin a usuarios finales.
Cdigo fuente de los componentes de migracin y carga inicial de
datos.
Procedimientos de migracin y carga inicial de datos.
Evaluacin del resultado de las pruebas de migracin y carga inicial
de datos.
1.9.2.5 IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS)
El propsito de la implantacin y aceptacin del sistema tiene como

objetivo principal la entrega y aceptacin del sistema en su totalidad y la
realizacin de las actividades necesarias para el paso a produccin: se prepara el
entorno
de
explotacin,
se
instalan
los
componentes,
se
activan
los
procedimientos manuales y automticos, se realiza la migracin o carga inicial de

datos, se realiza la prueba de implantacin, se realiza la prueba de aceptacin, se
prepara el mantenimiento, es muy comn que el desarrollo y mantenimiento sean
realizados por grupos distintos.
- 56 -
El usuario de operacin realiza las pruebas de implantacin, y el usuario

final realiza las pruebas de aceptacin, Es necesario que la persona que vaya a
asumir el mantenimiento conozca el sistema antes de su incorporacin al entorno
de produccin. Como resultado de este proceso se obtienen los siguientes
productos:
Plan de implantacin del sistema en su totalidad.

Equipo de implantacin que realizar la implantacin.
Plan de formacin del equipo de implantacin( esquema, materiales,
recursos necesarios, planificacin y especificacin de la formacin de
usuarios finales).
Evaluacin de las pruebas de implantacin del sistema por parte del
usuario de operacin.
Evaluacin de las pruebas de aceptacin del sistema por parte del usuario
final.
Plan de mantenimiento previo al paso a produccin.
Acuerdo de nivel de servicio del sistema.
Sistema en produccin.
1.9.3 MANTENIMIENTO DE SISTEMAS DE INFORMACIN (MSI)
El propsito de mantenimiento de sistema de informacin es obtener una

nueva versin de un Sistema de Informacin a partir de las peticiones de
mantenimiento de los usuarios.
Se considera dos tipos de mantenimiento que son mantenimiento correctivo

y mantenimiento evolutivo. Adems se analizan las alternativas de solucin, se
realizan las tareas necesarias para el desarrollo, se realizan las pruebas de
regresin y es muy importante registrar los cambios que se realizan en los
Sistemas de Informacin para documentar.
- 57 -
Como resultado de este proceso se obtiene los siguientes productos:
Catlogo de peticiones de cambio.

Resultado del estudio de la peticin
Propuesta de solucin.
Anlisis de impacto de los cambios.
Plan de accin para la modificacin.
Plan de pruebas de regresin.
Evaluacin del cambio.
Evaluacin del resultado de las pruebas de regresin.
1.10.- INTERFACES
La estructura de Mtrica VERSIN 3
incluye tambin un conjunto de
procesos que definen una serie de actividades de interfaz con otros procesos
organizativos o de soporte que en el caso de existir en la organizacin,
enriquecern o influirn en la ejecucin de las actividades de los procesos
principales de Mtrica VERSIN 3.
La aplicacin de MTRICA Versin 3 proporciona sistemas con calidad y

seguridad, no obstante puede ser necesario en funcin de las caractersticas del
sistema un refuerzo especial en estos aspectos, refuerzo que se obtendra
aplicando la interfaz. Las interfaces descritas en la metodologa son:
1.10.1 GESTIN DE PROYECTOS (GP)
Incluye una serie de actividades que se realizar en paralelo a las

actividades principales del ciclo de vida y que estn orientadas a los siguientes
aspectos: Planificacin incluye los calendarios para la terminacin oportuna de las
distintas actividades y tareas, la estimacin de esfuerzos, la asignacin de
responsabilidades, gestin de riesgos asociados a las distintas actividades o al
- 58 -
propio proyecto, medidas de control de calidad, etc., Ejecucin y control relativo al

seguimiento del proyecto, informes de progreso, resolucin de problemas, etc,
Revisin y evaluacin permite valorar los resultados obtenidos a partir de las
distintas actividades del proyecto.
1.10.2.- SEGURIDAD (SEG)
El anlisis de los riesgos constituye una pieza fundamental en el diseo y

desarrollo de sistemas de informacin seguros. Si bien los riesgos que afectan a
un sistema de informacin son de distinta ndole: naturales (inundaciones,
incendios, etc.) o lgicos (fallos propios, ataques externos, virus, etc.) son estos
ltimos los contemplados en la interfaz de Seguridad de MTRICA Versin 3.
El objetivo de la interfaz de seguridad es incorporar en los sistemas de

informacin mecanismos de seguridad adicionales a los que se proponen en la
propia metodologa, asegurando el desarrollo de cualquier tipo de sistema a lo
largo de los procesos que se realicen para su obtencin.
La interfaz de Seguridad hace posible incorporar durante la fase de
desarrollo las funciones y mecanismos que refuerzan la seguridad del nuevo
sistema y del propio proceso de desarrollo, asegurando su consistencia y
seguridad, completando el plan de seguridad vigente en la organizacin.
En consecuencia, la interfaz contempla dos tipos de actividades

diferenciadas: Actividades relacionadas con la seguridad intrnseca del sistema de
informacin, Actividades que velan por la seguridad del propio proceso de
desarrollo del sistema de informacin. Las valoraciones sobre la seguridad deben
realizarse en funcin de las caractersticas del sistema.
1.10.3.- GESTIN DE LA CONFIGURACIN (GC)
- 59 -
La interfaz de gestin de la configuracin consiste en la aplicacin de

procedimientos administrativos y tcnicos durante el desarrollo del sistema de
informacin y su posterior mantenimiento. Su finalidad es identificar, definir,
proporcionar informacin y controlar los cambios en la configuracin del sistema.
Este proceso permitir conocer el estado de cada uno de los productos que se
han definido como elementos de configuracin, garantizando que no se realizan
cambios incontrolados y que todos los participantes en el desarrollo del sistema
disponen de la versin adecuada de los productos que manejan.
La interfaz de gestin de configuracin permite definir las necesidades de

gestin de configuracin para cada sistema de informacin, recogiendo en un plan
de gestin de configuracin, en el que se especifican actividades de identificacin
y registro de productos, que se realizan durante todas las actividades de
desarrollo y mantenimiento del sistema de informacin. Tambin permite controlar
el sistema como producto global a lo largo de su creacin, obtener informes sobre
el estado de desarrollo en que se encuentra y reducir el nmero de errores
durante el mismo, lo que se traduce en un aumento de calidad del proceso de
desarrollo y de mejora de la productividad en la organizacin.
La gestin de configuracin facilita adems el mantenimiento del sistema,

aportando informacin precisa para valorar el impacto de los cambios solicitados y
reduciendo el tiempo de implementacin de un cambio, tanto evolutivo como
correctivo.
1.10.4 ASEGURAMIENTO DE LA CALIDAD (CAL)
Las actividades propias del Proceso de interfaz de Calidad en Mtrica

VERSIN 3
estn orientadas a verificar la calidad de los productos. Son
actividades que evalan la calidad y que son realizadas por un grupo de

Aseguramiento de la Calidad independiente de los responsables de la obtencin
de los mismos. Estas actividades de interfaz no entrarn en contradiccin con el
- 60 -
Plan General de Garanta de Calidad (PGGC), pero sern lo suficientemente

abiertas como para soportar una nueva versin del PGGC en el futuro.
Las actividades relativas a la Calidad Intrnseca del Producto son propias

de los Procesos principales de Mtrica VERSIN 3 , y no del Proceso de interfaz
de Calidad. Son actividades que previenen la falta de Calidad de los productos y
que son responsabilidad de quienes ejecutan las actividades para la obtencin de
los mismos. Las actividades contempladas en la interfaz de Aseguramiento de la
Calidad permitirn: Reducir, eliminar y prevenir las deficiencias de calidad de los
productos a obtener, Alcanzar una razonable confianza en que las prestaciones y
servicios esperados por el cliente o el usuario queden satisfechas.
1.11.- TECNICAS Y PRACTICAS

En el proceso de Desarrollo de Sistemas de Informacin se incluyen tanto
las tcnicas propias de un desarrollo orientado a objetos como estructurado, ya
que las actividades de ambas estn integradas en una estructura comn.
Se hace una distincin entre tcnicas y prcticas en funcin del propsito al
que respondan. Se considera tcnica al conjunto de procedimientos que se
apoyan en estndares, es decir, que utilizan trminos de sintaxis y semntica y
cumplen unos criterios de calidad. Las prcticas representan un medio para la
consecucin de unos objetivos especficos de manera rpida, segura y precisa,
sin necesidad de cumplir unos criterios o reglas preestablecidas.
En el caso de desarrollos orientados a objetos se ha seguido la notacin de

UML, es importante resaltar que la notacin que se propone en la aplicacin de la
tcnica en ningn caso se considerar obligatoria. Cada organizacin podr
utilizar la notacin que desee.
- 61 -
1.12.- PARTICIPANTES
MTRICA Versin 3 ha sido concebida para abarcar el desarrollo completo de
Sistemas de Informacin sea cual sea su complejidad y magnitud, por lo cual su
estructura y los perfiles de los participantes que intervienen debern adaptarse y
dimensionarse en cada momento de acuerdo a las caractersticas particulares de
cada proyecto.
- 62 -
- 63 -
CAPITULO II
II.- ESTANDARES IEEE DE CALIDAD
IEEE es el Instituto de Ingenieros en Electricidad, Electrnica y

Computacin, fundado en 1884, bajo su lema: Redes del mundo", est es ms
conocida como IEEE.
Cuenta con ms de 360.000 miembros aproximadamente en 175 pases,

produce el 30 por ciento de la literatura publicada en el mundo de la ingeniera
elctrica, computadoras y tecnologa de control, anualmente presenta mas de 300
conferencias importantes y tiene casi 900 estndares activos con 700 bajo
desarrollo.
2.1.- IMPORTANCIA DE LOS ESTNDARES IEEE

Los estndares IEEE son importantes porque:
Agrupan lo mejor y ms apropiado de las prcticas y usos del desarrollo de

software, evitando la repeticin de errores pasados
Engloban los conocimientos que son patrimonio de una organizacin
Proporcionan
un
marco
para
implementar
procedimientos
aseguramiento de la calidad
Proporcionan continuidad entre el trabajo de distintas personas
Proporciona un marco para el anlisis de calidad
[Ref 2.1]
- 64 -
de
2.2.- CONCEPTO DE IEEE

IEEE significa "Institute of Electrical and Electrnico Engineers" (Instituto de
Ingenieros Electrnicos y Electricistas). Asociacin de profesionales de la
ingeniera agrupados en diferentes comits para trabajar en diversas reas.
La IEEE es una asociacin profesional tcnica sin animo de lucro, la actual IEEE esta
relacionada con el desarrollo y publicacin de estndares que son generalmente
aceptados tanto para teora y prctica de la ingeniera elctrica, electrnica e
informtica.
[Ref 2.2]
2.3.- TIPOS DE ESTNDARES IEEE PARA LA INGENIERA DE

SOFTWARE
La IEEE, con el objetivo de fomentar la calidad en los productos han
desarrollado un sin nmero de estndares en diversas reas. Cada rea tiene
sus respectivos grupos de estndares, en este caso citaremos los estndares
para el rea de Ingeniera de software, los cuales pueden ser aplicados en todo
el ciclo del producto software, con la finalidad de obtener un software de calidad.
A continuacin se presenta los estndares IEEE:
- 65 -
ESTANDARES IEEE
ORD
NOMENCLATURA
NOMBRE
(INGLES)
FASE
(ESPAOL)
ESTNDAR IEEE PARA GLOSARIO DE
TERMINOLOGA DE INGENIERA DE
SOFTWARE
ANALISIS:
TERMINOLOGA
IEEE STD 610.12 - 1990

IEEE STANDARD GLOSSARY OF
(R2002)
SOFTWARE ENGINEERING
TERMINOLOGY
IEEE STD 730-2002
IEEE STANDARD FOR SOFTWARE

QUALITY ASSURANCE PLANS
(SQAP)
ESTNDAR IEEE PARA PLANES DE

ASEGURAMIENTO DE CALIDAD DE
SOFTWARE (SQAP)
DISEO:
CALIDAD
IEEE STD 828-1998

CONFIGURATION MANAGEMENT
PLANS (SCMP)

GESTIN DE CONFIGURACIN
SOFTWARE (SCMP)
CONSTRUCCIN:
CONFIGURACIN DE
SOFTWARE
IEEE STD 829-1998

TEST DOCUMENTATION
ESTNDAR IEEE PARA

DOCUMENTACIN DE PRUEBAS DE
SOFTWARE
DISEO:
CALIDAD
CONSTRUCCIN
PRUEBAS
IEEE STD 830-1998
IEEE RECOMMENDED PRACTICE

FOR SOFTWARE REQUIREMENTS
SPECIFICATIONS (ERS)
PRACTICA RECOMENDADA IEEE

PARA LA ESPECIFICACIN DE
REQUISITOS SOFTWARE (ERS)
ANALISIS:
REQUISITOS
IEEE STD 1008-1987

(R1993)

UNIT TESTING
ESTNDAR IEEE PARA PRUEBAS

UNITARIAS DE SOFTWARE
PRUEBAS
- 66 -
IEEE STD 1012-1998

VERIFICATION AND VALIDATION
(V&V)
ESTNDAR IEEE PARA LA

VERIFICACIN Y VALIDACIN DE
SOFTWARE (V&V)
DISEO:
CALIDAD
ESTANDARES IEEE
ORD
NOMENCLATURA
NOMBRE
(INGLES)
FOR SOFTWARE DESIGN
DESCRIPTIONS (SDD)
(ESPAOL)
PARA DESCRIBIR EL DISEO
SOFTWARE (SDD)
FASE
IEEE STD 1016-1998
IEEE STD 1058-1998

PROJECT MANAGEMENT PLANS
(SPMP)
ESTANDAR IEEE PARA PLANES DE

GESTIN DE PROYECTO SOFTWARE
(SPMP)
ANALISIS
10
IEEE STD 1061-1998
IEEE STANDARD FOR A SOFTWARE

QUALITY METRICS METHODOLOGY
ESTANDAR IEEE PARA UNA

METODOLOGIA DE METRICA DE
CALIDAD DE SOFTWARE
CONSTRUCCION
MANTENIMIENTO
11
IEEE STD 1062-1998

EDITION

FOR SOFTWARE ACQUISITION

PARA ADQUIRIR SOFTWARE
ANALISIS:
REQUISITOS
12
IEEE STD 1063-2001

USER DOCUMENTATION
ESTANDAR IEEE PARA

DOCUMENTACIN DE USUARIO DEL
SOFTWARE
DISEO:
CALIDAD
CONSTRUCCIN
PRUEBAS
13
IEEE STD 1219-1998

MAINTENANCE
ESTANDAR IEEE PARA

MANTENIMIENTO DE SOFTWARE
MANTENIMIENTO
- 67 -
DISEO
14
IEEE STD 1220-1998
IEEE STANDARD FOR THE

APPLICATION AND MANAGEMENT
OF THE SYSTEMS ENGINEERING
PROCESS (SEP)
ESTANDAR IEEE PARA APLICACIN Y

GESTION DE PROCESOS DE
INGENIERIA DE SISTEMAS (SEP)
INGENIERA DE
SISTEMAS
ESTANDARES IEEE
ORD
NOMENCLATURA
NOMBRE
FASE
(INGLES)
SAFETY PLANS
(ESPAOL)
SEGURIDAD DE SOFTWARE
IEEE STD 1233-1998

EDITION
IEEE GUIDE FOR DEVELOPING

SYSTEM REQUIREMENTS
SPECIFICATIONS (SyRS)
GUIA IEEE PARA DESARROLLO DE

ESPECIFICACION DE REQUISITOS DEL
SISTEMA (SyRS)
ANALISIS:
REQUISITOS
IEEE STD 1320.1-1998
IEEE STANDARD FOR FUNCTIONAL

MODELING LANGUAGESYNTAX
AND SEMANTICS FOR IDEF0
(INTEGRATED DEFINITION FOR
FUNCTION MODELING)
ESTNDAR IEEE PARA EL MODELO

FUNCIONAL LENGUAJE
SINTAXIS
Y SEMNTICA PARA IDEF0
(DEFINICIN INTEGRADA PARA EL
MODELO FUNCIONAL)
ANALISIS:
REQUISITOS
DISEO
15
IEEE STD 1228-1994
16
17
- 68 -
ANALISIS:
REQUISITOS
DISEO:
CALIDAD
PRUEBAS
18
IEEE STD 1320.2-1998
IEEE STANDARD FOR CONCEPTUAL

MODELING LANGUAGE SYNTAX
AND SEMANTICS FOR IDEF1X
(INTEGRATED DEFINITION FOR
DATA MODELING)
ESTNDAR IEEE PARA EL MODELO

CONCEPTUAL LENGUAJE
SINTAXIS Y SEMNTICA PARA IDEF1X
(DEFINICIN INTEGRADA PARA EL
MODELO DE INFORMACIN)
19
IEEE STD 1074-1997
IEEE STANDARD FOR DEVELOPING

SOFTWARE LIFE CYCLE
PROCESSES (SLCP)
ESTANDAR IEEE PARA DESARROLLO

DE PROCESOS DEL CICLO DE VIDA
DEL SOFTWARE (SLCP)
ANALISIS:
REQUISITOS
DISEO
ESTANDARES IEEE
ORD
20
NOMENCLATURA
IEEE STD 2001-2002
NOMBRE
(INGLES)
(ESPAOL)
FOR INTERNET PRACTICESWEB
PARA INTERNET INGENIERIA DE
PAGE ENGINEERING
PAGINAS WEB APLICACIONES
INTRANET/EXTRANET
INTRANET-EXTRANET
APPLICATIONS
- 69 -
FASE
Sistema de Inventario
Plan de Gestin de Configuracin del Software
GCS
Versin: 1.0
Fecha: 18/08/05
2.3.1.- DESCRIPCIPCIN DE ESTNDARES IEEE
IEEE STD 610.12 - 1990 (R2002)
ESTNDAR IEEE PARA GLOSARIO DE TERMINOLOGA DE INGENIERA

DE SOFTWARE
Resumen: Este estndar incluye los trminos desconocidos con sus

respectivos significados.
Palabras Claves: Ingeniera de Software, Glosario, Terminologa, Definicin,

Diccionario.
Fase:
Anlisis: Terminologa
CONTENIDO
1.- Estructura del Glosario
2.- Definiciones de Trminos
- 70 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 730 - 2002
ESTNDAR IEEE PARA PLANES DE ASEGURAMIENTO DE CALIDAD DE

SOFTWARE (SQAP)
Resumen: Este estndar especifica el formato y contenido del plan de

aseguramiento de calidad de software.
Palabras Claves: Seguridad, Calidad, Calidad de Software.
Fase:
Diseo: Calidad
CONTENIDO
1.- Plan de Aseguramiento de Calidad de Software

1.1.- Propsito
1.2.- Documentos de Referencia
1.3.- Administracin
1.4.- Documentacin
1.5.- Estndares, Prcticas y Mtricas
1.6.- Revisiones de Software
1.7.- Pruebas
1.8.- Reportes de Problemas y Acciones Correctivas
1.9.- Herramienta, Tcnica y Metodologa
1.10.- Control de Medios de Comunicacin
1.11.- Control de Proveedor
- 71 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.12.- Coleccin de Registros, Mantenimiento y Retencin

1.13.- Capacitacin
1.14.- Gestin de Riesgos
1.15.- Procedimiento de Cambio SQAP e Historia
IEEE STD 828 1998

ESTNDAR IEEE PARA PLANES DE GESTIN DE CONFIGURACIN SOFTWARE (SCMP)
Resumen: Este estndar establece los requerimientos mnimos y actividades

de los planes de gestin de configuracin software que ser realizado en
cualquier parte del ciclo de vida del producto software.
Palabras Claves: Control de Configuracin, Gestin de Configuracin

Software (SCM)
Fase:
Construccin: Configuracin de Software
CONTENIDO
1.- Plan de Gestin de Configuracin Software (SCMP)
1.1.- Introduccin
1.2.- Gestin SCMP
1.3.- Actividades SCMP
1.4.- Horario SCMP
1.5.- Recursos SCMP
1.6.- Plan de Mantenimiento SCMP
- 72 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD. 829 1998
ESTNDAR IEEE PARA DOCUMENTACIN DE PRUEBAS DE

SOFTWARE
Resumen: Este estndar describe una serie de documentos bsicos de
pruebas de software, especifica el formato y contenido del documento de
pruebas de forma individual.
Palabras Claves: Especificacin de Casos de Pruebas, Especificacin de

Diseo de Pruebas, Reportes de Incidentes de Pruebas, Registro de Pruebas,
Plan de Pruebas, Especificacin de Procesos de Pruebas, Reporte de
Resumen de Pruebas.
Fase:
Diseo: Calidad
Construccin
Pruebas
CONTENIDO
- 73 -
GCS
1.-
Versin: 1.0
Fecha: 18/08/05
Plan de Pruebas
1.1.- Propsito
1.1.1.- Identificacin del Plan de Pruebas
1.1.2.- Introduccin
1.1.3.- Items de Pruebas
1.1.4.- Caractersticas a ser Probadas
1.1.5.- Caractersticas a no ser Probadas
1.1.6.- Aproximacin
1.1.7.- Criterio de Item Pasa/Falla
1.1.8.- Criterios de Suspencin y Requisitos de Reanudacin
1.1.9.- Pruebas a Entregar
1.1.10.- Tareas de Pruebas
1.1.11.- Necesidades del Entorno
1.1.12.- Responsabilidades
1.1.13.- Necesidades del Personal y Capacitacin
1.1.14.- Horarios
1.1.15.- Riesgos y Contingencias
1.1.16.- Aprobacin
1.2.- Registro de Pruebas
- 74 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 830 - 1998

PRCTICA RECOMENDADA IEEE PARA LA ESPECIFICACIN DE
REQUISITOS SOFTWARE (ERS)
Resumen: Este estndar describe el formato y contenido de la especificacin

de requisitos software.
Palabras Claves: Especificacin de Requisitos Software, Especificacin de

Requisitos del Sistema.
Fase:
Anlisis: Requisitos
- 75 -
GCS
Versin: 1.0
Fecha: 18/08/05
CONTENIDO
1.- Partes del ERS
1.1.- Introduccin
1.1.1.-
Propsito
1.1.2.-
Alcance
1.1.3.-
Definicin, Siglas y Abreviaturas
1.1.4.-
Referencias
1.2.- Descripcin General

1.2.1.- Perspectiva del Producto
1.2.2.- Funciones del Producto
1.2.3.- Caractersticas del Usuario
1.2.4.- Restricciones
1.2.5.- Suposiciones y Dependencias
1.3.- Requisitos Especficos
1.3.1.- Requisitos Funcionales
1.3.2.- Requisitos de Interfaces Externas
1.3.3.- Requisitos de Redimiento
1.3.4.- Requisitos de Desarrollo
1.3.5.- Requisitos Tecnolgicos
1.3.6.- Atributos
IEEE STD 1008 - 1987 (R 2003)

ESTNDAR IEEE PARA PRUEBAS UNITARIAS DE SOFTWARE
Resumen: Este estndar proporciona una gua para desarrollar est prueba.
Palabras Claves: Casos de Pruebas, Plan de Pruebas, Conjunto de Pruebas,

Pruebas Unitarias.
- 76 -
GCS
Versin: 1.0
Fecha: 18/08/05
Fase:
Pruebas
CONTENIDO
1.- Plan de Pruebas Unitarias
1.1.- Fase de Perfeccionamiento del Plan de Pruebas
1.1.1.-
Aproximacin General del Plan, Recursos y Horarios
1.1.2.-
Caractersticas a ser Probadas
1.1.3.-
Desarrollo del Plan General
1.2.- Fase de Adquisicin: Conjunto de Pruebas

1.2.1.-
Disear el Conjunto de Pruebas
1.2.2.-
Ejecutar el Desarrollo del Plan y Diseo
1.3.- Fase de Medida: Pruebas Unitarias

1.3.1.-
Ejecutar los Procedimientos de Pruebas
1.3.2.-
Verificar la Terminacin
1.3.3.-
Evaluar el Esfuerzo de las Pruebas Unitarias
IEEE STD 1012 - 1998
ESTNDAR
IEEE
PARA
LA
VERIFICACIN
VALIDACIN
DE
SOFTWARE (V&V)
Resumen: Este estndar determina que el desarrollo del producto software

este conforme a los requisitos y satisface las necesidades del usuario.
- 77 -
GCS
Versin: 1.0
Fecha: 18/08/05
Palabras Claves: Integridad del Software, Procesos del Ciclo de Vida del
Software, Verificacin y Validacin.
Fase:
Diseo: Calidad
CONTENIDO
1.- Plan de Verificacin y Validacin de Software (SVVP)
1.1.- Propsito
1.2.- Definiciones
1.3.- Evaluacin V&V
1.3.1 Organizacin
1.3.2 Horario
1.3.3 Esquema de Integracin de Software
1.3.4 Resumen de Recursos
1.3.5 Responsables
1.3.6 Herramientas, Tcnicas y Mtodos
1.4.- Procesos de V&V
1.4.1 Proceso: Administracin
1.4.2 Proceso: Adquisicin
1.4.3 Proceso: Desarrollo
1.4.4 Proceso: Operacin
1.4.5 Proceso: Mantenimiento
1.5.- Reporte de Requisitos V&V
1.6.- Administracin de Requisitos V&V
1.7.- Documento de Requisitos V&V
- 78 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1016 - 1998
PRCTICA
RECOMENDADA
IEEE
PARA
DESCRIBIR
EL
DISEO
SOFTWARE (SDD)
Resumen: Este estndar describe el contenido y recomendaciones para organizar la

descripcin de diseo software, est prctica es aplicada en documentos, base de datos
automatizadas, lenguajes de descripcin de diseo.
Palabras Claves: Diseo de Software, Descripcin del Diseo Software.
Fase:
Diseo
CONTENIDO
1.- Consideraciones para Producir un SDD

1.1.- Ciclo de Vida de Software
1.2.-
SDD Dentro del Ciclo de Vida
1.3.-
Propsito de un SDD
2.- Contenido de Informacin de la Descripcin de Diseo

2.1.- Introduccin
2.2.- Entidades de Diseo
2.3.- Atributos de Entidad de Diseo
3.- Organizacin de la Descripcin del Diseo
3.1.- Introduccin
3.2.- Visin de Diseo
IEEE STD 1058 - 1998
- 79 -
GCS
ESTNDAR
IEEE
Versin: 1.0
Fecha: 18/08/05
PARA PLANES
DE
GESTIN
DEL
PROYECTO
SOFTWARE (SPMP)
Resumen: Este estndar describe el formato y contenido del plan de gestin

del proyecto software, se aplica a cualquier tipo o tamao de proyecto
software.
Palabras Claves: Plan de Gestin, Planes de Gestin del Proyecto Software

(SPMP).
Fase:
Anlisis
CONTENIDO
1.- Elementos del Plan de Gestin del Proyecto Software (SPMP)

1.1.- Antecentes
1.2.- Referencias
1.3.- Definiciones
1.4.- Organizacin del Proyecto
1.5.- Plan de Procesos de Gestin
1.6.- Plan de Procesos Tcnicos
1.7.- Plan de Procesos de Soporte
1.8.- Planes Adicionales
- 80 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1061 - 1998
ESTNDAR IEEE PARA UNA METODOLOGA DE MTRICA DE CALIDAD

DE SOFTWARE
Resumen: Este estndar crea requisitos de calidad e identifica, implementa,
analiza y valida el proceso, define la mtrica de calidad del producto software y
la metodologa expande el ciclo de vida del software.
Palabras Claves: Mtrica, Factor de Calidad.
Fase:
Construccin
Mantenimiento
CONTENIDO
1.- Metodologa de Mtrica de Calidad de Software
1.1.-
Establece Requisitos de Calidad de Software
1.2.-
Identifica la Mtrica de Calidad de Software
1.3.-
Implementa la Mtrica de Calidad de Software
1.4.-
Analiza los Resultados de la Mtrica de Software
1.5.-
Valida la Mtrica de Calidad de Software
- 81 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1062 1998 (R 2002)
PRCTICA RECOMENDADA IEEE PARA ADQUIRIR SOFTWARE
Resumen: Este estndar tiene un conjunto de prcticas de calidad admitidas

que pueden ser seleccionadas y aplicadas durante uno o ms pasos, en el
proceso de descripcin de adquisicin del software, puede ser aplicado a
cualquier software.
Palabras Claves: Adquirir, Ciclo de Vida de Adquisicin de Software, Proceso

de Adquisicin de Software.
Fase:
Anlisis: Requisitos
CONTENIDO
1.- Proceso de Adquisicin de Software
1.1.-
Ciclo de Vida de Adquisicin de Software
1.2.-
Nueve Pasos en Adquisicin de Calidad de Software
2.- Proceso de Adquisicin de Software

2.1.- Planeamiento de la Estrategia Organizacional
2.2.- Implementando Procesos de Organizacin
2.3.- Define los Requisitos de Software
2.4.- Identifica Proveedores Potenciales
- 82 -
GCS
Versin: 1.0
Fecha: 18/08/05
2.5.- Prepara Requisitos de Contrato

2.6.- Evaluando Propuestas y Seleccionando Proveedor
2.7.- Administracin de Ejecucin del Proveedor
2.8.- Aceptando el Software
2.9.- Utilizacin del Software
IEEE STD 1063 - 2001
ESTNDAR
IEEE
PARA
DOCUMENTACIN
DE
USUARIO
DEL
SOFTWARE
Resumen: Este estndar describe los requisitos mnimos para la estructura del
documento del usuario, incluye impresin y documento electrnico, usados por
los usuarios que trabajan en el sistema.
Palabras Claves: Ayuda en Lnea, Documentacin de Usuario del Software,

Manual de Usuario.
Fase:
Diseo: Calidad
Construccin
Pruebas
CONTENIDO
1.- Estructura del Documento del Usuario del Software

1.1.-
Estructura General del Documento
1.2.-
Componentes Iniciales
2.-
Contenido de Informacin del Documento del Usuario del Software
2.1.-
Contenido de Datos de Identificacin
- 83 -
GCS
Versin: 1.0
Fecha: 18/08/05
2.2.-
Informacin para Uso del documento
2.3.-
Concepto de Operacin
2.4.-
Informacin para Uso General del Software
2.5.-
Informacin para Procedimientos y Tutoriales
2.6.-
Informacin sobre Terminologa
2.7.-
Informacin sobre Fuentes de Informacin Relacionadas
3.-
Formato de Documentacin de Usuario del Software
3.1.-
Uso de Formato Impreso o Electrnico
3.2.-
Legibilidad
3.3.-
Formatos para Representar Elementos de Interfaces de Usuario
3.4.-
Formatos para Caractersticas del Documento para Acceder a la

Informacin
3.5.-
Formato para Caractersticas de Navegacin
- 84 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1074 - 1994 (R2002)
ESTNDAR IEEE PARA EL DESARROLLO DE PROCESO DEL CICLO DE

VIDA DEL SOFTWARE (SLCP)
Resumen: Este estndar desarrolla el proceso del ciclo de vida del software,
es dirigido principalmente a la arquitectura de procesos y es til para las
organizaciones que administran y ejecutan proyectos de software.
Palabras Claves: Ciclo de Vida de Software, Modelo de Ciclo de Vida del

Software, Procesos del Ciclo de Vida del Software.
Fase:
CONTENIDO
1.- Desarrollar un SLCP

1.1.- Informacin de Entrada
1.2.- Descripcin
1.3.- Informacin de Salida
- 85 -
GCS
Versin: 1.0
Fecha: 18/08/05
2.- Estimacin de Rendimiento

3.2.-
Descripcin
3.3.-
Informacin de Salida
3.- Recursos Asignados para el Proyecto

3.1.-
Informacin de Entrada
3.2.-
Descripcin
3.3.-
Informacin de Salida
4.- Mtrica Definida

4.2.- Descripcin
4.3.- Informacin de Salida
IEEE STD 1219 1998
ESTNDAR IEEE PARA MANTENIMIENTO DE SOFTWARE
Resumen: Este estndar describe la gestin y ejecucin de las actividades de

mantenimiento de software.
Palabras Claves: Ciclo de Vida, Mantenimiento, Software, Mantenimiento de

Software.
Fase:
Mantenimiento
CONTENIDO
1. Mantenimiento de Software
- 86 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.1.-
Identificacin de Problemas/Modificacin, Clasificacin y Ordenacin
1.2.-
Anlisis
1.3.-
Diseo
1.4.-
Implementacin
1.5.-
Prueba de Sistema
1.6.-
Prueba de Aceptacin
1.7.-
Entrega
IEEE STD 1220 1998
ESTNDAR IEEE PARA APLICACIN Y GESTIN DE PROCESOS DE INGENIERIA DE

SISTEMAS (SEP)
Resumen: Este estndar se enfoca en las actividades de ingeniera necesarias

para guiar el desarrollo y asegurar que el producto sea diseado
apropiadamente, para crear, operar y mantener evitando riesgos en la
aplicacin y gestin de ingeniera de sistemas.
- 87 -
GCS
Versin: 1.0
Fecha: 18/08/05
Palabras Claves: Componente, Hardware, Interconexin, Procesos del Ciclo

de Vida, Software, Sistema del Ciclo de Vida, Ingeniera de Sistemas.
Fase:
Ingeniera de Sistemas
CONTENIDO
1.-
Aplicacin de Ingeniera de Sistemas Durante el Ciclo de Vida del

Sistema
1.1.- Fase de Definicin de Sistema

1.2.- Fase de Diseo Preliminar
1.3.- Fase de Diseo Detallado
1.4.- Fabricacin, Ensamblaje, Integracin y Fase de Pruebas (FAIT)
1.5.- Produccin y Fase de Soporte del Cliente
1.6.- Ingeniera Simultanea de Procesos del Ciclo de Vida
2.-
Procesos del Sistema de Ingeniera (SEP)
2.1.- Anlisis de Requisitos

2.2.- Validacin de Requisitos
2.3.- Anlisis Funcional
2.4.- Verificacin Funcional
2.5.- Sntesis
2.6.- Verificacin de Diseo
2.7.- Anlisis del Sistema
2.8.- Control
- 88 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1228 - 1994 (R2002)
ESTNDAR IEEE PARA PLANES DE SEGURIDAD DE SOFTWARE

Resumen: Este estndar establece los requisitos mnimos y el contenido del
plan de seguridad de software, se aplica en el desarrollo, procedimiento y retiro
- 89 -
GCS
Versin: 1.0
Fecha: 18/08/05
del software, no incluye requisitos previos para usar el software en sistemas

distribuidos o procesos paralelos.
Palabras Claves: Seguridad, Software de Criterio, Plan de Seguridad de

Software, Programa de Seguridad de Software, Requisitos de Seguridad.
Fase:
Anlisis: Requisitos
Diseo: Calidad
Pruebas
CONTENIDO
1.- Plan de Seguridad de Software

1.1.- Propsito
1.2.- Definiciones, Acrnimos, Abreviaturas y Referencias
1.3.- Administracin de Seguridad de Software
1.3.1.-
Organizacin y Responsables
1.3.2.-
Recursos
1.3.3.-
Personal de Calidad y Capacitacin
1.3.4.-
Ciclo de Vida del Software
1.3.5.-
Requisitos de Documentacin
1.3.6.-
Registro de Programas de Seguridad de Software
1.3.7.-
Actividades de Gestin de Configuracin de Software
1.3.8.-
Actividades de Aseguramiento de Calidad Software
1.3.9.-
Actividades de Validacin y Verificacin de Software
1.3.10.-
Herramientas de Soporte y Aprobacin
1.3.11.-
Desarrollo Previo o Adquisicin de Software
1.3.12.-
Administracin de Subcontratos
1.3.13.-
Certificacin de Procesos
- 90 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.4.- Anlisis de Seguridad de Software

1.4.1.-
Preparacin de Anlisis de Seguridad de Software
1.4.2.-
Anlisis de Requisitos de Seguridad de Software
1.4.3.-
Anlisis de Diseo de Seguridad de Software
1.4.4.-
Anlisis de Cdigo de Seguridad de Software
1.4.5.-
Anlisis de Pruebas de Seguridad de Software
1.4.6.-
Anlisis de Cambios de Seguridad de Software
1.5.- Desarrollo Posterior

1.5.1.-
Capacitacin
1.5.2.-
Desarrollo
1.5.2.1
Instalacin
1.5.2.2
Inicio y Transmisin
1.5.2.3
Soporte de Operacin
1.5.3.-
Monitoreo
1.5.4.-
Mantenimiento
1.5.5.-
Retiro y Notificacin
1.6.- Aprobacin del Plan
IEEE STD 1233 1998 (R2002)
- 91 -
GCS
Versin: 1.0
Fecha: 18/08/05
GUA IEEE PARA DESARROLLO DE ESPECIFICACIN DE REQUISITOS

DEL SISTEMA (SyRS)
Resumen: Este estndar desarrolla un conjunto de especificaciones de
requisitos del sistema que satisfacen una necesidad, que
incluye la
identificacin, organizacin, presentacin y modificacin de requisitos, tambin

incluye las caractersticas necesarias y calidad en los requisitos individuales y
globales.
Palabras Claves: Requisitos, Especificacin de Requisitos del Sistema,

Sistema
Fase:
Anlisis: Requisitos
CONTENIDO
1.- Especificacin de Requisitos del Sistema (SyRS)

1.1.- Introduccin
1.1.1.-
Propsito del Sistema
1.1.2.-
Alcance del Sistema
1.1.3.-
Definiciones, Acrnimos y Abreviaturas
1.1.4.-
Referencias
1.1.5.-
Visin General del Sistema
1.2.- Descripcin General del Sistema

1.2.1.-
Contexto del Sistema
1.2.2.-
Modelo del Sistema y Fases
1.2.3.-
Alcance de Capacidad del Sistema
1.2.4.-
Alcance de Condiciones del Sistema
1.2.5.-
Alcance de Restricciones del Sistema
1.2.6.-
Caractersticas del Usuario
- 92 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.2.7.-
Suposiciones y Dependencias
1.2.8.-
Situacin Operacional
1.3.- Capacidad del Sistema, Condiciones y Restricciones

1.3.1.-
Fsica
1.3.1.1
Construccin
1.3.1.2
Durabilidad
1.3.1.3
Adaptabilidad
1.3.1.4
Condiciones del Entorno
1.3.2.-
Caractersticas de Ejecucin del Sistema
1.3.3.-
Seguridad del Sistema
1.3.4.-
Administracin del Sistema
1.3.5.-
Operacin del Sistema
1.3.5.1
Factor Humano del Sistema
1.3.5.2
Mantenimiento del Sistema
1.3.5.3
Confiabilidad del Sistema
1.3.6.-
Polticas y Reglas
1.3.7.-
Soporte del Ciclo de Vida del Sistema
1.4.- Interfaces del Sistema
- 93 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1320.1 1998

ESTNDAR IEEE PARA EL MODELO FUNCIONAL LENGUAJE SISTAXIS
Y SEMNTICA PARA IDEF0 (DEFINICIN INTEGRADA PARA EL MODELO
FUNCIONAL)
Resumen: Este estndar realiza el modelo funcional IDEF0 que es diseado
para representar las decisiones, acciones y actividades de una organizacin o
sistema. Para sistemas nuevos IDEF0 puede ser usado primero para definir los
requisitos y especificar funciones en los sistemas futuros, como base de est
arquitectura IDEF0 puede ser usada para disear una implementacin que
rena estos requisitos y ejecute estas funciones.
En sistemas existentes
IDEF0 puede ser usado para analizar las funciones que ejecuta el sistema y
realizar los registros de los recursos.
Palabras Claves: Empresa, Lenguaje, Lenguaje del Modelo Funcional, IDEF0
Fase:
Anlisis: Requisitos
Diseo
IEEE STD 1320.2 1998

ESTNDAR IEEE PARA EL MODELO CONCEPTUAL LENGUAJE
SINTAXIS Y SEMNTICA PARA IDEF1X (DEFINICIN INTEGRADA PARA
EL MODELO DE INFORMACIN)
Resumen: Este estndar consiste en dos lenguajes del modelo conceptual que
es lgico y fsico. El modelo conceptual IDEF1X soporta la implementacin de
- 94 -
GCS
Versin: 1.0
Fecha: 18/08/05
base de datos relacionadas, base de datos relacionadas extendidas, bases de

datos orientadas a objetos y lenguajes de programacin orientados a objetos.
Palabras Claves: Esquema Conceptual, Modelo de Datos, IDEF1X, Identidad de

Estilo, Modelo de Informacin, Modelo Orientado a Objetos.
Fase:
Anlisis: Requisitos
Diseo
IEEE STD 2001 - 2002

PRCTICA RECOMENDADA IEEE PARA INTERNET INGENIERA DE
PAGINAS WEB APLICACIONES INTRANET-EXTRANET
Resumen: Este estndar se basa en W3C(World Wide Web Consortium), est

prctica recomendada no realiza consideraciones de envos clsicos o factor
humano en la limitacin detrs del diseo de paginas web que refleja una
buena practica de ingeniera.
Palabras Claves: Extranet, Intranet, Pagina WEB, Sitios WEB, Ingeniera de

Sitios WEB, Ciclo de Vida del Sitio WEB, Administracin del sitio WEB, World
Wide Web.
VER ANEXO 2.1 Para ms Informacin de los Estndares
- 95 -
GCS
Versin: 1.0
Fecha: 18/08/05
2.4.- PORQUE ES IMPORTANTE IMPLEMENTAR ESTNDARES DE

CALIDAD EN EL SOFTWARE
Es importante implementar estndares de calidad en el software por la
competencia, ya que cada da es ms fuerte, es necesario que las empresas se
preocupen en dar un mejor producto. Pero la calidad del producto no solo se mide
al terminarlo. La complejidad de los problemas aumentado considerablemente hoy
en da buscan una solucin en el software. Pero este crecimiento ha sobrepasado
el aumento en la habilidad de desarrollar y mantener el software por parte de las
organizaciones dedicadas a desarrollarlo o mantenerlo.
Enfrentar una solucin con dos caras: Por una parte las organizaciones
quieren ser capaces de desarrollar y entregar software confiable, a tiempo y
apegado al presupuesto acordado con el cliente, la segunda cara de la moneda
nos muestra la perspectiva del cliente, el cual quiere saber con certeza que todo lo
anterior se cumplir. Por esto las organizaciones deben buscar una norma,
estndar, o modelo que pueda ayudar a conseguir una meta de calidad
(competitividad). Sin embargo, la competitividad no es la nica razn por la cual se
busca calidad en el software. Debemos darle importancia a cada programa que se
desarrolla, tomando conciencia y responsabilidad de las consecuencias que un
defecto en nuestro producto podra ocasionar. Algunos defectos de software han
ocasionando serios daos y hasta perjudicado fsicamente a personas. El
problema es que los sistemas cada vez son mas rpidos, mas complejos, y
automticos, la posibilidad de una falla catastrfica aumenta el potencial del dao
que podra ocasionar [PERROW; 84].
As que se debe saber distinguir entre simple y fcil. Un error simple no

necesariamente ser fcil de encontrar, por lo tanto todos estamos involucrados
en la calidad del producto, al ser responsables de la calidad de nuestro trabajo.
Otro aspecto negativo de los defectos es el econmico. Cada defecto representa
- 96 -
GCS
Versin: 1.0
Fecha: 18/08/05
un costo adicional. Un error identificado en la misma fase donde se produjo es

mucho ms barato de resolver que el mismo defecto en una fase posterior y an
ms caro si ste sale a la luz despus que el producto ya ha sido entregado.
Las siguientes razones son importantes para implementar un sistema de

calidad:
Satisfaccin del cliente

Competencia
Defectos
- 97 -
GCS
Versin: 1.0
Fecha: 18/08/05
CAPITULO III
III.
PROBLEMTICA DEL COMISARIATO DE LA

COOPERATIVA SAN ANTONIO
3.1 ANTECEDENTES DEL COMISARIATO DE LA COOPERATIVA
El comisariato de la cooperativa San Antonio es una institucin privada que

se encuentra ubicada en la provincia de Cotopaxi, cantn Latacunga sector Lasso,
se creo el 17 diciembre del 2002, gracias a la iniciativa de un grupo de socios que
creyeron que es necesario tener un comisariato en la institucin, en el que se
pueda adquirir los productos a crdito y con precios razonables.
En la actualidad cuenta con su propia infraestructura la cual es administrada

por dos personas que desempean sus funciones respectivamente atendiendo al
cliente y controlando el inventario.
Este presta servicios a todos los socios y clientes para satisfacer

oportunamente sus necesidades y expectativas, comprometindose en ofrecer
productos de calidad para atender a los consumidores, aportando de esta manera
a mejorar los niveles de vida y promover el desarrollo social y econmico de la
cooperativa. Como toda institucin tiene competencia sea esta grande o mediana
por esta razn es necesario estar renovados da a da en brindar ms y mejores
productos de alta calidad a inmejorables precios, pero sin descuidar al cliente.
- 98 -
GCS
Versin: 1.0
Fecha: 18/08/05
MISIN
Satisfacer las necesidades de los socios y clientes, al contar con productos de alta
calidad y contribuir activamente en la prestacin de servicio y bienestar de todos nuestros
socios y proveedores.
OBJETIVOS
Planificar los procesos de compra - venta de los productos a fin de

corregir errores de eficiencia y eficacia que aseguren los niveles de
ventas.
Valorar la calidad de los productos en forma continua a fin de determinar

que sea apto para el consumo humano
Controlar el inventario a fin de que los productos no se caduquen.
Actualmente el comisariato se desempea con normalidad en lo financiero y

comercial, en lo tecnolgico es necesario implementar un sistema de informacin para
poder automatizar los procesos que maneja el comisariato con lo cual se podr atender a los
socios y cliente con mayor rapidez y sobre todo contar siempre con la informacin
actualizada.
3.2 ESTUDIO DE LA SITUACIN ACTUAL DEL COMISARIATO

DE LA COOPERATIVA
- 99 -
GCS
Versin: 1.0
Fecha: 18/08/05
El comisariato de la cooperativa San Antonio es una institucin privada que se encuentra

ubicada en la provincia de Cotopaxi, cantn Latacunga sector Lasso, en la actualidad
cuenta con su propia infraestructura la cual es administrada por dos personas que
desempean sus funciones respectivamente atendiendo al cliente y controlando el
inventario.
Este presta servicios a todos los socios y clientes para satisfacer oportunamente sus
necesidades y expectativas, comprometindose en ofrecer productos de calidad para
atender a los consumidores, aportando de esta manera a mejorar los niveles de vida y
promover el desarrollo social y econmico de la cooperativa. Como toda institucin
tiene competencia sea esta grande o mediana por esta razn es necesario estar renovados
da a da en brindar ms y mejores productos de alta calidad a inmejorables precios, pero
sin descuidar al cliente.
La tecnologa en esta institucin es escasa ya que todos los procesos se los realiza
manualmente lo cual retrasa al cliente y causa un malestar por la perdida de tiempo.
La administracin preocupada por innovarse y ser mas competitivo ha decidido
incorporar tecnologa informtica y capacitar al recurso humano, ya que podr
automatizar todos los procesos que maneja, siendo un punto favorable para la institucin
por que ahorrara tiempo, costo y recursos, sobre todo mejorar la atencin.
3.3.- IMPORTANCIA DE LA AUTOMATIZACIN DEL INVENTARIO
Es importante automatizar para estar acorde con la tecnologa ya que este

milenio es, sin duda, uno de los puntos bsicos en los que se sustenta el
desarrollo de cualquier institucin.
conservan
Las ventajas que aporta la nueva tecnologa puede sintetizarse en los siguientes
aspectos:
- 100 -
GCS
Versin: 1.0
Fecha: 18/08/05
Atender a los clientes de manera eficiente, eficaz y sobretodo con mayor

rapidez
Tener informacin actualizada el momento que se lo requiera
La facturacin podr controlar la mercadera comprada y vendida, en
cantidad y precio
Evitar el aglutinamiento e inexistencia de mercadera
La informacin se presentar en forma impresa en pantalla y papel, el
momento que lo requieran
Los procesos son fciles, rpidos y eficientes
Controlara el stock de mercadera
Con esto podr ser ms competitivo y principalmente tener informacin

actualizada el momento que se lo requiera.
- 101 -
GCS
Versin: 1.0
Fecha: 18/08/05
CAPITULO IV
4. APLICACIN DE LOS ESTANDARES IEEE DE CALIDAD
EN EL DESARROLLO DEL SOFTWARE
4.1 PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI)
4.1.1 INICIO DEL PLAN DE SISTEMAS DE INFORMACIN
Analizada la situacin actual y las necesidades del personal del comisariato de la

Cooperativa San Antonio, se inicia el plan de sistemas de informacin que tendr en
cuenta los objetivos y metas de la organizacin en especial la del departamento del
comisariato, este proceso ser inmediato para poder dar soporte al departamento
administrativo del mismo, siendo el usuario el principal responsable del manejo
adecuado del sistema de informacin, este sistema ser manejable y fcil de utilizar para
obtener resultados favorables.
4.1.1.1 OBJETIVO GENERAL
Desarrollar un sistema de informacin que de soporte consistente y confiable al

comisariato utilizando estndares IEEE en el desarrollo del producto software con el que
el usuario se sienta satisfecho y seguro de la operabilidad.
- 102 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.1.1.2 OBJETIVOS ESPECIFICOS
Conocer los requerimientos de informacin de cada uno de los

departamentos.
Emplear tcnicas, mtodos y estrategias en la obtencin del sistema de

informacin.
Aplicar estndares IEEE para ingeniera de software en el proceso de

desarrollo del sistema de informacin.
4.1.1.3 IDENTIFICACIN DEL ALCANCE DEL PSI
El PSI se elabora para desarrollar un sistema de inventario, con la colaboracin del

personal que labora en el comisariato, este sistema manejar la informacin de socios,
artculos, proveedores, facturas de compra y venta, este controlar el stock de los
artculos y ser aplicado en el departamento del comisariato de la Cooperativa San
Antonio.
4.1.1.4 DETERMINACIN DE RESPONSABLES
AREA
Gerente
RESPONSABLE
Sr. Patricio Vega
Secretara Administrativa Srta. Carla Bermeo
DESCRIPCIN
Dirige la Cooperativa
Realiza todos los asuntos
administrativos que le asigna el
gerente.
Contabilidad
Sra. Carmen Escobar
- 103 -
Maneja el estado general de las
GCS
Versin: 1.0
Fecha: 18/08/05
cuentas.
Ahorros
Sra. Carmen Escobar
Guarda el dinero que aportan

los socios.
Crditos
Sra. Carmen Escobar
Otorga prestamos a los socios

que lo soliciten.
Cobranzas
Sra. Carmen Escobar
Recauda el dinero prestado a

los socios.
Recursos Humanos
Sr. Alberto Oa
Encargado de seleccionar el
personal.
Comisariato
Sr. Sandro Caizares
rea en la que se expende

varios artculos
Bodega
Sr. Sandro Caizares
Almacena y distribuye los

artculos en las perchas.
Adquisiciones
Sr. Sandro Caizares
Compra los artculos a los

proveedores.
Caja
Srta. Martha Prez
Factura la compra del socio.
GERENCIA
SECRETARIA
ADMINISTRATIVA
CONTABILIDAD
AHORROS
CREDITOS
RECURSOS
HUMANOS
COMISARIATO
COBRANZA
BODEGA
- 104 -
ADQUISICIONES
CAJA
GCS
Versin: 1.0
Fecha: 18/08/05
Fig. 4.1 Estructura Orgnica y Funcional de la Cooperativa San Antonio
4.1.2 DEFINICIN Y ORGANIZACIN DEL PSI
4.1.2.1 ESPECIFICACIN DEL MBITO Y ALCANCE
Para la especificacin del mbito y alcance se detalla la misin y visin que

tiene cada departamento que es parte de la cooperativa.
DEPARTAMENTO DE CONTABILIDAD
MISIN
Contribuir al desarrollo de las actividades financieras de la cooperativa, con la

prestacin de todos los servicios que est ofrece para satisfacer las necesidades de los
socios.
OBJETIVOS
Conocer el estado financiero de la cooperativa.
Proveer la informacin exacta para tomar decisiones y controlar.
Dar proteccin legal a los estados financieros.
- 105 -
GCS
Versin: 1.0
Fecha: 18/08/05
DEPARTAMENTO DE RECURSOS HUMANOS

MISIN
Reclutar, seleccionar, capacitar y desarrollar el desempeo del personal, manteniendo

el nmero adecuado de personas para promover la mejora de la calidad de vida
laboral, para que cumplan satisfactoriamente todas sus actividades.
OBJETIVOS
Mejorar el nivel de desempeo del personal que labora en la cooperativa.
Capacitar y motivar al personal para que cumpla su trabajo con calidad y

eficiencia.
Evaluar el desempeo del personal que labora en la cooperativa.

DEPARTAMENTO COMISARIATO
MISIN
Satisfacer las necesidades de los socios y clientes, al contar con productos de alta
calidad y contribuir activamente en la prestacin de servicio y bienestar de todos
nuestros socios y proveedores.
OBJETIVOS
- 106 -
GCS
Versin: 1.0
Fecha: 18/08/05
Planificar los procesos de compra - venta de los productos a fin de

corregir errores de eficiencia y eficacia que aseguren los niveles de
ventas.
Valorar la calidad de los productos en forma continua a fin de determinar

que sea apto para el consumo humano
Controlar el inventario a fin de que los productos no se caduquen.
El PSI ser aplicado al departamento del comisariato para desarrollar el sistema de

inventario.
4.1.2.2
ORAGANIZACIN DEL PSI
Para la organizacin del PSI se selecciona al personal del comisariato como

participantes, quienes colaborarn en el seguimiento y desarrollo del plan.
ORGANIZACIN DEL PSI

DESCRIPCIN
RESPONSABLE
Gerencia
Srta. Carla Bermeo
Personal Administrativo
Sr. Sandro Caizares
Equipo Tcnico
Gladys Aguagallo
Paulina Caizares
Equipo de Planeacin
Gladys Aguagallo
Paulina Caizares
- 107 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.1.2.3 DEFINICIN DEL PLAN DE TRABAJO
El plan de trabajo se realiza tomando en cuenta las principales actividades con el fin de
recolectar informacin con lo cul se ha podido establecer un cronograma de
actividades.
PLAN DE TRABAJO DEL PSI

ACTIVIDAD
Toma de informacin
RESPONSABLE
Equipo Tcnico
DURACIN
10 Das
Equipo de Planeacin
Aprobacin de la toma de
Gerencia
1 Da
informacin
Equipo Tcnico
Modelo E-R
Equipo Tcnico
1 Da
Evaluacin y aprobacin del
Equipo Tcnico
1 Da
Equipo Tcnico
5 Das
modelo E-R
Catalogacin de requisitos
Personal
Administrativo
Diagnostico de la situacin
Equipo Tcnico
- 108 -
1Da
GCS
Versin: 1.0
Fecha: 18/08/05
actual
Arquitectura tcnica necesaria
Equipo Tcnico
1 Da
Seleccin de arquitectura
Equipo Tcnico
1 Da
Gerencia
1 Da
tecnolgica
Aprobacin del plan
Personal
Administrativo Equipo
Tcnico
4.1.2.4 COMUNICACIN DEL PLAN DE TRABAJO
Se comunica al equipo de trabajo que participa en el desarrollo del PSI que el plan de
trabajo est aceptado por cada uno de los miembros. (Ver Anexo 4.1)
4.1.3 ESTUDIO DE LA INFORMACIN RELEVANTE
Debido a que no existe una planificacin previa al plan de sistemas de informacin no se

realiza, por lo que no se afecta a ningn proceso dentro del departamento del
comisariato.
- 109 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.1.4.- IDENTIFICACIN DE REQUISITOS
4.1.4.1.-
ESTUDIO DE LOS PROCESOS DEL PSI
Este estudio se realiza por medio de encuestas con el personal que labora en el
comisariato, con el fin de conocer los procesos que cada persona realiza. Con lo que se
identifica los requisitos y se elabora el modelo de informacin que representa las
distintas entidades y relaciones implicadas para el desarrollo del sistema. (Ver Anexo
4.2)
DEPARTAMENTO COMISARIATO
PROCESOS
RESPONSABLE
S
Con la lista de artculos faltantes en bodega

Selecciona al proveedor
Solicita los artculos que desea comprar al proveedor
Se fija la fecha de pago de la compra de los artculos con el
proveedor y el de adquisiciones
El proveedor entrega comprobante de compra de artculos
- 110 -
Adquisiciones
GCS
Versin: 1.0
Fecha: 18/08/05
Entrega lista de precios de los artculos al bodeguero para

que marque cada artculo con su respectivo precio
El de adquisiciones comunica al bodeguero que ya a
Bodeguero
realizado el pedido e indica la fecha que llegar el pedido

Llega el pedido y recibe el comprobante de la compra
realizada
Recibe el pedido
Verifica que estn todos los artculos que se han solicitado
con el comprobante de compra y firma
Ingresa los artculos a la bodega.
Registra los artculos ingresados a la bodega (cantidad y
precio)
Ordena los artculos en las estanteras para posteriormente
sacarlos a la venta en el comisariato
Luego verifica y registra que artculos faltan en las
estanteras del comisariato para sacar de la bodega
Marca el precio en los artculos
Lleva los artculos faltantes de la bodega a las estanteras del
comisariato para que sean vendidos
El socio toma los artculos que desea de las estanteras del
comisariato en la canasta
Va a la caja para facturar sus artculos el cliente
Realiza la factura de venta, registra datos personales y los
artculos adquiridos por el socio
Empaqueta los artculos facturados
Pregunta como ser el pago de la factura (contado o crdito)
al socio
Responde el socio (contado o crdito)
Firma la factura de venta el socio y la vendedora
- 111 -
Vendedora
GCS
Versin: 1.0
Fecha: 18/08/05
Entrega la copia de la factura de venta al socio
4.1.4.2.-
ANALISIS DE LAS NECESIDADES DE INFORMACIN
Para el anlisis de las necesidades de informacin se identifica cada una de

los procesos estudiados anteriormente. Se elabora un modelo conceptual con las
entidades y relaciones existentes entre procesos.
PROVEEDOR
ENTREGA
ARTICULOS
SO
N
VENDIDOS
AQUIEN
SOCIO
- 112 -
GCS
Versin: 1.0
Fecha: 18/08/05
El proveedor entrega una factura de compra de los artculos adquiridos, para que estos
sean recibidos y posteriormente sean vendidos, los artculos son vendidos a los socios y
se entrega una factura de venta.
4.1.4.3.- CATALOGACIN DE REQUISITOS
Para la catalogacin de requisitos se emplea la informacin obtenida en el estudio de los

procesos y anlisis de la necesidad de informacin.
Este catalogo asignara las prioridades de 1 a 3 siguiendo est tabla:
PRIORIDADES 1 A 3
PRIORIDAD
DESCRIPCIN
Primaria (porque es un requisito primordial para realizar los

siguientes pasos)
Secundario (porque depende de un requisito primario)
Opcional
(porque no es fundamental realizarlo)
Tabla. 4.1 Prioridades de 1 a 3
CATALOGO DE REQUISITOS
DESCRIPCION
ID PRIORIDAD
Gestin de Proveedor
- 113 -
GCS
Versin: 1.0
Fecha: 18/08/05
Gestin de Factura Compra (Proveedores)
Gestin de Artculo
Gestin de Socio
Gestin de Factura Venta (Socios)
4.1.5.- ESTUDIO DE LOS SISTEMAS DE INFORMACIN ACTUALES
El Comisariato de la Cooperativa San Antonio no cuenta con sistemas de informacin

por lo que no se realiza est actividad.
4.1.6.- DISEO DEL MODELO DE SISTEMAS DE INFORMACIN
4.1.6.1.-
DIAGNOSTICO DE LA SITUACION ACTUAL
Actualmente el comisariato realiza el manejo del inventario manualmente, por esta razn
no se puede tener la informacin el momento que as lo requiera la administracin, ya
que todo se tiene que constatar fsicamente, en el Kardex lo que resulta una perdida de
tiempo, en algunos casos se puede mezclar la informacin, ocasionando muchas veces
perdidas de tiempo y dinero. Por otro lado no poder saber con exactitud el stock
existente en la bodega causando algunas veces aglomeracin de Artculos, por no estar
al tanto de lo que se ha vendido y adquirido.
Para saber como est el comisariato se realiza la matriz FODA.
- 114 -
GCS
Versin: 1.0
Fecha: 18/08/05
MATRIZ FODA
FORTALEZAS
Experiencia de 3 aos
OPORTUNIDADES
Costos bajos en los artculos
Compra
Contar con clientes fijos
los
artculos
los
proveedores directos
Dar crditos a los socios
Tener crdito de los proveedores

Contar con toda clase de artculos
para
satisfacer
todas
las
necesidades de los socios

Dar un buen servicio a los socios
para conservarlos
DEBILIDADES
AMENAZAS
Falta de tecnologa por no contar
Cambios
con
tributaria
dispositivos
electrnicos
constantes
en
la
(ordenador)
Desastres naturales.
Precios no competitivos ya que no
Inflacin
existe otro comisariato cerca
(proveedores)
Impuntualidad del personal
Apertura
Manejar los procesos manualmente
(riesgo de no ser competitivo).
en
de
ley
los
precios
nuevos
mercados
dentro del comisariato

Actualmente el comisariato se desempea con normalidad en lo financiero y comercial,
en lo tecnolgico es necesario implementar un sistema de informacin para poder
automatizar los procesos que maneja el comisariato con lo cual se podr atender a los
socios y cliente con mayor rapidez y sobre todo contar siempre con la informacin
actualizada.
- 115 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.1.6.2.- DEFINICIN DEL MODELO DE SISTEMAS DE INFORMACIN DE LA

ORGANIZACIN
El comisariato viene desarrollando todas las actividades con normalidad ya que cada persona es responsable de su cargo,
estas actividades se las realiza manualmente, Al no contar con un sistema de informacin sistematizado, el personal que
labora aqu a expresado su necesidad de incorporar un sistema que respalde su trabajo y desempeo, y principalmente
satisfacer las necesidades de los miembros de la misma.
Para lo que se disea la estructura del sistema de inventario el que se aplicara en el comisariato.
SICOIN
GESTION
PROVEEDOR
GESTION
ARTCULO
GESTION
FACTURA COMPRA
GESTION
SOCIOS
GESTION
FACTURA VENTA
Fig. 4.2 Sistema de Inventario (Jerarqua)

Detalles del Sistema SICOIN (Sistema de inventario del Comisariato), este
sistema permitir saber cual es el stock de artculos existentes en bodega,
manejando las siguientes gestiones:
Gestin de Proveedor
Permitir realizar las funciones de ingresar, eliminar, modificar y consultar

en forma Individual o general, los datos de los proveedores que suministran los
artculos.
- 116 -
GCS
Versin: 1.0
Fecha: 18/08/05
Gestin de Artculos

en forma Individual o general, los artculos que se han adquirido para la venta en
el comisariato.
Gestin de Socios

en forma Individual o general, los datos de los socios que compran en el
comisariato.
Gestin de factura Compra

en forma Individual o general, las facturas de compra que se efectan con los
proveedores para la adquisicin de los artculos.
Gestin de factura Venta

en forma Individual o general, las facturas de venta que se efectan con el socio el
momento que sacan los artculos del comisariato.
4.1.7.- DEFINICIN DE LA ARQUITECTURA TECNOLGICA
- 117 -
GCS
Versin: 1.0
Fecha: 18/08/05
Se define la arquitectura tecnolgica que dar soporte al sistema que se desarrollara para
el comisariato.
Se requiere:
PC Pentium II o Superior
Impresora
Software de Aplicacin: PHP
Software Base: Sistema Operativo Windows (95,98,XP,Profesional)
Base de Datos: MYSQL
Servidor WEB: Apache
Cliente WEB: Microsoft Internet Explorer
4.1.8.- DEFINICIN DEL PLAN DE ACCIN
4.1.8.1.- DEFINICIN DE PROYECTOS A REALIZAR
ORD
FUNCIN
SISTEMA
Sistema de Inventario Este sistema permitir saber el stock de los

artculos que existe en la bodega del
comisariato.
4.1.8.2.- REVISIN Y APROBACIN DEL PSI

- 118 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para la revisin y aprobacin del PSI se rene el equipo de trabajo que participo en el
desarrollo de este plan para aprobar (Ver Anexo 4.3)
4.2.- ESTUDIO DE VIALIDAD DEL SISTEMA (EVS)
4.2.1.- ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA
Para establecer el alcance del sistema, se estudia la necesidad del usuario, que est en la
PSI que se realizo anteriormente.
4.2.1.1.- ESTUDIO DE LA SOLICITUD
Una vez realizada la PSI se puede describir en forma general la necesidad que tiene el
comisariato, este necesita un sistema de inventario que maneje la informacin de socios,
artculos, proveedores y facturas, tanto de compra de artculos a proveedores y venta de
artculos a socios, controlar el stock de todos los artculos que se encuentran en la
bodega.
- 119 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.2.2.- IDENTIFICACIN DEL ALCANCE DEL SISTEMA
El sistema de inventario a desarrollarse ser aplicado en el departamento del comisariato

de la Cooperativa San Antonio.
4.2.3.- ESPECIFICACION DEL ALCANCE DEL EVS
Para realizar la especificacin del alcance del EVS, se selecciona a los participantes del
personal del comisariato, quienes colaboraran para desarrollar el EVS.
PLAN DE TRABAJO DEL EVS

ACTIVIDAD
Identificacin de Requisitos
RESPONSABLE
Equipo Tcnico
DURACIN
20 Das
Catalogacin de Requisitos
Equipo Tcnico
5 Das
Descripcin de alternativa de
Equipo Tcnico
2 Das
solucin
- 120 -
GCS
Estudio de Inversin
Versin: 1.0
Fecha: 18/08/05
Equipo Tcnico
5 Das
4.2.4.- ESTUDIO DE LA SITUACIN ACTUAL
Debido a que no existen sistemas de informacin no se realiza el estudio de la situacin

actual, teniendo en cuenta que los procesos se los hace manualmente, por lo que no se
afecta a ningn proceso dentro del departamento del comisariato.
4.2.5.- DEFINICIN DE REQUISITOS DEL SISTEMA
4.2.5.1.-
IDENTIFICACIN DE LAS DIRECTRICES TCNICAS Y DE

GESTIN
El comisariato no cuenta con ninguna directriz tcnica y de gestin para desarrollar

sistemas ya que no tiene ninguna planificacin de sistemas de informacin.
4.2.5.2.-
IDENTIFICACION DE REQUISITOS
Para identificar los requisitos se ha realizado varias sesiones de trabajo con los
participantes, identificando los siguientes requisitos:
Control de Acceso
- 121 -
GCS
Versin: 1.0
Fecha: 18/08/05
Gestin de Proveedor
Req(01) Ingresar un nuevo Proveedor.
Req(02) Eliminar una Proveedor.
Req(03) Modificar los datos de un Proveedor.
Req(04) Consultar los Proveedores en forma general.
Req(05) Consultar los Proveedores en forma individual.
Gestin de Artculos
Req(06) Ingresar un nuevo Artculo.
Req(07) Eliminar un Artculo.
Req(08) Modificar los datos de un Artculo.
Req(09) Consultar los Artculos en forma general.
Req(010) Consultar los Artculos en forma individual.
Gestin de Socios
Req(11) Ingresar un nuevo Socio.
Req(12) Eliminar un Socio.
Req(13) Modificar los datos de un Socio.
Req(14) Consultar los Socios en forma general.
Req(15) Consultar los Socios en forma individual.
Gestin de Factura Compra (Proveedor)
Req(16) Ingresar una nueva Factura Compra.
Req(17) Eliminar un Factura Compra.
Req(18) Modificar los datos de una Factura Compra.
Req(19) Consultar las Facturas Compras en forma general.
Req(20)
Consultar
las
Facturas
Compras
en
individual.
Gestin de Factura Venta (Socio)
Req(21) Ingresar una nueva Factura Venta.
Req(22) Eliminar un Factura Venta.
Req(23) Modificar los datos de una Factura Venta.
- 122 -
forma
GCS
Versin: 1.0
Fecha: 18/08/05
Req(24) Consultar las Facturas Ventas en forma general.

Req(25) Consultar las Facturas Ventas en forma individual.
4.2.5.3.- CATALOGACION DE REQUISITOS
Para la catalogacin de requisitos se emplea la informacin obtenida en la identificacin

de requisitos, y para identificar la prioridad se utiliza la tabla 4.1
CATALOGO DE REQUISITOS
DESCRIPCION
ID PRIORIDAD
Control de Acceso
Men Principal
Gestin de Proveedor
Ingresar Proveedor: cdigo, nombre, apellido, direccin,
telfono, descripcin, distribuidor.
Eliminar Proveedor: seleccionar uno, comprobar que no exista

factura compra, verificar datos y elimina.
Modificar Proveedor: seleccionar uno, verificar datos y modifica.
Consulta general de Proveedor: despliega lista de proveedores.
Consulta individual de Proveedor: seleccionar uno, despliega

informacin.
Gestin de Artculo
10
Ingresar Artculo: cdigo, nombre, stock, valor de venta.
11
Eliminar Artculo: seleccionar uno, comprobar que no exista

factura compra, verificar datos y elimina.
12
Modificar Artculo: seleccionar uno, verificar datos y modifica.
13
Consulta general de Artculo: despliega lista de artculo.
- 123 -
GCS
14
Versin: 1.0
Fecha: 18/08/05
Consulta individual de Artculo: seleccionar uno, despliega

informacin.
15
Gestin de Socio
16
Ingresar Socio: cdigo, cdula, nombre, apellido, direccin.
17
Eliminar Socio: seleccionar uno, comprobar que no exista

factura venta, verificar datos y elimina.
18
Modificar Socio: seleccionar uno, verificar datos y modifica.
19
Consulta general de Socio: despliega lista de socio.
20
Consulta individual de Socio: seleccionar uno, despliega

informacin.
21
Gestin de Factura Compra (Proveedores)
22
Ingresar Factura Compra: nmero de factura, fecha de emisin,

fecha de vencimiento, detalle, cantidad, suma total, iva, valor
total, estado.
23
Eliminar Factura Compra: seleccionar uno, comprobar que no

exista artculo y proveedor, verificar datos y elimina.
24
Modificar Factura Compra: seleccionar uno, verificar datos y

modifica.
25
Consulta general de Factura Compra: despliega lista de factura

compra.
26
Consulta individual de Factura Compra: seleccionar uno,

despliega informacin.
27
Gestin de Factura Venta (Socios)
28
Ingresar Factura Venta: nmero de factura, fecha de emisin,

fecha de vencimiento, detalle, cantidad, suma total, iva, valor
total, estado.
29
Eliminar Factura Venta: seleccionar uno, comprobar que no

exista artculo y socio, verificar datos y elimina.
30
Modificar Factura Venta: seleccionar uno, verificar datos y
- 124 -
GCS
Versin: 1.0
Fecha: 18/08/05
modifica.
31
Consulta general de Factura Venta: despliega lista de factura

venta.
32
Consulta individual de Factura Venta: seleccionar uno,

despliega informacin.
4.2.6.- ESTUDIO DE ALTERNATIVAS DE SOLUCIN
4.2.6.1.- PRESENTACION DE ALTERNATIVA DE SOLUCIN
Una vez identificados y analizados los requisitos del sistema, se propone la alternativa
de solucin, para desarrollar el producto software que en este caso es un Sistema de
Inventario que se manejar dentro del comisariato, que ser desarrollado en PHP como
software de aplicacin, Sistema Operativo Windows como software base, Interfaces
diseadas en Dreamweaver MX 2004, gestor de Base de Datos MYSQL, Servidor WEB
Apache y Cliente WEB Microsoft Internet Explorer.
4.2.6.2.- DESCRIPCIN DE LA ALTERNATIVA DE SOLUCIN
La alternativa de solucin para desarrollar el Sistema de Inventario (SICOIN) es:
Metodologa de desarrollo: Mtrica V3 orientada a objetos
- 125 -
GCS
Versin: 1.0
Fecha: 18/08/05
Software de Aplicacin: PHP por ser un lenguaje que soporta scripting para la
creacin de WEBSITE, ser multiplataformas y bases de
datos mltiples.
Servidor WEB: Apache por ser el ms utilizado en el mundo y provee seguridad y
eficiencia
Cliente WEB: Microsoft Internet Explorer
Base de Datos: MYSQL por integrarse con PHP y consumir pocos recursos del CPU
y memoria, adems por ser orientada a la WEB y por su velocidad.
Interfaces: Dreamweaver MX 2004
Software Base: Sistema Operativo Windows (95,98,XP, Profesional).
4.2.7.- VALORACION DE ALTERNATIVAS
4.2.7.1.-
ESTUDIO DE LA INVERSIN
Para realizar el estudio de la inversin se valora el impacto en la organizacin y se

establece su viabilidad econmica.
RAZN
CANTIDAD
Ingenieros
2
100
VALOR
COSTO TOTAL
1200,oo
2400,oo
Cd
1.50
3,oo
Papel bon
0.01
1,oo
- 126 -
GCS
Versin: 1.0
Fecha: 18/08/05
Carpetas
0.15
0,75
Esferos
.020
0,80
Borradores
0.10
0,20
Cuaderno
1,oo
1,oo
Cartuchos de tinta
25,oo
50,oo
2456,75
TOTAL PARCIAL
HARDWARE
COSTO TOTAL
Computadora
1400,oo
Impresora
95,oo
1495,oo
TOTAL PARCIAL
SOFTWARE
COSTO TOTAL
Windows 98
250,oo
PHP
---------
MYSQL
---------
APACHE
---------
Dreamweaver MX 2004
---------
TOTAL PARCIAL
250,oo
TOTAL DEL PROYECTO
4201,75
4.2.8.- SELECCIN DE LA SOLUCIN
Para presentar la solucin se rene el equipo de trabajo que participo en el desarrollo de

EVS para aprobar est alternativa para el desarrollo del sistema de inventario (SICOIN)
en el comisariato (Ver Anexo 4.4)
- 127 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.3.- ANALISIS DEL SISTEMA DE INFORMACIN (ASI)
4.3.1.- DEFINICIN DEL SISTEMA
4.3.1.1.- DETERMINACIN DEL ALCANCE DEL SISTEMA
El sistema de inventario controlara los datos de stock de Compra y ventas, el mismo que
ser aplicado en el departamento del comisariato de la cooperativa San Antonio.
4.3.1.2.- IDENTIFICACIN DEL ENTORNO TECNOLGICO
El entorno tecnolgico que se requiere para el desarrollo del sistema de inventario es:
Hardware
Impresora
Metodologa de Desarrollo
Mtrica V3 Orientada a Objetos.
Sistema Base
- 128 -
GCS
Versin: 1.0
Fecha: 18/08/05
Sistema Operativo WINDOWS (95,98,XP,Profesional)

Software de Aplicacin
PHP
Servidor WEB
APACHE
Cliente WEB
Microsoft Internet Explorer
Base de Datos
MYSQL
Interfaces
Dreamweaver MX 2004
4.3.1.3.- ESPECIFICACIN DE ESTANDARES Y NORMAS
Los estndares que se aplicara en el ASI son los siguientes:
Estndar IEEE 1320.2 1998 (Estndar IEEE para el Modelo Conceptual Lenguaje Sintaxis y Semntica para IDEF1X (Definicin Integrada para el Modelo de
Informacin))
- 129 -
GCS
Versin: 1.0
Fecha: 18/08/05
Estndar IEEE 830 1998 (Estndar IEEE Prctica Recomendada para la Especificacin
de Requisitos Software (ERS))
Estndar IEEE 1008 1997 R2003 (Estndar IEEE para Pruebas Unitarias de Software
4.3.1.4.- IDENTIFICACIN DE LOS USUARIOS PARTICIRANTES Y FINALES
PLAN DE TRABAJO DEL ASI

ACTIVIDAD
Establecimiento de Requisitos
RESPONSABLE
Equipo Tcnico
DURACIN
10 Das
Identificacin de Subsistemas
Equipo Tcnico
1 Das
Anlisis de los casos de uso
Equipo Tcnico
10 Das
Anlisis de clases
Equipo Tcnico
10 Das
Elaboracin del modelo de
Equipo Tcnico
5 Das
Equipo Tcnico
---------
Equipo Tcnico
4 Das
de Anlisis
datos
Elaboracin del modelo de
procesos
Definicin de interfaces de
- 130 -
GCS
Versin: 1.0
Fecha: 18/08/05
usuario
Anlisis de consistencia y
Equipo Tcnico
20 Das
Equipo Tcnico
10 Das
especificacin de requisitos
Especificacin del plan de
pruebas
Aprobacin del ASI
Gerencia
1 Das
Equipo Tcnico
4.3.2.- ESTABLECIMIENTO DE REQUISITOS
4.3.2.1.- OBTENCIN DE REQUISITOS
Para obtener los requisitos del sistema de inventario (SICOIN) del comisariato, se
realiza la Especificacin de Requisitos de Software (ERS).
A continuacin se realiza el Modelo Conceptual, Diagrama de Casos de Uso y la

Definicin de Casos de Uso de Alto Nivel utilizando la herramienta Rational Rose
(UML)
- 131 -
GCS
Versin: 1.0
Fecha: 18/08/05
MODELO CONCEPTUAL DEL SISTEMA
- 132 -
GCS
Versin: 1.0
Fecha: 18/08/05
Proveedor
Factura venta detalle
1
1..*
Incluye
1
Tiene
Almacena
1..*
1..*
Factura compra
Articulo
1
Factura venta
1..*
1..*
Adquiere
Contiene
Registra
1..*
1
Socio
Factura compra detalle

1
- 133 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE CASOS DE USO
Consultar socio
Ingresar proveedor
Modificar socio
Eliminar proveedor
Eliminar socio
Ingresar socio
Modificar datos proveedor

Consulta factura venta
Consultar proveedor
Modificar factura venta
Ingresar factura compra

Eliminar factura venta
Eliminar factura compra
Administrador
Ingresar factura venta
Modificar factura compra
Consultar factura venta detalle
Consultar factura compra
Modificar factura venta

Ingresar factura compra detalle
Eliminar factura venta

Eliminar factura compra detalle
Ingresar factura venta

Modificar factura compra detalle
Ingresar articulo
Consultar proveedor
Modificar articulo
Consultar factura compra detalle
Eliminar articulo
- 134 -
GCS
Versin: 1.0
Fecha: 18/08/05
DEFINICIN DE COSOS DE USO DE ALTO NIVEL
Gestin de Artculo
Caso de uso
: Ingresar artculo
Actores
: Administrador
Tipo
: Primario
Descripcin
: Administrador solicita operacin de ingresar artculo, el
sistema presenta la pantalla de ingreso de artculo, el Administrador ingresa

datos solicitados en la pantalla, termina caso de uso
Caso de uso
: Eliminar artculo
Actores
: Administrador
Tipo
: Primario
Descripcin
: Administrador solicita operacin eliminar artculo, el sistema
presenta la pantalla de eliminar artculo, el Administrador selecciona el artculo

a eliminar, el sistema presenta los datos del artculo seleccionado, el
Administrador verifica que los datos corresponden al artculo, confirma
operacin, termina caso de uso.
Caso de uso
: Modificar artculo
Actores
: Administrador
Tipo
: Primario
Descripcin
: Administrador solicita operacin de modificar artculo, el
sistema presenta la pantalla de modificar artculo, el Administrador selecciona

el artculo a modificar, el sistema presenta los datos del artculo seleccionado,
el Administrador modifica los datos del producto, confirma operacin, termina
caso de uso.
Caso de Uso
: Consultar artculo
- 135 -
GCS
Versin: 1.0
Fecha: 18/08/05
Actores
: Administrador
Tipo
: Primario
Descripcin
: Administrador solicita la operacin de consultar artculo, el
sistema presenta la pantalla consulta artculo, el Administrador selecciona un

artculo, el sistema presenta los datos del artculo seleccionado, confirma
operacin, terminar caso de uso.
4.3.2.2.- ESPECIFICACIN DE CASOS DE USO
Para la especfica de casos de uso se utiliza la informacin anterior, con lo que se puede
desarrollar los escenarios:
CICLO 1
GESTIN DE ARTCULO
Ingresar Artculo
Eliminar Artculo
Modificar Artculo
Consultar Artculo
CASO DE USO
Caso de Uso : Ingresar Artculo

Actores
: Administrador (Iniciador)
Propsito
: Ingresar un artculo en el sistema.
Visin General : El Administrador solicita la operacin de ingresar artculo, el

sistema presenta el formulario de ingreso de artculo, el administrador
- 136 -
GCS
Versin: 1.0
Fecha: 18/08/05
ingresa uno a uno los datos del artculo, sistema almacena los datos y
confirma la operacin.
Tipo
: Primario, real.
Referencias
Curso Tpico de Eventos

Accin del Actor
Respuesta del Sistema
1. Este caso de uso comienza
2. Presenta formulario de ingreso de
cuando un administrador solicita la
artculo
operacin de ingresar artculo

3. Ingresa uno a uno los datos del
4. Almacena los datos del artculo y
artculo.
confirma la operacin.
Cursos Alternativos
Lnea 2: No existe formulario, termina el caso de uso.
Lnea 4: Existe artculo termina caso de uso.
CONTRATOS DE OPERACIN
Nombre
: Seleccionar ingresar artculo(op)
Responsabilidades : Presentar formulario de ingreso de artculo

Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso Ingresar_artculo, diagrama de secuencia
Ingresar_ artculo.
Notas
Excepciones
: No existe formulario.
Salida
Pre-condiciones
: Exista sesin activa.
Post-condiciones
: Ninguna
- 137 -
GCS
Nombre
Versin: 1.0
Fecha: 18/08/05
: Ingresar datos del artculo(lista de datos)
Responsabilidades : Permitir al administrador el ingreso del artculo

Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso Ingresar_ artculo,
diagrama de
secuencia Ingresar_ artculo.

Notas
Excepciones
: Existe artculo.
Salida
Pre-condiciones
: Administrador ingreso datos en campo de formulario
Post-condiciones : Se crea una instancia de tipo artculo.
CASO DE USO
Caso de Uso : Eliminar Artculo

Actores
: Administrador
Propsito
: Eliminar un Artculo en el sistema.
Visin general : El Administrador solicita la operacin de eliminar artculo, el

sistema presenta la lista de artculos, Administrador selecciona un artculo de
la lista, sistema presenta los datos del artculo, Administrador confirma
operacin de eliminacin.
Tipo
: Primario, real.
Referencias :
Accin del Actor
1. Este caso de uso comienza cuando
2. Presenta la lista de artculos
un administrador solicita la operacin

de eliminar artculo
3.Selecciona un artculo de la lista
- 138 -
4.Presenta los datos del artculo
GCS
Versin: 1.0
Fecha: 18/08/05
seleccionada
5. Verifica datos
6. Confirma operacin
CURSOS ALTERNATIVOS
Lnea 2: No existe lista de artculos, termina el caso de uso.
Lnea 4: No existe datos de artculo seleccionada termina caso de uso.
Nombre
: Seleccin de operacin eliminar artculo(op)
Responsabilidades : Presentar formulario de eliminar artculo

Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso eliminar_artculo, diagrama de secuencia
eliminar_artculo.
Notas
Excepciones : No Existe Formulario de eliminar artculo
Salida
Pre-condiciones
: Debe existir formularios de eliminar artculo
Post-condiciones
: Ninguna
Nombre
: Seleccionar un artculo (lista)
Responsabilidades : Presentar Datos del artculo

Tipo
: Sistema.
Ref. Cruzadas
eliminar_artculo.
Notas
Excepciones
: No Existe datos de artculo
Salida
Pre-condiciones
: Debe existir artculo
Post-condiciones
: Ninguna
- 139 -
GCS
Versin: 1.0
Fecha: 18/08/05
Nombre
: Confirmar operacin
Responsabilidades : Eliminar artculo del sistema
Tipo
: Sistema.
Ref. Cruzadas
eliminar_artculo.
Notas
Excepciones
Salida
Pre-condiciones
Post-condiciones
: Se elimina una instancia de tipo artculo
CASO DE USO
Caso de Uso : Modificar Artculo

Actores
: Administrador
Propsito
: Modificar datos de un artculo en el sistema.
Visin general : El administrador solicita la operacin de modificar datos del

artculo, el sistema presenta la lista de artculos, administrador selecciona
una de la lista, sistema presenta los datos del artculo, administrador modifica
los datos uno a uno y confirma operacin de modificacin.
Tipo
: Primario, real.
Referencias :
Accin del Actor
Este caso de uso comienza cuando
2. Presenta la lista de los artculos
el administrador solicita la operacin

de modificar artculo
3.Selecciona una de la lista
4.Presenta los datos del artculo
- 140 -
GCS
Versin: 1.0
Fecha: 18/08/05
seleccionado
5. Modifica los datos del artculo
6. Confirma operacin
CURSOS ALTERNATIVOS
Lnea 2: No existe lista del artculo termina casos de uso.
Lnea 4: No existe datos del artculo seleccionada termina caso de uso.
CONTRATO DE OPERACIN
Nombre
: Seleccin de operacin Modificar artculo(op)
Responsabilidades : Presentar formulario de modificar artculo

Tipo
: Sistema.
Caso de uso
modificar_artculo,
diagrama
de
secuencia
modificar_artculo.
Notas
Excepciones
: No existe Formulario de modificar artculo
Salida
Pre-condiciones
: Debe existir formularios de modificar artculo
Post-condiciones
: Ninguna
Nombre
: Seleccionar un artculo(lista)

Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso modificar_artculo,
secuencia modificar_artculo.
Notas
Excepciones
: No Existe datos de artculo
Salida
Pre-condiciones
Post-condiciones : Ninguna
- 141 -
diagrama de
GCS
Versin: 1.0
Fecha: 18/08/05
Nombre
: Modificar datos del artculo
Responsabilidades : Presentar Datos del artculo a ser modificados
Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso modificar_artculo, diagrama de
secuencia modificar_artculo.
Notas
Excepciones : No Existe datos de artculo
Salida
Pre-condiciones
Post-condiciones
: Ninguna
CASO DE USO
Caso de Uso : Consultar Artculo

Actores
: Administrador
Propsito
: Consultar datos de un artculo en el sistema.
Visin general : El administrador solicita la operacin de consultar datos del

artculo, el sistema presenta la lista del artculo, administrador selecciona un
artculo de la lista, sistema presenta los datos del artculo, administrador
confirma operacin de consulta.
Tipo
: Primario, real.
Referencias :

Accin del Actor
1. Este caso de uso comienza cuando

el administrador solicita la operacin
- 142 -
2. Presenta la lista del artculo
GCS
Versin: 1.0
Fecha: 18/08/05
de consultar artculo
3. Selecciona un artculo de la lista
4. Presenta los datos del artculo

seleccionado
CURSOS ALTERNATIVOS
Lnea 2: No existe lista del artculo termina casos de uso.
Lnea 4: No existen datos del artculo seleccionado termina caso de uso.
Nombre
: Seleccin de operacin consultar artculo(op)
Responsabilidades : Presentar formulario de consultar artculo

Tipo
Sistema.
Ref. Cruzadas
Consultar_artculo.
Notas
Excepciones
: Caso de uso Consultar_artculo, diagrama de secuencia
: No Existe Formulario de consultar artculo
Salida
Pre-condiciones
: Debe existir formularios de consultar artculo
Post-condiciones
: Ninguna
Nombre
: Seleccionar un artculo (Lista)

Tipo
: Sistema.
Ref. Cruzadas
: Caso de uso Consultar_artculo de secuencia
Consultar_artculo.
Notas
Excepciones
: No existen datos del artculo
Salida
Pre-condiciones
: El artculo debe existir
Post-condiciones
: Ninguna
- 143 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.3.2.3.- VALIDACIN DE REQUISITOS
Una vez establecidos los requisitos especficos se procede a realizar el anlisis y diseo
del Modelo Conceptual, Diagrama de Casos de Uso, Casos de Uso de Alto Nivel, Casos
de Usos Expandidos, Contrato de operacin, los que son validados por los usuarios, los
mismos que confirman que esta informacin es la correcta.
4.3.3.- IDENTIFICACIN DE SUBSISTEMAS DE ANLISIS
4.3.3.1.- DETERMINACIN DE SUBSISTEMAS DE ANLISIS
Para determinar los subsistemas de anlisis, se debe descomponer el sistema para

facilitar el manejo de la informacin, estos son los subsistemas que tendr el sistema de
inventario del comisariato:
Subsistema de Proveedor
Subsistema de Artculo
Subsistema de Socio
Subsistema de Factura Compra
Subsistema de Factura Venta
- 144 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.3.4.- ANALISIS DE CASOS DE USO
4.3.4.1.- IDENTIFICACIN DE CLASES ASOCIADAS A UN CASO DE USO
Para identificar las clases asociadas a un caso de uso se debe realizar una lista de objetos
los que se obtienen del establecimiento de requisitos, para realizar el diagrama de clase:
LISTA DE OBJETOS
GESTIN
Proveedor
CASO DE USO
Ingresar Proveedor
OPERACIN
Seleccionar ingresar proveedor(op)
Ingresar datos de proveedor
Eliminar Proveedor
Solicitar la operacin eliminar

proveedor
Seleccionar un proveedor(lista)
Confirmar operacin eliminar
proveedor
Modificar Proveedor
Seleccione modificar datos

proveedor (op)
Seleccionar un proveedor(lista)
Modificar datos proveedor
Consultar Proveedor
Seleccionar consultar proveedor

(op)
Seleccionar un proveedor (lista)
Artculo
Ingresar Artculo
Seleccionar ingresar Artculo(op)

Ingresar datos de Artculo
- 145 -
GCS
Versin: 1.0
Fecha: 18/08/05
Eliminar Artculo

Artculo
Seleccionar un Artculo(lista)
Artculo
Modificar Artculo

Artculo (op)
Seleccionar un Artculo(lista)
Modificar datos Artculo
Consultar Artculo
Seleccionar consultar Artculo (op)

Seleccionar un Artculo (lista)
Socio
Ingresar Socio
Seleccionar ingresar Socio(op)

Ingresar datos de Socio
Eliminar Socio

Socio
Seleccionar un Socio(lista)
Socio
Modificar Socio

Socio(op)
Modificar datos Socio
Consultar Socio
Seleccionar consultar Socio(op)

Factura Venta
Ingresar Factura Venta
Seleccionar ingresar Factura

Venta(op)
Ingresar datos de Factura Venta
- 146 -
GCS
Versin: 1.0
Fecha: 18/08/05
Eliminar Factura Venta

Factura Venta
Seleccionar un Factura Venta(lista)
Factura Venta
Modificar Factura Venta
Seleccione modificar datos Factura

Venta(op)
Modificar datos Factura Venta
Consultar Factura Venta
Seleccionar consultar Factura

Venta(op)
Factura Venta
Ingresar Factura Venta
Seleccionar ingresar Factura Venta
Detalle
Detalle
Detalle(op)
Ingresar datos de Factura Venta
Detalle
Detalle
Factura Venta Detalle

Seleccionar un Factura Venta
Detalle(lista)
Modificar Factura Venta
Detalle
Venta Detalle(op)
Detalle(lista)
Modificar datos Factura Venta
Detalle
- 147 -
GCS
Versin: 1.0
Fecha: 18/08/05
Consultar Factura Venta
Detalle
Venta Detalle(op)
Detalle(lista)
Factura Compra
Ingresar Factura Compra

Compra(op)
Ingresar datos de Factura Compra
Eliminar Factura
Compra
Factura Compra
Seleccionar un Factura
Compra(lista)
Factura Compra
Modificar Factura
Compra
Compra(op)
Compra(lista)
Modificar datos Factura Compra
Consultar Factura
Compra
Compra(op)
Compra(lista)
Factura Compra
Ingresar Factura Compra
Detalle
Detalle
Compra Detalle(op)
Ingresar datos de Factura Compra
Detalle
- 148 -
GCS
Versin: 1.0
Fecha: 18/08/05
Eliminar Factura
Compra Detalle
Factura Compra Detalle

Seleccionar un Factura Compra
Detalle(lista)
Modificar Factura
Compra Detalle
Compra Detalle(op)
Detalle(lista)
Modificar datos Factura Compra
Detalle
Consultar Factura
Compra Detalle
Compra Detalle(op)
Detalle(lista)
4.3.5.- ANALISIS DE CLASES
4.3.5.1 IDENTIFICACIN DE RESPONSABILIDADES Y ATRIBUTOS
Para identificar las responsabilidades y atributos de una clase, se revisa los casos de uso
para saber como es realizan las operaciones.
- 149 -
GCS
Versin: 1.0
Fecha: 18/08/05
IDENTIFICACIN DE RESPONSABILIDADES Y ATRIBUTOS DE UNA

CLASE
Clase
Eventos
Ingresar
Proveedor
Responsabilidad
Agrupa datos
Atributos
Cdigo, nombre
apellido, direccin
Eliminar
telfono,
Modificar
descripcin
Consultar
distribuidor.
Ingresar
Artculo
Agrupa datos
Cdigo, nombre,
stock, valor de
Eliminar
venta.
Modificar
Consultar
Ingresar
Socio
Agrupa datos
Cdigo, cdula,
nombre, apellido,
Eliminar
direccin.
Modificar
Consultar
Ingresar
Factura Compra
Agrupa datos
Serial, nmero de
factura, fecha de
Eliminar
vencimiento, fecha
Modificar
de emisin, detalle,
- 150 -
GCS
Versin: 1.0
Fecha: 18/08/05
Consultar
suma total, iva,

valor total, estado.
Ingresar
Factura Compra
Eliminar
Detalle
Modificar
Agrupa datos
Serial, cantidad
suma total, iva,
valor total.
Consultar
Factura Venta
Ingresar
Agrupa datos
Serial, nmero de
factura, fecha de
Eliminar
emisin, fecha de
Modificar
vencimiento,
Consultar
detalle, suma total,

iva, valor total,
estado.
Ingresar
Agrupa datos
Serial, cantidad,
suma total, iva,
Eliminar
valor total.
Modificar
Consultar
4.3.6.- ELABORACIN DEL MODELO DE DATOS
- 151 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.3.6.1.- ELABORACIN DEL MODELO CONCEPTUAL
Para elaborar el modelo conceptual del sistema de inventario (SICOIN) del comisariato,
se aplicara el estndar IEEE 1320.2 1998 (Estndar IEEE para el Modelo Conceptual
Lenguaje Sintaxis y Semntica para IDEF1X(Definicin Integrada para el modelo de
Informacin))
El modelo conceptual ser diseado con la herramienta CASE STUDIO 2 Versin 2.19
que utiliza la notacin IDEF1.
IDEF1 es un modelador de bases de datos que representa la estructura y la semntica de

la informacin dentro del sistema. (Ver Anexo 4.5)
CASE STUDIO 2 es una herramienta profesional que disea la base de datos

automticamente, permitiendo crear los diagramas entidad relacin para varias bases de
datos, considerando la integridad, restricciones, etc. (Ver Anexo 4.5)
- 152 -
GCS
Versin: 1.0
Fecha: 18/08/05
MODELO CONCEPTUAL SICOIN
- 153 -
GCS
Versin: 1.0
Fecha: 18/08/05
Fig. 4.3 Modelo Conceptual (CASE STUDIO 2 Versin 2.19)
MODELO FISICO SICOIN
- 154 -
GCS
Versin: 1.0
Fecha: 18/08/05
Fig. 4.4 Modelo Fsico (CASE STUDIO 2 Versin 2.19)
4.3.7.- ELABORACIN DEL MODELO DE PROCESOS
Debido a que no se est siguiendo un anlisis estructurado, en el ASI no se realiza est

actividad.
4.3.8.- DEFINICION DE INTERFACES DE USUARIO
4.3.8.1
ESPECIFICACIN DE PRINCIPIOS GENERALES DE LA INTERFAZ
Para la especificacin de principios generales de la interfaz se selecciona el entorno de la

interfaz interactiva del usuario.
INTERFAZ DE USUARIO
TIPO
Colores de Interfaz
ELEMENTOS
Barra de Men
Formularios
- 155 -
FORMATO
Azul
Amarrillo
GCS
Colores de Texto
Fuente
Versin: 1.0
Fecha: 18/08/05
Botones
Tomate
Barra de Men
Blanco
Formularios
Negro
Botones
Negro
Mensajes
Negro
Barra de Men
Arial tamao 10
Formularios
Arial tamao 10
Botones
Arial tamao 10
Mensajes
Arial tamao 10
REPORTES
Pantalla
Colores y Fuente
Los establecidos
Impresin
Color
Blanco / Negro
Fuente
Los establecidos
4.3.9.- ANLISIS DE CONSISTENCIA Y ESPECIFICACIN DE REQUISITOS
4.3.9.1 ELABORACIN
DE
LA
ESPECIFICACIN
SOFTWARE (ERS)
- 156 -
DE
REQUISITOS
GCS
Versin: 1.0
Fecha: 18/08/05
Para la elaboracin de la documentacin ERS se utilizara el Estndar IEEE 830 1998

(Estndar IEEE Prctica Recomendada para la Especificacin de Requisitos Software
(ERS))
Aplicado el Estndar IEEE 830 se obtuvo como resultado los siguientes requisitos
funcionales, para mayor detalle (Ver Anexo 4.6)
REQUISITOS FUNCIONALES
GESTIN PROVEEDOR
El sistema permitir:
GESTIN ARTCULOS
GESTIN SOCIOS
- 157 -
GCS
Versin: 1.0
Fecha: 18/08/05

GESTIN FACTURA VENTA

GESTIN FACTURA COMPRA

Req(25)Consultar las Facturas Compras en forma individual.
- 158 -
GCS
4.3.10.-
Versin: 1.0
Fecha: 18/08/05
ESPECIFICACIN DEL PLAN DE PRUEBAS
Para realizar el plan de pruebas se utilizara el Estndar IEEE 1008 1997 R2003
(Estndar IEEE para Pruebas Unitarias de Software)
Aplicado el Estndar IEEE 1008 se obtuvo como resultado las Caractersticas a ser
probadas, para mayor detalle (Ver Anexo 4.7)
Crear Artculo y almacenar datos

Crear Artculo con cdigo existente
Crear Artculo con valores que no admiten los campos
Modificar los datos de un Artculo y actualizarlos
Modificar los datos de un Artculo con valores que no admiten los
campos
Buscar datos de un Artculo y desplegar informacin
Buscar datos de un Artculo con cdigo no existente
Eliminar un Artculo
Eliminar Artculo con informacin relacionada
4.3.10.1
DEFINICION DEL ALCANCE DE LAS PRUEBAS
En el desarrollo del sistema de inventario del comisariato, en la fase del ASI se aplicara
las Pruebas Unitarias.
- 159 -
GCS
4.3.11.-
Versin: 1.0
Fecha: 18/08/05
APROBACIN DEL ANLISIS DEL SISTEMA DE INFORMACIN
Para la aprobacin del ASI se rene el equipo de trabajo que participo en el desarrollo de
este plan para aprobar (Ver Anexo 4.8)
4.4.- DISEO DEL SISTEMA DE INFORMACIN (DSI)
4.4.1.- DEFINICIN DE LA ARQUITECTURA DEL SISTEMA
4.4.1.1.- DEFINICIN DE NIVELES DE ARQUITECTURA
Para definir el nivel de arquitectura que tendremos tanto de hardware y

software en el sistema de inventario a desarrollar en el comisariato, se
representara de la siguiente manera.
CLIENTE /SERVIDOR
BD
- 160 -
IMPRESORA
GCS
Versin: 1.0
Fecha: 18/08/05
Fig 4.5 Niveles de Arquitectura
4.4.1.2 IDENTIFICACION DE REQUISITOS DE DISEO Y CONSTRUCCION
El entorno tecnolgico que se requiere para el diseo y construccin del sistema de

inventario del comisariato es:
Hardware PC Pentium II o Superior, Impresora

Metodologa de Desarrollo Mtrica V3 Orientada a Objetos
Sistema Base Sistema Operativo WINDOWS (95,98,XP, Profesional)
Software de Aplicacin PHP
Servidor WEB APACHE
Cliente WEB Microsoft Internet Explorer
Base de Datos MYSQL
Interfaces Dreamweaver MX 2004
- 161 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.4.1.3.- ESPECIFICACIN DE EXCEPCIONES
La especificacin de excepciones define el comportamiento no habitual del sistema

cuando este funcione.
CATALOGO DE EXCEPCIONES
DESCRIPCION
TIPO
ELEMENTOS AFECTADOS
Acceso al sistema
Tener
Accede al sistema SICOIN
(nombre y password)
Formulario de Ingreso de
Cdigo
Rango o Valor no Valido
Datos Proveedor, Artculo,

Socio.
Cdula
Datos Socio.
Nombre
Valor no Valido
Datos Proveedor, Artculo,

Socio.
Apellido
Valor no Valido
Datos Proveedor, Socio.
Telfono
Datos Proveedor.
Stock
Datos Artculo.
Fecha
emisin
y Rango o Valor no Valido
vencimiento
Datos Factura Compra y
Venta.
Cantidad
Valor no Valido
Datos Factura Compra y
- 162 -
GCS
Versin: 1.0
Fecha: 18/08/05
Venta.
4.4.1.4.-
ESPECIFICACIN DE ESTANDARES Y NORMAS DE DISEO Y

CONSTRUCCIN
Los estndares que se aplicara en el DSI son los siguientes:
Estndar IEEE 830 1998 (Estndar IEEE Prctica Recomendada para la Especificacin
de Requisitos Software (ERS))
Estndar IEEE 829 1998 (Estndar IEEE para Documentacin de Pruebas de

Software)
Estndar IEEE 1063 2001 (Estndar IEEE para la documentacin del Usuario del
Software)
4.4.1.5.-
IDENTIFICACIN DE SUBSISTEMAS DE DISEO
- 163 -
GCS
Versin: 1.0
Fecha: 18/08/05
Los subsistemas de diseo que tendr el sistema de inventario del comisariato, reducirn
la complejidad y facilitaran el mantenimiento del mismo.
SUBSISTEMAS DE DISEO
SUBSISTEMAS
GESTIONES
Proveedor
Ingresar, Eliminar, Modificar, Consultar los Datos
Artculo
Socio
Factura Compra
Factura Venta
4.4.1.6.-
ESPECIFICACIN DEL ENTORNO TECNOLGICO
El entorno tecnolgico que se requiere para el sistema de inventario del comisariato es:

Servidor WEB APACHE
Base de Datos MYSQL
- 164 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.4.2.- DISEO DE LA ARQUITECTURA DE SOPORTE
Debido a que no existe ningn subsistema de soporte para el sistema de inventario del
comisariato, est actividad no se realiza.
4.4.3.- DISEO DE CASOS DE USO REALES

4.4.3.1.-
DISEO DE LA REALIZACIN DE LOS CASOS DE USO
Para describir la interaccin de objetos hay que realizar los diagramas de secuencia y
colaboracin.
DIAGRAMA DE SECUENCIA INGRESAR ARTICULO
- 165 -
GCS
Versin: 1.0
Fecha: 18/08/05
ACTOR
SISTEMA
Seleciona Ingresar Articulo (op)
Campos de
Articulo
Cdigo
Nombre
Stock
Valor de Venta
Ingresar datos del Articulo(campos)
DIAGRAMA DE COLABORACION SELECCIN DE OPERACIN INGRESO DE

ARTICULO (OP)
1: Selecionar Ingresar Articulo(op)
Interfaz: Interfaz
Principal
: Administrador
Formularios: Formulario
Ingreso Articulo
2: (Formulario=ok) Presentar Formulario

3: (Formulario=No ok) Desplegar
mensaje No Existe
4: Presenta Formulario
Interfaz: Interfaz
Salida
- 166 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE COLABORACIN INGRESAR DATOS DEL ARTICULO

(LISTA DE DATOS)
1: Ingresar datos del Articulo (string, string, string, string)

Formulario: Formulario
Ingresar Articulo
: Administrador
2: Crear Articulo (string, string, string, string)

Articulo: Ingresado
Articulo
3: Presenta Formulario (vacio)
Interfaz: Interfaz
Salida
- 167 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE SECUENCIA ELIMINAR ARTICULO
ACTOR
SISTEMA
Selecionar Operacin EliminarArticulo
Campos de
Articulo
Cdigo
Nombre
Stock
Valor de Venta
Seleccionar un Articulo (lista)
Confirmar Operacin Eliminar Articulo
DIAGRAMA DE COLABORACIN SELECCIN DE OPERACIN ELIMINAR

ARTICULO(OP)
- 168 -
GCS
Versin: 1.0
Fecha: 18/08/05
1: Selecionar Operacin Eliminar Articulo (op)
Interfaz: Interfaz
Principal
: Administrador

3: (Formulario=No ok) Despliega No existe
Formularios: Formulario
Eliminar Articulo
Interfaz: Interfaz
Salida
DIAGRAMA DE COLABORACIN SELECCIN DE UN ARTICULO(LISTA)
1: Seleccionar un Articulo (lista)
Interfaz: Interfaz
Seleccinar Articulo
: Administrador
2: Presentar Datos Articulo seleccionado
Articulo: Eliminar
Articulo
3: Elimina Articulo
Interfaz: Interfaz
Salida
- 169 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE COLABORACION CONFIRMAR OPERACIN
1: Confirmar Operacion Eliminar Articulo
Interfaz: Interfaz Confirmar

Operacion Eliminar Articulo
: Administrador
2: (Formulario=ok) Articulo Eliminado
3: (Formulario=No ok) Despliege no se
Puede Eliminar
Articulo: Confirmar Operacion
Eliminar Articulo
4: Elimina Articulo
Interfaz: Interfaz
Slida
- 170 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE SECUENCIA MODIFICAR DATOS DEL ARTICULO
ACTOR
SISTEMA
Seleccinar Modificar Datos Articulo (op)
Campos de
Articulo
Nombre
Stock
Valor de Venta
Modificar Datos Articulo
DIAGRAMA DE COLABORACIN SELECCIN DE MODIFICAR DATOS
1: Seleccinar Modificar Datos Articulo (op)
Interfaz: Interfaz
Principal
: Administrador
2: (Formulario=ok) Presenta Formulario

3: (Formulario=No ok) Despliaga No existe
Modificar Articulo
Interfaz: Interfaz
Salida
ARTICULO (OP)
- 171 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE COLABORACIN SELECCIN DE UN ARTICULO (LISTA)
Interfaz: Interfaz
Seleccionar Articulo
: Administrador
2: Presentar Datos Articulo Seleccionado
Articulo: Modificar
Articulo
3: Modificar Articulo
Interfaz: Interfaz
Salida
DIAGRAMA DE COLABORACIN MODIFICAR DATOS DEL ARTICULO
- 172 -
GCS
Versin: 1.0
Fecha: 18/08/05
1: Modificar Datos Articulo

Interfaz: Interfaz Modificar
Datos Articulo
: Administrador
2: (Formulario=ok) Articulo Modificado
3: (Formulario=No ok) Despliege No se Puede Modificar
Articulo: Modificar
Datos Articulo
4: Modificado Articulo
Interfaz: Interfaz
Salida
DIAGRAMA DE SECUENCIA CONSULTAR ARTICULO
- 173 -
GCS
Versin: 1.0
Fecha: 18/08/05
ACTOR
SISTEMA
Seleccionar Consultar Articulo(op)

Campos de
Articulo
Cdigo
Nombre
Stock
Valor de Venta
DIAGRAMA DE COLABORACIN SELECCIN DE CONSULTAR ARTICULO(OP)
1: Seleccionar Consultar Articulo (op)
Interfaz: Interfaz
Principal
: Administrador

3: (Formulario=No ok) Despliege no existe
Consultar Articulo
Interfaz: Interfaz
Salida
- 174 -
GCS
Versin: 1.0
Fecha: 18/08/05
DIAGRAMA DE COLABORACION SELECCIN UN ARTICULO (LISTA)
Interfaz: Interfaz
Consultar Articulo
: Administrador
2: Presentar Datos Articulo Seleccionado
Articulo: Consultar
Articulo
3: Consultar Articulo
Interfaz: Interfaz
Salida
4.4.4.- DISEO DE CLASES
El diseo de clases recoge las especificaciones detalladas de cada una de las clases es
- 175 -
GCS
Versin: 1.0
Fecha: 18/08/05
decir sus atributos, operaciones y mtodos.
DIAGRAMA DE CLASE DE ARTCULO
4.4.5.- DISEO DE LA ARQUITECTURA DE MDULOS DEL SISTEMA
Debido a que est actividad se la hace en caso de diseo estructurado, no

se la realizara.
4.4.6.- DISEO FSICO DE DATOS
4.4.6.1.- DISEO DEL MODELO FISICO DE DATOS
Ver Fig. 4.4 Modelo Fsico en el ASI
4.4.6.2.- ESPECIFICACIN DE LOS CAMINOS DE ACCESO A LOS DATOS
Se determinar los caminos de acceso a los datos.
ENTIDAD
CASOS DE ACCESO
Proveedor
Artculo
- 176 -
GCS
4.4.7.-
Versin: 1.0
Fecha: 18/08/05
Socio
Factura Compra
Factura Venta
VERIFICACIN Y ACEPTACIN DE LA ARQUITECTURA DEL
SISTEMA
4.4.7.1.- VERIFICACION DE LAS ESPECIFICACIONES DE DISEO
Asegura la calidad formal de los distintos modelos, seguidos para la elaboracin de cada
producto y verifica que cumpla con dichas especificaciones.
VERIFICACIN DE ESTNDARES
REQUISITOS
ESTANDAR
ERS
IEEE 830
Pruebas de Software
IEEE 829
- 177 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.4.7.2.- ANALISIS DE CONSISTENCIA DE LAS ESPECIFICACIONES DE

DISEO
Para el anlisis de consistencia de las especificaciones de diseo, se compara el Anlisis

de clases / Diseo del Modelo Fsico de Datos
Obteniendo como resultado que los elementos del modelo fsico de datos corresponden a
los elementos utilizados por las clases de diseo, tanto de los subsistemas especficos
como de las gestiones.
4.4.8.- GENERACION DE ESPECIFICACIONES DE CONSTRUCCION
4.4.8.1.- ESPECIFICACION DEL ENTORNO DE CONSTRUCCION

El entorno tecnolgico que se requiere para el diseo y construccin del sistema de
inventario del comisariato es:

Servidor WEB APACHE
Base de Datos MYSQL
- 178 -
GCS
Versin: 1.0
Fecha: 18/08/05

4.4.8.2.-
DEFINICION
DE
COMPONENTES
SUBSISTEMAS
CONSTRUCCION
SUBSISTEMAS DE CONSTRUCCIN
SUBSISTEMAS
COMPONENTES
Proveedor
Nuevo, Modificar, Guardar, Actualizar, Salir
Artculo
Socio
Factura Compra
Factura Venta
4.4.9.- DISEO DE LA MIGRACION Y CARGA INICIAL DE DATOS
Debido a que no se cargar o migrarn datos de otros sistemas, no se realiza est

actividad.
4.4.10.- ESPECIFICACIN TECNICA DEL PLAN DE PRUEBAS
Para la especificacin del plan de pruebas del sistema de informacin, se seguir el

estndar IEEE 829 (Ver Anexo 4.9)
- 179 -
DE
GCS
Versin: 1.0
Fecha: 18/08/05
4.4.11 ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACION
4.4.11.1 ESPECIFICACIN DE REQUISITOS DE DOCUMENTACIN DE

USUARIO
Para elaborar la documentacin del usuario se tomara en cuenta el Estndar IEEE 1063
2001 (Estndar IEEE para la documentacin de Usuario del Software). (Ver CD 4.10)
Formato de Documentacin que tendr el documento
Espacio entre lnea
1.5
Fuente
Arial
Tamao
12
Tipo de Papel
Tamao de Papel
Bond blanco de 75g

Inen A4
Distribucin de la Documentacin
Se editara dos copias, una para el jefe del departamento y el otro para el
administrador del sistema.
Control de Versiones
Existir una sola versin
4.4.11.- APROBACIN DEL DISEO DEL SISTEMA DE INFORMACIN
- 180 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para la aprobacin del DSI se rene el equipo de trabajo que participo en el desarrollo de
este plan para aprobar. (Ver Anexo 4.11)
4.5.- CONSTRUCCION DEL SISTEMA DE INFORMACION (CSI)
4.5.1.- PREPARACIN DEL ENTORNO DE GENERACIN Y CONSTRUCCIN
4.5.1.1.-
IMPLANTACIN DE LA BASE DE DATOS FSICA O FICHEROS
Para la implantacin de la base de datos fsica o ficheros se realiza lo siguiente:
El gestor de base de datos y el espacio ser reservado para el almacenamiento de las

tablas por MYSQL, todo esto se realiza en el servidor, en C:\servidor\mysql\data, la base
de datos se puede crear con el scrip que genero el modelo fsico o realizarlo
manualmente.
4.5.1.2.-
PREPARACIN DEL ENTORNO DE CONSTRUCCIN
Para la preparacin del entorno de construccin se debe definir las

bibliotecas y las herramientas a utilizar.
- 181 -
GCS
Versin: 1.0
Fecha: 18/08/05
BIBLIOTECAS
Base de Datos
C:\servidor\mysql\data\bdd_inventarios
Interfaces del Sistema
C:\Archivos de programa\Apache Group\Apache\htdocs\SICOIN

HERRAMIENTAS
PHP Genera Cdigo Fuente

APACHE Servidor WEB
MYSQL Gestor Base de Datos
Microsoft Internet Explorer Cliente WEB
4.5.2.- GENERACIN DEL

PROCEDIMIENTOS
CDIGO
DE
LOS
COMPONENTES
Cdigo fuente (Ver CD 4.12)
4.5.3.- EJECUCIN DE LAS PRUEBAS UNITARIAS
Una vez codificado los componentes, se precisa comprobar que si la

estructura es la correcta a la establecida anteriormente en el plan de pruebas.
4.5.3.1.-
REALIZACIN DE LAS PRUEBAS UNITARIAS
Una vez ejecuta esta prueba se demuestra el correcto funcionamiento de

los componentes del sistema, y se puede observar que son los mismos requisitos
que se establecieron en la fase de anlisis, confirmando que las respuestas son
iguales a las expuestas en el plan.
- 182 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.5.4.- EJECUCIN DE LAS PRUEBAS DE INTEGRACIN
Con la ejecucin de esta prueba se verifica que los componentes interacten

correctamente entre sus interfaces, y todo est tal como se estableci en el plan.
4.5.4.1.-
REALIZACIN DE LAS PRUEBAS DE INTEGRACIN
Una vez ejecuta esta prueba se comprueba que todos los subsistemas del
sistema interactan correctamente, y se puede verificar que est como se ha
establecido en la fase de diseo, confirmando que las respuestas son las
expuestas en el plan.
4.5.5.- EJECUCIN DE LAS PRUEBAS DEL SISTEMA
Con la ejecucin de esta prueba, se verifica que los subsistemas del sistema interactan
correctamente en forma global, y todo est tal como se estableci en el plan.
4.5.5.1.-
REALIZACIN DE LAS PRUEBAS DEL SISTEMA
Una vez ejecuta esta prueba, que es paralela a las pruebas Unitarias y de
integracin, comprobamos que todo funciona correctamente, de acuerdo al plan
establecido de pruebas.
4.5.6.- ELABORACIN DE LOS MANUALES DE USUARIO
- 183 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para la especificacin de requisitos de documentacin de usuario se aplicara el Estndar

IEEE 1063 2001 (Estndar IEEE para la documentacin del Usuario del Software)
(Ver Anexo 4.10)
4.5.7.- DEFINICIN DE LA FORMACIN DE USUARIOS FINALES
4.5.7.1.-
DEFINICIN DEL ESQUEMA DE FORMACIN

USUARIO
Administrador
PERFIL
Este usuario requiere tener conocimiento tcnico sobre el
manejo de un sistema de informacin y saber el
funcionamiento total del sistema, para que pueda
administrar eficientemente y no tener ningn problema.
Gerente
Este usuario debe tener algn conocimiento de

computacin y manejo del sistema, para que pueda acceder
al sistema de acuerdo al perfil que le fue asignado por el
administrador.
Cajera/o
Este usuario debe tener algn conocimiento de

computacin y del manejo del sistema, para que pueda
acceder al sistema de acuerdo al perfil que le fue asignado
por el administrador.
4.5.8.- CONSTRUCCIN DE LOS COMPONENTES Y PROCEDIMIENTOS DE

MIGRACIN Y CARGA INICIAL DE DATOS
- 184 -
GCS
Versin: 1.0
Fecha: 18/08/05
Debido a que no existe un sistema anterior no se realiza la cargar o

migrarn datos, ya que pasaremos lo manual a sistematizar.
4.5.9.- APROBACIN DEL SISTEMA DE INFORMACIN

Para la revisin y aprobacin del CSI se rene el equipo de trabajo que participo en la
construccin del sistema de informacin para su aprobacin. (Ver Anexo 4.13)
4.6.- IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS)
Debido a que se esta siguiendo el ciclo de vida secuencias no se realizara est fase, el
sistema SICOIN ser implantado siguiendo las polticas del comisariato.
El ciclo de vida secuencial es el siguiente:
REQUISITOS
DISEO
CODIFICACIN
PRUEBAS
OPERACIN
- 185 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.7.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN (MSI)
Debido a que el sistema SICOIN es el primer sistema que se incorpora en el comisariato

no se realiza est fase, tambin debe estar un tiempo en funcionamiento el sistema para
realizar el mantenimiento.
4.8.- ASEGURAMIENTO DE LA CALIDAD

4.8.1.- ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)
4.8.1.1.- IDENTIFICACIN DE LAS PROPIEDADES DE CALIDAD PARA EL

SISTEMA
Para realizar la identificacin de las propiedades de calidad para el sistema, se

selecciona el equipo de trabajo para que determine y valore el plan de aseguramiento de
calidad.
- 186 -
GCS
Versin: 1.0
Fecha: 18/08/05
PLAN DE ASEGURAMIENTO DE CALIDAD

PROPIEDADES
ACTIVIDAD
EVS
EQUIPO DE TRABAJO
Eficiencia (Hardware)
Alternativa
Gladys Aguagallo
de
Paulina Caizares
Integridad (Base de Datos)
solucin
Facilidad de Uso (Software)
4.8.1.2.-
ESTABLECIMIENTO
DEL
PLAN
DE
ASEGURAMIENTO
DE
CALIDAD
4.8.1.2.1
NECESIDAD
DEL
PLAN
DE
ASEGURAMIENTO
DE
CALIDAD
PARA
LAS
ALTERNATIVAS PROPUESTAS
Debido a que ya se escogi la alternativa de solucin y existe la viabilidad econmica,

no se realizar este plan.
4.8.1.3.-
ADECUACIN DEL PLAN DE ASEGURAMIENTO DE CALIDAD
La adecuacin del plan de aseguramiento de calidad no se establece debido a que la

actividad anterior no se realiza.
- 187 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.8.2.- ANALISIS DEL SISTEMA DE INFORMACIN (ASI)
4.8.2.1.-
ESPECIFICACIN INICIAL DEL PLAN DE ASEGURAMIENTO DE

CALIDAD
Para iniciar el plan de aseguramiento de calidad es necesario detallar el nombre

del producto, el estndar a utilizar y los responsables para llevar a cabo este plan.
PLAN DE ASEGURAMIENTO DE CALIDAD

ESTANDAR
SITEMA
EQUIPO DE TRABAJO
Sistema de Inventario IEEE 730 2002 (Estndar
Gladys Aguagallo
(SICOIN)
Paulina Caizares
IEEE para Planes de

Aseguramiento de Calidad)
4.8.2.2.-
ESPECIFICACIN DETALLADA DEL PLAN DE ASEGURAMIENTO

DE CALIDAD
Para asegurar la calidad del sistema de inventario (SICOIN) del comisariato, se realiza el
Plan de Aseguramiento de la Calidad (SQAP), para lo que se aplicara el estndar IEEE
730 2002
Aplicando el Estndar IEEE 730 se obtuvo como resultado los requisitos mnimos, para
ms detalle (Ver Anexo 4.14)
- 188 -
GCS
Versin: 1.0
Fecha: 18/08/05
Requisitos Mnimos
Revisin de la gestin
Revisin de los requisitos del software
Revisin del anlisis
Revisin de diseo
Revisin de construccin
4.8.2.3.-
REVISIN DEL ANALISIS DE CONSISTENCIA
4.8.2.3.1 REVISIN DEL CATALOGO DE REQUISITOS
REGISTRO DE REVISIN DEL CATALOGO DE REQUISITOS
FECHA
16/05/05
DESCRIPCIN
AUTOR
La revisin del catalogo de requisitos se lo Gladys Aguagallo

realiza con la especificacin de requisitos de Paulina Caizares
software (ERS), con lo que se puede validar
los requisitos, y se obtuvo como resultado
que los requisitos son correctos y que
corresponden a los ERS.
4.8.2.4.-
REVISIN DEL PLAN DE PRUEBAS
REGISTRO DE REVISIN DEL PLAN DE PRUEBAS
FECHA
6/06/05
DESCRIPCIN
AUTOR
La revisin del plan de pruebas unitarias se Gladys Aguagallo

lo realiza con los ERS, para verificar que las
caractersticas a ser probadas sean las
- 189 -
Paulina Caizares
GCS
Versin: 1.0
Fecha: 18/08/05
correctas y que corresponden al ERS.
4.8.2.5.-
REGISTRO DE LA APROBACIN DEL ANLISIS DEL SISTEMA
4.8.2.5.1 REGISTRO DE APROBACIN DEL ANALISIS DEL SISTEMA DE

INFORMACIN (ASI)
REGISTRO DE APROBACIN DEL ASI
FECHA
13/06/05
DESCRIPCIN
AUTOR
Se rene el equipo de trabajo que participo Gerente

en el desarrollo del plan del ASI para revisar Personal
este documento, finalmente se aprueba el
Administrativo
plan.
Equipo Tcnico
4.8.3.- DISEO DEL SISTEMA DE INFORMACIN (DSI)
4.8.3.1.-
REVISIN DE LA VERIFICACIN DE LA ARQUITECTURA DEL

SISTEMA
REGISTRO DE VERIFICACIN DE LA ARQUITECTURA DEL SISTEMA
- 190 -
GCS
Versin: 1.0
Fecha: 18/08/05
FECHA
DESCRIPCIN
AUTOR
20/06/05
Se comprueba que la arquitectura del sistema
Gladys Aguagallo
Paulina Caizares
se ajusta a la requerida en el DSI para

desarrollar el sistema.
4.8.3.2.-
REVISIN DE LA ESPECIFICACIN TCNICA DEL PLAN DE

PRUEBAS
REGISTRO DEL PLAN DE PRUEBAS DE INTEGRACIN
FECHA
9/05/05
DESCRIPCIN
AUTOR
Se comprueba que existe el plan de pruebas Gladys Aguagallo

de
integracin
que
este
siga
las
Paulina Caizares
Caractersticas a ser probadas, constatando

que las interfaces tengan secuencia entre
ellas segn lo establecido en el DSI.
4.8.3.3.-
REVISIN DE LOS REQUISITOS DE IMPLANTACIN
4.8.3.3.1 REVISION DE LOS REQUISITOS DE DOCUMENTACIN DE

USUARIO
- 191 -
GCS
Versin: 1.0
Fecha: 18/08/05
REGISTRO DE DOCUMENTACIN DE USUARIO
FECHA
11/07/05
DESCRIPCIN
AUTOR
Se registra la entrega del manual de usuario, Gladys Aguagallo

el nmero de copias y el estndar que se
Paulina Caizares
utilizo para elaborar el manual de usuario.
4.8.3.4.-
REGISTRO DE APROBACIN DEL DISEO DEL SISTEMA DE

INFORMACIN (DSI)
REGISTRO DE APROBACIN DEL DSI
FECHA
18/07/05
DESCRIPCIN
AUTOR

en el desarrollo del plan del DSI para revisar Personal
este documento, finalmente se aprueba el Administrativo
plan.
Equipo Tcnico
4.8.4.- CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)
- 192 -
GCS
4.8.4.1.-
Versin: 1.0
Fecha: 18/08/05
REVISIN DE CDIGO DE COMPONENTES Y PROCEDIMIENTOS
REGISTRO DE CDIGO
FECHA
19/07/05
DESCRIPCIN
AUTOR
Se verifica que exista el cdigo fuente en la Gladys Aguagallo

fase de Construccin.
4.8.4.2.-
Paulina Caizares
REVISIN DE LAS PRUEBAS UNITARIAS, DE INTEGRACIN Y DEL

SISTEMA
REGISTRO DE PRUEBAS
FECHA
11/07/05
DESCRIPCIN
AUTOR
Se revisa que existan las pruebas unitarias, Gladys Aguagallo

de integracin y de sistema, para verificar si
han
seguido
las
caractersticas
Paulina Caizares
ser
probadas en el plan.
4.8.4.3.-
REVISIN DE LOS MANUALES DE USUARIO
REGISTRO DE MANUALES DE USUARIO
FECHA
11/07/05
DESCRIPCIN
AUTOR
Se registra la entrega del manual de usuario, Gladys Aguagallo

el nmero de copias y se revisa que aplicado
- 193 -
Paulina Caizares
GCS
Versin: 1.0
Fecha: 18/08/05
el estndar IEEE 1063, que se utilizo para

elaborar el manual de usuario.
4.8.4.4.-
REVISIN DE LA FORMACIN A USUARIOS FINALES
FECHA
22/08/05
DESCRIPCIN
AUTOR
Se verifica que estn definido los usuarios Gladys Aguagallo

finales en la fase del CSI.
4.8.4.5.-
Paulina Caizares
REGISTRO DE APROBACIN DE LA CONSTRUCCIN DEL

SISTEMA DE INFORMACIN
REGISTRO DE APROBACIN
FECHA
29/08/05
DESCRIPCIN
AUTOR

en el desarrollo del sistema para
revisar, Personal
finalmente se aprueba.
Administrativo
Equipo Tcnico
4.8.5.- IMPLANTACIN Y ACEPTACIN DEL SISTEMA
Debido a que estamos siguiendo el ciclo de vida secuencias no se realizara est fase, el
4.8.6.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN
- 194 -
GCS
Versin: 1.0
Fecha: 18/08/05

4.9.- INTERFAZ DE SEGURIDAD

4.9.1.- PLANIFICACIN DEL SISTEMA DE INFORMACIN
4.9.1.1.-
PLANIFICACIN
DE
LA
SEGURIDAD
REQUERIDA
EN
EL
PROCESO DE PLANIFICACIN DE SISTEMAS DE INFORMACIN

Se debe dar seguridad a la informacin aportada por el comisariato para la elaboracin de
la Planificacin del sistema de informacin, est informacin debe ser confidencial e
Integra, en la Identificacin de Requisitos.
4.9.1.2.-
EVALUACIN
DEL
RIESGO
PARA
LA
ARQUITECTURA
TECNOLGICA
La evaluacin de los riesgos se realiza para calcular los posibles problemas

que se pueden presentar negativamente, obteniendo de esta manera los costos
econmicos de la proteccin de la informacin en el anlisis, de esta forma se
puede anticipar los problemas y costos en el plan de accin.
Para evaluar los riesgos de la arquitectura tecnolgica se utilizara la

herramienta MAGERIT (RIS2k).
MAGERIT (Metodologa de Anlisis y Gestin de Riesgos de los

Sistemas de Informacin de las Administraciones Pblicas) es un mtodo
- 195 -
GCS
Versin: 1.0
Fecha: 18/08/05
formal para investigar los riesgos que soportan los sistemas de informacin y para
recomendar las medidas apropiadas que debera aportarse para controlar estos
riesgos.
ACTIVOS son los recursos del sistema de informacin o relacionados con

este. Necesarios para que la organizacin funcione correctamente y alcance los
objetivos propuestos por su direccin.
AMENAZAS son eventos que pueden desencadenar un incidente en la

organizacin produciendo daos materiales o perdidas en los activos.
- 196 -
GCS
Versin: 1.0
Fecha: 18/08/05
RIESGO EFECTIVO (R.e.) se llama riesgo efectivo al nivel de riesgo

resultante, una vez aplicado las salvaguardas existentes en el sistema de
informacin.
RIESGO INTRINSECO (R.i.) se define o calcula antes que aplique las

salvaguardas
- 197 -
GCS
Versin: 1.0
Fecha: 18/08/05
SALVAGUARDAS es la accin que reduce el riesgo
4.9.1.3.- DETERMINACIN DE LA SEGURIDAD EN EL PLAN DE ACCIN
- 198 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para determinar la seguridad del plan de accin se debe activar los mecanismos de
Salvaguarda que se determinaron para la arquitectura tecnolgica en el RIS2K, tomando
en cuenta:
Definir herramientas y metodologa de pruebas

Estudiar estrategias y criterios generales del organismo
Estudiar la situacin actual del organismos
Planificar y valorar el proyecto de adaptacin
4.9.1.4.-
CATALOGACIN DE LOS PRODUCTOS GENERADOS DURANTE EL

PROCESO DE PLANIFICACIN DEL SISTEMAS DE INFORMACIN
Los productos resultantes del PSI son los siguientes
Arquitectura tecnolgica
Plan de accin
4.9.2.- ESTUDIO DE VIABILIDAD DEL SISTEMA
4.9.2.1.-
ESTUDIO DE LA SEGURIDAD REQUERIDA EN EL PROCESO

ESTUDIO DE VIABILIDAD DEL SISTEMA
Para el estudio de viabilidad del sistema la seguridad que se seguir en cuanto a

Confidencialidad, Disponibilidad e Integridad en la definicin de los requisitos.
4.9.2.2.- SELECCIN DEL EQUIPO DE SEGURIDAD
- 199 -
GCS
Versin: 1.0
Fecha: 18/08/05
El equipo de seguridad estar integrado por:
Gladys Aguagallo
Paulina Caizares
4.9.2.3.-
RECOMENDACIONES ADICIONALES DE SEGURIDAD PARA EL

SISTEMA DE INFORMACIN
Control de Acceso al Sistema SICOIN

Tener activado y actualizado el Antivirus
Al iniciar el funcionamiento del computador, tener un Control de Acceso
La Base de Datos no puede ser modificada, solo tendr el permiso de
lectura
El Sistema SICOIN ser instalado en el comisariato, con los archivos
ejecutables
4.9.2.4.-

PROCESO DE ESTUDIO DE VIABILIDAD DEL SISTEMA
Los productos resultantes del EVS son los siguientes
Estudio de la situacin actual

Estudio de alternativas de solucin
4.9.3.- ANALISIS DEL SISTEMA DE INFORMACIN (ASI)
4.9.3.1.-
ESTUDIO DE LA SEGURIDAD REQUERIDA EN EL PROCESO DE

ANALISIS DEL SISTEMA DE INFORMACIN
- 200 -
GCS
Versin: 1.0
Fecha: 18/08/05
La seguridad en el anlisis del sistema de informacin ser, Confidencialidad,

Disponibilidad e Integridad tanto en el entorno tcnico como en la obtencin de los
productos generados.
4.9.3.2.- DESCRIPCIN
DE
LAS
FUNCIONES
MECANISMOS
DE
SEGURIDAD
Para describir las funciones y mecanismos de seguridad se utiliza la herramienta RIS2K,

en la gestin de riesgos con lo que se puede minimizar o eliminar los riesgos.
SALVAGUARDA
FUNCIN
Realizar
diagnstico
general
MECANISMO
TIPO
actual Preventiva
Estudiar situacin
tcnica del organismo
Estudiar
estrategia
criterios
generales
y
del
organismo
Valorar
los
sistemas
informticos
Planificar
valorar
el
proyecto de adaptacin
Conversin y pruebas
Definir
de aplicaciones
metodologa de pruebas
herramientas
y Preventivo
Validacin y soporte
Definir
herramientas
de
conversin de bases de
datos
- 201 -
GCS
4.9.3.3.-
Versin: 1.0
Fecha: 18/08/05
DEFINICIN DE LOS CRITERIOS DE ACEPTACIN DE LA

SEGURIDAD
OBJETIVO
LA TECNICA
DE
Seguridad a nivel de aplicacin: un usuario puede acceder

al sistema de acuerdo al perfil
Seguridad a nivel de sistema: pueden acceder al sistema
solo los usuarios que tengan una clave y password
TCNICA
Seguridad a nivel de aplicacin: identificar y listar cada tipo

de usuario y perfil para realizar las pruebas
4.9.3.4.- CATALOGACIN DE LOS PRODUCTOS GENERADOS DURANTE EL

PROCESO DE ANALISIS DEL SISTEMA DE INFORMACIN
Anlisis de casos de uso

Especificacin de casos de uso de alto nivel
Elaboracin del modelo de datos
Definiciones de interfaces de usuario
Especificacin del plan de pruebas unitarias
4.9.4.- DISEO DEL SISTEMA DE INFORMACIN (DSI)
4.9.4.1.-

DISEO DEL SISTEMA DE INFORMACIN
La seguridad en el diseo del sistema de informacin ser, Confidencialidad,

productos generados.
- 202 -
GCS
4.9.4.2.-
Versin: 1.0
Fecha: 18/08/05
ESPECIFICACIN DE REQUISITOS DE SEGURIDAD DEL ENTORNO

TECNOLGICO
4.9.4.3.-
REQUISITOS DE SEGURIDAD DEL ENTORNO DE CONSTRUCCIN
4.9.4.4.-
DISEO DE PRUEBAS DE SEGURIDAD
La comprobacin de la seguridad del sistema se la efectuara de la siguiente manera:
- 203 -
GCS
Versin: 1.0
Fecha: 18/08/05
Introducir en el campo clave (nombre asignado por el administrador)

Introducir en el campo password (asignado por el administrador)
Pulsar el botn ingresar
Ingresa a la aplicacin segn el perfil dado al usuario
4.9.4.5.-

PROCESO DE DISEO DEL SISTEMA DE INFORMACIN
La documentacin que se genera en el DSI es:

Arquitectura del sistema
Diseo de clases
Diseo fsico de datos
Catalogo de normas
Especificacin tcnica del plan de pruebas
4.9.5.- CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)
4.9.5.1.-

CONSTRUCCIN DEL SISTEMA DE INFORMACIN
La seguridad en la construccin del sistema de informacin ser, Confidencialidad,

productos intermedios generados.
4.9.5.2.-
EVALUACIN DE LOS RESULTADOS DE PRUEBAS DE SEGURIDAD
OBJETIVO DE LA
Seguridad a nivel de aplicacin: un usuario
TECNICA
puede acceder al sistema de acuerdo al perfil
- 204 -
GCS
Versin: 1.0
Fecha: 18/08/05
Seguridad a nivel de sistema: pueden acceder

al sistema solo los usuarios que tengan una
clave y password
TECNICA
Seguridad a nivel de aplicacin: identificar y

listar cada tipo de usuario y perfil para realizar
las pruebas
4.9.5.3.-
ELABORACIN DEL PLAN DE FORMACIN DE SEGURIDAD
USUARIOS
Administrad
PERFIL
ADMINISTRACIN
MATERIAL
Total
Administra el Sistema
Capacitacin / Manual
Gerente
Consultas
Reportes del Sistema
Cajera/o
Factura
Administra la
Venta
facturacin de venta del
or
sistema.
4.9.5.4.-

PROCESO DE CONSTRUCCIN DEL SISTEMA DE INFORMACIN
Los documentos generados en el CSI son los siguientes:
- 205 -
GCS
Versin: 1.0
Fecha: 18/08/05
Resultado y evaluacin de las Pruebas Unitarias

Evaluacin del Resultado de las Pruebas de Integracin
Evaluacin del Resultado de las Pruebas del Sistema
Especificacin de la Formacin a Usuarios Finales
4.9.6.- IMPLANTACIN Y ACEPTACIN DEL SISTEMA
Debido a que se esta siguiendo el ciclo de vida secuencial no se realizara est fase, el
4.9.7.- MANTENIMIENTO DEL SISTEMA DE INFORMACIN

4.10.- GESTION DE CONFIGURACIN

4.10.1 ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)
4.10.1.1
DEFINICIN
DE
LOS
REQUISITOS
CONFIGURACIN
- 206 -
DE
GESTIN
DE
GCS
Versin: 1.0
Fecha: 18/08/05
La gestin de configuracin del sistema SICOIN, es un documento base

para realizar los controles de versiones, estados y cambios en el sistema.
4.10.1.2
ESTABLECIMIENTO
DEL
PLAN
DE
GESTIN
DE
LA
CONFIGURACIN
Para la gestin de configuracin se utilizara el Estndar IEEE 828 1998
(Estndar IEEE para Planes de Gestin de Configuracin del Software (GCS))
(Ver Anexo 4.15)
4.10.2 ANALISIS,
DISEO,
CONSTRUCCIN
IMPLANTACIN
ACEPTACIN DEL SISTEMA DE INFORMACIN
4.10.2.1
IDENTIFICACIN Y REGISTRO DE PRODUCTOS
REGISTRO DE PRODUCTOS
VERSION ESTADO
NOMBRE
ERS
(Especificacin
de
1.0
Creado
Requisitos Software)
Documento de Diseo Funcional
LOCALIZACIN
Fase
Anlisis
del
Sistema
1.0
Creado
Mdulo de Especificacin
Funcional del sistema
Diseo Tcnico del Sistema
1.0
Creado
Fase
Diseo
del
Sistema
Desarrollo de componentes del
1.0
Creado
Sistema
Desarrollo de Procedimientos de
Fase 3 Construccin del

Sistema
1.0
Usuario
Creado
Fase 3 Construccin del

Sistema
- 207 -
GCS
4.10.2.2
Versin: 1.0
Fecha: 18/08/05
IDENTIFICACIN Y REGISTRO DE PRODUCTO GLOBAL
REGISTRO DE PRODUCTO GLOBAL

VERSION ESTADO
NOMBRE
SICOIN (Sistema de
1.0
Creado
LOCALIZACIN
SISTEMA
C:\Archivos
Control de Inventario)
de
programa\Apache
Group\Apache\htdocs\SICOIN
BASE DE DATOS
C:\servidor\mysql\data\bdd_inventarios
4.10.3 MANTENIMIENTO DEL SISTEMA DE INFORMACIN
4.10.3.1
REGISTRO DEL CAMBIO EN EL SISTEMA DE GESTIN DE LA

CONFIGURACIN

4.11.- GESTION DE PROYECTOS

4.11.1.- ACTIVIDADES DE INICIO DEL PROYECTO
- 208 -
GCS
Versin: 1.0
Fecha: 18/08/05
4.11.1.1.- ESTIMACIN DE ESFUERZO
La Estimacin de Esfuerzo aplica la tcnica de puntos de funcin, para calcular costos y

tiempo del proyecto SICOIN(Sistema de Control de Inventario).El anlisis de los puntos
de funcin se desarrolla considerando cinco parmetros bsicos externos del sistema.
Entrada ( EI External Input).

Salida ( EO External Output).
Consulta (EQ External Query).
Grupos de Datos Lgicos Internos (ILF).
Grupos de Datos Lgicos Externos (EIF)
Estos puntos se clasifican en dos funciones que son: datos y transacciones
1. FUNCIN DE DATOS
1.1 FICHEROS LGICOS INTERNOS (ILF)
FICHERO LGICO INTERNO
NMERO DE FICHEROS
Proveedores
Articulo
Socios
Factura Compra
- 209 -
GCS
Versin: 1.0
Fecha: 18/08/05
Factura Venta
Una vez identificado el nmero de ILF, es necesario valorar su complejidad

con el nmero de datos requeridos (DET) y el nmero de subgrupos identificables
(RET)
FICHERO
NUMERO
NUMERO
COMPLEJIDA
LGICO INTERNO
DET
RET
Proveedor
Baja
Articulo
Baja
Socios
Baja
Baja
Factura Compra
Baja
Baja
Factura Venta
Baja
Como resultado obtenemos que ILF:
COMPLEJIDAD
VALOR
Baja
Media
Alta
1.2 FICHERO DE INTERFAZ EXTERNA (EIF)
- 210 -
GCS
Versin: 1.0
Fecha: 18/08/05
Estos ficheros hacen referencia a grupos de datos de otra aplicacin, en

nuestro caso no existe ya que no tenemos otra aplicacin, por tanto EIF es igual a
cero.
2. FUNCIN DE TRANSACCIN
Tenemos 3 tipos de funciones:

Entradas Internas (EI)
Salidas Externas (EO)
Consultas Externas (EQ).
2.1 ENTRADAS INTERNAS (EI)
ENTRADA INTERNA
FUNCIN
NMERO
ENTRADAS
Datos Proveedor
Alta/Baja/Modificacin/Consultar
Datos Articulo
Datos Socios
Datos Factura Compra Detalle Alta/Baja/Modificacin/Consulta
Datos Compra
Alta/Baja/Modificacin/Consulta
Datos Factura Venta Detalle
Datos Compra
Con estos datos determinamos la complejidad.
ENTRADA EXTERNA
N FTR
- 211 -
N DET
COMPLEJIDA
GCS
Versin: 1.0
Fecha: 18/08/05
D
Datos Proveedor
Baja
Datos Articulo
Baja
Datos Socios
Baja
Datos Factura Compra Detalle
Alta
Datos Factura Compra
Alta
Datos Factura Venta Detalle
Alta
Datos Factura Venta
Alta
La Complejidad tiene que multiplicarse por su correspondiente peso.
ENTRADAS INTERNAS (EI)
COMPLEJIDAD
PESO
CANTIDAD
TOTAL
Alta
24
Media
Baja
2.2 SALIDAS EXTERNAS (EO)
ENTRADA EXTERNA
FUNCIN
NMERO ENTRADAS
Consulta de Proveedores
Pantalla/Papel
Consulta de Articulo
Pantalla/Papel
Consulta de Socios
Pantalla/Papel
- 212 -
GCS
Versin: 1.0
Fecha: 18/08/05
Consulta de factura Compra detalle
Pantalla/Papel
Consulta de factura venta detalle
Pantalla/Papel
Consulta de Factura Venta
Pantalla/Papel
Consulta de factura Venta
Pantalla/Papel
Con estos datos determinamos la complejidad
ENTRADA EXTERNA
N FTR
N DET
COMPLEJIDAD
Consulta de proveedores
Baja
Consulta de Articulo
Baja
Consulta de Socios
Baja
Consulta de factura Compra detalle
Alta
Consulta de factura venta detalle
Alta
Consulta de Factura Venta
Alta
Consulta de factura Venta
Alta
La Complejidad debe multiplicarse por su correspondiente peso.
SALIDAS EXTERNAS (EO)

COMPLEJIDAD
PESO
CANTIDAD
TOTAL
Alta
28
Media
Baja
12
- 213 -
GCS
Versin: 1.0
Fecha: 18/08/05
2.3 CONSULTA EXTERNAS (EQ)
ENTRADA EXTERNA
FUNCIN
NMERO
ENTRADAS
Consulta Individual de Proveedor
Pantalla/Papel
Consulta Individual de Articulo
Pantalla/Papel
Consulta Individual de socios
Pantalla/Papel
Consulta Individual de Factura Compra Detalle
Pantalla/Papel
Consulta Individual de factura Compra
Pantalla/Papel
Consulta de Individual de Factura Venta detalle
Pantalla/Papel
Consulta Individual de Venta
Pantalla/Papel
Con estos datos determinamos la complejidad.
Para la entrada
ENTRADA EXTERNA
N FTR N DET COMPLEJIDAD
Baja
Baja
Baja
Alta
Alta
- 214 -
GCS
Versin: 1.0
Fecha: 18/08/05
Alta
Consulta de Nota por Facultad
Alta
Para la salida
ENTRADA EXTERNA
N FTR N DET COMPLEJIDAD
Baja
Baja
Baja
Alta
Alta
Alta
Alta
Comparando las consultas de entrada y salida tenemos.
ENTRADA EXTERNA
CONSULTA
CONSULTA COMPLEJIDAD
ENTRADA
SALIDA
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Consulta Individual de Factura
Alta
Alta
Alta
Alta
Alta
Alta
Compra Detalle
Consulta Individual de factura
- 215 -
GCS
Versin: 1.0
Fecha: 18/08/05
Compra
Consulta de Individual de Factura
Alta
Alta
Alta
Alta
Alta
Alta
Venta detalle
La Complejidad debe multiplicarse por su correspondiente peso.
Consultas externas
COMPLEJIDAD
PESO
CANTIDAD
TOTAL
Alta
24
Media
Baja
3. CLCULO DE LOS PUNTOS DE FUNCIN SIN AJUSTAR

PARMETRO
COMPLEJIDAD
NMERO
PESO
TOTAL
ILF
Alta
15
Medio
10
Bajo
49
Alta
10
Medio
Bajo
EIF
- 216 -
GCS
EI
EO
EQ
Versin: 1.0
Fecha: 18/08/05
Alta
24
Medio
Bajo
Alta
28
Medio
Bajo
12
Alta
24
Medio
Bajo
El total de puntos de funcin sin ajustar 159, para realizar el ajuste se lo hace con
las caractersticas generales del proyecto.
CARACTERSTICA
Comunicacin de Datos
Rendimiento
Configuracin
Frecuencia de Transacciones
Diseo para la Eficiencia del Usuario Final

Procesos Complejos
X
X
Facilidad de Instalacin
Facilidad de Operacin
- 217 -
GCS
Versin: 1.0
Fecha: 18/08/05
Facilidad de Cambio
Sumando los valores presentados en la tabla obtenemos el grado de influencia TDI,

para nuestro caso es igual a 21
4. CLCULO DE PUNTOS DE FUNCIN AJUSTADOS
AF=(TDI*0.01)+0.65=(21*0.01)+0.65=0.86
RESULTADO = FPA=FP*AF
FPA=159*.0.86
FPA= 136.74
5. ESTIMACIN DEL TAMAO DE LA FUTURA APLICACIN
El lenguaje que vamos a utilizar es de cuarta generacin, que nos da factor

de sentencias igual a 20.
KDSI = ((FPA*FS)/1000)
KDSI =((136.74*20)/1000)
KDSI=2.7348
6. MTODO DE ESTIMACIN COCOMO
Para estimar el proyecto SICOIN, utilizaremos COCOMO, el cual presenta

una jerarqua de modelos que van desde el bsico, intermedio y avanzado, con
sus respectivas caractersticas. Tambin es importante tomar en cuenta el modo
de desarrollo de software, que puede ser orgnico, semiacoplado y acoplado.
- 218 -
GCS
Versin: 1.0
Fecha: 18/08/05
En nuestro caso establecemos el modelo intermedio que se ajusta a

nuestras necesidades y se desarrollar en modo orgnico por las caractersticas
siguientes.
El proyecto de software es pequeo.
El equipo de proyecto es pequeo.
Los requisitos se consideran un poco rgidos.
El entorno de desarrollo es estable.
Se adopta el modelo Intermedio, por que es toma como base el tamao de
la aplicacin y los conductores de costos.
Procedemos a continuacin a calcular el Esfuerzo.

E=3.2(2,7348) 1.05
E=3.2*2,87
E=9.184 MESES/HOMBRE
FACTOR
CLCULO DEL FACTOR DE AJUSTE

RATIO
MULTIPLICANDO
RELY
NOMINAL
DATA
BAJO
0.94
CPLX
BAJO
0.94
TIME
NOMINAL
STOR
NOMINAL
VIRT
BAJO
0.87
TURN
NOMINAL
- 219 -
GCS
Versin: 1.0
Fecha: 18/08/05
CLCULO DEL FACTOR DE AJUSTE

FACTOR
RATIO
MULTIPLICANDO
ACAP
NOMINAL
AEXP
ALTO
0.91
PCAP
NOMINAL
VEXP
ALTO
0.90
LEXP
ALTO
0.95
MODP
ALTO
0.91
TOOL
ALTO
0.91
SCED
NOMINAL
Multiplicando tenemos Fajuste = 0.495

Efinal=E*Fajuste=9.184*0.495
E final=4.546 Meses/ Hombre
Ahora calculamos el tiempo necesario para el desarrollo TDEV, el nmero

de empleados NREC y el coste del producto COST.
TDEV=2.5*(4.546)0,.38
TDEV=4.444 MESES.
CLCULO DEL NMERO DE PERSONAS
- 220 -
GCS
Versin: 1.0
Fecha: 18/08/05
EFinal
NREC= ------
= (4.444/4.546) = 1 Persona
TDEV
COST=TDEV*NREC*$1000=4.546*0.97*1000=$4409.62
6.1 ESTIMACIN DETALLADA POR FASES
Los porcentajes de esfuerzo, tiempo y recursos por fases se detallan a

continuacin, los mismos que nos servirn de base par la planificacin del
proyecto y su gestin.
FASE
ESFUERZO
TIEMPO MESES
RECURSOS
PM(%)
(DAS)
H (%)
Planificacin y requisitos
7,00
16,260
0,414
Diseo del Producto
17,00
24,130
0,677
Programacin
63,619
55,480
1,102
Diseo Detallado
26,870
Codificacin y Pruebas
36,741
20,390
0,914
Unitarias
Integracin y pruebas
19,390
Para comprobar los resultados que se han obtenido, utilizamos la COCOMO, en el cual
los valores de las ecuaciones son diferentes y trata a los problemas de Software de
- 221 -
GCS
Versin: 1.0
Fecha: 18/08/05
manera diferente. Estos nuevos valores se han obtenido de una serie de datos histricos
estadsticos de proyectos desarrollados.
Los resultados que nos entreg COCOMO fue: Los puntos de funcin
corresponden a 159, el nmero de lneas de cdigo es de 3180, valores iguales a
los obtenidos al realizar el clculo manual
El tiempo estimado del proyecto es de:
Optimista
Medio
Pesimista
5.5 meses
5.9 meses
6.3 meses
Utilizando COCOMO, se procedi a modificar los valores de las ecuaciones,

para lo cual se tom los valores que COCOMO utiliza en el modelo intermedio,
para proyectos en modo orgnico, obteniendo los siguientes resultados.
Optimista
Medio
Pesimista
3,7 meses
4,2 meses
4,9 meses
Para la planificacin utilizaremos estos valores obtenidos, que nos permiten

poner hitos para la entrega de productos. Estos valores nos dan una cierta holgura
para trabajar e ir comparando los resultados obtenidos.
4.11.1.2.- PLANIFICACIN
Este documento presenta los pasos para el desarrollo del sistema SICOIN,
el que servir de base para realizar un control del avance del proyecto.
- 222 -
GCS
Versin: 1.0
Fecha: 18/08/05
La planificacin del proyecto ayuda a establecer la viabilidad del esfuerzo,

facilitando la informacin bsica de costos y planificacin, la cual ser empleada a
lo largo de todo el proceso de Ingeniera de Software.
En trminos generales, el sistema deber proporcionar soporte a las

siguientes tareas de gestin:
Gestin de proveedor
Gestin de artculo
Gestin de socio
Gestin de factura compra
Gestin de factura venta
Para la estimacin del proyecto utilizaremos la Tcnica de Estimacin, la

documento que estima el proyecto SICOIN, para la calidad del Software, la
documentacin del Plan de Aseguramiento de Calidad del Software.
Recursos del proyecto
Personal
Ingeniero de Sistemas.
Hardware y Software
Hardware
PC con la siguiente configuracin:
Pentium de 300 Mhz.
Memoria 64 Mb.
- 223 -
GCS
Versin: 1.0
Fecha: 18/08/05
Disco duro de 3 Gb.
Software
Sistema Operativo Windows 98
Herramienta de anlisis Case Studio 2 Versin 2.19
Herramienta para gestin de proyectos Project Ver 97.
Ris2k Versin 1.0
Visual Basic Ver 6.0
Microsoft Access Ver 97
ORGANIGRAMA DEL PROYECTO SICOIN
COMIT DE DIRECCIN
EQUIPO DE GESTIN
DE CONFIGURACIN
RESPONSABLES GCS
COMIT CCC
GRUPO DE GARANTIA
DE CALIDADA
COMPONENTES GC
BIBLIOTECARIO
Fig. 4.6 Organigrama del Proyecto SICOIN
PLANIFICACIN DEL CALENDARIO
- 224 -
EQUIPO
DESARROLLO
DE
GCS
Versin: 1.0
Fecha: 18/08/05
La fecha de Inicio del proyecto es 2 de Febrero del 2005, se va ha

considerar una jornada laboral de 8 horas, con meses de 22 das, dado que la
duracin estimada es de 4 meses y medio.
El calendario de actividades con los tiempos se refleja a continuacin, estos datos han
sido obtenidos mediante el uso de COCOMO.
FASE
TIEMPO ESTIMADO
Planificacin y Requisitos
16,260
Diseo del Producto
24,130
Programacin
55,480
Integracin y Pruebas del Sistema
20,390
Planificacin de costos
De acuerdo a los resultados obtenidos al aplicar la formula y tomando cmo
base de sueldo medio de 1.000 dlares, el resultado es de 4.450 dlares.
Detalle de la planificacin
- 225 -
GCS
Versin: 1.0
Fecha: 18/08/05
Presentamos la distribucin de tiempo en el cronograma.
4.11.2.- ACTIVIDADES DE SEGUIMIENTO Y CONTROL
4.11.2.1.- ASIGNACIN DETALLADA DE TAREAS
TAREAS
RESPONSABLES
Comit de Direccin
Gladys Aguagallo
Paulina Caizares
Equipo de Gestin de Configuracin
Gladys Aguagallo
Paulina Caizares
Grupo de Garanta de Calidad
Gladys Aguagallo
Paulina Caizares
Equipo de Desarrollo
Gladys Aguagallo
Paulina Caizares
Responsables de GCS
Gladys Aguagallo
Paulina Caizares
Componentes GC
Gladys Aguagallo
Paulina Caizares
Comit CCC
Gladys Aguagallo
Paulina Caizares
Bibliotecario
Gladys Aguagallo
Paulina Caizares
4.11.2.2.- COMUNICACIN AL EQUIPO DEL PROYECTO
Se comunica al equipo de trabajo las actividades que deber realizar.
- 226 -
GCS
Versin: 1.0
Fecha: 18/08/05
TAREAS
RESPONSABLES
Comit de Direccin
Gladys Aguagallo
Paulina Caizares
Equipo de Gestin de Configuracin
Gladys Aguagallo
Paulina Caizares
Grupo de Garanta de Calidad
Gladys Aguagallo
Paulina Caizares
Equipo de Desarrollo
Gladys Aguagallo
Paulina Caizares
Responsables de GCS
Gladys Aguagallo
Paulina Caizares
Componentes GC
Gladys Aguagallo
Paulina Caizares
Comit CCC
Gladys Aguagallo
Paulina Caizares
Bibliotecario
Gladys Aguagallo
Paulina Caizares
4.11.2.3.- SEGUIMIENTO DE TAREAS
El seguimiento de las tareas se lo realizara siguiendo el cronograma y se lo

registrara en el formulario siguiente:
FORMULARIO DE REVISIONES DE TAREAS
- 227 -
GCS
Versin: 1.0
Fecha: 18/08/05
SICOIN
1. FECHA DE REVISIN: ____/____/_____
2. TAREA:
______________________________________________________________
______________________________________________________________
3. FECHA DE INICIO DE LA TAREA: ____/____/______
4. FECHA DE FINALIZACIN DE LA TAREA: ____/____/______
5. PARTICIPANTES
6. TIEMPO EMPLEADO HASTA LA REALIZACIN DE LA REVISIN

________________________
7. PORCENTAJE DE TRABAJO REALIZADO

_____________________________
8. PRESENTA INCIDENCIAS
SI ( )
En caso de SI llenar formulario de Incidencias
9. FIRMAS
- 228 -
NO ( )
GCS
Versin: 1.0
Fecha: 18/08/05
GESTION DE INCIDENCIAS
4.11.2.4.- ANALISIS Y REGISTRO DE LA INCIDENCIA
FORMULARIO DE INCIDENCIAS
SICOIN
1. FECHA: ____/_____/_______
2. NUMERO DE DEFECTOS ENCONTRADOS: ___________________________
3. NOMBRES DE LAS INCIDENCIAS

__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
4. RESPONSABLES
__________________________________________________________________
__________________________________________________________________
5. TIEMPO PERDIDO: ______________________________________________

6. SOLUCION DE INCIDENCIA
__________________________________________________________________
__________________________________________________________________
__________________________________________________________________
7. FIRMAS:
__________________________________________________________________
- 229 -
GCS
Versin: 1.0
Fecha: 18/08/05
GESTIN DE CAMBIOS DE LOS REQUISITOS

4.11.2.5.- PETICIN DE CAMBIO DE REQUISITOS
SOLICITUD DE CAMBIO
SICOIN
SOLICITUD DE CAMBIO
1. Nombre del Sistema: _____________________________________________
2. # de Control: ___________________________________________________
3. Niveles de Aplicacin
Sistema ___ Hardware___ Software____ Documentacin____ Otros____
4. Solicitud de Cambios
Org. Originadora ________________________ Originador ______________
# Telefonico _____________ Fecha: ___/___/______
5. ECS Afectados
______________________________________________________________
6. Documentos Afectados
______________________________________________________________
7. Prioridad
Rutinario ____ Urgente ____ Emergente ____
8. Descripcin del Cambio
______________________________________________________________
9. Necesidades para el Cambio
______________________________________________________________
10. Afecta a otros Sistemas Software / Equipamiento el cambio
Si ____ No ____
En caso de seleccionar la opcin Si explicar en el siguiente punto.
11. Efectos estimados sobre otros Sistemas / software / Equipamiento
- 230 -
GCS
Versin: 1.0
Fecha: 18/08/05
_____________________________________________________________
12. Alternativas
_____________________________________________________________
Esta rea debe ser contestada por el responsable de la GCS
13. Fecha de recepcin ____/____/______

14. Disposicin ___________________________________________________
15. Firma: _____________________________ Fecha: ____/____/____
4.11.2.6.- ANALISIS DE LA PETICIN DE CAMBIO DE REQUISITOS
CERTIFICACIN DEL CAMBIO

SICOIN
1. NOMBRE DEL SISTEMA

______________________________________________________________
3. # DE CONTROL
______________________________________________________________
4. ORIGINADOR DEL CAMBIO
______________________________________________________________
5. REALIZADOR DEL CAMBIO
______________________________________________________________
6. RESULTADOS DEL CAMBIO
______________________________________________________________
7. DISPOSICIN
______________________________________________________________
8. FIRMA
______________________________________________________________
- 231 -
GCS
Versin: 1.0
Fecha: 18/08/05
9. FECHA
____/____/_______
4.11.2.7.- APROBACIN DE LA SOLUCIN
FORMULARIO DE APROBACIN DEL CAMBIO
SICOIN
1. FECHA: ____/____/_______
2. NOMBRE DEL CAMBIO
________________________________________________________________
________________________________________________________________
3. ESTADO DEL CAMBIO
APROBADO (
REPROBADO (
4. COSTOS DEL CAMBIO

________________________________________________________________
5. FECHA DE REALIZACIN DEL CAMBIO: ____/____/___________
6. RESPONSABLES
7. FIRMAS
- 232 -
GCS
Versin: 1.0
Fecha: 18/08/05
________________________________________________________________
4.11.2.8.- ESTIMACIN
DEL
ESFUERZO
PLANIFICACIN
DE
LA
SOLUCIN
Esta actividad se la realiza cuando existe la peticin de cambios para modificar la

planificacin con los respectivos cambios, en este caso no tenemos cambios por lo que
no lo realizamos.
4.11.2.9.- REGISTRO DEL CAMBIO DE REQUISITOS
REGISTRO DE CAMBIOS
NOMBRE
N CONTROL
DESCRIPCIN
CAMBIO
XXX
FECHA
CAMBIO
XXX
XXXXXXXXX
DD/MM/YYYY
4.11.2.10.- FINALIZACIN DE LA TAREA
FORMULARIO DE FINALIZACIN
SICOIN
1. RESPONSABLE
2. TAREA:
_______________________________________________________
- 233 -
GCS
Versin: 1.0
Fecha: 18/08/05
3. FECHA DE INICIO: ____/____/_______
4. FECHA DE FINALIZACIN: ____/____/_______
5. FIRMAS ___________________________
4.11.2.11.- ACTUALIZACIN DE LA PLANIFICACIN
Esta actualizacin la realiza el jefe del proyecto a la planificacin realizada

en la actividad de inicio del proyecto de la gestin de proyectos, para lo cual se
debe seguir el desarrollo del sistema.
Tomando en cuenta la planificacin efectuada, se verifica el cumplimiento

del periodo estimado para cada tarea, caso contrario se actualizara la
planificacin.
4.11.2.12.- REUNIONES DE SEGUIMIENTO
Esta reunin se realiza para seguir el desarrollo del sistema y verificar el cumpliendo de
los periodos de desarrollo de cada tarea con la planificacin, en donde el jefe de
proyecto puede realizar algunos ajustes y resolver los incidentes presentados por parte
del equipo de proyecto.
4.11.2.13.- ACEPTACIN
- 234 -
GCS
Versin: 1.0
Fecha: 18/08/05
El jefe del proyecto acepta una vez que verificados que los resultados son los esperados.
CAPITULO V
V.- CONCLUSIONES Y RECOMENDACIONES
5.1.- CONCLUSIONES
En esta tesis se ha revisado y aplicado los principales estndares IEEE

relacionados al desarrollo del producto software, ayudando a garantizar la
calidad del producto.
La estandarizacin de un producto software ayuda a garantizar la calidad y

da importancia a la satisfaccin del cliente, sobre todo mejora la relacin
empresa-cliente. Ya que estos estndares generan la documentacin
necesaria para que pueda utilizar cualquier otra persona, independiente del
desarrollador del producto software.
Como resultado de la aplicacin de Mtrica Versin 3 y los Estndares

IEEE se desarrollo el Sistema de Inventario, el que esta acorde a los
requisitos del cliente, alcanzando la satisfaccin del mismo, as como la
- 235 -
GCS
Versin: 1.0
Fecha: 18/08/05
prevencin de no conformidades y el proceso de mejora continua. La

utilizacin de una metodologa y de estndares no es garanta de xito, ya
que esto facilita el proceso de desarrollo del producto y no el xito del
mismo ya que si no se aplica correctamente no se obtendr lo que se desea
que es un producto de calidad.
El Sistema de Inventario para el comisariato de la cooperativa San Antonio,

contribuir con las tareas que se realizan en este departamento,
permitiendo de esta manera alcanzar mayor rendimiento y aprovechamiento
del recurso informtico. Este sistema de informacin puede ser aplicado a
cualquier comisariato por que todos manejan los mismos conceptos.
5.2 RECOMENDACIONES
Se recomienda que se incorpore la utilizacin de los Estndares IEEE en el

desarrollo del producto software, para poder aportar mayor calidad a las
soluciones informticas.
Se recomienda que las empresas dedicadas al desarrollo de sistemas,

verifiquen antes de seleccionar la metodologa y las herramientas a seguir
que cumplan con algunos de los principales estndares IEEE, para el
desarrollo del producto software.
La utilizacin de los Estndares IEEE es recomendable ya que estos nos

ayudad a tener la documenta de la informacin que se ha generada en el
trascurso del desarrollo del producto software.
- 236 -
GCS
Versin: 1.0
Fecha: 18/08/05
ANEXO 1.1
- 237 -
GCS
Versin: 1.0
Fecha: 18/08/05
HERRAMIENTAS CASE
Las herramientas CASE son un acrnimo en ingls de Computer Aided
Software Engineering, que viene a significar Ingeniera de Software Asistida por
Ordenador y son instrumentos o sistemas automatizados que brindan soporte a
las actividades de produccin de software.
Se pueden clasificar en:
CASE superior (Upper CASE) Fase de Planificacin
y Gestin de
Proyectos.
CASE intermedio (Middle CASE) Referidas a la automatizacin del
Anlisis y Diseo de Sistemas de Informacin.
- 238 -
GCS
Versin: 1.0
Fecha: 18/08/05
CASE inferior (Lower CASE) asistencia del ordenador en la construccin

(Programacin y generacin de cdigo) de los sistemas de informacin.
TIPOS DE HERRAMIENTAS
Las herramientas se pueden clasifican en:
Herramientas de Diagramacin.
Herramientas de Generadores de pantallas e informes (Prototipado
interfaces ).
Herramientas de Repositorios e informes.,
Herramientas de Verificacin y Anlisis.
Herramientas de Generadores de Cdigo
Herramientas de Mantenimiento.
Herramientas de Planificacin.
- 239 -
GCS
Versin: 1.0
Fecha: 18/08/05
ANEXO 1.2
VISIN GENERAL DE LA INGENIERA DE SOFTWARE
DEFINICIO
Fallo de
definicin
DESARROLL
O
Errores
Modificaciones y Adaptaciones
- 240 -
MANTENIMIEN
TO
GCS
Versin: 1.0
Fecha: 18/08/05
1.- DEFINICIN (Se centra en el qu):
Qu debe hacer el sistema?

El sistema genera informacin que ha de manejar el sistema como:
Necesidades de rendimiento, Restricciones de diseo, Interfaces del sistema con
los usuarios y con otros sistemas, Criterios de validacin, Se elaboran los
documentos de requisitos del sistema (SyRS) y del software (SRS).
2.-DESARROLLO (Se centra en el cmo):
Cmo construir el sistema?
Se construye Diseando las estructuras de los datos y los programas como

son: Caractersticas de las interfaces, Paso del diseo al lenguaje de
programacin, Pasos para realizarse las pruebas , Se escriben y documentan los
programas y Se prueba el software construido.
3.- MANTENIMIENTO (Se centra en el cambio que va asociado a la correccin de

errores, a las adaptaciones requeridas por la evolucin del entorno del software y
a las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a
reforzar o ampliar el sistema).
Esta fase comienza una vez construido el sistema y es cuando se empieza

a utilizar, se centra en el cambio, el software es sometido a reparaciones y
modificaciones cada vez que se detecta un fallo o se necesita cubrir una nueva
necesidad de los usuarios. En esta fase recae el mayor porcentaje del costo de un
sistema.
- 241 -
GCS
Versin: 1.0
Fecha: 18/08/05
En esta fase tenemos cuatro tipos de mantenimiento para un sistema que

son:
Correctivo: Es un programa, no realiza correctamente la aplicacin para la

que ha sido diseado, y por lo tanto, debe ser modificado.
Perfectivo: Son modificaciones a los programas, para conseguir mayor

adecuacin a los requisitos, mayor eficiencia, o simplemente recoger
nuevas funcionalidades no expresadas en la fase de definicin del sistema.
Adaptativo: Es adaptar los programas para acomodarlos a los cambios de

su entorno externo (modificaciones en la legislacin, CPU, S.O. las reglas
de negocio, etc.)
Preventivo: El software se deteriora con los cambios, y este tipo de

mantenimiento hace cambios en los programas para que se puedan
corregir, adaptar y mejorar ms fcilmente (Reingeniera del software).
- 242 -
GCS
Versin: 1.0
Fecha: 18/08/05
ANEXO 2.1
INFORMACIN DE ESTNDARES
IEEE STD 610.12 - 1990 (R2002)
ESTNDAR IEEE PARA GLOSARIO DE TERMINOLOGA DE
INGENIERA DE SOFTWARE
CONTENIDOS
1.- Estructura del Glosario
2.- Definiciones de trminos
1.- ESTRUCTURA DEL GLOSARIO
- 243 -
GCS
Versin: 1.0
Fecha: 18/08/05
Los trminos en el glosario deben ser organizados en orden alfabtico y

pueden ser de una sola palabra, frase o siglas, si un trmino tiene ms de una
definicin estas deben ser numeradas.
2.- DEFINICIONES DE TERMINOS
Se define los trminos con sus respectivos significados.
IEEE STD 730 - 2002
ESTNDAR IEEE PARA PLANES DE ASEGURAMIENTO DE

CALIDAD DE SOFTWARE (SQAP)
CONTENIDO
1.- Plan de Aseguramiento de Calidad de Software
1.1.- Propsito
1.2.- Documentos de Referencia
- 244 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.3.- Administracin
1.4.- Documentacin
1.5.- Estndares, Practicas y Mtricas
1.6.- Revisiones de Software
1.7.- Pruebas
1.8.- Reporte de Problemas y Acciones Correctivas
1.9.- Herramientas, Tcnicas y Metodologa
1.10.- Control de Medios de Comunicacin
1.11.- Control de Proveedor
1.12.- Coleccin de Registros, Mantenimiento y Retencin
1.13.- Capacitacin
1.14.- Gestin de Riesgo
1.15.- Procedimiento de Cambio SQAP e Historia
1.- PLAN DE ASEGURAMIENTO DE CALIDAD DE SOFTWARE
El SQAP tiene en la primera pgina la fecha de emisin, el estado del

documento y la identificacin de la organizacin que realiza el documento, este
ser aprobado por el gerente de cada unidad de organizacin.
1.1.- PROPSITO
Est seccin detalla el objetivo especifico y mbito particular del SQAP, se debe incluir
el nombre y uso del software sealando en que fase del ciclo de vida del software se
aplicar el SQAP.
- 245 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.2.- DOCUMENTOS DE REFERENCIA
Esta seccin lista los documentos que fueron utilizados para desarrollar el SQAP, estos
documentos incluyen las polticas y leyes que llevaron a desarrollar este plan, La versin
y fecha de cada documento debe estar incluido en la lista.
1.3.- ADMINISTRACIN
Esta seccin describe la estructura de la organizacin del proyecto, sus tareas, papeles y
responsabilidades.
1.3.1.- ORGANIZACIN
Esta seccin trata la estructura organizacional que interviene y controla la calidad del
software y describe los principales elementos de la organizacin, para verificar, evaluar
y monitorear la calidad del software, siendo la organizacin la responsable de preparar y
mantener el SQAP.
1.3.2.-
TAREAS
Esta seccin describe:

Fase del ciclo de vida en la que se aplicara el SQAP
Tareas a realizarse
Criterio de entrada y salida de cada tarea
- 246 -
GCS
Versin: 1.0
Fecha: 18/08/05
Relacin y secuencia de las tareas

Horario del plan
1.3.3.-
PAPELES Y RESPONSABLES
Esta seccin identifica los elementos especficos de la organizacin que es responsable

de las tareas.
1.3.4.-
EVALUACIN DE RECURSOS DE ASEGURAMIENTO DE CALIDAD
Esta seccin evala los recursos y costos a ser consumidos en el aseguramiento y control
de la calidad.
1.4.-
DOCUMENTACIN
1.4.1.-
PROPSITO
Esta seccin realiza las siguientes funciones:

Identifica la documentacin para controlar el desarrollo, verificando y valida
el uso y mantenimiento del software.
Lista los documentos que deben ser revisado
1.4.2.-
REQUISITOS MNIMOS DE DOCUMENTACIN
Esta seccin asegura que la implementacin del software cumple con los
documentos bsicos para satisface los requisitos tcnicos.
1.4.2.1.-
DESCRIPCIN DE LOS REQUISITOS DEL SOFTWARE (SRD)
- 247 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin especifica los requisitos que pueden ser escritos por el
proveedor (interno o externo), cliente o ambos, cada requisito debe ser identificado
y definido nicamente para verificar y validar objetivamente.
1.4.2.2.- DESCRIPCIN DEL DISEO DEL SOFTWARE (SDD)
Esta seccin toma la estructura del software para satisfacer los requisitos (SRD). El SDD
debe describir los componentes y subcomponentes del diseo del software incluyendo la
base de datos e interfaz interna para lo cual se puede realizar un prototipo.
1.4.2.3.- PLAN DE VERIFICACIN Y VALIDACIN
Esta seccin se utiliza para determinar que el producto software este

acorde a los requisitos y si cumple con las expectativas del usuario. El plan de
verificacin y validacin puede ser adjuntado a un solo documento y define la
verificacin y validacin de tareas, entrada y salida de informacin
para
salvaguardar el nivel de integridad del software.
1.4.2.4.- REPORTE DE RESULTADOS DE VERIFICACIN Y VALIDACIN
Esta seccin describe los resultados de las actividades realizadas en el software de

acuerdo al plan.
1.4.2.5.- DOCUMENTACIN DEL USUARIO
- 248 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin gua al usuario en la instalacin, operacin, administracin y

mantenimiento del producto software, este documento describe el control y la secuencia
de la informacin de entrada, opciones, limitaciones del programa y otra informacin,
con este documento el usuario puede manipular el sistema.
1.4.2.6.- PLAN DE GESTIN DE CONFIGURACIN DEL SOFTWARE (SMCP)

Esta seccin documenta las actividades del SMCP en el que se definen las rutas para mantener, guardar, asegurar, controlar y documentar
las versiones en las bibliotecas, este plan se aplica a la parte del ciclo de vida que se desarrolle el SQAP.
1.4.2.7.- OTRA DOCUMENTACIN
Esta seccin identifica otros documentos aplicables al proyecto de desarrollo del

software, puede incluir los siguientes documentos:
Plan de proceso de desarrollo

Mtodos de Ingeniera de software/proceso/descripcin de herramientas.
Plan de Gestin del proyecto software
Plan de mantenimiento
Plan de seguridad del software
Plan de integracin del software.
1.5.-
ESTNDARES, PRACTICAS Y MTRICAS
1.5.1.- PROPSITO
- 249 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin identifica los estndares, prcticas y mtricas a ser aplicadas, acorde a estos
trminos sern aplicados y asegurados.
1.5.2.- CONTENIDO
Documentacin del estndar

Diseo del estndar
Codificacin del estndar
Comentario del estndar
Producto de aseguramiento de calidad del software
1.6.-
REVISINES DE SOFTWARE
1.6.1.- PROPSITO
Esta seccin describe:

La revisin de software a ser desarrollada
El horario para las revisiones del software
Las acciones futuras que se pueden requerir y como deben ser
implementadas y verificadas.
1.6.2.- REQUERIMIENTOS MNIMOS
1.6.2.1.-
REVISIN DE LAS ESPECIFICACIONES DEL SOFTWARE (SSR)
- 250 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin asegura la validez de los requisitos indicados en la descripcin de los

requisitos del software.
1.6.2.2.-
REVISIN DEL DISEO ARQUITECTNICO (ADR)
Esta seccin evala los arreglos tcnicos del diseo preliminar, detallados
en la descripcin del diseo del software.
1.6.2.3.-
REVISIN DEL DISEO DETALLADO (DDR)
Esta seccin determina la aceptacin del diseo detallado en la descripcin del diseo
del software para satisfacer la descripcin de los requisitos del software.
1.6.2.4.-
REVISIN DEL PLAN DE VERIFICACIN Y VALIDACIN
Esta seccin evala la eficacia y totalidad del plan de verificacin y validacin.

1.6.2.5.-
AUDITORIA FUNCIONAL
Esta seccin realiza la auditoria al software y verifica que todos los requisitos que se han
detallado en la descripcin de los requisitos del software son los correctos.
1.6.2.6.-
AUDITORIA FSICA
Esta seccin verifica la consistencia interna del software.
1.6.2.7.-
AUDITORIA DE PROCESOS
- 251 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin verifica la consistencia del diseo:
Cdigo vs. diseo de documentacin

Especificacin de Interfaz
Implementacin de diseo vs. requerimientos funcionales
1.6.2.8.-
REVISIONES DE GESTION
Esta seccin valora la ejecucin de todas las acciones y trminos identificados en el

SQAP. Las revisiones de gestin son llevadas a cabo por el personal que gestiona el
sistema, est puede requerir cambios adicionales en el SQAP.
1.6.2.9.-
REVISIN DEL PLAN DE GESTIN DE CONFIGURACIN DEL

SOFTWARE (SCMPR)
Esta seccin evala la documentacin y actividades del SCMP.
1.6.2.10.- REVISIN DE IMPLEMENTACIN
Esta seccin se realiza para valorar el desarrollo del proyecto una vez
concluido.
1.7.-
PRUEBAS
- 252 -
GCS
Versin: 1.0
Fecha: 18/08/05
Est seccin realiza las evaluaciones no contenidas en el Plan de validacin y

verificacin del software, pero si son parte del SQAP.
1.8.-
REPORTES DE PROBLEMAS Y ACCIONES CORRECTIVAS
Esta seccin describe las prcticas y procedimientos para realizar los reportes de
problemas y reportes correctivos en el desarrollo, mantenimiento e implementacin del
software.
1.9.-
HERRAMIENTA TECNICA Y METODOLOGIA
Esta seccin describe el propsito del uso, aplicacin y limitaciones de esta herramienta,
tcnica y metodologa en el proceso del SQAP.
1.10.- CONTROL DE MEDIOS DE COMUNICACIN
Esta seccin identifica el medio de comunicacin de cada estacin de trabajo por

producto y la documentacin protegiendo el medio fsico de acceso no autorizado o
degradacin de las fases del ciclo de vida del software.
1.11.- CONTROL DE PROVEEDOR
Esta seccin asegura que el software entregado por el proveedor cumple con los
requisitos establecidos previamente para su desarrollado, se debe especificar los mtodos
- 253 -
GCS
Versin: 1.0
Fecha: 18/08/05
a ser usados para asegurar lo inteligente del producto con el SQAP. El proveedor debe
preparar e implementar un acuerdo antes de desarrollar el software con el cliente en el
que se indique los mtodos a ser empleados para que se cumpla con los requisitos del
SQAP, si el software se desarrolla bajo un contrato, entonces los procedimientos de
revisin del contrato y actualizacin deben ser descritos.
1.12.- COLECCIN DE REGISTROS, MANTENIMIENTO Y RETENCIN
Esta seccin identifica la documentacin del SQAP que ser retenida y los mtodos
utilizados para guardar y proteger est documentacin, tambin tendr el perodo de
retencin del documento.
1.13.- CAPACITACIN
Esta seccin contiene las actividades necesarias para cumplir con la

ejecucin del SQAP.
1.14.- GESTIN DE RIESGO
Esta seccin especifica los mtodos y procedimientos empleados para identificar, valorar
y controlar las reas de riesgo durante las fases del ciclo de vida del software a ser
cubiertas por el SQAP.
1.15.- PROCEDIMIENTO DE CAMBIO SQAP E HISTORIA
- 254 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin contiene los procesos para ir modificando el SQAP y mantiene un historial
de los cambios y las modificaciones.
IEEE STD 828 1998
ESTNDAR IEEE PARA PLANES DE GESTIN DE

CONFIGURACIN SOFTWARE (SCMP)
CONTENIDO
2.-
1.-
Plan de Gestin de Configuracin de Software (SCMP)

2.1.-
Introduccin
2.2.-
Gestin SCMP
2.3.-
Actividades SCMP
2.4.-
Horario SCMP
2.5.-
Recursos SCMP
2.6.-
Plan de Mantenimiento SCMP
PLAN DE GESTIN DE CONFIGURACIN SOFTWARE (SCMP)
- 255 -
GCS
Versin: 1.0
Fecha: 18/08/05
La informacin del SCMP puede ser presentada en cualquier formato, secuencia o

localizacin, este documento debe tener un ttulo y definir un formato para el
documento.
1.1.-
INTRODUCCIN
Esta seccin incluye:
Propsito
Alcance
Definiciones y Acrnimos
Referencias
1.1.1.-
PROPSITO
Est seccin detalla el objetivo especifico y mbito particular del SCMP.
1.1.2.-
ALCANCE
Esta seccin describe la aplicacin, limitacin y antecedentes de desarrollo del proyecto

software e identifica otro software a ser incluido como parte del plan.
1.1.3.-
DEFINICIONES Y ACRNIMOS
Esta seccin establece una terminologa comn entre todos los usuarios del
plan.
- 256 -
GCS
1.1.4.-
Versin: 1.0
Fecha: 18/08/05
REFERENCIAS
Esta seccin describe los documentos relacionados, estos se identifican

individualmente.
1.2.-
GESTIN SCMP
Esta seccin incluye 3 temas:
Organizacin
Responsables
Polticas, Directivas y Procedimientos
1.2.1.-
ORGANIZACIN
Esta seccin identifica los equipos que participan o son responsables de cualquier
actividad en el SCMP y las relaciones de equipos.
1.2.2.-
RESPONSABLES
Esta seccin asigna responsables para las actividades del SCM.
1.2.3.-
POLITICAS, DIRECTIVAS Y PROCEDIMIENTOS
Esta seccin describe las restricciones externas del plan
1.3.-
ACTIVIDADES SCMP
- 257 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin incluye:
Identificacin de Configuracin
Control de Configuracin
Auditoria de Configuracin
1.3.1.-
IDENTIFICACIN DE CONFIGURACIN
Esta seccin identifica el nombre y describe las caractersticas fsicas y

funcionales de la documentacin en sus respectivas fases del ciclo de vida del
software, los elementos de configuracin a ser controlados se identifican en los
tems de configuracin (CI) y la estructura de cada lnea base, tiene la versin y
descripcin de cada elemento.
1.3.2.-
CONTROL DE CONFIGURACIN
Esta seccin identifica y documenta los cambios de las lneas bases de los
tems de configuracin, los cambios incluyen documentacin para realizar el
cambio, anlisis y evaluacin de la peticin de cambio, aprobacin o
desaprobacin de la peticin, verificacin, implementacin
y realizacin del
cambio.
1.3.3.-
AUDITORIA DE CONFIGURACIN
Esta seccin describe e identifica las revisiones a ser aplicadas en el

proyecto y define el objetivo, horario, procedimiento, participantes, registro de
acciones correctivas y aprobacin.
1.4.-
HORARIO SCMP
- 258 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin establece la secuencia y coordinacin de la informacin para identificar las

actividades del SCMP y para todos los programas afectados en este plan, este horario
incluye la duracin del plan y puede ser representado en un grfico o comunicar est
informacin.
1.5.-
RECURSOS SCMP
Esta seccin identifica las herramientas, tcnicas, equipos, personal y necesidades de

capacitacin para implementar el SCMP.
1.6.-
PLAN DE MANTENIMIENTO SCMP
Esta seccin identifica las actividades y responsables para asegurar el SCMP durante el
ciclo de vida del software, est documentacin debe ser revisada al inicio de cada fase
con los cambios y aprobaciones.
- 259 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 829 1998
ESTNDAR IEEE PARA DOCUMENTACIN DE PRUEBAS DE

SOFTWARE
CONTENIDO
2.-
Plan de Pruebas
1.3.-
Propsito
1.3.1.- Identificacin del Plan de Pruebas

1.3.2.- Introduccin
1.3.3.- Items de Pruebas
1.3.4.- Caractersticas a ser Probadas
1.3.5.- Caractersticas a no ser Probadas
1.3.6.- Aproximacin
1.3.7.- Criterio de Item Pasa/Falla
1.3.8.- Criterios de Suspencin y Requisitos de Reanudacin
1.3.9.- Pruebas a Entregar
1.3.10.-
Tareas de Pruebas
1.3.11.-
Necesidades del Entorno
1.3.12.-
Responsabilidades
1.3.13.-
Necesidades del Personal y Capacitacin
1.3.14.-
Horarios
1.3.15.-
Riesgos y contingencias
1.3.16.-
Aprobacin
1.4.-
Registro de Pruebas
- 260 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.- PLAN DE PRUEBAS

1.1.- PROPSITO
Esta seccin describe el alcance, mbito, recursos, horario de actividades,

responsable para cada tarea y el riesgo asociado con este plan.
1.1.1.-
IDENTIFICACIN DEL PLAN DE PRUEBAS
Esta seccin asigna el identificador al plan.
1.1.2.-
INTRODUCCIN
Esta seccin describe las caractersticas a ser probadas y la referencia de

los siguientes documentos: autorizacin de proyecto, plan de proyecto, plan de
aseguramiento de calidad, plan de gestin de configuracin y estndares si estos
existen.
1.1.3.-
ITMS DE PRUEBAS
Esta seccin especifica las caractersticas de los requisitos lgicos o fsicos

antes de probar, el nivel, versin y revisin del tems de pruebas. La siguiente
documentacin es de referencia en caso de que exista: especificacin de
requerimientos, especificacin de diseo, gua del usuario, gua de operacin y
gua de instalacin del software.
- 261 -
GCS
1.1.4.-
Versin: 1.0
Fecha: 18/08/05
CARACTERSTICAS A SER PROBADAS
Esta seccin identifica todas las caractersticas y combinaciones del software a ser
probadas.
1.1.5.-
CARACTERSTICAS A NO SER PROBADAS
Esta seccin identifica todas las caractersticas y combinaciones del software que no
sern probadas y sus razones.
1.1.6.-
APROXIMACIN
Esta seccin especifica las actividades principales, tcnicas y herramientas

que se utilizan para probar las caractersticas. La aproximacin debe ser descrita
para identificar las tareas principales y estimar el tiempo requerido
1.1.7.-
CRITERIO DE ITEM PASA / FALLA
Esta seccin especifica el criterio a ser utilizado para determinar cada tem que pasa o
falla en la prueba.
1.1.8.-
CRITERIOS DE SUSPENSIN Y REQUISITOS DE REANUDACIN
- 262 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin especifica el criterio utilizado para suspender todo o una parte de las
actividades de prueba, est actividad debe repetirse cuando la prueba es resumida.
1.1.9.-
PRUEBAS A ENTREGAR
Esta seccin incluye los siguientes documentos: plan de prueba, especificaciones de

diseo de prueba, especificaciones de caso de prueba, especificaciones de procedimiento
de prueba, reportes de transmisin de tems de prueba, registro de pruebas, reportes de
incidentes de pruebas, reportes de pruebas.
1.1.10.-
TAREAS DE PRUEBAS
Esta seccin identifica todas las dependencias de tareas internas y
la
capacitacin requerida.
1.1.11.-
NECESIDADES DEL ENTORNO
Esta seccin describe las caractersticas fsicas y de comunicaciones, sistema de

software, nivel de seguridad y herramientas.
1.1.12.-
RESPONSABILIDADES
Esta seccin identifica los grupos responsables de administrar, disear, preparar,

ejecutar y revisar las pruebas.
1.1.13.-
NECESIDADES DEL PERSONAL Y CAPACITACIN
- 263 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin especifica las pruebas al personal por nivel de habilidades e identifica
las opciones de capacitacin.
1.1.14.-
HORARIOS
Esta seccin describe los horarios del proyecto y estima el tiempo requerido para hacer
cada tarea.
1.1.15.-
RIESGOS Y CONTINGENCIAS
Esta seccin describe las suposiciones de alto riesgo del plan, especifica los planes
de contingencia que requieren horarios que cumplan con la fecha de entrega.
1.1.16.-
APROBACIN
Esta seccin especifica los nombres y ttulos de todas las personas que aprobaran el
plan. Provee espacio para las firmas y fechas.
2.-
REGISTRO DE PRUEBAS
2.1.-
PROPSITO
Esta seccin describe la ejecucin de las pruebas.
2.2.-
IDENTIFICADOR DE REGISTRO DE PRUEBAS
Esta seccin asigna el identificador al plan.
- 264 -
GCS
2.3.-
Versin: 1.0
Fecha: 18/08/05
DESCRIPCIN
Esta seccin identifica los trminos que van hacer probados y los atributos del
entorno, para ejecutar las pruebas.
2.4.-
ACTIVIDADES Y ENTRADAS DE SUCESOS
Esta seccin registra las fechas de incidencias, tiempo y responsable.
IEEE STD 830 - 1998
PRACTICA RECOMENDADA IEEE PARA LA ESPECIFICACIN

DE REQUISITOS SOFTWARE (ERS)
CONTENIDO
1.- Partes del ERS
1.4.- Introduccin
- 265 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.4.1.-
Propsito
1.4.2.-
Alcance
1.4.3.-
Definicin, Siglas y Abreviaturas
1.4.4.-
Referencias
1.5.- Descripcin General

1.5.1.-
Perspectiva del Producto
1.5.2.-
Funciones del Producto
1.5.3.-
Caractersticas del Usuario
1.5.4.-
Restricciones
1.5.5.-
Suposiciones y dependencias
1.6.- Requisitos Especficos

1.6.1.-
Requisitos Funcionales
1.6.2.-
Requisitos de Interfaces Externas
1.6.3.-
Requisitos de Rendimiento
1.6.4.-
Requisitos de Desarrollo
1.6.5.-
Requisitos Tecnolgicos
1.6.6.-
Atributos
1.-
PARTES DEL ERS
1.1.-
INTRODUCCIN
Esta seccin proporciona una apreciacin global del ERS completo.
1.1.1.-
PROPSITO
- 266 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin detalla el objetivo especifico y mbito particular del ERS.
1.1.2.-
ALCANCE
Esta seccin describe el producto software para disear y explicar lo que har y los
beneficios que tendr.
1.1.3.-
DEFINICION, SIGLAS, Y ABREVIATURAS

Esta seccin proporciona las definiciones de todos los trminos, siglas, y abreviaturas que
tendr el ERS.
1.1.4.-
REFERENCIAS
Esta seccin describe la documentacin relacionada, estos se identifican

individualmente.
1.2.-
DESCRIPCIN GENERAL
Esta seccin describe los factores generales que afectan el producto y sus requisitos.
1.2.1.-
PERSPECTIVA DEL PRODUCTO
Esta seccin describe el producto en caso de ser independiente o si es

dependiente de otro sistema ms grande entonces debe especificar los requisitos
- 267 -
GCS
Versin: 1.0
Fecha: 18/08/05
y las interfaces entre ese sistema y el software, en este caso debe describir como
operar el software.
En
las
interfaces
de
Sistema,
Usuario,
Hardware,
Software,
Comunicaciones, Memoria, Funcionamientos y Requisitos de adaptacin de Sitio.
1.2.1.1.-
INTERFACES DE SISTEMA
Esta seccin detalla cada interfaz e identifica la funcionalidad del software para sacar los
requisitos del sistema y las interfaces.
1.2.1.2.-
INTERFACES DE USUARIO
Esta seccin describe las caractersticas de la configuracin como son formatos de

pantalla, reportes, mens, pginas, opciones de mensajes de error largos o cortos y todos
estos requisitos deben ser verificados, los atributos del sistema se especificarn con el
ttulo Facilidad de Uso.
1.2.1.3.-
INTERFACES DE HARDWARE
Esta seccin especifica las caractersticas lgicas y los componentes de hardware del
sistema.
1.2.1.4.-
INTERFACES DE SOFTWARE
Esta seccin especifica el uso de otros productos de software e interfaces con otros sistemas.
Estos deben identificarse con: nombre, cdigo, nmero de la especificacin, nmero de versin y fuente.
1.2.1.5.INTERFACES DE COMUNICACIONES
Esta seccin especifica varias interfaces de comunicaciones como los protocolos de las
redes locales, etc.
- 268 -
GCS
1.2.1.6.-
Versin: 1.0
Fecha: 18/08/05
MEMORIA
Esta seccin especifica cualquier caracterstica aplicable y lmites en la memoria

primaria y secundaria.
1.2.1.7.-
FUNCIONAMIENTOS
Esta seccin especifica los funcionamientos normales y especiales requeridos por el

usuario.
1.2.1.8.-
REQUISITOS DE ADAPTACIN DE SITIO
Esta seccin especifica el sitio o los rasgos que se deben relacionar a caractersticas que
deben modificarse para adaptar el software a una instalacin particular.
1.2.2.-
FUNCIONES DEL PRODUCTO
Esta seccin proporciona una sntesis de las principales funciones que realiza el
software.
1.2.3.-
CARACTERSTICAS DEL USUARIO
Esta seccin describe las caractersticas generales de los usuarios del producto que
incluye nivel educativo, experiencia y especializacin tcnica.
1.2.4.-
RESTRICCIONES
- 269 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin describe en forma general cualquier otro punto que limite las opciones de
los diseadores. Estos incluyen: polticas reguladoras, limitaciones de hardware,
interfaces a otras aplicaciones, funciones de auditorias, funciones de control, requisitos
de lenguaje, requisitos de fiabilidad, credibilidad de la aplicacin y seguridad.
1.2.5.-
SUPOSICIONES Y DEPENDENCIAS
Esta seccin detalla cada uno de los factores que afectan a los requisitos
declarados en el ERS.
1.3.-
REQUISITOS ESPECFICOS
Esta seccin contiene todos los requisitos de software apropiadamente detallados para
permitirles a los creadores disear el sistema para satisfacer los requisitos, esta seccin
es la ms grande e importante del ERS.
1.3.1.-
Esta seccin define las funciones que tendr el software, aceptando y

procesando las entradas y generando las salidas.
1.3.2.-
REQUISITOS DE INTERFACES EXTERNAS
sta seccin detalla todas las entradas y salidas del sistema software. Debe
completar la descripcin de la interfaz y no debe repetirse la informacin.
1.3.3.-
REQUISITOS DE RENDIMIENTO
Esta seccin define los parmetros que asignan restricciones.
- 270 -
GCS
1.3.4.-
Versin: 1.0
Fecha: 18/08/05
REQUISITOS DEL DESARROLLO

Esta seccin define los requerimientos planteados por el equipo de trabajo que es: metodologa
que se seguir, ciclo de vida y herramienta que se utilizar.
1.3.5.-
REQUISITOS TECNOLOGICOS
Esta seccin describe las necesidades tecnolgicas de hardware, software, sistema

operativo, conexin de bases de datos y cualquier otro equipo que forme parte del
sistema.
1.3.6.-
1.3.6.1.-
ATRIBUTOS
SEGURIDAD
Esta seccin especifica los factores que protegen el software de accesos provisionales,
modificacin, destruccin. Los requisitos especficos pueden tener:
Utilizar tcnicas criptogrficas

Mantener registros especficos o una serie de historia de datos
Asignar ciertas funciones a mdulos diferentes
Restringir comunicaciones entre algunas reas del programa
Revisar la integridad de datos para variables criticas.
- 271 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1008 - 1987 (R 2003)
ESTNDAR IEEE PARA PRUEBAS UNITARIAS DE SOFTWARE

CONTENIDO
2.- Plan de Pruebas Unitarias
2.1.-
Fase de Perfeccionamiento del Plan de Pruebas
2.1.1.-
Aproximacin General del Plan, Recursos y Horarios
2.1.2.-
Caractersticas a ser Probadas
2.1.3.-
Desarrollo del Plan General
2.2.-
Fase de Adquisicin: Conjunto de Pruebas
2.2.1.-
Disear el Conjunto de Pruebas
2.2.2.-
Ejecutar el Desarrollo del Plan y Diseo
2.3.-
Fase de Medida: Pruebas Unitarias
2.3.1.-
Ejecutar los Procedimientos de Pruebas
2.3.2.-
Verificar la Terminacin
2.3.3.-
Evaluar el Esfuerzo de las Pruebas Unitarias
1.-
PLAN DE PRUEBAS UNITARIAS
1.1.-
FASE DE PERFECCIONAMIENTO DEL PLAN DE PRUEBAS
1.1.1.- APROXIMACIN GENERAL DEL PLAN, RECURSOS Y HORARIOS
El plan de pruebas unitarias debe empezarse a realizar cuando se inicie el

plan de pruebas de software, ya que este documento se adjunta al plan general.
- 272 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.1.1.1.- ENTRADAS DEL PLAN
Proyecto del plan

Documentacin de los requisitos del software
1.1.1.2.- TAREAS DEL PLAN
Especificar una aproximacin del plan de pruebas unitarias.

Especificar las Caractersticas a ser probadas que sern cubiertas por el
plan, cada tabla debe tener un caso de prueba unitaria.
Especificar los requerimientos que satisfaga la prueba para que termine
esta.
Determinar los recursos que se requiere para ejecutar las pruebas
unitarias
considerando:
hardware,
comunicaciones,
software,
herramientas.
Especificar un horario para las actividades de las pruebas unitarias.
1.1.1.3.- SALIDAS DEL PLAN
Informacin del plan de pruebas unitarias

Requisitos generales para las pruebas unitarias
1.1.2.- CARACTERSTICAS A SER PROBADAS
1.1.2.1.-
DETERMINAR ENTRADAS
Documentacin de requisitos de unidad

Documentacin de diseo de arquitectura del software
1.1.2.2.-
DETERMINAR TAREAS
- 273 -
GCS
Versin: 1.0
Fecha: 18/08/05
Describir los requisitos para asegurar que estos son nicos.

Identificar los requisitos y procedimientos adicionales que pueden ser
probados en este tipo de prueba.
Identificar datos de entrada y salida.
Describir los datos validos y no validos para realizar la prueba.
1.1.2.3.-
DETERMINAR SALIDAS
Lista de elementos a ser incluidos en la prueba.

Clasificar los requisitos.
1.1.3.- DESARROLLO DEL PLAN GENERAL
1.1.3.1.-
DESARROLLAR LAS ENTRADAS
Lista de elementos a incluirse en la prueba.

Informacin del plan de pruebas unitarias.
1.1.3.2.-
DESARROLLO DE TAREAS
Identificar los casos de prueba existente.

Identificar los recursos para ejecutar las pruebas unitarias.
Especificar el horario para las pruebas
1.1.3.3.-
DESARROLLO DE SALIDAS
Informacin especifica del plan de pruebas unitarias .

Especificacin de los recursos para las pruebas
1.2.- FASE DE ADQUISICIN: CONJUNTO DE PRUEBAS

- 274 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.2.1.-
DISEAR EL CONJUNTO DE PRUEBAS
1.2.1.1.-
DISEAR LAS ENTRADAS
Documentacin de requerimientos.
Lista de elementos a ser incluidos en las pruebas.
Documentacin del diseo
Especificacin de pruebas para pruebas previas.
1.2.1.2.-
DISEAR LAS TAREAS
Disear la arquitectura para las pruebas, basadas en las Caractersticas

a ser probadas.
Poner los casos de pruebas, puede estar de acuerdo a la informacin del
estndar IEEE 829 o especificadas en una seccin suplementaria.
1.2.1.3.-
DISEAR LAS SALIDAS
Especificacin del diseo de las pruebas unitarias.

Especificaciones de pruebas separadas.
Especificaciones de casos de pruebas separadas.
1.2.2.-
EJECUTAR EL DESARROLLO DEL PLAN Y DISEO
1.2.2.1.-
EJECUTAR ENTRADAS
- 275 -
GCS
Versin: 1.0
Fecha: 18/08/05
Documentacin de especificaciones de los casos y diseo de pruebas

unitarias
Descripcin de los datos
Recursos para las pruebas
Items de pruebas
Herramientas de pruebas
1.2.2.2.-
EJECUTAR TAREAS
Obtener y verificar los datos de pruebas, incluir datos adicionales

necesarios para asegurar la consistencia y la integridad.
Obtener los recursos.
Obtener los items de pruebas para asegurar la ejecucin y la satisfaccin
de la prueba.
1.2.2.3.-
EJECUTAR SALIDAS
Verificar los datos de las pruebas

Configuracin de los items de pruebas
Informacin de pruebas
1.3.- FASE DE MEDIDA: PRUEBAS UNITARIAS
1.3.1.-
EJECUTAR LOS PROCEDIMIENTOS DE PRUEBAS
1.3.1.1.-
EJECUTAR ENTRADAS
Verificar los datos de prueba.

Recursos de las pruebas
Configuracin de items de prueba
- 276 -
GCS
Versin: 1.0
Fecha: 18/08/05
Especificacin de los casos de pruebas
1.3.1.2.-
EJECUTAR TAREAS
Ejecutar las pruebas

Determinar los resultados
1.3.1.3.-
EJECUTAR SALIDAS
Registrar la informacin de la ejecucin de las pruebas en el se incluir el

ingreso de prueba, descripciones de la prueba, incidentes, resultados de
anlisis de fracaso de la prueba, etc.
Especificacin y datos de las pruebas revisadas.
1.3.2.-
VERIFICAR LA TERMINACIN
1.3.2.1.-
VERIFICAR LAS ENTRADAS
Terminacin de los requisitos.

Informacin de la ejecucin.
1.3.2.2.-
VERIFICAR LAS TAREAS
Informacin de la ejecucin.
Evaluar las pruebas de unidad
Si es necesario realizar las pruebas suplementarias o cuando las pruebas
no son satisfactorias, suplementar con las pruebas de serie como son:
Actualizar las pruebas arquitectnicas y aumentar los casos de
pruebas
Modificar las especificaciones de los procedimientos de pruebas
Obtener los datos de las pruebas
- 277 -
GCS
Versin: 1.0
Fecha: 18/08/05
Ejecutar las pruebas adicionales
1.3.2.3.-
VERIFICAR LAS SALIDAS
Revisar la informacin registrada de las pruebas y los casos adicionales

de pruebas
Verificar los datos de pruebas adicionales si se a producido
1.3.3.-
EVALAR EL ESFUERZO DE LAS PRUEBAS UNITARIAS
1.3.3.1.-
EVALUAR LAS ENTRADAS
Especificacin del diseo de pruebas unitarias

Informacin de ejecucin
Informacin de revisin
Especificacin de casos de pruebas
1.3.3.2.-
EVALUAR LAS TAREAS
Describir el estado de las pruebas, identificar incidentes de pruebas no

resueltas y las razones para la falta de resolucin
Evaluar el diseo e implementacin en contra de los requerimientos
pasados sobre los resultados de prueba
Completar el reporte del resumen de pruebas
1.3.3.3.-
EVALUAR LAS SALIDAS
Completar reporte de resumen de pruebas
- 278 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE STD 1063 - 2001
ESTNDAR IEEE PARA DOCUMENTACIN DE USUARIO DEL

SOFTWARE
CONTENIDO
4.-
Estructura del Documento del Usuario del Software
4.1.-
Estructura General del Documento
4.2.-
Componentes Iniciales
5.-
Contenido de Informacin del Documento del Usuario del Software
5.1.-
Contenido de Datos de Identificacin
5.2.-
Informacin para Uso del documento

- 279 -
GCS
Versin: 1.0
Fecha: 18/08/05
5.3.-
Concepto de Operacin
5.4.-
Informacin para Uso General del Software
5.5.-
Informacin para Procedimientos y Tutoriales
5.6.-
Informacin sobre Terminologa
5.7.-
Informacin sobre Fuentes de Informacin Relacionadas
6.-
Formato de Documentacin de Usuario del Software
6.1.-
Uso de Formato Impreso o Electrnico
6.2.-
Legibilidad
6.3.-
Formatos para Representar Elementos de Interfaces de Usuario
6.4.-
Formatos para Caractersticas del Documento para Acceder a la

Informacin
6.5.-
1.-
Formato para Caractersticas de Navegacin
ESTRUCTURA DEL DOCUMENTO DEL USUARIO DEL SOFTWARE
Esta seccin puede ser estructurada en un solo documento o una serie de

documentos impresos o electrnicos.
1.1.-
ESTRUCTURA GENERAL DEL DOCUMENTO
Esta seccin debe estructurar la documentacin en unidades con contenido nico,

como puede ser:
- 280 -
GCS
Versin: 1.0
Fecha: 18/08/05
Un documento impreso es estructurado dentro de las unidades lgicas llamadas

captulos, subdivididos dentro del tema, los cuales pueden ser divididos dentro de
subtemas e impresos en unidades fsicas llamadas paginas.
Un documento electrnico es estructurado dentro de las unidades lgicas

llamadas temas y presentados en unidades fsicas llamadas paginas o pantallas.
1.2.-
COMPONENTES INICIALES
Esta seccin debe empezar con datos de identificacin y la introduccin, el primer

captulo o tema del documento es la introduccin, describe el alcance y el propsito del
software.
2.- CONTENIDO DE INFORMACIN DEL DOCUMENTO DEL USUARIO DEL

SOFTWARE
2.1.-
CONTENIDO DE DATOS DE IDENTIFICACIN
Esta seccin debe contener la siguiente informacin:

Titulo del Documento
Versin y Fecha del Documento
Versin del Producto Software
Responsable del Documento
2.2.-
INFORMACIN PARA USO DEL DOCUMENTO
Esta seccin debe incluir informacin de cmo manejar el documento y recomendar

como consultar las secciones del documento, si un documento est contenido de varios
volmenes puede tener una gua separada del contenido. La documentacin puede incluir la
identificacin y la versin del documento y software.
- 281 -
GCS
2.3.-
Versin: 1.0
Fecha: 18/08/05
CONCEPTO DE OPERACIN
Esta seccin debe explicar los antecedentes para el uso del software, usando como
un antecedente el mtodo visual o verbal del proceso de trabajo o en forma general lo que
har el software y el documento, este antecedente debe ser explicado en trminos familiares
para el usuario.
2.4.-
INFORMACIN PARA USO GENERAL DEL SOFTWARE
Esta seccin debe incluir la siguiente informacin:
Instalacin y desinstalacin del software

Caractersticas de interconexin
Acceso al software.
Navegacin y salida del software mediante el acceso al sistema.
Operacin de datos (editar, guardar, leer, imprimir, actualizar y
borrar).
Mtodos de cancelacin, interrumpiendo y reinicio de operacin.
2.5.-
INFORMACIN PARA PROCEDIMIENTOS Y TUTORIALES
Esta seccin debe incluir la siguiente informacin:
Visin general del propsito del procedimiento y explicar los

conceptos necesarios no incluido en otras partes.
Identificar las actividades tcnicas y administrativas que deben ser
hechas antes de empezar como pueden ser software adicional,
identificacin de drivers, interconexiones o protocolos.
- 282 -
GCS
Versin: 1.0
Fecha: 18/08/05
Advertencias relevantes, prevenciones y notas que aplican al

procedimiento entero.
2.6.-
INFORMACIN SOBRE TERMINOLOGA
Esta seccin debe incluir un glosario de trminos ordenados alfabticamente, tanto

de abreviaciones y siglas no familiares al usuario, el glosario puede ser impreso o
electrnico.
2.7.-
INFORMACIN SOBRE FUENTES DE INFORMACIN RELACIONADAS
Esta seccin puede incluir lo siguiente:
Especificacin de requerimientos, especificacin de diseo, estndares

aplicados, para el software y la documentacin.
Planes de prueba y procedimientos para el software y la documentacin.
La documentacin del hardware y software.
La documentacin debe indicar si la referencia contiene material

informativo.
3.- FORMATO DE DOCUMENTACIN DEL USUARIO DEL SOFTWARE
Esta seccin incluye el formato del documento:
Presentacin del documento Impreso o electrnico

Tipo y tamao de fuente
Color de la fuente y tamao del papel
3.1.- USO DE FORMATOS IMPRESOS O ELECTRNICOS
- 283 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin debe presentar la siguiente informacin, tanto impresa como

electrnica:
Informacin de Hardware y de software

Informacin e instrucciones de instalacin
Instrucciones para utilizar el software.
Instrucciones para el acceso al software
Caractersticas del software diseadas para permitir la impresin de
documentos electrnicos.
3.2.- LEGIBILIDAD
Esta seccin describe como debe ser la documentacin impresa o

electrnica del usuario:
La documentacin debe ser legible

Usar papel de color o color de fondo de pantalla, la documentacin en
lnea debe permanecer legible si el usuario es capaz de agrandar,
acortar o reformar la pantalla o ventana.
3.3.- FORMATOS PARA REPRESENTAR ELEMENTOS DE INTERFACES DE

USUARIO
Esta seccin describe las interfaces grficas del usuario del software, como los botones,
iconos, usos especiales de claves de teclado o claves de combinaciones y las respuestas
deben ser presentados en documentacin por grfico consistente o formatos tipogrficos
- 284 -
GCS
Versin: 1.0
Fecha: 18/08/05
para que cada uno de los elementos sean distinguidos del texto. La documentacin debe
incluir una representacin de elemento. Su propsito y una explicacin de su accin
(consecuencia funcional) con ejemplos de operaciones actuales.
3.4.- FORMATOS PARA CARACTERISTICAS DEL DOCUMENTO PARA

ACCEDER A LA INFORMACIN
3.4.1.-
CUADRO DE CONTENIDOS
Un cuadro de contenidos debe tener encabezados de los captulos o ttulos de tpicos

bajados al tercer nivel. La tabla de contenidos incluye solo el primer nivel de
encabezados, la documentacin electrnica puede exhibir cuadros de contenidos en
formato expandibles para proveer el nivel principal y acceso detallado a encabezados. El
cuadro de contenidos debe incluir tambin apndices, glosario, e ndice.
3.4.2.- LISTA DE ILUSTRACIONES
Esta seccin contiene las tablas, lista de figuras o una lista de ilustraciones,
si el documento contenido ms de 5 ilustraciones numeradas y no es visible poner
una referencia de texto. Las ilustraciones deben tener el nmero y ttulo como un
punto de acceso a cada uno.
3.4.3.- INDICE
- 285 -
GCS
Versin: 1.0
Fecha: 18/08/05
Esta seccin describe como organizar el ndice, este debe
ser
alfabticamente, los grficos o conceptos con un punto de acceso para cada uno
de los documentos impresos, cuando tenga ms de 40 pginas deben incluir un
ndice. Los puntos de acceso puede ser nmero de pginas, nmero de tpicos,
nmero de ilustraciones, o referencias a otro ndice de entrada.
Los documentos electrnicos con ms de 40 tpicos deben incluir una

herramienta de bsqueda un ndice de los puntos de acceso estos son los
enlaces electrnicos.
3.5.- FORMATOS PARA CARACTERISTICAS DE NAVEGACIN
Esta seccin incluye el encabezado del captulos y tpico, pagina o ttulo de pantalla y
nmero de pantalla, encabezados de pgina, los iconos de navegacin deben ser
provedos para que los usuarios puedan determinar su localizacin dentro del impreso o
documento electrnico. La documentacin puede incluir explicaciones del sistema y
caracterstica especficas.
Las caractersticas de navegacin deben tener:
Tabla de contenidos
Indice
Las caractersticas de navegacin deben usar formatos consistentes como:
Enlaces calificados, color o grfico para distinguirlos el texto simple
- 286 -
GCS
Versin: 1.0
Fecha: 18/08/05
Los enlaces entre tpicos relacionados deben ser bidireccionales, para

cualquier tpico para que los usuarios tengan acceso.
La referencia electrnica debe ser accesible desde el software que
documenta y debe tener salir de la documentacin y retorna al software.
El software puede ser enlazado a la ayuda en lnea, tutoriales o
documentos de referencia de varias maneras, tales como las siguientes:
A travs de un punto de entrada para ayudar al sistema.

A travs de botones de ayuda en las pantallas del software que proveen
informacin en un tpico en particular (caja de dialogo y ayudar del nivel
de campo).
A travs de ayuda de contexto sensitivo y texto (claves de herramientas)
- 287 -
GCS
Versin: 1.0
Fecha: 18/08/05
IEEE Std 1320.2 1998
ESTNDAR
LENGUAJE
IEEE
(DEFINICIN
PARA
SINTAXIS
EL
Y
INTEGRADA
MODELO
CONCEPTUAL
SEMNTICA
PARA
PARA
MODELO
EL
IDEF1X
DE
INFORMACIN)
ANTECEDENTES
Este estndar describe la semntica y sintaxis de IDEF1X, un lenguaje utilizado
para representar un esquema conceptual.
El modelo IDEF1X es utilizado para representar la estructura de la informacin de

los modelos y semntica de los datos, es de compatibilidad descendiente con el estndar de
procesos de informacin del gobierno US federal (FIPS) PUB 184, definicin de
Integracin para modelo de informacin (IDEF1X) el estilo de identidad se utiliza para
producir modelos de objeto que representan el conocimiento, comportamiento y reglas de
conceptos.
MBITO
Este estndar define la semntica y sintaxis de IDEF1X, define las construcciones

validas del lenguaje y especifica como puede ser combinadas para formar un modelo
valido.
- 288 -
GCS
Versin: 1.0
Fecha: 18/08/05
PROPSITO
El objetivo de este estndar es describir el lenguaje IDEF1X de una manera no

ambigua.
LENGUAJE DE CONSTRUCCIN IDEF1X
El construccin del lenguaje IDEF1X se incluye lo siguiente:
Clase.- Una clase es una abstraccin del conocimiento y funcionamiento de una

serie de cosas similares cualquier cosa que sea clasificada en una instancia de
una clase dada, en el cul poseen el mismo tipo de conocimiento,
funcionamiento y reglas. Una instancia es una discreta cosa con direccin
intrinsica, identidad nica, estado o valor de la clase.
Generalizacin.- las clases son utilizadas para representar la nocin de cosas

cuyo conocimiento o acciones son relativas del mundo real, algunas clases debe
tener algn sentido para otras clases. Una instancia es una subclase representada
o tambin una instancia es una superclase es la que determina la herencia de
responsabilidades entre clases.
IDEF1X
IDEF
(INTEGRATION
DEFINITION
FOR
INFORMATION
MODELING)
(DEFINICIN INTEGRADA DE MODELADO DE INFORMACIN)
- 289 -
GCS
Versin: 1.0
Fecha: 18/08/05
Qu es el IDEF?
La Familia de mtodos IDEF fue desarrollada por la industria y el
gobierno
Estadounidense. Su propsito es proporcionar una estructura extensa flexible para describir,

analizar, y evaluar las prcticas comerciales. Los que desarrollaron este mtodo no son
propietarios y este mtodo es apoyado por los estndares internacionales.
Donde se Utiliza el IDEF
Transmisin del papel a los sistemas electrnicos

Reingenieria de procesos comerciales / Perfeccionamiento
Negocio / Documentacin de Sistemas Industriales / ISO 9000
Software / Desarrollo de Sistemas de Informacin
Anlisis de los Sistemas Industriales y Diseo
IDEF1X?
Es un modelador de Datos, disea bases de datos

relacionales y sistemas.
Que es un Modelo de Datos IDEF1X?
Es utilizado para producir un modelo grfico de los datos que represente la
estructura y la semntica de la informacin dentro del sistema. Debido a la
versatilidad para realizar representaciones de estructura de datos tanto
lgicamente como fsicamente de una manera estndar, sencilla y fiable.
- 290 -
GCS
Versin: 1.0
Fecha: 18/08/05
IDEF1X, a diferencia de otros lenguajes de modelado, todas las relaciones deben ser
binarias, es decir, deben conectar exactamente dos entidades. Esto no significa que las
relaciones binarias no sean necesarias, sino que ellas en IDEF1X van a ser manejadas
por medio de las entidades asociativas.
Una meta de IDEF1X es eliminar todas las relaciones muchos a muchos,
convirtindola en un par de relaciones uno a muchos. Para ello, se vale del uso de
una entidad asociativa entre medio de las otras dos entidades
La notacin de IDEF1X exhibe entidades como rectngulos con las esquinas ajustadas o
redondeadas. Si las esquinas de la entidad se redondean, la entidad es dependiente
IDEF1X como un Estndar

Federal Information Processing Standards Publication (FIPS PUB)
184-Integrated Definition for Data Modeling (IDEF1X)
Federal de informacin de Procesos Estndares Publicados (FIPS PUB)
184- Definicin Integrada para Modelar Datos.
Publicado en Diciembre de 1994

DoD (Departamento de defensa de los Estados Unidos) 8020.1-M Establece que IDEF1X es un Mtodo Estndar DoD usado para
Modelo de Datos.
CASE STUDIO 2 VERSIN 2.19

Case Studio 2 es una herramienta profesional que disea la base de datos
automticamente, permite que usted cree visualmente los diagramas de entidad
relacin (ERD) para varias bases de datos.
- 291 -
GCS
Versin: 1.0
Fecha: 18/08/05
Cuando crea ERD el programa considera las opciones individuales de la

base de datos como la integridad de referencia, las restricciones, los dominios,
etc. Usted tendr una perspectiva de todos los elementos de la base de datos,
puede poner los valores de todos los atributos, tipos de relaciones y otros criterios.
SOPORTA LAS SIGUIENTES BASES DE

DATOS
Advantage DS 7
MS SQL 7
Clipper
MS SQL 6.5
DB2 v. 8
MySQL 4.1
MySQL 3.23
DB2 v. 7
Oracle 10g
DBISAM 3
Oracle 9
Firebird 1.5
Oracle 8
Informix 9
Oracle 7
Informix
Paradox
Ingres
Pervasive V8
InterBase 7
PostgreSQL 8
InterBase 6 SQL 1
PostgreSQL 7.4
InterBase 6 SQL 3
PostgreSQL 7.3
InterBase 5
PostgreSQL 7
InterBase 4
Sybase Anywhere 9
MaxDB (SAP)
Sybase ASE 12.5.1
MS Access 2000
Sybase ASE 12.5
MS Access 97
MS SQL 2000
El software Case Studio 2 podr ser descargado y probado durante cierto

perodo de tiempo. Si se lo va aplicar tendr que comprar la versin completa del
editor. La versin de ensayo libre contiene el instalador y desinstalador, y tiene un
tamao de 5188 kilobytes, funcionar en Windows 95/98/2000/NT/XP.
Necesita los siguientes requisitos:
- 292 -
GCS
Versin: 1.0
Fecha: 18/08/05
Windows 95/98/Me/NT/2000/XP
Pentium
64 Mb
16 Mb en Disco duro
COOPERATIVA SAN ANTONIO DEPARTAMENTO COMISARIATO
ESTNDAR IEEE 830-1998

ESPECIFICACIONES DE REQUISITOS SOFTWARE (ERS)
1. INTRODUCCIN
La Especificacin de Requisito Software (ERS) es un documento base para

el desarrollo del sistema de inventario, est documentacin se realiza con la
colaboracin de todo el personal del departamento del comisariato. Este
documento se desarrolla siguiendo el estndar IEEE 830-1998 Estndar IEEE
Practica Recomendada para la Especificacin de Requisito Software .
1.1
PROPSITO.
El objetivo de este documento es recopilar los requisitos funcionales, no funcionales y

las restricciones que tendr el sistema a ser desarrollado en el departamento del
comisariato de la cooperativa.
- 293 -
GCS
Versin: 1.0
Fecha: 18/08/05
Actualmente el comisariato realiza el manejo del inventario manualmente, por est razn
no se puede tener informacin el momento que lo requiera la administracin, ya que
todo se tiene que constatar fsicamente en el Kardex, lo que resulta una perdida de
tiempo, en algunos casos se puede mezclar la informacin ocasionando muchas veces
perdida de tiempo y dinero. Por otro lado no poder saber con exactitud el stock existente
en la bodega causando algunas veces aglomeracin de artculos, por no estar al tanto de
lo que se ha vendido y adquirido.
1.2
ALCANCE
El sistema se denominar SICOIN (Sistema de Inventario del comisariato), este sistema

manejar la informacin de socios, artculos, proveedores, facturas de compra y venta de
artculos, el mismo que controlar los datos de stock de compras y ventas de artculos en
la bodega, ser aplicado en el departamento del comisariato de la cooperativa San
Antonio.
1.3
DEFINICIONES, SIGLAS Y ABREVIATURAS
1.3.1. DEFINICIONES
- 294 -
GCS
Versin: 1.0
Fecha: 18/08/05
Palabra
Definicin
Administra
Persona encargada de la gestin del comisariato
dor
(proveedor, socio, Articulo, bodega, facturacin de

compra).
Usuario
Persona encargada de administrar la facturacin de venta
Socio
Persona que solicita la operacin de facturacin de venta
Gerente
Persona encargada de administracin del comisariato.
1.3.2. SIGLAS
Siglas
ERS
Definicin
Especificacin de Requisitos Software
1.3.3. ABREVIATURAS
Abreviatur
Definicin
- 295 -
GCS
Versin: 1.0
Fecha: 18/08/05
a
SICOIN
1.4.
Sistema de Inventario del Comisariato
REFERENCIA
Estndar IEEE 830-1998 (IEEE Recommended Practice for Software

Requirements Specification)
2.
DESCRIPCIN GENERAL
En est seccin se detalla de forma general el sistema, con el objetivo de conocer las principales funciones que realizara, tanto con los
datos, restricciones, y cualquier factor que afecte el desarrollo del mismo.
2.1 PERSPECTIVA DEL PRODUCTO
Debido a que no existe un sistema de informacin no se realiza est actividad, por lo que
no se afecta a ningn proceso dentro del departamento del comisariato.
2.2 FUNCIONES DEL PRODUCTO
En forma general el sistema deber dar soportar las siguientes gestiones:
Gestin de Proveedores
Gestin de Artculo
Gestin de Socios
Gestin de Factura Venta
Gestin de Factura Compra
Gestin de Proveedor
- 296 -
GCS
Versin: 1.0
Fecha: 18/08/05
Permitir realizar las funciones de ingresar, eliminar, modificar y consultar en

forma Individual o general.
Para ingresar un Proveedor, se deber ingresar, el cdigo del proveedor, en

el caso de no existir el cdigo ingresado, el sistema permitir el ingreso de los
campos de nombre, apellido, direccin, telfono, descripcin, distribuidora.
Para la eliminacin, se seleccionar un Proveedor de la lista de Proveedores, luego de

comprobar que no exista factura compra de proveedores y de verificar que los datos
presentados corresponden al proveedor a eliminar, se proceder a aceptar la
operacin.
Para modificar los datos de un Proveedor, se seleccionar de la lista de

proveedores, y tras verificar que los datos desplegados corresponden al
proveedor a modificar. Slo podrn ser modificados aquellos campos que el
sistema lo permita.
Para las consultas Individuales del Proveedor, se seleccionar de la lista de

proveedores, y desplegar la informacin del proveedor en cuestin.
La consulta general permitir conocer todos los proveedores que brindan

productos al comisariato.
Gestin de Artculos

- 297 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para ingresar un Artculo, se deber ingresar, el cdigo del Articulo, en el

caso de no existir el cdigo ingresado, el sistema permitir el ingreso de los
campos de nombre, stock, valor de venta, IVA, valor mnimo de artculos.
Para la eliminacin, se seleccionar un artculo de la lista de artculos, luego de

comprobar que no exista factura compra de artculos y de verificar que los datos
presentados corresponden al artculo a eliminar, se proceder a aceptar la operacin.
Para modificar los datos de un artculo, se seleccionar de la lista de

artculos, y tras verificar que los datos desplegados corresponden al articulo a
modificar. Slo podrn ser modificados aquellos campos que el sistema lo
permita.
Para las consultas Individuales del Articulo, se seleccionar de la lista de

artculos, y desplegar la informacin del artculo en cuestin.
La consulta general permitir conocer todos los artculos que brinda el

comisariato.
Gestin de Socios

Para ingresar un Socio, se deber ingresar, el cdigo del Socio, en el caso de

no existir el cdigo ingresado, el sistema permitir el ingreso de los campos
de cedula, nombre, apellido, direccin.
- 298 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para la eliminacin, se seleccionar un socio de la lista de socios, luego de

comprobar que no exista factura venta de socios y de verificar que los datos
presentados corresponden al socio a eliminar, se proceder a aceptar la operacin.
Para modificar los datos de un socio, se seleccionar de la lista de socios, y

tras verificar que los datos desplegados corresponden al socio a modificar.
Slo podrn ser modificados aquellos campos que el sistema lo permita.
Para las consultas Individuales del Socio, se seleccionar de la lista de

socios, y desplegar la informacin del socio en cuestin.
La consulta general permitir conocer a todos los socios que realizan la

compra en el comisariato.
Gestin de factura Venta

Para ingresar una Factura Venta, se deber ingresar los campos de fecha de
vencimiento, detalle, fecha de emisin, suma total, IVA, Valor total, estado,
cantidad.
Para la eliminacin, se seleccionar una factura venta de la lista, luego de comprobar

que no exista artculos y socios en la factura venta a eliminar, se proceder a aceptar
la operacin.
- 299 -
GCS
Versin: 1.0
Fecha: 18/08/05
Para modificar los datos de una factura venta, se seleccionar de la lista de

factura venta, y tras verificar que los datos desplegados corresponden a la
factura venta a modificar. Slo podrn ser modificados aquellos campos que
el sistema lo permita.
Para las consultas Individuales de la Factura venta, se seleccionar de la lista

de la factura venta, y
desplegar la informacin de la factura venta en
cuestin.
La consulta general permitir conocer todas las facturas ventas de cada socio
que lo realiza en el comisariato.
Gestin de factura Compra

Para ingresar una Factura Compra, se deber ingresar los campos de fecha
de emisin, fecha de vencimiento, detalle, suma total, IVA, Valor total, estado,
cantidad.
Para la eliminacin, se seleccionar una factura compra de la lista de la factura

compra, luego de comprobar que no exista artculos y proveedores en la factura
compra a eliminar, se proceder a aceptar la operacin.
Para modificar los datos de una factura compra, se seleccionar de la lista de

factura compra, y tras verificar que los datos desplegados corresponden a la
- 300 -
GCS
Versin: 1.0
Fecha: 18/08/05
factura compra a modificar. Slo podrn ser modificados aquellos campos

que el sistema lo permita.
Para las consultas Individuales de la Factura compra, se seleccionar de la

lista de la factura compra, y desplegar la informacin de la factura compra
en cuestin.
La consulta general permitir conocer todas las facturas compras que realiza
el comisariato.
2.3 CARACTERSTICAS DEL USUARIO
El sistema de informacin deber tener interfaces fciles de aprender y sencillas de

manejar, debido a las caractersticas de los usuarios.
2.4 RESTRICCIONES
Las restricciones que se deber tener en cuenta a la hora de desarrollar el

sistema, tanto en hardware y software son las siguientes:
Hardware
Impresora
Metodologa de Desarrollo
Mtrica V3 Orientada a Objetos.
- 301 -
GCS
Versin: 1.0
Fecha: 18/08/05
Sistema Base
Sistema Operativo WINDOWS (95,98,XP,Profesional)
Software de Aplicacin
PHP
Servidor WEB
APACHE
Cliente WEB
Microsoft Internet Explorer
Base de Datos
MYSQL
Interfaces
Dreamweaver MX 2004
2.5 SUPOSICIONES Y DEPENDENCIAS
Los requisitos que se han definido son invariables, ya que sean revisado y
aprobado por el personal que labora en el comisariato.
El sistema que ser desarrollado no tendr dependencia con otros

sistemas, seguir una arquitectura cliente/servidor.
3.
REQUISITOS ESPECFICOS
- 302 -
GCS
Versin: 1.0
Fecha: 18/08/05
En est seccin se describir los requisitos funcionales, los cuales sern

satisfechos por el sistema.
3.1.
3.2.1.
GESTIN PROVEEDOR
3.2.2.
GESTIN ARTCULOS
3.2.3.
GESTIN SOCIOS
- 303 -
GCS
3.2.4.
Versin: 1.0
Fecha: 18/08/05
GESTIN FACTURA VENTA

3.2.5.
GESTIN FACTURA COMPRA

Req(25)Consultar las Facturas Compras en forma individual.
3.2.
REQUISITOS DE INTERFACES EXTERNAS
3.2.1.INTERFACES DE USUARIO
Las interfaces de usuario se desarrollaran en un ambiente de ventanas y el trabajo se lo realizara con el teclado o mouse(ratn).
3.2.2.INTERFACES DE HARDWARE
Se trabajara en plataforma cliente/servidor.
3.2.3.INTERFACES DE SOFTWARE
No va a interactuar con otros sistemas
- 304 -
GCS
3.3.
Versin: 1.0
Fecha: 18/08/05
REQUISITOS DE RENDIMIENTO
No se ha definido
3.4.
REQUISITOS DE DESARROLLO
El ciclo de vida para desarrollar el producto ser el Secuencial bsico.
3.5.
REQUISITOS TECNOLGICOS

Servidor WEB APACHE
Base de Datos MYSQL
3.6.
ATRIBUTOS
3.6.1.SEGURIDAD
Cuando un usuario del sistema intente conectarse, deber ingresar su clave

y password asignada, la cual ser entregada por el administrador del sistema, este
dar permisos de acuerdo a su perfil, si los datos ingresados no son los correctos
- 305 -
GCS
Versin: 1.0
Fecha: 18/08/05
se le indicar un mensaje de error, y a los tres intentos consecutivos se cerrar el

programa.
Los tipos de usuarios que se van a contemplar, y las labores que corresponden a cada uno de ellos son:
Administrador del Sistema
Se encargar de definir los perfiles de los diferentes usuarios, que podrn acceder al
sistema.
Gerente
Pueden consultar los datos de Proveedores, Artculos, Socios, Factura de Venta, Factura de
Compra.
Cajera(o)
Pueden Ingresar, modificar, y consultar, la informacin de las Factura de Venta.
- 306 -
GCS
Versin: 1.0
Fecha: 18/08/05
COOPERATIVA SAN ANTONIO DEPARTAMENTO

COMISARIATO
DOCUMENTACIN DE PRUEBAS DE SOFTWARE
1.- INTRODUCCIN
1.1
.- PROPSITO
El propsito del Plan de Pruebas es recoger toda la informacin necesaria

para planear y controlar el esfuerzo de las pruebas dadas.
Este Plan de Pruebas para el Sistema de Control de Inventario tiene

los siguientes objetivos:
Identificar las pruebas que se realizarn en el sistema.

Identificar problemas en el funcionamiento del sistema.
Establecer recursos requeridos para la realizacin de cada una delas
pruebas.
1.2.- ALCANCE
El Plan de Pruebas describe los niveles de comprobacin del sistema; es

decir, las pruebas integracin y los tipos de comprobacin como la funcionalidad,
fiabilidad las mismas que sern dirigidas por este plan de prueba.
- 307 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.3.- PERSONAS AL QUE SE DIRIGE EL PLAN
Este Plan de Pruebas esta dirigido exclusivamente para la o las personas

encargadas de la verificacin funcional del sistema.
1.4.- PREPARACIN DEL PLAN DE PRUEBAS
La siguiente tabla que se presenta a continuacin, permitir determinar para

cada requisito la caracterstica a ser probada y los tipos de prueba que se
emplearn.
REQUISITOS
CARACTERSTICAS A SER
TIPOS DE PRUEBAS
PROBADAS
Gestin
Crear Proveedor y almacenar
Proveedor
datos.
Valores tpicos de
Crear proveedor con cdigo
error
existente.
Valores imposibles
Crear proveedor con campos

obligatorios vacos.
Crear proveedor con valores
que no admiten los campos.
Eliminar proveedor.
Eliminar proveedor con
informacin relacionada
Modificar los datos de un
proveedor y actualizar datos
- 308 -
Pruebas de caja negra.
GCS
Versin: 1.0
Fecha: 18/08/05
Modificar el cdigo del proveedor

con cdigo existente
Modificar los datos de un
proveedor con valores que no
admiten los campos.
Consulta datos de un proveedor y
desplegar informacin
Consultar datos de un proveedor
con nombre de proveedor no
existente.
Consultamos datos de un
proveedor con nombre de
parmetro vaco.
Gestin
Crear Artculo y almacenar datos. Pruebas de caja negra.
Artculo
Crear Artculo con cdigo
Valores tpicos de
existente.
error
Crear Artculo con campos
Valores imposibles
obligatorios vacos.
Crear Artculo con valores que no
admiten los campos.
Eliminar Artculo
Eliminar Artculo con informacin
relacionada
Modificar los datos de una Artculo
y actualizar datos
Modificar el cdigo del artculo con
cdigo existente.
Modificar los datos de una Artculo
- 309 -
GCS
Versin: 1.0
Fecha: 18/08/05
con valores que no admiten los

campos.
Consultar datos de un Artculo y
desplegar informacin
Consultar datos de un Artculo con
nombre de Artculo rea no
existente.
Consultar datos de un Artculo con
nombre de rea vaco
Gestin Socio
Crear Socio y almacenar datos.
Crear Socio con cdigo
Valores tpicos de
existente.
error
Crear Socio con cdula existente.
Valores imposibles
Crear Socio con campos

obligatorios vacos.
Crear Socio con valores que no
admiten los campos.
Eliminar un Socio.
Eliminar Socio con informacin
relacionada.
Modificar los datos de un Socio y
actualizarlos.
Modificar la cdigo del Socio con
cdigo existente.
Modificar los datos de un Socio
con campos obligatorios vacos.
Modificar los datos de un Socio
con valores que no admiten los
campos.
- 310 -
GCS
Versin: 1.0
Fecha: 18/08/05
Consulta datos de un Socio y

desplegar informacin.
Consultar datos de un Socio con
cdigo no existente.
Consultar datos de un Socio con
campo cdigo vaco.
Gestin
Crear Factura Compra y almacenar Pruebas de caja negra.
Factura
datos.
Valores tpicos de
Compra
Crear Factura Compra con el
error
serial de la factura existente.
Valores imposibles
Crear Factura Compra con

campos obligatorios vacos.
Crear Factura Compra con
valores que no admiten los
campos.
Eliminar Factura Compra
Eliminar Factura Compra con
Modificar los datos de una Factura
Compra y actualizar datos
Compra con campos obligatorios
vacos.
Compra con valores que no
admiten los campos.
Consulta datos de una Factura
Compra y desplegar informacin
- 311 -
GCS
Versin: 1.0
Fecha: 18/08/05
Consulta datos de una Factura

Compra con el cdigo de
proveedor de Proveedor.
Gestin
Crear Factura Venta y almacenar
Factura Venta
datos.
Valores tpicos de
Crear Factura Venta con el serial
error
de factura existente.
Valores imposibles
Crear Factura Venta con campos

obligatorios vacos.
Crear Factura Venta con valores
que no admiten los campos.
Eliminar Factura Venta con
Modificar los datos de un Factura
Venta y actualizar datos
Venta con campos obligatorios
vacos.
Venta con valores que no admiten
los campos.
Consultar datos de un Factura
Venta y desplegar informacin
Venta con serial de Factura
Venta no existente.
- 312 -
GCS
Versin: 1.0
Fecha: 18/08/05
Venta con el serial de Factura

Venta vaco.
1.5.- REFERENCIAS
Especificacin de Casos de Prueba
2 .- PRUEBAS PLANEADAS
Se ha diseados un conjunto de pruebas para comprobar el cumplimiento

de las especificaciones de requisitos. Se van a desarrollar las siguientes pruebas:
2.1.- PRUEBA DE INTEGRACIN DE COMPONENTES
El objetivo de esta prueba es comprobar el correcto funcionamiento de la

relacin que existe entre las interfaces de cada uno de los componentes.
2.1.1.- COMPROBACIN DEL CICLO DEL NEGOCIO
La comprobacin del Ciclo del Negocio deben emular las actividades

realizadas en el Sistema de Control de Inventarios, en el tiempo actual. Debe por
ejemplo, identificarse un Socio, un producto y deben ejecutarse la factura venta y
actualizar el stock de los productos.
Objetivo de la Tcnica:
El objetivo es probar y respaldar que

los procesos se realizan segn el
modelo del negocio
- 313 -
GCS
Versin: 1.0
Fecha: 18/08/05
Tcnica:
Se simularn varios ciclos del negocio.
Criterios de xito:
La tcnica apoya la comprobacin de

todos los ciclos del negocio.
2.2.- PRUEBA DE INTEGRACIN DE COMPONENTES
Las pruebas de seguridades y control de acceso enfocan dos reas importantes de

seguridad:
Seguridad a nivel de
aplicacin, incluso acceso a los Datos o
Funciones de Negocio
Seguridad a nivel del sistema, incluyendo accesos remotos al sistema.
Basados en la seguridad deseada, los niveles de seguridad en la

aplicacin-nivelada asegura la restriccin de actores a funciones especficas o
casos de uso, y la limitacin a los datos disponibles a ellos.
La seguridad a nivel del sistema se asegura cuando los usuarios que acceden al
sistema son capaces de acceder a las aplicaciones slo a travs de las entradas apropiadas.
Objetivo
Tcnica:
de
la Bajo las siguientes condiciones se pueden observar:

La Seguridad a nivel de aplicacin: un actor puede
acceder slo a las funciones o datos a los que su tipo de
usuario tiene permiso.
La Seguridad a nivel de sistema: slo los actores con
acceso al sistema pueden acceder a la aplicacin.
- 314 -
GCS
Tcnica:
Versin: 1.0
Fecha: 18/08/05
La Seguridad a nivel de Aplicacin: Identificar y listar cada

tipo de usuario y las funciones o datos al que cada tipo tiene
permiso. Para:
Crear las pruebas para cada tipo del usuario.
Criterios de xito:
La tcnica apoya la comprobacin para cada tipo del actor y

pueden probarse las funciones apropiadas o datos afectados
por escenas de seguridad.
Consideraciones
El Acceso al sistema debe ser revisado y discutido por el
Especiales:
administrador de la red del sistema.
3 .- ESPECIFICACIN DE LA PLANTILLA PARA LOS CASOS DE

PRUEBA
3.1.-
DESCRIPCIN
Resumen lo que realiza el caso de prueba.
3.2.-
CONDICIONES DE EJECUCIN
Especifica los usuarios que pueden realizar el caso de prueba.
3.3.-
CRITERIOS DE ENTRADA
Especifica el criterio que se usar para determinar si la ejecucin de

la Prueba puede empezar.
- 315 -
GCS
3.4.-
Versin: 1.0
Fecha: 18/08/05
CRITERIOS DE SALIDA
Especifica el criterio que se usar para determinar si la ejecucin de
la Prueba est completa o su ejecucin no proporciona beneficio.
3.5.-
RESULTADO ESPERADO
Proporciona un contorno breve de la forma y contenido de los resmenes

de evaluacin de la prueba.
3.6.-
EVALUACIN DE LA PRUEBA
Proporciona un contorno breve de la forma y contenido de los

informes que miden la magnitud de la prueba.
4.- RECURSOS REQUERIDOS PARA EL SISTEMA

4.1.-
HARDWARE BASE DEL SISTEMA
La siguiente tabla muestra los recursos del sistema para realizar el Plan de
Pruebas.
RECURSOS DEL SISTEMA
RECURSOS
TIPO
Base de Datos
Nombre de base de Datos
SICOIN
- 316 -
GCS
Versin: 1.0
Fecha: 18/08/05
Hardware
Computadora Pentium o Superior
Velocidad de Procesamiento de 466 Mhz
Disco Duro 9.52 GB
Memoria RAM 24. MB
Monitor VGA o Superior
Drive 3
Mouse compatible con Microsoft
Tarjeta de Sonido
4.2.-
SOFTWARE BASE DEL SISTEMA
La siguiente tabla muestra los recursos del sistema para realizar el Plan de
Pruebas.
ELEMENTOS DE SOFTWARE
NOMBRE
TIPO
Windows
Sistema Operativo
Software
Visual Basic 6.0

Microsoft Access 97
ODBC de 32 bits
5.- RESULTADO DE EVALUACIN DE PRUEBAS
.........................................................................................................................
- 317 -
GCS
Versin: 1.0
Fecha: 18/08/05
.........................................................................................................................
........................................................................................................................
.......................................................................................................................
COOPERATIVA SAN ANTONIO DEPARTAMENTO COMISARIATO
PLAN DE ASEGURAMIENTO DE CALIDAD (SQAP)
1. PROPSITO
El propsito del Plan de Aseguramiento de Calidad es establecer una serie de estndares,

procedimientos y mtodos que permitan obtener software de calidad, garantizando de
est forma que el sistema desarrollado SICOIN, cumplir con los requisitos que
aseguren la calidad.
- 318 -
GCS
Versin: 1.0
Fecha: 18/08/05
2. ACRNIMOS, ABREVIATURAS Y REFERENCIAS
ACRNIMOS
PAC
Plan de Aseguramiento de Calidad
CCC
Comit de Control de Cambios
ABREVIATURA
SICOIN
Sistema de Control de Inventario
REFERENCIAS
Estndar IEEE 730 2002 (Estndar IEEE para Planes de Aseguramiento de Calidad)
3. GESTIN
ORGANIZACIN
El
Aseguramiento
de
Calidad
tiene
relacin
con
la
Gestin
de
Configuracin de Software ya que con este documento se realizan las revisiones y

auditoria en las lneas base fijadas, con el objetivo de garantizar la calidad del
producto.
- 319 -
GCS
Versin: 1.0
Fecha: 18/08/05
TAREAS
En esta actividad se describe las siguientes tareas de calidad a realizar:
TAREAS DEL SQAP
ACTIVIDADES
ENTREGA ASOCIADA
Realizar el Plan de SQAP
Plan de SQAP
Identificar las propiedades de
Propiedades de Calidad
Calidad
Evaluar la calidad de los productos
Informe de revisin de SQAP
Revisar el ajuste al proceso
Informe de revisin de SQAP
Realizar Revisin Tcnica Formal
Informe de Revisin Tcnica Formal
Evaluar y ajustar el Plan de SQAP
Documento de Evaluacin y Ajustes

al Plan de SQAP
Revisar la entrega semanal
Entrega semanal de SQAP
Realizar evaluacin final de SQAP
Evaluacin final de SQAP
Reuniones de Apoyo a la calidad
No Aplica
RESPONSABLES
El Aseguramiento de Calidad y Gestin de Configuracin de Software, esta
integrado por dos personas que son Gladys Aguagallo, Paulina Caizares
quienes son responsables durante el transcurso del proyecto:
- 320 -
GCS
Versin: 1.0
Fecha: 18/08/05
Documento de Requisitos
Modelo de Casos de Uso
Alcance del Sistema
1. DOCUMENTACIN
1.1 PROPOSITO
El propsito de esta seccin es especificar los documentos que dirigen el

desarrollo del proyecto y que debern ser revisados como parte de las actividades
de aseguramiento de la calidad.
Para Asegurar que la Implementacin del software satisfaga los requisitos,

se deber generar la siguiente documentacin
1.2
REQUISITOS MNIMOS DE DOCUMENTACIN
Especificacin de Requisitos de Software
Para aprobar estos elementos se toma cada lnea base que tiene el plan de
gestin de configuracin de software.
2. ESTNDARES Y MTRICAS
2.1 PROPOSITO
El propsito es identifica los estndares, prcticas y mtricas a ser

aplicadas, acorde a estos trminos sern asegurados
- 321 -
GCS
Versin: 1.0
Fecha: 18/08/05
LISTA DE ESTANDARES
ACTIVIDAD
ESTNDAR
DESCRIPCION
Practica Recomendada para la
Requisitos (ERS)
IEEE Std 830 - 1998
Especificacin
de
Requisitos
Software (ERS)
3. REVISIONES
3.1 PROPOSITO
El propsito de las revisiones del software es saber en que fase esta

fallando, el nombre del producto, quien es el responsable y cuanto tiempo va a
durar en el arreglo, durante todo el proyecto.
REVISIN DEL SQAP

FECHA
16/05/05
FASE
REVISION
AUTOR
Anlisis
del La revisin del catalogo de Gladys Aguagallo
Sistema
de
requisitos se lo realiza con la Paulina Caizares
Informacin
(ASI):
especificacin de requisitos de
Catalogo
de
software (ERS), con lo que se
- 322 -
GCS
Requisitos
Versin: 1.0
Fecha: 18/08/05
puede validar los requisitos, y se

obtuvo como resultado que los
requisitos son correctos y que
corresponden a los ERS.
6/06/05
Anlisis
del La revisin del plan de pruebas Gladys Aguagallo
Sistema
de
unitarias se lo realiza con los Paulina Caizares
Informacin
(ASI):
ERS, para verificar que las
Plan
Pruebas
de caractersticas a ser probadas

sean
las
correctas
que
corresponden al ERS.
13/06/05
Anlisis
del Se rene el equipo de trabajo Gerente
Sistema
de
que participo en el desarrollo del Personal
Informacin
(ASI):
plan del ASI para revisar este Administrativo
Aprobacin del documento , finalmente se
Equipo Tcnico
ASI
aprueba el plan.
3.2 REQUERIMIENTOS MINIMOS
6.2.1. REVISIN DE LOS REQUISITOS DEL SOFTWARE
El objetivo de la revisin de los requisitos del software es determinar, si se

ha comprendido todas las necesidades del cliente, el producto que debe ser
evaluado la Especificacin de Requisitos del Software.
6.2.2. REVISIN DE ANLISIS
El objetivo es asegurar que se han identificado todo lo que va a realizar el

sistema completo, luego de realizar esta revisin es asegurar que se ha
proporcionado todos los elementos necesarios para que las partes implicadas del
- 323 -
GCS
Versin: 1.0
Fecha: 18/08/05
equipo de desarrollo puedan llevar a cabo el diseo del sistema. La

documentacin ha ser evaluada ser:
Documento de Diseo funcional

Plan de pruebas del sistema y aceptacin.
4. REPORTE DE PROBLEMAS Y ACCIONES CORRECTIVAS
Al final de cada una de las revisiones que se realizar en cada lnea base,
se generar un informe de revisin, en el cual, a parte de los datos propios de la
revisin y sus asistentes indicarn los defectos encontrados si existen, para lo cual
se har uso del siguiente estndar de tipos de defectos.
REPORTE DE PROBLEMAS
NMERO
NOMBRE
DESCRIPCIN
10
Documentacin
Comentarios, mensajes, manuales.
20
Sintaxis
Problemas de sintaxis en general.
30
Variables
Problemas
de
asignacin
de
variables, declaracin.
40
Tipos complejos
Problemas de rangos, estructura o

contenido de tipos complejos
50
Interfaces Internas
Problemas
en
llamadas
procedimientos y argumentos
60
Interfaces externas
Problemas en el manejo de ficheros o

bases de datos
70
Interfaz de usuario
Problemas en la interfaz de usuario,

mensajes, formatos, pantallas.
- 324 -
GCS
Versin: 1.0
Fecha: 18/08/05
REPORTE DE PROBLEMAS
NMERO
NOMBRE
DESCRIPCIN
80
Comprobaciones de error
Problemas en los mensajes de error,

comprobacin
de
errores
inadecuados.
90
Lgica
Defectos en la lgica del programa,

ramificaciones, interacciones.
100
Otros
Otros problemas
PLAN DE GESTIN DE CONFIGURACIN DEL SOFTWARE

(IEEE Std. 828-1998)
1.2.
Propsito del Plan
El Plan de Gestin de Configuracin del Software establece y documenta los

requisitos, estndares y procedimientos para los elementos del software.
- 325 -
GCS
Versin: 1.0
Fecha: 18/08/05
Este plan tiene la finalidad de ser un documento base, tanto para el personal
de desarrollo como para el equipo de direccin del proyecto.
1.3.
Alcance
El Plan de Gestin de Configuracin del Software se aplicar al proyecto

SICOIN (Sistema de Control de Inventario), para realizar el cronograma de
actividades del proyecto se utilizara la herramienta Project.
1.4.
Definicin y Acrnimos
ACRONIMOS
SMC
Administrador de configuracin de Software
GC
Gestin de la Configuracin
GCS
Gestin de Configuracin de Software
EC
Elemento de Configuracin
LB
Lnea Base
SC
Solicitud de Cambio
SMOB01
Cdigo del Producto
CCC
Comit de Control de Cambios
DEFINICION
SICOIN
1.5.
Sistema de Control de inventario.
Referencias
Estndar IEEE 828 1998 (Estndar IEEE para Planes de Gestin de
Configuracin del Software (GCS)).
1.6.
Organizacin
- 326 -
GCS
Versin: 1.0
Fecha: 18/08/05
EL personal de desarrollo y el comit de control de cambio deben estar en

contacto permanente, de manera que no exista atraso en el proceso de cambio y
actualizacin.
1.7.
Responsables
1.6.1 Responsable de la Gestin de Configuracin
Responsables:
Gladys Aguagallo
Paulina Caizares
Funciones:
Realizar el Plan de Gestin de Configuracin
Controlar y Coordinar la Gestin de Configuracin.
1.6.2 Comit de Control de Cambios

El comit de control de cambios toma las decisiones finales acerca de las
peticiones de cambios, tomando en cuenta el estado, prioridad e impacto de cada
cambio de un ECS sobre otros ECS.
Este comit est formado por:

Gladys Aguagallo
Paulina Caizares
- 327 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.6.3 Biblioteca
Responsables:
Gladys Aguagallo
Paulina Caizares
EQUIPO DE TRABAJO
GCS
Gladys Aguagallo
Paulina Caizares
CCC
BIBLIOTECA
Gladys Aguagallo
Paulina Caizares
Gladys Aguagallo
Paulina Caizares
Fig. 4.5 Equipo de Trabajo
1.8.
Polticas, Directivas y Procedimientos
Se describen en el apartado de Control de Cambios de Configuracin.
- 328 -
GCS
1.9.
Versin: 1.0
Fecha: 18/08/05
Actividades de Gestin de Configuracin
1.8.1. Jerarqua Preliminar del Producto
SICOIN
GESTION
PROVEEDOR
GESTION
ARTICULO
GESTION
SOCIO
GESTION
FACTURA
COMPRA
GESTION
FACTURA
VENTA
Fig. 4.6 Jerarqua del Producto

1.8.2. Seleccin de los Elementos de Configuracin
Los Elementos de Configuracin de Software (ECS), son todos los productos generados y la informacin producida en un proyecto
cmo resultado del proceso de Ingeniera de software.
1.8.2.2.
Fase 1: Anlisis del Sistema
1.8.2.1.1 Especificacin del Requisitos Software (ERS)
El ERS es un documento seleccionado cmo EC ya que puede someterse a continuas

revisiones de los usuarios, desarrolladores y equipo de GC. El mismo que contiene:
Requisitos Funcionales (RF)
- 329 -
GCS
Versin: 1.0
Fecha: 18/08/05
Requisitos de Usuario (RU)

Hito Revisin de la Fase de Requisitos
1.8.2.3. Mdulo Especificacin Funcional del Sistema (EFS)
1.8.2.2.1 Documento de Diseo Funcional (DDF)

Este documento ser afectado por los cambios que se realicen en los ERS, el
mismo que est compuesto por los siguientes ECS:
Modelo Conceptual (MC)
Diagramas de casos de uso (DCU)
Definicin de Uso de Alto Nivel (DUAN)
Modelo Entidad /Relacin (MER)
Definicin de Interfaz de Usuario (DIU)
Especificacin del Plan de Pruebas (EPP)
Hito Revisin Fase de Especificacin Funcional del Sistema
1.8.2.4. Fase 2: Diseo del sistema
1.8.2.3.1 Mdulo Diseo Tcnico del Sistema (DTS)
1.8.2.31.1 Documento de Diseo Tcnico (DDT)
- 330 -
GCS
Versin: 1.0
Fecha: 18/08/05
Este documento constituye un ECS, por que une la documentacin que se maneja en el
diseo y se reflejan las decisiones tomadas para determinar la estructura del sistema, a su
vez se descompone en:
Diseo de la Arquitectura Fsica del Sistema (DAF)

Diseo de la Estructura Fsica de Datos del Sistema (DEFD)
Plan de Pruebas del Software del Proyecto (PPSP)
Hito Revisin Fase de Diseo
1.8.2.5. Fase 3: Construccin del Sistema
1.8.2.4.1 Mdulo Desarrollo de Componentes del Sistema (DCS)

Cdigo Fuente (CF)
Programas Ejecutables (PE)
Pruebas Unitarias y de Integracin (PUI)
Hito Revisin de Fase de Construccin
1.8.2.4.2 Mdulo PDU - Desarrollo de Procedimientos de Usuario.

Manual de Usuario (MU)
Hito Revisin de Fase de Construccin
1.8.2.6
Otros ECS
1.8.2.6.1 Estimacin del Sistema.
Documento que proporciona la estimacin del tamao, costo y recursos del

sistema.
- 331 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.8.2.6.2 Calendario de Entregas
Documento que contiene la planificacin de las fechas de terminacin de las

distintas fases, mdulos y actividades, que se tomaran en cuenta durante todo el
proceso del desarrollo.
1.8.2.6.3 Plan de Gestin de la Configuracin
Este ECS corresponde al documento actual, es importante cuando avance el

desarrollo del proyecto se irn incrementando los ECS, con la finalidad de determinar
cules son los elementos que se han sometido a control.
1.8.2.6.4 Plan de Garanta de la Calidad

Es un documento en el refleja las polticas de la organizacin y
procedimientos para asegurar la calidad de los productos que se generen en el
transcurso del desarrollo del sistema.
1.10.
Seleccin del Esquema de Identificacin
Se elaborara la hoja de los ECS en la que identificaremos cada uno de los EC de la

siguiente manera:
Hoja de Elementos de Configuracin de Software

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
ANARF01
Requisitos Funcionales.
Documento Requisitos Funcionales.
GRUPO DE ANALISTA DE SISTEMAS
- 332 -
GCS
FECHA DE CREACIN
IDENTIFICACIN DEL PROYECTO
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACIN
NUMERO DE VERSIN
FECHA DE VERSIN
Versin: 1.0
Fecha: 18/08/05
20/20/05
SICOIN
HITO REVISIN DE LA FASE DE ANLISIS
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACIN
NUMERO DE VERSIN
FECHA DE VERSIN
ANARU01
Requisitos de Usuario
Documento Requisitos de Usuario
GRUPO DE ANALISTA DE SISTEMAS
20/20/05
SICOIN
HITO REVISIN DE LA FASE DE ANLISIS
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
DDFMOC01
Modelo Conceptual
Documento del Modelo Conceptual
Grupo de Analistas
20/20/05
SICOIN
HITO REVISIN FASE DE
ESPECIFICACIN FUNCIONAL DEL
SISTEMA
DOCUMENTO
BIBLIOTECA
- 333 -
GCS
NUMERO DE VERSION
FECHA DE VERSION
Versin: 1.0
Fecha: 18/08/05
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DDFDCU01
Diagrama de Casos de Uso
Documento de Diagrama de Casos de Uso
Grupo de Analistas
20/20/05
SICOIN
SISTEMA
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DDFCAN01
Definicin de Casos de Uso de Alto Nivel
Documento de Definicin de Casos de Uso de
Alto Nivel
Grupo de Analistas
20/20/05
SICOIN
SISTEMA
DOCUMENTO
BIBLIOTECA
1
20/20/05
- 334 -
GCS
Versin: 1.0
Fecha: 18/08/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DDFMER01
Modelo Entidad / Relacin
Documento del Modelo Entidad / Relacin
Grupo de Analistas
20/20/05
SICOIN
SISTEMA
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DDFDIU01
Definicin de interfaces de Usuario
Documento de Definicin de Interfaces de
Usuario
Grupo de Analistas
20/20/05
SICOIN
HITO REVISIN FASE DE ESPECIFICACIN
FUNCIONAL DEL SISTEMA
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
DDFEPP01
Especificacin del Plan de Pruebas
Documento de Especificacin del Plan de
Pruebas.
Grupo de Analistas
20/20/05
SICOIN
SISTEMA
DOCUMENTO
- 335 -
GCS
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
Versin: 1.0
Fecha: 18/08/05
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DSIDAF01
Diseo de la Arquitectura Fsica del
Sistema.
Documento del Diseo de la Arquitectura
Fsica del Sistema.
Grupo de Analistas
20/20/05
SICOIN
HITO REVISIN DE LA FASE DE DISEO
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
DSIPPS01
Plan de Pruebas del Software del Proyecto.
Documento del Plan de Pruebas del
Software del Proyecto.
Grupo de Analistas
20/20/05
SICOIN
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
CSICF001
Cdigo Fuente
Documento del Cdigo Fuente
Grupo de Analistas
- 336 -
GCS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
Versin: 1.0
Fecha: 18/08/05
20/20/05
SICOIN
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
CSIPE001
Programas Ejecutables
Documento de Programas Ejecutables
Grupo de Analistas
20/20/05
SICOIN
HITO REVISIN DE LA FASE DE
CONSTRUCCION
DOCUMENTO
BIBLIOTECA
1
20/20/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
CSIPUI01
Programas Unitarias y de Integracin
Documento de Programas Unitarias y de
Integracin
Grupo de Analistas
20/20/05
SICOIN
CONSTRUCCIN
DOCUMENTO
BIBLIOTECA
1
20/20/05
- 337 -
GCS
Versin: 1.0
Fecha: 18/08/05

CODIGO ECS
NOMBRE ECS
DESCRIPCIN ECS
AUTOR/ ES ECS
FECHA DE CREACIN
IDEN DE LINEA BASE
CSIMU001
Manual de Usuario
Documento del Manual de Usuario
Grupo de Analistas
20/20/05
SICOIN
CONSTRUCCION
DOCUMENTO
BIBLIOTECA
1
20/20/05
TIPO DE ELEMENTO
LOCALIZACION
NUMERO DE VERSION
FECHA DE VERSION
1.11. Definicin de Relaciones
1.10.1 Equivalencia
La equivalencia se utiliza para mostrar los EC que se encuentran duplicado en otras

copias, la cual se localizar en el inventario de copias, que estar formado por los
siguientes campos.
Identificacin del ECS.

Nmero de copia
Tipo (Documento, programa)
Localizacin
- 338 -
GCS
Versin: 1.0
Fecha: 18/08/05
1.10.2 Composicin
La composicin se ha empleado cuando se divide un ECS en otros ECS.
ECS Contenedor
ECS Contenido
1.10.3 Dependencia
La dependencia se aplicar en la documentacin, la cual nos servir para facilitar la

trazabilidad de los requisitos.
1.10.4 Derivacin
La derivacin se aplica cuando un ECS tiene origen en otro ECS.

ECS Origen
ECS Generado
1.10.5 Sucesin
La sucesin es la historia de cambios de elementos desde una revisin a otras, esto se

conoce como el nmero de versiones.
1.12.
Definicin y Establecimiento de Lnea Base

- 339 -
GCS
Versin: 1.0
Fecha: 18/08/05
CODIGO LINEA BASE
REQ01
NOMBRE
Hito Revisin Fase de Requisitos
DESCRIPCION
Establecimiento de requisitos del Programa
AUTOR
Analista de Sistemas
FECHA
20/20/05
CODIGO LINEA BASE
REV01
NOMBRE
Hito Revisin Fase de Especificacin Funcional del

Sistema
DESCRIPCION
Mdulo EFS Especificacin Funcional del Sistema
AUTOR
Evaluacin
FECHA
20/20/05
CODIGO LINEA BASE
DIS01
NOMBRE
Hito Revisin Fase de Diseo
DESCRIPCIN
Diseo del sistema
AUTOR
Evaluacin
FECHA
20/20/05
CODIGO LINEA BASE
DIS01
NOMBRE
Hito Revisin Fase de Construccin
DESCRIPCIN
Construccin del sistema
AUTOR
Evaluacin
FECHA
20/20/05
1.13. Definicin y Establecimiento de Biblioteca de Software
Biblioteca de Trabajo
- 340 -
GCS
Versin: 1.0
Fecha: 18/08/05
C:>
PROYECTOS
SICOIN
Biblioteca de Trabajo
Gladys
Paulina
- 341 -
GCS
Versin: 1.0
Fecha: 18/08/05
Biblioteca de Integracin
C:>
PROYECTOS
SICOIN
Biblioteca de Integracin
Documentos
Ejecutables
Fuentes
Grficos
Biblioteca del Proyecto
C:>
PROYECTOS
SICOIN
Biblioteca del Proyecto
Lnea Base 1
Lnea Base 2
..
..
Lnea Base n
- 342 -
GCS
Versin: 1.0
Fecha: 18/08/05
Biblioteca Maestra
C:>
PROYECTOS
SICOIN
Biblioteca de Maestra
Documentos
Ejecutables
Fuentes
Grficos
Pruebas
1.14.
Control de Cambios
Para realizar el control de cambios de los elementos de configuracin hay

que:
Solicitud de Cambio (Ver Formato)

Clasificar y Registrar Solicitud de Cambio
Evaluacin de la Solicitud de Cambio
Aprobar o Rechazar Cambio
Informe de Cambio
Certificacin del Cambio (Ver Formato)
- 343 -
GCS
Versin: 1.0
Fecha: 18/08/05
SICOIN
SOLICITUD DE CAMBIO
16. Nombre del Sistema: _____________________________________________

17. # de Control: ___________________________________________________
18. Niveles de Aplicacin
Sistema ___ Hardware___ Software____ Documentacin____ Otros____
19. Solicitud de Cambios

Org. Originadora ________________________ Originador ______________
# Telefonico _____________ Fecha: ___/___/______
20. ECS Afectados

______________________________________________________________
21. Documentos Afectados

______________________________________________________________
22. Prioridad
Rutinario ____ Urgente ____ Emergente ____
23. Descripcin del Cambio

______________________________________________________________
24. Necesidades para el Cambio

______________________________________________________________
25. Afecta a otros Sistemas Software / Equipamiento el cambio

Si ____ No ____
En caso de seleccionar la opcin Si explicar en el siguiente punto.
26. Efectos estimados sobre otros Sistemas / software / Equipamiento

_____________________________________________________________
27. Alternativas
_____________________________________________________________
Esta rea debe ser contestada por el responsable de la GCS
28. Fecha de recepcin ____/____/______

29. Disposicin ___________________________________________________
30. Firma: _____________________________ Fecha: ____/____/____
- 344 -
GCS
Versin: 1.0
Fecha: 18/08/05
SICOIN
1. NOMBRE DEL SISTEMA

______________________________________________________________
2. # DE CONTROL
______________________________________________________________
3. ORIGINADOR DEL CAMBIO
______________________________________________________________
4. REALIZADOR DEL CAMBIO
______________________________________________________________
5. RESULTADOS DEL CAMBIO
______________________________________________________________
6. DISPOSICIN
______________________________________________________________
7. FIRMA
______________________________________________________________
8. FECHA
____/____/_______
1.15.
Contabilidad del Estado de la Configuracin
- 345 -
GCS
Versin: 1.0
Fecha: 18/08/05
Informa el estado de configuracin al administrador, usuario y desarrollador. A travs

de los siguientes informes:
Inventario de los ECS.

Inventario de Versiones.
Inventario de Lneas Base.
Inventario de copias.
1.14.1 Auditora de la Configuracin
Se realizan dos tipos que son:
Revisiones de Fase.
Revisiones de Cambios.
1.14.2 Programacin
Especificaremos los 5 hitos para la planificacin del sistema SICOIN con las referentes
fechas para su desarrollo:
Gestin
Requisitos
Anlisis
Diseo
Construccin (Producto y Operacin)
- 346 -
GCS
Versin: 1.0
Fecha: 18/08/05
COOPERATIVA SAN ANTONIO DEPARTAMENTO

COMISARIATO
ESTNDAR IEEE 610-1990 R2002
GOSARIO DE TERMINOLOGA DE INGENIERIA DE

SOFTWARE
1.9.1 A
Acceso: Accin de Llegar.
Aceptacin: Accin de aceptar
Administrador: La persona que supervisa y controla el correcto funcionamiento
de un sistema informtico
Alcance: Capacidad o posibilidad de coger y lograr algo.
Anlisis: Distincin y separacin de las partes de un todo hasta llegar a conocer
los principios o elementos de este.
Arquitectura: Arte de proyectar y construir.
Articulo: Cosa Comerciable.
ASI: Anlisis de Informacin de Informacin.
Atributos: Propiedad de un ser.
B
Base Datos: Aplicacin informtica para manejar informacin en forma de
"fichas": Proveedor, artculos, socios, factura venta, factura compra etc. La
mayora de las bases de datos actuales permiten hacer listados, consultas, crear
pantallas de visualizacin de datos, controlar el acceso de los usuarios.
Basic: Lenguaje de programacin inicialmente diseado para principiantes
(Beginners All-purpose Symbolic Instruction Code).
- 347 -
GCS
Versin: 1.0
Fecha: 18/08/05
C
CCC: Comit de Control de Cambios
Cajera: Persona que ejerce el cargo de cajero/a
Caso de alto Nivel:
Catalogacin: Accin de catalogar.
Clases: Grupo de divisin hecho con arreglo a determinadas condiciones o
calidades.
Compra: Accin de Compra.
Configuracin: Disposicin que compone una cosa.
Control: Sitio donde esta situado un control o inspeccin.
Construccin: Accin de Construir.
Consultar: Consulta de datos
CSI: Construccin del Sistema de Informacin.
D
DAF: Diseo de la Arquitectura Fsica del Sistema.
DCU: Diagramas de Casos de Uso.
Desarrollo: Accin de desarrollar o desarrollarse.
DDF: Documento de Diseo Funcional.
DDT: Documento de Diseo Tcnico.
DEFD: Diseo de la Estructura Fsica de Datos del Sistema.
Diseo: Trabajo de proyeccin de objetos de uso cotidiano.
DIU: Definicin de interfaz de Usuario.
Documento: Cosa que sirve para ilustrar o aclarar algo.
DSI: Diseo del Sistemas de Informacin.
DTS: Diseo Tcnico del sistema.
DUAN: Diseo de Alto Nivel.
DOS: Sistema operativo de disco (Disk Operating System). Se trata de un sistema
operativo monousuario y monotarea. Hay diversas versiones, con distintos
- 348 -
GCS
Versin: 1.0
Fecha: 18/08/05
nombres segn la casa que lo desarrolle: MsDos (Microsoft), DrDos (Digital

Research), PcDos (IBM), Novell Dos (Novell), etc.
E
EC: Elementos de configuracin.
Ejecutable: Un programa que se puede "ejecutar" o usar "por s solo", sin que
haga falta tener una cierta aplicacin informtica desde la que manejarlo.
EFS: Especificacin funcional del sistema.
Eliminar: Accin de eliminar.
EPP: Especificacin del Plan de Pruebas.
ERS: Especificacin de Requisitos Software.
Estndar: es un conjunto de criterios de desarrollo que guan la manera en que se
hace la ingeniera de software.
Estructura: Agrupamiento de un conjunto de datos que tiene unas propiedades
caractersticas.
Eventos: Suceso imprevisto.
EVS: Estudio de Viabilidad del Sistema.
1.9.2 F
Factura: Cuenta detallada de los objetos comprendidos en una venta.
Formulario: Relativo a las pantallas que presenta el sistema.
Fuente: Programa escrito en un lenguaje de programacin, antes de convertirse a
ejecutable o Tipo de letra.
G
GC: Gestin de Configuracin.
GCS: Gestin de Configuracin.
Gerente: Encargado general de una empresa o sociedad mercantil.
- 349 -
GCS
Versin: 1.0
Fecha: 18/08/05
Gestin: Hacer gestin de administrar.

H
Hardware: La parte "que se puede tocar" de un ordenador: caja (y todo su
contenido), teclado, pantalla.
Hito: Revisin de fase de requisitos.
I
IAS: Implementacin y Aceptacin del Sistema.
IEEE: Instituto de Ingenieros Elctricos y Electrnicos, una institucin americana
responsable de la creacin de una gran cantidad de estndares en electrnica e
informtica.
Impresora: Dispositivo encargado de volcar a papel la informacin que maneja un
ordenador.
Ingreso: Accin de ingresar.
Integracin: Proceso de unificacin de varias entidades.
Interfaz: Conexin de un ordenador con el exterior, o entre dos dispositivos.
Inventario: Asientos de los bienes y dems cosas pertenecientes a una persona o
comunidad.
I/O: Entrada/salida (Input/Output).
1.9.3 L
LB: Lnea Base.
M
MC: Modelo Conceptual.
Microprocesador: Es el "cerebro" del ordenador. Su velocidad de trabajo se mide
en Megahertzios (MHz) y su capacidad de proceso por el nmero de bits que es
capaz de manejar a la vez (por ejemplo: 32 bits, o 64 bits)..
- 350 -
GCS
Versin: 1.0
Fecha: 18/08/05
Microsoft: Casa desarrolladora de software, creadora de sistemas operativos

como MsDos y Windows, as como de aplicaciones informticas de todo tipo.
MER: Modelo Entidad/Relacin.
Metodologa: Es un conjunto de mtodos que se aplican en el desarrollo d un
sistema que incluye fases, tcnicas, procedimientos, reglas, herramientas,
documentacin y normas de calidad.
Modelo Entidad- Relacin:
Modificar: Cambiar atributos.
MSI: Mantenimiento del Sistema de Informacin.
Multitarea: Es cuando un ordenador es capaz de realizar ms de una tarea a la
vez. Puede ser en paralelo (si tiene ms de un procesador) o concurrente (si slo
tiene uno).
Mysql: Gestor de Base Datos
1.9.4 O
ODBC: Conectividad a la base de datos abierta, interfaz que da acceso a
powerdesigner.
Office: Suite realizada por Microsoft, que incluye aplicaciones como Word, Excel,
Outlook (y opcionalmente otras como Access o Publisher).
1.9.5 P
Pantalla: La pantalla (o monitor) es el dispositivo encargado de mostrar la
informacin mientras trabajamos con el ordenador. Hoy en da es habitual que las
pantallas sean de color, aunque todava se pueden encontrar pantallas
monocromas: de fsforo verde, mbar o blanco.
PC: Ordenador personal (Personal Computer). Esta abreviatura proviene del IBM
Personal Computer, creado por la casa IBM a principios de los 80.
Pentium: Procesador de 32 bits realizado por Intel, evolucin del 80486 (y
compatible con l y con toda la familia x86), con velocidades a partir de 60 MHz.
PPSP: Plan de Pruebas del Software del proyecto. Requerir
- 351 -
GCS
Versin: 1.0
Fecha: 18/08/05
Procesos: Conjunto de fases sucesivas.

Producto: Produccin de algo
Programa: Es un conjunto de rdenes para un ordenador. Cuando se trata de un
programa ya terminado que se compra, se suele hablar de una Aplicacin
Informtica. Los programas se deben escribir en un cierto lenguaje de
programacin.
Proveedor: Persona que tiene oficio de proveer.
Propsito: Intencin de hacer o de no hacer una cosa.
Pruebas: Accin de probar.
PSI: Planificacin de Sistemas de Informacin
1.9.6 R
Racional Rosse: Es una set de herramientas modeladoras visuales.
RAM: Memoria de acceso directo (Random Access Memory).
Ratn: Dispositivo utilizado para comunicarse con el ordenador. Permite sealar
zonas de la pantalla, como modo de indicar al ordenador lo que deseamos hacer.
Requisitos: Condicin necesaria para una cosa.
Responsabilidades: Calidad de responsable, obligacin de responder una cosa.
Restricciones: Limitacin y modificacin.
Revisin: Es habitual que una aplicacin software sufra modificaciones, mejoras o
correcciones. El nmero de versin suele indicar el avance de los cambios. Suelen
ser nmeros correlativos, y frecuentemente son dos cifras separadas por un punto.
RF: Requisitos Funcionales
RU: Requisitos de Usuarios
S
SC: Solicitud de Cambio.
SICOIN: Sistema de Control de Inventarios
Seguridad: Calidad de seguro.
- 352 -
GCS
Versin: 1.0
Fecha: 18/08/05
SMC: Administrador de configuracin de software.

SMOB01: Cdigo del Producto.
Sistema: Conjunto de reglas, principios o medidas, enlazadas

entre si.
Sistema Operativo: Es una capa intermedia entre el ordenador
y el usuario. Se podra considerar como un programa
(normalmente de gran tamao) que toma el control del
ordenador y que nos proporciona las utilidades bsicas. Para
usos ms avanzados, necesitaremos instalar aplicaciones
informticas como bases de datos, hojas de clculo, programas a
medida, etc.
Solicitud: Cualidad de solicitud.
Socio: persona asociada con otra para algn fin.
Software: La parte "que no se puede tocar" de un ordenador: los programas y los
datos.
T
Tabla: En el mundo de las bases de datos, un conjunto de registros (fichas) que
contienen los datos de nuestros proveedores podran estar almacenados en una
misma tabla.
Tecnologa: Conjunto de los conocimientos propios de una tcnica.

1.9.7 U
Unitario: Que propende a la unidad o a la conserva.
Usuario: Es La persona que se beneficia del sistema y emite resultados que son
almacenados.
1.9.8 V
Validacin: Accin de validar.
- 353 -
GCS
Versin: 1.0
Fecha: 18/08/05
Venta: Accin de vender.
W
Windows: Nombre genrico de toda una familia de software diseado por
Microsoft. Las primeras versiones (hasta la 3.11) eran un entorno grfico basado
en ventanas, para el sistema operativo Dos. A partir de Windows 95 (Windows 95
y Windows 98) ya se trata de un sistema operativo en s mismo, con capacidades
multitarea.
- 354 -
GCS
Versin: 1.0
Fecha: 18/08/05
PLANIFICACIN DEL SISTEMA
- 355 -
- 356 -

Ieee T Espel 0002

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ieee T Espel 0002

Загружено:

Авторское право:

Доступные форматы

ESCUELA POLITECNICA DEL EJRCITO

FACULTAD DE INGENIERIA DE SISTEMAS E INFORMATICA

INGENIEROS ELECTRICOS Y ELECTRONICOS) DE CALIDAD EN EL

PROYECTO PREVIO A LA OBTENCIN DEL TITULO DE INGENIERO EN

GLADYS PIEDAD AGUAGALLO LEMA

Es deber de los padres preparar a sus

CAPITULO I.- ANTECEDENTES DE LA INGENIERIA

TECNICAS Y PRACTICAS .....25

CAPITULO II.- ESTANDARES IEEE DE CALIDAD

2.2 CONCEPTO DE IEEE 28

CAPITULO III.- PROBLEMTICA DEL COMISARIATO

ANTECEDENTES DEL COMISARIATO DE LA COOPERATIVA .58

ESTUDIO DE LA SITUACIN ACTUAL DE LA COOPERATIVA.59

IMPORTANCIA DE LA AUTOMATIZACIN DEL INVENTARIO ...60

CAPITULO IV.- APLICACION DE LOS ESTANDARES IEEE DE

PLANIFICACION DE SISTEMAS DE INFORMACIN (PSI).......62

ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS) ..77

4.2.4.- ESTUDIO DE LA SITUACIN ACTUAL ...78

ANALISIS DEL SISTEMA DE INFORMACIN (ASI) ..84

DISEO DEL SISTEMA DE INFORMACIN (DSI).. .113

4.4.8.- GENERACIN DE ESPECIFICACIONES DE

CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)128

IMPLANTACIN Y ACEPTACIN DEL SISTEMA (IAS)..132

MATENIMIENTO DEL SISTEMA DE INFORMACIN (MSI)...133

4.8.2.- ANALISIS DEL SISTEMA DE INFORMACIN (ASI)134

4.10.- GESTION DE LA CONFIGURACIN152

CAPITULO V.- CONCLUSIONES Y RECOMENDACIONES

INFORMACIN RECOPILADA DE LA COOPERATIVA SAN

CALIDAD Y METRICA VERSION 3

1.1.- DEFINICION DE SOFTWARE

A continuacin se citara algunas definiciones:

El software es un conjunto de instrucciones detalladas que controlan la

El software es simplemente el conjunto de instrucciones individuales que se

El software es un conjunto de : INSTRUCCIONES que cuando se ejecutan

Fig. 1.1 Estructura del Software

En sntesis el software se puede definir como un conjunto de instrucciones

1.2.- PRODUCTO SOFTWARE

Un producto software se puede definir como una expresin de un conjunto

1.3.- METODOLOGIAS Y HERRAMIENTAS

La metodologa estudia al conjunto de mtodos integrados para alcanzar

La metodologa es una versin amplia y detallada de un ciclo de vida

Reglas, procedimientos, mtodos, herramientas

Funciones individuales y en grupos por cada tarea

[Whitten, Bentley, Barlow]

desarrolladores de sistemas de informacin.[MADDISON-83]

En conclusin metodologa es el conjunto de mtodos que se aplican en

anlisis de los requisitos, diseo de estructura de datos, arquitectura de

Las herramientas son los ambientes de apoyo necesario para automatizar

Las herramientas suministran un soporte automtico para los mtodos,

Las herramientas son ayudas automatizadas que soportan el control del

pruebas para asegurar la consistencia y

pruebas para la totalidad.

1.4.- MODELOS DE PROCESOS SOFTWARE

Un proceso software es un conjunto de actividades y resultados asociados

Existen 4 actividades fundamentales, comunes para todos los procesos de

1) Especificacin del software.- La funcionalidad del software y las

2) Desarrollo del software.- Debe producirse software que cumpla con la

3) Validacin del software.- El software debe validarse para asegurar

4) Evolucin del software.- El software debe evolucionar para cumplir

Distintos procesos de software organizan las actividades de diferentes

Modelo de Procesos del Software

Un modelo de procesos del software es una descripcin de un proceso de

Estos modelos, pueden ser: