TRABAJO INVESTIGATIVO 5

ALEJANDRO TIQUE CIFUENTES COD: 20101078102 MARCELA MORENO COD: 20102078076 YEISON RINCN COD:20092078071

ANLISIS DE SISTEMAS PRESENTADO A: JUAN CARLOS GUEVARA

UNIVERSIDAD DISTRITAL FRANCISCO JOS DE CALDAS FACULTAD TECNOLOGICA TECNOLOGA EN SISTEMATIZACIN DE DATOS BOGOT, 2013

INTRODUCCION

El xito o fracaso de un proyecto de software es una cuestin de percepcin, y puede variar de un proyecto a otro, En los proyectos de software, la gestin de riesgos resulta un escaln vital para obtener el xito en el desarrollo de tales proyectos. Las presiones de la competencia, los cambios normativos y la evolucin de las tcnicas, pueden obligar a los jefes de proyectos de software a alterar los planes y estrategias durante la ejecucin de un proyecto. Los cambios en los requerimientos de los usuarios, las nuevas herramientas y tecnologas, las constantes amenazas de seguridad y los cambios en la plantilla de empleados, aaden ms presin al equipo de proyectos de software y perjudican la toma de decisiones. Por lo tanto es necesario administrar los riesgos por medio de un proceso de desarrollo de software predecible ya que provee un fundamento que permite generar en forma consistente el software para el usuario final, y a un menor costo. A partir de esta base, se podrn adoptar tcnicas y herramientas para lograr que los desarrolladores sean ms productivos, para elevar la calidad del software, y para automatizar muchos de los procesos de gestin del software, liberando de esta manera ms tiempo para el desarrollo de las aplicaciones. Existe una creciente necesidad en las compaas de desarrollo de software, de disponer herramientas que permitan automatizar y estandarizar sus procesos de gestin, en busca de una mayor madurez organizacional, este trabajo consiste en realizar una investigacin rigurosa sobre los diferentes elementos que se deben tener en cuenta en el desarrollo de un proyecto de software, con el fin de conocerlos y aplicarlos en la implementacin de aplicaciones.

3. GESTION DE UN PROYECTO DE SOFTWARE

La gestin de proyectos es un proceso continuo. Este proceso requiere de una estrategia global, apoyada por herramientas de trabajo que incrementen la productividad. El propsito de planificar y controlar es proveer una propuesta uniforme para el desarrollo y la administracin de los proyectos. Los planes deben apoyar los niveles estratgicos, tcticos y operacionales de las organizaciones con el fin de alcanzar las metas corporativas de largo, mediano y corto plazo. A travs del ciclo de vida de un proyecto, se conforman dos categoras de actividades a realizar y que se encuentran directamente relacionadas: las actividades de gestin y las actividades de desarrollo del sistema. Las actividades de gestin son aquellas relacionadas con la administracin delas organizaciones, personas, sistemas y procedimientos comprometidos en el proceso de planificacin y construccin del sistema. La planificacin del proyecto, junto con las actividades de control, es iterada para cada fase del proyecto y proveen de la estrategia de administracin con la cual las actividades de desarrollo del sistema son estimadas, programadas y ejecutadas. Las actividades de desarrollo del sistema se centran en el desarrollo mismo. Las metodologas de desarrollo estn tpicamente organizadas en distintas fases, agrupadas en reas funcionales de estudio, diseo y construccin, basadas en una estructura de particin del trabajo. La administracin y planificacin de proyectos requiere de la integracin de dos modelos implcitos de trabajo, usualmente no reconocidos: el modelo de administracin y el modelo de desarrollo.

El Modelo de Administracin El modelo de administracin identifica las relacionas entre la administracinmisma y los procesos de planificacin y control,incluye a organizaciones, sistemas y personas.

Ilustracin 1 Modelo de Administracin

Los administradores de proyectos de software son responsables por laplanificacin del desarrollo, supervisin de las tareas y aseguramiento de queel trabajo es realizado de acuerdo a los estndares, a tiempo y dentro delpresupuesto. Una buena administracin no garantiza el xito, pero una malaadministracin generalmente conlleva a un producto de Software terminadotarde, que excede el costo estimado y caro de mantener. La administracin de proyectos proyectostradicionales en que: informticos se diferencia de los

El producto es intangible. El administrador de proyectos (o Jefe deproyecto) depende de la documentacin disponible para revisar elprogreso. No se tiene an comprensin acabada del proceso de desarrollo deSoftware. Los modelos que se utilizan son slo una simplificacin paraayudar a la comprensin. Los proyectos grandes son nicos en su tipo. La experiencia histricacasi no existe para grandes proyectos.

Actividades de Administracin Las actividades de administracin son: Generacin de la propuesta. Estimacin de costos. Planificacin y creacin de itinerario. Monitoreo y revisiones. Seleccin y evaluacin de personal. Informes y presentaciones.

La planificacin y el control del proyecto son una parte integral del procesode administracin. Una planificacin eficaz puede tomar desde un 15% hastaun 25% del total del esfuerzo del proyecto. La planificacin ocurrecontinuamente durante el proyecto, desde la concepcin inicial hasta laproduccin final. Su principal objetivo es lograr la construccin dentro de un programa y presupuesto progresivamente refinados, para lo cual se realizanlas siguientes funciones: Asignacin de Recursos. Estimacin y Planificacin detallada del Proyecto. Revisiones del Proyecto. Control de Calidad.

Fases y Revisiones Administrativas Los proyectos bien definidos estn compuestos por fases, cada una de lascuales tienen objetivos especficos y salidas mensurables. Las revisionesadministrativas conducen el proyecto, ya que en ellas se debe decidir si: Detener y posponer el proyecto. Cambiar el mbito, objetivos y restricciones (y s fueranecesario, repetir toda o parte de la fase en cuestin). Aprobar los puntos de calidad / Hitos. Pasar a la siguiente fase. Una de estas decisiones debe ser tomada durante cada sesin de revisin. Cada sesin debiera incluir a todos los participantes del proyecto: operadoresde computadoras, auditores, equipo tcnico, personal de desarrollo y elusuario final. El modelo de administracin se sustenta en organizaciones y procesos. Sistos son utilizados apropiadamente, es posible incrementar la productividadde los administradores y del personal que compone las organizaciones.

