Haga clic para modificar el estilo de subttulo del patrn

5/27/12

11

CAPAS DE LA INGENIERIA DE SOFTWARE

Herramient as Mtodos Proceso Un enfoque de calidad

El fundamento de la Ingeniera de Software es la calidad

5/27/12 22

Capas de la ingeniera de software

El fundamento de la ingeniera de software es la capa del

proceso. El proceso de la ingeniera de software es la unin que mantiene juntas las capas de tecnologa y que permite un desarrollo racional y oportuno de la ingeniera de software.

El proceso define un marco de trabajo para un conjunto de

reas claves de proceso (ACPs ) [PAU93] que se deben establecer para la entrega efectiva de la tecnologa de la ingeniera de software. Las reas claves del proceso forman la base del control de gestin de proyectos del software y establecen el contexto en el que se aplican los mtodos tcnicos, se obtienen productos del trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona adecuadamente.
33

5/27/12

Capas de la ingeniera de software..

Los mtodos de la ingeniera de software indican cmo construir

tcnicamente el software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos de la ingeniera de software dependen de un conjunto de principios que gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras tcnicas descriptivas.

Las herramientas de la ingeniera del software proporcionan un

enfoque automtico o semi-automtico para el proceso y para los mtodos. Cuando se integran herramientas para que la informacin creada por una herramienta la pueda utilizar otra, se establece un sistema de soporte para el desarrollo del software llamado ingeniera del software asistida por computadora (CASE)

5/27/12

44

Proceso
Ejecutar una serie de acciones, y que

stas tengan cierto orden, dependencias, roles responsables, resultados, tiempos de ejecucin y herramientas de apoyo

Conjunto de prcticas relacionadas entre

si, llevadas a cabo a travs de roles y por elementos automatizados, que utilizando recursos y a partir de insumos producen un satisfactor de negocio para el cliente. (MoProSoft)
55

5/27/12

Proceso de Desarrollo de Software

Es un conjunto de personas, estructuras de

organizacin, reglas, polticas, actividades y sus procedimientos, componentes de software, metodologas, y herramientas utilizadas o creadas especificamente para definir, desarrollar, ofrecer un servicio, innovar y extender un producto de software.

5/27/12

66

Un Proceso Software :
Permite estandarizar esfuerzos, promover el

reuso, repeticin proyectos. prcticas.

constistencia

entre

Provee la oportunidad de introducir mejores Permite entender que las herramientas deben

ser utilizadas para soportar un proceso.

5/27/12

77

Proceso de Desarrollo de Software

Es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo. Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo.

5/27/12

88

Proceso de Desarrollo de Software

El conjunto de actividades fundamentales que se encuentran presentes en los procesos de desarrollo de software son:

Especificacin de software: Define la funcionalidad y restricciones operacionales que debe cumplir el software. Diseo e Implementacin: Se disea y construye el software de acuerdo a la especificacin. Validacin: El software debe validarse, para asegurar que cumpla con lo que quiere el cliente. para
99

Evolucin: El software debe evolucionar, 5/27/12 adaptarse a las necesidades del cliente.

Caractersticas del proceso

Entendible
l

Se encuentra el proceso bien definido y es entendible ?.

Visible
l

El proceso es visible al exterior ?.

Soportable
l

Puede el proceso ser soportado por herramientas CASE ?.

Aceptable
l

El proceso es aceptado por aquellos involucrados en el ?. 1010

5/27/12

Caractersticas del proceso

Confiable
l

Los errores del proceso son descubiertos antes de que se conviertan en errores del producto ?.

Robusto
l

Puede continuar el proceso a pesar de problemas inesperados ?.

Mantenible
l

Puede el proceso evolucionar para cumplir con los objetivos organizacionales ?.

Rapidez
l

Que tan rpido puede producirse el sistema ?. 1111

5/27/12

Mtodos de Proceso de Software

Todo el desarrollo del software se puede caracterizar como un bucle de resolucin de problemas en el que se encuentran cuatro etapas distintas: definicin de problemas, desarrollo tcnico, status quo e integracin de soluciones.

5/27/12

1212

Problemas en el Modelo del Proceso

anmalas diseo y la manufactura

