SlideShare ist ein Scribd-Unternehmen logo
1 von 9
Downloaden Sie, um offline zu lesen
Profa. Yamila Gascón
1
CLASE 3
REVISIÓN DE CONCEPTOS BÁSICOS (Material Modulo Ingeniería de
Requisitos)
Tema 1 Requisitos: Conceptos, tipos y
propiedades (Fuente: Barrios, J. y Montilva, J.)
El Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) son dos sub-
disciplinas de la Ingeniería de Software (IS). El MN está relacionado con el estudio del
espacio del problema en IS e IR está asociado al problema de los requisitos y al espacio
de la solución. Cuando se aplican al desarrollo de software como procesos, el MN
precede a la IR.
1) ¿Qué es un requisito?
Perspectiva del usuario
– Un requisito es una condición o capacidad de la aplicación (o sistema de software)
que necesita un usuario para resolver un problema o alcanzar un objetivo.
• Perspectiva del desarrollador:
–Es una condición o capacidad que debe ser satisfecha o poseída por la aplicación, a
fin de satisfacer un contrato, estándar, especificación u otro documento
formalmente impuesto.
• En ambos casos, es una representación documentada de una condición o capacidad
que debe mostrar la aplicación en desarrollo.
2) ¿Qué es un requisito del software?
Es una condición o capacidad que expresa lo que una aplicación debe hacer para
satisfacer necesidades de información de su dominio (sistema de hardware/software;
negocio).
Los requisitos van a definir lo que la aplicación debe hacer, las interacciones usuarios-
aplicación y aplicación-aplicación, las restricciones bajo las cuales la aplicación debe
operar, los atributos de calidad que la aplicación debe satisfacer.
3) ¿Cuál es la clasificación de los requisitos de software?
Wiegers, 2003
Profa. Yamila Gascón
2
Los requisitos del software funcionales establecen los objetivos del negocio con respecto
a la aplicación, los servicios que la aplicación debe proporcionarle al negocio, determinan
la funcionalidad de la aplicación y qué funciones debe ejecutar la aplicación.
Los requisitos funcionales pueden ser:
a) Del negocio
Se expresan desde la perspectiva de la empresa:
• Describen porque la empresa o el cliente desea desarrollar la aplicación
• Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso de la
aplicación
b) Usuarios
–Se expresan desde la perspectiva del usuario:
• Describen las necesidades que los usuarios tienen y las tareas que los usuarios
realizarán con la aplicación
• Expresan lo que el usuario será capaz de hacer con la aplicación
–Se modelan mediante casos de uso
–Ejemplos:
• Hojear la mapoteca digital
• Visualizar un mapa
• Comprar un mapa
c) Del sistema
–Están asociados a productos que tienen componentes de hardware y software
–Asumen que la aplicación es parte de un sistema mayor, p.ej.:
• Videojuegos, equipos de audio, etc.
• Sistemas de información gerencial
• Sistemas de control (Ej. Sensores/actuadores)
–Ejemplos de requisitos del sistema:
• El sistema de control deberá disparar una alarma cada vez que el sensor detecte una
presión fuera del rango permisible
• La interfaz del celular debe bloquearse cada vez que el usuario presione
simultáneamente el botón “Llamar” y la tecla *
d) Del funcionamiento
–Se expresan desde la perspectiva del desarrollador:
• Son requisitos funcionales propiamente dichos
• Describen los servicios que la aplicación presta a todos sus usuarios directos
• Expresan que hace la aplicación bajo ciertos estímulos o eventos (comportamiento del
sistema)
–Ejemplos:
•mimapa.com deberá permitir que el cliente efectúe el pago de su pedido en línea usando
tarjetas de crédito o un sistema de pagos en línea (Ej. paypal)
• El sistema debe permitirle al usuario visualizar el mapa seleccionado por el usuario de
aquellos contenidos en el catálogo de mapas
Los requisitos de software no funcionales no están relacionados directamente con el
comportamiento de la aplicación, restringen el diseño de la aplicación (la solución),
Profa. Yamila Gascón
3
establecen las limitaciones para su desarrollo y definen la calidad que la aplicación debe
tener.
Los requisitos no funcionales pueden ser:
a) Restricciones:
–Expresan las limitaciones que se le imponen al desarrollo la aplicación
– Describen aspectos tales como:
• Plataforma de desarrollo y operación (H/S)
• Uso de estándares, prácticas, métodos de desarrollo, herramientas, etc.
• Tiempo máximo de desarrollo
• Costo máximo del proyecto
–Ejemplos:
•mimapa.com debe ser desarrollada:
–Bajo una plataforma LAMP: Linux, Apache, MySQLy PHP
–En un tiempo no mayor a seis meses
–Con costo no superior a los Bs.F 300.000
b) Atributos de calidad
–Son las cualidades o propiedades de calidad que la aplicación debe satisfacer, por
ejemplo:
• El rendimiento que la aplicación debe mostrar
• La confiabilidad que debe poseer
• La seguridad que debe proveer
• La utilidad que debe garantizar
–La calidad de una aplicación se mide en función de sus atributos de calidad
–Para facilitar su medición durante la verificación, deben expresarse cuantitativa o
cualitativamente
• Ejemplo:
– mimapa.com debe tener una confiabilidad igual o mayor al 95%
–Los atributos cualitativos se miden usando escalas cualitativas, tales como la Escala de
LIKERT
–1: muy bajo, 2: bajo, 3: medio, 4: alto, 5: muy alto
• Ejemplo:
–mimapa.com debe ser fácil de usar:
»Debe medir un mínimo de 4 puntos en una escala de 5 puntos
c) Requisitos de interfaz
–Expresan las características de la interacción usuario-sistema o sistema-sistema
–Se dividen en:
• Requisitos de interfaz gráfica (GUI):
–Describen las propiedades generales del interfaz gráfica que permitirá la interacción
entre el usuario y la aplicación
–Ej.: La interfaz de la aplicación mimapa.com debe ser implementada usando tecnología
web
• Requisitos de interfaces con otros sistemas:
–Describen con qué o cómo la aplicación interactuará con otras aplicaciones de software
o sistemas de hardware
–Ej.: mimapa.comdeberá interactuar con el sistema de pagos en línea paypal
d) Reglas del negocio:
Profa. Yamila Gascón
4
–Expresan regulaciones que la aplicación debe acatar, p.ej.:
• Regulaciones gubernamentales: Leyes, decretos, providencias, etc.
• Regulaciones de la empresa: Políticas, normas, procedimientos, estrategias, etc.
• Regulaciones propias de la aplicación:
–Estándares y mejores prácticas de desarrollo que deben seguirse
–Algoritmos que deben usarse, etc.
–Ejemplos:
•mimapa.com debe elaborarse siguiendo el método de WATCH adoptado por la
empresa VECTOR C.A.
• Un cliente puede descargar gratuitamente las actualizaciones de un mapa adquirido
por el/ella durante los 12 meses siguientes a su compra
4) ¿Cuáles son los tipos de requisitos no funcionales?
a) Funcionabilidad: Los atributos de calidad asociados a la funcionabilidad, son el grupo
de atributos que permiten calificar si una aplicación maneja adecuadamente las funciones
para las cuales fue diseñada, entre ellas encontramos:
– Adecuación: Capacidad de la aplicación para realizar funciones apropiadas a las tareas
o procesos del negocio que ejecutan los usuarios
–Interoperabilidad: Habilidad de la aplicación para interactuar con otros sistemas o
aplicaciones
–Seguridad: Habilidad de la aplicación para prevenir el acceso no autorizado (accidental
o premeditado) a sus programas y datos
–Conformidad: Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas
b) Confiabilidad: Los atributos de calidad asociados a la confiabilidad, miden la
capacidad de la aplicación para mantener un nivel de rendimiento aceptable bajo
condiciones normales y en un tiempo establecido, entre ellas se encuentran:
– Nivel de Madurez: Mide la frecuencia de fallas ocasionada por errores en el software
–Tolerancia a fallas: Habilidad de la aplicación para mantener un nivel específico de
funcionamiento en caso de fallas
Adecuación
Interoperabilidad
Seguridad
Conformidad
Nivel de MadurezTolerancia a fallos Facilidad de recuperación
Comprensibilidad
Facilidad de aprendizaje
Operatividad
Uso de recursos
Rendimiento
Capacidad de análisis
Facilidad de prueba
Facilidad de modificación
Facilidad de instalación
Adaptabilidad
Coexistencia
Profa. Yamila Gascón
5
–Facilidad de Recuperación: Habilidad de la aplicación para restablecer su nivel de
operación y recuperar sus datos ante una falla
c) Utilidad: Los atributos de calidad asociados a la utilidad, permiten evaluar el esfuerzo
que los usuarios invierten en utilizar el sistema, entre ellos se encuentran:
– Comprensibilidad: Capacidad que tiene la aplicación para que sus usuarios reconozcan
la estructura lógica de la aplicación y los conceptos relativos a ella
–Facilidad de Aprendizaje: Capacidad que tiene la aplicación para que sus usuarios
aprendan a usarlo
–Operatividad: Capacidad de la aplicación para que sus usuarios la operen y controlen
d) Eficiencia: Los atributos de calidad asociados a la eficiencia, evalúan la relación entre
el nivel de funcionamiento de la aplicación y la cantidad de recursos utilizados, entre
éstos se encuentran:
–Uso de recursos: Mide la cantidad de recursos usados y la duración de su uso durante la
ejecución de sus funciones
–Rendimiento: Especifican qué tan bien o tan rápido debe la aplicación ejecutar una
función dada en términos de: Velocidad (tiempo promedio de acceso a datos), Volumen
de transacciones por minuto, Capacidad (carga de uso concurrente) y Tiempo (demanda
de tiempo real)
e) Mantenibilidad: Los atributos de calidad asociados a la mantenibilidad, permiten
medir el esfuerzo requerido para mantener la aplicación, bien sea debido a fallas o a
mejoras, entre éstos se encuentran:
–Facilidad de Modificación: Capacidad que tiene la aplicación para que sus
mantenedores puedan modificar aspectos o funciones y adaptar la aplicación a un
ambiente diferente
–Capacidad de análisis: Capacidad de la aplicación para diagnosticar deficiencias o
causas de fallas o identificar partes que han de ser modificadas
–Facilidad de prueba: Capacidad de la aplicación para permitir ser validada, una vez
modificada
f) Portabilidad: Los atributos de calidad asociados a la portabilidad, miden la habilidad
de la aplicación para ser transferida de un ambiente (plataforma de operación) a otro,
entre éstos se encuentran:
– Facilidad de Instalación: Habilidad de la aplicación para instalarse en su ambiente de
operación
–Adaptabilidad: Capacidad de la aplicación para ser adaptada a diferentes ambientes de
operación sin que se requiera modificarla más allá de lo requerido
–Coexistencia: Capacidad de la aplicación para coexistir con otras aplicaciones
compartiendo recursos comunes
5) ¿Cuáles son los niveles de requisitos?
Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que
ellos tratan (adaptado de [Wiegers, 2003])
Profa. Yamila Gascón
6
6) ¿Cuáles son las propiedades de los requisitos?
La calidad de los requisitos se mide por sus propiedades:
–Cada requisito debe expresarse de una manera sencilla, clara y sin ambigüedades,
usando:
• Lenguaje natural (Español),
• Lenguajes gráficos (Ej. UML) o
• Lenguajes formales (Ej. Notación Z)
–Preferiblemente, debe expresarse de manera cuantitativa
• Uso de métricas que faciliten la verificación
–Debe identificarse de manera única e inequívoca
• Uso de un sistema de numeración para facilitar su búsqueda y manejo
–Debe ser correcto
• Debe estar validado por el cliente
–Los requisitos deben ser consistentes entre sí
• No debe haber conflictos o incompatibilidad entre requisitos
–Deben ser completos
• Deben describir toda la funcionalidad que la aplicación deberá implementar
– Cada requisito debe ser factible (realista o alcanzable)
– Debe describir algo que el cliente o usuario necesita
• Resuelve algún problema del cliente
–Debe ser verificable
• Deben medibles y sin ambigüedad
–Se le puede hacer un seguimiento a través de todo el desarrollo del sistema
7) ¿Cuáles son los problemas que presentan los requisitos?
• Requisitos incompletos (13.1%)
• Falta de participación del usuario (12.4%)
• Falta de recursos (10.6%)
Profa. Yamila Gascón
7
• Expectativas poco realistas (9.9%)
• Falta de apoyo gerencial (9.3%)
• Cambios en los requisitos y las especificaciones (8.7%)
• Falta de planificación (8.1%)
• El sistema dejó de ser necesario (7.5%)
a) Cuando los requisitos son mal definidos, no reflejan las necesidades reales de
los actores del proyecto, son inconsistentes, incompletos, no son factibles, y el
costo de cambiar los requisitos crece a medida que avanza el proyecto.
b) En el caso de que el usuario o cliente no siempre sabe lo que quiere del
sistema, se observa al inicio del proyecto, que el mismo no sabe que esperar del
sistema y los requisitos tienden a surgir en la medida que el usuario se familiariza
con: las tecnología TIC y el sistema de información.
c) Cuando el usuario no tiene tiempo para participar en el proyecto, bien porque
evita participar en el proyecto, no está consciente de la importancia de su
participación ó no ve al sistema como algo que le pertenece.
d) Cuando existen problemas de comunicación, el cliente o usuario no entiende el
lenguaje informático de los analistas y los analistas no entienden el lenguaje del
dominio de la aplicación.
e) En el caso de existir múltiples interpretaciones de los requisitos, el analista
entiende y especifica de manera diferente los requisitos del cliente y el diseñador
interpreta de otra manera los requisitos especificados por el analista.
8) ¿Cuáles son las soluciones a los problemas presentados por los requisitos?
Aplicar la IR, la cual es una sub - disciplina de la Ingeniería del Software que se encarga
de estudiar los problemas asociados a los requisitos y proponer soluciones a estos
problemas. La IR establece métodos, modelos, técnicas, herramientas, prácticas, entre
otros para resolver los problemas de los requisitos.
9) ¿Cómo resolver los problemas de los requisitos?
a) Entender la naturaleza del software: La naturaleza del software promueve cambios
frecuentes en los requisitos.
b) Entender el espacio del problema antes de analizar el espacio de la solución:
Modelar el negocio antes de identificar y especificar requisitos.
c) Utilizar un proceso de Ingeniería de Requisitos bien definido y probado: Este
proceso debe describir como identificar, analizar, documentar, verificar y gestionar
requisitos. Debe ser parte del proceso de desarrollo de software.
d) Utilizar prácticas reconocidas (mejores prácticas), p.ej.:
• Incorporar al usuario en el desarrollo de la aplicación (participación activa)
• Modelar los requisitos usando notaciones gráficas estandarizadas
• Gestionar los requisitos
e) Emplear personal especializado que entienda los problemas de los requisitos:
Tales como Analistas de Negocios y Analistas de Requisitos.
10) Espacio del problema vs. Espacio de la solución
Profa. Yamila Gascón
8
En la ingeniería del software existen dos espacios, el problema y la solución, el MN se
encarga del espacio del problema – SN, (Las necesidades ocurren en el espacio del
problema), y la IR se encarga del espacio de la solución - aplicación (Los requisitos
tienen lugar en el espacio de la solución).
11) Soluciones a los problemas de los requisitos
El Modelo de las 6P contribuye, también, a resolver el problema de los requisitos. Este
modelo identifica factores críticos de éxito del desarrollo de software
12) Mejores prácticas de Ingeniería de Requisitos
La Ingeniería de Requisitos (IR) propone un conjunto de mejores prácticas que han
probado ser efectivas -Adaptado de Wiegers (2003)-
a) Prácticas asociadas al conocimiento de la IR
–Capacitar a los analistas en los temas técnicos de la IR
–Educar a los Representantes de Usuarios y Gerentes en la problemática y soluciones de
los requisitos. Concientizar sobre la necesidad de una IR
–Capacitar a los desarrolladores en el dominio de la aplicación (sistema de negocios)
–Crear un glosario de términos del sistema de negocios
b) Prácticas asociadas a la Gestión de Requisitos
–Definir un proceso para controlar los cambios de los requisitos
–Establecer un Comité encargado del control de cambios
–Llevar a cabo el análisis del impacto que cada cambio en los requisitos tiene sobre el
proyecto
–Establecer una línea base de requisitos y llevar control de las versiones
–Mantener históricos de cambios en los requisitos
–Hacerle seguimiento a los requisitos. Llevar las matrices de trazabilidad
–Medir la variabilidad de los requisitos
–Usar herramientas para gestionar requisitos
c) Prácticas asociadas a la Gestión del Proyecto
–Seleccionar un ciclo de vida o método de desarrollo apropiado
–Definir claramente el proceso de Ingeniería de Requisitos
Profa. Yamila Gascón
9
–Basar los planes en los requisitos. Planes iterativos
–Renegociar los acuerdos de requisitos
–Manejar los riesgos de los requisitos
–Aprender de proyectos pasados (lecciones aprendidas)
d) Prácticas asociadas al Descubrimiento de Requisitos
–Definir la visión y el alcance del producto
–Identificar los tipos de usuarios
–Identificar casos de uso
–Identificar los eventos y respuestas de la aplicación
–Observar a los usuarios realizando sus actividades
–Reutilizar requisitos de otros proyectos similares
e) Prácticas asociadas al Análisis de Requisitos
–Establecer el contexto de la aplicación. Definir las relaciones entre la aplicación y su
dominio o sistema de negocios
–Crear prototipos
–Analizar la factibilidad de los requisitos
–Establecer las prioridades de los requisitos
–Modelar los requisitos. Crear modelos funcionales, estructural y dinámicos
–Crear un diccionario de datos. Definir los elementos contenidos en los modelos
–Asignar requisitos a los subsistemas de la aplicación. Relacionar los requisitos con la
arquitectura de la aplicación
f) Prácticas asociadas a la Especificación de Requisitos
–Adoptar una plantilla para elaborar el Documento de Requisitos. Usar preferiblemente
los estándares y adaptarlo a las necesidades de su organización
–Identificar las fuentes de los requisitos. ¿Quién propuso este requisito?
–Identificar cada requisito de manera única
–Registrar las reglas del negocio
–Especificar los atributos de calidad. Usar modelos de calidad para seleccionar los
requisitos apropiados a la aplicación. Especificar las métricas para medir los atributos
g) Prácticas asociadas a la Validación de Requisitos
–Inspeccionar el Documento de Requisitos (DR). Realizar la Revisión Técnica del DR
– Probar los requisitos. Diseñar las pruebas funcionales basadas en los requisitos
–Definir los criterios de aceptación. ¿Qué criterios usará el cliente o usuarios para aceptar
la aplicación?

Weitere ähnliche Inhalte

Was ist angesagt?

Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitosinmacu_
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientosguest409adc
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
tipos de requisitos
  tipos de requisitos   tipos de requisitos
tipos de requisitos Juan Henao
 
Análisis de Requerimientos
Análisis de RequerimientosAnálisis de Requerimientos
Análisis de RequerimientosUTPL UTPL
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSLuis Anibal
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimientoturlahackers
 
Requerimientos
RequerimientosRequerimientos
Requerimientoskaresha3
 
Mv unidad 2 t1
Mv unidad 2 t1Mv unidad 2 t1
Mv unidad 2 t1Norerod
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidadgcaicedo
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del softwareuniv of pamplona
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientosGustavo Araque
 
Analisis De Requerimientos Erick Rojas Figueroa
Analisis De Requerimientos   Erick Rojas FigueroaAnalisis De Requerimientos   Erick Rojas Figueroa
Analisis De Requerimientos Erick Rojas Figueroaedays
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitosZuleima
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosmezcalote
 
Principios de Ing. De Requerimientos
Principios de Ing. De RequerimientosPrincipios de Ing. De Requerimientos
Principios de Ing. De RequerimientosRoxanaPerez54
 

Was ist angesagt? (20)

Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
 
Unidad I Requerimientos
Unidad I RequerimientosUnidad I Requerimientos
Unidad I Requerimientos
 