Organizaciones Las formas de organizar un proyecto son: Grupos de direccin del proyecto. Grupo de evaluacin especial de las tareas. Grupos de proyectos. Procesos Algunos de los procesos en un proyecto son: Anlisis y administracin de la cartera de proyectos. Control de cambios (diseo y produccin). Evaluacin y determinacin del tamao de los proyectos. Anlisis y administracin del riesgo. Autorizacin del proyecto. Anlisis costo / beneficio, Clculo de Tasa Interna de Retorno, Flujode Caja, Valor Presente Neto. Evaluacin de la Calidad (SQA) La cartera de aplicaciones Una cartera de aplicaciones es un inventario de todos los proyectosplanificados y actuales, incluyendo todos los tipos de proyectos, es decir: Nuevos desarrollos (utilizando herramientas tradicionales oprototipos). Mejoras. Soporte a produccin. Mantenimiento. Instalaciones de paquetes.

Esta cartera debe ser administrada eficientemente para alcanzar las metasestablecidas por la organizacin en el mbito ejecutivo. Los administradores clave, asignados por el nivel ejecutivo, conforman el grupo deadministradores de la cartera (GAC). El procedimiento de autorizacin delproyecto provee de informacin decisional detallada que permite al GACdirigir el contenido de esta cartera. Los cambios en la cartera se originan a partir de cambios en el negocio o amedida que las distintas etapas del trabajo se van complementando. Normalmente se agregan nuevos recursos, o bien cambian las prioridades paradar cumplimiento a las necesidades surgidas por los cambios.

Organizacin para proyectos de software Dentro de las organizaciones se pueden identificar estructuras formales einformales. Una Estructura Organizacional tpica es aquella que identifica losniveles jerrquicos estratgicos, tcticos y operacionales.Independiente de su tipo, una estructura Organizacional debe ser losuficientemente flexible como para permitir un apropiado flujo deinformacin a los distintos niveles, facilitando los requerimientos de reportes,comunicacin y toma de decisiones. Los equipos de trabajo deben ser pequeos, con no ms de ocho personas entotal. Si el proyecto es muy grande, ste deber ser dividido en subsistemas,teniendo especial cuidado en definir adecuadamente la interfaz entre ellos.Los beneficios de trabajar con un equipo pequeo son el que permite: Definir estndares de calidad. Que los miembros del equipo trabajen en conjunto. Programar las tareas sin afectar el ego. Que todos puedan conocer el trabajo del otro. La comunicacin es ms rpida y eficiente. Se crean decomunicacin simples. Se establecen lazos afectivos que fortalecen la creatividad.

canales

4. DESCRIBA DOS METRICAS Y ELABORE UN EJEMPLO 4.1 Metricas De Proceso Las mtricas del proceso se recopilan de todos los proyectos y durante un largo perodo de tiempo. Su intento es proporcionar indicadores que lleven a mejoras de los procesos de software a largo plazo. Un indicador es una mtrica o una combinacin de mtricas que proporcionan una visin profunda del proceso del software, del proyecto de software o del producto en si. La medicin del proceso implica las mediciones de las actividades relacionadas con el software siendo algunos de sus atributos tpicos el esfuerzo, el coste y los defectos encontrados. Las mtricas permiten tener una visin profunda del proceso de software que ayudar a tomar decisiones ms fundamentadas, ayudan a analizar el trabajo desarrollado, conocer si se ha mejorado o no con respecto a proyectos anteriores, ayudan a detectar reas con problemas para poder remediarlos a tiempo y a realizar mejores estimaciones. Para mejorar un proceso se deben medir los atributos del mismo, desarrollar mtricas de acuerdo a estos atributos y utilizarlas para proporcionar indicadores que conduzcan la mejora del proceso. Los errores detectados antes de la entrega

del software, la productividad, recursos y tiempo consumido y ajuste con la planificacin son algunos de los resultados que pueden medirse en el proceso, as como las tareas especficas de la ingeniera del software. Las mtricas del proceso se caracterizan por: El control y ejecucin del proyecto. Medicin de tiempos del anlisis, diseo, implementacin, implantacin y postimplantacin. Medicin de las pruebas (errores, cubrimiento, resultado en nmero de defectos y nmero de xito). Medicin de la transformacin o evolucin del producto.

Estas mtricas evalan el proceso de fabricacin del producto correspondiente. Algunos ejemplo clsicos de este tipo de mtricas son el tiempo de desarrollo del producto, el esfuerzo que conlleva dicho desarrollo, el nmero y tipo de recursos empleados (personas, mquinas,), el coste del proceso, etc. El tiempo requerido para completar un proceso en particular (tiempo total del proyecto, por ingeniero, por actividad, etc) es un indicador de la mantenibilidad del sistema a tener en cuenta. Aunque no se puede generalizar, cuanto mayor es el tiempo total y por ingeniero para desarrollar un sistema mayor ser su complejidad y por lo tanto ms difcil ser de mantener. De la misma manera, cuantos mayores sean los costes requeridos para un proceso en particular (esfuerzo en personas-da, costes de viajes, recursos de hardware), menor ser la mantenibilidad del sistema. Adems, de estas, el nmero de defectos descubiertos durante la fase de pruebas y las mtricas relacionadas. Defectos descubiertos durante las pruebas El nmero de defectos encontrados durante la fase de pruebas una vez que el cdigo est integrado est correlacionado positivamente con el nmero de defectos del software que se encontrarn durante la explotacin del mismo. Un gran nmero de defectos durante las pruebas indica que durante la fase de desarrollo se han cometido muchos errores, y, salvo un gran esfuerzo en la fase de pruebas, parte de estos errores se arrastrarn hasta que el sistema est en explotacin. Mtricas relacionadas con las reparaciones de procesos

