GUIA 2. PARTE 2. ESTIMACIONES.

Documentos relacionados
COCOMO. Modelo constructivo de costes

REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA DEFENSA UNIVERSIDAD NACIONAL EXPERIMENTAL

Ejemplo Estimación con el método de Cocomo

Ingeniería de Software I Primer Parcial

Ingeniería de Software. Tema 2 ESTIMACION DE PROYECTOS SOFTWARE

Estimación de Costos

Estimación de costes del Software

F1 F2 F3 F4 F5 F6 F7 F8 F9 F10 F11 F12 F13 F SUMA FACTORES DE AJUSTE: 32

Cuerpo de Profesores Técnicos de Formación Profesional

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 3: ADMINISTRACIÓN DE PROYECTOS

Los modelos de estimación de costos analizan la economía y deseconomía de escala. Es frecuente lograr economía en proyectos gracias a la inversión en

Ingeniería del Software de Gestión Titulación: ITIG / ITIG - LADE 1º Cuatrimestre - octubre de 2012

Estimación. Ingeniería de software Eduardo Ferreira, Martín Solari

Herramientas Informáticas I Software: Sistemas Operativos

Programa. 2.1 Métricas Internas

ADMINISTRACIÓN DE PROYECTOS. Facultad de Estadística e Informática

E77 - Gestión de Recursos de la Información. Tema 1 - Métricas del Proyecto de Software

Contenidos: Definiciones:

ADMINISTRACIÓN DE PROYECTOS. Facultad de Estadística e Informática

E77 - Gestión de Recursos de la Información. Tema 2 - Estimación

BASES DE DATOS TEMA 1 PERSPECTIVA DEL ÁREA DE BASES DE DATOS

Introducción a la Computación. Herramientas Informáticas. Omar Ernesto Cabrera Rosero Universidad de Nariño

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 7, SECCIÓN 1: REQUISITOS SOFTWARE

Programación en lenguajes estructurados de aplicaciones de gestión. Código: J62.13 Nivel: 3

Selección del Hardware y Software Administración del proceso de desarrollo de Sistemas de Información.

Biblioteca de recursos. Descargado desde

Evolución del software y su situación actual

Hoja de respuestas. Examen tipo A

Vida y Cultura. Ixmiquilpense

SISTEMAS OPERATIVOS Introducción. Amilcar Meneses Viveros

Software para supervisión y control de operaciones

Tecnología hardware y software

INDICE Sección I. Sistema de Información Gerencial Capitulo 1. Capitulo 2. Necesidades y Fuentes de Información de los Administradores

PROCEDIMIENTOS ALMACENADOS

Especificación de requisitos de software

COCOMO. estos para posteriormente poder realizar los calculos del metodo de estimación:

EL SISTEMA OPERATIVO. Dónde estamos?

GLOSARIO DE TÉRMINOS

Estimación de Proyectos

Biblioteca de recursos. Descargado desde

Cambios en Ingeniería de Software

La técnica es un sistema conformado por:

Es un conjunto de palabras y símbolos que permiten al usuario generar comandos e instrucciones para que la computadora los ejecute.

Estimación de Costos: Problemas y Enfoques. Técnicas de Estimación...

UNIDAD I Introducción al Sistema Manejador de Base de Datos (DBMS)

Presentado por: Josué Andino Denis Flores Jorge Luis Pontón Diego Soria. Andino, Flores, Pontón, Soria 1

Atributos de Calidad del Software

El sistema será definido como SACP (Sistema de Administración de Clientes y Proveedores).

Guía Docente: Guía Básica. Datos para la identificación de la asignatura. Escuela de Ingeniería Informática Grado en Ingeniería Informática

1.4.1 Inicio de la computadora por primera vez Hay problemas Causas, síntomas y soluciones a posibles averías...

Herramientas Informáticas I

ARQUITECTURA BÁSICA DEL ORDENADOR: Hardware y Software. IES Miguel de Cervantes de Sevilla

Objetivos Didácticos Contenidos Criterios de evaluación Estándares de aprendizaje evaluables

ESCUELA INDUSTRIAL SUPERIOR PEDRO DOMINGO MURILLO

UNIDAD I. Universidad del Zulia Costa Oriental del Lago. Conceptos Básicos

El Archivo. Concepto y finalidad 1

ESTÁNDAR DE COMPETENCIA

Definición de S. Tiempo Real

LÓGICA DE PROGRAMACIÓN

Administración Informática. Unidad I. Tipos de sistemas y su clasificación A) Sistemas de información.

Cliente- Servidor. Bases de Datos Distribuidas

