domingo, 17 de febrero de 2019

Metodología de desarrollo web

Metodología de desarrollo web


La metodología de desarrollo web es una visión de nuestro software que hemos desarrollado para nuestro cliente como visión de una aplicación que hemos desarrollado. Este software esta determinada como una aplicación web. Tenemos que seguir una serie de estándares para poder realizar dicha opción.

Extensión WAE

Frecuentemente somos cuestionados en nuestros cursos acerca de las formas para representar de manera más explícita cierto tipo de aplicaciones utilizando UML, pero sin lo “aburrido” de la notación. Cierto es que UML es gráfico de por sí, pero usar los mismos elementos independientemente del tipo de aplicación, a algunas personas les genera ruido y prefieren algo más explícito. Por ejemplo cuando estudiamos el modelado de aplicaciones web, el modelado del negocio, de sistemas de tiempo real o de bases de datos con UML.
Para resolverlo aprovechamos una de las características peculiares que le dan flexibilidad a la notación de UML. Y consiste en el conjunto de mecanismos de extensión (de significado): estereotipo, restricción y valor etiquetado. Estos mecanismos le permiten a UML extender y enriquecer el significado de sus elementos y símbolos básico de tal suerte que pueden ser empleados para representar dominios en donde nunca se tuvo una intención explícita de origen de aplicarlos. Haberlo hecho así supondría una limitante para la aplicación genérica del lenguaje unificado. Ejemplos de estos dominios son el modelado de negocio (aunque ya existe BPNM como un estándar más específico), el modelado de bases de datos, el modelado de aplicaciones Web o el modelado de circuitos electrónicos, por mencionar algunos.

Arquitectura para web

La mayoría de las aplicaciones desarrolladas hoy en día son las aplicaciones llamadas Web, es decir, aquellas que tienen como elemento significativo de su arquitectura un navegador y un protocolo de comunicación HTTP. Cuando capacitamos a la gente en arquitectura y patrones, buscamos que el alumno comprenda las formas de elaborar este tipo de aplicaciones, como su ubicación en algunos de los patrones de arquitectura Web: “Cliente Delgado Web”, “Cliente Robusto Web” o “Reparto Web”.

El estándar de facto en WEB

En 1998, Jim Conallen definió una extensión a la que denominó WAE (Web Application Extension) para UML. Esta extensión es la convención más difundida y aceptada hasta nuestros días y podríamos decir que define el estándar de facto. En esta entrega, formada por dos artículos, presentaremos los elementos que definen el 20-80 en el modelado de aplicaciones Web usando la WAE. El foco de este artículo es la WAE en los diagrama de clases.

Para que sepan más acerca de los diagramas  WAE les dejo el siguiente link:

Para conocer más acerca de los estereotipos les dejo el siguiente link:

Espero que les sirva la información¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡



Metodologías de desarrollo ágil

Metodologías de desarrollo ágil

El desarrollo ágil de software envuelve un enfoque para la toma de decisiones en los proyectos de software, que se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del proyecto. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo.
Métodos ágiles
Algunos métodos ágiles de desarrollo de software:
  •  
  • ·         Adaptive Software Development (ASD)
  • ·         Agile Unified Process
  • ·         Crystal Clear
  • ·         Feature Driven Development (FDD)
  • ·         Lean Software Development (LSD) : Lean startup
  • ·         Kanban (desarrollo)
  • ·         Open Unified Process (OpenUP)
  • ·         Programación Extrema (XP)
  • ·         Método de desarrollo de sistemas dinámicos (DSDM)
  • ·         Scrum
  • ·         G300
  • ·         6D-BUM
  • ·         PMI Agile

Las metodologías ágiles de la cual les daremos a conocer un poco son las siguientes:
Metodología Scrum:¿Qué es?
Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema.
Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades. 
Scrum - SOFTENG.jpg
¿Cuándo se utiliza?
Metodología de desarrollo XP
La programación extrema o eXtreme Programming (de ahora en adelante, XP) es una metodología de desarrollo de la ingeniería de software formulada por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Les dejo el siguiente link para que conozcan más acerca de la metodología Scrum:
Les dejo el siguiente link para que conozcan más acerca de la metodología XP:



Metodologías de desarrollo tradicional

Metodologías de desarrollo tradicional

Teniendo en cuenta la filosofía de desarrollo de las metodologías, aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa de requisitos y modelado, reciben el apelativo de Metodologías Tradicionales o Pesadas. 



Estas metodologías tradicionales imponen una disciplina de trabajo sobre el proceso de desarrollo del software, con el fin de conseguir un software más eficiente. Para ello, se hace énfasis en la planificación total de todo el trabajo a realizar y una vez que está todo detallado, comienza el ciclo de desarrollo del producto software. Se centran especialmente en el control del proceso, mediante una rigurosa definición de roles, actividades, artefactos, herramientas y notaciones para el modelado y documentación detallada [42]. Además, las metodologías tradicionales no se adaptan adecuadamente a los cambios, por lo que no son métodos adecuados cuando se trabaja en un entorno, donde los requisitos no pueden predecirse o bien pueden variar.