Una posible manera de medir la mantenibilidad de un software durante su proceso de construccin es medir la frecuencia de fallos debidos a efectos laterales producidos despus de una modificacin (X):

siendo A el nmero de fallos debidos a efectos laterales detectados y corregidos y B= nmero total de fallos corregidos. Cuanto mayor sea X es predecible que ms difcil ser de mantener en el futuro el sistema. 4.2 Metricas Del Producto La Calidad del Software es el cumplimiento de los requisitos de funcionalidad y desempeo explcitamente establecidos, de los estndares de desarrollo explcitamente documentados y de las caractersticas implcitas que se esperan de todo software desarrollado profesionalmente. Con esta definicin se destacan tres puntos importantes: 1. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia con estos requisitos es una falta de calidad. 2. Los estndares especificados definen un conjunto de criterios de desarrollo que guan la ingeniera del software. Si no se siguen los criterios, el resultado ser, casi seguramente, la falta de calidad. 3. A menudo se soslaya un conjunto de requisitos implcitos. Si el software cumple con sus requisitos explcitos pero no con los implcitos, la calidad del software estar en duda.

Factores de Calidad de McCall Estos factores se dividen en dos grupos muy importantes: 1. Los que se miden directamente. 2. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos factores los cuales se concentran en tres aspectos importantes de un producto de software: sus caractersticas operativas, su capacidad para experimentar cambios y su capacidad para adaptarse a nuevos entornos.

Correccin: Grado en que cumple el programa con su especificacin y satisface los objetivos que propuso el cliente. Confiabilidad: Grado en que se esperara que un programa desempee su funcin con la precisin requerida. Eficiencia: Cantidad de cdigo y de RR. De cmputo necesarios para que un programa realice su funcin. Integridad: Grado de control sobre el acceso al S/W o los datos por parte de personas no autorizadas. Facilidad de uso: Esfuerzo necesario para prender, operar y preparar los datos de entrada de un programa e interpretar la salida. Facilidad de mantenimiento: Esfuerzo necesario para localizar y corregir un error en un programa. Flexibilidad: Esfuerzo necesario para modificar un programa en operacin. Facilidad de prueba: Esfuerzo que demanda probar un programa con el fin de asegurar que realiza su funcin. Portabilidad: Esfuerzo necesario para transferir el programa de un entrono de hardware o software a otro. Facilidad de reutilizacin: grado en que un programa puede reutilizarse en otras aplicaciones. Interoperabilidad: Esfuerzo necesario para acoplar un sistema con otro.

Muchas de estas mtricas solo se miden subjetivamente.

Factores de calidad del estndar ISO 9126 Se desarroll como un intento por identificar los atributos de calidad para el software de computadora. El estndar identifica 6 puntos: Funcionalidad Confiabilidad Facilidad de uso Eficiencia Facilidad de mantenimiento Portabilidad El reto de las mtricas del producto El peligro de tratar de encontrar medidas que caractericen tantos atributos diferentes es que inevitablemente las medidas tienen que satisfacer objetivos que entran en conflicto entre s. Esto se opone a la teora de que cada medicin debe ser representativa. Aunque la afirmacin de Fenton es correcta, muchas personas argumentan que la medicin del producto realizada durante las primeras etapas del proceso de software proporciona a los ingenieros un mecanismo consistente y objetivo para evaluar la calidad.

Principios de medicin Roche sugiere un proceso de medicin al que caracterizan cinco actividades: Formulacin. Derivacin de medidas y mtricas apropiadas para la representacin del software que se considera. Recoleccin. Mecanismo con que se acumulan los datos necesarios para derivar las mtricas formuladas. Anlisis. Clculo de las mtricas y la aplicacin de herramientas matemticas. Interpretacin. Evaluacin de las mtricas en un esfuerzo por conocer mejor la calidad de la representacin.

Retroalimentacin. Recomendaciones derivadas de la interpretacin de las mtricas del producto transmitidas al equipo del software.

Existen principios que son representativos de muchos otros que podran proponerse para caracterizar y validar las mtricas: Una mtrica debe tener propiedades matemticas deseables. Cuado una mtrica representa una caracterstica de software que aumenta cuando se presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el valor de la mtrica debe aumentar o disminuir en el mismo sentido. Cada mtrica debe validarse empricamente en una amplia variedad de contextos antes de publicarse o aplicarse a la toma de decisiones.

Medicin del Software Orientado a Objetos El paradigma objetivo/pregunta/mtrica (OPM) desarrollado por Basili y Weiss es considerado una tcnica para identificar significativa mtricas las cuales son aplicables en cualquier parte del proceso de software; destaca la necesidad de: 1. Establecer un objetivo de medicin que sea especfico para la actividad del proceso o las caractersticas del producto que se est evaluando. 2. Definir un conjunto de preguntas que deben responderse con el fin de alcanzar el objeto. 3. Identificar mtricas bien formadas que ayuden a responder esas preguntas. Los atributos de las mtricas efectivas del software Ejiogu define un conjunto de atributos que toda mtrica efectiva del software debe abarcar: Simples y calculable Consistentes y objetivas Consistentes en el uso de unidades y dimensiones Independientes del lenguaje de programacin Mecanismos efectivos para la retroalimentacin de alta calidad

Panorama de las mtricas del producto

Mtricas para el modelo de anlisis Incluyen aspectos como: Funcionalidad entregada Tamao del sistema Calidad de la especificacin

Mtricas para el modelo de diseo Mtricas arquitectnicas Mtricas al nivel de componente Mtricas de diseo de la interfaz Mtricas especializadas en diseo orientado a objetos

Mtricas para el cdigo fuente, se usan para evaluar su complejidad, adems la facilidad con que se mantiene y prueba. Mtricas de Halstead Mtricas de complejidad Mtricas de longitud

Mtricas para pruebas, ayudan a disear casos de prueba efectivos y evaluar la eficacia de las pruebas. Mtricas de cobertura de instrucciones y ramas Mtricas relacionadas con los defectos Efectividad de la prueba Mtricas en el proceso

En muchos modelos las mtricas de un modelo pueden aplicarse en actividades posteriores a la ingeniera del software.

