Definiciones más importantes de la arquitectura del software.

Las técnicas metodológicas desarrolladas con el fin de facilitar la programación se

engloban dentro de la llamada Arquitectura de Software o Arquitectura lógica. Se refiere a
un grupo de abstracciones y patrones que nos brindan un esquema de referencia útil para
guiarnos en el desarrollo de software dentro de un sistema informático.

Así, los programadores, diseñadores, ingenieros y analistas pueden trabajar bajo una línea
común que les posibilite la compatibilidad necesaria para lograr el objetivo deseado.

Algunos objetivos dentro de un esquema de Arquitectura de Software pueden ser: el

software debe ser mantenible, esto es, fácilmente analizable, modificable, corregible;
también puede ser un objetivo el nivel de interacción con otros sistemas informáticos, o su
escalabilidad.

Estas Arquitecturas están definidas muchas veces por el tipo de tecnología a la cual se
enfrenta un programador o grupo de programadores, por lo cual algunos tipos de
arquitectura son más recomendables que otras para ciertas tecnologías.

Cada tarea de computación es asignada a una computadora, por lo cual una Arquitectura
determinada debe ser implementada físicamente y definir de forma abstracta los
componentes que tomarán arte en las tareas y sus interfaces comunicativas.

Todo esto se desarrolla a "alto nivel", ensamblando elementos para lograr la mayor
funcionalidad posible siendo a la vez portable, logrando disponibilidad, escalabilidad y
confiabilidad.

Como ejemplos de Arquitecturas podemos citar las monolíticas (los grupos funcionales del
software están altamente acoplados entre sí), cliente-servidor (se reparte la carga de
cómputo en dos partes independientes), y la arquitectura de tres niveles (la carga se divide
entre tres partes: presentación, cálculo y almacenamiento).

Estilo de la arquitectura

Una arquitectura de software, o simplemente una vista de la arquitectura, puede tener un

atributo llamado estilo de la arquitectura, que reduce el conjunto de formatos posibles
para escoger e impone un cierto grado de uniformidad con la arquitectura. El estilo puede
definirse mediante un conjunto de patrones, o mediante la elección de componentes o
conectores específicos como bloques de compilación básicos. Para un sistema dado, el
estilo se puede capturar como parte de la descripción de la arquitectura en una guía de
estilo de la arquitectura, que se proporciona a través del producto de trabajo  
Directrices específicas del proyecto en RUP. El estilo desempeña un papel principal en la
comprensibilidad y la integridad de la arquitectura.
Importancia de y los Elementos que la Componen.

La importancia de la arquitectura de software

1. Creamos una base sólida para el proyecto.

2. Conseguiremos que la plataforma creada sea escalable.
3. Aumenta el rendimiento de la plataforma.
4. Reduce considerablemente los costes y evita duplicaciones del código.
5. La arquitectura de software es una manera de garantizarte una buena IT, puesto que el
arquitecto debe conservar durante toda la creación, una visión general del producto, de
forma que pueda bajar a pequeñas partes del código y saber enlazarlas con el resto. Debe
mantener una línea lógica y en ocasiones incluso, dar la cara para asegurar resultado
exitosos.
6. El arquitecto, al tener esta visión global del proceso e incluso del producto final, sabe en
qué aspectos se puede ahorrar gastos. De forma que reutiliza procesos y comparte los
datos para optimizar al máximo cada proceso evolutivo, buscando a su vez la mayor
perfección posible.
7. Ya que el código es propio, es mucho más visible y se tiene pleno conocimiento sobre él,
de forma que será mucho más fácil encontrar problemas y por lo tanto soluciones, en
definitiva tenemos un mantenimiento mucho más eficaz.
8. Este conocimiento, a la par nos permite la implementación de cambios en los sistemas de
manera más rápida.
9. Incrementa la calidad de la plataforma.
10. Ayuda en las tareas más complejas.
11. Nos permite hacer la plataforma de manera más rápida.
12. Permite una mayor adaptabilidad. Por ejemplo a la hora de modificar características
técnicas en front end, o implementar motores de reglas. Son tareas más sencillas de
adaptar cada una a su debido tiempo, ya que por otro lado el arquitecto de software
establece prioridades.
13. Ayuda a la gestión de riesgos reduciendo el porcentaje de fracasos.
14. Reduce los tiempos de creación y de entrega de los proyectos.
15. Da prioridad a los conflictos. Permite comunicación entre las partes y decisiones de diseño
previas a su implementación, de forma que sea más fácil un diseño especializado.
Importancia de los Elementos que la Componen.

¿Qué aspectos debería tener en consideración un

arquitecto de software ?
 

Para que la arquitectura de Software sea posible, es necesario tener en cuenta una serie de
aspectos sin los cuales, no sería posible.

 Usuario final. No solo es una meta a la que se tiene que llegar, y para el cual
queremos adaptar el producto, sino que el usuario final en sí, es intuitivo y exigente.
Por lo tanto debemos presentarle un producto fiable, funcional, de fácil uso, con un
buen rendimiento y seguro.
 El administrador del sistema. Deberá estar alerta, velando por el comportamiento
