#1INTRODUCCION A LA INGENIERIA DE SOFTWARE EVOLUCION DEL SOFTWARE

1 geneeracion:La mayoría del software se desarrollaba y era utilizado por la misma persona u organización. La misma persona lo escribía, lo ejecutaba y, si fallaba, lo depuraba. El diseño era un proceso implícito, realizado en la mente de alguien y, la documentación normalmente no existía.

2 generacion:

Se extienden desde la mitad de la década de los sesenta hasta finales de los setenta. La multiprogramación y los sistemas multiusuario introdujeron nuevos conceptos de interacción hombre – máquina. También se caracterizo por el establecimiento del software como producto y la llegada de las «casas del software». Los patronos de la industria, del gobierno y de la universidad se aprestaban a «desarrollar el mejor paquete de software» y ganar así mucho dinero.

3 generacion:

se caracterizo por la llegada y amplio uso de los microprocesadores. El microprocesador ha producido un extenso grupo de productos inteligentes, desde automóviles hasta  hornos microondas, desde robots industriales a equipos de diagnósticos de suero sanguíneo.

4. generacion

La cuarta era de la evolución de los sistemas informáticos se aleja de las computadoras individuales y de los programas de computadoras, dirigiéndose al impacto colectivo de las computadoras y del software.

DEFINICION DE  INGENIERIA DE SOFTWARE

La ingeniería del software es la aplicación de un enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software, que es la aplicación de la ingeniería del software (IEEE, 1990). El enfoque sistemático, disciplinado y cuantificable es con frecuencia calificado de modelo de proceso de software (en el sentido general) o de proceso de desarrollo de software (en el sentido específico).

METODOLOGIAS DEL DESARROLLO DE SOFTWARE  Las metodologías ágiles están revolucionando la manera de producir software, y a la vez generando un amplio debate entre sus seguidores y quienes por escepticismo o convencimiento no las ven como alternativa para las metodologías tradicionales. La evolución de la disciplina de ingeniería del software ha traído consigo propuestas diferentes para mejorar los resultados del proceso de construcción. Las metodologías tradicionales haciendo énfasis en la planificación y las metodologías ágiles haciendo énfasis en la adaptabilidad del proceso, delinean las principales propuestas presentes

DEFINICION DE METODOLOGIA

Una metodología es un conjunto integrado de técnicas y métodos que permite abordar de forma homogénea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo. Las metodologías se basan en una combinación de los modelos de proceso genéricos (cascada, incremental…). Definen artefactos, roles y actividades, junto con prácticas y técnicas recomendadas. La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto para llevarlo a cabo con altas posibilidades de éxito. Una metodología para el desarrollo de software comprende los procesos a seguir sistemáticamente para idear, implementar y mantener un producto software desde que surge la necesidad del producto hasta que cumplimos el objetivo por el cual fue creado

Si esto se aplica a la ingeniería del software, podemos destacar que una metodología:

• Optimiza el proceso y el producto software. • Proporciona métodos que guían en la planificación y en el desarrollo del software. • Define qué hacer, cómo y cuándo durante todo el desarrollo y mantenimiento de un proyecto.

Una metodología define una estrategia global para enfrentarse con el proyecto. Entre los elementos que forman parte de una metodología se pueden destacar: • Fases: tareas a realizar en cada fase. • Productos: E/S de cada fase, documentos. • Procedimientos y herramientas: apoyo a la realización de cada tarea. • Criterios de evaluación del proceso y del producto: permiten determinar si se han logrado los objetivos. El marco de trabajo de una metodología de desarrollo de software consiste en: • Una filosofía de desarrollo de software, con el enfoque o enfoques del proceso de desarrollo de software. • Múltiples herramientas, modelos y métodos para ayudar en el proceso de desarrollo de software. Estos marcos de trabajo están con frecuencia vinculados a algunos tipos de organizaciones, que se encargan del desarrollo, soporte de uso y promoción de la metodología. La metodología con frecuencia se documenta de alguna manera formal.

