Modulo de Diseño de Sistemas

INSTITUTO TECNOLGICO SUPERIOR
JOSE OCHOA LEN DISEO DE SISTEMAS

Profesor: Ing. Yasser Alara!o Sal"nas #$"n%o &"&lo
1
UNIDAD I
INTRODUCCIN AL DISEO DE SISTEMAS
Qu significa Diseo?... Qu abarca un diseo?... Qu hace un arquitecto para el diseo de
una casa?...
Diseo: Es un boceto, bosquejo o esquema que se realiza, ya sea mentalmente o en
un soporte material, antes de concretar la produccin de algo. El trmino tambin se emplea para
referirse a la apariencia de ciertos productos en cuanto a sus lneas, forma y funcionalidades.
Qu significa Sistema?... Qu es un sistema?
Sistema: Un sistema es un conjunto de partes o elementos organizados y relacionados que
interactan entre s para lograr un objetivo. Los sistemas reciben (entrada) datos, energa o
materia del ambiente y proveen (salida) informacin, energa o materia.
Ejemplo de un sistema: Sistema respiratorio, sistema nervioso, sistema seo, el sistema de frenos
de un vehculo, el sistema elctrico de una casa, un sistema de riego, entre otros.
Sistema Informtico: Es el conjunto de sub-procesos que siguen un secuencia lgica para la
solucin de un problema. Un sistema tiene una entrada de datos y una salida. Tambin dispone
de una retroalimentacin. 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 podra causar
dao seria el polvo o el frio; en el caso de un sistema informtico el agente externo sera un virus
informtico.

Retroalimentacin
Entrada Salida
Proceso

2
El objetivo del diseo es producir un modelo o
representacin de una entidad que se va a construir
posteriormente (Pressman, 2002)
El diseo es el primer paso en la fase de desarrollo de cualquier producto o sistema de Ingeniera.
Toma los requerimientos de las funcionalidades de un SI (entrada, procesamiento, salida,
almacenamiento y control) identificadas en la fase de anlisis y los sintetiza en un nuevo
proyecto de sistema.

Se cuenta con una especificacin preliminar de lo que el nuevo sistema de informacin
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 informacin.

Existe mucha incertidumbre debido a que se concilian diferentes ideas de lo que los
usuarios consideran debera hacer el sistema, con las alternativas existentes acerca del
ambiente de aplicacin del nuevo sistema.

Crea una representacin 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 anlisis del ejercicio
N 1, propuesto en el anexos 1. Disea los diagramas: asos de usos,
diagrama de clases y diagrama de secuencia.

3

Despus de haber realizado el anlisis de un problema informtico haciendo uso de la gama de
diagramas que nos provee UML, se procede a realizar el diseo del sistema el mismo que se
compone de 4 fases que son:
1. Diseo de Datos
2. Diseo Arquitectnico
3. Diseo de Interfaces
4. Diseo de componentes


4
En la etapa de diseo es donde se toman las decisiones que afectarn finalmente al xito de la
implementacin del programa, y tambin, a la facilidad de mantenimiento que tendr el software.
Por tanto el diseo es un paso fundamental de la fase de desarrollo. El diseo es la nica forma
mediante la que podemos traducir con precisin los requisitos del cliente en un producto o
sistema acabado. El diseo de software es la base de todas las partes posteriores del desarrollo y
de la fase de prueba, como muestra en el siguiente grfico.

Sin diseo, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se
realicen pequeos cambios, un sistema que sea difcil de probar, un sistema cuya calidad no
pueda ser evaluada hasta ms adelante, cuando quede poco tiempo y ya sea haya gastado mucho
dinero.

El proceso de diseo sistema

El diseo del sistema es un proceso mediante el que se traducen los requisitos en una
representacin del software, que se acerca mucho al cdigo fuente. Desde el punto de vista de la
gestin del proyecto, el diseo del software se realiza en dos etapas: el diseo preliminar y el
diseo detallado.

El diseo preliminar se centra en la transformacin de los requisitos en los datos y la
arquitectura del software.
El diseo detallado se ocupa del refinamiento y de la representacin arquitectnica que
lleva a una estructura de datos refinada y a las representaciones algortmicas del software.

Adems del diseo de datos, del diseo arquitectnico y del desarrollo procedimental, muchas
aplicaciones modernas requieren un diseo de la interfaz.


5

Diseo y calidad del software

A lo largo del proceso de diseo, la calidad del diseo se evala mediante una serie de revisiones
tcnicas formales (RTF) que son una actividad de garanta del software cuyos objetivos son:

1. Descubrir los errores en la funcin, la lgica o la implementacin de cualquier
representacin del software.
2. Verificar que el software alcanza sus requisitos.
3. Garantizar que el software se ha representado segn los estndares establecidos.
4. Conseguir un software desarrollado de forma uniforme.
5. Hacer que los proyectos sean manejables.

Cada RTF se lleva a cabo mediante una reunin y slo tendr xito si est bien planificada,
controlada y atendida. A continuacin, se listan una serie de criterios para determinar la calidad
del software.

1. Un diseo debe tener una organizacin jerrquica.
2. Un diseo debe ser modular, es decir, el software debe estar dividido en elementos que
realicen funciones especficas.
3. Un diseo debe tener representaciones distintas y separadas de los datos y de los
procedimientos.
4. Un diseo debe llevar a mdulos que exhiban caractersticas funcionales independientes.
5. Un diseo debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los mdulos y el exterior.
6. Un diseo debe obtenerse mediante un mtodo que sea reproducible y que est dirigido
por la informacin obtenida durante el anlisis de requerimientos.

Un buen diseo de software no se consigue fcilmente, se requiere de la aplicacin de principios
fundamentales de diseo, de una metodologa sistemtica y de una revisin exhaustiva.

ACTIVIDAD. !ocializar y destacar los aspectos ms rele"antes del anexo #:
$%&'%$()(%N*+ D%, !+F*-.$%. Formar grupos de trabajo y desarrollar un
organizador gr/ico.
TAREA. $ealizar un diagn0stico de /orma detallada de la situaci0n problemtica
de la empresa. ,a propuesta de soluci0n, los objeti"os a cumplir y por 1ltimo la
lista de re2uerimientos /uncionales del sistema. Formar grupos de trabajo no
mayor a 3 integrantes por grupo.

6
UNIDAD II
METODOLOGA DE DISEO DE SOFTWARE
La necesidad de una metodologa de desarrollo

Maddison [1983] define metodologa como un conjunto de filosofas, etapas, procedimientos,
reglas, tcnicas, herramientas, documentacin y aspectos de formacin para los desarrolladores
de sistemas de informacin.

Piattini [1996], llega a la definicin de metodologa de desarrollo como un conjunto de
procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a los desarrolladores
a realizar nuevo software. Sintetizando lo anterior el autor dice que una metodologa
representa el camino para desarrollar software de una manera sistemtica.

Las metodologas persiguen tres necesidades principales:

Mejores aplicaciones, conducentes a una mejor calidad.
Un proceso de desarrollo controlado.
Un proceso normalizado en una organizacin, 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 ms tcnicas, pudiendo ser grficos con textos.

Caractersticas y clasificacin de las metodologas
Se pueden enumerar una serie de caractersticas [Piattini, 1996] que debe tener la metodologa y
que influirn en el entorno de desarrollo:

Reglas predefinidas
Determinacin de los pasos del ciclo de vida
Verificaciones en cada etapa
Planificacin y control
Comunicacin efectiva entre desarrolladores y usuarios.
De fcil comprensin
Soporte de herramientas automatizadas.
Qu permita definir mediciones que indiquen mejoras
Qu permita modificaciones
Qu soporte reusabilidad del software

ACTIVIDAD. !ocializar y destacar los aspectos ms rele"antes del anexo 4:
)+D%,+! D%, (,+ D% 5(D. D%, !+F*-.$%. Formar grupos de trabajo y
preparar una exposici0n sobre el tema.

7
Metodologas para desarrollo de software
Un proceso de software detallado y completo suele denominarse Metodologa. Las
metodologas se basan en una combinacin de los modelos de proceso genricos (cascada,
evolutivo, incremental, etc.). Adicionalmente una metodologa debera definir con precisin los
artefactos, roles y actividades involucrados, junto con prcticas y tcnicas recomendadas, guas
de adaptacin de la metodologa al proyecto, guas para uso de herramientas de apoyo, etc.
Habitualmente se utiliza el trmino mtodo para referirse a tcnicas, notaciones y guas
asociadas, que son aplicables a una (o algunas) actividades del proceso de desarrollo, por
ejemplo, suele hablarse de mtodos de anlisis y/o diseo.
La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad
de propuestas y diferencias en el grado de detalle, informacin 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 anlisis y diseo, podemos clasificar las metodologas en
dos grupos: Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte,
considerando su filosofa de desarrollo, aquellas metodologas con mayor nfasis en la
planificacin y control del proyecto, en especificacin precisa de requisitos y modelado, reciben
el apelativo de Metodologas Tradicionales. Otras metodologas, denominadas Metodologas
giles, estn ms orientadas a la generacin de cdigo con ciclos muy cortos de desarrollo, se
dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos humanos
asociados al trabajo en equipo e involucran activamente al cliente en el proceso. A continuacin
se revisan brevemente cada una de estas categoras de metodologas.
Metodologas estructuradas
Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin
Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de
Flujo de Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan
para la implementacin lenguajes de 3ra y 4ta generacin.
Metodologas orientadas a objetos
Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms
representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin
de C++ en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a
consolidarse algunos mtodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir
una unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms
modesto, para dar lugar al Unified Modeling Language (UML), la notacin OO ms popular en
la actualidad.
Algunos mtodos OO con notaciones predecesoras de UML. Algunas metodologas orientadas a
objetos que utilizan la notacin UML son: Rational Unified Process (RUP), OPEN, MTRICA
(que tambin soporta la notacin estructurada).
Metodologas tradicionales (no giles)
Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante

8
todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se
realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas
tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en
cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a
aplicarse), realizando una configuracin adecuada, podra considerarse gil.
Metodologas giles
Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de
software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo
momento) [11].
Entre las metodologas giles identificadas en [11]:
XP - Extreme Programming .
Scrum
Familia de Metodologas Crystal.
Feature Driven Development
Proceso Unificado Rational, una configuracin gil
Dynamic Systems Development Method.

