Está en la página 1de 72

Universidad Politcnica del Oeste Mariscal Sucre

INGENIERIA DE SOFTWARE II
Trayecto III - Trimestre I Unidad 1

2009 Rafael Matos. 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-

Comunicacin: yrmatos@gmail.com - 0426-7054640

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ORGANIZACIN DEL CURSO

Clases terico-prcticas o consultas del Proyecto Prctico:

Seccin 7001: Lunes de 9:30 am a 11:05 am y Jueves de 7:00 am a 9:25 am


Seccin 7002: Lunes de 7:00 am a 9:25 am y Jueves de 9:30 am a 11:05 am Seccin 7024: Mircoles de 5:50 pm a 8:15 pm y Viernes de 8:20 pm a 9:55 pm

Proyecto Prctico (Tributario al Proyecto Socio-Tecnolgico) 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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

EVALUACIN DEL CURSO

1 Informe Tcnico sobre el Marco ISO-9126 (10%) (30-01-2013) Taller 1 (15%) (06-02-2013)

Evaluaciones Terica 1 (15%) (20-02-2013)


Evaluacin Terica 2 (15%). (13-03-2013) Taller 2 (15%) (10-04-2013)

Informe del Proyecto Prctico (20%) (12-04-2013)


Presentacin del Proyecto (10%) (17, 24 y 26-04-2013)

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CONTENIDO ANALTICO DEL CURSO

SABERES
Unidad 1: Requerimientos del Software o Qu son los requerimientos o Requisitos? o Necesidades, Objetivos Requerimientos y Actores Relacionados con los

ESTRATEGIAS

RECURSOS

EVALUACIN

o Importancia de la Ingeniera de Requisitos en la prctica o Levantamiento y Recoleccin de Requerimientos. o Tcnicas ms usadas: Mtodo JAD y FPA

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 Casos Prcticos Proyector Multimedia Plataforma Tecnolgica Aula de encuentros Evaluacin continua Trabajo en grupo Ejercicios individuales Participacin

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 Estndares de Documentacin. de alta calidad.
Trabajos de investigacin que fortalezcan en el participante la capacidad de interpretacin de la formacin relacionada con la investigacin en ingeniera del software.

o Tipos de requerimientos: funcionales, no-funcionales, dominio, atributos de calidad.

del

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CONTENIDO ANALTICO DEL CURSO (2)

SABERES
Unidad 3: Anlisis de Requerimientos
o Inspeccin, validacin, completitud, deteccin de conflictos inconsistencias de requerimientos. o Documentos de Requerimientos de Software: Creacin, Importancia. o Mtricas y herramientas para la ingeniera de requisitos. 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. e

ESTRATEGIAS

RECURSOS

EVALUACIN

usos e

Lecturas orientadas. El profesor asesor elaborar un cuestionario con preguntas que orienten al participante en la identificacin del conocimiento relevante que debe adquirir hacia el final de la lectura.

Exposiciones, mesas redondas y foros de discusin acerca de las consultas y lecturas recomendadas realizadas por el participante.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

REFERENCIAS BIBLIOGRFICAS Y FUENTES DOCUMENTALES

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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

INTRODUCCIN (1) 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?

Tras varios minutos de discusin. IS2:

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

INTRODUCCIN (2) 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.

Un software de calidad es aquel que posee una combinacin deseada de atributos


IEEE Std. 1061

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

INTRODUCCIN (3) Realidades sobre los Atributos de Calidad del Software

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica 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 solucin.

Reconocer la importancia del Modelado de Negocios y de la Ingeniera de Requerimientos en el proceso de desarrollo de software de calidad.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

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]

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ORGENES DE LA CALIDAD

Calidad Programada

Calidad Realizada

Calidad Necesaria

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CALIDAD DE SOFTWARE Definiciones

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. 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]

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126)

CARACTERISTICAS/ ATRIBUTOS* FUNCIONALIDAD

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.

Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas. 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

Aprendizaje
Comprensin Operatividad

* Un atributo es una entidad la cual puede ser verificada o medida en el producto software.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

FACTORES DE LA CALIDAD DE SOFTWARE (MARCO ISO 9126)

CARACTERISTICAS/ ATRIBUTOS

DESCRIPCIN Conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas.

EFICIENCIA

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

Estabilidad Facilidad de anlisis 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.

PORTABILIDAD

Capacidad de instalacin Capacidad de reemplazamiento Adaptabilidad

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ASIGNACIN NRO. 1 (Valor 10%)

