Elaboración de Técnicas de Aseguramiento de La Calidad - FUKL - LIZZA

FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E
INGENIERÍAS
Elaboración de técnicas de Aseguramiento de la Calidad y Métricas para el

mejoramiento de los procesos del sistema de Información UNO, del área
financiera de la empresa suministros E impresos Ltda.
ALUMNO
LIZZA CATALINA MEDINA GONZALEZ

CODIGO 534001
DOCENTE
GUSTAVO HERAZO
INGENIERO DE SISTEMAS
FUNDACION UNIVERSITARIA KONRAD LORENZ

FACULTAD DE MATEMÁTICAS E INGENIERÍAS
INGENIERÍA DE SISTEMAS
BOGOTA D.C.
2008
INGENIERÍAS
1ASPECTOS DE LA INVESTIGACION.
1.1 DESCRIPCION DEL PROBLEMA.
Actualmente, la empresa Suministros e Impresos Ltda., posee un Sistema de

Información llamado “Sistema UNO”, aplicado a todas las áreas de la Compañía,
sin embargo, éste sistema carece de estándares que le permita a la compañía
visualizar principios de aseguramiento de la calidad y por ende ningún tipo de
métrica de software que permita la auto evaluación y generar estándares para que
la empresa pueda mostrar indicadores de desempeño del sistema de información,
lo cual representa un grave problema con las áreas de calidad de la compañía.
Desde el momento de la creación el 25 de enero de 1984, la empresa suministros
e impresos ha procurado estar a la vanguardia de las innovaciones en el
mercado, inicialmente empezó siendo distribuidor directo de CARVAJAL S.A.,
LEGIS S.A., BEROL, INDISTRI, 3M COLOMBIA. Pero el mercado seguía
evolucionando y llegaron los consumibles y la compañía decide ampliar su gama
de productos y ahora cuenta con los proveedores más grandes del mercado de
los consumibles.
1.2JUSTIFICACION DEL PROYECTO DE INVESTIGACION.
De acuerdo a la necesidad que experimentan las empresas de lograr la

certificación ISO, La empresa “Suministros e Impresos Ltda.”, busca garantizar a
sus clientes, que los productos que se ofrecen son de la mejor calidad y cumplen
con las necesidades que cada uno de ellos requieren.
Por otro lado se hace necesario, ampliar su gama de elementos de
comercialización para seguir siendo uno de los distribuidores líderes en el
mercado. Así, mismo que los proveedores que cuentan en su portafolio, sientan la
INGENIERÍAS
seguridad que sus transacciones comerciales están regidas por toda la excelencia
que exige la certificación.
De acuerdo a los lineamientos que la Fundación Universitaria Konrad Lorenz

“FUKL” propone, se relacionan las siguientes justificaciones:
• Justificación Metodológica: El presente Proyecto de Investigación,

presentará técnicas de Metodología orientadas a negocios, basadas
en la normatividad que nos proporciona la ISO, siguiendo
paralelamente las fases descritas en el Método Científico
• Justificación Financiera: el presente proyecto busca ampliar las
ganancias generadas en la compañía obteniendo la certificación para
ampliar su gama de producto y portafolio de clientes.
• Justificación Organizacional: el presente proyecto esta orientado a
mejorar la distribución del área financiera y poder mejorar sus
procesos y obtener mejores resultados
1.3 DELIMITACION.
1.3.1Espacial. El Proyecto tendrá su foco en la empresa Suministros e impresos

Ltda. Ubicada en la Cra 22 N 73-28 dedicada a la distribución de papelería, la
cual fue fundada hace 24 años por la familia GAITSKELL,
El señor Maurice Gaitskell quien trabajaba en IBM decide colocar la
compañía por una idea de un amigo al momento de pensionarse, se inicia
en un garaje, con un vendedor, y una secretaria, en la actualidad se cuenta
con una edificación que reúne tres casas, y con 100 empleados.
INGENIERÍAS
Así mismo, el proyecto tendrá su control y seguimiento en las instalaciones de la

FUNDACION UNIVERSITARIA KONRAD LORENZ “FUKL” Entidad universitaria
ubicada en la Carrera 9 Bis N 62-43 de la ciudad de Bogota.
1.3.2Cronológica. Las siguientes son las actividades ha realizar para la gestión

del proyecto:
FASE 1 1 2 3 4 5 6 7 8
Actividades
Conocimiento de la Metodología de Investiga-
ción X X
Indagar los lineamientos de la Propuesta Inicial X
Reunión para delimitar el tema y aprobación X
Investigación Preliminar X X
Borrador de la propuesta de la Fase I X
Entrega de Documento para revisión X
Corrección Final de Fase I X
1.3.3Conceptual.
Inicialmente las bases conceptuales del Proyecto de Investigación, se

enfocaran en los siguientes tópicos:
• 1. Aseguramiento de la Calidad, correspondiente al análisis de los
procesos de la empresa “Suministro e Impresos Ltda.”, en toda el
área financiera.
• Métricas de Análisis y Diseño que cubra el área financiera del
Sistema de Información UNO.
• Las áreas de negocios que se incluirán en el estudio serán:
contabilidad, cartera y tesorería
• El análisis del estudio comprenderá todos los conceptos pertinentes
que nos aseguran inicialmente la certificación nacional tanto del
Sistema de Información, como el de los procesos de la Empresa ante
ISO.
INGENIERÍAS
• Metodología BMP, para el modelado de las reglas de negocios de la

Compañía.
• Análisis y Diseño Orientado a objetos, como modelo de ingeniería de
software, en conjunto con UML (Lenguaje de modelado unificado).
Los tópicos que no se tomaran en cuenta para el Proyecto serán:
1, Interfaces de análisis y diseño entre las demás áreas de la

compañía, que representen asocios con el área financiera.
2. Las áreas que estén descritas como procesos manuales y que estén
dentro del ámbito del área financiera, no se tendrán en cuenta para el
logro del Proyecto.
1.3.4Financiera.
De acuerdo a lo proyectado en la Fase I del proyecto, se tienes en cuenta

las siguientes necesidades:
INGENIERÍAS
Requerimientos valor
200.00
Medios de almacenamiento externo 0
(Usb, discos externos, CD, etc.)
Transporte 200.000
470.00
0
Asesoría profesor
1.500.00
Equipo PC 0
1.180.00
Servicios Internet 0
Papelería 100.000
Otros Gastos 200.000
3.150.00
total 0
1.4 OBJETIVOS
1.4.1General.
Elaborar un estudio que permita el Aseguramiento de la Calidad y Métricas para el

mejoramiento de los procesos del sistema de Información UNO, del área
financiera de la empresa suministros E impresos Ltda.
1.4.2Específicos.
• Conocimiento de la Metodología de Investigación
• Indagar los lineamientos de la Propuesta Inicial

INGENIERÍAS
• Elaborar el modelo de análisis de la propuesta utili-

zando una metodología de IS
• Elaborar el Diseño de la Propuesta utilizando UML

