Ingeniería Del Software: Colegio de Ingenieros Del Perú

Colegio de Ingenieros del Per
Consejo Departamental Ancash-Chimbote
Ingeniera del Software

Ing. Franz Denis Vargas Morales.
Sntomas de Problemas del Software
Necesidad de los usuarios o negocio no alcanzadas Requerimientos cambian Los mdulos no se integran Difcil de mantener Descubrimiento tardo de defectos Pobre calidad o pobre experiencia del usuario final Pobre desempeo bajo carga real Esfuerzo no coordinados del equipo de proyecto Problemas con construcciones y lanzamientos
Seguimiento de los sntomas a las causas

Symptoms
Needs not met
Root Causes
Insufficient requirements
Best Practices
Develop Iteratively Manage Requirements
Requirements churn
Modules dont fit Hard to maintain Late discovery
Ambiguous communications
Brittle architectures Overwhelming complexity Undetected inconsistencies
Use Component Architectures

Model Visually (UML) Model Visually (UML)
Poor quality
Poor performance Colliding developers Build-and-release
Poor testing
Subjective assessment Waterfall development Uncontrolled change Insufficient automation
Continuously Verify Quality Continuously Verify Quality

Manage Change
Ciclo de vida del software
Guide to the Software Engineering Body of Knowledge (SWEBOK) (Versin 0.95)
Software Requirements
Requirenents Engineering Process Requirements Elicitation Requirements Analysis Requirements Specification Requirements Validation Requirements Management
Software Design
Software Design Basic Concepts Key Issues in Software Design Software Structure and Architecture Software Design Quality Analysis and Evaluation Software Design Notations Software Design Strategies and Methods
Software Construction
Reduction in complexity (Linguistic,Formal & Visual Construction Methods) Anticipation of Diversity (Linguistic,Formal & Visual Construction Methods) Structuring for Validation (Linguistic,Formal & Visual Construction Methods) Use of External Standards (Linguistic,Formal & Visual Construction Methods)
Software Testing
Testing Basic Concepts and Definitions Test Levels Test Techniques Test-Related Measures Managing the Test Process
Software Maintenance
Basic Concepts Maintenance Process Keys Issues in Software Maintenance
Fuente: http://www.computer.org/
Guide to the Software Engineering Body of Knowledge (SWEBOK) (Versin 0.95) Software Configuration Management
Management of the SCM Process Software Configuration Identification Software Configuration Control Software Configuration Status Accounting Software Configuration Auditing Software Release Management and Delivery
Software Engineering Management

Organizational Management Process/Project Management Software Engineering Measurement
Software Engineering Process

Software Engineering Process Concepts Process Infrastructure Process Measurement Process Definition Qualitative Process Analysis Process Implementation and Change
Software Engineering Tools and Methods

Software Tools
(Software requirements,design, construction, testing, maintenance, engineering process, quality, configuration management,engineering management, support and miscellaneous tools)
Software Quality
Software Quality Concepts Definition & Planning for Quality Techniques Requiring Two or More People Support to Other Techniques Testing Special to SQA or V&V Defect Finding Techniques Measurement in Software Quality Analysis
Software Methods (Heuristic,

Formal, PRototyping and miscellanous methods)
Fuente: http://www.computer.org/
Las Seis Buenas Prcticas
Buenas Prcticas
Desarrollar Iterativamente Administrar requerimientos Usar arquitectura de componentes Modelar visualmente (UML) Verificar la calidad continuamente Gestionar los cambios
7
Modelo Iterativo incremental
Modelo Iterativo incremental
El Perfil de los Riesgos
Riesgos en modelo en cascada
Riesgos
Reduccin de Riesgos
Riesgos en modelo iterativo
Tiempo
10
Buenas Prcticas
11
Ingeniera de Requerimientos dentro del SWEBOK
Fuente: http://www.swebok.org
12
Ciclo de Vida NTP-ISO/IEC 12207

Procesos Principales 1. Adquisicin 2. Suministro 3. Desarrollo 4. Operacin Procesos de Apoyo
1. Documentacin 2. Gestin de la Configuracin 3. Aseguramiento de la Calidad 4. Verificacin 5. Validacin
5. Mantenimiento
6. Revisin Conjunta 1. Gestin 2. Infraestructura 3. Mejora 7. Auditora
Organizativos
8. Solucin de Problemas
4. Recursos Humanos
13
NTP ISO/IEC 12207 Procesos del Ciclo de Vida del Software
14
Requerimientos y Cambios: Dnde estamos?
15
Ingeniera de los Requerimientos
Denota el proceso de especificar los requerimientos a travs del estudio de las necesidades de los involucrados (stakeholders), analizar sistemticamente y refinar dichas especificaciones
16
reas Principales de la IR
Gestin de los Requerimientos
Especificacin
Procesos de Ingeniera de Requerimientos

17
Captura
Validacin
Anlisis
Definiendo: Requerimiento
IBM Rational:
una condicin o capacidad a la que debe ajustarse el software que se construye Una capacidad del software requerida por el usuario para resolver un problema o alcanzar un objetivo
IEEE Std 830:
18
Definiendo: Administracin de Requerimientos
Enfoque sistemtico para capturar, documentar, organizar, documentar los requerimientos del sistema. Un proceso que establece y mantiene acuerdo entre clientes y equipo de proyecto sobre los requerimientos cambiantes del sistema.
19
Por qu administrarlos?
Son los mayores contribuyentes al fracaso de los proyectos (Standish Groups CHAOS Reports:1994-1997) El cambio de los requerimientos del usuario se considera la causa ms frecuente en el fracaso de los proyectos (Computer Industry Daily:1997)
20
Buenas Prcticas
21
Arquitecturas basadas en componentes resilentes
Resilente:
Alcanza requerimientos actuales y futuros Mejora la extensibilidad Permite el reuso Encapsula dependencias entre sistemas Reusa o adapta componentes Seleccionar componente comerciales Evoluciona el software actual de manera incremental
Basada en Componentes:

22
Propsito de Arquitectura Basada en Componentes
Es la base para el reuso de
Componentes Arquitectura Planeamiento Staffing Entregas Administrar complejidad Mantener integridad
Base para la gestin de proyecto

Aplicacin
Control Intelectual
Negocio
Middleware
Software de Sistema
23
Marco General de la Ingeniera del Software: la arquitectura?
24
NTP ISO/IEC 12207 Procesos del Ciclo de Vida del Software

Para cada elemento software (o elemento de configuracin) Preparar el diseo detallado del componente. Refinar hasta los niveles ms bajos, que contienen las unidades que puedan ser codificadas, compiladas y probadas Preparar y documentar el diseo de las interfaces externas. Deber permitir la codificacin sin ms informacin Preparar y documentar el diseo de los datos Definir, documentar y planear los requisitos de pruebas de unidades. Evaluar el diseo y los requisitos usados como base Para cada elemento software (o elemento de configuracin)
25
Arquitectura: Dnde estamos?
26
Buenas Prcticas
27
Qu es un Modelo?

Un modelo es una simplificacin de la realidad. Un modelo provee los planos del sistema. Un modelo podra ser estructural, enfatizando la organizacin del sistema. Un modelo podra ser dinmico, enfatizando la dinmica del sistema.
28
Por Qu Modelamos?
Construimos modelamos para comprender mejor el sistema que se desarrollar. El modelado tiene como objetivos:
Ayudar a visualizar cmo es o queremos que sea el sistema. Permitir especificar la estructura o el comportamiento del sistema. Proporcionar plantillas que guan en la construccin del sistema. Documentar las decisiones que se adopten.
29
La Importancia del Modelado
Para construir modelos de software complejos porque no podemos comprender el software en su totalidad.
Otros... Palabras Maquetas Fotos Satelitales Modelos mentales Diagramas
C HI N A
B U R MA
T AIW AN
Planos
LA
OS
B at an Is.
B ab u y an Is.
Luzo n
TH A I LA N D
SOUTHEAST ASIA
0 100 0 200 200 400 400 600 600 KM M I
NAM
M ANI LA
C A M B O D I A
Min d o ro
S amar P an ay Ley te
Pa
la
wa
I E
Neg ros
Bandar Seri Begawan
S U LU
Min d an ao
C ities and Towns
Ca pi ta ls 1 , 0 0 0 ,0 0 0 a nd ov e r -
BRUNEI
S E A
P AC I F IC
S u lu Arch ip el ag o
M A L A YS I A
Nan t un a Is . An amb as Is.
SAB A H
Grficos Estadsticos
PAPUA NEW GUINEA
P H IL IP P IN E S E A
PH IL IP
PIN ES
IN
B an y ak Is.
KUAL A LUM PUR
A AY AL M
O CE A N
S an g ih e Is lan ds Tal au d Is .
CE LE B E S
K AWA SAR
B OR N EO K A L I MA N TA N
S U
M en taw ai Is.
S E A
M A
SI NGA PORE
B at u Is .
BE
Karimata B an g k a Arch .
MOLUCCA SEA
B an g g ai Arch .
B acan Is . Ob i Is.
Hal mah era S ch o ut en Isl an d s
LE
B il lit on
CE
I N D J A V O N E S I A A
JAKA
NG BANDU
I N D IA N
T R A
Gulf of Bone
J AVA RTA SEA
ra Madu
Kan g ean Is .
S ul a Is .
CERAM
B u ru
SEA
C eram
IRI AN
Kai Is. Aru Is. Tan imb ar
JAY
BANDA SEA
ang Semar
F LOR E S
S umb awa
S E A
Is .
B al i
Sumb a
SAVU SEA
Timo r
S awu Is.
OC E A N
A US TR AL I A
Partituras
Mapas
30
Los 4 Principios del Modelamiento
Los modelos creados influencian la forma de atacar el problema. Cada modelo puede expresarse en diferentes niveles de precisin. Los mejores modelos estn conectados a la realidad. No es suficiente un nico modelo.
31
Principio 1: La eleccin del modelo es importante
Los modelos creados influyen profundamente como el problema es resuelto y la forma de la solucin.

En software, los modelos elegidos afectan la visin del mundo. Cada visin del mundo conduce a diferentes tipos de sistemas.
Modelo de Proceso
Modelo de Despliegue
Modelo de Diseo
32
1.1. La Eleccin del Modelo

No existe un nico modelo que muestre todo el sistema La eleccin de qu modelos crear tiene una profunda influencia sobre cmo se acomete un problema y cmo se da forma a una solucin
33
Principio 2: El nivel de precisin puede variar
Cada modelo puede ser expresado en diferentes niveles de precisin.
El mejor tipo de modelo permite escoger el grado de detalle, dependiendo de:

Quin ve el modelo? Por qu necesita verlo?.
Vista del cliente

34
Vista del Diseador
2.1. Los niveles de precisin
Todo modelo puede ser expresado a diferentes niveles de precisin
35
Principio 3: Modelos conectados a la realidad

