Curso 2009/2010
INGENIERÍA DE REQUISITOS
Primer tema • Tema 1. Introducción a la Ingeniería de Requisitos 1.1 Ingeniería del software: una revisión 1.2 Ingeniería de Requisitos e Ingeniería del Software 1.3 Importancia de la Ingeniería de Requisitos en la práctica 1.4 Factores de calidad del software 1.5 Estrategias más importantes de desarrollo de software 1.6 Familias de métodos 1.7 Resumen de fases genéricas en Ingeniería del Software e Ingeniería de Requisitos
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
len jes gua
mé tod os
herramientas
Ingeniería del Software, Sistemas de Información
modelos téc
ni ca
s
conceptos
Tema 1. Introducción a la Ingeniería de Requisitos
1—1
INGENIERÍA DE REQUISITOS
Curso 2009/2010
1.1 Ingeniería del software: una revisión •"La utilización de una aproximación sistemática, disciplinada y cuantificable, al desarrollo, operación y mantenimiento de software; es decir la aplicación de la ingeniería al software" •“El estudio de aproximaciones para conseguir ese fin” Glosario de términos estándar de Ingeniería del Software del IEEE (IEEE 90) (actualización y ampliación del estándar de 1.983) Software: "programas de computador, procedimientos, y, posiblemente, la documentación asociada y los datos pertenecientes a las operaciones de un sistema de computación".
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ingeniería del Software, otras definiciones •“La Ingeniería del Software supone la aplicación del conocimiento científico al diseño y construcción de programas de computadora y la documentación asociada requerida para su desarrollo, operación y mantenimiento”
Barry Boehm, “Software Engineering”, IEEE Transactions on Computers, Vol. C-25, n.12, December 76.
Tema 1. Introducción a la Ingeniería de Requisitos
1—2
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Ingeniería del Software según el SEI (Carnegie-Mellon, USA) Estructura “bi-dimensional”, considerando las visiones siguientes de la IS (Ford 91): •Visión Proceso •Visión Producto
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Visión Proceso Actividades
Desarrollo Control Gestión Operación Método Abstracciones Evaluación s Comunicación Representaciones Herramientas
I.R. en el desarrollo
Tema 1. Introducción a la Ingeniería de Requisitos
Aspectos
1—3
INGENIERÍA DE REQUISITOS
Curso 2009/2010
Dimensión “Actividad” (Proceso) •
•
•
•
Desarrollo: Actividades que crean o producen los “artefactos” de un sistema software. Incluyen Análisis de Requisitos, Especificación, Diseño, Implementación y Pruebas. Se aconseja diferenciar los aspectos software de los aspectos de sistemas y se recomienda incluir ambos en el programa Control:Actividades que moderan, restringen y dirigen el desarrollo. Incluyen evolución del software (control versiones,cambios, gestión de configuraciones) y calidad del software (aseguramiento, control y prueba, V&V) Gestión: Actividades que implican a los ejecutivos, administrativos y supervisores del desarrollo, incluidas las actividades técnicas de soporte a su trabajo. Incluyen Planificación de proyectos, estimación de costes, asignación de recursos (económicos, personal), constitución de equipos, asuntos legales y de contratación, etc. Operaciones: Actividades relacionadas con el uso del software en la organización. Incluye formación, planificación de la puesta en marcha, puesta en marcha, transición del viejo al nuevo sistema, operación del software y gestión de la retirada del software.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Dimensión “Aspecto” (Proceso) •
• •
• •
•
Abstracciones: Principios fundamentales (ocultamiento de información, principios de diseño, …); modelos proceso de desarrollo estrategia en cascada, prototipado, etc.; modelos de computación secuencial y concurrente: máquinas de estado finito (FST: “Finite State Machine”:), redes de Petri (RdP); modelo de estimación de costes: COCOMO Representación:Notaciones: tablas decisión, DFD, PERT; lenguajes (ADA) Métodos: Métodos formales (pruebas de corrección para verificación, especificaciones ejecutables), métodos intuitivos (AE, AOO, DOO), prácticas comunes de implementación (programación estructurada) Herramientas: Herramientas integradas o de software individual (email, procesadores de textos, CASE, compiladores, etc...) Evaluación: Métricas, análisis y evaluación tanto de los productos software como del proceso software y del impacto en las organizaciones. Todo ello con el fin de mejorar futuros desarrollos. Comunicación: oral y escrita, documentación, formación.
Tema 1. Introducción a la Ingeniería de Requisitos
1—4
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Visión Producto Dos dimensiones: •clase de sistema software •requisitos del sistema
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Dimensión Clase de sistema software (Producto) Características específicas de un software, como puede ser el construido con programación concurrente, para la que existen diferentes lenguajes, notaciones de diseño y especificación, etc. Diferentes criterios de clasificación, los grupos resultantes no tienen porqué ser disjuntos. Por ejemplo, atendiendo al dominio de aplicación: sistemas de comunicación, sistemas operativos, bases de datos, sistemas de aviónica, etc.; atendiendo al tipo de relación del sistema con el entorno: batch, reactivos, interactivos, tiempo real y embebido.
Tema 1. Introducción a la Ingeniería de Requisitos
1—5
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Dimensión requisitos del sistema (Producto) Propiedades que debería tener el sistema que se va a construir (lo ideal sería que el software pudiera satisfacer todas al cien por cien). Estos requisitos suelen restringirse a los aspectos funcionales, pero hay muchos más, no funcionales, cuya consecución depende de muchas de las actividades realizadas a lo largo del proceso software. Entre ellos podemos citar : accesibilidad, adaptabilidad, disponibilidad, compatibilidad, corrección, eficiencia, tolerancia a fallos, integridad, interoperabilidad, mantenibilidad, rendimiento, protección, fiabilidad (garantía de funcionamiento), reutilización, robustez, seguridad, posibilidades de prueba, usabilidad, etc
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
2 visiones, 4 dimensiones (SEI) • Visión Proceso: – Actividad – Aspecto
• Visión Producto: – Clase de sistema software – Requisitos del sistema
ejemplo: “Métodos para especificación de sistemas de tiempo real tolerantes a fallos” actividad: Desarrollo; aspecto: Métodos (ambos de la visión proceso) con la clase de sistemas en tiempo real y el requisito de tolerancia a fallos (ambos de la visión producto).
Tema 1. Introducción a la Ingeniería de Requisitos
1—6
Curso 2009/2010
INGENIERÍA DE REQUISITOS
1.2 Ingeniería de Requisitos e Ingeniería del Software La Ingeniería de Requisitos comprende las actividades de desarrollo de software (y SI) relacionados con la gestión y definición de necesidades, restricciones y atributos de calidad para sistemas nuevos o actuales. Ingeniería del Software
Bases de datos
Ingeniería de Requisitos
Ingeniería del conocimiento
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Análisis de requisitos • “El proceso de estudiar las necesidades de los usuarios para conseguir una definición de requisitos de software, hardware o de sistemas” • “El proceso de estudiar y refinar requisitos de software, hardware o de sistemas” Glosario de términos estándar de Ingeniería del Software del IEEE (IEEE90)
Tema 1. Introducción a la Ingeniería de Requisitos
1—7
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Requisito • “Una condición o capacidad necesitada por un usuario para resolver un problema o alcanzar un objetivo” • “Una condición o capacidad que debe ser cumplida, o poseída, por un sistema o componente de sistema, para satisfacer un contrato, estándar, especificación u otros documentos impuestos formalmente” • “Una representación documentada de una condición o capacidad relativa a los puntos anteriores” Glosario de términos estándar de Ingeniería del Software del IEEE (IEEE90)
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
1.3 Importancia de la Ingeniería de Requisitos en la práctica
Tema 1. Introducción a la Ingeniería de Requisitos
1—8
INGENIERÍA DE REQUISITOS
Curso 2009/2010
1.3 Importancia de la Ingeniería de Requisitos en la práctica • A pesar de los importantes avances en TIC, muchos
proyectos de software no dan los resultados esperados, se retrasan enormemente, desbordan sus presupuestos iniciales, o simplemente, finalizan plagados de errores. •Basado en la experiencia y casos concretos identificados por prestigiosos autores:
Glass, R. L. (1998). Software Runaways: Monumental Disasters, Prentice Hall. Glass, R. L. (2002). Software Engineering: Facts and Fallacies, AddisonWesley. Smith, J. M. (2001). Troubled IT Projects prevention and turnaround. London, IEE.
•En muchos casos, la causa identificada es una gestión inapropiada de la especificación de los requisitos
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Requisitos, factor crítico de éxito Glass, R. L. (2002). Software Engineering: Facts and Fallacies, identifica 55 “hechos”, entre ellos: •H23. Una de las causas más comunes de proyectos descontrolados es la inestabilidad de los requisitos. El origen de esta inestabilidad se debe, en la mayoría de las ocasiones, a que el cliente, o los usuarios, no tienen claro realmente qué es lo que quieren y cuál es exactamente el problema que quieren resolver. De los 55 hechos, Glass presenta dos como las causas más comunes para dar lugar a proyectos descontrolados: una es éste hecho 23, la otra es el identificado como hecho 8: realizar una inadecuada estimación del proyecto en tiempos y costes. •H24. Los errores relacionados con los requisitos son los más caros de corregir durante la construcción del software. Ésta es una afirmación que nos encontramos de forma recurrente en la literatura y como resultado de estudios empíricos sobre proyectos software (véase por ejemplo (Pressman 2000) o (Boehm y Basili 2001).
Tema 1. Introducción a la Ingeniería de Requisitos
1—9
INGENIERÍA DE REQUISITOS
Curso 2009/2010
Requisitos, factor crítico de éxito Glass, R. L. (2002) •H25. El problema más difícil de corregir, relacionado con los requisitos, es que no sean descubiertos a tiempo requisitos que son relevantes para el proyecto. El origen se debe a una mala gestión en la identificación de stakeholders o en el proceso de búsqueda y recogida de requisitos H26. Al pasar de los requisitos del problema a los requisitos del diseño, se produce una explosión de “requisitos derivados” (los requisitos que surgen para satisfacer una determinada solución de diseño) causada por la complejidad del proceso de la solución. A veces la lista de estos nuevos requisitos derivados puede llegar a ser 50 veces más grande que la de los requisitos originales. La derivación se puede producir no sólo pensando en requisitos de diseño, sino simplemente en el refinamiento sucesivo de requisitos originales en otros más detallados.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Requisitos, factor crítico de éxito Otros estudios generales, basados en evidencia empírica Blackburn, J.D. et al. (Blackburn, Scudder et al. 1996) analizaron diversos estudios, y comparados con los suyos propios, implicando a más de 600 compañías de software, distribuidas entre Estados Unidos, Europa y Japón. Entre sus conclusiones: “...con respecto al tiempo utilizado en las diversas etapas del desarrollo de software, la única etapa con una correlación positiva es la del tiempo empleado en la determinación de los requisitos de los clientes: las empresas más productivas dedicaban significativamente más tiempo a estas tareas “...el tiempo y el esfuerzo dedicado al prototipado y a otras técnicas para refinar los requisitos de los clientes son amortizadas rápidamente en un ciclo de desarrollo más corto.” Gran parte del trabajo que hay que deshacer y rehacer en el desarrollo se debe a cambios en las especificaciones (muchas veces producidos por errores o malas interpretaciones de los requisitos)
Tema 1. Introducción a la Ingeniería de Requisitos
1—10
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Requisitos, factor crítico de éxito
Andrew Martin (Martin 2003) analiza la configuración de proyectos en TI en 10 organizaciones, desde un punto de vista gerencial, identificando de nuevo un papel preponderante para la gestión de los requisitos del proyecto entre un total de seis aspectos clave: – Políticas estratégicas en TI, – Gestión de Riesgos, – Gestión de Requisitos – Consideraciones Prácticas, – Explotación dirigida de la experiencia acumulada y – Adopción dirigida de nuevas tecnologías.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Algunos resultados •“...Bell Labs e IBM determinaron que el 80% de todos los defectos del software ocurren en la fase de requisitos. Testing Techniques Newsletter (ttnsoft.com)
•“...La consultora Standish Group informó que las compañías y agencias del gobierno de los EEUU gastarían 81 billones de dólares por proyectos software fallidos (cancelados antes de llegar a su término, o bien entregados, pero nunca usados) en 1.995. Esto suponía el 31% del total de proyectos.” Causas: Poco soporte de la dirección, requisitos mal definidos, pobre planificación Computer, August 1995 (Industry Trends Section); y July 1998 http://www.standishgroup.com/chaos.html
Tema 1. Introducción a la Ingeniería de Requisitos
1—11
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Algunos resultados 2004
29%
18%
53%
http://www.lessons-from-history.com
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Algunos resultados • Casi el 50% el número de proyectos de desarrollo de software que entregaban un producto que no era utilizado nunca por los clientes, y muchos de estos proyectos no son utilizados porque no satisfacen los requisitos de los clientes (Bell 2000)
•De 1027 proyectos analizados, solo el 12,7% se consideraron éxitos (Taylor 2001): – La deficiente atención a la gestión de requisitos, y otros aspectos relacionados con estos, considerados clave (Taylor, A. 2001, IT Projects, sink or swim, BCS review, http://www.bcs.org/review/2001/articles/itservices/projects.htm)
Tema 1. Introducción a la Ingeniería de Requisitos
1—12
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Algunos resultados •Capers Jones y Bill Curtis, varias fuentes (Arias 2003, ESI): – “El 25% de todos los proyectos software son cancelados. – Las compañías están entregando productos a sus clientes que conservan al menos un 15% de defectos. – Muchas compañías están gastando entre 30%-44% de su tiempo y dinero en rehacer software que ya estaba construido. – Las empresas cumplen con sus plazos (en proyectos software) sólo en el 50% de las ocasiones”.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ejemplos de fracasos • 2 Billones de dólares perdidos al no poder poner en marcha el aeropuerto de Denver (USA) por culpa del software de control del sistema de traslado de equipajes (fecha prevista apertura 1-noviembre-93; abrió el 28-febrero-95, retraso de 16 meses). Computer, Febrero, 1995; (Glass 98)
Tema 1. Introducción a la Ingeniería de Requisitos
1—13
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Ejemplos de fracasos •
Un sensor mal programado por Francia, destruyó el supercohete europeo Ariane 5 (El País, 23 de junio de 1996, nª 33-1996)
•
Error ocurrido en la conversión de datos de coma flotante, 64 bits, a valor entero con signo, de 16 bits. El valor real a ser convertido tenía un valor mayor de lo que podía representarse con el entero de 16 bits
•
Ese valor demasiado grande ocurrió como resultado de mantener un requisito del software del Ariane 4, no necesaria para el Ariane 5, relacionado con la velocidad horizontal y ángulo de ataque detectado por un sensor de vuelo
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ejemplos de fracasos Diez minutos antes de su aterrizaje previsto en Marte, se perdió el contacto con la nave Mars Polar Lander. Un error de software hizo creer a uno de los brazos de la sonda que ya había tocado suelo, cuando aún se encontraba 40m de altura (3 de diciembre 1999).
Tema 1. Introducción a la Ingeniería de Requisitos
1—14
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Ejemplos de fracasos •
Q
El 11 de diciembre de 2000, un helicóptero MV-22 Osprey del ejército de EEUU se estrelló cerca de Tucson. Murieron 4 soldados. Las investigaciones posteriores revelaron que hubo un error informático en el sistema de alarmas de fallos hidráulicos. No se activó la alarma que debía advertir de un incidente en este sistema, y el piloto no obtuvo información fiable para volar En 1992, dos fallos informáticos provocaron en dos ocasiones el bloqueo de los sistemas de gestión de emergencias médicas en Londres. Entre otras consecuencias, se produjo una pérdida del control sobre la red de ambulancias, realizado de forma automática, lo que derivó en retrasos en los servicios de hasta 3 horas. Se estima que unas 20 personas pudieron morir por ese motivo.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ejemplos de fracasos • 50 casos reales más, descritos en: – http://www.lessons-from-history.com – Última actualización: Junio 2007
Tema 1. Introducción a la Ingeniería de Requisitos
1—15
Curso 2009/2010
INGENIERÍA DE REQUISITOS
EFECTOS ACUMULATIVOS DE LOS ERRORES EN CADA FASE DEL DESARROLLO (Davis 93, p. 27) problema real
especificación correcta
especificación errónea
diseño correcto
diseño erróneo
programas correctos
errores de programación
funciones correctas
errores corregibles
diseño
implementación
especificación de requisitos
diseño basado en especificaciones erróneas
programas basados en programas basados en errores especificaciónes erróneas de diseño
pruebas errores difíciles de corregir
errores ocultos
productos software imperfectos
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
1.4 Factores de calidad del software • • • • •
CORRECCIÓN (FIABILIDAD, EFICACIA) ROBUSTEZ EXTENSIBILIDAD REUTILIZACIÓN EFICIENCIA
• MODULARIDAD • CONTINUIDAD (sensibilidad a los cambios, durante el mantenimiento)
Tema 1. Introducción a la Ingeniería de Requisitos
1—16
Curso 2009/2010
INGENIERÍA DE REQUISITOS
1.5 Estrategias más importantes de desarrollo de software • • • • •
CICLO DE DESARROLLO REUTILIZACIÓN PROTOTIPADO RÁPIDO DIRIGIDO POR MODELOS (MDD) Otras: – Paradigma de programación automática – Ensamblaje de componentes – Ciclos de vida OO – ...
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ciclo de Vida y Ciclo de Desarrollo Ciclo de vida ≠ Ciclo de desarrollo Desde el análisis hasta la entrega al usuario Toda la vida del sistema: desde la concepción hasta el fin de uso
Tema 1. Introducción a la Ingeniería de Requisitos
1—17
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Procesos del Ciclo de Vida del Software • Necesario conseguir un marco común para “hablar el mismo lenguaje” en el desarrollo y gestión de software. • Marco común ⇒ Estándares ciclo de vida: – IEEE 1074-1991 - IEEE Standard for Developing Software Life Cycle Processes – ISO/IEC 12207:1995 (E) Information technology – Software life cycle processes
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
¿Porqué usar estándares en Ingeniería del Software? – IEEE – Institute of Electrical and Electronics Engineers. – ISO – International Organization for Standardization. – IEC – International Electrotechnical Commission.
• Objetivo: definir los procesos de desarrollo y mantenimiento del software, y de gestión del mismo, de forma genérica y abstracta.
Tema 1. Introducción a la Ingeniería de Requisitos
1—18
Curso 2009/2010
INGENIERÍA DE REQUISITOS
Estándares y Guías • Estándar oficial: conjunto de criterios aprobados por un organismo oficial de estandarización (ISO, ANSI, IEEE, ACM,…) • Documentados y disponibles para determinar la adecuación de una acción (estándar de proceso) o de un objeto (estándar de producto) [Hilera et al. 97]
• Estándar “de facto”: idem, organismo no oficial (OMG, LaTeX, Word,…) • Guía: conjunto de criterios bien definidos y documentados que encaminan una actividad o tarea. (Es más flexible que un estándar.)
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
IEEE 1074-1991. Developing Software Life Cycle Processes Sección 2 3
Título Procesos de modelo de ciclo de vida del software Procesos de gestión del proyecto
4
Procesos pre-desarrollo
5
Procesos de desarrollo
6
Procesos post-desarrollo
7
Procesos integrales
Tema 1. Introducción a la Ingeniería de Requisitos
Procesos Modelo del Ciclo de vida del software Inicio del proyecto Monitorización y control del proyecto Gestión de la calidad del software Exploración de conceptos Asignación del sistema Requisitos Diseño Implementación Instalación Operación y soporte Mantenimiento Fin de uso Verificación y validación Gestión de la configuración del software Desarrollo de la documentación Entrenamiento
1—19
Curso 2009/2010
INGENIERÍA DE REQUISITOS
ISO/IEC 12207 Procesos del ciclo de vida PROCESOS PRINCIPALES
PROCESOS DE SOPORTE
ADQUISICIÓN
DOCUMENTACIÓN
SUMINISTRO
GESTIÓN DE CONFIGURACIÓN
EXPLOTACIÓN
ASEGURAMIENTO DE CALIDAD
DESARROLLO
MANTENIMIENTO
VERIFICACIÓN VALIDACIÓN
PROCESOS DE LA ORGANIZACIÓN GESTIÓN
INFRAESTRUCTURA
REVISIÓN CONJUNTA
MEJORA
FORMACIÓN
AUDITORÍA
PROCESO DE ADAPTACIÓN
RESOLUCIÓN DE PROBLEMAS
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Ciclo de Vida. Modelo en cascada INGENIERÍA DEL SISTEMA ANÁLISIS DISEÑO CODIFICACIÓN PRUEBA MANTENIMIENTO
Tema 1. Introducción a la Ingeniería de Requisitos
1—20
INGENIERÍA DE REQUISITOS
Curso 2009/2010
Metamodelos de proceso: SPEM • Metamodelo de proceso: formaliza los conceptos generales existentes en la definición de modelos de procesos software. Permite así, por instanciación, la definición de procesos de forma flexible. • El propósito de un modelo de proceso es documentar y comunicar un proceso y posibilitar la reutilización del mismo, y de sus conceptos.
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Metamodelos de proceso: SPEM • SPEM: Software Process Engineering Metamodel (SPEM), del OMG. Definido como un Profile (UML) • Eclipse Process Framework (EPF) es un proyecto de software libre, gestionado por la Eclipse Foundation; plugin que da soporte a SPEM (versión más reciente: SPEM 2.0)
Tema 1. Introducción a la Ingeniería de Requisitos
1—21
Curso 2009/2010
INGENIERÍA DE REQUISITOS
REUTILIZACIÓN • • • • • •
Necesario diseño previo Rigurosa descripción de módulos e interfaces Definición de interfaces con otros sistemas Requisitos de entrada/salida Librería indexada de módulos Sus mayores beneficios se consiguen en el ámbito de la OO y del desarrollo basado en componentes (CBD: Component-based Development)
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
TIPOS DE REUTILIZACIÓN • “PURA” – Inclusión de módulos ya construidos
• OPERATIVA – Inclusión y pequeñas modificaciones
• REFERENCIAL – Plantillas
Tema 1. Introducción a la Ingeniería de Requisitos
1—22
Curso 2009/2010
INGENIERÍA DE REQUISITOS
PROTOTIPADO • Construcción de “maquetas” del software y del SI • Principios de los 80 • Herramientas específicas, RAD, Lenguajes de programación y entornos convencionales • Recomendado expresamente por estándares internacionales y guías nacionales: – MÉTRICA, PGGC, ISO 9000, IEEE 830, ...
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
MDD (“Model Driven Development”)
CIM: Computing Independent Model PIM: Platform Independent Model PSM: Platform Specific Model
Tema 1. Introducción a la Ingeniería de Requisitos
1—23
Curso 2009/2010
INGENIERÍA DE REQUISITOS
MDD (“Model Driven Development”)
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
1.6 Familias de métodos • • • • • • • •
orientadas a procesos orientadas a datos orientadas a estados y transiciones diseño basado en el conocimiento orientadas a objetos basados en técnicas formales basados en técnicas MDD Métodos “ágiles” (complementan alguno de las de arriba, no son métodos completos, normalmente)
Tema 1. Introducción a la Ingeniería de Requisitos
1—24
Curso 2009/2010
INGENIERÍA DE REQUISITOS
1.7 Resumen de fases genéricas en Ing. del Software e Ingeniería de Requisitos (Pressman 06)
Ingeniería del Software:
Análisis de sistemas Planificación proyectos Análisis de requisitos
QUÉ HACER (DEFINICIÓN) CÓMO HACERLO (DESARROLLO)
GESTIÓN DE CAMBIOS (MANTENIMIENTO)
Diseño de software Codificación Pruebas del software
Corrección (errores) Adaptación (nuevo sist.inf) Mejoras
Departamento de Informática y Sistemas. Facultad de Informática. Universidad de Murcia
Resumen: Impacto de los cambios, según la fase en que se producen (Pressman 06) Coste del cambio
40-1000 x
1x
Definición, Reqs
Tema 1. Introducción a la Ingeniería de Requisitos
3-70 x
Desarrollo (incl. pruebas)
Después de la entrega
1—25