1 presentacion_1_-_ingenieria_de_software[1]

Ingeniería de Software

SENAModulo de introducción a sistemas

Ingeniería de Software y Proceso de Software

Asignatura: Ingeniería del Software Año 2010

Introducción a los Métodos de Desarrollo de Software.

Ingeniería de Software Que es el Software? Proceso de Software Definición de Métodos de desarrollo. Beneficios de usar Métodos. Características deseables. Clasificación. Ejemplos de métodos.


Las economías de los países desarrollados dependen en gran parte del software.

Mas y más sistemas son actualmente controlados por software.

La Ingeniería de Software concierne a teorías, métodos y herramientas para el desarrollo profesional de software.

El gasto en La Ingeniería de Software, representa un alto porcentaje del PIB de los países desarrollados


Que es la Ingenieria de Software ? Cual es la diferencia entre un programador y un

Ingeniero de Software? Cual es la diferencia entre la Ingeniería de

Software y la Ingeniera de Sistemas? Cual es la diferencia entre la Ingenieria de

Software y la Computación ? Que es el software ? Que es un proceso de software ?

Que es la Ingeniería de Software

La Ingeniería de Software es una disciplina de la Ingeniería que concierne a todos los aspectos de la producción de software

Los Ingenieros de Software adoptan un enfoque sistemático para llevar a cabo su trabajo y utilizan las herramientas y técnicas necesarias para resolver el problema planteado, de acuerdo a las restricciones de desarrollo y recursos disponibles.

Diferencia entre Ingenieria de Software y Computación

La computación concierne a la teoría y fundamentos de cualquier sistema de computo, sea de hardware o de software.

La Ingenieria de software concierne solo al desarrollo de sistemas o productos de software

La Ingeniería de Software todavía esta lejos de ser una ciencia como los son la Química o la Física.

Ingenieria de Sistemas e Ingenieria de Software

La Ingeniería de Sistemas concierne a todos los aspectos del desarrollo de sistemas basados en cómputo, que incluyen hardware, software y el proceso de Ingeniería. La Ingeniería de Software es solo parte de este proceso

Que es el Software ?

Programas de cómputo y su documentación asociada. Productos genéricos.

Productos que son producidos por una organización para ser vendidos al mercado.

Productos hechos a medida. Sistemas que son desarrollados bajo pedido a un desarrollador

específico. La mayor parte del gasto del software es en productos genéricos, pero hay

más esfuerzo en el desarrollo de los sistemas hechos a medida.

Características de los Productos de Software

Mantenibles. Debe ser posible que el software evolucione y que siga

cumpliendo con sus especificaciones.

Confiabilidad. El software no debe causar danos físicos o económicos en el

caso de fallos.

Eficiencia. El software no debe desperdiciar los recursos del sistema.

Utilización adecuada. El software debe contar con una interfaz de usuario adecuada y

su documentación.

Costos del Software

Costo Directo: Es el que se paga por adquirir el software, se puede adquirir en un negocio de computación, por Internet o Software a la medida.

Costo Indirecto: Incluye Capacitación, Instalación, soporte técnico.

Costo Oculto: Ocasionado principalmente por las fallas del software a diferencia de los costos directos e indirectos los cuales son previsibles, los costos ocultos son difíciles de prever.

Costos del Software Las consecuencias por fallas del software se pueden

clasificar en: Consecuencias inmediatas y efectos directos: Son los

prejuicios ocasionados mientras dura la caída de los sistemas. Estos costos son relativamente predecibles dado que dependen directamente del tiempo que dure la transacción.

Consecuencias a mediano y largo plazo y efectos indirectos. Son los prejuicios posteriores a la caída del sistema. Las consecuencias varían desde la restauración de los datos, servicios de emergencia, propaganda negativa, perdida de clientes y hasta posible accidentes

Costos del Software

Los costos del software a menudo dominan al costo del sistema. El costo del software en un PC es a menudo mas caro que la PC.

Cuesta mas mantener el software que desarrollarlo. Para sistemas con una larga vida, este costo se multiplica.

La Ingeniería de Software concierne a un desarrollo efectivo en cuanto a costos del software.

Importancia de las características del producto

La importancia relativa de las características depende en el tipo de producto y en el ambiente en el que será utilizado.

En algunos casos, algunos atributos pueden dominar. En sistemas de seguridad críticos de tiempo real,

los atributos clave pueden ser la confiabilidad y la eficiencia.

Los costos tienden a crecer exponencialmente si son requeridos altos niveles de alguna característica.

Que tipos de software hay ?

Por su estructura: Funcionales. Orientados a objetos.