Entre las metodologías tradicionales o pesadas podemos citar:
• RUP (Rational Unified Procces)
• MSF (Microsoft Solution Framework)
• Win-Win Spiral Model
• Iconix


Algunas de las metodologías que podemos usar son las que mencionamos a continuación:
Metodología en cascada:
El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de software se concibe como  un conjunto de etapas que  se ejecutan una tras otra. Se le denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada.

Fases del modelo

El modelo de desarrollo en cascada sigue una serie de etapas de forma sucesiva, la etapa siguiente empieza cuando termina la etapa anterior.
Las fases que componen el modelo son las siguientes:

Requisitos del software

En esta fase se hace un análisis de las necesidades del cliente para determinar las características del software a desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles técnicos. Hay que ser especialmente cuidadoso en esta primera fase, ya que en este modelo no se pueden añadir nuevos requisitos en mitad del proceso de desarrollo.
Por lo tanto, esta es la etapa en la que se lleva a cabo una descripción de los requisitos del software, y se acuerda entre el cliente y la empresa desarrolladora lo que el producto deberá hacer. Disponer de una especificación de los requisitos permite estimar de forma rigurosa las necesidades del software antes de su diseño. Además, permite tener una base a partir de la cual estimar el coste del producto, los riesgos y los plazos.
En el documento en el que se especifican los requisitos, se establece una lista de los requerimientos acordados. Los desarrolladores deben comprender de forma clara el producto que van a desarrollar. Esto se consigue teniendo una lista detallada de los requisitos, y con una comunicación fluida con el cliente hasta que termine el el tiempo de desarrollo.

Metodología en espiral:

El desarrollo de la metodología en espiral es un ciclo de vida de software definido por primera vez por Barry Boehm en 1986, utilizado generalmente en una ingeniería de software.

Las actividades de este modelo se conforman en una espiral, en la que cada bucle o interacción representa un conjunto de actividades. Las actividades no están fijadas a ninguna prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.




Les dejo el siguiente link para que conozcan más acerca de la metodología en espiral:
Les dejo el siguiente link para que conozcan más acerca de la metodología en cascada:



Diagrama de contexto

Diagrama de contexto

Un Diagrama de Contexto de Sistema (DCS) en Ingeniería de software e Ingeniería de sistemas es un diagrama que define los límites entre el sistema, o parte del sistema, y su ambiente, mostrando las entidades que interactúan con él.2​ Este diagrama es una vista de alto nivel de un sistema. Es similar al Diagrama de bloques.


Para qué sirve?

ü  Para representar los límites del sistema, es decir permite distinguir lo que es el sistema y su entorno.
ü  Define lo que hace y lo que no hace parte del sistema.
            Implica aspectos sociales y organizacionales. 


ü  Nos sirven como una manera de representar los límites del sistema, se distingue lo que conforma el sistema y su entono.
ü  El diagrama de este modelado es también conocido como el nivel 0 del diagrama de un flujo de datos.
ü  Se muestran las relaciones que se dan en el sistema y se debe tomar en cuenta los requerimientos y el diseño del sistema.
ü  Determina donde tiene que implementarse una nueva funcionalidad.
ü  Deber hacerse oportunamente durante el proceso, para limitar los costos del sistema, así como el tiempo necesario para comprender los requerimientos y el diseño del sistema.


Les dejo el link del siguiente vídeo para que sepan como se crea un diagrama de contexto:

Espero que esta información les ayude a conocer más del tema...
Gracias¡¡¡¡¡¡¡¡


lunes, 11 de febrero de 2019

Modelado de negocios

Modelado de negocios

El modelado de negocios de ingeniería de software ha evolucionado desde los años 60, hasta convertirse el día de hoy en uno de los aspectos más importantes para el avance correcto para la venta del software que se va a desarrollar. De esta manera daremos a conocer nuestro producto para un mercado en comparación a otros productos con los que va a competir.



Figura 1. Proceso de modelado de negocios

En la siguiente imagen se da a conocer la notación UML que debemos de tener en cuenta al momento de realzar nuestro modelo de negocios:



Para representar un modelo de negocios se usan dos herramientas importantes uno de forma textual que es un diagrama de casos de uso como el que se muestra en la siguiente imagen:


Otra forma de representar el modelo de negocios es diagramaticamente en la que podemos representar el software que hemos desarrollado de igual manera. Cabe destacar que para realizar un buen modelado de negocios es recomendable usar los dos para brindar mejor información del software desarrollado. Para representar esta forma se puede usar un diagrama UML de actividades como el que se muestra a continuación:


Les dejo el link del siguiente vídeo para que conozcan más acerca del modelado de negocios:


Publicaciones 2do Parcial

Buenas noches¡¡¡¡¡¡¡¡¡¡¡¡¡
A partir de aquí siguen las publicaciones correspondientes al segundo parcial...


miércoles, 6 de febrero de 2019

Vídeos de parcial 1

Links de vídeos del parcial 1

Buenas noches amigos¡¡¡¡
Aqui les dejo los links de los vídeos que realizamos para  nuestras unidades que vimos en el transcurso del proyecto: