República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación Superior

Universidad Experimental de la Gran Caracas UNEXCA

Ingeniería en Informática

INGENIERIA DEL SOFTWARE II

 
 ¿QUE ES DISEÑO DE SOFTWARE?
El diseño de software es el proceso por el que un agente crea una
especificación de un artefacto de software, pensado para cumplir unos objetivos,
utilizando un conjunto de componentes primitivos y sujeto a restricciones. El
diseño de software  se puede referir a "toda la actividad implicada en
conceptualizar, enmarcar, implementar, poner en funcionamiento y, finalmente,
modificar sistemas complejos" o "la actividad que sigue a la especificación de
requisitos y procede a la programación, como en un proceso de ingeniería de
software estilizado.

Diseño de software normalmente implica problema solucionando y planeando una

solución de software. Esto incluye ambos un componente de nivel bajo y diseño de
algoritmo y un alto-nivel, diseño de arquitectura.

El diseño de Software es el primer paso en el SFDLC (Software Design Life

Cycle, en español ciclo de vida del diseño de software), lo que cambia la atención
e importancia desde problema de dominio a solución de dominio. Intenta
especificar cómo satisfacer los requisitos mencionados en el SRS.

El diseño de Software produce 3 niveles de resultados:

Diseño arquitectónico

El Diseño arquitectónico, es la versión más abstracta del sistema. Identifica el

software como un sistema con distintos componentes que interactúan entre ellos.
En este momento es cuando los diseñadores conciben la idea de posibles
soluciones de dominio.

Diseño de alto nivel

El Diseño de alto nivel, rompe con el concepto de diseño arquitectónico que se

refiere a ‘Componente de única entidad múltiple', por lo contrario, tiene un punto
de vista menos abstracto de los sub sistemas y módulos y representa la existente
interacción entre ellos. El Diseño de alto nivel se centra en cómo el sistema junto

2
con todos sus componentes se puede implementar en forma de módulos.
Reconoce estructuras modulares de cada sub sistema y su relación e interacción
entre las mismas.

Diseño detallado

El Diseño detallado diseña acuerdos con la parte de implementación de lo que

se ve como sistema y sus sub sistemas con los dos tipos de diseño mencionados
con anterioridad. Es más detallado en cuanto a los módulos y a su
implementación. Define estructuras lógicas de cada módulo y de sus interfaces
para comunicarse con los otros módulos.

¿IMPORTANCIA DEL DISEÑO DEL SOFTWARE?

Una fase muy importante en el ciclo de vida de un proyecto es el Diseño

del Software.

Se trata de una etapa fundamental y en muchas ocasiones la más importante

en el desarrollo de Software. Es el momento en que los profesionales tienen que
aportar sus conocimientos, experiencia y creatividad para llegar a una
solución que cumpla con los requerimientos funcionales y no funcionales
establecidos en la fase de la toma de requisitos.

El diseño del Software tiene un impacto directo sobre la capacidad del sistema
para cumplir o no el total de requerimientos establecidos. Un error de diseño en
esta fase puede acarrear problemas en todo el proyecto y provocar que este caiga
en una espiral de continuos cambios y de rehacer constantemente el trabajo.

Si tuviéramos que resumir en una sola palabra la importancia del diseño del
Software esta sería “Calidad”. Para acometer la tarea de diseño de manera
satisfactoria existen algunas técnicas que podemos (y muchas de ellas debemos)
seguir.

3
 CONCEPTOS DE DISEÑO

Los conceptos de diseño proporcionan al diseñador de software una base

sobre la que se pueden aplicar métodos más sofisticados. El conjunto de
conceptos fundamentales del diseño ha evolucionado. Son los siguientes:

1. Abstracción - la abstracción es el proceso o resultado de la generalización

reduciendo el contenido de información de un concepto o un fenómeno
observable, típicamente para retener información única que es pertinente
para un propósito particular. Es el acto de Representar características
esenciales sin incluir los detalles de fondo o explicaciones.
2. Refinamiento - es el proceso de elaboración. Una jerarquía se desarrolla
descomponiendo una declaración macroscópica de función de un modo
sensato hasta que se logre obtener declaraciones del lenguaje de
programación. En cada paso, una o varias instrucciones de un programa
dado se descomponen en instrucciones más detalladas. La abstracción y
El Refinamiento son conceptos complementarios.
3. Modularidad - La arquitectura de software está dividida en componentes
llamados módulos.
4. Arquitectura de software - se refiere a la estructura global del software y las
maneras en que esa estructura proporciona integridad conceptual al
sistema. Una buena arquitectura de software amortizará la inversión en
cuanto al resultado deseado del proyecto, en el rendimiento, la calidad, el
programa y el coste.
5. Jerarquía de control - Un estructura de programa  que representa la
organización de un componente e implica una jerarquía de control.
6. Estructural Partitioning - La estructura de programa puede ser dividida
horizontal y verticalmente. Las particiones horizontales definen ramas
separadas de jerarquía modular para cada función importante. Las
4
 particiones verticales sugiere que el control y el trabajo tendrían que ser
distribuidos de arriba a abajo en la estructura de programa.
7. Estructura de datos - es una representación de la relación lógica entre los
elementos individuales de los datos.
8. Procedimiento de software - centra en el procesamiento de cada módulo
individualmente.
9. Ocultar Información- los módulos tendrían que ser especificados y
diseñados de modo que la información contenida dentro de un módulo es
inaccesible a otros módulos, que no tienen ninguna necesidad de conocer
esa información.

¿QUÉ ES LA TRAZABILIDAD EN INGENIERÍA DE SOFTWARE?

La trazabilidad software es una antigua buena práctica, recomendada para

medianos o grandes desarrollos software, que trata sobre cómo enlazar o
relacionar los requisitos con otros elementos del ciclo de vida, principalmente,
casos de prueba y código.
Gracias a la trazabilidad de requisitos tenemos la posibilidad de identificar el
origen de cada requisito y realizar el seguimiento de cada cambio que se realice
sobre el mismo. Además, al trazar los requisitos con otros artefactos como
pruebas, casos de uso, código, etc., será posible responder a los cambios de
forma más controlada y con más información, y en consecuencia anticiparnos a lo
que un cambio puede significar.

Una de las técnicas más utilizadas para recoger la información bi-direccional de

trazas, son las matrices de trazabilidad. Éstas muestran diversos elementos en
filas y columnas (por ejemplo requisitos y pruebas) indicando en cada celda de la
matriz si los elementos están o no trazados y en qué dirección. Este tipo de
técnicas permite un análisis gráfico de la trazabilidad de requisitos y la gestión de
su impacto ante posibles cambios.

5
 ¿ATRIBUTOS DE CALIDAD?

Atributos de calidad (también cualidades del software) son características no

funcionales que se consideran deseables en un sistema de software. Sin embargo,
no todos los sistemas de software deben tener en cuenta todos estos atributos o
cualidades, algunas serán más importantes que otras dependiendo del sistema, y
ciertamente no se pueden maximizar todas a la vez.

Se establece una diferencia entre cualidades y requerimientos, porque algunas

de ellas pueden incorporarse como entrada al diseño por un camino distinto al del
análisis (por ejemplo, como restricciones de arquitectura o influencias del entorno).

PARTICIPANTES EN EL DISEÑO

Consiste en todas aquellas actividades que involucran llenar (y mantener

llenos) los puestos que fueron establecidos en la estructura organizacional del
proyecto. Esto incluye selección de candidatos, entrenamiento y otros.

Patrocinador del proyecto, jefe del proyecto, Gerente del proyecto,

Programador, Equipo de apoyo técnico, Responsables del área, Usuarios.

ESTÁNDARES DE CALIDAD

Estándar de calidad es el que reúne los requisitos mínimos en busca de la

excelencia dentro de una organización institucional

Los estándares de calidad de software hacen parte de la ingeniería de

software, utilización de estándares y metodologías para el diseño, programación,
prueba y análisis del software desarrollado, con el objetivo de ofrecer una mayor
confiabilidad, mantenibilidad en concordancia con los requisitos exigidos, con esto
se eleva la productividad y el control en la calidad de software, parte de la gestión
de la calidad se establecen a mejorar su eficacia y eficiencia.

6
 Los estándares definen un conjunto de criterios que guían la forma en que se