Mtricas para el modelo de anlisis Mtricas basadas en la funcin La mtrica de punto de funcin (PF) es para medir la funcionalidad que entrega un sistema. Se usa para: 1. estimar el costo o el esfuerzo requerido para disear, codificar y probar el software 2. predecir el nmero de errores que se encontrarn durante la prueba

3. pronosticar el nmero de componentes, de lneas de cdigo proyectadas, o ambas, en el sistema implementado. Los valores del dominio de la informacin se definen de la siguiente manera: Nmero de entradas externas (EE). Nmero de salidas externas (SE) Nmero de consultas externas (CE) Nmero de archivos lgicos internos (ALI) Nmero de archivos de interfaz externos (AIE)

Mtricas para el modelo de diseo Mtricas del diseo arquitectnico Consideradas mtricas de caja negra ya que no requieren ningn conocimien- to del funcionamiento interno de un componente de software en particular. Card y Glass definen tres medidas de la complejidad del diseo del software: Complejidad Estructural en el caso de arquitecturas jerrquicas Complejidad de datos indica complejidad de la interfaz interna de un mdulo Complejidad del sistema es la suma de las complejidades estructural y de datos.

Mtricas para el diseo orientado a objetos Whitmire describe nueve caractersticas distintivas y mensurables de un Dis- eo OO: Tamao Complejidad Acoplamiento Suficiencia Grado de avance Cohesin Primitivismo Similitud Volatilidad

Mtricas para el cdigo fuente Ests mtricas asignadas como cuantitativas por Halstead, se derivan despus de que se ha generado el cdigo o se estima una vez que el diseo est completo.

5. DESCRIBA DOS TECNICAS DE ESTIMACDION Y ELABORE UN EJEMPLO 5.1 Estimacin Basada en Puntos de Funcin de Albrecht. El objetivo de esta tcnica es medir la cantidad de funcionalidad a partir de la especificacin de un sistema, con independencia de la tecnologa con la que pudiera ser desarrollado. Lo primero es calcular los puntos de funcin (PF) sin ajustar para lo cual que se requiere determinar: Tipos de funcin de datos Ficheros Lgicos Internos(ILF) Ficheros de Interfaces Externos(EIF) Tipos de Funciones de Transacciones Entradas Externas(EI) Salidas Externas(EO) Consultas Externas(EQ)

Al identificar estos elementos se les clasifican de complejidad alta, media, baja y se le asigna un peso. Luego se calculan los Puntos Funcionales sin ajustar sumando las cantidades de cada tipo de objeto multiplicadas por su ponderacin. Luego se calculan los puntos funcionales ajustados multiplicndolos por un factor de ajuste que se calculan tomando en cuentas 14 factores de complejidad tcnica. Estos factores son valorados en una escala de 0 a 5. La valoracin de estos factores puede generar una variacin de ms menos 35%.

Algunos problemas con esta tcnica Subjetividad en el factor tecnologa y en los pesos. Uso temprano, se necesita una especificacin completa del sistema. Su clculo no puede automatizarse completamente depende del juicio experto. No son independientes de las metodologas de anlisis y diseo usadas. No son sufrientemente tempranos para la gestin de proyectos ya que cuando se dispone de los elementos para calcularlos se ha invertido entre el 15 y el 40% del esfuerzo .

5.2 Estimacin LDC Las LDC miden en forma directa el tamao del producto de software. Se calculan contando las instrucciones de cdigo fuente de cada elemento del producto de software excluyendo, generalmente, los comentarios. Antes de adoptar esta mtrica,la organizacin debe definirla en forma exhaustiva. Esta definicin debe respetarse, ya que podra atentar a la integridad de los datos del proyecto. Cuando se utiliza LDC como variable de estimacin, la descomposicin funcional es absolutamente esencial, a menudo se lleva hasta considerables niveles de detalle. Usando PF es la variable de estimacin es menos detallado. Tambin, debe de tenerse en cuenta que mientras que LDC se estima directamente, PF se determina indirectamente mediante la estimacin del nmero de entradas, salidas, archivos de datos y peticiones externas, entre otras. Entonces, se calcula el valor esperado de LDC. El valor esperado para la variable de estimacin, E, se obtiene como una medida ponderada de las estimaciones LDC ptima (a), ms probable (m) y pesimista (b). Esta tcnica trata de definir el tiempo y el costo del proyecto en base a la cantidad de lneas de cdigo se tienen que escribir, cual es el costo por lnea y cuantas lneas de cdigo desarrollamos en un mes.
Con este cuadro se calculan los LDC:

Se coloca en la columna de "Bsf/lnea" el precio de cada lnea en cada mdulo, esto generalmente se realiza basados en los costos de proyectos anteriores. La siguiente casilla pertenece a cuantas lneas se pueden escribir en un mes. La casilla de "Coste", nos permite tener el clculo de cuanto costara cada mdulo,esto se obtiene de multiplicar la columna de "Bsf. por lnea" con la de "Esperada". Los meses se calculan multiplicando las "Lneas al mes" por "Esperada" Al totalizarlas columnas calculadas tendramos en la columna de "Esperada" la cantidad de lneas que se escribiran, el la de "Coste" el costo estimado del proyecto y en la de "Meses" los meses que demorara el proyecto.

Pasos para el clculo LDC: Descomponer el problema Estimar valores para columnas de lineas de cdigo a escribir Calcular columna esperada

Proceso de Estimacin