VENTAJAS DEL USO DE UNA METODOLOGIA

Son muchas las ventajas que puede aportar el uso de una metodología. A continuación se van a exponer algunas de ellas, clasificadas desde distintos puntos de vista. Desde el punto de vista de gestión: • Facilitar la tarea de planificación • Facilitar la tarea del control y seguimiento de un proyecto • Mejorar la relación coste/beneficio • Optimizar el uso de los recursos disponibles • Facilitar la evaluación de resultados y el cumplimiento de los objetivos • Facilitar la comunicación efectiva entre usuarios y desarrolladores Desde el punto de vista de los ingenieros del software: • Ayudar a la comprensión del problema • Optimizar el conjunto y cada una de las fases del proceso de desarrollo • Facilitar el mantenimiento del producto final • Permitir la reutilización de partes del producto Desde el punto de vista del cliente o usuario: • Garantizar un determinado nivel de calidad en el producto final • Ofrecer confianza en los plazos de tiempo fijados en la definición del proyecto • Definir el ciclo de vida que más se adecue a las condiciones y características del desarrollo

Metodologías tradicionales

Las metodologías tradicionales son denominadas, a veces, de forma peyorativa, como metodologías pesadas. Centran su atención en llevar una documentación exhaustiva de todo el proyecto y en

cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto. Otra de las características importantes dentro de este enfoque, son los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es volátil. Las metodologías tradicionales (formales) se focalizan en la documentación, planificación y procesos (plantillas, técnicas de administración, revisiones, etc.)

Metodologías ágiles

Este enfoque nace como respuesta a los problemas que puedan ocasionar las metodologías tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y la planificación adaptativa. Basan su fundamento en la adaptabilidad de los procesos de desarrollo. Estas metodologías ponen de relevancia que la capacidad de respuesta a un cambio es más importante que el seguimiento estricto de un plan.

CAPAS DE LA INGENIERIA DE SOFTWARE

El enfoque de ingeniería del software cuenta con un compromiso organizacional con la calidad porque no es posible incorporar la ingeniería del software en una organización que no está centrada en conseguir calidad. La ingeniería del software es una tecnología multicapa. Se puede ver como un conjunto de componentes estratificados, que reposan sobre ese enfoque de calidad.Estos componentes que forman parte de la ingeniería del software son: • Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestión del proyecto y las actividades de ingeniería. • Métodos: las actividades técnicas requeridas para la creación de productos de trabajo. • Herramientas: la ayuda automatizada para los procesos y métodos

Se puede ver como un conjunto de componentes estratificados, que reposan sobre ese enfoque de calidad.Estos componentes que forman parte de la ingeniería del software son: • Procesos: un marco de trabajo que ayuda al jefe de proyecto a controlar la gestión del proyecto y las actividades de ingeniería. • Métodos: las actividades técnicas requeridas para la creación de productos de trabajo. • Herramientas: la ayuda automatizada para los procesos y métodos

Procesos la capa de proceso define el proceso que se usará para construir el software y las actividades y tareas que un jefe de proyecto tiene que gestionar. se pueden ver todas las actividades, incluyendo las actividades técnicas,como parte del proceso. Una buena ingeniería de software hace que el proceso de software sea más visible, predecible y más útil para aquellos que construyen software.

Métodos

La capa de métodos se centra en las actividades técnicas que se deben realizar para conseguir las tareas de ingeniería. La construcción de software implica una amplia colección de actividades técnicas. La capa de métodos contiene los métodos definidos para realizar esas actividades de forma eficiente.

Herramientas

