2.4. Herramientas CASE para la Ingeniería de requisitos

A medida que pasa el tiempo se logra entender que el empleo del software es una buena opción para agilizar y sistematizar las tareas en el desarrollo de procesos. El desarrollo de software no es la excepción; en este caso dichas herramientas se han denominado CASE (Ingeniería De Software Asistida Por Computador). 

Estas incluyen un conjunto de programas que facilitan la optimización de un producto ofreciendo apoyo permanente a los analistas, ingenieros de software y desarrolladores. CASE es la aplicación de métodos y técnicas que dan utilidades a los programas, por medio de otros, procedimientos y su respectiva documentación. 

En este post se hace referencia a 3 herramientas que ayudan a la gestión de requisitos; es decir al proceso de identificación, asignación y seguimiento de los mismos, incluyendo interfaz, verificación, modificación y control de cada requisito, durante el ciclo de vida del proyecto. Los cambios/actualizaciones de requisitos deben ser gestionados para asegurar que se mantenga la calidad del producto.  

IRQA: 

Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. Facilita la captura, organización y análisis de las condiciones, así como la especificación de la  solución mediante el apoyo metodológico adaptable a cada cliente.

CONTROLA: 

Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a 

la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos. Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones,    control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.

RETO:

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema, básicamente, mediante tres técnicas complementarias entre si: la definoinicion de la misión del sistema, la construcción del árbol de refinamiento de funciones y el desarrollo de modelo de uso.

OSRMT:

Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.  

JEREMIA:

Se trata de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en ele equipo. Esta herramienta ayuda durante el desarrollo del sistema, especialmente con el seguimiento de cambio de los requisitos a lo largo del ciclo de vida.

RAMBUTAN:

Esta herramienta esta basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final ayudando a los analistas del sistema en la recopilación y la categorización de hechos en un documento de especificación de requisito.

En comparación con otras herramientas la gestión de requisitos rambután y las ofrecen la<s siguientes ventajas competitivas: aplicación del cliente (PDA- class) portabilidad entre plataformas, independiente a cualquier metodología de especificación de requisitos herramientas de distribución libre.

Mapa 2.4

Descargar Diapositiva:

https://onedrive.live.com/redir?resid=9D77951F9A04392%21296

2.3. Modelado de requisitos

El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.

El modelo de requisitos es el primer modelo a desarrollarse, sirviendo de base para la formación de todos los demás modelos en el desarrollo de software. En general, el cualquier cambio en la funcionalidad del sistema es más fácil de hacer, y con menores consecuencias, a este nivel que posteriormente. El modelo de requisitos que desarrollaremos se basa en la metodología Objectory(Jacobson et al. 1992), basada principalmente en el modelo de casos de uso.

Actualmente esta metodología es parte del Proceso Unificado de Rational(RUP). El modelo de casos de uso y el propio modelo de requisitos son la base para los demás modelos:

·         Requisitos: El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

·         Análisis: La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

·         Diseño: La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

·         Implementación: Los casos de uso son implementados mediante el código fuente en el modelo de implementación.

·         Pruebas: Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

·         Documentación: El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

En la metodología de Objectory, el modelo de requisitos consiste de tres modelos principales, visualmenterepresentado por un diagrama de tres dimensiones .

 Los tres ejes de modelado del modelo de requisitos.

·         El modelo de comportamiento, basado directamente en el modelo de casos de uso, especifica la funcionalidadque ofrece el sistema desde el punto de vista del usuario. Este modelo utiliza dos conceptos claves: actores pararepresentar los distintos papeles que los usuarios pueden jugar con el sistema, ycasos de uso para representarqué pueden hacer los actores con respecto al sistema

·          El modelo de presentación o modelo de interfaces o borde especifica cómo interactúa el sistema con actores externos al ejecutar los casos de uso, en particular, en los sistemas de información ricos en interacción con el usuario, especifica cómo se verán visualmente las interfaces gráficas y que funcionalidad ofrecerá cada una de ellas.

·          El modelo de información o modelo del dominio del problema especifica los aspectos estructurales del sistema.

Este modelo conceptualiza el sistema según los objetos que representan las entidades básicas de la aplicación.

