domingo, 20 de septiembre de 2015

MODELANDO PROCESOS DE NEGOCIO

Un aspecto importante dentro de las organizaciones es tener definidos los procesos de negocio, y podemos apoyarnos en BPMN para proporcionar los pasos del proceso de negocio, de una forma gráfica que sea fácilmente comprensible  para los todos los interesados o involucrados en el negocio, como lo son los analistas, desarrolladores, administradores, gerentes, etc. La idea de esta entrada es comprender como usar BPMN y mostrar algunos elementos gráficos usados.

BPMN define un Business Process Diagram (BPD), que se basa en una técnica de grafos de flujo para crear modelos gráficos de operaciones de procesos de negocio. Un modelo de procesos de negocio, es una red de objetos gráficos, que son actividades (trabajo) y controles de flujo que definen su orden de rendimiento.

                         

Un BPD está formado por un conjunto de elementos gráficos. Estos elementos habilitan el fácil desarrollo de diagramas simples que serán familiares para la mayoría de analistas de negocio (diagrama de flujo). Los elementos fueron elegidos para ser distinguibles los unos de los otros y para usar formas familiares para la mayoría de modeladores. Dentro de las categorías básicas de elementos, se puede añadir información y variaciones adicionales para dar soporte a los requerimientos complejos sin cambiar dramáticamente el look-and-feel básico del diagrama. Las cuatro categorías básicas de elementos son:

  • Objetos de flujo: Un BPD es un pequeño conjunto de tres elementos básicos, que son los objetos de flujo.

    • Evento: Un evento se representa con un círculo. Es algo que “pasa” durante el curso del proceso de negocio. Estos eventos afectan al flujo del proceso y suelen tener una causa o un impacto.


    • Actividad: Una actividad se representa con un rectángulo redondeado y es un término genérico para el trabajo que hace una compañía.
    • Gateway: Una gateway se representa por la típica figura de diamante y se usa para controlar la divergencia o convergencia de la secuencia de flujo.


  • Objetos conectores: Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. Hay tres objetos conectores que hacen esta función. 

    • Flujo de secuencia: El flujo de secuencia se representa por una linea sólida con una cabeza de flecha sólida y se usa para mostrar el orden (la secuencia) en el que las diferentes actividades se ejecutarán en el Proceso.
    • Flujo de mensajes: El flujo de mensaje se representa por un linea discontinua con una punta de flecha hueca y se usa para mostrar el flujo de mensajes entre dos participantes del proceso separados (entidades de negocio o roles de negocio).
    • Asociación: una asociación se representa por una linea de puntos con una punta de flecha de lineas y se usa para asociar datos, texto, y otros artefactos con los objetos de flujo. Las asociaciones se usan para mostrar entradas y salidas de las actividades.


  • Swimlanes: Son usados para organizar actividades en categorías separadas visualmente para ilustrar diferentes capacidades funcionales o responsabilidades. BPMN soporta los swimlanes con dos constructores principales:
    • Pool: una pool representa un Participante de un Proceso. Además actúa como un contenedor gráfico para particionar un conjunto de actividades desde otros pools.
    • Lane: una lane es una sub-partición dentro de un pool y extiende la longitud del pool, verticalmente u horizontalmente. Las lanes se usan para organizar y categorizar actividades.
                               


SIMPLEMENTE, UN BUEN DISEÑO


Detallando ahora los distintos estándares con lo que podemos modelar los procesos de negocio para volver mas óptimos los sistemas de información de las organizaciones si se tienen en cuenta los conceptos mencionados. Por ejemplo SOA colabora en los modelos de desarrollo y propone una practicas y conceptos que colaboran a una eficiencia de integración de distintos SI. En la actualidad SOA es usado mucho en los servicios WEB, en donde SOA define la naturaleza del servicio, (es la arquitectura de la aplicación en donde se obtienen la referencia de los procesos de negocio) pero no define la tecnología, la cual puede ser SOAP, XML,etc.  Teniendo esta introducción, podemos ver algunos beneficios que se pueden obtener de la utilización de SOA desde algunos puntos de entrada.

La Arquitectura Orientada a Servicios (SOA) es un estilo arquitectónico de TI que soporta la transformación de su empresa en un conjunto de servicios vinculados o tareas empresariales repetibles a las cuales se puede acceder en una red cuando sea necesario. Puede ser una red local, Internet o bien una red geográfica y tecnológicamente distinta, que combina servicios en Nueva York, Londres y Hong Kong, aunque estén todos instalados en su desktop local. Esos servicios pueden combinarse para realizar una tarea empresarial específica, para permitir que su empresa se adapte a condiciones y requisitos cambiantes.

                  
Cuando la implementación de SOA es guiada por objetivos empresariales estratégicos, se asegura a la transformación positiva de la empresa y se puede obtener los beneficios principales de SOA, que son:



