Ingeniería del Software I

Presentación del tema: "Ingeniería del Software I"— Transcripción de la presentación:

1 Ingeniería del Software I
El contenido de los temas fue tomado del libro Un Enfoque Práctico de Pressman

2 Filosofías y Enfoques

3 Unidad II – 2 Enfoques de la ingeniería del Software
2.1 ISO / IEC / SPICE 2.1.1 2.1.2 2.2 Ingeniería de sistemas 2.2.1 Sistemas basados en computadora 2.2.2 La jerarquía de la ingeniería de sistemas 2.2.3 Ingeniería de procesos de negocios: una visión general 2.2.4 Ingeniería del producto: una visión general 2.2.5 Modelado de sistemas 2.3 Ingeniería de software 2.3.1 La práctica de la ingeniería del software 2.3.2 Práctica de la comunicación 2.3.3 Práctica de la planeación 2.3.4 Práctica del modelado 2.3.5 Práctica de la construcción 2.3.6 Despliegue 2.4 Ingeniería de requisitos 2.4.1 Un puente hacia el diseño y la construcción 2.4.2 Tareas de la ingeniería de requisitos 2.4.3 Inicio del proceso de la ingeniería de requisitos 2.4.4 Obtención de requisitos 2.4.5 Desarrollo de casos de uso 2.4.6 Construcción del modelado de análisis 2.4.7 Negociación de requisitos 2.4.8 Validación de requisitos

4 Unidad II – 2.1 ISO / IEC / SPICE
ISO/IEC TR 15504/SPICE Define el modelo de referencia de procesos de software y de capacidades de procesos que constituyen la base para la evaluación de procesos de software. Se compone de 9 partes de las cuales la 2, 3 y 9 son normativas y las demás informativas. Ventajas Específico para el desarrollo y mantenimiento de software. Fácil de entender (24 procesos). Definido como un conjunto de procesos. Orientado a mejorar los procesos para contribuir a los objetivos del negocio. Desventajas No es práctico ni fácil de aplicar. Tiene solamente lineamientos para un mecanismo de evaluación. Todavía no es norma internacional. Para evaluar el proceso o buen funcionamiento de un software se utiliza algunos estándares de calidad de la norma ISO: La evaluación de un proceso se define como el examen disciplinado de los procesos usados en una organización junto a un conjunto de criterios para determinar la capacidad de esos procesos para ser realizados dentro de los objetivos de calidad, coste y planificación. El propósito es caracterizar la práctica actual, identificando debilidades y fortalezas y la habilidad del proceso para controlar o evitar las causas de baja calidad, desviaciones en coste o planificación.

5 Unidad II – 2.1 Enfoques de la ingeniería de software
ISO/IEC TR 15504/SPICE Así, en 1984, el Depto. de Defensa (DoD) de los Estados Unidos establece al SEI (Software Engineering Institute) de la Univ. Carnegie Mellon como Centro de Investigación y Desarrollo financiado con la misión de liderar los avances para la mejora de la calidad de los sistemas dependientes del software [35]. ISO plasma los estándares de calidad y desarrollo en 1987 con la norma ISO 9000, un conjunto. de estándares internacionales para sistemas de calidad; en particular ISO 9001 e ISO son aplicables al proceso software y a organizaciones de desarrollo software [42]. La Organización Nacional de Estandarización (ISO) ha establecido el estándar ISO 9001:2000, para definir los requisitos de un sistema de gestión de calidad que sirva para elaborar productos de más alta calidad y así mejorar la satisfacción del cliente. Este estándar subraya la importancia que tiene para una organización identificar, implementar, gestionar y mejorar de manera continua la efectividad de los procesos necesarios para el sistema de administración de calidad y, gestionar las interacciones de estos procesos para conseguir los objetivos de la organización. (Planear, hacer, revisar y actuar), lo cual se aplica a los elementos de gestión de calidad de un proyecto de software. *Planear: establece los objetivos, las actividades y tareas del proceso necesario para conseguir un software de alta calidad y una satisfacción del cliente. *Hacer: implementa el proceso de software (incluida las actividades del marco de trabajo y las actividades sombrilla). Revisar: monitorea y mide el proceso para asegurarse de que todos los requisitos establecidos para la gestión de calidad hayan sido cumplidos.