La capa de herramientas proporciona soporte a las capas de proceso y métodos centrándose en el significado de la automatización de algunas de las actividades manuales. Las herramientas se pueden utilizar para automatizar las siguientes actividades: • Actividades de gestión de proyectos. • Métodos técnicos usados en la ingeniería del software. • Soporte de sistemas general. • Marcos de trabajo para otras herramientas. La automatización ayuda a eliminar el tedio del trabajo, reduce las posibilidades de errores, y hace más fácil usar buenas prácticas de ingeniería del software. Cuando se usan herramientas, la documentación se convierte en una parte integral deltrabajo hecho, en vez de ser una actividad adicional.

Existen una gran variedad de herramientas para múltiples actividades. Entre ellas se pueden destacar las siguientes: • Herramientas de gestión de proyectos.

• Herramientas de control de cambios. • Herramientas de análisis y diseño. • Herramientas de generación de código. • Herramientas de pruebas. • Herramientas de reingeniería. • Herramientas de documentación. • Herramientas de prototipos. Estas herramientas soportan las capas de proceso y de métodos en varias actividades.

#MODELO DE PROCESO DE SOFTWARE Ciclo de vida de desarrollo del software

El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando desde que nace la idea inicial hasta que el software es retirado o remplazado (muere). También se denomina a veces paradigma. Entre las funciones que debe tener un ciclo de vida se pueden destacar: • Determinar el orden de las fases del proceso de software. • Establecer los criterios de transición para pasar de una fase a la siguiente. • Definir las entradas y salidas de cada fase. • Describir los estados por los que pasa el producto. • Describir las actividades a realizar para transformar el producto. • Definir un esquema que sirve como base para planificar, organizar, coordinar, desarrollarUn ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas que se pueden planificar. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto,

recibiendo en cada pasada de ejecución aportaciones a los resultados intermedios que se van produciendo (realimentación). • Fases: una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La

agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). • Entregables: son los productos intermedios que generan las fases. Pueden ser

materiales o inmateriales (documentos, software).

Las actividades genéricas del ciclo de vida del desarrollo del software son: • Especificación: lo que el sistema debería hacer y sus restricciones de desarrollo. • Desarrollo: producción del sistema software.

• Validación: comprobar que el sistema es lo que el cliente quiere. • Evolución: cambiar el software en respuesta a las demandas de cambioModelos de ciclo de vida del software La ingeniería del software se vale de una serie de modelos que establecen y muestran las distintas etapas y estados por los que pasa un producto software, desde su concepción inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como “Cascada” o “Lineal Secuencial”.

Modelo en cascada

Es un enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a la finalización de la

inmediatamente anterior. El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases que componen el ciclo de vida. La primera descripción formal del modelo en cascada se cree que fue en un artículo publicado en 1970 por Winston W. Royce, aunque Royce no usó el término cascada en este artículo. Irónicamente, Royce estaba presentando este modelo como un ejemplo de modelo que no funcionaba, defectuoso. En el modelo original de Royce, existían las siguientes fases: 1. Especificación de requisitos 2. Diseño 3. Construcción (Implementación o codificación) 4. Integración 5. Pruebas 6. Instalación 7. Mantenimiento Para seguir el modelo en cascada, se avanza de una fase a la siguiente en una forma puramente secuencial.

Modelo en V

El modelo en v se desarrolló para terminar con algunos de los problemas que se vieron utilizando el enfoque de cascada tradicional. Los defectos estaban siendo encontrados demasiado tarde en el ciclo de vida, ya que las pruebas no se introducían hasta el final del proyecto. El modelo en v dice que las pruebas necesitan empezarse lo más pronto posible en el ciclo de vida. También muestra que las pruebas no son sólo una actividad basada en la ejecución. Hay una variedad de actividades que se han de realizar antes del fin de la fase de codificación. Estas actividades deberían ser llevadas a cabo en paralelo con las actividades de desarrollo, y los técnicos de pruebas necesitan trabajar con los desarrolladores y analistas de negocio de tal forma que puedan realizar estas actividades y tareas y producir una serie de entregables de pruebas.

