Mostrando entradas con la etiqueta Sistemas. Mostrar todas las entradas
Mostrando entradas con la etiqueta Sistemas. Mostrar todas las entradas

miércoles, 21 de noviembre de 2012

Revisando: Windows Server - Máquinas virtuales con Hyper-V

  • Hyper-V [Wikipedia]
  • Instalación y configuración de un servidor de Hyper-V
  • Creación, configuración y uso de máquinas virtuales con Hyper-V
  • Soporte nativo para VHDs (Discos Duros Virtuales)



Hyper-V [Wikipedia]

Fuente:  es.wikipedia.org 















Arquitectura de Hyper-V.
Microsoft Hyper-V es un programa de virtualización basado en un hipervisor para los sistemas de 64-bits1 con los procesadores basados en AMD-V o Tecnología de virtualización Intel (el instrumental de gestión también se puede instalar en sistemas x86). Una versión beta de Hyper-V se incluyó en el Windows Server 2008 y la versión definitiva se publicó el 26 de junio de 2008.2
La versión actual de Hyper-V, incluida en Windows Server 2008 R2 como rol de servidor, agregó mejoras y nuevas funcionalidades como Live Migration, almacenamiento en máquinas virtuales dinámicas, y compatibilidad mejorada con procesadores y redes3

Referencias

  1. ↑ Paul Thurrott. «Windows Server Virtualization Preview». Consultado el 25-09-2007.
  2. ↑ «Hyper-V RTM announcement available today from the microsoft download centre». Consultado el 26-06-2008.
  3. ↑ «Novedades de Hyper-V». Consultado el 31-10-2011.

Enlaces externos

Aprendizaje

Descarga de prueba



Instalación y configuración de un servidor de Hyper-V

Fuente: youtube.com

Instalación del rol de Hyper-V en un servidor con Windows Server 2008 R2, así como una demostración de los cambios que la arquitectura de hipervisor usada por Hyper-V provoca en el sistema operativo anfitrión (partición primaria). También se presentará la consola de administración de Hyper-V y sus funcionalidades.

Subido por  el 03/01/2011



Creación, configuración y uso de máquinas virtuales con Hyper-V

Fuente:  youtube.com

Creación de una máquina virtual usando el asistente de Hyper-V y preparación para la instalación de un sistema operativo basado en el uso de una imagen ISO de un DVD de instalación. Presentación de todas las opciones de configuración de hardware virtual y demostración del uso de la herramienta de conexión con máquina virtual.


Subido por  el 03/01/2011
Amplía información:
TechNet Edge España: http://technet.microsoft.com/es-es/edge
TechNet Library: http://technet.microsoft.com/es-es/library/dd277881.aspx


Soporte nativo para VHDs (Discos Duros Virtuales)

Fuente: youtube.com

Instalación, desde cero, de un sistema operativo basado en disco duro virtual de Microsoft, en un equipo en el que ya hay instalado otro sistema operativo. Presentaremos algunas de las opciones de la herramienta diskpart para gestionar discos físicos y virtuales, así como particiones. Por último se muestran algunas de las opciones de gestión de discos duros virtuales desde el administrador de discos de Windows 7 y Windows Server 2008 R2.


Subido por  el 04/01/2011



  


Publicado por aegxxi-labBlgr en 2:39 0 comentarios
Etiquetas: ,

Revisando: Windows Server - RAID

  • RAID - Introducción I
  • RAID - Introducción II
  • RAID - Introducción III
  • RAID - Volumenes dinámicos a básicos
  • RAID - Windows 2003 Server - Raid 1 - Parte 1
  • RAID - Windows 2003 Server - Raid 1 - Parte 2
  • RAID - Windows 2003 Server - Raid 1 - Recuperar - Parte 1
  • RAID - Windows 2003 Server - Raid 1 - Recuperar - Parte 2
  • RAID - Windows 2003 Server - Raid 1 - Quitar
  • RAID - Windows 2003 Server - Raid 5
  • RAID - Windows 2003 Server - Raid 5 - Recuperar
  • RAID - Windows 2003 Server - Raid 5 - Quitar
  • Raid 0 en Windows 2003 Server
  • RAID - Windows 2003 Server - Raid 0
  • RAID - Windows 2003 Server - Raid 0 - Eliminar Volumen
  • INSTALANDO VOLUMENES RAID WINDOWS SERVER 2008 



RAID - Introducción I

Fuente: youtube.com 


Subido por  el 18/02/2009



RAID - Introducción II

Fuente: youtube.com


Subido por  el 18/02/2009



RAID - Introducción III

Fuente:  youtube.com


Subido por  el 18/02/2009



RAID - Volumenes dinámicos a básicos

Fuente:  youtube.com

RAID - Volumenes dinámicos a básicos


Subido por  el 18/02/2009



RAID - Windows 2003 Server - Raid 1 - Parte 1

Fuente:  youtube.com

Material didáctico multimedia de apoyo para Ciclos Formativos de Informática sobre plataforma Moodle. Redes Locales y WAN
http://www.ciclosinformatica.net


Subido por  el 22/10/2010



RAID - Windows 2003 Server - Raid 1 - Parte 2

Fuente: youtube.com

Material didáctico multimedia de apoyo para Ciclos Formativos de Informática sobre plataforma Moodle. Redes Locales y WAN
http://www.ciclosinformatica.net


Subido por  el 22/10/2010



RAID - Windows 2003 Server - Raid 1 - Recuperar - Parte 1

Fuente: youtube.com

Material didáctico multimedia de apoyo para Ciclos Formativos de Informática sobre plataforma Moodle.
Redes Locales y WAN


Subido por  el 21/10/2010



RAID - Windows 2003 Server - Raid 1 - Recuperar - Parte 2

Fuente: youtube.com

Material didáctico multimedia de apoyo para Ciclos Formativos de Informática sobre plataforma Moodle.
Redes Locales y WAN


Subido por  el 21/10/2010



RAID - Windows 2003 Server - Raid 1 - Quitar

Fuente:  youtube.com


Subido por  el 18/02/2009


RAID - Windows 2003 Server - Raid 5

Fuente: youtube.com 


Subido por  el 18/02/2009



RAID - Windows 2003 Server - Raid 5 - Recuperar

Fuente: youtube.com


Subido por  el 18/02/2009



RAID - Windows 2003 Server - Raid 5 - Quitar

Fuente:  youtube.com 


Subido por  el 18/02/2009



