Proceso Desarrollo

Proceso Software
dirigido por las Pruebas
CIF 9159 – Taller Integrado

Contenidos
I. Motivación
II. Modelado de Software con UML
III. Herramientas
IV. Introducción al Proceso de Desarrollo de Software
V. Metodologías Ágiles versus Tradicionales
VI. Pruebas de Aceptación y Proceso Software

www.dsic.upv.es/~letelier
VII.Conclusiones
2
ë
Contenidos
I. Motivación
III. Herramientas

VII.Conclusiones
3
ë
¿Qué queremos conseguir?
-
Costo
+ Calidad
+
Productividad +
Satisfacción
4
ë
Claves en el Desarrollo de Software
Notación
p.e. UML, DFDs, ER, etc.
Herramientas Proceso
p.e. Rational Rose p.e. Rational Unified Process
StarUML, etc. Métrica 3.0, XP, etc.
5
ë
Contexto: envergadura/complejidad del producto
Construcción de una casa para “fido”
Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
6
ë
… Contexto: envergadura/complejidad del producto
Construcción de una casa familiar
• Construida eficientemente y en un
tiempo razonable por un equipo
• Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
7
ë
www.dsic.upv.es/~letelier … Contexto: envergadura/complejidad del producto
No comments
8
ë
Contenidos
I. Motivación
III. Herramientas

VII.Conclusiones
9
ë
Modelos y Diagramas
Un modelo captura una vista de un sistema del

mundo real. Es una abstracción de dicho sistema,
considerando un cierto propósito.
Diagrama: una representación gráfica de una
colección de elementos de modelado, a menudo
dibujada como un grafo con vértices conectados por
arcos
Un modelo se puede representar a través de 1 o más
diagramas
10
ë
... Modelos y Diagramas
Un proceso de desarrollo de software debe contar un conjunto

de modelos que permitan expresar el producto desde cada
una de las perspectivas de interés
El código fuente del sistema es el modelo más detallado del

sistema (y además es ejecutable!!). Sin embargo, se requieren
otros modelos ...
Cada modelo es completo desde su punto de vista del sistema,

sin embargo, existen relaciones de trazabilidad entre los
diferentes modelos
11
ë
¿Por qué modelar el Software?
Modelo: Representación del software =>

abstracción
El modelado facilita:
• Comunicación de ideas
• Evaluar alternativas
• Aproximación gradual al producto
• “Visualizar” el producto
¿Cuánto y cómo modelar?

Depende de la envergadura y/o complejidad del
producto y debe además estar acorde con la

explotación que se haga de los modelos
12
ë
Grado de modelado: Según su explotación
Nivel de aprovechamiento Generar parcial o totalmente una

3 implementación a partir de los modelos
de los modelos
2 Tomar decisiones de análisis/diseño

que condicionen la implementación
1 Comunicar ideas y estudiar alternativas

0 “Documentar” (a posteriori)
13
ë
Ventajas del Enfoque Orientado a Objetos
Proximidad de los conceptos de modelado respecto
de las entidades del mundo real
• Mejora captura y validación de requisitos
• Acerca el “espacio del problema” y el “espacio de
la solución”
Modelado integrado de propiedades estáticas y
dinámicas del ámbito del problema
• Facilita construcción, mantenimiento y
reutilización
Conceptos comunes de modelado durante el análisis,
diseño e implementación
• Facilita la transición entre distintas fases
• Favorece el desarrollo iterativo del sistema

• Disipa la barrera entre el “qué” y el “cómo”
14
ë
Diagramas de UML
Los diagramas expresan gráficamente partes de un modelo
State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia
Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelos Componentes
Scenario Component
Scenario Component
Diagrams
Diagramas
Diagramas de
Diagrams
Diagrams Diagrams de
Estados Diagramas de Distribución
Actividad
15
ë
Tener presente
UML es la notación más amplia / exhaustiva /