6 ISO/IEC TR 15504/SPICE Actuar: inicia las actividades de mejoramiento del proceso de software, el cual tiene una continuidad de trabajo para mejorar el proceso. De acuerdo con inspecciones y encuestas recientes en todo el mundo [60], el estándar ISO 9001 es el más popular en el mundo de la ingeniería del software, seguido de CMM o CMMI (Modelo de Capacidad y Madurez) e ISO/IEC (SPICE) Estándar Spice (ISO/IEC 15504: define un conjunto de requisitos para la evaluación del proceso de software; lo que pretende es ayudar a las organizaciones en el desarrollo de una evaluación objetiva de la eficacia de cualquier proceso de software definido(SPI99) Estándar IEEE corresponde a las siglas de The Institute of Electrical and Electronics Engineers, el Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías, como ingenieros eléctricos, ingenieros en electrónica, ingenieros en sistemas e ingenieros en telecomunicación.... Su creación se remonta al año 1884, contando entre sus fundadores a personalidades de la talla de Thomas Alva Edison, Alexander Graham Bell y Franklin Leonard Pope. En 1963 adoptó el nombre de IEEE al fusionarse asociaciones como el AIEE (American Institute of Electrical Engineers) y el IRE (Institute of Radio Engineers). A través de sus miembros, más de voluntarios en 175 países, el IEEE es una autoridad líder y de máximo prestigio en las áreas técnicas derivadas de la eléctrica original: desde ingeniería computacional, tecnologías biomédica y aeroespacial, hasta las áreas de energía eléctrica, control, telecomunicaciones y electrónica de consumo, entre otras. Según el mismo IEEE, su trabajo es promover la creatividad, el desarrollo y la integración, compartir y aplicar los avances en las tecnologías de la información, electrónica y ciencias en general para beneficio de la humanidad y de los mismos profesionales

7 ISO/IEC TR 15504/SPICE Algunos de los estándares de la IEEE son: IEEE 1394 IEEE 488 y sus estándares propuestos. IEEE 802 y sus estándares propuestos. Qué es IEEE? THE INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS INC. , IEEE. Es una Sociedad Profesional con membresía en todo el mundo. Se empeña en actividades técnicas educacionales y profesionales que promueven la teoría y la práctica de la electro tecnología para el desarrollo personal y profesional de sus miembros. Fomenta el conocimiento y los avances científicos y tecnológicos, los cuales, miembros del IEEE transforman en productos prácticos y seguros, y en procedimientos que engrandecen la calidad de vida. Vision del IEEE Fomentar el avance de la Prosperidad Global mediante: Promoción de la Inovación Tecnológica. Promover una comunidad Global Apoyar el desarrollo Profesional de la membresía El IEEE está organizado administrativamente por Regiones y Secciones.

8 2.2.1 Sistemas basados en computadora
Unidad II – 2.2 Ingeniería de sistemas 2.2.1 Sistemas basados en computadora Antes de que sea posible construir el software, por medio de la ingeniería, se debe entender el sistema en que éste reside. Para lograrlo es necesario determinar el objetivo general del sistema; se debe identificar, analizar, especificar, modelar, validar y gestionar los requisitos operacionales. Estas actividades son el fundamento de la ingeniería de sistemas. Un ingeniero de sistemas es el encargado de trabajar para entender los requisitos del sistema que pide el cliente, usuario futuros y otros interesados. Por lo tanto antes de empezar cualquier proceso se debe entender perfectamente que es lo que está pidiendo el cliente para así evitar posibles errores, para lo cual se deben identificar los objetivos y requisitos operacionales más detallados al obtener información del cliente; se analizan los requisitos para evaluar su claridad, si está completo y es consistente; se crea una especificación, que por lo general está incorporada a un modelo de sistema, que después lo validan los participantes y clientes. Por último, se gestionan los requisitos del sistema para asegurar que los cambios se controlan de manera apropiada. Para verificar el producto obtenido se debe producir una representación efectiva del sistema, como consecuencia de la ingeniería del mismo. Se puede realizar a través de un prototipo, una especificación o incluso un modelo simbólico, pero debe comunicar las características operativas, funcionales y de comportamiento del sistema que se va a construir e incorporarlo dentro de la arquitectura del sistema. Se está seguro que el producto está hecho correctamente mediante una revisión de todos los productos de trabajo obtenidos, para verificar su claridad, si está completa y es consistente.

9 2.2.1 Sistemas basados en computadora
La palabra sistema tal vez sea el término más usado y del que más se abusa en el léxico técnico. Se habla de sistemas políticos, sistemas educativos, de sistemas de aviación y sistemas de fabricación, de sistemas bancarios y sistemas de locomoción. Sistema es un conjunto o disposición de cosas relacionadas que forman una unidad o un todo orgánico. También se puede definir como una serie de hechos, principios, reglas, etcétera, clasificado y dispuestos de manera ordenada que muestran un plan lógico de la unión de las partes. También se define como un conjunto o disposición de elementos que están organizados para cumplir una meta predefinida al procesar información. Elementos de un sistema: Software: Programas de computadora. Parte intangible del computador. Sirve para hacer efectivo el método, procedimiento o control lógico que se requiere. Hardware: Parte tangible del computador. Son los dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (computadores de red, dispositivos de telecomunicación) que permiten el flujo de datos, y dispositivos electromecánicos (sensores, motores. Bombas) que proporcionan una función externa, del mundo real. Personas: Usuarios y operadores de hardware y software. Bases de datos: Una extensa y organizada recopilación de información a la cual se tiene acceso a través de software y que persiste a través del tiempo. Documentación: Información descriptiva(modelos, especificaciones, manuales, archivos de ayuda en línea, sitios web) que detalla el uso y operación del sistema.

10 2.2.1 Sistemas basados en computadora
Procedimientos: Los pasos que definen el uso específico de cada elemento del sistema o el contexto de procedimientos en que reside le sistema. Todos estos elementos se combinan de varias maneras para transformar la información. La buena ingeniería de sistemas comienza con un entendimiento claro del contexto, la visión global, y después de manera progresiva, el enfoque se delimita hasta la comprensión de los detalles técnicos. El papel del ingeniero de sistemas es definir los elementos de un sistema específico basado en computadora en el contexto de la jerarquía global de sistemas (macro elementos).

11 2.2.2 La jerarquía de la ingeniería de sistemas
Unidad II – 2.2 Ingeniería de sistemas 2.2.2 La jerarquía de la ingeniería de sistemas Comienza con una visión global, en donde se analiza la necesidad de elementos del sistema (información, software, hardware, personas) al final se inicia el análisis, diseño y construcción del elemento final del sistema deseado. Dominio de negocio o de producto Visión global Dominio de interés Elemento del sistema Visión del dominio Visión del elemento Visión detallada

12 2.2.3 Ingeniería de procesos de negocios: una visión general
Unidad II – 2.2 Ingeniería de sistemas 2.2.3 Ingeniería de procesos de negocios: una visión general La meta de la ingeniería de proceso de negocios(IPN) es definir arquitecturas que permitan que un negocio utilice información de manera efectiva. Cuando las necesidades de tecnología de información de una compañía se observan de manera global, casi no hay duda de que se requiera la ingeniería de sistemas. No solo se requiere la especificación de la arquitectura de computo apropiada, sino también se debe desarrollar la arquitectura de software que puebla la configuración única de fuentes de computo de la organización. La ingeniería de procesos de negocio es un enfoque que crea un plan general para implementar la arquitectura de cómputo , para lo cual se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocios. Arquitectura de datos : proporciona un marco de trabajo para las necesidades de información de un negocio o de una función de negocios. Objeto de los datos (contiene atributos que definen aspectos), las relaciones identificadas entre estos datos (forma en que los objetos están conectados entre sí: Cliente y producto A, los dos objetos pueden conectarse por la relación compra, es decir, un cliente compra un producto A, o un producto A es comprado por un cliente. Arquitectura de aplicaciones: abarca aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito de negocio. La arquitectura de aplicación es el sistema de programas (software)que realiza esta transformación. Infraestructura de la tecnología : proporciona el fundamento para las estructuras de datos y de aplicación. La infraestructura comprende el hardware y el software con que se apoyan las aplicaciones y los datos. Esto incluye computadoras, sistemas de operación, redes de computadora, enlaces de telecomunicaciones, tecnologías de almacenamiento y la arquitectura (cliente – servidor) diseñada para implementar estas tecnologías.

13 2.2.3 Ingeniería de proceso de negocios : una visión general
Dominio de negocio o de producto Planeación estratégica de la información (visión global) Área del negocio Análisis del área de negocio(visión de dominio) Un área de negocio Requisito de proceso Sistema de información Diseño del sistema del negocio (visión del elemento) Ingeniero de software Construcción e integración (visión detallada) Arquitectura de la ingeniería del proceso del negocio

14 2.2.3 Ingeniería del producto: una visión general
El producto completo Ingeniería de requisitos (visión global) Capacidades Hardware Ingeniería de componente (visión de dominio) Software Requisito de proceso Datos Función Comportamiento Modelado de análisis y diseño(visión del elemento) Ingeniero de software Componentes de programa Construcción e integración (visión detallada) Arquitectura de la ingeniería de producto

15 2.2.4 Ingeniería del producto: una visión general
Unidad II – 2.2 Ingeniería de sistemas 2.2.4 Ingeniería del producto: una visión general La meta de la ingeniería del producto es traducir el deseo del cliente, de una serie de capacidades definidas, a un producto del trabajo. Para conseguir esta meta la ingeniería de producto, como la ingeniería de procesos de negocios debe crear una arquitectura y una estructura. La arquitectura abarca cuatro componentes de sistemas distintos: software, hardware, datos (y base de datos) y personas. Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de información y control, funcionalidad del producto y comportamiento, desempeño general del producto, diseño, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos requisitos, el trabajo de la ingeniería de requisitos es asignar función y comportamiento a cada uno de los cuatro componentes antes descritos. Una vez hecha la asignación comienza la ingeniería de componentes del sistema. La ingeniería de componentes de sistema es en realidad un conjunto de actividades concurrentes que dirige por separado cada uno de los componentes del sistema: ingeniería de software, ingeniería de hardware, ingeniería humana e ingeniería de base de datos. Cada una de estas disciplinas de ingenierías toma una visión de dominio específica, pero es importante señalar que las disciplinas de ingenierías deben establecer y mantener una comunicación activa entre ellas. La visión de elemento para la ingeniería de producto es la disciplina de ingeniería aplicada a un componente asignado. Para la ingeniería de software significa actividades de modelado del análisis y diseño y actividades de construcción y despliegue que abarcan: generación de código, pruebas y tareas de soporte.

16 2.2.5 Modelado de sistemas Unidad II – 2.2 Ingeniería de sistemas
Los modelados de sistemas tienden a ser jerárquicos o estratificados por naturaleza. Modelado Hatley – Pirbhai: Todo sistema basado en computadora puede modelarse como transformación de la información al emplear una plantilla de entrada – proceso – salida. Este modelo representa la entrada, el procesamiento y la salida junto con la interfaz del usuario y el mantenimiento/autocomprobación. Al igual que casi todas las técnicas de modelado utilizadas en la ingeniería de sistemas y de software, la plantilla modelado de sistemas le permite al analista crear una jerarquía en detalle. El diagrama de contexto de sistema (DCS) establece los límites de información entre el sistema que implemente y el ambiente en que opera el sistema. Esto quiere decir, que define todos los productos externos de información que el sistema utiliza, todos los consumidores externos de información que el sistema crea, y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento o autocomprobación.

17 2.3.1 La práctica de la ingeniería de software
Unidad II – 2.3 Ingeniería de software 2.3.1 La práctica de la ingeniería de software Es un amplio arreglo de conceptos, principios, métodos y herramientas que deben considerarse cuando se planea y desarrolla software. Representa los detalles, las consideraciones técnicas y los cómos que están bajo la superficie del proceso de software: las cosas que se necesitarán para realmente construir software de computadora de alta calidad. La práctica de la ingeniería del software la aplican los ingenieros de software y sus gerentes. Existen tres elementos de la práctica que se aplican sin importar el modelo de proceso que se escoja, estos son los conceptos, los principios y los métodos. Un cuarto elemento de la práctica- las herramientas – apoya la aplicación de los métodos. La práctica incluye las actividades técnicas que producen todos los productos de trabajo definidos por el modelo de proceso del software que se ha elegido. Para estar seguro de que lo ha hecho correctamente primero se deben comprender con firmeza los conceptos y principios aplicables al trabajo que se realiza en el momento (por ejemplo: el diseño), después es preciso asegurarse que se ha seleccionado un método apropiado para el trabajo, se debe tener la certeza que se ha entendido la forma de aplicar el método y el uso de las herramientas automatizadas cuando éstas son apropiadas para la tarea, y se debe ser firme en la necesidad de usar técnicas para asegurar la calidad de los productos de trabajo que se produzcan. La práctica de la ingeniería de software en un sentido genérico , la práctica es una colección de conceptos, principios, métodos y herramientas a las que un ingeniero de software recurre a diario. La práctica permite a los gerentes coordinar proyectos de software e ingenieros de la especialidad para construir programas de computadora. La práctica multiplica un modelo de proceso de software con los cómos técnicos y de gestión necesarios para realizar el trabajo. La práctica transforma un enfoque fortuito en algo más organizado, más efectivo y con más probabilidad de alcanzar el éxito.

18 2.3.1 La práctica de la ingeniería de software
Unidad II – 2.3 Ingeniería de software 2.3.1 La práctica de la ingeniería de software ESENCIA DE LA PRACTICA DE LA INGENIERIA DEL SOFTWARE: Entender el problema. Planear una solución (modelado y diseño de software) Llevar a cabo el plan (generación de código) Examinar el resultado para probar la precisión (realización de pruebas y aseguramiento de la calidad). Antes de comenzar un proyecto de software, se debe estar seguro de que tiene un propósito de negocios y de que los usuarios perciben un valor en él. Si el software tiene un valor, este cambiará a lo largo de su vida útil. Por esa razón, el software debe construirse de forma que se le pueda dar mantenimiento.

19 2.3.2 Práctica de la comunicación
Unidad II – 2.3 Ingeniería de software 2.3.2 Práctica de la comunicación Antes de que los requisitos del cliente puedan analizarse, modelarse o especificarse, éstos deben recopilarse por medio de una actividad de comunicación. Antes de comunicar se debe estar seguro de entender el punto de vista de la otra parte, saber un poco de sus necesidades y entonces opinar. La comunicación efectiva (entre pares técnicos, con el cliente u otros participantes del software y con los gerentes de proyecto) está entre las actividades más desafiantes que enfrenta un ingeniero de software. En este contexto se examinan los principios y conceptos de comunicación de acuerdo con la manera en que se aplican en la comunicación con el cliente. La práctica exige de unos principios básicos y fundamentales: Principio #1: Escuchar (clarificar cada punto) Principio #2: Prepararse antes de comunicar (investigar) Principio #3: Alguien debe facilitar la actividad. (líder o mediador) Principio #4: La comunicación cara a cara es lo mejor. (un representante) Principio #5: Tomar notas y documentar las decisiones. Principio #6: Buscar la colaboración (trabajar en equipo) Principio #7: Conservar el enfoque, examinar un módulo a la vez. Principio #8: Si algo no está claro, se hace un dibujo. Principio #9: Una vez que se llega a un acuerdo sobre algo, se debe continuar. Si no se llega a un acuerdo, se debe continuar, o si una característica o función no está clara y no se puede

20 2.3.2 Práctica de la comunicación
Unidad II – 2.3 Ingeniería de software 2.3.2 Práctica de la comunicación clarificar en el momento, se debe continuar. La comunicación, como cualquier actividad de Ingeniería del software, requiere de tiempo. Principio #10: La negociación no es un concurso o un juego. Funciona mejor cuando ambas partes ganan. En muchas ocasiones los ingenieros de software y los clientes deben negociar funciones y características, prioridades y fechas de entrega. La negociación demanda el compromiso y cumplimiento de todas las partes.

21 2.3.2 Práctica de la planeación
Unidad II – 2.3 Ingeniería de software 2.3.2 Práctica de la planeación La actividad de comunicación ayuda al equipo de software a definir sus metas y objetivos generales (por supuesto, sujeto al cambio conforme pasa el tiempo).Sin embargo entender estas metas y objetivos no es lo mismo que definir un plan para llegar a ellos. La actividad de la planeación abarca un conjunto de prácticas técnicas y de gestión que permiten al equipo de software definir un mapa del camino mientras se viaja a través de su meta estratégica y objetivos tácitos. Para la buena realización y éxito de todo proyecto se debe realizar una buena planeación de los objetivos para alcanzar la meta deseada. Sin importar el rigor con el que se conduzca la planeación, los siguientes principios son válidos en todo momento: Entender los alcances del proyecto: tener claro hasta donde se quiere ir. Destino del software. Involucrar al cliente en la actividad de planeación: el cliente define prioridades y establece las restricciones del proyecto. A menudo los ingenieros de software negocian las órdenes de entrega, los límites de tiempo y otros asuntos relacionados con el proyecto. Reconocer que la planeación es iterativa: Debe ajustarse el plan para adaptarlo a los cambio, además, en cuanto comience el trabajo del software es posible que las cosas cambien. Los modelos iterativos e incrementales del proceso dictan la re-planeación basada en la retroalimentación recibida de los usuarios.

22 2.3.2 Práctica de la planeación
Unidad II – 2.3 Ingeniería de software 2.3.2 Práctica de la planeación Estimar con base en el conocimiento disponible: la finalidad de la estimación es proporcionar un indicio del esfuerzo, costo y duración de las tareas, con base en el conocimiento que el equipo tiene del trabajo que se va a realizar. Si la información es vaga o poco confiable, las estimaciones tendrán de igual forma poca confiabilidad. Considerar el riesgo cuando se define el plan: adecuar un buen plan de contingencia como apoyo a la resolución de posibles problemas. Ser realista: mientras se establece el plan de proyecto, se deben considerar posibles errores humanos. Ajustar la granularidad mientras se define el plan: se refiere al grado de detalle que se introduce conforme se desarrolla el plan, o sea granularidad es el detalle con el que algunos elementos de la planeación se representan o dirigen. Planeación con detalle significativo y real. Definir como se intentará asegurar la calidad: si habrán revisiones técnicas formales, estas se deben calendarizar. O sea identificar la forma en que el equipo de software pretende asegurar la calidad del proceso. Describir como se pretende incluir el cambio: el equipo de software debe identificar la forma en que se incluirán los cambios conforme se realiza el trabajo de ingeniería del software. Por ejemplo: el cliente puede solicitar un cambio en cualquier momento. Si se presenta una solicitud de cambio el equipo está obligado a implementarlo de inmediato. Adaptar el plan a menudo y hacer los ajustes cuando se requieran: se debe adaptar el progreso a diario (calendario), se deben buscar áreas problemáticas y situaciones en las que el trabajo

23 2.3.2 Práctica de la planeación
Unidad II – 2.3 Ingeniería de software 2.3.2 Práctica de la planeación Calendarizado no vaya de acuerdo con el trabajo que se ejecuta en realidad. Cuando se encuentran desfases, el plan se ajusta en concordancia con ello. En la búsqueda de mayor efectividad, todos los integrantes del equipo de software deben participar en la actividad de planeación. Solo entonces se dice que son miembros del equipo, cuando están comprometidos con el plan. Una buena planeación se realiza preguntado lo siguiente: Por qué está en desarrollo el sistema? (el propósito del negocio justifica el gasto de personal, tiempo y dinero. Que se hará? Cuando se terminará? es necesario establecer un flujo de trabajo y un tiempo limite. Quién es el responsable de una función? definir las responsabilidades de cada miembro. En donde se ubican dentro de la organización? el cliente, los usuarios y otros participantes también tienen responsabilidades. Cómo se realizará el trabajo en los sentidos técnicos y de gestión? es necesario definir una estrategia técnica y de gestión para el proyecto. Cuando se necesita de cada recurso?

24 2.3.3 Práctica del modelado Unidad II – 2.3 Ingeniería de software
Los modelos de análisis representan los requisitos del cliente. Los modelados de diseño proporcionan una especificación concreta para la construcción del software. El modelado de análisis se enfoca en tres atributos del software: la información que se debe procesar, la función que se debe entregar y el comportamiento que se debe exhibir. Los modelos se crean para obtener un mejor entendimiento de la entidad real que se construirá. Cuando la entidad es un objeto físico (un avión, edificio, y otros), se puede construir un modelo idéntico en forma y tamaño, pero en menor escala. Sin embargo, cuando la entidad es un software, el modelo debe tomar una forma diferente. Debe ser capaz de representar la información que el software transforma, la arquitectura y las funciones que permiten que ocurra la transformación. Los modelos de análisis representan los requisitos del cliente. Los modelos de diseño representan características del software que ayudan a los profesionales a construirlo de manera efectiva.

25 2.3.4 Práctica de la construcción
Unidad II – 2.3 Ingeniería de software 2.3.4 Práctica de la construcción La actividad de construcción abarca una serie de tareas de codificación y realización de pruebas que conducen al software operativo que está listo para entregarlo al cliente o usuario final. En el trabajo de la ingeniería de software la codificación puede ser: La creación directa de código fuente de un lenguaje de programación. La generación automática de código fuente al utilizar una representación intermedia del diseño del componente que será construido. La generación automática de código mediante un lenguaje de programación de cuarta generación (por ejemplo: Visual C++) Existe una serie de principios y conceptos aplicables a la codificación y las pruebas. Principios y conceptos de codificación: Principios de preparación: antes de escribir una línea de código se debe estar seguro de: entender el problema que se intenta resolver, entender los principios y conceptos básicos del diseño, escoger un lenguaje de programación que satisfaga las necesidades del software que se va a construir y el ambiente en que este va a operar, seleccionar un ambiente de programación que proporcione herramientas que faciliten el trabajo, crear un conjunto de pruebas de unidad que serán aplicadas una vez se complete el componente que se va a codificar. Principio de codificación: cuando se comience a escribir el código se debe estar seguro de : restringir los algoritmos al seguir la práctica de la programación estructurada, seleccionar las estructuras de datos que satisfarán las necesidades del diseño, entender la arquitectura del

26 2.3.4 Práctica de la construcción
Unidad II – 2.3 Ingeniería de software 2.3.4 Práctica de la construcción Software y crear interfases que sean consistentes que sean consistentes con ella, mantener la lógica condicional tan simple como sea posible, crear ciclos anidados en una forma que los haga fáciles de probar, seleccionar nombres de variables significativas y seguir otros estándares locales de codificación, escribir código que tenga documentación propia, crear una configuración lineal (por ejemplo, sangrías y líneas en blanco que ayuden a la comprensión del código) Principios de validación: después de haber completado los primeros pases de codificación se debe estar seguro de: conducir un ensayo de código cuando sea apropiado, realizar pruebas de unidad y corregir los errores que se hayan descubierto, re fabricar el código. Principio de las pruebas: es ejecutar el programa con la intención de encontrar posibles errores que aún no se descubren hasta el momento de la codificación definitiva. Una prueba exitosa es aquella en la que se detecta un error que aún no se descubría. Para las pruebas sólo es necesario invertir enfoque y probar hacia fuera.

27 2.3.4 Práctica del despliegue
Unidad II – 2.3 Ingeniería de software 2.3.4 Práctica del despliegue Se debe tener la seguridad de que el cliente sabe qué esperar antes de que se entregue el incremento de software. De lo contrario, el cliente esperará más de lo que se le puede entregar. La actividad del despliegue abarca 3 funciones: Entrega, soporte y retroalimentación. El despliegue se presenta conforme el software avanza a su terminación. Cada ciclo de entrega le proporciona al cliente y a los usuarios finales un incremento de software operativo que provee funciones y características útiles. Cada ciclo de soporte proporciona documentación y asistencia humana para todas las funciones y características introducidas durante todos los ciclos de despliegue que se han presentado hasta la fecha. Cada ciclo de retroalimentación ofrece al equipo de software una guía importante que conduce a modificaciones en las funciones, características y el enfoque que se toma para el siguiente incremento. Se deben administrar las expectativas que el cliente tiene del software. Se debe ensamblar (un CD-ROM)y probar un paquete de entrega completo. Se debe establecer un régimen de soporte antes de entregar el software. (para cubrir las expectativas del cliente) Se debe proporcionar material instructivo apropiado a los usuarios finales (manuales) El software con errores se debe arreglar primero y entregarse después.

28 2.4.1 Un puente hacia el diseño y la construcción
Unidad II – 2.4 Ingeniería de requisitos 2.4.1 Un puente hacia el diseño y la construcción La ingeniería de requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, que es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software. Las actividades de diseño y construcción del software de computadora son desafiantes, creativas y hasta divertidas, de hecho, la construcción es tan irresistible que muchos desarrolladores de software quieren entrar en ella antes de comprender con claridad de qué es lo que se necesita. La parte más difícil de construir un sistema de software es decidir qué construir. Ninguna parte del trabajo estropea tanto el sistema resultante si se hace mal. Ninguna parte es tan difícil de rectificar después. La ingeniería de requisitos establece una base sólida para el diseño y la construcción. Sin ella, el software resultante tiene una alta probabilidad de no satisfacer las necesidades del cliente. Esta ingeniería como todas las demás actividades de la ingeniería del software, debe adaptarse a las necesidades del proceso, el proyecto, el producto y las personas que realizan el trabajo.

29 2.4.2 Tareas de la ingeniería de requisitos
Unidad II – 2.4 Ingeniería de requisitos 2.4.2 Tareas de la ingeniería de requisitos Se debe esperar la realización de una parte del diseño durante el trabajo de los requisitos y una parte del trabajo de requisitos durante el diseño. La ingeniería de requisitos proporciona el mecanismo apropiado para entender lo que el cliente quiere, analizar las necesidades, evaluar la factibilidad, negociar una solución razonable, especificar la solución sin ambigüedades, validar la especificación, y administrar los requisitos conforme éstos se transforman en un sistema operacional. El proceso de la ingeniería de requisitos se lleva a cabo a través de siete distintas funciones: Inicio Obtención Elaboración Negociación Especificación Validación Gestión. (ADECUAR AL CAMBIO) reestructuración.

30 2.4.3 Inicio del proceso de la ingeniería de requisitos
Unidad II – 2.4 Ingeniería de requisitos 2.4.3 Inicio del proceso de la ingeniería de requisitos Todos los involucrados en el proceso deben trabajar en equipo, para así garantizar un excelente trabajo, eso quiere decir que tanto los clientes como los ingenieros de software deben trabajar en conjunto. Para este inicio se realizan varios pasos a seguir: * Identificación de los interesados: realizar una lista de las posibles personas que colaborarían o aportarían información para el proceso. (Un interesado es cualquiera que participa en forma directa en el sistema que se va a desarrollar u obtiene beneficios de éste. *Reconocimiento de múltiples puntos de vista: los requisitos del sistema se exploran desde diversos puntos de vista, en donde los interesados o clientes dan a conocer sus exigencias con respecto al software. *Trabajo con respeto a la colaboración: identificar los requisitos en que todos los clientes están de acuerdo (o interesados) y aéreas de conflicto o inconsistencia (quiere decir donde no están de acuerdo). Una forma de resolver los conflictos en este tipo de situación es someterlos a votación, basados en puntos de prioridad, en donde se le permitirá a cada interesado exponer la importancia relativa de cada requisito propuesto. *Formulación de las primeras preguntas: las preguntas al inicio del proyecto deben ser libres de contexto, se debe centrar en cuales son las preguntas que ayudan a comprender en forma preliminar el problema?

31 2.4.4 Obtención de requisitos
Unidad II – 2.4 Ingeniería de requisitos 2.4.4 Obtención de requisitos Se centra en cuales son las directrices básicas para llevar a cabo una reunión conjunta de recopilación de requisitos. Se debe trabajar en equipo para identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos para la solución. Se debe dedicar mucho tiempo a tratar de decidir qué es lo que se va a construir, que es lo que exige el o los clientes, para así obtener al final el producto esperado. La meta es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto de requisitos de solución preliminares en una atmósfera que conduzca al cumplimiento de la meta. Si un sistema o producto servirá a muchos usuarios de debe tener la completa seguridad de que los requisitos se obtienen de una muestra representativa de los usuarios. Si solo uno de los usuarios define todos los requisitos, el riesgo de rechazo es alto. Se debe reprimir el impulso de ignorar la idea de un cliente por ser muy costosa o poco práctica. La intención aquí es negociar una lista que sea aceptable para todos. Para lograr esto se debe mantener la mente abierta.

32 2.4.5 Desarrollo de casos de uso
Unidad II – 2.4 Ingeniería de requisitos 2.4.5 Desarrollo de casos de uso Los casos de uso se definen desde el punto de vista de un actor. Un actor es un papel que las personas (usuarios) o los dispositivos representan cuando interactúan con el software. Ose que primero se debe definir el conjunto de actores que estarán involucrados en la realización del software. Es importante señalar que un actor y un usuario final no son necesariamente lo mismo. Un usuario típico puede desempeñar varios papeles al usar un sistema, mientras que un actor representa una clase de entidad externa que desempeña un solo papel en el contexto del caso de uso. Ejemplo, quienes operan una máquina exclusivamente. Los requisitos básicos definen 3 clases de actores: Propietario de la casa: usuario Administrador de la configuración: probablemente la misma persona que el propietario, pero en una función diferente. Los sensores: dispositivos agregados al sistema El subsistema de monitoreo: la estación central que monitorea la función en el hogar donde está instalado .

33 2.4.6 Construcción del modelado de análisis
Unidad II – 2.4 Ingeniería de requisitos 2.4.6 Construcción del modelado de análisis Siempre es una buena idea involucrar a los interesados. Una de las mejores formas de hacerlo es pedirle a cada uno que elabore casos de uso que describan la forma en que se utilizará el software. El objetivo del modelo de análisis es describir los dominios requeridos de información, funcionamiento y comportamiento para un sistema basado en computadoras. El modelo cambia en forma dinámica conforme los ingenieros de software aprenden más acerca del sistema que se va a construir y los interesados entienden mejor lo que necesitan. Por esta razón el modelo de análisis es una representación de los requisitos en un momento determinado. Por lo que se espera que éste cambie. Conforme el modelo de análisis evoluciona, ciertos elementos se volverán relativamente estables, por lo que proporcionarán una base sólida para las tareas de diseño que siguen. Sin embargo otros elementos del modelo pueden ser más volátiles, lo que indicará que el cliente aún no entiende por completo los requisitos para el sistema. Elementos del modelo de análisis. Existen muchas maneras de buscar requisitos para un sistema basado en computadora. Algunas personas involucradas con el software dicen que lo mejor es seleccionar un modo de representación y aplicarlo sin tomar en cuenta todos los modos de representación para mostrar el modelo de análisis. (modelo de uso), las diferentes formas de representación obligan al equipo de software a considerar los requisitos desde distintos puntos de vista, un enfoque que tiene mayores probabilidades de descubrir omisiones, inconsistencias y ambigüedades. Los elementos específos del modelo de análisis los determina el método de modelado que se utilice.

34 2.4.7 Negociación de requisitos
Unidad II – 2.4 Ingeniería de requisitos 2.4.7 Negociación de requisitos Es una actividad que sirve a través de la vida técnica y personal . Las mejores negociaciones son aquellas que buscan un resultado del tipo “ganar”, es decir, el cliente gana al obtener el sistema o producto que satisface la mayoría de sus necesidades, y el equipo de software gana al trabajar con presupuesto y límites de tiempo realistas y alcanzables.. En un contexto ideal de la ingeniería de requisitos, las tareas de inicio, obtención y elaboración determinan los requisitos con el suficiente detalle como para emprender los pasos subsecuentes de la ingeniería del software. En realidad esto sucede muy rara vez. En realidad el cliente y el desarrollador entran en un proceso de negociación, en el cual se le debe pedir al cliente un balance de la funcionalidad, el rendimiento y otras características del sistema o producto frente al costo y el tiempo de colocación en el mercado. El objetivo de esta negociación es desarrollar un plan de proyecto que satisfaga las necesidades del cliente al mismo tiempo que refleja las restricciones del mundo real (por ejemplo: tiempo, gente, presupuesto) a las que está sometido el equipo de software. Para esto se debe: *Identificar a los interesados clave en el sistema o subsistema. *Determinación de las condiciones ganadoras de los interesados. *Negociación de las condiciones ganadoras de los interesados para reconciliarlas en conjunto de condiciones del tipo ganar-ganar para todos los involucrados. Este es el criterio clave que nos lleva al ganar-ganar de la ingeniería del software.

35 2.4.8 Validación de requisitos
Unidad II – 2.4 Ingeniería de requisitos 2.4.8 Validación de requisitos Al crear cada elemento del modelo análisis, éste se examina para conocer su consistencia, sus omisiones y ambigüedades. A los requisitos que representa el modelo el cliente les da jerarquía y se agrupan en paquetes de requisitos que se implementan como incrementos de software y se le entregan. Cuando se revisan los requisitos se debe realizar las siguientes preguntas: Cada requisito es consistente con el objetivo general del sistema/producto. Han sido especificado todos los requisitos con el grado apropiado de abstracción.(Si algún requisito es inapropiado en esta etapa) El requisito es necesario en realidad o representa una característica agregada irrelevante para el objetivo del sistema. Está cada requisito limitado . Existe una fuente determinada para cada requisito. Entran algunos requisitos en conflicto con otros. Es alcanzable cada requisito. Se puede probar un requisito una vez que se haya implementado. El modelo de requisito refleja de manera apropiada la información, la función y el comportamiento del sistema que será construido. Se particiona un requisito para mejor comprensión de la información. Se puede simplificar el modelo de requisitos.