jueves, 19 de enero de 2012

5) UML, una vision moderna del problema de modelamineto generico

Introducción         Unified Modeling Languaje

UML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. Otros métodos de modelaje como OMT (Object Modeling Technique) o Booch sí definen procesos concretos. En UML los procesos de desarrollo son diferentes según los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicación en tiempo real, que el proceso de desarrollo de una aplicación orientada a gestión, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las faces del proceso. El método del UML recomienda utilizar los procesos que otras metodologías tienen definidos.

Los Inicios

A partir del año 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa común, Rational Software Corporation, y comienzan a unificar sus dos métodos. Un año más tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versión del UML. A finales de ese mismo año, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se añade al grupo.

Como objetivos principales de la consecución de un nuevo método que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente:
  • El método debía ser capaz de modelar no sólo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientación a objetos (OO).
  • Crear un lenguaje para modelado utilizable a la vez por máquinas y por personas.
  • Establecer un acoplamiento explícito de los conceptos y los artefactos ejecutables.
  • Manejar los problemas típicos de los sistemas complejos de misión crítica.
Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los métodos más utilizados sigan evolucionando en conjunto y no por separado. Y además, unificar las perspectivas entre diferentes tipos de sistemas (no sólo software, sino también en el ámbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de análisis, el diseño, la implementación y los conceptos internos de la OO.




                                                    Introduccion de UML 01
 


Modelado de objetos

En la especificación del UML podemos comprobar que una de las partes que lo componen es un metamodelo formal. Un metamodelo es un modelo que define el lenguaje para expresar otros modelos. Un modelo en OO es una abstracción cerrada semánticamente de un sistema y un sistema es una colección de unidades conectadas que son organizadas para realizar un propósito específico. Un sistema puede ser descripto por uno o más modelos, posiblemente desde distintos puntos de vista.

Una parte del UML define, entonces, una abstracción con significado de un lenguaje para expresar otros modelos (es decir, otras abstracciones de un sistema, o conjunto de unidades conectadas que se organizan para conseguir un propósito). Lo que en principio puede parecer complicado no lo es tanto si pensamos que uno de los objetivos del UML es llegar a convertirse en una manera de definir modelos, no sólo establecer una forma de modelo, de esta forma simplemente estamos diciendo que UML, además, define un lenguaje con el que podemos abstraer cualquier tipo de modelo.

El UML es una técnica de modelado de objetos y como tal supone una abstracción de un sistema para llegar a construirlo en términos concretos. El modelado no es más que la construcción de un modelo a partir de una especificación.

Un modelo es una abstracción de algo, que se elabora para comprender ese algo antes de construirlo. El modelo omite detalles que no resultan esenciales para la comprensión del original y por lo tanto facilita dicha comprensión.

Los modelos se utilizan en muchas actividades de la vida humana: antes de construir una casa el arquitecto utiliza un plano, los músicos representan la música en forma de notas musicales, los artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los óleos, etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos al fin y al cabo. La OMT, por ejemplo, intenta abstraer la realidad utilizando tres clases de modelos OO: el modelo de objetos, que describe la estructura estática; el modelo dinámico, con el que describe las relaciones temporales entre objetos; y el modelo funcional que describe las relaciones funcionales entre valores. Mediante estas tres fases de construcción de modelos, se consigue una abstracción de la realidad que tiene en sí misma información sobre las principales características de ésta.

Los modelos además, al no ser una representación que incluya todos los detalles de los originales, permiten probar más fácilmente los sistemas que modelan y determinar los errores. Según se indica en la Metodología OMT (Rumbaugh), los modelos permiten una mejor comunicación con el cliente por distintas razones:
  • Es posible enseñar al cliente una posible aproximación de lo que será el producto final.
  • Proporcionan una primera aproximación al problema que permite visualizar cómo quedará el resultado.
  • Reducen la complejidad del original en subconjuntos que son fácilmente tratables por separado.

Se consigue un modelo completo de la realidad cuando el modelo captura los aspectos importantes del problema y omite el resto. Los lenguajes de programación que estamos acostumbrados a utilizar no son adecuados para realizar modelos completos de sistemas reales porque necesitan una especificación total con detalles que no son importantes para el algoritmo que están implementando. En OMT se modela un sistema desde tres puntos de vista diferentes donde cada uno representa una parte del sistema y una unión lo describe de forma completa. En esta técnica de modelado se utilizó una aproximación al proceso de implementación de software habitual donde se utilizan estructuras de datos (modelo de objetos), las operaciones que se realizan con ellos tienen una secuencia en el tiempo (modelo dinámico) y se realiza una transformación sobre sus valores (modelo funcional).

UML utiliza parte de este planteamiento obteniendo distintos puntos de vista de la realidad que modela mediante los distintos tipos de diagramas que posee. Con la creación del UML se persigue obtener un lenguaje que sea capaz de abstraer cualquier tipo de sistema, sea informático o no, mediante los diagramas, es decir, mediante representaciones gráficas que contienen toda la información relevante del sistema. Un diagrama es una representación gráfica de una colección de elementos del modelo, que habitualmente toma forma de grafo donde los arcos que conectan sus vértices son las relaciones entre los objetos y los vértices se corresponden con los elementos del modelo. Los distintos puntos de vista de un sistema real que se quieren representar para obtener el modelo se dibuja dé forma que se resaltan los detalles necesarios para entender el sistema.

                                               
                                                Material de los diagramas que existen en UML


Artefactos para el Desarrollo de Proyectos

Un artefacto es una información que es utilizada o producida mediante un proceso de desarrollo de software. Pueden ser artefactos un modelo, una descripción o un software. Los artefactos de UML se especifican en forma de diagramas, éstos, junto con la documentación sobre el sistema constituyen los artefactos principales que el modelador puede observar.

Se necesita más de un punto de vista para llegar a representar un sistema. UML utiliza los diagramas gráficos para obtener estos distintos puntos de vista de un sistema:
  • Diagramas de Implementación.
  • Diagramas de Comportamiento o Interacción.
  • Diagramas de Casos de uso.
  • Diagramas de Clases.

Ejemplo de algunos de los diagramas que utiliza UML.
Diagramas de Implementación

Se derivan de los diagramas de proceso y módulos de la metodología de Booch, aunque presentan algunas modificaciones. Los diagramas de implementación muestran los aspectos físicos del sistema. Incluyen la estructura del código fuente y la implementación, en tiempo de implementación. Existen dos tipos:
Diagramas de componentes
Diagrama de plataformas despliegue

Diagramas de componentes

Muestra la dependencia entre los distintos componentes de software, incluyendo componentes de código fuente, binario y ejecutable. Un componente es un fragmento de código software (un fuente, binario o ejecutable) que se utiliza para mostrar dependencias en tiempo de compilación.

Diagrama de plataformas o despliegue

Muestra la configuración de los componentes hardware, los procesos, los elementos de procesamiento en tiempo de ejecución y los objetos que existen en tiempo de ejecución. En este tipo de diagramas intervienen nodos, asociaciones de comunicación, componentes dentro de los nodos y objetos que se encuentran a su vez dentro de los componentes. Un nodo es un objeto físico en tiempo de ejecución, es decir una máquina que se compone habitualmente de, por lo menos, memoria y capacidad de procesamiento, a su vez puede estar formado por otros componentes.
Diagramas de Interacción o Comportamiento

Muestran las interacciones entre objetos ocurridas en un escenario (parte) del sistema. Hay varios tipos:
Diagrama de secuencia.
Diagrama de colaboración.
Diagrama de estado.
Diagrama de actividad.

Diagrama de secuencia

Muestran las interacciones entre un conjunto de objetos, ordenadas según el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboración, es decir son instancias concretas de una clase que participa en la interacción. El objeto puede existir sólo durante la ejecución de la interacción, se puede crear o puede ser destruido durante la ejecución de la interacción. Un diagrama de secuencia representa una forma de indicar el período durante el que un objeto está desarrollando una acción directamente o a través de un procedimiento.

En este tipo de diagramas también intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operación del objeto destino. Existen distintos tipos de mensajes según cómo se producen en el tiempo: simples, síncronos, y asíncronos.

Los diagrama de secuencia permiten indicar cuál es el momento en el que se envía o se completa un mensaje mediante el tiempo de transición, que se especifica en el diagrama.

Diagrama de colaboración

        Muestra la interacción entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan información similar, pero en una forma diferente.
Formando parte de los diagramas de colaboración nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interacción, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.

Un enlace es una instancia de una asociación que conecta dos objetos de un diagrama de colaboración. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.

Los diagramas de interacción indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envío de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envían entre objetos pueden ser de distintos tipos, también según como se producen en el tiempo; existen mensajes simples, sincrónicos, balking, timeout y asíncronos. Durante la ejecución de un diagrama de colaboración se crean y destruyen objetos y enlaces.

Diagramas de actividad

Son similares a los diagramas de flujo de otras metodologías OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de acción (estados con una acción interna y una o más transiciones que suceden al finalizar esta acción, o lo que es lo mismo, un paso en la ejecución de lo que será un procedimiento) y las transiciones vienen provocadas por la finalización de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementación de un caso de uso o de un método (que tiene el mismo significado que en cualquier otra metodología OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.

Diagramas de estado

Representan la secuencia de estados por los que un objeto o una interacción entre objetos pasa durante su tiempo de vida en respuesta a estímulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una máquina de estados. Un estado en UML es cuando un objeto o una interacción satisface una condición, desarrolla alguna acción o se encuentra esperando un evento.
Cuando un objeto o una interacción pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transición, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Además una transición puede ser interna si el estado del que parte el objeto o interacción es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transición. Como en todas las metodologías OO se envían mensajes, en este caso es la acción de la que puede enviar mensajes a uno o varios objetos destino


Diagramas de Casos de Uso

Unos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interacción con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la relación y la generalización son relaciones.

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar como reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con él; un ejemplo de actor podría ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes:
  • Un actor se comunica con un caso de uso.
  • Un caso de uso extiende otro caso de uso.
  • Un caso de uso usa otro caso de uso
Diagramas de Clases

Los diagramas de clases representan un conjunto de elementos del modelo que son estáticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.
Algunos de los elementos que se pueden clasificar como estáticos son los siguientes:

Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un único paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitiéndose que un paquete contenga otro paquete.

Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, métodos, relaciones y significado. En UML una clase es una implementación de un tipo. Los componentes de una clase son:
Atributo. Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos.
Operación. También conocido como método, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza.
Las clases pueden tener varios parámetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrán definidas según sus parámetros formales. Las plantillas pueden tener especificados los valores reales para los parámetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podría aparecer su plantilla.

Relacionando con las clases nos encontramos con el término utilidad, que se corresponde con una agrupación de variables y procedimientos globales en forma de declaración de clase, también puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaración de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programación.

Metaclase: Es una clase cuyas instancias son clases. Sirven como depósito para mantener las variables de clase y proporcionan operaciones (método de clase) para inicializar estas variables. Se utilizan para construir metamodelos (modelos que se utilizan para definir otros modelos).

Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementación. Un tipo establece una especificación de comportamiento para las clases.

Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo.

Relación entre clases: Las clases se relacionan entre sí de distintas formas, que marcan los tipos de relaciones existentes:
Asociación:Es una relación que describe un conjunto de vínculos entre clases. Pueden ser binarias o n-arias, según se implican a dos clases o más. Las relaciones de asociación vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociación (existen otros tipos de roles según la relación a la que identifiquen). Indican la información más importante de las asociaciones. Es posible indicar el número de instancias de una clase que participan en una relación mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociación permiten especificar qué objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociación que determina los valores que indican cuales son los valores que se asociarán.
Una asociación se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociación.
Existe una forma especial de asociación, la agregación, que especifica una relación entre las clases donde el llamado "agregado" indica él todo y el "componente" es una parte del mismo.
Composición:
Es un tipo de agregación donde la relación de posesión es tan fuerte como para marcar otro tipo de relación. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composición, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos.
Generalización:
Cuando se establece una relación de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber más de una clase que se comporte como subclase.
Dependencia:
Una relación de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente.

Relación de Refinamiento

Es una relación entre dos elementos donde uno de ellos especifica de forma completa al otro que ya ha sido especificado con cierto detalle.

Nuevas características del UML

Además de los conceptos extraídos de métodos anteriores, se han añadido otros nuevos que vienen a suplir carencias antiguas de la metodología de modelado. Estos nuevos conceptos son los siguientes:
  • Definición de estereotipos: un estereotipo es una nueva clase de elemento de modelado que debe basarse en ciertas clases ya existentes en el metamodelo y constituye un mecanismo de extensión del modelo.
  • Responsabilidades.
  • Mecanismos de extensibilidad: estereotipos, valores etiquetados y restricciones.
  • Tareas y procesos.
  • Distribución y concurrencia (para modelar por ejemplo ActiveX/DCOM y CORBA).
  • Patrones/Colaboraciones.
  • Diagramas de actividad (para reingeniería de proceso de negocios)
  • Clara separación de tipo, clase e instancia.
  • Refinamiento (para manejar relaciones entre niveles de abstracción).
  • Interfaces y componentes.

El Proceso de Desarrollo

UML no define un proceso concreto que determine las fases de desarrollo de un sistema, las empresas pueden utilizar UML como el lenguaje para definir sus propios procesos y lo único que tendrán en común con otras organizaciones que utilicen UML serán los tipos de diagramas.

UML es un método independiente del proceso. Los procesos de desarrollo deben ser definidos dentro del contexto donde se van a implementar los sistemas.

Herramientas CASE

Rational Rose es la herramienta CASE que comercializan los desarrolladores de UML y que soporta de forma completa la especificación del UML 1.1.
Esta herramienta propone la utilización de cuatro tipos de modelo para realizar un diseño del sistema, utilizando una vista estática y otra dinámica de los modelos del sistema, uno lógico y otro físico. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del
problema y el sistema de software.

Desarrollo Iterativo

Rational Rose utiliza un proceso de desarrollo iterativo controlado (controlled iterative process development), donde el desarrollo se lleva a cabo en una secuencia de iteraciones. Cada iteración comienza con una primera aproximación del análisis, diseño e implementación para identificar los riesgos del diseño, los cuales se utilizan para conducir la iteración, primero se identifican los riesgos y después se prueba la aplicación para que éstos se hagan mínimos.
Cuando la implementación pasa todas las pruebas que se determinan en el proceso, ésta se revisa y se añaden los elementos modificados al modelo de análisis y diseño. Una vez que la actualización del modelo se ha modificado, se realiza la siguiente iteración.

Trabajo en Grupo

Rose permite que haya varias personas trabajando a la vez en el proceso iterativo controlado, para ello posibilita que cada desarrollador opere en un espacio de trabajo privado que contiene el modelo completo y tenga un control exclusivo sobre la propagación de los cambios en ese espacio de trabajo.

También es posible descomponer el modelo en unidades controladas e integrarlas con un sistema para realizar el control de proyectos que permite mantener la integridad de dichas unidades.

Generador de Código

Se puede generar código en distintos lenguajes de programación a partir de un diseño en UML.

Ingeniería Inversa

Rational Rose proporciona mecanismos para realizar la denominada Ingeniería Inversa, es decir, a partir del código de un programa, se puede obtener información sobre su diseño.



Bibliografia  



http://www.ingenierosoftware.com/analisisydiseno/uml.php

http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf 

4) Metodo de Estimación de Costos de Construcción


ESTIMACIÓN DE COSTOS


INTRODUCCION

Todo proyecto de ingeniería de software debe partir con un buen plan, pero lamentablemente, la planificación es una tarea nada trivial. Uno de los aspectos que dificultan la labor de administradores y jefes de proyecto en torno a la planificación es la difícil tarea de realizar una estimación de costos y plazos realista.
La estimación es más arte que ciencia; también es parte de la etapa de la planificación y algunas actividades de la ingeniería. La diferencia en la estimación de costos entre ingeniería de software y otras disciplinas es que en ingeniería de software lo principal para las personas es el costo; y en otras disciplinas el costo de las cosas materiales depende de la actividad.
Existen técnicas para la estimación de costos, pero para ello se requiere experiencia, acceso a una buena información histórica y coraje para confiar en medidas cuantitativas cuando todo lo que existe son datos cualitativos.
El manejador de costo principal para un proyecto de desarrollo de software es sin duda el tamaño del producto. La medida del tamaño debe ser tal que esté en relación directa con el esfuerzo de desarrollo, por lo que las métricas de tamaño tratan de considerar todos los aspectos que influyen en el costo, como tecnología, tipos de recursos y complejidad.

MÉTRICAS PARA LA PRODUCTIVIDAD Y CALIDAD DEL SOFTWARE

La medición es esencial para cualquier disciplina de ingeniería y la ingeniería de software no es una excepción.
Las métricas de software se refieren aun amplio rango de medidas para el software de computadoras dentro del contexto de la planificación del proyecto de software, las métricas de calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente afectan a la estimación de costos.
Las mediciones en el mundo físico pueden ser catalogadas en dos campos: medidas directas (por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de tornillos producidos, medida por la cuenta de los tornillos rechazados). Las métricas de software pueden ser catalogadas de forma parecida.
Se puede clasificar en:
Métricas de productividad, se centran en el rendimiento del proceso de la ingeniería de software.
Métricas de Calidad, proporcionan una indicación de cómo se ajusta el software, a los requerimientos implícitos y explícitos del cliente.
Métricas Técnicas, se centran en el carácter del software mas que en el proceso, a través del cual el software a sido desarrollado.
Métricas Orientadas al tamaño, son utilizadas para obtener medidas directas del resultado y la calidad de la ingeniería del software.
Métricas Orientadas a la Función, son medidas indirectas del software y del proceso por el cual se desarrollará; se centran en la funcionalidad o utilidad del programa (Puntos de Función)
Métricas Orientadas a la persona, consiguen información sobre la forma en que la gente desarrolla software de computadora y sobre el punto de vista humano de la efectividad de las herramientas y métodos.

ESTIMACION DEL PROYECTO DE SOFTWARE

Para realizar estimaciones seguras de coste y esfuerzo surge un numero de posible de opciones como:
Retrasar la estimación mas adelante en el proyecto (obviamente se puede hacer una estimación cien por ciento fiable después de completar el proyecto)
Utilizar "técnicas de descomposición " relativamente simples para generar las estimaciones del proyecto de software (por ej. Estimación LDC y PF)
Desarrollar un modelo empírico para el coste y el esfuerzo de software.
Adquirir una o más herramientas automáticas de estimación.
Desdichadamente la primera opción, aunque atractiva no es practica, porque las estimaciones del coste deben ser proporcionadas de antemano. Las tres opciones restantes son aproximaciones viables para la estimación del proyecto de software. Las técnicas de descomposición utilizan una aproximación de "divide y vencerás " para la estimación del proyecto de software. Los modelos de estimación empíricos pueden utilizarse para completar las técnicas de descomposición y ofrecer una aproximación de la estimación potencialmente evaluable por ella misma. Las herramientas automáticas de estimación implementan una o mas técnicas de descomposición o modelos empíricos.

MODELOS DE ESTIMACIÓN EMPÍRICA

Un modelo de estimación para el software por computadora utiliza formulas derivadas empíricamente para predecir los datos.
Los datos empíricos que soportan la mayoría de los modelos se obtienen de una muestra limitada de proyectos. Tomando en cuenta los recursos se tienen los modelos recursos y consisten en una o más ecuaciones obtenidas empíricamente que predicen el esfuerzo (personas-mes), la duración del proyecto (meses cronológicos) o otros datos pertinentes al proyecto. Según Basili describe cuatro modelos de recurso:
modelos simple-variable estáticos (ej. COCOMO), modelos multi-variables estáticos, modelos multi-dinámicos variables y modelos teóricos.

MODELO COCOMO

Barry Boehm en su libro "economía de la ingeniería de software" detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra "constructive" se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres "niveles" de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.
Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).
Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de "guías de costo" que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.
Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:
Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).
Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)
Proyecto (por ej. Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).
En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.
Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos
Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por :
Donde:
E = es el esfuerzo estimado expresado en hombres-mes
EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto
a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.
EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.
A continuación veremos los coeficientes para el modelo intermedio que depende de modo de desarrollo:

MODO DE DESARROLLO
A
b
c
d
Organic 3.2 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 2.8 1.20 2.5 0.32



 Estimacion de Proyecto




EVALUACIÓN DE MODELOS DE ESTIMACIÓN
DE COSTOS DE SOFTWARE
(SLIM,COCOMO,PUNTOS DE FUNCIÓN)

A continuación se presenta un relato de una evaluación de modelos que estiman costos para el desarrollo software. Para esta evaluación se preciso los datos(información) de 15 empresas (proyectos), información que ayudaron a evaluar cuatro de los más populares modelos algoritmicos usados para estimar costos. Estos son: SLIM, COCOMO, PUNTOS DE FUNCIÓN y ESTIMACS.




INTRODUCCIÓN
Los investigadores han expresado su interés en la estimación de costos para el desarrollo de software, esta preocupación se ha hecho presente a medida que avanza el desarrollo de proyectos de software. Principalmente, el interés de comparar resultados usando diferentes métricas para cálculos de productividad.
Para ello se presentan tres preguntas a responder:
  • ¿Son los modelos de estimación de costo dl software realmente generalizables para ambientes diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables para el ambiente típico de procesamiento de datos para los negocios?
  • ¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así, ¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?
Para un mejor entendimiento, primeramente se presenta una explicación de cómo se seleccionó los cuatro modelos para la evaluación, seguidamente se procederá a con una breve descripción de los modelos, para continuar con la descripción del ambiente en el cual los datos se originaron. Luego se describirá los métodos de recolección-datos y análisis-datos, para entrar directamente a explicar los resultados y finalmente dar conclusiones.




