La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Trayecto.

Presentaciones similares


Presentación del tema: "Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Trayecto."— Transcripción de la presentación:

1 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Trayecto III. Trimestre I

2 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" ¿PORQUÉ ESTAMOS ACA? Queremos capacitarlos para participar en los grandes proyectos, tanto técnicos como de gestión, de desarrollo de software que el país demanda. Queremos DESPERTAR SU INTERES en el desarrollo de software como un mecanismo eficiente para la administración de nuestro recurso más valioso: La información. Queremos que sean AGENTES DE CAMBIO para potenciar el crecimiento del desarrollo de software en nuestro país.

3 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. 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:

4 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" ORGANIZACIÓN DEL CURSO Clases teórico-prácticas o consultas del Proyecto Práctico los Lunes de 7:00 a.m. a 9:10 a.m. y los Miércoles de 7:00 a.m. a 8:25 a.m. Proyecto Práctico 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.

5 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" EVALUACIÓN DEL CURSO Tres Evaluaciones parciales teórico prácticos. (50%) Un Taller práctico UML (10%). Informe sobre calidad de Software. (10%) Proyecto Práctico (30%)

6 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" SABERESESTRATEGIASRECURSOSEVALUACIÓN Unidad 1: Requerimientos del Software o ¿Qué son los requerimientos o Requisitos? o Necesidades, objetivos y actores relacionados con los requerimientos o Importancia de la Ingeniería de Requisitos en la práctica o Levantamiento y Recolección de Requerimientos. o Técnicas más usadas: Método JAD y FPA Unidad 2: Especificación de Requerimientos o Textual, notación gráfica y lenguajes de representación (Lenguaje Unificado de Modelado UML, Notación de Requerimientos de Usuario URN). o Técnicas para escribir requerimientos de alta calidad. Estándares de Documentación. o Tipos de requerimientos: funcionales, no-funcionales, del dominio, atributos de calidad. Talleres prácticos dirigidos, 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. 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. Pizarra magnética Marcadores Material Educativo Computarizado: Material Instruccional, Software Instruccional Computador Proyector Multimedia Plataforma Tecnológica Aula de encuentros Evaluación continua Trabajo en grupo Ejercicios individuales Participación Casos Prácticos CONTENIDO ANALÍTICO DEL CURSO

7 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" SABERESESTRATEGIASRECURSOSEVALUACIÓN Unidad 3: Análisis de Requerimientos o Inspección, validación, completitud, detección de conflictos e inconsistencias de requerimientos. o Documentos de Requerimientos de Software: Creación, usos e Importancia. o Métricas y herramientas para la ingeniería de requisitos. Unidad 4: Modelado del Sistema o Técnicas y métodos de modelado de sistemas. o Modelado orientado a casos de uso, prototipo y técnicas de análisis. o Modelado del negocio: Casos de uso del negocio, Especificación de CUN, Actividades del negocio, Objetos del Negocio. Lecturas orientadas. 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. Exposiciones, mesas redondas y foros de discusión acerca de las consultas y lecturas recomendadas realizadas por el participante. CONTENIDO ANALÍTICO DEL CURSO (2)

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

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

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

11 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" REALIDADES SOBRE LOS ATRIBUTOS DE CALIDAD DEL SOFTWARE Por lo general están pobremente especificados, o no especificados (un requerimiento que no es medible no es implementable). En general no se analizan sus dependencias. La importancia de los atributos varia con el dominio para el cual se construye el software. El ingeniero de software, 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, no el fin. El atributo de mayor importancia suele ser la flexibilidad: Facilidad de cambios.

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

13 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" ¿QUÉ ES CALIDAD? Propiedad o conjunto de propiedades inherentes a una cosa, que permite apreciarla como igual, mejor o peor que las restantes de su especie. 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. NORMA UNE Traducción de ISO 8402 [AENOR, 1992]

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

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

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

17 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" CARACTERISTICAS/ ATRIBUTOS DESCRIPCIÓN EFICIENCIA 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. Comportamiento en el tiempo Comportamiento de recursos MANTENIBILIDAD Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software. Estabilidad Facilidad de análisis Facilidad de cambio Facilidad de pruebas PORTABILIDAD Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra. Capacidad de instalación Capacidad de reemplazamiento Adaptabilidad FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126)

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

19 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Una condición o capacidad que debe poseer el sistema, 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, estándar, especificación u otro documento formalmente impuesto. (IEEE Standard Glossary of Engineering Terminology, 1990 ) Los requerimientos son el punto de acuerdo entre el cliente y el ingeniero de software. Este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente. ¿QUÉ SON LOS REQUERIMIENTOS? (1)

20 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Serie de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar en una especificación. (Abbott, 1986 ) Propiedad que debe exhibir, cumplir o satisfacer un sistema desarrollado o adaptado para resolver un problema particular (Sawyer y Kotonya, 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, 1998) ¿QUÉ SON LOS REQUERIMIENTOS? (2) Los requerimientos EXPRESAN lo que una aplicación o sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios. No intentab expresar cómo lograr estas funciones

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

22 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Los requerimientos definen: ¿QUÉ DEFINEN LOS REQUERIMIENTOS? 1. 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 interacciones usuarios-sistema y sistema-sistema 3. Las restricciones bajo las cuales el sistema debe operar La interfaz gráfica usuario-sistema (GUI) La interfaz de la aplicación con otros sistemas. La plataforma de operación del sistema. La tecnología de información que debe utilizar el sistema. 4. Los atributos de calidad que el sistema debe satisfacer Estándar ISO 9126

23 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Un sistema de comercio electrónico para monedas antiguas. CASO DE ESTUDIO 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

