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:

Extensión WAE

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

Estereotipos UML

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. 

¿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:

Metodología Scrum

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

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:

Metología en espiral

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

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. 

Características del Modelo de Contexto:

ü  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:

Diagrama de contexto

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

Gracias¡¡¡¡¡¡¡¡

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:

Modelado de negocios

Publicaciones 2do Parcial

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

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:

Vídeo Unidad 1

Vídeo de unidad 2

Modelado UML

Modelado UML

Diagramas del UML

 El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los diagramas es presentar diversas perspectivas de un sistema, a las cuales se les conoce como modelo. Recordemos que un modelo es una representación simplificada de la realidad; el modelo UML describe lo que supuestamente hará un sistema, pero no dice cómo implementar dicho sistema. 

A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: 

A continuación les dejo el link del siguiente vídeo para que conozcan más acerca de los diagramas que usa el modelado UML:

Diagramas del modelado UML

Arquitectura de software

Arquitecturas de software

Como sabemos hasta para la realización de una casa se debe contar con una arquitectura que pueda soportar los pilares. Lo mismo pasa al momento de realizar un proyecto debemos de definir de manera clara y concreta como es que sera nuestro proyecto.

¿Qué es la arquitectura de software?

Antes de elaborar sobre el tema, es conveniente definir el concepto ya que hoy en día el término de arquitectura se usa para referirse a varios aspectos relacionados con las TI. De acuerdo al Software Engineering Institute (SEI), la Arquitectura de Software se refiere a “las estructuras de un sistema, compuestas de elementos con propiedades visibles de forma externa y las relaciones que existen entre ellos.”

Si les interesa conocer más acerca de la arquitectura de software les dejo el link del siguiente vídeo:

Arquitectura de software

Arquitectura de software SOA

Arquitectura de monolítica vs arquitectura de micro servicios

Arquitectura de distribución

Arquitectura cliente-servidor:

Arquitectura en capas:

La arquitectura basada en capas se enfoca en la distribución de roles y responsabilidades de forma jerárquica proveyendo una forma muy efectiva de separación de responsabilidades. El rol indica el modo y tipo de interacción con otras capas, y la responsabilidad indica la funcionalidad que está siendo desarrollada.

Por ejemplo, una aplicación web típica está compuesta por una capa de presentación (funcionalidad relacionada con la interfaz de usuario), una capa de negocios (procesamiento de reglas de negocios) y una capa de datos (funcionalidad relacionada con el acceso a datos).

Si les interesa conocer más acerca de las arquitecturas de software les dejo el siguiente el link:

Tipos de arquitecturas

Norma IEEE 830 y plantillas SRS

Norma IEEE-830 y plantillas SRS

Ámbito de Sistema

En esta subsección:

• Se podrá dar un nombre al futuro sistema (p.ej. MiSistema)
• Se explicará lo que el sistema hará y lo que no hará.
• Se describirán los beneficios, objetivos y metas que se espera alcanzar con el futuro sistema.
• Se referenciarán todos aquellos documentos de nivel superior (p.e. en Ingeniería de Sistemas, que incluyen Hardware y Software, debería mantenerse la consistencia con el documento de especificación de requisitos globales del sistema, si existe).

Requisitos Específicos

Esta sección contiene los requisitos a un nivel de detalle suficiente como para permitir a los diseñadores diseñar un sistema que satisfaga estos requisitos, y que permita al equipo de pruebas planificar y realizar las pruebas que demuestren si el sistema satisface, o no, los requisitos. Todo requisito aquí especificado describirá los comportamientos externos del sistema, perceptibles por parte de los usuarios, operadores y otros sistemas. Esta es la sección más larga e importante de la ERS.

Deberán aplicarse los siguientes principios:

• El documento debería ser perfectamente legible por personas de muy distintas formaciones e intereses.

• Deberán referenciarse aquellos documentos relevantes que poseen alguna influencia sobre los requisitos.
• Todo requisito deberá ser unívocamente identificable mediante algún código o sistema de numeración adecuado.
• Lo ideal, aunque en la práctica no siempre realizable, es que los requisitos posean las siguientes características:
• Corrección: La ERS es correcta si y sólo si todo requisito que figura aquí (y que será implementado en el sistema) refleja alguna necesidad real. La corrección de la ERS implica que el sistema implementado será el sistema deseado.
• No ambiguos: Cada requisito tiene una sola interpretación. Para eliminar la ambigüedad inherente a los requisitos expresados en lenguaje natural, se deberán utilizar gráficos o notaciones formales. En el caso de utilizar términos que, habitualmente, poseen más de una interpretación, se definirán con precisión en el glosario.
• Completos: Todos los requisitos relevantes han sido incluidos en la ERS. Conviene incluir todas las posibles respuestas del sistema a los datos de entrada, tanto válidos como no válidos.
• Consistentes: Los requisitos no pueden ser contradictorios. Un conjunto de requisitos contradictorio no es implementable.
• Clasificados: Normalmente, no todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por importancia (esenciales, condicionales u opcionales) o por estabilidad (cambios que se espera que afecten al requisito). Esto sirve, ante todo, para no emplear excesivos recursos en implementar requisitos no esenciales.
• Verificables: La ERS es verificable si y sólo si todos sus requisitos son verificables. Un requisito es verificable (testeable) si existe un proceso finito y no costoso para demostrar que el sistema cumple con el requisito. Un requisito ambiguo no es, en general, verificable. Expresiones como a veces, bien, adecuado, etc. introducen ambigüedad en los requisitos. Requisitos como “en caso de accidente la nube tóxica no se extenderá más allá de 25 Km” no es verificable por el alto costo que conlleva.
• Modificables: La ERS es modificable si y sólo si se encuentra estructurada de forma que los cambios a los requisitos pueden realizarse de forma fácil, completa y consistente. La utilización de herramientas automáticas de gestión de requisitos (por ejemplo RequisitePro o Doors) facilitan enormemente esta tarea.
• Trazables: La ERS es trazable si se conoce el origen de cada requisito y se facilita la referencia de cada requisito a los componentes del diseño y de la implementación. La trazabilidad hacia atrás indica el origen (documento, persona, etc.) de cada requisito. La trazabilidad hacia delante de un requisito R indica qué componentes del sistema son los que realizan el requisito R.