Existen cinco puntos con los cuales se puede optimizar a la empresa. Esos puntos de entrada son impulsados por necesidades empresariales (puntos de entrada relacionados con personas, procesos e información) y necesidades de TI (puntos de entrada relacionados con conectividad y reutilización). He aquí algunas descripciones generales de los cinco puntos de entrada:



domingo, 13 de septiembre de 2015

Metodología de desarrollo iterativo y creciente

Buscando información acerca de la metodología de trabajo planteada para el desarrollo del proyecto, encontré algunas definiciones acerca de la metodología de desarrollo iterativo e incremental, la cual es la mas usada hoy en día por los beneficios que esta ofrece.

                                        
Si en un ciclo de vida en cascada las fases del ciclo de vida (requisitos, análisis, diseño, etc.) se realizan una única vez, y el inicio de una fase no comienza hasta que termina la fase que procede, en un ciclo de vida iterativo e incremental se va liberando partes del producto (prototipos) periódicamente, en cada iteracion y cada nueva versión normalmente, aumenta la funcionalidad y mejora la calidad respecto a la anterior.

Los pasos claves en el proceso son comenzar con una implementacion simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo este implementado. En cada iteracion, se realizan cambios en el diseño y se agregan nuevas funcionalidades y capacidades al sistema. El proceso en si mismo consiste en crear una versión del sistema. La meta es crear un producto con el que el usuario pueda interactuar y por ende retroalimentar el proceso sin dificultad alguna de que estas modificaciones no den lugar en la planeacion del mismo.

Separando la metodología en los dos procesos fundamentales, tenemos:

  • Proceso incremental:  La esencia de este proceso, es desarrollar por partes el producto de software, para después integrarlas a medida que se completan. Un ejemplo de un desarrollo puramente incremental puede ser la integración de módulos en diferentes fases.
  • Proceso iterativo: En cada ciclo del producto, de manera iterativa este se revisa y mejora. De esta forma se mejora cada vez mas la calidad del producto y esto no implica tener que añadir nuevas funciones al mismo.

De esta manera podemos apreciar que las ventajas que nos ofrece esta metodología de trabajo es muy beneficioso, ya que nos puede ayudar a resolver problemas de alto riesgo en tiempos tempranos del proyecto, realizar adaptaciones al proyecto que no se identificaron en la planeacion y con esto una menor tasa de fallo del proyectos o que no se cumplan con los objetivos del mismo.




CALIDAD DE SOFTWARE

Apropósito de  la descripción de calidad de software, que nos da la norma ISO 25000, quise buscar un poco acerca de investigaciones realizados en el tema de la calidad de software, y encontré este articulo el cual compartiré con uds en esta ocasión.

                   

Como primera medida lo importante para este tema seria tener una referencia acerca de que es la calidad de software y una definición amplia de calidad, planteada en la norma UNE-EN ISO 8402, expresa que “la calidad es el conjunto de propiedades y características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades explícitas o implícitas”. 

Al intentar definir el concepto de calidad del software se debe diferenciar entre la calidad del Producto de software y la calidad del Proceso de desarrollo del mismo. Hay un vínculo claro entre la calidad del proceso y del producto en producción debido a que el proceso es relativamente fácil de estandarizar y monitorizar. Cada sistema de producción se calibra, y debe producir una y otra vez productos de alta calidad. Sin embargo, el software no se manufactura, sino que se diseña. El desarrollo de software es un proceso más creativo que mecánico, donde las experiencias y habilidades individuales son importantes. La calidad del producto, sea cual fuere el proceso utilizado, también se ve afectada por factores externos, como la novedad de una aplicación o la presión comercial para sacar un producto rápidamente.

Modelos de calidad de software

 A lo largo del tiempo se han desarrollado diferentes modelos para evaluar la calidad del software, que intentan descomponer la calidad en una categoría de características más sencillas. Entre ellos puede mencionarse el de McCall, Evans y Marciniak, Deutch y Willis, FURPS, entre otros. 

Un hito en la definición de estándares de calidad de producto software, lo constituye la publicación del ISO9126 en el año 1991. Luego, en el año 2001, este estándar fue reemplazado por dos estándares relacionados: el ISO/IEC 9126, que especifica características y métricas de la calidad del software; y el estándar ISO/IEC 14598, que especifica la evaluación de productos de software. 

El estándar ISO/IEC 9126 se compone de cuatro partes: 
  • modelo de calidad
  • métricas externas 
  • métricas internas  
  • métricas para la calidad en uso. 
Propone un modelo de calidad categorizando la calidad de los atributos software en seis características
  • funcionalidad
  • fiabilidad
  • usabilidad
  • eficiencia
  • mantenibilidad
  • portabilidad
