Ecuandor Plan Nacional Toda Una Vida 20172021

INSTITUTO TECNOLÓGICO SUPERIOR
“JOSE OCHOA LEÓN” DISEÑO DE SISTEMAS
UNIDAD I 1
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.
Entrad Salida
Proces
Retroalimentació
Ing. Jonnathan Castillo Quinto ciclo

“El objetivo del diseño es producir un modelo o

2
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
ACTIVIDAD. Formar grupos de trabajo y realiza el análisis del

ejercicio N° 1, propuesto en el anexos 1. Diseña los diagramas:
Casos de usos, diagrama de clases y diagrama de secuencia.
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. 4
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.

5
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.
ACTIVIDAD. Socializar y destacar los aspectos más relevantes del anexo

2: REQUERIMIENTO DEL SOFTWARE. Formar grupos de trabajo y
desarrollar un organizador gráfico.
TAREA. Realizar un diagnóstico de forma detallada de la situación

problemática de la empresa. La propuesta de solución, los objetivos a
cumplir y por último la lista de requerimientos funcionales del sistema.
Formar grupos de trabajo no mayor a 5 integrantes por grupo.

UNIDAD II 6
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, pudiendo ser gráficos con textos.
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.
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
7
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. 8
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.
INVESTIGACIÓN. Formar grupos de trabajo y preparar una exposición sobre las

metodologías de desarrollo ágil como son XP y Scrum, describiendo
detalladamente las etapas y procesos de cada una de ellas, así como las ventajas y
desventajas. (Complementar con el anexo 4)
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
9
 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 10
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: 11
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.
TAREA. Realizar toda la fase de análisis del sistema propuesto como

solución. Trabajar los mismos grupos de la tarea anterior. (Ver anexo 6)
12
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. 13
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 14
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.

15
Ejemplo:

16
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.
TAREA. Desarrollar toda la fase de análisis del sistema propuesto,

por lo que se debe incluir los Diagramas principales. Trabajar los
mismos grupos de la tarea anterior.

UNIDAD IV 17
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
ParamodelarConceptualmenteesposibleutilizarvariosModelosdeDatos Un modelo práctico para

ilustrar el diseño conceptual es el modeloentidadrelación.

Conceptos del Modelo entidad relación - MER:
18
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.

19
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

20
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.

21
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.

22
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
23
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.

