Entornos de desarrollo de software

Profesora Ana Gloria Cordero de Hernández

Ingeniería de Software I

Nicole Mitchell Luis Eduardo Vivar

Universidad Tecnológica de Panamá Facultad de Ingeniería en Sistemas Computacionales

Investigación No.2 CASE para entornos de desarrollo de software

Miércoles, 9 de mayo de 2012

Introducción Todo el mundo conoce la historia de los hijos del zapatero: el zapatero esta tan ocupado haciendo zapatos para otros que sus hijos van descalzos. Durante los últimos 20 años, muchos de los ingenieros de software han sido los “hijos del zapatero”. Aunque han construidos sistemas complejos que automatizan el trabajo de otros, ellos mismos no han aplicado estas técnicas. De hecho hasta hace poco, la ingeniería de software era fundamentalmente una actividad manual en la que las herramientas se utilizaban únicamente en las etapas finales.

Hoy en día, los ingenieros de software han recibido su primer par de zapatos – la ingeniería de software asistida por computadora (sus siglas en ingles CASE).

No hay tanta variedad de zapatos como nos gustaría. Sin embargo, constituyen una pieza indispensable del guardarropa del ingeniero y, con el tiempo, se harán más confortables, más fáciles de usar y más adaptables a las necesidades de cada usuario.

En esta investigación plantearemos diferentes entornos y herramientas que nos permiten el desarrollo de software como lo son las herramientas CASE y UML, herramientas que nos ayudan a aumentar la productividad de un sistema de software, pero no solo eso sino que también encontramos como parte de la investigación el modelo de “4+1” Vistas que de igual forma nos permitirá visualizar de forma más conceptualizada el desarrollo de un software y por ultimo encontramos las fábricas de software empresas en donde se utilizan y se llevan a cabo todos estos procesos y muchos otros.

1

PLAN DE CONTENIDO Introducción .................................................................................................................................. 1 Índice ................................................................................................. ¡Error! Marcador no definido.

Herramientas CASE .................................................................................................................... 4 Objetivos ......................................................................................................................................... 4 Orígenes del CASE ........................................................................................................................... 5 Generales ........................................................................................................................................ 5 Bloques que Componen el CASE ..................................................................................................... 6 Clasificación de las herramientas CASE ........................................................................................... 9

Herramientas UML ................................................................................................................... 16 Investigación realizada en donde se comparan diferentes herramientas UML ........................... 18

Modelo “4+1” Vistas ............................................................................................................... 20 El modelo “4+1” vistas de la arquitectura del software ............................................................... 21 La vista lógica ................................................................................................................................ 21 La Vista de Procesos ...................................................................................................................... 22 Vista de Desarrollo ........................................................................................................................ 23 Vista Física ..................................................................................................................................... 25 Escenarios o Casos de Uso ............................................................................................................ 26

Fábrica de Software ................................................................................................................. 29 Definición ...................................................................................................................................... 29 Descripción .................................................................................................................................... 29 Antecedentes ................................................................................................................................ 30 Análisis de Fabricas de Software en América Latina ..................................................................... 31 Listado de fábricas de software de América Latina ................................................................ 32 Indra .......................................................................................................................................... 32 Capability Maturity Model Integration ......................................................................................... 35 Historia ...................................................................................................................................... 36 Representación del CMMI ......................................................................................................... 37 CMMI modelo de marco ........................................................................................................... 37

2

Conclusiones ............................................................................................................................... 41 BibliografĂ­a................................................................................................................................... 42

3

Herramientas CASE Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte del código automáticamente con el diseño dado, compilación automática, documentación o detección de errores entre otras, que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem Statement Analyzer).

Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

Objetivos 1. Mejorar la productividad en el desarrollo y mantenimiento del software.

2. Aumentar la calidad del software.

3. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informáticos.

4. Mejorar la planificación de un proyecto 5. Aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos.

6. Automatizar el desarrollo del software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto.

7. Ayuda a la reutilización del software, portabilidad y estandarización de la documentación 8. Gestión global en todas las fases de desarrollo de software con una misma herramienta.

9. Facilitar el uso de las distintas metodologías propias de la ingeniería del software.

4

Orígenes del CASE En 1955, los ingenieros mecánicos y eléctricos trabajan con herramientas manuales: libros y tablas que contenían formulas y los algoritmos necesarios para el análisis de un problema; calculadoras (mecánicas) para realizar los cálculos necesarios y asegurar que el producto iba a funcionar; bolígrafos y lápices, mesas de dibujo y reglas que permita al ingeniero crear los modelos del producto que iba a construir. Se hizo un buen trabajo, pero se hizo a mano.

Paso una década y el mismo grupo de ingeniería comenzó a experimentar con la ingeniería basada en computadora. Muchos se resistieron a utilizar computadoras. Una excusa habitual era: “no me fio de los resultados”. Sin embargo, otros se lanzaron hacia delante. El proceso estaba cambiando.

Pasamos a 1975. Las formulas y los algoritmos que el ingeniero necesitaba se incorporaron a programas de computadora que se utilizaban para analizar una gran variedad de problemas de ingeniería. La gente confiaba en los resultados de estos programas. De hecho, la mayoría de su trabajo no podía realizarse sin ellos. Las estación es de trabajo graficas, conectadas a potentes computadoras, estuvieron en uso y sustituyeron a las mesas de dibujo y otras herramientas para la creación de modelos de ingeniería. Se estaba construyendo un puente entre la ingeniería y el trabajo de manufactura, creando el primer enlace el diseño asistido por computadora (CAD) y la fabricación asistida por computadora (CAM.) Volviendo al futuro, encontramos ingeniería asistida por computadora (CAE), diseño asistido por computadora y fabricación integrada por computadora (CIM, sucesor de CAM) como actividades usuales en la mayoría de las empresas.

Generales Las herramientas CASE son usadas en algunas de las fases de desarrollo de sistemas de información, incluyendo análisis, diseño y programación. Su objetivo fundamental es proveer un lenguaje para describir el sistema general que sea lo suficientemente explícito para generar todos los programas necesarios.

La CASE supone la aplicación de principios científicos a través de una metodología que ayude a producir software de alta calidad en un tiempo mucho más reducido.

5

Bloques que Componen el CASE La Ingeniería del Software Asistida por Computadora (CASE) puede ser tan simple como una herramienta que permite desarrollar una actividad específica, o tan compleja como un "entorno" que integre distintas herramientas, bases de datos, hardware, red, sistemas operativos, estándares y muchos otros componentes.

Cada bloque constituye la base del siguiente, con las herramientas situadas en la cima de la pila. Es interesante ver que el fundamento para un CASE efectivo tiene poco que ver con las herramientas de ingeniería del software en si mismas.

Herramientas CASE: son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de las mismas en términos de tiempo y de dinero.

Marco de integración: Es un conjunto de programas especializados que permiten a cada herramienta CASE comunicarse con las demás.

6