Requerimientos del software
Requerimientos del software Requerimientos del software
Requerimientos del software
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
tipos de requisitos
  tipos de requisitos   tipos de requisitos
tipos de requisitos
 
Requerimientos del Software
Requerimientos del SoftwareRequerimientos del Software
Requerimientos del Software
 
Análisis de Requerimientos
Análisis de RequerimientosAnálisis de Requerimientos
Análisis de Requerimientos
 
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOSINGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
INGENIERÍA DE REQUISITOS E INGENIERÍA DE REQUERIMIENTOS
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
 
Requerimientos
RequerimientosRequerimientos
Requerimientos
 
Mv unidad 2 t1
Mv unidad 2 t1Mv unidad 2 t1
Mv unidad 2 t1
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 
Requerimientos de Usabilidad
Requerimientos de  UsabilidadRequerimientos de  Usabilidad
Requerimientos de Usabilidad
 
2. requerimientos del software
2. requerimientos del software2. requerimientos del software
2. requerimientos del software
 
Análisis de requerimientos
Análisis de requerimientosAnálisis de requerimientos
Análisis de requerimientos
 
Analisis De Requerimientos Erick Rojas Figueroa
Analisis De Requerimientos   Erick Rojas FigueroaAnalisis De Requerimientos   Erick Rojas Figueroa
Analisis De Requerimientos Erick Rojas Figueroa
 