Ventajas de LDC Facil de calcular Base de clculo de modelos de estimacion de costos de software existentes Existencia de literatura al respecto Facil de automatizar Desventajas de LDC Dependencia del lenguaje de programacin Dificil de estimar en etapas tempranas del proyecto Dificil de calcular en lenguajes de programacin no procedurales 6. DESCRIBA LOS RIESGOS DE UN PROYECTO Y ELABORE UN EJEMPLO El riesgo de un proyecto de software siempre implica dos caractersticas:

Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100 por 100 de probabilidad'. Prdida: si el riesgo se convierte en una realidad, ocurrirn consecuencias no deseadas o prdidas. Cuando se analizan los riesgos es importante cuantificar el nivel de incertidumbre y el grado de prdidas asociado con cada riesgo. Para hacerlo, se consideran categoras de riesgos. Los riesgos del proyecto amenazan al plan del proyecto; es decir, si los riesgos del proyecto se hacen realidad, es probable que la planificacin temporal del proyecto se retrase y que los costes aumenten. Los riesgos del proyecto identifican los problemas potenciales de presupuesto, planificacin temporal, personal (asignacin y organizacin), recursos, cliente y requisitos y su impacto en un proyecto de software. Los riesgos tcnicos amenazan la calidad y la planificacintemporal del software que hay que producir. Siun riesgo tcnico se convierte en realidad, la implementacinpuede llegar a ser difcil o imposible. Losriesgos tcnicos identifican problemas potenciales dediseo, implementacin, de interfaz, verificacin y demantenimiento. Adems, las ambigedades de especificaciones,incertidumbre tcnica, tcnicas anticuadasy las tecnologas punta son tambin factores de riesgo. Los riesgos tcnicos ocurren porque el problema es ms difcil de resolver de lo que pensbamos. Los riesgos del negocio amenazan la viabilidad delsoftware a construir. Los riesgos del negocio a menudoponen en peligro el proyecto o el producto. Los candidatospara los 3 principales riesgos del negocio son:

Construir un producto o sistema excelente que noquiere nadie en realidad (riesgo de mercado) Construirun producto que no encaja en la estrategia comercialgeneral de la compaa (riesgo estratgico) Construir un producto que el departamento de ventas no sabe cmo vender perder el apoyo de una gestin experta debido a cambios de enfoque o a cambios de personal (riesgo de direccin)

perder presupuesto o personal asignado (riesgos de presupuesto)

Otra categorizacin general de los riesgos ha sido propuesta por Charette. Los riesgos conocidos son todos aquellos que se pueden descubrir despus de una cuidadosa evaluacin del plan del proyecto, del entorno tcnico y comercial en el que se desarrolla el proyecto y otras fuentes de informacin fiables (Por ejemplo: fechas de entrega poco realistas, falta de especificacin de requisitos o de mbito del software, o un entorno pobre de desarrollo). Los riesgos predecibles se extrapolan de la experiencia en proyectos anteriores (por ejemplo: cambio de personal, mala comunicacin con el cliente, disminucin del esfuerzo del personal a medida que atienden peticiones de mantenimiento). Los riesgos impredecibles son el comodn de la baraja. Pueden ocurrir, pero son extremadamente difciles de identificar por adelantado. La identificacin del riesgo es un intento sistemtico para especificar las amenazas al plan del proyecto (estimaciones, planificacin temporal, carga de recursos, etc.). Identificando los riesgos conocidos y predecibles, el gestor del proyecto da un paso adelante para evitarlos cuando sea posible y controlarlos cuando sea necesario. Existen dos tipos diferenciados de riesgos, riesgosgenricos y riesgos especficos del producto. Los riesgos genricos son una amenaza potencialpara todos los proyectos de software. Los riesgos especficos de producto slo los pueden identificar los que tienen una clara visin de la tecnologa, el personal y el entorno especfico del proyecto en cuestin. Para identificar los riesgos especficos del producto, se examinan el plan del proyecto y la declaracin del mbito del software y se desarrolla una respuesta a la siguiente pregunta: Qu caractersticas especiales de este producto pueden estar amenazadas por nuestro plan del proyecto? Un mtodo para identificar riesgos es crear una lista de comprobacin de elementos de riesgo. La lista de comprobacin se puede utilizar para identificar riesgos y se centra en un subconjunto de riesgos conocidos y predecibles en las siguientes subcategoras genricas: Tamao del producto: riesgos asociados con el tamao general del software a construir o a modificar. Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestin o por el mercado. Caractersticas del cliente: riesgos asociados con la sofisticacin del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.

Definicin del proceso: riesgos asociados con el grado de definicin del proceso del software y su seguimiento por la organizacin de desarrollo. Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construccin del producto. Tecnologa a construir: riesgos asociados con la complejidad del sistema a construir y la tecnologa punta que contiene el sistema. Tamao y experiencia de la plantilla: riesgos asociados con la experiencia tcnica y de proyectos de los ingenieros del software que van a realizar el trabajo. La lista de comprobacin de elementos de riesgo puede organizarse de diferentes maneras. Se pueden responder a cuestiones relevantes de cada uno de los temas apuntados anteriormente para cada proyecto de software. Las respuestas a estas preguntas permiten al planificador del proyecto estimar el impacto del riesgo. Un formato diferente de lista de comprobacin de elementos de riesgo contiene simplemente las caractersticas relevantes para cada subcategora genrica. Finalmente, se lista un conjunto de componentes y controladores del riesgo junto con sus probabilidades de aparicin.

Ilustracin 2Ejemplo de evaluacin global del riesgo de un proyecto

7. ELABORE LA PLANIFICACIN DE UN PROYECTO DE SOFTWARE A) Aqu se describe y define las principales componentes de la planeacin en el desarrollo de un sistema informtico: QUE ES UN PROYECTO DE SISTEMA O SOFTWARE. ? Es el Proceso de gestin para la creacin de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimacin, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimacin, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen tcnicas tiles para la estimacin de costes de tiempo. Y dado que la estimacin es la base de todas las dems actividades de planificacin del proyecto y sirve como gua para una buena Ingeniera Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento tcnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificacin. El Tamao del proyecto es otro factor importante que puede afectar la precisin de las estimaciones. A medida que el tamao aumenta, crece rpidamente la interdependencia entre varios elementos del Software. La disponibilidad de informacin Histrica es otro elemento que determina el riesgo de la estimacin. OBJETIVOS DE LA PLANIFICACIN DEL PROYECTO. El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse. El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a estimaciones razonables. ACTIVIDADES ASOCIADAS AL PROYECTO DE SOFTWARE. mbito del Software. Es la primera actividad de llevada a cabo durante la planificacin del proyecto de Software. En esta etapa se deben evaluar la funcin y el rendimiento que se asignaron al Software durante la Ingeniera del Sistema de Computadora para establecer un mbito de proyecto que no sea ambiguo, e incomprensible para directivos y tcnicos. Describe la funcin, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalan las funciones del mbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimacin. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes. El mbito se define como un pre-requisito para la estimacin y existen algunos elementos que se debe tomar en cuenta como es: o La Obtencin de la Informacin necesaria para el software. Para esto el analista y el cliente se renen sobre las expectativas del proyecto y se ponen de acuerdo en los puntos de inters para su desarrollo. RECURSOS. La Segunda tarea de la planificacin del desarrollo de Software es la estimacin de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirmide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirmide se encuentran los Componentes reutilizables. Y en la