24
•
,
'
CONTRATISTA REGIS'fRO 1UNIOAO DIE CONTAATACIONI
RESPONSABLE
AAEA SECRETARÍA 25
3
Rla!gMrvde
---------- Enlriula
e
Reglslro ele
Sali(la
21
Resoluclones
OO.
'Unipersonales
24
----------+--------+-----e Noliliu1ciones ,
Pro,cese, de lns,cripción ,en el Registr,e d,e Licila,dores die una Administración Púb 1ica 1

DISEÑO DE LAS INTERFACES DE ENTRADA DE DATOS 26
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 interfaces 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.

27
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 Interface 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 28
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.

29
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ú.

30
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.

31
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.

32
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 33
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. 34
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.
35
 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
36
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.
TAREA. Desarrollar el diseño de interfaz de la aplicación, debe incluir la

pantalla principal, los módulos principales, los mensajes de error y el
menú principal. Trabajar los mismos grupos de la tarea anterior.
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
Manipulación
rápida e intuitiva adecuadas donde existe una Videos juegos, sistemas
Directa
fácil de aprender metáfora 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 Procesamiento de
formularios. datos sencillos.
usuario 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
37
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
38
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
39
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ú 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ú.

40
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(interfaces graficas de usuario) 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ú
41
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.
42
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.

43
TAREA. Completar el proyecto final cumpliendo con el esquema del

anexo 6. Trabajar los mismos grupos de la tarea anterior. Preparar la
defensa del proyecto.
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.
44
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.

45
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,
46
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

47
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.
48
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 49
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 50
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 51
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 52
problemas acomodando la incertidumbre natural que existe al principio de cualquier
proyecto.
 El cliente debe ser 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.
Obtención de
Diseño Global
Desarrollo GRUPO
USUARIO /
DISEÑADOR
Refinamiento
Sistema Terminado

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 53
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 54
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 55
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:
56
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.
Durante el desarrollo de cada incremento se puede utilizar el modelo de cascada o evolutivo,
dependiendo del conocimiento que se tenga sobre los requisitos a implementar. Si se tiene un
buen conocimiento, se puede optar por cascada, si es dudoso, evolutivo.
Versión
#2 Versión ANÁLISIS DISEÑO CÓDIGO PRUEBAS
GRUP
O PRODUC ANÁLISIS DISEÑO CÓDIGO PRUEBAS
SISTE

57
Entre las ventajas del modelo incremental se encuentran:

 Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar
a usarlo desde el primer incremento.
 Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas
del sistema.
 Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada
incremento.
 Las partes más importantes del sistema son entregadas primero, por lo cual se realizan más
pruebas en estos módulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
 Cada incremento debe ser pequeño para limitar el riesgo (menos de 20.000 líneas).
 Cada incremento debe aumentar la funcionalidad.
 Es difícil establecer las correspondencias de los requisitos contra los incrementos.

 Es difícil detectar las unidades o servicios genéricos para todo 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 58
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.
59
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 60
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 con
Permite Visión del
Modelo de requisitos y Produce software Gestión de
correcciones progreso por el
proceso arquitectura no altamente fiable riesgos
sobre la marcha Cliente y el Jefe
predefinidos
del proyecto
Cascada Bajo Alto Bajo Bajo Bajo
Prototipo Alto Medio Medio Alto Alto
Incremental Bajo Alto Medio Bajo Bajo
Espiral Alto Alto Alto Medio Medio

CUADRO COMPARATIVO DE LOS MODELOS
61

•
,
'
62
MODELO ENFOQUE VENTAJAS/DESVENTAJAS APLICABILIDAD
Requiere comunicación Utilizado para el

permanente con el desarrollo de
Es una mejora del Modelo cliente por lo tanto si se aplicaciones
Basado en prototipos cambia el contacto con le complejas y/o
Cada vuelta en la espiral cual se realiza desarrollo específicas. (Ej.
representa una fase del es necesario que esté al Investigación
proceso. tanto de lo realizado y lo Genética)
No hay fases fijas, cada pendiente, cliente debe
vuelta en la espiral ser gran conocedor del
determina las actividades a sistema.
realizar.
La dimensión radial
MODELO
representa el coste
ESPIRAL
acumulado en la financiación
de las fases.
La dimensión angular
representa el progreso
hecho en completar cada
ciclo de la espiral.
Un ciclo a través de la
espiral es simular un paso a
través de un modelo en
cascada
MODELO ENFOQUE VENTAJAS APLICABILIDAD

/DESVENTAJAS
Modelo Lineal-Secuencial con el Los clientes no tienen Reemplazar el
Modelo Basado en Prototipos que esperar hasta antiguo desarrollo con
tener el sistema uno nuevo que
El sistema no se entrega de una completo. El primer satisfaga las nuevas
vez, sino que se divide y se incremento satisface necesidades según las
entregan incrementos. los requisitos más redefiniciones del
Con cada incremento se entrega la críticos. problema
parte de la funcionalidad que se
ha establecido. Los primeros Manejo de Versiones
incrementos sirven
Los requisitos son priorizados. Los como prototipo y
requisitos con una más alta ayudan en la tarea de
prioridad se incluyen en los detectar los
MODELO incrementos más tempranos. posteriores
INCREMENTAL requisitos.
O EVOLUTIVO Los requisitos de un incremento
son inamovibles. Sin embargo Existe un riesgo bajo
estos puede verse modificados en de fallar en el
incrementos posteriores. proyecto total.
Este proceso se repite hasta la Los servicios del

obtención de un producto sistema con la
completo. prioridad más alta
tienden a ser los más
Sin embargo el modelo probados.
incremental se centra en la
entrega de un producto operativo Puede ser d ifíci I
en cada incremento. ajustar los requisitos
a los incrementos.

ANEXO 4 63
METODOLOGÍAS DE DESARROLLO AGILES
XP (Extreme Programming)
Generalmente lo conducen pequeños grupos con requerimientos vagos y cambiantes.
Pilares
 Siempre probar todo, código sin prueba es rechazado.

 Programación en parejas en una misma PC, programando y debuggeando.
 Simpleza: hacer que las cosas sean fáciles, no pensar en mañana.
 Comunicación con el cliente constante, historias detalladas.
Plan de iteración: los desarrolladores que aceptan la tarea estiman la duración.
Roles: Programador, cliente, tester, traker, coach, consultor, gran jefe.
Historias de usuarios: lo que quiere el cliente que se haga.
Metáfora: lo más parecido a la arquitectura, cada proyecto tiene una convención de nombres a
recordar.
Semana laboral de 40 horas: si hay horas extra es señal de que está mal.
Codificación estándar: no tiene que notarse quien codificó.
Código colectivo: cualquier programador puede trabajar cualquier parte.
Scrum
Etapas:
1) Inicio:
a. Planeamiento: establecer la visión, presupuesto, financiamiento y backlog del
producto. Se establecen equipo de trabajo, herramientas y fecha de entrega
aproximada.
b. Arquitectura: conceptualización y análisis. Se hace un diseño de alto nivel
para actualizar modelos del dominio y reflejar el nuevo contexto del sistema.
Diseñadores y arquitectos dividen el proyecto basándose en los ítems del
backlog.
2) Desarrollo: Se divide en iteraciones (sprints), que es el proceso de adaptación a las
variables que cambian con el entorno. Un sprint puede durar de una semana a un mes,
y cada uno abarca las fases tradicionales del desarrollo del software (requerimientos,

análisis, diseño, desarrollo y entrega). Es semi caótico, por lo cual no usa diagramas
de Gantt. Durante un sprint no se pueden cambiar los miembros del equipo ni 64
introducirse cambios (estos se hacen en el backlog). En cada sprint se planifica
(reunión), desarrolla (con las fases), envoltura (cerrar paquetes), revisión de riesgos y
ajustes.
Durante un sprint se realizan reuniones diarias llamadas SCRUM, el objetivo es quitar
impedimentos que surjan, duran 15 minutos, obligatorias.
3) Cierre: Se realiza cuando las variables de entorno están completas, y el desarrollo

