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

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

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

Transcripción

1 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: Dra. Graciela D. S. Hadad

2

3 Facultad de Tecnología 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 Dra. Graciela D. S. Hadad 2011

4 Índice Pág. 1 La importancia de los requisitos en el desarrollo del software Evolución de los errores en el proceso de desarrollo de software Evolución de los requisitos La Ingeniería de Requisitos en el contexto de la Ingeniería de Software Puntos clave de la Ingeniería de Requisitos Principales iniciativas en la Ingeniería de Requisitos Estándares para especificar requisitos Estándares de calidad en el proceso de IR Congresos dedicados a esta disciplina Revistas y libros dedicados al tema Herramientas comerciales que soportan actividades de la IR El proceso de Ingeniería de Requisitos Referencias UB FTI Ingeniería de Requerimientos

5 1 La importancia de los requisitos en el desarrollo del software La clave del éxito o fracaso de un proyecto de software depende fuertemente de resolver el problema correcto (Rumbaugh, 1994), es decir, encontrar el conjunto de soluciones adecuadas al problema en el universo de discurso 1. Para lo cual, se debe primero capturar las demandas, necesidades y problemas existentes en el universo de discurso y luego determinar que los requisitos especificados sean los correctos. Ya en la década anterior Frederick Brooks anunciaba en su artículo No Silver Bullet (Brooks, 1987): «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.» 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. Los costos por corrección de errores en los requisitos se incrementan en cada fase de desarrollo del software. La incidencia del costo de 1 Universo de discurso: 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. UB FTI Ingeniería de Requerimientos

6 corrección de requisitos erróneos ha sido ampliamente estudiada por autores como Michael Fagan (1974), Barry Boehm (1976), Bell y Thayer (1976), Edmund Daly (1977), Basili y Weiss (1981) y Alan Davis (1993) entre otros. Barry Boehm (1981) estudió varios proyectos de desarrollo de software de gran envergadura para determinar el costo de corrección de errores en los requisitos, errores que eran descubiertos tardíamente en el proceso de desarrollo (ver Tabla 1). Como se observa en la Tabla 1, el costo relativo de reparar un requisito erróneo que permanece sin ser detectado hasta la etapa de operación puede costar hasta 100 veces más que si fuera detectado y corregido en la fase de requisitos. En un estudio más reciente, Joseph Carr (2000) mostró que la mayoría de estos números siguen siendo válidos. 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. Costo relativo de corrección de un error, Boehm (1981) Se puntualiza a continuación los aspectos a considerar en los errores en los requisitos, Alan Davis (1993): 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. Modelo Mizuno (1983) (ver Figura 1) UB FTI Ingeniería de Requerimientos

7 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. Barry Boehm (1975) 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 y Vincena (1984) 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 y Weiss (1981) v) Los errores en los requisitos pueden detectarse. La detección puede realizarse a través de distintas técnicas: ad hoc, inspecciones (muy alta efectividad), testeos (pruebas individuales), pruebas de integración, evaluación (pruebas de aceptación), otros. Las inspecciones detectan el 65% de errores, el testeo de unidades: 10%, integración: 6%, evaluación: 10%, otros: 10% Alan Davis (1993) UB FTI Ingeniería de Requerimientos

8 Los puntos recién mencionados se pueden resumir en las siguientes conclusiones, Davis (1993): Se cometen muchos errores de requisitos. Muchos de esos errores se detectan tardíamente. Sin embargo, muchos de esos errores pueden detectarse tempranamente. El no detectar 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 y Lawson, 1979) (Boehm, 1981) (GAO, 1992) (Faulk, 1992) (Lutz, 1993) (CHAOS, 1995) 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, requisitos incompletos, etc. En 1987, el Departamento de Defensa de los Estados Unidos generó un informe (Brooks, 1987b) 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. 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, 1994) (Stix, 1994), el Sistema de Administración de Equipaje del Nuevo Aeropuerto Internacional de Denver (GAO, 1994), el Sistema de Ambulancias de Londres (Finkelstein y Dowell, 1996), el Sistema de tiempo real de Paramax System Corporation (Lindstrom, 1993). 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 UB FTI Ingeniería de Requerimientos

