Tareas

UNIDAD 1

CONCEPTOS BÁSICOS

La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos (software).

Esta disciplina  trasciende la actividad de programación, que es la actividad principal a la hora de crear un software. El ingeniero de software se encarga de toda la gestión del proyecto  para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto.La ingeniería de software, por lo tanto, incluye el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.

EL PAPEL EVOLUTIVO DEL SOFTWARE.

Hoy en día, el software tiene un papel dual. Es producto y canal de distribución de este. Como producto, ofrece la potencia de cómputo presentada como hardware de una computadora o, de manera más global por una red de computadoras accesible mediante hardware local y de acceso físico. Sin importar el lugar en que resida el software, ya sea en un celular o dentro de una computadora central, éste es un transformador de información; realiza la producción, el manejo, la adquisición, la modificación, el despliegue o la transmisión de la información. 

ERA	AÑOS	CARACTERÍSTICAS
1ª	1950- 1965	·     Se trabajaba con la idea de “Codificar y Corregir”. No existía un planteamiento previo. No existía documentación de ningún tipo. Existencia de pocos métodos formales y pocos creyentes en ellos. Desarrollo a base de prueba y error.
2ª	1965 - 1972	Se busca simplificar código. Aparición de Multiprogramación y Sistemas Multiusuarios. Sistemas de Tiempo Real apoyan la toma de decisiones. Aparición de Software como producto. (Casas de Software). inicio de la crisis del software. Se buscan procedimientos para el desarrollo del Software.
3ª	1972 - 1989	Nuevo Concepto: Sistemas Distribuidos. Complejidad en los Sistemas de Información. Aparecen: Redes de área local y global, y Comunicadores Digitales. Amplio Uso de Microprocesadores.
4ª	1989 - -	Impacto Colectivo de Software. Aparecen: Redes de Información, Tecnologías Orientadas a Objetos. Aparecen: Redes Neuronales, Sistemas Expertos y SW de Inteligencia Artificial. La información como valor preponderante dentro de las Organizaciones.

ETAPAS DE DESARROLLO DE SOFTWARE
La ingeniería de software requiere llevar a cabo numerosas tareas agrupadas en etapas, al conjunto de estas etapas se le denomina ciclo de vida . Las etapas comunes a casi todos los modelos de ciclo de vida son las siguientes:

Etapa de Análisis:

Es el proceso de investigar un problema que se quiere resolver. Definir claramente el Problema que se desea resolver o el sistema que se desea crear. Identificar los componentes principales que integrarán el producto.

Etapa de Diseño:

Es el proceso de utilizar la información recolectada en la etapa de análisis al diseño del producto. La principal tarea de la etapa de diseño es desarrollar un modelo o las especificaciones para el producto o Componentes del Sistema.

Etapa de Desarrollo:

Consiste en utilizar los modelos creados durante la etapa de diseño para crear los componentes del sistema.

Etapa de Pruebas o Verificación Prueba:

Consiste en asegurar que los componentes individuales que integran al sistema o producto, cumplen con los requerimientos de la especificación creada durante la etapa de diseño.

Etapa de Implementación o Entrega Implantación:

Consiste en poner a disposición del cliente el producto.

Etapa de Mantenimiento Mantenimiento:

Consiste en corregir problemas del producto y re- liberar el producto como una nueva versión o revisión (producto mejorado).

Etapa final EOL (End-of-Life) :

El fin del ciclo del producto consiste en realizar todas las tareas necesarias para asegurar que los clientes y los empleados están consientes de que el producto ya no será vendido ni soportado. 

MAPA CONCEPTUAL

CONCLUSIÓN:

como conclusión tenemos que la ingeniería de software juega un papel muy importante ya que es una disciplina formada por un conjunto de métodos y técnicas para poder diseñar y desarrollar un programa informático. el software ha ido evolucionando a través de los años, antes se trabajaba con la idea de codificar y corregir pero ahora es un nuevo concepto ya que es mas accesible y se puede emplear en distinto hardware y para transmición de información.

y este cuenta con algunas etapas las cuales son etapa de análisis, de diseño, de desarrollo, Etapa de Pruebas o Verificación Prueba, Etapa de Implementación o Entrega Implantación, Etapa de Mantenimiento Mantenimiento y Etapa final EOL (End-of-Life).