Por su funcion: Programas o Sistemas de Usuario Interfaces Hombre-Maquina. Herramientas de Software. Librerías. Sistemas de uso genérico: Compiladores, S.O’s, Procesadores

de Texto, etc. Bases de Datos. Sistemas basados en Web.

El Proceso de Software

Conjunto estructurado de actividades requeridas para desarrollar un sistema de software. Especificación Diseño Desarrollo Validación Mantenimiento Evolución

Las actividades varían dependiendo de la organización y del tipo de sistema a desarrollarse.

Debe estar explícitamente modelado si va a ser bien administrado.

El Proceso de Software

Proceso Genérico de Software

Especificación - establecer los requerimientos y restricciones del sistema

Diseño - Producir un modelo en papel del sistema Manufactura - construir el sistema Prueba - verificar que el sistema cumpla con las

especificaciones requeridas Instalación - entregar el sistema al usuario y asegurar

su operacionalidad Mantenimiento - reparar fallos en el sistema cuando

sea descubiertos

Características del proceso

Entendible: Se encuentra el proceso bien definido. Soportable: Puede el proceso ser soportado por

herramientas CASE. Aceptable: El proceso es aceptado por aquellos

involucrados en el. Confiable: Los errores del proceso son descubiertos antes

de que se conviertan en errores del producto. Robusto: Puede continuar el proceso a pesar de

problemas inesperados. Mantenible: Puede el proceso evolucionar para cumplir con

los objetivos organizacionales. Rapidez: Que tan rápido puede producirse el sistema.

Modelos del proceso de software

Un modelo de proceso software es una descripción del proceso, desde un punto de vista particular

Un modelo es siempre una simplificación del proceso software, una abstracción del proceso real

Ejemplos: Un modelo de flujo de trabajo – representa la sucesión de actividades

(acciones humanas) en el proceso, en conjunción con sus entradas, salidas y dependencias

Un modelo de flujo de datos – representa un conjunto de actividades, cada una produciendo alguna transformación en los datos; los actividades son de menor nivel que las de un modelo de flujo de trabajo y pueden representar acciones humanas o de las computadoras

Un modelo de rol/acción – representa los roles de la gente involucrada en el proceso de software y las actividades del cual son responsables

Modelos del proceso de software

Los modelos generales del proceso de software (paradigmas del proceso software) son abstracciones útiles para explicar diferentes enfoques para el desarrollo de software

Para desarrollar un sistema muy complejo, se pueden utilizar diferentes procesos de software para diversas partes del sistema

El modelo de cascada El primero modelo de proceso de desarrollo de

software, derivado de otros procesos de ingeniería (Royse, 1970)

Se denomina también como ciclo de vida del software

Representa como fases separadas del proceso las actividades fundamentales de este.

El modelo se denomina “cascada” debido a la cascada de una fase a otra

El modelo de cascada Definición de

Requerimientos

Diseño del Softwarey del Sistema

Implementación yPrueba de unidades

Integración y Prueba del Sistema

Operación yMantenimiento

El modelo de cascada 1. Análisis y definición de requerimientos – los servicios, restricciones y

metas del sistema se definen a partir de las consultas con los usuarios, en detalles, sirviendo como una especificación del sistema

2. Diseño de sistemas y de software – el diseño de sistemas divide los requerimientos en sistemas de hardware o de software y establece una arquitectura completa del sistema; el diseño de software identifica y describe las abstracciones fundamentales del sistema de software y sus relaciones

3. Implementación y prueba de unidades – se obtiene un conjunto o unidades de programas; cada una de las unidades debe cumplir su especificación

4. Integración y prueba del sistema – las unidades individuales se integran y prueban como un sistema completo, que debe cumplir los requerimientos del software

5. Operación y mantenimiento – el sistema se instala y pone en uso práctico; se corigen los errores no descubiertos en las etapas anteriores, se mejora la implementación de las unidades, los servicios del sistema, si se establecen nuevos requerimientos

El modelo de cascada El modelo de cascada es inflexible en dividir el

proyecto en las etapas mencionadas Refleja la practica de la ingeniería, por lo tanto

se siguen utilizando para el desarrollo de software, particularmente cuando éste es parte de proyectos grandes de ingeniería de sistemas

En la practica: Las etapas interaccionan y intercambian

informaciones El proceso no es un modelo lineal simple, sino que

implica una serie de iteraciones de las actividades de desarrollo

El modelo de cascada Las iteraciones son costosas e implican rehacer el

trabajo, por lo tanto es normal congelar partes del desarrollo después de un numero reducido de iteraciones

El congelamiento prematuro de requerimientos puede implicar que el sistema no va a hacer lo que los usuarios desean, o que se obtiene un sistema mal estructurado