Servicios de portabilidad: Este conjunto constituye un puente entre las herramientas CASE, su marco de integración y la arquitectura de entorno. De esta forma permiten que las herramientas CASE y su marco de integración puedan migrar a través de diferentes plataformas de hardware y sistemas operativos sin problemas de adaptación.

Sistema operativo: Gestiona el hardware, la red y las herramientas; mantiene el entorno unido.

Plataforma hardware: Son las estaciones de trabajo individuales interconectadas mediante la red para que los ingenieros del software puedan comunicarse de forma efectiva.

Arquitectura de entorno: Es la base del CASE, en este bloque se construyen los entornos de la ingeniería del software, engloba los sistemas de software y hardware. Además considera los patrones del trabajo humano que se aplican durante el proceso de ingeniería del software.

En la siguientes figuras se muestran los niveles de integración del CASE. En el nivel mas bajo del espectro de integración esta la herramienta individual (solución puntual). Cuando las herramientas proporcionan facilidades para el intercambio de datos el nivel de integración aumenta ligeramente. Estas herramientas generan una salida en un formato estándar compatible con otras herramientas que puedan leer ese formato. En algunos casos, los que construyen herramientas CASE complementarias trabajan juntos para establecer un puente entre ellas (ejemplo: una herramienta de diseño y análisis que se une a un generador de código). La integración por fuente única se da cuando el constructor de herramientas CASE integra diferentes herramientas y las vende como un único paquete. Al final del espectro de integración esta el entorno de soporte de proyectos integrado (IPSE por sus siglas en ingles).

7

8

Clasificación de las herramientas CASE Siempre que se intenta clasificar las herramientas CASE se corren riesgos. Se suele suponer que para crear un entorno CASE efectivo, se deben incluir todas las categorías de herramientas – pero esto es sencillamente falso. Se puede dar lugar a una confusión al situar a una herramienta determinada dentro de una categoría cuando se podría pensar que pertenece a una categoría distinta. La categorización simple tiende a ser llana – esto es, no aparee una interacción jerárquica de las herramientas o de las relaciones entre ellas.

Pero aun asumiendo todos estos riesgos, es necesario crear una taxonomía – para comprender mejor el alcance del CASE, y para apreciar mejor donde se pueden aplicar estar herramientas.

Las herramientas CASE se pueden clasificar bajo diferentes enfoques: ♦ Por su función ♦ Por su papel como instrumentos para el personal técnico o los directivos. ♦ Por la arquitectura del entorno que las soporta (hardware y software) ♦ Origen Tomando la funcionalidad como criterio principal se creó la siguiente Clasificación: Herramientas de planificación de sistemas de gestión Proporcionan un "meta-modelo" del cual se pueden obtener sistemas de información específicos, mediante la modelización de los requisitos de información estratégica de una organización. El objetivo principal de las herramientas de esta categoría es ayudar a comprender mejor como se mueve la información.

Herramientas de gestión de proyectos Pueden hacer estimaciones útiles de esfuerzo, coste y duración del proyecto, definir una estructura de partición del trabajo, planificación del mismo y hacer el seguimiento de proyectos de forma continua. Además se pueden utilizar para recoger datos que permitan realizar una estimación de la productividad del desarrollo y la calidad del producto.

Herramientas de planificación de proyectos Las herramientas que caen dentro de esta categoría se centran en dos áreas fundamentales: el esfuerzo y coste de un proyecto de software; y la planificación del proyecto.

Herramientas de seguimiento de requisitos

9

El objetivo de estas herramientas es de proporcionar un enfoque sistemático para aislar requisitos, comenzando con las especificaciones del cliente. La extracción de requisitos puede ser tan sencilla como encontrar cada ocurrencia del verbo “deber”.

Herramientas de gestión y medida Las herramientas de medidas actuales se centran a las características del producto y del proceso. Las herramientas orientadas a la gestión parten de medidas específicas del proyecto que proporcionan una indicación global de la productividad y de la calidad.

Herramientas de soporte La categoría de herramientas de soporte engloba las herramientas de aplicación y de sistemas que complementan el proceso de ingeniería de software. Estas incluyen herramientas de documentación, herramientas para gestión de redes y software del sistema, herramientas de control de calidad y herramientas de gestión de bases de datos y de configuración del software.

Herramientas de documentación Las herramientas de producción de documentación y autoedición se utilizan en casi todos los aspectos de la ingeniería del software y representan una oportunidad muy interesante para todos los que desarrollan software. No es raro que una empresa emplee el 20 o el 30 por ciento de su esfuerzo de desarrollo en la documentación. Por esta razón, estas herramientas constituyen una opción importante para aumentar la productividad.

Las herramientas de documentación suelen estar unidas a otras herramientas CASE por medio de una interfaz de datos suministrada por el vendedor. Muchas herramientas de análisis y diseño están unidas a uno o varios sistemas de autoedición, de tal forma que los modelos y textos creados durante el análisis y el diseño puedan ser transmitidos a una herramienta de documentación y añadidos a la especificación creada utilizando la misma herramienta de documentación.

10

Herramientas para software de sistemas: El CASE es una tecnología de estaciones de trabajo. Por esto, el entorno CASE debe soportar software de redes de comunicación de alta calidad, correo electrónico, boletines electrónicos y otras posibilidades de comunicación.

Herramientas de control de calidad: La mayoría de las herramientas CASE que se venden como orientadas al control de calidad, son en realidad herramientas de medida que comprueban el código fuente para determinar su compatibilidad con lenguajes estándar. Otras herramientas extraen métricas técnicas como base para medir la calidad del software que se está desarrollando.

Herramientas de bases de datos y de GCS: El software de gestión de bases de datos sirve como base para el establecimiento de una base de datos CASE (almacén). Poniendo énfasis en los objetos de la configuración, las herramientas de gestión de bases de datos para CASE pueden evolucionar de los sistemas relacionales a los sistemas basados en objetos.

Herramientas de análisis y diseño Las herramientas de análisis y diseño permiten al ingeniero de software crear un modelo del sistema que se va a construir. El modelo contiene una representación de los datos y del flujo de control, del contenido de los datos, representaciones de los procesos, especificaciones de control y otras representaciones del modelo. Las herramientas de análisis y diseño también permiten la evaluación de la calidad del modelo y ayudan a eliminar errores antes de que se propaguen al diseño, o al código.

Herramientas de AE/DE La mayoría de las herramientas de diseño y análisis se basan en el método de análisis y diseño estructurado (AE/DE). El AE/DE es una técnica que permite al ingeniero de software crear progresivamente modelos más complejos de un sistema, comenzando en el nivel de requisitos y concluyendo con un diseño de arquitectura.

Herramientas PRO/SIM Las herramientas de creación de prototipos y de simulación (PRO/SIM) proporcionan al ingeniero de software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de que sea construido. Muchas herramientas tienen la capacidad de generar código.

Herramientas para el diseño y desarrollo de interfaces: Las herramientas de diseño y desarrollo de interfaces son, en realidad un conjunto de componentes de software, tales como menús, botones, estructuras de ventanas