Normalmente, las especificaciones son incompletas o No existe una distincin precisa entre la especificacin, el Solo hasta que el sistema se ha producido se puede probar El software no se puede remplazar siempre durante el

mantenimiento

5/27/12

1313

Modelos de Desarrollo de Software proceso de Representacion formal o simplificada de

software.
Modelos Genericos:
Modelo de Cascada
u

Separar en distintas fases de especificacin y desarrollo.

Desarrollo Evolutivo
u

La especificacin y el desarrollo estn intercalados.

Prototipado
u

Un modelo sirve de prototipo para la construccin del sistema final.

Transformacin Formal
u 5/27/12 Un modelo matemtico del sistema se transforma formalmente en la implementacin.

1414

Modelo de Cascada (grfica)

Definicin de Requerimie ntos Diseo del Software y del Sistema Implementaci ny Prueba de unidades
Integracin y Prueba del Sistema

5/27/12

Opera cin y Mante nimien

1515

Fases del Modelo de Cascada

Anlisis de requerimientos y definicin. Diseo del sistema y del software. Implementacin y prueba de unidades Integracin y prueba del sistema. Operacin y mantenimiento. La dificultad en esta modelo reside, en la dificultad de

hacer cambios entre etapas.

5/27/12

1616

Ciclo de Vida en V

5/27/12

1717

Ciclo de Vida en V
Las caractersticas de este modelo son las mismas que las del ciclo

de vida en cascada, con el agregado de los controles cruzados entre etapas para lograr una mayor correccin. del principio que establece que los procedimientos utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse creado en la fase de diseo.

Proviene

Una fase adems de utilizarse como entrada para la siguiente, sirve

para validar o verificar otras fases posteriores.

5/27/12

1818

Documentacin
Producto Entrada Proceso
Requerimientos Comunicados Especificacin de requerimientos (documentos) Especificacin de Diseo ( documento) Modulos ejecutables de Software Producto de Software Integrado Producto de Software Entregado Ingenieria de Requerimientos Diseo Programacin Integracin Entrega Mantenimiento

Producto Salida
Especificacin de requerimientos (documentos) Especificacin de Diseo ( documento) Modulos ejecutables de Software Producto de Software Integrado Producto de Software Entregado Requerimientos para cambio

5/27/12

POR QU FALLA ALGUNAS VECES EL MODELO LINEAL?

1.- Como resultado, los cambios pueden causar confusin cuando el equipo del proyecto comienza. 2.-El modelo lineal secuencial requiere dificultades a la hora de afrontar la incertidumbre natural al comienzo de muchos proyectos. 3.-Un grave error puede ser desastroso si no se detecta hasta que se revisa el programa. Cada uno de estos errores es real. Tiene un lugar definido e importante en el trabajo de la ingeniera del software proporciona una plantilla en la que se encuentran mtodos para anlisis, diseo, codificacin, y mantenimiento.
5/27/12

Desarrollo Evolutivo
Activi dades Concu rrent Especifica cin es
Descripc in del sistema Versi n Inicial

Desarro llo

Versione s Intermed ias Versi n Final

Validaci n

5/27/12

2121

Desarrollo Evolutivo
Problemas
l l l

Poca visibilidad en el proceso Los sistemas estn pobremente especificados Se requieren habilidades especiales.

Aplicabilidad
l l l

Para sistemas interactivos pequeos o medianos. Para partes de sistemas grandes (p.ej. la interfaz de usuario). Para sistemas de corta vida.

5/27/12

2222

Prototipado
Prototipado exploratorio
l

El objetivo es trabajar con clientes hasta evolucionar a un sistema final, a partir de una especificacin inicial. Se debe comenzar con unas especificaciones bien entendidas.

Prototipado de throw-away.
l

El objetivo es entender los requerimientos del sistema. Se puede comenzar con especificaciones poco entendidas.

5/27/12

2323

Modelo de construccin de prototipos

Escuchar al cliente Construir/ revisar maqueta

El cliente prueba la maqueta

5/27/12

Modelo de construccin de prototipos

5/27/12

 Por qu se usar este modelo?

El cliente no puede especificar todos los

requerimientos al principio.

Existen dudas de alguna parte del sistema. Facilita un modelo al programador

