Teoria _DS_1Parcial

Vista previa del material en texto

1 
 
CICLO DE VIDA DE SISTEMAS DE INFORMACIÓN 
INTRODUCCIÓN E INSERCIÓN DEL DS EN EL CVS 
DEFINICIONES 
Sistemas de Información: “Se entiende como el conjunto de tecnologías, 
procesos, aplicaciones de negocios y software disponibles para las personas 
dentro de una organización” 
Contiene: 
 Una Entrada 
 Una Salida 
 Un Proceso de transformación 
 
 
SISTEMAS DE PROCESAMIENTO DE DATOS 
BASICAMENTE SERIA: 
 
2 
 
SOFTWARE: “Es la suma total de los programas de ordenador, procedimientos, 
reglas, la documentación asociada y los datos que pertenecen a un sistema de 
cómputo" y "un producto de software es un producto diseñado para un usuario" 
(IEEE). 
 
DIFERENCIAS 
HARDWARE SOFTWARE 
Se fabrica Se desarrolla 
Se daña con el tiempo No se daña. Puede alterarse, con el 
tiempo mejora 
Se puede reemplazar Se mantiene para prolongar su 
reemplazo 
Se fabrica ensamblando componentes Se desarrolla siguiendo distintas 
metodologías 
 
 
EL DISEÑO DENTRO DEL CICLO DE VIDA DE UN SISTEMA DE 
INFORMACION 
 
 
 
3 
 
TAREAS EN LA ETAPA DE ANALISIS DEL CVS: 
 Definir los requerimientos para solucionar un problema. 
 Examinar las necesidades del usuario. 
 Definir las propiedades que debería poseer el sistema para cubrir esas 
necesidades. 
 Identificar las limitaciones del sistema y los requisitos de performance. 
 Definir precisamente las funciones a llevarse a cabo y no cómo trabajan. 
 Del análisis surgen las ESPECIFICACIONES FUNCIONALES DEL 
SISTEMA. 
 Etc… 
El Diseño es el núcleo técnico dela Ingeniería del SW. 
Durante su elaboración se desarrollan, revisan y documentan los refinamientos 
progresivos de la estructura de datos, arquitectura, interfaces y datos 
procedimentales de los componentes del SW. El Diseño da como resultado 
representaciones del SW para evaluar la calidad. 
 
TAREAS EN LA ETAPA DE DISENO DEL CVS: 
 Planificar cómo se construirá el sistema. 
 Determinar los procesos y datos que se necesitan. 
 Ensamblar dichos componentes para proporcionar la solución informática. 
 Desarrollo de algoritmos que describen lo que hace cada componente. 
 Etcetc … 
CONSIDERACIONES: no dejar en cuenta que 
 Detectar 1 error de diseño durante la codificación requiere el doble de 
tiempo corregirlo. Detectarlo durante la fase de prueba o producción, 10 
veces más. 
 Mayor cuidado al diseño  Sistemas más baratos y confiables 
 Su falta complica el desarrollo, que carece de plan de acción y dificulta 
asignar personal a las tareas. 
 No hay mecanismos de medición de la calidad de los trabajos de los 
desarrolladores, por lo que se carece de documentación y prueba. 
 Se da una oportunidad a los desarrolladores para planear lo que van a 
hacer y evaluar las bondades de su plan antes de codificarlo y probarlo. 
PROPÓSITO: Especificar cómo debe ser construido el SW para cumplir con las 
Especificaciones Funcionales. 
 
4 
 
ETAPAS DEL DISEÑO 
 Diseño Arquitectónico o del Sistema. 
 Diseño Detallado. 
DISEÑO ARQUITECTÓNICO O DEL SISTEMA 
 Diseño de Alto Nivel. 
 Define los procedimientos básicos y sus interrelaciones. 
 Define a grandes rasgos la representación de los datos. 
 Sigue la estructura del problema a resolver. 
DISEÑO DETALLADO 
 Crea algoritmos específicos. 
 Estructuras de Datos detalladas. 
 Define niveles del sistema. 
 Requiere niveles sucesivos de detalle y refinamiento. 
 Termina con algoritmos precisos y estructuras de datos que cubren todos 
los requerimientos. 
 
PRINCIPIOS Y CONCEPTOS 
Durante las 4 últimas décadas se han propuesto diferentes principios y conceptos 
fundamentales del diseño de SW. 
Los Principios sirven de guía al ingeniero del SW a medida que avanza el 
proceso de Diseño. 
Los Conceptos proporcionan los criterios básicos para la calidad del Diseño. 
 
MÉTODOS DEL DISEÑO 
Conceptos Generales. Importancia: 
 Es el camino para llegar a un fin. 
 Es un Proceso disciplinado para generar un conjunto de modelos que 
describe a un sistema de software en desarrollo, utilizando alguna notación 
bien definida. 
 Brindan disciplina para desarrollar sistemas de software complejos. 
 Facilitan comunicación y estándares en equipos de desarrollo. 
 Definen metas y objetivos para medir el progreso y gestionar el riesgo. 
 Surgieron de la complejidad creciente de los sistemas de software en los 
60’s y 70’s. 
5 
 
MODELO DEL DOMINIO O CONCEPTUAL 
 (UML Y PATRONES – CRAIG LARMAN) 
 
MODELO DEL DOMINIO O CONCEPTUAL 
Es una representación visual de las clases conceptuales u objetos del mundo real 
en un dominio de interés, como Libro y Biblioteca, empleado y empresa, etc. 
En el UP el MD, se utiliza para el Modelado del Negocio y, utilizando UML, se 
representa como un conjunto de Diagramas de Clases en los que no se define 
ninguna operación. 
Puede mostrarnos: 
1. Conceptos: o sea una idea, cosa u objeto. Es mejor exagerar y especificar un 
MC con muchos conceptos refinados que no especificarlo cabalmente. 
2. Asociaciones entre conceptos: es una relación entre dos conceptos que 
indica alguna conexión significativa e interesante entre ellos. 
3. Atributos de las clases conceptuales. 
Conceptos: 
 El MD muestra clases conceptuales o vocabulario del dominio, por lo que 
puede ser una cosa, idea u objeto. 
 Es mejor especificar en exceso un MD con muchos conceptos de grado fino 
que especificar por defecto. 
 A los documentos de Salidas del Sistema se los considerara cuando 
representen un documento de retorno para el sistema. 
Asociaciones entre conceptos: 
 Pueden existir varias asociaciones entre dos tipos (conceptos). 
 Se representa a través de una línea bidireccional entre los conceptos con el 
nombre de la asociación. 
 En el extremo puede haber una expresión de multiplicidad que indique la 
relación numérica entre las instancias de los conceptos. 
 Una flecha opcional de la dirección de la lectura indica la dirección en que 
debe leerse el nombre de la asociación, no denota la dirección de visibilidad 
o de navegación. 
Algunas categorías de alta prioridad que conviene incluir en un MD son: 
 A es una parte física o lógica B. 
 A está física o lógicamente contenido en B. 
6 
 
 A está registrado en B. 
La multiplicidad define cuántas instancias de un tipo A pueden asociarse a una 
instancia del tipo B en determinado momento. P.ej.: * (cero o más), 1..* (uno o 
más), 3,5,8 (exactamente eso), etc. 
Atributos de Conceptos: son valores lógicos de los datos de un objeto: 
 En el MD se incluyen sólo aquellos que indiquen la necesidad de recordar 
información. 
 Los tipos más simples de atributos son los que, en la práctica, suelen 
considerarse los tipos primitivos de datos. 
 En un MD es preferible que los atributos sean atributos simples, objetos de 
valor o valores puros de datos (p.ej: booleano, fecha, número, cadena o 
texto, hora, dirección, color, copo, cod. Del producto, etc.). 
 La regla en objetos es relacionar conceptos con una asociación y no con un 
atributo. La violación más frecuente de esta regla consiste en agregar un 
tipo de atributo de llave foránea, lo cual suele hacerse con los diseños de 
BD relacionales, a fin de asociar dos tipos. 
 
 
 
 
7 
 
GLOSARIO O DICCIONARIO MODELO 
Artefacto de UML que incluye y define todos los términos que requieran 
explicación para mejorar la comunicación y reducir el riesgo de malos entendidos. 
Se crea originalmente durante la fase de Planeación y después se perfecciona en 
cada ciclo de desarrollo al aparecer nuevos vocablos hasta el fin del proyecto. 
Se puede utilizar un formato de tres columnas para hacerlo, en donde se expresan 
el término a describir, la categoría (casos de uso, atributo, tipo, etc.) y la 
descripción o comentarios. 
 
DIAGRAMA DE LASECUENCIA DE UN SISTEMA 
UML Y PATRONES – CRAIG LARMAN 
 
DIAGRAMA DE LA SECUENCIA DE UN SISTEMA (DSS) 
Da una descripción gráfica delas interacciones del actor y de las operaciones a 
que da origen. 
Es una parte de lo que se conoce como Comportamiento del Sistema (describir 
lo que hace sin explicar de qué manera lo hace). 
Es una representación que muestra, en determinado escenario de un caso de uso, 
los eventos generados por actores externos, su orden y los eventos internos del 
sistema. 
El diagrama es temporal, secuencial hacia abajo y siguiendo el orden del caso de 
uso, que es el artefacto que debe estar previamente hecho. 
8 
 
 
 Evento de un sistema: hecho externo de entrada que un actor produce en un 
sistema y origina una operación de respuesta. 
 Operación de un sistema: es una acción que este ejecuta en respuesta a un 
evento del sistema. 
Se debe utilizar para el nombre de un evento un verbo imperativo (agregar, 
introducir, terminar, efectuar, etc.) 
Directriz para su construcción: 
1.- Trazar una línea que represente el sistema. 
2.- Identificar los actores que operan directamente con el. Si hay más de uno se 
hará una línea por cada uno de ellos. 
3.- Identificar los eventos generados por los actores dentro del curso normal de los 
eventos. 
4.- A la izquierda del diagrama se puede incluir o no el texto del caso de uso. 
 
 
 
 
 
 
 
9 
 
CONTRATOS 
UML Y PATRONES – CRAIG LARMAN 
 
