Universidad Politécnica del Oeste “Mariscal Sucre”

INGENIERIA DE SOFTWARE II
Trayecto III - Trimestre I Unidad 1

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste “Mariscal Sucre”

¿QUÉ ES IMPORTANTE?

Es importante la participación en clase Es importante la puntualidad Es importante mantener nuestros celulares apagados o en modo de vibración en clase. -no contestarlos en el salón-

Comunicación: yrmatos@gmail.com - 0426-7054640

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste “Mariscal Sucre”

ORGANIZACIÓN DEL CURSO

Clases teórico-prácticas o consultas del Proyecto Práctico:

Sección 7001: Lunes de 9:30 am a 11:05 am y Jueves de 7:00 am a 9:25 am
Sección 7002: Lunes de 7:00 am a 9:25 am y Jueves de 9:30 am a 11:05 am Sección 7024: Miércoles de 5:50 pm a 8:15 pm y Viernes de 8:20 pm a 9:55 pm

Proyecto Práctico (Tributario al Proyecto Socio-Tecnológico) Talleres prácticos relacionados con la materia con el objetivo de:

Entender el contexto del tema. Debatir las ideas expuestas en el taller. Cotejar lo que creemos saber.

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste "Mariscal Sucre" . (13-03-2013) Taller 2 (15%) (10-04-2013)    Informe del Proyecto Práctico (20%) (12-04-2013) Presentación del Proyecto (10%) (17. 24 y 26-04-2013)  © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” EVALUACIÓN DEL CURSO  1 Informe Técnico sobre el Marco ISO-9126 (10%) (30-01-2013) Taller 1 (15%) (06-02-2013)   Evaluaciones Teórica 1 (15%) (20-02-2013) Evaluación Teórica 2 (15%).