Aunque en muchas metodologías se permite especificar la funcionalidad completa del sistema utilizando el modelo del dominio del problema, incluyendo operaciones formales sobre los objetos correspondientes a un modelo de requisitos expresado sin casos de uso, el modelo del dominio del problema será de mucha más ayuda como apoyo al modelo de casos de uso y no como una entidad totalmente independiente.

Es importante resaltar que esta separación en tres ejes de modelado independientes es la base para una mayor estabilidad en el desarrollo del sistema, permitiendo minimizar los efectos de cada uno sobre los otros dos.

Descripción del Problema

La descripción del problema es una descripción muy preliminar de necesidades que sirve únicamente como punto de inicio para comprender los requisitos del sistema. Se trata aquí de simular una descripción preparada por un cliente la cual debe evolucionar por medio del modelo de requisitos para lograr la especificación final del sistema a desarrollarse. La descripción del problema debe ser una descripción de necesidades y no una propuesta para una solución. La descripción inicial puede ser incompleta e informal. No hay razón para esperar que la descripción inicial del problema, preparada sin un análisis completo, sea correcta.

Modelo de Casos de Uso

El modelo de casos de uso describe un sistema en término de sus distintas formas de utilización, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarán cambios en los casos de uso. Por ejemplo, un caso de uso para manejar un automóvil sería la secuencia de eventos desde que el conductor entra en el coche encendiendo el motor hasta llegar a su destino final. Por lo tanto, para comprender los casos de uso de un sistema primero es necesario saber quiénes son sus usuarios

Mapa 2.3

Descargar diapositiva: 

https://onedrive.live.com/redir?resid=9D77951F9A04392%21290

2.2. Técnicas de la Ingeniería de Requisitos

En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos comprende  todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos.

Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request.

El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Implicaciones

• ·         La Ingeniería de Requisitos implica todas las actividades del ciclo de vida dedicadas a:
• ·         La reducción de los requisitos de usuario.
• ·         El análisis y negociación de requisitos para derivar requisitos adicionales.
• ·         La documentación de los requisitos como especificación.
• ·         La validación de los requisitos documentados contra las necesidades de usuario.
• ·         Así como los procesos que apoyan estas actividades.

Fases de implementación

• Desde un punto de vista conceptual, las actividades son de cinco clases.
• 
  
•       Obtener requisitos: a través de entrevistas o comunicación con clientes o usuarios, para saber cuáles son sus expectativas.
•       Analizar requisitos: detectar y corregir las falencias comunicativas, transformando los requisitos obtenidos de entrevistas y requisitos, en condiciones apropiadas para ser tratados en el diseño.
•       Documentar requisitos: igual que todas las etapas, los requisitos deben estar debidamente documentados.
•       Verificar los requisitos: consiste en comprobar el correcto funcionamiento de un requisito en la aplicación.
•       Validar los requisitos: comprobar que los requisitos implementados se corresponden con lo que inicialmente se pretendía.

Descargar Diapositiva: 

https://onedrive.live.com/redir?resid=9D77951F9A04392%21291

2.1. Tareas de la Ingeniería de Requisitos

Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.

Inicio:

Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.

Obtención:

Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:

1 Problema de ámbito

1 Problema de comprensión

1 Problemas de volatilidad

Elaboración:

Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.

Negociación:

En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.

Especificación:

Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.

Validación:

Un equipo de validación toma el producto de la fase de especialización, lo revisa para detectar errores, conflictos u omisiones y los corrige con el fin de garantizar la consistencia de requisitos. La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.

Gestión de requisitos:

Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.

Mapa 2.1

Descargar diapositiva: 

https://onedrive.live.com/redir?resid=9D77951F9A04392%21292

16 Septiembre: Día de la Independencia de México

El 16 de septiembre de 1810 al amanecer, en el entonces poblado de Dolores (hoy Municipio de Dolores Hidalgo ubicado en el territorio del estado de Guanajuato), el pueblo acudió al llamado de la campana de la iglesia y con el grito ¡Mexicanos, viva México!, ¡"Viva la Virgen de Guadalupe! Hidalgo incitó al pueblo a levantarse contra los españoles.

A este suceso se le conoce como "Grito de Dolores".

Fue el comienzo de un largo periodo de 11 años de guerra por lograr la Independencia de México, finalmente alcanzada el 27 de septiembre de 1821.