11

iconos, mecanismos de visualización, controladores de dispositivos y otros elementos de este tipo.

Herramientas de programación Engloba los compiladores, los editores y los depuradores que se utilizan con los lenguajes de programación convencionales.

Herramientas de codificación convencionales Durante casi 30 años las únicas herramientas disponibles para los programadores eran las herramientas convencionales de programación y por esto, cada problema de ingeniería de software era como un problema de programación. Hoy en día las herramientas convencionales siguen existiendo como una primera línea del desarrollo de software, pero están respaldadas por todas las herramientas CASE. Herramientas de codificación de cuarta generación: Los sistemas de consulta a bases de datos, los generadores de código y los lenguajes de cuarta generación han cambiado la forma de desarrollar sistemas.

Idealmente, estas herramientas de generación de código no solo traducirían la descripción de un sistema a un programa operativo sino que también ayudaran a verificar la corrección de la especificación del sistema. De tal forma que la salida resultante satisfaga los requisitos del usuario.

12

Herramientas de programación orientadas a objetos: Es una de las tecnologías más actuales de la ingeniería de software. Los entornos de programación orientados a objetos suelen estar unidos a lenguajes de programación específicos como: C++, Eiffel, Objetive-C, Smalltalk o Java. Un entorno O-O típico incorpora características de las interfaces de tercera generación (ventanas, ratón, menús desplegables, operaciones sensibles al contexto, multimedia, etc.) con funciones especializadas como la del “inspector” –una función

13

que permite al ingeniero de software examinar todos los objetos contenidos en las bibliotecas de objetos para determinar si pueden o no se utilizadas en la aplicación actual.

Herramientas de creación de prototipos La realización de prototipos es un paradigma de la ingeniería de software ampliamente utilizado, todas las herramientas de creación de prototipos se sitúan en algún lugar del espectro de implementación que se muestra en la figura.

Herramientas de ingeniería inversa: Utiliza como entrada el programa fuente para extraer y analizar su arquitectura, su estructura de control, el flujo lógico y la estructura y flujo de datos. Otras herramientas que pertenecen a esta categoría aplican una técnica conocida como partición de programas. Las herramientas de ingeniería inversa han sido denominadas herramientas de “visualización de código”, permitiendo que el ingeniero visualice el programa, y a su vez ayudan a controlar la cantidad de cambios y la productividad de la gente que los realiza.

Herramientas de reingeniería: pueden dividirse en dos subcategorías – de restructuración de código, que aceptan como entrada código fuente si estructurar y realizan el análisis de ingeniería inversa restructurando el código y agostándolo a los conceptos modernos de programación estructurada; de revisión de datos, que analizan las definiciones de los datos o una base de datos descrita en un lenguaje de programación o en lenguaje de descripción de base de datos, traducen esta descripción a una notación grafica que puede ser analizada por el ingeniero de software. Al trabajar con las herramientas de reingeniería, se puede modificar la estructura lógica de la base de datos, normalizar los archivos resultantes y generar automáticamente un nuevo diseño físico de la base de datos.

Ejemplos de herramientas CASE A continuación se muestra una lista de herramientas CASE, solo se muestran las que se consideraron mas comunes, algunos de nosotros ya hemos trabajado con una o mas de

14

estas herramientas, pero ahora sabemos que son las herramientas CASE, y tambiĂŠn sabemos lo Ăştiles y la gran ayuda que podemos obtener de ellas.

15

Herramientas UML Una herramienta UML es una aplicación de software que utilizan los analistas y programadores informáticos y les facilitan el trabajo con todo tipo de diagramas UML o LUM (Lenguaje Unificado de Modelado), tales como diagramas de estructura, diagramas de comportamiento o diagramas de interacción.

Existen en la actualidad muchas comunidades en Internet que se dedican a tratar temas acerca de UML, al punto que se encuentran alguna meta-sitio en donde se organizan las direcciones que nos brindan información de UML. Algunas de estas comunidades en Internet, se dedican a realizar y mantener páginas en las que listan las herramientas de modelado con UML, con sus principales características, incluso su precio y vínculos donde puede ampliarse la información o comprarlas.

Ahora con el fin de evaluar los aspectos característicos ya mencionados, realizaremos un análisis comparativo entre siete herramientas de UML que nos parecieron interesantes: 1. ArgoUML Es una aplicación de diagramado de UML escrita en Java y publicada bajo la Licencia BSD. Dado que es una aplicación Java, está disponible en cualquier plataforma soportada por Java.

2. Rational: Rational Software es actualmente conocida como una familia de software de IBM para el despliegue, diseño, construcción, pruebas y administración de proyectos en el proceso desarrollo de software.

3. WithClass Es una herramienta para proyectos interdisciplinarios, evaluada a través de un demo y descargada desde la página de Microgold Company, es una aplicación cuyo precio varia dependiendo del modelo. Esta disponible en tres niveles: C#, Compañía y Profesional.

4. Together Técnicamente, el conjunto es un conjunto de Eclipse plug-ins . Junto desarrollador proporciona UML 1.4 modelado, soporte multilenguaje, física de modelado de datos , patrones de diseño , el código fuente de reconocimiento de patrones de diseño, el código de diseño de la plantilla y la reutilización, la generación de documentación , y las auditorías de código y métricas. Together añade independiente del idioma de diagramas UML 2.0, modelado de procesos de negocio y modelos de datos lógicos , y la

16

lógica de la transformación física del modelo de datos y soporte modelo personalizado.

5. Poseidón Es un software de aplicación utilizado para crear modelos con el Unified Modeling Language . Se originó a partir de la ArgoUML proyecto, pero grandes cambios eran necesarios a fin de que ArgoUML en un proyecto comercial, y como resultado los dos esfuerzos son muy divergentes.

6. Umbrello Quizás sea la herramienta más intuitiva para aquellos que están pocos acostumbrados a trabajar con UML de las que aquí comento. Guarda la estética común a todos los programas desarrollados para y por KDE, por lo que si estás acostumbrado a trabajar en este escritorio o con algunos de sus programas principales no te costará nada adaptarte al mismo, aunque como todos sabemos igual puede funcionar el Gnome.

También soporta la generación de código a partir del modelo de elementos y los diagramas para un gran número de lenguajes.

7. BoUML Es un software multiplataforma, capaz de generar código automáticamente (en IDL, C++, Java y PHP) a partir de los diagramas. Se pueden diseñar diagramas de secuencias, de clases, casos de uso, etc.

Además permite añadir aplicaciones externas escritas en C++ o Java, siendo una de estas extensiones predefinidas la generación de código y la ingeniería inversa.

8. Día Día es un programa de creación de diagramas basado en GTK+ bajo la licencia GPL. Está inspirado en el programa comercial de Windows „Visio‟, y puede ser usado para dibujar muchos tipos diferentes de diagramas.

