Gerencia de Proyectos Informaticos

jueves, 10 de junio de 2010

KMKey Project

Caracteristicas Positivas:
- Planificación del proyecto. WBS. Flujos de trabajo. Calendario.
- Graficos Gantt. Periodos de ejecución. Progreso. Real frente previsto. Tareas fuera de plazo. Avisos.
- Enlace con MS Project para generar el flujo de trabajo.

Caracteristicas Negativas:

- Desde el mismo gestor de expedientes cualquier usuario autorizado puede introducir No Conformidades.
- Se puede planificar las correspondientes Acciones Correctivas o Preventivas por parte de usurarios no autorizados.
- Se puede repartir las tareas a cada uno de los responsables y controlando plazos y acciones realizadas, de ususarios no autorizados.

Service Desktop Pro

Características Positivas:
- Provee soporte al cliente debe iniciada desde la recepción de solicitudes,evaluandola.
- Asigna el trabajo a los miembros del equipo.
- Ejecuta las obra y comunica al cliente de la finalización de las obras.

Características Negativas:
-Puede crear errores de registros y de notificación de defectos por parte de los clientes en sus diversos proyectos.
- No asigna prioridad y seguimiento de acciones.
- No define claramente las medidas que deben adoptarse a la hora de defectos.

ProjectPlan

Características Destacadas:
* Planes de Proyecto Impresionante
* Proyecto de Integración de MS
* Planes de proyectos traje de todas las formas y tamaños
* Herramientas avanzadas de programación

Características negativas:
- Projectplan no tiene casi nada que ofrecer cuando se trata de la cuenta con su colaboración.
- No tiene buenas funciones de colaboración.
- No es tan fácil de usar y navegar;
- Solo tiene utilidad para las empresas que ya tienen un sistema de comunicación eficaz en su lugar.

jueves, 3 de junio de 2010

Cost Xpert

Con el objetivo de una forma fácil, rápida aplicación, seguro y confiable de los métodos científicos en la práctica, Costo Xpert desarrollado una intuitiva herramienta estándar operados. This methodology is usable even without expert knowledge. Esta metodología se puede utilizar incluso sin el conocimiento de expertos.
The Cost Xpert Tool Suite represents the latest standard of the Integrated Methodology driven Estimation (IME) and is an intuitive operated standard tool for the realistic estimation of effort, time, resources and cost to complete a project, as well as an estimate of potential risk, defects, and documentation page count for the entire IT application life cycle. El costo Xpert Herramienta Suite representa el último estándar de la Metodología integrada impulsada Estimación (IME), y es una intuitiva herramienta operada estándar para la estimación realista de esfuerzo, tiempo, recursos y costos para completar un proyecto, así como una estimación del riesgo potencial , defectos, y recuento de páginas de documentación para todo el ciclo de vida de TI de la aplicación. Our solution is based on scientifically published methods and models , industry standards and best practice approaches. Nuestra solución se basa en la publicación científica métodos y modelos estándares de la industria, y las mejores enfoques de la práctica. It is the most comprehensive approach, covering any project situation no matter if it is feasibility phase, development or maintenance. Es el enfoque más integral, que cubre cualquier situación del proyecto, no importa si es la fase de viabilidad, el desarrollo o mantenimiento.

The intelligent consideration of all relevant elements including project types, process models, hard facts, soft facts, quality and risk factors and constraints ensures the accurate estimation . La consideración inteligente de todos los elementos pertinentes incluyendo los tipos de proyectos, modelos de procesos, hechos, duros y blandos, la calidad y los factores de riesgo y las limitaciones garantiza la estimación exacta . The intuitive workflow and precalibrations of our expert system, as well as a wizard guided assessment enables the effective use of methods even without the necessarily need to become a methodology expert first. El flujo de trabajo intuitivo y precalibrations de nuestro sistema de expertos, así como una evaluación guiada asistente permite el uso eficaz de los métodos, incluso sin la necesidad de ser necesariamente un experto en metodología de primera.
The IME represents the cutting-edge of methodologies and technologies. El IME representa la vanguardia de las metodologías y tecnologías. [Referencia]: www.costxpert.eu/en/expertise_product/cost_xpert_tool_suite

CHECKPOINT

Check Point se creó en 1993, por el actual Presidente de la compañía y CEO Gil Shwed , a la edad de 25, junto con dos de sus amigos, Marius Nacht (actualmente se desempeña como Vice Presidente) y Shlomo Kramer (que dejó de Check Point en 2003 a crear una nueva empresa - Imperva , donde se desempeña como Presidente y CEO). Gil had the initial idea for the company's core technology know as stateful inspection , which became the foundation for the company's first product (simply called FireWall-1 ); soon afterwards they also developed one of the world's first VPN products ( VPN-1 ). Gil tuvo la idea inicial de la tecnología básica de la empresa se conoce como inspección de estado , que se convirtió en la base para el primer producto de la empresa de la (llamada simplemente FireWall-1 ); poco después que su evolución también uno de los primeros VPN mundo los productos de la ( VPN-1 ).

Check Point Software Technologies Ltd. ( NASDAQ : CHKP ) es un proveedor global de seguridad de TI soluciones. Best known for its firewall and VPN products, Check Point first pioneered the industry with FireWall-1 and its patented stateful inspection technology. Mejor conocida por su firewall y VPN productos de Check Point primero fue pionera en la industria con FireWall-1 y su tecnología patentada de inspección de estado de tecnología. Today the company develops, markets and supports a wide range of software and combined hardware and software products that cover all the aspects of IT security, including network security , endpoint security and security management . Actualmente, la empresa desarrolla, comercializa y apoya una amplia gama de software y combinados de hardware y software que cubren todos los aspectos de seguridad de TI, incluyendo seguridad de red , seguridad de punto final y gestión de la seguridad .[Referencia]: http://en.wikipedia.org/wiki/Check_Point

El Modelo SLIM

Estimación por Analogía
El Modelo SLIM

La Ecuación del Software
La cantidad de trabajo que se encuentra en cualquier producto se puede ver como el producto del esfuerzo realizado en un periodo de tiempo, y se puede escribir como
Producto = (Constante) • Esfuerzo • Tiempo
donde
Producto representa cierta medida sobre la funcionalidad del mismo, y se cree proporcional al producto Esfuerzo • Tiempo. La medida SLOC suele ser una medida habitual de la funcionalidad.
Esfuerzo representa el trabajo humano, medido en personas-mes o personas-año.
Tiempo representa la duración del trabajo, medido en meses o años.
La Constante es un factor de proporcionalidad. Una vez establecidas las otras tres variables, esta constante permite igualarlos. Sin embargo parece que la cantidad de producto depende también de "cómo se hacen las cosas", puesto que con el mismo esfuerzo y tiempo, y dependiendo del entorno de trabajo, podremos conseguir mayor o menor cantidad de producto.[Referencia]: http://translate.google.com/translate?hl=es&langpair=en|es&u=http://www.ecfc.u-net.com/cost/slim.htm

Modelos COCOMO y COCOMO II

