Documentos de Académico
Documentos de Profesional
Documentos de Cultura
INGENIERIA DE SOFTWARE II
Trayecto III. Trimestre I
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
QU ES IMPORTANTE?
Es importante la participacin en clase Es importante la puntualidad Es importante mantener nuestros celulares apagados o en modo de vibracin, en clase. -no contestarlos en el saln-
Universidad Politcnica del Oeste Mariscal Sucre
Clases terico-prcticas o consultas del Proyecto Prctico los Lunes de 7:00 a.m. a 9:10 a.m. y los Mircoles de 7:00 a.m. a 8:25 a.m.
Proyecto Prctico Talleres prcticos 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.
Universidad Politcnica del Oeste Mariscal Sucre
Tres Evaluaciones parciales terico prcticos. (50%) Un Taller prctico UML (10%). Informe sobre calidad de Software. (10%) Proyecto Prctico (30%)
Universidad Politcnica del Oeste Mariscal Sucre
SABERES
ESTRATEGIAS
RECURSOS
EVALUACIN
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 Ingeniera de Requisitos en la prctica o Levantamiento y Recoleccin de Requerimientos. o Tcnicas ms usadas: Mtodo JAD y FPA Trabajos de investigacin que fortalezcan en el participante la capacidad de interpretacin de la formacin relacionada con la investigacin en ingeniera del software. Talleres prcticos dirigidos, basados en casos de estudios nicos e integrales que permitan al participante la aplicacin directa y visible de los conocimientos tericos adquiridos durante las actividades en aula de encuentros.
Pizarra magntica Marcadores Material Educativo Computarizado: Material Instruccional, Software Instruccional Computador Proyector Multimedia Plataforma Tecnolgica Aula de encuentros Evaluacin continua Trabajo en grupo Ejercicios individuales Participacin Casos Prcticos
Unidad 2: Especificacin de Requerimientos o Textual, notacin grfica y lenguajes de representacin (Lenguaje Unificado de Modelado UML, Notacin de Requerimientos de Usuario URN). o Tcnicas para escribir requerimientos de alta calidad. Estndares de Documentacin. o Tipos de requerimientos: funcionales, no-funcionales, atributos de calidad. del dominio,
Universidad Politcnica del Oeste Mariscal Sucre
SABERES
ESTRATEGIAS
RECURSOS
EVALUACIN
usos e
Unidad 4: Modelado del Sistema o Tcnicas y mtodos de modelado de sistemas. o Modelado orientado a casos de uso, prototipo y tcnicas de anlisis. o Modelado del negocio: Casos de uso del negocio, Especificacin de CUN, Actividades del negocio, Objetos del Negocio.
Exposiciones, mesas redondas y foros de discusin acerca de las consultas y lecturas recomendadas realizadas por el participante.
Universidad Politcnica del Oeste Mariscal Sucre
Humphrey Watts S. (2001). Introduccin 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 introduccin al anlisis y diseo orientado a objetos y al proceso unificado. PEARSON Prentice Hall. Segunda Edicin. MEYER Bertrand, (1999).Construccin de Software Orientado a Objetos. Prentice Hall,
Pfleeger, Shari Lawrence (2002). Ingeniera de Software. Teora y Prctica. Pearson Education, Buenos Aires.
Pressman, Roger S. (2005). Ingeniera del Software: Un enfoque prctico; Sexta edicin. McGraw-Hill, Madrid.
Reifer, Donald J. (1993). SOFTWARE MANAGEMENT. IEEE Computer Society Press. Los Alamitos, CA Sommerville, Ian (2006). Ingeniera de Software; Sexta edicin. Pearson Educacin, Mxico. 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, 1999. Choque Ayala de Joaquin , Americo . Ingeniero de Sistemas www.unpmsm.org Joaquin Deza de Choque, Victoria Rosa. Analista de Sistemas www.unpmsm.org Apuntes de Clases
Universidad Politcnica del Oeste Mariscal Sucre
UN CASO HIPOTTICO
C: IS1: C: IS2: C: IS1: C: IS2: C: El sistema debe usarse en los 740 puntos ubicados en diferentes partes de la geografa nacional. Los 740 puntos de acceso en todo el pas, van a tener conectividad? Si, todos van a tener banda ancha. Qu tipo de arquitectura estn esperando? Nosotros hemos pensado en un sistema WEB Pero van a tener conectividad, las 24 horas? Bueno sabemos que en algunas partes es difcil y deben pensar en eso. Puede ser una parte WEB y una no WEB. !Por supuesto!. Una parte Cliente/Servidor y una WEB. S, me parece bien, porque en realidad no hace falta que funcione todo si no hay conexin; as que la parte cliente/servidor podra ser ms pequea que la parte WEB. Perdn, porqu quieren un sistema WEB?
Universidad Politcnica del Oeste Mariscal Sucre
REFLEXIONES
La funcionalidad es slo 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 caractersticas especficas 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.
Universidad Politcnica del Oeste Mariscal Sucre
Por lo general estn 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.
Universidad Politcnica del Oeste Mariscal Sucre
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 solucin. Reconocer la importancia del Modelado de Negocios y de la Ingeniera de Requerimientos en el proceso de desarrollo de software de calidad.
Universidad Politcnica 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 Espaola
Totalidad de las caractersticas de un producto o servicio que le confieren su aptitud para satisfacer unas necesidades expresadas o implcitas.
NORMA UNE 66-001-92 Traduccin de ISO 8402 [AENOR, 1992]
Universidad Politcnica del Oeste Mariscal Sucre
ORGENES DE LA CALIDAD
Calidad Programada
Calidad Realizada
Calidad Necesaria
Universidad Politcnica del Oeste Mariscal Sucre
CALIDAD DE SOFTWARE
Los requisitos [requerimientos] especificados. Las necesidades o expectativas del cliente o usuario.
(IEEE Std. 610.1990) [IEEE, 1993] (Cursivas nuestras)
Concordancia del software producido con los requisitos funcionales y de rendimiento explcitamente establecidos, con los estndares de desarrollo documentados y con las caractersticas implcitas que se espera de todo software desarrollado profesionalmente.
[Pressman, 1998]
Universidad Politcnica del Oeste Mariscal Sucre
DESCRIPCIN Un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas. Las funciones son aquellas que satisfacen lo indicado o implica necesidades.
Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de prestacin bajo condiciones establecidas durante un perodo de tiempo establecido.
FIABILIDAD
Madurez Recuperabilidad Tolerancia a fallos Un conjuntos de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios.
USABILIDAD
Universidad Politcnica del Oeste Mariscal Sucre
DESCRIPCIN Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas.
Comportamiento en el tiempo Comportamiento de recursos Conjunto de atributos relacionados con la facilidad de extender, modificar o corregir errores en un sistema software.
MANTENIBILIDAD
PORTABILIDAD
Conjunto de atributos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra.
Universidad Politcnica 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 Nosotros nos comprometemos a mejorar las metodologas o procesos retrasan y un 26% son totalmente exitosos. Cuando un proyecto de desarrollo, o crear nuevas y concientizarnos en su utilizacin fracasa, rara vez es debido a fallas tcnicas, la principal causa de fallos adecuada. y fracasos es la falta de aplicacin de una buena metodologa o proceso de desarrollo.
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Serie de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar en una especificacin.
(Abbott, 1986 )
Los que debe exhibir, cumplir o satisfacer un Propiedad requerimientos EXPRESAN lo que una aplicacin osistema sistema debe hacer para satisfacer las necesidades de desarrollado o adaptado para resolver un problema particular (Sawyer y Kotonya, 2001) sus clientes o usuarios. No intentab expresar cmo lograr estas funciones Aspecto de un sistema o una descripcin de aquello que el sistema es capaz de hacer a fin de cumplir su propsito
(Pfleeger, 1998)
Universidad Politcnica del Oeste Mariscal Sucre
CONTEXTO DE SISTEMA
El trmino sistema se refiere a: Un sistema de software
- Software de sistema -- Ejemplo: Sistemas operativos, compilador, interpretes, DBMS, entre otros.
-
- Software de desarrollo
-
- Aplicacin de software
-
Un sistema de hardware-software
-
Un sistema de negocios
Se refiere al dominio de aplicacin donde un sistema de software o H/S opera. Ejemplos: -- El sistema contable de una empresa
-
- El vehculo donde opera el GPS. -- El proceso industrial controlado por un controlador automtico
-
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
CASO DE ESTUDIO
Un sistema de comercio electrnico para monedas antiguas.
RAFMA, C.A. es una empresa especializada en la compra y venta de monedas antiguas de todo el mundo, con ms de 10 aos en el mercado. Durante su existencia, RAFMA ha conformado una de las ms completas colecciones de monedas antiguas a nivel mundial. Para operar RAFMA enva catlogos impresos de su coleccin a clientes selectos en todo el mundo, por los cuales deben cancelar $10. Los pedidos se hacan por correo electrnico 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 electrnico, para lo cual se contrat el desarrollo de la aplicacin web: oldcurrency.com
Universidad Politcnica del Oeste Mariscal Sucre
CASO DE ESTUDIO
Un sistema de comercio electrnico para monedas antiguas (oldcurrency.com).
Oldcurrency.com es una aplicacin que permite la comercializacin de monedas antiguas de y desde cualquier parte del mundo. La aplicacin debe permitir:
Algunos requerimientos
Hojear el catlogo de monedas antiguas disponible. Buscar una moneda de acuerdo a criterios especficos. Visualizar una moneda especfica. Comprar una moneda. Recibir informacin sobre la moneda de preferencia de los usuarios.
Universidad Politcnica del Oeste Mariscal Sucre
Requerimientos funcionales: Funciones a realizar por el software. Requerimientos no funcionales: Requerimientos depermiten Los estndares y las normas de desarrollo seguridad, rendimiento, interfaz,que se consiga una alta calidad tcnica. las opciones de solucionar el etc. Describen restricciones que limitan problema. Restricciones cuantitativas o precisin. Pseudorequerimientos: Impuestos por el cliente que restringen la implementacin del sistema
Implcitos: Los requerimientos implcitos no aparecen en la ERS, pero si no se cumplen con ellos la calidad del software queda en entredicho.
Universidad Politcnica del Oeste Mariscal Sucre
Requerimiento
Funcional
No Funcional
De Negocios
Del Usuario
Del Sistema
De Comportamiento
Restriccin
Atributo de Calidad
De Interfaz
Regla de Negocio
Universidad Politcnica del Oeste Mariscal Sucre
Requerimientos de Usuarios
Ejemplos:
La empresa RAFMA, C.A. quiere abrir su mercado a cualquier usuario interesado en la adquisicin de monedas antiguas. La aplicacin oldcurrency.com deber contribuir a abrir el mercado e incrementar el volumen de ventas anuales de monedas antiguas.
Universidad Politcnica del Oeste Mariscal Sucre
Requerimientos 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 aplicacin. Asumen que la el software es parte de un sistema mayor.
Ejemplos:
La aplicacin oldcurrency.com deber enviar un mensaje electrnico cada vez que RAFMA, C.A. disponga de una moneda antigua de su inters.
Ejemplos:
El sistema oldcurrency.com, deber permitirle al cliente efectuar el pago de su pedido en lnea, usando cualquier tarjeta de crdito. El sistema deber permitirle al usuario visualizar la moneda o monedas seleccionadas por el usuario de los contenidos en el catlogo de monedas.
Universidad Politcnica del Oeste Mariscal Sucre
Atributos de Calidad
Expresan las limitaciones que se le imponen al desarrollo del sistema. Describen aspectos tales como:
Plataforma de desarrollo y operacin. Uso de estndares, prcticas, mtodos de desarrollo. Tiempo mximo de desarrollo. Costo mximo de desarrollo.
El rendimiento que la aplicacin debe tener. La confiabilidad que debe poseer. La seguridad que debe proveer. La utilidad que debe garantizar.
Ejemplos:
oldcurrency.com, deber tener una confiabilidad mayor a 95%. oldcurrency.com deber ser fcil de usar..
Ejemplos:
oldcurrency.com deber ser una aplicacin web que debe ser desarrollado con las siguientes herramientas: Plataforma LAMP: Linux, Apache, MySql y PHP. Tiempo mximo de desarrollo 6 meses. Costo mximo de desarrollo 50.000 Bs.
Universidad Politcnica del Oeste Mariscal Sucre
De Interfaz
Expresan todas las regulaciones que la aplicacin deber acatar, entre otras:
Regulaciones gubernamentales (Leyes, decretos, providencias, etc.) Regulaciones de la empresa (Polticas, normas, procedimientos, estrategias, etc.) Regulaciones propias de la aplicacin (Estndares, metodologa que debe seguirse, algoritmos o clases que deben usarse).
Expresan las caractersticas de la interaccin del usuario con el sistema. Se dividen en:
Requerimientos de interfaz grfica (GUI). Describen las propiedades generales de la interfaz grfica que permitir la interaccin entre el usuario y el sistema. Requerimientos de interfaces con otros sistemas. Describen con qu o cmo la aplicacin interactuar con otras aplicaciones de software o sistemas de hardware.
Ejemplos:
oldcurrency.com deber desarrollarse usando la metodologa RUP. Un cliente puede descargar gratuitamente las actualizaciones de un catlogo adquirido por el, durante los dos primeros meses a partir de la publicacin de la actualizacin.
Ejemplos:
oldcurrency.com deber ser implementada usando una interfaz web. Oldcurrency.com, deber interactuar con el sistema de pagos online paypal.
Universidad Politcnica del Oeste Mariscal Sucre
Requerimientos No Funcionales
Establecen:
Los objetivos de negocio respecto al sistema. Los servicios que el sistema debe proporcionarle al sistema.
Determinan la funcionalidad del sistema. Determinan lo que el sistema deber hacer, es decir:
Su comportamiento. Su interaccin con los usuarios y su dominio de aplicacin (negocio) Sus respuestas a eventos.
No estn relacionados con la funcionalidad o comportamiento del sistema. Restringen el diseo del sistema (la solucin) 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.
Universidad Politcnica del Oeste Mariscal Sucre
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 interpretacin. debiendo poder
expresarse de una manera sencilla, clara y sin ambiguedades usando: - Lenguaje natural (espaol). - Lenguajes grficos (UML) - Lenguajes formales (Notacin Z).
Relevantes. Importancia para el sistema software a implementar. Traceables. Cada accin de diseo debe corresponderse con algn requerimiento del
cliente (resuelve un problema de este).
Universidad Politcnica del Oeste Mariscal Sucre
Correctos. Cada requerimiento establecido debe representar algo requerido por el usuario
para el sistema que se construye y ser validado por este.
Trminos conflictivos: Si dos trminos usan en contextos diferentes para la misma se cosa. Caractersticas 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.
Universidad Politcnica del Oeste Mariscal Sucre
EJEMPLOS DE REQUERIMIENTOS
1. Hasta 15 objetos se dibujarn dentro de la misma ventana. Si excede el nmero se utilizar una ventana diferente. 2. El sistema tendr una interfaz de usuario sencilla de utilizar. 3. Los usuarios deben escribir su contrasea 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.
Universidad Politcnica del Oeste Mariscal Sucre
$1 durante la fase de diseo. $2 durante la fase del diseo detallado. $3 durante la codificacin. $5 durante la prueba de unidades. $20 durante la validacin.
Universidad Politcnica 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 informacin. 2. El usuario no tiene tiempo para participar en el proyecto. - Evita participar en el proyecto.
- No est consciente de la importancia de su participacin. - No ve el sistema como algo que le pertenece. 3. Problemas de Comunicacin. - El cliente o el usuario no entiende el lenguaje informtico de los analistas. - Los analista no entienden el lenguaje del dominio de la aplicacin.
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
- Modelar el negocio antes de identificar y especificar requerimientos. 3. Utilizar un proceso de desarrollo bien definido y probado..
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
INGENIERIA DE REQUERIMIENTOS
INGENIERA DE SOFTWARE
Ingeniera de Requerimientos (IR) Est asociada al problema de los requerimientos y al Espacio de la Solucin.
MN
IR
Universidad Politcnica del Oeste Mariscal Sucre
Los requerimientos de una aplicacin dependen de los procesos de negocio que la aplicacin soporta (cmo y porqu lo hace).
la - Si los procesos de negocio no se conocen, la identificacin de necesidades y especificacin de requerimientos no tienen fundamentacin alguna.
Una buena prctica de la IR es modelar los procesos de negocio antes de definir sus requisitos. - Se puede hacer mediante la elaboracin de un pequeo modelo.
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Modelo de
Negocios
El Problema
Sub-modelos
Objetivos
Procesos de Negocio
Objetos de Negocio
Actores
Reglas de Negocio
Eventos
Requerimientos Funcionales
Requerimientos No Funcionales
Universidad Politcnica del Oeste Mariscal Sucre
En la fase de Ingeniera de Requerimientos, el Modelo de Negocios es usado para: - Entender el proceso de negocio actual y establecer sus problemas de informacin. - Descubrir las necesidades que los usuarios tienen. - Se analiza cada proceso para determinar que informacin requiere. - Facilitar la definicin y especificacin de requerimientos funcionales. que se - Los diagramas de actividades permiten identificar aquellas acciones desean automatizar.
Universidad Politcnica del Oeste Mariscal Sucre
La IR se encarga de establecer:
Principios Modelos Mtodos Mejores prcticas Tcnicas y
Universidad Politcnica del Oeste Mariscal Sucre
- Transformar la definicin de necesidades en una descripcin completa y precisa de requerimientos denominada: Especificacin de Requerimientos de Software (ERS). - Lograr un entendimiento comn, entre usuarios y desarrolladores, de los
requerimientos que debe satisfacer el sistema.
Universidad Politcnica del Oeste Mariscal Sucre
tiene
tres
elementos
El Producto: Qu se hace?
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Documento de Definicin 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 (espaol)
Documento de Especificacin de Requerimientos (DDR) Describe detalladamente los requerimientos contenidos en el DDR. Est orientado a los desarrolladores. Tiene un carcter tcnico. Los requerimientos se describen en un lenguaje o notacin tcnica. - Ejemplo: UML, SADT, ER
Universidad Politcnica del Oeste Mariscal Sucre
Existen varios estndares y modelos (plantillas o patrones) que ayudan a elaborar el DR. El estndar IEEE 830-1993
Propuesto por el Institute of Electrical and Electronics Engineers (IEEE) Agrupa los documentos DDR y DER en un solo documento. Es tambin un estndar ANSI
Universidad Politcnica del Oeste Mariscal Sucre
III.
Requerimientos especficos
1. Requerimientos de interfaz 2. Clases/Objetos 3. Requisitos de desempeo 4. Restricciones de diseo 5. Atributos de calidad del sistema 6. Otros requisitos
II.
Descripcin general
1. Perspectivas del producto - Interfaces del sistema - Interfaces del usuario - Interfaces de H/S - Interfaces de comunicacin - Restricciones de memoria - Operaciones - Requisitos de adaptacin del sitio.
IV. V.
Apndices Indice
Universidad Politcnica del Oeste Mariscal Sucre
Identificador del Tipo de Requisito: Caso de Uso: Requisito: 45 Funcional 4.2.1 Descripcin : Calcular el promedio diario, mensual y anual ingresos por concepto de venta de monedas antguas de cada una de las casa sucursales de RAFMA en los cinco continentes. Justificacin del requisito Es necesario elaborar los reportes de ingresos diarios, mensuales y anuales de venta de monedas antguas de cada sucursal. Fuente (que interesado lo propone) Unidad en la que se origina: Pedro Prez Departamento de Ventas Criterios de Validacin Los valores obtenidos se compararan con los obtenidos en aos pasados para determinar si hay inconsistencias. Grado de satisfaccin del usuario: Grado de insatisfaccin del interesado: 3 5 Dependencias (qu requisitos dependen Conflictos (qu requisitos son de este): incompatibles con este) 35, 56 Documentos de Soporte: Historico de cambios: Manual de Ventas 15/07/2010 Proyecto: Analista: Rafael Matos oldcurrency.com
Plantilla Volere
Universidad Politcnica del Oeste Mariscal Sucre
ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (1) La Ingeniera de Requerimientos consta de cinco grandes procesos:
Capturan, organizan, filtran y documentan los requisitos Obtencin de Requisitos Anlisis de Requisitos Especificacin de Requisitos
Procesos Tcnicos
Validacin de Requisitos
Procesos de Gestin
Gestin de Requisitos Controlan y apoyan a los procesos tcnicos
Universidad Politcnica del Oeste Mariscal Sucre
Denominada tambin Captura de Requerimientos Consiste en la bsqueda y recoleccin de requerimientos Sus actividades principales son:
Establecimiento de objetivos y descripcin del problema.
Identificacin de actores o interesados (stakeholders). Entidades externas que interactan con el sistema
Adquisicin de conocimientos sobre el dominio de la aplicacin. Organizacin del conocimiento Recoleccin de los requerimientos que tienen los interesados, es decir, Identificacin de escenarios. Descripcin concreta, enfocada e informal de una sola caracterstica del sistema desde el punto de vista de un solo actor.
Universidad Politcnica del Oeste Mariscal Sucre
ACTORES 1. Dueos del Sistema. Para cualquier sistema de informacin grande o pequeo habr 1 o mas dueos del sistema, los dueos del sistema tienden a estar interesados en: cunto costara el sistema?, cul ser el costo/beneficio?, cundo recuperaran la inversin y cmo la recuperaran?, etc. Este grupo es quien paga por el sistema. 2. Supervisores del contrato. Sugieren hitos de control y cronogramas que disciplinan el desarrollo del sistema. 3. Clientes y usuarios. Deben comprender y trasmitir adecuadamente los requerimientos, para del sistema. Existen internos y externos. 4. Los Gerentes de Negocios, para calibrar el impacto de construir y utilizar el sistema.
Universidad Politcnica del Oeste Mariscal Sucre
ACTORES 4. Los Diseadores. Usarn los requerimientos como base del desarrollo. 5. Los verificadores. Encargados de las sesiones de prueba destinadas a asegurar Un agente de cambio se puede definir como que el sistema cumple los requerimientos.
alguien que sirve de catalizador para el cambio, cambio coopera con los 6. Analistasdesarrolla un plan para especialista yque estudia los problemas y de Sistemas. Es un el dems una facilitar el cambio. necesidades de paraorganizacin para determinar como las personas, datos,
Universidad Politcnica del Oeste Mariscal Sucre
2.
MTODOS Y TCNICAS
a. b. c. d. e. f. Cuestionarios Entrevistas Talleres Prototipos JAD FPA
Universidad Politcnica del Oeste Mariscal Sucre
Documentacin a analizar:
Sobre las prcticas existentes de los usuarios. Sobre procedimientos de soporte. Sobre componentes tcnicos. Sobre el modelo lgico Sobre los modelos de procesos y datos Sobre requisitos existente
Universidad Politcnica del Oeste Mariscal Sucre
Personas. Identificar personas con puntos de vista precisos para representar el conjunto de los requerimientos:
Es 1. Direccincontar con ms de una persona por cada punto de vista. importante General
2. 3. 4. 5. 6. 7. Usuarios finales y direccin Clientes Proveedores El equipo operativo El equipo de mantenimiento Asesora jurdica u otros expertos.
Universidad Politcnica del Oeste Mariscal Sucre
Consiste en analizar los requerimientos recolectados durante el proceso de Obtencin con el fin de:
Determinar y resolver posibles conflictos entre requisitos. Refinar los requisitos obtenidos, establecer prioridades. Establecer acuerdos entre los usuarios y desarrolladores sobre los requerimientos que se pueden implementar.
Verificar necesidad, consistencia, completitud y factibilidad. Discutir, priorizar y acordar requisitos. Elaborar los modelos funcional, estructural y dinmico de la aplicacin.
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Consiste en la documentacin de los requerimientos. Est relacionado con la estructura, calidad y verificabilidad del Documento de Requisitos (El producto) Premisa:
La documentacin de requerimientos es la presentacin fundamental para el manejo exitoso de estos [Kotonya y Sommerville, 2000]
Actividades.
Seleccin del estndar de documentacin Documentacin de los requerimientos del cliente. Documentacin de los requerimientos del desarrollador
Universidad Politcnica del Oeste Mariscal Sucre
Modelo de Calidad del Software (Marco ISO 9126) Lenguajes de Modelado Grfico Lenguaje Orientado a Objetos (UML)
Lenguajes Estructurados: DFD, ER. Lenguajes Dinmicos: Redes de Petri, Diagramas de estado
Universidad Politcnica del Oeste Mariscal Sucre
Consiste en examinar los productos elaborados durante la Ingeniera de Requerimientos para determinar si son descripciones vlidas 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 dinmico
Universidad Politcnica del Oeste Mariscal Sucre
Consistentes No hay conflicto entre los requerimientos Cumplen con los estndares establecidos Precisos No hay requerimientos ambiguos Libres de errores
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
El manejo de las relaciones entre requerimientos El manejo de las dependencias entre el documento de requerimientos y otros documentos producidos en el desarrollo del sistema
Seguimiento o trazabilidad de requerimientos
Universidad Politcnica del Oeste Mariscal Sucre
Universidad Politcnica del Oeste Mariscal Sucre
Quines participan en el proceso de Ingeniera de Requerimientos? En la elaboracin del Documento de Requerimientos participan un conjunto de interesados o actores. Para garantizar el xito del proceso IR, el conjunto de actores debe estar debidamente organizado y estructurado. A este conjunto organizado de actores se le conoce como Equipo de Requerimientos
Universidad Politcnica del Oeste Mariscal Sucre
Responsabilidades y Funciones del Equipo de Requerimientos Seleccionar el modelo de procesos apropiados para ejecutar el proceso de IR. Adaptar el modelo de proceso de la IR a las caractersticas del proyecto y la empresa. Planificar el proceso de requerimientos. Elaborar el Documento de Requerimientos siguiendo el proceso. Mantener actualizado el Documento de Requerimientos. Hacerle seguimiento a los requerimientos (mantener la trazabilidad) Proporcionar soporte tcnico al equipo de desarrollo del sistema en relacin a los requermientos.