1. Completar la Tabla del marco ISO-9126. 2. Determinar el grado de calidad de una aplicacin WEB, en funcin del Marco ISO-9126. Para la aplicacin seleccionada determinar: Empresa, URL, Objetivos

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CALIDAD DEL SOFWARE Reflexin

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 tcnicas, la principal causa de fallos y fracasos es la falta de aplicacin de una buena metodologa o proceso de desarrollo. Nosotros DEBEMOS comprometemos a mejorar las metodologas o procesos de desarrollo, o crear nuevas y concientizarnos en su utilizacin adecuada.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

QU SON LOS REQUERIMIENTOS? (1)

Una condicin o capacidad que debe poseer el sistema, necesaria para resolver un problema o alcanzar un objetivo
Una condicin o capacidad que debe ser satisfecha o poseida por un sistema o un componente del sistema a fin de satisfacer un contrato, estndar, especificacin 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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

QU SON LOS REQUERIMIENTOS? (2)


Serie de instrucciones abstractas de alto nivel de un servicio o de un sistema, limitado a detallar en una especificacin.
(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 descripcin de aquello que el sistema es capaz de hacer a fin de cumplir su propsito
(Pfleeger, 1998)

Los requerimientos EXPRESAN lo que una aplicacin o sistema debe hacer para satisfacer las necesidades de sus clientes o usuarios. lograr estas funciones No intentan expresar cmo

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

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
-

- Ejemplo: Herramientas CASE, conductor de pruebas, entre otros.

- Aplicacin de software
-

- Ejemplo: Aplicaciones WEB, SIG, SSD, vdeojuegos, entre otros.

Un sistema de Hardware-Software
-

- Ejemplo: Celulares, , controladores de procesos, relojes digitales, GPS, entre otros.

Un sistema de Negocios
Se refiere al dominio de aplicacin donde un sistema de software o H/S opera.
Sistema de Negocios Sistema H/S
-

Ejemplos:
- El sistema contable de una empresa

- El vehculo donde opera el GPS. -- El proceso industrial controlado por un controlador automtico

Sistema de Software

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

QU DEFINEN LOS REQUERIMIENTOS?


Los requerimientos definen: 1. Lo que el sistema debe hacer
Las funciones que debe ejecutar. Los datos que debe capturar y almacenar La informacin que debe producir

2. Las interacciones usuarios-sistema y sistema-sistema


La interfaz grfica usuario-sistema (GUI) La interfaz de la aplicacin con otros sistemas.

3. Las restricciones bajo las cuales el sistema debe operar


La plataforma de operacin del sistema. La tecnologa de informacin que debe utilizar el sistema.

4. Los atributos de calidad que el sistema debe satisfacer


Estndar ISO 9126

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CASO DE ESTUDIO (1)


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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CASO DE ESTUDIO (2)


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.

Algunos requerimientos

La aplicacin debe permitir:

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CLASIFICACIN DE LOS REQUERIMIENTOS (1)

Explcitos: Los requerimientos establecidos explcitamente se reflejan en el documento de Especificacin 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 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.

Los estndares y las normas de desarrollo permiten que se consiga una alta calidad tcnica.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CLASIFICACIN DE LOS REQUERIMIENTOS (2)


Segn Wiegers, 2003

Requerimiento

Funcional

No Funcional

De Negocios

Del Usuario

Del Sistema

De Comportamiento

Restriccin

Atributo de Calidad

De Interfaz

Regla de Negocio

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica 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 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 aplicacin. Expresan lo que el usuario ser capaz de hacer con el sistema.

Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso del sistema.

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.

Se modelan mediante casos de uso. Ejemplos:


Hojear los catlogos de monedas antiguas.
Visualizar un moneda. Comprar una moneda

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

REQUERIMIENTOS FUNCIONALES (2)

Requerimientos del Sistema

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.

Se expresan desde la perspectiva del desarrollador.


Se denominan tambin 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:
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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica 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 operacin. Uso de estndares, prcticas, mtodos de desarrollo. Tiempo mximo de desarrollo. Costo mximo de desarrollo.

Expresan las propiedades de calidad que el sistema debe satisfacer.


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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

REQUERIMIENTOS NO FUNCIONALES (2)

Reglas de Negocio

De Interfaz

Expresan todas las regulaciones que la aplicacin deber acatar, entre otras:
Regulaciones gubernamentales decretos, providencias, etc.) (Leyes,

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.

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).

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 usando una interfaz web. ser implementada