Todos los modelos simplifican la realidad. Un buen modelo refleja las caractersticas potencialmente fatales.
36
3.1. Modelos Ligados a la realidad
Es mejor tener modelos que tengan una clara conexin de la realidad y donde esta conexin sea dbil saber exactamente cmo se apartan esos modelos del mundo real Todos los modelos simplifican la realidad.
37
Principio 4: Un nico modelo no es suficiente
Un simple modelo no es suficiente. Cada sistema no trivial o complejo se enfoca mejor a travs de un conjunto limitado de modelos relativamente independientes. Cree nuevos modelos que puedan ser construidos y estudiados de manera separada, pero interrelacionados.
Logical View
Analysts/Designers
Structure
Implementation View
Programmers
Software management
Use-Case View
End-user Functionality
Process View
System integrators
Performance, scalability, throughput
Deployment View
System engineering
System topology, delivery, installation, communication
38
4.1. Un nico modelo no es suficiente
Cualquier sistema no trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes.
39
Por Qu Modelar Visualmente?

Capturar estructura y comportamiento Mostrar como se ensamblan los elementos Mantener diseo e implementacin consistentes Ocultar o exponer detalles cuando sea apropiado Promover comunicacin no ambigua
UML: Un lenguaje para todos
40
Comunicacin NO AMBIGUA
41
El Modelo Arquitectura 4+1 Vistas

Vista Estructural Vista de Implementacin
Analistas/ Diseadores
Estructura
Usuarios Finales Funcionalidad
Programadores Administracin del Software
Vista Casos de Uso

Integradores de Sistemas Vista de Performance Escalabilidad Proceso Throughput Ingenieros de Sistemas
Vista de Despliegue
Topologa Entrega, instalacin comunicacin
*Se puede incorporar la Vista de Datos al modelo propuesto

42
Modelamiento Visual con UML 1.4

Diagrama Secuencias Diagrama Caso de Uso
Diagrama Colaboracin
Diagrama Clases
Diagrama Actividad
Modelo
Diagrama Objetos
Diagrama Estados
Diagrama Despliegue
Diagrama Componentes
43
Modelamiento Visual con UML 2.0