• Elaborar la propuesta basada en técnicas de aseguramiento
de la calidad
2MARCO TEORICO.
2.1 ANTECEDENTES
2.1.1Históricos
2.1.1.1ASEGURAMIENTO DE LA CALIDAD
El aseguramiento de la calidad es un aspecto importante de las operaciones de

producción en toda la historia, pero es en la década de los años veinte cuando se
consolidaría el término.
En esta época, los empleados del departamento de inspección de WE5TERN

ELECTRIC fueron transferidos a BELL TELEPHONE LABORATORIES. Las accio-
nes de este grupo comprendían la formulación de nuevas teorías y métodos de
inspección para mejorar y mantener la calidad.
Los pioneros del aseguramiento de calidad, Walter Shewnart, Harold Dodge y Ge-
orge Edwards fueron miembros de este grupo. Fue allí donde se acuñó el término
aseguramiento de la calidad. La elaboración de gráficas de control por parte de
Shewnart, de técnicas de muestreo por Dodge y de técnicas de análisis económi-
cos para resolver problemas fueron la base del moderno aseguramiento de la cali-
dad. [1]
Así mismo, La Organización Internacional de Normas ISO creada desde hace más
de cinco décadas, desde su fundación su propósito fue mejorar la calidad, aumen-
tar la productividad, disminuir los costos e impulsar el comercio internacional.
INGENIERÍAS
De este organismo surgen la familia de normas ISO 9000, que están integradas
por un conjunto de modelos y documentos sobre gestión de calidad. En 1987 se
publicaron las normas internacionales actuales sobre aseguramiento de la calidad.
Por primera vez, cada una de ellas sirve como un modelo de calidad dirigido a de-
terminada área de la industria, la manufactura o los servicios. En la actualidad cu-
bren todas las funciones o posibilidades de desempeño, y tienen el objetivo de lle-
var la calidad o la productividad de los productos o servicios que se oferten. Aun-
que los antecedentes más remotos de la existencia de la norma ISO 9000 datan
de hace más de 50 años, es importante destacar que la aceptación internacional
de la normalización ha tenido vigencia, sobre todo, a partir de la década de 1980
[2].
2.1.2LEGALES.
2.1.2.1 NORMA ISO 9000
La familia de NORMAS ISO 9000 son normas de calidad establecidas por la Orga-
nización Internacional para la Estandarización (ISO) que se pueden aplicar en
cualquier tipo de organización. Se componen de estándares y guías relacionados
con sistemas de gestión y de herramientas específicas como los métodos de audi-
toría (el proceso de verificar que los sistemas de gestión cumplen con el estándar).
Su implantación en estas organizaciones, aunque supone un duro trabajo, ofrece

una gran cantidad de ventajas para sus empresas. Los principales beneficios son:
• Reducción de rechazos e incidencias en la producción o prestación del ser-

vicio
• Aumento de la productividad
• Mayor compromiso con los requisitos del cliente
• Mejora continua
INGENIERÍAS
La familia de normas apareció por primera vez en 1987 teniendo como base una
norma estándar británica (BS), y se extendió principalmente a partir de su versión
de 1994, estando actualmente en su versión 2000.
La principal norma de la familia es: ISO 9001:2000 - Sistemas de Gestión de la

Calidad - Requisitos.
Y otra norma es vinculante a la anterior: ISO 9004:2000 - Sistemas de Gestión de

la Calidad - Guía de mejoras del funcionamiento.
Las normas ISO 9000 de 1994 estaban principalmente pensadas para organiza-
ciones que realizaban proceso productivo y, por tanto, su implantación en las em-
presas de servicios era muy dura y por eso se sigue en la creencia de que es un
sistema bastante burocrático.
Con la revisión de 2000 se ha conseguido una norma bastante menos burocrática

para organizaciones de todo tipo, y además se puede aplicar sin problemas en
empresas de servicios e incluso en la Administración Pública.
Para verificar que se cumple con los requisitos de la norma, existen unas entida-
des de certificación que dan sus propios certificados y permiten el sello. Estas enti-
dades están vigiladas por organismos nacionales que les dan su acreditación.
Para la implantación, es muy conveniente que apoye a la organización una empre-

sa de consultoría, que tenga buenas referencias, y el firme compromiso de la Di-
rección de que quiere implantar el Sistema, ya que es necesario dedicar tiempo
del personal de la empresa para implantar el Sistema de gestión de la calidad.
2.1.2.2 Marco Conceptual de las Normas ISO 9000
El marco conceptual de cumplimiento debe verificarse para que la organización

obtenga la certificación de su Sistema de gestión de la calidad.
INGENIERÍAS
Una organización que cumple con la ISO 9001:2005 sólo cumple con los requisitos
básicos en cuanto a normas de calidad. Si quiere ir más allá y lograr la excelencia,
debería cumplir requisitos adicionales. La ISO 9004:2000 establece estos requisi-
tos adicionales. Esta norma es entonces una guía para la mejora destinada a
aquellas organizaciones que quieren ir más allá de los requisitos básicos de cali-
dad de la ISO 9001:2005. La ISO 9004:2000 no es una norma certificable, y su
cumplimiento no puede ser exigido por una entidad certificadora. Tiene una princi-
pal diferencia en la gestión del sistema de calidad de la versión 2000 comparada
con la versión anterior del año 1994, esta diferencia es la introducción del concep-
to de «gestión por procesos interrelacionados». En vez de normar y asegurar la
calidad bajo una conceptualización estática, como ocurría en la versión de 1994,
en la nueva versión se propone complementarla con una visión integral y dinámica
de mejora continua, orientada a que el cliente se pueda sentir satisfecho.
En la versión 2000, se dice que el sistema de calidad debe demostrar que la orga-
nización es capaz de:
• Suministrar un producto o servicio que de manera consistente, cumpla con

los requisitos de los clientes y las reglamentaciones correspondientes.
• Lograr una satisfacción del cliente mediante la aplicación efectiva del siste-
ma, incluyendo la prevención de no-conformidades y el proceso de mejora
continua.
El modelo del sistema de calidad consiste en 4 principios que se dejan agrupar en

cuatro subsistemas interactivos de gestión de calidad y que se deben normar en la
organización.
• Responsabilidad de la Dirección;
• Gestión de los Recursos;
• Realización del Producto o Servicio;
• Medición, Análisis y Mejora
En esta versión también se incluyeron nuevas mejoras:

INGENIERÍAS
• Facilitar la comunicación entre la organización y los clientes.

• Incluir nuevos elementos como la información, comunicación, infraestructu-
ras y protección del ambiente de trabajo.
• Adaptar la terminología, como por ejemplo, usar el término organización en
vez de suministrador [3].
2.1.3INVESTIGATIVOS
2.1.3.1PROYECTO DE TESIS
ESTÁNDARES DE CALIDAD PARA PRUEBAS DE SOFTWARE PARA ALCAN-