extensa para modelado de software existente
en la actualidad. Aglutina prácticamente a
todas las propuestas previas
“El 80 por ciento de la mayoría de los

problemas pueden modelarse usando
alrededor del 20 por ciento de UML” (Grady
Booch)
16
ë
Modelado de Datos en el Enfoque OO
• En un “mundo OO ideal” no sería necesario el modelado de

datos!!
Los objetos se crearían y existirían mientras no se
destruyan
La persistencia de un objeto sería transparente para el
programador
El lenguaje de programación o el OODBMS se encargaría
de persistir los objetos
En el “mundo OO actual” el uso de BD relacionales conlleva

sacrificios/incongruencias en la implementación
El programador escribe sentencias SQL en los métodos y

explícitamente materializa o desmaterializa objetos
De momento los frameworks de persistencia (p.e.
Hibernate, ADO .NET EF) constituyen una mejora
17
ë
… Modelado de Datos en el Enfoque OO
Así pues, si usamos una BD Relacional debemos obtener un
Modelo Lógico Relacional (MLR) tal como se hace en el enfoque
estructurado
¿Cómo derivar un MLR a partir del Modelo de Análisis/Diseño

expresado en Diagramas de Clases?
Transformar Diagramas de Clases en Diagramas E-R y
posteriormente derivar el MLR.
“Ver” los Diagramas de Clases como Diagramas E-R, considerando
sólo las clases persistentes y sus atributos persistentes. Derivar el
MLR a partir de esta “visualización”. Las pautas de derivación son
similares a las usadas a partir de un Diagrama E-R
¿Qué notación y herramienta utilizar?

Profile UML para modelado de datos junto a herramienta CASE

Directamente modelar/implementar la BD a través de un editor de
diagramas de tablas provisto por el gestor de BD
18
ë
Introducción
Modelado de Requisitos
Requisitos de usuario (Stakeholder goals/needs)
Objetivos y necesidades del cliente
Requisitos de sistema (Software Features)
Servicios y restricciones que puedan constituir un contrato
Requisitos de software (Use Cases)
Descripción que sirva como base para el diseño e

implementación
19
ë
¿Cómo modelar requisitos no funcionales?
UML no aborda la especificación de requisitos no

funcionales
ISO/IEC 9126
20
ë
Interacción entre el Modelado de Procesos y Datos
en el Enfoque Estructurado
Recolección y
Análisis de
Requisitos
Requisitos Requisitos de
Funcionales Bases de Datos
Análisis Diseño
Funcional Conceptual
Especificación de
Modelo Conceptual
Independiente Procesos
del SGBD
Diseño
Diseño Lógico
Dependiente de Programas
del SGBD de Aplicación Modelo Lógico
Especificaciones de Diseño
Diseño de Programas Físico
Implementación
Modelo Físico +
del SW Detalles físicos
Implementación
Programas de Aplicación de la BD
Esquema Interno
de la BD
21
ë
Enfoques para el modelado de Software
Requisitos Análisis Diseño Implementación
Diagramas de Flujo de Diagramas

Datos de
Estructura Programación
Enfoque
Forms o Web
Estructurado
Diagramas E-R Modelo
Relacional
Bases de Datos
Diagramas de UML Relacional
Enfoque OO
Modelo
Relacional !!
Procesos – Código - Comportamiento

Software = +
Datos – BD - Estructura 22
ë
Contenidos
I. Motivación
III. Herramientas

VII.Conclusiones
23
ë
Herramientas
Soporte para actividades/notaciones
• Entornos Integrados de Desarrollo – IDEs
• Herramientas para Pruebas
• Herramientas para Ingeniería de Requisitos
• Herramientas CASE
…
24
ë
… Herramientas
Veamos algunas herramientas …

25
ë
Tendencias en modelado y herramientas
Modelado y generación de código en dominios