Ingeniería de requisitos
Ingeniería de requisitosIngeniería de requisitos
Ingeniería de requisitos
 
Unidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientosUnidad 2 Ingeniería de requerimientos
Unidad 2 Ingeniería de requerimientos
 
Metricas McCall
Metricas McCallMetricas McCall
Metricas McCall
 
Principios de Ing. De Requerimientos
Principios de Ing. De RequerimientosPrincipios de Ing. De Requerimientos
Principios de Ing. De Requerimientos
 

Andere mochten auch

Unidad II - ADSI
Unidad II - ADSIUnidad II - ADSI
Unidad II - ADSIGermaina
 
Ingenieria de software buena (1)
Ingenieria de software buena (1)Ingenieria de software buena (1)
Ingenieria de software buena (1)Mario Rodriguez
 
Fases Proyectos Adsi
Fases Proyectos AdsiFases Proyectos Adsi
Fases Proyectos Adsiysik granja
 
Adsi c02-gd01 guia solucion de algoritmos
Adsi c02-gd01 guia solucion de algoritmosAdsi c02-gd01 guia solucion de algoritmos
Adsi c02-gd01 guia solucion de algoritmosbrayanfp
 

Andere mochten auch (8)

Unidad II - ADSI
Unidad II - ADSIUnidad II - ADSI
Unidad II - ADSI
 
Ingenieria de software buena (1)
Ingenieria de software buena (1)Ingenieria de software buena (1)
Ingenieria de software buena (1)
 
ADSI
ADSI ADSI
ADSI
 
Perfil del tec
Perfil del tecPerfil del tec
Perfil del tec
 
Fases Proyectos Adsi
Fases Proyectos AdsiFases Proyectos Adsi
Fases Proyectos Adsi
 
Infografia
InfografiaInfografia
Infografia
 
Adsi c02-iev1-uml(1) - diaz oscar david
Adsi c02-iev1-uml(1) - diaz oscar davidAdsi c02-iev1-uml(1) - diaz oscar david
Adsi c02-iev1-uml(1) - diaz oscar david
 
Adsi c02-gd01 guia solucion de algoritmos
Adsi c02-gd01 guia solucion de algoritmosAdsi c02-gd01 guia solucion de algoritmos
Adsi c02-gd01 guia solucion de algoritmos
 

Ähnlich wie Revisión de conceptos básicos clase IR

Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfNinoskaChuraLlojlla1
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototiposTensor
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosSergio Sanchez
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer AlasEliezer Alas
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del softwareaimeemoir
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientosTensor
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASAlcoverify
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemascardan2007i
 
Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientosXilena16
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitosSergio Ramos
 
Metricas calidad de software
Metricas calidad de softwareMetricas calidad de software
Metricas calidad de softwareCristian Proaño
 
Ing de req
Ing de reqIng de req
Ing de reqwhymber
 
Diseño de Software (Ensayo)
Diseño de Software (Ensayo)Diseño de Software (Ensayo)
Diseño de Software (Ensayo)icesarandres
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareSaraEAlcntaraR
 
Met.desarrollar aplic.
Met.desarrollar aplic.Met.desarrollar aplic.
Met.desarrollar aplic.EIYSC
 