CONTRATOS 
Para su preparación debe estar desarrollado previamente el Modelo Conceptual, 
los DSS y la identificación de sus operaciones. 
Este artefacto también tiene relación con el Comportamiento de un Sistema, ya 
que permite ver cómo cambia el estado de un sistema cuando se llama una 
operación suya. 
El Contrato es un documento que describe lo que una operación se propone 
lograr, que se redacta en un estilo declarativo, enfatizando lo que sucederá y no 
cómo se conseguirá. 
Se deben redactar contratos para cada operación del sistema con el fin de 
describir su comportamiento. 
Secciones de un Contrato: 
 Nombre 
 Responsabilidades 
 Tipo 
 Ref. cruzadas 
 Notas 
 Excepciones 
 Precondiciones 
 Poscondiciones 
 Precondiciones 
Son las suposiciones acerca del estado del sistema antes de ejecutar la 
operación. Se deben describir las cosas que son importantes probar en el software 
en algún momento de la ejecución de la operación y las cosas que no serán 
sometidas a prueba, pero de las cuales depende el éxito de la operación 
 Poscondiciones 
El estado del sistema después de la operación. O sea cómo cambió el sistema 
tras una operación. Estas poscondiciones se relacionan con el MD en que a la 
pregunta de qué instancias o asociaciones es posible crear o formar, la respuesta 
nos la dará el MD. 
 
10 
 
Categorías de Poscondiciones 
1.- Creación y eliminación de instancias. 
2.- Modificación de los atributos. 
3.- Asociaciones formadas y canceladas. 
Categorías de Poscondiciones 
Para expresar las poscondiciones se debe hacerlo en forma pasiva declarativa, en 
pretérito (Fue creada..., Se asoció..., Se estableció..., etc.) para destacar la 
declaración de un cambio de estado. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
11 
 
 
 
 
UNIDAD 1 
 
CICLO DE VIDA DE 
DESARROLLO DE SISTEMAS 
DE INFORMACIÓN 
Ian Sommerville 
 
 
 
 
 
 
12 
 
CVS – Modelos o Metodologías 
CICLO DE VIDA DE DESARROLLO DE SISTEMAS 
 
ISO 12207 
 
“Un marco de referencia que contiene los procesos, las actividades y las tareas 
involucradas en el desarrollo, la explotación y el mantenimiento de un producto de 
software, abarcando la vida del sistema desde la definición de los requisitos hasta 
la finalización de su uso". 
 
OBJETIVOS DEL CVDS 
 
Definir las actividades a llevarse a cabo en el desarrollo. 
Lograr congruencia entre los proyectos de desarrollo al interior y exterior de la 
organización. 
Proporcionar puntos de control y revisión administrativos. 
Organizar las actividades de manera lógica. 
Controlar la calidad del sistema. 
 
PROCESO DEL SOFTWARE (SW) 
 
“CONJUNTO DE ACTIVIDADES QUE CONDUCEN A LA CREACION DE UN 
PRODUCTO SOFTWARE”. 
 
“Las actividades pueden comenzar de cero o ampliar y modificar los sistemas 
existentes y configurando e integrando SW comercial o componentes del sistema”. 
 
“Un Modelo del Proceso de SW es una representación abstracta de un proceso del 
SW”. 
Ian Sommerville 
 
MODELOS DE PROCESO DEL SOFTWARE 
 
ALGUNAS ACTIVIDADES COMUNES 
 
ESPECIFICACION DEL SOFTWARE: Definir funcionalidad del SW y 
restricciones en su operación. 
DISEÑO E IMPLEMENTACION DEL SW: Producir SW cumpliendo lo anterior. 
VALIDACION DEL SW: Asegurar que el SW hace lo que el cliente desea. 
EVOLUCION DEL SW: El SW debe crecer para cubrir nuevas necesidades. 
13 
 
MODELOS DE PROCESOS O DE DESARROLLO DE SOFTWARE 
 
Modelos de Procesos Genéricos 
 
 Desarrollo Convencional o en Cascada. 
 Desarrollo Evolutivo. 
 Ingeniería del SW basada en Componentes. 
 
Iteración de Procesos 
 
 Entrega Incremental. 
 Desarrollo en Espiral. 
 
Modelo de Proceso Híbrido 
 
 RUP (Rational Unified Proccess). 
 
 
Desarrollo Convencional, Tradicional o en Cascada 
 
“Considera las actividades fundamentales del proceso y las representa como fases 
separadas (especificación de requerimientos, diseño, implementación, pruebas, 
etc.)”. 
 
Se utiliza cuando los requerimientos se comprenden bien y es improbable un 
cambio radical. 
 
Este enfoque se sigue utilizando para el desarrollo de SW, particularmente cuando 
éste es parte de proyectos grandes de ingeniería de sistemas. 
 
 
14 
 
 
 
15 
 
DESARROLLO EN CASCADA 
 
VENTAJAS Y USOS 
 
 La documentación se produce en cada fase. 
 Se usa cuando se conocen bien los requerimientos. 
 Se usa cuando los cambios en el futuro son inexistentes o improbables. 
 Cuando el Proceso de SW es parte de Proyectos de Ingeniería de 
Sistemas. 
 
DESVENTAJAS 
 
 Secuencialidad. 
 No siempre se cuentan con todas las especificaciones desde el principio. 
 Cambios de parecer de los usuarios. 
 Los resultados no se ven hasta que esté avanzado el proyecto. 
 
Desarrollo Evolutivo 
 
“Se basa en la idea de desarrollar una implementación inicial, exponiéndola a los 
comentarios del usuario y refinándola a través de las diferentes versiones hasta 
que se desarrolla un sistema adecuado”. 
 
Las actividades de especificación, desarrollo y validación se entrelazan en vez de 
separarse, con una rápida retroalimentación entre éstas. 
 
Tipos: 
 
Desarrollo Exploratorio: 
 
 Objetivo: trabajar con el cliente, explorar sus necesidades y entregar un 
sistema final. 
 
Prototipos Desechables: 
 
 Objetivo: comprender los requerimientos del cliente y desarrollar una 
definición mejorada de los mismos (El prototipo se centra en experimentar 
con los requerimientos del cliente que no se comprenden claramente). 
 
 
 
 
16 
 
VENTAJAS Y USOS 
 
 Satisface las necesidades inmediatas de los usuarios. 
 La especificación se puede desarrollar en forma creciente. 
 Se usa en sistemas pequeños y de tamaño medio. 
 Se usa en forma conjunta con Prototipos y el desarrollo rápido de 
aplicaciones y en RUP. 
 
DESVENTAJAS 
 
 El Proceso no es visible (la documentación de nuevas versiones a veces no 
es rentable). 
 Los cambios continuos tienden a corromper la estructura del SW. 
 Los cambios a introducir son cada vez más difíciles y costosos. 
 
 
 
17 
 
- Cambia constantemente en el tiempo 
- Las iteraciones no tendrían fin 
 
Ingeniería del SW Basada en Componentes (CBSE) 
 
“Se basa en la reutilización informal de Componentes de SW reutilizables y de 
algunos marcos de trabajo de integración para estos.” 
 
Algunas veces estos componentes son sistemas por sí mismos que se pueden 
utilizar para una funcionalidad específica. 
 
Etapas Intermedias: 
 
Análisis de Componentes (buscar componentes de concordancia total o 
parcial). 
 
Modificación de requerimientos(requerimientos vs. Componentes)  buscar 
alternativas. 
 
Diseño del sistema con reutilización: diseño de un marco de trabajo para el 
sistema (disponibilidad vs nuevo diseño). 
 
Desarrollo e Integración: Desarrollo de nuevo SW no disponible como 
componente e integración del mismo. 
 
VENTAJAS Y USOS 
 
 Reduce la cantidad de SW a desarrollar. 
 Disminuye los costos. 
 Minimiza los riesgos. 
 Permite una entrega rápida del SW. 
 Se utiliza en la integración de servicios web de una serie de proveedores. 
 
DESVENTAJAS 
 
 El Proceso a veces no cumple acabadamente con los requerimientos del 
usuario. 
 Se pierde parte del control sobre la evolución del sistema. 
 
 
 
 
18 
 
ITERACION DE PROCESOS 
 
El proceso de SW no es un proceso único; más bien, las actividades del proceso 
se repiten regularmente conforme el sistema se rehace en respuesta a peticiones 
de cambios. 
 
La esencia de los procesos iterativos es que la especificación se desarrolla junto 
con el SW y que no existe una especificación completa del sistema hasta que el 
incremento final se especifica. 
 
Tipos 
 
Entrega Incremental: La especificación, el diseño y la implementación del SW 
se dividen en una serie de incrementos, los cuales se desarrollan por turnos. 
 
Desarrollo en Espiral: el desarrollo gira en espiral hacia fuera, empezando con 
un esbozo inicial y terminando con el desarrollo final del mismo. 
 
FASES DE LA ENTREGA INCREMENTAL 
 
 
 
VENTAJAS DE LA ENTREGA INCREMENTAL 
 
 Los clientes no tienen que esperar hasta que el sistema completo se 
entregue para sacar provecho de él. 
 Los clientes pueden utilizar los incrementos iniciales como prototipos y 
obtener experiencia sobre los requerimientos de los incrementos 
posteriores del sistema. 
19 
 
 Existe un bajo riesgo de un fallo total del proyecto. 
 Puesto que los servicios de más alta prioridad se entregan primero, y los 
incrementos posteriores se integran a ellos, es inevitable que los servicios 
más importantes del sistema sean a los que se le hagan más pruebas. 
 
FASES DEL DESARROLLO EN ESPIRAL 
 
Definición de Objetivos 
 
 Identificar las restricciones del proceso y del producto. 
 Trazar un plan detallado de gestión. 
 Identificar los riesgos. 
 Planear estrategias alternativas. 
 
Evaluación y reducción de riesgos 
 
 Análisis detallado de cada riesgo. 
 Pasos para reducir los riesgos identificados. 
 