aplican procedimientos y metodologías al software desarrollado, la certificación de
calidad permite una valoración independiente de la organización, donde se
demuestra la capacidad de desarrollar productos y servicios de calidad.

DISEÑO ARQUITECTONICO
PATRONES DE DISEÑO

Los patrones de diseño son unas técnicas para resolver problemas comunes en

el desarrollo de software y otros ámbitos referentes al diseño de interacción o
interfaces.

Un patrón de diseño resulta ser una solución a un problema de diseño. Para

que una solución sea considerada un patrón debe poseer ciertas características.
Una de ellas es que debe haber comprobado su efectividad resolviendo problemas
similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que
significa que es aplicable a diferentes problemas de diseño en distintas
circunstancias.

MODELADO DEL DISEÑO:

El modelo de diseño es una abstracción de la implementación del sistema. Se

utiliza para concebir y para documentar el diseño del sistema de software. Es un
producto de trabajo integral y compuesto que abarca todas las clases de diseño,
subsistemas, paquetes, colaboraciones y las relaciones entre ellos.Cuando se
diseña la interfaz entran en juego 4 modelos diferentes:

1. Modelo de diseño creado por el ingeniero de software.

2. Modelo del usuario: que puede ser creado por el ingeniero de software u
otros ingenieros.

3. Percepción del usuario.

4-Imagen del sistema creada por los que implementan el sistema.

7
 Estos 4 modelos se pueden reconciliar y derivar una representación
consecuente de la interfaz, para lo cual se deben conocer los perfiles de edad,
sexo, habilidades físicas, educación, antecedentes culturales o étnicos,
motivación, objetivos y personalidad. Además se pueden establecer las siguientes
categorías de usuarios:

Principiantes: no tienen conocimientos sintácticos ni conocimientos semánticos

de la utilización de la aplicación.

Usuarios esporádicos y con conocimientos: poseen un conocimiento semántico

razonable, pero una retención baja de la información necesaria para utilizar la
interfaz.

Usuarios frecuentes y con conocimientos: poseen el conocimiento sintáctico y

semántico suficiente, buscan modos abreviados de interacción

Elementos del diseño

Para elaborar el diseño de la interfaz se utilizarán las siguientes herramientas:

1. Diagrama de menús

2. Diseño de cada una de las pantallas del sistema de acuerdo con el diagrama
jerárquico.

3. Conteo de Puntos de función

Diferentes modelos arquitectónicos pueden ser producidos durante el proceso

de diseño.

Cada modelo presenta diferentes perspectivas de la arquitectura:

 Modelo estático estructural que muestra los componentes principales del

sistema.

8
  Modelo dinámico del proceso que muestra la estructura de proceso del
sistema.
 Modelo de interfaz que define las interfaces de los subsistemas.

 Modelo de relaciones tales como un modelo de flujo de datos.

EVALUACION DEL DISEÑO

Durante el primer año de implementación de un programa debe realizarse este

tipo de evaluación. La información que brinda la evaluación de diseño permite
tomar decisiones para mejorar la lógica interna de un programa, es decir, saber si
su esquema actual contribuye a la solución del problema para el cual fue creado.

Los atributos de calidad son aquellas características medibles, tales como el

desempeño o disponibilidad, que permiten expresar la calidad del sistema de un
punto de vista del cliente y de la organización de desarrollo. Como se vio en
columnas anteriores, un buen diseño arquitectónico es clave para poder satisfacer
este tipo de requerimientos. Imaginemos, por ejemplo, que se tienen escenarios
de atributos de calidad de desempeño y escalabilidad como los siguientes:

DES-1: Un usuario arranca de forma manual el proceso de validación de

facturas. El sistema realiza el proceso sobre 2’000’000 de facturas en un tiempo
no mayor a 8 horas.

MOD-1: Un ingeniero agrega un componente para soportar un nuevo protocolo

de comunicación al sistema en tiempo de desarrollo. El componente es agregado
de forma exitosa sin que esto requiera de modificar ningún componente previo del
sistema.

Al terminar de realizar el diseño de una arquitectura, quisiéramos estar seguros

que el diseño arquitectural propuesto satisface realmente requerimientos como los
anteriores. El riesgo de no tener seguridad al respecto de ello de forma temprana
en el desarrollo puede tener consecuencias muy serias en etapas posteriores del