BIBLIOGRAFIA:

http://www.buenastareas.com/ensayos/Introduccion-Fundamentos-De-Ingenier%C3%ADa-De-Software/3026326.html
http://ithuejutlaisabelgarciamendez.blogspot.mx/2013/02/1_9862.html

CLASIFICACIÓN DE LA TECNOLOGÍA DE SOFTWARE

Tecnología orientada a objetos

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los lenguajes de programación, además se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. Es que para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos.

La programación orientada a objetos es una de las formas más populares de programar y viene teniendo gran acogida en el desarrollo de proyectos de software desde los últimos años. Esta acogida se debe a sus grandes capacidades y ventajas frente a las antiguas formas de programar.

Tradicionalmente, la programación fue hecha en una manera secuencial o lineal, es decir una serie de pasos consecutivos con estructuras consecutivas y bifurcaciones.

Los lenguajes basados en esta forma de programación ofrecían ventajas al principio, pero el problema ocurre cuando los sistemas se vuelven complejos. 

Frente a esta dificultad aparecieron los lenguajes basados en la programación estructurada. La idea principal de esta forma de programación es separar las partes complejas del programa en módulos o segmentos que sean ejecutados conforme se requieran. 

Programación estructurada

EL creciente empleo de los computadores ha conducido a buscar un abaratamiento del desarrollo des software, paralelo a la reducción del costo del hardware obtenido gracias a los avances tecnológicos. Los altos costos del mantenimiento de las aplicaciones en producción normal también han urgido la necesidad de mejorar la productividad del personal de programación.

En la década del sesenta salieron a la luz publica los principios de lo que más tarde se llamo Programación Estructurada, posteriormente se libero el conjunto de las llamadas "Técnicas para mejoramiento de la productividad en programación" (en ingles Improved Programming Technologies, abreviado IPTs), siendo la Programación Estructurada una de ellas.

Los programas computarizados pueden ser escritos con un alto grado de estructuración, lo cual les permite ser mas fácilmente comprensibles en actividades tales como pruebas, mantenimiento y modificación de los mismos. Mediante la programación Estructurada todas las bifurcaciones de control de un programa se encuentran estandarizadas, de forma tal que es posible leer la codificación del mismo desde su inicio hasta su terminación en forma continua, sin tener que saltar de un lugar a otro del programa siguiendo el rastro de la lógica establecida por el programador, como es la situación habitual con codificaciones desarrolladas bajo otras técnicas.

EN programación Estructurada los programadores deben profundizar mas que lo usual al procederá realizar el diseño original del programa, pero el resultado final es más fácil de leer y comprender, el objetivo de u programador profesional al escribir programas de una manera estructurada, es realizarlos utilizando solamente un numero de bifurcaciones de control estandarizados.

EL resultado de aplicar la sistemática y disciplinada manera de elaboración de programas establecida por la Programación Estructurada es una programación de alta precisión como nunca antes había sido lograda. Las pruebas de los programas, desarrollados utilizando este método, se acoplan mas rápidamente y el resultado final con programas que pueden ser leídos, mantenidos y modificados por otros programadores con mucho mayor facilidad.

DEFINICIÓN DE LAS HERRAMIENTAS CASE

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software. Como es sabido, los estados en el Ciclo de Vida de desarrollo de un Software son: Investigación Preliminar, Análisis, Diseño, Implementación e Instalación.

La realización de un nuevo software requiere que las tareas sean organizadas y completadas en forma correcta y eficiente. Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software.

HISTORIA DE LAS HERRAMIENTAS CASE

Ya en los años 70 un proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la relación existente entre los requisitos de un problema y las necesidades que éstos generaban, Aunque ésos son los inicios de las herramientas informáticas que ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC. 

Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas más específicas para cada fase del ciclo de vida del software.

CLASIFICACIÓN DE LAS HERRAMIENTAS CASE

Aunque no es fácil y no existe una forma única de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parámetros:

1. Las plataformas que soportan.
2. Las fases del ciclo de vida del desarrollo de sistemas que cubren.
3 La arquitectura de las aplicaciones que producen.
4. Su funcionalidad.

