Uso de Escenarios. en la Derivación de Software

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Uso de Escenarios. en la Derivación de Software"

Transcripción

1 Uso de Escenarios en la Derivación de Software Tesis Doctoral Graciela Dora Susana Hadad Director de tesis: Asesor Científico: Prof. Dr. Julio Cesar Sampaio do Prado Leite Pontificia Universidade Catolica do Rio de Janeiro Prof. Ing. Jorge Horacio Doorn Universidad Nacional de La Plata Facultad de Ciencias Exactas Universidad Nacional de La Plata Argentina

2 Resumen Esta tesis presenta una estrategia en la Ingeniería de Requisitos, denominada SDRES, que intenta abordar temas poco tratados en la práctica real, tales como los cambios constantes en los requisitos, defectos del software originados en los requisitos, el contexto organizacional que rodea al sistema de software y la consideración de requisitos de calidad. Esta estrategia está dirigida por modelos (Léxico Extendido del Lenguaje, Escenarios y Documento de Requisitos) y orientada al cliente, por ello utiliza sus modelos escritos en lenguaje natural como medio de comunicación y elicitación. SDRES tiene en cuenta la calidad de los modelos que produce mediante procesos de verificación y validación. Para cada actividad de la estrategia se presenta un conjunto de heurísticas y recomendaciones. Se encara el tema de evolución y versionado de los modelos, así como distintas modalidades de utilizar la estrategia según la complejidad del problema, el conocimiento sobre el mismo y otras características. Abstract The present thesis shows a Requirements Engineering strategy, called SDRES, which proposes to face topics rarely treated in real practice, such as continuous changes in requirements, software defects brought in requirements, the organisational context surrounding the software system and the quality treatment of requirements. This strategy is driven by models (Language Extended Lexicon, Scenarios and Software Requirements Specification) and oriented to the client. Therefore it uses models written in natural language as means of communication and elicitation. SDRES keeps in mind the quality of the produced models by means of verification and validation processes. For each activity of the strategy a set of heuristic and recommendations is presented. The evolution topic and model versioning is treated, as well as different modalities to use the strategy according to the complexity of the problem, the knowledge on the problem and other characteristics. «Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.» Antoine de Saint Exupery i

3 Índice Descripción Página Lista de Figuras vi Lista de Tablas viii Lista de Acrónimos Utilizados ix 1. Introducción Motivación La importancia de los requisitos Errores en el proceso de desarrollo de software La Ingeniería de Requisitos y la Ingeniería de Software Evolución de los requisitos Reflexiones Objetivos y Trabajo realizado Estructura de la tesis Ingeniería de Requisitos Consideraciones iniciales El Proceso de la Ingeniería de Requisitos Contexto del proceso de la IR Aspectos ético contractuales de la IR Características y Actividades del proceso de la IR Elicitación Modelado Análisis Gestión de Requisitos Rastreo de los Requisitos Comparación de taxonomías de actividades en la IR La Ingeniería de Requisitos en los Modelos de Proceso de Software Modelos de Proceso de Software Observaciones sobre los Modelos de Proceso de 49 Software 2.4. Métodos de la Ingeniería de Requisitos Introducción Técnicas tradicionales de Análisis de Sistemas Métodos Orientados a Objetos Comparando técnicas estructuradas vs orientadas a 55 objetos desde la IR Otros métodos en la IR La IR en el Proceso Unificado Métodos Ágiles Características generales Relación con los métodos clásicos y la IR La Programación extrema 69 ii

4 Descripción Página 2.6. Los Requisitos Requerimientos, Requisitos y Especificaciones Qué versus Cómo Propiedades y Atributos de los requisitos Taxonomía de requisitos Documento de Definición de Requisitos Uso de Glosarios en el desarrollo de software Introducción a diccionarios y glosarios Estrategias en la IR que usan glosarios Escenarios y Casos de Uso Definición de Escenario y Caso de Uso Estrategias basadas en escenarios en la IR Técnica de Inspección de Requisitos El framework: Client-Oriented Requirements Baseline SDRES, una Estrategia en la Ingeniería de Requisitos Introducción Etapas de la estrategia La evolución de los modelos Tipos de evolución en SDRES Gestión de evolución de los modelos Cómo aplicar y adaptar SDRES Ámbito de aplicación de la estrategia Versionado de los modelos Resumen Léxico Extendido del Lenguaje Introducción El modelo del LEL El proceso de creación del LEL Generalidades del proceso Actividades del proceso Otros tópicos en el proceso Observaciones La técnica del LEL frente a la práctica de glosarios Uso del LEL en otras estrategias Ficha de Información Anticipada Resumen Escenarios Introducción Escenarios Actuales y Escenarios Futuros El modelo de Escenario Observaciones Resumen Escenarios Actuales El proceso de construcción de escenarios actuales Generalidades del proceso Actividades del proceso Observaciones Inspección de escenarios 211 iii

5 Descripción Página Características de la inspección Taxonomía de Defectos El proceso de inspección Intra e Inter inspección de escenarios Administrando el Proceso de Inspección Observaciones Resumen Escenarios Futuros Introducción El proceso de construcción de escenarios futuros Características del proceso Generalidades del proceso Actividades del proceso Enfoques en el modelado de EF Observaciones Resumen Explicitar Requisitos del Software Introducción El proceso de explicitar los requisitos Gestión de requisitos Observaciones Resumen Conclusiones Corolario Consideraciones finales Futuros trabajos 278 Apéndices 280 A. Principales iniciativas en la Ingeniería de Requisitos 280 A.1. Introducción 280 A.2. Fijación de estándares para especificar requisitos 280 A.3. Estándares de calidad para procesos de software que han Incluido estándares para el proceso de IR 281 A.4. Congresos dedicados exclusivamente a esta disciplina 282 A.5. Revistas y libros dedicados exclusivamente al tema 282 A.6. Herramientas comerciales que soportan actividades de 283 la IR A.7. Comunidades informáticas 284 A.7.1. Internacionales 284 A.7.2. Nacionales 284 B. Publicaciones contenidas en la tesis 285 B.1. Publicaciones en Capítulo de Libro 285 B.2. Publicaciones Internacionales con Referato 285 B.3. Publicaciones en Anales de Congresos 285 B.4. Publicaciones Internas con referato 286 B.5. Publicaciones sin referato 286 B.6. Artículos enviados para publicación 287 B.7. Artículos en etapa final de redacción 287 C. Trabajos derivados de esta tesis 288 iv