ACERCA DE LOS MODELOS.
Selección de los Modelos.

Un repaso de la literatura revela una interesante diferencia entre modelos de estimación, esta se refiere a modelos que usan SLOC(líneas de código) como principal entrada y aquellos que no las utilizan. SLOC fue seleccionado rápidamente, como métrica por los investigadores sin ninguna duda, por su cuantificabilidad y objetividad.
El siguiente paso para escoger modelos fue el de buscar en la literatura actual, modelos que se centren en SLOC, de esta búsqueda se selecciono dos: modelo COCOMO y Algoritmo SLIM. Igualmente se procedió a la búsqueda de modelos no-SLOC, solo se encontraron dos: Método de Puntos de Función, desarrollado por Alan Albrecht y el modelo ESTIMACS, desarrollado por Howard Rubin.

Descripción de los MODELOS

Continuando, se presenta una breve descripción de los cuatro modelos mencionados anteriormente.
  • Algoritmo SLIM.
Software Lipe Cycle Management, SLIM fue desarrollado en el año 1970 por Larry Putman. Depende de una estimación SLOC para el tamaño general del proyecto, se modifica a través del uso de la curva de Raleigh para producir la estimación del esfuerzo.
El usuario puede influenciar la forma de la curva a través de dos parámetros, la pendiente inicial de la curva y el factor de productividad. Puesto que estos son números dimensionales el usuario tiene dos maneras de ingresar los datos, en la primera el usuario puede calibrar el modelo de ingreso de datos o bien respondes a las 22 preguntas que el SLIM puede proporcionar recomendando un PF y MBL, el segundo método fue el escogido para esta investigación debido a la ausencia de un banco de datos que pueda calibrarse, lo que reflejaría con precisión la experiencia de los usuarios.
  • Modelo COCOMO.
