Mostrando entradas con la etiqueta INGENIERIA DE SOFTWARE I. Mostrar todas las entradas
Mostrando entradas con la etiqueta INGENIERIA DE SOFTWARE I. Mostrar todas las entradas

domingo, 14 de noviembre de 2021

Diagramas para la documentación de las vistas propuestas en el modelo 4+1

 

Modelo “4+1” vistas de Kruchten

El modelo “4+1” de Kruchten, es un modelo de vistas [1] diseñado por el profesor Philippe Kruchten y que encaja con el estándar “IEEE 1471-2000” (Recommended Practice for Architecture Description of Software-Intensive Systems ) que se utiliza para describir la arquitectura de un sistema software intensivo basado en el uso de múltiples puntos de vista.

Vale, si por ahora no te has enterado de nada y no estas en 3 o 4 de carrera de Ingeniería del Software (o derivados) no te preocupes es normal, y si estas en 3 o 4 de carrera y aun así no te has enterado de nada, ¡Ponte las pilas YA! Porque estas cosas te deberían (por lo menos) sonar.

Antes de entrar a explicar mas en detalle el modelo de kruchten vamos a explicar e intentar dejar claro algunos conceptos como por ejemplo qué es un sistema software, qué es una vista y qué es un punto de vista.

Lo primero es saber que es eso de “un sistema software”, el cual lo definimos con la siguiente “ecuación”

 Sistema software = Hardware + Software

Efectivamente, a grandes rasgos un sistema software es un software (mas o menos complejo) que “corre” en un determinado hardware (mas o menos complejo). Por ejemplo, todo el rollo de los “cajeros automáticos” es un sistema software ya que en un “hardware” que llamamos “cajero”, se ejecuta algún tipo de programa (software) el cual nos permite realizar determinadas gestiones.

Otra cosa de la que habla este modelo de Kruchten es sobre los conceptos de vista y puntos de vista, pues bien una vista no es mas que una representación de todo el sistema software desde una determinada perspectiva, y un punto de vista se define como un conjunto de reglas (o normas) para realizar y entender las vistas.

Bien, sino te ha quedado muy claro que es esto de las vistas y los puntos de vista, vamos a explicarlo con una sencilla analogía del mundo de la arquitectura (de la arquitectura de las casas, edificios y esas cosas):

Si un arquitecto nos muestra un plano de una casa (como la de la siguiente imagen), nos esta mostrando una vista de la casa y como no tenemos ni idea de arquitectura, cuando nos explique o nos de un documento en el que explique que un determinado símbolo del plano representa a una puerta u otro símbolo representa una mesa, nos estará dado un punto de vista para que podamos entender el plano de la casa. Si mas tarde nos mostrase otro plano (o maqueta) de la casa, nos estaría dando otra vista de la casa y nos tendrá que explicar el nuevo punto de vista, es decir, que nos tendrá que explicar que significa cada símbolo u objeto de esa nueva vista.

Bueno pues vistos los conceptos de lo que son las vistas y los puntos de vista, y habiendo explicado que es un sistema software, uno ya se puede hacer a la idea de que va el modelo “4+1” vistas de Kruchten para la descripción de arquitecturas de sistemas software ¿NO?.

Pues sí, lo que propone Kruchten es que un sistema software se ha de documentar y mostrar (tal y como se propone en el estándar IEEE 1471-2000) con 4 vistas bien diferenciadas y estas 4 vistas se han de relacionar entre sí con una vista más, que es la denominada vista “+1”. Estas 4 vista las denominó Kruchten como: vista lógica, vista de procesos, vista de despliegue y vista física y la vista “+1” que tiene la función de relacionar las 4 vistas citadas, la denominó vista de escenario.

Cada una de estas vistas ha de mostrar toda la arquitectura del sistema software que se esté documentando, pero cada una de ellas ha de documentarse de forma diferente y ha de mostrar aspectos diferentes del sistema software. A continuación, pasamos a explicar que información ha de haber en la documentación de cada una de estas vistas.

Vista Lógica: En esta vista se representa la funcionalidad que el sistema proporcionara a los usuarios finales. Es decir, se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Para completar la documentación de esta vista se pueden incluir los diagramas de clases, de comunicación o de secuencia de UML.

Vista de Despliegue: En esta vista se muestra el sistema desde la perspectiva de un programador y se ocupa de la gestión del software; o en otras palabras, se va a mostrar como esta dividido el sistema software en componentes y las dependencias que hay entre esos componentes. Para completar la documentación de esta vista se pueden incluir los diagramas de componentes y de paquetes de UML.

Vista de Procesos: En esta vista se muestran los procesos que hay en el sistema y la forma en la que se comunican estos procesos; es decir, se representa desde la perspectiva de un integrador de sistemas, el flujo de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Para completar la documentación de esta vista se puede incluir el diagrama de actividad de UML.

Vista Física: En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes físicos del sistema así como las conexiones físicas entre esos componentes que conforman la solución (incluyendo los servicios). Para completar la documentación de esta vista se puede incluir el diagrama de despliegue de UML.

“+1” Vista de Escenarios: Esta vista va a ser representada por los casos de uso  software y va a tener la función de unir y relacionar las otras 4 vistas, esto quiere decir que desde un caso de uso podemos ver como se van ligando las otras 4 vistas, con lo que tendremos una trazabilidad de componentes, clases, equipos, paquetes, etc., para realizar cada caso de uso. Para completar la documentación de esta vista se pueden incluir el diagramas de casos de uso de UML.

Principales diagramas de UML

 Principales diagramas de UML


 Se dividen en 2, diagramas estructurales y diagramas de comportamiento.