También puede aparecer la necesidad de repetir algunos (o todas las) etapas previas del proceso, debido a los errores y omisiones que se descubren, o a la necesidad de nuevas funcionalidades

El desarrollo evolutivo(construcción de prototipos)

Se desarrolla una implementación inicial, exponiéndola a los comentarios del usuario y redefiniéndola a través de las diferentes versiones

Las actividades de especificación, desarrollo y validación se llevan a cabo concurrentemente, y tienen realimentación rápida a lo largo del proceso

Un primer sistema se desarrolla rápidamente, a partir de especificaciones abstractas, y se refina después, con la ayuda del cliente

El desarrollo evolutivo Un enfoque evolutivo para el desarrollo de

software es más efectivo que el de cascada, porque cumple con las necesidades inmediatas de los clientes

La especificación se puede desarrollar de forma creciente

El mejor entendimiento de los usuarios por su problema se reflejará en el sistema software

El desarrollo evolutivo Desde una perspectiva de ingeniería y

administración, el desarrollo evolutivo pone tres problemas: El proceso no es visible – si los sistemas se

desarrollan rápidamente, es muy costoso producir documentos que reflejan cada versión del sistema

frecuentemente los sistemas tienen una estructura deficiente – los cambios continuos tienden a corromper la estructura del software

se requieren herramientas y técnicas especiales – incompatibles con herramientas y técnicas habituales, relativamente pocas personas teniendo habilidades necesarias para utilizarlas

El desarrollo evolutivo

Esquema de la descripción

Especificación Desarrollo Validación

Versión inicial Versiones intermedias Versión final

El desarrollo evolutivo Más adecuado para sistemas pequeños o medianos,

con un periodo de vida relativamente corto Para sistemas grandes, con un periodo de vida largo, es

más eficiente un proceso mixto, que reúna las mejores características del modelo de cascada y el de desarrollo evolutivo: Las partes del sistema bien comprendidas, se especifican y

desarrollan utilizando un proceso basado en el modelo de cascada

Las partes difíciles de especificar por adelantado (la interfaz de usuario, por ejemplo) se desarrollan utilizando un enfoque de programación exploratoria

El desarrollo formal Enfoque parecido al modelo de cascada,

pero el proceso de desarrollo se basa en la transformación matemática formal de una especificación del sistema a un programa ejecutable

El desarrollo de software es incremental, cada etapa se desarrolla y verifica utilizando un enfoque formal

El desarrollo formal

Definición de requerimient

os

Especificación formal

Transformación formal

Integración y prueba del

sistema

El desarrollo formal La especificación formal se refina a través

de una serie de transformaciones, hasta llegar a un programa

La representación matemática formal del sistema se convierte sistemáticamente en una representación mas detallada, matemáticamente correcta, cada paso agregando mas detalles

El desarrollo formal La distancia entre cada transformación es menor

que la distancia entre una especificación y un programa, por lo tanto un enfoque por transformaciones compuesto de una serie de pasos pequeños es mas adecuado para sistemas de gran escala

Por este tipo de sistemas las pruebas son muy largas y pocas practicas

El problema que aparece en el caso del desarrollo formal es de elegir qué transformación aplicar y probar la correspondencia entre transformaciones

El desarrollo basado en reutilización

Se basa en la existencia de un numero significante de componentes reutilizables, cuales se integran en el sistema, más que desarrollarlos desde cero

Aunque en la mayoría de los proyectos software existe algo de reutilización de software, habitualmente esta es una reutilización informal, “empírico”

Las personas que trabajan en el proyecto buscan diseños o códigos similares para modificarlos a lo requerido y incorporarlos en el sistema

El enfoque orientado a reutilización se compone de un gran numero de componentes de software reutilizable, así como de marcos de trabajos para estos


Definición de requerimient

os

Análisis de componente

sModificación

de requerimiento

s

Diseño de sistemas con reutilización Desarrollo e

integración

Validación del

sistema


La primera y la ultima etapa del proceso son similares con otros procesos, pero las etapas intermedias son distintas:

Análisis de componentes – se buscan componentes para implementar la especificación de requerimientos

Modificación de requerimientos – los requerimientos se modifican para reflejar los componentes disponibles; si eso no es posible, se buscan soluciones alternativas

Diseño de sistemas con reutilización – se diseña o se reutiliza un marco de trabajo para el sistema, tomando en cuenta los componentes disponibles; si no hay componentes adecuados, se diseñan otros nuevos

Desarrollo e integración – los componentes disponibles se compran, los componentes no-disponibles se desarrollan y todos los componentes y los sistemas se integran