Debido a la complejidad y envergadura del trabajo requerido para analizar, disear e implantar
un sistema de informtico 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 anlisis y diseo se apliquen principios
fundamentales de la teora de sistemas.
El enfoque sistmico
Anlisis del medio ambiente
Definicin exacta de los lmites del sistema
La consideracin de la flexibilidad necesaria en el nuevo sistema para asimilar la
dinmica del Objeto de direccin y del propio sistema de informacin
El hombre como elemento fundamental
La inclusin de los medios de control necesarios para garantizar el equilibrio del sistema
INVESTIGACIN. Formar grupos de trabajo y preparar una exposici0n sobre las
metodolog6as de desarrollo gil como son 78 y !crum, describiendo detalladamente las
etapas y procesos de cada una de ellas, as6 como las "entajas y des"entajas.
9omplementar con el anexo :;

9
El trabajo del diseador es creativo en gran parte, pues son diseados para objetivos especficos
y sin reglas rgidas, sin embargo es posible establecer una estructura que contenga ciertas normas
aplicables a los recursos, organizacin, tcnicas, mtodos y procesos durante los cuales el trabajo
de sistematizacin puede hacerse ms eficiente, debiendo ser flexible para no impedir la
creatividad del sistematizador.
Conclusiones de las metodologas.
Independientemente del paradigma que se utilice, del rea de aplicacin, y del tamao y la
complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de
fases genricas, existentes en todos los paradigmas. Estas fases son la definicin, el desarrollo y
el mantenimiento.
1) Definicin.
La fase de definicin se centra en el qu. Durante esta fase, se intenta identificar:
qu informacin es la que tiene que ser procesada.
qu funcin y rendimiento son los que se esperan.
qu restricciones de diseo existen.
qu interfaces deben utilizarse.
qu lenguaje de programacin, sistema operativo y soporte hardware van a ser
utilizados.
qu criterios de validacin 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 realizarn cuatro tareas especficas:
Anlisis del sistema.
El anlisis del sistema define el papel de cada elemento de un sistema informtico,
estableciendo cul es el papel del software dentro de ese sistema.
Es la fase de diseo externo. Consiste en cuestionar al usuario sobre qu hace el sistema,
qu caractersticas extras l quiere en su nuevo sistema y qu restricciones debe satisfacer. La
salida del anlisis debe incluir una especificacin funcional y un anlisis estructurado que
contiene los requerimientos para el nuevo sistema, los cuales el usuario debe leer, analizar y
sealar 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
Planificacin del proyecto software.
Durante esta etapa se lleva a cabo el anlisis de riesgos, se definen los recursos necesarios
para desarrollar el software y se establecen las estimaciones de tiempo y costes. El propsito de
esta etapa de planificacin es proporcionar una indicacin preliminar de la viabilidad del
proyecto de acuerdo con el coste y con la agenda que se hayan establecido. Posteriormente, la
gestin 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 nmero de soluciones que pueden satisfacer las necesidades del usuario
dentro de su esquema.
Desarrollar estimados de los beneficios y desventajas de cada solucin.
Desarrollar esquemas de cmo 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 decisin de si se lleva a cabo la parte de anlisis.
Todo este estudio evitar el gasto de un anlisis de un proyecto imposible. En l intervienen el
usuario y el analista. (Ver anexo 5)
2) Desarrollo.
La fase de definicin se centra en el cmo.
cmo ha de ser la arquitectura de la aplicacin.
cmo han de ser las estructuras de datos.
cmo han de implementarse los detalles de procedimiento de los mdulos.
cmo van a ser los interfaces.
cmo ha de traducirse el diseo a un lenguaje de programacin.
cmo van a realizarse las pruebas.
Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de vida
utilizado, en general se realizarn cuatro tareas especficas:
Diseo.
El diseo del software traduce los requisitos a un conjunto de representaciones (grficas,
en forma de tabla o basadas en algn lenguaje apropiado) que describen cmo van a estructurarse
los datos, cul va a ser la arquitectura de la aplicacin, cul va a ser la estructura de cada

11
programa y cmo van a ser las interfaces. Es necesario seguir criterios de diseo que nos
permitan asegurar la calidad del producto. Es la fase de diseo interno. Posteriormente se lleva a
cabo un diseo detallado donde se describen las especificaciones de los mdulos. Una vez
finalizado el diseo es necesario revisarlo para asegurar la completitud y el cumplimiento de los
requisitos del software.
Codificacin.
En esta fase, el diseo se traduce a un lenguaje de programacin, dando como resultado
un programa ejecutable. La buena calidad de los programas desarrollados depende en gran
medida de la calidad del diseo. 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 diseo. El listado fuente de cada mdulo (o el programa fuente en soporte
magntico) pasa a formar parte de la configuracin del sistema.
Pruebas.
Una vez que tenemos implementado el software es preciso probarlo, para detectar errores
de codificacin, de diseo o de especificacin. Las pruebas son necesarias para encontrar el
mayor nmero posible de errores antes de entregar el programa al cliente.
Garanta 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 correccin 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 definicin y de desarrollo, pero en el contexto de un software ya existente y en
funcionamiento.

TAREA. $ealizar toda la /ase de anlisis del sistema propuesto como soluci0n.
*rabajar los mismos grupos de la tarea anterior. 95er anexo <;

12
UNIDAD III
DISEO DE SISTEMAS

Es la transformacin de las especificaciones funcionales de un sistema, en un modelo que defina
"COMO" se va a lograr su implementacin fsica.

Aplicando el enfoque de sistemas, tenemos:
1. Definir la estructura inicial.
2. Disear los mdulos y/o ventanas.
3. Terminar la base de datos.
4. Disear entradas y salidas.
5. Generar el prototipo.
6. Revisar el diseo.

Importancia del diseo.
Organiza las ideas referentes al desarrollo de un nuevo sistema, facilitando el trabajo por
realizar en la etapa de construccin.
Define claramente los componentes que tendr el nuevo sistema, a nivel de bases de
datos, procesos e interfaces.
Descubre la estructura fsica que tendr el nuevo sistema.
Toma en cuenta el diseo de formatos tanto de entrada de datos, como de salidas del
propio sistema.
Proporciona una visin inicial para los usuarios, de cmo ser su interaccin con el
sistema, a travs de los prototipos.
Da claridad para definir la arquitectura necesaria que soportar al nuevo sistema.


13
Caractersticas del diseo.

Es una representacin abstracta del sistema, que plantea una solucin que ser
implementada luego.
Se preocupa de la "forma" del sistema en todos sus aspectos, definiendo con todo el
detalle cmo se ira a obtener esa forma planteada. Para esto es necesario desarrollar
ciertas actividades como:
ABSTRACCIN: Generalizar un problema con el fn de asignar prioridades a su
solucin y establecer una jerarqua.
OPERACIONALIDAD: Convertir la estructura generada en algo realizable y
funcional.
VERIFICACIN: Comprobar que se cumple con lo especificado en el anlisis.
Es una etapa limitada por el ambiente tecnolgico de hardware y software existente en la
organizacin.
Busca que la construccin del sistema se vuelva ms rutinaria y elemental.
La estructura a disear debe ser modular, donde cada mdulo exhiba caractersticas
funcionales independientes.
Un buen diseo debe ser :
COMPLETO : Debe abarcar todos los requerimientos planteados anteriormente.
CONSISTENTE : Se deben definir bien las interfaces con otros sistemas.
CLARO : Que sea fcil de traducir a un lenguaje de programacin.
MANTENIBLE : Que evale la posibilidad de modificaciones futuras.
PRACTICO : Que pueda ser realizable fcilmente, con las herramientas
tecnolgicas existentes en la organizacin.
EVALUABLE : Que permita revisarse y mejorarse.
Participacin requerida.

Es una etapa muy tcnica que requiere gran participacin del personal de sistemas y del usuario,
en lo que respecta a evaluaciones de prototipos y de diseo de pantallas (ventanas) del nuevo
sistema.