Dispone de una serie de extensiones para ayudar en la elaboración de diagramas entidad-interrelación, UML, flujo de datos, diagramas de red, y un largo etc.

Pero muchos al usarlo tal vez puedan sentir una frustración ya que no es muy sencillo de usar y se trata „solamente‟ de una herramienta de dibujo de diagramas, evitando que podamos sacarle todo el provecho que podríamos sacar del UML. Día incluye una herramienta para generar código a partir de los diagramas realizados.

17

Investigación realizada en donde se comparan diferentes herramientas UML Las características que finalmente analizamos fueron las siguientes:  Código abierto  Tipo de licencia (siendo muy importante que hubiera un licenciamiento académico a un coste accesible)  Lenguaje de programación utilizado  Integración con entornos de desarrollo (y cuales)  Coste  Versión de UML  Diagramas que soporta  Soporte para MDA  Soporte para XMI  Generación de código (y que lenguajes de programación soporta)  Capacidades de ingeniería inversa  Sistema Operativo  Requisitos de instalación Las herramientas analizadas fueron:  ArgoUML  Poseidon for UML  OpenAmeos  Visual Paradigm for UML  StarUML  Rational Software Modeler (sucesor de Rational Rose)  Enterprise Architect  Umbrello UML Modeler  UML Designer Como el objetivo principal del análisis de herramientas era el de seleccionar un entorno de trabajo para los estudiantes (un ambiente que sea lo mas amigable posible), en donde descubrimos que tanto IBM como Visual Paradigm ofrecen sus herramientas de modelado para fines académicos sin coste alguno, y el proceso de gestión de licenciamiento es bastante sencillo.

Por último, no se puede dejar de mencionar que como la Web 2.0 ha llegado también al mundo del

18

modelado UML, una herramienta que a pesar de estar en versión Beta, permite crear al vuelo y con una sintaxis poco compleja, diagramas UML que pueden compartirse a través de Internet con mucha facilidad, y que además se ve como una herramienta muy útil al momento de tener reuniones virtuales o para crear sin mucha complejidad un diagrama UML que quiera ser compartido en algún blog o borrador de modelado.

19

Modelo “4+1” Vistas La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema; así como los requisitos no funcionales del mismo: fiabilidad, escalabilidad, portabilidad, disponibilidad, etc. Esto implica tener o hacer un gran esfuerzo para comprender planos y aspectos de los diseñadores de lo quieren dar a entender en sus diagramas y peor aún que si alguien ajeno a la elaboración del proyecto lo trata de comprender.

El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes.

• La vista lógica.

• La vista de procesos.

• La vista física.

• La vista de desarrollo.

Por tal motivo los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista. La arquitectura evoluciona parcialmente a partir de estos escenarios y pues veremos esto más a detalle a continuación.

20

El modelo “4+1” vistas de la arquitectura del software Una de las herramientas para representar modelos de arquitectura anteriores al UML es la denominada 4+1 visto propuesta por Kruchten. Surge esta necesidad cuando un desarrollador inicia el modelado de un problema; lógicamente en este proceso se hace énfasis en proporcionar la mayor información del mismo a través de los diagramas que se utilicen para su descripción, esto trae consigo que puedan suceder conflictos en la representación de la arquitectura del sistema. Esta arquitectura de software propuesta por Kruchten es una forma de resolver esta problemática. El modelo describe la arquitectura de software del sistema a través de 5 vistas concurrentes.

Kruchten las agrupa estas 5 vistas por su naturaleza en 3 apartados; el conceptual donde sitúa a la vista lógica y la de procesos, el físico que compone las vistas de componentes y la distribuida y por último la funcional la que se refiere a la vista de casos de uso.

La vista lógica Es aquella que trata de clases y subsistemas, tiene las siguientes particularidades: soporta los requerimientos funcionales (estos son asignados por el usuario final), identifica mecanismos y diseña elementos comunes a través del sistema; utiliza los diagramas de clases y la notación de Booch.; además de utilizar el estilo arquitectónico orientado a objetos.

Notación. La notación para la vista lógica se deriva de la notación de Booch. Esta se simplifica considerablemente de tal modo de tener en cuenta solamente los ítems relevantes para la arquitectura. En particular, los numerosos adornos disponibles son bastante inútiles a este nivel de diseñó. Usamos Rational Rose para apoyar el diseñó lógico de la arquitectura.

21

La Vista de Procesos La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad del sistema, de tolerancia a fallas. La vista de procesos también especifica en cual hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica.

La arquitectura de procesos se describe en varios niveles de abstracción, donde cada nivel se refiere a distintos intereses. El nivel más alto la arquitectura de procesos puede verse como un conjunto de redes lógicas de programas comunicantes (llamados “procesos”) ejecutándose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse para apoyar la separación de la operación del sistema en línea del sistema fuera de ´enea, así como también para apoyar la coexistencia de versiones de software de simulación o de prueba.

Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente (i.e., comenzar, recuperar, reconfigurar, y detener). Además, los procesos pueden replicarse para aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad.

Partición. El software se particiona en un conjunto de tareas independientes: hilo de control separado que puede planificarse para su ejecución independiente en un nodo de procesamiento.

Podemos entonces distinguir:

22

• Tareas mayores son elementos arquitectónicos que pueden ser manejados en forma univoca. Se comunican a través de un conjunto bien definido de mecanismos de comunicación inter-tarea: servicios de comunicación sincrónicos y asincrónicos basados en mensajes, llamados a procedimientos remotos, difusión de eventos, etc.

Las tareas mayores no debieran hacer suposiciones acerca de su localización con otras tareas dentro de un mismo proceso o un mismo nodo de procesamiento.

• Tareas menores son tareas adicionales introducidas localmente por motivos de implementación tales como actividades cíclicas, almacenamiento en un buffer, time-out, etc.). Pueden implementarse en Ada por ejemplo, o como hilos de control liviano (threads). Pueden comunicarse mediante rendezvous o memoria compartida.

El flujo de mensajes y la carga de procesos pueden estimarse en base al diagrama de procesos. También es posible implementar una vista de procesos “vacía”, con cargas dummy para los procesos y medir entonces su performance en el sistema objetivo.

Notación. La notación que usamos para la vista de procesos se expande de la notación originalmente propuesta por Booch para las tareas de Ada y se centra solamente en los elementos arquitectónicamente relevantes

Vista de Desarrollo La vista de desarrollo se centra en la organización real de los módulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeñas – bibliotecas de programas o subsistemas– que pueden ser desarrollados por uno o un grupo pequeño de desarrolladores. Los subsistemas se organizan en una jerarquía de

23

capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores.

La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, administración del software, reutilización y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programación que se use. La vista de desarrollo apoya la asignación de requisitos y trabajo al equipo de desarrollo, y apoya la evaluación de costos, la planificación, el monitoreo de progreso del proyecto, y también como base para analizar reusó, portabilidad y seguridad. Es la base para establecer una línea de productos.

