Microsoft Word - Metodologia de Analisis de Riesgo Cissp

División de Alta Tecnología – DAT
UML 2.3 con Enterprise Architect
ANALISIS Y DISEÑO DE SOFTWARE
UML 2.3 con Enterprise

Architect
OBJETIVOS DEL CURSO
 Usar UML para el análisis y diseño orientado a

objetos.
 Aplicar el análisis y diseño iterativo, basado en casos
de uso para desarrollar modelos eficientes y
robustos.
 Modelar clases, objetos, componentes, atributos,
operaciones, relaciones, multiplicidad.
 Analizar un problema concreto para representar una
realidad en objetos y transformarla en un modelo
UML por medio de una herramienta
 Manipular los diagramas en UML 2.3
 Generar código y actualizar el modelo.
División de Alta Tecnología - DAT
METODOLOGÍA DEL CURSO
 45 horas de Teoría y práctica.

 Material audiovisual
 Libro del curso, presentaciones
 Participación individual y grupal
 Laboratorios en clase
1
EVALUACIÓN DEL CURSO
 PPC = Promedio de prácticas calificadas

 2 Prácticas calificadas (sesiones por definir)
 Tareas
 TF = Trabajo Final (Última sesión)
 EF = Examen Final (Penúltima sesión)
Promedio = 30% (PPC) + 30% TF + 40% EF
UML 2.3 con Enterprise

Architect
Capitulo 1. Introducción al
Análisis y Diseño
orientado a Objetos
Capítulo 1:
Introducción al Análisis y Diseño orientado
a Objetos
Temas:
1. Crisis del software
2. El modelado
3. Conceptos iniciales
4. Buenas prácticas
2
Capítulo 1:
a Objetos
Introducción al Análisis y Diseño orientado a Objetos
1. Crisis del Software
1.1 Introducción
1.2 Síntomas
1.3 Razones
1.4 Soluciones
1.1. INTRODUCCIÓN
 La crisis del software:

 No satisface los requerimientos.
 No satisface las necesidades del cliente.
 Excede los presupuestos.
 Excede el cronograma inicial.
3
1.1. INTRODUCCIÓN
 Casos:
 El departamento de vehículos motorizados de
California gastó sobre $43 millones de dólares
en un sistema para fundir los sistemas de
conductores y registro de vehículos
 El sistema fue abandonado sin ni siquiera
haber sido usado.
 Un fallido esfuerzo de $165 millones de
dólares de American Airlines de vincular su
software de reserva de pasajes con el sistema
de reservaciones de Marriott, Hilton y Budget.
1.2. SÍNTOMAS
 Baja calidad del producto de software.

 Tiempo y presupuesto inicial excedido.
 Confiabilidad cuestionable.
 Altos requerimientos de personal para desarrollo
y mantenimiento.
Figura: http://thumbs.dreamstime.com/thumb_0/1083885788In01Lh.jpg
1.3. RAZONES
 Algunas razones:
 Base Inestable
 Fallas en el manejo del riesgo
 La complejidad del software
4
1.4. SOLUCIONES
 Se recomienda:
 Buen Análisis y Diseño
 Construir un modelo sencillo
 Usar un lenguaje de modelado
 Compatible con diversas herramientas
Capítulo 1:
a Objetos
Temas:
2. El modelado
2. El modelado
2.1 Introducción
2.2 La importancia de modelar
2.3 Modelamiento
2.4 Métodos para el modelado
5
2.2. LA IMPORTANCIA DE MODELAR
 La elaboración de un modelo para el desarrollo

de un sistema antes de su programación es tan
importante como tener un modelo (planos) y los
cimientos antes de construir una casa.
“Un modelo es la simplificación de la realidad”
2. El modelado
2.3. MODELAMIENTO
Cervantes
Concepto
sin objeto
Objeto sin
Concepto
Napoleón
2. El modelado
2.4. MÉTODOS PARA EL MODELAMIENTO
1 No-formales
2 Semi-formales
3 Formales
2. El modelado
6
Capítulo 1:
a Objetos
Temas:
2. El modelado
3. Conceptos Iniciales
3.1 Objeto
3.2 Orientación a objetos
3.3 Principio del software OO
3.4 Clases
3.1 OBJETO
“Es un ente real o conceptual que posee