La clasificación basada en las fases del ciclo de desarrollo cubre:

Upper CASE (U-CASE), herramientas que ayudan en las fases de planificación, análisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML.

Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

Lower CASE (L-CASE), herramientas que semi-automatizan la generación de código, crean programas de detección de errores, soportan la depuración de programas y pruebas. Además automatizan la documentación completa de la aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificación excluyente entre sí, ni con la anterior:

Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde análisis hasta implementación.

MetaCASE, herramientas que permiten la definición de nuestra propia técnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiéramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles.

CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software.

IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestión de proyectos y gestión de la configuración.


MAPA CONCEPTUAL

CONCLUSIÓN
la clasificación de la tecnología de software se divide básicamente en tecnología orientada a objetos que se viene aplicando en el análisis y diseño con mucho éxito, al igual que en las bases de datos. Es que para hacer una buena programación orientada a objetos hay que desarrollar todo el sistema aplicando esta tecnología, de ahí la importancia del análisis y el diseño orientado a objetos. y en programación estructurada que se refiere a os programas computarizados pueden ser escritos con un alto grado de estructuración, lo cual les permite ser mas fácilmente comprensibles en actividades tales como pruebas, mantenimiento y modificación de los mismos. por otra parte podemos definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.


BIBLIOGRAFIA:

http://www.ecured.cu/index.php/Herramienta_CASE

http://ithuejutlaisabelgarciamendez.blogspot.mx/2013/02/1_9013.html

http://es.scribd.com/doc/128286949/Clasificacion-de-La-Tecnologia-de-Desarrollo

http://www.buenastareas.com/ensayos/Definici%C3%B3n-e-Historia-De-Las-Herramientas/5789324.html


CUESTIONARIO

1.  Define que es un sistema:

 Es un conjunto organizado de cosas o partes interactuantes que se relacionan formando un todo unitario y complejo.

2.  Define que es una entropía: 

Es el desgaste del sistema que se origina por el transcurso del tiempo o por el funcionamiento del problema.

3.  Define el ciclo de la vida de un proyecto de software: 

Es el desarrollo del software desde su fase inicial hasta su fase final.

4.  Define que es programación en sistema:

 Implementación de un lenguaje de programación para crear funciones definidas durante la etapa del diseño.

5.  Define que es el software: 

Son los programas y documentos, base de datos o procedimiento de operaciones.

6.  Define que es hardware: 

Son todos los elementos físicos de una computadora.

7.  Escribe las pruebas que aplican a un sistema de información:

 Prueba de unidad;  Prueba de integración;  Prueba beta

8.  Define que es implementación: 

Proceso de instalar equipos o software nuevo, como resultado de un análisis y diseño previo.

2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS 

Se define como un conjunto de actividades en los cuales, utilizando tecnicas 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.

CONCLUSIÓN: 

como conclusión podemos ver que es un conjunto de varias actividades donde se utilizan técnicas y algunas herramientas con las que se analiza un problema, esas herramientas tienen objetivos para llevar a cabo un objetivo general. algunas son  inicio,obtención elaboración, negociación, gestión de requisitos, validación y especificación.

BIBLIOGRAFIA:

http://es.slideshare.net/nenyta08/tareas-de-ingenieria-de-requerimientos

http://insitutotec.blogspot.mx/2013/03/21-tareas-de-la-ingenieria-de-requisitos.html

2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISITOS

La ingeniería de requisitos puede ser un proceso largo y arduo para el que se requiere de habilidades psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la gente, así que es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los requisitos del cliente. Históricamente, esto ha incluido técnicas tales como las entrevistas, o talleres con grupos para crear listas de requisitos. Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando sea necesario, el analista empleará una combinación de estos métodos para establecer los requisitos exactos de las personas implicadas, para producir un sistema que resuelva las necesidades del negocio.

Entrevistas

Las entrevistas son un método común. Por lo general no se entrevista a toda la gente que se relacionará con el sistema, sino a una selección de personas que represente a todos los sectores críticos de la organización, con el énfasis puesto en los sectores mas afectados o que harán un uso más frecuente del nuevo sistema.