6 Descripción Página C.1. Tesis relacionadas 288 D. Aplicaciones de la estrategia 290 D.1. Introducción 290 D.2. Ejemplo de Léxico Extendido del Lenguaje 291 D.3. Ejemplo de Escenarios Actuales 303 D.4. Ejemplo de Escenarios Futuros 318 D.5. Ejemplo de Lista de Requisitos 351 E. Modelo de Trazas 356 E.1. Introducción 356 E.2. Ejemplos 360 E.3. Codificación de Entidades EJEMPLO E.4. Tipos de Operaciones EJEMPLO E.5. Codificación de Entidades EJEMPLO E.6. Tipos de Operaciones EJEMPLO F. Aplicación de Inspecciones en Escenarios 374 F.1. Introducción 374 F.2. Intra Inspección 374 F.2.1. Guías de Instrucción Intra Inspección 374 F.2.2. Formularios de Intra Inspección 382 F3. Inter Inspección 393 F.3.1. Guías de Instrucción Inter Inspección 393 F.3.2. Formularios de Inter Inspección 403 F.4. Gestión de Inspección 416 F.4.1. Guías de Instrucción de Gestión de Inspección 416 F.4.2. Formularios de Gestión de Inspección 420 G. Relación entre Escenario y Caso de Uso 425 G.1. Relación entre los tipos de escenarios y de casos de uso 425 G.2. Relación entre los componentes de escenarios y de casos 427 de uso Referencias 430 Agradecimientos 454 v

7 Lista de Figuras Figura Nº Descripción Página 1-1 Catarata de Errores según el Modelo Mizuno Catarata de Errores extendiendo el Modelo Mizuno Evolución de los Errores + Evolución de los Requisitos Gráfico Belady-Lehman Proceso de la Ingeniería de Requisitos Evolución del UdeD frente a las Actividades de la IR Verificación y Validación Sub-actividades de la Negociación Sub-actividades de la Gestión de Requisitos Tipos de Rastreabilidad Modelos de Proceso de Software versus Necesidades de Usuarios Fases y Flujos de Trabajo de RUP Requerimientos versus Requisitos Estructura de SRS según [IEEE Std ] Taxonomía de inspecciones basadas en enfoques de lectura SDRES, una Estrategia en la IR SADT de la Estrategia Evolución por cambios genuinos en el UdeD Evolución por cambios en las expectativas de los usuarios Evolución por mejora en la comprensión de las expectativas Evolución por puesta en servicio parcial del software Evolución por puesta en servicio total del software Nexos en el CORB Registro de Trazas para Versionado Ejemplo de la vista hipertexto entre el LEL, Escenarios y SRS El Modelo del Léxico Extendido del Lenguaje Diagrama de Entidad-Relación del Modelo del LEL SADT del proceso de creación del LEL SADT de la actividad Planear en el proceso del LEL SADT de la actividad Recolectar en el proceso del LEL SADT de la actividad Clasificar en el proceso del LEL Ejemplos de jerarquías de símbolos Ejemplo de homónimos Ejemplo de homónimos con sinónimos Ficha de Información Anticipada Relación entre actividades de la IR y actividades del LEL Diagrama de Entidad-Relación del Modelo de Escenario Diagrama de Entidad-Relación Extendido del Componente Episodios Modelo de Escenario SADT del proceso de construcción de Escenarios Actuales SADT de la actividad Derivar en el proceso de EA 179 vi

8 Figura Nº Descripción Página 6-3 Ejemplo de derivación de un escenario actual Versión final de un escenario actual SADT de la actividad Organizar en el proceso de EA Ejemplo de operación Factorizar Ejemplo de operación Consolidar Ejemplos de Escenarios Integradores Ejemplos de Construcción de Secuencias SADT del proceso de Inspección de Escenarios SADT de la actividad Verificar Forma III: Control Sintáctico del Escenario Forma VI: Cumplimiento del Léxico Forma VII: Control de Ocurrencia de Actores de Escenarios Instrucciones para la Intra forma VI: Cumplimiento del Léxico Forma VI: Control de Precondiciones de Sub-Escenarios Forma VII: Control de Solapamiento de Escenarios Forma XI: Control de Cubrimiento de Impactos del LEL Instrucciones para la Intra forma VI: Control de Precondiciones de Sub-Escenarios 6-20 Forma IV: DEOs por Componente Relación entre actividades de IR y actividades de construcción de EA Ejemplo de evolución de un escenario actual a un escenario futuro Evolución proyectada de Escenarios Actuales a Futuros en el marco de los Objetivos SADT del proceso de construcción de Escenarios Futuros SADT de la actividad Organizar en el proceso de EF Selección de Enfoque para construir EF Recorrido del árbol en modalidad post-order Recorrido del árbol en modalidad pre-order Recorrido del árbol en modalidad híbrida Relación entre actividades de IR y actividades de construcción de EF SADT del proceso de explicitar Requisitos del Software Ejemplo de lista de requisitos de un escenario futuro Trazas semánticas Intra CORB y Extra CORB Relación entre actividades de IR y actividades de explicitar requisitos 274 D-1 Resultados del proceso de derivación y organización para el Sistema de Agenda de Reuniones 303 E-1 Modelo de Trazas para Versionado 358 E-2 Vista de una Traza 359 G-1 Modelo de Caso de Uso 425 G-2 Relaciones entre tipos de escenarios y tipos de casos de uso 426 vii

9 Lista de Tablas Tabla Nº Descripción Página 1-1 Costo relativo de corrección de errores Uso de técnicas en el proceso de la Ingeniería de Requisitos Técnicas V&V en la Ingeniería de Requisitos Comparativo de Actividades de la IR Foco de Valores en los Métodos Ágiles Visiones del Qué y del Cómo Ejemplificando las visiones del Qué y del Cómo Comparación de eficiencia de Lectura basada en Escenarios contra Ad Hoc y Checklist Aplicación de SDRES en los Modelos de Proceso Tipos de Nexos entre Modelos Ejemplos del género en símbolos Datos de casos de estudio utilizando el LEL Tipos de operaciones en la reorganización de escenarios Cuadro comparativo de construcción de escenarios Enfoques para construir escenarios Descripción de los formularios de inspección de Intra escenarios Descripción de los formularios de inspección de Inter escenarios Descripción de los formularios de gestión de inspecciones Datos de casos de estudio sobre Escenarios Actuales Datos de inspecciones controladas sobre Escenarios Actuales Datos de casos de estudio sobre Escenarios Futuros Tipos de requisitos extraídos de escenarios futuros Tipos de relación entre componente y requisito Datos de casos de estudio sobre Requisitos derivados de EF Énfasis de diversas estrategias en las actividades de la IR 277 D-1 Evolución de escenarios actuales para el Sistema de Agenda de Reuniones D-2 Evolución de EA a EF según enfoques para el Sistema de Agenda de Reuniones G-1 Relación entre componentes de Escenario y de Caso de Uso 428 viii