El modelo orientado a reutilización reduce la cantidad de software a desarrollarse, los costos y los riesgos

El proceso es mas rápido Los compromisos en los requerimientos

son inevitables, existiendo el peligro de obtener un sistema que no cumple las necesidades reales de los usuarios

Modelos de iteración de procesos

Cada modelo de proceso de software tiene ventajas y desventajas

Cada uno es más o poco adecuado para un proceso especifico

Para sistemas grandes, complejos, generalmente deben utilizarse enfoques distintos para distintas parte del sistema

Por eso se deben utilizar modelos híbridos


El diseño y la implementación del sistema deben rehacerse para reflejar los cambios de los requerimientos del sistema, por lo tanto son necesarios iteraciones de procesos

La esencia de los procesos iterativos es que la especificación se desarrolla junto con el software

En el enfoque incremental no existe una especificación completa del sistema hasta que la parte final se especifica: Esto puede crear conflictos en organizaciones donde la

especificación completa del sistema es parte del contrato para el desarrollo del mismo

El enfoque incremental requiere un nuevo tipo de contrato, que a los algunos clientes les es difícil de aceptar


Existen dos principales modelos híbridos que permiten el uso de diferentes enfoques de desarrollo apoyando la iteración de procesos:

El desarrollo incremental – la especificación, el diseño y la implementación del software se dividen en una serie de incrementos los cuales se desarrollan uno a uno

El desarrollo en espiral – el desarrollo gira en espiral hacia fuera, empezando con un esbozo inicial y terminando con el desarrollo final del sistema

El modelo incremental

El desarrollo incremental: sugerido por Mills (1980) un enfoque intermedio que combina las ventajas

del modelo en cascada con las ventajas del modelo de desarrollo evolutivo

combina el modelo lineal secuencial con la filosofía interactiva de construcción de prototipos

El modelo incremental El modelo de desarrollo en cascada: Se administra fácilmente y su separación en el diseño y la

implementación conduce a sistemas robustos, susceptibles a cambios Los cambios de requerimientos durante el desarrollo implican rehacer

el trabajo de captura de estos, de diseño e implementaciónEl modelo de desarrollo evolutivo: Permite que los requerimientos y las decisiones de diseño se retrasen Conduce a un sistema débilmente estructurado y difícil de mantener

El modelo incremental El modelo incremental: Reduce la repetición del trabajo en el proceso de

desarrollo Proporciona a los clientes oportunidades para retrasar

las decisiones en los requerimientos detallados, hasta que adquieren cierta experiencia con el sistema

Los clientes identifican, de forma somera, los servicios que proveerá el sistema, y la importancia de estos servicios

Se definen varios incrementos en donde cada uno proporciona un subconjunto de funcionalidad del sistema

Los servicios de prioridad más alta se entregan primero al cliente

El modelo incremental Los requerimientos para los servicios que se van a entregar en el

primer incremento se definen en detalle y éste se desarrolla utilizando el proceso mas apropiado

Una vez que un incremento se completa, no se aceptan cambios en los requerimientos para el incremento en cuestión

A diferencia de la construcción de prototipos, los clientes pueden ponerlo en servicio, pudiendo utilizar parte de la funcionalidad del sistema (le permite también clarificar sus requerimientos para los incrementes posteriores)

Tan pronto como se implementan los nuevos incrementos, se integran a los existentes, de tal forma que la funcionalidad del sistema mejora con cada incremento

No es necesario utilizar el mismo proceso de desarrollo por cada incremento

Habitualmente se usa un modelo de cascada si los servicios en un incremento tienen una especificación bien definida, o un modelo de desarrollo evolutivo si la especificación no es clara

El modelo incremental Definir

esquema de requerimient

os

Asignar requerimientos a los incrementos

Diseñar la arquitectura del

sistema

Desarrollar incremento

s del sistema

Validar increment

os

Integrar increment

os

Validar sistema

Sistema final


Ventajas: Los clientes no tienen que esperar hasta que el sistema

completo se entregue, cada incremento es una versión de sistema disponible para su uso inmediato

Los incrementos iniciales pueden ser utilizados como prototipos para obtener experiencia sobre los requerimientos de los incrementos posteriores

El riesgo de falla en el proyecto total es bajo, especialmente en las partes mas importantes del sistema, que se entregan primeras (por lo tanto a los servicios mas importantes del sistema les haga más pruebas)


Problemas: Los incrementos (que cada uno debe entregar alguna

funcionalidad del sistema) deben ser relativamente pequeños (menos de 20.000 líneas de código) y, consecuentemente, puede ser difícil adaptar los requerimientos del cliente a incrementos de tamaño apropiado

Es difícil de identificar los recursos comunes que requerían todos los incrementos