Modelos de Estimación de Costes
Modelos COCOMO y COCOMO II
Constructivo modelo de costes II (COCOMO II) es un modelo que permite estimar el costo, el esfuerzo, y el calendario en la planificación de una actividad de desarrollo de software. COCOMO II es la última importante ampliación de la original COCOMO (COCOMO 81) modelo publicado en 1981. Se compone de tres submodelos, cada uno con una mayor fidelidad a lo largo de la mayor se está en la planificación del proyecto y el proceso de diseño. En la fidelidad cada vez mayor, estos submodelos se llaman Composición Aplicaciones, Diseño Temprano, y los modelos posteriores a la arquitectura.
COCOMO II puede ser utilizado para las situaciones siguientes decisión importante.
• Hacer de inversión u otras decisiones financieras relacionadas con un esfuerzo de desarrollo de software.
• Ajuste de presupuestos de los proyectos y programas como base para la planificación y el control.
• Decisiones sobre las compensaciones o de la negociación entre los costos de software, programación, funcionalidad, rendimiento o la calidad de los factores.
• Haciendo coste de Software y calendario de las decisiones de gestión de riesgos.
• La decisión sobre qué partes de un sistema software se tiene que desarrollar, la reutilizar, el arrendamiento o la compra.
• Hacer legado sobre decisiones de inventario de software: ¿qué partes de modificar, eliminar, subcontratar, etc.
• Establecer estrategias mixtas de inversión para mejorar la capacidad de organización de software, a través de la reutilización, herramientas, proceso de maduración, subcontratación, etc.
• Decidir cómo implementar una estrategia de mejora de procesos, como la prevista en el SEI CMM.
El modelo COCOMO original fue publicado por primera vez por el Dr. Barry Boehm en 1981, y refleja las prácticas de desarrollo de software de la jornada. En la siguiente década y media, las técnicas de desarrollo de software cambiado drásticamente. Estos cambios incluyeron un alejamiento de la unidad central de procesamiento por lotes durante la noche en tiempo real a cambio de escritorio basado en; un énfasis mucho mayor en la reutilización de software existente y la creación de nuevos sistemas utilizando off-the-shelf componentes de software, y el gasto tanto esfuerzo para diseñar y gestionar el proceso de desarrollo de software como se gastó una vez la creación del producto de software.
Estos cambios y otros comenzaron a hacer la aplicación del modelo COCOMO problemática original. La solución al problema fue que reinventar el modelo de la década de 1990. Después de varios años y los esfuerzos combinados de la USC-CSSE, ISR en UC Irvine, y el COCOMO II Proyecto Organizaciones afiliadas, el resultado es COCOMO II, un modelo de cálculo de costes revisado que refleje los cambios en la práctica profesional de desarrollo de software que se han producido desde la década de 1970. Esta COCOMO nueva y mejorada ya está listo para ayudar a los profesionales estimadores de costos de software desde hace muchos años por venir.
Acerca de la nomenclatura

El modelo original fue publicado en 1981 por el simple nombre de COCOMO. Este es un acrónimo derivado de las dos primeras letras de cada palabra en la frase más constructiva modelo de costes. La palabra constructiva se refiere al hecho de que el modelo ayuda a un estimador a comprender mejor las complejidades del trabajo de software por hacer, y por su carácter abierto permite el estimador de saber exactamente por qué el modelo proporciona la estimación que hace.
No es sorprendente que el nuevo modelo (compuesto por los tres submodelos) fue inicialmente recibió el nombre de COCOMO 2.0. Sin embargo, después de cierta confusión en la forma de designar a las versiones posteriores del software de aplicación del nuevo modelo, el nombre fue cambiado definitivamente a COCOMO II. Para evitar más confusión, el modelo COCOMO original fue también entonces volver a designarlo COCOMO 81. Todas las referencias a COCOMO encuentra en los libros y la literatura publicada antes de 1995 se refieren a lo que ahora se llama COCOMO 81. La mayoría de las referencias a COCOMO publicados a partir de 1995 se refieren a lo que ahora se llama COCOMO II.
Si en el examen de una referencia que todavía no está seguro de qué modelo se está discutiendo, hay pocas pistas obvias. Si en el contexto del debate sobre COCOMO estos términos se utilizan: Básico, Intermedio, o disposiciones de nombres de los modelos; Orgánica, adosada, o Embedded para el modo de desarrollo, entonces el modelo que nos ocupa es COCOMO 81. Sin embargo, si los nombres mencionados son el modelo de aplicaciones de composición, diseño inicial, o la arquitectura post-, o si se habla de Precedentedness factores de escala (PREC), Desarrollo de Flexibilidad (FLEX), Arquitectura / Riesgo Resolución (Resl), el Equipo de Cohesión (TEAM ), o Proceso de Madurez (PMAT), entonces el modelo que nos ocupa es COCOMO II.
3.- Estimación con uso de Modelos COCOMO
Pueden aplicarse a los tres modos de desarrollo de proyectos y son:
3.1. Modelo Básico
Se suele aplicar en los desarrollos de productos pequeños/medios, desarrollados por personal de la propia empresa en modo orgánico. Aunque también puede aplicarse al resto de los modos.
Las ecuaciones de estimación de esfuerzo y tiempo de desarrollo para cada modo de desarrollo:

Orgánico: MM = 2,4 (KDSI)1,05

TDEV = 2,5 (MM) 0,38

Semilibre: MM = 3,0 (KDSI) 1,12


TDEV = 2,5 (MM) 0,35

Rígido: MM = 3,6 (KDSI) 1,20

TDEV = 2,5 (MM)0,32
Donde,

KDSI significa número de instrucciones de código en miles.
MM significa esfuerzo medido en Meses/Hombre.
TDEV significa duración en Meses.[Referecncia]:http://translate.google.com/translate?hl=es&langpair=en|es&u=http://www.softstarsystems.com/cocomo2.htm

Heuristica

De acuerdo con Schuster (1974): El enfoque heurístico para la resolución de problemas consiste en aplicar la inteligencia humana, la experiencia, sentido común y ciertas reglas del pulgar (o heurística) para desarrollar un aceptable, pero no necesariamente una solución óptima, a un problema. Por supuesto, determinar lo que constituye una solución aceptable es parte de la tarea de decidir qué método utilizar, pero en sentido amplio, una solución aceptable es aquella que es a la vez razonablemente buena (cerca del óptimo) y derivados dentro de los esfuerzos razonables, tiempo y costo restricciones. A menudo el esfuerzo (mano de obra, equipo y otros recursos) necesarios, los plazos en la solución cuando se necesita, y el costo de recopilar, procesar y analizar todos los datos necesarios para los procedimientos complicados determinista o se oponen a su utilidad o favorecen la más rápido, más simple enfoque heurístico. Así, el enfoque heurístico se utiliza generalmente cuando las técnicas deterministas o no están disponibles, económico o práctico.

