UNIDAD 3

INTRODUCCIÓN AL DISEÑO DE SISTEMAS

¿Qué significa Diseño?... ¿Qué abarca un diseño?... ¿Qué hace un arquitecto para el
diseño de una casa?...

Diseño: Es un boceto, bosquejo o esquema que se realiza, ya sea

mentalmente o en un soporte material, antes de concretar la producción de algo. El
término también se emplea para referirse a la apariencia de ciertos productos en
cuanto a sus líneas, forma y funcionalidades.

¿Qué significa Sistema?... ¿Qué es un sistema?

Sistema: Un sistema es un conjunto de partes o elementos organizados y relacionados

que interactúan entre sí para lograr un objetivo. Los sistemas reciben (entrada) datos,
energía o materia del ambiente y proveen (salida) información, energía o materia.

Ejemplo de un sistema: Sistema respiratorio, sistema nervioso, sistema óseo, el

sistema de frenos de un vehículo, el sistema eléctrico de una casa, un sistema de
riego, entre otros.

Sistema Informático: Es el conjunto de sub-procesos que siguen un secuencia lógica

para la solución de un problema. Un sistema tiene una entrada de datos y una salida.
También dispone de una retroalimentación. El sistema está dentro de un entorno y
debe cuidarse se los agentes externos. Por ejemplo si hablamos del sistema de
respiratorio el agente externo que podría causar daño seria el polvo o el frio; en el caso
de un sistema informático el agente externo sería un virus informático.

Proceso
 “El objetivo del diseño es producir un modelo o
representación de una entidad que se va a construir
posteriormente” (Pressman, 2002)

El diseño es el primer paso en la fase de desarrollo de cualquier producto o sistema

de Ingeniería. Toma los requerimientos de las funcionalidades de un SI (entrada,
procesamiento, salida, almacenamiento y control) identificadas en la fase de análisis y
los sintetiza en un nuevo proyecto de sistema.

• Se cuenta con una especificación preliminar de lo que el nuevo sistema de

información debe hacer y se tiene claro que es necesario realizar un nuevo
sistema: para arreglar los problemas del sistema actual y responder a las
nuevas necesidades y a las oportunidades para usar la información.

• Existe mucha incertidumbre debido a que se concilian diferentes ideas de lo que

los usuarios consideran debería hacer el sistema, con las alternativas existentes
acerca del ambiente de aplicación del nuevo sistema.

“Crea una representación o modelo de software,

donde se proporciona detalles acerca de las
estructuras de datos, las arquitecturas, las interfaces
y los componentes de software que son necesarios
para implementar el sistema”. Roger S. Pressman
 INSTITUTO TECNOLÓGICO SUPERIOR
“JOSE OCHOA LEÓN” DISEÑO DE SISTEMAS

Después de haber realizado el análisis de un problema informático haciendo uso de la

gama de diagramas que nos provee UML, se procede a realizar el diseño del sistema
el mismo que se compone de 4 fases que son:

1. Diseño de Datos

2. Diseño Arquitectónico

3. Diseño de Interfaces

4. Diseño de componentes
En la etapa de diseño es donde se toman las decisiones que afectarán finalmente al
éxito de la implementación del programa, y también, a la facilidad de mantenimiento
que tendrá el software. Por tanto el diseño es un paso fundamental de la fase de
desarrollo. El diseño es la única forma mediante la que podemos traducir con precisión
los requisitos del cliente en un producto o sistema acabado. El diseño de software es
la base de todas las partes posteriores del desarrollo y de la fase de prueba, como
muestra en el siguiente gráfico.

Sin diseño, nos arriesgamos a construir un sistema inestable, un sistema que falle
cuando se realicen pequeños cambios, un sistema que sea difícil de probar, un
sistema cuya calidad no pueda ser evaluada hasta más adelante, cuando quede poco
tiempo y ya sea haya gastado mucho dinero.

El proceso de diseño sistema

El diseño del sistema es un proceso mediante el que se traducen los requisitos en una
representación del software, que se acerca mucho al código fuente. Desde el punto de
vista de la gestión del proyecto, el diseño del software se realiza en dos etapas: el
diseño preliminar y el diseño detallado.

 El diseño preliminar se centra en la transformación de los requisitos en los

datos y la arquitectura del software.
 El diseño detallado se ocupa del refinamiento y de la representación
arquitectónica que lleva a una estructura de datos refinada y a las
representaciones algorítmicas del software.

Además del diseño de datos, del diseño arquitectónico y del desarrollo procedimental,
muchas aplicaciones modernas requieren un diseño de la interfaz.
Diseño y calidad del software

A lo largo del proceso de diseño, la calidad del diseño se evalúa mediante una serie
de revisiones técnicas formales (RTF) que son una actividad de garantía del
software cuyos objetivos son:

1. Descubrir los errores en la función, la lógica o la implementación de cualquier

representación del software.
2. Verificar que el software alcanza sus requisitos.
3. Garantizar que el software se ha representado según los estándares
establecidos.
4. Conseguir un software desarrollado de forma uniforme.
5. Hacer que los proyectos sean manejables.

Cada RTF se lleva a cabo mediante una reunión y sólo tendrá éxito si está bien
planificada, controlada y atendida. A continuación, se listan una serie de criterios para
determinar la calidad del software.

1. Un diseño debe tener una organización jerárquica.

2. Un diseño debe ser modular, es decir, el software debe estar dividido en
elementos que realicen funciones específicas.
3. Un diseño debe tener representaciones distintas y separadas de los datos y de
los procedimientos.
4. Un diseño debe llevar a módulos que exhiban características funcionales
independientes.
5. Un diseño debe conducir a interfaces que reduzcan la complejidad de las
conexiones entre los módulos y el exterior.
6. Un diseño debe obtenerse mediante un método que sea reproducible y que esté
dirigido por la información obtenida durante el análisis de requerimientos.

Un buen diseño de software no se consigue fácilmente, se requiere de la aplicación de

principios fundamentales de diseño, de una metodología sistemática y de una revisión
exhaustiva.
UNIDAD II METODOLOGÍA DE DISEÑO DE SOFTWARE

La necesidad de una metodología de desarrollo

Maddison [1983] define metodología como un conjunto de filosofías, etapas,

procedimientos, reglas, técnicas, herramientas, documentación y aspectos de
formación para los desarrolladores de sistemas de información.

Piattini [1996], llega a la definición de metodología de desarrollo como “un conjunto de

procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los
desarrolladores a realizar nuevo software”. Sintetizando lo anterior el autor dice que
una metodología “representa el camino para desarrollar software de una manera
sistemática”.

Las metodologías persiguen tres necesidades principales:

 Mejores aplicaciones, conducentes a una mejor calidad.

 Un proceso de desarrollo controlado.
 Un proceso normalizado en una organización, no dependiente del personal.

Los procesos se descomponen hasta el nivel de tareas o actividades elementales,

donde cada tarea está identificada por un procedimiento que define la forma de
llevarla a cabo. Para aplicar un procedimiento se pueden usar una o más técnicas,
ACTIVIDAD. Socializar y destacar los aspectos más relevantes del anexo 3:
MODELOS DEL CICLO DE VIDA DEL SOFTWARE. Formar grupos de trabajo y preparar
una exposición sobre el tema.

pudiendo ser gráficos con textos.

Características y clasificación de las metodologías
Se pueden enumerar una serie de características [Piattini, 1996] que debe tener la
metodología y que influirán en el entorno de desarrollo:

 Reglas predefinidas
 Determinación de los pasos del ciclo de vida
 Verificaciones en cada etapa
 Planificación y control
 Comunicación efectiva entre desarrolladores y usuarios.
 De fácil comprensión
 Soporte de herramientas automatizadas.
 Qué permita definir mediciones que indiquen mejoras
 Qué permita modificaciones
 Qué soporte reusabilidad del software
Metodologías para desarrollo de software
Un proceso de software detallado y completo suele denominarse “Metodología”. Las
metodologías se basan en una combinación de los modelos de proceso genéricos
(cascada, evolutivo, incremental, etc.). Adicionalmente una metodología debería
definir con precisión los artefactos, roles y actividades involucrados, junto con prácticas
y técnicas recomendadas, guías de adaptación de la metodología al proyecto, guías
para uso de herramientas de apoyo, etc. Habitualmente se utiliza el término “método”
para referirse a técnicas, notaciones y guías asociadas, que son aplicables a una (o
algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de
métodos de análisis y/o diseño.
La comparación y/o clasificación de metodologías no es una tarea sencilla debido a la
diversidad de propuestas y diferencias en el grado de detalle, información disponible
y alcance de cada una de ellas. A grandes rasgos, si tomamos como criterio las
notaciones utilizadas para especificar artefactos producidos en actividades de análisis
y diseño, podemos clasificar las metodologías en dos grupos: Metodologías
Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su
filosofía de desarrollo, aquellas metodologías con mayor énfasis en la planificación y
control del proyecto, en especificación precisa de requisitos y modelado, reciben el
apelativo de Metodologías Tradicionales. Otras metodologías, denominadas
Metodologías Ágiles, están más orientadas a la generación de código con ciclos muy
cortos de desarrollo, se dirigen a equipos de desarrollo pequeños, hacen especial
hincapié en aspectos humanos asociados al trabajo en equipo e involucran
activamente al cliente en el proceso. A continuación se revisan brevemente cada una
de estas categorías de metodologías.

Metodologías estructuradas
Los métodos estructurados comenzaron a desarrollarse a fines de los 70’s con la
Programación Estructurada, luego a mediados de los 70’s aparecieron técnicas para
el Diseño (por ejemplo: el diagrama de Estructura) primero y posteriormente para el
Análisis (por ejemplo: Diagramas de Flujo de Datos). Estas metodologías son
particularmente apropiadas en proyectos que utilizan para la implementación
lenguajes de 3ra y 4ta generación.

Metodologías orientadas a objetos

Su historia va unida a la evolución de los lenguajes de programación orientada a
objeto, los más representativos: a fines de los 60’s SIMULA, a fines de los 70’s
Smalltalk-80, la primera versión de C++ en 1981 y actualmente Java o C# de Microsoft.
A fines de los 80’s comenzaron a consolidarse algunos métodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Método Unificado con la ambiciosa idea de
conseguir una unificación de sus métodos y notaciones, que posteriormente se
reorienta a un objetivo más modesto, para dar lugar al Unified Modeling Language
(UML), la notación OO más popular en la actualidad.
Algunos métodos OO con notaciones predecesoras de UML. Algunas metodologías
orientadas a objetos que utilizan la notación UML son: Rational Unified Process (RUP),
OPEN, MÉTRICA (que también soporta la notación estructurada).

Metodologías tradicionales (no ágiles)

Las metodologías no ágiles son aquellas que están guiadas por una fuerte
planificación durante todo el proceso de desarrollo; llamadas también metodologías
tradicionales o clásicas, donde se realiza una intensa etapa de análisis y diseño antes
de la construcción del sistema.
Todas las propuestas metodológicas antes indicadas pueden considerarse como
metodologías tradicionales. Aunque en el caso particular de RUP, por el especial
énfasis que presenta en cuanto a su adaptación a las condiciones del proyecto
(mediante su configuración previa a aplicarse), realizando una configuración
adecuada, podría considerarse Ágil.

Metodologías ágiles
Un proceso es ágil cuando el desarrollo de software es incremental (entregas
pequeñas de software, con ciclos rápidos), cooperativo (cliente y desarrolladores
trabajan juntos constantemente con una cercana comunicación), sencillo (el método
en sí mismo es fácil de aprender y modificar, bien documentado), y adaptable (permite
realizar cambios de último momento) [11].
Entre las metodologías ágiles identificadas en [11]:
 XP - Extreme Programming .
 Scrum
 Familia de Metodologías Crystal.
 Feature Driven Development
 Proceso Unificado Rational, una configuración ágil
 Dynamic Systems Development Method.

Debido a la complejidad y envergadura del trabajo requerido para analizar, diseñar e

implantar un sistema de informático se necesita para hacerlo con eficiencia se
planifique, ejecute y controle de acuerdo a ciertas reglas, leyes y principios que por un
lado organicen el trabajo de forma adecuada y por otro garanticen que el trabajo del
análisis y diseño se apliquen principios fundamentales de la teoría de sistemas.

El enfoque sistémico
Análisis del medio ambiente
Definición exacta de los límites del sistema
La consideración de la flexibilidad necesaria en el nuevo sistema para asimilar
la dinámica del Objeto de dirección y del propio sistema de información
El hombre como elemento fundamental
La inclusión de los medios de control necesarios para garantizar el equilibrio del
 sistema
El trabajo del diseñador es creativo en gran parte, pues son diseñados para objetivos
específicos y sin reglas rígidas, sin embargo es posible establecer una estructura
que contenga ciertas normas aplicables a los recursos, organización, técnicas,
métodos y procesos durante los cuales el trabajo de sistematización puede hacerse
más eficiente, debiendo ser flexible para no impedir la creatividad del sistematizador.

Conclusiones de las metodologías.

Independientemente del paradigma que se utilice, del área de aplicación, y del

tamaño y la complejidad del proyecto, el proceso de desarrollo de software contiene
siempre una serie de fases genéricas, existentes en todos los paradigmas. Estas fases
son la definición, el desarrollo y el mantenimiento.

1) Definición.