9 y parte de Canadá, debido a un error de programación en el sistema de gestión y monitoreo de energía de un proveedor, 2003), el software de la Estación Espacial Internacional (varios problemas 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. 2 Evolución de los 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 (1983) propuso un modelo para las cataratas de errores que se presenta en la Figura 1. 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, aunque contiene varias simplificaciones que enmascaran algunos aspectos relevantes de la problemática de la Ingeniería de Requisitos (IR). 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 determine unívocamente los requisitos del sistema de software. Por el UB FTI Ingeniería de Requerimientos

10 contrario, el problema real reside en que las organizaciones no son completas ni coherentes (Godel, 1962). Además, las 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. 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 Programas basados Programas basados en diseño erróneo en especificación errores errónea Prueba Funciones correctas Errores corregibles Errores incorregibles Errores escondidos Producto con Programas Imperfectos Figura 1. Catarata de Errores según el Modelo Mizuno (1983) 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 sin omisiones. El problema real es un agregado de certezas, contradicciones, dudas y aspectos no planteados. En otras palabras, sí hay información directamente UB FTI Ingeniería de Requerimientos

11 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. Decimos idealmente porque pueden insertarse intereses personales no claramente explicitados o eventualmente cuidadosamente ocultos. Por 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 2 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. La Figura 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 comenten 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 2 En la Figura 2 solo se muestra la apertura en actividades de la fase Definición de Requisitos por razones de espacio. UB FTI Ingeniería de Requerimientos

12 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. Problema Real Certezas Inconsistencia 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 2. Catarata de Errores extendiendo el Modelo Mizuno 3 Evolución de los requisitos La Ingeniería de Software desde sus comienzos ha propuesto métodos para facilitar los cambios en el software (Lehman y Belady, 1985) (Lehman, 1991), desde los métodos estructurados, ocultando información en módulos hasta los métodos orientados a objetos encapsulando comportamiento en clases. Los cambios no son algo ocasionales sino que, muy por el contrario, ocurren constantemente durante todo el ciclo de vida del software. Como bien UB FTI Ingeniería de Requerimientos

13 menciona Leite (1997): «el cambio es una propiedad intrínseca al software», y por lo tanto merece una consideración especial en el proceso de desarrollo, que es la administración de dichos cambios. Desde la perspectiva de la IR, esta actividad se denomina gestión de requisitos. Los requisitos evolucionan registrando los cambios que el universo de discurso impone al software. Estadísticas realizadas marcan que el 50% o más de los requisitos van a cambiar antes que el sistema de software se ponga en operación (Kotonya y Sommerville, 1998). Es por esta razón que se pone énfasis en especificaciones dinámicas de requisitos precisos y claros que acompañen los cambios del universo de discurso y que permitan el seguimiento de los mismos desde cualquier punto del proceso de producción del software hasta sus orígenes. Debe considerarse cuál es el origen de estos cambios en el software. Son estos cambios realmente genuinos, es decir, surgen como consecuencia de cambios en el universo de discurso o provienen de requisitos descubiertos tardíamente? Es frecuente que algunos requisitos se descubran parcialmente o no salgan a la luz hasta avanzado el desarrollo, cuando los diseñadores o inclusive los programadores deben realizar tareas a muy bajo nivel de detalle y se chocan con ambigüedades, contradicciones u omisiones. En estos casos, la esencia del cambio no corresponde a un mundo en evolución sino a requisitos no descubiertos oportunamente. Con respecto a los cambios reales en el universo de discurso, no sólo se deben a cambios externos o internos a la organización como consecuencia de factores políticos, económicos, legales, sociales o tecnológicos, sino muchas veces a un cambio en las expectativas de los mismos clientes y usuarios una vez que ven más claramente las posibilidades que permitirá el sistema de software. Lehman (1980) va más allá expresando que un sistema una vez instalado se convierte en parte del universo de discurso alterándolo y, por ende, él mismo (el software) altera sus propios requisitos. UB FTI Ingeniería de Requerimientos

14 En general, las estadísticas realizadas sobre la evolución de los requisitos no discriminan adecuadamente el origen de los cambios en el desarrollo del software, y simplemente lo adjudican a la evolución del universo de discurso (Yeh y Ng, 1990) (Kotonya y Sommerville, 1996) (Madhavji, 1997) (Goedicke et al., 1999). Lientz y Swanson (1978) determinaron que los cambios en el software durante su mantenimiento se debían en un 80% a cambios en los requisitos y el restante 20% a correcciones de errores. Sin embargo, no se discrimina en estos valores cuántas de las correcciones de errores se debían a requisitos con defectos ni cuántos de los cambios en los requisitos eran por la naturaleza evolutiva del universo de discurso o por defectos en los requisitos (requisitos descubiertos tardíamente o requisitos mal interpretados). Un estudio más reciente sobre mantenimiento de software (Pigoski, 1996) informa que alrededor del 55% de los pedidos de cambio corresponden a requisitos nuevos o cambios en requisitos por mejoras, mientras que un 25% son cambios técnicos por adaptaciones. Desde ya que existen universos de discurso donde predomina una evolución constante, tal es el caso por ejemplo del dominio de las telecomunicaciones. También es el caso de desarrollos de sistemas grandes, complejos donde es inevitable que haya múltiples versiones que derivan tanto de cambios planeados por mejoras como de cambios no planeados por evolución del universo de discurso. Por otro lado, el descubrimiento tardío de requisitos se debe en muchos casos a procesos de producción débiles con pocas guías y poca disciplina, donde se requiere la generación rápida del artefacto de software y los requisitos se descubren a medida que se implementa parcialmente el software, tal es el caso en el dominio del comercio electrónico donde hay una fuerte competencia. Es también muy común que el descubrimiento tardío corresponda a requisitos no funcionales, cuando éstos no son atendidos adecuadamente durante la definición de requisitos (Cysneiros y Leite, 1999). Un requisito no funcional no capturado oportunamente puede obligar a muchos cambios en otros requisitos tanto funcionales como no funcionales. UB FTI Ingeniería de Requerimientos

15 De lo mencionado hasta ahora, cabe destacar dos cuestiones: i) La visión del Modelo de Mizuno (Figura 1) y la visión extendida del mismo (Figura 2) son estáticas. Ambas consideran que los procesos del negocio no cambian durante el período de desarrollo del software. ii) La visión muy difundida de la evolución de los requisitos se basa en un único componente: el cambio del universo de discurso, pero prácticamente omite un segundo componente: los requisitos descubiertos o comprendidos tardíamente. Es obvio que este último componente produce también modificaciones en los requisitos, y lo hace con mucha mayor frecuencia de lo mencionado en la literatura. Michael Jackson (1994) afirma que sobre los requisitos se saben dos cosas: 1) van a cambiar y 2) van a ser mal comprendidos. Problema Real Certezas Dudas Inconsistencias Aspectos no considerados Tiempo de desarrollo Elicitación Modelado Requisitos Propuestas candidatos correctas correctos Especificación Especificación correcta Especificación errónea Demandas correctas Requisitos candidatos erróneos Demandas erróneas Propuestas erróneas Especificación Especific. basada basada en en propuestas requisitos erróneos erróneas Demandas inconsistentes Requisitos basados en demandas erróneas Especific. basada en demandas erróneas Demandas omitidas Requisitos basados en demandas inconsistentes Especific. basada en demandas inconsistentes Requisitos omitidos Especificación omitida Producto con Programas Imperfectos Figura 3. Evolución de los Errores + Evolución de los Requisitos UB FTI Ingeniería de Requerimientos