Universidad Politécnica del Oeste “Mariscal Sucre” CONTENIDO ANALÍTICO DEL CURSO SABERES Unidad 1: Requerimientos del Software o ¿Qué son los requerimientos o Requisitos? o Necesidades. Notación de Requerimientos de Usuario URN). Pizarra magnética Marcadores Material Educativo Computarizado: Material Instruccional. basados en casos de estudios únicos e integrales que permitan al participante la aplicación directa y visible de los conocimientos teóricos adquiridos durante las actividades en aula de encuentros. Objetivos Requerimientos y Actores Relacionados con los ESTRATEGIAS RECURSOS EVALUACIÓN o Importancia de la Ingeniería de Requisitos en la práctica o Levantamiento y Recolección de Requerimientos. de alta calidad. dominio. Universidad Politécnica del Oeste "Mariscal Sucre" . del © 2009 Rafael Matos. atributos de calidad. o Técnicas para escribir requerimientos Estándares de Documentación. o Técnicas más usadas: Método JAD y FPA Talleres prácticos dirigidos. Software Instruccional Computador Casos Prácticos Proyector Multimedia Plataforma Tecnológica Aula de encuentros Evaluación continua Trabajo en grupo Ejercicios individuales Participación Unidad 2: Especificación de Requerimientos o Textual. o Tipos de requerimientos: funcionales. no-funcionales. notación gráfica y lenguajes de representación (Lenguaje Unificado de Modelado UML. Trabajos de investigación que fortalezcan en el participante la capacidad de interpretación de la formación relacionada con la investigación en ingeniería del software.

o Documentos de Requerimientos de Software: Creación. Actividades del Negocio. Prototipo y Técnicas de Análisis. Importancia. o Métricas y herramientas para la ingeniería de requisitos. o Modelado Orientado a Casos de Uso. El profesor asesor elaborará un cuestionario con preguntas que orienten al participante en la identificación del conocimiento relevante que debe adquirir hacia el final de la lectura. Unidad 4: Modelado del Sistema o Técnicas y Métodos de Modelado de Sistemas. completitud.Universidad Politécnica del Oeste “Mariscal Sucre” CONTENIDO ANALÍTICO DEL CURSO (2) SABERES Unidad 3: Análisis de Requerimientos o Inspección. validación. mesas redondas y foros de discusión acerca de las consultas y lecturas recomendadas realizadas por el participante. detección de conflictos inconsistencias de requerimientos. Exposiciones. Universidad Politécnica del Oeste "Mariscal Sucre" . o Modelado del negocio: Casos de Uso del Negocio. e ESTRATEGIAS RECURSOS EVALUACIÓN usos e Lecturas orientadas. Especificación de CUN. Objetos del Negocio. © 2009 Rafael Matos.

Donald J. McGraw-Hill. Shari Lawrence (2002). N. Prentice Hall. Madrid. Addison Wesley.org Joaquin Deza de Choque. Buenos Aires. Ingeniería de Software. SOFTWARE MANAGEMENT. Graham (2000). Pearson Educación. Pressman. Ingeniería de Software. Redmond: Microsoft Press. Yingxu & King.Construcción de Software Orientado a Objetos.unpmsm. PEARSON – Prentice Hall. 1999. Pearson Education. Principles and Applications. Scott F. Meyer JACOBSON Ivar. (2001). México. Victoria Rosa. CRC Press LLC. Analyzing Requirements and Defining Solution Architectures. Addition Wesley. (2003) UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Sexta edición. Roger S. Reifer. CA Sommerville. BOOCH Grady RUMBAUCH James (1999) The United Software Development Process. Los Alamitos. Pfleeger. Choque Ayala de Joaquin . Rational Software Corporation. Sexta edición. Wilson. Universidad Politécnica del Oeste "Mariscal Sucre" . Americo . MEYER Bertrand.unpmsm.org Apuntes de Clases © 2009 Rafael Matos. IEEE Computer Society Press. Florida. Ingeniería del Software: Un enfoque práctico. Segunda Edición. (2005). Ian (2006). Ingeniero de Sistemas www. Introducción al Proceso Software Personal. Wang. (1999). Software Engineering Processes. Larman Craig. W.Universidad Politécnica del Oeste “Mariscal Sucre” REFERENCIAS BIBLIOGRÁFICAS Y FUENTES DOCUMENTALES Humphrey Watts S. (1993). Teoría y Práctica. Analista de Sistemas www.

así que la parte cliente/servidor podría ser más pequeña que la parte WEB. Sí. ¿Los 740 puntos de acceso en todo el país.Universidad Politécnica del Oeste “Mariscal Sucre” INTRODUCCIÓN (1) Un Caso Hipotético C: IS1: C: IS2: C: IS1: C: IS2: C: El sistema debe usarse en los 740 puntos ubicados en diferentes partes de la geografía nacional. van a tener conectividad? Si. las 24 horas? Bueno sabemos que en algunas partes es difícil y deben pensar en eso. !Por supuesto!. Puede ser una parte WEB y una no WEB. porque en realidad no hace falta que funcione todo si no hay conexión. ¿Qué tipo de arquitectura están esperando? Nosotros hemos pensado en un sistema WEB ¿Pero van a tener conectividad. ¿porqué quieren un sistema WEB? …Tras varios minutos de discusión. Universidad Politécnica del Oeste "Mariscal Sucre" . Perdón. me parece bien. IS2: © 2009 Rafael Matos. Una parte Cliente/Servidor y una WEB. todos van a tener banda ancha.

que nos hablan de las características específicas que el sistema tendrá.   Los atributos de calidad muchas veces se afectan entre sí. Para definir la arquitectura debemos CONOCER los requerimientos o atributos de calidad. performance o flexibilidad vs. etc. usabilidad. Por ejemplo portabilidad vs. Ejemplo: Flexibilidad. “Un software de calidad es aquel que posee una combinación deseada de atributos” IEEE Std. 1061 © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" . transportabilidad. performance.Universidad Politécnica del Oeste “Mariscal Sucre” INTRODUCCIÓN (2) Reflexiones  La funcionalidad es sólo una parte de lo que el sistema puede hacer.

El atributo de mayor importancia suele ser la flexibilidad: Facilidad de cambios. El ingeniero de software. La importancia de los atributos varia con el dominio para el cual se construye el software. En general no se analizan sus dependencias. o no especificados (un requerimiento que no es medible no es implementable).Universidad Politécnica del Oeste “Mariscal Sucre” INTRODUCCIÓN (3) Realidades sobre los Atributos de Calidad del Software  Por lo general están pobremente especificados. no el fin. Universidad Politécnica del Oeste "Mariscal Sucre" . generalmente no identifica las restricciones asociadas a los atributos de calidad que identifica.     La arquitectura de un sistema es un medio para alcanzar los atributos de calidad deseados.  © 2009 Rafael Matos.

© 2009 Rafael Matos. Identificar los problemas asociados a los requerimientos de software Diferenciar entre el espacio del problema y el espacio de solución. Universidad Politécnica del Oeste "Mariscal Sucre" . REQUERIMIENTOS DEL SOFTWARE Objetivos  Valorar la importancia de construir software de calidad Caracterizar los requerimientos de software.     Reconocer la importancia del Modelado de Negocios y de la Ingeniería de Requerimientos en el proceso de desarrollo de software de calidad.Universidad Politécnica del Oeste “Mariscal Sucre” UNIDAD I.

Universidad Politécnica del Oeste "Mariscal Sucre" . 1992] © 2009 Rafael Matos. NORMA UNE 66-001-92 Traducción de ISO 8402 [AENOR. que permite apreciarla como igual. Diccionario de la Real Academia Española Totalidad de las características de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implícitas.Universidad Politécnica del Oeste “Mariscal Sucre” ¿QUÉ ES CALIDAD? Propiedad o conjunto de propiedades inherentes a una cosa. mejor o peor que las restantes de su especie.

Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ORÍGENES DE LA CALIDAD Calidad Programada Calidad Realizada Calidad Necesaria © 2009 Rafael Matos.

Universidad Politécnica del Oeste “Mariscal Sucre” CALIDAD DE SOFTWARE Definiciones Grado con el que un sistema. 1998] © 2009 Rafael Matos. (IEEE Std. Universidad Politécnica del Oeste "Mariscal Sucre" . 610. Las necesidades o expectativas del cliente o usuario. con los estándares de desarrollo documentados y con las características implícitas que se espera de todo software desarrollado profesionalmente.1990) [IEEE. componente o proceso cumple con: – – Los requisitos [requerimientos] especificados. [Pressman. 1993] (Cursivas nuestras) Concordancia del software producido con los requisitos funcionales y de rendimiento explícitamente establecidos.

© 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126) CARACTERISTICAS/ ATRIBUTOS* FUNCIONALIDAD  DESCRIPCIÓN Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades específicas. Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas. Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestación bajo condiciones establecidas durante un período de tiempo establecido.     FIABILIDAD  Madurez Recuperabilidad Tolerancia a fallos Un conjuntos de atributos relacionados con el esfuerzo necesitado para el uso.   USABILIDAD  Aprendizaje Comprensión Operatividad   * Un atributo es una entidad la cual puede ser verificada o medida en el producto software. Las funciones son aquellas que satisfacen lo indicado o implica necesidades. y en la valoración individual de tal uso. por un establecido o implicado conjunto de usuarios. Universidad Politécnica del Oeste "Mariscal Sucre" .

modificar o corregir errores en un sistema software. Universidad Politécnica del Oeste "Mariscal Sucre" .  MANTENIBILIDAD  Estabilidad Facilidad de análisis Facilidad de cambio Facilidad de pruebas Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.Universidad Politécnica del Oeste “Mariscal Sucre” FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126) CARACTERISTICAS/ ATRIBUTOS DESCRIPCIÓN Conjunto de atributos relacionados con la relación entre el nivel de desempeño del software y la cantidad de recursos necesitados bajo condiciones establecidas.    PORTABILIDAD  Capacidad de instalación Capacidad de reemplazamiento Adaptabilidad   © 2009 Rafael Matos. EFICIENCIA  Comportamiento en el tiempo Comportamiento de recursos Conjunto de atributos relacionados con la facilidad de extender.

URL. 2. • Para la aplicación seleccionada determinar: Empresa. 1 (Valor 10%) 1. Completar la Tabla del marco ISO-9126. en función del Marco ISO-9126. Objetivos © 2009 Rafael Matos. Determinar el grado de calidad de una aplicación WEB. Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ASIGNACIÓN NRO.