10 Lista de Acrónimos utilizados ACM Association for Computer Machinery CMM Capability Maturity Model CMMI Capability Maturity Model Integration CORB Client-Oriented Requirements Baseline COTS Commercial Off The Shelf CREWS Cooperative Requirements Engineering With Scenarios DEO Discrepancias, Errores y Omisiones DER Diagrama de Entidad-Relación DFD Diagrama de Flujo de Datos EA Escenarios Actuales EF Escenarios Futuros EG Escenarios Generales EI Escenarios Integradores ESPRIT European Strategic Program on Information Technology IEC International Electrotechnical Commission IEEE Institute for Electrical and Electronics Engineers IID Iterative and Incremental Development IR Ingeniería de Requisitos ISO International Standardisation Organisation JAD Joint Application Design LEL Language Extended Lexicon / Léxico Extendido del Lenguaje LN Lenguaje Natural MD Modelo de Diseño NATO North Atlantic Treaty Organisation OMG Object Management Group OMT Object Modeling Technique RAD Rapid Application Development RE Requirements Engineering RF Requisitos Funcionales RNF Requisitos No Funcionales RUP Rational Unified Process SADT Structured Analysis and Design Technique SDRES Scenario Driven Requirements Engineering Strategy SEI Software Engineering Institute SPICE Software Process Improvement and Capability Evaluation SRS Software Requirements Specification TSE Transactions on Software Engineering UB Universidad de Belgrano - Argentina UdeD Universo de Discurso UML Unified Modelling Language UNCPBA Universidad Nacional del Centro de la Provincia de Buenos Aires ix

11 UNLaM UTN V&V XP Universidad Nacional de La Matanza Universidad Tecnológica Nacional Verificación y Validación extreme Programming / Programación extrema x

12 Capítulo 1 Introducción «The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.» F. Brooks, "No Silver Bullet", IEEE Computer, Motivación La importancia de los requisitos La clave del éxito o fracaso de un proyecto de software depende fuertemente de resolver el problema correcto [Rumbaugh 94], es decir, encontrar el conjunto de soluciones adecuadas al problema en el universo de discurso (UdeD) 1. Para lo cual, se debe primero adquirir conocimiento sobre el UdeD, capturando las demandas, necesidades y problemas presentes en él y, luego, determinar que los requisitos especificados para el sistema de software sean los correctos. Los errores en los requisitos incrementan altamente los costos de desarrollo y mantenimiento de los sistemas de software, dado que la corrección de los mismos puede involucrar desde simples adaptaciones al código, el rediseño de algún componente o hasta reformular total o parcialmente la solución propuesta. Es sabido que los costos por corrección de errores en los requisitos se incrementan en cada fase de desarrollo del software. La incidencia del costo de corrección de requisitos erróneos ha sido ampliamente estudiada por autores como Michael Fagan [Fagan 74], Barry Boehm [Boehm 76], Bell y Thayer [Bell 76], Edmund Daly [Daly 77], Victor Basili [Basili 81] y Alan Davis [Davis 93] entre otros. Barry Boehm [Boehm 81] estudió varios proyectos de desarrollo de software de gran envergadura para determinar el costo de corrección de errores en requisitos (ver Tabla 1-1), errores que eran descubiertos tardíamente en el proceso de desarrollo. Como se puede observar en la Tabla 1-1, en el caso de un requisito erróneo que permanece sin ser detectado ni corregido hasta la etapa de operación, su reparación puede costar hasta 100 veces más que si fuera 1 Universo de discurso [Leite 94]: todo el contexto en el cual el software se desarrolla e incluye todas las fuentes de información y toda la gente relacionada con el software. Es la realidad acotada por el conjunto de objetivos establecidos por quienes demandan una solución de software. Las personas involucradas en el proceso de desarrollo son principalmente: usuarios, clientes, ingenieros de software, expertos del dominio, las cuales son denominadas en la literatura con la palabra stakeholders. Capítulo 1 Introducción 1

13 detectado y corregido en la fase de establecimiento de los requisitos. Fase donde se detectó el error Costo promedio Definición de Requisitos 1 Diseño 3-6 Codificación 10 Pruebas de desarrollo Prueba de aceptación Operación Tabla 1-1. Costo relativo de corrección de errores [Boehm 81] Se puntualizan a continuación aquellos aspectos a considerar en los errores en los requisitos [Davis 93]: i) Cuanto más tarde en el ciclo de vida se detecta un error, más costoso es repararlo. El crecimiento de los costos de reparación es producto de la catarata de errores que se producen: errores originados en una etapa se arrastran en fases sucesivas más nuevos errores que se originan en cada una de ellas (ver Figura 1-1). [Mizuno 83] Se debe acotar que el costo de reparación tiene ligado naturalmente un costo de desarrollo previo de los artefactos que se desecharán o rehacerán en la cadena de errores. ii) Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron. El 54% de los errores se detectan después de la fase de codificación y prueba. Estos errores provienen en un 45% de la fase de requisitos y en un 9% de la fase de codificación. [Boehm 75] iii) Se están cometiendo demasiados errores. El 56% de los errores tienen su origen en la etapa de requisitos. Informado por Tom DeMarco, citado en [Tavolato 84] Capítulo 1 Introducción 2

