2. DISEÑO CONCEPTUAL
El diseño conceptual se considera como un análisis de
actividades y consiste en la solución de negocios para el
usuario y se expresa con los casos de uso. El diseño lógico
es la solución del equipo de proyecto del negocio y
consiste de las siguientes tareas:
Identificar los usuarios y sus roles
Obtener datos de los usuarios
Evaluar la información
Documentar los escenarios de uso
Validar con los usuarios
Validar contra la arquitectura de la empresa
3. DISEÑO CONCEPTUAL
Una forma de obtener estos requerimientos es
construir una matriz usuarios-actividades de
negocios, realizar entrevistas, encuestas y/o
visitas a los usuarios, de tal manera que se
obtenga quién, qué, cuándo, dónde y por qué de
la solución.
4. DISEÑO LÓGICO
El diseño lógico traduce los escenarios de uso
creados en el diseño conceptual en un conjunto de
objetos de negocio y sus servicios. El diseño lógico se
convierte en parte en la especificación funcional que
se usa en el diseño físico. El diseño lógico es
independiente de la tecnología. El diseño lógico
refina, organiza y detalla la solución de negocios y
define formalmente las reglas y políticas específicas
de negocios.
El diseño lógico es el proceso de construir un
esquema de la información que utiliza la empresa,
basándose en un modelo de base de datos específico,
independiente del SGBD concreto que se vaya a
utilizar y de cualquier otra consideración física.
5. ETAPAS Y TAREAS DEL DISEÑO LOGICO
DETALLADO (diseña el exterior y documentarlo)
1.- Generar alternativas de solución (mínimo 2) Se
puede generar alternativas:
a) Agregando una función
b) Eliminando una función o fundiéndola
c) Modificando fuertemente el interior
Se evalúan técnica, económica y
operacionalmente las alternativas generadas.
(bienes de capital; costo - beneficio) y se elige
una.
6. ETAPAS Y TAREAS…
2.- Documentar la alternativa elegida Se debe documentar
cada función del exterior, en formulario que contendrá:
- Nombre de la función
- Situación
- Objetivo; lo que pretende hacer
- Información de entrada; y de donde proviene; detallada
- Información de salida; y a donde va; detallada
- Archivos internos que usa: fichero, memoria, kárdex,....
- Recursos utilizados. Secretaria, máquinas, teléfono fax,....
- Procedimiento general (describir la manera en que ella se
realizará)
- Observaciones
7. ETAPAS Y TAREAS…
3.-Documentar los procedimientos administrativos
Formularios usados; con su diseño. Se debe indicar todos
los formularios a usar, los que usa ahora, y los que usará:
- Flujograma de formularios; tabla de doble entrada origen
- destino de los formularios original y copias que se tiene
contemplado utilizar.
- Sistemas de codificación usados. Los códigos que se
utilizará, estén ya en uso o a ser usados ahora.
8. ETAPAS Y TAREAS…
4.-Requerimientos al interior. Se debe especificar aquí lo
que se quiere que el computador acepte como información
de entrada a él y que proveniente del exterior del sistema
o medio ambiente, y lo que se quiere que el computador
genere como información de salida para alimentar las
funciones contempladas en el diseño del SI:
Descripción de la información de Entrada, con el origen,
cantidad, periodicidad, tipo.
Descripción de la información de Salida. Se hace por
medio del:
- Diseño de los formularios de salida (listados que se
espera)
- Diseño de las pantallas de consultas (menú, formatos de
respuestas)
9. EL DISEÑO LÓGICO GLOBAL
Objetivo:
Establecer las alternativas de diseño en relación a
la situación actual, y elegir la "mejor" de ellas a
través de un proceso de evaluación. El resultado
final es un conjunto de funciones a ser realizadas
por el sistema, junto con la especificación de la
manera en que ellas se llevarán a cabo, los flujos
de información que los conectarán y el rol del
computador.
Modelos : Se usa dos tipos de modelos para
visualizar el sistema.
10. 1º.- Aquí el sistema se concibe como una "malla" o red de
funciones interactuando a través de información que
reciben de entradas de las funciones relacionadas, y
generan salidas hacia ellas, y que además regulan el
funcionamiento de la malla de los procesos del sistema.
11. 2º Visualizar el sistema como una partición jerárquica de
cada uno de los elementos que lo componen en la forma:
Entrada -- Función -- Salida. Los elementos son los que
están en el modelo descrito en la malla de funciones. Es un
diagrama del tipo árbol.
13. El diseño físico traduce el diseño lógico en una
solución implementable y costo-efectiva o económica.
El componente es la unidad de construcción
elemental del diseño físico. Las características de un
componente son:
Se define según cómo interactúa con otros
Encapsula sus funciones y sus datos
Es reusable a través de las aplicaciones
Puede verse como una caja negra
Puede contener otros componentes
15. ACOPLAMIENTO:
Mide el grado de independencia entre los módulo. Un
buen diseño debe minimizar el acoplamiento
(aumentar la independencia.) por las sig. Razones:
1º Cuanto menos conexiones existan entre 2 módulos,
menos oportunidad hay de que aparezca el efecto
RIPPLE (1 defecto de 1 módulo aparece afectando a
otro).
2º Se desea poder cambiar un modulo sin que afecte a
otro.
3º Mientras se mantiene un módulo, no debemos
preocuparnos de otro, máxima sencillez.
16. COHESIÓN:
Mide el grado de integración de los elementos de un
módulo, para organizar todos los elementos de forma
que los que estén más relacionados a la hora de
realizar una tarea pertenezcan al mismo módulo y los
elementos relacionados entre sí en módulos
separados.
17. Cuanto más vinculados estén los elementos de un
módulo, más fuerte es su cohesión, lo que lleva a un
mejor acoplamiento y a un mejor sistema (el SW es
fácil de mantener y los módulos fáciles de usar).
A medida que aumenta el número de módulos, el
coste por interfaz crece y el esfuerzo para desarrollar
cada módulo decrece.
18. Iceberg de la usabilidad
Qué es la Arquitectura del Software y que
relación tiene con la usabilidad. Tener en cuenta
la usabilidad en el momento del diseño de la
arquitectura de un sistema interactivo nos puede
ahorrar muchos problemas.
19. Se podría decir que, en el diseño de un sistema, hay
tres aspectos a tener en cuenta:
la presentación de la información
la funcionalidad de la aplicación
la Arquitectura del Software
¿Cuántas veces hemos tenido que correr a realizar
cambios profundos en la funcionalidad de una
aplicación después de haber detectado problemas de
usabilidad?
20. Dick Berry, en su analogía del Iceberg de la usabilidad, explica que los aspectos
relacionados con la presentación, es decir, lo que normalmente entendemos como
look & feel, sólo afectan en un 40% a la usabilidad. El 60% restante está
influenciado por lo que él llama “modelo del usuario”, que está constituido por los
objetivos que el usuario quiere alcanzar con sus tareas.
21. Arquitectura de software y
usabilidad
El usuario pueda visualizar el progreso de sus
peticiones, que pueda deshacer acciones (undo), que
pueda disponer de un entono multilingüe, que pueda
cancelar una operación que lleva mucho tiempo en
espera, que pueda reutilizar información que ha
introducido anteriormente, y muchas otras cosas.
Si analizamos estos escenarios de interacción,
veremos que la causa de que no se puedan
implementar es que no se tuvo en cuenta al usuario al
inicio del diseño del sistema, es decir, en la
Arquitectura del Software.
22. Arquitectura de software
Arquitectura del Software es el diseño de más alto nivel
de la estructura de un sistema, programa o aplicación y
tiene la responsabilidad de:
Definir los módulos principales
Definir las responsabilidades que tendrá cada uno de
estos módulos
Definir la interacción que existirá entre dichos
módulos:
Control y flujo de datos
Secuenciación de la información
Protocolos de interacción y comunicación
Ubicación en el hardware
23. La definición oficial de Arquitectura del Software es la
IEEE Std 1471-2000 que reza así: “La Arquitectura del
Software es la organización fundamental de un
sistema formada por sus componentes, las relaciones
entre ellos y el contexto en el que se implantarán, y
los principios que orientan su diseño y evolución”
24. Uno de los modelos más conocidos es el “4+1” de Philippe
Kruchten, vinculado al Rational Unified Process (RUP),
que define cuatro vistas diferentes:
Vista lógica: describe el modelo de objetos.
Vista de proceso: muestra la concurrencia y sincronía de
los procesos.
Vista física: muestra la ubicación del software en el
hardware.
Vista de desarrollo: describe la organización del entorno
de desarrollo.
Existe una quinta vista que consiste en una selección de
casos de uso o de escenarios que los arquitectos pueden
elaborar a partir de las cuatro vistas anteriores
25. Heurísticas de diseño
Las heurísticas de diseño son un conjunto de
recomendaciones que ayudan a mejorar la estructura
del sistema, optimizando la modularidad. La aplicación
de estas recomendaciones depende en gran medida del
diseño específico, así como de las características del
equipo físico donde se desarrolla el sistema.
26. 1).- Tamaño del módulo
El desarrollo del sistema de una estructura modular define
la funcionalidad propia de cada módulo. Sin embargo, es
recomendable revisar independientemente cada módulo a
efectos de optimizar su tamaño en número de sentencias,
para facilitar el desarrollo técnico del programa y su
posterior mantenimiento.
En general, podemos resumir diferentes versiones sobre el
tamaño óptimo de un módulo definiendo que, el coste en el
desarrollo y mantenimiento de un sistema será óptimo,
cuando su estructura esté compuesta por módulos con un
tamaño comprendido entre 10 y 100 sentencias.
27. Tamaño del módulo
Un módulo demasiado grande a menudo puede deberse a:
a) Dos o más funciones han sido combinadas (frecuentemente con
cohesión lógica) en un mismo módulo.
28. 2).- Ámbito de control
Se llama ámbito de control de un módulo a todos los
módulos llamados por él y a los llamados por éstos, es
decir, a todos los módulos que hay por debajo de él, en
esa rama del diagrama de descomposición funcional.
Un módulo que llama a muchos otros puede ser difícil
de entender, y en el otro extremo, si los módulos
forman una larga secuencia lineal, es posible que pueda
suprimirse alguno de ellos. Debe evitarse ambos
extremos:
29. Ambito de control alto:
Normalmente se produce cuando no se tienen en cuenta los niveles
intermedios. El estudio de los grupos de módulos subordinados que
permitan combinar sus funciones en una sola, puede solucionar el
problema.
Resistencia por parte del diseñador a delegar responsabilidades en
módulos subordinados.
Solución: debe considerarse la posibilidad de agruparse varios
subordinados en una función combinada. El principio de cohesión debe
guiar este proceso para evitar módulos de baja cohesión.
30. Ámbito de control bajo:
Para optimizar una estructura de este tipo se deben revisar
las posibilidades de descomponer las funciones en
subfunciones con entidad propia, para formar nuevos
módulos, o por el contrario, comprimir módulos
subordinados en el módulo de nivel superior. esto es
válido si se puede dar a los nuevos módulos un sentido
dentro de la estructura del problema.