características y comportamiento propios, únicos
e inconfundibles”
Computador
Andrea Lamas
Serie 26588-A
7
3.1.2. CARACTERÍSTICAS
 Identidad:
 Cada objeto tiene una identidad única, incluso
si su estado es idéntico al de otro objeto.
3.1. Objeto
 Atributos y Operaciones:
 Atributos:
 Nombre
 Estatura
 Edad
 Comportamiento
(operación):
 Caminar
 Hablar
 Saltar
3.1. Objeto
 Comportamiento
 Agrupa las competencias de un objeto
 Conocido como OPERACIÓN
 Es consecuencia de un estímulo externo
(mensaje)
Ejemplo: Prender CPU
 Estado
 Representado por los valores de los
atributos
Ejemplo: Prendido, apagado
3.1. Objeto
8
3.1. OBJETOS. Identificación de elementos
Imaginemos que tenemos estacionado

en nuestra cochera un Audi - A8 6.0
450CV quattro, color azul que corre
hasta 250 km/h.
Marca = Audi
Modelo = A8 6.0 450CV quattro
Color = Azul
Velocidad Máxima = 250 km/h
Cuando a las características del objeto se le asignan valores, se dice

que el objeto tiene estados.
3.1.3. COMUNICACIÓN ENTRE OBJETOS
Objeto 1
: Mensaje A
Objeto 2
: Mensaje E
: Mensaje C
Objeto 3 Objeto 4
: Mensaje D
3.1. Objeto
LABORATORIO N° 1
 En este laboratorio, usted:

 Identificará los objetos del enunciado
 Establecerá la diferencia con otros elementos
9
3.2. ORIENTACIÓN A OBJETOS
“Conjunto de disciplinas que desarrollan y

modelizan software que facilitan la construcción
de sistemas a partir de componentes.”
3.3 PRINCIPIOS DEL SW OO
 Abstracción
 Encapsulamiento
 Principio cliente-servidor
 Jerarquías
 Polimorfismo
 Modularidad
 Persistencia
3.4. CLASES
 Conjunto de objetos con características

(atributos) y comportamientos (operaciones)
similares.
Juan Arias José López Mary Falcón

DNI 07715221 DNI 08816721 DNI 05814423
CLASE:
Ate Lince San Borja
Persona
10
3.4.2. NOMBRAMIENTO DE CLASES
 Guía de estilo:
 Usar un sustantivo singular.
 Los nombres de la clase deben empezar con
mayúsculas.
 No debe usarse el subrayado.
 Los nombres compuestos se ponen juntos y la
primera palabra se escribirá con mayúscula.
 Ejemplo:
 Alumno, SistemaDePago
3.4. Clases
3.4.3. NOTACIÓN DE CLASES EN UML
 Representación gráfica
 Nombre
 Estructura (atributos)
 Comportamiento (operaciones)
Profesor
-Apellidos
-Nombres
-Grado Academico
+consulta_grado()
+graba_sueldo()
Representación UML
3.4. Clases
LABORATORIO N° 2

 Identificará las clases del enunciado.
 Establecerá la diferencia con los objetos.
 Identificará los elementos que servirán de
atributos a las clases.
11
Capítulo 1:
a Objetos
Temas:
2. El modelado
4. Buenas Prácticas
4.1. Las 6 mejores prácticas
a) Desarrollar software iterativamente
b) Administrar los requerimientos
c) Utilizar arquitecturas basadas en componentes
d) Modelar software visualmente
e) Verificar la calidad del software
f) Controlar los cambios al software
4.2. Consecuencias de no aplicar las buenas prácticas
4.1. LAS 6 MEJORES PRÁCTICAS
ADMINISTRAR REQUERIMIENTOS
Arquitecturas
Desarrollar Verificar Modelizar
Basadas en
Iterativamente Calidad Visualmente
Componentes
CONTROLAR CAMBIOS
12
4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE
 Cada iteración resulta en un release ejecutable
Requerimientos
Análisis y Diseño
Planeamiento
Implementación
Planeamiento
Inicial Ambiente de
Administración
Distribución
Evaluación
Prueba
4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE
 Características:
 Los desentendimientos importantes se
evidencian tempranamente.
 Se alienta el feedback del usuario.
 Focalización en los temas más críticos, sin
distracciones.
 Testing continuo e iterativo: evaluación
objetiva.
 Detección temprana de inconsistencias entre