14 iv) Los errores de requisitos responden a una clasificación típica. hechos incorrectos 49% omisiones 31% inconsistencias 13% ambigüedades 5% otros (requisitos mal ubicados) 2% [Basili 81] v) Los errores en los requisitos pueden detectarse. La detección puede realizarse a través de distintas técnicas: ad hoc, inspecciones, pruebas unitarias, pruebas de integración, evaluación (pruebas de aceptación), otros. Las inspecciones detectan el 65% de errores, las pruebas unitarias: 10%, pruebas de integración: 6%, evaluación: 10%, otros: 10%. [Davis 93] Los puntos recién mencionados se pueden resumir en las siguientes conclusiones [Davis 93]: Se cometen muchos errores de requisitos. Muchos de esos errores se detectan tardíamente. Sin embargo, muchos de esos errores pueden detectarse tempranamente. No detectar los errores contribuye al incremento de costos en el software. Diversas estadísticas realizadas a lo largo de las últimas décadas referidas a fracasos en proyectos de software [Alford 79] [Boehm 81] [GAO 92] [Faulk 92] [Lutz 93] [CHAOS 95] concluyen que los requisitos son la fuente principal de problemas en la mayoría de dichos proyectos: requisitos inadecuados, cambios en los requisitos durante el ciclo de vida, requisitos no bien comprendidos y requisitos incompletos. En 1987, el Departamento de Defensa de los Estados Unidos generó un informe [Brooks 87b] sobre los problemas de calidad y productividad en el desarrollo de software militar, que abrió las puertas para la investigación de la llamada crisis del software, ya reconocida desde fines de la década del 60 [Naur 68]. Paralelamente, acaecieron en la práctica industrial fracasos paradigmáticos en proyectos de gran envergadura, tales como el Sistema de Control del Tráfico Aéreo de la Administración Federal de Aviación [Gibbs 94] [Stix 94], el Sistema de Administración de Equipaje del Nuevo Aeropuerto Internacional de Denver [GAO 94], el Sistema de Ambulancias de Londres [Finkelstein 96], el Sistema de tiempo real de Paramax System Corporation [Lindstrom 93] y otros. Algunos de los casos más recientes que se pueden mencionar son: el Sistema de Reservas del Ferrocarril Nacional francés (dos días fuera de uso por defectos en la actualización de un programa, 2004), el Sistema de Gestión de Energía de General Electric (causó un apagón en el noreste de Estados Unidos y parte de Canadá, debido a un error de Capítulo 1 Introducción 3

15 programación en el sistema de gestión y monitoreo de energía de un proveedor que provocó la caída del resto de sistemas que no preveían esta falla, 2003), el software de la Estación Espacial Internacional (varios problemas tales como la operación de un brazo del robot de la estación, 2001), el programa de simulación del puente Millenium en Londres (falló debido a una incorrecta estimación de la cantidad de peatones, 2000), entre otros muchos. En respuesta a la baja calidad de los productos de software con altos costos de corrección y mantenimiento, muchos desarrolladores de software e investigadores se han planteado la necesidad de profundizar en el proceso previo al diseño del software. Sus investigaciones y prácticas profesionales han apuntado a garantizar la producción de software de alta calidad y bajo costo basándose en el establecimiento de un punto de partida de alta confiabilidad, mediante la detección de errores lo más tempranamente posible. Es necesario entonces contar con procesos de producción de requisitos confiables. En esta sub-sección, se ha dado cuenta de las consecuencias que producen los defectos en los requisitos, cabe mencionar a continuación las fuentes de dichos defectos. El reconocimiento de los defectos en los requisitos mediante el estudio de sus causas y efectos ha permitido, en los últimos años, el establecimiento de procesos de definición de requisitos atentos a esta grave circunstancia Errores en el proceso de desarrollo de software Habitualmente cuando se hace referencia a errores en los requisitos de los sistemas se desliza en forma tácita la idea de que el profesional de software o el proceso de captura han sido el origen de los mismos. Esta suposición, si bien muy difundida, probablemente sea parcialmente falsa ya que muchos de los errores, discrepancias y omisiones que aparecen en los requisitos y naturalmente se propagan al sistema final, ya existían en la fuente de información. En realidad existe una responsabilidad compartida, ya que en los casos en que el defecto está empotrado en la fuente de información, el ingeniero de requisitos tiene algún grado de responsabilidad al no ponerlo en evidencia, especialmente en relación con las discrepancias y omisiones. Mizuno en [Mizuno 83] propuso un modelo para la catarata de errores que se presenta en la Figura 1-1. Si bien este gráfico es notoriamente ilustrativo para comprender el problema de la propagación y la ampliación de los errores a lo largo del proceso de desarrollo de software, contiene varias simplificaciones excesivas que enmascaran algunos aspectos relevantes de la problemática de la Ingeniería de Requisitos. El punto más importante parece ser la visión del problema real como una entidad fuente de todo saber y verdad. No existe un problema real perfecto que constituya la esencia químicamente pura de las necesidades del UdeD y que determine unívocamente los requisitos del sistema de software. Por el contrario, la dificultad realmente reside en que la visión que las organizaciones tienen de ellas mismas es incompleta o incoherente [Godel 62]. Peor aún las Capítulo 1 Introducción 4

16 fuentes de información introducen sus propias contradicciones, sesgos, errores y extemporalidades que obscurecen un poco más la percepción de las necesidades del negocio 2. Problema Real Definición de Requisitos Especificación correcta Especificación errónea Diseño Diseño correcto Diseño erróneo Diseño basado en especificación errónea Implementación Programas correctos Programas con errores Programas basados en diseño erróneo Programas basados en especificación errónea Prueba Funciones correctas Errores corregibles Errores incorregibles Errores escondidos Producto con programas imperfectos Figura 1-1. Catarata de Errores según el Modelo Mizuno [Mizuno 83] El meta-modelo conceptual, que supone un problema real perfecto, asigna además todas las dificultades a: i) la inhabilidad de las fuentes de información para revelar el conocimiento profundo, y ii) la inhabilidad del ingeniero de requisitos para capturar la información relevante y libre de omisiones. Esta visión ha entronizado el concepto de la captura de requisitos, ya que lo único que habría que hacer es descubrir la verdad. De esta manera los requisitos se han reducido a un conjunto de pepitas de oro y por lo tanto la tarea a emprender es tamizar la grava para encontrarlos. El problema real es un agregado de certezas, contradicciones, dudas y 2 En [Jacobson 99] se pone de manifiesto que una complicación en la captura de requisitos son los usuarios por ser éstos una fuente imperfecta de información. Capítulo 1 Introducción 5

17 aspectos no planteados. En otras palabras, sí hay información directamente transformable en requisitos del sistema de software, pero hay mucho más que eso. La tarea del ingeniero de requisitos es mucho más compleja que meramente sonsacar los requisitos, también debe colaborar con el esclarecimiento de las dudas, debe detectar las contradicciones y visualizar las circunstancias no consideradas, entre otras. Adicionalmente, el ingeniero de requisitos contribuye con propuestas de servicios del sistema que en algunos casos complementan la información adquirida y en algunos otros ofrece algún antagonismo con la misma. Los requerimientos, pedidos y demandas de los usuarios son idealmente realizados en el contexto del objetivo de obtener una mejora en los procesos del negocio. Se dice idealmente porque pueden insertarse objetivos personales no claramente explicitados o eventualmente cuidadosamente ocultos. Por el otro lado, las propuestas del ingeniero de requisitos están guiadas por la aspiración de facilitar el desarrollo del artefacto de software, ya sea simplificando el sistema o dotándolo de propiedades que lo acerquen a modelos conceptuales preconcebidos. En la Figura 1-2, se presenta un esquema que extiende el modelo de Mizuno, visualizando el problema real como un agregado de certezas, contradicciones, dudas y aspectos no considerados. En este esquema además se representa el hecho de que las fuentes de información aportan su propia distorsión dificultando, en alguna medida, aún más el proceso de definición de los requisitos del sistema de software, proceso que por otro lado, como se visualiza en la figura, se descompone en tres sub-etapas: elicitación, modelado y especificación 3. Por razones de espacio, no se ha graficado en la Figura 1-2 la cascada de errores que se arrastran en las siguientes etapas de diseño, implementación y prueba. La Figura 1-2 fue confeccionada siguiendo el estilo de la figura original de Mizuno, por lo que conserva las mismas simplificaciones que la original, excepto las ya indicadas modificaciones en la visión del problema real. En ese sentido, el esquema no refleja que sobre los requisitos erróneos se puedan además acumular errores de diseño (sólo se cometen errores de diseño sobre los requisitos correctos) y que los errores de programación se concentran en los fragmentos del sistema correctamente diseñados. Por otra parte, en ambas figuras también se ignora que una actividad de validación forzaría, con un alto costo, la corrección de los errores incorregibles ; así como descubriría en mayor o menor grado los errores escondidos, también con altos costos de corrección. Como se ha mencionado arriba, la tarea del ingeniero de requisitos no es simple, debe tamizar la grava en el UdeD para encontrar información relevante, certera y lo más completa posible, para lo cual debe contar con técnicas y herramientas adecuadas, saber lidiar con personas a distintos niveles de la organización, y seguir los pasos necesarios que le permitan asegurar el mejor resultado. Es decir, el ingeniero de requisitos debe adquirir 3 La especificación puede ser vista como parte del modelado, pero se ha presentado por separado para mostrar más en detalle la cascada de errores. Capítulo 1 Introducción 6