La vista de desarrollo de un sistema se representa en diagramas de módulos o subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa solo puede describirse completamente cuando todos los elementos del software han sido identificados. Sin embargo, es posible listar las reglas que rigen la arquitectura de desarrollo – partición, agrupamiento, visibilidad– antes de conocer todos los elementos.

Notación. Usamos una variante de la notación de Booch limitándonos a aquellos ítems relevantes para la arquitectura.

24

Vista Física Mapeando el software al hardware La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados –redes, procesos, tareas y objetos– requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre el código fuente en sí.

Notación para la arquitectura física. Los diagramas físicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto toman diversas formas, con o sin el mapeo de la vista de procesos.

25

Escenarios o Casos de Uso En la quinta y última vista del Modelo 4+1 se presentan los escenarios en los cuales un Caso de Uso dispara una secuencia de acciones que devienen en la interacción entre las vistas tratadas anteriormente.

El usuario, como actor primario, dispara la actividad <_<Apostar>_> que desencadena la secuencia de operaciones necesarias para completar este C.U. Se puede comprender fácilmente de qué manera interactúan las diferentes vistas: 1. En un único Proceso (aplicación web) usuario interactúa con el nodo Cliente mediante teclado y monitor 2. El cliente se comunica con el nodo Web Server

26

3. Web server contiene una Vista Lógica englobada en diferentes Componentes que manipula los datos, validando y consultando mediante la interfaz correspondiente, los datos del nodo Base De Datos De esta forma notamos cómo los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjunto pequeño de escenarios relevantes instancias de casos de uso más generales. Se presentan dos ejemplos más de casos de usos:

27

28

Fábrica de Software La intensa competencia en los mercados está demandando a las organizaciones adaptarse ágilmente a las nuevas condiciones de sus industrias con el propósito de fortalecer su competitividad y en consecuencia continuar desarrollando negocios crecientes y rentables.

La velocidad de adaptación depende en gran medida del conocimiento que la organización tiene de sus procesos y reglas de negocio y de los sistemas de información que los automatizan, además de la cantidad de personas disponibles para responder a los requerimientos de adaptación. Por otro lado las empresas están obligadas a atender asuntos estratégicos orientados a la renovación o innovación de sus ofertas de valor que les asegure su permanencia en los mercados.

Definición De acuerdo con Greenfield y Short, fábrica de software es "una línea de productos de software que configura gran cantidad de herramientas, procesos y contenidos utilizando una plantilla de fábrica de software basado en un esquema de fábrica de software para automatizar el desarrollo y mantenimiento de las variantes de un producto arquetípico mediante la adaptación, montaje y la configuración de marco basado en los componentes ".

Podemos resumir esto en que una fábrica de software es una empresa de la industria del software cuya misión es el desarrollo de software para sus clientes de acuerdo a los requerimientos específicos que aquel le solicita.

Descripción En la ingeniería de software y la empresa de arquitectura de software, una fábrica de software es una estructura de organización que se especializa en la producción de aplicaciones informáticas de software o componentes de software de acuerdo a específicos, definidos externamente necesidades del usuario final a través de un proceso de montaje. Una fábrica de software aplica las técnicas de fabricación y principios de desarrollo de software para imitar los beneficios de la manufactura tradicional. Las fábricas de software que están involucradas con la contratación externa de creación de software.

Dado que la codificación requiere un ingeniero de software, (o el paralelo en la industria manufacturera tradicional, un artesano experto) que se elimina del proceso en la capa de aplicación, el software se crea mediante el ensamblaje de componentes predefinidos en lugar de utilizar tradicionales IDE. Codificación tradicionales, se deja sólo para crear nuevos componentes o servicios. Como tradicional de fabricación, la ingeniería se deja a la

29

creación de los componentes y los requisitos para el sistema de recolección. Una aplicación compuesta es el resultado final de la fabricación en una fábrica de software.

Fábrica de software basado en el desarrollo de aplicaciones aborda el problema de desarrollo tradicional de aplicaciones donde las aplicaciones se desarrollan y distribuyen sin sacar provecho de los conocimientos adquiridos y los bienes producidos a partir de desarrollo

de

aplicaciones

similares.

Muchos

enfoques,

tales

como

formación,

documentación, y los marcos, se utilizan para abordar este problema, sin embargo, el uso de estos métodos para aplicar de forma coherente los valiosos conocimientos previamente adquiridos en el desarrollo de múltiples aplicaciones puede ser un proceso ineficiente y propenso a errores.

Las fábricas de software frente a este problema mediante la codificación de las prácticas de probada eficacia para el desarrollo de un estilo específico de aplicación dentro de un paquete de orientación integrada que es fácil para los equipos de proyecto a adoptar.

Desarrollo de aplicaciones usando una fábrica de software adecuada puede proporcionar muchos beneficios, tales como mejora de la productividad, la calidad y capacidad de evolución.

Antecedentes El término Fábrica Software se acuñó hace casi 40 años, en 1968, en el congreso IFIP (International Federation of Information Processing) por Bemer, quien afirmaba que es imposible que los programadores hagan buen software simplemente bajo supervisión humana, mientras que “una fábrica, sin embargo, tiene más que supervisión humana. Mide y controla la productividad y calidad. Se mantienen registros financieros para coste y planificación”, frase para la reflexión, mas si la trasladamos al momento actual y consideramos sus años de antigüedad.

Hitachi fue la primera empresa que utilizó el término “fábrica” en 1969 cuando fundó Hitachi Software Works.

También es importante resaltar el destacado impulso y difusión empresarial que desde hace tiempo, aparte de en EEUU, el concepto ha tenido en Japón, y mas recientemente en China. A este respecto elaboramos la siguiente tabla donde hemos situado por orden cronológico las primeras fábricas software.     

1969 1975 1976 1977 1979

Primera fábrica de software: Hitachi Software Works Fábrica software de la Systems Development Corporation Fábrica software de NEC Fábrica software de Toshiba Fábrica software de Fujitsu

30

En lo que respecta a la evolución de la estrategia que ha ido guiando las fábricas se pueden establecer tres épocas principales.

Las fábricas de las décadas de los setenta y ochenta, que se basan principalmente en: diseñar edificios que soporten el proceso de desarrollo de software, construir un Software Work Bench (SWB) para las actividades del proceso de desarrollo y establecer una organización que controle y monitorice el proceso. Posteriormente se añadieron otras disciplinas de gestión de proyectos y calidad, metodologías, programas de formación, etc.