o crear nuevas y concientizarnos en su utilización adecuada. Universidad Politécnica del Oeste "Mariscal Sucre" . Nosotros DEBEMOS comprometemos a mejorar las metodologías o procesos de desarrollo.Universidad Politécnica del Oeste “Mariscal Sucre” CALIDAD DEL SOFWARE Reflexión Se estima que. Cuando un proyecto fracasa. rara vez es debido a fallas técnicas. un 46% caen en severas modificaciones que lo retrasan y un 26% son totalmente exitosos. del total de proyectos software grandes emprendidos. un 28% fracasan. la principal causa de fallos y fracasos es la falta de aplicación de una buena metodología o proceso de desarrollo. © 2009 Rafael Matos.

© 2009 Rafael Matos. Este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente. Universidad Politécnica del Oeste "Mariscal Sucre" . especificación u otro documento formalmente impuesto. estándar. necesaria para resolver un problema o alcanzar un objetivo” Una condición o capacidad que debe ser satisfecha o poseida por un sistema o un componente del sistema a fin de satisfacer un contrato. (IEEE Standard Glossary of Engineering Terminology.Universidad Politécnica del Oeste “Mariscal Sucre” ¿QUÉ SON LOS REQUERIMIENTOS? (1) “Una condición o capacidad que debe poseer el sistema. 1990 ) Los requerimientos son el punto de acuerdo entre el cliente y el ingeniero de software.