18 habilidades y conocimientos que trascienden el campo tecnológico para entrar en contacto con otras ciencias que le den soporte integral a su actividad. Problema Real Certezas Inconsistencia s Dudas Aspectos no considerados Elicitación Demandas correctas Demandas erróneas Demandas inconsistentes Demandas omitidas Modelado Requisitos candidatos correctos Propuestas correctas Requisitos candidatos erróneos Propuestas erróneas Requisitos basados en demandas erróneas Requisitos basados en demandas inconsistentes Requisitos omitidos Especificación Especificación correcta Especificación errónea Especificación basada en requisitos erróneos Especific. basada en propuestas erróneas Especific. basada en demandas erróneas Especific. basada en demandas inconsistentes Especificación omitida Producto con programas imperfectos Figura 1-2. Catarata de Errores extendiendo el Modelo Mizuno La Ingeniería de Requisitos y la Ingeniería de Software La Ingeniería de Software (término acuñado por primera vez por un grupo de estudio de la NATO en 1968 [Naur 68]) provee un enfoque sistematizado para el desarrollo, operación, mantenimiento y retiro (desmantelamiento) del software [IEEE Std ]. Por lo tanto, como toda disciplina de la ingeniería, debe contar con las siguientes características: tecnologías bien comprendidas, procesos bien definidos, resultado predecible de las etapas del proceso y pasos del proceso repetibles. Se trata de una aspiración a la que tanto la Ingeniería de Software como la Ingeniería de Requisitos se están aproximando día a día, aún cuando Fred Brooks [Brooks 87] haya anunciado que nunca se encontrará la bala de plata: «Ninguna mejora importante en el área de la ingeniería de software aparecerá nunca». Dan Berry coincide con Brooks, pues luego de mostrar la frustración que causa el Capítulo 1 Introducción 7

19 desarrollo de software ya sea desde la aplicación de IR hasta XP, sugiere que tal vez el desarrollo de software sea un arte, independientemente de la cantidad de sistematización lograda en los procesos y métodos elaborados [Berry 02]. Pese a esto, la corriente principal de la Ingeniería de Software procura avanzar y hay mucho terreno para ello, y esto se evidencia en la cantidad y calidad de los trabajos de investigación que se están realizando en esta área. Existe una gran diferencia entre el producto a construir por la ingeniería de software respecto a otras ingenierías. En casi todas las ramas de la ingeniería se genera habitualmente un bosquejo / maqueta / plano / diagrama u otro elemento que representa el artefacto a construir y, a través de él, se planifica la tarea de construcción y se asegura que responda a las expectativas de los clientes. Sin embargo, una dificultad especial que se le presenta a la ingeniería de software es justamente la representación del producto a construir, pues dicho producto (el software) es en sí mismo una representación del mundo real, entonces los documentos y/o modelos que describen el software a construir son una representación de una representación a ser creada [Kovitz 02]. Esto implica la necesidad de prestar especial atención a la generación de esos documentos y/o modelos que representarán a ese artefacto, lo que indudablemente requiere un considerable esfuerzo y tiempo de elaboración, para que sean precisos, correctos y lo más completos posibles. Esta es la tarea básica de la Ingeniería de Requisitos como pilar del desarrollo de software y, como tal, debe considerarse en el contexto de la Ingeniería de Software y de la Ingeniería de Sistemas [Kaindl 02]. Por tanto, se debe observar que la Ingeniería de Software se basa en dos conceptos fundamentales: producto [Gunther 78] y sistema. Es decir, tiene simultáneamente tanto un enfoque ingenieril como un enfoque sistémico. La función de la ingeniería es procurar productos de mejor calidad dentro de un costo compatible con esa calidad, optimizando costos. Pero además, dado que el producto es un sistema debe tener en consideración las características que presenta todo sistema: propósito, globalidad, entropía y homeostasis, de acuerdo a la Teoría General de Sistemas [von Bertalanffy 68]. La Ingeniería de Software tiene dos vertientes, una mejorar el proceso de producción de software con técnicas de desarrollo, y otra mejorar la gestión del proceso, y es en esta segunda parte donde fundamentalmente cabe la Ingeniería de Requisitos pues tiene más que ver con lo humano que con lo tecnológico. Se debe enfatizar que el proceso de desarrollo de software no es solamente una actividad técnica pues se lleva a cabo en un contexto social donde todos los involucrados participan [Leite 94] [Maté 05]. La Ingeniería de Requisitos es una disciplina que procura sistematizar el proceso de definición de requisitos. Es decir, apunta a mejorar la forma en que se comprenden y definen los servicios que deberán prestar los sistemas de software. La complejidad de los problemas a resolver exige que se preste más atención a su correcto entendimiento antes de comprometer una solución. La IR cubre todas las actividades involucradas en descubrir, modelar, analizar y mantener un conjunto de requisitos para un sistema de software. Capítulo 1 Introducción 8

20 Aunque el problema de cómo establecer sistemas no es nuevo, sólo recientemente la comunidad científica de computación, principalmente la comunidad de ingeniería de software, comenzó a prestar especial atención a la tarea de definición de los servicios que deben prestar los sistemas. El término Ingeniería de Requisitos surgió (formalmente publicado) recién en Enero de 1977 en IEEE Transactions on Software Engineering, donde figuran los siguientes artículos acuñando el término: A Requirements Engineering Methodology for Real-Time Processing Requirements, Alford, M., IEEE-TSE, January An Extendable Approach to Computer-Aided Software Requirements Engineering, Bell, T., Bixler, D., Dyer, M., IEEE-TSE, January La primera conferencia internacional sobre este tema fue en 1993 (RE 93) y en 1995 se realizó la primera reunión del grupo de trabajo IFIP 2.9 (Ingeniería de Requisitos de Software). La Ingeniería de Software ha estado prestando más atención al modelado e implementación (codificación) de productos, proveyendo métodos, herramientas y procedimientos para tal fin, mientras que la Ingeniería de Requisitos comenzó examinando los aspectos del establecimiento de requisitos y su intrínseca dependencia de los aspectos sociales que rodean la construcción del software y que rodearán su operación. La IR tiene una interacción muy fuerte con aquellos que demandan un producto de software. Por lo tanto, el proceso de la IR es un esfuerzo cooperativo que involucra a usuarios, clientes, ingenieros de software, consultores, expertos, denominados en la literatura stakeholders, siendo el término que se emplea en castellano involucrados 4. La IR debe entonces achicar la brecha entre el usuario que tiene necesidades y requiere soluciones a sus problemas, pero que no tiene los conocimientos para especificar los requisitos, y el ingeniero de software que sí tiene dichos conocimientos técnicos pero desconoce el mundo del usuario con sus problemas y necesidades. De lo dicho, surgen dos aspectos ineludibles en un proceso de IR exitoso: i) establecer una buena comunicación entre ambas partes, y ii) comprender cabalmente el mundo del usuario. Lo primero sólo es posible lograrlo cuando el ingeniero de software comprende el vocabulario que maneja el usuario. La postura inversa es casi 4 Se entiende por clientes a los involucrados en el UdeD que de alguna manera se constituyen en dueños del sistema, es decir aquellos que demandan el sistema de software y usuarios a aquellos que efectivamente deban interactuar con el mismo. Naturalmente que un cliente puede ser simultáneamente un usuario y frecuentemente lo es; inclusive éstos no son roles estáticos, por el contrario pueden interactuar con el ingeniero de requisitos cambiando su punto de vista de cliente a usuario y viceversa en forma notoriamente dinámica. Se puede decir que el punto de vista del cliente tiene un sesgo más fuerte hacia los objetivos del sistema a ser desarrollado, y que el del usuario está más dirigido a los detalles concretos de su trabajo diario. Capítulo 1 Introducción 9

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 2

Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 2 Facultad de Tecnología Informática Ingeniería en Informática Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 2 Recopilación: Dra. Graciela D. S. Hadad

