resumen parcial de ingeniera de requerimientos .pdf

parcial 1 INGENIERIA DE REQUERIMIETOS el software en el tiempo ·En 1935 alan Turing dio la idea del software como programa de una computadora ·En 1958 john tukey, dice que el software es un conjunto de partes interrrelaciona...

parcial 1 INGENIERIA DE REQUERIMIETOS el software en el tiempo ·En 1935 alan Turing dio la idea del software como programa de una computadora ·En 1958 john tukey, dice que el software es un conjunto de partes interrrelacionadas que alcanzan algún objetivo. ·Reducir al software a programas es una simplificación válida para una computadora pero no para quienes lo van a construir. ¿Qué es el software? Alma y cerebro de una computadora: El software es lo que le permite a una computadora hacer algo útil. Sin software, una computadora es solo un conjunto de hardware sin funcionalidad. Corporización de las funciones de un sistema: El software define y realiza las funciones que un sistema debe llevar a cabo, transformando los objetivos en acciones. Conocimiento capturado: El software encapsula el conocimiento sobre una tarea o área de aplicación, transformándolo en acciones automáticas que la computadora puede realizar. Colección de programas y datos: Es una colección de programas y datos que transforman una computadora, diseñada para cualquier propósito, en una máquina capaz de realizar tareas específicas, como manejar una base de datos o jugar un videojuego. Información generada durante el desarrollo: El software también incluye toda la información (como la documentación) que se produce durante su desarrollo, desde los requisitos hasta los manuales de usuario. semantica Definir "software" es importante: Si decimos que el software son solo los programas ejecutables (los que podemos usar), estamos dejando fuera mucha información importante que también forma parte del proceso de creación del software. Por ejemplo, los documentos de diseño, las pruebas, y otros detalles que ayudan a crear el programa. Incluir toda la información relevante: Si consideramos que todo lo que está relacionado con el software (como la documentación, el código fuente, las pruebas) también es parte de él, debemos tratar esa información con la misma atención y cuidado que ponemos en el programa ejecutable. Es decir, debemos gestionarla de forma organizada y rigurosa. Es crucial para evitar errores: Si no cuidamos esta información extra con el mismo rigor, se puede perder o cambiar de manera incorrecta, y eso puede introducir errores en el desarrollo del software, afectando el resultado final. 1.  parcial 1 INGENIERIA DE REQUERIMIETOS representación del software son todas las formas en que se presenta o describe un programa y los datos asociados. Estas representaciones incluyen diferentes tipos de información que ayudan a entender y construir el software, no solo el programa final. Incluyen: 1. Programas: El código ejecutable que realiza las funciones del software. 2. Diseños detallados: Descripciones precisas de cómo funciona cada parte del software. 3. Diseños de arquitectura: Diagramas que muestran la estructura general del sistema, cómo se organiza y cómo interactúan sus componentes. 4. Especificaciones formales: Descripciones del comportamiento del software escritas en lenguajes especializados para ser muy precisas. 5. Requerimientos del sistema: Lo que el sistema debe hacer, expresado en diferentes formatos o lenguajes. Conocimiento de ingeniería de software. se refiere a toda la información que ayuda a desarrollar software de manera eficiente y efectiva. Este conocimiento puede ser general, aplicable a cualquier proyecto, o específico de un desarrollo en particular. Incluye: Información sobre el proyecto: Detalles específicos de un proyecto de software en particular, como los requisitos, el cronograma, el equipo, y los problemas enfrentados. Tecnología de software: Métodos, conceptos y técnicas que se usan para desarrollar software, como metodologías ágiles, patrones de diseño, o técnicas de programación. Conocimiento sobre sistemas similares: Lecciones aprendidas o detalles sobre sistemas previos que se parecen al que se está desarrollando, lo que puede ayudar a resolver problemas o tomar decisiones informadas. Solución de problemas técnicos: Información detallada sobre cómo identificar y resolver problemas específicos del sistema que se está desarrollando. Ejemplos de formas que toma el software. son todas las representaciones e información que se generan durante su ciclo de vida, desde la idea inicial hasta su uso final. 2.  parcial 1 INGENIERIA DE REQUERIMIETOS software como producto Al principio, el software no se veía como un producto: Cuando las computadoras comenzaron a usarse, se les veía solo como máquinas que procesaban información (símbolos, números, etc.). El software, que es lo que les dice a las computadoras qué hacer, no era considerado un "producto" que pudiera venderse o distribuirse de forma independiente. A partir de los años 60, el software empezó a ser visto como un producto: En esa época, el hardware (la parte física de la computadora) y el software (los programas) se separaron. Esto permitió que el software comenzara a considerarse como algo que podía venderse o comprarse por sí solo, sin estar ligado al hardware. El software es más que solo un producto, es conocimiento empaquetado: Cuando hablamos de software, no solo nos referimos a algo que se puede vender, sino que también es una forma de empaquetar conocimiento técnico. Los programas que usas están llenos de conocimientos, fórmulas y procesos que los desarrolladores han creado y puesto en un formato que las computadoras pueden entender. software como conocimiento 1. Los programas tienen conocimiento dentro: Cada programa está hecho a partir de ideas, soluciones y técnicas que los programadores han desarrollado, es decir, contienen "conocimiento". 2. El programa que usas (el ejecutable) es solo el final de todo el proceso: Para llegar a ese programa que puedes usar, los programadores pasan por varias etapas, como planificación, diseño y codificación. Todo ese proceso también tiene conocimiento. 3. Las versiones finales también contienen conocimiento: Incluso en su forma final (el programa listo para usar), sigue habiendo conocimiento técnico detrás de cómo funciona. 4. Limitarse solo a usar el programa final es perder mucho del conocimiento que lo creó: Si solo pensamos en el software como el programa que ejecutamos, perdemos todo el entendimiento de cómo y por qué fue hecho de cierta manera. Reutilizar software ayuda a no perder ese conocimiento: Si guardamos y reutilizamos las ideas y componentes de un software, no solo ahorramos tiempo, sino que también preservamos el conocimiento que se usó para crearlo. El software es como un informe de investigación: Al igual que un informe documenta conocimiento, el software encapsula y refleja el conocimiento de los programadores y desarrolladores. 3.  parcial 1 INGENIERIA DE REQUERIMIETOS software unico Es intangible: A diferencia de los productos físicos, no puedes ver ni tocar el software. Esto hace que sea más difícil de controlar, medir y gestionar. Alto contenido intelectual: El software está compuesto principalmente de ideas, lógica y soluciones a problemas, lo que significa que su valor reside en el conocimiento y creatividad de quienes lo desarrollan. No se reconoce como un activo contable: Aunque tiene mucho valor, no siempre se lo considera como un activo físico o contable en la misma manera que un edificio o una máquina. Mano de obra intensiva: El desarrollo de software requiere mucho trabajo humano. Los proyectos de software dependen de equipos que colaboran, y esto complica la comunicación y coordinación, lo que puede generar problemas en los proyectos. No hay separación entre I+D y producción: En la fabricación de productos físicos, primero se investiga y se diseña (Investigación y Desarrollo, o I+D), y luego se produce en masa. En el software, no existe esa distinción clara: la investigación, el diseño y la producción están muy entrelazados. Modificable hasta el infinito: El software puede cambiarse y actualizarse casi indefinidamente. Si bien esto es una ventaja, también crea desafíos para mantener y evolucionar el software, especialmente una vez que ha sido liberado. software como conocimiento 1. Objetivo de la ingeniería: El objetivo general de la ingeniería es construir productos físicos. Por ejemplo, en la ingeniería civil, se construyen edificios, puentes, etc. 2. Objetivo de la Ingeniería de Software: En la ingeniería de software, el objetivo es construir sistemas de software. Esto implica crear no solo el código, sino también el diseño, la documentación y todos los aspectos que componen un sistema de software. 3. Diferencia principal - Maleabilidad: A diferencia de los productos físicos, el software es maleable (puede ser modificado fácilmente). Esto significa que se pueden hacer cambios y ajustes en el software de manera más flexible. 4. Cambio en el software - Idea errónea: Hay una idea errónea de que hacer cambios en el software es fácil. En realidad, cambiar el software no es solo modificar el código, sino que a menudo requiere una revisión del diseño y puede ser complicado. 5. Cambio como diseño, no solo código: En lugar de ver un cambio en el software simplemente como una modificación del código, debe verse como un cambio en el diseño del sistema. Esto es porque el diseño y la implementación están profundamente entrelazados. 6. Producción humano-intensiva: El desarrollo de software requiere mucho trabajo humano y es más similar al diseño e implementación que a la manufactura de productos físicos. La ingeniería de software es más acerca de crear y perfeccionar el diseño que de ensamblar partes físicas. 7. Herramientas en la ingeniería clásica vs. ingeniería de software: En la ingeniería clásica, los ingenieros tienen herramientas para describir y analizar productos que son diferentes de los productos mismos (como planos y 4. modelos). En la ingeniería de software, las herramientas para describir el software (como diagramas y documentación) están mucho más integradas con el producto final.  parcial 1 INGENIERIA DE REQUERIMIETOS cualidades del software Estas son las cualidades clave que el software debe cumplir para ser efectivo y útil: 1. Corrección Funcional: El software debe comportarse de acuerdo con las especificaciones de los requerimientos funcionales, es decir, debe hacer lo que se espera que haga según lo definido. 2. Confiabilidad: El software debe ser confiable, lo que significa que los usuarios deben poder depender de él para realizar sus tareas sin fallos inesperados. 3. Robustez: El software debe comportarse de manera razonable incluso en situaciones que no estaban previstas en los requerimientos, manejando errores o condiciones excepcionales de manera adecuada. 4. Performance: También conocida como eficiencia, se refiere al uso económico de los recursos de computación. El software debe funcionar de manera rápida y eficaz sin desperdiciar recursos. 5. Amistosidad: El software debe ser fácil de usar para las personas. Esto significa que la interfaz y la experiencia del usuario deben ser intuitivas y amigables. 6. Verificabilidad: Las propiedades y el comportamiento del software deben poder ser comprobados fácilmente para asegurar que cumple con los requisitos y estándares. 7. Mantenibilidad: El software debe ser fácil de reparar y actualizar. Debe poder evolucionar para adaptarse a nuevas necesidades o corregir errores. 8. Reusabilidad: Los componentes del software deben poder ser utilizados en otros sistemas o proyectos sin necesidad de modificaciones significativas. 9. Portabilidad: El software debe poder ejecutarse en diferentes entornos o plataformas sin necesidad de cambios importantes. 10. Comprensibilidad: El software y su documentación deben ser fáciles de entender para los desarrolladores y otros usuarios involucrados en su mantenimiento o uso. 11. Interoperatividad: El software debe ser capaz de trabajar y cooperar con otros sistemas, facilitando la integración y el intercambio de datos. 12. Productividad: Esta cualidad mide la eficiencia del proceso de desarrollo del software, incluyendo cuánto tiempo y recursos se necesitan para producir el software. 13. Oportunidad: El software debe ser liberado en el tiempo previsto. La puntualidad en la entrega es crucial para cumplir con los plazos y expectativas. 14. Visibilidad: Los pasos previos en el desarrollo del software y su estado actual deben estar bien documentados, permitiendo a los desarrolladores y otras partes interesadas seguir y entender el progreso. 5.  parcial 1 INGENIERIA DE REQUERIMIETOS cualidades internas Visibilidad: Solo los desarrolladores pueden ver y medir estas cualidades. Importancia: Estas cualidades afectan directamente la estructura y el diseño del software, facilitando o dificultando el cumplimiento de las cualidades externas. Ejemplos: Verificabilidad: Facilita la confiabilidad del software. Mantenibilidad: Permite que el software sea fácilmente actualizado y reparado. Reusabilidad: Permite que componentes del software sean reutilizados en otros proyectos. Comprensibilidad: Facilita el entendimiento y el trabajo con el código por parte de los desarrolladores. cualidades externas Visibilidad: Son perceptibles para los usuarios finales y otros interesados en el uso del software. Importancia: Estas cualidades afectan la experiencia del usuario y la percepción del software. Ejemplos: Corrección Funcional: El software cumple con las especificaciones y resuelve el problema del usuario. Confiabilidad: El usuario puede confiar en que el software funcionará correctamente. Robustez: El software maneja bien situaciones inesperadas o errores. Amistosidad: El software es fácil de usar y accesible para los usuarios finales. relación entre cualidades externas e internas Interdependencia: Las cualidades internas son fundamentales para lograr cualidades externas efectivas. Por ejemplo, la verificabilidad (una cualidad interna) es crucial para asegurar la confiabilidad (una cualidad externa). No siempre directamente relacionadas: Aunque hay una relación, las cualidades externas no siempre son un reflejo directo de las cualidades internas. La calidad del software visto por los usuarios finales no es exclusivamente consecuencia de la estructura interna del software. 6.  parcial 1 INGENIERIA DE REQUERIMIETOS intereses de cualidades Usuario Final: Intereses: El usuario final se enfoca en que el software sea correcto, confiable, robusto, y fácil de usar. Cualidades Relevantes: Corrección funcional, confiabilidad, robustez, amistosidad. Ingeniero de Software/Desarrollador: Intereses: El ingeniero se preocupa por cómo el software puede ser reutilizado, mantenido, y verificado, además de cómo interactúa con otros sistemas. Cualidades Relevantes: Reusabilidad, portabilidad, comprensibilidad, interoperatividad, verificabilidad, mantenibilidad. Project Manager: Intereses: El project manager se enfoca en la eficiencia del proceso de desarrollo y la gestión del proyecto. Cualidades Relevantes: Productividad, visibilidad, oportunidad. EL SOFTWARE Y LA DESECONOMÍA DE ESCALA El costo de hacer software crece más rápido de lo que imaginamos: Cuando hacemos software, no es tan simple como decir que si un proyecto es 10 veces más grande, costará 10 veces más. ¡No funciona así en el software!  El problema está en la comunicación: Cuanto más grande es un proyecto, más personas se necesitan para hacerlo. El problema es que, con más personas, también aumenta la cantidad de comunicación que tiene que haber entre ellas. Si tienes 2 personas, hay 1 vía de comunicación entre ellas. Si añades una tercera persona, ya tienes 3 vías de comunicación. Con 4 personas, sube a 6 vías. Cuanto más gente agregues, ¡mucho más crecen las vías de comunicación!  Crecimiento exponencial: Este crecimiento de las vías de comunicación no es lineal, sino exponencial. Eso significa que no crece de manera proporcional al número de personas, sino mucho más rápido.  Esto causa más esfuerzo en proyectos grandes: Cuando los proyectos de software se hacen más grandes, el esfuerzo para coordinarlos y completarlos aumenta mucho más de lo que uno pensaría. No solo porque hay más trabajo que hacer, sino porque la gente tiene que comunicarse más, resolver más problemas, y eso toma tiempo y esfuerzo.  Deseconomía de escala en software: Fuera del mundo del software, solemos hablar de economías de escala, donde si haces algo a mayor escala (como una fábrica más grande), el costo por unidad baja. Pero en el software, pasa lo contrario: deseconomía de escala. Cuanto más grande es un proyecto, más cuesta hacer cada parte, porque la complejidad y la comunicación aumentan. 7.  parcial 1 INGENIERIA DE REQUERIMIETOS proceso definición IEEE IEEE: “Una secuencia de pasos ejecutados para un propósito dado.” Componentes Clave: Secuencia de Pasos: Un conjunto ordenado de actividades o tareas. Propósito: El objetivo que se busca lograr con el proceso. Prácticas: Se ajusta a las prácticas específicas de diferentes campos de la ingeniería. Pfleeger: “Podemos pensar al conjunto ordenado de tareas como un proceso: una serie de pasos que involucran actividades, restricciones y recursos que producen una determinada salida esperada.” Componentes Clave: Actividades: Tareas específicas que se deben realizar. Restricciones: Limitaciones que deben ser consideradas. Recursos: Herramientas, tiempo, y otros elementos necesarios. Salida Esperada: El resultado final o producto del proceso. Basili: Afirma que los procesos de ingeniería del software son específicos y claramente definidos, ya que el software como producto es único. Esto significa que los procesos utilizados para desarrollar software no son los mismos que los utilizados para fabricar productos físicos. aspectos clave Acciones y Propósito: Un proceso es una serie de pasos (acciones) que se ejecutan con un propósito específico. Estos pasos están diseñados para alcanzar un objetivo o producir un resultado esperado. Cualidades del Proceso: Estructura: Los procesos tienen una estructura ordenada que facilita la ejecución de tareas. Adaptabilidad: Los procesos deben ajustarse a las necesidades específicas de la ingeniería o el proyecto. Resultados: El proceso está orientado a producir un resultado o salida esperada, que puede ser un producto, un informe, un diseño, etc. Especificidad del Software: En ingeniería del software, los procesos son únicos y adaptados a la naturaleza del software. Los procesos para desarrollar software son diferentes de los utilizados en otras áreas de ingeniería debido a la naturaleza intangible y maleable del software. 8.  parcial 1 INGENIERIA DE REQUERIMIETOS El proceso en detalle (según Pfleeger) El proceso involucra muchas actividades: Un proceso está compuesto por distintas tareas o pasos que deben realizarse para lograr un objetivo. Uso de recursos y restricciones: Para llevar a cabo un proceso, necesitamos recursos (como tiempo, personas, tecnología) y debemos enfrentar restricciones. Por ejemplo, el equipo puede no estar capacitado para usar cierta tecnología, o no tener suficiente tiempo. Subprocesos encadenados: A veces, un proceso grande está compuesto por varios subprocesos más pequeños, que se relacionan entre sí de alguna manera. Entradas y salidas claras: Cada actividad dentro del proceso tiene criterios que deben cumplirse para empezar (entradas) y para terminar (salidas). Por ejemplo, antes de probar un programa, debe cumplir con ciertas condiciones y tener un diseño previo. Esto asegura que todo esté en orden antes de avanzar al siguiente paso. Secuencia de actividades: Las actividades se realizan en un orden específico, siguiendo una secuencia para lograr el objetivo final. Objetivos y principios guía: Cada actividad tiene un objetivo claro y principios que guían cómo debe realizarse. Restricciones: Las actividades y los productos que se generan están sujetos a restricciones (por ejemplo, tiempo, dinero, o requisitos técnicos). mapa conceptual del proceso Un proceso incluye varias actividades que se realizan en orden, y estas tienen guías para alcanzar sus objetivos. Las actividades generan productos intermedios (como avances parciales) y, al final, se produce un producto final. aplicación en el software Cuando desarrollamos software, seguimos un proceso que organiza todo en una secuencia de actividades. Esto incluye la generación de productos intermedios (como prototipos o versiones preliminares) y un producto final (el software terminado). El desarrollo de software sigue su propio proceso, llamado ciclo de vida de desarrollo de software, y dentro de este hay subprocesos, como la ingeniería de requerimientos. 9.  parcial 1 INGENIERIA DE REQUERIMIETOS ingeniería de requerimiento Es un subproceso del desarrollo de software. Se organiza en actividades que generan productos intermedios. Tiene criterios de entrada y salida. Utiliza recursos y enfrenta restricciones las dificultades esenciales en el software Dificultades Esenciales vs. Accidentales Esenciales: Inherentes a la naturaleza del software. Accidentales: Derivadas de cómo se desarrolla el software actualmente, pero no son inherentes a su esencia. Propiedades Inherentes a la Esencia del Software 1. Complejidad: Naturaleza: El software es extremadamente complejo, probablemente más que cualquier otra construcción humana. Escalabilidad: Aumentar el tamaño del software no es simplemente repetir los elementos en mayor escala. La complejidad aumenta de manera no lineal con el tamaño, lo que genera varios problemas: Dificultad de Comunicación: La complejidad dificulta la comunicación entre los miembros del equipo. Extensión: Ampliar el software con nuevas funciones es complicado y a menudo impredecible. Administración de Proyectos: La complejidad hace difícil mantener una visión global e integrar el software conceptual. Rotación de Personal: La alta complejidad requiere un profundo conocimiento, haciendo que la rotación de personal sea un desafío importante. 2. Conformidad: Naturaleza: El software debe adaptarse y conformarse a los sistemas y estándares existentes. Razones: Interfaz: Muchas veces, el software es el último en ser desarrollado, lo que significa que debe integrarse con sistemas y estándares existentes. Capacidad de Conformación: El software a menudo se percibe como el elemento que debe adaptarse a interfaces externas. 10.  parcial 1 INGENIERIA DE REQUERIMIETOS Propiedades Inherentes a la Esencia del Software 3. Modificabilidad: Naturaleza: El software está en constante cambio y evolución. Razones para Cambios: Funciones: Las funciones del software están bajo constante presión para adaptarse y cambiar. Manejabilidad: El software es muy maleable y puede ser modificado fácilmente. Evolución: El software exitoso a menudo se actualiza y expande con nuevas funciones, y debe sobrevivir a cambios en el hardware y el entorno para el que fue originalmente diseñado. Contexto Cultural: El software está integrado en un contexto cultural que incluye aplicaciones, usuarios, leyes y máquinas, todos los cuales cambian y afectan al software. 4. Invisibilidad: Naturaleza: El software no tiene una representación física o geométrica como los mapas de la tierra o los diagramas de circuitos. Representaciones: El software se representa a través de diagramas que muestran: Flujo de Control Flujo de Datos Patrones de Dependencia Secuencia de Tiempo Relaciones Nombre-Espacio Problemas: Limitaciones Cognitivas: La invisibilidad del software impide el uso completo de herramientas cognitivas y la comprensión intuitiva. Comunicación: Dificulta la comunicación entre desarrolladores, ya que no se puede visualizar fácilmente el estado o la estructura del software. Impacto en el Desarrollo de Software Comprensión del Trabajo: Cómo entendemos lo que se nos pide hacer. Definición del Trabajo: Qué necesitamos hacer para cumplir con los requerimientos. Volatilidad: La inestabilidad de los requerimientos y cómo estos cambian. Visualización: La dificultad de visualizar el producto final y su estructura. 11  parcial 1 INGENIERIA DE REQUERIMIETOS Dificultades esenciales en el desarrollo de software Cuando desarrollamos software, enfrentamos dos tipos de dificultades: Las inherentes al desarrollo de software: Estas son las complejidades que siempre estarán presentes. Por ejemplo, entender bien lo que el cliente quiere o cómo debe funcinar el sistema. Problemas de representación o modelo: Aquí hablamos de cómo representamos el software o los sistemas en nuestra mente o en documentos antes de escribir el código. Estos modelos pueden ser inexactos o difíciles de entender. ¿Qué es un modelo? Un modelo es una representación simplificada de algo, hecha para ayudarnos a visualizar o entender un sistema. Aquí algunos ejemplos: Una copia pequeña y exacta: Como una maqueta de un avión en aeromodelismo. Es similar al original, pero más pequeño y más barato de hacer. Una descripción o analogía: Como un dibujo o un gráfico que nos ayuda a visualizar algo que no podemos ver directamente, como el flujo de datos en una app. Un plan o patrón: Como los planos de una casa, que te indican cómo construirla. Una proyección teórica: Es un modelo que representa algo que aún no existe, pero queremos construir, como el diseño de un nuevo software. ¿Para qué hacemos modelos en software? Los modelos se construyen por dos razones principales: Representar la realidad: Hacemos modelos para entender cómo es o cómo funciona algo que ya existe. Planificar una construcción: A partir de un modelo, creamos un nuevo artefacto o sistema, como un software que aún no existe. 12  parcial 1 INGENIERIA DE REQUERIMIETOS Sustancia del proceso de desarrollo de software (según Blum) Blum describe el proceso de desarrollo de software en tres pasos: Modelo conceptual: Es una idea general de la solución al problema. No es muy preciso, pero nos da una visión inicial. Modelo formal: A partir del modelo conceptual, lo formalizamos para que sea más preciso. Aquí podemos verificar si las soluciones que hemos propuesto son correctas. Implementación: Finalmente, construimos el software siguiendo el modelo formal. La implementación es el código que finalmente satisface las especificaciones del modelo. La dificultad para obtener los requerimientos Fred Brooks (en su ensayo No Silver Bullet) señala que la parte más difícil de construir un sistema de software es decidir exactamente qué debe hacer. Es decir, definir los requerimientos. Los requerimientos son las funciones, características y expectativas que el sistema debe cumplir. ¿Por qué es tan complicado? Lo más difícil del trabajo conceptual: Entender qué necesita el usuario y traducirlo en requerimientos detallados es la parte más difícil del desarrollo de software. Errores en los requerimientos tienen un gran impacto: Si se malinterpretan los requerimientos o se omite algo, el sistema entero puede salir mal y, peor aún, corregir esos errores más tarde es muy costoso y complicado El reto de obtener el conocimiento El problema principal es capturar el conocimiento que tienen los usuarios y expertos sobre lo que el software debe hacer. Esto se complica porque: A veces los usuarios no pueden explicar claramente lo que necesitan. Los expertos humanos pueden tener dificultades para transmitir su conocimiento de una manera que los desarrolladores puedan entender. 13.  parcial 1 INGENIERIA DE REQUERIMIETOS Requerimientos y contexto organizacional Los requerimientos solo tienen sentido si se entienden dentro del contexto de la organización. Esto significa que los desarrolladores deben conocer cómo funciona la empresa, sus procesos y necesidades. Los requerimientos surgen de la interacción entre los usuarios y los técnicos. Problemas con los usuarios Los usuarios, que son quienes usan el software, presentan varios desafíos al definir requerimientos: Falta de consenso: A veces, diferentes usuarios tienen distintas ideas sobre lo que el software debe hacer. Tiempo limitado: Los usuarios pueden no tener suficiente tiempo para participar en el proceso de definir los requerimientos. Problemas de comunicación: A veces es difícil para los usuarios explicar exactamente lo que quieren. Problemas de poder político: Dentro de la organización, puede haber conflictos sobre qué funciones son más importantes o deben ser prioritarias. Problemas entre usuarios y desarrolladores La comunicación entre usuarios y desarrolladores puede ser complicada: Diferencias de lenguaje: Los usuarios hablan en términos de negocio, mientras que los desarrolladores piensan en términos técnicos. Esto genera malentendidos. Diferencias de formación profesional: Los usuarios son expertos en su área, y los desarrolladores son expertos en tecnología, lo que a veces dificulta que se entiendan. Desarrolladores: enfoque en la solución Los desarrolladores suelen estar muy enfocados en resolver problemas técnicos, pero esto a veces los lleva a pasar por alto o malinterpretar las necesidades reales de los usuarios. 14.  parcial 1 INGENIERIA DE REQUERIMIETOS ¿Qué es un Stakeholder? Un stakeholder es cualquier persona u organización que se ve afectada, de forma positiva o negativa, por un sistema o cambio. También es alguien que tiene interés o influencia en ese sistema. tipos de stalkerholer Se pueden clasificar según su interés en el proyecto de software: Interesados en su construcción: Son los responsables de diseñar y desarrollar el software. Ejemplos: project managers, diseñadores de software, ingenieros. Interés financiero: Se preocupan por los aspectos económicos del software, como la compra o venta. Ejemplos: analistas de negocios, gerentes de ventas, compradores. Interesados en su implementación y operación: Son quienes se encargan de que el software se implemente y funcione correctamente. Ejemplos: equipo de soporte, ingenieros de mantenimiento, gerentes. Interesados en su uso: Son los que realmente usarán el software en su día a día. Ejemplos: gerentes, empleados, usuarios directos e indirectos. Objetivos de cada grupo Cada uno de estos grupos tiene un interés diferente en el proyecto, ya sea que quieran que el software funcione bien, que sea rentable, o que sea fácil de usar. 15.  parcial 1 INGENIERIA DE REQUERIMIETOS ¿Cómo se ven los desarrolladores y los usuarios entre sí? Cómo ven los desarrolladores a los usuarios: Los desarrolladores piensan que los usuarios: No saben bien lo que quieren. No pueden expresar sus necesidades. Quieren todo de inmediato. No quieren asumir responsabilidades por el sistema. Cómo ven los usuarios a los desarrolladores: Los usuarios piensan que los desarrolladores: No entienden el negocio. Dicen "no" todo el tiempo. Se enfocan demasiado en lo técnico y se retrasan. No están disponibles cuando hay cambios importantes. Problemas de comunicación La comunicación entre los stakeholders puede fallar en varias etapas: Emisor (quien habla): Puede omitir o decir algo incorrectamente. Receptor (quien escucha): Puede no entender completamente o malinterpretar el mensaje. Medio: A veces, el mensaje se distorsiona o se pierde en el camino. La importancia de la comunicación en el desarrollo de software En un proyecto de software, la comunicación entre los diferentes stakeholders (personas involucradas, como usuarios, analistas y desarrolladores) es esencial. Sin embargo, esta comunicación puede ser problemática, ya que cada grupo tiene diferentes intereses y maneras de expresarse. 16.  parcial 1 INGENIERIA DE REQUERIMIETOS ¿Por qué es difícil la comunicación? Diferentes lenguajes: Los usuarios hablan en términos de su negocio o industria, mientras que los analistas y desarrolladores usan términos técnicos de programación. Esto genera un gap semántico, que es una brecha en la comprensión porque no hablan "el mismo idioma". Falta de entendimiento mutuo: Los usuarios a veces no entienden las limitaciones técnicas, y los desarrolladores no entienden completamente los objetivos del negocio. ¿Cómo mejorar la comunicación? El "contrato social" Para evitar estos problemas, se sugiere establecer un "contrato social" entre usuarios y analistas. Este contrato no es algo legal, sino un acuerdo sobre cómo trabajar juntos. Derechos del usuario: 1. Esperar que los analistas hablen en un lenguaje comprensible. 2. Que los analistas entiendan su negocio. 3. Recibir un documento claro de los requerimientos del software (lo que se va a hacer). 4. Que se les explique lo que se ha desarrollado. 5. Ser tratados con respeto. 6. Recibir ideas y alternativas sobre cómo implementar el software. 7. Pedir que el software sea fácil de usar. 8. Tener la posibilidad de ajustar los requerimientos para usar componentes ya existentes. 9. Recibir estimaciones realistas de los costos de cualquier cambio. 10. Que el software final cumpla con sus necesidades. 17.  parcial 1 INGENIERIA DE REQUERIMIETOS Deberes del usuario: 1. Enseñar a los analistas sobre su negocio. 2. Dar tiempo para aclarar sus necesidades. 3. Ser claros y precisos en los requerimientos. 4. Tomar decisiones rápidamente. 5. Respetar las evaluaciones de costo y viabilidad hechas por los desarrolladores. 6. Establecer prioridades entre los requerimientos. 7. Revisar los documentos y prototipos creados. 8. Informar de cualquier cambio en los requerimientos. 9. Seguir el proceso de cambios establecido por la organización. 10. Respetar el proceso de ingeniería que los analistas usan para definir los requerimientos. ciclo de vida tradicional El ciclo de vida tradicional en desarrollo de software se refiere al Proceso Unificado de Rational (RUP). Básicamente, este método organiza el trabajo en 4 fases principales, con pasos que se repiten en ciclos (iteraciones). Aquí te lo explico de manera simple: Primero se analiza el negocio: Antes de pensar en computadoras, se estudia cómo funciona el negocio. Luego, se definen los requerimientos: Se decide qué necesita el negocio y cómo un sistema informático puede ayudar. Análisis y diseño: Se diseña la solución, es decir, cómo la tecnología resolverá el problema. Las 4 fases del proceso son: 1. Inicio: Se comienza a definir el proyecto. 2. Elaboración: Se detallan los requerimientos y el diseño. 3. Construcción: Se desarrolla el sistema. 4. Transición: Se implementa y entrega al cliente. Cada fase tiene pequeños ciclos (iteraciones), para hacer el proceso más flexible y mejorar el sistema con cada vuelta. 18.  parcial 1 INGENIERIA DE REQUERIMIETOS ciclo de vida scrum El ciclo de vida de Scrum es una forma ágil de desarrollar software, diferente al método tradicional (RUP) porque se enfoca en crear software rápidamente y mejorar con el tiempo, en lugar de tener mucha documentación detallada desde el principio. Roles en Scrum: 1. Product Owner (PO): Es la persona que se encarga de hablar con los stakeholders (personas interesadas en el proyecto) para saber qué necesita el sistema. Luego, organiza esos requerimientos. 2. Equipo (Team): Un grupo de personas con diferentes habilidades que desarrollan el software basándose en lo que pide el Product Owner. 3. Artefactos en Scrum: 4. Product Backlog: Es como una lista de deseos, donde se anotan todas las cosas que el software debería tener (funciones o características). Esta lista es más simple y menos detallada que en RUP. 5. Sprint Backlog: Es una selección de algunas de esas cosas de la lista que el equipo va a trabajar en durante un sprint. 6. Sprint: Es un ciclo corto (entre 2 y 4 semanas) donde el equipo desarrolla una parte del software. giro copernicano El "giro copernicano" en el desarrollo de software es una comparación para mostrar el gran cambio entre el método tradicional (RUP) y el ágil (Scrum). Así como Copérnico cambió la forma de ver el sistema solar, los métodos ágiles cambiaron la forma de hacer software. En RUP (modelo tradicional o predictivo): Se fijan los requerimientos desde el principio: Sabemos todo lo que el software debe tener. Luego, se planifica el tiempo y el costo según esos requerimientos. Es como si tuviéramos un plan detallado y lo seguimos sin muchos cambio. En Scrum (modelo ágil): Primero se define el tiempo (cuánto tiempo tenemos) y los recursos (equipo disponible). El alcance (las funciones o características que se van a desarrollar) se ajusta en función del tiempo y recursos. Se prioriza lo más importante y se va ajustando conforme avanza el proyecto. En resumen, RUP tiene un plan fijo desde el principio, mientras que Scrum es más flexible, ajustando el plan según el tiempo y recursos disponibles. Este es el "giro copernicano", porque cambia completamente cómo se priorizan las cosas. 19.  parcial 1 INGENIERIA DE REQUERIMIETOS ciclo de vida distribuido En este tipo de ciclo de vida distribuido, el trabajo se reparte entre equipos que están en diferentes partes del mundo. Por ejemplo, el equipo de gestión está en Europa, el de desarrollo en Argentina y el de testing en India. La gran ventaja es que, debido a las diferencias horarias, el trabajo puede seguir casi 24 horas al día. Cuando un equipo termina su jornada, otro en una zona horaria diferente puede continuar el trabajo. Ventajas: Más velocidad: El proyecto avanza sin parar, aprovechando las diferentes zonas horarias. Desventajas: Cultura y comunicación: Las diferencias culturales (como el estilo de trabajo o la puntualidad) y los idiomas pueden causar malentendidos. Ambigüedad: El lenguaje natural puede ser confuso, lo que podría generar errores en la comunicación entre equipos. Este tipo de ciclo de vida tiene grandes beneficios, pero requiere una buena coordinación y comunicación clara para evitar problemas. modelo en V El modelo en V es una variación del ciclo de vida en cascada, donde cada etapa de desarrollo tiene una etapa de prueba relacionada. Imagina una "V", donde la parte de arriba a la izquierda son las fases de planificación y especificación, y la parte de arriba a la derecha son las fases de validación y pruebas. El punto en el centro (el vértice de la "V") es cuando se realiza la codificación. Ejemplo: Los requerimientos (lo que el cliente quiere) se validan con las pruebas de aceptación de usuarios para asegurarse de que el sistema cumple con lo esperado. Diferencia con metodologías ágiles: En el modelo en V hay mucha más documentación y se hace énfasis en validar cada etapa del desarrollo antes de avanzar. En ágiles, el enfoque está en entregar software funcional rápidamente y la documentación es más ligera. modelo en V Por otro lado, el CMMi (Capability Maturity Model Integration) no es un ciclo de vida, sino un modelo que mide cuán maduros son los procesos de un equipo de desarrollo. Evalúa qué tan bien está organizado un equipo y cómo pueden mejorar sus procesos para ser más eficientes. 20.  parcial 1 INGENIERIA DE REQUERIMIETOS la calidad según Pirsing Dilema de la calidad: Pirsig discute sobre si la calidad es algo objetivo (que reside en los objetos) o subjetivo (que depende del observador). Si la calidad es objetiva, ¿por qué no podemos medirla científicamente? Si es totalmente subjetiva, entonces cualquiera puede decidir qué es calidad, lo que la haría inconsistente. Conclusión: Pirsig llega a la idea de que la calidad no es ni completamente objetiva ni completamente subjetiva, sino algo que surge en la relación entre el objeto y el sujeto. La calidad no puede separarse de la experiencia de interactuar con algo. Relación sujeto-objeto: Pirsig sugiere que la calidad se encuentra en la interacción entre quien percibe (sujeto) y el objeto en sí. No es algo que se pueda separar y medir por sí solo, ni algo que dependa únicamente de la opinión del observador. El concepto de calidad según J.M. Juran y W.E. Deming Juran: Para él, la calidad tiene dos partes: Satisfacción del usuario: Un producto es de calidad si cumple con lo que el usuario necesita. Sin defectos: También significa que el producto no tiene fallos o errores que hagan que el usuario se queje o devuelva el producto. Deming: Él dice que la calidad es difícil de definir porque: Las necesidades cambian: Es complicado anticipar lo que los usuarios van a querer en el futuro, ya que sus necesidades cambian rápido. El reto es hacer un producto que siga siendo útil y satisfactorio a lo largo del tiempo, aunque las expectativas de los usuarios cambien. la calidad según IEEE: La calidad es cuando un sistema o programa: Cumple con los requerimientos que fueron especificados (lo que se acordó que debía hacer). Satisface las necesidades y expectativas del cliente o usuario. 21.  parcial 1 INGENIERIA DE REQUERIMIETOS la calidad según Fisher & Light: La calidad es cuando un sistema tiene todos los atributos o características que lo hacen excelente. Añaden el concepto de excelencia, que es hacerlo lo mejor posible. El concepto de calidad según DoD-STD-2168: La calidad es la capacidad de un producto de software para cumplir con los requerimientos que se le dieron. Impactos positivos de prácticas de requerimientos Factores que hacen exitoso un proyecto: 1. Involucramiento de los usuarios: Cuando los usuarios participan activamente en el proyecto, el software que se desarrolla se ajusta mejor a lo que realmente necesitan. 2. Apoyo de la gestión ejecutiva: Tener el respaldo de los jefes ayuda a que el proyecto avance sin problemas y con los recursos necesarios. 3. Especificación clara de los requerimientos: Saber exactamente qué debe hacer el software desde el principio evita malentendidos y problemas. 4. Planificación adecuada: Un buen plan ayuda a mantener el proyecto en orden y dentro del tiempo y presupuesto. 5. Expectativas realistas: Es importante que todos tengan claro lo que se puede lograr y en cuánto tiempo, para evitar decepciones. Indicadores de proyectos complicados: 1. Falta de participación del usuario: Si los usuarios no se involucran, el software puede terminar siendo inútil para ellos. 2. Requerimientos incompletos: Si no se saben bien todos los detalles de lo que debe hacer el software, es probable que algo importante quede fuera. 3. Requerimientos cambiantes: Cuando los objetivos cambian constantemente, es difícil avanzar sin contratiempos. 4. Falta de apoyo de los jefes: Si los líderes no respaldan el proyecto, puede faltar dinero o recursos, lo que lo hace más difícil. 5. Incompetencia técnica: Si el equipo no tiene las habilidades necesarias, el proyecto puede estancarse o salir mal. 22.  parcial 1 INGENIERIA DE REQUERIMIETOS beneficios de tener buenos requerimientos en el desarrollo Acuerdo entre los stakeholders: Las personas interesadas (clientes, equipo, etc.) se ponen de acuerdo sobre qué es lo que se espera del sistema y cómo se va a evaluar si está terminado correctamente. Base para estimaciones: Tener buenos requerimientos ayuda a calcular mejor cuántos recursos (como dinero, tiempo o personas) se necesitarán para completar el sistema. Mejoras en el sistema: Unos buenos requerimientos hacen que el sistema sea más fácil de usar y mantener a lo largo del tiempo. Menos esfuerzo extra: Al definir bien lo que se necesita, se evitan errores y retrabajos (hacer cosas dos veces). Finalmente, se menciona que estas ventajas son más evidentes cuando el sistema es grande o complicado. los beneficios de la Ingeniería de Requerimientos. Proactivos (lo que ayuda a hacer antes de que ocurran problemas): Involucrar a los usuarios: Hacer que los usuarios participen en la definición del proyecto. Formular claramente los requerimientos: Definir claramente lo que el proyecto debe hacer. Establecer expectativas realistas: Asegurarse de que lo que se promete sea alcanzable. Clarificar la visión y los objetivos: Tener claro qué se quiere lograr con el proyecto. Predicción del éxito: Ayuda a saber si el proyecto tiene posibilidades de éxito desde el principio. Reduce (lo que ayuda a evitar o minimizar problemas): Impacto de riesgos: Disminuir las posibilidades de que algo salga mal. Compromiso del usuario: Lograr que los usuarios estén comprometidos con el proyecto. Comprensión de los requerimientos: Asegurarse de que todos entiendan qué se necesita. Manejo de expectativas: Evitar que los usuarios esperen cosas irreales. Conflictos entre departamentos y usuarios: Reducir peleas o malentendidos entre equipos. Cambios de alcance y objeciones: Controlar bien los cambios en lo que el proyecto debe hacer para evitar problemas. 23.  parcial 1 INGENIERIA DE REQUERIMIETOS impactos negativos los impactos negativos que pueden ocurrir si no se aplican correctamente las prácticas de Ingeniería de Requerimientos (IR). Cuando estas se omiten, los proyectos suelen fracasar por varias razones. Requerimientos incompletos: Si no se sabe bien lo que el proyecto necesita, habrá confusión y problemas. Falta de compromiso de los usuarios: Si los usuarios no participan ni se interesan, es probable que el proyecto no salga bien. Falta de recursos: Si no hay suficiente dinero, personal o tiempo, el proyecto tendrá dificultades para avanzar. Expectativas no realistas: Prometer más de lo que realmente se puede hacer llevará a decepciones. Falta de soporte de la gestión ejecutiva: Si los líderes de la empresa no apoyan el proyecto, este puede quedarse sin dirección o recursos. Requerimientos y especificaciones cambiantes: Cambiar constantemente lo que se pide del proyecto lo hace difícil de manejar. Falta de planificación: Sin un buen plan, el proyecto no tendrá una guía clara y será más fácil que falle. Falta de gestión de IT: No tener un buen equipo técnico o un control adecuado de las herramientas puede causar problemas serios. Problemas técnicos: Fallos tecnológicos pueden aparecer si no se gestionan bien desde el principio. Estadisticas Estudios de Bell Lab e IBM: Muestran que el 80% de los defectos en los proyectos ocurre durante la fase de requerimientos. Es decir, si no se definen bien desde el principio, es muy probable que aparezcan errores más adelante. Proyectos de USAF (Fuerza Aérea de EE. UU.): Aquí, el 36% de los defectos provino de fallos en la traducción de los requerimientos (entender mal lo que se necesita). Además, solo el 9% de los defectos fueron resueltos en la etapa de requerimientos, lo que significa que la mayoría de los problemas no se detectaron a tiempo. Naves Voyager y Galileo: De los 197 defectos encontrados durante las pruebas, solo 3 fueron problemas de programación. La mayoría de los errores venían de los requerimientos mal definidos. 24.  parcial 1 INGENIERIA DE REQUERIMIETOS elicitacion La elicitación es el proceso de obtener o sonsacar las ideas y necesidades del usuario para convertirlas en requerimientos claros para un sistema de software. Aunque la palabra no existe en español de forma oficial, viene del verbo en inglés "elicit" que significa obtener información. En este caso, es sobre lo que el cliente necesita o espera del sistema. Este proceso es clave porque el éxito de un sistema depende de que se cumplan las necesidades y expectativas de los usuarios. A menudo, los usuarios no tienen claros todos los detalles desde el principio, por lo que es necesario utilizar técnicas y herramientas para ayudar a descubrir esas necesidades. La definición de requerimientos de la IEEE (IEEE-STD- 610 de 1990) Requerimientos del usuario: Son las necesidades que tiene el usuario para solucionar un problema o alcanzar un objetivo con el sistema. Requerimientos del sistema: Son las capacidades que el sistema o sus componentes deben cumplir para ajustarse a un contrato, estándar o especificación previamente acordada. requerimientos que se consideran en un sistema de software: Necesidades: Son los requisitos fundamentales que el sistema debe cumplir para resolver el problema principal. Ejemplos incluyen funcionalidad, comportamiento del sistema, tiempo de respuesta y características operacionales. Deseos: Son características adicionales que los stakeholders (interesados) desean, pero que no son esenciales para resolver el problema. Incluyen cosas como funcionalidades extra, mejoras en la interfaz o algoritmos específicos. Expectativas: Son características esperadas por los stakeholders, pero que a menudo no son mencionadas explícitamente. Estas pueden ser sobre la confiabilidad, características de la interfaz, o aspectos específicos del dominio. 25.  parcial 1 INGENIERIA DE REQUERIMIETOS ¿Cuál es el rol de los requerimientos? El rol de los requerimientos en el desarrollo de software es fundamental para asegurar que el sistema final cumpla con las expectativas y necesidades de todas las partes involucradas: 1. Acuerdo desarrolladores-clientes-usuarios finales: Los requerimientos establecen un entendimiento claro entre quienes desarrollan el software, quienes lo pagan (clientes) y quienes lo usan. Ayudan a evitar malentendidos. 2. Aspecto contractual: Sirven como base para contratos, donde se definen las funcionalidades y características que debe tener el software, garantizando que ambas partes (cliente y desarrollador) sepan lo que se entregará. 3. Multipartes (comunicación, conflicto y cambio de visiones): Los requerimientos facilitan la comunicación entre todos los interesados en el proyecto (clientes, usuarios, desarrolladores), resolviendo conflictos y gestionando posibles cambios en la visión del proyecto. 4. Base para el diseño del software: Son el punto de partida para que los diseñadores y desarrolladores sepan qué características y funciones debe tener el sistema. 5. Minimizar defectos tanto como sea posible: Al tener requerimientos claros y bien definidos, se reduce el riesgo de errores o malentendidos que puedan generar defectos en el software. 6. Técnicamente factible: Los requerimientos aseguran que las funcionalidades solicitadas puedan ser implementadas con la tecnología disponible y en el tiempo previsto. 7. Soporte para verificación y validación: Sirven de referencia para comprobar que el software cumple con las especificaciones iniciales (verificación) y que realmente satisface las necesidades del usuario final (validación). 8. Soporte a la evolución del sistema: Ayudan a guiar las mejoras y actualizaciones del sistema con el tiempo, asegurando que el software pueda adaptarse a nuevas necesidades o tecnologías. 9. Evolución del sistema: Los requerimientos permiten gestionar el paso de un sistema antiguo a uno nuevo, asegurando que se tomen en cuenta los cambios necesarios para que el nuevo sistema funcione adecuadamente. 26.  parcial 1 INGENIERIA DE REQUERIMIETOS perspectiva organizacional Contribuciones: Automatizar y reducir costos: El objetivo es automatizar procesos para hacerlos más eficientes y reducir costos. Informar a quienes toman decisiones: Proporcionar a los líderes de la organización la información necesaria para tomar decisiones estratégicas. Transformar la organización: Convertir la información en una herramienta estratégica que ayude a mejorar la organización. Prerrequisitos: Visión del negocio y la organización: Es crucial tener una clara comprensión de los objetivos y la estructura de la empresa. Alineación con la estrategia corporativa: Los sistemas deben estar alineados con los objetivos generales de la empresa para asegurar que todos los esfuerzos contribuyan al éxito del negocio. Desarrollo de los sistemas: Necesidades de los involucrados: Es fundamental tener en cuenta las necesidades de todas las partes interesadas (stakeholders). Satisfacer los requerimientos y la estrategia de negocio: Asegurar que el sistema cumpla tanto con las necesidades del usuario como con los objetivos estratégicos de la organización. 27.  parcial 1 INGENIERIA DE REQUERIMIETOS el concepto de Requerimientos desde la perspectiva de software En el desarrollo de software, la ingeniería de requerimientos juega un papel fundamental para asegurar que el producto final cumpla con lo que los usuarios y clientes necesitan. 1. Proceso (según ISO): Se define como una serie de acciones únicas y finitas que tienen un propósito o efecto específico y se ejecutan bajo condiciones establecidas. En el contexto del desarrollo de software, el proceso está compuesto por diferentes fases, y una de ellas es la determinación de los requerimientos. 2. Requerimientos como subproceso del desarrollo: La identificación y definición de los requerimientos es solo una parte (subproceso) dentro del proceso general de desarrollo del software. Se trata de capturar las necesidades del usuario y del sistema para que se puedan diseñar soluciones que cumplan con esas demandas. 3. Ingeniería de requerimientos y el diseño: Para que un sistema de software funcione como se espera, se necesita un proceso de diseño bien definido, basado en los requerimientos. Este proceso incluye: Requerimientos a satisfacer: Lo primero es entender qué necesita el usuario y qué se espera que haga el sistema. Esto se traduce en un conjunto de requerimientos. Output (salida): El resultado es un documento de especificación de diseño, que describe cómo debe construirse el sistema para cumplir con los requerimientos. Objetivo del diseñador: El diseñador debe crear un artefacto (el software) que, al implementarse, satisfaga los requerimientos establecidos. 4. Propiedades comunes del diseño en todos los enfoques: Generación de modelos: Durante el proceso de diseño, se crean varios modelos que representan diferentes aspectos del sistema, como la arquitectura, el comportamiento y la interfaz. Pasos orientados por objetivos: Cada paso del diseño tiene un objetivo claro, y se avanza a través de fases que representan una mejora o refinamiento continuo del sistema. Transiciones y refinamientos: A medida que el diseño avanza, las ideas y los modelos se refinan y se transforman hasta llegar a una solución final que cumple con los requerimientos. 28.  parcial 1 INGENIERIA DE REQUERIMIETOS modelo de referencia delos requerimientos y su relación con el sistema y el ambiente. La imagen representa el modelo de relación entre los requerimientos, el sistema y el ambiente en el desarrollo de software. 1. Ambiente (W): Es el dominio del conocimiento donde se encuentran los hechos del mundo real. Aquí se identifican los requerimientos (R), es decir, las necesidades del usuario, descritas en términos de cómo afectan al ambiente. 2. Requerimientos (R): Son las necesidades del usuario que deben satisfacerse en el sistema. Estos requerimientos se trasladan del ambiente al sistema a través de una especificación (S). 3. Especificación (S): Es la descripción técnica que proporciona información al programador sobre cómo construir el sistema para que cumpla con los requerimientos. Es el puente entre lo que se necesita en el ambiente y lo que el sistema debe hacer. 4. Sistema (M): Es la plataforma o el entorno técnico donde el sistema de software es implementado. Utiliza la plataforma de programación (P), que es el programa que implementa la especificación. el concepto de "Análisis de requerimientos" El análisis de requerimientos es una parte clave en el desarrollo de software, ya que define y aclara lo que necesita el sistema para cumplir con las expectativas de los usuarios y del negocio. A continuación, te explico de manera sencilla los conceptos relacionados con la especificación de requerimientos de software (SRS) y su importancia en el proceso: 1. Especificación de Requerimientos de Software (SRS): Es un documento que modela lo que se necesita en el software y describe el problema que el sistema debe resolver. Esta especificación utiliza diferentes formas de expresión, desde lenguaje natural hasta gráficos o modelos matemáticos. 2. Estructura y estándares: Existen varios formatos y estándares para organizar una SRS, que buscan asegurar que toda la información relevante esté claramente documentada. 3. Razones para desarrollar una SRS: Proceso de comunicación: Ayuda a que todos los involucrados (clientes, usuarios, desarrolladores) tengan un entendimiento común de lo que el software debe hacer. Arreglo contractual: Sirve como base para acuerdos formales entre el cliente y el desarrollador, asegurando que todos sepan qué se entregará. Evaluación y testeo: La SRS se usa para evaluar si el producto final cumple con los requerimientos y para guiar las pruebas del sistema. 4. Especificación funcional: Tradicionalmente, la SRS se enfocaba en describir lo que el sistema debía hacer, prestando atención a aspectos como la entrada (input), el procesamiento, y la salida (output). 29.  parcial 1 INGENIERIA DE REQUERIMIETOS análisis de requerimientos Requerimientos funcionales y no funcionales: Requerimientos funcionales: Se refieren a lo que el sistema debe hacer, es decir, las funciones y características que debe tener. Requerimientos no funcionales: Son restricciones o condiciones que el sistema debe cumplir, como el rendimiento, la seguridad, o la usabilidad. A menudo se dejaban de lado en los enfoques tradicionales, pero son fundamentales para el éxito del sistema. Relación SRS-arquitectura del sistema: La SRS define el "qué" del sistema (qué debe hacer), mientras que la arquitectura define el "cómo" (cómo se va a implementar). Ambos deben estar bien alineados para que el sistema funcione correctamente. Propósito del sistema: El propósito de un sistema de software va más allá de los requerimientos funcionales. También incluye una comprensión del contexto en el que operará y las restricciones que afectan su desarrollo e implementación. requerimientos no funcionales Los requerimientos no funcionales son características o restricciones que se aplican a un sistema para asegurar que los requerimientos funcionales se puedan cumplir de manera adecuada. Mientras que los requerimientos funcionales definen lo que debe hacer el sistema (por ejemplo, permitir al usuario iniciar sesión), los no funcionales definen cómo el sistema debe hacerlo (por ejemplo, que la respuesta sea rápida o segura). requerimientos no funcionales que debe cumplir un sistema para funcionar correctamente: 1. Performance: El sistema debe ser rápido, procesar datos en tiempo real y cumplir con restricciones de tiempo. 2. Seguridad: Necesita controles de acceso, niveles de seguridad y políticas para proteger los datos. 3. Interface: La interfaz debe ser fácil de usar, permitir búsqueda de datos y tener ayudas disponibles. 4. Mantenibilidad y portabilidad: El sistema debe ser fácil de mantener, poder moverse a otros entornos y trabajar con otros sistemas. 5. Restricciones específicas: Hay limitaciones según el dominio del sistema y la tecnología usada para implementarlo. 30.  parcial 1 INGENIERIA DE REQUERIMIETOS ingeniería de requerimientos La ingeniería de requerimientos es un proceso organizado que se usa para definir qué necesita hacer un sistema o software. Este proceso implica: Colaboración e iteración: Se trabaja en equipo, y el análisis del problema se repite varias veces hasta entenderlo completamente. Análisis: Se estudia el problema en detalle para descubrir qué se necesita. Documentación: Se escriben las observaciones y los requerimientos en diferentes formatos para que todos puedan entenderlos. Validación: Se verifica y se asegura que los requerimientos documentados reflejan bien lo que se necesita. Este proceso ayuda a asegurarse de que el sistema o software cumpla con lo que realmente se espera de él. alcance El alcance de la Ingeniería de Requerimientos se refiere a todo lo que abarca este proceso. Es decir, incluye: Los procesos que llevan a definir y formular los requerimientos de un sistema o software. Los productos resultantes, como los documentos que describen estos requerimientos. La gestión de los requerimientos durante todo el ciclo de vida del software, desde el desarrollo hasta su mantenimiento. caracteristicas Representación, aspecto social y cognitivo: Involucra cómo se representan los requerimientos, y considera las interacciones entre personas y la comprensión del problema. De informal a formal: Se empieza con ideas generales (informales) y se transforman en especificaciones más técnicas (formales). No es lineal ni determinístico: El proceso no sigue un orden fijo, ya que cambia y evoluciona según las circunstancias. No es solo técnico: Obtener, especificar y validar requerimientos no es solo una tarea técnica, también requiere habilidades interpersonales. Resolución de problemas: Se trata de entender y solucionar problemas. 31.  parcial 1 INGENIERIA DE REQUERIMIETOS analisis Los problemas no están totalmente estructurados ni claros desde el principio. Los requerimientos están influenciados por el contexto de la organización. Las soluciones que se proponen no son naturales, sino diseñadas específicamente para el problema. Los problemas evolucionan y cambian con el tiempo. Se necesitan conocimientos de diferentes disciplinas. Los conocimientos del analista de sistemas evolucionan a medida que el proyecto avanza. Procesos de la Ingeniería de Requerimientos Elicitación / Relevamiento: Es el proceso de recopilar información y requisitos. Se hace en distintos niveles, como el negocio (entender la necesidad desde el punto de vista de la empresa) y el producto de software (detalles técnicos del software). Se identifican los stakeholders (personas clave que tienen interés en el proyecto) y se planifica cómo se recopilará la información. Se utilizan técnicas como entrevistas, prototipos, brainstorming (lluvia de ideas), observación, análisis de documentos, y cuestionarios para obtener información relevante. Especificación / Documentación: Una vez que se tiene la información, se organiza y documenta. Se crean subprocesos para definir la estructura del documento de requisitos del sistema (SRS, Software Requirements Specification), y se asegura que todo esté controlado. Se usan herramientas como casos de uso, storyboards (guiones gráficos) y juegos de roles para detallar los requisitos. Validación: Es revisar que lo que se ha documentado y especificado cumple con los requisitos y expectativas iniciales. Trazabilidad y Gestión: Asegurar que los requisitos sean rastreables a lo largo del proyecto, es decir, que cada paso pueda vincularse con las necesidades iniciales, y que haya un control adecuado del proceso. 32.  parcial 1 INGENIERIA DE REQUERIMIETOS Aspectos principales de la IR El modelo de proceso de Loucopoulos, en el contexto de la ingeniería de requisitos (IR), se enfoca en tres etapas clave que ayudan a gestionar de manera efectiva los requisitos en el desarrollo de software: 1. Elicitación: Esta fase implica recopilar los requisitos del sistema a partir de las fuentes relevantes, como los usuarios finales, los clientes o cualquier otra parte interesada. Se trata de entender lo que realmente se necesita para resolver el problema o mejorar un proceso. 2. Especificación: Una vez recolectados los requisitos, se deben documentar de manera clara y detallada. Esto puede incluir tanto los requisitos funcionales (lo que el sistema debe hacer) como los no funcionales (cómo debe hacerlo). El objetivo aquí es asegurarse de que todos los participantes tengan una comprensión común y precisa del sistema que se va a construir. 3. Validación: Esta etapa se centra en verificar que los requisitos especificados son correctos, completos y que efectivamente cumplen con las necesidades del cliente o usuario. Aquí se realizan revisiones y evaluaciones para garantizar que no haya malentendidos o errores antes de avanzar a las etapas de diseño y desarrollo. Estos tres aspectos son fundamentales para un proceso de ingeniería de requisitos efectivo, asegurando que se aborden y se acuerden correctamente los problemas antes de desarrollar una solución tecnológica. 33.  parcial 1 INGENIERIA DE REQUERIMIETOS el proceso de ingeniería de requisitos 1. Elicitación: Qué es: Es el proceso donde se obtienen los requisitos del usuario. Aquí se busca comprender las necesidades y expectativas del usuario. Cómo se relaciona: El usuario comunica lo que necesita (sus requisitos) y se comienza a adquirir el conocimiento del dominio (el área específica donde se va a aplicar el software). Si es necesario más conocimiento, se retroalimenta al proceso de elicitación para profundizar más en la información del dominio. 2. Especificación: Qué es: Una vez que se han elicitado los requisitos, se procede a especificar detalladamente lo que se ha recopilado. Es decir, se traducen las necesidades del usuario en documentos técnicos y modelos que describen cómo debe funcionar el sistema. Cómo se relaciona: Los modelos de requisitos y la especificación de los mismos se basan en el conocimiento adquirido durante la elicitación. Si durante la especificación se descubre que se necesita más conocimiento, el proceso vuelve a la fase de elicitación para buscar más detalles. 3. Validación: Qué es: En esta fase se revisa si los modelos y especificaciones creadas reflejan correctamente las necesidades del usuario. El usuario proporciona feedback (retroalimentación) sobre si lo que se ha especificado cumple con sus expectativas. Cómo se relaciona: Los resultados de la validación determinan si es necesario hacer ajustes en la especificación o volver a la elicitación para obtener más información. Además, la validación usa los modelos de requisitos que se especificaron previamente para confirmar que son correctos. 4. Usuario y Conocimiento del Dominio: El usuario es quien proporciona los requisitos y valida si se han comprendido correctamente. El conocimiento del dominio del problema se obtiene tanto en la elicitación como en la validación, ayudando a que el proceso sea más preciso. En resumen, este ciclo asegura que haya una constante interacción entre lo que el usuario necesita, cómo se documenta y especifica esa necesidad, y cómo se valida que todo está correcto. Si en cualquier momento hay falta de claridad o errores, el proceso permite regresar a fases anteriores para corregir y ajustar. 34.  parcial 1 INGENIERIA DE REQUERIMIETOS el proceso de ingeniería de requisitos 1. Elicitación: Qué es: Es el proceso donde se obtienen los requisitos del usuario. Aquí se busca comprender las necesidades y expectativas del usuario. Cómo se relaciona: El usuario comunica lo que necesita (sus requisitos) y se comienza a adquirir el conocimiento del dominio (el área específica donde se va a aplicar el software). Si es necesario más conocimiento, se retroalimenta al proceso de elicitación para profundizar más en la información del dominio. 2. Especificación: Qué es: Una vez que se han elicitado los requisitos, se procede a especificar detalladamente lo que se ha recopilado. Es decir, se traducen las necesidades del usuario en documentos técnicos y modelos que describen cómo debe funcionar el sistema. Cómo se relaciona: Los modelos de requisitos y la especificación de los mismos se basan en el conocimiento adquirido durante la elicitación. Si durante la especificación se descubre que se necesita más conocimiento, el proceso vuelve a la fase de elicitación para buscar más detalles. 3. Validación: Qué es: En esta fase se revisa si los modelos y especificaciones creadas reflejan correctamente las necesidades del usuario. El usuario proporciona feedback (retroalimentación) sobre si lo que se ha especificado cumple con sus expectativas. Cómo se relaciona: Los resultados de la validación determinan si es necesario hacer ajustes en la especificación o volver a la elicitación para obtener más información. Además, la validación usa los modelos de requisitos que se especificaron previamente para confirmar que son correctos. 4. Usuario y Conocimiento del Dominio: El usuario es quien proporciona los requisitos y valida si se han comprendido correctamente. El conocimiento del dominio del problema se obtiene tanto en la elicitación como en la validación, ayudando a que el proceso sea más preciso. En resumen, este ciclo asegura que haya una constante interacción entre lo que el usuario necesita, cómo se documenta y especifica esa necesidad, y cómo se valida que todo está correcto. Si en cualquier momento hay falta de claridad o errores, el proceso permite regresar a fases anteriores para corregir y ajustar. 35.  parcial 1 INGENIERIA DE REQUERIMIETOS El modelo de SWEBOK El modelo de SWEBOK (Software Engineering Body of Knowledge) se centra en definir los aspectos clave de los requerimientos de software. Fundamentos de los requerimientos de software: Define qué es un requerimiento y los diferentes tipos: funcionales (lo que debe hacer el software) y no funcionales (cómo debe hacerlo, como rendimiento). También incluye otras características, como propiedades emergentes (lo que aparece cuando el sistema se usa en su conjunto) y cómo medir los requerimientos. Procesos de requerimientos: Describe cómo los requerimientos se gestionan y mejoran. Involucra diferentes actores y cómo el proceso debe ser apoyado y gestionado a lo largo del tiempo. Elicitación de requerimientos: Se refiere a cómo obtener los requerimientos del cliente o usuario. Esto puede hacerse a través de diversas técnicas, como entrevistas o cuestionarios, y requiere identificar las fuentes de información. Análisis de requerimientos: Una vez que tienes los requerimientos, los organizas y clasificas. Aquí también se realiza el diseño y la negociación para asegurar que todos estén de acuerdo con lo que el software debe hacer. Especificación de requerimientos: Aquí los requerimientos se escriben de manera formal y clara, para que todos los involucrados (desarrolladores, clientes, etc.) entiendan lo que debe hacer el software. Validación de requerimientos: Se revisan los requerimientos para asegurar que están correctos. Se pueden hacer prototipos o realizar pruebas para confirmar que lo que se pidió es lo que se necesita. Consideraciones prácticas: Habla sobre aspectos importantes en la práctica, como manejar los cambios en los requerimientos, rastrear quién pidió qué, y medir si se cumplen los requerimientos. En resumen, SWEBOK divide el trabajo con los requerimientos de software en varias fases, desde obtenerlos, analizarlos, validarlos, hasta gestionar cambios a lo largo del desarrollo. 36.  parcial 1 INGENIERIA DE REQUERIMIETOS El modelo BABOK v2 El modelo BABOK v2 (Business Analysis Body of Knowledge) se enfoca en las áreas clave del análisis de negocio, que incluyen cómo manejar los requerimientos y cómo se gestionan dentro de una empresa. A continuación te lo explico de manera sencilla: 1. Business Analysis Planning and Monitoring (Planificación y Monitoreo del Análisis de Negocio): Implica planificar y hacer seguimiento de todo el trabajo relacionado con el análisis de negocio. Básicamente, es cómo organizarse para hacer bien el trabajo. 2. Elicitation (Elicitación): Es el proceso de obtener información de los interesados (personas involucradas) para entender qué necesita la empresa o el cliente. Aquí se recopilan los requerimientos. 3. Enterprise Analysis (Análisis Empresarial): Aquí se mira la empresa como un todo. Se evalúan las oportunidades, los problemas y cómo se puede mejorar la organización. Es un análisis a gran escala para entender el contexto. 4. Requirements Analysis (Análisis de Requerimientos): Una vez que se tienen los requerimientos, se analizan para ver si están claros, completos y viables. Aquí también entra la negociación, que es necesaria cuando hay muchos interesados que tienen opiniones diferentes. 5. Solution Assessment and Validation (Evaluación y Validación de Soluciones): Después de desarrollar una solución, se evalúa para asegurarse de que realmente resuelve los problemas o satisface las necesidades que fueron identificadas al principio. 6. Requirements Management and Communication (Gestión y Comunicación de Requerimientos): Se refiere a cómo se manejan los requerimientos durante todo el ciclo de vida del proyecto, asegurando que todos los involucrados estén informados y alineados con los cambios. 7. Underlying Competencies (Competencias Subyacentes): Son las habilidades y conocimientos que los analistas de negocio necesitan, como comunicación, negociación y análisis crítico. En resumen, el modelo BABOK organiza el trabajo del analista de negocio en áreas clave, desde la recolección de información hasta la validación de soluciones, con un enfoque en la negociación y la gestión de requerimientos a lo largo del proceso. 37.  parcial 1 INGENIERIA DE REQUERIMIETOS ciclo de vida de análisis de negocio las diferentes etapas que se siguen en el análisis de negocio para desarrollar una solución adecuada. 1. Planificación y monitoreo del análisis de negocio: Se planifica cómo se va a llevar a cabo el análisis y se hace un seguimiento constante para asegurarse de que todo vaya bien. 2. Gestión del ciclo de vida de los requisitos: Se gestionan y se mantienen los requisitos durante todo el proceso de desarrollo, asegurándose de que siempre estén actualizados y alineados con lo que se necesita. 3. Análisis y definición de requisitos y diseño: Se estudian los requisitos y se define cómo se va a diseñar la solución que cumpla con ellos. 4. Evaluación de la solución: Se revisa la solución para ver si cumple con los requisitos y si funciona bien para el negocio. 5. Análisis estratégico: Se estudia la estrategia del negocio para asegurarse de que la solución esté alineada con los objetivos generales. 6. Elicitación y colaboración: Es la etapa en la que se obtiene información y se colabora con las personas involucradas (como los clientes o usuarios) para entender sus necesidades. este modelo ha sido ajustado y mejorado con el tiempo, incluyendo la parte de "gestión del ciclo de vida de los requisitos", que conecta esta fase con todo el ciclo de desarrollo del software. Esto asegura que la solución siempre esté adaptada a las necesidades del negocio y a los cambios que puedan surgir. libro del año 2017 un proceso de Ingeniería de Requerimientos (IR) dividido en dos grandes áreas: el dominio del problema y el dominio de la solución. 1. Dominio del problema: Statement of Needs (Declaración de Necesidades): Es lo que se necesita o espera del sistema. Requerimientos de los stakeholders (partes interesadas): Aquí se recogen los deseos, necesidades y expectativas de las personas involucradas en el proyecto (usuarios, clientes, etc.). Desarrollo de los requerimientos de los stakeholders: En esta parte, se procesan y organizan esos requerimientos para comprender mejor las necesidades. Modelo de uso: Un documento o diagrama que muestra cómo se espera que los usuarios interactúen con el sistema. 2. Dominio de la solución: Desarrollo de los requerimientos del sistema: Una vez se tienen claros los requerimientos de los stakeholders, se traducen en especificaciones técnicas que el sistema debe cumplir. Desarrollo del diseño del sistema: Aquí se diseña la arquitectura del sistema basada en los requerimientos del sistema. Repetición para cada subsistema o componente: Este proceso se repite para cada parte o subsistema del proyecto. Desarrollo de los requisitos del subsistema/componente: Cada parte del sistema también tiene sus propios requisitos, que son procesados y diseñados en detalle. Arquitectura del diseño del subsistema: Se define cómo se construirá cada parte del sistema. el proceso va desde escuchar y entender las necesidades de los stakeholders en el "dominio del problema" hasta desarrollar una solución técnica detallada en el "dominio de la solución". El libro del 2017 de Jeremy Dick, Elizabeth Hull y Ken Jackson destaca la importancia de abordar ambos dominios para garantizar que todas las voces sean escuchadas y que la solución sea adecuada para todos los interesados 38.  parcial 1 INGENIERIA DE REQUERIMIETOS ¿qué rol cumplen los procesos ágiles en la IR? se manejan los requisitos en un entorno ágil, y cómo se transforman desde ideas generales a tareas específicas a lo largo del proceso. Desglose del gráfico: 1. De lo general a lo específico: Theme (Tema): Es el concepto más amplio, el "por qué" de lo que se está desarrollando. Es una visión general del sistema o del producto. Epic (Épica): Es una gran funcionalidad o una necesidad importante del sistema, que responde al "por qué" y proporciona valor significativo. Feature (Característica): Responde al "qué" y describe una funcionalidad más concreta que debe implementarse. Story (Historia de Usuario): Responde al "cómo" desde la perspectiva del usuario. Se trata de una descripción detallada de lo que necesita el usuario. Task (Tarea): Son actividades muy específicas que los equipos deben realizar para cumplir con una historia de usuario. Ciclo Ágil para las Especificaciones: Feature (Característica): Es el nivel más alto donde se define una funcionalidad importante. Este es el punto de partida en el desarrollo ágil. User Story (Historia de Usuario): Descompone una característica en historias de usuario más pequeñas. Cada historia de usuario responde a necesidades específicas del usuario y suele seguir la estructura: "Como [tipo de usuario], quiero [objetivo] para [beneficio]". Scenario (Escenario): Detalle aún mayor dentro de una historia de usuario. Cada escenario plantea una situación particular que se debe cubrir y suele describirse con frases como "Dado que..." o "Como usuario...". Iteración e Incremento: Este enfoque ágil permite que se desarrolle de manera iterativa e incremental. Primero se crean las características grandes (features), luego se detallan como historias de usuario, y finalmente, estas se dividen en tareas específicas que el equipo puede ejecutar. En resumen: Los procesos ágiles transforman los conocimientos generales en especificaciones detalladas a través de varios niveles (épicas, características, historias de usuario, tareas). Este enfoque asegura que el trabajo avance en pequeños incrementos, ajustándose a las necesidades de los stakeholders, lo que facilita la gestión de requisitos de manera eficiente y continua. 39.  parcial 1 INGENIERIA DE REQUERIMIETOS los diferentes niveles de la Ingeniería ágil de requerimientos La Ingeniería Ágil de Requerimientos sigue un enfoque iterativo e incremental, lo que reduce la necesidad de una extensa documentación inicial como en los métodos tradicionales. En lugar de crear grandes especificaciones detalladas desde el principio, la documentación en ágil se elabora a medida que avanza el proyecto y evoluciona el entendimiento de los requisitos. Este enfoque permite flexibilidad y adaptabilidad. Niveles de la Ingeniería Ágil de Requerimientos: 1. Visioning (Alta visión o Tema/Épica): Es el nivel más alto y abstracto. Aquí se define el objetivo general o el "tema" (similar a una épica), que abarca un conjunto amplio de funcionalidades. No se entra en detalles técnicos, solo en el "qué" se quiere lograr. 2. Brainstorm (Medio): Se identifican las "características" o grandes funcionalidades que soportarán el tema o la épica. En esta fase, las funcionalidades clave son identificadas y discutidas, pero aún no se profundiza en los detalles. 3. Breakdown (Pequeño): Las características se descomponen en "historias de usuario". Aquí comienza a verse más detalle. Cada historia representa un pedazo funcional del sistema que debe completarse en un ciclo corto (generalmente en una iteración o sprint). 4. Deep Dive (Detalles): Finalmente, se realiza una inmersión profunda en los detalles específicos, como las reglas de negocio, pruebas de aceptación, diagramas de actividades, prototipos de interfaz de usuario, y las tareas necesarias para implementar las historias de usuario. Este nivel se va construyendo a medida que se implementan las funcionalidades, y la validación se hace a través de las demos del producto funcionando. En resumen, la especificación en ágil es progresiva, comenzando con una visión general y descomponiéndose en detalles manejables a medida que avanza el desarrollo del proyecto. 40.  parcial 1 INGENIERIA DE REQUERIMIETOS el cono de la incertidumbre El Cono de la Incertidumbre es una representación visual clave en la gestión ágil de proyectos que ilustra cómo disminuye la incertidumbre a medida que el proyecto avanza y se detallan los requisitos y estimaciones. Explicación del diagrama: 1. Tema (Theme): En este punto inicial, los requisitos son muy generales y abstractos. El nivel de incertidumbre es extremadamente alto (hasta 4x), lo que significa que las estimaciones hechas aquí tienen una variabilidad enorme. Por esta razón, hacer promesas basadas en un "tema" sería arriesgado y poco fiable. 2. Épicas (Epic): A medida que el proyecto progresa y las épicas son definidas, la incertidumbre comienza a disminuir, pero aún sigue siendo significativa. Las épicas son grandes bloques funcionales, que pueden abarcar múltiples características. Aunque hay más claridad que en la fase de tema, las estimaciones aún son imprecisas. 3. Características (Feature): En esta fase, se desglosan las épicas en características más manejables. El nivel de incertidumbre ha disminuido considerablemente (alrededor de 2x), y las estimaciones son más confiables. Sin embargo, todavía no es recomendable comprometerse firmemente, aunque las proyecciones ya tienen una base más sólida. 4. Historias de Usuario (Story): Aquí es donde los requisitos y las actividades están mejor definidos. Las historias de usuario representan pequeñas piezas de funcionalidad que se pueden completar en una iteración. La incertidumbre es mucho menor, lo que permite hacer estimaciones más precisas. En este punto es más seguro realizar compromisos, ya que se tiene una mejor comprensión del alcance. 5. Tareas (Task): Finalmente, en el nivel de tareas, la incertidumbre es mínima (0.5x a 0.25x). Cada historia de usuario se descompone en tareas específicas que los equipos pueden ejecutar directamente. En este nivel, las promesas y compromisos son mucho más factibles, porque se ha reducido casi completamente la variabilidad en las estimaciones. Lecciones claves: No hacer promesas tempranas: Intentar comprometerse a nivel de tema o épica es problemático debido a la alta variabilidad en las estimaciones. Esperar a que se reduzca la incertidumbre: Las decisiones importantes deben tomarse cuando el nivel de detalle es mayor y la variabilidad de las estimaciones es mucho más baja, como en los niveles de historias de usuario o tareas. Este diagrama refuerza la idea ágil de avanzar de lo general a lo específico, y cómo a medida que descomponemos los requisitos, la capacidad de hacer predicciones confiables mejora 41.  parcial 1 INGENIERIA DE REQUERIMIETOS La Elicitación de Requisitos, según el proceso descrito por Loucopoulos La Elicitación de Requisitos, según el proceso descrito por Loucopoulos, implica un enfoque estructurado para obtener un entendimiento profundo del problema que se busca resolver a través de software. Aquí se detallan las principales partes del proceso: Propósito: Obtener conocimiento relevante sobre el problema con el fin de crear una especificación precisa del software que lo resolverá. Al finalizar esta fase, el analista debería convertirse en un "experto" en el dominio del problema, con un conocimiento exhaustivo del mismo. Inputs: Expertos del dominio: Personas que tienen profundo conocimiento en el área específica del problema. Literatura sobre el dominio: Información escrita que ayuda a comprender el contexto y antecedentes del problema. Software existente: Revisión de otros sistemas de software similares en el mismo o diferentes dominios. Estándares nacionales e internacionales: Normativas que influyen en el desarrollo del software. Otros stakeholders: Todos aquellos con un interés o influencia en el proyecto. Actividades: Identificación de fuentes de conocimiento: Descubrir de dónde se puede obtener la información más valiosa. Evaluación de la relevancia del conocimiento: Decidir qué información es más útil y aplicable. Comprensión del impacto: Analizar cómo la información influye en el problema y su solución. Técnicas utilizadas: Entrevistas, prototipos, y reutilización del conocimiento adquirido previamente. Productos: Creación de modelos: Durante este proceso, se desarrollan diferentes tipos de modelos (conceptuales y luego más detallados). Modelos mentales del analista: Inicialmente, los modelos son más abstractos y conceptuales, pero con el tiempo se enfocan más en soluciones específicas de software. Sucesión de modelos: Los modelos evolucionan desde representaciones generales del dominio del problema hasta detalles orientados al software. Interacción con otros procesos: Material base: Los resultados de la elicitación alimentan otros procesos del desarrollo de software. Ejecución en paralelo: La elicitación puede ocurrir junto a otras fases del desarrollo, permitiendo un enfoque iterativo. Este enfoque resalta la importancia de dedicar tiempo suficiente a la fase de elicitación, ya que esta define la base sobre la cual se construirán las soluciones de software. Además, resalta cómo las metodologías ágiles permiten una evolución continua de los modelos, ajustándose a nuevos descubrimientos sobre el problema y las necesidades del usuario.