Durante los noventa surgen diferentes aproximaciones: Fábricas basadas en Entornos de Desarrollo Integrados, el contexto lo constituyen grandes empresas europeas.  Fábricas de componentes basadas en experiencia, como el SEL (Software Engineering Laboratory) de la NASA, el SEC (Software Experience Center) de DaimlerChrysler o el EPIK (Engineering Process Improvement and Knowledge Sharing) de ICL.  Fábricas de software basadas en la madurez de procesos, el contexto de esta aproximación lo constituye el modelo CMM.  Fábricas de software basadas en la reutilización, basadas en familias de soluciones relacionadas.  Fábricas enfocadas a otras técnicas de gestión de la calidad, como TQM (Gestión de Calidad Total), generadores de código y herramientas CASE. Y en los 2000 son Greenfield y Short (2004) de Microsoft quienes vuelven a poner de moda el concepto como enfoque en el que confluyen el desarrollo basado en componentes, el desarrollo dirigido por modelos y las líneas de producto software. En línea con las recientes propuestas sobre el modelo de fábrica de software para organizaciones chinas, que consideran: Fábrica Software = (Especificaciones de Gestión, Líneas de producto) x (Procesos, Personas, Técnicas) 

Análisis de Fabricas de Software en América Latina La siguiente tabla se puede ordenar desde cualquiera de sus campos. Además, si pulsa sobre el nombre de una empresa, accederá a su página individual, que contendrá información de la fábrica de software en particular que ha sido enviada por los usuarios.

31

Listado de fábricas de software de América Latina Nombre

País

Huso horario

Certificaciones

Indra

GMT-3

CMMI nivel 3

Mnemo

GMT-6

CMMI nivel 5

Synapsis

GMT-3

CMMI Nivel 2

Argentina Tecsidel

GMT-3

Ultrasist

GMT-6

Inforbiz

GMT-6

CMMI Nivel 5

A continuación les presentamos el perfil de una de las empresas que tiene sede en Panamá la empresa Indra:

Indra Indra es una compañía global de tecnología, innovación y talento, líder en soluciones y servicios de alto valor añadido para los sectores de Transporte y Tráfico, Energía e Industria, Administración Pública y Sanidad,Servicios Financieros, Seguridad y Defensa y Telecom y Media. Indra opera en más de 110 países y cuenta con más de 36.000 profesionales a nivel mundial focalizados en desarrollar soluciones innovadoras que cubran las necesidades de los clientes más exigentes. Indra es la segunda compañía europea en su sector por inversión en I+D, con cerca de 500 M€ invertidos en los últimos tres años.

Sostenibilidad y Valores La capacidad para innovar es el eje central de nuestra Responsabilidad Corporativa y sostenibilidad: “Ser una empresa innovadora y del conocimiento en las relaciones con nuestros públicos internos y externos (accionistas, profesionales, clientes, etc.), así como con las instituciones que lo cultivan y desarrollan, y con las comunidades en las que actuamos”.

Gestión responsable de nuestras relaciones con accionistas e inversores como pilar de nuestra sostenibilidad económica: 1.

2.

3.

4.

Estrategia de negocio sólida y sostenible que garantice el crecimiento de la compañía Política retributiva competitiva que recompense la confianza depositada en la empresa Política informativa transparente, veraz y rigurosa Normativa de Gobierno Corporativo que asegure el buen gobierno de la compañía.

32

Nuestra oferta: competitividad y eficiencia para nuestros clientes La diferenciación de la oferta, del modelo de entrega y hasta del modelo de negocio son fundamentales para asegurar el mantenimiento de la ventaja competitiva.

Simultáneamente, la reducción de costes, el enfoque en las tareas realmente diferenciadoras y el consecuente mejor aprovechamiento de los recursos disponibles son los elementos más relevantes de esta transformación de los procesos.

Indra en Panamá Indra está presente en Panamá desde 1999 y cuenta con más 160 profesionales y un Software Lab muy competitivo con metodologías de producción avanzadas, certificado CMMI Nivel 3, que atiende las necesidades locales y del entorno centroamericano.

Panamá es el centro de operaciones de Indra en Centroamérica y Caribe. En el país, la multinacional tiene una sólida posición en los principales mercados a través de una oferta de alto valor agregado que incluye desde la consultoría, el desarrollo de proyectos y la integración de sistemas y aplicaciones hasta el outsourcing de sistemas de información y de procesos de negocios.

Proyectos en Panamá Autoridad Marítima de Panamá Uno de los proyectos más relevantes de Indra en Panamá es la modernización de los sistemas de gestión de la información de la Autoridad Marítima de Panamá (AMP), la flota más grande del mundo. El proyecto contempla la implementación de una plataforma que conectará las direcciones de Marina Mercante, Gente de Mar, Recursos Marinos, Puertos y Planificación, con los 77 consulados que Panamá tiene en todo el mundo y con las oficinas técnicas de la AMP en Panamá, Nueva York, Londres y Manila. Además, Indra está desarrollando para dicha institución un sistema de identificación que sustituirá la actual licencia y que estará dotado de un sistema de identificación biométrico, que incluirá fotografía digital, firma electrónica y huellas dactilares digitalizadas.

Con todas estas mejoras, la AMP cumplirá con los estándares internacionales de calidad de la Organización Marítima Internacional (OMI) al tiempo que optimizará sus recursos, reducirá los costes y mejorará el servicio que presta. El objetivo final que se persigue es que Panamá se consolide como líder en el abanderamiento de buques, una actividad que supone uno de los principales motores de su economía.

Dirección General de Ingresos en Panamá El objetivo del proyecto consistió en la creación de un sistema para la Dirección General de Ingresos del Gobierno de Panamá en el que se pueda ejecutar el procedimiento de fiscalización masiva. Este sistema se caracteriza por poseer un

33

elevado nivel de parametrización, no haciéndola depender de usuarios con perfil de programador.

El sistema se encuentra compuesto por los siguientes subsistemas: subsistema de recepción, subsistema de validación, subsistema de carga de datos, definición y mantenimiento de las lógicas de control, definición y mantenimiento de la estratificación y escenarios de las lógicas de control, definición y mantenimiento de un pre - plan de fiscalización, aplicación de lógicas de control, expediente, asignación de expedientes a usuarios, exclusión de contribuyentes, tratamiento de las comunicaciones, reprocesamiento de las lógicas de control, tratamiento de las notificaciones, mantenimiento de motivaciones, tratamiento de documentos, servicio de notificaciones, actuaciones en el expediente, tratamiento de los intervinientes en el expediente, mantenimiento de observaciones en el expediente, aplicación de los tipos de observación, y mantenimiento de tipo de documentos.

Los subsistemas de Recepción, Validación y Carga de datos permitirán que el sistema FMA se alimente con datos procedentes de fuentes internas y externas.

Los subsistemas Definición y Mantenimiento de las Lógicas de Control, Definición y mantenimiento de la estratificación y escenarios de las lógicas de control y Definición y mantenimiento de un pre-plan de fiscalización, le permitirán al usuario crear unos parámetros predeterminados que utilizará para elaborar el plan de fiscalización.

Por su parte, el subsistema Aplicación de lógicas de control le permitirá al usuario obtener una selección de contribuyentes que él mismo podrá tratar de manera que aumente o disminuya la selección que se realizó con los parámetros prestablecidos.