Heurística de enrutamiento es un sistema usado para describir cómo los datos se entregan cuando los problemas en una topología de la red surgen. Heurística de enrutamiento se realiza con algoritmos específicos para determinar el mejor, aunque no siempre óptima, ruta a un destino. Cuando una interrupción en una topología de la red se produce, el software se ejecuta en la electrónica de red calcula otra ruta hacia el destino deseado a través de una ruta alterna, disponible.[Referencia]
http://translate.google.com/translate?hl=es&langpair=en|es&u=http://en.wikipedia.org/wiki/Heuristic

Puntos de Función

Medición de las Especificaciones

Puntos de Función Albrecht: Los Puntos de Función miden la aplicación desde una perspectiva del usuario, dejando de lado los detalles de codificación. Es una técnica totalmente independiente de todas las consideraciones de lenguaje y ha sido aplicada en más de 250 lenguajes diferentes. Se supone que FPA evalúa con fiabilidad

- El valor comercial de un sistema para el usuario

- tamaño del proyecto, coste y tiempo de desarrollo

- calidad y productividad del programador MIS

- esfuerzo de adaptación, modificación y mantenimiento

- posibilidad de desarrollo propio

- beneficios de implementación en 4GL.

fpa_archivos\fpapic1.jpg

Figura 1. Relaciones entre Usuarios, Aplicaciones y Funciones

Un Punto de Función se define como una función comercial de usuario final. De esta manera un programa que tenga

“x” PF’s entrega “x” funciones al usuario final. El mejor modo de trabajo es la interacción analista-usuario.

El proceso requiere dos etapas fundamentales:

1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos (mejor en este orden)

- Salidas

- Consultas

- Entradas

- Ficheros

- Interfaces.

Después se clasifica y pondera cada función por su nivel de complejidad (simple, media, compleja).

2. Se ajusta este total de acuerdo con unas características del entorno. Ver la figura 1.

I. Salidas .

Se debe contar cada dato único de usuario o salida de control generado proceduralmente y que sale del límite de la aplicación. Esto incluye informes y mensajes a otras aplicaciones y usuarios.

Una salida se considera única si

1. tiene formato diferente

2. tiene el mismo formato que otra salida pero requiere diferente lógica de procesamiento.

Además de las pantallas y los listados (papel o pantalla), también pueden ser salidas:

• fichero de transacción enviado a otra aplicación

• facturas

• cheques

• fichas perforadas

• transacciones automáticas

• mensajes al usuario

• cintas

• gráficos

• ficheros back-up, etc.

No se deben contar como salidas:

• cabeceras de columna, títulos, número de página

• mensajes individuales (información, confirmación o respuestas a consultas de error)

• salida en igual formato y lógica que ya se hay contado para otro soporte.

Salidas

1-5 items de datos

referenciados

6-19 items de

datos referenciados

20 o más items de

datos referenciados

0 o 1 fichero

referenciado

Simple (4)

Simple (4)

Medio (5)

2 o 3 ficheros

referenciados

Simple (4)

Medio (5)

Complejo (7)

4 o más ficheros

referenciados

Medio (5)

Complejo (7)

Complejo (7)

II. ENTRADAS.

Se debe contar cada dato único de usuario o entrada de control que se introduce en los límites de la aplicación y actualiza un fichero lógico interno, conjunto de datos, tabla o dato independiente. Esto incluye ficheros de entrada y transacciones recibidas de otras aplicaciones.

Una entrada se considera única si

1. tiene un formato diferente

2. tiene el mismo formato que otra entrada pero requiere una lógica diferente de procesamiento, o se modifica un fichero interno lógico diferente.

Supongamos que tenemos dos pantallas de entrada, cada una con el mismo formato pero con diferente lógica de procesamiento. Se cuenta cada pantalla como una entrada diferente; pero si tuvieran la misma lógica sólo se contaría una. Lo mismo sucede con la repetición de pantallas.

Supongamos que tenemos un pantalla cuya función es actualizar un fichero o un conjunto de datos. Puesto que cada una de las tres funciones de actualización (añadir, cambiar, borrar) requiere diferente lógica de procesamiento tendremos tres entradas, no una. Cada fichero tendrá tres entradas, así como una salida (el fichero formateado de salida) y una consulta.

Tipos de entradas pueden ser:

• el ratón

• documentos MICR

• transacciones de cintas

• pantallas sensitivas

• lectores de código de barras, etc.

Entradas

1-4 items de datos

referenciados

5-15 items de

datos referenciados

16 o más items de

datos referenciados

0 o 1 fichero

referenciado

Simple (3)

Simple (3)

Medio (4)

2 ficheros

referenciados

Simple (3)

Medio (4)

Complejo (6)

3 o más ficheros

referenciados

Medio (4)

Complejo (6)

Complejo (6)

III. Consultas

Se debe contar cada combinación única de entrada/salida en la que la entrada on-line definida por el usuario genera una salida inmediata on-line. Las consultas se pueden proporcionar a/desde otra aplicación; por ejemplo, responder a otra aplicación que pregunta por el precio de un producto se contaría como una consulta. Una consulta se considera única si

1. tiene un formato diferente de otras bien en su entrada o salida

2. tiene el mismo formato, tanto entrada como salida, que otra consulta pero requiere diferente lógica de procesamiento en cualquiera de los dos.

Una consulta directa en una base de datos o fichero maestro es aquella que

1. utiliza claves simples para recuperar datos específicos -esto es, un registro simple o grupo de registros, no un rango-

2. requiere respuesta inmediata, y

3. no realiza funciones de actualización (aunque se pueden efectuar cálculos).

Las consultas pueden aparecer en

• consulta de usuario/display sin actualización de fichero u otra entidad lógica

• fichero de transacción que sale del límite de la aplicación si está accesible al usuario on-line

• pantalla de selección de menú (todas las pantallas de menú cuentan como una consulta)

• mensaje de información o pantalla de ayuda.

Consultas

Parte Salida

1-5 items de datos

referenciados

6-19 items de

datos referenciados

20 o más items de

datos referenciados

0 o 1 fichero

referenciado

Simple (4)

Simple (4)

Medio (5)

2 o 3 ficheros

referenciados

Simple (4)

Medio (5)

Complejo (7)

4 o más ficheros

referenciados

Medio (5)

Complejo (7)

Complejo (7)

Parte Entrada

1-4 items de datos

referenciados

5-15 items de

datos referenciados

16 o más items de

datos referenciados

0 o 1 fichero

referenciado

Simple (3)

Simple (3)

Medio (4)

2 ficheros

referenciados

Simple (3)

Medio (4)

Complejo (6)

3 o más ficheros

referenciados

Medio (4)

Complejo (6)

Complejo (6)

IV. Ficheros

Se debe contar cada grupo lógico mayor de datos de usuario o de información de control mantenidos dentro de los límites de la aplicación. FPA distingue entre dos tipos de ficheros: ficheros con transacciones temporales y ficheros con registros lógicos de datos permanentes. Sólo los almacenamientos de datos permanentes se ven como ficheros lógicos. Cuando se mantienen dentro de la aplicación se clasifican como "ficheros internos lógicos". Si se comparten entre aplicaciones se clasifican como interfaces y cómo ficheros internos lógicos.