ZAR EL NIVEL 2 DE TEST MATURITY MODEL. AUTOR, FECHA.
1.- PLANTEAMIENTO DEL PROBLEMA
En las diversas entidades (empresas, organizaciones, personas desarrolladoras

de software) de las aplicaciones de software se ha hecho cada vez más importan-
te en las labores cotidianas.
Potenciado con las mejoras tecnológicas en los equipos de computación y el auge
de Internet; soportan en muchos casos la mayor parte de las operaciones de ne-
gocio. El software se ha convertido en una actividad programada, planificada y con
un ciclo de vida definido que le otorga un carácter formal. El ciclo de vida del soft-
ware para la IEEE 1074 se conceptúa como “Una aproximación lógica a la adquisi-
ción, el suministro, el desarrollo, la explotación y el mantenimiento del software”.
Mientras para ISO 12207-1 el concepto de ciclo de vida es “Un marco de referen-
cia que contiene los procesos, las actividades y las tareas involucradas en el desa-
rrollo, la explotación y el mantenimiento de un producto de software, abarcando la
vida del sistema desde la definición de requisitos hasta la finalización de su uso”.
El ciclo de vida del software involucra una serie de procesos. El proceso de desa-
rrollo involucra: el análisis de los requisitos del software, el diseño detallado del
software, codificación y prueba del software. El proceso de soporte incluye: el pro-
ceso de aseguramiento de la calidad, proceso de verificación, proceso de valida-
ción. Las entidades tienen pues objetivos que deben lograr (planillas, inventarios,
determinar el flujo de caja, matrícula de clientes, notas,…); y, se hace; pero con al-
INGENIERÍAS
gunas fallas o errores, en consecuencia tenemos un problema; y, debemos nom-

brarlo, como:
Deficiencias en el proceso de pruebas de software.

Uno de los aspectos más descuidados en este gran proceso de desarrollo es pues
el de las pruebas, a pesar de ser el medio por el cual se puede asegurar la calidad
del producto de software, cumplir con los requisitos del usuario en la mayoría de
los casos no es suficiente, para ello hace falta definir un proceso de pruebas serio,
uniforme para todos los proyectos, es decir, estandarizado y que incluya las mejo-
res prácticas de pruebas siempre bajo un modelo que asegure la mejora conti-
nua.
Una alternativa para alcanzar competitividad en la industria del software requiere
desarrollar y aplicar un modelo basado en metodologías o procedimientos están-
dares para el planeamiento, especificación y ejecución de pruebas de software.
En las universidades que ofertan Ingeniería Informática o denominación afín las
actividades de pruebas de software pasan casi desapercibidas, pues no se crean
casos de pruebas que permitan garantizar la calidad del software, la ausencia de
una orientación clara en la planificación del proyecto y de políticas organizaciona-
les que apoyen este proceso debido al desconocimiento o inaplicabilidad de algu-
nos modelos de calidad aumentan el riesgo de producir software que inmediata-
mente reporta continuos errores o fallas graves. No se trata de sólo invertir más
tiempo o contratar más personal, lo que se necesita es una metodología que defi-
na actividades y responsabilidades, naturalmente esta tarea no se puede realizar
de manera improvisada sino que es un proceso gradual, aquí es donde CMM y to-
dos los modelos desprendidos de el pueden ayudar, tal como el TMM en su nivel
más adecuado.
FORMULACIÓN DEL PROBLEMA:

¿Cómo superar las deficiencias del proceso de pruebas de software basado en el
Nivel 2 del Modelo de Madurez de pruebas, las mejores prácticas de pruebas y
aseguramiento de calidad de software?
INGENIERÍAS
SISTEMATIZACIÓN DEL PROBLEMA:

¿Qué conceptos están relacionados con el proceso de pruebas de software?
¿Cómo analizar el proceso de pruebas de software como medio de aseguramiento
de calidad por excelencia?
¿Cuáles son los estándares y modelos de madurez más usados y sus deficiencias
para con los procesos de pruebas?
¿Qué es el modelo TMM para pruebas de software?
¿Cómo realizar una propuesta de un modelo de procesos de pruebas con el objeti-
vo de alcanzar el Nivel 2 de TMM.
JUSTIFICACIÓN EN IMPORTANCIA:
Esta investigación es necesaria para las organizaciones (universidades, empre-
sas públicas y privadas, municipalidades,…) porque al contar con un producto ga-
rantizado con alta calidad de software que adquiere evitaran la presencia de fallas
o errores que puedan dificultar la mayor parte de las operaciones de negocio en la
que estén involucrados.
Asimismo, complementariamente es conveniente para las entidades desarro-
lladoras de
Software; porque tienen la necesidad de garantizar la alta calidad de software, de-
biendo
Dedicar tiempo de desarrollo similar al de programación y desde luego implica un
impacto en el costo; siendo una fase que muchos de los involucrados aún n consi-
deran.
La importancia del tema a investigar está relacionado con un problema actual que
es contar
Con productos de software libre de fallas y errores. Aplicable de tal forma que sus
resultados aporten con estándares de calidad en el área de la Ingeniería de soft-
ware y que la sociedad tan dependiente de las tecnologías en sus tareas cotidia-
nas cuenten con productos con aseguramiento de su calidad y mejora continua.
INGENIERÍAS
Es por esto que la intención es rescatar la importancia de los estándares y meto-

dologías para las pruebas de software que vana a garantizar su calidad.
LIMITACIONES Y ALCANCE:
La presente investigación se limitará a:
Enfocar el análisis en definir la importancia de la calidad en el software, conceptos
previos para ayudar a aclarar los temas relacionados y justificar la investigación;
más adelante se analizará el proceso de pruebas de software como medio de ase-
guramiento de calidad por excelencia, se realizará un breve estudio de los están-
dares y modelos de madurez más usados y sus deficiencias para con los procesos
de pruebas; finalmente se analizarán dos de los modelos específicos para pruebas
de software, y a partir del más aceptado de ellos, para este caso TMM, se hará la
propuesta de un modelo de procesos de pruebas con el objetivo de alcanzar el Ni-
vel 2 de TMM.
En tal sentido el modelo de pruebas a plantear deberá satisfacer todos los objeti-
vos de madurez que plantea dicho nivel, se asumirá que las demás procesos rela-
cionados con el ciclo de vida de desarrollo de software también estarán por lo me-
nos en un nivel 2 de CMM o de CMM-SW o que se tiene un sistema calidad imple-
mentado. [5]
2.2 BASES TEORICAS
Uno de los problemas que se afrontan actualmente en la esfera de la computación

es la calidad del software. Desde la década del 70, este tema ha sido motivo de
preocupación para especialistas, ingenieros, investigadores y comercializadores
de software, los cuales han realizado gran cantidad de investigaciones al respecto
con dos objetivos fundamentales:
• ¿Cómo obtener un software con calidad?
• ¿Cómo evaluar la calidad del software?

INGENIERÍAS
Ambas interrogantes conllevan amplias respuestas, pero están estrechamente

