viernes, 3 de febrero de 2012

República Bolivariana de Venezuela.
 Ministerio del Poder Popular para la Educación Universitaria.
Universidad Politécnica de Guárico. L
Calabozo -Edo- Guárico.





ESPECIFICACIÓN DE REQUERIMIENTOS





Profesor:                          Autores:
Eliomar Nieves.                  Bastidas, Yettsy CI.21.277.471.
Ingenieria en informática.    Freites, Karla CI. 20.522.848.
Sección: # 04.                    Milano, María CI. 20.523.388.  
                                         Palacios, Yadurmis CI. 21.280.458.
                                         Sumoza, Erika CI. 20.524.992.
                                         Vargas, Alexander CI. 21.005.357.  


Febrero – 2012

                                                                             
                                        

jueves, 2 de febrero de 2012

Lenguaje Unificado de Modelado UML, Notación de Requerimientos de Usuario URN.

Textual.

Tradicionalmente la especificación de requisitos se ha realizado usando sobre todo especificaciones textuales en lenguaje natural. Las herramientas de apoyo a la gestión de requisitos se han enfocado a la manipulación de trozos de texto. Estos requisitos expresados textualmente se enlazan formando un grafo de trazabilidad el cual se usa para gestionar los requisitos y su trazabilidad. En este enfoque, las especificaciones generadas en las otras actividades del desarrollo de software pueden también ser añadidas al grafo de trazabilidad representándolas como texto.

Notación gráfica.

Incluye todas las notaciones que pueden demostrar el flujo de información entre requisitos apoyándose en diversas imágenes.
Estas notaciones permiten al usuario del sistema tener mayor comprensión del software lo que hace y como lo hace.
          La más utilizada actualmente es el Lenguaje Unificado de modelado (UML). Otra notación que se puede usar es la notación de requerimientos de usuario (URN).

UML.
         Es un lenguaje para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo.
UML, emergió en los años 90 luego de la búsqueda de un lenguaje de modelamiento que unificara a la industria. A pesar de que UML evolucionó de varios métodos orientados al objeto de segunda generación (en nivel de notación), su alcance extiende su uso más allá de sus predecesores.
UML es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación.  Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo).  Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos Los tipos de sistemas y los procesos de ciclo de vida.
UML  se aplica para especificar sistemas, puede ser usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema puede ser realizado. Se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado. Puede ser usado para guiar la realización de un sistema similar a los "planos". Asimismo puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida.

URN.
 Fue una iniciativa de la Internet Engineering Task Force IETF, la rama de desarrollo de ingeniería y protocolos de Internet, con la premisa de conseguir una forma universal de identificación de recursos, para que cada recurso fuera único y constante. Se trataba de un identificador paralelo al URL. Una característica importante de este sistema es que trabaja junto con Uniform Resource Characteristics/Citacion (URC), un sistema para la descripción de metadatos. La sintaxis del URN, consta de 3 bloques separados por dos puntos: el identificador URN, el NID o nombre de la categoría en la que se incluye el documento (por ejemplo, inet para documentos de Internet) y el NSS o cadena específica que indica primero la ruta y a continuación el documento concreto. URN es una notación pensada para la especificación, análisis y validación de los requisitos de usuario. URN combina dos vistas complementarias: una para definir los objetivos del sistema usando el Goal-oriented Requirement Language (GRL) y otra para deifnir los escenarios de uso con la notación Use Case Map (UCM).

¿Qué aplicación basada en software libre se puede recomendar para trabajar con UML?

·         BOUML

Descarga AQUI BOUML y muchos programas más basados en UML...

Técnicas para escribir requerimientos de alta calidad.

·         Técnica JAD (Diseño de Aplicación Conjunta).
·         Técnica FPA (Análisis de Puntos de Función).

      La técnica más usada mundialmente es la JAD debido a su efectividad por logra requerimientos de alta calidad.
Técnica JAD.
     Joint Application Design (JAD) El Diseño de Aplicación Conjunta es una técnica o proceso usado en el Ciclo de Vida del Desarrollo de Sistemas para elicitar requerimientos de Sistemas de información para una compañía. Le técnica JAD también incluye enfoques para mejorar la participación de los usuarios, agilizar el desarrollo y mejorar la calidad de las especificaciones de requerimientos. Consiste en un taller donde los trabajadores del conocimiento y especialistas de TI se reúnen, a veces por varios días, para definir y revisar los requerimientos del negocio para el sistema. Sus principales ventajas son la optimización del tiempo, organización  y resolución de conflictos intrínsecos al ámbito de la gestión.  
Fundamentos del JAD.
El proceso de JAD se basa en cuatro ideas simples:
·         La gente que hace un trabajo tiene la mejor comprensión de ese trabajo
·         La gente entrenada en Tecnologías de la Información tiene la mejor comprensión de las posibilidades de esas tecnologías.
·         Los sistemas de información y los procesos del negocio raramente existen en forma aislada. Más bien trascienden los límites de cualquier sistema u oficina y afectan el trabajo en departamentos relacionados. La gente que trabaja en estas áreas relacionadas tiene una percepción valiosa del papel del sistema dentro de una comunidad más amplia.
·         Los mejores sistemas de información se diseñan cuando todos estos grupos trabajan juntos en un proyecto como socios iguales.
Roles del JAD.
Patrocinador del proyecto.
      Es quien presupuesta el proyecto, el dueño del sistema. Tienen el lugar más alto en la organización, de modo que ellos pueden tomar las decisiones y proporcionar los recursos necesarios y apoyar para el proyecto. Responsabilidades:
·         Asegurar que los clientes correctos son parte del grupo.
·         Asegurar que hay suficiente personal de soporte técnico en el proyecto.
·         Ayudar en la selección de casos de la prueba.
·         Ayudar en la definición del alcance y funcionalidad.
·         Ayudar en el benchmarking contra los sistemas actuales y los sistemas externos.
Líder del proyecto.
      Tiene que estar comprometido al proyecto, tener un conocimiento de fondo del área comercial y sistemas de información actuales relacionados. Ellos necesitan ser entusiastas y objetivos y no permitirle a ningún solo individuo dominar el grupo. Responsabilidades:
·         Asegurar que todos los roles de su equipo estén ocupados(que no falte nadie).
·         Asegurar que las reuniones se planifiquen y publiquen con agenda.
·         Asegurar que las agendas se planifican y se siguen.
·         Asegurar que se asignan las tareas y se cumplen, y que el listado de tareas se ejecutan en la secuencia prevista con su línea de tiempo.
·         Coordinar el esfuerzo de los analistas del equipo.
Registrador.
      Toma los apuntes durante una sesión, y entonces los revisa en un resumen conciso de discusiones y decisiones. Es importante que las notas resultantes no son una transcripción de quién lo dijo. Este papel puede compartirse entre varios miembros del equipo según la necesidad. Estas notas sirven como una referencia al grupo al retomar las discusiones, y para la referencia del retorno en los puntos complejos. Responsabilidades:
·         Tomar notas durante las reuniones.
·         Resumir y condensar notas después de la reunión.
·         Asegura que el líder del proyecto así como el patrocinador revisen las notas y las corrijan antes de publicarlas.
·         Guardar un historial de notas previendo la entrada de nuevos miembros al equipo en fases adelantadas del proyecto.
Time Keeper.
     Son los responsables de asegurar que se cumpla la agenda establecida a fin de optimizar el tiempo.
Clientes.
      Son los que conocen cómo funcionara el sistema y cómo se usa. Ellos ayudarán al equipo a comprender las tareas manipuladas por el sistema. Responsabilidades:
·         Definir la información con la que el proceso tiene que tratar.
·         Crear casos de uso para su prueba.
·         Analizar los obstáculos al éxito en el ambiente actual.
Tipos de Requerimientos.

Requerimientos Funcionales.
Son los requerimientos del usuario se ocupan para asignar los requerimientos de más alto nivel.  Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Se usan para designar la descripción detallada.
Los requerimientos del usuario son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema provea y de las restricciones que este debe tener. Los requerimientos del sistema establecen detalladamente los servicios y restricciones del sistema.
Requerimientos No funcionales.
Son prescindibles, condicionan lo que se tiene que hacer pero no son indispensables, indican mediante restricciones globales, de dominio y tecnología como debe construirse o funcionar.  Su fuente principal es tanto el usuario como el cliente. Definidos como característica requerida del sistema, del proceso de desarrollo, del servicio prestado o de cualquier otro aspecto del desarrollo, que señala una restricción del mismo.
 Del dominio.
Son requerimientos que provienen del dominio de aplicación del sistema y que reflejan las características de ese dominio. Éstos pueden ser funcionales o no funcionales.  Se derivan del dominio del sistema más que de las necesidades especificas de los usuarios. Pueden ser requerimientos funcionales nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares. Los requerimientos del dominio son importantes debido a que a menudo reflejan los fundamentos del dominio de aplicación. Si estos requerimientos no se satisfacen, es imposible hacer que el sistema trabaje de forma satisfactoria.
Atributos de calidad.
    Los atributos de calidad generales del software son escalabilidad, seguridad, desempeño, y modificabilidad.
Escalabilidad: Es acerca de cómo un diseño puede hacer frente con algún aspecto de los requerimientos que aumentan de tamaño en la aplicación. Para que se concrete el requisito de atributo de calidad, necesitamos entender exactamente que es lo que se espera para ser grande.
Seguridad: Es un tema técnico complejo que puede solo ser tratado con un poco de superficialidad. Seguridad se reduce al entendimiento de los requerimientos precisos de seguridad para una aplicación y la elaboración de mecanismos para soportarlos.
Desempeño: No es realmente un problema, es un enfoque en la comunidad de los atributos de calidad. Se sospecha que es asi porque es una de las cualidades de una aplicación que pueden ser a menudo cuantificados y validados.
Modificabilidad: El atributo de calidad Modificabilidad es una característica de que tan fácil es poder cambiar una aplicación para abastecer nuevos requerimientos funcionales y no funcionales. Prediciendo que la modificabilidad requiere de un costo estimado de esfuerzo y dinero para realizar cambios.