16 En la Figura 3 se muestra la incorporación de la noción de evolución de requisitos a la Figura 2, donde se presenta un eje relativo al tiempo de desarrollo del software y otro relativo al tiempo de los cambios durante el desarrollo mismo. El proceso de la IR (ver sección 7) tiene sentido en organizaciones con una estabilidad aceptable en sus procesos del negocio. En organizaciones con estrategias o procesos del negocio inestables a muy inestables, hay que pensar en métodos ágiles de desarrollo de software, pues cuál es el sentido de modelar requisitos que cambian más rápido que el tiempo necesario para documentarlos. Los sistemas de software son un factor de estabilización de los procedimientos de la organización, por lo tanto, es natural que el proceso de desarrollo del software tenga un cierto grado de conflicto con la tendencia a la variación de estas organizaciones. En organizaciones con cambios constantes, los sistemas de software se ven sumidos en un mantenimiento permanente e incremental a medida que nuevos componentes de software se van instalando. 4 La Ingeniería de Requisitos en el contexto de la Ingeniería de Software La Ingeniería de Requisitos (IR) es una disciplina que procura sistematizar el proceso de definición de requisitos. Es decir, apunta a mejorar la forma en que comprendemos y definimos sistemas de software complejos. La complejidad de los sistemas exige que se preste más atención al correcto entendimiento del problema antes de comprometer una solución. La IR cubre todas las actividades involucradas en descubrir, documentar, analizar y mantener un conjunto de requisitos para un sistema de software. UB FTI Ingeniería de Requerimientos

17 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 requisitos. El término Ingeniería de Requisitos ( Requirements Engineering ) surgió formalmente publicado recién en Enero de 1977 en IEEE Transactions on Software Engineering. 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 demasiada atención al modelado e implementación de productos, pero la IR comenzó examinando los aspectos de la generación 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, entre otros, denominados en la literatura involucrados 3. 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) garantizar una buena comunicación entre ambas partes, y ii) comprender cabalmente el mundo del usuario. Lo primero se logra cuando el ingeniero de software comprende el vocabulario que maneja el usuario. Para lo segundo, el ingeniero de software requiere utilizar técnicas específicas que ayuden a obtener información de ese mundo 3 Es la traducción en castellano que se emplea de la palabra stakeholders. UB FTI Ingeniería de Requerimientos

18 (técnicas de elicitación 4 ) y que faciliten determinar si la comprensión lograda es correcta (técnicas de Verificación y Validación). Cabe destacar que cuando la fuente de información son las personas, éstas muchas veces no saben o no pueden o no quieren expresar claramente sus necesidades, o lo que es peor aún, pueden ni siquiera ser concientes de ellas. En resumen, la necesidad de asegurar una buena comprensión entre los ingenieros de requisitos y los usuarios (en general, entre todos los involucrados) ha inducido al desarrollo de métodos que permitan la colaboración entre todos los participantes del proceso de definición de requisitos. Los ingenieros de requisitos deben comprender, modelar y analizar el universo de discurso donde el software operará y los usuarios deben confirmar que la visión de los ingenieros es correcta. Estos requisitos deben contemplar las necesidades de los usuarios, las reglas de la organización y las reglas externas próximas al universo de discurso. Debido a la baja calidad de los productos de software con altos costos de corrección y mantenimiento, los desarrolladores de software e investigadores han profundizado sus estudios y prácticas en el proceso previo al diseño del software. Se debe garantizar la producción de software de alta calidad y bajo costo estableciendo un punto de partida de alta confiabilidad, el que se logra mediante la detección lo más tempranamente posible de errores. Es necesario entonces contar con procesos de producción de requisitos confiables. Por otra parte, la IR enfatiza la necesidad de que los requisitos no sólo sean de la mayor calidad posible en el comienzo del proceso de desarrollo, sino que también se conserve la calidad a lo largo de todo el desarrollo. Para lograr esto, es necesario que los requisitos puedan evolucionar registrando los cambios que la realidad impone al desarrollo de la aplicación. 4 Elicitar: descubrir, tornar explícito, obtener el máximo de información para el conocimiento del objeto en cuestión. UB FTI Ingeniería de Requerimientos

19 5 Puntos clave de la Ingeniería de Requisitos En base a lo ya mencionado hasta aquí, los puntos claves que debe considerar un proceso de IR son: i) Involucrar a los clientes y usuarios en el proceso. Es decir, establecer la participación activa y constante de los clientes y usuarios. Esto implica entablar una buena comunicación con ellos para comprender cabalmente sus necesidades. ii) Asegurar la calidad de los requisitos. Esto involucra utilizar técnicas adecuadas de Verificación y Validación, las cuales deben formar parte de las actividades continuas del proceso de la IR y no como hitos estáticos. Por otro lado, la calidad de los requisitos debe conservarse a lo largo de todo el ciclo de vida del software. iii) Considerar la evolución de los requisitos durante el ciclo de vida del software. El proceso debe acompañar esta evolución. Esto involucra una adecuada gestión de los requisitos, asegurando la rastreabilidad 5 de los mismos. iv) Considerar aspectos sociales, organizacionales, políticos y legales del ambiente donde el software operará. Esto impone una inmersión de los desarrolladores en dicho ambiente y el uso de técnicas de modelado organizacional. v) Procurar la completitud de los requisitos 6. Esto es por un lado, un aspecto de la calidad y por otro lado, requiere de una comprensión adecuada del universo de discurso, ambos aspectos tratados en los puntos anteriores. Dados los graves problemas que los errores en los requisitos ocasionan sobre 5 La rastreabilidad de los requisitos ( requirements traceability ) se encarga de mantener vínculos entre los requisitos, el diseño y el código, y entre los requisitos y las fuentes de información que les dieron origen. 6 Falacia de la completitud: en un mundo real de gran complejidad, se aspira a obtener un conjunto de requisitos lo más completo posible (Leite, 1994). UB FTI Ingeniería de Requerimientos