24 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Un sistema de comercio electrónico para monedas antiguas (oldcurrency.com). CASO DE ESTUDIO Oldcurrency.com es una aplicación que permite la comercialización de monedas antiguas de y desde cualquier parte del mundo. 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. Algunos requerimientos

25 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. 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.

26 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" CLASIFICACIÓN DE LOS REQUERIMIENTOS (2) Según Wiegers, 2003 Requerimiento FuncionalNo Funcional De Negocios Del UsuarioDel Sistema De Comporta- miento Restricción Atributo de Calidad De Interfaz Regla de Negocio

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

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

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

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

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

32 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD Los Requerimientos deben ser: Completos. Todo lo que el software tiene que hacer está recogido en el conjunto de requerimientos, es decir, deben describir toda la funcionalidad que el sistema deberá implementar. No ambiguos. Cada requerimiento debe tener una sola interpretación. debiendo poder expresarse de una manera sencilla, clara y sin ambiguedades usando: - Lenguaje natural (español). - Lenguajes gráficos (UML) - Lenguajes formales (Notación Z). Relevantes. Importancia para el sistema software a implementar. Traceables. Cada acción de diseño debe corresponderse con algún requerimiento del cliente (resuelve un problema de este). Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando métricas que faciliten su verificación.

33 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" CARACTERÍSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD Los Requerimientos deben ser: Correctos. Cada requerimiento establecido debe representar algo requerido por el usuario para el sistema que se construye y ser validado por este. Consistentes. Ningún requerimiento puede estar en conflicto con otro. Tipos de inconsistencias: Términos conflictivos: Si dos términos se usan en contextos diferentes para la misma cosa. Características en conflicto: Si en dos partes de la ERS se pide que el producto muestre comportamientos contradictorios. Inconsistencia temporal: Si dos partes de la ERS piden que el producto obedezca restricciones de tiempo contradictorias.

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

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

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

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

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

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

40 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" Todo software ha de tener una alcance funcional. El diseñador debe establecer los límites del problema. 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. El dominio del problema es la parte del mundo, que para el fin del software a construir, interesa al diseñador. MUNDO REAL MUNDO REAL ESPACIO DE PROBLEMA ES RELEVANTE DEFINIR CLARAMENTE EL DOMINIO DOMINIO = ESPACIO DEL PROBLEMA ESPACIO DEL PROBLEMA – ESPACIO DE LA SOLUCION (2)

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

42 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (1) Los requerimientos funcionales de un sistema expresan necesidades de información: - ¿Qué información requieren los usuarios para ejecutar sus procesos de negocio?. - ¿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). - Si los procesos de negocio no se conocen, la identificación de necesidades y la especificación de requerimientos no tienen fundamentación alguna. Una buena práctica de la IR es modelar los procesos de negocio antes de definir sus requisitos. - Se puede hacer mediante la elaboración de un pequeño modelo. NECESIDADES Y REQUERIMIENTOS

43 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. 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. Es el mecanismo por el cual un negocio trata de generar ingresos y/o beneficios. Es un resumen de cómo una organización planifica servir a sus clientes. En aplicaciones empresariales el MN representa diferentes aspectos del dominio de la aplicación. - El dominio es denominado SISTEMA DE NEGOCIOS. El MN identifica y representa aspectos del sistema de negocios, tales como: - Objetivos de la organización. - Procesos de Negocio y sus actividades. - Reglas de Negocio. - Objetos del Negocio. - Actores y su organización. El producto del MN son los MODELOS DE NEGOCIO.

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

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

46 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. 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, encargada del estudio de los requerimientos para automatizar sistemas. La IR estudia: - Los problemas de los requerimientos. - Las soluciones que pueden contribuir a resolver estos problemas. La IR se encarga de establecer: - Principios - Modelos - Métodos - Mejores prácticas - Técnicas y -Herramientas automatizadas que contribuyan a mejorar la definición y especificación de los requerimientos. -

47 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. 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. - Transformar la definición de necesidades en una descripción completa y ´precisa de requerimientos denominada: Especificación de Requerimientos de Software (ERS). - Lograr un entendimiento común, entre usuarios y desarrolladores, de los requerimientos que debe satisfacer el sistema.

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

49 Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (3) ¿Qué produce la Ingeniería de Requerimientos? El Producto 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: - Los Clientes, usuarios y gerentes. - Desarrolladores del sistema

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

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

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

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

54 Universidad Politécnica del Oeste Mariscal Sucre ESPACIO DE LA SOLUCIÓN: INGENIERIA DE REQUERIMIENTOS (5) El Producto Plantilla Volere Identificador del Requisito:Tipo de Requisito:Caso de Uso: 45Funcional4.2.1 Descripción: Calcular el promedio diario, 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. Justificación del requisito Es necesario elaborar los reportes de ingresos diarios, mensuales y anuales de venta de monedas antíguas de cada sucursal. Fuente (que interesado lo propone)Unidad en la que se origina: Pedro PérezDepartamento de Ventas Criterios de Validación Los valores obtenidos se compararan con los obtenidos en años pasados para determinar si hay inconsistencias. Grado de satisfacción del usuario:Grado de insatisfacción del interesado: 35 Dependencias (qué requisitos dependen de este):Conflictos (qué requisitos son incompatibles con este) 35, 56 Documentos de Soporte:Historico de cambios: Manual de Ventas15/07/2010 Proyecto: oldcurrency.com Analista: Rafael Matos

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


Descargar ppt "Universidad Politécnica del Oeste Mariscal Sucre © 2009 Rafael Matos. Universidad Politécnica del Oeste "Mariscal Sucre" INGENIERIA DE SOFTWARE II Trayecto."

Presentaciones similares


Anuncios Google