parte ms alta de la pirmide se encuentra el recurso primario, las personas (el recurso humano). Cada recurso queda especificado mediante cuatro caractersticas: Descripcin del Recurso. Informes de disponibilidad. Fecha cronolgica en la que se requiere el recurso. Tiempo durante el que ser aplicado el recurso.

Recursos Humanos. La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado despus de hacer una estimacin del esfuerzo de desarrollo (por ejemplo personas mes o personas aos), y seleccionar la posicin dentro de la organizacin y la especialidad que desempeara cada profesional. Recursos o componentes de software reutilizables. Cualquier estudio sobre recursos de software estara incompleto sin estudiar la reutilizacin, esto es la creacin y la reutilizacin de bloques de construccin de Software. Tales bloques se deben establecer en catlogos para una consulta ms fcil, estandarizarse para una fcil aplicacin y validarse para la tambin fcil integracin. El Autor Bennatan sugiere cuatro categoras de recursos de software que se deberan tener en cuenta a medida que se avanza con la planificacin: o o o o Componentes ya desarrollados. Componentes ya experimentados. Componentes con experiencia Parcial. Componentes nuevos.

Recursos de entorno. El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniera de Software, incorpora Hardware y Software. El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena prctica de la Ingeniera del Software, un planificador de proyectos debe determinar la ventana temporal requerida para el Hardware y el Software, y verificar que estos recursos estn disponibles. Muchas veces el desarrollo de las pruebas de validacin de un proyecto de software para la composicin automatizada puede necesitar un compositor de fotografas en algn punto durante el desarrollo. Cada elemento de hardware debe ser especificado por el planificador del Proyecto de Software.

 ESTIMACIN DEL PROYECTO DE SOFTWARE. En el principio el costo del software constitua un pequeo porcentaje del costo total de los sistemas basados en computadoras. Hoy en da el software es el elemento ms caro de la mayora de los sistemas informticos. Un gran error en la estimacin del costo puede ser lo que marque la diferencia entre beneficios y perdidas, la estimacin del costo y del esfuerzo del software nunca ser una ciencia exacta, son demasiadas las variables: humanas, tcnicas, de entorno, polticas, que pueden afectar el costo final del software y el esfuerzo aplicado para desarrollarlo. Para realizar estimaciones seguras de costos y esfuerzos tienen varias opciones posibles: Deje la estimacin para mas adelante (obviamente podemos realizar una estimacin al cien por cien fiable despus de haber terminado el proyecto. Base las estimaciones en proyectos similares ya terminados. Utilice tcnicas de descomposicin relativamente sencillas para generar las estimaciones de costos y esfuerzo del proyecto. Desarrolle un modelo emprico para l clculo de costos y esfuerzos del Software. Desdichadamente la primera opcin, aunque atractiva no es prctica. La Segunda opcin puede funcionar razonablemente bien si el proyecto actual es bastante similar a los esfuerzos pasados y si otras influencias del proyecto son similares. Las opciones restantes son mtodos viables para la estimacin del proyecto de software. Desde el punto de vista ideal, se deben aplicar conjuntamente las tcnicas indicadas usando cada una de ellas como comprobacin de las otras. Antes de hacer una estimacin, el planificador del proyecto debe comprender el mbito del software a construir y generar una estimacin de su tamao. Estimacin basada en el Proceso. Es la tcnica ms comn para estimar un proyecto es basar la estimacin en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeo de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimacin de cada tarea. Al igual que las tcnicas basadas en problemas, la estimacin basada en el proceso comienza en una delineacin de las funciones del software obtenidas a partir del mbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como ultimo paso se calculan los costos y el esfuerzo de cada funcin y la actividad del proceso de software. DIFERENTES MODELOS DE ESTIMACIN. Existen diferentes modelos de estimacin como son:

Los Modelos Empricos: Donde los datos que soportan la mayora de los modelos de estimacin obtienen una muestra limitada de proyectos. Por est razn, el modelo de estimacin no es adecuado para todas las clases de software y en todos los entornos de desarrollo. Por lo tanto los resultados obtenidos de dichos modelos se deben utilizar con prudencia. El Modelo COCOMO. Barry Boehm, en su libro clsico sobre economa de la Ingeniera del Software, introduce una jerarqua de modelos de estimacin de Software con el nombre de COCOMO, por su nombre en Ingles (Constructive, Cost, Model) modelo constructivo de costos. La jerarqua de modelos de Boehm est constituida por los siguientes: o Modelo I. El Modelo COCOMO bsico calcula el esfuerzo y el costo del desarrollo de Software en funcin del tamao del programa, expresado en las lneas estimadas. o Modelo II. El Modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costos que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. o Modelo III. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin del impacto de los conductores de costos en cada caso (anlisis, diseo, etc.) del proceso de ingeniera de Software.

Herramientas Automticas De Estimacin. Las herramientas automticas de estimacin permiten al planificador estimar costos y esfuerzos, as como llevar a cabo anlisis del tipo, que pasa si, con importantes variables del proyecto, tales como la fecha de entrega o la seleccin del personal. Aunque existen muchas herramientas automticas de estimacin, todas exhiben las mismas caractersticas generales y todas requieren de una o ms clases de datos. A partir de estos datos, el modelo implementado por la herramienta automtica de estimacin proporciona estimaciones del esfuerzo requerido para llevar a cabo el proyecto, los costos, la carga de personal, la duracin, y en algunos casos la planificacin temporal de desarrollo y riesgos asociados. En resumen el planificador del Proyecto de Software tiene que estimar tres cosas antes de que comience el proyecto: cuanto durara, cuanto esfuerzo requerir y cuanta gente estar implicada. Adems el planificador debe

predecir los recursos de hardware y software que va a requerir y el riesgo implicado. Para obtener estimaciones exactas para un proyecto, generalmente se utilizan al menos dos de las tres tcnicas referidas anteriormente. Mediante la comparacin y la conciliacin de las estimaciones obtenidas con las diferentes tcnicas, el planificador puede obtener una estimacin ms exacta. La estimacin del proyecto de software nunca ser una ciencia exacta, pero la combinacin de buenos datos histricos y tcnicas puede mejorar la precisin de la estimacin. B) Aqu se define y describe un ejemplo de planeacin de un proyecto informtico: Planificacin de Proyectos: Gestin del Videoclub - mbito Funcionamiento habitual. Todas las pelculas que pertenecen al videoclub se tienen que haber registrado en la base de datos para poder ser alquiladas. Todas las personas que quieran alquilar alguna pelcula del videoclub tiene que ser socio. El sistema tendr que gestionar las pelculas que han sido alquiladas, pudiendo saber quin las ha alquilado y por cuanto tiempo. Se pedir al sistema cada mes un listado de socios con todos sus datos, si tiene deudas pendientes y el historial de alquiler de pelculas en el videoclub, tanto mensual como total. Tambin se pedir al sistema otro listado de pelculas alquiladas, con datos sobre su frecuencia de alquiler. Funciones importantes. Registro de pelculas Registro de socios Gestin del alquiler Listados Rendimiento y restricciones: Habituales Fiabilidad: Habitual Interfaz con otros sistemas: Ninguno