El modelo en espiral El modelo en espiral: Propuesto originalmente por Boehm (1988), es un modelo centrado en

actividad Se desarrollo para resolver la debilidad del modelo de cascada El desarrollo gira hacia fuera, empezando con una esquema inicial y

terminando con el desarrollo final del sistema Se basa en las mismas actividades que el modelo de cascada, pero

añade varias tareas: Administración de riesgo Reutilización Elaboración de prototipos

Modelo de Proceso de EspiralDetermine objetivos

alternativas yrestricciones

Evalúe alternativas,identifique y resuelva

riesgosAnálisis de

Riesgos

Análisis deRiesgos

Análisis deRiesgos

Análisis de

Riesgos

Planea la siguiente fase

Desarrolla y verificael siguiente nivel

del producto

PrototipoOperacionalPrototipo

3Prototipo2Proto

tipo 1

Plan de requerimientosPlan del ciclo de vida

REVISIÓN

Plan de Desarrollo

Plan de Integracióny Prueba

Concepto deOperación

Simulaciones, modelos

Requerimientos de

SWValidación deRequerimientos

Servicio

Prueba deAceptación

Prueba deIntegración

Prueba deUnidades

Codificación

DiseñoDetallado

Diseño delProducto

El modelo en espiral Cada ciclo de la espiral se divide en cuatro sectores: Definición de objetivos – se identifican las restricciones del proceso y el

producto, se estipula un plan detallado de administración, se identifican los riesgos y, dependiente de estos, se planean estrategias alternativas

Evaluación de alternativas y reducción de riesgos – se hace un análisis detallado para cada uno de los riesgos del proyecto, definiéndose los pasos para reducir dichos riesgos

Desarrollo y validación – se elige un modelo apropiado por el desarrollo del sistema, según los riesgos identificados

Planeación – Se revisa el proyecto y se toma la decisión de si se debe continuar con un ciclo posterior de la espiral, en este caso planeándose la siguiente fase

El modelo en espiral Cada ciclo de la espiral sigue el modelo de cascada e

incluye las siguientes actividades: Determinar objetivos Especificar restricciones Generar alternativas Identificar riesgos Resolver riesgos Desarrollar y verificar el producto del siguiente nivel Planear

El modelo en espiral A diferencia de otros modelos, el desarrollo en espiral

toma en cuenta de una forma explicita el riesgo La disminución de riesgos es una actividad muy

importante en la administración del proyecto, ya que estos pueden causar problemas graves, como la calendarización y excesos de costos

En el modelo en espiral no existen fases fijas, como la de especificación o diseño

El modelo puede contener otros modelos

Plantilla para una ronda del espiral

Objetivos. Restricciones. Alternativas. Riesgos. Resolución de riesgos. Resultados. Planes. Garantías (commitments).

Ventajas del Modelo de Espiral

Centra su atención en la reutilización de componentes y eliminación de errores en información descubierta en fases iniciales.

Los objetivos de calidad son el primer objetivo.

Integra desarrollo con mantenimiento. Provee un marco de desarrollo de

hardware/software.

Proceso unificado de desarrollo de software

Propuesto por Booch, Jacobson, Rumbaugh

Similar al modelo espiral, el proceso consta de varios ciclos

Cada ciclo termina con la entrega de un producto al cliente


Cada ciclo consta de cuatro fases: Inicio – se define una necesidad o idea y se evalúa

su factibilidad Elaboración – se planea el proyecto, se define el

sistema, se le asignan los recursos Construcción – desarrollo Transición – instalación y posdesarrollo

Cada iteración trata un conjunto de casos de uso relacionados o resuelve un riesgo identificado al inicio de la iteración


A diferencia de otros modelos, enfatiza el escalonamianto de recursos

Asume que las actividades clásicas (análisis, diseño, implementación, pruebas) participan en cada una de las iteraciones, pero en porcentajes distintas, según las características de la etapa


Se utiliza un conjunto de modelos relacionadas: Modelo de casos de uso – captura los requerimientos Modelo de análisis – describe el sistema como un

conjunto de clases Modelo de diseño – define la estructura del sistema como

un conjunto de subsistemas e interfaces Modelo de implementación - establece la correspondencia

entre clases y componentes Modelo de pruebas – verifica que el sistema ejecutable

proporcione la funcionalidad necesaria


Modelo de casos de uso

Modelo de análisis

Modelo de

pruebas

Modelo de implementaci

ón

Modelo de distribució

n

Modelo de diseño

Especificado por

Realizado por

Distribuido por

Implementado por Verificado por


El mantenimiento de las dependencias entre los modelos se puede realizar por:

Ingeniería hacia delante – los modelos de analisis y diseño se establecen a partir del modelo de casos de uso, los modelos de implementación y pruebas se generan luego, a partir de estos

Ingeniería inversa – los modelos de análisis y diseño se extraen o actualizan mediante el código existente

Ingeniería de viaje redondo – combinacion de ingeniería hacia delante e inversa, dependiente de cuál modelo esté sufriendo la mayor cantidad de cambios

Perspectivas centradas en actividades y perspectivas centradas en entidades

Modelos centrados en actividades: Representan de manera explicita las actividades

del proceso Los participantes se enfocan en la manera de

crear los productos de trabajo Modelos centrados en problemas:

Representan de manera explicita los productos de trabajo

Los participantes se enfocan en el contenido y estructura de los productos de trabajo

El modelo basado en problemas Esta centrado en entidades Esta orientado al manejo de los cambios frecuentes Se puede utilizar si el tiempo entre cambios es

significativamente más pequeño que la duración de una actividad

Cada proyecto empieza con la identificación de un conjunto de problemas

Todos los problemas están guardados en una base de problemas a la que tienen acceso todos los participantes en el proyecto

El modelo basado en problemas

El estado de un problema puede ser: Cerrado – ha sido resuelto Abierto – se resuelven mediante

conversaciones y negociaciones entre los participantes en el proyecto

Un problema cerrado puede abrirse de nuevo si ocurren cambios

Entre problemas existen dependencias

El modelo basado en problemas Se pueden establecer correspondencias entre los problemas y las

actividades de otros modelos (paradigmas) En el modelo en cascada los desarrolladores resuelven por completo los

problemas asociadas con una actividad antes de pasar a la siguiente En el modelo espiral los riesgos corresponden a problemas que están

evaluados y se vuelven a abrir al inicio de cada ciclo El uso de problemas y sus dependencias permite que las actividades

del ciclo de vida se lleven a cabo en forma concurrente La administración del proyecto es muy importante El administrador debe mantener la cantidad de problemas abiertos

pequeña y manejable

El estándar para el desarrollo de procesos software

El estándar IEEE 1074: Describe el conjunto de actividades y

procesos obligatorios para el desarrollo y mantenimiento del software

Establece un marco común para el desarrollo de modelos de ciclo de vida

Ofrece ejemplos de situaciones típicas

El estándar para el desarrollo de procesos software

Actividad – tarea o grupo de subactividades que se asignan a un equipo o a un participante del proyecto, para lograr un propósito específico

Proceso – conjunto de actividades que se realiza para un propósito específico

Grupo de procesos – conjunto de procesos agrupados en un nivel superior de abstracción

Las tareas consuman recursos y crean un producto de trabajo Las actividades se descomponen en tareas específicas, se le dan

fechas de inicio y fin, se asignan a un participante o a un equipo

El estándar para el desarrollo de procesos software (IEEE 1074)

Grupo de procesos ProcesosModelado del ciclo de vida Selección de un modelo de ciclo de vida

Administración del proyecto Inicio del proyectoSupervisión y control del proyectoAdministración de la calidad del software

Predesarrollo Exploración de conceptosAsignación del sistema

Desarrollo RequerimientosDiseñoImplementación

Posdesarrollo InstalaciónOperación y soporteMantenimientoRetiro

Procesos integrales Verificación y validaciónAdministración de la configuración del softwareDesarrollo de la documentaciónEntrenamiento

El modelo de madurez de capacidades

Las actividades y artefactos que se eligen para un proyecto específico no están definidos por el estándar

El modelo de madurez de capacidades (CMM – Capability Maturity Model): Ofrece lineamientos para la selección de actividades del

proceso software Asume que el proceso software es más predecible cuando se

utilizan modelos de ciclo de vida bien estructurados, visibles para todos los participantes en el proyecto, y que se adaptan al cambio


CMM utiliza cinco niveles para caracterizar la madurez de una organización: Nivel 1: Inicial Nivel 2: Repetible Nivel 3: Definido Nivel 4: Administrado Nivel 5: Optimizado

Para medir la madurez de una organización SEI (Software Engineering Institute) ha definido un conjunto de áreas de proceso claves

Para alcanzar a un cierto nivel, la organización debe demostrar que maneja todas las áreas de proceso claves para ese nivel


Nivel 1: Inicial Pocas actividades bien definidas Para asegurar el éxito de un proyecto son

necesarios grandes esfuerzos y habilidades individuales

El cliente no tiene una forma efectiva para interactuar con la administración del proyecto

El modelo del ciclo de vida (si existe) es una caja negra para el cliente

El cliente debe esperar hasta el fin del proyecto para inspeccionar el producto