ligadas con el concepto de la calidad del software, que es el resultado de la
primera y la fuente de la segunda.
2.2.1 ¿QUE ES LA 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 sinónimo de eficiencia,
flexibilidad, corrección, confiabilidad, portabilidad, usabilidad, seguridad e
integridad.
La calidad del software es medible y varía de un sistema a otro o de un programa

a otro. Un software elaborado para el control de naves espaciales debe ser confia-
ble al nivel de "cero fallas"; un software hecho para ejecutarse una sola vez no re-
quiere el mismo nivel de calidad; mientras que un producto de software para ser
explotado durante un largo período (10 años o más), necesita ser confiable, y flexi-
ble para disminuir los costos de mantenimiento y perfeccionamiento durante el
tiempo de explotación.
La calidad del software puede medirse después de elaborado el producto. Pero

esto puede resultar muy costoso si se detectan problemas deriva dos de imperfec-
ciones en el diseño, por lo que es imprescindible tener en cuenta tanto la obten-
ción de la calidad como su control durante todas las etapas del ciclo de vida del
software.
2.2.2 ¿COMO OBTENER UN SOFTWARE DE CALIDAD?

La obtención de un software con calidad implica la utilización de metodologías o
procedimientos estándares para el análisis, diseño, programación y prueba del
software que permitan uniformar la filosofía de trabajo, en aras de lograr una
mayor confiabilidad, y facilidad de prueba, a la vez que eleven la productividad,
tanto para la labor de desarrollo como para el control de la calidad del software.
La política establecida debe estar sustentada sobre tres principios básicos: tecno-
lógico, administrativo y ergonómico.
INGENIERÍAS
El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

software.
El principio administrativo contempla las funciones de planificación y control del

desarrollo del software, así como la organización del ambiente o centro de ingenie-
ría de software.
El principio ergonómico define la interfaz entre el usuario y el ambiente automati-

zado.
La adopción de una buena política contribuye en gran medida a lograr la calidad

del software, pero no la asegura. Para el aseguramiento de la calidad es necesario
su control o evaluación.
2.2. 3 ¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?
Para controlar la calidad del software es necesario, ante todo, definir los paráme-
tros, indicadores o criterios de medición, ya que, como bien plantea Tom De Mar-
co, "usted no puede controlar lo que no se puede medir".
Las cualidades para medir la calidad del software son definidas por innumerables
autores, los cuales las denominan y agrupan de formas diferentes. Por ejemplo,
John Wiley define métricas de calidad y criterios, donde cada métrica se obtiene a
partir de combinaciones de los diferentes criterios. La Metodología para la evalua-
ción de la calidad de los medios de programas de la CIC, de Rusia, define indica-
dores de calidad estructurados en cuatro niveles jerárquicos: factor, criterio, métri-
ca, elemento de evaluación, donde cada nivel inferior contiene los indicadores que
conforman el nivel precedente. Otros autores identifican la calidad con el nivel de
complejidad del software y definen dos categorías de métricas: de complejidad de
programa o código, y de complejidad de sistema o estructura.
Todos los autores coinciden en que el software posee determinados índices medi-
bles que son las bases para la calidad, el control y el perfeccionamiento de la pro-
ductividad.
INGENIERÍAS
Una vez seleccionados los índices de calidad, se debe establecer el proceso de

control, que requiere los siguientes pasos:
• Definir el software que va a ser controlado: clasificación por tipo, esfera de

aplicación, complejidad, etc., de acuerdo con los estándares establecidos
para el desarrollo del software.
• Seleccionar una medida que pueda ser aplicada al objeto de control. Para
cada clase de software es necesario definir los indicadores y sus magnitu-
des.
• Crear o determinar los métodos de valoración de los indicadores: métodos
manuales como cuestionarios o encuestas estándares para la medición de
criterios periciales y herramientas automatizadas para medir los criterios de
cálculo.
• Definir las regulaciones organizativas para realizar el control: quiénes parti-
cipan en el control de la calidad, cuándo se realiza, qué documentos deben
ser revisados y elaborados, etc.
A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en

un proyecto para el Aseguramiento de la Calidad del Software (ACS), válido para
cualquier entidad que se dedique a la investigación, producción y comercialización
del software, el cual incluye la elaboración de un Sistema de Indicadores de la
Calidad del Software, la confección de una Metodología para el Aseguramiento de
la Calidad del Software y el desarrollo de herramientas manuales y automatizadas
de apoyo para la aplicación de las técnicas y procedimientos del ACS, de forma tal
que se conforme un Sistema de Aseguramiento de la Calidad del Software. [4].
2.3 CONSTRUCCION DEL MARCO CONCEPTUAL.
2.3.1METAS A ALCANZAR.
INGENIERÍAS
En el proyecto se espera alcanzar las siguientes metas en los siguientes plazos

determinados:
• Corto: desarrollar la perspectiva que se tiene en el momento de escoger

un tema como proyecto y aplicar las metodologías para la construcción de
este, teniendo en cuenta los conocimientos adquiridos en el transcurso de
la materia.
• Mediano: buscar otros enfoques para el proyecto, continuar con este en

Ingeniería de Software II para enriquecerlo y que sea un proyecto a mayor
escala.
• Largo: lograr el titulo académico presentando el proyecto como trabajo de

grado.
2.3.2PRINCIPIOS.
Las características con las que el proyecto concluirá son las siguientes:
• Integridad en la información.
• Mejoramiento de la obtención de la información en el área financiera
• Mejoramiento de procesos para la seguridad de la información.
2.3.3ENFOQUE.
El presente Proyecto de Investigación tendrá un enfoque de tipo puntual, ya que
solo se centrara en una área especifica donde se implemento el sistema de
INGENIERÍAS
información “Sistema Uno” esta área es el departamento financiero y se

agrupara todos los estudios en caja, tesorería y cartera.
2.3.4NECESIDADES A SATISFACER.
Las necesidades que el proyecto va ha suplir de acuerdo a la descripción del
problema encontrado son las siguientes:
• Estándares de aseguramiento de la calidad que permita a la compañía
visualizar la auto evolución
• evaluar y generar estándares para que la empresa pueda mostrar
indicadores de desempeño del sistema de información.
• principios de aseguramiento de la calidad y por ende tipos de métrica de
software que permita la evaluación del sistema.
2.4 DEFINICION DE TERMINOS BASICOS.
• SQA : Software Quality Assurance (Aseguramiento de la Calidad del

Software)
• SQAP : Software Quality Assurance Plan
• SPM : Software Proyect Management
• SPMP : Software Proyect Management Plan
• ISO : Organización Internacional para la Estandarización.
3. DISEÑO METODOLOGICO
3.1 TIPO DE INVESTIGACION
El presente Proyecto de Investigación será de tipo descriptivo, puesto que se