Oldcurrency.com, deber interactuar con el sistema de pagos online paypal.


2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

DIFERENCIAS ENTRE LOS TIPOS DE REQUERIMIENTOS

Requerimientos Funcionales

Requerimientos No Funcionales

Establecen:
Los objetivos de negocio respecto al sistema. Los servicios que el sistema debe proporcionarle a los usuarios.

No estn relacionados con funcionalidad o comportamiento sistema.

la del

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.

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CARACTERSTICAS 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, es decir, 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.

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

CARACTERSTICAS DE REQUERIMIENTOS DE ALTA CALIDAD (2)

Traceables. Cada accin de diseo debe corresponderse con algn requerimiento del cliente (resuelve un problema de este). Verificables. Preferiblemente deben expresarse de manera cuantitativa, usando mtricas que faciliten su verificacin. Consistentes. Ningn requerimiento puede estar en conflicto con otro. Tipos de Inconsistencia: Trminos conflictivos: Si dos trminos se usan en contextos diferentes para la misma 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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

PORQU DETERMINAR REQUERIMIENTOS?

1. El software normalmente est integrado por muchos componentes. En la mayor parte de los casos, es difcil para el ingeniero de software entender todos estos componentes al mismo tiempo.

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 diseo. $2 durante la fase del diseo detallado. $3 durante la codificacin. $5 durante la prueba de unidades. $20 durante la validacin. $100 despus que el sistema ha entrado en produccin.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

PROBLEMAS AL DETERMINAR REQUERIMIENTOS (1)


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.

2009 Rafael Matos. Universidad

Universidad Politcnica del Oeste Mariscal Sucre

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 diseador interpreta de otra manera los requisitos especificados por el analista. 5. Requerimientos mal definidos. - No reflejan las necesidades reales de los usuarios del sistema.

- Son inconsistentes.
- Son incompletos. - No son factibles.

2009 Rafael Matos. Universidad

Universidad Politcnica del Oeste Mariscal Sucre

SOLUCIN A LOS PROBLEMAS DE LOS REQUERIMIENTOS


1. Entender la naturaleza del software. - La naturaleza del software promueve cambios frecuentes en 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 prcticas reconocidas (mejores prcticas) - Incorporar al cliente en el desarrollo del sistema (activamente). - Modelar los requerimientos usando notaciones grficas estandarizadas. - Gestionar los requisitos. 5. Emplear personal especializado - Analistas de negocios. - Analistas de requerimientos.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA ESPACIO DE LA SOLUCION (1)

1. Los mtodos tradicionales de desarrollo de software importancia del problema y su anlisis, debido a que: - Se centran en la solucin y sus requisitos.

subestiman

la

- No alinea la solucin al negocio.


2. La separacin del espacio del problema y el de la solucin es crucial en toda ingeniera. 3. La ingeniera de sistemas fsicos establece una clara separacin entre ambos espacios (problema y solucin).. 4. Las necesidades ocurren en el espacio del problema. 5. Los requerimientos tienen lugar en el espacio de la solucin.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA ESPACIO DE LA SOLUCION (2)


Todo software ha de tener una alcance funcional. El diseador debe establecer los lmites del problema. MUNDO REAL Lo que est dentro de los lmites (dominio) forma parte del problema Lo que est fuera de los lmites no forma parte del problema . El dominio del problema es la parte del mundo, que para el fin del software a construir, interesa al diseador.

ES RELEVANTE DEFINIR CLARAMENTE EL DOMINIO

ESPACIO DE PROBLEMA

DOMINIO = ESPACIO DEL PROBLEMA

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

INGENIERIA DE REQUERIMIENTOS

Modelado del Negocio (MN)

Estudia el Espacio del Problema en Ingeniera de Software

INGENIERA DE SOFTWARE Est asociada al problema de los requerimientos y al Espacio de la Solucin.

Ingeniera de Requerimientos (IR)

MN

IR

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (1)


Necesidades y Requerimientos Los requerimientos funcionales de un sistema expresan necesidades de informacin: - Qu informacin requieren los usuarios para ejecutar sus procesos de negocio?.

- Qu actividades de un proceso de negocio requieren ser automatizadas?


Los requerimientos de una aplicacin dependen de los procesos de negocio que la aplicacin soporta (cmo y porqu lo hace). - Si los procesos de negocio no se conocen, la identificacin de necesidades y la 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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (2)