20 el producto final (el sistema de software) y durante el proceso de producción del mismo, es que diversos centros de estudio, organismos gubernamentales y otras organizaciones se han dedicado en la última década a la investigación en el área de los requisitos de los sistemas de software. En tal sentido, se han propuesto diversos enfoques en el tratamiento de requisitos, estableciendo nuevos procesos, técnicas y métodos de producción de requisitos, creando herramientas de soporte a dichos procesos, fijando estándares en los procesos y productos, y estableciendo procesos para garantizar la calidad de los requisitos, procesos que permitan la evolución de los requisitos y su adecuada gestión durante todo el ciclo de vida del software. En la sección siguiente se enumeran algunos ejemplos importantes de estas iniciativas. 6 Principales iniciativas en la Ingeniería de Requisitos A pesar de ser la IR una disciplina reciente, cuyos comienzos datan de principios de la década del 90, existen abundantes evidencias de la dimensión que ha tomado en el desarrollo de sistemas de software. Esta evidencia se basa en la serie de estándares fijados para el documento de especificación de requisitos y para el proceso de producción de los requisitos, la variedad de productos comerciales que soportan de diversas formas las actividades involucradas en la IR, la profusión de congresos, revistas y libros específicos en esta área y las comunidades informáticas dedicadas al estudio de los diferentes aspectos que abarca la Ingeniería de Requisitos. Se detallan en las siguientes sub-secciones algunos de estos testimonios, tanto en el ámbito académico como profesional. UB FTI Ingeniería de Requerimientos

21 6.1 Estándares para especificar requisitos IEEE Std , IEEE Recommended Practice for Software Requirements Specifications, IEEE, New York, IEEE Std P1233/D3, IEEE Guide for Developing System Requirements for Specifications, IEEE, New York, DOD-STD-2167A, Defense System Software Development, US Department of Defense, Febrero Reemplazado en Diciembre de 1994 por MIL-STD-498 (el cual elimina la influencia del modelo de cascada). NCC, The STARTS Guide: A Guide to Methods and Software Tools for the Construction of Large Real-Time Systems, National Computing Centre, Manchester, MIL-STD-498, estándar requerido por el gobierno de Estados Unidos, Diciembre 1994, cancelado en Junio Este estándar implementa los procesos de desarrollo y documentación de ISO/IEC DIS 12207, e interpreta todas las cláusulas aplicables en MIL-Q-9858A (Quality Program Requirements) y en ISO 9001 (Quality Systems) para software. Establece una plantilla para el Documento de Especificación de Requisitos y describe un proceso de desarrollo de software incremental e iterativo y prácticas para la evolución de requisitos. ESA PSS-05-01, Guide to the software engineering standards, desarrollado por European Space Agency Board for Software Standardisation and Control, Octubre En particular presenta dos documentos referidos a requisitos: ESA PSS Guide to the User Requirements Definition Phase y ESA PSS Guide to the Software Requirements Definition Phase. DOD , estándar requerido por el gobierno de Estados Unidos, Este estándar reemplazó al MIL-STD-498, y también recomienda el uso de procesos incrementales e iterativos. UB FTI Ingeniería de Requerimientos

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

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

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

Uso de Escenarios. en la Derivación de Software

Uso de Escenarios. en la Derivación de Software 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

Más detalles

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas CÓDIGO ASIGNATURA 635 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas ASIGNATURA: Ingeniería de Requerimientos Ingeniería en Informática Año: 2010 Cuatri: 1º 1. OBJETIVOS Marco referencial El rol

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

CSTIC 2011. Madrid, 20 de Septiembre 2011. Universidad Pontificia de Comillas. Patronos:

CSTIC 2011. Madrid, 20 de Septiembre 2011. Universidad Pontificia de Comillas. Patronos: Madrid, 20 de Septiembre 2011 Universidad Pontificia de Comillas Patronos: Mantenimiento del Software: Aspectos Clave para la Gestión de un Servicio Continuo Patrocinadores Miguel Ángel Martínez Jimeno

Más detalles

Magíster en Ingeniería de Software Administración de Proyectos Prof. Lic. Alejandro Oliveros

Magíster en Ingeniería de Software Administración de Proyectos Prof. Lic. Alejandro Oliveros Profesor: Lic. Alejandro Oliveros Objetivo Discutir los lineamientos generales de la administración de proyectos enfatizando aspectos vinculados a la medición de resultados, a la inserción de parámetros

Más detalles

Los requisitos, un factor crítico en el éxito de los proyectos

Los requisitos, un factor crítico en el éxito de los proyectos Los requisitos, un factor crítico en el éxito de los proyectos La importancia de los modelos José Luis Fernández Sánchez Profesor titular ETSI Industriales- Universidad Politécnica de Madrid jlfdez@etsii.upm.es

Más detalles

Data analyses for sharing assessment results Introduction to Requirements Engineering - Technical Report Dec 2008 Natalia Andriano

