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 GONZALEZCODIGO 534001

DOCENTE

GUSTAVO HERAZOINGENIERO DE SISTEMAS

FUNDACION UNIVERSITARIA KONRAD LORENZFACULTAD DE MATEMÁTICAS E INGENIERÍAS

INGENIERÍA DE SISTEMASBOGOTA D.C.

2008

http://www.fukl.edu.co/index.php/programas/programaspregrado/ingenieria-sistemas


http://www.fukl.edu.co/


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





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.





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





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





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





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-




http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_calidad

http://es.wikipedia.org/wiki/ISO_9000

http://es.wikipedia.org/wiki/ISO


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.




http://es.wikipedia.org/wiki/ISO_9001:2000

http://es.wikipedia.org/wiki/2000



http://es.wikipedia.org/wiki/Organizaci%C3%B3n

http://es.wikipedia.org/wiki/Organizaci%C3%B3n_Internacional_para_la_Estandarizaci%C3%B3n



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




http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_la_calidad

http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_la_calidad

http://es.wikipedia.org/wiki/Empresa_de_consultor%C3%ADa

http://es.wikipedia.org/wiki/Empresa_de_consultor%C3%ADa

http://es.wikipedia.org/wiki/Entidades_de_certificaci%C3%B3n

http://es.wikipedia.org/wiki/Entidades_de_certificaci%C3%B3n



http://es.wikipedia.org/w/index.php?title=ISO_9004:2000&action=edit&redlink=1


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].




http://es.wikipedia.org/wiki/Organizaci%C3%B3n

http://es.wikipedia.org/wiki/Gesti%C3%B3n_de_calidad


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





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?





¿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:





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.





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.





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:





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:





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.





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)






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





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?





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.





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).





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.





PROCESO DE DESARROLLO





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





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





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





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






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




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





CONTROL DE CAJA

INICIO

CONSULTAR NIT, NOMBRE

CLIENTE CON

SALDO

CONSULTAR ENCABEZADO FACTURA

CONSULTAR DETALLE DE FACTURA

TERMINAR

SINO






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





APLICACIÓN TESORERIA

INICIO

GENERAR REPORTE DIARIOGENERAR REPORTE DE PROVEEDORES

PROVEEDORES EN MORA

NO SI

GENERAR CHEQUE

DESCARGUE DE FACTURAS

TERMINAR





DIAGRAMAS DE COLABORACION


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






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.


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





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?





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)





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






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






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


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





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




SALIDAS






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)



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)

ficheros1-19 ítems de da-tos 20-50 ítems de datos 51 o mas ítems de referenciados referenciados datos referenciados





SALIDAS1-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)



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)









3.5.3 TABLA DE FACTOR COMPLEJIDAD

No FACTOR DE COMPLEJIDAD VALOR (0…5)

1 COMUNICACIÓN DE DATOS 02 FUNCION DISTRIBUIDA 0





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





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





[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




http://tvdi.det.uvigo.es/~avilas/UML/node7.html

http://gfranklin.iespana.es/tesis/resumentot.pdf

http://bvs.sld.cu/revistas/aci/vol3_3_95/aci05395.htm

http://es.wikipedia.org/wiki/Historia_de_la_calidad

elaboración de técnicas de aseguramiento de la calidad _fukl_lizza

Documents