9
desarrollo y muy particularmente, si se descubren problemas relacionados con la
arquitectura en etapas tardías tales como la implantación del sistema.

La evaluación de la arquitectura de software es una herramienta que ayuda a

mitigar riesgos como el descrito anteriormente. Para lograrlo, la evaluación busca
esencialmente responder a la pregunta siguiente: ¿El diseño de la arquitectura
satisface a los requerimientos que influyen a la arquitectura y, principalmente, a
los atributos de calidad?

Técnicas de evaluación

Existen diversas técnicas de evaluación de arquitectura de software, que se

describen a continuación:

Checklists y cuestionarios

El uso de checklists (listas de verificación) y cuestionarios para realizar

revisiones e inspecciones del diseño que se ha producido. Realizarlos de forma
efectiva, no es una tarea trivial. Checklists y cuestionarios deben enfocarse sobre
cuestiones de fondo del diseño más que de la forma. Algunos ejemplos de
preguntas y comentarios al respecto, se muestran a continuación:

• ¿Todos los campos de la plantilla de vista han sido llenados? Esta pregunta
es necesaria, pero se enfoca sobre la forma.

• ¿Se ha definido un mecanismo de manejo de excepciones adecuado? Esta

pregunta se enfoca en cuestiones de diseño, la dificultad reside en definir lo que
se entiende como un mecanismo “adecuado”.

• ¿Se han documentado decisiones de diseño relativas a todos los drivers

arquitecturales? Es una pregunta útil, aunque una respuesta positiva no permite
saber si las decisiones de diseño son adecuadas.

Es complicado realizar checklists y cuestionarios genéricos que cubran todo

tipo de sistemas, por ello, es conveniente enfocarlos a dominios específicos que
requieran diseños arquitectónicos similares.

10
 La evaluación de arquitecturas por medio de checklists y cuestionarios deben
mantenerse resguardados y controlados.

Evaluación basada en escenarios

Las evaluaciones basadas en escenarios son una técnica más efectiva que la
anterior, sin embargo, se trata también de una técnica más costosa y más
compleja de implantar.

La evaluación basada en escenarios, toma como entrada escenarios que

pueden ser de atributos de calidad (como los descritos arriba) o bien funcionales
(por ejemplo, el flujo principal de algún caso de uso). Los escenarios son usados
por un equipo de evaluación para cuestionar al arquitecto sobre las decisiones de
diseño que tomó y el arquitecto debe ser capaz de argumentar de manera
convincente que el diseño planteado satisface o no los escenarios sobre los
cuales se le está cuestionando.

Una evaluación basada en escenarios requiere de poder conformar un comité

de evaluación. Generalmente, este comité de evaluación debe estar compuesto
por gente suficientemente experimentada como para poder entender y cuestionar
el diseño arquitectónico, este tipo de gente generalmente son ingenieros de
software experimentados o bien arquitectos de software.

Otras técnicas

Otras técnicas de evaluación incluyen la generación de simulaciones,

experimentos y análisis específicos. Estas técnicas son apropiadas para cierto tipo
de sistemas como por ejemplo los sistemas de tiempo real. Dependiendo la
criticidad del sistema, es conveniente combinar varias de las técnicas de
evaluación con el fin de tener mayor seguridad sobre la pertinencia de la
evaluación.

11
 La arquitectura de software es un artefacto fundamental dentro del desarrollo
de sistemas de calidad. El no cuidar aspectos relacionados con el desarrollo de la
arquitectura puede resultar en sistemas que no cubren las expectativas de los
clientes y de la organización de desarrollo; la evaluación del diseño de la
arquitectura es, por lo tanto, una actividad fundamental dentro de las actividades
de desarrollo. El alto costo que tienen los defectos relacionados con la arquitectura
en etapas tardías de desarrollo justifica plenamente que se invierta en la
realización de esta práctica como parte del desarrollo.

Por último, vale la pena señalar que la evaluación de la arquitectura pone a prueba
las habilidades “suaves” (soft skills) de los arquitectos, quienes deben ser capaces
de hacer presentaciones efectivas de su diseño, tanto a nivel escrito como a nivel
oral o bien de cuestionar diseños de otros arquitectos de forma pertinente.

12