intuitivo y la buena administración. Así como de controlar las herramientas que nos
ayudan a sostenerlo.
 El vendedor. Tiene que ser consciente en todo momento de cómo se encuentra la
competencia, saber qué es lo que quieren los usuarios, que productos se venden
mejor, cuales son los costes del producto, o cuales son las tendencias.
 El cliente. Preocupado en todo momento por su producto, por si será estable, cual
será el coste final y si se cumplirá el calendario de entrega.
 El desarrollador. Estará atento a que todos los requisitos se cumplan y que el
diseño sea simple y coherente.
 El project Manager. Consciente del presupuesto, los recursos, el coste y el timing
de entrega, su misión es conseguir que todo se cumpla. Para eso, coordina a los
desarrolladores y hace de intermediario con el cliente.
 The maintainer. Se preocupa por finalizar el proyecto con contenidos coherentes y
comprensibles. Documenta el diseño para que sea más sencilla su ejecución y que
futuras modificaciones sean más factibles.

En definitiva, el arquitecto de Software debe encargarse de organizar desde una visión

general cada proceso de creación del código, buscando la forma más sencilla, económica,
práctica y segura de seguir adelante.

Por eso en Apiumhub contamos con ecosistemas de trabajo, guiados por la arquitectura
web, de forma que nuestros proyectos tengan unos resultados más positivos, por menor
coste.
Esperemos que el artículo “importancia de la arquitectura de software” te haya servido de
ayuda. Y que tengan mayores conocimientos sobre todo lo que la arquitectura de software
representa.

Especificaciones y la vista Arquitectónica.

Considera como vista arquitectónica y del concepto puntos-de-vista que está muy
relacionado con las vistas, lo cual permitirá tener una precisión de los términos aquí
empleados. Luego se hace un análisis de las propuestas más importantes de los modelos de
las vistas en la arquitectura de software, en función de los criterios considerados para
separar los asuntos de interés (concerns) arquitectónicos. Del resultado de este análisis, se
detectan los principales problemas y se presenta la propuesta para su solución que se hace
en esta tesis. Como primer paso para iniciar con la propuesta se definen las bases del
modelo de vistas que aquí se usa, especificando tanto los elementos y relaciones que lo
constituyen. A continuación, se realiza la especificación del modelo para cada una de las
vistas básica aquí consideras, la cual comprende a sus elementos, relaciones y notación
correspondiente.

Precisando el concepto de vista arquitectónica

Se han hecho algunas analogías para entender lo que una vista es, aunque no todas son del
todo apropiadas. Por ejemplo (Perry y Wolf, 1995) compara las vistas con los diferentes
planos arquitectónicos de un edificio, específicamente con los planos de planta y elevación
(proyección isométrica), cada uno equiparable a una vista,