Desarrollo y Validación: 
 
 Elección de un modelo para el desarrollo del sistema (por ejemplo: riesgos 
en la interfaz  construcción de prototipos evolutivos. 
 
Planificación: 
 
 Revisión del proyecto y se decide continuar o no con un ciclo posterior de la 
espiral. 
 
 
- Cada ciclo en la espiral representa una fase del proceso SW. 
- Es una mejora y generalización al prototipado. 
20 
 
- Se considera como una sucesión de prototipos. 
- El cliente es la fuente natural de incertidumbres. 
 
DESARROLLO EN ESPIRAL 
 
La diferencia principal entre el modelo en espiral y los otros modelos del Proceso 
de SW es la consideración explícita del riesgo en el modelo en espiral. El 
riesgo significa sencillamente algo que puede ir mal y que origine problemas en el 
proyecto. Por lo tanto, disminuirlos es una actividad muy importante en la gestión 
del proyecto. 
 
RUP 
 
Proceso Unificado de Rational (RUP) 
 
Es un híbrido que reúne elementos de todos los modelos de proceso genéricos 
vistos, iteraciones de apoyo e ilustra buenas prácticas en la especificación y el 
diseño, cuyas fases están más relacionadas con asuntos de negocio más que 
técnicos (o actividades del proceso). 
Es un ejemplo de un modelo de proceso moderno que proviene del trabajo en el 
UML y el asociado Proceso Unificado (PU – Rumbaugh). 
 
El RUP se describe normalmente desde 3 perspectivas: 
 
Una perspectiva dinámica que muestra las fases del modelo sobre el tiempo. 
Una perspectiva estática que muestra las actividades del proceso que se 
representan. 
Una perspectiva práctica que sugiere buenas prácticas a utilizar durante el 
proceso. 
 
 
 
21 
 
Cada fase se representa de un modo iterativo con los resultados desarrollados 
incrementalmente y todo el conjunto también. 
 
FASES 
 
Inicio: se establece un caso de negocio para el sistema, identificándose las 
entidades externas (personas y sistemas) que interactúan y definir estas 
interacciones. 
 
Elaboración: se desarrolla una comprensión del dominio del problema y un 
marco de trabajo arquitectónico, desarrollándose el plan del proyecto e identificar 
los riesgos clave del proyecto. 
 
Construcción: Comprende obtener el diseño del sistema, la programación y las 
pruebas. Se desarrollan e integran las partes del sistema. 
 
Transicción: Es implementar el sistema desde el ámbito de desarrollo a la 
comunidad del usuario y hacerlo trabajar en un entorno real. 
 
La vista estática se centra en las actividades que tienen lugar durante el proceso 
de desarrollo o flujos de trabajo. 
 
Flujos de trabajo estáticos en el RUP 
 
 
Flujo de Trabajo 
 
Descripción 
 
Modelado del Negocio 
 
Los procesos se utilizan usando Casos de Uso del 
Negocio. 
 
 
 
Requerimientos 
 
Definir actores que interactúan con el sistema. 
Hacer Casos de Uso para modelar los requerimientos 
del sistema. 
 
 
 
Análisis y Diseño 
 
Se crea y documenta un modelo del diseño utilizando 
modelos arquitectónicos, modelos de componentes, 
modelos de objetos y modelos de secuencia. 
 
 
Implementación 
 
 
Se implementan y estructuran en subsistemas los 
componentes del sistema. 
 
22 
 
 
Pruebas 
 
Se llevan a cabo en forma conjunta con la 
Implementación. 
 
Despliegue 
 
Se crea una versión del pro- ducto y se instala en el 
lugar de trabajo de los usuarios. 
 
Configuración y 
cambios de Gestión 
 
Gestiona los cambios del sistema. 
 
 
Gestión del Proyecto 
 
Gestiona el desarrollo del sistema. 
 
 
Entorno 
 
Se hace herramientas de SW apropiadas para los 
equipos de desarrollo de SW. 
 
Buenas Prácticas recomendadas 
 
Desarrolle el SW en forma iterativa: planificar incrementos del SW basado en 
las prioridades del usuario. 
Gestione los requerimientos: Documentar los mismos, conocer los cambios y 
analizar su consideración o no. 
Utilice arquitectura basadas en componentes: Estructurar la arquitectura de 
esa forma. 
Modele el SW visualmente: Utilizar modelos gráficos UML para presentar vistas 
estáticas y dinámicas del SW. 
Verifique la calidad del SW: cumplir con los estándares. 
Controle los cambios del SW: Gestionar estos a través de un sistema de 
gestión de cambios y procedimientos y herramientas de gestión de 
configuraciones. 
 
Proceso Unificado de Rational (RUP) 
 
No es un proceso para cualquier tipo de desarrollo, solo representa una nueva 
generación de procesos genéricos, con las ventajas de las fases y flujos de 
trabajo. 
 
 
 
 
23 
 
MODELOS DE DESARROLLO RAPIDO DE SOFTWARE (RAD) 
 
MODELOS DE DESARROLLO RAPIDO DE SOFTWARE 
 
Los procesos de desarrollo rápido de software están diseñados para producir 
software útil de forma rápida. 
 
Son procesos iterativos en los que se entrelazan la especificación, el diseño, el 
desarrollo y las pruebas. 
 
El SW no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, 
donde en cada incremento se incluyen nuevas funcionalidades al sistema. 
 
Ian Sommerville 
 
Características: 
 
 Los procesos de especificación, diseño e implementación son concurrentes 
 El sistema se desarrolla en una serie de incrementos 
 Se utiliza un sistema de desarrollo interactivo para las interfaces para 
crearlas rápidamente. 
 
Ventajas del enfoque Incremental 
 
 Entrega acelerada de los servicios del cliente (implementar prioridades 
 aprovechamiento del sistema  análisis de resultados y cambios 
posteriores) 
 Compromisodel cliente con el sistema (compromiso del usuario del 
sistema  retroalimentación de requerimientos  mejora continua) 
 
 
24 
 
 
 
Problemas del Desarrollo Iterativo e Incremental: 
 
Problemas de Administración: (velocidad de desarrollo  mayor 
documentación  mayor gasto). 
Problemas Contractuales: (requerimientos inciertos  Costos inciertos). 
Problemas de validación: (documentación escasa  difícil validación). 
Problemas de Mantenimiento: Los cambios continuos corrompen la estructura 
de cualquier sistema software. 
 
Desarrollo Incremental vs. Prototipado Desechable 
 
Objetivo del Desarrollo Incremental: Entregar a los usuarios finales un sistema 
funcional (Primero lo prioritario y lo que mejor se comprenda). 
Objetivo del prototipado desechable: validar u obtener los requerimientos del 
sistema (primero los requerimientos inciertos). 
 
 
 
 
 
 
 
 
 
 
25 
 
Métodos Agiles 
 
Surgen en contraposición a los denominados enfoques “pesados” de desarrollo 
basados en la planificación y se caracterizan que permiten centrarse en el 
software mismo en vez de su diseño y documentación. 
 
Dependen de un enfoque iterativo para la especificación, desarrollo y entrega del 
SW, y principalmente fueron diseñados para apoyar el desarrollo de aplicaciones 
de negocio donde los requerimientos del sistema normalmente cambian 
rápidamente durante el proceso de desarrollo. 
Ian Sommerville 
 
Métodos Agiles 
 
Programación Extrema (Beck, 1999, 2000) 
Scrum (Schwaber y Beedle, 2001) 
Cristal (Cockburn, 2001) 
Desarrollo de SW Adaptable (Highsmith, 2000) 
DSDM (stapleton, 1997) 
Desarrollo dirigido por Características (Palmer y Felsing, 2002) 
Noción de Modelado Agil (Ambler y Jeffries, 2002) 
Instanciaciones ágiles del RUP (Larman, 2002) 
 
Principios de Métodos Agiles 
 
Participación del Cliente. 
Entrega Incremental. 
Personas, no procesos formales. 
Aceptar el cambio en el diseño del sistema. 
Mantener la simplicidad. 
 
Desarrollo Rápido de Aplicaciones 
 
Las Técnicas de desarrollo rápido de aplicaciones (RAD) evolucionaron de los 
llamados lenguajes de cuarta generación de los años 80 y se utilizan para 
desarrollar aplicaciones con un uso intensivo de datos. 
Usan un conjunto de herramientas que permiten crear datos, buscarlos, 
visualizarlos y presentarlos en informes. 
 
 
 
 
26 
 
Herramientas RAD 
 
Un lenguaje de programación de BD (estándar SQL): Estructura y 
manipulación. 
Un Generador de Interfases: creación de formularios de introducción y 
visualización de datos). 
Enlaces a aplicaciones de oficina: hojas de cálculo o procesador de textos. 
Generador de informes: definición y creación de reportes. 
 
 
Desarrollo Visual en RAD 
 
El Desarrollo Visual es un enfoque a RAD que utiliza la integración de 
componentes SW reutilizables de grado fino. 
Un enfoque alternativo basado en la reutilización reutiliza componentes que son 
sistemas de aplicaciones completos (COTS – Commercial Off-the-Shelf). 
 
Modelos de Desarrollo Rápido de Software 
 
 
 
En este ejemplo, cuando un usuario del sistema accede a un objeto de un tipo 
particular, se llama a la aplicación asociada para proporcionar la funcionalidad al 
usuario (p.ej: objetos tipo sonido se procesaran con el reproductor de audio). 
 
27 
 
Programación Extrema (XP) 
 
Es otro de los métodos agiles de desarrollo de SW, en donde: 
 
Todos los requerimientos se expresan como escenarios (historias de usuario). 
Los requerimientos se implementan directamente como una serie de tareas. 
Los programadores trabajan en pareja. 
Desarrollan pruebas para cada tarea. 
Todas las pruebas se deben ejecutar satisfactoriamente antes de integrar el 
Código. 
 
 
ANALISIS Y DISEÑO ORIENTADO A OBJETOS 
ROGER S. PRESSMAN 
 
 
AOO Y DOO 
 
 
ESTRUCTURADO vs AOO 
 
El AOO representa un cambio radical sobre la metodologías orientadas a 
procesos, pero sólo un cambio incremental respecto de las metodologías 
orientadas a datos, tales como la ingeniería de la información (Fichman y 
Kemerer). 
 
Algunos Métodos de AOO: 
 
GRADY BOOCH 
RUMBAUGH  OMT (Técnica de Modelado de objetos) 
JACOBSON  OOSE (Ingeniería del SW orientada de objetos) 
COAD Y YOURDON 
WIRFS-BROCK 
BOOCH, RUMBAUGH Y JACOBSON  UML (Lenguaje de Modelado 
Unificado). 
 
 
 
 
 
 
28 
 
UML 
 
Permite expresar un modelo de análisis utilizando una notación de modelado con 
unas reglas sintácticas, semánticas y prácticas. 
 
Reglas que lo definen: 
 
Sintaxis: nos dice cómo mostrar y combinar los símbolos (ídem al 
lenguaje natural). 
Semántica: nos dice lo que significa cada símbolo y cómo interpretarlo, solo o 
combinado con otros. 
Prácticas: definen el significado de los símbolos a través de los cuales se 
obtiene el modelo y se hace comprensible para otras personas (construcción de 
frases claras y comprensibles). 
 