Data analyses for sharing assessment results Introduction to Requirements Engineering - Technical Report Dec 2008 Natalia Andriano Data analyses for sharing assessment results Introduction to Requirements Engineering - Technical Report Dec 2008 Natalia Andriano Grupo de Investigación en Ingeniería y Calidad de Software Departamento

Más detalles

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012

Objetivos FACULTAD DE INGENIERIA. DEPARTAMENTO DE INGENIERIA DE SISTEMAS. Código de la asignatura 4070. Fecha de Actualización Julio 24 de 2012 Nombre de la asignatura Ingeniería de Software Código de la asignatura 4070 Fecha de Actualización Julio 24 de 2012 Intensidad horaria semanal Horas Contacto 4 Horas Trabajo Independiente 8 Créditos Académicos

Más detalles

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del

A continuación se describe con mayor detalle cada una de las unidades: UNIDAD 2: Calidad en el desarrollo, adquisición, operación y mantenimiento del 1. OBJETIVOS: Incorporar los conceptos de indicador, métrica, medida, escala de medición, y proceso de medición. Entender la importancia de los indicadores de desempeño de procesos, su medición y seguimiento.

Más detalles

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

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

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

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

GUÍA PRÁCTICA DE GESTIÓN DE REQUISITOS LNCS

GUÍA PRÁCTICA DE GESTIÓN DE REQUISITOS LNCS GUÍA PRÁCTICA DE GESTIÓN DE REQUISITOS Diciembre 2008 AVISO LEGAL CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon. Las distintas normas ISO mencionadas

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

Resumen. Introducción

Resumen. Introducción Arquitectura de software para Sistemas de Información Ambiental Urciuolo Adriana, Iturraspe Rodolfo, Parson Ariel, Esteban Natalia Universidad Nacional de la Patagonia San Juan Bosco Sede Ushuaia, Darwin

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

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

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software E-ISSN: 1885-4486 reicis@ati.es Asociación de Técnicos de Informática España Mesquida, Antoni Lluís; Mas, Antònia; Amengual, Esperança;

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

Guía Docente Curso 2012-2013

Guía Docente Curso 2012-2013 ESCUELA TÉCNIICA SUPERIIOR DE IINGENIIERÍÍA Guía Docente Curso 2012-2013 Titulación Ingeniería Informática DATOS DE LA ASIGNATURA * * Asignatura en experiencia piloto de implantación del sistema de créditos

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

1. Técnicas de recolección de información. 2. Identificación de requerimientos. 5. Introducción del método orientado a objetos en el análisis

1. Técnicas de recolección de información. 2. Identificación de requerimientos. 5. Introducción del método orientado a objetos en el análisis Contenido INGENIERIA DE SOFTWARE Tema 3: Ingeniería de Requisitos Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca dtorres@mixteco.utm.mx IEC 37 1. Técnicas de recolección de información

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

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas CÓDIGO ASIGNATURA 1131-2 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas ASIGNATURA: Proceso Software Proceso Software 1. OBJETIVOS Marco referencial El rol del curso Proceso Software es el de

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

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

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

Estándares Internacionales

Estándares Internacionales Estándares Internacionales M. en C. Mario Farías-Elinos Quality management has just become too important to leave to chance Philip Crosby 1 Contenido Estándares ISO para el Software Estándares IEEE para

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

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas CÓDIGO ASIGNATURA 633 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas ASIGNATURA: Proceso de Software Proceso de Software Año: 2010 Cuatri: 2º 1. OBJETIVOS Marco referencial El rol del curso Proceso

Más detalles

Conceptos de mejoras de procesos Estándares, y modelos de evaluación y mejora de los procesos de software

Conceptos de mejoras de procesos Estándares, y modelos de evaluación y mejora de los procesos de software La calidad como valor agregado al desarrollo de productos de software Temas Conceptos de mejoras de procesos Estándares, y modelos de evaluación y mejora de los procesos de software ISO/IEC 15504 ISO/IEC

Más detalles

Estándar de Ingeniería de Software de la European Space Agency (ESA)

Estándar de Ingeniería de Software de la European Space Agency (ESA) Estándar de Ingeniería de Software de la European Space Agency (ESA) Sergio Ochoa M. Cecilia Bastarrica Contenidos Fases, actividades e hitos establecidos por el estándar. Conclusiones 2 1 Ciclo de Vida

Más detalles

UN SONDEO EN ESPAÑA SOBRE LA PRÁCTICA PROFESIONAL EN PROCESOS PARA PRUEBAS DE SOFTWARE

UN SONDEO EN ESPAÑA SOBRE LA PRÁCTICA PROFESIONAL EN PROCESOS PARA PRUEBAS DE SOFTWARE Taller sobre Pruebas en Ingeniería del Software PRIS 2006 UN SONDEO EN ESPAÑA SOBRE LA PRÁCTICA PROFESIONAL EN PROCESOS PARA PRUEBAS DE SOFTWARE Luis Fernández Sanz 1 *, Pedro José Lara Bercial 1 1: Departamento

Más detalles

Introducción a Rational Unified Process (RUP)

Introducción a Rational Unified Process (RUP) Qué es un Proceso de Desarrollo de SW? Introducción a Patricio Letelier letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) (UPV) - España Define Quién debe hacer Qué, Cuándo y

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

Elicitación y Especificación de Requerimientos No Funcionales para aplicaciones Web

Elicitación y Especificación de Requerimientos No Funcionales para aplicaciones Web Elicitación y Especificación de Requerimientos No Funcionales para aplicaciones Web Silvana del Valle Rojo, Alejandro Oliveros INTEC UADE, Lima 775, CABA, Argentina sdelvallerojo@uade.edu.ar, aoliveros@gmail.com

Más detalles