Constructive Cost Model, fué desarrollado por Barry Boehm de TRW, publicado en 1981. Basado en el análisis de 63 proyectos de software desarrollados. Boehm desarrollo un modelo (de tres niveles: básico, intermedio y avanzado) fácil de entender que predice la duración del proyecto, así como el esfuerzo para la realización de este.
El modelo detallado COCOMO(utilizado en esta evaluación) es muy similar al modelo intermedio excepto que el proyecto es dividido en cuatro fases: diseño del producto, diseño detallado, codificación de pruebas, integración-pruebas.
  • Modelo PUNTOS de FUNCIÓN.
El modelo Puntos de función fue realizado por Alam Albrecht y fue publicado en 1979. Albrecht estaba interesado en el problema general de medición de productividad en sistemas y creo un método como alternativa a la estimación SLOC. Este método captura los el numero de transacciones de entrada y el numero de reportes.
El modelo Puntos de Función tiene ventajas sobre la cuantificación de las linees de código (SLOC) como: es posible estimarlas en el ciclo de vida, alrededor del tiempo de definición de requerimientos para el documento y pueden ser estimadas por un miembro del proyecto relativamente no técnico.
Existen dos pasos que involucrados para el conteo de puntos de función:
  • el primero contar las funciones de usuario (tipos de entradas externas e internas, archivos lógicos internos, de interface externos y tipos externos de encuesta)
  • el segundo, ajustar la complejidad de los procesos.
  • Modelo ESTIMACS.
El modelo Estimacs fue desarrollado por Howard Rubin. Este modelo no requiere como entrada el numero de SLOC, tiene 25 preguntas, cuyas respuestas le sirven de datos de entrada.

ACERCA DE LOS DATOS.

Base de Datos del Proyecto, los proyectos seleccionados para la evaluación poseían dos atributos en común: eran de un tamaño mediano y el estaban disponibles para completar la recolección de datos.