Raid 0 en Windows 2003 Server

Fuente: youtube.com


Subido por  el 21/05/2007



RAID - Windows 2003 Server - Raid 0

Fuente:  youtube.com 


Subido por  el 18/02/2009



RAID - Windows 2003 Server - Raid 0 - Eliminar Volumen

Fuente:  youtube.com 


Subido por  el 18/02/2009



INSTALANDO VOLUMENES RAID WINDOWS SERVER 2008 

Fuente: youtube.com,  youtube.com

Parte 1:

Parte 2:

Publicado el 03/08/2012 por 


Publicado por aegxxi-labBlgr en 2:01 0 comentarios
Etiquetas: ,

domingo, 10 de junio de 2012

Revisando: El Analista Funcional (10/06/2012)


  • Analista Funcional en Argentina.
  • Desarrollo de software. El analista funcional y el analista orgánico.
  • El rol del Analista Funcional en equipos ágiles.
  • La importancia de un buen análisis funcional.
  • Actualidad y Tendencias: Analista (Funcional y de Testing).
  • ¿El Analista Funcional debe ser Técnico?.
  • ¿Dónde esta el límite entre un ‘Analista de Testing’ y un ‘Analista Funcional’?.
  • Análisis Funcional – Requisitos del mercado.



Analista Funcional en Argentina.

Fuente: marianariva.blogspot.com.ar

Función de un analista funcional por definición
  • Relevar y gestionar las necesidades funcionales del cliente en la elaboración y ejecución del proyecto, cumpliendo con los estándares y la documentación requerida por las normas de calidad de la empresa. Relevar las necesidades del cliente considerando las características de su operatoria. Especificar los requerimientos y funcionalidades de la solución. Determinar la viabilidad de adaptación del sistema de acuerdo a las características del negocio del cliente. Actualizar información sobre nuevas tecnologías y productos propiciando el aprendizaje permanente.

Tareas que actualmente el mercado requiere de un analista funcional
  • Relevamiento, analisis y documentación de procesos integrales, requerimientos técnicos, requerimientos de negocio, etc
  • Validación de Modelos de Diseño
  • Entrevistas con usuarios y proveedores
  • Revisión de estimaciones
  • Especificación de diseños funcionales de casos de uso
  • Emisión de procedimientos
  • Generar y mantener documentación sobre los circuitos operativos, sistemas que permita su análisis y mejoramiento.
  • Armado de lotes de prueba
  • Capacitación a usuarios
  • Detectar la necesidad de nuevos sistemas o proponer mejoras
  • Analizar alternativas de implementación
  • Parametrización
  • Implementar soluciones junto a el equipo de desarrollo
  • Soporte post implementación
  • Generar informes / reportes
Conocimientos técnicos requeridos
  • Metodologías formales de análisis y desarrollo
  • UML
  • SQL / PLSQL
  • Datawarehousing
  • Orientación de Objetos
  • Herramientas automáticas para soporte de procesos de testing
  • Herramientas Office / Project
Compentencias requeridas
  • Trabajo en equipo
  • Capacidad de análisis
  • Buena comunicación oral y escrita
  • Predisposición hacia el usuario
Actualmente, los requerimientos de analistas funcionales en el mercado son varios. Cada medio de publicación de búsquedas actualmente posee mas de 150 ofertas de este perfil.
En épocas pasadas, el analista funcional realizaba diversas y variadas funciones que con el correr del tiempo y la evolución de los equipos de desarrollo de sistemas en el país , han ido tomando nuevos caminos hacia la especialización.
Actualmente existen personas que se dedican SOLAMENTE al testing, al seguimiento de tiempos y aseguramiento de los mismos, a la calidad, documentación o administracion de requerimientos.
El analista funcional sigue teniendo un perfil amplio, que no solamente interviene en la primera etapa clásica del proyecto ( relevamiento, análisis y diseño) sino que las nuevas metodologías hace que intervenga constantemente y su tarea sea generalicia.
Hay requerimientos técnicos que siempre son bienvenidos, especialmente base de datos y lenguajes de consulta sobre las mismas.
También el analista debe conocer las diferentes arquitecturas de sistemas, para poder entender, diseñar y hasta implementar sistemas en tales entornos.
La comunicación debería ser su fuerte. Con el usuario, con el cliente interno, con el equipo completo.

Publicado por 



Desarrollo de software. El analista funcional y el analista orgánico.

Fuente: jummp.wordpress.com

¿Qué tareas realiza un analista funcional?, ¿cuáles un analista orgánico?. Depende de la entidad en la que trabajen y del proyecto en sí, la limitación de las funciones de cada uno.
Por regla general, se considera analista funcional a quien se encarga de la recopilación del catálogo de requisitos y de la definición de los casos de uso (o historias de usuario). Su objetivo es describir las funcionalidades del sistema y su comportamiento mediante el estudio de las necesidades del usuario. Su trabajo es muy importante y sin embargo no se le da el valor que se merece, ya he comentado en más de una ocasión que lo técnico suele resultar más glamuroso.
Los sistemas se desarrollan para el usuario y para que sean de utilidad hay que saber captar qué es lo que quiere el usuario y cómo desea interactuar con el sistema.
La técnica es muy importante, pero no lo es menos que la vertiente funcional, todos suman y todos restan si no hacen adecuadamente su trabajo.
El analista orgánico se encarga del diseño que no es otra cosa que la particularización de las necesidades del usuario a una implementación concreta. Para un proyecto concreto vendría a ser el arquitecto de la solución, ya que entraría incluso a definir el framework con el que se va a trabajar.
Lo habitual en los proyectos de desarrollo de software es encontrarnos con analistas que realizan las dos funciones, aunando en un solo perfil lo funcional y lo técnico. Tiene como principal ventaja que no es necesario transferir el conocimiento entre diferentes fases o procesos del desarrollo y que cada tarea es realizada por un experto en la misma. El principal inconveniente es que no existe una especialización, no obstante, hay que ser bastante bueno en uno de los dos perfiles para marcar de manera clara la diferencia respecto a analistas que realicen ambos trabajos (ahora, quien las marca es que es muy bueno y por tanto, vale mucho dinero).
En desarrollos iterativos e incrementales con una orientación ágil lo deseable es que la evolución del desarrollo sea rápida (realizándose los incrementos con cierta frecuencia) y resulta fundamental la participación del usuario, a ser posible como una pieza más del equipo de proyecto, lo normal es que no exista distinción entre analista funcional y orgánico, si bien, tendrá una vertiente más técnica, por las características particulares de este tipo de desarrollos. Existirán excepciones, en proyectos que por su naturaleza requiera de desarrolladores que den apoyo funcional, por la experiencia que tengan en un tipo de negocio concreto.