Talleres

Los requisitos tienen a menudo implicaciones cruzadas desconocidas para las personas implicadas individuales y que a menudo no se descubren en las entrevistas o quedan incompletamente definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse realizando en un ambiente controlado, talleres facilitados por un analista del negocio, en donde las personas implicadas participan en discusiones para descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A menudo es útil la selección de un secretario dedicado a la documentación de la discusión, liberando al analista del negocio para centrarse en el proceso de la definición de los requisitos y para dirigir la discusión.

Forma de contrato 

En lugar de una entrevista, se pueden llenar formularios o contratos indicando los requisitos. En sistemas muy complejos éstos pueden tener centenares de páginas.

Objetivos medibles

Los requisitos formulados por los usuarios se toman como objetivos generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde el punto de vista del sistema hasta determinar los objetivos críticos del funcionamiento interno que luego darán forma a los comportamientos apreciables por el usuario. Luego, se establecen formas de medir el progreso en la construcción, para evaluar en cualquier momento qué tan avanzado se encuentra el proyecto.

Prototipos

Un prototipo es una pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

Casos de uso   

Un caso de uso es una técnica para documentar posibles requisitos, graficando la relación del sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece como una caja negra, y sólo se representa su interacción con entidades externas, permite omitir dichos aspectos y determinar los que realmente corresponden a las entidades externas. El objetivo de esta práctica es mejorar la comunicación entre los usuarios y los desarrolladores, mediante la prueba temprana de prototipos para minimizar cambios hacia el final del proyecto y reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros potenciales.

§  A los directivos, una vez que ven un prototipo, les cuesta comprender que queda mucho trabajo por hacer para completar el diseño final.

§  Los diseñadores tienden a reutilizar el código de los prototipos por temor a “perder el tiempo” al comenzar otra vez.

§  Los prototipos ayudan principalmente a las decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan explícitamente cuáles son los requisitos.

§  Los diseñadores y los usuarios finales pueden centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en producir un sistema que sirva el proceso del negocio.