METODOLOGÍA.




  • Procedimiento para Recolectar los datos. Para cada proyecto hubo una junta con el manejador de proyectos que tenia que llenar las formas especificas. Los propósitos eran:
  • Discutir cada pregunta para asegurarse que se entendiera el concepto y se respondiera consistentemente
    Resaltar la importancia de la participación del manejador del proyecto en el trabajo.






  • Procedimiento para Analizar los datos, Una vez llenadas las Formas se revisó la consistencia del contenido. Se presento redundancia de muchas preguntas en los modelos, a excepción de las preguntas del modelo Punto de Función con relación a las del modelo ESTIMACS. Lo que significo que era posible asegurar una respuesta acerca del conocimiento del personal del proyecto para el modelo COCOMO, ya que presento consistencia con preguntas similares del modelo SLIM.
  • Análisis del error, Para tener un margen de error entre una estimación, se cálculo el error relativo relacionando el esfuerzo estimado con el esfuerzo verdadero realizado en el proyecto. Usando dos exámenes para evaluar el proyecto:

    • El de cálculo de error relativo(MRE).
    • El método de regresión.


    RESULTADOS.
    Los resultados que se presentan, son los encontrados después de que cada modelo fue corrido en los 15 proyectos seleccionados.




  • Resultados de SLIM, fue corrido usando los parámetros por defecto del modelo, los usuarios respondieron a las 22 preguntas del SLIM.
  • Este modelo no tiene una vía buena para el cálculo del error relativo(MRE), obteniendo un porcentaje de error promedio de 772%, con el pequeño error de 21%.
  • Resultados de COCOMO, los resultados para las tres versiones COCOMO en el cálculo del MRE fueron pobres, obteniéndose un promedio de 601% con el error más bajo de 83%.
  • Resultados de Puntos de Función, el promedio MRE es de 102,74%.
  • Resultados ESTIMACS, presento un promedio del 85%.      
  • CONCLUSIONES.
  • Después de examinar cada modelo independientemente, se procedió a responder las tres preguntas formuladas al comenzar con esta evaluación:¿Son los modelos de estimación de costo del software realmente generalizables para ambientes diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables para el ambiente típico de procesamiento de datos para los negocios?
    Los modelos desarrollados en ambientes diferentes no trabajan muy bien, cuando se desea acoplarlos. Los porcentajes de error calculados usando la formula de error relativo están en el rango de 85 a 775%. Esta variación se debe la diferencia de ambientes.
    ¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así, ¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?
    En términos de los resultados de error relativo los modelos que no usan líneas de código como entrada fueron mejores. Pero en términos de los resultados de regresión están altamente correlacionados.
    En conclusión: los modelos, a pesar de su perfeccionamiento sobre diferentes entradas para la estimación de esfuerzo, no modelan de manera adecuada los factores que afectan la productividad. Es necesario hacer mas investigaciones acerca de cómo medir todos los factores que afectan los sistemas de productividad profesional, si la profesión es encontrarse con los cambios del futuro.
    Resolución del ejemplo 3
    Sistema Colaborativo, para calcular el esfuerzo requerido se tiene:
    E = 3.6 * ( EDSI ) ^ 1.20
    Donde 3.6 y 1.20 son constantes para lo que son programas de sistema y EDSI son las líneas de código
    De donde en el caso del sistema colaborativo el esfuerzo será:
    E = 3.6 * ( 11.038 ) ^ 1.20
    E = 64
    Donde (11.038) significa 11038 líneas de código fuente, y esto se conoce por la notación KDSI
    Nota.- Los estimadores de esfuerzo excluyen los costos de planeación, instalación y entrenamiento, así como los costos de secretarias, personal de limpieza y operadores del equipo de computo.
    El tiempo de desarrollo para un programa, según lo sugiere Boehm, es de:
    TDEV = 2.5 * ( E ) ^ 0.32
    En el caso del sistema colaborativo el tiempo necesario se calculara de la siguiente manera:
    TDEV = 2.5 * ( 64 ) ^ 0.32
    TDEV = 9.5
    Dado el numero total de meses programador de un proyecto y el tiempo nominal de desarrollo requeridos, el nivel promedio de contratación puede obtenerse mediante una simple división:
    PG = E / TDEV
    Donde PG son el numero de programadores requeridos.
    De donde para el sistema colaborativo el numero de programadores requeridos será:
    PG = 64 / 9.5
    PG = 6.73
    PG = 7
    Ahora para la distribución del tiempo total de desarrollo del sistema colaborativo, para cada fase se tiene que:
    40 % Análisis y Diseño
    20% Codificación
    40% Pruebas
    De donde se tendrá que el tiempo para cada fase será:
    4 Meses Análisis y Diseño
    5 Meses Pruebas
    3 Meses Codificación
    Ahora se verá lo que son los costos, estos serán:



  • Costos de Desarrollo,
  • Costos de Equipamiento,
  • Costos de Mantenimiento.



  • Costo de Desarrollo



  • Personal: Analistas y Programadores 20900$
  • Analistas ( 400$ / mes, durante 9.5 meses): 2 analistas
    Programadores (200$/mes, durante 9.5 meses): 7 programadores




  • Pruebas ( 500 $ / mes, durante 5 meses ) 2500 $



  • Alquiler Equipo ( 100 $ / mes, durante 9.5 meses ) 6650 $



  • Material: 200$



  • Suministros de Computadora
  • Material de Escritorio
  • TOTAL COSTO DESARROLLO: 30250 $



  • Costo Equipamiento



  • 25 Maquinas Terminales 23750 $
  • Características:



  • Tarjeta madre QDI Brillant I BX AGP ATX
  • Procesador Intel Pentium II 350 Mhz (Original)
  • Cache en tarjeta de 512 Kb
  • 32 Mb. DIMM de memoria RAM PC-100
  • Disco duro de 6.4 Gb. (Western Digital)
  • Monitor de 14” SVGA (Samsung SyncMaster 400b)
  • Tarjeta de Video de alta velocidad de 4 Mb.
  • Tarjeta de Red FAST 100Mb. PCI PnP
  • Precio Unitario de 950 $



  • 1 Maquina Servidora 1300 $
  • Características:



  • Tarjeta madre marca SOYO - 5BT
  • Procesador Intel Pentium II 400 Mhz (Original)
  • Cache en tarjeta de 512 Kb
  • 64 Mb. DIMM de memoria RAM PC-100
  • Disco duro de 8.4 Gb. (Western Digital)
  • Monitor de 14” SVGA (Samsung SyncMaster 400b)
  • Tarjeta de Video de alta velocidad de 4 Mb.
  • Tarjeta de Red FAST 100Mb. PCI PnP



  • Conexión Red: 2600 $



  • Topología Estrella
  • Cable UTP (200 mts., 5$/metro)
  • 2 HUB's ( 450 $ precio unitario )
  • Accesorios de Red
  • TOTAL COSTO EQUIPAMIENTO 27650 $



  • Costo de Mantenimiento (Anual) 500 $
  • TOTAL COSTO MANTENIMIENTO 500 $

    TOTAL COSTO SISTEMA COLABORATIVO 58400 $
    RESULTADOS DEL MODELO DE IMPLEMENTACION INTERMEDIO COCOMO 81

    Los resultados obtenidos con el calculador MODELO INTERMEDIO COCOMO 81 son los siguientes:
    Esfuerzo = 64 personas / mes
    Tiempo = 9.5 meses
    Cantidad de líneas de código en ambos casos es:
    11038 líneas
    Este número de líneas fueron determinadas en el anterior trabajo.
    COCOMO
    Haciendo comparaciones con el COCOMO realizado manualmente se tiene las siguientes observaciones:



  • En cuanto al esfuerzo se tiene una variación aceptable de 2.16 personas/mes
  • Tiempo se tiene una discrepancia de 0.98 meses
  • Nuestra opinión sería que los resultados obtenidos no están muy lejos; y que son aceptables y también si se alteraría algún parámetro del Calculador entonces se llegaría a una aproximación todavía mas aceptable; pero esto sería ya forzando el resultado.
    En su libro: Model and Metrics for Software Management and Engineering
    18
    " ESTIMACIÓN DE COSTOS "
    E = a (EDSI)h * (EAF)
    TDEV = c E d
    PG = E / TDEV



     

    COCOMO II     Teoría y ejercicio práctico. Método de estimación de costos de Software.



     

    Humor: Hitler se entera que no usaron un modelo cocomo de estimación de costos en su proyecto


    Bibliografia  

    http://ingenieriasoftware1.blogspot.es/

    http://html.rincondelvago.com/estimacion-de-costos.html

    3) Tendencias Actuales de Construcción de SI


    Las organizaciones están viviendo un cambio en el paradigma de desarrollo de sus sistemas de información: de los datos a los procesos. La finalidad que se persigue con ello es enfatizar los procesos de negocio para conseguir arquitecturas más ágiles y flexibles, adaptables a los continuos cambios que se producen en los mercados en los que las organizaciones desarrollan su negocio. El objetivo es independizar la gestión de los procesos de negocio de las aplicaciones, para que cualquier modificación en la lógica de negocio no afecte al código de los aplicaciones.

    Para ello se utilizaran sistemas de gestión de procesos de negocio (BPMS). Es una revolución similar a la que se produjo al aislar la gestión de los datos de las aplicaciones, con la llegada de las bases de datos y el modelo relacional. Este cambio de arquitectura, orientada a los procesos, se consigue más fácilmente si la organización dispone ya de una arquitectura orientada a servicios que además le permitirá exteriorizar su funcionalidad en forma de servicios Web. Los procesos de negocio combinarán estos servicios mediante orquestación y coreografías. En este trabajo se aborda la descripción general de los BPMS,
    estudiando su relación con la integración de aplicaciones y arquitecturas de servicios. Palabras clave: Procesos de negocio, BPM, workflow, organizaciones, arquitecturas de servicios, servicios Web, sistemas de información.

    En su todavía corta historia, la tecnología de la información aplicada a las organizaciones ha vivido dos grandes hitos: el primero vino dado por el desarrollo del modelo relacional de bases de datos realizado por Codd en 1970 y el segundo, por la llegada de las soluciones de planificación de recursos o ERPs (Enterprise Resource Planning) en siglas inglesas. Antes del modelo relacional las aplicaciones definían y gestionaban su propio modelo de datos almacenando la información en ficheros externos o en soluciones más sofisticadas que utilizaban modelos de datos diversos como los jerárquicos o en red. Esta situación provocaba que diferentes aplicaciones dentro de la misma organización tuvieran replicada una gran cantidad de información con los problemas derivados de consumo de recursos, inconsistencias, repetición de tareas, falta de seguridad, etc. Con la llegada del modelo relacional y de los sistemas de gestión de bases de datos relacionales se comenzó un proceso de extracción de los datos de las aplicaciones hacia las bases de datos relacionales. Las organizaciones empezaron a diseñar un modelo de datos global para toda la organización sobre el cual se construían las aplicaciones, que acudían al gestor de bases de datos para el tratamiento de los datos.
    Un sistema de información es el conjunto de recursos que permiten recoger, gestionar, controlar y difundir la información de toda una empresa u organización
    .
    Desde los años setenta, los sistemas de bases de datos han ido reemplazando a los sistemas de ficheros en los sistemas de información de las empresas. Al mismo tiempo, se ha ido reconociendo la gran importancia que tienen los datos que éstas manejan, convirtiéndose en uno de sus recursos más importantes. Esto ha hecho que muchas empresas tengan departamentos que se encarguen de gestionar toda su información, que estará almacenada en una base de datos. Aparecen los papeles de administrador de datos y administrador de la base de datos, que son las personas encargadas de supervisar y controlar todas las actividades relacionadas con los datos de la empresa y con el ciclo de vida de las aplicaciones de bases de datos, respectivamente.

    Un sistema de información está formado por los siguientes componentes:

        * La base de datos.
        * El SGBD.
        * Los programas de aplicación.
        * Los dispositivos físicos (ordenadores, dispositivos de almacenamiento, etc.).
        * El personal que utiliza y que desarrolla el sistema.

    La base de datos es un componente fundamental de un sistema de información. El ciclo de vida de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de vida de desarrollo del software. Las etapas típicas del ciclo de vida de desarrollo del software son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. Este ciclo de vida hace énfasis en la identificación de las funciones que realiza la empresa y en el desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el ciclo de vida de desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo. Por esta razón, el análisis estructurado hace énfasis en los diagramas de flujo de datos, siguiendo el movimiento de los datos a través de una secuencia de transformaciones, y refinando éstas a través de una serie de niveles. Lo mismo ocurre en el diseño estructurado, que ve a un sistema como una función que se descompone sucesivamente en niveles o subfunciones.

    Concentrándose en las funciones se infravaloran los datos y, en especial, la estructura de los datos que son manipulados por las funciones. El resultado es que estos sistemas tienen valor durante poco tiempo en relación con las necesidades de los usuarios a largo plazo. Esto sucede debido a que al poco tiempo de haber instalado un sistema, las funciones implementadas son en realidad un subconjunto de las funciones que los usuarios realmente desean. Casi inmediatamente, los usuarios descubren una gran variedad de servicios adicionales que quisieran incorporar al sistema. Estas necesidades causan problemas a los sistemas obtenidos con un diseño orientado a funciones, puesto que este diseño puede requerir una revisión importante para acomodar las funciones adicionales

    En contraste, el enfoque orientado a datos centra el foco de atención en el análisis de los datos utilizados por las funciones. Esto tiene dos ventajas. La primera es que los datos son una parte considerablemente más estable que las funciones. La segunda ventaja es que la propia estructura de un esquema de base de datos requiere de un análisis sofisticado de los datos y de sus relaciones. Una vez que se haya construido un esquema para la base de datos que sea lógico, podrían diseñarse tantas funciones como fuera necesario para sacar provecho del mismo. Sin embargo, sin un esquema tal, la base de datos sólo podría ser útil para una única aplicación. Por lo tanto, el enfoque orientado a funciones puede ser bueno para el desarrollo a corto plazo, pero pierde su valor real a largo plazo. Usando un enfoque orientado a datos, los datos pasan a ser los cimientos sobre los cuales se puede construir una gran variedad de funciones diferentes.

    Este cambio supuso un gran avance tanto para la gestión de los datos de las organizaciones como para el desarrollo de aplicaciones informáticas. La organización disponía de un punto central de gestión de los datos, lo que permitía un mayor control en la seguridad de los mismos, una mayor eficiencia en su tratamiento y la eliminación de inconsistencias, entre otras ventajas. Las aplicaciones eran más fáciles de diseñar y más ligeras al no ser necesarios muchos módulos encargado
    s de la gestión de datos. Las aplicaciones se comunicaban y se comunican actualmente, con la base de datos mediante un lenguaje de consulta y de definición de datos estandarizado, el SQL (Structured Query Language), lo que permite incluso no depender de un gestor de base de datos concreto, pudiendo crear una capa de interfaz entre la aplicación y la base de datos que posibilita migrar de gestor de base de datos con un esfuerzo mínimo.

    El desgaje de los datos de las aplicaciones dio lugar a las arquitecturas de software de dos capas, una para las aplicaciones que definían las operaciones a realizar y provocaban consultas y modificaciones sobre los modelos de datos, y otra formada por la o las bases de datos que daban soporte a las aplicaciones. Posteriormente, al separarse los sistemas que interactúan con el usuario/cliente de las aplicaciones surgieron modelos de tres capas. La tercera capa es la capa de presentación, que se encarga de obtener y presentar los datos al usuario.

    Estos modelos se han ido sofisticando, especialmente con la generalización del uso en
    los negocios de Internet y se han construido aplicaciones distribuidas que separan claramente el sistema de interacción con el usuario vía web, el sistema denominado front-end, y los sistemas corporativos que establecen las reglas de negocio, denominados back-end, y que son los que acceden al almacén de datos.

    El modelo centralizado de datos ha influido poderosamente tanto en las organizaciones como en la tecnología de la información.

    Alrededor de este almacén de datos corporativo han surgido tecnologías como el Datawarehouse o la minería de datos (Data Minig) que pretenden explotar la gran cantidad de datos que tienen las organizaciones, extrayendo información significativa que aporte conocimiento al negocio a través de la determinación de factores ocultos, tendencias y correlaciones, ayudando en la toma de decisiones y por tanto proporcionando una ventaja competitiva.

    Durante los años 70 y 80 las organizaciones fueron construyendo sus modelos de datos relacionales, levantando el gran almacén de datos que las aplicaciones alimentaban, aplicaciones que habitualmente se diseñaban y desarrollaban por áreas de negocio. Así manufacturación, planificación, almacenaje, contabilidad, finanzas, ventas, marketing o recursos humanos tenían sus propias aplicaciones. Esto permitía una gran personalización y adaptación de las aplicaciones a cada una de las áreas de negocio pero provocaba una falta de integración de todos los datos generados dentro de la organización. No había un sistema de información que supusiese la integración de todas las aplicaciones de la organización y que aprovechase la sinergia que de ello se podía derivar. Este es el objetivo de los sistemas ERP, que aparecen para dar ese paso de integración, constituyéndose como una solución global para el sistema de información de la empresa. Por supuesto esta solución global se apoyaba en un modelo global de datos y gracias a la estandarización de SQL ni siquiera dependía de un determinado gestor de base de datos, permitiendo la adaptación del ERP a los diversos gestores existentes en el mercado.

    Los sistemas ERP son paquetes de software compuestos de varios módulos, tales como recursos humanos, ventas, finanzas, producción, etc. posibilitando la integración de datos en la organización a través de los procesos de negocios de la organización. Estos paquetes pueden y deben ser personalizados. Las aplicaciones ERP son servicios y por tanto siempre conllevan un proceso de adaptación tanto de la aplicación a la organización como viceversa, de la organización a la aplicación. El término sistema
    ERP hace referencia tanto al proceso de integración de datos entre los procesos de negocio, como al software utilizado en el proceso de integración.

    Los sistemas ERP tienen su origen en los sistemas MRP (Material Requirement Planning) (Napier 2003), de planificación de recursos materiales de los años 70, pero con la gran diferencia de que los ERP pueden manejar en principio cualquier tipo de negocio, no solo relacionados con la manufacturación. Durante los 90, y acelerándose a medida que se acercaba el año 2000, los sistemas ERP llegaron a ser el estándar de facto para el reemplazamiento de las aplicaciones heredadas en las grandes organizaciones. El inconveniente de los sistemas ERP es su elevado coste de implantación, por lo que las pequeñas y medianas organizaciones no adoptan habitualmente estos sistemas, debido a que casi nunca compensa su gran coste con los beneficios reportados por la migración a este tipo de sistemas.

    Muy relacionados con los sistemas ERP, e incluso en muchas ocasiones integrados en estos, aparecen habitualmente sistemas específicos de gestión de ciertos procesos fundamentales de la empresa, ejemplo de los cuales son los sistemas de gestión de la cadena de suministros (SCM, Supply Chain Management), o sistemas de gestión de relaciones con el cliente (CRM, Customer Relationship Management). SCM es el término utilizado para describir el conjunto de procesos de producción y logística cuyo objetivo final es la entrega de un producto a un cliente. Esto quiere decir, que la cadena de suministro incluye todas las actividades asociadas, desde la obtención de materiales para la transformación del producto, hasta su colocación en el mercado. Con la ayuda de estas herramientas SCM, las organizaciones disponen de una mayor visibilidad en la totalidad de la cadena de suministro, lo que les permite reducir los gastos, mejorar la eficiencia operacional y responder con mayor rapidez a la demanda del cliente. Un sistema SCM es una parte importante de un sistema ERP especialmente para compañías de manufacturación.

    Los sistemas CRM son herramientas de ayuda a la venta, que contemplan globalmente la relación Organización-Cliente, y que permiten planificar adecuadamente las gestiones de marketing y comerciales con clientes. Utilizan la tecnología para ayudar en la gestión de su base de clientes, conectando bases de datos diferentes, tales como cifras de ventas, actividades de call center, incisión web e incisión móvil para conseguir información relevante acerca de las interacciones con los clientes.
    Es interesante resaltar que, frente a los ERP que parten de las aplicaciones básicas de las áreas de negocio, permitiendo su integración, para conseguir que el sistema de información adopte una visión global de la organización, los SCM o los CRM propician la integración gracias a afrontar un proceso básico en la actividad de la empresa: la
    cadena de suministro en el caso de los primeros o el tratamiento de los clientes en el segundo.



                                                 Sistema de informacion ERP, CRM, SCM


    Bibliografia  

    http://www.ucm.es/info/multidoc/multidoc/revista/num9/prensa/jime-chacon.htm
    http://www3.unileon.es/pecvnia/pecvnia02/02_129_158.pdf




    2) Modelo de Ciclo de Vida de SI

    Tal como ya hemos mencionado, las etapas principales a realizar en cualquier ciclo de vida son:

    1. Análisis: Construye un modelo de los requisitos
    2. Diseño: A partir del modelo de análisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario.
    3. Codificación: Construye el sistema. La salida de esta fase es código ejecutable.
    4. Pruebas: Se comprueba que se cumplen criterios de corrección y calidad.
    5. Mantenimiento: En esta fase, que tiene lugar después de la entrega se asegura que el sistema siga funcionando y adaptándose a nuevos requisitos.
    Las etapas constan de tareas. La documentación es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida según se muestra en la figura



    Etapa genérica
     
    \includegraphics[]{c1_cv_7.eps}

    Algunos autores dividen la fase del diseño en dos partes: Diseño global o arquitectónico y diseño detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentación y se planifica la integración. En el detallado para cada módulo se refina el diseño, se definen los requisitos del módulo y su documentación.
    Las formas de organizar y estructurar la secuencia de ejecución de las tareas en las diferentes fases de cada uno de los métodos puede dar lugar a un tipo de ciclo de vida diferente. Los principales ciclos de vida que se van a presentar a continuación realizan estas tareas. Cada uno de ellos tiene sus ventajas e inconvenientes.


    Ciclos de vida en cascada

    El ciclo de vida inicialmente propuesto por Royce en 1970, fue adaptado para el software a partir de ciclos de vida de otras ramas de la ingeniería. Es el primero de los propuestos y el más ampliamente seguido por las organizaciones (se estima que el 90% de los sistemas han sido desarrollados así). La estructura se muestra en la figura


    Ciclo de vida en cascada
    \includegraphics[]{c1_cv_1.eps}

     Descripción

    Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseño, lo cual significa que se harán los cambios necesarios en la codificación y se tendrán que realizar de nuevo las pruebas, es decir, si se tiene que volver a una de las etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas.
    Después de cada etapa se realiza una revisión para comprobar si se puede pasar a la siguiente.
    Trabaja en base a documentos, es decir, la entrada y la salida de cada fase es un tipo de documento específico. Idealmente, cada fase podría hacerla un equipo diferente gracias a la documentación generada entre las fases. Los documentos son:

    • Análisis: Toma como entrada una descripción en lenguaje natural de lo que quiere el cliente. Produce el S.R.D. (Software Requirements Document).
    • Diseño: Su entrada es el S.R.D. Produce el S.D.D. (Software Design Document)
    • Codificación: A partir del S.D.D. produce módulos. En esta fase se hacen también pruebas de unidad.
    • Pruebas: A partir de los módulos probados se realiza la integración y pruebas de todo el sistema. El resultado de las pruebas es el producto final listo para entregar.

    Ventajas


    • La planificación es sencilla.
    • La calidad del producto resultante es alta.
    • Permite trabajar con personal poco cualificado.

    Inconvenientes


    • Lo peor es la necesidad de tener todos los requisitos al principio. Lo normal es que el cliente no tenga perfectamente definidas las especificaciones del sistema, o puede ser que surjan necesidades imprevistas.
    • Si se han cometido errores en una fase es difícil volver atrás.
    • No se tiene el producto hasta el final, esto quiere decir que:
      • Si se comete un error en la fase de análisis no lo descubrimos hasta la entrega, con el consiguiente gasto inútil de recursos.
      • El cliente no verá resultados hasta el final, con lo que puede impacientarse .
    • No se tienen indicadores fiables del progreso del trabajo (síndrome del 90%)
    • Es comparativamente más lento que los demás y el coste es mayor también.

    Tipos de proyectos para los que es adecuado


    • Aquellos para los que se dispone de todas las especificaciones desde el principio, por ejemplo, los de reingeniería.
    • Se está desarrollando un tipo de producto que no es novedoso.
    • Proyectos complejos que se entienden bien desde el principio.
    Como el modelo en cascada ha sido muy popular ha generado algunas variantes. Ahora veremos algunas.


     Ciclo de vida en V

    Propuesto por Alan Davis, tiene las mismas fases que el anterior pero se considera el nivel de abstracción de cada una. Una fase además de utilizarse como entrada para la siguiente, sirve para validar o verificar otras fases posteriores. Su estructura está representada en la figura

    Ciclo de vida en V
    \includegraphics[]{c1_cv_2.eps}

    Ciclo de vida tipo sashimi

    Según el modelo en cascada puro una fase solo puede empezar cuando ha terminado la anterior. En este caso sin embargo, se permite un solapamiento entre fases. Por ejemplo, sin tener terminado del todo el diseño se comienza a implementar. El nombre ``sashimi'' deriva del modo del estilo de presentación de rodajas de pescado crudo en Japón. Una ventaja de este modelo es que no necesita generar tanta documentación como el ciclo de vida en cascada puro debido a la continuidad del mismo personal entre fases. Los problemas planteados son:

    • Es aún más difícil controlar el progreso del proyecto debido a que los finales de fase ya no son un punto de referencia claro.
    • Al hacer cosas en paralelo si hay problemas de comunicación pueden surgir inconsistencias.
    La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnología y el tipo de ciclo de vida. El diseño arquitectónico es el de alto nivel, el detallado el de bajo nivel. En la figura se ha representado la estructura del ciclo de vida sashimi.


     
    Ciclo de vida sashimi
    \includegraphics[]{c1_cv_5.eps}


    Ciclo de vida en cascada con subproyectos

    Si una vez que se ha llegado al diseño arquitectónico, se comprueba que el sistema se divide en varios subsistemas independientes entre sí, sería razonable suponer que a partir de ese punto cada uno se puede desarrollar por separado y en consecuencia en paralelo con los demás. Cada uno tendrá seguramente fechas de terminación distintas. Una vez que han terminado todos se integran y se prueba el sistema en su conjunto. La ventaja es que se puede tener a más gente trabajando en paralelo de forma eficiente. El riesgo es que existan interdependencias entre los subproyectos.


    Ciclo de vida en cascada incremental

    En este caso se va creando el sistema añadiendo pequeñas funcionalidades. Cada uno de los pequeños incrementos es parecido a lo que ocurre dentro de la fase de mantenimiento. La ventaja de este método es que no es necesario tener todos los requisitos en un principio. El inconveniente es que los errores en la detección de requisitos se encuentran tarde.
    Hay dos partes en el ciclo de vida, similares al anterior. Por un lado está el análisis y el diseño global. Por otra parte están los pequeños incrementos, con las fases de diseño detallado, codificación y mantenimiento. En la figura se puede ver su estructura.


    Cascada incremental
    \includegraphics[]{c1_cv_4.eps}


    Ciclo de vida en cascada con reducción de riesgos

    Como se ha comentado anteriormente, uno de los problemas del ciclo de vida en cascada es que si se entienden mal los requisitos esto sólo se descubrirá cuando se entregue el producto. Para evitar este problema se puede hacer un desarrollo iterativo durante las fases de análisis y diseño global. Esto consistiría en:

    1. Preguntar al usuario.
    2. Hacer el diseño global que se desprende del punto 1.
    3. Hacer un prototipo de interfaz de usuario, entrevistas con los usuarios, etc y volver con ello al punto 1 para identificar más requisitos o corregir malentendidos.
    El resto es igual al ciclo de vida en cascada.


    Modelo de ciclo de vida en espiral

    Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseño, errores en la implementación, etc. Un representación típica de esta estructura se muestra en la figura


    Ciclo de vida en espiral
    \includegraphics[]{c1_cv_3.eps}

    En cada iteración Boehm recomienda recopilar la siguiente lista de informaciones:

    • Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc.
    • Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista
      • Características del producto.
      • Formas de gestionar el proyecto.
    • Restricciones:
      • Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc.
      • Desde el punto de vista organizativo: Coste, tiempo, personal, etc.
    • Riesgos: Lista de riesgos identificados.
    • Resolución de riesgos: La técnica más usada es la construcción de prototipos.
    • Resultados: Son lo que realmente ha ocurrido después de la resolución de riesgos.
    • Planes: Lo que se va a hacer en la siguiente fase.
    • Compromiso: Decisiones de gestión sobre como continuar.
    Al terminar una iteración se comprueba que lo que se ha hecho efectivamente cumple con los requisitos establecidos, también se verifica que funciona correctamente. El propio cliente evalúa el producto. No existe una diferencia muy clara entre cuando termina el proyecto y cuando empieza la fase de mantenimiento. Cuando hay que hacer un cambio, este puede consistir en un nuevo ciclo.

    Ventajas


    • No necesita una definición completa de los requisitos para empezar a funcionar.
    • Al entregar productos desde el final de la primera iteración es más fácil validar los requisitos.
    • El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteración (las anteriores iteraciones están bien).
    • El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

    Inconvenientes


    • Es difícil evaluar los riesgos.
    • Necesita de la participación continua por parte del cliente.
    • Cuando se subcontrata hay que producir previamente una especificación completa de lo que se necesita, y esto lleva tiempo.

    Dónde es adecuado


    • Sistemas de gran tamaño.
    • Proyectos donde sea importante el factor riesgo.
    • Cuando no sea posible definir al principio todos los requisitos.

    Ciclos de vida orientados a objetos

    Los tipos de ciclos de vida que se han visto hasta ahora son relativos al análisis y diseño estructurados, pero los objetos tienen una particularidad, y es que están basados en componentes que se relacionan entre ellos a través de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de miniproyectos. Además, hoy en día la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida típico en una metodología de diseño orientado a objetos es iterativo e incremental.
    En este texto sólo veremos un tipo de ciclo de vida orientado a objetos, que es además el más representativo, el modelo fuente.


    Modelo fuente

    Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientación a objetos y posiblemente el más seguido. Un proyecto se divide en las fases:

    1. Planificación del negocio
    2. Construcción: Es la más importante y se divide a su vez en otras cinco actividades
      • Planificación
      • Investigación
      • Especificación
      • Implementación
      • Revisión
    3. Entrega
    La primera y la tercera fase son independientes de la metodología de desarrollo orientado a objetos. Además de las tres fases, existen dos periodos:
    1. Crecimiento: Es el tiempo durante el cual se construye el sistema
    2. Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificación del negocio, Construcción y Entrega.
    Cada clase puede tener un ciclo de vida sólo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo. En la figura  se muestra un esquema de este tipo de ciclo de vida.


     
    \includegraphics[]{c1_cv_6.eps}



     Algunos modelos de ciclos de vida



    Modelo de Cascada no modificado


     Modelo Espiral



    Modelo Evolutivo



     Modelo Incremental 

    Bibliografia  

    http://oposicionestic.blogspot.com/2011/06/el-ciclo-de-vida-de-los-sistemas.html