Propuesta de un Modelo para Especificar Requisitos de Software para Sistemas Sensibles al Contexto. Marisa Daniela Panizzi, Lucio Oscar Bravo

Propuesta de un Modelo para Especificar Requisitos de Software para Sistemas Sensibles al Contexto. Marisa Daniela Panizzi, Lucio Oscar Bravo Propuesta de un Modelo para Especificar Requisitos de Software para Sistemas Sensibles al Contexto Marisa Daniela Panizzi, Lucio Oscar Bravo Instituto de Investigación en Ingeniería de Software Experimental

Más detalles

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA).

MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). MODELOS DE PROCESO PARA LA INTEGRACIÓN DEL NEGOCIO UTILIZANDO SERVICE ORIENTED ARCHITECTURE (SOA). López, G. 1 ; Jeder, I. 1 ; Echeverría, A. 1 ; Fierro, P. (PhD.) 2 1. Laboratorio de Informática de Gestión

Más detalles

Departamento de Informática y Sistemas Facultad de Informática Campus Universitario de Espinardo Murcia Profesor: Juan Antonio López Quesada

Departamento de Informática y Sistemas Facultad de Informática Campus Universitario de Espinardo Murcia Profesor: Juan Antonio López Quesada Departamento de Informática y Sistemas Facultad de Informática Campus Universitario de Espinardo Murcia Profesor: Juan Antonio López Quesada Índice de contenidos 1.- El proceso software 2.- Estándares

Más detalles

Capability Maturity Model Integration CMMI - Overview I

Capability Maturity Model Integration CMMI - Overview I Capability Maturity Model Integration CMMI - Overview I CAPIS Centro de Ingeniería del Software e Ingeniería del Conocimiento Junio 2004 Objetivo de la presentación Brindar una visión general del CMMI

Más detalles

Administración de Conocimiento como soporte al Mantenimiento de Software

Administración de Conocimiento como soporte al Mantenimiento de Software Administración de Conocimiento como soporte al Mantenimiento de Software Oscar M. Rodríguez 1, Ana I. Martínez 1, Jesús Favela 1, Aurora Vizcaíno 2 1 CICESE, Departamento de Ciencias de la Computación,

Más detalles

Mario G. Oloriz Maria Laura Lucchini. Módulos semanales 3 Días de dictado: L M M J V S 1 2

Mario G. Oloriz Maria Laura Lucchini. Módulos semanales 3 Días de dictado: L M M J V S 1 2 Técnico Superior en Análisis de Sistemas Plan 2003 Res: 281/03 PROGRAMA DE LA MATERIA: Sistemas de Información I 7213 Area: SISTEMAS Módulos semanales 3 Días de dictado: L M M J V S 1 2 Equipo Docente

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

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

Fundamentos de Ingeniería del Software. Capítulo 6. El proceso del software

Fundamentos de Ingeniería del Software. Capítulo 6. El proceso del software Fundamentos de Ingeniería del Software Capítulo 6. El proceso del software Cap. 6. El proceso del software. Estructura 1. El proceso software 2. Estándares en ingeniería del software Utilidad de los estándares

Más detalles

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE

PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE CIENCIAS POSTGRADO EN CIENCIAS DE LA COMPUTACIÓN PROGRAMA DE LA ASIGNATURA CURSO BASICO: ARQUITECTURA DEL SOFTWARE INFORMACIÓN GENERAL Profesor: Francisca Losavio

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

Estudio de métricas para el control de proyectos software

Estudio de métricas para el control de proyectos software Estudio de métricas para el control de proyectos software Concepción Presedo Dept. de Lenguajes y Sistemas Informáticos EUITI Bilbao UPV/EHU 48012 Bilbao conchi.presedo@ehu.es J. Javier Dolado Dept. de

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

Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico

Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico Desarrollo de un ciclo de mejora Construcción de un método de diagnóstico Alicia Mon, Marcelo Estayno, Andrea Arancio {aliciamon, mestayno, andrea.arancio}@fibertel.com.ar G.I.S. UNLaM 1 Resumen. Las pequeñas

Más detalles

PROGRAMA CONTENIDOS. Laudon, Kenneth C. y Laudon, Jane P. - SISTEMAS DE INFORMACIÓN GERENCIAL Editorial Prentice Hall, sexta edición 2002.

PROGRAMA CONTENIDOS. Laudon, Kenneth C. y Laudon, Jane P. - SISTEMAS DE INFORMACIÓN GERENCIAL Editorial Prentice Hall, sexta edición 2002. PROGRAMA 1) OBJETIVOS DE LA ASIGNATURA Que el Estudiante forme su criterio profesional integrando los conocimientos y experiencia práctica necesarios para poder construir e implementar un Sistema de Información

Más detalles

SW-CMM (CMM for Software)

SW-CMM (CMM for Software) Sinopsis de los modelos SW-CMM y CMMI Juan Palacio 1.0 Abril - 2006 Síntesis de los modelos de procesos CMM y CMMI para desarrollo y mantenimiento de software. CMMI (y previamente CMM) puede emplearse

Más detalles

Administración de Proyectos

Administración de Proyectos Administración de Proyectos Año 2010 Carrera: Magister en Ingeniería de Software Duración: Cuatrimestral Profesor a Cargo: A. Oliveros Hs. semanales : 3 OBJETIVOS GENERALES: Identificar, analizar y establecer

Más detalles

Estimando completitud en Ingeniería de Requisitos

Estimando completitud en Ingeniería de Requisitos Estimando completitud en Ingeniería de Requisitos Marcela Ridao, Jorge H. Doorn INTIA, Facultad de Ciencias Exactas Univ. Nacional del Centro de la Provincia de Buenos Aires email: {mridao, jdoorn}@exa.unicen.edu.ar