TEMARIO DE PROFESORES TÉCNICOS DE F.P. : SISTEMAS Y APLICACIONES INFORMÁTICAS. Octubre 1997 (Publicado en el B.O.E. de 13 de Febrero de 1.

INGENIERIA DE SOFTWARE

INFORME MEMORIA CACHE Y MEMORIA VIRTUAL.

ESTIMACIÓN DE COSTOS UTILIZANDO EL MODELO COCOMO II. Gónzalez Nuñez Humberto Mendoza Hidrogo Greta Rosales López Zahira Oviedo Hernándes Guillermo

0-31 : caracteres de control : carac. Comunes : especiales (flechas, símbolos) y particulares (ñ)

UNIDAD 1: - ESTRUCTURA Y FUNCIONAMIENTO DE UN ORDENADOR

TAREA 1. INTRODUCCIÓN A LOS SISTEMAS OPERATIVOS.

ENTRADA-SALIDA. 2. Dispositivos de Carácter: Envía o recibe un flujo de caracteres No es direccionable, no tiene operación de búsqueda

Introducción a la programación: Contenido. Introducción

Capítulo 3 CICLO DE VIDA DE UN PROGRAMA. Presentación resumen del libro: "EMPEZAR DE CERO A PROGRAMAR EN lenguaje C"

INDICE Introducción Parte I: las redes y las conexiones entre redes Capitulo I: Qué es una red? Capitulo 2: los componentes de una red y como operan

En este video vamos a examinar los distintos tipos de ordenadores que podemos encontrar hoy en día.

Especialidades en GII-TI

Aspel-PROD 3.0 Aspel-PROD 3.0 Aspel-SAE 5.0 Aspel-SAE 5.0

IMPLANTACIÓN DE SISTEMAS OPERATIVOS

FACULTAD DE INGENIERÍA

Lenguaje binario. Código ASCII. Medidas de la información

Modelo y Análisis 179

MEMORIA PRIMARIA memoria primaria

Implementación de Componentes

PROGRAMA: INTRODUCCIÓN A LA INFORMÁTICA

Estimación de costos y esfuerzos. Calidad en el Desarrollo de Software. Estimación de costos para el software. Planificación de proyectos

Las herramientas ofimáticas permiten idear, crear, manipular, transmitir y almacenar información necesaria en una oficina.

Unidad I: Organización del Computador. Ing. Marglorie Colina

Guía para la instalación de discos duro SATA y Configuración RAID

Esp. Alexis Olvany Torres ch. Datos de salida. Datos de salida. Datos de salida

COORDINACIÓN GENERAL DE TECNOLOGÍAS DE INFORMACIÓN PROCEDIMIENTO DE RESPALDO DE INFORMACIÓN DEL DEPARTAMENTO DE SISTEMAS DE INFORMACIÓN

CAPITULO III CONTROLADORES

1. Secuencia y temporalización de los contenidos.

UNIDAD II. Software del Computador. Ing. Yesika Medina Ing. Yesika Medina

INGENIERÍA DEL SOFTWARE III MÉTODOS DE ESTIMACIÓN. Curso 2013/2014

CI Politécnico Estella

Tema 5: Gestión de Proyectos Software Estimación

Prof. María Alejandra Quintero. Informática Año

AUDITORIA TECNOLOGIA INFORMATICA FERNANDO RADA BARONA

ADMINISTRACIÓN DE PROYECTOS. Facultad de Estadística e Informática

SISTEMAS DE INFORMACIÓN III LABORATORIO

2.3 ESTIMACION DE PROYECTOS

Organización. Organización. Llenguatges de Programació Curs Gonzalo Besuievsky IMA - UdG. Horario Miércoles de 9:30 a 13:00

Transcripción:

1. Modelos de Estimación: Puntos de Función 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. Un Punto de Función se define como una función comercial de usuario final. De esta manera un programa que tenga x Puntos de Función entrega x funciones al usuario final. El proceso requiere dos etapas fundamentales: 1

1. Se identifican las funciones disponibles para el usuario y se organizan en cinco grupos o dominios: - Salidas. - Entradas. - Consultas. - Archivos. - Archivos Externos / Interfaces Después se clasifica y pondera cada función por su nivel de complejidad (baja, media, alta). 2. Se ajusta este total de acuerdo con unas características del entorno. 2

Tablas para el cálculo de Puntos de Función Parámetro Complejidad Peso Salidas Alta 7 Media 5 Baja 4 Entradas Alta 6 Media 4 Baja 3 Consultas Alta 7 Media 5 Baja 4 Archivos Internos Alta 15 Media 10 Baja 7 Archivos Externos / Alta 10 Interfaces Media 7 Baja 5 3

Grupo 1: Salidas. Una salida se considera única si: Tiene formato diferente. 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: Archivo de transacción enviado a otra aplicación Facturas Cheques Transacciones automáticas Mensajes al usuario Cintas Gráficos Archivos de back-up, etc. 4

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 haya contado para otro soporte. Para determinar el nivel de complejidad buscamos en la tabla siguiente y buscamos el cruce entre el valor del parámetro Cantidad de Archivos referenciados con valor del parámetro Cantidad de Datos Elementales Referenciados Cantidad Archivos referenciados de Cantidad de Datos Elementales Referenciados 1-5 6-19 20 0 1 Baja (4) Baja (4) Media (5) 2-3 Baja (4) Media (5) Alta (7) 4 Media (5) Alta (7) Alta (7) 5

Una entrada se considera única si: Grupo 2: Entradas. Tiene un formato diferente. Tiene el mismo formato que otra entrada pero requiere una lógica diferente de procesamiento, o se modifica un archivo 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 una pantalla cuya función es actualizar un archivo 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 archivo tendrá tres entradas, así como una salida (el archivo formateado de salida) y una consulta. 6

Para determinar el nivel de complejidad buscamos en la tabla siguiente y buscamos el cruce entre el valor del parámetro Cantidad de Archivos referenciados con valor del parámetro Cantidad de Datos Elementales Referenciados Cantidad Archivos referenciados de Cantidad de Datos Elementales Referenciados 1-4 5-15 16 0 1 Baja (3) Baja (3) Media (4) 2 Baja (3) Media (4) Alta (6) 3 Media (4) Alta (6) Alta (6) 7

Una consulta se considera única si: Grupo 3: Consultas. Tiene un formato diferente de otras bien en su entrada o salida. Tiene el mismo formato, tanto entrada como salida, que otra consulta pero requiere diferente lógica de procesamiento en cualquiera de los dos. PARTE SALIDA Cantidad de Archivos referenciados Cantidad de Datos Elementales Referenciados 1-5 6-19 20 0 1 Baja (4) Baja (4) Media (5) 2-3 Baja (4) Media (5) Alta (7) 4 Media (5) Alta (7) Alta (7) PARTE ENTRADA Cantidad de Archivos referenciados Cantidad de Datos Elementales Referenciados 1-4 5-15 16 0 1 Baja (4) Baja (4) Media (5) 2 Baja (4) Media (5) Alta (7) 3 Media (5) Alta (7) Alta (7) 8

Se puede encontrar archivos en: Grupo 4: Archivos. Bases de datos: 1 por vista lógica o camino de acceso. Archivos maestros: 1 por cada grupo de claves. Tablas mantenidas por los usuarios: estados, tarifas, mensajes, etc. Archivo de procesamiento batch. Índices de referencias cruzadas. Para determinar el nivel de complejidad buscamos en la tabla siguiente y buscamos el cruce entre el valor del parámetro Cantidad de Formatos / Relaciones de Registro Lógico con valor del parámetro Cantidad de Datos Elementales Referenciados Cantidad de Formatos / Relaciones de Registro Lógico Cantidad de Datos Elementales Referenciados 1-19 20-50 51 1 Baja (7) Baja (7) Media (10) 2 5 Baja (7) Media (10) Alta (15) 6 Media (10) Alta (15) Alta (15) 9

Grupo 5: Archivos Externos / Interfaces. Los interfaces se pueden encontrar en: Archivos lógicos internos accesibles desde otra aplicación. Archivos lógicos internos accedidos en otra aplicación. Base de datos compartida. Lista de parámetros compartida. Archivo de impresión exportado Archivo de transacción compartido que requiere conversión. Cantidad de Formatos / Relaciones de Registro Lógico Cantidad de Datos Elementales Referenciados 1-19 20-50 51 1 Baja (5) Baja (5) Media (7) 2 5 Baja (5) Media (7) Alta (10) 6 Media (7) Alta (10) Alta (10) 10

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 distribuidos 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. 11

1. Comunicación de datos La aplicación es por lotes o utilizando un computador personal. 0 La aplicación es por lotes pero existe una entrada de datos o impresión remotas. 1 La aplicación es por lotes pero la entrada de datos y la impresión son remotas. 2 Entrada on-line de datos a un sistema de consultas. 3 Más de un computador front-end, pero la aplicación soporta sólo un tipo de protocolo de comunicaciones. 4 Más de un computador front-end y la aplicación soporta más de un tipo de protocolo de comunicaciones. 5 2. Funciones Distribuidas No existen funciones distribuidas en la aplicación. 0 La aplicación prepara datos que el usuario final procesa en otro componente del sistema. 1 La aplicación prepara datos que son transferidos y procesados por otro componente del sistema, pero no por el usuario final. 2 El proceso distribuido y la transferencia de datos son on-line y en una sola dirección. 3 El proceso distribuido y la transferencia de datos son on-line y en ambas direcciones. 4 Los procesos se desarrollan de forma dinámica en el componente más apropiado del sistema. 5 12

3. Rendimiento No existen requisitos específicos de rendimiento. 0 El rendimiento y requisitos de diseño han sido definidos y revisados pero no requieren ninguna acción especial. 1 El tiempo de respuesta o la capacidad de proceso es crítico durante las horas punta y no se requiere ningún diseño especial para la utilización de la CPU. 2 El tiempo de respuesta o la capacidad de proceso es crítico durante todas las horas de operación, pero no se requiere ningún diseño especial para la utilización de la CPU. 3 Se requiere un diseño especial para tener en cuenta los requisitos de rendimiento ya que éstos son muy estrictos por parte del usuario. 4 Sobre el punto 4, además hay que utilizar herramientas para el análisis de rendimiento durante la fase de diseño, codificación y/o instalación. También hay que verificar los requisitos de rendimiento. 5 4. Configuraciones fuertemente utilizadas No existen restricciones de ningún tipo. 0 Existen restricciones operativas, pero no requieren un esfuerzo especial para conseguirlas. 1 Existen algunas restricciones de seguridad o tiempo. 2 Existen requisitos específicos de procesador para algunas partes de la aplicación. 3 Las restricciones definidas en el computador central o procesador obligan a limitaciones en la aplicación. 4 Además de las características del punto 4, existen limitaciones en los componentes distribuidos del sistema. 5 13

5. Frecuencia de Transacciones No existe una definición del periodo punta de transacciones. 0 Se conoce el periodo punta (mensual, trimestral, etc). 1 Se conoce el periodo punta mensual. 2 Se conoce el periodo punta diario. 3 La frecuencia de transacciones definida por el usuario en los requisitos de la aplicación es suficientemente alta como para requerir un análisis específico de los rendimientos de tareas durante la 4 fase de diseño. La frecuencia de transacciones definida por el usuario en los requisitos de la aplicación es suficientemente alta como para requerir el uso de herramientas de análisis de los rendimientos de 5 tareas y de herramientas de medida del rendimiento en el diseño, codificación y/o instalación. 6. Entrada de datos on-line Todas las entradas se realizan por lotes. 0 0% > (entradas interactivas) < 8% 1 8% >= (entradas interactivas) < 16% 2 16% >= (entradas interactivas) < 24% 3 24% >= (entradas interactivas) <=30 % 4 Más del 30% de las entradas son interactivas. 5 14

7. Eficiencia del usuario final Ninguna función. 0 1-3 funciones. 1 4-5 funciones. 2 6 o más funciones, pero no existen requisitos de usuario respecto a la eficiencia. 3 6 o más funciones, pero están definidos los requisitos de eficiencia del usuario que obligan a diseñar tareas que tienen en cuenta factores humanos (p.ej. minimizar el 4 número de tecleos). 6 o más funciones, y hay requisitos del usuario sobre eficiencia que obligan a utilizar 5 herramientas especiales y procesos para demostrar que los objetivos se han cumplido. 8. Actualizaciones on-line Ninguna. 0 Actualización on-line de 1 a 3 ficheros. 1 Actualización on-line de 4 o más ficheros. 2 Actualizaciones importantes de los Ficheros Lógicos Internos. 3 Además del punto 3, la protección contra la pérdida de datos es esencial y ha sido especialmente diseñada y programada en el sistema. 4 Además del punto 4, existe un alto volumen de transacciones y los procedimientos de recuperación están altamente automatizados con intervención mínima del usuario. 5 15

9. Procesos Complejos Ninguna de las siguientes categorías: Controles especiales (auditorías) y/o aplicaciones de seguridad. Procesos lógicos complejos. Procesos matemáticos complejos. Excesivas excepciones de proceso. Manejo de dispositivos complejos (multimedia, etc) Una de las categorías anteriores. 1 Dos de las categorías anteriores. 2 Tres de las categorías anteriores. 3 Cuatro de las categorías anteriores. 4 Todas las categorías anteriores. 5 10. Reusabilidad (o Nivel de Reutilización) No reusable. 0 Se utiliza código reusable dentro de la aplicación. 1 Sobre el punto 1, menos del 10% de la aplicación tiene en cuenta necesidades de más de un usuario. 2 Sobre el punto 1, el 10% o más de la aplicación tiene en cuenta necesidades de más de un usuario. 3 La aplicación fue expresamente realizada y documentada para ser fácilmente reusable. La aplicación es adaptada por el desarrollador a nivel de código fuente. 4 La aplicación fue expresamente realizada y documentada para ser fácilmente reusable. La aplicación es adaptada por el desarrollador o el usuario por medio de parámetros de mantenimiento. 5 0 16

11. Facilidad de Instalación No existen requisitos especiales de instalación ni se requieren desarrollos especiales. 0 No existen requisitos especiales de instalación pero sí se requieren desarrollos especiales para la instalación. 1 Los requisitos de instalación fueron definidos por el usuario. 2 Los requisitos de instalación fueron definidos por el usuario y las guías de conversión e instalación fueron proporcionadas y probadas. 3 Además del punto 2, se proporcionaron y probaron herramientas para la instalación. 4 Además del punto 2, se proporcionaron y probaron herramientas para la instalación y revisión automática. 5 12. Facilidad de Operación No se definieron por parte del usuario necesidades especiales de operación. 0 Seleccionar, valorando como uno, cada una de las siguientes solicitudes realizadas a la aplicación: Procesos eficaces de arranque y recuperación (contar como 2). 1-4 La aplicación minimiza la necesidad de uso/manejo de cintas. La aplicación minimiza la necesidad de uso/manejo de papel. La aplicación debe diseñarse para que los usuarios sólo tengan que intervenir en el 5 proceso de arranque y parada de la aplicación. 17

13. Instalación en Lugares Distintos No existen requisitos de usuario para considerar la necesidad de más de un usuario o lugar de instalación. 0 Se necesita diseñar la aplicación para ser utilizada en múltiples lugares pero funcionará bajo entornos idénticos de hardware y software. 1 Se necesita diseñar la aplicación para ser utilizada en múltiples lugares pero funcionará bajo entornos similares de hardware y software. 2 Se necesita diseñar la aplicación para ser utilizada en múltiples lugares pero funcionará bajo entornos distintos de hardware y software. 3 Deberán ser proporcionados y probados la documentación y los planes de soporte de la aplicación para ser utilizados en distintos lugares en el modo que se indicó en los puntos 1 ó 2. 4 Deberán ser proporcionados y probados la documentación y los planes de soporte de la aplicación para ser utilizados en distintos lugares en el modo que se indicó en el punto 3. 5 14. Facilidad de Cambio No existe ningún requisito por parte de los usuarios para facilitar el cambio (ej. distintas entradas al sistema, flexibilidad en las consultas o salidas, etc.) 0 Se seleccionará alguna de estas opciones: Facilidad para realizar consultas o informes simples tales como la utilización de operadores lógicos AND/OR sobre un fichero lógico interno. (Contar por 1). Facilidad para realizar consultas o informes de complejidad media tales como la utilización de operadores lógicos AND/OR sobre más de un fichero lógico interno. (Contar por 2). Facilidad para realizar consultas o informes complejos. (Contar por 3). Se mantendrán datos de control en tablas que serán gestionados por los usuarios a través de procesos interactivos on-line, pero los cambios no son efectivos inmediatamente (Contar por 1). Igual que en el caso anterior, pero los cambios serán efectivos inmediatamente. (Contar por 2). 1-5 18

EJEMPLO DE ESTIMACIÓN CON PUNTOS DE FUNCIÓN Un banco le ha encargado la realización de una aplicación para la ayuda a la toma de decisiones en la concesión de créditos. El cliente explica que la aplicación debería tomar como entradas una serie de grupos de datos con: Información personal del cliente (nombre, cédula, edad, domicilio y estado civil), Ocupación (profesión, tipo de contrato, antigüedad, sueldo), Información sobre el crédito (destino del mismo, cantidad y plazo de devolución). Todas estas entradas serán interactivas. La aplicación debe mantener un almacén con las personas que han solicitado un crédito (independientemente de si se les ha concedido o no), que debe ser actualizado de manera on-line. La aplicación debe poder realizar consultas por tipo de crédito y por concesión (es decir, consultar créditos concedidos y no concedidos). Además, el banco posee un archivo con clientes morosos, que la aplicación puede leer. Con los datos de entrada, la aplicación debe producir en una salida textual una sugerencia sobre la concesión del crédito y las condiciones del mismo. Tras la toma de decisión sobre la concesión del crédito, el usuario de la aplicación introduce en una nueva pantalla si se concede el crédito o no. Además se quiere tener la posibilidad de generar listados de los créditos concedidos, así como una estadística. 19

El banco quiere instalar la aplicación en diversas oficinas, todas con computadores personales con sistema operativo Windows XP. Los usuarios han pedido un diseño para obtener la máxima eficiencia del usuario final así como la máxima facilidad de operación. Además, se prevé que el cálculo para la recomendación de la concesión del crédito tendrá una lógica compleja, si bien se reutilizará código de un proyecto anterior en la aplicación. Se pide: a) Calcule de manera razonada los Puntos de Función ajustados para la aplicación que se describe. b) Estime el costo de la aplicación, teniendo en cuenta que ha planificado implementarla en el lenguaje Visual Basic. Las métricas de proyectos anteriores de la empresa indican una tasa de 95 líneas de código por punto de función y 8 Euros por línea de código en Visual Basic. Durante el proyecto, el cliente propone añadir nueva funcionalidad a la aplicación. En particular, una nueva salida gráfica con el volumen de dinero concedido por el banco por año (complejidad alta), así como una nueva consulta por estado civil (complejidad baja). Además, el cliente quiere añadir restricciones de seguridad a la aplicación (encriptación de datos). Cómo influirían estos cambios en el presupuesto inicial? (use las mismas tasas que para el apartado b). 20