El modelo en v es un proceso que representa la secuencia de pasos en el desarrollo del ciclo de vida de un proyecto. Describe las actividades y resultados que han de ser producidos durante el desarrollo del producto. La parte izquierda de la v representa la descomposición de los requisitos y la creación de las especificaciones del sistema. El lado derecho de la v representa la integración de partes y su verificación. V significa “Validación y Verificación”. Realmente las etapas individuales del proceso pueden ser casi las mismas que las del modelo en cascada. Sin embargo hay una gran diferencia. En vez de ir para abajo de una forma lineal las fases del proceso vuelven hacia arriba tras la fase de codificación, formando una v. La razón de esto es que para cada una de las fases de diseño se ha encontrado que hay un homólogo en las fases de pruebas que se correlacionan.

Modelo iterativo

Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el riesgo que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de recogida de requisitos. Consiste en la iteración de varios ciclos de vida en cascada. Al final de cada iteración se le entrega al cliente una versión mejorada o con mayores funcionalidades del producto. El

cliente es quien, después de cada iteración, evalúa el producto y lo corrige o propone mejoras. Estas iteraciones se repetirán hasta obtener un producto que satisfaga las necesidades del cliente. Este modelo se suele utilizar en proyectos en los que los requisitos no están claros por parte del usuario, por lo que se hace necesaria la creación de distintos prototipos para presentarlos y conseguir la conformidad del cliente.

Modelo de desarrollo incremental

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las

funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación. Modelo en espiral El desarrollo en espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado de forma generalizada en la ingeniería del software. Las actividades de este modelo se conforman en una espiral, cada bucle representa un conjunto de actividades. Las actividades no están fijadas a priori, sino que las siguientes se eligen en función del análisis de riesgos, comenzando por el bucle anterior. Al ser un modelo de ciclo de vida orientado a la gestión de riesgos se dice que uno de los

aspectos fundamentales de su éxito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y catalogar correctamente riesgos.

Tareas: Para cada ciclo habrá cuatro actividades:

1. Determinar o fijar objetivos:

Curso de Introducción a la Ingeniería del Software 29  • Fijar también los productos definidos a obtener: requerimientos, especificación, manual de usuario.

• Fijar las restricciones. • Identificar riesgos del proyecto y estrategias alternativas para evitarlos. • Hay una cosa que solo se hace una vez: planificación inicial o previa

2

. Análisis del riesgo:

• Estudiar todos los riesgos potenciales y se seleccionan una o varias alternativas propuestas para reducir o eliminar los riesgos 3. Desarrollar, verificar y validar (probar): • Tareas de la actividad propia y de prueba. • Análisis de alternativas e identificación de resolución de riesgos. • Dependiendo del resultado de la evaluación de riesgos, se elige un modelo para el desarrollo, que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. Así, por ejemplo, si los riesgos de la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podría ser la construcción de prototipos evolutivos.

4. Planificar:

• Revisar todo lo que se ha llevado a cabo, evaluándolo y decidiendo si se continua con las fases siguientes y planificando la próxima actividad. El proceso empieza en la posición central. Desde allí se mueve en el sentido de las agujas del reloj

Modelo de prototipos

El paradigma de construcción de prototipos comienza con la recolección de requisitos. El desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos y las áreas del esquema en donde es obligatoria más definición. Entonces aparece un diseño rápido. El diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario/cliente. El diseño rápido lleva a la construcción de un prototipo. El prototipo lo evalúa el cliente/usuario y se utiliza para refinar los requisitos del software a desarrollar. La iteración ocurre cuando el prototipo se pone a punto para satisfacer las necesidades del cliente, permitiendo al mismo tiempo que el desarrollador comprenda mejor lo que se necesita hacer.

Etiquetas: Ciclo de vida de un sistema semiestructurado, Ciclo de vida del hardware, Ciclo de vida semiestructurado, Examen analista de desarrollo de software