finalizado. documentación final, testing y lanzamiento.
Es ideal para problemas complejos y de ambientes cambiantes.
Roles: product owner, Scrum master, cliente, gerencia y equipo SCRUM.
Evita estancamientos, seguimiento del equipo y del proyecto, el SW incrementa su funcionalidad

en cada sprint. Controla cambios en el entorno y el proyecto mejora aun con ellos. El cliente
obtiene feedback frecuente.
Desventajas: delegación de autoridad, resistencia al cambio.
Comparación Up – Xp –Scrum

ANEXO 5 65
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
66
 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)
ANEXO 6
1. INTRODUCCIÓN
1.1. Antecedentes
1.1. Planteamiento del problema
1.2. Objetivos
1.2.1. Objetivo general
1.2.2. Objetivo específicos
1.3. Propuesta de solución
2. MARCO TEÓRICO
2.1. Requerimientos del software y hardware
2.1. Requerimiento de hardware.
2.2. Requerimiento de software
2.3. Cronograma de actividades
3. ANÁLISIS DEL SISTEMA
3.1. Identificación de requerimientos
3.1.1. Requerimientos funcionales
3.1.2. Requerimientos no funcionales
3.2. Roles del sistema
3.3. Módulos del sistema
3.4. Metodología de desarrollo
3.5. Casos de usos
3.6. Identificación de actores
3.7. Diagramas y descripción de los casos de usos
3.8. Diagrama de clases
3.9. Diagramas de secuencia
4. DISEÑO DEL SISTEMA
4.1. Arquitectura del sistema (grafica de cliente /servidor. # capaz, n capaz, red)
4.2. Descripción de los subsistemas de la aplicación
4.2.1. Diagramas de secuencia de ventanas.
4.3. Diseño de interfaces
4.3.1. Pantalla de inicio del sistema
4.3.2. Interfaces para el modulo
4.3.3. Interfaces para el modulo

4.4. Diseño de la base de datos
4.4.1. Modelo entidad relación 67
4.4.2. Modelo relacional
4.4.3. Descripción de las tablas
4.4.4. Scripts de la base de datos
5. CONCLUSIONES Y RECOMENDACIONES.
5.1. Conclusiones
5.2. Recomendaciones
6. BIBLIOGRAFÍA
7. ANEXOS
ANEXO 7
El inglés Jonathan Ive, nombrado caballero del Imperio Británico
El responsable de diseño de los productos de Apple, el inglés Jonathan Ive, fue nombrado
caballero del Imperio británico por la princesa Ana en una ceremonia celebrada en el palacio de
Buckingham. Ahora podrá utilizar el título de 'Sir'.
Ive tomó el mando de la sección de diseño de Apple en 1996, por lo que está considerado el
responsable de algunos de los productos más emblemáticos de la marca como el iMac, el
MacBook, el iPod, el iPhone o el iPad.
Este legado y los servicios prestados tanto al mundo del diseño
como a la empresa son los que valoró la monarquía inglesa para
otorgarle este honor.
"Fue muy bonito y emocionante. Me siento especialmente
orgulloso", declaró Ive, de 45 años, que acudió al acto con su mujer
y sus dos hijos, con los que vive en San Francisco (EEUU), donde
se encuentra la sede de la compañía de la manzana.
El diseñador, nacido en Londres, intercambió algunas palabras con

la princesa Ana sobre su ultimo diseño, el iPad, que desde su salida al mercado es el producto de
referencia en el sector de las tabletas. 68
Ive aseguró no obstante que mientras trabaja en el diseño de los productos no piensa en el
impacto que tendrán, sino en "hacer el mejor producto posible".
Jonathan Ive, que estudió en la Universidad Politécnica de Newcastle (nordeste de Inglaterra),
empezó a trabajar en Apple en 1992 y en 1996 se convirtió en el responsable de diseño de la
marca.
Su trabajo en la compañía de Steve Jobs, que lo definió como su "compañero espiritual", ha
revolucionado el mundo del diseño y de la informática y le valió en 2005 para ser nombrado ya
comandante del Imperio británico.
ANEXO 8
DESCRIPCIÓN DE LOS CASOS DE USOS

69
ANEXO 9
EJEMPLO DE CRONOGRAMA

70
ANEXO 10
DIAGRAMAS DE ESTADOS
Introducción
Un diagrama de estados muestra la secuencia de estados que pasa un objeto durante su vida
en respuesta a los estímulos recibidos, juntamente con sus respuestas. Definiremos tres
conceptos que nos ayudarán a entender los diagramas de estados:
 Acontecimiento: todo aquello que requiere la respuesta del sistema software.
 Estado: condición de un objeto o de un caso de uso en un momento del tiempo.
 Transición: cambio de estado como consecuencia de un acontecimiento.
A continuación se muestra un ejemplo de diagrama de estados para el diagrama de clases

dado:

71
El punto negro marca el estado inicial, y es por donde empieza a leerse el diagrama de estados.
Cada estado se representa con un globo y un nombre.
La flecha que une dos estados se llama transición.
Cada transición lleva asociado un nombre, que determina el acontecimiento que hace que se
produzca dicha transición.
Uso de los diagramas de estados
Los diagramas de estados se pueden especificar para:
 Una clase objetos:
o Para describir por qué los objetos cambian de subclase.
o Las subclases de un diagrama de estados no tienen por qué aparecer

explícitamente en el esquema conceptual (diagrama de clases).
o Para describir clases de objetos que presenten un importante comportamiento

dinámico.
 Casos de uso:
o Para describir la
secuencia legal en la que
los acontecimientos se
pueden producir en el
mundo real.

En el siguiente ejemplo, vemos el diagrama de estados para el caso de uso “Comprar
productos”, en que en la compra de un producto no se puede realizar el pago hasta que no se 72
haya cerrado la venta.
APUNTES

Ecuandor Plan Nacional Toda Una Vida 20172021

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Ecuandor Plan Nacional Toda Una Vida 20172021

Загружено:

Авторское право:

Доступные форматы

INSTITUTO TECNOLÓGICO SUPERIOR

“JOSE OCHOA LEÓN” DISEÑO DE SISTEMAS

INTRODUCCIÓN AL DISEÑO DE SISTEMAS

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

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

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

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

Ing. Jonnathan Castillo Quinto ciclo

“El objetivo del diseño es producir un modelo o

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

“Crea una representación o modelo de software,

ACTIVIDAD. Formar grupos de trabajo y realiza el análisis del

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

Ing. Jonnathan Castillo Quinto ciclo

El proceso de diseño sistema

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

Ing. Jonnathan Castillo Quinto ciclo

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

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

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

ACTIVIDAD. Socializar y destacar los aspectos más relevantes del anexo

TAREA. Realizar un diagnóstico de forma detallada de la situación

Ing. Jonnathan Castillo Quinto ciclo

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

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

Las metodologías persiguen tres necesidades principales:

 Mejores aplicaciones, conducentes a una mejor calidad.

ACTIVIDAD. Socializar y destacar los aspectos más relevantes del anexo

Características y clasificación de las metodologías

Ing. Jonnathan Castillo Quinto ciclo

Metodologías orientadas a objetos

Metodologías tradicionales (no ágiles)

Ing. Jonnathan Castillo Quinto ciclo

INVESTIGACIÓN. Formar grupos de trabajo y preparar una exposición sobre las

 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

Ing. Jonnathan Castillo Quinto ciclo

Conclusiones de las metodologías.

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.

Análisis del sistema.

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

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

Ing. Jonnathan Castillo Quinto ciclo

Planificación del proyecto software.

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

 Identificar los problemas con el sistema actual.

 Identificar el alcance del sistema a ser estudiado.

 Identificar los principales objetivos del nuevo sistema.

 Desarrollar estimados de los beneficios y desventajas de cada solución.

 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

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

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

Ing. Jonnathan Castillo Quinto ciclo

El diseño del software traduce los requisitos a un conjunto de representaciones (gráficas,

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

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

TAREA. Realizar toda la fase de análisis del sistema propuesto como

UNIDAD III DISEÑO

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