Nivel 2: Repetible Cada proyecto tiene un modelo de ciclo de vida bien definido Los modelos diferentes entre diferente proyectos bajan la posibilidad

de reutilizar el conocimiento Los nuevos proyectos se basan en la experiencia de la organización

con anteriores proyectos similares El éxito es predecible para proyectos en dominios de aplicación

similares a los anteriores El cliente interactúa con la organización solamente en momentos bien

definidos Son posibles algunas correcciones antes de la entrega


Nivel 3: Definido Utiliza un modelo de ciclo de vida documentado

para todas las actividades administrativas y técnicas por toda la organización

Al inicio de cada proyecto se produce una versión personalizada del modelo general

El cliente conoce el modelo estándar y el modelo específico para el proyecto en desarrollo


Nivel 4: Administrado Define las medidas para las actividades y los

productos a entregar El modelo de ciclo de vida puede entenderse y

analizarse de modo cuantitativo Al cliente se le informa de los riesgos antes del

comienzo del proyecto y conoce las medidas utilizadas por la organización


Nivel 5: Optimizado Existe un mecanismo de retroalimentación en

base a los datos de las mediciones, para mejorar el modelo de ciclo de vida

El cliente, los administradores y los desarrolladores se comunican y trabajan juntos durante el desarrollo del proyecto

Técnicas de cuarta generación (T4G)

Un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir algunas o todas de las siguiente herramientas:

lenguajes no procedimentales de consulta a bases de datos, generación de informaciones, manejo de datos

interacción y definición de pantallas generación de códigos capacidades graficas de alto nivel etc.


El enfoque T4G comienza con la análisis de requerimientos

El cliente describe los requisitos, que son a continuación traducidos directamente a un prototipo operativo

En la practica, el dialogo cliente-desarrollador es esencial, al igual que por otros paradigmas


A continuación se puede ir directamente al paso de implementación, usando un lenguaje de cuarta generación no procedimental (L4G), pero el uso de T4G sin diseño causará las mismas dificultades que en el caso de los enfoques convencionales (baja calidad, mantenimiento difícil etc.)

La implementación mediante un lenguaje L4G permite centrarse en la representación de los resultados deseados, que es lo que se traduce automáticamente en un código fuente que produce dichos resultados

Debe existir una estructura de datos con información relevante y a la que el L4G pueda acceder rápidamente


Las otras etapas del proceso de desarrollo de software (validación, evolución) existen como por cualquier otro enfoque

El modelo T4G reduce el tiempo de desarrollo del software y mejora la productividad, especialmente para aplicaciones pequeñas o de tamaño medio

Para aplicaciones de alta complejidad, el tiempo que se ahorra mediante la eliminación de la codificación se pierde debido al hecho que se exige el mismo o más tiempo de análisis, diseño y prueba

Ingeniería de software asistida por computadora

El software que se utiliza para ayudar a las actividades del proceso del software se denomina CASE (Computer-Aided Software Engineering)

La tecnología CASE ayuda el proceso del software automatizando algunas de sus actividades, así como proporcionando información acerca del software en desarrollo

Las herramientas CASE incluyen editores de diseño, diccionarios de datos, compiladores, depuradores, herramientas de construcción de sistemas etc.


Aunque la tecnología CASE está disponible para muchas actividades rutinarias en el proceso del software y conduce a algunas mejoras en la calidad y productividad del software, esta tecnología no ha revolucionado a la ingeniería de software como se predijo

Hay dos factores importantes que limitan la utilización de la tecnología CASE: los sistemas CASE automatizan actividades de rutina, pero la

ingeniería de software es una actividad que se basa en la creatividad la ingeniería de software es una actividad de equipo, pero la tecnología

CASE no facilita la interacción con los otros miembros del equipo


Existan varias formas de clasificar las herramientas CASE, cada una de las cuales proporciona una perspectiva diferente de esas herramientas:

Una perspectiva funcional – clasifica las herramientas CASE de acuerdo con su función especifica

Una perspectiva de proceso – clasifica las herramientas CASE de acuerdo con su ayuda a las actividades del proceso

Una perspectiva de integración – clasifica las herramientas CASE de acuerdo con la forma en que están organizadas en unidades integradas, las cuales proporcionan ayuda a una o más actividades del proceso.

Que modelo utilizar ?

Para sistemas bien comprendidos utiliza el Modelo de Cascada. La fase de análisis de riesgos es relativamente fácil.

Con requerimientos estables y sistemas de seguridad críticos, utiliza modelos formales.

Con especificaciones incompletas, utiliza el modelo de prototipado.

Pueden utilizarse modelos híbridos en distintas partes del desarrollo.