El subsistema expediente permitirá mantener ordenadas y clasificadas todas las actuaciones realizadas en el procedimiento de fiscalización independientemente de que sean realizadas de forma automática o manualmente por el usuario.

Del mismo modo, el subsistema exclusión de contribuyentes, permitirá a los usuarios decidir si se han de excluir contribuyentes del plan de fiscalización masiva.

La exclusión de estos contribuyentes deberá ser motivada. Identificados estos contribuyentes, y excluidos los que se consideren oportunos, se asignarán los expedientes a los usuarios fiscalizadores. A tal fin, se ha previsto el subsistema Asignación de Expediente.

Asignados los expedientes, los usuarios a través de las actuaciones a realizar en el expediente (Subsistema Actuaciones en el Expediente) elaborarán los documentos (Subsistema Generación de Documentos) que serán notificados a los contribuyentes (Subsistema Notificaciones) iniciándose de esta manera la fiscalización de segundo nivel.

El subsistema comunicaciones identifica la primera actuación a realizar aprobado el plan de fiscalización. A través de este subsistema se iniciará el proceso de comunicación con el contribuyente.

34

Dentro del proceso y, a fin de iniciar la comunicación con el contribuyente, será necesario que se haya elaborado un documento que se ponga en su conocimiento y que éste le sea remitido. Estas dos necesidades se verán soportadas por los subsistemas generar documento y servicio de notificaciones.

El subsistema reprocesamiento de lógicas de control permitirá, por su parte, conocer qué contribuyentes son los que quedan pendientes de regularizar su situación. Dado que, además de los contribuyentes seleccionados estos pueden haber conferido la representación a otra persona, se prevé el subsistema tratamiento de personas, que permitirá relacionar los contribuyentes con los representantes y mantener actualizados los datos de ambos tipos de personas.

El subsistema motivación se encuentra íntimamente relacionada con el subsistema generación de documentos ya que todos los documentos que se generen deberán estar provistos de una notificación.

Mantenimiento de motivación permitirá estar actualizado el catálogo de textos que se usará como motivación de los documentos. Dado que, durante el procedimiento de fiscalización masiva, pueden existir situaciones que sea necesario contemplar para la correcta tramitación del expediente.

El subsistema observaciones permitirá reflejar en el expediente estos hechos para que sean tenidas en cuenta.

Por último, el subsistema mantenimiento de observaciones permitirá que se definan, modifiquen o eliminen las tipologías de observaciones incluidas por el usuario.

Modelo de negocios SAP para Grupo Estrella Azul La implementación del modelo de negocios SAP en el Grupo Estrella Azul tiene como objetivo unificar la información bajo una plataforma única que permita que ésta sea manejada en tiempo real. Lo anterior permite a Estrella Azul, entre otras ventajas, mejorar el acceso a la información para el análisis y toma de decisiones estratégicas; optimizar los procesos de negocio en áreas claves como producción, ventas, logística, finanzas y contabilidad; facilitar el manejo de inventarios; aumentar la eficiencia a través de la incorporación de mejores prácticas y contar con una base operacional más robusta y flexible.

Capability Maturity Model Integration Capability Maturity Model Integration (CMMI) es un enfoque de mejora de procesos, cuyo objetivo es ayudar a las organizaciones a mejorar su rendimiento. CMMI se puede utilizar para guiar la mejora de procesos a través de un proyecto, una división o una organización entera. En la actualidad el apoyo es CMMI versión 1.3.

35

CMMI en ingeniería de software y el desarrollo organizacional es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales para la mejora de procesos eficaces. CMMI está registrado en la Oficina de Patentes de EE.UU. y la Oficina de Marcas de la Universidad Carnegie Mellon.

Según el Instituto de Ingeniería de Software (SEI, 2008), CMMI ayuda a "integrar funciones organizativas tradicionalmente separadas, establecer objetivos de mejora de procesos y prioridades, proporcionar una guía para los procesos de calidad, y proporcionar un punto de referencia para evaluar los procesos actuales CMMI en la actualidad se ocupa de tres áreas de interés: 

Desarrollo de productos y servicios - CMMI para el Desarrollo (CMMI-DEV),



Establecimiento de servicio, gestión y entrega - CMMI para servicios (CMMI-SVC), y



La adquisición de productos y servicios - CMMI para la adquisición (CMMI-ACQ).

CMMI ha sido desarrollado por un grupo de expertos de la industria, el gobierno y el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon. Modelos CMMI guiar el desarrollo o mejora de procesos que cumplan con los objetivos empresariales de una organización. Un modelo CMMI también puede utilizarse como un marco para evaluar la madurez de los procesos de la organización.

CMMI se originó en la ingeniería de software, pero ha sido muy generalizado en los últimos años para abarcar otras áreas de interés, tales como el desarrollo de productos de hardware, la entrega de todo tipo de servicios y la adquisición de productos y servicios. La palabra "software" no aparece en las definiciones de CMMI. Esta generalización de los conceptos de mejora CMMI hace extremadamente abstracto. No es lo más específico a la ingeniería de software como su predecesor, el software CMM

Historia CMMI fue desarrollado por el proyecto CMMI, cuyo objetivo es mejorar la usabilidad de los modelos de madurez integrando varios modelos en un marco. El proyecto consistió en miembros de la industria, el gobierno y la Carnegie Mellon Software Engineering Institute (SEI). Los principales patrocinadores incluyen a la Oficina del Secretario de Defensa (OSD) y la Asociación Industrial de la Defensa Nacional.

CMMI es el sucesor del Capability Maturity Model (CMM) o CMM Software. El CMM fue desarrollado desde 1987 hasta 1997. En 2002, CMMI versión 1.1 fue lanzada, la versión 1.2 seguido en agosto de 2006, y CMMI versión 1.3 en noviembre de 2010. Algunos de los principales cambios en CMMI V1.3 son el soporte de Desarrollo de Software Ágil, las

36

mejoras en las prácticas de alta madurez y la alineación de la representación (por etapas y continua)

Representación del CMMI CMMI existe en dos representaciones: continua y por etapas. La representación continua se ha diseñado para permitir al usuario concentrarse en los procesos específicos que se consideran importantes para los objetivos de la organización de negocios inmediatos, o aquellos a los que la organización les asigna un alto grado de riesgos. La representación por etapas está diseñada para proporcionar una secuencia estándar de mejoras, y puede servir como una base para comparar la madurez de los proyectos y organizaciones. La representación por etapas también se prevé una fácil migración desde el SW-CMM a CMMI

CMMI modelo de marco Dependiendo de las áreas de interés CMMI (adquisición, servicios de desarrollo) que se utilizan, las áreas de proceso que contiene varían. Las áreas de proceso son las áreas que serán cubiertas por los procesos de la organización.