Las transacciones, por el contrario, se considera que son sucesos que desencadenan cambios en los ficheros lógicos internos; no se clasifican como ficheros. Un fichero transacción se puede clasificar como entrada si es leído para actualizar datos en un fichero lógico interno. Un fichero transacción puede ser un interface o una salida si trasfiere transacciones de actualización a otra aplicación.

Cuando se utiliza análisis estructurado cada almacenamiento de datos contendrá al menos un fichero lógico interno. Hay que enfatizar que hablamos de ficheros lógicos. Supongamos que un fichero físico contiene dos claves diferentes, entonces contaríamos dos ficheros lógicos internos, puesto que cada camino presenta diferente información. Del mismo modo, cada vista lógica del usuario en una base de datos se cuenta como un fichero.

Se pueden encontrar ficheros en :

• bases de datos: 1 por vista lógica o camino de acceso

• ficheros maestros: 1 por cada grupo de claves

• tablas mantenidas por los usuarios: estados, tarifas, mensajes, etc.

• fichero de procesamiento batch

• índices de referencias cruzadas

Ficheros

1-19 items de datos

referenciados

20-50 items de

datos referenciados

51 o más items de

datos referenciados

1 formato/relación de

registro lógico

Simple (7)

Simple (7)

Medio (10)

2-5 formatos/relaciones de registro lógico

Simple (7)

Medio (10)

Complejo (15)

6 o más formatos/

relaciones de registro lógico

Medio (10)

Complejo (15)

Complejo (15)

V. Interfaces.

Se debe contar como uno cada fichero lógico de otro grupo de datos ( o información de control) que se envía fuera de los límites de la aplicación, o se comparte o es recibido desde otra aplicación. Los ficheros que se comparten entre aplicaciones se cuentan como ficheros y como interfaces en cada aplicación en la que se utilizan; de otro modo sólo se puntuará como fichero en aquella aplicación que utilice o mantenga el fichero (la otra sólo recibirá puntos de interface). Esto es, cada fichero interface debe ser también un fichero interno lógico en esa aplicación, en otra o en ambas; o puede ser un fichero transacción o de impresión generado en la propia aplicación. Los interfaces presentan una de estas situaciones:

1. Datos o información de control se pasa del fichero A al fichero B. En A se puntúa fichero e interface y en B sólo interface

2. Datos o información de control se pasa del fichero B a A. En B se puntúa fichero e interface y en A sólo interface

3. Datos o información de control se comparte entre A y B. A y B reciben puntos de fichero e interface.

Ver tabla adjunta.

Utilización del fichero:

en esta aplicación A contar

en las otras aplicaciones B

recibido de B

sólo interface (sin actualizaciones)

ambos fichero e interface

compartido con B

ambos fichero e interface

ambos fichero ( si se mantiene) e interface

enviado a B

ambos fichero e interface

sólo interface (sin actualizaciones)

Los interfaces habitualmente involucran ficheros maestros, no transacciones. Hay diferencia entre ficheros maestros lógicos y ficheros transacción. Si las aplicaciones se relacionan a través de transacciones entonces se puntuarán entrada, salida, y/o consulta, y, quizá, interface. Si lo hacen a través de ficheros maestros entonces se puntuará interface y, quizá, fichero. Un fichero transacción no se contará como interface si el formato con el que lo recibe el otro programa es el mismo (no hay conexión). El programa receptor lo contaría como entrada. Si el programa que lo envía realiza el trabajo de conversión entonces se contará (para éste) una salida y un interface.

Los interfaces se pueden encontrar en:

• ficheros lógicos internos accesibles desde otra aplicación

• ficheros lógicos internos accedidos en otra aplicación

• base de datos compartida

• lista de parámetros compartida

• fichero de impresión exportado

• fichero transacción compartido que requiere conversión.

Se contarán como un interface