5/27/12

Modelo Incremental
Combina

5/27/12

elementos del modelo lineal con la filosofa de creacin de prototipos El primer incremento a menudo es un producto esencial que el cliente utiliza o evala A partir de la evaluacin se planea el siguiente incremento y as

Modelo Incremental
Incremen Anli Dise Cdito 1 Prueb Entrega de 1.er sis o go as Incremenincremento Anli Dise Cdito 2 Prueb Entrega de 2.o sis o go as Incremen incremento Anli Dise Cdito 3 Prueb Entrega de 3.er sis o go as incremento Incremen Anli Dise Cdito 4 Prueb Entrega de 4.o sis o go as incremento Tiempo de 5/27/12

Modelo Incremental

5/27/12

Modelo de ensamble de componentes

modelo utiliza el marco de El

5/27/12

trabajo tcnico del paradigma orientado a objetos Incorpora muchas caractersticas del modelo en espiral La actividad de ingeniera comienza con la identificacin de clases candidatas Segn estudios realizados este modelo:

Modelo de ensamble de componentes

Id e n tific a r co m p o n e n te s c a n d id a to s C o n stru ir n in te ra c cio n e s d e l sis te m a Poner co m p o n e n te s n u e v o s e n la b ib lio te c a B u sc a r c o m p o n e n te s e n b ib lio te c a E x tra e r c o m p o n e n te s s i e st n d is p o n ib le s

C o n s tru ir co m p o n e n te s si n o e s t n d is p o n ib le s
5/27/12

Modelo de desarrollo concurrente

Bajo desarrollo Cambios en espera Bajo revisin En lnea base

Cambios en espera

Activida des de anlisis

Hecho

5/27/12

Representa un estado de una

Modelo del proceso orientado a objetos

Identificando clases candidatas

Planeacinn
i Comunicacin Cut ome s r con el clientet on Comm i cai un

Anlisi s de riesgo

Construyendo nesima versin del sistema

Buscando clases en libreras

Agregar clase a las libreras Ingeniera si las clases no disponibles

Extrayendo clases si estn disponibles

Cut ome s Evaluacin r del cliente on Eva uai l t

Ingeniera Construccin y rediseo

Anlisi s OO Diseo OO Codificaci nOO Prueba s OO

5/27/12

Problemas y Riesgos con los Modelos.

Cascada.
l

Alto riesgo en sistemas nuevos debido a problemas en las especificaciones y en el diseo. Bajo riesgo para desarrollos bien comprendidos utilizando tecnologa conocida.

Prototipado.
l

Bajo riesgo para nuevas aplicaciones debido a que las especificaciones y el diseo se llevan a cabo paso a paso. Alto riesgo debido a falta de visibilidad

Evolutivo.
Alto riesgo debido a la necesidad de tecnologa avanzada y habilidades del grupo desarrollador. 5/27/12 3434
l

Manejo de Riesgos
La tarea principal del administrador consiste en minimizar

riesgos.
El riesgo inherente en una actividad es se mide en base

a la incertidumbre que presenta el resultado de esa actividad.

Las actividades con alto riesgo causan sobre-costes en

cuanto a planeacin y costos

El riesgo es proporcional al monto de la calidad de la

informacin disponible. Cuanto menos informacin, mayor el riesgo.

5/27/12 3535

Modelos de Procesos Hbridos

Los sistemas grandes estn hechos usualmente de varios

subsistemas.
No es necesario utilizar el mismo modelo de proceso para

todos los subsistemas.

El prototipado es recomendado cuando existen

especificaciones de alto riesgo.

El modelo de cascada es utilizado en desarrollos bien

comprendidos.

5/27/12

3636

Modelo de Proceso de Espiral

Determine objetivos alternativas y restricciones Anlisis de Riesgos Anlisis de Riesgos Anlisis de Prototipo Riesgos Prototip Operacion Anlisi Prototip o al Prot s o 3 o 2 de tipo Riesgo Simulaciones, modelos y 3 s Concepto benchmarks de Requeri Operacin mientos Diseo Diseo Detallad de Validacin de o del Codificaci SW Requerimient Producto n Prueba os de Dise Prueba Unidade o de V &V Prueba Integraci s Desarrolla y de n verifica Aceptaci Servici el siguiente nivel n o del producto Evale alternativas, identifique y resuelva riesgos