La siguiente tabla muestra las áreas de proceso que están presentes en todas las áreas de interés en CMMI CMMI versión 1.3. Esta colección de dieciséis áreas de proceso se conoce como las áreas centrales de proceso CMMI. Los niveles de madurez CMMI para el desarrollo de Hay cinco niveles de madurez. Sin embargo, las calificaciones de nivel de madurez se otorgan para los niveles 2 a 5. Las áreas de proceso por debajo de sus niveles de madurez y se enumeran para el CMMI para el modelo de desarrollo: Nivel de Madurez 2 - Gestionado 1. CM - Gestión de la Configuración 2. MA - Medición y Análisis

37

3. PMC - Monitoreo y Control de Proyectos 4. PP - Planificación de Proyectos 5. PPQA - Procesos y Aseguramiento de la Calidad del producto 6. REQM - Gestión de Requisitos 7. SAM - Gestión de proveedores Acuerdo Nivel de Madurez 3 - Definido 1. DAR - Análisis de Decisiones y Resolución 2. MIP - Gestión Integrada de Proyectos 3. OPD - Definición del proceso de organización 4. OPF - Enfoque del Proceso Organizacional 5. OT - la organización de formación 6. PI - Integración del producto 7. RD - Requisitos para el Desarrollo.

8. RSKM - Gestión de Riesgos.

9. TS - Solución técnica.

10. VAL - Validación.

11. VER - Verificación.

Nivel de Madurez 4 - Cuantitativamente Gestionado 1. OPP - Performance del Proceso Organizacional 2. QPM - Gestión de proyectos cuantitativa Nivel de Madurez 5 - Optimización 1. CAR - Análisis causal y resolución 2. OPM - Gestión del Desempeño Organizacional Los niveles de madurez CMMI en los servicios Las áreas de proceso por debajo de sus niveles de madurez y se enumeran para el modelo de CMMI para Servicios: Nivel de Madurez 2 - Gestionado 1. CM - Gestión de la Configuración 2. MA - Medición y Análisis 3. PPQA - Procesos y Aseguramiento de la Calidad del producto 4. REQM - Gestión de Requisitos 5. SAM - Gestión de proveedores Acuerdo

38

6. SD - Entrega de Servicios 7. WMC - Seguimiento y control del trabajo 8. WP - Planificación del trabajo Nivel de Madurez 3 - Definido 1. CAM - Capacidad y Gestión de la Disponibilidad 2. DAR - Análisis de Decisiones y Resolución 3. IRP - Solución de Incidencias y Prevención 4. IWM - Gestión de trabajo integrado 5. OPD - Definición del proceso de organización 6. OPF - Enfoque del Proceso Organizacional 7. OT - la organización de formación 8. RSKM - Gestión de Riesgos 9. SCON - Continuidad del Servicio 10. SSD - Servicio de Desarrollo de Sistema 11. SST - Sistema de Transición del Servicio 12. STSM - Servicio de Gestión Estratégica Nivel de Madurez 4 - Cuantitativamente Gestionado 1. OPP - Performance del Proceso Organizacional 2. QWM - Gestión de trabajo cuantitativo Nivel de Madurez 5 - Optimización 1. CAR - Análisis causal y resolución 2. OPM - Gestión del Desempeño Organizacional Los niveles de madurez en CMMI para la adquisición de Las áreas de proceso por debajo de sus niveles de madurez y se enumeran para el modelo de CMMI para la adquisición: Nivel de Madurez 2 - Gestionado 1. AM - Gestión de Acuerdo 2. ARD - Adquisición de Desarrollo de Requisitos 3. CM - Gestión de la Configuración 4. MA - Medición y Análisis 5. PMC - Monitoreo y Control de Proyectos 6. PP - Planificación de Proyectos

39

7. PPQA - Procesos y Aseguramiento de la Calidad del producto 8. REQM - Gestión de Requisitos 9. AMS - Solicitud y Acuerdo de Desarrollo de Proveedores Nivel de Madurez 3 - Definido 1. ATM - Adquisición de Gestión Técnica 2. AVAL - Validación de Adquisición 3. AVER - Verificación de la adquisición 4. DAR - Análisis de Decisiones y Resolución 5. MIP - Gestión Integrada de Proyectos 6. OPD - Definición del proceso de organización 7. OPF - Enfoque del Proceso Organizacional 8. OT - la organización de formación 9. RSKM - Gestión de Riesgos

Nivel de Madurez 4 - Cuantitativamente Gestionado 1. OPP - Performance del Proceso Organizacional 2. QPM - Gestión de proyectos cuantitativa Nivel de Madurez 5 - Optimización 1. CAR - Análisis causal y resolución 2. OPM - Gestión del Desempeño Organizacional

40

Conclusiones 1. Las herramientas CASE, son aquellas que mediante una metodología científica nos permiten desarrollar los software que deseamos de una manera mas organizada y a la vez le da una mejor calidad al producto final.

2. Existen muchas herramientas UML, que nos ayudan a moldear los distintos escenarios que vamos a tener, pero cabe destacar que estas herramientas nos ayudan a poder esquematizar de cierta forma el problema que vamos a tratar 3. El modelo de “4 vistas+1” nos permite tener como una guía arquitectónica de lo que estamos diseñando, de manera que sea fácil interpretarlo para personas ajenas al proyecto.

4. Las fabricas de software son aquellas que nos permiten crear replicas idénticas de un software de manera que pueda reutilizarse en distintos lugares.

5. En Panamá no existen fábricas de software registradas oficialmente con los procesos del CMMI, por ende es un campo que se debería explotar para poder hacer un mejor impacto en la sociedad tanto panameña como mundial.

41

BibliografĂ­a 1. http://en.wikipedia.org/wiki/Software_factory 2. http://es.wikipedia.org/wiki/F%C3%A1brica_de_software 3. http://www.kybeleconsulting.com/?option=com_content&view=article&id= 60&Itemid=61 4. http://www.javiergarzas.com/2007/05/primeras-fbricas-software-conceptoe.html 5. http://www.fabricasdesoftware.es/sobre-el-portal 6. http://www.fabricasdesoftware.es/listado-de-fabricas-software-porpaises/listado-de-fbricas-latinoamericanas 7. http://es.wikipedia.org/wiki/Capability_Maturity_Model_Integration 8. http://en.wikipedia.org/wiki/Capability_Maturity_Model_Integration 9. http://case-tools.org/tools/withclass.html 10. http://www.jams.name/2010/04/18/herramientas-uml-cual-utilizar/ 11. http://synergix.wordpress.com/2008/07/31/las-4-mas-1-vistas/ 12. http://es.scribd.com/doc/49826815/Modelo-4-1-vista 13. http://www.buenastareas.com/ensayos/Modelo-De-4-1-Vistas/200237.html 14. http://docente.ucol.mx/almoradi/public_html/Respaldo/resumen3.htm 15. www.jams.name/2010/04/18/herramientas-uml-cual-utilizar/ 16. http://www.diatel.upm.es/malvarez/UML/Comparativa.html 17. es.wikipedia.org/wiki/CategorĂ­a:Herramientas_UML 18. paraisolinux.com/herramientas-para-modelado-uml

42