• fichero de registros de otra aplicación (en la otra aplicación (+1 fichero,

+1 interface).

Ficheros Transacción

en esta aplicación A

en otras aplicaciones B

Situación:

contar:

contar:

NO SE REQUIERE CONVERSIÓN DE DATOS

1. Recibido de B

entrada (lo normal) o

salida

2. enviado a B

salida o

entrada (lo normal)

SE PRECISA CONVERSIÓN

DE DATOS

1. Recibido de B, A convierte

ambos fichero e interface

------------------------------

2. Recibido de B, B convierte

------------------------------

ambos fichero e interface

3. Enviado a B, A convierte

ambos fichero e interface

------------------------------

4. Enviado a B, B convierte

------------------------------

ambos fichero e interface

• fichero de registros a otra aplicación (+1 fichero) (otra aplicación +1 interface)

• fichero de registros a varias aplicaciones (+1 fichero) - afecta al peso de complejidad también-

• fichero de registros compartido entre dos o más aplicaciones (+1 fichero) (para las otras aplicaciones: +1 interface, +1 fichero en cada aplicación si realizan mantenimiento)

• base de datos compartida con otras aplicaciones (+1 fichero) 1 interface por cada vista realmente enviada (para la otra aplicación: +1 fichero, +1 interface por cada vista utilizada)

• base de datos compartida de otras aplicaciones (+1 fichero) 1 interface por cada vista utilizada (para la otra aplicación: +1 fichero, +1 interface por vista)

• fichero transacción de otra aplicación con conversión de datos (+1 entrada)

• fichero transacción enviado a otra aplicación con conversión de datos (+1 salida). Los ficheros transacción sólo se cuentan en una aplicación (no en las dos)

• lista de parámetros.

Interfaces

1-19 items de datos

referenciados

20-50 items de

datos referenciados

51 o más items de

datos referenciados

1 formato/relación de

registro lógico

Simple (5)

Simple (5)

Medio (7)

2-5 formatos/relaciones de registro lógico

Simple (5)

Medio (7)

Complejo (10)

6 o más formatos/

relaciones de registro lógico

Medio (7)

Complejo (10)

Complejo (10)

VI. Características generales FPA de la aplicación.

Según este método, la cuenta de puntos de función no ajustada debe calibrarse con otros 14 elementos que dependen del entorno. Estos son:

1. Comunicaciones de datos

2. Datos o procesamiento distribuídos

3. Objetivos de rendimiento

4. Configuración utilizada masivamente

5. Tasa de transacción

6. Entrada de datos on-line

7. Eficiencia para el usuario

8. Actualización on-line

9. Procesamiento complejo

10. Reutilización

11. Facilidad de instalación y conversión

12. Facilidad de operación

13. Puestos múltiples

14. Facilidad de cambio.

Estos factores se puntúan de 0 a 5; también se pueden asociar porcentajes, como se muestra en las figuras.

Valor del Factor

Influencia en el Sistema

Porcentaje que afecta o es requerido por la aplicación

0

Ninguna

0%

1

Insignificante

1-20%

2

Moderada

21-40%

3

Media

41-60%

4

Significativa

61-80%

5

Fuerte

81-100%

Escala de influencia (excepto para el factor 10)

Valor del Factor

Porcentaje que afecta o es requerido por la aplicación

0

0-10%

1

11-20%

2

21-30%

3

31-40%

4

41-50%

5

>50%

Escala de influencia para el factor 10

1. Comunicación de Datos: los datos o información de control que la aplicación utiliza se envía o recibe a través de las facilidades de comunicación.

0 Aplicación es batch exclusivamente

1-2 Impresión o entrada de datos remota

3-5 Teleproceso (TP) interactivo

3 TP interface a un proceso batch

5 La aplicación es interactiva predominantemente

2. Función Distribuída. "Distribuída" significa que los componentes (o los datos) de la aplicación están distribuídos en dos o más procesadores diferentes (esto también incrementa el factor anterior).

0 La aplicación no ayuda a la trasferencia de datos o a la función de procesamiento entre los componentes del sistema

1 La aplicación prepara datos para el usuario final de otro procesador

2-4 Los datos se preparan para trasferencia, se trasfieren y se procesan en otro componente del sistema

5 Las funciones de procesamiento se realizan dinámicamente en el componente más apropiado del sistema.

3. Rendimiento: referido a la importancia de respuesta dentro de todo el sistema

0-3 Análisis y diseño de las consideraciones del rendimiento son estándar. No se precisan requerimientos especiales por parte del usuario

4 En la fase de diseño se incluyen tareas del análisis del rendimiento para cumplir los requerimientos del usuario

5 Además se utilizan herramientas de análisis del rendimiento en el diseño, desarrollo e instalación

4. Configuración utilizada masivamente: referente a la importancia del entorno. Esto es, si hay restricciones de memoria o del hardware.

0-3 La aplicación corre en una máquina estándar sin restricciones de operación

4 Restricciones de operación requieren características específicas de la aplicación en el procesador central

5 Además hay restricciones específicas a la aplicación en los componentes distribuídos del sistema.

5. Tasas de Transacción: una alta llegada de transacciones provoca problemas más allá de los de la característica 3

0-3 Las tasas son tales que las consideraciones de análisis de rendimiento son estándares

4 En la fase de diseño se incluyen tareas de análisis de rendimiento para verificar las altas tasas de transacciones

5 Además se utilizan herramientas de análisis del rendimiento.

6. Entrada On-Line de datos

0-2 Hasta el 15% de las transacciones tienen entrada interactiva

3-4 15% al 30% tienen entrada interactiva

5 30% al 50% tienen entrada interactiva.

7. Diseño para la eficiencia de usuario final

0-3 No se especifican requerimientos especiales

4 Se incluyen tareas de diseño para la consideración de factores humanos

5 Además se utilizan herramientas especiales o de prototipado para promover la eficiencia.

8. Actualización On-Line

0 Nada

1-2 Actualización on line de los ficheros de control. El volumen de actualización es bajo y la recuperación fácil.

3 Actualización on line de la mayoría de los ficheros internos lógicos

4 Además es esencial la protección contra la pérdida de datos

5 Además se considera el coste de recuperación de volúmenes elevados.

9. Complejidad del procesamiento: esto es, complejidad interna más allá de la media en lo referente a la entrada, salida o lógica de procesamiento

¿Qué características tiene la aplicación?

• mucho procesamiento matemático y/o lógico

• procesamiento complejo de las entradas

• procesamiento complejo de las salidas

• muchas excepciones de procesamiento, muchas transacciones incompletas y mucho reprocesamiento de las transacciones

• procesamiento de seguridad y/o control sensitivo

0 No se aplica nada de esto

1 Se aplica alguna cosa

2 Se aplican dos cosas

3 Se aplican tres cosas

4 Se aplican cuatro cosas

5 Se aplica todo.

10. Utilizable en otras aplicaciones: el código se diseña para que sea compartido o utilizable por otras aplicaciones (no confundir con 13).

0-1 Una aplicación local que responde a las necesidades de una organización usuaria

2-3 La aplicación utiliza o produce módulos comunes que consideran más necesidades que las del usuario

4-5 Además, la aplicación se "empaquetó" y documentó con el propósito de fácil reutilización

11. Facilidad de Instalación

0-1 No se requieren por parte del usuario facilidades especiales de conversión e instalación

2-3 Los requerimientos de conversión e instalación fueron descritos por el usuario y se proporcionaron guías de conversión e instalación

4-5 Además se proporcionaron y probaron herramientas de conversión e instalación

12. Facilidad de Operación

0 No se especifican por parte del usuario consideraciones específicas de operación

1-2 Se requieren, proporcionan y prueban procesos específicos de arranque, backup y recuperación

3-4 Además la aplicación minimiza la necesidad de actividades manuales, tales como instalación de cintas y papel

5 La aplicación se diseña para operación sin atención

13. Puestos Múltiples.

0 El usuario no requiere la consideración de más de un puesto

1-3 Se incluyeron necesidades de varios puestos en el diseño

4-5 Se proporciona documentación y plan de apoyo para soportar la aplicación en varios lugares

14. Facilidad de Cambio: esfuerzo específico de diseño para facilitar cambios futuros.

0 No hay requerimientos especiales del usuario para minimizar o facilitar el cambio

1-3 Se proporciona capacidad de consulta flexible

4-5 Datos importantes de control se mantienen en tablas que son actualizadas por el usuario a través de procesos on-line interactivos.

Así, para calcular el total de puntos de función utilizaremos la fórmula

PF's no ajustados * (0'65 + 0.01 (influencia 14 factores)).

Método de Análisis Puntos de Función MkII

Los puntos de función MkII se obtienen de manera similar al método de Albrecht, esto es, son el producto de dos componentes, el "tamaño de procesamiento de la información" y el "ajuste de complejidad técnica".

Componentes del método Mark II

Tamaño del Procesamiento de la Información.

En vez de utilizar cinco componentes: entradas, salidas, interfaces, consultas y ficheros lógicos, el sistema se examina desde el punto de vista de las transacciones lógicas, consistiendo cada una de ellas en entrada, proceso y salida. Se define una transacción lógica como una combinación única de entrada/proceso/salida desencadenada por un único evento de interés para el usuario, o una necesidad de recuperar información. Ejemplos de ello son

• crear un nuevo cliente

• actualizar una cuenta

• generar un informe mensual.

La cuenta de PF's no ajustada para una transacción lógica se basa en la hipótesis

donde los pesos Wi se obtienen por calibrado.

Ajuste de Complejidad Técnica MkII.

Se modifica el ajuste Albrecht en dos sentidos

• ampliar la lista de características generales. Se incluyen cinco características específicas más y se permite introducir otras.

• se permite determinar el peso del total de los grados de influencia por calibrado de la instalación.

Así

TCA = 0.65 + C · (grado de influencia total).

C se obtiene por calibrado.

Calibrado de los Pesos MkII.

Los pesos se calibran analizando la proporción de horas trabajadas como se muestra a continuación

Horas totales del proyecto

• X horas para el "Tamaño del Procesamiento de la Información"

Divididas en

- Entrada

- Proceso

- Salida

Utilizado para determinar WI, WO, WE

• Y horas para los "Factores de Complejidad Técnica"

Divididas en cada uno de los 19 factores (para valorarlos).

Si lo que se proporciona es la relación Y/X entonces