La fase de definición se centra en el qué. Durante esta fase, se intenta identificar:

 qué información es la que tiene que ser procesada.

 qué función y rendimiento son los que se esperan.
 qué restricciones de diseño existen.
 qué interfaces deben utilizarse.
 qué lenguaje de programación, sistema operativo y soporte hardware van
a ser utilizados.
 qué criterios de validación se necesitan para conseguir que el sistema
final sea correcto.

Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado
(cascada, espiral, evolutivo e incremental), en general se realizarán cuatro tareas
específicas:

Análisis del sistema.

El análisis del sistema define el papel de cada elemento de un sistema informático,

estableciendo cuál es el papel del software dentro de ese sistema.

Es la fase de diseño externo. Consiste en cuestionar al usuario sobre qué hace el

sistema, qué características extras él quiere en su nuevo sistema y qué restricciones
debe satisfacer. La salida del análisis debe incluir una especificación funcional y un
análisis estructurado que contiene los requerimientos para el nuevo sistema, los
cuales el usuario debe leer, analizar y señalar lo que él quiere

Reconocimiento del problema: La idea de desarrollar un nuevo sistema surge

cuando el usuario reconoce que tiene problemas con los medios con que cuenta
actualmente para llevar a cabo su trabajo. Así comienza esta fase que trata de
reemplazar el sistema existente (ya sea manual o automatizado) por otro. En esta
fase interviene totalmente el usuario

Planificación del proyecto software.

Durante esta etapa se lleva a cabo el análisis de riesgos, se definen los recursos
necesarios para desarrollar el software y se establecen las estimaciones de tiempo y
costes. El propósito de esta etapa de planificación es proporcionar una indicación
preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que
se hayan establecido. Posteriormente, la gestión del proyecto durante el desarrollo del
mismo realiza y revisa el plan de proyecto de software.

Estudio de la factibilidad: Se decide si el usuario necesita o no una computadora.

Este estudio sirve para:

Identificar los problemas con el sistema actual.

Identificar el alcance del sistema a ser estudiado.
Identificar los principales objetivos del nuevo sistema.
Identificar un número de soluciones que pueden satisfacer las necesidades del
usuario dentro de su esquema.
Desarrollar estimados de los beneficios y desventajas de cada solución.
Desarrollar esquemas de cómo puede llevarse a cabo el proyecto teniendo una
idea de los recursos que se requieren.
Obtener puntos de vista del usuario y el administrador sobre las modificaciones.
Obtener una decisión de si se lleva a cabo la parte de análisis.

Todo este estudio evitará el gasto de un análisis de un proyecto imposible. En él

intervienen el usuario y el analista. (Ver anexo 5)

2) Desarrollo.

La fase de definición se centra en el cómo.

cómo ha de ser la arquitectura de la aplicación.

cómo han de ser las estructuras de datos.
cómo han de implementarse los detalles de procedimiento de los módulos.
cómo van a ser los interfaces.
cómo ha de traducirse el diseño a un lenguaje de programación.
cómo van a realizarse las pruebas.

Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de
vida utilizado, en general se realizarán cuatro tareas específicas:
Diseño.

El diseño del software traduce los requisitos a un conjunto de representaciones

(gráficas, en forma de tabla o basadas en algún lenguaje apropiado) que describen
cómo van a estructurarse los datos, cuál va a ser la arquitectura de la aplicación,
cuál va a ser la estructura de cada programa y cómo van a ser las interfaces. Es
necesario seguir criterios de diseño que nos permitan asegurar la calidad del
producto. Es la fase de diseño interno. Posteriormente se lleva a cabo un diseño
detallado donde se describen las especificaciones de los módulos. Una vez finalizado
el diseño es necesario revisarlo para asegurar la completitud y el cumplimiento de los
requisitos del software.

Codificación.

En esta fase, el diseño se traduce a un lenguaje de programación, dando como

resultado un programa ejecutable. La buena calidad de los programas desarrollados
depende en gran medida de la calidad del diseño. Una vez codificados los programas
debe revisarse su estilo y claridad, y se comprueba que haya una correspondencia con
la estructura de los mismos definida en la fase de diseño. El listado fuente de cada
módulo (o el programa fuente en soporte magnético) pasa a formar parte de la
configuración del sistema.

Pruebas.

Una vez que tenemos implementado el software es preciso probarlo, para detectar
errores de codificación, de diseño o de especificación. Las pruebas son necesarias
para encontrar el mayor número posible de errores antes de entregar el programa al
cliente.

Garantía de calidad.

Una vez terminada la fase de pruebas, el software está casi preparado para ser
entregado al cliente.

3) Mantenimiento.

La fase de mantenimiento se centra en los cambios que va a sufrir el software a lo

largo de su vida útil. Como ya hemos dicho, estos cambio pueden deberse a la
corrección de errores, a cambios en el entorno inmediato del software o a cambios en
los requisitos del cliente, dirigidos normalmente a ampliar el sistema. La fase de
mantenimiento vuelve a aplicar los pasos de las fases de definición y de desarrollo,
pero en el contexto de un software ya existente y en funcionamiento.

UNIDAD III DISEÑO DE SISTEMAS

Es la transformación de las especificaciones funcionales de un sistema, en un modelo

que defina "Como" se va a lograr su implementación física.

Aplicando el enfoque de sistemas, tenemos:

1. Definir la estructura inicial.

2. Diseñar los módulos y/o ventanas.
3. Terminar la base de datos.
4. Diseñar entradas y salidas.
5. Generar el prototipo.
6. Revisar el diseño.

Importancia del diseño.

 Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el
trabajo por realizar en la etapa de construcción.
 Define claramente los componentes que tendrá el nuevo sistema, a nivel de
bases de datos, procesos e interfaces.
 “Descubre” la estructura física que tendrá el nuevo sistema.
 Toma en cuenta el diseño de formatos tanto de entrada de datos, como de
salidas del propio sistema.
 Proporciona una visión inicial para los usuarios, de cómo será su interacción
con el sistema, a través de los prototipos.
 Da claridad para definir la arquitectura necesaria que soportará al nuevo
sistema.

Características del diseño.

 Es una representación abstracta del sistema, que plantea una solución que será
implementada luego.
 Se preocupa de la "forma" del sistema en todos sus aspectos, definiendo con
todo el detalle cómo se iría a obtener esa forma planteada. Para esto es
necesario desarrollar ciertas actividades como:
 ABSTRACCIÓN: Generalizar un problema con el fín de asignar
prioridades a su solución y establecer una jerarquía.
 OPERACIONALIDAD: Convertir la estructura generada en algo realizable
y funcional.
 VERIFICACIÓN: Comprobar que se cumple con lo especificado en el
 análisis.
 Es una etapa limitada por el ambiente tecnológico de hardware y software
existente en la organización.
 Busca que la construcción del sistema se vuelva más rutinaria y elemental.
 La estructura a diseñar debe ser modular, donde cada módulo exhiba
características funcionales independientes.
 Un buen diseño debe ser :
 COMPLETO : Debe abarcar todos los requerimientos planteados
anteriormente.
 CONSISTENTE : Se deben definir bien las interfaces con otros sistemas.
 CLARO : Que sea fácil de traducir a un lenguaje de programación.
 MANTENIBLE : Que evalúe la posibilidad de modificaciones futuras.
 PRACTICO : Que pueda ser realizable fácilmente, con las herramientas
tecnológicas existentes en la organización.
 EVALUABLE : Que permita revisarse y mejorarse.

Participación requerida.

Es una etapa muy técnica que requiere gran participación del personal de sistemas y
del usuario, en lo que respecta a evaluaciones de prototipos y de diseño de pantallas
(ventanas) del nuevo sistema.

Analistas. Elaboran las especificaciones del diseño, con base en el análisis elaborado
anteriormente. El papel que desempeña en ésta etapa el analista de sistemas, es el
de diseñador. La habilidades de un buen diseñador difieren algo de las del analista.
Veamos: Se debe enfocar a la tecnología, sin olvidar los procesos definidos en el
análisis, mientras el analista hace lo contrario. Se enfrenta con la tarea de traducir los
requerimientos del negocio a la tecnología disponible en la organización.

Un buen diseñador es creativo, lleno de recursos e inteligente para evaluar opciones

entre soluciones que no son perfectas. Las habilidades de un diseñador estan más
cercanas a las de un programador, ya que se debe tener claro el ambiente tecnológico,
para poder sacar el mayor provecho de él.

Usuarios. Aprueban aspectos como operación del sistema, diseño de entradas y

salidas, diseño de archivos y funcionalidad del sistema (Interfase de usuario).
Pasos en el desarrollo del diseño.

Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en
el diseño de un sistema de información. Cada una de estas tareas debe estar
claramente documentada, en el manual de desarrollo del sistema.
Descomposición funcional de módulos.

Esta técnica es la empleada para elaborar la estructura del sistema. Consiste en

descomponer en forma sucesiva un módulo en otros módulos de más baja jerarquía,
hasta lograr el detalle suficiente en la asignación de funciones a estos. Reglas para la
descomposición:

 Cualquier estructura tendrá un módulo general o coordinador.

 Cada módulo, si lo requiere, se subdividirá en otros.
 Cada módulo subordinado, será coordinado por sus padres (un módulo puede
tener varios padres).
 Deben existir por lo menos dos módulos al mismo nivel de descomposición.
Ejemplo:
De la anterior estructura podemos observar :
 Siempre existe un módulo coordinador. En éste caso es el módulo llamado S.I.
NOMINA.
 No todos los módulos se descomponen al mismo nivel, como es el caso de
PRODUCIR CHEQUES, que sólo tiene un nivel de descomposición. Un módulo
se debe descomponer, hasta obtener una medida alta de cohesión en la
función que realiza.
 En primera instancia se está tratando de utilizar los mismos módulos tanto para
el cálculo de devengados, como para el de deducciones, con el objetivo de
ahorrar más tarde, tiempo de construcción. Obviamente, se debe mirar si esto
es posible, a la luz del concepto de acople, que veremos más tarde.
 Existe un módulo, cuya descomposición está mal enfocada, dado que sólo se
subdivide en otro módulo, lo que atenta contra las reglas antes mencionadas.
Tal módulo es el denominado EXTRACTAR BÁSICO.
Diseño de módulos. (Diseño detallado).
Es la descripción y representación detallada de cómo cada módulo de la estructura
definida, ejecutará su trabajo con el fin de facilitar el proceso de construcción. Es
básico en este punto, retomar las especificaciones de proceso o mini especificaciones
desarrolladas en el análisis, ya que el diseño de módulos, no es más que un
refinamiento de la especificación de proceso elaborada anteriormente.
 UNIDAD IV

DISEÑO DEL MODELO CONCEPTUAL DE DATOS

El propósito de la metodología de diseño es

facilitar el propósito de diseño y servir de
soporte de la base de datos mediante la
utilización de procedimientos, técnicas,
herramientas ya ayudas para la generación
de documentación.

Cuando se trabaja bajo el análisis conceptual

de una situación, nos referimos a la
abstracción de hechos reales de los cuales se
emite un concepto o es posible hacer una
idea de ello. Para poder realizar la
abstracción de un tema en un área específica,
a nivel informático, es necesario tener los
requerimientos formulados por los usuarios
con respecto a este. Estos requerimientos
contienen el conjunto de hechos y reglas que
dan pauta a la creación del esquema
conceptual donde por medio de este se podrá
realizar una descripción de alto nivel de la
futura base de datos. Para manipular este
esquema se utiliza un modelo conceptual que
proporciona un lenguaje que permite utilizar
un conjunto de símbolos (estándares) para la
creación de este.

Fases del diseño de base de datos

 Diseño conceptual.- es la construcción de un modelo que represente todos los

datos utilizados en una organización independientemente de las
consideraciones físicas
 Diseño lógico.- construir un modelo de la organización basados en un modelo
de datos específicos, relacionar el modelo conceptual con el lógico
 Diseño físico.- generar de cómo va a ser la implementación de la base de datos
dependiendo de la el SGBD que se vaya a utilizar

Diseño conceptual
El diseño conceptual se hace independiente al sistema gestor de base de datos
(DBMS) que utilice el usuario para la implementación de esta.
Ver video: https://www.youtube.com/watch?v=THyQ-hhuOx4
Para modelar Conceptualmente es posible utilizar varios Modelos de Datos Un modelo
práctico para ilustrar el diseño conceptual es el modelo entidad relación.

Conceptos del Modelo entidad relación - MER:

Entidades: Una entidad es una "cosa" u "objeto" del mundo real, con existencia
independiente y distinguible de los demás objetos. Cada entidad tiene un conjunto de
propiedades y valores que la identifican de forma unívoca. Esta puede ser tanto
tangible (existencia física), ejemplo: Un carro, como intangible (existencia
conceptual), ejemplo: Un curso universitario.

Atributos: Las propiedades que califican y le dan vida a la entidad se denominan

atributos. Ejemplo: la entidad persona se puede describir por las siguientes
propiedades: cédula, nombre, dirección, sexo, peso, altura, color, tipo de sangre,
salario.

1. PASO 1 CONSTRUIR UN DISEÑO CONCEPTUAL DE LOS DATOS.

 Identificar los tipos de entidad

 Identificar los tipos de relación
 Identificar y asociar los atributos con los tipos de entidad y relación.
 Determinar los dominios de los atributos
 Determinar los atributos de clave candidata, principal y alternativa.
 Determinar el uso de los conceptos de modelado avanzado.
 Comprobar si el modelo tiene redundancia.
 Validar el modelo conceptual comprobando las transacciones de los usuarios
 Repasar el modelo de datos conceptual con los usuarios.
 Identificar las entidades.
Diseño lógico. Se utiliza el modelo relacional. En el diseño lógico desaparecen las
relaciones de muchos a muchos y se indican las llaves primarias y segundarias.

Ver video: https://www.youtube.com/watch?v=_SADhrQD5bY

Diseño físico. Es la base de datos final utilizada en un

SGBD. Ver video:

https://www.youtube.com/watch?v=dniZcgxyWhw

Diferencias entre el diseño conceptual y lógico

 El modelo conceptual es independiente del DBMS que se vaya a utilizar. El
lógico depende de un tipo de SGBD en particular.
 El modelo lógico es más cercano al ordenador
 Es más cercano al usuario el modelo conceptual, el lógico forma el paso entre
el informático y el sistema.
Diccionario de datos

TAREA. Desarrollar el diseño físico de la base de datos, es decir los modelos:

entidad relación y modelo relacional. Además se debe incluir el diccionario de
datos. Trabajar los mismos grupos de la tarea anterior.

UNIDAD V

DISEÑO DE LOS PROCESOS

Ayuda a comprender el trabajo como un proceso y a identificar en qué parte del
proceso está el problema.

Es muy importante comprender que cada paso en el proceso crea relaciones o

dependencias entre unos y otros para lograr la realización del trabajo. Cada paso del
proceso depende en uno o varios proveedores de materiales o servicios y en algunos
casos de información o recursos, los cuales deben ser: confiables, libres de defectos,
oportunos y completos.

En contraposición, aquellos que son los receptores del o de los productos del proceso
deben asentar claramente sus requerimientos y dar a conocer cuando no están
recibiendo lo esperado.

Es también muy importante que el diagrama de flujo sobre el que se haga el análisis
de cualquier proceso se encuentre al día, ya que si no es así puede desvirtuar la
identificación de problemas reales. Cada proceso es un sistema y debe ser tratado de
tal manera con todas las partes con las que conecta. Si se cambia una de las partes
del subsistema siempre se verá afectado el cómo actúa el sistema en su totalidad.

¿Cómo se elabora?
 Valide el diagrama de flujo y las medidas de desempeño del mismo con los
propietarios o los que llevan a cabo el proceso y con los usuarios del mismo.
Antes de que un equipo pueda mejorar algún proceso, necesitan entenderlo.
 Las personas que pueden evaluarlo son las que participan en el proceso o
reciben algún producto, servicio o información de él.
 Se puede llevar a cabo un proceso de chequeo bajo los siguientes
considerandos: Se debe confirmar la precisión del proceso conforme se
desarrolla el diagrama de flujo, así como el tiempo estimado/ real de cada paso,
tal como se lleva a cabo actualmente.
 Enliste todos los pasos del proceso como se están realizando. Mantenga tan
simple como sea posible su descripción.
 Se debe identificar y registrar el valor, tiempo invertido y costo de cada paso en
el proceso.
 Utilice símbolos para mostrar el flujo de las acciones y decisiones involucradas
en el proceso de principio a fin. La simbología básica es la siguiente:
Ejemplos de Diagramas de procesos.
 DISEÑO DE LAS INTERFACES DE ENTRADA DE DATOS
Se define aquí, con todo el grado de detalle, cómo serán los documentos de entrada
requeridos por el sistema, las diferentes pantallas de diálogo, las salidas generadas,
todas las consultas y reportes emitidos, los formatos de salida y las diferentes
interfases con otros sistemas.
Es una tarea que se ocupa mucho de la forma, dado el carácter gráfico de la tecnología
usada. Se deben tener estándares claros de diseño, para evitar que cada analista
realice a su amaño estas definiciones. Si no se tiene estándares, es conveniente hacer
un alto en este punto y definirlos claramente, para evitar ambigüedades en la
presentación y diseño del sistema.
Es conveniente seguir los lineamientos que ofrece la tecnología Windows, ya que
éstos son estándares a nivel mundial.

DISEÑO DE DOCUMENTOS FUENTES.

Se hacen basados en el contenido de los flujos de datos de entrada del sistema,

descritos en el diccionario de datos. Se debe tener en cuenta :
 En el encabezado del documento
 Logotipo de la Organización.
 Nombre de la Organización.
 Nombre del departamento, sección o división.
 Código del documento.
 Número del documento.
 En el cuerpo del documento :
 Presentar un orden lógico de campos, de acuerdo con el orden de los datos que
muestran las pantallas.
 Mostrar una descripción clara de cada campo a diligenciar.
 Permitir suficiente espacio para diligenciar cada campo.
 Manejar una presentación agradable y armónica.
 Permitir un espacio para posibles observaciones.

Diseño de ventanas.
Las ventanas son la forma básica de comunicación con el usuario y la unidad de
programación a tener en cuenta en la construcción. Se deben diseñar, teniendo en
cuenta los estándares antes mencionados y el tipo de ventana (entrada de datos,
consultas, de menú, etc.). Se debe tener en cuenta:

 Mostrar información que indique dónde se encuentra el usuario. Debe incluir:

 Nombre del sistema.
 Nombre de la ventana.
 Posibilidad de maximizar, minimizar o redimensionar la ventana.
 Posibilidad de personalizarla.
 Permitir líneas de mensajes de ayuda y de error.
 Mostrar los mensajes resaltados y en cajas de diálogo.
 Otorgar un primer nivel de ayuda en la línea de ayudas para cada opción.
 El orden de datos en la pantalla debe ser claro y asemejarse al orden de los
datos en los documentos fuentes.

La tecnología actual direcciona el diseño de las ventanas, hacia la utilización de

herramientas gráficas, por sus ventajas comparativas con otras tecnologías. Dicha
técnica se conoce en el mercado con el nombre de GUI (Graphical User Interface) o
Interfase Gráfica de Usuario. El reto consiste en elaborar interfaces que estén bien
diseñadas, satisfagan las necesidades del negocio y satisfagan las expectativas cada
vez mayores de los usuarios. Algunos criterios a tener en cuenta en el diseño de GUI,
son :

Control del Usuario: Un buen diseño debe estar direccionado a soportar el hecho de
que el usuario es quien tiene el control en la GUI. El usuario tiene la libertad para
moverse de ventana a ventana y hacer cualquier cosa que desee. La tarea del
diseñador es restringir a lugares donde no puede ir el usuario, más que a los lugares
donde puede acceder.

Una buena aplicación GUI debe tener facilidad para el uso del mouse o para el teclado,
indistintamente. Por ello se deben incluir aspectos como el orden de tabulación y teclas
aceleradoras (hot key) para que cualquier acción que se realce con el mouse, se pueda
realizar también con el teclado.

Sensibilidad: El sistema debe proporcionar retroalimentación tangible e inmediata

para cada acción. Puede ser tan simple como cambiar un apuntador por el reloj de
arena. Se deben usar cuadros de diálogo para indicar errores de usuario, a través de
mensajes claros y entendibles. Nunca mensajes generados por el sistema operativo,
por ejemplo.

Personalización: Se debe permitir personalizar las diferentes ventanas del sistema,

a los diversos tipos de usuarios que las acceden, teniendo cuidado de modificar
algunos aspectos como colores, ocultamiento de columnas, etc.

Dirección: Se debe tener presente que la memorización de comandos no aplica bajo

GUI. Especialmente el hecho de ubicar un objeto en el sistema, debe ser tan intuitivo
como señalarlo con el mouse y realizar la operación deseada con el objeto. Algo así
como “apunte y dispare”.

Se pueden usar para tal propósito iconos y barras de herramientas que aclaren la
ubicación de los diferentes objetos existentes.

Consistencia: El sistema deberá ser consistente con el mundo en que los usuarios
viven y trabajan diariamente. Para ello se debe usar el vocabulario que manejan los
usuarios y tratar de estandarizarlo a lo largo de todo el sistema, para que la GUI sea
entendible por ellos.

Una clave aquí de estándares, es tratar de mantener los definidos en aplicaciones de

uso general como Word y Excel, que siempre tratan de mostrar la misma interface para
el usuario.

Claridad: La información presentada en la interface debe ser inmediatamente

comprensible y el uso de la aplicación debe ser visualmente evidente. Se deben usar
tablas de control a través de listas desplegables para dar mayor información a los
usuarios, cuando se necesitan digitar datos como por ejemplo, sexo, estado civil,
departamento, etc.

Estética: La composición y disposición de una ventana debe ser visualmente

agradable. Deberá atraer la vista hacia la información que es más importante. El ojo
humano ve primero la parte izquierda superior del centro de la pantalla y hace un
barrido en el sentido de las agujas del reloj. Se debe tener especial cuidado con los
colores a usar, el tipo de letra, el tamaño de la misma. No se deben presentar ventanas
muy atiborradas de objetos ; es mejor dividirlas en otras ventanas, para evitar
confusiones.
Tipos de Ventanas

Ventana Principal o de Aplicación.

 Es la ventana más común.
 Es independiente de cualquier otra ventana.
 Puede traslapar y ser traslapada por otras ventanas.
 Es movible, redimensionable, puede ser minimizada.
 Generalmente tienen un menú.

Ventana Desplegable.
 Conocida con el nombre de Pop Up.
  Aparece por encima de la ventana que la llama.
 Se abre desde una ventana existente, llamada Ventana Madre.
 No puede ser traslapada por su madre.
 Puede existir después de que se cierra la ventana madre.

Ventana Hija.
 Es muy similar a una ventana desplegable, pero más restrictiva.
 Se abre a partir de una ventana madre.
 No puede ser traslapada por la ventana madre.
 No puede ser arrastrada fuera del marco de la ventana madre.
 No puede existir después de cerrar la ventana madre.

Ventana de Respuesta.
  Es la más restrictiva de todas las ventanas.
 No se libera sino hasta que se cierra.
 No es minimizable ni redimensionable.
 Se usa para forzar al usuario a través de una ruta particular.

Ventana MDI. Traduce: Marco de Interface para Documentos Múltiples. Es un espacio

de trabajo redimensionable y auto contenido que opera como una ventana principal.
 Viene con un menú.
 Las ventanas que se abren dentro del marco son llamadas Hojas MDI.
 Las hojas MDI se comportan como ventanas hijas.
 Se pueden acomodar en mosaico, cascada y capas.
 Se pueden abrir varias instancias de la misma hoja.
 Son útiles para dividir sistemas grandes en aplicaciones separadas.

Carpeta con Fichas o Pestañas.

 Conocida como Tab Folder.
 Su apariencia es como el de un archivador manual.
 Útiles para desplegar varios elementos de datos por temas.
 Se accede a cada ficha, con un clic en cada pestaña.
 DISEÑO DE REPORTES.

Se diferencian de los informes, por ser impresos y tener un límite de columnas para su
presentación. Se deben diseñar teniendo en cuenta el contenido de los flujos de datos
de salida definidos en el diccionario de datos. Se debe tener en cuenta:
 En el encabezado de los reportes :
 Presentar el nombre de la empresa.
 Mostrar el nombre del sistema de Información.
 Mostrar el Título del reporte.
 La fecha de elaboración del reporte.
 Paginar el reporte.
 Presentar los nombres completos de los campos a listar.
 Para reportes con totales, mostrar totales generales al finalizar el reporte.
 Distribuir la información en una forma clara, ordenada y armónica.

DISEÑO DE OPERACIÓN DEL SISTEMA (PROTOTIPOS).

Es la tarea clave en lo que respecta a la definición de la forma como van a interactuar

el usuario y el sistema, ya que se define, por parte de los analistas la navegación y
comunicación entre las dos partes. No debemos perder el objetivo de ésta tarea,
tratando de mostrar el sistema funcionando en éste punto. En algunos
establecimientos, la creación de prototipos es una “disculpa” para codificar algo
rápidamente y ver si los usuarios lo aceptan. Busca que los usuarios tengan una idea
de cómo será el diálogo y la navegación a través del sistema y en consecuencia se le
debe aclarar al mismo el objetivo anteriormente expuesto.

Se debe construir un modelo sencillo que muestre cómo será la operación del sistema,
con el fin de probar con el usuario la dinámica, funcionalidad y características de
implementación. Está aceptado generalmente que un prototipo es un modelo a escala
de lo real, pero no tan funcional para que equivalga al producto final. Es la simulación
de cómo quedará funcionando el sistema, para garantizar que se ajustará a las
necesidades del usuario.

Es un proceso de refinamiento en el cual participa activamente el usuario. Involucra

directamente al usuario en el proyecto. Por primera vez el sistema tiene una “cara”.
Inevitablemente, después de ver el prototipo, alguien encontrará un evento que hasta
el momento no se había detectado, añadirá elementos a las ventanas y eliminará otros
innecesarios. Por ello, el prototipo enriquecerá aún más el modelo de información y de
procesos definidos anteriormente.

Una buena idea para construir prototipos es la elaboración de los mismos en papel,
para dar una mayor agilidad a la tarea, dado que ella es recursiva, pues se pretende
mostrar y corregir, hasta obtener un producto totalmente aceptado por los usuarios.
Se debe tener en cuenta:

 Las herramientas de hardware y software disponibles para la construcción.

 La estructura general del sistema.
 Los modelos definidos en el análisis (procesos e información).

El modelo de información es una guía crítica para la disposición de ventanas. El marco

organizacional de los datos está dictado por la cardinalidad de la relación en el
diagrama entidad- relación. Si un pedido tiene varios conceptos de pedido, se podría
esperar una relación encabezado-detalle en la ventana de mantenimiento de pedidos:

Los
diferentes módulos del sistema.
 Algunas características propias del usuario:
 Usuarios dedicados (Exigen poca documentación y capacitación).
 Usuarios casual (Desean un sistema amistoso y detallado).
 Grado de escolaridad.
  Funciones que desarrolla en la organización.
 Nivel de jerarquía.
 No mostrar características que no se puedan luego implementar.
 No se debe comenzar a construir el sistema, con la creación temprana de
prototipos.

Corregir los modelos de procesos e información, si surgen comentarios con la

exposición del prototipo.

PUNTOS DE VISTA EN UNA INTERFAZ DE USUARIO

El del usuario, el del programador y el del diseñador (analogía de la construcción de

una casa). Cada uno tiene un modelo mental propio de la interfaz, que contiene los
conceptos y expectativas acerca de la misma, desarrollados a través de su
experiencia.

El modelo permite explicar o predecir comportamientos del sistema y tomar las

decisiones adecuadas para modificar el mismo. Los modelos subyacen en la
interacción con las computadoras, de ahí su importancia.

Modelo del usuario: El usuario tiene su visión personal del sistema, y espera que
éste se comporte de una cierta forma. Se puede conocer el modelo del usuario
estudiándolo, ya sea realizando tests de usabilidad, entrevistas, o a través de una
realimentación. Una interfaz debe facilitar el proceso de crear un modelo mental
efectivo.

Para ello son de gran utilidad las metáforas, que asocian un dominio nuevo a uno ya
conocido por el usuario. Un ejemplo típico es la metáfora del escritorio, común a la
mayoría de las interfaces gráficas actuales.

Principios de Diseño de las interfaces de usuario

 Familiaridad del usuario: Utilizar términos y conceptos que se
toman de la experiencia de las personas que más utilizan el sistema.
 Consistencia: Siempre que sea posible, la interfaz debe ser
 consistente en el sentido de que las operaciones comparables se activan de la
misma forma.
 Mínima sorpresa: El comportamiento del sistema no debe
provocar sorpresa a los usuarios.
 Recuperabilidad: La interfaz debe incluir mecanismos para
permitir a los usuarios recuperarse de los errores. Esto puede ser de dos
formas:
 Confirmación de acciones destructivas.
 Proveer de un recurso para deshacer. El recurso deshacer
restablece el sistema al estado previo antes de que ocurriera la
acción.
 Guía al usuario: Cuando los errores ocurren, la interfaz debe
proveer retroalimentación significativa y características de ayuda
sensible al contexto.
 Diversidad de usuarios: La interfaz debe proveer características
de interacción apropiada para los diferentes tipos de usuarios.
Consideraciones importantes en el diseño de interfaces

Antes de abordar el proceso de diseño de interfaz del usuario se deben tratar algunas
consideraciones en el diseño que tienen que ser tomados en cuenta por los
diseñadores de interfaces de usuarios.

Interacción del usuario: Una interfaz coherente debe integrar la interacción del
usuario y la presentación de la información. Shneiderman (1998) clasifica la interacción
en 5 estilos primarios:

Manipulación directa: Interacción directa con los objetos de la pantalla, Rápida e

intuitiva, Fácil de aprender, Ejemplo: para borrar un archivo, el usuario lo arrastra al
bote de basura. Videos de juegos, Puede ser difícil de implementar, Sólo es adecuada
donde hay una metáfora visual para las tareas y objetos.
Selección de menús: El usuario selecciona un comando de una lista de posibilidades.
Evita errores del usuario, Se requiere teclear poco, Lenta para usuarios
experimentados, Puede llegar a ser complejo si existen muchas opciones en el menú,
Ejemplo: muchos de los sistemas de propósito general.

Llenado de formularios: Introducción de datos sencilla en los campos de un

formulario, Fácil de aprender, Ocupa mucho espacio en la pantalla, Ejemplo: ingreso
datos del cliente

Lenguaje de comandos: Los usuarios emiten un comando especial y los parámetros

asociados para indicar al sistema que hacer, Poderoso y flexible, Difícil de aprender,
Administración de errores pobre, Ejemplo: Sistemas operativos

Lenguaje Natural: El usuario emite comandos en lenguaje natural, Accesible a

usuarios casuales, Fácil de ampliar, Se requiere teclear más, Los sistemas de
comprensión de lenguaje natural no son fiables, Ejemplo: Sistemas de horarios,
sistemas www de recuperación de la información.

VENTAJAS Y DESVENTAJAS DE LOS ESTILOS DE INTERACCIÓN

Estilo de Principales
Principales Desventajas Ejemplo de Aplicación
Interacción Ventajas
Puede ser difícil de
Interacción implementar. Solo es adecuadas
Manipulación
rápida e intuitiva donde existe una metáfora Videos juegos, sistemas
Directa
fácil de aprender visual para las tareas CAD.
y objetivos.
Evitar errores de Lenta para usuarios
La mayoría de los
Selección de los usuarios. Se experimentales. Puede llegar a
sistemas de propósitos
menú. requiere tipear ser compleja si existen muchas
general.
poco. opciones en el menú.
Ocupa mucho espacio en la
pantalla. Causa problemas Control de stock.
Relleno de Introducción de
cuando las opciones del usuario Procesamiento de
formularios. datos sencillos.
no se ajustan a los préstamos personales.
campos del formulario.
Sistemas operativos.
Lenguaje de Poderosos y Difícil de aprender. Gestión
Sistemas de comandos
comandos flexibles pobre errores.
y control.
Accesibilidad a
Se requiere teclear más. Los Sistemas de
Lenguaje usuarios
sistemas de comprensión de recuperación de
natural causales. Fácil
lenguaje natural no son fiables. información.
de ampliar.
Tipos de interfaces de usuario
Dentro de las Interfaces de Usuario se puede distinguir básicamente los
siguientes tipos:
A) Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar,
procesar y entregar los datos: teclado, ratón y pantalla visualizadora.
B) Una interfaz de software, destinada a entregar información acerca de los
procesos y herramientas de control, a través de lo que el usuario observa
habitualmente en la pantalla.
C) Una interfaz de Software-Hardware, que establece un puente entre la máquina
y las personas, permite a la maquina entender la instrucción y a el hombre entender el
código binario traducido a información legible.

Según la forma de interactuar del usuario

Atendiendo a como el usuario puede interactuar con una interfaz, nos
encontramos con varios tipos de interfaces de usuario:

Interfaces de lenguaje natural

Las interfaces de lenguaje natural son quizás el sueño e ideal de usuarios
inexpertos, debido a que permiten a usuarios interactuar con la computadora en su
lenguaje cotidiano o natural. No se requieren habilidades especiales de usuarios,
quienes interactúan con la computadora mediante lenguaje natural.

Mencione todos los vendedores de quienes se conocen

sus cuotas este Mes:
María González

María Alvarado

Sulimar Pastran

Compare el porcentaje de vegetales podridos en cada

uno de nuestros almacenes:
Fair Oaks 4%
La pantalla descrita en la figura anterior se menciona tres preguntas de lenguaje
natural de tres aplicaciones diferentes. Observe que la interacción con cada una
parece muy fácil. Por ejemplo, la primera frase —"Mencione todos los vendedores de
quienes se conocen sus cuotas este mes"— parece sencilla.
Las sutilezas e irregularidades que residen en las ambigüedades del lenguaje natural
producen un problema de programación sumamente exigente y complejo. Los intentos
por interactuar con lenguaje natural para algunas aplicaciones en las cuales cualquier
otro tipo de interfaz no es factible (por decir, en el caso de un usuario que está
incapacitado) se está obteniendo con algo de éxito; sin embargo, estas interfaces
normalmente son caras.

Interfaces de pregunta y respuesta

En una interfaz de pregunta y respuesta, la computadora despliega en pantalla
una pregunta para el usuario. Para interactuar, el usuario introduce una respuesta
(mediante pulsaciones del teclado o un clic del ratón) y la computadora después actúa
en esa información de entrada de acuerdo con su programa, normalmente pasando a
la siguiente pregunta.
 En la figura anterior se muestra un tipo de interfaz de pregunta y respuesta
denominado cuadro de diálogo. Un cuadro de diálogo actúa como una interfaz de
pregunta y respuesta dentro de otra aplicación, en este caso un diagrama PERT para
un proyecto de análisis de sistemas para Bakerloo Brothers. Observe que el rectángulo
redondeado para "Sí" está resaltado, lo que indica que es la respuesta más común
para esta situación. La interfaz principal para esta aplicación no necesariamente debe
ser de pregunta y respuesta. Más bien, al incorporar un cuadro de diálogo, el
programador ha incluido una interfaz de fácil uso dentro de una más complicada.

Los asistentes usados para instalar software son un ejemplo común de una interfaz de
pregunta y respuesta. El usuario responde a las preguntas acerca del proceso de
instalación, tal como dónde instalar el software o características. Otro ejemplo común
es el uso del Asistente de Office usado en los productos de Microsoft. Cuando el
usuario necesita ayuda, el Asistente de Office hace preguntas y reacciona a las
respuestas con preguntas adicionales diseñadas para limitar el alcance del problema.
Los usuarios que no están familiarizados con aplicaciones particulares o no están
informados sobre un tema podrían encontrar interfaces de pregunta y respuesta más
cómodas, ganando rápidamente confianza a través de su éxito.
Menús
Una interfaz de menús adquiere apropiadamente su nombre de la lista de platillos
que se pueden seleccionar en un restaurante. De forma similar, una interfaz de menú
proporciona al usuario una lista en pantalla de las selecciones disponibles. En
respuesta al menú, un usuario está limitado a las opciones desplegadas. El usuario no
necesita conocer el sistema pero tiene que saber qué tarea se debe realizar. Por
ejemplo, con un menú típico de procesamiento de texto, los usuarios pueden escoger
opciones para editar, copiar o imprimir. Sin embargo, para utilizar el mejor menú los
usuarios deben saber qué tarea desean desempeñar.

Los menús no dependen del hardware. Las variaciones abundan. Los menús se
establecen para usar el teclado, lápiz óptico o el ratón. Las selecciones se pueden
identificar con un número, carta o palabra clave. La consistencia es importante en el
diseño de una interfaz de menú.
Los menús también se pueden ocultar hasta que el usuario quiera usarlos. La figura
muestra cómo se usa un menú desplegable. Los menús se pueden anidar dentro de
otro para llevar a un usuario a las opciones de un programa. Los menús anidados
permiten a la pantalla aparecer menos desordenada, la cual es consistente con el
adecuado diseño.

También permiten a usuarios evitar ver opciones de menú en las que no están
interesados.
Los menús anidados también pueden mover rápidamente a los usuarios a través del
programa.
Los menús de GUI se usan para controlar el software de PC y tienen los
siguientes lineamientos:
1. Siempre se despliega la barra de menú principal.
2. El menú principal usa palabras simples para los artículos del menú. Las
opciones de menú principales siempre despliegan menús desplegables secundarios.
3. El menú principal debe tener opciones secundarias agrupadas en grupos
similares de características.
4. Los menús desplegables que se presentan cuando se hace clic en un artículo
de menú principal con frecuencia consisten en más de una palabra.
5. Estas opciones secundarias desempeñan acciones o despliegan artículos de
menú adicionales.
6. Los artículos de menú en gris no están disponibles para la actividad actual. Un
menú de objeto, también llamado menú desplegable independiente, se despliega
cuando el usuario hace clic en un objeto de la GUI con el botón derecho del ratón.
Estos menús contienen artículos específicos para la actividad actual y la mayoría es
funciones duplicadas de artículos de menú principales.

Interfaces de formulario (formularios de entrada/salida)

Las interfaces de formulario consisten de formularios en pantalla o formularios

que se basan en la Web que despliegan campos que contienen datos o parámetros
que necesitan ser comunicados al usuario. El formulario a menudo es un facsímil de
un formulario impreso que ya es familiar para el usuario. Esta técnica de interfaz
también se conoce como método basado en el formulario y en formularios de
entrada/salida.

La figura muestra una interfaz de formulario. Un menú desplegable para el Núm. De