Las cuales son subdivididas en subcaracterísticas.
La calidad de uso es definida como “la capacidad del software que posibilita la obtención de objetivos específicos con efectividad, productividad, satisfacción y seguridad”. El modelo más actual está representado por las normas ISO 25000:2005, conocidas con el nombre de SQuaRE (Software Quality Requirements and Evaluation), basada en ISO 9126 y en ISO 14598, se desagrega en 5 tópicos: 
  1. Gestión de la Calidad (2500n), 
  2. Modelo de Calidad (2501n), 
  3. Medidas de Calidad (2502n), 
  4. Requerimientos de Calidad (2503n) 
  5. Evaluación de la Calidad (2504n). 
La especificación de requisitos de calidad y la evaluación de productos software son dos procesos que por su inherente complejidad pueden beneficiarse del proceso que regule su realización. Sin embargo, y como señala el estándar SQuaRE, es importante que sus objetivos estén alineados. Por ello, la creación de una norma que regule su realización pueda ser muy beneficiosa, en cuanto a la consistencia de los resultados obtenidos. Otro aspecto destacable de SQuaRE es la incorporación de una normalización de la terminología, considera la Metrología como la ciencia de la medida y la necesidad de amoldar los conceptos usados en Ingeniería del Software a los utilizados en otras disciplinas que hacen uso de la medición.



http://sedici.unlp.edu.ar/bitstream/handle/10915/19762/Documento_completo.pdf?sequence=1

domingo, 6 de septiembre de 2015

Un Sitio Web como sistema de información

Para esta ocasión, estaba buscando artículos relacionados con el ciclo de vida de la información y encontré este, en el cual se explica los conceptos importantes en el desarrollo de un sitio web como sistema de información, el cual esta basado en el ciclo de vida de información propuesto por Vizcaya, y este a sus vez tiene relación con la arquitectura de la información.

En primera medida podemos definir sitio Web que puede considerarse un sistema en tanto está compuesto por elementos que se relacionan entre sí para cumplir determinados objetivos. Estos elementos o componentes son amplios y diversos. Entre ellos se encuentran las siguientes entidades y procesos:
  • Entidades
    • Información y los elementos a través de los cuales se representa y organiza (esquemas, estructuras, sistema de navegación, archivos, y las propias páginas que integran el sitio)
    • Equipo de realización (arquitecto de información, diseñador, programador, etc.)
    • Usuarios
  • procesos: todos las tareas que se realizan durante su concepción, diseño, implementación, posicionamiento y uso.

En tal sentido, un sitio Web es un sistema cuyo objeto principal es la información que se transforma a medida que pasa por cada uno de los subprocesos que en él tienen lugar. Si se plantea que los sistemas que trabajan con elementos “informativos” (datos, documentos, objetos, información) se denominan sistemas de información; y al esbozar que un sistema de información es un conjunto de elementos o componentes relacionados con la información que interaccionan entre sí para lograr un objetivo: facilitar y/o recuperar información, no hay lugar a dudas que un sitio Web constituye un sistema de información y en el que tienen lugar los siguientes procesos:

  • Selección
  • Organización de la información
  • Diseño de interface
  • Implementación
  • Posicionamiento
  • Búsqueda y recuperación
  • Diseminación

Estos procesos pertenecen a un sistema de información, por lo cual guardan una supuesta relación con los procesos identificados en el ciclo de vida de la información.

                                          

Podemos definir algunos procesos de la arquitectura de información, que tienen alguna relación con el ciclo de vida de información y por consiguiente con el diseño del sitio web:

  • Selección: es el proceso que permite la entrada de la mayor cantidad de recursos al sistema conformado por un sitio Web
  • Organización de la información: Tiene objetivos establecidos que son: analizar, organizar y representar la información, y es el proceso más importante dentro de la Arquitectura de Información
  • Estructuras de la organización de la información: Las estructuras de OI definen las relaciones entre los grupos de contenido y los elementos que lo integran. Los tipos pueden ser jerárquicas o hipertextuales.
  • Sistema de navegación: Se emplean para trazar el curso del usuario en su proceso de consulta, determinar su posición, y hallar el camino de regreso. Aportan sentido de contexto y comodidad.
  • Sistema de etiquetado: Los sistemas de etiquetas garantizan la representación general del contenido disponible en el sitio. La función fundamental de estas es comunicar la información eficientemente optimizando el espacio donde se muestra en la página Web, con un mensaje directo y claro.
  • Sistemas de búsqueda: se encarga de diseñar como va a estar estructurado el sistema de búsqueda interna de un sitio Web.