TCA(real) = 0.65 · (1 + Y/X)

Reglas Prácticas para Aplicar MkII FPA en la Medición del Tamaño del Sistema

I. Entidades

Una entidad es cualquier cosa del mundo real (objeto, transacción, periodo de tiempo, etc. tangible o intangible, y grupos de clases) acerca de la que queremos saber información. Por ejemplo, en un sistema de personal "empleado" es una entidad. "Fecha de Nacimiento", sin embargo, no lo es. La fecha de nacimiento es algo que queremos conocer de la entidad "empleado" (fecha de nacimiento es un atributo de la entidad empleado).

Ejemplos de entidades primarias que pueden ser introducidas y/o almacenadas en una aplicación comercial son: tipo de producto, almacén, cliente, orden, factura, pago, proveedor, orden de compra, empleado, departamento, cuenta, volumen de ventas, volumen de compra, volumen de producción, etc.

Una entidad puede ser una cosa cuyas ocurrencias son identificables individualmente, por ejemplo "empleado", o una cosa colectiva tal como "todos los empleados de la empresa". Los atributos de esta entidad serían el número total de empleados, media de años de servicio, etc.

En el caso de tener que resolver relaciones 'varias a varias' (por ejemplo, en el modelo entidad-relación) las entidades 'intersección' se tratarán como si fueran una entidad más.

Para el modelo relacional, una entidad sería 'el sujeto de una relación en tercera forma normal'. Así una entidad se puede definir como el sujeto de un fichero normalizado.

Entidades introducidas y/o almacenadas en el sistema.

En un sistema de personal, "empleado" sería una entidad para la que los datos se introducen y almacenan. Entonces habría que contarla. Por el contrario, un ejemplo de una entidad para la que sólo se crearía información con propósitos de salida sería la entidad colectiva "todos los empleados de la empresa". Si ocurre que esta entidad colectiva sólo aparece en la salida, entonces no necesitamos contarla en el tamaño del componente de procesamiento de la transacción, porque se contabilizará en el tamaño del componente de salida.

Entidades Primarias versus tablas maestras y ficheros de parámetros.

Entidades primarias son las entidades para las que el sistema se ha construído con la intención de recolectar y almacenar datos. Pero nos pueden aparecer ficheros que contienen datos fijos acerca de multitud de circunstancias, que se utilizan con el propósito de referencia, validación, adaptación del sistema, etc.

Habitualmente contienen códigos de países, unidades de medida, departamentos, rangos en determinados números de serie, tablas de autorización, mensajes del operador, mensajes de error, etc.

Aunque representan "cosas" del mundo real, nos referiremos a ellas como entidades no primarias. Todas estas entidades no primarias se engloban en una única denominada Entidad del Sistema.

Para cualquier transacción que hace al menos una referencia a estos ficheros de parámetros, la regla es contar una referencia a la Entidad del Sistema en la cuenta de entidades referenciadas en esa transacción.

Entidades y Subentidades.

Todas las subentidades deben contarse como entidades primarias separadas dentro de una transacción sólo si la transacción procesa cada tipo de subentidad con una lógica de procesamiento diferente, o si las subentidades tienen diferentes atributos.

Cuenta de Entidades

Hay que contar el número de entidades primarias a las que se hace referencia en una transacción (no el número de referencias a entidades en una transacción). Por ejemplo, si una entidad es referenciada dos veces en una transacción (una para leer y otra para modificarla), se cuenta solamente una referencia a esa entidad en esa transacción.

Relaciones circulares en una entidad.

Si una entidad se relaciona con ella misma, habrá que contarla dos veces.

II. Transacciones Lógicas.

Definición.

Una transacción lógica es una combinación de uno o más tipos de entrada, algún procesamiento, y uno o más tipos de salida correspondientes a un proceso lógicamente único. Una transacción se desencadena por un evento en el mundo real que tiene significado para el usuario, o es el resultado de una consulta o extracción de información que no modifica los datos almacenados.

Ejemplos de transacciones:

• extracción de un registro (o selección de registros de acuerdo a los parámetros de entrada) de un fichero maestro, y mostrarlo o imprimirlo

• añadir un nuevo cliente a un fichero maestro de clientes

• procesar la cabecera de un pedido (antes de introducir una o más líneas)

• procesar un pedido (la salida puede ser una nota de envío, confirmación, etc.)

• calcular la nómina mensual (las entradas pueden ser las horas extras, etc.; las salidas pueden ser la carta de la nómina, instrucciones de pago al banco, informe de pagos de nómina, etc.)

• calcular el plan mensual de requerimientos de materiales.

De estos ejemplos se deduce que estamos definiendo las transacciones al nivel más bajo de los procesos de la empresa, que se separan por la necesidad de interacción con el mundo real.

Los procesos internos que suceden repetidas veces deben contarse en la transacción en la que aparecen. No deben contarse como transacciones diferentes a menos que se desencadenen por un suceso de significado para el usuario.

Cambios en el valor de un dato de entrada no pueden desencadenar diferentes transacciones lógicas.

Un ejemplo para diferenciar las transacciones lógicas lo encontramos en un sistema simple para gestionar las reservas de un hotel. La figura 20 muestra el diagrama entidad-relación, y una secuencia de pantallas para solicitar una habitación se muestra en la figura 21.

Tenemos, paradójicamente, dos transacciones lógicas:

1. Una transacción consultando precio y disponibilidad de habitación, involucrando

2 entradas: fecha de llegada y de salida

2 entidades referenciadas: tipo de habitación, tiempo de disponibilidad

4 salidas: fechas, tipo de habitación y precio

(en este momento el diálogo podría interrumpirse, bien por falta de habitaciones o porque el cliente no desea esas habitaciones).

2. Una transacción lógica para reservar una habitación, involucrando

9 entradas: fechas, selección de habitación simple y pantalla 02

3 entidades referenciadas: habitación, cliente y tiempo de disponibilidad

3 salidas: información de confirmación.

Si el cliente desea modificar la reserva, las transacciones lógicas serían

- búsqueda de la reserva

- cancelación

- solicitud de nueva habitación

Cancelar una reserva será siempre una transacción lógica sea cual sea la situación. Solicitar una nueva habitación es la misma que la que acabamos de ver.

III. Determinación de las Transacciones Lógicas en una Especificación Funcional

Dado que el enfoque funcional y el enfoque orientado a los datos pueden dar lugar a diferentes transacciones lógicas, aunque teóricamente debieran dar lugar a las mismas, es la tarea del analista decidir qué es lo que se trata como transacción lógica, teniendo en cuenta qué es lo que genera procesamientos diferentes desde el punto de vista de los requerimientos de usuario.

IV. Determinación de las Transacciones lógicas de un Sistema Instalado

Ver referencia [Symmons, 1991]

V. Cuenta de los Elementos de Datos.

• Contar tipos de elementos de datos, no ocurrencias de elementos de datos.

• No contar los elementos de datos de las cabeceras y pies de pantallas o informes que no se generan específicamente para esa pantalla.

• No contar etiquetas, cajas, subrayados, etc.