El rol del Analista Funcional en equipos ágiles.

Fuente: maypun.blogspot.com.ar


Tradicionalmente el Rol del Analista Funcional o Ingeniero de Requerimientos ha sido definido en el contexto de un proyecto utilizando el modelo cascada del ciclo de desarrollo de software (SDLC), donde el Analista recolecta todos los requerimientos y reglas de negocio en el comienzo, antes de empezar a desarrollar. Sin embargo, la demanda acelerada de soluciones ha modificado la dinámica del desarrollo de sistemas a un enfoque más ágil, donde los requerimientos y las reglas de negocio se definen al mismo tiempo que se desarrolla el software, en ciclos iterativos.


De aquí que surje la pregunta "¿Existe la necesidad del rol de Analista Funcional en un equipo de desarrollo de software ágil?"

Si el lector es de los que piensan que el rol del Analista Funcional no es necesario en el enfoque ágil, le pregunto si ha evaluado fehacientemente cómo se ve expandido el rol del desarrollador al incorpor las actividades necesarias para relacionarse directamente con el cliente.
Creo que independientemente del Ciclo de desarrollo de software elegido, el rol del analista funcional es necesario. En el caso del enfoque ágil, puede ser riesgoso para el proyecto que las funciones del Analista Funcional sean absorbidas por miembros del equipo de desarrollo.

Para los propósitos del artículo, tomaremos a Scrum como método ágil de desarrollo de software.


El Rol del Analista Funcional como Facilitador

Diferenciaremos el rol del Dueño del Producto (Product Owner) en Scrum, que es el de asegurar que se satisfagan las necesidades del negocio, del rol del del Analista Funcional que es traducir la visión del Dueño del Producto en el Listado de Requerimientos (Backlog) que servirán como entrada al equipo de desarrollo.
En algunos proyectos, ambos roles pueden estar representados en la misma persona.

El Analista Funcional funciona como enlace entre los interesados en el proyecto (stakeholders) y el equipo de desarrollo. Para ello, utiliza distintas técnicas y habilidades (tormentas de ideas, votación de las funcionalidades, análisis de costo-beneficio, generar participación activa, mantener el trabajo en foco, etc.) para asistir a los líderes del proyecto en el logro de los objetivos propuestos.


En proyectos de desarrollo utilizando el ciclo ágil, el Analista Funcional contribuye en dos actividades principales: asegurar el cumplimiento de la Visión y Alcance, y moderar las reuniones de Planificación y Revisión de cada Iteración.
Todo proyecto comienza con una definición de la Visión y Alcance de la solución a desarrollar para cumplir con una necesidad de negocio. En el enfoque ágil, la visión y el alcance se definen en un conjunto de reuniones, cada una representando una porción de la visión y alcance en ese momento, que es determinada por los interesados.

El desafío para el patrocinador del proyecto es el de asegurar que la visión y alcance del proyecto sean resultado de un esfuerzo colaborativo entre todos los interesados en el proyecto, de aquí la necesidad del rol del Analista Funcional como facilitador. El Analista Funcional debe utilizar técnicas que faciliten que todos los interesados en el proyecto participen, colaboren y lleguen a un consenso sobre el conjunto priorizado de funcionalidades de alto nivel que deben ser desarrolladas. Debe asegurarse de que estas funcionalidades están justificadas y que tienen correspondencia con las necesidades de negocio. Todas las funcionalidades estarán sujetas a la aprobación del patrocinador del proyecto.


Reuniones de Planificación, Sincronización y Retrospectiva

Luego de que se identificaron el conjunto de funcionalidades de alto nivel, las reuniones del equipo de desarrollo comienzan con un consenso sobre cuáles de ellas serán desarrolladas en la primera iteración. Una vez que se seleccionó un conjunto finito de funcionalidades y se les asignó una fecha de entrega (time-box), todos los días se realizan reuniones de sincronización para revisar el estado de avance y eliminar obstáculos. Finalmente, se valida el prototipo y se implementa, realizando luego la reunión de retrospectiva y volviendo al inicio con una nueva reunión de planificación de las funcionalidades a incluir en la siguiente iteración.

En estas reuniones, surge el mismo desafío, asegurarse de que el software desarrollado sea producto del esfuerzo colaborativo y consenso de los participantes. Una vez más surge la necesidad del rol del Analista Funcional como facilitador.
Estas reuniones involucran detalles técnicos y del negocio vitales a los efectos de la solución a desarrollar:

  • Requerimientos funcionales
  • Reglas de negocio asociadas
  • Interfaz de usuario
  • Métodos técnicos de implementación


En las reuniones de sincronización, el rol del Analista Funcional es diferente del que tiene en las de planificación. En las reuniones de planificación, el Analista Funcional definió y ejecutó una agenda, en las de sincronización el rol es el de asistir a los interesados en el proyecto y al equipo de desarrollo para determinar los requerimientos del sistema, con el propósito de construir los prototipos que conformen de manera incremental el sistema a desarrollar.

El Rol del Analista Funcional facilita lo anterior mediante la utilización de herramientas de Modelado del Negocio para identificar y analizar requerimientos de usuario, requerimientos del sistema y reglas de negocio:
  • Diagramas de Actividad - procesos manuales
  • Casos de Uso - requerimientos funcionales
  • Diagramas de Entidad-Relación
  • Diagramas de Transición de estados
  • Diagramas de clases - para implementaciones orientadas a objetos



La rigurosidad con la cual el Analista Funcional debe modelar el negocio es determinada por las necesidades del equipo de desarrollo. En lugar de realizar una documentación exhaustiva y detallada de los requerimientos como en el modelo en cascada (waterfall SDLC), el Analista genera la documentación "suficiente y necesaria" que permita que el equipo de desarrollo codifique los prototipos.


Conclusión