http://eprints.rclis.org/14370/1/La_arquitectura_de_informaci%C3%B3n_un_an%C3%A1lisis_a_partir_de_los_procesos_del_Ciclo_de_Vida_de_la_Informaci%C3%B3n.pdf

sábado, 5 de septiembre de 2015

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

Bueno en esta ocasión estaba buscando el ciclo de elaboración de un sistema de información, entre ello encontré que al unas fases que dados unos determinados autores cambian, pero por lo general son las mismas incluso muy parecidas al ciclo de vida de un proyecto de software.

Una consideración personal, es que cada una de las etapas debe de contener su planificación de tiempo y demás, pero una de las etapa fundamental es el mantenimiento, puesto que aquí es donde se hace una retroalimentación del sistema y se verifica que este es en buen funcionamiento acorde con los objetivos de negocio de la organización.

Y es que todo Sistema de Información tiene un tiempo de vida (ciclo de vida). Y este ciclo de vida de un sistema de información consta de diversas etapas que ayudan a la organización a tener éxito durante su tiempo de vida. A continuación veremos cada una de estas etapas:



                                         

1. Investigación preliminar

La solicitud para recibir apoyo de un sistema de información se origina con la petición de una persona, ya sea, un administrador, un trabajador o un especialista en sistemas.

Al comenzar esta etapa se divide en tres partes:

a) Aclaración de la solicitud: Demasiadas solicitudes de trabajadores y usuarios no se especifican de manera clara, por consiguiente antes de proceder a la investigación de sistemas se debe determinar qué es lo que desea el solicitante.

b) Estudio de factibilidad: La investigación preliminar debe determinar si el sistema es factible. Existen tres aspectos fundamentales:
  • Factibilidad técnica: Fijarse si las condiciones son eficaces para el desarrollo del trabajo, tal como la tecnología.
  • Factibilidad económica: Determinar si el sistema beneficia a la organización.
  • Factibilidad operacional: Determinar si el sistema será utilizado.

c) Aprobación de la solicitud: La mayoría de proyectos solicitados no se llevan a cabo, porque los administradores seleccionan y deciden cual es más importante. Luego más tarde al aprobar un proyecto se estiman los costos, el tiempo que llevara su desarrollo; así como también las necesidades de los trabajadores.

2. Determinación de los requerimientos

El analista recopila opiniones y soluciones que proponen los demás para cambiar el proceso y conforme a estos detalles, los analistas estudian los datos sobre los requerimientos con la finalidad de identificar las características que debe tener el nuevo sistema, incluyendo la información que debe obtener y producir el nuevo sistema, junto con características operacionales, tales como controladores de procesamiento, tiempos de respuesta y métodos de entrada y salida.

3. Diseño de sistemas

El diseño de un sistema de información produce detalles de cómo el sistema cumplirá con los requerimientos identificados durante la fase de análisis.

Este proceso indica los datos de entrada, (los cuales serán almacenados) y se inicia identificando las salidas que debe producir el sistema, donde los diseñadores seleccionan las estructuras de archivo y los dispositivos de almacenamiento, tales como discos y cintas magnéticas. El diseñador emite información detallada del diseño al equipo de programación para comenzar así la fase desarrollo de software.

4. Desarrollo de software

En esta etapa el programador instala el software y se hace responsable de la documentación de los programas y de proporcionar una explicación de cómo y porque ciertos procedimientos se codifican de determinada manera. La documentación es esencial para probar el programa y dar mantenimiento a la aplicación instalada.

Durante esta fase el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas. Se utilizan como entradas conjunto de datos de prueba para su procesamiento y luego se examinan resultados. De esta manera se observa si el sistema es confiable.

5. Implantación , evaluación.

La implantación es un proceso, donde instala la aplicación y construye todos los archivos de datos necesarios para su uso.

En una organización es preferible que emplee la aplicación solo en un área de la empresa, para así no halla riesgos y una vez instaladas en la empresa, esta aplicación se emplearan durante muchos años. Por tal motivo debe realizarse el mantenimiento respectivo porque la organización cambia a medida que pasa el tiempo, para satisfacer las nuevas necesidades de los usuarios.

La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:

  • · Evaluación operacional: valoración del funcionamiento del sistema.
  • · Impacto organización: Identificación de los beneficios para la organización

6. Mantenimiento.

Tiene como objetivo adecuar el sistema a los cambios del entorno y de la propia entidad que producen nuevas necesidades informativas en la gerencia y los niveles superiores y a los cambios técnicos del hardware y software, deben ser justificados y aprobados por la gerencia de la entidad y reflejados en la documentación técnica del sistema, para que se mantenga actualizada y en el manual de usuario para que continué reflejando la realidad del sistema.


http://izamorar.com/ciclo-de-vida-de-un-sistema-de-informacion/
http://elvex.ugr.es/idbis/db/docs/lifecycle.pdf