Más detalles

Definición de un Proceso de Implantación de Sistemas

Definición de un Proceso de Implantación de Sistemas Definición de un Proceso de Implantación de Sistemas Alicia Mon, Marcelo Estayno, Fernando López Gil, Eduardo De María 1 1 Grupo de Ingeniería de Software (G.I.S.) / Departamento de Sistemas / Universidad

Más detalles

Universidad Ricardo Palma Facultad de Ingeniería

Universidad Ricardo Palma Facultad de Ingeniería Universidad Ricardo Palma Facultad de Ingeniería Escuela Académico Profesional de Ingeniería Informática Sílabo Plan de Estudios 2006-II I. DATOS GENERALES Curso : Calidad de Código : IF 0905 Ciclo : IX

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

Tape Mbo e: una Metodología Orientada a Servicios

Tape Mbo e: una Metodología Orientada a Servicios Tape Mbo e: una Metodología Orientada a Servicios Motivación Objetivos Tecnología Estado del Arte Evaluación del Estado del Arte Tape Mb e Ciclo de Vida Roles Disciplinas Ciclo de Vida y Disciplinas Evaluación

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

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

GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática. Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso

GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática. Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso Año académico 2014-15 GUÍA DOCENTE INGENIERÍA DEL SOFTWARE Grado en Ingeniería Informática Profesorado: Juan Manuel Gimeno Illa Montserrat Sendin Veloso Información general de la asignatura Denominació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

Temas de investigación y desarrollo

Temas de investigación y desarrollo Componentes de Dominio para Sistemas de Información Ambiental Urciuolo Adriana, Iturraspe Rodolfo, Moyano Ezequiel, Rosanigo Beatriz, Parson Ariel, Villarreal Martín urciuolo@tdfuego.com, iturraspe@tdfuego.com,

Más detalles

Diagrama de casos de uso

Diagrama de casos de uso Diagrama de casos de uso Se utiliza para capturar los requerimientos funcionales de un sistema, de tal forma que plasman las relaciones entre los usuarios y el sistema. Contenido Pasos de construcción

Más detalles

Requerimientos No funcionales para aplicaciones Web

Requerimientos No funcionales para aplicaciones Web Requerimientos No funcionales para aplicaciones Web Silvana del Valle Rojo, Alejandro Oliveros INTEC UADE, Lima 717, CABA, Argentina {Sdelvallerojo,aoliveros}@uade.edu.ar Abstract. Las necesidades particulares

Más detalles

GESTIÓN AUTOMATIZADA DE REQUISITOS DE SEGURIDAD EN PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN

GESTIÓN AUTOMATIZADA DE REQUISITOS DE SEGURIDAD EN PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN GESTIÓN AUTOMATIZADA DE REQUISITOS DE SEGURIDAD EN PROYECTOS DE DESARROLLO DE SISTEMAS DE INFORMACIÓN Daniel Mellado Fernández Oficina de Gestión de Proyectos Centro de Desarrollo del INSS. Gerencia de

Más detalles

ESPECIFICACIÓN Y TRAZABILIDAD DE REQUERIMIENTOS EN EL DESARROLLO DE APLICACIONES WEB

ESPECIFICACIÓN Y TRAZABILIDAD DE REQUERIMIENTOS EN EL DESARROLLO DE APLICACIONES WEB ESPECIFICACIÓN Y TRAZABILIDAD DE REQUERIMIENTOS EN EL DESARROLLO DE APLICACIONES WEB Ferraro, Maria de los Angeles a ; Medina, Yanina a* ; Dapozo, Gladys a ; Estayno, Marcelo b a Facultad de Ciencias Exactas

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

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

Ingeniería y Arquitectura. Duración: 4 Semestres. Magíster en Gestión de Proyectos Informáticos

Ingeniería y Arquitectura. Duración: 4 Semestres. Magíster en Gestión de Proyectos Informáticos Página 1 de 4 Universidad de Pamplona Facultad Ingeniería y Arquitectura Nombre del programa Maestría en Gestión de Proyectos Informáticos Modalidad: Presencial Duración: 4 Semestres Título obtenido o

Más detalles

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA

PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA INGENIERÍA INFORMÁTICA Grupo de Investigación y Desarrollo en Ingeniería de Software Normas de la Calidad del Producto Software

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

Verificación. 3.1 Marco de Referencia para el desarrollo de software

Verificación. 3.1 Marco de Referencia para el desarrollo de software Verificación 3.1 Marco de Referencia para el desarrollo de software Verificación es la acción de verificar (comprobar o examinar la verdad de algo). La verificación suele ser el proceso que se realiza

Más detalles

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas

DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas CÓDIGO ASIGNATURA 1126 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas ASIGNATURA: Ingeniería de Software Ingeniería en Informática Año: 5º Cuatri: 1 y 2 1. OBJETIVOS La materia Ingeniería de Software

Más detalles

Estándares de Calidad para el Desarrollo y Mantenimiento de Software

Estándares de Calidad para el Desarrollo y Mantenimiento de Software Estándares de Calidad para el Desarrollo y Mantenimiento de Software Dr. Marcelo Jenkins C. Escuela de Computación n e Informática Universidad de Costa Rica San Pedro, Costa Rica Tel: : (506) 207-4020

Más detalles

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Lornel A. Rivas 1,2, María Pérez 2, Luis E. Mendoza 2, y Anna Grimán 2 1 Gerencia de Investigación, Instituto Nacional de

Más detalles

Producción del LEL en un Dominio Técnico. Informe de un caso.