VISTAS DE UML 
 
DEL USUARIO: Representa el sistema (producto) desde la perspectiva de los 
usuarios (actores)  Casos de Uso. 
 ESTRUCTURAL: Los datos y la funcionalidad se muestran desde dentro del 
sistema  Modelo del Dominio. 
DEL COMPORTAMIENTO: representa los aspectos dinámicos o 
comportamiento del sistema (interacciones o colaboraciones). 
DE IMPLEMENTACION: representa los aspectos estructurales y de 
comportamiento tal y como van a ser implementados. 
DEL ENTORNO: aspectos estructurales y de comportamiento en el que el 
sistema a implementar se representa. 
 
 
29 
 
 
 
 Modelo de Análisis Modelo de Diseño 
 
 
AOO Y DOO 
 
Diseño de Subsistemas: se obtiene considerando los requerimientos globales 
del cliente (casos de uso) y los sucesos y estados que son externamente 
observables (modelo de comportamiento). 
Diseño de clases y objetos: es trazado de la descripción de atributos, 
operaciones y colaboraciones del modelo CRC. 
Diseño de mensajes: es manejado por el modelo objeto-relación. 
Diseño de Responsabilidades: es derivado del uso de atributos, operaciones y 
colaboraciones descrito en el modelo CRC. 
 
Lo esencial durante el Diseño del paradigma OO es la creación de los Diagramas 
de Interacción, que representen el modo en que los objetos colaboran para 
satisfacer los requisitos; luego o en paralelo, se representarán los Diagramas de 
Clases del Diseño que resumen las clases SW e interfaces que se van a 
implementar en el SW (ambos forman parte del Modelo de Diseño del UP). 
Craig Larman 
 
 
30 
 
PROTOTIPOS 
 
Prototipado del SW 
 
Un Prototipo es una versión inicial de un sistema software que se utiliza para 
demostrar conceptos, probar opciones de diseño y, en general, informarse más del 
problema y sus posibles soluciones. 
Ian Sommerville 
 
Usos del Prototipado del SW 
 
1. En el proceso de ingeniería de requerimientos ayudando en la obtención y 
validación de los mismos; 
2. En el proceso de diseño del sistema explorando soluciones SW particulares y 
apoyando el diseño de las interfaces de usuario; 
3. En el proceso de pruebas ejecutando pruebas back-to-back con el sistema a 
entregar al cliente. 
 
Prototipado de la Interfaz de Usuario (UI) 
 
El Propósito del Prototipado en definitiva es permitir a los usuarios adquirir una 
experiencia directa con la interfaz. 
 
Para ello se puede adoptar un proceso en dos etapas: 
 
1.- Al principio del proceso dibujar prototipos en papel – maquetas de los diseños 
de pantalla- y mostrárselos a los usuarios finales. 
2.- Perfeccionar el diseño y desarrollar prototipos automatizados cada vez más 
sofisticados y se ponen a disposición de los usuarios para realizar simulación y 
pruebas de actividades. 
 
Enfoques para el Prototipado de UI 
 
1.- Enfoque dirigido por secuencia de comandos (Macromedia Director): Se 
crean pantallas con elementos visuales (botones y menúes), asociandouna 
secuencia de comandos con estos elementos. No hay aplicación lógica alguna en 
este enfoque; 
2.- Lenguaje de programación visuales (ej: Visual Basic): Incorporan un potente 
entorno de desarrollo, con una variedad de objetos reutilizables y un sistema de 
desarrollo de UI en forma rápida; 
3.- Basado en Internet (navegadores Web y lenguajes como Java): ofrecen 
una UI hecha, agregándole funcionalidad asociando segmentos de programas 
31 
 
Java (applets) con la información a visualizar. Estos se ejecutan automáticamente 
cuando se carga la página en el navegador. Sirve como RAD, pero existen 
restricciones del navegador y del modelo de seguridad de Java. 
 
Beneficios del Prototipado del SW 
 
Mejora en la usabilidad del sistema; 
Una mejor concordancia entre el sistema y las necesidades del usuario; 
Mejora en la calidad del diseño; 
Mejora en el mantenimiento; 
Reducción en el esfuerzo de desarrollo. 
 
Desventajas de usar el Prototipo como Sistema final 
 
Imposibilidad de ajustar el prototipo a los requerimientos no funcionales 
(rendimiento, protección, robustez y fiabilidad); 
El cambio rápido implica documentación insuficiente, no conveniente para el 
mantenimiento a largo plazo; 
Los cambios realizados durante el desarrollo degradan la estructura del sistema; 
Los estándares de calidad organizacionales se relajan para el desarrollo del 
prototipo. 
 
32 
 
Tipos de Prototipos 
 
Prototipado de interfaz de usuario: modelos de pantallas. 
Prototipado funcional (operacional): implementa algunas funciones, y a 
medida que se comprueba que son las apropiadas, se corrigen, refinan y se 
añaden cosas. 
Modelos de rendimiento: evalúan el rendimiento de una aplicación crítica (no 
sirven al análisis de requisitos). 
Rápidos o desechables 
 Sirve al análisis y validación de los requisitos. 
 Se redacta la especificación del sistema y se lo desecha. 
 La aplicación se desarrolla siguiendo un paradigma diferente. 
 Si no se desecha, es un problema. 
Evolutivos: 
 Comienza con un sistema relativamente simple que implementa los 
requisitos más importantes o mejor conocidos. 
 El prototipo se aumenta o cambia en cuanto se descubren nuevos 
requisitos. 
 Finalmente se convierte en el sistema requerido. 
 Actualmente se usa en el desarrollo de sitios Webs y en aplicaciones de 
comercio electrónico. 
Vertical: se desarrolla completamente alguna de las funciones. 
Horizontal: desarrolla parcialmente todas las funciones. 
 
 
INGENIERIA DEL SW ASISTIDA POR COMPUTADORA (CASE) 
 
HERRAMIENTAS CASE 
 
Es el SW que se utiliza para ayudar a las actividades del proceso del SW, como la 
ingeniería de requerimientos, el diseño, el desarrollo de programas y las pruebas. 
 
Ayuda al proceso automatizando algunas de sus actividades 
Proporciona información acerca del SW en desarrollo 
 
Algunas actividades que se automatizan: 
 
El Desarrollo de modelos gráficos del sistema como parte de la especificación de 
requerimientos o del diseño del SW. 
La comprensión del diseño utilizando un diccionario de datos (entidades y 
relaciones). 
33 
 
La generación de interfaces del usuario a partir de la descripción gráfica de la 
interfaz elaborada por el usuario. 
La depuración de programas por medio de la provisión de la información 
proporcionada por los programas en ejecución. 
La conversión automática de programas de una versión anterior de un lenguaje 
de programación, como COBOL, a una versión más nueva. 
 
Limitaciones para su uso: 
 
Automatiza actividades rutinarias, no hay creatividad. 
No proporciona ayuda para la interactividad en el trabajo en equipo. 
 
Algunas herramientas considerando la función que cumplen: 
 
Planificación: PERT, Estimación, hojas de Cálculo. 
Edición: Editores de Texto, de diagramas, procesadores de texto. 
Gestión del Cambio: Rastreo de requerimientos, sistemas de control de 
cambios. 
Gestión de la configuración: Sistema de gestión de las versiones, de 
construcción de sistemas. 
Construcción de Prototipos: Lenguajes de muy alto nivel, generadores de 
interfaz del usuario. 
Apoyo a Métodos: Editores de diseño, diccionario de datos, generadores de 
código. 
Procesamiento de Lenguajes: Compiladores, interpretes. 
Análisis de Programas: Generadores de referencias cruzadas, analizadores 
estáticos, analizadores dinámicos. 
Pruebas: Generadores de pruebas de datos, comparadores de archivos. 
Depuración: Sistemas de depuración interactiva. 
Documentación: Programas de diseño de páginas, editores de imágenes. 
Reingeniería: Sistemas de referencias cruzadas, sistemas reestructuración de 
programas. 
 
 
 
 
 
 
 
 
 
34 
 
COMPONENTES DE UNA HERRAMIENTA CASE 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Un diccionario de datos: mantiene información sobre las entidades utilizadas 
en el diseño de un sistema. 
Herramientas de generación y definición de informes: obtienen información 
del almacén central y generan automáticamente la documentación del sistema. 
Herramientas de definición de formularios: permiten especificar los formatos 
de pantallas y de documentos. 
Facilidades para importar/exportar: Permiten el intercambio de información 
desde el repositorio central con otras herramientas de desarrollo. 
Generadores de código que generan código o esqueletos de código de forma 
automática a partir del diseño capturado en el almacén central. 
Las herramientas CASE permiten al usuario generar programas a partir de la 
información proporcionada en el modelo del sistema. 
Las herramientas CASE soportan diferentes lenguajes para que el usuario pueda 
generar un programas, a partir del mismo modelo de diseño. 
Como los modelos excluyen detalles de bajo nivel, el generador de código no 
puede normalmente generar el sistema completo. 
Por lo cual, normalmente es necesaria alguna codificación manual para añadir 
detalles al código generado. 
 
 
 
35 
 
Las herramientas Case se pueden clasificar desde 3 puntos de vista distintos: 
 
1) Una perspectiva funcional: de acuerdo con su función específica. 
2) Una perspectiva de proceso: de acuerdo con las actividades del proceso que 
ayudan. 
3) Una perspectiva de integración: de acuerdo con cómo están organizadas en 
unidades integradas que proporcionan ayuda a una o más actividades del 
proceso. 
 
 
CLASIFICACIÓN DE HERRAMIENTAS CASE SEGÚN SU FUNCIÓN 
 
La Figura siguiente: 
 
 
 
Una clasificación de las herramientas CASE acorde con su función. 
Enumera diferentes tipos y da ejemplos específicos de cada una. 
No es una lista completa de herramientas CASE. 
Las herramientas especializadas, como las de ayuda a la reutilización, no se 
incluyen. 
 
 
 
 
36 
 
CLASIFICACIÓN DE HERRAMIENTAS CASE SEGÚN LA 
PERSPECTIVA DEL PROCESO 
 
La siguiente figura muestra las fases del proceso que reciben ayuda por varios 
tipos de herramientas CASE. 
 
 
 
Las herramientas para la planificación y estimación, edición de texto, preparación 
de documentos y gestión de la configuración pueden utilizarse durante todo el 
proceso del software. 
 
