Este documento trata sobre la ingeniería de requisitos de software. Explica que la ingeniería de requisitos juega un papel crucial en todas las fases del desarrollo de software al caracterizar la aplicación en base a las necesidades de los usuarios. Identifica, analiza, especifica, valida y gestiona los requisitos funcionales y no funcionales que el software debe cumplir.
Tema 2 - T2: Métodos y actividades de la ingeniería de requisitosMagemyl Egana
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre II - Tema 2 : Métodos y actividades de IR
Tema 3- T2: La ERS - Especificación de requisitos de softwareMagemyl Egana
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 2 - Tema 2
Contenido: concepto, objetivo y característica de la ERS
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 2 - Tema 4
Contenido: definición, método, producto, pasos para hacer DAS, vista 4+1, Patrón MVC
Tema 2 - T2: Métodos y actividades de la ingeniería de requisitosMagemyl Egana
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre II - Tema 2 : Métodos y actividades de IR
Tema 3- T2: La ERS - Especificación de requisitos de softwareMagemyl Egana
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 2 - Tema 2
Contenido: concepto, objetivo y característica de la ERS
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 2 - Tema 4
Contenido: definición, método, producto, pasos para hacer DAS, vista 4+1, Patrón MVC
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
03 gestión de pruebas de software diseño de casos de pruebasAntonio Quiña
Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollado para conseguir un objetivo particular o condición de prueba. Ejemplo: verificar el cumplimiento de un requisito específico
Introduce los conceptos de requerimientos del usuario y del sistema. Asimismo describe los requerimientos funcionales y no funcionales, y explica la organización del documento de requerimientos de software. Está basado en Sommerville 7ma. Edición.
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
03 gestión de pruebas de software diseño de casos de pruebasAntonio Quiña
Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados, desarrollado para conseguir un objetivo particular o condición de prueba. Ejemplo: verificar el cumplimiento de un requisito específico
Introduce los conceptos de requerimientos del usuario y del sistema. Asimismo describe los requerimientos funcionales y no funcionales, y explica la organización del documento de requerimientos de software. Está basado en Sommerville 7ma. Edición.
Resumen del capitulo 2 del libro Guide to the Software Engineering Body of Knowledge o llamado tambien como SWEBOK, el resumen es sobre los Requerimientos del Software
La ECUN especificación de casos de uso del negocio
Unidad 1 - Semestre 1 - UNEXCA
Ingeniería del software II
Contenido: concepto, objetivo, contenido de la ECUN, ejemplo de la realización del CUN y el diagrama de activividad
Unidad 1: Modelado del negocio
Tema: Modelado de casos de uso del negocio
Semestre 1: Ingeniería del software II - UNEXCA
Contenido: ¿Para qué modelar el negocio? ¿Cuándo modelar?Modelo de negocio en el proceso iterativo, ¿Cómo modelar? , procesos de negocio, casos de uso del negocio, diagrama CUN, actores, trabajador, objetos del negocio, entidades del negocio
Tema 4: Implantación del software - Etapas según el metodo WatchMagemyl Egana
UNEXCA
Cátedra: Ingeniería del software II
Tema: Implantación de software
De acuerdo al método Watch de Jonás Montilva,( Mérida, Venezuela, 2004), la implantación corresponde a la instalación y entrega de la aplicación y es descrita en los siguientes pasos:
1) Planificación de la instalación
2) Elaboración de la documentación técnica que se le entregarán al cliente.
3) Capacitación de usuarios
4) Instalación de la Plataforma de Operación
5) Instalación de la Aplicación
6) Carga inicial de datos
7) Diseño y ejecución de pruebas de Instalación
8) Inicio de Operaciones
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Semestre 2 - Tema 1
Contenido: definición, usos, enfoque, métodos del modelado de negocio . Método BMM (Business modeling method) de Montilva y Barrios y diagramas asociados al método. Ejemplos. Diferencia entre modelado del negocio e ingeniería de requisitos,
Tema 3 T3 Ejecución del ciclo de pruebas.pdfMagemyl Egana
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 3
Contenido: términos importantes en la ejecución de las pruebas de software, casos de prueba, suite de prueba, ciclo de prueba, ambiente de prueba, probador.
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 2
Contenido: concepto, tipos, escenarios, casos de uso vs casos de prueba, atributos e importancia.
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 2 - Tema 5
Contenido: concepto, pasos del diseño según método Watch, tips para el diseño UI
Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre 3 - Tema 1
Contenido: concepto, productos, roles, consideraciones, atributos, tipos, niveles y técnicas de prueba
2. La Ingeniería de Requisitos (IR) juega un papel
crucial a lo largo de todas las fases del desarrollo
de software, considerándose como el proceso
técnico de inicio que ocurre en el espacio de la
solución del problema del usuario.
La IR se encarga de caracterizar la aplicación con
base a las necesidades y los requerimientos de los
usuarios y provee los procesos de identificación,
análisis, especificación, validación y gestión de los
requisitos que los sistemas de software o
aplicaciones deben cumplir. (Barrios y Montilva,
2006).
DEFINICIÓN
02
3. DEFINICIÓN
03
“Ayuda a los ingenieros de software a entender
mejor el problema en cuya solución trabajarán.
Incluye el conjunto de tareas que conducen a
comprender cuál será el impacto del software
sobre el negocio, qué es lo que el cliente
quiere y cómo interactuarán los usuarios
finales con el software”. (Pressman, 2006: 155)
“Proceso para desarrollar una especificación
de software. Las especificaciones pretender
comunicar las necesidades del sistema del
cliente a los desarrolladores del sistema”.
(Sommerville, 2005: 82).
4. BENEFICIOS
04
Permite gestionar las necesidades del proyecto de
forma estructurada.
Mejora la calidad del software, pues éste cumple
cabalmente con el conjuntos de requisitos descritos
y documentados (funcionalidad, usabilidad,
desempeño, entre otros).
Mejora la comunicación entre los integrantes del
equipo de trabajo de IS, representando una forma
de tener consenso entre el usuario y el equipo de
desarrollo.
Evita rechazo por parte del usuario final.
Genera insumos importantes para la fase de diseño
arquitectónico y pruebas de software.
5. MODELADO DE NEGOCIO VS
INGENIERÍA DE REQUISITOS
MODELADO DE NEGOCIO
CONTEXTO ORGANIZACIONAL
Qué y cómo hace la empresa
INGENIERÍA DE REQUISITOS
05
CONTEXTO SOFTWARE
Qué y cómo hace el software
EL PROBLEMA
Objetivos, procesos, objetos, reglas, actores, eventos
LA SOLUCIÓN
Requisitos funcionales, no funcionales y complementarios
6. ¿QUÉ ES UN
REQUERIMIENTO?
06
Originado del deseo del usuario por
resolver un problema.
Deseo que tiene el usuario sobre un
posible producto de sofware que
resuelva su problema dentro de la
empresa.
Necesidad documentada en lenguaje de
usuario.
7. ¿QUÉ ES UN
REQUISITO?
07
Originado del requerimiento del usuario,
para resolver su problema.
Condición o capacidad que debe tener un
software para cumplir el deseo del usuario.
Especificación de lo que necesita el
software para cumplir la petición de
usuario, documentado con un lenguaje
técnico dirigido a una audiencia específica.
8. ¿QUÉ ES UN REQUISITO?
•Una condición o necesidad de un usuario para
resolver un problema o alcanzar un objetivo”
(Std 610.12-1900, IEEE: 62).
08
•Una condición o capacidad que debe estar presente
en un sistema o componentes de sistema para
satisfacer un contrato, estándar, especificación u otro
documento formal” (Std 610.12-1900, IEEE: 62).
Una declaración abstracta de alto nivel de un servicio
que debe proporcionar el sistema o una restricción de
éste”(Sommerville, 2005: 108).
9. CONDICIÓN DEL REQUISITO
09
Especificado por escrito, como si fuera un contrato o un
acuerdo entre partes.
Probable y verificable; sí no se puede comprobar,
entonces ¿cómo se sabe si se cumplió con él o no?
Conciso, fácil de leer y entender, redactado de forma
simple y clara para aquellos que deseen consultar a
futuro.
Completo, que no necesite ampliar detalles en su
redacción, es decir, la información proporcionada es
suficiente para su comprensión.
Consistente, sin contradecir a otro requisito.
No ambiguo, posee una sola interpretación. El lenguaje
usado en su definición, no debe causar confusiones al
lector.
1.
2.
3.
4.
5.
6.
10. Durante la etapa de descubrimiento, análisis y
especificación de requisitos, se pueden presentar
muchos inconvenientes, los cuales son importantes
de identificar y prevenir; entre los más comunes
tenemos:
•Los requerimientos no son obvios y vienen de
muchas fuentes.
•Los requerimientos son difíciles de expresar en
palabras (el lenguaje es ambiguo).
•La cantidad de requerimientos del usuario es
difícil de manejar.
DIFICULTADES
10
11. •Cambio en los requisitos durante el ciclo de
desarrollo.
•El usuario no explica lo que realmente hace en
un determinado proceso y tiende a recordar lo
excepcional y olvidar lo rutinario e importante.
•El usuario se centra en lo que no funciona del
proceso.
•El usuario difiere del Desarrollador, pues
manejan distintos vocabularios.
•El usuario usa el mismo término pero con
distintos significado.
DIFICULTADES
11
12. TIPOS DE REQUISITOS
12
•FUNCIONALES: define “qué hace el sistema”, las
funciones que el sistema será capaz de hacer y las
transformaciones del sistema (entradas-proceso-
salidas).
•NO FUNCIONALES: define “cómo hace el
sistema”, los atributos de calidad del sistema, las
restricciones y limitaciones del sistema.
•COMPLEMENTARIOS: define aquellas
restricciones técnicas no contempladas en los
requisitos no funcionales.