View
1.119
Download
0
Embed Size (px)
DESCRIPTION
Este trabajo fue presentado como parte de las actividades del curso de ingeniería de software que se ofrece dentro del programa de ingeniería de sistemas de la Fundación Universitaria Konrad Lorenz. Autor: Lizza Catalina Medina González. Profesor que condujo el trabajo: Gustavo Adolfo Herazo Pérez
Citation preview
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 GONZALEZCODIGO 534001
DOCENTE
GUSTAVO HERAZOINGENIERO DE SISTEMAS
FUNDACION UNIVERSITARIA KONRAD LORENZFACULTAD DE MATEMÁTICAS E INGENIERÍAS
INGENIERÍA DE SISTEMASBOGOTA D.C.
2008
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
1 ASPECTOS 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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E 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.1 Espacial. 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.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E 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.2 Cronoló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.3 Conceptual.
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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
Sistema de Información, como el de los procesos de la Empresa ante
ISO.
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.4 Financiera.
De acuerdo a lo proyectado en la Fase I del proyecto, se tienes en cuenta
las siguientes necesidades:
Requerimientos valor
Medios de almacenamiento externo
200.00
0
(Usb, discos externos, CD, etc.)
Transporte 200.000
470.00
0
Asesoría profesor
Equipo PC
1.500.00
0
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
Servicios Internet
1.180.00
0
Papelería 100.000
Otros Gastos 200.000
total
3.150.00
0
1.4 OBJETIVOS
1.4.1 General.
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.2 Específicos.
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 -
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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
2 MARCO TEORICO.
2.1 ANTECEDENTES
2.1.1 Históricos
2.1.1.1 ASEGURAMIENTO 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
George Edwards fueron miembros de este grupo. Fue allí donde se acuñó el tér-
mino 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ó-
micos para resolver problemas fueron la base del moderno aseguramiento de la
calidad. [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.
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-
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.2 LEGALES.
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
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.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.
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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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:
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].
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
2.1.3 INVESTIGATIVOS
2.1.3.1 PROYECTO 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 so-
ftware para la IEEE 1074 se conceptúa como “Una aproximación lógica a la adqui-
sició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 so-
ftware, codificación y prueba del software. El proceso de soporte incluye: el proce-
so 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-
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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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?
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?
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
¿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 so-
ftware 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.
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:
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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?
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.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.
El principio tecnológico define las técnicas a utilizar en el proceso de desarrollo del
software.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.
Una vez seleccionados los índices de calidad, se debe establecer el proceso de
control, que requiere los siguientes pasos:
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.1 METAS A ALCANZAR.
En el proyecto se espera alcanzar las siguientes metas en los siguientes plazos
determinados:
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.2 PRINCIPIOS.
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.3 ENFOQUE.
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
información “Sistema Uno” esta área es el departamento financiero y se
agrupara todos los estudios en caja, tesorería y cartera.
2.3.4 NECESIDADES A SATISFACER.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.1TIPO 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.
3.2. ANALISIS
3.2.1.1 ANÁLISIS ORIENTADO A OBJETOS
EL LENGUAJE UNIFICADO DE MODELADO (UML)
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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
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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.
¿QUÉ ES UML?
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.)
• Relaciones: relacionan los elementos entre sí.
• Diagramas: Son colecciones de elementos con sus relaciones.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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
taquilleros y los jefes de taquilla) y las operaciones que pueden realizar (sus
roles).
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
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.
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
PROCESO DE DESARROLLO
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E 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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
Casos de uso
Validación dePasswor y contraseña
Asignar perfil
Asignar formulario
Validación de seguridad
Administración de red
Consultar factura de Arqueo
Digitación documento de
recaudo
Descargue de cartera
Genera arqueo
Impresión
Control de caja
Control deCaja
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
Genera reporte diario
Genera reporte cartera
Genera Notas Debito
Genera Notas Especiales
Impresión
APLICACIÓN DE CARTERA
ANALISTA DECARTERA
Genera reporte de pagos
Genera pagos de proveedores
GRAVAR CHEQUES POST-FECHADOS
Impresión
APLICACIÓN A PROVEEDORES
TESORERIA
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
DIAGRAMAS DE SECUENCIA
ADMINISTRACION DE RED
CONTROL DE CAJA
::SEGURIDAD ::PERFILES ::FORMULARIO ::BASEDATOS
VALIDAR CONTRASEÑA
ASIGNAR PERFIL
ASIG. FORMULARIO
PROCESO BD
CONFIRMACION DEL USUARIO
CONSULTAR CLIENTE (NIT, NOMBRE)
CONSULTAR N. FACTURA (NIT, N. FACTURA)
::CLIENTE ::ENCABEZADO ::DETALLE FACT. ::BASEDATOS
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
APLICACIÓN DE CARTERA
APLICACIÓN DE TESORERIA
::MOVIMIENTO DIARIO
::CONTABILIZARCARTERA
::NOTAS ::NOTAS ESPECIALES BASES DEDATOS
::VALIDACION USUARIO
CONFIRMACION
VALIDAR CONTRASEÑA
GENERA REPORTE DIARIO
GENERA REPORTES CARTERA
GENERA NOTA DB
GENERA NOTA ESPECIALES
VALIDACION DE
USUARIO
CUENTA DE PROVEEDOR
GENERAR CHEQUE A
PROVEEDOR
IMPRESIÓN DE REPORTE
BASES DE DATOS
VALIDARVALIDACION
CONFIRMACION
GENERA REP DIARIO
ELABORACION CHEQUE
DESCARGUE DE FACTURASIMPRESION
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
DIAGRAMAS DE ACTIVIDAD
ADMINISTRADOR DE RED
ESPERAINICIO
INGRESAR CONTRASEÑA
CONTRASEÑA CORRECTA
ASIGNAR PERFIL
NO SI
ASIGNAR PERFIL ESPERA
NO
SI
ASIGNAR FORMULARIO
NO
SI
TERMINAR
ESPERA
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
CONTROL DE CAJA
INICIO
CONSULTAR NIT, NOMBRE
CLIENTE CON
SALDO
CONSULTAR ENCABEZADO FACTURA
CONSULTAR DETALLE DE FACTURA
TERMINAR
SINO
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
APLICACIÓN DE CARTERA
INICIO
GENERAR REPORTE DIARIO
SE AFECTARON LAS CUENTAS DE CLIENTES
NO SI
EL CLIENTEDEVOLVIO
MERCANCIA
GENERAR REPORTE DE CARTERA
NO SI
GENERAR NOTA
EL CLIENTECOMPRO
COMSUMIBLES
NO
GENERAR NOTA ESPECIAL
SI
TERMINAR
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
APLICACIÓN TESORERIA
INICIO
GENERAR REPORTE DIARIOGENERAR REPORTE DE PROVEEDORES
PROVEEDORES EN MORA
NO SI
GENERAR CHEQUE
DESCARGUE DE FACTURAS
TERMINAR
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
DIAGRAMAS DE COLABORACION
ADMINISTRADOR DE RED
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
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.
SEGURIDAD PERFIL FORMULARIOS
2
1 3
1 2
3
CLIENTE ENCABEZADO DETALLE FACTURA
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
APLICACIÓN DE CARTERA
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
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.
MOVIMIENTO DIARIO
REPORTE DECARTERA
NOTASDB
NOTAS ESPECIALES
1 2
3
GENERAR REPORTEPROVEEDORES
GENERAR CHEQUE DESCARGUE DE FACTURAS1 2
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E 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?
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E 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 VIDAEficiencia Requerimientos y análisis y diseñoCorrección Pruebas e implantaciónConfiabilidad PruebasFacilidad de Mantenimiento PruebasFlexibilidad Análisis y diseñoReusabilidad Análisis y diseñoPortabilidad Análisis y diseño
3.5 METRICAS
3.5.1 METRICAS DIRECTAS(ORIENTADAS AL TAMAÑO)
PRODUCTIVIDAD (DESARROLLADORES)
LCD/PERSONA/MES1, 000,000/15/30 =2, 000,000
PRODUCTIVIDAD (DOCUMENTACION)
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
LDC/N DE DESARROLLADORES1, 000,000/15=66.667
COSTO
VALOR/LDC
42, 000,000/1, 000,000= 42CALIDAD
No DE ERRORES/LDC
10/1, 000,000= 0,00001
3.5.2 METRICAS INDIRECTAS( PUNTO DE FUNCION)
CONTROL DE CAJA
SALIDAS1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero Simple(4) Simple(5) referenciado 2 o 3 fichero Medio(5) referenciado 4 o mas ficheros referenciados ENTRADAS
1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero Simple(3) referenciado 2 fichero referenciado 3 o mas ficheros referenciados CONSULTASparte de salida
1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
0 o 1 fichero Simple(4) Simple(4) referenciado 2 o 3 fichero Medio(5) referenciado 4 o mas ficheros referenciados parte de entrada 1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de
referenciados referenciados datos referenciados0 o 1 fichero Simple(3) referenciado 2 fichero referenciado 3 o mas ficheros referenciados
FICHEROS1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación simple(7) de registro lógico 2-5 formato/relación Simple(7) de registro lógico 6 o mas formato/relación de registro lógico
INTERFACES1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(5) de registro lógico 6 o mas formato/relación de registro lógico
ADMINISTRADOR DE RED
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
SALIDAS1-5 ítems de datos 6-19 items de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero Simple(4) referenciado 2 o 3 fichero referenciado 4 o mas ficheros referenciados
ENTRADA1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero Simple(3) referenciado 2 fichero referenciado 3 o mas ficheros referenciados
CONSULTASparte de salida
1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero Simple(4) referenciado 2 o 3 fichero referenciado 4 o mas ficheros referenciados parte de entrada 1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de
referenciados referenciados datos referenciados0 o 1 fichero Simple(3) referenciado 2 fichero referenciado 3 o mas ficheros
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
referenciados
FICHEROS1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación simple(7) de registro lógico 2-5 formato/relación de registro lógico 6 o mas formato/relación de registro lógico
INTERFACES1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(5) de registro lógico 6 o mas formato/relación de registro lógico
APLICACIÓN DE CARTERA
SALIDAS
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero referenciado 2 o 3 fichero referenciado 4 o mas ficheros Medio(5) referenciados
ENTRADAS1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero referenciado 2 fichero referenciado 3 o mas ficheros referenciados Medio (4)
CONSULTASparte de salida
1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero referenciado 2 o 3 fichero referenciado 4 o mas ficheros Medio(5) referenciados parte de entrada 1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de
referenciados referenciados datos referenciados0 o 1 fichero referenciado 2 fichero referenciado 3 o mas ficheros
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
referenciados Medio(4)
ficheros1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(7) de registro lógico 6 o mas formato/relación de registro lógico
INTERFACES1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(5) de registro lógico 6 o mas formato/relación de registro lógico
APLICACIÓN DE TESORERIA
SALIDAS1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
0 o 1 fichero referenciado 2 o 3 fichero referenciado 4 o mas ficheros Medio(5) referenciados
ENTRADAS1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero referenciado 2 fichero referenciado 3 o mas ficheros referenciados Medio(4)
CONSULTASparte de salida
1-5 ítems de datos 6-19 ítems de datos 20 o mas ítems de referenciados referenciados datos referenciados
0 o 1 fichero referenciado 2 o 3 fichero referenciado 4 o mas ficheros Medio(5) referenciados parte de entrada 1-4 ítems de datos 5-15 ítems de datos 16 o mas ítems de
referenciados referenciados datos referenciados0 o 1 fichero referenciado 2 fichero referenciado 3 o mas ficheros referenciados Medio(4)
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
FICHEROS1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(7) de registro lógico 6 o mas formato/relación de registro lógico
INTERFACES1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados
1 formato/relación de registro lógico 2-5 formato/relación Simple(5) de registro lógico 6 o mas formato/relación de registro lógico
3.5.3 TABLA DE FACTOR COMPLEJIDAD
No FACTOR DE COMPLEJIDAD VALOR (0…5)
1 COMUNICACIÓN DE DATOS 02 FUNCION DISTRIBUIDA 0
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
3 RENDIMIENTO 34 CONFIGURACION UTILIZADA MASIVAMENTE 15 TASAS DE TRANSACCION 16 ENTRADA DE ON-LINE DE DATOS 57 DISEÑO PARA LA EFICIENCIA DE USUARIO FINAL 18 ACTUALIZACION ON-INE 49 COMPLEJIDAD DEL PROCESAMIENTO 5
10 UTILIZABLE EN OTRAS APLICACIONES 011 FACILIDAD DE INSTALACION 312 FACILIDAD DE OPERACIÓN 213 PUESTOS MULTIPLES 014 FACILIDAD DE CAMBIO 0
FACTOR DE COMPLEJIDAD TOTAL 25
3.5.4 PUNTOS DE FUNCION SIN AJUSTAR
SIMPLE MEDIO COMPLEJO CANTIDAD PESO CANTIDAD PESO CANTIDAD PESO ENTRADAS 2 3 2 4 6 14SALIDAD 3 4 3 5 7 27CONSULTAS 5 3 5 4 6 35FICHEROS 5 7 10 15 35INTERFACES 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
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
PF/PERSONA/MES2.161,50/0,5=4.323
DOCUMENTACIONPF/N DE DESARROLLADORES2.161,50/15=144,10
COSTOVALOR/PF42.000.000/2.161,50=19.431
No DE ERRORES/PF10/2.161,50=0.005
BIBLIOGRAFIA
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ-FACULTAD DE MATEMÁTICAS E INGENIERÍAS
[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_ISO_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