viernes, 28 de agosto de 2015

El Modelo de “4+1” Vistas de la Arquitectura del Software

Un tema interesante que encontré, es el modelo denominado "4+1" del profesor Philippe Kruchten, tambien denominado vistas recurrentes. Este uso de múltiples vistas permite abordar los intereses de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyecto, etc., y manejar los requisitos funcionales y no funcionales separadamente. Se describe cada una de las cinco vistas descritas, conjuntamente con la notación para captarla. Las vistas se diseñan mediante un proceso centrado en la arquitectura, motivado por escenarios y desarrollado iterativamente. 



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. Cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. 

La arquitectura del software se trata de abstracciones, de descomposición y composición, de estilos y estética. También tiene relación con el diseño y la implementación de la estructura de alto nivel del software. Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, así como también otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad del sistema. Bueno pues, en el modelo de Kruchten, propone un sistema de software en 4 vistas bien diferenciadas, cada una de estas vistas ha de mostrar toda la arquitectura del sistema de  software que se este documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del software.

Para entender mejor este concepto, podemos tomar de ejemplo, si un arquitecto nos enseña el plano de una casa, nos esta enseñando una vista de la casa, pero en el momento en el que nos explica que significado tienen cada símbolo, por ejemplo que determinado símbolo representa una puerta, nos esta dando su punto de vista para entender mejor el plano. si luego nos muestra otro plano en donde se muestren diferentes símbolos con otras representaciones de la casa, nos dara otro punto de vista.

Esto para comprender mejor los puntos de vista, ahora podemos ver mejor cada una de las vistas que propone el modelo:


  • La vista lógica describe el modelo de objetos del diseño cuando se usa un método de diseño orientado a objetos. Para diseñar una aplicación muy orientada a los datos, se puede usar un enfoque alternativo para desarrollar algún otro tipo de vista lógica, tal como diagramas de entidad-relación.
  • La vista de procesos describe los aspectos de concurrencia y sincronización del diseño. 
  • La vista física describe el mapeo del software en el hardware y refleja los aspectos de distribución. 
  • La vista de desarrollo describe la organización estática del software en su ambiente de desarrollo.

Como parte final, están los escenarios los cuales constituyen la quinta vista. y es que los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas cuatro vistas, pero estas son ilustrarlas en un conjunto reducido de casos de uso o escenarios,  La arquitectura evoluciona parcialmente a partir de estos escenarios. 

Los escenarios son de alguna manera una abstracción de los requisitos mas importantes. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de interacción de objetos. Esta vista es redundante con las otras (y por lo tanto “+1”), pero sirve a dos propósitos principales:



  • Como una guía para descubrir elementos arquitectónicos durante el diseño de arquitectura tal como lo describiremos mas adelante 
  • Como un rol de validación e ilustración después de completar el diseño de arquitectura, en el papel y como punto de partido de las pruebas de un prototipo de la arquitectura. 

http://jarroba.com/modelo-41-vistas-de-kruchten-para-dummies/
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf


LENGUAJES DE PATRONES DE ARQUITECTURA DE SOFTWARE

Como siempre en cada entrada de este blog, lo que trato es de compartir temas relacionados con la clase y en esta ocasión encontré un articulo de la universidad de Pereira algo interesante, el cual hablan un poco de la arquitectura de software visto como una herramienta de ayuda y su vez resaltando el arte que esta contiene, profundizando hasta el tema de lenguajes de patrones de arquitectura de software. Lo que intentare en esta entrada sera de resaltar las características mas importantes que considero encontrados en este articulo.



Como primera medida me parece importante dar una referencia de la definición de arquitectura de software, que de manera general, se define como un nuevo paradigma o nueva forma de ver un sistema de información desde un punto de vista holístico, donde cada componente afecta los requerimientos fundamentales, ya sean funcionales o no funcionales. Esta disciplina aborda estos requerimientos rigurosamente y garantiza un buen diseño de la aplicación final, lo que redunda en mejor calidad, un mayor retorno de inversión de los proyectos y garantiza una mejor mantenibilidad de los sistemas de información construidos. Otra definición es la de George Fairbanks quien define la Arquitectura de Software como: La ciencia que trata el diseño de un sistema de información y del impacto de sus cualidades como: desempeño, seguridad, modificabilidad entre otras.

De forma histórica y evolutiva, el articulo muestra el cambio que se tuvo de la ingeniería de software a la arquitectura de software.