la parte introduce automáticamente una Descripción y un Precio de la unidad para el
artículo. Cuando el usuario pasa al campo Cantidad e introduce el número de artículos
a ser comprados, el software calcula automáticamente el Precio extendido
multiplicando la Cantidad y el Precio de la unidad.
Los formularios para las pantallas de despliegue se configuran para mostrar qué
información debe introducirse y dónde. Los campos en blanco requieren información
que se puede resaltar con caracteres inversos o intermitentes. Por ejemplo, el usuario
mueve el cursor de un campo a otro mediante la pulsación de una tecla de flecha. Esta
disposición permite moverse un campo hacia atrás o un campo hacia adelante
oprimiendo la tecla de flecha correspondiente. Los formularios que se basan en la Web
ofrecen la oportunidad de incluir hipervínculos para ejemplos de formularios
completados correctamente o para ayuda extensa y ejemplos.
Interfaces gráficas de usuario
Las interfaces gráficas de usuario (GUIs) permiten la manipulación directa de la
representación gráfica en pantalla, la cual se puede realizar con la entrada del teclado,
una palanca de juego o el ratón. La manipulación directa requiere mayor sofisticación
del sistema que las interfaces vistas anteriormente. La clave para las GUIs es la
retro alimentación constante que proporcionan. La retroalimentación continua en el
objeto manipulado significa que se pueden hacer rápidamente los cambios o incluso
cancelar operaciones sin incurrir en mensajes de error. El concepto de retro
alimentación para los usuarios se discute más a fondo en una sección más adelante.
La creación de GUIs representa un reto, debido a que se debe inventar un modelo
apropiado de realidad o un modelo conceptual aceptable de la representación. El
diseño de GUIs para uso en intranets, extranets y, aún más urgente, en Web, requiere
una planeación más cuidadosa (véase el capítulo 12 en el diseño de sitio Web). En
general, los usuarios de sitios Web son desconocidos para el diseñador, de modo que
el diseño debe ser bien definido. La elección de iconos, lenguaje e hipervínculos se
vuelve un conjunto de decisiones y suposiciones acerca de qué tipos de usuarios del
sitio Web están esperando atraer.
 BIBLIOGRAFÍA

Análisis y Diseño de sistemas autor: Whitenn, Kenneth W; Ingeniería,

edición 2003.
Análisis y Diseños de Sistema 6°edicion, PEARSON.
Ingeniería del software. Un enfoque práctico (sexta edición), R. S. Pressman. McGraw
Hill Higher Education
Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.

Naur P., Randell B., Software Engineering: A Report on a Conference Sponsored by

the NATO Scienc, 1969.
Jacaboson, I., Booch, G., Rumbaugh J., El Proceso Unificado de Desarrollo de
Software, Addison Wesley 2000.
Beck, K., Una explicación de la Programación Extrema. Aceptar el cambio, Pearson
Educación, 2000.
Abrahamsson, P., Salo, O., Ronkainen, J., Agile Software Development Methods.
Review and Analysis, VTT, 2002.
Schwaber, K., Scrum Development Process. Workshop on Business Object Design
and Implementation, OOPSLA´95, 1995.
Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002.

http://243.sip.ucm.es/is/intro.html
http://www.centersoft.co.cu/Desasoft.htm
http://members.tripod.cl/RuthGarrido/ingsof/cap2-
4.html
http://www.reduaeh.mx/presenta/univirtual/notas_
2.htm http://definicion.de/diseno/#ixzz2yPbzN3UK
http://www.alegsa.com.ar/Dic/sistema.php
http://www.dgplades.salud.gob.mx/descargas/dhg/DIAGRAMA_PROCESOS.pdf
 ANEXO 1
CASO PRÁCTICO
RESTAURANTE

El sistema software a desarrollar consiste en gestionar el servicio de un Restaurante.

El sistema tiene que soportar las siguientes funciones:

• Presentación de menús a comensales: Los camareros utilizan Tablet PCs para

presentar en las mesas los menús (primeros platos, segundos, postres, bebidas...) que
ofrece el restaurante a los clientes. Con este dispositivo el camarero indica los
nombres de los primeros y segundos platos y sus precios; del postre se indica además
si es frío o caliente y de la bebida, en el caso de los vinos, el año. Cada camarero
gestiona un grupo de mesas, numeradas de 1 a n, y tiene un nombre.

El gerente utiliza el sistema para configurar, cada semana, el número de mesas y la

asignación de camareros a éstas (indicando el DNI del camarero y el número de mesa
asignado). La información de los camareros (DNI, apellidos y nombre) es obtenida del
subsistema de recursos humanos.

El gerente puede realizar consultas para obtener una lista ordenada por mesas en la
que se indica el resumen de ventas en dicha mesa y los camareros asignados
(apellidos y nombre) en un determinado periodo de tiempo.

• Recepción de peticiones en las mesas: Utilizando este mismo dispositivo los

camareros anotan las peticiones de los clientes, y se calcula un presupuesto inicial
que se le indica a los comensales. En la petición el cliente indica su número de mesa.
El sistema almacena la hora de la petición.

• Gestión en cocina de solicitudes, elaboración de platos y avisos de fin de

elaboración de platos: Estas peticiones son visualizadas en la cocina utilizando una
pizarra interactiva conectada a un PC. Esta pizarra muestra los platos solicitados
ordenados por hora y mesa. Sobre ella, interaccionando con un dedo, los cocineros
indican los platos ya listos para ser servidos una vez los han terminado de cocinar. El
sistema tiene que recoger la hora de finalización de un plato.

• Entrega de platos: Los camareros consultan en su Tablet PC cuándo están los

platos terminados y los recogen en la cocina para llevárselos a los comensales. Los
platos que no requieren elaboración en cocina (bebidas, pan, algunos postres...) son
recogidos directamente por el camarero en el almacén de la cocina, que contiene
frigoríficos y cámaras con dichos platos.

• Facturación: Las facturas son emitidas directamente por los camareros desde sus
Tablet PCs utilizando una impresora común conectada “sin cables”. Las facturas se
emiten cuando los clientes piden la cuenta. El precio de los productos incluye el IVA,
que tiene que ser desglosado en la factura.
• Aprovisionamiento: El jefe de cocina, que es uno de los cocineros, gestiona los
aprovisionamientos de alimentos, elaborando los pedidos y recibiendo la mercancía.
El restaurante trabaja con diversos proveedores cuya información es proporcionada
por la gerencia. Esta información consiste en los datos de contacto del proveedor, los
alimentos que suministra y su precio.

Para la elaboración de un pedido, el jefe de cocina indica el tipo de alimento y las

unidades necesarias. Con la información de los alimentos a pedir, el sistema busca los
proveedores más adecuados para cada alimento (teniendo en cuenta el precio y el
tiempo medio que tardan en servir ese alimento).

Como resultado el sistema elabora los pedidos concretos que se van a efectuar a cada
proveedor. Los proveedores siempre adjuntan la factura, que indica las cantidades de
alimentos que se han comprado.

• Consumo de alimentos: De cada alimento (por ejemplo, carne de ternera, sardinas,

pan, coca-cola, agua...) el sistema registra el número de unidades almacenadas. Al
final de cada día, el jefe de cocina ejecuta un proceso que calcula, a partir de los
platos elaborados, los alimentos que se han consumido. Esta definición –cuántas
unidades hay que descontar de cada alimento para un plato dado– es realizada por el
gerente del restaurante utilizando un ordenador ubicado en su oficina con el que
además establece los menús que ofrece el restaurante.

Todos los dispositivos están conectados en red local mediante tecnología inalámbrica.
 ANEXO 2 REQUERIMIENTOS DEL SOFTWARE

La Ingeniería de Requerimientos contempla todas las tareas específicas para

satisfacer las necesidades durante el proceso de creación o modificación de un

software.

Las especificaciones de requerimientos, nos permiten verificar si se están cumpliendo

o no los objetivos establecidos ya que estos son el reflejo de los requerimientos del
cliente, usuarios que nos permite verificar el cumplimiento de metas. Los
requerimientos deben ser:

 Medibles
 Comprobables
 Sin contradicciones
 Sin ambigüedades

Ejemplo de requerimientos.

El software debe imprimir rápido.

¿Que entendemos por esto? La palabra rápido es variable, no es Medible. Para que el
requerimiento sea correcto debería poder entregar una razón que sea Medible y
razonable.

El software debe imprimir 100 hojas por minuto.

Requerimientos funcionales y no funcionales

En la Ingeniería de Requerimientos, los requerimientos de dividen en dos

principalmente. Requerimientos Funcionales Requerimientos No Funcionales

Los requerimientos Funcionales: contemplan todo lo que el usuario desea que realice
el sistema, ejemplo; emisión de comprobante, impresión de facturas, etc. “Que debe
hacer un sistema”

Los requerimientos no funcionales: contemplan todo lo que se necesita para que el

sistema funcione correctamente; por ejemplo Impresora para la impresión de la
factura. “Como debe ser un sistema”.

Ver video: https://www.youtube.com/watch?feature=player_embedded&v=tF88eNhNSb4

Pasos para capturar requerimientos

1) Identificar actores: representan entidades externas que interactúan con el

sistema (rol). Se les da nombre a cada uno y describen sus papeles.
2) Identificación de escenarios: descripción concreta e informal de lo que la gente
hace y experimenta al tratar de usar una aplicación. Serán casos de uso (cdu).
3) Identificación de casos de uso: especifica todos los escenarios para una
funcionalidad. Lo inicia un actor. Es un flujo completo del sistema.
4) Descripción de casos de uso: caminos básicos, caminos alternativos,
precondiciones (estado inicial), descripciones, etc.
5) Diagramas de estado: describen estados y transiciones entre ellos. De
actividad: describen transición en detalle. De interacción: describen interacción
cdu-actor.
6) Prototipo de la interfaz:
a. Diseño lógico: se plantean los elementos de interfaz necesarios para el
caso de uso, la relación entre estos, como se aplican a los casos de uso,
su apariencia y modo de manipulación. Luego, cual usa cada actor.
b. Diseño físico: se preparan esquemas de la configuración de elementos
de las interfaces, y bocetos adicionales para combinar varios elementos
de interfaz y se construyen prototipos ejecutables de lo más importante.
7) Estructurar el modelo de caso de uso: Extraer descripciones de funcionalidad
de casos de uso generales y compartidas que pueden ser creadas por casos de
uso específicos, extenderlas o incluirlas.
a. Relaciones de generalización: simplifican forma de
trabajo y comprensión. Permiten reutilizar casos de uso.
b. Relaciones de extensión: se puede incluir el
comportamiento caso en otro bajo ciertas circunstancias.
Solo para casos excepcionales.
c. Relaciones de inclusión: permiten evitar redundancias y reutilizar
casos de uso. Solo para comportamientos compartidos entre
casos de uso.
El diagrama de casos de uso debe ser intuitivo, comprensible y
mostrar todos los casos de uso del sistema..

Fuente original ApoyoTi.com: Ingeniería de Requerimientos –

Introducción http://www.apoyoti.com/ingenieria-de-
requerimientos/
 ANEXO 3

MODELOS DE CICLO DE VIDA DEL SOFTWARE.

Modelo en Cascada.

El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de modelos
de actividades de ingeniería con el fin de establecer algo de orden en el desarrollo de
grandes productos de software. Consiste en diferentes etapas, las cuales son
procesadas en una manera lineal. Comparado con otros modelos de desarrollo de
software es más rígido y mejor administrable. El modelo cascada es un modelo muy
importante y ha sido la base de muchos otros modelos, sin embargo, para muchos
proyectos modernos, ha quedado un poco desactualizado.