• Considerar todos los mensajes de error como posibles ocurrencias del tipo de datos "mensaje de error". Del mismo modo todos los mensajes del operador se deben considerar como valores del tipo de elemento de datos "mensajes del operador".

• Contar las fechas (día/mes/año) como un sólo elemento de datos (aunque se pueden dar excepciones).

• Para las tablas se aplica esta última regla, contando tipos de elementos de datos, no ocurrencias, tanto para las filas como para las columnas. Por ejemplo, si las columnas de una página muestran las ventas desde enero a diciembre y la última columna muestra el total anual, y si el procesamiento para cada mes es el mismo, entonces hay que contar dos tipos de columna, una para el mes y otra para el año.

Para las filas pueden ocurrir dos circunstancias

- si cada fila se calcula mediante el mismo proceso, esto es, si en el informe mencionado cada fila corresponde a un vendedor, entonces hay que contar un sólo tipo de fila

- cuando las filas se calculan con procesos diferentes (por ejemplo, ventas previstas, ventas reales, ventas facturadas), hay que contar el número de tipos de filas, que en este caso son tres.

Finalmente, número de tipos de elementos de datos = (número de tipos de columnas) · (número de tipos de filas).

• si el sistema proporciona valores por defecto para los elementos de datos de entrada, y los muestra al usuario, quizá para reescribirlos, se contarán como elementos de datos normales.

• cuando un elemento de datos de entrada se vuelve a mostrar como salida, hay que contarlo como entrada y como salida. Sin embargo si, después de una validación, un campo de entrada se señala como incorrecto, no hay que contarlo dos veces. Esta situación es análoga a la generación de un mensaje de error: la transacción todavía está en la fase de entrada.

• elementos de control de datos, como por ejemplo campos para la selección de opciones de menús, no deben, en general, contarse. Asimismo, tampoco hay que contar el uso de las teclas de función. Sin embargo, debe tenerse en cuenta que cada transacción lógica debe tener, al menos, un elemento de datos de entrada.

VI. Ajuste de la Complejidad Técnica

Las secciones anteriores han definido las reglas para contar lo que Albrecht denominó 'Puntos de Función No-Ajustados'. Albrecht propuso multiplicar este valor por un factor que refleje el grado de influencia de otros 14 factores de naturaleza técnica. Cada característica puede tener un grado de influencia de 0 a 5, y la suma de todas las características se utiliza para calcular este factor, que puede variar de 0.65 a 1.35.

MkII FPA sigue exactamente el mismo enfoque, excepto que

• se incluyen cinco características técnicas más, y se pueden incluir otras justificándolas

• el peso de cada influencia se obtiene por un proceso de calibración, en vez de utilizar constantes

• el factor se denomina 'Ajuste de la Complejidad Técnica', más que 'Factor de Ajuste del Valor'.

Las reglas de puntuación general de la influencia de cada característica son:

• ausente, o ninguna influencia si presente = 0

• influencia insignificante = 1

• influencia moderada = 2

• influencia media = 3

• influencia significativa = 4

• influencia fuerte = 5

Estas reglas generales se sustituyen por las reglas específicas como se indica a continuación.

1. Comunicación de Datos

0 Aplicación es batch exclusivamente

1-2 Impresión o entrada de datos remota

3-5 Teleproceso (TP) interactivo

3 TP interface a un proceso batch

5 La aplicación se interactiva

2. Función Distribuída. "Distribuída" significa que los componentes de la aplicación están distribuídos en dos o más procesadores diferentes.

0 La aplicación no ayuda a la trasferencia de datos o a la función de procesamiento entre los componentes del sistema

1 La aplicación prepara datos para el usuario final de otro procesador

2-3 Los datos se preparan para trasferencia, se trasfieren y se procesan en otro componente del sistema

4 Igual que 2-3, pero con realimentación al sistema inicial

5 Las funciones de procesamiento se realizan dinámicamente en el componente más apropiado del sistema.

3. Rendimiento (referido a la importancia de respuesta dentro de todo el sistema)

0-3 Análisis y diseño de las consideraciones del rendimiento son estándar. No se requieren requerimientos especiales por parte del usuario

4 En la fase de diseño se incluyen tareas del análisis del rendimiento para cumplir los requerimientos del usuario

5 Además se utilizan herramientas de análisis del rendimiento en el diseño, desarrollo e instalación

4. Configuración utilizada masivamente (referente a la importancia del entorno)

0-3 La aplicación corre en una máquina estándar sin restricciones de operación

4 Restricciones de operación requieren características específicas de la aplicación en el procesador central

5 Además hay restricciones específicas a la aplicación en los componentes distribuídos del sistema.

5. Tasas de Transacción (una alta llegada de transacciones provoca problemas más allá de los de la característica 3)

0-3 Las tasas son tales que las consideraciones de análisis de rendimiento son estándares

4 En la fase de diseño se incluyen tareas de análisis de rendimiento para verificar las altas tasas de transacciones

5 Además se utilizan herramientas de análisis del rendimiento.

6. Entrada On-Line de datos

0-2 Hasta el 15% de las transacciones tienen entrada interactiva

3-4 15% al 30% tienen entrada interactiva

5 30% al 50% tienen entrada interactiva.

7. Diseño para la eficiencia de usuario final

0 Sistema batch

1-3 No se especifican requerimientos especiales

4 Se incluyen tareas de diseño para la consideración de factores humanos

5 Además se utilizan herramientas especiales o de prototipado para promover la eficiencia.

8. Actualización On-Line

0 Nada

1-2 Actualización on line de los ficheros de control. El volumen de actualización es bajo y la recuperación fácil.

3 Actualización on line de la mayoría de los ficheros internos lógicos

4 Además es esencial la protección contra la pérdida de datos

5 Además se considera el coste de recuperación de volúmenes elevados.

9. Complejidad del procesamiento (esto es complejidad interna más allá de las convenciones de cuenta de entidades de MkII FPA).

¿Qué características tiene la aplicación?

• mucho procesamiento matemático y/o lógico

• muchas excepciones de procesamiento, muchas transacciones incompletas y mucho reprocesamiento de las transacciones

• procesamiento de seguridad y/o control sensitivo

0 No se aplica nada de esto

1-3 Se aplica alguna cosa

4 Se aplican dos cosas

5 Se aplica todo.

10. Utilizable en otras aplicaciones (el código se diseña para que sea compartido o utilizable por otras aplicaciones -no confundir con 13).

0-1 Una aplicación local que responde a las necesidades de una organización usuaria

2-3 La aplicación utiliza o produce módulos comunes que consideran más necesidades que las del usuario

4-5 Además, la aplicación se "empaquetó" y documentó con el propósito de fácil reutilización

11. Facilidad de Instalación

0-1 No se requieren por parte del usuario facilidades especiales de conversión e instalación

2-3 Los requerimientos de conversión e instalación fueron descritos por el usuario y se proporcionaron guías de conversión e instalación

4-5 Además se proporcionaron y probaron herramientas de conversión e instalación

12. Facilidad de Operación

0 No se especifican por parte del usuario consideraciones específicas de operación