Diagramas estructurales:

  • Diagrama de clases.
  • Diagrama de componentes.
  • Diagrama de despliegue.
  • Diagrama de objetos.
  • Diagrama de paquetes.
  • Diagrama de perfiles.
  • Diagrama de estructura compuesta.

Diagramas de comportamiento:

  • Diagrama de actividades.
  • Diagrama de casos de usos.
  • Diagrama de secuencia.
  • Diagrama de comunicación.
  • Diagrama de tiempos.
  • Diagrama global de interacciones.

ingeniería de software, herramientas, métodos y procesos

 


Principios Presentados por el Manifiesto Ágil

 Principios Manifiesto Ágil

1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

3.Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.

4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

6.El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.

7. El software funcionando es la medida principal de progreso.

8. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

9.La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

10.La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia



Importancia del proceso de software, métodos, y herramientas en su ciclo de vida

 

Importancia del proceso de software, métodos, y herramientas en su ciclo de vida

 ¿Cuál es la importancia del proceso de software, métodos, y herramientas, en su ciclo de vida?

En ingeniería del software, un proceso de desarrollo del software es el proceso de dividir el trabajo de desarrollo del software en distintas fases para mejorar el diseño, la gestión del producto, y la gestión de proyecto. Es también conocido como el ciclo de vida del desarrollo de software. La metodología puede incluir la pre-definición de entregas concretas y artefactos que son creados y completados por un equipo del proyecto para desarrollar o mantener una aplicación.

La mayoría de procesos de desarrollo modernos pueden ser vagamente descritos como ágiles. Otras metodologías incluyen desarrollo en cascada, prototipado, desarrollo iterativo e incremental, desarrollo de espiral, desarrollo de aplicación rápida, y programación extrema.

Algunas personas consideran el "modelo" del ciclo de vida un término más general para una categoría de las metodologías y el "proceso" de desarrollo de software un término más concreto para referirse a un proceso concreto escogido por una organización específica. Por ejemplo, hay muchos procesos de desarrollo de software concretos que encajan en la espiral del modelo del ciclo de vida. Este campo es a menudo considerado un subconjunto del ciclo de vida del desarrollo de sistemas





Proceso de elicitación de requisitos y los tipos de requerimientos de software

 


Descripción de la licitación de requisitos y tipos de requerimientos del software en un desarrollo.


Identificación de requisitos de software

 La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible.





jueves, 2 de septiembre de 2021

Principios presentados por el manifiesto ágil

 1) La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. 

2) Dar la bienvenida a los cambios incluso al final del desarrollo. Los cambios le darán una ventaja competitiva a nuestro cliente. 

3) Hacer entregas frecuentes de software que funcione, desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

 4) Las personas del negocio y los desarrolladores deben trabajar juntos diariamente a lo largo de todo el proyecto. 

5) Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos. metodologías se diferencian de las tradicionales principalmente porque se adaptan al cambio y están enfocadas principalmente en las personas, no en los procesos.

 6) El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. 

7) El software que funciona es la principal medida del progreso. 

8) Los procesos ágiles promueven un desarrollo sostenido. Los promotores, usuarios y desarrolladores deben poder mantener un ritmo de trabajo constante de forma indefinida. 

9) La atención continua a la calidad técnica y al buen diseño mejoran la agilidad. 

10) La simplicidad es esencial. Se ha de saber maximizar el trabajo que no se debe realizar.

 11) Las mejores arquitecturas, requisitos y diseños surgen de los equipos que se han organizado ellos mismos. 

12) En intervalos regulares, el equipo debe reflexionar con respecto a cómo llegar a ser más efectivo, y ajustar su comportamiento para conseguirlo

Importancia del proceso de software, métodos, y herramientas en su ciclo de vida

 


La importancia del ciclo de vida del software, se debe a la evolución constante que tienen as tecnologías, y su precisión a lo que necesita el usuario final, contemplando lo anterior, es bueno identificar que un proceso de calidad debe de tener unos conceptos claros para su desarrollo, los cuales enfocan los métodos y sus respectivas herramientas, lo cual abarca con claridad, lo que es la Ingeniería de Software.

Los métodos definen el orden, especificaciones claras de los pasos que el programa puede aceptar, con estos métodos podemos llevar un lineamiento de hacia donde se puede encaminar el desarrollo, pero esto no solamente puede ser concebido por métodos, Las herramientas son la maquina esencial del proceso, la herramienta, que en su definición es el lenguaje usado y apropiado para la creación del software.

La conjunción  de estructurar estos conceptos, involucra  la manera correcta de la creación del software, ya que estos a su vez, deben de regirse por ciertas normas que garanticen los ciclos y su funcionamiento, como se podría crear un proceso de calidad sin los análisis y definición de requisitos?, no seria viable, ya que esto nos ayuda a definir las especificaciones y características, además, de sus limitaciones, al ser cíclico, se debe de realizar las pruebas pertinentes, donde se obviara su creación, y se resolverán pautas incompletas, bugs, y percances que hayan pasado desapercibidos.

Cuando el usuario final puede hacer uso del software, se puede tener una fase de mantenimiento, donde se "reparara" errores no previstos y a su vez se puede actualizar para implementar mejoras o acciones necesarias para otros usuarios y otras funcionalidades. Así, vuelve y se activa el ciclo de vida del software.

Realizado el resumen del ciclo y creación del software con sus métodos y herramientas, se puede tener una idea sensata  de la importancia del proceso y ciclo de vida, ya que esto aporta una solución eficaz y sobresaliente al modelo creado, para sus usos futuros y aplicación de nuevas herramientas, sin la necesidad de incluir e interrumpir el flujo del proceso y tener una especificación estándar que garantiza el funcionamiento correcto de lo que se quiere implementar.