Descripción del modelo

El modelo cascada es un modelo de ingeniería diseñado para ser aplicado en el

desarrollo de software. La idea principal es la siguiente: existen diferentes etapas de
desarrollo, la salida de la primera etapa “fluye” hacia la segunda etapa y esta salida
“fluye” hacia la tercera y así sucesivamente.

Existen generalmente cinco etapas en este modelo de desarrollo de software:

 Análisis y definición de requerimientos: en esta etapa, se establecen los

requerimientos del producto que se desea desarrollar. Éstos consisten
usualmente en los servicios que debe proveer, limitaciones y metas del
software. Una vez que se ha establecido esto, los requerimientos deben ser
definidos en una manera apropiada para ser útiles en la siguiente etapa. Esta
etapa incluye también un estudio de la factibilidad y viabilidad del proyecto con
el fin de determinar la conveniencia de la puesta en marcha del proceso de
desarrollo. Puede ser tomada como la concepción de un producto de software
y ser vista como el comienzo del ciclo de vida.
 Diseño del sistema: el diseño del software es un proceso multipaso que se
 centra en cuatro atributos diferentes de los programas: estructura de datos,
arquitectura del software, detalle del proceso y caracterización de las
interfases. El proceso de diseño representa los requerimientos en una forma
que permita la codificación del producto (además de una evaluación de la
calidad previa a la etapa de codificación). Al igual que los requerimientos, el
diseño es documentado y se convierte en parte del producto de software.
 Implementación: esta es la etapa en la cual son creados los programas. Si el
diseño posee un nivel de detalle alto, la etapa de codificación puede
implementarse mecánicamente. A menudo suele incluirse un testeo unitario en
esta etapa, es decir, las unidades de código producidas son evaluadas
individualmente antes de pasar a la etapa de integración y testeo global.
 Testeo del sistema: una vez concluida la codificación, comienza el testeo del
programa. El proceso de testeo se centra en dos puntos principales: las lógicas
internas del software; y las funcionalidades externas, es decir, se solucionan
errores de “comportamiento” del software y se asegura que las entradas
definidas producen resultados reales que coinciden con los requerimientos
especificados.
 Mantenimiento: esta etapa consiste en la corrección de errores que no fueron
previamente detectados, mejoras funcionales y de performance, y otros tipos de
soporte. La etapa de mantenimiento es parte del ciclo de vida del producto de
software y no pertenece estrictamente al desarrollo. Sin embargo, mejoras y
correcciones pueden ser consideradas como parte del desarrollo.

Estas son las etapas principales. También existen sub-etapas, dentro de cada etapa,
pero éstas difieren mucho de un proyecto a otro. También es posible que ciertos
proyectos de software requieran la incorporación de una etapa extra o la separación
de una etapa en otras dos. Sin embargo, todas estas variaciones al modelo cascada
poseen el mismo concepto básico: la idea de que una etapa provee salidas que serán
usadas como las entradas de la siguiente etapa (un flujo lineal entre las etapas). Por
lo tanto, el progreso del proceso de desarrollo de un producto de software, usando el
modelo cascada, es simple de conocer y controlar.

Existen actividades que son llevadas a cabo en cada una de las etapas del desarrollo
del software. Éstas son documentación, verificación y administración. La
documentación es intrínseca al modelo cascada puesto que la mayoría de las salidas
que arrojan las etapas son documentos.

Problemas con el Modelo Cascada

El ciclo de vida clásico es el paradigma más viejo y el más ampliamente usado en

la ingeniería del software. Sin embargo, su aplicabilidad en muchos campos ha sido
cuestionada. Entre los problemas que aparecen cuando se aplica el modelo cascada
están:

Los proyectos raramente siguen el flujo secuencial que el modelo propone. La

iteración siempre es necesaria y está presente, creando problemas en la
aplicación del modelo.
A menudo es difícil para el cliente poder especificar todos los requerimientos
explícitamente. El modelo de vida del software clásico requiere esto y presenta
problemas acomodando la incertidumbre natural que existe al principio de
cualquier proyecto.
 Obtención
de

Diseño
Global

Desarrol GRUPO
lo USUARIO
/
Refinamie
nto

Sistema
El cliente debe ser Terminado
paciente.
Una versión funcional del sistema no estará
disponible hasta tarde en la duración del desarrollo. Cualquier error o
malentendido, si no es detectado hasta que el programa funcionando es
revisado, puede ser desastroso.

Cada uno de estos problemas es real. Sin embargo, el modelo clásico del ciclo de vida
del software tiene un lugar bien definido e importante en los trabajos de ingeniería del
software. Provee un patrón dentro del cual encajan métodos para el análisis, diseño,
codificación y mantenimiento.

Aplicación

El modelo cascada se aplica bien en situaciones en las que el software es simple

y en las que el dominio de requerimientos es bien conocido, la tecnología usada en el
desarrollo es accesible y los recursos están disponibles.

Modelo Prototipo.

Dos de las críticas que se hacían al modelo de ciclo de vida en cascada eran que es
difícil tener claros todos los requisitos del sistema al inicio del proyecto, y que no se
dispone de una versión operativa del programa hasta las fases finales del desarrollo,
lo que dificulta la detección de errores y deja también para el final el descubrimiento
de los requisitos inadvertidos en las fases de análisis. Para paliar estas deficiencias
se ha propuesto un modelo de ciclo de vida basado en la construcción de prototipos.

En primer lugar, hay que ver si el sistema que tenemos que desarrollar es un buen
candidato a utilizar el paradigma de ciclo de vida de construcción de prototipos o al
modelo en espiral. En general, cualquier aplicación que presente mucha interacción
con el usuario, o que necesite algoritmos que puedan construirse de manera evolutiva,
yendo de lo más general a lo más específico es una buena candidata. No obstante,
hay que tener en cuenta la complejidad: si la aplicación necesita que se desarrolle una
gran cantidad de código para poder tener un prototipo que enseñar al usuario, las
ventajas de la construcción de prototipos se verán superadas por el esfuerzo de
desarrollar un prototipo que al final habrá que desechar o modificar mucho. También
hay que tener en cuenta la disposición del cliente para probar un prototipo y sugerir
modificaciones de los requisitos. Puede ser que el cliente ‘no tenga tiempo para andar
jugando’ o ‘no vea las ventajas de este método de desarrollo’.
También es conveniente construir prototipos para probar la eficiencia de los algoritmos
que se van a implementar, o para comprobar el rendimiento de un determinado
componente del sistema en condiciones similares a las que existirán durante la
utilización del sistema. Es bastante frecuente que el producto de ingeniería
desarrollado presente un buen rendimiento durante la fase de pruebas realizada por
los ingenieros antes de entregarlo al cliente pero que sea muy ineficiente, o incluso
inviable, a la hora de almacenar o procesar el volumen real de información que debe
manejar el cliente. En estos casos, la construcción de un prototipo de parte del
sistema y la realización de pruebas de rendimiento, sirven para decidir, antes de
empezar la fase de diseño, cuál es el modelo más adecuado de entre la gama
disponible para el soporte hardware o cómo deben hacerse los accesos para obtener
buenas respuestas en tiempo cuando la aplicación esté ya en funcionamiento.

En otros casos, el prototipo servirá para modelar y poder mostrar al cliente cómo va a
realizarse la E/S de datos en la aplicación, de forma que éste pueda hacerse una idea
de cómo va a ser el sistema final, pudiendo entonces detectar deficiencias o errores
en la especificación aunque el modelo no sea más que una cáscara vacía.

Según esto un prototipo puede tener alguna de las tres formas siguientes:

 un prototipo, en papel o ejecutable en ordenador, que describa la interacción

hombre- máquina y los listados del sistema.
 un prototipo que implemente algún(os) subconjunto(s) de la función requerida,
y que sirva para evaluar el rendimiento de un algoritmo o las necesidades de
capacidad de almacenamiento y velocidad de cálculo del sistema final.
 un programa que realice en todo o en parte la función deseada pero que tenga
características (rendimiento, consideración de casos particulares, etc.) que
deban ser mejoradas durante el desarrollo del proyecto.

La secuencia de tareas del paradigma de construcción de prototipos puede verse

en la siguiente figura.
Si se ha decidido construir un prototipo, lo primero que hay que hacer es realizar un
modelo del sistema, a partir de los requisitos que ya conozcamos. En este caso no es
necesario realizar una definición completa de los requisitos, pero sí es conveniente
determinar al menos las áreas donde será necesaria una definición posterior más
detallada.

Luego se procede a diseñar el prototipo. Se tratará de un diseño rápido, centrado sobre

todo en la arquitectura del sistema y la definición de la estructura de las interfaces más
que en aspectos de procedimiento de los programas: nos fijaremos más en la forma
y en la apariencia que en el contenido.

A partir del diseño construiremos el prototipo. Existen herramientas especializadas en

generar prototipos ejecutables a partir del diseño. Otra opción sería utilizar técnicas de
cuarta generación. La posibilidad más reciente consiste en el uso de especificaciones
formales, que faciliten el desarrollo incremental de especificaciones y permitan la
prueba de estas especificaciones.

En cualquier caso, el objetivo es siempre que la codificación sea rápida, aunque sea
en detrimento de la calidad del software generado.

Una vez listo el prototipo, hay que presentarlo al cliente para que lo pruebe y sugiera
modificaciones. En este punto el cliente puede ver una implementación de los
requisitos que ha definido inicialmente y sugerir las modificaciones necesarias en las
especificaciones para que satisfagan mejor sus necesidades.
A partir de estos comentarios del cliente y los cambios que se muestren necesarios en
los requisitos, se procederá a construir un nuevo prototipo y así sucesivamente hasta
que los requisitos queden totalmente formalizados, y se pueda entonces empezar con
el desarrollo del producto final.

Por tanto, el prototipado es una técnica que sirve fundamentalmente para la fase de
análisis de requisitos, pero lleva consigo la obtención de una serie de subproductos
que son útiles a lo largo del desarrollo del proyecto:

 Gran parte del trabajo realizado durante la fase de diseño rápido (especialmente
la definición de pantallas e informes) puede ser utilizada durante el diseño del
producto final. Además, tras realizar varias vueltas en el ciclo de construcción
de prototipos, el diseño del mismo se parece cada vez más al que tendrá el
producto final.
 Durante la fase de construcción de prototipos será necesario codificar algunos
componentes del software que también podrán ser reutilizados en la
codificación del producto final, aunque deban de ser optimizados en cuanto a
corrección o velocidad de procesamiento.