CLASIFICACIÓN DE HERRAMIENTAS CASE SEGÚN LA 
PERSPECTIVA DE INTEGRACIÓN 
 
En función de la amplia ayuda que ofrece la tecnología CASE para el proceso del 
software, los sistemas CASE se pueden clasificar en tres categorías: 
 
1. Herramientas: ayudan a las tareas individuales del proceso (compilación de un 
programa y la comparación de los resultados de las pruebas). Las herramientas 
pueden ser de propósito general, independientes (procesador de texto) o 
agrupadas en bancos de trabajo. 
37 
 
2. Bancos de trabajo: ayudan a las fases o actividades del proceso 
(especificación/análisis, diseño, etc.). Son un conjunto de herramientas con algún 
grado de integración. 
 
3. Entornos: ayudan a todos los procesos del software, o una parte sustancial de 
éstos. Normalmenteincluyen varios bancos de trabajo integrados. 
 
La siguiente figura ilustra esta clasificación y muestra algunos ejemplos de estas 
clases de ayuda CASE. 
 
 
 
Herramientas de propósito general: se usan a discreción del ingeniero de 
software, quien decide cuándo aplicarlas para ayudar al proceso. 
Bancos de Trabajo: ayudan a algún método que incluye un modelo del proceso 
y un conjunto de reglas/pautas que se aplican al software en desarrollo. 
Entornos: se clasifican en integrados y centrados en el proceso. 
Entornos Integrados: brindan ayuda a los datos, al control y a la integración de 
la presentación. 
Entornos Centrados en Procesos: son más generales. Incluyen el 
conocimiento del proceso del software y un motor de procesos para aconsejar a 
los ingenieros qué herramientas o bancos de trabajo aplicar y cuándo deben 
utilizarse. 
 
38 
 
CLASIFICACIÓN DE HERRAMIENTAS CASE 
 
Advertencias: 
 
En la práctica, los límites entre estas diferentes clases son borrosos. Las 
herramientas se pueden vender como productos individuales, y ayudar a 
diferentes actividades. 
 
Ejemplo: Muchos procesadores de texto incluyen un editor de diagramas 
integrado. Los bancos de trabajo CASE para el diseño normalmente ayudan a la 
programación y a las pruebas (se relacionan más con el entorno que con los 
bancos de trabajo especializados). 
 
Conclusiones: 
 
No siempre es fácil ubicar un producto utilizando una clasificación. 
Sin embargo, la clasificación brinda un primer paso útil para ayudar a entender la 
amplitud de los servicios que los sistemas CASE pueden proporcionar al proceso 
de Desarrollo de Software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
39 
 
 
 
 
 
 
 
 
UNIDAD 2 
 
DISEÑO DEL SW E 
INGENIERIA DEL SW 
ROGER S. PRESSMAN 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
40 
 
DISEÑO DEL SW E INGENIERIA DEL SW 
 
El Diseño es una representación significativa de ingeniería de algo que se va a 
construir. 
 
Es el núcleo técnico de la ingeniería del software (diseño, generación de código y 
pruebas) y se aplica independientemente del modelo o metodología de diseño de 
SW que se utilice. 
Roger S Pressman 
 
 
Áreas o Niveles DEL DISEÑO: 
 
Datos 
Arquitectura 
Interfaces 
Componentes 
 
Conversión del Modelo de Análisis en un diseño de SW 
 
 
 
 
41 
 
Diseño de Datos: 
 
Los objetos de datos y las relaciones definidas en el DER y el contenido de datos 
detallado que se representa en el Diccionario de Datos (ambos del Modelo de 
Análisis) proporcionan la base de la actividad del diseño de datos. 
 
Diseño Arquitectónico: 
 
Define la relación entre los elementos estructurales principales del SW, los 
patrones de diseño que se pueden utilizar para lograr los requisitos que se han 
definido para el sistema y las restricciones que afectan a la manera en que se 
pueden aplicar los patrones de diseño arquitectónicos. La información para este 
diseño surge del DFD del Modelo de Análisis. 
 
Diseño de la Interfaz: 
 
En este nivel es la ergonómica humana la que dicta nuestro enfoque de diseño. 
El diseño de la interfaz describe la manera de comunicarse el SW dentro de s 
mismo, con sistemas que interoperan dentro de él y con las personas que lo 
utilizan. 
Una interfaz implica un flujo de información (p.ej: datos y/o control) y un tipo 
específico de comportamiento, esto se toma de los diagramas correspondientes 
del Modelo de Análisis (DFD y Especificaciones de Proceso). 
 
Diseño de Componentes: 
 
En este nivel un “enfoque de programación” conduce a diseños de datos y 
procedimientos eficaces. 
El diseño a este nivel transforma los elementos estructurales de la arquitectura del 
SW en una descripción procedimental de los componentes del SW. 
Toma como base la información de la Especificación de Proceso, Especificación 
de Control y del Diagrama de Transición de Estado del Modelo de Análisis. 
 
DISEÑO DEL SW E INGENIERIA DEL SW 
 
El Diseño comienza con el modelo de los requisitos (que surge del Modelo de 
Análisis), luego se obtienen los modelos detallados para las 4 áreas o niveles y el 
producto obtenido del diseño será la especificación del mismo con los 4 modelos 
que responden a las 4 áreas o niveles indicados anteriormente. 
 
Para verificar la calidad de la tarea de diseño, en cada etapa se revisa el producto 
obtenido en cuanto a claridad, corrección, finalización y consistencia, y se 
comparan con los requisitos y unos con otros. 
42 
 
DISEÑO ARQUITECTONICO 
 
Ian Sommerville, Cap. 11 
 
El Diseño Arquitectónico es un proceso creativo en el que se intenta establecer 
una organización del sistema que satisfaga los requerimientos funcionales y no 
funcionales del propio sistema. 
 
El proceso de diseño arquitectónico está relacionado con el establecimiento de un 
marco estructural básico que identifica los principales componentes de un sistema 
y las comunicaciones entre estos componentes. 
 
La arquitectura del sistema afecta el rendimiento, solidez, grado de distribución y 
mantenabilidad de un sistema. El estilo y estructura particular elegida para una 
aplicación puede, por lo tanto, depender de los requerimientos no funcionales del 
sistema: 
 
Requerimientos no funcionales 
 
El estilo y estructura particular elegida para una aplicación depende de: 
 
Rendimiento: si este es el criterio a utilizar, la arquitectura debería diseñarse 
para identificar las operaciones críticas en un pequeño nro. de subsistemas 
reduciendo las comunicaciones entre ellos como sea posible. 
 
Protección: usando este criterio, debería usarse una arquitectura estructurada 
en capas, con los recursos más críticos protegidos en las capas más internas y 
aplicando una validación de seguridad de alto nivel en dichas capas. 
 
Mantenibilidad: Si este es el criterio, debería diseñarse usando componentes 
independientes de grano fino que puedan modificarse con facilidad. 
 
Seguridad: Para esto, la arquitectura debería diseñarse para que las 
operaciones relacionadas con la seguridad se localizaran en un solo subsistema o 
en uno pequeño nro. 
 
Disponibilidad: en este caso debería diseñarse para incluir componentes 
redundantes y para que sea posible reemplazar y actualizar componentes sin 
detener el sistema. 
 
 
 
43 
 
Cuestiones de diseño a considerar durante el proceso de Diseño: 
 
Existe una arquitectura de aplicación genérica que pueda actuar como una 
plantilla para el sistema que se está diseñando? (reutilización). 
 
Cómo se distribuirá el sistema entre varios procesadores? 
 
Qué estilo o estilos arquitectónicos son apropiados para el sistema? (cliente- 
servidor, capas, etc.). 
 
Cuál será la aproximación fundamental utilizada para estructurar el sistema? 
(control de módulos). 
 
Cómo se descompondrán en módulos las unidades estructurales del sistema? 
 
Qué estrategia se utilizará para controlar el funcionamiento de las unidades del 
sistema? (evaluación del nivel de satisfacción). 
 
Cómo se evaluará el diseño arquitectónico? 
 
Cómo debería documentarse la arquitectura del sistema? 
 
Organización del Sistema 
 
La Organización de un sistema refleja la estrategia básica usada para estructurar 
dicho sistema. 
Esta puede reflejarse directamente en la estructura de los subsistemas. 
 
Algunas organizaciones son: 
 
Repositorio de datos. 
Servicios y servidores compartidos. 
Máquina abstracta o estilo por capas funcionales- 
 
El Modelo de Repositorio se consigue mediante dos formas: 
 
1. Todos los datos compartidos se almacenan en una BD central a la que pueden 
acceder todos los subsistemas. Esto es lo que se denomina modelo de repositorio. 
2. Cada subsistema mantiene su propia BD. Los datos se intercambian con otros 
subsistemas mediante el paso de mensajes entre ellos. 
 
 
44 
 
Modelo de Repositorio oCentrada de datos 
 
 
 
En este modelo (arquitectura de un conjunto de herramientas CASE integradas) el 
repositorio es pasivo y el control es responsabilidad de los subsistemas que lo 
utilizan. 
 
Modelo Cliente-Servidor 
 
Es una arquitectura distribuida que se organiza como un conjunto de servicios y 
servidores asociados, más unos clientes que acceden y usan los servicios. Sus 
componentes son: 
 
Servidores que ofrecen servicios a otros subsistemas (p.ej: servidores de 
impresoras, de ficheros, de compilación, etc.). 
 
Clientes que llaman a los servicios ofrecidos por los servidores. 
 
Una red que permita a los clientes acceder a estos servicios. 
 
Los clientes acceden a los servicios de un servidor a través de llamadas a 
procedimientos remotos usando un protocolo de petición-respuesta tal como el 
protocolo http usado en la WWW. 
 
 
 
 
45 
 
Modelo Cliente/Servidor 
 
 
Modelo de Capas 
 
Organiza el sistema en capas, cada una de las cuales proporciona un conjunto 
de servicios. 
Cada capa puede pensarse como una máquina abstracta cuyo lenguaje máquina 
se define por los servicios proporcionados por la capa y se lo usa para 
implementar el siguiente nivel de la máquina abstracta. 
Soporta el desarrollo incremental de sistemas. 
A medida que se desarrolla una capa, algunos de los servicios proporcionados 
por esa capa pueden estar disponibles para los usuarios. 
Soporta los cambios y es portable. En la medida en la que su interfaz no cambie, 
una capa puede reemplazarse por otra equivalente. 
La desventaja es que la estructuración de los sistemas puede resultar difícil. 
46 
 
 
 