Mientras se van definiendo, priorizando, analizando y/o desarrollando las funcionalidades, el Analista Funcional se asegura que los interesados en el proyecto aprueben la solución final. El Rol del Analista Funcional podría ser llevado a cabo por un miembro del equipo de desarrollo, sin embargo, se debe considerar el riesgo que involucra que una persona menos entrenada y con menos experiencia en el Análisis Funcional sea la responsable de construir consenso entre los participantes. El nivel de productividad y consenso estará directamente relacionado con el uso efectivo de herramientas de Análisis Funcional.
Además, existe el riesgo de que los interesados en el proyecto y los desarrolladores se enfoquen en aspectos técnicos del prototipo en lugar de hacerlo en los requerimientos.

Es prudente evitar estos riesgos, y a los efectos de "asegurar" el éxito del equipo, la mejor práctica es que el rol del Analista Funcional se formalice en una persona que asista al equipo de desarrollo de software ágil.
Autor: Alejandro Grinsztajn

Fuente: Este artículo es un resumen y traducción del artículo de Mark A. Monteleone en www.batimes.com



La importancia de un buen análisis funcional.

Fuente: jummp.wordpress.com

De todos es sabido que cuanto antes se solucione un problema en un proyecto de desarrollo de software, menos coste tiene para el mismo y de ello salen beneficiados tanto proveedor como cliente.
Por ese motivo resulta esencial que un proyecto sea sólido desde la base, siendo la misma el análisis funcional, lo que hace que sea muy importante la figura del analista que es la persona o grupo de personas (si el proyecto es grande) que se tienen que encargar de entender, interpretar y traducir lo que el usuario demanda, sentando las bases de los posteriores procesos de diseño y construcción del sistema de información.
Hacer un buen análisis es una tarea bastante compleja, ya que resulta muy complicado obtener todos los requerimientos del usuario desde etapas muy tempranas, ya que por regla general el usuario empieza a descubrir el detalle de todo lo que quiere cuando empieza a utilizar el producto ya construido con ejemplos reales de su día a día de trabajo (también suelen comentar nuevos requisitos o enmendar requisitos previos, en otras etapas conforme se le vaya presentando la evolución del proyecto, de hecho no es malo que se corrijan, ya que cuanto más avanzado esté el proyecto, el esfuerzo de hacer los cambios es mucho mayor). De hecho es prácticamente inevitable no hacer evolutivos que solventen esos flecos que no se detectaron en análisis para dejar el producto lo más próximo posible a lo que los usuarios necesitan y demandan. Como consecuencia de lo anterior, y como es lógico, se puede considerar que un análisis funcional es más bueno conforme sea menor el número de ajustes que haya que hacer en etapas posteriores del proyecto.
Es importante matizar que un proyecto de desarrollo de software no es una barra libre y que es importante que el usuario conozca sus responsabilidades en el proceso de definición del sistema y que no se pueden estar cambiando de requisitos continuamente, como tampoco podría estar cambiando frecuentemente de opinión si le están construyendo una casa. Todo lo anterior además hay que compatibilizarlo con que todas las partes están interesadas en el que el proyecto vaya a buen término, por lo que tampoco es una buena política ser inflexibles en la modificación del catálogo de requisitos, porque si el resultado final no es el que quiere el usuario, el sistema de información tendrá muchas papeletas para no ser utilizado. Equilibrio complicado: evitar que los usuarios modifiquen continuamente requisitos y tener un poco de mano izquierda cuando se planteen esos cambios. Como ese equilibrio es complicado de mantener y es fuente frecuente de conflictos, hay que intentar que el análisis tenga la mayor calidad posible.
Hacer un análisis funcional por tanto es una tarea compleja, a lo que hay que sumar que en muchos casos hay que aprender mucho sobre el proceso de negocio que se pretende informatizar, para entender de mejor manera lo que el usuario demanda, ya que resulta todo más fácil si el lenguaje que se utiliza es el mismo. En muchas ocasiones esos procesos de negocio son tremendamente complejos y además se dispone también de poco tiempo para entenderlos, teniendo en cuenta que por regla general y como he comentado muchas veces en mi blog, los proyectos informáticos suelen estar infravalorados (por el que contrata y/o por el que es contratado (para conseguir el contrato)).
Dado que el análisis funcional consiste en abstraer un conjunto de necesidades de los usuarios es muy importante la implicación de los mismos y eso no siempre se consigue. Si los usuarios no están implicados, por muy buen analista funcional que tenga el proyecto, las probabilidades de que este salga mal crecen exponencialmente. Evidentemente un buen analista puede paliar esos huecos que deja el usuario e incluso conseguir una mayor participación de los usuarios, pero más tarde o más temprano los problemas aparecerán y al final siempre termina pagando el proyecto (en primera instancia) y el que lo desarrolla (en segunda). Por todo lo anterior, se puede pedir que un analista funcional aprenda un proceso de negocio complejo, que consiga extraer de los usuarios lo que buscan y necesitan y que además lo haga en un tiempo record, pero lo que no se le puede pedir es que haga magia y resuelva problemáticas que le trascienden, como el caso que he comentado de la inacción de los usuarios en determinados proyectos, siendo esa falta la implicación la primera causa de que un análisis no salga bien y por tanto una de las causas más importantes del fracaso de un proyecto y no se trata en este caso de tirar pelotas fuera y ponerme del lado de mis colegas de profesión, se trata de algo que he podido vivir en diferentes proyectos de manera muy directa.
Nadie es infalible y un analista funcional tampoco lo es. Habrá errores (independientemente de que la causa de los mismos sea provocada por circunstancias adversas en el proyecto o no), puede que en este proyecto sean muy pocos y que en otros sean mayores, por eso es importante que el analista lo tenga asumido desde un principio, como también lo es que de esos errores se debe aprender y que resultarán fundamentales en la formación del mismo. Al final esos errores terminan curtiendo y permiten que cada vez los análisis que se realicen sean mejores. Por tanto, la experiencia resulta importante. En cualquier caso, suponer un análisis perfecto es suponer que en un proyecto se dan circunstancias ideales y que todas las variables que pueden influir en que las cosas vayan mejor o peor, están todas a favor.
De todo lo comentado en los párrafos anteriores se extrae que es importante que un analista funcional sea un buen comunicador, primero con el usuario ya que resulta fundamental que el usuario conozca todo lo que hemos entendido y cómo se pretende llevar a cabo (no conseguir eso es ir a ciegas) y segundo con el equipo de proyecto ya que tiene que trasladar a documentación y hacerles entender la interpretación de lo que el usuario quiere y cómo lo quiere.
Un buen análisis funcional no asegura el éxito del proyecto, ya que la ejecución técnica del mismo también tiene un peso importante, pero lo que sí es seguro es que si el análisis funcional no es bueno, la ejecución técnica difícilmente puede salvar las deficiencias del mismo y tocará corregir el producto una vez construido y además, por regla general, en diferentes evoluciones, lo cual es muy costoso y tampoco asegura que ese árbol que empezó torcido, termine por enderezarse.