Más detalles

Escenarios. Diapositiva 1. Ingeniería de Requerimientos: Escenarios

Escenarios. Diapositiva 1. Ingeniería de Requerimientos: Escenarios Escenarios Diapositiva 1. Ingeniería de Requerimientos: Escenarios Diapositiva 2. Uso de lenguaje natural Debido a que uno de los objetivos de la Ingeniería de Requisitos es aumentar el conocimiento del

Más detalles

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc).

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc). REVISIÓN CONCEPTOS, METODOLOGÍAS Y HERRAMIENTAS SOPORTE EN INGENIERÍA MARLON MÚJICA Estudiante de Ingeniería de Sistemas Universidad Industrial de Santander mujica@cidlisuis.org COLOMBIA EDWIN LOGREIRA

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Cecilia Datko 1, Yanela Carllinni 2 Analista de Sistemas en el Depto. Sistemas de la Dirección de Informática

Más detalles

MANTENIMIENTO DE SOFTWARE

MANTENIMIENTO DE SOFTWARE MANTENIMIENTO DE SOFTWARE Definición de Mantenimiento El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como la modificación de un producto software después de haber sido entregado

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009

Ingeniería de Software I. Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Ingeniería de Software I Sebastián Uchitel y Víctor Braberman 1er Cuatrimestre 2009 Quienes somos? 2 Quienes son? 3 Objetivos del Curso Entender el rol fundamental que juega la construcción y análisis

Más detalles

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

Ingeniería de Software. Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm.

Ingeniería de Software. Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm. Ingeniería de Software Dr. Marcello Visconti Departamento de Informática Universidad Técnica Federico Santa María visconti@inf.utfsm.cl Ingeniería?? de Software Grandes Problemas Actuales Retraso respecto

Más detalles

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño

Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Evolución de Plantillas Genéricas para la descripción de Casos de Uso a Plantillas Genéricas para Análisis y Diseño Ing. Marcela Daniele AC. Daniel Romero Dpto. de Computación. Facultad: Ciencias Exactas,

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

MAESTRÍA TESIS EN INGENIERÍA DE SOFTWARE TEMA: USO DE PATRONES EN EL PROCESO DE CONSTRUCCIÓN DE ESCENARIOS ALUMNO: ING.

MAESTRÍA TESIS EN INGENIERÍA DE SOFTWARE TEMA: USO DE PATRONES EN EL PROCESO DE CONSTRUCCIÓN DE ESCENARIOS ALUMNO: ING. MAESTRÍA EN INGENIERÍA DE SOFTWARE TESIS TEMA: USO DE PATRONES EN EL PROCESO DE CONSTRUCCIÓN DE ESCENARIOS ALUMNO: ING. MARCELA RIDAO DIRECTOR: ING. JORGE H. DOORN CODIRECTOR: DR. JULIO CESAR SAMPAIO DO

Más detalles

Ingeniería de Software V Ingeniería de requerimientos Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances

Ingeniería de Software V Ingeniería de requerimientos Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances Facultad de Tecnología Informática Ingeniería en Informática Ingeniería de Software V Ingeniería de requerimientos Notas de clase Panorama de la Ingeniería de Requisitos: sus fundamentos y avances Recopilación:

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: CICLO DE VIDA VISIÓN TRADICIONAL DEL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN STEMAS DE INFORMACIÓN Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza M. Material revisado

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

SISTEMAS DE INFORMACIÓN II TEORÍA

SISTEMAS DE INFORMACIÓN II TEORÍA CONTENIDO: DETERMINACIÓN DE REQUERIMIENTOS ENTREVISTAS, CUESTIONARIOS, OBSERVACIONES JOINT APPICATION DESIGN (JAD) PROTOTIPOS, CASE, GROUPWARE Material diseñado y elaborado por: Prof. Luis Eduardo Mendoza

Más detalles

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE

ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE ESTÁNDARES Y MODELOS DE CALIDAD DEL SOFTWARE INTRODUCCIÓN La calidad es un concepto complejo, que se viene aplicando en el campo de la informática desde hace muchos años, la aplicación de la calidad al

Más detalles

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM Metodología BPM:RAD - Rapid Analysis & Design Capítulo extraído de El Libro del BPM 2011 Metodología BPM:RAD Rapid Analysis & Design para la modelización y diseño de procesos orientados a tecnologías BPM

Más detalles

Ingeniería del Software I

Ingeniería del Software I Ingeniería del Software I 1er. Cuatrimestre 2002 Martina Marré martina@dc.uba.ar Organización 3 tipos de clase: teórica, práctica, taller 3 grupos de docentes un cronograma material en la WEB 2002 2 Aprobación

Más detalles

Resumen. 1. Motivación

Resumen. 1. Motivación Uso de en la Derivación de Software Tesis Doctoral Graciela Dora Susana Hadad ghadad@unlam.edu.ar Director: Prof. Dr. Julio Cesar Sampaio do Prado Leite Co-director: Prof. Ing. Jorge Horacio Doorn Universidad

Más detalles

Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado.

Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado. Nº 01 PUBLICADO EN INGENIUM Nª 03 Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado. Ing. Rosa Menéndez Mueras Resumen Definiciones básicas de modelo de análisis y análisis

Más detalles

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática

El Proceso de Desarrollo de Software. Diseño de Software Avanzado Departamento de Informática El Proceso de Desarrollo de Software La Ingeniería del Software Ingeniería... La profesión en la que el conocimiento de las ciencias naturales y matemáticas, ganado con estudio, experiencia y práctica,

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE

MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE MODELOS DE CALIDAD EN EL DESARROLLO DE SOFTWARE INTRODUCCIÓN Los Modelos de Calidad son herramientas que guían a las Organizaciones a la Mejora Continua y la Competitividad dando les especificaciones de