Analistas. Elaboran las especificaciones del diseo, con base en el anlisis elaborado
anteriormente. El papel que desempea en sta etapa el analista de sistemas, es el de diseador.
La habilidades de un buen diseador difieren algo de las del analista. Veamos : Se debe enfocar a
la tecnologa, sin olvidar los procesos definidos en el anlisis, mientras el analista hace lo
contrario. Se enfrenta con la tarea de traducir los requerimientos del negocio a la tecnologa
disponible en la organizacin.

Un buen diseador es creativo, lleno de recursos e inteligente para evaluar opciones entre
soluciones que no son perfectas. Las habilidades de un diseador estan ms cercanas a las de un
programador, ya que se debe tener claro el ambiente tecnolgico, para poder sacar el mayor
provecho de l.


14
Usuarios. Aprueban aspectos como operacin del sistema, diseo de entradas y salidas, diseo
de archivos y funcionalidad del sistema (Interfase de usuario).
Pasos en el desarrollo del diseo.

Los siguientes son los pasos a seguir para lograr un desarrollo coherente y serio en el diseo de
un sistema de informacin. Cada una de estas tareas debe estar claramente documentada, en el
manual de desarrollo del sistema.

Descomposicin funcional de mdulos.

Esta tcnica es la empleada para elaborar la estructura del sistema. Consiste en descomponer en
forma sucesiva un mdulo en otros mdulos de ms baja jerarqua, hasta lograr el detalle
suficiente en la asignacin de funciones a estos. Reglas para la descomposicin:

Cualquier estructura tendr un mdulo general o coordinador.
Cada mdulo, si lo requiere, se subdividir en otros.
Cada mdulo subordinado, ser coordinado por sus padres (un mdulo puede tener varios
padres).
Deben existir por lo menos dos mdulos al mismo nivel de descomposicin.


15

Ejemplo:


16

De la anterior estructura podemos observar :
Siempre existe un mdulo coordinador. En ste caso es el mdulo llamado S.I.
NOMINA.
No todos los mdulos se descomponen al mismo nivel, como es el caso de PRODUCIR
CHEQUES, que slo tiene un nivel de descomposicin. Un mdulo se debe
descomponer, hasta obtener una medida alta de cohesin en la funcin que realiza.
En primera instancia se est tratando de utilizar los mismos mdulos tanto para el clculo
de devengados, como para el de deducciones, con el objetivo de ahorrar ms tarde,
tiempo de construccin. Obviamente, se debe mirar si esto es posible, a la luz del
concepto de acople, que veremos ms tarde.
Existe un mdulo, cuya descomposicin est mal enfocada, dado que slo se subdivide
en otro mdulo, lo que atenta contra las reglas antes mencionadas. Tal mdulo es el
denominado EXTRACTAR BSICO.
Diseo de mdulos. (Diseo detallado).
Es la descripcin y representacin detallada de cmo cada mdulo de la estructura definida,
ejecutar su trabajo con el fin de facilitar el proceso de construccin. Es bsico en este punto,
retomar las especificaciones de proceso o mini especificaciones desarrolladas en el anlisis, ya
que el diseo de mdulos, no es ms que un refinamiento de la especificacin de proceso
elaborada anteriormente.

TAREA. Desarrollar toda la /ase de anlisis del sistema propuesto, por lo 2ue
se debe incluir los Diagramas principales. *rabajar los mismos grupos de la
tarea anterior.

17
UNIDAD IV
DISEO DEL MODELO CONCEPTUAL DE DATOS

El propsito de la metodologa de diseo es
facilitar el propsito de diseo y servir de soporte
de la base de datos mediante la utilizacin de
procedimientos, tcnicas, herramientas ya ayudas
para la generacin de documentacin.
Cuando se trabaja bajo el anlisis conceptual de
una situacin, nos referimos a la abstraccin de
hechos reales de los cuales se emite un concepto o
es posible hacer una idea de ello. Para poder
realizar la abstraccin de un tema en un rea
especfica, a nivel informtico, 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 creacin del esquema conceptual donde por
medio de este se podr realizar una descripcin 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 smbolos (estndares) para la creacin de este.
Fases del diseo de base de datos
Diseo conceptual.- es la construccin de un modelo que represente todos los datos
utilizados en una organizacin independientemente de las consideraciones fsicas
Diseo lgico.- construir un modelo de la organizacin basados en un modelo de datos
especficos, relacionar el modelo conceptual con el lgico
Diseo fsico.- generar de cmo va a ser la implementacin de la base de datos
dependiendo de la el SGBD que se vaya a utilizar
Diseo conceptual
El diseo conceptual se hace independiente al sistema gestor de base de datos (DBMS) que
utilice el usuario para la implementacin de esta.
Ver video: https://www.youtube.com/watch?v=THyQ-hhuOx4
Para modelar Conceptualmente es posible utilizar varios Modelos de Datos Un modelo prctico
para ilustrar el diseo conceptual es el modelo entidad relacin.


18
Conceptos del Modelo entidad relacin - MER:
Entidades: Una entidad es una "cosa" u "objeto" del mundo real, con existencia independiente y
distinguible de los dems objetos. Cada entidad tiene un conjunto de propiedades y valores que
la identifican de forma unvoca. Esta puede ser tanto tangible (existencia fsica), 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: cdula, nombre,
direccin, sexo, peso, altura, color, tipo de sangre, salario.
1. PASO 1 CONSTRUIR UN DISEO CONCEPTUAL DE LOS DATOS.
Identificar los tipos de entidad
Identificar los tipos de relacin
Identificar y asociar los atributos con los tipos de entidad y relacin.
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

Diseo lgico. Se utiliza el modelo relacional. En el diseo lgico 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

Diseo fsico. Es la base de datos final utilizada en un SGBD.
Ver video: https://www.youtube.com/watch?v=dniZcgxyWhw

Diferencias entre el diseo conceptual y lgico
El modelo conceptual es independiente del DBMS que se vaya a utilizar. El lgico
depende de un tipo de SGBD en particular.
El modelo lgico es ms cercano al ordenador
Es ms cercano al usuario el modelo conceptual, el lgico forma el paso entre el
informtico y el sistema.


21
Diccionario de datos

TAREA. Desarrollar el diseo /6sico de la base de datos, es decir los modelos:
entidad relaci0n y modelo relacional. .dems se debe incluir el diccionario de
datos. *rabajar los mismos grupos de la tarea anterior.

22
UNIDAD V
DISEO 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 realizacin del trabajo. Cada paso del proceso depende en uno o
varios proveedores de materiales o servicios y en algunos casos de informacin o recursos, los
cuales deben ser: confiables, libres de defectos, oportunos y completos.
En contraposicin, aquellos que son los receptores del o de los productos del proceso deben
asentar claramente sus requerimientos y dar a conocer cuando no estn recibiendo lo esperado.
Es tambin muy importante que el diagrama de flujo sobre el que se haga el anlisis de cualquier
proceso se encuentre al da, ya que si no es as puede desvirtuar la identificacin 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 cmo
acta el sistema en su totalidad.
Cmo se elabora?
Valide el diagrama de flujo y las medidas de desempeo 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 algn proceso, necesitan entenderlo.
Las personas que pueden evaluarlo son las que participan en el proceso o reciben algn
producto, servicio o informacin de l.
Se puede llevar a cabo un proceso de chequeo bajo los siguientes considerandos: Se debe
confirmar la precisin del proceso conforme se desarrolla el diagrama de flujo, as como
el tiempo estimado/ real de cada paso, tal como se lleva a cabo actualmente.

23
Enliste todos los pasos del proceso como se estn realizando. Mantenga tan simple como
sea posible su descripcin.
Se debe identificar y registrar el valor, tiempo invertido y costo de cada paso en el
proceso.
Utilice smbolos para mostrar el flujo de las acciones y decisiones involucradas en el
proceso de principio a fin. La simbologa bsica es la siguiente:

Ejemplos de Diagramas de procesos.


24


25
DISEO DE LAS INTERFACES DE ENTRADA DE DATOS
Se define aqu, con todo el grado de detalle, cmo sern los documentos de entrada requeridos
por el sistema, las diferentes pantallas de dilogo, las salidas generadas, todas las consultas y
reportes emitidos, los formatos de salida y las diferentes interfases con otros sistemas.
Es una tarea que se ocupa mucho de la forma, dado el carcter grfico de la tecnologa usada. Se
deben tener estndares claros de diseo, para evitar que cada analista realice a su amao estas
definiciones. Si no se tiene estndares, es conveniente hacer un alto en este punto y definirlos
claramente, para evitar ambigedades en la presentacin y diseo del sistema.
Es conveniente seguir los lineamientos que ofrece la tecnologa Windows, ya que stos son
estndares a nivel mundial.
DISEO 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 Organizacin.
Nombre de la Organizacin.
Nombre del departamento, seccin o divisin.
Cdigo del documento.
Nmero del documento.
En el cuerpo del documento :
Presentar un orden lgico de campos, de acuerdo con el orden de los datos que muestran
las pantallas.
Mostrar una descripcin clara de cada campo a diligenciar.
Permitir suficiente espacio para diligenciar cada campo.
Manejar una presentacin agradable y armnica.
Permitir un espacio para posibles observaciones.
Diseo de ventanas.