requerimientos, diseños e implementaciones.
4.1.2. ADMINISTRAR LOS REQUERIMIENTOS
 Los requerimientos pueden ser adecuadamente

capturados y comunicados, a través de Casos de
Uso.
 Los Casos de Uso son importantes instrumentos
de planificación.
Modelo de Casos de Uso
Los Casos de Uso direccionan

el trabajo desde el análisis Realización influenciados por verifica
hasta el test
Modelo de Diseño
Modelo de Implementación Modelo de Test
13
4.1.2. ADMINISTRAR LOS REQUERIMIENTOS
¿Cómo son interpretados los

requerimientos?
Necesito
algo para
balancearme
bajo un árbol
¿Cómo lo explicó el
cliente?
¿Cómo son interpretados los requerimientos?
¿Cómo lo entendió el ¿Cómo fue descrito ¿Cómo fue analizado

líder del proyecto? por el consultor? y diseñado?
¿Cómo fue ¿Cómo fue ¿Cómo fue

programado? documentado? instalado?
14
¿Cómo fue ¿Qué soporte se ¿Qué necesitaba

cobrado? brindó? realmente el cliente?
4.1.3. UTILIZAR ARQUITECTURAS BASADAS EN

COMPONENTES
 Un componente de software puede definirse como

una pieza no trivial de software, un módulo o un
subsistema que completa una función clara, tiene
límites claros y puede ser integrado en una
arquitectura bien definida.
Aplicación
Negocio
Arquitectura basada Middleware

en componentes
System-
software
4.1.3. UTILIZAR ARQUITECTURAS BASADAS EN

COMPONENTES
 La Arquitectura de Software representa el

conjunto de decisiones significativas sobre la
organización de un sistema de software:
 Selección de los elementos estructurales y sus
interfaces, por los cuales el sistema está compuesto.
 Comportamiento, especificado como colaboraciones
entre los elementos.
 Composición en subsistemas de los elementos
estructurales y de comportamiento.
 Estilo de arquitectura que guía a la organización.
15
4.1.4. MODELAR SOFTWARE VISUALMENTE
Subsistemas
La Modelización
Clases
Visual eleva el nivel
de abstracción
Código
4.1.4. MODELAR SOFTWARE VISUALMENTE
 Beneficios:
 Los casos de uso permiten especificar
comportamiento sin ambigüedades.
 Quedan expuestas las arquitecturas
inflexibles o no modulares.
 El diseño refleja sus inconsistencias más
rápidamente.
 Existen herramientas que proveen soporte
para la modelización visual.
4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE
 La actividad fundamental de esta práctica es el

testing.
 Evaluar continuamente la calidad de un sistema
con respecto a funcionalidad, confiabilidad y
performance.
Encontrar y reparar un Costo

problema de software después
de la implementación puede
resultar de 100 a 1000 veces
más costoso
Desarrollo Implementación
16
4.1.5. VERIFICAR LA CALIDAD DEL SOFTWARE
 Beneficios:
 La evaluación del estado del proyecto es
objetiva, pues se evalúan resultados de test.
 Se exponen las inconsistencias en los
requerimientos, diseños e implementaciones.
 Se focaliza en las áreas de riesgo más alto.
 Los defectos se identifican en forma
temprana.
 Existen herramientas automatizadas para el
testing de funcionalidad, confiabilidad y
performance.
4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE
El manejo del cambio es más que apenas comprobar dentro y fuera de

archivos. Incluye el manejo de espacios de trabajo, del desarrollo
paralelo, de la integración y de construcciones.
4.1.6. CONTROLAR LOS CAMBIOS AL SOFTWARE
 Beneficios:
 Las solicitudes de cambios formales facilitan
la claridad de comunicación.
 Los espacios de trabajo aislados reducen la
interferencia entre los miembros del equipo
que trabajan en paralelo.
 Las estadísticas de cantidad de cambios
proveen buenas métricas para evaluar
objetivamente el estado del proyecto.
 La propagación del cambio es evaluable y
controlable.
 Los cambios pueden ser mantenidos en
sistemas automáticos.
17
4.2. CONSECUENCIAS DE NO APLICAR LAS

BUENAS PRÁCTICAS
Baja
Calidad del
software
4.2.1. Detección del fracaso en un proyecto
 No cumplen sus objetivos.

 Se exceden considerablemente en el tiempo.
 Se exceden de su presupuesto.
 No se comprendieron las necesidades del