realiza una investigación del tema elegido, se ejecuta la recolección de datos,
se busca que las personas describan sus actividades y procesos de una
manera clara y secuencial para poder tabular estos resultados con el fin de
extraer generalizaciones significativas que contribuyan al conocimiento.
INGENIERÍAS
3.2. ANALISIS
3.2.1.1 ANÁLISIS ORIENTADO A OBJETOS
EL LENGUAJE UNIFICADO DE MODELADO (UML)
Cualquier rama de ingeniería o arquitectura ha encontrado útil desde hace mucho

tiempo la representación de los diseños de forma gráfica. Desde los inicios de la
informática se han estado utilizando distintas formas de representar los diseños de
una forma más bien personal o con algún modelo gráfico. La falta de
estandarización en la manera de representar gráfica-mente un modelo impedía
que los diseños gráficos realizados se pudieran compartir fácilmente entre
distintos diseñadores.
Se necesitaba por tanto un lenguaje no sólo para comunicar las ideas a otros
desarrolladores sino también para servir de apoyo en los procesos de análisis de
un problema. Con este objetivo se creo el Lenguaje Unificado de Modelado (UML:
Unified Modeling Lan-guage). UML se ha convertido en ese estándar tan ansiado
para representar y modelar la información con la que se trabaja en las fases de
análisis y, especialmente, de diseño.
El lenguaje UML tiene una notación gráfica muy expresiva que permite representar
en mayor o menor medida todas las fases de un proyecto informático: desde el
análisis con los casos de uso, el diseño con los diagramas de clases, objetos, etc.,
hasta la implementación y configuración con los diagramas de des-pliegue.
HISTORIA DE UML
El lenguaje UML comenzó a gestarse en octubre de 1994 [1], cuando Rumbaugh
se unió a la compañía Rational fundada por Booch (dos reputados investiga-dores
en el área de metodología del software). El objetivo de ambos era unificar dos
métodos que habían desarrollado: el método Booch y el OMT (Object Mode-lling
Tool). El primer borrador apareció en octubre de 1995. En esa misma época otro
reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas.
Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje
INGENIERÍAS
se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas
estas colaboraciones condujeron a la definición de la primera versión de UML.
MODELADO VISUAL
Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una
simplificación de la realidad. El objetivo del modelado de un sistema es capturar
las partes esenciales del sistema. Para facilitar este modelado, se realiza una
abstracción y se plasma en una notación gráfica. Esto se conoce como modelado
visual.
El modelado visual permite manejar la complejidad de los sistemas a analizar o
diseñar. De la misma forma que para construir una choza no hace falta un modelo,
cuando se intenta construir un sistema complejo como un rascacielos, es
necesario abstraer la complejidad en modelos que el ser humano pueda entender.
UML sirve para el modelado completo de sistemas complejos, tanto en el diseño
de los sistemas software como para la arquitectura hardware donde se ejecuten.
Otro objetivo de este modelado visual es que sea independiente del lenguaje de
implementación, de tal forma que los diseños realizados usando UML se puedan
implementar en cualquier lenguaje que soporte las posibilidades de UML
(principalmente lenguajes orientados a objetos).
UML es además un método formal de modelado. Esto aporta las siguientes
ventajas:
• Mayor rigor en la especificación.
• Permite realizar una verificación y validación del modelo realizado.
• Se pueden automatizar determinados procesos y permite generar código a

partir de los modelos y a la inversa (a partir del código fuente generar los
modelos). Esto permite que el modelo y el código estén actualizados, con lo
que siempre se puede mantener la visión en el diseño, de más alto nivel, de
la estructura de un proyecto.
INGENIERÍAS
¿QUÉ ES UML?
UML es ante todo un lenguaje. Un lenguaje proporciona un vocabulario y unas

reglas para permitir una comunicación. En este caso, este lenguaje se centra en la
representación gráfica de un sistema.
Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo
crearlos. Esto último es el objetivo de las metodologías de desarrollo.
Los objetivos de UML son muchos, pero se pueden sintetizar sus funciones:
• Visualizar: UML permite expresar de una forma gráfica un sistema de forma

que otro lo puede entender.
• Especificar: UML permite especificar cuáles son las características de un

sistema antes de su construcción.
• Construir: A partir de los modelos especifica-dos se pueden construir los
sistemas diseñados.
• Documentar: Los propios elementos gráficos sirven como documentación del

sistema des-arrollado que pueden servir para su futura re-visión.
Aunque UML está pensado para modelar sistemas complejos con gran cantidad
de software, el lenguaje es los suficientemente expresivo como para modelar
sistemas que no son informáticos, como flujos de trabajo (workflow ) en una
empresa, diseño de la estructura de una organización y por supuesto, en el diseño
de hardware.
Un modelo UML esta compuesto por tres clases de bloques de construcción:
• Elementos: Los elementos son abstracciones de cosas reales o ficticias

(objetos, acciones, etc.)
INGENIERÍAS
• Relaciones: relacionan los elementos entre sí.
• Diagramas: Son colecciones de elementos con sus relaciones.
DIAGRAMAS UML
Un diagrama es la representación gráfica de un conjunto de elementos con sus

relaciones. En concreto, un diagrama ofrece una vista del sistema a modelar. Para
poder representar correctamente un sistema, UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas. UML incluye los
siguientes diagramas:
• Diagrama de casos de uso.

• Diagrama de clases.
• Diagrama de objetos.
• Diagrama de secuencia.
• Diagrama de colaboración.
• Diagrama de estados.
• Diagrama de actividades.
• Diagrama de componentes.
• Diagrama de despliegue.
Los diagramas más interesantes (y los más usados) son los de casos de uso,
clases y secuencia, por lo que nos centraremos en éstos. Pare ello, se utilizará
ejemplos de un sistema de venta de entradas de cine por Internet.
El diagrama de casos de usos representa gráficamente los casos de uso que tiene
un sistema. Se define un caso de uso como cada interacción supuesta con el
sistema a desarrollar, donde se representan los requisitos funcionales. Es decir, se
está diciendo lo que tiene que hacer un sistema y cómo. En la figura 3 se muestra
un ejemplo de casos de uso, donde se muestran tres actores (los clientes, los
INGENIERÍAS
taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus
roles).
El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones.
Éste es el diagrama más común a la hora de describir el diseño de los sistemas
orientados a objetos
En el diagrama de secuencia se muestra la interacción de los objetos que
componen un sistema de forma temporal.
El resto de diagramas muestran distintos aspectos del sistema a modelar. Para
modelar el comportamiento dinámico del sistema están los de interacción,
colaboración, estados y actividades. Los diagramas de componentes y despliegue
están enfocados a la implementación del sistema.
INGENIERÍAS
PROCESO DE DESARROLLO
INGENIERÍAS
Aunque UML es bastante independiente del pro-ceso de desarrollo que se siga,