Producción del LEL en un Dominio Técnico. Informe de un caso. 54 WER2000 Producción del LEL en un Dominio Técnico. Informe de un caso. Gustavo D. Gil a, Daniel Arias Figueroa a, Alejandro Oliveros b a L.I.D.T.I. - Laboratorio de Investigación y Desarrollo en Tecnologías

Más detalles

DEOs para el LEL. Lista de Fuentes de Información. Modelo de Escenarios Heurísticas. Construir las Tarjetas CRC 3. Derivar Objetos

DEOs para el LEL. Lista de Fuentes de Información. Modelo de Escenarios Heurísticas. Construir las Tarjetas CRC 3. Derivar Objetos Comprendiendo el Universo de Discurso Futuro con Jorge H. Doorn 1,2, Graciela D.S. Hadad 2,3, Gladys N. Kaplan 2,3 1 Universidad del Centro de la Provincia de Buenos Aires - INTIA Pinto 399 (7000) Tandil,

Más detalles

La usabilidad en los estándares internacionales relacionados con calidad: definición, logro y evaluación. Año 2015

La usabilidad en los estándares internacionales relacionados con calidad: definición, logro y evaluación. Año 2015 La usabilidad en los estándares internacionales relacionados con calidad: definición, logro y evaluación Año 2015 Docente Responsable: Dr. Francisco Montero. (UCLM-España) Docente Asistente: Dra. María

Más detalles

Pontificia Universidad Católica del Ecuador

Pontificia Universidad Católica del Ecuador 1. DATOS INFORMATIVOS: MATERIA O MÓDULO: INGENIERÍA DE SOFTWARE I CÓDIGO: CARRERA: SISTEMAS NIVEL: QUINTO No. CRÉDITOS: 4 CRÉDITOS TEORÍA: 4 SEMESTRE/AÑO ACADÉMICO: Segundo Semestre 2011-2012 CRÉDITOS

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

Diseño e Implementación de un Sistema de Administración de la Calidad del Software para una Institución Financiera

Diseño e Implementación de un Sistema de Administración de la Calidad del Software para una Institución Financiera Diseño e Implementación de un Sistema de Administración de la Calidad del para una Institución Financiera Marcelo Jenkins Escuela de Ciencias de la Computación e Informática Universidad de Costa Rica San

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

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

Heurísticas para el modelado de requisitos escritos en lenguaje natural

Heurísticas para el modelado de requisitos escritos en lenguaje natural Heurísticas para el modelado de requisitos escritos en lenguaje natural Claudia Litvak 1, Graciela Hadad 1,2, Jorge Doorn 1,2 1 DIIT, Universidad Nacional de La Matanza, Argentina 2 Escuela de Informática,

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

ORGANIZACIÓN DOCENTE del curso 2009-10

ORGANIZACIÓN DOCENTE del curso 2009-10 ORGANIZACIÓN DOCENTE del curso 2009-10 1. DATOS GENERALES DE LA ASIGNATURA NOMBRE Ingeniería del Software II PÁGINA WEB www.ctr.unican.es/asignaturas/is2 CÓDIGO DEPARTAMENTO Matemáticas, Estadística y

Más detalles

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más)

Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Encuesta Perfil de Egreso del Ingeniero en Computación y/o Informática en Chile (Para programas de 10 semestres o más) Nombre del Encuestado e-mail Nombre de la Carrera Universidad Unidad Académica Sede

Más detalles

Tema 8º: Aspectos prácticos

Tema 8º: Aspectos prácticos Tema 8º: Aspectos prácticos Gestión y planificación Administración de personal Gestión de versiones Reutilización Control de calidad del software Documentación Herramientas Temas especiales Las ventajas

Más detalles

ARMONIZACIÓN DE MODELOS DE CALIDAD DEL SOFTWARE

ARMONIZACIÓN DE MODELOS DE CALIDAD DEL SOFTWARE DESDE LA ACADEMIA ARMONIZACIÓN DE MODELOS DE CALIDAD DEL SOFTWARE GABRIEL ALBERTO GARCÍA MIRELES, FÉLIX ÓSCAR GARCÍA RUBIO La tendencia actual entre las organizaciones que desarrollan software es la adopción

Más detalles

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Evaluación asistida de CMMI-SW

Evaluación asistida de CMMI-SW Evaluación asistida de CMMI-SW Peralta, M.; Diez, E.; Britos, P. y García Martínez, R. 1 Centro de Ingeniería del Software e Ingeniería del Conocimiento (CAPIS) Escuela de Postgrado. Instituto Tecnológico

Más detalles

Business Intelligence & Knowledge Discovery en el contexto del estándar Project Management Body Of Knowledge del Project Management Institute

Business Intelligence & Knowledge Discovery en el contexto del estándar Project Management Body Of Knowledge del Project Management Institute Business Intelligence & Knowledge Discovery en el contexto del estándar Project Management Body Of Knowledge del Project Management Institute Moreno, Juan Pablo 1 ; Montejano, Germán 2 ; Vilallonga, Gabriel

Más detalles

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Posgrado en Ciencias y Tecnologías de la Información Marzo del 2012. 1. Responsables Dra. Angelina

Más detalles

ASISTENCIA AUTOMÁTICA EN CERTIFICACIÓN BASADO EN EL ESTÁNDAR ISO 9001:2000

ASISTENCIA AUTOMÁTICA EN CERTIFICACIÓN BASADO EN EL ESTÁNDAR ISO 9001:2000 ASISTENCIA AUTOMÁTICA EN CERTIFICACIÓN BASADO EN EL ESTÁNDAR ISO 9001:2000 Proyecto de tesis de Alumno: Licenciado Carlos G. Rivero Bianchi Director: M. lng. Paola Britos Radicación: Centro de Ingeniería

Más detalles