SOLUCION. Primero determinamos los niveles de complejidad para cada grupo (o dominio): SALIDAS: Elemento Archivos referenciados Datos elementales referenciados Una salida textual con sugerencia sobre la concesión del crédito y las condiciones del mismo Listados de créditos concedidos 1 (el de créditos) 1 (ese listado de concedidos) La salida (sí/no) Los 3 de créditos (destino, cantidad, plazo) Los de clientes: 5 info personal y 4 de ocupación 1 (el de esa estadística). Estadística 0 (la estadística se genera) 3 Elementos 2 14 Cruce de 2 archivos con 14 datos: complejidad MEDIA. Puntaje: 5. ENTRADAS: Elemento Archivos referenciados Datos elementales referenciados Información Personal Cliente Ocupación Información Crédito 1 (el de CLIENTES) 1 (el de créditos) Los de clientes: 5 info personal 4 de ocupación Los 3 de créditos: (destino, cantidad, plazo) 1 Pantalla concesión de crédito 0 4 Elementos 2 13 Cruce de 2 archivos con 13 datos: complejidad MEDIA. Puntaje: 4. 21

CONSULTAS (se tiene en cuenta parte de salida, pues la entrada son solo los parámetros mencionados): Elemento Archivos referenciados Datos elementales referenciados Por tipo de crédito por concesión 1 (el de créditos) 1 (el de CLIENTES) 1 : El de destino Los de clientes: 5 info personal y 4 de ocupación 2 Elementos 2 10 Cruce de 2 archivos con 10 datos: complejidad MEDIA. Puntaje: 5. ARCHIVOS INTERNOS Elemento Archivos referenciados Datos elementales referenciados Almacén con las personas que han solicitado un crédito 1 (el de CLIENTES) 1 (el de créditos) Los de clientes: 5 info personal y 4 de ocupación Los 3 de créditos: (destino, cantidad, plazo) 1 Elemento 2 12 Cruce de 2 archivos con 12 datos: complejidad BAJA. Puntaje: 7. ARCHIVOS EXTERNOS Elemento Archivos referenciados Datos elementales referenciados Clientes morosos 1 (ese archivo de morosos) Los de clientes: 5 info personal y 4 de ocupación Los 3 de créditos (destino, cantidad, plazo) 1 Elemento 1 12 Cruce de 1 archivo con 12 datos: complejidad BAJA. Puntaje: 5. 22