REVISIN Plan de requerimientos Plan del ciclo de vida Plan de Desarroll o Plan de Integracin y Prueba

Planea la siguiente fase

5/27/12

3737

Modelo del Ciclo de Vida en Espiral

5/27/12

3838

Fases del Modelo de Espiral

Planteamiento de Objetivos
l

Se identifican los objetivos especficos para cada fase del proyecto.

Identificacin y reduccin de riesgos.

l

Los riesgos clave se identifican y analizan, y la informacin sirve para minimizar los riesgos.

Desarrollo y Validacin.
l

Se elige un modelo apropiado para la siguiente fase del desarrollo.

Planeacin.
l Se 5/27/12 revisa el proyecto y se trazan planes para la siguiente ronda 3939 del espiral.

Plantilla para una ronda del espiral

Objetivos. Restricciones. Alternativas. Riesgos. Resolucin de riesgos. Resultados. Planes. Garantas (commitments).
5/27/12 4040

Ventajas del Modelo de Espiral

Centra su atencin en la reutilizacin de componentes y

eliminacin de errores en informacin descubierta en fases iniciales.

Los objetivos de calidad son el primer objetivo. Integra desarrollo con mantenimiento. Provee un marco de desarrollo de hardware/software.

5/27/12

4141

Problemas con el Modelo de Espiral

y los resultados a entregar por adelantado.
Requiere refinamiento para uso generalizado.

El desarrollo contractual especifica el modelo del proceso Requiere de experiencia en la identificacin de riesgos.

5/27/12

4242

Que modelo utilizar ?

Para sistemas bien comprendidos utiliza el Modelo de

Cascada. La fase de anlisis de riesgos es relativamente fcil.

Con requerimientos estables y sistemas de seguridad

crticos, utiliza modelos formales.

Con especificaciones incompletas, utiliza el modelo de

prototipado.
Pueden utilizarse modelos hbridos en distintas partes del

desarrollo.
5/27/12 4343

Visibilidad de Procesos
Los sistemas de software son intangibles por lo que los

administradores necesitan documentacin para identificar el progreso en el desarrollo.

Esto puede causar problemas..
l

El tiempo planeado para entrega de resultados puede no coincidir con el tiempo necesario para completar una actividad. La necesidad de producir documentos restringe la iteracin entre procesos. .El tiempo para revisar y aprobar documentos es significativo.

El modelo de cascada es an el modelo basado en

5/27/12

resultados mas utilizado.

4444

Documentos del Modelo de Cascada

Actividad Anlisis de Requerimientos Definicin de Especificacin Requerimientosdel Sistema. Diseo Arquitectural Diseo de Interfaces Diseo Detallado Codificacin Prueba de Unidades Prueba de Mdulos Prueba de Integracin Prueba del Sistema Prueba de Aceptacin
5/27/12

Documentos Producidos Documento de Documento de Requerimientos Especificacin Funcional, Plan de Pruebas de Requerimientos. Aceptacin.
Especificacin de la Arquitectura, y Plan de Pruebas del Sistema Especificacin de la Interfaces y Plan de pruebas de Integracin. Especificacin del diseo y Plan de prueba de Unidades.

Cdigo de Programa Reporte de prueba de Reporte unidadesde prueba de Reporte de prueba de integracin y Manual de mdulos usuario final Reporte de prueba del Sistema final mas la documentacin. sistema
4545

Visibilidad del Modelo

Modelo de Proceso Modelo de Cascada Desarrollo Evolutivo Modelos Formales Desarrollo orientado a la reutilizacin Modelo de Espiral
5/27/12

Visibilidad del Proceso Buena visibilidad, cada actividad produce un documento o resultado muy caro al producir Visibilidad pobre,
docuementos en cada iteracin.

Buena visibilidad, en cada fase deben producirse documentos. Visibilidad moderada. Importante contar con documentacin de componentes reutilizables. Buena visibilidad, cada segmento y cada anillo del espiral debe producir un 4646

Metodos Orientados a Objetos

Modelado de Casos de Uso Proceso Unificado Programacin Extrema

5/27/12

4747