cumplir o satisfacer un sistema desarrollado o adaptado para resolver un problema particular” (Sawyer y Kotonya. 1986 ) “Propiedad que debe exhibir.” (Abbott.Universidad Politécnica del Oeste “Mariscal Sucre” ¿QUÉ SON LOS REQUERIMIENTOS? (2) “Serie de instrucciones abstractas de alto nivel de un servicio o de un sistema. lograr estas funciones No intentan expresar cómo © 2009 Rafael Matos. 1998) Los requerimientos EXPRESAN lo que una aplicación o sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios. 2001) “Aspecto de un sistema o una descripción de aquello que el sistema es capaz de hacer a fin de cumplir su propósito” (Pfleeger. limitado a detallar en una especificación. Universidad Politécnica del Oeste "Mariscal Sucre" .

Aplicación de software - .El vehículo donde opera el GPS. compilador.Software de sistema -. Universidad Politécnica del Oeste "Mariscal Sucre" . vídeojuegos. controladores de procesos.Universidad Politécnica del Oeste “Mariscal Sucre” CONTEXTO DE SISTEMA El término “sistema” se refiere a: Un sistema de Software . -. entre otros.El sistema contable de una empresa . Sistema de Negocios Sistema H/S - Ejemplos: . entre otros.Software de desarrollo - . - . Un sistema de Hardware-Software - . .Ejemplo: Celulares. conductor de pruebas.Ejemplo: Herramientas CASE.Ejemplo: Aplicaciones WEB. SSD. entre otros. . GPS.Ejemplo: Sistemas operativos. DBMS.El proceso industrial controlado por un controlador automático Sistema de Software © 2009 Rafael Matos. SIG. Un sistema de Negocios Se refiere al dominio de aplicación donde un sistema de software o H/S opera. relojes digitales. entre otros. interpretes.

3. 4.Universidad Politécnica del Oeste “Mariscal Sucre” ¿QUÉ DEFINEN LOS REQUERIMIENTOS? Los requerimientos definen: 1. • La tecnología de información que debe utilizar el sistema. Las interacciones usuarios-sistema y sistema-sistema • La interfaz gráfica usuario-sistema (GUI) • La interfaz de la aplicación con otros sistemas. Lo que el sistema debe hacer • Las funciones que debe ejecutar. • Los datos que debe capturar y almacenar • La información que debe producir 2. Las restricciones bajo las cuales el sistema debe operar • La plataforma de operación del sistema. Los atributos de calidad que el sistema debe satisfacer • Estándar ISO 9126 © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" .

Universidad Politécnica del Oeste “Mariscal Sucre”

CASO DE ESTUDIO (1)
Un sistema de comercio electrónico para monedas antiguas.

RAFMA, C.A. es una empresa especializada en la compra y venta de monedas antiguas de todo el mundo, con más de 10 años en el mercado. Durante su existencia, RAFMA ha conformado una de las más completas colecciones de monedas antiguas a nivel mundial. Para operar RAFMA envía catálogos impresos de su colección a clientes selectos en todo el mundo, por los cuales deben cancelar $10. Los pedidos se hacían por correo electrónico y las monedas eran despachadas por correo courier a los clientes. Como estrategia para fortalecer el negocio RAFMA decidió cambiar su modelo de negocios por uno basado en comercio electrónico, para lo cual se contrató el desarrollo de la aplicación web: oldcurrency.com

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste “Mariscal Sucre”

CASO DE ESTUDIO (2)
Un sistema de comercio electrónico para monedas antiguas (oldcurrency.com).

Oldcurrency.com es una aplicación que permite la comercialización de monedas antiguas de y desde cualquier parte del mundo.

Algunos requerimientos

La aplicación debe permitir:

Hojear el catálogo de monedas antiguas disponible.
Buscar una moneda de acuerdo a criterios específicos. Visualizar una moneda específica. Comprar una moneda.

Recibir información sobre la moneda de preferencia de los usuarios.

© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste “Mariscal Sucre”

CLASIFICACIÓN DE LOS REQUERIMIENTOS (1)

Explícitos: Los requerimientos establecidos explícitamente se reflejan en el documento de Especificación de Requerimientos del Sistema (ERS)
– –

Requerimientos funcionales: Funciones a realizar por el software. Requerimientos no funcionales: Requerimientos de seguridad, rendimiento, interfaz, etc. Describen restricciones que limitan las opciones de solucionar el problema. Restricciones cuantitativas o precisión. Pseudorequerimientos: Impuestos por el cliente que restringen la implementación del sistema

Implícitos: Los requerimientos implícitos no aparecen en la ERS, pero si no se cumplen con ellos la calidad del software queda en entredicho.

Los estándares y las normas de desarrollo permiten que se consiga una alta calidad técnica.
© 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre"

Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” CLASIFICACIÓN DE LOS REQUERIMIENTOS (2) Según Wiegers. 2003 Requerimiento Funcional No Funcional De Negocios Del Usuario Del Sistema De Comportamiento Restricción Atributo de Calidad De Interfaz Regla de Negocio © 2009 Rafael Matos.

Se expresan desde la perspectiva del usuario. C.com deberá contribuir a abrir el mercado e incrementar el volumen de ventas anuales de monedas antiguas. • Visualizar un moneda.A. • Comprar una moneda © 2009 Rafael Matos. • Expresan que objetivos. metas o necesidades la empresa espera alcanzar con el uso del sistema. • Describen las necesidades que los usuarios tienen y las tareas que los usuarios deben realizar con el sistema o aplicación.Universidad Politécnica del Oeste “Mariscal Sucre” REQUERIMIENTOS FUNCIONALES (1) Requerimientos del Negocio  Requerimientos de Usuarios  Se expresan desde la perspectiva de la empresa • Describen porque la empresa o el cliente desea desarrollar el sistema.   Se modelan mediante casos de uso. Ejemplos: • Hojear los catálogos de monedas antiguas. Universidad Politécnica del Oeste "Mariscal Sucre" .  Ejemplos: • La empresa RAFMA. quiere abrir su mercado a cualquier usuario interesado en la adquisición de monedas antiguas. • Expresan lo que el usuario será capaz de hacer con el sistema. • La aplicación oldcurrency.

Asumen que la el software es parte de un sistema mayor. • Se denominan también requisitos funcionales propiamente dicho.Universidad Politécnica del Oeste “Mariscal Sucre” REQUERIMIENTOS FUNCIONALES (2) Requerimientos del Sistema  Requerimientos de Comportamiento  Son de alto nivel para productos que tienen componentes H/S.    Ejemplos: • El sistema oldcurrency. Universidad Politécnica del Oeste "Mariscal Sucre" . deberá permitirle al cliente efectuar el pago de su pedido en línea.com deberá enviar un mensaje electrónico cada vez que RAFMA. Se expresan desde la perspectiva del sistema H/S que contiene la aplicación. usando cualquier tarjeta de crédito. disponga de una moneda antigua de su interés. • Describen los servicios que el sistema presta a todos los usuarios directos.com. © 2009 Rafael Matos.A. • El sistema deberá permitirle al usuario visualizar la moneda o monedas seleccionadas por el usuario de los contenidos en el catálogo de monedas. • Expresan que hace el sistema bajo ciertos eventos (su comportamiento). Ejemplos: • La aplicación oldcurrency. Se expresan desde la perspectiva del desarrollador. C.

© 2009 Rafael Matos. • Costo máximo de desarrollo 50. MySql y PHP. Universidad Politécnica del Oeste "Mariscal Sucre" . prácticas. • Costo máximo de desarrollo. métodos de desarrollo. deberá tener una confiabilidad mayor a 95%.  Ejemplos: • oldcurrency. Apache. • oldcurrency.com deberá ser una aplicación web que debe ser desarrollado con las siguientes herramientas: • Plataforma LAMP: Linux. • El rendimiento que la aplicación debe tener. • Tiempo máximo de desarrollo. • Tiempo máximo de desarrollo 6 meses.. • La utilidad que debe garantizar. Expresan las propiedades de calidad que el sistema debe satisfacer.000 Bs. • Uso de estándares. • La seguridad que debe proveer. • La confiabilidad que debe poseer.com deberá ser fácil de usar.Universidad Politécnica del Oeste “Mariscal Sucre” REQUERIMIENTOS NO FUNCIONALES (1) Restricciones  Atributos de Calidad  Expresan las limitaciones que se le imponen al desarrollo del sistema. Describen aspectos tales como: • Plataforma de desarrollo y operación.com.   Ejemplos: • oldcurrency.

 Ejemplos: • oldcurrency.com deberá desarrollarse usando la metodología RUP. Universidad Politécnica del Oeste "Mariscal Sucre" . • Describen con qué o cómo la aplicación interactuará con otras aplicaciones de software o sistemas de hardware.com deberá usando una interfaz web. estrategias.) • Regulaciones propias de la aplicación (Estándares. etc. normas. Expresan las características de la interacción del usuario con el sistema. etc.com. © 2009 Rafael Matos.  • Regulaciones de la empresa (Políticas.  Ejemplos: • oldcurrency. • Requerimientos de interfaces con otros sistemas. algoritmos o clases que deben usarse). providencias. durante los dos primeros meses a partir de la publicación de la actualización. deberá interactuar con el sistema de pagos online paypal. • Un cliente puede descargar gratuitamente las actualizaciones de un catálogo adquirido por el.) (Leyes.Universidad Politécnica del Oeste “Mariscal Sucre” REQUERIMIENTOS NO FUNCIONALES (2) Reglas de Negocio  De Interfaz  Expresan todas las regulaciones que la aplicación deberá acatar. Se dividen en: • Requerimientos de interfaz gráfica (GUI). metodología que debe seguirse. entre otras: • Regulaciones gubernamentales decretos. procedimientos. • Describen las propiedades generales de la interfaz gráfica que permitirá la interacción entre el usuario y el sistema. ser implementada • Oldcurrency.

es decir: • Su comportamiento. Determinan lo que el sistema deberá hacer.  • Las reglas de negocio que el sistema debe respetar o implementar. © 2009 Rafael Matos. la del   Determinan la funcionalidad del sistema. • Su interacción con los usuarios y su dominio de aplicación (negocio) • Sus respuestas a eventos.  Restringen el diseño del sistema (la solución) Describen: • Las restricciones que se le imponen al sistema. • Las interfaces con otros sistemas. Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” DIFERENCIAS ENTRE LOS TIPOS DE REQUERIMIENTOS Requerimientos Funcionales  Requerimientos No Funcionales  Establecen: • Los objetivos de negocio respecto al sistema. • Los atributos de calidad que el sistema debe satisfacer. No están relacionados con funcionalidad o comportamiento sistema. • Los servicios que el sistema debe proporcionarle a los usuarios.

Universidad Politécnica del Oeste "Mariscal Sucre" .Lenguaje natural (español).Lenguajes gráficos (UML) . es decir. • Relevantes. Importancia para el sistema software a implementar. • No ambiguos. © 2009 Rafael Matos. deben describir toda la funcionalidad que el sistema deberá implementar y por lo tanto debe representar algo requerido por el usuario para el sistema que se construye y ser validado por este.Universidad Politécnica del Oeste “Mariscal Sucre” CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD (1) Los Requerimientos deben ser: • Completos. Todo lo que el software tiene que hacer está recogido en el conjunto de requerimientos. Cada requerimiento debe tener una sola interpretación.Lenguajes formales (Notación Z). debiendo poder expresarse de una manera sencilla. . clara y sin ambiguedades usando: .

Preferiblemente deben expresarse de manera cuantitativa. © 2009 Rafael Matos. Tipos de Inconsistencia: • Términos conflictivos: Si dos términos se usan en contextos diferentes para la misma cosa. • Verificables. • Características en conflicto: Si en dos partes de la ERS se pide que el producto muestre comportamientos contradictorios. Ningún requerimiento puede estar en conflicto con otro. Cada acción de diseño debe corresponderse con algún requerimiento del cliente (resuelve un problema de este). usando métricas que faciliten su verificación. Universidad Politécnica del Oeste "Mariscal Sucre" . • Consistentes. • Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca restricciones de tiempo contradictorias.Universidad Politécnica del Oeste “Mariscal Sucre” CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD (2) • Traceables.

3. Si excede el número se utilizará una ventana diferente. El tiempo de respuesta para el comando „DELETE’ será menor de 5 segundos. El tiempo de respuesta para todos los comandos será menor de 0. Universidad Politécnica del Oeste "Mariscal Sucre" . © 2009 Rafael Matos. 4.Universidad Politécnica del Oeste “Mariscal Sucre” EJEMPLOS DE REQUERIMIENTOS 1.” 2. El sistema tendrá un tiempo de respuesta aceptable.1 segundos. 5. El sistema tendrá una interfaz de usuario sencilla de utilizar. Hasta 15 objetos se dibujarán dentro de la misma ventana. Los usuarios deben escribir su contraseña en un tiempo menor de 15 segundos desde que escribieron su nombre de usuario.

El costo de cambiar los requerimientos crece a medida que avanza el proyecto. en forma proporcional.Universidad Politécnica del Oeste “Mariscal Sucre” ¿PORQUÉ DETERMINAR REQUERIMIENTOS? 1. El software normalmente está integrado por muchos componentes. como sigue:. $20 durante la validación. $3 durante la codificación.      © 2009 Rafael Matos. $5 durante la prueba de unidades. $2 durante la fase del diseño detallado. Universidad Politécnica del Oeste "Mariscal Sucre" . $100 después que el sistema ha entrado en producción. es difícil para el ingeniero de software entender todos estos componentes al mismo tiempo.  $1 durante la fase de diseño. En la mayor parte de los casos. 2. Reparar un requisito omitido o mal especificado se ha establecido.

No ve el sistema como algo que le pertenece. . • Los requerimientos suelen surgir a medida que el usuario se familiariza con la TIC y el sistema de información. 2.Evita participar en el proyecto. El usuario no tiene tiempo para participar en el proyecto. .Universidad Politécnica del Oeste “Mariscal Sucre” PROBLEMAS AL DETERMINAR REQUERIMIENTOS (1) 1. • Los analista no entienden el lenguaje del dominio de la aplicación.No está consciente de la importancia de su participación. Problemas de Comunicación. 3. © 2009 Rafael Matos. El usuario o cliente no siempre sabe lo que quiere del sistema. • Al inicio del proyecto. Universidad . • El cliente o el usuario no entiende el lenguaje informático de los analistas. . no sabe que esperar del sistema.

. © 2009 Rafael Matos. Los requerimientos pueden interpretarse de diferente manera.Son incompletos. .Universidad Politécnica del Oeste “Mariscal Sucre” PROBLEMAS AL DETERMINAR REQUERIMIENTOS (2) 4. .No reflejan las necesidades reales de los usuarios del sistema.El analista entiende y especifica de manera diferente los requerimientos del cliente. Universidad .El diseñador interpreta de otra manera los requisitos especificados por el analista. Requerimientos mal definidos. 5. .Son inconsistentes. .No son factibles. .

Analistas de negocios.Analistas de requerimientos. Entender el Espacio del Problema. .Modelar los requerimientos usando notaciones gráficas estandarizadas.Incorporar al cliente en el desarrollo del sistema (activamente). . . Utilizar un proceso de desarrollo bien definido y probado. 5. Entender la naturaleza del software.La naturaleza del software promueve cambios frecuentes en los requerimientos.Universidad Politécnica del Oeste “Mariscal Sucre” SOLUCIÓN A LOS PROBLEMAS DE LOS REQUERIMIENTOS 1. .. Emplear personal especializado . 2.Modelar el negocio antes de identificar y especificar requerimientos. . © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" . 3. 4.Gestionar los requisitos. Utilizar prácticas reconocidas (mejores prácticas) .

Los métodos tradicionales de desarrollo de software importancia del problema y su análisis. La separación del espacio del problema y el de la solución es crucial en toda ingeniería. La ingeniería de sistemas físicos establece una clara separación entre ambos espacios (problema y solución).No alinea la solución al negocio. Las necesidades ocurren en el espacio del problema.Se centran en la solución y sus requisitos. 3. © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA – ESPACIO DE LA SOLUCION (1) 1. subestiman la . Los requerimientos tienen lugar en el espacio de la solución. 5. 4. Universidad Politécnica del Oeste "Mariscal Sucre" . debido a que: .. 2.

Universidad Politécnica del Oeste "Mariscal Sucre" . ES RELEVANTE DEFINIR CLARAMENTE EL DOMINIO ESPACIO DE PROBLEMA DOMINIO = ESPACIO DEL PROBLEMA © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA – ESPACIO DE LA SOLUCION (2)  Todo software ha de tener una alcance funcional. interesa al diseñador.  El dominio del problema es la parte del mundo. que para el fin del software a construir.  El diseñador debe establecer los límites del problema. MUNDO REAL  Lo que está dentro de los límites (dominio) forma parte del problema  Lo que está fuera de los límites no forma parte del problema .

Ingeniería de Requerimientos (IR) MN IR © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” INGENIERIA DE REQUERIMIENTOS Modelado del Negocio (MN) Estudia el Espacio del Problema en Ingeniería de Software INGENIERÍA DE SOFTWARE Está asociada al problema de los requerimientos y al Espacio de la Solución. Universidad Politécnica del Oeste "Mariscal Sucre" .

¿Qué actividades de un proceso de negocio requieren ser automatizadas? • Los requerimientos de una aplicación dependen de los procesos de negocio que la aplicación soporta (cómo y porqué lo hace). • Una buena práctica de la IR es modelar los procesos de negocio antes de definir sus requisitos. .¿Qué información requieren los usuarios para ejecutar sus procesos de negocio?. Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (1) Necesidades y Requerimientos • Los requerimientos funcionales de un sistema expresan necesidades de información: .Se puede hacer mediante la elaboración de un pequeño modelo. . © 2009 Rafael Matos. .Si los procesos de negocio no se conocen. la identificación de necesidades y la especificación de requerimientos no tienen fundamentación alguna.

Universidad Politécnica del Oeste "Mariscal Sucre" .Actores y su organización. tales como: . . . Es un resumen de cómo una organización planifica servir a sus clientes. © 2009 Rafael Matos. • El producto del MN son los MODELOS DE NEGOCIO. .Procesos de Negocio y sus actividades. • El MN identifica y representa aspectos del sistema de negocios. • Es el mecanismo por el cual un negocio trata de generar ingresos y/o beneficios.El dominio es denominado SISTEMA DE NEGOCIOS.Objetivos de la organización.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (2) • El Modelado de Negocios (MN) es un proceso a través del cual se representa el dominio de una aplicación. • En aplicaciones empresariales el MN representa diferentes aspectos del dominio de la aplicación. . .Reglas de Negocio.Objetos del Negocio.

y cómo se relaciona con ellos • Un Modelo de Negocios es un documento compuesto por un conjunto de submodelos. Universidad Politécnica del Oeste "Mariscal Sucre" . . cómo llega a ellos. Modelo de Negocios El Problema Sub-modelos Objetivos Procesos de Negocio Objetos de Negocio Actores Reglas de Negocio Eventos Requerimientos Funcionales Requerimientos No Funcionales La Solución © 2009 Rafael Matos. es una representación simplificada de la lógica de negocio que describe lo que un negocio ofrece a sus clientes.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (3) • El Modelo de Negocios de una empresa.Cada sub-modelo describe uno o más elementos organizacionales.

– Se analiza cada proceso para determinar que información requiere. – Los diagramas de actividades permiten identificar aquellas acciones que se desean automatizar. Universidad Politécnica del Oeste "Mariscal Sucre" . • Caracterizar el nuevo proceso de negocios y su flujo de trabajo. • Facilitar la definición y especificación de requerimientos funcionales.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (4) En la fase de Ingeniería de Requerimientos. © 2009 Rafael Matos. • Descubrir las necesidades que los usuarios tienen. el Modelo de Negocios es usado para: • Entender el proceso de negocio actual y establecer sus problemas de información.

Métodos . a mejorar la definición y - © 2009 Rafael Matos. encargada del estudio de los requerimientos para automatizar sistemas.Los problemas de los requerimientos.Mejores prácticas .Técnicas y . Universidad Politécnica del Oeste "Mariscal Sucre" .Principios .Las soluciones que pueden contribuir a resolver estos problemas.Modelos .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (1) • La Ingeniería de Requerimientos (IR) es una sub-disciplina de la Ingeniería de Software. • La IR se encarga de establecer: . • La IR estudia: . .Herramientas automatizadas que contribuyan especificación de los requerimientos.

© 2009 Rafael Matos. − Lograr un entendimiento común. de los requerimientos que debe satisfacer el sistema. Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (2) • La aplicación de la IR al desarrollo de un sistema conduce a: − Encontrar y definir las necesidades que tienen los interesados de la aplicación. entre usuarios y desarrolladores. − Transformar la definición de necesidades en una descripción completa y precisa de requerimientos denominada: Especificación de Requerimientos de Software (ERS).

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (3) La Ingeniería de Requerimientos elementos fundamentales que son: tiene tres El Equipo: ¿Quiénes lo hacen? El Producto: ¿Qué se hace? El Proceso: ¿Cómo hacerlo? © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" .

Los Clientes.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (4) El Producto ¿Qué produce la Ingeniería de Requerimientos? • Su producto principal es el DOCUMENTO DE REQUERIMIENTOS. .Contiene el conjunto de requerimientos que debe satisfacer el sistema • El Documento de Requerimientos (DR) es un documento manual o electrónico que describe y comunica de manera sencilla y comprensible los requerimientos para: .Desarrolladores del sistema © 2009 Rafael Matos. . Universidad Politécnica del Oeste "Mariscal Sucre" . usuarios y gerentes.

Documento de Definición de Requerimientos (DDR) . .Los servicios y funciones que debe ofrecer el sistema.Las propiedades o atributos de calidad que deberá caracterizar al sistema.Documento de Especificación de Requerimientos (DER) © 2009 Rafael Matos.Las restricciones bajo las cuales deberá operar el sistema. . Universidad Politécnica del Oeste "Mariscal Sucre" . • Normalmente el documento se divide en dos partes: .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (5) El Producto • El Documento de Requerimientos debe describir: .

Universidad Politécnica del Oeste "Mariscal Sucre" . • Los requerimientos se describen en un lenguaje o notación técnica. • Los requerimientos se describen en lenguaje natural (español) . • Está orientado usuarios. • Está orientado a los desarrolladores. SADT. • Tiene un carácter técnico. a los clientes y/o Documento de Especificación de Requerimientos (DER) • Describe detalladamente los requerimientos contenidos en el DDR. ER © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (6) El Producto Documento de Definición de Requerimientos (DDR) • Describe los requerimientos de alto nivel desde la perspectiva de los clientes y/o usuarios.Ejemplo: UML.

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (7) El Producto Existen varios estándares y modelos (plantillas o patrones) que ayudan a elaborar el DR. . .Permite documentar cada requerimiento mediante un formato especial. − Es también un estándar ANSI • La plantilla Volere. • El estándar IEEE 830-1993 − Propuesto por el Institute of Electrical and Electronics Engineers (IEEE) − Agrupa los documentos DDR y DER en un solo documento.

Propósito 2. Definiciones.Requisitos de adaptación del sitio. Otros requisitos . Referencias 5.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (8) El Producto El estándar IEEE-830-1993 I.Interfaces de comunicación 3. Indice . Requisitos de desempeño 4. Restricciones de diseño 5. Características del usuario 4.Operaciones . 4. Descripción general 1. Suposiciones y dependencias 6. Perspectivas del producto . Apéndices V.Restricciones de memoria . Requerimientos específicos 1. Funciones del producto 3. Introduccción 1.Interfaces de H/S . Atributos de calidad del sistema 6. Clases/Objetos II.Interfaces del sistema . Estructura del documento III. acrónimos y abreviaturas. Requerimientos de interfaz 2. Alcance 2. Restricciones 5. Distribución de requisitos 3.Interfaces del usuario . IV.

56 Documentos de Soporte: Historico de cambios: Manual de Ventas 15/07/2010 Proyecto: oldcurrency. Fuente (que interesado lo propone) Unidad en la que se origina: Pedro Pérez Departamento de Ventas Criterios de Validación Los valores obtenidos se compararan con los obtenidos en años pasados para determinar si hay inconsistencias.2. mensual y anual ingresos por concepto de venta de monedas antíguas de cada una de las casa sucursales de RAFMA en los cinco continentes. Grado de satisfacción del usuario: Grado de insatisfacción del interesado: 3 5 Dependencias (qué requisitos dependen de este): Conflictos (qué requisitos son incompatibles con este) 35.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (9) El Producto Plantilla Volere Identificador del Requisito: 45 Tipo de Requisito: Funcional Caso de Uso: 4. mensuales y anuales de venta de monedas antíguas de cada sucursal. Justificación del requisito Es necesario elaborar los reportes de ingresos diarios.com Analista: Rafael Matos .1 Descripción: Calcular el promedio diario.

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (10) El Proceso La Ingeniería de Requerimientos consta de cinco grandes procesos: Capturan. filtran y documentan los requisitos Obtención de Requisitos Análisis de Requisitos Especificación de Requisitos Procesos Técnicos Validación de Requisitos Procesos de Gestión Gestión de Requisitos Controlan y apoyan a los procesos técnicos . organizan.

Universidad Politécnica del Oeste "Mariscal Sucre" . © 2009 Rafael Matos. Entidades externas que interactúan con el sistema − Adquisición de conocimientos sobre el dominio de la aplicación. − Organización del conocimiento − Recolección de los requerimientos que tienen los interesados.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (11) El Proceso de Obtención de Requerimientos • Denominada también Captura de Requerimientos • Consiste en la búsqueda y recolección de requerimientos • Sus actividades principales son: Establecimiento de objetivos y descripción del problema. − Identificación de actores o interesados (stakeholders). Identificación de escenarios. es decir. enfocada e informal de una sola característica del sistema desde el punto de vista de un solo actor. Descripción concreta.

para calibrar el impacto de construir y utilizar el sistema. Supervisores del contrato. Dueños del Sistema. etc. © 2009 Rafael Matos. para del sistema. Existen internos y externos. ¿cuándo recuperaran la inversión y cómo la recuperaran?. los dueños del sistema tienden a estar interesados en: ¿cuánto costara el sistema?.… Este grupo es quien paga por el sistema. Para cualquier sistema de información grande o pequeño habrá 1 o mas dueños del sistema.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (12) El Proceso de Obtención de Requerimientos Actores 1. Universidad Politécnica del Oeste "Mariscal Sucre" . 4. Sugieren hitos de control y cronogramas que disciplinan el desarrollo del sistema. Deben comprender y trasmitir adecuadamente los requerimientos. 2. Clientes y usuarios. Los Gerentes de Negocios. ¿cuál será el costo/beneficio?. 3.

Usarán los requerimientos como base del desarrollo. desarrolla un plan para el cambio y especialista que demás para 6. que sirve de catalizador para el cambio. facilitar el cambio procesos y la tecnología de la información pueden en conjunto mejorar un negocio. Los tres principales roles del analista de sistemas son el de consultor. El analista desempeña diversos roles. © 2009 Rafael Matos. Es un coopera con los estudia los problemas y necesidades de una organización para determinar como las personas.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (13) El Proceso de Obtención de Requerimientos Actores 4. Los verificadores. exporto en soporte técnico y agente de cambio. datos. Universidad Politécnica del Oeste "Mariscal Sucre" . Analistas de Sistemas. en ocasiones varios de ellos al mismo tiempo. Los Diseñadores. Encargados de las sesiones de prueba destinadas a asegurar Un agente de cambio se puede definir como alguien que el sistema cumple los requerimientos. 5.

Métodos y Técnicas a. Observación directa h.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (14) El Proceso de Obtención de Requerimientos Administración de la Captura de Requerimientos 1. JAD f. Entrevistas c. Personas con puntos de vista necesarios. j. Fuentes a. Prototipos g. FPA k. Revisión de Documentos. Torbellino de ideas l. Cuestionarios b. 2. Universidad Politécnica del Oeste "Mariscal Sucre" . b. Análisis de documentos © 2009 Rafael Matos. Reutilización de requisitos i. Uso de Modelo de Negocios Ingeniería de Reverso e. Talleres d.

• Documentación a analizar: − Sobre las prácticas existentes de los usuarios. Universidad Politécnica del Oeste "Mariscal Sucre" . − Sobre el modelo lógico − Sobre los modelos de procesos y datos − Sobre requisitos existente © 2009 Rafael Matos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (15) El Proceso de Obtención de Requerimientos Administración de la Captura de Requerimientos – Fuentes Revisión de Documentos • Es imprescindible cuando: − El sistema se instalará en infraestructuras existentes. − Sobre procedimientos de soporte. − Sobre componentes técnicos. − Suplemento de funcionalidad ya disponible.

Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (16) El Proceso de Obtención de Requerimientos Administración de la Captura de Requerimientos – Fuentes Personas Identificar personas con puntos de vista precisos para representar el conjunto de los requerimientos: ES Dirección General 1. © 2009 Rafael Matos. Usuarios Finales y Dirección PUNTO DE VISTA Clientes Proveedores El Equipo Operativo El Equipo de Mantenimiento ConsultoríaJ urídica u otros expertos. 5. 6. 4. 3. 7. IMPORTANTE CONTAR CON MÁS DE UNA PERSONA POR CADA 2.

− Modelar requisitos  Elaborar los modelos funcional. • Las Actividades principales de esta etapa son: − Refinamiento y clasificación de requerimientos  Verificar necesidad. Universidad Politécnica del Oeste "Mariscal Sucre" . − Construir un prototipo de la interfaz gráfica © 2009 Rafael Matos. − Refinar los requisitos obtenidos. establecer prioridades. priorizar y acordar requisitos. consistencia. estructural y dinámico de la aplicación. − Negociación de requerimientos  Discutir. completitud y factibilidad. − Establecer acuerdos entre los usuarios y desarrolladores sobre los requerimientos que se pueden implementar.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (17) El Proceso de Análisis de Requerimientos • Consiste en analizar los requerimientos recolectados durante el proceso de obtención con el fin de: − Determinar y resolver posibles conflictos entre requisitos.

− Modelado de funciones mediante Diagramas de Casos de Uso. Universidad Politécnica del Oeste "Mariscal Sucre" . © 2009 Rafael Matos. − Modelado de Flujo de Trabajo a través de Diagramas de Actividad − Modelado de la Estructura de la Aplicación usando Diagramas de Clase − Modelado de la Dinámica de la Aplicación mediante Diagramas de Secuencia. Análisis Orientado a Objetos. • Técnicas de Negociación. − Modelado de procesos mediante Diagramas de Flujo de Datos (DFD) − Modelado de Transiciones empleando Diagramas de Estado − Modelado de Entidades por medio de Diagramas Entidad Relación (DER) • Prototipos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (18) El Proceso de Análisis de Requerimientos Técnicas Utilizadas • • Análisis de los Procesos de Negocio. • Análisis Estructurado de Sistemas.

− Documentación de los requerimientos del desarrollador © 2009 Rafael Matos. 2000] • Actividades.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (19) El Proceso de Especificación de Requerimientos • • • Consiste en la documentación de los requerimientos. calidad y verificabilidad del Documento de Requisitos (El Producto) Premisa: − “La documentación de requerimientos es la presentación fundamental para el manejo exitoso de estos” [Kotonya y Sommerville. − Selección del estándar de documentación − Documentación de los requerimientos del cliente. Está relacionado con la estructura. Universidad Politécnica del Oeste "Mariscal Sucre" .

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (20) El Proceso de Especificación de Requerimientos Técnicas Utilizadas • Uso de estándares de documentación de requisitos − IEEE 830-1998 − IEEE P1233/D3 − ISO/IEC 12119-1994 − IEEE 1362-1998 • Indicadores de Calidad − Modelo de Calidad del Software (Marco ISO 9126) • Lenguajes y Notaciones − Lenguajes de Modelado Gráfico  Lenguaje Orientado a Objetos (UML)  Lenguajes Estructurados: DFD. Diagramas de Estado © 2009 Rafael Matos. ER. Universidad Politécnica del Oeste "Mariscal Sucre" .  Lenguajes Dinámicos: Redes de Petri.

Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (21) El Proceso de Validación de Requerimientos • Consiste en examinar los productos elaborados durante la Ingeniería de Requerimientos para determinar si son descripciones válidas y aceptables de los requisitos del sistema que se desea construir. • Productos de la IR que se validan en este proceso. − Lista de requerimientos recolectados − Modelos de requerimientos  Modelo funcional. estructural y dinámico − Prototipos − Documentos de Requisitos  Documento de Definición de Requerimientos  Documento de Especificación de Requerimientos © 2009 Rafael Matos.

Universidad Politécnica del Oeste "Mariscal Sucre" .Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (22) El Proceso de Validación de Requerimientos Los productos de la IR se validan para determinar si sus requisitos son: • Correctos − Satisfacen las necesidades reales de los usuarios • Completos − Incluyen todos los requisitos que los usuarios necesitan • Consistentes − No hay conflicto entre los requerimientos • Cumplen con los estándares establecidos • Precisos − No hay requerimientos ambiguos • Libres de errores © 2009 Rafael Matos.

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (23) El Proceso de Validación de Requerimientos Actividades y Técnicas utilizadas: • Revisión Técnica − Inspección de modelos − Inspección de documentos • Validación de Prototipos − Evaluación de prototipos de interfaces gráficas • Definición de criterios de aceptación − Establecer los criterios que los usuarios emplearán para aceptar el sistema © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" .

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (24) El Proceso de Gestión de Requerimientos Esta relacionado con: • La planificación de las actividades de IR • El manejo de los cambios − Control de cambios de requerimientos • El manejo de las relaciones entre requerimientos − Establecer los criterios que los usuarios emplearán para aceptar el sistema • El manejo de las dependencias entre el documento de requerimientos y otros documentos producidos en el desarrollo del sistema − Seguimiento o trazabilidad de requerimientos © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" .

Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (25) El Proceso de Gestión de Requerimientos Actividades y Técnicas utilizadas: • Planificación y Control de Proyectos • Gestión de Cambios • Gestión de Almacenamiento de Requerimientos  Identificación de Requerimientos  Uso de procesadores de texto  Uso de bases de datos de requerimientos • Rastreo o trazabilidad de Requisitos © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" .

• Para garantizar el éxito del proceso IR.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (26) El Equipo de Requerimientos ¿Quiénes participan en el proceso de Ingeniería de Requerimientos? • En la elaboración del Documento de Requerimientos participan un conjunto de interesados o actores. • A este conjunto organizado de actores se le conoce como Equipo de Requerimientos © 2009 Rafael Matos. el conjunto de actores debe estar debidamente organizado y estructurado. Universidad Politécnica del Oeste "Mariscal Sucre" .

© 2009 Rafael Matos. • Planificar el proceso de requerimientos. • Elaborar el Documento de Requerimientos siguiendo el proceso. Universidad Politécnica del Oeste "Mariscal Sucre" . • Mantener actualizado el Documento de Requerimientos.Universidad Politécnica del Oeste “Mariscal Sucre” ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (27) El Equipo de Requerimientos Responsabilidades y Funciones del Equipo de Requerimientos • Seleccionar el modelo de procesos apropiados para ejecutar el proceso de IR. • Hacerle seguimiento a los requerimientos (mantener la trazabilidad) • Proporcionar soporte técnico al equipo de desarrollo del sistema en relación a los requerimientos. • Adaptar el modelo de proceso de la IR a las características del proyecto y la empresa.