La Ingeniería de Software tuvo sus inicios en la década de los sesenta y a partir de allí a evolucionado de forma constante a través de las últimas seis décadas. En los años cincuenta se inició con el intentó imitar la ingeniería de hardware y se pensó en ese entonces que la utilización del método científico brindaría un soporte investigativo suficiente para obtener un proceso técnico coherente. Finalizando el siglo XX la ingeniería evolucionó como un área de estudio más estructurada y con fundamentos teóricos fuertes. Desde entonces la voluntad de los ingenieros fue de mejorar la calidad del software construido y de dar herramientas que facilitaran el trabajo a diseñadores e implementadores de sistemas de información en general.



Dominios específicos de aplicación


Los lenguajes de patrones han ocupado un lugar muy importante en los diseños de Arquitectura de Software. Se aplican tanto en proyectos de investigación y como en proyectos comerciales de desarrollo de software.

Una ejemplo de cómo los lenguajes de patrones pueden ser usados en dominios específicos se puede observar en el proyecto realizado por IBM donde se define un lenguaje de patrones para aplicaciones eBusiness. Este lenguaje divide los patrones de arquitectura en cuatro categorías: Patrones de negocios, patrones de integración, patrones de aplicación y patrones de ejecución, los cuales parten la arquitectura completa en tres capas principales como se sigue: Capa de negocios, capa de integración y Middleware o Capa de infraestructura. A continuación se define cada uno de las categorías que conformaron el lenguaje propuesto.

Patrones de negocio: mapea las interacciones entre los actores del negocio y las funcionalidades del sistema en particular. Patrones de Integración: Estos se definen como ortogonales a la capa de negocios, creando soluciones particulares que al integrarse soportan las funcionalidades de un sistema en particular.
Patrones de Aplicación: Estos patrones refinan los patrones de negocio e integración subdividiendo los subsistemas en componentes que proveen interfaces claras de implementación de funcionalidades del sistema a diseñar.
Patrones de Ejecución: Refinan los componentes del patrón de aplicación descomponiéndolos en componentes más pequeños sobre la infraestructura o middleware. Ya en este lenguaje los patrones intervienen directamente en la capa física de la aplicación con infraestructura y tecnología.

Esta subdivisión de patrones permite una variedad de soluciones de diseño reusables por diversas aplicaciones en este dominio en particular.

Los Lenguajes de Patrones citados anteriormente han sido utilizados por la industria, y estos se originaron de proyectos de investigación. Otras universidades e investigadores han desarrollado diversos Lenguajes los cuales hoy en día se han convertido en estándares de facto. A continuación se mencionan algunos estos.



http://200.21.217.140/index.php/revistaciencia/article/view/8595

domingo, 23 de agosto de 2015

PLANEANDO UN SISTEMA DE INFORMACION


A través de los años, se han evaluado numerosos intentos de modernizar sistemas de información; se han encontrado grandes problemas como altos costos, largos retrasos en el desarrollo y sistemas que no satisfacen las necesidades del usuario.


En muchos casos, estos defectos en el desarrollo ocurrieron por una inadecuada planeación detallada para identificar necesidades futuras y actuales de los usuarios y una prematura decisión a un específico diseño que no consideró alternativas de solución o que tan bien satisficieran las necesidades de los usuarios. 

Tiendo este preámbulo, podemos ver que gran parte del éxito de un sistema de información, comprende su planeación y es allí que buscando alguna información sobre esto, encontré un artículo en donde plantean una ideas del cómo se puede llegar a realizar esta planeación para que el sistema de información vaya a acorde con los principios de la organización y pueda cumplir con éxito los objetivos por los cuales se está creando. 



La planificación de Sistemas de Información (PSI) tiene como objetivo la obtención de un marco de referencia para el desarrollo de sistemas de información que responda a los objetivos estratégicos de la organización. Este marco de referencia consta de:
  • Una descripción de la situación actual, que constituirá el punto de partida del Plan de Sistemas de Información. Dicha descripción incluirá un análisis técnico de puntos fuertes y riesgos, así como el análisis de servicio a los objetivos de la organización.
  • Un conjunto de modelos que constituya la arquitectura de información. 
  • Una propuesta de proyectos a desarrollar en los próximos años, así como la prioridad de realización de cada proyecto. 
  • Una propuesta de calendario para la ejecución de dichos proyectos. 
  • La evaluación de los recursos necesarios para los proyectos a desarrollar en el próximo año, con el objetivo de tenerlos en cuenta en los presupuestos. Para el resto de proyectos, bastará con una estimación de alto nivel. 
  • Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos mecanismos de evaluación adecuados. 
La perspectiva del plan debe ser estratégica y operativa, no tecnológica. Es fundamental que la alta dirección de la organización tome parte activa en la decisión del Plan de Sistemas de Información con el fin de posibilitar su éxito. La dirección debe convencer a sus colaboradores más directos de la necesidad de realización del plan; de su apoyo de forma constructiva, mentalizándose de que la ejecución del mismo requerirá la utilización de unos recursos de los cuales son responsables.