Ahora presentamos una tabla resumida a partir del análisis anterior: Dominio Salidas Elementos Una salida textual con sugerencia sobre la concesión del crédito y las condiciones del mismo Listados de créditos concedidos Estadística Entradas Información Personal Cliente Ocupación Información Crédito Pantalla concesión de crédito Consultas Por tipo de crédito Archivos Internos Archivos Externos / Interfaces Cantidad de Elementos Valor de Complejidad Producto 3 5 15 4 4 16 Por concesión 2 5 10 Almacén con las personas que han solicitado un crédito 1 7 7 Clientes morosos 1 5 5 Sumatoria de los valores de la columna Producto 53 Puntos de Función sin Ajustar (PFSA): 53 23

Con respecto a los Factores de Ajuste: # Factor de Ajuste Calificación 1 Comunicación de datos 0 2 Funciones distribuidas 0 3 Rendimiento 0 4 Configuraciones fuertemente utilizadas 0 5 Frecuencia de Transacciones 0 6 Entrada de datos on-line 5 (Todas las entradas interactivas) 7 Eficiencia del usuario final 5 (máxima) 8 Actualizaciones on-line 1 (1 archivo) 9 Procesos complejos 1 (procesos lógicos complejos) 10 Reusabilidad 1 (se utiliza código reusable) 11 Facilidad de instalación 0 12 Facilidad de operación 5 (máxima facilidad operación) 13 Instalación en lugares distintos 1 (entornos idénticos) 14 Facilidad de cambio 0 Suma Factores de Ajuste 19 Puntos de Función Ajustados (PFA): PFA = PFSA * (0.65 (0.01*(Suma Factores de Ajuste))) PFA = 53 * (0.65 (0.01*(19))) = 53 * (0.65 0.19) = 53 * 0.84 = 44.52 Total Puntos de Función: 44 24