Grandes hombres dieron su vida por la Patria:

Miguel Hidalgo y Costilla 1753 –1811), Ignacio José de Allende y Unzaga (1769 - 1811), Juan Aldama (1774 - 1811), José Mariano de Abasolo (1783-1816), José Mariano Jiménez (1771 – 1811), Francisco Xavier Mina (1789 - 1817) y José María Morelos y Pavón (1765 - 1815)

Se calcula entre 20.000 y 25.000 hombres y mujeres muertos en la lucha por la Independencia (1810-1821).

 Algunos muy conocidos, otros igual de valientes que dieron su vida por la libertad.

El 16 de septiembre del año 1812, en el lugar conocido como el Chapitel del poblado de Huichapan del ahora estado de Hidalgo, se festejó por primera vez  el comienzo de la lucha por la Independencia  a iniciativa de Ignacio López Rayón, quien fuera Secretario Particular de Miguel Hidalgo y uno de los primeros formadores del congreso constituyente.

En 1813 José María Morelos y Pavón, ante el Congreso de Chilpancingo,  propuso instituir el 16 de septiembre como aniversario del inicio de Independencia.

Solo en el año de 1847 la celebración del aniversario de la independencia de México fue suspendida, esto a causa de la invasión de Estados Unidos al país, posteriormente se continuó en forma ininterrumpida

Fiesta nacional

Todos los mexicanos, ya sea en territorio nacional o en diferentes partes del mundo, celebran la fiesta nacional del 16 de septiembre y ven por televisión el mensaje oficial del Grito  que da el Presidente de la República, utilizando la misma campana que usó el Cura Hidalgo.

Actualmente  en este día en  México no se trabaja, ni siquiera en la Bolsa de Valores. Por las principales calles de las ciudades se organiza un desfile en el que marchan  niños de  diferentes escuelas y otros representan los hechos ocurridos el 16 de septiembre de 1810.

Por la tarde continúa la fiesta: se realizan "verbenas populares" en las plazas principales donde  se venden platillos mexicanos como pozole, enchiladas, tamales, buñuelos, atole, etc.

Todo amenizado  con bailes folklóricos, música de mariachi o banda.

En muchos lugares se venden artículos alegóricos a la fecha: banderas, sombreros, juguetes, muñecos con ropa típica mexicana, etc.

Curiosidades

- Porfirio Díaz Morí en el año  1896,  trasladó la campana de la Iglesia de Dolores Hidalgo, al Palacio Nacional, para poder desde ahí hacer la ceremonia del Grito de Independencia.

- La introducción de la ceremonia del grito en la noche del 15 de septiembre empezó a registrarse a mediados del siglo XIX a instancias de Porfirio Díaz por ser el día de su cumpleaños.

- Algunos presidentes de México han conmemorado el Grito desde la capital del país, otros lo han hecho en la cuna de la Independencia, en Dolores Hidalgo.

Septiembre se considera el Mes de la Patria porque coincidieron importantes acontecimientos ligados a la lucha por la libertad:

- La defensa del Castillo de Chapultepec por los Niños Héroes (13 septiembre 1847)

 -El inicio de la Guerra de Independencia (16 septiembre 1810),

- El 27 de septiembre de 1821, el ejército Trigarante, con Iturbide al frente, hizo su entrada triunfal a México consumando así el fin de la Guerra y el 28 se nombró al primer gobierno independiente.

-El 30 de septiembre de 1765 nace  uno de sus próceres: Don José María Morelos y Pavón.

DÍA DE LOS NIÑOS HÉROES (13 DE SEPTIEMBRE)

Día de los Niños Héroes

Este episodio de la Historia de México ocurre en el año de 1846 siendo presidente de México Antonio López de Santa Anna, durante el cual ocurre la guerra de Estados Unidos contra México.

La guerra fue declarada por el presidente James Polk con fines expansionistas, ya que pretendían apoderarse de las provincias mexicanas de Alta California, Nuevo México y, en caso conveniente, de Chihuahua.

Durante el tiempo que duró la guerra (del 8 de marzo de 1846 al 30 de mayo de 1848), en México reinaba la anarquía: en ese periodo hubo siete presidentes y sólo siete de los 19 estados que en esa época formaban la federación mexicana participaron en la defensa de la soberanía nacional.