Actualidad y Tendencias: Analista (Funcional y de Testing).

Fuente: testingbaires.com

Actualidad y Tendencias: Analista (Funcional y de Testing) para proyectos SAP, Ágiles y WTF

Entiendo que la figura del “Analista Funcional” dentro de un proyecto, es aquella persona o grupo de personas que se ocupa/n de comprender, interpretar, y convertir la demanda o requerimiento del cliente o ‘usuario final’ en una especificación funcional, para permitir y facilitar que el desarrollador o equipo de desarrolladores construya el proceso de diseño y desarrollo de la solución informática, asi como también que el ‘probador’ o ‘tester’ pueda validar y verificar el desarrollo.
Hoy en día existen diferentes tipos de ‘Analistas Funcionales’ dependiendo del contexto de proyecto en el que se encuentre, ya que la diversidad de industrias requieren para sus soluciones, la ejecución de proyectos SAP,Ágiles ó Tradicionales/Modelo en cascada (Waterfall SDLC).
El DEBATE de este artículo lo pueden seguir en el grupo de discusión en Linkedin: TESTING & QA,
A continuación, expongo algunas de las funciones básicas que entiendo tienen los distintos tipos de Analistas Funcionales y luego, una serie de preguntas que procuraré encontrar respuestas, buscándolas en la net, o en libros, o bien, a partir de debates que genere en distintos foros.

Analista Funcional para proyectos SAP
Básicamente. algunas de sus funciones son:
  • Analizar especificaciones;
  • Preparar los casos de uso;
  • Analizar incidencias;
  • Documentar las soluciones a incidencias;
  • Ajustar configuraciones;
  •  Ejecutar pruebas unitarias;
  • Atender las consultas de usuarios;
  • Realizar actividades de soporte, mantenimiento correctivo y evolutivo de módulos implementados


Analista Funcional para proyectos Agiles
Básicamente. algunas de sus funciones son:
  • Traducir la visión del Dueño del Producto (Product Owner) a un Listado de Requerimientos (Backlog), generando la documentación suficiente y necesaria
  • Asegurar que se cumpla la visión y alcance del proyecto
  • Moderar y Facilitar las reuniones de planificación y revisión de cada iteración
  • Definir y ejecutar la agenda en las reuniones de planificación
  • Asistir a los stakeholders y desarrolladores para determinar los requerimientos, priorizar las funcionalidades y asi construir los prototipos
  • Asegurar la correspondencia entre las funcionalidades y las necesidades de negocio
  • Utilizar herramientas para el modelado de negocios
  • Buscar y Preocuparse por buscar la aprobación de la solución final


Analista Funcional para proyectos Tradicionales (Waterfall SDLC – Modelo en cascada)
Básicamente. algunas de sus funciones son:
  • Realizar tareas de relevamiento, análisis y diseño de sistemas
  • Asistir al desarrollador en el entendimiento de los requerimientos
  • Documentar de forma exhaustiva y detallada los requerimientos contenidos en las especificaciones del cliente 
  • Relevar los datos del proyecto
  • Diseñar las entradas, salidas, archivos del proyecto
  • Asistir al tester en el entendimiento de los requerimientos
  • Controlar el cumplimiento del plan de proyecto


  • ¿En qué proyecto, el Analista Funcional puede estar actuando mejor como ‘Facilitador’?
  • ¿En qué proyecto, el Analista Funcional puede ser ser más absorbido por el equipo de desarrollo?
  • ¿Qué riesgos asociados debe considerar el Analista Funcional en cada uno los proyectos?
  • ¿Cómo aumenta el Analista Funcional su nivel de productividad y consenso en cada uno de los proyectos?
  • ¿Qué tipo de Analista Funcional puede comprender mejor la denominada ‘Big Picture’ del proyecto?
  • ¿Cuál es el futuro del Analista Funcional en cada uno de estos proyectos?
  • ¿Cómo interactúa con el ‘Analista Funcional’, el ‘Analista Tester’ ó ‘Tester’ en cada uno de estos proyectos?
  • ¿Cuáles son las funciones básicas de un ‘Analista Tester’ ó ‘Tester’ en cada uno de estos proyectos?
  • ¿Cuál es el futuro del ‘Analista Tester’ en cada uno de estos proyectos?
Fuentes:



¿El Analista Funcional debe ser Técnico?.

Fuente: testingbaires.com


El siguiente texto fue extraído -previa autorización de su administrador- de uno de los debates que inició Daniel Mónaco desde su grupo de discusión en Linkedin.

Sé que con este tema hay muchas opiniones diferentes.
Se me ocurren hacer las siguientes divisiones:
1. Analista funcional con estudio en el Area de Sistemas
2. Analista funcional con estudio en otras Areas.
3. Analista de Negocio
4. Usuario Clave