26

Las ventanas son la forma bsica de comunicacin con el usuario y la unidad de programacin a
tener en cuenta en la construccin. Se deben disear, teniendo en cuenta los estndares antes
mencionados y el tipo de ventana (entrada de datos, consultas, de men, etc.). Se debe tener en
cuenta:

Mostrar informacin que indique dnde 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 lneas de mensajes de ayuda y de error.
Mostrar los mensajes resaltados y en cajas de dilogo.
Otorgar un primer nivel de ayuda en la lnea de ayudas para cada opcin.
El orden de datos en la pantalla debe ser claro y asemejarse al orden de los datos en los
documentos fuentes.

La tecnologa actual direcciona el diseo de las ventanas, hacia la utilizacin de herramientas
grficas, por sus ventajas comparativas con otras tecnologas. Dicha tcnica se conoce en el
mercado con el nombre de GUI (Graphical User Interface) o Interfase Grfica de Usuario. El reto
consiste en elaborar interfaces que estn bien diseadas, satisfagan las necesidades del negocio y
satisfagan las expectativas cada vez mayores de los usuarios. Algunos criterios a tener en cuenta
en el diseo de GUI, son :

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

Una buena aplicacin GUI debe tener facilidad para el uso del mouse o para el teclado,
indistintamente. Por ello se deben incluir aspectos como el orden de tabulacin y teclas
aceleradoras (hot key) para que cualquier accin que se realce con el mouse, se pueda realizar
tambin con el teclado.

Sensibilidad: El sistema debe proporcionar retroalimentacin tangible e inmediata para cada
accin. Puede ser tan simple como cambiar un apuntador por el reloj de arena. Se deben usar
cuadros de dilogo para indicar errores de usuario, a travs de mensajes claros y entendibles.
Nunca mensajes generados por el sistema operativo, por ejemplo.

Personalizacin: 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.

Direccin: Se debe tener presente que la memorizacin de comandos no aplica bajo GUI.
Especialmente el hecho de ubicar un objeto en el sistema, debe ser tan intuitivo como sealarlo
con el mouse y realizar la operacin deseada con el objeto. Algo as como apunte y dispare.

27
Se pueden usar para tal propsito iconos y barras de herramientas que aclaren la ubicacin 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 estndares, 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 informacin presentada en la interface debe ser inmediatamente comprensible y el
uso de la aplicacin debe ser visualmente evidente. Se deben usar tablas de control a travs de
listas desplegables para dar mayor informacin a los usuarios, cuando se necesitan digitar datos
como por ejemplo, sexo, estado civil, departamento, etc.

Esttica: La composicin y disposicin de una ventana debe ser visualmente agradable. Deber
atraer la vista hacia la informacin que es ms 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 tamao de la misma. No
se deben presentar ventanas muy atiborradas de objetos ; es mejor dividirlas en otras ventanas,
para evitar confusiones.


28
Tipos de Ventanas
Ventana Principal o de Aplicacin.
Es la ventana ms comn.
Es independiente de cualquier otra ventana.
Puede traslapar y ser traslapada por otras ventanas.
Es movible, redimensionable, puede ser minimizada.
Generalmente tienen un men.

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


29

Ventana Hija.
Es muy similar a una ventana desplegable, pero ms 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 despus de cerrar la ventana madre.

Ventana de Respuesta.
Es la ms 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 travs de una ruta particular.


30

Ventana MDI. Traduce: Marco de Interface para Documentos Mltiples. 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 Pestaas.
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 pestaa.

DISEO DE REPORTES.

Se diferencian de los informes, por ser impresos y tener un lmite de columnas para su
presentacin. Se deben disear 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 Informacin.
Mostrar el Ttulo del reporte.
La fecha de elaboracin del reporte.

31
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 informacin en una forma clara, ordenada y armnica.

DISEO DE OPERACIN DEL SISTEMA (PROTOTIPOS).

Es la tarea clave en lo que respecta a la definicin de la forma como van a interactuar el usuario
y el sistema, ya que se define, por parte de los analistas la navegacin y comunicacin 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 creacin de prototipos es una
disculpa para codificar algo rpidamente y ver si los usuarios lo aceptan. Busca que los
usuarios tengan una idea de cmo ser el dilogo y la navegacin a travs del sistema y en
consecuencia se le debe aclarar al mismo el objetivo anteriormente expuesto.

Se debe construir un modelo sencillo que muestre cmo ser la operacin del sistema, con el fin
de probar con el usuario la dinmica, funcionalidad y caractersticas de implementacin. Est
aceptado generalmente que un prototipo es un modelo a escala de lo real, pero no tan funcional
para que equivalga al producto final. Es la simulacin de cmo 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, despus
de ver el prototipo, alguien encontrar un evento que hasta el momento no se haba detectado,
aadir elementos a las ventanas y eliminar otros innecesarios. Por ello, el prototipo enriquecer
an ms el modelo de informacin y de procesos definidos anteriormente.

Una buena idea para construir prototipos es la elaboracin 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 construccin.
La estructura general del sistema.
Los modelos definidos en el anlisis (procesos e informacin).

El modelo de informacin es una gua crtica para la disposicin de ventanas. El marco
organizacional de los datos est dictado por la cardinalidad de la relacin en el diagrama entidad-
relacin. Si un pedido tiene varios conceptos de pedido, se podra esperar una relacin
encabezado-detalle en la ventana de mantenimiento de pedidos:

32

Los
diferentes mdulos del sistema.
Algunas caractersticas propias del usuario:
Usuarios dedicados (Exigen poca documentacin y capacitacin).
Usuarios casual (Desean un sistema amistoso y detallado).
Grado de escolaridad.
Funciones que desarrolla en la organizacin.
Nivel de jerarqua.
No mostrar caractersticas que no se puedan luego implementar.
No se debe comenzar a construir el sistema, con la creacin temprana de prototipos.

Corregir los modelos de procesos e informacin, si surgen comentarios con la exposicin del
prototipo.

PUNTOS DE VISTA EN UNA INTERFAZ DE USUARIO

El del usuario, el del programador y el del diseador (analoga de la construccin 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 travs 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 interaccin con las
computadoras, de ah su importancia.

Modelo del usuario: El usuario tiene su visin personal del sistema, y espera que ste se
comporte de una cierta forma. Se puede conocer el modelo del usuario estudindolo, ya sea

33
realizando tests de usabilidad, entrevistas, o a travs de una realimentacin. Una interfaz debe
facilitar el proceso de crear un modelo mental efectivo.

Para ello son de gran utilidad las metforas, que asocian un dominio nuevo a uno ya conocido
por el usuario. Un ejemplo tpico es la metfora del escritorio, comn a la mayora de las
interfaces grficas actuales.

Principios de Diseo de las interfaces de usuario
Familiaridad del usuario: Utilizar trminos y conceptos que se toman de
la experiencia de las personas que ms 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.
Mnima 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:
Confirmacin de acciones destructivas.
Proveer de un recurso para deshacer. El recurso deshacer restablece el
sistema al estado previo antes de que ocurriera la accin.
Gua al usuario: Cuando los errores ocurren, la interfaz debe proveer
retroalimentacin significativa y caractersticas de ayuda sensible al
contexto.
Diversidad de usuarios: La interfaz debe proveer caractersticas de
interaccin apropiada para los diferentes tipos de usuarios.
Consideraciones importantes en el diseo de interfaces

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


34
Interaccin del usuario: Una interfaz coherente debe integrar la interaccin del usuario y la
presentacin de la informacin. Shneiderman (1998) clasifica la interaccin en 5 estilos
primarios:

Manipulacin directa: Interaccin directa con los objetos de la pantalla, Rpida e intuitiva,
Fcil de aprender, Ejemplo: para borrar un archivo, el usuario lo arrastra al bote de basura.
Videos de juegos, Puede ser difcil de implementar, Slo es adecuada donde hay una metfora
visual para las tareas y objetos.
Seleccin de mens: 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
propsito general.

Llenado de formularios: Introduccin de datos sencilla en los campos de un formulario, Fcil
de aprender, Ocupa mucho espacio en la pantalla, Ejemplo: ingreso datos del cliente

Lenguaje de comandos: Los usuarios emiten un comando especial y los parmetros asociados
para indicar al sistema que hacer, Poderoso y flexible, Difcil de aprender, Administracin de
errores pobre, Ejemplo: Sistemas operativos

Lenguaje Natural: El usuario emite comandos en lenguaje natural, Accesible a usuarios
casuales, Fcil de ampliar, Se requiere teclear ms, Los sistemas de comprensin de lenguaje
natural no son fiables, Ejemplo: Sistemas de horarios, sistemas www de recuperacin de la
informacin.

TAREA. Desarrollar el diseo de inter/az de la aplicaci0n, debe incluir la
pantalla principal, los m0dulos principales, los mensajes de error y el men1
principal. *rabajar los mismos grupos de la tarea anterior.

35
VENTAJAS Y DESVENTAJAS DE LOS ESTILOS DE INTERACCIN
Estilo de
Interaccin
Principales
Ventajas
Principales Desventajas Ejemplo de Aplicacin
Manipulacin
Directa
Interaccin
rpida e intuitiva
fcil de aprender
Puede ser difcil de
implementar. Solo es
adecuadas donde existe una
metfora visual para las tareas
y objetivos.

Videos juegos, sistemas
CAD.
Seleccin de
men.
Evitar errores de
los usuarios. Se
requiere tipear
poco.
Lenta para usuarios
experimentales. Puede llegar a
ser compleja si existen muchas
opciones en el men.
La mayora de los
sistemas de propsitos
general.
Relleno de
formularios.
Introduccin de
datos sencillos.
Ocupa mucho espacio en la
pantalla. Causa problemas
cuando las opciones del
usuario no se ajustan a los
campos del formulario.
Control de stock.
Procesamiento de
prstamos personales.
Lenguaje de
comandos
Poderosos y
flexibles
Difcil de aprender. Gestin
pobre errores.
Sistemas operativos.
Sistemas de comandos
y control.
Lenguaje
natural
Accesibilidad a
usuarios
causales. Fcil
de ampliar.
Se requiere teclear ms. Los
sistemas de comprensin de
lenguaje natural no son fiables.
Sistemas de
recuperacin de
informacin.

Tipos de interfaces de usuario
Dentro de las Interfaces de Usuario se puede distinguir bsicamente los siguientes tipos:
A) Una interfaz de hardware, a nivel de los dispositivos utilizados para ingresar, procesar y
entregar los datos: teclado, ratn y pantalla visualizadora.
B) Una interfaz de software, destinada a entregar informacin acerca de los procesos y
herramientas de control, a travs de lo que el usuario observa habitualmente en la pantalla.
C) Una interfaz de Software-Hardware, que establece un puente entre la mquina y las
personas, permite a la maquina entender la instruccin y a el hombre entender el cdigo binario
traducido a informacin legible.
Segn 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:

36
Interfaces de lenguaje natural
Las interfaces de lenguaje natural son quizs el sueo 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 interactan con la
computadora mediante lenguaje natural.

La pantalla descrita en la figura anterior se menciona tres preguntas de lenguaje natural de
tres aplicaciones diferentes. Observe que la interaccin con cada una parece muy fcil. Por
ejemplo, la primera frase "Mencione todos los vendedores de quienes se conocen sus cuotas
este mes" parece sencilla.
Las sutilezas e irregularidades que residen en las ambigedades del lenguaje natural
producen un problema de programacin 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 ratn) y la computadora despus acta en esa informacin de entrada de
acuerdo con su programa, normalmente pasando a la siguiente pregunta.

Mencione todos los vendedores de quienes se conocen
sus cuotas este Mes:
Mara Gonzlez
Mara Alvarado
Sulimar Pastran

Compare el porcentaje de vegetales podridos en cada
uno de nuestros almacenes:
Fair Oaks 4%
Tysons 5%

37

En la figura anterior se muestra un tipo de interfaz de pregunta y respuesta denominado
cuadro de dilogo. Un cuadro de dilogo acta como una interfaz de pregunta y respuesta dentro
de otra aplicacin, en este caso un diagrama PERT para un proyecto de anlisis de sistemas para
Bakerloo Brothers. Observe que el rectngulo redondeado para "S" est resaltado, lo que indica
que es la respuesta ms comn para esta situacin. La interfaz principal para esta aplicacin no
necesariamente debe ser de pregunta y respuesta. Ms bien, al incorporar un cuadro de dilogo,
el programador ha incluido una interfaz de fcil uso dentro de una ms complicada.

Los asistentes usados para instalar software son un ejemplo comn de una interfaz de
pregunta y respuesta. El usuario responde a las preguntas acerca del proceso de instalacin, tal
como dnde instalar el software o caractersticas. Otro ejemplo comn 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 diseadas para
limitar el alcance del problema. Los usuarios que no estn familiarizados con aplicaciones
particulares o no estn informados sobre un tema podran encontrar interfaces de pregunta y
respuesta ms cmodas, ganando rpidamente confianza a travs de su xito.


38
Mens
Una interfaz de mens adquiere apropiadamente su nombre de la lista de platillos que se
pueden seleccionar en un restaurante. De forma similar, una interfaz de men proporciona al
usuario una lista en pantalla de las selecciones disponibles. En respuesta al men, un usuario est
limitado a las opciones desplegadas. El usuario no necesita conocer el sistema pero tiene que
saber qu tarea se debe realizar. Por ejemplo, con un men tpico 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 desempear.

Los mens no dependen del hardware. Las variaciones abundan. Los mens se establecen
para usar el teclado, lpiz ptico o el ratn. Las selecciones se pueden identificar con un nmero,
carta o palabra clave. La consistencia es importante en el diseo de una interfaz de men.


39
Los mens tambin se pueden ocultar hasta que el usuario quiera usarlos. La figura
muestra cmo se usa un men desplegable. Los mens se pueden anidar dentro de otro para
llevar a un usuario a las opciones de un programa. Los mens anidados permiten a la pantalla
aparecer menos desordenada, la cual es consistente con el adecuado diseo.

Tambin permiten a usuarios evitar ver opciones de men en las que no estn interesados.
Los mens anidados tambin pueden mover rpidamente a los usuarios a travs del programa.
Los mens de GUI se usan para controlar el software de PC y tienen los siguientes
lineamientos:
1. Siempre se despliega la barra de men principal.
2. El men principal usa palabras simples para los artculos del men. Las opciones de
men principales siempre despliegan mens desplegables secundarios.
3. El men principal debe tener opciones secundarias agrupadas en grupos similares de
caractersticas.
4. Los mens desplegables que se presentan cuando se hace clic en un artculo de men
principal con frecuencia consisten en ms de una palabra.
5. Estas opciones secundarias desempean acciones o despliegan artculos de men
adicionales.
6. Los artculos de men en gris no estn disponibles para la actividad actual. Un men de
objeto, tambin llamado men desplegable independiente, se despliega cuando el usuario hace
clic en un objeto de la GUI con el botn derecho del ratn. Estos mens contienen artculos
especficos para la actividad actual y la mayora es funciones duplicadas de artculos 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 parmetros que necesitan ser
comunicados al usuario. El formulario a menudo es un facsmil de un formulario impreso que ya
es familiar para el usuario. Esta tcnica de interfaz tambin se conoce como mtodo basado en el
formulario y en formularios de entrada/salida.

40

La figura muestra una interfaz de formulario. Un men desplegable para el Nm. de la
parte introduce automticamente una Descripcin y un Precio de la unidad para el artculo.
Cuando el usuario pasa al campo Cantidad e introduce el nmero de artculos a ser comprados, el
software calcula automticamente el Precio extendido multiplicando la Cantidad y el Precio de la
unidad.
Los formularios para las pantallas de despliegue se configuran para mostrar qu
informacin debe introducirse y dnde. Los campos en blanco requieren informacin que se
puede resaltar con caracteres inversos o intermitentes. Por ejemplo, el usuario mueve el cursor de
un campo a otro mediante la pulsacin de una tecla de flecha. Esta disposicin permite moverse
un campo hacia atrs o un campo hacia adelante oprimiendo la tecla de flecha correspondiente.
Los formularios que se basan en la Web ofrecen la oportunidad de incluir hipervnculos para
ejemplos de formularios completados correctamente o para ayuda extensa y ejemplos.
Interfaces grficas de usuario
Las interfaces grficas de usuario (GUIs) permiten la manipulacin directa de la
representacin grfica en pantalla, la cual se puede realizar con la entrada del teclado, una
palanca de juego o el ratn. La manipulacin directa requiere mayor sofisticacin del sistema
que las interfaces vistas anteriormente. La clave para las GUIs es la retro alimentacin constante

41
que proporcionan. La retroalimentacin continua en el objeto manipulado significa que se
pueden hacer rpidamente los cambios o incluso cancelar operaciones sin incurrir en mensajes de
error. El concepto de retro alimentacin para los usuarios se discute ms a fondo en una seccin
ms adelante.
La creacin de GUIs representa un reto, debido a que se debe inventar un modelo
apropiado de realidad o un modelo conceptual aceptable de la representacin. El diseo de GUIs
para uso en intranets, extranets y, an ms urgente, en Web, requiere una planeacin ms
cuidadosa (vase el captulo 12 en el diseo de sitio Web). En general, los usuarios de sitios Web
son desconocidos para el diseador, de modo que el diseo debe ser bien definido. La eleccin
de iconos, lenguaje e hipervnculos se vuelve un conjunto de decisiones y suposiciones acerca de
qu tipos de usuarios del sitio Web estn esperando atraer.

TAREA. ompletar el proyecto /inal cumpliendo con el es2uema del anexo <.
*rabajar los mismos grupos de la tarea anterior. 8reparar la de/ensa del
proyecto.

42
BIBLIOGRAFA