Estime el costo de la aplicación, teniendo en cuenta que ha planificado implementarla en el lenguaje Visual Basic. Las métricas de proyectos anteriores de la empresa indican una tasa de 95 líneas de código por punto de función y 8 Euros por línea de código en Visual Basic. LDC Visual Basic = 44 PF * 95 (LDC / PF) = 4180 LDC Costo = 4180 LDC * 8 Euros / LDC = 33440 Euros La tabla siguiente proporciona estimaciones informales del número de líneas de código que se necesitan para construir un punto de función en varios lenguajes de programación: Lenguaje LDC/PF Ensamblador 320 C 128 Cobol 105 Fortran 105 Pascal 90 C 65 Java 55 SQL 15 25

Durante el proyecto, el cliente propone añadir nueva funcionalidad a la aplicación. En particular: Una nueva salida gráfica con el volumen de dinero concedido por el banco por año (complejidad alta), Una nueva consulta por estado civil (complejidad baja). Además, el cliente quiere añadir restricciones de seguridad a la aplicación (encriptación de datos). Cómo influirían estos cambios en el presupuesto inicial? Se añade una salida compleja (7) y una consulta simple (4), por tanto los nuevos puntos de función sin ajustar son: 53 11 = 64. Con las restricciones de seguridad se ve afectado el ítem Configuraciones fuertemente utilizadas con un valor de 2 (restricciones de seguridad). Nuevo Factor de Ajuste: 21 PFA = 64 x (0.650.21) = 64 * 0.86 = 55.04 --> 55 PF Visual Basic = 55 PF * 95 LDC / PF = 5225 LDC Costo = 5225 LDC * 8 Euros / LDC = 41800 Euros 26