Más detalles

Mejorando las debilidades de RUP para la gestión de proyectos

Mejorando las debilidades de RUP para la gestión de proyectos RISI 7(2), 2010 (49-56) Revista de Investigación de Sistemas e Informática Facultad de Ingeniería de Sistemas e Informática Universidad Nacional Mayor de San Marcos ISSN 1815-0268 (versión impresa) ISSN

Más detalles

Ingeniería del Software II

Ingeniería del Software II Bloque III: Proceso Unificado Simona Bernardi Dipartimento di Informatica Università di Torino (Italia) Duración: 4 horas Objetivo: Conocer un proceso de desarrollo de software diferente a OMT Simona Bernardi

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

MEJORA CONTINUA DE LA CALIDAD EN LOS PROCESOS (1)

MEJORA CONTINUA DE LA CALIDAD EN LOS PROCESOS (1) Vol. (6) 1: pp. 89-94 MEJORA CONTINUA DE LA CALIDAD EN LOS PROCESOS (1) Manuel García P. (2) Carlos Quispe A. (3) Luis Ráez G. INTRODUCCIÓN RESUMEN El enfoque actual de la calidad en las organizaciones

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Primer Cuatrimestre de 2009 Clase 1a: Introducción a la Ingeniería de Software Buenos Aires, 16 de Marzo de 2009 Existe la Ingeniería de Software? Ingeniería de Software según

Más detalles

UNIVERSIDAD TECNOLÓGICA DE JALISCO

UNIVERSIDAD TECNOLÓGICA DE JALISCO UNIVERSIDAD TECNOLÓGICA DE JALISCO Creación Periodo: Mayo - Agosto 2013 Adecuaciones Periodo: Por: M.C. Felipe Belmont Polanco M.C.Felipe Belmont Polanco. Pág. 1 Temario I.- Introducción a la ingeniería

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO Autor: Lic. Claudio Jorge Rancán Directora: M.Ing. Paola Britos Julio 2003

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Calidad del software. Ingeniería del Software I Universidad Rey Juan Carlos

Calidad del software. Ingeniería del Software I Universidad Rey Juan Carlos Calidad del software Ingeniería del Software I Universidad Rey Juan Carlos Definición de Calidad Software I do not worry whether something is cheap or expensive. I only worry if it is good. If it is good

Más detalles

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

Más detalles

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

Más detalles

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

para la automatización es una forma en que puede mejorar los procesos de negocio.

para la automatización es una forma en que puede mejorar los procesos de negocio. El Modelado del Negocio Utilizando la Metodología Rational Unified Process (RUP) Omar Beltrán Celis Mendoza 1, Alderson Luna Aguinaga 1, Ing. Daniel Lévano Rodríguez, Mg 2 Resumen El Modelado del Negocio

Más detalles

Pontificia Universidad Católica Argentina

Pontificia Universidad Católica Argentina Carrera : Ingeniería Informática Pontificia Universidad Católica Argentina PROGRAMA DE INGENIERÍA DE SOFTWARE I 2010 Ubicación en el Plan de Estudios : 3 er Año, cuatrimestral Carga Horaria : 8 hs / semana

Más detalles

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3

1. Introducción. 2. El concepto de calidad del software. 3. Estándares de calidad existentes. 4. La norma ISO 9000-3 Contenido INGENIERIA DE SOFTWARE Tema 6: Administración de la calidad del software Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx Cubo 37 1. Introducción 2.

Más detalles

Estudio Comparativo de Técnicas de Modelado de Negocio

Estudio Comparativo de Técnicas de Modelado de Negocio Estudio Comparativo de Técnicas de Modelado de Negocio Juan José Cadavid 1, Carlos Andrés Ospina 1, Juan Bernardo Quintero 2 1 Avansoft S.A. Medellín, Colombia {jjcadavid, caospina}@avansoft.com 2 ABC-Flex

Más detalles

3. LÉXICO EXTENDIDO DEL LENGUAJE.

3. LÉXICO EXTENDIDO DEL LENGUAJE. 3. LÉXICO EXTENDIDO DEL LENGUAJE. El LEL (Language Extended Lexicon) [Leite90] es un modelo que permite representar y documentar, con tecnología hipertextual un conjunto de símbolos que representan el

Más detalles

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE

SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE Recibido: 23 de febrero de 2011 Aceptado: 29 de marzo de 2011 SCOPE PLANNING IN SOFTWARE PROJECTS PLANIFICACIÓN DEL ALCANCE EN PROYECTOS DE SOFTWARE MSc. Ailin Orjuela, MSc. Luis Alberto Esteban, MSc.

Más detalles

Objetivo: Analizar las características de los modelos de estandarización de la calidad CMM, SPICE, IEEE e ISO

Objetivo: Analizar las características de los modelos de estandarización de la calidad CMM, SPICE, IEEE e ISO INGENIERÍA DE SOFTWARE AVANZADA MIS (Sesión 10) 4.3 Modelos de mejora de proceso (CMM y SPICE) 4.4 Normas técnicas (IEEE, ISO, EU, etc.) 4.3 Modelos de mejora de proceso (CMM y SPICE) Objetivo: Analizar

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software

Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Modelos de Ciclo de Vida de Desarrollo de Software en el Contexto de la Industria Colombiana de Software Hugo F. Arboleda Jiménez. MSc. Docente-Investigador, Facultad de Ingenierías, Universidad de San

Más detalles

Curso: El Proceso de Desarrollo de Software

Curso: El Proceso de Desarrollo de Software Curso: El Proceso de Desarrollo de Software EL PROCESO DE DESARROLLO DE SOFTWARE... 1 OBJETIVO...1 CONTENIDO...1 BIBLIOGRAFÍA...4 DOCENTE...4 MODALIDAD DEL DESARROLLO...4 El proceso de Desarrollo de Software

Más detalles

INGENIERÍA de REQUERIMIENTOS

INGENIERÍA de REQUERIMIENTOS INGENIERÍA de REQUERIMIENTOS Unidad IV Análisis de Requerimientos Verificación Validación Negociación - Trazabilidad Quality Function Deployment (QFD) 1 1 Análisis Verificación y Validación de Requerimientos

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

Modelo de Procesos Integral

Modelo de Procesos Integral Modelo de Procesos Integral Gestión de Servicios de TI Procesos de negocio complejos y cambiantes, tiempos acelerados y un mercado global imponen requerimientos exigentes. El negocio depende de la tecnología,

Más detalles

Modelos de especificación de requerimientos para la obtención de esquemas conceptuales en un dominio restringido

Modelos de especificación de requerimientos para la obtención de esquemas conceptuales en un dominio restringido Modelos de especificación de requerimientos para la obtención de esquemas conceptuales en un dominio restringido Fernández Taurant, Juan Pablo Ing. Marciszack, Marcelo M. Universidad Tecnológica Nacional,

Más detalles

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos

Capítulo 2 Ideas generales de CMMI-SW. 2.1 Introducción. 2.2 Procesos. 2.3 Modelo de procesos Capítulo 2 Ideas generales de CMMI-SW 2.1 Introducción El Capability Maturity Model Integration (en adelante CMMI), se compone de un conjunto de modelos, métodos de evaluación y cursos de formación para

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 1

Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 1 Facultad de Tecnología Informática Ingeniería en Informática Ingeniería de Software V Ingeniería de requerimientos Estrategia en la Ingeniería de Requisitos PARTE 1 Recopilación: Dra. Graciela D. S. Hadad

Más detalles

DESARROLLO DE SOFTWARE ORIENTADO. A OBJETOS: Modelo de requerimientos del RUP

DESARROLLO DE SOFTWARE ORIENTADO. A OBJETOS: Modelo de requerimientos del RUP DESARROLLO DE SOFTWARE ORIENTADO A OBJETOS: Modelo de requerimientos del RUP Adesmiro Zelada Escobedo 1*, Miguel Figueroa Martel 2 * 1 Facultad de Ingeniería y Arquitectura, Universidad Peruana Unión *

Más detalles

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1

Calidad y Software. Evento ONGEI 29 mar 11. www.asistp.com 1 Calidad y Software Evento ONGEI 29 mar 11 www.asistp.com 1 Agenda La Calidad y los Procesos El Proceso de Software Las pruebas de Software www.asistp.com 2 Calidad www.asistp.com 3 Calidad algunas definiciones

Más detalles

Pontificia Universidad Javeriana Ingeniería de Requerimientos Anamaria Ortiz Febrero de 2007

Pontificia Universidad Javeriana Ingeniería de Requerimientos Anamaria Ortiz Febrero de 2007 Pontificia Universidad Javeriana Ingeniería de Requerimientos Anamaria Ortiz Febrero de 2007 Agenda Definiciones de Calidad SRS Software Requirement Specification. Errores de Requerimientos. Implicaciones

Más detalles

ADMINISTRACIÓN DE PROYECTOS

ADMINISTRACIÓN DE PROYECTOS ADMINISTRACIÓN DE PROYECTOS QUÉ ES LA ADMINISTRACIÓN DE PROYECTOS? Es la planeación, organización, dirección y control de los recursos para lograr un objetivo a corto plazo. También se dice que la administración

Más detalles

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez

Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y Sandra Dinora Orantes Jiménez Revista Digital Universitaria 1 de enero 2012 Volumen 13 Número 1 ISSN: 1067-6079 Metodologías híbridas para desarrollo de software: una opción factible para México Eréndira Miriam Jiménez Hernández y

Más detalles

El tema del proyecto de tesis que estoy desarrollando, según la clasificación de la ACM (Association for Computing Machinery) es la siguiente:

El tema del proyecto de tesis que estoy desarrollando, según la clasificación de la ACM (Association for Computing Machinery) es la siguiente: CAPITULO III: ESTADO DEL ARTE 3.1. Taxonomía El tema del proyecto de tesis que estoy desarrollando, según la clasificación de la ACM (Association for Computing Machinery) es la siguiente: H. Sistemas de

Más detalles

Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado.

Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado. Modelo de Negocio y Análisis de Requerimientos Basado en el Proceso Unificado. Rosa Menéndez Mueras 1 Resumen Definiciones básicas de modelo de análisis y análisis de requerimientos basado en el estándar

Más detalles

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2 UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA GESTIÓN DE SOFTWARE INFORME SOBRE Evaluación de Productos Grupo 2 Marcelo Caponi 3.825.139-0 Daniel De Vera 4.120.602-3 José Luis Ibarra 4.347.596-3

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S1 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

PROCESOS DE SOFTWARE HE AHÍ EL DILEMA

PROCESOS DE SOFTWARE HE AHÍ EL DILEMA PROCESOS DE SOFTWARE HE AHÍ EL DILEMA JAIME GARCIA CEPEDA jgarcia@skitconsulting.com SKIT Consulting 2718884 BOGOTÁ 1 PREAMBULO Septiembre'2007 2 Algunos de nuestros Ingenieros Septiembre'2007 3 Ing. PASARELA

Más detalles

GRANULARIDAD DE LA INFORMACIÓN EXTEMPORANEA EN LOS PROCESOS DE REQUISITOS

GRANULARIDAD DE LA INFORMACIÓN EXTEMPORANEA EN LOS PROCESOS DE REQUISITOS GRANULARIDAD DE LA INFORMACIÓN EXTEMPORANEA EN LOS PROCESOS DE REQUISITOS Gladys Kaplan 1,3, Jorge Doorn 1,2, Graciela Hadad 1 1 Departamento de Ingeniería e Investigaciones Tecnológicas, UNLaM 2 INTIA,

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

UNIDAD 3 EL PROCESO DE EDUCCIÓN

UNIDAD 3 EL PROCESO DE EDUCCIÓN UNIDAD 3 EL PROCESO DE EDUCCIÓN 3. EL PROCESO DE EDUCCIÓN... 1 3.1.DEFINICIONES... 1 3.2.EL PROCESO DE EDUCCIÓN... 2 3.3.PARTICIPANTES... 5 3.4.PROBLEMAS DE LA EDUCCIÓN... 7 3.1. Definiciones En los últimos

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

Gestión de Requerimientos: el talón de Aquiles de los proyectos

Gestión de Requerimientos: el talón de Aquiles de los proyectos 1 Gestión de Requerimientos: el talón de Aquiles de los proyectos Guilherme Siqueira Simões guilherme.simoes@fattocs.com Enlighten your software 1 de Julio de 2015 2 Agenda Qué es la gestión de requerimientos?

Más detalles

Traceability en la elicitación y especificación de requerimientos. Leandro Antonelli. Directores: Alejandro Oliveros Gustavo Rossi

Traceability en la elicitación y especificación de requerimientos. Leandro Antonelli. Directores: Alejandro Oliveros Gustavo Rossi Traceability en la elicitación y especificación de requerimientos Leandro Antonelli Directores: Alejandro Oliveros Gustavo Rossi Tesis presentada a la Facultad de Informática de la Universidad Nacional

Más detalles

Las Buenas Prácticas de la Ingeniería de Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de Análisis y Diseño de Software

Las Buenas Prácticas de la Ingeniería de Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de Análisis y Diseño de Software Las Buenas Prácticas de la Ingeniería de Requerimientos y los Mapas Mentales como Instrumentos de Apoyo al Proceso de Análisis y Diseño de Software Luis Carlos Díaz Ch. Miguel Eduardo Torres M. {luisdiaz,metorres}@javeriana.edu.co

Más detalles

Análisis Comparativo de Modelos de Calidad

Análisis Comparativo de Modelos de Calidad Análisis Comparativo de Modelos de Calidad Identificación de Mejores Prácticas para la Gestión de Calidad en Pequeños Entornos Vianca Vega Zepeda Departamento de Ingeniería de Sistemas y Computación Universidad

Más detalles