Anlisis y Diseo de sistemas autor: Whitenn, Kenneth W; Ingeniera, edicin
2003.
Anlisis y Diseos de Sistema 6edicion, PEARSON.
Ingeniera del software. Un enfoque prctico (sexta edicin), R. S. Pressman. McGraw Hill
Higher Education
Pressman, R, Ingeniera del Software: Un enfoque prctico, 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 explicacin de la Programacin Extrema. Aceptar el cambio, Pearson Educacin,
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, OOPSLA95, 1995.
Schwaber, K., Beedle, M., Agile Software Development With Scrum, Prentice Hall, 2002.

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


43
ANEXO 1
CASO PRCTICO
RESTAURANTE

El sistema software a desarrollar consiste en gestionar el servicio de un Restaurante. El
sistema tiene que soportar las siguientes funciones:

Presentacin de mens a comensales: Los camareros utilizan Tablet PCs para
presentar en las mesas los mens (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 adems si es fro o
caliente y de la bebida, en el caso de los vinos, el ao. 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 nmero de mesas y la
asignacin de camareros a stas (indicando el DNI del camarero y el nmero de mesa
asignado). La informacin de los camareros (DNI, apellidos y nombre) es obtenida del
subsistema de recursos humanos.

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

Recepcin 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 peticin el cliente indica su nmero de mesa. El sistema
almacena la hora de la peticin.

Gestin en cocina de solicitudes, elaboracin de platos y avisos de fin de
elaboracin 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 finalizacin de un plato.

Entrega de platos: Los camareros consultan en su Tablet PC cundo estn los platos
terminados y los recogen en la cocina para llevrselos a los comensales. Los platos que
no requieren elaboracin en cocina (bebidas, pan, algunos postres...) son recogidos
directamente por el camarero en el almacn de la cocina, que contiene frigorficos y
cmaras con dichos platos.


44
Facturacin: Las facturas son emitidas directamente por los camareros desde sus
Tablet PCs utilizando una impresora comn 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 mercanca. El
restaurante trabaja con diversos proveedores cuya informacin es proporcionada por la
gerencia. Esta informacin consiste en los datos de contacto del proveedor, los alimentos
que suministra y su precio.

Para la elaboracin de un pedido, el jefe de cocina indica el tipo de alimento y las
unidades necesarias. Con la informacin de los alimentos a pedir, el sistema busca los
proveedores ms adecuados para cada alimento (teniendo en cuenta el precio y el tiempo
medio que tardan en servir ese alimento).

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

Consumo de alimentos: De cada alimento (por ejemplo, carne de ternera, sardinas,
pan, coca-cola, agua...) el sistema registra el nmero de unidades almacenadas. Al final
de cada da, el jefe de cocina ejecuta un proceso que calcula, a partir de los platos
elaborados, los alimentos que se han consumido. Esta definicin cuntas 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 adems establece los
mens que ofrece el restaurante.

Todos los dispositivos estn conectados en red local mediante tecnologa inalmbrica.


45
ANEXO 2
REQUERIMIENTOS DEL SOFTWARE

La Ingeniera de Requerimientos contempla todas las tareas especficas para satisfacer las
necesidades durante el proceso de creacin o modificacin de un software.
Las especificaciones de requerimientos, nos permiten verificar si se estn 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 Ambigedades
Ejemplo de requerimientos.
El software debe imprimir rpido.

46
Que entendemos por esto? La palabra rpido es variable, no es Medible. Para que el
requerimiento sea correcto debera poder entregar una razn que sea Medible y razonable.
El software debe imprimir 100 hojas por minuto.
Requerimientos funcionales y no funcionales
En la Ingeniera 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; emisin de comprobante, impresin 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 impresin de la factura. Como debe ser
un sistema.

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


47
Pasos para capturar requerimientos
1) Identificar actores: representan entidades externas que interactan con el sistema (rol). Se
les da nombre a cada uno y describen sus papeles.
2) Identificacin de escenarios: descripcin concreta e informal de lo que la gente hace y
experimenta al tratar de usar una aplicacin. Sern casos de uso (cdu).
3) Identificacin de casos de uso: especifica todos los escenarios para una funcionalidad. Lo
inicia un actor. Es un flujo completo del sistema.
4) Descripcin de casos de uso: caminos bsicos, caminos alternativos, precondiciones
(estado inicial), descripciones, etc.
5) Diagramas de estado: describen estados y transiciones entre ellos. De actividad: describen
transicin en detalle. De interaccin: describen interaccin cdu-actor.
6) Prototipo de la interfaz:
a. Diseo lgico: se plantean los elementos de interfaz necesarios para el caso de
uso, la relacin entre estos, como se aplican a los casos de uso, su apariencia y
modo de manipulacin. Luego, cual usa cada actor.
b. Diseo fsico: se preparan esquemas de la configuracin de elementos de las
interfaces, y bocetos adicionales para combinar varios elementos de interfaz y se
construyen prototipos ejecutables de lo ms 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 especficos,
extenderlas o incluirlas.
a. Relaciones de generalizacin: simplifican forma de trabajo y
comprensin. Permiten reutilizar casos de uso.
b. Relaciones de extensin: se puede incluir el comportamiento
caso en otro bajo ciertas circunstancias. Solo para casos
excepcionales.
c. Relaciones de inclusin: 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: Ingeniera de Requerimientos
Introduccin http://www.apoyoti.com/ingenieria-de-requerimientos/


48
ANEXO 3
MODELOS DE CICLO DE VIDA DEL SOFTWARE.
Modelo en Cascada.
El modelo cascada (waterfall), propuesto por Royce en 1970, fue derivado de modelos de
actividades de ingeniera 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 ms rgido 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.
Descripcin del modelo
El modelo cascada es un modelo de ingeniera diseado 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:
Anlisis y definicin 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

49
siguiente etapa. Esta etapa incluye tambin 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 concepcin de un producto de software y ser vista
como el comienzo del ciclo de vida.
Diseo del sistema: el diseo 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 caracterizacin de las interfases. El proceso de diseo
representa los requerimientos en una forma que permita la codificacin del producto
(adems de una evaluacin de la calidad previa a la etapa de codificacin). Al igual que
los requerimientos, el diseo es documentado y se convierte en parte del producto de
software.
Implementacin: esta es la etapa en la cual son creados los programas. Si el diseo
posee un nivel de detalle alto, la etapa de codificacin puede implementarse
mecnicamente. A menudo suele incluirse un testeo unitario en esta etapa, es decir, las
unidades de cdigo producidas son evaluadas individualmente antes de pasar a la etapa
de integracin y testeo global.
Testeo del sistema: una vez concluida la codificacin, comienza el testeo del programa.
El proceso de testeo se centra en dos puntos principales: las lgicas 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 correccin 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. Tambin existen sub-etapas, dentro de cada etapa, pero stas
difieren mucho de un proyecto a otro. Tambin es posible que ciertos proyectos de software
requieran la incorporacin de una etapa extra o la separacin de una etapa en otras dos. Sin
embargo, todas estas variaciones al modelo cascada poseen el mismo concepto bsico: la idea de
que una etapa provee salidas que sern 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 documentacin, verificacin y administracin. La documentacin es intrnseca al
modelo cascada puesto que la mayora de las salidas que arrojan las etapas son documentos.
Problemas con el Modelo Cascada
El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado en la
ingeniera del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada.
Entre los problemas que aparecen cuando se aplica el modelo cascada estn:

50
Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteracin
siempre es necesaria y est presente, creando problemas en la aplicacin del modelo.
A menudo es difcil para el cliente poder especificar todos los requerimientos
explcitamente. El modelo de vida del software clsico requiere esto y presenta
problemas acomodando la incertidumbre natural que existe al principio de cualquier
proyecto.
El cliente debe ser paciente. Una versin funcional del sistema no estar disponible hasta
tarde en la duracin 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 clsico del ciclo de vida del
software tiene un lugar bien definido e importante en los trabajos de ingeniera del software.
Provee un patrn dentro del cual encajan mtodos para el anlisis, diseo, codificacin y
mantenimiento.
Aplicacin
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 tecnologa usada en el desarrollo es accesible
y los recursos estn disponibles.
Modelo Prototipo.
Dos de las crticas que se hacan al modelo de ciclo de vida en cascada eran que es difcil
tener claros todos los requisitos del sistema al inicio del proyecto, y que no se dispone de una
versin operativa del programa hasta las fases finales del desarrollo, lo que dificulta la deteccin
de errores y deja tambin para el final el descubrimiento de los requisitos inadvertidos en las
fases de anlisis. Para paliar estas deficiencias se ha propuesto un modelo de ciclo de vida
basado en la construccin de prototipos.

Obtencin de

Diseo Global

Desarrollo

Refinamiento

Sistema Terminado

GRUPO
USUARIO /
DISEADOR