A continuación se darán a conocer algunos de los requisitos que debe de tener una plantilla SRS, cabe destacar que estas ya están estandarizadas por la norma antes mencionadas. A continuación se muestra un ejemplo de un formato lleno:

Para conocer más acerca de la norma les dejo el link del siguiente vídeo:

Norma IEEE 830

Gracias¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡

Análisis y síntesis de la información

Análisis y síntesis de la información para el desarrollo de proyecto de software

En términos mas generales tenemos como análisis de la información lo siguiente:

A partir de este diagrama podríamos determinar que el análisis es buscar las ideas principales de aquella información que nos están presentando para llegar al objetivo principal que es la realización del proyecto.

Los principios que debemos de tomar en cuenta para poder realizar un buen análisis de los requerimientos proporcionados por nuestro cliente son los mencionados a continuación:

Las etapas para la realización de un buen análisis de la información para la creación de nuestro proyecto de software las podemos encontrar de la siguiente manera:

1.Reconocimiento del problema: En esta parte al estar en contacto con nuestro cliente. Vamos a conocer mediante los requerimientos que este nos de cuales son las verdaderas necesidades que tiene, tomando en cuenta el problema que se busca resolver.

2. Evaluación y síntesis: en esta parte vamos a determinar que tan relevante es la problemática que se quiere resolver de nuestro cliente. De esta forma podremos dar una síntesis de la información obtenida para plantear una solución.

3.Modelado: en esta parte haremos una representación de como es que funcionara dicho software al momento de que el usuario lo use. Pudiéndose crear prototipos del mismo para que sea más fácil la comprensión de los detalles.

4.Especificación: en esta parte se darán a conocer los resultados que se dieron acerca de los aspectos detectados por el usuario. Se especificara de manera directa que es lo que va a continuar y si habrá cambios.

5.Revisión: esta es la fase final para llegar a la entrega final del proyecto. Es donde se buscan aplicar las mejoras si es que son necesarias.  Ya que es donde se procederá a la entrega del proyecto de desarrollo.

Les dejo el siguiente link por si quieren conocer más acerca del análisis de la información:

Análisis de la información

En cuanto a la síntesis de la información se da a conocer lo siguiente:

Técnicas de recolección de requerimientos

Cada uno de estos requerimientos obtenidos con nuestro cliente nos van a permitir realizar conclusiones concretas para poder llevar a cabo el proyecto que este quiere. Resolviendo primero que nada las necesidades que nuestro cliente tiene.

En el siguiente diagrama se dan a conocer los tipos de requerimientos para la realización de un proyecto de software:

Las características de un buen requerimiento son las que se muestran a continuación:

Las técnicas que podemos usar para recolectar dichos requerimientos son las siguientes:

Entrevistas

La entrevista es de gran utilidad para obtener información cualitativa como opiniones, o descripciones subjetivas de actividades. Es una técnica muy utilizada, y requiere una mayor preparación y experiencia por parte del analista. La entrevista se puede definir como un “intento sistemático de recoger información de otra persona” a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada. 

Desarrollo Conjunto de Aplicaciones ( JAD )

Es una técnica que se utiliza para promover la cooperación y el trabajo en equipo entre usuarios y analistas. Consiste en realizar sesiones en las que participan usuarios expertos del dominio junto a analistas de software. 

Desarrollo de Prototipos

Los prototipos suelen consistir en versiones reducidas, demos o conjuntos de pantallas (que no son totalmente operativos) de la aplicación pedida. Esta técnica es particularmente útil cuando:

• El área de la aplicación no está bien definida (posiblemente por ser algo muy novedoso).
• El costo del rechazo de la aplicación por los usuarios es muy alto.
• Es necesario evaluar previamente el impacto del sistema en los usuarios y en la organización.

Observación

Por medio de esta técnica el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. Este método permite observar la forma en que se llevan a cabo los procesos y, por otro, verificar que realmente se sigan todos los pasos especificados. Como sabemos, en muchos casos los procesos son una cosa en papel y otra muy diferente en la práctica.

Cuestionarios

El uso de cuestionarios permite a los analistas reunir información proveniente de un grupo grande de personas. 

Tormenta de ideas 

Consiste en reuniones con cuatro a diez personas donde como primer paso sugieren toda clase de ideas sin juzgar su validez –por muy disparatadas que parezcan–, y después de recopilar todas las ideas se realiza un análisis detallado de cada propuesta.

Les dejo el siguiente link por si quieren conocer más del tema🔻:
Link de vídeo de requerimientos de software