2. Modelos de Estimación: COCOMO (COnstructive COst MOdel): a) Básico: Calcula esfuerzo y coste en función del tamaño del programa (LDC). b) Intermedio: Calcula el esfuerzo del desarrollo en función del tamaño del programa y de un conjunto de "conductores de coste" (evaluación subjetiva del producto, Hardware, personal y atributos del proyecto). COCOMO está definido para tres tipos de proyectos de Software: 1. Modo orgánico: Proyectos pequeños y sencillos, con equipos de experiencia en la aplicación y requisitos poco rígidos. 2. Modo semiacoplado: Proyectos intermedios (más complejos), con equipos que poseen variados niveles de experiencia y requisitos más rígidos. 3. Modo empotrado: Proyectos que deben ser desarrollados en un conjunto de Hardware, Software y restricciones muy grandes. Modelo COCOMO Básico. Las ecuaciones del COCOMO básico son: E = a * (KLDC) b D = c * (E) d Donde E es esfuerzo aplicado (personas/mes), D es tiempo de desarrollo (meses) y KLDC es el número estimado de líneas de código (en miles). a, b, c y d son coeficientes. El modelo COCOMO básico maneja los siguientes valores para los coeficientes: Modo (Tipo de Proyecto) a b c d Orgánico 2.4 1.05 2.5 0.38 Semiacoplado 3.0 1.12 2.5 0.35 Empotrado 3.6 1.20 2.5 0.32 27

Modelo COCOMO Intermedio. La ampliación del modelo básico considera un conjunto de "atributos conductores del coste". (a) Del Producto. (b) Del hardware. (c) Del personal. (d) Del proyecto. Cada atributo se valora desde "muy abajo" hasta "extra alto" (escala de 6 puntos). Según la evaluación, se determina un multiplicador de esfuerzo (TABLAS DE BOEHM). El factor de ajuste del esfuerzo (FAE) viene del producto de los multiplicadores de esfuerzo. Los valores típicos de FAE van de 0,7 a 1,66. La ecuación del COCOMO intermedio es: E = a * (KLDC) b * FAE Donde E es el esfuerzo aplicado (personas/mes) y KLDC es el número estimado en líneas de código (en miles). a y b son coeficientes. COCOMO es el modelo empírico más complejo para la estimación del Software. El modelo COCOMO intermedio maneja los siguientes valores para los coeficientes: Modo (Tipo de Proyecto) a b Orgánico 3.2 1.05 Semiacoplado 3.0 1.12 Empotrado 2.8 1.20 El tiempo de desarrollo se da por: D = 2.5 * (E) 0.38 28

Atributos de coste. Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo. De un análisis estadístico de más de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO. Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto. (1) Atributos del producto RELY: garantía de funcionamiento requerida al software DATA: tamaño de la base de datos CPLX: complejidad del producto (2) Atributos del hardware TIME: restricción de tiempo de ejecución VIRT: volatilidad de la máquina virtual (3) Atributos del personal ACAP: capacidad del analista PCAP: capacidad del programador LEXP: experiencia en lenguaje de prog. STOR: restricción del almacenamiento principal TURN: tiempo de respuesta del ordenador AEXP: experiencia en la aplicación VEXP: experiencia en máquina virtual (4) Atributos del proyecto MODP: prácticas de programación modernas TOOL: utilización de herramientas software SCED: plan de desarrollo requerido 29

Estos 15 valores se multiplican, y nos proporciona el esfuerzo ajustado al entorno. COST DRIVERS Very Low Low Nominal High Very High Extra High 1 2 3 4 5 6 PRODUCTO RELY Fiabilidad 0,75 0,88 1,00 1,15 1,40 DATA Tamaño BD 0,94 1,00 1,08 1,16 CPLX Complejidad Prod. 0,70 0,85 1,00 1,15 1,30 1,65 HARDWARE TIME Restricciones en Tiempo Ejecución 1,00 1,11 1,30 1,66 STOR Restricciones Almacenamiento 1,00 1,06 1,21 1,56 VIRT Máquina Virtual 0,87 1,00 1,15 1,30 TURN Tiempo de Máquina 0,87 1,00 1,07 1,15 PERSONAL ACAP Capacidad Analista 1,46 1,19 1,00 0,86 0,71 AEXP Experiencia 1,29 1,13 1,00 0,91 0,82 PCAP Capacidad Programador 1,42 1,17 1,00 0,86 VEXP Experiencia en Maq. Virtual 1,21 1,10 1,00 0,90 LEXP Experiencia en Leng Progr. 1,14 1,07 1,00 0,95 DEL PROYECTO MODP Uso prácticas de Progr. Modernas 1,24 1,10 1,00 0,91 0,82 TOOL Uso de Herram. Software 1,24 1,10 1,00 0,91 0,83 SCED Agenda de Desarrollo requerido 1,23 1,08 1,00 1,04 1,10 30

Significado de los atributos. A. RELY. Indica las posibles consecuencias para el usuario en el caso que todavía existan defectos en el producto. Una puntuación "muy baja" indica que solamente hace falta eliminar los defectos sin ninguna otra consecuencia. Very Low Low Nominal High Very High El efecto de un fallo del software simplemente trae como consecuencia la inconveniencia de corregir el fallo. El efecto de un fallo software es una pérdida fácilmente recuperable para los usuarios. El efecto es una moderada pérdida para los usuarios, pero es una situación de la que se puede salir sin excesiva dificultad. El efecto es una gran pérdida financiera o una inconveniencia masiva humana. El efecto es una pérdida de vidas humanas. B. DATA. Indica el tamaño de la base de datos a desarrollar en relación con el tamaño del programa. Tenemos cuatro segmentos con la razón 10-100-1000, que determinan las puntuaciones de 'bajo' a 'muy alto'. Se define por el cociente: D (Tamaño de la base de datos en bytes) P (Tamaño del programa en DSI) donde D es la cantidad de datos a ser articulada y almacenada en memoria secundaria (cintas, discos, etc.) hasta el tiempo de entrega del producto software. C. CPLX. Indica la complejidad de cada módulo y se utiliza para determinar la complejidad compuesta del sistema. Entonces la puntuación puede variar de "muy bajo" si el módulo está compuesto de expresiones matemáticas simples a "extremadamente alto" para módulos que utilizan muchos recursos de planificación. 31

D. TIME. Siempre será más exigente para un programador escribir un programa que tiene una restricción en el tiempo de ejecución. Esta puntuación se expresa en el porcentaje de tiempo de ejecución disponible. Es 'nominal' cuando el porcentaje es el 50%, y "extremadamente alto" cuando la restricción es del 95%. E. STOR. Se espera que un cierto porcentaje del almacenamiento principal sea utilizado por el programa. El esfuerzo de programación se incremente si el programa tiene que correr en un volumen menor del almacenamiento principal. STOR captura este esfuerzo extra de "nominal" cuando la reducción del almacenamiento principal es del 50% a "extremadamente alto" cuando la reducción es del 95%. F. VIRT. Durante el desarrollo del software la máquina (hard y soft) en la que el programa se va a desarrollar puede sufrir algunos cambios. VIRT lo refleja desde "bajo" a "muy alto". G. TURN. Cuantifica el tiempo de respuesta del ordenador desde el punto de vista del programador. Cuanto mayor sea el tiempo de respuesta, más alto será el esfuerzo humano. TURN puede variar desde "bajo" para un sistema interactivo a "muy alto", cuando el tiempo medio de respuesta es de más de 12 horas. H. ACAP. La capacidad del grupo de analistas, en términos de habilidad de análisis, eficiencia y capacidad para cooperar tiene un impacto significativo en el esfuerzo humano. Cuanto más capaz sea el grupo, menos esfuerzo será necesario. ACAP puede variar desde "muy bajo" a "muy alto". 32

I. AEXP. La experiencia del grupo en una aplicación similar tiene una gran influencia en el esfuerzo. Puede variar desde "muy bajo" (menos de cuatro meses de experiencia) a "muy alto" (mayor de 12 años de experiencia). Very Low Low Nominal High Very High < 4 meses experiencia media 1 año de experiencia media 3 años de experiencia media 6 años de experiencia media > 12 años, o reimplementación de un subsistema J. PCAP. La cuantificación es similar a la de ACAP, pero en este caso relacionado con los programadores. Se aplica a los programadores como grupo, pero no a los programadores individuales. K. VEXP. Cuanto mayor sea la experiencia del grupo de programación con el procesador, menor será el esfuerzo necesario. VEXP puede variar desde "muy bajo", cuando la experiencia es menor de un mes, a "alto" cuando esta experiencia es mayor de 3 años. Very Low Low Nominal High < 1 mes experiencia media 4 meses 1 año > 3 años 33

L. LEXP. Un grupo de programadores con amplia experiencia en un lenguaje determinado programará de una manera mucho más segura, generando un menor número de defectos y de requerimientos humanos. Puede variar desde "muy bajo" a "alto" para un grupo de un mes a tres años de experiencia, respectivamente. Very Low < 1 mes experiencia media Low 4 meses Nominal 1 año High > 3 años M. MODP. Utilización de prácticas modernas de programación. Varía de "muy bajo" a "muy alto". Estas prácticas incluyen, p.e.: programación estructurada y desarrollo "top-down". Very Low No se utilizan prácticas modernas de programación (PMP). Low Nominal High Very High Uso experimental de algunas PMP Experiencia razonable en el uso de algunas PMP Experiencia razonable en gran parte de PMP Uso habitual de PMP N. TOOL. El uso adecuado de herramientas software es un multiplicador de la productividad. La puntuación de TOOL varía desde "muy bajo" cuando sólo se utilizan herramientas básicas, a "muy alto" cuando se utilizan herramientas específicas. O. SCED. El tiempo nominal de desarrollo, tal como se define en el modo básico, es el plazo que requiere menor esfuerzo humano. Cualquier adelantamiento ("muy bajo") o retraso ("muy alto") demandarán más esfuerzo. 34

Ejemplo: Supóngase que se calculó que el tamaño estimado de un proyecto de software de modo orgánico es de 32000 LDC. MODELO BÁSICO: El número de personas mes requeridas por el proyecto: Esfuerzo = 2.4 * (32) (1.05) = 91 p.m. (personas mes) El periodo requerido para terminar el proyecto: Tiempo = 2.5 * (91) (0.38) = 14 meses La cantidad de personal necesario para terminar el proyecto en la escala de tiempo: N = PM/TDES = 91/14 = 6.5 personas 35

Recalculando lo anterior: Modo Orgánico: Esfuerzo = 3.2 * (32) (1.05) = 122 p*m (personas mes) El periodo requerido para terminar el proyecto (solo para el valor nominal): Tiempo = 2.5 * (122) (0.38) = 15.5 meses La cantidad de personal necesario para terminar el proyecto en la escala de tiempo: Cantidad de personas = Esfuerzo/Tiempo = 122 (p*m) / 15.5 m = 7.8 personas 36

3. EJEMPLOS (Libro de Pressman) 3.1. Líneas de Código. Se desea construir un software CAD. Con los siguientes componentes identificados: FUNCIÓN LDC (est.) Interfaz de Usuario y Facilidades de Control (IUFC). 2.300 Análisis Geométrico de dos dimensiones (AG2D). 5.300 Análisis Geométrico de tres dimensiones (AG3D). 6.800 Gestión de Base de Datos (GBD). 3.350 Facilidades de presentación gráfica de computadora (FPGC). 4.950 Control de Periféricos (CP). 2.100 Módulos de Análisis del Diseño (MAD). 8.400 LINEAS DE CÓDIGO ESTIMADAS 33.200 Nos dan Tasa de Productividad = 620 LDC/pm Tarifa Laboral = 8000 / pm Procedemos a calcular: 8000 / pm 8000 pm * Costo LDC = = 620 LDC/pm 620 pm * LDC = 13 / LDC Costo Total Proyecto = 13 / LDC * 33200 LDC = 431.600 33200 LDC 33200 pm * LDC Esfuerzo = = 620 LDC/pm 620 LDC = 53.5 pm 54 pm 37

3.2. ESTIMACIÓN BASADA EN PUNTOS DE FUNCIÓN (Complemento) DOMINIO DE INFORMACIÓN CUENTA FACTOR DE PESO (FP) SIMPLE MEDIO COMPLEJO Número Entradas Usuario 3 4 6 Número Salidas Usuario 4 5 7 Número Peticiones al Usuario 3 4 6 Número de Archivos 7 10 15 Número Interfaces Externos 5 7 10 CUENTA TOTAL EST DOMINIO DE INFORMACIÓN CUENTAS OPT PROB PES EST PESO Cuenta PF Número Entradas Usuario 20 24 30 24.33 4 97 Número Salidas Usuario 12 15 22 15.66 5 78 Número Peticiones al Usuario 16 22 28 22 4 88 Número de Archivos 4 4 5 4.16 10 42 Número Interfaces Externos 2 2 3 2.16 7 15 CUENTA TOTAL 320 38

Luego, se estima cada Factor de Ponderación de Complejidad: c/u se evalúa de 0 a 5. Copia de Seguridad y Recuperación 4 Comunicaciones de Datos 2 Proceso Distribuido 0 Rendimiento Crítico 4 Entorno Operativo Existente 3 Entrada de Datos (On-Line) 4 Transacciones de entrada en # pantallas 5 Arch. Maestros actualizados (On-Line) 3 Complejidad Valores del Dom. de Info. 5 Complejidad del Procesamiento Interno 5 Codigo Diseñado xa Reutilización 4 Conversión / Instalación en diseño 3 Instalaciones Múltiples 5 Aplicación diseñada para el cambio 5 0- Sin influencia 1- Incidental 2- Moderado 3- Medio 4- Significativo 5- Esencial PF = Cuenta Total x [0,65 0,01 x SUM(Fi)] [0,65 0,01 x SUM(Fi)]: Factor de ajuste de complejidad SUM(Fi) = 52 PF = 320 x [0,65 (0,01 x 52)] = 320 x [0,65 0,52] = 320 x [1.17] = 374.4 375 Nos dan Tasa de Productividad = 6.5 PF/pm Tarifa Laboral = 8000 / pm Costo PF = 8000 / pm 8000 pm * = 6.5 PF/pm 6.5 pm * PF = 1230 / PF Costo Total Proyecto = 1230 / PF * 375 PF = 461.250 375 PF 375 pm * PF Esfuerzo = = 6.5 PF/pm 6.5 PF = 57.6 pm 58 pm 39

Donde: E = Esfuerzo de desarrollo en personas-año. t = tiempo de desarrollo en años. B = Factor Especial de Destrezas. 4. LA ECUACIÓN DEL SOFTWARE Esfuerzo L 4/3 P* t L = Número de líneas de código fuente. P = Parámetro (o Índice) de Productividad. Sobre el parámetro de productividad (P): Los datos de la siguiente tabla están tomados directamente del Documento Modern Empirical Cost and Schedule Estimation Tools. A DACS State-of-the-Art Report. Disponible en: http://goo.gl/vtnc1a 3 * B Índice Tipo Aplicación 987 Microcódigo Índices de Productividad Ejemplos o aclaraciones El microcódigo son las instrucciones que ejecuta la unidad de control dentro de la arquitectura interna de un microprocesador. Ningún usuario tiene acceso al microcódigo; solo en casos muy especiales algunos proveedores de micros escriben microcódigo a medida de clientes para aplicaciones específicas. 40

Índice 1597 Tipo Aplicación Firmware (ROM) Índices de Productividad Ejemplos o aclaraciones El glosario estándar de terminología del software del Institute of Electrical and Electronics Engineers (IEEE), Std 610.12-1990, define el firmware como sigue: "La combinación de instrucciones de un dispositivo de hardware e instrucciones y datos de computadora que residen como software de solo lectura en ese dispositivo". Como pueden ver se refiere a otros elementos hardware (además del microprocesador) que tengan instrucciones al interior de su estructura. Entonces, el firmware es software, no tiene nada físico salvo el dispositivo que lo contiene. Se llama diferente por varias razones: - No lo puede cambiar el usuario normal, a veces se puede actualizar - Sin el firmware NADA funciona, es la BIOS del sistema. - Está ligado al hardware, y no servirá de un aparato a otro EN CASO DE NO SER idénticos. 1974 Software Embebido de Tiempo Real Software para aviónica Un sistema embebido (anglicismo "embedded") o empotrado (integrado, incrustado) es un sistema de computación diseñado para realizar una o algunas pocas funciones dedicadas, frecuentemente en un sistema de computación en tiempo real. Al contrario de lo que ocurre con los computadores de propósito general (como por ejemplo una computadora personal) que están diseñados para cubrir un amplio rango de necesidades, los sistemas embebidos se diseñan para cubrir necesidades específicas. En un sistema embebido la mayoría de los componentes se encuentran incluidos en la placa base (la tarjeta de vídeo, audio, módem, etc.) y muchas veces los dispositivos resultantes no tienen el aspecto de lo que se suele asociar a una computadora. Algunos ejemplos de sistemas embebidos podrían ser dispositivos como un taxímetro, un sistema de control de acceso, la electrónica que controla una máquina expendedora o el sistema de control de una fotocopiadora entre otras múltiples aplicaciones. Por lo general los sistemas embebidos se pueden programar directamente en el lenguaje ensamblador del microcontrolador o microprocesador incorporado sobre el mismo, o también, utilizando los compiladores específicos, pueden utilizarse lenguajes como C o C; en algunos casos, cuando el tiempo de respuesta de la aplicación no es un factor crítico, también pueden usarse lenguajes interpretados como JAVA. 41

Índice Tipo Aplicación Índices de Productividad Ejemplos o aclaraciones 4181 Control Autom Software para automatización de procesos, brazos robot, control de hidroeléctricas, etc. 5186 Control de Procesos Software para control estadístico de procesos. Software para inspección de defectos de productos manufacturados. 8362 Telecomunic. Software para gestión de redes y/o centrales de comunicación para celulares. 13530 28657 Software de Sistemas Sistemas científicos Sistemas para negocios Software para dinámica de sistemas, investigación de operaciones, sistemas sociales, etc. Software para bio-informática, simulaciones físicas o químicas, modelado de piezas (como AUTOCAD), análisis químicos, herramientas CASE, etc. Software para ventas, inventarios, nóminas, control académico, contabilidad, planeación y gestión de proyectos, transportes y envíos, etc. Y el valor B (sobre Factor Especial de Destrezas) se obtiene de la siguiente tabla: Tamaño (en Líneas de Código Fuente en inglés, Source Lines of Code SLOC- ) Valor del factor B 5 15 K 0.16 20 K 0.18 30 K 0.28 40 K 0.34 50 K 0.37 > 70 K 0.39 ------------------------ FIN DEL DOCUMENTO 42