Ähnlich wie Revisión de conceptos básicos clase IR (20)

Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdfTema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
Tema 4 Fundamentos_y_Metodos_de_Analisis_de_Requerimientos_P.pdf
 
Desarrollo de prototipos
Desarrollo de prototiposDesarrollo de prototipos
Desarrollo de prototipos
 
Taller en clases (1)
Taller en clases (1)Taller en clases (1)
Taller en clases (1)
 
Unidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De RequerimientosUnidad 1.3 Analisis De Requerimientos
Unidad 1.3 Analisis De Requerimientos
 
Presentación digital Eliezer Alas
Presentación digital Eliezer AlasPresentación digital Eliezer Alas
Presentación digital Eliezer Alas
 
Metricas tecnicas del software
Metricas tecnicas del softwareMetricas tecnicas del software
Metricas tecnicas del software
 
Tipos de requerimeintos
Tipos de requerimeintosTipos de requerimeintos
Tipos de requerimeintos
 
Ingenieria de requerimientos
Ingenieria de requerimientosIngenieria de requerimientos
Ingenieria de requerimientos
 
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMASIMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
IMPORTANCIA DEL ANÁLISIS DE REQUERIMIENTOS PARA EL DESARROLLO DE SISTEMAS
 
Analisis y Diseño de Sistemas
Analisis y Diseño de SistemasAnalisis y Diseño de Sistemas
Analisis y Diseño de Sistemas
 
Taller ingernieria de requerimientos
Taller ingernieria de requerimientosTaller ingernieria de requerimientos
Taller ingernieria de requerimientos
 
Software
SoftwareSoftware
Software
 
Requerimientos del software
Requerimientos del softwareRequerimientos del software
Requerimientos del software
 
Ingenieria de requisitos
Ingenieria de requisitosIngenieria de requisitos
Ingenieria de requisitos
 
Clases 30 05
Clases 30 05Clases 30 05
Clases 30 05
 
Metricas calidad de software
Metricas calidad de softwareMetricas calidad de software
Metricas calidad de software
 
Ing de req
Ing de reqIng de req
Ing de req
 
Diseño de Software (Ensayo)
Diseño de Software (Ensayo)Diseño de Software (Ensayo)
Diseño de Software (Ensayo)
 
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del SoftwareTema N° 5 Ingeniería de Requisitos y los Requisitos del Software
Tema N° 5 Ingeniería de Requisitos y los Requisitos del Software
 
Met.desarrollar aplic.
Met.desarrollar aplic.Met.desarrollar aplic.
Met.desarrollar aplic.
 

Mehr von YAMILA GASCON

Emprendimiento_Motivación
Emprendimiento_MotivaciónEmprendimiento_Motivación
Emprendimiento_MotivaciónYAMILA GASCON
 
Lineamientos Ensayos
Lineamientos EnsayosLineamientos Ensayos
Lineamientos EnsayosYAMILA GASCON
 
Unidad I resolución_conflictos_final
Unidad I resolución_conflictos_finalUnidad I resolución_conflictos_final
Unidad I resolución_conflictos_finalYAMILA GASCON
 
Presentacion unidad I Yamila Gascón y Jairo Mendoza
Presentacion unidad I Yamila Gascón y Jairo MendozaPresentacion unidad I Yamila Gascón y Jairo Mendoza
Presentacion unidad I Yamila Gascón y Jairo MendozaYAMILA GASCON
 
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...YAMILA GASCON
 
Actividad 2 tesis doctoral 1
Actividad 2 tesis doctoral 1Actividad 2 tesis doctoral 1
Actividad 2 tesis doctoral 1YAMILA GASCON
 
Resolución de casos. Presentación.
Resolución de casos. Presentación.Resolución de casos. Presentación.
Resolución de casos. Presentación.YAMILA GASCON
 
Revisión de conceptos básicos Modelado de Negocios
Revisión de conceptos básicos Modelado de NegociosRevisión de conceptos básicos Modelado de Negocios
Revisión de conceptos básicos Modelado de NegociosYAMILA GASCON
 
Planificación Estrategica
Planificación EstrategicaPlanificación Estrategica
Planificación EstrategicaYAMILA GASCON
 
Del modelo del negocio al modelo de requisitos
Del modelo del negocio al modelo de requisitosDel modelo del negocio al modelo de requisitos
Del modelo del negocio al modelo de requisitosYAMILA GASCON
 

Mehr von YAMILA GASCON (15)

Emprendimiento_Motivación
Emprendimiento_MotivaciónEmprendimiento_Motivación
Emprendimiento_Motivación
 
Emprendimiento
EmprendimientoEmprendimiento
Emprendimiento
 
Lineamientos Ensayos
Lineamientos EnsayosLineamientos Ensayos
Lineamientos Ensayos
 
Unidad I resolución_conflictos_final
Unidad I resolución_conflictos_finalUnidad I resolución_conflictos_final
Unidad I resolución_conflictos_final
 
Presentacion unidad I Yamila Gascón y Jairo Mendoza
Presentacion unidad I Yamila Gascón y Jairo MendozaPresentacion unidad I Yamila Gascón y Jairo Mendoza
Presentacion unidad I Yamila Gascón y Jairo Mendoza
 
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...
H chero-herramientasyportalesdigitalesparalainvestigacincientfica-14101917122...
 
Actividad 2 tesis doctoral 1
Actividad 2 tesis doctoral 1Actividad 2 tesis doctoral 1
Actividad 2 tesis doctoral 1
 
Resolución de casos. Presentación.
Resolución de casos. Presentación.Resolución de casos. Presentación.
Resolución de casos. Presentación.
 
Resolucion de casos
Resolucion de casosResolucion de casos
Resolucion de casos
 
Norma iso 9126
Norma iso 9126Norma iso 9126
Norma iso 9126
 
Revisión de conceptos básicos Modelado de Negocios
Revisión de conceptos básicos Modelado de NegociosRevisión de conceptos básicos Modelado de Negocios
Revisión de conceptos básicos Modelado de Negocios
 
Planificación Estrategica
Planificación EstrategicaPlanificación Estrategica
Planificación Estrategica
 
Aydsi
AydsiAydsi
Aydsi
 