1-2 Se requieren, proporcionan y prueban procesos específicos de arranque, backup y recuperación

3-4 Además la aplicación minimiza la necesidad de actividades manuales, tales como instalación de cintas y papel

5 La aplicación se diseña para operación sin atención

13. Puestos Múltiples. Añadir puntos por cada uno de los siguientes factores

0 El usuario no requiere la consideración de más de un puesto

1 De uno a cuatro puestos

2 Cinco o más puestos

1 Se proporciona documentación y plan de apoyo para soportar la aplicación en varios lugares

2 Los puestos están en países diferentes

14. Facilidad de Cambio (esfuerzo específico de diseño para facilitar cambios futuros). Añadir puntos por cada uno de los siguientes factores

0 No hay requerimientos especiales del usuario para minimizar o facilitar el cambio

1-3 Se proporciona capacidad de consulta flexible

1-2 Datos importantes de control se mantienen en tablas que son actualizadas por el usuario a través de procesos on-line interactivos.

15. Requerimientos de otras Aplicaciones

0 El sistema es stand-alone

1-4 Requerimientos del sistema para interfaces o compartición de datos deben ser sincronizados con otras aplicaciones

5 Se deben sincronizar los requerimientos del sistema con cuatro o más aplicaciones

16. Seguridad, Privacidad y Auditoría. Añadir puntos por cada uno de los siguientes factores

1 Si el sistema debe cumplir requerimientos personales (incluso legales) de privacidad

1 Si el sistema debe cumplir requerimientos especiales de auditoría

1-2 Si el sistema debe cumplir requerimientos excepcionales de seguridad para prevenir pérdidas de naturaleza financiera o militar

1 Si se requiere el criptografiado de los datos de las comunicaciones

17. Necesidad de Adiestramiento al Usuario

0 Si no es necesario material ni cursos

1-4 Si se requiere entrenamiento especial o se proporcionan facilidades de ayuda on-line

• utilización de facilidades de "help" estándares

• desarrollo de " " especiales

• entrega de material especial de adiestramiento

5 Se requiere un sistema separado de entrenamiento o simulador

18. Uso directo de otras empresas

0 No existe otra empresa conectada al sistema

1 Los datos se envían o reciben de empresas conocidas

2 Empresas conocidas están conectadas al sistema en modo de lectura solamente

3-4 Empresas conocidas están conectadas directamente al sistema con capacidad de actualización on-line

5 Empresas desconocidas (público en general o un grupo demasiado extenso como para ser adiestrado) pueden acceder al sistema

19. Documentación. Contar 1 por cada tipo de documento listado a continuación que se entrega al final del proyecto.

• Especificación Funcional del Sistema (datos y procesos)

• Especificación Técnica del Sistema

• Documentación del programa (al menos diagramas de flujo)

• Librería de Elementos de Datos

• Elemento de Datos/ Registro/ X-referencia del programa

• Manual de usuario

• Folleto de información general del sistema

• Librería de datos de prueba

• Material de curso de adiestramiento al usuario

• Documentos de coste/beneficio del sistema

• Informe de petición de cambios y errores

Se calcula el grado de influencia utilizando la siguiente tabla

0 si 0-2 tipos de documento

1 si 3-4

2 si 5-6

3 si 7-8

4 si 9-10

5 si 11-12 tipos de documento

20. Características definidas por el cliente

La lista de Características de la aplicación se puede extender, pero teniendo en cuenta que deben provenir de los requerimientos del usuario.

Como regla general se debe tratar de encajar los requerimientos en las anteriores 19 características, y extenderlo sólo en caso que sea necesario. Ejemplos que han sido incluídos son

• requerimiento de salida gráfica

• requerimientos para salida en formato de código de barras y etiquetas, que han de ser proporcionados específicamente a esta aplicación

• requerimientos para que el sistema se adapte a más de un lenguaje natural.

VII. Ecuaciones de Cálculo FP

Para proyectos de desarrollo, las reglas a utilizar son como sigue

i) Puntos de Función No-Ajustados

Para todas las transacciones lógicas del sistema, añadir la suma total de

Elementos de Datos de Entrada NI

Entidades Referenciadas NE

Elementos de Datos de Salida NO

La fórmula para calcular el total del Tamaño de Procesamiento de la Información expresada en Puntos de Función No-Ajustados es entonces

UFP's = NI · WI + NE · WE + NO · WO

donde

WI = Peso para un elemento de datos de entrada

WE = Peso para una entidad referenciada

WO = Peso para un elemento de datos de salida.

Podemos utilizar pesos calibrados en nuestro propio entorno o bien utilizar pesos estándares distribuídos por algunas compañías

WI = 0.58

WE = 1.66

WO = 0.26

ii) Ajuste de la Complejidad Técnica - TCA

TCA = 0.65 + C · (suma del grado de Influencia para las 19 características de la aplicación, más las definidas por el cliente)

El valor actual medio industrial de 'C' es 0.005

iii) Indice de Punto de Función = (Total de UFP's) · (TCA)

Método de Estimación MkII FP

Es un proceso con cinco pasos

1) Calcular o "adivestimar" el tamaño del sistema en MkII PF.

a) identificación de las transacciones lógicas del sistema. Si el proyecto está en una fase muy temprana se puede "adivestimar" el sistema, basándonos en nuestra experiencia en proyectos similares y en la tabla 59.

Aplicar los pasos b) a f) separadamente para las partes on-line y batch del sistema.

b) para cada transacción lógica contar el número de elementos de datos de entrada, tipos de entidades referenciadas y elementos de datos de salida. Así se obtienen NI, NE y NO.

c) cálculo de los UFP

UFP = 0.58 NI + 1.66 NE + 0.26 NO

(los coeficientes son industriales).

d) valorar los grados de influencia de las características de la aplicación

e) cálculo del TCA

TCA = 0.65 + 0.005 · (grados totales de influencia)

0.005 es un coeficiente industrial.

f) obtención del tamaño para las partes on-line (So) y batch (Sb)

tamaño = UFP · TCA

g) S = So + Sb

2) Cálculo del Esfuerzo

h) cálculo de la productividad para el desarrollo según la fórmula

- para S < 1000 puntos de función

- para S > 1000 puntos de función

P = L

donde

P es la productividad en puntos de función por hora de trabajo con respecto al tamaño del sistema

S es el tamaño del sistema

A es un factor de escala calibrado al entorno (valores industriales son A = 1.0 para un entorno 3GL, A = 1.6 para un 4GL)

L es la "productividad en grandes proyectos" (en ausencia de datos se calcula S = 0.06 · A para S > 1000).

i) cálculo del esfuerzo

B = 1.0 para un sistema on-line

B = 1.5 para un sistema batch

Si tenemos un sistema combinado

j) cálculo de la tasa de tiempo de entrega según la fórmula

donde D son los puntos de función por semana

k) cálculo del tiempo de entrega

[Referencia]: http://www.google.com/#hl=es&tbs=clir%3A1%2Cclirtl%3Aen&q=Metricas+de+estimacion+de+proyectos&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=ec4995acfeafd666