49pero esto refleja una idea de dependencia más que de separación de elementos diferentes,
puesto que para crear el plano de elevación se requiere tener primero el de planta (el plano
de elevación es en parte una proyección del de planta), siendo que lo que se pretende con
las vistas es no hacerlas tan dependientes una de la otra (aunque estén relacionadas

La relación entre vistas, puntos-de-vista y concerns es ilustrada esquemáticamente por

(Kande y Strohmeier,2000), lo cual se muestra en la Figura 3.1, apreciándose cómo cada
uno de los dos puntos-de-vista ilustrados (el estructural y del análisis de la arquitectura),
establece un grupo de concerns, cuyas reglas para definirlos están contenidos en lo que ahí
se llama espacio-de-concerns, de dicho espacio también se llegan a generar las vistas que
modelan y representan a estos concerns.Existe otra definición sobre punto-de-vista para los
sistemas de software distribuidos que está dada por la norma ISO Reference Model of Open
Distributed Processing (RM-ODP) (ISO/IEC DIS 10746-3, 1993). Ahí un punto-de-vista es
considerado sólo como una forma de abstracción paraseleccionar a las construcciones
arquitectónicas con el fin de enfocarlas a concerns particulares dentro de un sistema, lo
Figura 3.1. Relación entre vista, punto-de-vista y concerns, tomado de (Kande y
Strohmeier, 2000)
53cual se enlaza con el concepto de abstracción dado por (Shaw 1984), descrito en párrafos
anteriores.

El punto-de-vista-empresarial, está dirigido hacia las necesidades de los usuarios de un

sistema de información, siendo el más abstracto de todos porque ahí se declaran las
políticas y requisitos empresariales de alto nivel.
El punto-de-vista de información, está enfocado al contenido de la información de la
empresa. Las actividades que esto conlleva son: la identificación de elementos de
información del sistema, las manipulaciones que pueden ser hechas con estos elementos y
los flujos de información en el sistema.
El punto-de-vista computacional, conduce a la partición lógica de las aplicaciones
distribuidas, independientemente del ambiente distribuido específico sobre las que ellas se

54ejecutan. Éste describe la funcionalidad que el sistema proporciona, manteniendo oculto

los detalles de la plataforma distribuida que soporta la aplicación.

El punto-de-vista de ingeniería, trata de los temas del soporte del sistema para las
aplicaciones distribuidas, enfocándose a identificar la funcionalidad de la plataforma
distribuida requerida para el soporte del modelo computacional.

El punto-de-vista tecnológico, como su nombre lo indica, se enfoca a identificar posibles

artefactos técnicos para los mecanismos de ingeniería, y para las estructuras tales como las
computacionales, de información y las empresariales. La consideración y descripción de
estos puntos-de-vista de la norma de RM-ODP sólo es útil en este trabajo para apreciar lo
que se puede ser considerado por un punto-de-vista, ya que no están orientados hacia la
arquitectura de software. Así que el concepto que es usado aquí sobre punto-de-vista es el
dado por (IEEE 1471, 2000) porque es el que hace referencia a las vistas.

Vista arquitectónica: ‘Es una representación de una estructura arquitectónica que está
compuesta por elementos y de las relaciones asociadas con ellos, dicha estructura
representa al sistema completo y es formada desde la perspectiva de un conjunto de
concerns relacionados que involucra a los actores del sistema’. Una estructura es tomada
aquí como: ‘el conjunto deelementos por sí mismos, tal como ellos existen en el software’
(Clements et al., 2003, pag. 35). Una estructura arquitectónica precisa que el conjunto de
estos elementos de software, corresponde sólo a los que se toman en cuenta en el nivel
arquitectónico, y no a los que están en todos los demás niveles del software.

Los modelos propuestos de vistas en la arquitectura

En el capítulo anterior, se ha mencionado que la separación de concerns en los sistemas de

software en forma multidimensional reduce los problemas que se presentan en

56el diseño del software. Uno de los medios para llevar a cabo esta separación en varias
dimensiones, es a través de la descomposición del sistema en estructuras que representan
las vistas, pues como se cita en (Courtois, 1985) ‘...la descomposición de un sistema en
estructuras es esencial para un entendimiento del sistema con muchos niveles, y para
resolver los problemas que surgen durante su análisis.

Niveles de Diseño de Software.

Diseño de software

Definición diseño de software

Diseño de software es el proceso de diseño para la planificación de una solución de

software. Este proceso es, por regla general, necesario para que los programadores puedan
manejar la complejidad que la mayoría de los programas informáticos poseen y para
disminuir el riesgo de desarrollos erróneos.

Ingeniería de requerimientos

Generalmente, cliente y contratista analizan primero los requerimientos que resultan, desde
el punto de vista del cliente, para el software a diseñar. En este contexto, el cliente prepara
el así llamado pliego de condiciones.

Realización

A continuación, cliente y contratista elaboran un concepto, en el que se define con qué

estructuras de programa, técnicas de programación y algoritmos los requerimientos
analizados anteriormente se deben cumplir y programar. El contratista especifica los
resultados de este concepto en el denominado pliego de condiciones.

Estado Actual de la Tecnología.

La tecnología avanza a velocidades de vértigo y las grandes, medianas y pequeñas

empresas pisan el acelerador para estar al día de cualquier cambio, e incluso generarlo.
Pero, ¿estamos los usuarios preparados para este ritmo de innovación?

En su estudio anual Trends View sobre los aprendizajes tecnológicos que nos dejó 2017, la
consultora The Cocktail analiza las tendencias que siguen las empresas en su relación con
el consumidor y las nuevas tecnologías a las que los clientes estamos expuestos. La
conclusión es que estamos funcionando a dos velocidades: mientras que las compañías
apuestan por la innovación, la experiencia del cliente y gran cantidad de información y
contenidos, los usuarios aún arrastramos desconfianzas del pasado. The Cocktail resume la
situación tecnológica actual en varios puntos:

 Sobreestimulación. La cantidad de información y contenidos al alcance del usuario

y la ausencia de herramientas para distinguir qué es más importante acaba
desembocando en un estado de constante alarma donde es difícil distinguir lo
verdadero de lo falso. Ante ello, desde la consultora proponen a las marcas
recuperar su legitimidad como líderes del sector, convertirse en expertos que guían
al consumidor.
 Demasiada disrupción. El consumidor todavía no ha asumido algunas
innovaciones cuando ya se está hablando de nuevas. Por ejemplo, en el caso de los
medios de pago hay multitud de nuevos players (bancos, fintech, tecnológicas...)
mientras el usuario muestra, por ahora, limitado interés.
 Cuerpo humano como interfaz. El cuerpo se ha convertido en la mejor
herramienta para la tecnología. Desbloquear el móvil con el rostro, pagar con la
huella dactilar, pedir algo mediante comandos de voz o hacer una foto mediante una
sonrisa es cada vez más habitual.
 'Efecto oportunidad.' Las campañas de último minuto tipo Black Friday, Límite 48
horas o Días sin IVA, consiguen crear una gran necesidad en los consumidores para
adquirir productos antes de que se agoten. En Zara, por ejemplo, se empieza a
integrar información meteorológica para planear sus campañas y adecuar su
operativa: 'Compra un abrigo si hoy hace frío'.
 Más tiendas físicas. Hace un par de años los establecimientos veían amenazado su
reinado por el aumento de las tiendas online. Ahora, incluso las tiendas en Internet
apuestan por abrir sus propios negocios físicos, como por ejemplo Amazon o
PcComponentes. Los flagship se convierten en tiendas para experimentar e incluso
marcas como Sanex, La Vaca Que Ríe o Colgate van a abrir sus propios
establecimientos. "El punto físico va a tomar un papel especialmente relevante para
construir diferenciación y donde la marca pueda proponer una experiencia única y
de valor con el consumidor. M&M o Lego ya han construido su propia experiencia
física y demuestran que es el momento en el que marcas (de todos lo sectores) se
planteen cuál es la experiencia física que la define para construir relación con el
consumidor", explica María Herranz, de The Cocktail Analysis.

Cuidado con lo colaborativo. The Cocktail advierte: "Si en años pasados la economía
colaborativa se presentaba (y era aceptada) como un espacio desintermediado en el que los
ciudadanos intercambiaban de forma autónoma, en 2017 esta percepción se modifica: se
empiezan a sentir los efectos secundarios de la desregulación y se identifican grandes
intereses corporativos detrás de estas plataformas". Buen ejemplo de ello son las protestas
de los conductores de Deliveroo o las asociaciones creadas contra Airbnb y los pisos
turísticos de alquiler.

Adiós al 'early adopter'. La tecnología ya no es solo para jóvenes o expertos. Todos somos
clientes potenciales de las grandes innovaciones del momento. El asistente de voz Alexa
cuenta ya con decenas de millones de usuarios en Estados Unidos con dos años de vida y en
España, Netflix llegó a mediados de 2016 y ya cuenta con más de 1.100.000 de usuarios.
Unidad: II REQUERIMIENTOS FUNCIONALES

Característica de Calidad de un Software.

Características de la calidad del

software
Repasa la lista y piensa en tu producto y en sus características. Añade aspectos específicos
para ajustar la lista a tu contexto y transfórmala a tu gusto.
Potencial. ¿El producto puede realizarfunciones valiosas?-Totalidad: todas las funciones
importantes deseadas por los usuarios finales están disponibles.-Precisión: cualquier cálculo
o resultado en el producto es correcto y se presenta con dígitos significativos.-Eficiencia: el
productorealizasus funciones de un modo eficiente (sin hacer lo que no se espera que
haga).-Interoperabilidad: las distintas funcionalidadesinteractúan entre ellas de la mejor
manera posible.-Concurrencia: capacidad del producto de ejecutar tareas múltiplesen
paralelo y funcionar al mismo tiempo que otros procesos. -Agnosticismo de datos: el
producto soporta todos los formatos de datos posibles y puede gestionar el "ruido" de los
mismos.-Extensibilidad: capacidad,por parte de clientes o terceros,de añadir
funcionalidadeso cambiar el comportamiento del producto.
Fiabilidad. ¿Puedes confiar en el producto en situaciones de distinta índole y dificultad?-
Estabilidad: el producto no debe sufrir caídas, excepciones no controladas ni errores en la
secuencia de comandos.-Robustez: el producto gestiona adecuadamente tanto los errores
previstos como los no previstos.-Gestióndelestrés: ¿cómo hace frente el sistema a
situaciones en las que se superan los límites existentes?-Recuperabilidad: el producto puede
recuperarsey seguir siendousado tras un error crítico.-Integridaddelosdatos: los distintos
tipos de datos se mantienen íntegrosalo largode todo el producto.-Inocuidad: el producto no
puede hacer daño a las personas o sus posesiones.-Recuperaciónfrenteadesastres: ¿y si
sucede algo realmente malo?-Integridad: ¿el comportamiento del producto es consistente,
predecible y confiable?
Usabilidad. ¿El producto es fácil de usar?-Factibilidad: el producto invita a descubrirsus
propias posibilidades.-Carácter intuitivo: es fácil entender y explicar lo que el producto
puede hacer.-Minimalismo: no hay redundanciaen el contenido o apariencia del producto.-
Facilidaddeaprendizaje: es rápido y fácil aprender a usar el producto.-
Defácilmemorización: una vez has aprendido a hacer algo, no se te olvida.-
Defácildescubrimiento: la información y capacidades del producto pueden ser descubiertas
mediante la exploración de la interfaz de usuario.-Operabilidad: un usuario experimentado
puede realizaracciones comunes con rapidez.-Interactividad: los estados del producto y las
posibilidades de interactuar con la aplicación (vía interfaz de usuario o APIs) son fáciles de
entender.-Control: el usuario debe sentirse con control sobre los procesos del software.-
Claridad: ¿está todo indicado explícitamente y con detalle, en un lenguaje comprensible
que no deje lugar a dudas?-Errores: haymensajes de error informativos, es difícil cometer
fallos y fácil recuperarse tras cometerlos.-Consistencia: el comportamiento es el mismo a
través del producto, y hay un único look & feel.-Configuración: las opciones y los
comportamientos por defecto pueden personalizarse, para una mayor flexibilidad.-
Accesibilidad: el producto puede ser utilizado por la mayor cantidad posible de personas y
cumple los estándares de accesibilidad aplicables.-Documentación: hay una ayuda que
realmente ayuda y que encaja con las funcionalidades.
Carisma.¿El producto "lo" tiene?-Unicidad: el producto es distinguible y tiene algo
queningún otro tiene.-Satisfacción: ¿cómo te sientes tras usar el producto?-Profesional:
¿tiene el producto un aire adecuado de profesionalidad y de encaje con su cometido?-
Atractivo: los distintos aspectosdel producto, ¿son atrayentes a la vista y demás sentidos?-
Curiosidad: ¿se interesarán los usuarios por el producto e intentarán averiguar qué pueden
hacer con él?-Hechizo: los usuarios, ¿se enganchan, disfrutan con fluidez y están totalmente
abstraídos mientras usan el producto?-Moda: ¿el producto debería usar las tecnologías/ideas
más modernas y potentes?-Expectación: el producto supera tusexpectativas e incluso
satisface necesidades que no sabías que tenías.-Actitud: ¿tienen el producto y su contenido
la actitud adecuada y se comunican contigo mediante un lenguaje y tono correctos?-
Dirección: las (primeras) impresiones del producto, ¿impresionan?-Historia: ¿existen
historias fascinantes sobre la concepción, construcción o uso del producto?
Seguridad.¿El producto se protege contra su uso indebido?-Autenticación: identificación
de los usuarios por parte del producto.-Autorización: gestión por parte del producto de lo
que un usuario autenticado puede ver y hacer.-Privacidad: capacidad de no revelar datos
protegidos a usuarios no autorizados.-Agujeros de seguridad: el producto no debería invitar
al descubrimiento desusvulnerabilidadesmediante el uso de ingeniería social.
-Secreto: el producto no debe revelar información sobre sus sistemas internosbajo ninguna
circunstancia.-Invulnerabilidad: capacidad de resistir ataques.-Sin virus: el producto no
debe contenervirus, ni comportarse como tal.-Resistenciaa la piratería: no hay posibilidad
de copiar ni distribuir ilegalmente el software o su código.-Conformidad: adecuación a los
estándares de seguridad a los que se adhiere el producto.
Rendimiento. ¿El producto es suficientemente rápido?-Capacidad: los múltiples límites del
producto, en distintas circunstancias (por ejemplo, lentitud en la red).-Utilizaciónde
recursos: uso adecuado de memoria, almacenamientoy otros recursos.-Capacidad de
respuesta: velocidad a la que una acción es (percibida como) realizada.-Disponibilidad: el
sistema está disponible para su uso cuando debe estarlo.-Caudal: capacidad del producto de
procesar grandes volúmenes de cosas.-Resistencia: ¿el producto puede aguantar carga
durante un periodo prolongado?-Retroalimentación: ¿es apropiada la retroalimentación por
parte del sistema ante las acciones del usuario?-Escalabilidad: ¿el producto reacciona
adecuadamente cuando es escalado horizontal o verticalmente, tanto a mayor como a menor
capacidad?
Capacidad tecnológica.¿Es fácil de instalar, mantener y dar asistencia al producto?-
Requerimientos del sistema: capacidad de funcionar en las configuraciones soportadas, así
como de gestionar entornos distintos y ausencia de componentes.-Instalación: el producto
es instalable en las plataformas esperadas usando la cantidad de recursos adecuada.-
Actualizaciones: facilidad de actualizar el producto a una versión más recientesin perder la
configuración ni los ajustes de usuario.-Desinstalación: ¿se eliminan todos los ficheros y
recursos del programa (salvo los del usuario o sistema) cuando éste se desinstala?-
Configuración: ¿la instalación puede configurarse de diversas maneras para ajustarse a las
necesidades del usuario?-Despliegue: el producto puede ser desplegado por parte del
departamento de TI a distintos tipos de usuarios (restringidos) y entornos.-Mantenibilidad:
¿es fácil de mantener y dar soporte a los usuarios sobre el producto y sus artefactos?-
Capacidad de prueba: ¿cuán eficientemente puede el cliente testear el producto desplegado?
Compatibilidad.¿Cómo interacciona el producto con otros programas y entornos?-
Compatibilidad de hardware: el producto puede usarse con las distintas configuraciones
delhardware indicado.-Compatibilidad de sistema operativo: el producto funciona en las
versiones indicadasde los sistemas operativos compatibles, comportándose tal y como se
esperaen ellos.-Compatibilidad de aplicación: el producto y sus datos funcionan
conjuntamente con las demás aplicaciones que el usuario desea.-Compatibilidad de
configuración: capacidad del producto de integrarse con las configuraciones del entorno.-
Compatibilidad regresiva: ¿el producto puede hacer todo lo que hacía su versión anterior?-
Compatibilidad a futuro: ¿será el producto capaz de usar artefactos o interfaces de
versiones futuras? -Sostenibilidad: efectos en el medio ambiente, por ejemplo: eficiencia
energética, desconexiones, modos de ahorro de energía, teletrabajo.-Conformidad con los
estándares: el producto es conforme a los estándares, regulaciones, leyes o códigos éticos
aplicables.
Características internas de la calidad del software
Estas características no son experimentadas directamente por los usuarios finales, pero
pueden ser también importantes para conseguir el éxito del producto.
Soporte. ¿Se puede dar soporte al uso real del producto y sus problemas asociados?-
Identificadores: ¿es fácil identificar partes del producto, sus versiones o errores
específicos?-Diagnóstico: ¿es posible obtener detalles de los problemasespecíficosde los
usuarios? -Resolución de problemas: ¿es fácil identificar errores (por ejemplo,en los
ficheros de log) y obtener ayuda?-Depuración: ¿se pueden observar los estados internos
delprograma cuando es necesario?-Versatilidad: capacidad de usar el producto con más
fines de los previstosinicialmente.
Capacidad de prueba.¿Es fácil probarel producto?-Trazabilidad: el producto guarda
registrode las acciones acorde alos niveles de traza adecuados y en un formato usable.-
Control: capacidad de establecer estados, objetos o variables de forma independiente.-
Observación: capacidad de observar cosas que deben ser probadas.-Monitorización: ¿el
producto puede dar pistas de qué está haciendo y cómo?-Aislamiento: capacidad de probar
una parte del producto por sí misma.-Estabilidad: los cambios en el software están
controlados y no son muy frecuentes.-Automatización: ¿existen interfaces programáticas,
ya sean públicas u ocultas, que puedan ser usadas?

-Información: el producto proporciona medios para que los testers puedan aprender
delmismolo que necesiten para realizar su tarea.-Auditoría: ¿pueden el producto y sus
derivadosser validados?

Mantenimiento.¿Se puede mantener y ampliar el producto a bajo precio?-Flexibilidad:

capacidad de cambiar el producto bajo petición.-Extensibilidad: ¿será fácil añadir nuevas
funcionalidadesen el futuro?-Simplicidad: el código no es más complejo de lo necesario y
no dificulta el diseño, ejecución o evaluación de las pruebas.-Legibilidad: el código está
documentado adecuadamente y es fácil de leer y entender.-Transparencia: ¿es fácil entender
las estructuras subyacentes del producto?-Modularidad: el código está separadoen partes
manejables.-Refactorizable: ¿estás satisfecho con las pruebas unitarias del producto?-
Análisis: capacidad de encontrar las causas de los defectos uotras partes del código que
sean deinterés.
Portabilidad.¿Es posible transferir el productoa otros entornos o lenguajes?-Reusabilidad:
¿se pueden reusar partes del producto en otros lugares? -Adaptabilidad: ¿es fácil
modificarel producto para que soporte un entorno distinto?-Compatibilidad: ¿el producto
cumple con interfaces comunes o estándares oficiales?-Internacionalización: es fácil
traducir el producto.-Localización: ¿están las distintas partes del producto preparadas para
satisfacer las necesidades de los países o culturas objetivo?-Robustez de la interfaz de
usuario: ¿el producto tendrá el mismo buen aspecto una vez traducido

Característica propiciada por la arquitectura lo I.S.O 9126

Cuando estamos desarrollando un software es importante comenzar bien, con el pie

derecho, por eso que mejor que conocer los estandares que al final del ciclo de vida del
desarrollo seran usados para evaluar y determinar si nuestro software es de Calidad por que
no tenerlos en cuenta para ir adelantando trabajos e ir construllendo el software con esas
caracteristicas que al final no las van a medir. 

Para ello la ISO-9126 define bastante bien unas caracteristicas que yo nombro como
singularidades que suena mas a Fisica.

Las siguiente son las caracterisiticas que la ISO-9126 establece para un software.

Funcionalidad

Singularidad que permite calificar si un software maneja de forma adecuada las funciones
que satisfagan las necesidades para las cuales fue diseñado.

Atributos

 Adecuación: Permite medir si el software cuenta con las funciones apropiadas para
efectuar las tareas que fueron especificadas en su diseño.

 Exactitud: Permite medir si el software presenta resultados o efectos acordes a las

necesidades para las que fue creado.

 Interoperabilidad: Permite medir la habilidad del software para interactuar con otros
sistemas específicos.

 Conformidad: Permite medir si el software se adhiere a estándares o convenciones

relativas al software o regulaciones de tipo legal.

 Seguridad: Permite medir si el software posee la habilidad para evitar acceso no

autorizados, accidentales o deliberados, a los programas o datos.

 
Confiabilidad

Singularidad que permite calificar la capacidad de un software en mantener su nivel de

ejecución bajo un periodo de tiempo establecido.

Atributos

 Nivel de madurez: Permite medir la frecuencia de falla por errores en el software.

 Tolerancia a fallas: Permite medir la habilidad de mantener un nivel de

funcionamiento en caso de fallas del software o infracciones de su interfaz
especificada.

 Recuperación: Permite medir la habilidad de restablecer el nivel de operación y de

recobrar los datos que hayan sido afectados en caso de una falla. Adicionalmente el
esfuerzo y tiempo necesario para ello.

Usabilidad

Singularidad que permite calificar el esfuerzo necesario que requiere el usuario para utilizar
el software.

Atributos

 Compresibilidad: Permite medir el esfuerzo que requiere el usuario para reconocer

la estructura lógica y los conceptos relativos del software.

 Facilidad de Aprender: Permite medir el esfuerzo que requiere el usuario para

aprender a como usar el software.

 Operatividad: Permite medir el esfuerzo que requiere el usuario para la operación y

control del software.

Eficiencia

Singularidad que permite calificar el grado en el que el software hace óptimo el

funcionamiento del software con respecto a la cantidad de recursos usados.

Atributos

 Comportamiento con respecto al tiempo: Permite medir los tiempos de respuesta y

de procesamiento de los datos.
  Comportamiento con respecto a recursos: Permite medir la cantidad de recursos
empleados y la duración de ese uso en el desempeño de sus funciones.

  

Mantenibilidad

Singularidad que permite calificar el esfuerzo necesario que se requiere para realizar
modificaciones al software, ya sea por corrección de errores o por el incremento de
funcionalidad.

Atributos

 Analizabilidad: Permite medir el esfuerzo necesario para diagnosticar las

deficiencias o causas de fallas, o para identificar las partes que se deben modificar.

 Cambiabilidad: Permite medir el esfuerzo necesario para realizar modificaciones,

remover fallas o adaptar el software a un entorno diferente.

 Estabilidad: Permite medir los riesgos de efectos inesperados debido a

modificaciones realizadas al software.

 Facilidad de prueba: Permite medir el esfuerzo necesario para validar el software

una vez fue modificado.

Portabilidad

Singularidad que permite calificar la habilidad que tiene el software para ser trasladado de
un entorno a otro.

Atributos

 Adaptabilidad: Permite medir la oportunidad que tiene el software para ser adaptado
a diferentes entornos especificados sin la aplicación de modificaciones o medios
provistos para este propósito.

 Facilidad de instalación: Permite medir el esfuerzo necesario para instalar el

software en un ambiente de trabajo.

 Conformidad: Permite medir si el software se adhiere a estándares o convenciones

relativas al software o regulaciones de tipo legal relativas a la portabilidad.

 Reemplazabilidad: Permite medir la oportunidad y el esfuerzo requerido para

sustituir el software en el entorno especificado por otro con funciones similares.
Unidad: III ESTILO ARQUITECTONICO
Definición, tipos cualidades de software que propicia.
CUALIDADES DE LAS ARQUITECTURAS•MODULARIDAD.
Sin considerar el enfoque de diseño utilizado (estilo arquitectural) (Lawrence, 1998), el
proceso de descomposición separa el diseño en partes que lo componen, llamadas
móduloso componentes. Se dice que un sistema es modular cuando cada actividad del
sistema de software es ejecutada exactamente por un componente y cuando las entradas y
las salidas de los componentes están bien definidas. Los módulos se organizan
jerárquicamente como resultado de la descomposición. En la opinión de Pressman
(Pressman, 1998), estos módulos se integrarán para satisfacer los requisitos del sistema.
Para este autor modularidad es el atributo del software que permite a un sistema ser
manejable intelectualmente. Lawrence (Lawrence, 1998) además agrega que los módulos
encapsulan información; la ventaja de esta característica es que el diseño interno de cada
componente está oculto para el resto de los otros componentes.

CUALIDADES DE LAS ARQUITECTURAS•NIVELES DE ABSTRACCIÓN .

Según Lawrence (Lawrence, 1998), estos módulos se estructuran según niveles de
abstracción. Estos niveles de abstracción ayudan a entender el problema a ser resuelto por
el sistema y la solución propuesta. Según Pressman (Pressman, 1998), cuando se plantea
una solución modular se pueden presentar muchos niveles de abstracción. Cada fase del
proceso de diseño es un refinamiento en el nivel de abstracción. Pressman (Pressman,
1998) propone tres (3) niveles de abstracción:–Abstracción procedimental.Es una secuencia
dada de instrucciones que tiene una función específica y limitada.–Abstracción de datos.Es
una colección determinada de datos que describen un objeto de datos.–Abstracción de
control.Implica un mecanismo de control del programa sin especificar detalles internos.

NIVELES DE DISEÑO DE LOS SISTEMAS DE SOFTWARE•

ARQUITECTURA.
Los aspectos de diseño involucran la asociación de la capacidad de todo el sistema con
componentes. Los componentes son módulos y la interconexión entre los módulos se
maneja de maneras diferentes. La composición está orienta hacia subsistemas.
•CÓDIGO.El diseño involucra algoritmos y estructuras de datos. Los componentes son
primitivas de lenguajes de programación, tales como números, caracteres, etc. Los
mecanismos de composición son arreglos, registros, procedimientos, etc.
•EJECUTABLE.El diseño involucra mapas de memoria, arreglos de datos, asignaciones de
registros, etc. Los componentes son patrones de bits soportados por el hardware y las
composiciones se escriben en lenguaje de máquina.

2. CLASIFICACION DE LOS ESTILO ARQUITECTONICO

ESTILOS ARQUITECTÓNICOS
Un estilo arquitectónico define una familia de sistemas de software en términos de su
organización estructural. Un estilo arquitectónico representa los componentes y las
relaciones entre ellos con las restricciones de su aplicación y las asociaciones y reglas de
diseño para su construcción. Shaw y Garlan (Shaw y Garlan, 1996) precisan, además, que
un estilo arquitectónico define un vocabulario de componentes y tipos de conectores.
ESTILOS ARQUITECTÓNICOS
PIPES and FILTERS (Tuberías y filtros)Cada componente tiene un conjunto de entradas y
un conjuntode salidas.• Un componente lee la ráfaga (stream) de datos en sus entradas y
produce una ráfaga de datos en sus salidas.• Los componentes se conocen como filtros y
son independientes.• Los conectores se comportan como conductores de las ráfagas,
transmitiendo salidas de un componente hacia entradas de otro.• El mejor ejemplo de este
estilo son los programas escritos en el Shellde Unix (Bach, 1986). Otros ejemplos se
observan en el área de procesamiento de señales, programación paralela y sistemas
distribuidos.

ESTILOS ARQUITECTÓNICO
SORGANIZACIONES POR TIPOS DE DATOS ABSTRACTOS Y O-OLa representación
de los datos y sus operaciones primitivas seencapsulan en Tipos de Datos Abstractos
(TDA) u objetos.• Los componentes son objetos (o instancias de tipos de datos abstractos).
Los objetos son ejemplos de un tipo de componente llamado manejador porque es el
responsable de preservar la integridad de un recurso• Los objetos interactúan a través de
invocaciones a funciones y procedimientos.• La implementación de las funciones y
procedimientos está oculta para el objeto cliente, lo cual permite hacer las modificaciones
fácilmente.• Para hacer uso de un servicio se hace necesario conocer la identidad del objeto;
al hacer un cambio en un objeto es necesario modificar todos los objetos que lo invocan.

ESTILOS ARQUITECTÓNICOS
BASADOS EN EVENTOS, INVOCACIÓN IMPLÍCITAEn el estilo anterior, la interfaz de
los componentes (objetos)cuentan con una colección de procedimientos y funciones, y
laintegración entre ellos se logra a través de la invocación explícitade éstos. En este estilo,
se considera una técnica de integraciónconocida como invocación implícita.• Los
componentes son módulos cuyas interfaces proveen una colección de procedimientos y un
conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente
también puede activar algunos de sus procedimientos con los eventos del sistema. Esto hará
que estos procedimientos sean invocados cuando los eventos ocurren en tiempo de
ejecución.• Los generadores de eventos no saben cuales componentes se afectarán por el
evento. Ejemplos de este estilo son los sistemas de gestión de bases de datos cuando
aseguran la consistencia de los datos, las aplicaciones con interfaces de usuarios al separar
la representación de los datos de las aplicaciones que las gerencia.

ESTILOS ARQUITECTÓNICOS

SISTEMAS EN CAPAS
Están organizados jerárquicamente; cada capa le presta serviciosa la capa superior y es
cliente de la capa inferior. • Los componentes implementan un máquina virtual en alguna
capa dela jerarquía. • Los conectores están definidos en los protocolos que determinan
cómo las capas interactúan. • Los ejemplos más conocidos de este estilo arquitectural son
los protocolos de comunicación.

ESTILOS ARQUITECTÓNICOS
REPOSITORIOS
Consta de dos (2) tipos de componentes: una estructura central de datosque refleja el estado
actual y una colección independiente de compo-nentes que operan sobre el almacén
central.• Las interacciones entre los componentes pueden variar significativamente. El tipo
de control seleccionado puede llevar a dos categorías:– Si el tipo de transacción es una
entrada que dispara la selección del proceso a ejecutarse, se está hablando de las
tradicionales bases de datos.– Si el estado actual de la estructura central de datos es el
principal activador de los procesos a ejecutarse, se habla de un estilo de repositorio tipo
pizarrón (blackboard). Son muy utilizados para aplicaciones que requieren interpretaciones
complejas de procesamiento de señales, tales como reconocimiento del habla y de patrones.

STILOS ARQUITECTÓNICOS
INTÉRPRETES
En una organización intérprete, una máquina virtual es produce-da en software. Un
intérprete incluye el pseudoprograma inter-pretado y la máquina de interpretación misma. •
Los intérpretes son a menudo usados para construir maquinas virtuales que enlazan la
máquina de computación esperada por la semántica y la máquina de computación
disponible en el hardware.

3. PRINCIPALES ESTILO ARQUITECTONICOS:

ESTILO DE FLUJO DE DATOS, ESTILO CENTRADO DE DATOS, ESTILO DE
LLAMADA Y RETORNO, ESTILO DERIVADOS, ESTILO DE CODIGO MOVIL,
ESTILO HETEROGENEO, ESTILO DE PINTUPOBIL