Recursos. Recursos humanos o Programadores Registro de pelculas (junior) Registro de socios (junior)

 Gestin del alquiler (snior) Listados (snior) o Especialista Diseo de la BBDD Recursos SW reutilizables o Componentes ya desarrollados: No Aplicable o Componentes ya experimentados: Gestin de una biblioteca o Componentes experimentados parcialmente: No recomendable o Componentes nuevos: Totalmente aplicable Recursos de entorno o Entorno de desarrollo PCs en Red + Impresora Herramientas SW de Dllo + BBDD o Entorno de destino PC + Impresora Algn componente SW

Estimacin. Estimaciones sobre proyectos similares Gestin de una biblioteca o Registro de libros o Registro de clientes o Gestin del prstamo o Listados

Aplicando Actividades Estructurales. Reuniones con Cliente (1 semana) Especificacin Requisitos (2) Diseo BBDD + Revisin (2) Registro Pelculas + Pruebas (1) Registro Socios + Pruebas (1) Gestin del Alquiler + Pruebas (2) Listados + Pruebas (2) Integracin + Pruebas (1) Instalacin (0,1) Formacin (0,5) Soporte (1) Fin (0)

8. ELABORE UN ESTUDIO DE FACTIBILIDAD DEL PROYECTO Aqu se describe y define las principales componentes del estudio de factibilidad: RECONOCIMIENTO GENERAL DEL SISTEMA. Ubicacin del sistema (Organizacin, departamento, sistema) Organizacin: Objeto social, tamao, organigrama, ubicacin geogrfica, visin, misin. Sistema: Objetivos del sistema: debe reflejar la necesidad de satisfacer informacin requerida por el usuario. Delimitacin o alcance del sistema (mdulos a implementar): Define los lmites hasta los cuales se va a expandir el proyecto. Resuelve las siguientes preguntas: Qu har el sistema? Qu No har el sistema? Beneficios que traer el desarrollo del sistema. Restricciones o condiciones que tendr el sistema: a nivel tecnolgico o de funcionalidad. Definicin del sistema (Narracin). Objetivos: o Definir caractersticas y necesidades de informacin. o Identificar cada uno de los componentes, las entradas, las salidas y las relaciones entre cada uno de ellos.

RECURSOS REQUERIDOS. Objetivo: definir las caractersticas y cantidades necesarias de talento humano, recursos tcnicos y materiales, as como sus costos, necesarios para el desarrollo del proyecto. USUARIOS DEL SISTEMA. Se identifican los usuarios que utilizarn el sistema, el cargo (dentro de la organizacin) y la ubicacin geogrfica de cada uno de ellos. Usuario primario: puede definir con adecuado criterio y autoridad las caractersticas fundamentales del sistema, dado que ste hace parte de su responsabilidad. Usuarios secundarios: son ellos quienes utilizan el sistema y por lo tanto no tienen una visin global de ste, pero brindan aportes importantes a nivel de detalle en los procesos ms comnmente utilizados por ellos, especialmente en interfaces con otras aplicaciones.

BENEFICIOS ESPERADOS DEL PROYECTO

Con el fin de asegurar la viabilidad del proyecto, todos los beneficios deben ser claramente identificados. Para identificar los beneficios en aconsejable detectar los problemas del sistema actual y los costos que representan. Si el sistema propuesto elimina el problema o reduce su costo, puede decirse que se tendr un beneficio en la cantidad que en la actualidad representa dicho costo. Beneficios tangibles: son de fcil cuantificacin, generalmente estn relacionados con la reduccin de recursos o talento humano. Beneficios intangibles: no son fcilmente cuantificables y estn relacionados con elementos como el impacto sobre aspectos como Good Will o mejora en otros procesos de la organizacin.

Ejemplo de beneficios: Mejoras en la eficiencia del rea bajo estudio. Reduccin de personal. Reduccin de futuras inversiones y costos. Disponibilidad del recurso humano. Mejoras en planeacin, control y uso de recursos. Suministro oportuno de insumos para las operaciones. Cumplimiento de requerimientos gubernamentales. Toma acertada de decisiones. Disponibilidad de informacin apropiada. Aumento en la confiabilidad de la informacin. Mejor servicio al cliente externo e interno Logro de ventajas competitivas. Valor agregado a un producto de la compaa.