Modelo de capas de un sistema de gestión de versiones 
 
 
PRINCIPIOS Y CONCEPTOS DEL DISEÑO 
ROGER S. PRESSMAN 
 
Principios del Diseño 
 
El Diseño de SW es tanto un Proceso como un Modelo. 
 
El Proceso de diseño es una secuencia de pasos que hacen posible que el 
diseñador describa todos los aspectos del SW que se va a construir. 
 
El Modelo de diseño es el equivalente a los planes de un arquitecto para una 
casa, ya que representa primero lo global y luego va a lo particular. 
 
Los Principios básicos del Diseño hacen posible que el ingeniero del SW 
navegue por el proceso de diseño. 
 
Davis sugiere un conjunto de ellos para el Diseño del SW, a saber: 
 
En el Proceso de Diseño no deberá utilizarse “orejeras”. Hay que tener en 
cuenta enfoques alternativos basados en: requisitos del problema, recursos 
disponibles y los conceptos de diseño existentes. 
 
El diseño deberá poderse rastrear hasta el modelo de análisis. Debe 
poderse rastrear cómo se han satisfecho los requisitos por el modelo de diseño. 
47 
 
 El diseño no deberá inventar nada que ya esté inventado. Se debe utilizar 
patrones ya existentes o adaptar estos al problema. 
 
El diseño deberá minimizar la distancia intelectual entre el SW y el 
problema como si de la misma vida real se tratara. La estructura del diseño del 
SW imita la estructura del dominio del problema. 
 
El diseño deberá presentar uniformidad e integración. Las reglas de estilo y 
formato deben definirse antes de encarar un trabajo. Las interfaces entre 
componentes deben definirse cuidadosamente. 
 
El diseño deberá estructurarse para admitir cambios. Debe ser flexible. 
 
El diseño deberá estructurarse para degradarse poco a poco, incluso 
cuando se enfrenta con datos, sucesos o condiciones de operación 
aberrantes. Deberá ser adaptable para recibir cambios y terminar su CVU en 
forma suave. 
 
El diseño no es escribir código y escribir código no es diseñar. 
 
El diseño deberá evaluarse en función de la calidad mientras se va 
creando, no después de terminarlo. Para evaluar esto se dispone de conceptos 
y medidas de diseño que se verá más adelante. 
 
El diseño deberá revisarse para minimizar los errores conceptuales 
(semánticos). Deberá asegurarse de haber afrontado los elementos conceptuales 
principales antes de preocuparse por la sintaxis del modelo de diseño. 
 
Conceptos del diseño 
 
Evolucionaron y cambiaron con el tiempo. Cada uno de ellos proporciona la base 
de donde el diseñador podrá aplicar los métodos de diseño más sofisticados. 
 
Cada uno ayudara al ingeniero del SW a responder las preguntas siguientes: 
 
Qué criterios se podrán utilizar para la partición del SW en componentes 
individuales? 
 
Cómo se puede separar la función y la estructura de datos de una 
representación conceptual del SW? 
 
Existen criterios uniformes que definen la calidad técnica de un diseño de SW? 
48 
 
M. A. Jackson dijo: 
 
“El comienzo de la sabiduría para un ingeniero de SW es reconocer la diferencia 
entre hacer que un programa funcione y conseguir que lo haga correctamente” 
 
Los conceptos de diseño de SW fundamentales proporcionan el marco de trabajo 
necesario para “que lo haga correctamente” 
 
Algunos de ellos son: 
 
Abstracción: se debe concentrar en el problema a algún nivel de generalización 
sin tener en consideración los datos irrelevantes de bajo nivel. En el nivel más alto 
se utilizará el lenguaje del entorno del problema y en el más bajo se establece la 
solución para implementarlo (generar el código fuente). 
 
Hay 3 tipos de abstracciones: 
 
 Abstracción procedimental: es una secuencia nombrada de instrucciones 
que tiene una función específica y limitada, p.e: abrir (que implica una 
secuencia larga de pasos procedimentales) 
 
 Abstracción de datos: es una colección nombrada de datos que describe 
un objeto de datos, p.e.: en abrir sería puerta (que se compone de una 
serie de atributos que describen ese objeto). Entonces por añadidura la 
abstracción abrir hace uso de los atributos de puerta. 
 
 Abstracción de Control: implica un mecanismo de control de programa sin 
especificar los datos internos. P.e: el semáforo de sincronización que se 
utilizará para coordinar las actividades en un sistema operativo. 
 
Refinamiento: El paso a paso es una estrategia de diseño descendente que se 
realiza para refinar los niveles de detalle procedimentales hasta alcanzar las 
sentencias del lenguaje de programación. Estos pasos implican decisiones de 
diseño. 
 
Modularidad: El SW se divide en componentes nombrados y abordados por 
separado, llamados generalmente módulos, que se integran para satisfacer los 
requisitos del problema. Esto es recomendable siempre y cuando no se 
modularice de más, porque en este caso la simplicidad de este concepto se verá 
abrumada por la complejidad de la integración. 
 Arquitectura del SW: Es la estructura jerárquica de los componentes del 
programa, la manera en que estos interactúan y los datos que van a utilizar. En un 
49 
 
sentido más amplio, los “componentes” se pueden generalizar para representar los 
elementos principales del sistema y sus interacciones. 
 
Jerarquía de Control: también denominada “estructura del programa” 
representa la organización de los componentes de programa (módulos) e implica 
una jerarquía de control. 
 
 
 
La profundidad y anchura proporcionan una indicación de la cantidad de niveles de 
control y el ámbito de control global respectivamente. 
 
El grado de salida es una medida del número de módulos que se controlan 
directamente con otro módulo. El grado de entrada indica la cantidad de módulos 
que controlan directamente un módulo dado. 
 
La relación de control entre los módulos se indica así: 
 
 Superior cuando un módulo controla a otro. 
 Subordinado cuando se habla del controlado. 
 
También representan dos características accesorias (sobre todo en SW 
orientado a objetos): 
 
 La visibilidad que indica el conjunto de componentes de programa que un 
componente dado puede invocar o utilizar como datos, incluso 
indirectamente, y la conectividad que indica el conjunto de componentes 
que un componente dado invoca o utiliza directamente como datos.50 
 
 División estructural: Si el estilo arquitectónico es jerárquico la estructura del 
programa se puede dividir en dos particiones: 
 
 La horizontal que define ramas separadas para cada función principal del 
programa (el enfoque más simple es el de Entrada, Proceso y Salida). 
 La Vertical (factorización) sugiere que los módulos de más alto nivel 
realicen tareas de control y los de más abajo las tareas de procesamiento. 
 
Ambos tienen sus ventajas y desventajas (p.e: el 1° proporciona SW más fácil de 
probar, de mantener, de ampliar y sin efectos secundarios; el 2° son menos 
susceptibles a los efectos secundarios cuando se producen cambios y por tanto se 
podrán mantener mejor). 
 
Estructura de Datos: es una representación de la relación lógica entre 
elementos individuales de datos. Esta dicta las alternativas de organización, 
métodos de acceso, grado de capacidad de asociación y procesamiento de la 
información. 
 
Procedimiento de SW: se centra en el procesamiento de cada módulo 
individualmente, este procedimiento debe proporcionar una especificación precisa 
de procesamiento, incluyendo la secuencia de sucesos, los puntos de decisión 
exactos, las operaciones repetitivas e incluso la estructura/organización de datos. 
 
Ocultamiento de información: sugiere que los módulos se caracterizan por las 
decisiones de diseño que (cada uno) ocultan a otros. Los módulos deben 
especificarse y diseñarse de manera que la información (procedimiento y datos) 
que está dentro de un módulo sea inaccesible a otros módulos que no necesiten 
esa información. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
51 
 
DISEÑO DE LA ARQUITECTURA LOGICA CON PATRONES 
CRAIG LARMAN 
 
 
Diseño de la arquitectura lógica con patrones 
 
Un sistema típico está compuesto de muchos paquetes lógicos. 
Como un paquete de interfaz de usuario, un paquete de accesos a BD, etc. donde 
cada paquete agrupa un cohesivo de responsabilidades (p.ej: el acceso a la BD). 
Esta es la práctica básica de aplicar la modularidad para dar soporte a la 
separación de intereses. 
 
Como definición la Arquitectura de SW es el conjunto de decisiones significativas 
sobre la organización del sistema SW, la selección de los elementos estructurales 
y sus interfaces, con los que se compone el sistema, junto con su comportamiento, 
tal como se especifica en las colaboraciones entre esos elementos, la composición 
de esos elementos estructurales y de comportamiento en subsistemas 
progresivamente más amplios, y el estilo de arquitectura que guía esta 
organización. 
 
La arquitectura es parte investigación y parte de trabajo de diseño, se lo definiría 
como: 
 
Investigación Estructural: implica la identificación de aquellos requisitos 
funcionales y no funcionales que influyen (o deberían influir) de manera 
significativa en el diseño del sistema, como tendencias de mercado, rendimiento, 
coste, mantenimiento y puntos evolución. 
 
Diseño Estructural: es la resolución de las influencias y requisitos en el diseño 
del SW, HW y las redes, operaciones, políticas, etc. 
 
En el UP, el Diseño y la Investigación de la arquitectura se llaman conjuntamente 
Análisis Arquitectural. 
 
Dimensiones y vistas de la arquitectura en el UP 
 
La arquitectura de un sistema, abarca varias dimensiones: 
 
La arquitectura lógica, que describe el sistema en términos de su organización 
conceptual en capas, paquetes, frameworks importantes, clases, interfaces y 
subsistemas. 
 
52 
 
El despliegue de la arquitectura, que describe el sistema en términos de la 
asignación de los procesos a unidades de procesos, y la configuración de la red. 
 
El UP sugiere seis vistas de la arquitectura: 
 Lógica 
 Proceso 
 Despliegue 
 Datos 
 Casos de Uso 
 Implementación 
 
Patrones de arquitectura y categoría de patrones 
 
El libro POSA (Pattern-Oriented SW Architecture) ofrece la siguiente clasificación 
de algunas buenas prácticas: 
 
De Arquitectura: relacionados con el diseño a gran escala y de grano grueso, y 
que se aplican típicamente durante las primeras iteraciones (la fase de 
elaboración) cuando se establecen las estructuras y conexiones más importantes. 
(p.ej: patrón Capas) 
 