1. Analista funcional con estudio en el Area de Sistemas:
Este profesional conoce los fundamentos de Programación, Base de Datos, Sistemas Operativos, etc. Estos conocimientos enriquecen al Analista y les permite ser bastante independiente para poder discriminar lo que el Sistema puede llegar a ser o que no, en base a los Requerimientos del Cliente. Además le permite trabajar no sólo en la etapa de Análisis, sino también en la de Diseño. Un Analista no debe quedarse sólo con lo que su rol Funcional le demande; debe conocer la tecnología a implementar o implementada, el Modelo de Clases y el Modelo de Datos que tendrá o tiene el Proyecto.
A este rol muchas veces se les denomina Analista funcional / técnico y tiene la responsabilidad de ser el nexo entre los Analistas y los Desarrolladores/Programadores del Sistema.
En el caso que un Proyecto sólo pueda contar con 1 Analista, me parece que este es el perfil más indicado.
2. Analista funcional con estudio en Areas que no son de Sistemas:
Generalmente este perfil tiene conocimiento en el negocio o puntualmente en el Análisis del Requerimiento o en el Análisis del Proceso.
Es muy útil y depende mucho de la experiencia que tenga el profesional.
Estos perfiles deben ser acompañados con perfiles de Analistas afines a Sistemas para complementarse.
Es bueno tener este perfil cuando se cuenta en el Proyecto con un Grupo de Analistas.
3. Analista de Negocio:
Este es un perfil relativamente nuevo y esta muy cerca de ser un usuario clave.
Puede tomar tareas de interprete entre el Cliente y el Analista funcional y ayuda puntualmente en el Análisis del Requerimiento.
Este perfil es recomendado en Proyectos grandes y donde el entendimiento del Negocio y de los Procesos sea complejo. Es un perfil requerido al utilizar metodología de
Proceso Unificado (UP).
4. Usuario Clave:
Este es un usuario que por su experiencia tiene un buen conocimiento del negocio y puede determinar las necesidades y el deseo del Cliente. Para algunas metodologías de Programación Extrema (XP), este perfil reemplaza al Analista funcional y es vital su participación 100% en el Proyecto. El problema que ocurre que al ser un Usuario clave, el Area que presta a este Usuario no puede tomarse el lujo de dejarlo participar enteramente en el Proyecto. Creo también que es un perfil complementario. Muchas empresas cometen el error al pensar que un Usuario Clave puede hacer el trabajo de un Analista Funcional por conocer el negocio. Son dos cosas distintas, conocer el negocio es sólo una parte de las tareas que debe realizar un Funcional.
En resumen, creo que un Analista de perfil de tipo 1 es indispensable en un Proyecto y los demás tipos deben complementarse y trabajar en conjunto con el primero. De no tenerse un Analista del tipo 1, tiene que aparecer la figura de un Analista puramente Técnico o un Arquitecto o un Responsable del Diseño del Sistema para acompañar a los Analistas de los otros tipos en las tomas de decisiones y en los análisis con los clientes.

Linkedin Group: http://www.linkedin.com/groups?mostPopular=&gid=3123613
Public Profile: http://ar.linkedin.com/pub/daniel-m%C3%B3naco/6/251/a67


¿Dónde esta el límite entre un ‘Analista de Testing’ y un ‘Analista Funcional’?

Fuente: testingbaires.com

El ‘Analista Funcional’ normalmente, analiza especificaciones (funcionales y/o técnicas) cuando participa en una estimación preliminar, un nuevo desarrollo o una modificación del código como consecuencia de una anomalía detectada por el cliente.
Luego de este análisis y en alguna instancia dentro del ciclo de desarrollo (antes o después de su finalización), deberá probar (testear). (*)
Por otra parte, ‘en la vereda de enfrente’ y hasta se podría decir, casi al mismo tiempo (por lo menos así se dá en algunos proyectos), el ‘Analista de QC (testing)’ también analiza las especificaciones, y en el caso de no estar diseñados los casos de uso, se los estará planteando él mismo para poder generar más tarde, los diferentes casos de prueba. En otras ocasiones, levanta el ‘producido’ por parte del ‘Analista Funcional’, lo revisa y genera los casos de prueba, es decir, en principio la matriz de cobertura de prueba.
Luego de este análisis y en alguna instancia dentro del ciclo de desarrollo (antes o después de su finalización), deberá tester. (*)
Ahora bien, es aquí donde planteo los siguientes interrogantes:
1. con qué metodología y técnica trabaja el ‘Analista Funcional’ al momento de realizar sus pruebas?
2. hasta que profundidad de prueba llega?
3. hay un momento en el que participa junto con el ‘Analista de QC’ en las pruebas?
4. en qué momento el ‘Analista de QC’ inicia sus pruebas?
5. hay un momento en el que participa junto con el ‘Analista Funcional’ en las pruebas?
6. el ‘Analista Funcional’ depende en algún momento del ‘Analista de QC’?
7. el ‘Analista de QC’ depende en algún momento del ‘Analista Funcional’?
Para leer los comentarios del debate iniciado en el grupo linkedin: TESTING & QA, acceder haciendo clic AQUI

Comentario dejado por un miembro:
“El analista Funcional es el que se encarga del relevamiento primario y posterior diseño de casos de uso (abarca diferente fases del diseño UML). En cambio el analista de Testing se encarga de diseñar los casos de prueba los cuales se fundamentan en la especificación lograda por los analistas Funcionales. Ambos roles son diferentes y no deberían solaparse, pero si tener un contacto permanente. Los analistas Funcionales no deberían intervenir directamente en el proceso de pruebas de integracion.”



Análisis Funcional – Requisitos del mercado.

Fuente: testingbaires.com

El siguiente, es parte de un debate iniciado en el grupo de discusión en linkedin: Análisis Funcional.
 
Requisitos del mercado

Estuve haciendo un estudio de las ofertas laborales en la Argentina y obtuve
los siguientes requisitos más pedidos para un puesto de Analista Funcional:

  • Dominio de Base de Datos relacionales
  • Conocimiento de lenguajes SQL (Transact-SQL, PL-SQL)
  • Habilidades de Gestión
  • Dominio de idioma inglés
  • UML
  • metodologías: Agiles (UP, Scrum, XP), CMMI
  • Utilización de métricas para elaborar estimaciones
  • Elaborar Casos de Prueba
  • Análisis y Diseño de Procesos
  • Manejo de alguna aplicación de Gestión de Proyecto (preferentemente MS Project).
  • Conocimiento del Negocio
  • Capacitación a Usuarios

Linkedin Group: Análisis Funcional
Public Profile: Daniel Mónaco

     
Publicado por aegxxi-labBlgr en 4:29 0 comentarios
Etiquetas: ,

Revisando: UML - Lenguaje Unificado de Modelado. (10/06/2012)


  • Lenguaje Unificado de Modelado. (definición Wikipedia)
  • Aprendiendo UML en 24 horas.
  • Uml Gota a Gota.
  • El Lenguaje unificado de modelado.
  • Diseñar y programar, todo es empezar.: Una introducción a la programación orientada a objetos usando UML y Java.
  • Ingenieria de Software Orientada a Objetos Con Uml, Java E Internet.
  • Diseño de sistemas software en UML.
  • Una Introducción a los Perfiles UML.
  • Especificación de sistemas software en UML.
  • Casos prácticos de UML.
  • UML 2 Iniciacion, ejemplos y ejercicios corregidos.
  • Método para la solución de problemas utilizando la Programación Orientada a Objetos.
  • Modelado de Sistemas com UML.
  • Herramientas para modelado UML gratuitos.




Lenguaje Unificado de Modelado.

Fuente:: es.wikipedia.org

Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y compuestos reciclados.