La presentación del Plan de Sistemas de Información y la constitución del equipo supone el arranque del proyecto y es fundamental que las más altas instancias de la organización estén implicadas en ambos, dando el apoyo necesario y aportando todo tipo de medios. 

Explicar el plan a las personas de la organización y a las unidades organizativas afectadas sobre las que recaerá el Plan, el apoyo de los altos directivos y la cualificación de los recursos de las distintas unidades implicadas, serán factores críticos de éxito del Plan de Sistemas de Información.

El nivel de detalle con el que se hará el estudio de la situación actual dependerá de la existencia de documentación actual, de si hay personas que conozcan dicha documentación y de la predisposición a una sustitución total o parcial por sistemas de información nuevos. En cualquier caso, como paso previo para detectar aspectos importantes que puedan afectar a la organización, es necesario investigar sus puntos fuertes, áreas de mejora, riesgos y amenazas posibles y hacer un diagnóstico de los mismos.

Para la elaboración del Plan de Sistemas de Información se estudian las necesidades de información de los procesos de la organización afectados por el Plan, con el fin de definir los requisitos generales y obtener modelos conceptuales de información. Por otra parte se evalúan las opciones tecnológicas y se propone un entorno. Tras analizar las prioridades relacionadas con las distintas variables que afectan a los sistemas de información, se elabora un calendario de proyectos con una planificación lo más detallada posible de los más inmediatos. Además, se propone una sistemática para mantener actualizado el Plan de Sistemas de Información para incluir en él todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo.


http://www.bocc.ubi.pt/pag/urrutia-amaia-planificacion.pdf
http://manuel.cillero.es/doc/metrica-3/procesos-principales/psi

sábado, 22 de agosto de 2015

DESCRIBIENDO LA ARQUITECTURA DE SOFWARE


La complejidad de los sistemas hechos por el hombre ha llegado a un nivel sin precedentes. Esto ha dado lugar a nuevas oportunidades, pero también a un aumento de desafíos para las organizaciones que crean y utilizan sistemas. Los conceptos, principios y procedimientos de arquitectura que se aplican cada vez más para ayudar a manejar la complejidad que enfrentan los actores de los sistemas.

La nacionalización de la arquitectura de un sistema, tal como se expresa en una descripción de la arquitectura, ayuda a la comprensión de la esencia del sistema y propiedades clave relativas a su comportamiento, composición y evolución, que a su vez afecta a preocupaciones tales como: la viabilidad, utilidad y facilidad de mantenimiento del sistema.

Esta norma se puede utilizar para establecer una práctica coherente para desarrollar descripciones de la arquitectura, los marcos de arquitectura y descripción de las arquitecturas establecidas en el marco de un ciclo de vida y sus procesos (no definido en esta Norma Internacional).

De la norma 1471 a la 42010

                           


La IEEE 42010 limita y organiza los frameworks de arquitectura y lenguajes de descripción de arquitectura (ADL). Esta norma proviene de su predecesora la IEEE 1471, con la IEE 42010, se buscó contribuir en los siguientes aspectos:
  • Que la arquitectura de un sistema sea considerada fundamental en el contexto del sistema y su desarrollo.
  • Documentación específica, organizada y clara de la arquitectura de un sistema.
  • Que la arquitectura de un sistema demuestre como la misma informa de las necesidades del sistema a todas las partes interesadas de una manera clara y coherente.
  • Que la arquitectura permita identificar todas las reglas del sistema a partir del analisis de cada punto de vista de la arquitectura.
  • Que las necesidades puedan ser capturadas a través de un modelo conceptual o meta modelo, estableciendo los conceptos clave y términos para hablar de arquitectura y descripción de la misma.

Modelo conceptual


En la figura se representan los conceptos clave relativos a los sistemas y sus arquitecturas como un contexto para la comprensión de la práctica de la descripción de la arquitectura.




El sistema de expresión se utiliza en esta Norma Internacional para referirse a las entidades cuyas arquitecturas son de interés. El término pretende incluir, pero no se limita a las entidades dentro de los siguientes dominios:
  • Sistemas: Los sistemas que son artificiales y se puede configurar con uno o más de los siguientes: el hardware, el software, los datos, los seres humanos, los procesos, los procedimientos, instalaciones, materiales y entidades presentes en la naturaleza.
  • Productos de software y servicios que se describen en [ISO / IEC 12207];
  • Sistemas intensivos en software: cualquier sistema en el que el software contribuye con influencias esenciales para el diseño, construcción, implementación y evolución del sistema en su conjunto" para abarcar "las aplicaciones individuales, sistemas en el sentido tradicional, subsistemas, sistemas de sistemas, líneas de productos, familias de productos, empresas integrales y otras agrupaciones de interés.