COSTOS DEL PROYECTO Los costos del proyecto pueden estar dados por la adquisicin o utilizacin de equipos, personal, compra de software, costos en los procedimientos para la recopilacin de informacin, preparacin de documentacin, mantenimiento de sistemas etc. Deben ser calculados para cada uno de los recursos en cada una de las etapas del ciclo de vida del sistema. Requerimiento para el clculo de la relacin: Costo/Beneficio. ANLISIS DE ALTERNATIVAS DE IMPLEMENTACIN

Es necesario evaluar cada una de las alternativas de implementacin, eligiendo una de ellas y descartando una por una las dems alternativas. Deben sustentarse las razones de cada decisin. Mejoras al sistema actual: en esencia el sistema actual se mantiene con algunas mejoras. Adquisicin de paquetes Desarrollo externo a la medida Outsourcing Desarrollo interno a la medida: realizado por analistas de la organizacin (nosotros). ANLISIS DE FACTIBILIDAD DEL SISTEMA El estudio de factibilidad se hace necesario cuando el desarrollo del sistema no tiene una justificacin econmica establecida, existe un alto riesgo tecnolgico, operativo, jurdico o no se cuenta con una alternativa clara de implementacin. Factibilidad econmica: Se debe hacer una comparacin de los costos de las posibles soluciones contra los beneficios que ofrecen, de acuerdo con lo documentado en los numerales anteriores. Debe hacerse para cada una de las alternativas de implementacin. Indicador: Relacin Costo / Beneficio (<1 Factible, >1 No factible)

Factibilidad tcnica: Se debe hacer un anlisis de la tecnologa requerida para conseguir la funcionalidad y el rendimiento del sistema propuesto, cul es el riesgo de desarrollo y cmo afectan stos elementos el costo del proyecto. Adems, se debe definir si el problema se puede resolver con los medios actualmente existentes y el grado de adaptacin de la solucin a la tecnologa con la que cuenta la organizacin. Existe la tecnologa requerida para el desarrollo del sistema? Puede la organizacin acceder a dicha tecnologa? Factibilidad operacional: Explica cmo hacer funcionar el sistema propuesto en las operaciones de la organizacin. Muestra como puede cambiar el sistema el entorno del usuario y las actividades que realiza. Comprende dos aspectos:

o Impacto sobre los usuarios: cuenta el proyecto con respaldo y compromiso verdadero, en trminos de actitud y asignacin de recursos? Consideran que el proyecto beneficia a la organizacin? Est la alta direccin comprometida? o Impacto sobre los dems sistemas de la organizacin DEFINIR EL IMPACTO SOBRE LOS PLANES GENERALES DE LA ORGANIZACIN O SOBRE SU PLANEACIN ESTRATGICA Se debe determinar cmo contribuye el sistema a: El logro de los planes del departamento. El logro de los planes especficos de la compaa. El logro de la misin organizacional. El logro de la visin organizacional.

CRONOGRAMA Se realiza con base en las etapas del ciclo de vida y bajo las restricciones de tiempo que siempre existen.

10. CONCLUSIONES

Un proyecto exitoso es aquel donde las actividades han sido especificadas en detalle, y por consiguiente, la estimacin de su duracin es tambin detallada, conduciendo a un buen plan, adems el xito de un proyecto de software no slo est asociado al cumplimiento de un compromiso o la satisfaccin de un plan de proyecto, sino tambin a las condiciones en las cuales sus participantes quedan despus que el proyecto ha terminado, tanto en trminos de su progreso laboral como del ambiente de trabajo. Las mtricas proporcionan los conocimientos necesarios para crear modelos efectivos de anlisis y diseo, un cdigo slido y pruebas exhaustivas. Las mtricas se enfocan al proceso de software en varios aspectos tales como mtricas del producto, para el modelo de anlisis, para el modelo de diseo, para el cdigo fuente, para pruebas y para mantenimiento, las cuales permiten el control de calidad en cada uno de estos procesos.

BIBLIOGRAFIA 1. Pressman, R.(2001).Ingeniera del software. Un enfoque prctico, 5a ed. McGraw-Hill 2. Steve McConnell, "Desarrollo y Gestin de Proyectos Informticos", McGraw Hill 1996 3. Ricardo Contreras, "Apuntes de clases: Ingeniera de Software", Universidad deConcepcin, 1997 4. Meli R., Santillo L. FUNCTION POINT ESTIMATION METHODS 5. Mara E Ruilova R, Mtricas del Producto para el Software (Ingeniera de software Enfoque Prctico),2008: http://techi322.files.wordpress.com/2008/08/metricas-del-producto-para-elsw.pdf 6. Miguel A Sicilia,Vernica De la Morena, Mtricas relacionadas con el proceso,2009 http://cnx.org/content/m17467/1.5/
7. Universidad Catlica UCAB. Gestin de Proyectos de Software. Estudio de

Factibilidad. https://sites.google.com/site/gpsguayana/contenido/ capitulo-iv--desarrollo-del-plan -para-proyectos/estudio-de-factibilidad 8. MEDINA, Mara. Ingeniera del Software. Planificacin del proyecto de software. 2012. http://isittla12.blogspot.com/2012/11/unidad-3planificaciondel-proyecto-de.html. 9. NOVA. Pedro. El Rincn Universitario. Anlisis y Diseo de sistemas. Planificacin de proyectos de software. 2004. http://www.e- mas.co.cl/ categoras / informtica / analisisyd.htm 10. ORTEGA, Jos. Desarrollo de proyectos de software. Divisin de ingeniera en sistemas computacionales. Tecnolgico de estudios superiores oriente del estado de Mxico. Secretaria de educacin de Mxico. La paz. Mxico. 2011 11. VARAS, Marcela. Gestin de Proyectos de Desarrollo de Software. Departamento de Ingeniera Informtica y Ciencias de la Computacin. Facultad de Ingeniera. Universidad de Concepcin. 2000