Del modelo del negocio al modelo de requisitos
Del modelo del negocio al modelo de requisitosDel modelo del negocio al modelo de requisitos
Del modelo del negocio al modelo de requisitos
 
Docti ej
Docti ejDocti ej
Docti ej
 

Revisión de conceptos básicos clase IR

  • 1. Profa. Yamila Gascón 1 CLASE 3 REVISIÓN DE CONCEPTOS BÁSICOS (Material Modulo Ingeniería de Requisitos) Tema 1 Requisitos: Conceptos, tipos y propiedades (Fuente: Barrios, J. y Montilva, J.) El Modelado de Negocios (MN) y la Ingeniería de Requisitos (IR) son dos sub- disciplinas de la Ingeniería de Software (IS). El MN está relacionado con el estudio del espacio del problema en IS e IR está asociado al problema de los requisitos y al espacio de la solución. Cuando se aplican al desarrollo de software como procesos, el MN precede a la IR. 1) ¿Qué es un requisito? Perspectiva del usuario – Un requisito es una condición o capacidad de la aplicación (o sistema de software) que necesita un usuario para resolver un problema o alcanzar un objetivo. • Perspectiva del desarrollador: –Es una condición o capacidad que debe ser satisfecha o poseída por la aplicación, a fin de satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. • En ambos casos, es una representación documentada de una condición o capacidad que debe mostrar la aplicación en desarrollo. 2) ¿Qué es un requisito del software? Es una condición o capacidad que expresa lo que una aplicación debe hacer para satisfacer necesidades de información de su dominio (sistema de hardware/software; negocio). Los requisitos van a definir lo que la aplicación debe hacer, las interacciones usuarios- aplicación y aplicación-aplicación, las restricciones bajo las cuales la aplicación debe operar, los atributos de calidad que la aplicación debe satisfacer. 3) ¿Cuál es la clasificación de los requisitos de software? Wiegers, 2003
  • 2. Profa. Yamila Gascón 2 Los requisitos del software funcionales establecen los objetivos del negocio con respecto a la aplicación, los servicios que la aplicación debe proporcionarle al negocio, determinan la funcionalidad de la aplicación y qué funciones debe ejecutar la aplicación. Los requisitos funcionales pueden ser: a) Del negocio Se expresan desde la perspectiva de la empresa: • Describen porque la empresa o el cliente desea desarrollar la aplicación • Expresan que objetivos, metas o necesidades la empresa espera alcanzar con el uso de la aplicación b) Usuarios –Se expresan desde la perspectiva del usuario: • Describen las necesidades que los usuarios tienen y las tareas que los usuarios realizarán con la aplicación • Expresan lo que el usuario será capaz de hacer con la aplicación –Se modelan mediante casos de uso –Ejemplos: • Hojear la mapoteca digital • Visualizar un mapa • Comprar un mapa c) Del sistema –Están asociados a productos que tienen componentes de hardware y software –Asumen que la aplicación es parte de un sistema mayor, p.ej.: • Videojuegos, equipos de audio, etc. • Sistemas de información gerencial • Sistemas de control (Ej. Sensores/actuadores) –Ejemplos de requisitos del sistema: • El sistema de control deberá disparar una alarma cada vez que el sensor detecte una presión fuera del rango permisible • La interfaz del celular debe bloquearse cada vez que el usuario presione simultáneamente el botón “Llamar” y la tecla * d) Del funcionamiento –Se expresan desde la perspectiva del desarrollador: • Son requisitos funcionales propiamente dichos • Describen los servicios que la aplicación presta a todos sus usuarios directos • Expresan que hace la aplicación bajo ciertos estímulos o eventos (comportamiento del sistema) –Ejemplos: •mimapa.com deberá permitir que el cliente efectúe el pago de su pedido en línea usando tarjetas de crédito o un sistema de pagos en línea (Ej. paypal) • El sistema debe permitirle al usuario visualizar el mapa seleccionado por el usuario de aquellos contenidos en el catálogo de mapas Los requisitos de software no funcionales no están relacionados directamente con el comportamiento de la aplicación, restringen el diseño de la aplicación (la solución),
  • 3. Profa. Yamila Gascón 3 establecen las limitaciones para su desarrollo y definen la calidad que la aplicación debe tener. Los requisitos no funcionales pueden ser: a) Restricciones: –Expresan las limitaciones que se le imponen al desarrollo la aplicación – Describen aspectos tales como: • Plataforma de desarrollo y operación (H/S) • Uso de estándares, prácticas, métodos de desarrollo, herramientas, etc. • Tiempo máximo de desarrollo • Costo máximo del proyecto –Ejemplos: •mimapa.com debe ser desarrollada: –Bajo una plataforma LAMP: Linux, Apache, MySQLy PHP –En un tiempo no mayor a seis meses –Con costo no superior a los Bs.F 300.000 b) Atributos de calidad –Son las cualidades o propiedades de calidad que la aplicación debe satisfacer, por ejemplo: • El rendimiento que la aplicación debe mostrar • La confiabilidad que debe poseer • La seguridad que debe proveer • La utilidad que debe garantizar –La calidad de una aplicación se mide en función de sus atributos de calidad –Para facilitar su medición durante la verificación, deben expresarse cuantitativa o cualitativamente • Ejemplo: – mimapa.com debe tener una confiabilidad igual o mayor al 95% –Los atributos cualitativos se miden usando escalas cualitativas, tales como la Escala de LIKERT –1: muy bajo, 2: bajo, 3: medio, 4: alto, 5: muy alto • Ejemplo: –mimapa.com debe ser fácil de usar: »Debe medir un mínimo de 4 puntos en una escala de 5 puntos c) Requisitos de interfaz –Expresan las características de la interacción usuario-sistema o sistema-sistema –Se dividen en: • Requisitos de interfaz gráfica (GUI): –Describen las propiedades generales del interfaz gráfica que permitirá la interacción entre el usuario y la aplicación –Ej.: La interfaz de la aplicación mimapa.com debe ser implementada usando tecnología web • Requisitos de interfaces con otros sistemas: –Describen con qué o cómo la aplicación interactuará con otras aplicaciones de software o sistemas de hardware –Ej.: mimapa.comdeberá interactuar con el sistema de pagos en línea paypal d) Reglas del negocio:
  • 4. Profa. Yamila Gascón 4 –Expresan regulaciones que la aplicación debe acatar, p.ej.: • Regulaciones gubernamentales: Leyes, decretos, providencias, etc. • Regulaciones de la empresa: Políticas, normas, procedimientos, estrategias, etc. • Regulaciones propias de la aplicación: –Estándares y mejores prácticas de desarrollo que deben seguirse –Algoritmos que deben usarse, etc. –Ejemplos: •mimapa.com debe elaborarse siguiendo el método de WATCH adoptado por la empresa VECTOR C.A. • Un cliente puede descargar gratuitamente las actualizaciones de un mapa adquirido por el/ella durante los 12 meses siguientes a su compra 4) ¿Cuáles son los tipos de requisitos no funcionales? a) Funcionabilidad: Los atributos de calidad asociados a la funcionabilidad, son el grupo de atributos que permiten calificar si una aplicación maneja adecuadamente las funciones para las cuales fue diseñada, entre ellas encontramos: – Adecuación: Capacidad de la aplicación para realizar funciones apropiadas a las tareas o procesos del negocio que ejecutan los usuarios –Interoperabilidad: Habilidad de la aplicación para interactuar con otros sistemas o aplicaciones –Seguridad: Habilidad de la aplicación para prevenir el acceso no autorizado (accidental o premeditado) a sus programas y datos –Conformidad: Evalúa si la aplicación se adhiere a estándares y regulaciones establecidas b) Confiabilidad: Los atributos de calidad asociados a la confiabilidad, miden la capacidad de la aplicación para mantener un nivel de rendimiento aceptable bajo condiciones normales y en un tiempo establecido, entre ellas se encuentran: – Nivel de Madurez: Mide la frecuencia de fallas ocasionada por errores en el software –Tolerancia a fallas: Habilidad de la aplicación para mantener un nivel específico de funcionamiento en caso de fallas Adecuación Interoperabilidad Seguridad Conformidad Nivel de MadurezTolerancia a fallos Facilidad de recuperación Comprensibilidad Facilidad de aprendizaje Operatividad Uso de recursos Rendimiento Capacidad de análisis Facilidad de prueba Facilidad de modificación Facilidad de instalación Adaptabilidad Coexistencia
  • 5. Profa. Yamila Gascón 5 –Facilidad de Recuperación: Habilidad de la aplicación para restablecer su nivel de operación y recuperar sus datos ante una falla c) Utilidad: Los atributos de calidad asociados a la utilidad, permiten evaluar el esfuerzo que los usuarios invierten en utilizar el sistema, entre ellos se encuentran: – Comprensibilidad: Capacidad que tiene la aplicación para que sus usuarios reconozcan la estructura lógica de la aplicación y los conceptos relativos a ella –Facilidad de Aprendizaje: Capacidad que tiene la aplicación para que sus usuarios aprendan a usarlo –Operatividad: Capacidad de la aplicación para que sus usuarios la operen y controlen d) Eficiencia: Los atributos de calidad asociados a la eficiencia, evalúan la relación entre el nivel de funcionamiento de la aplicación y la cantidad de recursos utilizados, entre éstos se encuentran: –Uso de recursos: Mide la cantidad de recursos usados y la duración de su uso durante la ejecución de sus funciones –Rendimiento: Especifican qué tan bien o tan rápido debe la aplicación ejecutar una función dada en términos de: Velocidad (tiempo promedio de acceso a datos), Volumen de transacciones por minuto, Capacidad (carga de uso concurrente) y Tiempo (demanda de tiempo real) e) Mantenibilidad: Los atributos de calidad asociados a la mantenibilidad, permiten medir el esfuerzo requerido para mantener la aplicación, bien sea debido a fallas o a mejoras, entre éstos se encuentran: –Facilidad de Modificación: Capacidad que tiene la aplicación para que sus mantenedores puedan modificar aspectos o funciones y adaptar la aplicación a un ambiente diferente –Capacidad de análisis: Capacidad de la aplicación para diagnosticar deficiencias o causas de fallas o identificar partes que han de ser modificadas –Facilidad de prueba: Capacidad de la aplicación para permitir ser validada, una vez modificada f) Portabilidad: Los atributos de calidad asociados a la portabilidad, miden la habilidad de la aplicación para ser transferida de un ambiente (plataforma de operación) a otro, entre éstos se encuentran: – Facilidad de Instalación: Habilidad de la aplicación para instalarse en su ambiente de operación –Adaptabilidad: Capacidad de la aplicación para ser adaptada a diferentes ambientes de operación sin que se requiera modificarla más allá de lo requerido –Coexistencia: Capacidad de la aplicación para coexistir con otras aplicaciones compartiendo recursos comunes 5) ¿Cuáles son los niveles de requisitos? Los requisitos tienen tres niveles asociados que determinan su origen y los aspectos que ellos tratan (adaptado de [Wiegers, 2003])
  • 6. Profa. Yamila Gascón 6 6) ¿Cuáles son las propiedades de los requisitos? La calidad de los requisitos se mide por sus propiedades: –Cada requisito debe expresarse de una manera sencilla, clara y sin ambigüedades, usando: • Lenguaje natural (Español), • Lenguajes gráficos (Ej. UML) o • Lenguajes formales (Ej. Notación Z) –Preferiblemente, debe expresarse de manera cuantitativa • Uso de métricas que faciliten la verificación –Debe identificarse de manera única e inequívoca • Uso de un sistema de numeración para facilitar su búsqueda y manejo –Debe ser correcto • Debe estar validado por el cliente –Los requisitos deben ser consistentes entre sí • No debe haber conflictos o incompatibilidad entre requisitos –Deben ser completos • Deben describir toda la funcionalidad que la aplicación deberá implementar – Cada requisito debe ser factible (realista o alcanzable) – Debe describir algo que el cliente o usuario necesita • Resuelve algún problema del cliente –Debe ser verificable • Deben medibles y sin ambigüedad –Se le puede hacer un seguimiento a través de todo el desarrollo del sistema 7) ¿Cuáles son los problemas que presentan los requisitos? • Requisitos incompletos (13.1%) • Falta de participación del usuario (12.4%) • Falta de recursos (10.6%)
  • 7. Profa. Yamila Gascón 7 • Expectativas poco realistas (9.9%) • Falta de apoyo gerencial (9.3%) • Cambios en los requisitos y las especificaciones (8.7%) • Falta de planificación (8.1%) • El sistema dejó de ser necesario (7.5%) a) Cuando los requisitos son mal definidos, no reflejan las necesidades reales de los actores del proyecto, son inconsistentes, incompletos, no son factibles, y el costo de cambiar los requisitos crece a medida que avanza el proyecto. b) En el caso de que el usuario o cliente no siempre sabe lo que quiere del sistema, se observa al inicio del proyecto, que el mismo no sabe que esperar del sistema y los requisitos tienden a surgir en la medida que el usuario se familiariza con: las tecnología TIC y el sistema de información. c) Cuando el usuario no tiene tiempo para participar en el proyecto, bien porque evita participar en el proyecto, no está consciente de la importancia de su participación ó no ve al sistema como algo que le pertenece. d) Cuando existen problemas de comunicación, el cliente o usuario no entiende el lenguaje informático de los analistas y los analistas no entienden el lenguaje del dominio de la aplicación. e) En el caso de existir múltiples interpretaciones de los requisitos, el analista entiende y especifica de manera diferente los requisitos del cliente y el diseñador interpreta de otra manera los requisitos especificados por el analista. 8) ¿Cuáles son las soluciones a los problemas presentados por los requisitos? Aplicar la IR, la cual es una sub - disciplina de la Ingeniería del Software que se encarga de estudiar los problemas asociados a los requisitos y proponer soluciones a estos problemas. La IR establece métodos, modelos, técnicas, herramientas, prácticas, entre otros para resolver los problemas de los requisitos. 9) ¿Cómo resolver los problemas de los requisitos? a) Entender la naturaleza del software: La naturaleza del software promueve cambios frecuentes en los requisitos. b) Entender el espacio del problema antes de analizar el espacio de la solución: Modelar el negocio antes de identificar y especificar requisitos. c) Utilizar un proceso de Ingeniería de Requisitos bien definido y probado: Este proceso debe describir como identificar, analizar, documentar, verificar y gestionar requisitos. Debe ser parte del proceso de desarrollo de software. d) Utilizar prácticas reconocidas (mejores prácticas), p.ej.: • Incorporar al usuario en el desarrollo de la aplicación (participación activa) • Modelar los requisitos usando notaciones gráficas estandarizadas • Gestionar los requisitos e) Emplear personal especializado que entienda los problemas de los requisitos: Tales como Analistas de Negocios y Analistas de Requisitos. 10) Espacio del problema vs. Espacio de la solución
  • 8. Profa. Yamila Gascón 8 En la ingeniería del software existen dos espacios, el problema y la solución, el MN se encarga del espacio del problema – SN, (Las necesidades ocurren en el espacio del problema), y la IR se encarga del espacio de la solución - aplicación (Los requisitos tienen lugar en el espacio de la solución). 11) Soluciones a los problemas de los requisitos El Modelo de las 6P contribuye, también, a resolver el problema de los requisitos. Este modelo identifica factores críticos de éxito del desarrollo de software 12) Mejores prácticas de Ingeniería de Requisitos La Ingeniería de Requisitos (IR) propone un conjunto de mejores prácticas que han probado ser efectivas -Adaptado de Wiegers (2003)- a) Prácticas asociadas al conocimiento de la IR –Capacitar a los analistas en los temas técnicos de la IR –Educar a los Representantes de Usuarios y Gerentes en la problemática y soluciones de los requisitos. Concientizar sobre la necesidad de una IR –Capacitar a los desarrolladores en el dominio de la aplicación (sistema de negocios) –Crear un glosario de términos del sistema de negocios b) Prácticas asociadas a la Gestión de Requisitos –Definir un proceso para controlar los cambios de los requisitos –Establecer un Comité encargado del control de cambios –Llevar a cabo el análisis del impacto que cada cambio en los requisitos tiene sobre el proyecto –Establecer una línea base de requisitos y llevar control de las versiones –Mantener históricos de cambios en los requisitos –Hacerle seguimiento a los requisitos. Llevar las matrices de trazabilidad –Medir la variabilidad de los requisitos –Usar herramientas para gestionar requisitos c) Prácticas asociadas a la Gestión del Proyecto –Seleccionar un ciclo de vida o método de desarrollo apropiado –Definir claramente el proceso de Ingeniería de Requisitos
  • 9. Profa. Yamila Gascón 9 –Basar los planes en los requisitos. Planes iterativos –Renegociar los acuerdos de requisitos –Manejar los riesgos de los requisitos –Aprender de proyectos pasados (lecciones aprendidas) d) Prácticas asociadas al Descubrimiento de Requisitos –Definir la visión y el alcance del producto –Identificar los tipos de usuarios –Identificar casos de uso –Identificar los eventos y respuestas de la aplicación –Observar a los usuarios realizando sus actividades –Reutilizar requisitos de otros proyectos similares e) Prácticas asociadas al Análisis de Requisitos –Establecer el contexto de la aplicación. Definir las relaciones entre la aplicación y su dominio o sistema de negocios –Crear prototipos –Analizar la factibilidad de los requisitos –Establecer las prioridades de los requisitos –Modelar los requisitos. Crear modelos funcionales, estructural y dinámicos –Crear un diccionario de datos. Definir los elementos contenidos en los modelos –Asignar requisitos a los subsistemas de la aplicación. Relacionar los requisitos con la arquitectura de la aplicación f) Prácticas asociadas a la Especificación de Requisitos –Adoptar una plantilla para elaborar el Documento de Requisitos. Usar preferiblemente los estándares y adaptarlo a las necesidades de su organización –Identificar las fuentes de los requisitos. ¿Quién propuso este requisito? –Identificar cada requisito de manera única –Registrar las reglas del negocio –Especificar los atributos de calidad. Usar modelos de calidad para seleccionar los requisitos apropiados a la aplicación. Especificar las métricas para medir los atributos g) Prácticas asociadas a la Validación de Requisitos –Inspeccionar el Documento de Requisitos (DR). Realizar la Revisión Técnica del DR – Probar los requisitos. Diseñar las pruebas funcionales basadas en los requisitos –Definir los criterios de aceptación. ¿Qué criterios usará el cliente o usuarios para aceptar la aplicación?