Métodos (metodologías) de Desarrollo de Software

Conjunto de pasos y procedimientos que deben seguirse para el desarrollo de softwareCómo se debe dividir un proyecto en etapas.Qué tareas se llevan a cabo en cada etapa.Qué salidas se producen y cuándo se deben

producir.Qué restricciones se aplican.Qué herramientas se van a utilizar.Cómo se gestiona y controla un proyecto.

Métodos de desarrollo de software Es necesario establecer

un enfoque disciplinado y sistemático para desarrollar un proyecto de software

Método (metodología)

Método Notación

Método Técnica

¿Qué es un método de desarrollo de software?

“Conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a producir nuevo software”. Modelo de proceso (fases y subfases, actividades, tareas). Procedimientos que dan lugar a productos. Técnicas (gráficas, textuales) Herramientas.

Puede acomodar varios ciclos de vida: Ciclo de vida: qué hay que producir, no cómo. Método: qué y cómo.


Definición alternativa de (Sommerville 2002)

“Un método de ingeniería de software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta calidad de una forma costeable.” .

Todos los métodos se basan en la idea de modelos gráficos de desarrollo de un sistema y en el uso de estos modelos como un sistema de especificación o diseño.


Componentes Descripción Ejemplo

Descripciones del modelo del sistema

Descripciones de los modelos del sistema que se desarrollará y la notación utilizada para definir estos modelos

Modelos de objetos, de flujo de datos, de máquina de estado, etc.

Reglas Restricciones que siempre aplican a los modelos de sistemas

Cada entidad de un modelo de sistema debe tener un nombre único

Recomenda-ciones

Seguir estas recomendaciones debe dar como resultado un modelo del sistema bien organizado.

Ningún objeto debe tener más de 7 subobjetos asociados a él.

Guías en el proceso

Descripciones de las actividades que deben seguirse para desarrollar los modelos del sistema y la organización de estas actividades.

Los atributos de los objetos deben documentarse antes de definir las operaciones asociadas a un objeto.

Métodos de desarrolloBeneficios

Sistemas de mayor calidad Pero el seguimiento de una metodología no basta!

Proceso de desarrollo (modelo de procesos) definido productos intermedios en cada fase mejor planificación y gestión del proyecto Desarrollos más rápidos. Recursos adecuados.

Proceso estándar en la organización facilidad de cambios de personal.

Métodos de desarrolloAdaptación del método

No existe un método “universal” o “ideal” Métodos diferentes tienen distintas áreas donde son

aplicables P.ej., los métodos OO son adecuados para

sistemas interactivos, pero no para sistemas en tiempo real con requisitos severos (Sommerville 2002).

El método está condicionado por el tamaño y estructura de la organización, y el tipo de aplicaciones.

“No es razonable pensar que dos organizaciones utilicen la misma metodología sin realizar cambios sobre ella”.

Métodos de desarrolloCaracterísticas deseables

Existencia de reglas predefinidas. Fases y subfases, tareas, productos intermedios,

técnicas, herramientas, etc. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificación y control. Comunicación efectiva. Uso sobre un amplio abanico de proyectos. Fácil formación.

Métodos de desarrolloCaracterísticas deseables

Herramientas CASE. Debe contener actividades que mejoren el

proceso de desarrollo. Soporte al mantenimiento.

p.ej. Reingeniería. Soporte de la reutilización del software

no sólo reutilización de código. Actualmente, se huye de métodos muy

burocráticos o “monolíticos”. Métodos “ágiles”.

Métodos. Clasificación

Estructurados: representan los procesos, flujos y estructuras de datos, de una manera jerárquica, descendente

Ven el sistema como entradas-proceso-salidas Orientados a procesos:

Se centran en la parte proceso Miniespecificaciones de proceso.

Orientados a datos: Se orientan más a las entradas y salidas Primero se definen los datos A partir de ellos, los componentes procedimentales Los datos son más estables

Métodos. Ejemplos

Estructurados De Marco 79 Gane & Sarson 79 Yourdon 89 SSADM Merise MÉTRICA 2.1

Orientados a datos JSD Jackson Warnier 74

OO OMT (Rumbaugh et al. 91) Booch 94 Objectory/OOSE (Jacobson

93) FUSION (Coleman 94) OOram (Reenskaug 96) Proceso Unificado (Jacobson

et al. 99) Rational Unified Process

(RUP) (Krutchen et al. 99) Tiempo real

Ward & Mellor 85 Hatley & Pirbhay 87

1 presentacion_1_-_ingenieria_de_software[1]

Technology

Transcript of 1 presentacion_1_-_ingenieria_de_software[1]