diagramas)
Diagrama Tiempos
(13
Diagrama Secuencias
Diagrama Caso de Uso
Diagrama de Paquetas
Diagrama Comunicacin
Diagrama Clases
Diagrama Actividad
Modelo
Diagrama Objetos
Diagrama de Visin Global de Interacciones
Diagrama Estados
Diagrama Despliegue
Diagrama Componentes
Diagrama Estructura Compuesta
44
Las Buenas Prcticas y el RUP
Enfoque Iterativo Guas para actividades y artefactos Proceso enfocado en la arquitectura Casos de uso que conducen el diseo y la implementacin Modelos que abstraen el sistema
45
RUP: Un proceso basado en equipos
Proceso de Ingeniera de Software

El Producto
rol
Interfaces con otros procesos
consume artefacto
46
produce
actividad
Estructura del Proceso: Ciclo de Vida y Fases
47
Principales Hitos
Concepcin
Elaboracin
Construccin
Transicin
Kick-Off: Lanzamiento Oficial del Proyecto Project Life Cicle Objectives (LCO): Compromiso con los objetivos del proyecto Product Life Cycle Architecture (LCA): Compromiso con una arquitectura viable del producto. Product Initial Operational Capabilities (IOC): Liberacin del producto con las capacidades operacionales comprometidas Product General/Gold Availlability (GA): Disponibilidad general del producto
48
Iteraciones y Fases
Una fase se estructura en iteraciones
En una Iteracin se desarrollan actividades de las diferentes disciplinas
Una iteracin es una secuencia distinta de actividades basadas en un plan establecido y criterios de evaluacin, resultando en un release? (interno o externo) ejecutable
49
I. Disciplina de Modelado de Negocio del RUP
50
Modelo de Casos de Uso del Negocio
51
Modelo de Anlisis del Negocio
Diagrama de actividades general
52
Diagrama de actividades Sub proceso
53
Modelo de dominio
54
Manos a la obra ...

Actividad
Tomando como referencia el caso de estudio, realizar: (1) Modelo del Negocio (2) Modelo de Anlisis del Negocio
55
II. Disciplina de Requisitos del RUP
56
Roles y responsabilidades
57
Conceptos bsicos de la Ingeniera de Requerimientos
Especificacin

58
Captura
Validacin
Anlisis
Flujo de Captura de Requerimientos
Escenario 1
Actores
Escenario n
Casos de Uso
59
Artefactos de Requerimiento
60
Dnde estn ahora sus Requerimientos?

Analice el problema a ser resuelto. Entienda las necesidades de los stakeholder. Organice Requerimientos iniciales .
Documents Documents
Hoja de clculo
Listas
Rotafolios
E-mails
Analista
61
Los Requerimientos y los Documentos Asociados

Necesidades
Documento de Visin
Caractersticas
Necesidades
Requerimientos de software
Modelo de CU
Especificaciones
Suplementarias
Requerimientos de Diseo, Test, y Documentacin

62
Especificaciones de Diseo
Documentacin de Usuario
Actividades Principales de la Obtencin de Requerimientos

: Escenario
Identificacin de Actores del sistema
Identificacin de Escenarios
Identificacin de Casos de Uso
Refinamiento de los Casos de Uso
Identificacin de Requerimientos No Funcionales : Actor Identificacin de Relaciones entre Casos de Uso
: Casos de Uso
: Requerimientos No Funcionales
63
Actividades de la Captura de Requerimientos

Identifica el Sistema Identificar Actores Identificar escenarios Identificar casos de uso y sus relaciones Refinar los casos de uso Identificar requerimientos no funcionales Identificar objetos participantes
64
Identificacin del Sistema

Desarrollo de un sistema no se hace tomando instantnea de una escena (dominio) La definicin de la frontera del sistema
Qu queda dentro y que fuera?
Cmo podemos identificar el propsito de un sistema? Proceso de requerimientos:

Identificacin de requerimientos: definicin del sistema en trminos comprensibles para el cliente Anlisis: especificacin tcnica del sistema en trminos comprensibles por el desarrollador
65
Identificacin de Actores
Los Actores: Representan a un agente que interacta con el sistema No son parte del sistema que se desarrolla Entran informacin al sistema Reciben informacin del sistema Entran y reciben informacin
66
Modelado de Requerimientos
67
Modelado de Requerimientos con Casos de Uso del Sistema
Elementos que participan en el Modelado de Casos de Uso.
Actor
Paquete
Caso de Uso
68
Actores del Sistema
Un actor del sistema (actor) representa un rol (humano, software o hardware) externo al sistema con el que se establece intercambio directo de informacin. Ejemplo:

Vendedor. Jefe de Almacn. Asistente de Produccin.

Nombre del Actor
69
Diagrama de Actores del Sistema
Usuario
Lector de cdigo de barra
Vendedor
Asistente
70
Paquetes
Un paquete es una coleccin de artefactos (casos de uso, actores, relaciones, diagramas y otros paquetes) que se utiliza para dividir un modelo en partes de menor tamao. Ejemplo:

Paquete Ventas. Paquete Seguridad.
Nombre del Paquete
71
Casos de uso del sistema
Un caso de uso del sistema identifica:

Es un proceso especfico del sistema con identidad propia. Define una secuencia de acciones que el sistema realiza para un actor en particular. Define la interaccin con el actor correspondiente. Produce un resultado observable y esperado para el actor correspondiente.
Nombre del caso de uso
72
Diagrama Casos de Uso del Sistema
Matricular estudiante Auxiliar de Matricula Auxiliar de Evaluacion
Colocar examen
Cancelar matricula
Consultar disponibilidad de cursos
Reservar cupo en un curso
Actualizar registro de profesores Rendir examen Aspirante
J de Escuela
Disear examen Abrir un curso Disear curso Profesor
73
Preparando el Modelo de Casos de Uso
Actividades: - Determinar los Actores para el Caso de Estudio Propuesto (ver SRS y Narrativa del Caso) - Elaborar el diagrama de casos de uso del sistema - Elaborar el documento Visin (ver plantilla y ejemplo)
74
Usualmente, qu no se ubica en los requerimientos?
Estructura del sistema, tecnologa de implementacin Metodologa de desarrollo Ambiente de desarrollo Lenguaje de implementacin Reuso Es deseable que ninguna de los aspectos anteriores sea restringido por el cliente: lgrelo!!!
75
Administracin de los Requerimientos
Especificacin

76
Validacin
Captura
Anlisis
Workflow de Requerimientos (RUP)

[ Sistema Nuevo ] [ Sistema Existente ] [ Nueva Entrada ]
Analizar el Problema [ Problema incorrecto ]
Comprender las Necesidades de los Usuarios
[ Problema correcto ]
Administrar Cambios en Requerimientos [ Redimensionar Sistema ]
Definir el Sistema
Administrar el Alcance del Sistema Refinar la Definicin del Sistema
77
Actividades de la Administracin de Requerimientos

Anlisis de Problemas Comprensin de las Necesidades de Usuarios Definicin de Sistemas Administracin de Alcances de Sistemas Refinamiento de la Definicin de Sistemas Administracin del Cambio de los Requerimientos
78
Actividad: Analizar el Problema
: Glosario : Cliente : Analista de Sistema
: Plan de Gestin de Requerimientos
: Interesado (Stakeholder) : Modelo de Objetos del Negocio
Capturar un Vocabulario Comn Desarrollar el Plan de Gestin de : Atributos de Requerimientos Requerimientos

Encontrar Actores y Casos de Uso
Desarrollar la Visin del Proyecto : Usuario Final : Modelo de Casos de Uso del Negocio : Modelo de Casos de Uso : Solicitudes de Interesados
: Visin
: Reglas del Negocio
: Atributos de Requerimientos
79
Actividad: Comprender Necesidades de los Stakeholders
: Reglas del Negocio : Analista de Sistema
: Plan de Gestin de Requerimientos : Guias para el Modelamiento de Casos de Uso
: Glosario Desarrollar la Visin
: Cliente Capturar Vocabulario Comn : Especificaciones Suplementarias : Interesado (Stakeholder) Identificar Solicitudes de los Stakeholders Administrar Dependencias
: Atributos de Requerimientos [Refinada]
Encontrar Actores y Casos de Usos
: Visin [Refinada]
: Solicitudes de Interesados : Solicitud de Cambio : Visin : Atributos de Requerimientos : Modelo de Casos de Uso
80
Actividad: Definir el Sistema

: Visin : Reglas del Negocio : Solicitudes de Interesados : Plan de Gestin de Requerimientos
: Visin [refinada] Desarrolar la Visin
: Especificaciones Suplementarias Administrar Dependencias
: Atributos de Requerimientos
: Glosario : Analista de Sistema [refinada] Capturar Vocabulario Comn Encontrar Casos de Uso y Actores : Glosario : Modelo de Casos de Uso : Guias para el Modelamiento de Casos de Uso : Modelo de Casos de Uso del Negocio : Modelo de Objetos del Negocio : Caso de Uso : Atributos de Requerimientos
81
Actividades: Administrar el Alcance del Sistema

: Modelo de Casos de Uso : Especificaciones Suplementarias Priorizar Casos de Uso : Atributos de Requerimientos : Visin
: Caso de Uso
: Documento de Arquitectura del Software [Vista Caso de Uso]
: Atributos de Requerimientos Desarrollar la Visin : Arquitecto de Software Administrar Dependencias [Refinado]
: Solicitudes de Interesados
Requerimientos
: de Cambio : Solicitud Visin [Refinado]
: Plan de Gestin de
82
Actividad: Refinar la definicin del sistema
: Glosario : Atributos de Requerimientos
: Guias para el Modelamiento de Casos de Uso
: Caso de Uso [descrito] : Especificaciones Suplementarias
: Solicitudes de Interesados
Detallar Caso de Uso
: Atributos de Requerimientos [refinado]
[detalladas]
Detallar los Requerimientos del Software : Visin : Especificador de Requerimientos : Especificaciones Suplementarias : Especificacin de los Requerimientos del Software Modelar la UI Prototipar la Interfaz con el Usuario : Caso de Uso
: Prototipo de la Interfaz Usuario
: Guas para el Diseo de la GUI : Storyboard del Caso de Uso
83
Administrar el Cambio en los Requerimientos

: Plan de Gestin de : Guias para el Modelamiento de Requerimientos Casos de Uso : Analista de Sistema Administrar Dependencias Estructurar el Modelo de Casos de Uso : Cliente : Modelo de Prueba : Lista de Riesgos
: Modelo de Diseo
: Solicitud de Cambio
: Especificaciones Suplementarias
: Caso de Uso : Modelo de Casos de Uso
: Modelo de Casos de Uso : Visin [refinado]
: Usuario Final Revisar los Requerimientos
: Interesado (Stakeholder)
: Plan de Iteracin
: Prototipo de la Interfaz Usuario
: Glosario
84
Especificacin de los Requerimientos
Especificacin

85
Validacin
Captura
Anlisis
Clasificacin de los Requerimientos
Tradicionalmente son agrupados en cinco (5) grandes categoras:

Funcionalidad Uso Confiabilidad Desempeo Soporte
(Funcionality) (Usability) (Reliability (Performance) (Supportability)
86
Tipos de requerimientos: en la prctica
Requerimientos Funcionales: describen las interacciones entre el sistema y su entorno independiente de la implementacin Requerimientos No Funcionales: aspecto visible al usuario pero no relacionado directamente al comportamiento funcional
El tiempo de respuesta debe ser menor a 1 segundo
Restricciones (Pseudo requerimientos): impuestas por el cliente o el entorno en el cul el sistema debe operar
El lenguaje de implementacin VB .NET
87
Requerimientos Funcionales
Especifican las acciones que el sistema debe realizar. Son definidos en UML con los Casos de Uso. Especifican el comportamiento esperado del sistema.
88
Productos de la Obtencin y anlisis de los requerimientos
Obtencin de Requerimientos Especificacin del Sistema : Modelo del Sistema
Modelo de Anlisis : Modelo del Sistema
Anlisis de los Requerimientos
89
Priorizacin de requisitos
Criterios para priorizar requisitos: Riesgos de los requisitos.
Comprende tanto la complejidad tcnica como otros factores, como incertidumbre del esfuerzo, especificacin pobre o facilidad de uso. Los riesgos de los requisitos es diferente a los riesgos del proyecto.
Se refiere a las funciones principales o de alto valor para el negocio.
Naturaleza crtica.
Significativo para la Arquitectura. Desarrollo de habilidades.

90
Ejemplo de un cuadro para priorizar requisitos:

Criterio
SA: Significativo para la Arquitectura R: Riesgo tecnolgico, complejo, nuevo, etc. NC: Naturaleza critica, de valor para el negocio.
Peso
2 3 1
Rango
0-3 0-3 0-3
Requisito
Procesar Venta Registrar Gestionar Devoluciones
Tipo
Caso de uso Caracterstica Caso de uso
SA
3 3 1
R
2 0 0
NC
3 1 0
Puntaje
15 7 2
91
Niveles de abstraccin de requisitos
92
Preparando el Modelo de Casos de Uso
Actividades: - Haga un anlisis del SRS del Caso de estudio y, de ser necesario, proponga algunos cambios.
93
III. Disciplina de Anlisis y Diseo del RUP

Conceptualizacin
Elaboracin
ltimo release?
Construccin
Transicin
Fuente: Rational Unified Process 94
Entendiendo el concepto de Versin

Es una imagen capturada del estado (contenido y relaciones) de un elemento u objeto, que establece un punto de referencia durante el ciclo de vida de dicho elemento
diferencias
95
Entendiendo el concepto de Lnea de Base

Especificacin o producto que ha sido formalmente revisada y aprobada; que sirve como base para un posterior desarrollo, y que puede ser cambiado solo a travs de un procedimiento formal de control de cambios
IEEE Std 610.12-1990
96
Entendiendo el concepto de Configuracin

caractersticas fsicas y/o funcionales de elementos hardware, software y firmware (o una combinacin de ellos) establecidas en las especificaciones tcnicas y alcanzadas en el producto
IEEE/CS: SWEBOK Version 2004, p.p. 7-1
97
Software Configuration Item (SCI)

es una agregacin de software, designado para gestin de la configuracin y tratado como una entidad simple en el proceso de SCM (Software Configuration Management)
IEEE Std 610.12-1990
pueden incluir planes, documentacin de diseo y especificaciones, materiales de pruebas, cdigo fuente y ejecutable de programas, herramientas software, datos y diccionarios de datos, documentacin para mantenimiento, operacin y uso del software IEEE/CS: SWEBOK p.p. 7-6
98
Qu es un release?
99
Calidad de la construccin
Depuracin
GA (release) Revisiones Tcnicas Canditado a Release

Beta Testing (Caja Negra)
Beta
Alfa Testing (Caja Blanca)
Alfa
Pre-Alfa
Actividades de Aseguramiento de Calidad
Estrategas de Diseo
Abstraccin
Separacin
Estructuras de Software
Metas de la Ing. de Software

Reusabilidad
Modelar propiedades esenciales
Objetos y Clases
Tratar el QU y el CMO independientemente
Composicin
Construir estructuras complejas a partir de estructuras simples
Herencias y Plantillas
Extensibilidad
Generalizacin
Identificacin de elementos y caractersticas comunes
Patrones de Diseo
Flexibilidad
100
Roles y sus responsabilidades
Arquitecto
Arquitecto de Software
Construir pruebas de conceptos arquitectnicos
Identificar Anlisis arquitectnico mecanismos de diseo
Identificar elementos de diseo
Describir la distribucin
Evaluar viabilidad de la prueba de concepto de la arquitectura
Describir la Incorporar elementos arquitectura para Diseo de Clases de diseo existentes tiempo de ejecucin
Diseador
Diseador Anlisis de Caso de Uso Diseo de Caso de Uso Diseo de Subsistemas Diseo de Elementos de prueba
101
Ing. Alfredo Csar Larios Franco, Dr.
Ingeniera de Sw
Responsabilidades del Arquitecto de Software
El arquitecto de software lidera y coordina las actividades y artefactos tcnicos.
Arquitecto
Modelo de Anlisis
Modelo de Diseo
Modelo de Implementacin Modelo de Despliegue

102
Arquitectura de Referencia
Documento de Arquitectura del Software
Ingeniera de Sw
Responsabilidades del Diseador
El diseador debe conocer las tcnicas de modelado de caso de uso, requerimientos del sistema y diseo de software.
Diseador
Interpretacin del Caso de Uso
Paquete
103 Ing. Alfredo Csar Larios Franco, Dr.
Subsistemas/Clases
Ingeniera de Sw
Principios de Diseo
No deber usarse orejeras
Un buen diseador deber tener en cuenta enfoques alternativos, juzgando todos los que se basan en los requisitos del problema, los recursos disponibles para realizar el trabajo y los conceptos de diseo
abstraccin, refinamiento, modularidad, arquitectura, jerarqua de control, divisin estructural, estructura de datos, ocultamiento de informacin, entre otros)
Fuente: Ingeniera de Software (PRESSMAN, 2002)
104
Ingeniera de Sw
Principios de Diseo
El Diseo deber poder rastrearse hasta el modelo de anlisis
Se debe de contar con un medio que permita rastrear cmo se han satisfecho los requisitos por el modelo de anlisis, dado que un solo elemento de diseo puede hacer seguimiento de los mltiples requisitos.
105
Ingeniera de Sw
Principios de Diseo
El Diseo no deber inventar nada que ya est inventado
Los sistemas se construyen utilizando un conjunto de patrones de diseo, muchos de los cuales ya estn inventados. Elegir dichos patrones como una alternativa a reinventar la rueda. Siempre hay poco tiempo y recursos limitados Invertir tiempos en nuevas ideas y conceptos y en la integracin de patrones en un marco de operacin (framework)
106
Ingeniera de Sw
Principios de Diseo
Deber minimizar la distancia intelectual entre el software y el problema como si de la misma vida real se tratara.
Emplear conceptos cercanos a la realidad conocida (OO en lugar de Estructurado) La estructura del software debera imitar en la medida de los posible la estructura del dominio del problema que se resuelve.
107
Ingeniera de Sw
Principios de Diseo
El diseo deber presentar unidad e integracin.

Uniforme, si parece que fue una nica persona quien lo cre. Definir reglas y estilos para el equipo antes de empezar. Se integra si tiene cuidado a la hora de definir interfaces entre los componentes del diseo
108
Ingeniera de Sw
Principios de Diseo
El diseo deber estructurarse para admitir cambios.
La nica constante en un proyecto de Ingeniera de Software en el cambio. Aplicar los conceptos de diseo indicados en el primer principio de manera cuidadosa.
109
Ingeniera de Sw
Principios de Diseo
El diseo deber estructurarse para degradarse poco a poco, incluso cuando se enfrenta a datos o sucesos de operacin aberrantes.

Disear para adaptarse a condiciones inusuales. Si debe terminar de funcionar, que lo haga de manera suave y elegante. No explotar como una bomba
110
Ingeniera de Sw
Principios de Diseo
El diseo no es escribir cdigo y escribir cdigo no es disear.

El nivel de abstraccin del modelo de diseo siempre es mayor que el cdigo fuente. Las nicas decisiones de diseo realizadas al nivel de codificacin se enfrentan con pequeos datos de implementacin que posibilitan codificar el diseo procedimental.
111
Ingeniera de Sw
Principios de Diseo
El diseo deber evaluarse en funcin de la calidad mientras se va creando, no despus de terminarlo.
Para ayudar al diseador en la evaluacin de la calidad se dispone de conceptos de diseo (vistos en principio 1).
112
Ingeniera de Sw
Principios de Diseo
El diseo deber revisarse para minimizar los errores conceptuales (semnticos).
Existe la tendencia de centrarse en minucias o detalles, cuando se revisa el diseo, perdiendo la perspectiva del bosque por culpa de los rboles. Asegurar haber afrontado los elementos conceptuales principales, antes de preocuparse por la sintaxis del modelo de diseo.
113
Ingeniera de Sw
Qu es un Patrn de Diseo?
Un patrn de diseo es una solucin a un problema de diseo comn:

Describe un problema de diseo comn, Describe la solucin al problema, Discute los resultados y conflicto de aplicar el patrn
Los patrones de diseo provee la capacidad para reusar diseos exitosos:

Template Parameters
Pattern Name Colaboracin parametrizada

114
Aspecto estructural
Aspecto del comportamiento

Ingeniera de Sw
Objeto de Acceso a Datos
Permite abstraer y encapsular los accesos a las fuentes de datos Administra la conexin con la fuente de datos para obtener y administrar los datos
DataAccessObject
DataSource
115
Ingeniera de Sw
Diseo de Caso de Uso: Flujo Bsico

: JFrameNuevoCurso : GestorAreasAcademicas : GestorCursos // formWindowOpened devolverAreasAcademicas( ) DAOAreas( ) : DAOAreas
seleccionarTodasAreas( )
Area(int, String) // jbtnGuardarActionPerformed registrarNuevoCurso(String, String, String, String, int)
: Area
Curso( )
: Curso
buscarArea(int)
DAOCursos( )
: DAOCursos
guardar(Curso)
116
Ingeniera de Sw
Diseo del Mecanismo de Acceso a los Datos
117
Ingeniera de Sw
Diagrama de Componentes
<<Application>>
CatalogoCurs os.exe
<<DLL>>
<<DLL>>
<<DLL>>
sigeac.ln.busque dacatalogo.dll
sigeac.ee.cata logocursos.dll
sigeac.ln.gestionc atalogocursos.dll
<<DLL>>
sigeac.dao.cat alogocursos.dll
Microsoft.Applicati onBlocks.Data.dll DBCatalogoCursos
118
Ingeniera de Sw
Definir una arquitectura candidata
Analizar la Arquitectura
Diseador
Analizar de los Casos de Uso
119
Ingeniera de Sw
Anlisis Arquitectnico en Contexto

[Temprano en Elaboracin] [Durante inception (opcional)]
Definir arquitectura candidata
Desarrollar sntesis arquitectnica
Architect
Anlisis
Analizar comportamientos
(opcional)
Refinar la arquitectura
Diseo
Disear componentes
Disear la base de datos
120
Ingeniera de Sw
Visin General del Anlisis Arquitectnico
Supplementary Specification
Glossary
Software Architecture Doc
Reference Architecture
Vision Document
Anlisis Arquitectnico Project-Specific Guidelines
Design Model
Use-Case Model
121
Deployment Model
Ingeniera de Sw
Pasos del Anlisis Arquitectnico
Conceptos Claves Definir la Organizacin de Alto Nivel del modelo Identificar los mecanismos de anlisis Identificar las abstracciones claves Crear las interpretaciones de los casos de uso Puntos Importantes
122
Ingeniera de Sw
Qu es un Paquete (Package)?

Un paquete es un mecanismo de propsito general para organizar elementos en grupos. Es un elemento del modelo que puede contener otros elementos del modelo
Lgica de Negocio
Un paquete puede usarse para:

Organizar el modelo bajo desarrollo Como una unidad de gestin de configuracin

Ing. Alfredo Csar Larios Franco, Dr. Ingeniera de Sw
123
Relaciones entre Paquetes: dependencia
Los paquetes pueden relacionarse con otros usando la relacin de dependencia.

relacin de dependencia
Paquete Cliente
Paquete Proveedor
Implicaciones de las Dependencias:

Cambios a un paquete proveedor puede afectar al paquete cliente. El paquete cliente no puede ser reusado independientemente porque depende del paquete proveedor (fuerte acoplamiento)
124
Evitar dependencias circulares

A A
B A B C
La jerarqua debe ser a cclica
C A'
Las dependencias circulares hacen que sea imposible el re uso de un paquete sin contar con el otro.
125 Ing. Alfredo Csar Larios Franco, Dr. Ingeniera de Sw
Pasos del Anlisis Arquitectnico
Conceptos Claves Definir la Organizacin de alto nivel del modelo Identificar los mecanismos de anlisis Identificar abstracciones claves Crear interpretaciones de los casos de uso Puntos Importantes
126
Ingeniera de Sw
Enfoque Tpico de Capas

Funcionalidad Especfica
Distintos subsistemas de aplicacin que conforman una aplicacin contiene el valor agregado del software desarrollado por la organizacin.
Application
Business-Specific
Especfico del negocio contiene un nmero de subsistemas re usables especficos para el tipo de negocio (core del negocio).
Middleware
Middleware ofrece subsistemas para clases utilitarias y servicios independiente de la platafofrma para computacin de objetos distribuidos en entornos heterogeneos y otros: GUI Builder, Int2DBMS, PI OS Services, OLE Services, etc.
System software contiene el software para la infraestructura tales como sistemas operativos, interfaces para hardware especficos, driver para dispositivos, etc.
Funcionalidad General
127
System Software
Ingeniera de Sw
Consideraciones de las Capas
Nivel de Abstraccin
Grupo de elementos al mismo nivel de abstraccin
Separacin de Preocupaciones
Grupo similares juntos Separar cosas distintas Aplicacin vs Elementos del Modelo de Dominio
Bajo acoplamiento Concentrarse en encapsular cambios Interfaz del usuario, reglas de negocio, tendencia de datos que tienen un alto potencial de cambios.
Posibilidad de Cambio:

128
Elementos del Anlisis de Caso de Uso

Modelo de Caso de Uso
Modelo de Diseo
Caso de Uso
Interpretacin del caso de uso
Diagramas de Secuencia
Diagramas de comunicacin
Caso de Uso
129
Diagramas de Clase
Analizar Comportamiento
Diseador
Anlisis del Caso de Uso
Identificar Elementos de Diseo
Revisar el Diseo Revisor Tcnico
Diseador de la Interfaz Usuario
Disear la Interfaz con el Usuario
Prototipar la Interfaz con el Usuario
130
Ingeniera de Sw
Identificar elementos de diseo
Identificar eventos y seales Identificar clases (pasivas y activas) y subsistemas Identificar interfaces entre subsistemas Identificar protocolos de las capsulas
131
Ingeniera de Sw
Identificar Clases de Diseo
Las clases de anlisis se mapean a clases de diseo directamente si:
Es una clase simple Representa una abstraccin lgica simple

Dividirse en varias clases Convertirse en un paquete Convertirse en un subsistema Cualquier combinacin de las anteriores
Clases de anlisis ms complejas pueden
132
Ingeniera de Sw
Revisar el diseo
Revisar el modelo de diseo como un todo Revisar las interpretaciones de los casos de uso Revisar cada elemento de diseo Revisar las guas de diseo Preparar registro de revisiones y documento de defectos
133
Ingeniera de Sw
Manos a la obra ...

Siguiendo el caso de estudio, elaborar:
(1) Diagrama de secuencia. (2) Diagrama de clases del diseo (3) Diagrama de componentes (4) Documento Arquitectura del software - SAD
134
Ingeniera de Sw
Disear la Interfaz con el Usuario (GUI)
Describir las caractersticas de los usuarios Identificar los elementos primarios de la interfaz con el usuario Definir el mapa de navegacin Detallar el diseo de los elementos de la interfaz con el usuario
135
Ingeniera de Sw
Prototipar la Interfaz con el Usuario (GUI)

Disear el prototipo de la interfaz con el usuario Implementar el prototipo de la interfaz con el usuario Obtener la retroalimentacin sobre el prototipo de la interfaz con el usuario
136
Ingeniera de Sw
Manos a la obra ...

Diseo de la Interfaz Usuario:
(1) Prepare en Visual Studio .NET un proyecto bajo el nombre DisenoIntruccional como una aplicacin Windows (5 minutos) (2) Prepare un formulario para el caso de uso Registrar Nuevo Curso indicado en el caso de estudio propuesto
137
Ingeniera de Sw
Disear los Componentes
Disear Cpsula Diseo del Caso de Uso Disear las Clases Diseador de Cpsula
Diseador
Disear elementos para pruebas
Disear los Subsistemas
Revisar el Diseo Revisor Tcnico
Definir elementos para pruebas
Diseador de Pruebas
138
Ingeniera de Sw
Disear los Casos de Uso

Crear interpretaciones del caso de uso Describir interacciones entre objetos de diseo Simplificar diagramas de secuencias usando subsistemas Describir comportamiento relacionado a la persistencia Refinar la descripcin del flujo de eventos Unificar clases de diseo y subsistemas
Disear las Clases

Crear clases de diseo iniciales Nombre Identificar clases persistentes <<estereotipo> Definir visibilidades Definir operaciones y mtodos // atributos Definir estados Definir atributos // operaciones Definir dependencias Definir asociaciones Definir la estructura interna de la clase Definir generalizaciones Resolver colisiones (concurrencia) de los casos de uso Resolver requerimientos no funcionales Aplicar patrones a problemas comunes
Disear los Subsistemas

Distribuir el comportamiento del subsistema a los elementos contenidos Documentos los elementos del subsistema Describir las dependencias entre los subsistemas
Nombre del subsistema
141
Ingeniera de Sw
Muchas Gracias!!!
142

Ingeniería Del Software: Colegio de Ingenieros Del Perú

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ingeniería Del Software: Colegio de Ingenieros Del Perú

Hochgeladen von

Copyright:

Verfügbare Formate

Colegio de Ingenieros del Per

Consejo Departamental Ancash-Chimbote

Ingeniera del Software

Sntomas de Problemas del Software

Seguimiento de los sntomas a las causas

Use Component Architectures

Continuously Verify Quality Continuously Verify Quality

Ciclo de vida del software

Guide to the Software Engineering Body of Knowledge (SWEBOK) (Versin 0.95)

Software Engineering Management

Software Engineering Process

Software Engineering Tools and Methods

Software Methods (Heuristic,

Las Seis Buenas Prcticas

Modelo Iterativo incremental

Modelo Iterativo incremental

El Perfil de los Riesgos

Riesgos en modelo en cascada

Riesgos en modelo iterativo

Las Seis Buenas Prcticas

Ingeniera de Requerimientos dentro del SWEBOK

Ciclo de Vida NTP-ISO/IEC 12207

NTP ISO/IEC 12207 Procesos del Ciclo de Vida del Software

Requerimientos y Cambios: Dnde estamos?

Ingeniera de los Requerimientos

Gestin de los Requerimientos

Procesos de Ingeniera de Requerimientos

IEEE Std 830:

Definiendo: Administracin de Requerimientos

Las Seis Buenas Prcticas

Arquitecturas basadas en componentes resilentes

Propsito de Arquitectura Basada en Componentes

Es la base para el reuso de

Componentes Arquitectura Planeamiento Staffing Entregas Administrar complejidad Mantener integridad

Base para la gestin de proyecto

Marco General de la Ingeniera del Software: la arquitectura?

NTP ISO/IEC 12207 Procesos del Ciclo de Vida del Software

Arquitectura: Dnde estamos?

Las Seis Buenas Prcticas

La Importancia del Modelado

Bandar Seri Begawan

C ities and Towns

KUAL A LUM PUR

Hal mah era S ch o ut en Isl an d s

Los 4 Principios del Modelamiento

Principio 1: La eleccin del modelo es importante

1.1. La Eleccin del Modelo

Principio 2: El nivel de precisin puede variar

Cada modelo puede ser expresado en diferentes niveles de precisin.

El mejor tipo de modelo permite escoger el grado de detalle, dependiendo de:

Quin ve el modelo? Por qu necesita verlo?.

Vista del cliente

Vista del Diseador

2.1. Los niveles de precisin

Todo modelo puede ser expresado a diferentes niveles de precisin

Principio 3: Modelos conectados a la realidad

3.1. Modelos Ligados a la realidad

Principio 4: Un nico modelo no es suficiente

4.1. Un nico modelo no es suficiente

Por Qu Modelar Visualmente?

UML: Un lenguaje para todos

El Modelo Arquitectura 4+1 Vistas

Usuarios Finales Funcionalidad