De Diseño: o sea el diseño de los objetos y frameworks de pequeña y mediana 
escala, que se aplican en el diseño de una solución para conectar los elementos 
de gran escala que se defines con los patrones de arquitectura, y durante el 
trabajo de diseño detallado para cualquier aspecto del diseño local (patrones de 
micro-arquitectura). P.ej: el patrón Fachada (para obtener la interfaz de una capa 
a la siguiente) y el patrón Estrategia (que permite algoritmos conectables). 
 
Estilos: que son soluciones de bajo nivel orientadas a la implementación o al 
lenguaje. P.ej: el patrón Singleton que sirve para asegurar el acceso global a una 
única instancia de una clase. 
 
Cabe aclarar que existen otras categorías, como ser: 
 
 Patrones del proceso del desarrollo de SW y organizacionales 
 Patrones de Interfaz de Usuario 
 Patrones de Prueba. 
 
 
 
 
 
53 
 
Análisis arquitectural y el SAD 
 
La esencia del AA es identificar los factores que deberían influir en la arquitectura, 
entender su variabilidad, prioridad y resolverlos. 
 
En el UP, los factores de la arquitectura se recogen en la Especificación 
Complementaria y, las decisiones de diseño que los resuelven, se recogen en el 
Documento de la Arquitectura de SW (SAD). 
 
El AA comienza en la fase de Inicio, siendo una actividad de alta prioridad y que 
tiene mucha influencia en el desarrollo de SW. 
 
 
Es útil para: 
 
Reducir el riesgo de olvidar algo esencial en el diseño de los sistemas. 
Evitar dedicar excesivo esfuerzo a cuestiones de baja prioridad. 
Ayudar a alinear el producto con los objetivos del negocio. 
 
 
El AA trata de la identificación y resolución de los requisitos no funcionales del 
sistema (p.ej: calidad), en el contexto de los requisitos funcionales. Comprende 
tanto la investigación arquitectural (identificación) como el diseño arquitectural 
(resolución). Algunas cuestiones que se identifican y resuelven, son: 
 
Cómo afectan en el diseño los requisitos de fiabilidad y tolerancia a fallos? 
 Cómo afecta en la rentabilidad el costo de las licencias de los subcomponentes 
comprados? 
Cómo afecta la distribución de los servicios en los requisitos de calidad y los 
requisitos funcionales? 
Cómo afectan al diseño los requisitos de adaptabilidad y de configuración. 
 
Pasos comunes en el AA son: 
 
1. Identificar y analizar, en forma completa, los requisitos no funcionales que 
influyen en la arquitectura. Estos son los factores de la arquitectura. 
 
2. Para aquellos requisitos que influyen de manera significativa en la 
arquitectura, analizar las alternativas y crear soluciones que resuelvan el 
impacto. Estas son las decisiones sobre la arquitectura. 
 
 
54 
 
Tipos y vistas de la arquitectura 
 
En el UP existe una especialización que se describen en “Vistas” de la 
arquitectura, que resumen y destacan una perspectiva particular, p.ej: 
 
La Vista Lógica de la arquitectura que resume la organización y funcionalidad 
de los elementos del SW importantes (como las capas) y es análogo al término 
arquitectura de la aplicación. 
 
La Vista de Despliegue que resume la topología del sistema, las 
comunicaciones y la correspondencia entre los elementos ejecutables y los nodos 
del proceso (análogo al término de arquitectura del sistema). 
 
Reiteramos, el UP sugiere seis vistas de la arquitectura (Lógica, Proceso, 
Despliegue, Datos, Casos de Uso e Implementación) 
 
En resumen, el AA se relaciona con las vistas de la arquitectura porque las 
decisiones sobre ésta se reflejan y describen en una o más vistas de la 
arquitectura.55 
 
 
 
 
 
 
 
 
 
 
 
Unidad 3 
 
DISEÑO DE INTERFACES DE 
USUARIO – REGLAS DE ORO 
 
(Roger S. Pressman – Ing. del SW) 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
56 
 
Diseño de la interfaz de usuario 
 
REGLAS DE ORO 
 
DAR EL CONTROL AL USUARIO 
REDUCIR LA CARGA DE MEMORIA DEL USUARIO 
CONSTRUIR UNA INTERFAZ CONSECUENTE 
 
 DAR EL CONTROL AL USUARIO 
 
 Se deben definir los modos de interacción de manera que no obligue a que 
el usuario realice acciones innecesarias y no deseadas. 
 Tener en consideración una interacción flexible. 
 Permitir que la interacción del usuario se pueda interrumpir y deshacer. 
 Diseñar la interacción directa con los objetos que aparecen en la pantalla. 
 Aligerar la interacción a medida que avanza el nivel de conocimiento y 
permitir personalizar la interacción. 
 Ocultar al usuario ocasional los entresijos técnicos. 
 
 REDUCIR LA CARGA DE MEMORIA DEL USUARIO 
 
 Reducir la demanda de memoria a corto plazo. 
 Establecer valores por defecto útiles. 
 Definir las deficiencias que sean intuitivas. 
 
 CONSTRUCION DE UNA INTERFAZ CONSECUENTE 
 
Significa que: 
1. Toda la información visual está organizada de acuerdo con el diseño 
estándar que se mantiene en todas las presentaciones de pantalla. 
2. Todos los mecanismos de entrada se limiten a un conjunto limitado y que 
se utilicen consecuentemente por toda la aplicación. 
3. Los mecanismos para ir de tarea a tarea se hayan definido e implementado 
consecuentemente. 
 
Principios para construir una interfaz consecuente: 
 
1. Permitir que el usuario realice una tarea en el contexto adecuado. 
2. Mantener la consistencia en toda la familia de aplicaciones. 
3. Los modelos interactivos anteriores han esperanzado al usuario, no 
realicemos cambios a menos que exista alguna razón convincente para 
hacerlo. 
57 
 
DISEÑO DE INTERFACES DE USUARIO 
Ian Sommerville – Ing. del SW 
 
 
DISEÑO DE INTERFACES DE USUARIO 
 
Los “errores de usuario” tienen por causa un mal diseño de las interfaces. 
 
Diseñar significa tener en cuenta las capacidades físicas y mentales de las 
personas que las utilizarán, entre ellas: 
 
 Memoria limitada a corto plazo. La información no debe ser abundante. 
 Posibilidad de cometer errores aumentando el estrés, lo que a su vez genera 
una mayor preocupación y posibilidad de errar. 
 Amplio rango de capacidades entre los usuarios. No se debe diseñar para las 
propias capacidades y pensar que los otros se adaptarán. 
 La existencia de diferentes preferencias de interacción. A algunas personas les 
gusta el modo texto, a otras el modo gráfico o con imágenes. 
 
Principios de diseño para una interfaz 
– Factores humanos – 
 
 
Principio 
 
Descripción 
 
Familiaridad 
La interfaz debe utilizar términos y conceptos 
obtenidos de la del Usuario, esto es, experiencia de 
las personas que más utilizan el sistema (amigables al 
entorno). 
 
Uniformidad 
Siempre que sea posible, la interfaz debe ser uniforme 
en el sentido de que las operaciones comparables se 
activen de la misma forma (comandos, menús, 
parámetros, puntuación, etc. debe ser similar) 
 
Mínima sorpresa 
El comportamiento del sistema no debe provocar 
sorpresa a los usuarios (efectos comparables a 
acciones comparables). 
 
 
Recuperabilidad 
La interfaz debe incluir mecanismos para permitir a los 
usuarios recuperarse de los errores (minimizar errores 
mediante: Confirmación de acciones destructivas, 
Proporcionar un recurso para deshacer, Generar 
puntos de control). 
 
Guía de Usuario 
Cuando ocurran errores, la interfaz debe proporcionar 
retroalimentación significativa y características de 
ayuda sensible al contexto (integrar niveles de ayuda 
58 
 
adecuados con el tipo de información que se está 
manejando). 
 
 
Diversidad de Usuarios 
La interfaz debe proporcionar características de 
interacción apropiadas para los diferentes tipos de 
usuarios del sistema (usuarios casuales – interfaz 
guiadas- vs. Usuarios potenciales – métodos 
abreviados-) 
 
 
Principios de diseño de las IU 
- Factores técnicos – 
 
 
 
Botones 
 
Descripción 
 
 
Cancelar 
Se usa cancelar en ventanas de respuesta en donde el 
Sistema pregunta al usuario si debe continuar con la acción 
Seleccionada o abandonarla. 
Cancelar se combina con un botón Aceptar o botones Si o 
No. 
Cerrar 
 
Cerrar se usa para cerrar ventanas dentro de la aplicación 
 
 
 
Salir 
Salir se usa para abandonar una aplicación completa. 
Cuando el usuario hace click en Cerrar o Salir el sistema 
debe Revisar para ver si no hay cambios guardados. 
 
Si hay cambios que no han sido guardados el sistema debe 
preguntar si desea guardar el trabajo antes de cerrar la 
ventana o salir de la aplicación. 
 
Eliminar 
Eliminar se usa para quitar datos de la Base de Datos en 
forma permanente Cuando el usuario hace click en Eliminar 
el sistema siempre debe preguntar ¿Está Ud. seguro? 
 
 
Guardar 
Cada acción de guardar en la Base de Datos debe ser 
explícita y obvia Nunca guarde datos con un botón Aceptar u 
OK. El usuario siempre debe estar consciente que está 
actualizando los registros de una forma permanente 
 
Guía de usuario 
Cuando ocurren errores, la interfaz debe proporcionar 
retroalimentación significativa y características de ayuda 
sensible al contexto. 
 
Deshacer 
Deshacer va bajo el menú de Edición. El deshacer por lo 
general es a nivel de campo. 
 
 
 
59 
 
Diseño de Interfaces de Usuario 
 
Cuestiones claves a considerar al encarar el diseño: 
 
 Cómo debe interactuar el usuario con el sistema informático? 
 Cómo se debe presentar la informa- ción del sistema informático al usuario? 
 
Interacción del usuario 
 
Significa emitir comandos y datos asociados al sistema informático. 
 
Existen cinco estilos para la interacción. 
 
Estilos par la interacción: 
 
 MANIPULACION DIRECTA: 
 
 PRINCIPAL VENTAJA: Interacción rápida e Intuitiva. Fácil de aprender. 
 PRINCIPAL DESVENTAJA: Puede ser difícil de implementar. Sólo es 