51

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 construccin de prototipos o al modelo en espiral. En
general, cualquier aplicacin que presente mucha interaccin con el usuario, o que necesite
algoritmos que puedan construirse de manera evolutiva, yendo de lo ms general a lo ms
especfico es una buena candidata. No obstante, hay que tener en cuenta la complejidad: si la
aplicacin necesita que se desarrolle una gran cantidad de cdigo para poder tener un prototipo
que ensear al usuario, las ventajas de la construccin de prototipos se vern superadas por el
esfuerzo de desarrollar un prototipo que al final habr que desechar o modificar mucho. Tambin
hay que tener en cuenta la disposicin 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 mtodo de desarrollo.
Tambin 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 existirn durante la utilizacin del sistema. Es bastante
frecuente que el producto de ingeniera 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 informacin
que debe manejar el cliente. En estos casos, la construccin de un prototipo de parte del sistema
y la realizacin de pruebas de rendimiento, sirven para decidir, antes de empezar la fase de
diseo, cul es el modelo ms adecuado de entre la gama disponible para el soporte hardware o
cmo deben hacerse los accesos para obtener buenas respuestas en tiempo cuando la aplicacin
est ya en funcionamiento.
En otros casos, el prototipo servir para modelar y poder mostrar al cliente cmo va a
realizarse la E/S de datos en la aplicacin, de forma que ste pueda hacerse una idea de cmo va
a ser el sistema final, pudiendo entonces detectar deficiencias o errores en la especificacin
aunque el modelo no sea ms que una cscara vaca.
Segn esto un prototipo puede tener alguna de las tres formas siguientes:
un prototipo, en papel o ejecutable en ordenador, que describa la interaccin hombre-
mquina y los listados del sistema.
un prototipo que implemente algn(os) subconjunto(s) de la funcin requerida, y que
sirva para evaluar el rendimiento de un algoritmo o las necesidades de capacidad de
almacenamiento y velocidad de clculo del sistema final.
un programa que realice en todo o en parte la funcin deseada pero que tenga
caractersticas (rendimiento, consideracin de casos particulares, etc.) que deban ser
mejoradas durante el desarrollo del proyecto.
La secuencia de tareas del paradigma de construccin de prototipos puede verse en la
siguiente figura.

52

Si se ha decidido construir un prototipo, lo primero que hay que hacer es realizar un modelo
del sistema, a partir de los requisitos que ya conozcamos. En este caso no es necesario realizar
una definicin completa de los requisitos, pero s es conveniente determinar al menos las reas
donde ser necesaria una definicin posterior ms detallada.
Luego se procede a disear el prototipo. Se tratar de un diseo rpido, centrado sobre todo
en la arquitectura del sistema y la definicin de la estructura de las interfaces ms que en
aspectos de procedimiento de los programas: nos fijaremos ms en la forma y en la apariencia
que en el contenido.
A partir del diseo construiremos el prototipo. Existen herramientas especializadas en
generar prototipos ejecutables a partir del diseo. Otra opcin sera utilizar tcnicas de cuarta
generacin. La posibilidad ms 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 codificacin sea rpida, 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 implementacin de los requisitos que ha
definido inicialmente y sugerir las modificaciones necesarias en las especificaciones para que
satisfagan mejor sus necesidades.

53
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 tcnica que sirve fundamentalmente para la fase de anlisis
de requisitos, pero lleva consigo la obtencin de una serie de subproductos que son tiles a lo
largo del desarrollo del proyecto:
Gran parte del trabajo realizado durante la fase de diseo rpido (especialmente la
definicin de pantallas e informes) puede ser utilizada durante el diseo del producto
final. Adems, tras realizar varias vueltas en el ciclo de construccin de prototipos, el
diseo del mismo se parece cada vez ms al que tendr el producto final.
Durante la fase de construccin de prototipos ser necesario codificar algunos
componentes del software que tambin podrn ser reutilizados en la codificacin del
producto final, aunque deban de ser optimizados en cuanto a correccin 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 diseo rpido), ser demasiado general
(sin considerar casos particulares, que debe tener en cuenta el sistema final) o estar codificado
en un lenguaje o para una mquina inadecuadas, o a partir de componentes software previamente
existentes. No hay que preocuparse de haber desperdiciado tiempo o esfuerzos construyendo
prototipos que luego habrn de ser desechados, si con ello hemos conseguido tener ms clara la
especificacin del proyecto, puesto que el tiempo perdido lo ahorraremos en las fases siguientes,
que podrn realizarse con menos esfuerzo y en las que se cometern menos errores que nos
obliguen a volver atrs en el ciclo de vida.
Hay que tener en cuenta que un anlisis 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 anlisis, diseo y codificacin, que habamos realizado
cuidadosamente, pensando que estbamos 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 basndose en un diseo rpido, en la reutilizacin
de trozos de software preexistentes y en herramientas de generacin de cdigo para informes y
manejo de ventanas.
Uno de los problemas que suelen aparecer siguiendo el paradigma de construccin 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 tcnicos se han acostumbrado a la mquina, 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 mquina para desarrollarlo

54
se han hecho basndose en criterios como el mejor conocimiento de esas herramientas por parte
los tcnicos 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 difcil de mantener. En definitiva a que tenga
poca calidad, y eso es precisamente lo que se quiere evitar aplicando la ingeniera del software.
Razones para usar este modelo
Con este modelo se puede ilustrar los formatos de datos de entrada, mensajes, informes y
dilogos al usuario, mediante lo cual se logra un mejor entendimiento de las necesidades. Se
logra una exploracin de los aspectos tcnicos del producto propuesto.
Otra de las razones para usar un prototipo es cuando el modelo de fases anlisis - diseo -
instrumentacin es inapropiado, es decir cuando el sistema se lo puede realizar solamente con
esta metodologa.
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 reduccin de la incertidumbre y del riesgo.
Se reduce el tiempo y costos.
Existe mayor comunicacin entre los desarrolladores y el usuario.
Desventajas:
Se depende de las herramientas de software para el xito ya que la necesidad de disminucin de
incertidumbre depende de las iteraciones del prototipo, entre ms 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 metodologa en a todos los sistemas.
Puede existir una mala interpretacin 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 repeticin 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 combinacin 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.

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

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 ms importantes del sistema son entregadas primero, por lo cual se realizan ms
pruebas en estos mdulos y se disminuye el riesgo de fallos.
Algunas de las desventajas identificadas para este modelo son:
Cada incremento debe ser pequeo para limitar el riesgo (menos de 20.000 lneas).
Cada incremento debe aumentar la funcionalidad.
GRUP
O
SISTE
MA /
Versin
# 2
Versin
# 1
ANLISIS DISEO CDIGO PRUEBAS
PRODUC
TO
ANLISIS DISEO CDIGO

56
Es difcil establecer las correspondencias de los requisitos contra los incrementos.
Es difcil detectar las unidades o servicios genricos 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
fallaron porque los riegos del proyecto se despreciaron y nadie se prepar para algn imprevisto.
Boehm reconoci esto y trat de incorporar el factor riesgo del proyecto al modelo de ciclo de
vida, agregndoselo a las mejores caractersticas de los modelos Cascada y Prototipado. El
resultado fue el Modelo Espiral. La direccin del nuevo modelo fue incorporar los puntos fuertes
y evitar las dificultades de otros modelos desplazando el nfasis de administracin hacia la
evaluacin y resolucin del riesgo. De esta manera se permite tanto a los desarrolladores como a
los clientes detener el proceso cuando se lo considere conveniente.
Descripcin del modelo
Bsicamente, 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

57
diseadores deberan definir e implementar solamente los rasgos de mayor prioridad. Con el
conocimiento adquirido, podran entonces volver atrs y definir e implementar ms
caractersticas en trozos ms pequeos.
El modelo Espiral define cuatro actividades principales en su ciclo de vida:
Planeamiento: determinacin de los objetivos, alternativas y limitaciones del proyecto.
Anlisis de riesgo: anlisis de alternativas e identificacin y solucin de riesgos.
Ingeniera: desarrollo y testeo del producto.
Evaluacin del cliente: tasacin de los resultados de la ingeniera.
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 travs 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 aseguracin de la calidad del software.
La reevaluacin despus de cada fase permite cambios en las percepciones de los
usuarios, avances tecnolgicos o perspectivas financieras.
La focalizacin en los objetivos y limitaciones ayuda a asegurar la calidad.
Puntos dbiles
Falta un proceso de gua explcito para determinar objetivos, limitaciones y alternativas.
Provee ms flexibilidad que la conveniente para la mayora de las aplicaciones.
La pericia de tasacin del riesgo no es una tarea fcil. El autor declara que es necesaria
mucha experiencia
en proyectos de
software para
realizar esta tarea
exitosamente.
Aplicacin
Proyectos complejos,
dinmicos, innovadores,
ambiciosos, llevados a
cabo por equipos internos
(no necesariamente de
software).

58

Cul es el modelo de proceso ms adecuado?
Cada proyecto de software requiere de una forma de particular de abordar el problema. Las
propuestas comerciales y acadmicas actuales promueven procesos iterativos, donde en cada
iteracin puede utilizarse uno u otro modelo de proceso, considerando un conjunto de criterios
(Por ejemplo: grado de definicin de requisitos, tamao del proyecto, riesgos identificados, entre
otros).
En la Tabla se expone un cuadro comparativo de acuerdo con algunos criterios bsicos para la
seleccin de un modelo de proceso, la medida utilizada indica el nivel de efectividad del modelo
de proceso de acuerdo al criterio (Por ejemplo: El modelo Cascada responde con un nivel de
efectividad Bajo cuando los Requisitos y arquitectura no estn predefinidos):