los mismos creadores de UML han propuesto su propia metodología de desarrollo,
denominada el Proceso Unificado de Desarrollo
El Proceso Unificado está basado en componentes, lo cual quiere decir que el
sistema software en construcción está formado por componentes software
interconectados a través de interfaces bien definidos. Además, el Proceso
Unificado utiliza el UML para expresar gráficamente todos los esquemas de un
sistema software. Pero, realmente, los aspectos que definen este Proceso
Unificado son tres: es iterativo e incremental, dirigido por casos de uso y centrado
en la arquitectura
• Dirigido por casos de uso: Basándose en los casos de uso, los desarrolladores
crean una serie de modelos de diseño e implementación que los llevan a
cabo. Además, estos modelos se validan para que sean conformes a los
casos de uso. Finalmente, los casos de uso también sir-ven para realizar las
pruebas sobre los componentes desarrollados.
• Centrado en la arquitectura: En la arquitectura de la construcción, antes de

construir un edificio éste se contempla desde varios puntos de vista:
estructura, conducciones eléctricas, fontanería, etc. Cada uno de estos
aspectos está representado por un gráfico con su notación correspondiente.
Siguiendo este ejemplo, el concepto de arquitectura software incluye los
aspectos estáticos y dinámicos más significativos del sistema.
• Iterativo e incremental: Todo sistema informático complejo supone un gran

esfuerzo que puede durar desde varios meses hasta años. Por lo tanto, lo
más práctico es dividir un proyecto en varias fases. Actualmente se suele
hablar de ciclos de vida en los que se realizan varios recorridos por todas las
fases. Cada recorrido por las fases se denomina iteración en el proyecto en
la que se realizan varios tipos de trabajo (denominados flujos). [6]
3.3. DISEÑO
INGENIERÍAS
Casos de uso
Validación de seguridad
Validación de
Passwor y contraseña
Asignar perfil
Administración de
red
Asignar formulario
Control de caja
Consultar factura de
Arqueo
Digitación
documento de
recaudo
Descargue de cartera
Genera arqueo
Control de
Caja
Impresión
APLICACIÓN DE CARTERA
INGENIERÍAS
Genera reporte diario
Genera reporte
cartera
Genera Notas Debito
ANALISTA DE
CARTERA
Genera Notas Especiales
Impresión
APLICACIÓN A PROVEEDORES
Genera reporte de
pagos
Genera pagos de
proveedores
GRAVAR CHEQUES POST-