Es importante remarcar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.
UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Contenido

Estandarización de UML

Desde el año 1995, UML es un estándar aprobado por la ISO como ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Versión 1.4.2.

Críticas a UML

A pesar de su estatus de estándar internacionalmente reconocido y utilizado, UML siempre ha sido criticado por su carencia de una semántica precisa, lo que ha dado lugar a que la interpretación de un modelo UML no pueda ser objetiva. Otro problema de UML es que no se presta con facilidad al diseño de sistemas distribuidos. En tales sistemas cobran importancia factores como transmisión, serialización, persistencia, etc. UML no cuenta con maneras de describir tales factores. No se puede, por ejemplo, usar UML para señalar que un objeto es persistente o remoto, o que existe en un servidor que corre continuamente y que es compartido entre varias instancias de ejecución del sistema analizado. Sin embargo, UML sí acepta la creación de nuestros propios elementos para este tipo de modelado, incluso cuenta con la posibilidad de agregar comentarios en forma de notas en las cuales se puede detallar todo aquello que no pueda ser expresado por la versión actual de la notación. Algo parecido ocurría anteriormente con el diseño de Base de Datos y para ello se utilizaban las restricciones explícitas escritas en lógica simbólica.
EEYORE¹

Historia

Antes de UML 1.x

Después de que la Rational Software Corporation contratara a James Rumbaugh de General Electric en 1994, la compañía se convirtió en la fuente de los dos esquemas de modelado orientado a objetos más populares de la época: el OMT (Object-modeling technique) de Rumbaugh, que era mejor para análisis orientado a objetos, y el Método Booch de Grady Booch, que era mejor para el diseño orientado a objetos. Poco después se les unió Ivar Jacobson, el creador del método de ingenieríá de software orientado a objetos. Jacobson se unió a Rational en 1995, después de que su compañía Objectory AB fuera comprada por Rational. Los tres metodologistas eran conocidos como los Tres Amigos, porque se sabia de sus constantes argumentos sobre las prácticas metodológicas.
En 1996 Rational concluyó que la abundancia de lenguajes de modelado estaba alentando la adopción de la tecnología de objetos, y para orientarse hacia un método unificado, encargaron a los Tres Amigos que desarrollaran un Lenguaje Unificado de Modelado abierto. Se consultó con representantes de compañías competidoras en el área de la tecnología de objetos durante la OOPSLA '96; eligieron cajas para representar clases en lugar de la notación de Booch que utilizaba símbolos de nubes.
Bajo la dirección técnica de los Tres Amigos fue organizado un consorcio internacional llamado UML Partners en 1996 para completar las especificaciones del Lenguaje Unificado de Modelado (UML), y para proponerlo como una respuesta al OMG RFP. El borrador de la especificación UML 1.0 de UML Partners fue propuesto a la OMG en enero de 1997. Durante el mismo mes la UML Partners formó una Fuerza de Tarea Semántica, encabezada por Cris Kobryn y administrada por Ed Eykholt, para finalizar las semánticas de la especificación y para integrarla con otros esfuerzos de estandarización. El resultado de este trabajo, el UML 1.1, fue presentado ante la OMG en agosto de 1997 y adoptado por la OMG en noviembre de 1997.

UML 1.x

Como notación de modelado, la influencia de la OMT domina UML (por ejemplo el uso de rectángulos para clases y objetos). Aunque se quitó la notación de "nubes" de Booch, si se adoptó la capacidad de Booch para especificar detalles de diseño en los niveles inferiores. La notación de Casos de Uso del Objectory y la notación de componentes de Booch fueron integrados al resto de la notación, pero la integración semántica era relativamente débil en UML 1.1, y no se arregló realmente hasta la revisión mayor de UML 2.0.
Conceptos de muchos otros métodos OO fueron integrados superficialmente en UML con el propósito de hacerlo compatible con todos los métodos OO. Además el grupo tomó en cuenta muchos otros métodos de la época, con el objetivo de asegurar amplia cobertura en el dominio de los sistemas en tiempo real. Como resultado, UML es útil en una variedad de problemas de ingeniería, desde procesos sencillos y aplicaciones de un sólo usuario a sistemas concurrentes y distribuidos.

Referencias

  • Martin Fowler, Kendall Sccott, "UML Gota a Gota", 1999.
  • Utilización de UML en Ingeniería del Software con Objetos y Componentes. Perdita Stevens, Rob Pooley. Addison Wesley. 2002.
  • UML 2 Perdita Stevens Pearson Education ISBN-10: 8478290869
  • UML Fermando Asteasuain ISBN-10: 9871347952

Enlaces externos





Aprendiendo UML en 24 horas.

Fuente: es.scribd.com

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocios y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. (Less)



Alternativas: 

En Linea:

Descarga:

Uml Gota a Gota.

Fuente: books.google.com.ar

Escrito por Martin Fowler,RENDALL SCOTT,Kendall Scott




El Lenguaje unificado de modelado.

Fuente: docs.google.com




Diseñar y programar, todo es empezar.: Una introducción a la programación orientada a objetos usando UML y Java.

Fuente: books.google.com.ar

Escrito por José F. Vélez Serrano,Alberto Peña Abril,Francisco Gortázar Bellas,Ángel Sánchez Calle





Ingenieria de Software Orientada a Objetos Con Uml, Java E Internet.

Fuente: books.google.com.ar

Escrito por Alfredo Weitzenfeld





Diseño de sistemas software en UML.

Fuente: books.google.com.ar

Escrito por Ernest Teniente López,Antoni Olivé Ramon,Enric Mayol Sarroca,Cristina Gómez Seone





Una Introducción a los Perfiles UML.

Fuente: docs.google.com

Lidia Fuentes y Antonio Vallecillo

Depto. de Lenguajes y Ciencias de la Computación, Universidad de Málaga
Campus de Teatinos. E29071- Málaga (SPAIN)
e-mail: {lff,av}@lcc.uma.es

Resumen

El lenguaje de modelado UML es el estándar más utilizado para especificar y
documentar cualquier sistema de forma precisa. Sin embargo, el hecho de que UML sea
una notación de propósito muy general obliga a que muchas veces sea deseable poder
contar con algún lenguaje más específico para modelar y representar los conceptos de
ciertos dominios particulares. Los Perfiles UML constituyen el mecanismo que
proporciona el propio UML para extender su sintaxis y su semántica para expresar los
conceptos específicos de un determinado dominio de aplicación. En este artículo
analizaremos los mecanismos de extensión que se utilizan para definir un Perfil UML.
También discutiremos la utilidad y relevancia de estos Perfiles UML en el contexto del
modelado guiado por arquitecturas (MDA).