Modelo de
proceso
Funciona con
requisitos y
arquitectura
no
predefinidos
Produce
software
altamente fiable
Gestin de
riesgos
Permite
correcciones
sobre la
marcha

Visin del
progreso por
el Cliente y el
Jefe 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


59
CUADRO COMPARATIVO DE LOS MODELOS


60


61
ANEXO 4
METODOLOGAS DE DESARROLLO AGILES

XP (Extreme Programming)
Generalmente lo conducen pequeos grupos con requerimientos vagos y cambiantes.
Pilares
Siempre probar todo, cdigo sin prueba es rechazado.
Programacin en parejas en una misma PC, programando y debuggeando.
Simpleza: hacer que las cosas sean fciles, no pensar en maana.
Comunicacin con el cliente constante, historias detalladas.
Plan de iteracin: los desarrolladores que aceptan la tarea estiman la duracin.
Roles: Programador, cliente, tester, traker, coach, consultor, gran jefe.
Historias de usuarios: lo que quiere el cliente que se haga.
Metfora: lo ms parecido a la arquitectura, cada proyecto tiene una convencin de nombres a
recordar.
Semana laboral de 40 horas: si hay horas extra es seal de que est mal.
Codificacin estndar: no tiene que notarse quien codific.
Cdigo colectivo: cualquier programador puede trabajar cualquier parte.

Scrum
Etapas:
1) Inicio:
a. Planeamiento: establecer la visin, presupuesto, financiamiento y backlog del
producto. Se establecen equipo de trabajo, herramientas y fecha de entrega
aproximada.
b. Arquitectura: conceptualizacin y anlisis. Se hace un diseo de alto nivel
para actualizar modelos del dominio y reflejar el nuevo contexto del sistema.
Diseadores y arquitectos dividen el proyecto basndose en los tems del
backlog.
2) Desarrollo: Se divide en iteraciones (sprints), que es el proceso de adaptacin 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,

62
anlisis, diseo, desarrollo y entrega). Es semi catico, por lo cual no usa diagramas
de Gantt. Durante un sprint no se pueden cambiar los miembros del equipo ni
introducirse cambios (estos se hacen en el backlog). En cada sprint se planifica
(reunin), desarrolla (con las fases), envoltura (cerrar paquetes), revisin 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 estn completas, y el desarrollo
finalizado. documentacin 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: delegacin de autoridad, resistencia al cambio.

Comparacin Up Xp Scrum


63
ANEXO 5
PRUEBA DE FACTIBILIDAD DEL PROYECTO INFORMTICO
La investigacin preliminar examina la factibilidad del proyecto, la posibilidad de que el sistema
sea de utilidad para la organizacin; 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 administracin?, Y por parte de
los usuarios?
Los mtodos 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 especfica?
Se perder la facilidad de acceso a la informacin?
La productividad de los empleados ser menor despus de instalado el sistema?
Los clientes se vern afectados por la implantacin?
Factibilidad Tcnica:
Existe o se puede adquirir la tecnologa necesaria para realizar lo que se pide?
El equipo propuesto tiene la capacidad tcnica para soportar todos los datos requeridos
para usar el nuevo sistema?
El sistema propuesto ofrecer respuestas adecuadas a las peticiones sin importar el
nmero y ubicacin de los usuarios?
Si se desarrolla el sistema, se puede crecer con facilidad?
Existen garantas tcnicas de exactitud, confiabilidad, facilidad de acceso y seguridad de
los datos?
Factibilidad financiera y econmica:
Un sistema puede ser factible desde el punto de vista tcnico y operacional, pero sino es factible
econmicamente para la organizacin no puede ser implantado. Las cuestiones econmicas y
financieras formuladas por los analistas deben incluir
El costo de llevar a cabo la investigacin completa de sistemas
El costo del hardware y software para la aplicacin
Beneficios en la forma de reduccin de costos o de menos errores costosos
El costo si nada sucede (si el proyecto no se lleva a cabo)


64
ANEXO 6

1. INTRODUCCIN
1.1. Antecedentes
1.1. Planteamiento del problema
1.2. Objetivos
1.2.1. Objetivo general
1.2.2. Objetivo especficos
1.3. Propuesta de solucin
2. MARCO TERICO
2.1. Requerimientos del software y hardware
2.1. Requerimiento de hardware.
2.2. Requerimiento de software
2.3. Cronograma de actividades
3. ANLISIS DEL SISTEMA
3.1. Identificacin de requerimientos
3.1.1. Requerimientos funcionales
3.1.2. Requerimientos no funcionales
3.2. Roles del sistema
3.3. Mdulos del sistema
3.4. Metodologa de desarrollo
3.5. Casos de usos
3.6. Identificacin de actores
3.7. Diagramas y descripcin de los casos de usos
3.8. Diagrama de clases
3.9. Diagramas de secuencia
4. DISEO DEL SISTEMA
4.1. Arquitectura del sistema (grafica de cliente /servidor. # capaz, n capaz, red)
4.2. Descripcin de los subsistemas de la aplicacin
4.2.1. Diagramas de secuencia de ventanas.
4.3. Diseo 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. Diseo de la base de datos
4.4.1. Modelo entidad relacin
4.4.2. Modelo relacional
4.4.3. Descripcin de las tablas
4.4.4. Scripts de la base de datos
5. CONCLUSIONES Y RECOMENDACIONES.
5.1. Conclusiones
5.2. Recomendaciones
6. BIBLIOGRAFA
7. ANEXOS


65
ANEXO 7
El ingls Jonathan Ive, nombrado caballero del Imperio Britnico

El responsable de diseo de los productos de Apple, el ingls Jonathan Ive, fue nombrado
caballero del Imperio britnico por la princesa Ana en una ceremonia celebrada en el palacio de
Buckingham. Ahora podr utilizar el ttulo de 'Sir'.
Ive tom el mando de la seccin de diseo de Apple en 1996, por lo que est considerado el
responsable de algunos de los productos ms emblemticos 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 diseo
como a la empresa son los que valor la monarqua inglesa para
otorgarle este honor.
"Fue muy bonito y emocionante. Me siento especialmente
orgulloso", declar Ive, de 45 aos, 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 compaa de la manzana.
El diseador, nacido en Londres, intercambi algunas palabras con
la princesa Ana sobre su ultimo diseo, el iPad, que desde su salida
al mercado es el producto de referencia en el sector de las tabletas.
Ive asegur no obstante que mientras trabaja en el diseo de los productos no piensa en el
impacto que tendrn, sino en "hacer el mejor producto posible".
Jonathan Ive, que estudi en la Universidad Politcnica de Newcastle (nordeste de Inglaterra),
empez a trabajar en Apple en 1992 y en 1996 se convirti en el responsable de diseo de la
marca.
Su trabajo en la compaa de Steve Jobs, que lo defini como su "compaero espiritual", ha
revolucionado el mundo del diseo y de la informtica y le vali en 2005 para ser nombrado ya
comandante del Imperio britnico.

66
ANEXO 8
DESCRIPCIN DE LOS CASOS DE USOS


67
ANEXO 9
EJEMPLO DE CRONOGRAMA


68
ANEXO 10
DIAGRAMAS DE ESTADOS
Introduccin
Un diagrama de estados muestra la secuencia de estados que pasa un objeto durante su vida en
respuesta a los estmulos recibidos, juntamente con sus respuestas. Definiremos tres conceptos que nos
audar!n a entender los diagramas de estados"
#contecimiento" todo aquello que requiere la respuesta del sistema soft$are.
Estado" condicin de un objeto o de un caso de uso en un momento del tiempo.
%ransicin" cambio de estado como consecuencia de un acontecimiento.
# continuacin se muestra un ejemplo de diagrama de estados para el diagrama de clases dado"

El punto negro marca el estado inicial, es por donde empie&a a leerse el diagrama de estados.
'ada estado se representa con un globo un nombre.
(a flec)a que une dos estados se llama transicin.

69
'ada transicin lleva asociado un nombre, que determina el acontecimiento que )ace que se produ&ca
dic)a transicin.

Uso de los diagramas de estados
(os diagramas de estados se pueden especificar para"
Una clase objetos"
o Para describir por qu* los objetos cambian de subclase.
o (as subclases de un diagrama de estados no tienen por qu* aparecer e+plcitamente en
el esquema conceptual ,diagrama de clases-.
o Para describir clases de objetos que presenten un importante comportamiento
din!mico.
'asos 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 .'omprar
productos/, en que en la compra de un
producto no se puede reali&ar el pago )asta
que no se )aa cerrado la venta.


70
APUNTES

Modulo de Diseño de Sistemas

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Modulo de Diseño de Sistemas

Diunggah oleh

Hak Cipta:

Format Tersedia

INSTITUTO TECNOLGICO SUPERIOR

JOSE OCHOA LEN DISEO DE SISTEMAS

Anda mungkin juga menyukai