usuario.
 No se previó el impacto de los requerimientos
de cambios.
 Se descubrieron muy tarde falencias graves
en el Proyecto.
 Hay módulos que no se pueden integrar.
 Interferencias entre los miembros del equipo.
4.2.3. LAS MEJORES PRÁCTICAS ENFRENTAN LAS CAUSAS
18
SOLUCIÓN A LOS PROBLEMAS DE SW
 Mejorar el proceso de desarrollo de Software
Seleccionar el Seleccionar el
mejor método de mejor estándar
desarrollo de modelado
LABORATORIO N° 3

 Reconocerá las 6 mejores prácticas.
 Identificará como se aplican las 6 mejores
prácticas en el desarrollo de un proyecto.
BIBLIOGRAFÍA RECOMENDADA
 UML 2 Toolkit.
 OMG Press
 Autores: Hans-Erik Eriksson, Magnus Perker,
Brian Lyons, David Fado.
 UML 2.0,
 Anaya Multimedia
 Autores: Jim Arlow, Ila Neustadt
19
BIBLIOGRAFÍA RECOMENDADA
 El Proceso Unificado de Desarrollo de Software.

 Jacobson I., Rumbaugh J., BOOCH G.
 2000. Addison Wesley.
 El Lenguaje Unificado de Modelado.
 El Lenguaje Unificado de Modelado. Manual de
Referencia.
20

Microsoft Word - Metodologia de Analisis de Riesgo Cissp

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Microsoft Word - Metodologia de Analisis de Riesgo Cissp

Cargado por

Copyright:

Formatos disponibles

División de Alta Tecnología – DAT

UML 2.3 con Enterprise Architect

ANALISIS Y DISEÑO DE SOFTWARE

UML 2.3 con Enterprise

OBJETIVOS DEL CURSO

 Usar UML para el análisis y diseño orientado a

División de Alta Tecnología - DAT

METODOLOGÍA DEL CURSO

 45 horas de Teoría y práctica.

División de Alta Tecnología - DAT

EVALUACIÓN DEL CURSO

 PPC = Promedio de prácticas calificadas

Promedio = 30% (PPC) + 30% TF + 40% EF

División de Alta Tecnología - DAT

UML 2.3 con Enterprise

UML 2.3 con Enterprise Architect

División de Alta Tecnología - DAT

UML 2.3 con Enterprise Architect

1. Crisis del software

División de Alta Tecnología - DAT

Introducción al Análisis y Diseño orientado a Objetos

1. Crisis del Software

División de Alta Tecnología - DAT

 La crisis del software:

1. Crisis del Software

1. Crisis del Software

 Baja calidad del producto de software.

1. Crisis del Software

1. Crisis del Software

1. Crisis del Software

UML 2.3 con Enterprise Architect

División de Alta Tecnología - DAT

Introducción al Análisis y Diseño orientado a Objetos

División de Alta Tecnología - DAT

2.2. LA IMPORTANCIA DE MODELAR

 La elaboración de un modelo para el desarrollo

“Un modelo es la simplificación de la realidad”

2.4. MÉTODOS PARA EL MODELAMIENTO

UML 2.3 con Enterprise Architect

División de Alta Tecnología - DAT

Introducción al Análisis y Diseño orientado a Objetos

División de Alta Tecnología - DAT

“Es un ente real o conceptual que posee

3.1. OBJETOS. Identificación de elementos

Imaginemos que tenemos estacionado

Cuando a las características del objeto se le asignan valores, se dice

3.1.3. COMUNICACIÓN ENTRE OBJETOS

 En este laboratorio, usted:

División de Alta Tecnología - DAT

3.2. ORIENTACIÓN A OBJETOS

“Conjunto de disciplinas que desarrollan y

3.3 PRINCIPIOS DEL SW OO

 Conjunto de objetos con características

Juan Arias José López Mary Falcón

3.4.2. NOMBRAMIENTO DE CLASES

3.4.3. NOTACIÓN DE CLASES EN UML

 En este laboratorio, usted:

División de Alta Tecnología - DAT

UML 2.3 con Enterprise Architect

División de Alta Tecnología - DAT

Introducción al Análisis y Diseño orientado a Objetos

División de Alta Tecnología - DAT

4.1. LAS 6 MEJORES PRÁCTICAS

4.1.1. DESARROLLAR SOFTWARE ITERATIVAMENTE