https://docs.google.com/viewer?url=http://c3po.eui.upm.es/file.php/24/UMLProfiles-Novatica04.pdf




Especificación de sistemas software en UML.

Fuente: books.google.com.ar

Escrito por Ernest Teniente López,Dolors Costal Costa,Ma Ribera Sancho Samsó




Casos prácticos de UML.

Fuente: books.google.com.ar

Escrito por Celia Gutiérrez Cosío




UML 2 Iniciacion, ejemplos y ejercicios corregidos.

Fuente: books.google.com.ar

Escrito por Laurent Debrauwer,Fien Van der Heyde



Segunda Edición:




Método para la solución de problemas utilizando la Programación Orientada a Objetos.

Fuente: books.google.com.ar

Escrito por Juan José Flores Cueto





Modelado de Sistemas com UML.

Fuente: mmc.geofisica.unam.mx

1. Introducción
2. ¿Qué es UML?
2.1. UML ofrece notación y semántica estándar
2.2. UML no es un Método
2.3. Extensiones UML 1.1
2.3.1. Esteroetipos
2.3.2. Extensiones de Modelado de Negocio
2.3.3. Lenguaje restrictivo (constraint) de objetos (OCL)
2.4. Más Extensiones
2.4.1. Análisis guiados por la responsabilidad con tarjetas CRC
2.4.2. Modelo Relacional de datos
3. Una perspectiva general de UML
3.1. Una vuelta por un caso de uso
3.2. Casos de Uso y Diagramas de Interacción
3.3. Clases y Diagramas de Implementación
3.4. Tarjetas CRC (CRC cards) - Una extensión informal de UML
3.5. Diagramas de Estado
3.6. Implementando el diseño
3.7. Implementando la aplicación
3.8. Implementando el diseño de Bases de Datos
3.9. Probar teniendo en cuenta los requisitos
4. Un estudio a fondo de UML
4.1. Modelado de Casos de Uso
4.1.1. Estudiar y descubrir los requisitos
4.1.2. Organización de Diagramas de Casos de Uso
4.1.3. Un Caso de Uso para cada escenario
4.1.4. Modelar secuencias alternas a través de la relación "Extiende" (extends)
4.1.5. Eliminar el modelado redundante a través de la relación "Usa" (uses)
4.1.6. Ayuda en casos de uso probando el sistema frente a los requisitos
4.2. Diagramas de Secuencia
4.3. Diagramas de Colaboración
4.4. Análisis y Diseño con el Diagrama de Clase
4.4.1. Desarrollo de Diagramas de Clase durante el análisis
4.4.2. Diseño del sistema con Diagramas de Clase
4.5. Modelando el comportamiento de las Clases con Diagramas de Estado
4.6. Diagramas de Actividad
4.6.1. Usando Diagramas de Actividad para modelar Casos de Uso
4.6.2. Usando Diagramas de Actividad para modelar Clases
4.7. Modelando Componentes de Software
4.8. Modelando la Distribución y la Implementación
4.9. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML
5. Uso de una Herramienta de Modelado
5.1. System Architect 2001
6. Sumario
7. Referencias


Herramientas para modelado UML gratuitos.

Fuente: rfsdigital.com


El Lenguaje de Modelado Unificado o LMU (Unified Modelling Language, por sus siglas en inglés) es el lenguaje de modelado más utilizado para representar y documentar un sistema. Tiene el respaldo del Object Management Group (OMG),  consorcio dedicado al establecimiento de diferentes estándares de tecnologías orientadas a objetos, tales como UML, XMI, CORBA


De acuerdo con la Wikipedia podemos ver otra definición de lo que significa el Lenguaje de Modelado Unificado:
Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio, funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.
En este post mostraremos una lista de las mejores herramientas de modelado gratuitos disponibles. Estas son las siguientes:
La lista de herramientas encontradas es la siguiente:



ArgoUML es un editor UML gratuito que tiene compatibilidad con el estándar UML 1.4. Permite la exportación a varios formatos gráficos y tiene la disponibilidad de perfiles para varios lenguajes de programación. Es mi herramienta favorita, aunque solo tiene soporte para UML 1.4 (la última versión de UML es 2.4.1).

Al ser programado en Java, ArgoUML tiene la característica de ser multiplataforma. Entre sus características resalta lo siguiente:
  • Exportación de diagramas a diferentes formatos
  • Generación de código
  • Soporte para bases de datos
  • Soporte cognitivo:
    • Críticas de diseño creado, listas de cosas por hacer (ToDo Lists), correcciones automáticas, entre otros.
    • Comprensión y solución del problema





Dia es un programa de creación de diagramas, similar al programa Visio de la suite de ofimática de Microsoft Office. Está  basado en GTK+, biblioteca con objetos y funciones para la interfaz gráfica de usuario, y tiene licencia GPL. Dispone de una gran serie de extensiones que permiten la elaboración de diagramas entidad-interrelación, UML, flujo de datos, diagramas de red, entre otros.




Herramienta gratuita UML de fácil uso con soporte para UML 2, está pensado para funcionar sobre Windows. Permite la generación de código desde el modelo. Tiene soporte para 12 tipos de diagramas, excepto diagramas de objetos.






StarUML es una herramienta de fácil uso que ayuda a generar diagramas compatibles con la suite de ofimática de Microsoft Office. Tiene código es compatible con C++ y Java. y se puede empezar a dibujar manualmente o hacer uso de plantillas que contienen archivos de instalación para modificarlas, pensado para persona que no están acostumbrada o no hayan trabajado anteriormente en modelamiento UML. 






TinyUML es una herramienta gratuita de modelado UML de fácil uso y de rápida creación de diagramas UML 2 implementado en la plataforma Java, requiere Java SE 6.


Opciones pagas:

Existen herramientas muy buenas de modelado en UML, en algunos casos con funcionalidades extendidas y con soporte de modelado de negocio como el Rational Software Architect de IBM, aunque los precios decepcionen a muchos, se puede utilizar una versión de prueba válida por 30 días.


            
Publicado por aegxxi-labBlgr en 2:17 0 comentarios
Etiquetas: , , ,
Suscribirse a: Entradas (Atom)