Ideas Clave. Unidad 1. Introducción a la Ingeniería del Software PDF

Unidad 1 Recursos de aprendizaje Introducción a la ingeniería del software Ideas claves de la Unidad 1  Unidad 1...

Unidad 1 Recursos de aprendizaje Introducción a la ingeniería del software Ideas claves de la Unidad 1  Unidad 1 Recursos de aprendizaje ÍNDICE Contenido 1.1 Historia de la Ingeniería del software. 3 1.2 Desarrollo de software profesional. Características de un producto de software 4 1.3 Categorías genéricas para las aplicaciones de software 7 1.4 Mitos alrededor del software 9 1.5 Ingeniería de software 11 1.6 Proceso de desarrollo de software 12 1.6.1 Modelos de proceso de software 14 Bibliografía 16  Unidad 1 Recursos de aprendizaje Unidad I. Introducción a la ingeniería del software Es imposible operar en el mundo moderno sin software. Las infraestructuras nacionales y los servicios públicos se controlan mediante sistemas basados en computadoras, y la mayoría de los productos eléctricos incluyen una computadora y un software de control. La fabricación y la distribución industrial están completamente computarizadas, como el sistema financiero. El entretenimiento, incluida la industria musical, los juegos por computadora, el cine y la televisión, usan software de manera intensiva. Por lo tanto, “la ingeniería de software es esencial para el funcionamiento de las sociedades, tanto a nivel nacional como internacional.” (Sommerville, 2011, pág. 4). Comenzaremos la exposición de ideas claves de la unidad número uno con una seria de preguntas y respuestas que nos ayudaran a comprender términos importantes en desarrollo de la asignatura de ingeniería del software. ¿Qué es? El software de computadora es el producto que construyen los programadores profesionales y al que después le dan mantenimiento durante un largo tiempo. (Pressman, 2010) Incluye programas que se ejecutan en una computadora de cualquier tamaño y arquitectura, contenido que se presenta a medida que se ejecutan los programas de cómputo e información descriptiva tanto en una copia dura como en formatos virtuales que engloban virtualmente a cualesquiera medios electrónicos. La ingeniería de software está formada por un proceso, un conjunto de métodos (prácticas) y un arreglo de herramientas que permite a los profesionales elaborar software de cómputo de alta calidad. ¿Quién lo hace? Los ingenieros de software elaboran y dan mantenimiento al software, y virtualmente cada persona lo emplea en el mundo industrializado, ya sea en forma directa o indirecta. (Pressman, 2010) ¿Por qué es importante? El software es importante porque afecta a casi todos los aspectos de nuestras vidas y ha invadido nuestro comercio, cultura y actividades cotidianas. La ingeniería de software es importante porque nos permite construir sistemas complejos en un tiempo razonable y con alta calidad. (Pressman, 2010) ¿Cuáles son los pasos? El software de computadora se construye del mismo modo que cualquier producto exitoso, con la aplicación de un proceso ágil y adaptable para obtener un resultado de mucha calidad, que satisfaga las necesidades de las personas que usarán el producto. En estos pasos se aplica el enfoque de la ingeniería de software. (Pressman, 2010) ¿Cuál es el producto final? Desde el punto de vista de un ingeniero de software, el producto final es el conjunto de programas, contenido (datos) y otros productos terminados que constituyen el software de computadora. Pero desde la perspectiva del usuario, el producto final es la información resultante (Pressman, 2010) En la actualidad, el software tiene un papel dual. “Es un producto y al mismo tiempo es el vehículo para entregar un producto.” (Pressman, 2010) En su forma de producto, brinda el potencial de cómputo incorporado en el hardware de cómputo, con más amplitud, en una red de computadoras a las que se accede por medio de un hardware local. Ya sea que resida en un teléfono móvil u opere en el interior de una computadora central, el software es un transformador de información —produce, administra, adquiere, modifica, despliega o transmite información que puede ser tan simple como un solo bit o tan compleja como una presentación con multimedios generada a partir de datos obtenidos de decenas de fuentes  Unidad 1 Recursos de aprendizaje independientes—. Como vehículo utilizado para distribuir el producto, el software actúa como la base para el control de la computadora (sistemas operativos), para la comunicación de información (redes) y para la creación y control de otros programas (herramientas y ambientes de software). 1.1 Historia de la Ingeniería del software. El concepto “ingeniería de software” se propuso originalmente en 1968, en una conferencia realizada para discutir lo que entonces se llamaba la “crisis del software” (Naur y Randell, 1969). Se volvió claro que los enfoques individuales al desarrollo de programas no escalaban hacia los grandes y complejos sistemas de software. Éstos no eran confiables, costaban más de lo esperado y se distribuían con demora. A lo largo de las décadas de 1970 y 1980 se desarrolló una variedad de nuevas técnicas y métodos de ingeniería de software, tales como la programación estructurada, el encubrimiento de información y el desarrollo orientado a objetos. Se perfeccionaron herramientas y notaciones estándar y ahora se usan de manera extensa. Algunas de las definiciones importantes las enumeramos a continuación 1. 1968: La conferencia NATO Software Engineering define la ingeniería del software como "el establecimiento y uso de principios sólidos de la ingeniería para obtener software económico que sea confiable y que funcione eficientemente en máquinas reales". 2. 1972: F.P. Brooks en su libro "The Mythical Man-Month" describe la ingeniería del software como "la planificación, diseño, codificación, prueba y mantenimiento del software". 3. 1979: Tom DeMarco y P.J. Plauger definen la ingeniería del software como "el uso de principios sólidos de la ingeniería para obtener software que sea confiable y que funcione eficientemente en máquinas reales". 4. 1991: El IEEE (Institute of Electrical and Electronics Engineers) define la ingeniería del software como "la aplicación sistemática, disciplinada y cuantificable del enfoque científico y tecnológico para el desarrollo, operación y mantenimiento de software". 5. 2004: El IEEE actualiza su definición de la ingeniería del software como "la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques; es decir, la aplicación de la ingeniería al software". Estas definiciones y otras que se han propuesto a lo largo de la historia de la ingeniería del software, han servido para establecer los principios y prácticas que se deben seguir en el desarrollo de software, con el objetivo de producir sistemas de software confiables, eficientes y económicos. 1.2 Desarrollo de software profesional. Características de un producto de software La ingeniería de software busca apoyar el desarrollo de software profesional, en lugar de la programación individual. Incluye técnicas que apoyan la especificación, el diseño y la evolución del programa, ninguno de los cuales son normalmente relevantes para el desarrollo de software personal. Con el objetivo de ayudarlo a obtener una amplia visión de lo que trata la ingeniería de software, en la pueden consultar las preguntas expuesta al inicio de la exposición de las ideas claves se resumen algunas preguntas planteadas con frecuencia. Muchos suponen que el software es tan sólo otra palabra para los programas de cómputo. No obstante, cuando se habla de ingeniería de software, esto no sólo se refiere a los programas en sí, sino también a toda  Unidad 1 Recursos de aprendizaje la documentación asociada y los datos de configuración requeridos para hacer que estos programas operen de manera correcta. Un sistema de software desarrollado profesionalmente es usualmente más que un solo programa. El sistema por lo regular consta de un número de programas separados y archivos de configuración que se usan para instalar dichos programas. Puede incluir documentación del sistema, que describe la estructura del sistema; documentación del usuario, que explica cómo usar el sistema, y los sitios web para que los usuarios descarguen información reciente del producto. Los ingenieros de software están interesados por el desarrollo de productos de software (es decir, software que puede venderse a un cliente). Existen dos tipos de productos de software: 1. Productos genéricos. Consisten en sistemas independientes que se producen por una organización de desarrollo y se venden en el mercado abierto a cualquier cliente que desee comprarlos. Ejemplos de este tipo de productos incluyen software para PC, como bases de datos, procesadores de texto, paquetes de dibujo y herramientas de administración de proyectos. También abarcan las llamadas aplicaciones verticales diseñadas para cierto propósito específico, tales como sistemas de información de librería, sistemas de contabilidad o sistemas para mantener registros dentales. 2. Productos personalizados (o a la medida). Son sistemas que están destinados para un cliente en particular. Un contratista de software desarrolla el programa especialmente para dicho cliente. Ejemplos de este tipo de software incluyen los sistemas de control para dispositivos electrónicos, sistemas escritos para apoyar cierto proceso empresarial y los sistemas de control de tráfico aéreo. ¿Cuáles son las características del producto de software, que lo distinguen de otros productos? Para poder comprender lo que es el software (y consecuentemente la ingeniería de software), es importante examinar las características del software que lo diferencian de otras cosas que los hombres pueden construir. Cuando se construye un hardware, el proceso creativo humano (análisis, diseño, construcción, prueba) se traduce finalmente en una forma física. Si construimos una nueva computadora, nuestro boceto inicial, diagramas formales del diseño y prototipo de prueba, evolucionan hacia un producto físico (chips, tarjetas de circuitos impresos, fuentes de potencia, etc.) El software es un elemento del sistema que es lógico, en lugar de físico. Por tanto, tiene unas características considerablemente distintas a las del hardware: El software se desarrolla, no se fabrica en un sentido clásico. Aunque existen similitudes entre el desarrollo del software y la construcción del hardware, ambas actividades son fundamentalmente diferentes. En ambas actividades la calidad se adquiere mediante un buen diseño, la fase de construcción del hardware puede introducir problemas de calidad que no existen (o son fácilmente corregibles) en el software. Ambas actividades dependen de las personas, pero la relación entre las personas dedicadas y el trabajo realizado es completamente diferente para el software. Ambas actividades requieren la construcción de un producto pero los enfoques son diferentes. Los costos del software se encuentran en la ingeniería. Esto significa que los proyectos de software no se pueden gestionar como si fueran proyectos de fabricación. El software no se "estropea”. - La figura No.1 describe para el hardware, la proporción de fallo como una función del tiempo. Esa relación denominada frecuentemente kurda de bañadera, indica que el hardware exhibe relativamente muchos fallos al principio de su vida (estos fallos son atribuibles normalmente a efectos del diseño o de la fabricación); una vez corregidos los defectos, la tasa de fallos cae hasta un nivel estacionario  Unidad 1 Recursos de aprendizaje bastante bajos, donde permanecen durante un cierto periodo de tiempo. Sin embargo, conforme pasa el tiempo, el hardware empieza a desgastarse y la tasa de fallos se incrementa. Figura 1: Curva de fallos del hardware. El software no es susceptible a los males del entorno que hacen que el hardware se estropee. Por tanto, en la teoría, la curva de fallos en el tiempo tendría la forma de la figura número dos. Los defectos no detectados harán que falle el programa durante las primeras etapas de su vida. Sin embargo, una vez que se corrigen estos defectos, la curva se aplana. La curva idealizada es una gran simplificación de los modelos reales de fallos del software. Sin embargo, la implicación es clara, el software no se estropea. ¡Pero sí se deteriora! Esto que parece una contradicción, puede comprenderse mejor considerando la curva real que se muestra en la figura 2. Durante su vida, el software sufre cambios (mantenimiento). En la medida en que se hacen los cambios, es bastante probable que se introduzcan nuevos defectos, haciendo que la curva de fallos tenga picos como se ve en la figura 2. Antes de que la curva pueda volver al estado estacionario original, se solicita otro cambio, haciendo que de nuevo se cree otro pico. Lentamente el nivel mínimo de fallos comienza a crecer, el software se va deteriorando debido a los cambios. Figura 2: Curvas de fallos real e idealizada del software. Otro aspecto de ese deterioro ilustra la diferencia entre el hardware y el software. Cuando un componente de hardware se estropea, se sustituye por una pieza de repuesto. No hay piezas de repuesto para el software. Cada fallo en el software indica un error en el diseño, o en el proceso mediante el que se tradujo el diseño a  Unidad 1 Recursos de aprendizaje código de máquina ejecutable. Por tanto, el mantenimiento del software tiene una complejidad considerablemente mayor que la del mantenimiento del hardware. Aunque la industria tiende a ensamblar componentes, la mayoría del software se construye a la medida. Consideremos la forma en la que se diseña y se construye el hardware de control para un producto basado en computadora. El ingeniero de diseño construye un sencillo esquema de la circuitería digital, hace algún análisis fundamental para asegurar que se consigue la función adecuada y va al armario donde se encuentran los catálogos de componentes digitales. Después de seleccionar cada componente, puede solicitarse la compra. A medida que la disciplina del hardware evoluciona, se crea un grupo de componentes de diseño estándar. Tornillos estándar y circuitos integrados preparados para la venta son solamente los 2000 componentes estándar que utilizan los ingenieros mecánicos y eléctricos cuando diseñan nuevos sistemas. Los componentes reutilizables se han creado para que el ingeniero pueda concentrarse en elementos verdaderamente innovadores de un diseño, por ejemplo, las partes del diseño que representan algo nuevo. En el mundo del hardware, la reutilización de componentes es una parte natural del proceso de ingeniería. En el mundo del software es algo que sólo ha comenzado a lograrse en una escala amplia. El componente de software debería diseñarse e implementarse para que pueda volver a ser reutilizado en muchos programas diferentes. En los años 60, se construyeron bibliotecas de subrutinas científicas reutilizables en una amplia serie de aplicaciones científicas y de ingeniería. Esas bibliotecas reutilizaban de forma efectiva algoritmos bien definidos, pero tenían un dominio de aplicación limitado. Hoy en día, hemos extendido nuestra visión de reutilización para abarcar no sólo los algoritmos, sino también las estructuras de datos. Los componentes reutilizables modernos encapsulan tanto datos, como procesos que se aplican a los datos, permitiendo al ingeniero crear nuevas aplicaciones a partir de las partes reutilizables. Por ejemplo, las interfases gráficas de usuario de hoy en día se construyen frecuentemente a partir de componentes reutilizables que permiten la creación de ventanas gráficas, de menús desplegables, y de una amplia variedad de mecanismos de interacción. Vale la pena insistir en que la diferencia más importante entre un producto de software y casi cualquier otro producto de la ingeniería es que el producto de software es intangible, no lo podemos palpar. Esto origina una gran cantidad de problemas que comienzan por la dificultad que se tiene para tener una percepción de su magnitud. Una clasificación de productos de software. El software puede aplicarse en cualquier situación en la que se hayan definido previamente un conjunto específico de pasos procedimentales (es decir, un algoritmo). El contenido y el determinismo de la información son factores importantes a considerar para determinar la naturaleza de una aplicación de software. El contenido se refiere al significado y a la forma de la información de entrada y salida. Por ejemplo, muchas aplicaciones bancarias usan unos datos de entrada muy estructurados (una base de datos) y producen informes con determinados formatos. El software que controla una máquina automática acepta elementos de datos discretos con una estructura limitada y produce órdenes concretas para la máquina en rápida sucesión.  Unidad 1 Recursos de aprendizaje 1.3 Categorías genéricas para las aplicaciones de software Algunas veces es difícil establecer categorías genéricas para las aplicaciones de software que sean significativas. Conforme aumenta la contabilidad del software es más difícil establecer compartimentos nítidamente separados. Las siguientes áreas del software indican la amplitud de las aplicaciones potenciales: Software de sistema. El software de sistemas es un conjunto de programas que han sido escritos para servir a otros programas. Algunos programas de sistemas, como por ejemplo compiladores, editores y utilidades de gestión de archivos, procesan estructuras de información complejas, pero determinadas. Otras aplicaciones de sistemas, como, por ejemplo, ciertos componentes de sistema operativo, utilidades de manejo de periféricos, procesadores de telecomunicaciones, procesan datos en gran medida indeterminados. En cualquier caso, el área del software de sistemas se caracteriza por una fuerte interacción con el hardware de la computadora, una gran utilización por múltiples usuarios, una operación concurrente que requiere una planificación, compartición de recursos y una sofisticada gestión de procesos, unas estructuras de datos complejas y múltiples interfases externas. Software de tiempo real. El software que coordina, analiza, controla sucesos del mundo real conforme ocurren, se denomina de tiempo real. Entre los elementos del software de tiempo real se incluyen: un componente de adquisición de datos que recolectar y gran formato a la información recibida del entorno externo, un componente de análisis que transforma la información según lo requieran la aplicación, un componente de control y salida que responda a entorno externo, y un componente de monitorización que coordina todos los demás componentes, de forma que pueda mantenerse la respuesta en tiempo real (típicamente en el rango de un milisegundo a un segundo). Software de gestión. El proceso de información comercial constituye la mayor de las áreas de aplicación del software. Los sistemas discretos (por ejemplo: nóminas, contabilidad, inventario, etc) han evolucionado hacia el software de sistemas de información de gestión que accede a una o más bases de datos que contienen información comercial. Las aplicaciones en esta área reestructuran los datos existentes para facilitar las operaciones comerciales o gestionar la toma de decisiones. Además de las tareas convencionales de procesamientos de datos, las aplicaciones de software de gestión también realizan el cálculo interactivo (por ejemplo, el procesamiento de transacciones en puntos de ventas). Software de ingeniería y científico. El software de ingeniería y científico está caracterizado por los algoritmos de manejo de números. Las aplicaciones van desde la astronomía a la vulcanología, desde el análisis de la creación de los automotores a la dinámica orbital de las lanzaderas espaciales y desde la biología molecular a la fabricación automática. Sin embargo, las nuevas aplicaciones del área de ingeniería y ciencia se han alejado de los algoritmos convencionales numéricos. El diseño asistido por computadora (CAD), la simulación de sistemas y otras aplicaciones interactivas, han comenzado a conocer características del software de tiempo real e incluso del software de sistemas. Software empotrado (embebido).  Unidad 1 Recursos de aprendizaje Los productos inteligentes se han convertido en algo común en casi todos los mercados de consumo e industriales. El software empotrado reside en memoria de sólo lectura y se utiliza para controlar datos y sistemas de los mercados industriales y de consumo. El software empotrado puede ejecutar funciones muy limitadas y curiosas (por ejemplo: el control de las teclas de un horno de microondas) o suministrar una función significativa y con capacidad de control (por ejemplo: funciones vitales en un automóvil, tales como control de la gasolina, sistemas de frenado, etc). Software de computadoras personales. El mercado del software de computadoras personales ha germinado en las pasadas dos décadas. El procesamiento de textos, las hojas de cálculo, los gráficos por computadora, multimedia, entretenimientos, la gestión de bases de datos, aplicaciones financieras, de negocios y personales y redes o acceso a bases de datos externas son algunas de los cientos de aplicaciones. Software de inteligencia artificial. El software de inteligencia artificial hace uso de algoritmos no numéricos para resolver demás complejos para los que no son adecuados el cálculo pueda análisis directo. Los sistemas expertos, también llamados sistemas basados en el conocimiento, reconocimiento de patrones, red neuronal artificial es, prueba de teoremas, y los fuegos son representativos de las aplicaciones de esta categoría. 1.4 Mitos alrededor del software Alrededor del software hay un grupo de mitos, que provocan que las personas y especialmente los clientes y usuarios se hagan falsas expectativas acerca del proceso de creación de un producto de software y del software en sí. A continuación, exponemos algunos de estos mitos señalados por Pressman en su libro. Mitos de gestión. Mito. Mi gente dispone de herramientas de desarrollo de software más avanzadas, después de todo, les compramos las computadoras más modernas. Realidad. Se necesita más que el último modelo de computadora para hacer un desarrollo de software de gran calidad. Las herramientas de ingeniería de software asistida por computadora (CASE) son más importantes que el hardware para conseguir buena calidad y productividad, aunque la mayoría de los desarrolladores de software todavía no las utilizan eficazmente. Mito. Si fallamos en la planificación, podemos añadir más programadores y recuperar el tiempo perdido. Realidad. El desarrollo de software no es un proceso mecánico como la fabricación. Brooks dice: “Añadir gente a un proyecto de software retrasado lo puede retrasar aún más”. Al principio, esta declaración puede parecer un contrasentido. Sin embargo, cuando se añaden nuevas personas, la necesidad de aprender y comunicarse con el equipo hace que se reduzca la cantidad de tiempo invertido en el desarrollo productivo. Puede añadirse gente, pero sólo de una manera planificada y bien coordinada. Mitos del cliente. Un cliente que solicita una aplicación de software puede ser una persona del despacho de al lado, un grupo técnico de la sala de abajo, el departamento de estadísticas o una empresa externa que solicita un software  Unidad 1 Recursos de aprendizaje bajo contrato. En muchos casos, el cliente cree en los mitos que existen sobre el software, debido a que los gestores y desarrolladores del software hacen muy poco para corregir esa mala información. Los mitos conducen a que el cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que desarrolla el software. Mito. Una declaración general de los objetivos es suficiente para comenzar a escribir los programas, podemos dar los detalles más adelante. Realidad. Una mala definición inicial es la principal causa de trabajo baldío en software. Es esencial una descripción formal y detallada del ámbito de la información, funciones, comportamiento, rendimiento, interfases, ligaduras del diseño y criterios de validación. Estas características pueden determinarse sólo después de una exhaustiva comunicación entre cliente y el analista. Mito. Los requisitos del proyecto cambian continuamente, pero los cambios pueden acomodarse fácilmente, ya que el software es flexible. Realidad. Es verdad que los requisitos del software cambian, pero el impacto del cambio varía según el momento en que se introduzca. Si se pone cuidado al dar la definición inicial, los cambios solicitados al principio pueden acomodarse fácilmente. El cliente puede revisar los requisitos y recomendar las modificaciones con relativamente poco impacto en el costo. Cuando los cambios se solicitan durante el diseño del software, el impacto en el costo crece rápidamente. Ya se han acordado los recursos a utilizar y se ha establecido un marco de trabajo del diseño. Los cambios pueden producir trastornos que requieran recursos adicionales e importantes modificaciones del diseño, es decir, costo adicional. Los cambios en la función, rendimiento, interfases u otras características, durante la implementación (codificación y prueba) pueden tener un impacto importante en el costo. Cuando se solicitan al final de un proyecto los cambios pueden producir un orden de magnitud más caro que el mismo cambio solicitado al principio. Mitos de los desarrolladores. Los mitos en los que aún creen muchos desarrolladores se han ido fomentando durante 50 años de cultura informática. Durante los primeros días del desarrollo del software, la programación se veía como un arte. Las viejas formas y actitudes tardan en morir. Mito. Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado. Realidad. Alguien dijo una vez: “cuánto más pronto se comience a escribir código, más se tardará en terminarlo”. Los datos industriales indican que entre el 50 y el 70% de todo el esfuerzo dedicado a un programa se realizará después de que se le haya entregado al cliente por primera vez. Mito. Hasta que no tengo el programa ejecutándose, realmente no tengo forma de comprobar su calidad. Realidad. Desde el principio del proyecto se puede aplicar uno de los mecanismos más efectivos para garantizar la calidad del software: la revisión técnica formal. La revisión del software es un filtro de calidad que se ha comprobado que es más efectivo que la prueba para encontrar ciertas clases de defectos en el software. Mito. Lo único que se entrega al terminar el proyecto es el programa funcionando.  Unidad 1 Recursos de aprendizaje Realidad. Un programa que funciona es sólo una parte de una configuración de software que incluye muchos elementos. La documentación proporciona el fundamento para un buen desarrollo y lo que es más importante, proporciona una guía para la tarea de mantenimiento del software. Mito. Si el cliente nos está pagando para que nosotros desarrollemos un software, es evidente que él tiene que saber qué es lo que quiere. Realidad. El cliente intuye que necesita un producto software para elevar la calidad de los procesos de la organización, o negocio que dirige, pero está lejos de saber qué es lo que puede lograr con un producto software. Por lo general un usuario conoce tan solo las funcionalidades de las que él se ocupa, pero tiene poco conocimiento de lo que hacen los demás en su área de trabajo y mucho menos tiene idea de cómo lograr la integración de esos procedimientos. El cliente no tiene idea de los posibles resultados que puede lograr con un producto software. Si a esto le añadimos las expectativas que brinda Internet, o una intranet, comprenderemos que sólo mediante un intercambio fluido el cliente y los miembros del equipo de desarrollo, se podrán identificar los verdaderos requisitos que deberá satisfacer el futuro producto software. Muchos profesionales del software reconocen la falacia de los mitos descritos anteriormente. Lamentablemente, las actitudes y métodos habituales fomentan una pobre gestión y malas prácticas técnicas, incluso cuando la realidad dicta un método mejor. El reconocimiento de las realidades del software es el primer paso hacia la formulación de soluciones prácticas para su desarrollo. 1.5 Ingeniería de software Según (Sommerville, 2011), la ingeniería de software es una disciplina de ingeniería que se interesa por todos los aspectos de la producción de software, desde las primeras etapas de la especificación del sistema hasta el mantenimiento del sistema después de que se pone en operación. En esta definición se presentan dos frases clave: 1. Disciplina de ingeniería Los ingenieros hacen que las cosas funcionen. Aplican teorías, métodos y herramientas donde es adecuado. Sin embargo, los usan de manera electiva y siempre tratan de encontrar soluciones a problemas, incluso cuando no hay teorías ni métodos aplicables. Los ingenieros también reconocen que deben trabajar ante restricciones organizacionales y financieras, de modo que buscan soluciones dentro de tales limitaciones. 2. Todos los aspectos de la producción del software La ingeniería de software no sólo se interesa por los procesos técnicos del desarrollo de software, sino también incluye actividades como la administración del proyecto de software y el desarrollo de herramientas, así como métodos y teorías para apoyar la producción de software. Como se observa en la Tabla 3, cada uno de estos aspectos que caracterizan la producción del software toman un papel esencial en la entrega final del producto de software  Unidad 1 Recursos de aprendizaje Figura 3. Atributos esenciales del buen software. (Sommerville, 2011) En general, los ingenieros de software adoptan en su trabajo un enfoque sistemático y organizado, pues usualmente ésta es la forma más efectiva de producir software de alta calidad. No obstante, la ingeniería busca seleccionar el método más adecuado para un conjunto de circunstancias y, de esta manera, un acercamiento al desarrollo más creativo y menos formal sería efectivo en ciertas situaciones. El desarrollo menos formal es particularmente adecuado para la creación de sistemas basados en la Web, que requieren una mezcla de habilidades de software y diseño gráfico. La ingeniería de software es importante por dos razones: 1. Cada vez con mayor frecuencia, los individuos y la sociedad se apoyan en los avanzados sistemas de software. Por ende, se requiere producir económica y rápidamente sistemas confiables. (Sommerville, 2011) 2. A menudo resulta más barato a largo plazo usar métodos y técnicas de ingeniería de software para los sistemas de software, que sólo diseñar los programas como si fuera un proyecto de programación personal. Para muchos tipos de sistemas, la mayoría de los costos consisten en cambiar el software después de ponerlo en operación. (Sommerville, 2011) El enfoque sistemático que se usa en la ingeniería de software según (Sommerville, 2011) se conoce en ocasiones como proceso de software. Un proceso de software es una secuencia de actividades que conducen a la elaboración de un producto de software. Existen cuatro actividades fundamentales que son comunes a todos los procesos de software, y éstas son, según refiere el propio autor: 1. Especificación del software, donde clientes e ingenieros definen el software que se producirá y las restricciones en su operación. 2. Desarrollo del software, donde se diseña y programa el software. 3. Validación del software, donde se verifica el software para asegurar que sea lo que el cliente requiere. 4. Evolución del software, donde se modifica el software para reflejar los requerimientos cambiantes del cliente y del mercado.  Unidad 1 Recursos de aprendizaje 1.6 Proceso de desarrollo de software Un proceso define “quién” está haciendo “qué”, “cuándo” y “cómo” para alcanzar un determinado objetivo. Un proceso de software es una serie de actividades relacionadas que conducen a la elaboración de un producto de software (Sommerville, 2011). Estas actividades pueden incluir el desarrollo de software desde cero en un lenguaje de programación estándar como Java o C. Sin embargo, las aplicaciones de negocios no se desarrollan precisamente de esta forma. El nuevo software empresarial con frecuencia ahora se desarrolla extendiendo y modificando los sistemas existentes, o configurando e integrando el software comercial o componentes del sistema. Existen muchos diferentes procesos de software, pero todos deben incluir cuatro actividades que son fundamentales para la ingeniería de software (Sommerville, 2011): 1. Especificación del software Tienen que definirse tanto la funcionalidad del software como las restricciones de su operación. 2. Diseño e implementación del software Debe desarrollarse el software para cumplir con las especificaciones. 3. Validación del software Hay que validar el software para asegurarse de que cumple lo que el cliente quiere. 4. Evolución del software El software tiene que evolucionar para satisfacer las necesidades cambiantes del cliente. En cierta forma, tales actividades forman parte de todos los procesos de software. Figura 4 Actividades que son fundamentales para la ingeniería de software Por supuesto, en la práctica éstas son actividades complejas en sí mismas e incluyen subactividades tales como la validación de requerimientos, el diseño arquitectónico, la prueba de unidad, etcétera. También existen actividades de soporte al proceso, como la documentación y el manejo de la configuración del software. Cuando los procesos se discuten y describen, por lo general se habla de actividades como especificar un modelo de datos, diseñar una interfaz de usuario, etcétera, así como del orden de dichas actividades. Sin embargo, al igual que las actividades, también las descripciones de los procesos deben incluir (Sommerville, 2011):  Unidad 1 Recursos de aprendizaje 1. Productos, que son los resultados de una actividad del proceso. Por ejemplo, el resultado de la actividad del diseño arquitectónico es un modelo de la arquitectura de software. 2. Roles, que reflejan las responsabilidades de la gente que interviene en el proceso. Ejemplos de roles: gerente de proyecto, gerente de configuración, programador, etcétera como se ilustra en la figura 4. 3. Precondiciones y postcondiciones, que son declaraciones válidas antes y después de que se realice una actividad del proceso o se cree un producto. Figura 5. Roles, que reflejan las responsabilidades de la gente que interviene en el proceso Por ejemplo, antes de comenzar el diseño arquitectónico, una precondición es que el cliente haya aprobado todos los requerimientos; después de terminar esta actividad, una postcondición podría ser que se revisen aquellos modelos UML que describen la arquitectura. Los procesos de software son complejos y, como todos los procesos intelectuales y creativos, se apoyan en personas con capacidad de juzgar y tomar decisiones. No hay un proceso ideal; además, la mayoría de las organizaciones han diseñado sus propios procesos de desarrollo de software. Los procesos han evolucionado para beneficiarse de las capacidades de la gente en una organización y de las características específicas de los sistemas que se están desarrollando. Para algunos sistemas, como los sistemas críticos, se requiere de un proceso de desarrollo muy estructurado. Para los sistemas empresariales, con requerimientos rápidamente cambiantes, es probable que sea más efectivo un proceso menos formal y flexible. 1.6.1 Modelos de proceso de software Un modelo de proceso de software es una representación simplificada de este proceso. (Sommerville, 2011) Cada modelo del proceso representa a otro desde una particular perspectiva y, por lo tanto, ofrece sólo información parcial acerca de dicho proceso. Por ejemplo, un modelo de actividad del proceso muestra las actividades y su secuencia, pero quizá sin presentar los roles de las personas que intervienen en esas actividades. A continuación, se describen algunos modelos de proceso muy generales (en ocasiones llamados “paradigmas de proceso”) (Sommerville, 2011) y se muestran desde una perspectiva arquitectónica. En otras palabras, se ve el marco (framework) del proceso, pero no los detalles de las actividades específicas.  Unidad 1 Recursos de aprendizaje Tales modelos genéricos no son descripciones definitivas de los procesos de software. Más bien, son abstracciones del proceso que se utilizan para explicar los diferentes enfoques del desarrollo de software. Se pueden considerar marcos del proceso que se extienden y se adaptan para crear procesos más específicos de ingeniería de software. (Sommerville, 2011) estos modelos del proceso que se enumeran a continuación: 1. El modelo en cascada (waterfall) Éste toma las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución y, luego, los representan como fases separadas del proceso, tal como especificación de requerimientos, diseño de software, implementación, pruebas, etcétera 2. Desarrollo incremental Este enfoque vincula las actividades de especificación, desarrollo y validación. El sistema se desarrolla como una serie de versiones (incrementos), y cada versión añade funcionalidad a la versión anterior. 3. Ingeniería de software orientada a la reutilización Este enfoque se basa en la existencia de un número significativo de componentes reutilizables. El proceso de desarrollo del sistema se enfoca en la integración de estos componentes en un sistema, en vez de desarrollarlo desde cero. Figura 6. El modelo en cascada (Sommerville, 2011) Figura 7. El modelo de desarrollo incremental. (Sommerville, 2011)  Unidad 1 Recursos de aprendizaje Figura 8. El modelo de ingeniería de software orientada a la reutilización. (Sommerville, 2011) Dichos modelos no son mutuamente excluyentes y con frecuencia se usan en conjunto como se observan en las figuras 6,7 y 8, sobre todo para el desarrollo de grandes sistemas. Para este tipo de sistemas, tiene sentido combinar algunas de las mejores características de los modelos de desarrollo en cascada e incremental. Se necesita contar con información sobre los requerimientos esenciales del sistema para diseñar la arquitectura de software que apoye dichos requerimientos. No puede desarrollarse de manera incremental. Los subsistemas dentro de un sistema más grande se desarrollan usando diferentes enfoques. Partes del sistema que son bien comprendidas pueden especificarse y desarrollarse al utilizar un proceso basado en cascada. Partes del sistema que por adelantado son difíciles de especificar, como la interfaz de usuario, siempre deben desarrollarse con un enfoque incremental. En este momento de la exposición de las ideas claves, se orienta la profundización en el estudio de cada uno de estos paradigmas del proceso de desarrollo del software expuestos por (Sommerville, 2011) en su libro Ingeniería del Software en las páginas 30-36. 1.7 Actividades del proceso de desarrollo de software Los procesos de software real son secuencias entrelazadas de actividades técnicas, colaborativas y administrativas con la meta general de especificar, diseñar, implementar y probar un sistema de software. Los desarrolladores de software usan en su trabajo diferentes herramientas de software. Las herramientas son útiles particularmente para dar apoyo a la edición de distintos tipos de documentos y para manejar el inmenso volumen de información detallada que se reproduce en un gran proyecto de software. Las cuatro actividades básicas descritas en la figura 4, de proceso de especificación, desarrollo, validación y evolución se organizan de diversa manera en diferentes procesos de desarrollo. En el modelo en cascada se organizan en secuencia, mientras que se entrelazan en el desarrollo incremental. La forma en que se llevan a cabo estas actividades depende del tipo de software, del personal y de la inclusión de estructuras organizativas. En la programación extrema, por ejemplo, las especificaciones se escriben en tarjetas. Las pruebas son ejecutables y se desarrollan antes del programa en sí. La evolución incluye la reestructuración o refactorización sustancial del sistema. En esta primera unidad didáctica estudiaremos esta primera actividad de las cuatro descritas con anterioridad, la especificación del software o la ingeniería de requerimientos consisten en el proceso de comprender y definir qué servicios se requieren del sistema, así como la identificación de las restricciones sobre la operación y el desarrollo del sistema. La ingeniería de requerimientos es una etapa particularmente crítica del proceso de software, ya que los errores en esta etapa conducen de manera inevitable a problemas posteriores tanto en el diseño como en la implementación del sistema.  Unidad 1 Recursos de aprendizaje El proceso de ingeniería de requerimientos figura 9 se enfoca en producir un documento de requerimientos convenido que especifique los requerimientos de los interesados que cumplirá el sistema. Por lo general, los requerimientos se presentan en dos niveles de detalle. Los usuarios finales y clientes necesitan un informe de requerimientos de alto nivel; los desarrolladores de sistemas precisan una descripción más detallada del sistema. Existen cuatro actividades principales en el proceso de ingeniería de requerimientos (Sommerville, 2011): 1. Estudio de factibilidad Se realiza una estimación sobre si las necesidades identificadas del usuario se cubren con las actuales tecnologías de software y hardware. El estudio considera si el sistema propuesto tendrá un costo-beneficio desde un punto de vista empresarial, y si éste puede desarrollarse dentro de las restricciones presupuestales existentes. Un estudio de factibilidad debe ser rápido y relativamente barato. El resultado debe informar la decisión respecto a si se continúa o no continúa con un análisis más detallado. 2. Obtención y análisis de requerimientos Éste es el proceso de derivar los requerimientos del sistema mediante observación de los sistemas existentes, discusiones con los usuarios y proveedores potenciales, análisis de tareas, etcétera. Esto puede incluir el desarrollo de uno o más modelos de sistemas y prototipos, lo que ayuda a entender el sistema que se va a especificar. 3. Especificación de requerimientos Consiste en la actividad de transcribir la información recopilada durante la actividad de análisis, en un documento que define un conjunto de requerimientos. En este documento se incluyen dos clases de requerimientos. Los requerimientos del usuario son informes abstractos de requerimientos del sistema para el cliente y el usuario final del sistema; y los requerimientos de sistema son una descripción detallada de la funcionalidad a ofrecer. 4. Validación de requerimientos Esta actividad verifica que los requerimientos sean realistas, coherentes y completos. Durante este proceso es inevitable descubrir errores en el documento de requerimientos. En consecuencia, deberían modificarse con la finalidad de corregir dichos problemas. Figura 9. Proceso de ingeniería de requerimientos. (Sommerville, 2011)  Unidad 1 Recursos de aprendizaje Desde luego, las actividades en el proceso de requerimientos no se realizan simplemente en una secuencia estricta. El análisis de requerimientos continúa durante la definición y especificación, y a lo largo del proceso salen a la luz nuevos requerimientos; por lo tanto, las actividades de análisis, definición y especificación están vinculadas. En los métodos ágiles, como programación extrema, los requerimientos se desarrollan de manera incremental según las prioridades del usuario, en tanto que la obtención de requerimientos proviene de los usuarios que son parte del equipo de desarrollo. 1.8 Los requerimientos Los requerimientos para un sistema son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su operación. Tales requerimientos reflejan las necesidades de los clientes por un sistema que atienda cierto propósito, como sería controlar un dispositivo, colocar un pedido o buscar información. Al proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se le llama ingeniería de requerimientos (IR) Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos son resultado del fracaso de hacer una separación clara entre esos diferentes niveles de descripción. En este texto se distinguen con el uso del término “requerimientos del usuario” para representar los requerimientos abstractos de alto nivel; y “requerimientos del sistema” para caracterizar la descripción detallada de lo que el sistema debe hacer. Los requerimientos del usuario y los requerimientos del sistema se definen del siguiente modo: 1. Los requerimientos del usuario son enunciados, en un lenguaje natural junto con diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las restricciones con las cuales éste debe operar 2. Los requerimientos del sistema son descripciones más detalladas de las funciones, los servicios y las restricciones operacionales del sistema de software. El documento de requerimientos del sistema (llamado en ocasiones especificación funcional) tiene que definir con exactitud lo que se implementará (Sommerville, 2011). Puede formar parte del contrato entre el comprador del sistema y los desarrolladores del software. Los diferentes niveles de requerimientos son útiles debido a que informan sobre el sistema a distintos tipos de lector. En la figura 10 ilustra la diferencia entre los requerimientos del usuario y del sistema. Este ejemplo de un sistema de administración de pacientes para apoyar la atención a la salud mental (MHC-PMS) muestra cómo los requerimientos del usuario se extienden hacia varios requerimientos del sistema. En la figura 10 se observa que el requerimiento del usuario es muy general. Los requerimientos del sistema ofrecen información más específica sobre los servicios y las funciones del sistema que se implementará.  Unidad 1 Recursos de aprendizaje Figura 10. Requerimientos del usuario y requerimientos del sistema (Sommerville, 2011) En resumen, los requerimientos de usuario y del sistema son dos tipos de requerimientos que son esenciales para el proceso de ingeniería de software. Los requerimientos de usuario describen las necesidades y expectativas de los usuarios finales del software, mientras que los requerimientos del sistema describen las funcionalidades, restricciones y objetivos del sistema que se va a desarrollar. A continuación, se describen en detalle cada uno de ellos: Requerimientos de usuario: 1. Describen las necesidades, expectativas y objetivos de los usuarios finales del software. 2. Pueden incluir funcionalidades específicas, requisitos de rendimiento, interfaz de usuario, seguridad, facilidad de uso, etc. 3. Suelen ser descritos en términos generales y no en detalles técnicos. 4. Son importantes para garantizar la satisfacción del usuario final y la adopción del software. Requerimientos del sistema: 1. Describen las funcionalidades y objetivos del sistema que se va a desarrollar. 2. Pueden incluir requisitos de hardware, software, rendimiento, seguridad, mantenibilidad, escalabilidad, etc. 3. Suelen ser descritos en términos técnicos específicos. 4. Son importantes para garantizar que el sistema se desarrolla correctamente y cumple con los objetivos establecidos. Es importante tener en cuenta que ambos tipos de requerimientos son necesarios y deben ser documentados y validados adecuadamente durante el proceso de ingeniería de software para garantizar la calidad y satisfacción del usuario final. Los requerimientos de usuario deben estar alineados con los requerimientos del sistema para garantizar que el software cumpla con las expectativas y necesidades de los usuarios finales, así como con los objetivos y restricciones del sistema que se va a desarrollar.  Unidad 1 Recursos de aprendizaje Es necesario escribir los requerimientos con diferentes niveles de detalle, ya que varios lectores los usarán de distintas formas. La figura 11 muestra los posibles lectores de los requerimientos del usuario y los del sistema. Figura 11. lectores de los requerimientos del usuario y los del sistema. 1.8.1 Requerimientos funcionales y no funcionales A menudo, los requerimientos del sistema de software se clasifican como requerimientos funcionales o requerimientos no funcionales: 1. Requerimientos funcionales. Son enunciados acerca de servicios que el sistema debe proveer, de cómo debería reaccionar el sistema a entradas particulares y de cómo debería comportarse el sistema en situaciones específicas. En algunos casos, los requerimientos funcionales también explican lo que no debe hacer el sistema. 2. Requerimientos no funcionales. Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de desarrollo, como impuestas por los estándares. Los requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a características o a servicios individuales del sistema. Los requerimientos funcionales para un sistema refieren lo que el sistema debe hacer. Tales requerimientos dependen del tipo de software que se esté desarrollando, de los usuarios esperados del software y del enfoque general que adopta la organización cuando se escriben los requerimientos (Sommerville, 2011). Al expresarse como requerimientos del usuario, los requerimientos funcionales se describen por lo general de forma abstracta que entiendan los usuarios del sistema. Sin embargo, los requerimientos funcionales más específicos del sistema detallan las funciones del sistema, sus entradas y salidas, sus excepciones, etcétera. Los requerimientos funcionales del sistema varían desde requerimientos generales que cubren lo que tiene que hacer el sistema, hasta requerimientos muy específicos que reflejan maneras locales de trabajar o los sistemas existentes de una organización. Por ejemplo, veamos algunos de los requerimientos funcionales para el sistema MHC-PMS, que se usan para mantener información de pacientes que reciben tratamiento por problemas de salud mental: 1. Un usuario podrá buscar en todas las clínicas las listas de citas. 2. El sistema elaborará diariamente, para cada clínica, una lista de pacientes que se espera que asistan a cita ese día. 3. Cada miembro del personal que usa el sistema debe identificarse de manera individual con su número de ocho dígitos.  Unidad 1 Recursos de aprendizaje Estos requerimientos funcionales del usuario definen las actividades específicas que debe proporcionar el sistema. Se tomaron del documento de requerimientos del usuario y muestran que los requerimientos funcionales pueden escribirse con diferentes niveles de detalle (contraste los requerimientos 1 y 3) Los requerimientos no funcionales, como indica su nombre, son requerimientos que no se relacionan directamente con los servicios específicos que el sistema entrega a sus usuarios (Sommerville, 2011). Pueden relacionarse con propiedades emergentes del sistema, como fiabilidad, tiempo de respuesta y uso de almacenamiento. De forma alternativa, pueden definir restricciones sobre la implementación del sistema, como las capacidades de los dispositivos I/O o las representaciones de datos usados en las interfaces con otros sistemas. Los requerimientos no funcionales, como el rendimiento, la seguridad o la disponibilidad, especifican o restringen por lo general características del sistema como un todo. Los requerimientos no funcionales a menudo son más significativos que los requerimientos funcionales individuales. Es común que los usuarios del sistema encuentren formas para trabajar en torno a una función del sistema que realmente no cubre sus necesidades. No obstante, el fracaso para cubrir los requerimientos no funcionales haría que todo el sistema fuera inútil. Por ejemplo, si un sistema de aeronave no cubre sus requerimientos de fiabilidad, no será certificado para su operación como dispositivo seguro; si un sistema de control embebido fracasa para cubrir sus requerimientos de rendimiento, no operarán correctamente las funciones de control. Aunque es posible identificar con regularidad cuáles componentes de sistema implementan requerimientos funcionales específicos (por ejemplo, hay componentes de formateo que implementan requerimientos de informe), por lo general es más difícil relacionar componentes con requerimientos no funcionales. La implementación de dichos requerimientos puede propagarse a lo largo del sistema. Para esto existen dos razones: 1. Los requerimientos no funcionales afectan más la arquitectura global de un sistema que los componentes individuales. Por ejemplo, para garantizar que se cumplan los requerimientos de rendimiento, quizá se deba organizar el sistema para minimizar las comunicaciones entre componentes. 2. Un requerimiento no funcional individual, como un requerimiento de seguridad, podría generar algunos requerimientos funcionales relacionados que definan nuevos servicios del sistema que se requieran. Además, también podría generar requerimientos que restrinjan los requerimientos ya existentes. Los requerimientos no funcionales surgen a través de necesidades del usuario, debido a restricciones presupuestales, políticas de la organización, necesidad de interoperabilidad con otro software o sistemas de hardware, o factores externos como regulaciones de seguridad o legislación sobre privacidad. La figura 12 es una clasificación de requerimientos no funcionales.  Unidad 1 Recursos de aprendizaje Figura 12. Tipos de requerimientos no funcionales (Sommerville, 2011) Los requerimientos son una parte importante del proceso de desarrollo de software, ya que permiten definir los objetivos y las características del sistema. En la práctica, en el documento de requerimientos, resulta difícil separar los requerimientos funcionales de los no funcionales. Si los requerimientos no funcionales se expresan por separado de los requerimientos funcionales, las relaciones entre ambos serían difíciles de entender. No obstante, se deben destacar de manera explícita los requerimientos que están claramente relacionados con las propiedades emergentes del sistema, como el rendimiento o la fiabilidad. Esto se logra al ponerlos en una sección separada del documento de requerimientos o al distinguirlos, en alguna forma, de otros requerimientos del sistema El documento de requerimientos de software (llamado algunas veces especificación de requerimientos de software o SRS) es un comunicado oficial de lo que deben implementar los desarrolladores del sistema (Sommerville, 2011). Incluye tanto los requerimientos del usuario para un sistema, como una especificación detallada de los requerimientos del sistema. En ocasiones, los requerimientos del usuario y del sistema se integran en una sola descripción. En otros casos, los requerimientos del usuario se definen en una introducción a la especificación de requerimientos del sistema. Si hay un gran número de requerimientos, los requerimientos del sistema detallados podrían presentarse en un documento aparte. Este documento tiene un conjunto variado de usuarios, desde el administrador ejecutivo de la organización que paga por el sistema, hasta los ingenieros responsables del desarrollo del software. La figura 13, tomada del libro del autor con Gerald Kotonya sobre ingeniería de requerimientos (Kotonya y Sommerville, 1998), muestra a los posibles usuarios del documento y cómo ellos lo utilizan  Unidad 1 Recursos de aprendizaje Figura 13. Usuarios de un documento de requerimientos (Sommerville, 2011) 1.9 Análisis de Requisitos Los procesos de ingeniería de requerimientos incluyen cuatro actividades de alto nivel como se explicó con anterioridad. Éstas se enfocan en valorar si el sistema es útil para la empresa (estudio de factibilidad), descubrir requerimientos (adquisición y análisis), convertir dichos requerimientos en alguna forma estándar (especificación) y comprobar que los requerimientos definan realmente el sistema que quiere el cliente (validación). En la figura 14 presenta este entrelazamiento. Figura 14. Vista en espiral del proceso de ingeniería de requerimientos (Sommerville, 2011)  Unidad 1 Recursos de aprendizaje Las actividades están organizadas como un proceso iterativo alrededor de una espiral, y la salida es un documento de requerimientos del sistema. La cantidad de tiempo y esfuerzo dedicados a cada actividad en cada iteración depende de la etapa del proceso global y el tipo de sistema que está siendo desarrollado. En el inicio del proceso, se empleará más esfuerzo para comprender los requerimientos empresariales de alto nivel y los no funcionales, así como los requerimientos del usuario para el sistema. (Sommerville, 2011) Después de un estudio de factibilidad inicial, la siguiente etapa del proceso de ingeniería de requerimientos es la adquisición y el análisis de requerimientos. En esta actividad, los ingenieros de software trabajan con clientes y usuarios finales del sistema para descubrir el dominio de aplicación, qué servicios debe proporcionar el sistema, el desempeño requerido de éste, las restricciones de hardware, etcétera Figura 15. El proceso de adquisición y análisis de requerimientos (Sommerville, 2011) 1.9.1 Las entrevistas Las entrevistas formales o informales con participantes del sistema son una parte de la mayoría de los procesos de ingeniería de requerimientos. En estas entrevistas, el equipo de ingeniería de requerimientos formula preguntas a los participantes sobre el sistema que actualmente usan y el sistema que se va a desarrollar. Los requerimientos se derivan de las respuestas a dichas preguntas. Las entrevistas son de dos tipos: 1. Entrevistas cerradas, donde los participantes responden a un conjunto de preguntas preestablecidas 2. Entrevistas abiertas, en las cuales no hay agenda predefinida. El equipo de ingeniería de requerimientos explora un rango de conflictos con los participantes del sistema y, como resultado, desarrolla una mejor comprensión de sus necesidades. 1.9.2 Los escenarios Los escenarios son particularmente útiles para detallar un bosquejo de descripción de requerimientos. Se trata de ejemplos sobre descripciones de sesiones de interacción. Cada escenario abarca comúnmente una interacción o un número pequeño de interacciones posibles. Se desarrollan diferentes formas de escenarios y se ofrecen varios tipos de información con diversos niveles de detalle acerca del sistema. Durante el proceso de adquisición, se suman detalles a éste para crear una representación completa de dicha interacción. En su forma más general, un escenario puede incluir:  Unidad 1 Recursos de aprendizaje 1. Una descripción de qué esperan el sistema y los usuarios cuando inicia el escenario. 2. Una descripción en el escenario del flujo normal de los eventos. 3. Una descripción de qué puede salir mal y cómo se manejaría. 4. Información de otras actividades que estén en marcha al mismo tiempo. 5. Una descripción del estado del sistema cuando termina el escenario La adquisición basada en escenarios implica trabajar con los participantes para identificar escenarios y captar detalles a incluir en dichos escenarios. Estos últimos pueden escribirse como texto, complementarse con diagramas, tomas de pantallas, etcétera. De forma alternativa, es posible usar un enfoque más estructurado, como los escenarios de evento o casos de uso 1.9.3 Casos de Usos Los casos de uso son una técnica de descubrimiento de requerimientos que se introdujo por primera vez en el método Objectory (Jacobson et al., 1993). Ahora se ha convertido en una característica fundamental del modelado de lenguaje unificado. En su forma más sencilla, un caso de uso identifica a los actores implicados en una interacción, y nombra el tipo de interacción. Entonces, esto se complementa con información adicional que describe la interacción con el sistema. La información adicional puede ser una descripción textual, o bien, uno o más modelos gráficos como una secuencia UML o un gráfico de estado. Figura 16. Casos de uso para el MHC-PMS (Sommerville, 2011) 1.10 Herramientas de desarrollo de Software Las herramientas de desarrollo del software (llamadas en ocasiones herramientas de Ingeniería de Software Asistido por Computadora o CASE, por las siglas de Computer-Aided Software Engineering) son programas usados para apoyar las actividades del proceso de la ingeniería de software. En consecuencia, estas herramientas incluyen editores de diseño, diccionarios de datos, compiladores, depuradores (debuggers), herramientas de construcción de sistema, etcétera. Las herramientas de software ofrecen apoyo de proceso al automatizar algunas actividades del proceso y brindar información sobre el software que se desarrolla. Los ejemplos de actividades susceptibles de automatizarse son: 1. Desarrollo de modelos de sistemas gráficos, como parte de la especificación de requerimientos o del diseño del software.  Unidad 1 Recursos de aprendizaje 2. Generación de código a partir de dichos modelos de sistemas gráficos. 3. Producción de interfaces de usuario a partir de una descripción de interfaz gráfica, creada por el usuario de manera interactiva. 4. Depuración del programa mediante el suministro de información sobre un programa que se ejecuta. Traducción automatizada de programas escritos, usando una versión anterior de un lenguaje de programación para tener una versión más reciente. Las herramientas pueden combinarse en un marco llamado ambiente de desarrollo interactivo o IDE (por las siglas de Interactive Development Environment). Esto ofrece un conjunto común de facilidades, que usan las herramientas para comunicarse y operar con mayor destreza en una forma integrada. El ECLIPSE IDE se usa ampliamente y se diseñó para incorporar muchos tipos diferentes de herramientas de software. La herramienta que utilizaremos para todo el modelado Enterprise Architect Esta herramienta de modelado y diseño de software fue desarrollada por Sparx Systems. Es una herramienta CASE (Computer-Aided Software Engineering) que permite a los usuarios modelar, diseñar, documentar y construir sistemas de software de forma visual y colaborativa. Entre las características de Enterprise Architect se incluyen: 1. La creación de diagramas de clases, diagramas de secuencia, diagramas de casos de uso, diagramas de actividad y otros tipos de diagramas UML (Unified Modeling Language) y de modelado de procesos de negocio. 2. También es posible generar código a partir de los modelos creados en Enterprise Architect y exportarlos a varios lenguajes de programación, como Java, C++, C#, entre otros. Además, Enterprise Architect es una herramienta colaborativa que permite a varios usuarios trabajar en el mismo proyecto simultáneamente, facilitando la gestión de proyectos de software complejos. También cuenta con herramientas de gestión de requerimientos, seguimiento de cambios y control de versiones. En resumen, Enterprise Architect es una herramienta CASE poderosa y versátil que ofrece una amplia gama de características para el modelado, diseño y construcción de sistemas de software, así como para la gestión de proyectos de software complejos y la colaboración entre usuarios A lo largo del desarrollo de la asignatura por cada una de las actividades o etapas del proceso de software realizaremos con esta herramienta case, todo el proceso de modelado en cada una de las etapas Especificar: 1. Modelo de requerimientos: describe los objetivos, funcionalidades y restricciones del sistema que se va a desarrollar. 2. Modelo de casos de uso: representa cómo los usuarios interactúan con el sistema y describe los escenarios típicos de uso. 3. Modelo de diagrama de clases: identifica las entidades principales del sistema y las relaciones entre ellas. Diseñar 1. Modelo de arquitectura: describe la estructura general del sistema y cómo los componentes se relacionan entre sí.  Unidad 1 Recursos de aprendizaje 2. Modelo de diagrama de secuencia: describe cómo los diferentes componentes del sistema interactúan para llevar a cabo las funcionalidades requeridas. 3. Modelo de diagrama de actividad: describe los procesos y flujos de trabajo dentro del sistema. 4. Modelo de diagrama de componentes: identifica los diferentes componentes que componen el sistema y cómo se relacionan entre sí. Implementar: 1. Modelo de diagrama de clases de implementación: describe cómo los componentes del sistema se implementan en código. 2. Modelo de diagrama de secuencia de implementación: describe cómo las diferentes piezas de código interactúan entre sí para implementar las funcionalidades requeridas. 3. Modelo de diagrama de despliegue: describe cómo el sistema se implementa y se distribuye físicamente en el hardware. Probar: 1. Modelo de casos de prueba: describe los escenarios de prueba y los casos de prueba para asegurar que el sistema cumpla con los requerimientos. 2. Modelo de plan de pruebas: describe cómo se ejecutarán los casos de prueba y cómo se medirán los resultados. 3. Modelo de informe de pruebas: documenta los resultados de las pruebas y las medidas tomadas para corregir los errores y mejorar la calidad del sistema. Es importante tener en cuenta que estos modelos son solo ejemplos y pueden variar según las necesidades del proyecto y la metodología utilizada. Además, algunos modelos pueden ser iterativos y sucesivos, y otros pueden realizarse en paralelo. Bibliografía Pressman, R. S. (2010). INGENIERÍA DEL SOFTWARE. UN ENFOQUE PRÁCTICO., (pág. 2). México. Sommerville, I. (2011). Ingeniería de Software. México. Echeverri, Jaime - Miguel Aristizábal - González, Liliana. Reflexiones sobre ingeniería de requisitos y pruebas de software. Ebook https://elibro.net/es/lc/ube/titulos/68913?fs_q=ingenieria__del__software&prev=fs. 2013 Casado Iglesias, Carlos. Entornos de desarrollo. EbooK. 2014