No obstante, hay que tener en cuenta que el prototipo no es el sistema final, puesto
que normalmente apenas es utilizable. Será demasiado lento, demasiado grande,
inadecuado para el volumen de datos necesario, contendrá errores (debido al diseño
rápido), será demasiado general (sin considerar casos particulares, que debe tener en
cuenta el sistema final) o estará codificado en un lenguaje o para una máquina
inadecuadas, o a partir de componentes software previamente existentes. No hay que
preocuparse de haber desperdiciado tiempo o esfuerzos construyendo prototipos que
luego habrán de ser desechados, si con ello hemos conseguido tener más clara la
especificación del proyecto, puesto que el tiempo perdido lo ahorraremos en las fases
siguientes, que podrán realizarse con menos esfuerzo y en las que se cometerán
menos errores que nos obliguen a volver atrás en el ciclo de vida.

Hay que tener en cuenta que un análisis de requisitos incorrecto o incompleto, cuyos
errores y deficiencias se detecten a la hora de las pruebas o tras entregar el software
al cliente, nos obligará a repetir de nuevo las fases de análisis, diseño y codificación,
que habíamos realizado cuidadosamente, pensando que estábamos desarrollando el
producto final. Al tener que repetir estas fases, sí que estaremos desechando una gran
cantidad de trabajo, normalmente muy superior al esfuerzo de construir un prototipo
basándose en un diseño rápido, en la reutilización de trozos de software preexistentes
y en herramientas de generación de código para informes y manejo de ventanas.

Uno de los problemas que suelen aparecer siguiendo el paradigma de construcción de

prototipos, es que con demasiada frecuencia el prototipo pasa a ser parte del sistema
final, bien sea por presiones del cliente, que quiere tener el sistema funcionando lo
antes posible o bien porque los técnicos se han acostumbrado a la máquina, el sistema
operativo o el lenguaje con el que se desarrolló el prototipo. Se olvida aquí que el
prototipo ha sido construido de forma acelerada, sin tener en cuenta consideraciones
de eficiencia, calidad del software o facilidad de mantenimiento, o que las elecciones
de lenguaje, sistema operativo o máquina para desarrollarlo se han hecho basándose
en criterios como el mejor conocimiento de esas herramientas por parte los técnicos
que en que sean adecuadas para el producto final.

El utilizar el prototipo en el producto final conduce a que éste contenga numerosos

errores latentes, sea ineficiente, poco fiable, incompleto o difícil de mantener. En
definitiva a que tenga poca calidad, y eso es precisamente lo que se quiere evitar
aplicando la ingeniería del software.

Razones para usar este modelo

Con este modelo se puede ilustrar los formatos de datos de entrada, mensajes,
informes y diálogos al usuario, mediante lo cual se logra un mejor entendimiento de
las necesidades. Se logra una exploración de los aspectos técnicos del producto
propuesto.
Otra de las razones para usar un prototipo es cuando el modelo de fases análisis -
diseño - instrumentación es inapropiado, es decir cuando el sistema se lo puede
realizar solamente con esta metodología.
Ventajas:
Útil cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida.
Existe una reducción de la incertidumbre y del
riesgo. Se reduce el tiempo y costos.
Existe mayor comunicación entre los desarrolladores y el usuario.
Desventajas:
Se depende de las herramientas de software para el éxito ya que la necesidad de
disminución de incertidumbre depende de las iteraciones del prototipo, entre más
iteraciones existan mejor y este último se logra mediante el uso de mejores
herramientas lo que hace a este proceso dependiente de las mismas.
No es posible usar la metodología en a todos los sistemas.

Puede existir una mala interpretación que pueden hacer los usuarios del prototipo, al
cual pueden confundir con el sistema terminado

Desarrollo Incremental
Mills sugirió el enfoque incremental de desarrollo como una forma de reducir la
repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma
de decisiones en los requisitos hasta adquirir experiencia con el sistema. Es una
combinación del Modelo de Cascada y Modelo Evolutivo.
Reduce el rehacer trabajo durante el proceso de desarrollo y da oportunidad para
retrasar las decisiones hasta tener experiencia en el sistema.

Modelo en Espiral.

El problema con los modelos de procesos de software es que no se enfrentan lo

suficiente con la incertidumbre inherente a los procesos de software. Importantes
proyectos de software fallaron porque los riegos del proyecto se despreciaron y nadie
se preparó para algún imprevisto. Boehm reconoció esto y trató de incorporar el factor
“riesgo del proyecto” al modelo de ciclo de vida, agregándoselo a las mejores
características de los modelos Cascada y Prototipado. El resultado fue el Modelo
Espiral. La dirección del nuevo modelo fue incorporar los puntos fuertes y evitar las
dificultades de otros modelos desplazando el énfasis de administración hacia la
evaluación y resolución del riesgo. De esta manera se permite tanto a los
desarrolladores como a los clientes detener el proceso cuando se lo considere
conveniente.

Descripción del modelo

Básicamente, la idea es desarrollo incremental usando el modelo Cascada para cada

paso, ayudando a administrar los riesgos. No se define en detalle el sistema completo
al principio; los diseñadores deberían definir e implementar solamente los rasgos de
mayor prioridad. Con el conocimiento adquirido, podrían entonces volver atrás y definir
e implementar más características en trozos más pequeños.

El modelo Espiral define cuatro actividades principales en su ciclo de vida:

 Planeamiento: determinación de los objetivos, alternativas y limitaciones del

proyecto.
 Análisis de riesgo: análisis de alternativas e identificación y solución de riesgos.
 Ingeniería: desarrollo y testeo del producto.
 Evaluación del cliente: tasación de los resultados de la ingeniería.

El modelo está representado por una espiral dividida en cuatro cuadrantes, cada
una de las cuales representa una de las actividades arriba mencionadas.

Puntos fuertes

 Evita las dificultades de los modelos existentes a través de un acercamiento

conducido por el riesgo.
 Intenta eliminar errores en las fases tempranas.
 Es el mismo modelo para el desarrollo y el mantenimiento.
 Provee mecanismos para la aseguración de la calidad del software.
 La reevaluación después de cada fase permite cambios en las percepciones de
los usuarios, avances tecnológicos o perspectivas financieras.
 La focalización en los objetivos y limitaciones ayuda a asegurar la calidad.

Puntos débiles

 Falta un proceso de guía explícito para determinar objetivos, limitaciones y

alternativas.
 Provee más flexibilidad que la conveniente para la mayoría de las aplicaciones.
 La pericia de tasación del riesgo no es una tarea fácil. El autor declara que es
necesaria mucha experiencia
en proyectos de
software para
realizar esta
tarea
exitosamente.

Aplicación

Proyectos
complejos, dinámicos,
innovadores,
ambiciosos, llevados a
cabo por equipos
internos (no
necesariamente de
software).
¿Cuál es el modelo de proceso más adecuado?
Cada proyecto de software requiere de una forma de particular de abordar el problema.
Las propuestas comerciales y académicas actuales promueven procesos iterativos,
donde en cada iteración puede utilizarse uno u otro modelo de proceso, considerando
un conjunto de criterios (Por ejemplo: grado de definición de requisitos, tamaño del
proyecto, riesgos identificados, entre otros).
En la Tabla se expone un cuadro comparativo de acuerdo con algunos criterios básicos
para la selección de un modelo de proceso, la medida utilizada indica el nivel de
efectividad del modelo de proceso de acuerdo al criterio (Por ejemplo: El modelo
Cascada responde con un nivel de efectividad Bajo cuando los Requisitos y
arquitectura no están predefinidos):

Funciona Permite
Modelo de con Produce Gestión de correcci Visión del
proceso software riesgos progreso
requisitos y ones
altamente por el
arquitectura sobre la
fiable Cliente y el
no marcha
Jefe del
predefinidos
proyecto

Cascada Bajo Alto Bajo Baj Bajo

o

Prototipo Alto Medi Medio Alto Alto

o

Incremental Bajo Alto Medio Baj Bajo

o

Espiral Alto Alto Alto Me Medio

dio
Scrum
Es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas
para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un
proyecto. Estas prácticas se apoyan unas a otras y su selección tiene origen en un
estudio de la manera de trabajar de equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por
el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la
competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se
disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante
la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es
necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere
trabajar utilizando un proceso especializado en el desarrollo de producto.

La programación extrema o eXtreme Programming (de ahora en adelante, XP)

Es una metodología de desarrollo de la ingeniería de software formulada por Kent
Beck, autor del primer libro sobre la materia, Extreme Programming Explained:
Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de
software. Al igual que éstos, la programación extrema se diferencia de las
metodologías tradicionales principalmente en que pone más énfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los
cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso
deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios
de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y
más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir
esfuerzos después en controlar los cambios en los requisitos.
Comparación Up – Xp –Scrum
ANEXO 5
PRUEBA DE FACTIBILIDAD DEL PROYECTO INFORMÁTICO

La investigación preliminar examina la factibilidad del proyecto, la posibilidad de que

el sistema sea de utilidad para la organización; a saber en tres áreas:

Factibilidad operacional:
Se refiere al hecho de que si trabajará o no el sistema si este se llega a desarrollar,
preguntas claves aquí son:

 ¿Existe apoyo suficiente para el proyecto por parte de la administración?, ¿Y

por parte de los usuarios?
 Los métodos que actualmente se usan en la empresa, ¿son aceptados por los
usuarios?
 ¿El sistema propuesto causará perjuicios?
 ¿Producirá resultados pobres en alguna área?
 ¿Se perderá control en alguna área específica?
 ¿Se perderá la facilidad de acceso a la información?
 ¿La productividad de los empleados será menor después de instalado el
sistema?
 ¿Los clientes se verán afectados por la implantación?

Factibilidad Técnica:

 ¿Existe o se puede adquirir la tecnología necesaria para realizar lo que se pide?

 ¿El equipo propuesto tiene la capacidad técnica para soportar todos los datos
requeridos para usar el nuevo sistema?
 ¿El sistema propuesto ofrecerá respuestas adecuadas a las peticiones sin
importar el número y ubicación de los usuarios?
 Si se desarrolla el sistema, ¿se puede crecer con facilidad?
 ¿Existen garantías técnicas de exactitud, confiabilidad, facilidad de acceso y
seguridad de los datos?

Factibilidad financiera y económica:

Un sistema puede ser factible desde el punto de vista técnico y operacional, pero sino
es factible económicamente para la organización no puede ser implantado. Las
cuestiones económicas y financieras formuladas por los analistas deben incluir

 El costo de llevar a cabo la investigación completa de sistemas

 El costo del hardware y software para la aplicación
 Beneficios en la forma de reducción de costos o de menos errores costosos
 El costo si nada sucede (si el proyecto no se lleva a cabo).