El Modelado de Negocios (MN) es un proceso a travs del cual se representa el dominio de una aplicacin. Es el mecanismo por el cual un negocio trata de generar ingresos y/o beneficios. Es un resumen de cmo una organizacin planifica servir a sus clientes. En aplicaciones empresariales el MN representa diferentes aspectos del dominio de la aplicacin. - El dominio es denominado SISTEMA DE NEGOCIOS. El MN identifica y representa aspectos del sistema de negocios, tales como: - Objetivos de la organizacin. - Procesos de Negocio y sus actividades. - Reglas de Negocio.

- Objetos del Negocio.


- Actores y su organizacin. El producto del MN son los MODELOS DE NEGOCIO.
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (3)


El Modelo de Negocios de una empresa, es una representacin simplificada de la lgica de negocio que describe lo que un negocio ofrece a sus clientes, cmo llega a ellos, y cmo se relaciona con ellos

Un Modelo de Negocios es un documento compuesto por un conjunto de submodelos.


- Cada sub-modelo describe uno o ms elementos organizacionales. 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 Solucin
2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DEL PROBLEMA: MODELADO DE NEGOCIOS (4)

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. Los diagramas de actividades permiten identificar aquellas acciones que se desean automatizar. Caracterizar el nuevo proceso de negocios y su flujo de trabajo.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (1)


La Ingeniera de Requerimientos (IR) es una sub-disciplina de la Ingeniera 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 - Mtodos

- Mejores prcticas
- Tcnicas y - Herramientas automatizadas que contribuyan especificacin de los requerimientos. a mejorar la definicin y

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (2)

La aplicacin de la IR al desarrollo de un sistema conduce a:


Encontrar y definir las necesidades que tienen los interesados de la aplicacin.

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (3)

La Ingeniera de Requerimientos elementos fundamentales que son:

tiene

tres

El Equipo: Quines lo hacen?

El Producto: Qu se hace?

El Proceso: Cmo hacerlo?

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (4)


El Producto

Qu produce la Ingeniera 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 electrnico que describe y comunica de manera sencilla y comprensible los requerimientos para: - Los Clientes, usuarios y gerentes.

- Desarrolladores del sistema

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: 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 Definicin de Requerimientos (DDR) - Documento de Especificacin de Requerimientos (DER)

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (6)


El Producto

Documento de Definicin de Requerimientos (DDR) Describe los requerimientos de alto nivel desde la perspectiva de los clientes y/o usuarios. Est orientado usuarios. a los clientes y/o

Documento de Especificacin de Requerimientos (DER) 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.

Los requerimientos se describen en lenguaje natural (espaol)

- Ejemplo: UML, SADT, ER

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (7)


El Producto

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 La plantilla Volere. - Permite documentar cada requerimiento mediante un formato especial.

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (8)


El Producto El estndar IEEE-830-1993 I. Introducccin 1. Propsito
2. Alcance 2. Funciones del producto 3. Caractersticas del usuario 4. Restricciones 5. Suposiciones y dependencias 6. Distribucin de requisitos

3. Definiciones, acrnimos y abreviaturas.


4. Referencias 5. Estructura del documento

III. Requerimientos especficos


1. Requerimientos de interfaz 2. Clases/Objetos

II.

Descripcin general
1. Perspectivas del producto - Interfaces del sistema - Interfaces del usuario - Interfaces de H/S - Interfaces de comunicacin

3. Requisitos de desempeo
4. Restricciones de diseo 5. Atributos de calidad del sistema 6. Otros requisitos

- Restricciones de memoria
- Operaciones - Requisitos de adaptacin del sitio.

IV. Apndices V. Indice

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (9)


El Producto Plantilla Volere
Identificador del Requisito: 45 Tipo de Requisito: Funcional Caso de Uso: 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 de este): Conflictos (qu requisitos son incompatibles con este) 35, 56 Documentos de Soporte: Historico de cambios: Manual de Ventas 15/07/2010 Proyecto: oldcurrency.com Analista: Rafael Matos

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (10)


El Proceso

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

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (11)


El Proceso de Obtencin de Requerimientos

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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (12)


El Proceso de Obtencin de Requerimientos 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.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (13)


El Proceso de Obtencin de Requerimientos

Actores 4. 5. Los Diseadores. Usarn los requerimientos como base del desarrollo. Los verificadores. Encargados de las sesiones de prueba destinadas a asegurar Un agente de cambio se puede definir como alguien que el sistema cumple los requerimientos.