FECHADOS
TESORERIA
Impresión
INGENIERÍAS
DIAGRAMAS DE SECUENCIA
ADMINISTRACION DE RED
::SEGURIDAD ::PERFILES ::FORMULARIO ::BASEDATOS
VALIDAR CONTRASEÑA
ASIGNAR PERFIL
ASIG. FORMULARIO
PROCESO BD
CONFIRMACION DEL USUARIO
CONTROL DE CAJA
::CLIENTE ::ENCABEZADO ::DETALLE FACT. ::BASEDATOS
CONSULTAR CLIENTE (NIT, NOMBRE)
CONSULTAR N. FACTURA (NIT, N. FACTURA)
CONSULTAR VALOR TOTAL (NIT, N FACTURA, COCONSECUTIVO, COD.ARTICULO
DEVUELVE (NIT, NOMBRE, N.FACTURACONSECUTIVO, COD ARTICULO, SALDO FACTURA

FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
::VALIDACION ::MOVIMIENTO ::CONTABILIZAR

::NOTAS ::NOTAS ESPECIALES BASES DE
USUARIO DIARIO CARTERA DATOS
VALIDAR CONTRASEÑA
CONFIRMACION
GENERA REPORTE DIARIO
GENERA REPORTES CARTERA
GENERA NOTA DB
GENERA NOTA ESPECIALES
APLICACIÓN DE TESORERIA
VALIDACION CUENTA DE GENERAR BASES DE IMPRESIÓN

DE PROVEEDOR CHEQUE A DATOS DE REPORTE
USUARIO PROVEEDOR
VALIDACION
VALIDAR
CONFIRMACION
GENERA REP DIARIO
ELABORACION CHEQUE
DESCARGUE DE FACTURAS
IMPRESION
INGENIERÍAS
DIAGRAMAS DE ACTIVIDAD
ADMINISTRADOR DE RED
ESPERA INICIO
INGRESAR CONTRASEÑA
NO SI
CONTRASEÑA
CORRECTA
NO
ASIGNAR PERFIL
ESPERA
SI
ASIGNAR PERFIL
SI
ASIGNAR
NO
FORMULARIO
ESPERA
TERMINAR
INGENIERÍAS
CONTROL DE CAJA
INICIO
CONSULTAR NIT, NOMBRE
NO SI
CLIENTE CON
SALDO
CONSULTAR ENCABEZADO FACTURA
CONSULTAR DETALLE DE FACTURA
TERMINAR
INGENIERÍAS
INICIO
GENERAR REPORTE DIARIO
NO SI
SE AFECTARON
LAS CUENTAS
DE CLIENTES
GENERAR REPORTE DE CARTERA
NO EL CLIENTE SI
DEVOLVIO
MERCANCIA
GENERAR NOTA
NO EL CLIENTE SI
COMPRO
COMSUMIBLES
GENERAR NOTA ESPECIAL

TERMINAR
INGENIERÍAS
APLICACIÓN TESORERIA
INICIO
GENERAR
GENERAR
REPORTE
REPORTE
DIARIO
DE
PROVEEDORES
NO SI
PROVEEDORES EN
MORA
GENERAR CHEQUE
DESCARGUE DE
FACTURAS
TERMINAR
INGENIERÍAS
DIAGRAMAS DE COLABORACION
ADMINISTRADOR DE RED
SEGURIDAD
1 PERFIL
3 FORMULARIOS
1. Aporta los datos de seguridad del usuario para crear los perfiles.
2. Aporta la función de encriptación para guardar la clave.
3. De acuerdo a cada perfil se crean los formularios
CONTROL DE CAJA 3
CLIENTE
1 ENCABEZADO
2 DETALLE FACTURA
1. El cliente aporta los datos básicos a los datos del encabezado.

2. El encabezado me genera los registros del detalle de la factura.
3. Calcula el valor total de la factura.
INGENIERÍAS
MOVIMIENTO DIARIO REPORTE DE NOTASDB

1 CARTERA 2
NOTAS ESPECIALES
1. el movimiento diario contribuye generando el listado de movimientos

en la cuenta de cada cliente.
2. Notas DB aportan el movimiento de devoluciones del cliente.
3. Las notas especiales aportan el movimiento de descuentos por
compra de consumibles.
APLICACIÓN DE TESORERIA
GENERAR REPORTE GENERAR CHEQUE DESCARGUE DE

PROVEEDORES 1 2 FACTURAS
1. El generar el reporte de proveedores le aporta a generar cheque los

proveedores que están en mora.
2. Generar cheque colabora brindando el descargue de las facturas
vencidas.
INGENIERÍAS
3.4 MODELO DE CALIDAD

3.4.1 JUSTIFICACION
los modelos de calidad nos ayudan a buscar el perfeccionamiento de un
producto para cuando llegue a manos de los cliente sea lo que el cliente
necesitaba para suplir su necesidad, en este proyecto se implementara el
modelo de calidad Mc Call el cual se desarrolla partiendo del modelo
jerárquico de evaluar el proyecto y luego los productos de este proyectó, este
modelo se implementa en modelos pequeños, tomando en estudio los factores
que nos ayudaran a los criterios para mejorar el software, y de acuerdo a
estos criterios implementar sus respectivas métricas.
3.4.1.1 FACTORES A TENER EN CUENTA PARA ESTUDIO
Eficiencia
La cantidad de recursos de computadoras y de código requeridos por un
programa para llevar a cabo sus funciones. La pregunta asociada a este factor
sería: ¿Se ejecutará en mi hardware lo mejor que pueda?
Corrección
Es el grado en que un programa satisface sus especificaciones y consigue los
objetivos pedidos por el cliente. Este factor tiene una pregunta asociada:
¿Hace lo que quiero?
Confiabilidad
Es el grado en que se puede esperar que un programa lleve a cabo sus
funciones esperadas con la precisión requerida. La pregunta asociada a este
factor sería: ¿Lo hace de forma fiable todo el tiempo?
Facilidad de Mantenimiento
Es el esfuerzo requerido para localizar y arreglar un error en un programa. La
pregunta asociada a este factor sería: ¿Puedo corregirlo?
INGENIERÍAS
Flexibilidad
Es el esfuerzo requerido para modificar un programa operativo. La pregunta
asociada a este factor sería: ¿Puedo cambiarlo?
Reusabilidad
Es el grado en que un programa (o partes de este) se pueden rehusar en otras
aplicaciones. Este factor tiene una pregunta asociada: ¿Podré rehusar alguna
parte del software?
Portabilidad
Es el esfuerzo requerido para transferir el programa desde un hardware y/o un
entorno de sistema de software a otro. Este factor tiene una pregunta asociada:
¿Podré usarlo en otra máquina?[7]
FACTOR ETAPA DE CICLO DE VIDA

Eficiencia Requerimientos y análisis y diseño
Corrección Pruebas e implantación
Confiabilidad Pruebas
Facilidad de Mantenimiento Pruebas
Flexibilidad Análisis y diseño
Reusabilidad Análisis y diseño
Portabilidad Análisis y diseño
3.5 METRICAS
3.5.1 METRICAS DIRECTAS(ORIENTADAS AL TAMAÑO)
• PRODUCTIVIDAD (DESARROLLADORES)
LCD/PERSONA/MES
1, 000,000/15/30
=2, 000,000
PRODUCTIVIDAD (DOCUMENTACION)
INGENIERÍAS
LDC/N DE DESARROLLADORES
1, 000,000/15
=66.667
• COSTO
VALOR/LDC
42, 000,000/1, 000,000

= 42
• CALIDAD
No DE ERRORES/LDC
10/1, 000,000
= 0,00001
3.5.2 METRICAS INDIRECTAS( PUNTO DE FUNCION)
• CONTROL DE CAJA
SALIDAS
1-5 ítems de 6-19 ítems de 20 o mas ítems
datos datos de
datos referencia-
referenciados referenciados dos
0 o 1 fichero Simple(4) Simple(5)
referenciado
2 o 3 fichero Medio(5)
referenciado
4 o mas ficheros
referenciados
ENTRADAS

datos datos de
datos referencia-
0 o 1 fichero Simple(3)
referenciado
2 fichero
referenciado
INGENIERÍAS
3 o mas fiche-
ros
referenciados
CONSULTAS
parte de salida
datos datos de
datos referencia-
0 o 1 fichero Simple(4) Simple(4)
referenciado
2 o 3 fichero Medio(5)
referenciado
4 o mas ficheros
referenciados
parte de entra- 1-4 ítems de 5-15 ítems de 16 o mas ítems
da datos datos de
datos referencia-
referenciado
2 fichero
referenciado
3 o mas ficheros
referenciados
FICHEROS
datos datos de
datos referencia-
1 formato/rela-
ción simple(7)
de registro lógico
2-5 formato/rela-
ción Simple(7)
de registro lógico
6 o mas formato/rela-
ción
de registro lógico
INTERFACES
datos datos de
INGENIERÍAS
datos referencia-
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(5)
de registro lógico
ción
de registro lógico
• ADMINISTRADOR DE RED
SALIDAS
1-5 ítems de 6-19 items de 20 o mas ítems
datos datos de
datos referencia-
referenciado
2 o 3 fichero
referenciado
4 o mas ficheros
referenciados
ENTRADA
datos datos de
datos referencia-
referenciado
2 fichero
referenciado
3 o mas ficheros
referenciados
INGENIERÍAS
CONSULTAS
parte de salida
datos datos de
datos referencia-
referenciado
2 o 3 fichero
referenciado
4 o mas ficheros
referenciados
da datos datos de
datos referencia-
referenciado
2 fichero
referenciado
3 o mas ficheros
referenciados
FICHEROS
datos datos de
datos referencia-
1 formato/rela-
ción simple(7)
de registro lógico
2-5 formato/rela-
ción
de registro lógico
ción
de registro lógico
INTERFACES
INGENIERÍAS
datos datos de
datos referencia-
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(5)
de registro lógico
ción
de registro lógico
• APLICACIÓN DE CARTERA
SALIDAS
datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 o 3 fichero
referenciado
4 o mas ficheros Medio(5)
referenciados
ENTRADAS
datos datos de
INGENIERÍAS
datos referencia-
0 o 1 fichero
referenciado
2 fichero
referenciado
3 o mas ficheros
referenciados Medio (4)
CONSULTAS
parte de salida
datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 o 3 fichero
referenciado
referenciados
da datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 fichero
referenciado
3 o mas ficheros
referenciados Medio(4)
ficheros
datos datos de
datos referencia-
INGENIERÍAS
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(7)
de registro lógico
ción
de registro lógico
INTERFACES
datos datos de
datos referencia-
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(5)
de registro lógico
ción
de registro lógico
• APLICACIÓN DE TESORERIA
SALIDAS
datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 o 3 fichero
INGENIERÍAS
referenciado
referenciados
ENTRADAS
datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 fichero
referenciado
3 o mas ficheros
CONSULTAS
parte de salida
datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 o 3 fichero
referenciado
referenciados
da datos datos de
datos referencia-
0 o 1 fichero
referenciado
2 fichero
referenciado
3 o mas ficheros
INGENIERÍAS
FICHEROS
datos datos de
datos referencia-
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(7)
de registro lógico
ción
de registro lógico
INTERFACES
datos datos de
datos referencia-
1 formato/rela-
ción
de registro lógico
2-5 formato/rela-
ción Simple(5)
de registro lógico
ción
de registro lógico
3.5.3 TABLA DE FACTOR COMPLEJIDAD

INGENIERÍAS
No FACTOR DE COMPLEJIDAD VALOR

(0…5)
1 COMUNICACIÓN DE DATOS 0
FUNCION DISTRI-
2 BUIDA 0
3 RENDIMIENTO 3
CONFIGURACION UTILIZADA MASIVAMEN-
4 TE 1
TASAS DE TRAN-
5 SACCION 1
ENTRADA DE ON-LINE DE DA-
6 TOS 5
DISEÑO PARA LA EFICIENCIA DE USUARIO
7 FINAL 1
ACTUALIZACION
8 ON-INE 4
COMPLEJIDAD DEL PROCESA-
9 MIENTO 5
UTILIZABLE EN OTRAS APLICA-
10 CIONES 0
11 FACILIDAD DE INSTALACION 3
12 FACILIDAD DE OPERACIÓN 2
PUESTOS MULTI-
13 PLES 0
FACILIDAD DE CAM-
14 BIO 0
FACTOR DE COMPLEJIDAD
TOTAL 25
3.5.4 PUNTOS DE FUNCION SIN AJUSTAR

SIMPLE MEDIO COMPLEJO
CANTIDAD PESO CANTIDAD PESO CANTIDAD PESO
ENTRA-
DAS 2 3 2 4 6 14
SALIDAD 3 4 3 5 7 27
INGENIERÍAS
CONSUL-
TAS 5 3 5 4 6 35
FICHEROS 5 7 10 15 35
INTERFA-
CES 4 5 7 10 20
131
3.5.5 INDIRECTAS CON PUNTO DE FUNCION

PF= (Σ (0,65+0,01)*Σ [Fi])
PF= (131)*(0,65+0,01)*(25)
PF=2.165,50
• PRODUCTIVIDAD
PF/PERSONA/MES
2.161,50/0,5
=4.323
• DOCUMENTACION
PF/N DE DESARROLLADORES
2.161,50/15
=144,10
• COSTO
VALOR/PF
42.000.000/2.161,50
=19.431
• No DE ERRORES/PF
10/2.161,50
=0.005
INGENIERÍAS
BIBLIOGRAFIA
[1] http://www.gestiopolis.com/canales/gerencial/articulos/27/asesis.htm
[2] http://es.wikipedia.org/wiki/Historia_de_la_calidad
[3]http://es.wikipedia.org/wiki/Caracter%C3%ADsticas_de_la_serie_de_normas_IS
O_9000
[4] http://bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm
[5] http://gfranklin.iespana.es/tesis/resumentot.pdf
[6] http://tvdi.det.uvigo.es/~avilas/UML/node7.html
[7] http://www.monografias.com

Elaboración de Técnicas de Aseguramiento de La Calidad - FUKL - LIZZA

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Elaboración de Técnicas de Aseguramiento de La Calidad - FUKL - LIZZA

Transféré par

Droits d'auteur :

Formats disponibles

FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E

Elaboración de técnicas de Aseguramiento de la Calidad y Métricas para el

LIZZA CATALINA MEDINA GONZALEZ

FUNDACION UNIVERSITARIA KONRAD LORENZ

1.1 DESCRIPCION DEL PROBLEMA.

Actualmente, la empresa Suministros e Impresos Ltda., posee un Sistema de

1.2JUSTIFICACION DEL PROYECTO DE INVESTIGACION.

De acuerdo a la necesidad que experimentan las empresas de lograr la

De acuerdo a los lineamientos que la Fundación Universitaria Konrad Lorenz

• Justificación Metodológica: El presente Proyecto de Investigación,

1.3.1Espacial. El Proyecto tendrá su foco en la empresa Suministros e impresos

Así mismo, el proyecto tendrá su control y seguimiento en las instalaciones de la

1.3.2Cronológica. Las siguientes son las actividades ha realizar para la gestión

Inicialmente las bases conceptuales del Proyecto de Investigación, se

• Metodología BMP, para el modelado de las reglas de negocios de la

Los tópicos que no se tomaran en cuenta para el Proyecto serán:

1, Interfaces de análisis y diseño entre las demás áreas de la

De acuerdo a lo proyectado en la Fase I del proyecto, se tienes en cuenta

Elaborar un estudio que permita el Aseguramiento de la Calidad y Métricas para el

• Conocimiento de la Metodología de Investigación

• Indagar los lineamientos de la Propuesta Inicial

• Elaborar el modelo de análisis de la propuesta utili-

• Elaborar el Diseño de la Propuesta utilizando UML

El aseguramiento de la calidad es un aspecto importante de las operaciones de

En esta época, los empleados del departamento de inspección de WE5TERN

2.1.2.1 NORMA ISO 9000

Su implantación en estas organizaciones, aunque supone un duro trabajo, ofrece

• Reducción de rechazos e incidencias en la producción o prestación del ser-

La principal norma de la familia es: ISO 9001:2000 - Sistemas de Gestión de la

Y otra norma es vinculante a la anterior: ISO 9004:2000 - Sistemas de Gestión de

Con la revisión de 2000 se ha conseguido una norma bastante menos burocrática

Para la implantación, es muy conveniente que apoye a la organización una empre-

2.1.2.2 Marco Conceptual de las Normas ISO 9000

El marco conceptual de cumplimiento debe verificarse para que la organización

• Suministrar un producto o servicio que de manera consistente, cumpla con

El modelo del sistema de calidad consiste en 4 principios que se dejan agrupar en

En esta versión también se incluyeron nuevas mejoras:

• Facilitar la comunicación entre la organización y los clientes.

ESTÁNDARES DE CALIDAD PARA PRUEBAS DE SOFTWARE PARA ALCAN-

1.- PLANTEAMIENTO DEL PROBLEMA

En las diversas entidades (empresas, organizaciones, personas desarrolladoras

gunas fallas o errores, en consecuencia tenemos un problema; y, debemos nom-

Deficiencias en el proceso de pruebas de software.

FORMULACIÓN DEL PROBLEMA:

SISTEMATIZACIÓN DEL PROBLEMA:

Es por esto que la intención es rescatar la importancia de los estándares y meto-

2.2 BASES TEORICAS

Uno de los problemas que se afrontan actualmente en la esfera de la computación

• ¿Cómo obtener un software con calidad?

• ¿Cómo evaluar la calidad del software?

Ambas interrogantes conllevan amplias respuestas, pero están estrechamente

2.2.1 ¿QUE ES LA CALIDAD DEL SOFTWARE?

La calidad del software es medible y varía de un sistema a otro o de un programa

La calidad del software puede medirse después de elaborado el producto. Pero

2.2.2 ¿COMO OBTENER UN SOFTWARE DE CALIDAD?

El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del

El principio administrativo contempla las funciones de planificación y control del

El principio ergonómico define la interfaz entre el usuario y el ambiente automati-

La adopción de una buena política contribuye en gran medida a lograr la calidad

2.2. 3 ¿COMO CONTROLAR LA CALIDAD DEL SOFTWARE?

Una vez seleccionados los índices de calidad, se debe establecer el proceso de

• Definir el software que va a ser controlado: clasificación por tipo, esfera de

A partir del análisis de todo lo anterior, nuestro Centro se encuentra enfrascado en