adecuada donde existe una metáfora visual para las tareas y objetos. 
 EJEMPLOS DE APLICACIÓN: Videojuegos, Sistemas, CAD, etc. 
 
 SELECCION DE MENÚES: 
 
 PRINCIPAL VENTAJA: Evita errores del Usuario. Se requiere teclear poco. 
 PRINCIPAL DESVENTAJA: Lenta para Usuarios experimentados. Puede 
llegar a ser compleja si existen muchas opciones en el menú. 
 EJEMPLOS DE APLICACIÓN: La mayoría de los Sistemas de propósito 
General. 
 
 RELLENADO DE FORMULARIOS: 
 
 PRINCIPAL VENTAJA: Introducción de datos sencilla. 
 PRINCIPAL DESVENTAJA: Ocupan mucho espacio en la pantalla. Causa 
problemas cuando las opciones del usuario no se ajustan a los campos del 
formulario. 
 EJEMPLOS DE APLICACIÓN: Control de stock. Procesamiento de 
préstamos personales, etc. 
 
 
 
 
60 
 
 LENGUAJE DE COMANDOS: 
 
 PRINCIPAL VENTAJA: Poderoso y flexible. 
 PRINCIPAL DESVENTAJA: Difícil de aprender. Gestión pobre de errores. 
 EJEMPLOS DE APLICACIÓN: Sistemas operativos. Sistemas de comando 
y control. 
 
LENGUAJE NATURAL 
 
 PRINCIPAL VENTAJA: Accesible a usuarios casuales. Fácil de ampliar. 
 PRINCIPAL DESVENTAJA: Se requiere teclear más. Los sistemas de 
comprensión de lenguaje natural no son fiables. 
 EJEMPLOS DE APLICACIÓN: Sistemas de recuperación de información. 
 
 
EL PROCESO DE DISEÑO DE LA INTERFAZ DEL USUARIO (UI) 
(Ian Sommerville – Ing. del SW – 344/351) 
 
 
EL PROCESO DE DISEÑO DE LA UI 
 
Es un proceso iterativo donde los usuarios interactúan con los diseñadores y 
prototipos de la interfaz para decidir las características, organización, apariencia y 
funcionamiento de la UI del sistema. 
 
Existen tres actividades esenciales en este proceso: 
 
 Análisis del usuario: se desarrolla una comprensión de las tareas que este 
realiza, su entorno de trabajo, los otros sistemas que utiliza, cómo interactúan con 
elresto de las personas en su trabajo, etc. 
 
 Prototipado de la UI: el diseño y desarrollo de la UI es un proceso iterativo, con 
el usuario y debe ser representado en forma tangible, para poder ser evaluado 
eficazmente. 
 
 Evaluación de la UI: permanentemente debe ser sometido a evaluación para 
proceder a nuevos ciclos de desarrollo iterativo en función a las experiencias 
reales. 
 
61 
 
 
 
Consiste en: 
 
 Identificar en forma global los requisitos para el SW, en función de lo conocido y 
las áreas del esquema donde es necesaria más definición. 
 
A través de un “diseño rápido” se construye un prototipo consistente en los 
aspectos del sistema que serán visibles para el usuario (interfaces). 
 
Se evalúa el prototipo y se lo usa para refinar los requisitos del SW a desarrollar. 
 
 Características: 
 Un alto grado de iteración 
 Un muy alto grado de participación del usuario 
 Un uso extensivo de prototipos 
 Normalmente pocos días de desarrollo (10% del proyecto) 
 Funcionalidad limitada 
 Poca fiabilidad 
 
 Lo ideal es que el prototipo sirva como herramienta para identificar los requisitos 
del SW, no como el sistema definitivo. 
 
 Se puede usar componentes para el sistema definitivo pero no puede ser el 
producto final. 
62 
 
Desventajas: 
 No es bueno para la calidad del SW. 
 No tiene en cuenta el mantenimiento posterior. 
 No considera los aspectos globales del sistema. 
 
Premisas: 
 Un mejor modelo de comunicación que el tradicional. 
 La iteración es necesaria. 
 Las versiones pueden no ser muy claras para los usuarios. 
 
Facilidad de Uso de la UI 
 
Es una medida de la manera en que un sistema de cómputo facilita el aprendizaje, 
ayuda a quienes aprenden a recordar lo que han aprendido; reduce la posibilidad 
de errores; les permite ser eficientes y los deja satisfecho con el sistema. 
 Para verificar la facilidad de uso realice una prueba de uso y conteste: 
 
 ¿Es posible usar el sistema sin ayuda ni enseñanza continua? 
 ¿Las reglas de interacción ayudan a un usuario conocedor a trabajar con 
eficiencia? 
 ¿Los mecanismos de interacción se vuelven más flexibles a medida que los 
usuarios adquieren más conocimientos? 
 ¿El sistema se ha adecuado al entorno físico y social en que habrá que usarse? 
¿El usuario está al tanto del estado del sistema? ¿El usuario sabe donde se 
encuentra en cada momento? 
 ¿La interfaz está estructurada de manera lógica y consistente? 
 ¿Los mecanismos de interacción, íconos y procedimientos son consistentes en 
toda la interfaz? 
 ¿La interacción anticipa errores y ayuda al usuario a corregirlos? 
 ¿La interfaz tolera los errores que se cometen? 
 ¿La interacción es simple? 
 
 
 
 
 
 
 
 
 
 
 
63 
 
CONCEPTOS Y DIRECTRICES DE UI EN UP 
 
Concepto de “Diseño centrado en el usuario” 
 
El diseño centrado en el usuario es el diseño de aplicaciones que tiene en cuenta 
las necesidades y la efectividad del usuario final como prioridad. 
 
No existe un consenso claro sobre qué constituye el diseño centrado en el usuario. 
Sin embargo, John Gould y sus compañeros de IBM desarrollaron una propuesta 
en la década de 1980 llamada Diseño para la usabilidad que incluye las 
definiciones aceptadas más comúnmente. Lo desarrollaron a partir de una 
experiencia práctica en una serie de sistemas interactivos, más notablemente, el 
sistema de mensajería Olympic de IBM de 1984. 
 
La propuesta tiene cuatro componentes principales: 
 
1. Atención en los usuarios 
 
Gould sugiere que los desarrolladores deberían decidir quiénes serán los usuarios 
e involucrarlos lo antes posible. También propone una serie de maneras de 
familiarizarse con los usuarios, sus tareas y requisitos: 
 Hablar con los usuarios. 
 Visitar las instalaciones de los clientes. 
 Observar el trabajo de los usuarios. 
 Grabar en vídeo el trabajo de los usuarios. 
 Conocer la organización del trabajo. 
 Probarlo uno mismo. 
 Hacer que los usuarios piensen en voz alta mientras trabajan. 
 Diseño participativo. 
 Incluir usuarios expertos en el equipo de diseño. 
 Realizar análisis de las tareas. 
 Utilizar encuestas y cuestionarios. 
 Desarrollar objetivos que se puedan probar. 
 
2. Integrado con diseño 
 
Las tareas de usabilidad deben realizarse en paralelo desde el principio del 
desarrollo. 
 
Estas tareas incluyen los bocetos (sketching) de la interfaz de usuario y el 
borrador de las guías de usuario o la ayuda en línea. Gould también resalta que la 
usabilidad debería ser responsabilidad de un grupo. 
64 
 
Una característica importante del diseño integrado es que el enfoque general (el 
Framework) del diseño detallado de la UI se desarrolla y se prueba en un estadio 
temprano. Esta es una diferencia importante entre el diseño centrado en el usuario 
y otras técnicas puramente incrementales. 
Garantiza que el diseño incremental que se lleva a cabo en las fases posteriores 
encaje perfectamente en el Framework, y que la interfaz de usuario sea 
consistente en cuanto al aspecto, la terminología y el concepto. 
 
A medida que el diseño de la interfaz de usuario avanza, muchas clases del 
dominio se representarán como elementos de la interfaz de usuario. 
Los elementos de la UI y las relaciones entre ellos, deberían ser consistentes con 
el modelo de dominio y representarse de forma consistente en todas las partes del 
sistema que se está diseñando. (Esto no ayuda únicamente a los usuarios, sino 
que mejora la reutilización de los componentes de la interfaz de usuario). 
 
3. Pruebas de usuario tempranas 
 
Las pruebas de usuario tempranas consisten en la creación de los primeros 
storyboards y el desarrollo temprano de prototipos de baja fidelidad (Un storyboard 
es una descripción lógica y conceptual de la funcionalidad del sistema, consulte 
directriz Storyboard). Los prototipos de alta fidelidad se crean cuando el proceso 
está más avanzado. 
Los storyboards se pueden utilizar en conjunción con casos de uso para escribir 
escenarios de utilización concretos para el sistema que se están diseñando. 
 
Los storyboards pueden ser narrativos, ilustra- dos (utilizando los bocetos de la UI 
para las ilustraciones); los guiones gráficos, los ensayos (con usuarios) y los 
grupos centrados en el usuario son propuestas poco familiares para muchos 
desarrolladores de SW. Sin embargo, son más rentables que el descubrimiento de 
diseños inadecuados o requisitos comprendidos incorrectamente cuando la 
implementación está en curso. 
 
4. Diseño iterativo 
 
El diseño iterativo se adapta a los problemas que necesitan un perfeccionamiento 
de la comprensión y tienen requisitos cambiantes. No resulta sorprendente que el 
diseño iterativo sea un componente clave del diseño centrado en el usuario. Esto 
se debe, en parte, a las cambiantes necesidades de los usuarios en el tiempo, 
pero también a la complejidad inherente de la producción de soluciones de diseño 
que pueden satisfacer varias necesidades. 
 
 
 
65 
 
Concepto de “Prototipo de interfaz de usuario” 
 
Quién lo utiliza y para que se utiliza? 
 
Los roles siguientes utilizan el prototipo de interfaz de usuario: 
 
 Diseñadores de interfaz de usuario, para explorar y/o validar el diseño de UI 
antes de que se invierta demasiado en este. 
 
 Especificadores de requisitos, para comprender la interfaz de usuario para un 
guion de uso. 
 
 Analistas de sistemas, para comprender cómo afecta la interfaz de usuario en 
el análisis del sistema. 
 
 Diseñadores, para comprender cómo afecta la interfaz de usuario y qué 
requiere del interior del sistema. 
 Administradores del proyecto, para planear las actividades de desarrollo y de 
prueba (testing). 
 
Concepto de “Mapa de Navegación” 
 
Este artefacto describe la estructura de los elementos de las UI del sistema, junto 
con las vías de navegación potenciales.