Vistas de arquitectura



Una descripción de arquitectura  deberá incluir exactamente una vista de arquitectura por cada punto de vista de arquitectura usado.
  1. Cada vista de arquitectura deberá adherir las convenciones de los puntos de vista que gobiernan la arquitectura.
  2. Cada vista de arquitectura deberá incluir:
    • Información principal y complementaria según lo especificado por la organización del proyecto.
    • Identificación del punto de vista que gobierna la vista.
    • Modelos de arquitectura que se ocupan de todos los problemas enmarcados por el punto de vista que lo gobierna y que cubra todo el sistema desde ese punto de vista.
    • El registro de los aspectos conocidos en la vista con respecto al punto de vista que lo gobierna.

Modelos de arquitectura


Una vista de arquitectura deberá  estar compuesto de uno o más modelos de arquitectura. Cada modelo de arquitectura deberá incluir la versión especificada por la organización y/o proyecto. Cada modelo de arquitectura deberá identificar el tipo de modelo que lo gobierna y adherirse a las convenciones de ese tipo de modelo.


Términos y definiciones


Architecting: proceso de concebir, definir, expresar, la documentación, la comunicación, la certificación de una aplicación adecuada de mantenimiento y mejora de una arquitectura a lo largo del ciclo de vida de un sistema

Arquitectura: (Sistema) conceptos o propiedades de un sistema en su entorno plasmada en sus elementos, relaciones, y en los principios de su diseño y evolución fundamentales

Descripción de la arquitectura: producto de trabajo se usa para expresar una arquitectura

Marco de arquitectura: convenciones, principios y prácticas para la descripción de arquitecturas establecido dentro de un dominio específico de aplicación y / o de la comunidad de partes interesadas

Vista de la arquitectura: producto de trabajo que expresa la arquitectura de un sistema desde la perspectiva de las preocupaciones específicas del sistema

Arquitectura mirador: producto de trabajo que se establecen los convenios para la construcción, interpretación y uso de los puntos de vista de arquitectura para enmarcar las preocupaciones específicas del sistema

Preocupación: (Sistema) de participación en un sistema correspondiente a una o más de sus grupos de interés

Ambiente: (Sistema) contexto determinar el entorno y las circunstancias de todas las influencias sobre un sistema

Tipo de Modelo: convenciones para un tipo de modelado.

Stakmeholder: Equipo, organización o clases de la misma, que tenga un interés en un sistema.




http://cabibbo.dia.uniroma3.it/asw/altrui/iso-iec-ieee-42010-2011.pdf
https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-1:v1:en

domingo, 16 de agosto de 2015

CONCEPTOS CLAVES


SISTEMA DE INFORMACIÓN

Podemos definir un sistema de información como:
  • Combinación de tecnología de la información y actividades humanas que usan esa tecnología para soportar operaciones, administración y toma de decisiones.
  • Esta compuesto por datos y procesos.
  • Su propósito es tener la información correcta, para las personas correctas, en el momento correcto, en la cantidad correcta, y en un formato correcto. 


AXIOMA

La palabra axioma proviene del sustantivo griego αξιωμα, que significa «lo que parece justo» o, que se le considera evidente, sin necesidad de demostración. El término viene del verbo griego αξιοειν (axioein), que significa «valorar», que a su vez procede de αξιος (axios): «valioso» o «digno». Entre los filósofos griegos antiguos, un axioma era lo que parecía verdadero sin necesidad de prueba alguna.

Los axiomas son importantes en los modelos de información ya que son los elementos de calificación los cuales le dan valor y significado al modelo presentado; y se presentar como verdades irrefutables.






jueves, 13 de agosto de 2015

INTRODUCCION

En la vida del hombre desde sus inicios, la información ha hecho parte fundamental en este,y ha evolucionado paralela y conjuntamente hasta convertirse en parte indispensable e indiscutible de nuestra rutina diaria a todos los niveles. 

A medida que crecía gradualmente la importancia de la informacióntambién variaba la manera en que esta se gestionaba, llegando a crear disciplinas estrictamente relacionadas con el estudio de información, y en la actualidad es una materia importante de aprendizaje de los inicios nuestra formación así como en parte indisoluble de la mayoría de las empresas a nivel mundial. 

En este progresar del ser humano, de las sociedades y de las tecnologías es que nacieron los sistemas de información (SI), siendo cada vez mas favorecidos en las empresas y organizaciones, y tomando mayor importancia para este. 

Actualmente los sistemas de información apoyados en herramientas ofimáticas han alcanzado un gran auge, a tal punto de casi desplazar los tradicionales formatos de papel. Algunos de los elementos mas importantes son los datos, la información y el conocimiento; entidades que suponen la materia prima de los sistemas de información en las organizaciones.

.