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