Esta intervención por parte de Estados Unidos contó con varias campañas, una de ellas la de Veracruz-México. La batalla de Chapultepec pertenece a la última parte de esta campaña. El 13 de septiembre de 1847, las fuerzas norteamericanas decidieron tomar el castillo de Chapultepec donde se alojaba desde hacía 3 tres años el Colegio Militar.

En el Colegio Militar como su nombre lo dice estudiaban los jóvenes que deseaban hacer carrera en el ejército. Fue ahí donde 6 cadetes dieron la vida para salvar a su patria, sus nombres son: Juan de la Barrera, Juan Escutia, Agustín Melgar, Fernando Montes de Oca, Vicente Suárez, y Francisco Márquez, todos ellos tenían edades de entre 13 y 17 años; cuentan que cuando todo había acabado un oficial norteamericano observando el rostro de los cadetes muertos, dijo lleno de sorpresa algo como: "¡Pero si son apenas unos niños!". Tal fue el origen de la expresión "Los niños héroes".

La batalla en Chapultepec comenzó con un intenso bombardeo de artillería, ocasionando graves estragos al edificio y a la infantería que lo defendía, que poco pudo hacer ante el alcance de los cañones. La defensa de Chapultepec estuvo el mando del general Nicolás Bravo, quien disponía de 200 cadetes del Colegio Militar y 632 soldados del Batallón de San Blas, al mando del teniente coronel Felipe Santiago Xicoténcatl, además, Antonio López de Santa Anna llevó al pie del cerro a 450 hombres. Derrotado el batallón de San Blas, los norteamericanos atacaron por el poniente y el sur del Colegio Militar, donde fueron detenidos durante algunas horas por los cadetes; pero más tarde las divisiones de Quitman y Pillow lograron escalar el Castillo. En el interior del inmueble la lucha fue cuerpo a cuerpo; finalmente, la heroica resistencia de sus defensores cedió ante la superioridad numérica y material de los norteamericanos quienes tomaron el edificio e hicieron prisioneros al general Nicolás Bravo, Mariano Monterde –director del Colegio– y varios alumnos sobrevivientes.

Después de ser ocupada la Ciudad de México, el 2 de febrero de 1848, en la sacristía de la Basílica de Guadalupe fue firmado el convenio con el que se dio fin a la guerra. Con el Tratado de Guadalupe Hidalgo, México perdió gran parte de su territorio. Reconocía al Río Bravo como límite meridional de Texas; además, cedía a los Estados Unidos norteamericanos los territorios de Nuevo México y Alta California. Por su parte, el gobierno norteamericano se comprometía a pagar las reclamaciones de sus ciudadanos contra México, a no exigir compensaciones por los gastos de guerra y a pagar 15 millones de pesos por los territorios cedidos.

Así el 13 de Septiembre son recordados todos los héroes que dieron su vida para salvar a la patria durante la guerra contra Estados Unidos.

En la Ciudad de México se realiza un desfile con la armada y en el Castillo de Chapultepec se hace una ceremonia con cañones para recordar a los "Niños Héroes". En las demás partes del país se conmemora con ceremonias cívicas.

Dia del programador

El Día del Programador se celebra el día 256 de cada año para agasajar a los trabajadores de sistemas.

La festividad fue propuesta en Rusia por Valentin Balt, un empleado de Parallel Technologies, una firma dedicada al diseño Web. En 2002, Balt recolectó firmas para presentar una petición al gobierno de su país para establecer la efeméride.

Recién el 11 de septiembre de 2009, el presidente ruso Dmitri Medvédev firmó el decreto que oficializaba esta fecha como el Día de los programadores. Se eligió el día número 256 (2 elevado a la 8) de cada año por dos motivos: es el máximo de combinaciones distintas que se hacen con 8 bits (un número conocido entre los programadores) y es la mayor potencia de 2 menor a 365 días.

Por eso, esta efeméride se festeja todos los 13 de septiembre, excepto los años bisiestos (como 2012), donde se adelanta un día. Así deseamos un Feliz Día del Programador a todos los trabajadores del sector, que cumplen un rol fundamental en la vida cotidiana de todos nosotros.