Los prototipos pueden ser: diagramas, aplicaciones operativas con funcionalidades sintetizadas. Los diagramas, en los casos donde se espera que el software final tenga diseño gráfico, se realizan en una variedad de documentos de diseño gráficos y a menudo elimina todo el color del diseño del software (es decir utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la apariencia final de la aplicación.

CONCLUSIÓN:

La ingeniería de requisitos es un proceso muy largo y un poco complicado y se requiere tener muchas habilidades. es importante identificar a todos los actores involucrados, considerar sus necesidades y asegurar que entienden las implicaciones de los nuevos sistemas es por eso que se utilizan distintos métodos como son entrevistas, talleres, formas de contrato, prototipos, casos de uso y otras técnicas para lograr al final conseguir un buen diseño

BIBLIOGRAFIA:

http://mayratellezs.blogspot.mx/2012/09/tecnicas-de-la-ingenieria-de-requisitos.html

Es.wikipedia.org/wiki/Ingeniería_de_requisitos

2.3 MODELADO DE REQUISITOS

Modelado de requisitos nos sirve y tiene como propósito comprender completamente el problema y todo lo que éste implica y conlleva. Su objetivo principal es delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Además el modelo de requisitos captura las principales características del sistema de software que se desea construir. Por medio de él representamos los requisitos del sistema de forma sencilla, para que de esta manera cualquier usuario pueda revisarlo y además entenderlo, sin necesidad de tener conocimientos previos al modelo e información. Intervienen en el los modelos de caso de uso, que desempeñan un papel importante de gran relevancia. En el estudio del modelo de requisitos se encuentran los funcionales y no funcionales. 

Cabe mencionar que los requisitos determinan lo que hará el sistema, es decir, como funcionará además, las restricciones sobre su operación e implementación. el análisis y especificación de requisitos es el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema. Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado. Puede verse como una declaración abstracta de alto nivel de un servicio que el sistema debe proporcionar. Los requisitos funcionales: son la característica requerida del sistema que expresa una capacidad de acción del mismo, una funcionalidad; generalmente expresada en una declaración en forma verbal. No todo lo que necesitaremos en nuestro sistema es funcionalidad pura; por el contrario a veces se necesitan otras cualidades, si se quieren generalidades, que no son objeto decodificación si bien es cierto que pueden llegar a afectar a esta. Pueden ser frases muy generales sobre lo que el sistema debería hacer.

Existen tres técnicas que nos permiten generar el modelo de requisitos:

Misión del sistema: describe cual es el propósito del sistema, sus responsabilidades y el      alcance que tendrá. A través de él podemos determinar, en términos generales, que hará y  que no hará el sistema. Aunque es una técnica sencilla es de vital importancia para el  desarrollo del sistema.

Árbol de refinamiento de funciones: descompone el sistema en interacciones externas, de acuerdo a algún criterio preestablecido. Cabe mencionar que las interacciones externas son organizadas en funciones que forman una jerarquía a manera de árbol, en cuyo nivel más alto (raíz) se ubica la misión del sistema. 

modelo de casos de uso:utiliza los elementos del Modelo de Casos de Uso. De esta forma, la especificación de actores y casos de uso así como el establecimiento de las relaciones entre éstos, constituye el objetivo fundamental del Modelo de Casos de Uso. El principal insumo requerido para el desarrollo de este modelo son las funciones elementales identificadas

         CONCLUSIÓN: el objetivo de la ingeniería del software es el desarrollo de sistemas apegados a las necesidades del cliente, pero también al  modelo de negocio, los recursos disponibles y el tiempo de entrega. debe cumplir con su misión: desarrollar software de calidad.También nos damos cuenta que el modelado de requisitos nos sirve como propósito para comprender completamente el problema y todo lo que implica. El objetivo principal del sistema es capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. también vemos que el modelo de requisitos de divide en funcionales y no funcionales lo que nos lleva a darnos cuenta cómo es que funcionara el modelo y las diferentes restricciones que se tiene.

BIBLIOGRAFIA;

http://www.slideshare.net/qeelo/modelado-de-requisitos-14350531

http://es.wikipedia.org/wiki/Requisito_funcional

2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITO

        Las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación:

IRQA 43

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.

RETO

Esta herramienta propone un modelo de requisitos para capturar los aspectos funcionales del sistema; básicamente, mediante tres técnicas complementarias entre sí: la definición de la Misión del Sistema, la construcción del Árbol de Refinamiento de Funciones y el desarrollo del Modelo de Casos de Uso.

Además, se introduce un Proceso de Análisis que permite traducir el Modelo de Requisitos en el Modelo Conceptual, manteniendo la trazabilidad entre ambos y propiciando una representación de la información en el segundo prototipo.

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.

OSRMT (Open Source Requirements Management Tool)

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 exclusivamente de una aplicación cliente exclusivamente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.

Con JEREMIA es posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formato DocBook XML, la cual junto con los requisitos, se almacena en una base de datos en MySQL. pero ahora existen herramientas de apoyo que ofrecen recursos administrativos y a prueba de error y permiten trabajar e introducir cambios. 

RAMBUTAN

Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona.

Ambas aplicaciones permiten al usuario introducir, modificar y visualizar los datos que componen un documento de especificación de requisitos. Comparada con otras herramientas de gestión de requisitos, Rambutan ofrece las siguientes ventajas competitivas: Aplicación cliente para palm (PDAclass), portabilidad entre plataformas, es independiente de cualquier metodología de especificación de requisitos, y permite distribución libre.

Existen otras herramientas en estudios para la gestión de requisitos. A continuación se mencionan, algunas de las incluidas en el estudio comparativo presentado por El Consejo Internacional sobre la

Ingeniería de Sistemas (INCOSE)7: CaliberRM, REM,

SMART TRACE, SoftREQ, Analyst Real Team System.

CONCLUSIÓN:

Las herramientas case son importantes ya que la gestion de requisitos de software era muy limitada y confusa

tambien es  posible captar las necesidades, analizarlas y clasificarlas. Implementa un módulo orientado a la generación de la documentación posible de exportar en formatos diferentes, asi como otras herramientas para la gestión de requisitos.

BIBLIOGRAFIA:

http://tecnologicofch.blogspot.mx/2013/03/24-herramientas-case-para-la-ingenieria.html

IDENTIFICACIÓN DE CLASES SEGÚN ESTEREOTIPOS

Para llevar a cabo la transición del modelo de requisitos al modelo de análisis se deben identificar los objetos necesarios para implementar todos los casos de uso. La arquitectura de objetos debe considerar los tres tipos de estereotipos de objetos. Para ello se deben identificar primero las clases borde, las clases entidad y finalmente las de Control.
En general, los cambios mas comunes a un sistema son los de funcionalidad y bordes. Los cambios de las interfaces deben afectar solo  a los objetos borde.
Los cambios a la funcionalidad son más dificiles de administrar, ya que ésta puede abarcar todos los tipos de objetos.
 bordes
Toda la funcionalidad especificada en las descripciones de los casos de uso que depende directamente de los aspectos externos del sistema, se ubica en los objetos borde, pues a través de ello se comunican los actores con el sistema. La tarea de una clase borde es traducir los eventos generados por un actor en eventos comprendidos por el sistema, y traducir los eventos del sistema en una presentación comprensible para el actor.
Las clases borde en otras palabras , describen la comunicación bidireccional entre el sistema y los actores.
Las clases borde son bastante fáciles de identificar, donde se cuenta con al menos tres estrategias:
1.       Se pueden identificar con base a los actores.
2.       Se pueden identificar con base en las descripciones de las interfaces del sistema que acompañan al modelo de requisitos.
3.       Se pueden identificar con base en las descripciones de los casos de uso y extraer la funcionalidad específica a los objetos bordes.

·         Estrategia correspondiente a los actores.
Cada actor necesita su propia clase borde para comunicarse con el sistema. En muchos casos un actor puede necesitar de varios objetos borde. Es evidente que los objetos borde no son totalmente independientes de cada uno, ya que, en ciertos casos deben saber la existencia de los demás.
 Entidad
Se utilizan objetos entidad para modelar la información que el sistema debe manejar a corto y largo plazo. La información a corto plazo existe durante la ejecución de un caso de uso, mientras que la información a largo plazo trasciende los caso de uso, por lo que es necesario guardarla en alguna base de datos o archivos.
Durante la identificación de objeto entidad, se encontrara que objetos que objetos similares aparecen en varios casos de uso.
Clases entidad:
Validar Usuario: Este casi de uso requiere validar información exclusivamente guardada en el registro de usuario, lo que  se hace en la clase entidad RegistroUsuario, utiliza también por el caso de uso RegistroUsuario.
Ofrecer Servicios: Este caso de uso administra las opciones de servicio y no requiere de ninguna clase entidad.
Registrar Usuario: Este caso de uso requiere guardar información exclusivamente acerca del usuario, lo que se hace en la clase entidad RegistroUsuario.
Registrar Tarjeta: Este caso de uso requiere guardar información exclusivamente acerca de la tarjeta del usuario lo que hace en la clase entidad RegistroTarjeta.
Consultar Información: Este casi de uso requiere de toda la información relacionada con consultas. Se puede tomar las clases del dominio del problema y quitar aquellas relacionadas con registros y reservaciones.
Hacer reservación: Este caso de uso requiere de la información relacionada con reservaciones. Se puedegn tomar las clases del dominio del problema y quitar aquellas relacionadas con registros.
Pagar Reservación: Este caso de uso requiere de la información relacionada con reservaciones. Dado que es una extensión al caso de uso Hacer Reservación, no es necesario volver a repetir todas las clases entidad, sino más bien especificar cualquier clase adicional.
 Control
En la mayoría de los casos de uso, existe un comportamiento que no se puede asignar de forma natural a ninguno de los otros dos tipos de objetos ya vistos. Una posibilidad es repartir el comportamiento entre los dos tipos de objetos, pero la solución no es buena si se considera el aspecto de extensibilidad. Un cambio en el comportamiento podría afectar varios objetos, dificultando su modificación. Para evitar estos problemas, tal comportamiento se asigna a objetos control.
Es difícil lograr un buen balance en la distribución del comportamiento del caso de uso entre los objetos entidad, borde y control. Los objetos de control normalmente proveen a administración de los demás tipos de objetos.