que sirve de catalizador para el cambio, desarrolla un plan para el cambio y especialista que dems para 6. Analistas de Sistemas. Es un coopera con los estudia los problemas y necesidades de una organizacin para determinar como las personas, datos, facilitar el cambio
procesos y la tecnologa de la informacin pueden en conjunto mejorar un negocio. El analista desempea diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres principales roles del analista de sistemas son el de consultor, exporto en soporte tcnico y agente de cambio.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (14)


El Proceso de Obtencin de Requerimientos Administracin de la Captura de Requerimientos 1. Fuentes a. Revisin de Documentos. b. Personas con puntos de vista necesarios. 2. Mtodos y Tcnicas a. Cuestionarios b. Entrevistas c. Talleres d. Prototipos g. Observacin directa h. Reutilizacin de requisitos

i.
j.

Uso de Modelo de Negocios


Ingeniera de Reverso

e. JAD
f. FPA

k. Torbellino de ideas l. Anlisis de documentos

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (15)


El Proceso de Obtencin de Requerimientos Administracin de la Captura de Requerimientos Fuentes Revisin de Documentos Es imprescindible cuando: El sistema se instalar en infraestructuras existentes.

Suplemento de funcionalidad ya disponible.


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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (16)


El Proceso de Obtencin de Requerimientos Administracin de la Captura de Requerimientos Fuentes Personas

Identificar personas con puntos de vista precisos para representar el conjunto de los requerimientos:

ES Direccin General 1. IMPORTANTE CONTAR CON MS DE UNA PERSONA POR CADA


2. 3. 4. 5. 6. 7. Usuarios Finales y Direccin PUNTO DE VISTA Clientes Proveedores El Equipo Operativo El Equipo de Mantenimiento ConsultoraJ urdica u otros expertos.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (17)


El Proceso de Anlisis de Requerimientos

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. Las Actividades principales de esta etapa son: Refinamiento y clasificacin de requerimientos

Verificar necesidad, consistencia, completitud y factibilidad.


Negociacin de requerimientos Discutir, priorizar y acordar requisitos. Modelar requisitos Elaborar los modelos funcional, estructural y dinmico de la aplicacin. Construir un prototipo de la interfaz grfica

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (18)


El Proceso de Anlisis de Requerimientos Tcnicas Utilizadas Anlisis de los Procesos de Negocio. Anlisis Orientado a Objetos. Modelado de funciones mediante Diagramas de Casos de Uso. Modelado de Flujo de Trabajo a travs de Diagramas de Actividad Modelado de la Estructura de la Aplicacin usando Diagramas de Clase Modelado de la Dinmica de la Aplicacin mediante Diagramas de Secuencia.

Anlisis Estructurado de Sistemas.


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 Relacin (DER)

Prototipos.

Tcnicas de Negociacin.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (19)


El Proceso de Especificacin de Requerimientos

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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (20)


El Proceso de Especificacin de Requerimientos

Tcnicas Utilizadas Uso de estndares de documentacin 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 Grfico Lenguaje Orientado a Objetos (UML) Lenguajes Estructurados: DFD, ER. Lenguajes Dinmicos: Redes de Petri, Diagramas de Estado

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (21)


El Proceso de Validacin de Requerimientos

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 Prototipos Documentos de Requisitos Documento de Definicin de Requerimientos

Documento de Especificacin de Requerimientos

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (22)


El Proceso de Validacin 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 estndares establecidos Precisos No hay requerimientos ambiguos Libres de errores

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (23)


El Proceso de Validacin de Requerimientos

Actividades y Tcnicas utilizadas: Revisin Tcnica Inspeccin de modelos Inspeccin de documentos Validacin de Prototipos

Evaluacin de prototipos de interfaces grficas


Definicin de criterios de aceptacin Establecer los criterios que los usuarios emplearn para aceptar el sistema

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (24)


El Proceso de Gestin de Requerimientos

Esta relacionado con: La planificacin 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 emplearn 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 Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (25)


El Proceso de Gestin de Requerimientos

Actividades y Tcnicas utilizadas: Planificacin y Control de Proyectos

Gestin de Cambios
Gestin de Almacenamiento de Requerimientos Identificacin de Requerimientos Uso de procesadores de texto Uso de bases de datos de requerimientos Rastreo o trazabilidad de Requisitos

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: INGENIERIA DE REQUERIMIENTOS (26)


El Equipo de Requerimientos 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

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

Universidad Politcnica del Oeste Mariscal Sucre

ESPACIO DE LA SOLUCIN: 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. 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 requerimientos.

2009 Rafael Matos. Universidad Politcnica del Oeste "Mariscal Sucre"

También podría gustarte