específicos (UML and beyond!!)
• Extendiendo UML mediante Profiles
(www.objecteering.com/products_uml_profile_builder.
php)
• Eclipse Modeling Framework (EMF,

http://www.eclipse.org/modeling/emf/)
• Microsoft Tools for Domain Specific Languagues –

DSL Tools
http://www.domainspecificdevelopment.com/
• Domain-Specific Modeling (DSM, www.dsmforum.org)
• Meta CASE Tools, MetaEdit+ (www.metacase.com)
26
ë
Contenidos
I. Motivación
III. Herramientas
IV. Introducción al Proceso de Desarrollo de

Software

VII.Conclusiones
27
ë
Calidad del producto, calidad del proceso
ISO/IEC 9126
28
28
ë
www.dsic.upv.es/~letelier ISO 9001 – SPICE – ISO/IEC 12207
29
ë
CMMI
Capability Madurity Model
30
ë
Modelos de proceso de software
Un modelo de proceso de software es una

representación simplificada de un proceso de
software que conlleva una estrategia global para
abordar el desarrollo de software
Modelos de proceso de software:

Codificar y corregir (code-and-fix)
Desarrollo en cascada
Desarrollo evolutivo
Desarrollo formal de sistemas
Desarrollo basado en reutilización

Desarrollo incremental
Desarrollo en espiral
31
ë
¿Qué es una Metodología?
Una metodología define Quién debe hacer Qué,
Cuándo y Cómo debe hacerlo
32
ë
Adaptando la metodología al proyecto
No existe una metodología de software universal. Las
características de cada proyecto exigen que el
proceso se adapte al proyecto.
33
ë
Una clasificación de Metodologías
Metodologías Estructuradas
MERISE (Francia), MÉTRICA 3 (España), SSADM
(Reino Unido)
Métodos estructurados en el ámbito académico:
Gane & Sarson, Ward & Mellor, Yourdon &
DeMarco, Information Engineering, etc.
Metodologías OO
Metodologías basadas en UML: Rational Unified
Process (RUP), Unified Process (UP), MÉTRICA 3
Métodos previos a UML: OOAD (Booch), OOSE

(Jacobson), Coad & Yourdon, Shaler & Mellor y
OMT (Rumbaugh)
34
34
ë
Contenidos
I. Motivación
III. Herramientas
V. Metodologías Tradicionales versus Ágiles

VII.Conclusiones
35
ë
www.dsic.upv.es/~letelier Rational Unified Process (RUP)
36
ë
Fases e Hitos (Milestones)
Inception Elaboration Construction Transition
Objetivos Arquitectura Capacidad Release

(Vision) Operacional del Producto
Inicial
tiempo
37
ë
Release, Base Line, Generación
ciclo de desarrollo ciclo de evolución

release base line generación

(producto al final de (release asociada (release final de
una iteración) a un hito) un ciclo de desarrollo)
38
ë
Elementos en RUP
Workflow, Workflow Detail , Roles, Actividades y Artefactos
Ejemplo
Workflow: Requirements Workflow Detail:Analyse the Problem

Roles Artefactos
Actividades 39
ë
Características esenciales de RUP
Proceso Dirigido por los Casos de Uso
Proceso Iterativo e Incremental
Proceso Centrado en la Arquitectura

40
ë
Proceso dirigido por los Casos de Uso
Capturar, definir y
Requisitos
validar los casos de uso
Análisis & Diseño

Casos de Uso Realizar los
integran el casos de uso
Implementación trabajo
Verificar que se
Pruebas satisfacen los casos
de uso
41
ë
www.dsic.upv.es/~letelier … Proceso dirigido por los Casos de Uso
42
ë
Proceso Iterativo e Incremental
Enfoque
Cascada
Enfoque
Iterativo e
Incremental
43
ë
Proceso Centrado en la Arquitectura
Arquitectura de un sistema es la organización o

estructura de sus partes más relevantes
Inception Elaboration Construction Transition
Architecture
44
ë
¿Qué es una Metodología Ágil?
www.agilealliance.com
• Las Metodologías Ágiles (AMs) valoran:

Al individuo y las interacciones en el equipo de desarrollo
más que a las actividades y las herramientas
Desarrollar software que funciona más que conseguir una

buena documentación ⇒ Minimalismo respecto del
modelado y la documentación del sistema
La colaboración con el cliente más que la negociación de

un contrato
Responder a los cambios más que seguir estrictamente

una planificación
45
ë
¿Por qué surgen las Metodologías Ágiles (AMs)?
Dificultad para implantar metodologías tradicionales.

Sofisticadas herramientas CASE y notaciones (UML)
Una solución a medida para un segmento importante

de proyectos de desarrollo de software
Pugna entre comunidades/gurús
“Aceptar el cambio” ...

46
ë
Artefactos esenciales en XP
Historias del Usuario

Tareas de Ingeniería
Pruebas de Aceptación
Pruebas Unitarias, de Integración y de Sistema
Plan de la Entrega
Código
47
ë
Historia de Usuario
Historia de Usuario
Número: 1 Nombre: Enviar artículo
Usuario: Autor
Modificación de Historia Número: Iteración Asignada: 2
Prioridad en Negocio: Alta
Puntos Estimados:
(Alta / Media / Baja)
Riesgo en Desarrollo:
Puntos Reales:
(Alto / Medio / Bajo)
Descripción:
Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de
los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como
autor de contacto. El sistema confirma la correcta recepción del artículo enviando un
e-mail al autor de contacto con un userid y password para que el autor pueda
posteriormente acceder al artículo.
Observaciones:
48
ë
www.dsic.upv.es/~letelier Boceto de IU para Historia de Usuario
49
ë
Tarea de Ingeniería
Tarea
Número tarea: Número historia:
Nombre tarea:
Tipo de tarea :
Puntos estimados:
Desarrollo / Corrección / Mejora / Otra
Fecha inicio: Fecha fin:
Programador responsable:
Descripción:
50
ë
Prueba de Aceptación
Número Caso de Prueba: Historia de Usuario:
Nombre Caso de Prueba:
Descripción:
Condiciones de ejecución:
Entradas:
Resultado esperado:
51
Evaluación:
ë
Prácticas XP
• El juego de la • Programación en
planificación parejas
• Entregas pequeñas • Propiedad colectiva
• Metáfora • Integración continua
• Diseño simple • Semana de 40 horas
• Pruebas • Cliente in situ
• Refactoring • Estándares de
programación
52
ë
www.dsic.upv.es/~letelier Interacción entre Prácticas XP
XP: Kent Beck

53
ë
Fase de Exploración
? Historias de Usuario
Prioridad Riesgo
Esfuerzo (puntos)
Definir
Historias
de Usuario
Elaborar Estimar Esfuerzo

Spikes y Riesgo
Identificar Escenarios/
Spikes (Bocetos)
54
ë
Planificación de la Entrega
Velocidad de
Proyecto (VP)
puntos/semana
Historias
de Usuario
Segunda N-ésima Última
Primera Iteración Iteración
Iteración Iteración
Historias
fuera de la
… entrega
2a3
semanas
Entrega
<= 3 meses
55
ë
Fase de Construcción
Trabajo durante una iteración XP
Historias de la Tareas de
Iteración Historias de
la iteración
Pruebas de
Aceptación
Programación
en Parejas
Validación
continua por
el cliente Diseño
Refactoring
Programación
Pruebas Unitarias
Integración
Versión del Pruebas de Integración
Producto Pruebas de Aceptación
56
ë
Sitios Recomendados
Sitio Extreme Programming: A Gentle Introduction. www.extremeprogramming.org
Secciones “Artículos” y “Roadmap” del sitio de la Agile Alliance.
www.agilealliance.org
Sitio Xprogramming, mantenido por Ron Jeffries. www.xprogramming.com
WikiWiki de Extreme Programming
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
Revista electrónica Software Development. www.sdmagazine.com
Número monográfico de revista CrossTalk: Agile Software Development.
www.stsc.hill.af.mil/crosstalk/2002/10/
Una extensiones de XP, Agile+. www.agiletek.com
Sitios de modelado ágil, mantenidos por Scott W. Ambler. www.agilemodeling.com,
www.agiledata.org
Refactoring, mantenido por Martin Fowler. www.refactoring.com

Pruebas en contexto ágil, www.junit.org
International Conference on eXtreme Programming and Agile Methods in Software
Development (XP200x) http://www.xp2004.org
XP Agile Universe http://www.agileuniverse.com 57
ë
Comparación Metodologías Ágiles v/s Tradicionales
Metodología Ágil Metodología Tradicional

Orientada a proyectos pequeños. Corta Aplicables a proyectos de cualquier
duración (o entregas frecuentes), equipos tamaño, pero suelen ser especialmente
pequeños (< 10 integrantes) y trabajando efectivas/usadas en proyectos grandes y
en el mismo sitio. Posibles problemas de con equipos posiblemente dispersos.
escalabilidad en proyectos “grandes” Posibles problemas de adaptabilidad a
proyectos “pequeños”
Pocos Artefactos. El modelado es Más Artefactos. El modelado es esencial,
prescindible, modelos desechables. mantenimiento de modelos
Pocos Roles, más genéricos y flexibles Más Roles, más específicos
No existe un contrato tradicional, debe ser Existe un contrato prefijado
bastante flexible
Cliente es parte del equipo de desarrollo El cliente interactúa con el equipo de
(además in-situ) desarrollo mediante reuniones
La arquitectura se va definiendo y Se promueve que la arquitectura se defina
mejorando a lo largo del proyecto tempranamente en el proyecto

Énfasis en los aspectos humanos: el Énfasis en la definición del proceso: roles,
individuo y el trabajo en equipo actividades y artefactos
Se esperan cambios durante el proyecto Se espera que no ocurran cambios de
gran impacto durante el proyecto 58
ë
Costo de los Cambios en SW
Tradicional
Costo
del
cambio
Suposición MAs
tiempo
59
59
ë
Configurabilidad versus Escalabilidad
Configurar una metodología tradicional para un

proyecto pequeño no es trivial
Una metodología ágiles podría presentar problemas

de escalabilidad para proyectos grandes … habría
que complementarla con artefactos, actividades y
roles
60
60
ë
Cuándo NO utilizar una Metodología Ágil
Algunos obstáculos críticos

Contrato poco flexible
Cliente con poca dedicación y disponibilidad para
el proyecto
Equipo numeroso y/o disperso
Equipo de desarrollo no involucrado
Entorno de trabajo inapropiado
61
61
ë
Contenidos
I. Motivación
III. Herramientas
V. Metodologías Tradicionales versus Ágiles

VII.Conclusiones
62
ë
Pruebas en Metodologías
No hay diferencias significativas respecto a pruebas
(desde el punto de vista de técnicas y herramientas
utilizadas) entre una metodología tradicional y una ágil
El minimalismo de las metodologías ágiles concede un

especial protagonismo a las pruebas del software
Las metodologías ágiles han renovado el interés por

las pruebas del software (p.e. Junit y sus derivados, y
la complicidad con la comunidad Open Source)
Pruebas usando una metodología ágil: interesante

alternativa de iniciación en pruebas para pequeña y

mediana empresa
63
ë
… Pruebas en Metodologías
Dificultades para la introducción de una “cultura”,
disciplina y prácticas de pruebas en un equipo de
desarrollo
Obstáculos o Malas estrategias

Carencia de un proceso de desarrollo que integre
las actividades de pruebas
Sobrevaloración de la automatización de las
pruebas como objetivo inmediato (o único)
No “Rentabilizar” el esfuerzo invertido en pruebas
Estrategia de implantación de una “cultura” de

pruebas a partir del aprovechamiento de las Pruebas
de Aceptación
64
ë
“Una PA tiene como propósito demostrar al cliente el
cumplimiento de un requisito del software”
Precisando un poco más, una PA:

Describe un escenario (secuencia de pasos) de
ejecución o uso del sistema desde la perspectiva
del cliente
Puede estar asociada a requisitos funcionales o no
funcionales
Un requisito tiene una o más PAs asociadas
Las PAs cubren desde escenarios

típicos/frecuentes hasta los más excepcionales
65
ë
PAs … ¿Cuándo?
“Modelo V” para pruebas

Especificación Pruebas de
de Requisitos Aceptación
Análisis de Pruebas de
Requisitos Sistema
Diseño de Pruebas de
Arquitectura Integración
Diseño de Pruebas
Módulos Unitarias
Diseño de Pruebas Aplicación de

Programación
Pruebas
66
ë
Aprovechamiento de las PAs
Adicional a su propósito fundamental, las PAs pueden

rentabilizarse usándose para:
Obligara definir requisitos que sean verificables
(IEEE 830)
Valorar adecuadamente el esfuerzo asociado a la
incorporación de un requisito
Negociar con el cliente el alcance del sistema
Planificar el desarrollo iterativo e incremental del
sistema
Guiar el desarrollo incremental
Identificar oportunidades de reutilización
67
ë
Especificación de requisitos
Nombre del Requisito: Retirar dinero

client
client
1 : Pin()
client
: TMDistributor
1 : Pin()
: TMDistributor
: TMDistributor
☺ Pero …
client : TMDistributor
2 : Pin Ok() 1 : Pin()
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
☺
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
4 : Saldo insuficiente()
3 : Cantidad()
2 : Pin Ok()
3 : Cantidad()
2 : Pin Ok()
3 : Cantidad()
Descripción narrativa
Diagramas de Secuencia ☺
Caso de Uso

Plantilla Bocetos de IU
68
ë
Requisitos y Pruebas de Aceptación
1 : Pin()
1 : Pin()
2 : Pin Ok() 1 : Pin()
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
2 : Pin Ok() 1 : Pin()
3 : Cantidad()
3 : Cantidad() 1 : Pin()
4 : Saldo insuficiente() 2 : Pin Ok()
3 : Cantidad()
2 : Pin Ok()
3 : Cantidad()
4 : Saldo insuficiente() 2 : Pin Ok()
3 : Cantidad()
Descripción narrativa (breve)
Diagramas
de Secuencia
Caso de Uso
Plantilla Bocetos de IU
69
ë
Requisitos + UIs + PAs
Descripción narrativa
Caso de Uso
(Sólo identificación)
Bocetos de IU
70
ë
… Ejemplo
Identificación de Pruebas de Aceptación
1. Reintegro usando cantidades predefinidas
2. Reintegro con cantidad introducida por cliente
3. Intento reintegro saldo < cantidad
4. Cancelación de operación
5. No disponibilidad de billetes
6. No disponibilidad de papel para recibo
7. Intento reintegro saldo < cantidad con cliente preferencial
8. Excedido tiempo de comunicación con sistema central
9. Excedido tiempo de espera para introducción de acción
10. …
71
ë
… Ejemplo
Identificación de Pruebas de Aceptación

1. Reintegro usando cantidades predefinidas
2. Reintegro con cantidad introducida por cliente
3. Intento reintegro saldo < cantidad
4. Cancelación de operación
Obligar a definir requisitos que sean verificables
5. No disponibilidad de billetes
Valorar adecuadamente el esfuerzo asociado a la
incorporación de un requisito
6. No disponibilidad de papel para recibo
Negociar con el cliente el alcance del sistema
7. Intento reintegro saldo < cantidad cliente preferencial
Planificar el desarrollo iterativo e incremental del
8. Excedido tiempo sistema
de comunicación con sistema central
9. Excedido tiempo de espera
Guiar para introducción
el desarrollo incremental de acción
10. … Identificar oportunidades de reutilización
72
ë
Conclusiones
Notación y Herramientas no son las “balas de plata”
para el éxito en desarrollo de software … el proceso
tampoco, pero puede tener un impacto más
significativo en dicho éxito (o fracaso)
“Preferir PAs como especificación de requisitos”, esto
tiene múltiples ventajas
La “cultura” de pruebas puede introducirse de
manera efectiva y “rentable” a partir de pruebas de
aceptación
Enfoque validado en contexto académico e industrial
La automatización de pruebas es interesante pero

no está ajena a otros inconvenientes
73
ë
ë www.dsic.upv.es/~letelier Contexto del proyecto
74
ë www.dsic.upv.es/~letelier … Conclusiones
75

Proceso Desarrollo

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Proceso Desarrollo

Enviado por

Direitos autorais:

Formatos disponíveis

Proceso Software

dirigido por las Pruebas

CIF 9159 – Taller Integrado

II. Modelado de Software con UML

IV. Introducción al Proceso de Desarrollo de Software

V. Metodologías Ágiles versus Tradicionales

VI. Pruebas de Aceptación y Proceso Software

II. Modelado de Software con UML

IV. Introducción al Proceso de Desarrollo de Software

V. Metodologías Ágiles versus Tradicionales

VI. Pruebas de Aceptación y Proceso Software

Construcción de una casa para “fido”

Puede hacerlo una sola persona

Construcción de una casa familiar

II. Modelado de Software con UML

IV. Introducción al Proceso de Desarrollo de Software

V. Metodologías Ágiles versus Tradicionales

VI. Pruebas de Aceptación y Proceso Software

Un modelo captura una vista de un sistema del

Un proceso de desarrollo de software debe contar un conjunto

El código fuente del sistema es el modelo más detallado del

Cada modelo es completo desde su punto de vista del sistema,

Modelo: Representación del software =>

¿Cuánto y cómo modelar?

producto y debe además estar acorde con la

Nivel de aprovechamiento Generar parcial o totalmente una

2 Tomar decisiones de análisis/diseño

1 Comunicar ideas y estudiar alternativas

• Favorece el desarrollo iterativo del sistema

Los diagramas expresan gráficamente partes de un modelo

UML es la notación más amplia / exhaustiva /

“El 80 por ciento de la mayoría de los

• En un “mundo OO ideal” no sería necesario el modelado de

En el “mundo OO actual” el uso de BD relacionales conlleva

El programador escribe sentencias SQL en los métodos y

¿Cómo derivar un MLR a partir del Modelo de Análisis/Diseño

¿Qué notación y herramienta utilizar?

Profile UML para modelado de datos junto a herramienta CASE

Requisitos de usuario (Stakeholder goals/needs)

Objetivos y necesidades del cliente

Requisitos de sistema (Software Features)

Servicios y restricciones que puedan constituir un contrato

Requisitos de software (Use Cases)

Descripción que sirva como base para el diseño e

UML no aborda la especificación de requisitos no

Requisitos Análisis Diseño Implementación

Diagramas de Flujo de Diagramas

Procesos – Código - Comportamiento

II. Modelado de Software con UML

IV. Introducción al Proceso de Desarrollo de Software

V. Metodologías Ágiles versus Tradicionales

VI. Pruebas de Aceptación y Proceso Software

Soporte para actividades/notaciones

• Entornos Integrados de Desarrollo – IDEs

• Herramientas para Pruebas

• Herramientas para Ingeniería de Requisitos

Veamos algunas herramientas …

Modelado y generación de código en dominios

• Eclipse Modeling Framework (EMF,

• Microsoft Tools for Domain Specific Languagues –

• Domain-Specific Modeling (DSM, www.dsmforum.org)

• Meta CASE Tools, MetaEdit+ (www.metacase.com)

II. Modelado de Software con UML

IV. Introducción al Proceso de Desarrollo de